Jochen Hettwer ist Mitarbeiter der interactive instruments GmbH in Bonn. Sein Aufgabenbereich umfasst u. a. die Betreuung der OKSTRA^®- Pflege in der bei der interactive instruments GmbH angesiedelten OKSTRA^®-Pflegestelle.

Dieser Beitrag beschreibt den Wechsel der Modellierungssprache zur Darstellung des OKSTRA^®- Referenzmodells von EXPRESS nach UML, erläutert die Motivation für die Umstellung, ihre technische Durchführung und die dabei getroffenen Designentscheidungen und gibt Informationen zu den zukünftigen Produkten der OKSTRA^®-Pflegestelle, die im Rahmen neuer OKSTRA^®- Versionen entstehen werden.

Einleitung

Den OKSTRA^® gibt es mittlerweile seit gut zehn Jahren. In dieser Zeit haben sich sowohl die Methoden zur Datenmodellierung als auch die IT-technischen Anforderungen an einen Standard wie den OKSTRA^® rasant verändert: Während in der Anfangszeit des OKSTRA^® Technologien  wie UML, XML, GML und OGC-Webservices noch in den Kinderschuhen steckten oder noch gar nicht auf der Bildfläche erschienen waren, sind sie heute unverzichtbare Bausteine der modernen Geoinformatik. Damit ergab sich auch für den OKSTRA^® ein stetiger Änderungsbedarf: Im Jahr 2002 wurde mit dem OKSTRA^®-XML erstmals ein GML-basiertes Datenaustauschformat veröffentlicht. Die Unterstützung der konzeptionellen SQL-Ableitung wurde im Jahr 2007 mangels Nachfrage eingestellt. Und im Jahr 2011 erfolgte ein weiterer Paradigmenwechsel auf dem Weg des OKSTRA^® in die IT-technische Zukunft: Die Umstellung des Referenzmodells von EXPRESS nach UML.

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

Einleitung

Den OKSTRA^® gibt es mittlerweile seit gut zehn Jahren. In dieser Zeit haben sich sowohl die Methoden zur Datenmodellierung als auch die IT-technischen Anforderungen an einen Standard wie den OKSTRA^® rasant verändert: Während in der Anfangszeit des OKSTRA^® Technologien  wie UML, XML, GML und OGC-Webservices noch in den Kinderschuhen steckten oder noch gar nicht auf der Bildfläche erschienen waren, sind sie heute unverzichtbare Bausteine der modernen Geoinformatik. Damit ergab sich auch für den OKSTRA^® ein stetiger Änderungsbedarf: Im Jahr 2002 wurde mit dem OKSTRA^®-XML erstmals ein GML-basiertes Datenaustauschformat veröffentlicht. Die Unterstützung der konzeptionellen SQL-Ableitung wurde im Jahr 2007 mangels Nachfrage eingestellt. Und im Jahr 2011 erfolgte ein weiterer Paradigmenwechsel auf dem Weg des OKSTRA^® in die IT-technische Zukunft: Die Umstellung des Referenzmodells von EXPRESS nach UML. 

Motivation für die Umstellung

Eine Umstellung des OKSTRA^®-Referenzmodells von EXPRESS nach UML war aufgrund der sich abzeichnenden Dominanz von UML im Bereich der Modellierungssprachen schon längere Zeit in der Diskussion. Nichtsdestoweniger gab es auch einige Gründe, die für die Beibehaltung von EXPRESS sprachen:

• Im Laufe der Zeit war in der Pflegestelle eine technische Infrastruktur für den Umgang mit EXPRESS-Modellen entstanden (Konsistenz-Checker, XML-Schema-Generator etc.), für die bei einem Umstieg in der Modellierungssprache ein Ersatz geschaffen werden musste.
• Die Verfahrenswege bei der Standardpflege und der Versionierung des Referenzmodells waren erprobt und eingespielt.
• Einige OKSTRA^®-Anwender hatten sich für die Arbeit mit dem OKSTRA^®-Referenzmodell EXPRESS-Tools angeschafft, die nach einer möglichen Umstellung nicht mehr für diesen Zweck verwendbar waren.
• Nachdem jedoch im Jahr 2010 in einer Machbarkeitsstudie die generelle Machbarkeit einer Umstellung festgestellt wurde und ein entsprechender Prototyp entstanden war, beschloss die Fachgruppe OKSTRA Ende 2010 die Durchführung der Umstellung. Maßgeblich dafür waren folgende Gründe:
• UML war inzwischen zum state of the art in der Datenmodellierung avanciert und infolgedessen deutlich weiterverbreitet als EXPRESS. Aus diesem Grund konnte davon ausgegangen werden, dass bei Software-Entwicklern generell mehr Kenntnisse über UML als über EXPRESS vorhanden sind. Darüber hinaus existieren weitaus mehr Software-Werkzeuge zum Umgang mit UML als mit EXPRESS.
• Die bisher getrennten Standard-Komponenten Referenzmodell (EXPRESS) und Dokumentation (NIAM-Diagramme) können durch die Umstellung in einem UML-Pflegetool zusammengeführt und integriert gepflegt werden, was entsprechende Synergieeffekte in der Arbeit der Pflegestelle erwarten lässt.
• Einige konzeptionelle Unschönheiten im bisherigen OKSTRA^®-Standard konnten durch die Umstellung beseitigt werden. Dies betraf u. a. den Bruch in der Geometrierepräsentation zwischen dem EXPRESS-Modell und dem OKSTRA^®-XML sowie das Vorhandensein von im Zusammenhang mit der Historisierung und den abstrakten Verweisen eingeführten „technischen“ Aspekten im EXPRESS-Modell, die dort aufgrund ihres konzeptionellen Charakters im Grunde nichts verloren hatten.
• Das OKSTRA^®-Referenzmodell konnte den ISO-Standards zur Modellierung von Geoinformationen angenähert werden, die ebenfalls UML verwenden. 

