REstrukturierung gefällig? Teil 2

REstrukturierung gefällig?

Teil 2: Das Regelwerk für Use-Case-Diagramme

Abbildung 1: Use-Case-Diagramme und STABLE

Hier klicken um das Bild zu vergrößern

Im ersten Teil dieser Blog-Serie haben wir Ihnen einiges über die Entstehung und Hintergründe von STABLE erzählt. Unserem Verfahren zur systematischen, regelgeleiteten Strukturierung von Anforderungen angelehnt an die Use-Case-Analyse. Wir haben auch erwähnt, dass wir dieses Verfahren in Form von Regelwerken dokumentiert haben. Ein Regelwerk für jedes der drei wichtigsten Diagrammtypen in der Analyse: Das Use-Case-Diagramm, das Aktivitätsdiagramm und den Zustandsautomaten.  In den kommenden Folgen unserer Blog-Serie wollen wir nun in diese Regelwerke hineinblicken. Da eine vollständige Vorstellung den Rahmen eines Blogs sprengt,  wollen wir anhand einiger ausgewählter Regeln ihren Inhalt zeigen. Beginnen wir also mit dem Regelwerk für Use-Case-Diagramme.

 

Der Einstieg

Die erste Frage, die sich uns gestellt hat, war „Wo innerhalb der Spezifikation ordnen wir uns ein?“ Unsere spontane Antwort: Natürlich im Kapitel „Anforderungen“. Schließlich wollen wir Anforderungen  strukturieren. Genau gesagt erstellen wir anhand der Use-Case-Analyse eine funktionale Sicht auf die Anforderungen, daher ordnen wir uns im Kapitel „Funktionale Anforderungen“ ein, parallel zu den nicht-funktionalen Anforderungen. Falls Sie eine Standard-Spezifikationsstruktur verwenden (wie z.B. VOLERE, IEEE 830-98 oder nach V-Modell XT), ist dieses Kapitel bereits vorhanden und Sie können direkt darin starten. Für alle Anderen gilt folgende Regel:

Ergebnis:

Hier klicken um das Bild zu vergrößern

Exkurs:

An dieser Stelle noch ein Wort zu nicht-funktionalen Anforderungen (NFAen): Manche NFAen lassen sich genau einer Funktion zuordnen (Sicherheitsanforderungen, Antwortzeiten oder Ähnliches) und sollten dann in die Struktur der funktionalen Anforderungen einsortiert werden. Alle nichtzuordenbaren NFAen werden in einem separaten Kapitel beschrieben, für das bereits gute Vorlagen zur Strukturierung existieren (z. B. IVENA oder VOLERE).

 

Das Use-Case-Diagramm einbinden

Eine der nächsten Fragen war: „Sollten Diagramme aus dem Modell in die Spezifikation aufgenommen werden?“ Als Gegenargument kam sofort, dass sie den Umfang des Dokumentes deutlich steigern. Dafür sprach jedoch, dass die Diagramme zum Einen die Lesbarkeit erhöhen und zum Anderen die Beziehung zum Modell herstellen (Stichwort Traceability). Jeder Projektbeteiligte der das Modell kennt, findet sich schnell in der Spezifikation zurecht, allen Anderen bieten die Diagramme einen guten Überblick über den Inhalt der Anforderungen. Daher haben wir uns für folgende Regel entschieden:

Ergebnis:

Hier klicken um das Bild zu vergrößern

 

 

Die erste Gliederungsebene aufbauen

Use-Case-Diagramme werden meist zu Beginn der Analyse erstellt und bewegen sich auf einer sehr groben Ebene der Systembeschreibung. Daher können wir sie prima verwenden, um die erste Gliederungsebene unserer Anforderungsstruktur zu bilden. Doch was ist mit der Reihenfolge? Von oben nach unten, nach Anzahl der Assoziationen, alphabetisch sortiert, nach Detaillierungsebenen sortiert…was soll es denn sein? Könnte ein Tool dies bei einer Automatisierung auswerten? Nach langem überlegen haben wir uns darauf besonnen, dass Use-Case-Diagramme per Definition keine Reihenfolge für die abgebildeten Funktionen vorgeben. Daher lautet unsere Regel:

Ergebnis:

Hier klicken um das Bild zu vergrößern

TIPP: Falls im Projektverlauf neue Anforderungen entstehen, können diese ohne Probleme in die STABLE Struktur einsortiert werden. Beziehen sich die neuen Anforderungen auf bestehende Use-Cases? Dann ordnen wir sie in den Kapiteln dieser Use-Cases ein. Falls nicht, legen wir neue Use-Cases im Diagramm und in der Struktur an. Eine Spezifikationsstruktur die mit dem STABLE Regelwerk aufgebaut ist, kann also sehr einfach erweitert werden!

 

Die Gliederungsebenen vertiefen

Bei großen Systemen geht die Anzahl der Use-Cases oft weit über die 7+/-2 hinaus (ein genannter Rekord lag bei 104!!), hier kann es sinnvoll sein Use-Cases zu hierarchisieren. Sprich, ein Use-Case dient nur als eine Gruppierung ähnlicher Funktionen und wird durch ein weiteres Use-Case-Diagramm verfeinert. In unserer Struktur sähe dies folgendermaßen aus:

Ergebnis:

Hier klicken um das Bild zu vergrößern

 

Erweitern von Use-Cases

In einem Use-Case-Diagramm können Beziehungen zwischen Use-Cases existieren. Eine Art von Beziehung ist die Erweiterung, dargestellt durch <<include>> oder <<extend>> Verbindungen. Diese Beziehung bereitete uns einiges Kopfzerbrechen. Der erweiternde Use-Case stellt einen Teil des erweiterten Use-Cases dar, er sollte also innerhalb dessen Kapitel stehen. Was aber, falls mehrere Use-Cases ihn einbinden? Redundant beschreiben oder darauf verweisen? Und wo innerhalb des Kapitels? Einfach am Anfang oder mit weiteren Verfeinerungen (z. B. Aktivitäten) in richtiger Ablaufreihenfolge? Wie die Ablaufreihenfolge bestimmten? Was wenn der erweiternde Use-Case auch als eigenständige Funktion nutzbar ist? Dann müsste er wiederum auf die oberste Kapitelebene. Müssen wir hier unterscheiden, wird es dann nicht zu kompliziert, was wenn sich dies im Laufe der Zeit ändert? Unsere Entscheidung: Alle Use-Cases eines Diagrammes werden auf der gleichen Kapitelebene beschrieben. Das Einbinden wird durch Anforderungen beschrieben. Damit ist die Struktur am einfachsten nachvollziehbar und muss bei Änderungen im Modell nicht ständig überarbeitet werden.

Doch hier tat sich schon die nächste Frage auf: Beschreibt man zuerst die erweiterten oder die erweiternden Funktionen? Bei Ersterem muss man während des Lesens immer nach hinten springen, bei Letzterem fehlt evtl. der Kontext…. Nach langer, langer Diskussion haben wir uns für folgende einfache Regel entschieden:

Ergebnis:

Hier klicken um das Bild zu vergrößern

Sie sehen, hinter den einfach anmutenden Regeln steckt viel Diskussion und Abwägung zwischen Einfachheit und Präzision. Natürlich umfasst das komplette Regelwerk noch weitaus mehr Regeln, doch wir wollen hier einen Schlussstrich ziehen und zum Ende kommen. Sie haben gesehen, dass Sie aufbauend auf den Regeln, die STABLE für die Überführung von Use-Case-Diagrammen bietet, eine grobe Struktur ihrer Spezifikation erstellen können und hierfür noch nicht einmal detaillierte Analyseergebnisse benötigen. Sie können also sehr früh in der Analysephase bereits einen Container für Anforderungen aufbauen und müssen nicht erst am Ende mit dem Sortieren beginnen.

Sollten wir es geschafft haben, Sie neugierig zu machen, schauen Sie doch einfach in der nächsten Zeit wieder einmal in unseren Blog. Im nächsten Teil unserer STABLE-Serie werden wir das Regelwerk für Aktivitätsdiagramme genauer unter die Lupe nehmen und auch hier einige unserer Erkenntnisse mit Ihnen teilen. Bei Interesse an den vollständigen Regelwerken schreiben Sie uns einfach an heureka@sophist.de.

Hinterlasse eine Antwort

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


9 + vier =

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>