Entwicklungshelfer

Inhaltsverzeichnis

Verschiedene Entscheidungen prägen aktuelle Softwareentwicklungsprojekte. Eine ist sicherlich die Zielplattform: Die größten Kontrahenten sind hier die Java 2 Enterprise Edition von Sun und Microsofts .Net. Hinzu kommen verschiedene Open-Source-Varianten wie Zope oder PHP, traditionelle C/C++-Applikationen und aktive Legacy-Systeme mit Cobol und RPG/II.

Ebenso wichtig ist der Entwicklungsprozess. Moderne agile Verfahren [1] wie Extreme Programming (XP) orientieren sich stark am Code und benötigen hierfür Werkzeuge. Modellorientierte Methoden wie der Rational Unified Process sind hingegen mehr am Design und den hierfür notwendigen Programmen interessiert.

Eine Übersicht über einige am Markt verfügbare Werzeuge zur Softwareentwicklung soll zeigen, was Stand der Dinge ist und worauf man bei der Auswahl der Produkte achten muss. Eine Gruppe besteht aus traditionellen, codezentrierten Entwicklungsumgebungen. Diese existieren inzwischen seit gut 15 Jahren und haben eine beachtliche Reife entwickelt.

Designwerkzeuge bilden die zweite Gruppe. Sie haben sich aus dem Dasein als reine Zeichenprogramme für UML-Diagramme zu vollwertigen Entwicklungsumgebungen emporgearbeitet. Und mit der aktuell diskutierten Model Driven Architecture (MDA) bekommen sie einen weiteren Schub.

IDEs: dem Code verschrieben

Seit Mitte der 80er-Jahre gehört die Nutzung klassischer Entwicklungsumgebungen zur täglichen Arbeit von Programmierern. Ob in C/C++, Java, Delphi oder früher Pascal - der Bedarf ist ähnlich. Typische Projekte bestehen aus einer Vielzahl von Dateien: verschiedene Programmiersprachen, Ressourcen, Hilfetexte, Konfigurationen und vieles mehr. Dazu kommt die Aufgabe, all dies zu einem Produkt zu verbinden. Integrierte Entwicklungsumgebungen (IDEs) schaffen den Rahmen dafür. Sie halten die Dateien zusammen, lassen Entwickler zwischen ihnen navigieren, bieten einen integrierten Editor und unterstützen die Kompilierung sowie gegebenenfalls das Linking in das Zielformat. Als Turbo Pascal all dies in einer handlichen Anwendung brachte, war die Fachwelt begeistert. Doch die Anforderungen sind gestiegen, und die Umgebungen haben nachgezogen. Und so belegen heutige IDEs leicht Hunderte Megabyte auf der Festplatte.

Kernelement in diesem Wust ist für den Kodierer der Editor. Es genügt nicht mehr, wenn dieser nur automatisch einrückt und die Syntax farblich hervorhebt. Gute Produkte unterstützen inzwischen eine Vielzahl von Sprachen parallel, färben Schlüsselwörter, Bezeichner, Konstanten, Kommentare konfigurierbar ein und lassen den Entwickler die Tastaturbelegung nach seinen Wünschen anpassen. Gängige Standards wie die Vorgaben von Emacs, vi(m), SPF oder die gute, alte Wordstar-Belegung stehen als Vorbelegungen zur Verfügung.

Die Konfiguration der Einrücktiefe, der Nutzung von Leerzeichen oder Tabulatoren oder das Entfernen von Leerzeichen am Ende einer Zeile sind seit langem Standard. Spannender ist es, wenn der Editor den Code nach Entwicklervorgaben neu formatieren kann. So lässt sich ein einheitlicher Unternehmensstandard definieren und auf den Code anwenden. Ebenso können alte Quellen in das aktuelle Layout umgewandelt werden, was einem jungen Teammitglied die Pflege angejahrter Software erleichtert. Diese Funktion sollte nicht nur im Editor, sondern auch auf der Kommandozeile zur Verfügung stehen, damit die Qualitätssicherung diesen Vorgang automatisch erledigen kann. Für neue Quellen stellen hingegen konfigurierbare Templates den Standard sicher.

Stilfragen: Formatierung und Benennung

Guter Codestil zeigt sich in konsistenter Formatierung ebenso wie in den Bezeichnern. Für diese ziehen aktuelle Editoren den Klassennamen heran, sodass sie zum Beispiel für eine Klasse RendererFactory als Variablenbezeichner aRendererFactory, rendererFactory oder factory vorschlagen. Ebenso ziehen sie projekt-eigene und eingebundene externe Bibliotheken neben den Standardbibliotheken für die Codevervollständigung heran.