Technische Durchführung

Da eine vollständig händische Erstellung eines OKSTRA^®-UML-Modells aufgrund der Größe des Modells nicht in Betracht kam, wurde nach (zumindest teilweise) automatisierbaren Lösungen gesucht. Letztendlich entschied sich die Pflegestelle dafür, als UML-Pflegetool die Software „Enterprise Architect“ von der Firma Sparx Systems einzusetzen, die über ein OLE Automation-Interface angesprochen werden kann. Ein weiteres Element des Umstellungsprozesses war die OKSTRA-Klassenbibliothek OKLABI, in deren Schemadatenbank die gesamte Modellinformation der umzustellenden OKSTRA^®-Version 1.015 bereits vorlag. Mittels eines für die Umstellung entwickelten Java-Tools wurde die Modellinformation von der OKLABI abgefragt und über das OLE Automation-Interface des Enterprise Architect in ein Enterprise Architect-Projekt transportiert. Die Erstellung von UML-Klassendiagrammen, das Übertragen von Dokumentationstexten aus den NIAM-Dokumenten sowie einzelne Nachbearbeitungen des Modells erfolgten anschließend händisch.

Für die Fortführung der Standardpflege auf der Grundlage des UML-Modells wurde darüber hinaus ein neuer Weg zur Erzeugung des XML-Schemas für das OKSTRA^®-XML benötigt. Hierfür wurde ein mehrstufiger Ansatz realisiert, der aus folgenden Schritten besteht:

1. Automatisierte Erzeugung eines modifizierten Enterprise Architect-Projektes, in dem Mehrfachvererbung durch Einbettung beseitigt ist und Relationen und Schlüsseltabellen-Attribute durch Attribute bestimmter Datentypen ersetzt worden sind
2. Erzeugung des XML-Schemas aus dem modifizierten Enterprise Architect-Projekt mit dem Open-Source-Programm „ShapeChange“

Eine rtf-Dokumentation (die anschließend layouttechnisch nachbearbeitet und in das pdf-Format konvertiert wird) sowie eine HTML-Dokumentation können darüber hinaus direkt mit dem Enterprise Architect erzeugt werden. 

Designentscheidungen beim Aufbau des UML-Modells

Für den Aufbau des OKSTRA^®-UML-Modells wurden verschiedene Designentscheidungen gefällt, von denen einige an dieser Stelle erläutert werden sollen:

1. Für jedes OKSTRA^®-Fachschema wurde ein eigenes UML-Paket geschaffen, außerdem je eines für die Schlüsseltabellen und die Datentypen. Ein Fachschema-Paket enthält somit nur noch die Objektarten des jeweiligen Schemas, jedoch keine Schlüsseltabellen und Datentypen mehr. Damit wird der Modellaufbau klarer, und die Datentypen und Schlüsseltabellen können bei Ableitungen aus dem Modell einfacher in eine zentrale Basiskomponente überführt werden, die dann von allen Fachschemata benutzt werden kann.
2. Die Verwendung von Schlüsseltabellen und komplexen Datentypen in einer Objektart geschieht in Form von UML-Attributen, nicht in Form von Relationen. Damit konnte in den UML-Klassendiagrammen eine kompakte Darstellung erreicht werden. Außerdem entspricht dieses Vorgehen der Darstellung im EXPRESS-Modell, in dem die entsprechenden Eigenschaften im Bereich der Attribute aufgeführt wurden.
3. Der Mechanismus des symbolischen Verweises wurde überarbeitet: Im EXPRESS-Modell wurden einzelne Relationen mit der Möglichkeit des symbolischen Verweises ausgestattet (indem z. B. nicht auf den Netzknoten, sondern auf den Netzknoten_abstrakt verwiesen wurde). Da die Fähigkeit zum symbolischen Verweis jedoch letztlich nicht an einzelne Relationen, sondern an die Objektarten gebunden ist (entweder existieren für eine Objektart symbolische Kennungen oder nicht) und da es nicht begründbar war, warum bei einigen Relationen auf eine bestimmte Objektart ein symbolische Verweis möglich sein sollte, bei anderen hingegen nicht, wurde folgendes Verfahren eingeführt: Eine Objektart, die symbolische Verweise ermöglicht, wird mit dem Stereotype „FachId“ gekennzeichnet. Sämtliche Relationen auf eine solche Objektart erlauben den symbolischen Verweis. Die für die Realisierung der symbolischen Verweise im EXPRESS-Modell nötigen formalen Objektarten mit den Namenssuffixen „_abstrakt“ und „_Symbol“ konnten damit entfallen, was zu einer deutlich strafferen und klareren Darstellung in den Klassendiagrammen führt. Als weitere Regel wurde eingeführt, dass alle Objektarten, die von einer „FachId“-Objektart erben, ebenfalls über die Möglichkeit des symbolischen Verweises verfügen. Damit konnten in einigen Fällen Relationsziele durch Angabe einer spezialisierteren Objektart präzisiert werden: Wenn z. B. eine Relation zur Objektart Bundesland aufgebaut werden sollte und gleichzeitig ein symbolische Verweis ermöglicht werden sollte, dann musste die Relation im EXPRESS-Modell auf den Verwaltungsbezirk zeigen, weil nur dieser (als Oberklasse des Bundeslandes) den symbolischen Verweis unterstützte. Im UML-Modell kann eine solche Relation hingegen direkt auf das Bundesland gerichtet werden.
4. Da sich aus dem EXPRESS-Modell auf einem standardisierten, nicht beeinflussbaren Weg das CTE-Format ergab, mussten die Kardinalitäten aller Relationen, die auf eine historisierbare Objektart gerichtet waren, multipel werden, um ggf. mehrere historische Versionen referenzieren zu können. Dies galt sogar dann, wenn eine solche Relation aus konzeptioneller Sicht eindeutig war: Ein Nullpunkt gehört z. B. aus konzeptioneller Sicht zu genau einem Netzknoten. Da der Netzknoten jedoch eine historisierbare Objektart ist und somit der Fall auftreten kann, dass ein Nullpunkt mehrere historische Versionen des Netzknotens referenzieren können muss, wurde die Relation im EXPRESS-Schema multipel. Diese Regel wurde für das UML-Modell dahingehend geändert, dass die Kardinalitäten von Relationen immer so angegeben werden, wie sie aus konzeptioneller Sicht gemeint sind. Falls ein bestimmtes, aus dem UML-Modell abgeleitetes Produkt aufgrund der Historisierung eine multiple Kardinalität erfordert, dann muss dies bei der Generierung des jeweiligen Produktes sichergestellt werden. Dies gilt insbesondere für das XML-Schema.
5. Das UML-Modell verwendet zur Darstellung von Geometrien Datentypen gemäß dem internationalen Standard ISO 19107 „Geografic Information – Spatial Schema“. Damit wird der Bruch in der Geometriedarstellung zwischen dem Referenzmodell und dem OKSTRA^®-XML beseitigt. Das Geometrieschema aus dem EXPRESS-Modell konnte damit entfallen. Geometrien werden darüber hinaus in Form von Attributen verwendet und nicht mehr durch Erben von bestimmten Oberklassen vermittelt. Dadurch werden die OKSTRA^®-Objektarten befähigt, mehrere Geometrien desselben Typs besitzen zu können, die anhand der Rollenbezeichnungen der entsprechenden Attribute voneinander unterschieden werden können.
6. Elementare Datentypen werden aus dem internationalen Standard ISO 19103 „Geografic Information – Conceptual Schema Language“ übernommen bzw. aus dessen Typen abgeleitet, um eine weitgehende Kompatibilität mit den bestehenden internationalen Normen zu gewährleisten.

Zukünftige Produkte der OKSTRA^®-Pflege

Folgende Produkte wird die OKSTRA^®-Pflegestelle für künftige OKSTRA^®-Versionen bereitstellen:

• Das UML-Modell, und zwar als Enterprise Architect-Projekt sowie als Export im XMI-Format (in den Versionen XMI 1.1 und XMI 2.1),
• das XML-Schema für das OKSTRA^®-XML,
• eine pdf-Dokumentation zu den Inhalten des UML-Modells mit Beschreibungen der einzelnen Pakete und der darin enthaltenen Objektarten, Datentypen und Schlüsseltabellen,
• eine HTML-Dokumentation, die die Navigation innerhalb des Modells über Hyperlinks ermöglicht.