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.

22.05.1981 - 

Von problemunabhängigen Datenstrukturen kann keine Programmstruktur abgeleitet werden

Jackson trennt Entwurf und Implementierung

Teil 6

Schachtelungsfreier Code hält alternative Implementierungsformen offen.

Auf der Basis des Strukturtextes kann nun nach unterschiedlichsten Codiertechniken Code in einer beliebigen Programmiersprache erstellt werden. Jackson stellt jedoch eine bestimmte Art der Codierung bereit, die er "schachtelungsfreien Code" nennt.

Dieser Codierstil erlaubt es, die zuvor genannten Implementierungsalternativen voll zu nutzen. Dann kann beispielsweise auch noch nachträglich ein Hauptprogramm nach festen Regeln in ein Unterprogramm überführt werden, wenn dies einmal erforderlich werden sollte.

Schachtelungsfreier Code kann mit geeigneten Software-Werkzeugen automatisch aus Strukturtext erzeugt werden. Voraussetzung ist dann allerdings, daß die Elementaranweisungen des Strukturtextes in der Zielsprache formuliert sind.

Wie werden größere Aufgabenstellungen mittels JSP gelöst?

Bisher wurde lediglich der Entwurf eines einzelnen JSP-Programms nach den grundlegenden Entwurfstechniken dieser Methode betrachtet. Der Entwurf größerer Aufgabenstellungen wird durch bestimmte Zergliederungstechniken auf den Entwurf mehrerer einzelner Programme zurückgeführt.

Das wichtigste Zergliederungskriterium sind hierbei die sogenannten Strukturkonflikte. Sie treten auf, wenn Eingabe- und Ausgabedatenstrukturen nicht "zueinander passen", was bei fast jeder größeren Aufgabenstellung der Fall ist. Hier versagt die JSP jedoch nicht, wie vielfach von selbsternannten "JSP-Experten" behauptet wird, hier zeigt sie vielmehr ihre wirklichen Qualitäten: Für alle Arten von Strukturkonflikten bietet Jackson Standardlösungsschemata an, die zu einer methodischen, eindeutigen und sehr transparenten Zergliederung eines Systems in einzelne Programme führen.

Alle diese Strukturkonflikte sind formal beim Vergleich der Eingabe- mit den Ausgabedatenstrukturen nachweisbar. Die Zergliederung ist damit "egoless" und deshalb in hohem Maße eindeutig und objektiv. Bei korrekter Anwendung der Methode entsteht die eindeutige Zergliederung zwangsläufig .

Leider ist es im Rahmen dieses Beitrages nicht möglich, auf das Erkennen und Lösen von Strukturkonflikten genauer einzugehen, allein schon, weil es nicht Aufgabe oder Ziel des Autors sein kann, an dieser Stelle die komplette JSP darzustellen. Es ist jedoch zu hoffen, daß das Mißverständnis ausgeräumt werden konnte, daß Strukturkonflikte ein Störfaktor bei der Methodenanwendung seien. Strukturkonflikte sind keine Erfindung von Jackson. Er ist jedoch der erste, der beschrieben hat, wie man sie systematisch erkennt und löst.

Größere Aufgabenstellungen werden als Netzwerk von "simple programs" entworfen .

Größere Aufgabenstellungen werden mit Hilfe von Strukturkonflikten und weiteren Kriterien in ein Netzwerk einzelner Programme zergliedert. Jedes dieser Programme wird nach den beschriebenen grundlegenden Entwurfstechniken der JSP entworfen. Wir bezeichnen ein so entworfenes Programm als "simple program".

Ein durch Zergliederung einer Aufgabenstellung entstandenes System von simple programs wird in einem Systemnetzwerkdiagramm (SND) dargestellt. Nehmen wir einmal an, daß unser Programm zum Saldieren von Bewegungsdaten, an dem der Entwurf eines simple program demonstriert wurde, Teil einer größeren Aufgabenstellung ist. Weitere aus der Aufgabenstellung abgeleitete simple programs sind:

Plausi: Plausibilitätsprüfung der Bewegungen

Update: Aktualisieren der Stammdatei

Drucken: Druckaufbereiten der Lagerbestandsdaten .

Der Zusammenhang zwischen diesen simple programs wird durch Bild 10 wiedergegeben.

Ein JSP-Entwurf erlaubt unterschiedliche Implementierungsformen eines Systems.

