Sie sind auf Seite 1von 22

222 Applikationen objektorientiert konzipieren 2010

222
Applikationen
objektorientiert
konzipieren
Zusammenfassung

1 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010

OO-Grundlagen
OO Projektvorgehen
Model Driven Architecture Im OO-Projektvorgehen hat sich noch kein
Die MDA (Model Driven Architecture) von Standard etabliert. Es gint aber drei allgemein
OMG (Object Management Group) sieht folgende anerkannte Prinzipien für die Vorgehensweise:
zusammenhängende Modellierungsebenen vor, • Iterativ, in überschabaren Inkrementen
welche zur Implementierung führen: entwickeln (eine oder mehrer Iterationen
• CIM: Computerunabhängige pro Modul).
Prozessmodellierung: Businessmodell in • Benutzeranforderungsgetrieben
z.B. BPMN entwickeln.
• PIM: Plattformunabhängige • Architekturzentriert und Modulbasiert
Modellierung eines Informationssystems: entwickeln.
Analysemodell
• PSM: Plattformspezifische Modellierung: Unified Modelling Language
Designmodell Mit UML (Unified Modelling Language) ist eine
• PSI: Plattformspezifische durch OMG normierte Modellierungssprache im
Implementation: konkrete Umsetzung in OO-Umfeld entstanden. Mit ihr können sowohl
einer Programmiersprache die statischen wie auch die dynamischen Aspekte
Die Verständigung zwischen Anwender, eines IT-Systems in unterschiedlichen
Manager und Systementwickler wird durch die, Diagrammtypen vollumfänglich modelliert
von dr realen Welt abgeleiteten Objekt- werden.
Begrifflichkeiten vereinfacht. Die
Generalisierung in Klassenhirachien ermöglicht
die Wiederverwendbarkeit von einmal
erstelltem Programmcode.

Objektorientierte Analyse (OOA)

Artefakte im Analyseprozess
Die Artefakte (Arbeitsresultate,
Lieferobjekte) des Analyseprozesses sollen allen
Beteiligten Klarheit geben, was bzw. Welches
System entwickelt werden soll.

Übersicht der Artefakte des


Analyseprozesses

2 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
• Systembeschreibung: Sie gibt einen • Statisches Analysemodell: Es gibt die
Überblick über das System und ein Struktur, den inneren Aufbau des Systems
gemeinsames Projektverständnis. wider.
• Modelle: Sie helfen, die Sachverhalte im • Dynamisches Modell: Es zeigt die Interaktion
Detail zu beschreiben, zu visualisieren und zu zwischen den Elementen des Systems auf.
prüfen. • Analyseprototyp: Er liefert dem Anwender
• Anwendungsfallmodell: Es stellt die eine erste Vorstellung der neuen Applikation.
Anforderungen in einer für die Anwender
verständlichen Form dar.

UML (Unified Modeling Language)


Statisches Analysemodell
Grundlagen
CRC-Karten
• Die vorwiegend grafischen, in der UML
verwendeten Sprachen dienen der Erstellung Class – Responsibility – Collaborator
(Klasse – Verantwortlichkeit – Zusammenarbeit)
von Anforderungs- und Entwurfsmodellen aus
Hilfsmittel um im Team Klassen zu definieren
unterschiedlichen Perspektiven.
• Die UML-Spezifikationen bestehen aus
ergänzenden und zum Teil überlappenden
Modellen.
• Das Klassenmodell steht im Zentrumder
Systemstruktur.
• Das Anwendungsfalldiagramm (Use Case
Diagramm) dient der Modellierung der
Anforderugen an ein System
• Je nach Bedarf werden weitere Modelle
verwendet, um zusätzliche Ansichten auf das
System zu beschreiben. Fragen
Die 7 UML-Sichten • Mit welchen Personen arbeitet das zu
untersuchende System zusammen?
Sicht Inhalt • Welche Dinge sind im Geschäftsprozess
Statisch Klassen, Objekte, strukturelle involviert oder beschrieben?
Beziehungen • Welche Artikel bzw. Leistung werden dem
Benutzersic Anwendungsfälle Kunden geliefert?
ht • Welche Papiere werden erstellt?
Verhalten Zustandsautomaten • Welche Informationen fliessen bei einem
Aktivitäten Ablauf von Aktivitäten Anwendungsfall in das System?
Interaktione Interaktionen von
n ausgewählten Objekten
Physische Physische Systemstruktur
Sicht
Gliederung Aufteilen der Modelle in
Pakete und Subsysteme

