entwurf verteilter systeme max göbel. das werden wir hören : verteilte applikationen: definition...
Post on 05-Apr-2015
115 Views
Preview:
TRANSCRIPT
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.
top related