9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder1 Architectural Design of Distributed Systems, Part 3 ECEN5053 SW

9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder

1

Architectural Design of Distributed Systems, Part 3

ECEN5053 SW Eng of

Distributed Systems

University of Colorado, Boulder


2

Overview of steps

System decomposition into subsystemsUse 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 deploymentInstances defined and configured

Mapped onto hardware configuration of distributed physical nodes


3

Static Model --Composite Classes


4

Subsystem Interfaces


5

Subsystem Interfaces - 2


6

Subsystem Interfaces - 3


7

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


8

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

Deployment Diagram


10

One more pass

Want to be sure the subsystems can be designed as distributed components, mapped to distributed nodes.

Component Configuration criteria

Providing a service specific to a site – each instance on a specific node

Performance

Specialized hardware or interfaces

User interface

Server component


11

Service specific to a site

One component can be operational even if the other nodes are unavailable

Proximity to the source of physical data – fast access for high access rates

Localized autonomyReceives high level commands from elsewhere

Provides low-level control, perhaps providing status information


12

Performance

All related objects on the same node to perform a time-critical function

May need to violate some other principle

How critical is critical?


13

Specialized HW

Component supports specialized hardware

interfaces to special-purpose peripherals, sensors

need to be nearby


14

User interface

Located at the node where the user is

Responses to simple requests can be rapid

Responses to more complicated requests can be slower – psychologically acceptable


15

Server component

Service for other components

“Proximity to source of data” may overlap

A data server might support remote access to a centralized database or file store – not always co-located with the data store


16

Subsystem Interfaces - asynchronous

Message communication for distributed systems

Loosely-coupled asynchronous message communication between subsystems wherever possible

FIFO message queues

Priority message queues

Group communication (multicast) from one location to all members of a group


17

Subsystem Interfaces - Synchronous

Tightly coupled – client sends a msg and waits (idle or suspended) for a response

Single client/server

Multiple-client/server• Queue can build up at server end• Server can delegate processing of client’s request

to another server which then responds directly to the original client


18

ack/nack

Msg communication in same or different subsystems is generally handled the same way but

remote transmission has the possibility of failure en routeMOM communicates with MOMEven in asynchronous comm, may want indication that msg has arrived• Negative ack to source task from local MOM if

ack not received within time spec• Source task must decide what to do


19

Synchronous with reply

Sends a msg and waits for a replynack from local MOM indicating timeout

If client and server are to dialog, establish a connection and send/receive msgs over the connection

Synchronous without replypossible but ... what’s the point?

(there may be a point – what is it?)


20

Group msg comm or subscribe/notify

One source, multiple destinations

Broadcast communicationunsolicited msg sent to all recipients; recipients decide whether to discard or process

Multicastsame msg sent to members of a group

Subscribe/notify

Publisher can send to group


21

Brokered Communication

Clients and servers can be distributed objectsObject broker is intermediary in interactions between them

Client does not have to maintain info about where the service is provided or how to obtain itProvides location transparency – if server moves, only the broker needs to knowServers register services they provide and locationClients identify service required and send msgBroker receives request, finds location, forwards req.


22

Transaction Management

In this section, sufficient to realize the need for transactions

Flat – all or nothing

Compound – might need only partial rollback

We’ll spend a week specifically on transaction management


23

Data distribution

Distributed datadivided into sections

each section on a different subsystem

Replicated dataidentical copies everywhere

challenge is to keep them identical at the level required by the application

We spend a week on this topic, also.

Documents

9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder1 Architectural Design of Distributed Systems, Part 3 ECEN5053 SW