Entwickeln mit UML
Das richtige Diagramm zur richtigen Zeit
Fortsetzung des Artikels von Teil 1
Einstieg und Werkzeuge
Trotz aller Unterschiede in Inhalt und Detailtiefe, bevor das erste Diagramm entsteht, ist erst einmal ein Grundgerüst, also eine Struktur für das Modell anzulegen. Fast alle Modellierungs-Tools stellen Ordner, Pakete oder Ähnliches für die Strukturierung des Modells zur Verfügung. Diagramme und Notationselemente werden dann in dieser Struktur einsortiert, denn ein Modell, in dem sich niemand zurechtfindet, ist für den Entwicklungsprozess wenig nützlich. Im ersten Schritt ist die Analysephase von der Designphase zu trennen.
Auch wenn beide Phasen im Entwicklungsprozess iterativ durchlaufen werden, sollten die Ergebnisse im Modell separiert sein. Oft sind zu einem späteren Zeitpunkt Änderungen fällig; dann ist es hilfreich zu wissen, was tatsächlich eine Vorgabe war (Analyse) und was geändert werden kann, weil es Teil der selbst gewählten Lösung ist (Design). In solchen Situationen hilft es übrigens, auch Gründe für Design-Entscheidungen und Alternativen in dem Modell mit zu dokumentieren.
In der Analysephase entstehen meist Vorgaben an die Systemfunktionen (etwa durch Use- Cases nach u.a. [3], [2]) und an die fachliche Struktur (beispielsweise durch eine objektorientierte Analyse nach u.a. [1]). Die Unterteilung des Designordners richtet sich nach den Sichten, die sie bilden (zum Beispiel das 4+1-Sichtenmodell nach [4]).
Das Werkzeug
Ist die Vorbereitung abgeschlossen, kann die tatsächliche Modellierungsarbeit beginnen. Die Aufgabe des Analysten oder Architekten ist es hierbei, die für das Projekt relevanten Informationen im Modell zu dokumentieren. Dazu muss er erstens entscheiden, welche Informationen überhaupt relevant sind, und zweitens, wie diese bestmöglich dargestellt werden. Bei der ersten Entscheidung helfen ihm Erfahrung und Kommunikation mit Projektkollegen. Für die zweite Art der Entscheidung muss der Verantwortliche sein »Werkzeug« – also die UML – kennen. Was bietet nun also die UML? Generell teilen sich die Diagramme der UML in zwei Kategorien auf:
- Strukturdiagramme zur Darstellung statischer Aspekte (Aufbau, Struktur, Abhängigkeiten, Verbindungen, etc.) und
- Verhaltensdiagramme zur Darstellung dynamischer Aspekte (Abläufe, Szenarien, Interaktionen, Verhalten, etc.).
Jobangebote+ passend zum Thema
Bild 1 zeigt die Einteilung aller UML-Diagramme in diese beiden Kategorien. Die erste Frage, die sich ein Modellierer stellen muss, lautet also: Ist der zu dokumentierende Inhalt dynamischer oder statischer Natur? Eine Kombination statischer und dynamischer Aspekte ist leider in keinem der Diagramme vorgesehen. Man muss sich also für eines entscheiden.
An dieser Stelle soll nicht jedes Diagramm einzeln erklärt werden, hierfür siehe beispielsweise [6]. Vielmehr gilt, entlang des Entwicklungsprozesses zu betrachten, welche Tätigkeiten typischerweise durchgeführt werden, und welche Diagramme sich für deren Dokumentation eignen.
Werkzeuge für die Analyse
In der Analyse finden, wie erwähnt, häufig zwei Tätigkeiten statt: eine funktionsorientierte Zerlegung des Systems und/oder eine objektorientierte Zerlegung der Aufgabe. Für den Einstieg in die funktionsorientierte Zerlegung eignet sich besonders das Use-Case-Diagramm, dieses zeigt zum einen den Systemkontext in Form von Akteuren und zum anderen eine grobe Übersicht der typischen Anwendungsfälle (Use- Cases) des Systems. Im weiteren Projektverlauf ist es notwendig, jeden einzelnen Anwendungsfall genauer zu betrachten und die dahinter stehende Systemfunktion zu detaillieren.
Da eine Funktion etwas Dynamisches ist, bieten sich hierfür alle Verhaltensdiagramme an. Abhängig von dem zu beschreibenden Aspekt der Funktion wählt der Analyst das dazu passende Diagramm: Aktivitätsdiagramme betonen eine Reihenfolge von Aktionen beziehungsweise Arbeitsschritten, während bei Interaktionsdiagrammen der Austausch von Nachrichten im Vordergrund steht. Zustandsautomaten wiederum geben vor, welche Zustände das System während des Ablaufes eines Anwendungsfalls einnehmen kann und wie es sich abhängig von seinem Zustand verhält. Bei Echtzeitsystemen kommen zusätzlich noch Timing-Diagramme zur Darstellung von Echtzeitverhalten zum Einsatz.
In der objektorientierten Zerlegung stehen nicht so viele Möglichkeiten offen. Hier lautet die Aufgabe, Objekte zu finden, ähnliche Objekte in Klassen zusammenzufassen, Abhängigkeiten zwischen den Klassen zu finden und die einzelnen Klassen mittels Eigenschaften (Attributen) und Fähigkeiten (Operationen) zu beschreiben. Für die Dokumentation dieses statischen Aspektes eignet sich besonders das Klassendiagramm. Darüber hinaus können auch hier dynamische Aspekte wie zum Beispiel die Zustände eines Objektes oder Interaktionen zwischen Objekten interessieren. Hier kommen wieder das Zustandsautomatendiagramm beziehungsweise das Sequenzdiagramm zum Einsatz.
Werkzeuge für das Design
Das Design besteht bekanntlich aus zwei Abschnitten, der Architektur (auch Grobdesign genannt) und dem Feindesign. In der Architektur finden, außer dem Klassen- und dem Objektdiagramm, so ziemlich alle Diagramme der UML ihre Anwendung. Für Dekompositionsund Kompositionsaspekte, die in der logischen Sicht, der Prozesssicht und der Entwicklungssicht enthalten sind und bei denen die Strukturierung und die Schnittstellendefinition im Vordergrund stehen, eignet sich die Darstellung in Komponentendiagrammen. Um die Funktionen einer Komponente und das Zusammenwirken mehrerer Komponenten zu modellieren, eignen sich wieder die bereits aus der Analyse bekannten Verhaltensdiagramme. Im Grunde führt der Architekt nichts anderes durch, als eine Analyse auf Komponentenebene. Für die physikalische Sicht, in der die Hardware und deren Topologie sowie die Verteilung der Software auf die Hardware gezeigt werden soll, setzt man am besten das Verteilungsdiagramm ein.
Bleiben noch die Szenarien, hier sind wichtige und kritische Anwendungsfälle des Systems durchzuspielen. Die Frage an dieser Stelle lautet: »Welches sind die beteiligten Komponenten, und wie arbeiten diese zusammen?«. Klar ist, dass hier ein dynamischer Aspekt darzustellen ist. Möchte der Analyst dabei mehr Gewicht auf den Informationsaustausch legen, eignet sich ein Sequenzdiagramm. Steht hingegen die Reihenfolge der Arbeitsschritte im Vordergrund, so ist ein Aktivitätsdiagramm geeigneter.
Im Feindesign kommen nun die beiden in der Architektur ausgenommenen Diagramme zum Einsatz, das Klassendiagramm und das Objektdiagramm. Das Feindesign soll darstellen, wie die gefundenen logischen Komponenten im Detail realisiert werden. Während das Klassendiagramm hierbei den prinzipiellen Aufbau aus Klassen und deren Abhängigkeiten zeigt, stellt das Objektdiagramm eine Art Schnappschuss zur Laufzeit dar. Es zeigt, welche Objekte, sprich Instanzen von Klassen, zu einem bestimmten Zeitpunkt existieren und wie diese zusammenhängen.
Modellieren heißt abstrahieren
Zum Abschluss noch ein wichtiger Hinweis. Ein Modell ist stets eine Abstraktion der Wirklichkeit und daher per Definition unvollständig. Also, nur Mut zur Unvollständigkeit! Ein Diagramm ist nicht besser, je mehr Informationen enthalten sind, sondern je präziser es den gewollten Inhalt abbildet. Überlegen Sie sich immer wieder, was Sie in einem Diagramm vermitteln wollen – und was nicht. Im Zweifel sind mehrere Diagramme mit Konzentration auf wenige Aspekte besser als ein einzelnes, völlig überladenes und damit nicht mehr lesbares Diagramm.
Was ist nun also das »richtige« Diagramm zur »richtigen« Zeit? Das richtige Diagramm ist das, mit dem Sie den zu zeigenden Aspekt bestmöglich darstellen können. Es gibt keinerlei Einschränkungen, welche Diagramme in welcher Phase einzusetzen sind. Die richtige Zeit meint nicht einen bestimmten Zeitpunkt im Projektverlauf, sondern vielmehr eine Tätigkeit oder einen Bedarfsfall. Die Antwort kann demnach nicht heißen: »In der ersten zwei Wochen nehmen Sie Use-Case-Diagramme, von der dritten bis zur fünften Woche Aktivitätsdiagramme und anschließend nur noch Komponenten- und Sequenzdiagramme «, sondern sie lautet: »Nehmen Sie Use-Case-Diagramme für eine grobe funktionsorientierte Zerlegung, Aktivitätsdiagramme zur Darstellung von Abläufen, Komponentendiagramme für eine strukturelle Zerlegung, und so weiter «.
- Das richtige Diagramm zur richtigen Zeit
- Einstieg und Werkzeuge
- Literatur und Autorin
