Bewertung der 1. Malefizabgabe

Alle mit FIXME gekennzeichneten Punkte müssen behoben und nachgereicht werden. Geschieht es nicht mache ich mir Gedanken über die Punktabzüge.

Es sind 20 Punkte zu erreichen (10 für Use-Case, 10 für Klassendiagramm).

Gruppe 1 (A)

FIXME: Use Case: Aktoren beschreiben, und dabei auch begründen warum ihr zwischen Spieler und Spielleiter unterscheidet.
FIXME: Use Case: Keine Vor-/Nachbedindungen
FIXME: Use Case: "Zielfeld wählen": Hier fehlt die Beschreibung wie sich das Zielfeld aus dem Würfelergebnis ergibt und die Auswirkung von Blockaden auf den Zug.
FIXME: Use Case: extend-Beziehungen zwischen Use-Cases auf beiden Seiten der Beziehung beschreiben, jeweils mit einer kurzen Zusammenfassung der Aktionen im jeweils anderen Use-Case.
FIXME: Klassen: "CFeld::FeldInfo": ich würde nicht empfehlen Integer-Werte für Feld-Infos zu verwenden. Mir ist ehrlich gesagt nicht klar was das überhaupt für Infos sein sollen. Es kommt mir aber so vor als wäre das eine Stufe zu detailliert, also erst in der nächsten Modellierungsstufe von Bedeutung. Nehmt es hier noch raus, oder modelliert und erklärt es so dass mir alles klar wird.
FIXME: Klassen: Interfaces gibt es in C++ nicht, euer "CFeldInAktion" ist wohl eine abstrakte Klasse ? Ist die Trennung von CFeld und CFeldInAktion überhaupt nötig ?
FIXME: Klassen: Die nicht erklärten Klassen für den Spielabauf (links unten unleserlich im Diagramm) bitte dort entfernen, das sieht nicht schön aus.

Use-Case-Beschreibung hätte detaillierter sein können, mir fehlt noch einiges an Spielregel-Bezug. Aktoren und Vor-/Nachbedingungen fehlen komplett.
Klassendiagramm OK.

Update 10.06.2006:

FIXME: Klassen: Verbindung von Sperre zu Feld fehlt (wie im Praktikum am 7.6. besprochen).

FIXME: Klassen: CSperrstein darf nicht von CFeld abgeleitet werden (wie im Praktikum am 7.6. besprochen).

FIXME: Klassen: Verbindung von Start-/Zielfeld zu Spieler fehlt (wie im Praktikum am 7.6. besprochen).

FIXME: Klassen: Vererbungen so anordnen dass die Parent-Klasse oben steht, die Subklassen baumartig darunter.

FIXME: Klassen: "CFeld::FeldInfo": ich würde nicht empfehlen Integer-Werte für Feld-Infos zu verwenden. Mir ist ehrlich gesagt nicht klar was das überhaupt für Infos sein sollen. Es kommt mir aber so vor als wäre das eine Stufe zu detailliert, also erst in der nächsten Modellierungsstufe von Bedeutung. Nehmt es hier noch raus, oder modelliert und erklärt es so dass mir alles klar wird.

FIXME: Klassen: CFeldInAktion: warum ist eine Subklasse von CFeld nötig ? Die ganzen Methoden können auch in CFeld gepackt werden oder ?

