Frameworks: An Introduction

1. Frameworks: An Introduction

2. Approach • Gather materials from • [1] Design Patterns – Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (GoF), and • [2], by Craig Larman. • Two very widely recognized sources… • [3] Some great slides / words from Team 4’s presentation supplemented via emails / help from Ken Bedwell • Will take the GoF’s book first followed by Larman’s materials – interspersed with [3]. • Emphasizing ‘principles.’ • Please note that the text in the overheads comes almost verbatim from these sources.

3. Definition • According to Gamma, et al [1]: “A Framework is a set of cooperating classes that makes up a reusable design for a specific class of software.” • A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations.

4. Definition - more • A developer will normally customize a framework to a specific application by “subclassing” and composing instances of framework classes. • (will see ahead) • This notion of ‘subclassing’ and creating instances of framework classes is an essential principle.

5. Differences between Frameworks and Design Patterns(1 of 3) • Frameworks are more concrete than Design Patterns • Can be embodied in code but only examples of patterns can be embodied in code. • A strength: can be written down in a programming language and not only studied, but executed and reused directly. • In contrast, design patterns have to be implemented (GoF patterns) each time they’re used. (at a much higher level…) • Design patterns also explain the intent, tradeoff, and consequences of a design…

6. Differences between Frameworks and Design Patterns(2 of 3) • Frameworks are larger architectural elements than design patterns. • Can be huge! • Industrial strength frameworks – if they are versatile and meet their objectives for reusability, … – can be very Very ‘large.’ • A typical framework contains several design patterns, but the reverse is never true

7. Differences between Frameworks and Design Patterns(3 of 3) • Yet, frameworks are more specialized than design patterns. • Frameworks always have a particular application domain. • Frameworks have a particular focus. • Frameworks dictate an application architecture; design patterns do not. • Frameworks will consist of cooperating classes already set up to be used in a design via subclassing, etc.

8. Future of Frameworks • Frameworks are becoming more and more common and important. • Use of frameworks are perhaps the most significant way in which OO systems achieve reuse. • Larger OO applications will end up consisting of layers of frameworks that cooperate with each other • With specific frameworks tailored to specific application domains… • Most of the design and code in the application will come from or be influenced by the frameworks it uses.-

9. Examples: • A framework may be directed toward building graphical editors for different domains like artistic drawing, music composition, etc. • Another framework might help us build compilers for different programming languages and target machines.

10. A little closer to home… • Another framework might be used for storing persistent objects. [2] • This should sound familiar! • Ahead, will show an example framework and its use in Team 4’s presentation and finish with some thoughts on a persistence framework as a vehicle for explaining “general framework design” with patterns. • Please note that it is usually better to get or buy one of these frameworks than to build one, which can consume person-years of effort…

11. Framework Examples(taken from Team 4 presentation) • Simple: • CA7 (job scheduling and monitoring) • Medium • MTS (Microsoft) • Struts (J2EE coding/design framework) • Complex • .Net • J2EE – this is what Team 4 used… • Siebel (workflow engine) • WebMethods (web service orchestration)

12. Frameworks and Design Architecture • Frameworks do MUCH for us. • Frameworks take away some design freedom by dictating our application architecture and the number of design decisions we make are reduced • Frameworks define the overall structure, its partitioning into classes and objects, key responsibilities, collaborations and threads of control. • Decisions are taken away to allow application designer to concentrate on the specifics of the application.

13. Frameworks and Design Architecture • The framework captures the design decisions common in a specific application domain. • Frameworks emphasize design reuse over code reuse, though a framework will usually include concrete subclasses that you can put to work right away.

14. Just the opposite… In conventional subroutine calls, we write the main procedure and call the code we want to reuse. In frameworks, we reuse the main procedure and write the code it calls! We will write the operations with particular names and calling conventions – reducing our creativity and design decisions. Can thus build applications much faster!

15. Framework Design • Main contribution of a Framework: the architecture it defines. • Framework designers gamble that his/her framework will work for all applications in that domain. • Framework must be flexible and extensible; any serious changes to the design of the framework may reduce its effectiveness.

16. Frameworks and Patterns • Framework designers must address all these issues. • Framework designer is much more likely to meet the goals of the framework (design and code reuse) by using design patterns. • Most frameworks usually use several design patterns. (See [2] pp 540-564)

17. More Basics • Again, a framework (a bit oversimplified) is an extendable set of objects for related functions. • Classic example: a GUI framework, such as Java’s AWT or Swing, a persistence framework... • “Signature” of a framework is that it provides an implementation for the core and unvarying functions, and includes a mechanism to allow a developer to plug in the various functions, or to extend the functions.

18. In general, a framework:(example coming…) • Is a cohesive set of interfaces and classes that collaborate to provide services for the core, unvarying part of a logical subsystem • Contains concrete (and especially) abstract classes that • define interfaces to conform to, • object interactions to participate in, • and other invariants. • Usually, but not necessarily, the framework users is required to define subclasses of existing framework classes to make use of, customize, and extend the framework services,

