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

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

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

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 – other course System configuration – specific deployment Instances defined and configured Mapped onto hardware configuration of distributed physical nodes

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

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

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

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/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 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

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

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

9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder12 Object Model

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

9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder14 Sample Collaboration Diagrams Fig , Gomaa Fig , Gomaa Step: Combine into high level collaboration diagram(s) as candidate subsystems Fig , p. 700, Factory Automation subsystem Fig , p. 701, Process Planning subsystem Fig , p. 703, Part Processing subsystem

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

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

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

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

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 vs. composite criteria Geographical distribution Peer-to-peer relationships Subsystem structuring criteria

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

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

9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder22 Subsystem Structuring Criteria Control Coordinator Data Collection Data Analysis Server User interface I/O subsystem System Services

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

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

9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder25 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/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder26 Server Provides service for other subsystems Does not initiate requests

9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder27 User Interface Provides user interface Acts as client providing access to servers Usually a composite object composed of related simpler user interface objects

9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder28 I/O subsystem Device interface classes

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