Ergänzende Diagramme Modellierung von Signalfamilien mit UML

Als Notationsform für die modellbasierte Analyse und Dokumentation hat sich die UML in den letzten Jahren immer mehr in den Vordergrund gedrängt und ist mittlerweile aus der modernen Systemanalyse nicht mehr wegzudenken.

Eine der Stärken der UML ist die Trennung der statischen Sicht eines Systems von dessen dynamischer Sicht. Dadurch kann der Analytiker sein Augenmerk auf die für ihn relevanten Informationen legen und diese sauber dokumentieren. Eine der sich hieraus ergebenden Herausforderungen ist es allerdings, diese beiden Sichten wieder in Abhängigkeit zu betrachten, um ein möglichst vollständiges Bild des zu entwickelnden Systems zu erstellen.

Wie ist nun die Verbindung der statischen und dynamischen Sicht auf ein solches System zu betrachten und zu dokumentieren? Im Folgenden konzentrieren wir uns auf die Modellierung von Fehlersignalen innerhalb eines Systems und das von diesen Signalen ausgelöste Verhalten. Ein sehr vereinfachtes Beispiel soll das ganze demonstrieren. Ziel ist es, die Signalkommunikation zwischen den Steuergeräten eines Passagierflugzeuges und der Kontrolleinheit im Cockpit zu beschreiben.

Sollte eines dieser Steuergeräte eine Fehlfunktion feststellen, schickt dieses Steuergerät ein Signal an die zentrale Kontrolleinheit. Es ergibt sich das Diagramm aus Bild 1 und Bild 2.

Je nachdem, welches Fehlersignal die Kontrolleinheit empfängt, wechselt die Kontrolleinheit vom Zustand »flugfähig« in einen der Unterzustände »Triebwerk fehlerhaft« oder »Flugwerk fehlerhaft« des Oberzustandes »nicht flugfähig«. Da sich diese beide Unterzustände unterscheiden, kann man den Zustandsautomat dergestalt erweitern, indem innerhalb des Zustandes »Triebwerk fehlerhaft« ein anderes Verhalten als im Zustand »Flugwerk fehlerhaft« ablaufen könnte.

Für die Modellierung der Signalfamilien ist dies allerdings nicht nötig und daher nur der Vollständigkeit halber erwähnt. Da in der Realität in einem Flugzeug weit mehr Fehlerfälle auftreten können als die im aktuellen Modell dargestellten und bisher auch noch keine Übergänge aus den Fehlerzuständen zurück in den Ausgangszustand modelliert sind, wird schnell klar, dass die hier vorgestellte Modellierungsvariante nur in Systemen mit einer überschaubaren Menge von Signalen funktionieren kann.

In komplexeren Systemen lässt sich dieser Problematik entgegenwirken, indem man die Signalvielfalt aus dem Zustandsautomat in ein UML-Klassendiagramm auslagert und innerhalb des Zustandsautomaten nur noch die Signale modelliert, die für das in diesem Diagramm dargestellte Verhalten relevant sind. Diesen Mechanismus nennen wir die Modellierung von Signalfamilien. Hierfür bedienen wir uns der Generalisierung und Spezialisierung von Klassen innerhalb eines UML-Klassendiagramms.

Signalfamilien im UML-Klassendiagramm

Um eine Familie von Signalen zu modellieren, sucht man nach gemeinsamen Arten von Signalen und definiert damit die Oberklassen der eigentlichen Fehlersignale innerhalb einer Generalisierungshierarchie. Beim Versuch, dieses Prinzip auf das Beispiel anzuwenden, lassen sich zwei übergeordnete Fehlertypen identifizieren, die aus dem dargestellten Inhalt des Zustandsautomaten folgen: Fehlersignale, die zu einem Übergang in den Zustand »Triebwerk fehlerhaft« führen, und Fehlersignale, die in den Zustand »Flugwerk fehlerhaft« führen.

Aus diesem Grund ist es sinnvoll, die beiden Klassen »Flugwerksfehler« und »Triebwerksfehler« einzuführen. Diesen beiden Klassen stellen unsere Oberklassen dar, denen wir nun über eine Spezialisierungsbeziehung die jeweiligen tatsächlichen Fehlersignale zuweisen. Damit haben wir einerseits die benötigten Oberklassen eingeführt und andererseits die bisherigen Klassen weiterhin in unserem Klassendiagramm. Es ergibt sich das Diagramm aus Bild 3.

Anstatt jedes spezialisierte Signal als eigene Klasse zu modellieren, bietet die UML auch die Möglich-keit, diese Blattklassen als Aufzählungstyp für ein Attribut der Basisklassen darzustellen (Bild 4). Auf diese Art und Weise entsteht ein sehr übersichtliches UML-Klassendiagramm mit der Möglichkeit, weitere Fehlersignale als Enumerationswerte in dem jeweiligen Aufzählungstyp aufzuführen, ohne weitere Änderungen in den Diagrammen durchführen zu müssen.

Unabhängig davon, welche Lösung der Systementwickler für die Modellierung der Klassendiagramme wählt (Bild 3 oder Bild 4), ist es nun möglich, die Anzahl der Übergänge im Zustandsautomaten zu verringern, indem die neuen Begriffe aus unserem Klassendiagramm als Trigger für die Zustandsübergänge dienen.

So entsteht ein übersichtlicher Zustandsautomat, der alle relevanten Informationen enthält (Bild 5). Durch den Zusammenhang der dynamischen mit der strukturellen Sicht und die geschickte Hierarchisierung von Signalen erhält man also zwei sich ergänzende Diagramme mit hohem Informationsgehalt und klarer Struktur. Darüber hinaus lässt sich das UML-Klassendiagramm leicht um weitere Signale erweitern, ohne dass die Lesbarkeit zu stark abnimmt. Somit lassen sich Informationen klar strukturieren und allen Beteiligten im Projekt näherbringen.

Über die Autoren:

Malik Tayeh ist Berater mit dem Schwerpunkt auf der natürlichsprachigen Spezifikation von komplexen Systemen im Bereich Automotive und Marco Prillwitz ist Berater und Trainer mit dem Schwerpunkt funktionsorientierte Spezifikation von elektrischen und mechatronischen Fahrzeugsystemen; beide bei Sophist.