1 DigInf 05/06 Diagrammtypen der UML 2.0 StrukturdiagrammeVerhaltensdiagramme Interaktionsdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm

1DigInf 05/06

Diagrammtypen der UML 2.0

Strukturdiagramme Verhaltensdiagramme

Interaktionsdiagramme

Klassendiagramm

Komponentendiagramm

Kompositionsstrukturdiagramm

Objektdiagramm

Zustandsautomat

Paketdiagramm

Aktivitätsdiagramm

Use-Case-Diagramm

Sequenzdiagramm

Kommunikationsdiagramm

Verteilungsdiagramm

UML-Diagramme

Unterschiede zwischen UML 1.x und UML 2.0:

hoch mittel

gering

Timingdiagramm

Interaktionsübersichtsdiagramm

2DigInf 05/06

Komponentendiagramm

Problem:• Mehrere Klassen zusammen sollen als Komponente ein gemeinsames

Verhalten in Form von öffentlich zugänglichen Schnittstellen bereitstellen.

Diese zentrale Frage beantwortet das Diagramm:• Wie werden meine Klassen zu wiederverwendbaren, verwaltbaren

Komponenten zusammengefasst und wie stehen diese miteinander in Beziehung?

Diese Stärken hat das Diagramm:a. zeigt Organisation und Abhängigkeiten einzelner technischer

Systemkomponentenb. Modellierung angebotener und benötigter Schnittstellen möglich

Quelle: Jeckle et al.: UML 2 - glasklar

3DigInf 05/06

Komponentenbegriff

Eine Komponente...• ist ein modularer Systemteil, der seinen Inhalt kapselt und vor dem

Nutzer verbirgt.• besteht aus anderen Elementen (Klassen, andere Komponenten).• bietet über extern nutzbare Schnittstellen klar definierte

Funktionalitäten an.• ist durch andere Komponenten, die die gleichen Schnittstellen

anbieten, ersetzbar.• wird durch Kombination mit anderen Komponenten zu einer

größeren Einheit zusammengefügt.• ist häufig eine eigenständige Anwendung.

4DigInf 05/06

Notationselemente I

• Komponenten werden durch den Stereotyp <<component>> angegeben

• es können zusätzlich die verwendeten Schnittstellen angegeben werden (black-box-Darstellung)

• <<provided interfaces>>• <<required interfaces>>

• es kann zusätzlich die interne Realisierung angegeben werden (white-box-Darstellung)

• <<realization>> (Klassen)• <<artifacts>>

<<component>>

Teilnehmerverwaltung

<<component>>


<<provided interfaces>> Sortierter Zugriff Wahlfreier Zugriff<<required interfaces>> Speichermedium

<<component>>


<<provided interfaces>> Sortierter Zugriff Wahlfreier Zugriff<<required interfaces>> Speichermedium

<<realization>> Teilnehmer Verwaltungsmetadaten

<<artifacts>> teilnehmer.jar

5DigInf 05/06

Notationselemente II

• Artefakte sind physische Informationseinheiten• Modelle, Quellcode, Scripte, Binärdateien,

Tabelle einer DB, Textdokumente, eMails etc.

• Artefakte sind in diesem Diagramm konkrete Ausprägungen (Instanzen) einer Komponente

• Stereotype zur näheren Beschreibung• file, document, executable, source, library• weitere Stereotypdefinitionen gibt es in

UML-Profilen (Enterprise Java Beans Profile EJB, Microsoft Component Profile COM)

• Artefakte können geschachtelt werden

<<artifact>>

Application.jar

<<artifact>>Application.jar

<<artifact>>

ejb1.xml

<<artifact>>

ejb2.xml

<<deployment spec>>

app.xml

6DigInf 05/06

Notationselemente III

• Schnittstellen werden mit einem Klassensymbol dargestellt

• sie beschreiben eine Menge von Operationen, Merkmalen und „Verpflichtungen“

• Komponente1 implementiert die Schnittstelle• Pfeildarstellung• Ball-Darstellung

