Modellbasierte Entwicklung Echtzeit modellieren mit UML 2
Entwickler müssen große Sorgfalt auf die Beschreibung der zeitbezogenen Anforderungen legen. Wir zeigen Ihnen, wie Sie mit UML 2 diese Anforderungen genau und widerspruchsfrei darstellen können.
Anbieter zum Thema
Eingebettete Systeme arbeiten als Teil eines größeren Ganzen. Damit das gesamte System funktioniert, muss die Software Funktionen bzw. Daten zu verlässlichen Zeitpunkten bereitstellen. Es besteht also eine große Abhängigkeit zwischen Software und Hardware. Außerdem kann die Leistung der Software nicht beliebig durch Anreicherung von Ressourcen (Datenkanälen, Prozessoren, Speicherplatz) erhöht werden, wodurch effizientes Arbeiten enorm an Wichtigkeit gewinnt. Zeitpunkte bzw. Zeiträume müssen eingehalten werden, zu denen ein eingebettetes System etwas leisten müssen. Aus diesem Grund spricht man meist von eingebetteten Echtzeitsystemen (Real Time Embedded Systems — RTE). Der Faktor Zeit zählt jedoch zu den nicht-funktionalen Anforderungen, deren Analyse und Dokumentation eher unbeliebt ist und daher so oft vernachlässigt wird. Da das Echtzeitverhalten bei RTE-Systemen aber einen derart hohen Stellenwert besitzt, führt hier leider kein Weg an einer genauen Betrachtung vorbei.
Generelle Zeitanforderungen generieren
Da sich bei RTE-Systemen vieles um den Faktor Effizienz dreht, werden wir im Folgenden die Modellierung von Zeitanforderungen mit der UML2 betrachten. Anforderungen an das Zeitverhalten des Systems gibt es auf allen Detaillierungsstufen der Systembeschreibung. Dementsprechend ist das Visualisieren von Zeitverhalten in fast allen Verhaltensdiagrammen der UML sinnvoll. Wir greifen uns die folgenden Diagramme heraus: Anwendungsfalldiagramm, Aktivitätsdiagramm, Zustandsautomat, Sequenzdiagramm und Timingdiagramm.
Wir beginnen mit dem Anwendungsfalldiagramm: Handelt es sich um sehr generelle Zeitanforderungen auf der abstrakten Ebene ganzer Prozesse, so eignen sich Anwendungsfalldiagramm und -beschreibung zum Erheben und zur Notation der Zeitanforderungen.
- Zeitdauer zur Abarbeitung eins Anwendungsfalls: In einer Notiz, die mit dem entsprechenden Anwendungsfall verbunden ist, können Sie beschreiben, wie viel Zeit zwischen einem eingehenden messbaren Event und dem erzielten Ergebnis im Standardfall vergehen darf.
- Reaktionszeit auf einen Trigger: In einer Notiz, die Sie an eine Verbindung zwischen Akteur und Anwendungsfall hängen, können Sie beschreiben welche Reaktionszeit der Akteur von dem System erwartet.
- Zeitpunkt der Ausführung eines Anwendungsfalls: In einer Notiz, die Sie an eine Verbindung zwischen Akteur und Anwendungsfall hängen, können Sie außerdem beschreiben, zu welchem Zeitpunkt ein Anwendungsfall von einem externen Akteur getriggert wird.
- Zeitgesteuerte Ereignisse: Die UML erlaubt es, für Akteure neben dem Strichmännchen und der als „actor“ stereotypisierten Klasse eigene Symbole zu definieren. Für Anwendungsfälle, die immer zu einer bestimmten Zeit ausgeführt werden, verwenden wir seit längerem eine Uhr als Symbol. Dieser Uhr können Sie Angaben beifügen, wann ein bestimmter Anwendungsfall ausgelöst wird („Jeden Montag um 5:00 Uhr“, „Alle 20 Minuten“). Dies hat sich bereits in einigen Fällen als hilfreich erwiesen.
Was nicht in ein Anwendungsfalldiagramm gehört
Was Sie nicht in einem Anwendungsfalldiagramm darstellen sollten, sind Zeitangaben zur Reihenfolge der Anwendungsfälle. Das gehört nicht zum Informationsgehalt des Anwendungsfalldiagramms. Prinzipiell sollten die Zeitangaben im Anwendungsfalldiagramm recht sparsam eingesetzt werden. Dieses Diagramm soll einen Einstieg sowie einen Überblick liefern und ist daher für die detaillierten Zeitangaben nicht geeignet. Die Zeitangaben gehen nicht verloren, vielmehr werden wir diese in anderen Darstellungsformen verwenden. Dazu nachher mehr.
Steht hinter dem Anwendungsfalldiagramm eine ausformulierte Anwendungsfallbeschreibung, welche die Einzelschritte des essenziellen Ablaufs schildert, so kann zu den einzelnen essenziellen Schritten (die den Standardablauf des Anwendungsfalls angeben) eine Zeitanforderung stehen. Mit der Technik kann die Zeitanforderung an den gesamten Anwendungsfall auf Zeitanforderungen für die Einzelschritte aufgeteilt werden.
Allerdings enthält die Anwendungsfallbeschreibung nur die essenziellen Schritte des Ablaufs und kann die Ausnahmesituationen und Alternativabläufe nicht oder nur sehr leserunfreundlich mit aufnehmen. Um diese Informationen ebenfalls adäquat beschreiben zu können, eignen sich besonders Aktivitäts-, Zustands- und/oder Sequenzdiagramme der UML 2.
Sequenzdiagramme definieren Zeitintervalle

