Objektorientierte Analyse und Design - beim Fachbereich Informatik ...
Objektorientierte Analyse und Design - beim Fachbereich Informatik ...
Objektorientierte Analyse und Design - beim Fachbereich Informatik ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
4.3 Aktivitätsdiagramme<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong>
4.3 Aktivitätsdiagramme<br />
Ausgangssituation<br />
n� Situation:<br />
ð� Use Cases- <strong>und</strong> Use Case Diagramme bieten adäquate Mittel<br />
zur Darstellung der funktionalen Anforderungen!<br />
- Aber die Abläufe sind in den Use Case -Templates nicht wirklich übersichtlich<br />
dargestellt<br />
- Parallele Vorgänge sind sprachlich schwer auszudrücken<br />
ð� Wie kann man Abläufe anschaulich beschreiben?<br />
- übersichtlich <strong>und</strong> leicht verständlich<br />
- inklusive Kontrollstrukturen (Schleifen <strong>und</strong> Bedingungen)<br />
- inklusive paralleler Ausführung von Teilabläufen (Concurrency)<br />
ð� Aktivitätsdiagramme<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 102
4.3 Aktivitätsdiagramme<br />
Notation am Beispiel: 'Essen zahlen'<br />
Startknoten<br />
Aktion<br />
Kontrollfluss(kante)<br />
Essen zahlen<br />
Verantwortungsbereich<br />
(swim lane)<br />
Synchronisations<br />
knoten<br />
Entscheidungs-<br />
knoten<br />
Endknoten<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 103
4.3 Aktivitätsdiagramme<br />
Notation am Beispiel: 'Betragsfunktion'<br />
Zahl<br />
Aktivität<br />
Betrag berechnen<br />
Parameter<br />
[Zahl < 0]<br />
[Zahl >= 0]<br />
Ergebnis<br />
[= -1*Zahl]<br />
Ergebnis<br />
[=Zahl]<br />
Objektknoten<br />
Ergebnis<br />
Zusammenführungsknoten<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 104
4.3 Aktivitätsdiagramme<br />
Tokenprinzip<br />
n� Aktivitätsdiagramme erlauben Verzweigungen des Kontrollflusses <strong>und</strong><br />
gleichzeitig ablaufende, parallele Pfade<br />
ð� Belege die aktiven Zweige mit je einer imaginären Marke ("Token") um zu<br />
verstehen, wie der Ablauf funktioniert !<br />
- Nachdem der Ablauf gestartet wurde, wird das erste Token erzeugt. Danach wird die Aktion a1 ausgeführt <strong>und</strong><br />
das Token auf den Ausgang von a1 gelegt. Durch die Verzweigung in die beiden Threads p1 <strong>und</strong> p2 wird am<br />
Anfang beider Threads je ein Token gesetzt. Die Aktionen p1 <strong>und</strong> p2 werden ausgeführt; die Tokens werden<br />
auf die Ausgänge von p1 <strong>und</strong> p2 gelegt. Erst wenn auch das Token über p3 gewandert ist <strong>und</strong> beide Tokens<br />
da sind, wird das Eingangstoken für a2 gestartet.<br />
Dann wird a2 ausgeführt, das Token auf den Ausgang von a2 gelegt, die Aktivität beendet <strong>und</strong> das Token<br />
vernichtet.<br />
1 2<br />
a1<br />
3<br />
3<br />
p1<br />
p2<br />
4<br />
p3<br />
5<br />
4<br />
6 7<br />
a2<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 105
4.3 Aktivitätsdiagramme<br />
Tokenprinzip am Beispiel: 'Essen zahlen' (erfolgreich)<br />
1<br />
2<br />
3<br />
7<br />
4<br />
6<br />
5<br />
8<br />
3<br />
9<br />
10<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 106
4.3 Aktivitätsdiagramme<br />
Elemente in Aktivitätsdiagrammen (I)<br />
Aktion ZZZ<br />
Aktivität XXX<br />
Ergebnis<br />
[=Basis]<br />
n� Aktion<br />
ð� Ist das Basiselement zur Spezifikation von Verhalten. Es beschreibt<br />
einen Einzelschritt wie z. B. "Summe berechnen"<br />
ð� Eine Aktion kann als nicht weiter zerlegbare Funktion angesehen<br />
werden. Sie transformiert eine Eingabe zu einer Ausgabe.<br />
n� Aktivität<br />
ð� Eine Aktivität setzt sich aus Aktionen <strong>und</strong> anderen Aktivitäten<br />
zusammen, die im Aktivitätsdiagramm enthalten sind.<br />
ð� Symbole in einer Aktivität stellen Aktionen dar aus denen die<br />
Aktivität aufgebaut ist <strong>und</strong> Pfeile den Kontrollfluss.<br />
n� Objektknoten<br />
ð� können in Aktivitätsdiagrammen Objekte oder Daten repräsentieren<br />
ð� Sie können als unabhängige Knoten in einem Diagramm benutzt<br />
werden, bzw. als Parameter für Aktionen (Input, Output Pin)<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 107
4.3 Aktivitätsdiagramme<br />
Elemente in Aktivitätsdiagrammen (II)<br />
[else]<br />
[x = 1]<br />
n� Entscheidungsknoten<br />
ð� Es wird eine der herausführenden Kontrollflusskanten<br />
weiterverfolgt (abhängig davon, welche Bedingung wahr ist).<br />
Zu jedem Zeitpunkt darf nur genau eine Bedingung wahr sein.<br />
n� Verbindungsknoten<br />
ð� Schaltet eine von mehreren hineinführenden<br />
Kontrollflusskanten, wird die herausführende<br />
Kontrollflusskante weiterverfolgt<br />
n� Synchronisationsknoten<br />
ð� Der aus dem Balken herausführende Ablauf kann nur dann<br />
weitergeführt werden, wenn alle einmündenden Abläufe<br />
beendet sind<br />
n� Splittingknoten<br />
ð� Aus dem Balken herausführende Abläufe können gleichzeitig,<br />
also parallel ausgeführt werden<br />
(Aufspaltung des Kontrollflusses in mehrere parallele Teile)<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 108
4.3 Aktivitätsdiagramme<br />
Anwendung<br />
n� Aktivitätsdiagramme<br />
ð� werden zur Modellierung von Abläufen <strong>und</strong> deren Steuerung benutzt<br />
ð� stellen die einzelnen Verfahrensschritte von Aktivitäten, zusammen mit der<br />
Reihenfolge in der sie ausgeführt werden, dar<br />
ð� können (durch Verantwortungsbereiche) die modellierten Aktionen bestimmten<br />
Modellelementen zuordnen<br />
ð� können von der Modellierung von Geschäftsprozessen bis zur Visualisierung von<br />
Kontrollflüssen benutzt werden<br />
Aktivitätsdiagramme können in einem Projekt überall verwendet<br />
werden, wo Verhalten beschrieben werden muss,<br />
bzw. wo Datenflüsse oder Kontrollflüsse modelliert werden sollen<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 109
4.3 Aktivitätsdiagramme<br />
Weiteres Beispiel: Geschäftsprozess 'Getränk bereiten'<br />
Kaffee-<br />
Maschine<br />
Kaffee<br />
brühen<br />
Suche<br />
Getränk<br />
Kaffee in<br />
Filter geben<br />
Maschine<br />
anschalten<br />
Kaffee<br />
eingießen<br />
Barkeeper Cola-Automat<br />
[kein Kaffeepulver<br />
vorhanden]<br />
Hole Dose<br />
Cola<br />
[Kaffeepulver vorhanden]<br />
Wasser<br />
eingießen<br />
Gast<br />
vertrösten<br />
Getränk<br />
aushändigen<br />
[Keine Cola<br />
vorhanden]<br />
Cola<br />
entnehmen<br />
[Cola<br />
vorhanden]<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 110
4.3 Aktivitätsdiagramme<br />
Notation in UML 2.x (I)<br />
The image cannot be displayed. Your computer may not have enough memory to open the image, or the<br />
image may have been corrupted. Restart your computer, and then open the file again. If the red x still<br />
appears, you may have to delete the image and then insert it again.<br />
The image cannot be displayed.<br />
Your computer may not have<br />
enough memory to open the<br />
image, or the image may have<br />
been corrupted. Restart your<br />
computer, and then open the file<br />
again. If the red x still appears,<br />
you may have to delete the<br />
Aktivität (Activity)<br />
Eine Aktivität besteht aus Knoten (Aktivitäten, Aktionen,<br />
Kontroll- <strong>und</strong> Objektknoten) <strong>und</strong> Kanten (Pfeilen), die den<br />
Kontrollfluss durch die Aktivität darstellen. Die Aktivität wird als<br />
abger<strong>und</strong>etes Rechteck dargestellt. In der linken, oberen Ecke<br />
steht der Name der Aktivität, gefolgt vom Eingangsparameter<br />
<strong>und</strong> Typ. Die Rechtecke an beiden Seiten geben die Eingangs-<br />
bzw. Ausgangsparameter an. Die Symbole in der Aktivität<br />
stellen die Aktionen dar <strong>und</strong> die Pfeile den Kontrollfluss.<br />
Aktion (Action)<br />
Eine Aktion ist in UML das Basiselement zur Spezifikation von<br />
Verhalten. Eine Aktion kann als nicht weiter zerlegbare<br />
Funktion angesehen werden. Sie transformiert eine Eingabe<br />
zu einer Ausgabe.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 111
4.3 Aktivitätsdiagramme<br />
Notation in UML 2.x (II)<br />
The image cannot be displayed. Your computer may not have enough<br />
memory to open the image, or the image may have been corrupted.<br />
Restart your computer, and then open the file again. If the red x still<br />
appears, you may have to delete the image and then insert it again.<br />
The image cannot be displayed.<br />
Your computer may not have<br />
enough memory to open the<br />
image, or the image may have<br />
been corrupted. Restart your<br />
computer, and then open the file<br />
again. If the red x still appears,<br />
you may have to delete the image<br />
and then insert it again.<br />
The image cannot be displayed. Your computer may not have enough<br />
memory to open the image, or the image may have been corrupted.<br />
Restart your computer, and then open the file again. If the red x still<br />
appears, you may have to delete the image and then insert it again.<br />
Start-, Endknoten, Ablaufende<br />
Ein Startknoten (Initial Node) stellt den Beginn eines Ablaufes dar. Ein<br />
Endknoten (Activity Final Node) beendet eine Aktivität vollständig. Ein<br />
Ablaufende (Flow Final Node) terminiert einen Zweig einer Aktivität, die<br />
Aktivität selbst läuft weiter.<br />
Pfeil/Kante<br />
Ein Pfeil beschreibt den Fluss zwischen den verb<strong>und</strong>enen Elementen.<br />
In einer eckigen Klammer kann eine Bedingung angegeben werden, die<br />
erfüllt sein muss, damit die Kante überquert wird.<br />
Entscheidung <strong>und</strong> Zusammenführung<br />
Bei der Entscheidung wird nach Eintreffen des Tokens a entweder nach<br />
b oder nach c verzweigt. Die Bedingung, die erfüllt sein muss, kann als<br />
Ausdruck in eckigen Klammern an den Pfeilen angegeben werden.<br />
Bei der Zusammenführung wird nach Eintreffen der Token a oder b<br />
nach c verzweigt.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 112
4.3 Aktivitätsdiagramme<br />
Notation in UML 2.x (III)<br />
The image cannot be displayed. Your computer may not have<br />
enough memory to open the image, or the image may have been<br />
corrupted. Restart your computer, and then open the file again. If<br />
the red x still appears, you may have to delete the image and<br />
then insert it again.<br />
The image cannot be displayed. Your<br />
computer may not have enough memory<br />
to open the image, or the image may<br />
have been corrupted. Restart your<br />
computer, and then open the file again. If<br />
the red x still appears, you may have to<br />
delete the image and then insert it again.<br />
Aufteilung (Splitting), Synchronisation<br />
Bei einem Splitting-Knoten wird in mehrere parallele Threads verzweigt<br />
(wenn a da ist, feuern b <strong>und</strong> c). Ein Synchronisationsknoten<br />
synchronisiert mehrere Threads (wenn a <strong>und</strong> b da sind, feuert c)<br />
Signal (Send signal action, Accept event action)<br />
Mit diesen Symbolen kann das Senden <strong>und</strong> Empfangen von Signalen<br />
dargestellt werden (z. B. „Polizei ruft an“ wäre ein empfangenes Signal<br />
bei Aktivität „Party feiern“).<br />
Zeitereignis (Accept time event action)<br />
Über diese Symbol wird ausgedrückt, dass eine Aktion zeitgesteuert<br />
angestoßen wird.<br />
Verantwortungsbereiche (Partitions, swim lanes)<br />
Zur Zuordnung der Aktionen einer Aktivität zu den verantwortlichen<br />
Elementen können Aktivitätsdiagramme in Partitionen (Activity Partition)<br />
unterteilt werden. Da ein entsprechend aufgeteiltes Diagramm wie eine<br />
in Bahnen eingeteiltes Schwimmbecken aussieht, werden die Activity<br />
Partitions oft auch swim lanes genannt.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 113
4.3 Aktivitätsdiagramme<br />
Notation in UML 2.x (IV)<br />
The image cannot be displayed. Your computer may not<br />
have enough memory to open the image, or the image may<br />
have been corrupted. Restart your computer, and then open<br />
the file again. If the red x still appears, you may have to<br />
delete the image and then insert it again.<br />
The image cannot be displayed. Your computer may not have<br />
enough memory to open the image, or the image may have been<br />
corrupted. Restart your computer, and then open the file again.<br />
If the red x still appears, you may have to delete the image and<br />
then insert it again.<br />
Objektknoten<br />
können in Aktivitätsdiagrammen Objekte oder Daten repräsentieren. Sie<br />
können als unabhängige Knoten in einem Diagramm benutzt werden,<br />
bzw. als Parameter für Aktionen (Input, Output Pin). Beide Darstellungen<br />
sind äquivalent. Im Bild oben ist a als Objekt eingezeichnet; im unteren<br />
Bild ist a Ausgangsparameter der linken Aktion <strong>und</strong> Eingangsparameter<br />
der rechten.<br />
Kanten<br />
verbinden die Aktionen in einem Diagramm <strong>und</strong> stellen den Fluss dar.<br />
Kanten, die Kontrollfluss modellieren, verbinden Aktionen direkt;<br />
Objektflusskanten verbinden die Pins der beteiligten Aktionen.<br />
Verfeinern von Aktivitäten<br />
Aktivitäten können in weiteren Aktivitätsdiagrammen verfeinert werden.<br />
Das zu verfeinernde Element wird mit einem Gabelsymbol<br />
gekennzeichnet <strong>und</strong> kann in einem Unterdiagramm verfeinert werden.<br />
Alle Aktivitäten sind auf der untersten Hierarchieebene auf Aktionen<br />
abzubilden.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 114
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
4.4 Alternative Beschreibung von Use Cases<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 115
4.4 Alternative Beschreibungen von Use Cases<br />
Möglichkeiten zur Beschreibung der Basic <strong>und</strong> Alternative Courses<br />
n� Zielsetzung Use Cases:<br />
ð� Beschreibung der Interaktion zwischen Benutzer(n) <strong>und</strong> einem System<br />
n� Bisherige Ausdrucksmittel:<br />
ð� normaler Text<br />
ð� strukturierter Text (pro Satz eine Aktion), in Tabellen<br />
n� Anforderungen<br />
ð� Möglichkeit zum Ausdruck von sequentiellen Abläufen zwischen System <strong>und</strong> der<br />
Außenwelt<br />
ð� If-Konstrukt für alternative Abläufe<br />
ð� Schleifen<br />
ð� Auslagern von Teilabläufen<br />
Das können Aktivitätsdiagramme auch!<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 116
4.4 Alternative Beschreibungen von Use Cases<br />
Aktivitätsdiagramme zur Beschreibung des Basic <strong>und</strong> Alternative Course<br />
Aktoren mit<br />
Kommunikation als<br />
Erweiterung zur<br />
UML-Norm für<br />
Aktivitätsdiagramme<br />
Alternative Course<br />
Ein-/Ausgabe<br />
Darstellung ist<br />
besonders geeignet<br />
bei parallelen Abläufen<br />
Darstellung von Angaben,<br />
die nichts mit der<br />
Schnittstelle zum Benutzer<br />
zu tun haben, aber deren<br />
Kenntnis wichtig für den<br />
Benutzer ist.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 117
K<strong>und</strong>e<br />
4.4 Alternative Beschreibungen von Use Cases<br />
Lösung: Aktivitätsdiagramme für Basic <strong>und</strong> Alternative Course<br />
Geld abheben<br />
PIN-Eingabe<br />
Betrag eingeben<br />
[PIN 1. oder 2.<br />
mal falsch]<br />
[PIN 3. mal falsch]<br />
[PIN gültig]<br />
Karte<br />
einschieben<br />
[Karte gültig] [Karte ungültig]<br />
Betrag<br />
abbuchen<br />
Fehlversuch<br />
protokollieren<br />
Fehlversuch<br />
protokollieren<br />
Karte<br />
ausgeben<br />
K<strong>und</strong>e<br />
benachrichtigen<br />
Karte<br />
einziehen<br />
Geld<br />
ausgeben<br />
Kommunikation<br />
teilweise nur<br />
angedeutet<br />
Fehlversuch<br />
protokollieren<br />
K<strong>und</strong>e<br />
benachrichtigen<br />
Karte<br />
ausgeben<br />
K<strong>und</strong>e<br />
benachrichtigen<br />
Farben dienen nur der<br />
Veranschaulichung!<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 119
4.4 Alternative Beschreibungen von Use Cases<br />
Fazit<br />
n� Die Beschreibung der Abläufe von Use Cases <strong>und</strong> die Modellierung der<br />
Use Cases eines Systems können auch in UML erfolgen<br />
n� aber<br />
ð� kein neues Sprach-Konstrukt zu erlernen<br />
ð� standardisierte Beschreibungsmittel<br />
ð� bessere Integration in Tools<br />
ð� die Verständlichkeit nimmt ab<br />
(versteht der K<strong>und</strong>e/Auftraggeber überhaupt Aktivitätsdiagramme?)<br />
ð� eine derartige Verwendung der UML ist nicht allgemein bekannt<br />
ð� es fehlen Ausdrucksmöglichkeiten für Stakeholder, Trigger, Guarantees,...<br />
Die meisten UML-Diagramme können zu<br />
unterschiedlichen Zwecken eingesetzt werden!<br />
Der Vorteil der „internationalen Sprache“ UML geht dann<br />
aber schnell verloren!<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 120
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
4.5 <strong>Analyse</strong>modell<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong>
4.5 <strong>Analyse</strong>modell<br />
<strong>Analyse</strong>modell<br />
n� Bei der Beschreibung der Anwendungsfälle stößt man auf materielle <strong>und</strong><br />
immaterielle Dinge (Objekte!) mit zu verwaltenden Informationen<br />
Modelliere diese Objekte der Domäne als Klassen<br />
mit Eigenschaften <strong>und</strong> Beziehungen<br />
ð� <strong>Analyse</strong>modell/Domänenmodell<br />
ð� Identifizieren von Objekten, Klassen, Attributen, Beziehungen<br />
ð� nur Klassen <strong>und</strong> Attribute, d. h. keine Operationen<br />
ð� keine Richtungen bei Beziehungen<br />
ð� evtl. Gemeinsamkeiten als Generalisierungsbeziehungen<br />
ð� evtl. weitere Eigenschaften der Klassen, die nicht in Diagrammform ausdrückbar<br />
sind, in Textform<br />
ð� die Klassen des <strong>Analyse</strong>modells/Domainmodells nennt man <strong>Analyse</strong>-/Domain-<br />
Klassen<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 122
4.5 <strong>Analyse</strong>modell<br />
<strong>Analyse</strong>klassendiagramm<br />
verallgemeinerte<br />
Datentypen<br />
keine Methoden<br />
Klassendiagramme werden im <strong>Design</strong>-Kapitel<br />
ausführlich behandelt!<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 123
4.5 <strong>Analyse</strong>modell<br />
Ergebnis des <strong>Analyse</strong>modells<br />
n� Statische Systemsicht<br />
ð� Klassendiagramme mit rudimentären Klassen (Domain-/<strong>Analyse</strong>klassen)<br />
ð� die zu Objekten gehören, die ein Anwender wahrnimmt<br />
ð� Erstellungsregeln:<br />
- jede Domainklasse muss in mindestens einem Anwendungsfall vorkommen<br />
- jede Domainklasse sollte mindestens ein Attribut haben<br />
- Domainklassen enthalten keine Realisierungsdetails einer potentiellen Lösung<br />
n� Dynamische Systemsicht<br />
ð� Aktivitätsdiagramme zur Verdeutlichung der Abläufe<br />
n� Das <strong>Analyse</strong>modell stellt einen ganz groben Entwurf für das <strong>Design</strong> dar<br />
ð� es dient der Verständigung zwischen Auftraggeber <strong>und</strong> -nehmer<br />
ð� die tatsächliche Umsetzung kann sich später deutlich unterscheiden<br />
ð� In der <strong>Design</strong>phase kommen weitere Diagramme hinzu (z. B. Zustands- &<br />
Komponentendiagramme)<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 124
4. <strong>Objektorientierte</strong> <strong>Analyse</strong><br />
Kontrollfragen<br />
ð� Welche Zielsetzung hat die Anforderungsanalyse?<br />
ð� Warum beschreibt man Anforderungen nicht in einer natürlichen Sprache?<br />
ð� Ist ein Dieb ein Stakeholder für einen Geldautomaten? Ein Aktor?<br />
ð� Was ist der Unterschied zwischen Include <strong>und</strong> Extend?<br />
ð� Wie stellt man Use Cases in UML dar?<br />
ð� Wie beschreibt man ein gesamtes System mit Use Cases?<br />
ð� Welche Beziehungen gibt es in der UML zwischen Use Cases?<br />
ð� Kann man Use Cases komplett in der UML beschreiben?<br />
ð� Was ist das Tokenprinzip?<br />
ð� Was sind „Swim Lanes“?<br />
ð� Was unterscheidet Zusammenführungsknoten von Synchronisationsknoten?<br />
ð� Was ist das <strong>Analyse</strong>modell?<br />
Sie wissen jetzt wie man die Ergebnisse einer<br />
objektorientierten <strong>Analyse</strong> dokumentiert !<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 125
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
5. <strong>Objektorientierte</strong>s <strong>Design</strong><br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong>
Die Idee ist das Absolute, <strong>und</strong> alles<br />
Wirkliche ist nur Realisierung der Idee.<br />
Georg W. F. Hegel<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 127
5. <strong>Objektorientierte</strong>s <strong>Design</strong><br />
Zur Erinnerung: Abstraktionsebenen<br />
gedankliche<br />
Ebene<br />
logische Ebene<br />
(Modell)<br />
physische Ebene<br />
(Implementierungsebene)<br />
Reale Welt<br />
OOA-Ebene<br />
OOD-Ebene<br />
Programm<br />
Abstraktion<br />
Implementierungskonzepte<br />
Codierung<br />
Abstraktionsebenen der objektorientierten Systementwicklung (4-Schichten-Modell)<br />
Arzt.cpp<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 128
5. <strong>Objektorientierte</strong>s <strong>Design</strong><br />
Zur Erinnerung: Phasenmodell der objektorientierten Systementwicklung<br />
Informationsgehalt<br />
reale Welt<br />
Abstraktion<br />
OOA<br />
(<strong>Analyse</strong>)<br />
<strong>Analyse</strong>-Modell<br />
Konkretisierung<br />
Abbildung<br />
OOD<br />
(<strong>Design</strong>)<br />
<strong>Design</strong>-<br />
Modell<br />
Isomorphismus<br />
OOP<br />
(Programmierung)<br />
Code<br />
Konsistenz<br />
Coderahmen<br />
Entwicklungs<br />
-phase<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 129
5. <strong>Objektorientierte</strong>s <strong>Design</strong><br />
Zwischenstand<br />
n� Sie ahnen jetzt<br />
ð� wie man die Welt der Anwendung analysiert <strong>und</strong><br />
ð� daraus Objekte <strong>und</strong> Klassen extrahiert<br />
n� Sie wissen jetzt<br />
ð� wie man die Ergebnisse dokumentiert<br />
- als textuelle Use Cases, als Use Case Diagramme (UML)<br />
- als Aktivitätsdiagramme (UML)<br />
- als <strong>Analyse</strong>modell<br />
n� Das ist alles recht abstrakt <strong>und</strong> hat wenig mit der Umsetzung zu tun !?<br />
ð� ergänze nun Umsetzungsdetails (Programmiersprache, Betriebssystem,...)<br />
ð� modifiziere die <strong>Analyse</strong>klassen<br />
- um weitere Klassen für die Realisierung<br />
- um Methoden, weitere Attribute<br />
ð� <strong>Objektorientierte</strong>s <strong>Design</strong><br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 130
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
5.1 Darstellung der Statik eines Systems<br />
5.1.1 Klassen <strong>und</strong> die UML<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong>
5.1.1 Darstellung der Statik eines Systems: Klassen <strong>und</strong> die UML<br />
Lernziele<br />
n� Sie sollen in diesem Kapitel verstehen,<br />
ð� wie man Klassen darstellt<br />
ð� wie man Klassen <strong>und</strong> deren Assoziationen findet<br />
ð� welche Arten von Beziehungen es zwischen Klassen gibt<br />
ð� Was Generalisierung <strong>und</strong> Spezialisierung ist<br />
ð� wie man Klassen <strong>und</strong> die Beziehungen zwischen Klassen in UML darstellt<br />
ð� wie man Klassen <strong>und</strong> Beziehungen in C++ umsetzt<br />
Hinterher können Sie Klassen <strong>und</strong> deren Beziehungen in<br />
einem Klassendiagramm darstellen!<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 132
5.1.1 Darstellung der Statik eines Systems: Klassen <strong>und</strong> die UML<br />
Darstellung von Klassen, Attributen <strong>und</strong> Methoden<br />
geschütztes Attribut<br />
privates Attribut<br />
öffentliches Attribut<br />
Klassenattribut<br />
Öffentliche Operation<br />
Klassenmethode<br />
Window<br />
# groesseX : Integer<br />
# groesseY : Integer<br />
- sichtbar : Boolean = TRUE<br />
+ position : (x : Integer, y : Integer)<br />
- standardGroesse: Flaeche<br />
+ darstellen_Icons ()<br />
+ maximieren ()<br />
+ minimieren ()<br />
# create ()<br />
+ veraendern_Groesse (offsetX, offsetY)<br />
+ ausgeben_Flaeche () : Flaeche<br />
Spezifikation<br />
Beschreibung...<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 133<br />
Typ<br />
Parameter<br />
Initialisierung<br />
Rückgabewert-Typ
5.1.1 Darstellung der Statik eines Systems: Klassen <strong>und</strong> die UML<br />
Darstellung von Klassen, Attributen <strong>und</strong> Methoden (II)<br />
n� Klassenmethode:<br />
ð� Bezieht sich nicht auf Instanz (Instanzmethode) sondern auf die Klasse als die<br />
Menge aller ihrer Objekte z. B. Konstruktor, Berechnung Durchschnittsgehalt etc.<br />
n� Klassenattribute:<br />
ð� Attributwert ist nicht einer Instanz (Instanzattribut) sondern der Klasse<br />
zugeordnet <strong>und</strong> existiert nur 1x für die Klasse, z. B. maxGeschwindigkeit eines<br />
Fahrzeugtyps.<br />
n� Spezifikation:<br />
ð� Text, der die Verantwortlichkeit/den Zweck einer Klasse, eines Attributs oder<br />
einer Methode beschreibt<br />
n� Methoden für das Schreiben <strong>und</strong> Lesen von Attributen:<br />
ð� setXXX, getXXX sind trivial ⇒ werden nicht in die Klassendefinition auf <strong>Analyse</strong>-<br />
Ebene aufgenommen<br />
n� Bei Verwendung eines CASE-Tools:<br />
ð� Einzelangaben können, um die Übersicht des Gesamtdiagramms zu erhöhen,<br />
ausgeblendet werden<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 134
5.1.1 Darstellung der Statik eines Systems: Klassen <strong>und</strong> die UML<br />
Wie findet man Kandidaten für Klassen (<strong>und</strong> Attribute)?<br />
n� Aus den Beschreibungen der Anwendungsfälle (Use Cases)!<br />
ð� Suche nach Substantiven (Kandidaten für Klassen, evtl. Attribute), z. B.<br />
- Personen, Orte, konkrete Dinge<br />
(Artikel, Rechnungen, Abteilung, Messwerte etc.)<br />
- Schnittstellen eines Systems<br />
(Masken, Anbindungen an Datenbanken etc.)<br />
- Abstrakte Dinge (ein Algorithmus, eine Information etc.)<br />
ð� Ordne nach Klassenkandidaten/Attributen zu Klassenkandidaten<br />
ð� Sondere überflüssige Klassenkandidaten aus!<br />
Ist K<strong>und</strong>e eine eigene Klasse oder nur eine Rolle in einer gemeinsamen Klasse?<br />
(z. B. Klasse Person mit Rollen: K<strong>und</strong>e, Vorgesetzter etc.)<br />
ð� Ergänze später im Lauf der Modellierung<br />
fehlende Klassen fallen auf, wenn man mit dem Modell arbeitet<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 135
5.1.1 Darstellung der Statik eines Systems: Klassen <strong>und</strong> die UML<br />
Wie findet man weitere Attribute <strong>und</strong> Methoden ?<br />
n� Attribute <strong>und</strong> Methoden ergeben sich aus<br />
ð� Beobachtungen des Anwendungsgebiets (der „Domäne“)<br />
- Attribute: Eigenschaften der Objekte<br />
- Methoden: Operationen auf den Objekten<br />
ð� oder aus der <strong>Analyse</strong> von Vorgängersystemen<br />
- Attribute: Einträge in Formularen, Bildschirmmasken, Datenmodell etc.<br />
- Methoden: Aktionen <strong>und</strong> Buttons in Formularen, Bildschirmmasken etc.<br />
ð� oder aus Anwendungsfällen (Use Cases)<br />
- Attribute: z. B. ...für jeden K<strong>und</strong>en wird das Alter erfasst...<br />
- Methoden: Suche Verben, die Aktionen auf den Objekten ausführen<br />
ð� <strong>und</strong> auch bei der Weiterarbeit mit dem Modell<br />
- fehlende Attribute <strong>und</strong> Methoden fallen auf, wenn man mit dem Modell arbeitet<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 136
5.1.1 Darstellung der Statik eines Systems: Klassen <strong>und</strong> die UML<br />
Wie findet man Klassen, Operationen <strong>und</strong> Attribute? Beispiel<br />
n� Aus der Beschreibung eines Anwendungsfalls:<br />
Ein Dauerauftrag überweist einen bestimmten Betrag in regelmäßigen<br />
Zeitabständen von einem Girokonto auf ein Anderes.<br />
Der Dauerauftrag gehört immer zu einem bestimmten Girokonto. Daueraufträge<br />
können angelegt <strong>und</strong> wieder gelöscht werden.<br />
ð� Dauerauftrag<br />
ð� Betrag<br />
ð� Zeitabstand<br />
ð� Girokonto<br />
ð� Anderes (Girokonto)<br />
ð� Überweisen<br />
ð� Anlegen<br />
ð� Löschen<br />
Klasse<br />
Attribut in Klasse Dauerauftrag<br />
Attribut in Klasse Dauerauftrag<br />
Klasse!? Assoziation von Dauerauftrag? Oder Attribut?<br />
Assoziation von Dauerauftrag? Oder Attribut?<br />
Operation in Klasse Dauerauftrag? Oder Girokonto?<br />
Operation in Klasse Dauerauftrag? Oder Konstruktor?<br />
Operation in Klasse Dauerauftrag? Oder Destruktor?<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 137
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
5.1.2 Darstellung der Statik eines Systems:<br />
Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong>
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Gr<strong>und</strong>idee Generalisierung<br />
n� Aus der Menge der Klassen sucht man<br />
nach Klassenpaaren wobei:<br />
ð� Die eine Klasse („Superklasse“) ist<br />
ein allgemeiner Typ <strong>und</strong> die<br />
andere Klasse („Subklasse“) ist ein<br />
spezieller Typ, der die<br />
Superklasse erweitert<br />
ð� Es besteht eine Ist-Ein-Beziehung!<br />
ð� Ein Objekt der Superklasse ist<br />
durch ein Objekt der Subklasse<br />
ersetzbar!<br />
ð� Unter der Subklasse ist eine<br />
Teilmenge der Menge der<br />
Instanzen der Superklasse<br />
angesiedelt<br />
Konto<br />
Kontonummer<br />
KontoStand<br />
GeldAbheben<br />
GeldEinzahlen<br />
Girokonto<br />
Kontonummer<br />
KontoStand<br />
ÜberziehungsLimit<br />
Sparkonto<br />
Kontonummer<br />
KontoStand<br />
Sperrfrist<br />
GeldAbheben<br />
GeldEinzahlen<br />
SetzeSperrfrist<br />
LeseSperrfrist<br />
GeldAbheben<br />
GeldEinzahlen<br />
PrüfeÜberziehungsLimit<br />
SetzeÜberziehungsLimit<br />
LeseÜberziehungsLimit<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 139
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Begriffe<br />
n� Generalisierung:<br />
ð� „Ist-ein-Beziehung“ von der Subklasse aus gesehen.<br />
ð� Ein Konto ist ein (verallgemeinertes) Girokonto<br />
n� Spezialisierung:<br />
ð� „Ist-ein-Beziehung“ von der Superklasse aus gesehen<br />
ð� Ein Girokonto ist ein (spezialisiertes) Konto<br />
ð� Die spezielle Klasse besitzt alle<br />
Merkmale der Superklasse<br />
n� Vererbung:<br />
ð� ist ein Konzept der Programmierung.<br />
Die Subklasse übernimmt („erbt“)<br />
alle Merkmale von der Superklasse<br />
Girokonto<br />
ÜberziehungsLimit<br />
Konto<br />
Kontonummer<br />
KontoStand<br />
GeldAbheben<br />
GeldEinzahlen<br />
PrüfeÜberziehungsLimit<br />
SetzeÜberziehungsLimit<br />
LeseÜberziehungsLimit<br />
ð� Die Subklasse besitzt alle Merkmale (Attribute, Operationen, Assoziationen,<br />
Aggregationen) der Superklasse <strong>und</strong> noch zusätzliche Merkmale<br />
Sparkonto<br />
Sperrfrist<br />
SetzeSperrfrist<br />
LeseSperrfrist<br />
GeldAbheben<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 140
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Beispiel: Vererbungshierarchie<br />
Pumpe<br />
Ansaugdruck<br />
Auslassdruck<br />
Durchflussmenge<br />
Zentrifugalpumpe<br />
Schaufeldurchmesser<br />
Zahl der Schaufeln<br />
Rotationsachse<br />
Gerät<br />
Name<br />
Hersteller<br />
Gewicht<br />
Preis<br />
Wärmetauscher<br />
Oberfläche<br />
Behälterdurchmesser<br />
Behälterlänge<br />
Behälterdruck<br />
Manteldruck<br />
Membranpumpe<br />
Membranmaterial<br />
...<br />
Welche Attribute<br />
besitzt eine<br />
Membranpumpe ?<br />
Kolbenpumpe<br />
Kolbenlänge<br />
Kolbendurchmesser<br />
Zahl der Zylinder<br />
Pumpe, Tank, etc. als<br />
spezielle Geräte mit<br />
Zusatzeigenschaften<br />
Tank<br />
Volumen<br />
Druck<br />
Durchmesser<br />
Höhe<br />
...<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 141
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Lösung: Welche Attribute besitzen die Objekte der Klassen?<br />
Instanzen:<br />
:Membranpumpe<br />
Name = P101<br />
Hersteller = Simplex<br />
Gewicht = 100 kg<br />
Preis = 8.000 €<br />
Ansaugdruck = 1,1 atm<br />
Auslassdruck = 3,3 atm<br />
Durchflussrate = 300 l/h<br />
Membranmat. = Teflon<br />
:Wärmetauscher<br />
Name = E302<br />
Hersteller = Braun<br />
Gewicht = 5000 kg<br />
Preis = 30.000 €<br />
Oberfläche = 300 m<br />
Behälterdurchm. = 2 cm<br />
Behälterlänge = 6 m<br />
Behälterdruck = 15 atm<br />
Manteldruck = 1,7 atm<br />
:Tank<br />
Name = T111<br />
Hersteller = Simplex<br />
Gewicht = 10.000 kg<br />
Preis = 80.000 €<br />
Volumen = 400.000 l<br />
Druck = 1,1 atm<br />
Durchmesser = 8 m<br />
Höhe = 9 m<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 142
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Sichtbarkeit<br />
n� Man unterscheidet 4 verschiedene Sichtbarkeitsstufen:<br />
ð� Public: für alle anderen Klassen sichtbar, d. h. öffentlich<br />
(in der UML: + )<br />
ð� Private: außerhalb der Klasse nicht sichtbar, auch nicht für Unterklassen<br />
(in der UML: – )<br />
ð� Protected: nur für alle Unterklassen sichtbar<br />
(in der UML: # )<br />
ð� Package: nur für Klassen im gleichen Paket („Ordner“) sichtbar<br />
(in der UML: ~ )<br />
n� innerhalb einer Generalisierung-/Spezialisierungshierarchie<br />
ð� können verschiedene Stufen der Sichtbarkeit eingesetzt werden<br />
Wegen der Kapselung<br />
sind Attribute in der<br />
Regel Private oder<br />
Protected!<br />
ð� „kennt“ jede Klasse nur ihre eigenen Attribute, Operationen <strong>und</strong> Beziehungen<br />
<strong>und</strong> die ihrer Oberklassen – sofern diese für sie sichtbar sind<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 143
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Regeln<br />
n� In Subklassen dürfen nicht nur zusätzliche Merkmale<br />
definiert werden, sondern auch geerbte Merkmale<br />
überschrieben werden:<br />
n� Aber:<br />
- Operationen (Reimplementierung/Polymorphie)<br />
- Einschränkungen von Attribut-Typen auf Untertypen (int statt float)<br />
- Einschränkungen der Typen oder Wertebereiche von Argumenten <strong>und</strong><br />
Rückgabewerten von Operationen<br />
ð� In der Subklasse können Berechnungen spezialisiert werden:<br />
z. B. kann die Operation GeldAbheben der Klasse Girokonto zusätzlich das<br />
Überziehungslimit prüfen<br />
Durch Überschreiben darf nie die Semantik des Attributs bzw.<br />
der Operation geändert werden!<br />
(Die Ist-ein-Beziehung darf nie verletzt werden!)<br />
Wie kann man das in einer<br />
Programmiersprache<br />
umsetzen?<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 144
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Einschränkungen bezüglich des Überschreibens der Merkmale (I)<br />
n� Integritätsbedingungen einer Klasse dürfen nicht verletzt werden:<br />
ð� Wenn eine Klasse eine bestimmt Bedingung vorschreibt, muss diese Bedingung<br />
in der abgeleiteten Klasse auch gelten<br />
ð� Beispiel: Ellipse-Kreis – Wer erbt von wem?<br />
- Eine Ellipse ist keine Spezialisierung eines Kreises, da die Kreiseigenschaft zweier<br />
gleichlanger Achsen durch die Ellipse verletzt würde. Ein Kreis ist jedoch eine<br />
spezielle Ellipse, bei der die Achsen gleich lang sind.<br />
n� Überschreiben von Methoden<br />
ð� Andere Implementierungen (z. B. Performance-Verbesserung) mit gleicher<br />
Funktionalität sind erlaubt.<br />
ð� Die Schnittstelle (Name, Anzahl von Argumenten) der Operation der Superklasse<br />
muss jedoch eingehalten werden.<br />
ð� Typen von Argumenten <strong>und</strong> Rückgabewerten dürfen nur eingeschränkt werden<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 145
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Einschränkungen bezüglich des Überschreibens der Merkmale (II)<br />
n� Der Typ eines Attributs der Subklasse muss vom Typ der Superklasse<br />
isomorph umschlossen sein<br />
ð� z. B.: Superklasse Attribut von Typ REAL<br />
in Subklasse Attribut von Typ INTEGER<br />
ð� z. B.: Superklasse Attribut von Typ der Klasse KONTO<br />
in Subklasse Attribut von Typ einer Subklasse<br />
von KONTO (z. B. GIROKONTO)<br />
n� Der Wertebereich von Attributen darf eingeschränkt,<br />
jedoch nicht erweitert werden<br />
ð� z. B.: Superklasse Mitarbeiter: Gehalt 1... 150.000,- €<br />
Subklasse Arbeiter: Gehalt 1... 80.000,- €<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 146
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Gleiche Eigenschaften – aber keine Generalisierung<br />
n� 2 Klassen haben gleiche Attribute, Operationen...<br />
ð� Dann kann man die gemeinsamen Merkmale in eine Superklasse extrahieren!?<br />
n� Achtung! Es muss eine „ist-ein-Beziehung“ bestehen!<br />
ð� Die Generalisierung darf nicht zur reinen Vereinfachung der Implementierung<br />
missbraucht werden!<br />
n� 1. Beispiel: Klasse Rollstuhl <strong>und</strong> Klasse Kraftfahrzeug:<br />
ð� Gleiche Attribute: Gewicht, Anzahl Räder, Farbe; Operation: fortbewegen<br />
ð� Kraftfahrzeug besitzt zusätzliches Attribut kW<br />
ð� Aber: trotzdem ist ein Kraftfahrzeug keine Spezialisierung eines Rollstuhls.<br />
n� 2. Beispiel: Klasse See <strong>und</strong> Klasse Papierformat:<br />
ð� Gleiche Attribute: Breite <strong>und</strong> Länge<br />
ð� Dieselben Attribute, aber:<br />
es liegt keine „ist-ein-Beziehung“ vor; aus semantischer Sicht<br />
haben die Klassen keine (sinnvolle) gemeinsame Superklasse<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 147
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung <strong>und</strong> Vererbung<br />
Darstellung von Randbedingungen für Vererbung/Mehrfachvererbung<br />
Constraints<br />
{overlapping, complete}<br />
Fahrzeug<br />
Luftfahrzeug Landfahrzeug Wasserfahrzeug<br />
{disjoint, incomplete} {disjoint, incomplete}<br />
Lastwagen<br />
Amphibienfahrzeug<br />
Segelboot<br />
Default: {overlapping, incomplete} – wird meist weggelassen<br />
Constraints<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 148
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
5.1.3 Darstellung der Statik eines Systems:<br />
Spezielle Klassen<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong>
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Abstrakte Klassen (I)<br />
n� Eine abstrakte Klasse ist eine spezielle Art von Klasse, von der niemals<br />
Instanzen erzeugt werden; sie ist bewusst unvollständig <strong>und</strong> bildet die Basis für<br />
weitere Unterklassen, die Exemplare haben können<br />
n� Eine abstrakte Klasse<br />
ð� beinhaltet mindestens eine abstrakte Operation<br />
ð� wird in C++ durch eine Klasse umgesetzt, die mindestens eine pure virtual<br />
Methode enthält<br />
ð� kann Default-Implementierungen enthalten<br />
n� Wozu ?<br />
ð� um davon andere Klassen abzuleiten!<br />
Abstrakte Klassen werden durch das<br />
Schlüsselwort abstract markiert – oder<br />
auch durch Kursivschreiben des Namens!<br />
ð� Klassenhierarchien sind „Begriffshierarchien“ – abstrakte Klassen definieren<br />
Oberbegriffe für Klassenhierarchien <strong>und</strong> setzen somit Begriffe <strong>und</strong> Standards fest<br />
ð� Abstrakte Klassen definieren den Kern einer Klassenhierarchie, d. h. die<br />
zentralen Gemeinsamkeiten!<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 150
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Abstrakte Klassen (II)<br />
n� Klassen, die nicht abstrakt sind <strong>und</strong> Instanzen bilden können, werden<br />
konkrete Klassen genannt.<br />
n� Konkrete Klassen, die von abstrakten Klassen erben, definieren alle abstrakten<br />
Operationen ihrer Superklassen, d. h. sie implementieren Methoden dafür.<br />
ð� Polymorphie<br />
gleiche Methoden anwendbar auf unterschiedliche Objekte<br />
(innerhalb einer Vererbungshierarchie)<br />
ð� dynamisches/spätes Binden<br />
Die Verknüpfung zwischen Methodenaufruf <strong>und</strong> Methodenimplementierung findet<br />
erst zur Laufzeit statt<br />
(Wird nicht von allen Sprachen unterstützt!)<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 151
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Abstrakte Klassen (Beispiel)<br />
{overlapping, complete}<br />
Luftfahrzeug Landfahrzeug Wasserfahrzeug<br />
{disjoint, incomplete} {disjoint, incomplete}<br />
Lastwagen<br />
fortbewegen()<br />
Fahrzeug<br />
{abstract}<br />
fortbewegen() {abstract}<br />
Amphibienfahrzeug<br />
fortbewegen()<br />
Segelboot<br />
fortbewegen()<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 152
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Schnittstelle: Definition<br />
n� Eine Schnittstelle (Interface) ist ein Modellierungselement, das mit Signaturen<br />
einen ausgewählten Teil eines extern sichtbaren Verhaltens beschreibt.<br />
Es gibt bereitgestellte <strong>und</strong> benötigte Schnittstellen.<br />
n� Ein Schnittstelle<br />
ð� legt durch Signaturen eine Schnittstelle für mehrere Klassen fest<br />
ð� kann nicht instanziiert werden<br />
ð� beinhaltet keine Implementierung<br />
ð� ist mit dem Stereotyp «interface» im Kopf gekennzeichnet<br />
ð� enthält in der Regel keine Attribute (darf es aber prinzipiell)<br />
ð� wird in C++ durch eine Klasse umgesetzt, die nur pure virtual Methoden enthält<br />
ð� wird realisiert, indem Klassen von der Schnittstellen ableiten <strong>und</strong> dann die<br />
Methoden implementieren<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 153
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Schnittstelle: Notation<br />
n� Bereitstellung <strong>und</strong> Verwendung einer Schnittstelle<br />
n� oder alternativ<br />
Anbieter<br />
bereitgestellte<br />
Schnittstelle<br />
«interface»<br />
Anbieter Nutzer<br />
Schnittstelle_A<br />
« implements »<br />
Schnittstelle_A<br />
hängt ab von<br />
Nutzer<br />
benötigte<br />
Schnittstelle<br />
« depends »<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 154
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Schnittstelle: Zweck<br />
n� Wozu ?<br />
ð� Schnittstellen definieren einen Teil der Außenschnittstelle,<br />
d. h. eine Zugriffsmöglichkeit, die mehrere Klassen gemeinsam nutzen<br />
ð� Es werden Operationen (<strong>und</strong> nicht die Methoden!) definiert, wobei die Aufrufer<br />
der Operationen zum Zeitpunkt der Definition der Schnittstelle evtl. noch nicht<br />
bekannt sind<br />
n� Beispiel<br />
ð� Wenn Sie unter Windows ein Programm schreiben, das sich an die normalen<br />
Mechanismen zur Umschaltung von Fenstern halten soll, müssen Sie bestimmte<br />
Methoden implementieren, damit das Verschieben <strong>und</strong> Überlappen der Fenster<br />
funktioniert (z. B. redraw)<br />
Diese Methoden sind in einem Interface innerhalb Windows definiert – aber die<br />
Implementierung müssen Sie machen!<br />
Windows<br />
Iwindow<br />
MyApp<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 155
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Schnittstelle: Beispiel<br />
Mensch<br />
fortbewegen()<br />
«interface»<br />
Bewegung<br />
fortbewegen()<br />
Vogel<br />
fortbewegen()<br />
Segelboot<br />
fortbewegen()<br />
Erkennen Sie den Unterschied zwischen<br />
Schnittstellen <strong>und</strong> abstrakten Klassen?<br />
Fahrzeug<br />
{abstract}<br />
fortbewegen() {abstract}<br />
abstrakte Klasse<br />
Luftfahrzeug Landfahrzeug Wasserfahrzeug<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 156
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Schnittstelle oder abstrakte Klasse?<br />
n� Eine abstrakte Klasse, die ausschließlich abstrakte Methoden enthält,<br />
ist identisch zu einer Schnittstelle<br />
ð� auch wenn die Konzepte sehr ähnlich sind, gibt es gr<strong>und</strong>legende Unterschiede<br />
Kern oder Rand<br />
Implementierung<br />
von Methoden<br />
Erweiterung der<br />
Funktionalität um<br />
eine neue Methode<br />
Schnittstelle Abstrakte Klasse<br />
Schnittstellen definieren die<br />
Außenschnittstelle einer Klasse,<br />
d. h. lediglich eine<br />
Zugriffsmöglichkeit, die mehrere<br />
Klassen nutzen können<br />
kein Code erlaubt; lediglich<br />
Festlegung von Signaturen<br />
Alle Implementierungen der<br />
Schnittstelle müssen aufgef<strong>und</strong>en<br />
<strong>und</strong> um die neue Methode erweitert<br />
werden<br />
Abstrakte Klassen beschreiben den<br />
Kern einer Vererbungshierarchie,<br />
den alle Spezialisierungen<br />
gemeinsam haben<br />
Code ist erlaubt; kann von erbenden<br />
Klassen überschrieben werden<br />
Durch Vererbung einer Default-<br />
Implementierung können alle<br />
erbenden Klassen leicht mit einer<br />
Implementierung versorgt werden<br />
Auszug aus: Rahman Mahmoodi "Abstract Class versus Interface"<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 157
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Parametrisierte Klassen (Templates) (I)<br />
n� Eine parametrisierbare Klasse ist eine mit<br />
generischen formalen Parametern versehene<br />
Schablone, mit der gewöhnliche (d. h. nicht-<br />
generische) Klassen erzeugt werden können.<br />
Die generischen Parameter dienen als Stell-<br />
vertreter für die echten Parameter, die<br />
Klassen oder einfache Datentypen<br />
repräsentieren.<br />
Fixed_List<br />
wurzel: T*<br />
cursor: T*<br />
eintrag T [0 .. max]<br />
n� Beispiel:<br />
Die parametrisierte Klasse Fixed_List hat die generischen Parameter T <strong>und</strong> max<br />
(eine Integerzahl). Eine Konkretisierung dieser Klasse muss max <strong>und</strong> T mit<br />
entsprechenden Daten belegen. Zum Beispiel max als 5 <strong>und</strong> T als int<br />
n� Anwendung:<br />
Standardalgorithmen <strong>und</strong> Datenstrukturen mit variablen Datentypen,<br />
z. B. Graphen, Bäume, Listen, Sortierungen, Suche<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 158<br />
...<br />
T,<br />
max: int
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen<br />
Parametrisierte Klassen (Templates) (II)<br />
n� Eine parametrisierte Klasse kann nicht direkt von anderen Klassen benutzt<br />
werden. Ihre generischen Parameter müssen erst an einen konkreten Typ<br />
„geb<strong>und</strong>en“ werden. Diese geb<strong>und</strong>enen Klassen können dann von anderen<br />
Klassen assoziiert werden.<br />
n� Bei der Definition einer Instanz einer parametrisierten Klasse müssen die<br />
Parameter konkretisiert werden. Zur Compilierzeit sind die möglichen Typen<br />
bekannt.<br />
FesteZahlen<br />
Liste<br />
«bind»<br />
< T -> int, max->20 ><br />
Fixed_List<br />
wurzel: T*<br />
cursor: T*<br />
eintrag T [0.. max]<br />
...<br />
FestePersonen<br />
Liste<br />
«bind»<br />
< T -> Person, max->100 ><br />
T, max: int<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 159
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
5.1.4 Darstellung der Statik eines Systems:<br />
Durchgängiges Beispiel<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 160
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel<br />
Durchgängiges Beispiel<br />
n� In diesem Abschnitt werden die theoretisch eingeführten Konzepte mit Hilfe<br />
eines Beispiels detailliert erläutert. Das Beispiel ist so gewählt, dass es durch<br />
das gesamte Kapitel weiterentwickelt <strong>und</strong> zu einem konsistenten<br />
objektorientierten Modell integriert wird.<br />
n� Die aufeinander aufbauenden Teile des Beispiels in den einzelnen Abschnitten<br />
sind so formuliert, dass die Ziele, die zu erreichen sind, in Form einer<br />
Aufgabenstellung beschrieben werden. Danach folgt die fachliche Beschreibung<br />
der zu modellierenden Inhalte.<br />
n� Sie sollten die Lösung selbst erarbeiten.<br />
Die Lösung wird aber direkt im Anschluss präsentiert.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 161
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel<br />
Aufgabe<br />
n� Analysieren Sie die nachfolgenden verbal formulierten Anforderungen an das<br />
System „Hochschulverwaltung“:<br />
ð� Identifizieren Sie die Klassen des Problembereichs (Domäne) <strong>und</strong> ihre Attribute<br />
durch Textanalyse.<br />
ð� Identifizieren Sie die Generalisierungs-/Spezialisierungs-Beziehungen zwischen<br />
den Klassen.<br />
ð� Integrieren Sie die Klassen zu einer Vererbungshierarchie (Klassendiagramm).<br />
n� Anforderungen:<br />
ð� In einer Hochschulverwaltung sind mehrere Personengruppen tätig. Die<br />
Hochschule hat Angestellte, die Professoren, Labor-Ingenieure, Lehrbeauftragte,<br />
Sekretärinnen oder Tutoren sein können. An einer Hochschule studieren<br />
Studenten, die auch als Tutoren in einzelnen Lehrveranstaltungen eingesetzt<br />
werden können. Jede Person hat einen Namen, Geburtsdatum <strong>und</strong> Geburtsort.<br />
Alle Angestellten verfügen über ein Gehaltskonto. Dozenten haben einen<br />
akademischen Titel <strong>und</strong> leisten pro Semester eine bestimmte Anzahl<br />
Semesterwochenst<strong>und</strong>en (SWS).<br />
Jeder Student hat eine identifizierende Matrikelnummer.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 162
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel<br />
Lösungsweg zu den Klassen <strong>und</strong> Attributen<br />
n� Zur Identifizierung der Klassenkandidaten wird zunächst eine Liste aller<br />
Substantive der Problembeschreibung erstellt:<br />
ð� ð� ð� Hochschulverwaltung, Personengruppen, Hochschule, Angestellte, Professoren,<br />
Labor-Ingenieure, Lehrbeauftragte, Sekretärinnen, Tutoren, Studenten, Person,<br />
Namen, Geburtsdatum, Geburtsort, Gehaltskonto, Dozenten, Titel, Semester, Semester, Anzahl,<br />
Semesterwochenst<strong>und</strong>en, Anzahl, Semesterwochenst<strong>und</strong>en, Matrikelnummer.<br />
Matrikelnummer<br />
n� Dann werden überflüssige Begriffe (red<strong>und</strong>ant oder irrelevant) eliminiert:<br />
ð� Hochschulverwaltung, Personengruppen, Hochschule, Semester, Anzahl<br />
n� Folgende Begriffe werden als Klassenkandidaten eliminiert, weil sie<br />
Eigenschaften (Attribute) anderer Substantive (Klassenkandidaten) bezeichnen:<br />
ð� Namen, Geburtsdatum, Geburtsort, Gehaltskonto, Titel,<br />
Semesterwochenst<strong>und</strong>en, Matrikelnummer.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 163
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel<br />
Lösung: Klassen <strong>und</strong> Attribute<br />
n� Daraus ergibt sich dann folgende grobe Klassenstruktur mit Attributen<br />
Klasse Attribute<br />
Person Name, Geburtsdatum, Geburtsort<br />
Student Matrikelnummer<br />
Angestellter Gehaltskonto<br />
Tutor<br />
Dozent Titel, Semesterwochenst<strong>und</strong>en<br />
Sekretärin<br />
Labor-Ingenieur<br />
Professor<br />
Lehrbeauftragter<br />
Studentischer Tutor<br />
ð� Selbstverständlich haben noch andere Klassen Attribute. Diese sind aber den<br />
Dokumenten (Anforderungen), die in dieser Projektphase (<strong>Analyse</strong>) vorliegen, noch<br />
nicht zu entnehmen. Deswegen werden sie zunächst offen gelassen <strong>und</strong> in<br />
späteren Projektphasen ergänzt (iterativer Entwicklungsprozess).<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 164
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel<br />
Zwischenschritt: Darstellung der Klassen<br />
Student<br />
# Matrikelnr : Integer<br />
studentischer<br />
Tutor<br />
Person<br />
# Name : String<br />
# GebDatum : Datum<br />
# Geburtsort : String<br />
Tutor<br />
{abstract}<br />
Dozent<br />
{abstract}<br />
# akademTitel : String<br />
# SWS : Integer<br />
+ Vergütung () {abstract}<br />
Angestellter<br />
{abstract}<br />
# Gehaltskonto<br />
+ Vergütung () {abstract}<br />
Professor Lehrbeauftragter<br />
Sekretärin<br />
Gibt es<br />
Generalisierungsbeziehungen?<br />
Lab-Ing<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 165
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel<br />
Lösung als Klassendiagramm<br />
Student<br />
# Matrikelnr : Integer<br />
studentischer<br />
Tutor<br />
Person Person {abstract}<br />
# Name : String<br />
# GebDatum : Datum<br />
# Geburtsort : String<br />
Tutor<br />
{disjoint, complete}<br />
Dozent<br />
{abstract}<br />
# akademTitel : String<br />
# SWS : Integer<br />
+ Vergütung () {abstract}<br />
Angestellter<br />
{abstract}<br />
# Gehaltskonto<br />
+ Vergütung () {abstract}<br />
Professor Lehrbeauftragter<br />
{overlapping}<br />
Sekretärin<br />
Lab-Ing<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 166
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel<br />
Offene Punkte<br />
n� Was passiert, wenn ein Student eine Tutorenstelle annimmt?<br />
ð� Das Objekt „Student“ müsste zerstört <strong>und</strong> ein neues Objekt der Klasse<br />
„StudentischerTutor“ erzeugt <strong>und</strong> mit denselben Daten belegt werden.<br />
n� Was passiert, wenn ein Labor-Ingenieur einen Lehrauftrag erhält?<br />
ð� dann stimmt das „disjoint“ nicht mehr<br />
ð� es gibt keine Klasse für diese Konstruktion<br />
Wie können diese Sachverhalte geschickter modelliert werden?<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 167
5.1.1 Darstellung der Statik eines Systems: Klassen <strong>und</strong> die UML<br />
Zwischenstand Klassen(diagramme)<br />
n� Klassendiagramme – behandelte Themen<br />
ð� Finden von Klassen<br />
ð� Bestandteile einer Klasse (Attributen <strong>und</strong> Operationen)<br />
ð� Sichtbarkeit<br />
ð� Vererbung/Generalisierung/Spezialisierung<br />
ð� Abstrakte Klasse<br />
ð� Schnittstelle<br />
ð� Parametrisierte Klasse<br />
ð� Offen: welche Beziehungen gibt es außer der Vererbung zwischen Klassen?<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 168
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
5.1.5 Darstellung der Statik eines Systems:<br />
Assoziationen<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 169
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Gr<strong>und</strong>idee<br />
n� Beobachtung:<br />
ð� Zwischen Objekten gibt es häufig Beziehungen – die Objekte „kennen sich“<br />
ð� Viele der Beziehungen gelten für alle Objekte einer Klasse<br />
n� Idee: Abstrahiere gleichartige Beziehungen zwischen Objekten<br />
zu Beziehungen zwischen Klassen!<br />
(analog zur Abstraktion von gleichartigen Objekten zu Klassen)<br />
n� „Assoziationen“<br />
ð� stellen logische Beziehungen zwischen Klassen dar;<br />
die Klassen „kennen sich“<br />
ð� sind Verknüpfungsmöglichkeiten zwischen Objekten dieser Klassen<br />
ð� definieren ebenso mögliche Kommunikationswege zwischen Objekten der<br />
Klassen.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 170
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Notation am Beispiel<br />
Leserichtung<br />
Navigationsrichtung<br />
Name der Assoziation<br />
Multiplizität<br />
* arbeitet für<br />
1..*<br />
Firma Person<br />
Arbeitgeber<br />
Rolle<br />
Arbeitnehmer<br />
ð� 1 Person (als Arbeitnehmer) arbeitet für 0..n Firmen (als Arbeitgeber)<br />
ð� 1 Firma (als Arbeitgeber) beschäftigt 1..n Personen (als Arbeitnehmer)<br />
ð� 1 Person (als Vorgesetzter) ist vorgesetzt für 0..n Personen (als Untergebene)<br />
ð� 1 Person (als Untergebener) hat 0..1 Personen als Vorgesetzten<br />
Vorgesetzter<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 171<br />
0..1<br />
*<br />
Untergebener<br />
ist<br />
vorgesetzt
Interpretation des Beispiels mit Objekten<br />
n� Betrachten Sie die folgenden Objekte<br />
Employer Inc.: Firma<br />
MoD : Firma<br />
W. Orker ist Vorgesetzter<br />
von I. N. Dianer, aber I. N.<br />
Dianer arbeitet gar nicht für<br />
die gleiche Firma.<br />
Vom Modell her ok, wenn<br />
auch fachlich eher falsch.<br />
(Lösung später durch<br />
„Constraints“)<br />
h_da: Firma<br />
arbeitet für<br />
B. Igboss: Person<br />
W. Orker : Person<br />
I. N. Dianer: Person<br />
T. Unix: Person<br />
P. Rof: Person<br />
A.R. Beitslos: Person<br />
ist<br />
vorgesetzt<br />
ist<br />
vorgesetzt<br />
Person ohne Vorgesetzten<br />
2 Personen bei der gleichen<br />
Firma ohne Assoziation<br />
untereinander<br />
Person ohne Vorgesetzten<br />
<strong>und</strong> ohne Firma<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 172
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Navigationsrichtungen bei Assoziationen<br />
n� Bei der Modellierung des dynamischen Verhaltens (Entwurf der Kommunikation<br />
zwischen Klassen) wird festgestellt, in welche Richtung eine<br />
Assoziationsbeziehung durchlaufen wird.<br />
ð� Diese Navigationsrichtung kann angegeben werden (offene Pfeilspitze)<br />
ð� Die Navigationsrichtung gibt <strong>beim</strong> späteren Programmentwurf Auskunft darüber,<br />
in welchen Klassen Verweise auf Objekte anderer Klassen angelegt werden<br />
müssen.<br />
n� Beispiel:<br />
unspezifiziert navigierbar<br />
* 1..*<br />
Auftrag Artikel<br />
Nicht mit der<br />
Leserichtung<br />
verwechseln!<br />
ð� Ein Auftrag muss seine assoziierten Artikel kennen<br />
(z. B. Gesamtsumme berechnen, Nachschauen was disponiert werden muss).<br />
ð� Es ist noch nicht festgelegt, ob ein Artikel wissen muss in welchen Aufträgen er<br />
bestellt wurde.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 173
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Notation für Navigationsrichtungen<br />
n� In UML 1.x steht die Assoziation in Linienform (ohne Pfeilspitzen)<br />
für eine bidirektionale Beziehung<br />
ð� es gab keine Möglichkeit auszudrücken, dass man sich über die Richtung<br />
„noch keine Gedanken gemacht“ hat<br />
n� In UML 2.x:<br />
ð� getrennte Notation für „navigierbar“ <strong>und</strong> „unspezifiziert“ (default)<br />
Unspezifiziert:<br />
UML 2!<br />
geändert ggü. UML 1.x<br />
1<br />
Klasse1<br />
*<br />
Klasse2<br />
1 *<br />
Unidirektional: Klasse1 Klasse2<br />
1<br />
Bidirektional: Klasse1<br />
*<br />
Klasse2<br />
Unidirektional<br />
(einseitig):<br />
1 *<br />
Klasse1 Klasse2<br />
nicht<br />
navigierbar<br />
navigierbar<br />
unspezifiziert<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 174
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Multiplizität<br />
n� Eine Assoziation sagt aus, dass sich Objekte der beteiligten Klassen kennen<br />
n� Die Multiplizität spezifiziert, wie viele Objekte ein bestimmtes Objekt kennen<br />
kann<br />
X<br />
n<br />
1<br />
0..2<br />
*<br />
3..*<br />
genau 1<br />
0 bis 2<br />
0 bis viele<br />
3 bis viele<br />
m Y Ein Objekt x der Klasse X kennt m Objekte der Klasse Y;<br />
Ein Objekt y der Klasse Y kennt n Objekte der Klasse X<br />
Beim Lesen einer Assoziation wird immer die Multiplizität am<br />
Ausgangspunkt der Beziehung als „1“ gelesen!<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 175
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Wie findet man Assoziationen?<br />
n� a) Dokumentenanalyse<br />
ð� Verben in Dokumenten (Use Cases, Dokumentationen, Spezifikationen<br />
Interview-Protokoll etc.)<br />
ð� Aber: Nicht alle Assoziationen sind für den zu modellierenden Problembereich<br />
wichtig!<br />
n� b) Weitere Hinweise auf Assoziationen:<br />
ð� Verwaltung von Dingen (Firma hat K<strong>und</strong>en, Abteilung gliedert sich in Gruppen)<br />
ð� Besitz (Motor besitzt Benzinpumpe, Auftrag besteht aus Positionen)<br />
ð� Kommunikation zwischen Objekten<br />
n� c) In späteren Schritten:<br />
ð� Bei dynamischer Modellierung wird die Kommunikation zwischen Klassen<br />
dargestellt:<br />
- Kommunikation läuft über vorhandene Assoziation – oder auch nicht<br />
Falls nicht ð� oft zusätzliche Assoziation!<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 176
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Modellierung<br />
n� Regeln:<br />
ð� Verbindungen zwischen Objekten stets als Assoziation modellieren<br />
(<strong>und</strong> nicht als Zeiger-Attribut)!<br />
- übersichtliche Darstellung<br />
- das Modell bleibt unabhängig von den Fähigkeiten der Programmiersprache<br />
ð� Voneinander unabhängige Beziehungen können (<strong>und</strong> sollten) durch mehrere<br />
Assoziationen (mit gleicher Quelle <strong>und</strong> gleichem Ziel) ausgedrückt werden<br />
- durch Rollen ausdrücken, warum es mehrere Beziehungen gibt<br />
ð� Multiplizität sollte angegeben werden<br />
- muss (spätestens) im <strong>Design</strong> angegeben werden, damit die Coderahmen mit<br />
entsprechenden Attributen generiert werden können<br />
ð� Implementierung erfolgt erst später (auf niedrigerer Abstraktionsebene)<br />
ð� Leserichtung immer angeben, wenn sie von links → rechts bzw. oben → unten<br />
abweicht<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 177
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Übung „Linien <strong>und</strong> Schnittpunkte“<br />
n� Entwickeln Sie ein Klassendiagramm zur Darstellung von Linien, die sich in<br />
Schnittpunkten schneiden können.<br />
L5<br />
L3<br />
L1<br />
L2<br />
P1<br />
P3<br />
P2<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 178<br />
L4
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
„Linien <strong>und</strong> Schnittpunkte“: <strong>Analyse</strong> des Problems<br />
n� 1) Klassen <strong>und</strong> Attribute durch „Suchen der Substantive“<br />
Schnittpunkt Linie<br />
Name Name<br />
n� 2) Erweiterung um Assoziationen<br />
Schnittpunkt schneidet<br />
Linie<br />
Name Name<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 179
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Assoziationen (Vorarbeit durch Betrachtung der Objekte) � Objektdiagramm<br />
L1 : Linie<br />
L2 : Linie<br />
L3 : Linie<br />
L4 : Linie<br />
L5 : Linie<br />
P1:<br />
Schnittpunkt<br />
P2:<br />
Schnittpunkt<br />
P3:<br />
Schnittpunkt<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 180
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
„Linien <strong>und</strong> Schnittpunkte“: Lösung als Klassendiagramm<br />
n� 3) Multiplizitäten aus dem Beispiel extrahieren:<br />
ð� Die Linien <strong>und</strong> Schnittpunkte sind Exemplare der Klassen „Linie“ <strong>und</strong><br />
„Schnittpunkt“. Die Linien L1, L3 <strong>und</strong> L4 besitzen jeweils zwei Schnittpunkte mit<br />
anderen Linien (P1,P3 bzw. P1,P2 bzw. P3,P2), L2 hat einen Schnittpunkt, L5<br />
hat keinen Schnittpunkt. P2 <strong>und</strong> P3 haben 2 Linien, Schnittpunkt P1 hat 3 Linien.<br />
Schnittpunkt 0..2 ? schneidet 2..3<br />
? Linie<br />
Name Name<br />
n� 4) Abstraktion:<br />
ð� 2 Linien können aufeinander liegen (haben unendlich viele Schnittpunkte)<br />
ð� beliebig viele Linien können durch einen Schnittpunkt gehen<br />
Schnittpunkt ? * schneidet 2..* ? Linie<br />
Name Name<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 181
Ein Problem<br />
n� Die bisherige Modellierung von Person <strong>und</strong> Firma soll so erweitert werden, dass<br />
ein Gehalt verwaltet <strong>und</strong> Urlaub beantragt werden kann<br />
ð� Betrachten Sie das Attribut Gehalt <strong>und</strong> die Methode Urlaub_beantragen()<br />
ð� Wie <strong>und</strong> wo sollten diese Elemente modelliert werden?<br />
ð� Denken Sie daran, dass eine Person in mehreren Firmen arbeiten kann!<br />
Employer Inc.: Firma<br />
MoD : Firma<br />
arbeitet für<br />
Gehalt<br />
Urlaub_beantragen()<br />
B. Igboss: Person<br />
W. Orker : Person<br />
I. N. Dianer: Person<br />
ð� Diese Attribute <strong>und</strong> Methoden gehören jeweils zu der<br />
Assoziation zwischen einer Firma <strong>und</strong> einer Person!<br />
ist<br />
vorgesetzt<br />
ist<br />
vorgesetzt<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 182
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Assoziationsklassen<br />
n� Es gibt Attribute <strong>und</strong> Operationen, die vom Vorhandensein einer Assoziation<br />
abhängig sind. In anderem Kontext sind sie nicht nötig.<br />
- Person bekommt das Gehalt nur/kann nur dann Urlaub beantragen, wenn sie<br />
angestellt ist <strong>und</strong> zwar von der Firma, bei der sie angestellt ist.<br />
- Gehalt, Urlaub_beantragen sind Merkmale der Assoziation.<br />
ð� auch Assoziationen können Merkmale, d. h. Attribute <strong>und</strong> Operationen besitzen.<br />
ð� „Assoziationsobjekt“<br />
n� Die Merkmale existieren für jede einzelne aufgebaute Verbindung zwischen zwei<br />
Objekten dieser Klassen genau einmal<br />
n� Abstraktion zur „Assoziationsklasse“ im Klassendiagramm<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 183
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Darstellung einer Assoziationsklasse<br />
* arbeitet _für 1..*<br />
Firma Person<br />
Arbeitgeber<br />
Anstellung<br />
Gehalt<br />
Urlaub_beantragen()<br />
Arbeitnehmer<br />
Vorgesetzter<br />
n� Bemerkung:<br />
ð� Auch wenn jede Person in genau einer Firma arbeiten würde, gehören Gehalt<br />
<strong>und</strong> Urlaub_beantragen semantisch zur Assoziation<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 184<br />
0..1<br />
*<br />
Untergebener<br />
ist_<br />
vorgesetzt<br />
Assoziationsklasse
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel – Fortsetzung<br />
n� Die bisher modellierte Vererbungshierarchie ist korrekt, jedoch bezüglich<br />
Flexibilität <strong>und</strong> Wiederverwendung ungünstig modelliert:<br />
ð� Wird ein Objekt der Klasse Student erzeugt, so müsste dieses Objekt seine<br />
Klasse wechseln, sobald der Student Tutor wird. Nach der bisher modellierten<br />
Hierarchie müsste das Objekt zerstört <strong>und</strong> ein neues Objekt der Klasse<br />
StudentischerTutor erzeugt <strong>und</strong> mit denselben Daten belegt werden.<br />
ð� Der Unterschied zwischen den Personengruppen (im Hinblick auf ein<br />
Hochschulverwaltungssystem) besteht in der Art der Vergütung.<br />
Die Vergütung taucht aber nur „versteckt“ als Methode auf.<br />
ð� Nachdem wir Assoziationen <strong>und</strong> Assoziationsklassen kennengelernt haben,<br />
können wir durch ein geschicktes <strong>Design</strong> der bisherigen Klassenhierarchie<br />
dieses Problem beseitigen.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 185
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel (Lösung mit Assoziationen)<br />
Student<br />
# Matrikelnr : Integer<br />
Person<br />
# Name : String<br />
# GebDatum : Datum<br />
# Geburtsort : String<br />
FH_Person<br />
+ Vergütung ()<br />
Dozent<br />
# akademTitel : String<br />
# SWS : Integer<br />
Die Klassen (Sekretärin etc.) sind in diesem<br />
Diagramm nicht dargestellt, weil es hier um die<br />
Aufteilung zwischen Person <strong>und</strong> Gehalt geht!<br />
*<br />
Gehaltskonto<br />
0..1<br />
Professor<br />
Vergütung<br />
+ Vergütung ()<br />
Vergütung<br />
{abstract}<br />
+ Vergütung () {abstract}<br />
Lehrbeauftragten<br />
Vergütung<br />
+ Vergütung ()<br />
Es gibt Personen,<br />
Vergütungen – <strong>und</strong><br />
Beziehungen dazwischen<br />
BAT<br />
+ Vergütung ()<br />
Tutor<br />
Vergütung<br />
+ Vergütung ()<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 186
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Randbedingungen für Assoziationen (Constraints)<br />
n� Zu Assoziationen können Randbedingungen hinzudefiniert werden.<br />
ð� Eine Randbedingung ist eine zusätzliche Information zum vorhandenen<br />
Modellelement, um es konsistent zu machen.<br />
ð� Constraints geben Bedingungen für die Implementierungsphase.<br />
n� Beispiel 1:<br />
Bei einem Polygon kommt es auf die Reihenfolge der Punkte an<br />
0..1<br />
wird_definiert<br />
Polygon Punkt<br />
{ordered}<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 187<br />
3..*
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Randbedingungen für Assoziationen (Beispiel)<br />
n� Randbedingungen mit langem Text können als Kommentar angegeben werden<br />
ð� z. B.: Der Vorgesetzte <strong>und</strong> dessen untergebener Arbeitnehmer müssen bei<br />
demselben Arbeitgeber beschäftigt sein.<br />
Arbeitgeber<br />
Firma Person<br />
Randbedingung formuliert in OCL<br />
(Object Constraint Language)<br />
Anstellung<br />
Arbeitnehmer<br />
* arbeitet _für 1..*<br />
Gehalt<br />
Urlaub_beantragen<br />
{ Person.Arbeitgeber =<br />
Person.Vorgesetzter.Arbeitgeber<br />
Vorgesetzter<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 188<br />
}<br />
1<br />
*<br />
Untergebener<br />
ist_<br />
vorgesetzt
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel (mit Constraints)<br />
n� Unsere bereits veränderte Vererbungshierarchie des ersten<br />
Klassenhierarchieentwurfs kann nun durch die Verwendung von selbstdefinierten<br />
Constraints vollständig <strong>und</strong> widerspruchsfrei modelliert werden.<br />
n� Es ist klar, dass nicht jedes Objekt willkürlich mit jedem Gehalt kombiniert<br />
werden kann. Durch ein entsprechendes Constraint sind nun (gemäß der<br />
Aufgabe eines Modells) alle Regeln des Anwendungsbereichs widergespiegelt<br />
<strong>und</strong> hinreichende Vorgaben für die Implementierung gegeben.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 189
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel (Lösung mit Constraints)<br />
Student<br />
# Matrikelnr : Integer<br />
Person<br />
# Name : String<br />
# GebDatum : Datum<br />
# Geburtsort : String<br />
FH_Person<br />
Dozent<br />
# akademTitel : String<br />
# SWS : Integer<br />
Gehaltskonto<br />
typeOf (Student.Vergütungsberechnung) = Tutorvergütung<br />
typeOf (FH_Person.Vergütungsberechnung) = BAT<br />
typeOf (Dozent.Vergütungsberechnung) ∈ (ProfessorVergütung,<br />
LehrbeauftragtenVergütung)<br />
*<br />
Professor<br />
Vergütung<br />
+ Vergütung ()<br />
Vergütungs<br />
berechnung<br />
{abstract}<br />
+ Vergütung () {abstract}<br />
Lehrbeauftragten<br />
Vergütung<br />
+ Vergütung ()<br />
Tutor<br />
Vergütung<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 190<br />
0..1<br />
BAT<br />
+ Vergütung ()<br />
+ Vergütung ()
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Ternäre <strong>und</strong> höherwertige Assoziationen: Beispiel<br />
n� An einer Assoziation können auch mehr als zwei Klassen beteiligt sein.<br />
Torwart Verein Saison S N U GT<br />
Peter Gleichauf FC Sandberg 1964 10 13 02 12<br />
Peter Gleichauf FC Sandberg 1966 15 10 00 21<br />
Fred Hill ASC Altheim 1966 08 06 11 13<br />
Fred Hill ASC Altheim 1972 21 02 02 01<br />
Fred Hill SV Rohrstock 1972 14 07 04 16<br />
Fred Hill FC Sandberg 1970 12 06 07 07<br />
Verein<br />
n� Zu einem assoziierten Tripel von<br />
ð� Spieler, Verein <strong>und</strong> Saison gibt es eine Statistik<br />
*<br />
Statistik<br />
Siege<br />
Niederlagen<br />
Unentschieden<br />
Gegentore<br />
Saison<br />
Torwart<br />
Spieler<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 191<br />
*<br />
*<br />
Ternäre<br />
Assoziation mit<br />
Assoziationsklasse
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Ternäre <strong>und</strong> höherwertige Assoziationen<br />
n� Oft sind vermeintliche 3-er Beziehungen in Wahrheit drei 2-er Beziehungen!<br />
ð� 3-er <strong>und</strong> höherwertige Assoziationen sollten, falls möglich, vermieden werden!<br />
n� Oft gibt es Alternativen zur 3-er bzw. höherwertigen Assoziation<br />
ð� durch die Einführung einer Klasse statt 3er-Beziehung<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 192
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel<br />
n� Aufgabe:<br />
ð� Erweitern Sie das bisherige Klassendiagramm des Hochschulverwaltungssystems<br />
so, dass es die folgenden Klassen <strong>und</strong> Assoziationen integriert.<br />
ð� Analysieren Sie zur Identifikation der Klassen <strong>und</strong> Assoziationen den Text.<br />
Bestimmen Sie die Multiplizitäten der Assoziationen <strong>und</strong> benennen Sie die<br />
Assoziationen <strong>und</strong>/oder die Rollen, die die beteiligten Klassen in einer Assoziation<br />
spielen, wenn dadurch die Verständlichkeit des Modells verbessert wird.<br />
n� Anforderungen:<br />
ð� Die Dozenten <strong>und</strong> die Studenten gehören einem <strong>Fachbereich</strong> an.<br />
ð� Studenten nehmen an Lehrveranstaltungen teil, welche die Dozenten halten<br />
ð� Lehrveranstaltungen werden mit einem benoteten Leistungsnachweis<br />
abgeschlossen. Besteht ein Student nicht, kann er die Klausur wiederholen<br />
ð� Studenten werden während der Masterarbeit von einem Professor betreut.<br />
Thema <strong>und</strong> Abgabetermin der Masterarbeit sind zu erfassen. Studenten können<br />
natürlich eine Masterarbeit auch unvollendet abbrechen.<br />
ð� Lehrveranstaltungen im Semester können von Tutoren mitbetreut werden.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 193
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel (überarbeitet)<br />
<strong>Fachbereich</strong><br />
1<br />
gehört_FB_an<br />
Masterarbeitsbetreuung<br />
Student<br />
*<br />
0..1<br />
Masterstudent Betreuer<br />
Teilnehmer *<br />
*<br />
besucht_<br />
Veranstaltung<br />
Leistung<br />
Note<br />
wiederholen<br />
gehört_FB_an<br />
Masterarbeit<br />
Thema<br />
Abgabe<br />
abbrechen<br />
Lehrkörper<br />
1 *<br />
Professor<br />
hält_<br />
Veranstaltung<br />
*<br />
Lab-Ing<br />
Sekretärin<br />
Dozent<br />
Referent<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 194<br />
1<br />
Lehrveranstaltung<br />
Semester<br />
Raumnummer<br />
Kurs<br />
*<br />
*<br />
Tutor<br />
Angestellter<br />
{abstract }<br />
* Betreuer<br />
betreut_<br />
Veranstaltung
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel: Zusatzfragen<br />
n� Sie sitzen gerade in einer Vorlesung. Wo ist die Beziehung zu Ihrem Professor?<br />
n� Was verändert sich, wenn 2 Professoren eine Masterarbeit betreuen?<br />
n� Was verändert sich, wenn wir darstellen wollen, dass Lehrbeauftragte zu<br />
mehreren <strong>Fachbereich</strong>en gehören können, Professoren aber nur zu einem?<br />
n� In Lehrveranstaltungen werden Werte von Attributen red<strong>und</strong>ant gespeichert (In<br />
der OOAD-LV von Herrn Weber, als auch in der OOAD-LV von Herrn Hahn<br />
stehen Titel <strong>und</strong> ECTS). Wie könnte man das vermeiden?<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 195
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Spezielle Assoziationen: Aggregation <strong>und</strong> Komposition<br />
n� Aggregation/Komposition bedeutet „Teil-von-Beziehung“ (oder „besteht-aus-<br />
Beziehung“), d. h. ein Objekt ist Bestandteil eines anderen<br />
Computersystem<br />
n� Aggregation <strong>und</strong> Komposition sind<br />
1 0..1<br />
1 1..* 1..*<br />
Motherboard Festplatte<br />
Netzwerkkarte<br />
ð� transitiv: A ist Teil von B, B ist Teil von C. Somit ist A Teil von C<br />
ð� asymmetrisch: A ist Teil von B, aber B ist nicht Teil von A<br />
Monitor<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 196
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Spezielle Assoziationen: Aggregation (Shared Aggregation)<br />
n� Aggregation:<br />
ð� Symbol: leere Raute<br />
ð� spezifiziert Referenz auf das aggregierte Objekt<br />
ð� Aggregiertes Objekt ist zwar Bestandteil, existiert aber unabhängig vom<br />
aggregierenden Objekt<br />
ð� „shared“ Aggregation (kann zu mehreren Objekten gleichzeitig gehören, d. h. die<br />
Multiplizität darf > 1 sein)<br />
Monitor<br />
0..1<br />
1<br />
Computersystem<br />
Mensch<br />
Verein<br />
1..*<br />
1..*<br />
shared Aggregation<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 197
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Spezielle Assoziationen: Komposition (Composite Aggregation)<br />
n� Komposition<br />
ð� Symbol: ausgefüllte Raute<br />
ð� Teilobjekte einer Komposition<br />
- werden <strong>beim</strong> Zerstören des „Ganzes-Objektes“ automatisch (kaskadierend) mit<br />
zerstört<br />
- dürfen nicht Teil anderer Kompositionen sein<br />
- dürfen nur von Operationen der „Ganzes-Klasse“ entfernt oder ersetzt werden<br />
ð� Komposition (= „unshared“ Aggregation)<br />
Motherboard<br />
1<br />
1<br />
(kann weggelassen werden, da bei<br />
Composite Aggregation immer 1)<br />
Computersystem Composite<br />
Finger<br />
Mensch<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 198<br />
10<br />
1
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Beispiel: Constraints für Aggregationen<br />
Auto<br />
1<br />
1<br />
Motor<br />
Getriebe<br />
Kupplung<br />
n� Ohne ein Constraint könnte laut Modell der Motor sowie das Getriebe ein<br />
anderes Kupplungsexemplar assoziieren als das übergeordnete Auto selbst<br />
ð� Inkonsistenz im Modell!<br />
n� Das hinzu definierte Constraint schließt diese Lücke<br />
1<br />
1<br />
1<br />
Ein Motor <strong>und</strong> das Getriebe<br />
müssen, um zu funktionieren, mit<br />
derselben Kupplung verb<strong>und</strong>en<br />
sein.<br />
Auto.Kupplung =<br />
Auto.Motor.Kupplung AND<br />
Auto.Kupplung =<br />
Auto.Getriebe.Kupplung<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 199
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel mit Aggregationen<br />
n� Aufgabe:<br />
Erweitern Sie das Klassendiagramm der Hochschulverwaltung um die<br />
nachfolgenden Inhalte<br />
n� Anforderungen:<br />
ð� Ein <strong>Fachbereich</strong> kann eine Bibliothek <strong>und</strong> mehrere Labore besitzen, in denen<br />
Laboringenieure arbeiten<br />
ð� Jeder <strong>Fachbereich</strong> beschäftigt in der Verwaltung Sekretärinnen<br />
ð� Die Laborräume sind zur Vermeidung von Diebstählen mit Sicherheitstüren<br />
ausgestattet<br />
ð� Labor-Ingenieure arbeiten in einem bestimmten Labor<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 200
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel mit Aggregationen (Lösung)<br />
Bibliothek Labor<br />
1<br />
<strong>Fachbereich</strong><br />
1<br />
Sicherheitstür<br />
1<br />
*<br />
*<br />
gehört_FB_an<br />
Masterarbeit<br />
*<br />
Student<br />
*<br />
1<br />
* Diplomand Betreuer<br />
Teilnehmer<br />
besucht_<br />
Veranstaltung<br />
1<br />
1 *<br />
Leistung<br />
Note<br />
wiederholen<br />
Arbeitsplatz<br />
gehört_FB_an<br />
Masterarbeit<br />
Thema<br />
Abgabe<br />
abbrechen<br />
arbeitet_in_Labor<br />
arbeitet_für_FB *<br />
Lehrkörper<br />
Professor<br />
hält_<br />
Veranstaltung<br />
*<br />
Dozent<br />
1<br />
Lehrveranst.<br />
Semester<br />
Raumnummer<br />
Kursname<br />
*<br />
1<br />
*<br />
Ansprechpartner<br />
Sekretärin<br />
Referent<br />
Lehrveranstaltungs-<br />
beschreibung<br />
Belegnummer<br />
Titel<br />
Beschreibung<br />
*<br />
Lab-Ing<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 201<br />
*<br />
beschreibt<br />
Tutor<br />
* Betreuer<br />
betreut_<br />
Veranstaltung<br />
Angestellter<br />
{abstract }
5.1.5 Darstellung der Statik eines Systems: Assoziationen<br />
Durchgängiges Beispiel (Erklärung)<br />
n� Labors <strong>und</strong> eine Bibliothek sind Teile eines <strong>Fachbereich</strong>s, die aber jederzeit<br />
einem anderen <strong>Fachbereich</strong> zugewiesen werden können. Daher ist die Teil-von-<br />
Beziehung eine Aggregation (shared Aggregation)<br />
n� Eine Sicherheitstür ist fester Bestandteil des Labors <strong>und</strong> ist deswegen eine<br />
Komposition (unshared Aggregation)<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 202
Hochschule Darmstadt<br />
<strong>Fachbereich</strong> <strong>Informatik</strong><br />
<strong>Objektorientierte</strong> <strong>Analyse</strong> <strong>und</strong> <strong>Design</strong><br />
5.1.6 Darstellung der Statik eines Systems:<br />
Zusammenfassung<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 203
5.1.6 Darstellung der Statik eines Systems: Zusammenfassung<br />
Schritte zum Entwickeln von Klassendiagrammen<br />
1. Klassen(kandidaten) finden<br />
ð� Substantive bestimmen<br />
ð� überflüssige Begriffe rausfiltern<br />
ð� Attribute identifizieren<br />
ð� Methoden über Verben suchen<br />
2. Vererbungsbeziehungen suchen<br />
ð� Ähnliche Klassen identifizieren (Aber: „Ist-ein-Regel“ beachten!)<br />
ð� Evtl. Schnittstellen durch abstrakte Klasse + Vererbung definieren<br />
3. Assoziationen zwischen Klassen bestimmen<br />
ð� „Kennt“-Beziehungen: normale Assoziation<br />
ð� „Besteht aus“-Beziehung: Aggregation bzw. Komposition<br />
ð� evtl. Leserichtung <strong>und</strong> Rollen angeben<br />
ð� Objekte, deren Existenz an einer Assoziation hängt: Assoziationsklasse<br />
4. Multiplizitäten <strong>und</strong> Navigationsrichtungen eintragen<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 204
5.1.6 Darstellung der Statik eines Systems: Zusammenfassung<br />
Wert von Klassendiagrammen<br />
n� Klassendiagramme sind eines der wichtigsten Beschreibungsmittel in der<br />
Modellierung<br />
ð� Zur Beschreibung eines (komplexen) Systems werden viele Klassendiagramme<br />
erstellt<br />
ð� Tipps:<br />
- niemals versuchen gleich alles perfekt zu machen;<br />
auch Klassendiagramme werden iterativ entwickelt<br />
- Details wie Navigationsrichtungen <strong>und</strong> Multiplizität erst dann eintragen,<br />
wenn die Modellierung hinreichend stabil scheint<br />
- Bei der Modellierung an die Systemgrenze denken!<br />
Nur das System modellieren – nicht die komplette Außenwelt!<br />
- immer nur einen Aspekt auf einem Diagramm darstellen;<br />
wenn das Diagramm nicht mehr auf eine Seite passt – aufteilen!<br />
- die Begriffe für alle Elemente mit großer Sorgfalt wählen<br />
- Assoziationen so konkret wie möglich spezifizieren<br />
- keine unverständlichen Pseudoprogramme in Constraints schreiben<br />
- es geht (auch) um Verständlichkeit<br />
- ein Pointer als Attribut einer Klasse ist meist eine falsch modellierte Assoziation<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 205
5.1.6 Darstellung der Statik eines Systems: Zusammenfassung<br />
Notation in UML 2.x (I)<br />
The image cannot be displayed. Your computer may not have enough<br />
memory to open the image, or the image may have been corrupted.<br />
Restart your computer, and then open the file again. If the red x still<br />
appears, you may have to delete the image and then insert it again.<br />
The image cannot be displayed. Your computer may not<br />
have enough memory to open the image, or the image may<br />
have been corrupted. Restart your computer, and then<br />
open the file again. If the red x still appears, you may have<br />
to delete the image and then insert it again.<br />
Klasse<br />
Ein Klasse kann als Rechteck dargestellt werden, das den<br />
Klassennamen enthält. Üblicherweise bestehen Klassen aus<br />
drei Bereichen; der obere Bereich enthält den Namen <strong>und</strong><br />
kann den Stereotyp (z. B. ) <strong>und</strong> das Paket, zu dem<br />
die Klasse gehört, enthalten. Im mittleren Bereich werden die<br />
Attribute angegeben <strong>und</strong> im unteren Bereich stehen die<br />
Operationen der Klasse. Laut UML-Spezifikation kann die<br />
Darstellung einer Klasse zusätzliche Bereiche enthalten.<br />
Abstrakte Klasse<br />
Der Name einer abstrakten Klasse wird kursiv geschrieben.<br />
Alternativ kann die Eigenschaft {abstract} angegeben werden.<br />
Schnittstelle (Interface)<br />
Schnittstellen sind Spezifikationen des externen Verhaltens<br />
von Klassen <strong>und</strong> beinhalten Signaturen für Operationen <strong>und</strong><br />
Attribute.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 206
5.1.6 Darstellung der Statik eines Systems: Zusammenfassung<br />
Notation in UML 2.x (II)<br />
The image cannot be displayed. Your computer may not have<br />
enough memory to open the image, or the image may have<br />
been corrupted. Restart your computer, and then open the file<br />
again. If the red x still appears, you may have to delete the<br />
image and then insert it again.<br />
Parametrisierte Klasse<br />
auch Template oder Schablone genannt. Die parametrisierte<br />
Klasse hat in der rechten, oberen Ecke ein das Klassensymbol<br />
überlappendes Rechteck, das die Schablonen-Parameter der<br />
Klasse enthält. Die Funktion, die den Parameter verwendet, wird<br />
angegeben. Die Klasse, die den Parameter bindet, wird über<br />
eine gestrichelte Linie mit Pfeil an dem Template verb<strong>und</strong>en.<br />
Diese trägt die Bezeichnung .<br />
Assoziation<br />
Eine Linie zwischen den Klassen stellt eine Assoziation dar. Eine<br />
Assoziation ist eine Beziehung zwischen Klassen. Die Objekte<br />
der Klassen kommunizieren über Assoziationen miteinander. Die<br />
Assoziation kann einen Namen haben. Ein Pfeil an dem Assoziationsnamen<br />
gibt die Leserichtung des Namens an. An den<br />
Assoziationsenden können die Rollen der beteiligten Klassen<br />
<strong>und</strong> die Multiplizität angegeben werden.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 207
5.1.6 Darstellung der Statik eines Systems: Zusammenfassung<br />
Notation in UML 2.x (III)<br />
The image cannot be displayed. Your computer may not have enough memory to open<br />
the image, or the image may have been corrupted. Restart your computer, and then open<br />
the file again. If the red x still appears, you may have to delete the image and then insert<br />
it again.<br />
The image cannot be displayed. Your computer may not have enough memory<br />
to open the image, or the image may have been corrupted. Restart your<br />
computer, and then open the file again. If the red x still appears, you may have<br />
to delete the image and then insert it again.<br />
Gerichtete Assoziation<br />
Mit einem Pfeil an der Assoziation kann die Navigationsrichtung<br />
angegeben werden. Der Pfeil drückt die<br />
Zugriffsrichtung der Objekte aus. Hier: Objekt A greift<br />
auf B zu, der Zugriff von B auf A ist noch un-spezifiziert.<br />
Generalisierung/Spezialisierung<br />
Generalisierungs-/Spezialisierungs-Beziehungen<br />
werden mit einem Pfeil dargestellt. Die Pfeilspitze zeigt<br />
auf die Oberklasse. Die Oberklasse gibt ihre Eigenschaften<br />
an die Unterklassen weiter.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 208
5.1.6 Darstellung der Statik eines Systems: Zusammenfassung<br />
Notation in UML 2.x (IV)<br />
The image cannot be displayed. Your computer may not have<br />
enough memory to open the image, or the image may have<br />
been corrupted. Restart your computer, and then open the file<br />
again. If the red x still appears, you may have to delete the<br />
image and then insert it again.<br />
The image cannot be displayed. Your computer may not have enough<br />
memory to open the image, or the image may have been corrupted.<br />
Restart your computer, and then open the file again. If the red x still<br />
appears, you may have to delete the image and then insert it again.<br />
Aggregation<br />
Eine Aggregation drückt eine Teile-Ganzes-Beziehung<br />
aus. Das Ganze-Objekt besteht aus Teil-Objekten. Die<br />
Raute befindet sich an dem Ende des Ganzen. Die<br />
Aggregation ist eine spezielle Art der Assoziation. Da<br />
das Ganze die Teile enthält, sollten am Assoziationsende<br />
der Teile ein Navigationspfeil stehen.<br />
Komposition<br />
Die Komposition ist auch eine Beziehung, die Teile zu<br />
einem Ganzen in Beziehung setzt. Die Teile <strong>und</strong> das<br />
Ganze sind bei dieser Beziehung existenzabhängig; die<br />
Teile können nicht ohne das Ganze existieren. Wird das<br />
Ganze gelöscht, so beenden auch die Teile ihre Existenz.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 209
5.1.6 Darstellung der Statik eines Systems: Zusammenfassung<br />
Notation in UML 2.x (V)<br />
The image cannot be displayed. Your computer may not have enough memory to<br />
open the image, or the image may have been corrupted. Restart your computer, and<br />
then open the file again. If the red x still appears, you may have to delete the image<br />
and then insert it again.<br />
The image cannot be displayed. Your computer may not have<br />
enough memory to open the image, or the image may have<br />
been corrupted. Restart your computer, and then open the file<br />
again. If the red x still appears, you may have to delete the<br />
image and then insert it again.<br />
Assoziationsklasse<br />
Ist eine Klasse von dem Vorhandensein einer Assoziation<br />
zwischen zwei Klassen abhängig, so kann dies durch eine<br />
Assoziationsklasse ausgedrückt werden. Die Assoziationsklasse<br />
beschreibt Eigenschaften, die keiner der an der<br />
Assoziation beteiligten Klassen sinnvoll zuordenbar sind.<br />
Die Assoziationsklasse wird über eine gestrichelte Linie mit<br />
der Assoziation, von der sie abhängt, verb<strong>und</strong>en. Hat die<br />
Assoziation einen Namen, dann muss die Assoziationsklasse<br />
den selben Namen erhalten. Die Assoziationsklasse<br />
ist ein <strong>Analyse</strong>konzept.<br />
Mehrgliedrige Assoziation<br />
Eine mehrgliedrige Assoziation drückt eine Beziehung<br />
zwischen mehr als 2 gleichwertigen Klassen aus. Die<br />
Beziehung wird mit einer Raute markiert.<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 210
5.1.1 Darstellung der Statik eines Systems: Klassen <strong>und</strong> die UML<br />
Zusammenfassung Klassendiagramme<br />
n� Klassendiagramme enthalten<br />
ð� Klassen mit Attributen <strong>und</strong> Methoden<br />
ð� Generalisierung/Spezialisierung<br />
ð� Abstrakte Klasse/Schnittstelle<br />
ð� Parametrisierte Klasse<br />
ð� Constraints<br />
ð� Assoziationen<br />
- (normale) Assoziationen: einfache, mehrfache<br />
- Aggregation<br />
- Komposition<br />
ð� Navigationsrichtung<br />
ð� Assoziationsklassen<br />
ð� Das sind die Elemente im „Modellierungs-Baukasten“<br />
– aber wie werden die in Code umgesetzt?<br />
OOAD, Dr. Eicke Godehardt WS2012/13, h_da, <strong>Fachbereich</strong> <strong>Informatik</strong> 211