Session D-UML

Vom Use Case zum Implementations-Modell
Modellierung mit UML

Manfred Rätzmann
(raezz@t-online.de)

Was ist die Unified Modeling Language (UML)?

Die UML ist eine grafische Notation zur Spezifikation, Konstruktion und Dokumentation von Systemen. Sie ist also von ihren Erfindern nicht nur für Software-Systeme konzipiert worden. Das zeigt sich am besten daran, daß UML Diagramme bereits in der Analysephase eingesetzt werden können. Dort geht es ja noch nicht darum, das zu erstellende Softwaresystem zu beschreiben, sondern das Geschäftsumfeld in Form eines Business-Models. Auch für ein solches Business-Model können bereits alle in der UML verfügbaren Diagrammtypen sinnvoll eingesetzt werden.

Diese Session möchte Ihnen einen Überblick darüber geben, welche Diagrammtypen die UML 1.3 verwendet und wie und wo Sie diese Diagramme bei der Modellierung einsetzen können. Für eine vollständige Erläuterung aller syntaktischen Möglichkeiten der UML reicht die Zeit hier natürlich nicht aus. Deshalb finden Sie auf der Konferenz-CD ein Glossar über alle Begriffe, Diagrammtypen und syntaktischen Elemente der UML. Dieses Glossar wurde zusammengestellt von Bernd Oesterreich, Autor des sehr empfehlenswerten Buches "Objektorientierte Softwareentwicklung, Analyse und Design mit der Unified Modelling Language" und kann auch von der Adresse http://www.oose.de/glossar runter geladen werden.

Die UML 1.3 kennt folgende Diagrammtypen:

  • Anwendungsfalldiagramm (engl. Use Case Diagram)
  • Aktivitätsdiagramm (engl. Activity Diagram)
  • Klassendiagramm (engl. Class Diagram oder Static Structure Diagram)
  • Sequenzdiagramm (engl. Sequence Diagram)
  • Kollaborationsdiagramm (engl. Collaboration Diagram)
  • Zustandsdiagramm (engl. State Diagram)
  • Komponentendiagramm (engl. Component Diagram)
  • Verteilungsdiagramm (engl. Deployment Diagram)

Anwendungsfalldiagramm

Ein Anwendungsfalldiagramm zeigt Akteure und Anwendungsfälle, also wer das System anwendet und was er oder sie damit tut. Ein einfaches Rechteck symbolisiert die Systemgrenzen. Akteure können Personen oder interne Systemkomponenten (z.B. ein Timer) sein. Sie können rechts und links vom System angesiedelt werden um zum Beispiel zwischen firmeninternen und externen Personen zu differenzieren. Zwischen Akteuren ist auch eine Vererbungshierarchie möglich.

Die Anwendungsfälle geben alle Arten der Systembenutzung wieder. Über die "uses" Beziehung läßt sich darstellen, daß innerhalb eines Anwendungsfalls ein anderer Anwendungsfall auftritt, der aber auch alleine auftreten kann. Die "extends" Beziehung gibt an, daß ein Anwendungsfall einen anderen erweitert.

Anwendungsfälle werden textlich beschrieben. Zu einem Anwendungsfalldiagramm wird es also immer mehrere Dokumente geben, die die dargestellten Anwendungsfälle beschreiben. Diese Dokumente haben meist eine einheitliche Struktur, die zumindest Akteure, Vorbedingungen , Ablaufbeschreibung, Variationen und Endzustand umfaßt.

Zum Einsatz von UseCases in der objektorientierten Analyse gibt es auf dieser Konferenz eine eigene Session D-CASE von Ulli Gellesch. Wenn Sie dieses erfolgreiche Analysekonzept für Ihre eigene Arbeit anwenden wollen, schauen Sie sich unbedingt Ullis Session an.

Aktivitätsdiagramm

Aktivitätsdiagramme beschreiben Abläufe im System oder bei dessen Benutzung an Hand von Aktivitäten. Häufig werde Aktivitätsdiagremm dazu eingesetzt, Anwendungsfälle detaillierter darzustellen als dies mit einem Anwendungsfalldiagram möglich ist.

Aktivitätsdiagramme ähneln den prozeduralen Flußdiagrammen. Sie können in Zuständigkeitsbereiche aufgeteilt werden (sog. Swimlanes). Ausgehend von einem Anfangszustand des Systems (ausgefüllter Kreis) werden die Aktivitäten durchlaufen und führen zu einem Endzustand (ausgefüllter Kreis mit äußerer Kreislinie). Dabei kann sich die Ablauffolge aufteilen (Fork) um parallele Abläufe darzustellen und danach wieder zu einem Strang vereinen (Join). Aktivitäten können auch mehrere Ausgänge haben, die von Bedingungen abhängen. Darüber hinaus kann man Bedingungen auch unabhängig von einer Aktivität für eine Verzweigung des Ablaufs angeben.

