1. Chapter 13 Application Framework

2. Outline Definition & anatomy Fulfilling the framework contract Building frameworks Examples

3. Outline Definition & anatomy Fulfilling the framework contract Building frameworks Examples

4. Definition An application framework may be roughly defined as a set of interacting object that, together, realize a set of functions.

5. An application framework may be described by the equation: Application Framework=a blueprint + component realization

6. The anatomy of a framework A set of participant of the framework A set of relationships between the participants of the framework A set of interaction scenarios between the participants of the framework

7. MVC framework Model Update Display Application calls Notification State data Controller View

8. Model: The model is the part responsible for the application s state and behavior, and for notifying the other components of state changes. A simply define as follows: interface Model { void iChanged (String aspect, Object value); Object getState (); }

9. View: The view is the part responsible for the graphical display. A simply define as follows: interface View { void update (String property, Object from, Object value); void display (); }

10. Controller: The controller is the component that is responsible for reacting to user inputs, and for translating them into actions to be execute on the application side. A simply define as follows: interface Controller { void KeyPressed (String key, Point cursorPt); void leftMouseButtonPressed (Point cursorPt); void rightMouseButtonPressed (Point cursorPt); }

11. What we get in this simplistic MVC framework? 1.The mere description of the interface of the participant is far too little information to understand how the framework works. 2.We don t know half the story without seeing the interaction between the various methods.

12. 1 Our presentation of the interfaces was accom- panied by textural descriptions, which expli- cated ( ) both the relationships and the interactions

13. 2 There are two basic interaction paths through the various components: c.leftMouseButtonPressed () m. m. m.ichanged (stateVar, val) v.update (stateVar, m, val) The description of the scenarios is referred to as message sequence, and is one way of representing the interaction behavior or interobject behavior that is inherent in the framework.

14. Model Contr- oller View getState ()iChanged(…) leftMouseButtonPressed (…) update (…) display () Figure 13.2 The participants represent pluggable components into an interaction infrastructure

15. The smalltalk MVC framework includes classes for handling low-level interface events that connect the event management functionalities of the host windowing system with controllers. We refer to that part of the framework as the interaction infrastructure Interaction infrastructure

16. Framework will typically come with simple realizations of some of the participants. Model Controller View Customer code

17. Instantiation scenario Framework users need to know: how to assemble the various components

18. Example: | myModel myView myController | instantiate CheckingAccount Account := CheckingAccount new create view for account myView :=MyViewClass new: account. set the controller to a MyControllerClass myView controller: (MyControllerClass new).

19. Describe a framework for the user, we need to specify the following: The set of participants of the framework, in term of the interfaces that they have to support The set of relationships between them The set of interaction scenarios between the participants that are mediated by the interaction infrastructure of the framework The set of instantiation scenarios, showing how to assemble an instance of the framework

20. The framework reuse lifecycle Specify the need in terms that can be match against the available descriptions of the reusable artefacts. Search and retrieve the most relevant artefacts Assess ( ) their reuse potential. Select the best fit candidate, and adapt it to the current need. Integrate it in the current application.

21. Outline Definition & anatomy Fulfilling the framework contract Building frameworks Examples

22. Key concern in developing reusable assets ( ) Key concern in developing reusable assets is to identify, isolate, and encapsulate the variabilities within an application domain in such a way to maximum the common pars, and to constrain the development of the variable part. For the case of object frameworks, given a set of objects that we know we need, and that have to collaborate to achieve a set of functions.

23. The concern If we break the necessary collaboration between components, we can make it possible to: –Implement as much of the common parts as possible –Interchange the collaborating components with little or no effect on the rest of the components.

24. Design Pattern Design pattern are use to mediate the interactions within an object framework. This is an indication of both, where to find good design pattern, and how to build good object frameworks:

25. Design Pattern (cont.) Good application frameworks are a source for good design patterns. Once we have identified the components of a framework, and their semantic dependen- cies, we can minimize the implementation of those dependencies by applying design patterns.

26. Figure 13.4 Frameworks accommodate variab- ilities by instantiating appropriate design patterns

