9/20/2004 arch. des. of dist. sys., ecen5053, univ of colorado, boulder1 architectural design of...
Post on 19-Dec-2015
213 views
TRANSCRIPT
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
1
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, 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
9/20/2004 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
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
4
Overview of steps
System decomposition into subsystemsUse subsystem structuring criteriaDefine interfaces between subsystemsEvaluate subsystem structure with component configuration criteria
Subsystem decomposition into concurrent tasks and passive (information hiding) objects – other courseSystem configuration – specific deployment
Instances defined and configuredMapped onto hardware configuration of distributed physical nodes
9/20/2004 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
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
6
Collaboration Diagram steps
Factory Automation System, Gomaa, p. 674
9/20/2004 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
9/20/2004 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
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
9
Use Case Model(cont. - 2)Production Manager use cases
Create/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• 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, Boulder
10
Domain Model
9/20/2004 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
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
12
Object Model
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
13
Context Diagram
<<external user>>
ProcessEngineer
<<external user>>
ProductionManager
<<external user>>
ProcessEngineer
<<external system>>
AssemblyRobot
<<external system>>
PickAndPlaceRobot
<<system>>
FactoryAutomation System
Interacts with
Interacts with
Interacts with
Interfaces to
Interfaces to
9/20/2004 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
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
15
Sample Collaboration Diagrams
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
16
Subsystem Collaboration Diagram
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
17
Process Planning Subsystem
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
18
Subsystem Collaboration Diagram
9/20/2004 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
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
20
Client/Server Collabs
AlarmHandler 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 subsystem
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
21
User Interfaces
Operator Interface
Process Engineer Interface
Production Manager Interface
9/20/2004 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
9/20/2004 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
9/20/2004 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
9/20/2004 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
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
26
Server
Provides service for other subsystems
Does not initiate requests
9/20/2004 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
9/20/2004 Arch. Des. of Dist. Sys., ECEN5053, Univ of Colorado, Boulder
28
I/O subsystem
Device interface classes
9/20/2004 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