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

<<local area network>> __________________Verteilte Applikationen: Definition_____________________ Eine verteilte Applikation ist eine nebenläufige Applikation, die auf physikalischen Knoten an geographisch unterschiedlichen Orten ausgeführt wird. Beispiel: Fahrstuhl Physikalischer Knoten1 <<local area network>> Physikalischer Knoten2

_______________Entwurf verteilter Applikationen: 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

Anforderungen an Subsysteme: _______________________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: _______________________Subsystemstrukturierung_(2)_____________________ 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

Klassen von Subsystemen: _______________________Subsystemstrukturierung_(3)_____________________ 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

Aufteilung in drei Subsysteme: _______________________Subsystemstrukturierung_(4)_____________________ 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_(5)_____________________ <<external input Device>> :ElevatorButton <<external input device>> :ArrivalSensor <<external output device>> :ElevatorLamp ElevatorLamp Output <<external output device>> :DirectionLamp ArrivalSensor Input ElevatorButton Request Motor Command Direction LampOutput <<system>> :ElevatorControl System <<external output device>> :Motor <<control Subsystem>> :ElevatorSubsystem Motor Response <<external output device>> :FloorLamp Arrival (Floor#) DirectionLamp Command SchedulerRequest Departed(Floor#) Floor Lamp Output FloorLampCommand Door Command Elevator Commitment <<coordinator subsystem>> :Scheduler <<data collection subsystem>> :FloorSubsystem <<external input device>> :FloorButton Door Response <<external output device>> :Door Service Request Floor ButtonRequest

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung

_______________________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)_________________________ 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)

