Wenn vom "Pseudo-Code" die Rede ist, geht es meist um Programmablaufpläne oder sonstige sehr programmnahe Dokumentation. Der Name selbst deutet schon auf die DV-Technik, sprich: Codierung von Programmen hin. Das Ziel dieser Arbeit ist es aufzuzeigen, wie sich die Darstellungsweise "Pseudo-Code" so anpassen läßt, daß man damit ganz allgemein die Ablauflogik von beliebigen Systemen beschreiben kann, ohne dabei sofort an eine DV-technische Realisierung denken zu müssen.

Unterstellt sei ein - etwa in einem Betrieb auftretender - Bedarf, irgendwelche Abläufe zwar in natürlicher Sprache, aber doch strukturiert zu dokumentieren. Durch den von uns entwickelten angepaßten Pseudo-Code erhält die allgemein übliche verbale Darstellungsweise einen Rahmen, der diesen Anforderungen entspricht und nur noch strukturierte Abläufe zuläßt. Diese Behauptung soll im folgenden nachgewiesen werden.

Dabei wird zunächst detailliert die abgewandelte Pseudocode-Version in ihrer Darstellungstechnik behandelt; sodann kommt es zu drei Vergleichsbetrachtungen (Pseudo-Code: Ablaufdiagramm/Struktogramm/Entscheidungstabelle), denen sich ein konkretes Pseudocode-Anwendungsbeispiel anschließt. Will man die technische Darstellung mittels Pseudo-Code beschreiben, so bedarf es zunächst einer Auflistung der vorhandenen Ablaufstrukturbausteine. Im einzelnen sind dies:

- Sequenz

SD 100

"Bezeichnung und/oder verbale Beschreibung der Funktion(en)"

SD 101

"Bezeichnung und/oder verbale Beschreibung der Funktion(en)"

SA 103

"Bezeichnung des Aggregats"

SD 104

"Bezeichnung und/oder verbale Beschreibung der Funktion(en)"

- If-Then-Else

IF 200

"Beschreibung der Bedingung"

TH 200

SD 201 "Bezeichnung und/oder verbale Beschreibung"

EL 200

SD 202 "Bezeichnung und/oder verbale Beschreibung"

EI 200

- If-Do

IF 300 "Beschreibung der Bedingung"

DO 300

SD 301 "Bezeichnung und/oder verbale Beschreibung"

EI 300

- Case-i

CA 400 "Beschreibung der allgemeinen Bedingung"

CA 400-1 "Beschreibung der speziellen Bedingungsausprägung von Fall 1"

SD 401 "Bezeichnung und/oder verbale Beschreibung"

CA 400-2 "Beschreibung der speziellen Bedingungsausprägung von Falle 2"

SD 402 "Bezeichnung und/oder verbale Beschreibung"

CA 400-3 "Beschreibung der speziellen Bedingungsausprägung von Fall 3"

SD 410 "Bezeichnung und/oder verbale Beschreibung"

EC 400

- While-Do

WH 500 "Bedingungsbeschreibung für das Fortsetzen der Schleife"

DO 500

SD 510 "Bezeichnung und/oder verbale Beschreibung"

EW 500

- Repeat-Until

RE 600

SD 620 "Bezeichnung und/oder verbale Beschreibung"

UN 600 "Bedingungsbeschreibung für das Verlassen der Schleife"

ER 600

- Break

BE 700

SV 720 "Bezeichnung und/oder verbale Beschreibung"

BR 700 "Bedingungsbeschreibung für das Verlassen der Schleife"

SD 726 "Bezeichnung und/oder verbale Beschreibung"

EB 700

XX 999-Symbolik

Zur Darstellung und Identifikation der Ablaufbausteine wird eine Symbolik nach dem Muster "XX 999" benutzt. Das XX-Element kommt dabei folgendermaßen zustande:

Sequenz

SD = Sequenz-Baustein, in dem die Funktion(en) im Detail dargestellt werden.

SA = Sequenz-Baustein, als Aggregat von Funktionen, das an anderer Stellte detailliert dargestellt wird.

If-Then-Else oder If-Do

IF = Beginn eines "If-Then-Else" oder eines "If-Do"-Ablaufbausteins

TH = THEN, ,Beginn der auszuführenden Funktionen im "If-Then-Else"-Baustein, wenn die Bedingung zutrifft.

