1. Object-Oriented Frameworks n Framework: architecture + implementation + hooks. n The framework serves as the basis for many applications. Developers fill in the hooks to produce a new app. Framework Hooks Framework New Applications

2. Types of Frameworks n Application frameworks - large frameworks applicable across domains that provide a wide range of services to a wide range of applications. MFC. n Domain frameworks - apply to a single domain, tend to be smaller. SEAF. n Support frameworks - provide a small set of underlying services which can apply across domains. CSF.

3. Types (2) n Black Box frameworks - applications are built by plugging in components or configuring options. Easier to use, but less flexible. n White Box frameworks - applications subclass or modify existing classes. Developers need more understanding of the workings of the frameworks. More flexible, but more time to learn. n Fundamental issue of ease of use vs. flexibility.

4. Desirable Properties n Ease of use: easy to understand and facilitate the development of applications. n Extensible: new components or properties can be easily added. n Flexible: can be used for a wide variety of applications. n Complete: coverage of the domain.

5. Parts of a Framework Framework Core Framework Library Unused Library Classes Application Extensions FrameworkApplication

6. CSF Overview n Java program that handles communication between client server or peer to peer programs over a network. n Has some persistent storage capabilities. n Not a full architecture. CommunicationPersistence

7. Communication Architecture Message Handler CommAware Object Message Data MailBox MailServer Client Server

8. Communication n Objects send messages through mail servers. Developers defined the client and server objects. Client Object Server Object Outbox Inbox Mail Server Mail Server Inbox

9. Communication (2) n Data objects are transmitted inside the messages. Serialized on one side and rebuilt on the other, so any type of information can be sent. n By default, the client and server objects invoke message handlers every time a message arrives (just like responding to a menu click). Server Object Inbox Mail Server Message Data Message Handler

10. Modified Three Tier Arch. User Interface Manager Workflow Manager Business Rules Manager Persistent Object Manager Database Client Server Database Communication Persistence

11. Persistence Overview n Any data object can be made a persistent data object. n The Persistence Manager tracks all persistent data in memory and manages how it is stored to disk. Persistent Data Persistence Manager File Handler File Handler File Handler File structure

12. Documentation n The purpose of the framework: a description of the domain plus the limitations of the framework. (General description) n The use of the framework: a description of the way the framework is intended to be used. (Use cases, hooks, examples) n The design of the framework: A description of the structure and behavior of the framework. (Design description, source code) Should source code be provided?

13. Framework Use n A framework is chosen to generally match the application requirements. n Framework users must learn the framework before they can develop an application from it. n The application design has to conform to the concepts provided by the framework. Users build extensions to the framework. n Multiple frameworks can be used in a single application, but there may be gaps or overlap in the functionality they provide.

14. Sample Application: CSFTalk n Simple text based communication between two or more users. n A user may have several talk sessions open at the same time. n A central location keeps track of who’s connected and available for chat, what chat sessions have been created and who belongs to them.

15. Using CSF n Decide what information needs to be communicated across the network - these become data objects. –Strings of text (messages between users) –lists of who’s connected –login information n Decide what information needs to be stored - use persistent data objects. –Conversation log

16. Using CSF (2) n Specify the protocol for sending that information - produce message types for these. –Connect to server, connected –Disconnect from server –Start chat session –Join chat session –End chat session –Request who’s connected, received connected list –Send text message, receive text message

17. Using CSF (3) n Decide who will send and receive the messages - these become CommAwareObjects. –Client –Server –Chat Session –Talk Session n Decide on the type of communication and give them mailboxes. Client Controller Server Controller Chat Sessions Talk Sessions InboxOutbox CommAware Object

18. Using CSF (4) n Match the CAOs to the actual messages they receive and produce MessageHandlers for them. These can be distinct classes, or methods of a class. –Client: connected, receive connected list –Server: connect to server, disconnect, start chat session, request connected list –Talk session: receive text message, end chat session –Chat session: send text message, end chat session, join chat session

19. Message Handlers Server Connect Disconnect Start Chat Session CommAware Object Message Handler

20. Using CSF (5) n Decide on how the programs should be connected (maintained connection vs. connectionless, standard application vs. applet) and choose the appropriate MailServer. –Talk is an application that uses the standard connectionless mailserver. n The choice of MailServer does not affect the other parts of the framework.

21. Using CSF (6) n For any persistent data a manager must be created to save and load that data. –Log file requires a log file manager. Log Persistence Manager Log File Manager Persistent Data

22. Hot Spots and Hooks n How do you learn how to build these classes and connect them together? n Frozen Spots: capture the commonalties across applications. n Hot Spots: general areas of variability within a framework. n Hooks: specific ways in which a framework can be customized.

23. Communication Design Message Handler CommAware Object Message Data Proxy Address MailBox MailServer Inbox Outbox Syncsend Data Master Hot Spots Frozen Spots

24. Hooks n How can I extend the framework to fulfill some requirement? –Match a requirement with one or more extensions. –Mark the places at which extensions can be made in a framework. –Show how those extensions can be made.

25. Communication Hooks Message Handler CommAware Object Message Data Address MailBox MailServer Inbox Outbox Syncsend New CAO New MH Create Inbox Create Outbox Choose Mailserver Send MessageNew Data

26. Types of Hooks n The type of hooks shows in general how much understanding of the framework is needed to make the change. –Option: black box changes, plug in modules, just select a pre-made component and connect it (swap mail servers). –Pattern: scripted set of changes which limits the parts of the framework affected (create and connect mailboxes. –Open: guidelines for making a change, constraints to consider, but mostly left open to the developer (add new types of mail servers, modify the connection protocol).

27. Types of Hooks (2) n Enable - turn on functionality. (making the connections necessary to send messages) n Disable - turn off functionality. n Replace - replace parts of the framework with custom parts in a well-defined way. (changing message dispatch) n Augment - insert new steps into existing functionality. n Add - add new parts or capabilities. (new data, new methods in CommAwareObjects)

28. Hook Description n Name - identifies the hook. n Requirement - a short description of the problem the hook is intended for. n Type - method and level of support for the change. n Area - subsystem or component the hook involves. n Participants - classes that are used by the hook. n Uses - other hooks used by this hook.

29. Hook Description (2) n Preconditions - conditions that need to be satisfied before using the hook. (Class exists, methods implemented, options chosen) n Changes - the actual set of steps for using the hook. n Postconditions - conditions that should be satisfied when the changes have been applied. n Comments - any additional notes about the hook.

30. Using Hooks for CSFTalk n The main client and each talk session on a client become New CommAwareObjects, so they can pass messages across the network. n The Create Outbox and Create Inbox hooks are used for each CAO. n A New Data class TextString is created to encapsulate the text being sent between each member of the chat session. n The Send Message hook shows how to actually send text messages to members of a chat session.

31. Example: NewCAO n Requirement: An class needs to communicate across the network. n Participants: NewCAO, CommAwareObject n Uses: Handle Message n Changes: –new subclass NewCAO of CommAwareObject –NewCAO.init extends CommAwareObject.init –repeat as necessary »fill in messagetype »Handle Message[NewCAO = NewCAO, message=messagetype] Client init CommAwareObject init

32. Handle Message n Requirement: When an object receives a message it needs to respond to it in some way. n Participants: NewCAO, message, MessageHandle, NewMH n Preconditions: –NewCAO subclass of CommAwareObject –operation NewCAO.init n Changes –new subclass NewMH of MessageHandler –NewMH.handlemsg extends MessageHandler.handlemsg –NewCAO.init -> NewCAO.registerHandler(message, NewMH)

33. Outcome Client init CommAwareObject init MessageHandler handleMsg Disconnect handleMsg ChatRequest handleMsg

34. CSFTalk Diagram ClientServer Chat Sessions Talk Sessions Talk Windows Main Window Client List TextString From the framework Client List Proxy TextString

35. Multiple Frameworks n Framework gap: Since talk windows have to derive from a UI class, they cannot also derive from CommAwareObject. Therefore, they can’t send or receive messages. There’s a gap. –Solution: Create classes to bridge the gap. In this case, TalkSession, derived from CAO, interacts with TalkWindow. n Framework overlap: Overlaps in functionality between two frameworks require removing or not using part of one of the frameworks.

36. Framework Design n Frameworks differ from applications –the level of abstraction is different as frameworks provide a solution for a family of related problems, rather than a single one. –to accommodate the family of problems, the framework is incomplete, incorporating hot spots and hooks to allow customization n Frameworks must be designed for flexibility, extensibility, completeness and ease of use.

37. Frameworks Design (2) n Small teams or individual developers recommended. n Build small flexible frameworks. n Frameworks should be developed from ‘scratch.’ n Hooks should be considered throughout the design process.

38. Iterative Approach n Determine the scope of the framework. n Identify key abstractions. n Identify hot spots. n Design and implement. n Test. n Refine the framework.

39. Key Abstractions n To find: –examine existing applications, or even build an application to gain expertise –develop scenarios n Abstractions –network communication –how data is represented –means of handling that data

40. Hot Spots n Examining existing applications will show which aspects change from application to application and which remain constant. n Hot Spots –clients and servers vary –the data sent varies –means of handling that data varies

41. Design and Implementation n Abstractions can be difficult to design properly. n Specific hooks for each hot spot can be designed. n There are trade-offs between ease of use and flexibility.

42. Designing CSF n Abstractions –network communication - mailboxes with addresses transmit messages through mailservers –data - Data class that can contain any kind of information –handling messages - MessageHandlers are automatically invoked whenever a message is received. (However, for flexibility, the mechanism can be overriden).

43. Designing CSF (2) n Hot Spots –clients and servers vary - New CommAwareObject Hook –data sent varies - New Data Hook –means of handling the data varies - New MessageHandler Hook

44. Design Tips reduce the number of classes and methods users have to override simplify the interaction between the framework and the application extensions isolate platform dependent code do as much as possible within the framework factor code so that users can override limiting assumptions provide notification hooks so that users can react to important state changes consolidate similar functionality into a single abstraction break down larger abstractions into smaller ones with greater flexibility implement each key variation of an abstraction as a class use composition rather than inheritance

45. Testing n Any defects in the framework will be passed on to all applications. n Two types of testing: –A framework can be tested in isolation with default implementations (standard testing). –A framework should be used to develop an actual application. n Rule of thumb: three applications should be built before distribution.

46. Framework Evolution n Framework evolution might be categorized as anything beyond use as-is and completion. n Refactorings can be used to restructure the framework while preserving its behavior. n Design patterns can be applied to make the framework more flexible. n What happens to applications when frameworks evolve?