5. UML-Diagramme - Angewandte Informatik

Softwaretechnik (Allgemeine Informatik)
Überblick
1
2
3
4
5
6
7
8
9
Einführung und Überblick
Abstraktion
Objektorientiertes Vorgehensmodell
Methoden der Anforderungs- und Problembereichsanalyse
UML-Diagramme
Objektorientiertes Design
Test
Dokumentation und Wartung
Projektmanagement und -organisation
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
174
Softwaretechnik (Allgemeine Informatik)
Überblick: 5. UML-Diagramme
5.1
Überblick
5.2
5.3
5.4
5.5
5.6
5.7
Klassendiagramme
Fachklassen und Beziehungen identifizieren
Interaktionsdiagramme
Paketdiagramme
Zustandsdiagramme
Aktivitätsdiagramme
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
175
1
5. UML-Diagramme
5.1 Überblick

UML Diagramme

Anwendungsfälle (Use Cases); wurden bereits behandelt
Klassendiagramme (Class Diagrams)
Paketdiagramme (Package Diagrams)
Interaktionsdiagramme (Interaction Diagrams)

Sequenzdiagramme (Sequence Diagrams)

Kommunikationsdiagramme (Communication Diagrams)

vor UML 2.0: Kollaborationsdiagramme (Collaboration Diagrams)
Aktivitätsdiagramme (Activity Diagrams)
Zustandsdiagramme (Statechart Diagrams)
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
176
5. UML-Diagramme
5.1 Überblick

UML Diagramme (fortgesetzt)

Verteilungsdiagramme (Deployment Diagrams)
Komponentendiagramme (Component Diagrams)
Neu in UML 2.0

Interaktionsübersichtsdiagramm

Timing-Diagramme

Verwandt mit Aktivitätsdiagrammen, höhere Abstraktionsebene
Zeitliches Verhalten von Objekten und Systemen
Kompositionsstrukturdiagramme

© Prof. Dr. Björn Dreher
Interna und Zusammenspiel von Systemteilen
Kommunikationswege
Softwaretechnik (Allgemeine Informatik)
177
2
Softwaretechnik (Allgemeine Informatik)
Überblick: 5. UML-Diagramme
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Überblick
Klassendiagramme
Fachklassen und Beziehungen identifizieren
Interaktionsdiagramme
Paketdiagramme
Zustandsdiagramme
Aktivitätsdiagramme
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
178
5. UML-Diagramme
5.2 Klassendiagramme

Klassendiagramme

Erstellung von Klassendiagrammen ist zentrale Technik innerhalb aller
objektorientierten Methoden
Objekte und Klassen

Ein Objekt hat

Eigenschaften,

Verhalten und

eine inhärente Identität.

© Prof. Dr. Björn Dreher
Nicht nur infolge bestimmter Eigenschaften (wie bei einem RDBMS)
Softwaretechnik (Allgemeine Informatik)
179
3
5. UML-Diagramme
5.2 Klassendiagramme

Objekte und Klassen (fortgesetzt)

Zusammenfassen verschiedener Objekte mit gemeinsamen
Eigenschaften und Verhalten zu Klassen.

Eine Klasse hat über ihre Eigenschaften hinweg eine bestimmte
Semantik:

Scheune - Pferd Beispiel:

Beide haben einen Wert und ein Alter, sind jedoch verschiedene
Klassen.

Unter rein finanziellen Gesichtspunkten könnten sie jedoch auch
zu einer Klasse gehören!
Jedes Objekt „kennt“ seine Klasse!

In den meisten OO-Sprachen kann das zur Laufzeit festgestellt
werden
© Prof. Dr. Björn Dreher
180
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Graphische Darstellung

Class oder Object Diagrams

Hauptsächlich Class Diagrams

Object Diagrams für Szenarien (Interaction Diagrams)

Für ein Class Diagram gibt es unendlich viele Object Diagrams
Person
Class
© Prof. Dr. Björn Dreher
Joe Smith: Person
Mary Sharp
:Person
Objects
Softwaretechnik (Allgemeine Informatik)
181
4
5. UML-Diagramme
5.2 Klassendiagramme

Attribute

Datenwerte von Objekten einer Klasse
Für jede Objektinstanz gibt es einen Wert für jedes Attribut
Verschiedene Instanzen können dieselben Attributwerte haben
Jeder Attributname ist in der Klasse eindeutig
Attributwerte haben keine Identität wie ein Objekt

Unterschied String „Kanada“ als Attributwert im Gegensatz zu dem
Land Kanada als Objekt der Klasse Land mit dem Attributwert
„Kanada“ für das Attribut Name.

Die Hauptstadt von Kanada ist ein Objekt der Klasse Stadt und
sollte nicht als Attribut der Klasse Land modelliert werden,

sondern als Assoziation zwischen einer Land-Klasse und einer StadtKlasse

(jedoch abhängig vom Kontext)
Der Name der Stadt ist dann (der String) „Ottawa“
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
182
5. UML-Diagramme
5.2 Klassendiagramme

Attribute: Darstellung
Person
name: String
age: int
Class m it
Attributen

Joe Smith: Person
name = Joe Smith
age = 24
Mary Sharp: Person
name = Mary Sharp
age = 52
Objects mit Werten
Separate, eindeutige Bezeichnerwerte für Objektinstanzen in Form von
künstlichen Attributen (surrogate keys) sind (im Gegensatz zu z.B.
Datenbankmodellierungen) nicht nötig
Jede Objektinstanz hat grundsätzlich eine eigene Identität!
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
183
5
5. UML-Diagramme
5.2 Klassendiagramme

Attribute: Spezifikation

Volle Spezifikation für Attribute:
Sichtbarkeit Name: Typ = Defaultwert {Constraint}
Klassenname

+ attr1: Typ1 = Initialwert1 {Einschr1}
Sichtbarkeiten:
- attr2: Typ2 = Initialwert2 {Einschr2}
...

Public
+
Protected
#
Private
Package
~
Constraints (Einschränkungen, auch Eigenschaftswert):

{changeable} Voreinstellung
{readOnly}
const Attribut (UML 1.n: {frozen} )
{ordered}
geordnete Reihenfolge, ohne Duplikate
{seq}
geordnete Reihenfolge, Duplikate erlaubt
{bag}
ungeordnet, Duplikate erlaubt
...
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
184
5. UML-Diagramme
5.2 Klassendiagramme

Operationen und Methoden

Eine Operation ist eine Funktion oder Transformation, die von dem
Objekt einer Klasse (auf sich selbst, ggf. auf Initiative eines anderen
Objektes) angewandt wird
Z.B. öffne, schliesse, verberge, zeige als Operationen der Klasse
Window
Alle Objekte einer Klasse verwenden dieselben Operationen
Jede aktuelle Operation gehört implizit zu einem Zielobjekt

Das genaue Verhalten der Operation hängt von der Klasse des
Zielobjekts ab

Ein Objekt „kennt“ seine Klasse und somit die richtige
Implementierung der Operation
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
185
6
5. UML-Diagramme
5.2 Klassendiagramme

Operationen und Methoden (fortgesetzt)

Dieselbe Operation kann auf unterschiedliche Klassen einer
Vererbungshierarchie anwendbar sein (polymorphe Operation)

Verschiedene Formen der Operation, abhängig von der
Klassenzugehörigkeit des Zielobjekts
Eine Methode ist die Implementierung einer Operation für eine
bestimmte Klasse

Beispiel: Generische Operation print der (übergeordneten) Klasse
File. Unterschiedliche Implementierungen (Methoden) für ASCII-,
binäre oder Bitmap-Files
Zusätzlich zu dem impliziten Zielobjekt kann eine Operation weitere
Argumente erhalten

Dadurch wird die Operation parametrisiert,

die Wahl der Methode wird dadurch jedoch nicht beeinflusst

Diese hängt allein von der Klassenzugehörigkeit des Zielobjekts ab
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
186
5. UML-Diagramme
5.2 Klassendiagramme

Operationen und Methoden (fortgesetzt)

Hat eine Operation Methoden für mehrere Klassen,

so müssen diese Methoden alle dieselbe Signatur (Anzahl und
Typen der Parameter und evtl. des Ergebnisses) besitzen

Z.B. dürfte die oben erwähnte Operation print nicht für eine
Methode den File-Name und für eine andere eine File-Handle als
Parameter haben
Das Verhalten der unterschiedlichen Methoden einer Operation sollte
eine konsistente semantische Bedeutung haben

Nicht:

© Prof. Dr. Björn Dreher
Operation invert für Matrixinversion einerseits und Auf-den-Kopfstellen
einer graphischen Figur andererseits
Softwaretechnik (Allgemeine Informatik)
187
7
5. UML-Diagramme
5.2 Klassendiagramme

Operationen und Methoden

Darstellung im unteren Drittel einer Class-Box:
Person
name: String
age: int
changeJob()
changeAddress()

File
fileName: String
size: int
lastUpdate: Date
print()
Geometric Object
color: word
position: Coordinates
move (delta: Vector)
select (p: Point): boolean
rotate (Angle)
Triviale Methoden (get- und set-Methoden für Attribute) werden
üblicherweise nicht dargestellt
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
188
5. UML-Diagramme
5.2 Klassendiagramme

Operationen und Methoden: Spezifikation

Volle Spezifikation für Operationen:
Sichtbarkeit Name (Parameterliste) : Rückgabetyp { Constraint }
Klassenname
+ attr1: Typ1 = Initialwert1 {Einschr1}
- attr2: Typ2 = Initialwert2 {Einschr2}
...
+ oper1 (parmliste1): resultattyp1
{EinschrO1}
# oper2 (parmliste2): resultattyp2
{EinschrO2}

Jeder Parameter in der Parameterliste hat die folgende Struktur:

Richtung Name : Typ = Defaultwert

in
out
inout
return (UML 2.0)
Softwaretechnik (Allgemeine Informatik)
189
8
5. UML-Diagramme
5.2 Klassendiagramme

Operationen und Methoden: Spezifikation (fortgesetzt)

Vordefinierte Constraints (Einschränkungen) (UML 2.0 nicht mehr):

{isQuery}
Zustand des Objektes bleibt unverändert
{sequential} Nutzer müssen sicherstellen, dass ein Objekt über
diese Operation nur einmal zu einer Zeit
angesprochen wird
{guarded}
Alle Aufrufe werden serialisiert
{concurrent} Operation wird als atomar angesehen (synchronized
in Java)
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
190
5. UML-Diagramme
5.2 Klassendiagramme

Operationen und Methoden: Spezifikation (fortgesetzt)

Einschränkungen

Können auch sonstige Texte sein
Lange Listen von Operationen können durch Stereotypen klassifiziert
werden (eher ungewöhnlich in UML 2.0!):

«constructor»
«process»
«query»
«modifier»
«helper»
Unterscheidung von Operationen, die Attribute ändern, und solche, die
nur Werte aufgrund der Attribute zurückgeben
Query Operationen, s.o.: Zusicherungen
Queries ohne Argumente können als derived attributes angesehen
werden
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
191
9
5. UML-Diagramme
5.2 Klassendiagramme

Beziehungen zwischen Klassen

Zwei Arten statischer Beziehungen zwischen Klassen:

Assoziationen

Untertypen (Generalisierung/Spezialisierung)
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
192
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationen

Repräsentieren Beziehungen (relationships) zwischen Instanzen von
Klassen

Joe Smith arbeitet-für Simplex Company

Die Simplex Company hat eine Anzahl von Büros
Assoziationen sind grundsätzlich bidirektional

Der Name (meist ein Verb) impliziert die Vorwärts-Richtung

Kann ein kleines ausgefülltes Dreieck zur Anzeige der Richtung
enthalten

Umgekehrt: Invers-Richtung.
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
193
10
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationen (fortgesetzt)

Implementierung oft als Referenz (Pointer) von einem Objekt zu einem
anderen

Referenz vs. Pointer abhängig von Programmiersprache

Bei der Implementierung hat man dann ein Referenz (Pointer)Attribut (oder eine Menge von Referenzen (Zeigern));

wird aber zum jetzigen Zeitpunkt nicht modelliert!
© Prof. Dr. Björn Dreher
194
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationen

Graphische Darstellung
hat-Hauptstadt
Land
name: String
Kanada:Land
Frankreich:Land
Deutschland:Land

Stadt
name: String
hat-Hauptstadt
hat-Hauptstadt
hat-Hauptstadt
Class
Diagramm
Ottawa:Stadt
Paris:Stadt
Object
Diagramm
Berlin:Stadt
Assoziationsnamen werden ab UML 2.0 nicht mehr kursiv geschrieben!
Wenn möglich sollte man die Klassen von links nach rechts anordnen
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
195
11
5. UML-Diagramme
5.2 Klassendiagramme

Multiplizitäten

Multiplizität spezifiziert,

wie viele Instanzen der einen Klasse eine Beziehung zu einer
Instanz der anderen Klasse haben können
Multiplizitäten sind oft nur 1 oder viele, können aber auch genauer
spezifiziert werden (UML 2.0: muss immer genau ein Intervall sein)
Klasse
genau ein
Klasse
viele (0 oder mehr)
Klasse
optional (0 oder 1)
Klasse
1 oder mehr
Klasse
numerisch spezifiziert
*
0..1
1..*
4
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
196
5. UML-Diagramme
5.2 Klassendiagramme

Multiplizitäten

Oft kennt man zu Beginn der Analyse die Multiplizitäten noch nicht
genau
Dann sollte man sich darüber zunächst nicht zu viele Gedanken
machen
Zuerst spezifiziert man Objekte, Klassen und Assoziationen,

erst dann entscheidet man über Multiplizitäten
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
197
12
5. UML-Diagramme
5.2 Klassendiagramme

Multiplizitäten: Beispiel

Gegeben sei eine Linie; finde alle Schnittpunkte mit anderen Linien
Oder:
Gegeben ein Schnittpunkt; finde alle Linien, die sich darin schneiden
Jeder Punkt ist Schnittpunkt von mindestens zwei Linien
Jede Linie hat Null, einen oder mehrere Schnittpunkte
© Prof. Dr. Björn Dreher
Linie
5. UML-Diagramme
name: String
5.2 Klassendiagramme

Multiplizitäten:
Beispiel
198
Softwaretechnik (Allgemeine Informatik)
schneidet-in
Class
Diagramm
Punkt
0..*
2..*
name: String
l1:Linie
l2:Linie
p1:Punkt
Object
Diagramm
l3:Linie
p2:Punkt
l4:Linie
l5:Linie
l2
p2
l3
BeispielDaten
p1
l4
l5
l1
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
199
13
5. UML-Diagramme
5.2 Klassendiagramme

Rolle

Welche Rolle spielt die Instanz dieser Klasse für eine Instanz der
Klasse an der anderen Seite der Assoziation?
Entweder besonderer Bezeichner bei der Klasse, die für die Klasse der
anderen Seite diese Rolle spielt
Ohne besonderen Bezeichner: Name der Klasse ist auch
Rollenbezeichner
Eine Rolle besitzt eine Multiplizität:

Wie viele Objekte sind an der Beziehung beteiligt?

„*“ bedeutet 0 bis viele
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
200
5. UML-Diagramme
5.2 Klassendiagramme

Rolle

Zwei Rollen für binäre Assoziationen.

Erleichtert das Navigieren von einer Klasse zur anderen ohne
explizit den Namen der Assoziation zu nennen
Beispiel:
Angestellter
Person
© Prof. Dr. Björn Dreher
*
Arbeitgeber
arbeitet-für
*
Unternehmen
Softwaretechnik (Allgemeine Informatik)
201
14
5. UML-Diagramme
5.2 Klassendiagramme

Rolle

Rollennamen am entgegengesetzten Ende von Assoziationen einer
Klasse müssen eindeutig sein
Rollennamen sind unbedingt notwendig, wenn mehr als eine
Assoziation zwischen zwei Klassen oder wenn eine Link (Instanz einer
Assoziation) zwischen Objekten derselben Klasse besteht:
Owner
*
User
Behältnis
Directory
*
* authorisierter User
0..1
*
Inhalt

Assoziationen werden meist durch ein Verb benannt
Für die Rollenbezeichnung verwendet man Substantive
© Prof. Dr. Björn Dreher
202
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Beispiel
Auftrag
empfangsDatum
istVorausBezahlt
anzahl: String
preis: Geld
ausführen()
abschliessen()
1
Positionen
Kunde
*
gibt
1
{ wenn Auftrag.kunde.
kreditWürdigkeit() ==
"gering" dann muß
Auftrag.istVorausBezahlt
true sein }
name
adresse
kreditWürdigkeit(): String
*
Auftragsposition
menge: Integer
preis: Geld
istGeliefert:
Boolean
*
Firmenkunde
kreditkartenNr
erinnern()
forderungenImMonat(Integer)
kreditWürdigkeit(): String
*
1
Produkt
© Prof. Dr. Björn Dreher
Privatkunde
unternehmensName
kreditWürdigkeit
kreditLimit
Verkäufer
0..1
{ kreditWürdigkeit() ==
"gering" }
Angestellter
Softwaretechnik (Allgemeine Informatik)
203
15
5. UML-Diagramme
5.2 Klassendiagramme

Navigieren über Assoziationen

Assoziationen implizieren Attribute, über die zu dem anderen Objekt
navigiert werden kann
Aus den Beziehungen können öffentliche Methoden abgeleitet werden,
die den Zugriff auf die verbundenen Klasse ermöglichen
class Auftrag {
public:
Kunde* getKunde();
Vector getAuftragsPositionen();
...
}

Bei mehrwertigen Beziehungen sind Container und Iteratoren
einzusetzen
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
204
5. UML-Diagramme
5.2 Klassendiagramme

Navigieren über Assoziationen (fortgesetzt)

Realisierung durch Referenz-Attribute bzw. Container von Referenzen
class Auftrag {
private:
Kunde* kunde;
Vector auftragsPositionen;
...
}
class Kunde {
private:
Vector auftraege;
...
}

Durch zusätzliche Pfeile kann die Navigierbarkeit angezeigt werden
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
205
16
5. UML-Diagramme
5.2 Klassendiagramme

Navigierbarkeit
Auftrag
Kunde
empfangsDatum
istVorausBezahlt
anzahl: String
preis: Geld
*
1
{ wenn Auftrag.kunde.
kreditWürdigkeit() ==
"gering" dann muß
Auftrag.istVorausBezahlt
true sein }
ausführen()
abschliessen()
1
Positionen
name
adresse
kreditWürdigkeit(): String
*
Auftragsposition
Firmenkunde
menge: Integer
preis: Geld
istGeliefert:
Boolean
*
Privatkunde
unternehmensName
kreditWürdigkeit
kreditLimit
kreditkartenNr
erinnern()
forderungenImMonat(Integer)
kreditWürdigkeit(): String
*
1
0..1
Verkäufer
Produkt
{ kreditWürdigkeit() ==
"gering" }
Angestellter
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
206
5. UML-Diagramme
5.2 Klassendiagramme

Regeln für Einschränkungen (Engl.: constraints)

Funktionale Beziehung zwischen Objekt-Instanzen. Schränkt z.B.
Attributwerte ein.
Beispiele

Kein Mitarbeiter darf mehr verdienen als sein Vorgesetzter
(Constraint zwischen zwei Objekten zur selben Zeit)
Ein Fenster hat ein Seitenverhältnis zwischen 0.8 und 1.5
(Constraint zwischen Eigenschaften desselben Objektes)
Die Priorität eines Jobs darf nicht zunehmen
(Zeitliches Constraint für dasselbe Objekt)
Employee
salary
0..1
boss
Job
priority
Window
length
width
1..*
{salary <= boss.salary}

{0.8<=length/width<=1.5}
{priority never increases}
Formulierung üblicherweise deklarativ

Später Umsetzung in prozedurale Form mittels Programmiersprache
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
207
17
5. UML-Diagramme
5.2 Klassendiagramme

Regeln für Einschränkungen (fortgesetzt)

