5.4.1 Kontrollfluß

Da das GIS als Server arbeitet soll, muß es über die Möglichkeit verfügen, Aufträge anderer Programme auszuführen. Die Grundlage dafür bietet das Betriebssystem MacOS an. Im Betriebssystem MacOS gibt es verschiedene Ebenen, auf denen Programme miteinander kommunizieren können. Die folgende Abbildung gibt eine Übersicht.

Das GIS ArcView verfügt auf der Plattform PowerMacintosh mit MacOS über die Möglichkeit des Empfangens und Sendens von AppleEvents (vgl. [ESR94a] und[ESR95b] zu "AppleEvent"). Für seine Funktion als Server ist nur die Möglichkeit des Empfangens von AppleEvents nötig.
Die zur Verfügung stehenden AppleEvents können mit Hilfe des Programms Scripteditor[16] ausfindig gemacht werden, indem das ArcView-Programmsymbol mit der Maus auf das Scripteditor- Programmsymbol gezogen wird. Es sind dies die AppleEvents open (öffnet ein ArcView-Projekt), print (druckt angegebene Dokumente), quit (beendet ArcView) und zweimal run (startet ArcView bzw. startet das als Zeichenfolge mit angegebene Avenue-Script).
Durch den AppleEvent run läßt sich ArcView so kontrollieren, als wäre das Avenue-Script direkt in ArcView gestartet worden.
Die zu Beginn der Implementation unter MacOS verfügbare JKD 1.0.2 von Sun bot keine dokumentierte Möglichkeit, AppleEvents direkt aus Java zu versenden. Zwar verfügte die JDK-Klassenbibliothek über entsprechende Klassen im package sun.macos.Appleevent.ae, jedoch sind die in der sun.*-package-Hierarchie vorhandenen Klassen von SUN als plattformabhängig eingestuft und daher absichtlich nicht dokumentiert. Zum Absetzen von Befehlen an das Betriebssystem wäre die Methode java.lang.Runtime.exec() konzipiert gewesen, die aber für MacOS nur leer implementiert ist.
Als Alternative blieb zunächst die Lösung, ein spezielles Apple-Script - AppleScriptProcessor genannt - zu verwenden, welches ein Verzeichnis überwacht und dort hineingeschriebene Dateien als Apple-Scripts[17] interpretiert und ausführt.
Mit Apple-Scripts ist es möglich, den Ablauf von Programmen zu kontrollieren. Hierzu wird der zum Sprachumfang von Apple-Script gehörende Befehl tell application verwendet. Ein Argument dieses Befehls ist der Programmname, ein weiteres ist u.a. der AppleEvent, der an das genannte Programm gesendet werden soll. Die folgende Tab. 3 gibt die Umsetzung von Apple-Script-Befehlen zu AppleEvents wieder.

Die Methode Mobile.Kernel.Macos.AppleScript.execute() stellt die Funktionalität, Apple-Scripts auszuführen, zur Verfügung. Die ursprüngliche Version schreibt zu diesem Zweck Dateien in das vom Apple-Script-Programm AppleScriptProcessor überwachte Verzeichnis, die dann vom AppleScriptProcessor ausgeführt werden. Die aktuelle Version 1.0 verwendet dagegen die AppleScript-Schnittstelle der von Apple hergestellten MRJ 2.0, die um die Klassen APPLEScript, AEDescUtilities und OSA aus dem package com.apple.MacOS erweitert werden mußte. Eine Anleitung für diese Erweiterung und die Programmtexte sind über[MRJ97] zugänglich.

Um ein bereits verfaßtes Avenue-Script starten zu können, muß bereits ein ArcView-Projekt geöffnet worden sein, in dem sich das zu startende Avenue-Script befindet. Zu diesem Zweck wird der AppleEvent open mit dem Projektnamen als Argument an den Finder gesendet. Anschließend kann ein Avenue-Script mit übergeben werden, das lediglich den Aufruf des bereits im geöffneten Projekt vorhandenen Avenue-Scripts enthält. Das folgende Apple-Script[18] zeigt den Aufruf eines in einem ArcView-Projekt vorhandenen Avenue-Scripts aus einem Apple-Script heraus:
(1) tell application ArcView
(2) activate
(3) run av.Run("MobileReadAll","3")
(4) end tell
Das vom Apple-Script aus gestartete Avenue-Script ist
av.Run("MobileReadAll","3").
Es startet das Avenue-Script MobileReadAll, das als Parameter die Zahl 3 als Zeichen erhält. Voraussetzung ist, das MobileReadAll im bereits geöffneten Projekt vorhanden ist.
Die Klasse Mobile.GIS.ArcView.ArcViewPrimitive stellt eine Reihe von Methoden zur Verfügung, die unter Verwendung der Klasse Mobile.Kernel.Macos.AppleScript den Zugriff auf ArcView erleichtern. Die wichtigste ist die Methode executeScript(), die einen Avenue-Script-Namen als Parameter erhält. Das so identifizierte Avenue-Script wird ausgeführt. Weitere Methoden können der folgenden Tabelle entnommen werden.

Die Klasse Mobile.GIS.ArcView.ArcViewPrimitive ist nicht Teil der Programmierschnittstelle zur Entwicklung von Bausteinen mit ArcView-Kopplung. (siehe gleichnamigen Abschnitt, S.119). Sie vefügt noch über keine hinreichende Fehlerbehandlung und stellt auch noch keine ausreichende Datenschnittstelle her. Die Methoden zum Setzen der Werte von globalen Variablen sind ausdrücklich nicht Teil der Datenschnittstelle, sondern stellen vielmehr eine Möglichkeit der Klassen der Kontrollschnittstelle dar, Daten mit steuerndem Charakter nach ArcView zu transferieren. Die für die Datenschnittstelle konzipierten Klassen
Mobile.GIS.ArcView.ArcViewData und Mobile.GIS.ArcView.ParameterList
sind im nächsten Abschnitt beschrieben.
Zur Programmierschnittstelle zur Entwicklung von Bausteinen mit ArcView-Kopplung gehört hingegen die Klasse
Mobile.GIS.ArcView.ArcView.
Sie enthält die Methode executeScript, die jedoch weitaus mächtiger ist als die Methode gleichen Namens in
Mobile.GIS.ArcView.ArcViewPrimitive.
Sie erhält eine Liste von MSL-Daten-Objekten als Parameter, überträgt diese Objekte unter Verwendung von
Mobile.GIS.ArcView.ArcViewData.transferTo()
nach ArcView und benutzt
Mobile.GIS.ArcView.ArcViewPrimitive.executeScript(),
um ein Avenue-Script in ArcView auszuführen. Nach Beendigung der Ausführung geht die Kontrolle wieder an
Mobile.GIS.ArcView.ArcView.executeScript()
zurück. Die zurückübertragenen Daten werden mittels
Mobile.GIS.ArcView.ArcViewData.transferFrom()
wiederum in Form einer Parameterliste zurückgegeben. Auftretende Fehler werden an Mobile.ErrorHandling, der zentralen Fehlerbehandlung des Mobile-Systems, weitergereicht.
Um zu verhindern, daß zwei Bausteine gleichzeitig ArcView benutzen, ist die Methode
Mobile.GIS.ArcView.ArcView.executeScript()
synchronisiert, d.h. es kann durch gegenseitigen Ausschluß immer nur einen Aufruf der Methode zur Zeit geben. Dieser Mechanismus wird durch das in der Programmiersprache reservierte Wort synchronized sichergestellt (vgl. [GJS96], S. 415 ff;[MSS96], S. 273ff).

Die Kommunikation zwischen dem Mobile-Kernsystem und ArcView wird in Form von Sessions betrieben. Der Umfang einer Session ist der des höchsten Experiments, also desjenigen Experiments, das während des aktuellen Experimentablaufs nicht Teil eines höheren Experiments ist.
Vor der Benutzung der Klasse Mobile.GIS.ArcView.ArcView durch einen Baustein muß ArcView initialisiert werden, um dem MOBILE-Kernsystem als Server dienen zu können. Dazu gehört das Starten von ArcView, das Öffnen des Projekts Mobile.apr, in dem sich die zu dieser Schnittstelle gehörenden Avenue-Scripte befinden, das Initialisieren globaler Variablen für das Projekt Mobile.apr. Deweiteren muß die Liste der bereits in ArcView importierten Projekte fortgeschrieben werden um zu verhindern, daß Projekte mehrfach importiert werden. Abschließend muß ArcView noch regulär beendet werden.
Der Verwaltung einer solchen Session dient die Klasse
Mobile.GIS.ArcView.Session.
Ihre Methode start() leistet die oben genannte Initialisierung. Sie wird durch den ersten Baustein aufgerufen, der ein Avenue-Script mittels
Mobile.GIS.ArcView.ArcView.executeScript()
ausführt. Die Überprüfung des Semaphors started verhindert das Starten mehrerer gleichzeitig ablaufender Sessions.
Die Methode Mobile.GIS.ArcView.Session.stop() sorgt für eine reguläre Beendigung von ArcView. Unter Verwendung der Methoden der Klasse Mobile.GIS.ArcView.ArcViewPrimitive schließt sie das laufende Projekt MobileSession.apr. Letzlich wird ArcView durch
Mobile.GIS.ArcView.ArcViewPrimitive.stop()
beendet. Sie wird jedoch nicht direkt aufgerufen, sondern durch
Mobile.GIS.ArcView.ArcView.stop(),
um zu verhindern, daß ArcView beendet wird, während noch Avenue-Scripte in Ausführung sind. Dies wird durch Synchronisierung mit
Mobile.GIS.ArcView.ArcView.executeScript()
erreicht.

In der Klasse Mobile.Kernel.MacintoshPaths werden alle für das MOBILE-System in Bezug auf das GIS ArcView benötigten Pfade gespeichert. Einige dieser Pfade werden mithin nicht mehr benötigt, da sie von der veralteten Version 0.1 der Klasse Mobile.Kernel.AppleScript verwendet wurden. Sie sind jetzt als deprecated, d.h. veraltet gekennzeichnet.
Diese Klasse ist die einzige, in der Pfade fest kodiert sind. Wenn die Schnittstelle in anderen Verzeichnissen installiert werden soll, so ist Java-seitig nur diese Klasse zu ändern und neu zu übersetzen. Avenue-seitig sind alle Pfade im Avenue-Script MobileInitArcView des ArcView-Projekts Mobile.apr enthalten. Sie müssen ebenfalls mit angepasst werden.

Für die Programmierschnittstelle zur Entwicklung von Bausteinen mit ArcView-Kopplung gibt es die Klasse Mobile.GIS.ArcView.Paths , die den einzigen unmittelbar dafür notwendigen Pfad bereitstellt:
Mobile.GIS.ArcView.Paths.getProjectPath()
gibt den Pfad zurück, in dem oder in dessen Unterverzeichnissen sich die für das Mobile-System einschließlich der von Bausteinen benötigten Projekte befinden müssen. Dazu zählt sowohl das Projekt Mobile.apr als auch diejenigen Projekte, die die für die Kopplung der einzelnen Bausteine benötigten Avenue-Scripte und Daten enthalten.

In der nächsten Abbildung ist der Kontrollfluß beim Aufruf des zu einem Baustein korrespondierenden Avenue-Scripts im Zusammenspiel mit dem Datenfluß in Abhängigkeit von der Zeit dargestellt. Dabei sind die Details des Datenflusses verborgen. Sie werden im anschließenden Abschnitt beschrieben.
Die Laufzeit verläuft in der Abbildung von oben nach unten. Der Kontrollfluß ist durch Pfeile mit weißen Spitzen, der Datenfluß durch Pfeile mit schwarzen Spitzen gekennzeichnet. Der Datenfluß an sich ist nicht in der Zeit festgelegt, es muß vielmehr durch den Kontrollfluß sichergestellt sein, daß die Daten, die von einem Programmteil produziert werden, nicht konsumiert werden, bevor sie vollständig sind. Dies ist dann der Fall, wenn
* im Diagramm alle Kontrollflüsse waagerecht verlaufen,
* der aufgerufene Programmteil später startet und früher endet als der aufrufende,
* alle als Rechteck dargestellten Programmteile in diesem Detaillierungsgrad das Produzieren bzw. Konsumieren unteilbar ausführen.
Über Start und Ende des Programmteils Baustein bzw. des Programms ArcView kann in erster Näherung vorausgesetzt werden, daß sie beide vor dem Aufruf der Methode von
Mobile.GIS.ArcView.ArcView.executeScript()
durch den Baustein begannen und nach deren Ende endeten. Die Abbildung zeigt genaugenommen den Verlauf des Kontrollflusses für alle nach deren ersten Aufruf gestarteten Aufrufe.
Genaugenommen reicht es jedoch, daß das als Server dienende Programm ArcView vor dem Eintreffen des ersten run-AppleEvents gestartet ist. Dieser wird über mehrere zwischenliegende Aufrufebenen durch
Mobile.GIS.ArcView.ArcViewPrimitive.executeScript()
ausgesendet. Durch die weiter oben beschriebene Verwaltung des Systemzustandes durch Mobile.GIS.ArcView.Session und die Überprüfung, ob die Session gestartet ist, wird erreicht, daß
Mobile.GIS.ArcView.ArcViewPrimitive.executeScript()
nicht aufgerufen wird, bevor die Session gestartet ist. Sofern die Session beim Aufruf von
Mobile.GIS.ArcView.ArcView.executeScript()
noch nicht gestartet ist, wir zuerst die Session und innerhalb dessen das Programm ArcView gestartet.
Nun ließe sich noch einwenden, daß ein weiterer Aufruf von
Mobile.GIS.ArcView.ArcView.executeScript()
so bald nach dem ersten erfolgen kann, daß zwar die Session im Zustand gestartet ist, aber das Programm ArcView noch nicht den Startvorgang abgeschlossen hat. Dies wird jedoch durch den wechselseitigen Ausschluß des Aufrufs von
Mobile.GIS.ArcView.ArcView.executeScript(),
der durch das reservierte Wort synchronized sichergestellt ist, gewährleistet.
Damit ist dann die notwendige Vorbedingung zum Aufruf von
Mobile.GIS.ArcView.ArcViewPrimitive.executeScript(),
daß das Programm ArcView gestartet sein muß, erfüllt.

[16] Das Programm Scripteditor dient auch dem Erstellen von AppleScripts
[17] Apple-Script ist das von Apple herausgegebene Beispiel für Script-Sprachen nach der sogenannten Open Scripting Architecture. (vgl.[App93], S. 1-13). Apple-Script entspricht in seiner Grundfunktionalität der des Finder, angereichert um Kontrollkonstrukte und das Senden und Empfangen von AppleEvents.
[18] Die Zeilennummern sind kein Bestandteil des Programms.