Enterprise Architect Add-In für die CASE Tool

EA Add-In für die CASE Tool-basierte Generierung von Geodatenbankschemas: Beispiel INSPIRE
119
Enterprise Architect Add-In für die
CASE Tool-basierte Generierung von
Geodatenbankschemas: am Beispiel des
INSPIRE Consolidated UML Models
Rico Vogel
Zusammenfassung
Mit der zunehmenden Etablierung von Geodateninfrastrukturen auf unterschiedlichen Ebenen der Verwaltung
und der Wirtschaft zielt das Geoinformationswesen verstärkt auf harmonisierte und standardisierte Geodaten und
Geoprozesse, deren Austausch interoperabel und automatisiert erfolgt. Neben Initiativen, wie der Infrastructure for
Spatial Information in the European Community (INSPIRE), die auf internationalen Normen und Standards
basieren, ist für Deutschland unter anderem die Geodateninfrastruktur Deutschland (GDI-DE) bedeutsam. Durch
diese Initiativen ergibt sich für geodatenhaltende Stellen neben der standardisierten Abgabe eigener Daten
zunehmend der Bedarf, diese Daten persistent in Datenmodellen ausgewählter GDI-Initiativen vorzuhalten und
diese Modelle in Bezug auf eigene Datenmodelle zu erweitern. Externe Datenmodelle, wie sie unter anderem durch
INSPIRE in plattformunabhängiger, aber maschinenlesbarer Form zur Verfügung gestellt werden, lassen sich
bedarfsorientiert erweitern und können über plattformspezifische Modellausprägungen in Quelltextform
transformiert werden, um beispielsweise Datenhaltungskomponenten zu generieren. Der vorliegende Beitrag zeigt
am Beispiel eines von Vogel (2011) entwickelten Ansatzes, wie das INSPIRE Consolidated UML Model unter
Erweiterung des Softwareentwicklungswerkzeuges Enterprise Architect weitgehend automatisiert in
PostgreSQL/PostGIS-Datenbanken abgebildet werden kann. Neben der Erzeugung strukturorientierter Skripte wird
explizit auch die Generierung inhaltsmodifizierender Quelltextstrukturen adressiert.
1
Hintergrund
Geodaten, wie sie durch terrestrische oder satellitengestützte Vermessungsverfahren, Digitalisierung,
oder Geoprozessierungen abgeleitet werden, sind häufig persistent zu speichern, um sie für weitere
Analysen oder kartographische Darstellungen vorzuhalten. Neben dateibasierten Techniken eignen sich
insbesondere Geodatenbanksysteme für die dauerhafte Speicherung (Brinkhoff 2013).
Zahlreiche Datenmodelle konnten sich in verschiedenen Fachdisziplinen etablieren, um Strukturen für
die Ablage der Geodaten anzubieten. Zur Abbildung häufig Entity Relationship (ER)-basierter
Datenmodelle in Datenbanken hat sich insbesondere die Data Definition Language (DDL) durchgesetzt.
Jüngere Entwicklungen im Bereich der Datenverarbeitung zielen dagegen auf eine generische
Modellierung von Datenstrukturen, häufig auf Basis der Unified Modeling Language (UML). Im
Hinblick auf eine persistente Datenhaltung besteht zudem ein Erfordernis zur Abbildung von UMLStrukturen in Datenbanken.
Diesbezügliche Ansätze und Automatisierungsbestrebungen resultieren insbesondere im Model
Driven Development (MDD, z. B. Beydeda et al. 2005), welches zunächst auf die Unterstützung der
objektorientierten Softwareentwicklung fokussierte, indem Klassenstrukturen in Quelltexten
ausgewählter Programmiersprachen abgebildet werden. Durch Mechanismen zur Transformation
zwischen unterschiedlichen Modellausprägungen erweist sich der MDD-Ansatz auch für die
Generierung von DDL-Skripten aus visuellen Modellen, wie UML-Klassendiagrammen, die einer
standardisierten Notation folgen, als praktikabel.
120
Rico Vogel
Enterprise Architect (EA) ist eine Software, welche ursprünglich insbesondere auf die UML-basierte
Modellierung abzielte und die in der von Vogel (2011) eingesetzten Version 7.5 auch MDDFunktionalitäten anbietet. Als Computer-Aided Software Engineering (CASE)-Werkzeug bietet EA
beispielsweise Templates zur Generierung von DDL-Code aus UML-Klassendiagrammen. Die
Funktionalität der genannten Version weist hinsichtlich der Transformation jedoch Einschränkungen
auf, insbesondere dann, wenn das exportierte DDL-Skript ohne zusätzliche Interaktionen in einem
Prozess durchlaufen werden soll, um ein vollständiges Datenbankschema zu generieren.
Zur Erreichung dieses Automatisierungsgrades wurde durch Vogel (2011) ein Prototyp eines EAAdd-Ins vorgestellt, welcher vollständig prozessierbare SQL-Skripte erzeugt. Neben DDL-Code können
diese Skripte auch um DML-Artefakte angereichert sein, um vordefinierte Literale der UMLStereotypen enumeration und codeList unmittelbar in die initiale Datenbankinstanz zu integrieren. Die
Abbildung von Multiplizitäten ist dagegen ein Beispiel für noch zu implementierende Funktionalität des
Prototyps.
Im Rahmen des Projektes ZENON (sZENarien ONline; Vogel 2013) ist der Einsatz dieses Add-Ins in
unterschiedlichen Phasen der Entwicklung eines webbasierten Entscheidungsunterstützungssystems
(Web-based spatial decision support system – WebSDSS) zum Aufbau von Testdatenbanken
vorgesehen. Ziel ist die Abbildung der vom WebSDSS repräsentierten Anwendungsdomäne
parametrisierter regionaler Zukünfte (Parameterized Regional Futures – PRFs; Schanze & Sauer 2011)
in einer Datenbank. Bei den PRFs handelt es sich um einen fragestellungs- und gebietsspezifischen
Szenarioansatz, der den regionalen und klimatischen Wandel umfasst und der exemplarisch für den
Freistaat Sachsen operationalisiert wird. Zentral ist die Formulierung und Parametrisierung sogenannter
Szenarien und strategischer Handlungsalternativen, welche zu Zukünften (Futures) kombiniert werden.
Der vorliegende Beitrag basiert überwiegend auf Vogel (2011). Er geht zunächst auf Grundsätze der
modellgetriebenen (Software-)Entwicklung ein und identifiziert einen technologischen Alternativansatz
(Abschnitt 2). In Abschnitt 3 wird das vereinfachend als ICUM bezeichnete INSPIRE Consolidated
UML Model vorgestellt. Abschnitt 4 stellt eine Implementierung des alternativen
Transformationsansatzes in Form eines Add-Ins für das CASE-Tool EA vor. Eine beispielhafte
Transformation des ICUM unter Anwendung des EA-Add-Ins in PostgreSQL/PostGIS-spezifisches
SQL ist Inhalt des 5. Abschnitts. Abschnitt 6 schließt den Beitrag mit einem Fazit und einem Ausblick,
der Perspektiven für die WebSDSS-Entwicklung im Projekt ZENON einschließt.
2
Model Driven Development und Enterprise Architect
Gemäß Balzert (2009: 80) werden Anforderungen und Entwürfe bei der klassischen
Softwareentwicklung durch abstrakte Modelle beschrieben. Anschließend erfolgt die Umsetzung der
Modelle in Quellcode durch Softwareentwickler. In der modellgetriebenen Entwicklung (MDD) werden
die Modelle zunächst formal beschrieben. Danach erfolgt eine automatisierte Generierung des
Programmcodes.
Im Allgemeinen basiert MDD auf drei Komponenten, einem Modell, einer Notation und CodeGeneratoren. Die Notation dient der formalen Beschreibung des Modells. Ein prominentes Beispiel ist
die UML, wobei im MDD insbesondere Klassendiagramme zum Einsatz kommen (z. B. Brown et al.
2005: 3 & 12). Die Transformation des Modells in programmiersprachenspezifische Quelltexte erfolgt
mit Hilfe von Code-Generatoren. UML-Klassendiagramme, die sich vor allem für die objektorientierte
Modellierung eignen, lassen sich mit Hilfe spezifischer Generatoren in objektorientierte
Programmiersprachen wie Java oder C# überführen.
In der MDD stehen unterschiedliche Modelltypen im Vordergrund. Ausgehend von Computational
Independent Models (CIMs), die von Rechnern im Allgemeinen nicht (eindeutig) interpretiert werden
können, werden vor allem plattformunabhängige Modelle (Platform independent model – PIM),
plattformspezifische Modelle (Platform specific model – PSM) und Code-Modelle (Code model – CM)
unterschieden.
EA Add-In für die CASE Tool-basierte Generierung von Geodatenbankschemas: Beispiel INSPIRE
121
Entsprechend werden verschiedene Transformationsschritte differenziert, im Speziellen CIM2PIM,
PIM2PSM und PSM2CM. Transformationen der Kategorie CIM2PIM erfolgen weitgehend interaktiv
(z. B. Najar 2006: 42), oder sie erfordern den Einsatz ergänzender Technologien, wie Optical Character
Recognition (OCR) zur Texterkennung oder Ontologien zur Erfassung von Zusammenhängen in einem
Fachvokabular, und können nur bedingt automatisiert werden. Auf Grund des meist hohen
Formalisierungsgrades der PIMs sind PIM2PSM-Transformationen und PSM2CM-Transformationen
überwiegend automatisierbar. Derartige Funktionalität wird insbesondere durch CASE-Tools angeboten.
Gemäß Balzert (2009: 80) können hinsichtlich der automatisierten Code-Generierung folgende
Vorteile identifiziert werden:
x Abstraktere Entwicklung (gegenüber Quelltextebene)
x Synchronisation zwischen Modell und Quelltext
x Wiederholbarkeit durch Automatisierung (der Quelltexterzeugung)
x Geringe Fehleranfälligkeit (gegenüber manueller Umsetzung).
Nachteilig werden dagegen nachstehende Aspekte angesehen (ebenda: 80):
x Rentabilität des Aufwandes erst bei wiederholter Quelltexterzeugung
x Erschwerte Fehlersuche (Debugger i. d. R. für Quelltexte)
x Höhere Effizienz manuell erzeugter Quelltexte.
(a)
PIM
122
Rico Vogel
(b) PSM
CREATE TABLE Integer (integerID integer NOT NULL);
CREATE TABLE Decimal (decimalID integer NOT NULL);
CREATE TABLE Real (realID integer NOT NULL);
CREATE TABLE Number (numberID integer NOT NULL);
ALTER TABLE Integer ADD CONSTRAINT PK_Integer PRIMARY KEY (integerID);
ALTER TABLE Decimal ADD CONSTRAINT PK_Decimal PRIMARY KEY (decimalID);
ALTER TABLE Real ADD CONSTRAINT PK_Real PRIMARY KEY (realID);
ALTER TABLE Number ADD CONSTRAINT PK_Number PRIMARY KEY (numberID);
ALTER TABLE Integer ADD CONSTRAINT FK_Integer_Number FOREIGN KEY (integerID)
REFERENCES Number (numberID);
ALTER TABLE Decimal ADD CONSTRAINT FK_Decimal_Number FOREIGN KEY (decimalID)
REFERENCES Number (numberID);
ALTER TABLE Real ADD CONSTRAINT FK_Real_Number FOREIGN KEY (realID) REFERENCES Number
(numberID);
(c) CM
Abbildung 2.1: MDD-Modellvarianten am Beispiel des ISO-Datentyps Number (gemäß ISO 19103:2005) in EA-spezifischer
UML-Notation (a und b) sowie als exportiertes Code model in SQL-Notation (c).
EA Add-In für die CASE Tool-basierte Generierung von Geodatenbankschemas: Beispiel INSPIRE
123
Enterprise Architect bietet als etabliertes CASE-Tool Werkzeuge zur MDD-Unterstützung. Gemäß
Sparks et al. (2010: 7) wird insbesondere die Model Driven Architecture (MDA) als MDD-Spezifikation
unterstützt, die als offener Standard unter anderem auf UML aufsetzt und die plattformunabhängige
Entwicklung von Applikationen spezifiziert. Beispielsweise werden im CASE-Tool Enterprise Architect
(EA) für PIM2PSM-Transformationen native built-in transformations angeboten, die das Generieren
plattformspezifischer Klassendiagramme unterstützen. Unter Einsatz von UML-Profilen, wie sie
beispielsweise für DDL, C#, Java, Enterprise JavaBeans (EJB), oder XML Schema Definition (XSD)
verfügbar sind, können je PIM mehrere PSMs erzeugt werden. PSM2CM-Transformationen werden in
EA dagegen in Form des Code engineering realisiert.
Wie exemplarisch aus Abbildung 2.1 ersichtlich, bietet EA für die PIM2PSM-Transformation
Funktionalität zur Auflösung von Generalisierungen sowie von Multiplizitäten in Relationstabellen.
Auch die Generierung von Primär- und Sekundärschlüsseln als typische Artefakte relationaler
Datenbanken erfolgt bei Transform Current Package (MDA-Transformation) standardmäßig durch EA.
Darüber hinaus werden enumeration- und codeList-Literale transformiert.
Aus Abbildung 2.1 geht weiterhin hervor, wie PSMs (b) in Skriptform (c) repräsentiert werden
können. Die dazu eingesetzte EA-Funktion Generate DDL … ist insbesondere für komplexe Modelle,
wie sie beispielsweise auf europäischer Ebene durch das ICUM an Bedeutung gewinnen, auf Grund
eingeschränkter Automatisierungsunterstützung der zu Grunde liegenden EA-Version unzureichend.
Da die Erzeugung von DDL-Fragmenten durch die Reihenfolge der Objekte im EA-Projekt Explorer
bestimmt wird, können folgende Defizite im erzeugten DDL-Skript identifiziert werden:
x eingeschränkte Berücksichtigung von Abhängigkeiten zwischen Klassen (z. B. Erzeugung
von abhängigen vor unabhängigen Klassen)
x dadurch begrenzte Möglichkeit zur automatisierten Erstellung der Datenbank
x Aufwand für erforderliche manuelle Modifikation der Reihenfolge der DDL-Fragmente
x eingeschränkte Praktikabilität insbesondere bei wiederholter Erstellung von
Datenbankschemas (z. B. bei neuen Modellversionen).
Als Alternative zum EA-basierten Code Engineering kann ein EA – Add-In dienen. Durch Nutzung
einer der EA-Programmierschnittstellen und der damit verbundenen Flexibilität zur Bereitstellung
individueller Lösungen lassen sich die aufgeführten Defizite unmittelbar adressieren. Bevor auf die
gewählte Variante eingegangen wird, erfolgt zunächst eine Vorstellung des ICUM.
3
INSPIRE Consolidated UML Model als Repräsentant komplexer
Domänenmodelle
Auf Grund der Vielfalt adressierter Themen sowie der referenzierten Komponenten, die komplexe
Strukturen aufweisen, werden die wesentlichen Aspekte des ICUM vorgestellt. In diesem Artikel wird
auf Release uml_model_r937.zip Bezug genommen, da diese Version als Referenz im Rahmen der
Entwicklung des in Abschnitt 4 vorgestellten Add-Ins dient. Hinsichtlich der Themen der Annexe II und
III der Infrastructure for Spatial Information in the European Community (INSPIRE) gibt es inzwischen
essenzielle Weiterentwicklungen. Für die Entwicklung des Add-Ins ist dies jedoch unerheblich, da die
Prozessierung veränderter oder erweiterter Schemas explizit als Anforderung formuliert wurde. Beim
ICUM handelt es sich um eine formale Beschreibung der Struktur der Geodaten der auf europäischer
Ebene zu etablierenden Geodateninfrastruktur INSPIRE, welche auf internationalen Normen und
Standards, insbesondere des Geoinformationswesens, basiert.
Entsprechend werden unter dem Begriff INSPIRE Consolidated UML Model die in Abbildung 3.1
dargestellten Komponenten verstanden:
x Foundation schemas,
x Generic Conceptual Model und
x Themes (INSPIRE application schemas).
Bei Foundation schemas (INSPIRE 2010: 49) handelt es sich um Container für Schemas externer
Anbieter. In der diskutierten ICUM-Version handelt es sich lediglich um das Harmonised Model des
124
Rico Vogel
Technischen Komitees 211 der ISO, welches die Schemas der ISO 19100er-Serie veröffentlicht. In
Abhängigkeit von sich verändernden thematischen Anforderungen können weitere Schemas ergänzt
werden.
Das Generic Conceptual Model (GCM; INSPIRE 2010: 32) des ICUM enthält 5 Pakete. Dabei
handelt es sich um abstrakte Basiskomponenten für die Modellierung thematischer INSPIREDatenspezifikationen. Diese Komponenten adressieren normative Regeln für Geometrien, Topologien,
temporale Repräsentationen, eindeutige Objekt-IDs, sowie Bezugssysteme (Spatial Reference Systems –
SRSs).
Abbildung 3.1: Hauptkomponenten des INSPIRE Consolidated UML Models.
Abbildung 3.2: Abhängigkeiten zwischen Klassen der INSPIRE application schemas am Beispiel des Paketes
Addresses (veränd. nach INSPIRE 2009: 18).
EA Add-In für die CASE Tool-basierte Generierung von Geodatenbankschemas: Beispiel INSPIRE
125
Die INSPIRE-Themes (INSPIRE 2010: 50, European Parliament 2007: 11–14) umfassen
Anwendungsschemata für die Datenthemen der Annexe I, II & III der INSPIRE-Direktive. Die
Entwicklung dieser Schemata erfolgt durch Thematic Working Groups (TWGs). In der vorgestellten
ICUM-Version existieren lediglich Pakete für die Themen des Annexes I (z. B. für Addresses).
Zwischen den Paketen Themes, Generic Conceptual Model und Foundation Schemas bestehen
Importbeziehungen (Stereotyp import; INSPIRE 2010: 52). Weitere Beziehungen existieren zwischen
den Komponenten innerhalb der drei Pakete. Abbildung 3.2 zeigt beispielhaft die Abhängigkeiten des
Paketes Addresses von den Paketen Cadastral Parcels, Geographical Names und Administrative Units,
des Themes-Paketes sowie von diesen zu Base Types des Generic Conceptual Models.
Bei den INSPIRE application schemas (ISO 19136, INSPIRE 2010: 10, 41 & 45) handelt es sich um
abstrakte Beschreibungen räumlicher Objekte und möglicher Inhalte INSPIRE-relevanter Geodaten.
Verschiedene Stereotypen charakterisieren unterschiedliche Klassen. Bei einem dataType handelt es
sich um einen strukturierten Datentyp und ein featureType beschreibt ein raumbezogenes Objekt gemäß
ISO 19136. Zudem handelt es sich bei einer Kodierung von Werten in Form von Literalen im Falle
unveränderlicher Listen um enumerations und im Falle modifizierbarer (i. d. R. erweiterbarer) Listen
um codeLists. Abbildung 3.3 zeigt neben Abhängigkeiten zwischen Klassen innerhalb des Paketes
Administrative Unit Repräsentanten für Klassen unterschiedlicher Stereotypen. Beispielsweise wird die
Klasse AdministrativeUnit als featureType modelliert und ResidenceOfAuthority als dataType. Im Falle
vordefinierter Literalwerte wird beispielsweise LegalStatusValue als unveränderliche enumeration und
AdministrativeHierarchyLevel als veränderliche codeList modelliert. Letztgenannte Klasse lässt sich bei
Bedarf um 7thOrder und weitere Werte ergänzen. Weitere Details und Modellierungsprinzipien finden
sich in der Literatur (z. B. Lutz & Friis-Christensen 2012).
Abbildung 3.3: INSPIRE Consolidated UML Model am Beispiel der Administrative Units mit möglichen Stereotypen (veränd.
nach INSPIRE 2009: 18).
126
4
Rico Vogel
Enterprise Architect – Add-In
Die in Abschnitt 2 genannten Defizite der in EA integrierten MDA-Technologie führen zu der
Überlegung einer verstärkten Automatisierung der Erzeugung von DDL/DML-Skripten (SQL-Skripten)
aus (komplexen) UML-Modellen. Ausgangspunkt ist die Nutzung der von Sparks et al. (2010: 1769–
1824) beschriebenen Automatisierung in Form des EA Add-In-Models als Alternative zur PSM2CMTransformation, wie sie als MDA-Funktionalität in EA zur Verfügung steht. Für WindowsBetriebssysteme eignet sich die Enterprise Architect-API für .NET als Basis der Entwicklung, wobei die
Implementierung beispielsweise in der Programmiersprache C# erfolgen kann. Die Option der
Umsetzung in einer anderen Programmiersprache wie Java wurde verworfen, da lediglich APIKomponenten älterer EA-Versionen verfügbar waren. Als Entwicklungsumgebung wurde Visual C#
2010 Express gewählt, da es sich um eine frei verfügbare Software handelt, welche die Entwicklung
graphischer Benutzungsoberflächen (Graphical User Interface – GUI) unterstützt.
Der als Inspire2Postgis bezeichnete Prototyp des EA-Add-Ins besteht aus zwei Paketen,
InspirePostgisEaAddIn und InspirePostgisLib. Wie aus Abbildung 4.1 hervorgeht, verwendet das als
InspirePostgisEaAddIn bezeichnete Add-In Komponenten der Programmbibliothek InspirePostgisLib.
Beide Pakete referenzieren zudem Komponenten der im Projektkontext als EA bezeichneten EA-API.
Als Kern des Add-Ins stellt InspirePostgisLib die Klasse MainAlgorithm zur Verfügung, die sich
insbesondere der Klassen SortedElementList und PlatformSpecificCodeModel bedient.
SortedElementList dient in erster Linie der Generierung einer Liste von Klassen eines übergebenen
UML-Modells wie dem in Abschnitt 3 vorgestellten ICUM, wobei die Sortierung einem rekursiven
Ansatz folgt, bei dem sämtliche Assoziationen im Modell traversiert werden, um die jeweils
unabhängigen Klassen zu identifizieren und in der Elementliste entsprechend früh zu positionieren. Die
Aufgabe der Klasse PlatformSpecificCodeModel liegt dagegen primär in der Generierung von DDLund DML-Ausdrücken für die einzelnen Elemente der Liste sortierter Klassen. Dies umfasst neben
x der Erzeugung von Datenbanktabellen (z. B. CREATE TABLE icum.CadastralParcel();),
x das Hinzufügen von Tabellenspalten (z. B. ALTER TABLE icum.CadastralParcel ADD
COLUMN cadastralParcelID integer NOT NULL;),
x das Setzen von Primär- und Sekundärschlüsseln (z. B. ALTER TABLE icum.CadastralParcel
ADD CONSTRAINT PK_CadastralParcel PRIMARY KEY (cadastralParcelID);),
x die Indexerzeugung (z. B. CREATE INDEX idx_CadastralBoundary_geometry ON
icum.CadastralBoundary USING GIST (geometry GIST_GEOMETRY_OPS);),
x die Eintragung von enumeration- oder codeList-Literalen (z. B. INSERT INTO
icum.AdministrativeHierarchyLevel (value, administrativeHierarchyLevelID) VALUES
('2ndOrder', 2);) oder
x das Einfügen von Geometriespalten (z. B. SELECT public.addgeometrycolumn ('icum',
'cadastralboundary', 'geometry', 25833, 'LINESTRING', 2);).
Zudem ermöglicht die Klasse PlatformSpecificCodeModel das Exportieren von SQL-Skripten, wobei
neben der Sortierung der Elemente des UML-Modells explizit die Reihenfolge der DDL/DMLAusdrücke Berücksichtigung findet. Beispielsweise erfordert die Modifikation einer Tabelle mittels
ALTER TABLE x die Existenz dieser Tabelle, was ein vorheriges Ausführen von CREATE TABLE x
impliziert. Auf Grund der multiplen Sortierung lassen sich die exportierten und häufig komplexen SQLSkripte vollständig ohne zusätzliche Interaktionen prozessieren und somit komplette (Geo-)Datenbanken
erzeugen.
EA Add-In für die CASE Tool-basierte Generierung von Geodatenbankschemas: Beispiel INSPIRE
127
Abbildung 4.1: Pakete, Klassen und Abhängigkeiten des Prototyps des Inspire2Postgis-EA-Add-Ins.
Die Klassen InspirePostGisEaAddIn und ElementResourceForm des Paketes InspirePostgisEaAddIn
fungieren als Clients für die soeben beschriebenen Klassen. Die Hauptklasse des Add-Ins,
InspirePostGisEaAddIn, dient primär der Herstellung der Verbindung zwischen dem Add-In und der
EA-Instanz. Dagegen stellt die auf System.Windows.Forms.Form basierende Klasse
ElementRessoureForm eine simple Windows-basierte GUI als Schnittstelle zwischen Nutzer und Add-In
bereit. Durch das Add-In werden folgende Menüpunkte angeboten:
x Define resource elements,
x Create sorted element list,
x Read sorted element list und
x Export to code model.
Define resource elements dient der Auswahl der verwendeten Ressourcen (PSM-Pakete im EAProjekt-Explorer). Im Falle der häufig gewünschten Einschränkung der Datenbankerzeugung für
ausgewählte Klassen eines komplexen Klassendiagramms ist ein Separieren dieser Klassen in ein
spezifisches Paket (Primärressource) erforderlich, welches explizit anzugeben ist.
Create sorted element list kapselt einen komplexen Algorithmus zur rekursiven Traversierung aller
Elemente der Primärressource, wobei die Klassen der Sekundärressourcen bei Bedarf, d. h. im Falle der
Referenzierung insbesondere in Form von Assoziationen, Aggregationen und Kompositionen,
einbezogen und ebenso traversiert werden. Ziel dieses Arbeitsschrittes ist die Erstellung einer commaseparated values (CSV)-Datei, welche alle erforderlichen Klassen in ihrer Sortierung, beginnend mit den
unabhängigen und gefolgt von den abhängigen, auflistet. Bei Bedarf können diese CSV-Dateien mittels
Read sorted element list später wieder eingelesen werden.
Export to code model erstellt für die noch im Speicher befindliche oder neu eingelesene Klassenliste
DDL/DML-Ausdrücke und fasst diese in einem SQL-Skript zusammen. Die gekapselte Funktionalität
berücksichtigt die o. g. Reihenfolge von DDL-Ausdrücken (z. B. Listung von ALTER TABLE x nach
CREATE TABLE x).
Die allgemeine Anwendung des Add-Ins folgt der oben aufgeführten Reihenfolge der Menüeinträge.
Dabei wird ein bereits in EA geladenes (EA-Projektdatei – EAP) oder importiertes (z. B. per XML
Metadata Interchange – XMI) Klassenmodell der Anwendungsdomäne vorausgesetzt.
5
INSPIRE-Beispieltransformation
Die Anwendung des EA-Add-In Prototyps erfolgte beispielhaft im Kontext der Projekte Hereplus
(http://www.hereplusproject.eu/) und EO2HEAVEN (http://www.eo2heaven.org/) und soll am Beispiel
des ICUM verdeutlicht werden. Dabei wird auf die Transformation der PIM-Variante des ICUM in eine
SQL-Variante als CM-Pendant abgestellt. Vorbereitend erfolgt die PIM2PSM-Transformation mittels
Transform current package mit einem modifizierten DDL-Code-Template (Sparks et al. 2010: 1169–
128
Rico Vogel
1203). In dem nicht näher beschriebenen Schritt erfolgt beispielsweise eine Transformation der in
Abbildung 3.3 dargestellten PIM-Variante der Administrative Units in die PSM-Form der Abbildung
5.1. Diese bildet die Basis der durch das EA-Add-In (Abschn. 4) realisierten PSM2CM-Transformation.
Abbildung 5.1: PSM des Paketes Administrative Units.
Für die persistente Datenhaltung im ICUM-Schema ist eine PostgreSQL/PostGIS-Datenbank
vorgesehen. Gemäß Brinkhoff (2013) handelt es sich um ein voll funktionsfähiges
Geodatenbanksystem, welches auf Basis der Simple Feature Access Specification (SFA) Konformität zu
den Entwicklungen des Open Geospatial Consortiums (OGC) aufweist. Zudem bietet die PostGISErweiterung Unterstützung von Geography Markup Language (GML), Koordinatentransformationen
und geometrische Aggregatfunktionen, Indexierung per Generalized Search Tree (GiST). Zentral sind
die Tabellen geometry_columns zur Erfassung von Geometrien und spatial_ref_sys für geodätische
Bezugssysteme (Spatial Reference System – SRS).
Unter der Voraussetzung, dass im EA-Projektexplorer eine PSM-Variante des ICUM verfügbar ist,
wird zunächst das zu transformierende Paket Themes selektiert. Sollte lediglich eine Auswahl von
Klassen transformiert werden, sind diese in einem neuen Paket (z. B. Selection) zu separieren.
Anschließend werden in einer durch Define resource elements geöffneten Eingabemaske das zu
transformierende Paket (Default resource package) ausgewählt und zusätzliche Ressourcen festgelegt
(Additional resource package). Im Beispiel sind dies Themes als Primärressource sowie ergänzend
ISO TC211 und Generic Conceptual Model als von Themes verwendete Sekundärressourcen.
Im Anschluss erfolgt per Create sorted element list die Erstellung einer CSV-Datei mit einer Liste
sortierter Klassen, die zunächst unabhängige und später abhängige Klassen enthält (Abb. 5.2). Gemäß
EA Add-In für die CASE Tool-basierte Generierung von Geodatenbankschemas: Beispiel INSPIRE
129
den Abhängigkeiten in Abbildung 3.1 werden im Allgemeinen zunächst Klassen des ISO TC211Paketes gelistet, gefolgt von Klassen aus Generic Conceptual Model und schließlich Klassen der
INSPIRE-Themes. Die Reihenfolge ergibt sich dabei unter anderem aus den Abhängigkeiten zwischen
einzelnen Themen, wie sie aus Abbildung 3.2 resultieren. Klassen abhängiger Pakete können jedoch
auch früh gelistet werden, wenn die Klassen keine Abhängigkeiten zu komplexen Klassen aufweisen.
Beispiele hierfür sind enumerations und codeLists (z. B. AdministrativeHierarchyLevel des Paketes
Administrative Units).
Counter,Name,ID,Stereotyp,GUID
1,CharacterSetCode,5020,table,{23AAA8D0-0AD6-496b-9010-C75D67E7614C}
2,Character,5019,table,{495329CA-61CB-48c5-891D-A776B7E38A18}
3,Sequence<Character>,5023,table,{E3E2A4DC-08CA-4a71-931B-3CF7A79B15C0}
4,CharacterString,5021,table,{A5449847-B0C6-4ae4-9F09-8DA156B7B4FB}
5,Identifier,5155,table,{9C933D33-E056-4180-98DB-2F65BD7AFE2D}
6,AdministrativeHierarchyLevel,5723,table,{C7CB8B48-AB89-43dd-98F2-B4100B41ABE9}
7,PT_FreeText,3244,table,{28C524F7-4DD6-48c8-9E8E-4B4EF752557C}
8,LanguageCode,3072,table,{493BCC64-545A-461b-B7E8-8853479F9D5D}
9,CountryCode,3055,table,{B928FE8C-CAF7-4c9f-987B-E8D68D4989C7}
...
21,CI_RoleCode,4462,table,{3F3FD6D6-69F1-4575-A361-F4F62E2424CC}
22,CI_ResponsibleParty,4461,table,{36078373-A82D-4db6-AF65-F2E28042367C}
23,PT_LocaleContainer,3246,table,{FCA86CF4-EE8A-4677-8075-BE0BAEC7CA88}
24,LocalisedCharacterString,3243,table,{4443F791-0D1F-4116-A215-32A3BDBC4E53}
25,NativenessValue,5773,table,{F5893E7E-40DA-4692-9820-1C2FAE75633A}
26,NameStatusValue,5772,table,{2511D490-2FCE-423c-BA15-5306E5E1DCA3}
27,URI,3176,table,{F3AAD0FB-4D1A-482c-AF05-DEF76F8C205C}
28,PronunciationOfName,5774,table,{63752544-C99D-4977-9007-51D9972AC2E6}
29,SpellingOfName,5775,table,{19A3564C-8FB7-48d3-83E8-EA402E7CF9CB}
...
43,AddressLocator,5704,table,{4028DA2F-D2EB-4966-A010-C480EDBE4E8B}
44,AddressRepresentation,5705,table,{2F2158A5-BAEB-4fdd-96AB-3BA8A60644A7}
45,Address,5701,table,{DE3D10FE-2CBC-40ca-8467-835068A06D43}
46,AddressComponent,5703,table,{53121139-CF1D-4ce3-9D0C-6320A22D5CA9}
47,AdminUnitName,5706,table,{66EAB370-529F-4a9f-84AC-84B18CE362A7}
...
51,UnitOfMeasure,4963,table,{D62CA841-51F3-49e2-B12F-849DD375B97D}
52,UomArea,4967,table,{8FAA3CD4-D23A-4b1c-A228-BE696AAE4B42}
53,Measure,4957,table,{5A40874A-E999-4197-8A27-087C9AAD7059}
...
57,CadastralBoundary,5734,table,{EEFE77DE-DF21-431a-B18A-1217E0636DE5}
58,CadastralParcel,5731,table,{A0BF3FC0-90F3-4f90-9065-DA9D144A9E23}
59,BasicPropertyUnit,5733,table,{E7BF8605-72E3-44a4-B749-9F29FBB7A9BB}
60,AdministrativeUnit,5724,table,{A19FFC08-A500-4a16-917D-772EEFDF9B5E}
Abbildung 5.2: Sorted element list am Beispiel des ICUM (Auszug).
Mit Read sorted element list können die CSV-Dateien erneut eingelesen werden, falls das EA-Projekt
zu einem späteren Zeitpunkt neu geladen wird. Anschließend, beziehungsweise wenn sich die Sorted
Element List noch im Arbeitsspeicher befindet, lässt sich mit Export to code model eine SQL-Datei
erzeugen, in der neben der Element-Sortierung die Reihenfolge von DDL- und DML-Ausdrücken
Berücksichtigung findet (s. o.). Abbildung 5.3 verdeutlicht den Aufbau dieser Ergebnisdatei. Diese
repräsentiert die CM-Variante des ICUM und kann ohne zusätzliche Interaktionen als SQL-Skript mit
einem Kommandozeilen-Client oder einem GUI-basierten Client, zu dem pgAdmin III zählt, zur
Erzeugung von PostgreSQL/PostGIS-Datenbanken eingesetzt werden.
130
Rico Vogel
CREATE TABLE icum.CharacterSetCode();
CREATE TABLE icum.Character();
CREATE TABLE icum.SequenceCharacter();
CREATE TABLE icum.CharacterString();
CREATE TABLE icum.Identifier();
CREATE TABLE icum.AdministrativeHierarchyLevel();
...
CREATE TABLE icum.AdminUnitName();
CREATE TABLE icum.MeasureType();
CREATE TABLE icum.Number();
CREATE TABLE icum.Real();
...
CREATE TABLE icum.CadastralBoundary();
CREATE TABLE icum.CadastralParcel();
CREATE TABLE icum.BasicPropertyUnit();
CREATE TABLE icum.AdministrativeUnit();
...
ALTER TABLE icum.SequenceCharacter OWNER TO icum;
...
COMMENT ON COLUMN icum.CharacterSetCode.value IS 'Reference to complex data type:
CharacterString';
...
SELECT public.addgeometrycolumn ('icum', 'residenceofauthority', 'geometry', 25833,
'POINT', 2);
SELECT public.addgeometrycolumn ('icum', 'geographicposition', 'geometry', 25833,
'POINT', 2);
SELECT public.addgeometrycolumn ('icum', 'cadastralboundary', 'geometry', 25833,
'LINESTRING', 2);
SELECT public.addgeometrycolumn ('icum', 'cadastralparcel', 'geometry', 25833,
'GEOMETRY', 2);
SELECT public.addgeometrycolumn ('icum', 'cadastralparcel', 'referencePoint', 25833,
'POINT', 2);
SELECT public.addgeometrycolumn ('icum', 'administrativeunit', 'geometry', 25833,
'MULTIPOLYGON', 2);
...
CREATE INDEX idx_ResidenceOfAuthority_geometry ON icum.ResidenceOfAuthority USING GIST
(geometry GIST_GEOMETRY_OPS);
CREATE INDEX idx_GeographicPosition_geometry ON icum.GeographicPosition USING GIST
(geometry GIST_GEOMETRY_OPS);
CREATE INDEX idx_CadastralBoundary_geometry ON icum.CadastralBoundary USING GIST
(geometry GIST_GEOMETRY_OPS);
...
ALTER TABLE icum.Identifier ADD CONSTRAINT PK_Identifier PRIMARY KEY (identifierID);
ALTER TABLE icum.AdministrativeHierarchyLevel ADD CONSTRAINT
PK_AdministrativeHierarchyLevel PRIMARY KEY
(administrativeHierarchyLevelID);
...
ALTER TABLE icum.Length ADD CONSTRAINT PK_Length PRIMARY KEY (lengthID);
ALTER TABLE icum.CadastralBoundary ADD CONSTRAINT PK_CadastralBoundary PRIMARY KEY
(cadastralBoundaryID);
ALTER TABLE icum.CadastralParcel ADD CONSTRAINT PK_CadastralParcel PRIMARY KEY
(cadastralParcelID);
ALTER TABLE icum.BasicPropertyUnit ADD CONSTRAINT PK_BasicPropertyUnit PRIMARY KEY
(basicPropertyUnitID);
ALTER TABLE icum.AdministrativeUnit ADD CONSTRAINT PK_AdministrativeUnit PRIMARY KEY
(administrativeUnitID);
...
ALTER TABLE icum.CadastralParcel ADD CONSTRAINT
FK_CadastralParcel_cadastralBoundaryID_integer FOREIGN KEY (cadastralBoundaryID)
REFERENCES icum.integer (integerID);
ALTER TABLE icum.BasicPropertyUnit ADD CONSTRAINT
FK_BasicPropertyUnit_inspireId_Identifier FOREIGN KEY (inspireId) REFERENCES
icum.Identifier (identifierID);
ALTER TABLE icum.BasicPropertyUnit ADD CONSTRAINT
FK_BasicPropertyUnit_nationalCadastralReference_CharacterString FOREIGN KEY
(nationalCadastralReference) REFERENCES icum.CharacterString (characterStringID);
ALTER TABLE icum.BasicPropertyUnit ADD CONSTRAINT FK_BasicPropertyUnit_areaValue_Area
FOREIGN KEY (areaValue) REFERENCES icum.Area (areaID);
...
INSERT INTO icum.AdministrativeHierarchyLevel (value, administrativeHierarchyLevelID)
VALUES ('1stOrder', 1);
...
Abbildung 5.3: Code model mit DDL- und DML-Ausdrücken am Beispiel des ICUM (Auszug).
EA Add-In für die CASE Tool-basierte Generierung von Geodatenbankschemas: Beispiel INSPIRE
6
131
Fazit und Ausblick
Der vorliegende Beitrag verdeutlicht, wie mit Hilfe eines CASE-Tools, ausgehend von der
konzeptuellen Modellierung, eine weitgehend automatisierte Erzeugung von Geodatenbanken realisiert
werden kann. Basierend auf UML-Klassendiagrammen und unter Anwendung des verbreiteten CASETools EA sowie durch die Entwicklung eines Prototyps für eine EA-Extension wird dargelegt, inwiefern
MDD-basierte Transformationen einen hohen Automatisierungsgrad zur Erzeugung von
Geodatenbanken unterstützen können. Um eine Abbildung des gesamten (ICUM-)Schemas zu
vermeiden, wurde auf die Realisierung des Mindesterfordernisses an Klassen fokussiert. Dies bedeutet,
dass bei Bedarf lediglich die von Referenzierungen betroffenen Bestandteile des Datenbankschemas
einbezogen werden und die nicht benötigten Klassen (bzw. Tabellen) im CM keine Berücksichtigung
finden. Damit lässt sich die Komplexität der Datenbank unter Umständen erheblich reduzieren.
Hinsichtlich des Einsatzes des EA-Add-Ins besteht trotz erfolgreicher Tests ein Erfordernis für
Weiterentwicklungen. Anpassungsbedarf besteht insbesondere im Hinblick auf die Abbildung von
Multiplizitäten, welche in der Generierung zusätzlicher Relationstabellen resultiert.
Grundsätzlich eignet sich die Extension für die Transformation weiterer (raumbezogener)
Datenmodelle, wie dem 3A-Modell. Das von der Arbeitsgemeinschaft der Vermessungsverwaltungen
der Länder der Bundesrepublik Deutschland (AdV) veröffentlichte Modell (AdV 2009), welches ebenso
als EA-Projekt verfügbar ist, repräsentiert AFIS-ALKIS-ATKIS. XPlanGML ist ein weiteres Beispiel,
welches unter anderem auf den interoperablen Austausch von Bebauungsplänen abzielt.
Darüber hinaus kann das EA-Add-In WebSDSS-Entwicklungsprozesse forcieren. Unterschiedliche
ZENON-Entwicklungsphasen (z. B. Vogel im vorliegenden Band) werden beispielsweise durch die
Verfügbarkeit von PRF-Daten geeigneter Data Concretization States (DCSs) unterstützt, wobei die
Abstraktionsgrade abstract, arbitrary, mockup und genuine unterschieden werden (Vogel et al. 2015:
108). In der Domänenmodellierung (AP2) dienen abstrakte Testdaten in Objektdiagrammen der
Validierung von Klassendiagrammen. Eine futureB lässt sich als Kombination aus scenarioA und
strategicAlternativeB definieren und eine futureC kombiniert scenarioA mit strategicAlternativeC
(ebenda: 107). Zudem können Datenhaltungskomponenten, wie sie von Vogel (2013) vorgesehen sind,
für PRF-Daten unterschiedlicher DCSs vorbereitet werden. In frühen Entwicklungsphasen kann bereits
der funktional eingeschränkte Prototyp des EA-Add-Ins eingesetzt werden. Dazu wird das von Vogel et
al. (in Vorb.) in AP2 formalisierte PRF-Domänenmodell als PIM-Variante über eine
PostgreSQL/PostGIS-spezifische PSM-Variante in ein SQL-Skript transformiert, welches als CM zur
Erzeugung eines Schemas einer PRF-Datenbank dient. Während der Systementwicklung (AP3) können
mittels Factory-Klassen Objektinstanzen wie futureB oder futureC einer Klasse Future erzeugt werden,
um die PRF-Datenbank zu füllen und Datensätze im Rahmen von Tests (AP5) abzurufen.
CASE-Tools wie EA wurden seit den hier vorgestellten Arbeiten von Vogel (2011) erheblich
weiterentwickelt. Neue EA-Versionen, aber auch Extract, Transform and Load (ETL)-Tools, wie
Feature Manipulation Engine (FME), verfügen ebenfalls über Komponenten, die hohe
Automatisierungsgrade bei der Erzeugung von Datenbanken erzielen. Entsprechende Werkzeuge sind
gegebenenfalls weitere Optionen zur Datenbankerzeugung, unter anderem weil sie in der Lage sind,
weitere Ausgabeformate beziehungsweise PSMs und CMs zu generieren. Gemäß Kirchenbauer (2009:
28) lassen sich beispielsweise mit Rational Rose aus dem 3A-UML-Diagramm XML (GML)
Schemadateien erstellen.
132
Rico Vogel
Literatur
AdV: Dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungswesens
(GeoInfoDok). Version 6.0.1, Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder
der
Bundesrepublik
Deutschland,
2009,
Im
Internet:
URL:
http://www.advonline.de/icc/extdeu/binarywriterservlet?imgUid=8f830072-8de8-9221-d5ad8f138a438ad1&uBasVariant=11111111-1111-1111-1111-111111111111 [Stand 12. März 2015].
Balzert, H.: Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering. 3. Aufl.,
Lehrbücher der Informatik, Spektrum, Akad. Verl., Heidelberg 2009.
Beydeda, S.; Book, M.; Gruhn, V. (Eds.): Model-Driven Software Development. Springer, Berlin,
Heidelberg 2005.
Brinkhoff, T.: Geodatenbanksysteme in Theorie und Praxis: Einführung in objektrelationale
Geodatenbanken unter besonderer Berücksichtigung von Oracle Spatial. 3., überarb. und erw.
Aufl., Wichmann, Berlin 2013.
Brown, A.W.; Conallen, J.; Tropeano, D.: Introduction: Models, Modeling, and Model-Driven
Architecture (MDA). In: Beydeda, S.; Book, M.; Gruhn, V. (Eds.): Model-Driven Software
Development. Springer: Berlin, Heidelberg 2005, 1–16.
European Parliament: Directive 2007/2/EC of the European Parliament and of the Council of 14 March
2007 establishing an Infrastructure for Spatial Information in the European Community
(INSPIRE). Off. J. Europ. Union 50 (2007) L 108, 1–14.
INSPIRE: INSPIRE Data Specification on Administrative units – Guidelines. INSPIRE Thematic
Working Group Administrative units, Data Specification D2.8.I.4, 2009, Im Internet: URL:
http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AU_
v3.0.pdf [Stand 08. Januar 2015].
INSPIRE: INSPIRE Generic Conceptual Model. Tech. Rep. D2.5, Version 3.3, Drafting Team Data
Specifications,
2010,
Im
Internet:
URL:
http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.5_v3_3.pdf [Stand 22. Juli
2014].
ISO 19103:2005: Geographic information – Conceptual schema language. International Organization for
Standardization, 2005.
ISO 19136:2007: Geographic information – Geography Markup Language (GML). International
Organization for Standardization, 2007.
Kirchenbauer, V.: Evaluierung und Überführung von Bebauungsplänen des Digitalen
Informationssystems Planrecht (DIP) in die Geodateninfrastruktur der Freien und Hansestadt
Hamburg unter Berücksichtigung des Standards XPlanung. Diplomarbeit, Hochschule Karlsruhe,
2009,
Im
Internet:
URL:
http://www.iai.fzk.de/wwwextern/fileadmin/Image_Archive/Bauwerke/GeoInformationssysteme/XPlanung/XPlanung/Dokumente/Diplomarbeit_Kirchenbauer_Vera.pdf
[Stand: 09. April 2015].
Lutz, M.; Friis-Christensen, A.: Tutorial: Using Enterprise Architect with a central UML repository.
INSPIRE
Consolidation
Team,
JRC,
2012,
Im
Internet:
URL:
https://www.seegrid.csiro.au/wiki/pub/AppSchemas/ConfiguringUMLToolForHollowWorld/INS
PIRE_uml_howtopdf__EN_2.0.pdf [Stand 18. Februar 2015].
Najar, C.R.: A Model-Driven Approach to Management of Integrated Metadata – Spatial Data in the
Context of Spatial Data Infrastructures. PhD thesis, ETH Zürich, 2006, Im Internet: URL:
http://www.igp-data.ethz.ch/berichte/Blaue_Berichte_PDF/90.pdf [Stand 09. April 2015].
Schanze, J.; Sauer, A.: Dokumentation des fragestellungs- und gebietsspezifischen Szenarioansatzes.
REGKLAM Ergebnisbericht Produkt 2.4a (Konzept), 2011, unveröffentlicht.
EA Add-In für die CASE Tool-basierte Generierung von Geodatenbankschemas: Beispiel INSPIRE
133
Sparks, G.; O'Bryan, D.; McNeilly, S.; Capey, N.; Mancarella, S.; Redfern, J.; Kumar, V.; Britten, H.;
Maxwell, B.; Meagher, S. (Eds.): Enterprise Architect User Guide. Sparx Systems, 2010, Im
Internet: URL: http://www.sparxsystems.com/bin/EAUserGuide.pdf [Stand 16. Juni 2010].
Vogel, R.: Automatisierte Generierung von Geodatenbankschemata aus dem INSPIRE Consolidated
UML Model. 1. Workshop der GDI Sachsen: INSPIRE-Umsetzung im Freistaat Sachsen, SMI
Dresden,
Präsentation,
2011,
Im
Internet:
URL:
http://www.gdi.sachsen.de/inhalt/info/archiv2011/110516/110510_GDIWS_8_RicoVogel.pdf
[Stand 09. April 2015].
Vogel, R.: ZENON – Entwicklung eines WebSDSS zur Abschätzung der Folgen des Klimawandels und
des gesellschaftlichen Wandels. In: Strobl, J.; Blaschke, T.; Griesebner, G.; Zagel, B. (Eds.):
Angewandte Geoinformatik 2013: Beiträge zum 25. AGIT-Symposium Salzburg, Wichmann:
Berlin,
Offenbach,
2013,
227–232,
Im
Internet:
URL:
http://gispoint.de/fileadmin/user_upload/paper_gis_open/537533082.pdf [Stand 12. März 2015].
Vogel, R.:
Prototypische
Technologieintegration
für
ein
WebGIS-basiertes
Entscheidungsunterstützungssystem auf der Basis aktueller Softwarekomponenten und
Frameworks. 18. Workshop „Modellierung und Simulation von Ökosystemen“, Kölpinsee 2014,
im vorliegenden Band.
Vogel, R.; Neubert, M.; Sauer, A.: Data Concretization States as Metadata of Parameterized Regional
Futures in a WebSDSS Development Context. In: Rückemann, C.-P.; Doytsher, Y. (Eds.):
GEOProcessing 2015, The Seventh International Conference on Advanced Geographic
Information Systems, Applications, and Services, IARIA: Lisbon, 2015, 106–109, Im Internet:
URL:
http://www.thinkmind.org/download.php?articleid=geoprocessing_2015_6_10_30031
[Stand 12. März 2015].
Vogel, R.; Sauer, A.; Schanze, J.: Object-Oriented Domain Modeling of a Regional Climate Change
Scenario Approach as a central WebSDSS Development Artifact. N.N., in Vorbereitung.