Forte Seminar, April 1997 1
Reusable Components Ready for Distribution
Patrick Steyaert
Programming Technology Lab
Vrije Universiteit BrusselE-mail: [email protected]
WWW: http://progwww.vub.ac.be/prog/pools/rcs/
Forte Seminar, April 1997 2
Typical Case
Groupware broadcast planning application developed and commercialized by spin-off
Original application developed for Flemish broadcast company
Designed and implemented by a small team (< 7) with early OOA/OOD methods
Implemented in a “pure” OO language 2-tiered client/server architecture
Forte Seminar, April 1997 3
Broadcast Planning — Workflow
- 6 months
- 1 day
Broadcast day
Tape External Applications
AccountingAirtime sales
...
Planning
+ 1 dayConsistency checking
Contract & Program
Forte Seminar, April 1997 4
Product Evolution
originalcustom
application
Danish Television Station
Belgian Television Station
...
Off-the-shelf solutions don’t work Substantial similarities between the planning process of
broadcast companies
Observation
Forte Seminar, April 1997 5
Product Goal
Offer a broadcast planning solution that is highly, and efficiently customizable to the needs of different customers. The solution must give the customer the feeling of a custom-built system with the qualities of a standard product.
It should contain no needless features, must be adapted to the customer’s work process, and must be integrated with existing hardware and software.
Moreover it should offer the stability and the possibility for future upgrades that is typically associated with off-the-shelf products
Forte Seminar, April 1997 6
Framework Approach
Off-the-shelf Framework-based Project-based
Consolidate the domain knowledge acquired during previous projects in a framework so that it can be reused in future projects as to realize the product goal. The framework thus constitutes an ever-evolving representation, in terms of variations and commonalities, of our knowledge of the domain at a certain point in time.
Forte Seminar, April 1997 7
Challenges
Definition of reusable architecture» integration with existing infrastructure» WEB awareness» migration to an open distributed architecture (CORBA)
Definition of domain model» separating site-specific code from general concepts
Maintaining the architecture» reuse documentation» architectural drift» change management
Forte Seminar, April 1997 8
Firstname
Lastname
Age
Person Editor
Person
Person
Reusable Objects/Components
Forte Seminar, April 1997 9
Firstname
Lastname
Age
Person Editor
Person
Person
Application Layer
Application Layer
Domain Layer
Domain Layer
Persistency Layer
Persistency Layer
Separation of Concerns
Forte Seminar, April 1997 10
Application LayerApplication Layer
Domain LayerDomain Layer
Persistency LayerPersistency Layer
Drawing Editor Firstname
Lastname
Age
Person Editor
License
Brand
Age
Car Editor
Person
CarDrawing
Layered Architecture
Forte Seminar, April 1997 11
Application LayerApplication Layer
Domain LayerDomain Layer
Persistency LayerPersistency Layer
DBDB
Application LayerApplication Layer
Domain LayerDomain Layer
Persistency LayerPersistency Layer
Application LayerApplication Layer
Domain LayerDomain Layer
Persistency LayerPersistency Layer
Client / Server
Middleware
Forte Seminar, April 1997 12
DBDB
Application LayerApplication Layer
Domain LayerDomain Layer
Persistency LayerPersistency Layer
Application LayerApplication Layer
Application LayerApplication Layer
Thin Client / Fat Server
CORBA
Forte Seminar, April 1997 13
DBDB
Application LayerApplication Layer
Domain LayerDomain Layer
Persistency LayerPersistency Layer Application LayerApplication Layer
Application LayerApplication Layer
Web ServerWeb Server
NetscapeNetscape ExplorerExplorer
Client / Server & Internet / Intranet
HTTP
CORBA
Forte Seminar, April 1997 14
DBDB
Application LayerApplication Layer
Domain LayerDomain Layer
Persistency LayerPersistency Layer Application LayerApplication Layer
Application LayerApplication Layer
ApplicationApplication
ApplicationApplication
Client / Server & Legacy
LegacyLegacy
Forte Seminar, April 1997 15
The Original Persistency Layer
Allow non DB experts to work on the application Migration to other DB's Be ready for OO databases
Domain Model
Persistency Layer
Store
Retrieve
HematomasHematomas
Forte Seminar, April 1997 16
bcPIDProgramID contractPID
Example
Program
contractPeriodbroadcastPeriod
Period
from: 01/01/96, 00h00 to: 01/02/96, 00h00
from: 07/01/96, 20h00 to: 07/01/96, 22h00
Period
ProgramTable:
PeriodTable: PeriodID fromDate fromHour toDate toHour
foreign key
Forte Seminar, April 1997 17
Software Patterns
Design patterns capture successful solutions to recurring problems that arise during software construction
Handbooks of successfull designs:» OOD patterns, CORBA patterns, distributed and
concurrent programming patterns, analysis paterns, organizational patterns, ....
Design patterns help to improve key software quality factors and support reuse of software architectures
Forte Seminar, April 1997 18
A Design Pattern
Describes a recurring design structure» Used twice rule» Names, abstracts from concrete designs» Identifies classes, collaborations, responsibilities» Applicability, trade-offs, consequences,
implementation issues
Is discovered, not invented Facilitates communication, focussing on the
software architecture
Forte Seminar, April 1997 19
Solution: Bridge Pattern
Well known design pattern, documented in the most popular design pattern book [Gamma&al. 96]
Intent: Decouple an abstraction from its implementation so that the two can vary independently
Motivation: Window Implementations
Forte Seminar, April 1997 20
Bridge: Motivation
Window
DrawText()DrawRect
WindowImp
DrawText()DrawRect
TransientWindow
DrawCloseBox
IconWindow
DrawBorder()
Window95Imp
DrawText()DrawRect
XWindowImp
DrawText()DrawRect
Imp
Forte Seminar, April 1997 21
Bridge: Applicability
Use the Bridge Pattern to» Avoid a permanent binding between an
abstraction and its implementation» Both the abstractions and their implementations
should be extensible by subclassing» To avoid proliferation of classes
Separation of Concerns
Forte Seminar, April 1997 22
Bridge: Structure
Abstraction
Operation()
Implementor
OperationImp()imp
RefinedAbstraction
ConcreteImpB
OperationImp()
ConcreteImpA
OperationImp()
Client
Bridge Participants
Forte Seminar, April 1997 23
Bridge: Consequences
Decoupling interface and implementation Improved extensibility Hiding implementation details from clients
Forte Seminar, April 1997 24
Our Bridge Architecture
A
B
C+D
Conceptual ObjectContains business rules
Implementation ObjectKnows how to map itself to a relational database
Implementation ObjectKnows how to map itself to a relational database
Forte Seminar, April 1997 25
Example
Program
broadcastPeriodcontractPeriod
Period
from: 01/01/96, 00h00 to: 01/02/96, 00h00
from: 07/01/96, 20h00 to: 07/01/96, 22h00
Period
ProgramTable
bcFromDatebcFromTimebcToDatebcToTimecntrFromDatecntrFromTime...
bcFromDatebcFromTimebcToDatebcToTimecntrFromDatecntrFromTimecntrToDatecntrToTime
ProgramStorage
Conceptual Objects Implementation Objects
BCPeriodStorage
Database
Forte Seminar, April 1997 26
2nd Example: Observer
Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
15,20,40
Motivation: Maintain consistency between objects without a tight coupling that reduces reusability.
Forte Seminar, April 1997 27
Observer : Applicability
Use Observer when» an abstraction has two aspects, one dependent on the
other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.
» a change to one object requires changing others, and you don’t know how many objects need to be changed
» an object should be able to notify other objects without making assumptions about who these objects are.
Separation of Concerns
Forte Seminar, April 1997 28
Observer : Structure
Subject
attach(Observer)dettach(Observer)Notify()
Observer
update()
ConcreteObserverobserverState
update()
state
ConcreteSubjectsubjectState
getState()setState()
forall o in observers o update
return subjectStateobserverState= subject subjectState
Observer Participants
Forte Seminar, April 1997 29
Observer : Consequences
abstract coupling between subject and observer
support for broadcast communication unexpected updates
Forte Seminar, April 1997 30
Notational Problems
Subject
attach(Observer)dettach(Observer)Notify()
Observer
update()
ConcreteObserverobserverState
update()
state
ConcreteSubjectsubjectState
getState()setState()
forall o in observers o update
return subjectStateobserverState= subject subjectState
Forte Seminar, April 1997 31
Solution: Reuse Contracts
Subject
attach(Observer)dettach(Observer)notify()getState()setState() [notify]
Observer
update()
ConcreteObserver
update()ConcreteSubjectsubjectState
getState()setState() [notify]
notify [update]
subjectupdate [getState]
concretisationupdateconcretisation
getState, setState
implementation must invoke
update
ConcreteSubject must make
Subject concrete
Forte Seminar, April 1997 32
Checking Architectural Drift
Subject
attach(Observer)dettach(Observer)notify()getState()setState() [notify]
Observer
update()
ConcreteObserver
update() [draw]ConcreteSubjectsubjectState
getState()setState() [-notify]
notify [update]
subjectupdate [getState]
refinementupdate [+draw]coarsening
setState [-notify]
Conflict !!!
Forte Seminar, April 1997 33
Reuse Contract Notation
Componentreuser
Componentprovider
Reuse contract between provider and reuser» declares how a component can be reused and is reused» emphasis on interaction between components» formal rules for change propagation
Subject
attach(Observer)dettach(Observer)notify()getState()setState() [notify]
coarseningsetState [-notify]
Forte Seminar, April 1997 34
There is More than Choosing an Object-Oriented Programming Language
Methodology» setting up architectures
Technology, tools and notations Process Model
» Planning for reuse
Migration and integration issues» Legacy Systems
Training