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 Metaplan der Pläne

1.7 Interpreter- schichtung

1.8 Phasen- trennung

1.9 Übersichts- vortrag

1.8 Phasentrennung

Erklärung des Begriffs

Bei der Phasentrennung wird unterschieden zwischen in Betrieb befindlichen Systemen und anderen Systemen, die von den in Betrieb befindlichen Systemen hergestellt, umgebaut oder gewartet werden. Die einen Systeme sind also aktiv, denn sie agieren, während die anderen Systeme passiv sind, denn es geschieht etwas mit ihnen. Die passiven Systeme müssen als "Werkstücke" betrachtet werden, die an Orten liegen, zu denen irgendwelche Akteure Zugang haben. Bereits in der biblischen Schöpfungsgeschichte wird eine solche Situation beschrieben (1. Mose, Kapitel 2, Vers 7): "Und Gott der Herr machte den Menschen aus einem Erdenkloß, und er blies ihm ein den lebendigen Odem in seine Nase. Und also ward der Mensch eine lebendige Seele." Hier findet ein Phasenübergang von passiv nach aktiv statt. Den gibt es auch, wenn ein Chirurg an einem betäubt auf dem Operationstisch liegenden Patienten einen Eingriff vornimmt und dieser Patient dann später aus der Narkose erwacht. Der umgekehrte Phasenübergang, also von aktiv nach passiv, findet vor der Operation statt, wenn der Patient in die Narkose fällt. Solche Phasenübergänge sind im Softwarebereich sehr leicht zu realisieren. Da alle softwarebestimmten Akteure aus Software und einen diese Software ausführenden Interpreter bestehen, stellt jeder Beginn einer Interpretation einen Phasenübergang von passiv nach aktiv dar. Entsprechend findet ein Phasenübergang von aktiv nach passiv statt, wenn der Interpreter einen Interpretationsvorgang unterbricht oder beendet. Solange der Programmcode nicht interpretiert wird, ist er ein passives informationelles Werkstück, das bearbeitet werden kann; sobald er aber von einem Interpreter gelesen und ausgeführt wird, ist er Teil eines aktiven Akteurs.

Im links oben gezeigten Aufbauplan gibt es einen Akteur 1, der in seinem Aktionsfeld ein System aufbaut, das er anschließend aktiviert, damit er dann mit dem neu geschaffenen Akteur 2 über den Kanal, der ihn mit diesem verbindet, kommunizieren kann. Man erkennt diesen Sachverhalt daran, dass der Akteur 1 zwei unterschiedliche Zugänge zu seinem Aktionsfeld hat: Es gibt einen Zugang auf das ganze Aktionsfeld, woraus geschlossen werden darf, dass in diesem Aktionsfeld etwas Passives liegt. Es gibt aber außerdem auch noch den Zugang zu einem in diesem Aktionsfeld liegenden Kanal, was nur Sinn macht, wenn dieser Kanal zu einem aktiven System gehört. Man könnte diesen Aufbauplan mit der biblischen Geschichte von der Schöpfung des Menschen verbinden und den Akteur 1 als Gott deuten. Man kann sich aber auch den Akteur 1 als einen Techniker vorstellen, der einen Roboter zusammenbaut, diesen dann aktiviert und anschließend mit ihm kommuniziert. In dem links unten gezeigten Aufbauplan gibt es auch ein Aktionsfeld, worin ein Systemaufbau dargestellt ist. Auf dieses Aktionsfeld greift aber kein Akteur als Ganzes zu, sondern die Zugriffe erfolgen nur auf die innen liegenden Kanäle. Daraus folgt, dass das in diesem Aktionsfeld liegende System keinen Phasenübergang erlebt, sondern ausschließlich aktiv ist. Dass das System aus dem Dolmetscher und den beiden Kanälen überhaupt in einem Aktionsfeld zusammengefasst wurde, liegt daran, dass man das Ganze als einen Kanal zwischen den beiden Diplomaten betrachtet kann, indem man davon absieht, dass keiner der Diplomaten die Sprache des anderen versteht.

Ein Beispiel aus der Praxis

Nun wird noch ein Beispiel vorgestellt, das verdeutlichen soll, dass bei der Abwicklung von Software die Aufeinanderfolge passiver und aktiver Phasen recht häufig vorkommt und keineswegs eine seltene Erscheinung ist.

Wenn ein Computerbenutzer seinen Dialog mit dem System beginnt, kann er anfangs nur mit dem Betriebssystem kommunizieren, denn außer diesem ist zu Beginn noch kein anderer Akteur aktiv. Das Ziel des Benutzers sei es aber, mit einem Akteur zu kommunizieren, dessen Rolle früher schon in der Sprache A formuliert und unter der Bezeichnung P im Hintergrundspeicher abgelegt wurde. Deshalb bittet der Benutzer das Betriebssystem, den Compiler für die Sprache A zu aktivieren. Sobald dieser Compiler aktiv geworden ist, meldet er sich beim Benutzer, um von diesem die Information zu erfragen, welcher in der Sprache A formulierte Text in die vom Computer interpretierbare Maschinensprache übersetzt werden soll. Nachdem der Compiler die erfolgreiche Erledigung seiner Arbeit gemeldet hat, wendet sich der Benutzer wieder an das Betriebssystem und erteilt diesem den Auftrag, den Akteur P zu aktivieren. Sobald dieser Akteur aktiv geworden ist, meldet er sich beim Benutzer, der nun einen Dialog mit diesem Akteur führen kann. Im Lauf dieses Dialogs erkennt der Akteur P die Notwendigkeit, seine Rolle zu erweitern. Er weiß, dass die Rollenerweiterung in der Sprache B formuliert unter der Bezeichnung D im Hintergrundspeicher liegt. Also wendet sich der Akteur P an das Betriebssystem mit der Bitte, den Compiler für die Sprache B zu aktivieren. Wenn sich daraufhin der Compiler beim Akteur P meldet, erhält er den Auftrag, den in der Sprache B formulierten Text D in die Maschinensprache zu übersetzen. Um diesen Rollenteil D kann nun der Akteur P seine bisherige Rolle erweitern. Er erhält dadurch zwar keine neue Bezeichnung, aber seine neue Rolle besteht nun aus dem Verbund der beiden Rollen P und D. Dieser so modifizierte Akteur mit dem unveränderten Namen P kann nun seinen früheren Dialog mit dem Benutzer fortsetzen.

Die Reihenfolge der Aktionen, die im Ablaufplan vorkommen, kann man auch dem Aufbauplan entnehmen. Denn der Benutzer kann nur mit aktiven Akteuren kommunizieren, und dem Ablaufplan kann man entnehmen, dass anfangs nur das Betriebssystem aktiv ist und dass die weiteren Akteure einer nach dem anderen aktiviert werden. Dies erkennt man daran, dass von den drei Kanälen, die den Benutzer mit seinen jeweiligen Kommunikationspartnern verbinden, zu Beginn nur derjenige, der zum Betriebssystem führt, nicht in einem Aktionsfeld liegt, in dem ein Akteur aufgebaut werden soll. Deshalb muss der erste zu aktivierende Akteur - das ist der Compiler A - auf Wunsch des Benutzers vom Betriebssystem aktiviert werden. Das Betriebssystem aktiviert zwar auch den Akteur P und den Compiler B, aber diese können nicht aktiviert werden, bevor der Compiler A aktiviert wurde. Denn zur Aktivierung des Akteurs P muss das Programm dieses Akteurs bereits in Maschinensprache vorliegen, und das ergibt sich erst als Ergebnis des Laufes des Compilers A. Und der Compiler B kann nicht aktiviert worden sein, bevor der Akteur P aktiviert wurde, denn nur dieser konnte dem Betriebssystem den Auftrag zur Aktivierung des Compilers B gegeben haben, da nur er einen Kanal hat, über den er anschließend den Compiler B beauftragen kann, die in Sprache B formulierte Programmerweiterung in die Maschinensprache zu übersetzen. Da der Akteur P der einzige ist, der auf die maschinensprachliche Form der Programmerweiterung lesend zugreift, kann nur er derjenige sein, der sich zum Verbundakteur erweitert.

zum Seitenanfang