Entwurf verteilter Systeme Max Göbel. Das werden wir hören : Verteilte Applikationen: Definition...

Entwurf verteilter Systeme

Max Göbel

Das werden wir hören :

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf

• (Taskstrukturierung, siehe Karstens Vortrag)

• Datenkapselungsklassen-Entwurf

• Konnektoren-Entwurf

• Task-Entwurf Zielsystemkonfigurierung

__________________Verteilte Applikationen: Definition_______________________________________Verteilte Applikationen: Definition_____________________

Eine verteilte Applikation ist eine nebenläufige Applikation, die auf physikalischen Knoten an geographisch unterschiedlichen Orten ausgeführt wird.

Physikalischer Knoten2

Physikalischer Knoten1

<<local area network>>

Beispiel: Fahrstuhl

_______________Entwurf verteilter Applikationen: _______________Entwurf verteilter Applikationen: Einleitung_________________Einleitung_________________

Ausgangspunkt:

Das Analysemodell. Hier wird die Problemdomäne widerspiegelt wird.

Ziel:

Mappen des Analysemodells auf ein Entwurfsmodell, welches die Lösungsdomäne widerspiegelt. Die drei wesentlichen Schritte dabei sind:

Subsystemstrukturierung

Subsystementwurf

Zielsystemkonfigurierung

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf

• (Taskstrukturierung, siehe Karstens Vortrag)

• Datenkapselungsklassen-Entwurf

• Konnektoren-Entwurf

• Task-Entwurf Zielsystemkonfigurierung

_______________________Subsystemstrukturierung_(1)____________________________________________Subsystemstrukturierung_(1)_____________________

Definition:Ein Subsystem ist eine konfigurierbare Komponente und

entspricht einem logischem Knoten. Eine Komponente

besteht aus nebenläufigen Tasks, die auf einem logischen

Knoten ausgeführt werden, und einem aktiven Objekt mit

wohldefinierter Schnittstelle.

Vorgehen:Ausgangspunkt ist das konsolidierte Kollaborationsdiagramm.

Darunter versteht man eine Zusammenfassung der

Kollaborationsdiagramme zu sämtlichen Use-Cases.

Anforderungen an Subsysteme: Geringe Kopplung zu anderen Subsystemen Starke Kopplung der Objekte innerhalb des Subsystems Eingrenzung auf eine spezielle Funktionalität Schmale Schnittstellen zu anderen Subsystemen

Kriterien zur Subsystemenstrukturierung: Geographische Gegebenheiten Echtzeitanforderungen Kontakt zwischen System und externen Objekten der

Außenwelt Koppelung zwischen den Objekten

Daumenregeln für die Subsystemstrukturierung: Für ein Userinterface ein eigenes Subsystem Häufig für ein Usecase ein eigenes Subsystem Alle Objekte, die Teil eines Aggregat- oder Compositeobjektes sind, kommen in dasselbe Subsystem Entityobjekte kommen im Zweifelsfall in das Subsystem,

von dem aus sie geupdated werden Ein Kontrollobjekte mit allen von ihm kontrollierten Objekten bildet ein Subsystem

_______________________Subsystemstrukturierung_(2)____________________________________________Subsystemstrukturierung_(2)_____________________

Klassen von Subsystemen:

Control Subsystem: Kontrolliert selbstständig einen abgegrenzten Teil des Systems Coordinator Subsystem:Koordiniert verschiedene Control Subsysteme Data Collection Subsystem:Sammelt Daten von der Umgebung und bereitet sie auf Data Analysis Subsystem:

Analysiert Daten, die von anderen Subsystemen gesammelt wurden Server Subsystem:

Bietet einen Service für andere Subsysteme an User Interface Subsystem:

Kapselt die Schnittstelle zum Benutzer I/O Subsystem:

Kapselt sämtliche Kommunikation mit der externen Umwelt System Services Subsystem

Stellt nicht-problemspezifische Dienste zur Verfügung

_______________________Subsystemstrukturierung_(3)____________________________________________Subsystemstrukturierung_(3)_____________________

Beispiel Fahrstuhl:

Wichtigstes Strukturierungskriterium: Geographische Gegebenheiten.

Aufteilung in drei Subsysteme: Ein control subsystem für jeden Fahrstuhl, das

