Institut für Informatik Arbeitsgruppe Softwaretechnik Warburger Str. 100 33098 Paderborn

Model-Checking von UML Modellen mit dem HUGO/RT System

Ausarbeitung im Rahmen des Seminars Analyse, Entwurf und Implementierung zuverlässiger Software

von

Tobias Koch Paderwall 5 33102 Paderborn

betreut durch

Daniela Schilling

Paderborn, Februar 2004

Inhaltsverzeichnis 1. 2. 3. 4. 5. 6. 7. 8. 9.

Einleitung ....................................................................................................... 2 Beschreibung des „Generalized Railroad Crossing“-Problems ..................... 3 Modellierung des „Generalized Railroad Crossing“-Problems ..................... 4 Umwandlung von UML State Machines in Timed Automata ....................... 8 Verifikation des Modells mit HUGO/RT....................................................... 9 Laufzeitverhalten.......................................................................................... 12 Einschränkungen des HUGO/RT-Systems .................................................. 12 Zusammenfassung und Ausblick ................................................................. 13 Quellen ......................................................................................................... 14

1

1. Einleitung Der Entwurf sicherheitskritischer Software stellt hohe Anforderungen an die Korrektheit des entstehenden Systems. Ein Entwurfsfehler kann später weitreichende und mitunter katastrophale Konsequenzen haben. Da das Testen und die Simulationen eines Systems nicht alle Fehler und Schwächen der Software aufdecken kann, bieten solche Verfahren beim Entwurf sicherheitskritischer Systeme keine akzeptable Lösung. Erst die zusätzliche formale Verifikation des Systems, z.B. durch Model Checking, kann die gewünschte Sicherheit bieten. Beim Model Checking wird zunächst ein Modell der zu entwerfenden Software erstellt. Nachfolgend werden die Anforderungen beschrieben, die das System zu erfüllen hat, und das Modell wird dahingehend überprüft, ob es diese Anforderungen erfüllt. Das in dieser Arbeit behandelte Tool HUGO/RT soll diesen Model Checking-Vorgang unterstützen. Hierzu übersetzt HUGO/RT ein UML-Modell in sogenannte Timed Automata, die anschließend durch den Model Checker UppAal verifiziert werden. Um das dynamische Verhalten eines Systems zu beschreiben, stehen in UML hauptsächlich zwei verschiedene Betrachtungsweisen offen. Auf der einen Seite werden die Handlungsabläufe der Software durch übergangsbasierte State Machines beschrieben, die Reaktionen und Abfolgen von Systemzuständen darstellen. Andererseits kann ein exemplarisches Verhalten des Systems in bestimmten Situationen durch nachrichtenbasierte Sequenz-Diagramme beschrieben werden. Dieses kann sowohl ein korrektes Verhalten der Software in bestimmten Szenarien darstellen als auch unerwünschte oder fehlerhafte Reaktionen und Systemzustände umschreiben. Um die Zuverlässigkeit eines Systems sicherzustellen, lassen sich nun mithilfe von HUGO/RT beide Darstellungsweisen verifizieren. Ich werde im Verlauf dieser Arbeit zunächst ein exemplarisches Problem vorstellen. Daraufhin werde ich die Modellierung des Problems als UML-State Machines beschreiben und die durch HUGO/RT vorgenommene Umwandlung eines UML-Modells in Timed Automata erläutern. Nachfolgend werde ich näher auf die Verifikation des exemplarischen Modells eingehen und das Laufzeitverhalten des HUGO/RT-Systems betrachten. Abschließen möchte ich mit einer Übersicht der Einschränkungen des gegenwärtig im Prototyp-Stadium befindlichen HUGO/RT-Tools sowie einer Zusammenfassung und einem Ausblick.

2

2. „Generalized Railroad Crossing“ Das „Generalized Railroad Crossing”-Problem beschreibt ein System zur sicheren Regelung eines beschrankten Bahnübergangs. Hierbei handelt es sich um die überwachten Abschnitte von k Bahnlinien (vgl. Abb. 1). Sobald ein Zug auf einer Bahnlinie in diesen Abschnitt eintritt, muss dafür gesorgt werden, dass die Schranken des Bahnübergangs sich schließen.

