5.3 Werkzeuge und Hilfsmittel

5.3.1 IDE (Integrated Development Environment)

Eine IDE ist ein auf die Bedürfnisse des Softwareentwicklers zugeschnittener Texteditor, der um sehr viele Funktionen erweitert wurde, die den Entwickler unterstützen. Bei kommerziellen Programmiersprachen werden diese Entwicklungsumgebungen für sehr viel Geld inkl. speziellen Compiler und Servern verkauft. Es gibt aber auch kostenfreie Alternativen, die allerdings oft im Gegensatz zu den kommerziellen weniger Funktionen haben und für die man keinen Support bekommt.

Allerdings entwickelt sich in den letzten Jahren der Trend, dass die großen Hersteller, wie z.B. IBM, ihre Entwicklungen als Open Source freigeben (z.B. Eclipse) und weiterhin massiv (finanziell und mit Resourcen) unterstützen, was man an den Neuentwicklungen im Quellcode erkennen kann. Diese neuen Versionen setzen viele Firmen dann ein und bauen eigene kommerzielle Lösungen daraus, die natürlich noch wesentlich mehr können und sehr gut an die eigenen Produkte angepasst werden.

5.3.2 Automatisierung

Bei der Entwicklung ist man immer wieder gezwungen den Code zu kompilieren oder andere verschiedene sich wiederholende Tätigkeiten auszuführen. Es gibt diverse Hilfsmittel, die den Programmierer unterstützen, die sich wiederholenden Tätigkeiten zu automatisieren. Eines der meist benutzten Hilfsmittel ist Ant, das eine Skriptsprache für diese Automatisierung ist. Eine Beschreibung verschiedener Werkzeuge um Ant findet man in BACKSCHAT/EDLICH 2004. Da eine ausführliche Besprechung den Rahmen dieser Arbeit sprengen würde, beschreibe ich Maven, ein Projekt, das auf Ant aufbaut und welches ich auch verwendet habe.

Da die Aufgaben bei jedem Entwickler sehr ähnlich sind, wurde das Projekt Maven (vgl. Seite 54) initiiert, das auf Ant aufbaut. Maven stellt eine Sammlung von Skripten zur Verfügung, die über sogenannte "Goals" aufgerufen werden können. Ein Goal zum Kompilieren wäre "java:compile". Zwischen den Goals bestehen auch Abhängigkeiten, so ruft das Goal "jar:install" vorher noch "java:compile" und diverse andere Goals auf. Der Vorteil liegt darin, dass man die üblichen Skripte nicht mehr bei jedem neuen Projekt kopieren und anpassen muss. Außerdem sieht jede Projektstruktur eines Maven-Projektes immer sehr ähnlich aus, was es erleichtert im Team zu arbeiten. Natürlich ist es auch möglich eigene Goals zu schreiben.

In einem Maven-Projekt hat man, im Gegensatz zu Ant-Projekten, nur noch Projektinformationen (project.xml, project.properties), in denen alle wesentlichen Aussagen über das Projekt stehen. Dort finden sich vom Projektnamen bis zu den Abhängigkeiten zu anderen Projekten alle Informationen wieder, aber keine Skripte, wie es bei Ant oft der Fall war. Die eigenen zusätzlichen Goals sind in der maven.xml zu finden.

Ende Oktober 2005 wurde Maven 2.0 veröffentlicht, welches ein komplettes Redesign ist, weil Maven 1.x einige konzeptionelle Fehler hatte.

5.3.3 Code-Generatoren

Code-Generatoren sind ein Werkzeug, das aus Informationen (meist an zentraler Stelle, z.B. im Quellcode, abgelegt) Code und Meta-Daten generiert und damit die Fehlerrate deutlich senkt und die Effizienz steigert, indem es viel Tipparbeit und Synchronisation zwischen Meta-Daten und Quelltext erspart. Teilweise können Generatoren aus Modellen schon halbfertige Software erstellen, bei der nur noch die Methodenrümpfe programmiert werden müssen. Diese Software ist häufig im kommerziellen Bereich bei sich wiederholenden Aufgaben (z.B. ein Shop hat immer einen Bestellvorgang, der immer sehr ähnlich ist) anzutreffen und nennt sich MDA (Model Driven Architecture).

In diesem Projekt habe ich XDoclet benutzt, welches für die Generierung von verschiedensten Dingen ausgelegt ist. Über sog. Annotations (Meta-Informationen im Java-Quellcode) werden dabei benötigte Dateien generiert. Das hat den Vorteil, dass der Code und die Meta-Informationen zusammen in einer Datei sind. XDoclet kann man auch über Ant und damit auch in Maven aufrufen, so dass man bei jeder Quellcode-änderung die erforderlichen Dateien neu generieren muss und der aufwändige und fehlerbehaftete Prozess der Synchronisierung der verschiedenen Dateien entfällt.

Beispielsweise muss bei der Hibernate-Persistenz zu jedem POJO (Plain Old Java Object) eine Mapping-Datei in XML erstellt werden, damit Hibernate weiß, welche Verbindungen zu anderen Objekten bestehen und wie die Tabelle in der Datenbank aussieht, die dieses POJO repräsentiert. Bei der Hibernate-Persistenz wird man stark durch Programme unterstützt, so kann man aus einem UML-Diagramm die Hibernate-Mappings und POJOs generieren und daraus wiederum die Datenbank automatisch anlegen lassen, so wie ich es auch gemacht habe. Dabei muss man nicht eine Zeile SQL schreiben. Aber es funktioniert auch anders herum: Die vorhandene Datenbank wird ausgelesen und daraus POJO und die Mappings erzeugt. Einige UML-Programme können aus dem Java-Code die UML-Diagramme erzeugen, was Reverse-Engeneering genannt wird.

Bei EJBs sind so viele Schritte nicht nötig, denn hier werden aus der Bean-Klasse die jeweils benötigten Dateien (Home-, Local-, .., Remote-Klassen) erzeugt. Zur weiteren Lektüre kann ich BACKSCHAT/EDLICH 2004 sehr empfehlen, denn hier würde dieses Thema den Rahmen sprengen.

5.3.4 Build- und Test-Automatisierung

Die Automatisierung von Builds (Kompilieren und in ausführbare Dateien kopieren) und Qualitäts-Tests ist ein essentieller Bestandteil der Vorgänge in jeder guten Softwarefirma. Diese Abläufe manuell durchzuführen ist nicht nur unsicher, fehleranfällig und unpraktikabel, weil es oft nur in der Nacht oder am Wochenende geschehen kann, sondern auch sehr zeitaufwändig und damit teuer. Daher möchte man diese Vorgänge, da sie immer nach dem gleichen Schema ablaufen, so weit wie möglich automatisieren.

Bei einem Integrationstest müssen erst alle Quelltexte aus dem Versionsverwaltungsserver (siehe 5.3.5) geholt und dann kompiliert werden, so wie es der Entwickler am Arbeitsplatz mit einem Teil der Projekte auch macht. Danach werden die ausführbaren Dateien erstellt und automatisch getestet. So werden alle Projekte den Abhängigkeiten folgend bearbeitet und getestet.

Verschiedene Tools (z.B. Anthill, CruiseControl, Continuum, LuntBuild) bieten diese automatischen Builds an und können (wenn sie sinnvoll in die Entwicklungsprozesse integriert sind) dazu beitragen, dass die Code-Qualität steigt. Auch dieses Thema ist zu umfangreich für weitere Erläuterungen, daher nochmal die Empfehlung, dass BACKSCHAT/EDLICH 2004 dieses Thema auch für Anfänger sehr gut dargestellt haben.

5.3.5 Versionskontrolle

Die Versionskontrolle ist ein Server, der Zugriff auf die verschiedenen Versionsstände der Quelltexte bereitstellt. Abgekürzt werden solche Systeme VCS (Version Control System) oder SCM (Source Code/Control Managementsystem). Es gibt zwei Ansätze der Systeme, die traditionelle pessimistische Vorgehensweise, bei der ein Quelltext vom Benutzer gesperrt und wieder freigegeben wird und die optimistische Vorgehensweise, bei der das gleichzeitige Bearbeiten der selben Datei erlaubt ist und die Änderungen beider Benutzer zusammengeführt (merge) werden. Der Server versucht dies erst automatisch, falls dies scheitert, muss der Benutzer manuell "mergen".

Ohne so ein System ist es nur sehr schwer möglich, im Team an einem Projekt zu arbeiten. Das meist verbreiteste Versionskontroll-System ist CVS, das auch eine sehr gute Integration in Eclipse hat. Ein neues für Java relevantes Versionscontroll-System ist SVN, die derzeit eine noch nicht ganz so stabile Integration in Eclipse hat, dafür aber viele Vorteile gegenüber CVS bietet, wie z.B. über alle Dateien durchgängige Versionsnummern. Bei CVS hat jede Datei eine eigene Versionsnummer, so dass man nicht beliebige Versionsstände aus dem Versionsserver holen kann, sondern nur vom Entwickler markierte Versionen.

Eine Liste von Versionskontroll-Systemen findet man auf Wikipedia. Dort findet man Links und Vergleiche der einzelnen Systeme.