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

of 33 /33
Entwurf verteilter Systeme Max Göbel

Embed Size (px)

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

  • Folie 1
  • Entwurf verteilter Systeme Max Gbel
  • Folie 2
  • Das werden wir hren : Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung
  • Folie 3
  • __________________Verteilte Applikationen: Definition_____________________ Eine verteilte Applikation ist eine nebenlufige Applikation, die auf physikalischen Knoten an geographisch unterschiedlichen Orten ausgefhrt wird. Physikalischer Knoten2 Physikalischer Knoten1 > Beispiel: Fahrstuhl
  • Folie 4
  • _______________Entwurf verteilter Applikationen: Einleitung_________________ Ausgangspunkt: Das Analysemodell. Hier wird die Problemdomne widerspiegelt wird. Ziel: Mappen des Analysemodells auf ein Entwurfsmodell, welches die Lsungsdomne widerspiegelt. Die drei wesentlichen Schritte dabei sind: Subsystemstrukturierung Subsystementwurf Zielsystemkonfigurierung
  • Folie 5
  • Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung
  • Folie 6
  • _______________________Subsystemstrukturierung_(1)_____________________ Definition: Ein Subsystem ist eine konfigurierbare Komponente und entspricht einem logischem Knoten. Eine Komponente besteht aus nebenlufigen Tasks, die auf einem logischen Knoten ausgefhrt werden, und einem aktiven Objekt mit wohldefinierter Schnittstelle. Vorgehen: Ausgangspunkt ist das konsolidierte Kollaborationsdiagramm. Darunter versteht man eine Zusammenfassung der Kollaborationsdiagramme zu smtlichen Use-Cases. Anforderungen an Subsysteme: Geringe Kopplung zu anderen Subsystemen Starke Kopplung der Objekte innerhalb des Subsystems Eingrenzung auf eine spezielle Funktionalitt Schmale Schnittstellen zu anderen Subsystemen
  • Folie 7
  • Kriterien zur Subsystemenstrukturierung: Geographische Gegebenheiten Echtzeitanforderungen Kontakt zwischen System und externen Objekten der Auenwelt Koppelung zwischen den Objekten Daumenregeln fr die Subsystemstrukturierung: Fr ein Userinterface ein eigenes Subsystem Hufig fr 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)_____________________
  • Folie 8
  • Klassen von Subsystemen: Control Subsystem: Kontrolliert selbststndig 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 fr andere Subsysteme an User Interface Subsystem: Kapselt die Schnittstelle zum Benutzer I/O Subsystem: Kapselt smtliche Kommunikation mit der externen Umwelt System Services Subsystem Stellt nicht-problemspezifische Dienste zur Verfgung _______________________Subsystemstrukturierung_(3)_____________________
  • Folie 9
  • Beispiel Fahrstuhl: Wichtigstes Strukturierungskriterium: Geographische Gegebenheiten. Aufteilung in drei Subsysteme: Ein control subsystem fr jeden Fahrstuhl, das autonom die Hardware jedes Fahrstuhls steuert und Requests entgegennimmt (ElevatorSubsystem) Ein data collection subsystem fr jedes Stockwerk, das die Fahrstuhlanforderungen entgegennimmt (FloorSubsystem) Ein coordinator subsystem, das die verschiedenen Fahrsthle koordiniert und jeder Fahrstuhlanforderung einen Fahrstuhl zuordnet (Scheduler)_______________________Subsystemstrukturierung_(4)_____________________
  • Folie 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)_____________________
  • Folie 11
  • Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung
  • Folie 12
  • _______________________Subsystementwurf_______________________________ Ziel: Detailierter Entwurf der einzelnen Subsysteme und Spezifikation aller Klassenschnittstellen. Vorgehen: Die einzelnen Subsysteme knnen unabhngig von einander mit Methoden fr die Entwicklung Nicht-verteilter-Applikationen entwickelt werden. Der Subsystementwurf gliedert sich in folgende Schritte: Taskstrukturierung Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf
  • Folie 13
  • Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung
  • Folie 14
  • _______________________Taskstrukturierung_(1)_________________________ Definition: Ein Task ist ein aktives Objekt mit eigenem Kontrollflu. Ein Task reprsentiert die Ausfhrung eines sequentiellen Programms oder einer sequentiellen Komponente eines nebenlufigen Programms. Jeder Task hat einen sequentiellen Kontrollflu. Es gibt keine Nebenlufigkeit innerhalb eines Tasks. Ziel: Strukturierung der Subsysteme in Tasks und Datenkapselungsklassen. Das objektorientierte Analysemodell wird auf eine nebenlufige Taskarchitektur gemappt. Vorgehensweise: Streng geheim (siehe Karstens Vortrag)
  • Folie 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)_________________________
  • Folie 16
  • Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung
  • Folie 17
  • __________________Datenkapselungsklassen-Entwurf_(1)___________________ Definition: Datenkapselungsklassen sind Klassen, deren Objekte von unterschiedlichen Tasks aus benutzt werden und deren Aufgabe darin besteht, eine einheitliche Schnittstelle fr den Zugriff auf bestimmte Daten anzubieten, sowie die innere Struktur der Daten fr 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 hinzufgen Jede Nachicht, die ein Objekt der betreffenden Klasse als empfngt, als Methode der Klasse im Klassendiagramm bernehmen.
  • Folie 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)
  • Folie 19
  • Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung
  • Folie 20
  • Definition: Ein Konnektor ist ein Objekt, dass die Kommunikationslogik fr die Kommunikation zwischen zwei Tasks kapselt. Mgliche Kommunikationsarten zwischen Tasks Asynchrone Kommunikation: Der Sender arbeitet sofort nach dem Senden weiter. Synchrone Kommunikation ohne Rckgabeparameter: Der Sender wartet, bis der Empfnger die Nachricht empfangen hat. Synchrone Kommunikation mit Rckgabeparamter: Der Sender wartet, bis der Empfnger die Nachricht empfangen und die Antwort zurckgeschickt hat. Verschieden Klassen von Konnektoren: Message Queue Connector: Kapselt den Kommunikationsmechanismus fr 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 fr synchrone Kommunikation ohne Rckgabeparameter. Message Buffer & Response Connector: Kapselt den Kommunikations- mechanismus fr synchrone Kommunikation mit Rckgabeparameter.__________________________Konnektoren-Entwurf_(1)_____________________
  • Folie 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
  • Folie 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)_____________________
  • Folie 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)
  • Folie 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)
  • Folie 25
  • Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung
  • Folie 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 fr andere Tasks bzw. Subsysteme beinhaltet ( Stereotyp > ) Interface-Klassen, die den Zugriff auf externe Gerte kapseln (Stereotypen > bzw. >) Ein Zustandskapselungs-Objekt, das die Logik eines zum Task gehrenden Statecharts kapselt (Stereotyp >)__________________________Task-Entwurf_(1)_____________________
  • Folie 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)_____________________
  • Folie 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)_____________________
  • Folie 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)
  • Folie 30
  • Verteilte Applikationen: Definition Entwurf verteilter Applikationen: Einleitung Subsystemstrukturierung Subsystementwurf (Taskstrukturierung, siehe Karstens Vortrag) Datenkapselungsklassen-Entwurf Konnektoren-Entwurf Task-Entwurf Zielsystemkonfigurierung
  • Folie 31
  • Ziel: Definition einer Instanz der verteilten Applikation fr eine konkrete verteilte Umgebung Die Zielsystem-Konfigurierung umfasst folgende Schritte: Die bentigten Subsystem-Instanzen mssen bestimmt werden Die bentigten Subsystem-Instanzen mssen parameterisiert werden (z.B. floorID, elevatorID) Die bentigten Subsystem-Instanzen mssen ber die Konnektoren miteinander verbunden werden Die bentigten Subsystem-Instanzen mssen auf physikalische Knoten gemapt werden.__________________________Zielsystemkonfigurierung_(1)__________________
  • Folie 32
  • > :FloorSubsystem {1 node per floor} :Scheduler {1 node} :ElevatorSubsystem {1 node per elevator}__________________________Zielsystemkonfigurierung_(2)__________________
  • Folie 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: Fr 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.