1. SDS Foil no 1 How to make real systems: Implementation design, deployment and realisation

2. SDS Foil no 2 Implementation design, deployment and realisation Non-functional properties

3. SDS Foil no 3 Realisation Is a precise technical definition of the realisation in terms of the technologies used, such as mechanics, electronics and software Is necessary to actually produce a working system The choice of realisation depends on what properties are desired from the realisation itself (often called non-functional properties) Is a precise technical definition of the realisation in terms of the technologies used, such as mechanics, electronics and software Is necessary to actually produce a working system The choice of realisation depends on what properties are desired from the realisation itself (often called non-functional properties) –What is wrong with realisations? –Why do we need the other models?

4. SDS Foil no 4 Deployment/Implementation design Describes aspects that come in addition to the functionality, such as distribution, hardware/software allocation and use of middleware and defines a mapping between functionality and realisation by: describing the realisation (the physical system) on a high level identifying the technologies used describing how and where the functionality is realised describes configurations Serves together with functionality as the main documentation. Describes aspects that come in addition to the functionality, such as distribution, hardware/software allocation and use of middleware and defines a mapping between functionality and realisation by: describing the realisation (the physical system) on a high level identifying the technologies used describing how and where the functionality is realised describes configurations Serves together with functionality as the main documentation. configuration data: –priorities; –versions; –etc.

5. SDS Foil no 5 How to implement the AC system?

6. SDS Foil no 6 A typical concrete system HW OS Middleware legacy app i/o

7. SDS Foil no 7 Deployment mapping HW OS Middleware legacy app i/o Key design issues: 1.Communication 2.Process behaviour

8. SDS Foil no 8 Implementation design and Deployment finalised Controller design choices: a- controller a language:Java size:compact speed: slow b- controller b... language:Java size:big speed: fast apc: Controller P D U System AccessControl implemented using a HW OS Middleware legacy app i/o

9. SDS Foil no 9 Signals as method/procedure calls Pseudo code of class P2: integer state; void c(){ switch (state) { case 1: P3.e(); P3.f(); State:=2; return; case 2:....; return;} } void d(){ switch (state) { case 1: P3.f(); State:=3; return; case 2:....; return;} } P1 [a,b][c,d] [e,f] P2 P3 P1 c(), d() P2 SDL UML classes Implement state e(), f() P3 state a(), b() any limitations?

10. SDS Foil no 10 Signals as messages

11. SDS Foil no 11 State oriented program State-1: Input:= Wait(Inport,Indefinetely); CASE Input OF (Signal-a): Action-1; GOTO State-3; (Signal-b): Action-2; GOTO State-5; ELSE: Action-3; GOTO State-1; ESAC; State-2: Input:= Wait(Inport,Indefinetely); CASE Input OF (Signal-c):...... State-1: Input:= Wait(Inport,Indefinetely); CASE Input OF (Signal-a): Action-1; GOTO State-3; (Signal-b): Action-2; GOTO State-5; ELSE: Action-3; GOTO State-1; ESAC; State-2: Input:= Wait(Inport,Indefinetely); CASE Input OF (Signal-c):...... State-1 State-5 State-3 signal-a signal-b * Action-1 Action-2 Action-1 Action-3 What if there are many instances?

12. SDS Foil no 12 Action oriented program NEWMODE CONTROL_STATES = SET(State-1, State-2, State-3,...); DCL State CONTROL_STATES; DO FOR EVER Input:= Wait(Inport,Indefinetely); CASE State OF State-1: CASE Input OF (Signal-a):Action-1; State:= State-3; (Signal-b):Action-2; State:= State-5; ELSE: Action-3; State:= State-1; ESAC; State-2: CASE Input OF (Signal-c):....... ESAC; OD; State-1 State-5 State-3 signal-a signal-b * Action-1 Action-2 Action-1 Action-3 What if there are many instances now?

13. SDS Foil no 13 Table driven code Process Instance State (*): Data ST- Table Process Type Output Input SS TYPE FSM (+): Action FSM-Support Signal Signalname (*): Param. do forever begin wait (Inport); Use Signalname and State as key to Transition Record in ST-table; Call Action; State := Next:State; end; inport

