1. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder1 Architectural Design of Distributed Systems, Part 2 ECEN5053 SW Eng of Distributed Systems University of Colorado, Boulder

2. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder2 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

3. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder3 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

4. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder4 User Interfaces – 1 for each Operator Interface Process Engineer Interface Production Manager Interface

5. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder5 Subsystem Structuring Criteria Control Coordinator Data Collection Data Analysis Server User interface I/O subsystem System Services

6. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder6 Control Subsystem Controls a given aspect of the system Inputs come from external environment Outputs to external environment Often state-dependent – may need statechart If more than one, may need Coordinator subsystem In Factory Automation System ReceivingWorkstationController LineWorkstationController ShippingWorkstationController

7. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder7 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

8. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder8 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

9. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder9 Server Provides service for other subsystems Does not initiate requests

10. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder10 User Interface Provides user interface Acts as client providing access to servers Usually a composite object composed of related simpler user interface objects

11. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder11 I/O subsystem Device interface classes See the context diagram – next slide

12. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder12 Context Diagram > ProcessEngineer > ProductionManager > ProcessEngineer > AssemblyRobot > PickAndPlaceRobot > FactoryAutomation System Interacts with Interfaces to

13. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder13 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

14. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder14 Static Model -- Composite Classes

15. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder15 Subsystem Interfaces

16. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder16 Subsystem Interfaces - 2

17. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder17 Subsystem Interfaces - 3

18. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder18 Timeline of COMET Design Methodology – Pt 1  Use case diagrams  Use case narratives Domain model System context model Static model of entity classes Define classes in the class dictionary (classes & attributes) Class diagram  objects  classes  high-level subsystems  add new classes to class dictionary  Per use case, dev collaboration diagram (or sequence)  Analyze sequence  Analyze information passed Dev. statechart for each state- dependent object in a state- dependent collaboration. Synthesize statecharts Message sequence descriptions for each collaboration diagram Requirements Model Analysis Model Design Model Synthesize artifacts of analysis to make initial sw architecture Synthesize collaboration diagrams into collaboration model Synthesize class diagram  Design overall sw architecture: Subsystem structure  Subsystem interfaces  Collaboration diagram for each subsystem  Hi-level collaboration diagram for whole system  Design distributed component-based sw architecture  For dist. apps., define dist. component subsystems using dist. configuration criteria  Def. msg comm interfaces

19. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder19 Timeline of COMET Design Methodology – Pt. 2 Define the concurrent task architecture for each subsystem  Apply task structuring criteria  Define tasks and their interfaces  Dev. concurrent collaboration diagrams for each subsystem  Describe each task in task behavior spec Analyze the performance of the design for real-time tasks Design the classes in each subsystem  Class interfaces  Inheritance hierarchies  If database needed o design db o dev wrapper classes  Dev. class interface spec for each class Dev. detailed software design for each subsystem  Internals of composite tasks including nested passive objects  Details of task synchronizatio mechanisms for obj’s accessed by multiple tasks  Connector classes that encapsulate details of inter-task communication  Des., doc each task’s internal event sequencing logic Performance Analysis for real-time sys Subsystem Classes Design Detailed software design Re-analyze performance in greater detail for each subsystem by iterating on these steps, if necessary. This applies to real-time application design.

20. 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder20 Deployment Diagram