FIXME: Klassen: Was ist der Unterschied zwischen CFeld::FeldInfo und CFeld::GibFeld ? Beschreibung ist in Subklassen überall identisch, nur aus der Beschreibung von CFeld ist erkennbar was gemeint ist. Hier hätte in den Subklassen die Beschreibung der konkreten Implementation hingehört ("gibt den Typ 'Startfeld' zurück)

Use-Case-Beschreibungen sind spitze. Die "extends"-Use-Cases hätten wie Standalone-Use-Cases beschrieben werden sollen, nicht als Teil des Use-Cases den sie erweitern. Siehe mein Kommentar zur ersten Version: "extend-Beziehungen zwischen Use-Cases auf beiden Seiten der Beziehung beschreiben, jeweils mit einer kurzen Zusammenfassung der Aktionen im jeweils anderen Use-Case." 9,5/10 Punkte
Klassen müssen noch nachgebessert werden (wurde ja auch so im Praktikum besprochen). Deshalb noch keine vorläufige Punktzahl.

Update 17.08.2006:
Die Klasse "CSperrstein" wurde entfernt. Verbindung von Start-/Zielfeld zu Spieler ist da.
Da kein explizites FIXME des Domänen-Klassen-Diagramms nachgereicht wurde (nur Klassendiagramm aus finaler Abgabe) lege ich die Punktzahl auf 8 Punkte fest.
Also ainsgesamt 17,5/20 Punkte.

Gruppe 2 (B)

FIXME: Use Case: Aktoren sind nicht beschrieben.
FIXME: Use Case: Vor-/Nachbedingungen fehlen.
FIXME: Use Case: Diagramme nicht als Screenshot ! Im Together habt ihr im Menü "File" die Option "Save Image".
FIXME: Use Case: "Spielsteine blockiert": Bitte erklärt was "blockiert" bedeutet (Spielregeln erklären).
FIXME: Use Case: "Spielstein auswählen": Wie sich die Zielfelder ermitteln wird erst im nächsten Use-Case beschrieben, in diesem Use-Case hätte mindestens ein Hinweis darauf hingehört.
FIXME: Use Case: "Spiel beenden" mit Speichern: Das ist wahrscheinlich eine "extend"-Verbindung zu "Speichern".
FIXME: Use Case: Die Extend-Beziehung von "Zielfeld wählen" sind nicht beschrieben.
FIXME: Klassen: Warum die Unterscheidung zwischen CPersonDaten und CSpieler ? In der Beschreibung findet sich keine Begründung dafür. Fasst die beiden Klassen entweder zu einer zusammen oder erklärt in der Beschreibung warum eine Trennung sinnvoll ist.
FIXME: Klassen: CNormalStein: Die Assoziationsbeziehungen in der Beschreibung sind anders als die im Diagramm.
FIXME: Klassen: CSpielstein: "Stellt Attribute für Unterklassen zur Verfügung". Und was sind das für Attribute ?
FIXME: Klassen: Es gibt keine Verbindung vom Spieler zu seinen Start- und Zielfeldern.
FIXME: Klassen: Die "Nachbar links/rechts/oben/unten"-Assoziation zwischen den Feldern fehlt.
FIXME: Klassen: Assoziationen in der Doku nicht nur durch "hat Assoziation zu..." abdecken sondern die Funktion dieser Assozation beschreiben. Z.B. beim Sperrstein: "Ein Sperrstein steht immer auf einem CNormalFeld".
FIXME: Klassen: Es fehlen die Membervariablen die sich direkt aus den Assoziationen ergeben (z.B. die Liste der Spielfiguren im CSpieler). Die hätten schon in dieser Designstufe ins Diagramm und natürlich auch in die Beschreibung gehört.

Einige Nachbesserungen an den UseCases (Aktoren und Vor-Nachbedingungen sowie Kleinkram).
Das Klassendiagramm und die dazugehörige Doku müssen nochmal überarbeitet werden.

Update 08.06.2006:

FIXME: Use Case: Aktoren-Beschreibung: ein Aktor ist die Rolle die ein Benutzer in einem Programm hat, wenn ihr also von zwei Rollen des Aktors sprecht dann müßten eigentlich zwei Aktoren in eurem Diagramm auftauchen, oder ihr müßt die Beschreibung ändern ;-).

FIXME: Use Case: Beschreibung von "Spielstein blockiert" ist falsch: alle Spielsteine müssen blockiert sein !

FIXME: Use Case: Beschreibung von "Spielstein auswählen" und "Zielfeld wählen" ist zu knapp, hier taucht viel zu wenig von den Spielregeln auf.

FIXME: Klassen: Warum haben Start-/Zielfeld keine Assoziation zum CNormalSpielstein ? Der Spielstein kann auch auf einem Start-/Zielfeld stehen.

FIXME: Klassen: CSpielfeld: "Stellt Methoden und Attribute für Unterklassen zur Verfügung". Und was sind das für Attribute ?

FIXME: Klassen: Es gibt keine Verbindung vom Spieler zu seinen Start- und Zielfeldern.

FIXME: Klassen: Die "Nachbar links/rechts/oben/unten"-Assoziation zwischen den Feldern fehlt.

FIXME: Klassen: Es fehlen die Membervariablen die sich direkt aus den Assoziationen ergeben (z.B. die Liste der Spielfiguren im CSpieler). Die hätten schon in dieser Designstufe ins Diagramm und natürlich auch in die Beschreibung gehört.

FIXME: Klassen: In der Beschreibung der Klassen muss bei den einzelnen Klassen beschrieben werden welche Teile der Anwendungslogik dort ablaufen (im Prinzip Verweise auf Use-Cases).

USe-Case: Vor-/Nachbedingungen schön detailliert. Spielregeln tauchen in den zugehörigen Use-Cases nicht komplett auf ("Spielstein wählen", "Zielfeld wählen"). 8/10 Punkte
Klassendiagramm-Doku viel zu knapp und mit fehlerhaften Klassenverbindungen. 4/10 Punkte

Update 29.06.2006:
Update aus der Abgabe "Malefiz 2".

FIXME: Use-Case-FIXMEs noch nicht behoben.
FIXME: Klassen: Es gibt keine Verbindung vom Spieler zu seinen Start- und Zielfeldern.

Klassendiagramm ist jetzt viel besser.
Aktuell: Use-Case 8/10 Punkte, Klassen: 9/10 Punkte.

Gruppe 3 (C)

FIXME: Use Case: Aktoren sind nicht beschrieben.
FIXME: Use Case: Vor-/Nachbedingungen fehlen.
FIXME: Use Case: Was ist der UseCase "Spielbrett laden" ? Hier war anhand der Beschreibung nicht erkennbar was der Unterschied zu "Spielstand laden" ist.
FIXME: Use Case: Was bedeuten die Angaben "useclass: ..." ?
FIXME: Use Case: "Ziehen" -> "Aussetzen": Aussetzen kann nur vorkommen wenn ALLE Figuren blockiert sind. Die Beschreibung ist an dieser Stelle nicht sehr deutlich.
FIXME: Use Case: Spieleditor: hier sollte geprüft werden ob ein Spielbrett sinnvoll ist (gibt es einen Weg von jedem Startfeld zum zugehörigen Zielfeld ? "Inseln", also unerreichbare Felder, verbieten).
FIXME: Use Case: "Spielbrett bearbeiten": hier machen die drei Extend keinen Sinn da durch die drei Extends der komplette UseCase "Spielbrett bearbeiten" in die drei Einzelusecases zerlegt wurde, also garnichts mehr davon übrig bleibt.
FIXME: Klassen: CFeld hat ein paar Attribute die nur für das Zeichnen benötigt sind (Radius). Das Zeichnen sollten separate "Render-Klassen" übernehmen, nicht die Datenklassen => raus mit den Attributen aus dem Klassendiagramm.
FIXME: Klassen: Das Umwandeln von CRegularFeld in ein Sperrfeld (wenn eine Sperre darauf gesetzt wird) ist keine gute Idee.
FIXME: Klassen: Start- und Zielfelder sollten Pointer auf Spieler haben.

Einige Nachbesserungen an den UseCases (Aktoren und Vor-Nachbedingungen sowie Kleinkram). Klassendiagramm ist bis auf Details OK.
1 Bonuspunkt für 149088 für Vorführen der StateChart am 07.06.2006.

Update 08.06.2006:

FIXME: In "Spielbrett laden" tauchen Elemente auf die eigentlich in "Neues Spiel starten" gehören (Spielerzahl und deren Daten eingeben)

FIXME: "Ziehen", Situation "Aussetzen": das Sperren-Überspringen gehört nicht in diesen Sonderfall sondern in die allgemeine Beschreibung.

FIXME: Was beschreibt der Abschnitt "Spieleditor" ? Einen Aktor oder ein System ?

FIXME: Da eure Anwendung aus zwei Systemen besteht (Spiel und Editor) sollten die Systeme auch beschrieben werden (pro System ein eigenes Kapitel in der Beschreibung, mit Aktor- und Use-Case-Beschreibungen aus dem jeweiligen System).

FIXME: In "Spielbrett bearbeiten" ist jetzt zuviel Logik gepackt (genau das Gegenteil aus der letzten Abgabe). Werft diesen Use-Case weg und hängt die Teile als Einzel-Use-Cases "Feld hinzufügen", "Feld verschieben", "Feld löschen" direkt an den Aktor !

FIXME: Worum hat das CFeld einen Pointer auf "CSpieler" ? Nur Start- und Zielfelder gehören zu einem Spieler.

Use-Cases sind weitgehend OK, nur im Spielbrett-Editor sollte "Spielbrett bearbeiten" nochmal verfeinert werden.
Aktuell: 17/20 Punkte

Gruppe 4 (D)

FIXME: Use Case: Ihr habt in der Beschreibung Use-Cases "Zug durchführen" und "Zugmöglichkeiten anzeigen", die es im Diagramm nicht gibt.
FIXME: Use Case: "Spielfigur bestimmen": Ihr schreibt "...werden ihm alle Möglichkeiten angezeigt, die der Spieler ... laufen kann...". Was sind das für Möglichkeiten ?
FIXME: Use Case: "Zielort bestimmen": hier sollten die möglichen "extends"-Pfade kurz erwähnt werden, mit Zusammenfassung der im "extends"-Use-Case ablaufenden Logik.
FIXME: Klassen: "CFeld::m_Spielstein": auf einem Feld können bis zu 5 Spielfiguren eines Spielers stehen, nicht nur eine.
FIXME: Klassen: Assozation zwischen CFeld und CSpielstein sollte "0..5" sein, nicht "1..5".
FIXME: Klassen: "CSpielstein wird von CFeld abgeleitet, da auf einem CFeld entweder eine Spielstein steht oder nicht.". Dieser Satz ist ziemlich falsch... Seid ihr sicher dass ihr "abgeleitet" meint ?
FIXME: Klassen: "CSpielfigur" gehört zu einem Spieler, diese Beziehung taucht nur im Diagramm auf, nicht in der Beschreibung.
FIXME: Klassen: "CSpieler": "Jeder Spieler besitzt 5 Spielfiguren, deshalb wird es von der Klasse CSpielfigur abgeleitet". Schon wieder scheint hier nicht "ableiten" gemeint zu sein ?
FIXME: Klassen: "CStartfeld" besteht aus 5 Feldern ? Meint ihr hier eine Beziehung zu CFeld, oder geht es nur um die zeichnerische Darstellung ?
FIXME: Klassen: Was ist ein CSperrfeld im Unterschied zu einem normalen Feld ? Eine Sperre kann im Spielverlauf auf fast jedem Feld landen. Ein CFeld wird zu einem Sperrfeld indem ein Sperrstein darauf gesetzt wird, aber eine eigene Klasse macht hier keinen Sinn (sonst müßte im Spielverlauf ein Normalfeld durch ein Sperrfeld ersetzt werden wenn ein Sperrstein abgesetzt wird).
FIXME: Klassen: CZielfeld - gleiches Problem wie bei CStartfeld: was meint ihr mit "besteht aus 5 Feldern" ?
FIXME: Klassen: In der Beschreibung der Felder fehlt irgendwo die Information dass auf die unterste Feldreihe keine Sperrsteine gesetzt werden dürfen.

Gute Aktoren-Beschreibung. Use-Cases sind schön ausführlich beschrieben, aber durch die 2 beschriebenen aber nicht vorhandenen Use-Cases ein wenig verwirrend.
Klassendiagramm hat einige Fehler, außerdem fehlt oft der Bezug der Klassen zum Ablauf im Use-Case- Diagramm (welche Teile eines Use-Case werden in einer bestimmten Klasse abgebildet ?). Hier ist noch einiges an Nachbesserungsbedarf.

Update 01.06.2006:

FIXME: In der Beschreibung taucht ein Use-Case "Anmelden der Spieler" auf, der nicht im Diagramm enthalten ist.

FIXME: Use Case: "Zielort bestimmen": hier sollten die möglichen "extends"-Pfade kurz erwähnt werden, mit Zusammenfassung der im "extends"-Use-Case ablaufenden Logik. Genauso sollte bei den "extends"-Use-Cases erwähnt werden an welchen anderen Use-Cases sie hängen.

FIXME: Bitte Vor- und Nachbedingungen beschreiben. Sollte ungefähr so aussehen (Beispiel für "Spielfigur bestimmen"):

Vorbedingung: Es sollte gewürfelt worden sein.
...Beschreibung des Use-Case...
Nachbedingung: Jetzt kann der Spieler ein Zielfeld wählen oder eine andere Spielfigur bestimmen.

FIXME: Klassen: In der Beschreibung von CFeld::m_Spielstein steht immer noch nicht die Information dass bis zu 5 Spielsteine auf dem Feld stehen können.

FIXME: Klassen: "Auf jedem CStartfeld steht ein CSpieler, dem jeweils ein CStartfeld zugewiesen wird". Der Satz ist nicht so ganz korrekt, und die Verbindungen zu CSpieler und CSpielfigur steckt bereits in den vorherigen Sätzen der Klassenbeschreibung.

FIXME: Klassen: Auf einem Feld können laut eurer Modellierung 0 bis 5 Figuren stehen. Das würde heißen dass auch bis zu 5 Sperren darauf stehen können. Vielleicht wäre es sinnvoller zwei Beziehungen zu modellieren: CFeld zu CSpielfigur (0..5) und CFeld zu CSperrstein (0..1). Dafür könnte die Assoziation zu CSpielstein raus. Das würde heißen dass ein CFeld zwei Membervariablen hat: Liste von CSpielfiguren die darauf stehen und einen CSperrstein-Pointer (NULL oder gültiger Wert).

Am Use-Case-Diagramm war nicht viel Verbesserung zu erkennen, Beschreibung ist immer noch OK. Aber bitte die Vor-/Nachbedingungen noch zufügen.
Im Klassendiagramm wurden einige Fehler behoben. Die Beschreibungen sind mir allerdings immer noch zu knapp (welcher Teil der Spiel-Logik läuft in der Klasse ab ? Welche Use-Case-Teile laufen hierüber ab ? ).
Da ihr mittlerweile eine 5er-Gruppe seid braucht ihr auch ein Use-Case-Diagramm für den Spielfeldeditor. Hier würde ich euch empfehlen ein eigenes System (=Use-Case-Diagramm) mit neuem Aktor zu zeichnen. Denkt natürlich auch an die Beschreibung des ganzen. Am Klassendiagramm ändert sich durch den Editor nichts, da die Datenklassen die gleichen bleiben.

Update 30.06.2006:
Vor-/Nachbedingungen sind jetzt gut beschrieben.
Spielbretteditor: Hier ist die Use-Case-Beschreibung zu knapp, sie besteht fast nur aus Vor- und Nachbedingungen. In den Auflistungen der Nachbedingungen stecken keine echten Use-Cases, das klingt nach Einzelteilen von Use-Cases.
An den Klassenbeschreibungen wurde nichts geändert (immer noch ein wenig zu knapp).
Use-Case: 8/10 Punkte. Klassendiagramm: 8/10 Punkte.

Gruppe 6 (F)

FIXME: Use Case: Warum die Trennung zwischen "Neues Spiel" und "Spielerdaten eingeben" ? Warum ein "include" ? Die Begründung sollte in der Beschreibung stecken.
Use Case: Die Use-Cases sind in der Beschreibung alphabetisch sortiert. Sinnvoller wäre eine logische Sortierung (z.B. nach Spielablauf). Das ist einer der Nachteile von generierter Doku.
FIXME: Use Case: "extends" und "include" auch in der Beschreibung der so verbundenen Use-Cases erwähnen (und kurze Zusammenfassung des Ablaufs im jeweils anderen Use-Case). Für "Würfeln" also z.B.: "Im Falle einer kompletten Blockade greift hier der Use Case "Aussetzen" (Runde wird für den aktuellen Spieler beendet).
FIXME: Klassen: bei "CFeld::GetNachbarXYZ" paßt die Beschreibung nicht zur Methodensignatur.
FIXME: Klassen: Document/View sind in dieser Stufe des Design noch nicht nötig. Entfernt die Klassen wenn das ohne großen Aufwand möglich ist. In der Document-Klasse verwenden wir für Neu/Laden/Speichern die Standard-MFC- Mechanismen, also keine eigenen Methoden "SpielNeu" etc.
FIXME: Klassen: CSperrfeld: "m_bCSperrstein" ist nicht nötig, entweder ist "lnkSperrstein" NULL oder nicht, daraus läßt sich also ableiten ob ein Sperrstein auf dem Feld steht.
FIXME: Klassen: CSpielstein: wieso hat der Spielstein keinen Pointer auf den Spieler ? Dann kann die Farbe raus, diese Information kriegt man aus dem verbundenen Spieler.
FIXME: Klassen: Start- und Zielbox: warum gibt es hier keinen Pointer auf den Spieler ? Dann kann die Farbe raus.
FIXME: Klassen: Die Klassenbeschreibung könnte allgemein ausführlicher sein, mehr auf die Einbindung der Klassen in die Spielmechanik eingehen.