EL = ELSE, Beginn der auszuführenden Funktionen im "If-Then-Else"-Baustein, wenn die Bedingung nicht zutrifft.

DO = Beginn der auszuführenden Funktionen im "If-Do"-Baustein, wenn die Bedingung zutrifft.

EI = ENDIF, Ende eines "If-Then-Else" oder eines "If-Do"-Bausteins.

Case

CA = CASEENTRY oder CASE, Beginn des gesamten oder der einzelnen Fälle des "Case-i" Bausteins

EC = ENDCASE, Ende des gesamten "Case-i"-Bausteins

While-Do

WH = WHILE, Beginn des "WHILEDO"-Bausteins

DO = Beginn der auszuführenden Funktionen im "While-Do" Baustein, wenn die Bedingung zutrifft.

EW = ENDWHILE, Ende des "While-Do "-Bausteins

Repeat-Until

RE = REPEAT, Beginn des "Repeat-Until"-Bausteins

UN = UNTIL, kennzeichnet die Beschreibung der Bedingung, bei deren Erfüllung der "Repeat-Until"-Baustein verlassen wird.

ER= ENDREPEAT, Ende des "Repeat-Until"-Bausteins

Break

BE = BREAKENTRY, Beginn des "Break"-Bausteins

BR = BREAK, kennzeichnet die Beschreibung der Bedingung bei deren Erfüllung der "Break" Baustein verlassen wird.

EB = ENDBREAK, Ende des "Break " -Bausteins

Die dreistellige Nummer der Symbolik identifiziert jeden Ablaufbaustein. Sie wird fortlaufend über den ganzen Ablaufplan für jeden Ablaufbaustein vergeben. Sie kann, muß jedoch nicht lückenlos sein. Obwohl im Beispiel eine dreistellige Nummer benutzt wird, ist die Stellenzahl ohne weiteres entsprechend dem Umfang eines Systems variierbar.

Systemablauf in Bausteinen und Sequenz-Bausteinen

Für den Systemablauf im Pseudo-Code gelten folgende allgemeine Regeln:

- Der Beginn einer Ablaufbeschreibung wird mit

BEGIN "Bezeichnung des Systems", das Ende mit

END dargestellt.

- Ein Aggregat - ein Sequenz-Baustein, der mehrere einzelne Bausteine umfaßt - wird mit

SA 999 "Bezeichnung des Aggregats" dargestellt. Die Aggregierung von einzelnen Bausteinen erfolgt auch folgenden Gründen:

- es handelt sich um eine oder mehrere Funktionen, die mehrfach an verschiedenen Wegen des Ablaufs ausgeführt werden (sogenannte Unterroutinen)

- um die Überschaubarkeit des Ablaufs zu erhöhen, werden nach dem "top-down"-Prinzip logisch zusammengehörende Funktionen schrittweise verfeinert, das heißt, erst als Aggregate dargestellt und dann je nach Komplexität in ein oder mehreren Schritten (= Unteraggregaten) in einzelne Bausteine aufgelöst

- aus Platzgründen, wenn bei der Darstellung aufgrund des Einrückens der Raum auf dem Blatt (oder Bildschirm) nicht mehr ausreicht.

- Die Beschreibung eines Aggregats hat grundsätzlich mit einem neuen Blatt zu beginnen. Die Seiten, auf denen das Aggregat aufgelöst dargestellt wird, werden mit "Aggregat-Nr./Seitenzahl mit 1 beginnend" numeriert.

- Die Überschrift auf der ersten Seite der Aggregatauflösung lautet:

BEG Aggregat-Nr., von Seite ... "Bezeichnung des Aggregats"

- Das Ende der Aggregatauflösung wird mit

END Aggregat-Nr. dargestellt.

- Seitenüberlauf bei der Darstellung eines Systemablaufs im Pseudo-Code ist innerhalb aller Ablaufstruktur-Bausteine zulässig. Es müssen jedoch auf der, Folgeseite die beim Einrücken erreichten Vertikalen unbedingt eingeholten werden. Damit die Darstellung nicht zu unübersichtlich wird, sollte ein Ablaufstruktur-Baustein nicht über drei Seiten hinausgehen. Vielmehr ist es dann ratsame mehrere in ihn verschachtelte Bausteine zu einem oder mehreren Aggregaten zusammenzufassen und erst innerhalb dieser detailliert darzustellen.

