AP1

Unified Modeling Language (UML)

3 Min. Lesezeit

Die UML (Unified Modeling Language) ist eine standardisierte grafische Sprache, um Software zu planen und zu dokumentieren. Herausgeber ist die OMG (Object Management Group). Die Diagramme teilen sich in zwei Gruppen:

  • Strukturdiagramme zeigen den Aufbau eines Systems, z. B. Klassen-, Objekt- und Komponentendiagramm.
  • Verhaltensdiagramme zeigen Abläufe, z. B. Anwendungsfall-, Aktivitäts-, Sequenz- und Zustandsdiagramm.

Klassendiagramm

Das Klassendiagramm zeigt die statische Struktur: Klassen mit ihren Attributen und Methoden und die Beziehungen zwischen den Klassen. Eine Klasse ist ein Kasten mit drei Bereichen: oben der Name, in der Mitte die Attribute, unten die Methoden.

UML-Klassendiagramm: Kunde erbt von Person (leeres Dreieck an Person). Kunde gibt 0 bis beliebig viele Bestellungen auf, jede Bestellung gehört zu genau einem Kunden. Eine Bestellung besteht aus mindestens einer Position (gefüllte Raute an Bestellung). Jede Klasse zeigt Attribute wie „- name: String“ und Methoden wie „+ getName(): String“UML-Klassendiagramm: Kunde erbt von Person (leeres Dreieck an Person). Kunde gibt 0 bis beliebig viele Bestellungen auf, jede Bestellung gehört zu genau einem Kunden. Eine Bestellung besteht aus mindestens einer Position (gefüllte Raute an Bestellung). Jede Klasse zeigt Attribute wie „- name: String“ und Methoden wie „+ getName(): String“

Schreibweise: - name: String ist ein privates Attribut name vom Typ String. + getName(): String ist eine öffentliche Methode, die einen String zurückgibt.

ZeichenSichtbarkeitZugriff
+publicvon überall
-privatenur innerhalb der Klasse
#protectedKlasse und ihre Unterklassen
~packageKlassen im selben Paket

Statische Attribute und Methoden sind unterstrichen. Abstrakte Klassen stehen kursiv oder mit dem Zusatz {abstract}.

Beziehungen

Die vier Beziehungsarten im Vergleich: Assoziation als einfache Linie zwischen Kunde und Bestellung, Aggregation mit leerer Raute an Team (Mitarbeiter existieren auch allein), Komposition mit gefüllter Raute an Haus (Räume gehen mit dem Haus unter), Vererbung mit leerem Dreieck an Person (Kunde ist eine Person)Die vier Beziehungsarten im Vergleich: Assoziation als einfache Linie zwischen Kunde und Bestellung, Aggregation mit leerer Raute an Team (Mitarbeiter existieren auch allein), Komposition mit gefüllter Raute an Haus (Räume gehen mit dem Haus unter), Vererbung mit leerem Dreieck an Person (Kunde ist eine Person)

BeziehungDarstellungBedeutungBeispiel
AssoziationLinieKlassen kennen sich oder arbeiten zusammenKunde und Bestellung
Aggregationleere Raute am GanzenTeil-Ganzes, die Teile existieren auch alleinTeam und Mitarbeiter
Kompositiongefüllte Raute am GanzenTeil-Ganzes, die Teile existieren nur mit dem GanzenHaus und Raum
Vererbung (Generalisierung)leeres Dreieck an der Oberklasse„ist ein“, die Unterklasse übernimmt Attribute und MethodenKunde ist eine Person
Realisierunggestrichelte Linie, leeres Dreieck am InterfaceKlasse implementiert ein InterfaceRechnung implementiert Druckbar

Multiplizitäten

Die Multiplizität an einem Linienende gibt an, wie viele Objekte dieser Klasse zu einem Objekt der Gegenseite gehören.

AngabeBedeutung
1genau eins
0..1keins oder eins
* bzw. 0..*beliebig viele, auch keins
1..*mindestens eins
2..4zwei bis vier

Beispiel aus dem Klassendiagramm: Ein Kunde gibt 0..* Bestellungen auf, jede Bestellung gehört zu genau 1 Kunden.

Anwendungsfalldiagramm

Das Anwendungsfalldiagramm (Use-Case-Diagramm) zeigt, welche Funktionen ein System aus Sicht seiner Nutzer bietet. Es beschreibt, was das System leistet, nicht wie.