Abb. 1 „Generalized Railroad Crossing”-Problem [1] Um die sichere Passage eines Zuges zu gewährleisten, ist die strikte Einhaltung einiger Zeitabläufe notwendig. Sei die Zeitspanne vom Eintritt (A) eines schnellstmöglichen Zuges in den kritischen Bereich der Bahnlinien bis zum Erreichen der Beschrankung durch diesen Zug mit ta bezeichnet. Nun muss sichergestellt sein, dass dieser Zeitraum ausreicht, um den Schranken den Befehl zu erteilen sich zu schließen. Die maximale Zeitspanne, nach der ein Zug am Bahnübergang angelangt (Zeitpunkt D), wird mit Ta bezeichnet. Die Zeitspanne, die benötigt wird, um die Schranken aus der voll geöffneten Stellung in eine geschlossene Position zu bringen, sei mit gd bezeichnet. Rechnet man eine maximale Verzögerung ∆ durch das Netzwerk zwischen Eintrittssensor und Beschrankung hinzu, so erhält man gd+. Um die Beschrankung aus dem geschlossenen Zustand in die geöffnete Position zu überführen, sind mindestens gu Zeiteinheiten notwendig. Zuzüglich der maximalen Verzögerung ∆ erhält man hier die mit gu+ bezeichnete Zeitspanne. Hieraus ergibt sich unter Berücksichtigung der Eventualität, dass die Schranken bei Eintritt des Zuges in den kritischen Bereich bereits geschlossen sind, der Zeitpunkt B, zu dem es noch möglich ist, die Schranken komplett zu öffnen und sie anschließend wieder zu schließen. Der Befehl zum Schließen der Beschrankung muss spätestens zum Zeitpunkt C erteilt werden, damit der schnellstmögliche Zug die Kreuzung sicher passieren kann. Nach weiteren tg Zeiteinheiten hat der schnellste Zug den Bahnübergang gekreuzt und wieder freigegeben. Für die gleiche Strecke benötigt der langsamste Zug die Zeitspanne Tg, bevor er die Markierung E passiert hat. Alle Zeitspannen und Zeitpunkte sind in der nachfolgenden Abbildung 2 aufgeführt.

Abb. 2 Das GRC-Modell [1]

3

3. Modellierung des „Generalized Railroad Crossing“-Problems Zur Modellierung eines zu verifizierenden Software-Systems werden von den Entwicklern des HUGO/RT-Prototyps die beiden UML-Editoren „Poseidon for UML“ und ArgoUML empfohlen. Beide gehen auf eine gemeinsame Entwicklungsbasis zurück und unterstützen daher den Export entworfener Systeme im .zargo-Format. Zunächst entwirft man die State Machines der Objekte „Track1“ und „Track2“ (vgl. Abb. 3). Diese repräsentieren zwei Bahnlinien, welche die kritische Passage „Gate“ kreuzen. Sie bestehen aus den drei Zuständen „NoTrain“, „Approach“ und „Crossing“.

Abb. 3 State Machine eines „Track“-Objektes Übergangsbegleitende Invarianten der Form [c >= t] repräsentieren hierbei die zeitgesteuerten Übergänge zwischen den Zuständen. „c“ steht in diesem Fall für eine Uhr, die bei Betreten des überwachten Bahnabschnitts durch einen Zug auf 0 gesetzt wird. Fortan wird diese Uhr in einem Zustand, dessen ausgehende Übergänge durch eine Zeitinvariante begleitet sind, überwacht. Verharrt die State Machine solange in einem Zustand bis die Uhr die TimerVariable „t“ überschreitet, so schaltet die State Machine automatisch in den folgenden Zustand. Eine solche Überschreitung einer Zeitvariablen kann beabsichtigt sein oder beispielsweise durch das Ausbleiben einer Synchronisationsnachricht, deren Eintreffen die State Machine zum Verlassen des aktuellen Zustands zwingen würde, erfolgen. Nach dem Eintritt eines Zuges in den überwachten Bereich wechselt die State Machine aus dem Startzustand „NoTrain“ in „Approach“, wobei die Uhr „c“ auf 0 gesetzt wird und eine Nachricht über den Eintritt an das „Controller“-Objekt versandt wird. Nach Ablauf der Zeitspanne „t5“ wechselt die State Machine von „Approach“ in den Zustand „Crossing“ und setzt die Uhr erneut zurück. Überschreitet die Uhr nun die Timer-Variable „t4“, so muss der Zug den kritischen Bereich durchfahren haben und die State Machine der Bahnlinie kehrt in den Zustand „NoTrain“ zurück. Hierbei wird der State Machine „Controller“ eine Nachricht über das Verlassen des kritischen Abschnitts durch den Zug gesandt.

4

Die State Machine „Gate“ verwaltet die Schranken im kritischen Bereich des Bahnabschnitts. Der Startzustand des Objektes ist „Open“, die Schranken sind geöffnet für den kreuzenden Straßenverkehr (vgl. Abb. 4).

Abb. 4 State Machine des „Gate“-Objektes Empfängt „Gate“ nun den Befehl „closeGate“, so wechselt die State Machine in den Zustand „Closing“, wo sie für die Dauer von „gd“ verweilt. Nach Ablauf dieser Zeitspanne folgt der Zustand „Closed“, der signalisiert, dass die Schranken geschlossen und der kritische Abschnitt der Bahnlinie frei zur Durchfahrt des Zuges ist. In diesem Zustand verharrt die State Machine bis sie das Signal „openGate“ erhält, woraufhin sie in den Zustand „Opening“ wechselt. Hier wartet das System für die Zeitdauer „gu“, mit der die Zeitspanne, welche für das Öffnen der Schranken benötigt wird, beschrieben wird. Nachfolgend wechselt die State Machine in den Ursprungszustand „Open“. Für die Überwachung der Bahnlinien sowie die Kontrolle der Schranken ist das Objekt „Controller“ zuständig. Es handelt sich hierbei um eine nebenläufige Composite State Machine, die aus mehreren State Machines besteht (vgl. Abb. 5). Diese können unabhängig voneinander ihre Zustände wechseln.

Abb. 5 Composite State Machine des „Controller“-Objektes Zunächst ist für jede Bahnlinie eine Kontrolle vorhanden, in diesem Beispiel mit „Control1“ und „Control2“ bezeichnet. Startzustand dieser Kontrollen ist der Zustand „Away1“ 5

