UML 2 Tutorial

Transcrição

UML 2 Tutorial

UML 2 Tutorial:
Einführung in die neue Standardmodellierungssprache
Mario Jeckle
Chris Rupp
Jürgen Hahn
Barbara Zengler
UML 2 Tutorial
Net.ObjectDays 2003
Seite 1
Darum geht´s
Präzisionssteigerung
Ideen
Übersichtlichkeit
Vorschläge
UML 2
Standardisierung
Roadmap
UML 2 Tutorial
Net.ObjectDays 2003
Ausführbarkeit
Abhängigkeiten
Seite 2
Metamodell
Praktischer
Einsatz
VerNeue
besserte
Diagramme
Diagramme
Was ist die UML?
logische
Sicht
Use Case - Sicht
Wunsch
des
Kunden
Deployment - Sicht
Requirements:
Das System soll mit
C++ realisiert werden
Bei Anfrage durch
einen Kunden muss die
Funktionalität sichergestellt
sein
Requirements & Use CaseBeschreibungen
...
Prozess - Sicht
ImplementierungsSicht
Datenmodell - Sicht
Notation für Modell des Systems
zeigt statische und dynamische Aspekte
Nicht jede Sicht in jedem System sinnvoll
UML 2 Tutorial
Net.ObjectDays 2003
Seite 3
UML ...
Geschichten von den fremden Meeren der Standardisierung
OML
Firesmith, HendersonSellers, Page-Jones; 1998
Unified Modeling Language v1.0
Booch, Jacobson, Rumbaugh;
1997
Catalysis
D’Souza, Willes; 1996
Unified Method
Booch, Rumbaugh; 1995
SOMA
Graham; 1994
MOSES
Henderson-Sellers; 1994
OBA
Rubin; 1992
BON
Nerson; 1992
OOA&D
Martin, Odell; 1992
OOA
Coad, Yourdan; 1991
SCOOP
Cherry; 1990
Fusion
Coleman, et al.;
1994
OOD
Booch; 1992
OMT
Rumbaugh, et al.; 1991
OOAD&I
Henderson-Sellers,
Macrone; 1992
OOSE
Jacobson; 1992
OSA
Embley; 1991
OOSA
Shlear, Mellor; 1991
RDD
Wirfs-Brock; 1990
HOOD
ESA; 1990
OBA
Bailin; 1989
Vom Methodenkrieg ...
UML 2 Tutorial
Net.ObjectDays 2003
State Charts
Harel; 1987
Seite 4
UML ...
Fragmentierung
Vereinheitlichung Standardisierung
Breiteneinsatz Erweiterung
Geschichten von den fremden Meeren der Standardisierung
OMG Unified Modeling Language 2.0
UML 2 Partners; unveröffentlicht
Viele arbeiten für alle
UML Partners; 2003
Erfahrungen
der Anwender
UML Partners; 2001
Object Management Group
übernimmt Copyright
UML Partners; 1999
Modeling Language 1.2 )
( OMG Unified
UML Partners; 1998
XML Metadata
Interchange
Einige arbeiten für andere
Unified Modeling Language 1.1
UML Partners; 9/1997
Integration der
Object Constraint Language Unified Modeling Language 1.0
UML Partners 1/1997
Unified Modeling Language 0.9, 0.91
Booch, Rumbaugh, Jacobson; 1996
Einsatzerfahrung
der Sprachschöpfer
Unified Method 0.8
Booch, Rumbaugh 1995
OMT
Rumbaugh, et al.; 1991
UML 2 Tutorial
OOD
Booch; 1992
Net.ObjectDays 2003
Wenige arbeiten für einige
OOSE
Jacobson; 1992
... zum Standardisierungskrieg
...
Seite 5
UML 2
... Warum eine neue Version?
Evolution
- Der Markt hat sich bewegt...
- Neue Programmiersprachen (z.B. C#, Python, PHP)
- Neue Anwendungsdomänen
(z.B. Serverprogrammierung, Echtzeitanwendungen)
Erfahrung
- Für einige Einsatzgebiete bietet UML v1.x ...
- Manchmal zu wenig Konstrukte
- Manchmal zu viele
- Machmal so viele, dass die sinnvolle
Auswahl schwerfällt
Eliminierung
- Einige Programmiersprachen verschwinden (z. B. C++)
- Einige früher als modellierungsnah eingestufte Konzepte
entwickeln sich inzwischen getrennt von UML weiter
(z. B. Entwicklungsprozesse, Codegenerierung)
UML 2 Tutorial
Net.ObjectDays 2003
Seite 6
UML ...
Ein Leiden am Second System Syndrom
UML 2 Tutorial
Net.ObjectDays 2003
Seite 7
UML 2
Die Ziele
Übersichtlichkeit
- Weniger graphische Modellkonstrukte
- Weniger Basiskonzepte
- Wiederverwendung von Basiskonzepten
Präzisionssteigerung
- Reformulierung des Meta-Modells
- Weitestgehende OCL-Verwendung
- Unveränderte Wiederverwendung von Basiskonstrukten soweit sinnvoll
möglich
Ausführbarkeit
- Erweiterte Zustandsmaschinen
- Stärkere Beziehungen zwischen statischen und dynamischen
Diagrammen
- Integration erprobter Konzepte außerhalb der UML
UML 2 Tutorial
Net.ObjectDays 2003
Seite 8
UML 2
Verrentung existierender Modellelemente
1. Durch UML-Werkzeuge nicht implementierte Sprachanteile
2. Durch OO-Methoden unberücksichtigte Sprachelemente
3. Programmiersprachen-spezifische Sprachelemente
4. Inpräzise UML-Sprachelemente
UML 2 Tutorial
Net.ObjectDays 2003
Seite 9
UML 2
1.
Durch UML-Werkzeuge nicht implementierte Sprachanteile
2.
Durch OO-Methoden unberücksichtigte Sprachelemente
3.
Programmiersprachen-spezifische Sprachelemente
4.
Inpräzise UML-Sprachelemente
SWE 1
System-Anforderungsanalyse und
-Entwurf
System
SWE 9
SystemEbene
System-Integration
Systemanforderungen
Systemarchitektur
Handbuchinformationen
Systemintegrationsplan
DV-Segment
SWE 2
SWE 8
DV-Anforderungsanalyse und -Entwurf
DV-Integration
SegmentEbene
DV-Anforderungen
DV-Architektur
DV-Integrationsplan
SWE 3
SW-Anforderungen
Implementierungsdok.
(SWKE)
SWKEIntegration
SW-Anforde
rungsanalyse
KonfigurationseinheitsEbene
SWKE
SWE 7
SW-Integration
(Komponente)
SWE 4
KomponentenIntegration
Grobentwurf
SW-Architektur
Schnittstellenentwurf
SWKE-Integrationsplan
KomponentenEbene
Komponente
(Modul)
SWE 5
Modul-/DatenbankDatenkatalog
SW-Entwurf
Ebene
Feinentwurf
(Datenbank)
Modul
SWE 6
Datenbank
Implementierung
Legende:
Prüfaktivitäten
(siehe QS)
Abb. 2.7 Funktionsüberblick Submodell SWE
UML 2 Tutorial
Net.ObjectDays 2003
Seite 10
UML 2
1.
2.
3.
4.
KlasseA
irgend : int
ein : bool
wichtiges : float
Element : byte
UML 2 Tutorial
Net.ObjectDays 2003
KlasseB
«friend»
Seite 11
noch : String
viel : short
wichtiger : float
UML 2
1.
2.
3.
4.
Objekt1 : KlasseA
irgend = 1
ein = true
wichtiges = 3.1
Element = 42
UML 2 Tutorial
Net.ObjectDays 2003
«copy»
«become»
Seite 12
Objekt2 : KlasseA
irgend = 1
ein = true
wichtiges = 3.1
Element = 42
UML 2
Neu: UML Schichten
Ebene 3
Complete
Ebene 2
Intermediate
Ebene 1
Basic
Ebene 0
Foundation
Die Idee entstammt der SQL-Standardisierung
Operationalisiert den Begriff der UML-Unterstützung
Auch weniger UML ist immer noch UML
UML 2 Tutorial
Net.ObjectDays 2003
Seite 13
Use-Case
Akivitätsdiagramm
x
Sequenzdiagramm
x
(noch nicht
eingeteilt)
Gewichtete Kanten, Streaming
x
(noch nicht
eingeteilt)
x
(noch nicht
eingeteilt)
Parallelität
(noch nicht
eingeteilt)
x
x
x
Anwendungsfall
Einfacher
Ablaufplan
Ablaufdiagramm
x
x
x
Grundlagen UseCases
Grundlagen
Aktivitäten
Grundlagen
Sequenzen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 14
...
complete
...
intermediate
...
basic
...
foundation
Struktur und Einbettung von UML
2
Unified Modeling Language 2.0
OCL
MOF2
Diagram
Interchange
Infrastructure
Statische
Anteile Dynamische
Anteile
überträgt
Superstructure
nutzt
UML ist nicht mehr eine monolithische Sprache
Vier seperate Entwicklungsgruppen werden vier seperate
Weiterentwicklungen mit starken inneren Zusammenhang erzeugen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 15
Struktur und Einbettung von UML 2
Verschiedene Weiterentwicklungsvorschläge:
- Infrastructure: 36 Lettern of Intents (LOIs);
5 Einreichungen durch 28 Firmen
- Superstructure: 37 LOIs;
- OCL: 30 LOIs; 4 Einreichungen durch 10 Firmen
- Diagram Interchange: 6 LOIs;
Eingereicht durch Einzelfirmen und Konsortien
Bezugnehmend auf einzelne Sprachaspekte der UML v1.x um diese
neu zu erweitern; Vorschläge für vollständig neue Diagrammtypen oder
die Abschaffung Existierender
UML 2 Tutorial
Net.ObjectDays 2003
Seite 16
Der Weg zu UML 2
Microsoft
Hewlett-Packard
Oracle
Sterling Software
MCI Systemhouse
Unisys
ICON Computing
Rational Software
0.9
Ericsson
IONA
Motorola
Telelogic
Boldsoft
Adaptive
Financial System
Architects
SUN
Gentleware
DaimlerChrylser
IntelliCorp
i-Logix
IBM
ObjecTime
Platinum
Technology
Alcatel
Ptech
Kabira
Taskon
Kennedy Carter
Reich Technologies
SOFTEAM
Computer Associates
1.1/2
1.3
1.4
1.5
1.0
OMG
EDS
Sterling Software
ICON Computing
ObjecTime
Platinum Technology
MCI Systemhouse
UML 2 Tutorial
2.0
Net.ObjectDays 2003
Seite 17
Microsoft
Hewlett-Packard
ICON Computing
IntelliCorp
Ptech
Taskon
Reich Technologies
Vorschläge zur UML 2
Einige komplexe Dinge sollten einfacher werden ...
UML 2 Tutorial
Net.ObjectDays 2003
Seite 18
Manchmal sagen Bilder einfach zu wenig ...
UML 2 Tutorial
Net.ObjectDays 2003
Seite 19
Superstructure und Infrastructure:
Ausgereiftester und mit breiter Unterstützung bedachter Vorschlag
durch die sog. „UML2 Partners“:
- Mitglieder:
Alcatel, Computer Associates, Ericsson, Hewlett-Packard, IONA,
Kabira Technologies, Motorola, Oracle, Rational Software,
SOFTEAM, Telelogic, and Unisys
- Unterstützer:
Advanced Concepts Center, Ceira Technologies, Compuware,
Commisariat à L´Energie Atomique, DaimlerChrysler, Embarcardero
Technologies, Enea Business Software, France Telecom, ...
UML 2 Tutorial
Net.ObjectDays 2003
Seite 20
UML 2.0 Ablaufplan
Ziel: Ein UML 2.0 Standard
Infrastructure RFP
Überarbeitete
Einreichung
Erste Einreichung
Annahme
Superstructure RFP
Überarbeitete
Einreichung
Erste Einreichung
Sep 00
UML 2 Tutorial
Apr 01
Net.ObjectDays 2003
Seite 21
Jun 01
Annahme
Aug 01
Okt 01
Jan 03
Apr 03
Dez 01
Feb 02
Sep 03
UML 2.0
Standardisierungsablauf
Komplexer Annahmeprozess
Bestätigung durch das
OMG Architecture Board
Jun 03
OMG Board of Directors
Okt 03 ?
OMG
Mitgliedsabstimmung
Sep 04 ?
angenommene
Spezifikation
gültige
Spezifikation
Ab diesem Zeitpunkt sind UML 2
Artikel, Bücher, Tools, ...
Wahrscheinlich zu erwarten
Sep 03 ?
Jun 04 ?
Okt 04 ?
OMG
Mitgliedsabstimmung
UML 2.0 Finalization
Task Force (FTF)
OMG Board of Directors
„offizieller“ Standard
(bis Oktober 2004 änderbar)
UML 2 Tutorial
Net.ObjectDays 2003
Seite 22
Diagramme der UML 2
Diagramme der
UML 2
Strukturdiagramme
Klassendiagramm
Komponentendiagramm
Kompositionsstrukturdiagramm
Verhaltensdiagramme
Objektdiagramm
Verteilungsdiagramm
Aktivitätsdiagramm
Paketdiagramm
Use-CaseDiagramm
Interaktionsdiagramme
Sequenzdiagramm
Interaktionsübersichtsdiagramm
Kommunikationsdiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 23
Zustandsautomat
Zeitverlaufsdiagramm
Wie hätten Sie´s denn gern?
Rational Unified Process
Arte
Agiles Vorgehen
XP
Crystal
OEP
EOS
ASD
Lean Software
Development
V-Modell
UML 2 Tutorial
Net.ObjectDays 2003
Spiralmodell
Unified Process
Seite 24
SCRUM
Entscheidungshilfe (1):
Gibt es Vorschriften?
Es gibt Vorschriften
Es haben freie Wahl
Was wird durch Ihre Umwelt erzwungen?
- Standardkonformität erforderlich zwecks
Freigabe des Systems (TÜV it, FDA,...)?
- Standard/Vorgehensmodell schreibt
gewisse Notation vor
- Zertifizierbarkeit des Systems
erforderlich?
Machen Sie das
Beste daraus!
Sie haben keine Wahl!
Allenfalls ergänzende Informationen
in anderen Notationen hinzufügen
und auf Vorschriften abbilden!
UML 2 Tutorial
Net.ObjectDays 2003
Seite 25
Entscheidunghilfe (2):
Akzeptanz von Formalität
Leser akzeptiert Formalismus
Was wünschen/ akzeptieren die
Stakeholder?
- Wie hoch ist die Motivation,
sich in Dokumente des
Entwicklungsprozesses zu
vertiefen?
- Welche Grundausbildung
haben die Betroffenen?
- Aufgeschlossenheit
gegenüber neuen Notationen
vorhanden?
- Starke Fixierung auf die alt
bekannte Methode?
UML 2 Tutorial
Net.ObjectDays 2003
Seite 26
Leser akzeptiert keinerlei
Formalismus
Prototypen jeglicher Art
(Lo-fi, Hi-fi)
Entscheiden Sie zwischen
„Lesbarkeit“, „Verständlichkeit“
auf der einen Seite und
„Prüfbarkeit“, „Automatisierbarkeit“ auf der anderen Seite.
Entscheidungshilfe (3):
Eignung für die Problemstellung
.... Jetzt kommt endlich die Fragen nach dem fachlichen Inhalt,
den ein Modell darstellt
UML 2 Tutorial
Net.ObjectDays 2003
Seite 27
Diagramme der UML und ihre
Anwendung I
Diagrammtyp
Diese zentrale Frage
beantwortet das Diagramm
Stärken
Klassendiagramm
Aus welchen Klassen besteht mein
System und wie stehen diese
untereinander in Beziehung?
Beschreibt die statische Struktur des
Systems.
Enthält alle relevanten Strukturzusammenhänge/Datentypen.
Brücke zu dynamischen Diagrammen.
Normalerweise unverzichtbar.
Paketdiagramm
Wie kann ich mein Modell so
schneiden, dass ich den Überblick
bewahre?
Logische Zusammenfassung von
Modellelementen.
Modellierung von Abhängigkeiten/
Inklusion möglich.
Objektdiagramm
Welche innere Struktur besitzt mein
System zu einem
bestimmten Zeitpunkt zur Laufzeit
(Klassendiagrammschnappschuss)?
Zeigt Objekte u. Attributbelegungen zu
einem bestimmten Zeitpunkt.
Verwendung beispielhaft zur
Veranschaulichung
Detailniveau wie im Klassendiagramm.
Sehr gute Darstellung von
Mengenverhältnissen.
UML 2 Tutorial
Net.ObjectDays 2003
Seite 28
Anwendung II
Diagrammtyp
Stärken
Wie sieht das Innenleben einer
Klasse, einer Komponente,
eines Systemteils aus?
Ideal für die Top-Down-Modellierung
des Systems (Ganz-Teil-Hierarchien).
Zeigt Teile eines „Gesamtelements“
und deren Mengenverhältnisse.
Präzise Modellierung der TeileBeziehungen über spezielle
Schnittstellen (Ports) möglich.
Komponentendiagramm
Wie werden meine Klassen zu
wieder verwendbaren, verwaltbaren
Komponenten zusammengefasst
und wie stehen diese in
Beziehung?
Zeigt Organisation und Abhängigkeiten einzelner technischer
Systemkomponenten.
Modellierung angebotener und
benötigter Schnittstellen möglich.
Verteilungsdiagramm
Wie sieht das Einsatzumfeld
(Hardware, Server, Datenbanken,
…) des Systems aus? Wie werden
die Komponenten zur Laufzeit
wohin verteilt?
Zeigt das Laufzeitumfeld des Systems
mit den „greifbaren“ Systemteilen.
Darstellung von „Softwareservern“
möglich.
Hohes Abstraktionsniveau, kaum
Notationselemente.
UML 2 Tutorial
Net.ObjectDays 2003
Seite 29
Anwendung III
Diagrammtyp
Stärken
Use-Case-Diagramm
Was leistet mein System für seine
Umwelt (Nachbarsysteme,
Stakeholder)?
Außensicht auf das System.
Geeignet zur Kontextabgrenzung.
Hohes Abstraktionsniveau, einfache
Notationsmittel.
Aktivitätsdiagramm
Wie läuft ein bestimmter flussorientierter Prozess oder ein
Algorithmus ab?
Sehr detaillierte Visualisierung von
Abläufen mit Bedingungen, Schleifen,
Verzweigungen.
Parallelisierung und Synchronisation.
Darstellung von Datenflüssen.
Zustandsautomat
Welche Zustände kann ein Objekt,
eine Schnittstelle, ein Use Case, …
bei welchen Ereignissen
annehmen?
Präzise Abbildung eines Zustandsmodells mit Zuständen, Ereignissen,
Nebenläufigkeiten, Bedingungen,
Ein- und Austrittsaktionen.
Schachtelung möglich.
Wer tauscht mit wem welche
Informationen in welcher
Reihenfolge aus?
Darstellung d. Informationsaustauschs
zwischen Kommunikationspartnern
Sehr präzise Darstellung der zeitlichen
Abfolge auch mit Nebenläufigkeiten.
UML 2 Tutorial
Net.ObjectDays 2003
Seite 30
Anwendung IV
Diagrammtyp
Stärken
Wer kommuniziert mit wem? Wer
„arbeitet“ im System
zusammen?
Stellt den Informationsaustausch
zwischen Kommunikationspartnern
dar.
Überblick steht im Vordergrund
(Details und zeitliche Abfolge weniger
wichtig).
Timingdiagramm
Wann befinden sich verschiedene
Interaktionspartner in welchem
Zustand?
Visualisiert das exakte zeitliche
Verhalten von Klassen,Schnittstellen,..
Geeignet für die Detailbetrachtungen,
bei denen es wichtig ist, dass ein
Ereignis zum richtigen Zeitpunkt
eintritt.
Wann läuft welche Interaktion ab?
Verbindet Interaktionsdiagramme
(Sequenz-, Kommunikation- und
Timingdiagramme) auf Top-LevelEbene.
Hohes Abstraktionsniveau.
UML 2 Tutorial
Net.ObjectDays 2003
Seite 31
UML 2 –
Die Strukturdiagramme
Barbara Zengler
Mario Jeckle
www.uml-glasklar.de
UML 2 Tutorial
Net.ObjectDays 2003
Seite 32
Zwei Dinge sind zu unserer Arbeit nötig:
Unermüdliche Ausdauer und die
Bereitschaft, etwas, in das man viel Zeit
und Arbeit gesteckt hat, wieder
wegzuwerfen.
Albert Einstein
UML 2 Tutorial
Net.ObjectDays 2003
Seite 33
Diagramme der UML 2
Diagramme der
UML 2
Strukturdiagramme
Klassendiagramm
Komponentendiagramm
Verhaltensdiagramme
Objektdiagramm
Verteilungsdiagramm
Aktivitätsdiagramm
Paketdiagramm
Use-CaseDiagramm
Sequenzdiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 34
Zustandsautomat
Die Strukturdiagramme
Klassendiagramm
Eine Zusammenstellung deklarativ-statischer
Modellelemente (d.h. Klassen, Typen,
ihre Inhalte und Beziehungen)
Objektdiagramm
Enthält Objekte und Beziehungsausprägungen
Paketdiagramm
Stellt die logische Organisation von Modellelementen und deren
Abhängigkeiten dar
Komponentendiagramm
Zeigt die Organisation und Abhängigkeiten von Komponenten
Zeigt die interne Struktur eines classifiers sowie seine
Möglichkeiten zu Interaktion mit anderen Systemkomponenten
Verteilungsdiagramm
Zeigt die Ausführungssicht des Systems
Strukturdiagramme
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 35
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Warum neue oder geänderte
Strukturdiagramme?
Strukturdiagramme
Hintergrund
Statische Modellierung seit Mitte der 1970er
Jahre gängig und hinreichend erforscht
(z.B. Entity-Relationship)
Darstellung nicht ausführbarer statischer Zusammenhänge
durch die ersten OO-Modellierungssprachen (u.a. Boochs
OOSE, Rumbaughs OMT) weidlich bearbeitet
Strukturdiagramme (insbesondere Klassendiagramme)
ausgereiftester und stabilster Teil der UML v1.x
Jüngere Entwicklungstrends, die eine Neufassung rechtfertigen
Metamodellierung
Konzeptionelle Bereinigung
Wiederverwendung von bestehenden Konstrukten
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 36
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Änderungen an den
Strukturdiagrammen!?
Statische Diagramme besitzen in der UML und ihrer
Anwendung eine hervorgehobene Bedeutung
Bekanntester Diagrammtyp
Meistverwendester Diagrammtyp
Basis des UML-Metamodells
Basis des UML-Metametamodells (Meta Object Facility)
Änderungen
„automatisch“ sehr sichtbar
für den UML-Anwender „spürbar“
beeinflussen u.U. gesamtes Sprachkonzept
wirken sich auf andere (Meta-)Sprachen aus
Inhärente Bedeutung für den Modellaustausch zwischen
Werkzeugen (XMI-Format wird aus Metamodell generiert)
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 37
Strukturdiagramme
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Statische Diagramme der UML 2
Diagramme der
UML 2
„wichtigster“ Diagrammtyp
Strukturdiagramme
Klassendiagramm
meist-geänderter Diagrammtyp
Komponentendiagramm
Verhaltensdiagramme
Objektdiagramm
Verteilungsdiagramm
Aktivitätsdiagramm
Paketdiagramm
Use-CaseDiagramm
Sequenzdiagramm
Klassendiagramm
Komponentendiagramm
5%
15%
45%
Objektdiagramm
19%
7%
9%
Verteilungsdiagramm
Paketdiagramm
neuer Diagrammtyp
UML 2 Tutorial
Net.ObjectDays 2003
Seite 38
Zustandsautomat
Basiskonzepte
Strukturdiagramme
Die UML-Basiskonzepte sind
Abstraktion
Typisierung und Identität
Strukturierung
(d.h. gekapselte Eigenschaften und vielfältige Beziehungen)
Erweiterbarkeit der Sprache
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 39
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Basiskonzepte
Strukturdiagramme
Abstraktion
Strukturierung
Klassendiagramm
Komponentendiagramm
UML 2 ...
Erweitert die Nutzung der Classifier
Vereinheitlicht ähnliche Konzepte unter gemeinsamen
Oberbegriffen
Bietet neue Diagrammtypen und -sichten
UML 2 Tutorial
Net.ObjectDays 2003
Seite 40
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Basiskonzepte -- Abstraktion
Strukturdiagramme
UML 2 ...
Oberbegriffen
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Classifier
DataType
PrimitiveType
Signal
Enumeration
Class
(from Kernel)
Association
CommunicationPath
AssociationClass
Activity
Actor
Behavior
Artifact
InformationItem
Interface
BehavioredClassifier
Class
(from Communications)
UseCase
Net.ObjectDays 2003
Collaboration
StateMachine
Class
(from StructuredClasses)
ProtocolStateMachine
Node
Interaction
Device
UML 2 Tutorial
StructuredClassifier
Seite 41
EncapsulatedClassifier
ExecutionEnvironment
Strukturdiagramme
UML 2 ...
Beziehungen (Assoziationen) werden zwischen ihnen geknüpft
... können Charakteristika (Attribute) besitzen
... können Verhaltensspezifikationen (Operationen) besitzen
... können generalisiert werden
... können autonom auf Signale reagieren
... können ausschließlich der Strukturierung dienen (abstract)
Klassendiagramm
Komponentendiagramm
Classifier
DataType
PrimitiveType
Signal
Enumeration
Class
(from Kernel)
Association
CommunicationPath
AssociationClass
Activity
Behavior
Interaction
Actor
Artifact
InformationItem
Interface
Class
UseCase
Collaboration
StateMachine
Class
Node
Device
UML 2 Tutorial
Net.ObjectDays 2003
Seite 42
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Strukturdiagramme
UML 2 ...
Oberbegriffen
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Beispiel:
Artefakt kann beliebige paktierbare Elemente „manifestieren“
myWebApp
«artifact»
.xml
.html
.class
.jsp
«manifest»
myApp.war
Anwendung:
Deployment von Webapplikationen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 43
Paketdiagramm
Strukturdiagramme
UML 2 ...
Oberbegriffen
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Beispiel:
Zeigt die interne Struktur eines Classifiers sowie seine
Möglichkeiten zu Interaktion mit anderen Systemkomponenten
UML 2 Tutorial
Net.ObjectDays 2003
Seite 44
Paketdiagramm
Basiskonzepte
Strukturdiagramme
Abstraktion
Strukturierung
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
UML 2 ...
Verhältnis zwischen Classifier und typisierten Elementen
klarer gefasst
Unterschied zwischen „typisiert sein“ und „Typ sein“ verwirklicht
Identitätsverhalten geklärt
(Insbesondere bei dynamischer Verarbeitung statischer Daten)
UML 2 Tutorial
Net.ObjectDays 2003
Seite 45
Basiskonzepte –
Strukturdiagramme
UML 2 ...
Verhältnis zwischen Classifier und
typisierten Elementen klarer gefasst
Klassendiagramm
Komponentendiagramm
UML 1.x
Element
Element
ModelElement
NamedElement
name
name
Namespace
GeneralizableElement
Classifier
UML 2 Tutorial
Net.ObjectDays 2003
TypedElement
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
UML 2
Type
Classifier
Seite 46
Basiskonzepte –
Strukturdiagramme
UML 2 ...
Verhältnis zwischen Classifier und
typisierten Elementen klarer gefasst
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
UML 2 ...
Identitätsbesitz ist nicht mehr statisch über die gesamte
Lebensdauer
Identitätsbehaftete Objekte können durch dynamische Aktivitäten
ihre Identität verlieren oder wechseln
Teilweise (beispielsweise in Kollaborationen) ist sie sogar
unerheblich
UML 2 Tutorial
Net.ObjectDays 2003
Seite 47
Basiskonzepte
Strukturdiagramme
Abstraktion
Strukturierung
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
UML 2 ...
Assoziationen zur Formulierung von Beziehungen zwischen
Classifier-Ausprägungen
(viele (unnötige) Einschränkungen) entfallen (z.B. Anwendung auf Use-Cases))
Generalisierungen zur Hierarchisierung von Classifiern
(Damit sind z.B. Pakete nicht mehr naiv generalisierbar, hierfür existiert ein separiertes „merge“-Konzept)
Abhängigkeitsbeziehungen dokumentieren logische
Wechselwirkungen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 48
Basiskonzepte -- Strukturierung
Strukturdiagramme
UML 2 ...
Assoziationen zur Formulierung von
Beziehungen zwischen Classifier-Ausprägungen
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Wechselwirkungen
Konstruktion
Konstrukteur
Änderungswunsch entgegennehmen
Kundenbetreuer
UML 2 Tutorial
Net.ObjectDays 2003
Seite 49
Strukturdiagramme
UML 2 ...
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Wechselwirkungen
Kund
enbe
treue
r
Konstruktion
Konstrukteur
Änderungswunsch entgegennehmen
Kundenbetreuer
UML 2 Tutorial
Net.ObjectDays 2003
Seite 50
Strukturdiagramme
UML 2 ...
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Wechselwirkungen
Generalization
1 general
isSubstitutable
Classifier
*
specific
Alle Classifier-Spezialisierungen sind nun spezialisierbar
Substituierbarkeit expliziert
UML 2 Tutorial
Net.ObjectDays 2003
Seite 51
Der Classifier-Zoo
Classifier
DataType
PrimitiveType
Signal
Enumeration
Class
(from Kernel)
Association
CommunicationPath
AssociationClass
Activity
Actor
Behavior
Artifact
InformationItem
Interface
Class
UseCase
Collaboration
StateMachine
Class
Node
Interaction
Device
Net.ObjectDays 2003
Seite 52
Alle Classifier-Spezialisierungen sind nun spezialisierbar
UML 2 Tutorial
Strukturdiagramme
UML 2 ...
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
«stereotype»
Wechselwirkungen
xml
«metaclass»
Klasse
«persistent, xml»
Partyteilnehmer
«stereotype»
persistent
«persistent»
Gastgeber
Neue Notation (genaugenommen gibt es erstmals eine)
Programmiersprachenspezifische Abhängigkeiten entfallen
z.B. C++-spezifisches „friend“
UML 2 Tutorial
Net.ObjectDays 2003
Seite 54
Klassendiagramm --Das „wichtigste“ Diagramm
Strukturdiagramme
Komponentendiagramm
Klassendiagramm
Objektdiagramm
Verteilungsdiagramm
KlassendiagrammPaketdiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 55
Klassendiagramm
Strukturdiagramme
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Funktion:
Klassendiagramm
Zusammenstellung deklarativ-statischer
Modellelemente (d.h. Klassen, Typen, ihre Inhalte und Beziehungen)
Verteilungsdiagramm
Aufgabe im Projekt:
Variierend ...
von der ersten Darstellung konzeptueller Dateninhalte
über plattformunabhängige logische Modelle
bis hin zu „Implementierungsbauplänen“
(„Bilder-für-Java“, „Kästchen-und-Strichchen-statt-C++“)
Ersetzt oftmals das klassische, in Entity Relationship-Notation
abgefasste, Datenmodell
UML 2 Tutorial
Net.ObjectDays 2003
Seite 56
Paketdiagramm
Klassendiagramm
Klasse
Komposition
Strukturdiagramme
Klassenname
Aggregation
abstrakte Klasse
Feier
Zutat
+termin : Datum
Klassendiagramm
+name : String
abbrechen()
Rolle
Cocktail
*
0..*
Häppchen
Zutaten : Zutat [1..*]
isst {ordered}
Partyteilnehmer
«interface»
Esser
/betrunken : Boolean = false
~intus : Cocktail [1..*]
#begeistert : Begeisterung
1..*
iss(in h : Häppchen; return satt:Boolean)
#überdenkeBegeisterung()
~trinke(in c : Cocktail)
mixt
Barmixer
Schnittstelle
Generalisierung
+mixe(in z : Zutat [1..*], out c:Cocktail)
1
Esser
Gast
1..*
verabschiedet
{unique}
empfängt
{unique}
1..*
mixt für
Esser
Eigenschaftswert
Gastgeber
Stereotyp
treibt an
hektisch : Boolean = true
1..1
feiere()
Attribut
Operation
Multiplizität
gerichtete Assoziation
UML 2 Tutorial
Net.ObjectDays 2003
«enumeration»
Begeisterung
begruesse(in g : Gast)
verabschiede (in g : Gast)
treibeAn(in b : Barmixer)
Assoziation
Seite 57
Objektdiagramm
VerteilungsPaketdiagramm
Klassendiagramm
diagramm
unterhält
besucht
Komponentendiagramm
ekstatisch
verzückt
neutral
gelangweilt
überdrüssig
Klassendiagramm
Klasse
Komposition
Strukturdiagramme
Klassenname
Aggregation
Klasse
abstrakte Klasse
Feier
Zutat
+termin : Datum
Klassendiagramm
+name : String
Komponentendiagramm
Objektdiagramm
Klassendiagramm
diagramm
unterhält
abbrechen()
Rolle
Cocktail
Sichtbarkeit name (Richtung Name : Typ [Multiplizität]=Vorgabe {Eigenschaft=Wert}) : Rückgabetyp {Eigenschaft=Wert}
besucht
*
0..*
Häppchen
Zutaten : Zutat [1..*]
isst {ordered}
Partyteilnehmer
«interface»
Esser
/betrunken : Boolean = false
~intus : Cocktail [1..*]
#begeistert : Begeisterung
1..*
[1..3]
iss(in h : Häppchen; return satt:Boolean)
#überdenkeBegeisterung()
~trinke(in c : Cocktail)
mixt
Barmixer
Schnittstelle
Generalisierung
+mixe(in z : Zutat [1..*], out c:Cocktail)
1
Esser
Gast
1..*
verabschiedet
{unique}
empfängt
{unique}
1..*
mixt für
Esser
Eigenschaftswert
Gastgeber
Sichtbarkeit
/ name Stereotyp
: Typ [Multiplizität] = Vorgabewert {Eigenschaft=Wert}
treibt an
hektisch : Boolean = true
1..1
feiere()
Attribut
Operation
Net.ObjectDays 2003
«enumeration»
Begeisterung
begruesse(in g : Gast)
verabschiede (in g : Gast)
treibeAn(in b : Barmixer)
Multiplizität
gerichtete Assoziation
UML 2 Tutorial
Klasse
Assoziation
Seite 58
ekstatisch
verzückt
neutral
gelangweilt
überdrüssig
Klassendiagramm
Strukturdiagramme
Klassendiagramm
Neu in UML 2:
Komponentendiagramm
Objektdiagramm
Klassendiagramm
diagramm
Klasse1
«Abhängigkeitsname»
Klasse2
Klasse3
Klasse5
Klasse4
Klasse6
Kommentar zur
Abhängigkeitsbeziehung
UML 2 Tutorial
Net.ObjectDays 2003
Seite 59
Klassendiagramm
Strukturdiagramme
Komponentendiagramm
Neu in UML 2:
Klassendiagramm
- Attribute besitzen Ordnung
- Graphische Assoziationsnotation
(Nutzung des „großen leeren Diamanten“auch für binäre Assoziationen)
- Kommentarnotation „mit Punkt“
Geändert in UML 2:
- Graphische Schnittstellennotation (Lollipops) jetzt Standard
- Spezifikation von Sichtbarkeit, Name, Typ und Multiplizität für Operationen
und Attribute vereinheitlicht
- Multiplizitätsdefinition schärfer formuliert
- Attribute sind keine implizite Kompositionsassoziation mehr
Entfällt in UML 2:
- Programmiersprachenmanifestationsspezifische Eigenschaften
(z.B. friend)
- Eigenschaften und Stereotypen unklarer Semantik
(z.B. become und copy)
Klassendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 60
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Kompositionsstrukturdiagramm --Ein neues Diagramm in UML 2
Strukturdiagramme
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Objektdiagramm
Verteilungsdiagramm
Seite 61
Paketdiagramm
Strukturdiagramme
Funktion:
Zeigt die interne Struktur eines Classifiers
sowie seine Möglichkeiten zu Interaktion mit
anderen Systemkomponenten
Klassendiagramm
Komponentendiagramm
Aufgabe im Projekt:
Beschreibung von extern angebotenen Schnittstellen
Abstraktion der Operationen und des Signals
UML 2 Tutorial
Net.ObjectDays 2003
Seite 62
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Strukturdiagramme
Basiskonzepte:
Part
Port
Kollaboration
Konnektor
Rollenverwendung
UML 2 Tutorial
Net.ObjectDays 2003
Klassendiagramm
Komponentendiagramm
Seite 63
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Strukturdiagramme
Basiskonzepte:
Part
Objekte oder Rollenausprägungen
Port
Öffentlich sichtund zugreifbarer Interaktionspunkt, der auf einen
Operationsaufruf oder den Empfang eines Signals reagiert
Kollaboration
Zusammenspiel von Operationen oder Classifiern
Konnektor
Assoziationsinstanz (Link), die Kommunikation zwischen
(allgemeinen) Instanzen ermöglicht
Rollenverwendung
Bindet realisierende Classifier an Kollaborationsinstanz
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 64
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Strukturdiagramme
Neu in UML 2:
Port: Definiert einen öffentlich sichtund zugreifbaren Interaktionspunkt, der
auf einen Operationsaufruf oder den Empfang eines Signals
reagiert.
Klassendiagramm
Komponentendiagramm
bereitgestellteSchnittstelle
Klasse
Verteilungsdiagramm
Paketdiagramm
partybeschallung
Stereoanlage
benötigteSchnittstelle
UML 2 Tutorial
Objektdiagramm
Net.ObjectDays 2003
Seite 65
strom, medium
Strukturdiagramme
Neu in UML 2:
Port: Werden durch andere Classifier
oder Ports angesprochen.
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Musikerzeugung
Stereoanlage
kabel
: Steckdose
Konnektor
Musikerzeugung
Konnektor
Stereoanlage
UML 2 Tutorial
Net.ObjectDays 2003
Seite 66
transformator
: Hamsterrad
Strukturdiagramme
Neu in UML 2:
Behavior Port:
Wie Port, allerdings
mit der Einschränkung, dass der
definierende Classifier das Verhalten selbst manifestieren
muss, andernfalls ist die empfangende Botschaft oder das
empfangene Signal verloren.
Kann Sichtbarkeits- und Zugriffsbeschränkt sein.
Klassendiagramm
Komponentendiagramm
partybeschallung
Stereoanlage
strom, medium
UML 2 Tutorial
Net.ObjectDays 2003
Seite 67
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Strukturdiagramme
Überarbeitet in UML 2:
Kollaboration: Visualisiert das
Zusammenspiel von Operationen oder
Classifiern
UML 2 Tutorial
Net.ObjectDays 2003
Seite 68
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Strukturdiagramme
Kollaboration: Visualisiert das
Zusammenspiel von Operationen oder
Classifiern
UML 2 Tutorial
Net.ObjectDays 2003
Seite 69
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Strukturdiagramme
Beispiel:
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 70
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Strukturdiagramme
Beispiel:
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 71
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Strukturdiagramme
Neu in UML 2:
- Der gesamte Diagrammtyp
- Ports als gemeinsame Abstraktion
von Operationen und Signalen
- Auffassung von Kollaborationen als Teile von
Kompositionsstrukturen
Klassendiagramm
Komponentendiagramm
Verteilungsdiagramm
Geändert in UML 2:
- Schnittstellennotation
- Möglichkeiten zur Darstellung von Kollaborationen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 72
Objektdiagramm
Paketdiagramm
Verteilungsdiagramm --Das Diagramm mit den meisten Änderungen
Strukturdiagramme
Verteilungsdiagramm
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Objektdiagramm
Verteilungsdiagramm
Seite 73
Paketdiagramm
Verteilungsdiagramm
Strukturdiagramme
Verteilungsdiagramm
Funktion:
Zeigt die Ausführungssicht des Systems
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Aufgabe im Projekt:
Beschreibung der Systemarchitektur
Erweitert Systemsicht um an der Ausführung beteiligte oder zur
Ausführung benötigte Hardwarekomponenten
UML 2 Tutorial
Net.ObjectDays 2003
Seite 74
Verteilungsdiagramm
Strukturdiagramme
Verteilungsdiagramm
Basiskonzepte:
Artefakt
Physische Informationseinheit, die während
des Entwicklungsprozesses erzeugt oder
verwendet wird.
(z.B. Modelle, Quellcode, Objekdateien, ...)
Knoten
Classifier, der eine zur Ausführungszeit verfügbare Ressource
darstellt.
Einsatzspezifikation (Deployment Specification)
Paramtermenge, die Laufzeitverhalten festlegt
Klassendiagramm
Komponentendiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 75
Objektdiagramm
Verteilungsdiagramm
Paketdiagramm
Verteilungsdiagramm
Strukturdiagramme
Verteilungsdiagramm
Knoten
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Artefakt
«device»
: Application Server
«artifact»
«execution environment»
J2EE
Server
: J2EE
Server
«deploy»
application.jar
entry.jsp
config.xml
MyBean.class
Deployment-Beziehung
1..*
1..*
Assoziation
execution : thread
transaction : false
«device»
: DB Server
Deployment-Spezifikation
UML 2 Tutorial
Net.ObjectDays 2003
«deployment spec»
appDesc.xml
Seite 76
Verteilungsdiagramm
Paketdiagramm
Verteilungsdiagramm
Strukturdiagramme
Verteilungsdiagramm
Neu in UML 2:
- Aktuelle Ausführungs- und
Laufzeitumgebungen wie J2EE und .NET
werden besser berücksichtigt
Klassendiagramm
Komponentendiagramm
Objektdiagramm
Verteilungsdiagramm
Geändert in UML 2:
- Knoten können hinsichtlich ihrer Rollen zum Ausführungszeitpunkt
feinspezifiziert werden
- Ausdetaillierung der Abhängigkeitsbeziehungen
Entfällt in UML 2:
- Unpraktikable graphische Darstellung des Knotens
UML 2 Tutorial
Net.ObjectDays 2003
Seite 77
Paketdiagramm
Fazit --statische Diagramme in UML 2
Absichtsvoll wenig „spürbar“ Neues
- Im Hintergrund
- Klarere Basiskonzepte
- Deutlich mehr Wiederverwendung
- Fast vollständig neues Metamodell
Modifizierte Semantik vieler (Meta-)Modellelemente
Einige neue graphische Primitive
Reichhaltigeres Angebot an Abhängigkeiten und
„eingebauten“ Modellerweiterungen (Stereotypen)
Behutsame Verrentung „problematischer“ Modellelemente
UML 2 Tutorial
Net.ObjectDays 2003
Seite 78
UML 2 –
Die Verhaltensdiagramme
Chris Rupp
Jürgen Hahn
www.uml-glasklar.de
UML 2 Tutorial
Net.ObjectDays 2003
Seite 79
Diagramme der UML 2
Diagramme der
UML 2
Strukturdiagramme
Klassendiagramm
Komponentendiagramm
Verhaltensdiagramme
Objektdiagramm
Verteilungsdiagramm
Aktivitätsdiagramm
Paketdiagramm
Use-CaseDiagramm
Sequenzdiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 80
Zustandsautomat
Use-Case-Diagramm
„Die Neugier steht immer an erster Stelle eines
Problems, das gelöst werden will.“
Galileo Galilei
UML 2 Tutorial
Net.ObjectDays 2003
Seite 81
Use-Case-Diagramm
Anwendung im Projekt
Darstellung der funktionalen Dienstleistungen eines Systems
Abgrenzung des Systems gegenüber seiner Umwelt
Aufteilen des Systems aus einer Außensicht
Erstellung planbarer Einheiten
Schaffen einer Kommunikationsgrundlage zwischen
Stakeholdern
UML 2 Tutorial
Net.ObjectDays 2003
Seite 82
Use-Case-Diagramm
Die Elemente im Überblick
System
Anwendungsfall
Benutzer
Use-Case
Beziehung
UML 2 Tutorial
Subject
Akteur
«include»
«extend»
«include»-Beziehung
«extend»-Beziehung
Net.ObjectDays 2003
Seite 83
Generalisierungsbeziehung
Use-Case-Diagramm
Use-Case:
- spiegelt ein funktionales Verhalten wieder
- wird durch Akteur angestoßen
- liefert ein für den Akteur sichtbares Ergebnis
Akteur:
- beschreibt eine Rolle
- steht außerhalb des Systems
- interagiert mit dem System
- kann eine Person, ein Nachbarsystem, .... sein
UML 2 Tutorial
Net.ObjectDays 2003
Seite 84
Use-Case-Diagramm
System (Betrachtungsgegenstand):
- Umgrenzt die Einheit, welche die Use-Cases realisiert
- Darstellung ist nicht zwingend notwendig
Assoziationen:
- beschreiben die Beziehungen zwischen Akteuren und UseCases
- «Extend»-Beziehung: Verhalten eines Use-Case kann durch
einen anderen erweitert werden
- «Include»-Beziehung: Verhalten eines Use-Case ist
vollständig in einem anderen enthalten
UML 2 Tutorial
Net.ObjectDays 2003
Seite 85
Use-Case-Diagramm
Die Anwendung
Systemname
Use-Case
Akteur
Systemgrenze
Verkauf
Kunde nicht
gefunden
Verkaufsposten
eingeben
«extend»
ExtendBeziehung
extension points:
fehlender Kunde
Verkäufer
«include»
Assoziation
UML 2 Tutorial
Net.ObjectDays 2003
Kreditwürdigkeit
prüfen
Seite 86
Kundendaten
einsehen
IncludeBeziehung
Use-Case-Diagramm
Die Anwendung
Finanzamt
Steuern hinterziehen
- Einkommen
- Vermögen
+ Belege fälschen()
+ Privat-/Geschäftskosten
vermischen()
Lohnsteuerkarte
beantragen
Bürger
- Familienstand
- Steuerklasse
+ Formular ausfüllen()
+ Karte ausdrucken()
Steuern zahlen
Auskunft über Finanzen geben
- Einkommen
- Vermögen
+ Belege zeigen()
+ Einkommensbeleg vorlegen()
UML 2 Tutorial
Net.ObjectDays 2003
Seite 87
Use-Case-Diagramm
Kontextabgrenzung
Abgrenzung von Systemen zu ihren Nachbarsystemen
Bestellung
Fast Food Restaurant
Rechnung
Kunde
Geld
Nahrung
Bestellung
Geld
Rechnung
Zulieferer
Waren
Richtlinien
Geld
Bestätigung
Zinsen
Amt
UML 2 Tutorial
Net.ObjectDays 2003
Seite 88
Bank
Use-Case-Diagramm
Die wichtigsten Änderungen
UML 1.x
UML 2
Ein Akteur darf unbenannt sein
Ein Akteur muss einen Namen haben
Nur Pakete können Use-Cases besitzen.
Classifier im Allgemeinen können Use-Cases
besitzen.
Als Realisierer von Use-Cases werden
(Sub-) Systeme impliziert, obwohl jeder
Classifier einen Use-Case realisieren darf.
Es wird deutlich herausgestellt, dass alle
Classifier Use-Cases realisieren können.
Bei der «extend»-Beziehung werden die
Vorbedingungen nur in der Nähe der
entsprechenden Relation angetragen:
Die Vorbedingung und die entsprechenden
extension points werden als Notiz an die
Erweiterungsbeziehung angehängt:
«Vorbedingung»
{Benutzer ruft Hilfefunktion auf}
extension point: Hilfethema
Benutzer ruft Hilfefunktion auf
«extend»
«extend»
UML 2 Tutorial
Net.ObjectDays 2003
Seite 89
Use-Case-Diagramm
Vorsicht: Fehler die vermieden werden sollten
Use-Case Name fehlt
Akteur muss außerhalb des
Systems stehen
Verkauf
Assoziationen dürfen nur
binär sein
Verkäufer
Kreditwürdigkeit
prüfen
Bezeichnung des Akteurs
fehlt
Angabe des
Erweiterungspunktes fehlt
UML 2 Tutorial
Net.ObjectDays 2003
Kundendaten
einsehen
«extend»
Bürgen finden
Kunde nicht
gefunden
Zwischen Use-Cases des selben Systems dürfen
keine Assoziationen vorhanden sein
Seite 90
Aktivitätsdiagramm
„Wenn du etwas so machst, wie du es seit zehn Jahren
gemacht hast, dann sind die Chancen recht groß, daß
du es falsch machst.“
Charles Kettering
UML 2 Tutorial
Net.ObjectDays 2003
Seite 91
Aktivitätsdiagramm
Aktivitätsdiagramme visualisieren mögliche Abläufe
mit veränderbarem Detaillierungsgrad
vielfache Anwendungsgebiete
Geschäftsprozessmodellierung
Beschreibung von Use-Cases
Implementieren einer Operation
UML 2 Tutorial
Net.ObjectDays 2003
Seite 92
Aktivitätsdiagramm
Das Tokenkonzept
Das Tokenkonzept wurde den Petrinetzen entnommen
Der Ablauf in einer Aktivität wird durch den Tokenfluss gesteuert
Ermöglicht die präzise Beschreibung des Verhaltens
Die Token sind nur ein Gedankenkonstrukt (keine explizite
Modellierung)
Aktion 1
Aktion 2
Achtung! Tokenkonzept bewirkt semantische Änderungen zu
UML 1.x
Aktion 1
Aktion 2
Aktion 1
Aktion 2
UML 2 Tutorial
Net.ObjectDays 2003
ODER
UND
Aktion 3
Aktion 3
UML 1.x
UML 2
Seite 93
Aktivitätsdiagramme
Die wichtigsten Elemente im Überblick
Aktivität
Aktionsname
Objekttyp
Aktion
Objektknoten
Strukturierte
Knoten
Eingangsparameter
Ausgangsparameter
Kontrollelemente
Name
UML 2 Tutorial
Startknoten
Verzweigungsknoten
Parallelisierungsknoten
Endknoten
Verbindungsknoten
Synchronisationsknoten
Net.ObjectDays 2003
Seite 94
Kante
Aktivitätsdiagramm
Aktivität - Aktion
Aktivität beschreibt das komplette Diagramm
Aktivität
Kann Ein- und
Ausgangsparameter haben
Aktion
Cocktail mixen
Zutaten
Zutaten mischen
in Gläser füllen
Cocktail
Eis zerkleinern
Ausgangsparameter
Eingangsparameter
Aktionen sind Verhaltensaufrufe
Summe der Aktionen realisiert die Aktivität
UML 2 Tutorial
Net.ObjectDays 2003
Seite 95
Aktivitätsdiagramm
Objektknoten
Objektknoten repräsentieren
nicht das Objekt selber, sondern
den Typ des Objekts
Darstellung als Objektknoten
oder durch Pin-Notation
Cocktail mixen
Cocktail
Cocktail mixen
Objektknoten als Datenspeicher
«datastore»
Name
[Zustand]
Net.ObjectDays 2003
Seite 96
Cocktail
Cocktail trinken
«centralBuffer»
UML 2 Tutorial
Cocktail
Aktivitätsdiagramm
Kontrollelemente I
Kontrollelemente steuern den Ablauf der Aktivität
Kontrollelemente
- starten und beenden Abläufe
- ermöglichen parallele Abläufe
- können mehrere Abläufe
synchronisieren
- lassen alternative Abläufe zu
möglicher Ablauf
Einladung bekommen
Einladung
Datum prüfen
Kante
[Zeit
vorhanden]
Lust auf Feier
prüfen
[keine Zeit]
Bedingung
[keine Lust]
[Lust
vorhanden]
Kontrollknoten
Feier absagen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 97
Zur Feier
zusagen
Aktivitätsdiagramm
Kontrollelemente II
Startknoten:
- Starten den Ablauf
- Mehrere Startknoten initiieren parallele Abläufe
Startknoten
Endknoten:
- Beenden die Aktivität oder
- einen einzigen Ablauf
Endknoten
Kanten:
- Übergänge zwischen zwei Knoten
- Beschreiben die Ablaufrichtung
UML 2 Tutorial
Net.ObjectDays 2003
Seite 98
Kante
Aktivitätsdiagramm
Kontrollelemente III
Verzweigungsknoten:
- Ermöglichen alternative Abläufe
- Bedingungen geben Ablaufrichtung vor
Verbindungsknoten:
- Vereinigen mehrere Abläufe
Verzweigungsknoten
Verbindungsknoten
Parallelisierungsknoten:
- Aufteilen in parallele Abläufe
Parallelisierungsknoten
Synchronisationsknoten:
- Zusammenführen paralleler Abläufe
Synchronisationsknoten
UML 2 Tutorial
Net.ObjectDays 2003
Seite 99
Aktivitätsdiagramm
Unterbrechungsbereich und Exception-Handler
Unterbrechungsbereich:
- Umfasst ein oder mehrere Aktionen
- Kann über Unterbrechungskante
verlassen werden
- Alle Aktionen im Bereich werden
dann gestoppt
Unterbrechungsbereich
Exception-Handler:
- Ermöglicht die Beschreibung von Ausnahmen
- Exception-Handler substituiert eine Aktion
Aktion
ExceptionHandler
ExceptionTyp
UML 2 Tutorial
Net.ObjectDays 2003
Seite 100
Unterbrechungskante
Strukturierte Knoten
Umfassen mehrere Elemente einer Aktivität
Ablauf startet erst dann, wenn an allen eingehenden kanten
Token anliegen
Objektknoten als Ein- und Ausgangsparameter möglich
Schlüsselwort
UML 2 Tutorial
Net.ObjectDays 2003
Seite 101
Entscheidungsknoten
Visualisierung komplexer Entscheidungen
if: prüfen der Bedingung
Speise
then: auszuführende
if
Speise bewerten
Elemente
else: möglicher Ablauf,
wenn kein if-Bereich then
Gute Kritik
erstellen
zutrifft
else if: wie if-Bereich Restaurant
nur mit
Schlechte Kritik
erstellen
vorgegebener
else
Prüfreihenfolge
UML 2 Tutorial
Net.ObjectDays 2003
Seite 102
schmackhaft?
Bewertung
Mengenverarbeitung
Einzelne Betrachtung der Elemente welche in der restlichen
Aktivität nur als Sammlung betrachtet werden
z.B. Vektorkomponenten, hashtable, verkettete Listen....
Elemente werden als Objektknoten (Pin) übergeben
iterative
Bierkiste
besorgen
UML 2 Tutorial
Flasche öffnen
Net.ObjectDays 2003
Flasche leeren
Seite 103
leere Bierkiste
zurückgeben
Strukturierte Konten
Schleifenknoten
Visualisieren den Ablauf komplexer Schleifen
for: initiale Aufgaben
while: prüfen der Bedingung
für einen Durchlauf
do: Schleifenrumpf
for
Zahl 1
Zahl 2
X = Zahl 1
Y = Zahl 2
while
A = X+ Zähler
Reihenfolge do – while
ist optional
A<Y
do
Zähler = Zähler +1
UML 2 Tutorial
Net.ObjectDays 2003
Seite 104
Zähler = 0
Aktivitätsdiagramm
Aktivitätsbereiche
Einteilen des Diagramms in Bereiche mit gemeinsamen
Eigenschaften
Hierarchische und
mehrdimensionale
Aufteilung möglich
Fastfood-Restaurant besuchen
Person
Bereichsname
UML 2 Tutorial
PKW ausparken
Bedienung
PKW parken
Ort
Parkplatz
Kunde
Restaurant
Menü bestellen
Net.ObjectDays 2003
Seite 105
Menü verzehren
Menü
zusammenstellen
Kassieren
Aktivitätsdiagramm
UML 1.x
UML 2
Aktivitätsdiagramm als „Sonderform“ des
Zustandsdiagramms.
Aktivitäten sind unabhängig von
Zustandsautomaten.
Aktivitätsdiagramme entsprechen in der
Struktur den Zustandsdiagrammen.
Aktivitäten verwenden eine den Petri-Netzen
ähnlich Semantik (Token-Konzept).
Diagramm heißt Aktivitätsdiagramm.
Diagramm wird als Aktivität bezeichnet.
Es ist nur ein Anfangszustand erlaubt.
Es sind mehrere Startknoten erlaubt.
Aktivitätsdiagramme haben keine Ein- und
Ausgabeparameter.
Aktivitäten können Ein- und
Ausgabeparameter enthalten.
Parallele Stränge müssen
zusammengeführt werden.
Parallel Abläufe müssen nicht wieder
zusammengeführt werden.
Swimlanes sind immer eindimensional
Aktivitätsbereiche können hierarchisch oder
multidimensional sein.
Notationssymbole für Zustand und Aktivität
unterschiedlich:
Die Notation von Aktionen entspricht der
Notation von Zuständen der UML 1.x
Aktionszustand1
UML 2 Tutorial
Net.ObjectDays 2003
Zustand
Aktion
Seite 106
Zustand
Aktivitätsdiagramm
Fehlende
Bedingungen
Biergarten
Biergarten
betreten
Sitzplatz suchen
Bier bestellen
Durch vorherige
Verzweigung ist hier eine
Synchronisation nicht
möglich
Bier trinken
Fehlender Pin
Fehlender
Aktionsname
Biergarten
verlassen
UML 2 Tutorial
Net.ObjectDays 2003
bezahlen
Seite 107
Zustandsautomaten
„Take your chance while you still got a choice.“
Scott/Young/Young
UML 2 Tutorial
Net.ObjectDays 2003
Seite 108
Zustandsautomat
Einfaches Beispiel
sm Scheibenwischer
[Wischer in
Parkposition]
Nachwischen Wa
Ausgangsstellung
entry / in Parkposition bringen
[Wischer in
Parkposition]
after(3seconds) /
Waschen beenden
Waschen
gewählt
Fertigwischen
entry / in Parkposition
bringen
Wischen
gewählt
Waschen
gewählt
Wischen
beendet
Wischen
do / normal wischen
Wischen [schnell] / schnell wischen
Wischen [Intervall] / Intervall wischen
[Wischer in
Parkposition]
Waschen
do / Waschen
Waschen Wi
do / Waschen
after(3seconds) /
Waschen beenden
Nachwischen Wi
entry / in Parkposition bringen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 109
Zustandsautomat
Zustandsautomaten bilden Verhalten ab:
- in welchem Zustand kann
- unter welcher Bedingung
- bei welchem eingehenden Ereignis
- welche Transition ausgeführt werden
Anwendungsgebiete
- Zustandsbeschreibung von Classifiern, u. a.
- Detaillierung von Use-Cases
- Verhaltensbeschreibung von Interfaces und Ports
- Detailbeschreibung von Signal- und Ereignisempfang
UML 2 Tutorial
Net.ObjectDays 2003
Seite 110
Zustandsautomat
sm Zustandsautomat
Zustandsname
Zustandsname
Unterzustandsautomatenzustand : sm Unterzustandsautomat
einfacher Zustand
Unterzustandsautomatenzustand
zusammengesetzter Zustand
Trigger [Guard] / Aktivität
[Vorbedingung] Operation / [Nachbedingung]
Transition in
Verhaltenszustandsautomaten
Endzustand
Transition in
Protokollzustandsautomaten
Pseudozustände
Startzustand
Gabelung
UML 2 Tutorial
Net.ObjectDays 2003
Kreuzung
Entscheidung
Vereinigung
Seite 111
Austrittspunkt
H
H*
flache Historie
tiefe Historie
Eintrittspunkt
Terminator
Zustandsautomat
Zustandsautomat
Unterscheidung:
- Verhaltenszustandsautomaten
- Protokollzustandsautomaten
sm Zustandsautomatenname
Ein Verhaltenszustandsautomat
bildet das diskrete Verhalten einer
Instanz eines Classifiers ab.
Ein Protokollzustandsautomat
beschreibt die erlaubte Aufrufsabfolge der Instanz eines Classifiers.
UML 2 Tutorial
Net.ObjectDays 2003
Seite 112
sm Zustandsautomatenname
{protocol}
Zustandsautomat
Protokollzustandsautomat
sm Ampel
[aus] /
rot(an) /
rot
[reset]
schalte(rot) /
schalte(rot) /
gelb
gelb(an) /
schalte(gelb) /
grün
rot-gelb
schalte(grün) /
UML 2 Tutorial
Net.ObjectDays 2003
Seite 113
Zustandsautomat
einfacher Zustand und Transition
Ein Zustand beschreibt eine bestimmte
Ausprägung:
- eine statische Situation
- auf ein externes Ereignis wartend
Kann Aktivitäten enthalten:
- entry, do und exit activity
- interne Transitionen
- verzögerte Ereignisse
Eine Transition ist der Übergang von einem
Quell- zu einem Zielzustand
Zustandsname
Zustandsname
entry / Aktivität
exit / Aktivität
do / Aktivität
Trigger [Guard] / defer
[Vorbedingung] Operation / [Nachbedingung]
Transitionen in
Verhaltenszustandsautomaten
UML 2 Tutorial
Net.ObjectDays 2003
Protokollzustandsautomaten
Seite 114
Zustandsautomat
Zustandsübergänge
Verschiedenste Möglichkeiten einen Zustandsübergang
anzustoßen
Fertigwischen
closed
[Wischer in
Parkposition]
Ausgangsstellung
entry / in Parkposition
bringen
[passiv offen]
TCB erstellen
[geschlossen]
TCB löschen
Stufe 1
listen
do / langsam drehen
PKW neu
angemeldet
PKW gebraucht
do/ benutzen
Stufe2 gewählt /
schalte 2
Stufe1 gewählt /
schalte 1
Stufe 2
aktiv
UML 2 Tutorial
after(60 seconds)
Net.ObjectDays 2003
standby
Seite 115
do / schnell drehen
Zustandsautomat
zusammengesetzter Zustand
Setzt sich aus Zuständen, Pseudozuständen
und Transitionen zusammen
Zustandsname
entry / Aktivität
exit / Aktivität
do / Aktivität
Trigger / Aktivität
Trigger / defer
Zustandsname
entry / Aktivität
exit / Aktivität
do / Aktivität
Trigger / Aktivität
Trigger / defer
aktiv
gedrückt
[anykey]
abgebrochen
A
Startort eingegeben
Ziel
gewählt
rückgängig
Zielort eingegeben
rückgängig
Termin gewählt
Termin
gewählt
bestätigt /
drucken
gedruckt
UML 2 Tutorial
Net.ObjectDays 2003
Seite 116
B
Zustandsautomat
Unterzustandsautomatenzustand
Steht stellvertretend für einen
Zustandsautomaten
Kann Ein- und Austrittspunkte besitzen
sm Bezahlung
Auswahl
bestätigt
[Z_art = BG]
[Z_art = GK]
abwickelnBezahlung : sm Bezahlung
/ ausgeben
Getränk
Bezahlen
Bargeld : sm BB
Bezahlen
Geldkarte : sm BG
[ok] /
abbuchen
[ok] /
abbuchen
Abbruch
abgebrochen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 117
abgebrochen
Abbruch
Zustandsautomat
Region
Verwendung von Regionen impliziert Parallelität
Erreichbar durch Verwendung von:
- Gabelungszuständen, oder
- Startzuständen (einer pro Region)
Flasche
geöffnet
offen
Flasche
geöffnet
Temperatur
Blubbereffekt
kalt
sprudelnd
offen
kalt
after
(Zeit)
UML 2 Tutorial
sprudelnd
after
(Zeit)
warm
still
Temperatur
Blubbereffekt
Net.ObjectDays 2003
Seite 118
after
(Zeit)
warm
after
(Zeit)
still
Zustandsautomat
Pseudozustände I
Startzustand:
- Verweist auf den ersten Zustand
- Einer pro Region
Entscheidung:
- Ausgehende Transition wird während
der Ausführung der Transition bestimmt
Kreuzung:
- Ausgehende Transition ist vor der
Ausführung der Transition bekannt
Ein- und Austrittspunkt:
- Zum Betreten und Verlassen von
Unterzustandsautomaten
UML 2 Tutorial
Net.ObjectDays 2003
Seite 119
Startzustand
Entscheidung
Kreuzung
Austrittspunkt
Eintrittspunkt
Zustandsautomat
Pseudozustände II
Gabelung und Vereinigung:
- Teilen eine Transition auf mehrere
parallele Zustände auf bzw. fügen mehrere
Transitionen zu einer zusammen
Flache Historie:
- Speichert den zuletzt aktiven Unterzustand
eines komplexen Zustands
Tiefe Historie:
- Speichert den zuletzt aktiven Unterzustand
eines in einem komplexen Zustand
enthaltenen Zustand
Terminator:
- Bei Erreichen endet die Lebensdauer der Instanz
des beschriebenen Classifiers
UML 2 Tutorial
Net.ObjectDays 2003
Seite 120
Gabelung
Vereinigung
H
flache Historie
H*
tiefe Historie
Terminator
Zustandsautomat
Beispiele Pseudozustände
Betriebsmodi Autoradio
probiert
Prüfung Trinkbarkeit
eingeschalten
Trinkbarkeit
geprüft
do / Trinkbarkeit prüfen
getrunken
H
Zustand3
manuell
umgeschaltet
[Kassette drin]
[ist ok = ja]
trinken
manuell
umgeschaltet
[keine Kassette
drin]
[Kassette
ausgeworfen]
umschalten
Kassette
eingelegt
Zustand2
[ist ok = nein]
wegschütten
ausgeschalten
manuell
umschalten
[CD-Kassette
drin]
manuell
umgeschaltet
Zustand1
A
do / x = 1
A
do / x = 1
Trigger / x = -1*x
Trigger / x = -1*x
x
[x<0]
B
UML 2 Tutorial
Net.ObjectDays 2003
[x>=0]
C
Seite 121
[<0]
[>=0]
B
C
Zustandsautomat
Explicit und default entry
Default entry:
Eine eingehende Transition endet
am Rand des
zusammengesetzten Zustands.
default entry
A
B
default entry
Explicit entry:
Eine eingehende Transition endet
an einem Unterzustand des
zusammengesetzten Zustands
A
A
explicit entry
B
explicit entry
explicit entry
A
UML 2 Tutorial
Net.ObjectDays 2003
Seite 122
B
Zustandsautomat
Verlassen von Zuständen
Das Verlassen von zusammengesetzten Zuständen und
Zustandsautomaten kann auf verschiedene Arten erfolgen
gesperrt
[else] / einschalten
[Pin unterdrückt] /
einschalten
A
B
Pin
unterdrückt
sm Authentifizierung
X
Trigger1 [Guard] /
Aktivität
Authentifizierung : sm Authentifizierung
Pin eingeben /
Eingabe# = 0
Y
Pincodeabfrage
do / Pincode prüfen
C
Trigger2 [Guard] /
Aktivität
Pincode
geprüft
Z
[#<3]
[Pin = falsch] /
Eingabe#++
Fehleingabe
do / Eingabe# prüfen
[Pin =
richtig]
Pin
unterdrückt
UML 2 Tutorial
Net.ObjectDays 2003
Seite 123
authentifiziert
[#>=3]
gesperrt
Zustandsautomat
Vererbung
Spezialisierung von Zustandsautomaten durch
- Erweiterung um Regionen, Zustände und Transitionen
- Erweiterung von Regionen und Zuständen
- Erweiterung von Transitionen
sm Geldautomat {extended}
sm Geldautomat
Karte prüfen
{final}
Betrag einlesen {extended}
Karte
angenommen
defekt
{final}
defekt
anderer Betrag
gewählt
Betrag wählen
Betrag
gewählt
Transaktion
bestätigen {final}
UML 2 Tutorial
Betrag wählen
Betrag eingeben
Transaktion nicht
bestätigen
Karte ausgegeben
{final}
Net.ObjectDays 2003
ok
Transaktion
bestätigen {final}
Seite 124
Zustandsautomat
UML 1.x
UML 2
-
Ports können nun
Protokollzustandsautomaten besitzen.
-
Ein-, Austrittspunkte und Terminatoren
wurden eingeführt.
Tiefe Historien können nur eingehende
Transitionen von außerhalb des
enthaltenden Zustands haben.
Tiefe Historien können auch Ziel einer
Transition innerhalb des enthaltenen
Zustands sein (also nicht nur von außen).
-
Regeln zur Ergänzung und Ersetzung von
Transitionen bei vererbten
Zustandsautomaten wurde hinzugefügt.
Generalisierung von Zustandsautomaten
wird durch eine Notiz kenntlich gemacht.
Das vererbte Verhalten wird mit einem
Zustandsautomaten dargestellt.
UML 2 Tutorial
Net.ObjectDays 2003
Seite 125
Zustandsautomat
Vorsicht: Fehlerteufel
Nur ein Startzustand
pro Region gestattet
sm Fehlerbeispiel
Bei Startzuständen nur eine
ausgehende Transition erlaubt
A
B
C
Vereinigung nicht
orthogonaler Zustände
nicht möglich
Transition ohne Zielzustand
Ausgehende Transition
in einem Endzustand
Transition ohne Quellzustand
UML 2 Tutorial
Net.ObjectDays 2003
D
Seite 126
Interaktionsmodellierung
mit der UML 2
„Auch in der Kommunikation gilt das Gesetz des
abnehmenden Grenznutzens: Immer mehr Aufwand
bringt – ab einem gewissen Punkt – immer weniger
Erfolg.“
Michael Tost
UML 2 Tutorial
Net.ObjectDays 2003
Seite 127
Interaktionen
Definition und Prinzip
Interaktionen sind ein wichtiges Basiskonzept der
UML-Verhaltensdiagramme
Interaktion ist der Nachrichten- und Datenaustausch zwischen
zwei Kommunikationspartnern
Grundelemente der Interaktion:
- Kommunikationspartner (repräsentiert durch Lebenslinien)
Sender
Empfänger
- Nachrichten
Nachrichtenaustausch
verbindet Sende- und
Nachricht
Empfangsereignisse
Sendeereignis
UML 2 Tutorial
Net.ObjectDays 2003
Seite 128
Empfangsereignis
Interaktionen
Wann modelliere ich Interaktionen im Projekt?
Modellierung von Interaktionen auf verschiedenen
Abstraktionsebenen
vielfache Einsatzmöglichkeiten
Lokale oder verteilte Kommunikation
Detailmodellierung im Feindesign
Spezifikation von Schnittstellen
Test und Simulation
UML 2 Tutorial
Net.ObjectDays 2003
Seite 129
Interaktionen
Welche UML 2 Diagramme gibt es zur
Interaktionsmodellierung?
Diagramme der
UML 2
Strukturdiagramme
Klassendiagramm
Komponentendiagramm
Verhaltensdiagramme
Objektdiagramm
Verteilungsdiagramm
Aktivitätsdiagramm
Paketdiagramm
Use-CaseDiagramm
Sequenzdiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 130
Zustandsautomat
Timing-Diagramm
Interaktionen
Sichten auf Interaktionen
Interaktionsdiagramme zeigen nur Sichten auf Interaktionen
Diagrammwahl nach hervorzuhebenden Modellierungsaspekt
1: Temp_einstellen
:Koch
:Herd
:Koch
:Herd
Temp_einstellen
:Herd
Lebenslinie
Temp_einstellen
Nachricht
:Koch
Sequenzdiagramm
Timing-Diagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 131
Sequenzdiagramm
„Erst die richtige Reihenfolge macht aus klugen
Gedanken ein gutes Ergebnis.“
A. van Rheyn
UML 2 Tutorial
Net.ObjectDays 2003
Seite 132
Sequenzdiagramm
Kommunikationspartner
sd Interaktion
K1
K2
K3
Lebenslinie
Nachricht1(Argument)
Zeitlicher
Verlauf
Ok=Nachricht1
Nachricht2
Aktionssequenz
Nachricht
UML 2 Tutorial
Net.ObjectDays 2003
Seite 133
Sequenzdiagramm
Kontextabgrenzung
sd Waschmaschine
:Waschmaschine
Benutzer
:Stromnetz
:Wasserleitung
befüllen
Waschmittel_zugeben
Weichspüler_zugeben
Programm_wählen
Einheit
Minuten
Strom
einschalten
Wasser
{30...90}
Abwasser
fertig
auschalten
aus
Wäsche_entnehmen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 134
:Kanal
Sequenzdiagramm
Use-Case-Diagramm
Sequenzdiagramm
sd Wäsche waschen
Waschmaschine
:Benutzer
Wäsche trocknen
:Steuerung
einschalten
«extend»
:Wasserventil
:Heizelement
öffnen
Hausmann
Wäsche waschen
Wasser erhitzen(Temperatur=30°)
schliessen
Hauptwaschgang
Benutzer
Wasserventil
abpumpen
Heizelement
Steuerung
par
Pumpe
schleudern
Motor
abpumpen
Klassendiagramm
fertig
UML 2 Tutorial
Net.ObjectDays 2003
Seite 135
:Motor
:Pumpe
Sequenzdiagramm
Lebenslinie
Zustandsbedingung
sd Bild aufhaengen
:Person
:Hammer
:Nagel
:Daumen
:Bild
[gerade]
loop
Abbruchbedingung
[Nagel
haelt]
alt
schlagen
getroffen =
schlagen
treffen
Kombiniertes
Fragment
treffen
Interaktions
-verweis
ref
Daumen verbinden
aufhaengen
Nachricht
UML 2 Tutorial
Net.ObjectDays 2003
Seite 136
Aktionssequenz
Sequenzdiagramm
Lebenslinien
Repräsentieren die Teilnehmer einer Interaktion
Repräsentieren
sd Internetsuche
- den Classifier selbst,
:Internetbrowser
- die Attribute des Classifiers,
suche_starten(Keyword)
- Teile des Classifiers, z. B. Ports
- die Operationen des Classifiers,
suche_starten
- und Parameter von Operationen
aktualisieren
- (lokale) Variablen einer Operation.
Bestellung
Darstellung der Aktionssequenzen
Stopp löscht die Lebenslinie
lösche
UML 2 Tutorial
Net.ObjectDays 2003
Seite 137
:Suchmaschine
Aktionssequenz
Sequenzdiagramm
Beispiele für Lebenslinien
Person
Motor
Motor
+ berechneAlter(int Geburtsjahr,Datum):Alter
p:Getriebe
Gaspedal
+ Beschleunigen()
sd
sd berechneAlter(int Geburtsjahr,Datum):Alter
Operationsname
kennzeichnet
Rückgabewert
Geburtsjahr:int
Datum
self
p:Getriebe
berechneAlter:Alter
beschleunigen
Setzen des
Rückgabewerts
sd Anschrift setzen
Person
UML 2 Tutorial
Nachname
:String
Vorname[0]
:String
Vorname[1]
:String
Adresse
Net.ObjectDays 2003
Nachname
:String
Seite 138
Vorname[0]
:String
Vorname[1]
:String
Adresse
Sequenzdiagramm
Zustandsinvariante-/Zustandsbedingung
„Lebenslinie“ muss Bedingung erfüllen
Wird zur Laufzeit überprüft
sd Pizzabestellung
:Kunde
:Pizzaservice
geöffnet
bestellen
bestellen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 139
Zustandsbedingung für
Lebenslinie „Pizzaservice“
Sequenzdiagramm
Nachrichten
Beschreiben den Informationsfluss zwischen den
Synchrone Nachricht
Kommunikationspartnern
A
Synchrone Nachrichten
(Sender wartet auf Antwort)
Asynchrone Nachrichten
Found Nachricht
(Antwort wird nicht erwartet)
Abgebildet durch Pfeil und Pfeilspitze
Lost und Found Nachrichten:
UML 2 Tutorial
Net.ObjectDays 2003
Seite 140
B
N1
C
N3
N2
N4
Antwortnachricht
Asynchrone
Nachricht
Lost Nachricht
Sequenzdiagramm
Kombinierte Fragmente
Teil einer Interaktion
Mit bestimmten Regeln für
- Auswahl
- Reihenfolge
- Häufigkeit
der Nachrichten
Interaktionsoperator
:A
:B
trennt
Operanden
alt
m
[x == 1]
}
n
[else]
Interaktionsbedingung
UML 2 Tutorial
Net.ObjectDays 2003
Seite 141
kombiniertes
Interaktionsfragment
Interaktionsoperand
Sequenzdiagramm
Alternativ (alt):
- Existenz von mehr als
einer Ablaufmöglichkeit
- Bedingungen geben den
Ablauf vor
- Immer 2 Operanden
Modellierung von
- If-else-Bedingungen
- Switch/case Anweisungen
UML 2 Tutorial
Net.ObjectDays 2003
sd Nahrung aufnehmen
:Partygast
:Buffet
alt
pluendern
[Partygast.Hungergefühl>normal]
aufessen
[Partygast.Hungergefühl== normal]
[else]
Seite 142
weiterfeiern
:Snacks
Sequenzdiagramm
sd Interaktion ignore {N3, N4}
Ignore (ignore)
- Blendet Nachrichten aus,
die für die Modellierung
irrelevant sind
- Im realen System können
diese jedoch vorkommen
A
N1
N2
N5
sd
Consider (consider)
- Nur die genannten
Nachrichten sind relevant
- Betont Intention des
Modellierers
UML 2 Tutorial
Net.ObjectDays 2003
Seite 143
C
B
Interaktion
consider {N3, N4}
A
C
B
N1
N3
N4
Sequenzdiagramm
sd Spiel ignore {ziehen}
Option (opt):
- Interaktion, die nur unter
bestimmten Bedingungen
durchgeführt wird
- If(...) then { ... }
:Spieler
:Würfel
opt
[keine Figur im
Feld]
loop (1,3)
[Augenzahl!=6]
wuerfeln
Loop (loop)
- Abbildung von Schleifen
- Zählschleife:
loop(min, max)
- Abbruch/Ausführung durch
[Bedingungen] steuerbar
UML 2 Tutorial
Net.ObjectDays 2003
Seite 144
wuerfeln
opt
loop
[Augenzahl==6]
[Augenzahl==6]
wuerfeln
wuerfeln
Sequenzdiagramm
sd trinken
Negative (neg)
- Hebt ungültige Folgen von
Einzelschritten hervor
- Zur Betonung gedacht
- Modellierung von
negativen (Test-)fällen
:Partygast
:Glas
austrinken
neg
austrinken
sd Party verlassen
Assertion (assert)
- Legt eine bestimmte
Reihenfolge fest
- Zur Betonung gedacht
:Partygast
:Gastgeber
verabschieden
assert
weggehen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 145
Sequenzdiagramm
sd Unfallaufnahme
Parallel (par)
- Mehrere Abläufe
sollen gleichzeitig
ablaufen
- „Threading“
Patient
:Patient
par
Aufnahme
:Aufnahme
OP
:OP
aufnehmen
operieren
aufnehmen
verlegen
Critical Region (critical)
- Festlegen eines
ununterbrechbaren,
statischen Ablaufs
UML 2 Tutorial
Net.ObjectDays 2003
critical
aufnehmen
(Herzinfarkt)
Seite 146
aufnehmen
(Herzinfarkt)
operieren
Station
:Station
Sequenzdiagramm
Kombinierte Fragmente - Coregion
Alternativdarstellung zum parallel kombinierten Fragment
Aber nur wenn nur eine Lebenslinie betroffen ist
Ablaufreihenfolge innerhalb der Coregion ist beliebig
sd Tankstopp
:Person
:Auto
tanken(Benzin)
Scheiben putzen
Öl kontollieren
bezahlen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 147
:Kasse
Sequenzdiagramm
Break (break)
- Unterberechen
des normalen
Ablaufs
sd Drogenfahndung
Fahrer
:Fahrer
Polizist
:Polizist
Auto
:Auto
anhalten
durchsuchen
Ergebnis
Zur Modellierung von
- Exceptions
- Systemfehlern
- Kritischen
asynchronen
Ereignissen
UML 2 Tutorial
Net.ObjectDays 2003
break
[Ergebnis == Drogen gefunden]
verhaften
weiterfahren
Seite 148
Sequenzdiagramm
Notationselemente - Interaktionsverweis
ref
C
sd
Referenziert (ref) auf
eine beliebige
Interaktion
Wiederverwendung in
mehreren Diagrammen möglich
„Zooming“ – Gedanke
Auch für Lebenslinien
möglich
X
Z
Y
ref C
ref
A
ref
B
sd A
sd B
X
Y
Z
Y
UML 2 Tutorial
Net.ObjectDays 2003
Seite 149
Z
Sequenzdiagramm
Modellierung von Zeitangaben
X
Y
a
t=now
Zeitpunkte beschreiben,
wann ein Ereignis eintritt
Einheit
Uhr
Zeiteinheit
für t ist ms
{12.00..12.05}
b
t=now
c
t..t+5
Zeitdauerbedingung
XX
Zeitdauer beschreibt,
Die Dauer von Nachrichten
oder Aktionssequenzen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 150
a
Zeiteinheit
Sekunden
YY
{2..10}
Hilfslinien
b
b
c
ÜZeit=duration
d
{0..0,5*ÜZeit}
{5..5}
Zeitdauerbeobachtungsaktion
Sequenzdiagramm
UML 1.x
UML 2
Zerlegung von Lebenslinie nicht möglich,
Referenzen von anderen Interaktionen
nicht möglich
Innerhalb von Sequenzdiagrammen kann auf
andere Interaktionen verwiesen werden
(Zerlegung von Abläufen oder Lebenslinien)
Kontrollflussmöglichkeiten äußerst
bescheiden: Schleifen und
Nachrichtenbedingungen möglich
Alle Kontrollflussmöglichkeiten (if, switch, ...)
höherer Programmiersprachen durch
kombinierte Fragmente, sehr gute
Unterstützung von nebenläufiger Modellierung
Nachrichtenarten:
asynchron, synchron, unspezifiziert
unspezifiziert entfällt,
Nachrichten eingeführt
lost
und
found
Zustandsinvarianten können an Lebenslinien
angetragen werden
UML 2 Tutorial
Net.ObjectDays 2003
Seite 151
„Auch das Chaos gruppiert sich um einen festen Punkt,
sonst wäre es nicht einmal als Chaos da.“
Arthur Schnitzler
UML 2 Tutorial
Net.ObjectDays 2003
Seite 152
Notationselemente:
- Interaktion
- Lebenslinien
Nachrichtenname
- Nachrichten
- Sequenzbezeichner
Name der Interaktion
Lebenslinie
cd Gassi gehen
1:Gassi gehen
Hundehalter
Sequenzbezeichner
Hund
3:entfernen
2.1:schimpfen
1.1:machen
2:reintreten
Richtung der
Nachricht
UML 2 Tutorial
Net.ObjectDays 2003
Seite 153
Passant
Häufchen
Gehört zu den Interaktionsdiagrammen
Zeigt das Zusammenspiel von strukturierten
Kommunikationspartnern.
Kontrollflüsse und zeitliche Aspekte sind weniger wichtig
Gut geeignet für die Modellierung von Prinzipien und Konzepten
Wenig Änderungen zur UML 1.x Version, dem
Kollaborationsdiagramm
UML 2 Tutorial
Net.ObjectDays 2003
Seite 154
Nachricht - Sequenzbezeichner
Definiert für Nachrichten
- Reihenfolge
- Ebene
der Abarbeitung
cd Restaurantbesuch
Gast
1b:bestellen
1a:bestellen
2a: [Glas voll]
trinken
Reihenfolge wird durch
Zahlen spezifiziert
4:bezahlen
(Betrag)
Getraenk
Essen
1:hinzufuegen
Ausführungsbedingung in
eckigen Klammern
2b*[Teller voll]:
essen
1:hinzufuegen
Rechnung
3:berechnen(Betrag)
UML 2 Tutorial
Net.ObjectDays 2003
Seite 155
Nebenläufigkeit und Schleifen
Nebenläufigkeit
durch Buchstaben im
Sequenzbezeichner
cd Reparaturauftrag
1a.1:Auftrag
1a:beauftragen
Auftragsannahme
Besitzer
Mechaniker
1a.1.1.1:erledigt
1b:ausleihen
1a.1.1a:reparieren
Definition von Schleifen
mit einem Stern „*“
2:fahren
Auto
Mietwagen
1a.1.1b*||[alle Ersatzteile vorhanden]:
Ersatzteil beschaffen
Kennzeichnung von
nebenläufigen Schleifendurchläufen mit
Doppelstrich „||“
Lager
1a.1.1c:[Ersatzteil nicht vorhanden]:
bestellen
Ersatzteil
UML 2 Tutorial
Net.ObjectDays 2003
Seite 156
UML 1.x
UML 2
Kollaborationsdiagramm
Vollständig äquivalent zum
Sequenzdiagramm
Subset des Sequenzdiagramms, z. B.
- keine Interaktionsverweise („ref“)
- keine kombinierten Fragmente
- Ereignisreihenfolge wird ignoriert
UML 2 Tutorial
Net.ObjectDays 2003
Seite 157
Timing-Diagramm
„Die Neugier steht immer an erster Stelle eines
Problems, das gelöst werden will.“
Galileo Galilei
UML 2 Tutorial
Net.ObjectDays 2003
Seite 158
Timing-Diagramm
Name des
Diagramms
ZeitBedingung
td Fußgängerampel
{d...6*d}
:Ampel
grün
rot
gehen
betriebsbereit
nicht
gehen
aktivieren
Lebenslinien
:Fußgänger
aktiv
wartend
d
Sek.
0 10 20 30
Zustand
Zeitskala
UML 2 Tutorial
Net.ObjectDays 2003
Seite 159
Zustandslinie
Nachricht
Timing-Diagramm
Gehört zu den Interaktionsdiagrammen
Darstellung des zeitlichen Veränderung eines Classifiers
(Klasse, Objekt, Komponente, ...)
Für die Modellierung zeitkritischer Zustands- und
Wertänderungen sinnvoll
Neu in der UML 2!
Bereits seit Jahren in Elektrotechnik genutzt (z. B. für
elektronische Schaltvorgänge)
UML 2 Tutorial
Net.ObjectDays 2003
Seite 160
Timing-Diagramm
Elemente – Lebenslinie - Zustandslinie
Nur eine Lebenslinie
oder kommunizierende
Lebenslinien möglich
Zeitliche Verzögerung des
Zustandsüberganges
td Fahrstuhltür
Zustand
Zustandslinien
beschreiben den
Wechsel der Zustände
im Ablauf der Zeit
UML 2 Tutorial
Net.ObjectDays 2003
:Fahrstuhltür
beim öffnen
beim
schliessen
Zustandslinie
:Lichtschrankensystem
Meist nur Sicht auf
wenige Zustände der
auf Lebenslinie
offen
unterbrochen
nicht
unterbrochen
0
Seite 161
2
sek
Timing-Diagramm
Elemente - Nachrichten
Nachrichten werden zwischen den Zustandslinien ausgetauscht
Bewirken häufig einen Zustandswechsel
:Verkehrsfunk
td Autoradio
aktiv
inaktiv
:Musiksender
Anfang
UML 2 Tutorial
leise
laut
Net.ObjectDays 2003
Seite 162
Ende
Nachricht
Timing-Diagramm
General-Value-Lifeline
Alternative Darstellungsform
td Waschstraße
{2a..6,5a}
{5a}
{4a}
:Waschstraße
betriebsbereit
Vorreinigung
Hauptwäsche
Trocknen
betriebsbereit
:Kunde
aktiv
warten
a
UML 2 Tutorial
Net.ObjectDays 2003
Seite 163
aktiv
Timing-Diagramm
td Schweinebraten zubereiten
:Schweinebraten
zubereitet
roh
fehlende
Zustandsbeschriftung
aktiv
warten
fehlende
Lebenslinienbeschriftung
Lücke in der
Zustandszeitlinie
UML 2 Tutorial
Net.ObjectDays 2003
Seite 164
Empfangsereignis vor
Sendeereignis
„Wer auf morgen wartet, wird übermorgen erkennen,
dass er heute versäumt hat das Notwendigste zu tun.“
Walter Scheffel
UML 2 Tutorial
Net.ObjectDays 2003
Seite 165
iod Betriebsfeier
ref
Verpflegung_organisieren
sd
:Chef
ref
:Angestellter
Mitarbeiter.Hemmschwelle=Feier:Alkoholkonsum
organisiereFeier
ref
Mitarbeiter_verständigen
[Keine Hemmschwelle]
sd
sd
:Chef
:Mitarbeiter
bedanken
UML 2 Tutorial
Net.ObjectDays 2003
Seite 166
:Chef
:Personalchef
mitarbeiterfeuern
Interaktionsübersicht
Darstellung der Ablaufreihenfolge mehrerer Interaktionen
Besonders geeignet für:
- Brückenschlag zwischen Aktivitäts- und
Interaktionsdiagrammen
- Logischen Zusammenhang zwischen mehreren
Interaktionsdiagrammen schaffen
Ablauf wird durch Kontrollelemente aus dem Aktivitätsdiagramm
dargestellt
Neu in der UML 2!
UML 2 Tutorial
Net.ObjectDays 2003
Seite 167
Fazit --dynamische Diagramme in UML 2
Viel neu - viel geklaut
Aktivitätsdiagramme und Sequenzdiagramme faktisch neu
Verbesserte Unterstützung der Codeabbildung
Bessere Modellierung von Nebenläufigkeiten und
Zeitverhalten möglich Î dennoch keine „Echtzeitsprache“
Deutlich bessere Schnittstelle zu Strukturdiagrammen
Notationsvielfalt erfordert Tailoring
Interaktionsübersichtsdiagramm, Timingdiagramm
erfordern Nachbesserungen
UML 2 Tutorial
Net.ObjectDays 2003
Seite 168
Damit Sie klar sehen!
Infos:
•www.uml-glasklar.de
•www.jeckle.de
•www.sophist.de
UML 2 Tutorial
Net.ObjectDays 2003
Seite 169
Modelle der Realität erstellen
Wir erkennen die Struktur Ihrer Projektanforderungen!
Infos unter www.SOPHIST.de
UML 2 Tutorial
Net.ObjectDays 2003
Seite 170
UML 2 Tutorial
Net.ObjectDays 2003
Seite 171

UML 2 Tutorial

Transcrição

Documentos relacionados

UML Klassendiagramm - Dr. Stefan Enderle

Eine Benefizfahrt mit dem Fahrrad von

ein AutoCAD Clone - segeln

Übungen zur Softwaretechnik - Software and Systems Engineering

Full Text

PRESSEMITTEILUNG Gentleware präsentiert Community

Gentleware AG

Dr. Vladimir Rubin - Amazon Web Services

Mit sane einen Scanner im Netzwerk nutzen

Erstellt mit Poseidon for UML Community Edition