Hey, ich hoffe das passt irgendwie in dieses Forum rein, ich hab leider keine Ahnung wo ich es sonst posten könnte.
Mache grade folgende Übungsaufgabe:
Sie designen einen OnlineShop. Der Benutzer kann online einen Produktkatalog durchsuchen und sich dann die Produktbeschreibungen anschauen. Gefällt ihm der Artikel, so kann er diesen in seinen Warenkorb legen. Voraussetzung ist, dass er sich als registrierter Benutzer legtimiert hat. Am Ende dieses Vorgangs kann der Benutzer seinen Warenkorb bestätigen und eine Bestellvorgang wird im System ausgelöst.
Aufgabe:
Erstellen Sie ein Klassendiagramm, dass diesen Anfordernungen genügt und notieren Sie die wesentlichen Vererbungen, Methoden, Attribute und Assoziationen. Kommentieren Sie Ihre Designentscheidungen, so dass klar wird was Sie damit ausdrücken wollen.
Ich hab von diesen UML Diagrammen wenig Ahnung muss ich gestehen und habe keine wirkliche Ahnung wie man das angeht.
Mein erster naiver Ansatz wäre sowas:
(Multiplizitäten konnte man bei dem Online-Tool leider nicht richtig eintragen und Methoden + Attribute habe ich erstmal rausgelassen. Man soll nur erkennen, wie ich es ungefähr meine).
Ist das überhaupt ein richtiger Ansatz? Ich tuhe mich jetzt schwer, wie ich ausdrücke, dass ein registrierter Benutzer Produkte zum Warenkorb hinzufügt. Da brauche ich ja irgendwie eine Beziehung zwischen drei Klassen.
Und wie designed man den letzten Teil sinnvoll? Also die Bestätigung + den Bestellvorgang im System.
Die Aufgabe lässt vermuten, dass man irgendwelche Design Pattern verwenden soll.
Hoffe mir kann da jemand helfen.
Dass Du Dich mit dem Modellieren von Aktionen (bspw. Produkte hinzufügen) im Klassendiagramm schwer tust, liegt nicht an Dir. Für die Modellierung von Aktionen gibt es in der UML andere Diagrammtypen (Use Case, Activity, Sequence etc.). Das Klassendiagramm ist ein Strukturdiagramm (was gibt es). Du musst Dir hier also “nur” überlegen, welche Datenstrukturen (Klassen, Felder, Methoden) wahrscheinlich nötig sind, um die gewünschten Aktivitäten zu füttern.
Die anzuwendenden “Patterns” (eigentlich nicht ganz korrekt) sind die best practices der Objektorientierung. Wichtige Stichpunkte sind “ist ein” für Vererbungsbeziehungen und “kennt, verwendet, gehört zu” etc. für Assoziationen.
Das zum Allgemeinen. Zu Deinem ersten Lösungsansatz:
Zwei Unterklassen für unregistrierte und registrierte Benutzer sind sehr fragwürdig
Ich würde eher den Warenkorb seinen Nutzer kennen lassen und nicht umgekehrt.
Ein Nutzer ist unabhängig von einem Warenkorb existent. Der Warenkorb aber nicht ohne Nutzer (Stichwort existenzielle Abhängigkeit also von der Assoziation über die Aggregation zur Komposition).
Ein Warenkorb muss die Produkte kennen, die in ihm enthalten sind.
Lieber noch mal zurückgehen und sich mit den Feinheiten der Klassendiagramme beschäftigen.
Ich würde eher den Warenkorb seinen Nutzer kennen lassen und nicht umgekehrt.
Ein Nutzer ist unabhängig von einem Warenkorb existent. Der Warenkorb aber nicht ohne Nutzer (Stichwort existenzielle Abhängigkeit also von der Assoziation über die Aggregation zur Komposition).
Wenn ich das jetzt mittels Komposition machen sollte, wäre das so richtig?
Dann könnte ein Warenkorb nicht ohne Benutzer existieren.
Wäre damit aber auch der Punkt erfüllt, dass der Warenkorb seinen Nutzer kennt und nicht umgekehrt?
Für mich sieht es erstmal so aus, als würde das Ganze das Teil kennen. Also der Benutzer den Warenkorb.
[quote=Tarrew]Wenn ich das jetzt mittels Komposition machen sollte, wäre das so richtig?[/quote]Kompositum ist ersmal korrekt.
[quote=Tarrew;123310]Wäre damit aber auch der Punkt erfüllt, dass der Warenkorb seinen Nutzer kennt und nicht umgekehrt?[/quote]Dass ist jetzt erst mal nicht so wichtig.
Dein Lehrer will, das Du Deine Absicht mit UML ausdrückst, und nicht die von nillehammer…
Die Frage, ob besser der Warenkorb den Benutzer kennt oder umgekehrt sollte nämlich auch berücksichtigen, über welchen Weg üblicher Weise auf den Warenkorb zugegriffen wird.
Und nochmal als Tipp: sein sparsam mit Vererbung.
Hat ein registrierter User (aus Sicht der Anwendung) tatsächlich ein anderes Verhalten oder “nur” andere Eigenschaften als ein unregistrierter?
Wer was „kennt“ wird durch die Navigationsrichtung modelliert, die graphisch durch Pfeile repräsentiert ist. Das ist ein anderer Aspekt als die Aggregation/Komposition. Es ist wichtig, das gedanklich klar zu trennen. Du sprichst aber in der Tat aber einen viel diskutierten Punkt an:
Allein graphisch würde der Pfeil an der Raute irgendwie „blöd“ aussehen. Es ist in der UML aber zulässig.
Durch Komposition wird eine existenzielle Abhängikeit ausgedrückt, aber auch eine Ganzes-Teil-Beziehung.
Nachdem ich das jetzt so sehe, würde ich doch zu einer einfachen Assoziation mit Navigationsrichtung Warenkorb zu Nutzer raten und die existenzielle Abhängigkeit durch die Multiplizitäten oder durch einen Constraint „not null“ ausdrücken. (Constraints sind in Klassendiagrammen zulässig. In der UML gibt es dafür sogar eine eigene Notation, die OCL). Sorrry für diesen Umweg.
Edit: Ja, TT hat Recht! Auch wenn ich hier so weise auftrete, ist es natürlich meine Sicht der Dinge und nicht der Weisheit letzter Schluss
Registered könnte beispielsweise ein boolsche Flag in der Benutzer Klasse sein, du kannst in einem Klassendiagram deinen Klassen ja auch Felder zuweisen.
Genauso hätte dein Warenkorb eine Collection die die Produkte des Users hortet. Also den Klassen-Content nicht vernachlässigen.
