close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Einführung Was ist die Unified Modeling Language ? Die Unified

EinbettenHerunterladen
1
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
© Karl Schwarzbeck
2
Einführung
Was ist die objektorientierte Methode ?
Methode
Standardisierte
Notation
Vollständiger
Konzept-Katalog
Planmäßige
Vorgehensweise
Grafik
Basis
Schritte
Text
Statik
Regeln
Dynamik
Beispiele
Formale Methoden: Analyse - Phase
Formale Methoden: Design - Phase
Formale Methoden: UML
konkret
abstrakt
© Karl Schwarzbeck
3
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
© Karl Schwarzbeck
4
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 SoftwareEntwicklung. 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.
Die Kunst des Modellierens ist die Kunst des
Weglassens.
Formale Methoden: UML
© Karl Schwarzbeck
5
Vollständiger Konzept-Katalog
Überblick
Mit der UML steht nicht nur eine standardisierte Modellierungssprache
zur Verfügung, sondern auch in vollständiger Katalog von SoftwareEntwicklungskonzepten.
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
© Karl Schwarzbeck
6
Vollständiger Konzept-Katalog
Statisches Modell
Datenmodellierung
Dynamische Konzepte
Assoziation
Aggregation
Paket
Geschäftsprozess
Botschaft
Szenario
Kollaborationsdiagramm
Zustandsautomat
Basiskonzepte
Formale Methoden: UML
Klasse
Objekt
Attribut
Operation
Vererbung
Polymorphismus
© Karl Schwarzbeck
7
Vollständiger Konzept-Katalog
Statisches Modell
Datenmodellierung
Dynamische Konzepte
Assoziation
Aggregation
Paket
Geschäftsprozess
Botschaft
Szenario
Kollaborationsdiagramm
Zustandsautomat
Basiskonzepte
Formale Methoden: UML
Klasse
Objekt
Attribut
Operation
Vererbung
Polymorphismus
© Karl Schwarzbeck
8
Vollständiger Konzept-Katalog
Statisches Modell
Datenmodellierung
Dynamische Konzepte
Assoziation*
Aggregation
Paket
Geschäftsprozess
Botschaft
Szenario
Kollaborationsdiagramm
Zustandsautomat
Basiskonzepte
Formale Methoden: UML
Klasse*
Objekt*
Attribut*
Operation*
Vererbung
Polymorphismus
© Karl Schwarzbeck
9
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:
•Klasse
•Objekt
•Attribut
•Operation
In der Design- und Implementierungs-Phase können folgende Konzepte
an Bedeutung gewinnen:
•(Mehrfach-) Vererbung
•Polymorphismus
Formale Methoden: UML
© Karl Schwarzbeck
10
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
© Karl Schwarzbeck
11
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
© Karl Schwarzbeck
12
Basiskonzepte
Klasse*
Notation:
Alternativen
klassenname
klassenname
Namensfeld
attribut1
attribut2
...
Attributenliste
attribut1
attribut2
...
Operationsliste
klassenname
operation1()
operation2()
...
operation1()
operation2()
...
klassenname
Formale Methoden: UML
© Karl Schwarzbeck
13
Basiskonzept
Klasse*
Beispiel:
Student
Name
Matrikelnr.
Noten
notiere Noten()
immatrikulieren()
exmatrikulieren()
Bezeichnung:
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.
Formale Methoden: UML
© Karl Schwarzbeck
14
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
© Karl Schwarzbeck
15
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
© Karl Schwarzbeck
16
Basiskonzepte
Objekt*
Beispiel:
:Student
Name = (Marie-José Julier)
Matrikelnr. = 123456
Noten = (Mathe=2, Java=3)
Formale Methoden: UML
© Karl Schwarzbeck
17
Basiskonzepte
Objekt*
Notation:
objektname: klassenname
attribut1 = wert1
attribut2 = wert2
...
Alternativen
:klassenname
attribut1 = wert1
attribut2 = wert2
...
objektname
Operationen werden bei einem
Objekt nie angegeben !
attribut1 = wert1
attribut2 = wert2
...
objektname
:klassenname
Formale Methoden: UML
© Karl Schwarzbeck
18
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
© Karl Schwarzbeck
19
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
:Student
Name = (Alexander, Huber)
Geburtsdatum = 14.2.80
Immatrikulation = 1.9.99
Matrikelnr. = 654321
Das Attribut
Vordiplom hat Noten = (Mathe=2, Prg.Sprache=3) noch - keinen Wert.
Formale Methoden: UML
© Karl Schwarzbeck
20
Basiskonzepte
Attribut*
Notation:
Attributspezifikation
Klasse
attribut: typ = Anfangswert
attribut
{mandatory, key, frozen, Einheit: ..., Beschreibung: ...}
klassenattribut
/abgeleitetes Attribut
Die richtige Entscheidung, welcher Begriff soll die Klasse
bezeichnen, welcher soll Attribut sein, ist oft Voraussetzung für ein
gutes Modell.
Formale Methoden: UML
© Karl Schwarzbeck
21
Basiskonzepte
Attribut*: Klassenattribut
Haben alle Objekte für ein bestimmtes Attribut denselben Wert, liegt ein
Klassenattribut vor.
Student
Beispiel:
Name
Geburtsdatum
Immatrikulation
Matrikelnr.
Vordiplom
Noten
...
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.
Stundenlohn
Bezeichnung: ________________
Formale Methoden: UML
© Karl Schwarzbeck
22
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
© Karl Schwarzbeck
23
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
© Karl Schwarzbeck
Basiskonzepte
24
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
© Karl Schwarzbeck
25
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
3. Anfangswert
4. Muss-Attribut (mandatory)
5. Schlüssel (key)
6. Attributwert nicht änderbar (frozen)
7. Einheit
8. Beschreibung
Formale Methoden: UML
© Karl Schwarzbeck
26
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
© Karl Schwarzbeck
27
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
© Karl Schwarzbeck
28
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
© Karl Schwarzbeck
29
Basiskonzepte
Operation* : Objektoperation
Eine Objektoperation wird stets auf ein einzelnes, bereits existierendes,
Objekt angewendet.
Beispiel: notiere Noten(), exmatrikulieren()
Formale Methoden: UML
© Karl Schwarzbeck
30
Basiskonzepte
Operation*: Konstruktoroperation
Eine Konstruktoroperation erzeugt ein einzelnes Objekt; dabei können
entsprechende Initialisierungen und Datenerfassungen durchgeführt
werden.
Beispiel: immatrikulieren()
Formale Methoden: UML
© Karl Schwarzbeck
31
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
© Karl Schwarzbeck
32
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
© Karl Schwarzbeck
33
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
© Karl Schwarzbeck
34
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
© Karl Schwarzbeck
35
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
:Firma
Huber: Student
:Firma
Der Student Huber wurde noch nicht zum Praktikum bei irgendeiner
Firma angemeldet.
Formale Methoden: UML
© Karl Schwarzbeck
36
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
© Karl Schwarzbeck
37
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()
delete()
setAttribut()
getAttribut()
link()
unlink()
getlink()
Erzeugen eines neuen Objektes
Löschen eines Objektes
Schreiben eines neuen Attributwertes
Lesen eines Attributwertes
Aufbau einer Verbindung zwischen Objekten
Entfernen einer Verbindung zwischen Objekten
Lesen einer Verbindung zwischen Objekten
Formale Methoden: UML
© Karl Schwarzbeck
38
Basiskonzepte
Operation*: Externe Verwaltungsoperationen
Externe Verwaltungsoperationen sind Operationen, die an der
Benutzeroberfläche eingegeben bzw. aufgerufen werden.
Beispiele:
erfassen()
ändern()
löschen()
zeigeListe()
Erzeugen eines neuen Objektes; im Unterschied zur
elementaren Operation new() können noch weitere Aktionen
damit verbunden sein
Ändern eines vorhandenen Objektes
Löschen eines Objektes
Alle Objekte der Klasse am Bildschirm anzeigen
Formale Methoden: UML
© Karl Schwarzbeck
39
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
© Karl Schwarzbeck
40
Basiskonzepte
Vererbung
Vererbung bedeutet, dass eine Unterklasse über die Eigenschaften
(Attribute) und Verhalten (Operationen) einer Oberklasse verfügen kann.
Beispiel:
Angestellter
Student
Stud. Hilfskraft
Personalnr
Name
Adresse
Geburtsdatum
Gehalt
Bank
Matrikelnr
Name
Adresse
Geburtsdatum
Immatrikulation
Matrikelnr
Name
Adresse
Geburtsdatum
Immatrikulation
Beschäftigungen
drucke Adresse()
überweise Gehalt()
drucke Adresse()
drucke Ausweis()
drucke Adresse()
drucke Ausweis()
drucke Arbeitszeiten()
Formale Methoden: UML
© Karl Schwarzbeck
41
Basiskonzepte
Vererbung
Beispiel:
Person
Name
Adresse
Geburtsdatum
drucke Adresse()
Angestellter
Personalnr
Gehalt
Bank
überweise Gehalt()
Student
Matrikelnr
Immatrikulation
drucke Ausweis()
Stud. Hilfskraft
Beschäftigungen
drucke Arbeitszeiten()
Formale Methoden: UML
© Karl Schwarzbeck
42
Basiskonzepte
Vererbung
Oberklasse
attributA
klassenattribut = W
operationA()
Notation:
Unterklasse
attributB
attributC
operationB()
Formale Methoden: UML
© Karl Schwarzbeck
43
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
© Karl Schwarzbeck
44
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.
Grafikelement
Mittelpunkt
istSichtbar
zeichnen()
Kreis
Radius
zeichnen()
Formale Methoden: UML
Rechteck
Länge
Breite
zeichnen()
© Karl Schwarzbeck
45
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
© Karl Schwarzbeck
46
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
© Karl Schwarzbeck
47
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
© Karl Schwarzbeck
48
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 EntityRelationship-Model”.)
Formale Methoden: UML
© Karl Schwarzbeck
Datenmodellierung
49
Aggregation
Bedeutung und Notation sind identisch wie im ERM.
Formale Methoden: UML
© Karl Schwarzbeck
50
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
© Karl Schwarzbeck
51
Datenmodellierung
Paket: Notation
Beispiel:
Ein Warenwirtschaftssystem (WWS) enthält die Pakete Einkauf,
Produktion, Verkauf und Materialwirtschaft.
WWS
Einkauf
Produktion
MaterialWirtschaft
Verkauf
Formale Methoden: UML
© Karl Schwarzbeck
52
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
Paket1
Paket11
Paket111
Klasse
Formale Methoden: UML
© Karl Schwarzbeck
53
Datenmodellierung
Paket: Notation - Abhängigkeit
Vermutete Auswirkungen von Änderungen können folgendermaßen
dargestellt werden:
Paket2
Paket1
Paket3
Dabei sind Paket1 und Paket2 von Paket3 abhängig.
Änderungen in Paket3 können zu Änderungen in den beiden abhängigen
Paketen führen.
Formale Methoden: UML
© Karl Schwarzbeck
54
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
•Geschäftsprozess
•Botschaft
•Szenario
•Zustandsautomat
Zur Darstellung dieser dynamischen Modelle müssen sehr häufig Elemente der Basiskonzepte (Klasse, Operation etc.) mit verwendet werden.
Formale Methoden: UML
© Karl Schwarzbeck
55
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 SoftwareSystem gehört (gehören soll) und was nicht.
Formale Methoden: UML
© Karl Schwarzbeck
56
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 SoftwareSystem ü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
© Karl Schwarzbeck
57
Dynamische Konzepte
Geschäftsprozess: Notation
Warenwirtschafts-SoftwareSystem
Kundensachbearbeiter
Auftrag
bearbeiten
Buchhalter
Lager
verwalten
Lieferantensachbearbeiter
Formale Methoden: UML
Lagersachbearbeiter
© Karl Schwarzbeck
58
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
© Karl Schwarzbeck
59
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
© Karl Schwarzbeck
60
Dynamische Konzepte
Botschaften senden
client ControllingMitarbeiter
berechneDurchschnittsumsatz()
Der Durchschnittsumsatz pro
Versicherten soll für mehrere
Filialen einer Versicherung
berechnet werden.
:Filiale
server
Filiale
Bezeichnung
Leiter
berechneDurchnittsumsatz()
Versicherter
1 * Nummer
Name
Vertrag
1 1..* Nummer
Art
Jahresbeitrag
berechneBeitrag()
Abschlussdatum
getJahresbeitrag()
Formale Methoden: UML
© Karl Schwarzbeck
61
Dynamische Konzepte
Botschaften senden
ControllingMitarbeiter
berechneDurchschnittsumsatz()
:Filiale berechneBeitrag()
client
Filiale
Bezeichnung
Leiter
berechneDurchnittsumsatz()
Der Durchschnittsumsatz pro
Versicherten soll für mehrere
Filialen einer Versicherung
berechnet werden.
:Versicherter
server
Versicherter
1 * Nummer
Name
Vertrag
1 1..* Nummer
Art
Jahresbeitrag
berechneBeitrag()
Abschlussdatum
getJahresbeitrag()
Formale Methoden: UML
© Karl Schwarzbeck
62
Dynamische Konzepte
Botschaften senden
ControllingMitarbeiter
berechneDurchschnittsumsatz()
:Filiale
berechneBeitrag()
Filiale
Bezeichnung
Leiter
berechneDurchnittsumsatz()
Der Durchschnittsumsatz pro
Versicherten soll für mehrere
Filialen einer Versicherung
berechnet werden.
:Versicherter getJahresbeitrag()
client
:Vertrag
server
Versicherter
1 * Nummer
Name
Vertrag
1 1..* Nummer
Art
Jahresbeitrag
berechneBeitrag()
Abschlussdatum
getJahresbeitrag()
Formale Methoden: UML
© Karl Schwarzbeck
63
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
© Karl Schwarzbeck
64
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
© Karl Schwarzbeck
65
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
© Karl Schwarzbeck
66
Dynamische Konzepte
Sequenzdiagramm - Auftrag bearbeiten-1 (Vorversion)
:Artikel
erfassen()
:Kunde
erfassen()
:Auftrag
istLieferbar()
erstelle
Rechnung()
Formale Methoden: UML
© Karl Schwarzbeck
67
Dynamische Konzepte
Sequenzdiagramm - Auftrag bearbeiten-1
:Artikel
erfassen()
:Kunde
erfassen()
:Auftrag
new()
:Auftragsposition
setBestellmenge()
istLieferbar()
[nichtLieferbar]
setBestellmenge()
erstelle
Rechnung()
Formale Methoden: UML
© Karl Schwarzbeck
68
Dynamische Konzepte
Sequenzdiagramm - Auftrag bearbeiten-2/3
:Kunde
:Artikel
abrufen()
[Änderung]
aktualisieren()
erfassen()
:Auftrag
istLieferbar()
erstelle
Rechnung()
Formale Methoden: UML
© Karl Schwarzbeck
69
Dynamische Konzepte
Sequenzdiagramm: Notation
Objekt wird
erzeugt
operation1()
:klasse2
:klasse3
:klasse1
Botschaft
operation2()
ObjektLebenslinie
operation3()
operation4()
Objekt wird
gelöscht
Zeit, in der
eine Operation
aktiviert ist
Zeit
Formale Methoden: UML
© Karl Schwarzbeck
70
Dynamische Konzepte
Sequenzdiagramm: Notation
Objekte
:klasse2
operation1()
:klasse3
:klasse1
operation2()
operation3()
operation4()
Zeit
Formale Methoden: UML
© Karl Schwarzbeck
71
Dynamische Konzepte
Kollaborationsdiagramm
Der Durchschnittsumsatz pro
Versicherten soll für mehrere
Filialen einer Versicherung
berechnet werden.
ControllingMitarbeiter
berechneDurchschnittsumsatz()
:Filiale
berechneBeitrag()
Formale Methoden: UML
:Versicherter getJahresbeitrag()
:Vertrag
© Karl Schwarzbeck
72
Dynamische Konzepte
Kollaborationsdiagramm (Objektdiagramm)
München: Filiale
Meier: Versicherter
Leben
:Vertrag
Berlin: Filiale
Huber: Versicherter
Leben
:Vertrag
Formale Methoden: UML
Hausrat
:Vertrag
Kraus: Versicherter
Hausrat
:Vertrag
© Karl Schwarzbeck
73
Dynamische Konzepte
Kollaborationsdiagramm: Notation
:klasse1
2: operation2()
operation()
1: operation1()
:klasse2
Formale Methoden: UML
2.1: operation3()
:klasse3
© Karl Schwarzbeck
74
Dynamische Konzepte
Kollaborationsdiagramm: Notation
:klasse1
{transient}
operation()
1: operation1()
:klasse2
{new}
Formale Methoden: UML
2: operation2()
2.1: operation3()
:klasse3
{destroyed}
© Karl Schwarzbeck
75
Dynamische Konzepte
Sequenz -
Kollaborationsdiagramm
klasse1
:klasse3
Klassenoperation()
Konstruktoroperation()
Klassenoperation()
:klasse2
Objektoperation()
Formale Methoden: UML
Konstruktoroperation()
Objektoperation()
klasse1
:klasse2
{new}
:klasse3
© Karl Schwarzbeck
76
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
© Karl Schwarzbeck
77
Dynamische Konzepte
Zustandsautomat: Parkautomat
when (Karte fehlerhaft)
/ auswerfen Karte
bereit
Karte
/ einziehen Karte
entry/ prüfe Karte
when (Karte korrekt)
/ anzeigen Gesamtbetrag
wartet
auf Geld
after (5 sec)
Quittung anfordern
/ drucke Quittung
Geld eingeworfen
[reicht nicht]
/ anzeigen Restbetrag
Geld eingeworfen [reicht aus]
/ ausgeben Karte
wartet auf
Quittung
Parkautomat
bezahlen Parkgebühr()
Formale Methoden: UML
© Karl Schwarzbeck
78
Dynamische Konzepte
Zustandsautomat: Notation
Anfangszustand
Zustand2
Zustand1
Ereignis1/ Aktion1
do/ Aktivität
implizites
Ereignis
Transition
Zustand4
entry/ Aktion3
exit/ Aktion4
Ereignis3 [Wächter]
Zustand3
Ereignis4
Ereignis2/ Aktion2
Endzustand
Formale Methoden: UML
© Karl Schwarzbeck
Document
Kategorie
Seele and Geist
Seitenansichten
2
Dateigröße
819 KB
Tags
1/--Seiten
melden