Die Kreativität und der Einfallsreichtum des Software-Ingenieurs sind immer noch die besten Garantien für ein gutes Gelingen des Entwicklungsvorhabens. Software Engineering Environments (SWE) dienen dabei als Hilfsmittel, ersetzen aber keineswegs das "Nachdenken". Der Autor geht in dieser Folge seines Beitrages konkret auf ein Projektmodell seines Hauses, der GEI in Aachen ein, nachdem in den vorangegangenen vier Teilen allgemeine Fragen geklärt und spezielle Methoden vorgestellt wurden. Auch Einführungshinweise für solche Hilfsmittel und Methodenbündel werden in dieser letzten Folge gegeben.

Eines der wesentlichsten Ergebnisse der Informatik-Forschung zur Lösung der Softwarekrise ist die strukturierte Programmierung. Deren positive Wirkung auf die Struktur und Lesbarkeit von Programmen ist heute auch in der Praxis unumstritten.

Durch die Anwendung der Vorgehensweise, die E.W. Dijkstra bereits 1972 /Dah72/ vorgeschlagen hat, entstehen Programme, die wesentlich leichter verständlich, besser änderbar und wartbar sind als Programme, die im Spaghettistil programmiert wurden.

Was Dijkstra intuitiv vorgeschlagen hatte (klare Kontrollstrukturen, Verzicht auf goto, . .), wurde von Boehm und Jacobini theoretisch untermauert.

Jeder Algorithmus läßt sich mit den drei Grundstrukturen Sequenz, Selektion und Iteration darstellen.

Programme sollen schrittweise unter Verwendung dieser Grundelemente konstruiert werden. Da jedes dieser Grundelemente einen genau bestimmten Anfangs- und Endpunkt besitzt (Single Entry, Single Exit), lassen sich diese Konstrukte beliebig ineinander schachteln.

Goto nicht schädlich

Diese Grundkonstrukte sind auch in den gängigen Programmiersprachen leicht darstellbar, obwohl sie oft nicht direkt in Form von Syntaxkonstrukten zur Verfügung gestellt werden.

Man darf deshalb strukturierte Programmierung nicht mit "goto"-freier Programmierung gleichsetzen. In vielen Sprachen - besonders in Assemblern - ist es notwendig, zur Darstellung von Iteration oder Selektion Sprünge zu verwenden. Dies ist - solange es kontrolliert durchgeführt wird - weder verwerflich noch schädlich.

Strukturierte Programmierung bedeutet lediglich Einhaltung einer gewissen Programmhygiene: keine Sprünge mitten in Schleifen, keine selbstmodifizierenden Anweisungen, sondern klarer, einfacher und disziplinierter Aufbau von Algorithmen.

Im letzten Teil dieser Serie sollen Werkzeuge beschrieben werden, die die aufgeführten Methoden maschinell unterstützen. Dabei werden die Möglichkeiten für eine solche Unterstützung des öfteren an einem bereits existierenden Software Engineering Environment veranschaulicht, das die beschriebenen Theorien und Werkzeuge umfaßt: nämlich an Promod, dem Projekt-Modell der GEI, Aachen.

Bei größeren Projekten fällt im Laufe der Zeit eine Flut von Dokumenten an, die irgendwo geordnet und verwaltet werden müssen. In einem Software Engineering Environment wie Promod wird diese Aufgabe von der Projektbibliothek übernommen.

Zentrale Sammelstelle

Die Projektbibliothek ist die zentrale Sammelstelle für alle Teildokumente, die während der verschiedenen Phasen der Entwicklung entstehen. Sie nimmt die Datenflußdiagramme aus der Analysephase auf, die Schnittstellenbeschreibungen aus der Systementwurfsphase, die Algorithmen aus der Programmentwurfsphase, den Code einzelner Funktionen und vieles andere mehr. Durch die Projektbibliothek werden die Beziehungen zwischen den einzelnen Dokumenten aufrechterhalten und organisiert.

Alle Werkzeuge arbeiten deshalb mit den Informationen aus der Projektbibliothek und generieren neue Informationen für die Projektbibliothek.

Abbildung 16 gibt einen Überblick über das momentan realisierte Promod-System. Das Bild zeigt die Projektbibliothek als Zentrale, mit der alle Prozessoren kommunizieren. Durch die dicken Pfeile wird der Projektablauf angedeutet.

Die Projektbibliothek ist so organisiert, daß man unter Angabe des Typs eines Objekts (was man sucht; beispielsweise Modul oder Dateneintrag) und des Namens des Objekts die zugehörigen Informationen am Bildschirm oder Drucker erhält.

In weiteren Ausbaustufen werden die in der Projektbibliothek enthaltenen Informationen als Basis für die Realisierung von Versionshaltungen, eines Configuration Management Systems und eines Projektplanungs- und Kontrollsystems benutzt werden.

Dem Benutzer gegenüber stellt sich ein Software Engineering Environment als einheitliches, in sich geschlossenes System dar. Wenn in der Einleitung oder anderen Kapiteln über verschiedene Teile gesprochen wurde, so geschah dies deshalb, weil logisch mehrere Phasen in der Systementwicklung zu unterscheiden sind und in jeder Phase verschiedene Ziele angestrebt werden. Trotz dieser unterschiedlichen Tätigkeiten muß die Führung des Benutzers durch das System durchgehend gleichartig gestaltet sein.

Führung durch das System

Der Benutzer arbeitet mit dem Achener System interaktiv an einem Terminal.

Alle Kommandos sind nach dem gleichen Schema aufgebaut. Ganz egal, ob man Datenflußdiagramme eingeben will, ein Systemmodell analysieren oder einzelne Funktionen drucken will: Der Kommandoname und die Identifizierung des Objekts, das man manipulieren will, reicht dazu aus, um die gewünschte Aktion einzuleiten. Wenn man einmal wirklich nicht mehr weiterkommt, so ruft man dem System "Help" zu und erhält Informationen darüber, was man als nächstes tun soll oder kann.

Im folgenden werden die Werkzeuge für die einzelnen Phasen getrennt beschrieben, um die Zuordnung zu den Methoden zu verdeutlichen. Als Benutzer sollte man diese Werkzeuge nicht getrennt sehen. Für ihn existiert nur das gesamte System.

Die Werkzeuge für die Anforderungsanalyse und -definitionsphase dienen zur interaktiven Konstruktion eines Systemmodells, sowie zur Überprüfung der Konsistenz und Vollständigkeit dieses Modells.

Dazu sollten logisch vier Prozessoren zur Verfügung stehen:

- der DFD-Prozessor zur Erstellung von Datenflußdiagrammen,

- der DD-Prozessor zur Erfassung von Daten im Data Dictionary,

- der TD-Prozessor zur Erfassung von Transformationsbeschreibungen,

- der AAD-Analysator zur Prüfung der Zusammenhänge des Systemmodells.

Der Arbeitsablauf des Systemanalytikers ist in Bild 17 dargestellt.

Die Knoten 1.1 bis 1.3 stellen die interaktive Erfassung der Teile des Systemmodells dar. Nach der Analyse (1.4) erfolgt der Iterationsschritt: Alle in der Analyse festgestellten Mängel in dem Systemmodell müssen korrigiert werden; gleichzeitig kann man weitere Verfeinerungen des Modells vornehmen.

Die drei interaktiven Prozessoren übernehmen folgende Aufgaben:

- Erfassung und syntaktische Prüfung der einzelnen Objekte,

- Analyse der Objekte,

- optische Gestaltung und Aufbereitung für den Bildschirm beziehungsweise den Drucker.

Am Beispiel der Datenflußdiagramme sollen die Aufgaben näher erläutert werden.

Die Eingabe der DFD erfolgt interaktiv nach bestimmten syntaktischen Regeln. Die syntaktische Prüfung solle gewährleisten, daß Fehler in der Beschreibung erkannt und verbessert werden können. So wird in dem System erwartet, daß jedes DFD

- einen Namen hat,

