REstrukturierung gefällig? Teil 4

Teil 4: das Regelwerk für Zustandsautomaten

Klicken Sie hier um das Bild zu vergrößern

 

Was bisher geschah: Nach einer kurzen Übersicht zur Entstehung und dem Inhalt von STABLE – unserem Verfahrens zur systematischen, regelgeleiteten Strukturierung von Anforderungen – haben wir uns die beiden Regelwerke für Use-Case Diagramme und Aktivitätsdiagramme ausschnittsweise angesehen. Heute werden wir uns dem dritten und bisher letzten Regelwerk widmen. Dem Regelwerk für Zustandsautomaten (oder genauer gesagt für Zustandsautomatendiagramme). Zustandsautomaten werden, genauso wie Aktivitätsdiagramme, häufig dazu verwendet Use-Cases zu verfeinern. Dies ist jedoch kein zwingendes Vorgehen und wie bereits in der letzten Folge erläutert, haben wir versucht unser Regelwerk an keinerlei Voraussetzungen zu binden. Wir haben im Folgenden  zur Einfachheit keine eventuell darüber liegenden Use-Cases betrachtet.

Da bei der Erstellung der Struktur und der Einordnung der Diagramme das gleiche Vorgehen wie bei Aktivitätsdiagrammen gilt, wollen wir diesen Teil überspringen und uns direkt ansehen, wie wir die einzelnen Notationselemente in eine Anforderungsstruktur überführen.

Zustände und deren Reihenfolge

Betrachten wir zunächst die Zustände, die wohl wichtigsten Elemente in einem Zustandsautomaten. Ähnlich wie bei den Use-Case-/ und Aktivitätsdiagrammen lauten die Regeln zur Überführung der Zustände:

Auch über die Reihenfolge der Zustände haben wir uns wieder Gedanken gemacht und heiß diskutiert. Herausgekommen sind folgende zwei Regeln:

Beispiel:

Klicken Sie hier um das Bild zu vergrößern

Die zweite Regel bzgl. der Reihenfolge von Zuständen klingt zugegebenermaßen etwas kryptisch. Sie bedeutet nichts anderes, als dass Sie das Muster, mit dem Sie sich bei der Beschreibung durch Ihren Automaten bewegen, selbst wählen können. Wir haben es nicht für sinnvoll gehalten hier ein bestimmtes Muster vorzugeben, da die Wahl sehr vom Inhalt des Diagrammes abhängt. Das einzige was Sie nicht machen dürfen, sind Sprünge zu einem Zustand, der von keinem der bisher beschriebenen Zustände erreichbar ist. Der Leser soll dadurch die Möglichkeit haben sich auf einem nachvollziehbaren Pfad durch den Automaten zu bewegen und nicht wahllos gedanklich hin und her springen müssen.

Vorstellbar wären nach unserer Regel beispielsweise:

  • ein sternförmiges Muster (immer alle möglichen, noch nicht beschriebenen Folgezustände von einem Zustand aus) oder
  • ein lineares Muster (Entscheidung für jeweils einen möglichen Folgezustand).

Reihenfolgeregeln, die wir verworfen haben sind unter anderem:

  • Alphabetische Ordnung (reißt die fachliche Verbindung der Zustände auseinander)
  • Ordnung anhand einer vergebenen Nummerierung (zu viel Gefahr für Inkonsistenzen und Aufwand durch die Vergabe der Nummern)

Übergänge zwischen Zuständen

Das zweitwichtigste Element nach den Zuständen sind die Transitionen (Zustandsübergänge). Um Zustandsübergänge in die Anforderungsstruktur zu überführen, haben wir folgende Regeln definiert:

Beispiel:

Klicken Sie hier um das Bild zu vergrößern

Parallele Unterzustandsautomaten

Um am Ende noch eines der interessanteren Notationselemente zu betrachten, sehen wir uns die Unterzustandsautomaten an. Das Zustandsautomaten-Diagramm bietet, genau wie das Aktivitätsdiagramm, eine Möglichkeit zur Schachtelung, hierbei wird ein Zustand durch einen internen Unterzustandsautomaten verfeinert. Genau wie bei den Aktivitätsdiagrammen werden sämtliche Inhalte der Schachtelung unterhalb des verfeinerten Elementes in die Struktur überführt. Eine Weiterführung dieses Schachtelungs-Konzeptes sind die parallelen Unterzustandsautomaten. Hierbei wird ein Zustand durch zwei oder mehrere parallel laufende Unterzustandsautomaten verfeinert. Auch hierfür haben wir Regeln definiert:

Beispiel:

Klicken Sie hier um das Bild zu vergrößern

 

Damit endet nun unsere kleine Reise durch die STABLE Regel-Welt. Sollten wir Ihr Interesse an den kompletten Umfängen unseres Regelwerks geweckt haben, melden Sie sich einfach per E-Mail an heureka@sophist.de oder telefonisch unter 0911 40 900-0 bei uns. Wir freuen uns auf Sie und senden Ihnen gerne weitere Informationen zu.

Wie zu Anfang angekündigt, haben wir uns bisher nur mit dynamischen Diagrammen der UML beschäftigt, die zur funktionsorientierte Zerlegung eines Systems verwendet werden. Doch damit geben wir uns natürlich nicht zufrieden. Eines unserer Ziele für 2010 ist es, am Konzept von STABLE weiter zu arbeiten und um statischen Diagrammtypen zu erweitern, die für eher Datenorientierte Systeme gerne verwendet werden.

STABLE 2 – To be continued …

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


8 − = sechs

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>