• Komponente2 benötigt die Schnittstelle• Pfeildarstellung• Socket-Darstellung

• Ball-Socket-Darstellung

<<component>>Komponente1





<<interface>>Schnittstellenname



<<use>>

attribut

operation()


Schnittstellenname

Schnittstellenname

7DigInf 05/06

Notationselemente IV

• zwischen Modellelementen können allgemeine Abhängigkeitsbeziehungen existieren (gestrichelter Pfeil, Quelle benötigt Ziel)

• zwischen Komponenten entspricht das der Verschachtelung (komplexe Komponenten)

• <<manifest>> wenn ein oder mehrere Artefakte durch eine Komponente realisiert werden

• <<substitute>> wenn eine Komponente eine andere ersetzen kann

• Schnittstellen sollten normalerweise den gleichen Namen tragen, um anzuzeigen, dass diese kompatibel zueinander sind

• wenn die Kompatibilität auch bei unterschiedlicher Benennung gegeben ist, kann das durch eine allgemeine Abhängigkeitsbeziehung ausgedrückt werden (Operationen einer Klasse heißen anders, erfüllen aber den gleichen Zweck)


<<artifact>>Application.jar

<<manifest>>



Schnittstellenname1Schnittstellenname2

Sortieren



<<substitute>>

Drucken Drucken

8DigInf 05/06

Anwendungsbeispiel

• die ausführbare Datei util.jar realisiert die Komponente Listengenerator und hängt vom Artefakt list.class ab, das wiederum von der Quellcodedatei list.java abhängt

• die Komponente Listengenerator hat die Schnittstelle Feldinhalt implementiert, benötigt die Schnittstelle Speichermedium und beinhaltet die Komponente Zeilengenerator

• die Komponente Zeilengenerator benötigt die Schnittstelle Zeilennummer (die Komponente Addierer implementiert die dazu kompatible Schnittstelle Zahlenfolge)

<<executable>>util.jar

<<component>>Listengenerator

<<manifest>> <<interface>>Speichermedium

<<use>>

<<component>>Zeilengenerator

<<component>>Addierer

Zahlenfolge

Zeilennummer

<<artifact>>list.class

<<source>>list.java

<<component>>Feldgenerator

Feldinhalt

9DigInf 05/06

Komponentendiagramm

Änderungen gegenüber früheren UML-Versionen• Manifestierung (früher Implementierung)• neues Komponentensymbol• neue Stereotypen (einige alte entfallen)

Besondere Hinweise• Es sollten Profile verwendet werden, um die Semantik der

Komponenten und Artefakte besser widerzuspiegeln (z.B. .NET und J2EE).

• Alle relevanten Dokumente des Entwicklungsprozesses sollten durch Artefakte dargestellt werden.

• Abhängigkeitsbeziehungen sollten möglichst vollständig dargestellt werden. Dazu sollten gegebenenfalls eigene Stereotype definiert werden.

10DigInf 05/06




Klassendiagramm

Komponentendiagramm


Objektdiagramm

Zustandsautomat

Paketdiagramm

Aktivitätsdiagramm

Use-Case-Diagramm

Sequenzdiagramm


Verteilungsdiagramm

UML-Diagramme


hoch mittel

gering

Timingdiagramm


11DigInf 05/06


Diese zentrale Frage beantwortet das Diagramm:• Wie sieht das Innenleben einer Klasse, einer Komponente, eines

Systemteils aus?

Diese Stärken hat das Diagramm:a. ideal für die Top-down-Modellierung des Systemsb. präzise Modellierung der Teile-Beziehungen über spezielle

Schnittstellen (Ports) möglich


12DigInf 05/06

Notationselemente I

• Ein Part repräsentiert eine Menge von Ausprägungen, die zu einer Ausprägung des sie umgebenden Classifiers (z.B. Klasse) gehören.