Zusätzlich können Aktivitäten Objektzustände hervorrufen (hier nicht dargestellt), die wiederum bei einer nächsten Aktivität vorausgesetzt werden können.

Klassendiagramm

Ein Klassendiagramm stellt die im System vorkommenden Klassen und deren Beziehung zueinander dar. Das ist die wohl bekannteste Diagrammform der UML. Die Beziehungen zwischen den Klassen können Vererbung (Generalization), Benutzung (Association), Enthalten-sein (Composition, Containment, Aggregation) oder Abhängigkeit (Dependency, nicht dargestellt) beschreiben. Jeder Beziehung kann eine Kardinalität für die an der Beziehung beteiligten Klassen mitgegeben werden.

Klassendiagramme sind statische Diagramme. Anders als Aktivitätsdiagramme, Sequenzdiagramme oder Kollaborationsdiagramme (siehe unten) enthalten sie keine Aussage darüber, zu welcher Zeit Objekte instantiiert werden, einander aufrufen, wieder freigegeben werden usw.

Sequenzdiagramm

Ein Sequenzdiagramm zeigt Objekte und deren Aufrufe untereinander zur Laufzeit. Wichtig ist hierbei die vertikale Zeitachse, die durch die gestrichelten Lebenslinien unter jedem Objekt dargestellt wird. Die Aufrufe können als Methodenaufrufe (procedure calls) als synchrone oder asynchrone Nachrichten oder auch als Aufrufe eigener Methoden entlang der Lebenslinie ausgelegt werden. Je nach gewünschtem Detallierungsgrad können auch Aufrufparameter und Rückgabewerte angegeben werden.

Kollaborationsdiagramm

Ein Kollaborationsdiagramm zeigt, ähnlich wie ein Sequenzdiagramm, welche Objekte bei einer bestimmten Systemaktivität zusammenarbeiten. Die zeitliche Abfolge der Aufrufe kann hier durch vorangestellte Reihenfolgenummern angegeben werden. Kollaborationsdiagramme werden aber vorrangig benutzt um darzustellen, welche Objekte überhaupt in einer bestimmten Situation zusammenarbeiten. Die Zeitachse spielt hier also eine untergeordnete Rolle.

Zustandsdiagram

Ein Zustandsdiagramm zeigt, in welchen Zuständen (States) ein Objekt sich während seiner Lebensdauer befindet. Das hier beschriebene Objekt ist dabei meistens kein konkretes Objekt sondern ein allgemeines Objekt als Repräsentant seiner Klasse, also Ein_Kunde (als Repräsentant der Klasse "Kunden") nicht Kunde_Meier (als konkretes Objekt). Die dargestellten Zustandsübergänge sind Aufrufe von Methoden dieses Objektes oder eintretende Ereignisse. Methodenaufrufe und Ereignisse können mit Bedingungen verknüpft werden, unter denen das Objekt dann in den einen oder anderen Zustand wechselt.

Komponentendiagramm

Komponentendiagramme zeigen den physischen oder logischen Aufbau eines Systems. Physische Einheiten werden häufig als Komponenten dargestellt. Das kann eine ausführbare Datei, eine Klassenbibliothek, eine DLL oder ähnliches sein.

Pakete.

Logische Einheiten werden dagegen meistens als Pakete (Packages) dargestellt. Diese Unterscheidung ist allerdings nicht zwingend. Die UML bezeichnet als Package einfach eine Zusammenfassung von Modellelementen.

Verteilungsdiagramm

Verteilungsdiagramme zeigen die Verteilung der physischen Systemresourcen. Knoten werden durch Quader dargestellt und können zusätzlich zu ihrem Namen noch einen Typ angeben. Knoten können Komponenten oder Objekte enthalten.

UML-Diagramme benutzen, ein Vorgehensmodell

In der Software-Entwicklung hat sich die UML inzwischen als Standard durchgesetzt. Die Vorläufer wie die Notation von Grady Booch oder die OMT Notation von Rumbaugh (die ja beide in die UML eingeflossen sind) werden heute immer seltener eingesetzt. Jedes neuere Modellierungstool unterstützt inzwischen die UML-Notation, wobei aber leider nicht immer alle Diagrammtypen unterstützt werden.

Im folgenden möchte ich an Hand einiger Beispiele zeigen, wie UML-Diagramme während der Analyse und Design-Phase eingesetzt werden können.

