Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Entwurf verteilter Systeme Max Göbel. Das werden wir hören : Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung."—  Präsentation transkript:

1 Entwurf verteilter Systeme Max Göbel

2 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

3 __________________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 > Beispiel: Fahrstuhl

4 _______________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

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

6 _______________________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

7 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)_____________________

8 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)_____________________

9 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)_____________________

10 > :ElevatorControl System <> :FloorSubsystem <> :Scheduler <> :ElevatorSubsystem <> :ElevatorButton <> :DirectionLamp <> :FloorLamp <> :FloorButton <> :ElevatorLamp <> :ArrivalSensor <> :Motor <> :Door FloorLamp Command DirectionLamp Command Arrival (Floor#) Departed (Floor#) Elevator Commitment Scheduler Request Service Request Floor Lamp Output Floor Button Request Motor Response Motor Command Elevator Button Request Elevator Lamp Output Arrival Sensor Input Door Response Door Command Direction LampOutput_______________________Subsystemstrukturierung_(5)_____________________

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

12 _______________________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

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

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

15 <> :Door <> :Motor > :ElevatorManager > :Scheduler <> :ElevatorButtons Interface <> :ArrivalSensorInterface > :ElevatorController > :FloorSubsystem <> :ElevatorLamp <> :ArrivalSensor <> :ElevatorButton > :LocalElevator Status&Plan > :ElevatorSubsystem Elevator Button Request Arrival Sensor Input Elevator Request Up, Down Approaching Floor (Floor #) FloorLamp Command DirectionLampCo mmand Elevator Lamp Output Motor Command Motor Response Door Command Door Response Arrived (Floor #) Departed (Floor#) Schduler Request Elevator Commitment Update Acknowledge CheckNext Destination CheckThis Floor(Floor#) Arrived (Floor#) Departed (Floor#) Next Destination Approaching Requested Floor_______________________Taskstrukturierung_(2)_________________________

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

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

18 1. Schritt__________________Datenkapselungsklassen-Entwurf_(2)___________________ <> :Elevator Controller <> :LocalElevator Status&Plan > :Elevator Manager Approaching Requested Floor Acknowledge Update Next Destination CheckNext Desination CheckThis Floor(Floor #) Arrived (Floor #) Departed (Floor #) 2. Schritt <> :Elevator Controller <> :LocalElevator Status&Plan > :Elevator Manager updatePlan(floor#, direction, out idleStatus) checkNextDestination( out direction) checkThisFloor( in floor#, out floorStatus, out direction) arrived(floor#, direction) departed(floor#, direction) 3. Schritt > LocalElevatorStatus&Plan + arrived (floor#, direction) + departed (floor#, direction) + checkThisFloor (in floor#, out floorStatus, out direction) + checkNextDestination (out direction) + updatePlan (floor#, direction, out idleStatus)

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

20 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)_____________________

21 __________________________Konnektoren-Entwurf_(2)_____________________ <> :Door <> :Motor > :ElevatorManager > :Scheduler <> :ElevatorButtons Interface <> :ArrivalSensorInterface > :ElevatorController > :FloorSubsystem <> :ElevatorLamp <> :ArrivalSensor <> :ElevatorButton > :LocalElevator Status&Plan > :ElevatorSubsystem Elevator Button Request Arrival Sensor Input Elevator Request Up, Down Approaching Floor (Floor #) FloorLamp Command DirectionLampCo mmand Elevator Lamp Output Motor Command Motor Response Door Command Door Response Arrived (Floor #) Departed (Floor#) Schduler Request Elevator Commitment Update Acknowledge CheckNext Destination CheckThis Floor(Floor#) Arrived (Floor#) Departed (Floor#) Next Destination Approaching Requested Floor

22 > Elevator Controller MessageBuffer > directionLamp MessageQ > floorLamp MessageQ > scheduler MessageQ <> :Elevator Controller <> :ArrivalSensors Interface > :Elevator Manager Receive (out elevatorControlMsg) send(nextDirectionMsg) send(approachingFloorMsg) send(directionLampMsg) send (elevatorStatusMsg) send (floorLampMsg)__________________________Konnektoren-Entwurf_(3)_____________________

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

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

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

26 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 > ) Interface-Klassen, die den Zugriff auf externe Geräte kapseln (Stereotypen > bzw. >) Ein Zustandskapselungs-Objekt, das die Logik eines zum Task gehörenden Statecharts kapselt (Stereotyp >)__________________________Task-Entwurf_(1)_____________________

27 <> :Door <> :Motor > :ElevatorManager > :Scheduler <> :ElevatorButtons Interface <> :ArrivalSensorInterface > :ElevatorController > :FloorSubsystem <> :ElevatorLamp <> :ArrivalSensor <> :ElevatorButton > :LocalElevator Status&Plan > :ElevatorSubsystem Elevator Button Request Arrival Sensor Input Elevator Request Up, Down Approaching Floor (Floor #) FloorLamp Command DirectionLampCo mmand Elevator Lamp Output Motor Command Motor Response Door Command Door Response Arrived (Floor #) Departed (Floor#) Schduler Request Elevator Commitment Update Acknowledge CheckNext Destination CheckThis Floor(Floor#) Arrived (Floor#) Departed (Floor#) Next Destination Approaching Requested Floor__________________________Task-Entwurf_(2)_____________________

28 > :ElevatorCoordinator > :DoorTimer > :MotorInterface <> :DoorInterface > :ElevatorControl > :ElevatorLampInterface > :ElevatorController 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(elevator StatusMsg) Send(floor LampMsg) send( directionL ampMsg)__________________________Task-Entwurf_(3)_____________________

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

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

31 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)__________________

32 > :FloorSubsystem {1 node per floor} :Scheduler {1 node} :ElevatorSubsystem {1 node per elevator}__________________________Zielsystemkonfigurierung_(2)__________________

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


Herunterladen ppt "Entwurf verteilter Systeme Max Göbel. Das werden wir hören : Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung."

Ähnliche Präsentationen


Google-Anzeigen