• Ein Kollaborationstyp (Ellipse mit Linie) wird verwendet, um eine Sicht auf kooperierende Modellelemente herauszubilden.

• Eine Kollaboration (Ellipse) wird verwendet, um die Zusammenarbeit der Elemente innerhalb eines Classifiers darzustellen.

Klasse

partName

Abstammung

Vorfahre Nachkomme

kollaboration1 : Kollaborationstyp1

13DigInf 05/06

Anwendungsbeispiel

• Es ist die Verwandtschaftsbeziehung eines Enkels zu seiner Großmutter dargestellt (Kollaboration Verwandtschaft).

• Der Kollaborationstyp Abstammung wird verwendet, um die Vaterschaftsbeziehung zwischen Vater und Sohn und die Mutterschaftsbeziehung zwischen Großmutter und Vater zu beschreiben.

Verwandtschaft

Vater

Großmutter

Mutterschaft : Abstammung

Vaterschaft : Abstammung Sohn

Nachkomme

Vorfahr

Vorfahr

Nachkomme

14DigInf 05/06


Änderungen gegenüber früheren UML-Versionen• Das Kompositionsstrukturdiagramm wurde neu eingeführt.

Besondere Hinweise• Das Diagram sollte verwendet werden, um bestimmte Aspekte der

Architektur des Systems zu veranschaulichen, z.B. beim Einsatz von Entwurfsmustern.

15DigInf 05/06




Klassendiagramm

Komponentendiagramm


Objektdiagramm

Zustandsautomat

Paketdiagramm

Aktivitätsdiagramm

Use-Case-Diagramm

Sequenzdiagramm


Verteilungsdiagramm

UML-Diagramme


hoch mittel

gering

Timingdiagramm


16DigInf 05/06

Objektdiagramm

Problem:• Bestimmte komplexe Systemkonfigurationen sollen modelliert werden.

Diese zentrale Frage beantwortet das Diagramm:• Welche innere Struktur besitzt mein System zu einem bestimmten

Zeitpunkt zur Laufzeit?

Diese Stärken hat das Diagramm:a. zeigt Objekte und deren Attributbelegungen zu einem bestimmten

Zeitpunktb. Grad der Detaillierung wie im Klassendiagrammc. sehr gute Darstellung von Mengenverhältnissen


17DigInf 05/06

Notationselemente

• Objekte werden mit dem Objektnamen und dem zugehörigen Klassennamen notiert.

• Attributwerte werden hinter dem Attributnamen notiert.

• Links sind Ausprägungen von Assoziationen und werden als Linie dargestellt.

objektname : Klassenname

vorname : String = „André“name : String = „Köhler“geburtsdatum : Date = 1977-03-25personalnummer : String =“4738394957“

referent : Mitarbeiter

18DigInf 05/06

Anwendungsbeispiel

Objektdiagramm

Klassendiagramm

Uni Leipzig : Arbeitgeber

: Gehalt

einkommen : Geld = 100

vorname : String = „André“name : String = „Köhler“geburtsdatum : Date = 1977-03-25personalnummer : String =“4738394957“

referent : Mitarbeiter, Person

Wissenschaftlicher Mitarbeiter

Person Mitarbeiter

vorname : String [1..*]name : Stringgeburtsdatum : Date

personalnummer : String

Arbeitgeber

Gehalt

einkommen : Geld

19DigInf 05/06

Objektdiagramm

Besondere Hinweise• Die instanziierenden Klassen und Schnittstellen sollten immer für

jedes Objekt mit angegeben werden, um die Lesbarkeit zu erhöhen.• Es sollten nur so viele Wertbelegungen angegeben werden, wie für

das Verständnis der spezifischen Konfiguration wirklich notwendig sind. Es ist keine zwingende Belegung aller Attribute mit Werten vorgeschrieben.

20DigInf 05/06




Klassendiagramm

Komponentendiagramm


Objektdiagramm

Zustandsautomat

Paketdiagramm

Aktivitätsdiagramm

Use-Case-Diagramm

