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

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

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 <= ta“. Dies bedeutet
anders ausgedrückt, dass die Zeitspanne zwischen dem Empfang der „Enter1“-Nachricht (zum
Zeitpunkt „a“) und dem Versenden der „closeGate“-Nachricht (zum Zeitpunkt „b“) kleiner
oder gleich ta ist. ta bezeichnet dabei die Zeitspanne, die ein schnellstmöglicher Zug bis zum
Erreichen des kritischen Bereiches benötigt. Testet man das in Abb. 9 dargestellte Diagramm
mit dieser Zeitinvariante „b-a <= ta“, so liefert die an UppAal gestellte Anfrage das Resultat:
Property 1 (line 1) is satisfied.
9
Ändert man nun die Zeitinvariante in „b-a >= ta“, so erhält man als Antwort auf die UppAalAnfrage:
Property 1 (line 1) is NOT satisfied.
Diese Rückmeldung wird nachvollziehbar, wenn man sich klarmacht, dass diese Invariante
die dargestellte Kollaboration das zugrundeliegende Modell verletzen würde. Die Ursache
hierfür liegt darin begründet, dass zwischen dem Eintritt eines Zuges in den kritischen
Bereich und dem Befehl „closeGate“ mehr Zeiteinheiten als die minimale Zeitperiode, die ein
schnellstmöglicher Zug für die Strecke benötigen würde, liegen.
Ein anderes Beispiel für eine verletzende Kollaboration zwischen den Objekten des Systems
wäre ein „openGate“-Befehl, der ohne Nachricht über den Austritt des Zuges aus dem
kritischen Bereich oder einen Timeout, der dieselbe Schlussfolgerung zulässt, erteilt wird. Der
übersetzte Timed Automaton eines solchen Sequenz-Diagramms ist in Abb. 10 dargestellt.
Abb. 10: Timed Automaton eines fehlerhaften Systemverhaltens
Korrekterweise lautet auch die Antwort des Model Checkers auf die Anfrage:
Property 1 (line 1) is NOT satisfied.
UppAal überprüft bei dieser Anfrage, ob ein Pfad auf dem Zustandsbaum existiert, der den
Zustand seq_8 erreicht. Dieser Zustand stellt in diesem Fall den letzten erreichten Zustand der
im Diagramm (vgl. Abb. 9) beschriebenen Kollaboration dar. Da dieser Zustand jedoch nicht
erreicht werden kann, da dies die Modellanforderungen verletzen würde, kann die Eigenschaft
nicht erfüllt werden.
Diesem Beispiel folgend können auch eine Reihe anderer Anfragen gestellt werden, um
bestimmte Zustände des Systems zu verifizieren. Eine Auswahl der zur Verfügung stehenden
Formeln ist in Abb. 11 abgebildet.
10
Abb. 11: Einige der in UppAal zur Verfügung stehende Formeln [6]
Diese Formeln lassen sich anders so beschreiben:
E<> p
Es existiert ein Pfad auf dem Zustandsbaum, der den Zustand „p“ erreicht.
A[] p
Alle Zustände des Zustandsbaumes repräsentieren Zustand „p“.
p --> 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