27. Component substitutability When we select classes to play the roles of specific participants, we use inheritance, polymorphism, and dynamic binding, to make sure that an instance of the framework will work properly

28. Inheritance The actual participants are subclasses of abstract that represent the participants. Type Conformance. Ensuring the type conformance of the actual participants to what is expected of them in the framework. Extension. The abstract classes are not only used to represent obligations but also provide some of the behavior.

29. Polymorphism We allow the code of the framework that was written generically for the participants classes to work with actual implementations of those participants.

30. Dynamic binding We enable polymorphic code to always invoke the method implementations that are most appropriate to the actual object being used.

31. Example Class OTC_Dispatcher:...{ //participant: provide parts of the implementation Collection * jobQueue; Public: OTC_Dispatcher (Collection * jobs = null ) { setJobQueue (jobs); … } (1) virtual void log (OTC_Job* job) { cout << Executing: << job <<endl; } (2) void setJobQueue (Queue * queue) { … } (3) int dispatch () { //general and shouldn t be redefined int nbJobs = 0 ; (3.1)while (jobQueue -> hasMoreElement () ) { (3.2)OTC_Job* nextJob = selectFirstJob () ; //inheritance, (3.3)nextJob ->start (); //polymorphism, //and dynamic binding

32. (3.4)log (nextJob); nbJobs ++; } return nbJobs; } … (4) virtual OTC_Job* selectFirstJob () = 0; //all subclass of OTC_Dispatcher have //to provide their own definition … } Class OTC_Job: … { //participant: provide parts of the implementation Public: (5)virtual void start () { initialise (); run (); end (); } (6) virtual void initialise () = 0; (7) void run () { … } (8)virtual void end () = 0; }

