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

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

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

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

SDS Foil no 5 A typical realization HW OS Middleware legacy app i/o

SDS Foil no 6 Deployment mapping HW OS Middleware legacy app i/o Key design issues: 1.Performance 2.Timeliness 3.Availability

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

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

SDS Foil no 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 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?

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

SDS Foil no 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! 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.

SDS Foil no 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!! 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!!

SDS Foil no 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? The ATM system? The access control system? The Taxi system? Call handling, the LocalSwitch? Web services, e.g. internet banking? A City guide?

SDS Foil no 14 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): 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?

SDS Foil no 15 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; 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?

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

SDS Foil no 17 State machines: 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

SDS Foil no 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 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

SDS Foil no 19 Runtime support – virtual SDL machines

SDS Foil no 20 A software design

SDS Foil no 21 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

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

SDS Foil no 23 Routing module

SDS Foil no 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. 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.

SDS Foil no 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. 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.