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.

26.02.1982

Die "XX-999-Symbolik" ein syntaktischer Fehltritt?

Vom methodischen Aspekt her betrachtet zeigt der Artikel von Herrn Wies an einem praktischen Beispiel in klarer Form, wie Pseudocode als vollwertiger Ersatz für Datenflußpläne in der Dokumentation eingesetzt werden kann. Die Argumente für die Anwendung von Pseudocode sind sauber zusammengetragen und überzeugend präsentiert. Auch die Entscheidungstabellentechnik wurde in durchaus treffender Form in die Überlegungen eingebunden. Im Prinzip stimme ich mit Herrn Wies, was die Anwendung von Pseudocode anbelangt. vollständig überein. Aber tun wir das denn eigentlich nicht alle? Die Unterschiede beginnen zweifellos in der Ausgestaltung der Syntax und hier muß ich widersprechen.

Die Strukturierte Programmierung soll den Ablauf lesbar und übersichtlich präsentieren, und dies gilt auch für die Schlüsselwörter, die benutzt werden, um den Text zu strukturieren.

Die XX-999-Symbolik kann diesem Wunsch nach Lesbarkeit nicht - gerecht werden. Es ist nicht einzusehen, daß CASE durch das Kürzel CA ersetzt werden soll, und kaum jemand wird hinter dem Buchstabenpaar RE die Anweisung zu einer Wiederholungsschleife vermuten. (Dies gilt übrigens auch für die von Jackson erfundene Wortamputation ITR für eine Iteration.) Die Anweisung DO zur Delimitierung einer IF-Bedingung ist völlig redundant und sollte entfernt werden.

Fundierter Syntaxvorschlag

Ich glaube, es ist durchaus zuzumuten, anstelle von WH "while" zu schreiben, denn gerade bei Dokumentationen haben wir es mit dem sogenannten Casual User zu tun, einem Anwender, der also gelegentlich und nicht als Hauptberuf solche Dokumentation liest. Für diesen ist es außerordentlich mühsam, sich durch die (im übrigen sehr übersichtliche) Beschreibung durchzuarbeiten und gleichzeitig in der linken Hand die Übersetzung von 18 verschiedenen Doppelbuchstaben zu haben.

Die 999-Notation

Über die Verwendung dreistelliger Nummern anstelle von aussagefähigen Namen sollten wir seit der Entwicklung symbolischer Assembler hinausgewachsen sein. Ich lehne solche Ansätze in allen Fällen ab, weil sie keinerlei Bezug zum beschriebenen Objekt haben, schwer zu warten sind und uns vom Sinn des Pseudocode, der Lesbarkeit, wegführen. Auch hier stelle ich übrigens eine verblüffende Parallele zu der mißglückten Konstruktion in der Schematic Logic von Jackson fest, in der mit der Anweisung DO999 auf eine numerierte Operationenliste verwiesen wird.

Mein Syntaxvorschlag für Pseudocode und Strukturierte Programmierung basiert auf weit verbreiteten Konventionen und auf einer längeren praktischen Erprobung sowohl für Dokumentationszwecke als auch für die Programmierung.

Die Sequenz = Einmalschleife

Eine Sequenz ist syntaktisch am zweckmäßigsten als Einmalschleife definiert. Herr Raysz von der Tübinger Integrata GmbH hat einmal in der COMPUTERWOCHE in einem Artikel überzeugend dargelegt, daß man Programme auch statisch lesen und konstruieren kann.

DO Offene Posenverarbeitung.

...

...

END Offene Postenverarbeitung.

Diese Sequenz könnte später durch Anfügen einer Ausführungsbedingung zu einer Schleife erweitert werden. Statisch gelesen hingegen sieht man, daß es sich um eine Verarbeitung der offenen Posten handelt.

Auswahl

Die 1:1-Auswahl kontrolliert eine Grupe von Aktionen aufgrund einer Bedingung.

IF Bedingung erfüllt.

...

...

END.

Die Bedingung wird in allen Fällen durch einen Punkt abgeschlossen auf den in der gleichen Zeile keine weiteren Angaben mehr folgen. Dadurch ist auch die Bedingung eindeutig erkennbar. Ferner werden die nachfolgenden Aktionen eingerückt, so daß auch optisch der Unterschied zwischen Bedingung und Maßnahme erkennbar bleibt, auch dann, wenn die Bedingung sich über mehrere Zeilen erstreckt.

Die 1:2-Auswahl

IF Bedingungerfällt.

...

...

ELSE

...

...

END

Die 1:n-Auswahl - das SELECT-Konstrukt

Hier werden n-Maßnahmen aufgrund einer (erweiterten) Bedingung angesteuert.

SELECT Bedingungsrumpf.

...

CASE Bedingungsrumpf.

...

ELSE.

...

END.

Die m:n-Auswahl - die Entscheidungstabelle

Die Entscheidungstabelle dient dazu, m-Bedingungen mit n-Maßnahmen in komplexer Weise zu verknüpfen.

Die Wiederholung

Das Grundkonstrukt der Wiederholung besteht aus:

DO Name Ausführungsbedingungen.

...

END Name.

Wie wir sehen, handelt es sich also um eine Sequenz, eine Gruppierung von Anweisungen, ergänzt um die Angabe, wie oft (Ausführungsbedingung) diese Sequenz durchzuführen ist. Bei den Ausführungsbedingungen unterscheiden wir:

While-Bedingung (kopfgesteuerte Schleife, Solange-Schleife) und Until-Bedingung (fußgesteuerte Schleife, Bis-Schleife).

Einen Sonderfall nimmt die Zählschleife ein, bei der das gleichzeitige Mitzählen eines Index' veranlaßt wird:

DO Verarbeitung VAPY INDEX FROM EXPR1 BY EXPR2 TO/DOWN-TO EXPR3

EXPR 1 - 3 sind beliebige mathematische Ausdrücke, die die Startbedingung, das Increment und die Ende-Bedingung angeben. Wir unterscheiden in unserer Aussage zwischen TO, das heißt, einer Schleife, bei der das Increment addiert wird und einer rückwärts laufenden Schleife DOWN TO, bei der das Increment subtrahiert wird. Auch hier kommt besonders augenfällig zum Ausdruck, daß auf Lesbarkeit geachtet werden muß und die Tatsache des Rückwärtslaufens einer Schleife nicht in einem negativen Vorzeichen des Increments versteckt werden sollte.

Die Abbruchsteuerung

Durch die Anweisung

QUIT Name

kann eine beliebig höhere Sequenz oder Schleife verlassen (quit) werden. In der Regel wird eine solche Quit-Anweisung in eine Bedingung

eingebettet sein:

DO Verarbeitung WHILE.......

...

IF Bedingung erfüllt.

<- QUIT Verarbeitung.

END

...

END Verarbeitung

Mit dieser Form der Quit-Anweisung kann aus einer tiefen Verschachtelungsstufe bei Auftreten eines Fehlers der Abbruch der Verarbeitung veranlaßt werden. Sie vermeidet insbesondere die häufig mit falscher Interpretation der Strukturierten Programmierung vorgenommene Lösung, bei der ein Schalter (OK-Switch) über sämtliche Stufen von Schleifen bis ganz nach unten mitgeschleppt werden muß, um einen asynchronen Abbruch zu erreichen. Auch hier wird der Lesbarkeit ein Bärendienst erwiesen, indem die Tatsache des asynchronen Abbruchs in Schleifenbedingungen versteckt und nicht explizit durch ein Wort befohlen wird.

Ende-Behandlung von Schleifen

Ein klassisches Problem in der Programmierung - Suchen und abhängig vom Sucherfolg durchzuführende Maßnahmen - hat uns zu einer Ergänzung, zu einem Konstrukt für die Endebehandlung von Schleifen veranlaßt:

Das im folgenden aufgeführte Fallbeispiel entspricht der ersten Pseudocode-Darstellung von Herrn Wies auf Seite 13 der genannten CW-Ausgabe.

SPP-B21 =============================================

0 DO KOPF UNTIL "Es liegt seine Fehlermeldung vor und die

0 ausgewählte Option ist nicht "Prüfen der erfaßten Daten":

