1. FDT Foil no 1 Overall Methodology – from Engineering RT Systems through TIMe; to RAM. Covering the full development cycle Supporting the whole company Covering the full development cycle Supporting the whole company

2. FDT Foil no 2 The systems engineering cycle/spiral Domain System descriptions Develop Install System Manufacture Domain descriptions Model has needs quality = satisfaction of needs

3. FDT Foil no 3 Objects and properties

4. FDT Foil no 4 Coverage of the ITU-T languages and UML

5. FDT Foil no 5 Macro Methodology

6. FDT Foil no 6 Develop system

7. FDT Foil no 7 RAM application functionality platform model Service ececution environment dynamic structure with dynamic discovery and composition r2 r3 r1 > collaborations with behaviourTypes with semantic interfaces r2 r3 r1 > collaborations with behaviourTypes with semantic interfaces framework functionality Implementation design; deployment realization ObjectsProperties

8. FDT Foil no 8 TIMe needs Market Problem domain Product family System instance needs Product needs Domain concepts, problems, ideas Instance needs User satisfaction Implementation instance system Domain model configuration Specification Application design Framework design Architecture design UML, MSC SDL, MSC, UML C++, Java,... UML,...

9. FDT Foil no 9 Model organization in TIMe objects properties context content component types (follow same pattern) design specification

10. FDT Foil no 10 Feature summary Supports design oriented development A step towards property oriented development Fully object oriented and model driven using UML and the ITU-T languages SDL and MSC Strategies and guidelines for how to make models Emphasis on flexibility, reuse and quality by construction Hypertext book available on CD-ROM Supports design oriented development A step towards property oriented development Fully object oriented and model driven using UML and the ITU-T languages SDL and MSC Strategies and guidelines for how to make models Emphasis on flexibility, reuse and quality by construction Hypertext book available on CD-ROM 5. Property oriented 3. Design oriented 1. Implementation oriented –Model driven Model driven

11. FDT Foil no 11 Model driven support for the whole company Product planning and marketing : a clear picture of the needs and a sound foundation for product planning precise communication with the market and development Development: better understanding of needs support to all development steps constructive approach to design service flexibility architectural flexibility Engineering, production, sales : efficient customer adaptation controlled maintenance Product planning and marketing : a clear picture of the needs and a sound foundation for product planning precise communication with the market and development Development: better understanding of needs support to all development steps constructive approach to design service flexibility architectural flexibility Engineering, production, sales : efficient customer adaptation controlled maintenance Domain domain Family imple- mentation specification design Instance instance system configuration

12. FDT Foil no 12 First: consider the Domain Consider the enterprise - to find the real needs (why) Identify: stake holders; helpers; services; subjects and transactions Consider the enterprise - to find the real needs (why) Identify: stake holders; helpers; services; subjects and transactions Object models Property models Dictionary Statement Domain descriptions An abstraction that helps to: understand the problem better communicate better plan better products facilitate reuse An abstraction that helps to: understand the problem better communicate better plan better products facilitate reuse

13. FDT Foil no 13 Make Domain object models zonedoor Passive objects group legal user member of has access to consist of 1..* 1 Authenticator Authorizer User Card Operator Door Active objects

14. FDT Foil no 14 Service User Access Make Domain property models User access: –A user enters his personal code, PIN –The authenticator checks the card id and the PIN –The authorizer checks the access right of the user –If OK the door is opened –If NOK no action MSC UserAccessGranted User AuthorizerAuthenticatorDoor Card id Enter PIN Givepin [PIN] Authorize[userid] Open_Lock Enter Authenticator Authorizer User Card Door User access roles

15. FDT Foil no 15 Model organization Object Models Type Service-A MSC Text Service-A Plays role of Property Models... Service-B MSC Text Service-B Plays role of r2 r3 r1 r2 r3 r1

16. FDT Foil no 16 Application System An abstraction where behaviour can be understood and analyzed. Where service oriented application development takes place. A firm foundation for designing an optimal implementation. An abstraction where behaviour can be understood and analyzed. Where service oriented application development takes place. A firm foundation for designing an optimal implementation. Interface given System given Domain given Users Other systems Controlled processes Known entities Environment System Service providing Service needing

17. FDT Foil no 17 System givenInterface givenDomain given Access Control System Identify Application objects User server Door server Operator server Authorizer Authenticator User Operator Door User panel Operator terminal Door controller

18. FDT Foil no 18 Identify Application aggregates User server Door server Operator server Authorizer Authenticator User panel Operator terminal User Operator Door controller Access Control System Validation AccessPoint OperationPoint

19. FDT Foil no 19 Define Application using SDL SYSTEM TYPE AccessControl ap(na): AccessPoint Op(no): Operation Point Validation USE AccessControlLib; usr val op db u o o a v v operator user

20. FDT Foil no 20 A block type

21. FDT Foil no 21 MSC Normal_Accepted ps_1 UserServer ds_1 Card UserCode Validate Accepted Accept Pass Admit Open DoorPassed Admitted Ready EnterCard msc Normal_Accepted

22. FDT Foil no 22 A process type 1(2)

23. FDT Foil no 23 A process type 2(2)

24. FDT Foil no 24 The User Server 1(2)

25. FDT Foil no 25 The User Server 2(2)