19. In general, a framework:(example coming…) • A framework has abstract classes that may contain both abstract and concrete methods, • A framework relies on the ‘Hollywood Principle’ – ‘don’t call us, we’ll call you.” • This means that the user-defined classes (for example new subclasses) will receive messages from the predefined framework classes. • These are usually handled by implementing super class abstract methods. (like via generalization) • Now, an example….

20. We create this class! Here is an example (Group 4). The framework provides all the classes you see except the <<implementation>> class that fills the ‘User Action” role. This is the whole idea about Frameworks. The framework “calls” the UserAction code, which is something that application developers provide.

21. Given this, let’s apply previous principles (from previous overheads…) • Slide 13:Plug-in architecture – UserAction plugs into framework • Generic – Could be reused in other apps - Can see? • Could be used with great flexibility in other apps by • inheriting from the interface, Action. Basically, ActionServlet ‘calls’ UserAction…. • Slide 14: The framework captures the design decisions common in a • specific application domain… • Frameworks emphasize design reuse over code reuse

22. Slide 15: In conventional subroutine calls, we write the main procedure and call the code we want to reuse. In frameworks, we reuse the main procedure and write the code it calls! We will write the operations with particular names and calling conventions – reducing our creativity and design decisions. Can thus build applications much faster!

23. Slide 20: Usually, but not necessarily, the framework user defines subclasses • of existing framework classes to make use of, customize, and extend the • framework services. (see UserAction extending Action…) • The subclassing/implementation of Action is the key. (See UserAction above) • This allows ActionServlet to polymorphically call UserActions no matter what they do.

24. (repeated The subclassing/implementation of Action is the key. • (See UserAction above) This allows ActionServlet to polymorphically call • UserActions no matter what they do. • From the perspective of the framework, the UserAction simply has to • "execute()" itself, taking certain framework and infrastructure classes as • parameters. • What it does is irrelevant to the framework.

25. Additional Points Plug in architecture - revisited • So long as your UserActions live with the conventions of the framework, they will be called. (Said differently, the plumbing of J2EE and JDBC is largely taken care of by the framework.) Generic - revisited • The framework doesn't care if your application is managing a nuclear power plant or a day care center, it runs your UserActions just the same. • Conversely, you, as a developer, can use the framework on any kind of suitably architected project

26. Additional Points Polymorphic • Heavily polymorphic. Goes along with being generic. Hence it’s great appeal and power. Separation of concerns • In this example, the framework provides a consistent way to separate the presentation layer (JSP's and Form classes) from the business logic layer (UserActions) from the data access layer (Persistence subsystem). • Notice that this is an example of the Model-View- Controller (MVC) architecture discussed in the patterns class. • As mentioned, frameworks typically make heavy use of design patterns.

27. Some Last Thoughts [2] • Remember, Frameworks are targeted to a specific application domain and must be set up correctly. • Benefits include significantly increased developer productivity! • An organization that is interested in increasing its degree of software reuse should emphasize the creation of frameworks [2]

28. Our example: The Need for Persistent Objects. • Let’s assume our project data resides in a relational database. • This data must be brought into local memory…

29. Storage Mechanisms and Persistent Objects • Object Databases: - If an object database is used to store and retrieve objects, no additional custom or third-party persistence services are needed. (major attraction) • Relational databases: Very prevalent. If so, we have problems due to mismatch between record-oriented and object-oriented representations of data. • Need a special O-R mapping service. • Other: Data might be stored in other storage mechanisms/formats: flat files, XML structures, Palm OS PDB files, hierarchical databases, … • If so, special services are required to enable us to used them as objects.

30. Some Last Thoughts = Application • Persistence Framework – could be used to create persistence services (persistence subsystem). • Considering a small persistence framework (a full-blown one is quite large and way beyond what we can do here or what was in [2]) • The framework should provide functions as: • Store and retrieve objects in a persistent storage mechanism (we have seen this…) • Commit and rollback transactions and many more… • Design must be extendable to support different storage mechanisms & formats such as RDBMSs, records in flat files, or XML in files • Full treatment of the development of this small framework is found in [2] pp. 540-564, but…

31. Still a huge undertaking. • Many points only glossed over [2] even after 24 pages of text… • Dematerializating objects • Materialization and dematerialization of collections • Queries for groups of objects • Thorough transaction handling • Error handling when a database operation fails • Multiuser access and locking strategies • Security – controlling access to the database

32. Solution: Persistency Subsystem (service) from a Persistence Framework. • So, a ‘persistency framework’ must be a general-purpose, reusable, and extendable set of types that provides functionality to support persistent objects. (note application area…) • The persistence service (or subsystem) actually provides the services and this will be created with a persistence framework. • In our context, our persistence service may also be called an O-R mapping service. (normally found in a technical services layer….)