In diesem Dokument, das im Rahmen der Lehrveranstaltung Embedded Systems an der Fachhochschule in Wiesbaden entstanden ist, wird auf die Echtzeiterweiterungen in UML 2.0 bzw. UML-RT ein. Es ist von Vorteil wenn Sie mit UML vertraut sind, da sich das Verstehen sonst teilweise etwas kompliziert darstellt.
Das Dokument ist zweigeteilt zu betrachten. Zum ersten sind ca. zwanzig Seiten, die sich mit den Erweiterungen und Notationen für UML beschäftigen wie z.B. neue Notationen für das Sequenzdiagramm oder aber auch den vollkommen neuen Diagrammtypen des Timingdiagramms. Im Anschluss daran werden die bisher in UML-RT verwendeten Erweiterungen mit ihren neuen Gegenstücken in UML 2.0 verglichen und es wird noch kurz auf den Mechanismus der Profiles und im Speziellen auf das Profile for Schedulability, Performance, and Time eingegangen. Im zweiten Teil des Dokuments sind sämtliche Stereotypen, die als Erweiterungen für UML im Profile for Schedulability, Performance, and Time sind aufgelistet.
Inhaltsverzeichnis:
Einführung:
Sequenzdiagramm:
Duration Observation:
Duration Constraint:
Time Observation:
Time Constraint:
Timingdiagramm:
1. Form
2. Form
3. Form
Notationen:
Vergleich UML - RT in UML 2.0:
UML-RT:
Capsules
Ports:
Connectoren:
Protokolle:
Statecharts:
UML 2.0 :
Komponenten:
Ports
Connectoren:
Signale:
Interfaces:
Statecharts:
Profiles:
Profile for Schedulability, Performance and Time:
RTresourceModeling:
<<GRMacquire>>
<<GRMcode>>
<<GRMdeploys>>
<<GRMrealize>>
<<GRMrelease>>
<<GRMrequires>>
Tagged Values:
RTtimeModeling
<<RTaction>>
<<RTclkInterrupt>>
<<RTclock>>
<<RTdelay>>
<<RTevent>>
<<RTinterval>>
<<RTnewClock>>
<<RTnewTimer>>
<<RTpause>>
<<RTreset>>
Christian H. Becker Seite
christian.h.becker@t-online.de
Liste V Embedded Systems WS 03/
<<RTset>>
<<RTstart>>
<<RTstimulus>>
<<RTtime>>
<<RTtimeout>>
<<RTtimer>>
<<RTtimeService>>
<<RTtimingMechanism>>
Tagged Values:
RTconcurrencyModeling
<<CRaction>>
<<CRasynch>>
<<CRconcurrent>>
<<CRcontains>>
<<CRdeferred>>
<<CRimmediate>>
<<CRmsgQ>>
<<CRsynch>>
SAprofile
<<SAengine>>
<<SAowns>>
<<SAprecedes>>
<<SAresource>>
<<SAresponse>>
<<SAschedRes>>
<<SAscheduler>>
<<SAsituation>>
<<SAtrigger>>
<<SAusedHost>>
<<SAuses>>
PAprofile
<<PAclosedLoad>>
<<PAcontext>>
<<PAhost>>
<<PAopenLoad>>
<<PAresource>>
<<PAstep>>
Tagged Values:
RSAprofile
<<RSAchannel>>
<<RSAclient>>
<<RSAconnection>>
<<RSAmutex>>
<<RSAorb>>
<<RSAserver>>
Quellenangabe:...
Einführung:
Im folgenden Dokument, das im Rahmen der Lehrveranstaltung Embedded Systems an der Fachhochschule in Wiesbaden entstanden ist, gehe ich auf die Echtzeiterweiterungen in UML 2.0 bzw. UML-RT ein. Es ist von Vorteil wenn sie mit UML vertraut sind, da sich das Verstehen sonst teilweise etwas kompliziert darstellt.
Das Dokument ist zweigeteilt zu betrachten.
Zum ersten sind ca. zwanzig Seiten, die sich mit den Erweiterungen und Notationen für UML beschäftigen wie z.B. neue Notationen für das Sequenzdiagramm oder aber auch den vollkommen neuen Diagrammtypen des Timingdiagramms. Im Anschluss daran habe ich die bisher in UML-RT verwendeten Erweiterungen mit ihren neuen Gegenstücken in UML 2.0 verglichen und gehe noch kurz auf den Mechanismus der Profiles und im Speziellen auf das Profile for Schedulability, Performance, and Time ein.
Im zweiten Teil des Dokuments sind sämtliche Stereotypen, die als Erweiterungen für UML im Profile for Schedulability, Performance, and Time sind aufgelistet.
Sequenzdiagramm:
Das aus UML 1.x bereits bekannte Sequenzdiagramm wurde um Notationen erweitert, die es einem ermöglichen zeitliche Aspekte im Diagramm zu modellieren. Diese Erweiterung ist nicht extra für Echtzeitanwendungen gedacht bietet jedoch eine Möglichkeit einige Anforderungen darzustellen. Bei den Erweiterungen handelt es sich um vier an der Zahl.
1) Duration Observation
2) Duration Constraint
3) Time Observation
4) Time Constraint
Duration Observation:
Diese Notation wird verwendet um eine Dauer zu überwachen / messen. Das bedeutet man kann damit die Dauer der Übertragung einer Nachricht messen / überwachen. Diese Dauer wird im Bild unten mit „d“ gekennzeichnet.
Duration Constraint:
Mit dieser Notation wird eine einzuhaltende Zeitspanne vorgegeben. Damit will ich sagen, dass wie im Bild unten der Vorgang zwischen „d“ und maximal „3*d“ abgeschlossen sein muss. Mit Vorgang ist alles zwischen den Markierungen gemeint.
Abbildung in dieser Leseprobe nicht enthalten
Time Observation:
Diese Notation wird verwendet, um von einem Zeitpunkt „t“ aus den zeitlichen Verlauf zu überwachen. Beim Bild oben wird damit ein Zeitpunkt „t“ bestimmt ab dem der zeitliche Verlauf überwacht wird.
Time Constraint:
Diese Notation wird verwendet, um eine Zeitspanne zu definieren die ab dem Zeitpunkt „t“ eingehalten werden muss. Im Bild ist dies frühestens „t“ und spätestens „t+3“ wobei mit „3“ drei Zeiteinheiten gemeint sind.
Auf die Standardnotationen gehe ich hier nicht ein, da diese aus UML 1.X bekannt sein sollten.
Timingdiagramm:
Das Timingdiagramm ist ein Diagrammtyp der in UML 2.0 erstmals verwendet wird. Es stammt aus dem Elektro-Ingenieurwesen und dient dazu das Verhalten einer Instanz im zeitlichen Verlauf zu sehen. Die im Kapitel Sequenzdiagramm erklärten Notationen wie Duration Constraint, Time Observation, Duration Observation und Time Constraint können auch hier verwendet werden. Zur genaueren Erläuterung bitte ich sie in diesem Kapitel nachzulesen. Ein Timingdiagramm kann in drei Formen dargestellt werden.
1. Form
Abbildung in dieser Leseprobe nicht enthalten
Das Diagramm oben zeigt eine Instanz der Klasse User mit den Zuständen Idle, WaitCard und WaitAccess. Dadurch wird auch ein weiterer Unterschied zum Sequenzdiagramm deutlich, nämlich das Anzeigen von Zuständen. Die tick mark values und der timing ruler sind Notationen um den zeitlichen Verlauf einzuteilen, darzustellen und Zeitmarken zu setzen. Die Bezeichner Code, CardOut und OK sind Messages, wie im Sequenzdiagramm.
2. Form
Abbildung in dieser Leseprobe nicht enthalten
Diese Darstellungsform wird verwendet um Nachrichtenlose Zustandsübergänge auch mit Zeitverlauf darzustellen. Die Zustände werden im inneren der Lifeline gezeichnet und das Kreuzen der beiden Außenlinien zeigt eine Zustandsänderung der Instanz an.
3. Form
Abbildung in dieser Leseprobe nicht enthalten
Diese Form ist eigentlich identisch mit der 1. allerdings zeigt sie zwei Klassen im Verhalten zueinander.
Abbildung in dieser Leseprobe nicht enthalten
Die Grafiken auf dieser Seite sind alle von[1]
Vergleich UML - RT in UML 2.0:
Auf den folgenden Seiten werde ich die Echtzeiterweiterung UML-RT kurz erläutern und anschließend aufzeigen, wie diese in UML 2.0 umgesetzt wurden.
UML-RT:
UML-RT wurde 1999 erstmals in UML 1.1 eingebracht. Nicht in der Standartnotation sondern als Erweiterung. Alle in diesem Teil erklärten Notationen sind in UML-RT definiert. UML-RT wurde verwendet um UML zur Echtzeitmodellierung verwenden zu können. Die Definitionen wurden größtenteils von ROOM übernommen. Daher stammt auch der Name UMLRT, welcher vom Tool ROSE-RT abgeleitet wurde.
Capsules
Jede Capsule repräsentiert ein potentiell aktives Objekt, welches entweder für sich alleine stehen kann oder aber stark hierarchisch in Subcapsules gekapselt ist. Bei einer solchen Schachtelung delegiert die Muttercapsule sozusagen die Subcapsules. Die Kommunikation zwischen Capsules, egal ob Extern oder Intern, geschieht ausschließlich durch gepufferten asynchronen Nachrichtenaustausch der über Ports geschieht. Sollte der Port beim eintreffen einer Nachricht gerade blockiert sein, wird diese in einer Queue gespeichert bis sie bearbeitet werden kann. Das Verhalten einer Capsule wird mittels eines Statecharts definiert. Der aus ROOM bekannte Name Actor wurde in UML-RT nicht verwendet, da es zu Konflikten mit dem im Use Case Modell verwendeten Actor geführt hätte.
Abbildung in dieser Leseprobe nicht enthalten
Die Grafik zeigt eine Capsule CLS mit den Subcapsules CommandHandler und MotorControl, die über Ports mit der Muttercapsule oder anderen Externen Capsules verbunden sind. Auf die Port Typen gehe ich in der Erläuterung Ports ein.
Ports:
Ports sind wie im Kapitel Capsules beschrieben der Kommunikationsweg der Capsule. Obwohl jede Capsule mehrere Ports haben kann, kann ein Port nur ausschließlich zu einer Capsule gehören. Der Port erwartet und versendet die Signale nach einem fest definierten Protokoll. Darauf wird im Kapitel Protokoll eingegangen. Es gibt zwei Arten von Ports und zwar die Relay Ports und die End Ports.
Die Grafik zeigt wo der Unterschied zwischen den beiden Porttypen ist. Während der End Port zur Kommunikation mit der Capsule zu der er gehört dient, wird der Relay Port dazu verwendet die Nachrichten an Subcapsules weiterzuleiten oder umgekehrt. Dadurch kann die Subcapsule ihrerseits mit der Muttercapsule kommunizieren.
Connectoren:
Connectoren sind der definierte Übermittlungsweg für Nachrichten zwischen Ports. Ports die nicht über Connectoren miteinander verbunden sind können auch nicht miteinander kommunizieren.
Protokolle:
Das Protokoll ist eine unabhängige Einheit die einem Port zwar zugeteilt sein muss aber in einem System mehrmals verwendet werden kann. In einem Protokoll sind die Eingangs- und Ausgangssignale definiert, die dieser Port sendet bzw. erwartet. Sollte an einem Port ein nicht definiertes Signal ankommen, kann dieser dieses nicht verarbeiten. Das Protokoll am Ende eines Connectors muss also das invertierte Protokoll dessen am anderen Ende sein. Ein invertierter Port bzw. ein Port mit invertiertem Protokoll ist im Bild oben in weiß gehalten, während der Gegenport in schwarz dargestellt wird.
Die Grafik zeigt ein binäres Protokoll mit dem Namen ProtModi. Die erlaubten Eingangssignale sind in der incoming Sektion beschrieben und die Ausgangssignale in der Sektion outgoing. Rechts neben dem Protokoll ist ein anderes Protokoll namens ProtRoboterModi welches vom Protokoll ProtModi erbt.[2]
Abbildung in dieser Leseprobe nicht enthalten
UML 2.0 :
UML 2.0 ist ein von der OMG zurzeit noch nicht verabschiedeter Draft, der allerdings für das erste Quartal 2004 angekündigt ist. Die Informationen in diesem Abschnitt stützen sich in erster Linie auf den UML 2.0 Superstructure Draft der unter www.omg.org zu beziehen ist.
Komponenten:
Die Komponenten in UML 2.0 entsprechen den Capsules in UML-RT. Es handelt sich dabei um Klassen die auch aktiv sein können. Auch bei Komponenten gibt es die Möglichkeit sie hierarchisch zu verschachteln wo die Signale über Connectors oder Interfaces zu den Unterkomponenten delegiert werden. Die Funktionalität von Komponenten ist weitaus größer als die von Capsules allerdings findet dies im Themengebiet Echtzeit keine Anwendung.
Die Grafik zeigt die für Komponenten
vorgesehene Notation. Entweder mit
Französischen Anführungszeichen oder mit dem Symbol in der rechten oberen Ecke. Mir sind im Laufe meiner Recherche auch einige Varianten mit beiden gleichzeitig begegnet.
Ports
Abbildung in dieser Leseprobe nicht enthalten
Wie bei UML-RT gibt es auch in UML 2.0 Ports. Allerdings ist es hier nicht so, dass der Port den einzigen Kommunikationsweg der Komponente darstellt. Eine Komponente kann auch direkt mit einem Interface verbunden sein oder auch mit einem Connector. Jedoch gilt hier, dass ein Port nur genau einer Komponente gehört. Es gibt auch in UML 2.0 drei verschiedene Arten von Ports. Erstens die Standard Ports, zweitens die komplexen Ports und drittens die behave Ports. Der Standard Port (links mit Interface) der sowohl eine Eingangsqueue als auch einen Ausgang hat, kann mit Interfaces verbunden werden oder[1] auch mit Connectoren. Die zweite Art der Ports ist der komplexe Port (rechts mit drei Interfaces). Dieser hat die Möglichkeit mehrere Interfaces gleichzeitig zu versorgen. Im Normalfall hat ein Port nur ein Eingangs- und ein Ausgangsinterface. Die dritte und letzte Art der Ports ist der behave Port. Dieser Port gehört der Komponente selbst an, in der er modelliert wird. Zum Beispiel die Komponente X kommuniziert mit der Komponente Y über den Connector XbiY. Um dies darzustellen wird in einem Architekturdiagramm eine Komponente Y modelliert. Auf der anderen Seite wird nur ein behave Port modelliert, da das Diagramm der Komponente X angehängt ist.
Connectoren:
Connectoren
übertragen die Signale zwischen den Ports und zeigen damit die Kommunikationswege der Komponente.
Connectoren können sowohl uni- als auch bidirektional sein. Dies wird durch Pfeile am Ende der Connectoren entweder in Flussrichtung oder entgegengesetzt gekennzeichnet. Die Grafik rechts zeigt einen bidirektionalen Connector CtrlbiHw, der die 0 Komponente Ctrl, die eine Instanz von Controller ist und Hw, die eine Instanz von Hardware ist, über die Ports P3 und P4 miteinander verbindet.
Signale:
Signale werden über Connectoren oder Interfaces an Ports bzw. deren Komponente übermittelt. Signale werden in einem Signaldiagramm definiert und können anschließend innerhalb des Systems beliebig oft an verschiedenen Stellen wieder verwendet werden. Signale können Parameter haben die im Signaldiagramm definiert sein müssen.
Interfaces:
Interfaces sind Schnittstellen zu Bedienern oder Sensoren oder auch zu anderen Interfaces. Sollte ein Interface direkt mit einem anderen verbunden sein nennt man das Assembly Connector. Es versteht sich natürlich, dass dafür die beiden Interfaces von unterschiedlichem Typ sein müssen. Es gibt nämlich zwei Arten von Interfaces. Erstens das Requires Interface, welches Nachrichten versendet und zweitens Realises Interface, welches Nachrichten empfängt. In der Grafik ist das Requires Interface das Interface ToUser und das Realises Interface das Interface FromUser. Die Interfaces werden auch im Statecharts:
[0]
Signaldiagramm definiert und es können mit ihnen einige Signale zusammengefasst werden. Das bedeutet wenn mein System zwei Signale hat die nur zum Benutzer gesendet werden z.B. Status und CurrentTemperature so können diese im Interface ToUser gebündelt werden. Danach werden Sie als ToUser::Status und ToUser::CurrentTemperatur geführt, um ihre Zugehörigkeit zum Interface darzustellen.
Abbildung in dieser Leseprobe nicht enthalten
Statecharts:
Das Verhalten von Capsules wird in Statecharts beschrieben. Diese sollten weitestgehend bekannt sein. Am Ende des Kapitels UML 2.0 gehe ich jedoch nochmals näher darauf ein.
Statecharts werden verwendet um das Verhalten einer Komponente darzustellen. In diesen werden Zustandsübergänge aufgrund von eingehenden Nachrichten modelliert. Da das Statechart schon seit längerem existiert und nichts UML 2.0 spezifisches ist möchte ich hier nur noch kurz erwähnen, dass in UML 2.0 Zustandsübergänge auch aufgrund von Timern eintreten können. Dazu habe ich ein Diagramm ausgewählt in dem ein Übergang wegen eines Timers geschieht. Als erstes sieht man wie ein Signal StartFl() eingeht. Dieses Signal transportiert zudem noch einen Integer Wert mit Namen flowRate. Anschließend wird der Timer (FlowTimer) gesetzt und der Thread geht in den Zustand Flowing. Diesen Zustand kann er nur verlassen wenn entweder der Timer abläuft oder das Signal StopFl() eingeht. Sollte der Timer ablaufen wird er erneut gesetzt und auf den aktuellen Füllstand wird der oben übergebene Wert flowRate addiert. Sollte jedoch das Signal StopFl() eingehen, wird der Timer resetet und der Thread ist wieder im Zustand Idle.
[...]
-
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X.