1. Forte Seminar, April 1997 1 Reusable Components Ready for Distribution Patrick Steyaert Programming Technology Lab Vrije Universiteit Brussel E-mail: prsteyae@vnet3.vub.ac.be WWW: http://progwww.vub.ac.be/prog/pools/rcs/

2. Forte Seminar, April 1997 2 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

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

4. Forte Seminar, April 1997 4 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

5. Forte Seminar, April 1997 5 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

6. Forte Seminar, April 1997 6 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.

7. Forte Seminar, April 1997 7 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

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

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

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

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

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

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

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

15. Forte Seminar, April 1997 15 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

16. Forte Seminar, April 1997 16 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

17. Forte Seminar, April 1997 17 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

18. Forte Seminar, April 1997 18 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

19. Forte Seminar, April 1997 19 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

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

21. Forte Seminar, April 1997 21 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

22. Forte Seminar, April 1997 22 Bridge: Structure Abstraction Operation() Implementor OperationImp() imp RefinedAbstraction ConcreteImpB OperationImp() ConcreteImpA OperationImp() Client Bridge Participants

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

24. Forte Seminar, April 1997 24 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

25. Forte Seminar, April 1997 25 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

26. Forte Seminar, April 1997 26 2nd 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.

27. Forte Seminar, April 1997 27 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

28. Forte Seminar, April 1997 28 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

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

30. Forte Seminar, April 1997 30 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

31. Forte Seminar, April 1997 31 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

32. Forte Seminar, April 1997 32 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 !!!

33. Forte Seminar, April 1997 33 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]

34. Forte Seminar, April 1997 34 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