Bewertung der 2. Malefizabgabe

Gruppe 1 (A)

Gruppe 2 (B)

• FIXME: Eure Methoden bekommen nie Pointer übergeben ("(CNormalSpielstein fig" statt "CNormalSpielstein *fig").
• FIXME: Klassendiagramm bitte in die Doku hängen, und die Klassen so groß ziehen dass alle Methoden erkennbar sind, nicht nur je zwei davon.
• FIXME: View-Klasse und Dialog werden nicht im Klassendiagramm beschrieben.
• FIXME: Eure Start-/Zielfelder gehören nicht zu einem Spieler (keine Verbindung zum Spieler)
• CSpieler: die Attribute "ausgewaehlteFigur" und "hatGewonnen" wären sauberer im aktuellen Zustand abgelegt oder ?
• FIXME: einige Aggregationen in eurem Diagramm sind nur Assoziationen. Eine Aggregation ist immer dann gegeben wenn man sagen kann "Objekt x besteht aus Objekt y". Das passt aber nicht bei der Verbindung "CNormalstein" zu "CSpielfeld". Das ist nur eine Assoziation.
• FIXME: "CGewonnen" implementiert nicht die abstrakte Methode "GetNextState".
• FIXME: Zustandsklassen sollten detaillierter beschrieben werden (hier läuft ziemlich viel Logik ab).
• FIXME: Bisher fehlen Sequenzdiagramm, Zustandsdiagramm und Testcases.

Gruppe 3 (C)

• Es wäre schön gewesen wenn ihr eure Dokus zu einem einzigen Dokument zusammengefügt hättet statt mir 6 verschiedene Word-Dateien zu geben.
• FIXME: Die Zustands- und View-klassen gehören in das Standard-Klassendiagramm, kein eigenes Diagramm.
• FIXME: Die Klassen haben viel zu wenig Methoden. Das ist fast schon der Detailgrad der in der 1. Designstufe nötig war.
• FIXME: CFigur: wieso kann man den Typ setzen ? Der Typ kommt doch durch die Subklasse, ein Setzen würde also die Vererbung ignorieren. Die Farbe der Figur wäre einfach zu ermitteln indem man eine Verbindung vom CSpielstein zum Spieler modelliert (bzw. den Weg von der Figur zum Spieler). Eine Sperre hat in der Datenmodellebene keine Farbe (ist eigentlich egal wie der gezeichnet wird).
• FIXME: Eure Klassenbeschreibung hört bei den Datenklassen auf, weder Document noch View sind beschrieben.
• FIXME: CMaleDoc: was ist mit dem Speichern ? "Serialize" müsste in eurem Diagramm wohl auftauchen.
• Das undokumentierte Sequenzdiagramme "Würfeln" habe ich ignoriert.
• Sequenzdiagramm "Sperre versetzen": beim ersten "VerarbeiteKlick" sehe ich keine Statusklasse die diesen Klick verarbeitet. Aus einer Bedingung "[if hat Sperre]" könnt ihr "[hat Sperre]" machen, die eckigen Klammern bedeuten implizit ein "if". Wieso führt der Aufruf von "GetSperre" / "SetSperre" auf CSperre, und was ist der Sinn dieser Methode ? Wo ist der Zustand "nicht gewürfelt", den ihr in der Beschreibung erwähnt ?
• Sequenzdiagramm "Ziehen": "VerarbeiteKlick" sollte keinen Punkt in Bildschirmkoordinaten erhalten, sondern am besten ein CFeld, höchstens aber logischen Koordinaten des Felds im Spielbrett. Das Umrechnen von Bildschirmkoordinaten in muss die View übernehmen.
  Bitte kein "this->" in die Aufrufe packen.
  "CFigurGewaehlt" sollte nicht "UpdateAllViews" des Documents aufrufen, sondern das irgendwie anders steuern, z.B. über die Rückgabe von "VearbeiteKlick".
  Müsste in der Verarbeitung des 2. Klicks der Zustand nicht wechseln nachdem die Figur umgesetzt wurde ? Wo wird geprüft ob das angeklickte Feld überhaupt ein gültiges Ziel ist ?

Gruppe 4 (D)

• FIXME: Zustands-Klassen-Modell fehlt komplett.
• FIXME: View hat keine Methoden, beim Document benötigte MFC-Methoden sind nicht im Diagramm eingetragen. In der Beschreibung fehlen die beiden Klassen ganz.
• FIXME: Abweichung vom Domänenklassendiagramm: es gibt hier eine Klasse "CSperrfeld": Nachtragen in "Malefiz 1"
• FIXME: Beschreibung der Klassen selbst ist knapper als in "Malefiz 1". Hier hätte mindestens die gleiche Menge Doku auftauchen müssen.
• FIXME: Unit-Tests: hier hätten die Initialzustände detaillierter definiert werden müssen (z.B. grafisch einen sinnvollen Startzustand darstellen).
• FIXME: Zustandsautomat muss natürlich beschrieben werden.
• FIXME: Sequenzdiagramm fehlt.

Gruppe 6 (F)

• FIXME: Klassendiagramm bisher zu knapp (zu wenig Methoden, View-Klassen kaum dokumentiert, Probleme bei MFC-Anbindung (separate Methoden "Speichern", "Laden", "SpielErstellen" in Document-Klasse, die eigentlich von MFC-Logik abgebildet werden). Die Methoden sollen in dieser Stufe des Designs auch beschrieben werden.
• FIXME: Klassendiagramm: jeder der Zustandsklassen muss die abstrakten Methoden der Basisklasse implementieren, in jeder der Klassen muss also "HandleFeldKlick" und "HandleWuerfelKlick" vorhanden sein, auch wenn die Methoden eventuell nichts macht.
• FIXME: Sequenzdiagramm: Missverständnis über das Aussehen eines Sequenzdiagramms bei "Feld wählen" ? Warum geht hier der Pfad durch "Würfelergebnis festlegen", "Mögliche Zielfelder anzeigen" und "Zielbox ausgewählt" ? Was ihr hier modelliert habt ist ein kompletter Rundenablauf, also eigentlich nur der zeitliche Ablauf mehrerer Use-Cases. Im Sequenzdiagramm soll aber genau ein Use-Case modelliert werden, mit allen Methoden und Klassen die vom Beginn des Use-Cases bis zu seinem Ende durchlaufen werden. Bitte nochmal überarbeiten. Das Sequenzdiagramm zu "Würfeln" ist ebenfalls zu knapp, hier sind doch bestimmt die View, die Document-Klasse, der Würfel und eine Zustandsklasse beteiligt oder ?
• FIXME: Sequenzdiagramme müssen natürlich auch dokumentiert werden, also der Use-Case im Überblick und jede Methode im Detail beschrieben werden.
• FIXME: Zustandsdiagramm muss beschrieben werden.
• FIXME: Was ist mit den Test Cases ?