UML und OCL

Transcrição

UML und OCL

© 2004-2010, Rainer Schmidberger
Einführung in die
Unified Modeling
Language
WS 2009/10
Rainer Schmidberger
[email protected]
se
Programmentwicklung,
Vorlesungsskript UML
14.10.2009
UML (1)
The Unified Modeling Language is a visual language
for specifying, constructing, and documenting the
artifacts of systems. It is a general-purpose modeling
language [...] that can be applied to all application
domains (e.g., health, finance, telecom, aerospace)
and implementation platforms [www.uml.org].
Die Unified Modeling Language (UML) ist eine von der
Object Management Group (OMG) entwickelte und
standardisierte Sprache für die Modellierung von
Software und anderen Systemen [de.wikipedia.org].
Aktuelle Version: 2.1
se
Folie 2
14.10.2009
UML (2)
Wurde entscheidend durch Grady Booch, Ivar
Jacobson und James Rumbaugh geprägt.
Hat die vor 1996 existierenden verschiedenen
Modellierungsmethoden (der genannten drei, sowie
anderer) abgelöst
Wird zur Prozessmodellierung, Analyse, Spezifikation
und zum Systementwurf verwendet
Es sind sehr viele gute Werkzeuge zur UML auf dem
Markt
Bietet sehr konkreten Übergang zur Implementierung.
Code-Generierung ist aus den Modellen heraus in
vielen Teilen möglich
In Zukunft: MDA, MDD und Executable UML?
se
Folie 3
Ivar Jacobson
Grady
Booch
14.10.2009
Die drei „Amigos“
se
James
Rumbaugh
Folie 4
14.10.2009
14.10.2009
Geschichte der UML
se
se
Quelle: Mario Jeckle, 2003
Folie 5
„Entstehung“ der UML
Quelle: www.ibm.com
Folie 6
Kurzübersicht über
die UML-Diagramme
Rainer Schmidberger
[email protected]
se
14.10.2009
Diagramm Übersicht
se
UML
Diagramme
Strukturdiagramme
Verhaltensdiagramme
Interaktionsdiagramme
Neu in UML 2.0
Klassend.
Objektd.
Komponentend.
Kompositionsstrukturd.
Verteilungsd.
Paketd.
Use Case-D.
Aktivitätsd.
Zustandsd.
Sequenzd.
Kommunikationsd.
Zeitdiagramm
Interaktionsübersichtsd.
Folie 8
14.10.2009
Diagramm Übersicht (engl.)
se
Quelle: www.uml.org, 2006
Folie 9
Strukturdiagramme
Klassendiagramm (class diagram)
Ö Modellierung der Klassen mit Methoden, Attributen und
Beziehungen
Paketdiagramm (paket diagram)
Ö Modellierung der logische Struktur der Modellelemente
mit deren (z.T. abstrakten) Abhängigkeiten
Objektdiagramm (object diagram)
Ö Modellierung von „Momentaufnahmen“ konkreter
Objekte mit Werten und Beziehungsausprägungen
14.10.2009
Kompositionsstrukturdiagramm (composite structure
diagram)
Ö Modellierung der internen Struktur eines Modellelements (Classifiers) sowie dessen Möglichkeiten zu
Interaktion mit anderen Systemkomponenten
Komponentendiagramm (component diagram)
se
Ö Modellierung der Komponenten (=Module) und deren
Abhängigkeiten
Verteilungsdiagramm (deployment diagram)
Ö Zeigt die (physischen) Geräte des Systems im Betrieb
Folie 10
Verhaltensdiagramme
Use-Case Diagramm (use case diagram)
Ö Modellierung der Anwendungsfunktionalität aus der
Sicht der Anwender
Aktivitätsdiagramm (activity diagram)
Ö Modellierung des dynamischen Ablaufs (i.d.R. eines
Use Case)
Zustandsdiagramm (state transition diagram)
Ö Modelliert die Zustände und Zustandswechsel (i.d.R.
zu einer Klasse)
Sequenzdiagramm (sequence diagram)
14.10.2009
Ö Modelliert ein Szenario: den Botschaftsfluss zwischen
Objekten
Kommunikationsdiagramm (comunication
diagram)
Ö Dynamik wie Sequenzdiagramm; zusätzlich
Objekteigenschaften
Timing-Diagramm
Ö Präziser zeitlicher Verlauf
Interaktionsübersichtsdiagramm
Ö Modellierung des Zusammenspiels einzelner
Interaktionsdiagramme
se
Folie 11
14.10.2009
Diagramm Übersicht
se
UML
Diagramme
StrukturDiagramme
VerhaltensDiagramme
InteraktionsDiagramme
Klassen-D.
Objekt- D.
Komponenten-D.
Kompositionsstruktur-D.
Verteilungs-D.
Paket-D.
Use Case-D.
Aktivitäts-D.
Zustands-D.
Sequenz- D.
Kommunikations- D.
Zeit-D.
InteraktionsÜbersichts-D.
Folie 12
Modellierung der Klassen mit Methoden, Attributen und
Beziehungen
Ähnlich dem ER-Diagramm
Rolle
Fahrkarte
Sichtbarkeit
startpunkt
zielpunkt
wegstrecke
rabatt
+fahrgast
0..*
Person
name : String
vorname : String
1
bestellen()
stornieren()
14.10.2009
Klassendiagramm
belasten(betrag : Waehrungsbetrag)
1
+karteninhaber
0..*
se
Beziehung
Multiplizität
Bestellvorgang
start()
Attribute
Methoden
Kreditkarte
betreiber
nr
kontrollNr
Ablaufdatum
istGueltig()
belasten(betrag : waehrungsbetrag)
Folie 13
Pakete dienen als „Container“ für beliebige UML Modellelemente
Das Paketdiagramm zeigt (abstrakte) Beziehungen zwischen
einzelnen Paketen
14.10.2009
Paketdiagramm
se
Businesslogic
Klassen
GUI Klassen
Rechnung
Modellsicht:
Datenbankzu
griffe
Berechnungs
logik

