DSD und das Aktivitätsdiagramm

Zusammenhängende Abläufe in einzelne Anforderungen transformieren

Dritter Eintrag zu unserer DSD-Serie. Heute geht es um das UML-Aktivitätsdiagramm. Da dieses Diagramm in der Anforderungsanalyse häufig zur Dokumentation von Anforderungen genutzt wird – etwa zur Visualisierung der Abarbeitung von Use Cases – war diese Diagrammart der UML auch Gegenstand der Untersuchungen in diesem Forschungsprojekt. Wie lassen sich die Elemente des Aktivitätsdiagramms also in natürlichsprachliche Anforderungen „übersetzen“? Gleichzeit müssen wir natürlich sicherstellen, dass diese einzelnen Anforderungen vollständig, korrekt, konsistent, möglichst eindeutig, etc. sind – sprich eine möglichst hohe Qualität erhalten.

Hierzu zunächst eine allgemeine Überlegung: In einem Aktivitätsdiagramm stellen wir Anforderungen zusammenhängend dar. Durch die Verbindung von Aktionen und Verhaltensaufrufen über Kontrollflüsse/Objektflüsse und weiterer Elemente wie Entscheidungs-/Verbindungsknoten oder Parallelisierungs-/Synchronisationsknoten kommt ein in sich korrekter und konsistenter Ablauf zustande. Dieser Ablauf ist im Diagramm selbst gut mit dem zugrunde liegenden Token-Konzept prüfbar. Wollen wir ein Aktivitätsdiagramm mit einzelnen Anforderungssätzen beschreiben, so zerreißen wir diese Art der Darstellung, Der im Diagramm sichtbare Ablauf geht zunächst verloren.

Dies würde bedeuten, dass wir uns jeder Aktion annehmen und dafür jeweils eine natürlichsprachliche Anforderung schreiben. Hierzu die in Abbildung 1 gezeigte Formulierung.

Damit aber nicht genug. Hiermit bilden wir nur Anforderungen in Form von Hauptsätzen. Der Zusammenhang der einzelnen Anforderungen fehlt. Diesen Zusammenhang – wie im Aktivitätsdiagramm gegeben – können wir jedoch auch bei der Beschreibung mittels natürlichsprachlicher Anforderungen integrieren. Zwar nicht grafisch, sehr wohl aber inhaltlich. Dies geschieht, indem wir jeder Anforderung mindestens einen Nebensatz voranstellen, der eine Bedingung enthält. Die Semantik der Bedingung ergibt sich aus der vorangegangenen Aktion. Somit stellen wir auch mit einzelnen Anforderungssätzen deren Verbindung untereinander her. Dies ist auch Grundlage für die weiteren Regeln zur Transformation des Aktivitätsdiagramms.

Übrigens: Falls Sie mehr als eine Bedingung für eine Anforderung benötigen ist dies völlig in Ordnung. Jede Bedingung ergibt dann einen Nebensatz. Diese Nebensätze stellen Sie an den Beginn der Anforderung und verbinden die Nebensätze mittels logischer Operatoren wie UND, ODER, XODER. Wird die Bedingungsstruktur einer Anforderung zu komplex und schwer lesbar nutzen sie Zeilenumbrüche und  Klammern.

Eine zweite Regel beschreibt die Abbildung einer Bedingungsstruktur aus einem Aktivitätsdiagramm in natürlichsprachliche Anforderungen. Hier kommt der Nebensatz ins Spiel, der inhaltlich auf die vorangegangene Aktion verweist:

Wollen Sie die Modellierung eines Verbindungsknotens in Textform ausdrücken, müssen Sie darauf achten, dass aus einem von n Zweigen ein Token ankommt und über den Verbindungsknoten in die danach folgende Aktion läuft. D. h. Sie erhalten in diesem Fall ein Satzkonstrukt mit n-Bedingungsnebensätzen – logisch verbunden über den Operator XODER (XOR, exklusives ODER).

Als drittes Beispiel wollen wir Ihnen an dieser Stelle noch eine Zusammenführung zeigen: Das Element des Synchronisierungsknotens. Wir sprechen also von mehreren nebenläufigen Zweigen, die wieder zu einem Fluss synchronisiert werden sollen. Dabei ist im Anforderungssatz darauf zu achten: Der Satz muss klar herausstellen, dass alle n nebenläufigen Zweige erst vollständig durchlaufen werden müssen und erst dann ein Token an die nach dem Synchronisationsknoten folgende Aktion übergeben wird. Dies gelingt uns wiederum sehr einfach über den UND-Operator. Sehen Sie selbst in Abbildung 3.

Neben den drei hier beispielhaft gezeigten Regeln haben wir noch weitere Notationselemente des Aktivitätsdiagrammes untersucht und Regeln zur Anforderungsbildung abgeleitet. Darunter fallen die Notationselemente: der Diagrammname im Diagrammrahmen, Aktivitätsbereiche, Startknoten, Endknoten, Parallelisierungsknoten sowie Signalsender und Signalempfänger.

Bei weiterem Interesse an diesem Thema bleiben Sie uns gewogen. Der nächste Teil dieser Serie wird nicht lange auf sich warten lassen. Oder sie kontaktieren uns hier im SOPHIST Blog oder über heureka@sophist.de.

In der nächsten Folge: das Klassendiagramm und dessen Abbildung in natürlichsprachliche Anforderungen.