Download - Modellierung Wintersemester 2014/15 UML (Folien teilw. … · Modellierung UML Klassen- und Objektdiagramme UML und Objekt-Orientierung Was bedeutetObjekt-Orientierung? Grundidee

Transcript

Modellierung

UML

Vorlesung “Modellierung”Wintersemester 2014/15

UML(Folien teilw. von Prof. B. Konig)

Prof. Norbert Fuhr

1 / 196

Modellierung

UML

UML: Einfuhrung

UML = Unified Modeling Language

Standard-Modellierungssprache furSoftware Engineering.

Basiert auf objekt-orientiertenKonzepten.

Sehr umfangreich, enthalt vieleverschiedene Typen von Modellen.

Entwickelt von Grady Booch,James Rumbaugh, Ivar Jacobson(1997).

2 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML und Objekt-Orientierung

Was bedeutet Objekt-Orientierung?

Grundidee

Die reale Welt besteht aus Objekten, die untereinander inBeziehungen stehen. Diese Sichtweise wird auch auf Modellierungund Softwareentwicklung ubertragen.

Etwas genauer . . .

Daten (= Attribute) werden zusammen mit der Funktionalitat (=Methoden) in Objekten organisiert bzw. gekapselt. Jedes Objekt istin der Lage Nachrichten (= Methodenaufrufe) zu empfangen,Daten zu verarbeiten und Nachrichten zu senden.

Diese Objekte konnen – einmal erstellt – in verschiedenenKontexten wiederverwendet werden.

3 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML und Objekt-Orientierung

Geschichte der Objekt-Orientierung

Entwicklung von objekt-orientierten Programmiersprachen:

60er Jahre: Simula (zur Beschreibung und Simulation vonkomplexen Mensch-Maschine-Interaktionen)80er Jahre: C++90er Jahre: Java

Verbreitung von objekt-orientierten Entwurfsmethoden:

70er Jahre: Entity-Relationship-Modell90er Jahre: Vorlaufer von UML:OOSE (Object-Oriented Software Engineering),OMT (Object Modeling Technique)Seit 1997: UMLSeit 2005: UML 2.0

4 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML und Objekt-Orientierung

Vorteile der objekt-orientierten Programmierung und Modellierung

Leichte Wiederverwendbarkeit dadurch, dass Daten undFunktionalitat zusammen verwaltet werden und es Konzeptezur Modifikation von Code (Stichwort: Vererbung) gibt.

Nahe zur realen Welt: viele Dinge der realen Welt konnen alsObjekte modelliert werden.

Vertraglichkeit mit Nebenlaufigkeit und Parallelitat:Kontrollfluss kann nebenlaufig in den Objekten ablaufen unddie Objekte konnen durch Nachrichtenaustausch bzw.Methodenaufrufe untereinander kommunizieren.

5 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML und Objekt-Orientierung

Ein Beispiel fur die Modellierung vonObjekten der realen Welt:

Fahrkartenautomat

Daten: Fahrtziele, Zoneneinteilung,Fahrtkosten

Funktionalitat: Tasten drucken,Preise anzeigen, Munzen einwerfen,Fahrkarte auswerfen

6 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML und Objekt-Orientierung

Konzepte

Klassen: definiert einen Typ von Objekten mit bestimmtenDaten und bestimmter Funktionalitat.

Beispiel: die Klasse der VRR-Fahrkartenautomaten

Objekte: Instanzen der Klasse.

Beispiel: der Fahrkartenautomat am DuisburgerHauptbahnhof, Osteingang

7 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML: Einfuhrung

Einsatzgebiete von UML

Visualisierung

Spezifikation

Konstruktion (z.B. zur Codegenerierung)

Dokumentation

8 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML: Einfuhrung

Vokabular der UML (nach Booch/Rumbaugh/Jacobson)

Dinge (things)

Beziehungen (relationships)

Diagramme (diagrams)

Dinge

Strukturen (structural things)

Verhalten (behavioral things)

Gruppen (grouping things)

Annotationen (annotational things)

9 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML: Einfuhrung

Beziehungen

Abhangigkeiten (dependencies)

Assoziationen (associations)

Generalisierungen (generalizations)

Realisierungen (realizations)

10 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML: Einfuhrung

UML-Diagramme

Verhaltens-diagramme

Interaktions-

diagramme

Objekt-

diagramm

Kompositions-

strukturdiagramm

diagrammeStruktur-

Klassen-

diagramm

Komponenten-

diagramm

Verteilungs-

diagramm

Paket-

diagramm

Diagrammeder UML

diagramm diagramm

diagramm

Aktivitats- Anwendungsfall-

Zustands-

diagrammdiagramm

Interaktionsuber-

sichtsdiagramm

Zeitverlaufs-/

Timing-Diagramm

Kommunikations-Sequenz-

11 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML: Einfuhrung

Diagramme (I)

Strukturdiagramme

Klassendiagramme (class diagrams)Objektdiagramme (object diagrams)Kompositionsstrukturdiagramme (composite structurediagram)Paketdiagramme (package diagram)Verteilungsdiagramme (deployment diagram)Komponentendiagramme (component diagrams)

12 / 196

Modellierung

UML

Klassen- und Objektdiagramme

UML: Einfuhrung

Diagramme (II)

Verhaltensdiagramme

Aktivitatsdiagramme (activity diagrams)Zustandsdiagramme (state diagrams)Anwendungsfalldiagramm (use case diagrams)

Interaktionsdiagramme

Sequenzdiagramme (sequence diagrams)Kommunikationsdiagramm (communicationdiagram)Zeitverlaufsdiagramm (timing diagram)Interaktionsubersichtsdiagramm (interactionoverview diagram)

Wir werden im Folgenden einige dieser Begriffe mit Leben fullen.

13 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Wir beginnen mit Klassen- und Objektdiagrammen . . .

Beispiel: Klasse der zweidimensionalen Punkte mit x-,y -Koordinaten und Operationen zum Auslesen der Koordinaten

Graphische Darstellung einer Klasse

x: inty: int

Klassenname

Attribute (evtl. mit Typ)

Operationen/Methodenget x(): intget y(): int

Point

14 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Bemerkungen:

Bei den Attributen handelt es sich um sogenannteInstanzattribute, d.h., sie gehoren zu den Instanzen einerKlasse (nicht zur Klasse selbst).

Man kann die Sichtbarkeit eines Attributes bzw. einerMethode spezifieren, indem man + (offentlich/sichtbar) oder− (privat/nicht sichtbar) vor den Attribut-/Methodennamenschreibt.Auch die Angabe # (geschutzt/protected) ist moglich. Indiesem Fall ist das Attribut nur fur Klassen sichtbar, die vonder entsprechenden Klasse erben.

15 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Bemerkungen:

Attribute haben im allgemeinen Typen, manchmal auchVorgabewerte (= initiale Werte). Dies wird dannfolgendermaßen notiert:

x: int = 0

Mehrstellige Operationen mitRuckgabewert, werden mit ihren Typen folgendermaßen notiert:

add(m: int, n: int): int

16 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Graphische Darstellung einer Instanz einer Klasse

x: inty: int

get x(): intget y(): int

�instantiate�

x = 0y = 0

Point mypoint :Point

17 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Graphische Darstellung von Generalisierung/Spezialisierung

c: stringx: inty: int

get x(): intget y(): int

color(): stringsetcolor(c: string)

Colored PointPoint

Die Klasse Colored Point spezialisiert die Klasse Point.Umgekehrt generalisiert Point die Klasse Colored Point.

18 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Bemerkungen:

In einer solchen Situation nennt man Point Superklasse undColored Point Subklasse.

Da die Subklasse die Attribute, Methoden und Assoziationender Superklasse erbt (und diesen noch weitere hinzufugenkann), spricht man auch von Vererbung. Außerdem kann manin der Subklasse Methoden der Superklasse uberschreiben unddurch neue ersetzen.

19 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Wie kann man Beziehungen zwischen Klassen in UML darstellen?

Es gibt folgende mogliche Beziehungen:

Assoziation

Aggregation

Komposition

20 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Wir beginnen mit der schwachsten Relation zwischen zwei Klassen:der Assoziation.

Assoziation

Es gibt eine Assoziation zwischen den Klassen A und B, wenn

es eine semantische Beziehung zwischen den Klassen gibt.

Ublicherweise werden Assoziationen durch Referenzen realisiert(d.h., eine der Klassen hat ein Attribut vom Typ der anderenKlasse).

21 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Beispiel fur eine Assoziation

Eine Person besitzt ein Auto.

besitzt

Person Auto

22 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Bemerkungen:

Es kann eine Leserichtung der Assoziation eingefuhrt werden:

besitzt

Person Auto

Die Navigationsrichtung (beschrieben durch eine Pfeilspitze)kann von der Leserichtung abweichen. Sie beschreibt, welcheKlasse ihren Assoziationspartner kennt (und daher seineMethoden aufrufen kann).

besitzt

Person Auto

Hier kennen sich beide Klassen gegenseitig.

23 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Multiplizitaten: an beide Enden der Assoziationen konnenMultiplizitaten in Form von Intervallen m..n (oder einfach nurm fur m..m) angegeben werden. Hier besitzt eine Person biszu funf Autos. Ein Auto ist im Besitz genau einer Person.

besitzt

Person Auto1 0..5

Falls die Multiplizitat großer als eins ist, muss dies in derImplementierung durch eine Liste (oder Menge oder Array)von Referenzen realisiert werden.

24 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Multiplizitaten allgemein: in folgendem Diagramm konnen iInstanzen von A (mit m ≤ i ≤ n) mit einer Instanz von Bassoziert sein. Umgekehrt konnen j Instanzen von B (mitk ≤ j ≤ l) mit einer Instanz von A assoziiert sein.

A Bm..n k..l

Falls es keine obere Schranke gibt, wird ein Stern (=unendlich) verwendet. Beispielsweise steht 2..∗ fur“mindestens zwei”.

Die Multiplizitat 0..∗ wird als Standardwert angenommen,wenn keine Angabe vorhanden ist.

25 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Rollen: Klassen konnen in verschiedenen Assoziationenverschiedene Rollen spielen. Rollen werden auch an denAssoziationen notiert (und konnen alle Bestandteile einesAttributs enthalten).

HaendlerKaeufer

EndkundeVerkaeuferKaeuferVerkaeufer

Grosshandel

26 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Die nachste Relation – Aggregation – ist etwas starker.

Aggregation

Es gibt eine Aggregation zwischen den Klassen A und B, wenn

Instanzen der Klasse A Instanzen der Klasse B als Teileenthalten. (Ein “Ganzes” enthalt mehrere “Teile”.)

27 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Beispiel fur eine Aggregation

Ein Parkplatz “enthalt” mehrere Autos.

AutoParkplatz

enthaelt

0..1 0..∗

28 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Die starkste Relation ist die sogenannte Komposition.

Komposition

Es gibt eine Komposition zwischen den Klassen A und B, wenn

Instanzen der Klasse A Instanzen der Klasse B als Teileenthalten und die Lebenszeit der Teile wird vom“Ganzen” kontrolliert. Das heißt, die Teile konnen(mussen) geloscht werden, sobald die Instanz der KlasseA geloscht wird.

29 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Beispiel fur eine Komposition

Ein Auto besteht aus vier Radern.

Auto Rad

besteht aus

1 4

Die Rader werden zerstort, sobald das Auto zerstort wird.

Bemerkung: In diesem Fall muss die Multiplizitat, die an derschwarzen Raute steht, immer 0 oder 1 sein. Jedes Teil kannhochstens zu einem Ganzen gehoren.

30 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

In Klassendiagrammen befinden sich normalerweise nicht nur zweiKlassen mit einer Assoziationen, sondern verschiedene Klasseneines Programms oder Moduls, mit ihren Beziehungenuntereinander.

Beispiel:

AutoParkplatz

enthaelt

0..1 0..∗

bes

itzt

Person

1

0..5

Rad

besteht aus

1 4

31 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

n-are Assoziation

Neben binaren (zweistelligen) Assoziationen gibt es auch n-areAssoziationen, die eine Beziehung zwischen n Klassen beschreiben.

1..∗

0..∗

Vorspeise

0..∗ Dessert

Menue

Hauptgericht

32 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Generalisierungsgruppen

Klassen konnen in unterschiedlicher Weise spezialisiert bzw.unterteilt werden. Daher konnen Generalisierungen zu Gruppenzusammengefasst werden.

Person

Frau

Mann

AlterGeschlecht

Erwachsener

Kind

Dabei wird die jeweilige Generalisierungsgruppe (hier: Alter bzw.Geschlecht) im Diagramm angegeben.

33 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Den Generalisierungsgruppen konnen Eigenschaften (ingeschweiften Klammern) zugeordnet werden.

complete/incomplete:

complete: die Generalisierungsgruppe ist vollstandig, d.h.,sie uberdeckt alle Instanzen der Klasse.incomplete: die Generalisierungsgruppe ist unvollstandig.

disjoint/overlapping:

disjoint: die spezialisierenden Klassen besitzen keinegemeinsamen Instanzen (keine Uberlappung).overlapping: die spezialisierenden Klassen konnengemeinsame Instanzen besitzen.

34 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Beispiele fur die Eigenschaften complete/incomplete unddisjoint/overlapping:

{complete,disjoint}

Person

Frau

Mann

Geschlecht

{complete,disjoint}

Hier handelt es sich um eine Partitionierung der Instanzen derKlasse.

35 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

{incomplete,disjoint}

Alter

Person

{incomplete,disjoint}

Kind

Erwachsener

Warum unvollstandig? es fehlt eine Klasse Jugendlicher.

36 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

{complete,overlapping}

Lebensraum

Tier

{complete,overlapping}

Fliegendes Tier

Meerestier

Landtier

Schildkroten sind sowohl Land- als auch Meerestiere.

37 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

{incomplete,overlapping}

Tier

LebensraumLandtier

Meerestier

{incomplete,overlapping}

Fliegende Tiere fehlen.

38 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Mehrfachvererbung

Es ist auch moglich, dass eine Klasse von mehreren Klassen erbt,d.h., eine Spezialisierung verschiedener Klassen ist. Dies bezeichnetman als Mehrfachvererbung.

Frau Kind

Erwachsener

AlterGeschlecht

Person

Mann

Maedchen

Ein Madchen ist sowohl ein Kind als auch ein weiblicher Mensch(= Frau).

39 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Basierend auf diesen graphischen Notation sollte man einobjekt-orientiertes System modellieren, bevor es implementiertwird. Dabei stellen sich insbesondere folgende Fragen:

Welche Objekte und Klassen werden benotigt?

Welche Merkmale haben diese Klassen und welcheBeziehungen bestehen zwischen Ihnen?

Wie sollen die Klassen eingesetzt werden?

Welche Methoden stellen diese Klassen zur Verfugung? Wiewirken diese Methoden zusammen?

In welchen Zustanden konnen sich Objekte befinden undwelche Nachrichten werden wann an andere Objektegeschickt?

40 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Ein großeres Beispiel fur objekt-orientierte Modellierung undProgrammierung: Wir modellieren eine Bank.

Folgende Anforderungen werden gestellt:

Eine Bank

hat mehrere Kundenund mehrere Angestellteund fuhrt eine Menge von Konten.

Konten konnen

Giro- oder Sparkonten sein. (Ein Sparkonto wirft hohereZinsen ab, darf aber nicht ins Minus absinken.)in Euro oder in Dollar gefuhrt werden.

41 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Auf den Konten sollen folgende Operationen ausgefuhrtwerden konnen:

EinzahlenAbhebenVerzinsenUmbuchen

Außerdem sollen alle Objekte (inklusive der Bank) ihreDarstellung ausdrucken konnen. Dazu hat jedes Objekt eineeigene print-Methode.

Das bezeichnet man auch als Overloading: eine Methodegleichen Namens kann bei Objekten verschiedener Klassenaufgerufen werden und erzielt dort unterschiedliche Effekte.

42 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Bank:

Bank

neuen kunden anlegen()

name: string

konten verzinsen()print()

angestellten einstellen()

Methoden: neuen Kunden anlegen;neuen Angestellten einstellen; alleKonten verzinsen

Außerdem: Eine Bank besteht (inKompositionsrelation) aus einerMenge von Konten, dieverschwinden, wenn die Bankverschwindet. Außerdem gibt esAggregationen mit einer Liste vonKunden und von Angestellten.

43 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Konto:

Konto

nummer: stringzins: float

verzinsen()print()

einzahlen(wert: Betrag)

umbuchen auf(kto: konto,abheben(wert: Betrag)

kontostand: Betrag

wert: Betrag)

Attribute: Kontonummer, Zins

Methoden: Kontostand abfragen,einzahlen, abheben, umbuchen einesBetrags auf ein anderes Konto,Konto verzinsen

Außerdem: Konto steht in einerKompositionsrelation mit Betrag,d.h., jedes Konto enthalt einenBetrag (siehe Klassendiagramm).

44 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Girokonto:

Girokonto

Konto

zins: float = 0.005

Die Klasse Girokonto wird vonKonto abgeleitet. Typischerweise istder Zins bei Girokonten niedriger alsbei Sparkonten. Von daher wirddieser auf einen niedrigerenAnfangswert gesetzt.

45 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Sparkonto:

Konto

Sparkonto

zins: float = 0.02

abheben(wert: Betrag)

wert: Betrag)umbuchen auf(kto: Konto,

Bei der Klasse Sparkonto muss – wiebeim Girokonto – ein neuerAnfangswert fur den Zins gesetztwerden.

Außerdem: es muss darauf geachtetwerden, dass das Konto nicht insMinus abgleitet. Dazu werden dieentsprechenden Methodenuberschrieben (in derImplementierung muss dieBedingung entsprechend getestetwerden).

46 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Betrag:

wert: float

Betrag

negativ(): bool

print()mult(faktor: float)

plus(wert: Betrag)minus(wert: Betrag)

Methoden: Test, ob Konto imMinus; Betrag addieren,subtrahieren; Multiplikation mit einerGleitpunktzahl (zum Verzinsen!)

Betrage mussen im allgemeinen in einer Wahrung angegebenwerden. Daher werden von der Klasse Betrag die UnterklassenEuro und Dollar abgeleitet.

47 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Euro:

Euro

betrag in euro():float

Betrag

Von Betrag wird zunachst die KlasseEuro abgeleitet.

Methoden: Betrag in Euro ausgeben

48 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Dollar:

Betrag

Dollar

betrag in dollar():float

Von Betrag wird außerdem dieKlasse Dollar abgeleitet.

Methoden: Betrag in Dollarausgeben

49 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Person:

Person

name: string

print()

Methoden: nur die print-Methode,weitere Methoden werden in denUnterklassen definiert

Außerdem: Person steht in einerAssoziationsrelation mit einer Listevon Konten, die entweder dieserPerson gehoren (Kunde) oder auf diediese Person Zugriff hat(Angestellte/r).

50 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Angestellter (erbt von Person):

Angestellter

zugriff auf konto(kto:Konto)

Methoden: Zugriff auf ein Kontoerlangen

51 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

Klasse Kunde (erbt von Person):

Kunde

konto eroeffnen()

Methoden: Konto eroffnen (hierkonnte noch ein Parameter ubergebenwerden, der beschreibt, ob das Kontoein Giro- oder Sparkonto sein soll undob es in Euro oder Dollar gefuhrtwerden soll)

Außerdem: Ein Kunde steht in einerAssoziationsrelation mit seinemBetreuer.

52 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Beispiel: Modellierung einer Bank

hat_Zugriff_aufKontotyp

Status

Waehrung

Betrag

Euro

betreut

name: string

Person

wert: float

Girokonto Sparkonto

Konto

1

1

Bank

Dollar

Kunde Angestellter

besteht aus

besitzt

1

1

53 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Abstrakte Klasse

Eine Klasse heißt abstrakt, wenn sie selbst keine Instanzen habenkann. Dazu wird die Eigenschaft {abstract} unter demKlassennamen angegeben. Manchmal wird stattdessen auch derKlassenname kursiv geschrieben.

Beispiel: in dem Bank-Beispiel mochte man beispielsweise nie eineInstanz der Klasse Person bilden, sondern nur von Kunde oderAngestellter.

Person{abstract}

54 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Wir betrachten nun Objektdiagramme. Ein Objekt ist eine Instanzoder Auspragung einer Klasse.

Objekte und Klassen

x: inty: int

get x(): intget y(): int

�instantiate�

x = 0y = 0

Point mypoint :Point

Ein Objektdiagramm beschreibt eine Art Momentaufnahme desSystems: eine Menge von Objekten, wie sie zu einem bestimmtenZeitpunkt vorhanden sind.

55 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Bemerkungen:

Ein Objekt kann, muss aber keinen Namen haben. Es mussaber die Klasse angegeben werden, von der dieses Objekt eineInstanz ist. (In der Form: :Point.)

Die Klassen mussen in dem Diagramm nicht graphischdargestellt werden. Es kann aber manchmal angemessen sein,“Bauplan” und “Produkt” gemeinsam darzustellen.

Nicht alle Attributbelegungen des Objekts mussen angegebenwerden.

56 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Links

Ein Link beschreibt eine Beziehung zwischen zwei Objekten. Er isteine Instanz einer Assoziation auf Klassenebene.

Bemerkungen:

Links sind nicht mit Multiplizitaten beschriftet, ein Linkreprasentiert genau eine Beziehung.

Es ist jedoch darauf zu achten, dass dieMultiplizitatsbedingungen des Klassendiagramms eingehaltenwerden. D.h., die Anzahl der Objekte, die miteinander inBeziehung stehen, mussen innerhalb der jeweiligen Schrankensein.

57 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Zuruck zum Beispiel: Autos, Parkplatz, Rader

Wir betrachten zunachst noch einmal das Klassendiagramm:

AutoParkplatz

enthaelt

0..1 0..∗

bes

itzt

Person

1

0..5

Rad

besteht aus

1 4

58 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Dieses Objektdiagramm passt zum vorherigen Klassendiagramm:

:Rad

:Rad

:Rad

:Rad

enthaelt

enthaeltb

esit

zt

besteht ausb

esitzt

besteht aus

peter

:Rad

:Rad

:Rad

:Rad

gruenerAudi

gabi

:Person

:Person

:AutoparkplatzLBereich

:ParkplatzschwarzerVW

:Auto

59 / 196

Modellierung

UML

Klassen- und Objektdiagramme

Klassen- und Objektdiagramme

Bemerkungen:

Auch Aggregations- und Kompositionssymbole durfen inObjektdiagrammen auftauchen.

Achtung: Beziehungen (Assoziationen, Aggregationen,Kompositionen) zwischen Klassen werden vererbt und mussendann auch entsprechend im Objektdiagramm bei denInstanzen der Unterklassen auftauchen.

Beispiel:

besitzt

besitzt

:Sparkonto

:Girokonto

klaus :Kunde

60 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Wir betrachten nun sogenannte Aktivitatsdiagramme (activitydiagrams), das sind UML-Diagramme mit denen man Ablaufplane,Reihenfolgen von Aktivitaten, parallele Aktivitaten, etc.modellieren kann.

Sie werden beispielsweise verwendet, um Geschaftsprozesse (auchWorkflow-Prozesse) des Auftraggebers zu modellieren. Sie konnenebenso eingesetzt werden, um interne Systemprozesse zubeschreiben.

Aktivitatsdiagramme sind in vielen Aspekten ahnlich zuPetri-Netzen. Im Unterschied zu Petri-Netzen bieten sie zusatzlicheModellierungsmoglichkeiten, haben jedoch keine formale Semantik.

61 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Plan einreichen

Plan erstellen

Phase paralleler

Aktivitaten

Bauplatz wahlen

Startknoten

Architekt suchen

Arbeit im Buro

[angenommen]

Plan

[nicht angenommen]

Arbeit auf Baustelle

Aktivitatsende

Haus fertigstellen

Beispiel:

Hausbau

62 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Wir vergleichen nun die Bestandteile von Aktivitatsdiagrammenmit Petrinetzen (angelehnt an die Semantik von Storrle):

Aktion

Eine Aktion wird durch ein Rechteck mit abgerundeten Eckendargestellt. Es entspricht einer Transition eines Petrinetzes.

Plan erstellen Plan erstellen

63 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Kontrollfluss

Der Kontrollfluss, d.h. die Kanten, zwischen den Aktionen wird indem entsprechenden Petrinetz durch Hilfsstellen dargestellt.

Architekt suchen

Bauplatz wahlen

Plan erstellen

Bauplatz wahlen

Architekt suchen

Plan erstellen

64 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Objektknoten

Objektknoten beschreiben Speicher fur die Ubergabe von Objektenbzw. Ressourcen. Sie entsprechen den Stellen des Petrinetzes.

Plan

Plan

Plan erstellen

Plan einreichen

Plan erstellen

Plan einreichen

Bemerkung: Objektknoten sind mit Klassennamen beschriftet. Siekonnen mehrere Instanzen dieser Klasse enthalten.

65 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Entscheidungsknoten (auch: Verzweigungsknoten)

Entscheidungsknoten (decision nodes) beschreiben eineVerzweigung des Kontrollflusses, wobei aus den moglichenKontrollflussen genau einer ausgewahlt wird. Sie werden durchHilfsstellen reprasentiert, die sich in der Vorbedingung mehrererTransitionen befinden.

Plan einreichen

Hilfstransition[angenommen]

[nicht angenommen]

Plan einreichen

Bei Bedarf (v.a. bei nachfolgenden Entscheidungs- oderObjektknoten) muss noch eine Hilfstransition eingefuhrt werden.

66 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Bemerkung zu Entscheidungsknoten:

Uberwachungsbedingungen (Guards), die den Kontrollfluss steuern,werden in eckigen Klammern an den ausgehenden Kontrollflussennotiert. Ahnliche Guards existieren auch in attributierten Netzen.

67 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Verbindungsknoten

Es gibt auch sogenannte Verbindungsknoten (merge nodes), diemehrere alternative Kontrollflusse zusammenfassen. Sie konnendurch Hilfsstellen dargestellt werden, die sich in derNachbedingung mehrerer Transitionen befinden.

Es gibt auch Knoten, die sowohl Entscheidungs- als auchVerbindungsknoten sind, d.h., mehrere eingehende und mehrereausgehende Kontrollflusse haben.

68 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Gabelung (auch: Parallelisierungsknoten)

Eine Gabelung (fork node) teilt einen Kontrollfluss in mehrereparallele Kontrollflusse auf.Sie entspricht einer Transition mit mehreren Stellen in derNachbedingung.

69 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Vereinigung (auch: Synchronisationsknoten)

Analog dazu gibt es die Vereinigung (join node), die mehrereparallele Kontrollflusse zusammenfasst. Sie wird durch eineTransition dargestellt, die mehrere Stellen in der Vorbedingung hat.

Wie Entscheidungs- und Verbindungsknoten kann man Gabelungenund Vereinigungen zu einem Element zusammenfassen.

70 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Bitte beachten:

Kontrollflusse durfen nur an Objektknoten, Entscheidungsknotenund Gabelungen aufgespalten und an Objektknoten,Verbindungsknoten und Vereinigungen wieder zusammengefuhrtwerden.

Folgendes ist nicht erlaubt:

AktionAktion

71 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Startknoten

Ein Startknoten entspricht einer initial markierten Stelle. EinAktivitatsdiagramm darf nur einen Startknoten haben, in den keinKontrollfluss hineinfuhrt

72 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Aktivitatsende

Das Aktivitatsende signalisiert, dass alle Kontrollflusse beendetwerden. Es gibt keine Entsprechung in Petrinetzen.

Es gibt auch ein Symbol fur das Flussende, das nur den in eshineinlaufenden Kontrollfluss beendet.

73 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Plan einreichen

fork

Arbeit im BuroArbeit auf Baustelle

join

Architekt suchen

PlanPlan erstellen

Bauplatz wahlen

Hilfstransition

Haus fertigstellen

Ubersetztes

Petrinetz

74 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Aktivitatsdiagramme enthalten noch mehr Anleihen ausPetrinetzen. Beispielsweise konnen auch die Kapazitat einesObjektknotens und das Gewicht eines Kontrollflusses spezifiziertwerden.

Gericht

{upperBound=6}

2Gericht zubereiten Gericht servieren

6

Gericht zubereiten Gericht servieren

Gericht

{weight=2}

Dabei beschreibt upperBound die Kapazitat einer Stelle (maximal6 Gerichte durfen gleichzeitig fertig sein) und weight das Gewicht(immer 2 Gerichte werden gleichzeitig serviert).

In Aktivitatsdiagrammen darf noch zusatzlich spezifiziert werden,in welcher Reihenfolge die Objekte aus dem Objektknotengenommen werden (unordered, ordered, LIFO, FIFO).

75 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Vorsicht:

Die Entsprechung zwischen Aktivitatsdiagrammen undPetrinetzen ist nicht immer ganz exakt. Nicht alle Konzepteentsprechen einander.

Das liegt teilweise auch daran, dass Aktivitatsdiagramme nurein semi-formales Modell sind und nicht alle Aspektevollstandig spezifiziert sind.

76 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Es gibt auch die Moglichkeit zur weiteren Strukturierung vonAktivitatsdiagrammen:

Aktivitatsbereiche (activity partitions/swimlanes)

Zusammenfassung mehrerer Knoten (Aktionen, Objektknoten,etc.) zu einer Einheit. Dies dient im allgemeinen dazu, um dieVerantwortung fur bestimmte Aktionen festzulegen.

Gast Kellner

Gericht bestellen

Gericht servierenGericht verspeisen

Bestellung aufnehmen

77 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramm mit Aktivitatsbereichen

78 / 196

Modellierung

UML

Verhaltensdiagramme

Aktivitatsdiagramme

Weitere Elemente von Aktivitatsdiagrammen:

Pins: Parameter und Parametersatze fur Aktionen

Senden und Empfang von Signalen

Kontrollstrukturen: Schleifenknoten, Bedingungsknoten

Unterbrechungsbereiche (interruptible activity region) zurBehandlung von Ausnahmen (Exceptions)

Expansionsbereiche (expansion region) zur wiederholtenAusfuhrung von Aktivitaten fur mehrere ubergebene Objekte

79 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Zustandsdiagramme (state diagrams, auch state machine diagramsoder statecharts) genannt, sind eng verwandt mit den bereitseingefuhrten Zustandsubergangsdiagrammen.

Sie werden eingesetzt, wenn bei der Modellierung der Fokus auf dieZustande und Zustandsubergange des Systems gelegt werden soll.

Im Gegensatz zu Aktivitatsdiagrammen werden auch weniger dieAktionen des Systems, sondern eher die Reaktionen des Systemsauf die Umgebung beschrieben.

80 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Anwendungen sind die Modellierung von:

Protokolle, Komponenten verteilter Systemen

Benutzeroberflachen

Eingebettete Systemen

. . .

Zustandsdiagramme wurden 1987 von David Harel unter demNamen Statecharts eingefuhrt. Harel modellierte damit vollstandigseine Armbanduhr.

81 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Eigenschaften von Zustandsdiagrammen:

Zustande und Zustandsubergange (Transitionen)

Hierarchisch aufgebaute Zustande

“Parallelschalten” von Zustandsdiagrammen durch Regionen

Historien, um sich fruher besuchte Zustande zu merken und indiese zuruckzukehren

Viele dieser Eigenschaften dienen dazu, unubersichtlicheZustandsdiagramme mit vielen Zustanden und Ubergangenubersichtlicher und kompakter zu gestalten.

82 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Wir lernen Zustandsdiagramme am Beispiel der Modellierung einerArmbanduhr kennen (stark vereinfacht gegenuber HarelsArmbanduhr).

Die Armbanduhr hat zwei Knopfe (a,b) und zwei Modi(Zeitanzeige, Alarmeinstellung). Zwischen diesen Modi wechseltman mit Hilfe von Knopf a.Der Alarm kann aus (off) oder an (on) sein. Man kann zwischenden Alarmzustanden mit Hilfe von Knopf b wechseln.

ba 9:21 ba baAlarm Alarm

a

a

a

b

b

on off

83 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Wir beginnen zunachst mit der Modellierung der Minutenanzeige.

10 . . .

. . .

after(1 min) after(1 min)

after(1 min) after(1 min)after(1 min)

2

575859

84 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Zustand

Ein Zustand eines Zustandsdiagramms wird durch ein Rechteckmit abgerundeten Ecken dargestellt.

0

Startzustand

Der Startzustand wird durch einen schwarzen ausgefullten Kreisgekennzeichnet (ahnlich wie bei Aktivitatsdiagrammen).

0

85 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Endzustand

Endzustande werden wie das Aktivitatsende inAktivitatsdiagrammen gekennzeichnet.

A

Fur den Fall, dass man ein System modelliert, das nicht terminierensoll, gibt es keinen Endzustand (wie in unserem Beispiel).

86 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Transition (= Zustandsubergang)

Eine Transition ist ein Pfeil, der mit Ereignis [Bedingung]/Effektbeschriftet ist. (Bedingung und Effekt sind optional.)

Ereignis: Signal oder Nachricht, die die entsprechendeTransition auslosen.

10after(1 min)

Bedingung: Uberwachungsbedingung (auch Guard genannt).

Effekt: Effekt, der durch die Transition ausgelost wird .

Im obigen Beispiel (Minutenanzeige) gibt es nur Ereignisse(sogennante time events), die die Zeitspanne spezifizieren, nachder die Transition ausgelost wird. Es gibt aber auch andereEreignisse, beispielsweise Methodenaufrufe.

87 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Neben den Effekten, die durch Transitionen ausgelost werden,konnen in einem Zustand weitere Aktionen bei Eintritt, Verweilenoder Verlassen ausgelost werden.

Sie haben den gleichen Aufbau wie die Beschriftung einerTransition: Ereignis [Bedingung]/Effekt. Dabei kann Ereignis unteranderem folgendes sein:

entry: der entsprechende Effekt wird bei Eintritt in denZustand ausgelost.

do: der Effekt ist eine Aktion, die nach Betreten des Zustandsausgefuhrt wird und die spatestens dann endet, wenn derZustand verlassen wird

exit: der entsprechende Effekt wird bei Verlassen des Zustandsausgelost.

88 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beispiel: die Uhr soll zu jeder vollen Stunden ein Signal von sichgeben. Daher wird die Aktion beep bei Eintritt in den Zustand 0ausgelost.

0

entry/beep

89 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Wie sieht es mit der Stundenanzeige aus? Diese soll parallel zurMinutenanzeige laufen, d.h., die Uhr ist in zwei Zustandengleichzeitig, ein Zustand fur die Stunden, der andere fur dieMinuten. Diese Situation wird durch Regionen modelliert.

Region

Regionen unterteilen ein Zustandsdiagramm in zwei Bereiche, dieparallel zueinander ausgefuhrt werden.

Dies erlaubt uns, insgesamt nur 24 + 60 = 84 Zustande, anstatt24 · 60 = 1440 Zustande zu zeichnen.

90 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

So sieht das modifizierte Zustandsdiagramm fur die Uhr jetzt aus:

1 . . .

. . .

1 . . .

. . .

0

entry/beepafter(1 min) after(1 min)

after(1 min) after(1 min)

2

575859

after(1 min)/h

20

22 2123

h h

hhh

Stunden

Minuten

91 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Bemerkungen:

Es gibt jetzt zwei Startzustande, die beide zu Beginn betretenwerden (Uhrzeit: 0:00).

Da Stunden- und Minutenanzeige nicht vollkommenunabhangig voneinander arbeiten, ist eine Synchronisationeingebaut. Die Transition in den Minutenzustand 0 lost einenEffekt h (h fur “hour”) aus.

Dieser Effekt ist dann ein Trigger, der das entsprechendeEreignis triggert und den Ubergang in den nachstenStundenzustand verursacht. Die beiden Transitionen werdensynchronisiert und finden gleichzeitig statt.

92 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Bemerkungen:

Transitionen verbrauchen im allgemeinen keine Zeit (imGegensatz zum Aufenthalt in Zustanden).

Neben Triggern, die direkt ausgefuhrt werden, gibt es auchEvents, die zunachst in einer Event Queue (= Warteschlange)abgelegt werden. Diese Warteschlange wird schrittweiseabgearbeitet, wobei die entsprechenden Ereignisse ausgelostwerden. Damit kann asynchrone Kommunikation beschriebenwerden.

Effekte konnen direkte Kommunikation bedeuten(beispielsweise Methodenaufrufe), konnen aber auchsogenannte Broadcasts (= Rundrufe) sein. Diese sind uberallim Zustandsdiagramm sichtbar. (Die ursprunglicheStatecharts-Semantik von Harel verwendete nur Broadcasts.)

93 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Nun soll noch die Moglichkeit hinzugefugt werden, das Alarmsignalzur vollen Stunden aus- und wieder einzuschalten. Dazu fuhren wirweitere Zustande (Alarm on, off) ein, in die man durch Druckenvon a gelangt.

Problem: wir brauchen mindestens 84 mit a beschrifteteTransitionen, die aus den Stunden-/Minutenzustanden ausgehen!Das sind ziemlich viele . . .

Dafur bieten Zustandsdiagramme folgende Losung:

Zusammengesetzte Zustande

Zusammengesetzte Zustande dienen dazu, um Hierarchien vonZustanden zu modellieren und damit ein- und ausgehendeTransitionen zusammenzufassen.

94 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Damit ergibt sich folgendes Diagramm:

1 . . .

. . .

1 . . .

. . .

20

22 2123

h h

hhh

Stunden

Minuten

after(1 min) after(1 min)

after(1 min) after(1 min)

2

575859

after(1 min)/h

0

entry/beep

on

off

a

ab b

Alarm

95 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Um eine gewisse Flexibilitat bei der Modellierung zu haben, werdenverschiedene Eintritts- und Austrittsmoglichkeiten bereitgestellt.

Eintrittsmoglichkeiten in einen Zustand (graphisch)

C

B

D E

A H H∗

Eintritt uber die

tiefe Historie

Eintritt uber die

flache Historie

Eintritt

Expliziter

Standard-Eintritt

96 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beschreibung der Eintrittsmoglichkeiten:

Standard-Eintritt: dabei wird der Startzustand deszusammengesetzten Zustands angesprungen.

(Fortsetzung bei B, was schließlich zu einer Fortsetzung bei Dfuhrt)

Expliziter Eintritt: es wird bei dem explizit angegebenenFolgezustand fortgesetzt.

(Fortsetzung bei C .)

97 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beschreibung der Eintrittsmoglichkeiten (Fortsetzung):

Eintritt uber die tiefe Historie: Wurde der zusammengesetzteZustand bereits fruher besucht, so wird der letzte vor demVerlassen des Zustands aktive Unterzustand dertiefstmoglichen Ebene betreten.

(Falls also der zusammengesetzte Zustand das letzte Mal vonE aus verlassen wurde, so wird jetzt wieder bei E fortgesetzt.)

Falls man noch niemals zuvor diesen zusammengesetztenZustand betreten hat, so wird der Zustand betreten, der mitder Kante gekennzeichnet ist, die aus dem H∗-Knoten ausgeht.

98 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beschreibung der Eintrittsmoglichkeiten (Fortsetzung):

Eintritt uber die flache Historie: Wurde der zusammengesetzteZustand bereits fruher besucht, so wird der letzte vor demVerlassen des Zustands aktive Unterzustand der oberstenEbene betreten.

(Falls also der zusammengesetzte Zustand das letzte Mal vonE aus verlassen wurde, so wird jetzt bei B fortgesetzt, wasletztendlich zu einer Fortsetzung bei D fuhrt.)

Außerdem: Eintritt uber einen Eintrittspunkt (wird hier nichtbehandelt).

99 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Wenn ein Zustand in mehrere Regionen unterteilt ist, so ergebensich bei den Eintrittsmoglichkeiten einige Besonderheiten.

Eintrittsmoglichkeiten bei Regionen (graphisch)

A B

C D

Standard-Eintritt

ExpliziterEintritt

Eintrittuber Gabelung

100 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beschreibung der Eintrittsmoglichkeiten bei Regionen:

Standard-Eintritt: dabei werden die jeweiligen Startzustandeder Regionen angesprungen.

(Fortsetzung bei A und C )

Expliziter Eintritt: ein Zustand einer Region wird direktangesprungen. In der anderen Region wird bei dementsprechenden Startzustand fortgesetzt.

(Fortsetzung bei B und C .)

Eintritt uber Gabelung: ahnlich wie bei Aktivitatsdiagrammenwird eine Gabelung eingesetzt, um die beiden anzuspringendenZustande in den Regionen zu kennzeichnen.

(Fortsetzung bei B und D.)

101 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Austrittsmoglichkeiten aus einem Zustand (graphisch)

C

B

D E

A

Austritt aus eineminneren Zustand

Austritt auseinem zusammengesetzten Zustand

102 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beschreibung der Austrittsmoglichkeiten:

Austritt aus einem zusammengesetzten Zustand: sobald dasmit der Transition assoziierte Ereignis stattfindet, wird jederbeliebige (Unter-)Zustand von A verlassen.

Austritt aus einem inneren Zustand: die Transition wird nurgenommen, wenn man sich gerade im entsprechenden Zustand(hier: Zustand E) befindet (und das entsprechende Ereignisstattfindet).

Außerdem: Austritt uber einen Austrittspunkt, uber einenEndzustand oder Terminator (wird hier nicht behandelt).

103 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beispiel zu Austrittsmoglichkeiten:

B C

A

D

E

a

entspricht B C

A

D

E

a aa

104 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Auch fur Austrittsmoglichkeiten mussen wir untersuchen, was sichbei Regionen andert.

Austrittsmoglichkeiten bei Regionen (graphisch)

A B

C D

Austritt aus einemzusammengesetzten

Zustand

Austritt aus eineminneren Zustand

Austrittuber Vereinigung

105 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beschreibung der Austrittsmoglichkeiten bei Regionen:

Austritt aus einem zusammengesetzten Zustand: dabei wirdder zusammengesetzte Zustand verlassen, egal in welchenUnterzustanden man sich gerade befindet.

Austritt aus einem inneren Zustand: der zusammengesetzteZustand wird nur verlassen, wenn man sich in der jeweiligenRegion in dem Zustand befindet, der durch den Pfeil verlassenwird. In den anderen Regionen kann man sich in beliebigenZustanden befinden.

(Austritt nur, wenn man sich in der ersten Region in Bbefindet.)

106 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beschreibung der Austrittsmoglichkeiten bei Regionen(Fortsetzung):

Austritt uber Vereinigung: ahnlich wie beiAktivitatsdiagrammen wird eine Vereinigung eingesetzt, ummehrere Regionen zusammenzufuhren. Der zusammengesetzteZustand kann nur verlassen werden, wenn man sich in denZustanden befindet, von denen Pfeile in die Vereinigunghineinfuhren.

(Austritt nur, wenn man sich in B und D befindet.)

107 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Wieder zuruck zur Arbanduhr. Es gibt ein weiteres Problem: wennman aus der Alarmeinstellung zuruckkehrt, ist die Zeit auf 0:00zuruckgesetzt!

Losung: Verwendung des Eintritts uber die (flache) Historie.Da man im Fall der Zeitanzeige in zwei Regionen gleichzeitigeintreten muss, verwenden wir eine Gabelung.

108 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

1 . . .

. . .

1 . . .

. . .

on

off

b b

20

22 2123

h h

hhh

Stunden

Minuten

after(1 min) after(1 min)

after(1 min) after(1 min)

2

575859

after(1 min)/h

0

entry/beep

a

Alarma

H

H

H

109 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Weiteres Problem: wenn man langere Zeit im Alarm-Zustandverbringt, so wird in dieser Zeit die Minuten-/Stundenanzeige nichtentsprechend aktualisiert. Das Time Event (after(1 min)) beziehtsich nur auf die Zeit, die seit dem Eintritt in den entsprechendenZustand vergangen ist.

Die Zeitanzeige musste deshalb entsprechend aktualisiert werden.Dieses Problem wird hier nicht gelost.

110 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Was fehlt noch?

Beim Wechseln zwischen den Alarm-Zustanden (on,off) mussein Flag (genannt al) gesetzt werden, um damit den beep-Effekt zukontrollieren.

Dieses Flag muss mit Hilfe einer Bedingung im Minutenzustand 0abgefragt werden.

Außerdem betreten wir den Zustand Alarm nun nicht mehr uberdie flache Historie, sondern fragen mit Hilfe von Bedingungen ab,wie al belegt ist. (Damit ist die Markierung des Anfangszustandseigentlich uberflussig geworden.)

111 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

1 . . .

. . .

. . .

. . .

1

20

22 2123

h h

hhh

Stunden

Minuten

after(1 min) after(1 min)575859

after(1 min)/h

a

Alarm

on

off

b/al=1

entry[al==1]/beepafter(1 min) after(1 min)

0

b/al=0

a[al==1]

a[al==0]

H

H

112 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Wir modellieren, dass die Batterie der Uhr kaputtgehen kann undgewechselt werden muss.

In diesem Fall will man den zusammengesetzten Zustand nichtuber die flache oder tiefe Historie betreten! Es wird also hiertatsachlich die Zeit auf 0:00 zuruckgesetzt.

Außerdem setzen wir das Flag al beim Einsetzen der Batteriezuruck auf den Anfangswert 1.

113 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

1 . . .

. . .

. . .

. . .

1

Uhr

20

22 2123

h h

hhh

Stunden

Minuten

after(1 min) after(1 min)575859

after(1 min)/h

a

Alarm

on

off

b/al=1

entry[al==1]/beepafter(1 min) after(1 min)

0

a[al==1]

a[al==0]

b/al=0 H

H

Batterie kaputt

Batterie geht kaputt Neue Batterie wird eingesetzt/al=1

114 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Ein großer Teil der Modellierungsmoglichkeiten vonZustandsautomaten dient dazu, Zustandsdiagramme kompakt undubersichtlich zu notieren.

Oft kann man Zustandsdiagramme “flachklopfen” undzusammengesetzte Zustande auflosen, wodurch man aquivalenteZustandsdiagramme erhalt, die die gleichen Ubergange erlauben.Dabei erhalt man jedoch im allgemeinen mehr Zustande und/oderTransitionen.

Wir sehen uns einige Beispiele an . . .

115 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beispiel 1: Wandeln Sie folgendes Zustandsdiagramm in ein“flaches” Zustandsdiagramm um:

A

B

C

D

a

b

e

c df

116 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Losung zu Beispiel 1:

A

B

C

D

e

c d

a

b

f

e

Idee: die Transition, die von dem zusammengesetzten Zustandwegfuhrt, durch mehrere Transitionen ersetzen, die von den innerenZustanden ausgehen.

117 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beispiel 2: Wandeln Sie folgendes Zustandsdiagramm in ein“flaches” Zustandsdiagramm um:

A B C D

E F

a b c

e

gG

h

118 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Losung zu Beispiel 2:

b c

g

h

a

b c

e e e

(D,F)(C,F)(B,F)

(B,E) (C,E) (D,E)

G

A

h

Idee: Kreuzprodukt der Zustandsmengen der Regionen bilden.

119 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Beispiel 3: Wandeln Sie folgendes Zustandsdiagramm in ein“flaches” Zustandsdiagramm um:

H

A

B

C

Db

e

c da f

Xx

120 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Losung zu Beispiel 3:

Xx

C

D

c da f a f

A(C)

B(C)

A(D)

B(D)b

e

e

b

Idee: in den außeren Zustanden muss man sich merken, auswelchem Zustand man den zusammengesetzten Zustand verlassenhat. Dies fuhrt zu zusatzlichen Zustanden.

121 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Weitere Elemente von Zustandsdiagrammen:

Unterscheidung zwischen verschiedenen Arten vonEreignissen: call event, signal event, change event, time event,any receive event

Verzogern und Ignorieren von Ereignissen

Entscheidungen und Kreuzungen

Rahmen und Wiederverwendung von Zustandsdiagrammen

Außerdem: Generalisierung und Spezialisierung vonZustandsdiagrammen

122 / 196

Modellierung

UML

Verhaltensdiagramme

Zustandsdiagramme

Zusammenfassung:Nach Harel werden Zustandsdiagramme bzw. deren Eigenschaftendurch folgende “Formel” beschrieben:

UML-Zustandsdiagramme =Zustandsubergangsdiagramme + Tiefe + Orthogonalitat(+ Broadcast-Kommunikation)

Dabei steht “Orthogonalitat” fur die Parallelitat, die durchRegionen erreicht werden kann.

123 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Sequenzdiagramme (sequence diagrams) sind die bekanntestenVertreter von Interaktionsdiagrammen in UML.

Sie dienen dazu, um Kommunikation und Interaktion zwischenmehreren Kommunikationspartnern zu modellieren und beruhenauf dem Basiskonzept der Interaktion:

Interaktion

Eine Interaktion ist das Zusammenspiel von mehrerenKommunikationspartnern.

Typische Beispiele: Versenden von Nachrichten, Datenaustausch,Methodenaufruf

124 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Sequenzdiagramme waren bereits vor Aufnahme in die UML unterdem Namen message sequence charts bekannt.

Im Gegensatz zu Aktivitatsdiagrammen oder Zustandsdiagrammenbeschreiben sie im allgemeinen nicht alle Ablaufe eines Systems,sondern nur einen oder mehrere mogliche Ablaufe.

125 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Sequenzdiagramme beschreiben Interaktionen in zwei Dimensionen:

Von links nach rechts: Anordnung der Kommunikationspartnerals LebenslinienOft wird der Partner, der den Ablauf initiiert ganz linksangegeben.

Von oben nach unten: Zeitachse

126 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Beispiel Restaurant

Petra

:Gast

Robert

:Kellner

Ina

:Kochin

Mustafa

:Kassierer

Menu bringen

bestellenbestellen

Getrank servieren

Essen abholenEssen servieren

bezahlen

127 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Kommunikationspartner

Die Kommunikationspartner in einem Sequenzdiagramm werdenahnlich wie in Objektdiagrammen als Rechtecke notiert.

Manchmal werden die Rechtecke auch weggelassen. MenschlichePartner werden auch durch ein Strichmannchen symbolisiert:

Von jedem Kommunikationspartner fuhrt eine gestrichelteLebenslinie nach unten.

128 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Ausfuhrungsbalken

Aktivitaten eines Kommunikationspartners werden durchsogenannte Ausfuhrungsbalken dargestellt.

Parallele Tatigkeiten eines Kommunikationspartners werden dabeidurch ubereinander liegende Ausfuhrungsbalken beschrieben (sieherechts oben).

Wahrend die Balken aktive Zeit anzeigen, symbolisieren diegestrichelten Linien passive Zeit.

129 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Nachrichten

Die Nachrichten beschreiben die Kommunikationen bzw.Interaktionen der Kommunikationspartner und werden durch Pfeiledargestellt. Eine Nachricht hat einen Sender und einen Empfanger.

Die Stellen, an denen die Pfeile auf den Lebenslinien auftreffen,nennt man auch Sendeereignis und Empfangsereignis.

EmpfangerSender

Name der NachrichtEmpfangs-ereignis

Sende-

ereignis

130 / 196

Modellierung

UML

Verhaltensdiagramme

Fallstudie: Fahrkartenautomat - Klassendiagramm

FA-Controller

+F_Stufe: char

+F_Preis: float

+Einnahme: float

+F_anfordern(Stufe:char)

+Preis_ber(Stufe:char): float

+bezahlt(Einnahme:float)

FA-Display

+Betrag: float

+Text: String

+Betrag_anz(Preis:float)

+Text_anz(Text:string)

FA-Geldannahme

+Einnahme: float

+Annahme_öffnen()

+Annahme schließen()

+Einwurf(Betrag:float)

+Restgeld(Betrag:float)

FA-Drucker

+F-Stufe: char

+F-Preis: float

+F_drucken(S:char,P:float)

131 / 196

Modellierung

UML

Verhaltensdiagramme

Fallstudie: Fahrkartenautomat - Sequenzdiagramm

Kunde

F_anfordernPreis_ber

Betrag_anz

Annahme_öffnen

Einwurf

bezahlt

Betrag_anz

Einwurf

bezahlt

Betrag_anz

Text_anz

Annahme_schließen

Restgeld

F_drucken

C: FA-Controller G: FA_Geldannahme D: FA-DruckerA: FA-Display

132 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Synchrone und asynchrone Nachrichten

Bei synchroner Kommunikation warten Sender und Empfangeraufeinander. Der Sender macht erst dann weiter, wenn er weiß,dass der Empfanger die Nachricht erhalten hat. Sie wird durch eineschwarze ausgefullte Pfeilspitze dargestellt.

133 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Synchrone und asynchrone Nachrichten (Fortsetzung)

Bei asynchroner Kommunikation wartet der Sender nicht darauf,dass der Empfanger die Nachricht erhalten hat. Er arbeitet einfachweiter. Die Nachricht wird durch eine einfache Pfeilspitze wirddargestellt.

Bei asynchronen Nachrichten kann es zu einer Zeitverzogerungzwischen Sende- und Empfangsereignis kommen, die durch einengeneigten Pfeil beschrieben wird (siehe oben rechts).

134 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Bei asynchroner Kommunikation (aber nicht bei synchronerKommunikation) kann auch der Fall eintreten, dass sichNachrichten uberholen oder kreuzen.

Das Uberholen der Nachrichten (oben links) ist nur dann nichtmoglich, wenn man explizit einen FIFO-Kanal fordert.

135 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Was jedoch nicht moglich ist, ist eine Nachricht, die “ruckwarts”in der Zeit lauft und vor dem Senden ankommt.

136 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Es ist jedoch moglich, eine Nachricht an sich selbst zu schicken.

:Gast

Gericht aussuchen

Bei einer synchronen Nachricht sollte man dabei paralleleAusfuhrungsbalken verwenden, da das Sende- undEmpfangsereignis parallel stattfinden mussen.

137 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Nachrichten, die als Antworten auf fruhere Nachrichten gedachtsind, werden durch gestrichelte Pfeile notiert. Dabei sollte derName der ursprunglichen Nachricht wiederholt werden.

Nachfrage

Antwort auf Nachfrage

138 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Wir machen uns nun Gedanken uber die Reihenfolge der Ereignissein einem Sequenzdiagramm. Dazu ist es nutzlich sichklarzumachen, was eine (partielle) Ordnung ist.

Partielle Ordnung

Gegen sei eine Menge X . Eine partielle Ordnung auf X ist eineRelation R ⊆ X × X mit folgenden Eigenschaften:

Reflexivitat: fur jedes x ∈ X gilt (x , x) ∈ R

Transitivitat: aus (x1, x2) ∈ R und (x2, x3) ∈ R furx1, x2, x3 ∈ X folgt (x1, x3) ∈ R.

Antisymmetrie: aus (x1, x2) ∈ R und (x2, x1) ∈ R furx1, x2 ∈ X folgt x1 = x2.

139 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Weitere Bezeichnungen:

Partielle Ordnung bezeichnet man oft mit dem Zeichen ≤ undnotiert in Infix-Schreibweise (x1 ≤ x2 statt (x1, x2) ∈ R).

Wir schreiben x1 < x2, falls x1 ≤ x2 und x1 6= x2.

Vorsicht: Die Relation < ist selbst keine partielle Ordnung.

140 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Totale Ordnung

Eine partielle Ordnung ≤ heißt total, wenn fur zwei beliebigeElemente x1, x2 ∈ X immer x1 ≤ x2 oder x2 ≤ x1 gilt.

Beispiele:

Die ≤-Relation auf den ganzen Zahlen Z ist eine totaleOrdnung.

Ein typisches Beispiel fur eine partielle Ordnung, die nichttotal ist, ist die Inklusionsordnung ⊆ auf Mengen.

141 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Reflexiv-transitive Hulle

Fur eine gegebene Relation R ⊆ E × E beschreiben wir derenreflexiv-transitive Hulle R∗. Man erhalt sie aus R, indem man

alle Paare (e, e) mit e ∈ E zu R hinzufugt und

bei (e1, e2), (e2, e3) ∈ R auch (e1, e3) zu R hinzufugt. DieserProzess wird so lange wiederholt, bis keine neuen Paare mehrhinzukommen.

Die reflexiv-transitiv Hulle R∗ einer Relation R ist immerreflexiv und transitiv. Sie ist jedoch nicht immerantisymmetrisch und daher nicht notwendigerweise eineOrdnung.

Die Relation R∗ ist die kleinste reflexive und transitiveRelation, die R enthalt.

142 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Beispiel:

Die reflexiv-transitive Hulle von

R = {(1, 2), (2, 3), (3, 4), (3, 5)}

ist

R∗ = {(1, 2), (2, 3), (3, 4), (3, 5),

(1, 1), (2, 2), (3, 3), (4, 4), (5, 5),

(1, 3), (1, 4), (1, 5), (2, 4), (2, 5)}

143 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Die Elemente von Sequenzdiagrammen, die nun geordnet werden,sind die Ereignisse, d.h., Sende- und Empfangsereignisse.

In den Sequenzdiagrammen, wie wir sie bisher kennengelernthaben, sind die Ereignisse immer total geordnet, nach folgendemSchema:

(Sendeereignis der Nachricht N) < (Empfangsereignis von N)

Die restlichen Ereignisse sind entsprechend dem zeitlichenVerlauf geordnet.

144 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Petra

:Gast

Robert

:Kellner

Ina

:Kochin

Mustafa

:Kassierer

Menu bringen

bestellenbestellen

Getrank servieren

Essen abholenEssen servieren

bezahlen

R5

P1

P2

P3

P4

P5

R1

R2R3

R4

R6

I1

I2

M1

R1 < P1 < P2 <R2 < R3 < I1 <R4 < P3 < I2 <R5 < R6 < P4 <P5 < M1

145 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

In einem einfachen Sequenzdiagramm (Erweiterungen werden nochbesprochen) werden daher die Ereignisse immer in eine Reihenfolgegebracht. Die Ordnung ist daher total. Im folgenden Diagramm giltbeispielsweise:

A1 < B1 < C1 < D1

A1

A B C D

B1

C1 D1

146 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Nicht so gunstig sind Diagramme, aus denen die Reihenfolge vonNachrichten nicht klar hervorgeht:

A BA1

A B C D

B1 C1 D1

Insbesondere ist die Darstellung echter Parallelitat inSequenzdiagrammen nicht vorgesehen.

147 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Aquivalenz von Sequenzdiagrammen

Zwei Sequenzdiagramme sind aquivalent, wenn sie die gleichenEreignisse enthalten und die Reihenfolge der Ereignisse identischist.

Dabei konnen die Diagramme durchaus verschieden gezeichnet sein(andere Reihenfolge der Kommunikationspartner, verschiedeneAbstande zwischen den Ereignissen, . . . ).

148 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Bisher haben wir gesehen, wie man mit einem Sequenzdiagrammeinen moglichen Ablauf beschreiben kann. In manchen Fallenmochte man jedoch mehrere (vielleicht sogar alle) Ablaufebeschreiben.

Dazu gibt es die Moglichkeit, kombinierte Fragmente zuverwenden, bei denen mehrere (Interaktions-)Operanden (=Teil-Sequenzdiagramme) mit Hilfe von Interaktions-Operatorenzusammengesetzt werden.

Wir betrachten im folgenden einige dieser Interaktions-Operatoren.

149 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Interaktionsoperator par (Parallelitat)

Hier sind die Operanden in beliebiger Reihenfolge ausfuhrbar. DieReihenfolge der Ereignisse in den Operanden muss aber gewahrtwerden, ansonsten gibt es keine Bedingungen.

:X :Y

par

X1 Y1

X2 Y2

X3 Y3

Dabei wird der Operator parlinks oben in der Eckeangegeben.

Eine gestrichelte waagrechteLinie trennt die verschiedenenOperanden.

150 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Nachrichten, die von einem Operanden in einen anderen laufen,sind nicht zugelassen.

:X :Y

par

X1

Y1

151 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Ordnung auf den Ereignissen:

X1 < Y1 < Y2 < X2 (Operand 1)

X3 < Y3 (Operand 2)

Ansonsten gibt es keine weiteren Einschrankungen

Dieses Sequenzdiagramm beschreibt insgesamt funfzehn Ablaufe,beispielsweise:

X1, Y1, X3, Y3, Y2, X2

X3, X1, Y1, Y2, X2, Y3

. . .

152 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Weitere Bemerkungen: um die Ereignis-Ordnung innerhalb einespar-Operators zu bestimmen . . .

verwendet man die partiellen Ordnungen der einzelnenOperanden (≤1, ≤2)

und vereinigt diese. Die Vereinigung ≤1 ∪ ≤2 ist ebenfallseine partielle Ordnung und beschreibt alle moglichenReihenfolgen von Ereignissen.

Jede Ereignisreihenfolge, bei der ein Ereignis X immer vor einemEreignis Y auftritt, falls X<Y gilt, ist eine mogliche Reihenfolge.

153 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Interaktionsoperator seq (schwache Sequenz)

Die Reihenfolge der Ereignisse in den Operanden muss wiedergewahrt werden, außerdem ist die Reihenfolge der Ereignisse aufden Lebenslinien (von oben nach unten) festgelegt.

:X

X1

:Y :Z :W

seq

Y1

Z1 Z2

Y2X2

154 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Ordnung auf den Ereignissen:

X1 < Y1 < Z1 < Z2 (Operand 1)

X2 < Y2 (Operand 2)

X1 < X2 (Lebenslinie von X)

Y1 < Y2 (Lebenslinie von Y)

Dieses Sequenzdiagramm beschreibt neun verschiedene Ablaufe,beispielsweise:

X1, X2, Y1, Z1, Z2, Y2

X1, Y1, X2, Y2, Z1, Z2

. . .

155 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Weitere Bemerkungen: um die Ereignis-Ordnung innerhalb einesseq-Operators zu bestimmen . . .

verwendet man die partiellen Ordnungen der einzelnenOperanden (≤1, ≤2),

außerdem die partiellen Ordnungen der einzelnen Lebenslinien(≤X , ≤Y , . . . ),

vereinigt diese und bestimmt die reflexiv-transitive Hulle.Dabei entsteht eine partielle Ordnung, die alle moglichenReihenfolgen von Ereignissen beschreibt.

156 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Bei Interaktions-Operanden ist es außerdem moglich, zusatzlicheOrdnungsbeziehungen einzufuhre, die ansonsten nicht abgedecktsind. (Durch gestrichelte Linien mit Pfeil in der Mitte.)

:X

X1

:Y :Z :W

Y1

Z1 Z2

Y2

par

X2

Die neue partielle Ordnung kann man hier dadurch bestimmen,indem man die neuen Paare hinzufugt und die reflexiv-transitiveHulle der Gesamtrelation bildet.

157 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Weitere Interaktions-Operatoren (Liste ist nicht vollstandig):

strict (Strikte Sequenz): Die Reihenfolge der Ereignisse wirdvon oben nach unten strikt eingehalten (wie in einemeinzelnen Operanden).

alt (Alternative): entsprechend einer If-Then-Else-Anweisung(mit Bedingungen)

neg (Negation): beschreibt eine ungultigeNachrichtenreihenfolge

loop (Schleife): beschreibt die Wiederholung eines Operanden

158 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Beispiel: wir modellieren ein Protokoll, bei dem einClient-Rechner S einen E-Mail an einen anderen Client Rverschickt.

Weitere Beteiligte sind der Mail-Server von S, der Mail-Servervon R und der DNS-Server, der benotigt wird, um Mail-Adressenin die IP-Adressen des entsprechenden Servers umzuwandeln (DNS= domain name system).

159 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

par Mail ausliefern

Bestatigung Ausliefern

Bestatigung Einliefern

IP-Adresse von E2

Mail einliefern

Frage nach IP-Adresse

Kontaktaufnahme

Verifiziere, ob

:ClientS1

:ServerS2

:DNS :ServerE2

:ClientE1

Name von S2 korrekt

Antwort Verifikation

Bestatigung der Kontaktaufnahme

Verschicken der Mail

Bestatigen der Mail

160 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Bemerkung: dieses Sequenzdiagramm ist an den Ablauf imSMTP-Protokoll angelehnt (SMTP = send mail transportprotocol), ist jedoch erheblich vereinfacht.

Sequenzdiagrammen zu vielen TCP/IP-Netzwerkprotokollen findetman unter:

http://www.eventhelix.com/Realtimemantra/Networking/

161 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Es gibt noch einige weitere Arten von Nachrichten:

Gefundene und verlorene Nachrichten

Bei gefundenen und verlorenen Nachrichten werden das Sende-bzw. das Empfangsereignis nicht explizit modelliert. DieNachrichten tauchen quasi aus der Umgebung auf undverschwinden wieder dorthin.

Solche Nachrichtenwerden benotigt, wenndie entsprechendenKommunikationspart-ner nicht mitmodelliertwerden.

:Fenster

schließen

Gefundene Nachricht

Larm

Ruhe!

Verlorene Nachricht

:Person

162 / 196

Modellierung

UML

Verhaltensdiagramme

Sequenzdiagramme

Erzeugung und Dekonstruktion von Objekten

Außerdem kann es passieren, dass Objekte nicht wahrend desganzen Ablaufs zur Verfugung stehen. Sie konnen wahrend desAblaufs dynamisch erzeugt und wieder zerstort werden.

Dies erfolgt zumeist durchsogenannte Erzeugungs- undDekonstruktionsnachrichtenund wird folgendermaßendargetellt:

:Zentrale

:Filialeeroffnen

Erzeugungsnachricht

Dekonstruktionsnachricht

schließen

163 / 196

Modellierung

UML

Verhaltensdiagramme

Kommunikationsdiagramme

Kommunikationsdiagramme enthalten dieselbe Information wieSequenzdiagramme, werden jedoch anders dargestellt.

Wahrend bei Sequenzdiagrammen der Fokus eher auf demzeitlichen Ablauf liegt, heben Kommunikationsdiagramme eher dieKommunikationsbeziehungen der Teilnehmer hervor.

Kommunikationsdiagramme gehoren – genau wieSequenzdiagramme – zur Klasse der Interaktionsdiagramme.

164 / 196

Modellierung

UML

Verhaltensdiagramme

Kommunikationsdiagramme

Das Sequenzdiagramm Restaurantbesuch Diagramm wirdfolgendermaßen als Kommunikationsdiagramm dargestellt:

Robert

:Kellner

Ina

:Kochin

3: bestellen

5: Essen abholen

Petra

:Gast

Mustafa

:Kassierer

7: bezahlen

1: Menu bringen

2: bestellen

4: Getrank servieren

6: Essen servieren

165 / 196

Modellierung

UML

Verhaltensdiagramme

Kommunikationsdiagramme

Dabei werden die Kommunikationspartner wie bisher durchRechtecke oder Strichmannchen dargestellt. Es wird jedoch keinzeitlicher Ablauf mehr dargestellt.

Die Interaktionen bzw. Nachrichten werden durch Linien notiert,an denen die Namen der Nachrichten und die Senderichtung (→)stehen.

Die Nummerierung der Nachrichten (1,2,3,. . . ) gibt dieReihenfolge an. Durch Buchstaben hinter den Nummern(2a,2b,. . . ) beschreibt man parallele Nachrichten, die in beliebigerReihenfolge angeordnet sein konnen.

166 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Uberblick uber weitere UML-Diagramme

Wir schließen die Vorlesung mit einem kurzen Uberblick uber dienoch fehlenden Typen von UML-Diagrammen ab.

Zuletzt gibt es dann noch ein paar Abschlussbemerkungen.

167 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Uberblick uber weitere UML-Diagramme

UML-Diagramme Liste

Verhaltens-diagramme

Interaktions-

diagramme

Objekt-

diagramm

Kompositions-

strukturdiagramm

diagrammeStruktur-

Klassen-

diagramm

Komponenten-

diagramm

Verteilungs-

diagramm

Paket-

diagramm

Diagrammeder UML

diagramm diagramm

diagramm

Aktivitats- Anwendungsfall-

Zustands-

diagrammdiagramm

Interaktionsuber-

sichtsdiagramm

Zeitverlaufs-/

Timing-Diagramm

Kommunikations-Sequenz-

168 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Uberblick uber weitere UML-Diagramme

UML-Diagramme (blau: bereits behandelte Diagramme)

Objekt-

diagramm

Verhaltens-diagramme

Interaktions-

diagrammeKompositions-

strukturdiagramm

Struktur-

Klassen-

diagramm

Komponenten-

diagramm

Verteilungs-

diagramm

Paket-

diagramm

Diagrammeder UML

diagramm diagramm

diagramm

Aktivitats- Anwendungsfall-

Zustands-

diagrammdiagramm

Interaktionsuber-

sichtsdiagramm

Zeitverlaufs-/

Timing-Diagramm

Kommunikations-Sequenz-

diagramme

169 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Uberblick uber weitere UML-Diagramme

Wir beginnen zunachst mit den beiden noch fehlenden Arten vonInteraktionsdiagrammen:

Timing-Diagramme bzw. Zeitverlaufsdiagramme

Interaktionsubersichtsdiagramme

170 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Timing-Diagramme

Timing-Diagramme sind in der Elektrotechnik weit verbreitet undzeigen an, zu welchem Zeitpunkt welcher Kommunikationspartnerwelchen Zustand einnimmt.

Dabei wird von links nach rechts (horizontal) die Zeit aufgetragenund von oben nach unten werden die Kommunikationspartner undderen Zustande aufgetragen.

171 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Timing-Diagramme

Beispiel: Ampelschaltung

gruen

rot

Sekunden0 10 20 30

gruen

gelbrot

gelb

rot:Aut

oam

pel

:Fus

sgae

nger

amp

el

172 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Interaktionsubersichtsdiagramme

Interaktionsubersichtsdiagramme sind im wesentlichenAktivitatsdiagramme, die – anstatt der Aktionen – hierarchischweitere Interaktionsdiagramme (Sequenzdiagramme,Kommunikationsdiagramme, Timing-Diagramme) enthaltenkonnen.

Sie werden eingesetzt, wenn es eine großere Menge verschiedenerArten von Aktionen gibt, uber die man sonst nur schwer denUberblick behalten kann.

Als Beispiel betrachten wir ein Interaktionsubersichtsdiagramm,das den Ablauf eines Freistoßes in einem Fussballspiel modelliert.

173 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Interaktionsubersichtsdiagramme

ref

:Torwart

sd Linkssprung

nach links

springen

positionieren

sd Fussball positionieren

:Fussball

[ruhend]

0 1 2 3sec

fliegend

ruhend

positionierenMauer

:Schuetze

Freistossfreigeben

0..3 sec

schiessendlaufendstehend

sd Freistoss ausfuehren

ref

springen

sd Rechtssprung

nach rechts

sd Stehenbleiben

stehen

bleiben

[Fussball gerade]

[Fussball nach rechts][Fussball nach links]

:Fussball

sd Fussball fangen

:Torwart[fliegend]

fangen

:Torwart :Torwart

:Fus

sbal

l:S

chue

tze

174 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Interaktionsubersichtsdiagramme

Bemerkungen:

Interaktionsreferenzen (Schlusselwort ref) werden verwendet,um an anderer Stelle definierte Interaktionsdiagrammewiederzuverwenden.

Anstatt der Aktionen wie in Aktivitatsdiagrammen werdenganze Interaktionsdiagramme verwendet, die alle sd alsDiagrammtyp fur Interaktionsdiagramme erhalten.

175 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Anwendungsfalldiagramme

In fruhen Stadien der Entwicklung und bei der Kommunikation mitdem Auftraggeber spielen auch Anwendungsfalldiagramme (engl.use case diagrams) eine grosse Rolle.

Anwendungsfalldiagramme modellieren die Funktionalitat desSystems

auf einem hohen Abstraktionsniveau;

aus der Black-Box-Sicht des Anwenders (d.h., nur das vonaußen Sichtbare soll beschrieben werden, nicht die interneRealisierung);

durch Spezifikation der Schnittstellen.

Die Anwender bzw. Nutzer tauchen als sogenannte Akteure in denDiagrammen auf.

176 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Anwendungsfalldiagramme

Beispiel: Restaurant

Gericht bestellen

Gast

Gericht verspeisen

Rechnung bezahlen

Mit Kreditkartebezahlen

Kreditkarte prufen�include�

1

1

1..*

1..*

Kellner

Restaurant

Kreditkarten-

gesellschaft

�actor�

177 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Anwendungsfalldiagramme

Anwendungsfalldiagramme bestehen aus folgenden Komponenten:

Systemgrenze

Die Systemgrenze ist ein Rechteck, das beschreibt, was sichaußerhalb und innerhalb des zu erstellenden Systems befindet.

Restaurant

178 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Anwendungsfalldiagramme

Akteur

Ein Akteur ist ein Typ oder eine Rolle, die ein externer Benutzeroder ein externes System wahrend der Interaktion mit dem Systemeinnimmt. Menschliche Akteur werden durch Strichmannchensymbolisiert, andere Akteure durch ein Rechteck, das mit demSchlusselwort �actor� gekennzeichnet ist

Gast

Kreditkarten-

gesellschaft

�actor�

179 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Anwendungsfalldiagramme

Anwendungsfall

Ein Anwendungsfall ist eine Menge von Aktionen, die von demSystem bereitgestellt werden und die einen Nutzen fur einen odermehrere Akteure bringen. (D.h., es handelt sich dabei um eine Art“Service” des Systems.) Ein Anwendungsfall wird durch eineEllipse dargestellt.

Mit Kreditkartebezahlen

180 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Anwendungsfalldiagramme

Assoziation

Wie bei Klassendiagrammen gibt es Assoziationen, vor allemzwischen Akteuren und Anwendungsfallen (welcher Akteur kannwelchen Anwendungsfall nutzen?).Assoziationen durfen die ublichen Beschriftungen besitzen(Multiplizitaten, etc.).

Gericht bestellen

Restaurant

1 1..*

Gast

181 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Anwendungsfalldiagramme

Generalisierung/Spezialisierung

Anwendungsfalle konnen andere Anwendungsfalle spezialisieren,d.h., sie konnen von ihnen erben. Dabei werden – wie bei Klassen –auch alle Assoziationen geerbt.

Mit Kreditkartebezahlen

Rechnung bezahlen

Auch Spezialisierungsbeziehungen zwischen Akteuren sind moglich.

182 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Anwendungsfalldiagramme

Include-Beziehung

Bei einer Include-Beziehung wird modelliert, dass einAnwendungsfall die Funktionalitat eines anderen Anwendungsfallesauf jeden Fall nutzt. D.h., der zweite Anwendungsfall wird immerals eine Art “Unterprozedur” aufgerufen.

Mit Kreditkartebezahlen

Kreditkarte prufen�include�

Es gibt auch sogenannte Extend-Beziehungen, bei denen einAnwendungsfall nur unter bestimmten Bedingungen in einenanderen Anwendungsfall eingebunden wird.

183 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Anwendungsfalldiagramme

Bemerkungen:

Anwendungsfalldiagramme sollten nicht zu viele Detailsenthalten.

Sie sind ein einfaches Mittel, um Anwenderwunsche zudiskutieren und sollten nur eine grobe Sicht auf dieFunktionalitat des Systems darstellen.

Bei Bedarf mussen bestimmte Anwendungsfalle dann nochtextuell oder mit Hilfe anderer UML-Diagramme genauerbeschrieben werden.

184 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Strukturierte, textuelle Beschreibung einesAnwendungsfalls

Af.-Nr. Name des Anwendungsfalles

Vorbedingungen:

Nachbedingungen:

Nicht-funktionale Anforderungen:

Beschreibung: ..

Variationen:

Regeln:

Services:

Ansprechpartner:

Anmerkungen / offene Fragen:

Dialogbeispiele oder - muster:

Diagramme:

185 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Beispiel: Formular zur Beschreibung einesAnwendungsfalls

186 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Formular zur Beschreibung eines Anwendungsfalls (2)

187 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Uberblick uber weitere UML-Diagramme

Wir sehen uns nun noch (ganz kurz) die fehlenden vier Typen vonStrukturdiagrammen an. UML-Ubersicht

Kompositionsstrukturdiagramme

Paketdiagramme

Verteilungsdiagramme

Komponentendiagramme

Im weitesten Sinne dienen sie alle dazu die (ubergeordnete)Struktur bzw. Architektur eines Systems darzustellen.

188 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Kompositionsstrukturdiagramme

Kompositionsstrukturdiagramme (engl. composite structurediagrams) beschreiben die interne Struktur von Komponenten(z.B. Klassen) in einer White-Box-Darstellung. Instanzen von durchKomposition verbundenen Klassen werden dabei als sogenannteParts innerhalb der Klasse dargestellt.

:Fernsehgeraet

Antenneneingang

Antennenkabel

SatAusgang

:SatReceiver

SatKabel

:SatAntenne

SatEmpfangsAnlage

Part

Part

189 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Paketdiagramme

Ein großes Softwaresystem muss in Pakete bzw. Module gegliedertwerden. Paketdiagramme (engl. package diagrams) beschreiben diestatische Struktur eines großen Systems durch Zusammenfassenvon Klassen in Paketen.

Kunde

kundenverwaltung personalverwaltung

Angestellter

kontenverwaltung

Konto

Girokonto Sparkonto

bank

190 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Verteilungsdiagramme

Verteilungsdiagramme (engl. deployment diagrams) beschreibendie Hardware-Komponenten, die in einem System benutzt werdenund wie diese in Beziehung stehen.

Sie konnen auch konkrete physische Informationseinheiten(Dateien, etc.) enthalten, die als Artefakte bezeichnet werden.

:PC0..50

:Laptop0..10

:PC0..50Host �LAN�

�Internet�

�WLAN�

1

:Mehrprozessorsystem

1

1:DBClient

�deploy�

�deploy�

�deploy� �artifact�

191 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Komponentendiagramme

Komponentendiagramme (engl. component diagrams) beschreibenim Gegensatz dazu die Software-Architektur eines Systems. Esbeantwortet die Frage, wie Klassen zur Laufzeit zu großerenKomponenten zusammengefasst werden und welche Schnittstellenangeboten und genutzt werden.

�component�

MailEingang

�component�

MailAusgang

�component�

MailManagement

Betrieb

uberwachen

Mail

abholen

�use�

192 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

UML-Vorgehensweise

a) Von den Anforderungen zu Klassendiagrammen

