Formale Methoden: UML

vhb.fh.regensburg.de

Formale Methoden: UML

Einführung

Was ist die Unified Modeling Language ?

Die Unified Modeling Language (UML) ist eine standardisierte Sprache in

der in allen Phasen der Software-Entwicklung Modelle methodisch erstellt

und beschrieben werden können.

Neben freiem Text sind ihre wesentlichen Elemente Grafiken.

Mit der UML steht im Bereich der objektorientierten SW-Entwicklung eine

standardisierten Notation zur Verfügung.

Formale Methoden: UML

1

© Karl Schwarzbeck


Einführung

Was ist die objektorientierte Methode ?

Standardisierte

Notation

Formale Methoden: UML

Methode

Vollständiger

Konzept-Katalog

Planmäßige

Vorgehensweise

Grafik Basis Schritte

Text Statik Regeln

Formale Methoden: Analyse - Phase

Dynamik Beispiele

Formale Methoden: Design - Phase

konkret

abstrakt

2

© Karl Schwarzbeck


Einführung

Standardisierte Notation

Die Ergebnisse einer objektorientierten methodischen Vorgehensweise

werden mit Hilfe grafischer Elemente (z.B. Klassendiagramm) und freiem

Text (z.B. Spezifikationen) beschrieben.

Selbstgewählte Dokumentationsstandards können die Sprachelemente

ergänzen.

Mit der UML steht seit 1997 eine Standard-Notation zur Verfügung, die

weltweit firmenübergreifend akzeptiert und angewendet wird.

Die grafischen Sprachelemente der UML werden zusammen mit den

entsprechenden Konzepten in den folgenden Abschnitten eingeführt.

Formale Methoden: UML

3

© Karl Schwarzbeck


Einführung

Was sind objektorientierte Modelle ?

Modelle sind Abstraktionen der Realität.

Die Kunst bei der Modell-Bildung besteht darin, alle wesentlichen

Gesichtspunkte einer Problemstellung zu erfassen und nicht Wesentliches

zu vernachlässigen - weg zu nehmen (abstrahieren).

Objektorientierte Modelle sind Abstraktionen im Bereich der Software-

Entwicklung. Sie orientieren sich an den Objekten und den Funktionen,

die zur Manipulation dieser Objekte benötigt werden.

Diese Parallelität von Daten- und Funktionsbetrachtung ist das wichtigste

Merkmal der zu Grunde liegenden Konzepte und Vorgehensweisen.

Formale Methoden: UML

Die Kunst des Modellierens ist die Kunst des

Weglassens.

4

© Karl Schwarzbeck


Vollständiger Konzept-Katalog

Überblick

Mit der UML steht nicht nur eine standardisierte Modellierungssprache

zur Verfügung, sondern auch in vollständiger Katalog von Software-

Entwicklungskonzepten.

Die sog. Basiskonzepte gingen aus den Programmiersprachen hervor.

Diese reichen aber nicht aus, um ein Fachmodell einer Problemstellung zu

entwickeln. Es wurden deshalb Elemente der semantischen Datenmodellierung

(siehe ERM!) mit aufgenommen.

Die Synthese zwischen der Welt der objektorientierten Programmiersprachen

und der Welt der Datenmodellierung ermöglicht die zeitunabhängigen

- statischen - Aspekte eines Problemfeldes zu beschreiben (Statisches

Modell).

Zur Modellierung des dynamischen Verhaltens wurden weitere Konzepte

mit den zugehörigen standardisierten Notationen eingeführt und ermöglichen

so auch dynamisches Modelle zu entwerfen.

Formale Methoden: UML

5

© Karl Schwarzbeck


Vollständiger Konzept-Katalog

Statisches Modell

Datenmodellierung

Assoziation

Aggregation

Paket

Basiskonzepte

Formale Methoden: UML

Dynamische Konzepte

Geschäftsprozess

Botschaft

Szenario

Kollaborationsdiagramm

Zustandsautomat

Klasse

Objekt

Attribut

Operation

Vererbung

Polymorphismus

6

© Karl Schwarzbeck


Vollständiger Konzept-Katalog

Statisches Modell

Datenmodellierung

Assoziation

Aggregation

Paket

Basiskonzepte

Formale Methoden: UML

Dynamische Konzepte

Geschäftsprozess

Botschaft

Szenario

Kollaborationsdiagramm

Zustandsautomat

Klasse

Objekt

Attribut

Operation

Vererbung

Polymorphismus

7

© Karl Schwarzbeck


Vollständiger Konzept-Katalog

Statisches Modell

Datenmodellierung

Assoziation*

Aggregation

Paket

Basiskonzepte

Formale Methoden: UML

Dynamische Konzepte

Geschäftsprozess

Botschaft

Szenario

Kollaborationsdiagramm

Zustandsautomat

Klasse*

Objekt*

Attribut*

Operation*

Vererbung

Polymorphismus

8

© Karl Schwarzbeck


Basiskonzepte

Überblick

Unter dem Begriff Basiskonzepte werden diejenigen Konzepte zusammengefasst,

die über alle SW-Entwicklungsphasen verwendet werden

können. Diese Basiskonzepte haben ihren Ursprung in den objektorientierten

Programmiersprachen.

In der Analyse- und Design-Phase sind folgende Konzepte wichtig:

Formale Methoden: UML

•Klasse

•Objekt

•Attribut

•Operation

In der Design- und Implementierungs-Phase können folgende Konzepte

an Bedeutung gewinnen:

•(Mehrfach-) Vererbung

•Polymorphismus

9

© Karl Schwarzbeck


Basiskonzepte

Klasse*

Eine Klasse legt für eine Gruppe von Objekten deren

•Datenstruktur (Attribute)

