 | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Wissensbrowser starten | ||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||
|  | |  | |  | |
| ||||||
| ||||||
|  | | ||||
| ||||||
Verfahren |
|
Verhalten: UML-RT Statecharts |
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| Beschreibung | |||||||||
| |||||||||
| Das Verhalten von Komponenten wird in der UML-RT wie in der Standard-UML mit Statecharts beschrieben. Die benutzte Statechart-Variante hat zwar ein sehr ähnliches Aussehen, aber es ergeben sich wesentliche Unterschiede in der Modellierung.
Komponenten kommunizieren in der UML-RT ausschließlich asynchron durch den gepufferten Austausch von Nachrichten. Der Empfänger kann die Bearbeitung einer Nachricht verzögern, und der Sender wird nicht bis zum Eintreffen einer Antwort – wie bei einem Methodenaufruf – blockiert. 
Die erste Abbildung zeigt das UML-RT Statechart der Klasse Automatisierungskomponente, die als Ausgangspunkt der Entwicklung der Klasse Ablaufsteuerung dient. Es definiert mehrere Betriebs-Zustände. Die Transitionen sind mit Markierungen beschriftet, die dem Betrachter das intuitive Verständnis erleichtern sollen. Transitionen werden in der UML-RT sehr detailliert spezifiziert, zugunsten der Übersichtlichkeit jedoch nicht direkt im Diagramm. Die Transition "status" im Beispiel wird durch die gleichnamige Nachricht getriggert und umfasst als Aktion das Senden der Nachricht automatik. UML-RT Statecharts können durch die Verfeinerung von Zuständen in Sub-Statecharts hierarchisch strukturiert werden. 
Die Komponente Ablaufsteuerung, die das Verhalten der Automatisierungskomponente erbt, verfeinert in der zweiten Abbildung den Zustand Automatikbetrieb, um die Montageaufgabe zu realisieren. Obwohl dieses Sub-Statechart ähnlich wie das Statechart in UML 1.x strukturiert ist, weisen die Diagramme wesentliche Unterschiede auf: Während im normalen UML Statechart die gesamte Ablauflogik in Methodenaufrufen wie montiereC() konzentriert ist, wird der Montageablauf hier durch einen wechselseitigen Nachrichtenaustausch realisiert. Dadurch ist die Ablaufsteuerung während der Montage nicht blockiert. Dies wird in der zweiten Abbildung ausgenutzt, um auf Störungen der Mechanik zu reagieren: Für jede Aktion wird ein Timeout gesetzt, der nach Ablauf einer Wartezeit in einen Fehlerzustand führt, falls die Aktion noch nicht beendet ist. Dieses Beispiel macht den Einsatzbereich von Timern deutlich: Sie stellen keine Garantie für die Einhaltung von Echtzeitanforderungen dar, ermöglichen aber, auf den Fortschritt von Zeit zu reagieren. Das Beispiel zeigt einen typischen Einsatz von UML-RT Statecharts: Sie stellen eine abstrakte Modellierung des Komponentenverhaltens dar, während Details in einer Programmiersprache wie z.B. C realisiert werden. In der zweiten Abbildung wird die Umsetzung von Befehlen der Montageanleitung in Positionsbefehle für die einzelnen Achsen in der Methode BerechneAchsen durchgeführt. Das Beispiel zeigt ein weiteres wichtiges Merkmal: Transition points definieren eine klare Schnittstelle zwischen Statecharts und Sub-Statecharts. Dadurch werden die Ebenen in der zweiten Abbildung entkoppelt. | |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
Eintrag kommentieren | ||||
| ||||
 | Übergeordnet | | ||
| ||||
|
| | ||
| ||||
| ||||
| ||||
| ||||
| Verhalten: UML-RT Statecharts | ||||
| ||||
| ||||
| ||||
| ||||
| Weitere Themen | | ||
| ||||
|
| | ||
| ||||
| ||||
| | | ||
| ||||||||||||||
|
