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

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


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


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


4

User Interfaces – 1 for each

Operator Interface

Process Engineer Interface

Production Manager Interface


5

Subsystem Structuring Criteria

Control

Coordinator

Data Collection

Data Analysis

Server

User interface

I/O subsystem

System Services


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


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


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

Server

Provides service for other subsystems

Does not initiate requests


10

User Interface

Provides user interface

Acts as client providing access to servers

Usually a composite object composed of related simpler user interface objects


11

I/O subsystem

Device interface classes

See the context diagram – next slide


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


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


14

Static Model --Composite Classes


15

Subsystem Interfaces


16

Subsystem Interfaces - 2


17

Subsystem Interfaces - 3


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


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.


20

Deployment Diagram

Documents

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