und dann uber Anwendungsfalldiagrammen zuInteraktionsdiagrammen zu Zustandsdiagrammenparallel Ubergang zu OO-Design mit Hilfe vonKomponentendiagrammenAktivitatsdiagramme nahezu beliebig zurAblaufveranschaulichung

b) Von den Anforderungen zu Use Case-Diagrammen

und dann Aktivitatsdiagrammen zur Detailbeschreibung vonAnwendungsfallenund dann uber Klassendiagramme zu Interaktionsdiagrammenund dann zu Zustandsdiagrammenparallel Ubergang zum OO-Design mit Hilfe vonKomponentendiagrammen

Beide Ansatze nur als grobe Richtlinien, nicht als Dogmen!

193 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Abschließende Bemerkungen

UML als semi-formale Modellierungsmethode

UML ist eine semi-formale Modellierungsmethode, d.h., nicht beijedem Sprachelement gibt es vollstandige Einigkeit uber dieBedeutung.

Trotz dieser Kritik ist die UML ein großer Fortschritt, da sievereinheitlichte Diagramme bereitstellt, die von jedem Beteiligtenam Softwareentwicklungsprozess verstanden werden konnen.

194 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Abschließende Bemerkungen

Konsistenz von Modellen

Bei der Beschreibung eines großen Systems durch mehrere Modelleist auch darauf zu achten, dass die Modelle untereinanderkonsistent sind. (Beispielsweise: Klassennamen, die in einemSequenzdiagramm verwendet werden, tauchen auch imKlassendiagramm auf.)

Es gibt Ansatze, solche Konsistenz (halb-automatisch) zuerreichen, indem man sogenannte Modelltransformationendurchfuhrt und verschiedene Diagramme ineinander ubersetzt.

195 / 196

Modellierung

UML

Uberblick uber weitere UML-Diagramme

Abschließende Bemerkungen

Es gibt noch viele Aspekte in der UML, die wir nicht betrachtethaben. Ein wichtiger Teil der UML ist beispielsweise die OCL(Object Constraint Language), eine formale Beschreibungssprache,in der man zusatzliche Bedingungen und Invarianten ausdruckenkann.

Weitergehende Informationen uber UML gibt es in zahllosenBuchern (siehe Literaturliste) und auf den Seiten der OMG (ObjectManagement Group):

http://www.omg.org/technology/documents/formal/uml.htm

Und naturlich gibt es neben UML und Petri-Netzen nochzahlreiche andere Modellierungsmethoden!

196 / 196