Jump to content
Melde dich an, um diesem Inhalt zu folgen  

UML Aufgabe

Empfohlene Beiträge

Hallo Community,

folgende Aufgabenstellung ist gegeben: 

image.png.5a6e5b0d1425282602ee220c3b637379.png

Die Lösung lautet wie folgt: 

image.png.336a2d0e8870116c0ad27afac372d60b.png

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 von Nino9612

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von Rienne

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

@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 von Nino9612

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von Rienne

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

<<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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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 von Whiz-zarD
Typo

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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).

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Nimm an der Diskussion teil

Du kannst jetzt hier posten und Dich später registrieren. Wenn Du bereits über eine Konto verfügst, melde Dich jetzt an, um mit Deinem Konto zu posten.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Melde dich an, um diesem Inhalt zu folgen  

Fachinformatiker.de, 2019 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung