Allzu oft wird die Dokumentation der DV-Systeme als eine Tätigkeit betrachtet, die neben der eigentlichen Programmentwicklung abläuft. Dies trifft jedoch nicht zu: Die Dokumentation ist eher als Abfallprodukt der Entwicklung zu sehen. Auf der einen Seite gibt der Entwickler etwas ein, möglichst über Bildschirmmasken en im Dialogbetrieb und auf der anderen Seite kommt die Dokumentation heraus, möglichst in Form von Tabellen und Diagramme (Siehe Abb. 1). Das, was er eingibt, sollte auch so formalisiert sein, daß es sowohl an sich als auch gegen andere Eingaben geprüft werden kann. Auf keinen Fall darf die Dokumentation nur ein Spiegelbild dessen sein, was der Entwickler am Bildschirm malt oder eintippt. Sie muß vielmehr eine Synthese beziehungsweise eine Aggretation verschiedener Entwicklungsinformationen bilden.
Das Hauptproblem der Dokumentation ergibt sich aus den unterschiedlichen semantischen Ebenen der Software-Entwicklung, wobei es mindestens vier gibt (siehe Abb. 2). Auf der höchsten Ebene befindet sich eine globale Definition des Systems bezüglich seines Umfangs und seiner Qualität. Der Umfang wird einerseits durch die geplanten Informationsobjekte, Benutzerschnittstellen, und Verarbeitungsvorgänge bestimmt. Die Qualität wird andererseits durch die Vergabe und Gewichtung der gewünschten Systemeigenschaften oder Qualitätsmerkmale determiniert. Auf Grund dieser Faktoren sollte es möglich sein, die Größe und die Komplexität des geplanten Systems abzuschätzen. Auf dieser Ebene kommt es darauf an, die globalen Systemelemente und ihre Zusammenhänge sowie die Abgrenzung des Systems von seiner Umwelt darzustellen. Dafür sind solche Dokumentationsmittel wie Kataloge, Entity/ Relationship-Diagramme, Belegflußpläne, grobe Ablaufdiagramme und Zuordnungstabellen geeignet.
Darstellungstechniken ordnen
Auf der nächsttieferen Ebene kommt das Fachkonzept. Hier werden die Informationsobjekte, Belege und Vorgänge ausführlich beschrieben und ihre Beziehungen zueinander festgelegt. In dem Fachkonzept wird das konzeptionelle Datenmodell durch die Bestimmung der Objekt/ Objekt-Beziehungen gebildet. Ebenfalls werden die Systemabläufe durch die Vorgabe der Vorgang/ Vorgang-Beziehungen bestimmt. Die groben Datenflüsse folgen aus den Vorgang/ Objekt-Beziehungen. Auf dieser Ebene werden auch die Benutzerschnittstellen - die Bildschirmmasken, Listenbilder und sonstige externe Datenträger - beschrieben. Dazu kommen die Daten- und Funktionsstrukturen sowie die Entscheidungslogik aus fachlicher Sicht. Die Entscheidungslogik könnte etwa als Entscheidungstabelle oder als einfache Bedingung eingegeben werden. Natürlich müssen auch die Beziehungen zwischen den einzelnen Funktionen, einschließlich der Bedingungen und den einzelnen Datenelementen definiert sein. Schließlich gilt es, die Funktionen und Daten selbst in bezug auf ihre Attribute zu beschreiben. Für die Dokumentation des Fachkonzepts sind eine Reihe Darstellungstechniken, wie etwa Entity/ Relationship-Programme, Datenflußdiagramme, Petrinetze, Ablaufdiagramme, Prozeßmatrizen, Musterbelege, Datenbäume, Funktionsbäume, HIPO Diagramme, Entscheidungstabellen, Entscheidungsbäume, Kataloge und Querverweislisten erforderlich. Es ist jedoch zu merken, daß hier nur die fachlichen Elemente, Strukturen und Beziehungen dokumentiert werden. Schon bei Fachkonzepten mittlerer Größenordnung ist eine maschinelle Dokumentationsunterstützung fast unentbehrlich.
Auf der nächst tieferen semantischen Ebene wird die Dokumentation noch vielfältiger. Denn hier handelt es sich um das DV-technische Konzept und dieses umfaßt noch mehr Elemente und Beziehungen.
Entwurfsinformationen speichern
Aus den Informationsobjekten werden hier Dateien und Datenbanken, aus den Belegmustern werden Masken- und Listenbeschreibungen aus den Vorgängen werden Programme und Prozesse aus den Datengruppen werden Sätze beziehungsweise Segmente, aus den Funktionsgruppen werden Module. Aus der Entscheidungslogik wird Pseudocode oder Entwurfssprache, aus den Datenflüssen werden Programmoder Modulschnittstellen. Es entsteht hier also ein riesiger Topf von Dateien und Datenbeschreibungen Masken- und Listenbeschreibungen Prozeß-, Programm- und Modulbeschreibungen sowie die Beschreibungen ihrer statischen und dynamischen Beziehungen zueinander.
Eine fast unendliche Anzahl von Dokumententypen können aus diesem Topf abgeleitet werden: Datenbankbäume, Datenflußnetze, Ablaufdiagramme, Petrinetze, EVA-Diagramme, Programmbäume, Strukturprogramme, Prozeßmatrizen oder Zuordnungstabellen. Manuell wird dies kaum zu schaffen sein. Die Dokumente müssen maschinell generiert werden. Dies setzt allerdings voraus, daß die Entwurfsinformation in dem DV-technischen Konzept maschinell gespeichert und verarbeitet ist.
Anspruchsvolle Tools
Auf der untersten Ebene liegt das Programm - ein Bündel datenbeschreibender und verarbeitender Anweisungen in irgendeiner Programmsprache, sei es Cobol, PL/1, RPG, Pascal oder Natural. Das Programm ist selbst ein Dokument, sogar das zuverlässigste, das wir haben. Es ist das einzige, das wirklich getestet wird. Aber der Quellcode ist in der Regel sehr detailliert und für die meisten, außer dem Verfasser selbst, kaum verständlich. Daher ist es notwendig, die Information, die in dem Programm steht, mit einem Werkzeug herauszuholen und menschengerecht aufzubereiten. Dazu dient ein statischer Analysator. Dieses Werkzeug liest das Programm, holt die Elemente und Beziehungen heraus und setzt sie in Dokumente wie Programmbäume, Datenbäume, Eva-Diagramme, Struktogramme und Datenflußtabellen um. Ein anspruchsvolles Software-Werkzeug kann sogar die Dokumente der dritten semantischen Ebene fast vollständig aus dem Programm wiederherstellen. Interessant wäre ein Tool, das aus Informationen des DV-Konzeptes auch das Fachkonzept nachdokumentieren könnte. Dazu sind aber erst einige grundsätzliche theoretische Probleme zu lösen.
Das Fazit dieser kurzen Wanderung durch die semantischen Ebenen der Software-Dokumentation läßt sich vielleicht so ausdrücken: Software und damit auch die Software-Dokumentation ist vielschichtig. Sie ist nicht nur tief gestaffelt, sondern auch breit gestreut. Um sie wirklich zu durchleuchten und nicht nur oberflächlich zu skizzieren, braucht man eine Vielzahl unterschiedlicher Darstellungsmittel.
Mit einem Dokumententyp ist es nicht getan. Ein Struktogramm vermittelt vielleicht etwa ein Zehntel dessen, was man über ein System wissen muß. Auch Hipo- und Sadt-Diagramme reichen bei weitem nicht aus, um ein DV-System in seiner ganzen Fülle darzustellen.
Die Dokumentation ist schließlich auch ein Mengenproblem. Die heutigen DV-Systeme werden immer größer und immer komplexer. Ein durchschnittliches System in der kommerziellen Datenverarbeitung wird mehrere tausend Daten und mehrere hundert Funktionen umfassen. Die Zahl der Beziehungen - Datenflüsse, Abläufe und Querverbindungen geht auch in die Tausende. Der Einsatz automatisierter Dokumentationswerkzeuge ist deshalb umgänglich, vor allem um Dokumente wahlweise gezielt generieren zu lassen. Wer dies nicht einsieht, wird früher oder später in seiner eigenen Papierflut ersticken.
*Harry M. Sneed ist Geschäftsführer der SES Software Engineering Service GmbH in München-Neubiberg