Anwendungsfalldiagramm eines Onlineshops: Der Akteur Kunde ist mit den Anwendungsfällen Artikel suchen und Bestellung aufgeben verbunden. Bestellung aufgeben bindet Bezahlen per «include» ein, Bezahlen ist mit dem Akteur Zahlungsdienst verbunden. Gutschein einlösen erweitert Bestellung aufgeben per «extend». Alle Anwendungsfälle liegen im Rahmen OnlineshopAnwendungsfalldiagramm eines Onlineshops: Der Akteur Kunde ist mit den Anwendungsfällen Artikel suchen und Bestellung aufgeben verbunden. Bestellung aufgeben bindet Bezahlen per «include» ein, Bezahlen ist mit dem Akteur Zahlungsdienst verbunden. Gutschein einlösen erweitert Bestellung aufgeben per «extend». Alle Anwendungsfälle liegen im Rahmen Onlineshop

  • Akteur: Strichmännchen außerhalb des Systems. Eine Rolle, die eine Person oder ein anderes System einnimmt.
  • Anwendungsfall: Ellipse, eine Funktion mit Nutzen für einen Akteur.
  • Systemgrenze: Rahmen mit dem Namen des Systems.
  • «include»: Ein Anwendungsfall bindet einen anderen immer ein. Der gestrichelte Pfeil zeigt auf den eingebundenen Fall.
  • «extend»: Ein Anwendungsfall erweitert einen anderen optional, nur unter einer Bedingung. Der gestrichelte Pfeil zeigt auf den erweiterten Fall.

Aktivitätsdiagramm

Das Aktivitätsdiagramm zeigt einen Ablauf Schritt für Schritt, ähnlich einem Programmablaufplan.

Aktivitätsdiagramm: Vom Startknoten geht es zur Aktion Bestellung prüfen, dann zu einer Entscheidung. Bei [verfügbar] folgt Ware versenden, bei [nicht verfügbar] Kunde informieren. Beide Zweige laufen in einer Zusammenführung zusammen und enden im EndknotenAktivitätsdiagramm: Vom Startknoten geht es zur Aktion Bestellung prüfen, dann zu einer Entscheidung. Bei [verfügbar] folgt Ware versenden, bei [nicht verfügbar] Kunde informieren. Beide Zweige laufen in einer Zusammenführung zusammen und enden im Endknoten

  • Startknoten: gefüllter Kreis. Endknoten: Kreis mit Punkt.
  • Aktion: Rechteck mit abgerundeten Ecken.
  • Entscheidung: Raute. Die Bedingungen (Guards) stehen in eckigen Klammern an den ausgehenden Pfeilen.
  • Zusammenführung: Raute, an der die Zweige wieder zusammenlaufen.
  • Gabelung und Vereinigung: dicker Balken. Ab der Gabelung laufen Aktionen parallel, an der Vereinigung wird auf alle gewartet.
  • Swimlanes: Spalten, die zeigen, wer eine Aktion ausführt.

Sequenzdiagramm

Das Sequenzdiagramm zeigt, welche Nachrichten Objekte in welcher Reihenfolge austauschen. Die Zeit läuft von oben nach unten.

Sequenzdiagramm mit den Lebenslinien Kunde, Webshop und Lager: 1. Kunde ruft bestellen(artikel) beim Webshop auf, 2. Webshop ruft pruefeBestand(artikel) beim Lager auf, 3. Lager antwortet verfügbar, 4. Webshop antwortet dem Kunden mit einer Bestätigung. Aufrufe sind durchgezogene Pfeile mit gefüllter Spitze, Antworten gestrichelte PfeileSequenzdiagramm mit den Lebenslinien Kunde, Webshop und Lager: 1. Kunde ruft bestellen(artikel) beim Webshop auf, 2. Webshop ruft pruefeBestand(artikel) beim Lager auf, 3. Lager antwortet verfügbar, 4. Webshop antwortet dem Kunden mit einer Bestätigung. Aufrufe sind durchgezogene Pfeile mit gefüllter Spitze, Antworten gestrichelte Pfeile

  • Lebenslinie: Kasten mit dem Objektnamen, darunter eine gestrichelte Linie.
  • Aktivierungsbalken: schmaler Balken, solange das Objekt arbeitet.
  • Synchrone Nachricht: durchgezogener Pfeil mit gefüllter Spitze. Der Sender wartet auf die Antwort.
  • Asynchrone Nachricht: durchgezogener Pfeil mit offener Spitze. Der Sender arbeitet weiter.
  • Antwort: gestrichelter Pfeil mit offener Spitze.

Weitere Diagramme

  • Zustandsdiagramm: Zustände eines Objekts und die Übergänge dazwischen, z. B. eine Bestellung: offen, bezahlt, versendet.
  • Objektdiagramm: konkrete Objekte mit Werten zu einem Zeitpunkt, eine Momentaufnahme des Klassendiagramms.
  • Komponentendiagramm: Aufbau eines Systems aus Komponenten und ihren Schnittstellen.