Zeitanforderungen zum Übermitteln von Nachrichten oder Ausführen einer Funktion lassen sich sehr gut mit Sequenzdiagrammen darstellen. Die UML bietet zwei prinzipielle Möglichkeiten, Zeitangaben in einem Sequenzdiagramm zu dokumentieren:
- Angabe der Zeit: Im Sequenzdiagramm werden Zeiten in Intervallen angegeben. Diese Inter-valle werden in folgender Form dargestellt: {tmin .. tmax}. Im Falle eines Zeitpunktes sagt das Intervall aus, dass ein Ereignis zwischen dem Zeitpunkt tmin und dem Zeitpunkt tmax stattfinden muss. Im Falle einer Zeitspanne bedeutet es, dass das Ereignis mindestens tmin Zeiteinheiten und maximal Zeitpunkt tmax Zeiteinheiten dauern darf. Die im Diagramm verwendete Zeiteinheit (Sekunden, Millisekunden, Nanosekunden) wird üblicherweise in einem Notizfeld in der rechten oberen Ecke des Diagramms angegeben.
- Modellierung von Zeitpunkten: Im Sequenzdiagramm können einzelne Zeitpunkte im Verlauf einer Lebenslinie definiert werden z.B. am Anfang oder Ende einer Nachricht. Hierfür wird ein kurzer, waagerechter Strich an die entsprechende Stelle der Lebenslinie modelliert und die Zeitangabe daran geschrieben.
- Modellierung von Zeitspannen: Zeitspannen können sowohl für die Dauer einer Nachrichtenübermittlung als auch für die Abstände zwischen zwei Zeitpunkten auf einer Lebenslinie definiert werden. Um die Zeitspanne festzulegen, in der eine Nachricht übermittelt werden soll, schreiben Sie die Zeitangabe hinter den Namen der Nachricht an den Pfeil. Um den Abstand zwischen zwei Zeitpunkten auf einer Lebenslinie anzugeben, werden diese Zeitpunkte durch je einen kurzen, waagerechten Strich an der entsprechenden Stelle der Lebenslinie gekennzeichnet und die Zeitangabe mit einem Doppelpfeil dazwischen geschrieben.
Zustandsautomaten modellieren detaillierte Anforderungen

