Thema

"Objektorientierte Konzepte in der Softwaredokumentation"

Autor: Marcus Budzyn , Studiengang Technische Informatik

im Rahmen des Oberseminars SoDoM (Softwaredokumentation mit Mustern)

betreut von Dr.-Ing. Klaus Quibeldey-Cirkel und Dipl.-Ing. Georg Odenthal

an der Universität/GH Siegen im Juli 1998

Einleitung

Während in der Programmierung von Softwaresystemen objektorientierte Konzepte akzeptiert und weit verbreitet sind, wird in der Dokumentation von Software dieses Konzept bisher weitgehend ignoriert. Es bietet sich aber eine Anwendung objektorientierter Konzepte auf die (System-) Softwaredokumentation an, was im folgenden gezeigt werden soll.

Man unterscheidet grundlegend zwischen Benutzer-, System- und Projektdokumentation (IEEE 1983, Pomberger 1986). Im folgenden soll nur auf die Systemdokumentation, die Schnittstellendefinitionen und Implementierungsdetails beschreibt, eingegangen werden. (Systemdokumentation ist für Programmierer gedacht ist, die Softwarekomponenten wiederverwenden oder warten müssen)

Nach der einfachen Einführung in die "Terminologie Objektorientierte Systeme" folgt ein Übergang auf die Softwaredokumentation. Es soll gezeigt werden, daß die Übertragung des Konzepts auf die Softwaredokumention ("Anwendung Objektorientierter Konzepte auf Softwaredokumentation") möglich ist.

Der Leser soll erkennen, daß damit eine für den Verfasser der Softwaredokumentation einfache und sehr leistungsfähige Methode zur Erstellung solcher Dokumente geschaffen wird.

Anschließend folgt die Betrachtung der "Wiederverwendbarkeit von Softwaredokumentation", d.h. bereits erstellter Dokumentation bzw. Teile dieser Dokumentation. Ein wichtiges Kriterium für die Verwendung einer neuen Methode (in diesem Fall das Paradigma der Objektorientierung) ist die Verfügbarkeit von Werkzeugen, welche diese Methode unterstützen. Im Kapitel "Ein Werkzeug zur objektorientierten Softwaredokumentation" wird das Werkzeug "DOgMA" vorgestellt, welches dieses Konzept verwirklicht.

Jedes Konzept besitzt Schwächen und Stärken; Diese sollen im Kapitel "Bewertung" aufgezeigt werden.

Abschließend werden verwendete Quellen in "Literatur und Links" aufgeführt und es ist möglich die zum Vortrag gehörende "Powerpoint-Präsentation" herunterzuladen. .

Terminologie Objektorientierter Systeme

Für den Leser, welcher mit den Konzepten objektorientierter Systeme und den dazugehörenden Begriffen nicht vertraut ist, sollen hier die grundlegenden Begriffe erläutert werden. (Als weiterführende Literatur sei empfohlen: [Stroustrup, 91], [Booch, 97] )

Eine allgemeine Definition objektorientierter Programmierung nach Grady Booch lautet:

"Objektorientierte Programmierung ist eine Implementierungsmethode, bei der Programme als kooperierende Ansammlungen von Objekten angeordnet sind. Jedes dieser Objekte stellt eine Instanz einer Klasse dar, und alle Klassen sind Elemente einer Klassenhierarchie, die durch Vererbungsbeziehungen gekennzeichnet ist."

Es sollen hier die wichtigen Begriffe "Objekt", "Klasse", "Vererbung", "Klassenbibliotheken/Anwendungsrahmen" und "Zugriffsmechanismen" kurz erläutert werden.

Das Objekt:

Ein objektorientiertes Softwaresystem besteht in der Ausführung aus (verschiedenen) Objekten. Ein solches Objekt hat Struktur und Verhalten.

Bsp.: Rechteck:

Struktur: Höhe, Breite, Sichtbar, x-Position, y-Position

Verhalten: Zeichne, Lösche, Drehe, Verschiebe

Ein Objekt wird durch Ausführung einer seiner Methoden aktiviert. Im Beispiel Rechteck wird die Methode "Verschiebe" unter Angabe neuer Koordinaten das Rechteck an eine andere Koordinate verschieben. Dabei wird der Zustand des Objekts verändert, weil x-Position und y-Position auf die neuen Werte gesetzt werden.

Es ist auch möglich, daß ein Objekt andere Objekte über seinen Zustand informiert bzw. andere Objekte zur Ausführung von Methoden auffordert. So ist komplexe Interaktion zwischen Objekten möglich.

Ein Beispiel für ein solches, objektorientiertes Softwaresystem ist z.B. eine (objektorientierte) CAD Anwendung:

Die auf dem Bildschirm dargestellten geometrischen Objekte werden als Objekte mit Verhalten und Struktur im Programm verwaltet. Verschiebt der Benutzer des Programms ein Objekt, so wird dies dem Objekt mitgeteilt ("Verschiebe"). Das verschobene Objekt kann mit anderen Objekten "verhandeln", auf welcher Ebene das Objekt zu zeichnen ist (Im Vordergrund, im Hintergrund oder einer Ebene dazwischen) und sich dann entsprechend neuzeichnen.

Die uns umgebende Wirklichkeit ist auch eine Ansammlung solcher Objekte. So hat ein Hund z.B. eine Struktur (Rasse, Geschlecht, Größe, Fellfarbe, Alter usw.) und Verhalten (Fressen, Bellen, "Hole Stöckchen", Verjage Briefträger). Diese Aufteilung in Objekte ist also ein sehr natürlicher (intuitiver) Vorgang.

Die Klasse:

Der Quellcode eines objektorientierten Softwaresystems besteht aus Klassen. Eine Klasse definiert dann die Struktur (Variablen) und das Verhalten (Methoden). Objekte mit gleichem Verhalten und gleicher Struktur sind in einer Klasse beschrieben.

Bsp. der Klasse Rechteck implementiert in der Programmiersprache C++ :

class Rechteck {

private: // definiert Sichtbarkeit der Variablen,
// private = nicht öffentlich

// Variablen (beschreiben Struktur)

BOOL m_Sichtbar; // TRUE: Rechteck ist auf dem Bildschirm sichtbar

int m_xPosition; // x-Koordinate der aktuellen Position des Rechtecks

int m_yPosition; // y-Koordinate der aktuellen Position des Rechtecks

int m_Winkel; // Bereich: 0..359, Winkel in dem das Rechteck
// dargestellt wird

public: // definiert Sichtbarkeit der Methoden
// public = öffentlich

// Methoden (beschreiben Verhalten)

void Zeichne(){

// Anweisungen, um das Rechteck auf dem Bildschirm anzuzeigen

// z.B. die entsprechende Fkt. der Grafikbibliothek benutzen

// ...

m_Sichtbar=TRUE;

}

void Loesche(){

// Anweisungen, um das Rechteck vom Bildschirm zu löschen

// z.B. die entsprechende Fkt. der Grafikbibliothek benutzen

// ...

m_Sichtbar=FALSE;

}

void Verschiebe(int x_Pos, int y_Pos){

// Zuerst Rechteck vom Bildschirm löschen

Loesche();

// Neue Position des Rechtecks abspeichern

m_xPosition = x_Pos;

m_yPosition = y_Pos;

// Soll das Rechteck sichtbar sein???

if (m_Sichtbar)

Zeichne(); // Ja...dann zeichne es

}

void Drehe(int neuerWinkel){

// Zuerst Rechteck vom Bildschirm löschen

Loesche();

// Neuen Winkel des Rechtecks abspeichern

m_Winkel = neuerWinkel;

// Soll das Rechteck sichtbar sein???

if (m_Sichtbar)

Zeichne(); // Ja...dann zeichne es

}

};

(Für weiterführende Informationen zur objektorientierten Programmierung in C++ wird [Stroustrup,91] empfohlen.)

Bisher besteht kein Unterschied zu einer prozeduralen Programmierung, wo (inhaltlich) zusammenhängende Prozeduren zu einem Modul zusammengefaßt werden. Der Unterschied der objektorientierten Programmierung zur konventionellen, prozeduralen Programmierung wird in den folgenden Punkten deutlich.

Die Vererbung:

Vererbung beschreibt die Beziehung zwischen Klassen. Eine Klasse A kann Verhalten und Struktur von einer anderen Klasse "erben" und zusätzlich Verhalten und Struktur hinzufügen.

Auf der semantischen Ebene stellt die Vererbung eine "is a" Beziehung dar.

Beispiel: Die Klasse "Rechteck" könnte von einer Klasse "Form" abgeleitet sein, welche grundsätzliches Verhalten und Struktur graphischer Objekte definiert und implementiert.

Die "is a" Beziehung bedeutet: Jedes "Rechteck" ist eine "Form", d.h. eine Spezialisierung von "Form".

