Softwaretechnik WS2010
Danke für eure Evaluation
Infos
Gesamtpunktzahlen
Ich habe Feedback von Hr. Igler: es gibt insgesamt 35 Punkte, davon sind 30 für die 1.0 nötig und der Rest ist Bonus. Hausübung A gibt also
5 Bonuspunkte, Hausübung B leider nicht.
Hausübung B2
Beispielhaftes UML-Diagramm für Aufgabe B6:
Erstellt mittels ArgoUML: http://argouml.tigris.org/
Hier die Aufgabenstellung: swt_10ws_hue_b2.pdf
Bitte vergleicht sie mit der Version, die Hr. Igler demnächst veröffentlichen wird (nicht dass eine Teilaufgabe noch dazukommt ;-)).
Da in Hr. Iglers Kursen in der Woche vor Weihnachten das Praktikum ausfällt, fällt bei uns die Stunde am 5.1.2011 aus. Nächste Stunde
(und damit Abgabe von Übung B2) ist am 12.1.2011.
Hinweis zur Aufgabe B.7 ("GUI"): ihr könnte die GUI mit einem Malprogramm zeichnen oder sogar handgemalt auf Papier abgeben.
Aber ihr könnt auch z.B. in Eclipse eine kleine Java-Anwendung bauen, die einen GUI-Prototyp enthält (also ein Fenster, das alle Steuerelemente
darstellt, aber keinerlei programmierte Logik hat).
Für Oberflächendesign empfehle ich den Plugin "Jigloo" (http://www.cloudgarden.com/jigloo/index.html).
Falls ihr einen Prototypen baut, ist es natürlich hilfreich, wenn z.B. der JTree der Aufgaben eine Dummy-Datensätze enthält.
Achtet beim Entwerfen der GUI auch auf das "Drumherum" wie:
-hat die Anwendung ein Windows-Icon links oben (es gibt im Web durchaus schicke frei verfügbare Icon-Pakete, z.B. http://openiconlibrary.sourceforge.net/).
-Hauptmenü?
-Toolbar?
-Statusleiste?
Wer einen Prototyp baut, wird (sofern der Prototyp vorzeigbar ist) mit Bonuspunkten belohnt.
Hausübung A
Für Eclipse-User: 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
JUnit
Hr. Iglers JUnit-Anleitung: junit.pdf
Crashkurs "JUnit in Eclipse 3.6":
Schritt 1: JUnit-Testcase anlegen: Im Contextmenü des Projekts die Option "New" => "JUnit Testcase" aufrufen:
Im nächsten Schritt gibt man dem Testcase einen Namen und ein Package (ich empfehle ein eigenes Package für alle Tests).
Wichtig ist, dass "JUnit 4" verwendet wird (Default). Im Feld "Class under test" könnte man eine Klasse wählen, für deren public Methoden
dann im nächsten Schritt Rümpfe von Testmethoden erzeugt werden, aber das hilft nicht allzuviel.
Beim Hinzufügen des ersten TestCase kommt eine Abfrage "JUnit dem BuildPath zufügen". Dies bejahen wir natürlich:
Sollten wir dies vergessen haben, könnten wir das nachträglich in den Projekteigenschaften nachholen:
Jetzt können wir den Code der Testklasse bauen. Hier das im Praktikum gezeigte Beispiel (um euch das Leben nicht zu einfach zu machen,
ohne den Code der Klasse "Dreieck" und ohne die Enum "Dreieck.Status" ;-).
package de.hsrm.cs.swt.dreieck.test;
import static org.junit.Assert.*;
import junit.framework.Assert;
import org.junit.Test;
import de.hsrm.cs.swt.dreieck.Dreieck;
public class DreieckTest
{
@Test
public void testUngleichseitig() throws Exception
{
Dreieck.Status status = Dreieck.checkDreieck(new String[] { "2", "2", "2" });
Assert.assertEquals(Dreieck.Status.ungleichseitig, status);
}
@Test
public void testStringEingabe() throws Exception
{
try
{
Dreieck.checkDreieck(new String[] { "a", "2", "3" });
Assert.fail("Exception fehlt!");
}
catch (Exception ex)
{
// OK so!
}
}
}
Wichtig ist hierbei, dass man jede Methode, die einen Test darstellt, mit der Annotation "@org.junit.Test
" versieht.
Ansonsten gilt für Testmethoden nur, dass sie keine Rückgabe und keine Parameter haben dürfen. Falls eine der zu testenden Methoden eine Exception
werfen könnte, kann man eine "throws Exception
"-Deklaration an die Methode anhängen (denn eine Exception im Test selbst ist ja ein
fehlgeschlagener Test - JUnit kümmert sich um die Behandlung dieses Fehlers).
Schritt 2: Ausführen:
Rechtsklick auf den Test, "Run as" => "JUnit Test":
Jetzt geht ein neues Fenster auf, in dem wir den Status der Tests sehen, und im Fehlerfall die Fehlermeldung und den StackTrace:
Weitere Vertiefung bleibt euch überlassen ;-)
Aufgabe A12: Zustandsdiagramm:
In der Stunde am 03.11.2010 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".
Objektdiagramm:
In der Stunde am 20.10.2010 kam die Frage auf "dürfen Aggregations-/Kompositionsbeziehungen auch im Objektdiagramm verwendet werden?".
Antwort: Blick in den UML2-Standard: http://www.omg.org/spec/UML/2.0/
Hier hilft uns Seite 152 (in der PFD-Version) weiter: "The graphic paths that can be included in structure diagrams are shown in Table 7.3.". In dieser Tabelle
stehen auch Aggregation etc. Und auf Seite 153 erklärt der Abschnitt "Variations", dass auch das "Object diagram" zu diesen "structure diagrams" gehört.
Aufgabe b5
Hier (unkommentiert) ein Klassendiagramm, dass die drei genannten Probleme umgeht:
Stand 25.01.2011
Historie:
01.11.2010: Erstellt
12.11.2010: JUnit-Crashkurs und "Exception im Zustandsdiagramm"
17.11.2010: Link zur "Kommentieren"-Seite und Hinweis "JavaDoc-Warnings in Eclipse"
14.12.2010: Link zur Bewertung der Hausübung 1
23.12.2010: Hinweise etc. zu B2
26.12.2010: Bewertung B1
13.01.2011: Hinweise zu Gesamtpunktzahl und Usecases B6
16.01.2011: Bewertung B2
23.01.2011: Bewertung B3
25.01.2011: Gesamtpunkte