respektive „Away2“. In diesen Zuständen verharrt das System bis ein Zug in den überwachten Abschnitt der Bahnlinie eintritt, woraufhin das „Track“-Objekt die Nachricht „enter“ an die Kontrolle versendet. Diese reagiert darauf, indem die entsprechende „Control“-State Machine den Zustand „Away“ verlässt und in den Zustand „Entered“ wechselt. Hier verbleibt das System für die Zeitdauer „d1“, um anschließend in den Zustand „Nearby“ zu schalten, was wiederum repräsentiert, dass der Zug sich nun dem kritischen Abschnitt der Strecke nähert. Zu diesem Zeitpunkt reicht die verbleibende Zeit bis zum Eintreffen des Zuges am Bahnübergang noch aus, um die Schranken komplett zu öffnen und wieder zu schließen einschließlich der benötigten Zeiten für die Nachrichtenübermittlung zwischen den Objekten. Bei dem Wechsel vom Zustand „Entered“ nach „Nearby“ wird die Variable „trains“, die die Anzahl der momentan im Bereich des Bahnübergangs befindlichen Züge hält, inkrementiert. Den Zustand „Nearby“ verlässt die State Machine erst nach weiteren „d2“ Zeiteinheiten. Während des Zustandwechsels schickt die State Machine das Kommando „doClose“ an sich selbst. Die Zeitabstände zwischen den Statuswechseln reicht aus, um die Nachricht abzusetzen und die Schranken vollständig zu schließen, bevor der erste Zug im kritischen Bereich der Beschrankung eintrifft. Der nun erreichte Zustand der State Machine wird mit „Critical“ bezeichnet. Diesen Zustand verlässt das System nun wiederum erst, wenn „Track“ meldet, dass der Zug den Abschnitt verlassen hat oder falls der Eintritt eines weiteren Zuges in den überwachten Bereich gemeldet wird. In diesem Fall wechselt die State Machine in den Zustand „Entered“. Die Variable „trains“ wird ebenfalls dekrementiert, da der erste Zug den kritischen Abschnitt verlässt bevor der zweite ihn erreicht. Verlässt ein Zug ganz regulär den überwachten Bereich, ohne dass ein weiterer Zug in diesen hineinfährt. wird mittels der Nachricht „exit“ mitgeteilt, dass der Zug den Bahnübergang passiert hat. Die Variable „trains“ wird dekrementiert und die State Machine schickt die Nachricht „doOpen“ an das „Controller“-Objekt. Der nachfolgende Zustand ist nun wieder „Away“. Die Kommunikation zwischen den „Control“-Objekten, die die Bahnabschnitte überwachen (hier „Control1“ und „Control2“) und dem „Gate“-Objekt, das die Schranken repräsentiert, stellt ein „ControlGate“-Objekt her, das ebenfalls zur Composite State Machine „Controller“ gehört. Startzustand von „ControlGate“ ist „Open“. Empfängt das System nun die Nachricht „doClose“, welche von den „Control“-Objekten beim Wechsel vom Zustand „Nearby“ zu „Critical“ gesendet wird, so verlässt die State Machine „Open“, um in den Zustand „Closed“ überzugehen. Hierbei wird die Nachricht „closeGate“ an die State Machine „Gate“ gesendet. Den Zustand „Closed“ verlässt „ControlGate“ auf die Nachricht „doOpen“ hin wieder, welche von den „Control“-Objekten beim Verlassen vom Zustand „Critical“ verschickt wird. Welchen Zustand die State Machine „ControlGate“ als nächstes annimmt, ist abhängig von der Variable „trains“. Diese Fallunterscheidung wird durch einen sogenannten junction pseudo state ermöglicht. Befinden sich noch weitere Züge im überwachten Abschnitt der Bahnstrecke, so hat der guard „trains“ einen Wert größer 0 und „ControlGate“ kehrt umgehend in den Zustand „Closed“ zurück, um ein weiteres „doOpen“-Signal abzuwarten. Haben hingegen alle Züge den überwachten Bereich verlassen, hat „trains“ den Wert 0 und „ControlGate“ kehrt in den Ausgangszustand „Open“ zurück. Hierbei wird das Signal „openGate“ an das „Gate“-Objekt übermittelt.

6

Um nun das System zu verifizieren, kann eine exemplarische Situation von System-Abläufen durch eine Kollaboration, dargestellt in einem Sequenz-Diagramm, beschrieben werden. Abbildung 6 zeigt ein sicheres Verhalten des Systems.

Abb. 6 Sicheres Systemverhalten Ausgehend von „track1“ wird eine Nachricht mit dem Inhalt „Enter1“ an das „Controller“Objekt „ctl“ gesandt. Kurz darauf sendet auch „track2“ eine Nachricht, die besagt, dass ein Zug in den überwachten Abschnitt von „Track2“ eingetreten ist. Nach der internen Reaktionszeit von „ctl“, bedingt durch die Zustandswechsel, sendet das „Controller“-Objekt die Nachricht „closeGate“ an das „Gate“-Objekt „gate“.

7

4. Umwandlung von UML State Machines in Timed Automata Um das nun entworfene System aus UML State Machines zu verifizieren, muss HUGO/RT diese zunächst in die für UppAal verständlichen Timed Automata übersetzen. Dies lässt sich am einfachsten an einem Beispiel erläutern. Gegeben sei die in Abbildung 7 dargestellte UML-State Machine.

