KÖLN (je) - Auf der Ebene der Beschreibung des Programmablaufs erweist sich das Struktogramm als besonders vorteilhaft. Harry M. Sneed vertritt diese Auffassung in seinem neuen Buch "Software-Entwicklungsmethodik", das unlängst bei der Kölner Verlagsgesellschaft Rudolf Müller GmbH & Co. erschienen und für 42 Mark erhältlich ist. Zur Frage der bestmöglichen Technik für den Entwurf von Programmen ergreift Sneed Partei für die Methoden von Michael Jackson.
Sneeds Buch beschreibt im einzelnen die Spezifikation, die verschiedenen Entwurfsstufen und -verfahren, die strukturierte Programmiertechnik, die verschiedenen Testphasen und die Qualitätskontrolle sowie die Werkzeuge zur Unterstützung dieser Aktivitäten. Außerdem werden Beispiele aus der DV-Praxis beschrieben und das Zusammenwirken von Methoden, Werkzeugen und Kontrollverfahren am Beispiel eines Softwareentwicklungssystems geschildert. Im folgenden ist mit freundlicher Genehmigung des Autors der Abschnitt 3.2.2 des Buches (Titel: "Programmentwurf") wiedergegeben.
Der Programmentwurf liegt, was den Abstraktionsgrad anbetrifft, eine Stufe tiefer als der Systementwurf. In ihm geht es nicht um das Gesamtsystem, sondern um einzelne Subsysteme beziehungsweise Komponenten die bei der Implementierung Phasen oder Lademoduln bilden werden. Sie können zwar mehrere Moduln beinhalten, sind aber eine Laufeinheit. Der Blickwinkel des Programm-Designers ist um einiges eingeschränkt gegenüber dem des System-Designers. Während der System-Designer sämtliche Schnittstellen und Funktionen berücksichtigen muß, kann der Programm-Designer seine ganze Aufmerksamkeit auf die Schnittstellen und Funktionen einer einzelnen Komponente konzentrieren. Die Entwurfsaufgabe ist daher um einiges einfacher.
Schon die Elemente eines Programmentwurfs sind für den Menschen leichter faßbar. Die statischpassiven Elemente sind inzwischen schon einzelne Tabellen, Datensätze oder andere überschaubare Datengruppierungen. Sie belegen entweder den internen oder externen Speicher und sind in bezug auf den Speicher definierbar. So gibt es statische und dynamische interne Speicherfelder sowie verschiedene Formen der externen Speicherung, wie zum Beispiel sequentiell, index-sequentiell oder relativ. Hier spielt auch die Zugriffsart eine wesentliche Rolle, das heißt, es treten bei der Definition der Code- und Speicher-Einheiten in stärkerem Maße lmplementierungsgesichtspunkte auf.
Die statisch-aktiven Elemente, die hier näher definiert werden, sind die Moduln, das heißt die eigentlichen Compiler- und Testeinheiten. In einer Sprache wie PL/1 sind es die externen Prozeduren, in Cobol die Programme und in Assembler die CSECTS. Die dynamisch-passiven Elemente sind der echte Datenaustausch zwischen Moduln sowie zwischen dem Programm und seiner Peripherie. Dazu gehören die Parameter bei Modulaufrufen, Interprogramm-Nachrichten und Dateizugriffen. Die dynamischaktiven Elemente sind letztlich die Aufruffolgen der einzelnen Moduln.
Für die Beschreibung der internen Speichereinheiten wie Tabellen, Parameter oder globale Strukturen sollte die Programmiersprache selbst herangezogen werden. Dies gilt auch teilweise für die externen Speichereinheiten wie Datenbanken oder Dateien. Nur sollten hier die Satz-Definitionen durch Mengenangaben ergänzt werden, beispielsweise Größe des primären Bereichs und Größe des sekundären Bereichs. Hierfür kann schon die Job Control-Sprache des jeweiligen Betriebssystems oder Datenbanksystems benützt werden.
Die Zuordnung der logischen Funktionen zu Moduln ist eine der schwierigsten Aufgaben des Programmentwurfs. Sie müssen so gruppiert werden, daß sie einen gemeinsamen Datenbereich haben, das heißt, daß sie über die Daten miteinander gekoppelt sind. Ein typisches Beispiel ist ein Modul, der eine Tabelle verwaltet. Er enthält die Funktionen: Einfügen, Suchen und Löschen. Diese Funktionen sind zeitlich voneinander getrennt. Dennoch gehören sie zusammen, weil sie alle die gleichen Daten verarbeiten (s. Abb. 1). Eine solche Vereinigung über den Zugriffsraum ist ein Grundsatz des "Structured Design".
Für die Beschreibung der Moduln können Baumdiagramme und Datogramme benutzt werden. Das Baumdiagramm bildet die Aufrufhierarchie ab, während die Datogramme die Ein/Ausgaben in und von dem Modul sowohl vertical als auch horizontal darstellen. Das Baumdiagramm auf dieser Ebene ist nicht mit dem Baumdiagramm auf der Systemebene zu verwechseln. Dort geht es um die funktionale Struktur, hier ist es die Struktur der Code-Einheiten, das heißt: Welcher Modul ruft welche anderen Moduln auf? (s. Abb. 2)
In dem Datogramm werden die Modul-Ein-/Ausgaben in bezug auf ihre physische Quelle beziehungsweise Senke eingeordnet. So gibt es Eingaben, die als Argumente von übergeordneten Moduln, oder Eingaben, die als Ergebnisse von untergeordneten Moduln kommen. Gleichzeitig gibt es Eingaben von externen Datenbereichen beziehungsweise Dateien oder von internen GLOBAL-Bereichen. Auf der Ausgabenseite gehen Argumente an untergeordnete Moduln und Ergebnisse an übergeordnete Moduln zurück. Parallel dazu können Daten in externen Dateien oder in internen GLOBAL-Bereichen abgelegt werden (s. Abb. 3). Die Moduln werden also durch ihren Standort sowie durch ihre Ein-/Ausgaben definiert.
Zur Beschreibung der physischen Datenflüsse, das heißt des Datenaustausches zwischen Moduln untereinander sowie zwischen Moduln und der Peripherie, können Datenflußtabellen dienen. Darin bilden die Moduln die Spalten und die Datenschnittstellen die Reihen. Wenn ein Modul von einer Schnittstelle liest, wird ein "E", wenn er in derselben schreibt, ein "A", und wenn er beides tut, ein "E/A" in dem betreffenden Quadrat eingetragen (s. Abb. 4).
Zur Beschreibung des Programmablaufs gibt es eine Reihe von Darstellungsmitteln wie Ablaufpläne, Struktogramme oder Pseudo-Codes. Auf dieser Ebene erweist sich das Struktogramm als besonders vorteilhaft, weil sich die Aufrufungsfolge der Moduln in Abhängigkeit von bestimmten Bedingungen in wenig Raum graphisch ausdrücken läßt. (s. Abb. 5). Pseudo-Code ist hingegen mehr für den Ausdruck der detaillierten Modulablauflogik geeignet.
Als Ergebnis des Programmentwurfs müßte zumindest folgende Dokumentation vorliegen:
- eine Beschreibung der Programm-Ein-/Ausgaben,
- eine Beschreibung der internen Schnittstellen,
- eine Beschreibung der Modulstruktur,
- eine Beschreibung des internen Datenflusses und
- eine Beschreibung der groben Ablauflogik.
Eine für den Entwurf von Programmen besonders geeignete Technik ist die von Michael Jackson, wonach die Programmstruktur aus der Datenstruktur abgeleitet wird. Wenn es schon feststeht, welche Eingaben ein Programm bekommt und welche Ausgaben es liefern muß, ist es relativ einfach, die Aufgaben den Eingaben zuzuordnen und daraus die Anweisungsfolgen zu ermitteln.
Falls die Eingaben den Ausgaben nicht direkt zuordnungsbar sind, wird ein Zwischendatenbereich kreiert, indem die Ein-/Ausgaben auf ihren kleinsten gemeinsamen Nenner reduziert werden. Die zerlegten Eingabe-Daten werden von einem Eingabe-Modul dort abgelegt und von einem Ausgabe-Modul abgeholt, um daraus neue Dateneinheiten zu bilden. Dabei steuert der Ausgabe-Modul den Eingabe-Modul oder umgekehrt. Jackson
nennt dies Programminversion.