Die Leistungsfaehigkeit vieler Programmierer und Software- Entwickler wird von einem bislang kaum wahrgenommenen Problem beeintraechtigt. Gemeint ist die eingefahrene Denkweise, die durch die staendige Auseinandersetzung mit Problemen innerhalb einer bestimmten Programmiersprache entsteht.

Wer beispielsweise in Cobol programmiert, wird versuchen, jede auftretende Aufgabe in ebendieser Programmiersprache zu fixieren und zu loesen. Damit entsteht im Laufe vieler Jahre eine Art und Weise zu denken, die eine von Cobol unabhaengige Logik in der Informatik nicht mehr zulaesst. Was dabei voellig vernachlaessigt wird, ist das abstrakte Denkvermoegen.

Nur Objekte und Beziehungen zulassen

Eine gute Moeglichkeit, diesem Kreislauf zu entrinnen, stellt der Einsatz eines Data-Dictionaries dar. Ein solches Informationsverzeichnis bietet die Moeglichkeit, logische Probleme und Aufgabenstellungen in Entity-Relationship-Denkweise zu formulieren und abzubilden.

Um die Bedeutung des Data-Dictionaries fuer die abstrakte Denkweise zu verstehen, ist es notwendig, sich eine entsprechend gestaltete Umgebung erst einmal vorzustellen: Ein Data-Dictionary basiert auf dem Entity-Relationship-Modell. Dieses Modell besagt in seinen Grundzuegen, dass sich eine Datenstruktur nur aus Objekten (Entities) und der zwischen diesen Elementen bestehenden Beziehung (Relationship) zusammensetzt.

Die Objekte sind dabei in einen fixen Typteil und einen frei waehlbaren Namensteil untergliedert. Die Datenstruktur in ihrer Gesamtheit besteht aus vielen Objekte, die mittels Beziehungen verbunden sind.

Das Data Dictionary bietet nun die Moeglichkeit, diese Objekte mit den zugehoerigen Beziehungen abzuspeichern. Am besten laesst sich das dadurch erreichen, dass das Data-Dictionary in drei wesentliche Teile zerlegt wird, naemlich in einen Bildschirm, einen Strukturkatalog und die Auswertungsfunktionen.

In Form eines Schachbretts angeordnet

Ueber den Bildschirm koennen alle Objekte eingegeben werden - moeglichst mit den zugehoerigen Beziehungen und den beschreibenden Attributen. In einem frei modellierbaren Strukturkatalog lassen sich dann alle Objekttypen und die zwischen diesen zugelassenen Beziehungen definieren. Unerlaesslich sind die Auswertungsfunktionen, die nach der Eingabe von Objekten, Beziehungen und Attributen die erzeugte Struktur in ihrer Gesamtheit anzeigen. Hierfuer bieten sich N2-Charts geradezu an.

Zum Verstaendnis dieser Technologie soll an dieser Stelle kurz der Aufbau eines N2-Charts erlaeutert werden: Es besteht aus n mal n Feldern, die in Form eines Quadrats angeordnet sind. Ein Beispiel hierfuer ist das Schachbrett, das aus einem Quadrat mit acht mal acht Feldern besteht. Auf der Diagonalen werden - von links oben nach rechts unten - die Objekte dargestellt.

Oberhalb und unterhalb der Halbierenden existiert zu jedem in der Diagonalen angezeigten Objektpaar je ein Schnittfeld, in dem sich die Beziehungen zwischen den Objekten anzeigen lassen. Ueber der Diagonalen wird dabei die Beziehung vom hoeher- zum niederrangigen Element ausgedrueckt; darunter verhaelt es sich umgekehrt. Idealerweise sollte das N2-Chart als Auswertungsfunktion mit Editiermoeglichkeit realisiert sein.

Mit den besprochenen Funktionen laesst sich nun folgendes vierstufige Modell umsetzen. Zunaechst stellt der Programmierer eine vorhandene Cobol-Struktur - zum Beispiel ein Datenelement mit den spezifischen Nummern 01 bis 50 - als Entity-Relationship- Gefuege dar. Daraus erarbeitet er einen Strukturkatalog, den er seiner eigenen Data-Dictionary-Anwendung zugrunde legt. Moegliche Objekttypen sind hier "Record" fuer Elemente mit der Stufennummer 01, "Group-of-Fields" fuer Datenelemente auf einer Stufe ungleich 01, aber ohne beschreibende Datensatzerklaerung, und "Field" fuer Elemente auf der letzten Stufe, die durch die Picture-Klausel naeher beschrieben wurden und somit die kleinsten Objekte der Struktur darstellen.

Nach Eingabe des Strukturkataloges trainiert der Programmierer, ueber den oben besprochenen Objektbildschirm Cobol-Datenelemente komplett, gegebenenfalls mit beschreibenden Attributen, einzugeben. Die erzeugten Strukturen schaut er sich ueber das N2- Chart an und uebt so die Denkweise des Entity-Relationship-Modells.

Staendige Wiederholung erzeugt Verstaendnis

Durch den Uebergang von der bekannten Cobol-Struktur in die bisher unbekannte, abstrakte Objektbeziehung-Denkweise wird der groesstmoegliche Lernerfolg erzielt. Die staendige Wiederholung erzeugt im Unterbewusstsein nach und nach ein Verstaendnis des Entity-Relationship-Modells sowie des zugehoerigen Data- Dictionaries. Durch die N2-Chart-Darstellung laesst sich darueber hinaus das Einfuehlungsvermoegen fuer die Gesamtstruktur foerdern.

Nachdem der Programmierer genuegend Datenelemente dargestellt hat, geht er dazu ueber, die bisher eingegebenen Strukturen zu erweitern und eigene Auswertungsfunktionen zu erarbeiten. Fuer die zuletzt genannte Aufgabe bietet es sich an, einen Generator fuer Cobol- Copy-Elemente zu erarbeiten. Erweiterungen der bestehenden Strukturen sind zum Beispiel Entitaeten, die ueber den Cobol- Datenelementen das Programmgefuege ergeben. Es kann sich aber auch um Strukturen handeln, aus denen sich im folgenden Programm logische Abfragen bezueglich der eingegebenen Datenelemente ergeben.

Auf der vierten und letzten Stufe loest sich der Programmierer gedanklich von den vorher erarbeiteten Cobol-Datenstrukturen ab. Aufbauend auf seinem gewachsenen Verstaendnis des Entity- Relationship-Modells, erarbeitet er nun eigenstaendige, von Cobol unabhaengige Strukturen ueber das N2-Chart. Bei dieser Aufgabe kann er seiner Kreativitaet freien Lauf lassen.

Uebergang zu Strukturen anderer Modelle moeglich

Fuer den Anfang kann zum Beispiel die Darstellung der Abteilung gewaehlt werden, in der der Programmierer derzeit angesiedelt ist. Von diesem Ausgangspunkt laesst sich dann ein Datenmodell der Mitarbeiter oder der Abteilungen in der gesamten Firma erstellen; im Prinzip sind dem Entwickler auch darueber hinaus keine Grenzen gesetzt.

In dem beschriebenen vierstufigen Modell loest sich der Programmierer waehrend der Anwendung langsam von der ihm eigenen Cobol-Denkweise. Waehrend der ersten drei Stufen gewoehnt er sich sowohl an das Entity-Relationship-Modell als auch an die Umstellung selbst. Der Umgewoehnungsvorgang vollzieht sich naemlich indirekt; das Ergebnis wird erst in der letzten Stufe deutlich.

Auf der vierten Stufe vollzieht sich die Wandlung zur abstrakten Denkweise. Losgeloest von der Cobol-spezifischen Vorgehensart, arbeitet der Programmierer nun kreativ innerhalb des Entity- Relationship-Modells, wo nur noch Objektbeziehung-Strukturen moeglich sind.

Bei diesen Strukturen handelt es sich um die einfachste Art des abstrakten Denkens. Folglich steht dem Entwickler, sobald er diese Ebene erreicht hat, auch der Uebergang zu komplizierteren Strukturen anderer Modelle offen. So ist zum Beispiel der systemtheoretische Ansatz der Betriebswirtschaftslehre sehr leicht verstaendlich fuer jemanden, der das Entity-Relationship-Modell von seiner Anwendung her kennt.

Die Durchfuehrung des beschriebenen Abloesungsprozesses gestaltet sich ebenfalls recht einfach. Der Programmierer arbeitet ueber zwei bis drei Monate pro Arbeitstag eine Stunde lang in oben beschriebener Art und Weise an dem dargestellten Data-Dictionary. Die einzelnen Stufen durchlaeuft er sequentiell, indem er sich bei jedem Uebergang zur naechsthoeheren Stufe Rechenschaft ablegt, ob der gewuenschte Erfolg bereits eingetreten ist.

Mit den Vorgesetzten duerfte es dabei kaum Schwierigkeiten geben, da jeder normale Chef froh darueber ist, wenn seine Untergebenen waehrend der Zeit, in der sie bei ihm arbeiten, den Sprung zu einem fuer hoehere Aufgaben qualifizierenden Profil schaffen. Das ist sicherlich den zusaetzlichen Arbeitsaufwand wert.

Durch die Gewoehnung an abstrakte Denkweisen wird uebrigens auch ein grosser Schritt in Richtung Entwicklung der eigenen Persoenlichkeit unternommen. Auch dieser Reifungsprozess lohnt immer.

*Klaus Speicher ist freier Autor in Muenchen.