Wenn von Ablaufdiagrammen die Rede ist, so sollen darunter stets strukturierte Diagramme verstanden werden, die auf den von Dijkstra entwickelten Normen basieren. Die Vorzüge dieser Art der Ablaufdarstellung gegenüber der chaotischen sind mittlerweile wohl allgemein anerkannt.

Der Vorteil jeder Art von Diagrammen ist die gute Überschaubarkeit. In der Regel prägt sich dem Menschen eine Zeichnung wesentlich besser ein als ein geschriebener Text. Hinzu kommt noch, daß man mit Diagrammen aufgrund der Traditionen in der DV schon vertraut ist.

Dennoch sind die Vorteile des Pseudo-Codes so gravierend, daß es sich lohnt, den schlechteren optischen Eindruck in Kauf zu nehmen. Im einzelnen sind zu nennen:

a) Schneller Entwurf

Abläufe im Pseudo-Code, beschreiben, spart Zeit beim erstmaligen Entwurf. Selbst wenn Diagramme ohne Lineal und Schablone gezeichnet werden, fällt dieser Zeichenaufwand zusätzlich zum Zeitaufwand für das Beschriften der Symbole an. Beim Pseudo-Code wird sozusagen nur "beschriftet".

b) Erleichterte Pflege und Änderung

Da die Darstellung im Pseudo-Code ausschließlich in natürlicher Sprache erfolgt und die verwendeten Symbole auf jeder gewöhnlichen Schreibmaschinentastatur zu finden sind, kann man sie wie einen normalen Text behandeln.

Einfügungen, Änderungen oder Löschungen werden genauso vorgenommen, wie es zum Beispiel bei einem Brief üblich ist. Die technische Ausführung einer Korrektur übernimmt eine Schreibkraft, im günstigsten Falle unterstützt durch Textautomaten, während der Auftraggeber - beispielsweise ein Systemanalytiker - nur noch durch schriftliche oder mündliche Randbemerkungen die entsprechenden Anweisungen gibt.

c) Abkürzungsfreies Erläutern

Der Pseudo-Code fördert die "kontextfreie Selbsterklärlichkeit" der Dokumentation. Immer wieder muß man feststellen, daß zur Beschriftung von Ablaufdiagrammen überwiegend Abkürzungen benutzt werden. Oft handelt es sich dabei um schwer verständliche Verstümmelungen, die einfach aufgrund des Platzmangels entstehen.

Selbst wenn Diagramme ohne Schablone gezeichnet und hierbei die geometrischen Figuren größenmäßig an die Beschriftung angepaßt werden, lassen sich solche platztechnisch bedingten Abkürzungen nicht immer vermeiden. Der Pseudo-Code hat diese durch die Darstellungstechnik bewirkten Restriktionen nicht. Solange der Papiervorrat (oder auch die Kapazität eines anderen geeigneten Speichermediums) reicht, sind den Funktionsbezeichnungen, -erläuterungen und/oder Hinweisen keine Grenzen gesetzt.

Dies ist nicht zuletzt auch dadurch möglich, daß ein Ablaufstrukturbaustein gleich welchen Typs im Pseudo-Code über mehrere Seiten hinweg beschrieben werden kann. Im Ablaufdiagramm hingegen wäre ein Seitenüberlauf beispielsweise einer "Repeat-Until"-Struktur sehr verwirrend.

d) Kein Entgleisen

Der Pseudo-Code läßt nur strukturierte Abläufe zu. Ein Entgleisen, wie es bei Diagramm vorkommen kann, ist von der Darstellungstechnik her unmöglich.

Pseudo-Code: Struktogramm

Ebenso wie im Ablaufdiagramm werden bei Struktogrammen die Ablauflogik graphisch und die Verarbeitungsfunktionen mittels Text beschrieben. Insofern kommen auch sie der Vorliebe des menschlichen Gehirns für graphische Darstellungen entgegen.

Einschränkend sei vielleicht bemerkt, daß durch die Kompaktheit der Struktogramme der optische Eindruck doch nicht ganz so gut ist wie bei Ablaufdiagrammen. Um so schwerer wiegen deshalb auch gegenüber den Struktogrammen die Vorteile des Pseudo-Codes; denn sie beruhen ja gerade darauf, daß jegliche graphischen Hilfsmittel vermieden werden.

Im einzelnen handelt es sich daher mit Ausnahme von d) auch um die gleichen Sachverhalte, wie sie schon im Vergleich mit dem Ablaufdiagramm dargelegt wurden.

Geht man davon aus, daß zum Erstellen von Entscheidungstabellen vorgedruckte Formulare (oder ein Bildschirmmaskengenerator) verwendet werden, so sind hier wie beim Pseudo-Code keine graphischen Arbeiten nötig. Die unter den Punkten a), b) und c) genannten Vorteile des Pseudo-Codes treffen daher auch für Entscheidungstabellen zu.

Darüber hinaus haben Entscheidungstabellen den Vorzug, daß sie auf Redundanz, Widerspruchsfreiheit und Vollständigkeit geprüft werden können. Was jedoch obigen Punkt d) angeht, so gilt auch für Entscheidungstabellen, daß sie nicht zur Strukturierung eines Ablaufs zwingen.

Schon bei der Darstellung der elementaren Strukturbausteine zeigen sich Schwächen. Sehr geeignet jedoch sind Entscheidungstabellen von ihrer Natur her zur Abbildung der Strukturen "IF-THEN-ELSE", "IF-DO" und "CASE-i". Hervorragendes leisten sie speziell, sobald es um ineinander verschachtelte "IF-THEN-ELSE" oder "IF-DO" geht und dabei nur wenige Aktionen auszuführen sind.

Betrachtet man hingegen die Darstellung der Strukturen "WHILE-DO", "REPEAT-UNTIL", "BREAK" oder gar der "SEQUENZ", so wird hierbei die Technik der Entscheidungstabellen vergewaltigt. Wenn man sich daher auf die Fälle beschränkt, in denen Entscheidungstabellen unbestreitbare Vorzüge haben so lassen sie sich sehr wirkungsvoll mit dem Pseudo-Code kombinieren.

Ohne Zweifel sind ineinander verschachtelte "IF-THEN-ELSE"- und "IF-DO"-Strukturen besonders bei drei und mehr Verschachtelungsstufen im Pseudo-Code etwas umständlich zu handhaben. Die Lösung lautet:

- Zusammenfassung der verschachtelten Strukturen zu einem Aggregat.

- Darstellung des Aggregates als strukturierte Entscheidungstabelle bei Beachtung der für Aggregate geltenden Regeln. Auf diese Weise entsteht ein Dokumentationswerkzeug, das alle Vorteile in sich vereinigt.

Manuell, flexibel und minutiös

Das unten gezeigte Anwendungsbeispiel entstammt einem System zur Verkaufsabrechnung, genauer: dem Arbeitsgebiet "Tägliche Verkaufsabrechnung/Auftragsbearbeitung" und hier wiederum dem Erfassen neuer Aufträge. Das Unternehmen, in welchem die Systementwicklung durchgeführt wurde, verfügt über einen Computer der MDT. Bisher werden keinerlei maschinengestützte Software-Werkzeuge zur Systementwicklung eingesetzt. Es ist auch in näherer Zukunft nur manuell möglich zu dokumentieren.

Die Methode des Pseudo-Codes wurde mit der Entwicklung des obengenannten Systems in diesem Unternehmen erstmalig angewandt. Zuvor hatte man noch nie Erfahrungen mit vergleichbaren Methoden gemacht. Abgesehen von einigen Notizen und Satzbeschreibungen von Dateien existierten als Dokumentation nur die Kompilierlisten.

Der Pseudo-Code hat sich in der hier beschriebenen Form als sehr flexibel erwiesen. Ursprünglich sollte er nur zur Dokumentation in der Systemanalyse und Phase des logischen Systemdesigns dienen. Es zeigte sich jedoch, daß er bei Bedarf auch so detailliert werden konnte, daß für Teilmoduln minutiöse, die DV-Technik einschließende Programmablaufpläne entstanden.

-----------------------------------------------------------------------------------------------------------------------

BEGIN Dok.-Nr./Seite

"Erfassen der Auftragskopfdaten (Modul B21)" B21

1

RE 001

CA 004

"Die gewünschte Option ist:"

CA 004"-1

"Prüfen der erfaßten Daten"

SA 003

"Prüfen der Auftragskopfdaten"

CA 004-2

"Erfassen von Auftragspositionen"

IF 006

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

TH 006

SD 007

"Übergang zum Modul B22 "Erfassen der Auftragspositionen" "

EL 006

SD 008

