PSI From Custom Developed Application to DomainSpecific Framework

PSI: From Custom Developed Application to Domain-Specific Framework Wim Codenie, Wilfried Verachtert, Arlette Vercammen OO Partners Otto de Mentockplein 19 1853 Strombeek-Bever, Belgium tel: 0032 -(0)2 -2630400 fax: 0032 -(0)2 -2677151 Email: wim@oopartners. com, wilfried@oopartners. com, arlette@oopartners. com 1

Content 3 Description of the original PSI application 3 Motivation for the PSI framework 3 Impact of the framework approach 3 Summary/Conclusions 2

The Original PSI Application 3 Original application developed for VTM (Flemish broadcast company) 3 Groupware application for television broadcast companies 3 Implemented in Visual. Works/Smalltalk 3 Designed and implemented by a small team (< 7) 3

PSI Workflow Planning Contract & Program - 6 months External Applications Tape Accounting Airtime sales. . . - 1 day Broadcast day + 1 day Consistency checking 4

PSI Distributed Architecture 2 -tiered client/server architecture Client Application Domain Model Persistency Layer Server Database Middleware Client Application Domain Model Persistency Layer 5

Evolution of PSI Danish Television Station (TV 2) VTM . . . Need for a PSI framework ! Belgian Television Station (RTBF) 6

PSI-framework 3 Objectives • Standard product – Easy customisable, adaptable, maintainable • by a small team • by domain experts – Open Architecture • Multi-database, Multi-platform • Integration with existing hard & software 7

PSI in Numbers 3 VTM: 2000 person days 3 TV 2: 200 person days (minor customisation) 3 Extra functionality: 650 person days 3 Framework development: 700 person days 3 RTBF: 100 person days (customisation of the framework) 3 Estimate for the next project: 80 person days 3 Goal for the future: 50 person days 8

Technical Issues. . . 3 Separating site-specific code from general concepts • Abstraction and refactoring techniques • Defining hooks to future installations • Factories (PSI Site), Super Switch 3 Better separation of persistency layer from domain model • Bridge architecture 3 Future • Migration to a more open distributed architecture (CORBA) • Better separation of UI from domain model 9

Abstraction & Refactoring (1) Class (or static) method to generate tape numbers Tape tape. Number: String. . . generate. Tape. Nr(). . . Star Trek tape. Number ‘V 543213 ABC’ . . . 10

Abstraction & Refactoring (2) Tape. Library tapes Tape number Tape. Number . . . generate. Tape. Nr(). . . Library 1 tapes Star Trek 1 number ‘V 543213’ number ‘V 544513’ Star Trek 3 number ‘V 523513’ Star Trek 2 11

Abstraction & Refactoring (3) tapes Tape. Library. . . generator Tape number Tape. Number. Generator generate. Tape. Nr(). . . Site 2 Site 1 Library 1 Generator 1 Library 2 Generator 2 12

PSI Site Transmission Program Before Transmission Site 1 Trans Site 2 Trans Site 1 Program Site 2 Program PSI Site Program. Class Trans. Class Serie Site 1 Serie Site 2 Serie self psi. Site new. Serie 13

The Original Persistency Layer 3 Be ready for OO databases 3 Allow non DB experts to work on the application 3 Migration to other DB's Domain Model Hematomas Store Persistency Layer Retrieve 14

Example Period Program from: 01/01/96, 00 h 00 to: 01/02/96, 00 h 00 contract. Period broadcast. Period from: 07/01/96, 20 h 00 to: 07/01/96, 22 h 00 Program. Table: Program. ID bc. PID contract. PID foreign key Period. Table: Period. ID from. Date from. Hour to. Date to. Hour 15

The Bridge Architecture C+D B Conceptual Object Contains business rules A Implementation Object Knows how to map itself to a relational database 16

Example Conceptual Objects Period Implementation Objects Database BCPeriod. Storage from: 01/01/96, 00 h 00 to: 01/02/96, 00 h 00 Program broadcast. Period contract. Period from: 07/01/96, 20 h 00 to: 07/01/96, 22 h 00 Program. Storage Program. Table bc. From. Date bc. From. Time bc. To. Date bc. To. Time cntr. From. Date cntr. From. Time cntr. To. Date cntr. To. Time bc. From. Date bc. From. Time bc. To. Date bc. To. Time cntr. From. Date cntr. From. Time. . . 17

Impact on Development Process 3 Iterative approach • No large upfront investments ! • Change propagations 3 “Analysis of Changes” instead of “Analysis from Scratch” • Use product as advanced prototype • Reuse documentation (cookbooks) 3 Impact on team structure • Different roles 18

Conclusions 3 Framework development process • Separation of concepts • Abstraction & Factorisation • Iteration 3 Needs our attention • Proliferation of versions • Change analysis, effort estimation 3 Competitive Advantage 19