Falls Sie das Verhalten Ihres Systems oder auch einzelner Klassen ihres Systems mittels eines Zu-standsautomaten spezifizieren möchten, so können Sie auch hier detaillierte Anforderungen an das Zeitverhalten unterbringen.
- Zeitlich gesteuerte Transitionen: Durch die sogenannten TimeEvents der UML können Zustandsübergänge durch zeitliche Trigger ausgelöst werden. Hierbei stehen zwei Arten von TimeEvents zur Verfügung: „after(
)“ und „at( )“. Wobei die absoluten Zeitangaben sehr selten verwendet werden. Diese Zeitangaben bilden den Trigger der Transition und können ganz normal durch Bedingungen (Guards) eingeschränkt und durch ein Verhalten ergänzt werden. - Zeitangaben für das Verhalten innerhalb eines Zustandes: Sie können Zeitanforderungen sowohl an das Gesamtverhalten eines Zustandes (alle Aktionen innerhalb dieses Zustandes) als auch an ein spezielles Verhalten innerhalb des Zustandes (speziell an die Exit-Aktivität) definieren. Diese Anforderungen schreiben Sie am Besten in eine Notiz, an den jeweiligen Zustand.
- Zeitangaben zu der Gesamtlebensdauer eines Objektes: Falls Sie eine Aussage zu der Lebensdauer eines Objektes machen möchten, bleibt Ihnen auch hier nur die Möglichkeit dies in einer Notiz im Diagramm zu beschreiben.
Angaben mit Timing-Diagrammen grafisch darstellen

In einem Timing-Diagramm können viele zeitliche Angaben grafisch dargestellt werden, die in anderen Diagrammen lediglich in Form von Kommentaren vorliegen.
- Zeitskala: Durch das Anlegen einer Zeitskala am unteren Rand der abgebildeten Lebensli-nien kann ein genauer zeitlicher Verlauf dargestellt werden. Die Einheit (Minuten, Sekunden, Millisekunden) dieser Zeitskala ist frei wählbar. Die Zeitskala kann zum Einen anzeigen, wie lange ein Objekt in einem bestimmten Zustand verweilt. Zum Anderen lässt sich damit darstellen, in welchem zeitlichen Abstand zwei Ereignisse (zwei Zustandswechsel eines einzigen Objektes oder zwei Zustandswechsel zweier verschiedener Objekte) zueinander liegen.
- Zeitpunkte und Zeitdauern: Wie beim Sequenzdiagramm können Sie Zeitpunkte und Zeitdauern auch in einem Timing Diagramm modellieren. Die Notationsweise entspricht ganz der im Sequenzdiagramm (siehe oben).
Die UML bietet, insbesondere ab der Version 2.0 vielerlei Notationsmöglichkeiten, die speziellen Belange eingebetteter Echtzeitsysteme zu modellieren. Es ist jedoch nicht sinnvoll alle nichtfunktionalen Anforderungen mit der UML darzustellen. In manchen Fällen sollten Sie besser auf gut formulierte natürlichsprachliche Anforderungen zurückgreifen, bevor Ihre Diagramme in einer Flut von Kommentaren untergehen.
Weiterführende Literatur:
Norm DIN 66272: Bewerten von Softwareprodukten: Qualitätsmerkmale und Leitfaden zu ihrer Verwendung. Ausg. Oktober 1994. DIN Deutsches Institut für Normung e.V.
Hatley, D.; Hruschka, P.; Pirbhai, I.: Komplexe Software-Systeme beherrschen. Bonn, mitp 2003.
Rupp, C.; Hruschka, P.: Agile Softwareentwicklung für Embedded-Real Time Systems mit der UML. München, Hanser Verlag 2002.
Rupp, C.; SOPHIST GROUP: Requirements- Engineering und - Management. München, Hanser Verlag 2006.
Rupp, C.; Queins, S., u.a.: UML 2 glasklar. München, Hanser Verlag 2007.
Artikelfiles und Artikellinks
Link: UML 2: Microsoft Visio
(ID:280130)