26. FDT Foil no 26 SDL uses Extended FSM (EFSM) A process is an EFSM having his own local (data) attributes and timers Processes interact by means of asynchronous "signals” (messages) Signals are queued (FIFO) in the input port until consumed by the FSM A process is an EFSM having his own local (data) attributes and timers Processes interact by means of asynchronous "signals” (messages) Signals are queued (FIFO) in the input port until consumed by the FSM input port FSM timer data output signalinput signal reveal/view save queue save timeout timer opdata op

27. FDT Foil no 27 Specification, design, verification and validation Specification Design Verify objects properties Validate Common representation Decompose Synthesize, verify

28. FDT Foil no 28 Compatibility and interface roles Interface roles are ”projected and distilled” behaviours visible on interfaces, or associations. Given two state machines A and B: 1.Derive the interface role behaviours ­Project: hide and transform ­Distill: gather, minimize and merge ­Detect inconsistencies 2.Correct inconsistencies and repeat from 1 3.Validate role compatibility Interface roles are ”projected and distilled” behaviours visible on interfaces, or associations. Given two state machines A and B: 1.Derive the interface role behaviours ­Project: hide and transform ­Distill: gather, minimize and merge ­Detect inconsistencies 2.Correct inconsistencies and repeat from 1 3.Validate role compatibility A B 1a 1b 1 3 1 2 2 session

29. FDT Foil no 29 Role behaviour and input consistent roles Deriving a role behaviour: Replace invisible inputs by “none” (or just make a mental note) Remove invisible outputs (or just ignore them) The result is a process graph with only visible inputs and outputs. (or just a mental view on the original graph) Input consistency: An invisible transition is a transition with a none input. An invisible transition is input consistent iff the next-state explicitly accepts all the visible inputs of the (present) state. The role is input consistent iff every invisible transition in the role is input consistent. Deriving a role behaviour: Replace invisible inputs by “none” (or just make a mental note) Remove invisible outputs (or just ignore them) The result is a process graph with only visible inputs and outputs. (or just a mental view on the original graph) Input consistency: An invisible transition is a transition with a none input. An invisible transition is input consistent iff the next-state explicitly accepts all the visible inputs of the (present) state. The role is input consistent iff every invisible transition in the role is input consistent. 1 none Sb 3 Gb 5 none Qb 1 Sa Ga 8 Qa 1 A invisible transitions 1 and 3 are not input consistent because 3 does not accept Sa 5 and 1 are input consistent because 1 accepts more than 5

30. FDT Foil no 30 Dual roles are fully compatible a-roles: 1.iff the original state machine is consistent, then the dual a-role may be constructed, 2.and used to discover, compare and select compatible services, 3.and to partially synthesise state machines. 1.iff the original state machine is consistent, then the dual a-role may be constructed, 2.and used to discover, compare and select compatible services, 3.and to partially synthesise state machines. A 1a 1b 2 session B 1c C 1d 1 2 D 1b 2b 3b 1 1 1 3 3 3

31. FDT Foil no 31 Deployment/Architecture An abstraction of the concrete system: hardware software non-functional properties showing the mapping from Application and Framework to implementation needed to design and document real systems expressed using UML or SOON made once for a Family An abstraction of the concrete system: hardware software non-functional properties showing the mapping from Application and Framework to implementation needed to design and document real systems expressed using UML or SOON made once for a Family Application + Infrastructure Support SW HW Support SW HW Application + Infrastructure

32. FDT Foil no 32 HS diagram

33. FDT Foil no 33 Framework An abstraction reflecting the architecture, showing distribution and error handling, describing the infrastructure. Needed for complete documentation, analysis and simulation of behavior. Expressed in SDL, is source for complete code generation. Made once for a Family. An abstraction reflecting the architecture, showing distribution and error handling, describing the infrastructure. Needed for complete documentation, analysis and simulation of behavior. Expressed in SDL, is source for complete code generation. Made once for a Family. ISD Infrastructure ISD ISD Application

34. FDT Foil no 34 Application specific SDL specification Complete, implementation specific SDL description Two SDL models

35. FDT Foil no 35 Framework example 1 system type AccessControl CentralUnit clusters(100): Cluster CE OP C GE GC virtual Cluster virtual AccessPoint Framework redefined block type AccessPoint system type actualAccessControl inherits AccessControl Use in application

36. FDT Foil no 36 Block Type Cluster virtual block type Cluster virtual LocalUnit virtual ClusterUnit localunits(10): LocalUnit clustercontrol: ClusterUnit PR GC GE e e CE L: AccessPoint virtual block type LocalUnit inherits General e R:Router redefined Router redefined Protocol Validation virtual block type ClusterUnit inherits General P3: Protocol CE redefined Router redefined Protocol L: AccessPoint e R: Router

37. FDT Foil no 37 Package GeneralArchitecture package GeneralArchitecture There is a type in the package which includes Protocol The General type also includes a Router (in order to achieve distribution transparency) There is a type in the package which includes Protocol The General type also includes a Router (in order to achieve distribution transparency) R: Router P:Protocol block type General PR virtual Router virtual Protocol

38. FDT Foil no 38 block type LocalUnit and ClusterUnit We have achieved the separation of infrastructure (which is now in the General type) and application specific ones (AccessPoint) L: AccessPoint virtual block type LocalUnit inherits General e R:Router redefined Router redefined Protocol Validation virtual block type ClusterUnit inherits General P3: Protocol CE redefined Router redefined Protocol L: AccessPoint e R: Router Application Infrastructure