Abb. 7 Exemplarische State Machine Zunächst wird der Startzustand der State Machine in eine entsprechende Location eines Timed Automaton übertragen. Aus den beiden State Machine-Startzuständen „A“ und „C“ wird die Location „AC“ generiert, die beide Zustände repräsentiert. Auf Empfang der Nachricht „b“ reagiert die State Machine, falls „x>0“gilt, mit einer Transition in den Zustand „E“ und verharrt weiterhin in Zustand „C“. Dies wird in einem übersetzten Timed Automaton durch die Location „EC“ dargestellt. Der Wechsel nach „EC“ wird begleitet durch den guard „x>0“. Wird die Bedingung hingegen nicht erfüllt, so wechselt die State Machine in den Zustand „G“. Diese Transition wird ebenso in den Timed Automaton eingefügt. Hierbei wird jedoch die Negation der Bedingung „x>0“ als guard eingefügt, um die Eindeutigkeit der Systemreaktion auf den Empfang der Nachricht „b“ zu gewährleisten. Der Wechsel der State Machine in den Zustand „F“ nach Erhalt der Nachricht „a“ wird ebenfalls direkt übersetzt. Die Transition der State Machine aus dem Zustand „A“ nach „B“ bzw. von „C“ nach „D“ muss in mehreren Schritten erfolgen, da der entstehende Timed Automaton pro Wechsel einer Location lediglich eine Aktion ausführen kann. Hierzu werden die sogenannten committed locations eingeführt, die der Timed Automaton zwar betreten darf, die er jedoch umgehend wieder verlassen muss. So wird eine erste committed location hinzugefügt um auf den Empfang der Nachricht „a“ zu reagieren. Beim Wechsel zur nächsten committed location wird die Variable „x“ inkrementiert. Nachfolgend wird die Nachricht „b“ versandt und die Empfangsbestätigung abgewartet. Erst dann wechselt der Timed Automaton in die Location „BD“. Der aus der Übersetzung resultierende Timed Automaton ist in der Abbildung 8 dargestellt.

Abb. 8 Aus der in Abb. 7 dargestellten State Machine erzeugter Timed Automaton 8

5. Verifikation des Modells mit HUGO/RT Um das entwickelte Modell zu verifizieren, bestehen zwei Möglichkeiten: 1. Das Modell wird gegen eine exemplarische Situation, die in einem SequenzDiagramm modelliert wird, verifiziert. 2. Es werden Anfragen mit Aussagen über die Zustandskonfigurationen des Modells gestellt. Gegenwärtig ist es mit den beiden empfohlenen UML-Editoren „Poseidon for UML“ und „Argo/UML“ leider nicht möglich, Sequenz-Diagramme zu erstellen. Eine Modifikation gegebener Diagramme ist mit einigen älteren Versionen der Software „Argo/UML“ stark eingeschränkt möglich. Nach Aufruf des HUGO/RT-Prototypen mit Übergabe einer .zargo-Projektdatei übersetzt die Software zunächst die enthaltenen Zustands-Diagramme, wie in Abschnitt 4 beschrieben, in die dem Model Checker UppAal verständlichen Timed Automata. In der Projektdatei enthaltene Sequenz-Diagramme werden von HUGO/RT in UppAal-Anfragen übersetzt, wobei getestet werden soll, ob ein im Sequenz-Diagramm zuletzt erreichter Zustand auch im gegebenen Modell erreicht werden kann. In Abb. 9 ist ein solches Sequenz-Diagramm des Systems zu sehen.

