Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.09.1986 - 

Langfrist-Risiko nimmt leicht gravierende Formen an:

Mangelnde Dokumentation wird zum Kostenfaktor

Die potentiellen Folgekosten mangelhafter Dokumentation halten sich so lange in Grenzen, wie nur programminterne Details betroffen sind. Kommen jedoch Aspekte des externen Datenflusses mit ins Spiel, lassen sich die Risiken kaum noch abschätzen. In seinem Beitrag nimmt Horst Pollmann* die automatische Programm-Dokumentation unter die Lupe.

Dokumentation ist kein Selbstzweck, und bekanntlich läuft ein Programm auch ohne jeden Kommentar. Sie leistet also weder einen Beitrag zur besseren Funktionalität noch zur schnelleren Fertigstellung des Programms.

Bedeutung gewinnt die Dokumentation als Kostensenkungs-Faktor: wenn nicht unmittelbar beim Programm, dann mittelbar für Anpassungen und im größeren Rahmen im Bereich der Nachfolge-Programme. Selbst unter Annahme des theoretischen Falls, daß sich die geforderte Funktionalität nicht verändert und der Autor des Programms dem Unternehmen auch erhalten bleibt, sind die Schnittstellen zwischen Programm und Umgebung von zentraler Bedeutung.

Verzicht auf Dokumentation ist ein Scheingeschäft

Die potentiellen Folgekosten aus mangelnder Dokumentation halten sich so lange in Grenzen, als nur programminterne Details betroffen sind. Hier mag ein Kostenvergleich sogar zeigen, daß der Verzicht auf Dokumentation momentan preiswerter ist als deren Herstellung. Sind jedoch Aspekte des Datenflusses von/nach außen berührt, lassen sich die Risiken bald kaum mehr abschätzen.

Zu untersuchen sind also die Komponenten einer vollständigen Programmdokumentation auf ihre Relevanz hinsichtlich der Schnittstellen. Die vorhandenen Interfaces gehen

- nach außen: zum Benutzer, über Bildschirm- beziehungsweise Druckformate, Parametereingaben und natürlich über die dem Programm innewohnende Logik, das heißt die Funktionalität,

- zur Seite: zu parallel laufenden Programmen, über operative Datenbasen (Common Areas und Workfiles),

- nach innen: zur strategischen Datenbasis des Unternehmens, also zu den Datenbanken,

- nach unten: zu den Unterprogrammen, über Schnittstellen-Parameter,

- nach oben: zu den DB/DC-Trägersystemen und dem Betriebssystem, über Link-Parameter und Unterprogramm-Calls.

Nun zu den Eigenschaften, die ein qualifizierter Dokumentations-Generator haben muß: Da auch hier ein Alleskönner unwirtschaftlich wäre, muß sich das System auf die hoch gewichteten Faktoren konzentrieren - zumindest darf es in diesen Bereichen keine Schwächen haben.

Die Ankopplung an ein Data-Dictionary ist an zwei Stellen erforderlich: Am Anfang ermittelt das Analysesystem beschreibende und strukturrelevante Daten zu im Programm gefundenen Namen, am Ende nimmt das Dictionary die Referenzdaten der Elemente auf. Daraus ist keine systemspezifische Abhängigkeit abzuleiten.

Ferner sind einige Standards einfach unverzichtbar: So wird es zum Beispiel für den Analysator sehr schwer, wenn Schnittstellenparameter zu Datenbanken nicht am Namen erkennbar sind, oder wenn bestimmte Elemente der Datenbasis im Programm plötzlich ganz anders heißen weil dort nicht wie üblich Strukturdefinition als Makro eingesetzt wurde, sondern die Struktur kurzerhand intern nachgebaut wurde.

Der Wert eines Analysators ist um so höher zu bewerten, je umfangreicher die "Restfunktionalität" ist, falls eine der bereits erwähnten Voraussetzungen nicht oder nur teilweise gegeben ist. Das ist auch der Grund dafür, daß die Forderung nach Unabhängigkeit vom Dictionary an erster Stelle steht.