Die Klasse "Rechteck" wird in diesem Fall "abgeleitete Klasse" oder "Subklasse" (von "Form") genannt, "Form" ist die Basisklasse oder Superklasse (von "Rechteck").

"Form" definiert und implementiert dann grundlegendes Verhalten und Struktur für graphische Objekte, z.B. die Variablen für die Position des Objektes und die Sichtbarkeit des Objektes.

Auch (grundlegendes) Verhalten kann in den Methoden einer Superklasse implementiert sein, z.B. eine "Zeichne" Methode. Ist die Implementierung dieser "Zeichne" Methode für die abgeleitete Klasse zufriedenstellend, muß "Zeichne" in der abgeleiteten Klasse nicht mehr implementiert werden (d.h. die Subklasse definiert nur noch die Erweiterungen der Superklasse).

Ist hingegen eine eigene, spezielle Behandlung der Methode "Zeichne" erwünscht, kann diese in der abgeleiteten Klasse überschrieben werden und damit mit eigener "Logik" versehen werden. Damit wird nicht mehr die "Zeichne" Methode der Superklasse "Form" benutzt, sondern die eigene (der Klasse "Rechteck") Implementation.

Klassenbibliotheken / Anwendungsrahmen:

Eine Sammlung von Klassen, welche ein Programmierer als Grundlage für eigene Klassen verwenden kann, wird Klassenbibliothek genannt. Diese Klassen sind für einfache Wiederverwendbarkeit entworfen, so daß eigene gewünschte Funktionalität einfach hinzugefügt werden kann. Beispiele für solche Klassenbibliotheken/Anwendungsrahmen sind die MFC Bibliothek der Firma Microsoft und die VCL Bibliothek der Firma Borland.

Klassenbibliotheken, die ein Grundgerüst für Anwendungen bilden, werden Anwendungsrahmen genannt. In einem Anwendungsrahmen wird das Grundgerüst der Anwendung erzeugt (Heutzutage meist graphische Benutzeroberflächen mit Fenstern, Toolbars, Menüs), das der Programmierer in einfacher Weise seinen Anforderungen anpassen kann (Bsp. MFC, Microsoft Foundation Classes der Firma Microsoft)

Zugriffsmechanismen:

Ein Client (der Klasse A) ist eine Klasse, welche die Klasse A "benutzt" (eine Instanz dieser Klasse anlegt). Eine "friend" Beziehung von Klassen ist möglich, wenn Klassen sehr "verwebt" sind, eine Trennung in mehrere Klassen dennoch sinnvoll erscheint.

[Stroustrup 91] definiert die folgenden Zugriffsbeschränkungen:

*Zugriffsart*	*Klasse A*	*Friend von A*	*abgel. Klasse von A*	*Client, der A verwendet*
*private*	Zugriff erlaubt	Zugriff erlaubt	Kein Zugriff	Kein Zugriff
*protected*	Zugriff erlaubt	Zugriff erlaubt	Zugriff erlaubt	Kein Zugriff
*public*	Zugriff erlaubt	Zugriff erlaubt	Zugriff erlaubt	Zugriff erlaubt

Anwendung Objektorientierter Konzepte auf Softwaredokumentation

Wie im vorhergehenden Kapitel gezeigt wurde, wird ein objektorientiertes System nicht "aus dem Nichts" erschaffen, sondern es ist eine Erweiterung und Veränderung bestehender Klassen (einer Klassenbibliothek/Anwendungsrahmen). Das gleiche sollte auch für objektorientierte Softwaredokumentation gelten – eine Beschreibung der Veränderungen und Erweiterungen der "Basisdokumentation" der verwendeten Klassen.

Die Anforderungen an die Dokumentation sind unterschiedlich bei den verschiedenen Benutzergruppen der Klassenbibliothek bzw. des Anwendungsrahmens.

Soll eine Wartung der Bibliothek stattfinden, müssen alle Details der Implementierung bekannt sein. Möchte eine Programmierer aber nur eine Klasse wiederverwenden, so ist für ihn eher das Black-Box Verhalten interessant und nicht die Implementierungsdetails.

Eine humoristische Darstellung dieser verborgenen Komplexität findet sich in [Booch, 97]

cat.TIF (23130 Byte)

Als anderes Beispiel soll eine Klasse für die Verwaltung eines Arrays dienen:

Der für die Wartung zuständige Programmierer möchte sicherlich wissen, ob das Array intern mit Zeigern realisiert ist, und in welcher Weise Zugriff, Speicherung und Freigabe der einzelnen Elemente erfolgen. Der diese Klasse wiederverwendende Programmierer möchte aber nur wissen, wie man Elemente ein- und ausliest (In wenigen Ausnahmefällen wird er sich für Implementierungsdetails interessieren, z.B. wenn es um Performancebetrachtungen und Abschätzung des verwendeten Speicherplatzes geht).

Im folgenden soll eine Übersicht gegeben werden, welcher Benutzergruppe welche Dokumentationsteile zur Verfügung stehen.

	*Übersicht (Wartung + Wiederbenutzer)*	*Externe Ansicht (Wartung + Wiederbenutzer)*	*interne Ansicht (Wartung)*
*statisch*	Übersicht	Beschreibung Klasseninterface	Beschreibung Klassenimplementation
*dynamisch*	Übersicht	Beschreibung Jobinterface	Beschreibung Jobimplementation

Die Einteilung in statisch/dynamisch gibt eine Trennung der Dokumentation in dynamisches Verhalten (Reaktion auf "Events", Flußkontrolle, Prozeßkommunikation usw.) und statische Aspekte (unterstützte Plattformen, Hardwareanforderungen, welche Methoden hat die Klasse usw.) wieder.

Zu beachten ist die von links nach rechts zunehmende Komplexität. Während die allgemeine Übersicht nur einen ersten Überblick über die Klasse geben soll, so enthüllt die interne Ansicht ganz rechts alle Interna der Klasse (und ist damit auch umfangreicher).

Im folgenden werden alle sechs Dokumentationsteile ausführlich beschrieben.

Statische Übersicht:

In der statischen Übersicht werden allgemeine Informationen zur Implementation gegeben. Dazu gehören unterstützte Plattformen, Hardwareanforderungen, die verwendeten Programmiersprachen, Bibliotheken, verwendete Klassen/Komponenten, Klassenhierarchie und eine Kurzbeschreibung der verwendeten Klassen.

Dynamische Übersicht:

In der dynamischen Übersicht wird das allgemeine Verhalten zur Laufzeit betrachtet. Dazu gehören Informationen über die Weiterleitung von Nachrichten, Prozeßkommunikation, Kommunikation mit anderen Anwendungen/Komponenten usw.

Beschreibung Klasseninterface:

Hier werden die Fähigkeiten der Klasse illustriert. Die Fragen "Welche Methoden gibt es? Wie sind die Methoden zu benutzen?" werden dabei beantwortet.

Diese Beschreibung gibt dem Wiederbenutzer wichtige Informationen, wie er diese Klasse effizient einsetzen kann und dem Wartungsprogrammierer wird bei der Erweiterung der Klasse die bereits implementierte Funktionalität dargestellt.

Beschreibung Jobinterface:

Klassenbibliotheken und Anwendungsrahmen bestehen üblicherweise aus mehr als hundert Klassen und mehr als tausend Methoden, so daß es sehr schwierig ist einen Überblick zu bekommen, welche Klassen in welcher Art eingesetzt werden müssen um ein bestimmtes "Ziel" zu erreichen.

Häufig gestellte Fragen lauten z.B. "Welche Klassen brauche ich als Grundgerüst für meine Applikation, wie muß ich diese Klassen miteinander in Beziehung setzen, welche Methoden muß ich überschreiben, welche Nachrichten muß ich bearbeiten, wann muß ich welche Nachricht schicken".

In dieser Beschreibung werden im Idealfall konkrete Beispiele gegeben, z.B. der Aufbau eines einfachen Programmes mit der Klassenbibliothek, um eine elementare Einsicht des Wirkungskreises und des Aufgabenkreises der einzelnen Klasse bzw. einer Gruppe von Klassen zu bekommen.

Vergleichbar ist dies vielleicht mit der Aufgabe verschiedener Institutionen in einer Gesellschaft. Man gewinnt wenig Einsicht, wenn man die Funktion einzelnen Behörden und Institutionen isoliert beschreibt. Erst wenn man die Wechselwirkungen zwischen diesen Behörden beschreibt und anhand von konkreten darstellt (z.B. ein neues Gesetz wird verabschiedet), wird der Zusammenhang klar.

So ist es in dieser Beschreibung sinnvoller, z.B. das Zusammenwirken der einzelnen Klassen in einem Grafikeditor zu beschreiben als isoliert die Klassen "Menü", "Toolbar" und "Fenster" zu beschreiben.

Beschreibung Klassenimplementation:

In dieser Beschreibung wird die interne Struktur und Konzeption einer Klasse dargestellt. Diese Darstellung muß so genaut erfolgen, daß selbst nicht an dem Entwurf/Implementation beteiligte Wartungsprogrammierer diese Klasse warten und erweitern können. Eine Beschreibung der Struktur der Klasse, der verwendeten Komponenten/Klassen (und deren Aufgabe) und aller Methoden und Variablen (und deren Aufgabe) ist zu diesem Zweck erforderlich.

Werden in der Klasse nicht-triviale Algorithmen verwendet, so sind diese ebenfalls detailliert zu beschreiben. Angaben zu Speicherplatz- und Laufzeitverhalten der verwendeten Algorithmen sowie gegebenenfalls bestehende Einschränkungen der Eingabewerte können die Arbeit des Wartungsprogrammierers erleichtern und sollten ebenfalls vorhanden sein.

Insgesamt kann die Beschreibung der Klassenimplementation als Erweiterung der Beschreibung des Klasseninterfaces gesehen werden.

Beschreibung Jobimplementation:

In dieser Beschreibung werden interne Abläufe detailliert dargestellt. Die hier beantworteten Fragen sind "Wie wird eine bestimmte Aufgabe bewältigt? Welche Klassen sind daran in welcher Weise beteiligt?" Auch diese Dokumentationsabschnitte sind nur dem Wartungsprogrammierer zugänglich.

Wiederverwendbarkeit von Softwaredokumentation

Besonders die Dokumentationsabschnitte "Beschreibung des Klasseninterfaces" und "Beschreibung der Klassenimplementation" sind für eine Wiederbenutzung geeignet, so daß im folgenden nur auf diese beiden Dokumentationsabschnitte eingegangen wird.

Um den Nutzeffekt der Objektorientierung zu erhöhen ist es sinnvoll, die Dokumentation in Abschnitte zu unterteilen. Ein solcher Abschnitt besteht aus einem Textblock mit einem Tite.

Hier der Abschnitt für die Klasse Rechteck

"Titel: Kurzbeschreibung

Diese Klasse verwaltet ein graphisches Objekt in Form eines Rechtecks.

Diese Objekt kann gezeichnet, gelöscht und verschoben werden. Außerdem kann es rotiert werden".

Abschnitte können durch den Programmierer (nach eigenem Ermessen) definiert werden und Vererbung kann auf sie genauso angewendet werden wie auf Methoden in der objektorientierten Programmierung.

Wie auch in der Programmierung kann ein solcher Abschnitt entweder

	unverändert,
	entfernt,
	ersetzt oder
	erweitert

werden.

Eine Gegenüberstellung von Softwareentwicklung und Dokumentation stellt die Gemeinsamkeiten heraus:

Softwarentwicklung

Rechteck	nein	ja	ja	nein
Form	nein	ja	ja	ja
Objekt	ja	ja	nein	nein
Methoden	Vergleiche	Drucke	Zeichne	Bewege

"Ja" bedeutet, daß diese Methode in dieser Klasse implementiert wurde und damit die Implementation (falls vorhanden) der Superklasse überschrieben wurde.

"Nein" bedeutet, daß diese Methode nicht in dieser Klasse implementiert wurde.

Dokumentation

Rechteck	ja	nein	nein	ja
Form	ja	ja	nein	nein
Objekt	ja	ja	ja	ja
Abschnitte	Kurzbeschreibung	Voraussetzungen für die Benutzung	Speichern in Dateien	Wartungsinformationen

"Ja" bedeutet, daß dieser Dokumentationsabschnitt in dieser Klasse geschrieben wurde und damit der Abschnitt (falls vorhanden) der Superklasse überschrieben wurde.

"Nein" bedeutet, daß dieser Dokumentationsabschnitt nicht in dieser Klasse geschrieben wurde.

Auch die gezeigten Zugriffsbeschränkungen public, protected und private sind auf Abschnitte der Dokumentation anwendbar. Hierbei haben die Schlüsselwörter folgende Bedeutung:

public	Diese Abschnitte können von jedem gelesen werden. Sie beschreiben, wie die Klasse zu benutzen ist
protected	Diese Abschnitte bieten zusätzliche Informationen, die benötigt wird, um Subklassen abzuleiten (für Wiederbenutzer und Wartung)
private	Diese Abschnitte stellen zusätzlich Implementierungsdetails zur Verfügung und sind daher exklusiv für Entwicklung/Wartung vorbehalten

Das heißt für die oben gezeigte. Dokumentation:

	public = öffentlich		protected	private
