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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-3 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-4 R O O T S
– 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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-5 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-6 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-7 R O O T S
<<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>>
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-8 R O O T S
<<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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-9 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-10 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-12 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-13 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-14 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-15 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-16 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-17 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-18 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-19 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-20 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-21 R O O T S
-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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-22 R O O T S
{‘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>>
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-23 R O O T S
Demo
Demo Together 2007 - Teil IInstallationshinweiseAllgemeiner ÜberblickAllgemeiner ÜberblickKlassendiagrammePaketdiagramme
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-24 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Unified Modelling Language (UML) R O O T Sap te U ed ode g a guage (U )
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-26 R O O T S
…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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-27 R O O T S
Calendarium.javaCalendarium
<<manifest>>oder Software
Verteilungs-Diagramme
Diabetes Unit-Server
:Health Care Domain :Object Database
TCP/IPRechner
<<communication>>
:Health Care Domain :Object Database
Liver Unit Server
ConnectionTCP/IPcommunication
Komponente/ M d l
:Health Care Domain :Object Database
/ Modul Interaktion / Kommunikation
:Liver Unit Configurationnutzt angebotene
Schnittstelle
:Configure Medical Knowledge
:Configure Users
:Liver Unit Server Application
Configuration
Schnittstelle
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-28 R O O T S
:Configure UsersApplication
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Unified Modelling Language (UML) R O O T Sap te U ed ode g a guage (U )
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-30 R O O T S
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, ...
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-31 R O O T S
<<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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-32 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-33 R O O T S
ü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]
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-34 R O O T S
[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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-35 R O O T S
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)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-36 R O O T S
( g g )Während der Ausführung einer Operation oder Interaktion
Demo
Demo Together 2007 - Teil IIUse-Case DiagrammAkti itätsdiagrammAktivitätsdiagrammZustandsdiagramm
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-37 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 4: Unified Modelling Language (UML) R O O T Sap te U ed ode g a guage (U )
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-39 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-40 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-41 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-42 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-43 R O O T S
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-44 R O O T S
Kollaborationsdiagramm
In UML1: KollaborationsdiagrammBeschreibt die notwendigen Operationen zwischen Interaktionspartnern
Strukturelle Sicht auf Abläufe
t [1] T iComm name
Strukturelle Sicht auf Abläufe
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])
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-45 R O O T S
Kollaborationsdiagramm
In UML1: KollaborationsdiagrammBeschreibt die notwendigen Operationen zwischen Interaktionspartnern
Strukturelle Sicht auf Abläufe
t [1] T iComm name
Strukturelle Sicht auf Abläufe
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
Vorlesung Softwaretechnologie, Wintersemester 2007/8 04-46 R O O T S
* Iteration *|| Nebenläufige Iteration [ … ] Bedingung
Top Related