Dies erspart Schreibarbeit, sorgt für Einheitlichkeit - also bessere Wartbarkeit - und vermeidet Tippfehler. Gerade Letztere können Zeit und Nerven kosten, wenn sie sich erst beim Übersetzen offenbaren. Weitere Hilfen bei der Tipparbeit sind Vorlagen für typische Konstrukte wie Schleifen, das Ein-/Ausfalten von Blöcken, Aufteilen des Texts für die gleichzeitige Bearbeitung an zwei Stellen, die Überprüfung von Eingabefehlern und das automatische Einbinden von Importen. Dazu gehört ebenfalls Unterstützung, die die Intention des Entwicklers erkennt und ihm passende Operationen anbietet - etwa die Generierung neuer Methoden.

Ein wichtiger Faktor bei der Arbeit mit Code ist das Refactoring [2]. Im Extreme Programming nimmt es einen breiten Raum als Basiselement des Entwicklungsprozesses ein. Denn bei diesem Verfahren kommt es vielfach vor, dass Pakete, Klassen, Methoden oder Attribute umzubenennen oder zu verschieben sind. Dies muss reibungslos über das ganze Projekt funktionieren, also überall, wo der Code verwandt wird. Gleichzeitig ist es bei Verschiebungen eventuell erforderlich, Importe hinzuzufügen oder zu löschen. Zusätzliche Erschwernis erfährt diese Arbeit, wenn das Projekt unter der Kontrolle eines Konfigurationsmanagements steht. Da sich auch Dateinamen ändern, muss dieses Werkzeug sie in den darunter liegenden Repositories nachvollziehen.

Weitere Operationen im Refactoring, die die Entwicklungsumgebung unterstützen sollte, sind die Änderung von Signaturen, das Einführen neuer Methoden aus bestehendem Code, die Erzeugung von Schnittstellen aus bestehenden Klassen sowie das Hinzufügen und Entfernen von Attributen. Je mächtiger dieser Funktionsumfang ist, umso erfolgreicher arbeiten Entwickler mit dem Code. Er veraltet nicht so schnell und bleibt so schlanker und wartbarer.

Übersetzen und Linken automatisieren

Ebenso komfortabel und leistungsfähig soll der Umgang mit dem gesamten Projekt sein. Dateien müssen sich leicht hinzufügen oder entfernen lassen, ohne Build-Skripte für make oder Ant anzupassen. Aktuelle Entwicklungsumgebungen bieten entweder ein eigenes System für das Übersetzen und Linken oder können mit make oder Ant umgehen. Dabei unterstützen sie auch eine Aufteilung in hierarchische Teilprojekte. Die Stärke dieses Verfahrens liegt darin, dass auch externe Werkzeuge - beispielsweise zur Erzeugung von Dokumentationen oder zum Einsatz der Anwendung auf einem Testsystem - integrierbar sind. Letzteres spielt in der J2EE-Welt eine wichtige Rolle, in der die IDE nicht nur einfach Java- in Class-Dateien übersetzt, sondern sie samt Deployment Descriptor in ein Archiv packen und einem Application Server zur Ausführung übergeben muss.

Die Ausführung einer Applikation auf beziehungsweise in einem externen System führt zu einer weiteren Aufgaben, die man mit Entwicklungsumgebungen heute erledigen will. Während die Fehlersuche in lokal laufenden Applikationen noch recht einfach ist, gehört in der Java-Welt sowie beim Cross-Compiling das Remote Debugging zu den weiteren Anforderungen. Die Fähigkeiten der Debugger selbst sind mit absoluten und bedingten Breakpoints, der Beobachtung von Variablen sowie der schrittweisen Ausführung der Programme inzwischen einheitlich.

Weitere Hilfe bei der Arbeit mit dem Code geben Navigationswerkzeuge. Sie zeigen als Cross Referencer an, wer welche Klassen, Variablen oder Methoden verwendet. Hierarchy Browser verdeutlichen hingegen, welche Klassen welche Schnittstellen implementieren und wie Klassenhierarchien aufgebaut sind. Intelligentere Browser suchen nach ungenutzten Klassen, Methoden, Attributen oder Codefragmenten, entdecken „unmögliche“ Verzweigungen oder die fehlende Ausnahmebehandlung. Zwar kann man auch ohne dies guten Code erzeugen, aber solche Funktionen helfen, stabile Applikationen zu schreiben.

In der Printausgabe finden Sie mehr über den aktuellen Stand der Konzepte bei Entwicklungswerkzeugen sowie Daten und Preise von 20 Tools. (ck)