3 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Klassen
Namensregelung für Paket-, Attributs- und
Die Beziehung der Klasse soll eine natürlich Operationsbezeichnungen
sprachliche Identifikation ermöglichen.
• Sie muss im ganzen Modell eindeutig sein.
Notation von Klassen • Es dürfen keine Sonderzeichen ausser dem
Unterstrich «_» verwendet werden.
Beispiel als Text mit Details: • Zusammengesetzte Namen sollen mit
Gross/Kleinschreibung abgegenzt werden
Mitarbeiter (z.B.: SeminarBuchung)
StammNr: Integer {readonly}
Name: String Klassen kommentieren
Vornamen [1..5]: String Jede Klasse kann informal mit Notizen
Geburtsdatum: Date kommentiert werden.
EingetretenAm: Date

Befoerdern (nach: Stufe, ab: Date)

Beispiel als Grafik mit Attributen und


Operationen:

Eigenschaften zu Attributen und


Operationen Abgeleitetes Attribut
Ein von einem anderen Attributswert
Eigenschaften: Notation: abgeleitetes Attribut beginnt mit einem Slash
Kardinalität «/». Für das Design werden diese Attribute
Eigenschaftswe meistens gestrichen, da diese sich errechnen
rt lassen.
Zusicherung
diverse weiter … Typ des Attributs
• Einfacher Datentyp: String, Boolean, Integer,
Attribute UnlimitedNatural
• Aufzählungsdatentyp (Enumeration)
Ein Attribut (Property) ist eine Eigenschaft
• Komplexer Datentyp, d.h. ein Objekt:
einer Klasse. In der Syntax sind verschiedene
enthält ein anderes Objekt, welches keine
Aussagen zu finden:
eigene Objektidentität aufweist
Syntax der Attributsdefinition
Initialwert eines Attributs
[sichtbarkeit] [/] name [:typ] [multiplizität]
Attribute können einen Initalwert enthalten.
[=initialwert] [{eigenschaftswert}]
([…] bedeutet, dass dieses Element optinal ist.) Attribute nur lesen
Attributen, die nur gelesen werden dürfen,
kann das Merkmal {readonly} mitgegeben
werden.

4 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Sichtbarkeit
Multiplizität
Art W Beschreibung
Public + Für alle anderen sichtbar Weist ein Attribut mehrer Werte in einer
Privat - Nur für die eigene Klasse konkrten Instanz auf, so definiert man die
e sichtbar erlaubte Anzahl von Werten mit einer konkreten
Protec # Nur für die eigene Klasse bzw. Angabe der Multiplizität in eckigen Klammern:
ted Deren Unterklassen sichtbar [0..3], [*] etc.. Diese Listen von Attributswerten
Packa ~ Nur innerhalb des gleichen können mit den Merkmalsangaben noch genauer
ge Pakets sichtbar eingeschränkt werden.

{bag} Belibige Listen von Werten.


{uniqu Jeder Attributswert darf nur
e} einmal vorkommen.
{order Die Liste von Attributswerten ist
ed} sortiert.

Operationen (Methoden)
Typ Art
Die Menge aller Operationen bildet das
Konstruktor Objekt erzeugen
Verhalten der Klasse.
Destruktor Objekt löschen
Syntax der Operationen Setter Kontrolliert Attributswerte
setzen
[sichtbarkeit] name (parameterliste) [:typ] Getter Kontrolliert Attributswerte
{constraints} lesen
Beispiel: Link Objektbeziehung aufbauen
Unlink Objektbeziehung löschen
Immatrikulieren ( Getlink Objektbeziehung lesen
Nachname :String, Query Dateninhalte abfragen
Vorname :String,
(mit/ohne Berechnung)
inout Strasse :String,
inout Platziert :String,
Update Dateninhalte persistieren
hat persistiert; mit Präp.obj.; veraltet] auf etwas p. auf etwas
out StudentenNr :Integer) beharren [lat. persistere ”stehen bleiben, verharren“]

