FRANKFURT (uk) - Die Dokumentation eines Softwaresystems müsse bereits mit dem ersten Entwurf begonnen und beide müßten in Anhängigkeit voneinander weiterentwickelt werden, forderte der amerikanische Professor Nico Habermann kürzlich anläßlich "Strukto 77", dem Control Data-Kongreß für Software-Systementwicklung. Nicht nur eine Systembeschreibung - so Habermann in Frankfurt - solle die Dokumentation darstellen, sondern auch t die Zusammenarbeit der Programmierer an einem Projekt erleichtern. Erreichen ließen sieh diese Ziele seiner Meinung nach mit einem dynamischen Dokumentationssystem, das allgemeine Regeln für die Systemmodifizierung festlegt und eine automatisierte Änderungsgeschichte erzeugt.

Die wichtigsten Passagen des Habermann-Referats drucken wir im folgenden mit freundlicher Genehmigung des Control Data Instituts nach:

Ein modernes Softwaresystem soll flexibel sein. Das heißt, es soll gleich so entworfen und konstruiert werden daß einzelne Teile noch leicht geändert werden können. Begründung dafür sind:

- das Versagen der "debugging philosophy"

Vor zehn Jahren war der allgemeine Gedanke, daß ein System einmalig konzipiert und konstruiert wird. Falls Fehler auftauchten, würde der Einsatz von einigen Mann-Stunden ausreichen, um die Programme zu korrigieren. Es kam jedoch heraus, daß der Aufwand sehr viel größer war als man geschätzt hatte, daß manche Fehler nicht korrigiert werden konnten ohne weitgreifende Änderungen im System durchzuführen, und daß es schwierig ist, den Entwurf aus dem Code zu rekonstruieren.

- die häufig geringe Leistung von allgemein gehaltenen Systemen

Wenn ein einheitliches System für mehrere verschiedene Anwendungen entworfen wird, ist es unvermeidlich, d aß die Leistungsfähigkeit darunter leidet. Hersteller von Hardware haben uns mit der Idee das richtige Beispiel gegeben, nicht nur ein einziges Modell einer Rechenanlage herzustellen, sondern eine "Serie" oder "Familie" (zum Beispiel die 370 Serie oder PDP11 Familie).

- die notwendige Anpassung und Ergänzung

Die Benutzer werden allmählich vernünftiger in der Art und Weise, wie sie ihre Anlagen ausnutzen. Das bringt mit sich, daß die Benutzer mit immer besseren, ihren Bedürfnissen entsprechenden Systemen bedient werden. Außerdem wird ständig bessere und/oder billigere Hardware hergestellt. Ein System soll flexibel genug sein, um solche Verbesserungen ausnutzen zu können.

Die Herstellung flexibler Software wird ermöglicht durch

1. einen modularen Systementwurf;

2. Systematische Dokumentation

Modularer Systementwurf ist eine notwendige, aber nicht ausreichende Bedingung für die Produktion flexibler Software. Daneben ist systematische Dokumentation notwendig, um ein System überhaupt verständlich und modifizierbar zu machen. Das Hauptziel der Dokumentation ist deshalb:

- es dem Programmierer zu ermöglichen, einzelne Systemmodule verstehen und analysieren zu können.

Für größere Systeme reicht es nicht die Programme selbst als Dokumentation zu verwenden. Ein Programm legt genau fest, was gemacht wird, aber nicht, welche Ideen dahinter stecken und warum eine bestimmte Implementierung gewählt worden ist. Es ist nicht so schwierig, für einen gegebenen Algorithmus ein Programm zu schreiben, umgekehrt aber sehr. Programme sind in diesem Sinne "write only". Ein Hauptziel der Dokumentation ist es, den Weg festzulegen, der von der Idee über den Entwurf zum Programm leitet, und ihn verständlich zu machen.

- es dem Programmierer zu ermöglichen, einzelne Systemmodule zu modifizieren und aus modifizierten Versionen und schon existierenden anderen Modulen richtige Systemversionen erzeugen zu können.

