Im ersten Teil unserer Blogserie „Modellierung von Signalfamilien“ haben wir uns mit dem Problem beschäftigt, wie unterschiedliche Signale denselben Zustandsübergang in einem Automaten auslösen können. Ausgehend von unserem sehr einfach gehaltenen Beispiel wurde aufgezeigt, welche Probleme bei der Modellierung von verschiedenen Signalen auftreten können. Unser UML-Zustandsdiagramm wirkte unleserlich, ineffizient und sehr komplex. Um diesem Sachverhalt entgegenzuwirken, wechseln wir zunächst von der Verhaltensperspektive in die Strukturperspektive unseres Systems.
Anforderungsaspekte, die die statische Struktur betreffen können durch ein UML-Klassendiagramm dokumentiert werden. So lassen sich wie in unserem Beispiel, unterschiedliche Signale und ihre Beziehungen zueinander darstellen.
Ziel ist die Vereinfachung unseres UML-Zustandsdiagramms mit Hilfe einer geschickten Verknüpfung des UML-Klassendiagramms, in welchem wir unsere Signale dokumentieren.
Um eine Familie von Signalen zu modellieren sucht man nach gemeinsamen Arten von Signalen und platziert sie mittels Vererbung in einer Spezialisierungs-/Generalisierungshierarchie. Dabei werden allgemeinere Signale höher platziert, während man spezialisierte weiter unten positioniert. Doch wie genau lassen sich spezialisierte Signale generalisieren?
In den meisten sehr technischen und ereignisgesteuerten Systemen wäre eine Klassifizierung nach elektronischen und mechatronischen Baugruppen denkbar. In unserem Fall betrachten wir die verschiedenen Fehlerarten und versuchen sie auf geschickte Weise zu generalisieren. Dabei gehen wir vom Abstrakten, Allgemeinen, Übergeordneten schrittweise hin zum Konkreten, Speziellen, Untergeordneten. Dieses Vorgehen bezeichnet man in der Informatik als Top-Down.
Da es sich um Fehlersignale handelt fügen wir eine neue Basisklasse FlugzeugFehler ein. Man nehme nun an, dass man einen Automaten modelliert hat, in dem ein Zustandsübergang durch den Empfang von FlugzeugFehler ausgelöst wird.
Ein Informationsmodell ist eine abstrakte Abbildung von Objekten und ihren Beziehungen zueinander, welches Sie zum Beispiel in einem Glossar innerhalb Ihrer Spezifikation dokumentieren können.
Ist Ihnen diese Unterteilung zu grob und nicht aussagekräftig genug, dann seien Sie gespannt auf den dritten Teil unserer Blogserie „Modellierung von Signalfamilien“, in dem es um die geschickte Unterteilung und Erweiterung unseres Informationsmodells und des UML-Zustandsdiagramms geht.
Grüße aus Nürnberg
Ihre SOPHISTen
Hier finden Sie den 3. Teil der Blogserie Modellierung von Signalfamilien