Klassendiagramm: Unterschied zwischen den Versionen
Thomas (Diskussion | Beiträge) Die Seite wurde neu angelegt: „== Einführung == Ein Klassendiagramm ist ein Strukturdiagramm der Unified Modeling Language (UML) zur grafischen Darstellung (Modellierung) von Klassen, deren Elementen und Beziehungen. Eine Klasse ist in der Objektorientierung ein abstrakter Oberbegriff für die Beschreibung der gemeinsamen Struktur und des gemeinsamen Verhaltens von Objekten. Für die Sicht auf einen Programmentwurf sind Klassendiagramme einer der wic…“ |
Keine Bearbeitungszusammenfassung |
||
| (9 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 67: | Zeile 67: | ||
<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. | ||
Sowohl die Komposition als auch die Aggregation sind Teil-von- bzw. Besteht-aus-Beziehungen. Wir können zum Beispiel modellieren, dass eine Bestellung aus den Bestellungspositionen oder dass eine Fußballmannschaft aus ihren Spielern besteht (http://openbook.galileocomputing.de/oo/oo_04_strukturvonooprogrammen_002.htm#Rxxob04strukturvonooprogrammen002040015221f03719e). | Sowohl die Komposition als auch die Aggregation sind Teil-von- bzw. Besteht-aus-Beziehungen. Wir können zum Beispiel modellieren, dass eine Bestellung aus den Bestellungspositionen oder dass eine Fußballmannschaft aus ihren Spielern besteht (http://openbook.galileocomputing.de/oo/oo_04_strukturvonooprogrammen_002.htm#Rxxob04strukturvonooprogrammen002040015221f03719e). | ||
===== | =====Aggregation ===== | ||
Aggregation ===== | |||
Von einer Aggregation sprechen wir, wenn ein [[Objekt]] ein Teil von mehreren zusammengesetzten Objekten sein kann. Die zusammengesetzten Objekte nennen wir in diesem Fall Aggregate. Die Lebensdauer der Teile kann dabei länger sein als die Lebensdauer der Aggregate. | Von einer Aggregation sprechen wir, wenn ein [[Objekt]] ein Teil von mehreren zusammengesetzten Objekten sein kann. Die zusammengesetzten Objekte nennen wir in diesem Fall Aggregate. Die Lebensdauer der Teile kann dabei länger sein als die Lebensdauer der Aggregate. | ||
| Zeile 102: | Zeile 102: | ||
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 126: | Zeile 126: | ||
} | } | ||
</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 168: | Zeile 171: | ||
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 175: | Zeile 178: | ||
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 186: | Zeile 189: | ||
} | } | ||
} | }</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 217: | Zeile 220: | ||
} | } | ||
} | }</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]] | |||