Michael Jackson:

Beständiges System basiert auf Modellbild der Wirklichkeit

03.04.1980

Meine Kollegen und ich sind dabei, eine Designmethode für Datenverarbeitungs-systeme zu entwickeln. Wir haben in dieser Hinsicht noch einige Arbeit zu investieren, bevor die Methode hinreichend vervollständigt ist, um in Formalkursen gelehrt werden zu können. Grundgedanken derselben sind jedoch bereits formuliert und durchdacht. Im wesentlichen stammen diese Basisgedanken aus unserer Programmdesignmethode JSP (Jackson Strukturierte Programmierung), die bereits in vielen Staaten der Welt regelmäßig gelehrt und praktiziert wird und deren allgemeine Akzeptanz steigt. (In Deutschland wird JSP von mbp GmbH, Dortmund, gelehrt.) Jedoch ist das Problem des Systemdesigns komplexer und schwieriger, als das des Programmdesigns und verlangt zusätzliche Erkenntnisse und Techniken. In diesem Artikel möchte ich kurz die Grundideen beschreiben und die generelle Form und Natur der Methode untersuchen.

Wo hat ein Systemdesigner zu beginnen? Es scheint selbstverständlich und wird üblicherweise vorausgesetzt, daß er mit einem die Systemfunktion klärenden Konzept beginnt: Das bedeutet einer Beschreibung dessen, was das System zu leisten hat, möglicherweise durch Charakteristika von In- und Output gekennzeichnet sowie deren Beziehungen untereinander.

Modell und Funktion

Bei diesem Ansatz ergeben sich jedoch einige Schwierigkeiten. Ein unmittelbares Problem ist zum Beispiel, daß der Auftraggeber, für den der Designer arbeitet - der spätere Anwender also - nicht dazu fähig ist, exakt anzugeben, was für Leistungen er vom System erwartet: Er nennt die grundlegenden Forderungen, wehrt sich jedoch dagegen, durch eine genaue Spezifikation festgelegt zu werden. Selbst wenn der Designer durch die Abzeichnung der funktionellen Beschreibung beispielsweise den Benutzer zu einer Entscheidung zwingt, ist das Problem dadurch nicht gelöst, sondern nur aufgeschoben: Funktionelle Änderungen werden mit Sicherheit spätestens dann gewünscht, wenn das System zum Einsatz kommt, normalerweise aber bereits sehr viel früher. Im günstigsten Fall hat der Designer den Kunden gezwungen, eine Installation zu akzeptieren, die seinen Vorstellungen nicht genau entspricht; schlimmstenfalls - und ich konnte das an mehr als nur einem Projekt beobachten - muß der Benutzer ein System bezahlen, das er überhaupt nicht verwenden kann.

Die prinzipielle Schwierigkeit resultiert daraus - wie auch im Fall der Applikationsentwicklung -, daß bereits geringe funktionelle Spezifikationsänderungen große Design-Änderungen nötig machen. In einer Weise, die bislang noch nicht vollständig verstanden ist, wirken sie sich bis in die Tiefe des Designkonzeptes aus, und bei Variation kleiner Details können große Teile desselben wertlos werden.

Der verantwortungsbewußte Designer wird versuchen, diese Problematik dadurch zu überwinden, daß er in der Systemerstellungsphase bestrebt ist, einen größeren Rahmen für die Vorgaben offen zu halten. Er bedenkt zusätzliche Funktionen, von denen er meint, daß sie zu späterem Zeitpunkt benötigt werden könnten. Jedoch: Welche Zusatzfunktionen sind wichtig, und wonach wird der Anwender fragen? Wodurch kann der Designer die Bedeutung einer möglichen zusätzlichen Funktion abschätzen, die weder bisher gefordert wurde, noch vielleicht jemals gefordert wird?

Die Kundenwünsche entspringen nicht der Willkür und lassen sich nicht umgehen; meist basieren sie auf Veränderungen im Arbeitsablauf, die sich aus äußeren Umständen ergeben. Der Manager einer Fabrik sieht einen besseren Weg den zeitlichen Ablauf einiger Vorgänge zu definieren: Der Vertriebsleiter entwirft einen vernünftigeren Plan für die Bestellungen einzelner Verkäufer (um Investitionen zu verringern oder Rabatte wahrzunehmen). Das bedeutet gleichzeitig, daß von der Rechenanlage neue oder anders aufbereitete Information gewünscht wird. Die Fabrik als solche hat sich dabei nicht geändert: Alle Maschinen befinden sich weiterhin in derselben Stellung, dieselben Produkte werden weiterhin mit denselben einzelnen Arbeitsschritten hergestellt. Die Verkäufer haben sich auch nicht geändert: Sie bieten immer noch dieselbe Art Ware aufgrund des ebenfalls unveränderten Rabattsystems an, und das Unternehmen muß die Waren wie bisher kaufen und lagern. Kurz, die Realität hat sich nicht geändert. Es ist einzig die Reaktion auf diese Wirklichkeit, die sich geändert hat.

Der richtige Ansatz für das Design resultiert daher nicht aus der Bestimmung der Systemfunktion, sondern desjenigen Wirklichkeitsausschnittes, in dem der Rechner seine Funktion ausüben soll. Vor Untersuchung der Systemfunktion hat sich der Designer mit dem Auftraggeber über die genaue Beschreibung der "Welt des Kunden" zu unterhalten. Diese Beschreibung trägt den Namen "Modell". Damit ist nicht ein Hardwaresystem-Modell gemeint, auch kleines der Systemfunktionen, sondern die modellhafte Nachbildung der Objekte, die das System zu bearbeiten hat - der Gegebenheiten also, die den Einsatz des Systems überhaupt erforderlich machen. Der Designer muß demnach damit beginnen, Fabrik, Maschinen, hergestellte Produkte oder (im Verkäuferbeispiel) eingekaufte Waren, Verpackungen und ähnliches modellmäßig nachzuempfinden.

Selbstverständlich gibt es keine Gewähr dafür, daß sich die reale Welt nicht verändern wird: Im Grunde genommen unterliegt das Modell genauso gewissen Veränderungen, wie die Systemfunktion. Jedoch erfolgen erwartungsgemäß betriebliche Umstellungen wesentlich seltener als funktionelle, da es schließlich die äußeren Umstände sind, die den Vorgängen ihren Sinn geben. Eine betriebliche Veränderung wird nahezu immer auch eine Funktionsänderung nach sich ziehen - die Umkehrung dieses Satzes ist jedoch nicht richtig. Änderungen im Arbeitsablauf treten im allgemeinen ohne Wechsel der zugrundeliegenden betrieblichen Konstellationen auf. Das bedeutet, daß ein System, das auf einem Modellbild der Wirklichkeit fußt, normalerweise beständiger sein wird als eines, das von der zu erfüllenden Funktion abgeleitet wurde.

Modellauswahl

Die modellmäßige Wirklichkeitsprojektion ist ein Hauptbestandteil in der Bestimmung eines Datenbankdesigns. Sicher ist der DB-Designer schon im frühesten Arbeitsstadium damit beschäftigt, herauszuarbeiten, was das System funktionell leisten muß. Ebenso befaßt er sich jedoch indirekt damit, die Realität in ein Modell umzusetzen.

Bedauerlicherweise ist das Datenbankdesign in einem wesentlichen Punkt ein-geschränkt. Der Wirklichkeitsausschnitt, mit dem sich ein solches Datenverarbeitungs-system auseinanderzusetzen hat, ist hauptsächlich durch eine zeitliche Komponente geprägt. Ein besonderes Interesse des Menschen gilt Ereignissen in Zusammenhang mit der temporären Sequenz, in der diese auftreten. Die Objekte, die der Mensch abbildet, sind mit Aktionen verknüpft, deren zeitliche Ordnung von höchster Wichtigkeit ist. Eine Datenbank kann diese sequentielle Komponente nur unter allergrößten Schwierigkeiten nachbilden. Im Grunde genommen ist eine Datenbank ein inertes Modell: Die Realisation derjenigen Datenbankeigenschaften, die mit dem temporären Ablauf von Ereignissen zu tun haben, fallen in das Ressort der Programmerstellung, demnach sind sie nicht eigentliche Aufgabe des DB-Designers.

Um die Zeit modellmäßig richtig abzubilden, müssen Modelle entworfen werden, die sequentielle Prozesse - oder aber entsprechende Strukturen - beinhalten: Um die zeitliche Abfolge von Vertreteraktionen zu repräsentieren, braucht man einen sequentiellen Prozeß, der der Tätigkeit von Vertretern entspricht und sich in den definierten zeitlichen Vorgängen weiterentwickelt, in Parallele zu dem einen aktionsbezogenen Entwicklungsprozeß in der realen Welt unterworfenen realen Vertreter.