Willkommen zum letzten Teil unserer Blogreihe. Lassen Sie uns kurz rekapitulieren welche Methoden zur Modellierung von Signalfamilien wir im Verlauf der letzten Wochen kennengelernt haben, um das Thema anschließend mit der Modellierung von Transitionen aus den Unterzuständen zurück zu unserem Ursprungszustand abzuschließen.
Ausgehend von einem simplen Zustandsautomaten mit 2 Zuständen und einer großen Anzahl gleichartiger Transitionen haben wir gelernt, dass man mithilfe der Hierarchisierung von Signalen innerhalb eines Informationsmodells Signale des gleichen Typus zusammenfassen kann. Durch die Spezialisierung der Klasse „FlugzeugFehler“ in drei Unterklassen und die weitere Spezialisierung in weitere Unterklassen konnten wir einen Zustandsautomaten modellieren der leicht zu lesen, trotz allem aber noch alle nötigen Informationen enthielt, um als vollständiges Analysemodell fungieren zu können.
Daraufhin konnten wir einen weiteren Aspekt betrachten, nämlich das Verhalten das durch den Empfang der verschiedenen Signaltypen ausgelöst wurde. Durch die Erweiterung des Zustandsautomaten um drei Unterzustände mit unterschiedlichen Zustandsverhalten war es uns möglich das Blinken von drei LEDs darzustellen, das durch den Empfang des jeweiligen Signaltypen angestoßen wird.
Wie eingangs bereits erwähnt wollen wir heute die Rücktransitionen aus unseren Fehlerzuständen zurück zum Ausgangszustand „flugfähig“ modellieren. Da aktuell noch keine Signale definiert wurden die unsere Fehlerfälle aufheben, müssen wir in einem ersten Schritt unser Informationsmodell erweitern.
Eine Möglichkeit dies darzustellen besteht daraus, für jedes mögliche Fehlersignal in unserem System ein zweites Signal zu modellieren dass die Aufhebung des Fehlerfalles signalisiert. Dies erreichen wir indem für analog zu unserer Oberklasse „FlugzeugFehler“ eine zweite Oberklasse zu generieren die durch eine Assoziation mit „FlugzeugFehler“ verbunden ist. Unsere neue Klasse nennen wir „FlugzeugFehlerKorrigiert“. Die Assoziation zwischen diesen beiden Klassen versehen wir nun mit der Multiplizität „1….1“. Dies sagt aus das jedes Signal von Typ „FlugzeugFehler“ über genau ein Gegenstück vom Typ „FlugzeugFehlerKorrigiert“ verfügt. Abschließend spezialisieren wir die Klasse „FlugzeugFehlerKorrigiert“ auf dieselbe Weise wie wir es bereits bei „FlugzeugFehler“ kennengelernt haben und modellieren damit auf diese Weise für jedes Fehlersignal ein Gegenstück.
Wie Sie sehen können befinden wir uns wieder einmal an dem Punkt, dass durch die Masse an in unserem Modell enthaltene Information die Lesbarkeit des Modelles leidet. Deshalb möchten wir Ihnen eine weitere Variante zeigen mithilfe derer sich Generalisierungsbeziehungen in einem Klassendiagramm darstellen lassen.
Anstatt jedes spezialisierte Signal als eigene Klasse zu modellieren, gibt es nämlich auch die Möglichkeit unsere Blattklassen als Enumerationwerte eines Attributes seiner Oberklassen darzustellen.
Dies modelliert man mit der UML wie folgt. In einem ersten Schritt wird eine Enumeration angelegt die wir „FlugwerkSignalTyp“ nennen. Diese Klasse wird nun Attributen versehen die unseren bisherigen spezialisierten Flugwerkfehler Klassen entsprechen. Da unsere neuen Enumerationwerte auch für unsere Korrektur Signale verwendet werden sollen, bleiben wir bei der Bennenung der Attribute abstrakter und nennen diese nur noch „Fahrwerk“ oder „Rumpfwerk“ und lassen die Unterscheidung zwischen Fehler und Korrektursignalen vorerst weg. Die neue Enumeration „FlugwerkSignalTyp“ enthält demnach die fünf Attribute „Fahrwerk“, „Rumpfwerk“, Tragwerk“, Steuerwerk“ und „Leitwerk“. Anschließend versehen wir die Klasse „FlugwerkFehler“ mit einem Attribut „FehlerTyp“ vom Typ „FlugwerkSignalTyp“ und entfernen unsere bisherigen spezialisierten Klassen aus dem Modell. Zu lesen ist das Modell nun wie folgt. Die Klasse „FlugwerkFehler“ verfügt über ein Attribut „FehlerTyp“ das die Werte annehmen kann die wir in der Klasse „FlugwerkSignalTyp“ als Attribute angelegt haben. Analog dazu verfahren wir mit unseren Generalisierten Korrektursignalen. Einziger Unterschied an dieser Stelle ist das wir die Attribute „Korrekturtyp“ anstatt „FehlerTyp“ nennen. Mit dieser Modellierungsvariante können wir nun alle Spezialisierungen unserer Fehlersignale aus dem Diagramm entfernen ohne dass dabei Informationen verloren gehen.
Wie Sie sehen hat die Lesbarkeit im Vergleich zu unserem ersten Entwurf wieder stark zugenommen.
Nachdem unser Informationsmodell wieder vollständig ist, können wir uns nun dem Zustandsautomaten zuwenden und die letzten fehlenden Transitionen nachtragen.
Jeder Fehlerzustand erhält nun eine Transition zurück zum Zustand „flugfähig“. Als Trigger für diesen Übergang wird nun das jeweilige Korrektur-Signal auf die Transition gelegt und der Zustandsautomat ist letztendlich vollständig.
Wir hoffen dass wir Ihnen mit dieser Blogreihe einige interessante Methoden zur Signalmodellierung näher bringen konnten, die Sie auch in der Praxis anwenden können und hoffen dass Sie uns auch weiterhin treu bleiben. Denn auch wenn wir dieses Thema vorerst abschließen, haben wir bereits weitere, interessante Praxistyps für die Modellierung mit der UML in der Hinterhand die Sie in den folgenden Monaten hier finden können.
Schöne Grüße aus Nürnberg.
Die SOPHISTen
Hier finden Sie den 4. Teil der Blogserie Modellierung von Signalfamilien.