Case Studies

1. Case Studies Comet case studies Elevator control system From task structuring to target system configuration.

2. Task structuring Centralized solution • Determine tasks for each subsystem • Define task interfaces • Design of data abstraction classes

3. Task structuring Centralized solution Assumptions • Elevator Control System is mapped to a single CPU or to a multiprocessor configuration with shared memory • Elevator Status&Plan object is accessible to all elevators and to the scheduler • We can use a centralized repository of data

4. Task structuring Centralized solution Procedure • Analize all the objects on the collaboration diagrams • Apply the task structuring criteria

5. Task structuring Elevator subsystem Elevator button Interface • Asynchronous input device interface criterion -> Separate task • Task inversion criteria -> One task handles all the elevator buttons

6. Task structuring Elevator subsystem Elevator Manager • Structured as a Coordinator Object

7. Task structuring Elevator subsystem Elevator Status&Plan • Passive data abstraction object -> doesn’t need a separate thread of control

8. Task structuring Elevator subsystem Elevator Control «external output device» :FloorLamp «coordinator» :Scheduler D6a.1: Direction Lamp Output D10a: Departed (Floor#) D6a: Off Up Direction Lamp «output device interface»:DirectionLampInterface «state dependent control»:ElevatorControl D6: Up «output device interface» :MotorInterface D9: Elevator Started D10: Departed (Floor#) D7: Start Up Motor Command D8: Motor Response «external output device» :Motor «entity» :ElevatorStatus&Plan

9. Task structuring Elevator subsystem Elevator Control Each Elevator Control object is mapped to a separate Elevator Controller task It interacts with several output device interface objects such as: • Motor Interface • Door Interface • Elevator Lamps Interface Do we need separate tasks?

10. Task structuring Elevator subsystem Output devices • Passive devices • Output request executed on demand • The calling task has to wait for the output request to complete • Elevator Controller doesn’t execute concurrently with Motor Interface and Door interface By the Control Clustering Criteria we combine these tasks with the Elevator Controller task

11. Task structuring Elevator subsystem Elevator Controller doesn’t execute concurrently with Motor Interface and Door interface Elevator Moving Approaching Floor/Check This Floor Entry/Departed Approaching Requested Floor/Stop ,On Direction Lamp Elevator Stopping Elevator Stopped/Open Door, Off Elevator Lamp, Arrived Elevator Door Opening Door opened/Start Timer Elevator at Floor

12. Task structuring Elevator subsystem Summary For the Elevator Control subsystem we have four tasks • Elevator Buttons Interface • Arrival Sensors Interface • Elevator Manager • Elevator Controller

13. Task structuring Elevator subsystem

14. Task structuring Floor subsystem We start from the floor subsystem structure. «data collection subsystem» :FloorSubsystem Floor Button Request Service Request «subsystem» : Scheduler «input device interface» :FloorButtonInterface «external input device» : FloorButton Floor Lamp Command Floor Lamp Output «output device interface» :FloorLampInterface «external output device» : FloorLamp «subsytem» :ElevatorSubsystem Direction Lamp Output Direction Lamp Command «external output device» : DirectionLamp «output device interface» :DirectionLampInterface

15. Task structuring Floor subsystem We determine the Floor Button Interface task We consider Floor Lamp Interface and Direction Lamp Interface • Are passive output devices • Receive concurrent requests from the Elevator Controller instances We use monitors tasks to serialize the requests

16. Task structuring Centralized solution

17. Task structuring Centralized solution

18. Task structuring Define Task interfaces • Consider message interfaces between concurrent tasks • Map them to loosely or tightly coupled messages • Add name and parameters of each message

19. Task structuring Define Task interfaces For instance: Elevator Request <<asynchronous input device interface>> :Elevator Buttons Interface <<coordinator>> :Elevator Manager Elevator Request(Elevator#,floor#,direction) <<asynchronous input device interface>> :Elevator Buttons Interface <<coordinator>> :Elevator Manager

20. Task structuring Define Task interfaces

21. Task structuring Define Task interfaces

22. <<data abstraction>> Elevator Status&Plan + arrived(elevator#,floor#,direction) + departed(elevator#,floor#,direction) + checkThisFloor(in elevator#,in floor#,out floor status, out direction) + checkNextDestination(in elevator,#out direction) + updatePlan(elevator#,floor#, direction ,out idlestatus) + selectElevator(in floor#, out elevator#,in direction) Task structuring Design of Data Abstraction Class

23. Distributed Solution • -Subsystem Structuring • Design of Device Interface classes • Design of information hiding classes • Design of Device Interface classes • Design of State-Dependent classes • Detailed software design • Design of Connector objects • Design of Composite Tasks • Target system configuration

24. General description Distributed solution Physical configuration: • Multiple nodes interconnected by a LAN • No shared memory • All communication is via loosely coupled messages

25. Task structuring Distributed Solution

26. General description Distributed solution An emerging issue • Now the Scheduler and the multiple instances of the ElevatorManager cannot directly access Elevator Status&Plan data object We may: • Embed ElevatorStatus&Plan in a server object • Use replicated data

27. General description Distributed solution Server solution • Clients access the ElevatorStatus&Plan with a synchronous message with reply Risk of Bottleneck!

28. General description Distributed solution Data replication solution • Each instance of the Elevator Subsystem maintains a Local ElevatorStatus&Plan • The Scheduler Subsystem maintains an Overall Status&Plan Faster data access

29. Subsystem Structuring Distributed solution Structure of Elevator Subsystem • Similar to the centralized solution -Each Elevator subsystem contains a Local Elevator Status&Plan object

30. Task structuring Distributed solution

31. Task structuring Distributed solution

32. Subsystem Structuring Distributed solution Structure of Scheduler Subsystem • Elevator Status&Plan Server Task • Receives Status and commitment messages • Updates Overall Elevator Status&Plan -Elevator scheduler • Receives Service Requests messages

33. Subsystem Structuring Distributed solution

34. Design of information hiding classes We design the operations of • Device Interface classes • Data abstraction class(distributed) • State Dependent class

35. <<Output Device interface>> Floor Lamp Interface <<Output Device interface>> Arrival Sensor Interface + initialize() +off() + initialize() + read(out sensorInput) Design of information hiding classes Design of device interface classes

36. <<Output Device interface>> Motor Interface <<Output Device interface>> Door Interface + initialize() + stop(out stopped) + up(out started) + down(out started) + initialize() + open(out opened) + close(out closed) Design of information hiding classes Design of device interface classes

37. Design of information hiding classes Design of Data Abstraction Class <<data abstraction>> LocalElevator Status&Plan + arrived(elevator#,floor#,direction) + departed(elevator#,floor#,direction) + checkThisFloor(in elevator#,in floor#,out floor status, out direction) + checkNextDestination(in elevator,#out direction) + updatePlan(elevator#,floor#, direction ,out idlestatus)

38. Design of information hiding classes Design of Data Abstraction Class <<data abstraction>> OverallElevator Status&Plan + arrived(elevator#,floor#,direction) + departed(elevator#,floor#,direction) + updatePlan(elevator#,floor#, direction ,out idlestatus) + selectElevator(in floor#, out elevator#,in direction)

39. <<state dependent control>> Elevator Control + processEvent(in event,out action) + currentStatus():Status Design of information hiding classes Design of State Dependent Class

40. Detailed Software Design Two main phases: • Design of the connector objects • Design of the composite tasks

41. Detailed Software Design Design of connector objects We introduce connectors to hide the details of message communication. The sender tasks should be unaware of the location of the receiver tasks Location transparency

42. Detailed Software Design Design of connector objects Elevator subsystem

43. Detailed Software Design Design of connector objects Elevator subsystem Messages from Arrival Sensor Interface and Elevator Manager to Elevator controller never overlap-> We can use one message buffer instead of two We introduce three message queue connectors to hide the details of asynchronous(and possibly remote) communication

44. Detailed Software Design Design of connector objects

45. Detailed Software Design Design of composite tasks Elevator Controller Task embeds • Three output device interfaces • One state dependent control object • Two objects that provide synchronization

46. Detailed Software Design Design of composite tasks • Resource monitor tasks embed the passive I/O interfaces for the devices they operate • Each device interface object for an asynchronous I/O device is placed inside the task supporting that device

47. Detailed Software Design Design of composite tasks

48. System Configuration Distributed solution Target system configuration • Instances of the component types are defined • Component instances are interconnected • Component instances are mapped to physical nodes

49. System Configuration Distributed solution A possible physical configuration • One Elevator Subsystem for each elevator node • One Floor Subsystem for each floor node

50. System Configuration Distributed solution