Klassendiagramm: Unterschied zwischen den Versionen
Thomas (Diskussion | Beiträge) |
Thomas (Diskussion | Beiträge) |
||
| (10 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 11: | Zeile 11: | ||
<iframe width="450" height="300" src="https://www.youtube.com/embed/yuqm2LumFZs?si=46KzIBCqGOL3h1pz" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> | <iframe width="450" height="300" src="https://www.youtube.com/embed/yuqm2LumFZs?si=46KzIBCqGOL3h1pz" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> | ||
</html> | </html> | ||
== Klassen == | == Klassen == | ||
[[Klasse|Klassen]] werden durch Rechtecke dargestellt, die entweder nur den Namen der Klasse (fett gedruckt) tragen oder zusätzlich auch [[Attribut|Attribute]] und [[Methode|Methoden]] spezifiziert haben. Dabei werden diese drei Rubriken – Klassenname, Attribute, Methoden– jeweils durch eine horizontale Linie getrennt. Wenn die [[Klasse]] keine [[Attribut|Eigenschaften]] oder [[Methode|Methoden]] besitzt, kann die unterste horizontale Linie entfallen. | [[Klasse|Klassen]] werden durch Rechtecke dargestellt, die entweder nur den Namen der Klasse (fett gedruckt) tragen oder zusätzlich auch [[Attribut|Attribute]] und [[Methode|Methoden]] spezifiziert haben. Dabei werden diese drei Rubriken – Klassenname, Attribute, Methoden– jeweils durch eine horizontale Linie getrennt. Wenn die [[Klasse]] keine [[Attribut|Eigenschaften]] oder [[Methode|Methoden]] besitzt, kann die unterste horizontale Linie entfallen. | ||
| Zeile 67: | Zeile 68: | ||
<html> | <html> | ||
<iframe width=" | <iframe width="280" height="157.5" src="https://www.youtube.com/embed/06FGt0K143k?si=GYrIA4cCqdgMttYs" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> | ||
</html> | </html> | ||
<html> | <html> | ||
<iframe width=" | <iframe width="280" height="157.5" src="https://www.youtube.com/embed/-STQ2qv2Yso?si=T7s2mTRXg2pymWDA" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> | ||
</html> | </html> | ||
==== Komposition und Aggregation ==== | ==== Komposition und Aggregation ==== | ||
[[Datei:Komosition und Aggregatuion UML.png|mini]] | |||
Bisher haben wir die Beziehungen zwischen verschiedenen Objekten betrachtet. Doch ein Objekt selbst kann eine komplexe Struktur besitzen, und wir können die Beziehungen zwischen dem [[Objekt]] und seinen Teilen genauer festlegen. Dabei unterscheiden wir zwischen Komposition und Aggregation. | Bisher haben wir die Beziehungen zwischen verschiedenen Objekten betrachtet. Doch ein Objekt selbst kann eine komplexe Struktur besitzen, und wir können die Beziehungen zwischen dem [[Objekt]] und seinen Teilen genauer festlegen. Dabei unterscheiden wir zwischen Komposition und Aggregation. | ||
| Zeile 101: | Zeile 103: | ||
Die Lebenszeit der Einzelteile ist der des Ganzen untergeordnet. Sie werden also zusammen mit dem Aggregat erzeugt, und sie werden zusammen mit dem Aggregat zerstört (Analyse und Design mit UML 2.3: objektorientierte Softwareentwicklung von Bernd Oestereich, Oldenbourg 2009 Seite 94 ff) | Die Lebenszeit der Einzelteile ist der des Ganzen untergeordnet. Sie werden also zusammen mit dem Aggregat erzeugt, und sie werden zusammen mit dem Aggregat zerstört (Analyse und Design mit UML 2.3: objektorientierte Softwareentwicklung von Bernd Oestereich, Oldenbourg 2009 Seite 94 ff) | ||
== Beispiele == | === Beispiele === | ||
Die Bedeutung für die Implementierung lässt sich am Besten anhand eines Beispiels nachvollziehen. Die Kompositionsbeziehung zwischen Gebäude und Raum wird über eine dynamische Datenstruktur (hier ein ArrayList) und den Konstruktor der Klasse Gebaeude realisiert. | Die Bedeutung für die Implementierung lässt sich am Besten anhand eines Beispiels nachvollziehen. Die Kompositionsbeziehung zwischen Gebäude und Raum wird über eine dynamische Datenstruktur (hier ein ArrayList) und den Konstruktor der Klasse Gebaeude realisiert. | ||
| Zeile 125: | Zeile 127: | ||
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
== Navigierbarkeit == | == Navigierbarkeit == | ||
[[Datei:UML Klassendiagramm Navigierbarkeit.jpg|mini]] | [[Datei:UML Klassendiagramm Navigierbarkeit.jpg|mini]] | ||
Eine weitere Eigenschaft einer Beziehung ist ihre Navigierbarkeit. Man spricht in diesem Zusammenhang auch von einer "gerichteten" Beziehung. Die Navigierbarkeit sagt etwas darüber aus, ob die eine [[Klasse]] auf die in beziehungstehende [[Klasse]] zugreifen kann bzw. [[Objekt|Objekte]] dieser Klasse kennt. Die Navigierbarkeit wird meistens in den Designmodellen angegeben, in den Analysemodellen spielt die Navigierbarkeit selten eine Rolle. | Eine weitere Eigenschaft einer Beziehung ist ihre Navigierbarkeit. Man spricht in diesem Zusammenhang auch von einer "gerichteten" Beziehung. Die Navigierbarkeit sagt etwas darüber aus, ob die eine [[Klasse]] auf die in beziehungstehende [[Klasse]] zugreifen kann bzw. [[Objekt|Objekte]] dieser Klasse kennt. Die Navigierbarkeit wird meistens in den Designmodellen angegeben, in den Analysemodellen spielt die Navigierbarkeit selten eine Rolle. | ||
<html> | <html> | ||
<iframe width=" | <iframe width="280" height="157.5" src="https://www.youtube.com/embed/fjkoK6ed00E?si=tz_TuRFN-h9vMDxg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> | ||
</html> | </html> | ||
<html> | <html> | ||
<iframe width=" | <iframe width="280 height="157.5" src="https://www.youtube.com/embed/b-RueUJeZHM?si=m2xpodntDTBjNIB5" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> | ||
</html> | </html> | ||
| Zeile 167: | Zeile 172: | ||
Unidirektional | === Unidirektional === | ||
Zeigt der Pfeil von Termin nach Kunde, ist dieses Design durch die oben aufgeführte Implementierung ebenfalls bereits realisiert. Ein Termin kennt seinen Kunden, in dem man dem Zeiger auf die Kundeninstanz folgen und dieses Objekt aufgerufen werden kann. Außerdem wurde für diesen Fall noch ein Kreuz ans andere Ende der Beziehung modelliert, um sicherzustellen, dass kein Kunde seine Termine aufrufen kann. | Zeigt der Pfeil von Termin nach Kunde, ist dieses Design durch die oben aufgeführte Implementierung ebenfalls bereits realisiert. Ein Termin kennt seinen Kunden, in dem man dem Zeiger auf die Kundeninstanz folgen und dieses Objekt aufgerufen werden kann. Außerdem wurde für diesen Fall noch ein Kreuz ans andere Ende der Beziehung modelliert, um sicherzustellen, dass kein Kunde seine Termine aufrufen kann. | ||
| Zeile 174: | Zeile 179: | ||
Da ein Kunde beliebig viele Termine haben kann, benötigen wir ein Hilfsobjekt, dass es ermöglicht, eine beliebige Anzahl von Referenzen zu verwalten. Es gibt eine Vielzahl an dynamischen Datenstrukturen um die Beziehungen zwischen Kunde und Termin zu verwalten. Exemplarisch wird für die folgende Implementierung die ArrayList eingesetzt. | Da ein Kunde beliebig viele Termine haben kann, benötigen wir ein Hilfsobjekt, dass es ermöglicht, eine beliebige Anzahl von Referenzen zu verwalten. Es gibt eine Vielzahl an dynamischen Datenstrukturen um die Beziehungen zwischen Kunde und Termin zu verwalten. Exemplarisch wird für die folgende Implementierung die ArrayList eingesetzt. | ||
<syntaxhighlight lang="java"> | |||
public class Kunde { | public class Kunde { | ||
| Zeile 185: | Zeile 190: | ||
} | } | ||
} | }</syntaxhighlight> | ||
Durch die Methode fuegeTerminHinzu kann ein Objekt der Klasse Termin der terminListe hinzugefügt werden. Die terminListe verweist auf ein Objekt der Klasse ArrayList. Hier können beliebig viele Zeiger auf Termin Objekte verwaltet werden. Somit ist der Zugriff auf Termin eines Kunden möglich. | Durch die Methode fuegeTerminHinzu kann ein Objekt der Klasse Termin der terminListe hinzugefügt werden. Die terminListe verweist auf ein Objekt der Klasse ArrayList. Hier können beliebig viele Zeiger auf Termin Objekte verwaltet werden. Somit ist der Zugriff auf Termin eines Kunden möglich. | ||
Bidirektional | === Bidirektional === | ||
Die Bidirektionalität ergibt sich durch die Kombination der beiden unidirektionalen Varianten. Die Pfeile zeigen von Termin auf Kunde und von Kunde auf Termin. Folgende Implementierung realisiert das bidirektionale Design: | Die Bidirektionalität ergibt sich durch die Kombination der beiden unidirektionalen Varianten. Die Pfeile zeigen von Termin auf Kunde und von Kunde auf Termin. Folgende Implementierung realisiert das bidirektionale Design: | ||
<syntaxhighlight lang="java"> | |||
public class Kunde { | public class Kunde { | ||
| Zeile 216: | Zeile 221: | ||
} | } | ||
} | }</syntaxhighlight> | ||
== static == | |||
[[Datei:Static UML.png|mini]] | |||
Statische [[Attribut|Attribute]] und [[Methode|Methoden]] werden in [[UML]] mittels Unterstrich dargestellt. So sind im unteren Schaubild die [[Instanzvariable|Instanzvariablen]] count und die Methode get_count() statisch. | |||
[[Kategorie:Modellierung]] | |||
[[Kategorie:FI_I_SDM]] | |||
[[Kategorie:AHR_I_Informatik_LK]] | |||
[[Kategorie:AHR_WuV_WI_GK]] | |||
[[Kategorie:FI_I_TP1]] | |||