Architectural Design of Distributed SystemsGoal: Design a system that is ...ComponentOverview of stepsStep 1: System decompositionCollaboration Diagram stepsUse Case ModelUse Case Model (cont.)Use Case Model (cont. - 2)Domain ModelObject StructuringObject ModelContext DiagramSample Collaboration DiagramsPowerPoint PresentationSlide 16Slide 17Slide 18System decompositionClient/Server CollabsUser Interfaces – 1 for each9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder1Architectural Design of Distributed SystemsECEN 5053 Software Engineering of Distributed SystemsUniversity of Colorado, Boulder9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder2Goal: Design a system that is ...Highly configurableMessage-basedConcurrent activitiesMapping subsystems to physical nodes is made at configuration time – design provides flexibilityMessage communication allows subsystems to be configured on same or different physical nodesWhen you know it must be same node – design for performance9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder3ComponentEach subsystem is a self-contained component typeDistributed component is an active object with a well-defined interfaceComposite object composed of other objectsSelf-contained – can be compiled separately, stored, instantiated, etc.Can be re-used in different but related applications unless it has application-specific logic9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder4Overview of stepsSystem decomposition into subsystemsUse subsystem structuring criteriaDefine interfaces between subsystemsEvaluate subsystem structure with component configuration criteriaSubsystem decomposition into concurrent tasks and passive (information hiding) objects – ECEN 5043System configuration – specific deploymentInstances defined and configuredMapped onto hardware configuration of distributed physical nodes9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder5Step 1: System decompositionA way to start -- create collaboration diagrams from use casesWhich objects communicate frequently with each other?An object can only be in one subsystem – choose.Aggregate or composite criteria – interacting tightly coupledGeographical distributionPeer-to-peer relationshipsSubsystem structuring criteria9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder6Collaboration Diagram stepsFactory Automation System, Gomaa, p. 6749/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder7Use Case ModelUse cases associated with Factory OperatorViewAlarmsView Workstation StatusGenerate Workstation Status and NotifyGenerate Alarm and Notify9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder8Use Case Model(cont.)Use cases associated with Process EngineerCreate/update OperationCreate/update Process Plan9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder9Use Case Model(cont. - 2)Production Manager use casesCreate/Modify Work OrderInitiates 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 belt9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder10Domain Model9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder11Object StructuringFigure 21.6, Gomaa -- next slideProcess PlanFactoryOperatorProductionManagerProcess EngineerAssembly RobotPickAndPlaceRobotAlarmPartWorkstationStatusWorkOrderOperation9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder12Object ModelFig 21.6 -- Gomaa9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder13Context Diagram<<external user>>ProcessEngineer<<external user>>ProductionManager<<external user>>ProcessEngineer<<external system>>AssemblyRobot<<external system>>PickAndPlaceRobot<<system>>FactoryAutomation SystemInteracts withInteracts withInteracts withInterfaces toInterfaces to9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder14Sample Collaboration DiagramsFig. 21.10, GomaaFig. 21.12, GomaaStep: Combine into high level collaboration diagram(s) as candidate subsystemsFig. 21.20, p. 700, Factory Automation subsystemFig. 21.21, p. 701, Process Planning subsystemFig. 21.23, p. 703, Part Processing subsystem9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder15Sample Collaboration Diagrams9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder16Subsystem Collaboration Diagram9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder17Process Planning Subsystem9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder18Subsystem Collaboration Diagram9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder19System decompositionA way to start -- create collaboration diagrams from use casesWhich objects communicate frequently with each other?An object can only be in one subsystem – choose.Aggregate or composite criteriaGeographical distributionPeer-to-peer relationshipsSubsystem structuring criteria9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder20Client/Server CollabsAlarmHandler is a serverOperator Interface is a client, actually a composite forming the Operator Interface user interface subsystem one for each operatorWorkStationStatus is a server, one for each workstationProcess Plan server and Operation server are used together as a composite server -- Process Planning serverMay aggregate the Process Planning Server and the Process Engineer Interface into a Process Planning subsystem9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder21User Interfaces – 1 for eachOperator Interface Process Engineer InterfaceProduction Manager