Sequenzdiagramm


Verteilungsdiagramm

UML-Diagramme


hoch mittel

gering

Timingdiagramm


21DigInf 05/06

Verteilungsdiagramm

Problem:• Es soll die Verteilung der Software des Systems auf die Hardware

beschrieben werden.

Diese zentrale Frage beantwortet das Diagramm:• Wie sieht das Einsatzumfeld (Hardware, Server, Datenbanken etc.) des

Systems aus? Wie werden die Komponenten zur Laufzeit wohin verteilt?

Diese Stärken hat das Diagramm:a. zeigt das Laufzeitumfeld des Systems mit den greifbaren Systemteilenb. Darstellung von „Softwareservern“ möglichc. hohes Abstraktionsniveau, kaum Notationselemente


22DigInf 05/06

Notationselemente

• Ein Knoten repräsentiert eine Ressource, inner-halb der mit Artefakten gearbeitet werden kann.

• Es gibt zwei Ausprägungen von Knoten:• Geräte (Hardware) <<device>>• Ausführungsumgebungen (Software-

umgebung) <<ExecutionEnvironment>>

• Eine Einsatzspezifikation (deployment spec) legt die genaue Ausführung von Artefakten fest.

• Kommunikationspfade werden durch eine Linie dargestellt (gerichtet und ungerichtet); über diese werden Nachrichten ausgetauscht.

• Verteilungsbeziehungen werden durch einen gestrichelten Pfeil dargestellt; damit wird dargestellt, welche Artfakte wo ablaufen.

Knotenname

<<device>>

Name

<<ExecutionEnvironment>>

Name

<<deployment spec>>

Name

Attribut: Typ

<<deploy>>

23DigInf 05/06

Anwendungsbeispiel

• Der Application Server (HW) ist assoziiert mit einem oder mehreren DB Servern (HW), auf ihm läuft die Ausführungsumgebung J2EE Server (SW).

• Die Anwendung Application.jar (Datei) wird vom J2EE Server ausgeführt.

• Die genauen Parameter der Ausführung sind in der Datei AppDesc.xml beschrieben.

<<artifact>>

Application.jar

<<device>>

: DB Server

<<device>>

: Application Server

<<ExecutionEnvironment>>: J2EE Server

Datenhaltung1..* 1..*

<<deployment spec>>

AppDesc.xml

execution : thread

<<deploy>>

24DigInf 05/06

Verteilungsdiagramm

Änderungen gegenüber früheren UML-Versionen• Es wurde eine bessere Unterscheidung zwischen Soft- und

Hardware-Ausführungsumgebungen vorgenommen.• Verwendung von Artefakten.

Besondere Hinweise• Beschränken Sie sich durchgängig auf eine Darstellungsvariante,

wenn mehrere Notationsvarianten möglich sind (z.B. mit oder ohne Deploy-Beziehungen).

25DigInf 05/06




Klassendiagramm

Komponentendiagramm


Objektdiagramm

Zustandsautomat

Paketdiagramm

Aktivitätsdiagramm

Use-Case-Diagramm

Sequenzdiagramm


Verteilungsdiagramm

UML-Diagramme


hoch mittel

gering

Timingdiagramm


26DigInf 05/06

Paketdiagramm

Problem:• Große Softwaresysteme mit mehreren 100 Klassen lassen sich nicht

mehr von einer Person überblicken.

Diese zentrale Frage beantwortet das Diagramm:• Wie kann ich mein Modell so schneiden, dass ich den Überblick

bewahre?

Diese Stärken hat das Diagramm:a. organisiert das Systemmodell in größeren Einheiten durch logische

Zusammenfassung von Modellelementenb. Modellierung von Abhängigkeiten und Inklusionen ist möglich


27DigInf 05/06

Notationselemente

• Das Paket wird mit seinen zugehörigen Elementen dargestellt (z.B. Klassen)

• Elemente können mit einer Sichtbarkeit versehen werden (- private, + public).