•Verhalten (Operationen)

•Beziehungen (Assoziationen) zu anderen Klassen

fest.

Der Name einer Klasse muss mindestens im Paket, besser im gesamten

System eindeutig sein.

Im ERM entspricht der Begriff “Entity-Type” (Entitätstyp) dem Begriff

Klasse; wesentlicher Unterschied ist, dass im ERM die Funktionen

(Operationen), die die Datenstrukturen bearbeiten, nicht modelliert

werden.

Formale Methoden: UML

10

© Karl Schwarzbeck


Basiskonzepte

Klasse*

Beispiel:

In einem Hochschul-Verwaltungsprogramm sind die Studenten eine

Gruppe von Objekten, die sich durch eine Reihe von Gemeinsamkeiten

auszeichnen. Die Gemeinsamkeiten dieser Gruppe treffen sowohl für

•die nähere Beschreibung

•den wesentlichen Tätigkeiten

•den Beziehungen zu anderen Gruppen

zu.

Formale Methoden: UML

11

© Karl Schwarzbeck


Basiskonzepte

Klasse*

Notation:

klassenname

attribut1

attribut2

. . .

operation1()

operation2()

. . .

Formale Methoden: UML

Namensfeld

Attributenliste

Operationsliste

Alternativen

klassenname

attribut1

attribut2

. . .

klassenname

operation1()

operation2()

. . .

klassenname

12

© Karl Schwarzbeck


Basiskonzept

Klasse*

Beispiel:

Bezeichnung:

Formale Methoden: UML

Student

Name

Matrikelnr.

Noten

notiere Noten()

immatrikulieren()

exmatrikulieren()

Der Klassenname ist ein Hauptwort (Substantiv) im Singular, das durch

ein Eigenschaftswort (Adjektiv) ergänzt werden kann.

Er muss innerhalb eines Paketes eindeutig sein, besser jedoch im

gesamten System.

13

© Karl Schwarzbeck


Basiskonzepte

Klasse*: Abstrakte Klasse

Aus dem eingangs dargestellten Beispiel kann geschlossen werden, dass

sich für jede Klasse konkrete Objekte erzeugen lassen. Das ist der

Normalfall.

Es gibt daneben Situationen, die es nahelegen Klassen zu modellieren von

denen keine Objekte existieren und auch nicht erzeugt werden können.

Derartige Klassen werden abstrakte Klassen genannt. Zur Bezeichnung

wird ihr Klassenname kursiv geschrieben; der Zusatz {abstract} ist ebenfalls

möglich.

Das Konzept der abstrakten Klassen ist besonders für die Vererbung von

Bedeutung. Dort wird es ausführlich behandelt.

Formale Methoden: UML

14

© Karl Schwarzbeck


Basiskonzepte

Objekt*

Ein Objekt (im ERM “Entity”) ist ein konkretes Exemplar einer Klasse.

Die Studentin Marie-José Julier mit der Matrikelnummer 123456 ist ein

Objekt der Klasse Student.

Der Zustand eines Objektes wird durch die aktuellen Werte der Attribute

festgelegt.

Das Verhalten eines Objektes wird beschrieben durch die Menge der

Operationen, die in der zugehörigen Klasse definiert sind; der Zustand

eines Objektes kann nur mit Hilfe dieser Operationen verändert oder abgefragt

werden: Das bedeutet, dass genau die Operationen zu definieren

sind, die die gewünschten Manipulationen des Zustandes eines Objektes

erlauben.

Dadurch wird eine Einheit aus Zustand (Datenstruktur) und den Operationen

erzwungen. Operationen aus anderen Klassen können nicht auf den

Zustand zugreifen. Damit ist das Geheimnisprinzip realisiert.

Formale Methoden: UML

15

© Karl Schwarzbeck


Basiskonzepte

Objekt*

Beispiel:

:Student

Name = (Marie-José Julier)

Matrikelnr. = 123456

Noten = (Mathe=2, Java=3)

Formale Methoden: UML

16

© Karl Schwarzbeck


Basiskonzepte

Objekt*

Notation:

objektname: klassenname

attribut1 = wert1

attribut2 = wert2

. . .

Operationen werden bei einem

Objekt nie angegeben !

Formale Methoden: UML

Alternativen

:klassenname

attribut1 = wert1

attribut2 = wert2

. . .

objektname

objektname

attribut1 = wert1

attribut2 = wert2

. . .

:klassenname

17

© Karl Schwarzbeck


Basiskonzepte

Objekt*: Externe / interne Objekte

Externe Objekte existieren in der realen Welt.

Interne Objekte existieren in einem Softwaresystem.

Das interne Objekt wird nur durch die Eigenschaften (und Tätigkeiten)

beschrieben, die bei der aktuellen Problemstellung von Bedeutung sind.

Beispiel:

Betrachten wir den realen Kunden Herrn Weißbeck bei der Modellierung

einer Banksoftware. Die Tatsache, dass Herr Weißbeck einen Pilotenschein

besitzt, ist dabei ohne Relevanz.

Soll dagegen ein Programm zur Verwaltung eines Flugsportvereines erstellt

werden, ist dieser Aspekt sehr wohl von Bedeutung.

Interne Objekte sind Abstraktionen der realen Welt -

der externen Objekte.

Formale Methoden: UML

18

© Karl Schwarzbeck


Basiskonzepte

Attribut*

In der Klasse wird beschrieben, welche Attribute die Objekte dieser

Klasse charakterisieren.

Alle Objekte besitzen die gleichen Attribute; die Werte der Attribute sind

bei den Objekten verschieden.

Beispiel:

Student

Name

Geburtsdatum

Immatrikulation

Matrikelnr.

Vordiplom

