kapitel 3 die unified modeling language (uml) · uml-diagramm vhlt di usecase-diagramm...
Post on 06-Nov-2019
28 Views
Preview:
TRANSCRIPT
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-4 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-5 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-6 R O O T S
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.
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-7 R O O T S
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.
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-8 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-9 R O O T S
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,...
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-10 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-11 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-12 R O O T S
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 )
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-13 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-14 R O O T S
Bezug von UML zu gängigen OO Sprachen
C++C++
UML
sprachspezifische Details
Konzepte ohne direkter Entsprechung in
direkt ineinander abbildbarer
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-15 R O O T S
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!
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-16 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-17 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-18 R O O T S
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
KomponentendiagrammStrukturdiagramm
Kompositions-strukturdiagramm
VerteilungsdiagrammUML-Diagramm
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
Interaktions-übersichtsdiagramm
UML Diagrammtypen: Was wird wo erläutert? erläutert?
Klassendiagramm
Objektdiagramm
Klassendiagramm++
Objektdiagramm
Paketdiagramm
KomponentendiagrammStrukturdiagramm
Kompositions-strukturdiagramm
VerteilungsdiagrammUML-Diagramm
V h lt di
UseCase-Diagramm
Aktivitätsdiagramm
Z t d diVerhaltensdiagramm Zustandsdiagramm
Interaktionsdiagramm
Sequenzdiagramm
Kommunikations-diagrammIn diesem Kapitel
Zeitverlaufsdiagramm
Interaktions-übersichtsdiagramm
Im Kapitel „Objektentwurf“
Im Kapitel „Anforderungserhebung und Anforderungsanalyse“
Im Kapitel „Systementwurf“
Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U
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()
Klassendiagramme repräsentieren die Struktur eines Systems
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-26 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-27 R O O T S
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
Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-30 R O O T S
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
Klassendiagramme repräsentieren die Struktur eines Systems
jetzt()
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-31 R O O T S
Klassendiagramme repräsentieren die Struktur eines Systems
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-32 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-33 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-34 R O O T S
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>>
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-35 R O O T S
<<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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-36 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-37 R O O T S
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.
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-38 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-39 R O O T S
Klassendiagramm: 1 zu 1 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.
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-40 R O O T S
takatuka: Landillegal: hat keine Hauptstadt
Klassendiagramm: 1 zu N 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.
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-41 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-42 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-43 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-44 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-45 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-46 R O O T S
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“
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-49 R O O T S
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 }
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-50 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-51 R O O T S
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 *
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-52 R O O T S
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.
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-53 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-54 R O O T S
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()
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-55 R O O T S
ü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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-56 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-57 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-58 R O O T S
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>>
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-59 R O O T S
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>>
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-60 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-61 R O O T S
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>>
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-63 R O O T S
Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U
Demo „Together 2007 SP1“ (Teil 1)
InstallationÜberblick
KlassendigrammePaketdiagramme
Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U
3.4 Strukturdiagramme „im Großen“
Komponentendiagramme KapitelKompositionsübersichtsdiagrammeVerteilungsdiagramme
Kapitel „Systementwurf“
Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U
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}
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-72 R O O T S
Zeitpunkt erfüllt sein muss
Asynchrone Sequenzdiagramme: UML 1.1Asynchrone NachrichtAsynchrone Nachricht
Akti i
Objekt-Erzeugung
Aktivierung
Auslassung
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-73 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-74 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-76 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-79 R O O T S
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)
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-80 R O O T S
1 ||[für alle Teilnehmer tn[b]]:prüfe(tn[b])
Kommunikationsdiagramm( Communication diagram‘)
In UML1: Kollaborationsdiagramm(‚Communication diagram )
Beziehungen im Kommunikationsdiagrammt ti h A i tistatisch: Assoziationen
temporär: Parameter, lokale oder globale Variablen
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)
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-81 R O O T S
1 ||[für alle Teilnehmer tn[b]]:prüfe(tn[b])
Kommunikationsdiagramm( Communication diagram‘)
In UML1: Kollaborationsdiagramm(‚Communication diagram )
Objekt mit Rolle : Typ Selektor
Comm Prüfente[t]:Termin
Sequenznummer sequentiell
Sequenznummer nebenläufig
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)
sequentiellnebenläufig
1 1: hatKollision(kandidat)
Nachricht 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])
* 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
Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U
Demo Together 2007 SP1 (Teil 2)
Sequenzdiagrammeq gKommunikationsdiagramme
Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-87 R O O T S
[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]
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-88 R O O T S
[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)
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-89 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-90 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-91 R O O T S
gSynchonisierungsknoten
Aktivitätsdiagramme: die wichtigsten ElementeElemente
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-92 R O O T S
Explizit: … weg von der …Implizit: … rechts oder unten …
Aktivitätsdiagramme: die wichtigsten ElementeElemente
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-93 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-94 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-95 R O O T S
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]
prüfe Passwort(pwd)
ergebnis=prüfePaswort(pwd)
prüfe Passwort(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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-96 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-97 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-98 R O O T S
Geliefert
Zustandsdiagramm: Beispiel Bestellungsbearbeitung“ mit Abbruch„Bestellungsbearbeitung mit Abbruch
[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]
Warten
[Posten nicht verfügbar]
Abbruch AbbruchAbbruch
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-99 R O O T S
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
[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]
Warten
[Posten nicht verfügbar]
AbbruchGruppentransition
Unterbricht alle laufenden Aktionen des
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-100 R O O T S
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]
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-101 R O O T S
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]
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-102 R O O T S
[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]
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-103 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-104 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-105 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-106 R O O T S
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.
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-107 R O O T S
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,
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-108 R O O T S
,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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-109 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-110 R O O T S
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).
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-111 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-112 R O O T S
Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U
Demo „Together 2007 SP1“ (Teil 3)
AktivitätsdiagrammeZustandsdiagramme
Interaktionsübersichtdiagramme
Vorlesung „ Softwaretechnologie“Kapitel 3: UML R O O T Sap te 3 U
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
KomponentendiagrammStrukturdiagramm
Kompositions-strukturdiagramm
VerteilungsdiagrammUML-Diagramm
V h lt di
UseCase-Diagramm
Aktivitätsdiagramm
Z t d di
Stereotypen
Verhaltensdiagramm Zustandsdiagramm
Interaktionsdiagramm
Sequenzdiagramm
Kommunikations-diagrammIn diesem Kapitel
Zeitverlaufsdiagramm
Interaktions-übersichtsdiagramm
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-115 R O O T S
<<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>>
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-116 R O O T S
<<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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-117 R O O T S
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
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Seite 3-118 R O O T S
Sinvoll bei der Modellierung von zeitkritischemVerhalten, z.B. Echzeitsysteme
b: z8
top related