UML Aufgabe

[Nino9612]

Hallo Community,

folgende Aufgabenstellung ist gegeben: 

Die Lösung lautet wie folgt: 

Wie kommt man basierend auf dem Klassendiagramm auf diese Variable?

Ich habe eine Vermutung das es wegen der 

Zitat

<<create>>+Reservierung()

Methode ist, bin mir hier aber nicht sicher, kann mir ebenso nicht zusammen reimen wie ich diese darstellung der methode verstehenen soll.

Kann mir das jemand genauer erklären?

Danke Nino

Bearbeitet 27. September 2017 von Nino9612

[Rienne]

Das liegt an der Verbindung zwischen den beiden Klassen (Komposition und Aggregation). Die Reservierungsliste enthält Null bis beliebig viele Reservierungen. Daher werden die Reservierungen in Form einer Liste in die Reservierungsliste eingebunden.

Und nein, das hat nichts mit dem <<create>> Reservierung() zu tun. Das ist nur der (bzw. ein) Konstruktor der Klasse Reservierung. Eigentlich muss dieser auch nicht explizit aufgeführt werden, zumal es der Standardkonstruktor ist, dem keine Parameter mitgegeben werden. Aber vermutlich ist er aufgeführt, damit er bei der Umsetzung berücksichtigt wird und die Variable reservierungsID initialisiert wird (bzw. eigentlich sollte dort eine ID vergeben werden, was durch den Kommentar angedeutet wird).

Bearbeitet 27. September 2017 von Rienne

[Nino9612]

@Rienne Vielen Dank für deine Antwort. Okay das mit der Aggregation habe ich nicht beachtet. Kannst du mir jedoch erklären wie das hier verstehen soll? 

Zitat

<<create>>+Reservierung()

Ich kann ja schlecht einfach basierend auf einer annahme die <List> variable erstellen. Die musst ja irgendwo definiert sein

Bearbeitet 27. September 2017 von Nino9612

[Rienne]

Das mit dem <<create>> habe ich mittels Bearbeitung schon versucht zu erklären.

vor 3 Minuten schrieb Nino9612:

Ich kann ja schlecht einfach basierend auf einer annahme die <List> variable erstellen. Die musst ja irgendwo definiert sein

Das ist ja keine Annahme, sondern eine, aus dem Diagramm ersichtliche, Tatsache. Wenn ein Objekt mehr als einmal in einem anderen Objekt vorkommen kann, sollte dieses dort als Datentyp, der mehrere Elemente dieses Objektes enthalten kann, existieren.

Bearbeitet 27. September 2017 von Rienne

[Nino9612]

vor 51 Minuten schrieb Rienne:

Das mit dem <<create>> habe ich mittels Bearbeitung schon versucht zu erklären.

Das ist ja keine Annahme, sondern eine, aus dem Diagramm ersichtliche, Tatsache. Wenn ein Objekt mehr als einmal in einem anderen Objekt vorkommen kann, sollte dieses dort als Datentyp, der mehrere Elemente dieses Objektes enthalten kann, existieren.

Das heißt die "Syntax" <<create>> steht für den Konstruktor?

[arlegermi]

vor 1 Stunde schrieb Nino9612:

Wie kommt man basierend auf dem Klassendiagramm auf diese Variable?

Auf genau diese Variable kommt man gar nicht. Das ist ein Implementierungsdetail, das aus dem Modell nicht ersichtlich ist. Das einzige, was das Modell (implizit) vorgibt, ist eine Möglichkeit, eine Menge von Reservierungen referenzieren zu können (und in diese Menge Reservierungen einzufügen bzw. zu entfernen).

Auf welche Weise du diese Anforderung realisierst, ist dir komplett selbst überlassen. Eine Liste ist einfach eine simple, leicht zu verstehende Umsetzung.

[Rienne]

@Nino9612 ja

[etreu]

<<create>> ist vom Benutzer definierter Stereotyp. Ich kenne vor allem <<construct>> bzw. <<constructor>> (analog dazu auch Destruktor) und <<interface>> oder in anderen Diagrammen auch <<component>>. 

Ist soweit nicht fest vorgegeben. Der Name sollte sprechend bzw. den Lesern bekannt/ verständlich sein.

[Whiz-zarD]

vor 2 Stunden schrieb arlegermi:

Auf welche Weise du diese Anforderung realisierst, ist dir komplett selbst überlassen. Eine Liste ist einfach eine simple, leicht zu verstehende Umsetzung.

Da ist das Klassendiagramm eben sehr inkonsequent, weil im Klassendiagramm auch private Felder und private Methoden aufgelistet werden sollen, die mit der Schnittstelle nach Außen nichts zu tun haben. Private Felder- oder Methoden sind ebenfalls vom Entwickler abhängig. Der Entwickler kann also durchaus auf die Idee kommen, einen Einzeiler in eine Methode zu packen, damit diese Zeile einen sprechenden Namen hat, wenn es nicht sofort ersichtlich ist, was diese Zeile eigentlich tut. Diese Methode würde ebenfalls im Klassendiagramm auftauchen aber ohne den Kontext zu kennen, wird es schwer, zu verstehen, was sie dort soll.

Wenn man also schon solche Details weglässt, wie die Definition der Liste, dann sollte im Klassendiagramm auch nur die Schnittstelle nach Außen und deren Abhängigkeiten sichtbar sein, denn alles andere ist Sache des Entwicklers und auch der verwendeten Sprache. Die aufgeführten Felder brauche ich in C# nicht mal und könnte sie als Properties abbilden. Der Compiler macht daraus zwar private Felder aber sie wären im Code nicht sichtbar. In Java bräuchte man sie hingegen schon.

Auch der aufgeführte Konstruktor ist in C# nicht relevant, weil Felder über den Memory Manager immer mit einem Default-Wert initialisiert werden.  Man kann aus Zusätzlicher Absicherung die Initialisierung hinschreiben aber die würde der Compiler wegoptimieren.

Das Klassendiagramm vermischt also zwei Sachen: Es wird vorgegeben, wie die Klasse nach Außen und Intern auszusehen hat aber gleichzeitig gibt man den Entwickler freie Hand, wie er die Verbindungen implementiert. Das passt einfach nicht zusammen. 

Bearbeitet 27. September 2017 von Whiz-zarD
Typo

[Rienne]

Naja, dass UML-Diagramme nicht das Allheilmittel sind, ist ja hingehend bekannt. Sie dienen aber dazu technische Aspekte für Außenstehende verständlich machen und bietet eine Form der vereinfachten Darstellung.

Die IHK hat ja auch schon mehr als einmal in ihren Prüfungen bewiesen, dass die, die die Prüfung entwerfen, selbst oftmals nicht wirklich Ahnung haben, was wo wie warum möglich ist.

[arlegermi]

vor 34 Minuten schrieb Whiz-zarD:

Da ist das Klassendiagramm eben sehr inkonsequent, weil im Klassendiagramm auch private Felder und private Methoden aufgelistet werden sollen, die mit der Schnittstelle nach Außen nichts zu tun haben.

Jupp, da hast du recht. Ich habe nie wirklich den Sinn darin gesehen, in Modellen die Implementierungsdetails abbilden zu wollen. Das ist in meinen Augen die falsche Abstraktionsebene (sicher gibt's auch hier Ausnahmen).