9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder1 Architectural...
-
date post
20-Dec-2015 -
Category
Documents
-
view
216 -
download
1
Transcript of 9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder1 Architectural...
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
1
Architectural Design of Distributed Systems, Part 2
ECEN5053 SW Eng of
Distributed Systems
University of Colorado, Boulder
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
2
System decompositionA 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-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
3
Client/Server Collabs
AlarmHandler is a serverOperator 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 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-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
4
User Interfaces – 1 for each
Operator Interface
Process Engineer Interface
Production Manager Interface
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
5
Subsystem Structuring Criteria
Control
Coordinator
Data Collection
Data Analysis
Server
User interface
I/O subsystem
System Services
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
6
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 SystemReceivingWorkstationController
LineWorkstationController
ShippingWorkstationController
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
7
Coordinator
May be needed if more than one controllerUnless the controller subsystems are completely independent
or the controller subsystems can coordinate among themselves as in the Factory Automation case
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
8
Data Collection & Analysis
Data Collection subsystemCollects data from external environment
May be a real time subsystem
Data Analysis subsystemAnalyzes data and provides reports or displays
Probably not a real time subsystem
One subsystem may do both functions
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
9
Server
Provides service for other subsystems
Does not initiate requests
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
10
User Interface
Provides user interface
Acts as client providing access to servers
Usually a composite object composed of related simpler user interface objects
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
11
I/O subsystem
Device interface classes
See the context diagram – next slide
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
12
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-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
13
System services
Some services are not problem domain specific
System-level servicesfile management
network communication management
middleware
Probably not developed along with the application but need to indicate they exist
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
14
Static Model --Composite Classes
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
15
Subsystem Interfaces
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
16
Subsystem Interfaces - 2
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
17
Subsystem Interfaces - 3
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
18
Timeline of COMET Design Methodology – Pt 1
Use case diagramsUse case narratives
Domain model
System context model
Static model of entity classes
Define classes in the class dictionary (classes & attributes)
Class diagramobjectsclasseshigh-level subsystemsadd new classes to class dictionary
Per use case, dev collaboration diagram (or sequence)Analyze sequenceAnalyze information passed
Dev. statechart for each state-dependent object in a state-dependent collaboration.Synthesize statecharts
Message sequence descriptions for each collaboration diagram
RequirementsModel
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 structureSubsystem interfacesCollaboration diagram for each subsystemHi-level collaboration diagram for whole system
Design distributed component-based sw architectureFor dist. apps., define dist. component subsystems using dist. configuration criteriaDef. msg comm interfaces
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
19
Timeline of COMET Design Methodology – Pt. 2
Define the concurrent task architecture for each subsystem
Apply task structuring criteriaDefine tasks and their interfacesDev. concurrent collaboration diagrams for each subsystemDescribe each task in task behavior spec
Analyze the performance of the design for real-time tasks
Design the classes in each subsystemClass interfacesInheritance hierarchiesIf database neededodesign dbodev wrapper classesDev. class interface spec for each class
Dev. detailed software design for each subsystemInternals of composite tasks including nested passive objectsDetails of task synchronizatio mechanisms for obj’s accessed by multiple tasksConnector classes that encapsulate details of inter-task communicationDes., doc each task’s internal event sequencing logic
PerformanceAnalysis 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.
9-23-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder
20
Deployment Diagram