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.

09.06.1978 - 

GES-Trainingspackage "Strukturierte Programmierung" unter Beschuß:

"Unrichtig, unsachlich und nutzlos"

FRANKFURT (de) - "Wer Normierte und Strukturierte Programmierung gegenüberstellt, vergleicht Äpfel und Birnen", wirft der Frankfurter Systemberater Edmund Schwarz der GES Gesellschaft für elektronische Systemforschung mbH (Insel Reichenau) vor. Schwarz hat dabei ein GES-Trainingspackage im Auge, über das die Computerwoche kürzlich berichtete (CW Nr. 20 vom 12. Mai 1978: "Für alle Phasen der Programmierung"). Kritisch setzt sich der Frankfurter mit einer Tabelle auseinander, in der die GES die Vorteile der Strukturierten Programmierung aufgelistet hat (zum besseren Verständnis bilden wir die Vergleichs-Matrix noch einmal ab, d. R.). Hier die Schwarz-Kritik im Wortlaut:

Durch Aufzählung von Merkmalen kann man noch keine Vorteile beweisen. Dies müßte man nicht unbedingt bemängeln, wenn ein objektiver Vergleich zwischen den Merkmalen möglich wäre. Doch der Teufel steckt im Detail, das heißt, in jeder Behauptung zu den einzelnen Schlagworten. Gehen wir sie einzeln durch:

Einsatzgebiet

Die Behauptung über das Einsatzgebiet der Normierten Programmierung ist falsch, denn die Einsatzmöglichkeit wird nicht bestimmt durch die Sachfunktion, sondern durch die Art der Bereitstellung und die Formatierung des zu bearbeitenden Datenbestandes. Die entsprechenden Bedingungen sind eben im kommerziellen Anwendungsbereich sehr häufig gegeben Die Methode selbst ist auch in anderen als kommerziellen Sachgebieten nutzbar.

Voraussetzungen

Die hier gebotenen Aussagen sind unsinnig, denn es geht nicht um Hierarchien, sondern um Zuordnungen. Die Zuordnungen aber werden durch die Bedürfnisse der jeweiligen Sachfunktion bestimmt, was bedeutet, daß von

Verarbeitung zu Verarbeitung (d. h. von Programm zu Programm) bei einem gleichartigen Datenbestand unterschiedliche Zuordnungen möglich sind.

Dateiorganisation

Die aufgestellte Behauptung ist sehr unsachlich, denn aus der sequentiellen Dateiorganisation als Grundbedingung für die Normierte Programmierung läßt sich zwar eine beschränkte Einsatzmöglichkeit, durchaus aber kein Qualitätsmerkmal herleiten.

Programmaufbau

Die Behauptung über den Programmaufbau der Normierten Programmierung ist falsch und unsachlich, denn das Wesen von Standards soll es doch wohl sein, daß sie so oft wie nur möglich wiederverwendet werden können.

Ablaufstrukturen

Aus der Behauptung über die Ablaufstrukturen läßt sich zweifellos ein deutlicher Vorteil der Normierten Programmierung herleiten. Dies gilt um so mehr, als ein normiert gestaltetes Programm zur Verarbeitung sequentieller Dateien auch im Sinne der Strukturierten Programmierung gegliedert werden kann. Dies zeigt als Gegenüberstellung unser Bild.

Programmierstil

Über den Programmierstil bei der Normierten Programmierung wird ebenfalls falsch und unsachlich berichtet, denn man kann die Funktionen der Normierten Programmierung durchaus in der Vorgehensweise der Strukturierten Programmierung gestalten, und solange man es nicht besser weiß oder kann, ist der benutzte lineare Programmierstil als Standard sicherlich nützlich.

Dokumentation

Auch die Aussage über die Dokumentation ist unrichtig. Wenn die Normierte Programmierung standardmäßig eingesetzt wird, dann muß man

nicht ständig aufs neue dokumentieren, sondern nur auf eine allgemeingültige Dokumentation verweisen. Die eigentliche Dokumentation kann dann auf die zu beschreibende Sachfunktion beschränkt werden. Im übrigen neigen Praktiker längst zu der Ansicht, daß Struktogramme vielfach sehr schwer lesbare Dokumentationselemente darstellen.

Voraussetzungen für Programmierer

Wer die Hinweise über die Voraussetzungen liest, muß lachen oder den Unsinn glauben, daß sich hinter der Strukturierten Programmierung ein ganz besonderes theoretisches Niveau verbirgt, das für die Normierte Programmierung nicht gelten würde.

Herkunft

Die Aussage über die Herkunft stellt kein Qualitätsmerkmal dar. Wenn man es aber dennoch so verstehen will, spricht sie für die Normierte Programmierung.

Verbreitung

Hier treibt man werbepsychologische "Mätzchen". Unsere Hardware kommt zu einem erheblichen Teil aus den USA, und auch die dazugehörige Software. Die Normierte Programmierung stammt aus der BRD. Ob die wohl gut sein kann?

Der überwiegende Teil der aufgestellten Behauptungen ist also unrichtig oder unsachlich. Für Theoretiker und Praktiker ist diese Gegenüberstellung von Normierter Programmierung und Strukturierter Programmierung nutzlos, denn... was nutzt es, wenn man Äpfel mit Birnen vergleicht? Sie kann höchstens als schlechtes Beispiel dienen.

Mit der Normierten Programmierung stellt man standardmäßig Gliederung und Codierung zur Erfüllung bestimmter Steuerfunktionen zur Verfügung. Mit Strukturierter Programmierung bietet man allgemeine Empfehlungen und Darstellungsformalismen zur Verknüpfung und Gestaltung von Programmfunktionen. Die Ideen und Ansätze beider Verfahren haben ihre Daseinsberechtigung, und man sollte sich nicht durch Vertriebsinteressen verleiten lassen, Verwirrung zu stiften. Standards können Nutzen bringen, wenn man die Einsatzmöglichkeiten begreift. Das klare Problemverständnis führt dann zum Einsatz der richtigen Mittel und Methoden.