autonom die Hardware jedes Fahrstuhls steuert und Requests entgegennimmt (ElevatorSubsystem)

Ein data collection subsystem für jedes Stockwerk, das die Fahrstuhlanforderungen entgegennimmt (FloorSubsystem)

Ein coordinator subsystem, das die verschiedenen Fahrstühle koordiniert und jeder

Fahrstuhlanforderung einen Fahrstuhl zuordnet (Scheduler)

_______________________Subsystemstrukturierung_(4)____________________________________________Subsystemstrukturierung_(4)_____________________

<<system>> :ElevatorControl System

<<data collectionsubsystem>>

:FloorSubsystem

<<coordinatorsubsystem>>

:Scheduler

<<controlSubsystem>>

:ElevatorSubsystem

<<external inputDevice>>

:ElevatorButton<<external output

device>>:DirectionLamp

<<external output device>>

:FloorLamp

<<external inputdevice>>

:FloorButton

<<external output device>>

:ElevatorLamp

<<external inputdevice>>

:ArrivalSensor

<<external output device>>:Motor

<<external output device>>

:Door

FloorLampCommand

DirectionLamp Command

Arrival (Floor#)

Departed(Floor#)

Elevator Commitment

SchedulerRequest

Service Request

Floor Lamp Output

Floor ButtonRequest

Motor Response

Motor Command

ElevatorButton Request

ElevatorLamp OutputArrival

Sensor Input

Door Response

Door Command

Direction LampOutput

_______________________Subsystemstrukturierung_(5)____________________________________________Subsystemstrukturierung_(5)_____________________

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf

• (Taskstrukturierung, siehe Karstens Vortrag)

• Datenkapselungsklassen-Entwurf

• Konnektoren-Entwurf

• Task-Entwurf Zielsystemkonfigurierung

_______________________Subsystementwurf______________________________________________________Subsystementwurf_______________________________

Ziel:

Detailierter Entwurf der einzelnen Subsysteme und Spezifikation aller Klassenschnittstellen.

Vorgehen:

Die einzelnen Subsysteme können unabhängig von einander mit Methoden für die Entwicklung Nicht-verteilter-Applikationen entwickelt werden. Der Subsystementwurf gliedert sich in folgende Schritte:

Taskstrukturierung

Datenkapselungsklassen-Entwurf

Konnektoren-Entwurf

Task-Entwurf

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf

• (Taskstrukturierung, siehe Karstens Vortrag)

• Datenkapselungsklassen-Entwurf

• Konnektoren-Entwurf

• Task-Entwurf Zielsystemkonfigurierung

_______________________Taskstrukturierung_(1)________________________________________________Taskstrukturierung_(1)_________________________

Definition:

Ein Task ist ein aktives Objekt mit eigenem Kontrollfluß. Ein Task repräsentiert die Ausführung eines sequentiellen Programms oder einer sequentiellen Komponente eines nebenläufigen Programms. Jeder Task hat einen sequentiellen Kontrollfluß. Es gibt keine Nebenläufigkeit innerhalb eines Tasks.

Ziel:

Strukturierung der Subsysteme in Tasks und Datenkapselungsklassen. Das objektorientierte Analysemodell wird auf eine nebenläufige Taskarchitektur gemappt.

Vorgehensweise:

Streng geheim (siehe Karstens Vortrag)

<<passive output device>>

:Door

<<passive output device>>:Motor

<<coordinator>>:ElevatorManager

<<subsystem>>:Scheduler

<<assynchronous Input device interface>>

:ElevatorButtonsInterface

<<assynchronous inputdevice interface>>

:ArrivalSensorInterface

<<control clusering>>:ElevatorController<<subsystem>>

:FloorSubsystem

<<passive output device>>

:ElevatorLamp

<<assynchronous input device>>:ArrivalSensor

<<assynchronous input device>>:ElevatorButton

<<data abstraction>>:LocalElevatorStatus&Plan

<<control subsystem>> :ElevatorSub

system

Elevator Button Request

Arrival Sensor Input

Elevator Request

Up, Down

Approaching Floor (Floor #)

FloorLamp CommandDirectionLampCo

mmand

Elevator Lamp Output

Motor Command

Motor Response

Door Command

Door Response

Arrived (Floor #)

Departed(Floor#)

Schduler Request

Elevator Commitment

Update

Acknowledge

CheckNextDestination

CheckThis Floor(Floor#)

Arrived (Floor#)

Departed (Floor#)

Next Destination

ApproachingRequested

Floor

_______________________Taskstrukturierung_(2)________________________________________________Taskstrukturierung_(2)_________________________

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf

• (Taskstrukturierung, siehe Karstens Vortrag)

• Datenkapselungsklassen-Entwurf

• Konnektoren-Entwurf

• Task-Entwurf Zielsystemkonfigurierung

__________________Datenkapselungsklassen-Entwurf_(1)_____________________________________Datenkapselungsklassen-Entwurf_(1)___________________

Definition:

Datenkapselungsklassen sind Klassen, deren Objekte von unterschiedlichen Tasks aus benutzt werden und deren Aufgabe darin besteht, eine einheitliche Schnittstelle für den Zugriff auf bestimmte Daten anzubieten, sowie die innere Struktur der Daten für andere Objekte transparent zu halten.

Vorgehen beim Entwurf einer Datenkapselungsklasse

Alle Objekte betrachten, die Nachichten an Objekte der betreffenden Klasse schicken.

Den bisher nur semiformal spezifizierten Nachichten eventuell fehlende Ein- und Ausgabeparameter hinzufügen

Jede Nachicht, die ein Objekt der betreffenden Klasse als empfängt, als Methode der Klasse im Klassendiagramm übernehmen.

1. Schritt__________________Datenkapselungsklassen-Entwurf_(2)_____________________________________Datenkapselungsklassen-Entwurf_(2)___________________

<<controll Clustering>>

:ElevatorController

<<data Abstraction>>:LocalElevatorStatus&Plan

<<coordinator>>:ElevatorManagerApproaching

Requested Floor

Acknowledge

UpdateNext Destination

CheckNext Desination

CheckThis Floor(Floor #)

Arrived (Floor #)

Departed (Floor #)

2. Schritt

<<controll Clustering>>

:ElevatorController

<<data Abstraction>>:LocalElevatorStatus&Plan

<<coordinator>>:ElevatorManager

updatePlan(floor#, direction, out idleStatus)

checkNextDestination( out direction)

checkThisFloor( in floor#, out floorStatus, out direction)

arrived(floor#, direction)

departed(floor#, direction)

3. Schritt<<data abstraction>> LocalElevatorStatus&Plan

+ arrived (floor#, direction)

+ departed (floor#, direction)

+ checkThisFloor (in floor#, out floorStatus, out direction)

+ checkNextDestination (out direction)

+ updatePlan (floor#, direction, out idleStatus)

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf

• (Taskstrukturierung, siehe Karstens Vortrag)

• Datenkapselungsklassen-Entwurf

• Konnektoren-Entwurf

• Task-Entwurf Zielsystemkonfigurierung

Definition:

Ein Konnektor ist ein Objekt, dass die Kommunikationslogik für die Kommunikation zwischen zwei Tasks kapselt.

Mögliche Kommunikationsarten zwischen Tasks Asynchrone Kommunikation: Der Sender arbeitet sofort nach dem Senden

weiter. Synchrone Kommunikation ohne Rückgabeparameter: Der Sender wartet, bis

der Empfänger die Nachricht empfangen hat. Synchrone Kommunikation mit Rückgabeparamter: Der Sender wartet, bis

der Empfänger die Nachricht empfangen und die Antwort zurückgeschickt hat.

Verschieden Klassen von Konnektoren: Message Queue Connector: Kapselt den Kommunikationsmechanismus für

asynchrone Kommunikation. Der Produzent wird nur dann suspendiert, wenn die Warteschlange voll ist, der Konsument nur dann, wenn die Warteschlange leer ist.

Message Buffer Connector: Kapselt den Kommunikationsmechanismus für synchrone Kommunikation ohne Rückgabeparameter.

Message Buffer & Response Connector: Kapselt den Kommunikations-mechanismus für synchrone Kommunikation mit Rückgabeparameter.

__________________________Konnektoren-Entwurf_(1)_______________________________________________Konnektoren-Entwurf_(1)_____________________

__________________________Konnektoren-Entwurf_(2)_______________________________________________Konnektoren-Entwurf_(2)_____________________

<<passive output device>>

:Door

<<passive output device>>:Motor

<<coordinator>>:ElevatorManager

<<subsystem>>:Scheduler

<<assynchronous Input device interface>>

:ElevatorButtonsInterface

<<assynchronous inputdevice interface>>

:ArrivalSensorInterface

<<control clusering>>:ElevatorController<<subsystem>>

:FloorSubsystem

<<passive output device>>

:ElevatorLamp

<<assynchronous input device>>:ArrivalSensor

<<assynchronous input device>>:ElevatorButton

<<data abstraction>>:LocalElevatorStatus&Plan

<<control subsystem>> :ElevatorSub

system

Elevator Button Request

Arrival Sensor Input

Elevator Request

Up, Down

Approaching Floor (Floor #)

FloorLamp CommandDirectionLampCo

mmand

Elevator Lamp Output

Motor Command

Motor Response

Door Command

Door Response

Arrived (Floor #)

Departed(Floor#)

Schduler Request

Elevator Commitment

Update

Acknowledge

CheckNextDestination

CheckThis Floor(Floor#)

Arrived (Floor#)

Departed (Floor#)

Next Destination

ApproachingRequested

Floor

<<connector>>Elevator

ControllerMessageBuffer

<<connector>>directionLamp

MessageQ

<<connector>>floorLampMessageQ

<<connector>>schedulerMessageQ

<<controllClustering>>:ElevatorController

<<assynchronous input device>>:ArrivalSensorsInterface

<<coordinator>>:ElevatorManager

Receive (out elevatorControlMsg)

send(nextDirectionMsg)

send(approachingFloorMsg)

send(directionLampMsg)

send (elevatorStatusMsg)

send (floorLampMsg)

__________________________Konnektoren-Entwurf_(3)_______________________________________________Konnektoren-Entwurf_(3)_____________________

__________________________Konnektoren-Entwurf_(4)_______________________________________________Konnektoren-Entwurf_(4)_____________________

aProducerTask

aConsumerTask

Entwurf eines Message Queue Connectors (Message Buffer Connector analog):

<<connector>>aMessageQueue

send (in message)

receive (out message)

<<connector>> MessageQueue

- messageQ: Queue

+ send (in message)

+ receive (out message)

__________________________Konnektoren-Entwurf_(5)_______________________________________________Konnektoren-Entwurf_(5)_____________________

aProducerTask

aConsumerTask

Entwurf eines Message Buffer & Response Connectors:

<<connector>>aMessageBuffer

&Response

send (in message, out response)

receive (out message)

<<connector>> MessageBuffer&Response

- messageBuffer: Buffer

- responseBuffer: Buffer

+ send (in message, out response)

+ receive (out message)

+ reply (in response)

reply (in response)

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf

• (Taskstrukturierung, siehe Karstens Vortrag)

• Datenkapselungsklassen-Entwurf

• Konnektoren-Entwurf

• Task-Entwurf Zielsystemkonfigurierung

Ziel:

Genaue Festlegung der Struktur und des Nachichtenflusses innerhalb der identifizierten Tasks.

Objekte, aus denen sich ein Task u.a. zusammensetzen kann:

Ein aktives Objekt, das die Kommunikationsschnittstelle für andere Tasks bzw. Subsysteme beinhaltet ( Stereotyp <<coordinator>> )

Interface-Klassen, die den Zugriff auf externe Geräte kapseln(Stereotypen <<input device interface>> bzw. <<output device interface>>)

Ein Zustandskapselungs-Objekt, das die Logik eines zum Task gehörenden Statecharts kapselt

(Stereotyp <<state depend controll>>)

__________________________Task-Entwurf_(1)_______________________________________________Task-Entwurf_(1)_____________________

<<passive output device>>

:Door

<<passive output device>>:Motor

<<coordinator>>:ElevatorManager

<<subsystem>>:Scheduler

<<assynchronous Input device interface>>

:ElevatorButtonsInterface

<<assynchronous inputdevice interface>>

:ArrivalSensorInterface

<<control clusering>>:ElevatorController<<subsystem>>

:FloorSubsystem

<<passive output device>>

:ElevatorLamp

<<assynchronous input device>>:ArrivalSensor

<<assynchronous input device>>:ElevatorButton

<<data abstraction>>:LocalElevatorStatus&Plan

<<control subsystem>> :ElevatorSub

system

Elevator Button Request

Arrival Sensor Input

Elevator Request

Up, Down

Approaching Floor (Floor #)

FloorLamp CommandDirectionLampCo

mmand

Elevator Lamp Output

Motor Command

Motor Response

Door Command

Door Response

Arrived (Floor #)

Departed(Floor#)

Schduler Request

Elevator Commitment

Update

Acknowledge

CheckNextDestination

CheckThis Floor(Floor#)

Arrived (Floor#)

Departed (Floor#)

Next Destination

ApproachingRequested

Floor

__________________________Task-Entwurf_(2)_______________________________________________Task-Entwurf_(2)_____________________

<<coordinator>>:ElevatorCoordinator

<<timer>>:DoorTimer

<<output device interface>>:MotorInterface

<<output device interface>>

:DoorInterface

<<state depend control>>:ElevatorControl

<<output device interface>>:ElevatorLampInterface

<<control clustering>> :ElevatorCont

roller

startTimer (out timeout)

stop(out stopped)up(out started)

down(out started)

open(out opened)

closed(out closed)

offElevatorLamp(floor#)

processEvent(in event,

out action)

checkNextDestination ( out direction),

checkThisFloor( in floor#, out floorStatus, out direction),

Arrived (floor#, direction),

Departed (floor#, direction)

elevatorLampOutput

motorCommand(out motorResponse)

doorCommand (out doorResponse)

receive (out elevator ControlMsg

send(elevatorStatusMsg)

Send(floor LampMsg)

send( directionLampMsg)

__________________________Task-Entwurf_(3)_______________________________________________Task-Entwurf_(3)_____________________

Die Task-Event-Sequenz-Logik beschreibt, welche Outputs Tasks aufgrung welcher Inputs erzeugen.

__________________________Task-Entwurf_(4)_______________________________________________Task-Entwurf_(4)_____________________

Loop receive(elevatorControlMsg) from elevetorControllerMessageBuffer; case elevatorControlMsg of approachingFloorMsg:

.... nextDirectionMsg:

.... endcase;Endloop;

<<controllClustering>>:ElevatorControllerReceive (out

elevatorControlMsg)

<<connector>>Elevator

ControllerMessageBuffer

<<assynchronous input device>>:ArrivalSensorsInterface

<<coordinator>>:ElevatorManager

Send (nextDirectionMsg)

Send (approachingFloorMsg)

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf

• (Taskstrukturierung, siehe Karstens Vortrag)

• Datenkapselungsklassen-Entwurf

• Konnektoren-Entwurf

• Task-Entwurf Zielsystemkonfigurierung

Ziel:

Definition einer Instanz der verteilten Applikation für eine konkrete verteilte Umgebung

Die Zielsystem-Konfigurierung umfasst folgende Schritte:

Die benötigten Subsystem-Instanzen müssen bestimmt werden

Die benötigten Subsystem-Instanzen müssen parameterisiert werden (z.B. floorID, elevatorID)

Die benötigten Subsystem-Instanzen müssen über die Konnektoren miteinander verbunden werden

Die benötigten Subsystem-Instanzen müssen auf physikalische Knoten gemapt werden.

__________________________Zielsystemkonfigurierung_(1)____________________________________________Zielsystemkonfigurierung_(1)__________________

<< local area network >>

:FloorSubsystem{1 node per floor}

:Scheduler{1 node}

:ElevatorSubsystem{1 node per elevator}

__________________________Zielsystemkonfigurierung_(2)____________________________________________Zielsystemkonfigurierung_(2)__________________

Das haben wir gelernt:

Gliederung einer komplexen verteilten Applikation in Subsysteme:

Verteilte Applikationen werden nach bestimmten Kriterien in einzelne Subsysteme unterteilt.

Entwurf der Subsysteme:

Für jedes Subsystem wird die interne Taskstruktur festgelegt sowi die Datenkapselungsklassen, Konnektoren und Task entworfen.

Konfiguration der verteilten Applikation:

Eine entworfene verteilte Applikation wird auf eine konkrete Hardwareumgebung gemapt.