MÜNCHEN- "Schon die Dokumentation macht keiner gern", sagt Friedel Marksteiner, leitender Mitarbeiter der Münchener Gesellschaft für Systementwicklung (gfs)mbH, "und um die Nachdokumentation steht es noch weitaus schlimmer." Marksteiner, der mit seinem Referat über computerunterstützte Dokumentation in der Software-Entwicklung die Sommer-Vortrags-reihe des Arbeitskreises Org./EDV, München, abschloß - CW berichtete darüber in Ausgabe 28 -, vertritt jedoch auch die Ansicht: "Ein Tool soll man nicht spüren." Beiden Anforderungen, versuchte Marksteiner in seinem Vortrag zu belegen - der Lösung des Dokumentationsproblems und der Benutzerfreundlichkeit-, wird "Byblos" gerecht.
Ein Aschenbrödel-Dasein sei es, was die Dokumentation heute führe, darüber war sich die Zuhörerrunde schnell einig. Sie gelte allgemein nichts, weil sie nichts Kreatives biete, aber zeitaufwendig sei, und weil sie zu unterlassen keine sofortigen Probleme schaffe. In dieser laxen Einstellung, diagnostizierte Marksteiner, liege eine der wesentlichen Ursachen für die sogenannte Software-Krise.
Ihre Kennzeichen seien Entwurfsmängel, Umsetzungsprobleme, zunehmender Wartungsaufwand sowie Planungsfehler (= Managementfehler im Verlauf eines Softwareprojekts); und dies alles laufe - bei zugleich immer neuen Anforderungen an die DV - auf rapide steigende Softwarekosten hinaus. Hier helfe nur konsequentes Software-Engineering, befand Marksteiner, insbesondere das Werkzeug der projektbegleitenden, rechnergesteuerten Dokumentation.
Adäquat und handhabbar
Wichtig für ein in Frage kommendes Tool sei es, folgende Kriterien zu erfüllen: Es soll problemadäquat, zielgruppengerecht, verhältnismäßig, wirtschaftlich und beherrschbar sein außerdem den Anforderungen der Methodenverträglichkeit, Akzeptanz und Handhabung entsprechen. Diese Attribute, meinte Marksteiner, träfen zu auf Byblos, einem "DV-System zur Dokumentation von Org- und Software", wie er es nannte.
Er könne dies guten Gewissens sagen, weil er an der Entwicklung von Byblos entscheidend mitgewirkt habe und deshalb alle Details kenne, unterstrich der Referent; zudem habe er in seiner neuen beruflichen Funktion an Byblos keinerlei kommerzielle Interessen mehr. (Byblos-Vertreiber sind Sidos und Siemens, beide München.) Zunächst stellte Marksteiner die Prozeßebenen der Byblos-Dokumentationsstruktur vor (siehe Grafik).
Im Top-Down-Verfahren werden Daten und Prozesse von Org/DV-Systemen und deren hierarchische, assoziative und Verwendungsrelationen auf verschiedenen Detaillierungsebenen beschrieben. In der Grafik bedeutet "Area" einen ablauforganisatorischen Abschnitt (ähnlich einer Transaktion), "Unit" ist eine Einzelaufgabe mit Spezialcharakter (beispielsweise die Datenerfassung in einem Betrieb), "Sequence" entspricht einer Teil-, "Rule" einer Elementaraufgabe. Die selbständige Dateneinheit "Stack" stellt das Ergebnis eines Ablaufs dar (das auch ein Zwischenergebnis sein kann).
Abfragen in alle Richtungen
Die Byblos-"Artikel" (Kästchen und Keise) auf der linken Seite der Grafik bilden den funktionell-fachlichen Teil, die auf der rechten Seite den DV-technischen Teil eines Gesamtsystems ab. Alle Beziehungen definiert Byblos von oben nach unten, vom Grob- bis zum Feinkonzept. Verknüpfungen und Abfragen können überallhin erfolgen.
Elemente eines Byblos-Artikels und somit Byblos-Darstellungsmittel - sind
- die Identifikation (Name, Kurzdefinition),
- die Deskriptorer, (Zergliederung, Zuordnung),
- die Beschreibung (Text, Entscheidungstabellen etc.) und
- die Verknüpfung (Richtung, Funktion).
Nur Byblos, merkt Marksteiner dazu an, erlaubt es, die Qualifikation einer Verknüpfung im System abzulegen. Wie ein Byblos-Artikel in praxi aussehen kann, veranschaulicht das abgedruckte Beispiel einer Area.
Eine Besonderheit neben Byblos-Funktionen wie Abfrage/Auswertung. oder Eingabe/Änderung sei das "Lexikon", hob Marksteiner hervor. Es gewährleiste gesteuerte Redundanz und die Vermeidung von Überschneidungen und Mehrfachspeicherungen. Dies geschehe, indem Byblos in mehreren Schritten die Abfragbarkeit eines neu aufzunehmenden Datenelements herstelle und dazu dessen Namen interpretiere sowie.
Auf diese Weise frage Byblos im Wege der grammatikalischen Vereinfachung und Einsetzung von Hauptsynonymen ab, ob ein solches Element - beispielsweise die Mehrwertsteuer- bereits vorhanden ist, vielleicht mit modifizierter Benennung und erziele durch rechtzeitige Fehlermeldung entsprechende "Spareffekte".
Der Allround-Charakter von Byblos kommt nach Marksteiners Ansicht nicht zuletzt in der Vielzahl der möglichen Abfragen zum Ausdruck. Im einzelnen stehe zur Wahl: das Erstellen der Dokumentation, ferner von Übersichten, Strukturdiagrammen, Verwendungsnachweisen, Planungs-, Schulungs- und Arbeitsunterlagen, darüber hinaus das Ermitteln und Prüfen von Schnittstellen und das Suchen nach bereits Vorhandenem. Außerdem unterstütze Byblos die Programmierung durch Generieren eines Programmrahmens.
Sourcecode sei in Byblos allerdings nicht ablegbar, räumte Marksteiner ein, zumindest auf absehbare Zeit. Byblos biete jedoch die Generierung compilierungsfähiger Programmteile (aus den in der Dokumentation abgespeicherten Funktionen) und eine Sicherung des Gleichlaufs zwischen Dokumentation und Programmbibliothek.
Die eingangs angedeuteten Probleme der Nachdokumentation, zog Marksteiner Bilanz, seien bei Byblos gut aufgehoben. In erster Linie handele es sich dabei um die Probleme der fehlenden Informationsquellen, uneinheitlichen Namensvergabe und mangelnden Motivation, aber auch um Umstellungsaufwand, das Blockieren produktiver Kapazitäten und nur schwer nachweisbare Wirtschaftlichkeit.
Nachdokumentations-Tools seien für Cobol und PL/I vorhanden, sagte Marksteiner, und Byblos laufe auf IBM-, Siemens- und Univac-Anlagen, sei aber- da in Cobol geschrieben auf andere Fabrikate leicht übertragbar. "Vom Konzept her" - damit schloß Marksteiner seine Ausführungen - "wird Byblos über eine Batch-Schnittstelle bedient, Online-Versionen aber sind bereits teilverwirklicht oder stehen unmittelbar bevor."