Benutzer-Werkzeuge

Webseiten-Werkzeuge


toyexercise:abgabemodalitaeten

Abgabemodalitäten

Namenskonventionen

Die implementierten Klassen sollen als jar-Datei im Moodle hochgeladen werden. Dabei ist eine strikte Namenskonvention für diese Dateien zu beachten! Da ein Teil der Kontrolle mit Hilfe automatisierter Skripte durchgeführt wird, können nur Abgaben bewertet werden, die diese Konvention auch einhalten. Jeder Aufgabe entspricht einem Teil des gesamten Packages, welcher sich im Namen der jeweiligen jar-Datei zusammen mit der Gruppen-Nummer wiederfinden soll: toydb.<package>.impl.<GruppeNr>.jar.

Beispiel: Eine Gruppe mit „Schlüssel“-Nummer 5 soll die Basis-Komponenten Record-Manager (rm), Index-Manager (ix) und Query-Processor (qp) erstellen. Im Verlauf der Veranstaltung müssen daher insgesamt 3 jar-Dateien abgeliefert werden: toydb.rm.impl.5.jar, toydb.ix.impl.5.jar und toydb.qp.impl.5.jar.

Wie auch im Packagenamen sollen die Klassennamen in den von Ihnen erstellten Implementierungs-Packages i.d.R. dem Namen der jeweilgen Schnittstelle entsprechen, unter Zusatz der Endung Impl. In Ausnahmefällen wird eine andere Namensgebung nötig (z.B. sind die Implementierungen der Index-Schnittstelle benannt nach der konkreten zu Grunde liegenden Zugriffstruktur, also beispielsweise BTree und RTree statt IndexImpl), achten Sie daher immer auf entsprechende Anweisungen bei den jeweiligen Aufgabenbeschreibungen!
Beispiel: Die Implementierung der Schnittstelle RecordFile im vorgegebenen Package toydb.rm hat also den Namen RecordFileImpl und befindet sich im Package toydb.rm.impl. Im Java-Quellcode sieht das dann z.B. so aus:

package toydb.rm.impl;
...
import toydb.*;
import toydb.rm.RecordFile;
...
public class RecordFileImpl implements RecordFile
{
...
}

Achten sie unbedingt darauf, dass ihre jar-Dateien auch den Quellcode und nicht nur die übersetzten Klassen enthalten!! Abgegebene Dateien, die keinen Quellcode enthalten, werden nicht beachtet! Desweiteren sollen die Dateien nur die Klassen des zu bearbeitenden Packages enthalten. Alle anderen Komponenten die benötigt werden, sind nur über separate jar-Dateien zu nutzen! Diese Dateien liegen dem Kontrolleur der Übungen bereits vor, sollen also nicht extra abgegeben werden.

Die einzelnen Teile des Projektes bauen aufeinander auf. Dabei hat sich jedes Team strikt an die vorgegebenen Schnittstellen zu halten. Das heißt zum Einen, dass die automatisierten Tests für ein Teil-Package nur die in der Schnittstelle vorgegebenen Klassen- und Methodennamen nutzt. Zum Anderen heißt das aber auch, dass jedes Team damit rechnen muss, dass seine Implementierung eines Teils des Projektes mit Teilen anderer Gruppen in Verbindung getestet wird. Somit ist es also unabdingbar, dass aufeinander aufbauende Implementierungen nur die Methoden anderer Teil-Packages nutzen, die auch in der Schnittstelle definiert sind!

Änderungen an bereits abgegebenen Dateien sind nicht möglich. Die einzige Ausnahme hierfür ist der Fall, dass aktuelle Übungen nicht angefertigt werden können, weil die zuvor implementierten Klassen fehlerhaft oder unvollständig sind. In diesem Fall müssen alle Änderungen beim Leiter der Übungen begründet werden. Erst mit dessen Einverständnis können Änderungen an bestehenden Teilen des Projektes durchgeführt werden. Da die Arbeit am Projekt möglichst realitätsnah angelegt ist, ist eine Akzeptanz der vorgeschlagenen Änderungen prinzipiell abhängig von kostenorientierten Faktoren. Anträge auf Änderungen sollten dies berücksichtigen und dementsprechend formuliert werden! Sollten eventuelle Änderungen akzeptiert werden, so sind die geänderten Versionen wiederum in getrennten jar-Dateien (Namenskonvention siehe oben) abzuliefern. Änderungen aus Effizienzgründen, z.B. am RecordManager um später den IndexManager effizienter gestalten zu können, werden prinzipiell abgelehnt. Ein überlegtes Design der entwickelten Software im Hinblick auf spätere Anforderungen ist also von vornherein zu beachten!

Dokumentation

Zu jedem abgegebenen Teil der gesamten Implementierung wird eine klare und übersichtliche Dokumentation erwartet, welche mit in die Bewertung einfließt. Diese Dokumentation soll einen kurzen Gesamtüberblick über die Implementierung, wichtige Designentscheidungen und das allgemeine Vorgehen geben. Eine überblicksartige Dokumentation der erstellten Klassen mit Hilfe von Javadoc wird ebenso erwartet, wobei die beiden Teile keine Überschneidungen beinhalten sollten. Besondere Abschnitte wie besonders trickreiche Schleifen o.ä. sollten im Code kurz kommentiert werden. Den ersten Teil der Dokumentation, den kurzen Gesamt-überblick, laden sie bitte als PDF-Datei toydb.<package>.impl.<GruppeNr>.pdf zusammen mit der entsprechenden jar-Datei als ZIP-Archiv im Moodle hoch. Die Javadoc-Kommentare sollen so im Quellcode verankert werden, dass ein einfacher Aufruf von javadoc auch die gewüschte Klassendokumentation liefert.

Bitte auf dem ersten Blatt zur Doku auch die Gruppen-Nr. mit angeben!

Sinn der Dokumentation ist es, dem Kontrolleur der Übungen einen schnelleren Überblick über das Design der Implementierung und die realisierte Lösung der Problemstellung zu verschaffen. Denken sie immer daran: Je klarer und übersichtlicher dokumentiert wird, desto schneller und leichter kann die Lösung bewertet werden und um so freundlicher ist auch die Einstellung dabei! ;-)

Fehlerbehandlung

Wie es in Java üblich ist hat die Behandlung von Fehlern mittels einer entsprechenden Ausnahmebehandlung zu erfolgen. Abweichungen hiervon (Benutzung von Fehlercodes o.ä.) werden als schlechtes Design bewertet, auch wenn die Implementierung fehlerfrei arbeitet.

Die abgelieferten Implementierungen dürfen intern keinerlei Ausgaben produzieren (es sei denn es ist in irgendeiner Art gefordert).

Gewinnung von Statistiken

Um eine effiziente Implementierung zu erreichen ist es hilfreich, das Speicherverhalten der Klassen und Methoden zu analysieren. Um Ihnen dies zu ermöglichen wird eine Klasse zur Aufzeichnung verschiedener Statistiken bereitgestellt. Die Klasse trägt den Namen toydb.pf.impl.PFStatistics und implementiert die Schnittstelle toydb.stats.Statistics. Die Dokumentation zur Benutzung dieser Klassen finden Sie zusammen mit den anderen Schnittstellen-Dokumentationen des ToyDB-Projektes.

toyexercise/abgabemodalitaeten.txt · Zuletzt geändert: 2013/04/22 09:38 von hagedorn