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

2. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder2 Goal: Design a system that is... Highly configurable Message-based Concurrent activities 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

3. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder3 Component Each subsystem is a 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

4. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder4 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 – ECEN 5043 System configuration – specific deployment Instances defined and configured Mapped onto hardware configuration of distributed physical nodes

5. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder5 Step 1: 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 or composite criteria – interacting tightly coupled Geographical distribution Peer-to-peer relationships Subsystem structuring criteria

6. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder6 Collaboration Diagram steps Factory Automation System, Gomaa, p. 674

7. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder7 Use Case Model Use cases associated with Factory Operator ViewAlarms View Workstation Status Generate Workstation Status and Notify Generate Alarm and Notify

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

9. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder9 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 (p-and-p) 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

10. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder10 Domain Model

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

12. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder12 Object Model Fig 21.6 -- Gomaa

13. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder13 Context Diagram > ProcessEngineer > ProductionManager > ProcessEngineer > AssemblyRobot > PickAndPlaceRobot > FactoryAutomation System Interacts with Interfaces to

14. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder14 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

15. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder15 Sample Collaboration Diagrams

16. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder16 Subsystem Collaboration Diagram

17. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder17 Process Planning Subsystem

18. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder18 Subsystem Collaboration Diagram

19. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder19 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 or composite criteria Geographical distribution Peer-to-peer relationships Subsystem structuring criteria

20. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder20 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

21. 9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder21 User Interfaces – 1 for each Operator Interface Process Engineer Interface Production Manager Interface