Softwaretechnik-Projekt SS2009
Berufungsvorträge
Die angedrohte Pflicht-Zusatzaufgabe "Berufungsvorträge" findet doch noch statt. Die Termine liegen leider hinter dem
ursprünglich geplanten endgültigen finalen Meldetermin der Noten, aber wir kriegen das schon hin ;-).
- 24.08.09: 9 Uhr, 11 Uhr, 14 Uhr "Testen von Software"
- 26.08.09: 9 Uhr, 11 Uhr "Design Pattern"
- 27.08.09: 9 Uhr, "Design Pattern"
Bedingung: pro Vortrag müssen von der 6er-Gruppe drei Leute, von den beiden Dreiergruppen je ein Student/eine Studentin anwesend sein!
Vereinbart mit Hr. Kleuker, wie diese Anwesenheit geprüft wird, da mir die Zeit fehlt, um selbst anwesend zu sein.
Auch die Verrechnung dieser "Zusatzaufgabe" wird Hr. Kleuker vornehmen. Da sie gemäß Aufgabenstellung mit 10% in die Gesamtarbeitszeit des Projekts eingeht
(das wiederum 70% der Gesamtnote ausmacht), also 7% der Gesamtnote ausmacht, bleiben also rein rechnerisch exakt 63% für das eigentliche Projekt. Ich denke, dass ich die Punktzahlen ungefähr
so aufteilen werden, dass die Endpräsentation 15%, die Doku ebenfalls 15% und die eigentliche Anwendung 33% der Gesamtnote ausmacht.
Diese Angaben sind noch vorläufig.
Endabnahme
Die finale Präsentation findet am DO 20.8. hochschulöffentlich statt. Genaue Uhrzeiten
siehe unten (bei Problemen mit dem Termin: Mail an mich und auch an Hr. Kleuker). Diese Abnahme besteht
aus einer Präsentation der Projektarchitektur und einer technischen Präsentation des Programms.
Bitte beachten: bei den Präsentationen müssen alle Teammitglieder gleichwertig in Aktion treten.
Nach der Endabnahme muss direkt abgegeben werden, Zeit zum Bugfixen besteht nicht mehr. Nutzt die Zeit davor,
um z.B. Programm und Doku mit mir zusammen auf grobe "Verstöße" durchzugehen!
Zusammenfassend nochmal ein paar Anforderungen an Programm und Abgabe:
- Speicherung der Daten gemäß sherd.xsd. Austausch der Diagramme zwischen den Gruppen muss möglich sein.
Wenn das nicht klappt und die Gruppe ihre Unschuld nicht beweisen kann, gibt es Punktabzüge.
- Benutzerhandbuch über JavaHelp, idealerweise Kontextbasiert (also z.B. abhängig vom gerade offenen Dialog
oder dem gerade gewählten Toolbarbutton/Zeichenwerkzeug)
- Die gesamte technische Doku muss als vollständiges, detailliert beschriebenes Dokument abgegeben werden,
siehe Abnahmekriterien Hr. Kleuker. Ich wünsche mir:
- Die ganze Doku sollte sinnvoll strukturiert sein, also nicht aus Fragmenten bestehen. Ein einziges Dokument
mit nur einem einzigen Layout.
- Use-Case-Diagramm + detaillierte Beschreibungen (bereits Erstelltes an finalen Programmstand anpassen)
- Klassendiagramm (detaillierte Klassenbeschreibung kommt über JavaDoc, muss nicht separat beschrieben werden)
- Dokumentieren von eingesetzten Designpatterns (Factory, Command, Memento, ...) und sonstigen relevanten Logiken (jeweils kleines Klassendiagramm + Beschreibung,
bei Verwendung eines StatePatterns sollte ein Zustandsdiagramm abgegeben werden)
- Falls ihr z.B. Commands im XML-Format verwendet: Beschreibung der Struktur der einzelnen Commands
- Auch wenn "sherd.xsd" auf meiner Seite vorgegeben ist, solltet ihr die Beschreibung des Dateiformats in
eure Doku aufnehmen.
- Sequenzdiagramme zu zwei kompletten, nicht zu trivialen Use Cases + Beschreibung (Diagramm ohne Beschreibung: 0 Punkte)
- Stundenabrechnung nicht vergessen.
Danke für eure Bewertung!
XML-Speicherung der Diagramme:
Ich habe einen Entwurf (Version 0.6) eines XML-Dokuments und einer Schema-Definition für die XML-Speicherung der Diagramme gebaut:
sherd.xml (referenziert sherd.xsd auf dieser meiner Webseite) und sherd.xsd
Besonderheiten/Einschränkungen:
- Jedes Element hat eine ID, diese ist pro Datentyp als "muss eindeutig sein" definiert (über ein Element
<xsd:key>)
- Relationships referenzieren Quell- und Zieltabelle nur über deren IDs. Durch ein Element
<xsd:keyref> wird sichergestellt,
dass die Werte der Attribute zu gültigen Tabellen-IDs gehören.
- Aufgrund der Struktur der Definition muss eine Spalte an einer Tabelle hängen, Spalten ohne Tabellen sind nicht möglich.
- Tabellennamen sind pro Datei eindeutig, Spaltennamen pro Tabelle (über ein Element
<xsd:unique<).
- Die Version der Definition wird in der XSD-Datei als Attribut "version" des "sherd"-Elements mitgeführt. Bei jeder Änderung
der xsd werde ich sie hochsetzen.
- Unsere Relationships haben exakt zwei Endpunkte, mehr als zwei verbundene Tabellen sind nicht vorgesehen.
Hierzu müsste aus zwei Attributen "Zieltabelle"/"Quelltabelle" vermutlich ein eigenes Unterelement "tabellenreferenz" oder ähnliches werden.
Eine Relationship kann 0 bis n Spalten (der Relationstabelle) enthalten. Für die Spaltennamen der Relationstabellen
gelten die gleichen Eindeutigkeitsregeln wie für Tabellenspalten).
Update 24.07.2009: Eine Relation hat in sherd.xsd 0.6 ein Attribut "relationname" (Pflichtfeld, muss im ganzen Diagramm eindeutig sein)
- Pro Datei wird genau ein Diagramm gespeichert. Mehrere Diagramme => mehrere Dateien.
- Pixelbreite und -höhe des Diagramms werden mitgespeichert.
- Der Datentyp der Spalten ist frei definiert, keinerlei Einschränkungen.
- Für Kardinalitäten sind die Werte "c" = 0/1, "1" = 1, "n" = 1..n, "nc" = 0..n erlaubt.
- Primary Keys werden über ein (optionales) Attribut "primarykey" der Spalte definiert.
Eclipse bietet die Möglichkeit, ein XML-Dokument gegen seine Schema-Definition zu validieren. In normalen Java-Projekten geht dies nur über das Contextmenü
der XML-Datei (Menüpunkt "Validate"), die Validierungsergebnisse werden als Messagebox ausgegeben. Wenn man den "Web Tools Platform"-Plugin installiert hat,
kann man sich ein "Dynamic Web Project" anlegen, in diesem werden XML-Dateien bei jedem Build validiert.
Die Beispiel-XML findet ihr Schema nur, wenn es im gleichen Verzeichnis liegt! Sobald wir eine finale Version haben, kann diese auf meine Seite gestellt und
von dort geladen werden.
Allgemeines
Führt eine Excel/OpenOffice-Tabelle mit, die ziemlich detailliert eure Arbeitsaufwände enthält
(wer hat wann was an welchem Projektteil gemacht?). Diese Tabelle benötige ich bei der finalen Abgabe,
um z.B. zu erkennen, wer mehr und wer weniger geschafft hat. Und vor allem kann ich dadurch Fehler in einzelnen
Modulen den Leuten zuordnen.
Ein Beispielgerüst habe ich hier: Stundenabrechnung.xls.
Ich habe zwei Karteireiter eingebaut, einen für Programmierung, einen für Doku. Ihr könnt die natürlich
detaillierter führen (z.B. Karteireiter für einzelne Module), meine Vorgabe ist das Minimum.
Drumherum
Eclipse:
Ich empfehle Eclipse 3.4.2 ("Ganymede"), und hier reicht uns im Moment das vorgefertigte Paket "Eclipse IDE for Java Developers".
SVN-Plugin
Für SVN-Zugriff gibt es zwei Möglichkeiten:
Im letzten SWT-Projekt hatten wir den Subversive-Plugin (http://www.eclipse.org/subversive/) benutzt.
Aktuell ist dies Version 0.7.7, um ihn zu installieren, muss man eine "Update Site" in Eclipse eintragen, und danach die SVN-Connectors einrichten.
Alternativ kann auch Subclipse (http://subclipse.tigris.org/) benutzt werden, das hatten wir in "Komponentenbasierte Architekturen" im
letztem Semester benutzt.
Aktuell ist dies Version 1.6.2, als "Update Site" muss http://subclipse.tigris.org/update_1.6.x in Eclipse eingetragen werden.
GUI-Designer
Ein brauchbarer GUI-Designer ist Jigloo: http://www.cloudgarden.com/jigloo/
Er ist frei für nicht-kommerziellen Gebrauch. Installationshinweise und Tutorial finden sich auf der verlinkten Seite.
Funktioniert problemlos mit Eclipse 3.4.2
Eclipse-Einstellungen
Vorschlag für Codeformatter- und JavaDoc-Einstellungen für Eclipse (aus der Softwaretechnik-Vertiefung des letzten Semesters):
Code-Formatter
Javadoc-Warn-Einstellungen (ACHTUNG: pro nicht behobener JavaDoc-Warnung gibt es einen Punkt Abzug!)
Blabla zum sauberen Programmieren
Kommentierung
Sinnvolles Arbeiten mit Exceptions: http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
Exception-Un-Konzepte: http://today.java.net/lpt/a/280#antipatterns
Beispiele
Zeichnen:
Zeichnen mittels SVG (Batik)
Alternative dazu: "Scene Graph": https://scenegraph.dev.java.net/
Zeichnen mittels Java3D
Socket-Grundlagen
XML lesen/schreiben
JavaHelp-Grundlagen
Design Patterns:
Für die Client/Server-Kommunikation empfehle ich das Command Pattern
Auf diesem aufbauend ist es möglich, Undo-Funktionalität zu bauen. Hierfür kann das Memento Pattern
zum Einsatz kommen.
Beide Patterns in einer Beschreibung: http://www.codeproject.com/KB/books/DesignPatterns.aspx
Literaturtips
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
Stand 23.08.2009
Historie:
25.03.2009: Erstellt
01.04.2009: Gruppen, Buchtip
08.04.2009: Gruppenleiter, Design Patterns
13.04.2009: Erster Entwurf der sherd-XSD
15.04.2009: Zweiter Entwurf der sherd-XSD (Version 0.2: Diagrammname, Eindeutigkeit Tabellen/Spaltenname, erlaubte
Werte für Kardinalität, "sherd"-Subelemente "tabellen" und "relations" hatten falsche Kardinalität)
16.04.2009: Beispiel "XML lesen/schreiben"
22.04.2009: Termine für Meilenstein 1, sherd.xsd 0.3 (Kommentare, eine Relation kann Spalten haben)
29.04.2009: Geänderter Meilenstein Gruppe 2, sherd.xsd 0.4 (optionales Attribut "primarykey" in Spalte), Link zum Batik-Beispiel
06.05.2009: sherd.xsd 0.5 (Diagramm-Breite/Höhe), Link zum Scene Graph-Projekt
10.05.2009: Java3D-Beispiel
13.05.2009: Gruppenteilung, Zusatzaufgabe
03.06.2009: Abschnitt "Saubere Programmierung"
10.06.2009: Link zum JavaHelp-Beispiel, Knauf-Bewertung
17.06.2009: Datum 2. Meilenstein, sherd.xml-Beispieldatei referenziert xsd im Web.
24.06.2009: Kriterien der Endabnahme
26.06.2009: Uhrzeiten der Endabnahme
24.07.2009: sherd.xsd 0.6: Element "relation" hat ein Attribut "relationname" (eindeutig über das ganze Diagramm)
05.08.2009: sherd.xsd 0.6 (keine neue Version): Keyname und referenziertes Element bei Relationsspalte/Tabellenspalte waren vertauscht (also nur Kosmetik)
07.08.2009: Berufungsvorträge
19.08.2009: Tausch Endabnahme Gruppe 2+3
23.08.2009: Link zu Bewertung