3 objektorientierte spezifikation l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 111

3. Objektorientierte Spezifikation PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on
  • Presentation posted in: General

3. Objektorientierte Spezifikation. Zunächst: allgemeines zur objektorientierten Spezifikation (auch objektorientierte Analyse (OOA) genannt) Dann: Die Unified Modeling Language UML. Objektorientierte Analyse. 3.1 Objektorientierte Analyse. Objekt = „Gegenstand, mit dem etwas geschieht“

Download Presentation

3. Objektorientierte Spezifikation

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


3 objektorientierte spezifikation l.jpg

3. Objektorientierte Spezifikation

Zunächst: allgemeines zur objektorientierten Spezifikation (auch objektorientierte Analyse (OOA) genannt)

Dann: Die Unified Modeling Language UML

Modellierung WS 06/07


3 1 objektorientierte analyse l.jpg

Objektorientierte Analyse

3.1 Objektorientierte Analyse

Objekt = „Gegenstand, mit dem etwas geschieht“

Folgerungen:

  • Wann immer gehandelt wird, sind Objekte Behandelte und auch Ausführende.

  • Handlungen stellen das Verhalten von Objekten dar.

  • Ziel von Handlungen sind Änderungen von Objekten

    Jedes Objekt (in der Realität) vereint Zustand und Verhalten

Modellierung WS 06/07


Sprachgebrauch l.jpg

Objektorientierte Analyse

Sprachgebrauch

  • Der Zustand eines Objektes ist gegeben durch die Wertebelegung seiner Attribute.

  • Das Verhalten eines Objektes wird definiert durch seine Methoden.

  • Nachrichten reizen ein Objekt zum Handeln und Antworten (= Anwenden von Methoden).

  • Objekte werden dynamisch erzeugt und vernichtet.

Modellierung WS 06/07


Beispiele l.jpg

Objektorientierte Analyse

Beispiele

Attribute

Alter

Gewicht

...

Name

Nummer

Ausstellungsdatum

Ablaufdatum

...

Methoden

Nenne-Alter

Nenne-Gewicht

Verzehre-Nahrung (...)

Laufe (...)

...

Ausstellen (...)

Verlängern (...)

...

Objekt

Mensch

Personalausweis

Modellierung WS 06/07


Slide5 l.jpg

Objektorientierte Analyse

Beobachtungen aus Beispielen:

  • Das Verhalten eines Objektes hängt von seinem Zustand ab.

  • Der Zustand wird durch das Verhalten verändert.

    Zustand und Verhalten sind eng verbunden.

    Folgerungen

  • Einkapselung = Zustand und Verhalten sind Bestandteile des Objekts.

  • Information Hiding = Zustand und Verhalten sind im Objekt verborgen.

  • Autonomie = ein Objekt entscheidet selbst über seine Reaktion auf eine Nachricht.

Modellierung WS 06/07


Ooa statik und dynamik l.jpg

Objektorientierte Analyse

OOA - Statik und Dynamik

  • OOA erfaßt statische und dynamische Aspekte

    • statische Aspekte: alles um die Struktur von Klassen

      • Klassen

      • Attribute, Operationen

      • Subsysteme

    • dynamische Aspekte: alles rund um Objekte und ihre Werte

      • Objekte

      • Ereignisse

      • Prozesse (verstanden als die Ausführung von Operationen)

Modellierung WS 06/07


Ziel der objektorientierung l.jpg

Objektorientierte Analyse

Ziel der Objektorientierung

Bereitstellung von geeigneten Konzepten für den Umgang mit Objekten.

Zum Beispiel:

  • Erzeugen gleichartiger Objekte

  • Erzeugen einander ähnlicher Objekte

  • Definition gleichartiger Kommunikationsbeziehungen zwischen Objekten.

Modellierung WS 06/07


Grundelemente der objektorientierung klassenbildung l.jpg

Objektorientierte Analyse

Grundelemente der Objektorientierung: Klassenbildung

Definition einer Klasse (= Schablone)

  • Definition der Attribute

  • Definition der Methoden

  • bei Bedarf Erzeugung von Objekten als „zu füllende Kopien“

    Vorteile:

  • Klassenbeschreibung ist unabhängig von der Existenz von Objekten

  • Definition und Nutzung sind voneinander getrennt.

    Beispiel:

    Der Blankovordruck eines Personalausweises wird nach einer Druckschablone erstellt

    und anschließend nach Anweisung ausgefüllt.

Modellierung WS 06/07


Grundelemente der objektorientierung vererbung l.jpg

Objektorientierte Analyse

Grundelemente der Objektorientierung: Vererbung

  • Ziel: Übernehmen einer Klassenbeschreibung beim Erzeugen einer ähnlichen Klasse

  • Konzept: Vererbung

    = Übernahme der Klassendefinition einer Superklasse in die Klassendefinition einer Subklasse

Beispiel für Vererbung:

Versicherung

erzeuge

Person

erbt von

erbt von

erzeuge

erzeuge

Versicherter

Mitarbeiter

Modellierung WS 06/07


Grundelemente der objektorientierung vererbung10 l.jpg

Objektorientierte Analyse

Grundelemente der Objektorientierung: Vererbung

  • Konzept: Mehrfacherbung

    = eine Subklasse besitzt mehrere Superklassen

Beispiel für Mehrfacherbung:

Versicherung

erzeuge

Person

erbt von

erbt von

erzeuge

erzeuge

Versicherter

Mitarbeiter

erbt von

erbt von

erzeuge

versicherter

Mitarbeiter

Modellierung WS 06/07


Grundlemente der objektorientierung beziehungen zwischen klassen l.jpg

Objektorientierte Analyse

Grundlemente der Objektorientierung: Beziehungen zwischen Klassen

Gleichartige Kommunikationsbeziehungen

zwischen Objekten werden durch die Definition der Beziehungen zwischen Klassen vorgegeben:

  • Assoziation („hat-Kenntnis-von“)

  • Aggregation („ist-Teil-von“)

Beispiel:

Versicherung

kennt

Vertrag

Person

besteht-aus

erbt von

erbt von

Paragraph

Versicherter

Mitarbeiter

Modellierung WS 06/07


Grundelemente der objektorientierung beziehung zwischen klassen l.jpg

Objektorientierte Analyse

Grundelemente der Objektorientierung: Beziehung zwischen Klassen

Beispiel für erzeugte Objekte:

Versicherung

kennt

Vertrag

Person

besteht-aus

erbt von

erbt von

Paragraph

Versicherter

Mitarbeiter

Modellierung WS 06/07


Grundelemente der objektorientierung polymorphie l.jpg

Objektorientierte Analyse

Grundelemente der Objektorientierung: Polymorphie

Polymorphie:

statisch:- in Abhängigkeit von den Parametertypen wird die

passende Operation gewählt.

- dies geht auch ohne Objektorientierung

Bsp.: +

dynamisch:die aufzurufende Operation wird erst dann ermittelt (und an das

Operationssymbol gebunden), wenn sie aufgerufen wird (und nicht

etwa zur Compile-Zeit)

Modellierung WS 06/07


Slide14 l.jpg

Objektorientierte Analyse

FigurenBehaelter

figuren: set

anzeigen()

GeomFigur

x:integer

y:integer

sichtbar: Boolean

anzeigen()

entfernen()

setPosition(neuX, neuY)

anzeigen„smalltalk-beispiel“

figuren do [:f | f anzeigen.].

„do: iteriert über die Elemente f

der Menge figuren“

Kreis

radius {radius>0}

setRadius(neuR)

anzeigen()

Rechteck

a {a>0}

b {b>0}

setA(neuA)

setB(neuB)

anzeigen()

Modellierung WS 06/07


Grundelemente der objektorientierung objektidentit t l.jpg

Objektorientierte Analyse

Grundelemente der Objektorientierung: Objektidentität

Objektidentität

  • Objektwertgleichheit  Objektgleichheit

  • Es kann objektwertgleiche Objekte geben

  • Unterscheidung erfolgt über interne Kennungen (Surrogate)

Modellierung WS 06/07


Zusammenfassung l.jpg

Objektorientierte Analyse

Zusammenfassung

Objekt-Orientierung

  • Ein objekt-orientiertes System besteht aus einer Menge von Objekten, die miteinander Nachrichten austauschen.

  • Bei der Gestaltung erleichtern Klassen, (Mehrfach-)Vererbung, Aggregation und Assoziation die Definition, die Konfiguration und den Einsatz von Objekten.

  • Die Struktur der Klassen ist statisch.

  • Die Menge und Struktur der Objekte ändert sich dynamisch.