Mengen-Eigenschaften:
is Member of
0..*
Person
0..*
{subset}
0..*
Committee
is Chair of

Strikte Syntax der Darstellung in UML: Immer eingebettet zwischen
geschweifte Klammern: { ... }
Corporation
Bank Account
{ or }
UML's Object
Constraint Language
(OCL)
Person
gender : {female, male}
0..1
wife
0..1
husband
{ self.wife.gender = female and
self.husband.gender = male }
© Prof. Dr. Björn Dreher
208
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Einschränkungsregel zum Sortieren

Normalerweise besteht für die Objekte an der „viele“-Seite keine
besondere Ordnung
In Einzelfällen kann eine solche Menge ein ordered set sein, also
sortiert
Dies ist dann eine inhärente Eigenschaft der Assoziation
Kann als Spezialfall eines constraint modelliert werden:
{ordered}
Fenster
© Prof. Dr. Björn Dreher
*
ist sichtbar-auf
Softwaretechnik (Allgemeine Informatik)
Bildschirm
209
18
5. UML-Diagramme
5.2 Klassendiagramme

Stereotypen

Weitere Klassifizierung von Klassen

Z.B. Entity-, Control-, Boundary-Klassen bei Ivar Jacobson (hier
jedoch eigene graphische Darstellung) oder

im MVC-Konzept

Bedeutet auch eine bestimmte Verantwortlichkeitskategorie

Dient auch als allgemeiner Erweiterungsmechanismus der UML

Üblicherweise zwischen « ... » dargestellt ( «Entity» )
© Prof. Dr. Björn Dreher
210
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Mehrfache Assoziationen

Bisher: Binäre Assoziationen
Es gibt auch dreifache (ternäre, ternary) Assoziationen

Sind atomare Einheiten und
können nicht in binäre Assoziationen aufgelöst werden, ohne dass
Information verloren geht:
Projekt
Sprache
Class
Diagramm
Person
abrechnung
:Projekt
cobol:Sprache
Object
Diagramm
mary:Person
cAD_Programm
:Projekt
© Prof. Dr. Björn Dreher
c++:Sprache
Softwaretechnik (Allgemeine Informatik)
211
19
5. UML-Diagramme
5.2 Klassendiagramme

Mehrfache Assoziationen (fortgesetzt)

Auch mehr als dreifache Assoziationen werden durch das
Rautensymbol gekennzeichnet
Auch solche Assoziationen können einen Namen haben
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
212
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation

„Teil-Ganzes“- oder „Teil-von“-Beziehungen
Besondere Form der Assoziation:

Objekt (Ganzes) besteht aus Komponenten (Teilen)

Komponenten sind Teile von dem Ganzen (Aggregat)
Beispiele:

Teileplan eines Werkstückes

Programmkopf, Deklarationsteil und Programmrumpf als Teile
eines Programms.
Aggregation ist eine Art von Assoziation mit zusätzlicher Semantik.
Wichtige Eigenschaft: Transitivität: Wenn A Teil von B ist und B Teil
von C, dann ist A auch Teil von C
Andererseits ist eine Aggregation antisymmetrisch: Wenn A Teil von B
ist, so ist B nicht Teil von A
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
213
20
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation

Nicht immer ist die Wahl einer Aggregation angezeigt

Zur Konkurrenz steht immer die normale Assoziation

Nur wenn bestimmte Eigenschaften an einem „Ganzen“
festgemacht werden können, lohnt es sich

Diese Eigenschaften propagieren dann zu den Komponenten

Auto, Tür, Schloss: Bewegung
Serialisierung
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
214
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation

Einfaches Beispiel:
Dokument
0..*
Absatz
0..*
Satz
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
215
21
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation

Etwas komplizierter:
PC
0..1
Monitor
Systembox
Mainboard
Maus
Tastatur
Netzteil
1..*
CPU
© Prof. Dr. Björn Dreher
RAM
Softwaretechnik (Allgemeine Informatik)
216
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation

Oft wird ein Aggregat semantisch als Ganzes Operationen unterworfen,
obwohl es physisch aus mehreren untergeordneten Objekten besteht
Teile müssen nicht existieren
Die Aggregation ist inhärent transitiv

Ein Aggregat hat Teile und diese können wieder Teile haben

Viele Aggregat Operationen werden auch auf direkte und indirekte
Teile des Aggregats angewandt
Rekursive Aggregation ist erlaubt
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
217
22
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation vs. Assoziation

Unterschied zwischen Assoziation und Aggregation wird von
verschiedenen Autoren nicht einheitlich definiert
Ist die Assoziation zwischen Firma und ihren Angestellten eine
Aggregation?

Peter Coad: ja

Jim Rumbaugh: nein
Aggregation fügt einer Assoziation eine bestimmte Semantik hinzu
Sie ist Spezialfall der Assoziation, keine unabhängige Eigenschaft

Haben zwei Objekte eine enge Teil-Ganzes Beziehung:
Aggregation
Sind sie eher unabhängig voneinander (bis auf die Beziehung):
Assoziation.
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
218
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation vs. Assoziation

Tests für Aggregation:

Würde man den Begriff „Teil-von“ verwenden?

Sind einige Operationen auf das Ganze auch automatisch auch
auf Teile anzuwenden?

Werden einige Attributwerte automatisch an Teile weitergegeben?

Ist in der Assoziation eine Asymmetrie, dass ein Teil dem anderen
untergeordnet ist?
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
219
23
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation vs. Assoziation
Unternehmen
1..*
Untern.bereich
1..*
Abteilung
arbeitet-für
1..*
Mitarbeiter

Unternehmen bestehen aus Unternehmensbereichen und diese aus
Abteilungen
Auch Unternehmen bestehen indirekt aus Abteilungen
Ein Unternehmen ist keine Aggregation von Mitarbeitern

Beide sind weitgehend unabhängige Objekte
Wahl jedoch oft nicht eindeutig

Auch abhängig von späteren Anwendungslogik (Sicht des Ganzen)

Typisch für Modellierung: Es gibt nur wenige feste Regeln
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
220
5. UML-Diagramme
5.2 Klassendiagramme

Aggregat Typen

Es gibt

Feste Aggregate: feste Struktur bzgl. Anzahl, Typen und Ebenen
der Teile (s. Rechner, weiter unten Lampe)

Variable Aggregate: feste Anzahl von Ebenen, aber Anzahl der
Teile kann variieren (s. Unternehmen)

Rekursive Aggregate: Enthält, direkt oder indirekt, eine Instanz
desselben Aggregats
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
221
24
5. UML-Diagramme
5.2 Klassendiagramme

Programm
Rekursive Aggregate
1..*
1..*
Block
Compound
Statement

Simple
Statement
Block ist hier eine abstrakte Superklasse.
Diese hat zwei Subklassen.

Simple Statement ist der terminale Knoten des Aggregats.

Compound Statement ist nur ein Zwischenknoten und besteht
selbst wieder aus „Instanzen“ der abstrakten Superklasse
(genauer: entweder der einen oder der anderen Subklasse)
Anzahl der möglichen Ebenen von rekursiven Aggregaten ist prinzipiell
unbeschränkt
© Prof. Dr. Björn Dreher
222
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Rekursive Aggregate

Anwendung des Composite Design Patterns:
Component
1..*
Client
children
operation()
add(Component)
remove(Component)
getChild(int): Component
Leaf
Composite
children
operation()

operation()
add(Component)
remove(Component)
getChild(int): Component
forall g in children
g.operation();
Achtung: Hier Composition anstelle Aggregation! (s.später)
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
223
25
5. UML-Diagramme
5.2 Klassendiagramme

Weiterverbreitung von Operationen

Engl.: Propagation, Triggering.
Automatische Anwendung einer Operation auf ein Netzwerk von
Objekten, wenn die Operation bei einem Startobjekt angewandt wird
Z.B.:

Bewegen eines Aggregats bewegt auch dessen Teile

Serialize der Modell-Klasse (MVC) als Aggregat ruft auch die
Serialize-Methoden aller Teile auf

Entsprechend auch bei Java
paint() eines JPanel ruft paint() Methoden aller eingefügten
Komponenten auf (Java)
© Prof. Dr. Björn Dreher
224
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Weiterverbreitung von Operationen

Beispiel
Person
1..*
Dokument
copy

copy
copy
besitzt
1..*
Absatz
copy
1..*
Zeichen
copy
Die copy Operation wird von links nach rechts weiterverbreitet
Wird ein Dokument kopiert, so betrifft das auch alle Absätze und das
wiederum betrifft alle Zeichen darin
Dies gilt jedoch nicht in der umgekehrten Richtung
Ein Absatz kann kopiert werden, ohne das ganze Dokument zu
kopieren
Die Kopie eines Dokumentes kopiert auch nicht die Person mit. Es wird
jedoch eine neue Link zwischen der Person und der Kopie aufgebaut
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
225
26
5. UML-Diagramme
5.2 Klassendiagramme

Weiterverbreitung von Operationen (fortgesetzt)

Konzept der Propagation ist äußerst mächtig
Man kann das Verhalten eines ganzen Netzes von Objekten
spezifizieren
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
226
5. UML-Diagramme
5.2 Klassendiagramme

Komposition

Aggregation ist eine konzeptionelle Ganzes-Teil Beziehung ohne
konkrete Auswirkungen auf die Existenzabhängigkeiten zwischen den
beteiligten Klassen
Bei der Komposition ist das anders. Hier kommt zusätzliche Semantik
ins Spiel

Das Ganze ist Eigentümer seiner Teile

Soweit Teile flexible Multiplizitäten haben, können sie zwar dem
Ganzen hinzugefügt und wieder entnommen werden,

sie leben und sterben jedoch mit dem Ganzen zusammen
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
227
27
5. UML-Diagramme
5.2 Klassendiagramme

Komposition

Ein Teil einer Komposition kann immer nur Teil eines Ganzen sein

Im Rahmen einer Kompositionsbeziehung
Bei einer normalen Aggregation kann ein Teil Bestandteil mehrerer
Aggregate sein

z.B. kann am Aggregat-Ende eine Muliplizität größer 1 stehen
Ein Teil einer Komposition kann aber gleichzeitig Teil einer oder
mehrerer (nicht existenzabhängiger) Aggregationen sein!
Bei der Komposition muss das Ganze auch die Erzeugung und
Vernichtung seiner Teile verantwortlich übernehmen
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
228
5. UML-Diagramme
5.2 Klassendiagramme

Komposition

Beispiel für eine Komposition:
Window
1
*
Frame

Die Teile einer Komposition ähneln Attributen

Sie sind feste Bestandteile der Ganzes-Klasse
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
229
28
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationsklassen

Anfügen von Attributen und Operationen an Assoziationen

Attribut: Normalerweise individuelle Eigenschaft eines Objektes
einer Klasse.

Es gibt Fälle, in denen man eine Eigenschaft nicht nur einer der
beiden verbundenen Klassen zuordnen kann

Typisch für viele-zu-viele Beziehungen

Name der Assoziation = Name der Assoziationsklasse
zugreifbar_durch
File
User
0..*
0..*
Zugreifbar_durch
Attribut der Assoziation
zugreifbar durch
zugriffsrecht
/etc/termcap
/etc/termcap
/usr/anne/.login
© Prof. Dr. Björn Dreher
(read)
(read, write)
(read, write)
Hans Müller
Fritz Klein
Anne Meyer
230
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationsklassen

Beispiel für viele-zu-eins Assoziation:
arbeitet_für
Person
Unternehmen
0..*
Vorgesetzter
0..1
name
pers_nr
adresse
0..*
bewertet
Angestellter
name
adresse
Arbeitet_für
gehalt
stellung
zeitraum
Bewertet
bewertung
Doch eher viele-zu-viele?
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
231
29
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationsklassen

Attribut einer ternären Assoziation:
Verein
Spieler
Jahr
Ergebnis
gewonnene Spiele
verlorene Spiele
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
232
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationsklassen

Bei eins-zu-viele Assoziationen kann man prinzipiell die Attribute der
„viele“-Klasse zuordnen
Damit vergibt man aber die Möglichkeit, später die Multiplizität ohne
weiteres ändern zu können:
arbeitet_für
Person
Unternehmen
*
name
pers_nr
adresse
Arbeitet_für
gehalt
stellung
name
adresse
Bevorzugte
Form
arbeitet_für
Person
Unternehmen
*
name
pers_nr
adresse
gehalt
stellung
© Prof. Dr. Björn Dreher
name
adresse
Nicht
empfohlenene
Form
Softwaretechnik (Allgemeine Informatik)
233
30
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationsklassen

Der Name der Assoziation entspricht dann dem der Klasse
Unser Beispiel mit zusätzlichen Attributen:
arbeitgeber
Person
*
1..*
Unternehmen
Arbeitet_für
stellung
einstellDatum
zeitraum
gehalt

Zusätzliche Einschränkung für Assoziationsklassen:

Es kann nur eine Instanz der Assoziationsklasse zwischen zwei
teilnehmenden Objekten bestehen

Nach obigem Diagramm dürfte eine Person nicht aus der Firma
ausscheiden und später noch einmal eingestellt werden
© Prof. Dr. Björn Dreher
234
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationsklassen

Umsetzung einer Assoziationsklasse bei der Implementierung
Um die o.g. spezielle Semantik beizubehalten, bedarf es spezieller
Assoziationszusicherungen:
arbeitgeber
Person
*
1..*
Unternehmen
Arbeitet_für
stellung
einstellDatum
zeitraum
gehalt
Arbeitet_für
Person
1
1..*
stellung
einstellDatum
zeitraum
gehalt
*
1
Unternehmen
{ Jede Person-Unternehmen
Kombination nur einmal }
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
235
31
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationsklassen

Implementierung der Assoziationsklasse als reguläre Klasse
Ohne spezielle Assoziationsklassen-Semantik:
Arbeitet_für
Person
1
1..*
stellung
einstellDatum
zeitraum
gehalt
*
1
Unternehmen
{ disjunkte Zeiträume der
Anstellungsverhältnisse }
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
236
5. UML-Diagramme
5.2 Klassendiagramme

Assoziationsklassen

Einleuchtendes Beispiel für korrekte Verwendung der
Assoziationsklassen-Semantik
Mitarbeiter
*
*
Fähigkeit
Hat_Kompetenzgrad
stufe

Jeder Mitarbeiter hat für jede Fähigkeit nur einen Kompetenzgrad
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
237
32
5. UML-Diagramme
5.2 Klassendiagramme

Qualifizierte Assoziationen

Verbindet zwei Klassen und einen qualifier.
Der qualifier ist ein spezielles Attribut, welches die effektive Multiplizität
der Assoziation reduziert
Qualifizierung kann für eins-zu-viele und viele-zu-viele Assoziationen
angewandt werden
Der qualifier unterscheidet an dem „viele“-Ende unter der Menge von
Objekten
*
Directory
Directory
file name
© Prof. Dr. Björn Dreher
File
File
Softwaretechnik (Allgemeine Informatik)
238
5. UML-Diagramme
5.2 Klassendiagramme

Qualifizierte Assoziationen: Beispiel

Ein Directory enthält viele Files,
ein File gehört zu genau einem Directory
Innerhalb des Directory unterscheidet aber das Attribut file name genau
unter den vielen Files des Directory
Ein Directory plus ein file name bestimmt eindeutig einen File
*
Directory
Directory

file name
File
File
UML-Äquivalent des Programmierkonzeptes

Assoziatives Feld (associative array),

Abbildung (map) und

Dictionary.
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
239
33
5. UML-Diagramme
5.2 Klassendiagramme

Qualifizierte Assoziationen

Nicht immer wird die Multiplizität auf eins reduziert:
Fachbereich
Amt
Gremium
FB Mitglied
*
Dekan
Prüfungsausschuß
Prüfungsausschuß
Prüfungsausschuß
Prüfungsausschuß
Studienausschuß
Studienausschuß
Studienausschuß
Schulz
Richter
Linn
Dreher
Schulz
Kröger
Schulz
Richter
FB I
FB I
FB I
FB I
FB I
FB I
FB I
FB I
© Prof. Dr. Björn Dreher
Gr.-Mitglied
*
240
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Abgeleitete Assoziationen

Derived Association
Assoziation die nicht ständig besteht, sondern aus anderen
Assoziationen berechnet werden kann:
Kunde
1
hat
1
abgeleitet
/für
Rechnung
*
basiert auf
*
1
Vertrag
{ Rechnung.Kunde = Rechnung.Vertrag.Kunde }
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
241
34
5. UML-Diagramme
5.2 Klassendiagramme

Abhängigkeit

Engl.: dependency
Abhängigkeit von einer anderen Klasse
Diese kommt z.B. als Typ in der Parameterversorgung einer Methode
vor
Bedeutet, dass eine Änderung in der Spezifikation einer Klasse (Event)
Auswirkungen auf eine andere Klasse (Window) hat, die die erste
Klasse verwendet
Impliziert keine Assoziation!
Window
open()
close()
move()
display()
handleEvent(ev: Event)
© Prof. Dr. Björn Dreher
Event
Softwaretechnik (Allgemeine Informatik)
242
5. UML-Diagramme
5.2 Klassendiagramme

Generalisierung und Vererbung

Generelle Konzepte

Leistungsstarke Abstraktionen, um Ähnlichkeiten zwischen
Klassen zu nutzen ohne auf Unterschiede verzichten zu müssen
Beispiel

Jedes Gerät besitzt einen Hersteller, ein Gewicht und einen Preis

Jede Pumpe hat zusätzlich eine Pumpdruck und eine
Durchflussmenge

Drucktanks haben zusätzlich ein Volumen und einen Druck
Grundlegende Geräteeigenschaften sollen nur einmal definiert werden
Weitere Details für Pumpen, Drucktanks oder andere Geräte werden
dann hinzugefügt
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
243
35
5. UML-Diagramme
5.2 Klassendiagramme

Gerät
Generalisierung und Vererbung

Generalisierungsmenge
name
hersteller
gewicht
preis
Beispiel:
Gerätetyp
{incomplete, disjoint}
Partitionen
Pumpe
Wärmetauscher
saugleistung
pumpdruck
durchflussmenge
oberflaeche
rohrdurchmesser
rohrlaenge
innendruck
aussendruck
•••
Drucktank
volumen
druck
Pumpentyp {incomplete, disjoint}

Zentrifugalpumpe
Generalisierungseigenschaften:

complete

incomplete

disjoint

overlapping
© Prof. Dr. Björn Dreher
durchmesser
schaufelanzahl
rotationsachse
Membranpumpe
membranmaterial
Kolbenpumpe
•••
kolbenhoehe
kolbendurchm
zylinderanzahl
Drucktanktyp
•••
Kugeltank
durchmesser
Zylindertank
durchmesser
hoehe
Schwimmdachtank
durchmesser
hoehe
Softwaretechnik (Allgemeine Informatik)
244
5. UML-Diagramme
5.2 Klassendiagramme

Generalisierung und Vererbung

Graphische Notation durch eine Linie von der Sub- zur Superklasse mit
einem großen unausgefülltes Dreieck am Superklassen-Ende

Das Dreieck kann auch nur eines für alle Spezialisierungen
gemeinsam sein

Möglichst sollte die Superklasse über der Subklasse angeordnet
sein

Weitere Klassen können durch drei Punkte (• • •) angedeutet
werden (woanders dargestellt oder noch nicht definiert)

UML 2.0: Generalisierungseigenschaft {incomplete}
Neben die Verbindung kann man beschreibenden Text schreiben

Generalisierungsmenge

Daneben könne Generalisierungseigenschaften angegeben
werden (complete/incomplete, disjoint/overlapping)
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
245
36
5. UML-Diagramme
5.2 Klassendiagramme

Generalisierung und Vererbung

Generalisierung/Spezialisierung ist die Beziehung zwischen

einer Klasse (superclass) und

einer oder mehreren weiter verfeinerten Klassen (subclasses).

Z.B. ist Gerät die Superklasse von Pumpe und Drucktank.
Attribute und Operationen, die allen Subklassen gemeinsam sind,

