Forte Seminar, April Reusable Components Ready for Distribution Patrick Steyaert Programming Technology Lab Vrije Universiteit Brussel WWW:

Forte Seminar, April Typical Case 4Groupware broadcast planning application developed and commercialized by spin-off 4Original application developed for Flemish broadcast company 4Designed and implemented by a small team (< 7) with early OOA/OOD methods 4Implemented in a “pure” OO language 42-tiered client/server architecture

Forte Seminar, April Broadcast Planning — Workflow - 6 months - 1 day Broadcast day Tape External Applications Accounting Airtime sales... Planning + 1 day Consistency checking Contract & Program

Forte Seminar, April Product Evolution original custom application Danish Television Station Belgian Television Station... 3Off-the-shelf solutions don’t work 3Substantial similarities between the planning process of broadcast companies Observation

Forte Seminar, April Product Goal 3Offer 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. 3It should contain no needless features, must be adapted to the customer’s work process, and must be integrated with existing hardware and software. 3Moreover it should offer the stability and the possibility for future upgrades that is typically associated with off-the- shelf products

Forte Seminar, April Framework Approach Off-the-shelfFramework-basedProject-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 Challenges 4Definition of reusable architecture »integration with existing infrastructure »WEB awareness »migration to an open distributed architecture (CORBA) 4Definition of domain model »separating site-specific code from general concepts 4Maintaining the architecture »reuse documentation »architectural drift »change management

Forte Seminar, April Firstname Lastname Age Person Editor Person Reusable Objects/Components

Forte Seminar, April Firstname Lastname Age Person Editor Person Separation of Concerns

Forte Seminar, April Drawing Editor Firstname Lastname Age Person Editor License Brand Age Car Editor Person Car Drawing Layered Architecture

Forte Seminar, April Application Layer Domain Layer Persistency Layer DB Application Layer Domain Layer Persistency Layer Application Layer Domain Layer Persistency Layer Client / Server Middleware

Forte Seminar, April DB Application Layer Domain Layer Persistency Layer Application Layer Thin Client / Fat Server CORBA

Forte Seminar, April DB Application Layer Domain Layer Persistency Layer Application Layer Web Server Netscape Explorer Client / Server & Internet / Intranet HTTP CORBA

Forte Seminar, April DB Application Layer Domain Layer Persistency Layer Application Layer Application Application Client / Server & Legacy Legacy

Forte Seminar, April The Original Persistency Layer 4Allow non DB experts to work on the application 4Migration to other DB's 4Be ready for OO databases Domain Model Persistency Layer Store Retrieve Hematomas

Forte Seminar, April bcPIDProgramIDcontractPID Example Program contractPeriod broadcastPeriod Period from: 01/01/96, 00h00 to: 01/02/96, 00h00 from: 07/01/96, 20h00 to: 07/01/96, 22h00 Period ProgramTable: PeriodTable: PeriodIDfromDatefromHourtoDatetoHour foreign key

Forte Seminar, April Software Patterns 4Design patterns capture successful solutions to recurring problems that arise during software construction 4Handbooks of successfull designs: »OOD patterns, CORBA patterns, distributed and concurrent programming patterns, analysis paterns, organizational patterns,.... 4Design patterns help to improve key software quality factors and support reuse of software architectures

Forte Seminar, April A Design Pattern 4Describes a recurring design structure »Used twice rule »Names, abstracts from concrete designs »Identifies classes, collaborations, responsibilities »Applicability, trade-offs, consequences, implementation issues 4Is discovered, not invented 4Facilitates communication, focussing on the software architecture

Forte Seminar, April Solution: Bridge Pattern 4Well known design pattern, documented in the most popular design pattern book [Gamma&al. 96] 4Intent: Decouple an abstraction from its implementation so that the two can vary independently 4Motivation: Window Implementations

Forte Seminar, April Bridge: Motivation Window DrawText() DrawRect WindowImp DrawText() DrawRect TransientWindow DrawCloseBox IconWindow DrawBorder() Window95Imp DrawText() DrawRect XWindowImp DrawText() DrawRect Imp

Forte Seminar, April Bridge: Applicability 4Use 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 Bridge: Structure Abstraction Operation() Implementor OperationImp() imp RefinedAbstraction ConcreteImpB OperationImp() ConcreteImpA OperationImp() Client Bridge Participants

Forte Seminar, April Bridge: Consequences 4Decoupling interface and implementation 4Improved extensibility 4Hiding implementation details from clients

Forte Seminar, April Our Bridge Architecture A B C+D Conceptual Object Contains business rules Implementation Object Knows how to map itself to a relational database Implementation Object Knows how to map itself to a relational database

Forte Seminar, April Example Program broadcastPeriod contractPeriod Period from: 01/01/96, 00h00 to: 01/02/96, 00h00 from: 07/01/96, 20h00 to: 07/01/96, 22h00 Period ProgramTable bcFromDate bcFromTime bcToDate bcToTime cntrFromDate cntrFromTime... bcFromDate bcFromTime bcToDate bcToTime cntrFromDate cntrFromTime cntrToDate cntrToTime ProgramStorage Conceptual ObjectsImplementation Objects BCPeriodStorage Database

Forte Seminar, April nd Example: Observer 4Intent: 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 4Motivation: Maintain consistency between objects without a tight coupling that reduces reusability.

Forte Seminar, April Observer : Applicability 4Use 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 Observer : Structure Subject attach(Observer) dettach(Observer) Notify() Observer update() ConcreteObserver observerState update() state ConcreteSubject subjectState getState() setState() forall o in observers o update return subjectState observerState= subject subjectState Observer Participants

Forte Seminar, April Observer : Consequences 4abstract coupling between subject and observer 4support for broadcast communication 4unexpected updates

Forte Seminar, April Notational Problems Subject attach(Observer) dettach(Observer) Notify() Observer update() ConcreteObserver observerState update() state ConcreteSubject subjectState getState() setState() forall o in observers o update return subjectState observerState= subject subjectState

Forte Seminar, April Solution: Reuse Contracts Subject attach(Observer) dettach(Observer) notify() getState() setState() [notify] Observer update() ConcreteObserver update() ConcreteSubject subjectState getState() setState() [notify] notify [update] subject update [getState] concretisation 3update concretisation 3getState, setState implementation must invoke update ConcreteSubject must make Subject concrete

Forte Seminar, April Checking Architectural Drift Subject attach(Observer) dettach(Observer) notify() getState() setState() [notify] Observer update() ConcreteObserver update() [draw] ConcreteSubject subjectState getState() setState() [-notify] notify [update] subject update [getState] refinement 3update [+draw] coarsening 3setState [-notify] Conflict !!!

Forte Seminar, April Reuse Contract Notation Component reuser Component provider 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] coarsening 3setState [-notify]

Forte Seminar, April There is More than Choosing an Object- Oriented Programming Language 4Methodology »setting up architectures 4Technology, tools and notations 4Process Model »Planning for reuse 4Migration and integration issues »Legacy Systems 4Training