14. SDS Foil no 14 Newtype with C-code for an operator

15. SDS Foil no 15 Inline code adapts to code details - but what if we change the programming language?

16. SDS Foil no 16 Layered implementation

17. SDS Foil no 17 Modeling PSM Implementation PlM’ MIDlet MIDlet ActorFrame Implementation using Actor classes J2EE EJB ActorFrame Implementation using Actor classes Functionality using Actor concepts JVM ActorFrame Implementation using Actor classes Mobiles, terminals, appliancesApplication servers An example of layering

18. SDS Foil no 18 How are concrete systems different from SDL systems? There are fundamental differences: 1. processing takes time; 2. errors and noise do occur; 3. physical distances must be covered; 4. resources are finite; 5.data types are concrete and not abstract. and conceptual differences: 6. in communication primitives; 7.in concurrency; 8. in synchronisation primitives; 9. in language primitives. There are fundamental differences: 1. processing takes time; 2. errors and noise do occur; 3. physical distances must be covered; 4. resources are finite; 5.data types are concrete and not abstract. and conceptual differences: 6. in communication primitives; 7.in concurrency; 8. in synchronisation primitives; 9. in language primitives.

19. SDS Foil no 19 How is SDL different from programming languages? Concurrency. Sequential programming languages like C and PASCAL give no support to the concurrency of SDL. Some languages like Java, CHILL and ADA support concurrency, but do it differently from SDL. Timing. Very few programming languages support time at all. SDL-like timing is not directly supported by any language, not even CHILL. Communication. SDL-like signal communication is not directly supported by any language. Sequential behaviour. An SDL process graph specify state- transition behaviour in the fashion of an extended finite state machine. Programming languages specify action sequences. Data. SDL data are abstract and possibly infinite. The implementation in a programming language have to be operational and finite. Concurrency. Sequential programming languages like C and PASCAL give no support to the concurrency of SDL. Some languages like Java, CHILL and ADA support concurrency, but do it differently from SDL. Timing. Very few programming languages support time at all. SDL-like timing is not directly supported by any language, not even CHILL. Communication. SDL-like signal communication is not directly supported by any language. Sequential behaviour. An SDL process graph specify state- transition behaviour in the fashion of an extended finite state machine. Programming languages specify action sequences. Data. SDL data are abstract and possibly infinite. The implementation in a programming language have to be operational and finite. How to bridge the gap?

20. SDS Foil no 20 The main steps of implementation design Starting from a defined functionality and non- functional properties: 1.Perform hardware software tradeoff. 2.Define hardware. 3.Define software. Then go back to functionality and: 1.Define design adjusted and complete functionality. Starting from a defined functionality and non- functional properties: 1.Perform hardware software tradeoff. 2.Define hardware. 3.Define software. Then go back to functionality and: 1.Define design adjusted and complete functionality.

21. SDS Foil no 21 Hardware – software tradeoff BLOCK TYPE LocalStation 1(1) Panel DOOR LSControl P1 CE CU D A: Implemented on dedicated hardware When: – limited functionality – speed is critical – flexiblility is low – physical device needed When: – limited functionality – speed is critical – flexiblility is low – physical device needed B: Implemented in software executing on general computer hardware When: –complex functionality – speed is less critical – high flexiblility When: –complex functionality – speed is less critical – high flexiblility

22. SDS Foil no 22 Design considerations The most time-critical part of the AC system is the access of the central database We may find that it is impossible to serve the system properly from only one database We may want to reconsider the architecture and put the validation closer to the LocalStations We introduce an intermediate level called Cluster The most time-critical part of the AC system is the access of the central database We may find that it is impossible to serve the system properly from only one database We may want to reconsider the architecture and put the validation closer to the LocalStations We introduce an intermediate level called Cluster

23. SDS Foil no 23 Design hardware

24. SDS Foil no 24 How to implement this? system LocalSwitch nameserver (k):other switch ua:UserAgt us:UserServ u(n):User ta: TerminalAgt t:TermServ t(m):Terminal Router pa:LinkAllo l(l):protokol o(k):Other –propose a distributed computing (hardware) structure –propose a deployment mapping from the SDL system above to the computing structure

