3 Statische Konzepte in der objektorientierten Analyse - Universität ...
3 Statische Konzepte in der objektorientierten Analyse - Universität ...
3 Statische Konzepte in der objektorientierten Analyse - Universität ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Grundlagen <strong>der</strong> Softwaretechnik<br />
Info 2 - GdS<br />
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Lernziele<br />
– Erklären können, was e<strong>in</strong>e Assoziation ist<br />
– Erklären können, was e<strong>in</strong>e assoziative Klasse und e<strong>in</strong>e qualifizierte<br />
Assoziation s<strong>in</strong>d<br />
– Erklären können, was Aggregation und Komposition bedeuten<br />
– Erklären können, was Vererbung ist<br />
– Erklären können, was e<strong>in</strong> Paket ist<br />
– UML-Notation für Assoziation, Vererbung und Paket anwenden können<br />
– Assoziationen und Vererbung <strong>in</strong> e<strong>in</strong>em Text identifizieren und darstellen<br />
können<br />
– Klassen zu Paketen gruppieren können<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
149
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
Info 2 - GdS<br />
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong><br />
<strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
3.2 Assoziation<br />
3.3 Aggregation und Komposition<br />
3.4 Vererbung<br />
3.5 Paket<br />
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
3.7 Zusammenfassung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
150
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
Info 2 - GdS<br />
OOA-Modell (<strong>Analyse</strong>modell):<br />
Vererbung<br />
Assoziation<br />
<strong>Statische</strong><br />
<strong>Konzepte</strong><br />
Paket<br />
Anwendungsfall<br />
Szenario<br />
Dynamische<br />
<strong>Konzepte</strong><br />
Zustandsautomat<br />
Botschaft<br />
Attribut<br />
Operation<br />
Basiskonzepte<br />
Nicht verän<strong>der</strong>bare<br />
Aspekte<br />
(grundlegende Struktur)<br />
<strong>Statische</strong>s Modell<br />
Klasse<br />
Objekt<br />
Verhalten des Systems im<br />
Zeitverlauf<br />
(Abläufe,<br />
Kommunikationsfluss)<br />
Dynamisches Modell<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
151
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
Info 2 - GdS<br />
OOA-Modell (<strong>Analyse</strong>modell):<br />
– Das statische Modell zeigt die Struktur<br />
Klassen beschreiben die Elemente des Fachkonzepts<br />
Assoziationen beschreiben die Beziehungen zwischen den Elementen<br />
Vererbung beschreibt die Verallgeme<strong>in</strong>erung von Klassen<br />
Attribute beschreiben Eigenschaften <strong>der</strong> Klassen (Daten des Systems)<br />
Pakete teilen das System <strong>in</strong> Teilsysteme auf<br />
– Das dynamische Modell zeigt Funktionsabläufe<br />
Anwendungsfälle beschreiben die durchzuführenden Aufgaben auf<br />
e<strong>in</strong>em sehr hohen Abstraktionsniveau<br />
Szenarios zeigen, wie Objekte mite<strong>in</strong>an<strong>der</strong> kommunizieren, um e<strong>in</strong>e<br />
bestimmte Aufgabe zu erledigen<br />
Zustandsautomaten beschreiben die Reaktionen e<strong>in</strong>es Objekts auf<br />
verschiedene Ereignisse<br />
Video: <strong>Statische</strong>s Modell mit dem UML-Werkzeug Poseidon<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
152
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Frage zu 3.1 : <strong>Statische</strong>s o<strong>der</strong> dynamisches Modell<br />
– Ordnen Sie die folgenden Aussagen dem statischen o<strong>der</strong> dem<br />
dynamischen Modell zu<br />
Aussage<br />
Beschreibt das Verhalten des zu entwickelnden<br />
Softwaresystems<br />
Bildet den stabilen Kern des <strong>objektorientierten</strong> Modells<br />
Beschreibt die Beziehungen zwischen Klassen (bzw.<br />
ihren Objekten)<br />
Zeigt, wie Objekte mite<strong>in</strong>an<strong>der</strong> kommunizieren, um e<strong>in</strong>e<br />
bestimmte Aufgabe zu erledigen<br />
Modelliert die Struktur des Softwaresystems<br />
Beschreibt die Reaktionen e<strong>in</strong>es Objekts auf<br />
verschiedene Ereignisse<br />
Enthält die Aufteilung des Systems <strong>in</strong> Teilsysteme<br />
<strong>Statische</strong>s<br />
Modell<br />
<br />
<br />
<br />
<br />
Dynamisches<br />
Modell<br />
<br />
<br />
<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
153
3.2 Assoziation<br />
Info 2 - GdS<br />
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong><br />
<strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
3.2 Assoziation<br />
3.3 Aggregation und Komposition<br />
3.4 Vererbung<br />
3.5 Paket<br />
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
3.7 Zusammenfassung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
154
3.2 Assoziation<br />
Info 2 - GdS<br />
Was ist e<strong>in</strong>e Assoziation?<br />
Def<strong>in</strong>ition:<br />
E<strong>in</strong>e Assoziation modelliert Verb<strong>in</strong>dungen zwischen Objekten e<strong>in</strong>er o<strong>der</strong><br />
mehrerer Klassen.<br />
Assoziation modelliert Verb<strong>in</strong>dungen zwischen Objekten, nicht<br />
zwischen Klassen!<br />
Beispiel:<br />
Objekte <strong>der</strong> Klasse Student (z.B. Paul, Susi o<strong>der</strong> Peter) haben e<strong>in</strong>e<br />
Verb<strong>in</strong>dung zu Objekten <strong>der</strong> Klasse Lehrveranstaltung (z.B. Grundlagen <strong>der</strong><br />
Softwaretechnik am Dienstag)<br />
Student<br />
besucht<br />
Lehrveranstaltung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
155
3.2 Assoziation<br />
Info 2 - GdS<br />
Beispiel: Assoziation zwischen Tank und Ventil<br />
– Klassendiagramm<br />
Tank<br />
Füllstand<br />
Soll-Niveau<br />
1 *<br />
besitzt<br />
Ventil<br />
Art<br />
Durchfluss<br />
Zustand<br />
Zeigt Klassen und ihre Beziehungen (statische Modellelemente)<br />
– Objektdiagramm<br />
T1:Tank<br />
Füllstand = 75<br />
Soll-Niveau = 80<br />
Zeigt Objekte und ihre Beziehungen<br />
(zu e<strong>in</strong>em bestimmten Zeitpunkt)<br />
V1:Ventil<br />
Art = E<strong>in</strong>lassventil<br />
Durchfluss = 4<br />
Zustand = offen<br />
V2:Ventil<br />
Art = Auslassventil<br />
Durchfluss = 7<br />
Zustand = geschlossen<br />
Die Menge aller Verb<strong>in</strong>dungen wird als Assoziation zwischen den<br />
Objekten <strong>der</strong> Klassen Tank und Ventil bezeichnet.<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
156
3.2 Assoziation<br />
Info 2 - GdS<br />
Eigenschaften von Assoziationen<br />
– Es gibt b<strong>in</strong>äre (zwischen zwei Objekten) und höherwertige Assoziationen<br />
– E<strong>in</strong>e reflexive Assoziation besteht zwischen Objekten <strong>der</strong>selben Klasse<br />
– E<strong>in</strong>e Assoziation hat e<strong>in</strong>e Richtung (Navigierbarkeit)<br />
"Welches Objekt ist über die Beziehung <strong>in</strong>formiert?"<br />
unidirektional<br />
bidirektional<br />
Assoziationen s<strong>in</strong>d <strong>in</strong> <strong>der</strong> Systemanalyse <strong>in</strong>härent bidirektional<br />
Objekte "kennen" sich gegenseitig<br />
– 3 Arten von Assoziation<br />
e<strong>in</strong>fache Assoziation<br />
Aggregation<br />
Komposition<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
157
3.2 Assoziation<br />
Info 2 - GdS<br />
UML Notation e<strong>in</strong>er Assoziation<br />
– B<strong>in</strong>äre Assoziation<br />
L<strong>in</strong>ie zwischen e<strong>in</strong>er o<strong>der</strong> zwei Klassen<br />
Assozationsname<br />
An jedem Ende <strong>der</strong> L<strong>in</strong>ie steht die Wertigkeit bzw. Kard<strong>in</strong>alität<br />
(multiplicity)<br />
"Wie viele Objekte kann e<strong>in</strong> bestimmtes Objekt kennen"<br />
An jedem Ende kann e<strong>in</strong> Rollenname stehen<br />
Klasse1<br />
Klasse2<br />
Attribut<br />
k1<br />
k2<br />
Attribut<br />
Operation()<br />
Operation()<br />
Klasse<br />
Attribut<br />
Operation()<br />
k2<br />
k1<br />
reflexive<br />
Assoziation<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
158
3.2 Assoziation<br />
Info 2 - GdS<br />
Assoziation im Objektdiagramm (Live-Mitschrieb)<br />
ObjectTec<br />
Maier<br />
Müller<br />
– Frage: Wie sieht das Klassendiagramm zu diesem Objektdiagramm aus?<br />
*<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
159
3.2 Assoziation<br />
Info 2 - GdS<br />
Name e<strong>in</strong>er Assoziation<br />
– Beschreibt Semantik (Bedeutung) <strong>der</strong> Assoziation<br />
– Beschreibt meistens nur e<strong>in</strong>e Richtung <strong>der</strong> Assoziation<br />
– E<strong>in</strong> schwarzes Dreieck gibt die Leserichtung an<br />
– Name darf fehlen, wenn die Bedeutung <strong>der</strong> Assoziation offensichtlich ist<br />
Prozessor<br />
Bezeichnung<br />
Taktfrequenz<br />
1 *<br />
benutzt<br />
Speicher<br />
Bezeichnung<br />
Größe<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
160
3.2 Assoziation<br />
Info 2 - GdS<br />
UML Notation <strong>der</strong> Kard<strong>in</strong>alität (Anzahl <strong>der</strong> Elemente)<br />
1<br />
0 ..1<br />
*<br />
3 ..*<br />
0..2<br />
2<br />
2, 4, 6<br />
1..5, 8, 10..*<br />
genau 1<br />
0 bis 1<br />
0 bis viele<br />
3 bis viele<br />
0 bis 2<br />
genau 2<br />
2, 4 o<strong>der</strong> 6<br />
nicht 6, 7 o<strong>der</strong> 9<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
161
3.2 Assoziation<br />
Info 2 - GdS<br />
Bedeutung <strong>der</strong> Kard<strong>in</strong>alität<br />
– Kann-Assoziation<br />
Untergrenze: Kard<strong>in</strong>alität 0<br />
– Muss-Assoziation<br />
Untergrenze: Kard<strong>in</strong>alität 1 o<strong>der</strong> größer<br />
muss<br />
kann<br />
Prozessor<br />
1<br />
Speicher<br />
Prozessor kann mehrere Speicher besitzen<br />
Es gibt Prozessoren, die ke<strong>in</strong>en Speicher besitzen<br />
Je<strong>der</strong> Speicher gehört genau zu e<strong>in</strong>em Prozessor<br />
muss<br />
muss<br />
Prozessor<br />
1<br />
1..<br />
Speicher<br />
Je<strong>der</strong> Prozessor muss m<strong>in</strong>destens e<strong>in</strong>en Speicher besitzen<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
162
3.2 Assoziation<br />
Info 2 - GdS<br />
Rollenname (1)<br />
– Beschreibt Bedeutung e<strong>in</strong>es Objekts <strong>in</strong> e<strong>in</strong>er Assoziation<br />
– B<strong>in</strong>äre Assoziationen besitzen maximal zwei Rollen<br />
– Wird an das Ende <strong>der</strong> Assoziation bei <strong>der</strong> Klasse geschrieben, <strong>der</strong>en<br />
Bedeutung <strong>in</strong> <strong>der</strong> Assoziation die Rolle beschreibt<br />
– Beispiel für Klassendiagramm<br />
– Beispiel für<br />
Implementierung<br />
Prozessor<br />
Bezeichnung<br />
Taktfrequenz<br />
1 1..*<br />
CPU<br />
Speicher<br />
Bezeichnung<br />
Größe<br />
class Speicher<br />
{<br />
Prozessor CPU;<br />
}<br />
. . .<br />
Rollennamen tragen zur Verständlichkeit des<br />
Modells mehr bei als <strong>der</strong> Assoziationsname<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
163
3.2 Assoziation<br />
Info 2 - GdS<br />
Rollenname (2)<br />
– Rollenname ist nicht optional ...<br />
wenn zwischen zwei Klassen mehr als e<strong>in</strong>e Assoziation besteht<br />
Prozessor<br />
Bezeichnung<br />
Taktfrequenz<br />
1 1..*<br />
CPU<br />
* 1..*<br />
Graphikkarte<br />
Speicher<br />
Bezeichnung<br />
Taktfrequenz<br />
bei reflexiven Assoziationen<br />
Rechner<br />
IP-Adresse<br />
Standort<br />
Protokolle<br />
Client<br />
*<br />
Server 1<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
164
3.2 Assoziation<br />
Info 2 - GdS<br />
Gerichtete Assoziation<br />
– Nur e<strong>in</strong> Objekt ist über Beziehung <strong>in</strong>formiert (unidirektionale Navigierbarkeit)<br />
– Nur <strong>in</strong> die Navigationsrichtung können Botschaften geschickt werden.<br />
– Darstellung durch geöffnete Pfeilspitze<br />
Tank<br />
steuert<br />
1. .*<br />
Alarmsignal<br />
Hupe<br />
E<strong>in</strong>er Hupe ist nicht bekannt,<br />
von welchen Tanks sie als<br />
Alarmsignal verwendet wird.<br />
– Jede bidirektionale Assoziation kann durch zwei unidirektionale<br />
Assoziationen ausgedrückt werden<br />
Tank<br />
1. .*<br />
steuert<br />
1. .*<br />
wird<br />
gesteuert von<br />
Hupe<br />
Tank<br />
1. .*<br />
steuert<br />
1. .*<br />
Hupe<br />
Navigierbarkeit <strong>in</strong> <strong>der</strong> <strong>Analyse</strong> nur <strong>in</strong> Ausnahmefällen festlegen<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
165
3.2 Assoziation<br />
Info 2 - GdS<br />
Geordnete Assoziation<br />
– Zeigt an, dass die Menge <strong>der</strong> Objektverb<strong>in</strong>dungen geordnet ist<br />
– Möglich bei Kard<strong>in</strong>alität größer e<strong>in</strong>s<br />
– Kennzeichnung <strong>der</strong> Ordnung durch das Schlüsselwort {or<strong>der</strong>ed}<br />
Ke<strong>in</strong>e Aussage über Def<strong>in</strong>ition <strong>der</strong> Ordnung (z.B. zeitlich, alphabetisch)<br />
Register<br />
1 {or<strong>der</strong>ed}*<br />
Speicherstelle<br />
Bit<br />
1. Stelle<br />
:Bit<br />
:Register<br />
2. Stelle<br />
:Bit<br />
3. Stelle<br />
:Bit<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
166
3.2 Assoziation<br />
Info 2 - GdS<br />
Restriktion (constra<strong>in</strong>t) e<strong>in</strong>er Assoziation<br />
– Bed<strong>in</strong>gung, die stets erfüllt se<strong>in</strong> muss<br />
– E<strong>in</strong>schränkung <strong>der</strong> möglichen Inhalte e<strong>in</strong>es Modellelements<br />
Angestellter<br />
Name<br />
Gehalt<br />
Position<br />
Mitarbeiter<br />
*<br />
Chef<br />
0..1<br />
{Chef.Gehalt><br />
Mitarbeiter.Gehalt}<br />
a1: Angestellter<br />
Gehalt = 7000<br />
Chef<br />
Mitarbeiter<br />
a2: Angestellter<br />
Gehalt = 5000<br />
a3: Angestellter<br />
Gehalt = 4500<br />
Chef<br />
Mitarbeiter<br />
a4: Angestellter<br />
Gehalt = 3000<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
167
3.2 Assoziation<br />
Info 2 - GdS<br />
or-Restriktion e<strong>in</strong>er Assoziation<br />
– Zu jedem beliebigen Zeitpunkt kann nur e<strong>in</strong>e von mehreren möglichen<br />
Assoziationen gelten<br />
– or- Restriktion kann sich auf mehr als zwei Assoziationen beziehen<br />
– Wichtig: E<strong>in</strong>bezogene Klassen müssen unterschiedliche Rollennamen haben<br />
Fehlt <strong>der</strong> Rollenname, gilt: Name <strong>der</strong> Klasse = Rollenname<br />
lagert <strong>in</strong><br />
1<br />
Hochregallager<br />
Palette1<br />
Palette<br />
*<br />
*<br />
{or}<br />
lagert <strong>in</strong><br />
1<br />
Lagerraum<br />
Palette2<br />
:Hochregallager<br />
:Lagerraum<br />
subset-Restriktion e<strong>in</strong>er Assoziation<br />
Sportler<br />
Teilnehmer<br />
*<br />
Sieger<br />
{subset}<br />
*<br />
0..1<br />
*<br />
Wettbewerb<br />
siehe Kap. 3.6<br />
Erweiterungsmechanismen<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
168
3.2 Assoziation<br />
Info 2 - GdS<br />
Beispiel für or-Restriktion: Umleitventil (Live-Mitschrieb)<br />
Umleit-<br />
ventil<br />
Abfluss<br />
1<br />
{or}<br />
1<br />
Speicherung<br />
Pumpe<br />
Druckspeicher<br />
– Java Code<br />
class Umleitventil {<br />
Pumpe Abfluss;<br />
Druckspeicher Speicherung;<br />
...<br />
}<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
169
3.2 Assoziation<br />
Info 2 - GdS<br />
Assoziative Klasse (association class)<br />
– Assoziationen können zusätzlich die Eigenschaften e<strong>in</strong>er Klasse besitzen<br />
– Darstellung mit Klassensymbol und gestrichelter L<strong>in</strong>ie<br />
– Name <strong>der</strong> Assoziation und <strong>der</strong> Assoziationsklasse s<strong>in</strong>d stets identisch<br />
Sen<strong>der</strong><br />
Name<br />
Adresse<br />
1 *<br />
Kanal<br />
Protokoll<br />
Zustand<br />
Empfänger<br />
Name<br />
Adresse<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
170
3.2 Assoziation<br />
Info 2 - GdS<br />
Verwendung von assoziativen Klassen (1)<br />
– Erfor<strong>der</strong>lich für Attribute und Operationen, die we<strong>der</strong> <strong>der</strong> e<strong>in</strong>en noch <strong>der</strong><br />
an<strong>der</strong>en Klasse zugeordnet werden können, son<strong>der</strong>n Eigenschaft <strong>der</strong><br />
Beziehung selbst s<strong>in</strong>d.<br />
– Werden nur <strong>in</strong> <strong>der</strong> <strong>Analyse</strong> verwendet<br />
– Im Entwurf Umwandlung <strong>in</strong> e<strong>in</strong>e richtige Klasse<br />
Klasse 1<br />
Rolle 1<br />
k1<br />
Rolle 2<br />
k2<br />
Klasse 2<br />
Klasse 1<br />
Rolle 1<br />
Assoziationsklasse<br />
Assoziationsklasse<br />
Rolle 2<br />
1 Rolle 2 Rolle 1 1<br />
k2<br />
k1<br />
Wichtig:<br />
Übernahme <strong>der</strong><br />
Kard<strong>in</strong>alitäten!<br />
Klasse 2<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
171
3.2 Assoziation<br />
Info 2 - GdS<br />
Verwendung von assoziativen Klassen (2)<br />
– Beispiel: Umwandlung e<strong>in</strong>er Assoziationsklasse<br />
Sen<strong>der</strong><br />
Name<br />
Adresse<br />
1 *<br />
Kanal<br />
Protokoll<br />
Zustand<br />
Empfänger<br />
Name<br />
Adresse<br />
Sen<strong>der</strong><br />
Name<br />
Adresse<br />
Empfänger<br />
Name<br />
Adresse<br />
1 1<br />
*<br />
Kanal<br />
Protokoll<br />
Zustand<br />
1<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
172
3.2 Assoziation<br />
Info 2 - GdS<br />
Qualifizierte Assoziation<br />
– E<strong>in</strong>teilung <strong>der</strong> Menge <strong>der</strong> assoziierten Objekte durch spezielles Attribut,<br />
dessen Wert e<strong>in</strong> o<strong>der</strong> mehrere Objekte auf <strong>der</strong> an<strong>der</strong>en Seite selektiert<br />
– Erhöhen den Informationsgehalt des Klassenmodells<br />
– Das qualifizierende Attribut wird <strong>in</strong> e<strong>in</strong>em Rechteck an <strong>der</strong> Seite <strong>der</strong><br />
Klasse notiert<br />
Mitarbeiter<br />
Name<br />
Personalnr.<br />
* beschaeftigt 1<br />
Unternehmen<br />
Name<br />
Anschrift<br />
E<strong>in</strong> Unternehmen<br />
beschäftigt e<strong>in</strong>e Menge<br />
von Mitarbeitern<br />
Je<strong>der</strong> Mitarbeiter<br />
gehört genau zu<br />
e<strong>in</strong>em Unternehmen<br />
Mitarbeiter<br />
Name<br />
Personalnr.<br />
1<br />
beschaeftigt 1<br />
Personalnr.<br />
Unternehmen<br />
Name<br />
Anschrift<br />
Mitarbeiter werden<br />
über ihre Personalnummer<br />
identifiziert<br />
Qualifikationsangaben können die Kard<strong>in</strong>alität verän<strong>der</strong>n!<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
173
3.2 Assoziation<br />
Info 2 - GdS<br />
Beispiel zu qualifizierte Assoziation<br />
– Ohne Qualifikation<br />
Schnittstellenkarte<br />
Typ<br />
Steckplatznr.<br />
* bedient 0..1<br />
PC-Bus<br />
Übertragungsrate<br />
PC-Bus bedient viele<br />
Schnittstellenkarten<br />
– Mit Qualifikation<br />
Schnittstellenkarte<br />
Typ<br />
Steckplatznr.<br />
1<br />
bedient 0..1<br />
Steckplatznr.<br />
PC-Bus<br />
Übertragungsrate<br />
PC-Bus-Objekt<br />
zusammen mit<br />
Steckplatznummer<br />
selektiert genau e<strong>in</strong>e<br />
Schnittstellenkarte<br />
– Veranschaulichung:<br />
Bezeichnung(Karte) Steckplatznr. Typ (PC-Bus)<br />
Graphikkarte 1 IDE-Bus<br />
Soundkarte 2 IDE-Bus<br />
Festplattencontroller 5 SCSI-Bus<br />
Video: Anwendungsbeispiel Sortierband - Assoziationen<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
174
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Frage zu 3.2<br />
Beschreiben Sie mit eigenen Worten, welche Art von Beziehung zwischen<br />
den zwei Klassen <strong>in</strong> dem nachfolgend abgebildeten Modell besteht.<br />
Person<br />
Name<br />
Vorname<br />
1..*<br />
*<br />
Volkshochschulkurs<br />
Nummer<br />
Bezeichnung<br />
Antwort<br />
– Bidirektionale Assoziation zwischen Person und Volkshochschulkurs<br />
– E<strong>in</strong>e Person kann null o<strong>der</strong> mehrere VHS-Kurse besuchen<br />
– Je<strong>der</strong> VHS-Kurs hat m<strong>in</strong>destens e<strong>in</strong>en Teilnehmer<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
175
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Frage zu 3.2<br />
Folgendes Diagramm ist gegeben:<br />
Student<br />
4<br />
Vere<strong>in</strong><br />
1<br />
3<br />
Unternehmen<br />
2<br />
Raum<br />
a) "arbeitet für“, b) "besitzt“,<br />
c) "nutzt“, d) "ist Mitglied",<br />
e) "befreundet mit“,<br />
f) "schraubt"<br />
Wie könnte die Bezeichnung <strong>der</strong> Assoziationen lauten?<br />
Antwort<br />
Möglichkeit 1: Möglichkeit 2:<br />
Student<br />
arbeitet<br />
für<br />
Unternehmen<br />
Student<br />
arbeitet<br />
für<br />
Unternehmen<br />
ist<br />
Mitglied<br />
Vere<strong>in</strong><br />
nutzt<br />
Raum<br />
besitzt<br />
arbeitet<br />
für<br />
Vere<strong>in</strong><br />
besitzt<br />
Raum<br />
nutzt<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
176
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong><br />
<strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
3.2 Assoziation<br />
3.3 Aggregation und Komposition<br />
3.4 Vererbung<br />
3.5 Paket<br />
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
3.7 Zusammenfassung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
177
Füllstandsmesser<br />
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
Aggregation<br />
Def<strong>in</strong>ition: E<strong>in</strong>e Aggregation bezeichnet e<strong>in</strong>e "Teil-Ganzes“- (whole-part)<br />
o<strong>der</strong> "ist-Teil-von“-Beziehung zwischen Klassen<br />
Ganzes<br />
Aggregatklasse<br />
Teil<br />
Teilklasse<br />
– Aggregation ist e<strong>in</strong>e spezielle Form <strong>der</strong> Assoziation<br />
– Lässt sich durch ist Teil von bzw. besteht aus beschreiben (Ganzes – Teile)<br />
– Raute kennzeichnet das Ganze<br />
Beispiel:<br />
Max-Niveau<br />
Soll-Niveau<br />
Füllstand<br />
Tank<br />
Füllstand<br />
Max-Niveau<br />
Soll-Niveau<br />
besteht aus ><br />
< ist Teil von<br />
Füllstandsmesser<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
178
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
Eigenschaften <strong>der</strong> Aggregation<br />
– ist asymmetrisch<br />
wenn B Teil von A ist, dann darf A nicht Teil von B se<strong>in</strong><br />
– ist transitiv<br />
wenn A Teil von B und B Teil von C, dann ist auch A Teil von C<br />
Anlage<br />
besteht aus<br />
1 1..*<br />
Tank<br />
besteht aus<br />
1 1..*<br />
Füllstandsmesser<br />
– muss nicht exklusiv se<strong>in</strong><br />
B darf gleichzeitig Teil von A und Teil von C se<strong>in</strong><br />
Abteilung<br />
beschäftigt<br />
1..* 1..*<br />
arbeitet für<br />
Freier Mitarbeiter<br />
– Das Ganze übernimmt Aufgaben stellvertretend für se<strong>in</strong>e Teile<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
179
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
Transivität e<strong>in</strong>er <strong>der</strong> Aggregation (Live-Mitschrieb)<br />
– Beispiel Pkw:<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
180
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
Wann liegt e<strong>in</strong>e Aggregation vor?<br />
– E<strong>in</strong>e Aggregation liegt vor, wenn die folgenden Fragen mit ja beantwortet<br />
werden können:<br />
1. Ist die Beschreibung ”Teil von” zutreffend?<br />
2. Werden manche Operationen auf das ”Ganze” automatisch auch auf<br />
die ”Teile” angewandt?<br />
3. Pflanzen sich manche Attribute vom ”Ganzen” auf alle o<strong>der</strong> e<strong>in</strong>ige<br />
”Teile” fort?<br />
4. Ist die Verb<strong>in</strong>dung durch e<strong>in</strong>e Asymmetrie gekennzeichnet, bei <strong>der</strong> die<br />
”Teile” dem ”Ganzen” untergeordnet s<strong>in</strong>d?<br />
– Beispiele für Aggregationsbeziehungen<br />
Das Ganze und se<strong>in</strong>e Teile<br />
Bsp.: Pkw (Ganzes) und Motor (Teil)<br />
Der Behälter und se<strong>in</strong> Inhalt<br />
Bsp.: Kaffeemasch<strong>in</strong>e (Behälter) und Kaffeepulver (Inhalt)<br />
Die Kollektion und ihre Mitglie<strong>der</strong><br />
Bsp.: Firma (Kollektion) und Angestellte (Mitglie<strong>der</strong>)<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
181
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
Komposition<br />
Def<strong>in</strong>ition: E<strong>in</strong>e Aggregation mit starker B<strong>in</strong>dung (Existenzabhängigkeit) wird<br />
als Komposition bezeichnet<br />
Ganzes<br />
Aggregation<br />
Teil<br />
Komposition<br />
Existenzabhängiges<br />
Teil<br />
– Kennzeichung durch gefüllte Raute<br />
Beispiel:<br />
Buch<br />
besteht<br />
aus<br />
ist Teil<br />
von<br />
Kapitel<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
182
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
Eigenschaften <strong>der</strong> Komposition<br />
Zusätzlich zur Aggregation gilt:<br />
– Jedes Objekt <strong>der</strong> Teilklasse kann zu e<strong>in</strong>em bestimmten Zeitpunkt<br />
nur Komponente e<strong>in</strong>es e<strong>in</strong>zigen Objekts <strong>der</strong> Aggregatklasse se<strong>in</strong><br />
Kard<strong>in</strong>alität <strong>der</strong> Aggregatklasse
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
Vergleich Aggregation vs. Komposition (2)<br />
PKW<br />
1<br />
hat<br />
4..5<br />
Rad<br />
Fenster<br />
1<br />
hat<br />
1..*<br />
Rahmen<br />
– Aggregation: "Pkw hat Rä<strong>der</strong>“<br />
Rä<strong>der</strong> gehören notwendigerweise zu e<strong>in</strong>em Auto<br />
Aggregation<br />
Rä<strong>der</strong> können aber eigenständig und zwischen Pkw austauschbar<br />
betrachtet werden<br />
ke<strong>in</strong>e Komposition<br />
– Komposition: „Fenster hat Rahmen“<br />
Wird das Fenster gelöscht, werden auch alle existenzabhängigen<br />
E<strong>in</strong>zelteile mitgelöscht<br />
Komposition<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
184
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
Beispiel Reiseunternehmen<br />
E<strong>in</strong> Reiseunternehmen erarbeitet e<strong>in</strong> Klassenmodell für die Verwaltung se<strong>in</strong>er<br />
Reisekataloge, se<strong>in</strong>er Reisebeschreibungen und <strong>der</strong> Reiseunterlagen. Selbstverständlich<br />
beschreibt e<strong>in</strong>e Klasse auch den Touristen, <strong>der</strong> die Reisen bucht.<br />
– E<strong>in</strong> Reisekatalog enthält e<strong>in</strong>e o<strong>der</strong> mehrere Reisebeschreibungen.<br />
– Die Reiseunterlagen für den Touristen werden aus e<strong>in</strong>zelnen Reisebeschreibungen,<br />
eventuell aus verschiedenen Katalogen, zusammengestellt.<br />
– Mehrere Touristen können auch geme<strong>in</strong>same Reiseunterlagen erhalten.<br />
hat<br />
bezieht sich auf<br />
Tourist Reiseunterlagen Katalog<br />
1..* 1..*<br />
0..* 1..*<br />
1<br />
1<br />
besteht aus<br />
besteht aus<br />
1..*<br />
1..*<br />
Reisebeschreibung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
185
3.3 Aggregation und Komposition<br />
Info 2 - GdS<br />
Beispiel Tanksystem<br />
– E<strong>in</strong> Tanksystem besteht aus mehreren<br />
Tanks, E<strong>in</strong>- bzw. Auslassventilen,<br />
Füllstandsmessern und Rohrleitungen<br />
– Je<strong>der</strong> Tank hat e<strong>in</strong> bis zwei E<strong>in</strong>lassventile,<br />
e<strong>in</strong> Auslassventil und e<strong>in</strong>en<br />
Füllstandsmesser<br />
– Je zwei Ventile unterschiedlichen Typs<br />
können über Rohrleitungen mite<strong>in</strong>an<strong>der</strong><br />
verbunden se<strong>in</strong>.<br />
1<br />
Füllstandsmesser<br />
Tank<br />
Füllstand<br />
Soll-Niveau<br />
füllen()<br />
leeren()<br />
setze_Soll-Niveau()<br />
1..2<br />
1<br />
E<strong>in</strong>lassventil<br />
0..1<br />
0..1<br />
Auslassventil<br />
Rohrleitung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
186
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Frage zu 3.3<br />
1. Gegeben seien die Klassen Haus und Zimmer. Welche Art Beziehung<br />
würden Sie zwischen beiden modellieren?<br />
Die e<strong>in</strong>fache Assoziation "hat Beziehung zu“<br />
Die Aggregation "besteht aus"<br />
Begründung:<br />
Existenzabhängigkeit<br />
zwischen Haus und Zimmer<br />
<br />
Die Komposition "besteht aus"<br />
2. Gegeben seien die Klassen Haus und Mieter. Welche Art <strong>der</strong> Assoziation<br />
würden Sie modellieren?<br />
<br />
Die e<strong>in</strong>fache Assoziation "hat"<br />
Die Aggregation "setzt sich zusammen aus"<br />
Die Komposition "besteht aus"<br />
Begründung: Die Beziehung<br />
zwischen Haus und Mietern<br />
ist nicht so <strong>in</strong>nig. Aggregation<br />
ist auch noch vertretbar.<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
187
3.4 Vererbung<br />
Info 2 - GdS<br />
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong><br />
<strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
3.2 Assoziation<br />
3.3 Aggregation und Komposition<br />
3.4 Vererbung<br />
3.5 Paket<br />
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
3.7 Zusammenfassung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
188
3.4 Vererbung<br />
Info 2 - GdS<br />
Ähnliches Verhalten von Objekten (Live-Mitschrieb)<br />
Ordner<br />
e<strong>in</strong>fügen<br />
= im Ordner abheften<br />
Mappe<br />
e<strong>in</strong>fügen<br />
= <strong>in</strong> <strong>der</strong> Mappe ablegen<br />
Ablage<br />
e<strong>in</strong>fügen<br />
Ordner<br />
Mappe<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
189
3.4 Vererbung<br />
Info 2 - GdS<br />
Was ist Vererbung?<br />
Def<strong>in</strong>ition: E<strong>in</strong>e Vererbung (generalization) ist e<strong>in</strong>e Beziehung zwischen<br />
e<strong>in</strong>er allgeme<strong>in</strong>en Klasse und e<strong>in</strong>er spezialisierten Klasse.<br />
Vererbung f<strong>in</strong>det nur zwischen Klassen statt!<br />
– Vererbung ist e<strong>in</strong> Abstraktionspr<strong>in</strong>zip zur hierarchischen Strukturierung<br />
(E<strong>in</strong>ordnung <strong>der</strong> Klassen <strong>in</strong> e<strong>in</strong>e Hierarchie)<br />
– Ziel: Geme<strong>in</strong>same Eigenschaften und Verhaltensweisen zusammenfassen<br />
– Spezialisierte Klasse ist vollständig konsistent mit allgeme<strong>in</strong>er Klasse,<br />
kann aber zusätzliche Informationen (Attribute, Operationen,<br />
Assoziationen) haben<br />
– Allgeme<strong>in</strong>e Klasse = Oberklasse (super class)<br />
– Spezialisierte Klasse = Unterklasse (sub class)<br />
Oberklasse<br />
Unterklasse<br />
Generalisierung<br />
Spezialisierung<br />
Substitutionspr<strong>in</strong>zip: Objekt <strong>der</strong> Unterklasse kann überall verwendet<br />
werden, wo e<strong>in</strong> Objekt <strong>der</strong> Oberklasse erlaubt ist, aber nicht umgekehrt!<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
190
3.4 Vererbung<br />
Beispiel e<strong>in</strong>er Vererbungsstruktur<br />
Zustand<br />
Ventil<br />
öffnen()<br />
schliessen()<br />
Leitungselement<br />
Nummer<br />
Länge<br />
Breite<br />
Höhe<br />
Durchfluss<br />
Umschaltventil<br />
Anzahl Abflüsse<br />
än<strong>der</strong>eRichtung()<br />
Pumpe<br />
Typ<br />
Pumpleistung<br />
start()<br />
stop()<br />
Pumpe<br />
Typ<br />
Nummer<br />
Länge<br />
Breite<br />
Höhe<br />
Durchfluss<br />
Pumpleistung<br />
start()<br />
stop()<br />
Vererbung ist e<strong>in</strong>e "ist e<strong>in</strong>" Beziehung<br />
Info 2 - GdS<br />
Ventil<br />
Nummer<br />
Länge<br />
Breite<br />
Höhe<br />
Durchfluss<br />
Zustand<br />
öffnen()<br />
schliessen()<br />
Umschaltventil<br />
Nummer<br />
Länge<br />
Breite<br />
Höhe<br />
Durchfluss<br />
Zustand<br />
Anzahl Abflüsse<br />
öffnen()<br />
schliessen()<br />
än<strong>der</strong>eRichtung()<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
191
3.4 Vererbung<br />
Info 2 - GdS<br />
UML Notation <strong>der</strong> Vererbung<br />
– Weißes bzw. transparentes Dreieck bei <strong>der</strong> Oberklasse<br />
Klasse1<br />
Klasse1<br />
Klasse2<br />
Klasse3<br />
Klasse2<br />
Klasse3<br />
Darstellungen gleichwertig alternativ verwendbar<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
192
3.4 Vererbung<br />
Info 2 - GdS<br />
Was wird vererbt ?<br />
– Operationen, Attribute und Assoziationen<br />
Objektdiagramm<br />
Klassendiagramm<br />
Obj3:AnyClass<br />
Objekt1<br />
<br />
SuperClass<br />
1<br />
AnyClass<br />
AttributA = Wert1<br />
AttributA<br />
Klassenattribut = W<br />
OperationA()<br />
Obj4:AnyClass<br />
Objekt2<br />
<br />
SubClass<br />
1 OtherClass<br />
Obj5:OtherClass<br />
AttributA = Wert2<br />
AttributB = Wert3<br />
AttributB<br />
OperationB()<br />
1. Attribut A von Superclass wird nach Subclass vererbt<br />
2. 0perationenA() von Superclass auch auf Subclass anwendbar<br />
3. Klassenattribut mit dem Wert W von Superclass an Subclass<br />
4. Assoziation zwischen Superclass und AnyClass an Subclass<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
193
3.4 Vererbung<br />
Info 2 - GdS<br />
Überschreiben von Operationen<br />
– Unterklassen können das Verhalten ihrer Oberklassen verfe<strong>in</strong>ern,<br />
redef<strong>in</strong>ieren bzw. überschreiben (redef<strong>in</strong>e, override)<br />
– Operationen können <strong>in</strong> <strong>der</strong> Unterklasse überschrieben, aber nicht<br />
elim<strong>in</strong>iert werden<br />
Gleiche Signatur <strong>der</strong> Operationen erfor<strong>der</strong>lich!<br />
Konto<br />
Kontonummer<br />
Kontostand<br />
buchen ()<br />
Durchfluss<br />
Zustand<br />
öffnen ()<br />
Ventil<br />
buchen ()<br />
Sparkonto<br />
Magnetventil<br />
öffnen ()<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
194
3.4 Vererbung<br />
Info 2 - GdS<br />
Abstrakte Klasse<br />
– Unterscheidung zwischen abstrakten und konkreten Klassen<br />
– Von e<strong>in</strong>er abstrakten Klasse können ke<strong>in</strong>e Objekte erzeugt werden<br />
– Verwendung, um ihre Informationen an spezialisierte Klassen zu vererben<br />
– Kennzeichnung durch kursiven Namen o<strong>der</strong> durch Merkmal {abstract}<br />
– E<strong>in</strong>e abstrakte Klasse kann abstrakte Operationen enthalten. Abstrakte<br />
Operationen müssen <strong>in</strong> <strong>der</strong> Unterklasse implementiert werden.<br />
Abstrakte Klasse ohne Vererbung s<strong>in</strong>nlos<br />
Person<br />
{abstract}<br />
Säugetier<br />
{abstract}<br />
Pflanzenfresser<br />
{abstract}<br />
Fleischfresser<br />
{abstract}<br />
Frau<br />
Mann<br />
Kuh<br />
Tiger<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
195
3.4 Vererbung<br />
Info 2 - GdS<br />
Polymorphismus<br />
Def<strong>in</strong>ition:<br />
E<strong>in</strong>e Botschaft ist polymorph, wenn sie bei unterschiedlichen Objekten<br />
Methoden aktiviert, die verschiedene Semantiken besitzen.<br />
– Polymorphie bedeutet unterschiedliches Verhalten verschiedener Objekte<br />
auf die gleiche Botschaft<br />
Beispiel<br />
– Methode move(Position) bei den verschieden<br />
Spielfiguren unterschiedlich implementiert<br />
Turm: Nur geradeaus<br />
Läufer: Nur diagonal<br />
Spr<strong>in</strong>ger: 1 Feld gerade, 1 Feld diagonal<br />
Gleiche Botschaft move(Position) löst<br />
unterschiedliche Reaktion aus<br />
Turm<br />
move(Pos)<br />
Schachfigur<br />
{abstract}<br />
Position<br />
move(Pos)<br />
{abstract}<br />
Läufer<br />
move(Pos)<br />
Spr<strong>in</strong>ger<br />
move(Pos)<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
196
3.4 Vererbung<br />
Info 2 - GdS<br />
Funktionsweise des Polymorphismus (Live-Mitschrieb)<br />
– Beispiel Schachspiel<br />
Spieler<br />
me<strong>in</strong>eFiguren: list of SchachFigur<br />
me<strong>in</strong>eFiguren = (:Turm, :Bauer, :Spr<strong>in</strong>ger, :Läufer, :Turm, ...)<br />
move(Pos)<br />
– Methode move(Pos) unterschiedliche Reaktionen<br />
– Z.B. me<strong>in</strong>eFiguren[2].move(a3)<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
197
3.4 Vererbung<br />
Info 2 - GdS<br />
Beispiel für Vererbung (1)<br />
– Auf e<strong>in</strong>er Fensterfläche sollen Kreise, Rechtecke und Dreiecke angezeigt,<br />
verschoben und entfernt werden können.<br />
– Die Begriffe Kreis, Rechteck und Dreieck können generalisiert und ganz<br />
allgeme<strong>in</strong> als geometrische Figuren bezeichnet werden.<br />
– Die Klassen Kreis, Rechteck und Dreieck s<strong>in</strong>d demnach Spezialisierungen<br />
<strong>der</strong> geme<strong>in</strong>samen Oberklasse GeomFigur<br />
GeomFigur<br />
Oberklasse<br />
Figurenform<br />
Diskrim<strong>in</strong>ator: Unterscheidungsmerkmal:<br />
gibt an,<br />
nach welchem Kriterium<br />
e<strong>in</strong>e Vererbungsstruktur<br />
erstellt wird<br />
Dreieck<br />
Kreis<br />
Rechteck<br />
Unterklasse<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
198
3.4 Vererbung<br />
Info 2 - GdS<br />
Beispiel für Vererbung (2)<br />
– Klassendiagramm<br />
GeomFigur<br />
{abstract}<br />
x: Integer<br />
y: Integer<br />
sichtbar: Boolean<br />
anzeigen() {abstract}<br />
entfernen() {abstract}<br />
verschiebeZu(pX, pY)<br />
Figurenform<br />
Abstrakte<br />
Klasse<br />
Diskrim<strong>in</strong>ator<br />
Kreis<br />
Rechteck<br />
Dreieck<br />
radius {radius > 0}<br />
setRadius(pR)<br />
anzeigen()<br />
entfernen()<br />
a {a > 0}<br />
b {b > 0}<br />
setKanten(pA, pB)<br />
anzeigen()<br />
entfernen()<br />
a {c-b < a < b+c}<br />
b {a-c < b < a+c}<br />
c {a-b < c < a+b}<br />
setKanten(pA, pB, pC)<br />
anzeigen()<br />
entfernen()<br />
Konkrete<br />
Klassen<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
199
3.4 Vererbung<br />
Info 2 - GdS<br />
Beispiel für Vererbung (3)<br />
– Java-Programmcode (Ausschnitt)<br />
abstract class GeomFigur<br />
{<br />
<strong>in</strong>t x, y;<br />
boolean sichtbar;<br />
}<br />
public abstract void anzeigen();<br />
public abstract void entfernen();<br />
public void verschiebeZu(<strong>in</strong>t pX,pY)<br />
{<br />
if (sichtbar)<br />
{<br />
entfernen();<br />
this.x = pX;<br />
this.y = pY;<br />
anzeigen();<br />
} else<br />
{<br />
this.x = pX;<br />
this.y = pY;<br />
}<br />
}<br />
class Rechteck extends GeomFigur<br />
{<br />
<strong>in</strong>t a, b;<br />
}<br />
public void anzeigen()<br />
{...}<br />
public void entfernen()<br />
{...}<br />
public void setKanten(<strong>in</strong>t pA, pB)<br />
{<br />
if ((a > 0) && (b > 0))<br />
{<br />
this.a = pA;<br />
this.b = pB;<br />
}<br />
}<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
200
3.4 Vererbung<br />
Info 2 - GdS<br />
Vor- und Nachteile <strong>der</strong> Vererbung<br />
+ Unterstützung <strong>der</strong> Än<strong>der</strong>barkeit<br />
Än<strong>der</strong>ung von Attributen <strong>in</strong> <strong>der</strong> Oberklasse wirkt sich automatisch auf<br />
alle Unterklassen aus<br />
+ E<strong>in</strong>sparung von Code<br />
+ Unterstützung <strong>der</strong> Wie<strong>der</strong>verwendbarkeit<br />
– Verletzung des Geheimnispr<strong>in</strong>zips<br />
Unterklasse ist von Än<strong>der</strong>ungen <strong>der</strong> Oberklasse abhängig<br />
Um die Unterklasse zu verstehen, muß<br />
auch die Oberklasse betrachtet werden<br />
Vererbung ist e<strong>in</strong> mächtiges, aber auch schwieriges Konzept<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
201
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Frage zu 3.4<br />
Kann e<strong>in</strong> Objekt Attribute und Methoden erben?<br />
Antwort<br />
Ja<br />
<br />
Ne<strong>in</strong><br />
Ja, außer Klassenattribute und -operationen<br />
Begründung<br />
– Die Klasse kann Attribute und Methoden von an<strong>der</strong>en Klassen erben<br />
– Objekt bekommt die Attribute und Methoden se<strong>in</strong>er Klasse bei <strong>der</strong><br />
Erzeugung aufgeprägt<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
202
3.5 Paket<br />
Info 2 - GdS<br />
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong><br />
<strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
3.2 Assoziation<br />
3.3 Aggregation und Komposition<br />
3.4 Vererbung<br />
3.5 Paket<br />
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
3.7 Zusammenfassung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
203
3.5 Paket<br />
Info 2 - GdS<br />
Was ist e<strong>in</strong> Paket?<br />
Def<strong>in</strong>ition:<br />
E<strong>in</strong> Paket (package) fasst Modellelemente (z.B. Klassen) zusammen<br />
– Pakete schaffen e<strong>in</strong>e bessere Übersicht über e<strong>in</strong> großes Modell<br />
– E<strong>in</strong> Paket kann selbst Pakete enthalten<br />
– Beschreibung <strong>der</strong> Systemstruktur auf e<strong>in</strong>er hohen Abstraktionsebene<br />
Das vollständige System kann als e<strong>in</strong> großes Paket aufgefasst werden<br />
Beispiel: Brauerei<br />
Malzproduktion<br />
Gärstation Abfüllung Lager<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
204
3.5 Paket<br />
Info 2 - GdS<br />
UML-Notation von Paketen<br />
– Paketname muss im gesamten System e<strong>in</strong>deutig se<strong>in</strong><br />
– Paketdiagramm: enthält Pakete und <strong>der</strong>en Abhängigkeiten<br />
Notation von<br />
Paketen<br />
System<br />
Abhängigkeiten von Paketen<br />
Paket1<br />
Paket2<br />
Paket1<br />
Paket2<br />
Paket3<br />
Paket1 und Paket2 s<strong>in</strong>d von Paket3 abhängig<br />
– Jede Klasse (jedes Modellelement) gehört zu höchstens e<strong>in</strong>em Paket<br />
– Es kann <strong>in</strong> mehreren an<strong>der</strong>en Paketen darauf verwiesen werden<br />
– E<strong>in</strong> Paket def<strong>in</strong>iert e<strong>in</strong>en Namensraum für alle enthaltenen Klassen<br />
– Verweis von außerhalb des Pakets<br />
Paket::Klasse o<strong>der</strong> Paket1::Paket11::Paket111::Klasse<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
205
3.5 Paket<br />
Info 2 - GdS<br />
Vererbung bei Paketen<br />
– Abgeleitete Pakete erben öffentliche (public) und geschützte (protected)<br />
Elemente des Oberpaketes<br />
– Elemente können <strong>in</strong> den abgeleiteten Paketen überschrieben werden<br />
Vorteile <strong>der</strong> Aufteilung <strong>in</strong> Pakete<br />
+ Besseres Verständnis durch Betrachtung von Teilsystemen bzw.<br />
Systemausschnitten<br />
+ Vermeidung von Namenskonflikten<br />
+ Zugriffskontrolle für Elemente <strong>in</strong> Paketen, Kapselung<br />
+ Vere<strong>in</strong>fachung <strong>der</strong> Testphase durch separates Testen von Paketen<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
206
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Frage zu 3.5<br />
Welche Richtl<strong>in</strong>ien zur Bildung von Paketen s<strong>in</strong>d s<strong>in</strong>nvoll?<br />
Antwort<br />
Zusammenfassung von Klassen mit <strong>in</strong>tensiver Kommunikation<br />
f<br />
f<br />
<br />
Es müssen m<strong>in</strong>d. drei Pakete pro System existieren<br />
Paketname aus Namen <strong>der</strong> be<strong>in</strong>halteten Klassen ableiten<br />
<br />
Identifikation aus zusammengehörigen Anwendungsfällen<br />
<br />
Aggregationen, Kompositionen und Vererbungsstrukturen im selben<br />
Paket zusammenfassen<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
207
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Frage zu 3.5<br />
Unterteilen Sie die Klassen Reiseunterlagen, Reise<strong>in</strong>formation, Vertrag,<br />
Tourist und Katalog <strong>in</strong> die Pakete Reise und Kunden<strong>in</strong>formation.<br />
Antwort<br />
Reise<br />
Reiseunterlagen Reise<strong>in</strong>formation Vertrag<br />
Kunden<strong>in</strong>formation<br />
Tourist<br />
Katalog<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
208
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
Info 2 - GdS<br />
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong><br />
<strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
3.2 Assoziation<br />
3.3 Aggregation und Komposition<br />
3.4 Vererbung<br />
3.5 Paket<br />
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
3.7 Zusammenfassung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
209
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
Info 2 - GdS<br />
Weitere Arten von Restriktionen bei Assoziationen<br />
– subset-Restriktion<br />
subset- Restriktion bildet Teilmenge<br />
Existiert nur, wenn die Hauptassoziation auch existiert<br />
Sportler<br />
Teilnehmer<br />
*<br />
Sieger<br />
{subset}<br />
*<br />
0..1<br />
*<br />
Wettbewerb<br />
Sieger e<strong>in</strong>es Wettbewerbs muss<br />
auch Teilnehmer se<strong>in</strong><br />
s1: Sportler<br />
s2: Sportler<br />
s3: Sportler<br />
w1: Wettbewerb<br />
w2: Wettbewerb<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
210
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
Info 2 - GdS<br />
Abgeleitete Assoziation (<strong>der</strong>ived association)<br />
– Assoziation, <strong>der</strong>en konkrete Objektbeziehungen je<strong>der</strong>zeit aus den Werten<br />
an<strong>der</strong>er Objektbeziehungen und Objekte abgeleitet werden ( redundant)<br />
– wird durch das Präfix „/“ gekennzeichnet<br />
– Ableitungsvorschrift wird ggf. als Restriktion notiert<br />
Professor<br />
1<br />
liest<br />
*<br />
Vorlesung<br />
*<br />
l<br />
ist Hörer von<br />
*<br />
*<br />
*<br />
hört<br />
Student<br />
:Professor<br />
:Vorlesung<br />
:Student<br />
:Vorlesung<br />
:Student<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
211
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
Info 2 - GdS<br />
Verwendung von Assoziationen <strong>in</strong> Objektdiagrammen<br />
– Steigerung des Aussagegehalts e<strong>in</strong>es Objektdiagramms durch<br />
Verwendung von<br />
Rollennamen<br />
Assoziationsname bei Objektverb<strong>in</strong>dung optional, muss<br />
unterstrichen werden !<br />
Qualifikationsangaben<br />
Symbole für Aggregation bzw. Komposition (siehe Kap. 3.3)<br />
:Kunde<br />
Herbst/W<strong>in</strong>ter.Katalog<br />
Konto<strong>in</strong>haber<br />
Kontoberechtigter<br />
Bestellnummer<br />
:Konto<br />
Ski-Anorak:Artikel<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
212
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
Info 2 - GdS<br />
Höherwertige Assoziation<br />
– Pr<strong>in</strong>zipiell s<strong>in</strong>d auch Assoziationen zwischen drei und mehr Klassen<br />
möglich<br />
– Bezeichnung: n-äre Assoziation (n-ary association)<br />
– Ternäre und höhere Assoziationen können ke<strong>in</strong>e Aggregation o<strong>der</strong><br />
Komposition bilden<br />
Jahr<br />
*<br />
Vere<strong>in</strong><br />
*<br />
*<br />
Fußball-Spieler<br />
Ergebnis<br />
Anzahl Tore<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
213
Info 2 - GdS<br />
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong><br />
<strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
3.1 <strong>Statische</strong> vs. dynamische <strong>Konzepte</strong><br />
3.2 Assoziation<br />
3.3 Aggregation und Komposition<br />
3.4 Vererbung<br />
3.5 Paket<br />
3.6 Erweiterungsmechanismen <strong>der</strong> UML (zum Selbststudium)<br />
3.7 Zusammenfassung<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
214
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Zusammenfassung § 3<br />
– E<strong>in</strong>e Assoziation modelliert Verb<strong>in</strong>dungen zwischen Objekten e<strong>in</strong>er o<strong>der</strong><br />
mehrerer Klassen<br />
– Son<strong>der</strong>fälle <strong>der</strong> Assoziation s<strong>in</strong>d Aggregation und Komposition<br />
– Vererbung beschreibt die Beziehung zwischen e<strong>in</strong>er allgeme<strong>in</strong>en Klasse<br />
und e<strong>in</strong>er spezialisierten Klasse<br />
– E<strong>in</strong> Paket gruppiert Modellelemente und ermöglicht die Darstellung des<br />
Softwaresystems auf e<strong>in</strong>em höheren Abstraktionsniveau<br />
Vererbung<br />
Assoziation<br />
Gerichtete<br />
Assoziation<br />
Aggregation<br />
Komposition<br />
Assoziative<br />
Klasse<br />
Qualifizierte<br />
Assoziation<br />
Höherwertige<br />
Assoziation<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
215
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Frage zu § 3<br />
Beschreiben Sie <strong>in</strong> dem Klassendiagramm für e<strong>in</strong>e Kontoverwaltung die<br />
Beziehungen zwischen den Klassen !<br />
1 1..* 1 1..*<br />
Kunde<br />
Konto<br />
Kontobewegung<br />
Girokonto<br />
Sparkonto<br />
– Zwischen Kunde und Konto besteht e<strong>in</strong>e ___________________, e<strong>in</strong>fache Assoziation weil<br />
we<strong>der</strong> <strong>der</strong> Kunde ________ Teil von Konto ist, noch umgekehrt<br />
– Zwischen Konto und Kontobewegung existiert e<strong>in</strong>e Komposition, weil<br />
e<strong>in</strong>e ____________Beziehung whole-part-<br />
vorliegt: ___________________ dynamische Semantik e<strong>in</strong>es<br />
Kontos gilt stets für alle Kontobewegungen<br />
– Weil bei <strong>der</strong> Eröffnung e<strong>in</strong>es Kontos gleich e<strong>in</strong>e E<strong>in</strong>zahlung vorzunehmen<br />
ist, ist bei ______________die Kontobewegung Kard<strong>in</strong>alität 1..* e<strong>in</strong>getragen<br />
– Komposition von Konto zu Kontobewegung wird an beide Unterklassen<br />
vererbt, d.h.________________________________ jedes Sparkonto- und Girokonto-Objekt hat Kontobewegungen<br />
– Die Vererbung <strong>der</strong> Assoziation zu Kunde bedeutet, dass<br />
Verb<strong>in</strong>dungen<br />
___________ zwischen Kunde und Girokonto bzw. Sparkonto existieren<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
216
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Vorbereitungsfragen zu § 3<br />
Frage 1: Welche Aussagen zu Paketen s<strong>in</strong>d richtig? (WS 02/03)<br />
Antwort<br />
E<strong>in</strong>e Schnittstelle kann Bestandteil mehrerer Pakete se<strong>in</strong>.<br />
Existieren <strong>in</strong> zwei Paketen Klassen mit dem selben Namen, müssen die<br />
Paketnamen explizit angegeben werden.<br />
Pakete dienen als Strukturierungsmittel zur Aufteilung von großen<br />
Modellen.<br />
Pakete <strong>in</strong> <strong>der</strong> UML lassen sich nicht schachteln.<br />
Pakete müssen immer vone<strong>in</strong>an<strong>der</strong> unabhängig se<strong>in</strong>.<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
217
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Vorbereitungsfragen zu § 3<br />
Frage 2: Welche Aussagen zu Assoziation, Aggregation und<br />
Komposition s<strong>in</strong>d richtig? (WS 03/04)<br />
Antwort<br />
E<strong>in</strong>e Assoziation beschreibt die Beziehung zwischen den Objekten <strong>der</strong><br />
beteiligten Klassen.<br />
Aggregation und Komposition s<strong>in</strong>d Assoziationen.<br />
In e<strong>in</strong>er Komposition kann e<strong>in</strong> Objekt gleichzeitig Teil mehrerer<br />
Aggregatobjekte se<strong>in</strong>.<br />
Bei e<strong>in</strong>er Aggregation erbt die Teilklasse von <strong>der</strong> Aggregatklasse.<br />
Die Programmiersprache Java unterscheidet nicht zwischen Assoziation,<br />
Aggregation und Komposition.<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
218
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Vorbereitungsfragen zu § 3<br />
Frage 3: Welche <strong>der</strong> folgenden Aussagen zur Vererbung s<strong>in</strong>d richtig?<br />
(WS 06/07)<br />
Antwort<br />
Es ist möglich, sowohl von konkreten als auch von abstrakten Klassen<br />
Objekte zu erzeugen.<br />
E<strong>in</strong>e Unterklasse stellt e<strong>in</strong>e Spezialisierung ihrer Oberklasse dar.<br />
In e<strong>in</strong>er Komposition kann e<strong>in</strong> Objekt gleichzeitig Teil mehrerer<br />
Aggregatobjekte se<strong>in</strong>.<br />
Erben mehrere Unterklassen von e<strong>in</strong>er geme<strong>in</strong>samen Oberklasse, so<br />
spricht man von Mehrfachvererbung.<br />
E<strong>in</strong>e Oberklasse ist vollständig konsistent mit ihrer Unterklasse, enthält<br />
aber zusätzlich noch weitere Informationen.<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
219
§ 3 <strong>Statische</strong> <strong>Konzepte</strong> <strong>in</strong> <strong>der</strong> <strong>objektorientierten</strong> <strong>Analyse</strong><br />
Info 2 - GdS<br />
Vorbereitungsfragen zu § 3<br />
Frage 4: Welche <strong>der</strong> folgenden Aussagen zur <strong>objektorientierten</strong> <strong>Analyse</strong><br />
s<strong>in</strong>d richtig? (WS 06/07)<br />
Antwort<br />
In <strong>der</strong> <strong>Analyse</strong> wird festgelegt, was das System tun und wie es realisiert<br />
werden soll.<br />
Die <strong>Analyse</strong> ist stark mit <strong>der</strong> Implementierung verknüpft.<br />
In <strong>der</strong> <strong>Analyse</strong> wird e<strong>in</strong> Fachkonzept des zu realisierenden Systems<br />
erstellt.<br />
Das OOA-Modell besteht nur aus e<strong>in</strong>em statischen Modell.<br />
Die <strong>Analyse</strong> beschreibt den Problembereich aus Anwen<strong>der</strong>sicht.<br />
© 2013 IAS, <strong>Universität</strong> Stuttgart<br />
220
Change language