werden der Superklasse zugeordnet,

stehen aber den Subklassen zur Verfügung.

Jede Subklasse erbt die Eigenschaften der Superklasse.
Generalisierung wird auch eine ist-ein (is-a) Beziehung genannt, denn:

jede Instanz der Subklasse ist auch gleichzeitig eine Instanz der
Superklasse
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
246
5. UML-Diagramme
5.2 Klassendiagramme

Generalisierung und Vererbung

Generalisierung und Vererbung sind transitiv über beliebig viele
Ebenen
Man redet von Vorfahren (ancestor) und Nachfahren (descendents).

Die Instanz einer Subklasse ist gleichzeitig Instanz aller ihrer
Vorfahren-Klassen (Substitutionsprinzip)

Der Zustand der Instanz enthält einen Wert für jedes Attribut der
Vorfahren-Klassen

Die Operation einer jeden Vorfahren-Klasse kann auf die Instanz
angewandt werden

Die Instanz kann zusätzlich weitere eigene Attribute und
Operationen selbst hinzufügen

Z.B. werden für die Klasse Pumpe die Attribute Pumpdruck und
Durchflussmenge hinzugefügt, die sonst keinen anderen Klassen
zur Verfügung steht
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
247
37
5. UML-Diagramme
5.2 Klassendiagramme

Generalisierung und Vererbung

Klassen von geometrischen Figuren:

Vererbung von Operationen

Operationen bewege,
selektiere, rotiere und
zeige an alle Subklassen
vererbt

skaliere anwendbar nur
für 1- und
NullDim
2-dimensionale
Figuren

fülle nur für
2-dimensionale

zeige als verschie- Punkt
Linie
endpunkte
dene Methoden
implementiert
zeige
© Prof. Dr. Björn Dreher
zeige
Figur
farbe
position
linienstärkel
linientyp
bewege
selektiere
rotiere
zeige {abstrakt}
Dimension
EinDim
ZweiDim
orientierung
orientierung
fuellmuster
skaliere
skaliere
fuelle
Bogen
Spline
Polygon
Kreis
radius
startwinkel
bogenwinkel
kontrollpkte
seitenzahl
vertices
radius
zeige
zeige
zeige
zeige
Softwaretechnik (Allgemeine Informatik)
248
5. UML-Diagramme
5.2 Klassendiagramme

Generalisierung und Vererbung

Eine zu tiefe Vererbungshierarchie ist genauso schwer zu überblicken
wie zu tiefe Verschachtelungen beim Programmieren

Zwei bis drei Ebenen sind gut, zehn Ebenen sind sicher zu viel,

Werte dazwischen hängen vom Einzelfall ab
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
249
38
5. UML-Diagramme
5.2 Klassendiagramme

Anwendung der Generalisierung

Nützlich sowohl bei der konzeptionellen Modellbildung als auch bei der
Implementierung

Hierbei besonders für die Erzeugung von wiederverwendbarem
Code
Objektorientierte Programmiersprachen unterstützen die Vererbung
sehr gut

Oft übersehener Vorteil: Konzeptionelle Vereinfachung, die von der
Verminderung der Anzahl der unabhängigen Features des
Systems kommt

Generalisierung, Spezialisierung und Vererbung sind Begriffe für
dieselbe Sache, lediglich die Sichtweisen sind unterschiedlich
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
250
5. UML-Diagramme
5.2 Klassendiagramme

Überschreiben von Operationen

Überschreiben bestimmter ererbter Operationen in Subklasse,

indem die entsprechende Operation unter demselben Namen neu
definiert wird (overriding feature) und

damit die ererbte Methode ersetzt
Gründe dafür:

Das Verhalten der Subklasse ist zwingend anders als das der
Superklasse

Die Spezifikation einer Eigenschaft muss enger ausgelegt werden

Bessere Performance
In dem obigen Beispiel

muss zeige für jede Figurenart separat implementiert werden

Die Operation rotiere wird für einen Kreis aus PerformanceGründen von einer leeren Methode überladen
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
251
39
5. UML-Diagramme
5.2 Klassendiagramme

Überschreiben von Operationen (fortgesetzt)

Man darf aber niemals die Signatur einer Operation verändern,

d.h. beim Überschreiben müssen Anzahl und Typen von
Parametern von Methoden und deren Resultattyp (hierbei gibt es
Ausnahmen) unverändert bleiben
Eine Operation sollte nie derart überschrieben werden,

dass sie inkonsistent mit Signatur oder Semantik der ererbten
Operation wird

Eine Subklasse ist ein Spezialfall der Superklasse und

sollte daher mit ihr weitgehend kompatibel bleiben.
Man sollte also nicht

irgendeine halbwegs passende Klasse übernehmen,

diese massiv modifizieren und evtl. sogar einige Eigenschaften,
die nicht passen, ignorieren!
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
252
5. UML-Diagramme
5.2 Klassendiagramme

Abstrakte Klassen und Schnittstellen

Abstrakte Klassen

Abstract Class

Klasse, die keine direkten Instanzen hat

Darstellung durch

Kursivschrift oder
Constraint: {abstract}.
Gilt für Klassen und Methoden
Nachkommenklassen haben Instanzen
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
253
40
5. UML-Diagramme
5.2 Klassendiagramme

Abstrakte Klassen

Darstellung als Meta-Klassenmodell:
subclass
subclass
Class
1..*
has subclasses
1..*
has subclasses
Concrete
class
superclass

Non-leaf
concrete class
Abstract
class
superclass
Leaf class
Eine concrete class ist eine Klasse, die Instanzen haben kann
Eine concrete class kann abstrakte Subklassen haben;

diese jedoch müssen wieder instanziierbare Subklassen haben
Nur konkrete Klasse kann Blatt (Ende) in dem Vererbungsbaum sein

Ausnahme: Frameworks
© Prof. Dr. Björn Dreher
254
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Abstrakte Klassen

Beispiel

Die Klasse Mitarbeiter ist eine abstrakte Klasse.

Jeder Mitarbeiter ist entweder

Aushilfe,
Arbeiter oder
Angestellter.
Mitarbeiter
jahresbezüge
berechneZahlung
{abstrakt}
Aushilfe
stundenlohn
überstdZuschlag
berechneZahlung

Arbeiter
wochenlohn
Angestellter
monatsgehalt
berechneZahlung
berechneZahlung
Abstrakte Klassen organisieren Eigenschaften, die mehreren anderen
Klassen gemein sind
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
255
41
5. UML-Diagramme
5.2 Klassendiagramme

Abstrakte Klassen

Manche abstrakten Klassen erscheinen natürlich in der
Anwendungsdomäne, andere werden künstlich eingeführt, um die
Wiederverwendung von Code zu ermöglichen

Gemeinsame Attribute

