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.

24.04.1981

Von problemunabhängigen Datenstrukturen kann keine Programmstruktur abgeleitet werdenJackson trennt Entwurf und ImplementierungTeil 2

In der JSP sind Datenstrukturen der Ausgangspunkt des Programmentwurfs.

Datenstrukturen als Ausgangspunkt des Programmentwurfs? Wie wir gesehen haben ist eine solche Vorgehensweise bei den bisher vorgestellten Datenstruktur-Begriffen nicht möglich. Kann die JSP nun Wunder vollbringen, oder wird im Rahmen dieser Methode unter Datenstruktur etwas ganz anderes verstanden? Letzteres ist der Fall.

Jackson versteht unter Datenstruktur die Syntax der zeitlich seriellen Datenströme (vor 15 Jahren wären das vor allem sequentielle Dateien gewesen), die in ein Programm eingehen und aus einem Programm herauskommen.

Abhängig von der Art der Aufgabenstellung ist diese Syntax mehr oder weniger offensichtlich. Ist eine formale Sprache (Programmiersprache, Kommandosprache) die Eingabe für das zu entwerfende Programm, deren Syntax in der Regel vor. Sie wird im Einzelfall erweitert, um auch fehlerhafte Eingaben zu erfassen; die Grundlage eines Programmentwurfs nach JSP, die Datenstruktur im JSP-Sinne, ist jedoch schon bekannt.

Anders als beim Entwurf einer dialogführenden Komponente: Die Syntax der Dialogeingaben und -ausgaben, also der zeitliche Ablauf des Dialogs und der Zusammenhang seiner einzelnen Schritte, ist normalerweise nicht so formal beschrieben wie etwa die Syntax einer Programmiersprache.

Übergestülpte Syntax

Noch anders beim Entwurf eines Stapelprogramms: Eingaben und Ausgaben sind auf Datei- und Satzebene ausführlich beschrieben; die Beziehungen zwischen einzelnen Sätzen und die Interpretation einzelner Sätze und Satzgruppen bei einer bestimmten Aufgabenstellung sind nur sehr informal dokumentiert.

Um in den beiden letztgenannten Beispielen genauso formal sein zu können wie etwa bei der syntaktischen Beschreibung einer Programmiersprache, stülpt Jackson eine Syntax über die Eingabe- und Ausgabe-Datenströme eines jeden Programms. Wir erhalten als Ergebnis JSP-Datenstrukturen, die die Sicht der verschiedenen Datenströme unter einer bestimmten Aufgabenstellung wiedergeben.

Als Notation zur Beschreibung dieser Datenstrukturen verwenden wir JSP-Strukturdiagramme, eine Darstellungstechnik, die in der JSP auch zur Beschreibung von Programmstrukturen verwendet wird. Diese einheitliche Darstellungstechnik für Daten- und Programmstrukturen erleichtert dle Ableitung der Programmstruktur von den Datenstrukturen wesentlich.

Vier Komponententypen

JSP-Strukturdiagramme bestehen aus vier Komponententypen: Sequenz (Folge), Selektion (Auswahl), Iteration (Wiederholung) und der atomaren Komponente (vergleichbar den terminalen Symbolen einer Programmiersprache). Wir werden diese vier Komponenten an dem in Bild 1 dargestellten Strukturdiagramm näher kennenlernen .

Bild 1 gibt die problemspezifische Datenstruktur eines Datenstroms "Bewegungsdaten" wieder. Die zugehörige Aufgabenstellung könnte darin bestehen, diese Bewegungsdaten zu saldieren und eine Saldenliste zu erstellen, die pro Teile-Nr. eine Saldozeile und pro Bewegung eine Bewegungszeile enthält. Es wird angenommen, daß die Daten für eine Bewegung auf je zwei Datensätzen vorliegen und die Bewegungen zu einer Teile-Nr. unmittelbar aufeinander folgen.

Im Strukturdiagramm "Bewegungsdaten" treten die vier genannten Komponententypen auf. Das Diagramm beginnt an der Spitze mit einer Iteration: "Bewegungsdaten pro Teile-Nr.". Der wiederholt auftretende (iterierte) Teil "Bewegung pro Teile-Nr." ist zur Kennzeichnung des Komponententyps mit einem "*" versehen worden. Ein "*" in einer Komponente besagt also, daß wir hier einen iterierten Teil vorliegen haben, die darüber angeordnete Komponente dennach eine Iteration ist. "Bewegungen pro Teile-Nr." ist selbst ebenfalls eine Iteration, wie der Stern im iterierten Teil "Bewegung" verdeutlicht.

Leerer Datenstrom

Diese beiden Iterationen sagen zur Struktur des Datenstroms "Bewegungsdaten" folgendes aus: Die "Bewegungsdaten" können aus einer beliebigen Anzahl Satzgruppen bestehen, die jeweils die Bewegungen zu einer Teile-Nr. umfassen. Für eine einzelne Teile-Nr. können beliebig viele Bewegungen auftreten. Da der itenerte Teil einer Iteration laut Definition nullmall, einmal oder mehrere Male auftreten kann, darf der Datenstrom auch leer sein.

Mit "Bewegung" lernen wir den Komponententyp Selektion (Auswahl) kennen. Eine "Bewegung" ist entweder ein "Eingang" oder ein "Ausgang". Die Komponenten unter denen ausgewählt (selektiert) werden muß, sind mit einem "o" gekennzeichnet. Eine Selektion darf auch mehr als zwei Teile haben, unter denen auszuwählen ist.

"Eingang" und "Ausgang" sind beide vom Typ Sequenz (Folge). Die Teile einer Sequenz sind nicht besonders gekennzeichnet. Sie treten je einmal in der dargestellten Reihenfolge von links nach rechts auf.

Problemspezifisch und doch allgemein

Die Teile der beiden Sequenzen, also "Satzart 1" und "Satzart 3" sowie "Satzart 2" und "Satzart 3", sind alle atomare Komponenten. Innerhalb einer atomaren Komponente gibt es kein zeitliches Nacheinander mehr. Ist ein Datensatz "Satzart 1" einmal gelesen und im Speicher, kann auf seine Felder in beliebiger Reihenfolge und auch gleichzeitig zugegriffen werden.

Die gezeigte Datenstruktur der Bewegungsdaten ist problemspezifisch insofern, als sie die Sicht dieser Daten bei der genannten Aufgabenstellung wiedergibt. Sie ist jedoch auch so allgemein, daß einer Programmstruktur, die auf dieser Datenstruktur basiert, unterschiedliche Funktionen zugeordnet werden können. Datenstruktur(en) und abgeleitete Programmstruktur verkörpern ein Modell der Realität, in der die Aufgabenstellung angesiedelt ist. Die einzelnen Funktionen eines Programms werden erst in einem späteren Entwurfsschritt mit diesem Modell vereinigt.

Der syntaxähnliche Charakter der JSP-Datenstrukturen soll durch Bild 2 unterstrichen werden. Dort wird der in Bild 1 als Strukturdiagramm dargestellte Sachverhalt in "Erweiterter Backus Normal Form (EBNF)" beschrieben, einer Notation, die häufig zur syntaktischen Beschreibung von Programmiersprachen verwendet wird.