Das SND von Bild 10 ist einem Datenflußplan nach DIN 66001 sehr ähnlich. Datenströme werden jedoch unabhängig von ihrer späteren Implementierung durch das Kreissymbol repräsentiert. Wie weiter oben angedeutet, bestehen hinsichtlich der Implementierungsmöglichkeiten eines simple program hohe Freiheitsgrade. Entsprechend ist es möglich, Datenströme beispielsweise als physische Dateien, Warteschlangen oder per Parametermechanismus zu übergebende Daten zu implementieren.

Programminversion - eine Codiertechnik zur Transformation von Hauptprogrammen in Unterprogramme.

Eine mögliche Implementierungsform unseres Systems besteht darin, alle vier Programme als Hauptprogramm und alle Datenströme als physische Dateien zu implementieren. Bei einer anderen Implementierungsform würde ein beliebiges Programm des Systems als Hauptprogramm implementiert, die drei übrigen Programme jedoch als Unterprogramme. Wählen wir etwa Update als Hauptprogramm, ergibt sich die in Bild 11 dargestellte Implementierung .

Nun ruft das Hauptprogramm Update das Unterprogramm Saldieren auf, wenn es einen Satz der Saldendatei lesen will. Update ruft Drucken auf, wenn es einen Satz der "Daten für Liste Lagerbestand" schreiben will. Weiter ruft Saldieren Plausi auf, wenn es einen Satz des Datenstroms "Korrekte Bewegungen" lesen will.

Der Datenaustausch erfolgt bei dieser Systemimplementierungsform jedoch nicht mehr über physisch sequentielle Dateien, sondern per Parametermechanismus. Er erfolgt satzweise, wobei pro Unterprogrammaufruf genau ein Satz übergeben wird. Die read- und write-Anweisungen des Entwurfs sind nun durch Unterprogrammaufrufe oder ein besonderes Inversionscoding ersetzt worden. Die Richtung der Datenübergabe ist durch Pfeile angedeutet worden. Sie ist natürlich dieselbe wie in Bild 10.

Grundlegend für die angedeuteten hohen Freiheitsgrade bezüglich verschiedener Implementierungsalternativen ist eine strikte Trennung von Entwurf und Implementierung. Der Entwurf eines simple program ist mit dem Erstellen des Strukturtextes abgeschlossen. Die Überführung eines als Hauptprogramm entworfenen simple program in ein Unterprogramm ist eine mechanisierbare und auch schon durch entsprechende Software-Werkzeuge automatisierte Transformation, bei der keine neuen Entwurfsüberlegungen anzustellen sind.

Haupt- und Unterprogramm erfüllen die gleiche Funktion, haben die gleiche Struktur, die gleichen Elementaranweisungen und basieren auf demselben Strukturtext. Sie unterscheiden sich lediglich durch die Art der Datenübergabe, die zwischen zwei Hauptprogrammen in Form einer physischen Datei, zwischen Haupt- und Unterprogramm satzweise per Parametermechanismus erfolgt.

Die Codiertechnik, die die genannte Transformation vom Hauptprogramm zum Unterprogramm bewirkt, bezeichnet Jackson als "Programminversion". Sie ähnelt der Koroutinentechnik, wie sie beispielsweise von der Programmiersprache Simula her bekannt ist.

JSP unterstützt Entwurf und Implementierung aktueller und zukunftsweisender Systemkonzepte.

Die Implementierungen des Systems von Bild 10 in Form von vier Hauptprogrammen oder einem Hauptprogramm und drei Unterprogrammen sind nur zwei einer großen Menge von Implementierungsalternativen. Sie werden ermöglicht, weil simple programs von vornherein als selbständige Prozesse entworfen werden, die über eigene Anweisungen zur Datenanforderung und zur Datenabgabe verfügen.

Diese Eingabe- und Ausgabeanweisungen müssen jeweils abhängig von der Implementierungsart modifiziert werden. Der Rest des Programms bleibt weitgehend unverändert. Weitere Implementierungsformen, die auf der Basis des vorliegenden Entwurfs möglich wären, sind etwa

þImplementierung auf einem Multiprozessorsystem, bei dem pro single program ein eigener Prozessor zur Verfügung steht; die verschiedenen Prozessoren sind über Datenkanäle miteinander verbunden.

þImplementierung auf einem Prozessor als System paralleler Prozesse, die über Puffer synchronisiert werden.

Bei der vorliegenden Aufgabenstellung erscheinen derartige Systemimplementierungsformen ungewöhnlich, da sie beim heutigen Stand der Hardware- und System-Software-Technik nicht der Regelfall sind.