1 . SELECT "Die gewünschte Option ist:".

1 . USE "Prüfen der erfaßten Daten".

2 . . PERFORM KOPFRUEF.

1 . CASE "Erfassen von Auftragspositionen".

2 . . IF "Existiert schon ein korrekter Auftragskopf 2 . . für den gegenwärtigen Auftrag".

3 . . . CALL MODUL_B22'.

2 . . ELSE.

3 . . . Fehlermeldung: "Zu diesem Auftrag 3 . . . fehlen die Auftragskopfdaten".

2 . . END.

1 . CASE "Erfassen von Auftragskommentaren".

2 . . IF "Existiert schon ein korrekter

2 . . Auftragskopf" für den gegenwärtigen

2 . . Auftrag".

3 . . . CALL MODUL_B95'.

2 . . ELSE.

3 . . . Fehlermeldung: "Zu diesem Auftrag 3 . . . fehlen die Auftrugskopfdaten".

2 . . END.

1 . CASE "Nächster Auftrag".

2 . . PERFORM "Abschließende Prüfung des

2 . . zuletzt erfaßten Auftrags".

1 . CASE "Ende der Auftragserfassung und Rückkehr zum Menü".

2 . . "Erfassen neuer Aufträge".

2 . . PERFORM "Abschließende Prüfung des

2 . . zuletzt erfaßten Auftrags".

1 . ELSE.

2 . . "Die ausgewählte Option ist ungültig".

1 . END.

0 END KOPF.

END================================================

Dieses Bild zeigt, daß die Syntax sehr einfach, sehr wenig fehleranfällig und robust ist. Sie eignet sich vorzüglich, um mit sehr geringem Aufwand formatiert zu werden. Ein Text-Formatierer, um aus dieser Syntax die gezeigte Darstellung auszudrucken, ist ein Programm, das in kürzester Frist selbst auf einem Personal Computer zu implementieren ist. Der Einbau einer solchen Routine in ein Dokumentationssystem stellt auf jeden Fall keine größeren Anforderungen an die Programmiertechnik.

Es ist auch kein besonders großer Aufwand, diese Syntax in irgendeine Zielsprache zu übersetzen, wenn man keine größeren Ambitionen bezüglich des generierten Codes hat. Die Schwierigkeiten bei der Implementation eines Werkzeuges beginnen aber, sobald man vernünftiges Fehler-Recovery, das heißt, das Abfangen von Fehlern so früh wie möglich und korrektes Weiterarbeiten, die Unterstützung von Testhilfen, die Generierung eines effizienten und übersichtlichen Codes, die Unterstützung von Programminversionen und Programmbausteintechnik und die Kopplung mit anderen Werkzeugen anstrebt.

Gerade dies aber haben wir in unserem "Delta"-Werkzeugsystem gemacht und erreicht: Wir mußten allerdings dabei auch die Erfahrung machen, daß die Integration einer Einzelidee in ein umfassendes Werkzeug sofort zu exponentiell größerem Aufwand führt: Bei den heutigen Möglichkeiten des Software-Engineering bedeutet dies jedoch nicht automatisch, daß diese Werkzeuge auf kleineren Anlagen nicht zur Verfügung stehen können. Wir haben Delta beispielsweise auf den Anlagen Kienzle und Triumph-Adler implementiert, und demnächst steht auch eine Version für den "Onyx" unter dem Unix-Betriebssystem zur Verfügung.

Mit der steigenden Leistungsfähigkeit sogenannter kleinerer Anlagen wird der Anwender solcher Maschinen- mit zunehmender Komplexität konfrontiert und genötigt, die gleichen Techniken der Software-Entwicklung anzuwenden, wie dies in der sogenannten klassischen EDV gemacht wird. Deshalb kann ich den Vorschlag von Herrn Wies, die Strukturierte Programmierung auch unterhalb der Großsysteme anzuwenden, nur voll unterstützen.

*Dr. Reinhold Thurner ist Geschäftsführer der Sodecon AG für Sydem-Entwicklung und Beratung, Bahnhofsplatz 26, CH - 8603 Schwenenbach, Telefon 01/8 25 23 43.