Use-Case-Doku gut, Vor- und Nachbedingungen sind erwähnt !.
Klassendiagramm: kleine Nachbesserungen, könnte noch detaillierter sein ;-).

Update 06.06.2006:
(nur Together-Projekt ohne überarbeitete Doku abgegeben)
Punkt 1 ("Spielerdaten eingeben"), Punkt 5 (Document, View), Punkt 7 (Spielstein mit Pointer auf Spieler), Punkt 8 (Start und Ziel haben Pointer auf Spieler) sind behoben. Ich brauche aber auch die überarbeitete Doku dazu !

Update 10.06.2006:

FIXME: Ihr habt CMalefizDoc und CMalefizView zwar aus dem Diagramm entfernt, nicht aber aus der Beschreibung.

FIXME: Ihr habt die Klasse CSperrstein zwar entfernt, aber sie taucht in der Beschreibung noch auf, außerdem in der Beschreibung von CSperreFeld.

FIXME: Start-/Zielbox brauchen eigentlich keine Membervariable "m_nAnzahlSpielsteine", diese Info kann auch aus dem Spielfigur-Array der Parentklasse errechnet werden oder ? Die Methode "GetAnzahlCSpielsteine" könnte das on the fly errechnen.

FIXME: Die Methoden von CFeld die ein "CFeld" als Parameter oder Rückgabewert haben sollten auf "CFeld *" umgestellt werden, sonst wird das Feld bei jedem Get/Set kopiert, im schlimmsten Fall mitsamt allen abhängigen Objekten. Diese Pointer-Probleme habt ihr glaube ich bei allen Assoziationen/Parameter/Rückgabewerten.

Ich halte es immer noch für sinnvoller den Sperrstein als eigene Klasse zu modellieren, aber wenn ihr ihn auf ein BOOL reduzieren wollt soll das so sein ;-). Was macht ihr mit der Situation dass der Spieler seine Figur auf eine Sperre gezogen hat und jetzt ein neues Feld für die Sperre suchen muss ? Mit einer Klasse "CSperrstein" würde man einfach einen Pointer auf diese zu versetzende Sperre irgendo (in "CSpielbrett" oder in der Zustandklasse "CZustandSperreVersetzen") ablegen.
Die Methode "CSpielbrett:FindeZielFelder" sollte wohl besser ein Array von CFeld-Pointern zurückliefern statt der Indizes. Saubere Verpointerung ist flexibler gegen spätere Änderungen, und es wird wohl nirgends wichtig sein dass hier Indizes zurückkommen oder ?

Use-Cases sind OK. 10/10 Punkte.
Klassendiagramm: Problem mit Pointern, enthält außerdem in Beschreibung noch gelöschte Elemente. Bitte nachbessern. Aktuell: 6/10 Punkte.

Update 15.06.2006:
Das Pointer-Problem im Diagramm ist behoben (bzw. ihr habt es teilweise gemacht, der Rest ist nach einer Together-Trickserei behebbar), ungenutzte Klassen wurden aus Beschreibung entfernt. Ach ja, die Rückgabe von "CSpielbrett:FindeZielFelder" sollte wohl ein "CFeld *[]" sein ;-).
20/20 Punkte.

Stand 17.08.2006
Historie:
28.05.2006: Seite erstellt.
01.06.2006: Nachbewertung Gruppe D
06.06.2006: Nachbewertung Gruppe F
07.06.2006: Bonuspunkt für 149088
08.06.2006: Nachbewertung Gruppen B und C
10.06.2006: Nachbewertung Gruppen A und F
15.06.2006: Nachbewertung Gruppe F
29.06.2006: Nachbewertung Gruppe B
30.06.2006: Nachbewertung Gruppe D
17.08.2006: Nachbewertung Gruppe A