2. Pachisi-Abgabe (Klassen- und Sequenzdiagramm)

Allgemein

• Die OCL-Syntax habe ich nur auf Vorhandensein bewertet, da es schon schwer genug war sich da auch noch reinzuarbeiten.

Gruppe A (146 006, 845 927, 546 873, 246 016)

• Reihenfolge der Beschreibung: Datenklassen vor Viewklassen (Beschreibung von unten nach oben aufbauen)
• CAPachisiView.OnDraw: Wie wird die View gezeichnet / aufgebaut ? Das hätte hier beschrieben werden müssen.
• Wo ist die View-Klasse im Klassendiagramm ?
• CAPachisiView: Membervariable "m_pFeldPosition" nicht beschrieben.
• CFeldPosition: Wie funktioniert die Zuordnung Mausklick<>Feld ?
• CMuscheln: Dass das Würfeln binär ist geht aus der Beschreibung nicht hervor. Kann nur aus dem Array m_bMuscheln erahnt werden.
• CMuscheln::m_bGrace ist wahrscheinlich nicht nötig, ob ein Grace vorliegt könnte auch einfach aus dem aktuellen Ergebnis ermittelt werden.
• CFeldStatus: warum nur per ID mit dem Feld verknüpft ? Zeiger auf Feld wäre schöner.
• Wozu CSpielerErstellung ? Das ist mir anhand der Beschreibung nicht klar geworden.
• CFeld: werden irgendwelche der Methoden von Subklassen überschrieben ? Wenn ja müßten sie dort auch auftauchen. Die meisten Methodne müssen wahrscheinlich überschrieben werden, da z.B. CFeld::IstBegehbar nicht von CFeld implementiert werden kann (nur Subklassen wissen ob ein bestimmter Spieler darauf ziehen darf).
• Zustandsbeschreibung: was genau passiert in den überschriebenen Memberfunktionen ?
• Sequenzdiagramm: Beschreibung eigentlich nicht vorhanden.
• Sequenzdiagramm: Diagramme sind schön ausführlich, fast schon "perfekt" zu nennen.
• OCL: Postcondition "Wuerfeln" von CRundenstart::MuschelnGeklickt ist kein Zustand sondern eine Aktion. In beiden Fällen hätte der return-Wert der Methode definiert werden müssen. Für CRundenstart::MuschelnGeklickt z.B.: "post neuerZustand: result = CZielfeldAuswahl".

• Die CAPachisiView ist doch in eurem Diagramm, habe ich übersehen.
• Beschreibung des Sequenzdiagramms "Würfeln" wurde erst nach meinem Besuch im Wiki (aber noch In-Time) hochgeladen. Die Beschreibung ist OK, aber ein wenig knapp für den hohen Detailgrad im Sequenzdiagramm.

Gruppe B (143 376, 843 365, 643 402)

• Struktur: Sequenzdiagramme bitte erst nach dem Klassendiagramm, da sie auf dem Klassendiagramm aufbauen.
• CWuerfel.Wurf: über die Wahrscheinlichkeitsverteilung müßt ihr euch zu dieser Phase des Designs schon klar sein !
• "Team" nur als Integer-Attribut, eine eigene Klasse wäre schöner gewesen.
• CFeld und Subklassen: die Klassen sind hier nur als "Markierer" für die unterschiedlichen Feldtypen genutzt. Schöner wäre es gewesen wenn jedes Feld die Logik kapselt, die entscheidet ob eine Figur darauf ziehen kann oder nicht. Die jetzige Implementation erfordert eine große Klasse die die Logik in einem großen Codeblock enthält. Deshalb wären eigene Subklassen für die Felder eigentlich nicht nötig, eine Methode "CreateBurg" / "CreateStartfeld" / ... von CFeld würde reichen, um die entsprechenden Feldtypen zu initialisieren.
• Was macht "CSerialize" in eurer Beschreibung ? Ihr habt sie ja selbst als obsolet deklariert.
• In CSpielsteuerung wird die Beschreibung ein wenig lustlos. Beispiel: CSpielsteuerung::getStrartSP(): Ermittelt mit Hilfe von CWuerfeln den Spieler der als erster Ziehen darf. Und wie geht das ?
  Die Verknüpfung zu den Stati fehlt in der Beschreibung.
