Allerlei zum Softwaretechnik - Praktikum 2006

Endgültige Abgabe bis Sonntag, 13.8. per Mail ! Schickt die Abgaben an meine Firmenadresse, zuhause bin ich wegen meines lahmen Modems zu nichts in der Lage ;-).

Abgegeben werden sollen das Programm und die Unit-Tests, alles im Quellcode. Das Benutzerhandbuch soll als Windows-Hilfe im CHM-Format vorliegen.
Außerdem wäre es gut wenn ihr die gesamte technische Dokumentation (Use-Cases, Klassen- und sonstige Diagramme mit Beschreibung) als "Technisches Handbuch" beilegen könntet. Gebt mir Bescheid ob ihr dabei FIXMEs aus bisherigen Abgaben behoben habt.

Noten werden auf dieser Seite bekanntgegeben.

Ich bin vom 2.8. bis 12.8. im Urlaub, kann euch also keine Hilfe bei Problemen geben.

Gesammelte Informationen

Installation:

Austausch eines MFC-Projekts

Malefiz 3 (das Programm):

<!DOCTYPE MalefizSavegame PUBLIC "Malefiz-Savegame Softwaretechnik 2006 FH Wiesbaden" "http://www.informatik.fh-wiesbaden.de/~knauf/SWT2006/Malefiz.dtd"> 

• Encoding soll immer UTF-8 sein (encoding="UTF-8"). Wenn ihr per Hand so eine Datei erstellen wollt empfehle ich euch z.B. Notepad, dort kann man beim Speichern dieses Encoding wählen.
• Ich habe das Feld in ein Gitterraster eingeteilt, jedes Feld bekommt eine eindeutige X-/Y-Koordinate. Die Zählung beginnt (da wir alle Profi-Informatiker sind) natürlich bei 0. Die Leute mit dem Spielfeldeditor haben eventuell abweichende Maximalwerte für X und Y und natürlich eine völlig andere Spielfeld-Verteilung. Das macht aber nix, ein eigenes Spielfeld ist sowieso nicht bei den Standard-Spiel-Gruppen einladbar.
  Das Gitterraster sieht so aus:
  
  
• Die Start-/Zielfelder habe ich auf jeweils ein Feld reduziert, d.h. darauf stehen 0 bis 5 Figuren. Ich denke die meisten Gruppen haben diese Definition verwendet da die 5-Feld-Cluster nicht ins Feld-Nachbar-Modell passen. Ihr könnt das natürlich zeichnerisch völlig anders darstellen und auch intern 5 Felder verwenden, nur beim Speichern sollte das als ein Feld behandelt werden.
• Die 4 Spieler haben Ids von 0 bis 3.
• Die 5 Spielfiguren eines Spielers haben Ids von 0 bis 4 (jeweils pro Spieler).
• Die 17 Sperren haben IDs von 0 bis 16 (bzw bei den Leuten mit Editor auch mehr oder weniger). Einige von euch haben keine Klasse "CSperre" im Modell. Das macht nix, nummeriert einfach beim Speichern eure Sperrsteine sinnvoll so dass ihr Dummy-IDs vergeben könnt.
• Ich habe vier Zustände gefunden in denen eine Spielspeicherung sinnvoll ist: "Rundenstart", "Gewürfelt", "Figur gewählt" und "Sperre versetzen". Eventuell kommt hier ein fünfter Zustand "Rundenende" dazu falls ihr nicht automatisch zum nächsten Spieler wechselt sondern ein Klick auf einen Button "Nächster Spieler" nötig ist. Welche Attribute die einzelnen Zustände haben steht in der Beispiel-Datei.

Malefiz 2:

• Es soll ein Klassendiagramm aller beteiligten Klassen (auch Views, Dialoge und sonstige MFC-Klassen) mit allen Methoden und Membervariablen erstellt werden (auf Basis des bereits vorhandenen Klassendiagramms). Alle Klassen, Methoden und Variablen müssen detailliert beschrieben werden, am besten an das Dokument aus Malefiz 1 angehängt.
• Zu zwei Use-Cases sollen Sequenzdiagramme (natürlich ebenfalls mit Beschreibung) erstellt werden.
  Wie ein Sequenzdiagramm unter Einbindung der vorhandenen Objekte erstellt wird ist hier beschrieben.