• Elemente eines Pakets können wiederum Pakete sein.

• Pakete können andere Pakete importieren (Quelle importiert Ziel).

• <<access>>: importierte Classifiers werden als private definiert

• <<import>>: importierte Classifiers werden als public definiert

• <<merge>>: der komplette Classifier wird importiert und kann verändert werden

Paketname

+Classifier1 -Classifier2

Paket X

Paket A Paket B

Paket C

<<access>>

<<import>>

<<merge>>

28DigInf 05/06

Anwendungsbeispiel

• Inhalt:• P3 importiert A

(P1) als private• P3 importiert B

(P2) als public• P4 importiert P3

• Folge:• P4 darf nicht auf A

zugreifen• P4 darf auf B

zugreifen

<<access>>

P1

A

P2

B

P3 P4

<<import>>

<<import>>

29DigInf 05/06

Paketdiagramm

Änderungen gegenüber früheren UML-Versionen• Keine (1.4 und 1.5).

Besondere Hinweise• Pakete sollten mit möglichst aussagekräftigen Namen versehen

werden.• Die UML unterstützt den Modellierer nicht in der logischen

Zuschneidung der Pakete.

30DigInf 05/06




Klassendiagramm

Komponentendiagramm


Objektdiagramm

Zustandsautomat

Paketdiagramm

Aktivitätsdiagramm

Use-Case-Diagramm

Sequenzdiagramm


Verteilungsdiagramm

UML-Diagramme


hoch mittel

gering

Timingdiagramm


31DigInf 05/06

Aktivitätsdiagramm

Problem:• Es sollen Abläufe, z.B. Geschäftsprozesse, modelliert werden. Im

Vordergrund steht dabei eine Aufgabe, die in Einzelschritte zerlegt werden soll.

• Es sollen Details eines Use Cases festgelegt werden.

Diese zentrale Frage beantwortet das Diagramm:• Wie realisiert mein System ein bestimmtes Verhalten?

Diese Stärken hat das Diagramm:a. Detaillierte Visualisierung von Abläufen mit Bedingungen, Schleifen und

Verzweigungen.b. Parallelisierung und Synchronisation ist möglich.c. Darstellung von Daten- und Kontrollflüssen.


32DigInf 05/06

Starke Änderungen in UML 2.0

Neue Basis• Aktivitätsdiagramme nutzen jetzt bewährte Mittel anderer Diagramm-

sprachen, z.B. Petri-Netze, Datenflussdiagramme, Struktogramme, Programmablaufpläne.

Ablaufkonzepte höherer Programmiersprachen• Es können jetzt alle gängigen Ablaufkonzepte (Kontrollstrukturen,

Exceptions, parallele Ablaufsteuerung) modelliert werden.

Tokenkonzept• Ein Token (auch: Marke) zeigt an, an welchem Punkt sich der Ablauf

gerade befindet. • Es können beliebig viele Token unterwegs sein (parallele Abläufe).• Token werden graphisch nicht dargestellt, sondern dienen nur der

Erklärung der Abläufe.

33DigInf 05/06

Notationselemente I

• eine Aktion ist der Aufruf eines Verhaltens• die Summe aller Aktionen realisiert die

Aktivität

• ein Pfeil steht für einen• Kontrollfluss (Kante, die für die

Steuerung des logischen Ablaufs notwendig ist)

• Objektfluss (Kante, die einen Objektknoten [Token] überträgt)

• Startknoten

• Endknoten für Kontrollflüsse

• Endknoten für Aktivitäten

Aktionsname

34DigInf 05/06

Notationselemente II

• Signalempfänger und –sender sind spezialisierte Aktionen.

• Bei Erreichen des Signalsenders wird ein Signal mit Payload versendet und an einen Signalempfänger versendet, der Kontroll- und Objektfluss wird fortgesetzt.

• Beim Empfang eines Signals durch den Signalempfänger wird der nachfolgende Kontroll- und Objektfluss ausgelöst.

Aktion undSignalsender

