Transcript Object-Oriented Frameworks

Object-Oriented Frameworks


Framework: architecture
+ implementation +
hooks.
The framework serves as
the basis for many
applications. Developers
fill in the hooks to
produce a new app.
Framework
Hooks
Framework
New Applications
Types of Frameworks



Application frameworks - large frameworks
applicable across domains that provide a wide
range of services to a wide range of applications.
MFC.
Domain frameworks - apply to a single domain,
tend to be smaller. SEAF.
Support frameworks - provide a small set of
underlying services which can apply across
domains. CSF.
Types (2)

Black Box frameworks - applications are built by
plugging in components or configuring options.
Easier to use, but less flexible.

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.

Fundamental issue of ease of use vs. flexibility.
Desirable Properties




Ease of use: easy to understand and facilitate the
development of applications.
Extensible: new components or properties can be
easily added.
Flexible: can be used for a wide variety of
applications.
Complete: coverage of the domain.
Parts of a Framework
Unused
Library
Classes
Framework
Library
Framework
Core
Application Extensions
Framework
Application
CSF Overview

Java program that handles communication
between client server or peer to peer programs
over a network.

Has some persistent storage capabilities.
Not a full architecture.

Communication
Persistence
Communication Architecture
Client
CommAware
Object
Data
MailBox
Message
MailServer
Server
Message
Handler
Communication

Objects send messages through mail servers.
Developers defined the client and server objects.
Outbox
Client Object
Inbox
Client Object Inbox
Mail
Server
Mail
Server
Inbox Server Object
Communication (2)


Data objects are transmitted inside the messages.
Serialized on one side and rebuilt on the other, so
any type of information can be sent.
By default, the client and server objects invoke
message handlers every time a message arrives
(just like responding to a menu click).
Mail
Server
Message
Data
Inbox Server Object
Message
Handler
Modified Three Tier Arch.
Client
User Interface Manager
Communication
Workflow Manager
Server
Business Rules Manager
Persistent Object Manager
Database
Persistence
Database
Persistence Overview


Any data object can be made a persistent data
object.
The Persistence Manager tracks all persistent data
in memory and manages how it is stored to disk.
Persistence
Manager
Persistent
Data
File
Handler
File
Handler
File structure
File
Handler
Documentation



The purpose of the framework: a description of the
domain plus the limitations of the framework.
(General description)
The use of the framework: a description of the way
the framework is intended to be used. (Use cases,
hooks, examples)
The design of the framework: A description of the
structure and behavior of the framework. (Design
description, source code) Should source code be
provided?
Framework Use




A framework is chosen to generally match the
application requirements.
Framework users must learn the framework before
they can develop an application from it.
The application design has to conform to the
concepts provided by the framework. Users build
extensions to the framework.
Multiple frameworks can be used in a single
application, but there may be gaps or overlap in the
functionality they provide.
Sample Application: CSFTalk



Simple text based communication between two or
more users.
A user may have several talk sessions open at the
same time.
A central location keeps track of who’s connected
and available for chat, what chat sessions have
been created and who belongs to them.
Using CSF

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

Decide what information needs to be stored - use
persistent data objects.
– Conversation log
Using CSF (2)

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
Using CSF (3)

Decide who will send and
receive the messages - these
become CommAwareObjects.
–
–
–
–

Client
Server
Chat Session
Talk Session
Decide on the type of
communication and give
them mailboxes.
Inbox
Outbox
Client
Controller
Talk
Sessions
Server
Controller
Chat
Sessions
CommAware
Object
Using CSF (4)

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
Message Handlers
CommAware
Object
Message
Handler
Connect
Disconnect
Server
Start Chat
Session
Using CSF (5)

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.

The choice of MailServer does not affect the other
parts of the framework.
Using CSF (6)

For any persistent data a manager must be created
to save and load that data.
– Log file requires a log file manager.
Persistent
Data
Persistence
Manager
Log
Log File
Manager
Hot Spots and Hooks

How do you learn how to build these classes
and connect them together?

Frozen Spots: capture the commonalties
across applications.
Hot Spots: general areas of variability within
a framework.
Hooks: specific ways in which a framework
can be customized.


Communication Design
Message
Handler
Data
Master
Data
Proxy
CommAware
Object
Hot Spots
Data
Inbox
Message
Outbox
MailBox
Address
Syncsend
MailServer
Frozen
Spots
Hooks

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.
Communication Hooks
New CAO
Create Outbox
New MH
Message
Handler
Send Message
New Data
CommAware
Object
Create Inbox
Data
Inbox
Message
Outbox
MailBox
Address
Syncsend
Choose Mailserver
MailServer
Types of Hooks

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).
Types of Hooks (2)





Enable - turn on functionality. (making the
connections necessary to send messages)
Disable - turn off functionality.
Replace - replace parts of the framework with
custom parts in a well-defined way. (changing
message dispatch)
Augment - insert new steps into existing
functionality.
Add - add new parts or capabilities. (new data,
new methods in CommAwareObjects)
Hook Description






Name - identifies the hook.
Requirement - a short description of the problem
the hook is intended for.
Type - method and level of support for the change.
Area - subsystem or component the hook involves.
Participants - classes that are used by the hook.
Uses - other hooks used by this hook.
Hook Description (2)




Preconditions - conditions that need to be satisfied
before using the hook. (Class exists, methods
implemented, options chosen)
Changes - the actual set of steps for using the
hook.
Postconditions - conditions that should be satisfied
when the changes have been applied.
Comments - any additional notes about the hook.
Using Hooks for CSFTalk




The main client and each talk session on a client
become New CommAwareObjects, so they can pass
messages across the network.
The Create Outbox and Create Inbox hooks are
used for each CAO.
A New Data class TextString is created to
encapsulate the text being sent between each
member of the chat session.
The Send Message hook shows how to actually
send text messages to members of a chat session.
Example: NewCAO




Requirement: An class needs to
communicate across the network.
Participants: NewCAO, CommAwareObject
Uses: Handle Message
Changes:
– new subclass NewCAO of CommAwareObject
– NewCAO.init extends CommAwareObject.init
– repeat as necessary
» fill in messagetype
» Handle Message[NewCAO = NewCAO,
message=messagetype]
CommAwareObject
init
Client
init
Handle Message



Requirement: When an object receives a message it needs
to respond to it in some way.
Participants: NewCAO, message, MessageHandle,
NewMH
Preconditions:
– NewCAO subclass of CommAwareObject
– operation NewCAO.init

Changes
– new subclass NewMH of MessageHandler
– NewMH.handlemsg extends MessageHandler.handlemsg
– NewCAO.init -> NewCAO.registerHandler(message, NewMH)
Outcome
CommAwareObject
MessageHandler
init
handleMsg
ChatRequest
Client
init
Disconnect
handleMsg
handleMsg
CSFTalk Diagram
Main
Window
Client
List Proxy
From the framework
Client
List
Client
Server
Talk
Sessions
Chat
Sessions
Talk
Windows
TextString
TextString
Multiple Frameworks

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.

Framework overlap: Overlaps in functionality
between two frameworks require removing or not
using part of one of the frameworks.
Framework Design

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

Frameworks must be designed for flexibility,
extensibility, completeness and ease of use.
Frameworks Design (2)
Small teams or individual developers
recommended.
 Build small flexible frameworks.
 Frameworks should be developed from
‘scratch.’
 Hooks should be considered throughout the
design process.

Iterative Approach
Determine the scope of the framework.
 Identify key abstractions.
 Identify hot spots.
 Design and implement.
 Test.
 Refine the framework.

Key Abstractions

To find:
– examine existing applications, or even build an
application to gain expertise
– develop scenarios

Abstractions
– network communication
– how data is represented
– means of handling that data
Hot Spots
Examining existing applications will show
which aspects change from application to
application and which remain constant.
 Hot Spots

– clients and servers vary
– the data sent varies
– means of handling that data varies
Design and Implementation
Abstractions can be difficult to design
properly.
 Specific hooks for each hot spot can be
designed.
 There are trade-offs between ease of use
and flexibility.

Designing CSF

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).
Designing CSF (2)

Hot Spots
– clients and servers vary - New CommAwareObject
Hook
– data sent varies - New Data Hook
– means of handling the data varies - New
MessageHandler Hook
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
Testing
Any defects in the framework will be
passed on to all applications.
 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.

Rule of thumb: three applications should be
built before distribution.
Framework Evolution




Framework evolution might be categorized as
anything beyond use as-is and completion.
Refactorings can be used to restructure the
framework while preserving its behavior.
Design patterns can be applied to make the
framework more flexible.
What happens to applications when frameworks
evolve?