In der Blog-Reihe „Systementwicklung“ möchten wir Ihnen einen praxisorientierten Überblick zur modellbasierten Dokumentation eines Systems mit Hilfe der Unified Modelling Language (UML) geben. Wir beginnen bei der Systemanalyse und arbeiten uns Schritt für Schritt bis zur System-Architektur vor. Das Hauptaugenmerk liegt dabei auf den Zielen der einzelnen Entwicklungsphasen, den verwendeten UML-Diagrammen und den Möglichkeiten, die Nachverfolgbarkeit von den Anforderungen bis hin zu den Elementen der System-Architektur sicherzustellen.

Wir beginnen in Punkt 1 mit der Analyse der Anforderungen mit Hilfe von Use Cases und beschreiben in Punkt 2 Möglichkeiten wie Sie diese textuell und modellbasiert verfeinern können. In Punkt 3 gehen wir auf das Begriffsmodell ein, mit dem Sie ein einheitliches Sprachverständnis zwischen allen Projektbeteiligten herstellen können.

1. Anforderungen mit Hilfe von Use Cases analysieren

• das Festlegen der System-Grenzen,
• das Identifizieren der Akteure und
• die Ermittlung der nach außen sichtbaren Funktionalität.

Die Ergebnisse modellieren wir mit Hilfe des Use Case-Diagramms der UML. In Abbildung 1 ist ein Ausschnitt eines Bibliothekssystems dargestellt. Es bietet die beiden Use Cases Leihobjekte verwalten und Leihobjekte zurückgeben an. Durch die ungerichteten Assoziationen wird zum Ausdruck gebracht, dass die beiden Akteure Bibliothekar und Kunde an diesen Use Cases beteiligt sind.

Ein Hinweis zur Modellierung von Use Cases: Verwenden Sie die include– und extend-Beziehungen mit Bedacht. Sie verleiten dazu, an Stelle der Use Cases das Verhalten des Systems und damit unterschiedliche Abstraktionsebenen in einem Diagramm zu modellieren.

Damit Sie nicht den Überblick verlieren, welche Anforderungen zu einem Use Case gehören und ob Sie alle Anforderungen berücksichtigt haben, empfehlen wir Ihnen, jede Anforderung mit einem Use Case zu verbinden. Dies können Sie mit unterschiedlichen Möglichkeiten realisieren:

• Einfügen des Identifizierungszeichen der Anforderungen in das Kommentarfeld der Use Case-Elemente.
• Einbinden der Anforderungen in das UML-Modell z.B. mit Hilfe der UML-Erweiterung System Modeling Language (SysML) und Verbinden der Anforderungs-Elemente mit den Use Cases

Welche Möglichkeit für Sie die Passende ist, hängt stark von Ihren Projektbedingungen ab. Als Beispiel ist in Abbildung 2 die erste Möglichkeit für den Use Cases Leihobjekt verleihen dargestellt.
2. Use Cases verfeinern

Sie wissen nun welche Use Cases Ihr System besitzt und welche Akteure an diesen beteiligt sind. Im nächsten Schritt verfeinern Sie die ermittelten Use Cases, um für jeden mindestens die zwei folgenden Fragen zu beantworten:

1. Wann wird der Use Case ausgeführt?
2. Welche Schritte beinhaltet der Use Case?

Dazu stellen wir Ihnen im Folgenden zwei Möglichkeiten vor, die sich auch kombinieren lassen: Die textuelle und modellbasierte Verfeinerung.

2.1 Textuelle Verfeinerung

Für die textuelle Beschreibung eines Use Cases existieren Templates, aus denen Sie sich die für Ihr Projekt benötigten Beschreibungselemente heraussuchen können. Als Minium empfehlen wir:

1. Name
2. Kurzbeschreibung
3. Vorbedingung
4. Fachlicher Auslöser
5. Normalfall (essentielle Schritte)

Wenn Sie die Use Case-Beschreibung als Ergänzung zum UML-Modell verwenden, können Sie die Beschreibungselemente Name und Normalfall (essentielle Schritte) weglassen, um redundante Informationen zu vermeiden. Name ergibt sich aus dem Namen des Use Case-Elements und den Normalfall beschreiben wir mit Hilfe eines UML-Verhaltensdiagramms im nachfolgenden Abschnitt. Abbildung 2 zeigt eine ergänzende Use Case-Beschreibung im Kommentarfeld des Use Case-Elements Leihobjekt verleihen.

2.2 Modellbasierte Verfeinerung

Die UML kennt vier verschiedene Diagrammarten zur Beschreibung von Verhalten:

• Aktivitäts-Diagramm,
• Sequenz-Diagramm,
• Timing-Diagramm sowie der
• Zustandsautomat.

UML-Diagramme haben gegenüber der textuellen Beschreibung den Vorteil der grafischen Darstellung, wodurch beispielsweise komplexere Abläufe für den Betrachter leichter zu erfassen sind.

Abbildung 3 zeigt eine simplifizierte Verfeinerung des Use Cases Leihobjekt zurückgeben. Ein Kunde muss sich zunächst identifizieren. Ist die Identifizierung erfolgreich, identifiziert der Bibliothekar das Leihobjekt und speichert die Ausleihe, falls das Leihobjekt identifiziert werden konnte. Damit endet der Normalfall.

Falls sich das Verhalten nur schwierig mit den vorhandenen Modell-Elementen beschreiben lässt, überprüfen Sie, ob Sie den richtigen Diagramm-Typ gewählt haben. Detaillierte Informationen zu den verschiedenen UML-Diagramme und deren Einsatzbereiche finden Sie im Buch „UML2 glasklar“.
3. Begriffsmodell – Eine Sprache sprechen

Ein großes Problem bei der Sprachkommunikation ist die Eindeutigkeit. Jeder Mensch besitzt ein eigenes Sprachverständnis, was bei der Entwicklung von Systemen schon oft zu Problemen geführt hat. Auch scheinbar unwichtige und allgemein bekannte Details sollten Sie festhalten, um ein einheitliches Verständnis in Ihrem Team und Projekt zu erzielen. Die einfachste Form des Begriffsmodells ist das Glossar in tabellarischer Form. Wir empfehlen Ihnen allerdings die Verwendung von Klassendiagrammen, da diese eine detaillierte Begriffsdefinition erlauben (Prozesswort im Kontext eines bestimmten Substantivs) und zudem eine grafische Darstellung ermöglichen. Auf eine tabellarische Auflistung müssen Sie nicht verzichten, da gute Modellierungswerkzeuge Ihnen den Export des Klassendiagramms ermöglichen.

Im nächsten Teil der Serie zeigen wir Ihnen welche UML-Diagramme Sie zur Modellierung der verschiedenen Sichten auf eine System-Architektur verwenden können. Im 3. Teil widmen wir uns der Nachverfolgbarkeit, mit der Sie überprüfen können, ob alle Analyse-Ergebnisse in der System-Architektur berücksichtigt wurden.