Aufgabenbeschreibung

Die Aufgabenbeschreibung entsteht aus den Vorgaben des Auftragsgebers. In ihr wird in natürlicher Sprache (d.h. nicht formalisiert) festgehalten, welche Zielsetzung das zu entwickelnde Programm hat, in welcher Umgebung es eingesetzt werden soll und welche Ergebnisse erwartet werden. Neben den rein sprachlichen Dokumenten kann ein erstes Modell (Business-Model) Bestandteil der Aufgabenbeschreibung sein. Das Business-Model wird als Entity-Relationship Diagramm (Klassenmodell ohne Klassenmethoden oder logisches Datenmodell) erstellt und kann bei Bedarf um Aktivitätsdiagramme, Sequenzdiagramme oder andere Systemdiagramme ergänzt werden.

Ausschnitt aus einem Business-Model

In diesem Business-Modell sind nur Entitäten aufgeführt. Der Modellierer hat sich an dieser Stelle also noch keine Gedanken über benötigte Attribute etc. gemacht, sondern einfach festgehalten, wie die für das Programm wichtigen Verhältnisse im modellierten Geschäftsbereich aussehen.

In anderem Zusammenhang könnten bei der Analyse des Geschäftsumfeldes durchaus schon detailliertere Modelle entstehen:

Gemeinsames Merkmal aller dieser Modelle ist aber, daß den Klassen noch keine Methoden zugeordnet sind.

Gebrauchsfallanalyse (UseCase Analysis)

In der Gebrauchsfallanalyse wird ermittelt, wie der zukünftige Anwender das System sieht, das heißt, welche Eingaben er durchführt und welche Ergebnisse er erwartet. Die Gebrauchsfallanalyse stützt sich im wesentlichen auf Interviews mit den zukünftigen Anwendern. Ausgehend von der Aufgabenbeschreibung wird detailliert jede Anwendungssituation analysiert und beschrieben. Ergebnis der Analyse sind UseCases als Dokumente und in Diagrammform.

Die Benutzeroberfläche ergibt sich im wesentlichen aus den in der Gebrauchsfallanalyse ermittelten UseCases.

Systemdesign

Hier werden erste Designentscheidungen auf einer hohen Abstraktionsebene getroffen. Um eine vollständige Beschreibung des zu erstellenden Systems zu erhalten, werden die UseCases durch Aktivitätsdiagramme ergänzt.

Designmodell erstellen

Anhand der Aufgabenbeschreibung, der Anforderungsanalyse und des Systemdesigns wird ein weiter gehendes Klassenmodell der gewünschten Anwendung erstellt (Designmodell). Dazu wird das oben erwähnte Business-Modell unter Berücksichtigung des entstandenen Systemdesigns in ein Klassenmodell umgewandelt. Das Designmodell enthält die im Businessmodell aufgeführten Entitäten sowie Klassen, die sich aus der internen Programmorganisation ergeben, und vergibt Zuständigkeiten in Form von Klassenmethoden. Die Klassenmethoden umfassen alle in der Aufgabenanalyse und den UseCases aufgeführten Funktionen. Das Designmodell legt sich aber noch nicht fest, aus welchen Basisklassen die im Programm benötigten Klassen abgeleitet werden sollen, da diese von der Sprache und vom verwendeten Framework etc. abhängen.

Das Designmodell beschreibt ebenfalls Abhängigkeiten und Beziehungen zwischen den gefundenen Klassen. Dazu werden Kollaborations- oder Sequenzdiagramme verwendet. Wenn die Lebensdauer bzw. der Werdegang einzelner Objekte wichtig ist (ähnlich Datenfluß), wird dies in Zustandsdiagrammen (State Diagram) festgehalten. Für jedes zu dokumentierende Objekt wird dabei ein eigenes Zustandsdiagramm angefertigt.

Hier als Beispiel ein Sequenzdiagramm, das die Aufrufsequenz eines spezifischen Programmteils widergibt:

Physisches Datenmodell erstellen

Aus dem Designmodell läßt sich das benötigte physische Datenmodell ableiten. Das Datenmodell wird in einem ER-Modeling Tool (z.B. xCase) dargestellt, mit dem die daraus resultierende Datenbank automatisch aufgebaut und gepflegt werden kann.

Implementations Modell

Der letzte Schritt ist das Implementationsmodell. Hier wird das Designmodell um Klassen erweitert, die für die Implementation in einer bestimmten Sprache benötigt werden. Auch die Entwicklung mit einem bestimmten Framework und die aus dem Framework benutzten Klassen werden erst im Implementationsmodell festgelegt.