Programmierprojekt HT08 (Modul 1136)

Leitung: Dipl. Inform. Daniel Volk, Sonja Maier, M.Sc.

Der technische Rahmen

Zu Frameworks im Allgemeinen

In schöner Regelmäßigkeit wird jedes Jahr während des Programmierprojekts die Frage gestellt, warum das Framework SalesPoint verbindlich vorgegeben wird. Dies hat mehrere Gründe, u.a. ergeben sich so bei Verwendung des Frameworks folgende Vorteile:

Durch das Framework ist eine Grundarchitektur vorgegeben. Das erleichtert den für Unerfahrene schwierigen OO Entwurf.
Einarbeitung in bestehende Programmsysteme gehört zum Arbeitsalltag des Software-Entwicklers. Das Framework ist durch die ausführliche Beschreibung und die flexible Anpassungsschnittstelle vergleichsweise gut zugänglich.
Es soll Wiederverwendung bewusst eingeübt werden. Unerfahrene Entwickler neigen dazu, laufend das Rad neu zu erfinden. Auf diese Weise entstehen unkontrollierte Code-Doubletten, die - weil nicht zusammenhängend - nicht systematisch gewartet (verbessert oder an neue Gegebenheiten angepaßt) werden können. Im Gegensatz dazu erfordert die Wiederverwendung von Bausteinen deren laufende Anpassung und führt dadurch zu immer flexibleren und verlässlicheren Komponenten: die Qualität steigt, die investierte Mühe lohnt sich mittel- und langfristig.

Neben dem zweckgemäßen Einsatz des Frameworks werden daher auch Beiträge zu dessen Verbesserung (neue, universell einsetzbare Bausteine, oder überarbeitete alte) besonders positiv gewertet.

Um Wildwuchs zu vermeiden, werden die Frameworks den Anwendungsentwicklern zudem nicht im Quelltext zur Verfügung gestellt. Es werden nur die übersetzten Bibliotheken bereitgestellt.

Zu SalesPoint im Speziellen

Sämtliche Informationen zum SalesPoint-Framework finden sich auf der zugehörigen [Projekt-Homepage]. Die einander ergänzenden Beschreibungen sollen Ihnen den Einstieg in die Materie und in seine Verwendung erleichtern. Im Hinblick auf die empfohlene Vorgehensweise bei der Einarbeitung, beachten Sie bitte die Hinweise zur [Einarbeitungsphase] des Praktikums.

Bitte bedenken Sie auch: Alle Beschreibungen enthalten technische Anteile, die möglicherweise erst beim wiederholten Lesen oder aufgrund eigener Erfahrungen verständlich werden, daher gilt: öfter mal wieder zur Hand nehmen - das ist sehr nützlich! Während die Übersicht und das Tutorial fortlaufend gelesen werden sollten, wird man die z.B. die JavaDoc-Beschreibung wohl eher zum Nachschlagen und zur Klärung von Zweifelsfällen verwenden.

Die Entwicklungswerkzeuge

Um dem Praktikum einen einheitlichen Rahmen zu geben und zusätzlich die Handhabung der programmtechnischen Artefakte deutlich zu vereinfachen, ist die Verwendung der im Folgenden beschriebenen Entwicklungswerkzeuge vorgeschrieben. Ein unbedingtes Muss ist weiterhin die Verwendung der selben Versionen aller Werkzeuge innerhalb der Teams. Genutzt werden hierbei:

Das [Java JDK 6.0 Update 7] als Sprachplattform.
Der [Rational Systems Developer v7.0] für Modellierung und Entwicklung (ist de facto eine Art "Eclipse extended" mit vielen installierten PlugIns). Das in der Installationsanleitung erwähnte Aktivierungskit wird zeitnah zur Verfügung gestellt. Wichtig hierbei ist, dass die Nutzung des Aktivierungskits nur für den Einsatz an der Uni und auch nur im Rahmen dieses Praktikums zulässig ist (nach dem Praktikum ist die Software wieder zu deinstallieren!). Eine Weitergabe an Dritte ist untersagt, das Aktivierungskit darf die Uni auf keinen Fall verlassen - bei Ausgabe der Software werden alle Teilnehmer eine diesbezügliche Erklärung unterzeichnen!
Das Eclipse SVN-PlugIn [Subclipse v1.2.3] zum Zugriff auf den SubVersion- Server vom Rational Systems Developer aus. Der jeweilige Entwicklungsordner der Gruppe befindet sich hierbei unter https://137.193.60.90/progproj/progproj08/inf<x> bzw. winf<x>. Der Login ist der jeweilige Nachname zzgl. des ersten Buchstabens des Vornamens, das entsprechende Gruppenpasswort wird zeitnah vor dem Praktikum mitgeteilt.
Die Bibliotheken JUnit und Ant in den im Rational Systems Developer vorliegenden Versionen. Dokumentation zu den Tools sind auf den jeweiligen Homepages ([JUnit] [Ant]) zu finden.
Die JavaDoc- und Jar-Funktionalität aus dem installierten JDK.

Hinweise:

Für Javadoc gibt es eine sehr praktische, aber relativ unbekannte Funktion um im eigenen JavaDoc automatisch auf andere JavaDocs zu verlinken, z.B. auf das vom SDK oder auf das von SalesPoint. Dafür gibt es den Kommandozeilenparameter -link url. Unter Windows sieht das dann z.B. so aus:

javadoc.exe -d docs -sourcepath src -link http://java.sun.com/javase/6/docs/api/ -link http://www-st.inf.tu-dresden.de/SalesPoint/v3.3/documentation/javadoc/ -use org.package1 org.package2

