-
Die
Erfindung betrifft ein Verfahren zur Bestimmung von Verklemmungen
(Deadlocks) in nebenläufigen
Prozessen, bei denen mindestens ein Objekt in einem Zustand auf
ein anderes Objekt in einem bestimmten Zustand wartet, für ein objektorientiert
beschriebenes Systemmodell eines reaktiven Systems.
-
Für die Entwicklung
und Konstruktion reaktiver Systeme hat sich die sogenannte Unified-Modeling-Language
UML zu einer Standardmodellierungssprache auf dem Gebiet des objektorientierten
Designs entwickelt. Mit dieser grafischen objektorientierten computerimplementierten
Sprache lassen sich nicht nur Softwareprogramme, sondern auch komplexe
technische Systeme, wie zum Beispiel Kraftfahrzeuge und Flugzeuge
beschreiben, und deren Funktionen verifizieren. Auf Grund der hohen
Sicherheitsanforderungen in diesen Gebieten ist die Kombination
einer Standardmodellierungssprache mit formalen Methoden erwünscht, um Fehlverhalten
bereits in der Kontruktionsphase sicher erkennen zu können. In
solchen Systemen kann es auch zu Verklemmungen (Deadlocks) in zyklischen
Prozessen kommen. Ein Deadlock ist in der Informatik ein Zustand
von Prozessen, bei dem mindestens zwei Prozesse untereinander auf
Betriebsmittel warten, die dem jeweils anderen Prozess zugeteilt
sind. Hierdurch blockieren sich beide Prozesse gegenseitig. Eine
Verklemmung kann dann nur durch Beendigung einzelner Prozesse oder
Neustart des Sy stems beseitigt werden. Beides kann in sicherheitskritischen
System sehr problematisch sein.
-
Deadlocks
können
bei Systemen eintreten, die fähig
sind mehrere Prozesse parallel ablaufen zu lassen (Multitasksysteme)
und bei denen die Reihenfolge der Betriebsmittelvergabe nicht festgelegt
ist.
-
Beispielsweise
aus T. Schäfer,
A. Knapp und S. Merz: "Model
Checking UML State Machines and Collaborations", in: Electronic Notes in Theoretical
Computer Science 47 (2001), pp. 1–13 ist ein Verfahren zum Nachweis
der Deadlock-Freiheit sowie anderer Modell-Eigenschaften für relativ
kleine Systeme mit der Methodik des Model-Checking beschrieben.
Dies sind spezialisierte Computerprogramme, die nachteilig eine
Transformation des Systems in eine Modelchecker-Eingabesprache erfordern.
Dabei wird jeder Zustand eines Zustandsautomatens durch einen individuellen
Prozess modelliert. Für
jeden Zustandsautomaten des UML-Systemmodells dienen zwei zusätzliche
Prozesse zum Ausgeben von Ereignissen, die in einer Ereigniswarteschlange
abgespeichert sind, und zur Behandlung von Transitionen. Für die Überprüfung objektorientierter Systemmodelle
ist jedoch eine aufwendige Transformation in die verfügbaren Modellierungssprache
mit stark eingeschränkter
Modellierungsmächtigkeit
erforderlich. Ein großes
Problem stellt auch die Berücksichtigung der
Datentypen von objektorientierten Modellen dar, die zu einem sehr
großen
Zustandsraum führen.
Dadurch ist die Größe der prüfbaren Systemmodelle
beschränkt.
-
Aufgabe
der Erfindung ist es daher, ein verbessertes Verfahren zur Bestimmung
von Verklemmungen in nebenläufigen
Prozessen für
objektorientiert beschriebene Systemmodelle von reaktiven Systemen
zu schaffen.
-
Die
Aufgabe wird gelöst
durch die Schritte:
- a) Extrahieren aller aktiven
Objekte des objektorientierten Systemmodells;
- b) Feststellen mindestens der von den aktiven Objekten konsumierten
und/oder produzierten Ereignissen, der Transitionen zwischen den
Objekten und von Wächterbedingungen
von Zustandsautomaten des UML-Systemmodells zur Beschreibung des
Systemmodells zur Beschreibung des Zustandsverhaltens der Objekte;
- c) Erzeugen der Zustands-Warte-Relationen zwischen den aktiven
Objekten aus den Ereignissen als Liste von Objekten, die in einem
definierten Zustand auf ein anderes Objekt in einem definierten
Zustand warten;
- d) Ermitteln möglicher
Verklemmungs-Situationen als Zyklen aufeinander wartender Instanzen
von zwei oder mehr unterschiedlichen Objekten, wobei in dem Zyklus
kein Objekt mit mehr als einem Zustand involviert ist und keines
der Objekte des Zyklus auf ein Objekt außerhalb des Zyklus wartet;
und für
jede Verklemmungs-Situation;
- e) Überprüfen aller
möglichen
Pfade die zu einer ermittelten Verklemmungs-Situation führen und aus den Zustandsautomaten
des UML-Systemmodells abgeleitet werden, durch simulierte Ausführung des UML-Systemmodells
unter Berücksichtigung
der Ereignisse und aktivierten Transitionen zur Analyse der Erreichbarkeit
der ermittelten möglichen
Verklemmungs-Situationen.
-
Mit
einem solchem Verfahren ist der Nachweis der Deadlock-Freiheit für große objektorientierte
Systemmodelle technischer reaktiver Systeme mit vielen parallelen
Komponenten unter Berücksichtigung
komplexer Datentypen möglich.
-
Gemäß der vorliegenden
Erfindung wird ein mehrstufiges Prüfverfahren vorgeschlagen. Mit
den Schritten a) und b) werden die für einen Deadlock relevanten
Eigenschaften eines Systemmodells extrahiert und hieraus im Schritt
c) ein Zustands-Warte-Diagramm
erzeugt, das später
statistisch analysiert werden kann, um herauszufinden, welche "Warte-Auf"-Relationen zwischen
aktiven Objekten existieren. Dabei werden die internen Zustände der
aktiven Objekte beschrieben.
-
In
einer zweiten Phase werden die möglichen
Verklemmungs-Situationen ermittelt. Sofern keine Verklemmungs-Situationen
gefunden wurden, ist das Verfahren beendet und das Ergebnis kann
dargestellt werden. Ansonsten erfolgt in einer dritten Phase die
Analyse der Erreichbarkeit der ermittelten möglichen Verklemmungs-Situationen durch
Berechnung der möglichen
Pfade in die erkannten potentiellen Verklemmungs-Situationen, die
in der vorhergehenden Phase aufgefunden wurden, unter Verwendung
eines Suchalgorhithmus. Dann wird analysiert, ob diese Pfade durch
einen heuristischen Simulationsansatz ausführbar sind.
-
Aktive
Objekte im Sinne der Erfindung sind in der Systemmodellierungssprache
verwendete Sprachmittel zur Beschreibung von Prozessen. Ein aktives
Objekt im objektorientierten Modell entspricht einem nebenläufigen Prozess
des modellierten technischen reaktiven Systems. Ein nebenläufiger Prozess
kann unter Umständen
zyklisch sein. Dies ist bei reaktiven Systemen häufig der Fall, aber keine notwendige
Bedingung für
die Anwendung des Verfahrens.
-
Vorzugsweise
werden im Schritt a) des Extrahierens aller aktiven Objekte die
aktiven Objekte aus einer statischen und dynamischen Struktursicht
des Systemmodells extrahiert und in einer Objekt-Liste gespeichert.
-
Vorteilhaft
ist, wenn dann für
jedes aktive Objekt eine zugeordnete Klasse in einer Klassen-Liste
abgespeichert wird und für
jede Klasse in der Klassen-Liste das zugehörige Zustandsdiagramm zur Spezifikation eines
Zustandsautomaten ausgewertet wird. Die spezifizierten Zustandsautomaten
können
dann in einer Zustandsautomaten-Liste abgespeichert werden.
-
Auf
diese Weise wird eine mathematische Listenstruktur bereitgestellt,
die eine effektive analytische Auswertung ermöglicht.
-
Die
Ermittlung der möglichen
Verklemmungs-Situationen erfolgt vorzugsweise mit einem an sich
bekannten Tiefensucheverfahren (Depth-First-Search).
-
Die Überprüfung der
Erreichbarkeit der ermittelten möglichen
Verklemmungs-Situationen
erfolgt vorzugsweise heuristisch, in dem ausgehend von einem initialen
Zustand des Systemmodells die jeweils aktivierten Transitionen ermittelt
werden und diejenige aktivierte Transition ausgewählt wird,
welche das Systemmodell näher
an das Verklemmungs-Ereignis heranbringt.
-
Aktivierte
Transitionen liegen beispielsweise dann vor, wenn die Wächterbedingung
für das
zugeordnete Objekt wahr ist und das Ereignis des Objektes in einer
Eingabewarteschlange liegt.
-
Vorzugsweise
wird der Schritt e) des Überprüfens aller
möglichen
Pfade für
jede Verklemmungs-Situation (Phase C), solange iterativ durchgeführt, bis
entweder ein Verklemmungs-Zustand erreicht ist oder alle Pfade eine
festgelegte Anzahl durchlaufen wurden.
-
Das
Systemmodell wird besonders bevorzugt mit der Unified-Modeling-Language
UML beschrieben.
-
Die
Aufgabe wird weiterhin durch ein Computerprogramm mit Programmcodemitteln
zur Durchführung des
oben beschriebenen Verfahrens gelöst, wenn das Computerprogramm
auf einem Rechner ausgeführt wird.
-
Die
Erfindung wird nachfolgend an Hand der beigefügten Zeichnungen beispielhaft
näher erläutert. Es zeigen:
-
1 Flussdiagramm
des erfindungsgemäßen Verfahrens
zur Bestimmung von Verklemmungen;
-
2 Statische
Systemstruktur (Klassendiagramm) eines beispielhaften Messsystemmodells;
-
3 Dynamische
Systemstruktur des beispielhaften Messsystemmodells aus 2;
-
4 der
Detailansicht des Verhaltens des Controllers des beispielhaften
Messsystemmodells
-
5 Detailansicht
des Verhaltens des ersten Sensors des beispielhaften Messsystemmodells;
-
6 Detailansicht
des Verhaltens des zweiten Sensors des beispielhaften Messsystemmodells;
-
7 Detailansicht
des Verhaltens der Uhr des beispielhaften Messsystemmodells;
-
8 Detailansicht
des Verhaltens des Benutzers des beispielhaften Messsystems
-
9 Zustands-Warte-Graph
eines beispielhaften Durchlaufs zur Erkennung potentieller Verklemmungen;
-
10 Sequenzdiagramm
zur Darstellung des Analyseergebnisses des erfindungsgemäßen Verfahrens
am Beispiel des Messsystemmodells.
-
Die 1 lässt ein
Flussdiagramm des erfindungsgemäßen mehrphasigen
Verfahrens zur Bestimmungen von Verklemmungen (Deadlocks) in nebenläufigen Prozessen
erkennen.
-
Ausgangspunkt
ist ein mit der Unified-Modeling-Language UML grafisch und objektorientiert
beschriebenes Systemmodell, nachfolgend UML-Systemmodell genannt.
Das Verfahren ist gleichermaßen
für andere Beschreibungssprachen
geeignet, die technische Systeme objektorientiert beschreiben.
-
In
einer ersten Phase a) erfolgt eine Extraktion der aktiven Objekte
des UML-Systemmodells,
sowie deren Eigenschaften und Relationen. Die für eine Verklemmung relevanten
Eigenschaften des UML-Systemmodells werden dabei extrahiert und
in mathematische Strukturen, wie zum Beispiel Listen, Mengen und
Tupel abgespeichert, die eine Auswertung mit einem effektiven Algorithmus
in den nachfolgenden Phasen ermöglichen.
-
Bei
der Extraktion werden alle aktiven Klassen des UML-Systemmodells
hinsichtlich ihrer Kommunikationseigenschaften analysiert. Konkret
bedeutet dies, dass für
jede aktive Klasse ein Satz von erzeugten Ereignissen und konsumierten
Ereignissen berechnet und in Erzeuger-Ereignis-Listen und Verbraucher-Ereignis-Listen
abgespeichert wird. In dieser Hinsicht werden Aufruf-Ereignisse
als Verbraucher-Ereignisse und Aufrufaktionen als Erzeuger von Ereignissen
angesehen. Ereignisse werden nur dann berücksichtigt, wenn ihre Erzeuger
und Verbraucher geeignet assoziiert sind.
-
In
einer zweiten Phase b) erfolgt eine Analyse zur Erkennung potentieller
Verklemmungs-Ereignisse. Diese Analyse kann durch statische Auswertung
eines UML-Zustandsdiagramms
erfolgen, um herauszufinden, welche Warte-Relationen zwischen den
aktiven Objekten existieren. Für
diesen Zweck wird ein Zustands-Warte-Graph eingefügt, der im Unterschied zum
klassischen Wartegraphen den internen Zustand der aktiven Objekte
wiedergibt. Die Detektion von Zyklen in dem Zustands-Warte-Graphen initiiert
die Existenz und den Ort potentieller Verklemmungen.
-
Eine
potentielle Verklemmung ist eine zyklische Wartesituation zwischen
konkurrierenden oder parallelen Komponenten eines Systems, die sich
jeweils innerhalb eines spezifischen Zustands befinden. Die potentiellen
Verklemmungen können
in einem Zustands-Warte-Graphen erkannt werden. Dies ist ein gerichteter Graph,
in dem jeder Knoten ein aktives Objekt in einem spezifischen Zustand
(des zugeordneten Zustandsdiagramms) und jede Kante eine "Warte-auf"-Relation darstellt.
Die Anzahl der Scheitelpunkte des Zustands-Warte-Graphen ist die
gleiche wie die Anzahl von Zuständen
aller Zustandsdiagramme des Modells, die aktiven Klassen zugeordnet
sind. Die Anzahl der Kanten hängt
von den in diesen Zustandsdiagrammen definierten Transitionen ab.
Der Kopf jeder Kante ist mit dem auf ein spezifisches Ereignis wartenden
Knoten verbunden. Der mit dem Ende der Kante verbundene Knoten ist
ein potentieller Urheber dieses speziellen Ereignisses.
-
Die
Analyse potentieller Verklemmungs-Situationen startet mit der Erzeugung
eines Zustands-Warte-Graphen. Dies wird durch Berechnung der in
der Phase der Extraktion der aktiven Objekte und deren Eigenschaften
und Relationen, zum Beispiel durch Berechnung von Konsumenten- und
Produzenten-Listen durchgeführt.
Nach Erzeugung des gesamten Zustands-Warte-Graphen des Systems können potentielle
Verklemmungs-Situationen detektiert werden. Eine potentielle Verklemmungs-Situation ist eine
Situation, in dem zwei oder mehrere Objekte jeweils in einem spezifischen
Zustand gegenseitig auf die Erzeugung eines bestimmten Ereignisses
warten.
-
Bei
dem erfindungsgemäßen Verfahren
werden nunmehr in der Phase b) alle Zyklen in dem Zustands-Warte-Graphen
detektiert und die relevanten Zyklen aussortiert. Dabei sind Zyklen
keine potentiellen Deadlocks, sondern logische Fehler in dem korrespondierenden
Zustandsdiagramm, bei denen alle Knoten des Zykluses dasselbe Objekt
sind. Zyklen mit zwei oder mehr Knoten unterschiedlicher Objekte
sind hingegen potentielle Deadlock-Situationen, wenn kein Objekt
mit mehr als einem Zustand in dem Zyklus involviert ist. Andernfalls
handelt es sich um Zyklen mit "überbeteiligten" Objekten. Die Detektion
aller Zyklen in dem Zustands-Warte-Graphen wird mit einem verbesserten
an sich bekannten Tiefensuchalgorithmus (Depth-First- Search Algorhythm)
durchgeführt,
der alle Zyklen des Graphen und die Aufteilung in einem einzigen
Durchlauf berechnet. Die Erkennung logischer Fehler und Zyklen mit "über-beteiligten" Objekten wird unter
Verwendung von Mengen-Operationen (Set-Operations) durchgeführt. Anschließend werden
die verbleibenden potentiellen Deadlock-Situationen hinsichtlich
der abgehenden Kanten untersucht. Dies wird durch Durchquerung des
Graphen und Berechnung des Ausgangsgrades von jedem Knoten durchgeführt. Der
Ausgangsgrad ist die Anzahl der vom Knoten abgehenden Kanten. Wenn
alle Knoten einen Ausgangsgrad von eins haben, liegt eine potentielle
Deadlock-Situation im Sinne der Erfindung vor. Falls Knoten mit
einem Ausgangsgrad von mehr als eins vorhanden sind, hängt es von
dem Zielobjekt der aus dem Zyklus herausweisenden Kante ab, ob der
untersuchte Zyklus ein potentieller Deadlock ist. Wenn das Zielobjekt
nicht in den betrachteten Zyklus involviert ist, handelt es sich
bei dem untersuchten Zyklus nicht um einen Deadlock. Andernfalls
muss überprüft werden,
ob die Kanten zwei Zustände
des gleichen Objektes verbinden. Falls bei dieser Überprüfung festgestellt
wird, dass die Kanten zwei Zustände
des gleichen Objektes verbinden, wird der potentielle Deadlock mit
einem logischen Fehler kombiniert und der logische Fehler sollte
korrigiert werden, bevor die Deadlock-Erkennung weitergeführt wird.
Ansonsten wird ein weiterer Zyklus in dem Zustands-Warte-Graphen
erkannt, der später
auszuwerten ist. In diesem Fall kann die nächste Phase c) initiiert werden,
da die Zyklendetektion sicherstellt, dass alle Zyklen aufgefunden
und separat in der weiteren Analyse der Erreichbarkeit der potentiellen
Verklemmungs-Situationen abgearbeitet werden.
-
Potentielle
Verklemmungs-Situation (Deadlock) bedeutet, dass es statistisch
möglich
ist, dass ein Deadlock auftritt. Ob das Deadlock-Ereignis tatsächlich während der
Laufzeit eintritt hängt
jedoch von dynamischen Aspekten des Systemmodells ab, die in der
nächsten
Phase c) der Analyse der Erreichbarkeit der potentiellen Verklemmungs-Situationen
separat von der Phase b) der Analyse zur Erkennung potentieller
Verklemmungs-Situationen untersucht wird.
-
Falls
keine potentiellen Verklemmungs-Situation in der Phase b) aufgefunden
werden, ist das System verklemmungsfrei und die nächste Phase
c) kann übersprungen
werden.
-
In
der Phase c) erfolgt dann die Analyse der Erreichbarkeit der potentiellen
Verklemmungs-Situationen. Hierbei wird jedes in der Phase b) erkannte
potentielle Verklemmungs-Situation untersucht, indem die möglichen
Pfade in die potentiellen Verklemmungs-Situationen unter Verwendung
eines Suchalgorithmus berechnet und dahingehend mit einem heuristischen
Simulationsansatz analysiert werden, ob diese Pfade ausführbar sind.
Der Suchalgorithmus führt
eine spezialisierte Tiefensuche für jedes relevante Zustandsdiagramm durch
und speichert alle Pfade zu potentiellen Verklemmungs-Situationen
in einer Pfadliste. Jede Pfadliste enthält alle Zustände und
Transitionen des jeweiligen Pfades.
-
Die
Pfadlisten werden als Eingangsdaten für die nachfolgende heuristische
Simulation genutzt. In der Simulation werden die Zustandsautomaten
des UML-Systemmodells
mit einem Simulator ausgeführt,
der die exakte UML-Semantik gemäß OMG-Standard
(www.omg.org) implementiert. Neben sehr speziellen Merkmalen, wie
die Warteschlangenlänge
und die Untersuchungsreihenfolge von in den Semantiken definierten
Ausdrücken
müssen
die folgenden Aspekte des Modells berücksichtigt werden:
Wächterbedingungen,
Ereignisparameterwerte und Atributwerte.
-
Für den Fall,
dass eine oder mehrere Pfade in eine potentielle Deadlock-Situation
vorhanden sind, ist es ausreichend, einen ausführbaren Pfad während der
Simulation aufzufinden. Der andere Fall ist wesentlich aufwendiger.
Wenn alle Pfade der Pfadliste einmal ausgeführt wurden und dabei kein ausführbarer
Pfad aufgefunden wurde kann nicht gefolgert werden, ob ein ausführbarer
Pfad vorhanden ist oder nicht. Auch nach theoretisch unendlich vielen
Ausführungen
kann nicht mit abschließender
Sicherheit ausgesagt werden, dass die nächste Ausführung nicht in eine potentielle
Deadlock-Situation führt.
Es wird daher vorgeschlagen, die Simulation nach einer festlegbaren
Anzahl n von Ausführungen
abzubrechen.
-
Der
Nachteil dieses heuristischen Simulationsansatzes ist, dass die
Nichtexistenz von Deadlocks nicht bewiesen werden kann, falls potentielle
Verklemmungs-Situationen
vorliegen, die in der Phase c) nicht erreichbar sind, d. h. bei
denen kein ausführbarer
Pfad nach einer Anzahl n Simulationen aufgefunden wurde. In diesem
Ausnahmefall hilft nur eine aufwendige Suche über einen vollständig ungefalteten
Zustandsraum zur Modellprüfung.
-
In
der letzten Phase d) werden die Analyseergebnisse dann dargestellt.
Dies kann beispielsweise mit einem erweiterten UML-Sequenzdiagramm
erfolgen.
-
Das
erfindungsgemäße Verfahren
wird nachfolgend an Hand eines Beispiels eines Mess-Systemmodells
beschrieben, das aus einem ersten und zweiten Sensor Sensor1 und
Sensor2, einer Steuerungseinheit Controller sowie einer Uhr besteht.
Die Sensoren Sensor1, Sensor2 verfügen über eine Messeinheit, die die eigentliche
Messung durchführt
und deren Verhalten im Mess-Systemmodell abstrahiert wird. Die Uhr
verfügt über ein
Uhrwerk, dass das Fortschreiten der Zeit modelliert und bei Aufruf
den aktuellen Zeitpunkt zurückliefert.
Auch von der exakten Funktionsweise der Uhr wird im Mess-Systemmodell
abstrahiert. Die Uhr wird von den Sensoren Sensor1, Sensor2 benötigt, um
die Messwerte mit Zeitstempeln zu versehen. Die Steuerungseinheit
Controller ist für
das Starten der Komponenten zuständig
und fragt zur Laufzeit des Systems immer wieder beide Sensoren Sensor1,
Sensor2 ab. Das System kann durch den Benutzer gestartet und gestoppt werden.
Das Verhalten des Benutzers kann zu Analysezwecken modelliert werden.
-
Die 2 lässt die
statische Systemstruktur des Mess-Systemmodells in Form eines Klassendiagramms
erkennen.
-
Die
im Klassendiagramm verwendeten Zeichnen + und – stehen für die Sichtbarkeit des Elements, dem
sie vorangestellt sind. Alle mit „+" annotierten Elemente (Operationen und/oder
Attribute) sind als öffentlich
(public) deklariert. Diese sind für alle anderen Klassen, die
mit der betreffenden Klasse assoziiert sind, sichtbar. Elemente,
die mit „-" annotiert sind,
sind privat (private) und deshalb nur innerhalb der betreffende Klasse
sichtbar. D. h., dass die privaten Elemente zwar von der Klasse
selbst zum Beispiel im zugehörigen Zustandsdiagramm
aufgerufen werden können,
aber nicht von anderen Klassen. Im Beispiel sind alle Operationen
der Klassen öffentlich,
d. h. mit „+" deklariert. Nur
die Attribute, die zum Speichern von Werten dienen sind privat mit „-" deklariert. Dies
entspricht dem Geheimnisprinzip in der objektorientierten Modellierung
und bewirkt, dass die Werte der Attribute von Klassen nur mit deren
Operationen manipuliert werden können,
und schränkt
die Gefahr von Seiteneffekten ein.
-
Es
wird deutlich, dass der Benutzer in einer Anfrage "Gebe_Messwert" für zwei Werte
Wert 1, Wert2 stellt, die dieser vom Controller als Parameter zurückerhält. Der
Controller startet den Messprozess mit dem Befehl "+Start()" und fordert Messwerte
des ersten und zweiten Sensors Sensor1, Sensor2 an (Gebe_Messwert_Sensor1,
Gebe_Messwert_Sensor2).
-
Die
Anfrage wird über
die Komponente Sensor an die Messeinheit weitergeleitet, die die
eigentliche Messung durchführt,
wobei ein Zeitstempel mit dem Befehl "Gebe_Zeitstempel" von der Uhr bei der Messung für jeden
Sensor Sensor1, Sensor2 abgefragt wird. Die Messwerte werden über die
Sensoren Sensor1, Sensor2 zusammen mit dem Zeitstempel an den Controller
und über
diesen an den Benutzer zurückgeschickt.
-
Die 3 lässt ein
Blockdiagramm der dynamischen Systemstruktur des Mess-Systemmodells erkennen.
Es wird deutlich, dass der Controller zur Parametrierung der Uhr
genutzt wird, die ihrerseits die Zeitmessungen Zeitmessung 1, Zeitmessung
2 bei der Messung durch die Sensoren Sensor1, Sensor2 vornimmt.
Die Messwerte werden zusammen mit dem Zeitstempeln als Signale Messung
1, Messung 2 an den Controller und über diesen an die Umgebung
eines Benutzers zurückgeschickt.
-
Das
Verhalten der einzelnen Systemelemente ist wie folgt:
Die 4 lässt die
Verhaltenssicht des Controllers als Diagramm erkennen. Nach der
Initialisierung parametrisiert der Controller die Uhr und startet
diese mit dem Befehl "Start/Uhr.Start". Weiterhin wird
die erste Messung (Messung 1) durch den Befehl "Sensor.Anfrage_Messwert" angestoßen. Anschließend wird
der Messwert des ersten Sensors abgefragt (Gebe_Messwert_Sensor1
(Messwert)/Messwert 1: = Messwert) und die zweite Messung (Messung
2) durch den zweiten Sensor (Sensor2) mit dem Befehl "Sensor2.Anfrage_Messwert" angestoßen. Von
der zweiten Messung (Messung 2) erfolgt eine Rückkopplung zur ersten Messung
(Messung 1) mit den Anfragen "Gebe_Messwert_Sensor2(Messwert)/Messwert
2: = Messwert" der
erneuten Anfrage des Messwerts bei Sensor1 durch den Befehl "Sensor1.Anfrage_Messwert" sowie gegebenenfalls
die Weitergabe der Messwerte an den Benutzer durch den Befehl "Benutzer.Gebe_Messwert
(Messwert 1, Messwert 2)„.
-
Diese
Schleife wird solange durchlaufen, bis Stoppsignale für die Uhr,
den Sensor1 und den Sensor2 ausgeschickt werden (Stop/Uhr.Stop);
Sensor1.Stop; Sensor2. Stop).
-
Die 5 lässt die
Verhaltenssicht des Sensors1 erkennen. Nach Initialisierung erfolgt
die Messung mit einer Anfrage nach dem Zeitstempel bei der Uhr mit
dem Befehl "Anfrage_Messwert/Uhr.Anfrage_Zeitstempel_Sensor1 ". Das Ergebnis des
Zustands Hole_Zeit ist die Weitergabe des Zeitstempels an den Sensor1
zur Verknüpfung
mit dem Messwert Sensor1 (Gebe_Zeitstempel/Aktuell:=Messeinheit.
Messung(); Controller.Gebe_Messwert_Sensor1(Aktuell).
-
Nach
Erhalt des Stopp-Signals "Sensor1.Stop" wird der Zustand "Messen" beendet.
-
Die 6 lässt eine
entsprechende Verhaltenssicht des Sensors2 erkennen. Für die Erläuterung
wird das vorher gesagte verwiesen.
-
Die 7 lässt die
Verhaltenssicht der Uhr erkennen. Nach Initialisierung erfolgt der
Zustand der Parametrierung der Uhr durch den Controller und es wird
mit dem Signal "Start" ein laufender Zustand "laufend" angeregt. Dieser
Zustand gibt einen Zeitstempel an den Sensor1 (Sensor1.Gebe_Zeitstempel(Zeitstempel)) weiter
und beantwortet die Anfrage nach einem Zeitstempel durch den Sensor2
durch Setzen des Zeitstempels auf die aktuelle Uhrzeit des Uhrwerks
(Anfrage_Zeitstempel_Sensor2/Zeitstempel: = Uhrwerk.aktuelle_Zeit()). Solange
ein Zustand "Anfrage_1" noch eine Anfrage
nach einem Zeitstempel durch einer der Sensoren Sensor1, Sensor2
feststellt, wird mit den Befehlen "Anfrage_Zeitstempel_Sensor2/Zeitstempel:
= Uhrwerk.Aktuelle_Zeit" der
Zeitstempel für
den Sensor2 festgestellt und dem Sensor2 mit dem Befehl "Sensor2.Gebe_Zeitstempel(Zeitstempel)" ein Zeitstempel
zugeordnet.
-
Ansonsten
wird mit dem Befehl "Stop" der Zusand gestoppt.
-
Die
Verhaltenssicht des Benutzers ist in der 8 dargestellt.
Nach der Initialisierung wird im Zustand "Starte" durch den Befehl "Controller.Start" die Steuerungseinheit gestartet und
der Zustand "Beobachter" aufgerufen, indem
das Ereignis "Gebe-Messwert" von der Steuerungseinheit
abgefordert wird. In dem anschließenden Zustand "Beobachter2" wird auf den Messwert
von der Steuerungseinheit gewartet und in einer Schleife durch die
Anfrage "Gebe-Messwert" von der Steuerungseinheit
weitere Messwerte abgefordert. Der Zustand wird durch den Befehl "Controller.Stop" an die Steuerungseinheit
beendet.
-
Für dieses
beispielhafte Mess-Systemmodell wird nun zurückkommend auf die 1 auf
die Phasen a) bis d) im einzelnen eingegangen.
-
In
der Phase a) der Merkmalsextraktion werden die für die Deadlock-Detektion benötigten Merkmale aus
dem UML-Systemmodell extrahiert und in den im folgenden dargestellten
Strukturen gespeichert.
-
Zunächst wird
unter Berücksichtigung
der statischen und dynamischen Struktursicht (Klassen- und Objektdiagramme)
ermittelt, welche Komponenten des Systems bei der Analyse zu berücksichtigen
sind. Da dies von der Art des UML-Systemmodells abhängt, muss
das UML-Systemmodell in einer speziellen Form (UML-Dialekt) vorliegen.
Im vorliegendem Beispiel wird von der Erzeugung der einzelnen Komponenten
des Systems abstrahiert. Es wird davon ausgegangen, dass beim Start
des Gesamtsystems alle aktiven Objekte erzeugt werden und über alle
Eigenschaften verfügen,
die im Klassendiagramm für
die zugehörigen
Klassen modelliert wurden. Die Links (Instanzen der Assoziationen
zwischen den Klassen) zwischen den Objekten haben die Eigenschaften,
die die zugehörigen
Assoziationen im Klassendiagramm tragen.
-
Ferner
wird davon ausgegangen, dass bei der Instanziierung von Objekten,
die ihnen durch Kompositionsbeziehungen zugeordneten Objekten ebenfalls
instanziiert werden. Deshalb sind alle im Objektdiagramm dargestellten
Objekte gerade die in der Detektion zu berücksichtigenden.
-
Je
nach Einsatzgebiet der Unified Modeling Language bzw. dem entsprechenden
UML-Profil kann dieser Teil der Merkmalsextraktion unterschiedlich
ausfallen. Dies ist jedoch nicht Gegenstand der vorliegenden Erfindung.
-
Nachdem
aus dem Objektdiagramm alle aktiven Objekte extrahiert und in einer
Objekt-Liste gespeichert wurden, wird diese Liste genau einmal durchlaufen,
und zu jedem Objekt die dazugehörige
Klasse in einer Klassen-Liste gespeichert. Die Länge der Klassen-Liste wird
als Anzahl_Klassen gespeichert. Dann wird zu jeder Klasse in der
Klassen-Liste, d. h. den aktiven Klassen, das dazugehörige Zustandsdiagramm
analysiert und der dort spezifizierte Zustandsautomat in der Zustandsautomaten-Liste gespeichert.
-
Anschließend werden
alle Objekte an Hand der zugeordneten Klassen in der Klassen-Liste
hinsichtlich ihrer produzierten Aktionen untersucht. Dazu muss jeweils
der richtige Zustandsautomat aus der Zustandsautomaten-Liste selektiert
werden und alle Transitionen der Reihe nach untersucht werden. Jede
Transition kann 0 bis n = beliebig viele Aktionen auslösen. Von
den verschiedenen Typen der Aktionen, die in der UML-Sprache definiert
sind, werden vom Verfahren nur die Aufruf-Aktionen (Call Actions) berücksichtigt.
Ferner kann das Verfahren optional auch Signal-Aktionen (Send Aktions)
berücksichtigen.
Da in der Regel je nach Art der Modellierung nur einer der beiden
Typen von Aktionen verwendet werden, wird das Verfahren nachfolgend
nur hinsichtlich der Aufruf-Aktionen beschrieben.
-
Die
gefundenen Aufruf-Aktionen werden in einer Aktionen-Tabelle gespeichert,
die wie folgt aufgebaut ist:
-
Dabei
ist in der Aktionen-Tabelle unter dem Eintrag Objekt der Objektnahme
zu finden und unter dem Eintrag Aktion eine Menge von O bis m Aktionen,
die jeweils aus den Komponenten Zustand, Zielobjekt und Zielereignis
bestehen. Die Anzahl m ist die Anzahl der Aktionen, die durch eine
Transition ausgelöst
werden können.
Der Zustand ist der Zustand des Zustandsautomaten, in dem das Objekt
die Aktion erzeugen kann, wenn die dazugehörige Transition schaltet. Das
Zielobjekt ist das Objekt, an dass die Aufruf-Aktion adressiert ist.
Das Zielereignis ist das Ereignis (Event) des Zielobjekts, das dabei
erzeugt und in dessen Eingabe Warteschlange (Input-Queue) gelegt
wird.
-
Danach
wird eine Wartemengen-Tabelle erzeugt. Diese ergibt sich, indem
für jedes
Objekt aus der Objekt-Liste über
die dazugehörige
Klasse aus der Klassen-Liste der zugehörige Zustandsautomat aus der
Zustandsautomaten-Liste selektiert und festgestellt wird, auf welche
Ereignisse (Events) das Objekt in welchem Zustand wartet und welches
Objekt das jeweilige Ereignis erzeugen kann. Die Information, welches
Objekt das jeweilige Ereignis erzeugen kann, wird aus der Aktionen-Tabelle
entnommen.
-
Die
Wartemengen-Tabelle hat die folgende Form:
-
Dabei
ist unter dem Eintrag Objekt analog zu einer Aktionen-Tabelle der
Objektname verzeichnet. Die Wartemenge ist so strukturiert, dass
zu jedem Zustand des Zustandsautomaten des Objekts eine Menge von Objekt-Zustandskombinationen
gespeichert werden kann. Eine Objekt-Zustandskombination hat die
Form „Objekt.
Zustand", wobei
hierbei "Objekt" das Objekt bezeichnet,
auf das gewartet wird und "Zustand" den Zustand, auf
den gewartet wird.
-
In
der oben genannten Tabelle wartet zum Beispiel das Objekt 1 in Zustand
1 auf das Objekt 2 in Zustand 1 und das Objekt 2 in Zustand 2. Wie
jede andere Menge in der Mathematik ist auch die Wartemenge frei
von Duplikaten.
-
Nach
Erstellung der Wartemengen-Tabelle werden alle Ergebnisse der Merkmalsextraktion
in einer Struktur „Modell-Merkmale" zusammengefasst,
die einen effizienten Zugriff auf alle Merkmale zuläßt und diese in
den anderen Phasen b), c) und d) zur Verfügung stellt.
-
Für das beispielhafte
Messsystemmodell sind die Ergebnisse der Merkmalsextraktion die
folgenden:
| Anzahl-Klassen
= | 5 |
| Objekt-Liste
= | [Ben- > Objekt, Con- > Objekt, Sn1- > Objekt, Sn2- > Objekt, U- > Objekt] |
| Klassen-Liste
= | [Benutzer- > Klasse, Controller- > Klasse, Sensor1- > Klasse, Sensor- > Klasse, Uhr- > Klasse] |
-
-
-
Nach
der Erstellung der Wartemengen-Tabelle werden diese Merkmale in
der Struktur „Modell-Merkmale" zusammengefasst
und den weiteren Phasen b), c) und d) des Verfahrens zur Verfügung gestellt.
Hierdurch wird ein effizienter Zugriff auf die verschiedenen Merkmale
ermöglicht.
-
In
der Phase b) „Potentielle
Deadlock Detektion" wird
aus der Wartemengen-Tabelle ein sogenannter Zustands-Wartegraph
(State-Wait-Graph) erzeugt. Dies ist ein Graph, dessen Knoten Objekt-Zustandskombinationen
bezeichnen und dessen Kanten „Warte-Auf"-Beziehungen (Wait-For-Relations)
bezeichnen. Aus diesem Graph lassen sich Aussagen wie Objekt 1 wartet
in Zustand 1 auf Objekt 2 in Zustand 1, etc. treffen. Analog zu
den Wartemengen sind die Kantenmengen von Graphen duplikatsfrei.
Dies vereinfacht die Anwendung von Algorithmen auf Graphen und verringert
deren Komplexität.
-
Eine
potentielle Verklemmungs-Situation (Deadlock) im Sinne des betrachteten
Verfahrens ist eine zyklische „Warte-Auf"-Beziehung mit einigen
weiteren Eigenschaften.
-
Die
Phase b) der Analyse zur Erkennung potentieller Verklemmungs-Situationen
arbeitet in zwei Stufen. In der ersten Stufe wird eine Zyklenerkennung
auf dem Zustands-Warte-Graph durchgeführt. Das Ergebnis ist eine
Menge potentieller Verklemmungs-Situationen. In der zweiten Stufe
werden diejenigen potentiellen Verklemmungs-Situationen aus der
Menge der potentiellen Deadlocks ausgesondert, welche die folgenden
Eigenschaften aufweisen:
- a) ein Objekt ist
mit mehreren Zuständen
am Deadlock beteiligt;
- b) es existiert eine Kante zu einem Objekt, das am Deadlock
nicht beteiligt ist;
- c) nur ein Objekt ist am Deadlock beteiligt.
-
Alle
nicht ausgesonderten Verklemmungs-Situationen bilden die endgültige Menge
der potentiellen Deadlocks.
-
Das
Verfahren zur Zyklenerkennung basiert auf dem allgemein bekannten
Tiefensucheverfahren (Depth-First-Search).
-
Die 9 lässt einen
beispielhaften Zustands-Wartegraphen für das Messsystemmodell erkennen.
-
Nach
der Zyklenerkennung ist die Menge der potentiellen Deadlocks wie
folgt:
((Ben.Beobachte2, Con.Messung2), (Con.Messung1, Sn1.Hole_Zeit,
U.Laufend, Sn2.Messen))
-
Nach
Aussonderung ist die Menge potentieller Deadlocks reduziert wie
folgt:
((Con.Messung1, Sn1.Hole_Zeit, U.Laufend, Sn2.Messen))
-
Die
potentielle Verklemmungs-Situation (Ben.Beobachte2, Con.Messung2)
wurde ausgesondert, weil eine Kante im Zustands-Wartegraphen von
Con.Messung2 nach Sn2.Hole_Zeit existiert und deshalb für ihn die
oben genannte Bedingung b) erfüllt
ist, d. h. dass eine Kante zu einem Objekt existiert, das am Deadlock nicht
beteiligt ist.
-
Die
finale Menge potentieller Deadlocks wird an die nächste Phase
c) der Analyse der Erreichbarkeit der potentiellen Verklemmungs-Ereignisse übergeben.
-
Die „Deadlock-Erreichbarkeitsanalyse" dient dem Nachweis,
dass die gefundenen potentiellen Deadlocks zur Laufzeit des Systems
erreichbar sind. Auch hier gibt es verschiedenen Standardverfahren,
die zur Erreichbarkeitsanalyse eingesetzt werden können. Besonders
wichtig für
das vorliegenden Verfahren ist, dass in der Phase der Deadlock-Erreichbarkeitsanalyse
nicht die Laufzeitvorteile, die durch die äußert günstige Zeitkomplexität resultieren,
verschenkt werden. Die erforderliche Zeit verhält sich voraussichtlich linear
zu der Anzahl der Kanten und Knoten des Zustands-Wartegraphen.
-
Aus
diesem Grunde werden bei der Erreichbarkeitsanalyse in der Phase
c) Heuristiken eingesetzt. Es werden neben den Ereignissen (Events)
und Aktionen (Actions) an den Transitionen (Transitions) auch Wächter-Bedingungen
(Guard-Conditions) der Zustandsautomaten berücksichtigt.
-
Der
erste Schritt der Analyse der Erreichbarkeit der potentiellen Verklemmungs-Ereignisse ist die
Berechnung der lokalen Pfade der beteiligten Objekte. Dazu werden
sogenannte Pfad-Listen konstruiert, die aus den Zustandsautomaten
des Modells abgeleitet werden können.
Anschließend
wird die Ausführung
des Modells simuliert, indem ausgehend vom initialen Zustand des
Modells geprüft
wird, welche Transitionen jeweils aktiviert sind, d. h. welche Transitionen
schalten können.
Transitionen können
genau dann schalten, wenn die Wächter-Bedingung
wahr ist und das Ereignis in der Eingabewarteschlange liegt. Dann
wird nach einer geeigneten Heuristik jeweils diejenige Transition
ausgewählt,
die das Modell näher
an die potentielle Verklemmungs-Situation heranbringt.
-
Die
Simulation bricht ab, wenn die potentielle Verklemmungs-Situation
erreicht wurde oder alle Pfade eine festgelegte Anzahl n mal durchlaufen
wurden und kein potentieller Zustand der Verklemmung erreicht werden
konnte. Im letzteren Fall kann keine Aussage gemacht werden, ob
der potentielle Zustand der Verklemmung noch erreicht werden kann.
-
Bei
der Erreichbarkeitsanalyse werden Pfadlisten und Spuren-Mengen (Traces
set) generiert. Dabei haben Pfadlisten die Form: Pfadliste
= {[(Z1, Z2), ..., (Zi, Zj)], ...},wobei (Z1, Z2) ein geordnetes
Paar ist, bei dem Z1 den Quellzustand einer Transition, Z2 den Zielzustand
der Transition bezeichnet und Zj in der Menge der potentiellen Verklemmungs-Situationen
liegt.
-
Ein
Modellzustand für
ein Modell mit einer Anzahl n von Objekten ist gegeben durch < O_1.Z,
..., O_n.Z, O_1.A_1, ..., O_n.A_m, ES_1, ... ES_n >,wobei O_i, 1 < i < n, m > = n das jeweilige
Objekt bezeichnet und Z den jeweils aktuellen Zustand des Objektes.
-
A_j,
1 < = j < = m ist der aktuelle
Wert des jeweiligen Attributs des betreffenden Objektes und
ES_i
ist die Eingabewarteschlange von O_i.
-
D.
h. zu jedem Modellzustand gehört
der Zustand (alle Attributwerte) sowie die Eingabewarteschlange aller
Objekte.
-
Die
Spuren-Menge ist die Menge aller Folgen {[M_a,
(O.Z_a, O.Z_b), M_z]},wobei M a der initiale Zustand des Modells
ist und M z der letzte Zustand vor Abbruch der Simulation und (O.Z_a,
O.Z_b) eine Transition des Objektes O von Z_a nach Z_b.
-
Die
Ausführung
von Aktionen, das Auftreten von Ereignissen etc. wird nicht mit
aufgezeichnet, sondern ist an der Änderung des Modellzustandes
erkennbar.
-
Die
Ergebnisse der Erreichbarkeitsanalyse am Beispiel des Messsystemmodells
sind wie folgt:
-
Eingabe:
-
- Menge der potentiellen Verklemmungs-Situationen nach Aussonderung
= {{Con.Messung1, Sn1.Hole_Zeit, U.Laufend, Sn2.Messen}}
-
-
-
In
der Phase d) werden die Analyseergebnisse dann dargestellt. Die
Visualisierung des Verfahrensergebnisses richtet sich an den Systementwickler
mit fundierten UML-Kenntnissen und Erfahrungen in der Systemmodellierung.
Wesentliches Darstellungsmittel ist dabei das bekannte Sequenzdiagramm,
in dem sehr gut dargestellt werden kann, nach welcher Sequenz von
Nachrichten die Deadlocksituation eintritt.
-
Die 10 lässt das
Sequenzdiagramm für
das Ergebnis der Erreichbarkeitsanalyse anhand des untersuchten
beispielhaften Messsystemmodells erkennen.
-
Im
Beispiel wurde für
die Darstellung der an der Verklemmungs-Situation beteiligten Nachrichten
das graphische Symbol ←←-----------
verwendet, welches für
den Stereotyp <<deadlock>> steht.
-
Ein
Rahmen mit abgerundeten Ecken dient, dazu, die am Deadlock beteiligten
Nachrichten optisch zusammenzufassen. Zusätzlich werden in einem Notizkasten
die Zustände
der am Deadlock beteiligten Objekte angegeben.
