UML (Unified Modelling Language)

Grundlagen

UseCase-Diagramm







UseCases können zueinander in Beziehung stehen. Die Beziehungen werden durch gestrichelte Linien dargestellt und sind richtungsgebunden.
Unterschieden wird zwischen Include- und Extend-Beziehung:




Klassendiagramm




Klasse
Der Klassenname beginnt immer mit einem Grossbuchstaben. Vor dem KlassenNamen kann durch zwei Doppelpunkte getrennt der zugehörige PaketNamen angegeben werden. (PaketName::KlassenName)
Der Name von Attributen und Methoden beginnt immer mit einem Kleinbuchstaben. Die UML-Notationen + # und - (siehe Kapselung) werden vor die jeweiligen Attribute und Methoden notiert. Die drei Punkte unter den jeweiligen Attributen (Ellipse) und Methoden geben an, dass die Liste nicht vollständig ist.



Objekt
Der Name des Objekts beginnt immer mit einem Kleinbuchstaben und wird immer unterstrichen dargestellt. Dem Namen des Objekts folgt, durch Doppelpunkt getrennt der Name der zugehoerigen Klasse. (objektName:KlassenName)
Die UML-Notationen + # und - (siehe Kapselung) werden vor die jeweiligen Attribute und Methoden notiert.



Vererbung
Klassen vererben ihre Eigenschaften und Methoden. In der erbenden Klasse werden diese nicht mehr aufgeführt. Die erbende Klasse kann weitere Attribute und Methoden zufügen.
  • Die vererbende OberKlasse steht oberhalb.
  • Hat eine Klasse keine OberKlasse, wird sie als RootKlasse (Wurzelklasse) bezeichnet.
  • Hat eine Klasse keine weiteren UnterKlassen, wird sie als LeafKlasse (BlattKlasse) bezeichnet.
  • Klassen, die keine Objekte haben, nennt man abstrakt. In diesem Fall wird der KlassenNamen kursiv dargestellt.


Aggregation

Form der Assoziation. (IS-A-Part Beziehung)
Klasse B ist in Klasse A enthalten.
Klasse B kann auch Teil anderer Klassen sein.
nicht ausgefüllte Raute zeigt zur MasterKlasse




Komposition

Form der Assoziation. (IS-A-Part Beziehung)
Klasse B ist in Klasse A physikalisch enthalten.
Klasse B kann nicht Teil einer anderen Klasse sein.
ausgefüllte Raute zeigt zur MasterKlasse


Assoziationen

Allgemeine Beziehung zwischen zwei selbstständigen Klassen. Wenn möglich auf gleicher Ebene dargestellt. Assoziationen können eine Richtung besitzen. Der Zugriff auf die Objekteigenschaften ist dann nur in dieser Richtung möglich. Eine Assoziation mit Navigationsrichtung wird beim Programmieren als Zeiger betrachtet. Assoziationen entsprechen den Relationen im ERM.




Eine Assoziation kann einen Namen haben. Der Pfeil vor oder hinter dem Namen beschreibt die Leserichtung der Beziehung.




Zwischen zwei Klassen koennen mehr als eine Assoziation bestehen.




Für Assoziationen können Kardinalitäten definiert werden. Die Kardinalitäten werden am jeweiligen Ende der Assoziation notiert und unter UML als Multiplizität bezeichnet.
- Zahl
- Bereich (z.B.: 0..1 oder 1..5)
- * für kein oder beliebig viele Objekte.




Die Rolle der jeweiligen Klasse in einer Assoziation kann am Ende der Assoziationslinie angegeben werden.




Assoziationen können Eigenschaften und Attribute haben. Diese werden in einer Assoziationsklasse festgehalten und mit einer gestrichelten Linie von unten an die Assoziationslinie angetragen. Assoziationsklassen koennen mit anderen Klassen assoziiert sein.




Assoziationen koennen reflexiv sein. Dies meint, dasz die Assoziation sich auf die Klasse bezieht, von der sie ausgeht. So fährt zum Beispiel ein Fahrzeuginsasse in seiner Rolle als Fahrer kein oder mehrere Fahrzeuginsassen in ihrer Rolle als Beifahrer.




Eine Assoziation kann eine Einschränkung aufweisen. Diese wird in geschweifte Klammern an die Assoziation angetragen.




Eine Klasse kann durch eine Oder-Verbindung mit zwei anderen Klassen assoziiert sein.
Die zwei betreffende Assoziationslinien werden durch eine gestrichelte Linie verbunden, in deren Mitte in geschweiften Klammern die Einschränkung steht.




Kapselung

Bei der Kapselung von Eigenschaften und Methoden gibt es drei Möglichkeiten:



Sequenzdiagramm

Das Sequenzdiagramm stellt dar, wie Objekte untereinander Nachrichten austauschen. Dies wird in einem zeitlichen Schema festgehalten.
Am oberen Ende werden die instanzierten Objekte in einem Rechteck benannt. Von dem Objekt geht nach unten eine Lebenslinie ab, die gestrichelt dargestellt wird. Der chronologische Ablauf ist also von oben nach unten. Aktivitäten eines Objekts werden als Rechteck auf der Lebenslinie angetragen. Nachrichten zwischen aktiven Objekten werden als waagerechte Pfeile dargestellt.





Nachrichten haben:
  • einen Namen Name
  • können Parameter übergeben Name (Parameter)
  • können bedingt [] ausgeführt werden. [Bedingung] Name
  • Ein Stern * vor dem Namen der Nachricht gibt an, daß eine Iteration gestartet werden soll.
  • Zu jeder Nachricht gehört auch eine Antwort im Format antwort:=nachricht ()