• Definiert eure Unit-Test-Cases: 10 Testfälle (mögliche Schritte im Programm) sollen definiert werden: Was ist der Initialzustand des Systems ? Was für Aktionen werden im Test durchgeführt ? Wie soll der Zustand des Systems anschließend sein ? Es sollten weitgehend alle Use-Cases abgedeckt werden. Anhand dieser Test-Definitionen werden wir später die Test-Cases programmieren.
  Siehe dazu meine Erläuterungen in der Stunde am 31.05.2006.
  Update 17.07.2006: Es reichen 5 Testfälle. Die sollten aber auch hauptsächlich Spiellogik abdecken, und nicht sich nicht mit eher trivialen Randfällen beschäftigen.
• Für den in der Stunde am 24.05. beschriebenen Zustandsautomat soll ein Diagramm erstellt werden. Dies geht mit Together, indem im Together ein Diagramm vom Typ "Statechart" zugefügt wird.
  Die benötigten Elemente für das Diagramm sind diese (Toolbar):
  
  Und hier ein Beispieldiagramm (der Ablauf einer typischen Abgabe in unserer Gruppe):
  

Malefiz 1:

• Use-Case-Diagramm
• Beschreibung des Use-Case-Diagramms. Es soll detailliert jeder Use-Case beschrieben werden. Die kompletten Spielregeln sollten auf Use-Cases verteilt werden. Zu jedem Use-Case sollen alle Sonderfälle und eventuelle Festlegungen von offenen Punkten beschrieben werden.
  Die Beschreibung jedes Use-Case soll außerdem eine einleitende Vorbedingung (welche anderen Use-Cases müssen vorher durchlaufen werden bzw. in welchem Zustand muss sich die Anwendung befinden) und eine abschließende Nachbedingungen (welche Use-Cases können anschließend starten) enthalten.
• Domänen-Klassendiagramm (also die Daten-Klassen und deren Verbindungen untereinander).
• Beschreibung der Klassen: zu jeder Klasse soll ausführlich ihre Funktion und ihre Beziehungen zu anderen Klassen beschrieben werden. Außerdem soll beschrieben werden welche Spiel-Funktionen bzw. Use-Case-Elemente in ihr geschehen.
• Das ganze bitte als ein einziges einheitlich formatiertes Word-/OpenOffice-/HTML-Dokument in das die Diagramme eingebettet sind. Am Ende soll ein einziges Heft mit der gesamten Programm-Doku entstehen.

Adressverwaltung 2:

• Wie die letzte Aufgabe ist auch diese in Einzelarbeit zu erledigen.
• Verwendet das Modified-Flag von CDocument (siehe MFCSchnipsel). Es reicht wenn der Aufruf von "SetModified" an den richtigen Stellen erfolgt. Die Anpassung des Fenstertitels ist Spielerei und deshalb nicht nötig.
• Die Anwendung soll als geteiltes Fenster realisiert werden. Dazu muss die Anwendung neu erstellt werden, nur Teile des Codes aus der Document-Klasse und CAdresse können wiederverwendet werden.
• Die linke View soll eine CFormView sein, auf ein ListControl und die Buttons "Neu", "Bearbeiten", "Löschen" liegen.
  
  Für das ListControl soll die Property "Ansicht" vom Default-Wert "Icon" auf "Bericht" gesetzt werden.
  Wie sie befüllt wird seht ihr in "CAdressverwaltungView::OnUpdate" im Beispiel.
  Das Grundprinzip ist dieses:

  	CString sNachname = _T("Müller");
  	this->m_ListCtrl.InsertItem (0, sNachname);
  	CString sVorname = _T("Otto");
  	this->m_ListCtrl.SetItemText (0, 1, sVorname);
  
  	sNachname = _T("Huber");
  	this->m_ListCtrl.InsertItem (1, sNachname);
  	sVorname = _T("Heinz");
  	this->m_ListCtrl.SetItemText (1, 1, sVorname);  

  "InsertItem" fügt eine neue Zeile ein, "SetItemText" setzt den Text in Zeile x, Spalte y.
  
  Für das Erkennen einer Auswahländerung fangen wir das Event "LVN_ITEMCHANGED" ab. Beispielcode siehe Beispiel.
  Da sich bei der Auswahländerung der Zustand von zwei Items ändert (das bisher gewählte hat danach nicht mehr den "selected"-Zustand, dafür aber das neue) und das Event dadurch bei einem Klick doppelt aufgerufen wird hilft folgender Code, nur das neu gewählte Item zu verarbeiten:

    	if ((pNMLV->uNewState & LVIS_SELECTED) == LVIS_SELECTED)
  	{
  		CString sMessage;
  		sMessage.Format (_T("OnLvnItemchangedList  for item %d! "), pNMLV->iItem);
  		AfxMessageBox ( sMessage);
  	}  

  Der Index des neuen Items steckt in "pNMLV.iItem".
  
  Ein Beispiel für das Abrufen des Index des gewählten Items findet sich im "OnBnClickedButtonBearbeiten":

  	POSITION posFirstSelected = this->m_ListCtrl.GetFirstSelectedItemPosition ();
  	//Wenn es kein Item gibt dann kommt hier NULL zurück:
  	if (posFirstSelected == NULL)
  	{
  		AfxMessageBox (_T("Kein Item gewählt !"));
  		return;
  	}
  	//Die erste gewählte Adresse holen:
  	int iItemSelected = this->m_ListCtrl.GetNextSelectedItem (posFirstSelected);
  	CString sMessage;
  	sMessage.Format (_T("Sie bearbeiten die Adresse in Zeile %d! "), iItemSelected);
  	AfxMessageBox ( sMessage); 

• Die rechte View soll eine CView sein, auf der die Details der gewählten Adresse zeichnerisch ausgegeben werden.
• Die aktuell gewählte Adresse soll als Membervariable ins Document gesetzt werden, hier holt die Detailview sie ab.
• Beim Klick auf "Neu" oder "Bearbeiten" soll ein Dialog aufgehen in dem eine Adresse bearbeitet werden kann.
• Der Unit-Test soll funktionierend gemacht werden (siehe vorgestelltes Beispiel in der Stunde vom 3.5.).
• Hier findet ihr eine Dummy-Beispielanwendung die das Aussehen vorgibt: Adressverwaltung.zip (aktualisiert am 24.05.: "SetItemText" statt LVITEM-Struktur).

Adressverwaltung 1:

• Die Aufgabe ist in Einzelarbeit zu erledigen (wobei ihr natürlich zusammenarbeiten könnt, ich will aber keine komplett identischen Projekte).
• Ich erwarte alle Features aus der Aufgabenstellung von Hr. Dreher.
• Es soll eine komplette Doxygen-Doku vorhanden sein (siehe MFCMinimal-Beispiel). Kommentare in den Methoden selbst schaden natürlich auch nicht !
• Haltet euch an den Styleguide von Hr. Dreher, um Bezug auf Variablennamen genauso wie bei Klassen- und Funktionsnamen. Alle Membervariablen in einen MFC-Projekt sind mit durchschnittlichen C++-Kenntnissen von Hand umbenennbar !
• Es soll außerdem ein Unit-Test-Projekt geliefert werden.
  Verwendet sinnvolle Test-Szenarios. Beispiel wären:
  -3 Adressen anlegen, Dokument speichern und neu laden -> Enthält es jetzt die originalen 3 Adressen in der gleichen Reihenfolge ?
  -3 Adressen zufügen, eine löschen, über Dokument iterieren: erhält man exakt die beiden nicht gelöschten Adressen zurück ?
  -Hinzufügen und Update einer Adresse ?
  Denkt euch ruhig ein paar eigene Tests aus. Ein Test sollte nach Möglichkeit nicht nur eine Trivial-Methode abdecken sondern ruhig einen ganzen Satz Einzelschritte.
• Unvollständige Features müssen (mit kleinem Punktabzug) nachgeliefert werden.

Beispiele

Literatur