Noten

Formale Methoden: UML

:Student

Name = (Alexander, Huber)

Geburtsdatum = 14.2.80

Immatrikulation = 1.9.99

Matrikelnr. = 654321

Noten = (Mathe=2, Prg.Sprache=3)

19

Das Attribut

Vordiplom hat -

noch - keinen Wert.

© Karl Schwarzbeck


Basiskonzepte

Attribut*

Notation:

Klasse

attribut

klassenattribut

/abgeleitetes Attribut

Formale Methoden: UML

Attributspezifikation

attribut: typ = Anfangswert

{mandatory, key, frozen, Einheit: ..., Beschreibung: ...}

Die richtige Entscheidung, welcher Begriff soll die Klasse

bezeichnen, welcher soll Attribut sein, ist oft Voraussetzung für ein

gutes Modell.

20

© Karl Schwarzbeck


Basiskonzepte

Attribut*: Klassenattribut

Haben alle Objekte für ein bestimmtes Attribut denselben Wert, liegt ein

Klassenattribut vor.

Student

Name

Geburtsdatum

Immatrikulation

Matrikelnr.

Vordiplom

Noten

. . .

Stundenlohn

Beispiel:

Formale Methoden: UML

Alle Studierende bekommen, wenn sie als Hilfskräfte

arbeiten, den gleichen Stundenlohn. Dieses Datum

sollte dann in der Klasse Student als Klassenattribut

eingetragen werden.

Der Vorteil ist, dass dieser Wert nur einmal gespeichert

werden muss; eine Änderung erfordert somit nur

einen Zugriff: Speicher- und Zeit-effizient.

Bezeichnung: ________________

21

© Karl Schwarzbeck


Basiskonzepte

Attribut*: Abgeleitetes Attribut

Der Wert eines abgeleiteten Attributes kann immer aus anderen Attributen

errechnet werden.

Beispiel:

Aus der Anzahl und dem Artikelpreis lässt sich das abgeleitete Attribut

/Positionsbetrag errechnen. Auf eine separate Einführung dieses Attributes

könnte verzichtet werden.

Bezeichnung: /

Vorsicht ! ! ! Änderungen von Werten abgeleiteter Attribute nie direkt,

sondern immer nur über das Berechnungsverfahren ! ! !

Häufig verbessern abgeleitete Attribute die Verständlichkeit eines

Modells und können erheblich zur Performance-Steigerung beitragen.

Formale Methoden: UML

22

© Karl Schwarzbeck


Basiskonzepte

Attribut*

Attributname:

Der Attributname muss innerhalb der Klasse eindeutig sein. In der Regel

ist er ein Hauptwort (Substantiv). Er beschreibt die gespeicherten Daten.

Außerhalb der Klasse wird die Bezeichnung klasse.attribut verwendet.

Geheimnisprinzip:

Auf Attribute darf nur mit den in der zugehörigen Klasse vereinbarten

Operationen zugegriffen werden.

Die Attribute sind zwar sichtbar für den Systementwickler, aber nicht

sichtbar für andere Klassen.

Formale Methoden: UML

23

© Karl Schwarzbeck


Basiskonzepte

Attribut*

Restriktionen:

Zwischen den Attributwerten können Bedingungen existieren, die immer

erfüllt sein müssen.

Beispiel:

Für die Attribute der Klasse Student gilt

Vordiplom > Immatrikulation > Geburtsdatum

Formale Methoden: UML

24

© Karl Schwarzbeck


Basiskonzepte

Attribut*: Spezifikation

Um aus einem OOA-Modell den Prototyp der Benutzeroberfläche abzuleiten

muss jedes Attribut durch folgende Angaben spezifiziert werden:

1. Name

2. Typ

Formale Methoden: UML

3. Anfangswert

4. Muss-Attribut (mandatory)

5. Schlüssel (key)

6. Attributwert nicht änderbar (frozen)

7. Einheit

8. Beschreibung

25

© Karl Schwarzbeck


Basiskonzepte

Attribut*: Spezifikation

1. Name

Innerhalb einer Klasse eindeutig. (Wurde bereits beschrieben, siehe dort.)

2. Typ

Typ = [Standardtyp, Aufzählungstyp, Klasse, list of Typ] (Wird erläutert.)

3. Anfangswert

Diesen Wert nimmt ein Attribut bei seiner Erzeugung an.

4. Muss-Attribut (mandatory)

Beim Erzeugen muss ein Attributwert eingetragen werden.

5. Schlüssel (key)

Ein Attribut ist Schlüssel, wenn es jedes Objekt einer Klasse eindeutig

identifiziert.

Formale Methoden: UML

26

© Karl Schwarzbeck


Basiskonzepte

Attribut*: Spezifikation

6. Attributwert nicht änderbar (frozen)

Attribut, dessen einmal festgelegter Wert nicht mehr geändert werden

kann.

7. Einheit

Wird für die Benutzeroberfläche benötigt und gibt an in welchen

Einheiten eine Eingabe erwartet wird. (Beispiel: Beträge in Euro, Zeit in

Stunden usw.)

8. Beschreibung

Falls der Name des Attributes nicht ausreicht, kann mit einer Beschreibung

die Bedeutung genauer dargestellt werden.

Bei abgeleiteten Attributen wird die Zusammensetzung und Berechnung

angegeben.

Formale Methoden: UML

27

© Karl Schwarzbeck


Basiskonzepte

Operation*

Eine Operation ist eine Funktion, die auf die (Klassen-) internen Daten

(Attributwerte) Zugriff hat. Sie ist eine ausführbare Tätigkeit; der Name

einer Operation muss deshalb immer ein Tunwort (Verb) enthalten, das

die Tätigkeit möglichst treffend benennt.