"Fehlermeldung: "Zu diesem Auftrag fehlen die Auftragskopfdaten"

EL 006

CA 004-3

"Erfassen von Auftragskommentaren"

IF 006

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

TH 009

SD 010

"Übergang zum Modul B95 "Erfassen des Kommentartyps" "

EL 009 Dok.-Nr./Seite

SD 011 B21

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

El 009

CA 004-4

"Nächster Auftrag"

SA 013

"Abschließende Prüfung des zuletzt erfaßten Auftrags"

CA 004-5

"Ende der Auftragserfassung und Rückkehr zum Menü:

"Erfassen neuer Aufträge" "

SA 013

"Abschließende Prüfung des zuletzt erfaßten Auftrags"

CA 004-6

"Die ausgewählte Option ist ungültig"

SD 016

"Fehlermeldung: "Die ausgewählte Option ist ungültig" "

EC 004

UN 001

"Es liegt keine Fehlermeldung vor und die ausgewählte Option ist nicht "Prüfen der erfaßten Daten" "

ER 001

END

--------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------

BEG 003, von Seite 1 Dok.-Nr./Seite

"Prüfen der Auftragskopfdaten" B21

CA 020 003/1

"Der aktuelle Auftrag ist:"

CA 021

"Von einem registrierten Kunden"

SA 022

"Prüfen Kopfdaten eines Auftrags von einem registrierten Kunden"

CA 020-2

"Für einen Barverkauf"

SA 023

"Prüfen Daten eines Auftragskopfes für einen Barverkauf"

CA 020-3

"Ein interner Auftrag von einer der firmeneigenen Verkaufsniederlassungen"

SA 024

"Prüfen Kopfdaten eines Auftrags von einer Verkaufsniederlassung"

EC 020

END 003

-----------------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------------

BEG 013, von Seite 2 Dok.-Nr./Seite

"Abschließende Prüfung des zuletzt erfaßten Auftrags" B21

013/1

IF 030

"Die Auftragskopfdaten und die Daten zumindest einer Artikelposition des zuletzt erfaßten Auftrags sind korrekt"

DO 030

SD 031

"Übernehmen des neuen Auftrags in den Auftragsbestand"

El 030

END 013

-----------------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------------

BEG 022, von Seite 003/1 Dok.-Nr./Seite

"Prüfen Kopfdaten eines Auftrags von einem registrierten B21

Kunden" 022/1

SA 040

"Prüfen Daten von "Firmenkennzeichen" bis "Priorität" "

IF 041

"Die Daten vom "Firmenkennzeichen bis Priorität" sind korrekt"

DO 041

IF 043

"Der Ident des Kunden (= Firmenkennzeichen und Kunden-Nr.) existiert im Kundenstamm und ist nicht gesperrt"

---------------------------------------------------------------------------------------------------------------------

So viel Dokumentation wie nötig - so wenig wie möglich

DÜSSELDORF (je) - Bedauerlicherweise behandeln die in der COMPUTERWOCHE publizierten Beiträge über Software-Engineering meist Werkzeuge, die nur für EDV-Benutzer mit Groß- und Größtcomputern in Frage kommen. Diese Auffassung vertritt Diplom-Kaufmann Louis O. Wies, der bei der Düsseldorfer Henkel KGaA in der ZR-Planung und -Kontrolle tätig, aber auch mit dem Rechnungswesen und der Systemberatung für verbundene Unternehmen beschäftigt ist. In der zurückliegenden fünf Jahren war Wies vornehmlich mit der Betreuung und Beratung von Erstanwendern befaßt, die MTD-Anlagen einsetzen (wollten). Dies Anwenderkreis - so Wies´ Erfahrung - steht regelmäßig vor dem Problem, trotz (nicht nur personell) dürftig ausgestatteter EDV-Abteilungen so etwas wie ein Software-Entwickslungssystem zu benötigen Abhilfe in dieser Situation schafft nach Wies´ Überzeugung ein System, das die Devise "So viel Dokumentation wie nötig, doch so wenig wie möglich" beherzigt und eine abgewandelte Form des bekannten Pseudocodes zur Basis hat. Wies versteht den von ihm verfaßten Beitrag gewissermaßen als Initialzündung für eine Diskussion über dieses und ähnliche Konzepte. Vielleicht, meint er, beteiligt sich an ihr ein größerer Kreis von Kollegen, die über vergleichbare Erfahrungen verfügen.