- aus mindestens einem Knoten besteht,

- mindestens eine Ein- und Ausgabe benötigt oder erzeugt.

Durch die Analyse werden methodische Fehler bei der DFD-Eingabe erkannt. So darf ein DFD

- keine isolierten Knoten beinhalten,

- keine unbenannten Datenflüsse außer zu Dateien haben,

- keine Zyklen in den Datenflüssen aufweisen.

Die Eingabe erfolgt formatfrei. Sobald ein syntaktisch korrektes und methodisch fehlerfreies DFD eingegeben wurde, bereitet der Prozessor ein übersichtliches und geordnetes Layout für das DFD auf. Beim nächsten Zugriff auf dieses Objekt erscheint es formatiert auf dem Bildschirm oder Drucker.

Dem AAD-Analysator stehen alle Daten, die interaktiv durch die drei vorgenannten Prozessoren erfaßt wurden, zur Verfügung. Ihm obliegt die Konsistenzprüfung über die Grenzen der einzelnen Prozessoren hinaus. Die globale Funktionsweise kann Bild 18 entnommen werden.

Neben den konsolidierten Ausgaben für die einzelnen Objekte sollten Reports entstehen, die den Zusammenhang der Teile herstellen:

- der Analysereport,

- Cross-Referenz-Listen.

Der Analysereport kann folgende Fragen beantworten:

- existiert für jeden Datenfluß auf den unterschiedlichen DFD-Ebenen ein DD-Eintrag?

- existiert für jede Datei auf den verschiedenen DFD-Ebenen ein DD-Eintrag?

- gibt es zu jedem Knoten der DFD-Ebenen eine Transformationsbeschreibung?

- werden Ein- und Ausgabedaten in den Transformationsbeschreibungen verwendet?

- werden in den Transformationsbeschreibungen Daten verwendet, die nicht zur Verfügung stehen?

- existieren in Dateien lokale Datenquellen oder -senken?

Die Cross-Referenz-Listen zeigen die Verwendungsstellen von Daten in DFD, DD und TD. Dabei erfolgen Angaben sowohl über Quelle und Senke, als auch über strukturelle Charakteristika des Datums.

Ähnlich wie für die vorige Phase sollte für die Systementwurfsphase eine Reihe von Prozessoren zur Konstruktion und zur Prüfung der Systemspezifikation zur Verfügung stehen. Im einzelnen können das sein:

- der Transformator zur Umsetzung des Systemmodells in eine Modulstruktur,

- der MS-Prozessor zur Bearbeitung der Modulspezifikation,

- der FS-Prozessor zur Bearbeitung der Funktionsspezifikation,

- der DD-Prozessor zur Erweiterung des Data Dictionary,

- der SE-Analysator zur Prüfung und Aufbereitung der Systemspezifikation.

Der Designer benutzt die Werkzeuge so, wie es in dem Datenflußdiagramm Bild 19 dargestellt ist.

Die Transformation stellt den Initialschritt zu dieser Phase dar. Das fertige Systemmodell kann automatisch in eine hierarchische Modulstruktur umgesetzt werden, diese wird in der Projektbibliothek abgelegt /Loe81/. Dann kann man mit den drei interaktiven Prozessoren (2.2 bis 2.4) diese Strukturen weiter bearbeiten. Die Arbeitsweise der interaktiven Prozessorenentspricht der, die für die erste Phase ausführlich beschrieben wurde. Inhaltlich sind folgende Informationen zu bearbeiten: Zu den Moduln können zusätzlich Export- und Importfunktionen hinzugefügt werden, die Aufgabe der Moduln kann informell durch Spezifikation des Zwecks, oder formalisiert durch genaue Beschreibung der Funktionsköpfe festgelegt werden, moduleigene Daten können definiert werden. Mit dem FS-Prozessor können die Funktionen präzisiert werden durch informelle Beschreibung der Aufgabe, Definition von lokalen Daten und Beschreibung der Algorithmen im Pseudokode.

Mit dem SE-Analysator (2.5) prüft man nach den Spielregeln von Modular Design die entstandene Modulstruktur. Dabei

- werden unvollständig spezifizierte Importe vervollständigt,

- nicht definierte, aber benutzte Funktionen erkannt,

- Fehler in der Parameterversorgung von Funktionen festgestellt und

- Benutzung von Daten anderer Moduln angemahnt.

Außerdem bereitet der SE-Analysator das Systemspezifikationsdokument auf. Dazu zählt nicht nur die optische Gestaltung von Moduln, Daten und Funktionen, sondern vor allem auch die Darstellung der

- Zusammenhänge der Moduln (Modulstruktur),

- Aufrufhierarchie der Funktionen und der

- Querverweise für Daten und Funktionen.

Nach diesem Analyseschritt folgt wieder die kreative Arbeit des Systemdesigners (Knoten 2.6). Er korrigiert die aufgetretenen Fehler und spezifiziert weitere Teile des Systems. Diese Ergänzungen können danach wieder interaktiv in die Projektbibliothek gebracht werden.

Nach der Methode der schrittweisen Verfeinerung werden Funktionen und Daten präzisiert. Danach kann ein Pseudocode-Prozessor die aufgebauten Strukturen untersuchen und Fehler und Inkonsistenz erkennen. Wie in den vorigen Phasen liegt es danach beim Designer, diese Mängel zu beheben und die Programmspezifikation bis zu einem Detaillierungsgrad voranzutreiben, der als Programmiervorgabe nötig ist. Je nach der Mächtigkeit der ausgewählten Programmiersprache kann man diesen Prozeß früher oder später abbrechen.

Zur Unterstützung der Implementierung stehen dem Programmierer weitere Prozessoren zur Verfügung. Sie dienen hauptsächlich dazu, ein "Auseinanderlaufen" von Programmcode und Entwurfsdokument zu verhindern.

Das Problem entsteht dadurch, daß oftmals die Fehler im Programmcode, die während der Implementierungs-, Test- oder Wartungsphase gefunden werden, nur im Code verbessert werden, aber nicht im Entwurf.

Deshalb unterstützt Promod die Idee der "Single Source" - Programmcode und Entwurf stehen (physikalisch) auf einer einzigen Quelldatei. Änderungen, Fehlerkorrekturen, Verbesserungen und Erweiterungen werden in dieser Single Source vorgenommen.

Die Prozessoren zur Verwirklichung dieser Ideen sind

- ein Preprozessor und

- ein Postprozessor.

Wie man diese Prozessoren in der Implementierungsphase benutzt, ist in Abbildung 20 dargestellt.

Der erste Schritt ist die Transformation der Programmspezifikation mit dem Preprozessor. Dabei wird der bestehende Entwurf in eine Kommentardatei umgewandelt. (Die Programmiersprache ist wählbar und bestimmt, welche Kommentarzeichen verwendet werden.

Bsp: * für Assembler, (* . . . *) für Pascal ).

Im zweiten Schritt kann man zwischen Die Kommentarteilen den entsprechenden Code für Daten und Funktionen einfügen. (Der Prozessor hat die Stellen, an denen Code eingefügt werden soll, bereits gekennzeichnet.)

Die so aufbereitete Single Source kann danach durch den jeweiligen Compiler oder Assembler übersetzt werden. Dabei erhält man nicht nur den Objektcode, sondern auch ein sehr ausführlich dokumentiertes und gut verständliches Listing.

Treten Fehler auf oder sind Modifikationen vorzunehmen, so werden diese in der Single Source bearbeitet (siehe Knoten 4.5).

Der Postprozessor sollte in der Lage sein, aus der Single Source zu jedem beliebigen Zeitpunkt eine stets vollständige und aktuelle Dokumentation zu extrahieren. Da der Aufbau dieser Dokumentation nach wie vor den Regeln der Entwurfswerkzeuge entspricht, kann man daraus auch alle Analysen und Reports generieren, die schon während der Entwurfsphase zur Verfügung standen.

Auf diese Art gewährleisten der Pre- und der Postprozessor eine kontinuierliche Vorgehensweise und schritthaltende Dokumentation in den letzten Phasen des Software Life Cycle.

Ein Software Engineering Environment ist ein umfangreiches, für viele Bereiche einsetzbares Hilfsmittel bei der Erstellung großer Softwaresysteme.

Erfahrung unverzichtbar

Eines kann es aber sicherlich nicht: Es ersetzt keinesfalls die Kreativität und die Erfahrung gut ausgebildeter Softwarespezialisten. Zur Benutzung der Werkzeuge im Promod-System ist es erforderlich, die Methoden nicht nur kennengelernt zu haben, sondern mit ihnen zu leben, zu denken und zu arbeiten. Die Bedienung der Werkzeuge ist rasch erlernt, das richtige Arbeiten mit den Methoden jedoch erfordert intensives Training, praktische Erfahrung und weitgehende Unterstützung durch qualifiziertes Personal in der Einführungsphase.

Dies wird vielleicht verständlicher, wenn man den Vergleich auf der Ebene der Programmiersprachen zieht. Nimmt man einen erfahrenen Assemblerprogrammierer, der seit vielen Jahren effizient maschinennahe Probleme löst unter Ausnützung all seines Wissens über den Assembler, das Betriebssystem und die Hardware. Von strukturierter Programmierung weiß er nichts, er kommt auch so hervorragend zurecht. Gibt man dieser Person als Programmiersprache Pascal, ohne gleichzeitig intensiv die Konzeption von Pascal - wie strukturierte Programmierung, frei gestaltbare Typisierung - zu schulen, so wird man an den Pascalprogrammen alle Tricks wiederfinden, die auch in den Assemblerprogrammen enthalten waren, insbesondere Umgehung von verschiedenen Prüfmöglichkeiten durch Einschub von Assemblerprogrammstücken und ähnliches.

Anders herum betrachtet: Läßt man jemanden, dessen erste Programmiersprache Pascal war und der mit der strukturierten Programmierung erzogen wurde, danach im Assembler programmieren, so werden die Programme vielleicht nicht die Effizienz eines "geborenen" Assemblerprogrammierers erreichen, aber man wird alle schönen Eigenschaften der Sprache Pascal im Assembler wiederfinden.

Nicht die Sprache entscheidet, ob ein Programm gut oder weniger gut ist, die Methode, mit der das Programm erstellt wurde, ist wesentlich. Natürlich kann eine gute Sprache wesentlich dazu beitragen, den Stil zu verbessern und die Methode zu lehren.

So ist auch der Einsatz von Promod zu sehen. Nicht die Werkzeuge sorgen für eine problemlose Projektabwicklung. Die eingesetzten Methoden sind der wesentliche Fortschritt. Die Werkzeuge helfen nur dabei, die Methoden richtig einzusetzen und vieles an Aufwand, der sonst auf dem Papier getrieben werden müßte, dem Computer zu überlassen.

Experten in den Vereinigten Staaten haben festgestellt, daß die Einführung strukturierter Methoden in größeren Organisationen mindestens einen Zeitraum von fünf bis zehn Jahre in Anspruch nimmt. Man darf also im ersten Pilotprojekt mit unserem System keine Wunder erwarten, wenn das dafür eingesetzte Personal die Voraussetzungen und die Motivation noch nicht mitbringt.

Deshalb schlagen wir einen langsameren, evolutionären Weg der Einführung vor, den die GEI selbst beschreitet.

Durch den Einsatz von Entwurfshilfsmitteln wie PDL lernt man, mit Pseudocode und schrittweiser Verfeinerung umzugehen. Für viele kleinere, in sich abgeschlossene Projekte bringt der Einsatz kleinere Werkzeuge bereits die Hilfe, die man benötigt.

Wachsen im Lauf der Zeit die Kenntnisse über Methoden und die Ansprüche an Hilfsmittel und Werkzeuge, dann kommt der Zeitpunkt zu dem die Einführung komplexer Software Engineering Environments problemlos möglich ist.

Das Promod-System ist noch keineswegs der Schlußpunkt der Entwicklung. Es stellt nur den derzeit implementierten und verfügbaren Umfang dar. Wie bereits im Abschnitt über die Projektbibliothek angedeutet wurde, werden weitere Hilfsmittel in das System eingebunden werden. Diese weiteren Hilfsmittel werden vor allem die Projektplanung, -koordinierung und -überwachung unterstützen. Damit wird das Spektrum der Leistungsfähigkeit weiter abgerundet und vervollständigt. (Ende der Folge)

Literaturverzeichnis:

(Boe 76) B. Boehm, Software Engineering, IEEE Trans. on Electr. Comp.. Dec. 1976.

(Cai75) S. H. Caine, E. W. Gordon, PDL: A Tool for Software Design, in: AFIPS, Proc., NCC, Vol. 44, 1975.

(Dah72) O. J. Dahl. E. W. Dijkstra, C. A. R. Hoare, Structured Programming, Academic Press, 1972.

(DeM79) T. DeMarco, Structured Analysis and System Specification, Yourdon Press, 1979.

(DeR76) F. DeRemer, H. H. Kron, Programming-in-the-Large versus Programming-in-the-Small, IEEE Trans. on SE, Vol. 2, No. 2, 1976.

(Fre77) P. Freeman, Fundamentals of Design, in: P. Freeman. A. Wasserman, Tutorial on Software Design Techniques, 3rd Ed., IEEE, 1980.

(GEI79) GEI mbH, PDL Entwurfshandbuch, GEI interne Notiz, 1979.

(Hru82) P. Hruschka, Fallstudie: Die Software-Produktionsumgebung PROMOD, GEI Kursunterlagen.

(Jac75) M. A. Jackson. Principles of Program Design, Academic Press. 1975.

(Ker81) P. Kerola, P. Freeman, A Comparison of Life Cycle Models, in: IEEE Proc. 5th ICSE, p.90-99 1981.

(Keu81) H. Keutgen, DARTS - Design Aid for Real Time Systems, KfK-PFT 17, Januar 1982, Kernforschungszentrum Karlsruhe.

(Lau80) R. Lauber et al., EPOS - A Specification and Design Technique For Computer Controlled Real-Time Automation Systems, in: IEEE Proc. 4th ICSE, p. 245-250 1980.

(Lis74) B- Liskov, S. Zilles. Programming with Abstract Data Types, ACM Sigplan Notices, Apr. 1974.

(Loe81) S. Loeffler, U. Satthoff, PROMOD-Transformator, GEI interne Notiz, 1981.

(Mil71) H. D. Mills, Top down Development in Large Systems, in: R. Rustin (ed.), Debugging Techniques in Large Systems Englewood Cliffs, N J.: Prentice Hall 1971.

(Mye75) G. J. Myers, Reliable Software Through Composite Design, Van Nostrand Reinhold, 1975.

(Orr77) K. T. Orr, Structured System Development, Yourdon Press, 1977.

(Par71) D. L Parnas, Information Distribution Aspects of Design Methodology, Proc. IFIP Congress 71, North Holland, 1971.

(Par72) D. L Parnas On the Criteria To Be Used in Decomposing Systems Into Modules, CACM, Vol. 5, No. 12, Dec. 1972.

(Ros77) D. T. Ross, K. E. Schoman, Jr., Structured Analysis for Requirement Definition, IEEE Trans. on SE, Jan. 1977.

(Sch81) R. Schaede, Eine Methode zum modularen Systementwurf, Software Technik Trends, Heft 1-2. 1981.

(Tei77) D. Teichroew, E. A. Hershey III, PSL/PSA: A Computer-Aided Technique For Structured Documentation and Analysis of Information Processing Systems, IEEE Trans. on SE. Vol. 3, No. 1, Jan. 1977.

(Wil80) R. R. Willis, Computer Aided Design of Software Systems. in: Proc. 4th ICSE. p.116-125, 1980.

(Wir76) N. Wirth, Algorithmus + Data Structures = Programs, Prentice Hall, 1976