25. SDS Foil no 25 Observations 1.The structure of the hardware looks differently from the structure of the functionality description in SDL. 2.Some communication protocols will be needed to support the communication between the local and central hardware. 3.The database is distributed. 4.Error handling may be improved. 1.The structure of the hardware looks differently from the structure of the functionality description in SDL. 2.Some communication protocols will be needed to support the communication between the local and central hardware. 3.The database is distributed. 4.Error handling may be improved.

26. SDS Foil no 26 New functions added by the implementation design Some new functions will normally be visible to the user: 1.error handling, e.g. error reports, missing services; 2.operation and maintenance of the realization, e.g. blocking units, testing unit;. 3.access to limited resources such as printers. Some should not be visible to the user: 1.distribution and multiplexing of computers and channels; 2.synchronization and mutual exclusion; 3.communication services; 4.load control. Some new functions will normally be visible to the user: 1.error handling, e.g. error reports, missing services; 2.operation and maintenance of the realization, e.g. blocking units, testing unit;. 3.access to limited resources such as printers. Some should not be visible to the user: 1.distribution and multiplexing of computers and channels; 2.synchronization and mutual exclusion; 3.communication services; 4.load control.

27. SDS Foil no 27 Design software

28. SDS Foil no 28 OS Software categories Message Routing Error Handling Operat. System Application: FSM = IMPLEMENT [ AccessControl.LocalUnit] Display Out SW TYPE LocalUnitSoftware Channel input Channel output Key Input Card- Reader Card i/o Door Lock unit Door Lock i/o Display Key- board (1,10): Panel Hw Panel Bus Out Channel In Channel middleware errh SDL support I/O application

29. SDS Foil no 29 Logical and physical communication BLOCK LocalStation BLOCK Central unit User Abstract system (SDL) Concrete system logical physical logical

30. SDS Foil no 30 Routing module

31. SDS Foil no 31 How design the software? system LocalSwitch nameserver (k):other switch ua:UserAgt us:UserServ u(n):User ta: TerminalAgt t:TermServ t(m):Terminal Router pa:LinkAllo l(l):protokol o(k):Other –Define the software structure running on a node

32. SDS Foil no 32 Access Control and Synchronous Middleware CORBA, Java-RMI, …. LocalUnit LANLAN Application: FSM Input/output ORBORB glue ClusterUnit Application: FSM Input/output ORBORB glue Application: FSM Input/output ORBORB glue CentralUnit call back stub ske- leton glue

33. SDS Foil no 33 Terminal Agent User Agent MeetingPlace Agent Call Agent Terminal Agent User Agent MeetingPlace Agent Call Agent JMS Servlet WebService Parlay-X WS IVR WS Location WS Map WS Parlay-X IVR Location Server MapServer Access and transport networks IPAQ P-800 Fixed or mobile terminal edges ServiceFrame – a convergent example

34. SDS Foil no 34 Testing what? Application (SDL). Application support: SDL runtime support. Input-output modules. Error handling. Middleware: Protocols. Routing. General support: Test and debug facilities. Operating system. Performance (non-functional): Real time response, delays. Traffic handling capacity. Load control. Application (SDL). Application support: SDL runtime support. Input-output modules. Error handling. Middleware: Protocols. Routing. General support: Test and debug facilities. Operating system. Performance (non-functional): Real time response, delays. Traffic handling capacity. Load control.

35. SDS Foil no 35 Deployment/ID descriptions using SOON implements executes represents Software Hardware

36. SDS Foil no 36 platform independent model - PIM platform implementation transformation platform specific implementation platform model platform specific model - PSM transformation General MDA

37. SDS Foil no 37 platform model with mapping abstract state machine platform implementation state machine support application implementation refined application model - PIM’ pure application model - PIM transformation refinement MDA for state machines

38. SDS Foil no 38 Functionality specification Implementation design Functionality description software electronics mechanics Implementation PIM’ PIM SDL C, C++, CHILL SOON PM+ MDA applied