Ein Paket kann selber wieder
Pakete oder andere
Modellelemente wie z.B.
Klassen enthalten
Folie 14
Zeigt eine Momentaufnahme des Systems
Dem Klassendiagramm sehr ähnlich: statt der (abstrakten) Klassen
werden (konkrete) Objekte dargestellt
Objektname ist in der Regel eine Rolle, in der ein Objekt agiert
Attributwerte können auch angezeigt werden
fluggast: Person
14.10.2009
Objektdiagramm
name : String = „Duck“
vorname : String = „Donald“
Objektname : Klassenname
se
bezahltMit
: Kreditkarte
betreiber : String = „Visa“
Nr : String = „1234567“
Folie 15
Ab UML 2.0, Composite Structure
„Kontext“-bezogenes Klassen-, Objekt oder
Komponentendiagramm
Zeigt eine „Ausprägung“ oder eine bestimmte
Konfiguration
14.10.2009
Kompositions-Struktur-Diagramm
Abrechnung
Kollaborationstyp
fahrgast : Person
se
: Kreditkarte
Folie 16
Modelliert die Software-Architektur mit Bibliotheken,
Komponenten, Datenbanken, usw.
Komponente
Verbindungen
14.10.2009
Komponenten Diagramm
<<Component>>
<<Component>>
GUISteuerung
Verbindungsrechner
Konnektor
se
Interface
Port
<<Component>>
BenutzerGUI
Anschlüsse
<<Component>>
Fahrplandatenbank
Abhängigkeiten
Folie 17
Deployment diagram
Modelliert die Abbildung auf das physische Ziel-System
(die Geräte) wie Server, Clients, externe Geräte, usw.
Beschreibende Artefakte können ebenso mit
aufgenommen werden
Browser
Application-Server
<<HTTP>>
<<JDBC>>
Datenbank
14.10.2009
Verteilungsdiagramm
se
Folie 18
Diagramm Übersicht
UML
Diagramme
14.10.2009
StrukturDiagramme
VerhaltensDiagramme
InteraktionsDiagramme
Klassen-D.
Objekt- D.
Komponenten-D.
Kompositionsstruktur-D.
Verteilungs-D.
Paket-D.
Use Case-D.
Aktivitäts-D.
Zustands-D.
Sequenz- D.
Kommunikations- D.
Zeit-D.
InteraktionsÜbersichts-D.
se
Folie 19
Modellierung der Anwendungsfunktionalität aus der
Sicht der Anwender
Geschäftsprozesse
Sehr einfache Diagramme
Akteur: Nutzer des Systems
14.10.2009
Use Case
se
Use Case
Verbindungen abfragen
Fahrgast
Beziehung: der Akteur
benutzt einen Use Case
System
Fahrkarten bestellen
Folie 20
Beschreibt den Ablauf eines Use Case
Ist auch für parallele Abläufe geeignet
Aktivität
Verbindungsstart
eingeben
14.10.2009
Aktivitätsdiagramm
Entscheidung
Verbindungsziel
eingeben
Eingaben
sind gültig
Weg
berechnen
Mind. eine Verbindung
wurde gefunden
nein
ja
Verbindungen
anzeigen
Fehlerseite
se
Folie 21
Modelliert die Zustände und
Zustandsübergänge einer Klasse
oder einer Komponente
Den Zustandsübergängen
können Ereignisse und Aktionen
zugeordnet werden
14.10.2009
Zustandsdiagramm
se
Transition
Beginn
ungültig
erfolgreiche
Belastung eines
Fahrgastkontos
storno
gültig
Zustand
Ende
Folie 22
Botschaftsfluss zwischen Objekten
Fahrkarte bestellen
: Fahrkarte
bestellen()
kunde: Person
: Kreditkarte
berechnePreis()
14.10.2009
Sequenzdiagramm
belasten(betrag)
istGueltig()
belasten(betrag)
se
Folie 23
Ähnlicher Inhalt wie beim Sequenzdiagramm
Bei vielen Objekten mit wenig Botschaftsfluss geeignet
14.10.2009
Kommunikationsdiagramm
3: berechnePreis( )
Reihenfolge
1: start( )
: Fahrkarte
2: bestellen( )
4: belasten(Waehrungsbetrag)
: Fahrgast
: Bestellvorgang
Botschaft
se
Beteiligtes
Objekt
: Person
5: istGueltig( )
6: belasten(waehrungsbetrag)
: Kreditkarte
Folie 24
Ab UML 2.0
Zeigt das Verhalten von Objekten mit genauer
Zeitachse.
Speziell für Hardware dominierte oder Realtime
Software.
14.10.2009
Timing diagram
se
Quelle: www.oose.de, www.sparxsystems.com.au
Folie 25
Ab UML 2.0
Zeigt den Zusammenhang
zwischen einzelnen
Interaktionsdiagrammen
auf
Elemente wie im
Aktivitätendiagramm
14.10.2009
Interaktionsübersicht
se
Folie 26
UML – Diagramm Layout
Header
Ö Syntax:
•
[<DiagrammTyp>]<DiagrammName>[<Parameter>]
Ö DiagrammTyp (Kürzel) - optional
•
cd, sd, uc, ...
Header
14.10.2009
Ö DiagrammName
Ö Parameter – optional
•
wird nur selten benutzt
Inhalt
Inhalt
Ö Graphisches Diagramm des angegebenen Typs
Anmerkung
se
Ö Die Diagramm-Darstellung wird letztendlich vom Werkzeug
festgelegt
Folie 27
www.ibm.com/software/rational
14.10.2009
UML Werkzeuge: Rational Rose
se
Folie 28
14.10.2009
14.10.2009
UML Werkzeuge: Argo UML
www.argouml.org
se
se
Folie 29
UML Werkzeuge: Rational XDE
www.ibm.com/software/rational
Folie 30
http://www.sparxsystems.com/
14.10.2009
UML Werkzeuge: Enterprise Architect
se
Folie 31
www.borland.com/de/products/together/index.html
14.10.2009
UML Werkzeuge: Borland Together
se
Folie 32
R1
http://www.visual-paradigm.com/
14.10.2009
UML Werkzeuge: Visual Paradigm
se
Folie 33
Folie 33
R1
Letzte Folie 24.10.
RS; 24.10.2008
UML im Projektverlauf
Use Case D.
Klassendiagramm
(techn. Modell)
Sequenzd.
Verteilungsd.
Komponentend.
Zustandsd.
Management
14.10.2009
Engineering
Aktivitätend.
Klassendiagramm
(Domänenmodell)
se
Quelle: Rational Software
Folie 34
Rumbaugh, James; Jacobson, Ivar; Booch, Grady : „The
unified modeling language reference manual“, Second
Edition, Addison-Wesley, 2004
Jeckle, Mario; et al. : „UML2 glasklar“, Hanser Verlag, 2004
14.10.2009
UML Literatur
se
Folie 35
UML Literatur
14.10.2009
Martin Fowler: „UML Distilled. A Brief Guide to the Standard
Object Modeling Languange“, Addison-Wesley, 2003
Kendall Scott : „UML Explained “, Addison-Wesley, 2001
se
Folie 36
Erhältlich über www.uml.org
Gliedert sich in zwei Dokumente:
Ö Infrastucture (http://www.omg.org/docs/formal/05-07-05.pdf)
Definition der grundlegenden Sprachelemente.
Ö Superstructure (http://www.omg.org/docs/formal/05-07-04.pdf)
Definition der Diagrammtypen
Überwiegend in UML Klassendiagrammen und OCL (Object
Constraint Language) spezifiziert.
14.10.2009
UML Spezifikation (1)
se
Folie 37
14.10.2009
UML Superstructure: Class
se
Folie 38
14.10.2009
UML Spezifikation: Classifier
se
Classifier
Classifier
Classifier
Classifier
Classifier
(from Kernel)
(from Templates)
(from UseCases)
(from Dependencies)
(from PowerTypes)
Actor
Artifact
(from UseCases)
(from Artifacts)
Classifier
(from Collaborations)
DataType
Association
(from Kernel)
(from Kernel)
Interface
(from Interfaces)
PrimitiveType
Enumeration
(from Kernel)
(from Kernel)
InformationItem
Signal
(from InformationFlows)
(from Communications)
Class
BehavioredClassifier
StructuredClassifier
(from Kernel)
(from BasicBehaviors)
(from InternalStructures)
Interface
Class and its
increments
BehavioredClassifier
(from Interfaces)
CommunicationPath
AssociationClass
Behavior
Class
UseCase
Collaboration
(from Nodes)
(from AssociationClasses)
EncapsulatedClassifier
(from UseCases)
(from Collaborations)
(from Ports)
Behavior
(from CompleteActivities)
Class
Activity
Interaction
StateMachine
OpaqueBehavior
(from FundamentalActivities)
(from BasicInteractions)
(from BehaviorStateMachines)
(from StructuredClasses)
Activity
(from BasicActivities)
Activity
(from StructuredActivities)
ProtocolStateMachine
Component
Node
(from BasicComponents)
(from Nodes)
(from ProtocolStateMachines)
Activity
(from CompleteActivities)
Component
(from PackagingComponents)
Device
ExecutionEnvironment
(from Nodes)
(from Nodes)
Folie 39
UML Spracharchitektur
M3
MetaMetamodell
Definiert als UML
Infrastructure
Meta Object Facility,
MOF
Class
<<instanceof>
14.10.2009
M2
Metamodell
Definiert als UML
Superstructure
<<instanceof>
Attribute
Class
<<instanceof>
M1
Modell
Domänenmodell
in UML
<<instanceof>
<<instanceof>
Firma
Person
Bezeichnung
Name
Vorname
Gehalt
<<instanceof>
M0
Association
<<instanceof>
<<instanceof>
Objekte der
Applikation
se
Folie 40
In der Praxis werden die verschiedenen Diagramme
unterschiedlich stark eingesetzt
Werkzeuge spielen eine wichtige Rolle
Nicht alle Werkzeuge unterstützen die UML 2.0
Praktisch niemand kennt und nutzt die UML vollständig
14.10.2009
Anmerkungen zur UML
se
Folie 41
Use Cases
Rainer Schmidberger
[email protected]
se
Formalisierung und Beschreibung der funktionalen
Anforderungen
14.10.2009
Nutzen von Use Cases
se
Quelle: Alan Chapman
Folie 43
Definition
"A use case is a piece of functionality in the system
that gives a user a result of value"
14.10.2009
"All the use cases together make up the use case
model, which describes the complete functionality of
the system"
"A use case specifies a sequence of actions,
including variants, that the system can perform and
that yields an observable result of value to a
particular actor"
se
Aus "The Unified Software Development Process", Ivar
Jacobson u.a., Addison-Wesley, 1999
Folie 44
Ein Use Case
14.10.2009
Use Case (1)
Ö beschreibt mehrere zusammenhängendende Aktivitäten,
Ö die von einem oder mehreren Akteuren durchgeführt
(genutzt) werden,
Ö um ein Ziel zu erreichen bzw. ein gewünschtes Ergebnis zu
erstellen
Akteur: Nutzer des Systems
Use Case
se
Fahrgast
Beziehung: der Akteur
benutzt einen Use Case
System
Fahrkarten bestellen
Fahrscheinsystem
Folie 45
14.10.2009
Use Case (2)
Use Cases beschreiben aus Anwendersicht den
Systemnutzen
Einfaches Kommunikationsmedium mit "Stakeholdern"
(Anwendern, Kunden, Management, ...)
Die Gesamtmenge der Use Cases beschreibt das
System, das an der Systemschnittstelle beobachtet
werden kann.
Abgrenzung zur Aktivität: ein Use Case umfasst viele
Aktivitäten
se
Folie 46
14.10.2009
Use Case (3)
Bezeichnung durch Substantiv + Verb (Infinitiv) z.B.
ÖEinstellung durchführen
ÖPrämie berechnen, usw.
(Geschäfts-)Prozesse können als Use Case modelliert
werden
Systemgrenzen werden festgelegt
Systemnutzer (=Akteure) werden festgelegt
Einsatzmöglichkeiten: Ist-Analyse, Soll-Analyse und
Spezifikation
Achtung: ein Use Case ist kein Softwaremodul!
Strukturierung der funktionalen Anforderungen
se
Folie 47
Use-Case-Diagramm
dient der Visualisierung und als Übersicht über die
vorhandenen Use Cases und Akteure
enthält die Beziehungen zwischen Akteuren und Use
Cases
Tipp: mehrere Use-Case-Diagramme erstellen!
14.10.2009
ÖJedes Use-Case-Diagramm sollte einen wichtigen Aspekt
des Systems wiederspiegeln!
se
Folie 48
14.10.2009
Akteure
Akteure sind
MA Verwaltung
Rollen (Personen oder Systeme, z.B. Benutzer, Rechner, externe
Datenbanken, auch Ereignisse oder Termine)
ÖAkteure werden im Begriffslexikon beschrieben
ÖAkteure werden im Use-Case-Diagramm eingezeichnet
ÖAkteure werden im Diagramm durch Assoziationen mit den Use Cases
verbunden, an denen sie beteiligt sind
selbst nicht Teil des zu beschreibenden Systems,
direkt mit einem oder mehreren Use Cases verbunden und
kommunizieren mit diesem
in der Regel aktiv, das heißt sie können Vorgänge anstoßen
Achtung: es werden nur die Akteure mit einem Use Case
verbunden, die an der Interaktion mit dem System selbst
teilnehmen!
se
Folie 49
Include-Beziehung
Use Case A fügt an einer
bestimmten Stelle Use Case B ein
Use Case A
<<include>>
14.10.2009
Use Case B
Use Case A fügt Use Case B an einer
gekennzeichneten Stelle ein
Use Case B kennt Use Case A nicht
Mehrfach vorkommende Use-Case-Abschnitte
werden nur einmal beschrieben
Tipp: man sollte diese Dekomposition nicht
übertreiben! Jeder Use Case soll erkennbaren Nutzen
behalten.
se
Folie 50
14.10.2009
Extend und Generalisierung
Es gibt weitere Beziehungen, die vorsichtig verwendet
<<extend>>
werden sollten:
A
B
extend-Beziehung: B erweitert A an einer dort
festgelegten Stelle
Generalisierungsbeziehung: B ist eine spezielle
Ausprägung von A
Beispiele:
Benutzer validieren
se
Auslandsstudent Immatrikulieren
Fremdwährung abheben
<<extend>>
<<extend>>
Kennwort prüfen
Biometriemerkmale prüfen
Geld abheben
Student Immatrukulieren
Achtung: die Semantik beider
Beziehungen ist nicht scharf spezifiziert!
Folie 51
Beispiel: Bankomat
Fremdwährung abheben
<<extend>>
14.10.2009
<<include>>
Geld abheben
Legitimierung prüfen
Bankkunde
<<include>>
Kontostand abfragen
se
Folie 52
Beispiel: Seminarbuchungssystem
14.10.2009
uc: Seminarbuchungss.
Registrierung via Group Directory,
HR-Online
Surfer
<<include>>
Kann soviel
wie...
Katalogfunktionen
<<include>>
Produktdaten anzeigen
Sowohl das Produkt, als
auch der MA muss
hierfür freigegeben sein
Eigene Bildungshistorie anzeigen
Selbst-Buchung
Mitarbeiter
Kann soviel
wie...
Termin buchen
se
Produkt suchen
Vorgesetzter
Auf anderen Termin Umbuchen
Mitarbeiter buchen
Buchung stornieren
Ersatzteilnehmer buchen
Reports zu MA-Buchungen anzeigen
Folie 53
14.10.2009
Use-Case-Beschreibung (1)
Beschreibung erfolgt
in verständlicher Sprache
mit konkretem Nutzen für
den initiierenden Akteur
präzise und eindeutig
mit überprüfbaren
Ergebnissen
mit definierten Begriffen
(Begriffslexikon)
semi-formal (strukturiert)
einheitlich
Use Case Dokumentation
Name:
Akteure:
Seminar buchen
Kunde
Vorbedingung:
Seminar ist freigegeben und hat noch
ausreichend Plätze frei
Regulärer Ablauf:
Der Kunde selektiert ein Seminar und ...
Nachbedingung:
Der Kunde ist auf das entsprechende Seminar
gebucht
Alternative Abläufe:
- das Seminar ist ausgebucht
- der Kunde hat keine Buchungsberechtigung
se
Folie 54
Name des Use Case
Beteiligte Akteure
Vorbedingung
ÖVoraussetzungen vor der Ausführung des Use Case
Regulärer Ablauf
ÖBeschreibung einzelner Aktionen innerhalb des Use Case in
Form verbaler Szenarien (Einzelaktivitäten)
ÖEvtl. Diagramme und Entscheidungstabellen
ÖBegriffe sorgfältig verwenden (Begriffslexikon)
14.10.2009
Use-Case-Beschreibung (2)
Nachbedingung
ÖZusicherungen, die nach Use-Case-Ende eintreffen müssen
Alternative Abläufe
se
ÖFehlerfälle
ÖSonderfälle
Folie 55
Use Case Beschreibung (3)
Name des Use Case
ÖPersonalausweis beantragen
Vorbedingung
ÖAntragsteller hat sich legitimiert und entsprechende Aktion
angstoßen. Es handelt sich nicht um einen Erstantrag
Regulärer Ablauf
14.10.2009
ÖBerechtigungen des Antragstellers werden geprüft (Siehe
Verordnung XY)
ÖZuständiges Amt wird über die Wohnsitzangaben ermittelt. Für
Wohnsitzlose gilt Sonderregelung 4711.
ÖGebührenrechnung wird erstellt. Abwicklung abhängig vom
Antragsteller über Kreditkarte oder Bankeinzug
ÖZusammenstellen des Antragpakets und weiterleiten an Stelle 0815
Nachbedingung
ÖDer Antragsteller hat jetzt den Status "beantragt", weitere Anträge
können solange nicht entgegengenommen werden
Alternative Abläufe
se
ÖErstanträge werden über use Case ABC behandelt
Folie 56
Beschreibt (grafisch) den Ablauf eines Use Case
Aktivität
Verbindungsstart
eingeben
14.10.2009
Beschreibung durch Aktivitätsdiagramm
Entscheidung
Verbindungsziel
eingeben
se
Eingaben
sind gültig
Weg
berechnen
Mind. eine Verbindung
wurde gefunden
nein
ja
Fehlerseite
Verbindungen
anzeigen
Folie 57
Beschreibt (grafisch) die beteiligten Instanzen und den
zeitlichen Ablauf eines Use Case
: Fahrgast
:
Reservierungssystem
:
Bestellsystem
:
Abrechnungssystem
1: buchung( )
14.10.2009
Beschreibung durch Sequenzdiagramm
3: berechnen( )
2: reservieren( )
se
Folie 58
14.10.2009
Vor- und Nachteile
Vorteile
Einfache Darstellung, leicht verständlich
Use Cases sind innerhalb der UML klar beschrieben
Es sind (sehr gute) Werkzeuge verfügbar
Erweiterungsmöglichkeit um Aktivitätsdiagramme und
Sequenzdiagramme
Greifen den verbreiteten Prozess-Gedanken auf
Nachteile
Beschreibung ist nicht formalisiert
Konsistenzen sind automatisch nicht prüfbar
Übergang zur Modellierung der fachlichen Klassen ist
brüchig
se
Folie 59
Business Use Case
Beschreibung der Fachlichkeit ohne
Berücksichtigung, welche Teile des Prozesses mit ITgestützt ablaufen und welche nicht
Unterscheidung „manuell“ oder „IT-gestützt“ über
den <<stereotyp>>
<<include>>
14.10.2009
Business Use Case
Seminar durchführen
Namenskärtchen verteilen
Use Case
Eingrenzung auf die IT-gestützten Prozesse
Ö
se
Bei e-Commerce-Systemen entsprechen die Business
Use Cases den Use Cases
Folie 60
Klassen-Diagramme
Rainer Schmidberger
[email protected]
se
Die Darstellung von
Klassen erfolgt als
Rechteck mit den
Bereichen
Person
Ö Klassenname
Ö Attributliste
Ö Methodenliste
Attribute
14.10.2009
UML Klassen (1)
Methoden
se
Folie 62
14.10.2009
UML Klassen (2)
Klassenname mit stereotype
Angabe
Attribute mit Datentypen
und Sichtbarkeiten und
Vorbelegungen
Methoden mit Signaturen
und Sichtbarkeiten
Sichtbarkeiten:
Ö public (+)
Ö protected (#)
Ö private (-)
Die Datentypen sind von
der verwendeten
Programmiersprache
abhängig!
se
<<entity>>
Person
-name : String
-vorname : String
-gehalt:GeldBetrag
+setGehalt(g:GeldBetrag)
+getGehalt() : GeldBetrag
+updateGehalt()
Folie 63
Attribute
Person
-name
-vorname
#gehaltsgruppe : int = 0
+/gehalt
anzahlPersonen : int
14.10.2009
Berechnetes Attribut
(Derived).
Berechnungsformel ist
nicht Teil des UMLModells
Klassenattribut: Attribut
steht allen Objekten
der Klasse Person nur
einmal zur Verfügung
se
Folie 64
14.10.2009
Methoden
Signaturen werden oft
nicht angegeben
Private Methoden
werden oft nicht
angegeben
Klassenmethode
(Aufruf über
Klassenbezeichner,
unterstrichen)
Abstrakte Methode
(wird kursiv gedruckt),
erzwingt
Implementierung in
den Kindklassen
se
Person
+setGehalt(g:GeldBetrag)
+getGehalt() : GeldBetrag
+getAnzahlPersonen() : int
+updateGehalt()
Folie 65
14.10.2009
Assoziationen
"Beziehungen", "Verbindungen" oder
"Navigationspfade" zwischen Klassen werden als
Assoziation bezeichnet
Verbindungen zwischen Objekten werden als Link
bezeichnet
In der UML werden Assoziationen sehr differenziert
beschrieben
Assoziationen sind logische Beziehungen, sie müssen
nicht notwendigerweise durch ein
Programmkonstrukt direkt im Code implementiert sein
se
Folie 66
Multipizität, Person ist 1
oder kein Firma-Objekt
zugeordnet
Person in der Rolle als
"Arbeitnehmer"
Person
0..1
Arbeitnehmer
0..*
arbeitet für
Firma
Arbeitgeber
14.10.2009
Assoziationen
se
Multipizität, Firma
sind kein, 1 oder viele
Personen-Objekte
zugeordnet
Firma in der Rolle als
"Arbeitgeber"
Name der Beziehung, wird
von links nach rechts gelesen
Folie 67
Navigierbarkeit
Die Pfeilrichtung zeigt die Navigierbarkeitsrichtung an.
Beidseitig navigierbare Assoziationen haben aber
keine Pfeile.
Nichtspezifizierte Navigierbarkeit hat ebenso keine
Pfeile
0..1
14.10.2009
Person
arbeitet für
Firma
Arbeitgeber
Ö Objekte der Klasse Person "kennen" ihren Arbeitgeber,
Objekte der Klasse Firma "kennen" aber ihre Mitarbeiter
nicht.
se
Folie 68
Die Multiplizität zeigt an, wie viele Objekte der
jeweiligen Klasse an der Assoziation teilnehmen
Ö Typische Multiplizität: 0..1, 1, 0..*, 1..*
Es können auch spezielle Multiplizitäten verwendet
werden wie z.B. 5, 29 oder 5..290
14.10.2009
Multiplizität
se
Person
Auto
Arbeitnehmer
0..*
arbeitet für
0..1
Firma
Arbeitgeber
4
Rad
Folie 69
Aggregation und Komposition
14.10.2009
Ganzes-Teil-Assoziation
Aggregierte Objekte werden von dem besitzenden Objekt
dominiert
I.Allg. ist kein externer Zugriff auf aggregierte Objekte möglich
Komposition: Die Lebensdauer (Instanzierung und Freigabe)
werden vom dominierenden Objekt beherrscht
Aggregation
Person
0..*
Adresse
0..*
StudentRolle
1
Komposition
Person
1
se
Folie 70
Assoziationen selbst können über Attribute (und auch
Methoden) verfügen
Die Assoziationsklasse repräsentiert die Assoziation
Insbesondere bei n:m-Assoziationen werden häufig
Assoziationsklassen verwendet
schreibt
0..*
Prüfung
Student
0..*
14.10.2009
Assoziationsklassen (1)
se
PrüfungsTeilnahme
hatTeilgenommen : boolean
note : Note
Auffälligkeit : String
07.11.
Folie 71
Assoziationsklassen (2)
Eine n:m Assoziation mit Assoziationsklasse (A) ist
semantisch mit einer 1:n und m:1-Assoziation (B)
gleichzusetzen
schreibt
Student
0..*
Prüfung
0..*
14.10.2009
A
PrüfungsTeilnahme
B
0..*
Student
PrüfungsTeilnahme
0..*
1
1
Prüfung
se
Folie 72
Bestehen mehrere Assoziationen zwischen zwei
Klassen, so werden oft rollenbeschreibende
Assoziationsklassen eingeführt
Arbeitnehmer
Person
se
arbeitet für
0..*
0..*
Arbeitgeber
Aktionär
investiert in
0..*
14.10.2009
Umgang mit Assoziationen
Kunde
0..*
Kapitalanlage
bezieht Produkte von
0..*
Person
Firma
0..*
Lieferant
0..*
0..*
Firma
PersonRolle
rolle
Folie 73
Rekursive Assoziationen
14.10.2009
Assoziationen können zur selben Klasse verbunden
sein
Damit ist nicht gemeint, dass ein Objekt mit sich selbst
in Beziehung steht, sondern zu Objekten der selben
Klasse!
Rekursive Assoziationen können auch
Assoziationsklassen haben
Vorgesetzter
0..1
Person
Arbeitnehmer
0..*
0..1
arbeitet für
Firma
Arbeitgeber
0..*
Mitarbeiter
se
Folie 74
Attribute, die wesentlich die Rolle eines Objektes in der
Beziehung beschreiben oder überhaupt die Beziehung
erst herstellen
Die qualifizierenden Attribute werden der Assoziation
nicht der Klasse zugeordnet
14.10.2009
Qualifizierende Attribute
se
Aufführung
aufführungsDatum: Date
SitzplatzNr : String
0..1
1
Eintrittskarte
Qualizierende
Attribute
Folie 75
Assoziationseinschränkungen
14.10.2009
Spezielle Regeln einer Assoziation werden als
Constraint bezeichnet
Ab UML 2.0: Object Constraint Language OCL
Die Darstellung erfolgt in { }
Typische Beispiele sind Sichtbarkeit oder Änderbarkeit
(z.B. ordered, addOnly)
0..1
Arbeitnehmer
Person
{ordered}
Firma
arbeitet für
0..*
se
Folie 76
Stellen Erweiterungen des UML-Standards dar
Vergeben einem UML-Element (wie z.B. einer Klasse) ein
spezielle Ausprägung
Darstellung des stereotyp in<< >> über dem
Klassennamen
Häufig verwendete Stereotypen:
14.10.2009
Stereotypes
se
<<boundary>>
Klassen, die mit der Außenwelt kommunizieren. Sie bilden
Schnittstellen zwischen System und Umwelt
<<control>>
Klassen, die Interaktionen zwischen anderen Klassen steuern
<<entity>>
Klassen, die selbst passiv sind und keine Interaktionen
auslösen (i.Allg. zur Datenhaltung)
<<utility>>
Keine Klasse, nicht instanzierbar, kapselt globale Variablen
und Funktionen. Zur Abbildung Nicht-OO-Bibliotheken
geeignet (z.B. Mathematik-Funktionen)
Folie 77
Vererbung
Alle Eigenschaften (also Methoden, Attribute oder
Beziehungen) einer Klasse (Vaterklasse) werden an die
Kindklassen übertragen
Die Kindklassen können weitere eigene Eigenschaften
definieren und auch ererbte Eigenschaften überschreiben
VersicherungsVertrag
14.10.2009
VersicherungsNehmer
AbschlussDatum
Generalisierung
Spezialisierung
SachVersicherungsVertrag
LebenVersicherungsVertrag
JahresBeitrag
VersicherterGegenstand
RisikoLVAnteil
BegünstigtePerson
Laufzeit
se
Folie 78
1

se
VersicherungsNehmer
AbschlussDatum

Zunächst entsteht aus den
bekannten Anforderungen
eine konkrete Klasse.
Motivation zur Vererbung
besteht nicht
3
2
VersicherungsNehmer
AbschlussDatum
JahresBeitrag
14.10.2009
Entstehung von Vererbung
VersicherungsNehmer
AbschlussDatum
JahresBeitrag
VersicherungsNehmer
AbschlußDatum

Es wird eine
mögliche Wiederverwendbarkeit
erkennbar
Allgemeingültige
Merkmale werden
generalisiert
Eine weitere Klasse nutzt die
zuvor stattgefundene
Generalisierung
Dieser Vorgang wird nun als
Spezialisierung bezeichnet
LebenVersicherungsVertrag
JahresBeitrag
RisikoLVAnteil
BegünstigtePerson
Laufzeit
Folie 79
Vererbung vs. Aggregation
Realisierung einer "ist-ein" Beziehung im Gegensatz
zu einer "hat-ein" Beziehung der Assoziation
Ö Ein LV-Vertrag ist einer Versicherungsvertrag
Ö Ein Auto hat Räder
14.10.2009
Vererbung im fachlichen Kontext ist selten sinnvoll
Alternative zur Vererbung ist eine Aggregation
A
B
Person
Person
Student
se
0..1
Student
Ein Student ist eine Person (?)
Wie wird mit dem Student in (A) verfahren,
wenn das Studium beendet wurde?
Folie 80
14.10.2009
Vererbung abstrakter Methoden
Wird eine abstrakte Methode vererbt, wird deren
Implementierung in den Kindklassen erzwungen
Vorteil: lässt sich auch keine generische Implementierung festlegen, so ist doch ein gemeinsames
Interface erzwingbar

PersistentesObject

se
Die Klasse Person
implementiert
die abstrakte
Methode
Store()
getStoreSQL() : String
Person

Eine abstrakte
Methode erzwingt
die Implementierung
in den Kindklassen
Klassen mit
abstrakten
Methoden können
selbst keine Objekte
instanzieren
Folie 81
Interface
14.10.2009
Ein Interface ist einer Klasse mit ausschließlich
abstrakten Methoden gleichzusetzen
Interfaces werden "realisiert"
Eine Klasse kann viele Interfaces realisieren
Interfaces definieren Methoden, die von den
Realisierungen implementiert werden müssen
Label-Darstellung:
Icon-Darstellung:
Veranstaltung
datumVon : Date
datumBis : Date
bezeichnung : String
preis : Waehrungsbetrag
Veranstaltung
datumVon : Date
datumBis : Date
bezeichnung : String
preis : Waehrungsbetrag
<<Interface>>
PersistentesObjekt
Store()
Delete()
Load()
hatPlaetzeFrei()
einbuchen()
Store()
Delete()
Load()
PersistentesObjek
t
hatPlaetzeFrei()
einbuchen()
Store()
Delete()
Load()
Store()
Delete()
Load()
se
Folie 82
Beispiel eines Klassendiagramms (1)
0..n
Singledate
Begin : Date
End : Date
Objectives : Memo
Content : Memo
AdditionalInformation : Memo
Folder
Field : Text (30)
OrderNo : Integer
Title : Text (100)
VHasChildrenProduct : Boolean
VHasChildrenFolder : Boolean
Description : Memo
ExportControl : Boolean
+Logisticprofile
1
14.10.2009
+module0..n
0..n
0..n
TrainingProduct
ID : Text (30)
Title : Text (100)
DeliveryMode : Selection
TrainingSection : Selection
CourseType : Selection
ExportControl : Integer
NewUntil : Date
0..n ValidUntil : Date
ModuleOnly : Boolean
MultipleRegistration : Boolean
+Copy
VHasEvents : Boolean
RegistrationMode : Selection
VSumPreRegistration : Integer
ReleaseState : Selection
Extern : Boolean
Comment : Memo
RefreshCycle : Number
RefreshCycleUnit : Selection
IgnoreTimeOverlap : Integer
NumberField1 : Integer
0..1
NumberField5 : Number
+Origin
PlanningTimeFrom : Date
PlanningTimeTo : Date
1
+LogisticprofileProduct
0..n
0..1
+ProductPreRegistration
+Predecessor
0..n
+Successor
0..n
0..n
TrainingProductPredecessor
NecessaryType : Selection
PositionX : Integer
PositionY : Integer
Role : Selection
NecessaryLevel : Number
Trainer
Contract : Selection
ContractComment : Text (100)
ContractDate : Date
Comment : Memo
TrainerType : Selection
DefaultHoursPerYear : Integer
Organizer
Initial : Text (30)
LogonName : Text (30)
Password : Text (15)
ActiveUntil : Date
PasswordValidUntil : Date
DbPasswort : Text (30)
FileNameImage : Text (50)
Type : Integer
AssignedCostCenters : Memo
VName1 : Text (50)
VName2 : Text (50)
VOrganizationName2 : Text (50)
EcadiaPassword : Text (30)
0..*
0..1
1
TrainerAssignment
MainTrainer : Integer
State : Integer
HotelNeed : Selection
InvitationDate : Date
TrainerRole : Selection
0..n
ResourceAssignment
DateFrom : Date
DateTo : Date
InterpretTimeframe : Selection
HourFrom : Date
HourTo : Date
FullDay : Boolean
AssignmentText : Text (100)
Comment : Text (100)
OccupancyMode : Selection
ReservationValidUntil : Date
ExternalComment : Memo
InternalComment : Memo
DifferentDuration : Number
DifferentDurationUnit : Integer
OccupancyReason : Integer
RoomAssignment
RoomRole : Selection
SeatingOrder : Selection
0..n
0..n
Enroll
RegistrationDate : Date
CancellationDate : Date
Kostenpflichtig : Boolean
State : Selection
Attendance : Integer
Comment : Memo
ValidUntil : Date
Certification : Boolean
InviatationSent : Selection
InvitationSentDate : Date
HotelNeed : Selection
Priority : Integer
OrderNo : Integer
CommentForIncompleteAttendance : Memo
0..n DifferentAttendanceDateFrom : Date
DifferentAttendanceDateTo : Date
PreferedAttendanceFrom : Date
+PreRegistration
PrefferedAttendanceTo : Date
OriginType : Selection
QualificationReached : Selection
LearningResult : Selection
LearningResultCommentBemerkung : Memo
VParticipantID : Text (30)
+Parent 0..1 VParticipantName1 : Text (50)
VParticipantName2 : Text (50)
VParticipantPhone : Text (30)
VParticipantOrgName1 : Text (50)
VParticipantOrgName2 : Text (50)
VParticipantEMail : Text (100)
VHasHotelbooking : Boolean
VEventDateFrom : Date
VEventDateTo : Date
0..n
VProductID : Text (30)
VProductTitle : Text (100)
DifferentDuration : Number
DifferentDurationUnit : Integer
VContactPersonr : Text (100)
CancellationReason : Selection
+Child
DesiredLanguage : Selection
ShowInTrainingHistory : Boolean
TextField0 : Text (100)
1
0..n
OrganizerGroup
Name : Text (100)
DefaultCostCenter : Text (50)
DefaultContingenteKey : Text (50)
Initial : Text (30)
ContingenteKey : Text (30)
0..1
PartnerProperty
name : Text (100)
description : Memo
Type : Selection
group : Selection
hasValues : Boolean
valueSelection : Selection
expiry : Integer
expiryUnit : Selection
rangeFrom : Integer
rangeTo : Integer
+organizerAdmin
+contactPerson
1
0..n
0..n
+groupMember
1
0..n
Room
RoomName : Text (50)
AmountSeats : Integer
RoomID : Text (30)
SuitableForHandicap : Integer
Floor : Selection
Size : Integer
DefaultSeatingOrder : Selection
Phone : Text (50)
Resource
CheckTimeoverlapping : Boolean
DefaultBookingType : Selection
+TrainingRoom
0..n
0..n
+trainingProgram
se
1
Event
ID : Text (30)
Semester : Text (50)
DateFrom : Date
DateTo : Date
HourFrom : Date
HourTo : Date
HourFromFirstDay : Date
HourToLastDay : Date
SingledatesText : Text (50)
Status : Integer
CancelationReason : Selection
Comment : Memo
ExportControl : Integer
MaxEnroll : Integer
MinEnroll : Integer
VSumEnroll : Integer
VSumWaitingList : Integer
TextBlock1 : Memo
TextBlock2 : Memo
TextBlock3 : Memo
VSumNonShown : Integer
VSumInvited : Integer
VSumTempEnroll : Integer
VSumAttendedParticular : Integer
VSumCancellationParticipant : Integer
VSumWaitinglistExpicit : Integer
VSumCancellationOrganizer : Integer
VSumInterested : Integer
VSumAppeard : Integer
0..n VRooms : Text (50)
VTrainers : Text (50)
VSumAttended : Integer
Duration : Number
DurationUnit : Integer
DeadlineDays : Integer
WebInfo : Memo
VProductTitle : Text (100)
0..* VProductID : Text (30)
TitleDiffering : Text (100)
Language : Selection
VContactPerson : Text (100)
inSingledates : Boolean
InviteBeforeEvent : Integer
ProceedOnDays : Selection
0..1
0..1
TrainingProgram
EventNote
creationDate : Date
content : Memo
accessMode : Selection
publishingMode : Selection
0..1
0..n
ExplorerShortcut
Type : Selection
OrderNo : Integer
PositionX : Integer
PositionY : Integer
1
0..n
0..n
0..n
+parent
TrainingProductContent
Title : Text (100)
Targetgroup : Memo
Prerequisites : Memo
Content : Memo
Targets : Memo
Methodology : Memo
Introduction : Memo
Facilitator : Memo
TechnicalRequirements : Memo
Language : Selection
CommentDuration : Text (100)
CommentParticipantAmount : Text (100)
CommentPrice : Text (100)
ValidUntil : Date
ResourceSingledateAssignment
1
+child
TrainingProgramEvent
Partner
Name1 : Text (50)
Name2 : Text (50)
PartnerID : Text (30)
1
Status
: Selection
CostCostCenter : Text (100)
IncomeCostCenter : Text (100)
Comment : Memo
DebitorID : Text (15)
CreditorID : Text (15)
VATFlag : Boolean
AccountigProcedure : Selection
DefaultCurrency : Selection
Extern : Boolean
Type : Selection
ContraktID : Text (30)
VAddressStreet : Text (100)
VAddressCountry : Text (6)
VAddressZip : Text (30)
VAddressCity : Text (100)
VPhone : Text (30)
VFax : Text (30)
VEMail : Text (100)
VIsTrainer : Boolean
VIsOrganizer : Boolean
VIsLocation : Boolean
VIsHotel : Boolean
VContactPerson : Text (100)
DefaultLanguage : Selection
ContingenteKey : Text (50)
FormOfAddress : Selection
JobTitle : Text (100)
1TextField4 : Text (100)
+Participant NumberField3 : Integer
1
0..n
0..n
0..1
1
0..n
0..n
PartnerPropertyAssignment
value : Integer
comment : Memo
status : Selection
partnerPropertyType : Selection
creationDate : Date
selection1 : Selection
selection2 : Selection
Address
AddressField1 : Text (100)
Street : Text (100)
Country : Text (6)
Zip : Text (30)
City : Text (100)
POBox : Text (30)
POBoxZip : Text (30)
POBoxCity : Text (100)
Type : Selection
ValidUntil : Date
0..n
1
0..n
Telecom
Phone : Text (30)
Fax : Text (30)
MobilePhone : Text (30)
EMail : Text (100)
HomePage : Text (100)
Type : Selection
0..n
0..n
+EventLocation 0..1
1
0..1
ExternalEnroll
ContractNo : Text (50)
Comment : Memo
ConfirmationBySupplier : Date
QualityOfTrainingComment : Memo
TrainingDuartion : Number
SupplierProductID : Text (30)
TrainingTitle : Text (100)
State : Integer
DateFrom : Date
DateTo : Date
LocationName : Text (50)
Location
Description : Memo
TravelInfoPublic : Memo
TravelInfoCar : Memo
MapFileName : Text (50)
AdditionalServices : Memo
0..1
0..n
1
0..1
1
+ExternalSupplier
Organization
VHasChilds : Boolean
+Child
0..n
+Member
Person
DayOfBirth : Date
EntryDate : Date
0..n ExitDate : Date
Funktion : Selection
EducationState : Selection
PlaceOfBirth : Text (50)
0..1
+Parent
TrainingProgramAssignment
OrderNo : Integer
IdealBeginWeekday : Integer
MinDistanceToPredecessor : Integer
MaxDistanceToPredecessor : Integer
BookingType : Selection
ColorInTimeTable : Selection
Folie 83
Beispiel eines Klassendiagramms (2)
Room
RoomName : Text (50)
AmountSeats : Integer
RoomID : Text (30)
SuitableForHandicap : Integer
Floor : Selection
Size : Integer
DefaultSeatingOrder : Selection
Phone : Text (50)
contains
0..n
+TrainingRoom
0..n
0..n
contains
0..n
EquipmentAssignment
amount : Integer
day : Integer
daySection : Selection
amountInterpretation : Selection
deliveryBy : Selection
neccessity : Selection
roomRole : Selection
comment : Memo
0..n
Equipment
Name : Text (50)
Description : Memo
SoftwareKey : Text (50)
Type : Selection
1
0..n
14.10.2009
Location
Description : Memo
TravelInfoPublic : Memo
TravelInfoCar : Memo
MapFileName : Text (50)
AdditionalServices : Memo
0..n
+EventLocation
requires
0..1
+Responsible
0..1
Organizer
+OrganizerContent Initial : Text (30)
LogonName : Text (30)
Password : Text (15)
ActiveUntil : Date
0..1
PasswordValidUntil : Date
DbPasswort : Text (30)
+OrganizerEvent
FileNameImage : Text (50)
Type : Integer
0..1
AssignedCostCenters : Memo
+OrganizerLogistic
VName1 : Text (50)
0..1
VName2 : Text (50)
EcadiaPassword : Text (30)
0..n
Event
0..n
0..1
0..n
0..n
0..n
se
Folie 84
Interaktionspunkt zwischen einem Classifier (Klasse,
Paket, Komponente, ...) und seiner Umgebung
Ö Gruppierung einer beliebigen Anzahl von Interfaces zu einem
Dienst, der einen bestimmten Dienst/ Zweck verfolgt
Ö Kapselung des Classifiers gegenüber seiner Umgebung
Ö Für ein- und ausgehende Signale
Sichtbarkeit
14.10.2009
Port
se
Ö public für eingehende Nachrichten
Ö protected, private für interne Nachrichtenverteilung
Eingehendes
Interface (required)
Ausgehendes Interface
(provided)
Port
(protected)
Port (public)
<<Component>>
Komponente A
Folie 85
Modelliert die Software-Architektur mit Bibliotheken,
Komponenten, Datenbanken, usw.
Komponente
Verbindungen
14.10.2009
Komponenten Diagramm
<<Component>>
<<Component>>
GUISteuerung
Verbindungsrechner
Konnektor
se
<<Component>>
BenutzerGUI
Anschlüsse
Interface
Port
<<Component>>
Abhängigkeiten
Fahrplandatenbank
Folie 86
14.10.2009
Komponenten Diagramm (2)
se
<<Component>>
Komponente 1
Konnektor
Interface 1
<<Component>>
Komponente 2
Interface
Port
Komponente: Abgegrenzter
Teil des Gesamtsystems
Konnektor (=required
Interface): eine von der
Komponente benötigte
Schnittstelle
Interface (=provided
Interface): eine von der
Komponente bereitgestellte
Schnitttstelle
Port: Interaktionspunkt, kann
mehrere (provided)
Interfaces enthalten
Folie 87
Siehe UML Superstructure, Kapitel 8
14.10.2009
UML Spezifikation zu Komponente
se
Folie 88
Ab UML 2.0, Composite Structure
„Kontext“-bezogenes Klassen-, Objekt oder
Komponentendiagramm
Zeigt eine „Ausprägung“ oder eine bestimmte
Konfiguration
14.10.2009
Kompositions-Struktur-Diagramm (1)
Abrechnung
Kollaborationstyp
fahrgast : Person
se
: Kreditkarte
Folie 89
Modelliert eine „Teil von“-Beziehung, ähnlich wie bei der
Aggregation
Die „Teile“ können über definierte Schnittstellen (Ports)
mit der Umgebung kommunizieren
Person
14.10.2009
Kompositions-Struktur-Diagramm (2)
: Adresse
„Teile“ werden zu
Attributen der
umhüllenden
Klasse
: Bankverbindung
se
Folie 90
Verhaltensdiagramme
Rainer Schmidberger
[email protected]
se
14.10.2009
Sequenzdiagramm
Beschreibt einzelne, genau definierte Abläufe
Dient der Beschreibung von Use Cases und zur
Beschreibung des dynamischen Verhaltens von
Objekten (Achtung: der Objekte, nicht der Klassen!)
Zeigt über die Abfolge (von oben nach unten) und
auch über die Nummerierung die zeitliche
Reihenfolge der Botschaften an
Die Summe aller Sequenzdiagramme beschreibt das
dynamische Verhalten des Systems
Botschaften werden bei der Klasse des Empfängerobjekts als Methode implementiert
se
Folie 92
Beispiel: „Fahrkarte bestellen“
14.10.2009
Sequenzdiagramm (1)
se
sd: Fahrkarte bestellen
: Fahrkarte
bestellen()
kunde: Person
: Kreditkarte
berechnePreis()
belasten(betrag)
istGueltig()
belasten(betrag)
Folie 93
Alternativen
: Fahrkarte
bestellen()
kunde: Person
: Kreditkarte
berechnePreis()
belasten(betrag)
14.10.2009
Sequenzdiagramm (2)
istGueltig()
result
alt
[ result == true ]
belasten(betrag)
[ else ]
sperren()
se
Folie 94
Schleifen
14.10.2009
Sequenzdiagramm (3)
se
: Fahrkarte
bestellen
kunde: Person
: Kreditkarte
berechnePreis
belasten(betrag)
istGueltig()
result
loop
[ restbetrag = 0 ]
belasten(betrag)
restbetrag
Folie 95
Referenzen
: Fahrkarte
bestellen
kunde: Person
: Kreditkarte
berechnePreis
belasten(betrag)
14.10.2009
Sequenzdiagramm (4)
istGueltig()
result
belasten(betrag)
ref
belasten(betrag)
restbetrag
se
Folie 96
Referenz
sd: belasten(betrag)
: Kreditkarte
...
belasten(betrag)
14.10.2009
Sequenzdiagramm (5)
se
Folie 97
Ähnlicher Inhalt wie beim Sequenzdiagramm
Bei vielen Objekten mit wenig Botschaftsfluss geeignet
3: berechnePreis( )
Reihenfolge
1: start( )
14.10.2009
Kommunikationsdiagramm
: Fahrkarte
2: bestellen( )
4: belasten(Waehrungsbetrag)
: Fahrgast
: Bestellvorgang
: Person
Botschaft
Beteiligtes
Objekt
5: istGueltig( )
6: belasten(waehrungsbetrag)
: Kreditkarte
se
Folie 98
14.10.2009
Aktivitätendiagramm
Aktivitätenfolge mit
Kontrollfluss
Wird zur Beschreibung von
Use Cases oder Klassen
eingesetzt
Wie bei
Zustandsübergängen
kann ein Ereignis je
Transition hinterlegt
werden
Verzweigungen und
Zusammenführungen
se
Aktivität
Entscheidung
(Decision)
Prüfung
korrigieren
Note bewerten
5
besser als 5
Aktivität 1
Als nicht bestanden
markieren
Noten
eintragen
Aktivität 2
Synchronisation
Aktivität 3
Folie 99
Vereinigung (Merge
Node)
Ö Einer der Eingänge muss
aktiv sein
14.10.2009
Verzweigung / Vereinigung
Verzweigung
(Decision Node)
Zusammenführung (Join
Node)
Ö Alle Eingänge müssen aktiv
sein
Gabelung (Fork Node)
Ö Alle Ausgänge werden aktiv
Ö Einer der Ausgänge
wird aktiv
se
Folie 100
Start- und Endknoten
(beendet die gesamte
Aktivität)
(beendet den Fluss an der
entsprechenden)
Sprungmarken
14.10.2009
Knoten
se
Aktivität A
Aktivität A
1
1
Aktivität B
Aktivität B
Folie 101
Signale im Aktivitätsdiagramm
Signal senden
Schlafen
Fernsehen
Signal empfangen
14.10.2009
7.00 Uhr
Empfang eines Zeitereignisses
Nachbar
lärmt
Unterbrechungsbereich
Aufstehen
Unterbrechungskante
se
Folie 102
Zeitpunkt
wählen
Gäste
einladen
Getränke
kalt stellen
Einkaufen
1
Essen
kochen
[Zusagen <
50%]
1
14.10.2009
Verlauf einer typischen Party
se
[Zusagen >= 50%]
[Essen
verbrannt]
[Essen
OK]
Warnung
der Polizei
Feiern
Partygäste
zählen
Essen
wegwerfen
Party
abbrechen
[genug]
[>= 10% sind
noch da]
Vorräte
prüfen
[< 10% sind noch da]
Partyservice
bestellen
Bei Tankstelle
nachkaufen
Betrunken
ins Bett
fallen
[keine Vorräte mehr]
Party
beenden
Quelle: Jeckle u.a., „UML glasklar“, Hanser Verlag, 2003
Folie 103
Aktivitätsdiagramm: Partitions
14.10.2009
S tudent
Eine „Partitions"
veranschaulicht
den
Zuständigkeitsbereich eines
bestimmten
Objekts
Werden oft
auch als
„Swimmlanes“
bezeichnet
Speziell zur
Veranschaulichung von Use
Cases
Prüfungsamt
Prüfer
Prüfung
anmelden
Anmeldung auf
Prüfungsliste ergänzen
Prüfung
erstellen
Prüfung
abhalten
Prüfung
schreiben
Prüfung
korrigieren
Prüfung
abgeben
Note bewerten
besser als 5
Noten
eintragen
se
5
Als nicht bestanden
markieren
Folie 104
Zeigt die Zustände und Zustandsübergänge innerhalb
eines Objektes an
Elemente:
14.10.2009
Zustandsautomat
Zustandsname
entry / Aktivität
exit / Aktivität
do / Aktivität
Zudem können noch Trigger mit Bedingungen
festgelegt werden, die Aktivitäten auslösen
Trigger [Guard] / Aktivität
se
Trigger: Ereignisse, die den Zustandswechsel herbeiführen
Guard: Bedingung, die zum Zustandswechsel erfüllt sein muss
Aktivität: Aktivität, die beim Zustandswechsel durchgeführt wird
Folie 105
Zeigt die Zustände und Zustandsübergänge innerhalb
eines Objektes an
Beginn
Geld einwerfen / Anzeige aktualisieren
Geldbetrag ist
eingeworfen
14.10.2009
Zustandsautomat
Geldausgabe
Taste "Abbruch" gedrückt
Zustandsübergang
Geld einwerfen / Anzeige aktualisieren
Taste "Parkschein" gedrückt / Geldeingabe sperren
Ereignis
/Aktion
Parkschein wird
gedruckt
Zustand
/ Alle Werte zurücksetzen
Timer T1 abgelaufen / Alle Werte zurücksetzen
Das Erreichen des EndeZustandes (final state)
führt zur Terminierung des
Objektes, dessen
Zustände hier dargestellt
werden

Ende
se
Folie 106
Composite state
Spezialisierung von Zuständen
14.10.2009
Verbundzustand
Führt in den Startzustand
des Verbundzustands
Verbindung aufbauen
Abgehoben
Aufgelegt
Taste
Abheben
Alle Ereignisse
"Aufgelegt"
führen aus dem
Verbundzustand
(jedem
beliebigen
Zustand dort)
wieder heraus
se
Taste
Nummernei
ngabe
Num mer gültig
Verbindungs
aufbau
Aufgelegt
Partner belegt signalisiert
Partner
belegt
Partner frei signalisiert
Freizeichen
Partner nimmt ab
Composite state
Verbindung
Folie 107
Object Constraint
Language (OCL)
Rainer Schmidberger
[email protected]
se
Die Object Constraint Language ist Teil von UML 2.0
OCL ist eine formale, prädikatenlogikbasierte Sprache
zur Ergänzung von UML-Modellen
OCL Ausdrücke sind leicht zu lesen (leichter als
beispielsweise die von Z oder die Prädikatenlogik)
OCL Ausdrücke sind deklarativ, d.h. sie ändern den
Systemzustand nicht
Dient zur Formulierung von Zusicherungen
14.10.2009
OCL
Ö Invarianten von Klassen
Ö Vor- und Nachbedingungen von Methoden
Nutzen von OCL
se
Ö Die UML-Modelle können präziser beschrieben werden
Ö Programmcode kann generiert werden
Folie 109
OCL constraints werden relativ zu einem Systemzustand
S ausgewertet
OCL constraints sind vom Typ Boolean; sie sind wahr
oder falsch bezüglich S
OCL constraints beschränken die erlaubten
Systemzustände eines UML Klassendiagramms
14.10.2009
OCL Constraints (1)
se
Folie 110
Invarianten:
Ö Eine Invariante I für eine Klasse C ist ein Boolscher OCLAusdruck.
Ö Semantik: I gilt in jedem feststellbaren Zustand (snapshot) jeder
Instanz von C.
Vor- und Nachbedingungen:
Ö Vor- und Nachbedingungen (v, n) für eine Operation p ist ein
Paar von Boolschen OCL-Ausdrücken.
Ö Semantik: v muss zum Zeitpunkt, wenn p aufgerufen wird, true
sein. n muss zum Zeitpunkt, wenn p terminiert, true sein
14.10.2009
OCL Constraints (2)
se
Folie 111
Der Kontext legt fest, auf welches Element sich ein OCL Constraint
bezieht.
context [ kontextInstanz : ] typeName
inv: OclAusdruck1
...
inv: OclAusdruckn
Beispiel:
14.10.2009
Der Kontext
se
context Person
inv: self.alter > 0
self (die referenziert per
default auf die KontextInstanz)
Soll bedeuten: zu keinem
Zeitpunkt darf es ein Objekt der
Klasse Person geben, das einen
negativen Wert im Attribut alter
hat
Folie 112
14.10.2009
Boolean Operationen
se
Operation
Notation
Ergebnistyp
Oder | Und |
Exklusiv Oder
a or | and | xor b
Boolean
Negation
not a
Boolean
Vergleich
a=b
Boolean
Ungleichheit
a <> b
Boolean
Impliziert (wenn a
a implies b
true ist, muss auch b
true sein
Boolean
Folie 113
14.10.2009
Integer/Real Operationen
Operation
Notation
Ergebnistyp
Vergleich
a = b, a<>b, a<b,
a>b, a<=b, a>=b,
Boolean
Rechnen
a+b, a-b, a*b, a/b
Integer/Real
Modulo
a.mod(b)
Integer/Real
Min, Max
a.max(b), a.min(b)
Integer/Real
...
se
Folie 114
oclIsTypeOf (t : OclType) : Boolean
oclIsKindOf (t : OclType) : Boolean
oclInState (s : OclState) : Boolean
Ö Prüfung von Zuständen bei Zustandsautomaten (State D.)
oclIsNew () : Boolean
Ö für Nachbedingungen, prüft, ob Objekte innerhalb einer
Methode neu erzeugt wurden
oclAsType (t : OclType) : instance of OclType
Beispiel:
14.10.2009
Spezielle OCL-Operatoren
se
context Person
inv: self.oclIsTypeOf( Person ) -- ist true
inv: self.oclIsTypeOf( Firma) -- ist false
Folie 115
14.10.2009
OCL Kollektionen
Set(Menge), OrderdSet
Bag (Liste)
Sequence (geordnete Liste)
Instanzierung:
als Literal
Ö Set { 1, 2, 4, 42}
Ö Sequence {1..10} entspricht Sequence {1,2,3,4,5,6,7,8,9,10}
durch Navigation
durch Aufruf von Kollektionsmethoden
durch Klasse.allInstances()
se
Folie 116
14.10.2009
OCL Kollektionen (Auszug)
Operator
Ergebnistyp
Beschreibung
count(objekt)
integer
Anzahl, wie oft das Objekt in der
Kollektion enthalten ist
size
integer
Anzahl d. Elemente
isEmpty
boolean
wahr, wenn Menge leer ist
notEmpty
boolean
falsch, wenn Menge leer ist
forAll(<ausdruck>)
boolean
wahr, wenn <ausdruck> für jedes
Element gilt
exists(<ausdruck>)
boolean
wahr, wenn <ausdruck> für mind.
ein Element gilt
select(<ausdruck>) Menge
Teilmenge, für die <ausdruck> gilt
includesAll
(Menge2)
wahr, wenn alle Elemente der
Menge Menge2 enthalten sind
se
boolean
Folie 117
OCL Kollektionen (2)
c->forAll(objekt1, ... Objektn |
<ausdruck >)
liefert true falls <ausdruck> für
alle Elemente true ist.
14.10.2009
context Firma
inv:
self.Mitarbeiter->forAll(p1, p2 |
p1 <> p2 implies p1.Name <> p2.Name)
c->exists(objekt1, ... Objektn |
<ausdruck>)
liefert true falls <ausdruck> für
mindestens eines der
Elemente true ist.
context Firma
inv:
self.Mitarbeiter->exists(p | p.Gehalt > 100000)
se
Folie 118
14.10.2009
OCL - Beispiel
Person
Name
Vorname
Gehalt
Alter
Mitarbeiter
0..*
0..1
Arbeitgeber
Firma
Bezeichnung
Die Mitarbeiter sind mind. 16 und max. 65 Jahre alt
Jeder hat ein Gehalt > 0
se
context Firma
inv:
self.Mitarbeiter->forAll(m | m.Alter>=16 and m.Alter<=65)
self.Mitarbeiter->forAll(m | m.Gehalt >= 0)
Folie 119
OCL - Beispiel
0..1
Chef
0..*
14.10.2009
Mitarbeiter
Person
Name
Vorname
Gehalt
Alter
0..1
Mitarbeiter
0..*
Arbeitgeber
Firma
Bezeichnung
Der Chef verdient mehr als sein Mitarbeiter
context Person
inv:
self.Chef->notEmpty() implies
self.Chef.Gehalt > self.Gehalt
se
Folie 120
OCL - Beispiel
14.10.2009
0..1
Chef
0..*
Mitarbeiter
Person
Name
Vorname
Gehalt
Alter
Mitarbeiter
0..*
0..1
Arbeitgeber
Firma
Bezeichnung
Der Chef arbeitet bei der selben Firma wie sein Mitarbeiter
se
context Person
inv:
self.Chef->notEmpty() implies
self.Chef.Arbeitgeber = self.Arbeitgeber
Folie 121
OCL - Beispiel
0..1
Chef
0..*
14.10.2009
Mitarbeiter
0..1
Mitarbeiter
Person
0..*
Name
Vorname
Gehalt
Alter
Firma
Arbeitgeber
Bezeichnung
Es gibt mindestens einen „Oberchef“
context Firma
inv:
self.Mitarbeiter->select(Chef->isEmpty())->size >= 1
se
Folie 122
14.10.2009
Vor- und Nachbedingungen
se
Person
Name
Gehalt : Real
0..1
Mitarbeiter
0..*
Arbeitgeber
Firma
Bezeichnung
istPleite : Boolean
einstellen(p : Person)
context Firma::einstellen(p :
pre:
not self.istPleite and
-p.Arbeitgeber->isEmpty()
--post:
p.Arbeitgeber = self and
-p.Gehalt > p.Gehalt@pre
---
Person)
Firma ist nicht pleite
Person ist nicht bereits
anderswo beschäftigt
jetzt eingestellt
Stellenwechsel mit
Gehaltserhöhung
Folie 123
Um auszudrücken, dass eine „Botschaft“ versendet
wurde, dient der hasSent (‘^’) Operator:
context Firma::einstellen(p : Person)
post: p^setArbeitgeber(self)
Bei unspezifizierten Parametern:
14.10.2009
OCL Messages
context Subject::hasChanged()
post: observer^update(? : Integer, ? : Integer))
Die Menge der Aufrufe einer Methode an einen
Empfänger wird über ^^ ausgedrückt
se
Folie 124
14.10.2009
OCL Werkzeuge
se
Folie 125
http://www.omg.org/technology/documents/modeling
_spec_catalog.htm
Jos Warmer, Anneke Kleppe, „The Object Constraint
Language“, second edition, Addison-Wesley, 2003.
14.10.2009
OCL Literatur
se
Folie 126
Trainer
+assistenzTrainer
14.10.2009
Übung
1
0..*
+chefTrainer
Verein
vereinsName : String
+arbeitgeber
1
+gast
+mitarbeiter 11..*
Spieler
se
Spiel
austragungsort : String
austragungsDatum : Date
istVerletzt : Boolean
istTorwart : Boolean
+torwart
+heim
0..1
Aufstellung
1
+feldspieler
auswechseln(spielerRein : Spieler, spielerRaus : Spieler)
10
0..1
Folie 127
Jeder Verein hat mindestens einen Cheftrainer
Kein Spieler einer Aufstellung ist verletzt
Alle Spieler einer Aufstellung arbeiten beim selben
Verein
Vor und Nachbedingung
14.10.2009
Aufgabe
Ö auswechseln
se
Folie 128
Übung a:
context Verein
inv: not self.chefTrainer->isEmpty()
14.10.2009
Jeder Verein hat mindestens einen Cheftrainer
se
Folie 129
Übung b:
Kein Spieler der Aufstellung ist verletzt
14.10.2009
context Aufstellung
inv: self.feldSpieler->Select(istVerletzt)->isempty()
inv: not self.torwart.istVerletzt
se
Folie 130
Übung c:
context Aufstellung
inv: self.feldSpieler->forAll(s1, s2 |
s1.arbeitgeber = s2.arbeitgeber)
14.10.2009
Alle Spieler einer Aufstellung arbeiten beim selben Verein
se
Folie 131
Übung d:
14.10.2009
Auswechslung
context Aufstellung::auswechseln(spielerRein : Spieler,
spielerRaus : Spieler)
pre:
self.feldspieler->exists(spielerRaus) and
not self.feldspieler->exists(spielerRein) and
not spielerRein.istVerletzt
post:
not self.feldspieler->exists(spielerRaus) and
self.feldspieler->exists(spielerRein)
se
Folie 132
Model Driven
Architecture MDA
Rainer Schmidberger
[email protected]
se
Modelle im Entwicklungsprozess
Nur Code
CodeGenerierung
14.10.2009
Modell
generieren
Code
se
Code
„Round Cycle“
Modell
generieren
Ausführbares
Modell
Modell
ReverseEngineering
Code
Folie 134
14.10.2009
MDA
se
www.omg.org/mda
Modelle sind zentrales Element des
Entwicklungsprozesses
Grundgedanke ist eine Modelltrennung
Ö Platform independent model (PIM):
Technologieneutrale Bestandteile wie z.B.
Geschäftsprozesse, Fachlogik,
Domänenmodell etc.
Ö Platform specific model (PSM): Modell für
die speziell zum Einsatz kommende
Systemlandschaft wie z.B. J2EE
Die Vision besteht in einer Ausführbarkeit
dieser Modelle
Viele Werkzeuge werden angeboten
Folie 135
UML-Profile spezifizieren domänenspezifische Typen, Stereotypes
usw.
UML Testing Profile
Ö The UML Testing Profile defines a language for designing, visualizing,
specifying, analyzing, constructing and documenting the artifacts of
test systems. [...] The UML Testing Profile can be used stand alone for
the handling of test artifacts or in an integrated manner [...]
UML Profile for Systems Engineering (SysML)
14.10.2009
UML-Profile
Ö [...] supports the specification, analysis, design, verification and
validation of a broad range of systems and systems-of-systems. These
systems may include hardware, software, information, processes,
personnel, and facilities. (www.sysml.org)
Weitere
Ö UML Profile for Schedulability, Performance and Time
Ö UML Profile for System on a Chip (SoC)
Ö UML Profile for Enterprise Application Integration (EAI)
se
14.10.2009
Folie 136
se
ACM, Alex E. Bell, Death by UML Fever, Queue, v.2 n.1, March 2004
Folie 137
14.10.2009
Was UML nicht modellieren kann ...

se
Projektplan, Arbeitspakete, Rollen, Aktivitäten
Personalplanung
Budget
Nichtfunktionale Anforderungen (z.B. Stabilität,
Wartbarkeit, Performance, Qualität, ...)
Relationales Datenmodell (ER-Diagramm)
Testplan, Testfälle, Testbericht
Risiken, Qualitätssicherung
Begriffslexikon (Glossar)
GUI-Entwürfe
Configuration Management
...
Folie 138