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.

04.05.1979 - 

Vier Grundanforderungen an ein Dialog-Programmiersystem:

Interaktives Programmieren ist , interaktives Problemlösen

Es ist - still geworden um die "Softwarekrise". Aber ob wir daraus schließen können, daß es sie nicht mehr gibt ... ?

Erst in ein paar Jahren werden wir sehen, ob nicht mehr bis zu 80 Prozent der in Produktionsprogrammen gefundenen Fehler aus der Analyse und der Planung stammen - derzeit ist dies noch immer der Fall. Und noch immer wird ein Großteil der für Programmentwicklung aufgewandten Bearbeiter- und Rechnerstunden für den "Programmtest" verbraucht; eine Tätigkeit, die manche Programmierpäpste als überflüssig empfinden, da sie "doch nur das Vorhandensein von Fehlern zeigen können (die sich denn auch in den "selbstverständlich ungetesteten" Beispielprogrammen in den Büchern der nämlichen Päpste leicht finden lassen).

Da mag denn wohl ein leiser Verdacht aufkommen, daß nur einige Symptome der Krise gelindert wurden, bis zur Heilung aber noch einige Zeit verstreichen wird. So wie Johannes der Täufer ziemlich lange ein "Umdenken" fordern mußte, bis wirklich etwas Ernsthaftes passierte, so hat es auch in unserer heutigen Programmierung mit dem Bewußtseinswandel noch seine gute Weile.

Man versteht "Programmierung" weiterhin als Codierung und Test. Man erfindet Regeln, "Konstruktionsverfahren", Methoden und Werkzeuge zur "Strukturierung" des Codes, als wüßte man nicht schon längst, daß strukturierter Unsinn auch Unsinn ist. Man baut Dialog-Programmiersysteme, als ob es nur darum ginge, dem Kodierer auch noch die Ablocharbeit aufzubürden, mit einer "Dialogschnittstelle", die sich vom Kartenlocher nur durch ihre längeren Antwortzeiten und ihre geringere Zuverlässigkeit unterscheidet. Und damit an dem System dann wenigstens irgend etwas interaktiv ist, unterstützt man den, Test nicht über Hilfen zur methodisch sauberen Entwicklung von Testplänen, -daten und -skipten, sondern als Bastelstube für beliebige Eingriffe und Änderungen in das Testobjekt.

Was ist denn wirklich das Problem? Daß Programmieren nichts anderes ist als Problemlösen - in der Praxis das Lösen sehr komplexen und oft sogar zu Beginn nicht oder nur unklar formulierter Probleme.

Das hat zwei Konsequenzen für den Entwickler oder Erwerber eines Dialog-Programmiersystems:

- Das System muß die mechanischen und routinemäßigen Tätigkeiten nicht mühsamer und komplizierter, sondern einfacher, schneller und sicherer machen (dabei sind Bleistift, Papier und Radiergummi bereits ausgesprochen einfach, schnell und sicher zu bedienende Hilfsmittel).

- Das System muß auf natürliche und konsistente Weise alle gegenwärtig benutzten Entwurfs- und Programmierhilfsmittel integrieren, und, wenn möglich, noch einige neue dazubringen.

Beginnen wir mit dem ersten Punkt, der Einfachheit, Sicherheit und Schnelligkeit. Die Sicherheit, auch bei einer Systemstörung die Datenintegrität mindestens bis zum gerade bearbeiteten Satz gewährleisten zu können, ist auf der Grundlage existierender, nicht für die Dialogprogrammierung, sondern für Information-Retrieval gedachter Datenbank- und Bibliothekssysteme zwar zu realisieren, kostet dann aber Zeit und oft auch explizite Sicherungsmaßnahmen von seiten des Benutzers - ein "zusätzliches Problem", als ob seine Programmierproblem nicht schon genug Konzentration erforderten.

Und die Antwortzeiten - die sind ohnehin meist schon an der Grenze des Vertretbaren. Das ist etwa eine Sekunde: Eine ziemlich lange Zeit für einen Menschen (ein durchschnittlicher Autofahrer reagiert auf eine Verkehrssituation in 0,6 Sekunden), aber ziemlich kurz für ein "auf interaktiv getrimmtes" Stapelsystem (vor allem dann, wenn man Reaktion auf jeden einzelnen Tastenanschlag verlangt - die Schrift unseres Bleistiftes ist schließlich auch nicht erst dann "gespeichert", wenn wir eine Zeile vollgeschrieben haben).

Interaktives Programmieren ist eben nicht ein einfaches Frage-Antwort-Spiel zwischen Rechner und Benutzer, wie etwa eine übliche kommerzielle Dialoganwendung. Sondern es ist Unterstützung eines komplexen Prozesses: der Problemlösung. Daß dieser Prozeß nicht auf irgendwelchen Maschinerie sondern im Kopf eines kreativ tätigen Menschen abläuft, macht ihn nicht einfacher oder anspruchsloser - im Gegenteil! Also sollte es selbstverständlich sein, dem produzierenden Menschen zu geben was der industriellen Produktionsanlage längst billig ist - einen eigenen Prozeßrechner, der jedes "Signal", jeden Tastendruck sofort verarbeitet, und dessen Software auf den Problemlösungsprozeß abgestimmt ist, in der Verarbeitung der Signale ebenso wie in der Antwortzeit.

Die zweite der obigen Forderungen war die Unterstützung von Methoden und Werkzeugen. Auch hier sollten wir uns an dem orientieren, was für den Rechnereinsatz bei industriellen Herstellungsprozessen längst selbstverständlich ist: Es gibt nicht nur eine "Produktionsmethode", sondern viele. Ihre Wahl hängt ab vom Produkt (Milch wird anders hergestellt als Autos, und auch Softwareprodukte sind sehr unterschiedlich). Sie hängt ab Aufgaben und Zielen der an der Herstellung beteiligten Mitarbeiter (der Konstrukteur braucht andere Werkzeuge als der Schweißer). Und sie hängt vom "Arbeitsstil" (der Produktionsablauf bei Porsche ist anders organisiert als der bei Opel).

Genauso gibt es viele Methoden und Techniken, die bei der Softwareentwicklung eingesetzt werden und die sich zumindest unter bestimmten Bedingungen bewährt haben. Auf sie zu verzichten, wäre ein Rückschritt.

Die Konsequenz sind vier Grundforderungen an ein interaktives Programmiersystem:

- Es darf den Benutzer nicht auf ein bestimmtes Verfahren oder ein bestimmtes Methodenbündel festlegen.

- Es darf dem Programmentwickler nicht seine bereits eingeführten (Stapel-) Werkzeug nehmen, sondern es muß sie ihm Bildschirmdialog weiterhin in der gewohnten Form zur Verfügung stellen.

- Es muß selbst eine Grunlage für die möglichst einfache Implementierung eines ständig wachsenden Satzes von Hilfen und Werkzeugen bieten, die der Benutzer verwenden kann, aber nicht muß (sicherlich sollte es der Projektleitung möglich sein, über das System bestimmte Vorgehensweisen nahezulegen oder zu erzwingen, aber das darf nie Sache des Herstellers des Programmiersystems sein).

- Es muß auch und vor allem Hilfen für die Wartung und Weiterentwicklung bestehender Programme bieten.

Die obige Anforderungsliste an ein Dialog- Programmiersystem weicht nicht unbeträchtlich von dein ab, was gemeinhin Postuliert wird - teils aus mangelnder Erfahrung in der interaktiven Programmierung, und teils wohl auch auf Grund der Realisierungsschwierigkeiten auf bestehender Großrechner-Hard-, und -Software.

*Karl-Heinz Herrman, ist Marketing-Leiter der Softlab GmbH, München.