Aktion undSignalempfänger

35DigInf 05/06

Notationselemente III• Eine Aktivität ist die gesamte Einheit, die in

einem Aktivitätsmodell modelliert wird .• Eine Aktivität besteht aus Aktionen und kann

Eingangs- und Ausgangsparameter (Objektknoten) haben.

• Aktivitäten können Vor- und Nachbedingungen haben.

• Aktivitäten können ineinander verschachtelt sein.

Zutaten CocktailZutaten mischen in Gläser füllen

Eis zerkleinern

Cocktail mixen <<precondition>>Durst

Aktivität

Eingangs-/ Ausgangsparameter

<<precondition>>

<<postcondition>>

36DigInf 05/06

Notationselemente IV

• Ein- und Ausgabeparameter einer Aktionen können auch durch Pins notiert werden.

• Aktionen können andere Aktivitäten aufrufen (Harke).

AktionsnamePin-Name Pin-Name

Aktion

Cocktail mixenFeiern

Zutaten Cocktail Getränk

Schrank durchsuchen

Salzstangen

Nahrung

37DigInf 05/06

Notationselemente V

• Der Verzweigungsknoten spaltet eine Kante in mehrere Alternativen auf (ein Token kann nur eine der ausgehenden Kanten passieren).

• Der Verbindungsknoten führt Kanten ohne Synchronisation zusammen (keine Verschmelzung der Token).

• Der Synchronisationsknoten führt eingehende Kanten zu einem gemeinsamen Ablauf zusammen (an allen eingehenden Kanten müssen Token anliegen).

• Der Parallelisierungsknoten teilt die eingehende Kante in mehrere parallele Abläufe auf.

[Bedingung1]

[Bedingung2]

[Bedingung3]

38DigInf 05/06

Notationselemente VI

• Strukturierte Knoten (gestrichelter Kasten) werden zur Gruppierung von Aktionen verwendet.

• Unterbrechungsbereiche werden verwendet, wenn bei Eintritt eines Ereignisses alle Aktionen in diesem Bereich beendet werden sollen und eine definierte Aktion ausgelöst werden soll.

• Aktivitätsbereiche werden verwendet, um Aktionen bestimmten Personen oder Organisationseinheiten zuzuordnen.

Bereich1 Bereich2

Name

39DigInf 05/06

Anwendungsbeispiel

Einkaufen

Zeitpunkt wählen Gäste einladen

[Zusagen < 50%] [Zusagen >= 50%]

Essen kochen Getränke kalt stellenEssen wegwerfen

Partyservice bestellen

[Essenverbrannt]

[Essengenießbar]

Feiern

Partygäste zählen

Vorräte prüfen

Party beenden

bei Tankstellenachrüsten

Nahrung vertilgen

[<10% sind noch da]

[>=10% sind noch da]

[keine Vorräte vorhanden]

[Vorräte vorhanden]

Essensreste wegwerfen

Müll rausbringen

{weight = 5}

Party abbrechen

betrunken insBett fallen

1

Warnung derPolizei 1

40DigInf 05/06

Aktivitätsdiagramm

Änderungen gegenüber früheren UML-Versionen• sind jetzt keine Sonderform der Zustandsdiagramme mehr, sondern

basieren auf erweiterten Petri-Netzen• damit sind viele Einschränkungen beseitigt:

• verbesserte Testbarkeit• fast automatisch erkennbare Verklemmungsfreiheit• bessere Unterstützung paralleler Flüsse• Ausführbarkeit fast vollständig möglich• mehr Flexibilität in der Modellierung durch das Tokenkonzept

Besondere Hinweise• Für die Modellierung reaktiver Systeme sollten lieber

Zustandsautomaten verwendet werden.• Verzweigungen und deren Bedingungen sollten immer exakt modelliert

werden.

Documents

1 DigInf 05/06 Diagrammtypen der UML 2.0 StrukturdiagrammeVerhaltensdiagramme Interaktionsdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm