A Einführung in die UML

A Einführung in die UML
1375
Einführung in die UML
A
Die Unified Modeling Language, kurz UML, ist eine grafische Notationsform, die bei
der Entwicklung und Planung von Softwaresystemen helfen kann. Sie wird häufig für
die objektorientierte Analyse (OOA) und das objektorientierte Design (OOD) eingesetzt. Im Rahmen dieses Kapitels wird die UML nur so weit vorgestellt, wie dies
zum Nachvollziehen der Beispiele dieses Buchs notwendig ist und den Einstieg für
den Gebrauch im praktischen Softwareentwurf erleichtert. Weiterführende Informationen finden Sie in diversen Büchern – beispielsweise im Standardwerk »Das UMLBenutzerhandbuch« [11] oder im Buch »UML 2.0: Das umfassende Handbuch« [53].
Einen einführenden Überblick gibt Abschnitt A.1. Die Möglichkeiten zur Modellierung der statischen Struktur eines Softwaresystems stellt Abschnitt A.2 vor. Notationen
zur Beschreibung der Dynamik werden in Abschnitt A.3 beschrieben.
A.1
Die UML im Überblick
Die UML entstand schrittweise durch Zusammenführung1 und Überarbeitung der bereits bestehenden Objektmodellierungssprachen (vgl. Tabelle A-1) der drei Experten
Grady Booch, James Rumbaugh und Ivar Jacobson.
Tabelle A-1 Experte und Modellierungstechnik
Experte
Modellierungstechnik
Grady Booch
Object-Oriented Analysis and Design (OOAD)
James Rumbaugh
Object Modelling Technique (OMT)
Ivar Jacobson
Object-Oriented Software Engineering (OOSE)
Die Entwicklung beginnt im Jahr 1994, als Booch und Rumbaugh beschließen, ihre Ansätze zu vereinigen, um einen Notationsstandard zu schaffen. Aus den ersten Ansätzen
entsteht 1995 die Unified Method Version 0.8, basierend auf der OMT mit Erweiterungen durch die OOAD. Jacobson bringt später OOSE ein. Es entsteht die UML, die 1997
1
Daher auch der Name UML, was auf Deutsch so viel wie »vereinheitlichte Modellierungssprache« bedeutet.
1376
A Einführung in die UML
von der OMG (Object Management Group) in Version 1.1 zum Standard für objektorientierte Modellierungssprachen erklärt wird. In den folgenden Jahren erscheinen die
UML 1.3 und 1.4. Diese stellen bis zur Veröffentlichung der Version 2.0 im Jahr 2005
den Standard dar. Aktuell ist Version 2.4 aus dem Jahr 2011. In diesem Buch verwende
ich die UML 2.0, weil die Neuerungen der Folgeversionen 2.x für diese Einführung
nicht relevant sind. Auf Änderungen in der Notation von Version 2.0 gegenüber der
Vorgängerversion 1.4 weise ich bei Bedarf hin.
Diagramme der UML
Ziel bei der Entwicklung der UML war es, eine universelle Beschreibungssprache für
objektorientierte Softwaresysteme und damit eine standardisierte Notation zu schaffen:
Eine Modellierungstechnik, mit der Entwickler ihre Modelle beschreiben und mit anderen Entwicklern austauschen können, ohne eine spezielle Programmiersprache vorauszusetzen. Zur Modellierung von Software wurden vor Einführung der UML verschiedene Notationen eingesetzt. Im Extremfall hat jeder Entwickler seine eigene Notation
erfunden.2 Ein Austausch gemeinsamer Architekturgedanken wird dadurch erschwert
und ist eventuell sogar mit Missverständnissen verbunden. Die UML vereinfacht dies
durch verschiedene vorwiegend grafische Notationen (Diagramme). Es existieren sechs
Strukturdiagramme3 und sieben Verhaltensdiagramme, die im Anschluss nur kurz
vorgestellt werden. Einen Überblick über die Diagramme gibt Abbildung A-1. Die im
Praxiseinsatz und für dieses Buch wichtigsten davon beschreiben die Abschnitte A.2
und A.3 ausführlicher.
Strukturdiagramme Strukturdiagramme beschreiben die statische Sicht auf ein
Softwaresystem und umfassen hauptsächlich Klassen- und Objektdiagramme. Den größeren Zusammenhang, die Aufteilung in Komponenten, Pakete und Subsysteme, stellen
Komponenten- und Paketdiagramme dar und ermöglichen somit eine Art Gliederungssicht. Die Aufteilung auf Rechner und andere Systeme wird mit Verteilungsdiagrammen
modelliert.
Verhaltensdiagramme Verhaltensdiagramme beschreiben dynamische Abläufe innerhalb eines modellierten Systems. Anforderungen aus Sicht eines Benutzers lassen
sich mit Anwendungsfällen festhalten. Die Interaktion von Systemkomponenten oder
ausgewählter Objekte kann mithilfe von Sequenz- und Kommunikationsdiagrammen
beschrieben werden. Stehen nicht die Kommunikationspartner, sondern Aktivitäten
oder Zustände im Fokus, so verwendet man dazu Aktivitäts- und Zustandsdiagramme.
2
In vielen Dokumentationen von Oracle wird leider nicht die UML verwendet. Dies macht es
immer wieder kompliziert, die Beispiele auf einen Blick nachzuvollziehen.
3
Mit Version 2.2 wurde mit dem Profildiagramm noch ein siebtes Strukturdiagramm eingeführt, was wir hier aber nicht weiter betrachten wollen.
A.1 Die UML im Überblick
1377
Abbildung A-1 Alle Diagramme der UML 2.0
Modellierung und Diagramm-Granularität
Der Entwurf eines Softwaresystems und dessen Modellierung beginnen mit der Aufnahme von Benutzeranforderungen und enden mit einer detaillierten Spezifikation der
logischen und zeitlichen Abläufe des Systemverhaltens. In Gesprächen mit Anwendern
lassen sich gewünschte Abläufe und Anforderungen ermitteln und mit Anwendungsfalldiagrammen beschreiben. Um die Modellierung näher zu erläutern, können optional
Kommentare beliebiger Länge in die Diagramme eingefügt werden. Über Zustandsund Aktivitätsdiagramme sowie Sequenzdiagramme können Abläufe in den beschriebenen Anwendungsfällen bei Bedarf konkretisiert werden. Diese Diagramme können
neben einer Modellierung auf einer eher fachlichen Ebene auch zur Darstellung und
Umsetzung in ein technisches Modell genutzt werden.
Zudem kann eine erste, grobe Beschreibung der statischen Struktur in Form von
Komponenten- und Klassendiagrammen entwickelt werden. Letztere bilden meistens
das zentrale Modell und den Ausgangspunkt der objektorientierten Modellierung.
1378
A Einführung in die UML
Achtung: Objektmodellierung und Wiederverwendbarkeit
Ein Modell stellt eine Vereinfachung (Abstraktion) des modellierten Systems dar und
konzentriert sich auf die für den jeweiligen Anwendungsfall benötigten Aspekte.
Es entstehen leicht Missverständnisse und die unerfüllbare Hoffnung bezüglich Objektmodellierung und Wiederverwendbarkeit: Aber die für einen Anwendungszweck
modellierten Klassen sind nicht für alle möglichen Applikationen wieder zu verwenden. Viele Applikationen benötigen komplett andere Sichtweisen und Details der
modellierten Gegenstände.
Im Projektverlauf können die Diagramme iterativ vervollständigt und angepasst werden. Hilfreich ist es, mehrere Versionen der Diagramme abhängig von der gegenwärtigen Projektphase (Konzept, Spezifikation, Implementierung) zu erstellen. Diese Modelle unterscheiden sich dann nicht nur in ihrem Detaillierungsgrad – sie können auch
grundsätzliche Änderungen enthalten. Während der Konzeption kann es beispielsweise
unbedeutend sein, wie eine Relation zwischen zwei Klassen umgesetzt wird, wichtig ist
nur, dass es überhaupt eine Verbindung zwischen den Klassen gibt. In der Implementierungsphase kann es aber von Belang sein, ob diese Relation durch Referenzen oder
eine Abbildungsklasse realisiert wird. Weiterhin ist es manchmal sinnvoll, eine zunächst
als gerichtete Referenz modellierte Relation dann doch bidirektional umzusetzen. Dies
deutet Abbildung A-2 an. Die dort eingesetzten Elemente werden im Detail in Abschnitt
A.2.1 vorgestellt – hier ist zunächst die Idee wichtig, nicht die konkrete Notation.
Abbildung A-2 Beispiel für verschiedene Detaillierungsgrade
Die Diagramme helfen nicht nur bei Analyse und Dokumentation, sondern sie können verschiedenen Tools als Basis für eine Sourcecode-Erzeugung dienen. Einige
Tools können Änderungen am Sourcecode auch wieder zurück ins Modell übernehmen
(Round-Trip Engineering).
A.2 Strukturdiagramme – statische Modelle
1379
Modellierungstools
Um direkt ein wenig mit der UML vertraut zu werden, können Sie folgende Modellierungstools aus dem Internet herunterladen und mit diesen etwas experimentieren.
astah Das Tool astah ermöglicht das Erstellen der wichtigsten UML-Diagramme.
Zusätzlich besitzt es viele kleine hilfreiche Funktionen zum Zeichnen der UMLDiagramme und deren Export. Als Highlight erlaubt es, Verzeichnisbäume zu analysieren und daraus Klassendiagramme zu erzeugen. Auch Round-Trip Engineering wird
unterstützt. Es steht kostenfrei unter http://astah.net/editions/ als Community Edition zur Verfügung. Es ist mein Favorit, um schnell, einfach und bequem UMLDiagramme zu erstellen, die auch noch professionell aussehen.
ArgoUML Ein weiteres frei verfügbares Tool ist ArgoUML. Vorteilhaft ist, dass man
keine Installation vornehmen muss. Es existiert eine Version, die sich als Java Web Start
ausführen lässt und damit auf jedem Rechner mit einer JVM und einem Webbrowser
lauffähig ist. Ein Download ist unter http://argouml.tigris.org/ möglich.
Enterprise Architect Enterprise Architect ist ein kommerzielles Tool, für das unter http://www.sparxsystems.com.au/products/ea/index.html/ eine Probeversion frei verfügbar ist. Der Enterprise Architect bietet viel, erfordert aber auch
eine recht lange Einarbeitungszeit.
A.2
A.2.1
Strukturdiagramme – statische Modelle
Klassendiagramme
Ein Klassendiagramm dient zum Modellieren der statischen Struktur eines Softwaresystems und beschreibt beteiligte Klassen, Schnittstellen und deren Beziehungen.
Elemente von Klassendiagrammen
Klassen Klassen werden als Rechteck dargestellt, das normalerweise in drei Abschnitte aufgeteilt wird. Im oberen Teil stehen der Klassenname und eventuell weitere,
ergänzende Informationen, darunter folgen der Attribut- und der Methodenabschnitt.
Beide sind optional. Abbildung A-3 zeigt den grundsätzlichen Aufbau.
Abbildung A-3 Struktur von Klassendiagrammen
1380
A Einführung in die UML
Im oberen Abschnitt können gewisse Anmerkungen, sogenannte Stereotypen, notiert
werden. Diese spezifizieren etwa, ob es sich um eine Aufzählung (Stereotyp <<enum>>)
oder um eine abstrakte Klasse (Stereotyp <<abstract>>) handelt. Bei Letzterer werden sowohl der Name als auch deren abstrakte Methoden kursiv dargestellt.
Für Attribute und Methoden sind verschiedene Sichtbarkeiten möglich, wobei +
für public, # für protected und - für private steht. Statische Elemente werden
unterstrichen. Für generische Klassen erfolgt in der rechten oberen Ecke die Angabe
ihrer Typparameter umrandet von einem gestrichelten Kästchen.
Tipp: Sichtbarkeiten
n
In einem Klassendiagramm sollten zur besseren Übersicht hauptsächlich
public-Methoden und evtl. einige protected-Methoden dargestellt werden.
Damit sollte die Schnittstelle einer Klasse vollständig beschrieben sein. Ist dies
nicht der Fall, so existieren direkte Zugriffe auf Attribute und es erfolgt keine vollständige Datenkapselung. Das ist zu vermeiden, um unerwartete Seiteneffekte
zu verhindern.
n
Methoden mit der Sichtbarkeit private spielen bei der Analyse und im Grobdesign kaum eine Rolle. Private Methoden sind selbst im Detaildesign und zur
Dokumentation eher selten in Diagrammen sinnvoll. Das liegt daran, dass in frühen Entwurfsphasen solche Details noch nicht interessieren und während der
Erstellung eines Softwaresystems auf dieser niedrigen Implementierungsebene einfach zu viel und in zu schneller Folge Änderungen stattfinden. Zum einen
sind diese Details kaum relevant für die Dokumentation und zum anderen würde es einen ungeheuren Aufwand erzeugen, Dokumentation und Sourcecode
jeweils aktuell und konsistent zueinander zu halten.
Schnittstellen Für Schnittstellen (Interfaces) existieren verschiedene Darstellungsformen. Die Notation erfolgt normalerweise wie bei Klassen als Rechteck, jedoch nur
mit Methodenabschnitt. Alle Methoden sind dort public und abstract. Im Unterschied zu Klassen wird im Kopfbereich das Stereotyp <<interface>> notiert. Als
alternative Darstellungsform für Interfaces existieren die Symbole des »Lolli« (Kreis
mit Linienverbindung zur Klasse) und der »Antenne« (offener Halbkreis mit Linienverbindung zur Klasse). Der »Lolli« wird verwendet, wenn man lediglich darstellen
will, dass eine Klasse das Interface implementiert, ohne auf die konkreten Methoden
einzugehen. Die »Antenne« zeigt an, dass dieses Interface benötigt wird, um gewisse
Aufgaben durchzuführen. Vor allem im Zusammenspiel zwischen verschiedenen Klassen in unterschiedlichen Paketen kann diese Darstellungsweise nützlich sein, da sie die
Details einzelner Methoden verbirgt. Abbildung A-4 zeigt die beschriebenen Varianten
der Interface-Darstellung.
A.2 Strukturdiagramme – statische Modelle
1381
Abbildung A-4 Verschiedene Darstellungen von Interfaces
Beziehungen zwischen Klassen und Interfaces
Klassen und Schnittstellen stehen in verschiedensten Beziehungen zueinander. Klassen
können nicht nur andere Klassen erweitern oder Interfaces realisieren, sondern diese
auch referenzieren, um dort Funktionalität aufzurufen.
Vererbungsbeziehungen Die Implementierung einer Schnittstelle wird über
einen Pfeil mit gestrichelter Linie symbolisiert. Dabei zeigt die Spitze auf das implementierte Interface. Für Ableitungen verwendet man durchgezogene Linien. Hier zeigt
die Pfeilspitze auf die Basisklasse. Abbildung A-5 stellt beide Beziehungen dar.
Abbildung A-5 Interfaces, abstrakte Klassen und Vererbung
Assoziation Die Assoziation ist die allgemeinste Form der Beziehung zwischen
Klassen oder Schnittstellen. Damit wird lediglich ausgedrückt, dass diese Elemente miteinander verbunden sind. Im Speziellen kann eine solche Assoziation auch wieder auf
die ursprüngliche Klasse zurückverweisen, um eine Selbstreferenz auszudrücken.
Eine Assoziation kann mit einem Namen versehen werden und optional auch eine Richtung haben, d. h., die eine Seite »kennt« die andere, aber nicht andersherum.
Des Weiteren können auf beiden Seiten einer Assoziation eine Multiplizität und ein
1382
A Einführung in die UML
Rollenname angegeben werden. Die Multiplizität legt die Anzahl möglicher Instanzen fest und kann beliebige Werte (1, 7) oder Wertebereiche (3-5; 7-9) umfassen.
Im Speziellen steht ein * für beliebig viele Instanzen. Der Rollenname wird eher selten angegeben, da es in der Regel schwierig ist, dem Assoziationsnamen dadurch noch
wertvolle Informationen hinzuzufügen.
Aggregation Die Aggregation ist ein Spezialfall einer Assoziation, allerdings gibt
es in der UML keine exakte Definition von deren Bedeutung. Gewöhnlich versteht man
darunter eine Ganzes-Teile-Beziehung, deren verbundene Elemente unabhängig voneinander sind. Eine Aggregation verwende ich meistens dann, wenn ein Objekt eine
Menge von anderen Objekten referenziert.
Die Darstellung erfolgt mit einem Rautensymbol an der Klasse, die das Ganze repräsentiert. Abbildung A-6 zeigt sowohl eine Assoziation als auch die Aggregation als
eine Spezialisierung davon.
Abbildung A-6 Assoziation und Aggregation
Komposition Die Komposition wiederum ist ein Spezialfall einer Aggregation mit
noch stärkerer Bindung. Das referenzierte bzw. die referenzierten Objekt(e) gehören
zu genau einer Instanz der besitzenden Klasse (sind »dinglich« enthalten). Endet die
Lebenszeit eines Containerobjekts, so müssen für Kompositionen auch die enthaltenen
Objekte terminiert werden. Diese Forderung ist in Java nicht direkt umzusetzen, da es
keine vom Programmierer aktivierbare Objektlöschung gibt. Stattdessen werden Objekte nur dann durch die Garbage Collection gelöscht, wenn diese von keinem anderen
Objekt mehr referenziert werden (vgl. Abschnitt 8.5). Komposition erfordert daher in
Java, dass nur die Containerobjekte Referenzen auf die enthaltenen Objekte besitzen.
Nur dann ist es dem Garbage Collector möglich, den Speicher der enthaltenen Objekte
freizugeben, wenn diese nicht länger von dem Containerobjekt referenziert werden.
A.2 Strukturdiagramme – statische Modelle
1383
Zur Darstellung wird ein gefülltes Rautensymbol verwendet. Abbildung A-7 zeigt
dies anhand einer Klasse Document. Deren Instanzen sich aus Paragraph-Objekten
zusammensetzen.
Abbildung A-7 Komposition
A.2.2 Objektdiagramme
Objektdiagramme ähneln den Klassendiagrammen. Sie zeigen einen speziellen Zustand
eines Klassendiagramms zu einem definierten Zeitpunkt, d. h. die aktuelle Wertebelegung der Attribute von Objekten. Da einerseits die Anzahl der Attribute groß sein kann
und andererseits häufig nur eine gewisse Teilmenge für einen betrachteten Fall interessant ist, erlaubt die Notation, nur eine Auswahl bestimmter Attribute aufzulisten.
Die Darstellung der Objekte erfolgt ähnlich zu den Klassen aus dem Klassendiagramm als Kasten mit der Angabe eines unterstrichenen Instanznamens im Format
Instanzname : Klassenname.4 Der Methodenabschnitt entfällt. Ein einfaches Beispiel zweier Objekte ist in Abbildung A-8 visualisiert.
Abbildung A-8 Objektdiagramm
A.2.3
Komponentendiagramme
Komponentendiagramme dienen zur Modellierung von Komponenten und deren Zusammenspiel. Komponenten bestehen aus Klassen und Interfaces und zeichnen sich
unter anderem dadurch aus, dass mehrere Komponenten zu größeren Komponenten zusammengefügt werden können.
Zwei Komponenten können miteinander arbeiten und verbunden werden, wenn die
angebotenen Schnittstellen einer Komponente zu den benötigten Schnittstellen einer anderen Komponente passen. Zur Beschreibung von Abhängigkeiten werden die bereits
vorgestellten »Lolli«- und »Antennen«-Symbole verwendet. Vor der UML 2 existierte das »Antennen«-Symbol noch nicht und man musste eine Abhängigkeitsbeziehung
4
Der Instanzname ist optional und kann bei nicht benannten (anonymen) Objekten entfallen.
1384
A Einführung in die UML
nutzen, die als gestrichelter Pfeil gezeichnet wird. Im Beispiel aus Abbildung A-9 ist
die Komponente ReportGenerator mit den Komponenten CSVEingang als Datenlieferant und den Komponenten HtmlReporter bzw. MailReporter als Datenausgabe
verbunden, indem die passenden Schnittstellen zusammengeführt sind.
Abbildung A-9 Komponentenbeispiel
Komponentendiagramme können verschiedene Detaillierungsstufen enthalten. Die sogenannte Blackbox-Sicht zeigt lediglich Komponenten und ihre Schnittstellen. Die
Whitebox-Sicht oder Komponenten-Modellierungssicht zeigt auch die innere Struktur,
also Klassen, Interfaces und ggf. weitere enthaltene Komponenten.
A.2.4
Paketdiagramme
Ein Paketdiagramm stellt die Struktur eines modellierten Systems mithilfe von Paketen
und Abhängigkeitsbeziehungen dar und zeigt die Unterteilung der Software in einzelne
Pakete. Paketdiagramme können sehr nützlich sein, um unerwünschte und unerwartete
Abhängigkeiten in einer Analyse eines bestehenden Systems, z. B. vor einem Redesign,
zu visualisieren. Nehmen wir an, ein Paket displaycontrol hätte drei Abhängigkeiten und eine davon wäre eine unerwartete Abhängigkeit von einem Paket services.
Abbildung A-10 stellt ein Paketdiagramm dar, das diese Situation beschreibt.
A.3
Verhaltensdiagramme – dynamische Modelle
Das dynamische Verhalten eines Systems lässt sich in verschiedenen Detaillierungsgraden betrachten. Auf sehr abstrakter Ebene kann es durch Anwendungsfalldiagramme
beschrieben werden. Auf feingranularer Ebene hilft der Einsatz verschiedener anderer
Diagrammtypen, das dynamische Verhalten genauer zu spezifizieren.
A.3.1
Anwendungsfalldiagramme
Ein Anwendungsfalldiagramm beschreibt Anforderungen an ein System aus Sicht eines Benutzers. Es bietet dazu eine relativ simple Darstellung der gewünschten Abläu-
A.3 Verhaltensdiagramme – dynamische Modelle
1385
Abbildung A-10 Abhängigkeiten in Paketdiagrammen
fe in Form von Strichmännchen-Akteuren und oval dargestellten Anwendungsfällen
(sogenannten Use Cases) sowie deren Beziehungen untereinander. Ein Anwendungsfall beschreibt dabei auf grobgranularer Ebene, Anforderungen und Arbeitsabläufe eines zukünftigen Benutzers. Bei Diskussionen mit Kunden oder dem Management über
die Systemfunktionalität kann diese Betrachtungsweise sinnvoll sein. Durch die starke
Abstraktion ist ein Anwendungsfalldiagramm aber eher ein Hilfsmittel zur Anforderungsermittlung und weniger zur Verhaltensbeschreibung und zum Systemdesign.
In Abbildung A-11 wird eine Bestellung in einem Restaurant als Anwendungsfall
modelliert.
Abbildung A-11 Anwendungsfall: Bestellung im Restaurant
1386
A Einführung in die UML
Die Idee habe ich aus dem Buch »UML 2.0 – Das umfassende Handbuch« [53] aufgegriffen und hier ein wenig erweitert, sodass sich verschiedene Abhängigkeitsbeziehungen intuitiv verdeutlichen lassen.
Es können also wie auch beim Klassendiagramm sowohl Akteure als auch Anwendungsfälle in Abhängigkeitsbeziehungen stehen. Auch Vererbung ist möglich: Ein
Akteur oder Anwendungsfall kann eine Spezialisierung eines anderen Akteurs bzw.
Anwendungsfalls sein, hier am Beispiel der verschiedenen Zahlungsweisen gezeigt.
Mit der Notation <<include>> wird ein Anwendungsfall B in einen bestehenden Anwendungsfall A integriert, d. h., während der Anwendungsfall A abläuft, wird
der Anwendungsfall B abgearbeitet und dessen Ergebnis in einem Teilschritt des Anwendungsfalls A verwendet. Die Aktionen im inkludierten Anwendungsfall finden entweder vor oder während des eigentlichen Anwendungsfalls statt. Im Beispiel ist dies
für den Anwendungsfall »Hauptgericht« gegeben. Wir erkennen ein weiteres Modellierungsdetail: Der inkludierte Anwendungsfall »Zubereitung« wird durch einen anderen
Akteur ausgeführt.
Über die Notation <<extend>> wird ein Anwendungsfall A unter bestimmten Bedingungen durch einen anderen Anwendungsfall B erweitert. Der Anwendungsfall A ist
dabei normalerweise in sich vollständig beschrieben. In diesem Beispiel kommt es je
nach Laune des Gasts nach der Abarbeitung des Anwendungsfalls »Hauptgericht« noch
zu der Bestellung eines Nachtischs, beschrieben durch den Anwendungsfall »Dessert«.
Diese optionale Abarbeitung lässt sich mithilfe einer <<extend>>-Beziehung modellieren.
Granularität von Anwendungsfalldiagrammen
Sollen kompliziertere Sachverhalte dargestellt werden, reicht die abstrakte Ebene der
Abbildungen nicht mehr aus: Die in den Anwendungsfalldiagrammen dargestellten Aktionen bestehen tatsächlich aus vielen kleineren Verarbeitungsschritten und komplexen
Interaktionen. Die Abbildungen sollten daher lediglich einen Teil der Modellierung mit
Anwendungsfällen darstellen. Hört die Modellierung allerdings hier auf, so ist deren
Wert relativ gering. Deshalb sollten die Anwendungsfälle mit weiteren detaillierten textuellen Beschreibungen konkretisiert werden. Aus diesen Erläuterungen können mögliche Abfolgen von Verarbeitungsschritten innerhalb eines Anwendungsfalls beschrieben werden. Deren Spezifikation erfolgt durch speziellere Verhaltensdiagramme, die im
Folgenden vorgestellt werden.
A.3 Verhaltensdiagramme – dynamische Modelle
A.3.2
1387
Sequenzdiagramme
Sequenzdiagramme dienen dazu, Abläufe, sogenannte Szenarien, zu beschreiben, in
denen mehrere Objekte per Nachrichtenaustausch kommunizieren. Der Schwerpunkt
liegt auf der konkreten chronologischen Abfolge der Nachrichten zwischen beteiligten
Objekten bzw. Klassen5 . Die Systemkomponente, die die Aktion startet, wird häufig
zur Unterscheidung von den anderen Objekten als gefüllter Kreis oder als Strichmännchen links oben im Diagramm repräsentiert. Hier beginnt die Abarbeitung der Aktionen
durch eine Nachricht an ein rechts daneben befindliches Objekt. Die zeitliche Reihenfolge der Kommunikation und damit die Abfolge der Nachrichten ergibt sich implizit
durch die vertikale Anordnung: Die Zeit schreitet in einem Sequenzdiagramm von oben
nach unten voran.6
Assoziationen zwischen Klassen werden in Sequenzdiagrammen nicht explizit dargestellt. Damit der Nachrichtenaustausch zwischen Kommunikationspartnern erfolgen
kann, müssen sich diese kennen. Im Klassendiagramm muss dazu entweder eine Assoziation zugrunde liegen oder zumindest eine Abhängigkeit (Dependency) existieren.
Eine Abhängigkeit kann beispielsweise durch Übergabe einer Referenz auf die zu verwendende Klasse ausgedrückt werden.
Elemente von Sequenzdiagrammen
Klassen und Objekte Die an einem Ablauf beteiligten Objekte oder Teilkomponenten werden als Rechteck mit Namen visualisiert. Die Lebensdauer eines Objekts
wird im Sequenzdiagramm als senkrechte gestrichelte Linie, die sogenannte Lebenslinie, unterhalb des Objektsymbols dargestellt. Wenn das Objekt während des im Diagramm abgebildeten Zeitabschnitts erzeugt oder zerstört wird, beginnt oder endet diese
Lebenslinie an der entsprechenden Stelle, ansonsten verläuft sie durchgehend von oben
nach unten.
Wenn ein Objekt erzeugt wird, zeigt der Pfeil der erzeugenden Nachricht auf das
Rechtecksymbol des neu erzeugten Objekts. Die Zerstörung eines Objekts wird durch
ein großes X am Ende seiner Lebenslinie kenntlich gemacht. Die auf der Lebenslinie eines Objekts platzierten Rechtecke kennzeichnen Perioden, in denen dieses Objekt aufgrund einer empfangenen Nachricht eine Aktion ausführt und aktiv ist. Es kann für jedes
Objekt mehrere solche Aktivitätsperioden geben. Abbildung A-12 visualisiert dies.
Nachrichten Der Austausch von Nachrichten zwischen Objekten bedeutet im Grunde nur, dass ein Objekt eine Aktion eines anderen Objekts aufruft – im Normalfall sind
5
Klassen können auch Bestandteil von Sequenzdiagrammen sein, wenn es sich um UtilityKlassen mit statischen Methoden handelt.
6
Allerdings ist dies streng genommen bei bedingten Lebenslinien nicht ganz korrekt, da aus
Platzgründen dann Alternativen untereinander dargestellt werden, obwohl sie eigentlich zeitgleich ablaufen.
1388
A Einführung in die UML
Abbildung A-12 Objekt in einem Sequenzdiagramm
dies Methodenaufrufe.7 Eine Nachricht wird als durchgezogener waagerechter Pfeil von
der Lebenslinie des aufrufenden Objekts zu der des empfangenden Objekts gezeichnet,
wobei Objekte auch Nachrichten an sich selbst senden können. Der Pfeil wird häufig
mit dem Namen der Nachricht und optional mit Parametern versehen. Rückgabewerte
können durch eine gestrichelte Linie symbolisch an den Aufrufer zurückgeliefert werden. Beim Nachrichtenaufruf unterscheidet man folgende Formen:
n
synchron – Der Aufrufer wartet so lange, bis der Empfänger die Nachricht verarbeitet hat, und setzt seine Abarbeitung anschließend fort.
n
asynchron – Der Aufrufer stößt die Aktion nur an. Danach läuft die Abarbeitung
parallel. Asynchrone Nachrichten setzen mehrere Threads voraus und können zur
Modellierung von Nebenläufigkeit verwendet werden.
Synchrone Aufrufe werden mit einer gefüllten Pfeilspitze gezeichnet. Asynchrone Aufrufe werden mit einem offenen Pfeil markiert. Abbildung A-13 zeigt beide Varianten.
Abbildung A-13 Nachrichten in Sequenzdiagrammen
7
Bei geringem Detaillierungsgrad in frühen Entwurfsphasen können dies auch nur Nachrichten sein, die exemplarisch den gewünschten Verlauf der Kommunikation andeuten.
A.3 Verhaltensdiagramme – dynamische Modelle
1389
Bedingungen und Schleifen in der UML 1.4 Zum Teil sollen Nachrichten nur
ausgeführt werden, wenn eine gewisse Bedingung erfüllt ist. Darüber kann man ifelse- bzw. switch-case-Strukturen abbilden. In der UML 1.4 wird dies durch mehrere von einem Punkt ausgehende Pfeile dargestellt. Zur Auswahl der Nachricht wird
eine Bedingung in eckigen Klammern angegeben.
Zur Darstellung von Schleifen bzw. der Wiederholung von Nachrichten wird in
der UML 1.4 ein Sternsymbol ’*’ vor dem Namen der Nachricht gezeichnet. Um die
Anzahl der Iterationen festzulegen, kann hinter dem Sternsymbol zusätzlich eine Abbruchbedingung spezifiziert werden. Abbildung A-14 zeigt beide Notationsformen.
Abbildung A-14 Schleifen und Bedingungen in Sequenzdiagrammen in der UML 1.4
Bedingungen und Schleifen in der der UML 2 In der UML 2 werden Bedingungen und Schleifen in separaten Kästchen mit dem Zusatz ’alt’ bzw. ’loop’ dargestellt. Abbildung A-15 zeigt dies.
1390
A Einführung in die UML
Abbildung A-15 Schleifen und Bedingungen in Sequenzdiagrammen in der UML 2
Hinweis: Zeitlicher Verlauf bei Bedingungen und Schleifen
Streng genommen widerspricht die Notation dem Gedanken, dass die Zeit im Sequenzdiagramm von oben nach unten läuft. Die angegebenen Alternativen finden
konkurrierend statt und haben keinen zeitlichen Versatz, wie dies durch die Notation angedeutet wird.
Angabe zeitlicher Randbedingungen Zur Spezifikation zeitlicher Randbedingungen lassen sich gewisse Zeitpunkte angeben und mit Bedingungen versehen, wie
dies Abbildung A-16 zeigt.
Zeitangabe
t1
{t2 - t1 < 10 sec}
Bedingung
t2
Abbildung A-16 Zeitliche Randbedingungen in Sequenzdiagrammen
A.3 Verhaltensdiagramme – dynamische Modelle
A.3.3
1391
Kommunikationsdiagramme
Kommunikationsdiagramme, früher unter dem Namen Kollaborationsdiagramme bekannt, modellieren, wie auch Sequenzdiagramme, Szenarien. Kommunikationsdiagramme betonen allerdings mehr den Nachrichtenfluss und die Aufrufhierarchie bei
der Zusammenarbeit und Interaktion von Objekten. Die zeitliche Reihenfolge der Nachrichten steht weniger im Fokus.
Kommunikationspartner und Nachrichten werden analog zum Sequenzdiagramm
als Rechtecke und Linien mit den Namen der Operationen dargestellt.8 Es hat sich in
der Praxis bewährt, die zentralen Objekte entweder mittig im Diagramm oder links
oben zu positionieren. Die dargestellten Interaktionen gehen dann hauptsächlich aus
der Diagrammmitte zum Rand oder in der bevorzugten Leserichtung von links nach
rechts. Dies zeigt Abbildung A-17.
Abbildung A-17 Beispiel eines Kommunikationsdiagramms
Über Pfeile und eine Nummerierung der Nachrichten wird die Richtung und die zeitliche Abfolge ausgedrückt – der zeitliche Ablauf ist dadurch manchmal jedoch nicht so
klar wie in Sequenzdiagrammen zu erkennen. Ein Rückpfeil als Symbol einer Rückantwort existiert hier ebenso wenig wie eine Unterscheidung zwischen synchronen und
asynchronen Nachrichten. Teilweise ist es hilfreich, die Nachrichten mit einem Hinweis
für die Aufrufart (synchron, asynchron) zu versehen.
A.3.4
Zustandsdiagramme
In der theoretischen Informatik beschreibt man Zustände und Übergänge zwischen diesen mit sogenannten Automaten. Das lässt sich in der UML mithilfe von Zustandsdiagrammen modellieren. Zustände besitzen einen Namen und werden als Rechteck mit
runden Ecken dargestellt. Aus einem momentanen Zustand kann in einen Zielzustand
gewechselt werden (Zustandsübergang bzw. Zustandstransition genannt). Ein solcher
8
Bei entsprechendem Detaillierungsgrad muss wieder jede Verbindung im Kommunikationsdiagramm durch eine Assoziation bzw. eine Dependency im Klassendiagramm abgebildet werden.
1392
A Einführung in die UML
Übergang kann an Bedingungen gebunden sein oder durch Ereignisse ausgelöst werden. Weiterhin kann beim Übergang eine Aktion erfolgen. All dies ist optional und
kann bei der Modellierung bei Bedarf angegeben werden. Abbildung A-18 zeigt die
entsprechende Notation.
Abbildung A-18 Zustand mit Transition
Im Detailentwurf können für jeden Zustand zusätzlich noch spezielle Aktionen spezifiziert werden, und zwar für das Eintreten in diesen Zustand, das Verlassen des Zustands
und Aktionen, die zyklisch während des Zustands ausgeführt werden. Zusätzlich zu den
»normalen« Zuständen gibt es noch zwei explizite künstliche Zustände: den Start- und
den Endzustand. Der durch einen gefüllten Kreis dargestellte Startzustand modelliert
immer einen definierten Ausgangspunkt. Endzustände geben das Ende der Zustandsübergänge und damit des modellierten Verhaltens an. Diese werden als ausgefüllter
Kreis mit Umrandung dargestellt. Abbildung A-19 zeigt dies.
Abbildung A-19 Zustand mit Aktionen
Beispiel
Betrachten wir als komplexeres Beispiel ein verteiltes System, in dem jede Komponente
sich zunächst selbsttätig initialisiert und bei einem »NameService« registriert. Danach
benachrichtigen sich die einzelnen Komponenten gegenseitig über die Bereitschaft zur
Zusammenarbeit mit einer SystemReady-Meldung. Erst dann wechseln sie in den Zustand SystemReadyAndRunning. In diesem Zustand verweilen sie, bis entweder das
Applikationsfenster geschlossen wird oder aber eine Exception auftritt. In letzterem Fall
startet sich das System automatisch wieder neu und der Ablauf im Zustandsdiagramm
beginnt wieder mit dem Zustand Initial. Den Ablauf verdeutlicht Abbildung A-20.
A.3 Verhaltensdiagramme – dynamische Modelle
1393
Abbildung A-20 Zustandsdiagramm eines verteilten Systems
A.3.5
Aktivitätsdiagramme
Aktivitätsdiagramme dienen der Darstellung von Abläufen auf der Basis von Aktivitäten und sind den Zustandsdiagrammen ähnlich. Aktivitätsdiagramme modellieren allerdings eher die Dynamik in Form von Aktionen – wohingegen in Zustandsdiagrammen
mehr die Ergebnisse der Aktionen, d. h. die erreichten Zustände, modelliert werden.
Aktivitäten besitzen einen Namen und werden als Rechteck mit runden Ecken dargestellt (Abbildung A-21). Nach Abschluss einer Aktivität kann eine neue Aktivität
ausgeführt werden. Dieser Übergang (Transition) kann an gewisse Bedingungen gebunden sein. Mehrere Aktivitäten können später wieder in einer Aktivität zusammengeführt
werden.
Abbildung A-21 Aktivitäten und Transitionen
1394
A Einführung in die UML
Zur Modellierung von Nebenläufigkeit dienen Synchronisierungspunkte. Dadurch lässt
sich das synchronisierte Aufsplitten und Zusammenführen von Aktionen darstellen. An
einer Verzweigung können die Nachfolgeaktivitäten unabhängig voneinander starten.
An einer Zusammenführung wird die Nachfolgeaktivität erst dann begonnen, wenn alle
Vorgängeraktivitäten abgeschlossen sind. Die Notation zeigt Abbildung A-22.
Abbildung A-22 Aktivitäten und Synchronisation
Mit Aktivitätsdiagrammen lassen sich, im Gegensatz zu Zustandsdiagrammen, sehr gut
mehrere beteiligte Systeme modellieren. Als Hilfsmittel zur Unterteilung dienen sogenannte »Swimlanes«. Diese partitionieren die Aktivitäten verschiedener beteiligter
Partner, um z. B. bestimmte Schritte eines Ablaufs unterschiedlichen Akteuren zuzuordnen.
Beispiel
Als Beispiel modellieren wir eine Kaffeebestellung in einem Café. Die Idee dazu habe
ich aus dem Buch »Objektorientierte Softwareentwicklung mit UML« von Peter Forbrig [25] aufgegriffen und hier leicht abgewandelt.
In diesem Beispiel sind die involvierten Rollenspieler ein Gast, ein Kellner und die
Küche. Deren Aktivitäten werden in eigenen Swimlanes modelliert. Neben der Bestellung des Kaffees beim Kellner und der anschließenden Zubereitung durch die Küche,
möchte der Gast während der Wartezeit gern Zeitung lesen. Abbildung A-23 visualisiert
eine Umsetzung in Form eines Aktivitätsdiagramms.
A.4 Weiterführende Literatur
1395
Abbildung A-23 Aktivitätsdiagramm Kaffeebestellung
A.4
Weiterführende Literatur
Dieser Anhang hat einen einführenden Überblick in die UML gegeben. Detaillierte
Informationen finden Sie unter anderem in folgenden Büchern:
n
»Das UML-Benutzerhandbuch« von Grady Booch, Jim Rumbaugh und Ivar Jacobson [11]
n
»UML 2.0: Das umfassende Handbuch« von Christoph Kecher [53]
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement