Kapitel 3 Die Unified Modeling Language (UML) · UML-Diagramm Vhlt di UseCase-Diagramm...

Vorlesung „Softwaretechnologie“Wintersemester 2008 R O O T Ste se este 008

Kapitel 3

Die Unified Modeling Language (UML)

3.1 Modellierung und UML Übersicht3.2 Kurzüberblick wichtiger Notationen im Zusammenhang

3.3 Strukturdiagramme im Kleinen: Klassen, Objekte, Pakete3.4 Verhaltensmodellierung: Zustands- und Aktivitätsdiagramme

3.5 Verhaltensmodellierung: Sequenz-, Kommunikations- und Interaktionsübersichtsdiagramme

Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U

3 1 Modellierung und 3.1 Modellierung und Unified Modelling Language Übersicht

AusgangspunktWarum Modellierung?

Warum objektorientierte Modellierung?Warum mit der UML?

UML-Überblick

Problemstellung

Ausgangssituation: Sie …k 2 3 P i hkennen 2-3 Programmiersprachenhaben bisher allein oder in sehr kleinen Gruppen (<5) gearbeitet

Neue Herausforderungen: Sie sollen … mit Kollegen zusammenarbeiten, die andere Programmiersprachen nutzen

fmit Kunden kommunizieren, die nichts von Informatik verstehenkomplexe, evt. verteilte Systeme realisieren, mit einer Vielzahl von Klassen, Subsystemen, verschiedensten Technologien, …Entwürfe auf einer höheren Abstraktionsebene als Quellcode kommunizieren und dokumentierenauch die Software-Verteilung, -Einführung und den Betrieb planenauch die Software Verteilung, Einführung und den Betrieb planen

Lösungsweg: Abstraktion des zu realisierenden Systems

© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-3 R O O T S

Erst modellieren, dann programmieren!

Systeme, Modelle, und Sichten

Ein Modell ist eine Abstraktion, welche ein System oder einen Teil davon beschreibtdavon beschreibtEine Sicht stellt ausgewählte Aspekte eines Modells dar.Modelle eines Systems können sich überschneiden. Sichten auch.

„Flugzeug“-System

Modelle eines Systems können sich überschneiden. Sichten auch.

Flugsimulator-ModellSystem

Sk l tt d ll

Flugsimulator Modell

Elektr. VerkabelungSicht

TanksystemSicht

SkelettmodellNavigationssystem

Sicht

Eine Notation ist ein Satz von Regeln (grafisch oder textuell) zur


g (g )Darstellung von Sichten

Systeme, Modelle, und Sichten (UML)

Dies ist eine statische Sicht eines Modells von

Systemen Modellen und Sichten

Sie ist in der „UML“-Notation beschrieben

Sicht**

dargestelltd h

beschrieben d h

System Modell

Systemen, Modellen und Sichten

durchdurch

... und dies ist ihre Instanz für Sie ist ebenfalls in der „UML“-

Flugzeug:System

das vorige Beispiel. Notation beschrieben

Flugsimulator:ModellSkelettmodell:Modell

g g y

g

Blaupausen:Sicht Tanksystem:Sicht Elektr Verkabelung:Sicht


p y g

Warum Software modellieren?

Software ist schon eine Abstraktion, also warum noch modellieren?

Software wird umfangreicher, nicht kleinerWindows NT 5 0 ~ 40 Millionen Zeilen CodeWindows NT 5.0 40 Millionen Zeilen CodeKein Programmierer kann diese Menge Code alleine bewältigen.

Code ist oft von Entwicklern, die an der Entwicklung nicht mitgewirkt haben, nicht direkt zu verstehen

Wir brauchen einfachere Repräsentationen für komplexe SystemeModellierung ist ein Mittel um mit Komplexität umzugehen


Objektorientierte Modellierung

Ding: Ein Element einer Anwendungsdomäne wie man es wahrnimmt, zum Beispiel:zum Beispiel:

Das Dokument, das Du liestMeine schwarze Uhr

Konzept: Fasst eine Menge von Dingen zusammen durch die Beschreibung ihrer gemeinsamen Eigenschaften, zum Beispiel:

Dokumente über Software EngineeringSchwarze Uhren

Ein Konzept ist ein 3-Tupel: Sein Name unterscheidet es von anderen Konzepten.S i I i i d di Ei h f di b i b i Di ISeine Intention sind die Eigenschaften, die bestimmen, ob ein Ding Instanz des Konzeptes ist.Seine Instanzen sind diejenigen Dinge, welche der Intention entsprechen.


Konzepte & Instanzen

Instanzen (Dinge)Name Intention

Uhr Ein Gerät, dasZeit misst.

Abstraktion: Klassifikation von Dingen in Konzepte anhand bestimmter EigenschaftenModellierung: Entwicklung von Abstraktionen, um bestimmte Fragen über einen Satz von Dingen unter Weglassung unwichtiger Details zu beantworten.


Konzepte & Instanzen Typen & Objekte

Instanzen (Dinge)Name Intention

Uhr Ein Gerät, dasZeit misst.

Instanzen (Objekte)Typen (Schnittstellen und Klassen)

Uhr meineSanduhr : Uhr

Instanzen (Objekte)Typen (Schnittstellen und Klassen)

zeit

datumsetzeDatum()

jansWecker : Uhr

gabisHandy : Uhr


gabisHandy : Uhr

Konzepte & Instanzen Typen & Objekte

TypEi Ab t kti i K t t P i hEin Abstraktion im Kontext von ProgrammiersprachenDer Typ einer Variable repräsentiert alle ihre möglichen Werte

InstanzElement eines bestimmten Typs

“ ODie Beziehung zwischen “Typ” und „Objekt das Instanz” des Typs ist, ist die gleiche wie zwischen “Konzept” und “Ding das Instanz” des Konzepts ist.

BeispielName: intName: intIntention: ganze ZahlenElemente: 0, -1, 1, 2, -2,...


Verwendung Objektorientierter ModellierungModellierungAnwendungsdomäne (Anforderungsanalyse):

Die Arbeitsumgebung des Systems

Lösungsdomäne (Design):

Di B fü b T h l iDie Arbeitsumgebung des Systems Die zum Bau verfügbaren Technologien

Modell der Anwendungsdomäne SystemmodellUML-Paket

Kontrolleur

KartendisplayÜbersichtsdisplayVerkehrskontrolle

Flugzeug Kontrolleur

Flugplan Flughafen

Flugplandatenbank

Verkehrskontrolle


Probleme im traditionellen SW-Prozess

Workflow Dokumente

A l Pfli ht h ft (T t)

Übersicht?Abbildbarkeit?Analyse: Pflichtenheft (Text) Abbildbarkeit?

Nachvollziehbarkeit?

Entwurf: Flussdiagramme, ...

Implementierung: Programmcodep g g

Test: Programmcode


Unified Modeling Language (UML)

Standardisierte graphische Notation für alle Aktivitäten der SoftwareentwicklungSoftwareentwicklung

Nutzen für Anforderungserhebung, Entwurf, Implementierung, Einsatz („deployment“), …Besondere Unterstützung für objektorientierte Modellierungeso de e U e s ü u g ü obje o e e e ode e u gStandardisiert durch die OMG (Object Management Group) www.omg.org

Bietet zahlreiche Diagrammtypen für verschiedene Sichten von SoftwareBietet zahlreiche Diagrammtypen für verschiedene Sichten von Softwarestatische Sicht auf die Strukturdynamische Sicht auf das Verhalten

Mittlerweile breite Werkzeugunterstützung für…… die Erstellung von UML Diagrammen… Code-Generierung aus Diagrammen (Forward Engineering)… Diagramm-Generierung aus Code (Reverse Engeneering)… nahtlose Synchronisation von Diagrammen und Code (Round-Trip E i i )


Engineering)

Nutzen der UML

Kommunikation mit AnwendernW i f lWenig formalEinfache graphische NotationKonzentration auf das Wesentliche

Kommunikation mit KollegenAustausch von Designs, ...Abstraktion von SprachdetailsSchutz vor übereilter ImplementationssichtSchutz vor übereilter Implementationssicht

Bandbreiteunterstützt alltägliche und exotische Konzeptemanuell, rechner-unterstützt und kombiniert einsetzbar


Bezug von UML zu gängigen OO Sprachen

C++C++

UML

sprachspezifische Details

Konzepte ohne direkter Entsprechung in

direkt ineinander abbildbarer


p ggängigen Sprachen gemeinsamer Kern

UML: Geschichte und Literatur

Entstanden aus der Zusammenführung dreier führender objekt-orientierten Methodologienorientierten Methodologien

OMT (James Rumbaugh) – Klassendiagramme, Sequenzdiagramme, …OOSE (Ivar Jacobson) – Anwendungsfalldiagramme, …Booch (Grady Booch) – Software-Prozess „Unified Process“

Literatur: StandardwerkeLiteratur: Standardwerke“The Unified Modeling Language User Guide” (Booch & al 1999) “The Unified Modeling Language Reference Manual” (Rumbaugh & al 1999)alle im Addison Wesley / Pearsons Verlag)

EmpfehlungEmpfehlung“UML Distilled” (Fowler & al. 2000, Addison Wesley) – kurz und gut!„UML@Work“ (Hitz & Kappel 2005, dpunkt) – UML 2.0, deutsch,

füh li h!


ausführlich!

UML Versionen

UML 1 (1997) / UML 1.1 (1998)OMG S ifik ti i M d lli t d dOMG-Spezifikation eines Modellierungsstandards

OMG (Object Management Group): Verband führender Softwareunternehmen und Standardisierungsgremium für objektorientierte Systementwicklung

UML 2 (2005)Neue DiagrammtypenNeue Diagrammtypen

Sollen den Anforderungen heutiger Softwarearchitekturen gerecht werden– Komponenten- und Serviceorientierte (SOA) Architekturen,

Geschäftsprozessmanagement, Echtzeitsysteme, …Geschäftsprozessmanagement, Echtzeitsysteme, …Modifikationen bestehender Diagrammtypen

Konvergenz der Diagrammtypen, vor allem der dynamischen DiagrammeGrundidee: Modell Driven Software Engineering (MDSE)Grundidee: Modell-Driven Software Engineering (MDSE)

Quellcode als Hauptartefakt ablösen und ……durch Modelle ersetzen, aus denen die Programme generiert werdenM d ll f i G i P i


Modelltransformationen, Generative Programmierung

UML in dieser Vorlesung

Hauptsächlich UML 2, mit Hinweisen auf UML 1.4I d P i i d h hä fi di UML 1 4 N t ti d tIn der Praxis wird noch häufig die UML 1.4 Notation verwendetManche Werkzeuge unterstützen UML 2 noch nicht vollständig

Together unterstützt UML 2 und UML 1.4 vollständig!vorbildliches Round-Trip Engineering


UML Diagrammtypen

Dies ist ein Klassendiagramm! Klassendiagramm

ObjektdiagrammObjektdiagramm

Paketdiagramm

KomponentendiagrammStrukturdiagramm

Kompositions-strukturdiagramm

VerteilungsdiagrammUML-Diagramm

V h lt di

UseCase-Diagramm

Aktivitätsdiagramm

Z t d di

konkrete Klasse

Verhaltensdiagramm Zustandsdiagramm

Interaktionsdiagrammabstrakte Klasse(kursiv) Vererbungs-

Sequenzdiagramm

Kommunikations-diagramm

( u s ) Vererbungs-beziehung

Zeitverlaufsdiagramm

Interaktions-übersichtsdiagramm

UML Diagrammtypen: Versionszuordnung

Klassendiagramm

ObjektdiagrammObjektdiagramm

Paketdiagramm




V h lt di

UseCase-Diagramm

Aktivitätsdiagramm

Z t d diVerhaltensdiagramm Zustandsdiagramm

Interaktionsdiagramm

Sequenzdiagramm

Kommunikations-diagramm

Neu in UML 2

Stark verändert in UML 2 Zeitverlaufsdiagramm


UML Diagrammtypen: Was wird wo erläutert? erläutert?

Klassendiagramm

Objektdiagramm

Klassendiagramm++

Objektdiagramm

Paketdiagramm




V h lt di

UseCase-Diagramm

Aktivitätsdiagramm

Z t d diVerhaltensdiagramm Zustandsdiagramm


Sequenzdiagramm

Kommunikations-diagrammIn diesem Kapitel



Im Kapitel „Objektentwurf“

Im Kapitel „Anforderungserhebung und Anforderungsanalyse“

Im Kapitel „Systementwurf“


3 2 Beispiel: Modellierung einer Uhr3.2 Beispiel: Modellierung einer UhrKurzüberblick elementarer UML-Notationen

Use-Case DiagrammeKlassendiagrammegSequenzdiagrammeZustandsdiagramme

Beispiel: Eine einfache LCD-Uhr

Struktur Verhalten1 Display2 Knöpfe

Knopf 1 drücken startet Stunden-Einstellung

1 Batterie…

Jeder weitere Druck schaltet weiter zu Minuten, Sekunden StundenSekunden, Stunden, ….

Knopf 2 drücken erhöht den Wert des aktuell einzustellenden Elementes.

Beide Knöpfe drücken beendet die Einstellungbeendet die Einstellung

UML-Kurzübersicht: Use-Case Diagramme

Anwendungsfall( Use Case‘)System (‚Use Case‘)y

LeseZeitAkteur

Uhrenträger UhrmacherSetzeZeit

TauscheBatterie

Use-Case Diagramme stellen die Funktionalität eines Use Case ag a e ste e d e u t o a tät e esSystems aus Sicht der Benutzer dar.

UML-Kurzübersicht: Klassen-Diagramme

Klasse

1 1 11

EinfacheUhr AssoziationMultiplizität

Batterie2

ZeitKnopf1 21

status

LCDDisplaytick Stunde

drücke()

lasseLos()

blinkeSekunden()blinkeMinuten()blinkeStunden()

MinutenSekunden

Attribute

lade()

erhöheStunden()()stoppeBlinken()refresh()

Attribute

Operationen

erhöheMinuten()erhöheSekunden()start()jetzt() p

Klassendiagramme repräsentieren die Struktur eines Systems

jetzt()


UML-Kurzübersicht: Sequenz-Diagramme

Objektsd Watch

bli k St d ()drückeKnopf1()

:Uhrenträger:Zeit:LCDDisplay:EinfacheUhr

blinkeStunden()

blinkeMinuten()

erhöheMin ten()

p ()

drückeKnopf2()

drückeKnopf1()

erhöheMinuten()

refresh()

starteAbNeuerZeit()

drückeKnopf2()

drückeBeideK()

Nachricht

stoppeBlinken()

Aktivierung

Sequenzdiagramme stellen die Interaktion von Objekten dar.

Nachricht Aktivierung


q g jHier: Einstellen der Zeit an einer LCD-Uhr.

UML-Kurzübersicht: Zustands-Diagramme

ZustandA f t d

knopf1&2Gedrückt knopf2Gedrückt ErhöheStunden

BlinkeStunden

Anfangszustand

Event

knopf1Gedrückt

k f2G d ü ktknopf1&2Gedrückt knopf2Gedrückt

knopf1Gedrückt

knopf1&2Gedrückt ErhöheMinuten

BlinkeMinutenTransition

knopf2Gedrückt

knopf1Gedrückt

BlinkeSekunden

ErhöheSekunden

StoppeBlinken

Zustandsdiagramme stellen die interne Sicht von Objekten dar:

knopf1&2GedrücktEndzustand


g jZustände und Zustandsübergänge endlicher Automat.

UML Notationskonventionen

Diagramme sind GraphenK t i d K tKnoten sind KonzepteKanten sind Beziehungen zwischen Konzepten

Rechtecke sind Typen oder Instanzen

Instanzen werden durch „Rolle : Typ“ und Unterstreichung gekennzeichnet

meineUhr:EinfacheUhrmeineUhr:EinfacheUhr

Joe:Feuerwehrmann

Bei Typen werden die Namen nicht unterstrichenEinfacheUhr

FeuerwehrmannFeuerwehrmann


3.3 Strukturdiagramme „im Kleinen“

KlassendiagrammeObjektdiagrammePaketdiagramme

Strukturdiagramme „im Kleinen“

Beschreiben die kleinsten in der objektorientierten Modellierung erfassten Teile eines EntwurfesTeile eines Entwurfes

Klassendie am häufigsten verwendete Struktur-Abstraktiong

Einzelne Objektezur Verdeutlichung von Objektbeziehungen, die sich auf Klassenebene nicht ausreichend beschreiben lassennicht ausreichend beschreiben lassen

PaketeGruppen von Klassen, die thematisch zusammengehörenpp , g… allerdings nicht unbedingt zur Laufzeit gemeinsam auftreten

Di t di di St kt i G ß “ b h ib d iDiagrammtypen, die die Struktur „im Großen“ beschreiben, werden im Kapitel „Systemeentwurf“ behandelt

Sie beschreiben Einheiten, die für die modulare Komposition, die


pVerteilung und die Laufzeit von Software Bedeutung haben

UML-Kurzübersicht: Klassen-Diagramme

Klasse

1 1 11

EinfacheUhr AssoziationMultiplizität

Batterie2

ZeitKnopf1 21

status

LCDDisplaytick Stunde

drücke()

lasseLos()

blinkeSekunden()blinkeMinuten()blinkeStunden()

MinutenSekunden

Attribute

lade()

erhöheStunden()()stoppeBlinken()refresh()

Attribute

Operationen

erhöheMinuten()erhöheSekunden()start()jetzt() p


jetzt()



Klassendiagramm: Elemente

Tarif

Z 2P i T blName

Att ib tZone2Price : Table getZones() : EnumerationgetPrice(Zone) : Price

Attribute

OperationenSignatur

Eine Klasse repräsentiert ein Konzept.Eine Klasse kapselt Zustand (Attribute) und Verhalten (Operationen).p ( ) ( p )Jedes Attribut hat einen Typ.Jede Operation hat eine Signatur.Der Klassenname ist die einzige unverzichtbare Information

Hinzufügen weiterer Information beim Fortschreiten des ModellierungsprozessesEs ist möglich, unwichtige Details in einer teilweisen Sicht des Modells zu

t k


verstecken

Klassendiagramm: Verschiedene Sichten

Window{ status=tested }

DetaillierungsgradI l ti

Fließender Übergang

Window

+ default-size: Rectangle+ size: Area = (100,100)# visibility: Boolean

i XWi d

ImplementierungAnalyse / Design„eingeklappt“

size: Areavisibility: Booleandisplay()

Wi d

- xwin: XWindow

+ display()+ hide()+ create()

g pp

hide()Window + create()

Sichtbarkeit (Implementierungs-Ansicht)blipublic: +

protected: #private: –p

Weitere NotationenKlassenvariable / -methode: unterstrichen


abstrakte Klasse / Methode: kursiv

Klassendiagramm: Abstrakte Klassen und InterfacesAbstrakte Klassen und Interfaces

Abstrakte Klassen InterfacesDefiniton

Implementierung unvollständig Definition

Ganz abstrakter TypEnthalten abstrakte Methoden

NotationKursivschrift für Namen

Keine Attribute und keine Methodenimplementierungen

Notationabstrakter Typen und MethodenAlternativ: Constraint {abstract} in geschweiften Klammern

Notationwie Abstrakte Klasseevtl. zusätzlich Angabe des St t i t fÄquivalente Beispiele Stereotyps <<interface>>

Beispiel

FlugobjektFlugzeug Flugzeug{ abstract } Flugobjekt

<<interface>>starten()fliegen(Ziel)

g g

tankstarten()beladen()

{ abstract }

starten()beladen()

tank


ege ( e )landen()beladen()

tanken()beladen()tanken()

Stereotypen: Definition spezieller semantischer Kategoriensemantischer Kategorien

Bisher nur Notationen für eine feste Menge von KonzeptenDi W lt i t b dli hDie Welt ist aber unendlich…

StereotypHinweis auf semantische Kategorie für die es keine spezifische NotationHinweis auf semantische Kategorie für die es keine spezifische Notation gibtAnsatzpunkt für anwendungsspezifische Erweiterungen

AnwendbarkeitAnwendbarkeitAllgemein (Klassen, Variablen, Operationen, Beziehungen, ...)

Notation“<<stereotyp>>“oder graphisches Symbol, z.B.

<<entity>>

<<controller>>

<<boundary>>

<<interface>>


<<interface>>

<<selbst definierte Kategorie>>

Stereotypen: Beispiele

Klasse mit Stereotypen <<entity>>

Rechteckp1 : Punktp2 : Punkt

Rechteckp1 : Punktp2 : Punkt

<<query>>fläche():Real

<<update>>

<<query>>fläche():Real

<<update>>bewege(delta:Punkt) bewege(delta:Punkt)

Drei Äquivalente Darstellungen der Klasse PenTracker

<<controller>>

PenTrackerPenTrackerPenTracker


Objektdiagramme

Objkte werden auch durch Rechtecke dargestellt, aber:Das Namensfeld einer Instanz ist unterstrichen und besteht aus:

Einem Namen für die Rolle dieser InstanzEinem Doppelpunkt als TrennerEinem Doppelpunkt als TrennerDem Typ der InstanzMan muss entweder die Rolle oder den Doppelpunkt und den Typ angebenpp p yp g

Die Attribute werden zusammen mit ihren jeweiligen Werten angegeben.

Eine benannte Instanz von TarifEine anonyme Instanz von Tarif

Sommertarif : Tarif

zone2price = { {‘1’ 1 80} {‘2’ 2 40} {‘3’ 3 60} }

:Tarif


zone2price = { { 1 , 1.80}, { 2 , 2.40}, { 3 , 3.60} }

Klassendiagramm: Assoziationen

Assoziationen definieren Beziehungen zwischen Instanzen von KlassenKlassen.

Relationsname und Richtung in die er zu lesen ist.Hier: „Person arbeitet-für Firma“

Rolle von Firma in Beziehung zu Person.

Rolle von Person in Beziehung zu Firma.

Person*

Arbeitnehmer

K di lität / M lti li ität*Arbeitgeber arbeitet-fürFirma

Kardinalität / Multiplizitätbeliebig: *festes Intervall: 0..1offenes Intervall: 5..*

Die Multiplizität am jeweiligen Ende einer Assoziation gibt an, mit wie vielen Zielobjekten ein Quellobjekt in Beziehung stehen kann.


Klassendiagramm: N zu M Assoziationen

Assoziationen definieren Beziehungen zwischen Instanzen von KlassenKlassen.Die Multiplizität am jeweiligen Ende einer Assoziation gibt an, mit wie vielen Zielobjekten ein Quellobjekt in Beziehung stehen kann.

Dazu passendes Objektdiagramm Person**

Arbeitgeber arbeitet-für ArbeitnehmerFirma

eva : Person

j h P

zeitArbeit: Firma

i hAG Fi

hat einen Job

hat mehrere Jobs

hat mehrere Arbeitnehmer

hat einen Arbeitnehmer johan : PersonichAG: Firma

opa: Person

hat mehrere Jobs

briefkasten: Firma hat keinen Job

hat einen Arbeitnehmer

hat keinen Arbeitnehmer


Klassendiagramm: 1 zu 1 Assoziationen


hat-hauptstadtStadt

1Land

0,1

Dazu passendes Objektdiagrammbonn : Stadt ist keine Hauptstadt

Illegales Objektdiagramm

dd : Stadtnrw: Land ist Hauptstadt

dd : Stadt

m: Stadt

nrw: Land

bayern : Land illegal:ist mehrfache Hauptstadt

illegal: mehrere Hauptstädte


takatuka: Landillegal: hat keine Hauptstadt

Klassendiagramm: 1 zu N Assoziationen


hat-eckpunktPunkt

3..*Polygon

0,1

Dazu passendes Objektdiagramm: Punkt

: Punkt: Punkt

Illegales Objektdiagramm

: Punkt: Polygon : Punkt

: Punkt

: Punkt

: Polygon

: Polygon illegal:mehrfacher Eckpunkt

illegal: zu wenig Exkpunkte

illegal: zu wenig Exkpunkte


takatuka: Landillegal: zu wenig Exkpunkte

Klassendiagramm: Aggregation

Aggregation = „ist Teil von“-BeziehungK i A üb Abhä i k it d T il GKeine Aussage über Abhängigkeit des Teils vom Ganzen

Teile dürfen in mehreren „Ganzen“ enthalten seinIhre Lebensdauer ist nicht von der des Ganzen abhängigIhre Lebensdauer ist nicht von der des Ganzen abhängig

*Pfad

*Segment

{ordered}

Dazu passende Veranschaulichung der realen Welt

{ordered}

C

B A

C

Rote Segmente sind Teil der Pfade AB und AC


der Pfade AB und AC

Klassendiagramm: Aggregation

Aggregation = „ist Teil von“-BeziehungK i A üb Abhä i k it d T il GKeine Aussage über Abhängigkeit des Teils vom Ganzen

Teile dürfen in mehreren „Ganzen“ enthalten seinIhre Lebensdauer ist nicht von der des Ganzen abhängigIhre Lebensdauer ist nicht von der des Ganzen abhängig

*Pfad

*Segment

{ordered}

Dazu passendes Objektdiagramm

{ordered}

s1 : Segments2 : Segment

s3 : Segment

BA : Pfad

CA : Pfad s3 : Segment

s6 : Segment

s4 : Segment

CA : Pfad

s5 : Segment7 S t


s6 : Segments7 : Segment

Klassendiagramm: Komposition

Komposition = „ist ausschließliches Teil von“-BeziehungL b d d T il d t it L b d d GLebensdauer des Teils endet mit Lebensdauer des GanzenBeispiel: Abteilungen können ohne Firma nicht existieren

Unterabteilung

Firma

*

Abteilung

Unterabteilung

Dazu passende Veranschaulichung der realen Welt

11 1..*g

Hauptabteilung

p g

ABC GmbH

F h E t i kl V t i bForschung

F1 F3F2

Entwicklung

E1 E3E2

Vertrieb

V1 V3V2


Klassendiagramm: Komposition

Komposition = „ist ausschließliches Teil von“-BeziehungL b d d T il d t it L b d d GLebensdauer des Teils endet mit Lebensdauer des GanzenBeispiel: Abteilungen können ohne Firma nicht existieren

Unterabteilung

Firma

*

Abteilung

Unterabteilung

Dazu passendes Objektdiagramm

11 1..*g

Hauptabteilung

p j g

ABC: Firma Forschung: Abteilung

F3: Abteilung

F1: AbteilungF2: Abteilung

Entwicklung: Abteilung

g

E3: Abteilung

E1: AbteilungE2: Abteilung


Vertrieb: Abteilung

V3: Abteilung

V1: AbteilungV2: Abteilung

Assoziation, Aggregation, Komposition

SpezialisierungenA ti i t i ll A i tiAggregation ist spezielle AssoziationKomposition ist spezielle Aggregation

ModellierungAlles was für Assoziationen gilt, gilt für die beiden anderen auch

f fIm Zweifelsfall die allgemeinere Notation wählen und Intention durch zusätzliche Bedingungen explizit machen (Kardinalitäten, Constraints, ...)

Aggregation versus Assoziation Assoziation mit Kardinalitätsangaben und Constraints

Komposition versus AggregationAggregation mit Kardinalitätsangaben und Constraints


Aggregation mit Kardinalitätsangaben und Constraints

Aggregation= „Ist Teil von“-Beziehung

Modelliert Einheit eines "Ganzen" mit seinen "Teilen"I li i t ft k k di d O tiImpliziert oft kaskadierende Operationen

Operation auf Ganzem wird auch auf allen Teilen durchgeführtBeispiel 1: Verschiebung eines Rechtecks verschiebt alle seine KantenBeispiel 1: Verschiebung eines Rechtecks verschiebt alle seine KantenBeispiel 2: Laden des Ganzen von Platte läd alle seine Teile

Impliziert oft Existenz-AbhängigkeitTeil existiert nicht ohne Ganzementspricht dem Kaskadierungsverhalten beim Löschen: Teile werden mit gelöscht oder an anderes Ganzes weitergegebeng g g

Impliziert oft ExklusivitätTeil ist in genau einem Ganzen enthalten

Mögliche semantische Kategorienabhängig, exklusivabhängig nicht exklusivabhängig, nicht exklusivunabhängig, exklusivunabhängig, nicht exklusiv

Assoziation: Die vier Kategorien

exklusiv nicht exklusiv(nur in einem Ganzen) (in mehreren Ganzen)

abhängig 1 1..*+ explizite Angabe der

g g(Propagierung der

Löschoperation)

+ explizite Angabe der Propagierungs-Semantik

1Spalte

1Firma Abteilung* 1Zeile Zelle

p{ … }

unabhängig 0..1 *g g

0 1 4

(keine Propagierung der Löschoperation)

* *0..1Auto Reifen4 *Proj. Mitarb.

Assoziation: Weitere Kategorien

Komposition mit Kardinalität 0..10 T il kö bhä i G t d

0..1

0: Teile können unabhängig von Ganzem erzeugt werden1: Sobald sie einem Ganzen zugeordnet werden sind sie von diesem abhängig

Wird in der UML stark propagiertSehr praxisrelevanter FallSehr praxisrelevanter FallIn der Praxis wird das meiste nicht „top-down“ produziert, sondern „bottom-up“


Bedingungen (‚Constraints‘)

Bisher wurden nur besonders häufige Bedingungen modelliert, über S i l t ti ( B K iti “) dSpezialnotationen (z.B. „Komposition“) oder Kardinalitäten (z.B. 1..4)Das reicht oft nicht aus! Es gibt daher auch eine …g

Notation für beliebige BedingungenAngabe von Bedingung in geschweiften Klammern: { Bedingung }

Bedingungssprachevordefinierte Eigenschaften:

abstract, readOnly, query, leaf, ordered, unique, set, bag, …abstract, readOnly, query, leaf, ordered, unique, set, bag, … beliebige umgangssprachliche Formulierung

{ existenzabhängig }1Zeile Zelle

Object Constraint Language

{ g g }1Spalte

{ existenzabhängig }


Kapitel „Objektmodellierung“

Statisches Modell: Aggregation und Komposition – Gemeinsames BeispielKomposition Gemeinsames Beispiel

3..* Punkt 1

{ordered}Komposition

Kreis

*

KreisradiusPolygon

*

1Stil

farbeistGefüllt

1

AggregationistGefüllt Aggregation


Statisches Modell: Aggregation und Komposition – Gemeinsames BeispielKomposition Gemeinsames Beispiel

Komposition Fü B i h P l P kt d K i P ktFür Beziehung Polygon → Punkt und Kreis → Punkt …… weil man nicht möchte, dass der Mittelpunkt des Kreises auch Eckpunkt des Polygons sein kann. Dann würde nämlich ein Verschieben des Kreises das Polygon verformen!

AggregationFür Beziehung Polygon Stil und Kreis StilFür Beziehung Polygon → Stil und Kreis → Stil …… weil man gern möchte, dass anpassen eines gemeinsamen Stils alle Formen ändert die ihn benutzen

3..*Punkt 1

{ordered}

*

KreisradiusPolygon

Stil *


1 farbeistGefüllt

1

Denksportaufgabe

Wi ü d Si di B i hWie würden Sie die Beziehung einer Datei zu einem Ordner modellieren?

Assoziation, Aggregation oder Komposition?

?

?

Bedenken Sie:?

Die Datei ist zu jedem Zeitpunkt exklusiver Teil eines Ordners,… kann aber in einen anderen Ordner verschoben werdenWenn der Ordner gelöscht wird, wird die Datei mit gelöscht.


wird die Datei mit gelöscht.

Klassendiagramm: Vererbung

"direkte" Darstellung Figur

KurveLinie Polygon

"zusammengefasste" FigurgDarstellung

KurveLinie Polygon

Multiple Vererbung

yg

Student AngestellterMultiple VererbungEine Klasse mit mehreren Oberklassen

Student Angestellter


Bsp: C++ studentische Hilfskraft

Klassendiagramm: Vererbung

Vererbungbt M th d / Att ib t i

Supergeerbte Methoden / Attribute im Diagramm der Unterklasse nichtwiederholen

m(s:String)m(s:String, i:int )

field:T

Overridingüberschriebene Methoden im Diagramm der UnterklasseDiagramm der Unterklasse wiederholen

Overloading Sub1 Sub2

alle verschiedenen Signaturen angeben Ansonsten gelten die obigen

m(s:String, i:int )g()

otherField:Am(s:String)f()Ansonsten gelten die obigen

Regeln (auch überladene Methoden können in Untertypen überschreiben werden)

g()


überschreiben werden)

UML, statisches Modell: Generische KlassenKlassen

Klassen mit Typ-ParameterC "T l t "C++: "Templates"Java: ab JDK 1.5

TSet...

insert(T)

T

formaler Typ-Parameterremove(T)

Generische Klasse

Wert für Typ Parameter

<Employee>«bind»

Gebundenes Element

Wert für Typ-Parameter

EmployeeSet


UML, statisches Modell: Generische KlassenKlassen

Klassen mit Typ-ParameterC "T l t "C++: "Templates"Java: ab JDK 1.5

TSet...

insert(T)

T

formaler Typ-Parameterremove(T)

Generische Klasse

Gebundenes Element

kompaktere alternative Notation

EmployeeSet

= Set <Employee>

Wert für Typ-Parameter


Set Employee

Statisches Modell: Interfaces

SemantikI t f th lt M th d i tInterfaces enthalten nur Methodensignaturen

NotationKlassensymbol mit stereotyp <<interface>> im NamensfeldKlassensymbol mit stereotyp interface im Namensfeldleeres Attributfeld kann weggelassen werden

<<interface>>Hashable

hash():Integerhash():Integer

<<interface>>Comparable

isEqual(String):Boolean


isEqual(String):Boolean

Statisches Modell: Implementierungs-BeziehungBeziehung

SemantikK t / Kl i l ti t I t f “„Komponente / Klasse implementiert Interface“

Notationgestrichelter Vererbungs-Pfeil oder „Lollipop“gestrichelter Vererbungs Pfeil oder „Lollipop

Stringg...

isEqual(String):Booleanhash():Integer

C bl

<<bietet>> Hashable

Comparable

<<interface>><<interface>>Hashable

<<interface>>

String...

isEqual(String):Boolean<<bietet>>


Comparablehash():Integer

Statisches Modell: „Braucht“-Beziehung

SemantikKl b öti t I t f “„Klasse benötigt Interface“

Notationgestrichelter spitzer Pfeil („Abhängigkeitspfeil“) + Stereotypgestrichelter spitzer Pfeil („Abhängigkeitspfeil ) Stereotyp

Stringg...

isEqual(String):Booleanhash():Integer

C bl

Hashtable<<bietet>> <<braucht>>Hashable

Comparable

<<interface>><<interface>>Hashable

<<interface>>

String...

isEqual(String):BooleanHashtable<<bietet>> <<braucht>>


Comparablehash():Integer

Aktive Klassen / Objekte

Aktive Klasse: Jede ihrer Instanzen ist ein eigener Thread. B i i lBeispiel

Zahlungsanfragebearbeitung, Rechnungsbearbeitung und Zahlungsanweisungserstellung sind (ständig) aktive KlassenHingegen sind z.B. Zahlungsanfragen selbst nur auf Anfrage aktiv

BestelungserfassungBestellbestättigung Rechnung

ZahlungsaufforderungsUI

Rechnungsbearbeitung {active}

* *

*

Zahlungsanfrage-bearbeitung-UI {active}

Zahlungsanweisungs- Zahlungsanfrage

1

bearbeitung

NotationUML 2.0: Klasse/Objekt mit doppeltem vertikalem Rand oder {active}

erstellung Zahlungsanfrage


UML 1.4: Klasse/Objekt mit dicker umlaufenden Umrandung

Paketdiagramme

BedeutungG i th ti h ö i KlGruppierung thematisch zusammengöriger Klassen

Darstellung“Karteikarten”, auf denen die dazugehörigen Klassen aufgemalt sindKarteikarten , auf denen die dazugehörigen Klassen aufgemalt sind

Referenz auf eine Klasse in einem anderen Packagepackage::class

Import aus anderem PackageGestrichelter Abhängigkeits-Pfeil mit stereotyp <<imports>>

Kunden

Kunde

Bank

KontoBank::Konto

Kunde

...

Konto

...

<<imports>>



Demo „Together 2007 SP1“ (Teil 1)

InstallationÜberblick

KlassendigrammePaketdiagramme


3.4 Strukturdiagramme „im Großen“

Komponentendiagramme KapitelKompositionsübersichtsdiagrammeVerteilungsdiagramme

Kapitel „Systementwurf“


3.4 Verhaltensmodellierung (Teil 1)

SequenzdiagrammeKommunikationsdiagramme

Interaktionsübersichtsdiagramme

Sequenzdiagramm (‚sequence diagram‘)

Visualisiert Nachrichten entlang einer vertikalen Zeitachse

sd Ticket

einer vertikalen ZeitachseInteraktion zwischen

Akteuren und Objekten Passenger:TicketMachine

jverschiedenen Objekteneinem Objekt mit sich selbst

Bi t t D t ll

selectZone()

Bietet Darstellung vonDatenflussZeitpunkte und -dauer

insertCoins()

Zeitpunkte und dauerBietet Operatoren für

Nebenläufigkeit

pickupChange()

Verzweigungen / SchleifenFilterungen / Zusicherungen pickUpTicket()

Sequenzdiagramm (‚sequence diagram‘)

ObjekteObj ktdi N t ti fü Obj kt

sd Ticket

Objektdiagramm-Notation für passive oder aktive Objekte

Lebenslinie Passenger

Objekt

:TicketMachine

Zeitraum in dem das Objekt existiertSpäter: Explizite Notation zur

selectZone() Lebenslinie

Nachricht AktivitätSpäter: Explizite Notation zur Objekt-“Geburt“ und –“Tod“

Aktivität / AktivierunginsertCoins()

Zeitraum in dem das Objekt etwas tutGetriggert durch Nachricht (bei

pickupChange()

passiven Objekten) oder dauernder Thread (bei aktiven Objekten)

pickUpTicket()

Sequenzdiagramme: Datenfluss

Der Pfeil beginnt an der Aktivierung, welche die Nachricht gesendet hatDie Akti ier ng an der der Pfeil endet beginnt direkt am PfeilkopfDie Aktivierung an der der Pfeil endet beginnt direkt am PfeilkopfEine Aktivierung dauert so lange wie alle geschachtelten AktivierungenRückgaben geschehen implizit am Ende einer Aktivierung (für synchrone g g p g ( yNachrichten)

Pfeile für Rückgaben werden nur benutzt, um den Datenfluss explizit zu machen

f f

sd Ticket

drücke()

:Passagier:ZonenKnopf : Tarif :Display

preis(auswahl)

zeigePreis(Preis)

Preis

Datenfluss

Sequenzdiagramme (wichtige Elemente)UML 1 1

Interaktionspartnerpassives Objekt

rolle:Typ

UML 1.1UML 2.0

rolle:Typ

passives Objektaktives Objekt (Prozess/Thread) rolle:Typ rolle:Typ

Nachrichtenübermittlungsynchronasynchron

m1

m2

m1

m2y

Antwortnachrichtohne Ergebnis (bei synchronenohne Ergebnis (bei synchronen Nachrichten meist weggelassen)mit Rückgabewert

m1

m1: wert wertmit Rückgabewert

ZeiteinschränkungAb l t Z it ktAbsoluter ZeitpunktRelativer ZeitpunktIntervall

at(12.00)

after(12.00)

{12.00…13.00}

Sequenzdiagramme (wichtige Elemente)UML 1 1

Objekt wird durch Nachricht erzeugt

obj : Typenew

UML 1.1UML 2.0

obj : Typenew

erzeugt

Nachricht an sich selbstobj : Type obj : Type

Nachricht an sich selbst

Rekursiver Aufruf obj : Type

Nachrichten ohne explizit modellierte Interaktionspartner

lost

found

ZustandsinvarianteBedingung, die zu bestimmten

obj : Type

{p=15}


Zeitpunkt erfüllt sein muss

Asynchrone Sequenzdiagramme: UML 1.1Asynchrone NachrichtAsynchrone Nachricht

Akti i

Objekt-Erzeugung

Aktivierung

Auslassung


Objekt-Tod

Sequenzdiagramme: Kontrollstrukturen in UML 1 1 Iteration + If-thenin UML 1.1 Iteration + If then

sd MovieRental

:Customer :Rental :Movieinvoice()

Bedingung

totalCharge()IterationBedingung

*[for all rentals] charge(cus)[old(cus)] getPriceCode()

totalBonusPoints()

*[for all rentals] bonusPoints()[old(cus)] getPriceCode()

Aktivitätsphase für


pNachricht an sich selbst

Sequenzdiagramme: Kontrollstrukturen in UML 2 Kombinierte Fragmente“in UML 2 „Kombinierte Fragmente

Bedingungsd MovieRental

cus:Customer :Rental :Movie

invoice()

trifft [a] zu, wird dies Interaktionsfragment ausgeführt

totalCharge(cus)

loop(1,3)

[a]alt

getPriceCode()Alternativeif-then-else

[b]opt

[old(cus)]Schleife

bonusPoints(cus)getPriceCode()

[old(cus)]

Optionale Interaktionpif-then

Sequenzdiagramme: InteraktionsfragmenteInteraktionsfragmente

Komplexere Kontrollstrukturen werden durch Operatoren auf Interaktionsfragmenten (Ausschnitte des Sequenzdiagramms) realisiertInteraktionsfragmenten (Ausschnitte des Sequenzdiagramms) realisiert

Operator ZweckVerzweigungen alt Alternative Interaktionen – if-then-elseg gund Schleifen opt Optionale Interaktionen – if-then

break Ausnahme-Interaktionen – innerste Schleife verlassenloop Iterative Interaktionen

Nebenläufigkeit und Ordnung

seq Sequentielle Interaktionen mit schwacher Ordnung (Default)strict Sequentielle Interaktionen mit strenger Ordnungpar Nebenläufige Interaktionencritical Atomare Interaktionen

Filterung und Zusicherung

ignore Irrelevante Interaktionenconsider Relevante Interaktionenassert Zugesicherte Interaktionenneg Ungültige Interaktionen


Anwendung siehe Beispiel auf der nächsten Folie

Sequenzdiagramm: Kalender-Beispiel

Gemeinsamer KalenderÀ l G l C l d

sd Termin löschen

À la Google-CalenderMan muss sich anmelden

:Termin-Maske

te[i]:Termin

:CALEN-DARIUM

b1:

Hier: „Löschen eines Termins“Erst anmelden …d T i i

Benutzer

sd Anmelden

ref

dann Terminanzeige …dann Selektion des Termins … und Löschen anzeigeKalender

anzeige

Quelle

anzeigeKalender

lösche(te[i]) Lösche

„UML@Work“, Abbildung 4-46(te[i]) Lösche

(te[i])…

Sequenzdiagramm: Kalender-Beispiel

Was versteckt sich hinter der Referenz?

sd Anmelden

Referenz?Ein beliebiges dynamisches Diagramm

:Termin-Maske

te[i]:Termin

:CALEN-DARIUM

b1:

üf P t( d)

prüfe Passwort(pwd)

Hier: Der Anmeldevorgang Benutzerloop (1,3) [ richtiges

Passwort ]ref

anzeige(ergebnis)

prüfe Passwort(pwd)ergebnis=prüfePaswort(pwd)

sd Anmelden

[ falschesPasswort ]

Abbrechenmelde

break

meldeAbbrechen

Sequenzdiagramme: Fazit

Sequenzdiagramme…ä ti V h lt b ü li h I t kti…repräsentieren Verhalten bezüglich Interaktionen.

…ergänzen die Klassendiagramme, welche die Struktur repräsentieren.…sind nützlich, um

das Verhalten eines Anwendungsfalls auf die beteiligten Objekte abzubilden beteiligte Objekte zu findenVerhalten präzise zu beschreibenVerhalten präzise zu beschreiben

Der Zusatzaufwand lohnt sich auf jeden Fall bei komplexen und unklaren Abläufen

Aber: keine Zeit vergeuden, um Trivialitäten und Offensichtliches mit Sequenzdiagrammen zu modellierenq g


Kommunikationsdiagramm( Communication diagram‘)

In UML1: Kollaborationsdiagramm(‚Communication diagram )

Beschreibt Interaktion zwischen ObjektenZ i t h t kt ll I f ti (B i h d Obj kt )Zeigt auch strukturelle Informationen (Beziehungen der Objekte)Zeitlicher Ablauf gegeben durch Nummerierung der Nachrichten

Comm Prüfente[t]:Termin

Comm Prüfen

1.1.1.1.1.a: beginn1.1.1.1.1.b: dauer

1.1.1.1[te[t] ≠ kandidat]: kollidiertMit(kandidat)

1 1: hatKollision(kandidat)

1.1.1*||[für alle Termine te[t]]: prüfe(te(t))

tn[b]:Teilnehmerkandidat:Termin

1*||[für alle Teilnehmer tn[b]]:prüfe(tn[b])

1.1: hatKollision(kandidat)


1 ||[für alle Teilnehmer tn[b]]:prüfe(tn[b])



Beziehungen im Kommunikationsdiagrammt ti h A i tistatisch: Assoziationen

temporär: Parameter, lokale oder globale Variablen


Comm Prüfen

1.1.1.1.1.a: beginn1.1.1.1.1.b: dauer



1.1.1*||[für alle Termine te[t]]: prüfe(te(t))








Objekt mit Rolle : Typ Selektor


Sequenznummer sequentiell

Sequenznummer nebenläufig

Comm Prüfen

1.1.1.1.1.a: beginn1.1.1.1.1.b: dauer


sequentiellnebenläufig


Nachricht 1.1.1*||[für alle Termine te[t]]: prüfe(te(t))





* Iteration *|| Nebenläufige Iteration

[ … ] Bedingung

Kommunikationsdiagramm

Objekte ohne „Lebenslinien“

Zeitlicher Verlauf wird durch Nummern in angegebenSyntax: „Nummer : Nachricht“Syntax: „Nummer : NachrichtBeispiel: 1 : foo, 2 : bar zuerst wird „foo“ gesendet, dann „bar“

Nummer zeigt sequenzielle oder parallele VerarbeitungSequentielle Bearbeitung Zahlen

Bei „1, 1.1., 1.2, 2“ sind 1.1, 1.2 sequentielle Teilabläufe von 1Bei „1, 1.1., 1.2, 2 sind 1.1, 1.2 sequentielle Teilabläufe von 1Nebenläufige Bearbeitung Namen

Bei „1, 1.a., 1.b, 2“ sind 1.a, 1.b nebenlufigeTeilabläufe von 1

Iteration wird nach der Sequenznummer angegeben:Sequentiell: 2.3 *[i=1..n]: nachricht(i)q [ ] ( )Nebenläufig: 2.3 *||[i=1..n]: nachricht(i)

Vergleich zu Sequenzdiagramm

Kommunikationsdiagramme sind schwierigerZ itli h Abf l i t N i k t i t dZeitliche Abfolge ist muss aus Nummerierung rekonstruiert werdenBei Änderungen muss viel neu Nummeriert werden

gute Werkzeugunterstützung ist daher essentiell

Kommunikationsdiagramme sind einfacherStrukturelle Informationen zusätzlich darstellbarStrukturelle Informationen zusätzlich darstellbarObjekte können überall platziert werdenWeniger Überkreuzungen übersichtlicherLeichter kollaborativ am Whiteboard zu erstellen


Demo Together 2007 SP1 (Teil 2)

Sequenzdiagrammeq gKommunikationsdiagramme


3.5 Verhaltensmodellierung (Teil 2)

AktivitätsdiagrammeInteraktionsübersichtsdiagrammeg

Zustandsdiagramme

Aktivitätsdiagramme

Eine Aktivität umfasst Aktionen, Kontroll- und DatenflüsseSi ifi i t d K t ll d D t fl i h AktiSie spezifiziert den Kontroll- und Datenfluss zwischen Aktionen

Eine Aktion ist ein elementarer Arbeitsschrittatomar (d.h. Effekte werden bei Unterbrechung rückgängig gemacht)atomar (d.h. Effekte werden bei Unterbrechung rückgängig gemacht)

SynchronisierungAktion

Aktivität

Teilnehmer

Synchronisierung

Kontaktpersonauswählen

Parallelisierung Person ausgewählt

Termin vereinbarenEnde

informierenTerminvorschlag

gefunden EntscheidungTerminvorschlag

finden[else]

g

AbbruchVereinigung

Start


[Anzahl Teilnehmer ohne Kollision <90%]Vereinigung

Bedingung

Aktivitätsdiagramme: TokenbasierteSemantikSemantik

Token, die Abläufen entsprechen, fließen durch das Diagramm, ab dem Startknoten.dem Startknoten.

Synchronisation: Auf jeder Eingangskannte muss ein Token ankommen.Parallelisierung: Auf jeder Ausgangskante fließt ein Token weiter.Vereinigung: Jedes ankommende Token wird weitergeleitet. Entscheidung: Token fliest nur auf der Ausgangskante, deren Bedingung wahr ist.

Teilnehmer Kontaktperson

auswählenPerson ausgewählt

informierenTerminvorschlag

gefunden

Terminvorschlag finden

[else]


[Anzahl Teilnehmer ohne Kollision <90%]

Aktivitätsdiagramme

Ablauforientierte Notation b i d f BPEL (B i P E i i L ) d P t ibasierend auf BPEL (Business Process Engineering Language) und Petri-Netzen

Auch für nicht objekt-orientierte SystemeAktivitäten sind unabhängig von ObjektenAnwendbar auch auf Geschäftsprozesse FunktionsbibliothekenAnwendbar auch auf Geschäftsprozesse, Funktionsbibliotheken, …

Elementare KonzepteAktivität = benanntes VerhaltenAktion = atomare Aktivität (einzelner Arbeitsschritt)


Aktivitätsdiagramme: Aktivitäten

Aktivitätsdiagramm G h b t h d Akti ität k t d Akti ität k tGraph bestehend aus Aktivitätsknoten und Aktivitätskanten

AktivitätsknotenKontrollknoten: Alternativen, Parallelisierung, SynchronisationDatenknoten: Parameter, Puffer, Datenbanken

fAktionsknoten: Elementare, atomare, meist vordefinierte Aktionen

AktivitätskantenAktivitätskantenKontrollflusskanten:Verbindungen von Aktions- und KontrollknotenDatenflusskanten: Verbindungen von Datenknoten


Aktivitätsdiagramme: die wichtigsten ElementeElemente

Aktivität Name der Aktivität

Start- und EndknotenStart 4 rte

n ot

en

StartAktivitätsende (Ende aller Abläufe)Ablaufende (Ende eines bestimmten Ablaufs) 3

von

44vo

rdef

inie

rA

ktio

nskn

o

Alternative Abläufe

v A

Entscheidungsknoten Vereinigungsknoten

ollk

note

n

Nebenläufige AbläufeParallelisierungsknoten

Kon

tro


gSynchonisierungsknoten


Datenknoten Aktivität Aktivitätsparameter überlappen den Rand!

Parameter von Aktivitäten

Parameter (Pins) von AktionenAktion

überlappen den Rand!

Pins liegen außen!

Temporäre Puffer <<centralBuffer>>To-dos

Persistente Puffer

Eingabeparameter

<<datastore>>Kontakte

Explizit: Pfeil im Datenknoten hin zurAktivität / AktionImplizit: Parameter links oder oben

Aktion Explizit

Implizit: Parameter links oder oben

AusgabeparameterExplizit: weg von der

Aktion Implizit


Explizit: … weg von der …Implizit: … rechts oder unten …


Datenfluss A1 A2Durchgezogene spitze Pfeile zwischen Datenknoten A1 <<centralBuffer>>

XYZ A2

KontrollflussA1 A2

Durchgezogene spitze Pfeile zwischen Aktionen, Aktivitäten und Kontrollknoten

A1 A2

A1 A2

A3


Aktivitätsdiagramme: Aktionen

Aktion = atomare Aktivität At k t b h d ht d b j li h Eff ktAtomar = kann unterbrochen werden, macht dann aber jegliche Effekte rückgängig

44 vordefinierte Aktionen in 4 KategorienAlle sprachunabhängig definiert. Sonderfall: OpaqueAction als Hinweis auf Aktion die in einer bestimmten Implementierungssprache definiert istAktion die in einer bestimmten Implementierungssprache definiert ist

Kommunikationsbezogenen AktionensendObjectAction, sendSignalAction

Objekt oder Signal an Empfänger sendenasynchron, Ergebnis wird ignoriertasynchron, Ergebnis wird ignoriertNotation: Blockpfeile Informiere Teilnehmer


Aktivitätsdiagramm: Partitionen

PartitionG

KalenderBenutzer

Gruppierung von Teilen eines AktivitätsdiagrammsGruppierungskriterium ist

<<datastore>>Benutzer

BenutzerIDprüfen

[else]beliebig

Im Beispiel: Zugehörigkeit der Aktionen zu gewissen Klassen

Termin anlegen

[ok]

Notation„Schwimmbahnen“/„Swimlanes“

Termin

Termin

[erzeugt]

Termin

Teilnehmer auswählen

Eckdaten des T i f

Termin

Kollisionen prüfen

Termins erfassen


Interaktionsübersichtsdiagramm ( Interaction overview diagram‘)(‚Interaction overview diagram )

Neu in UML 2M d lli K llfl

Siehe

intover Termin erfassen

Modelliert Kontrollfluss zwischen verschiedenen Interaktionsabläufen

:Termin-Maske

:CALEN-DARIUM

b1:Benutzer

loop(1 3)

sd Anmeldensd PrüfePasswort

Reihenfolge und Bedingungen

I t i P i i i

anzeige(ergebnis)

[richtigesPasswort]


ergebnis=prüfePaswort(pwd)


loop(1,3)

Ist im Prinzip ein Aktivitätsdiagramm das statt Aktionen Interaktionsdiagramme als Knoten enthalten kann

Auch nur Referenzen auf Interaktionsdiagramme möglich

Eckdaten des Termins erfassen

Teilnehmer erfassen

ref ref

Interaktionsdiagramme möglich („ref“) Notifikationen erzeugen

Sichten aktualisierenref


Zustandsdiagramm

Beschreiben das dynamische Verhalten eines Objektes als endlicher AutomatAutomat

button1&2Pressed button2Pressed IncrementBli k H

Startzustand

button1&2Pressed

button1Pressed

button2Pressed IncrementHours

Blink Hours

ZustandTransition

Ereignis

button2Pressedbutton1&2Pressed IncrementMinutes

Blink MinutesZustand

button1&2Pressed button2Pressed

button1Pressed

Blink Seconds IncrementStop Blink Seconds IncrementSeconds

StopBlinking

Endzustand


Zustandsdiagramm: Beispiel Bestellungsbearbeitung“„Bestellungsbearbeitung

Start-Zustand Zustand

Ereignis [Bedingung] / Aktion

[nicht alle Posten geprüft]/ hole nächsten Posten Prüfen Ausliefern

[alle Posten geprüft&& verfügbar]

do / prüfeVerfügbarkeit do / ausliefern

f

g ]

Neue Ware erhalten

[alle Posten geprüft&& manche nicht verfügbar]

Ereignis / Aktion

Warten

[Posten nicht verfügbar]

Transition

self-transition

Transition


Geliefert

Zustandsdiagramm: Beispiel Bestellungsbearbeitung“ mit Abbruch„Bestellungsbearbeitung mit Abbruch

[nicht alle Posten geprüft]/ hole nächsten Posten Prüfen Ausliefern



f

g ]

Neue Ware erhalten


Warten


Abbruch AbbruchAbbruch


GeliefertAbgebrochen

Zustandsdiagramm – Geschachtelte Bestellungsbearbeitung“ mit Abbruch„Bestellungsbearbeitung mit Abbruch

Oberzustand (‘superstate’, ‘complex state’)

Aktiv[nicht alle Posten geprüft]/ hole nächsten Posten Prüfen Ausliefern



f

g ]

Neue Ware erhalten


Warten


AbbruchGruppentransition

Unterbricht alle laufenden Aktionen des


Unterbricht alle laufenden Aktionen des Quellzustandes und all seiner Unterzustände GeliefertAbgebrochen

Nebenläufige Zustands-Diagramme:Mit impliziten Übergängen auf und vonMit impliziten Übergängen auf und von

Implizite ParallelisierungI li it T iti A ß i j d d ll l St t tä dImplizite Transition von Außen in jeden der parallelen Startzustände

Implizite SynchronisationImplizite Transition von den parallelen Endzuständen zum nächstenImplizite Transition von den parallelen Endzuständen zum nächsten äußeren Zustand… erst wenn alle parallelen Endzustände erreicht sind.

Warten

Abgebrochencanceled

Gruppentransition

GeliefertAusliefernPrüfen

Gruppentransition

AutorisiertAutorisierung Einzeltransition[ok]


Abgelehnt[fehlgeschlagen]

Nebenläufige Zustands-Diagramme:Mit expliziter Parallelisierung / SynchronMit expliziter Parallelisierung / Synchron.

Explizite Parallelisierung: Quellzustände außerhalb, Zielzustände in verschiedenen parallelen Unterbereichenverschiedenen parallelen Unterbereichen

Zielzustände beliebig (müssen nicht Startzustände sein)Explizite Synchronisation: Zielzustände außerhalb, Quellzustände in p yverschiedenen parallelen Unterbereichen

Quellzustände beliebig (müssen nicht Endzustände sein)

Waiting

canceled Abgebrochen

DispatchingCheckingGeliefert

AuthorizedAuthorizing[ok]


[authorization failed] Abgelehnt

Zustandsdiagramm: „Auktion“

Aus dem Aktivitätsdiagramm bekannte Kontrollflussnotation erlaubtE t h id V i iEntscheidung, Vereinigung

Auktion

Auktionshaus

Bieten

Auktion

Gebot abgeben [Gebot gültig]

[Gebot abgelehnt, weitere Gebote]

Gebot überprüfen

Gebot erwarten

Gebot akzeptieren

Kreditwürdigkeit prüfen

Kreditwürdigkeit prüfen

[Prüfungen positiv]

Gekauft

Identität prüfen[Prüfungen negativ]

[Prüfungen positiv]


Zustand: Ein Zustand ist ein Viertupel

NameM h b t Z tä d lt l hi dMehrere unbenannte Zustände gelten als verschieden

AktivitätenWas geschieht beim Eintritt in den Zustand (entry),Was geschieht beim Eintritt in den Zustand (entry), … während des Zustands (do) und… beim Verlassen des Zustands (exit)

Innere TransitionenInterne Zustandsübergänge, die nicht die entry- und exit-Aktivitäten auslösen

Innere StrukturGeschachtelte Unterzustände und die dazugehörigen Transitionen

Jede Kategorie ist optional aber mindestens eine muss angegeben sein. Innere Struktur kann ersetzt werden durch Verweis auf


Teilautomat.

Entry- und Exit-Aktivitäten

Entry-AktivitätKurzschreibweise für Aktivität die auf jeder eingehenden Kante geschieht

Exit-AktivitätKurzschreibweise für Aktivität die auf jeder ausgehenden Kante geschiehtKurzschreibweise für Aktivität die auf jeder ausgehenden Kante geschieht

Kapselung und WartbarkeitEntry und Exit im Zustand statt auf jeder ein- und ausgehenden Kante

Z Z/ a2

≡/ a1

/ a1

entry / a1exit / a2

≡/ a2

/ a1


Innere Transitionen

Selbst-Transition Innere TransitionExterner Übergang in den selben Zustand

Interner Übergang in den selben Zustand

Löst wie jede externe Transition alle Aktivitäten des Zustands aus.

Löst keine entry- und exit-Aktivitäten aus!

Z

Z

e / a ≠(keine)

Aktivitäten

Ze / a

e / a ≠Innere

Transition


Zustandsautomat mit entry- und exit-Aktivitäten: Termineingabeformular“Aktivitäten: „Termineingabeformular

BeginnBearbeiten EndeBearbeitenTABgentry / Schreibmarke setzendo / DatumZeit erfassenexit / Abhängigkeiten aktualisieren

entry / Schreibmarke setzendo / DatumZeit erfassenexit / Abhängigkeiten aktualisieren

ENTER

F hl OK

TABENTER ENTER

ENTER[Werte korrekt]Fehler

entry / Fehlermeldung anzeigenexit / Fehlermeldung löschen

OKentry / Schaltfläche hervorhebenexit / Hervorhebung aufhebenENTER

[Werte inkorrekt]

[Werte korrekt]/ Änderungen akzeptieren

Abbruch

TAB

ENTER

Die Spezifikation des Verhaltens

entry / Schaltfläche hervorhebenexit / Hervorhebung aufheben

ENTER/ Änderungenverwerfen

graphischer Oberflächen ist eine typischeAnwendung von Zustandsdiagrammen.


g

