How to make real systems: Implementation design, deployment and realisation

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

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

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) So, what’s the problem? How is implementation design different from functional design?

4. Consider the AC system as an example: Abstract objects, SDL State machines Asynchronous messaging How to find a realization? Realization Concrete objects, hw, sw Distribution Scheduling I/O drivers Middleware

5. legacy app app i/o legacy app app i/o Middleware Middleware OS OS HW HW A typical realization

6. legacy app app i/o legacy app app i/o Middleware Middleware OS OS HW HW Deployment mapping Key design issues: • Performance • Timeliness • Availability

7. legacy app app i/o legacy app app i/o Middleware Middleware OS OS HW HW Communication options • Synchronous – invocation: method calls, RMI, CORBA, Web, SOAP, … • Asynchronous – messaging: TCP, UDP, MoM, Actor Router, MQTT, … • Physical lines and I/O

8. [a,b] [c,d] [e,f] P1 P2 P3 SDL Implement Implement Implement UML classes P2 P3 P1 state state state a(), b() c(), d() e(), f() Synchronous communication using method 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;} } } any limitations?

9. Conditions for synchronous communication by procedure/method calls : Structure: The (sub) system must behave like a single procedure/method call tree, a single sequential activity thread. Waiting: Waiting for external events or timers only at the root of the tree, unless the waiting time is negligible. No mixed initiatives!! Return signals: For each signal sent down the tree, not more than one reply signal is returned to the sender (implemented as a procedure return value). Return signals must be sent as the last action on a transition before entering the next state, i.e. only one pr transition. Timing: There is sufficient time between each external input signal to process all signals and outputs that follows from it, and to return to the input process. Consequently, there is no need to give pre-emptive priority to the input process. Distribution: The added RPC/RMI overhead must be acceptable What if there are many instances?

10. Asynchronous communication using messages Structure: no restrictions Distribution: transparent, efficient and scalable Memory management: required – here freepools

11. What about performance? • Synchronous calls are only efficient within a single activity thread! • Asynchronous messaging is normally more efficient between scheduled processes and across networks even with the overhead of queues! Because with messaging: • scheduling is simple • processes are not blocked when communicating • context switching is reduced.

12. Communication • SDL and UML does not restrict your implementation options! • You are free to use your preferred communication solution • As long as it fits your application problem!!

13. Is synchronous communication OK in • The ATM system? • The access control system? • The Taxi system? • Call handling, the LocalSwitch? • Web services, e.g. internet banking? • A City guide?

14. signal-a signal-b * State-1 Action-1 Action-2 Action-3 Action-1 Action-1 Action-1 State-1 State-5 State-3 State machines: 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): ... ... What if there are many instances?

15. signal-a signal-b * State-1 Action-1 Action-2 Action-3 Action-1 Action-1 Action-1 State-1 State-5 State-3 State machines: 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; What if there are many instances now?

16. Implementation from Exercise 2 P1 run state Pn run state P1 Run state Pn Run state inq RTS RTS: Do forever Begin msg := inq.receiveMessage(); //input fsm:= findObject(msg.destination) //select process instance fsm.run(msg); End;

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

18. State machines • SDL/UML does not restrict your implementation options • You are free to use any language and platform you like • Using a runtime support system helps to simplify coding and testing. • RTS features: • Signal addressing • Signal sending and receiving • Timers • Process scheduling • SDL Procedure calls and composite states • State-machine coding

19. Runtime support – virtual SDL machines

20. A software design

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

22. Logical and physical communication BLOCK LocalStation BLOCK Central unit logical User logical Abstract system (SDL) Concrete system physical physical

23. Routing module

24. How are concrete systems different from abstract SDL and UML 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.

25. 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. configuration data: • priorities; • versions; • etc.