Ein Frontend ist die Schnittstelle zwischen Benutzer und der Software, es soll den Umgang mit dem Programm vereinfachen und unterstützen. Daher ist es wichtig für ein Frontend, wie es Aufgebaut ist und wie es den Benutzer durch einzelne Bearbeitungsschritte begleitet. Demnach ist das Design eines Frontends sehr wichtig für die Benutzerfreundlichkeit. Ein mit Funktionen überfrachtetes Frontend ist genau so problematisch wie ein Forntend mit zu wenig Funktionalität. Der Benutzer bzw. Autor ist auf ein gutes Frontend angewiesen.
1.3 Autorenfrontend für der Softwaredokumentation
Ein Autorenfrontend für die Softwaredokumentation soll es dem einzelnen Autoren einfacher machen die von ihm zu erstellenden Dokumente Modell- und Normgerecht zu gestalten. Es soll weiterhin die Möglichkeit bieten einen Überblick über die aktuelle Dokumentation und die anderer Projekte zu erhalten. Daher ist es wichtig, daß das Frontend folgende Eigenschaften besitzt:
(Etwas genauer werde ich auf diese Punkte im Kapitel 2 eingehen.)
Die Basis eines solchen Frontends besteht aus einem gutem Textverarbeitungsprogramm, wie z.B. Word, welches auch die Möglichkeit der Erweiterung und der Grafikeinbindung hat. Diese Basis und das Anfügen der Entsprechenden Funktionalität, erleichtern dem Autoren das Verfassen von Dokumenten bzw. Teildokumenten.
Die geeignete Führung des Autoren durch das Frontend, darf hierbei allerdings nicht vernachlässigt werden.
1.4 Welche Aufgaben hat ein Autor bei der Softwaredokumentation?
Die Entwickler von Software arbeiten meist in Teams um die Aufgabe der Programmentwicklung in den Griff zu bekommen. Daher ist der Entwickler eines bestimmten Teils der Software auch für deren Dokumentation zuständig.
Der Autor ist meist an Vorgehensmodellen und Normen gebunden, diese muß er bei der Dokumentation berücksichtigen. Diese Aufteilung hat zur Folge, daß die Dokumentation in viele kleine Dokumente zerfällt und später wieder zusammengefaßt wird. Einige Vorgehensmodelle und Normen unterstützen diese Arbeitsweise indem sie durch das Zusammenfassen kleinerer Dokumenten (z.B. Arbeitspapiere) ein größeres Dokument (z.B. Gruppendokument) verfassen. Somit hat der einzelne Autor zwar mehr Arbeit, aber jeder Entwicklungsschritt ist Nachvollziehbar.
1.5 Wie unterstützen heutzutage die Werkzeuge den Autoren bei der Softwaredokumentation?
Bei der Entwicklung von Programmen unterstützen heute meist Werkzeuge den Entwickler bei seiner Arbeit. CASE
ä , Rational Roseä , ObjectiFä , SoDAä und einige andere dieser Tools sind bei der Entwicklung nicht mehr wegzudenken. Die Autoren einer Softwaredokumentation können davon profitieren, indem sie die erstellten Diagramme übernehmen und noch Erläuterungen dazu schreiben. Die Aufgabe der Erläuterung versuchen heute auch schon einige Tools oder Programmerweiterungen zu übernehmen. Solche Programme wie SoDAä oder ObjectiFä können dieses allerdings nur abschnitte eines Dokumentes liefern können.Ein weiteres Problem ist die Verwaltung der einzelnen Dokumente, die in einem Projekt anfallen. Diese Verwaltungsaufgabe versuchen die Tools Step-In
ä und In-Lineä zu bewerkstelligen. Im weiteren werde ich einige dieser Tools vorstellen .1.5.1 Software Documentation Automation SoDA
ä"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
• Klassendiagramme
• Szenario- Diagramme
• Klassenbeschreibungen
• Beschreibungen von Methoden
• Beschreibungen von Attributen
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 Word-Dokument.
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
•OPEN
•DISPLAY
•REPEAT
•LIMIT
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." [Blachnik97]
ä
"Bei ObjectiF von MicroTOOL handelt es sich auch um eine Entwicklungsumgebung für objektorientierte 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." [Blachnik97]
1.5.3 Vergleich zwischen ObjectiF
ä und SoDAä"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." [Blachnik97]
"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
• ObjectiF (Entwicklungswerkzeug von MicroTOOL für die objekt-orientierte Softwareentwicklung),
• case 4.0 (Entwicklungswerkzeug von MicroTOOL für die strukturierte Softwareentwicklung),
• Word (von Microsoft für Texte innerhalb des Prozeßmodells).
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
•Versionen
•Varianten und
•Konfigurationen.
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." [Blachnik97]