Home |
1.1 Zwei Probleme |
1.2 Lösungs- konzept |
1.3 Aufbau- pläne |
1.4 Ablauf- pläne |
1.5 Daten- pläne |
1.6 Metaplan der Pläne |
1.7 Interpreter- schichtung |
1.8 Phasen- trennung |
1.9 Übersichts- vortrag |
Irrelevanz des Programmtextes:
Angemessene grafische Darstellungen der Ergebnisse der Planung von Softwaresystemen kann man nur finden, indem man sich von der Vorstellung
programmiersprachlich formulierter Programme löst.
Denn Programme sind Texte, deren Struktur hinsichtlich der Lösung unseres aktuellen Darstellungsproblems völlig irrelevant ist.
Die Konzentration auf den Programmtext wird den Suchenden sogar meist in falsche Richtungen lenken. Anstatt über einen statischen Text nachzudenken
muss man sich bewusst machen, dass es um Systeme geht, in denen sich dynamische Vorgänge abspielen, die durch Kooperation einzelner Akteure
entstehen. Diese Besonderheit des Lösungsansatzes kommt schon in der Kapitelüberschrift zum Ausdruck: Erfassung der Strukturen
von Kooperationssystemen in grafischen Plänen.
Unterscheidung zwischen Rolle und Träger:
Mit dem Begriff des Kooperationssystems ist die Vorstellung verbunden, dass es mehrere Akteure gibt, die zur Erfüllung eines gemeinsamen
Zwecks miteinander kooperieren. Dabei hat man üblicherweise die Vorstellung, dass es sich bei den Akteuren um Menschen handelt. In einem
Kooperationsverbund können aber neben Menschen auch Tiere und technische Systeme als Akteure vorkommen. Wenn Menschen Computer benutzen, ist es
normalerweise nicht die nackte Hardware, mit der sie kooperieren, sondern sie kooperieren mit Akteuren, die dadurch entstehen, dass der oder die Computer
durch die Interpretation von Software in bestimmten Rollen auftreten. Deshalb ist es zweckmäßig zu sagen, dass ein Akteur durch die Rolle bestimmt wird,
die ein Träger der jeweiligen Rolle aktuell "spielt". Im Bereich des Theaters sind die Rollenträger die Schauspieler, und im Bereich der Informationstechnik
sind die Träger der Rollen die Computer. Wenn man nur an dem Stück interessiert ist, das gerade gespielt wird, wird man schnell vergessen, wer der aktuelle
Träger einer bestimmten Rolle ist, und man wird sich nur noch für den "Rollenakteur" interessieren. Software sollte also immer als eine Beschreibung
interagierender Rollenakteure betrachtet werden, und das dadurch gebildete Kooperationssystem muss dargestellt werden. Diese Sicht macht es auch verständlich,
dass die sprachliche Formulierung der Rollen für das Verständnis des Kooperationssystems irrelevant ist - eine Rolle kann in beliebiger Sprache formuliert
sein und bleibt doch immer eindeutig eine bestimmte Rolle.
Verallgemeinerung der Art der "Werkstücke":
Auch ist die Vorstellung nicht zwingend, dass das, was schrittweise von den kooperierenden Akteuren verarbeitet werden soll,
Information ist. Vielmehr darf man seine Sicht - zumindest teilweise - auf das beschränken, was allen Systemen gemeinsam ist, in denen mehrere Akteure
in Kooperation schrittweise irgendwelche "Werkstücke" bearbeiten. Diese Werkstücke können materiell, energetisch oder informationell sein.
Informationelle Werkstücke sind Daten. Die Systeme müssen auch nicht "puristisch" sein; es ist durchaus zulässig, dass
in ein und demselben System alle drei Arten von Werkstücken gleichzeitig vorkommen.
Aufbaupläne, Ablaufpläne und Datenpläne:
Jedes Werkstück befindet sich zu jedem Zeitpunkt an einem bestimmten Ort im System, und die Aktivität der Akteure besteht
aus schrittweisen Aktionen. Eine Aktion dient dazu, ein Werkstück zu bearbeiten, aus zwei oder mehr Werkstücken ein einziges zu machen,
aus einem Werkstück zwei oder mehr Werkstücke zu machen, oder ein Werkstück von einem Ort an einen anderen zu bringen.
Da die Aktionen an bestimmten Orten stattfinden, nenne ich die Orte Aktionsfelder. Aktionsfelder, auf denen die Werkstücke ruhen,
sind Speicher, und Aktionsfelder, auf denen sich die Werkstücke bewegen, sind Kanäle . Aus der Art der Aktionen, für
die ein Akteur zuständig ist, folgt, zu welchen Aktionsfeldern er Zugang haben muss, und das kann in einem sog.
Aufbauplan dargestellt werden.
Da die Kooperation der Akteure einem bestimmten Ziel dient, sind die Aktionen zum Teil kausal voneinander abhängig, was bedeutet, dass der Beginn
einer Aktion das Ende bestimmter anderer Aktionen voraussetzen darf. Diese kausale Abhängigkeit kann in einem
Ablaufplan dargestellt werden.
Während die Art der Werkstücke - materiell, energetisch oder informationell - für die Aufbau- und Ablaufpläne irrelevant ist, hängen die
Pläne, welche die Strukturen zusammengesetzter Werkstücke beschreiben, selbstverständlich von der Art der Werkstücke ab. In der
vorliegenden Betrachtung geht es um Software und damit um informationelle Werkstücke, also um Daten, und deren Struktur wird in
Datenplänen dargestellt.
Beziehungen zwischen den Plänen:
Die für das Verständnis eines großen Systems erforderlichen Informationen lassen sich nur mit einer großen Anzahl von Plänen
erfassen. Dabei hat mit Ausnahme des "obersten" Aufbauplans jeder dieser Pläne einen "Vaterplan", dem er zugeordnet ist und zu dem er weitere
Informationen liefert. Jeder Plantyp kann Vaterplan sein, weil das, was ein Knoten in diesem Plan symbolisiert, nicht elementar sein muss, sondern
Struktur haben kann, die durch einen "Kindplan" des gleichen Typs dargestellt werden kann. Beispielsweise kann ein Akteur, der in einem Aufbauplan
vorkommt, selbst wieder ein System sein, für das es einen Aufbauplan gibt. Und eine Aktion, die in einem Ablaufplan vorkommt, kann aus einer Menge
einfacherer Aktionen zusammengesetzt sein, deren kausale Abhängigkeiten wieder in einem Ablaufplan dargestellt werden können. Neben den
Kindplänen, die Strukturen zeigen, die in einem Knoten ihres Vaterplans abstrahiert sind, gibt es noch eine zweite Form der Vater-Kind-Beziehung.
In diesen Fällen ist der Vaterplan immer ein Aufbauplan, wogegen der Kindplan entweder ein Ablaufplan oder ein Datenstrukturplan ist. Die Vater-Kind-Beziehung
ist in diesen Fällen darin begründet, dass der Kindplan entweder Aktionen zeigt, die von den Akteuren auf dem Vaterplan
ausgeführt werden, oder dass er eine Datenstruktur beschreibt, die auf einem Aktionsfeld des Vaterplans vorkommt. Aus den verschiedenen
möglichen Vater-Kind-Beziehungen zwischen den Plänen folgt, dass der "oberste" Plan - also der einzige Plan, der keinen Vater hat - nur ein
Aufbauplan sein kann. Und dieser Aufbauplan ist für das Systemverständnis der wichtigste, denn alle darunterliegenden Pläne bringen
nur noch weitere Informationen, die man ohne den obersten Plan nicht einordnen könnte.
zum Seitenanfang