Parameterrichtung Zusicherungen
Folgende Angaben definieren die Richtung Zusicherungen, welche bei Aufruf, der
der Parameter: Ausführung bzw. beim Abschluss der Operation
• in: Eingabeparameter (ist Defaultwert) einzuhalten sind, werden als Constraints (d.h. in
• out: Ausgabeparameter geschweifter Klammer) angegeben
• inout: Ein- und Ausgabeparameter
Zusicherung Syntaxbeispiel
Parametertyp Vorbedingu {pre: KundenNr ist gültig}
Sofern eine Operation einen Typ besitzt, ng:
entspricht dies dem Typ des Invariante {inv: Objekt ist für Dritte
Rückgabeparameters. Den Parametern ist der (Zusicherung gesperrt}
Typ (mit Doppelpunkt) beizufügen. Folgende während der
Arten werden unterschieden: Ausführung)
Nachbedin {post: Änderung ist
gung persistiert}

5 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010

Beziehungen (Assoziationen)
UML sieht für die Beziehungen zwischen einem
Beziehungen klären folgende Fragen: Ganzen und dessen Teile zwei Arten von
• Welche fachlichen Beziehungen bestehen Beziehungen vor:
zwischen den Objekten?
• Aggregation (Klasse B ist Teil von Klasse A)
• Wie viele Objekte einer Klasse sind an einer
• Komposition (Klasse B ist Teil von Klasse A
Beziehung beteiligt?
und kann nicht Existenz ohne Klasse A)

Sie weisen folgene optionalen Modellelemente


auf:
• Bezeichnung der Beziehung mit evtl.
Leserichtung
• Rollenbezeichnungen am Ende der
Assoziation
• Multiplizität (z.B.: 1, *, 1..*)
• Navigationsrichtung

Klassen und Objekte


Bezeichnu Beschreibung Beispiel Grafik
ng
Objekt Ein individuell erkennbares, von Die konkrete Person Eva Müller,
(object) anderen Objekteneindeutig 36 Jahre alt, Leiterin Fertigung,
unterscheidbares Element der Realität. Firma AGP, verheiratet, 1 Kind
Klassen Eine eindeutig benannte Einheit, Mitarbeiter, Abteilung
(class) welche eine Menge gleichartiger
Objekte beschreibt.
Gleichartige Objekte werden in Klassen modelliert (zusammengefasst). Sie dienen vorallem der
Modellierung besonderer Aspekte, wie z.B. dem Ablauf einer Operation.

Eigenschaften von Objekten


Jedes Objekt hat Eigenschaften:
Eigenschaft Beschreibung Beispiel
Attribute Attribute haben für jedes Objekt einen Wert,
(attributes) welche keine eigenen Identität besitz.

Operationen Sie modellieren die Möglichkeit zur Bearbeitung


(operations, von Objekten und werden auch Methoden
services) (methodes) genannt.

6 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Wertebereich Sie beschreiben die Menge alle möglichen
e (domains) Werte für ein Attribut

Diagramme

Übersicht der UML-Diagramme

Diagram

Structur Behavior
Diagram Diagram
Aufbaudiagramm Verhaltensdiagramm
(statisch) (dynamisch)

Class Component Object Activity Use Case State Machine


Diagram Diagram Diagram Diagram Diagram Diagram
Klassendiagramm Komponentendiag . Objektdiagramm Aktivitätsdiagramm Anwendungsdiag . Zustandsübergangsd.

Composit Deployment Package Interaction


Structure Diag. Diagram Diagram Diagram
Kompositstrukturdiag. Entwicklungsdiag . Paketdiagramm Interaktionsdiagramm

Sequence Interaction
Diagram Overview Diag.
Sequenzdiagramm Interaktionsüberblicksd.

Communication Timing
Diagram Diagram
Quelle: www.omg.org Kommunikationsdiag . Zeitdiagramm

Use Case Diagramm (Anwendungsfalldiagramm)

7 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010

Fragestellungen
• Wann beginnt der Use Case?
• Welches Ereignis löst den Arbeitsablauf aus?
• Welche Eingabedaten werden benötigt?
• Welche Vorbedingung muss erfüllt sein?
• Welche Schritte sind auszuführen?
• Ist eine zwingende Reihenfolge festgelegt?
• Gibt es akternative, optionale Zweige?
• Welche Endergebnisse werden erstellt?
• Welche Nachbedingungen werden
sichergestellt? ( sind wieder Vorbedingungen
für abhängige Use Cases!)
• Wann endet der Use Case?
• Welche Ausnahmesituation gibt es?
• Welche Endresultate ergibt es bei
Ausnahmesituationen?

