Fachklassenmodell

[Chrysotomus]

Hey Leute, dieses Fachklassenmodell ist noch nicht vollständig. Damit jeder einen groben Plan hat, was man im Fachklassenmodell braucht, beschreibe ich das kurz im ersten Absatz. Jeder der das schon weiß, kann den ersten Absatz überspringen.

In einem Fachklassenmodell müssen die wichtigsten fachlichen Gegenstände des zu entwickelnden Systems repräsentiert und ihre Zusammenhänge modelliert werden. Dafür muss man den Assoziationen eine Benennung (und eine Richtung im Namen) geben. Wenn diese mal feststehen, kann man unser Programmkonzept möglichst detailliert aufbereiten. Sobald das Grundgerüst mit Klassen und Assoziationen steht, müssen noch Kardinalitäten ergänzt werden. Wer genauere Infos möchte, findet diese auf Seite 78 in Österreichs Buch - und ein Beispielmodell auf Seite 79.

Fragen die ich habe und Probleme, auf die ich gestoßen bin: 1) Auf den ersten Blick dürfte man direkt feststellen, dass die Kardinalitäten fehlen. Ich habe leider wirklich Probleme, diese zuzuordnen. Ich denke es kommt auch irgendwie darauf an, aus welcher Perspektive man dieses Diagramm betrachtet. Ist der User eine Person und immer ein und das Selbe? Oder ist der User ein Element einer Gruppe und dementsprechend kann dieser mehrmals/einmalig in einer Kardinalität auftreten. 2) Mir ist keine Benennung für die Assoziation zum 'STOPP'-Skill eingefallen. 3) Müsste der Stopp-Skill mit allen anderen Skills, verbunden sein, weil er diese ja stoppen kann? (So würde ich dann auch die Assoziation nennen: 'stoppt ->') 4) Gibt es eine Möglichkeit, den User noch bestimmen zu lassen, welchen Account vom ZPA System ihm gehört? Soll ich vielleicht noch eine Zwischenklassen namens Accounts erstellen? Dann verbinde ich Kalender/Stundenplan (holt von->) mit Account. Dieser wird dann mit mit ZPA verbunden (gehört zu->) 5) Soll dieses Diagramm womöglich weniger ausgebaut sein (Zum Beispiel Wetter wegnehmen), da wir das nicht alles im Sprint 0 oder Sprint 1 umsetzen werden?

Weitere Feinheiten: 1) Ich bin mir nicht sicher, ob die Benennung der Assoziationen nicht schöner lauten könnte. Ich bin für Vorschläge offen. 2) Eigentlich müsste am Ende des Namens der jeweiligen Assoziation eine dicke ausgemalte Pfeilspitze sein. Ich habe dafür allerdings kein Symbol gefunden und deswegen einen leichten gewöhnlichen Pfeil gemacht. 3) Passt der Name der Klasse 'Wetterstation'?

[kkaiser12]

Hier mal meine Meinung zu den einzelnen Punkten:

1 Also ich hätte gesagt, dass es nur einen User gibt.

2./3. Ich fände es logisch, wenn der stop-Use Case mit allen anderen verbunden ist, weil man ja den Skill an jeder Stelle stoppen können sollte.

4. Das mit der Accountverknüpfung ist eine gute Frage, das haben wir bisher gar nicht bedacht. Soll das in die Fächergegenstandszuordnung oder zu help oder ein eigener Use Case werden? Von der Logik her könnte das sogar noch ein eigener Use case werden, meiner Meinung nach passt es zu keinem anderen Es wäre super, wenn hierzu jeder nochmal seine Meinung abgeben könnte.

5. Ich glaube in den Product Backlog kommen alle Ideen. Diejenigen, die man aktuell umsetzt kommen dann in den Sprint Backlog, daher sollte das so passen.

[Chrysotomus]

Danke für die Rückmeldung. Es hat sich nach ein bisschen Rücksprache mit Frau Socher jedoch herausgestellt, dass das Fachklassendiagramm eigentlich etwas komplett anderes beschreibt, als ich ursprünglich dachte. Deswegen musste ich ein neues erstellen. Damit alle der Änderung folgen können: Ein Fachklassendiagramm beschreibt welche Instanzen von Klassen mit anderen Instanzen interagieren. Dabei ist wichtig, welche Rolle diese bei Assoziationen auf sich gegenseitig haben, und welche Kardinalitäten auftreten. Objektvariablen und Methoden sind rein optional, also habe ich das mal mit reingenommen. Ich freue mich auf schnelle Rückmeldung, ob euch das allen so passt!

[Chrysotomus]

Äußere Einflüsse oder Verbindungen spielen in dem Fachklassendiagramm noch keine Rolle. Das bedeutet, dass ich die Wetterstation und den Speicher weglassen konnte, oder gar sollte. Diese Version sieht zwar recht schlank aus, ist jedoch grundsätzlich denke ich genau das, worauf unser Projekt basiert

Achja, ich kann mir gut vorstellen, dass ich die Variable 'Fächer' im Kalender löschen könnte, bin mir allerdings nicht sicher.

[kkaiser12]

Ok, sieht gut aus. Kann man die Gegenstände dann nur aus dem Enum auswählen? Das einzige, was ich mich noch frage, ist, ob man noch irgendwo den Wettertipp modellieren muss, ich hab aber auch grade keine Idee, wie.

[Chrysotomus]

Ich hatte die Idee das wie folgt zu erweitern, wenn man möchte:

Fach wird eine abstrake Basisklasse. Es gibt Pflichfächer, das sind die, die im ZPA stehen, und es gibt freiwillige Fächer, die man dann noch hinzufügen kann. Das wären zum Beispiel AW-Fächer. Das selbe würde ich mit Gegenständen machen. Anstatt des Enums, eine abstrake Klasse, die Gegenstände und einpackbare Dinge darstellt. 3 konkrete Klassen erben davon. Einmal die Materialien, die Vorlesungspezifisch sind, zum Beispiel, rote oder blaue Ordner. Eine Klasse für allgemeine Gegenstände die man immer brauchen kann, wie zum Beispiel Block, Federmäppchen und Laptop. Die dritte Klasse wäre dann wetterbedingte Materialien

[kkaiser12]

Ok, hört sich gut an. Ich hatte nur nicht genau verstanden, wie das mit dem Enum zusammenhängt, aber jetzt hat sich das geklärt.

[Chrysotomus]

Oh sorry, dass ich das nicht klar gestellt habe. Wenn du zur Sicherheit nochmal eine Referenz möchtest. Das habe ich von einer der ersten Seiten des Foliensatzes zu Webservices auf Moodle. Da wird 'Color' auch in einem Enum gespeichert.

[ngaeng]

sieht gut aus finde ich

[Chrysotomus]

Hey Leute, ich habe das Fachklassendiagramm geupdatet. Es wäre super, wenn Ihr alle kurz mal Rückmeldung geben würdet, ob euch das so auch noch passt. (Auch wenn ich denke, dass das eigentlich alles passen dürfte.) Ich mache mich auch schonmal an ein Klassendiagramm, das die ganze ZPA Schnittstelle beschreibt.

[Chrysotomus]

So, das Fachklassenmodell, dass die Businesslogik klar machen soll ist jetzt auch auf dem aktuellsten Stand. Bitte einmal drüber sehen

[ngaeng]

Sieht passend aus find ich. Ist das Lecture dann einfach repräsentativ für das, was über die Datenbank abgewickelt wird? Wenn du fertig bist kannst dus auf der Wiki Seite mit den UML Diagrammen (auch wenn die vermutlich nicht mehr angeschaut wird) hinzufügen bzw bei den Github Pages.

[Chrysotomus]

Passt, danke. Also ich habe für Lecture jetzt nicht in die Datenbank gesehen, aber ich werde anhand dessen eh nur erklären, was der Grundgedanke von allem war und wie wir aus der Business-Idee dann eine technische gemacht haben.

[Chrysotomus]

Oh, ich habe eben festgestellt, dass du es schon auf dem Wiki verlinkt hast, danke dafür. Ich habe mir mal die Freiheit genommen im Wiki die Reihenfolge der Diagramme zu ändern, damit wir während der Präsentation nicht unorganisiert hin und her scrollen müssen