Architectural Design of Distributed Systems

1. Architectural Design of Distributed Systems ECEN 5053 Software Engineering of Distributed Systems University of Colorado, Boulder Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

2. Goal • Highly configurable • Message-based • Concurrent • Mapping subsystems to physical nodes is made at configuration time – design provides flexibility • Message communication allows subsystems to be configured on same or different physical nodes • When you know it must be same node – design for performance Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

3. Component • Each subsystem is self-contained component type • Distributed component is an active object with a well-defined interface • Composite object composed of other objects • Self-contained – can be compiled separately, stored, instantiated, etc. • Can be re-used in different but related applications unless it has application-specific logic Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

4. Overview of steps • System decomposition into subsystems • Use subsystem structuring criteria • Define interfaces between subsystems • Evaluate subsystem structure with component configuration criteria • Subsystem decomposition into concurrent tasks and passive (information hiding) objects – other course • System configuration – specific deployment • Instances defined and configured • Mapped onto hardware configuration of distributed physical nodes Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

5. System decomposition • A way to start -- create collaboration diagrams from use cases • Which objects communicate frequently with each other? • An object can only be in one subsystem – choose. • Aggregate vs. composite criteria • Geographical distribution • Peer-to-peer relationships • Subsystem structuring criteria Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

6. Collaboration Diagram steps • Factory Automation System, Gomaa, p. 674 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

7. Use Case Model • Use cases associated with Factory Operator • ViewAlarms • View Workstation Status • Generate Workstation Status and Notify • Generate Alarm and Notify Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

8. Use Case Model(cont.) • Use cases associated with Process Engineer • Create/update Operation • Create/update Process Plan Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

9. Use Case Model(cont. - 2) • Production Manager use cases • Create/Modify Work Order • Initiates Manufacture Part • releases a work order to be processed in the factory • each part starts processing at receiving workstation where raw part loaded to conveyor belt • next wkstn, picked off conv. belt by pick-and-place robot • assembly robot performs manufacturing operation • p-and-p robot puts back on conv. belt for transport to next workstation • continues to shipping wkstn, picked off conv belt Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

10. Domain Model Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

11. Object Structuring • Figure 21.6, Gomaa -- next slide Process Plan FactoryOperator ProductionManager Process Engineer Assembly Robot PickAndPlaceRobot Alarm Part WorkstationStatus WorkOrder Operation Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

12. Object Model Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

13. Context Diagram <<external user>> ProcessEngineer <<external user>> ProcessEngineer Interacts with Interacts with <<system>> FactoryAutomation System <<external user>> ProductionManager Interfaces to Interacts with <<external system>> PickAndPlaceRobot Interfaces to <<external system>> AssemblyRobot Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

14. Sample Collaboration Diagrams • Fig. 21.10, Gomaa • Fig. 21.12, Gomaa • Step: Combine into high level collaboration diagram(s) as candidate subsystems • Fig. 21.20, p. 700, Factory Automation subsystem • Fig. 21.21, p. 701, Process Planning subsystem • Fig. 21.23, p. 703, Part Processing subsystem Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

15. Sample Collaboration Diagrams Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

16. Subsystem Collaboration Diagram Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

17. Process Planning Subsystem Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

18. Subsystem Collaboration Diagram Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

19. System decomposition • A way to start -- create collaboration diagrams from use cases • Which objects communicate frequently with each other? • An object can only be in one subsystem – choose. • Aggregate vs. composite criteria • Geographical distribution • Peer-to-peer relationships • Subsystem structuring criteria Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

20. Client/Server Collabs • AlarmHandler is a server • Operator Interface is a client, actually a composite forming the Operator Interface user interface subsystem • one for each operator • WorkStationStatus is a server, one for each workstation • Process Plan server and Operation server are used together as a composite server -- Process Planning server • May aggregate the Process Planning Server and the Process Engineer Interface into a Process Planning subsystem Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

21. User Interfaces • Operator Interface • Process Engineer Interface • Production Manager Interface Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

22. Subsystem Structuring Criteria • Control • Coordinator • Data Collection • Data Analysis • Server • User interface • I/O subsystem • System Services Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

23. Control Subsystem • Controls a given aspect of the system • Inputs come from external environment • Outputs to external environment • Often state-dependent • If more than one, may need Coordinator subsystem • In Factory Automation System • ReceivingWorkstationController • LineWorkstationController • ShippingWorkstationController Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

24. Coordinator • May be needed if more than one controller • Unless the controller subsystems are completely independent • or the controller subsystems can coordinate among themselves as in the Factory Automation case Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

25. Data Collection & Analysis • Data Collection subsystem • Collects data from external environment • May be a real time subsystem • Data Analysis subsystem • Analyzes data and provides reports or displays • Probably not a real time subsystem • One subsystem may do both functions Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

26. Server • Provides service for other subsystems • Does not initiate requests Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

27. User Interface • Provides user interface • Acts as client providing access to servers • Usually a composite object composed of related simpler user interface objects Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

28. I/O subsystem • Device interface classes Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder

29. System services • Some services are not problem domain specific • System-level services • file management • network communication management • middleware • Probably not developed along with the application but need to indicate they exist Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder