Kapitel 4 Einführung in die Unified Modeling Language (UML) · zAktivitätsdiagramm/Activity...

Vorlesung Softwaretechnologie 2007/8Dr. Günter Kniesel R O O T SDr. Günter Kniesel

Kapitel 4Einführung in die

Unified Modeling Language (UML)

Unified Modeling Language

Einheitliche Sprache / Notation für den gesamten Zyklus der Softwareentwicklung

Bietet zahlreiche Diagrammtypen für……die verschiedenen Phasen der Softwareentwicklung

erschiedene Eigenschaften on Soft are…verschiedene Eigenschaften von Softwarestatische Sicht auf die Strukturdynamische Sicht auf das Verhalten

Plattform für die Kommunikation zwischenSoftware-Entwickern und Kunden / AuftraggebernSoftware-Entwicklern untereinander

Mittlerweile breite Tool-Unterstützung fürMittlerweile breite Tool-Unterstützung für……die Erstellung von UML Diagrammen…Code-Generierung aus Diagrammen

Di G i C d (R E i )

Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-2 R O O T S

…Diagramm-Generierung aus Code (Reverse-Engeneering)

Bezug von UML zu gängigen OO Sprachen

C++

UML

sprachspezifische Details

Konzepte ohne direkter Entsprechung in

gängigen Sprachen

direkt ineinander abbildbarer

gemeinsamer Kern


UML Versionen

UML 1, 1997 / UML 1.1, 1998Ergebnis eines OMG-Aufrufs zur Spezifikation eines ModellierungsstandardsModellierungsstandards

OMG: Standardisierungsgremium für Objektorientierte Systementwicklung

UML 2, 2005Neue Diagrammtypen

Sollen den Anforderungen heutiger Softwarearchitekturen gerecht werden– Komponenten- und Serviceorientierte (SOA) Architekturenp ( )– Geschäftsprozessmanagement– Echtzeitsysteme–– …

Modifikationen bestehender Diagrammtypenz.T. große Änderungen

Grundidee: Modell Driven Software Engineering (MDSE)Sourcecode als Hauptartefakt ablösen…und durch Modelle ersetzen, aus denen die Programme generiert werden


– MDA, Generative Programming, Program Transformations

UML Versionen

In dieser VorlesungHauptsächlich UML 2, teilweise UML 1.4

In der Praxis wird noch häufig die UML 1 4 Notation verwendetIn der Praxis wird noch häufig die UML 1.4 Notation verwendetManche Tools unterstützen UML 2 noch nicht vollständig


UML Diagramme: Hierarchie & Neuerungen in UML 2

Klassendiagramm

Objektdiagramm

PaketdiagrammStrukturdiagramm

Neu in UML 2

Komponentendiagramm

Kompositions-strukturdiagramm

Strukturdiagramm

VerteilungsdiagrammUML-Diagramm

UseCase-Diagramm

konkrete Klasse

Verhaltensdiagramm

Aktivitätsdiragramm

Zustandsdiagramm

I t kti di

Sequenzdiagramm

Kommunikations

Interaktionsdiagramm

abstrakte Klasse

Vererbungs- Kommunikations-diagramm

Zeitverlaufsdiagramm

Interaktions-Dies ist bereits ein Klassendiagramm!

Vererbungsbeziehung


Interaktionsüberichtsdiagramm

Dies ist bereits ein Klassendiagramm!

UML Kurzübersicht: Strukturdiagramme

Klassendiagramm / Class diagramBeschreibt die statische Struktur des Systems:

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

Objektdiagramm / Object diagram a:A b:B*

Besteht aus Objekten und deren Beziehung foo:Cbar:C

Paket Diagramm / Package diagramB h ibt di K iti P k t M

PBeschreibt die Komposition von PaketenKann Klassendiagramme enthalten

i

MyClass::N

M

Q


<<imports>>M

UML Kurzübersicht: Strukturdiagramme 2

Komponentendiagramm / Component diagramZeigt die Implementierungsabhängigkeiten von

K2

Komponenten untereinander

Kompositionsstrukturdiagramm /

K1

Kompositionsstrukturdiagramm / Composite structure diagram

Hierarchische Dekomposition verschiedener

AX

:AssoziationSystembestandteile (UML Modell-Elemente)Darstellung der internen Struktur von Klassen, Komponenten, Knoten und Kollaborationen

YZ *

:Assoziation

Verteilungsdiagramm / Deployment diagram <<device>>DBServerZeigt die eingesetzte Hardwaretopologie

…und das Laufzeitsystem

DBServer

<<device>>PDA

<<deploy>>


<<artifact>>Order.jar

UML Kurzübersicht: Verhaltensdiagramme

X Y<<include>>Anwendungsfalldiagram / Use case diagram

Beschreibt das funktionelle Verhalten des Z

A B C

Systems aus Sicht des Benutzers.

Aktivitätsdiagramm / Activity diagramf

g

h

d

eAktivitätsdiagramm / Activity diagram

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

s3e

e‘

hg

Zustandsdiagramm / State diagrams1 s2

s4

e

e#

Beschreiben das dynamische Verhalten eines individuellen Objektes als endlichen Automat

Interaktionsdiagramm / Interaction diagrammBeschreibt das Zusammenspiel verschiedener Objekte

Vier verschiedene Typen

s. nächste Folie


Objekte

UML Kurzübersicht: Verhaltensdiagramme: Interaktion

a:A b:B c:CSequenzdiagramm / Sequence diagramBeschreibt das dynamische Verhalten zwischen Akte ren nd S stem a s eitlicher Sicht

C1:e1

Akteuren und System aus zeitlicher Sicht

Kommunikationsdiagram / Communication diagram a:A

b:B

c:C

e

1 1 e2

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

1.1:e2

a:A

m1z1z2

Zeitverlaufsdiagramm / Timing diagramDarstellung von Zustandsänderungen von Interaktionspartnern a

b:B

m1m3z7

z8

z2pSinvoll bei der Modellierung von zeitkritischem Verhalten, z.B. Echzeitsysteme

a:A b:B c:Csd P

Interaktionsübersichtdiagramm /Interaction overview diagram

Zeigt Interaktionsdiagramme im Kontrollfluss


Zeigt Interaktionsdiagramme im Kontrollfluss

Vorlesung Softwaretechnologie 2007/8Kapitel 4: Unified Modelling Language (UML) R O O T Sap te U ed ode g a guage (U )

3 1 UML Strukturdiagramme (1):3.1 UML Strukturdiagramme (1):Klassen-, Objekt- und Paketdiagramme

Klassendiagramm

Klasse

1 1 11

EinfacheUhrMultiplizität Assoziation

Batterie2

ZeitKnopf1 12

status

LCDDisplayblinkIdx

drücke()lasseLos()

blinkeSekunden()blinkeMinuten()blinkeStunden()t Bli k ()

lade() jetzt()

stoppeBlinken()refresh()

OperationAttribute

Klassendiagramme repräsentieren die Struktur eines Systems


Klassendiagramme repräsentieren die Struktur eines Systems

Klassendiagramm : Elemente

Tarif

T bl Z 2P iName

Att ib tTable Zone2PriceEnumeration getZones()Price getPrice(Zone)

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.D Kl i t di i i i htb I f tiDer 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 SichtenFliessender

Window{ status=tested }

DetaillierungsgradImplementierungAnal se / Design

Übergang

Window

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

i XWi d

Analyse / Design„eingeklappt“

size: Areavisibility: Booleandisplay()

Wi d

- xwin: XWindow

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

Sichtbarkeit (Implementierungs-Ansicht)public: +protected: #private:private: –

Weitere NotationenKlassenvariable / -methode: unterstrichen


Klassenvariable / -methode: unterstrichenabstrakte Klasse / Methode: kursiv

Klassendiagramm: Assoziationen

Tarif

Enumeration getZones()

*pricezone

Mehrfahrtenkarte*

Assoziationen bezeichnen Beziehungen zwischen Instanzen von

Enumeration getZones()Price getPrice(Zone)

zone

Klassen.Die Multiplizität am Ende einer Assoziation gibt an, wie viele Objekte ein Quellenobjekt legitim referenzieren kann.ein Quellenobjekt legitim referenzieren kann.

PolygonLand

1hat hauptstadt

name:String

1

1-1 Beziehung 1-n Beziehung

*

x:Integery:Integer

Punkt

hat-hauptstadt

name:StringStadt

1

1


y:Integername:String

Klassendiagramm : Assoziationen

Kardinalitätbeliebig: * Relationsname und Richtung in die beliebig: *festes Intervall: 0..1offenes Intervall: 5..*

ger zu lesen ist.Hier: „Person arbeitet-für Firma“

Person* arbeitet-für ArbeitnehmerFirma Person*Arbeitgeber beschäftigt

Firma

Rolle von Firma in Beziehung zu PersonRolle von Firma in Beziehung zu Person.

Findet sich oft als Variablenname in der Implementierung von Person wieder:

public class Person { Firma [] arbeitgeber;

}

Binären Relationen die in beide Richtungen navigierbar sein sollen, werden besser


Binären Relationen die in beide Richtungen navigierbar sein sollen, werden besser durch eigene Klasse Implementiert.

UML, statisches Modell: Assoziationen (Implementations-Sicht)

Navigations-Hinweis• in Implementations-Sicht• Hier: direkter Zugriff nur

Beziehungen mit unbegrenzter Kardinalität werden durch passende "Collection"-Typen implementiert

(Array, Vector, etc.).

Hier: direkter Zugriff nur von Person auf Company

Person* works-for employeeCompany Person

*employer employs

Rolle von Company in Beziehung zu Person.Fi d t i h ft l V i bl i d I l ti

Company

Findet sich oft als Variablenname in der Implementierung von Person wieder:

class Person { {Company[] employers;

}

Bi ä R l ti di i b id Ri ht i i b i


Binären Relationen die in beide Richtungen navigierbar sein sollen, werden besser durch eigene Klasse Implementiert.

Klassendiagramm: Aggregation

„ist Teil von“-Beziehungkeine Aussage über Abhängigkeit des Teils vom Ganzeng g g

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

* *Pfad Segment

{ordered}

B A

C

Rotes Segment ist Teil


Rotes Segment ist Teil der Pfade AB und AC

Klassendiagramm: Komposition

„ist ausschließliches Teil von“-BeziehungLebensdauer des Teils endet mit Lebensdauer des GanzenLebensdauer des Teils endet mit Lebensdauer des GanzenBeispiel: Abteilungen können ohne Firma nicht existieren

1*

1..*0..1Firma

1..Abteilung


Klassendiagramm: Vererbung

"direkte" Darstellung Figur

KurveLinie Polygon

"zusammengefasste" Darstellung

FigurDarstellung

KurveLinie Polygon

Multiple Vererbung

yg

Student AngestellterEine Klasse mit mehreren Oberklassen Bsp: C++

Student Angestellter


Bsp: C++studentische Hilfskraft

UML, Statisches Modell: Utility-Klassen

<< utility >>Trigonometrie

Klassen ohne Instanzenhaben nur Klassen-Methoden / -AttributeUnterstreich ng ird eggelassen

gUnterstreichung wird weggelassenKursivschrift wird weggelassen

tangens(Arc) : Doublearctan(Double) : Arc

SinnKapselung prozeduraler BibliothekenF kti di i ht i ll i ...Funktionen, die nicht sinnvoll einem Objekt zugeordnet werden können

Mathematische Funktionen TrigonometrieDämon-Prozess

Utility-Notation ist mehr als nur

Trigonometrie

// diese Klasse besagt nicht // das gleiche wie obige!Utility Notation ist mehr als nur

Bequemlichkeitbesagt, dass hier nie Instanz-Methoden / Attribute hinzugefügt werden sollten

// das gleiche wie obige!

tangens(Arc) : Doublearctan(Double) : Arc


-Attribute hinzugefügt werden sollten arctan(Double) : Arc...

Objektdiagramme

Einheitliche Unterscheidung von Typen/Klassen und Instanzen in UMLDas Namensfeld einer Instanz ist unterstrichen und besteht aus:

Einem Namen für diese Instanz (optional)Einem Doppelpunkt als Trenner (zwingend)Dem Typ der Instanz (zwingend)

Die Attribute werden zusammen mit ihren jeweiligen Werten angegebenangegeben.

Eine benannte Instanz Eine anonyme Instanz von Tarif

tarif 1974:Tarif

von Tarif

:Tarif

y

tarif_1974:Tarif

zone2price = {{‘1’, .20},{‘2’, .40},

:Tarif


{‘3’, .60}}

Paketdiagramme

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

R f f i Kl i i d P kReferenz auf eine Klasse in einem anderen Packagepackage::class

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

Kunden

Kunde

Bank

KontoBank::Konto

Kunde

...

Konto

...

<<imports>>


Demo

Demo Together 2007 - Teil IInstallationshinweiseAllgemeiner ÜberblickAllgemeiner ÜberblickKlassendiagrammePaketdiagramme



3.2 UML Strukturdiagramme (2):Komponenten, Verteilungsdiagramme

Kompositionsstrukturdiagramme

KomponentendiagrammKomponenten in UMLKomponenten in UML

Eine Komponente ist ein modularer Teil eines SystemsDient zur Kapselung einer beliebig komplexen Struktur

In UML 2: kann sowohl physische als auch logische Modellierungsaspekte abdeckenIn UML 2: kann sowohl physische als auch logische Modellierungsaspekte abdecken

Komponentendiagramme…zeigen die Definition von Komponenten

und Abhängigkeiten zwischen diesen…und Abhängigkeiten zwischen diesen

Keine feste Trennung zwischen Komponenten und anderen Strukturdiagrammen!Komponenten können in Klassendiagrammen verwendet werden und vice versa

angebotenes Interface Komponenten-VerknüpfungEine von vielen Varianten

Camcorder tvin

micini Si l

palSignal SomeComponent

Eine von vielen Varianten

micinmicSignal

öffentlicher Port

b öti t I t fnicht-öffentlicher Port


…benötigtes Interface

Verteilungsdiagramme

Z i M d l / K t d dZeigen Module / Komponenten und deren……Verteilung auf Rechner…Kommunikation…Kommunikation…Angebotene und genutzte Interfaces…Sonstige Beziehungen untereinander

Abhängigkeits-Pfeile Zeigen von der abhängigen Komponente weg

KommunikationsbeziehungGeräteknoten Ausführungsumgebungsknoten

<<device>>calServer:Host<<device>>

calClient:PC

gg g g

ManifestationBeziehung zwischen logischen

<<execution Environment>>:J2EE Server

<<artifact>>

<<execution Environment>>

:BrowserVerteilung

Beziehung zwischen logischen Modellelementen und physischen Artefakten

<<artifact>>jdbc.jar<<deploy>>

Calendarium

VerteilungArtefaktPhysische Informationseinheit, z.b. Modell, Beschreibung

d S f


Calendarium.javaCalendarium

<<manifest>>oder Software

Verteilungs-Diagramme

Diabetes Unit-Server

:Health Care Domain :Object Database

TCP/IPRechner

<<communication>>


Liver Unit Server

ConnectionTCP/IPcommunication

Komponente/ M d l


/ Modul Interaktion / Kommunikation

:Liver Unit Configurationnutzt angebotene

Schnittstelle

:Configure Medical Knowledge

:Configure Users

:Liver Unit Server Application

Configuration

Schnittstelle


:Configure UsersApplication


3 2 UML Verhaltensdiagramme:3.2 UML Verhaltensdiagramme:Use-Case, Aktivitäts-, Zustandsdiagramme

Use-Case Diagramm

Use-Case Diagramme stellen die Funktionalität eines Systems aus Sicht des Benutzers dar.

SystemAnwendungsfall

(Use Case)

L Z it

y (Use Case)

Akteur

Uhr

LeseZeit Akteur

Uhrenträger Uhrmacher

SetzeZeit

TauscheBatterieRolle eines

Akteurs


Use-Case Diagramm: Elemente

EinsatzAnalysephase Kommunikation mit Auftraggeber / BenutzerKommunikation mit Auftraggeber / BenutzerErfassung von Anwendungsszenarien (Use Cases)

El t

Rolle eines Akteurs

BeispielElemente

Akteure

System

Use Cases name

salespersoncustomer

Annotationen place order...

Beziehungen

<<extend>> BA

<<include>>A BWhen placing an

order, ...


<<inherit>> BA

Use-Case Diagramm: Spezialisierungen

Kalender-Manager

Eintragerfassenerfassen

to-do-Eintragerfassen

Terminerfassen

Benutzer

E Mail System

Programmverwalten

erfassenerfassen

Kalender

«include»E-Mail System

includeZugriffsrechte

«extend»

Kalenderaktualisieren

Teilnehmer

«include»gverwalten

Einstellungenverwalten

«extend»

Verfeinerung und Strukturierung der Use Cases

verständigen Fax-Systemverwalten

Verfeinerung und Strukturierung der Use-Cases A «include» B: das Verhalten von B wird in A eingefügtB «extend» A: das Verhalten von B kann in A eingefügt werden


B ist Generalisierung von A: A erbt das gesamte Verhalten von B.

Use-Case Diagramm: Extension Points

Condition: (Zugriffsrechte ausgewählt)extension point: Zugriffsrechte anpassen

Notizen können Bedingungen und den Namen des extension

points enthalten

Programm verwalten

t i i t

Zugriffsrechteverwalten

«extend»

extension pointsZugriffsrechte anpassenEinstellungen anpassen

Einstellungenverwalten«extend»

Condition: (Einstellungen ausgewählt)extension point: Einstellungen anpassen

Extension Point

Extension points werden im zu erweiternden Use Case spezifiziert

Spezifikation

Beschreiben, wo der erweiternde Use Case einzufügen istNamen von erweiternden Use Cases müssen nicht mit extension points übereinstimmen


übereinstimmenNotizen bescheiben Bedingungen und den Namen des Extension points

Aktivitätsdiagramme

Spezifiziert den Kontroll- und Datenfluss zwischen ArbeitsschrittenIn UML 1.1: spezielle, ablauforientierte ZustandsdiagrammeUML 2 Lös ng om Z standsprin ip hin Abla forientierter SemantikUML 2: Lösung vom Zustandsprinzip, hin zu Ablauforientierter Semantik

Aktivität umfasst (atomare) Aktionen, Kontroll- und Datenflüsse

SynchronisierungAktionParallelisierung

Teilnehmer informieren

Kontaktpersonauswählen

Person ausgewählt

o e eTerminvorschlag

gefunden EntscheidungTerminvorschlag

finden

[Anzahl Teilnehmer ohne Kollision <90%][else]


[Anzahl Teilnehmer ohne Kollision 90%]Abbruch

Aktivitätsdiagramme: die wichtigsten Elemente

Name der Aktion

KnotenAktionStart- und Endknoten

InitialknotenAktivitätsendknotenAktivitätsendknotenAblaufendknoten, das Ende eines bestimmten Ablaufs

Alternative AbläufeAlternative AbläufeEntscheidungsknoten Vereinigungsknoten

Nebenläufige AbläufeParallelisierungsknotenSynchonisierungsknotenSynchonisierungsknoten


Zustandsdiagramme

button1&2Pressed button2Pressed IncrementBlink Hours

state Watch Startzustand

Ereignis

button1Pressed

b tton2Pressedb tt 1&2P d

HoursBlink Hours

ZustandTransition

Ereignis

button2Pressedbutton1&2Pressed IncrementMinutes

Blink Minutes

button1&2Pressed button2Pressed

button1Pressed

Blink Seconds IncrementStopSecondsBlinking

Endzustand

Beschreiben die Zustände von Objekten…Während ihres Lebenslaufs (Erzeugung bis Destruktion)


( g g )Während der Ausführung einer Operation oder Interaktion

Demo

Demo Together 2007 - Teil IIUse-Case DiagrammAkti itätsdiagrammAktivitätsdiagrammZustandsdiagramm



4.3 UML Verhaltensdiagramme (2):Sequenz- und KommunikationsdiagrammeZeit- und Interaktionsübersichtsdiagramme

Sequenzdiagramme

Objektesd Ticket

selectZone()

Passenger Objekt-Lebenslinien:TicketMachine

()

insertCoins()

Aktivierung

Benutzt während der AnforderungsanalysepickupChange()

insertCoins()

Benutzt während der Anforderungsanalyseum Use Case Beschreibungen zu verfeinernum zusätzliche Objekte zu finden

pickupChange()

pickUpTicket() j(“participating objects”)

Benutzt während des Systementwurfsum Subsystemschnittstellen zu verfeinern

pickUpTicket()

Nachrichten


Abläufe zu beschreiben

Sequenzdiagramme

sd Ticket

selectZone()

:Passenger:ZoneButton :TarifSchedule :Display

l k P i ( l ti )()

lookupPrice(selection)

displayPrice(price)

price

displayPrice(price)Datenfluss

Der Pfeil beginnt an der Aktivierung, welche die Nachricht gesendet hatEine Aktivierung dauert so lange wie alle geschachtelten Aktivierungeng g g gRückgaben geschehen implizit am Ende einer Aktivierung (für synchrone Nachrichten)Pfeile für Rückgaben werden nur benutzt um den Datenfluss explizit zu


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

Sequenzdiagramme: UML 1.1

sd MovieRental

:Customer :Rental :Movieinvoice()invoice()

totalCharge()

Iteration Bedingungen

*[for all rentals] charge()getPriceCode()g ()

totalBonusPoints()

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

Aktivitätsphase für Nachricht an sich selbst


Sequenzdiagramme: UML 2

sd MovieRental

:Customer :Rental :Movie

invoice()

totalCharge()alt [a]

Bedingung

getPriceCode()

loop(1,3)Alternative

[b]

Schleife

bonusPoints()getPriceCode()

[b]opt[c]

getPriceCode()

Optionale Interaktionenanalog dazu: break


analog dazu: break(einfaches Exception-Handling)

Sequenzdiagramme: UML2

Sequenzdiagramme in UML 2 enthalten weitere neue ElementeOperatoren für Filterungen und Zusicherungen

Ignore Consider AssertIgnore, Consider, AssertOperatoren für NebenläufigkeitInteraktionsreferenzuvm…

In dieser Vorlesung werden nur die Kernkonzepte vonIn dieser Vorlesung werden nur die Kernkonzepte von Sequenzdiagrammen verwendet

Hauptsächlich Elemente aus UML 1.1


Sequenzdiagramme: Fazit

Sequenzdiagramme……repräsentieren Verhalten bezüglich Interaktionen.

ergän en die Klassendiagramme elche die Str kt r repräsentieren…ergänzen die Klassendiagramme, welche die Struktur repräsentieren.…sind nützlich, um

beteiligte Objekte zu findenVerhalten präzise zu beschreibendas Verhalten eines Anwendungsfalls auf die beteiligten Objekte abzubilden

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 modellieren


Kollaborationsdiagramm

In UML1: KollaborationsdiagrammBeschreibt die notwendigen Operationen zwischen Interaktionspartnern

Strukturelle Sicht auf Abläufe

t [1] T iComm name


te[1]:Termin

1.1.1.1.1.a: beginn1 1 1 1 1 b: dauer

1.1.1.1[te[t] ≠ kandidat]: kollidiertMit(kandidat)1.1.1.1.1.b: dauer ( )

t [b] T il hk did t T i

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])


Kollaborationsdiagramm

In UML1: KollaborationsdiagrammBeschreibt die notwendigen Operationen zwischen Interaktionspartnern


t [1] T iComm name


InteraktionspartnerNachrichtenübermittlung

synchron

Typ der Rolle

te[1]:Termin

1.1.1.1.1.a: beginn1 1 1 1 1 b: dauer

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

asynchronName der Rolle

1.1.1.1.1.b: dauer ( )

Sequenznummern sequentiell

Sequenznummern nebenläufig

Selektor

t [b] T il hk did t T i

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]) Nachrichten


* Iteration *|| Nebenläufige Iteration [ … ] Bedingung

Demo

Demo Together 2007 - Teil IIISequenzdiagramm


Kapitel 4 Einführung in die Unified Modeling Language (UML) · zAktivitätsdiagramm/Activity...

Documents

Transcript of Kapitel 4 Einführung in die Unified Modeling Language (UML) · zAktivitätsdiagramm/Activity...