_______________________Taskstrukturierung_(2)_________________________ <<control subsystem>> :ElevatorSubsystem Elevator Lamp Output <<control clusering>> :ElevatorController <<subsystem>> :FloorSubsystem <<passive output device>> :ElevatorLamp DirectionLampCommand FloorLamp Command Approaching Floor (Floor #) Door Command Arrival Sensor Input Motor Command <<assynchronous input device interface>> :ArrivalSensorInterface Motor Response Next Destination Departed (Floor#) <<assynchronous input device>> :ArrivalSensor <<passive output device>> :Motor ApproachingRequested Floor Arrived (Floor#) Up, Down Door Response CheckThis Floor(Floor#) <<passive output device>> :Door <<assynchronous Input device interface>> :ElevatorButtons Interface CheckNextDestination Elevator Button Request <<data abstraction>> :LocalElevator Status&Plan Departed(Floor#) Update Arrived (Floor #) <<assynchronous input device>> :ElevatorButton Elevator Request Schduler Request <<subsystem>> :Scheduler Acknowledge <<coordinator>> :ElevatorManager Elevator Commitment

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung

__________________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.

__________________Datenkapselungsklassen-Entwurf_(2)___________________ 1. Schritt <<controll Clustering>> :Elevator Controller <<data Abstraction>> :LocalElevator Status&Plan <<coordinator>> Manager Approaching Requested Floor Acknowledge Update Next Destination CheckNext Desination CheckThis Floor(Floor #) Arrived (Floor #) Departed (Floor #) 2. Schritt updatePlan(floor#, direction, out idleStatus) checkNextDestination( out direction) arrived(floor#, direction) <<controll Clustering>> :Elevator Controller <<data Abstraction>> :LocalElevator Status&Plan <<coordinator>> :Elevator Manager checkThisFloor( in floor#, out floorStatus, out 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

__________________________Konnektoren-Entwurf_(1)_____________________ 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_(2)_____________________ <<control subsystem>> :ElevatorSubsystem Elevator Lamp Output <<control clusering>> :ElevatorController <<subsystem>> :FloorSubsystem <<passive output device>> :ElevatorLamp DirectionLampCommand FloorLamp Command Approaching Floor (Floor #) Door Command Arrival Sensor Input Motor Command <<assynchronous input device interface>> :ArrivalSensorInterface Motor Response Next Destination Departed (Floor#) <<assynchronous input device>> :ArrivalSensor <<passive output device>> :Motor ApproachingRequested Floor Arrived (Floor#) Up, Down Door Response CheckThis Floor(Floor#) <<passive output device>> :Door <<assynchronous Input device interface>> :ElevatorButtons Interface CheckNextDestination Elevator Button Request <<data abstraction>> :LocalElevator Status&Plan Departed(Floor#) Update Arrived (Floor #) <<assynchronous input device>> :ElevatorButton Elevator Request Schduler Request <<subsystem>> :Scheduler Acknowledge <<coordinator>> :ElevatorManager Elevator Commitment

__________________________Konnektoren-Entwurf_(3)_____________________ <<connector>> directionLamp MessageQ <<assynchronous input device>> :ArrivalSensors Interface send(directionLampMsg) send(approachingFloorMsg) send (floorLampMsg) <<connector>> Elevator Controller MessageBuffer <<controll Clustering>> :Elevator Controller <<connector>> floorLamp MessageQ Receive (out elevatorControlMsg) send(nextDirectionMsg) send (elevatorStatusMsg) <<connector>> scheduler MessageQ <<coordinator>> :Elevator Manager

__________________________Konnektoren-Entwurf_(4)_____________________ Entwurf eines Message Queue Connectors (Message Buffer Connector analog): aProducerTask send (in message) <<connector>> MessageQueue <<connector>> aMessageQueue - messageQ: Queue receive (out message) + send (in message) + receive (out message) aConsumerTask

__________________________Konnektoren-Entwurf_(5)_____________________ Entwurf eines Message Buffer & Response Connectors: aProducerTask send (in message, out response) <<connector>> MessageBuffer&Response <<connector>> aMessageBuffer &Response messageBuffer: Buffer responseBuffer: Buffer receive (out message) + send (in message, out response) + receive (out message) + reply (in response) reply (in response) aConsumerTask

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung

__________________________Task-Entwurf_(1)_____________________ 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_(2)_____________________ <<control subsystem>> :ElevatorSubsystem Elevator Lamp Output <<control clusering>> :ElevatorController <<subsystem>> :FloorSubsystem <<passive output device>> :ElevatorLamp DirectionLampCommand FloorLamp Command Approaching Floor (Floor #) Door Command Arrival Sensor Input Motor Command <<assynchronous input device interface>> :ArrivalSensorInterface Motor Response Next Destination Departed (Floor#) <<assynchronous input device>> :ArrivalSensor <<passive output device>> :Motor ApproachingRequested Floor Arrived (Floor#) Up, Down Door Response CheckThis Floor(Floor#) <<passive output device>> :Door <<assynchronous Input device interface>> :ElevatorButtons Interface CheckNextDestination Elevator Button Request <<data abstraction>> :LocalElevator Status&Plan Departed(Floor#) Update Arrived (Floor #) <<assynchronous input device>> :ElevatorButton Elevator Request Schduler Request <<subsystem>> :Scheduler Acknowledge <<coordinator>> :ElevatorManager Elevator Commitment

__________________________Task-Entwurf_(3)_____________________ <<control clustering>> :ElevatorController <<output device interface>> :MotorInterface motorCommand(out motorResponse) <<timer>> :DoorTimer down(out started) receive (out elevator ControlMsg stop(out stopped) up(out started) startTimer (out timeout) <<output device interface>> :DoorInterface open(out opened) closed(out closed) doorCommand (out doorResponse) send(elevatorStatusMsg) <<coordinator>> :ElevatorCoordinator offElevatorLamp(floor#) <<output device interface>> :ElevatorLampInterface Send(floor LampMsg) checkNextDestination ( out direction), elevatorLampOutput processEvent(in event, out action) checkThisFloor( in floor#, out floorStatus, out direction), <<state depend control>> :ElevatorControl send( directionLampMsg) Arrived (floor#, direction), Departed (floor#, direction)

__________________________Task-Entwurf_(4)_____________________ Die Task-Event-Sequenz-Logik beschreibt, welche Outputs Tasks aufgrung welcher Inputs erzeugen. Send (approachingFloorMsg) <<assynchronous input device>> :ArrivalSensors Interface <<connector>> Elevator Controller MessageBuffer <<controll Clustering>> :Elevator Controller Receive (out elevatorControlMsg) Send (nextDirectionMsg) <<coordinator>> :Elevator Manager Loop receive(elevatorControlMsg) from elevetorControllerMessageBuffer; case elevatorControlMsg of approachingFloorMsg: .... nextDirectionMsg: endcase; Endloop;

Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung

Die Zielsystem-Konfigurierung umfasst folgende Schritte: 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.

<< local area network >> __________________________Zielsystemkonfigurierung_(2)__________________ :ElevatorSubsystem {1 node per elevator} << local area network >> :Scheduler {1 node} :FloorSubsystem {1 node per floor}

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.