1. Kapitel
Erfassung der Strukturen von Kooperationssystemen in grafischen Plänen
= Fundamental Modelling Concepts (FMC)



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
Interpreter-
schichtung
1.7
Phasen-
trennung

1.2 Das Lösungskonzept

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