Expansion von „do / DatumZeit erfassen“

BeginnBearbeitenentry / Schreibmarke setzen

wird nicht h hi entry / Schreibmarke setzen

exit / Abhängigkeiten aktualisieren

/ posDate = posTime = 0

after(5 min.)

mehr hiererwähnt

…da es nun im Detail da

DatumErfassenentry / Schreibmarke an posDate setzenZiffer(z) [posDate < 8] / date[posDate]:=z; posDate++

TAB

ENTER

/ posDate posTime 0

F1

im Detail daspezifiziert wird

Ziffer(z) [posDate < 8] / date[posDate]:=z; posDate++BACKSPACE [posDate > 0] / posDate--

Hilfe zeigen

Z itE f

BACKSPACE [posTime = 0]when(posDate = 8)H

CLEAR

„History-Zustand“ =Unterzustand der vorher

verlassen wurde

ZeitErfassenentry / Schreibmarke an posTime setzenZiffer(z) [posTime <4 ] / time[posTime]:=z; posTime++BACKSPACE [posTime > 0] / posTime--

CLEAR/ Anzeige löschen

Wenn Ihnen nicht klar ist warum hier eine selbst-Transition steht,


,blättern Sie 2 Folien zurück.

Unmittelbar vorheriger Zustand ( History State‘)(‚History State )

„merkt“ sich die Unterbrechungsgeschichte der unmittelbarenTeilzuständeH

TeilzuständeDient dazu in den unmittelbar enthaltenen unterbrochenen Teilzustand zurückzukehren.Im Beispiel würde ‚e3‘ zu L oder K zurückkehren.Falls es zu K zurückkehrt, würde es wieder im Startzustand A anfangenMerke: merkt sich nicht tiefer geschachtelte Teilzustände!HMerke: merkt sich nicht tiefer geschachtelte Teilzustände!

YHistory State

H

HK

e0 e1 e2

e3

History State

A BX L Ze0 e1 e2


Beliebig geschachtelter vorheriger Zustand ( Deep History State‘)Zustand (‚Deep History State )

„merkt“ sich die Unterbrechungsgeschichte beliebig tief geschachtelter TeilzuständeH*geschachtelter Teilzustände

Um im vorherigen Beipiel gegebenenfalls auch nach B zurückkehren zu können würde man ein verweden.H*Referenzen auf geschachtelte Unterzustände mit „Doppelpunkt-Notation“:z.B: „Y:K:B“

Deep History StateY

H*Deep History State

K

e0 e1 e2

e3

A BX L Ze0 e1 e2


Transition = Zustandsübergang

NotationSpitzer Pfeil mit Beschriftung Ereignis [Bedingung] / Aktion

E [B] / ASpitzer Pfeil mit Beschriftung Ereignis [Bedingung] / Aktion

SemantikWenn das Ereignis eintritt und die Bedingung wahr ist, wird die Transition

d di Akti füh t “di T iti f t”und die Aktion ausgeführt “die Transition feuert”Die Transition unterbricht evtl. noch laufende Aktionen des QuellzustandesSind mehrere Transitionen „feuerbereit“ wird nichtdeterministisch genau geine ausgewählt.

EreignisKeines angegeben: Implizit das Ende der Aktivitäten des QuellzustandsKeines angegeben: Implizit das Ende der Aktivitäten des Quellzustands.Signal(Param): Empfangenes Signal, evtl. mit Parametern.Call(Param): Empfangene Nachricht, evtl. mit Parametern.when(Cond): Wahr werden einer laufend überprüften Bedingung.after(TimeIntervall): Nach Ablauf einer absoluten Zeitspanne (1 Sek) oder eines relativen Zeitintervals (5 Sekunden seit Verelassen von Zustand Z).


eines relativen Zeitintervals (5 Sekunden seit Verelassen von Zustand Z).Sonstiges: Auch recht informelle “Ereignisse” zuässig.

Transition: Semantische Feinheiten

when(Lager leer) / AktionS b ld d L l i t i t Akti

E / A

Sobald das Lager leer ist passiert Aktion

Bestellung eingegangen [Lager leer] / Aktion E [B] / Ag g g g [ g ]Nur wenn eine Bestellung eingeht und danndas Lager leer ist passiert Aktion

[ ]

[Lager leer] / AktionWenn bei Ende der Aktivität des Quellzustands

[B] / A

das Lager leer ist passiert Aktion



Demo „Together 2007 SP1“ (Teil 3)

AktivitätsdiagrammeZustandsdiagramme

Interaktionsübersichtdiagramme


3.6 Zusammenfassung und Ausblick

Kurzrückblick der besprochenen NotationenKurzübersicht der ausstehenden Notationen

Überblick kommender Kapitel in Bezug auf UML

UML Notationen: Was wird wo erläutert?

Klassendiagramm

Objektdiagramm

Klassendiagramm++

Objektdiagramm

Paketdiagramm




V h lt di

UseCase-Diagramm

Aktivitätsdiagramm

Z t d di

Stereotypen

Verhaltensdiagramm Zustandsdiagramm


Sequenzdiagramm

Kommunikations-diagrammIn diesem Kapitel



Im Kapitel „Objektentwurf“

Im Kapitel „Anforderungserhebung und Anforderungsanalyse“

Im Kapitel „Systementwurf“

UML Kurzübersicht: Strukturdiagramme

Klassendiagramm / Class diagramB h ibt di t ti h St kt d S t

A B*

Beschreibt die statische Struktur des Systems: Objekte, Attribute und Assoziationen. C1 ..*

Objektdiagramm / Object diagrama:A b:B*

j g j gBesteht aus Objekten und deren Beziehung foo:C

bar:C

Paket Diagramm / Package diagramM

PBeschreibt die Komposition von PaketenKann Klassendiagramme enthalten

i

MyClass::N

M

Q


<<imports>>M

UML Kurzübersicht: Strukturdiagramme 2

Komponentendiagramm / Component diagramZ i t di I l ti bhä i k it

K2

Zeigt die Implementierungsabhängigkeiten von Komponenten untereinander K1

Kompositionsstrukturdiagramm / Composite structure diagram

Hierarchische Dekomposition verschiedener

AX

:AssoziationHierarchische Dekomposition verschiedenerSystembestandteile (UML Modell-Elemente)Darstellung der internen Struktur von Klassen, K t K t d K ll b ti

YZ *

Komponenten, Knoten und Kollaborationen

Verteilungsdiagramm / Deployment diagram<<device>>DBServerVerteilungsdiagramm / Deployment diagram

Zeigt die eingesetzte Hardwaretopologie…und das Laufzeitsystem

<<device>>PDA

<<deploy>>


<<artifact>>Order.jar

UML Kurzübersicht: VerhaltensdiagrammeVerhaltensdiagramme

Anwendungsfalldiagram / Use case diagramBeschreibt das f nktionelle Verhalten des S stems

X Y<<include>>

Beschreibt das funktionelle Verhalten des Systems aus Sicht des Benutzers.

/

Z

A B CAktivitätsdiagramm / Activity diagram

Modelliert das dynamische Verhalten eines Systems, insbesondere den Workflow, z.B. durch ein Fl di

fg

d

e

Flussdiagramm

Zustandsdiagramm / State diagram s3e‘

h

g gBeschreiben das dynamische Verhalten eines individuellen Objektes als endlichen Automat

s1 s2

s4

ee

e#

Interaktionsdiagramm / Interaction diagrammBeschreibt das Zusammenspiel verschiedener

Vier verschiedene Typen

s. nächste Folie


Objekte

UML Kurzübersicht: Verhaltensdiagramme: InteraktionVerhaltensdiagramme: Interaktion

Sequenzdiagramm / Sequence diagramB h ibt d d i h V h lt i h

a:A b:B c:C

Beschreibt das dynamische Verhalten zwischen Akteuren und System aus zeitlicher Sicht

Kommunikationsdiagram / C1:e1Kommunikationsdiagram /

Communication diagramBeschreibt das dynamische Verhalten zwischen Akteuren und System aus struktureller Sicht

a:A

b:B

c:C

e

1 1 e2Akteuren und System aus struktureller Sicht

Interaktionsübersichtdiagramm /Interaction overview diagram

1.1:e2

a:A b:B c:Csd P

gZeigt Interaktionsdiagramme im Kontrollfluss

Zeitverlaufsdiagramm / Timing diagramDarstellung von Zustandsänderungen von InteraktionspartnernSinvoll bei der Modellierung von zeitkritischem

a:A

:B

m1m3z7

z1z2


Sinvoll bei der Modellierung von zeitkritischemVerhalten, z.B. Echzeitsysteme

b: z8

Kapitel 3 Die Unified Modeling Language (UML) · UML-Diagramm Vhlt di UseCase-Diagramm...

Documents

Transcript of Kapitel 3 Die Unified Modeling Language (UML) · UML-Diagramm Vhlt di UseCase-Diagramm...