REstrukturierung gefällig? Teil 3

Teil 3: Das Regelwerk für Aktivitätsdiagramme

Klicken Sie hier um das Bild zu vergrößern

Im vorigen Teil unserer Blogserie über STABLE haben wir das Regelwerk zu Use-Case-Diagrammen und die daraus entstehende Anforderungsstruktur betrachtet. Heute wollen wir uns wie angekündigt dem Aktivitätsdiagramm der UML widmen, einem Diagramm zur Modellierung von Abläufen.

Regeln und Varianten
Bevor wir beginnen, möchten wir noch ein paar Worte zu den sogenannten „Varianten“ innerhalb unserer Regelwerke verlieren. Während der Erstellung der Regeln kamen wir oft an Stellen, an denen die Ausprägung der Regel von Projektrandbedingungen abhing. „Wenn man dies und das im Projekt macht, sähe die Regel so aus. Wenn man es aber anders macht, ergäbe sich eine andere Regel.“ Wie sollten wir damit umgehen? Jede eventuelle Kombination durchspielen? Das wäre erstens zu verwirrend und zweitens zu zeitaufwändig gewesen. Daher haben wir an genau diesen Stellen sogenannte „Varianten“ aufgenommen. Also Regeln, die einen Sonderfall abbilden, der aber im weiteren Regelwerk nicht weiter verfolgt wird. Wir halten unsere Regeln für einfach genug, dass wir die Transferleistung auf den Sonderfall getrost dem aufmerksamen Leser überlassen. Warum wir dies hier erwähnen? Ganz einfach, die Einordnung des Aktivitätsdiagrammes startet genau mit solch einer Variante.

Aufbau der Struktur
In unseren Projekten gehen wir fast immer nach der Use-Case-Analyse vor, d. h. wir bilden Use-Cases, die dann durch Aktivitätsdiagramme oder Zustandsautomaten verfeinert werden. Dieses Vorgehen stellt aber natürlich keine Grundvoraussetzung dar um Modelle in eine Anforderungsstruktur zu überführen. Hin und her gerissen zwischen der häufigsten Vorgehensweise und der minimalsten Voraussetzung, haben wir lange überlegt, ob wir die Regelwerke aufeinander aufbauend oder separat von einander definieren sollten. Je länger wir diskutiert haben, desto mehr mögliche Variationen der Verbindung von Diagrammarten sind uns eingefallen (Use-Cases auf oberster Ebene, ein Aktivitätsdiagramm zur Darstellung der Geschäftsprozesse auf oberster Ebene, ein Paketdiagramm auf oberster Ebene….). Nachdem wir uns bei der Wahl der häufigsten Methode nicht recht einig wurden, haben wir es als das Sinnvollste erachtet, KEINE Voraussetzungen an die Methode zu stellen und die Regelwerke als autarke Einheiten zu betrachten.

Demzufolge gehen wir beim Aktivitätsdiagramm genauso wie beim Use-Case-Diagramm von dem einfachsten Fall aus, dass noch nichts existiert. Demnach lauten unsere Grundregeln für den Aufbau der Struktur:

An einem Beispiel sähe das Ergebnis dieser drei Regeln folgendermaßen aus:

Klicken Sie hier um das Bild zu vergrößern

Variante: Einordnung des Aktivitätsdiagrammes in eine bestehende Struktur
Wie bereits erwähnt, geht man in der Analyse häufig nach dem klassischen Use-Case-Ansatz vor. Hierbei werden Use-Cases durch Aktivitätsdiagramme verfeinert um den Ablauf darzustellen, der sich hinter einem Use-Case verbirgt. Ist die Systemspezifikation entsprechend (oder ähnlich) des Regelwerks von STABLE für Use-Case Diagramme gegliedert, so liegt es nahe, das Aktivitätsdiagramm direkt bei dem zugehörigen Use-Case in der Anforderungsstruktur zu dokumentieren. Diesen Fall haben wir als Variante aufgenommen:

Würden man diese Variante weiter verfolgen, so verschöben sich natürlich auch alle weiteren Kapitel, die aus diesem Aktivitätsdiagramm folgen an die entsprechende Stelle in der Struktur. Das Ergebnis sähe wie folgt aus.

 

Klicken Sie hier um das Bild zu vergrößern