33. The same ex. in java interface Dispatcher { //separate the interface and implementations. public void log (Job aJob); public void setJobQueue (Collection Queue); public int dispatch (); public Job selectFirstJob (); } interface Job { public void start (); public void initialise (); public void run (); public void end (); } Assume that we have two classes OTC_Dispatcher and OTC_Job which implement this two interface respectively.

34. Departures from the C++ implementation 1.Participants classes do not have to inherit from any particular class 2.The provided abstract classes (OTC_Dispa-tcher and OTC_Job ) refer to each other through the Dispatcher and Job interfaces, and not by name, which would allow them to work not only with each other but also with any other class that implements the corresponding interface.

35. Another issue: Assembling participants to instantiate a framework Despite our best efforts to abstract the roles of the components, we could still be left with implementation-level dependencies between the participant components, which are not adequately expressed by abstract interface.

36. Example In a portable GUI framework that can emulate various native interfaces, there is the implicit assumption that the realization of the CompositeContainer widget be compatible with the TextView widget.

38. ButtonPanel WButton XButtonXPanel WPannel Figure 13.5 Mutually consistent specializations

39. An acceptable solution: factory class Factory class (ref. Design Pattern [Gamma et al. 1994]) consists of including, in the framework, a class whose only purpose is to manufacture ( ) objects that play specific roles.

40. In this case, an abstract factory class would look like: abstract class WidgetFactory { abstract public Button getButton (); abstract public Panel getPanel (); abstract public ListView getListView (); … }

41. Then we can have subclasses of the widget factory that would create mutually consistent instances of the various participants, as in: class Win32WidgetFactory extends WidgetFactory { public Button getButton () {return new WButton (); } public Panel getPanel () {return new WPanel (); } public ListView getListView () {return new WlistView (); }

42. and : class XWidgetFactory extends WidgetFactory { public Button getButton () {return new XButton (); } public Panel getPanel () {return new XPanel (); } public ListView getListView () {return new XlistView (); }

43. Composability requirement (ch. 12) For reusable artifacts to be composable, a number of criteria have to met: –Two components are able to communicate and to interoperate. –They need to be independent

44. Composition issue How to compose objects without creating dependencies between them? –An acceptable solution: Adapter pattern

45. Adapter pattern (1) Problem –You want to use a class that calls a method through an interface, but you want to use it with a class that does not implement that interface. Solution –Convert the interface of a class into another interface client expect. –Adapter lets classes work together that couldn t otherwise because of incompatible interface.

46. Adapter pattern (2) Structure –A class adapter uses multiple inheritance to adapt one interface to another.

47. Adapter pattern (3) Structure –An object adapter relies on object composition

48. Adapter pattern (4) Consequences –Class and object adapters have different trade- offs. A class adapter a class adapter won t work when we want to adapt a class and all its subclasses. Let Adapter override some of Adaptee s behavior, since adapter is a subclass of Adaptee. Introduces only one object, and no additional pointer indirection is needed to get to the adaptee.

49. Adapter pattern (5) –An object adapter Lets a single adapter work with many adaptees-the adaptee itself and all of its subclasses (if any). Make it harder to override adaptee behavior. It will require subclassing adaptee and making adapter refer to the subclass rather than the adaptee itself.

50. Outline Definition & anatomy Fulfilling the framework contract Building frameworks Examples

51. Building frameworks Researcher and practitioners alike agree that: 1.Frameworks are useful 2.Their development is difficult 3.Their development benefits from continual improvement based on actual reuse experience.

52. The first step in building framework is to identify the functional requirements, or domain scoping. Regarding the remaining steps, there are two school of thought ( ): –The top-down analytic school. –The button-up synthetic ( ) school.

53. Framework as products of domain engineering Designing and implementing a domain has to be incremental, for at least two reasons: 1.Extension 2.To road-test the architecture before developing components into this architecture.

54. Which part do we start with? The answer, from most experts, is to start with those aspect of the domain that have an influence on the architecture. A useful to think of the architecture in terms of two layer –Computational layer –Functional layer The computational layer underlies all of the functions

55. The functional layer may be more partitionable than the computational layer, and lend itself better to incremental development. Experts says: start with those functions that are likely to require most or all of the computational infrastructure so that the major design tradeoffs will be addressed with the first increment.

56. Framework as planned byproducts of application development The idea here is that we grow frameworks out of subset of applications within the targeted framework domain. We still need to elicit ( ) the requirements of the framework. We start building applications from the domain, and then start introducing variations in those part of the application.

57. A representative example Hotspot-driven development as advocated by Pree and Schmidt Two applications of a framework will differ by the binding of at least one hotspot. The idea here is to identify those hotspots early on in the process

59. The first iteration will solve a specific problem; later iteration will design variability into the identified hotspots. Designing a hotspot means changing a specific binding of a point of variation into: 1.An abstract description (a generalization) of the aspect of interest, and 2.A number of concrete realization (including the existing one)

60. Outline Definition & anatomy Fulfilling the framework contract Building frameworks Examples

61. The SWING framework Overview Event handling sub-framework Pluggable look-and-feel (PLAF) sub-framework

62. Overview The SWING framework is an all Java framework for building applications with graphical user interface. SWING is an adaptation of the MVC framework

63. AWT V.S. SWING The AWT API consists of the lowest common denominator ( ) of the various host platforms. This also means that an application can only have the look and feel of its host environment. SWING interacts with the host environment through AWT Java components, and it relies only on those AWT classes that are independent of the platform.

65. The event-handling framework MVC framework assign one object per view to handle all sort of user interactions. The SWING way is to have several control objects control the same view object, but each control object subscribing to one kind of user interactions.

66. The event-handling framework is fairly common, and may be found, in different flavors, in various GUI frameworks.

67. The pluggable look and feel framework In SWING, the look and feel of applications is delegated to a separate object, for added flexibility. The look of a widget has to do with the visual attributes. The feel of the interface is related to user input, and characterizes things. The SWING designers decided to encapsulate the look and feel of a GUI into a separate object called UI delegate

68. SWING designer decided to encapsulate the look and feel of a GUI into a separate object called UI delegate ( ), which can be changed while the application is running. JList UIManager (abstract) ListUI displaysmanages

69. JList UIManager BasicListUI Basic- LookAndFeel

70. Conclusion Application frameworks are an important part of successful reuse. By addressing all phases of the development lifecycle, we are able to attain ( ) higher levels of reuse. Developing frameworks means using the entire abstraction and composition arsenal ( ), and going at it in an incremental and disciplined ( ) fashion.