Damit man unabhängig vom eigenen Rechner wird ist es ratsam, auf WWW-Adressen zu verweisen. Das Beispiel hier verweist nun auf das Java SDK und SalesPoint. Verwendet man Eclipse, um das JavaDoc generieren zu lassen, so muss man im Ant-file zwischen die <javadoc>-Tags noch <link>-Tags einfügen. Das sieht dann z.B. so aus:

<javadoc ...>
<link href="http://java.sun.com/javase/6/docs/api/" />
<link href="http://www-st.inf.tu-dresden.de/SalesPoint/v3.3/documentation/javadoc/" />

Beim Erstellen des JavaDoc ist eine der beiden Möglichkeiten anzuwenden. Außerdem soll das JavaDoc immer so erstellt werden, dass alle Informationen sichtbar werden, auch solche, die als private deklariert sind.
Um mit Jar ein ausführbares Archiv zu erstellen muss man eine Reihe von Schritten durchführen. Zunächst benötigt man ein sog. Manifest. Das ist eine Textdatei beliebigen Namens, z.B.manifest.mf. Dort aufgeführt wird, vollständig referenziert, die Klasse, in der die main-Methode zu finden ist, gefolgt von einer Leerzeile (wichtig!), so z.B.

Main-Class: org.demo.MeinMain
(hier die Leerzeile)

Gehen wir nun davon aus, dass sich alle .class Dateien im Unterverzeichnis bin befinden, dann sieht der notwendige Jar-Aufruf unter Windows etwa so aus:

jar.exe cvfm video.jar manifest.mf -C bin .

Wenn man nun noch externe .jar Dateien in seinem Projekt benötigt (so wie bei uns SalesPoint oder JUnit), dann muss man diese erst entpacken (das geht mit jar.exe oder einem normalen zip-Entpacker), und die .class Dateien, die darin enthalten sind, auch in bin kopieren (und dabei natürlich deren Ordnerstruktur beibehalten). Am Aufruf für jar.exe ändert sich dadurch nichts.
Zu den Themen IBM RSD, SVN+Subclipse, JUnit und JavaDoc+Java2HTML stehen ebenfalls noch die [Vorträge] von Seiten der Tutoren zur Verfügung.

Die Dokumentationswerkzeuge

Die Web-Seiten der Teams sind das primäre Kommunikationsmedium für das Programmierpraktikum, sie sind demzufolge auch die hauptsächliche Informationsquelle für den Praktikumsleiter. Wichtig ist also, dass Sie diese regelmässig aktualisieren und selbigen eine einfach zugängliche und übersichtliche Struktur geben. Der Fokus der Web-Seiten liegt hierbei eindeutig auf dem Inhalt und nicht in additiven, technischen Spielereien! Gestalten Sie die Seiten also schlicht und investieren sie nicht allzuviel Zeit in das Layout. Halten Sie sich beim Aufbau ihrer Seite an die in der gegebenen [Vorlage] enthaltenen Struktur und integrieren Sie alle notwendigen Artefakte (siehe hierzu auch [Projektrahmen]/ [Projektphasen])! Nutzen Sie zum Erstellen und Pflegen der Seiten den Editor Ihrer Wahl - damit lässt sich Zeit sparen.

Als Ablageort für die Web-Seiten steht jedem Team ein BSCW-Ordner zur Verfügung. Der Zugang zu diesem wird den Mitgliedern der Gruppe per RZ-Kennung ermöglicht (die Freigabe erfolgt zeitnah vor dem Praktikum). Der einfachstmögliche Zugriff kann per WebDAV-Protokoll erfolgen - auf diese Weise kann das BSCW-Verzeichnis wie ein virtueller Ordner genutzt werden. Hierzu gibt es eine [Anleitung]

Hinweise:

Die Szenarien sind als schlichte Textseiten (bzw. Textdateien) abzulegen, welche nach dem aus der Übung bekannten Schema eingerückt sind.
Die CRC-Karten (Papier-Variante!), welche sich aus den Sitzungen in der Analysephase ergeben, sind in eingescannter Form (bitte in moderater Auflösung!) abzulegen. Ein Transfer in eine wie auch immer geartete EDV-Variante ist nicht gefordert!
Die geforderten GUI-Skizzen (auch die Papier bzw. Whiteboard-Variante!), welche aus dem Storyboarding hervorgehen, sind ebenfalls in eingescannter Form (bitte auch hier in moderater Auflösung!) abzulegen.
Alle UML-Diagramme sind nicht nur als Screenshot abzulegen, sondern auch per zusätzlichem Text zu erläutern (nur die Diagramme für sich sind in den allermeisten Fällen noch nicht sehr aussagekräftig). Die Nutzung der vorhandenen Export-Funktionalität des Rational Systems Developer kann hier Zeit und Mühen in erheblichem Umfang ersparen - selbige sei deswegen dringend empfohlen!
Für die Darstellung von Quelltext gilt folgende Regelung: ab fünf Zeilen wird das Ganze mit [Java2HTML] dargestellt, damit die Übersichtlichkeit gewahrt bleibt. Die Verwendung von Screenshots zur Darstellung von Quelltext ist inakzeptabel!
Benutzer- und Testhandbuch sind auf den Web-Seiten als PDF-Dokumente abzulegen. Das ursprüngliche Dateiformat ist hierbei beliebig, nutzen Sie diesbezüglich den Editor Ihrer Wahl! Orientieren Sie sich beim Aufbau des Testhandbuchs an der gegebenen [Vorlage]!

zurück