Aktivitäten und ihre Reihenfolge
Abläufe in einer Software oder einem System sind selten geradlinig, da gibt es alternative Abläufe, parallele Abläufe, Rücksprünge, Quersprünge und und und. Die UML gibt hierfür verschiedenste Notationselemente zur Modellierung vor. Die wichtigsten darunter sind sicherlich die Verzweigung und die Parallelisierung. Auch hier haben wir lange überlegt, mit welcher Regel wir die Reihenfolge der Aktivitäten am besten festlegen. Vorschläge waren viele da. Beispielsweise angelehnt an die Möglichkeiten einen gerichteten Graphen zu durchlaufen („breadth first“ bzw. „depth first“), hier kam uns jedoch die Semantik hinter den Aktivitäten zu kurz. Wie wäre es mit „Jeweils die Teilpfade bis zum nächsten Kontrollknoten der Länge nach geordnet“, oder „Zuerst den 80% Weg durch das gesamte Diagramm und anschließend alle alternativen Pfade der Häufigkeit nach geordnet“. Alle Möglichkeiten wurden genauso schnell verworfen wie sie gefunden waren. Denn was ist, falls sich Aktivitäten verschieben, gestrichen werden oder neue hinzukommen? Müssen dann alle Kapitel umsortiert werden um die Regel wieder zu erfüllen? Das erschien uns dann doch zu unpraktisch. Wir haben uns nach langem hin und her geeinigt (vorerst) auf jeglichen Formalismus zu verzichtet und folgende drei Regeln für die Reihenfolge aufzustellen:

Klicken Sie hier um das Bild zu vergrößern

Redundanzen und Wiederverwendung
Zum Abschluss möchten wir Ihnen noch eine weitere, sehr interessante Regel dieses Regelwerkes vorstellen. Jede größere Spezifikation, die wir in unseren vielen verschiedenen Projekten zu Gesicht bekommen haben, kämpfte mit dem gleichen Problem: der Redundanz. Redundante Anforderungen machen das Erstellen, Pflegen und Ändern einer Spezifikation zu einer großen Herausforderung. Gerade bei der Modellierung von Aktivitätsdiagrammen, stößt man schnell auf sich wiederholende Anforderungen. Aktivitäten, die sich wiederholen, können dank der Schachtelung an einer Stelle beschrieben und dann an verschiedenen Stellen in unterschiedlichen Aktivitätsdiagrammen wiederverwendet werden. Doch wie überführen wir diese Wiederverwendung in unsere Struktur? Genau nach dem gleichen Prinzip: Auslagern und Referenzieren. Wir haben folgende Regel hierfür definiert:

Regel:

Ergebnis:

Klicken Sie hier um das Bild zu vergrößern

Das Auslagern von Inhalten an eine separate (!) zentrale Stelle hat den Vorteil, dass jeder sofort erkennt, wo Wiederverwendung auftritt. Einfache Verlinkungen in RM-Tools sind hierfür oft nicht präsent genug und allzu oft veraltet. Häufig werden Stellen innerhalb der Spezifikation referenziert, die dann ohne Rücksprache oder Wissen der anderen geändert werden. Für ein separates Kapitel kann leichter festgelegt werden, dass Inhalte nur in Absprache mit allen Verantwortlichen verändert werden dürfen. Um die wiederverwendeten Anforderungen zu finden, muss zudem nicht kreuz und quer durch die Spezifikation „gesprungen“ werden, sondern immer nur an die eine zentrale Stelle.

Durch die explizite Referenzierung der ausgelagerten Stelle ergeben sich zwei Vorteile: Sie erhalten zum Einen den Lesefluss in ihrer Struktur und gewährleisten zum Anderen, dass sich jeder Kollege in Ihrer Spezifikation zurecht findet und nicht auf vermeintliche Spezifikationslücken stößt.

Achtung! Lagern Sie gleichlautende Aktivitäten nie ungesehen aus. Vergewissern Sie sich immer zuerst, dass die dahinter stehenden Aktivitäten auch tatsächlich die gleichen sind.

Wir sind am Ende unseres Eintrages angekommen und hoffen, unser heutiger Einblick in das STABLE-Regelwerk für Aktivitätsdiagramme war interessant und hat Ihr Interesse geweckt. Vorschläge und Kommentare zu Regeln sind uns wie immer herzlich willkommen. Leider reicht der Umfang eines Blog-Eintrages nicht aus, um alle Regeln vorzustellen, die unser Regelwerk für Aktivitätsdiagramme umfasst. Sollten Sie an dieser Stelle Interesse an den kompletten Umfängen des Regelwerks 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.

Im nächsten Eintrag dieser Blogserie werden wir uns mit dem Zustandsautomaten beschäftigen und zeigen, welche Regeln wir zur Überführung von Zuständen, Transitionen und Co. gefunden haben. Wenn Sie schon immer einmal wissen wollten, wie Sie die Informationen aus einem Zustandsautomaten gut strukturiert, natürlichsprachlich dokumentieren können, schauen Sie doch einfach wieder rein!

Hinterlasse eine Antwort

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


1 + fünf =

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>