Obwohl das statische Ziel, die Darstellung einer verständlichen Systembeschreibung, wohl allgemein anerkannt ist, wird die wichtige Rolle der Dokumentation mit Bezug auf Systemmodifikationen im allgemeinen stark unterschätzt. Ich plädiere dafür, die Dokumentation nicht nur auf eine statische Beschreibung zu beschränken, sondern auch Systemmodifikationen (womöglich automatisch) zu demonstrieren, damit jeder beteiligte Programmierer ein klares Bild hat, welche Systemversion vorhanden und welche Modifikationen durchgeführt worden sind. Eine gute dynamische Dokumentation kann als ein wichtiges Systementwicklungs-Hilfsmittel verwendet werden.

Modulare Struktur einer "guten" Dokumentation

Obwohl eine Beschreibung, die einen Überblick über ein Gesamtsystem darstellt, nützlich sein kann, ist das Gesamtsystem eine zu große Einheit für eine detaillierte Beschreibung. Eine modulare Dokumentation ist mehr geeignet, und zwar eine Dokumentation, die mit der modularen Struktur des Systems verknüpft ist. Der Grund dafür ist, daß die Programme innerhalb eines Moduls viel stärker zusammenhängen als die in unterschiedlichen Modulen.

Die elementaren Teile eines Dokumentationsmoduls sind Files (Dateien). Die Files, die die relevante Information eines Moduls enthalten, nennen wir "Basicfiles". Die Standard Basicfiles geben einem Programmierer Zugang zu einem Modul. Die Information, die in diesen Files enthalten ist, erfüllt drei Zwecke:

- das Modul zu beschreiben und zu erklären;

- die Modifikationsgeschichte aufzubewahren;

- die Wirkung eines Moduls ausprobieren zu können.

Diese Zwecke werden realisiert durch drei Standardfiles, die man in jedem Dokumentationsmodul findet: eine "Textfile", eine "Logfile" und eine "Testfile". Die Anzahl der Standardfiles ist nicht beliebig, sondern für jedes Modul festgelegt und genau gleich. Obwohl der Inhalt der Textfiles in verschiedenen Modulen nicht derselbe ist, ist die Funktion dieser Files die gleiche, das heißt, eine Erklärung und Beschreibung des Moduls zu geben. Genauso ist die Funktion der Logfile in allen Modulen die gleiche, wie auch die Funktion der Testfile.

Die Logfile enthält eine Liste von kurzen Meldungen, die angeben, welche Änderungen in einem Modul angebracht worden sind. Die Meldungen sind nach Datum geordnet.

Dynamische Dokumentation mit Workingfiles

Wir betrachten die Dokumentation nicht nur als eine statische Beschreibung, sondern vielmehr als ein aktives Hilfsmittel, das in der Systementwicklung und Wartung eingesetzt wird. Dokumentationsmodule sind Objekte, die selbst dauernd geändert werden: Fehler in Sourceprogrammen werden korrigiert, Algorithmen werden verbessert, Datenobjekte werden vereinfacht, die Leistung wird erhöht, usw.

Normalerweise werden Basicfiles nicht in ihrer ursprünglichen Darstellung gebraucht, sondern erst übersetzt und gebunden oder formatiert. Die Files, die auf diese Weise erzeugt werden, nennen wir "Workingfiles".

Schwierigkeiten entstehen, wenn mehrere Programmierer zusammen an einem Projekt, insbesondere an einem Modul, arbeiten. Es passiert, daß der eine ein Sourceprogramm ändert, ohne es den anderen Programmierern zu sagen, daß Beteiligte nicht wissen, ob eine vorgenommene Änderung schon gemacht worden ist usw.

Diese Schwierigkeiten können vermieden werden, wenn die Art und Weise, wie ein Modul geändert werden soll, an einige strenge Regeln gebunden wird.

Wir wollen erreichen, daß

- jeder beteiligte Programmierer sich über erneute Änderungen informieren kann;

- jedes Modul sich in einem brauchbaren Zustand befindet (wenn es nicht gerade geändert wird);

- von verschiedenen Programmierern durchgeführte oder vorgenommene Änderungen nicht miteinander in Konflikt geraten.

Um dieses Ziel zu erreichen, müssen wir die Menge von Operationen festlegen, die bedingt, was man mit einem Modul machen und wie man es ändern kann. Es wird dann nicht mehr möglich sein, anders auf ein Modul zuzugreifen, als wie es einmal festgelegt wurde.

* Ordentlicher Professor an der Carnegie-Mellon University in Pittsburgh/Penn.