Eine oft vergessene Dimension bei der Softwareentwicklung ist die Dynamik. Deshalb muß ein SW-Modell diesen Aspekt eines Produktes herausstellen und den chronologischen Ablauf der Funktionen aufzeigen. Die kritische Phase der Softwareentwicklung ist der Entwurf: Nach der Ursachenverteilung der Fehler in fertigen Systemen entfallen mehr als zwei Drittel der "Macken" auf diesen Bereich.

Die grafischen Darstellungen zur Visualisierung der Softwarekonstruktion beschränkten sich bei den klassischen Strukturen auf die Abbildung der Systemhierarchie. Und weil ein Softwareprodukt ausschließlich durch seine Dokumentation überhaupt "anwesend" ist, verleugnet die klassische Softwaretechnik den dynamischen Aspekt eines Softwaresystems bei grafischen Abbildungen (Ablauflogik als zeitliche Begrenzung der Funktionen) mit einer schier unglaublichen Vehemenz.

Umgekehrt respektieren die Konstruktionsgrafiken für dynamische Strukturen die hierarchischen Grundsätze auf ihre Weise für Topdown- und Outside-in-Abbildungen. Die Tatsache nämlich, daß beide Strukturen, die für den dynamischen Ablauf und die für die statische Hierarchie, eine gemeinsame Komponente haben, macht die folgende Betrachtungsweise möglich:

Beide Konstruktionsgrafiken, die der Systemhierarchie und die der Ablauflogik, verwenden als gemeinsame Komponente die Funktionsspezifikation. Auf diese Weise läßt sich ein Softwareprodukt als dreidimensionales Gebilde begreifen, in welchem die Dimensionen funktionale Breite, hierarchische Höhe und dynamische Tiefe enthalten sind.

Ohne die Konstruktionsgrafik für den dynamischen Aspekt ist Software als geozentrisches System dokumentiert, bestehend aus Funktionen in einer hierarchischen Baumstruktur. Wenn es darum geht, grafische Abbildungen zur besseren Transparenz von Softwareprodukten zu nutzen, dann bieten sich diese für Ansicht und Grundriß in der Weise an, wie der Architekt einen Baukörper zeichnet.

Wird nun ein Software-Werkzeug eingesetzt, das aus diesen Konstruktionsgrafiken automatisch ablauffähige Programme herstellt, dann sind die verbalen Strukturanweisungen ein für allemal zu vergessen.

Durch die so erreichte imense Transparenzsteigerung ergibt sich gerade in komplexen Systemen Autorenunabhängigkeit sowie Zuverlässigkeit in einem bisher unbekannten Maße. Werden zudem noch aus der bereits geschilderten menschenverständlichen, tabellarischen Spezifikation die Verarbeitungsfunktionen maschinell erzeugt, dann ist sicher der Weg aus der Softwarekrise gefunden.

Die beschriebene dreidimensionale Betrachtung eines Softwareproduktes verleiht sogar dem Begriff Softwaremodell plötzlich die ihm zukommende Bedeutung: Während der Architekt für ein komplexes Gebäude neben Ansicht und Grundriß ein Modell fertigt, welches die statische Zusammensetzung veranschaulicht, tun die Software-lngenieure dasselbe - allerdings für den dynamischen Ablauf. Denn gute Software-Werkzeuge, welche die Konstruktionsgrafiken in die Ablauflogik übersetzen, verfügen über Komponenten, die Funktions-Dummies erzeugen.

Gepaart mit Funktionsmasken im Dialogsystem, liefern diese Werkzeuge frühzeitige Erkenntnisse über die Dynamik komplexer Systeme, indem sie den Ablauf chronologisch ausführen. Dabei ist es wichtig, daß solche Werkzeuge Quellcode erzeugen, der in dieser Form Bestandteil des realen Produktes bleibt. Denn im Zeitalter des modernen Software-Engineering darf man erwarten, daß das einmal Konstruierte nicht noch einmal codiert werden muß.

Der richtige Weg läßt sich unter anderem daran erkennen, daß Begriffe wie "Prototyping", die in der Vergangenheit sehr strapaziert worden sind, im Szenario der dreidimensionalen Werkzeuge plötzlich einen Sinn machen.

In diesem Zusammenhang sei ein bekannter Verkaufsrepräsentant eines Softwarehauses zitiert, der kürzlich auf einer Veranstaltung den Ausspruch tat: "Sie können nicht einmal richtig strukturieren, da wollen sie schon Prototyping machen." Der Vertreter eines anderen Unternehmens meinte: "Prototyping ist ein gefährliches Konzept, denn es führt zu Schnellschüssen, die im Software-Entwurf eher Probleme machen."

Beide Aussagen zeugen davon, daß nicht vom gleichen Verständnis für Prototyping ausgegangen wird. Das Traurige daran ist, daß ein für die Softwaretechnik so bedeutsamer Begriff wie Prototyping aus Marketing-Gesichtspunkten absurd definiert, von der Zielgruppe falsch interpretiert und deshalb letztlich diskriminiert wird.

Nach dem allgemeinen Verständnis ist ein Prototyp etwas, was als Vorläufer existiert und mehr oder weniger geändert in Serie produziert werden soll. Software geht aber nicht in Serie. Vielleicht wäre es deshalb angebracht gewesen, den Begriff Prototyp nicht in das Glossar der Softwaretechnologie einzubringen.

Trotzdem gibt es einen gemeinsamen Nenner: Prototyping zielt in jedem Falle darauf, das konstruierte Produkt unter Praxisbedingungen zu erproben. Deshalb ist es richtig, ein Software-Werkzeug als Prototyping-Werkzeug zu bezeichnen, wenn es in der Lage ist, das durch Konstruktionsgrafiken repräsentierte Softwareprodukt unter Weglassen des Vorgangs der Realisierung in praxisähnlicher Umgebung auszuführen.

Diese Definition führt allerdings die meisten sogenannten "Prototyping-Werkzeuge" ad absurdum. Da sind die Maskengeneratoren, die Werkzeuge, welche die Maskenfolge in Dialogsystemen nur trivial ausführen können (vorhergehende Masken - nachfolgende Masken) und schließlich gibt es die Tools, die eine Maskenfolge nur simulieren, ohne die Funktionen der Maskenverarbeitung zu berücksichtigen - alles Spielzeug für die Kinder der Informatik.

Software-Prototyping erhält ohnehin nur dann einen Sinn, wenn es untrennbar mit der Modelltechnik verbunden ist. Denn Modelle haben zum Ziel, die dritte Dimension zusammen mit der ersten und der zweiten plastisch darzustellen. Wenn bei einem komplexen Baukörper die zweidimensionalen Konstruktionsgrafiken Ansicht und Grundriß nicht ausreichen, die Verständigung zwischen Auftraggeber und Auftragnehmer herbeizuführen, dann ist der Architekt aufgefordert, ein Modell seiner Pläne anzufertigen.

Chronologischer Ablauf ist zu dokumentieren

Die dritte Dimension beim Software-Bau ist die Dynamik. Deshalb hat ein Software-Modell den dynamischen Aspekt eines Softwareproduktes herauszustellen - also den chronologischen Ablauf der Funktionen. Dementsprechend müssen Software-Modelle dokumentiert sein. Es hilft also gar nichts, wenn Systemhierarchie und Systemfunktionen beschrieben werden und die grafische Abbildung der dritten Dimension - der chronologische Ablauf - unterschlagen ist.

Auch nutzt es nichts, wenn man die logische Struktur durch Sprachen verbal durch Pseudocode, Programmcode oder sonst irgendwie beschreibt, weil so der Teil der Realisierung vor den Part der Planung gestellt würde.

Konstruktionsgrafiken, welche die ablauflogische Dynamik eines Softwareproduktes repräsentieren, sind geeignet, die Lösungen autorenunabhängig zu machen. Denn die Geschwindigkeit, mit der sich ein Nichtautor ein Bild von dem gelösten Problem macht, bestimmt die Schnelligkeit seines Handelns. Diese Geschwindigkeit ist bei grafischen Darstellungen um ein Vielfaches höher, als bei verbalen Beschreibungen.

Final-Prototyp stellt konkretes Produkt dar

Werden die Charakterzüge der typischen Aufgabenstellungen des Software-Engineering herausgearbeitet und daraus Problemklassen definiert, dann lassen sich die Software-Modelle dafür in einer Modellbank ablegen. Man braucht dann dem Computer nur noch die Anforderungsspezifikation verständlich zu machen, um so den Software-Entwurf maschinell zu erzeugen. Da dies nur der Entwurf eines "ersten Prototyps" sein kann, sind spezielle Techniken nötig, um diesen Prototyp so lange zu bearbeiten, bis der Final-Prototyp entstanden ist. Der Final-Prototyp stellt gleichzeitig das konkrete Produkt dar.

Durch das Aufschließen der Tür zum Software-Modell eröffnen sich ungeahnte Möglichkeiten einer neuen Software-Technologie. So gewinnt man zunächst einmal die Technik des "automated Software-Design", weiterhin die Technik des "konsistenten Prototyping" (die schrittweise Verfeinerung vom Prototyp zum Produkt) und schließlich noch eine Technik, welche als "Software-Recycling" zu verstehen ist. Denn eine mit den geschilderten Konstruktionsgrafiken realisierte Lösung, liefert gleichzeitig "Stoff" für eine ähnliche andere Lösung.

Die technischen Möglichkeiten der neuen Software-Engineering-Werkzeuge wird nur derjenige nutzen, der sie in der Praxis gebrauchen kann. In der Vergangenheit ließ sich oft feststellen, daß Theorie und Praxis so weit auseinander lagen, daß der eigentliche Effekt, den SW-Entwicklungsprozeß maßgeblich zu verbessern und zu rationalisieren, ausblieb.

Typische Aufgabenklassen müssen bestimmt werden

Die Frage ist also: Können die hier beschriebenen Techniken in der Praxis nutzbar eingesetzt werden? Um diese Frage abschließend zu beantworten, ist es nötig, die typischen Aufgabenklassen kommerzieller Anwendungen zu bestimmen, so wie es bereits bei der Modellbank erwähnt wurde.

Zunächst lassen sich die beiden großen Bereiche Batch- und Dialog-Anwendungen unterscheiden. Und da die binäre Auflösung bei der bisherigen Betrachtung der Software-Produktions-Umgebung nützliche Hilfen gewährt hat, sollte dieses Prinzip auch weiter beibehalten werden.

So unterscheidet man zunächst bei den Batch-Anwendungen die Klasse der Aufgaben zur Verarbeitung von sequentiellen Dateien nach Satzgruppen (auch normierte Programmierung genannt) und die Batch-Anwendungen, die nicht zur ersten Klasse zugerechnet werden können.

Bei den Dialog-Anwendungen sind grundsätzlich zwei Aufgabenklassen zu differenzieren: die Klasse der Retrieval-Systeme (die nicht vom Informations-Center direkt gelöst werden) und die Aufgabenklasse zur Aktualisierung permanenter Datenbestände (die Update-Systeme).

Man kann sich nun unschwer vorstellen, daß die chronologische Abfolge der Funktionen in einer Batch-Anwendung mit den geschilderten Konstruktionsgrafiken ohne Einschränkungen darstellbar ist. Bei der Betrachtung der Dialog-Anwendungen muß allerdings festgestellt werden, daß hier restriktive Techniken in den Transaktions-Monitoren enthalten sind, welche die Anwendung der Konstruktionsgrafiken nicht so ohne weiteres zulassen.

Lösungen von "gestern" wirken als Hemmschuh

Weil aber Dialog-Anwendungen künftig den größeren Teil der Aufgabenstellungen ausmachen, müssen neue Software-Engineering-Werkzeuge gerade hierfür besonders gut geeignet sein. Es wäre fatal, neue Techniken zu präsentieren, die nur für die Aufgabenstellungen von gestern geeignet sind, so, wie das bei der Jackson-strukturierten Programmierung früher der Fall war.

Allerdings wäre es genauso fatal, wenn moderne Software-Engineering-Werkzeuge eine Verbeugung vor dem "Gesslerhut" der Transaktionssysteme machen würden, so, wie das ganze Völkerstämme von Software-Entwicklern in der täglichen Praxis tun müssen. Es ist doch ein Milliarden von Mark teures Mißverständnis zwischen Hersteller und Anwender, wenn hier die technischen Voraussetzungen dafür fehlen, eine komplexe Dialog-Anwendung genauso chronologisch und modular zu entwickeln, wie dies für Batchaufgaben möglich ist.

Nach der Ursachenverteilung der Fehler in Software-Systemen entfallen mehr als zwei Drittel auf den Software-Entwurf. Einen großen Anteil daran haben diejenigen Entwurfsfehler, die auf die technischen Restriktionen der Transaktionssysteme zurückzuführen sind.