Auf alle Objekte einer Klasse sind dieselben Operationen anwendbar.

Es können drei Kategorien von Operationen unterschieden werden:

•Objektoperationen (kurz Operationen)

•Konstruktoroperationen

•Klassenoperationen

Nicht selbstverständlich und häufig nicht trivial ist die Entscheidung,

welche Operation welcher Klasse zugeordnet werden soll.

Formale Methoden: UML

28

© Karl Schwarzbeck


Basiskonzepte

Operation* : Objektoperation

Eine Objektoperation wird stets auf ein einzelnes, bereits existierendes,

Objekt angewendet.

Beispiel: notiere Noten(), exmatrikulieren()

Formale Methoden: UML

29

© Karl Schwarzbeck


Basiskonzepte

Operation*: Konstruktoroperation

Eine Konstruktoroperation erzeugt ein einzelnes Objekt; dabei können

entsprechende Initialisierungen und Datenerfassungen durchgeführt

werden.

Beispiel: immatrikulieren()

Formale Methoden: UML

30

© Karl Schwarzbeck


Basiskonzepte

Operation*: Klassenoperation

Eine Klassenoperation wird nicht auf ein einzelnes Objekt angewendet.

Sie bezieht sich auf die Gesamtheit aller Objekte einer Klasse. Sie wird

durch Unterstreichen gekennzeichnet.

Beispiel: drucke Liste-Vordiplom()

Formale Methoden: UML

31

© Karl Schwarzbeck


Basiskonzepte

Operation*: Klassenoperation - 1. Fall

Eine Operation verändert Klassenattribute ohne Beteiligung eines

einzelnes Objektes.

Beispiel: verändere Stundenlohn()

Dem gewählten Beispiel liegt die angenommene Situation zugrunde, dass

Studenten als Hilfskräfte tätig sein können und der - für alle Studenten

gleiche - Stundenlohn als Berechnungsgrundlage dient.

Da sich die Operation auf ein Attribut der Klasse Student bezieht, wird

diese Operation der Klasse Student zugeordnet.

Da sie sich nicht auf ein einzelnes Objekt bezieht, ist diese Operation als

Klassenoperation zu kennzeichnen.

Formale Methoden: UML

32

© Karl Schwarzbeck


Basiskonzepte

Operation*: Klassenoperation - 2. Fall

Eine Operation bezieht sich auf alle oder mehrere Objekte einer Klasse.

Dabei wird ausgenutzt, dass eine Klasse alle ihre Objekte kennt

(Objektverwaltung).

Beispiel: drucke Liste-Vordiplom()

Es werden von allen Studierenden diejenigen ausgedruckt, die das

Vordiplom erworben haben.

Formale Methoden: UML

33

© Karl Schwarzbeck


Basiskonzepte

Operation*: Sieben Arten von Operationen

1. Operationen mit lesendem Zugriff (auf die Attribute derselben Klasse):

Beispiel: drucke Studienbescheinigung()

2. Operationen mit schreibendem Zugriff:

Beispiel: notiere Noten()

3. Operationen zur Durchführung von Berechnungen:

Beispiel: berechne Notendurchschnitt()

4. Operationen zum Erzeugen und Löschen von Objekten:

Beispiel: immatrikulieren(), exmatrikulieren()

5. Operationen zum Selektieren von Objekten (immer Klassenoperationen):

Beispiel: drucke Liste-Vordiplom()

Formale Methoden: UML

34

© Karl Schwarzbeck


Basiskonzepte

Operation*: Sieben Arten von Operationen

6. Operationen zum Aufbau von Verbindungen zwischen Objekten:

Absolviert die Studentin Meier ihr Praktikum bei der Firma OK-Soft, dann

muss im Zuge einer geeigneten Operation eine Verbindung zum Objekt

OK-Soft aus der Klasse Firma erzeugt werden.

Beispiel: anmelden zum Praktikum()

Meier: Student

Huber: Student

Der Student Huber wurde noch nicht zum Praktikum bei irgendeiner

Firma angemeldet.

Formale Methoden: UML

:Firma

:Firma

35

© Karl Schwarzbeck


Basiskonzepte

Operation*: Sieben Arten von Operationen

7. Operationen, die Operationen aus anderen Klassen aktivieren:

Um einen Praktikumsnachweis erstellen zu können muss das Objekt

Meier über eine Obejektverbindung Operationen des Firmenobjektes

verwenden; etwa zum Lesen von Firmenanschrift und weiterer

Attributwerte des Firmenobjektes.

Beispiel: drucke Praktikumsnachweis()

Formale Methoden: UML

36

© Karl Schwarzbeck


Basiskonzepte

Operation*: Verwaltungsoperationen

Verwaltungsoperationen sind elementare Operationen, die in (fast) jeder

Klasse benötigt werden. Im Klassendiagramm werden sie meist nicht

aufgeführt um die Übersichtlichkeit zu erhöhen.

Für eine detaillierte Beschreibung von dynamischen Zusammenhängen in

Interaktionsdiagrammen (siehe “Dynamische Konzepte”) werden sie

benötigt.

Beispiele:

new() Erzeugen eines neuen Objektes

delete() Löschen eines Objektes

setAttribut() Schreiben eines neuen Attributwertes

getAttribut() Lesen eines Attributwertes

link() Aufbau einer Verbindung zwischen Objekten

unlink() Entfernen einer Verbindung zwischen Objekten

getlink() Lesen einer Verbindung zwischen Objekten

Formale Methoden: UML

37

© Karl Schwarzbeck


Basiskonzepte

Operation*: Externe Verwaltungsoperationen

Externe Verwaltungsoperationen sind Operationen, die an der