Der Analysator muß in der Lage sein, alle geforderten Informationen aus der Source allein zu ziehen. Das verringert - wegen der fehlenden Hinweise auf die Logik der Elemente - zwar den dokumentarischen Wert der Analyseliste, darf aber deren Vollständigkeit nicht in Frage stellen. Daraus ergibt sich eine Forderung nach substituierenden Steuerkommandos, die an die Stelle eines im Source nicht gegebenen Standards treten.

Alias-Namen und andere Platzhalter-Hinweise sollten zu Beginn der Analyse definiert werden können. Der Analysator muß I/O-Areas als solche erkennen, auch wenn sie nicht als Makro definiert sind, und DB-Interface-Strukturen identifizieren, auch wenn sie nicht den inzwischen eingeführten Namenskonventionen gehorchen. Konkret läuft es darauf hinaus, daß der Analysator Steuerkommandos für Synonymgleichungen, Einzeldefinitionen und generische Definition im Repertoire haben muß.

Aus der Analyse muß hervorgehen, welche DB-Elemente gelesen, verändert, erstellt und gelöscht werden. Auch die Häufigkeit pro Elemente sollte ausgewiesen sein. Wichtig ist ferner, daß Hierarchien erkennbar werden. Wenn also ein Programm ein Segmentexemplar in die Datenbank schreibt, muß die Analyse deutlich machen, ob die Struktur Feld für Feld zusammengebaut wird oder kommentarlos von irgendwoher übernommen ist.

Hinweise auf Parameter sind unerläßlich

Ähnliches gilt für die Analyse der Datei-Referenz. Zu ergänzen ist, daß Redefinitionsstrukturen erkannt und ausgewiesen werden müssen. Ebenso wichtig wie die Frage, welche der Parameter gelesen oder geändert werden, sind die Hinweise auf solche, die überhaupt nicht verwendet oder nur an Unterprogramme durchgereicht werden. Die Forderungen für die Analyse der Ausgabe-Formate sind weitgehend mit denen zu Datenbank-Elementen identisch. Ein weitergehendes Postulat wäre, die Zuordnung DB-Elemente zu Ausgabeformat-Feld zu ermitteln.

Im Sinne einer Baukasten-Stückliste müssen die Aufrufe externer Unterprogramme ausgewiesen werden. Hier taucht das Problem auf, daß Unterprogramme Parameter - zum Beispiel DB-Felder - übergeben bekommen, über deren Verwendung zunächst keine Aussage gemacht werden kann. Der Analysator muß dieses Problem entweder lösen (Analyse-Ergebnis zum Unterprogramm in der Bibliothek, Verarbeitung von Kommentaren an den Analysator) oder als ungelöst im Ergebnisprotokoll ausweisen.

Dies läßt sich beispielsweise so lösen, daß neben der Referenzliste auch eine Liste der "kritischen Punkte" im Programm erstellt wird. Neben Verstößen gegen Standards enthält diese Liste alle Feldreferenzen, die undefiniert sind.

Die Kontrolle der Normen und Standards geht über die reine Referenz-Analyse und führt zur ganz allgemeinen Qualitätskontrolle. Beginnend mit den Namenskonventionen, kann man sich sehr weitgehende Prüfungen vorstellen, bis hin zu Fragen des Layouts.

Mit diesen Forderungen sind die in der Tabelle gesetzten Schwerpunkte im wesentlichen abgedeckt. Es gibt aber noch eine nicht besonders schwierige Aufgabe, die einem Programm-Analysator zugemutet werden kann: die Extraktion des programminternen Kommentars. Jeder Programmierer ist noch am ehest??? direkt in der Source bereit, einige Worte über die Vorgehensweise zu verlieren, was ohne große Mühe zu den Dokumentationskomponenten Inhaltsverzeichnis, besondere Hinweise (Tricks) und Sachwortregister führt.

Die Überlegung zielt auf die drei letzten Punkte der Tabelle, die aus dem Blickwinkel der Schnittstellen nicht erstrangig waren. Dennoch sollte ein guter Programmcode-Analysator hier nicht passen: Solche einfachen, aber langwierigen Aufgabenstellungen waren der auslösende Impuls, um Programme zu schreiben.

*Horst Pollmann ist zuständig für den Vertrieb von IBM-Softwareprodukten in der Zweigniederlassung Dortmund der GEI Gesellschaft für Elektronische Informationsverarbeitung GmbH Aachen.