.
Softwaretechnik WS2011
Softwaretechnik WS2011
Abnahme
Die Abnahme findet am Donnerstag, 16.2. um 17:00 Uhr im üblichen Raum statt.
Ein paar Wünsche von mir:
- Schön wäre, wenn ihr eine Art Projekttagebuch abgeben könntet, dass eure Erfahrungen mit dem alten Projekt und eure Verbesserungsideen
sowie die Erfahrungen bei der Umsetzungen derselben enthält. Hier dürfen auch gerne Mißerfolge stehen, und der Grund dafür.
- Quellcode: kommentiert den kompletten Code (auch Klassen, die ihr nicht geändert habt) mit JavaDoc. Siehe unten für die
strengen JavaDoc-Einstellungen. Jede Warnung im Projekt, die leicht behebbar ist, ergibt einen Punkt Abzug!
Falls im Projekt Klassen aus anderen alten Aufgaben stecken, die nichts mit dem Programm selbst zu tun haben, dann löscht sie.
- Unittests und Testfall-Beschreibung.
Unittests können problematisch bis unmöglich sein bei Spielen, die zufallsgesteuerte Gegner haben oder und/oder sehr viel Timer-gesteuert
machen. Teil 1 des Problems könnte man lösen, indem man im Unittest statt der zufälligen Ereignisse einem hartcodierten Ablaufplan folgt. Das
bedeutet aber viel Aufwand, weil man den Ablaufplan auch in der Model/Controllerschicht einbauen muss, und außerdem testet man trotzdem einen
wesentlichen Teil der Aufgabe (Zufallsfaktor) nicht. Deshalb sind Unittests eventuell nicht machbar. Solch einen Fall bitte in der Abgabe schriftlich begründen
und dafür gute Testfälle für den Test durch einen Menschen abgeben.
Diese Testbeschreibungen sind natürlich auch nötig, falls Unittests gebaut werden
konnten, aber nicht alle Teile der Anwendung (z.B. Starten, GUI) durch einen Unittest abdeckbar sind.
- UseCase-Diagramm - natürlich mit Beschreibung der Aktoren und Use-Cases
- Klassendiagramm des modifizierten Programms. Da ein großes Klassendiagramm nicht viel Aussage hat, teilt es lieber in Einzelteile auf, um
z.B. den Zusammenhang der Modelklassen oder die Controllerschicht zu erklären. Die Zusammenhänge der Klassen sollten dokumentiert werden,
außer eure Javadoc ist so ausführlich, dass man irgendwo z.B. die Spiellogik im Ganzen erklärt bekommt.
- Beschreibung der Probleme der alten Anwendung (aber eher ein Grobüberblick, nicht jedes Detail beschreiben) und eurer Verbesserungen.
Umstellungen an der Klassenstruktur lassen sich eventuell gut darstellen, indem man einen Ausschnitt des Klassendiagramms der alten Anwendung
und den gleichen Sachverhalt im neuen Klassendiagramm darstellt. Auch ein Sequenzdiagramm kann hier "Alt" und "Neu" gut vergleichen.
- (optional) Sequenz- oder sonstiges Verhaltensdiagramm eines zentralen Use-Case der neuen Anwendung
- Ausblick: was wäre noch zu verbessern?
Bewertung
Befindet sich in StudIP...
Falls ihr bei eurer Punktzahl eine rote Ecke seht, dann gibt es einen Kommentar mit mehr Infos zu eventuellen Punktabzügen. Und bei häufigen
Fehlern habe ich in Zeile 2 (maximal erreichbare Punktzahl der Aufgabe) ebenfalls Kommentare eingetragen.
Danke für eure Evaluation
Literatur
Sehr empfehlenswertes UML 2-Buch:
http://www.hanser.de/buch.asp?isbn=978-3-446-41118-0
Buch über Design Patterns: Head First Design Patterns
Eric Freeman, Elisabeth Freeman, Bert Bates, Kathy Sierra
ISBN englische Version: ISBN-10: 0596007124, ISBN-13: 978-0596007126
ISBN deutsche Version ("Entwurfsmuster von Kopf bis Fuß"): ISBN-10: 3897214210, ISBN-13: 978-3897214217
JavaDoc
Spätestens für die große Hausübung gilt: bitte JavaDoc-Warnungen gemäß diesen Einstellungen konfigurieren:
Jede Eclipse-Warning in der Hausübung führt zu einem Punkt Abzug, außer sie ist wirklich nicht vermeidbar!
Kommentierung
Sauberes Kommentieren
Code Coverage:
Siehe auch das entsprechende Dossier von Hr. Igler: "Code Coverage" kann z.B. ermitteln, wieviele Teile eines Programms vom Code von vorhandenen JUnit-Tests
durchlaufen wird: http://en.wikipedia.org/wiki/Code_coverage
Es gibt für Eclipse den Plugin "EclEmma": http://eclemma.org/
Nach der Installation des Plugins ist das Ausführen denkbar einfach: im Projekt-Contextmenü wird der Punkt "Coverage as" => "JUnit Test" aufgerufen:
Danach werden die JUnit-Tests wie gewohnt ausgeführt, und am Ende sehen wir, zu welchem Prozentsatz die einzelnen Methoden von Tests abgedeckt wurden.
Idealfall ist natürlich, alle Schleifen und vor allem die IF-Entscheidungen zu durchlaufen.
JUnit:
Hier findet ihr einen Schnelleinstieg in JUnit.
UML-Tool
Ich empfehle ArgoUML:http://argouml.tigris.org
(unter http://argouml-downloads.tigris.org/argouml-0.32.2/ findet man auch einen Zip-Download,
der ohne Installation funktioniert).
Aufgabe B13: Zustandsdiagramm:
Hier eine Musterlösung und ein paar weitere Notationselemente aus dem Zustandsdiagramm.
Aufgabe B12: Zustandsdiagramm:
Im letzten Semester kam die Frage auf "wie modelliert man Exceptions im Zustandsdiagramm?"
Hier kommt es darauf an, ob durch die Exception eine komplette Verarbeitung abgebrochen wird (z.B. beim Parsen einer XML-Datei, wo ein Fehler vermutlich
den gesamten Parse-Vorgang ohne Möglichkeit auf "Reparatur" beenden würde), oder ob "nur" die aktuell aufgerufene Methode (und damit: Transition)
einen Fehler wirft, der Zustand des Gesamtsystems sich aber nicht ändert.
Im Beispiel der Klasse "MyStack" ist letzteres der Fall. Deshalb könnte eine Modellierung von "push im Falle eines vollen Stacks aufrufen" so aussehen:
Man beachte, dass der Guard hier den die Exception auslösenden Zustand "size == 4" definiert, und das Verhalten ist "Exception werfen".
Aufgabe B5
Hier (unkommentiert) ein Klassendiagramm, dass die drei genannten Probleme umgeht:
Aufgabe B4
Hier ein Vorschlag für die Modellierung von Exceptions im Klassendiagramm:
http://www.agilemodeling.com/style/classDiagram.htm#Figure4.
Zur Sicherheit habe ich das Beispiel von dort kopiert:
"+findAllInstances(): Vector {exceptions=NetworkFailure, DatabaseError}"
Aufgabenblatt A
Hier ein Link zu einer detaillierten Ariane5-Analyse:
http://www.uni-koblenz.de/~beckert/Lehre/Seminar-Softwarefehler/Ausarbeitungen/weyand.pdf
Stand 26.01.2012
Historie:
24.10.2011: Erstellt
30.10.2011: Bewertung Blatt 2, Literaturhinweis
06.11.2011: Bewertung in StudIP geschoben, Hinweise zu B4, B5 und B12
08.11.2011: Abgabe Übung B / Teil 3
11.11.2011: Praktikum 16.11
22.11.2011: Link zu Zustandsdiagramm-Details
23.11.2011: Link zu JUnit
30.11.2011: JavaDoc-Warnung-Einstellungen, "EclEmma"
06.12.2011: Design-Patterns-Buch
13.12.2011: Link zu "Sauberes Kommentieren"
19.12.2011: Evaluation
26.01.2012: Abnahmekriterien