Modellierung WS 06/07


Grundphilosophie objekt orientierter software entwicklung l.jpg

Objektorientierte Analyse

Grundphilosophie objekt-orientierterSoftware-Entwicklung

  • „reale“ Handlungsabläufe werden ins „Software-Modell“ übertragen

  • Realität wird als objektorientiertes System aufgefaßt

  • „reale“ Objekte werden durch passende „Modell-Objekte“ ersetzt

  • „Modell-Objekte“ übernehmen die „Modell-Handlung“

    Objekte bestimmen und geeignetes Modell schaffen!

Modellierung WS 06/07


Entwicklungsabschnitte l.jpg

Objektorientierte Analyse

Entwicklungsabschnitte

  • OO-Analyse:Bestimmen von Objekten und Klassen aus

    der Realität des Anwendungsbereichs

  • OO-Design:Ergänzen der Strukturen

    aufgrund technischer Erfordernisse

  • OO-Programmierung:Umsetzen in Programmiersprache

    und Anpassen an Sprachspezifika

Modellierung WS 06/07


Oo analyse besteht aus l.jpg

Objektorientierte Analyse

OO-Analyse besteht aus

der Erforschung des Anwendungsbereichs, d.h.

  • Objekte entdecken

  • Klassen ableiten

  • Klassen strukturieren

  • Aufgaben zuordnen

  • Zusammenarbeit festlegen

Modellierung WS 06/07


Erforschung vorgehen l.jpg

Objektorientierte Analyse

Erforschung: Vorgehen

Entdecken von Objekten des Anwendungsbereichs:

  • Ableiten aus textueller Beschreibung

    (Hauptwörter selektieren und normieren)

  • Ableiten aus eigenem Wissen

  • Ableiten aus Expertenbefragung

  • Ableiten aus „Use Case Model“

    (Analyse der anwendungstypischen Handlungsabläufe)

    Kandidaten für Objekte sind

  • greifbare Dinge

  • Konzepte

  • Ereignisse

Modellierung WS 06/07


Erforschung weiteres vorgehen l.jpg

Objektorientierte Analyse

Erforschung: Weiteres Vorgehen

Ableiten von Klassen aus Objekten

=„natürliche“ Gemeinsamkeiten von Objekten erkennen und diese in Klassen zusammenfassen

Strukturieren der Klassen

  • existierende Vererbungsstrukturen bestimmen

    (mögliche Subklassen suchen)

    (mögliche Superklassen suchen)

  • Superklassen ergänzen

    (Gemeinsamkeiten in Superklassen extrahieren)

  • Abhängigkeiten bestimmen

    (Aggregationen und Assoziationen charakterisieren)

Modellierung WS 06/07


Erforschung beispiel vererbung l.jpg

Gerät

Pumpe

Pumpe

Kühler

Kühler

Objektorientierte Analyse

Erforschung: Beispiel Vererbung

Ohne Beziehungen

Mit Vererbung

Membran-

pumpe

Zentrifugal-

pumpe

Zentrifugal-

pumpe

Membran-

pumpe

Notation: OMT

Modellierung WS 06/07


Erforschung beispiel aggregation l.jpg

Sekretariat

Sekretariat

Abteilung

Abteilung

Bereich

Bereich

Leitung

Leitung

Firma

Firma

Objektorientierte Analyse

Erforschung: Beispiel Aggregation

Ohne Beziehungen

Mit Aggregation

Notation: OMT

Modellierung WS 06/07


Erforschung weiteres vorgehen24 l.jpg

Objektorientierte Analyse

Erforschung: Weiteres Vorgehen

Zuordnen von Aufgaben zu Klassen

  • Klassen beschreiben

  • Attribute bestimmen

    (Zustände von Objekten abgrenzen)

    (Attribute Superklassen zuordnen)

    (Relevanz von Attributen für alle Objekte)

  • Methoden bestimmen

    (Verhalten zu Attributen)

    (Leistungen des Systems verteilen)

    (Relevanz von Methoden für alle Objekte)

Modellierung WS 06/07


Erforschung weiteres vorgehen25 l.jpg

Objektorientierte Analyse

Erforschung: Weiteres Vorgehen

Zusammenarbeit festlegen

=Nachrichtenaustausch zwischen Objekten verschiedener

Klassen charakterisieren

Klassen sind Vertragspartner der Form „Produzent“ und „Konsument“

wie im Wirtschaftsleben:

  • Nachfrage nach Verhalten aufstellen

  • Angebote an Verhalten vornehmen

  • Angebote und Nachfragen einander anpassen

Modellierung WS 06/07


Oo analyse l.jpg

Objektorientierte Analyse

OO-Analyse

Das Ergebnis der vorgestellten OO-Analyse ist eine

statische Struktur von Klassen (= Klassenmodell).

Es fehlt eine Beschreibung der Dynamik, z.B. Angaben über

  • das Erzeugen und Vernichten von Objekten,

  • die zu einem Zeitpunkt konkret agierende Menge von Objekten,

  • die Wirkung einer Methodenanwendung auf den internen Zustand

    eines Objektes

  • den Ablauf der Kommunikation zwischen Objekten

Modellierung WS 06/07


Oo analyse27 l.jpg

Objektorientierte Analyse

OO-Analyse

Zur Beschreibung der Dynamik von objektorientierten Systemen

werden „herkömmliche“ Methoden eingesetzt. Zum Beispiel:

  • Zustandsdiagramme

  • Sequenzdiagramme

  • Anwendungsfalldiagramme

  • formale, semiformale und informale Texte

    Eine statische Struktur ohne Dynamikmodellierung

    ist Stückwerk !

Modellierung WS 06/07


Vorteile von objektorientierten methoden gegen ber funktionsorientierten strukturierten methoden l.jpg

Objektorientierte Analyse

Vorteile von objektorientierten Methoden gegenüberfunktionsorientierten (strukturierten) Methoden

  • Ganzheitliche Betrachtung

  • unterschiedliche Abstraktionsebenen bei Anwendung des gleichen Paradigmas

  • evolutionäre Entwicklung ist möglich

  • einfacher Zugang zu Anwendungsgebiet

  • bessere Kommunikationsbasis als bei separaten ER-Modellen und Funktionsbäumen (oder ähnlicher Darstellung)

  • kein Paradigmenwechsel in der Entwicklung

  • bessere Durchschaubarkeit durch Übereinstimmung der Strukturen mit der Realität

  • einfache Möglichkeit der Wiederverwendung

Modellierung WS 06/07


Risiken und gefahren von objektorientierten methoden l.jpg

Objektorientierte Analyse

Risiken und Gefahren von objektorientierten Methoden

  • wenig Erfahrung

  • Scaling-Up-Problem noch nicht vollständig bekannt / gelöst

    • Konfigurations-Management

    • integriertes Qualitäts-Management

  • Überschätzung von Einzelaspekten, z.B. Vererbung, und deren exzessive Verwendung

  • Gefahr der Überspezifikation (der Zweck des Verständnisses gerät außer Sicht)

  • unausgereifte Werkzeuge

Modellierung WS 06/07


R ckblick auf historie l.jpg

Objektorientierte Analyse

Rückblick auf Historie

Ursprünge der VererbungProgrammiersprache SIMULA1967

Grundlagen für EinkapselungInformation Hiding1972

Abstrakte Datentypen1975

Grundlage für NotationenEntity-Relationship-Modellierung1976

Dynamikmodellierung(traditionelle Methoden)

Objektorientierung kombiniert etablierte Methoden!

Modellierung WS 06/07


Slide31 l.jpg

Objektorientierte Analyse

Objektorientierte Modellierungssprachen ermöglichen Vorteile, sie garantieren sie nicht.

Deshalb: objektorientierte Modellierung muß durch geeignete Methoden und Richtlinien ergänzt werden.

Versuch: UML und passende Methode

Modellierung WS 06/07


Slide32 l.jpg

UML: Einführung

3.2 Die Unified Modeling Language (UML)

Spezifikationssprache: UML

Syntax

Methodik

Semantik

Modellierung WS 06/07


Slide33 l.jpg

UML: Einführung

OOD, 1991

G. Booch

S.Shlaer, S. Mellor

OOA und OOD, 1991

P. Coad, E. Yourdon,

1991

OMT, 1991

J. Rumbaugh

OOSE, 1992

I. Jacobson

CRC-Karten

(Class-Responsibilities-

Collaborations)

R. -Brock 1990

Unified Method

G. Booch / J. Rumbaugh,

1995

State Charts

(erw. / hierarchische

Zustandsübergangs-

diagramme)

D. Harel

Unified Modeling Language (UML)

G. Booch / J. Rumbaugh / L. Jacobson

1996

Integrationen auf dem Weg zur UML

Integrationen ohne Niederschlag in der UML

Modellierung WS 06/07


Beschreibungsmittel in uml l.jpg

Anwendungsfalldiagramme (Use Case Diagram)

Akteure

Anwendungsfälle

Beziehungen

Klassendiagramme (Klassenstrukturdiagramm)

Klassen

Beziehungen zwischen Klassen

Verhaltensdiagramme

Aktivitätsdiagramme

Zustände

Zustandsübergänge

Ereignisse

Aktivitäten

Objektzustände

Kollaborationsdiagramme

Objekte

Beziehungen inklusive Nachrichtenaustausch

(räumlich geordnet)

Sequenzdiagramme (Weg-Zeit-Diagramme)

Objekte

Beziehungen inklusive Nachrichtenaustausch

(zeitlich geordnet)

Zustandsdiagramme

Zustände

Beziehungen

Ereignisse

Implementierungsdiagramme

Komponentendiagramm

Komponenten

Beziehungen zwischen Komponenten

Einsatzdiagramme

Komponenten

Beziehungen

Knoten

UML: Einführung

Beschreibungsmittel in UML

Modellierung WS 06/07


Slide35 l.jpg

UML: Einführung

1) Klassendiagramme (inkl. CRC Cards)

falls das

Anwendungsgebiet

workflow-geprägt

ist

OOA

3a) Sequenzdiagramme

3b) Kollaborationsdiagramme

2) Anwendungsfall-

diagramm

6) Aktivitäten-

diagramm

4) Zustandsübergangs-

diagramm

OOD

5) Komponenten-

diagramme

Modellierung WS 06/07


Uml klassendiagramme l.jpg

UML: Klassendiagramme

UML-Klassendiagramme

Klassifikation->Bildung von Klassen

Generalisierung/->Vererbung

SpezialisierungBildung von Ober- und Unterklassen

Assoziation->Beziehung zwischen Objekten einer oder mehrerer

Klassen

Aggregation->Spezialfall der Assoziation, Objekte sind Bestand-

teile eines anderen Objektes

Modellierung WS 06/07


Slide37 l.jpg

UML: Klassendiagramme

Klassifikation

Assoziation

Name-von-B-aus

1

0..*

B

A

Name-von-A-aus

Ein A-Objekt steht zu beliebig vielen B-Objekten in Verbindung.

Die Beziehung von A aus gesehen heißt „Name-von-A-aus“.

Ein B-Objekt steht zu einem A-Objekt in Verbindung.

Modellierung WS 06/07


Slide38 l.jpg

UML: Klassendiagramme

Generalisierung

Aggregation

B

A

1..*

1

Ein A-Objekt steht zu einem oder mehreren B-Objekten in Verbindung.

Ein B-Objekt steht zu einem A-Objekt in Verbindung.

Modellierung WS 06/07


Unterscheidungen verschiedener aggregationen l.jpg

UML: Klassendiagramme

Unterscheidungen verschiedener Aggregationen

Normale Aggregation

besteht aus >

besteht aus >

Unternehmen

Abteilung

Mitarbeiter

1..*

1..*

1

1

Komposition (Einzelteile sind vom Aggregat existenzabhängig d.h. sie können

ohne das Aggregat nicht existieren).

hat >

Rechnung

Rechnungsposition

1..*

1

Hinweis: Bei Komposition auf der Aggregatseite 1.

Modellierung WS 06/07


Richtungen von assoziationen und aggregationen l.jpg

UML: Klassendiagramme

Richtungen von Assoziationen und Aggregationen

... geben an, welche Objekte von der Beziehung wissen

hat >

B

A

Ein Objekt der Klasse A kennt das komponierte Objekt der Klasse B,

aber nicht umgekehrt, es kann Nachrichten an Objekte der Klasse B senden,

aber nicht umgekehrt!

Modellierung WS 06/07


Kommunikation zwischen objekten l.jpg

UML: Klassendiagramme

Kommunikation zwischen Objekten

... erfolgt über den Austausch von Nachrichten

B

A

set() ->

Ein Objekt der Klasse A kann die Nachricht set() an ein Objekt der Klasse B senden.

.

Modellierung WS 06/07


Slide42 l.jpg

UML: Klassendiagramme

Grundelemente der Objektorientierung: Klassen, ihre Interna und Objekte

Zusicherung

Klassenname

Kreis

radius: integer {radius > 0}

mittelpunkt: Point = (10,10)

anzeigen()

entfernen()

setPosition(pos: Point)

setRadius(neuerRadius: integer)

Attributname

Initialwert

Attribut-Typ

Operationen

Parameter

(Name: Typ = Initialwert)

Klasse

einKreis: Kreis

radius=25

mittelpunkt=(10,10)

Exemplarname

Klassenname

Attributnamen

Attributwerte

Objekt

Modellierung WS 06/07


Attribute und operationen in vererbungsbeziehungen l.jpg

UML: Klassendiagramme

Grundelemente der Objektorientierung: Vererbung

Attribute und Operationen in Vererbungsbeziehungen

GeomFigur

x:integer

y:integer

sichtbar: Boolean

anzeigen()

entfernen()

setPosition(neuX, neuY)

Attribute und Operationen werden in den Klassen angesiedelt, in die sie der

Anschauung nach gehören. Redundanz-, Performanz- und sonstige Entwurfs- und

Implementierungsaspekte interessieren während der OOA NICHT !

Kreis

radius {radius>0}

setRadius(neuR)

Dreieck

a {c-b < a < b+c}

b {a-c < b < a+c}

c {a-b < c < a+b}

setA(neuA)

setB(neuB)

setC(neuC)

Rechteck

a {a>0}

b {b>0}

setA(neuA)

setB(neuB)

Modellierung WS 06/07


Vererbung gem anschauung l.jpg

UML: Klassendiagramme

Vererbung gemäß Anschauung

Rechteck

a {a>0}

b {b>0}

setA(neuA)

setB(neuB)

anzeigen()

entfernen()

Liefert für Quadrate nicht

die minimale

Implementierung, denn es

gibt zwei Kantenlängen.

Quadrat

{a=b}

Modellierung WS 06/07


Alternative vererbung l.jpg

UML: Klassendiagramme

Alternative Vererbung

Quadrat

a {a>0}

setA(neuA)

anzeigen()

entfernen()

Entspricht nicht der Anschauung,

ist aber redundanzfrei !

Rechteck

b{b>0}

setB(neuB)

Modellierung WS 06/07


Slide46 l.jpg

UML: Klassendiagramme

Multiple Klassifikation

  • Bei multipler Klassifikation kann ein Objekt durch mehrere Klassen beschrieben werden, die nicht über Vererbungsbeziehungen miteinander verbunden sind.

  • Zur Angabe der gültigen Kombinationen von Klassen werden Diskriminatoren verwendet.

  • Alle Klassen mit dem gleichen Diskriminator sind disjunkt.

  • Vollständige Diskriminatoren bedeuten, daß die Vereinigung aller Objekte der „Unterklassen“ die Menge der Objekte der „Oberklasse“ ergibt. Im Sinne des Diskriminators ist die „Oberklasse“ dann eine abstrakte Klasse.

  • Dynamische Diskriminatoren erlauben, daß ein Objekt zur Laufzeit den Typ wechselt (schwierige Implementierung!)

Modellierung WS 06/07


Slide47 l.jpg

UML: Klassendiagramme

Multiple Klassifikation

Diskriminator

Surgeon

Female

Doctor

sex

(vollständig)

role

(dynamisch)

Family

Doctor

Person

Nurse

Male

patient

Physio-

therapist

Patient

Legale Kombination von Klassen für ein Objekt: Female, Patient, Nurse

Male, Physiotherapist

Female, Patient

Illegale Kombinationen von Klassen für ein Objekt:Patient, Doctor

Male, Doctor, Nurse

Modellierung WS 06/07


Abstrakte klassen l.jpg

UML: Klassendiagramme

Abstrakte Klassen

... sind Klassen, von denen keine Objekte erzeugt werden können.

Die Klasse „GeomFigur“ ist eine abstrakte Klasse, denn es werden konkrete Kreise, Dreiecke, Rechtecke, aber keine geometrischen Figur-Objekte erzeugt.

Modellierung WS 06/07


Parametrisierte klassen l.jpg

T

Set

Set<Integer>

UML: Klassendiagramme

Parametrisierte Klassen

... sind Klassen, die einen Typ als Parameter haben. Typischerweise: Stacks, Queues, Listen, Mengen

Parametrisierte Klasse

Parametrisierte Klasse mit gebundenem Parameter

Modellierung WS 06/07


Graphische darstellung von parametrisierbaren und abstrakten klassen l.jpg

UML: Klassendiagramme

Graphische Darstellung von parametrisierbaren und abstrakten Klassen

parameterisierbare Klassen

Wartezimmer

i: Element

„bind“ <Patient>

Warteschlange

anfuegen()

entnehmen()

Stau

„bind“ <PKW>

abstrakte Klassen

Klasse

{abstrakt}

attribute

operationen()

Vereinfachte Darstellung

Klasse

attribute

operationen()

Klasse

{abstrakt}

Klasse

Modellierung WS 06/07


Attribute klassenattribute abgeleitete attribute l.jpg

UML: Klassendiagramme

Attribute, Klassenattribute, abgeleitete Attribute

Attribute werden beschrieben durch

  • Name

  • Datentyp oder Klasse

  • Initialwert

  • Zusicherungen / constraints (Syntax: {constraint}, keine weiteren Angaben!)

    Klassenattribute gehören nicht zu einem Objekt, sondern zur Menge aller

    Objekte einer Klasse (vereinfacht: zur Klasse).

    Beispiel: Zähler, der angibt, wieviel Objekte eines Typs erzeugt werden.

    Abgeleitete Attribute sind Attribute, deren Werte aus den Werten anderer Attribute abgeleitet werden können. Die namen abgeleiteter Attribute beginnen mit einem Slash /

    Beispiel: Das Attribut /Alter einer Person kann aus ihrem Geburtsdatum abgeleitet werden.

Modellierung WS 06/07


Sichtbarkeit von attributen l.jpg

UML: Klassendiagramme

Sichtbarkeit von Attributen

  • public: für alle sichtbar und benutzbar. UML-Notation +

  • protected: für die Klasse selbst, für die Unterklassen und für explizit ausgezeichnete Klassen. UML-Notation #

  • private: für die Klasse selbst und für explizit ausgezeichnete Klassen. UML-Notation -

  • Syntax der Operationsdefinition:

    visibility name (parameter-list) : return-type-expression {property-string}

    visibility: + (public), # (protected), - (private)

    name: string

    parameter-list: beinhaltet (optional) Argumente, Syntax wie bei Attributen

    return-type-expression: optional Spezifikation des Rückgabewertes (abhängig von der Implementierungssprache)

    property-string: Eigenschaften der Operation

    Hinweis: In der OOA sollten die Operationen nicht im Sinne einer Schnittstellendefinition verwendet werden. Stattdessen sollten sie die prinzipiellen Verantwortlichkeiten und Aufgaben einer Klasse definieren. -> zum Beispiel mit CRC Karten!

Modellierung WS 06/07


Crc karten class responsibility collaboration l.jpg

UML: Klassendiagramme

CRC Karten (Class-Responsibility-Collaboration)

Class Name

  • Mit CRC-Karten werden die abstrakten Aufgaben einer Klasse definiert.

Bestellung

Collaboration

Responsibility

Prüfe, ob Artikel

auf Lager

Lagerbestand

Bestimme Preis

Lagerbestand

Prüfe auf gültige

Zahlung

Kunde

Ausliefern

Modellierung WS 06/07


Slide54 l.jpg

UML: Klassendiagramme

Rollen in Assoziationen

  • Jede Assoziation hat zwei Rollen. Jede entspricht einer Richtung.

  • Rollen können explizit benannt werden.

  • Der Name einer Rolle von Klasse A nach Klasse B steht am B-Ende der Assoziation (vgl. Bestellung - interne Bestellung).

Modellierung WS 06/07


Slide55 l.jpg

UML: Klassendiagramme

Multiplicity: mandatory

Bestellung

dateReceived

isPrepaid

number: String

price: Money

dispatch()

close()

Kunde

name

adress

creditRating(): String

*

1

Constraint

Generalization

Association

Class

1

{if Bestellung.Kunde.creditRating is

„poor“, then Bestellung.isPrepaid

must be true}

Persönlicher

Kunde

creditcard#

Firmenkunde

contactName

creditRating

creditLimit

remind()

billForMonth(Integer)

Rollenname

Attributes

{creditRating() ==

„poor“}

Artikel

Multiplicity: Many-valued

*

Interne Bestellung

quantity: Integer

price: Money

isSatisfied: Boolean

*

0..1

Operations

sales rep

Multiplicity: optional

Arbeitnehmer

* 1

Produkt

Modellierung WS 06/07


Klassendiagramme weiterf hrende konzepte l.jpg

UML: Klassendiagramme

Klassendiagramme: weiterführende Konzepte

Assoziationsklassen werden benutzt, um Assoziationen mit Attributen und Operationen zu verknüpfen.

Person

Firma

*

Arbeitgeber

*

Angestellter

Beschäftigung

Periode:Zeitraum

Modellierung WS 06/07


Klassendiagramme weiterf hrende konzepte57 l.jpg

UML: Klassendiagramme

Klassendiagramme: weiterführende Konzepte

Abgeleitete

Assoziation

/Arbeitgeber

Assoziationsklassen können vermieden werden. Ihre Bedeutung ergibt sich gemäß dem folgenden Beispiel.

*

*

Beschäftigung

Periode:Zeitraum

Person

Firma

1 *

* 1

Beförderung einer Assoziationsklasse zu einer vollen Klasse

Bei der Verwendung einer Assoziationsklasse gab es zwischen einer Person und einer

Firma nur ein Beschäftigungsverhältnis, diese Restriktion ist durch die Verwendung

der normalen Klasse aufgehoben.

Modellierung WS 06/07


Klassendiagramme weiterf hrende konzepte58 l.jpg

UML: Klassendiagramme

Klassendiagramme: weiterführende Konzepte

Person

Firma

*

Arbeitgeber

*

Frage: Ist die Restriktion sinnvoll?

Beschäftigung

Periode:Zeitraum

Annahme: eine Person verläßt eine Firma

und kehrt später wieder zurück. Also: zwischen

einer Person und einer Firma mehrere Objekte

der Klasse Beschäftigung.

Modellierung WS 06/07


Klassendiagramme weiterf hrende konzepte59 l.jpg

UML: Klassendiagramme

Klassendiagramme: weiterführende Konzepte

Obwohl es also sinnvolle Kombinationen von mehreren Assoziationsobjekten zwischen zwei assoziierten Objekten gibt, läßt die UML-Semantikdefinition von Assoziationsklassen dies nicht zu.

Dies bedeutet jedoch keine prinzipielle Einschränkung der Ausdruckskraft, da die Beförderung der Assoziationsklasse zu einer vollen Klasse einen Ausweg bietet.

Modellierung WS 06/07


Klassendiagramme weiterf hrende konzepte60 l.jpg

UML: Klassendiagramme

Klassendiagramme: weiterführende Konzepte

Qualifizierte Assoziationen erlauben es, Aussagen über die Assoziationen von Mengen von Objekten zu anderen Objekten zu machen. Das Kriterium, über das die Menge der Objekte bestimmt wird, nennt man Qualifikation.

Bestellungseingang

Menge: Nummer

Bestellung

0..1

Produkt

Eingangsnummer

Pro Produkt gibt es für eine Menge von Bestellungen einen Bestellungseingang.

Produkt bündelt eine Menge von Bestellungen. Es qualifiziert alle Bestellungen, die

zu einem Bestellungseingang gehören!

Modellierung WS 06/07


Uml anwendungsfalldiagramme l.jpg

UML: Anwendungsfalldiagramme

UML - Anwendungsfalldiagramme

  • Ein Anwendungsfalldiagram zeigt die Beziehungen zwischen Akteuren und Anwendungsfällen, d.h. es stellt das externe Systemverhalten aus der Sicht des Anwenders dar.

  • Anwendungsfälle werden auch als Szenarien oder Geschäftsprozesse bezeichnet.

  • Anwendungsfälle beschreiben für den Anwender sichtbare Funktionen.

  • Anwendungsfälle beschreiben die Erreichung eines für den Anwender zusammenhängenden Ziels.

Modellierung WS 06/07


Uml anwendungsfalldiagramme62 l.jpg

UML: Anwendungsfalldiagramme

UML - Anwendungsfalldiagramme

  • Wichtig ist die Fokussierung auf Ziele des Anwenders und auf Interna des Systems, die mit diesen Zielen zusammenhängen. Beispiel:

    • Ziel: Was muß der Benutzer tun, um eine individuelle Dokumentenvorlage zu erstellen?

    • Interna: definiere eine Vorlage, kopiere sie in das Verzeichnis für Vorlagen, wende diese Vorlage an.

  • Zielfokussierte Anwendungsfälle eignen sich gut für die Abstimmung mit dem zukünftigen Anwender.

  • Auf das interne Verhalten ausgerichtete Anwendungsfälle eignen sich gut für Planungszwecke.

Modellierung WS 06/07


Notation f r anwendungsf lle l.jpg

UML: Anwendungsfalldiagramme

Notation für Anwendungsfälle

Anwendungsfall

Akteurein Akteur stellt eine Rolle dar, er gibt nicht an,

wieviele Ausprägungen es gibt

Beziehung zwischen Anwendungsfall

und Akteur, der Akteur führt den

Anwendungsfall aus.

uses/

extends*

uses- oder extends-Beziehung

zwischen zwei Anwendungsfällen

AF1 uses AF2

*UML 2.0: include/extend

Modellierung WS 06/07


Uml anwendungsfalldiagramme64 l.jpg

UML: Anwendungsfalldiagramme

UML - Anwendungsfalldiagramme

Notation für Anwendungsfälle

Diagrammname

Akteur 2

Anwendungs-

fall 1

Anwendungs-

fall 2

Akteur 1

Anwendungs-

fall 3

Modellierung WS 06/07


Slide65 l.jpg

UML: Anwendungsfalldiagramme

Definiere

Provision

Identifiziere

Versicherungs-

nehmer

„uses“

Maklerkoordinator

Berate

Versicherungs-

nehmer

Ermittle

Partner

Mache Angebot

Makler

„extends“

Mache

Composit-

Angebot

Versicherungsnehmer

Angestellter

Außendienstmitarbeiter

Modellierung WS 06/07


Slide66 l.jpg

UML: Anwendungsfalldiagramme

Zeitschriftenumlauf

1

Zeitschrift

registrieren

Mitverwend.

Anwendungsf.

2

Mark. Art.

registrieren

„uses“

Anwendungs-

fall

Bibliothek

3

Umlaufzettel

erstellen

„extends“

Erweiterung oder.

Variante

4

Zeitschrift

archivieren

Modellierung WS 06/07


Strukturierte textuelle beschreibung eines anwendungsfalls l.jpg

UML: Anwendungsfalldiagramme

Strukturierte, textuelle Beschreibung einesAnwendungsfalls

Af.-Nr.Name des Anwendungsfalles

Vorbedingungen: ...

Nachbedingungen: ...

Nicht-funktionale Anforderungen: ...

Beschreibung: ..

Variationen: ...

Regeln: ...

Services: ...

Ansprechpartner: ...

Anmerkungen / offene Fragen: ...

Dialogbeispiele oder - muster: ...

Diagramme: ...

Modellierung WS 06/07


Slide68 l.jpg

UML: Anwendungsfalldiagramme

Modellierung WS 06/07


Slide69 l.jpg

UML: Anwendungsfalldiagramme

Modellierung WS 06/07


Slide70 l.jpg

UML: Sequenzdiagramme

UML - Sequenzdiagramme (Weg-Zeit-Diagramme) und Kollaborationsdiagramme

  • individuelle Objekte (in Sequenzdiagrammen und Kollaborationsdiagrammen)

  • Beziehungen zwischen Objekten inklusive Nachrichtenaustausch (zeitlich geordnet) (in Sequenzdiagrammen)

  • Beziehungen zwischen Objekten inklusive Nachrichtenaustausch (räumlich geordnet) (in Kollaborationsdiagrammen)

Modellierung WS 06/07


Slide71 l.jpg

UML: Sequenzdiagramme

UML - Sequenzdiagramme (Weg-Zeit-Diagramme) und Kollaborationsdiagramme

Sequenzdiagramme und Kollaborationsdiagramme werden zusammenfassend als Interaktionsdiagramme bezeichnet.

Beide Arten von Diagrammen werden benutzt, um das Verhalten innerhalb eines Anwendungsfalls detailliert zu beschreiben. Sie liefern keine formale Beschreibung!

Sie beschreiben, wie Gruppen von Objekten miteinander interagieren.

Es werden Aussagen über die Anzahl der involvierten Objekte und über den Nachrichtenaustausch zwischen den Objekten gemacht.

Modellierung WS 06/07


Slide72 l.jpg

UML: Sequenzdiagramme

UML - Sequenzdiagramme (Weg-Zeit-Diagramme)

  • Pro Objekt: eine vertikale Lebenslinie (wie lange existiert ein Objekt).

  • Nachrichten werden durch horizontale Pfeile zwischen den Lebenslinien der involvierten Objekte angezeigt (optional ergänzt um Parameter und zusätzliche Restriktionen). Zu den Restruktionen gehören:

    • Vorbedingungen für das Versenden der Nachricht

    • Iterationsangaben (wenn mehrere Objekte mit Nachrichten versorgt werden)

  • Ein Objekt kann sich selbst eine Nachricht schicken (Selbstdelegation). Dies wird graphisch dargestellt durch einen Pfeil, der als Quelle und Ziel die gleiche Lebenslinie hat.

  • Neben Nachrichten gibt es sogenannte returns. Ein return gibt an, ob und wann die Kontrolle an den Nachrichtenversender zurückkehrt (Pfeil mit offener Spitze).

Modellierung WS 06/07


Slide73 l.jpg

UML: Sequenzdiagramme

UML - Sequenzdiagramme (Weg-Zeit-Diagramme)

Ein Bestellungs-

eingabefenster

Eine Bestellungr

Eine interne

Bestellung

Ein Artikel

prepare()

* prepare ()

Object

check()

Condition

Message

[check=„true“]

remove()

Iteration

needsToReorder()

Self-Delegation

Ein neu zu

bestellener

Artikel

new

Return

Zeit

[check = „true“]

new

Ein Liefer-

artikel

Weg

Creation

Modellierung WS 06/07


Slide74 l.jpg

UML: Sequenzdiagramme

UML - SequenzdiagrammeParallele Prozesse und Aktivierungen

  • Mit Hilfe von Aktivierungen kann ausgedrückt werden, wann die Operationen eines Objektes ausgeführt werden (wann also Prozesse zu diesen Methoden existieren)

  • Aktivierungen werden durch Rechtecke auf den Lebenslinien der Objekte angegeben. Ihre Höhe deutet die Lebenszeit der jeweiligen Prozesse an.

  • Selbstdelegation führt zu verschachtelten Aktivierungen.

  • Asynchrone Operationsaufrufe werden durch Pfeile mit halber Spitze dargestellt. Bei einem asynchronen Aufruf wartet der Aufrufer nicht auf ein Ergebnis. Typischerweise eingesetzt für:

    • Erzeugen eines unabhängigen Kontrollbereichs.

    • Erzeugen eines neuen Objektes.

    • Kommunikation mit einem bereits existierenden Kontrollbereich.

    • Pro Objekt: eine vertikale Lebenslinie (wie lange existiert ein Objekt).

  • Das Löschen eines Objektes wird durch ein X am Ende seiner Lebenslinie dargestellt.

Modellierung WS 06/07


Beispiel transaktionsbehandlung regelfall l.jpg

UML: Sequenzdiagramme

Beispiel Transaktionsbehandlung - Regelfall

Asynchrone Nachricht

eine Transaktion

ein Transaktions-

koordinator

neu

ein erster Trans-

aktionsprüfer

Aktivierung

neu

ein zweiter Trans-

aktionsprüfer

neu

Andere

Verarbeitung

unterdrückt

ok

alle

beendet?

gültig

ok

Objekt löscht

sich

alle

beendet?

Selbstdelegation

Modellierung WS 06/07


Beispiel transaktionsbehandlung fehlerfall l.jpg

UML: Sequenzdiagramme

Beispiel Transaktionsbehandlung - Fehlerfall

Wenn eine Transaktion

erzeugt wird...

...dann erzeugt sie ein Objekt

Transaktionskoordinator, der

die Prüfungen überwacht.

Der Koordinator erzeugt eine

Reihe von Prüfern, einen pro

Prüfung. Diese Objekte

arbeiten als getrennte

Prozesse.

Wenn eine Prüfung nicht

erfolgreich ist, dann vernich-

tet der Koordinator alle

noch laufenden Prüfer.

...und teilt mit, daß die

Transaktion ungültig ist.

eine Transaktion

neu

ein Transaktions-

koordinator

neu

ein erster Trans-

aktionsprüfer

neu

ein zweiter Trans-

aktionsprüfer

neu

Versagen

ungültig

Lösch-

prüfer

löschen

ein anderes

Objekt löschen

Modellierung WS 06/07


Slide77 l.jpg

UML: Kollaborationsdiagramme

UML - Kollaborationsdiagramme

  • Kollaborationsdigramme drücken den gleichen Sachverhalt aus wie Sequenzdiagramme.

  • Die Reihenfolge der Nachrichten ergibt sich aus der Numerierung der Nachrichten.

  • Die Anordnung der Objekte gibt die Möglichkeit, Zusammenhänge zwischen Objekten (zum Beispiel die Existenz von Beziehungen oder ihren räumlichen / örtlichen Zusammenhang) zu veranschaulichen.

  • Namensschema für Objekte: Objektname: Klassenname

  • In einem Namen darf entweder der Objektname oder der Doppelpunkt und der Klassenname ausgelassen werden.

Modellierung WS 06/07


Slide78 l.jpg

Reihenfolge

Nachricht

1: vorbereiten()

Selbstdelegation

5: Bedürfnis an

Besteller

2*: vorbereiten()

3: prüfen()

4: [prüfen==true] entfernen

7: [prüfen==true] neu

6: neu

UML: Kollaborationsdiagramme

Objekt

: Bestellungs-

eingabefenster

: Bestellung

Macallan:

Bestellungseingang

Macallan Lager:

Lieferartikel

: Lieferartikel

: Lieferartikel

Modellierung WS 06/07


Kollaborationsdiagramm mit hierarchischer numerierung uml l.jpg

Reihenfolge

1: vorbereiten()

: Bestellung

1.1.2.1: Bedürfnis an

Besteller

1.1*: vorbereiten()

1.1.1: prüfen()

1.1.2: [prüfen==true] entfernen

Macallan:

Bestellungseingang

Macallan Lager:

Lieferartikel

1.1.3: [prüfen==true] neu

1.1.2.2: neu

: Lieferartikel

: Lieferartikel

UML: Kollaborationsdiagramme

Kollaborationsdiagramm mit hierarchischer Numerierung (UML)

: Bestellungs-

eingabefenster

Modellierung WS 06/07


Uml zusammenfassung der bisherigen diagramme l.jpg

UML

UMLZusammenfassung der bisherigen Diagramme

  • Klassendiagramm (inkl. CRC-Karten)Statik

  • AnwendungsfalldiagrammDynamik (Benutzersicht)

  • InteraktionsdiagrammDynamik (Kooperation

    Sequenzdiagrammvon Objekten)

    Kollaborationsdiagramm

Modellierung WS 06/07


Uml zusammenfassung der bisherigen diagramme 2 l.jpg

UML

UMLZusammenfassung der bisherigen Diagramme (2)

Und nun noch:

  • ZustandsübergangsdiagrammeDynamik einzelner Objekte

    einfache

    parallele

  • AktivitätsdiagrammAbläufe / Anwendungsfälle

    und ihre Kooperation

  • KomponentendiagrammSystemstrukturierung

Modellierung WS 06/07


Uml zustands bergangsdiagramm l.jpg

UML: Zustandsübergangsdiagramme

UML - Zustandsübergangsdiagramm

  • Zustandsübergangsdiagramme beschreiben die erlaubten Zustandsübergänge eines Objektes und die Ereignisse, die die Übergänge auslösen.

  • Zustände werden durch abgerundete Rechtecke dargestellt, Übergänge durch Pfeile.

  • Syntax für Pfeilanschriften: Ereignis [Bedingung] Aktion wobei alle drei Teile optional sind.

  • Wenn in einem Zustand interne Operationen ausgeführt werden sollen, so finden sich diese nach dem Schlüsselwort „tue/“ im unteren Teil eines Zustandes.

Modellierung WS 06/07


Uml zustands bergangsdiagramme notation l.jpg

UML: Zustandsübergangsdiagramme

UML-Zustandsübergangsdiagramme(Notation)

Zustand

Zustandsübergang, der durch das Eintreten des Ereignisses

ausgelöst wird (falls die Bedingung gilt!) und dabei die Aktion

durchführt

Zustand, dessen Eintreten das Auslösen der Aktivität veranlaßt.

Ein Übergang ohne Ereignis tritt ein, sobald die Aktivität des

Quellzustandes beendet ist.

Die Bedingungen werden verwendet, um den gewünschten

Zustandsübergang auszuwählen. Die Bedingungen an den

Übergängen mit demgleichen Quellzustand sollten sich

wechselseitig ausschließen.

Ereignis [Bedingung] Aktion

Zustand

tue / Aktivität

[Bedingung] Aktion

Zustand

[Bed1]

[Bed2]

[Bed3]

Modellierung WS 06/07


Uml zustands bergangsdiagramme 2 notation l.jpg

UML: Zustandsübergangsdiagramme

UML-Zustandsübergangsdiagramme (2)(Notation)

Zustand

Ereignis / Aktion

  • Der Zustand reagiert auf das Ereignis mit einer Aktion

  • (die nicht zu einem neuen Zustand führt).

  • Ein Zustand kann mit einer Eingangsaktion (entry) und einer

  • Ausgangsaktinon (exit) assoziiert sein.

  • (alternative Darstellung: rein textuell)

  • Ein Selbstübergang dieser Art führt zur Ausführung von

  • exit

  • Aktion

  • entry

entry

Zustand

exit

Ereignis/

Aktion

entry

Zustand

exit

Modellierung WS 06/07


Uml zustands bergangsdiagramm beispiel bestellung l.jpg

Start

/hole ersten Artikel

Hole nächsten Artikel

[nicht alle Artikel geprüft]

[alle Artikel geprüft

und verfügbar]

Prüfend

tue/prüfe Artikel

Auslieferung

tue/veranlasse

Lieferung

[Alle Artikel geprüft &&

einige nicht im Lager]

geliefert

Aktivität

Artikel erhalten

[alle Artikel verfügbar]

Artikel erhalten

[einige nicht im Lager]

Wartend

Geliefert

Zustand

Interner Übergang

UML: Zustandsübergangsdiagramme

UML - Zustandsübergangsdiagramm(Beispiel Bestellung)

Modellierung WS 06/07


Uml zustands bergangsdiagramm86 l.jpg

UML: Zustandsübergangsdiagramme

UML - Zustandsübergangsdiagramm

Hinweis:

  • Wechselweiser Ausschluß der Bedingungen an den Übergängen, die vom Zustand „prüfend“ ausgehen:

    • nicht alle Artikel geprüft => nächster Artikel wird geprüft

    • alle Artikel geprüft und alle verfügbar => Lieferung veranlassen

    • alle Artikel geprüft, nicht alle verfügbar => wartend

  • Zustände ohne Aktivität oder: Warten auf ein Ereignis

    Bsp.: Im Zustand „wartend“ wird auf die Lieferung von Artikeln

    gewartet, sonst passiert nichts !

Modellierung WS 06/07


Uml zustands bergangsdiagramm erweiterung um abweisen einer bestellung l.jpg

abweisen

abweisen

abweisen

UML: Zustandsübergangsdiagramme

UML - Zustandsübergangsdiagramm(Erweiterung um „Abweisen einer Bestellung“)

Anforderung: Abweisen soll jederzeit möglich sein

=> Von allen Zuständen werden Zustandsübergänge zu „Abgewiesen“ ergänzt.

Hole nächsten Artikel

[nicht alle Artikel geprüft]

[alle Artikel geprüft

und verfügbar]

Prüfend

tue/prüfe Artikel

Auslieferung

tue/veranlasse

Lieferung

[Alle Artikel geprüft &&

einige nicht im Lager]

[Artikel erhalten &&

alle Artikel vorrätig]

geliefert

Artikel erhalten

[einige nicht im Lager]

Wartend

Geliefert

Abgewiesen

Modellierung WS 06/07


Alternative strukturierung durch oberzust nde superstates l.jpg

aktiv

geliefert

abweisen

Geliefert

Abgewiesen

UML: Zustandsübergangsdiagramme

Alternative Strukturierung durch Oberzustände(Superstates)

Hole nächsten Artikel

[nicht alle Artikel geprüft]

[alle Artikel geprüft

und verfügbar]

Prüfend

tue/prüfe Artikel

Auslieferung

tue/veranlasse

Lieferung

[Alle Artikel geprüft &&

einige nicht im Lager]

Artikel erhalten

[einige nicht im Lager]

Artikel erhalten

[alle Artikel verfügbar]

Wartend

Hinweis: es bleibt auf dieser Ebene unspezifiziert, wann (von welchem

Zustand kommend) der Zustand „abgewiesen“ eintritt!

Modellierung WS 06/07


Zustands bergangsdiagramme ein zweites beispiel l.jpg

UML: Zustandsübergangsdiagramme

Zustandsübergangsdiagramme(ein zweites Beispiel)

Prüfend

tue/prüfe Zahlung

[Zahlung nicht OK]

[Zahlung OK]

geprüft

abgewiesen

geliefert

Modellierung WS 06/07


Uml zustands bergangsdiagramme l.jpg

UML: Zustandsübergangsdiagramme

UML-Zustandsübergangsdiagramme

Oft werden externe Ereignisse als Auslöser verschiedener Zustandsübergangsdiagramme betrachtet.

In zusammengehörigen Fällen (Bestellung, Zahlung) kommt man auf diese Weise zu parallelen

Zustandsübergangsdiagrammen.

abgewiesen(Bestellung)

wartend

abgewiesen

prüfend

(Bestellung)

veranlasse

Lieferung

geliefert

Ende

prüfend

(Zahlung)

geprüft

abgewiesen(Zahlung)

Modellierung WS 06/07


Uml zustands bergangsdiagramme91 l.jpg

UML: Zustandsübergangsdiagramme

UML - Zustandsübergangsdiagramme

  • Parallele Zustandsübergangsdiagramme machen Sinn, wenn ein Objekt Mengen von unabhängigen Zuständen hat.

  • Komplizierte, parallele Zustandsübergangsdiagramme sind ein Indiz dafür, daß Objekte in mehrere Objekte aufgeteilt werden sollten (oben z.B. in Bestellung und Zahlung)

Modellierung WS 06/07


Uml zustands bergangsdiagramme bewertung l.jpg

UML: Zustandsübergangsdiagramme

UML - Zustandsübergangsdiagramme(Bewertung)

  • Geeignet für die Beschreibung des Verhaltens eines Objektes über mehrere Anwendungsfälle hinweg

  • nicht geeignet für die Beschreibung der Interaktion zwischen Objekten

  • geeignet für die Beschreibung des Verhaltens der Objekte der wesentlichen Klassen! Vollständigkeitsfanatismus nützt nicht viel.

  • Geeignet für Benutzungsschnittstellen und Kontrollobjekte.

Modellierung WS 06/07


Uml aktivit tsdiagramme l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramme

  • Ein Aktivitätsdiagramm beschreibt die Reihenfolge und Abhängigkeiten von logisch zusammengehörenden Aktivitäten.

  • Eine Aktivität ist dabei ein einzelner Schritt in einem Verarbeitungsablauf.

  • Die Aktivitäten eines Aktivitätsdiagramms sind eindeutig Objekten zugeordnet (wichtiger Unterschied zu Datenflußdiagrammen !)

  • Aktivitäten und Aktivitätsdiagramme sind entweder

    • einer Klasse

    • einer Operation (besonders hilfreich für komplexe Operationen)

    • einem Anwendungsfall zugeordnet. (besonders hilfreich bei Anwendungsfällen mit Parallelität)

Modellierung WS 06/07


Uml aktivit tsdiagramme forts l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramme (Forts.)

  • Aktivitätsdiagramme gehen nicht auf eine der Ursprungsnotationen (Booch, Rumbaugh, Jacobson) zurück.

  • Aktivitätsdiagramme sind nützlich, wenn es um geschäftprozeß-orientierte Softwaresysteme geht.

  • Die Ausführungsregeln für Aktivitätsdiagramme erinnern an die Ausführungsregeln von Petrinetzen.

  • Zur Übung kann das Aktivitätsdiagramm „Getränke“ in ein Petrinetz überführt werden.

Modellierung WS 06/07


Uml aktivit tsdiagramm notation l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramm(Notation)

Synchronisation der Kontrolle (AND)

mit Synchronisationsbedingung

(Die Bedingung ist optional.)

Aufsplitten der Kontrolle

(Zulassen von Parallelität)

Aktivität

Aktivität

Kontrollfluß

Aktivität2 wird nach

Abschluß von Aktivität1

gestartet.

Verzweigunsaktivität

(kann auch durch normale

Aktivität dargestellt werden)

Kontrollfluß, der unter der

angegebenen Bedingung

gewählt wird.

[Bedingung]

Aktivität1

Aktivität2

[Bedingung]

Modellierung WS 06/07


Uml aktivit tsdiagramm forts notation l.jpg

UML: Aktivitätsdiagramme

UML-Aktivitätsdiagramm (Forts.)(Notation)

Aktivität

Objekt

[Zustand]

Aktivität wird durchgeführt,

wenn über einen der eingehenden

Kontrollflüsse die Kontrolle ankommt

(OR)

Start des Ablaufs und Identifikation

der betroffenen Klasse

Ende des Ablaufs (optional)

Aktivität

Die Ausführung der Aktivität versetzt das Objekt in

den angegebenen Zustand (optionales, selten

verwendetes Konstrukt in Aktivitätsdiagrammen).

Hinweis: fragwürdige Überlappung zu Zustands-

übergangsdiagrammen !

Beispiel: aus dem Aktivitätsdiagramm wird eine

Bestellung in den Zustand „abgewiesen“ versetzt (was

bedeutet das,für das Zustandsübergangsdiagramm?)

Klasse

Modellierung WS 06/07


Uml aktivit tsdiagramm beispiel zur spezifikation einer operation l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramm(Beispiel zur Spezifikation einer Operation)

[kein Kaffee]

[keine Cola]

Finde

Getränk

Synchonisation

[Kaffee gefunden]

[Cola gefunden]

Kaffee in

Filter

Wasser

einfüllen

Nehme

Tassen

Nehme Dose

Cola

Aktivität

Filter in

Maschine

Ende

Einschenken

Trinken

Anschalten

Kaffee

kochen

Modellierung WS 06/07


Uml aktivit tsdiagramm beispiel zur spezifikation eines anwendungfalls l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramm(Beispiel zur Spezifikation eines Anwendungfalls)

Informale Beschreibung:

Wenn eine Bestellung eintrifft, überprüfen wir jede Bestellposition, um zu sehen, ob der Lagerbestand reicht. Falls das so ist, werden die Waren der Bestellung zugeordnet. Wenn durch diese Zuordnung der minimale Lagerbestand unterschritten wird, dann wird eine Nachbestellung veranlaßt. Währenddessen wird die Zahlung überprüft. Wenn die Zahlung OK ist und genügend Waren vorhanden sind, wird geliefert. Wenn wir für die Lieferung auf nachzubestellende Waren warten müssen, bleibt die Bestellung offen. Wenn die Zahlung nicht OK ist, wird die Bestellung abgewiesen.

Modellierung WS 06/07


Uml aktivit tsdiagramm beispiel zur spezifikation des anwendungsfalles bestelleingang l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramm(Beispiel zur Spezifikation des Anwendungsfalles „Bestelleingang“)

Bestellung

Mehrfacher

Auslöser

Bestellung

erhalten

*

Für jede Bestellposition

Bestellung

abweisen

Prüfe

Zahlung

Prüfe Verfügbarkeit

einer Bestellposition

[verfügbar]

[OK]

Zuordnung zur

Bestellung

Synchronisations-

bedingung

[nachzubestellen]

[Waren für alle

Bestellpositionen

verfügbar und

Zahlung OK]

Nachbestellungs-

artikel

Veranlasse

Lieferung

Modellierung WS 06/07


Uml aktivit tsdiagramme100 l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramme

Hinweis:

1.)hier wäre ein ausgezeichnetes Ende nicht sinnvoll, da es

mehrere Enden gibt

2.)aus dem linken Zweig kann der rechte nicht angehalten werden! (bei strikter Sequentialiseirung ist dieses Problem vermeidbar,

allerdings nur auf Kosten der Parallelität)

3.)Wenn die Bedingung am Ende von „prüfe Verfügbarkeit einer

Bestellposition“ nicht erfüllt ist, stoppt der Ablauf! Im günstigsten Fall

wird eine ankommende Lieferung die weitere Auslieferung veran-

lassen (Frage der Ausführungssemantik!)

