Jedes Rechteck des Bachmann-Diagramms repräsentiert einen Segmenttyp beziehungsweise Satztyp innerhalb der Datenbank. Diese Komponenten erscheinen im JSP-Strukturdiagramm als atomare Komponenten (Blätter). Das JSP-Strukturdiagramm als Ganzes beschreibt die aus diesen atomaren Komponenten gebildeten Mengen.

Elementaranweisungen zum Lesen der DB.

Das JSP-Strukturdiagramm spiegelt auch den Zugriffspfad durch die Datenbank wieder. So kann etwa auf die Daten über die Erfahrungen eines Mitarbeiters bei diesem Beispiel nur über das Mitarbeiter-Segment zugegriffen werden: sie sind Teile einer Sequenz.

Auf der Grundlage von Datenstrukturdiagrammen, die den für eine bestimmte Aufgabe erforderlichen Datenbankausschnitt problemspezifisch beschreiben, werden Programmstrukturen abgeleitet, denen die Elementaranweisungen zum Lesen der Datenbank sehr einfach zugeordnet werden können. Die Bedingungen für die verschiedenen Iterationskomponenten lassen sich ebenfalls einfach und verständlich formulieren.

Auch bei Dialogprogrammen werden Datenstrome konsumiert und produziert.

Beim Entwurf dialogführender Komponenten steht die problemspezifische Beschreibung der Eingaben vom und Ausgaben zum Terminal im Vordergrund des Entwurfs. Durch die entsprechenden Strukturdiagramme wird der Zusammenhang zwischen einzelnen Dialogschritten inklusive der erforderlichen Fehlerbehandlung anschaulich beschrieben.

Bild 13 zeigt das Strukturdiagramm für korrekte Dialogeingaben einer Auftragserfassung. Bild 14 ist ergänzt um die erforderliche Fehlerbehandlung und um Korrekturmöglichkeiten. Ein korrekter Dialog läuft bei diesem Beispiel folgendermaßen ab:

Nach Aufruf des Programms durch Eingabe des Transaktionscodes "AE" (Auftragseingänge) wird in der ersten Spalte der Zeile, in der am Terminal die nächste Nachricht eingegeben werden soll, ein Strich angezeigt. Daraufhin gibt der Sachbearbeiter den Code KN gefolgt von einer Kundennummer ein. Das Programm antwortet mit "AUFTRAGSNR. IST nnnnnn" und schreibt, wie bei allen Ausgabenachrichten, auf die eine Benutzereingabe erwartet wird, einen Strich in die erste Spalte der nächsten Zeile.

Nach Vergabe der Auftragsnummer werden die einzelnen Auftragsposten eingegeben. Dazu wird jeweils der Code AT, gefolgt von einer Artikelnummer, eingegeben. Das Programm antwortet mit einer maximal 30stelligen Artikelbezeichnung. Der Sachbearbeiter kann nun entweder dem Programm mitteilen, daß für diesen Artikel keine Bestellung vorliegt, indem er CC (cancel) eingibt, oder er kann einen Auftragsposten eingeben. Dies geschieht durch Eingabe des Codes MG (Menge) und einer Ganzzahl. Erfolgt statt Eingabe von CC oder MG und Mengenangabe die Fortsetzung des Dialogs mit einem anderen korrekten Code, wird vom Programm die Menge 1 angenommen. Dazu erfolgt die Ausgabe der Nachricht "MENGE 1 ANGENOMMEN FUER ARTIKEL nnnnnn". Da vom Sachbearbeiter nach dieser Nachricht keine Eingabe erwartet wird, wird auch kein Strich in die nächste Zeile geschrieben.

Der Sachbearbeiter beendet den Dialog durch Eingabe einer Endenachricht. Gibt er SV (save) ein, gilt der Auftrag als gesichert, gibt er DL (delete) ein, wird der komplette Auftrag ignoriert. Das Programm antwortet entsprechend mit "AUFTRAG GESICHERT" oder "AUFTRAG IGNORIERT".

Beispiel für einen Dialog mit dem gewünschten Programm (Benutzereingaben sind fett gesetzt):

Beim Entwurf einer dialogführenden Komponente wird immer der gesamte Dialog in Betracht gezogen, nicht nur ein einzelner Dialogschritt Dies gilt auch bei transaktionsorientierter Implementierung. Durch diese Vorgehensweise wird eine hohe Portabilität derartiger Komponenten bezüglich unterschiedlicher Hardware-Software-Systeme und TP-Monitore sichergestellt .