8 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Qualitative Aspekte (Prüfung)
• Interagiert jeder Use Case unmittelbat mit
einem Akteur?
• Enthält kein Diagramm mehr als 10 Use
Cases?
• Sind die Name intuitiv verständlich? Multiplizität
• Ist die Beschreibung für die Anwender
verständlich?
• Sind die Begrifflichkeiten kosistent?
• Sind die Use Cases werder zu mächtig, noch
zu klein?
• Ist die Beschreibung des Ablaufes nicht zu
Voreinstellung auf der Akteurseite ist 1
detailliert?
• Ist die Anwendung und nicht ein Dialogablauf Anwendungsfallgeneralisierung
beschrieben?
• Sind alle Aspekte abgedeckt?
• Gibt es keine Widersprüche?

Vorgehen
1. Informationen komplettieren
Akteurgeneralisierung
2. Akteure finden
3. Anwendungsfälle identifizieren
4. Diagrammentwurf zeichnen
5. Beschreibung erstellen
6. Beziehungen modellieren
7. Sicht überprüfen

Notationen
Elemente
Akteur / Actor

Entitätsbeziehung / Include-Beziehung

Anwendungsfall / Use Case

Anwendungsfall A beinhaltet Anwendungsfall B


Erweiterungsbeziehung / Extend-Beziehung
Systemkontext mit Systemgrenze

Anwendungsfall A erweitert Anwendungsfall B


Erweiterungsbeziehung mit Bedingung

Beziehungen (Assoziation) Anwendungsfall A erweitert unter der Bedingung {form. Bedingung}


an der/den Stelle/n extention points Anwendungsfall B
Assoziation / Kommunikation Erweiterungsstelle

9 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Kurzbeschreibung 2 bis 5 Zeilen Text
Akteure Liste der beteiligten Akteure
Auslöser Stichwortartiger Hinweis, wass den
Anwendungsfall ausgelöst hat (z.B.: eine
Anfrage, eine Kundenbestellung…)
Vorbedingung Was muss für die Auslösung erfüllt sein?
Eingehende Welche konkreten Daten werden vom
Informationen Akteur geliefert.(zu hohen
Anwendungsfälle beschreiben Detaillierunggrad vermeiden)
Ergebnisse Welchen Nutzen und konkreten Ergebnisse
Jeden Anwendungsfall beschreibt man mit erhalten die Akteure.
Nachbedingungen Wie ist der Zustand nach dem Ablauf aller
verschiedenen definierten Informationen. Die Aktivitäten (z.B.: Offerte erstellt beim
Anwendungsfälle werden in der Regel mit Anwendungsfall “Offertanfrage
folgender Liste beschrieben: bearbeiten”)
Ablauf Einzelne Tätigkeiten in kurzen Worten
Kategorie Primär: notwendiges, häufiges Verhalten
Teil Beschreibung Sekundär: notwendiges, seltenes Verhalten
Name Substantiv + Verb  möglichst Optional: nicht notwendiges Verhalten
aussagekräftig
Spezialisierung von Verweis auf eine Generalisierung, sofern
eine vorliegt

Klassendiagramm

Das Klassendiagramm stellt ein statische Elemente


Sicht auf die Klassen und deren Beziehungen dar.
Elemente in einem Klassendiagramm können
Pakete, Akteure Komponenten, strukturierte
Klassen und Kollaborationen sein.

Notationen

10 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Klasse
Klasse mit Rubriken (Compartments) für
Attribute und Operationen

Sichtbarkeit + entspricht «public»


für Attribute und # entspricht «protected»
Operationen - entspricht «private»
Multiplizität Attribut:Typ[*]
von Attributen
Alternative Darstellung der Klasse
Jede der Rubriken (Compartments) kann weggelassen bzw. neue
Rubriken können hinzugefügt werden.

Parametrisierte
Klasse mit aktuellem
Parameter P
Parametrisierbare
Klassen mit F als
formalem Parameter

Klasse vom
Stereotyp
stereotypName
Schnittstellen

Aktive Klasse
Abstrakte Klasse

Beziehungen

Beispiel für Beziehungen

Notation
Beziehungen (Assoziation) Qualifizierte Assoziation
Assoziation
11 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Aggregation
n-äre Assiozation mit Rolle und Multiplizität
Klasse B ist Teil von Klasse A
Komposition

Klasse B ist Teil von Klasse A und kann ohne Klasse A nicht
existieren

Beispiel:

Klasse A enthält Klasse B. Klasse B kann ohne Klasse A nicht


existieren
Schnittstellen
Navigierbarkeit bei binären Assoziationen

In beiden Richtungen unspezifiziert  impliziert: in beide


Richtungen navigierbar