Rechteck	ja	nein	nein	ja
Form	ja	ja	nein	nein
Objekt	ja	ja	ja	ja
Abschnitte	Kurzbeschreibung	Voraussetzungen für die Benutzung	Speichern in Dateien	Wartungsinformationen

"Kurzbeschreibung" und "Vorausbedingungen für die Nutzung" sind für jeden sichtbar (=public), "Speichern in Dateien" ist als protected deklariert, d.h. diese Informationen sind für Programmierer sichtbar, die eine Subklasse ableiten und daher mehr Informationen benötigen.

Die Abschnitte für Entwicklungs-/Wartungsprogrammierer sind als private deklariert. Zu beachten ist, daß auch hier der Entwickler der Klasse "Rechteck" nicht die Abschnitte der Superklassen einsehen kann (Gekennzeichnet durch die horizontale Linie). Nur ein Entwickler (bzw. das Personal, welches Zugriff auf diese Klasse hat) hat Zugriff auf diese Dokumentationsabschnitte.

Ein Werkzeug zur objektorientierten Softwaredokumentation – "DoGMA"

Das Programm DoGMA [Sametinger, 94] realisiert die im vorherigen Kapitel aufgezeigt Methode der objektorientierten Softwaredokumentation.

Benutzerschnittstelle des Werkzeugs DOgMA

Im linken oberen Fenster wird eine Kurzinformation der Klasse gezeigt. Es wird der Name der Klasse, eine Kurzbeschreibung, der Name der Textdatei und die Vererbungshierarchie angezeigt.

Im Fenster "Editable classes" werden alle dem Projekt dazugehörenden Klassen aufgeführt. Die zu dieser Klasse gehörenden Methoden sind in der Listbox "Methods for clients" aufgeführt. Wird in einer dieser Listboxen ein Eintrag ausgewählt, so zeigt die darunterliegende Listbox "Documentation for clients" alle für diese Klasse bzw. Methode verfügbaren Dokumentationsabschnitte an. Wählt der Benutzer hier einen Dokumentationsabschnitt aus, so wird im linken, unteren Fenster der entsprechende Textabschnitt angezeigt.

In diesem Beispiel ein Abschnitt aus "Document", einer Superklasse von "Hyperproject", die Superklasse von "DProject" ist.

Es kann eingestellt werden, welcher Benutzergruppe man angehört: Clients, Heirs oder friends (entsprechend public, protected und private).

Dementsprechend werden die für diese Benutzergruppe verfügbaren Klassen und Methoden und damit auch die Dokumentationsabschnitte angezeigt.

Durch diese hierarchische Struktur und die direkte Umsetzung des Konzeptes der Anwendung objektorientierter Konzepte auf die Softwaredokumentation ist ein sehr schneller Zugriff auf relevante Dokumentationsabschnitte möglich. Außerdem erntfällt das sonst übliche "Kopieren von Abschnitten" bei der Erstellung von Dokumentation, da nicht neugeschriebene Abschnitte vererbt werden.

Bewertung

Objektorientierte Konzepte in der Softwaredokumentation bieten viele gute Ansätze. Für eine Verbreitung dieses Konzepts sind aber neben der Eignung auch weitere Kriterien zu erfüllen. Um objektorientierte Softwaredokumentation zu erstellen, muß man passende Werkzeuge haben. Dieses muß auf vielen Rechnerplattformen erhältlich sein und ausgereiftes, sicheres Arbeiten ermöglichen. Außerdem sollte es im besten Fall mehrere dieser Werkzeuge (von verschiedenen Herstellern) geben, und die von diesen Werkzeugen erzeugte Dokumente sollten untereinander austauschbar sein. Dazu ist es nötig, objektorientierte Softwaredokumentation zu standardisieren, um verschiedene Hersteller zu ermutigen, sich diesem Standard anzuschließen.

Ein weiterer Punkt ist die Akzeptanz bei den Programmierern, die mit diesen Werkzeugen arbeiten sollen. Ist das Produkt einfach bedienbar? Ist das dahinterstehende Konzept einfach verständlich? Wie schnell ist eine Umstellung von der "klassischen Softwaredokumentation" möglich? Welche finanziellen Belastungen kommt auf die Firma zu (Schulungen, Werkzeuge)? Bedeutet objektorientierte Softwaredokumentation eine Mehrarbeit? Ist eine "klassische Softwaredokumentation" nicht doch vollkommen genügend?

Viele dieser Fragen lassen sich sicherlich erst nach Praxiserfahrungen mit solchen Dokumentationswerkzeugen beantworten.