Die Komponente kann als Hauptprogramm implementiert werden, wenn das Betriebssystem dies erfordert. Mittels Programminversion kann dieselbe Komponente jedoch auch so implementiert werden, daß sie unter einem TP-Monitor ablauffähig ist und von diesem beim Vorliegen von Dialogeingaben aktiviert wird.

Ist transaktionsonentierte Verarbeitung gewünscht und/oder soll eine einzelne transaktionsverarbeitende Routine einen bestimmten Speicherplatzbedarf nicht übersteigen, kann ein einzelnes simple programm textlich in mehrere solche Routinen zerlegt werden. Die dabei anzuwendenden Regeln stellen sicher, daß die Kontrollübergabe von einer Routine zur anderen transparent bleibt.

Beim Entwurf dialogführender Komponenten in Online-Anwendungen zeigt sich die JSP als echte Entwurfsmethode der einmal erstellte Entwurf bleibt von der Implementierungswahl unbeeinflußt.

Durch Erweiterung der JSP um Jackson System Development (JSD) ergibt sich ein abgestimmtes Methodenbündel für die gesamte Systementwicklung.

In jüngster Zeit sind die auf der Basis der JSP entwickelten Ansätze zum System Design zu einer abgerundeten Methode weiterentwickelt worden. Diese als Jackson System Development (JSD) bezeichnete Methode stellt wie JSP die Modellbildung in den Vordergrund ihrer Systembetrachtung.

Genau wie JSP baut auch JSD auf bekannten Ansätzen auf Sie bezieht ihren theoretischen und praktischen Background aus den Techniken zur Simulation diskreter Ereignisse, bei denen Modellbildung ebenfalls ein wichtiger Aspekt ist.

Es ist gelungen, beim Systementwurf ähnlich wie beim Programmentwurf eine Reihe von Problemklassen herauszuarbeiten, für die standardisierte Lösungsschemata angeboten werden. Diese Problemklassen gelten unabhängig von bestimmten Anwendungsgebieten und zeigen interessante Parallelen zwischen kommerziell-administrativer und Prozeßdatenverarbeitung auf. Sie bieten damit die Möglichkeit zu Know-how-Transfer und größerer Flexibilität der Programmierer zwischen unterschiedlichen Bereichen der Software-Erstellung.

JSP ist eine zukunftssichere Methode mit einem breiten Anwendungsspektrum.

Michael A. Jackson und seinen Mitarbeitern ist es gelungen, die Erfahrungen, die in unterschiedlichen DV-Anwendungsgebieten gemacht wurden, zu vereinigen und auf eine systematische, methodische Basis zu stellen. Dabei wurden die wesentlichen Konzepte und Problemklassen, die für den Programm- und Systementwurf gelten, herausgearbeitet. Für die verschiedenen Problemklassen wurden standardisierte Lösungsschemata entwickelt.

JSP und JSD sind nicht die Methoden, mit denen man alle Probleme bei der Software-Erstellung lösen kann. Es sind jedoch Methoden, die ein sehr breites Anwendungsspektrum unterstützen und durch ihre strikte Trennung von Entwurf und Implementierung auch für zukunftsweisende Technologien wie verteilte Systeme und Parallelverarbeitung bestens geeignet sind.

Wer nicht nur seine alltäglichen Programm- und Systementwürfe methodisch erstellen will, sondern auch zukunftsorientierte, anspruchsvolle Systeme realisieren muß, wird durch Anwendung von JSP/JSD in diesem Bestreben langfristig unterstützt.

Literatur

Jackson 75

Jackson, Michael A.: Principles of Program Design, London - New York - San Francisco 1975 ; Deutsche Übersetzung: Jackson, Michael, A :

Grundsätze des Programmentwurfs; Darmstadt 1979

Wirth 75

Wirth, Niklaus: Algorithmen und Datenstrukturen; Stuttgart 1975.

Wirth 79

Wirth, Niklaus: The Module: A System Structuring Facility in High-Level Programming Languages In: Proceedings of the Symposium on Language Design and Programming Methodology Sydney 10./11.Sept 1979.

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 Datendarstellung 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.

- Elemantaranweisungen 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 halt 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 Implementienungsformen 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.

- Auch bei Dialogprogrammen werden Datenströme konsumiert und produziert.

- Durch Erweiterung der JSP um Jackson System Development (JSD) ergibt sich ein abgestimmtes Methodenbündel für die gesamte Systementwicklung.

- JSP ist eine zukunftssichere Methode mit einem breiten Anwendungsspektrum.

Wolfgang George