Forte Seminar, April 1997 1 Reusable Components Ready for Distribution Patrick Steyaert Programming Technology Lab Vrije Universiteit Brussel E-mail: [email protected]

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/


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


Broadcast Planning — Workflow

- 6 months

- 1 day

Broadcast day

Tape External Applications

AccountingAirtime sales

...

Planning

+ 1 dayConsistency checking

Contract & Program


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


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


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.


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


Firstname

Lastname

Age

Person Editor

Person

Person

Reusable Objects/Components


Firstname

Lastname

Age

Person Editor

Person

Person

Application Layer

Application Layer

Domain Layer

Domain Layer

Persistency Layer

Persistency Layer

Separation of Concerns


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





DBDB







Client / Server

Middleware


DBDB






Thin Client / Fat Server

CORBA


DBDB



Persistency LayerPersistency Layer Application LayerApplication Layer


Web ServerWeb Server

NetscapeNetscape ExplorerExplorer

Client / Server & Internet / Intranet

HTTP

CORBA


DBDB



Persistency LayerPersistency Layer Application LayerApplication Layer


ApplicationApplication

ApplicationApplication

Client / Server & Legacy

LegacyLegacy


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


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


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


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


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


Bridge: Motivation

Window

DrawText()DrawRect

WindowImp

DrawText()DrawRect

TransientWindow

DrawCloseBox

IconWindow

DrawBorder()

Window95Imp

DrawText()DrawRect

XWindowImp

DrawText()DrawRect

Imp


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



Bridge: Structure

Abstraction

Operation()

Implementor

OperationImp()imp

RefinedAbstraction

ConcreteImpB

OperationImp()

ConcreteImpA

OperationImp()

Client

Bridge Participants


Bridge: Consequences

Decoupling interface and implementation Improved extensibility Hiding implementation details from clients


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


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


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.


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.



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


Observer : Consequences

abstract coupling between subject and observer

support for broadcast communication unexpected updates


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


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


Checking Architectural Drift

Subject


Observer

update()

ConcreteObserver

update() [draw]ConcreteSubjectsubjectState

getState()setState() [-notify]

notify [update]

subjectupdate [getState]

refinementupdate [+draw]coarsening

setState [-notify]

Conflict !!!


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


coarseningsetState [-notify]


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

Documents

Forte Seminar, April 1997 1 Reusable Components Ready for Distribution Patrick Steyaert Programming Technology Lab Vrije Universiteit Brussel E-mail: [email protected]