In beide Richttungen navigierbar

Nach rechts navigierbar, nach link unspezifiziert  impliziert: nur


nach rechts navigierbar

Nur nach rechts navigierbar

Nach links nicht navigierbar, nach rechts unspezifiziert 


impliziert: nur nach rechts navigierbar
Sonstiges
Notiz
In keine Richtung navigierbar
Multiplizität
Zusicherung (Constrains)

Genau ein Objekt von B steht in Beziehung mit einem Objekt von A

Viele Objekte von B stehen in Beziehung mit Objekten in A

Abhängigkeiten zwischen Beziehungen werden als Zusicherungen


modelliert. Folgende Zusicherungen sind möglich:
Mindestenst n Objekte von B stehen in Beziehung mit Objekten
von A • {or}: keine, nur eine oder beide Beziehungen dürfen
vorhanden sein
• {xor}: es darf nur eine Beziehung vorhanden sein
Optional stehen 0 oder 1 Objekt von B in Beziehung zu einem • {and}: es dürfen beide Beziehungen vorhanden sein
Objekt von A Detaillierte Angaben sind möglich mit „incomplete“, „complete“,
„overlapping“ und „disjoint“:
• {incomplete, overlapping}  nicht komplett und überlappend
Bereich von Objekten von B angeben, die in Beziehung stehen mit
Objekten von A
Spezifizierte Einschränkung der Multiplizität
• {complete, disjoint}  komplett und nicht überlappend
geordnet
Generalisierung / Vererbung

Visuelle Stereotypen
Attributierte Assoziation (Assoziationsklasse)

Die Assoziationsklasse ist eine Bedingung für die Beziehung


zwischen Klasse A und Klasse B
Abhängigkeit
12 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010

Analysemuster zur Lösungsfindung


Beziehungen (Assoziation)
Rechnung

1 Analysemuster «Liste»
enthält
Die einzelnen Positionen bilden existenzabhängige Teile

1..*
des Ganzen, womit eine Komposition angezeigt ist.
Rechnungspositionen

(Der Wert bei Rechnung kann nur 0..1 oder 1 sein)


Buch

1 Analysemuster «Exemplar»
Das Buch ist ein informationelles Objekt, während das
*
effektive Buchexemplar ein physisches Objekt darstellt.
Buchexemplar Die Klasse „Buch“ enthält Informationen, welche für jedes
zugehörige Exemplar gilt.

Analysemuster «Zugehörigkeit»
* 1 Dieses Muster ist wie das Muster „Exemplar“, nur dass der
Mitarbeiter Abteilung
Fokus in der Zugehörigkeit eines Objektes zu einem
übergeordneten Ganzen liegt, ohne dabei Teil des
Anderen zu sein.

1
Automat

1
1 1 Analysemuster «Baugruppe»
1..* 1 1 1
Ein Ganzes besteht aus einzelnen unterschiedlichen
Eingabetasten Kartenlesegerät Anzeige Drucker Teilen. Dies wird durch mehrere Kompositionen gelöst.

* Analysemuster «Stückliste»
Baustein Es existiert ein kaskadierenses Ganzes, welches aus
0..1
Einzelteilen besteht. Ein Einzelteil davon bildet wiederum
ein Ganzes, welches seinerseits aus Einzelteilen besteht.

13 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
*
Objekt
Analysemuster «Verzeichnis»
0..1 Ein Verzeichnis kann Dateien und Verzeichnisse enthalten.
Datei Verzeichnis
Jedes Unterverzeichnis enthält wiederum weitere Dateien
und Verzeichnisse.

* * Analysemuster «Histroie»
Mitarbeiter Funktion
„t“ bildet die zeitliche Einschränkung, dass während einer
{t=1}
bestimmten Zeitperiode nur eine Beziehung aktiv sein
Tätigkeit darf.
Mit einer Assoziationsklasse kann eine Bedingung
eingefügt werden.

Paketdiagramm
Notation
Das Paketdiagramm zeigt einzelne Pakete
und deren Beziehung zueinander. Elemente
Paket (Namensraum)

Beziehungen (Assoziation)
Abhängigkeiten

Import

Import öffentlicher Elemente aus PaketB in den Namensraum von


PaketA ()
Privater Import

Privater Import öffentlicher Elemente aus PaketB in den privaten


Namensraum von PaketA

Objektdiagramm
Das Objektdiagramm stellt eine statische
Sicht auf einzelne Objekte aus einzelnen Klassen
und deren Beziehungen zueinander dar.

14 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010

Notation
Elemente
Objekt
Anonymes Objekt
Objekt mit
Attributswert

Aktives Objekt

Beziehungen (Assoziation)
Link als Instanz einer Assoziation mit
Linkname und Rolle

Link als Instanz einer Aggregation

Link als Instanz einer navigierbaren


Assoziation

Aktivitätsdiagramm

15 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010

Notation Alternative Darstellung mit Pins


Elemente
Aktion
Aktion mit Parametermengen
Aktion als
Dekomposition
Aktion ruft eine eigenständige Kontrollfluss über Konnektoren
Aktivität auf
Objekt

Objekt mit Zustand


Kontrollknoten
Startknoten
E Signal empfangen Endknoten
r
Flussabschluss
e Senden eines
i Signals Teilung (Splitting)
UND-Verbindung
g Zeitsignal
n (at 8pm / after 20min)
i
s Synchronisation
s UND-Verbindung
e
Kontrollfluss (Kante)

Daten- bzw. Objektfluss oder Kante

16 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Spezifizierte Entscheidungsknoten für die Zusammenführung
Synchronisation von Flüssen

Entscheidung
ODER-Verbindung

Zusammenführung Ausnahmebehandlung
ODER-Verbindung (exeption handler)

Unterbrechungsbereich
(Hier kann die Ausnahmesituation auftreten)

Entscheidung und
Zusammenführung Weitere Elemente
ODER-Verbindung
Aktivität

Abfolgen von Aktionen Partition


Aufspaltung des Flusses über Kontrollknoten

Synchronisation von Flüssen über Kontrollknoten

Ausdehnungsbereich mit Ausdehnungsknoten für


Mengenverarbeitung
(«parallel»,«iterativ» oder «stream»)

Entscheidungsknoten für die Verzweigung von


Flüssen

17 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Beispiel:

18 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Zustandsdiagramm

Startzustand
Verweist auf den ersten
Zustand (Einer pro Region)
Endzustand
Austrittspunkt
Zum Verlassen eines
Unterzustandsautomaten
Eintrittspunkt
Zum Betreten eines
Unterzustandsautomaten
Flache Historie
Speichert den zuletzt
aktiven Unterzustand eines
komplexen Zustands.
Tiefe Historie
Speichert den zuletzt
aktiven Unterzustand eines
in einem komplexen
Zustand enthaltenen
Zustands.
Entscheidung
Die ausgehende Transition
wird während der
Ausführung der Transition
bestimmt.
Notation
Elemente
Zustand Kreuzung
Die ausgehende Transition
ist schon vor der
Ausführung der Transition
bekannt.
Zustand mit
zugeordneten
Verhaltensspez. Gabelung
Teilt eine Transition auf
mehrere paralelle
Zustände auf.
Zusammengesetzter Zustand

Vereinigung
Fügt mehrere Transitionen
zu einer zusammen.

Terminator
Bei Erreichen endet die
Lebensdauer der Instanz
Zustandsübergang: Beim Eintreten von ‚Ereignis‘ des beschriebenen
Classifiers.
unter der ‚bedingung‘ wird die ‚aktion‘
(operation) durchgeführt.

19 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Sequenzdiagramm

Notation Objektdestrukti
on
Elemente Zustand
Kommunikation
spartner mit
Lebenslinie Interaktionsverweis

Kombiniertes Fragment

Aktionssequenz

Asynchrone
Objektkonstruktion
Meldung
Synchrone
Meldung
Antwortmeldun
g
Selbstaufruf

20 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010

Komponentendiagramm

Quellennachweis:
Applikationen objektorientiert konzipieren (222) (Hansruedi Tremp)
2. überarbeitete Auflage 2007, Compendio Bildungsmedian AG, Zürich
UML 2.0 - Die neue Version der Standardmodellierungssprache
Vorlesung “Software-Engineering” 2004, Fachhochschule Furtwangen, (Prof. Mario Jeckle)
Ein Überblick über UML (Martin Glinz)
Veröffentlichung 2001, Tutorial unter www.admin-wissen.de

21 Bernhard Tinner
222 Applikationen objektorientiert konzipieren 2010
Referenz UML 2 (Cortex Brainware GmbH)
2010, Cortex Brainware – Consulting & Training GmbH (www.cortex-brainware.de)
Anwendungsfall Wikipedia
2010, Wikipedia http://de.wikipedia.org

22 Bernhard Tinner