Auf dem Markt existieren mehrere Entwicklungsumgebungen. Mit
vielen dieser Entwicklungsumgebungen kann man auch eine
Dokumentation erstellen. Hier stelle ich als Beispiel die
Produkte von Rational Rose und von MicroTOOL vor und vergleiche
diese zwei Werkzeuge.
Software Documentation Automation, kurz SoDA,
ist eine Erweiterung für die Rational Rose Entwicklungsumgebung.
Damit ist es möglich, Informationen für die Dokumentation aus
der Entwicklungsumgebung zu erhalten. Die Informationen werden
entweder in das Programm Microsoft Word oder in das Programm
Adobe FrameMaker+SGML übernommen [Rational Rose].
Bei der Entwicklung der Software entsteht in der
Entwicklungsumgebung ein Modell, das Daten enthält, wie
Zu jedem dieser Teile gibt es spezielle
Informationen, bei den Klassen zum Beispiel die Anzahl der
Objekte dieser Klasse im System oder das Modul zu der diese
Klasse gehört. Aus diesen Informationen generiert das Programm
C++ Dateien mit den Klassendefinitionen. In diese Dateien muß
nur noch der Programmcode eingegeben werden. Neben diesen
Informationen läßt sich auch ein freier Text eingeben. Dieser
Text dient zur Beschreibung und wird in die C++ Dateien
übernommen.
Abbildung 12: Import von Daten nach Word
[Rational Rose]
Um alle diese Informationen ohne erneute Eingabe nutzen zu
können, importiert SoDA die Informationen aus der
Entwicklungsumgebung nach Word bzw. FrameMaker. Dabei ist SoDA
direkt in die Programme integriert. Wie dies geschieht, wird am
Beispiel von Word dargestellt, siehe Abbildung 12. In der
Abbildung sind links die Eingabefelder der Entwicklungsumgebung
dargestellt und rechts ist das von SoDA aus diesen Daten
erstellte Worddokument.
Die Informationen, die die Entwicklungsumgebung zur Verfügung
stellt, sind unstrukturiert. Deshalb muß SoDA Funktionen
anbieten, um die Informationen zu strukturieren. Diese Funktionen
sind in einem Menüpunkt in Word vorhanden. Es stehen die
Funktionen
zur Verfügung. Mit der OPEN Funktion wird
angegeben, woher die Informationen kommen. Die DISPLAY Funktion
dient zum Ausgeben der Informationen. Dabei muß das gewünschte
Objekt und die gewünschte Information über das Objekt, z.B.
Name oder Beschreibung, angegeben werden. Weitere
Auswahlmöglichkeiten dienen zur Änderung des Aussehens.
Die REPEAT-Funktion wiederholt einen Abschnitt für alle
ausgewählten Objekte. Somit ist es möglich, alle
Klassendiagramme oder alle Klassenbeschreibungen in die
Dokumentation aufzunehmen. Mit der LIMT Funktion werden Ausnahmen
berücksichtigt, z.B. das Fehlen von Diagrammen eines bestimmten
Typs. Dann kann statt den Diagrammen ein Hinweistext erscheinen.
Abbildung
13: Datenfluß in SoDA [Rational
Rose]
Mit diesen Funktionen läßt sich zusammen mit
eigenen Texten, z.B. Überschriften, und Formatierungsanweisungen
sehr flexibel ein Template erstellen. Dadurch ist es möglich,
ein auf die eigenen Bedürfnisse angepaßte Dokumentation zu
erstellen. In dieses Template importiert SoDA die Informationen
an die durch die Funktionen vorgegebenen Stellen. Die so erzeugte
Dokumentation läßt sich noch beliebig durch Eingeben von
zusätzlichen Texten vervollständigen (vgl. Abbildung 13). Eine
Änderung des Entwurfs in der Entwicklungsumgebung kann jederzeit
in die Dokumentation übernommen werden. Dabei gehen die
ergänzten Texte nicht verloren. Sie bleiben an den
entsprechenden Stellen in der Dokumentation enthalten.
Bei ObjectiF von MicroTOOL handelt es sich auch um eine
Entwicklungsumgebung für objekt-orientierte Programme. In diese
Entwicklungsumgebung entstehen die gleichen Daten wie bei dem
Programm von Rational Rose (Klassendiagramme, Szenario-Diagramme,
Beschreibungen von Klassen, Methoden und Attribute) [MicroTOOL].
Diese Daten lassen sich für eine Dokumentation direkt nach Word
exportieren.
Abbildung
14: Datenauswahl in ObjectiF
[MicroTOOL]
Der Export der Daten geschieht über die
OLE-Schnittstelle. Dazu ist eine Dokumentenvorlage für Word
vorhanden. Diese Vorlage definiert die Schriften für die in Word
importierten Daten. Außerdem stellt sie eine Funktion zur
Verfügung, mit der die Daten importiert werden. Diese Funktion
öffnet ein Fenster (Abbildung 14), das die Auswahl der zu
importierenden Daten erlaubt. Neben der Dokumentation lassen sich
auch Metriken erstellen. Diese Metriken, z.B. Anzahl der
Klassenmethoden, geben einen Anhaltspunkt über die Qualität des
Entwurfes an.
Bei der Erstellung einer Dokumentation können die Daten
beschränkt werden. Dies geschieht durch Auswahl der Komponenten,
denn die Ausgabe der Subjekte, der größten Einheiten in
ObjectiF, enthält zum Beispiel die Klassenmodelle des
ausgewählten Subjektes. Die Daten der einzelnen Komponenten
lassen sich noch weiter beschränken. So sind bei der Komponente
Subjekt die in der Abbildung 15 dargestellten Daten auswählbar.
In den kleineren Komponenten stehen nur noch die Daten zur
Auswahl bereit, die in dieser Komponente oder den darunter
liegenden Teilkomponenten vorhanden sind.
Abbildung
15: Mögliche Daten für die
Dokumentation [MicroTOOL]
ObjectiF exportiert die Daten in einem festen
Format. Der Entwickler kann nur schwer die Reihenfolge der Daten
verändern. Für eine bestimmte Reihenfolge muß er die Daten
nacheinander importieren und entsprechend aneinanderreihen. Dies
ist jedoch mit großem Aufwand verbunden, da dies nicht für
mehrere Dokumentationen automatisierbar ist.
Entgegen des festen Formates für die gesamte Struktur ist die
Möglichkeit der Beschreibungen der einzelnen Teile sehr
flexibel. Die Beschreibungen werden in Word geschrieben. Dazu
überträgt ObjectiF ein vorgegebenes Layout an Word über die
OLE-Schnittstelle. In dieses Dokument kann der Entwickler den
Text eingeben. Word gibt die Änderungen an ObjectiF zurück, das
dann die Änderungen speichert. Die vorgegebenen Layouts sind
leicht änderbar, denn sie liegen als Wordvorlagen vor. Damit
läßt sich die Beschreibung der einzelnen Objekte, z.B. die
Klassenbeschreibungen, speziell an die eigenen Bedürfnisse
anpassen und in einzelne Abschnitte untergliedern. Da diese
Anpassung für alle Objekte eines Typs gilt, sind somit die
Beschreibungen einheitlich und ein Leser der Beschreibung findet
sich leicht in der Beschreibung zurecht. Außerdem enthalten die
Beschreibungen nach dem Ausfüllen alle nötigen Informationen.
Es ist im Gegensatz zu einer freien Beschreibung nicht möglich,
einzelne Teile der Beschreibung zu vergessen.
Bei den beiden Entwicklungsumgebungen ObjectiF und Rational
Rose werden die Daten für die Dokumentation aus der
Entwicklungsumgebung übernommen. Dazu müssen die Entwickler
aber beim Entwicklungsprozeß alle Informationen, die für das
Verständnis wichtig sind, eingeben.
Bei einem Vergleich zwischen den beiden Werkzeugen zur
Dokumentation zeigt sich, daß das Programm SoDA wesentlich
flexibler ist als ObjectiF. Der Benutzer von SoDA kann das
Aussehen und die Art der Dokumentation durch die Erstellung von
Templates wesentlich beeinflussen. Die so erzeugten
Dokumentationen sind dann natürlich eher an die Bedürfnisse der
Software angepaßt. Bei ObjectiF kann nur der Umfang der
Dokumentation bestimmt werden. Durch Aneinandersetzen von
mehreren Teildokumentationen läßt sich zwar auch eine flexible
Struktur erreichen, jedoch ist dieser Weg zu aufwendig, um ihn
häufig zu nutzen.
Andererseits ist bei Rational Rose die Dokumentation bei der
Entwicklung stark im Hintergrund. Dies sieht man auch daran, daß
bei Rational Rose mit SoDA, im Gegensatz zu ObjectiF, ein
Zusatzprogramm benötigt wird. Bei ObjectiF sind schon die
Eingaben der Entwickler durch die Vorlagen besser strukturiert.
Indem die Vorlagen in einzelne Abschnitte unterteilt sind, ist
leichter sicherzustellen, daß alle notwendigen Informationen zu
den jeweiligen Objekten vorhanden sind. Außerdem erfolgt die
Bearbeitung dieser Informationen in Word, so daß die Eingabe
direkt formatiert erfolgt. Rational Rose stellt nur einen
einfachen Texteditor zur Verfügung, so daß die einzelnen Teile
in der Dokumentation nicht strukturiert werden können.
Beide Programme berücksichtigen, daß die Software
weiterentwickelt wird. Die Dokumentation muß entsprechend
angepaßt werden. Deshalb bieten beide Programme die
Möglichkeit, ein neue Dokumentation aus den neuen Informationen
zu generieren, ohne daß das Programm die zusätzliche Eingaben
löscht.
In-Step und In-Line von MicroTOOL sind Werkzeuge für das
Prozeßmanagement und für die Versionierung bei der
Softwareentwicklung. In-Step dient dem Prozeßmanagement und
unterstützt ein Vorgehen nach einem Prozeßmodel, so ist das
V-Modell und das objekt-orientierte Model zur
Anwendungsentwicklung nach der Unified Modeling Language in dem
Werkzeug integriert [MicroTOOL]. Andere Prozeßmodelle lassen
sich aber auch in dem Werkzeug integrieren.
Abbildung 16:
In-Step Aktivitäten [MicroTOOL]
Die Unterstützung der entsprechenden Prozeßmodelle liegt im
Festhalten aller Schritte des Prozeßmodells. In-Step führt die
Entwickler durch das Prozeßmodel (Abbildung 16) und alle
notwendigen Schritte werden ausgeführt und die entsprechenden
Dokumente erstellt. Dabei hält In-Step zu jedem Schritt den
Zustand fest. So kann ein bestimmter Schritt geplant sein, sich
in Bearbeitung befinden, durchgeführt oder abgeschlossen sein.
Durch diese Strukturierung ist auch jederzeit feststellbar, wie
weit das Projekt fortgeschritten ist und welche Schritte noch
ausgeführt werden müssen.
Für die Bearbeitung der einzelnen Teile ruft In-Step auch das
jeweilige Werkzeug auf. Momentan unterstützt In-Step
Die Schnittstellen von In-Step lassen sich aber auch an andere
Werkzeuge anpassen.
Die Daten speichert In-Step in einer relationalen Datenbank,
damit ein Bearbeiten mit mehreren Entwicklern einfach möglich
ist, da die Daten für alle Mitarbeiter zugreifbar vorliegen. So
können nach der Bearbeitung die Mitarbeiter der
Qualitätskontrolle direkt auf die zu überprüfenden Daten
zugreifen. Nach der Überprüfung können sie auch direkt die
Zustandskennung für das Dokument auf akzeptiert setzen und damit
das Dokument für die Folgeschritte freigeben.
In-Line baut ebenfalls auf eine relationale Datenbank auf und
dient der Versionsverwaltung. In-Line unterscheidet
Die Entwicklung der einzelnen Dateien wird in Versionen von
dieser Datei festgehalten. Die einzelnen Dateien können auch
unterschiedliche Varianten besitzen, damit die Entwicklung der
Software mit unterschiedlichen Varianten erfolgen kann (z.B.
Workstation-Version oder Server-Version). Denn die Unterschiede
zwischen den Varianten sind meist sehr klein, so daß der
größte Teil der Entwicklung gemeinsam erfolgen kann. Die
Speicherung der einzelnen Versionen und Varianten erfolgt immer
komplett. Es kommt keine Deltaspeicherung zur Anwendung, damit
der Zugriff auf die Daten schnell möglich ist. Außerdem kann so
In-Line schneller Konsistenzkriterien überprüfen. Allerdings
bietet MicroTOOL Komprimierungstools von anderen Herstellern an,
um die Datenmenge zu verringern.
Abbildung 17:
Konfigurationen in In-Step [MicroTOOL]
Die Konfigurationen, siehe Abbildung 17, dienen zum
Zusammenfassen der einzelnen Versionen der Dateien. Eine
Konfiguration besteht aus mehreren Dateien, wobei zu jeder Datei
die Versionsnummer festgelegt ist. Damit können die Dateien, die
zum Beispiel eine bestimmte Schnittstelle definieren,
zusammengefaßt werden. Einen neue Konfiguration wird bei der
Änderung der Schnittstelle erzeugt. Diese nimmt wieder die
gleichen Dateien auf. Für die Dateien, die für die neue
Schnittstelle verändert werden müssen, wird eine neue Version
angelegt. Die Entwickler können auch direkt die alten Versionen
übernehmen, wenn keine Veränderungen in einer Komponente
notwendig sind.