Besser wäre eine Ergänzung zu folgendem Aktivitätsdiagramm:

Modellierung WS 06/07


Uml aktivit tsdiagramm beispiel zur spezifikation des anwendungsfalles bestelleingang101 l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramm(Beispiel zur Spezifikation des Anwendungsfalles „Bestelleingang“)

Bestellung

Erhalte

Lieferung

Bestellung

erhalten

Identifiziere ausstehende,

bestellte Artikel

Für jeden identifizierten,

bestellten Artikel

*

Für jede Bestellposition

*

Bestellung

abweisen

Prüfe

Zahlung

Prüfe Verfügbarkeit

einer Bestellposition

Ordere ankommende Waren

den Bestellungen zu

[verfügbar]

[OK]

Zuordnung zur

Bestellung

Alle offenen

Bestellungen

berücksichtigt

[Waren für alle

Bestellpositionen

verfügbar und

Zahlung OK]

Nachbestellungs-

artikel

[nachzubest.]

Rest ins Lager

Veranlasse

Lieferung

Modellierung WS 06/07


Uml aktivit tsdiagramm bestelleingang und nachlieferung l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramm(Bestelleingang und Nachlieferung)

  • Homogene Spezifikation, aber

    • was passiert bei vielen offenen Bestellungen?

    • wie passiert die Kommunikation zwischen einem Ablauf des Typs Nachlieferung und vielen Nachbestellungen?

      Allgemein: Wie legt ein Ablaufmodell (ausgedrückt als Aktivitätsdiagramm) die Kommunikation auf der Ebene einzelner Abläufe fest?

      Zur Erinnerung: OOA dient der Spezifikation; es müssen keine vollständigen Festlegungen der Implementierungen entstehen. Es ist deshalb durchaus nützlich, mit Beschreibungen zu arbeiten, die nicht alles festlegen, solange man sich der Lücken bewußt ist.

Modellierung WS 06/07


Uml aktivit tsdiagramm strukturierung l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramm(Strukturierung)

  • Das zusammengefügte Beispiel (Bestelleingang und Nachlieferung) ist nicht eindeutig einer Klasse, einer Operation oder einem Anwendungsfall zuzuordnen (weil es durch Komposition zweier getrennter Abläufe entstanden ist).

  • Da man einerseits die Wechselwirkungen beschreiben möchte (deshalb die Komposition) und andererseits die klare Zuordnung nicht aufgeben möchte, gibt es das Strukturierungsmittel der vertikalen Abgrenzung.

Modellierung WS 06/07


Uml aktivit tsdiagramm beispiel zur vertikalen abgrenzung l.jpg

UML: Aktivitätsdiagramme

UML-Aktivitätsdiagramm(Beispiel zur vertikalen Abgrenzung)

Lager-

Manager

Finanzen

Bestellungsverarbeitung

Erhalte

Lieferung

Bestellung

erhalten

Identifiziere ausstehende,

bestellte Artikel

Für jede Bestell-

position

Für jeden identifizierten,

bestellten Artikel

*

*

[nicht OK]

Waren-

wirtschaft

Prüfe

Zahlung

Prüfe Verfügbarkeit

einer Bestellposition

Ordere ankommende Waren

den Bestellungen zu

[verfügbar]

Bestellung

abweisen

Zuordnung zur

Bestellung

[OK]

Alle offenen

Bestellungen

berücksichtigt

Nachbestellungs-

artikel

[nachzubest.]

[Waren für alle

Bestellpositionen

verfügbar und

Zahlung OK]

Rest ins Lager

Veranlasse

Lieferung

Modellierung WS 06/07


Uml aktivit tsdiagramm strukturierung105 l.jpg

UML: Aktivitätsdiagramme

Aktivitäten können verfeinert werden

(passende Abstraktionsebenen für

unterschiedliche Zwecke)

Beispiel: Verfeinerung der Aktivität

„prüfe Zahlung“

UML-Aktivitätsdiagramm (Strukturierung)

Bestimme

Zahlungstyp

Nicht OK

Scheck

Rechnung

[nein]

Prüfe

Scheck

Normaler

Kunde?

Bestellwert

> 1000 DM?

[N]

[nicht OK]

[Y]

[Ja]

[nicht OK]

[nicht erhalten]

Prüfe

Zahlungsgeschichte

Vorkasse

anfordern

Prüfe

Kreditkarte

Kreditwürdigkeit

prüfen

[OK]

Nicht OK

[nicht OK]

[OK]

[OK]

[OK]

Eröffne

Kundenkonto

OK

Modellierung WS 06/07


Uml aktivit tsdiagramme bewertung l.jpg

UML: Aktivitätsdiagramme

UML - Aktivitätsdiagramme (Bewertung)

  • geeignet für die Modellierung von Geschäftsprozessen über die Grenzen von Anwendungsfällen hinweg.

  • geeignet für die detaillierte Analyse von Anwendungsfällen.

  • geeignet für die Modellierung von parallelen Software-Systemen

  • nicht geeignet für die Beschreibung der Interaktion von Objekten

  • nicht geeignet für die Zustandsübergänge eines einzelnen Objektes

Modellierung WS 06/07


Slide107 l.jpg

UML: Komponentendiagramme

UML - Komponentendiagramme - Zwischen OOA und OOD

  • In UML heißt eine Gruppe von „zusammengehörenden“ Klassen package (Komponente).

  • Die Zusammenfassung von Klassen zu Komponenten dient zur Strukturierung von Klassendiagrammen. Oft ist diese Strukturierung ein erster Entwurfsschritt.

  • Als Hilfe dient die Ermittlung von Abhängigkeiten.

  • Zwei Komponenten sind abhängig, wenn Änderungen an der Schnittstelle der einen der anderen bekannt gemacht werden müssen.

  • Zyklische Abhängigkeiten sind in UML nicht verboten, sollten aber dringend aufgelöst werden.

Modellierung WS 06/07


Komponentendiagramme zwischen ooa und oo l.jpg

Behandlung von

Bestellungen

UI

AWT

Mailingliste

UI

Behandlung von

Bestellungen

Anwendung

Mailingliste

Anwendung

Bestellungen

Kunden

UML: Komponentendiagramme

Komponentendiagramme - Zwischen OOA und OO

Paket

Abhängigkeit

Im kleinen Rechteck

links oben, kann dann der

Komponentenname auftauchen,

wenn die internen Klassen

innerhalb des Komponentenrechtecks

angezeigt werden sollen.

Modellierung WS 06/07


Uml methodik l.jpg

UML: Metamodell

UML- Methodik

1 Von den Anforderungen zu Klassendiagrammen

und dann über Use Case Diagrammen zu Interaktionsdiagrammen zu Zustandsübergangsdiagrammen

parallel Übergang zu OOD mit Hilfe von Komponentendiagrammen

Aktivitätsdiagramme nahezu beliebig zur Ablaufveranschaulichung

oder

2 Von den Anforderungen zu Use Case Diagrammen

und dann Aktivitätsdiagrammen zur Detailbeschreibung von Use Cases

und dann über Klassendiagramme zu Interaktionsdigrammen

und dann zu Zustandsübergangsdiagrammen

parallel Übergang zu OOD mit Hilfe von Komponentendiagrammen

Beide Ansätze nur als grobe Richtlinien, nicht als Dogmen!

Modellierung WS 06/07


Uml 2 0 neuerungen l.jpg

UML 2.0 - Neuerungen

  • Seit November 2005

  • Alte Diagramme im wesentlichen beibehalten

  • Erweiterungen:

    • Bessere dynamische Modellierung, insbesondere Zeitaspekte

    • Neue Möglichkeiten zur Referenzierung, auch zwischen Verhaltens- und Strukturdiagrammen

    • Schachtelung in allen Verhaltensdiagrammen

Modellierung WS 06/07


Uml 2 0 diagrammtypen l.jpg

Struktur-

diagramme

Verhaltens-

diagramme

UML 2.0-Diagrammtypen

Komponenten-

diagramm

Klassen-

diagramm

Aktivitäts-

diagramm

Use-Case-

Diagramm

Zustands-

automat

ähnlich Petri-Netzen

Paket-

diagramm

Objekt-

diagramm

Interaktions-Diagramme

Sequenz-

diagramm

Interaktionsübersichts-

diagramm

Kompositions-

strukturdiagramm

Verteilungs-

diagramm

Zeitverlaufs-

diagramm

Kommunikations-

Diagramm

UML 1.x: Kollaborationsdiagramm

Modellierung WS 06/07


  • Login