Problem

Die durch konventionelle Entwicklungsumgebungen generierten Dokumentationen enthalten keine Unterstützung zur Darstellung des Entwicklungsfortschritts.

Kontext

Um einen Software-Entwurf besser zu verstehen, kann es günstig sein, die Evolution eines Entwurfs nachzuvollziehen. Die Arbeit mit einer Entwicklungsumgebung gestaltet sich in der Regel so, daß der aktuelle Stand eines Entwurfs schrittweise verfeinert wird und die vorangegangenen Entwicklungsschritte dabei überschrieben werden. Mit einer Versionsverwaltung^* kann zwar jeder Zwischenstand gespeichert und auch wiederhergestellt werden, es bedarf aber einer Integration von Entwicklungsumgebung, Konfigurationsmanagement und Dokumentationsumgebung, um die Evolution jeder Komponente^* nachvollziehen zu können.

Kräfte

• Komplexität ß à Vollständigkeit der Dokumentation
• Einfache Bedienung und Übersichtlichkeit ß à Integration verschiedener Werkzeuge

Lösung

Zunächst muß ein Modell und ein Konzept zur Versionierung aller im Entwicklungsprozeß anfallenden Komponenten^* erstellt werden. Was die Modellierung von Komponenten^* der verschiedenen Abstraktionsebenen angeht, wurde in [Florijn et al., 1997] hier schon wesentliches geleistet und für uns wird die Arbeit in der Anpassung dieses Konzepts bestehen.

Die Realisierung im Rahmen der Dokumentationsumgebung wird aus der Erstellung eines Datenmodells bestehen. Hierfür bietet z.B. microtool mit objectiF [microtool, 1997] eine offene Schnittstelle, um auf das Datenmodell der SEU zugreifen zu können. Zur Versionierung wird ein Konfigurationsmanagementsystem (z.B. inStep [microtool, 1997] oder ClearCase [PureAtria, 1997]) eingesetzt werden oder die Versionierungskomponente einer Dokumentations-Entwicklungsumgebung (z.B. SchemaText [Schema, 1997] oder EDMS [Documentum, 1997]).

Bild 1: Versionsbaum und Abhängigkeitsgraph in einer Komponentenhierarchie

Der prinzipielle Zusammenhang zwischen dem Abhängigkeitsgraph^* der Komponenten^* und den verschiedenen Versionsbäumen^* jeder einzelnen Komponente ist exemplarisch in Bild 1 dargestellt. Komponenten sind als hervorgehobene graue Kreise dargestellt. Der Abhängigkeitsgraph ist gestrichelt ausgeführt, wenn die Abhängigkeit zwischen Komponenten verschiedener Ebenen besteht und durchgezogen, wenn die Abhängigkeit zwischen Komponenten einer Ebene besteht. Die Versionsbäume sind in den hervorgehobenen Rechtecken eingezeichnet.

Sei mit Kⁿ_i (n-Index der Ebene, i-Index der Version) eine Komponente bezeichnet. Zu einer Komponente gehört immer eine Menge von abhängigen Komponenten. Die Abhängigkeit soll unter der Sichtweise der Dokumentation informell gefaßt werden und bezieht sich auf der

• Systemebene^* und Musterebene^*: auf manuell zu spezifizierende Abhängigkeiten.
• Klassenebene^*: auf statische und dynamische Abhängigkeiten (Vererbung, Aggregation, Kenntnis). Diese Abhängigkeiten können eventuell auch auf der Musterebene ausgewertet werden, wenn dadurch verschiedene Musterausprägungen in Beziehung gebracht werden.
• Quellcode-Ebene^*: auf die Zugehörigkeit von Operationen zu bestimmten Klassen der überliegenden Ebene, auf die Änderung von Operationsschnittstellen und die Veränderung der Ausführungssemantik von Operationen. Letztere kann ggf. auch in Form von Pre- und Postconditions [Meyer, 1988] angegeben werden.

Die Veränderung einer Komponente wird durch den ihr zugeordneten Versionsbaum dargestellt. Eine Abhängigkeit zwischen zwei verschiedenen Komponenten K₁ⁿ_i und K₂^m_j kann durch die Veränderung einer der Komponenten (ià i+1 oder jà j+1) entstehen oder eine bestehende Abhängigkeit kann dadurch gelöst werden. Es existieren somit viele Abhängigkeitsgraphen, wobei zwischen primären und sekundären zu unterscheiden ist:

• ein Abhängigkeitsgraph wird als primär bezeichnet, wenn er zu einer Konfiguration^* gehört,
• sonst als sekundär.

Aus Sicht der Werkzeugunterstützung für die Dokumentation ist es wichtig, daß die komplexen Zusammenhänge zwischen den verschiedenen Graphen kompakt und übersichtlich dargestellt werden. Als Beispiel ist eine interaktive^* Unterstützung bei der Erzeugung der Kopie einer Komponente nötig: wie wird mit der Dokumentation der Komponente^* und mit den Referenzen auf die Dokumentationen der abhängigen Komponenten verfahren? (siehe Change Management). Weitere Probleme sind im Kontext mit der Darstellung der Dokumente und der Navigation^* in der Dokumentenstruktur zu lösen (siehe Navigation: Lost in Hyperspace).

Referenzen

Change Management, Benachrichtigung bei Änderungen, Navigation: Lost in Hyperspace