Kapseln von Klassen, die an derselben Assoziation oder
Aggregation teilnehmen

Definition von Methoden, die von den Subklassen geerbt werden
müssen

Evtl. nur die Signatur (Protokoll) der Operation,

ohne die tatsächliche Methode zu implementieren (Abstrakte
Operation)
Dies ist für Concrete Classes nicht erlaubt

Diese müssen immer Implementierungen der Methoden zur
Verfügung stellen
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
256
5. UML-Diagramme
5.2 Klassendiagramme

Abstrakte Klassen

Abstrakte Klassen definieren das Protokoll einer Operation (Anzahl,
Parameter und Resultattyp einer Operation, auch die semantische
Bedeutung!)
Nachfolgerklassen können Operationen verfeinern, z.B.

um Datentypen weiter einzuschränken,

die Initialisierung zu ändern oder

die Methode anders zu implementieren
Das Protokoll kann jedoch nicht erweitert oder geändert werden
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
257
42
5. UML-Diagramme
5.2 Klassendiagramme

Schnittstellen

Eine abstrakte Klasse ohne Implementierungen

Nur Definition der Signaturen
Sei InputStream eine abstrakte Klasse,
DataInput ein Interface
DataInputStream ist konkreter Nachfahre von InputStream und
implementiert zusätzlich DataInput.
Die Klasse OrderReader verwendet an einigen Stellen die Schnittstelle
DataInput und ist daher von ihr abhängig
InputStream
{abstract}
<<interface>>
DataInput
OrderReader
Gestrichelte
Linien!
DataInputStream
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
258
5. UML-Diagramme
5.2 Klassendiagramme

Schnittstellen

Andere Darstellung:
DataInput
OrderReader
DataInputStream
InputStream

Hier keine Unterscheidung in der Darstellung zwischen Schnittstelle
und abstrakter Klasse
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
259
43
5. UML-Diagramme
5.2 Klassendiagramme

Schnittstellen

«interface»
Klasse1
Interface1
UML 2.0:
Klasse2
«use»
«interface»
Interface1
Klasse implementiert
Schnittstelle
Klasse1
Interface1
Klasse2
Interface1
Klasse1
Klasse benötigt
Schnittstelle
Klasse2
Interface1
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
260
5. UML-Diagramme
5.2 Klassendiagramme

Generalisierung als Erweiterung oder als Restriktion

„Die Instanz einer Klasse ist gleichzeitig Instanz aller Vorfahren dieser
Klasse!“

Daher gelten alle Eigenschaften der Vorfahren automatisch auch
für alle Instanzen der Nachfahren-Klasse

Diese kann geerbte Attribute nicht weglassen oder unterdrücken
Dasselbe gilt für Operationen.

Jedoch kann eine Subklasse eine Operation reimplementieren
(Effizienzgründe o.ä.),

aber das Protokoll bleibt dasselbe
Eine Subklasse kann jedoch Eigenschaften hinzufügen (extension)

s. Mitarbeiter-Beispiel
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
261
44
5. UML-Diagramme
5.2 Klassendiagramme

Generalisierung als Erweiterung oder als Restriktion

Eine Subklasse kann Vorfahrenattribute auch einschränken (restriction)

Dabei wird der Wertebereich, den das Attribut annehmen kann,
eingeschränkt
Beispiel:

Ein Kreis ist eine Ellipse, deren große und kleine Achse gleich sind

Semantisch jedoch problematisch!
Geerbte Eigenschaften dürfen unter einer Restriktion umbenannt
werden (soweit die Zielsprache das erlaubt);

Beispiel Ellipsenachsen → Durchmesser.
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
262
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation vs. Generalisierung

Aggregation ist etwas anderes als Generalisierung, obwohl man
innerhalb einer Vererbungshierarchie die Vorfahrenklassen als Teile
der Nachfahrenklassen ansehen kann:

Aggregation setzt Instanzen in Beziehung; zwei Objekte sind
involviert, das Ganze und das Teil

Generalisierung setzt Klassen in Beziehung; strukturiert die
Beschreibung eines einzelnen Objektes

Superklasse und Subklasse beziehen sich auf Eigenschaften eines
einzelnen Objektes.
Obwohl beide Konzepte zu Baumstrukturen hinführen, bedeuten die
Bäume etwas völlig unterschiedliches

Aggregation: „part-of“- oder „hat-ein“-Beziehung

Generalisation: „is-a“-Beziehung
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
263
45
5. UML-Diagramme
5.2 Klassendiagramme

Aggregation vs. Generalisierung
Lampe
Leuchtröhre
Drossel

Halterung
Halogenlampe
Starter
Fuß
Schirm
Schalter
Kabel
Sockel
Deutlich ist hier die Ganzes-Teile Beziehung zu sehen. Jede Subklasse
besteht zusätzlich aus weiteren Teilen

Aggregation: „Und-Beziehung“

Generalisierung: „Oder-Beziehung“
© Prof. Dr. Björn Dreher
264
Softwaretechnik (Allgemeine Informatik)
5. UML-Diagramme
5.2 Klassendiagramme

Parametrisierte Klassen

C++: Template Klassen
Java: Generische Klassen
T, k: int
Liste
- eintrag: T [0..k]
operation1()
<<bind>> <T->Gast, k->20>
Gästebuch
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
<<bind>> <T->Adresse, k->100>
Telefonbuch
265
46
5. UML-Diagramme
5.2 Klassendiagramme

Klassen-Deskriptoren

Neben Attributen und Operationen, die jede Instanz einer Klasse quasi
als Eigentum bekommt, gibt es Fälle,
in denen Attribute und Operationen nur einmal in der Klasse vorhanden
sind
Die Klasse wird quasi als Meta-Objekt angesehen (Das Objekt
beschreibt die Klasse)
Klassen-Attribute

Beschreiben Werte,

die der ganzen Klasse von Objekten gemeinsam sind (im
Gegensatz zu solchen jeder einzelnen Instanz).
Anwendung:

Default-Werte zur Erzeugung neuer Instanzen,

Konstanten,

summarische Informationen über alle Instanzen der Klasse
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
266
5. UML-Diagramme
5.2 Klassendiagramme

Klassen-Operationen

Sind Operationen auf die Klasse selbst
Anwendung:

Erzeugung neuer Objektinstanzen

Hilfsmethoden, die nicht auf Zustand einer Instanz wirken

Eine Query über Klassen-Attribute
Darstellung durch Unterstreichung:
Window
size:
Rectangle
visibility:
Boolean
allWindows:
Set[Window]
visibleWindows: Set[Window]
defaultSize:
Rectangle
maximumSize:
Rectangle
display
newWindow
getHighestPriorityWindow
© Prof. Dr. Björn Dreher
Softwaretechnik (Allgemeine Informatik)
267
47

Download Report