Drei Arten von Nachrichten werden unterschieden:
  • Einfach
    Das sendende Objekt gibt die AblaufKontrolle an das empfangende Objekt ab.
  • Synchron
    Das sendende Objekt wartet auf eine Antwort, bevor es im Ablauf fortfährt.
  • Asynchron
    Das sendende Objekt wartet nicht auf eine Antwort, bevor es im Ablauf fortfährt.


Erläuternder Text zu den Nachrichten wird am linken Rand des Diagramms auf Höhe der betreffenden Nachricht angetragen.




Mit links gezeigter Darstellung werden neue Objekte instanziert.



Mittels eines Destruktors (x) am Ende der Lebenslinie wird das Lebensende eines Objekts angezeigt.



Nebenstehendes Diagramm zeigt die Darstellung bedingter Nachrichten an zwei unterschiedliche Objekte.

Die jeweilige Bedingung wird in eckigen Klammern der Nachricht vorangestellt.




Zustandsdiagramm

Dieses Diagramm zeigt die Zustände auf, in denen sich ein Objekt befinden kann. Das Symbol für einen Zustand ist ein Rechteck mit abgerundeten Ecken. Die Übergänge von einem Zustand zu einem anderen Zustand werden mit Pfeilen dargestellt und als Transitionen bezeichnet. Mit den Transitionen kann ein Ereignis angegeben werden (oberhalb der Linie), das für eine Zustandsänderung verantwortlich ist. Diese Art von Zustandsübergang wird als triggerd transition bezeichnet. Findet dagegen eine Zustandsänderung statt, weil alle Aktivitäten eines Zustands abgearbeitet sind, wird diese als triggerless transition bezeichnet.

Transitionen können an Bedingungen (guard condition) gebunden sein. Diese Bedingung (z.B. ein Timer) wird in eckigen Klammern an der Transition notiert.

Der Startpunkt einer Reihe von Zuständen wird mit einem ausgefülltem Kreis dargestellt. Das Ende einer Zustandssequenz wird mit einem ausgefüllten Kreis mit umgebenem Kreis dargestellt.




Einfachstes Zustandsdiagramm mit Kennzeichnung von Anfang und Ende.
Zustandssymbol mit Angaben zu:
  • Zustandsname
  • Zustandsvariable (optional)
  • Aktivitäten (optional)


Folgendes Beispiel zeigt die unterschiedlichen Zustände des Objekts Anrufbeantworter.



Die den Aktivitäten vorangestellten Schlüsselwörter entry, exit und do geben an:

Zustände können detailiert werden, indem sie in Teilzustände gegliedert werden. Hierbei sind zwei Arten zu unterscheiden:
- sequentielle Teilzustände
- nebenläufige (parallele) Teilzustände

Nebenstehendes Beispiel zeigt den Zustand Fahren des Objekts Auto zerlegt in die sequentiellen Teilzustände Gas geben und Bremsen.


Nebenstehendes Bild des Zustands Fahren wurde um den Teilzustand Lenken erweitert. Dieser Teilzustand ist nebenläufig zu den Teilzuständen Gas geben und Bremsen und wird durch eine gestrichelte Linie von diesen abgetrennt.




Aktivitätsdiagramm

Diese Diagrammart wird eingesetzt, um die einzelnen Aktivitäten in einem Prozess chronologisch darzustellen. Die Übergänge (Transitionen) von einer Aktivität zur Nächsten werden durch Pfeile dargestellt.




Einfachstes Aktivitätsdiagramm mit Kennzeichnung von Anfang und Ende.
Aktivitäten werden in einem Rechteck mit abgerundeten Ecken dargestellt.


Um nebenläufige (parallele) Aktivitäten einzuleiten, müssen die Transitionslinien geteilt werden. Hierzu wird das nebenstehend gezeigte Symbol eingesetzt. Die dicke Linie rechtwinklig zu den Transitionen stellt die Synchronisationslinie dar.



Um nebenläufige Aktivitäten zusammenzuführen wird das nebenstehend gezeigte Symbol eingesetzt. Sind alle nebenläufigen Aktivitäten abgearbeitet (logisch und), wird zur nächsten Aktivität übergegangen.
Um bedingte Verzweigungen darzustellen, bietet das Aktivitätsdiagramm zwei Darstellungsmöglichkeiten:



Die Verzweigung geht von einer Raute aus. Diese Art der Darstellung ist an die Symbolik eines Programmablaufplans angeglichen.


Die Verzweigung geht direkt vom Aktivitätssymbol aus.


Bei beiden Darstellungen wird die jeweilige Bedingung, die erfüllt sein muss, direkt an die Transition in eckige Klammern angetragen.



Um die Transitionen wieder zusammenzuführen wird ebenfalls das Raute-Symbol verwendet.

Sollen die einzelnen Aktivitäten einer Klasse zugeordnet werden, können Swimlanes eingesetzt werden, um die einzelnen Bereiche voneinander zu trennen.



Packagediagramm

Das Packagediagramm wird zur Gliederung von Klassendiagrammen (auch UseCaseDiagrammen) verwendet. Mehrere Klassen werden in einem Package (Ordnersymbol) zu einer Gruppe zusammengefasst, um somit einen Überblick über das Gesamtsystem zu erlangen. Der Name eines Objektes in der einen Klasse kann identisch mit dem Namen eines Objekts in einer anderen Klasse sein.




In oben gezeigten Beispiel steht das Package Verwaltung in Abhängigkeit zu den Packages Urlaub und Gehalt. Diese Abhängigkeit wird durch einen gestrichelten Pfeil dargestellt. Wird ein Objekt in einem Package geaendert, auf das ein Pfeil zeigt, so muss das Package von dem der Pfeil ausgeht aktualisiert werden.

Ein Package kann weitere Packages enthalten.




nützliche Links

UML Referenz TogetherSoft