Die Erweiterbarkeit der Datenschnittstelle ist eines der Konzepte dieser
Diplomarbeit.
Weiter oben wurde bereits erläutert, welche Stationen der Datentransfer
vom MOBILE-Kernsystem zum GIS ArcView und umgekehrt durchläuft. Dieser
Abschnitt soll diese Stationen unter dem Aspekt erläutern, wie eine
Erweiterung möglich ist. Kern dessen ist eine Auflistung all jener
Klassen, Avenue-Scripte und Dokumentationen, die zu ändern, anzupassen
oder neu zu erstellen sind (siehe Tab. 5: Prüfliste
Konvertererweiterung am Ende dieses Abschnitts).
Grundlage jeder Erweiterung ist die Erweiterung der Grammatik der
Austauschrepräsentation. Sie ist das verbindliche Dokument, auf dessen
Basis die zur Erweiterung nötige Programmierarbeit auch in zwei Teams
aufgeteilt werden kann. Da die Austauschrepräsentation für beide
Richtungen gleich ist, kann ein geschlossener Konvertierungskreislauf zu
Testzwecken auch über nur eine Seite erfolgen, d.h. nur mit den
Java-Klassen oder nur mit den Avenue-Scripten. Testdateien können mit
jedem Texteditor, der reine ASCII-Dateien exportieren kann, erstellt werden.
Wichtig für die Erweiterung der Grammatik der Austauschrepräsentation
ist die Auswahl des zu konvertierenden Datentypen. In Frage kommen
gemäß der Konzeption dieser Schnittstelle nur MSL-Daten-Typen. Sie
sollten bereits vor der Änderung der Grammatik als von Mobile.MSL.MSLData
abgeleitete Klasse implementiert sein. Um ein Objekt der zu konvertierenden
Klasse in die Avenue-Repräsentation und zurück so übertragen zu
können, daß das zurückerhaltene Objekt ein Klon des Originals
ist, müssen sämtliche Felder der Klasse konvertiert werden. Um die
Konvertierung der Felder zu ermöglichen, kann es nötig sein, weitere
Konverter erstellen zu müssen, wenn die Felder keinem MSL-Daten-Typ
entsprechen, für den bereits ein Konverter existiert.
Mit der Erweiterung der Grammatik der Austauschrepräsentation einhergehen
sollte die Anpassung der Avenue-Repräsentation und deren Dokumentation
nach der Vorlage des Abschnitts Repräsentation der MSL-Datentypen in
Avenue (S.112).
Ein neu zu erstellender Konverter sollte bereits bestehende Konverter nutzen.
Auch wenn es in Avenue keine rekursiv verschachtelten Aufrufe von
Avenue-Scripten gibt, so bleibt es trotzdem möglich, das Parsen bzw.
Generieren von Teilstrukturen durch Aufruf nichtrekursiv verschachtelter
Avenue-Scripte durchzuführen. So greifen zum Beispiel die Konverter
für Point auf die Konverter für RealNumber
zurück, wie für die Konvertierung eines Punktes aus der
Austauschrepräsentation in die Avenue-Repräsentation illustriert
ist.
Charakteristisch für die bisher in Avenue erstellten Konverter ist,
daß sie bereits Vereinfachungen an der Avenue-Repräsentation
gegenüber der Austauschrepräsentation vornehmen, sofern das Ergebnis
eindeutig und ohne Informationsverlust bleibt. So kann auf die Typbezeichner
RealNumber innerhalb der Avenue-Repräsentation eines
Point verzichtet werden, da die Koordinatenangaben in einem
Avenue-Point stets als Gleitkommazahlen erfolgen.
Eine weitere Vereinfachung nähme dann MobileExtricatePoint vor.
In der nächsten Tabelle sind die für die Konvertierung erforderlichen
Konverter benannt. (vgl. auch die Übersicht in[Hup98a])
Zeile 1 und 6 sind die Java-seitigen Konverter zur Konvertierung in die bzw.
aus der Java-Repräsentation. Sie befinden sich im package
Mobile.GIS.ArcView.Convert. Die Zeilen 2 bis 5 geben die
Avenue-seitigen Konverter an. Sie befinden sich im ArcView-Projekt
Mobile.apr.
Die folgende Tabelle enthält die Prüfliste zur Erweiterung der
Konverter. Für "NewConverter" bzw. "newConverter" ist der
Name des neuen Konverters einzusetzen. Grundsätzlich sollten englische
Namen verwendet werden. Im Einzelfall kann es zu Namenskonflikten kommen, wenn
der Name einer Java-Klasse aus java.lang oder einem reservierten Wort gleicht.
Die Behebung ist den Quelldateien für den Typ Boolean zu entnehmen.