Benutzeroberfläche eingegeben bzw. aufgerufen werden.

Beispiele:

erfassen() Erzeugen eines neuen Objektes; im Unterschied zur

elementaren Operation new() können noch weitere Aktionen

damit verbunden sein

ändern() Ändern eines vorhandenen Objektes

löschen() Löschen eines Objektes

zeigeListe() Alle Objekte der Klasse am Bildschirm anzeigen

Formale Methoden: UML

38

© Karl Schwarzbeck


Basiskonzepte

Operation*: Externe / interne Operationen

Externe Operationen sind Operationen, die an der Benutzeroberfläche

eingegeben bzw. aufgerufen werden; sie können weitere - interne -

Operationen aufrufen.

Interne Operationen werden in das Klassendiagramm nur dann

eingetragen, wenn es für das Verständnis nötig ist.

Ein wesentliches Ziel der Arbeiten in der Analysephase ist es,

alle externen Operationen zu ermitteln.

Formale Methoden: UML

39

© Karl Schwarzbeck


Basiskonzepte

Vererbung

Vererbung bedeutet, dass eine Unterklasse über die Eigenschaften

(Attribute) und Verhalten (Operationen) einer Oberklasse verfügen kann.

Beispiel:

Angestellter

Personalnr

Name

Adresse

Geburtsdatum

Gehalt

Bank

drucke Adresse()

überweise Gehalt()

Formale Methoden: UML

Student

Matrikelnr

Name

Adresse

Geburtsdatum

Immatrikulation

drucke Adresse()

drucke Ausweis()

Stud. Hilfskraft

Matrikelnr

Name

Adresse

Geburtsdatum

Immatrikulation

Beschäftigungen

drucke Adresse()

drucke Ausweis()

drucke Arbeitszeiten()

40

© Karl Schwarzbeck


Basiskonzepte

Vererbung

Beispiel:

Angestellter

Personalnr

Gehalt

Bank

überweise Gehalt()

Formale Methoden: UML

Person

Name

Adresse

Geburtsdatum

drucke Adresse()

Student

Matrikelnr

Immatrikulation

drucke Ausweis()

Stud. Hilfskraft

Beschäftigungen

drucke Arbeitszeiten()

41

© Karl Schwarzbeck


Basiskonzepte

Vererbung

Formale Methoden: UML

Oberklasse

attributA

klassenattribut = W

operationA()

Notation:

attributB

attributC

Unterklasse

operationB()

42

© Karl Schwarzbeck


Basiskonzepte

Vererbung: Vor- und Nachteile

Vorteile:

• Mit geringem Aufwand können neue Klassen entworfen werden, die auf

bereits existierende aufbauen.

• Bei Änderungen in einer Oberklasse ist die Änderung in der gesamten

darunterliegenden Vererbungshierarchie gültig.

Nachteile:

• Bei Änderungen in einer Oberklasse ist die Änderung in der gesamten

darunterliegenden Vererbungshierarchie gültig. Oft muss die Unterklasse

an die Änderung angepasst werden.

• Geheimnisprinzip ist verletzt: Um eine Unterklasse zu verstehen muss

man auch die Oberklasse kennen.

Formale Methoden: UML

43

© Karl Schwarzbeck


Basiskonzepte

Polymorphismus

Polymorphismus heißt Vielgestaltigkeit und bedeutet, dass der Aufrufer

einer Operation (der Sender einer Botschaft) nicht wissen muss, zu welcher

Klasse das Empfängerobjekt gehört.

Kreis

Formale Methoden: UML

Grafikelement

Mittelpunkt

istSichtbar

zeichnen()

Rechteck

Radius

Länge

Breite

zeichnen() zeichnen()

44

© Karl Schwarzbeck


Basiskonzepte

Polymorphismus

Gehen wir von der Vererbungsstruktur der vorangegangenen Seite aus,

ergeben sich vollkommen unterschiedliche Wirkungen.

Deklariert man einen Zeiger pGrafik

Grafikelement* pGrafik,

kann der Operationsaufruf

pGrafik->zeichnen()

Folgendes bewirken:

Gilt pGrafik = new Kreis, dann wird Kreis.zeichnen() ausgeführt.

Gilt pGrafik = new Rechteck, dann wird Rechteck.zeichnen() ausgeführt.

Formale Methoden: UML

45

© Karl Schwarzbeck


Basiskonzepte

Polymorphismus

Der Polymorphismus ist (soll) in der Analysephase von untergeordneter

Bedeutung (sein!).

In der Design- und Implementierungsphase ist er allerdings ein wichtiges

Konzept der objektorientierten Software-Entwicklung.

Seine Ursprünge reichen weit in die Geschichte der Programmiersprachen

zurück:

Die arithmetischen Operatoren “+”, “-”, “x” und “:” werden meist auf sowohl

ganze als auch reelle Zahlen angewendet. Die zu Grunde liegenden

Algorithmen sind je nach Typ der Operanden vollkommen unterschiedlich.

Für den Anwender ist es aber sehr komfortabel, wenn er sich darüber

keine Gedanken zu machen braucht.

Dieses Konzept wurde systematisch weiterentwickelt und jetzt allgemein

verfügbar gemacht. Es soll dazu beitragen, flexible und leicht änderbare

Programme zu schreiben.

Formale Methoden: UML

46

© Karl Schwarzbeck


Datenmodellierung

Überblick

Die Ähnlichkeit zwischen dem Entity-Relationship-Diagramm (ERD) und

dem Klassendiagramm ist sehr groß. Die Begriffe Beziehung (relationship)

und Assoziation bedeuten das Gleiche.

Unterschiede ergeben sich aus der stärkeren Betonung der Anwendersicht

im objektorientierten Ansatz:

•Es ist keine Normalisierung der Attribute notwendig.

•Künstliche Schlüsselattribute sind nicht notwendig.

•Fremdschlüssel sind nicht notwendig.

Das Paket-Konzept ist im ERM nicht bekannt. Es ist aber ein wertvolles

Instrument, um insbesondere größere Softwareprogramme auf einer

hohen Abstraktionsebene mit einfachen Mitteln strukturieren zu können.

Formale Methoden: UML

47

© Karl Schwarzbeck


Datenmodellierung

Assoziation*

Die Bedeutung der beiden Begriffe “Beziehung” (relationship) aus dem

ERM und “Assoziation” aus der objektorientierten Sicht ist gleich.

Die Begriffe “Entität” (Entity) und “Objekt” sind in Bezug auf die Datenmodellierung

vergleichbar.

Ähnliches gilt für die Bezeichnung “Entitätstyp” (Entity-Type) einerseits

und “Klasse” andererseits.

Die Notation ist identisch.

(Siehe “Formale Methoden: ERM”, Kapitel “Notation im Entity-

Relationship-Model”.)

Formale Methoden: UML

48

© Karl Schwarzbeck


Datenmodellierung

Aggregation

Bedeutung und Notation sind identisch wie im ERM.

Formale Methoden: UML

49

© Karl Schwarzbeck


Datenmodellierung

Paket

Ein Paket fasst Modellelemente (z.B Klassen) zusammen.

Ein Paket kann selbst Pakete enthalten. Ein Softwaresystem kann als

großes Paket betrachtet werden, das alles andere enthält.

Das Konzept des Paketes hilft dabei die Komponenten eines Modells in

sinnvoller Weise zu gruppieren. Dadurch wird die Beschreibung der

Systemstruktur auf einer hohen Abstraktionsebene erleichtert.

Formale Methoden: UML

50

© Karl Schwarzbeck


Datenmodellierung

Paket: Notation

Beispiel:

Ein Warenwirtschaftssystem (WWS) enthält die Pakete Einkauf,

Produktion, Verkauf und Materialwirtschaft.

WWS

Formale Methoden: UML

Einkauf

Produktion

Verkauf

Material-

Wirtschaft

51

© Karl Schwarzbeck


Datenmodellierung

Paket: Notation

Jede Klasse (allgemeiner: jedes Modellelement) gehört zu genau einem

Paket. In anderen Paketen kann darauf verwiesen werden.

Ein Paket definiert einen Namensraum für alle in ihm enthaltenen Modellelemente.

Systemweit eindeutig ist z.B. die Bezeichnung

Paket::Klasse

Bei geschachtelten Paketen wird die

Bezeichnung nach folgendem Muster

durchgeführt:

Paket1::Paket11::Paket111::Klasse

Formale Methoden: UML

Paket1

Paket11

Paket111

Klasse

52

© Karl Schwarzbeck


Datenmodellierung

Paket: Notation - Abhängigkeit

Vermutete Auswirkungen von Änderungen können folgendermaßen

dargestellt werden:

Paket1

Formale Methoden: UML

Paket3

Paket2

Dabei sind Paket1 und Paket2 von Paket3 abhängig.

Änderungen in Paket3 können zu Änderungen in den beiden abhängigen

Paketen führen.

53

© Karl Schwarzbeck


Dynamische Konzepte

Überblick

Dynamische Konzepte wurden in die UML mit dem Ziel aufgenommen,

zeitliche Abläufe beschreiben zu können.

Die vier dynamischen Konzepte, die sowohl in der Analyse- als auch

Design-Phase zur Modellierung Zeitablauf-wichtiger bzw. -kritischer

Ausschnitte eines Gesamtsystems angewendet werden können, sind

Formale Methoden: UML

•Geschäftsprozess

•Botschaft

•Szenario

•Zustandsautomat

Zur Darstellung dieser dynamischen Modelle müssen sehr häufig Elemente

der Basiskonzepte (Klasse, Operation etc.) mit verwendet werden.

54

© Karl Schwarzbeck


Dynamische Konzepte

Geschäftsprozess

Bei der Modellierung der Geschäftsprozesse sollen die ergebnisorientierten

Arbeitsabläufe bei der Benutzung der zu realisierenden Software im

Vordergrund stehen und nicht die Funktionalität des zu erstellenden Programms.

Ein Geschäftsprozess besteht aus mehreren zusammenhängenden Aufgaben,

die von einem Akteur durchgeführt werden. Dabei wird ein bestimmtes

Ziel verfolgt bzw. ein gewünschtes Arbeitsergebnis angestrebt.

Ein Akteur ist eine Rolle, die ein Benutzer des Systems spielt. Jeder Akteur

hat einen gewissen Einfluss auf das System. Ein Akteur ist häufig eine Person.

Es kann sich aber auch um eine Organisationseinheit oder ein externes

System handeln, das mit dem zu modellierenden System kommuniziert.

Akteure befinden sich stets außerhalb des Systems mit dem sie agieren. In

der Analyse-Phase ist jedoch nicht von Anfang an klar, was zum Software-

System gehört (gehören soll) und was nicht.

Formale Methoden: UML

55

© Karl Schwarzbeck


Dynamische Konzepte

Geschäftsprozess

Das Geschäftsprozess-Konzept hat seine Wurzeln in den von Jacobson

1987 erstmals vorgestellten Begriff “use case”. Dort wird zwischen einem

use case

•im Software-System und

•im Unternehmen

unterschieden.

Wird dieses Konzept in der Analyse-Phase eingesetzt kann nicht zu Beginn

der Analyse bekannt sein, welche Aktivitäten durch das Software-

System übernommen werden sollen und welche Aktivitäten im - möglicherweise

neu gestalten - organisatorischen Umfeld des Benutzers verbleiben.

Die Wahl des Begriffes “Geschäftsprozess” soll andeuten, dass nicht die

Funktionalität der Software im Zentrum der Betrachtungen steht, sondern

die ergebnisorientierten Arbeitsabläufe unter Einbeziehnug der Benutzung

der zu realisierenden Software.

Formale Methoden: UML

56

© Karl Schwarzbeck


Dynamische Konzepte

Geschäftsprozess: Notation

Kundensachbearbeiter

Lieferantensachbearbeiter

Formale Methoden: UML

Warenwirtschafts-Software-

System

Auftrag

bearbeiten

Lager

verwalten

Buchhalter

Lagersachbearbeiter

57

© Karl Schwarzbeck


Dynamische Konzepte

Botschaft

Eine Botschaft ist die Aufforderung eines Senders (client) an einen

Empfänger (server) eine Dienstleistung zu erbringen.

Der Empfänger führt eine Operation aus. Da diese Operation den gleichen

Namen hat wie die Botschaft, liegt der Unterschied der beiden Begriffe in

der unterschiedlichen Betrachtungsweise:

Ein Funktionsaufruf kann überall in einem Programm stehen - es wird

eine Botschaft von einer bestimmten Stelle (gehört zum client) gesendet an

ein Objekt einer Klasse (gehört zum server).

Die Menge aller Botschaften auf die die Objekte einer Klasse reagieren

können, wird das Protokoll dieser Klasse bezeichnet.

Formale Methoden: UML

58

© Karl Schwarzbeck


Dynamische Konzepte

Botschaft: Vererbung

Erhält ein Objekt, das in einer Vererbungshierarchie integriert ist, eine

Botschaft, läuft folgender Mechanismus ab:

Zunächst wird in der Klasse, zu der dieses Objekt gehört, die Liste der

eigenen Operationen durchsucht. Wird eine Operation gleichen Namens

gefunden, wird sie ausgeführt.

Wird keine gefunden, wird die Suche in der direkten Oberklasse fortgesetzt.

Formale Methoden: UML

59

© Karl Schwarzbeck


Dynamische Konzepte

Botschaften senden

client

:Filiale

server

Controlling-

Mitarbeiter

Filiale

Bezeichnung

Leiter

berechneDurchschnittsumsatz()

berechneDurchnittsumsatz()

Formale Methoden: UML

Der Durchschnittsumsatz pro

Versicherten soll für mehrere

Filialen einer Versicherung

berechnet werden.

Versicherter

Nummer

Name

1 * 1 1..*

berechneBeitrag()

Vertrag

Nummer

Art

Jahresbeitrag

Abschlussdatum

60

getJahresbeitrag()

© Karl Schwarzbeck


Dynamische Konzepte

Botschaften senden

Controlling-

Mitarbeiter

berechneDurchschnittsumsatz()

:Filiale

berechneBeitrag()

:Versicherter

client server

Filiale

Bezeichnung

Leiter

berechneDurchnittsumsatz()

Formale Methoden: UML

Der Durchschnittsumsatz pro

Versicherten soll für mehrere

Filialen einer Versicherung

berechnet werden.

Versicherter

Nummer

Name

1 * 1 1..*

berechneBeitrag()

Vertrag

Nummer

Art

Jahresbeitrag

Abschlussdatum

61

getJahresbeitrag()

© Karl Schwarzbeck


Dynamische Konzepte

Botschaften senden

Controlling-

Mitarbeiter

berechneDurchschnittsumsatz()

:Filiale

berechneBeitrag()

:Versicherter

getJahresbeitrag()

:Vertrag

client server

Filiale

Bezeichnung

Leiter

berechneDurchnittsumsatz()

Formale Methoden: UML

Der Durchschnittsumsatz pro

Versicherten soll für mehrere

Filialen einer Versicherung

berechnet werden.

Versicherter

Nummer

Name

1 * 1 1..*

berechneBeitrag()

Vertrag

Nummer

Art

Jahresbeitrag

Abschlussdatum

62

getJahresbeitrag()

© Karl Schwarzbeck


Dynamische Konzepte

Szenario

Ein Szenario ist eine Sequenz von Verarbeitungsschritten.

Welche Schrittte im einzelnen zu durchlaufen sind, ist von bestimmten

Bedingungen abhängig.

Diese Schritte sollen dazu beitragen ein festgelegtes Ziel zu erreichen bzw.

ein gewünschtes Ergebnis zu erhalten.

Die Sequenz beginnt mit einem auslösenden Ereignis und wird fortgesetzt,

bis das Ziel erreicht ist oder aufgegeben wird.

Zur Darstellung kann das Sequenz- oder das Kollaborationsdiagramm

verwendet werden.

Formale Methoden: UML

63

© Karl Schwarzbeck


Dynamische Konzepte

Szenario

Ein Geschäftsprozess wird durch eine Anzahl von Szenarios dokumentiert.

Man kann zwei Arten von Szenarios unterscheiden:

•Szenarios, die zum Ziel führen

•Szenarios, die zur Aufgabe des Zieles führen (Fehlschlag, Abbruch)

Formale Methoden: UML

64

© Karl Schwarzbeck


Dynamische Konzepte

Szenario

Aus dem Beispiel Geschäftsprozess Auftrag bearbeiten lassen sich folgende

Szenarios ableiten:

1 Auftrag für einen Neukunden bearbeiten, wenn mindestens ein Artikel

lieferbar ist.

2 Auftrag für einen bereits existierenden Kunden bearbeiten, wenn

mindestens ein Artikel lieferbar ist.

3 Auftrag für einen bereits existierenden Kunden bearbeiten, sich seine

Kundendaten geändert haben und mindestens ein Artikel lieferbar ist.

Formale Methoden: UML

65

© Karl Schwarzbeck


Dynamische Konzepte

Sequenzdiagramm - Auftrag bearbeiten-1 (Vorversion)

erfassen()

erfassen()

:Kunde

Formale Methoden: UML

:Auftrag

istLieferbar()

erstelle

Rechnung()

:Artikel

66

© Karl Schwarzbeck


Dynamische Konzepte

Sequenzdiagramm - Auftrag bearbeiten-1

erfassen()

erfassen()

:Kunde

Formale Methoden: UML

:Auftrag

new()

setBestellmenge()

istLieferbar()

[nichtLieferbar]

setBestellmenge()

erstelle

Rechnung()

:Auftragsposition

:Artikel

67

© Karl Schwarzbeck


Dynamische Konzepte

Sequenzdiagramm - Auftrag bearbeiten-2/3

abrufen()

[Änderung]

aktualisieren()

erfassen()

:Kunde

Formale Methoden: UML

:Auftrag

istLieferbar()

erstelle

Rechnung()

:Artikel

68

© Karl Schwarzbeck


Dynamische Konzepte

Sequenzdiagramm: Notation

Zeit

operation1()

Botschaft

Objekt wird

gelöscht

Formale Methoden: UML

Objekt wird

erzeugt

:klasse1

operation2()

operation3()

operation4()

:klasse2 :klasse3

Objekt-

Lebenslinie

Zeit, in der

eine Operation

aktiviert ist

69

© Karl Schwarzbeck


Dynamische Konzepte

Sequenzdiagramm: Notation

Zeit

operation1()

Formale Methoden: UML

:klasse1

operation2()

operation3()

operation4()

:klasse2 :klasse3

70

Objekte

© Karl Schwarzbeck


Dynamische Konzepte

Kollaborationsdiagramm

Controlling-

Mitarbeiter

berechneDurchschnittsumsatz()

Formale Methoden: UML

Der Durchschnittsumsatz pro

Versicherten soll für mehrere

Filialen einer Versicherung

berechnet werden.

:Filiale :Versicherter :Vertrag

berechneBeitrag() getJahresbeitrag()

71

© Karl Schwarzbeck


Dynamische Konzepte

Kollaborationsdiagramm (Objektdiagramm)

Meier: Versicherter Huber: Versicherter Kraus: Versicherter

Leben

:Vertrag

Formale Methoden: UML

München: Filiale Berlin: Filiale

Leben

:Vertrag

Hausrat

:Vertrag

Hausrat

:Vertrag

72

© Karl Schwarzbeck


Dynamische Konzepte

Kollaborationsdiagramm: Notation

operation()

1: operation1()

Formale Methoden: UML

:klasse2

:klasse1

:klasse3

2: operation2()

2.1: operation3()

73

© Karl Schwarzbeck


Dynamische Konzepte

Kollaborationsdiagramm: Notation

operation()

1: operation1()

Formale Methoden: UML

:klasse2

{new}

:klasse1

{transient}

:klasse3

{destroyed}

2: operation2()

2.1: operation3()

74

© Karl Schwarzbeck


Dynamische Konzepte

Sequenz - Kollaborationsdiagramm

Klassenoperation()

klasse1

Konstruktoroperation()

Objektoperation()

Formale Methoden: UML

:klasse2

:klasse3

Klassenoperation()

75

klasse1

Konstruktoroperation() :klasse2

{new}

Objektoperation()

:klasse3

© Karl Schwarzbeck


Dynamische Konzepte

Zustandsautomat

Ein Zustandsautomat besteht aus Zuständen und Zustandsübergängen

(Transitionen).

Ein Zustand erstreckt sich über eine bestimmte Zeitdauer. In einen Zustand

wird das Objekt durch ein entsprechendes Ereignis gebracht.

Ein Ereignis tritt zu einem (bekannten oder unbekannten) Zeitpunkt auf;

ein Ereignis hat keine Zeitdauer.

Ein Objekt kann - nacheinander - verschiedene Zustände durchlaufen; zu

einem Zeitpunkt befindet es sich immer in genau einem Zustand. Alle

Objekte einer Klasse haben den gleichen Zustandsautomaten.

Tritt ein Ereignis ein, dann hängt der Folgezustand vom aktuellen Zustand

und vom Ereignis ab.

Zur Darstellung des Zustandsautomaten dient das Zustandsdiagramm.

Formale Methoden: UML

76

© Karl Schwarzbeck


Dynamische Konzepte

Zustandsautomat: Parkautomat

bereit

Quittung anfordern

/ drucke Quittung

after (5 sec)

Formale Methoden: UML

Karte

/ einziehen Karte

wartet auf

Quittung

when (Karte fehlerhaft)

/ auswerfen Karte

wartet

auf Geld

Geld eingeworfen [reicht aus]

/ ausgeben Karte

entry/ prüfe Karte

when (Karte korrekt)

/ anzeigen Gesamtbetrag

77

Geld eingeworfen

[reicht nicht]

/ anzeigen Restbetrag

Parkautomat

bezahlen Parkgebühr()

© Karl Schwarzbeck


Dynamische Konzepte

Zustandsautomat: Notation

Zustand1

Zustand4

entry/ Aktion3

exit/ Aktion4

Ereignis4

Anfangszustand

Formale Methoden: UML

Ereignis1/ Aktion1

Ereignis3 [Wächter]

Endzustand

Transition

Zustand2

do/ Aktivität

Zustand3

Ereignis2/ Aktion2

implizites

Ereignis

78

© Karl Schwarzbeck

Weitere Magazine dieses Users
Ähnliche Magazine