Abb. 9: Sequenz-Diagramm eines sicheren Systemverhaltens Die zu verwendende Syntax besteht aus einer Zahl, welche die Reihenfolge der Interaktionen zwischen den Objekten kennzeichnet. Darauf folgt der Sende-Zeitpunkt der Nachricht. Getrennt durch einen Strich „-“ wird nun der Empfangs-Zeitpunkt spezifiziert, gefolgt vom Inhalt der Nachricht. Sollte ein Zeitpunkt nicht angegeben werden können oder müssen, so kann der entsprechende Marker entfallen. Alle Objekte müssen zudem die zu testenden Zeitinvarianten als „tagged value“ mit dem Namen „timing“ enthalten. Angenommen, die Zeitinvariante im dargestellten Diagramm sei „b-a q Dem Zustand „p“ folgt auf jedem Pfad des Zustandsbaumes ein Zustand „q“. Möchte man also erfahren, ob „closeGate“-Nachrichten die „Gate“-Kontrolle erreichen, so formuliert man die Anfrage: E GateStateMachine.Closing Ein komplexeres Beispiel lautet: A[] GateStateMachine.Open imply not Track1StateMachine.Crossing and not Track2StateMachine.Crossing2 Hierbei wird verifiziert, dass, wann immer sich die Schranken im geöffneten Zustand befinden, weder auf Track1 noch auf Track2 ein Zug den Bahnübergang kreuzt. Auch nicht zulässige Systemzustände lassen sich auf diese Weise untersuchen. Die Anfrage E ControlStateMachine.Open_x_Critical1_x_Away2 and ControlStateMachine.Nearby1_clock>d2 untersucht das Modell daraufhin, ob trotz geöffneter Schranken und einem Zug im kritischen Bereich der Bahnstrecke 1 die Uhr Nearby1_clock genügend Restzeit zum Schließen der Schranken meldet. Diese Eigenschaft ist nicht erfüllbar. A[] Track1StateMachine.Crossing or Track2StateMachine.Crossing2 imply GateStateMachine.Closed verifiziert, ob tatsächlich jeder modellierte Zustand „Crossing“, der erreicht wird, sobald ein Zug den Bahnübergang kreuzt, impliziert, dass die Schranken geschlossen sind.

11

6. Laufzeitverhalten Das Laufzeitverhalten des Prototyps lässt sich nur erahnen, da ein Großteil der verwendeten Ressourcen während der Ausführung für Java benutzt werden. Das beschriebene Beispiel des GRC-Modells lässt sich auf einem Pentium III 933 MHz mit 512 MB Arbeitsspeicher in etwa 2.5 Sekunden in die entsprechenden Timed Automata für UppAal übersetzen. Der Speicheraufwand während der Übersetzung beträgt ungefähr 213 MB. Um eine Abschätzung darüber treffen zu können, wie groß der Bedarf hieran für den eigentlichen Übersetzungsvorgang ist, habe ich ein Java-Programm ohne Funktionalität geschrieben und ebenfalls den Speicheraufwand gemessen. Die Ausführung einer leeren Klasse benötigt auf dem gleichen System etwa 210 MB. Inwiefern dieser Vergleich die wirklichen Verhältnisse widerspiegelt, lässt sich nur schwer feststellen, jedoch ermöglicht er zumindest eine grobe Abschätzung. Die Verifikation des Modells mittels UppAal benötigt auf demselben System lediglich Bruchteile einer Sekunde. Im Mittel ließ sich eine Anfrage in 0.13 Sekunden beantworten. Der Speicheraufwand betrug hierbei konstant 2.3 MB. Bei einer umfangreicheren Verifikation mit 10 Anfragen stieg der Speicherbedarf auf 3.1 MB und die CPU-Nutzung dauerte 0.32 Sekunden. Das mittels HUGO/RT generierte Timed Automata-Modell besteht aus 10 einzelnen Timed Automaton, die ca. 200 Locations und 11 Clocks benötigen. Gegenüber den 18 Zuständen in 6 State Machines des ursprünglich erstellten Modells wird hierbei eine Schwäche von HUGO/RT offensichtlich. 7. Einschränkungen des HUGO/RT-Systems Obwohl das HUGO/RT-System trotz der Prototyp-Bezeichnung bereits einen sehr guten und umfangreichen Eindruck hinterlässt, sind einige Einschränkungen oder Mängel erkennbar geworden. So wird bei der Übersetzung der UML State Machines in Timed Automata angenommen, es gäbe lediglich eine Instanz jeder Klasse. Darüber hinaus nimmt der Prototyp an, die Namen der Operationen und Signale seien eindeutig. Auch können Ereignisse, die in dem behandelten Beispiel nur als Nachrichten auftauchen, keinerlei Parameter tragen. All diese Einschränkungen stellen jedoch kein wirkliches Hindernis dar, da sie durch eine etwas aufwändigere Namensgebung leicht umgangen werden können. Der Prototyp unterstützt ebenfalls keine Sequenzen von Nachrichten, die in einer Transition des UppAal-Modells auftreten. Auch Reaktionen auf zurückgestellte Ereignisse sind derzeit nicht behandelbar mit HUGO/RT. Aufgrund der eingeschränkten Ausdrucksstärke der UML-Kollaborationen planen die Entwickler in einer künftigen Version der Software, Live Sequence Charts als Spezifikationsformalismus zu implementieren. Die angesprochenen Mängel bei der Erstellung und Bearbeitung der Sequenz-Diagramme sollen mit der in Kürze erscheinenden Version 0.16 des UML-Editors Argo/UML behoben werden. Bis dahin ist die Benutzung von HUGO/RT zur Verifikation eines Systems mithilfe solcher Diagramme praktisch nicht möglich.