Es gibt jedoch heute schon in vielen Anwendungsgebieten Aufgabenstellungen, für die die genannten Implementierungsformen von den betrieblichen Anforderungen her angemessen sind. Ein Beispiel ist die zunehmende Zahl der lmplementierung verteilter Systeme (distributed processing). Gerade auch für diese Aufgabenstellungen ist JSP eine angemessene Methode.

Ist JSP auch für den Entwurf von DB- und Dialog-Anwendungsprogrammen geeignet?

Wenn man seine JSP-Kenntnisse nur auf Jacksons Buch Principles of Program Design (erschienen 1975) oder dessen deutsche Übersetzung stützt, kann der Eindruck entstehen, JSP sei für DB- und Dialog-Anwendungen ungeeignet. Entsprechende Beispiele fehlen nämlich. Im folgenden soll ein Anwendungsbeispiel für diesen Bereich vorgestellt werden.

Mit JSP werden DB-Anwendungsprogramme entworfen, keine Datenbanken selbst.

JSP ist eine datenstrukturorientierte Programmentwurfsmethode, keine Datenstrukturierungsmethode. Für die logische oder physische Strukturierung von anwendungsabhängigen Datenbeständen selbst ist JSP deshalb nicht gedacht. Sehr wohl geeignet ist JSP jedoch zum Entwurf von DB-Anwendungsprogrammen. Der in das Programm eingehende Datenstrom von DB-Segmenten oder -Sätzen wird problemspezifisch mit einem JSP-Strukturdiagramm beschrieben und dient so als Grundlage für die Programmstruktur.

Betrachten wir als Beispiel die vereinfachte Beschreibung der Mitarbeiter-Datenbank einer Unternehmung in Bild 12. Dem JSP-Strukturdiagramm legen wir dabei folgende einfache Aufgabenstellung zugrunde: die Datenbank soll gelesen und aufgelistet werden. Wird fortgesetzt.

Was steckt wirklich hinter der Jackson Methode?

Übersicht über die von Wolfgang George gewählten Themenpunkte

Einführung

þWas unterscheidet die verschiedenen in Theorie und Praxis bekannten Datenstrukturbegriffe ?

- Mit dem Datenstrukturbegriff werden grundlegende Konzepte der DatendarstelIung und des Datengebrauchs verbunden.

- Der Datenstrukturbegriff in der "Datenbankwelt".

- In der JSP sind Datenstrukturen der Ausgangspunkt des Programmentwurfs.

- Als Problembeschreibungssprache unterstützen JSP-Strukturdiagramme die Kommunikation zwischen Datenverarbeitungspartnern.

þWie wird die Programmstruktur von den JSP-Datenstrukturen abgeleitet?

- 1:1- Entsprechungen stellen die Verbindung zwischen mehreren Datenstrukturen eines Programms her.

- Die Ableitung der Programmstruktur erfolgt auf der Basis der 1:1-Entsprechungen nach festen Regeln.

- Die Korrektheit einer Programmstruktur bezüglich ihrer Datenstrukturen kann formal überprüft werden.

þWie wird dem Modell {Programmstruktur) eine Funktion zugeordnet?

- Elementaranweisungen spezifizieren Teilfunktionen.

- Elementaranweisungen können Bezug auf bottom-up entwickelte, im Rahmen eines Arbeitsgebietes allgemein verwendbare Unterprogramme nehmen.

- Elementaranweisungen werden der Programmstruktur zugeordnet.

- Die Formulierung der Bedingungen ist ein selbständiger Teilschritt des JSP-Entwurfs.

þMit Strukturtext - einem Pseudocode - wird der Entwurf dokumentiert.

þSchachtelungsfreier Code hält alternative Implementierungsformen offen.

þWie werden größere Aufgabenstellungen mittels JSP gelöst?

- Größere Aufgabenstellungen werden als Netzwerk von "simple programs" entworfen.

- Ein JSP-Entwurf erlaubt unterschiedliche Implementierungsformen eines Systems.

- Programminversion - eine Codiertechnik zur Transformation von Hauptprogrammen in Unterprogramme.

- JSP unterstützt Entwurf und Implementierung aktueller und zukunftsweisender Systemkonzepte.

þIst JSP auch für den Entwurf von DB- und Dialog-Anwendungen geeignet?

- Mit JSP werden DB-Anwendungsprogramme entworfen, keine Datenbanken selbst.