Heute wollen wir uns mit einer der vielen Problemstellungen befassen, mit denen man bei der Modellierung mit der UML in Berührung kommen kann. Sollten Sie bereits in der Praxis modelliert haben, kennen Sie diese Situation bestimmt auch. Sie möchten einen Sachverhalt modellieren, allerdings ist dieser so komplex, dass Ihre Modelle aufgrund der vielen in ihnen enthaltenen Informationen nur noch für Sie und vielleicht noch für die Ersteller der UML Superstructure zu verstehen sind.

Wir wollen Ihnen eine der vielen Möglichkeiten aufzeigen, wie Sie Ihre Modelle vereinfachen können, ohne dabei wichtige Informationen zu unterschlagen.

Als Beispiel soll uns heute die Startvorbereitung eines Flugzeuges dienen. Wie Sie bestimmt bereits in dem einen oder anderen Hollywoodfilm gesehen haben, werden vor dem Start eines Flugzeuges immer noch ein letztes Mal alle Komponenten auf Einsatzfähigkeit überprüft. Der Einfachheit halber gehen wir davon aus, dass eine einzelne Komponente, der Hardwarecontroller, all diese Komponententests überwacht. Sollte eine der restlichen Komponenten im Flugzeug (z. B. das Fahrwerk oder das Triebwerk) einen irgendwie gearteten Fehler aufweisen, schickt die fehlerhafte Komponente ein Signal an den Hardwarecontroller, damit dieser den Start verhindern kann. In einem Zustandsdiagramm ausgedrückt könnte man dies wie folgt modellieren.

Wie Sie sehen können, befindet sich der Hardwarecontroller zu Beginn im Zustand „Aktiv“. Sollte nun ein Fehlersignal empfangen werden, stößt dieses Ereignis eine Transition vom Zustand „Aktiv“ in den Zustand „Nicht flugfähig“ an.

Auf den ersten Blick sieht unser Modell sehr gut aus. Geht man aber davon aus, dass in einem Flugzeug weit mehr Fehlerfälle auftreten können als die im Modell dargestellten sieben Signale und dass der Zustandsautomat des Hardwarecontrollers in der Realität etwas umfangreicher ist als hier dargestellt, kommen wir sehr schnell an die Grenzen dieser Modellierungsvariante.

Wie lässt sich dieses Dilemma nun lösen? Da alle Signale das gleiche Verhalten auslösen (eine Transition vom Zustand „Aktiv“ in den Zustand „Nicht flugfähig“), gibt es die Möglichkeit, alle Ereignisse, die dieselbe Transition auslösen (in diesem Fall die Fehlersignale), auf dieselbe Transition zu setzen. Unser Modell würde nach dieser Lösung wie folgt aussehen.

Wie Sie sehen können, hat sich die Lesbarkeit des Diagrammes bereits erheblich gesteigert. Allerdings funktioniert dieser Lösungsansatz auch nur bis zu einer gewissen Menge an Ereignissen (Signalen), die dieselbe Transition auslösen. Würden wir die Anzahl der Signale verdoppeln, würden wir auch hier an die Grenzen dieser Modellierungsvariante geraten.

Aber was heißt dies nun für die Praxis? Müssen Sie in Ihren Zustandsautomaten mit redundanten Transitionen wie in Bild 1 leben oder stattdessen den „Tod der 1000 Ereignisse“ sterben wie in Bild 2 gezeigt?

Natürlich nicht, denn die UML bietet die Möglichkeit, Signale zu „Signalfamilien“ zusammenzufassen, um genau diese Probleme zu umgehen. Doch wie man dies in einem Modell darstellt, und vor allem welche Probleme bei der Modellierung von Signalen zu lösen sind, werden wir im zweiten Teil dieser Blogreihe beantworten.

Grüße aus Nürnberg
Ihre SOPHISTen

Hier geht es zum zweiten Teil unserer Blogserie Modellierung von Signalfamilien