12

8. Zusammenfassung und Ausblick Der behandelte Prototyp der HUGO/RT-Software ist im gegenwärtigen Zustand in der Lage UML-Zustands- und Sequenzdiagramme in Timed Automata zu übersetzen. Zur Verifikation der generierten Modelle wird anschließend der Model Checker UppAal aufgerufen, der die übersetzten Timed Automata zur Eingabe bekommt. Die Aufgabe die UML-Modelle zu übersetzen erledigt HUGO/RT bereits sehr gut. Ich konnte keine Abstürze des Systems beobachten. Die Benutzbarkeit des Systems leidet jedoch bis dato noch unter den erwähnten Mängeln der UML-Editoren „Poseidon for UML“ und „Argo/UML“. Momentan erfährt die HUGO/RT-Software offenbar auch keine Weiterentwicklung. Die angesprochenen Mängel in der Namensgebung sollen laut den Entwicklern in einer kommenden Version behoben werden. Zu den übrigen Erweiterungen der Software sollen die Code-Generierung und eine Unterstützung für zurückgestellte Nachrichten gehören, was in der aktuell verfügbaren Version des Systems nicht möglich ist. Probleme traten während der Arbeit mit unterschiedlichen UppAal-Versionen auf, da im Zuge der Weiterentwicklung offenbar leichte Änderungen in der Syntax der verwendeten ProjektDateien vorgenommen wurden.

13

9. Quellen: 1. Knapp, Merz und Rauh. Model Checking Timed UML State Machines and Collaborations, München, 2002. http://www.pst.informatik.unimuenchen.de/personen/merz/papers/ftrtft02.pdf 2. Hirsch. Model-Checking und Timed Automata, Paderborn, 2003. 3. Knapp und Merz, Model Checking UML Statecharts and Collaborations, Turku, 2002. http://www.loria.fr/~merz/talks/hugo-turku.pdf 4. Giese und Burmester. Real-Time Statechart Semantics, S. 8ff., Paderborn, 2003. http://www.upb.de/cs/ag-schaefer/Personen/Aktuell/Giese/archive/2003/tr-ri-03239/tr-ri-03-239.pdf 5. David und Amnell. UppAal2k: Small Tutorial, 2002. http://www.docs.uu.se/docs/undergrad/instances/spring2003/RealTime/labs/ass3/tutori al.pdf 6. Skou. An introduction to UppAal and Timed Automata, Aalborg, 2003. http://www.cs.auc.dk/~ask/Undervisning/MVP/html/mvp5.pdf 7. Sierszecki, Berthing, Ruby und Horsdal. Model Checking Real-Time Temporal Logic, S. 34 ff., Aarhus, 2003. http://www.daimi.au.dk/Conver/tctl-presentation.pdf

14