• CWindowWizard: Mir ist nicht so ganz klar was diese Klasse macht. Dito für CWindow2Sp und CWindow4Sp (wieso überhaupt zwei Klassen für die unterschiedlichen Spielerzahlen ?)
• CStatus: auch die abstrakten Methoden beschreiben (wo werden sie verwendet ? Wozu sind sie?)
• CSpielregeln: seeehr lustlos beschrieben
• Die OCLs bitte auch beschreiben. So ist mir bei einigen nicht ganz klar was gemeint ist.
  Beispiel:

  	context CStatusWuerfel::klickWuerfel(void):void
  	pre DiceIt: CWuerfeln::Wuerfeln >= 0 

  Was ist "CWuerfeln::Wuerfeln" ? Eine static Membervariable von CWuerfeln ? Dort gibt es nur die Methode "Wurf", und die ändert den Zustand des Objekts (also für OCL ungeeignet !).
  Scheinbar fehlerhaftes Verständis der Syntax: "::" nur zum Zugriff auf static Variablen/Methoden einer Klasse.
  CStatusWuerfeln:klickFeld: Was meint ihr mit "CFormView::OnMouse > 0" ? Doch nicht etwa ein Aufrufen des Eventhandlers ? In der OCL dürfen keine Methoden aufgerufen werden die den Zustand ändern. In Post Conditions NUR den Zustand des Objekts nach dem Aufruf beschreiben.
  CStatusZugAusfuehren::klickFeld: eine Invariant gibt es nicht bei Methoden.
• Sequenzdiagramme OK

Gruppe C (546 881, 944 689, 946 665)

• Bitte das Klassendiagramm nicht über 7 PDF-Seiten verteilen. Hier wäre ein separates Bild angebracht gewesen.
• "#include" haben im Klassendiagramm nichts zu suchen. Die Verbindung zu anderen Klassen sollte in der Beschreibung auftauchen
• Jede Klasse muss mit einem kurzen Überblick versehen sein (im Prinzip die Beschreibung aus dem Domänen-Klassendiagramm).
• Layout ist ziemlich schwer zu lesen. Habt ihr mir hier die generierte HTML-Doku ins PDF kopiert ?
• Die separate Auflistung der Methoden mit anschließender Detailbeschreibung hättet ihr euch schenken können. Es hätte gereicht wenn ihr das alles in die ausführliche Beschreibung gepackt hättet.
• Beschreibung CBurg / CZielburg: was machen diese Klassen ? Was unterscheidet sie (außer der Ableitung) von einem CFeld ?
• OCL: CZustand::wuerfeln: pre: if Zustand instanceof CFigurGezogen then pre: wurfwert=(6 or 10 or 25) : Keine geschachtelten Pre-Conditions. Else-Zweig ? Post-Condition für diesen Zweig: statt Zustand instanceof CGewuerfelt müßte es heißen result instanceof CGewuerfelt
  Mit das beste OCL der Abgaben.
• Sequenzdiagramm baut nicht auf bestehendem Pachisi-Projekt auf, sonst hättet ihr die Methoden aus einer Auswahlliste wählen können.

Gruppe D (243 408, 340 037, 137 236, 835 794)

• Das Klassendiagramm von unten nach oben beschreiben, also von den Datenklassen zur View.
• Zu jeder Klasse bitte auch die Beschreibung was sie überhaupt macht (Überblick).
• Membervariablen: teilweise nicht detailliert genug beschrieben (Beziehung zu anderen Klassen, Anwendungslogik). Dies will ich mir nicht aus der Methodenbeschreibung suchen müssen.
• Membervariablen, Funktionen: Kurzbeschreibung nicht mit C-Kommentaren
• CPachsisView: wie geschieht das Umrechnen der Bildschirmposition in logische Koordinaten ?
• CPachisiDoc::setzeStein: statt Pseudocode wären mir hier 2 Sätze mit Beschreibung lieber gewesen. Dann könnte ich mehr damit anfangen.
• CPachisiDoc: bei den Methoden die nur auf andere Klassen weiterleiten (z.B. getAktivesFeld, getSteinVisibleStat): kurz beschreiben was in der Zielklasse passiert. Sonst muss ich die Zielklasse suchen und da die Beschreibung lesen.
• CFeld ist nicht mit dem besitzenden Spieler verknüpft. Macht es schwer herauszukriegen wem es gehört.
• CFeld und Subklassen: die Klassen sind hier nur als "Markierer" für die unterschiedlichen Feldtypen genutzt. Schöner wäre es gewesen wenn jedes Feld die Logik kapselt, die entscheidet ob eine Figur darauf ziehen kann oder nicht. Die jetzige Implementation erfordert eine große Klasse die die Logik in einem großen Codeblock enthält. Deshalb wären eigene Subklassen für die Felder eigentlich nicht nötig, eine Methode "CreateBurg" / "CreateStartfeld" / ... von CFeld würde reichen, um die entsprechenden Feldtypen zu initialisieren.
• OCL: CStateZug:aktion: die beiden Pre-Conditions sind eigentlich "def" (Deklarationen) ! Falls ihr den auf Initialwert einer Klassenvariablen zugreifen wollt, geht das über das Schlüsselwort "@pre".
  if-Bedingungen: statt zei,spa = state->mouseKlickToState(zei:int, spa:int) = skip = true wäre richtig gewesen: zei,spa = state->mouseKlickToState(zei:int, spa:int) = skip
• Sequenzdiagramme OK