4  Das Objektorientierte Paradigma

In der Informatk hat sich die Objektorientierung zu einem dominierenden Pradigma ent­wickelt und zeichnet sich dadurch aus, daß es unterschiedliche Aspekte der Softwaretech­nologie in einem Konzept integriert. Objektorientierte Ansätze können auf unterschied­lichen Ebenen des Entwicklungsprozesses zur Anwendung kommen (vgl. WORBOYS 1995, S. 84f.; BILL 1996, S. 330; LEYKAUF/ ALBRECHT 1993, S. 49):

• Techniken der Objektorientierten Analyse (OOA) und des Objektorientierten Designs (OOD) werden bei der Strukturierung des Anwendungsproblems auf der konzeptionellen Ebene eingesetzt und lösen hiermit relational geprägte Modelle wie das ERM ab..

• Die Umsetzung in das logische Modell wird von der Verwendung eines objekt­orientierten Datenbankmanagementsystems geprägt.

• Die Implementierung erfolgt in einer objektorientierten Programmiersprache wie C++, Java oder Smalltalk.

Abbildung 8: Der objektorientierte Ansatz



Quelle: SCHADER/ RUNDSHAGEN 1994, S. 15

Das Grundprinzip läßt sich folgendermaßen charakterisieren: Ein Datenobjekt, das einen Teil der realen Welt repräsentiert, wird zusammen mit den zugehörigen Methoden in einer Einheit gekapselt. Andere Programmteile können das so eingekapselte Objekt nur über diese Methoden ansprechen und zu Aktionen veranlassen. Dies führt zu einer Modularisierung, indem funktionale Bereiche eines Software-Systems in selbständige und nur über definierte Schnittstellen manipulierbare Komponenten zerlegt werden (BILL 1996, S. 330; RALSTON 1995, S. 166).

4.1 Grundlegende Konzepte

4.1.1 Das Objekt

Der Begriff des Objekts wird im Objektorienierten Paradigma in zweierlei Hinsicht ver­wendet (FRITSCH/ANDERS 1996, S. 4):

1. Externe Objekte sind die zu modellierenden Elemente der Realwelt, die für einen be­stimmten Anwendungskontext von Bedeutung sind. Diese können dinglicher Natur sein (z.B. Straßen, Flurstück, Teich) als auch abstrakte Begriffe (z.B. Prozesse, Vor­gänge, Beziehungen) beschreiben.

2. Interne Objekte sind die Repräsentationen der externen Objekte in einem EDV-System.

Da sich die vorliegende Arbeit mit Datenmodellen im Sinne einer Repräsentation in einem Computer beschäftigt, werden hier in erster Linie interne Objekte angesprochen.

Jedes Objekt ist aufgrund seines Objektidentifikators (OID) systemweit eindeutig zu iden­tifizieren. Diese OID ist völlig unabhängig vom Zustand des Objektes, d.h. der Wertebe­legung der Attribute. Deshalb ist es möglich, daß zwei verschiedenen Objekte denselben Zustand besitzen, aber anhand ihrer OID noch differenziert werden können (FRITSCH/ANDERS 1996, S. 4). Hier liegt ein deutlicher Unterschied zum Relationalen Modell, wo die Tupel anhand ihrer Attributwerte unterschieden werden, ohne daß eine davon unabhängige, inhärente Identität gegeben wäre (GÜNTHER 1998, S. 111f.).

4.1.2 Klassen

Eine Klasse faßt eine Menge möglicher Objekte zusammen, die Gemeinsamkeiten hin­sichtlich ihrer Eigenschaften, ihren Beziehungen zu anderen Objekten und ihrer Semantik aufweisen. In der Klasse wird festgelegt, über welche Attribute die Eigenschaften seiner Objekte beschrieben werden. Auf Objektebene werden diese Attribute mit individuellen Werten belegt, die das Objekt charakterisieren. Strukturell kann jedes Objekt zusätzlich zu seinen Attributwerten auch in seinen Beziehungen zu anderen Objekten beschrieben werden. Die korrespondierenden Klasse definiert, von welcher Art das Bezugsobjekt ist, d.h. zu welcher Klasse es gehört (RUMBOUGH u.a. 1993, S.28). Beispielsweise wird in der Klasse „Flurstück“ festgelegt, daß Objekte diesen Typs über die Attribute „Flurstücks­nummer“ und „Fläche“ sowie über eine Beziehung zu einem Objekt der Klasse „Person“, die den Eigentümer bezeichnet, beschrieben werden.

Abbildung 9: Klassen und Objekte



Quelle: Eigener Entwurf

Neben der Strukturbeschreibung besitzt die Klasse darüberhinaus einen semantischen Charakter. In Abhängigkeit des Anwendungszwecks können Repräsentationen von Entitäten der Realwelt unterschiedlichen Klassen im Datenmodell zugeordnet werden. Obwohl sowohl ein Universitätsgebäude als auch ein Warenhaus über einen Wert, eine Grundfläche und eine Geschoßzahl verfügen, können sie unterschiedlichen Klassen ange­hören, falls in der Modellierung die Eigentümerstruktur und der Verwendungszweck be­rücksichtigt werden soll. Faßt der Entwickler beide Objekte lediglich als Immobilien auf, können sie einer gemeinsamen Klasse angehören. Hier wird die Bedeutung der Klasse innerhalb der Objektorientierung für die Abbildung eines Realitätsausschnittes in einem Datenmodell deutlich: durch die Abstraktion des Anwendungsproblems können Einzelbe­obachtungen auf Kategorien generalisiert werden (RUMBOUGH u.a. 1993, S. 28).

Die Zugehörigkeit des Objekts zu einer Klasse als eine Instanz derselben ist eine implizite Eigenschaft jeden Objekts. Die meisten objektorientierten Programmiersprachen können die Klasse eines Objekts zur Laufzeit des Programms feststellen (SCHADER/ KUHLINS 1996, S. 166).

Der Begriff „Objekttyp“ wird häufig synonym für „Klasse“ benutzt. In einer engen Aus­legung besteht aber folgender Unterschied: auf der konzeptionellen Ebene fassen Objekt­typen Objekte mit ähnlichen Eigenschaften und Verhalten zusammen, die dann auf der Implementierungsebene in Klassen mit den entsprechenden Datenstrukturen und Methoden abgebildet werden (WORBOYS 1995, S. 86). Da diese Unterscheidung aber in der Literatur nicht durchgängig Anwendung findet, wird in der vorliegenden Arbeit der Begriff „Objekttyp“ bzw. „Typ“ dann verwendet, wenn die Art eines Objektes betont werden soll, während die Klasse sowohl die Art als auch die konkrete Implementierung beschreibt.

4.1.3 Vererbung

Das Vererbungskonzept stellt eine Möglichkeit dar, Gemeinsamkeiten zwischen verschiedenen Klassen redundanzfrei zu teilen und gleichzeitig die Eigenheiten der jeweiligen Klassen zu erhalten. Eine Klasse kann von einer anderen Klasse abgeleitet werden, wobei die neue Unterklasse (Subklasse) alle Eigenschaften ihrer Oberklasse (Superklasse) erbt (RUMBOUGH u.a. 1993, S. 48). Damit geht dieses Modellierungs­konstrukt über das reine Bilden einer Begriffshierarchie hinaus. Der Unterschied soll an­hand eines Beispiels aus dem (nicht objektorientierten) ATKIS - Objektartenkatalog auf­gezeigt werden (SCHELLERER 1992, S. 17f.; BORCHERT 1994, S. 30):

Der Objektartenkatalog ist hierarchisch in Objektbereiche, Objektgruppen und Objektarten gegliedert. Die beschreibenden Attribute werden aber erst in der untersten Stufe, der Objektart, und damit auf dieser Ebene redundant definiert.

Abbildung 10: Ausschnitt ATKIS-Objektartenkatalog



Quelle: Nach BORCHERT 1994, S. 30 , verändert

In einem objektorientierten Entwurf würden die Attribute „Bezeichnung“, „Funktion“ und „Zustand“ in einer Oberklasse (hier sowohl in „Straßenverkehr“ als auch in „Verkehr“ möglich“) definiert und automatisch an die Klassen „Straße“, „Weg“ und „Platz“ weiter­vererbt. Im Gegensatz zu der Begriffshierarchie in ATKIS, die auf drei Ebenen begrenzt ist, kann die Vererbung über beliebig viele Stufen weitergeführt werden. Die Höhe des dabei entstehenden Baumes hängt damit nur davon ab, wie sinnvoll und aussagekräftig das Datenmodell ist. Grundsätzlich unterscheiden sich die Klassenhierarchien in den ver­schiedenen Programmiersprachen darin, daß z.B. in Smalltalk und Java alle Klassen von einer systemseitig definierten „Urklasse“ abstammen und damit einen Baum bilden, während andere Sprachen wie C++ einen Wald ergeben, da mehrere benutzerdefinierte Wurzeln möglich sind (HEUER 1992, S.209).

Je nach Blickrichtung bzw. Verwendungszweck kann man das Vererbungskonzept als Generalisierung bzw. Spezialisierung betrachten. Bei der Generalisierung werden die Gemeinsamkeiten mehrerer Klassen zu einer Superklasse zusammengefaßt, während die Spezialisierung die Individualität einzelner Klassen gegenüber einer gemeinsamen Super­klasse betont. Ausgehend von obigem Beispiel könnte die Klasse „Straße“ entsprechend dem Attribut „Widmung“ in die Unterklassen „Autobahn“, „Bundesstraße“, „Landesstraße“, „Kreisstraße“, „Gemeindestraße“ und „Sonstige Straßen“ aufgespalten werden.

Abbildung 11: ATKIS-Ausschnitt als Klassendiagramm



Quelle: Eigener Entwurf

Der semantische Charakter der Klasse und ihre Bedeutung für die Datenmodellierung wird durch die Vererbung betont. Schon beim Entwurf des Datenmodells muß entschieden werden, welche Aspekte der Entitäten primär betrachtet werden und welche Rolle sie im Gesamtkontext der Anwendungsproblematik wahrnehmen. Im obigen Beispiel ist der thematische Aspekt der Objekte das Kriterium für die Hierarchiebildung. Ein wichtiges Charakteristikum interner Objekte in einem GIS ist ihre geometrische Repräsentation, die darüber entscheidet, welche Analysefunktionen zur Verfügung stehen. Im entsprechenden Maßstab werden Straßen und Wege zu Linien generalisiert, während Plätze als Polygone dargestellt würden. Wendet man diesen Aspekt hier an, wird die Klasse „Plätze“ von einer anderen Klasse abgeleitet als „Straße“, und „Weg“.

Abbildung 12: Klassenvererbung anhand der Geometrie



Quelle: Eigener Entwurf.

4.1.4 Assoziation

Mit Hilfe der Assoziation werden auf Klassenebene Verknüpfungen zwischen Objekten modelliert. Insofern besteht eine Analogie zu der Beziehung eines Objektes zu seiner Klasse: ein Objekt ist eine Instanz seiner Klasse, während eine Verknüpfung zwischen zwei oder mehreren Objekten eine Instanz einer Assoziation zwischen Klassen darstellt. In der Aussage „Theo Huber ist-Eigentümer-von Flurstück Nummer 0815“ wird ein Objekt der Klasse „Person“ über eine Instanz der binären Assoziation „ist-Eigentümer-von“ mit einem Objekt der Klasse „Flurstück“ verknüpft. Die in der Benennung ausgedrückte Richtung der Assoziation kann auch in der entgegengesetzten Richtung durchlaufen werden, indem die Assoziation als „ist-Eigentum-von“ formuliert wird. Die Multiplizität einer Assoziation spezifiziert, wieviele Instanzen einer Klasse mit einer Instanz einer assoziierten Klasse verknüpft sein können (RUMBOUGH u.a. 1993, S. 34).

4.1.5 Aggregation

Die Aggregation ist eine Sonderform der Assoziation, da die hiermit abgebildete Be­ziehung zwischen Objekten eine „Teil-Ganzes“-Relation darstellt. Beispielsweise drückt die Darstellung eines Polygons als eine Sequenz von Linienstücken aus, daß das einzelne Linienstück Teil des Polygons ist und dieses wiederum von der Existenz dieses Linien­stücks abhängt. Der Unterschied zu einer normalen Assoziation besteht darin, daß durch das Zusammensetzen der einzelnen Komponenten ein neuer Begriff mit eigener Identität und zusätzlichen Eigenschaften definiert wird. Erst die sinnvolle Gruppierung der Linien­stücke zu einem Polygon läßt die Interpretation zu, daß damit eine Fläche mit einem Flächen­inhalt und einem Umfang repräsentiert wird. Da die Aggregation transitiv ist, kön­nen „Teil-Ganzes“-Relationen über mehrere Ebenen hinweg modelliert werden. Dadurch können komplexe Objekte übersichtlicher in Stufen zerlegt werden (RUMBOUGH u.a. 1993, S. 46f.).

Abbildung 13: Aggregation



Quelle: Eigener Entwurf.

4.1.6 Verhalten

Neben den datenbezogenen Eigenschaften seiner Objekte beschreibt die Klasse auch das mögliche Verhalten und die Operationen, die auf den Instanzen angewendet werden kön­nen. Diese sind in Fom von Methoden implementiert. Eine Fläche wird damit nicht nur durch die begrenzenden Linien repräsentiert, sondern bietet darüberhinaus Funktionen, die bestimmte Werte ermitteln (Flächeninhalt, Umfang, Schnittoperation mit anderer Fläche) oder Aktionen auslösen (Darstellung auf einem Ausgabegerät, Skalierung). Während im ERM nur die Datenebene betrachtet wird, ergänzt die Objektorientierung diese Sicht um die objektbezogene Funktionalität und erfaßt damit die statisch-datenorientierten sowie die dynamisch-verhaltensbezogenen Aspekte von Informationen (WORBOYS 1995, S. 85).

Das Konzept der Vererbung bezieht sich ebenfalls auf das Objektverhalten. Eine Unter­klasse erbt nicht wie im ERM nur die Attribute seiner Oberklasse, sondern auch die dort definierten Operationen und kann diese durch Überschreiben anpassen (overriding) und zusätzliche Methoden definieren (SCHADER/ KUHLINS 1996, S.255).

Jedes Objekt verfügt über zwei spezielle Methoden: den Konstruktor und den Destruktor. Der Konstruktor wird aufgerufen, sobald das Objekt im Speicher erzeugt bzw. „konstruiert“ wird. Hier finden die für das Objekt wichtigen Initialisierungen statt. Ein Aufruf des Destruktors erfolgt, sobald das Objekt gelöscht wird. Damit kann der Pro­grammierer sicherstellen, daß alle von dem Objekt beanspruchten Systemressourcen wieder freigegeben werden (SCHADER/ KUHLINS 1996, S. 170) .

4.1.7 Polymorphismus

Polymorphismus steht für die Eigenschaft von Objekten, zur Laufzeit eines Programmes verschiedene Typen darstellen zu können. Wie bereits erwähnt, ist die Zugehörigkeit eines Objekts zu seiner Klasse eine implizite Eigenschaft jeden Objektes. Durch das Konzept der Vererbung wird dieser Aspekt erweitert: da eine Unterklasse als eine Teilmenge seiner Oberklasse mit speziellen Merkmalen angesehen werden kann, ist es möglich, jedes Objekt dieser Unterklasse auch als ein Exemplar der Oberklasse zu interpretieren (BILL 1996, S. 340f.). Die Autobahn mit der Bezeichnung „A6“ ist eine spezielle Ausprägung des allgemeineren Falles „Straße“ mit den zusätzlichen Eigenschaften, daß die erlaubte Höchstgeschwindigkeit unbegrenzt sein kann und die Zuständigkeit für die Instandhaltung bei einer Bundesbehörde liegt. Mit den anderen Straßen teilt sie die Eigenschaften, daß sie thematisch dem Bereich Verkehr zugeordnet ist und hinsichtlich ihres baulichen Zustands einstufbar ist.

4.2 Weiterführende Konzepte

4.2.1 Abstrakte und konkrete Klassen

Ein weiteres Konzept, das sich indirekt aus der Generalisierung ableitet, betrifft die Fest­legung einer Klasse als abstrakt. bzw. konkret. Der Unterschied besteht darin, daß von einer abstrakten Klasse keine Instanzen direkt erstellt werden können, sondern nur von abgeleiteten konkreten Klassen. Diese Festlegung ist dann von Nutzen, wenn eine Super­klasse lediglich der Definition eines Konzepts dient, dessen unterschiedlichen Ausprägungen in den abgeleiteten Klassen spezifiziert werden müssen (SCHADER/ KUHLINS 1996, S.262). In dem in Abbildung 12 dargestellten Beispiel ist es nicht möglich, ein Geometrie–Objekt zu erstellen, wohl aber Objekte vom Typ Punkt, Linie und Fläche. Angenommen, in der Klasse Geometrie ist eine Methode „Auf_Bildschirm_zeichnen“ definiert, die an die Subklassen weitervererbt wird, so kann diese in der Geometrie-Klasse nicht implementiert werden, da diese nicht über die not­wendigen Daten in Form von Koordinatenwerten verfügt. Erst in den abgeleiteten Klassen stehen diese Daten zur Verfügung und für jede Klasse muß eine Funktion programmiert werden, die das entsprechende Objekt auf einem Bildschirm anzeigt.

4.2.2 Mehrfachvererbung

Die bisher betrachtete einfache Vererbung erlaubt maximal eine Oberklasse. Eine Er­weiterung stellt das Konzept der Mehrfachvererbung dar, wobei eine Unterklasse von mehreren Oberklassen erben kann.¹ Dadurch kann in einem Datenmodell ausgedrückt werden, daß ein und dasselbe Objekt in in einem anderen Kontext eine andere Rolle er­füllt. Beispielsweise stellt eine Schleuse einmal ein Bauwerk, ein anderes Mal ein Ver­kehrshindernis dar oder ein Grundstück umfaßt sowohl eigentumsrechtliche als auch widmungsrechtliche Aspekte. Wesentlich dabei ist, daß die Identität eines Objektes davon nicht betroffen ist, sondern lediglich für ein Objekt in einem anderen Anwendungskontext andere Eigenschaften und Verhaltensmerkmale von Bedeutung sind (BARTELME 1995, S. 151).

Abbildung 14: Mehrfachvererbung



Quelle: Eigener Entwurf.

4.2.3 Kapselung

Dieses auch als „information hiding“ bezeichnete Prinzip dient der Datenabstraktion einer Klasse. Dabei wird die abstrakte Sicht auf die Objekte gezielt von der internen Implemen­tierung getrennt, indem einige Eigenschaften eines Objekts als „privat“, d.h. nur für das Objekt selbst zugänglich, deklariert werden. Die öffentlichen Eigenschaften bilden die Schnittstelle (das „Interface“) der Klasse, über die die Objekte diesen Typs angesprochen werden können. Durch diese Deklaration kann das System unerlaubte Manipulationen auf den Objekten unterbinden. An der internen Realisierung können nachfolgend Änderungen vorgenommen werden, die sich auf andere Bereiche der Software nicht auswirken, solange die Schnittstelle unverändert bleibt (FRITSCH/ANDERS 1996, S. 5).

4.3 Objektorientierte Datenbanken

Ein objektorientiertes Datenbankmanagementsystem ist ein DBMS mit einem objektorientierten Datenmodell. Diese Definition impliziert zwei Sachverhalte (GÜNTHER 1998, S. 111):

1. Ein OODBMS enthält die volle Funktionlität eines modernen DBMS und bietet Merkmale wie Sekundärspeicherverwaltung, parallelen Zugriff mehrerer Benutzer, Recovery, Unterstützung von ad hoc-Abfragen, verteilte Datenbanken und Integritäts­bedingungen.

2. Ein OODBMS bietet die Merkmale objektorientierter Systeme wie Objektidentitäten, Klassen und Vererbung, komplexe Objekte und benutzerdefinierte Datentypen.

Mit strukturell objektorientierten DBMS können beliebig komplexe Objekte modelliert werden, während verhaltensmäßig objektorientierte Systeme die Definition von Typen mit eigenen Methoden erlauben. Voll objektorientierte Systeme unterstützen sowohl strukturelle als auch verhaltensmäßige Merkmale (FRITSCH/ANDERS 1996, S. 7).

Durch die zunehmende Bedeutung neuer Anwendungsbereiche wie GIS, CAD, Bildver­arbeitung oder Automatisierungstechniken (Computer Aided Manufactoring - CAM), den sog. Nicht-Standard-Anwendungen, werden an die Datenbanktechnik Anforderungen hin­sichtlich der Flexibilität und Strukturierung gestellt, die konventionelle Systeme wie die relationalen DBMS nicht erfüllen können. Die auf dem Objektmodell basierenden Systeme bieten diese geforderten Merkmale: Bildung komplexer Objekte, Schnittstellen zu objektorientierten Programmiersprachen und weitestgehend redundanzfreie Daten­modellierung (ROCHE 1996, S. 6f.).

In der Praxis können OODBMS als eine Erweiterung von objektorientierten Programmier­sprachen angesehen werden, da die meisten Systeme direkt auf die Anbindung an eine Sprache wie C++, Java oder Smalltalk aufbauen (FRITSCH/ANDERS 1996, S. 6). In einem normalen Softwaresystem werden Objekte zur Laufzeit des Programms erzeugt und stehen spätestens zu dem Zeitpunkt nicht mehr zur Verfügung, an dem das Programm be­endet wird. Sollen die in einem Objekt gekapselten Daten auch zu einem späteren Zeit­punkt verfügbar sein, müssen sie zunächst auf einen Sekundärspeicher geschrieben werden. Objektorientierte Datenbanksysteme bieten hierzu die Möglichkeit, den Inhalt der Objekte in einer speziellen Struktur abzulegen, mit deren Hilfe es möglich ist, nicht nur einfache Datentypen wie Zahlen und Zeichenketten sondern auch Referenzen zwischen Objekten dauerhaft zu speichern. Wird dann ein Objekt aus der Datenbank gelesen, prüft das Datenbanksystem, ob sich die von diesem Objekt referenzierten Instanzen bereits im Arbeitsspeicher befinden und liest diese gegebenenfalls dorthin aus. Die gespeicherten Referenzen werden dann in Adressen des Arbeitspeichers umgewandelt, die die Stelle bezeichnen, an der das Objekt nun vorliegt und über die man jetzt auf das Objekt zu­greifen kann (SCHADER 1997 , S.13).

Im Unterschied zu relationalen Datenbanken fehlten objektorientierten Datenbank­systemen lange Zeit eine klare theoretische Fundierung und entsprechende Festlegungen, über welche Eigenschaften ein objektorientiertes Datenbankmanagementsystem verfügen muß. Erste Ansätze dazu lieferten ATKINSON u.a. 1992, indem sie obligatorische und optionale Merkmale erstmals publizierten. Um auf dem kommerziellen Datenbanksektor einen Standard aufzustellen, haben sich mehrere Hard- und Softwarehersteller (z.B. IBM, Poet, ONTOS, O₂) zur „Object Database Management Group“ (ODMG) zusammenge­schlossen. Dabei werden mit dem Standard vorrangig zwei Ziele verfolgt:

• Ein standardkonformes Anwendungsprogramm soll ohne Änderung des Sourcecodes auf unterschiedlichen Datenbankprodukten und in verschiedensten Hard- und Software­umgebungen übersetzbar und lauffähig sein.

• Auf die Datenbanken sollen in verschiedenen Programmiersprachen entwickelte An­wendungsprogramme gleichzeitig zugreifen können. Momentan stehen hier die objektorientierten Programmiersprachen C++ und Java im Vordergrund, vereinzelt wird auch Smalltalk unterstützt.

Die Standardisierung betrifft lediglich die Schnittstelle, über die die Produkte ange­sprochen werden können, wobei die Art der internen Datenverwaltung voneinander ab­weicht. Grundbestandteile des Standards sind ein Objektmodell, die Objektdefinitions-Sprache ODL (Object Definition Language) und die Anfragesprache OQL (Object Query Language) (SCHADER 1997, S. 1ff.; HELOKUNNAS 1994, S. 1201f.).

Das ODMG-Objektmodell spezifiziert, welche Softwareeinheiten in der Datenbank ge­speichert werden können und welche Merkmale objektorientierter Systementwicklung anwendbar sind. Der Standard unterstützt Vererbungsstrukturen und verwendet diesen Mechanismus, um Objekte benutzerdefinierter Klassen persistenzfähig zu machen. Dazu ist eine Klasse d_Object definiert, die über Fähigkeiten zum Schreiben und Lesen seiner Datenfelder verfügt und damit als Superklasse für alle benutzerdefinierten persistenten Klassen dient. Jedes persistente Objekt erhält vom Datenbanksystem eine eindeutige Identität, die für die gesamte Lebensdauer des Objekts gültig bleibt, auch wenn sich des­sen Eigenschaften ändern. Die Eigenschaften der Objekte können mit Hilfe von Literalen (long, short, float, double, string usw.) sowie über Beziehungen zu anderen Objekten be­schrieben werden. Neben diesen atomaren Objekten sind auch diverse Collection-Typen, d.h. Objektmengen, definiert (set, bag, list, array), die sich darin unterscheiden, ob die Menge geordnet ist und ob Duplikate gestattet sind (SCHADER 1997, S. 10 ff.).

4.4 Eignung objektorientierter Konzepte für GIS

4.4.1 Unterschiede zu einem Layer-GIS

Da objektorientierte Methoden in erster Linie programmiertechnische Konzepte betreffen, stellt sich die Frage, inwiefern ein potentieller GIS-Anwender von diesen Strukturen profitieren kann. BARTELME sieht in diesem Zusammenhang zunächst folgende Unter­schiede objektorientierter Lösungen zu layerorientierten Strategien als wesentlich an (BARTELME 1995, S. 151f.):

• Betonung des Individuums: Ausgangspunkt der Modellierung sind einzelne Objekte, die mit anderen gleichartigen Objekten zu Klassen zusammengefaßt werden.

• Abkehr von strenger Hierarchie: Jedes Objekt kann mit Hilfe der Mehrfach­vererbung mehreren Klassen zugeordnet werden. Dieses Konstrukt sollte aber aus Gründen der Übersichtlichkeit nur Ausnahmefällen Anwendung finden.

• Dynamik: Anstatt der starren ebenenbezogenen Einteilung sind flexible Zusammen­fassungen möglich.

• Verhalten: Neben seinen Daten verfügt jedes Objekt über ein definiertes Verhalten, das über einen Nachrichtenmechanismus ausgelöst werden kann.

• Keine Flächendeckung: Der layerorientierte Zugang impliziert, daß die Ausprägung eines Attributs für jede Stelle eines Untersuchungsgebietes bekannt ist. Aufgrund der Individualität der Objekte ist dies im objektorientierten Ansatz nicht gegeben. Eine weitere Folge dieser Sichtweise ist, daß die Geometrie eines Objektes ein Attribut un­ter anderen darstellt, während bei Layern die Geometrie im Mittelpunkt steht.

4.4.2 Erweiterte Modellierungsstrukturen

Die strukturellen Möglichkeiten wie Vererbung, Aggregation und Assoziation bieten einer­seits umfangreiche Modellierungsmöglichkeiten, erzwingen andererseits eine weiter­gehende Strukturierung durch den Anwender als dies bei konventionellen Lösungen der Fall ist. Dies ist zwar zunächst mit einem weitaus größeren Aufwand verbunden, erhöht aber letztendlich die Qualität der Daten, indem Abhängigkeiten und Verbindungen zwischen Objekten dargestellt sind und dadurch die Ableitung von Informationen aus den reinen Daten unterstützt wird (LEYKAUF/ ALBRECHT 1993, S. 50).

Komplexe Systeme aus den Bereichen der Ökologie, der Transportlogistik, der Ver­sorgung und der Kommunikation sind Untersuchungsgegenstand in einem GIS und erfor­dern Möglichkeiten, die vielfältigen Beziehungen der Systemelemente untereinander dar­zustellen. Hinsichtlich der Bewältigung und Abbildung dieser Komplexität in einem Daten­modell bietet das objektorientierte Paradigma einen intuitiven Zugang, da mit Hilfe der Konstrukte Assoziation und Aggregation Verknüpfungen zwischen Objekten unmit­telbar darstellbar sind. Diese Beziehungen können komplexe Objekte repräsentieren, die selbst wiederum als eine Einheit anzusprechen sind (ARCTUR/ SARGENT 1998, o.S.).

Unter dem Gesichtspunkt der Datenintegration ist festzustellen, daß es objektorientierte Lösungen ermöglichen, das Anwendungsproblem derart zu strukturieren, daß räumliche und thematische Attribute in einem Objekt vereint sind. Beim Aufbau eines GIS-Daten­modells kann dadurch die bislang festzustellende Geometriezentrierung durch eine Objektzentrierung ersetzt werden. Der in Kapitel 3 dargestellte Aufbau eines konventionellen GIS leitet den Anwender dazu, einzelne geometrische Elemente mit Daten­sätzen zu verbinden, die diese Geometrie thematisch beschreiben. Ausgangspunkt der Datenmodellierung ist also beispielsweise ein Polygon, daß dann durch zusätzliche Attribute thematisch erfaßt wird. In einem objektorientierten System stehen dahingegen die Begriffe des Anwenders im Mittelpunkt, die neben anderen Attributen auch durch Geometrien beschrieben werden. Die von LEYKAUF/ ALBRECHT (1993, S.50) als zu­tiefst „ungeographisch“ bezeichnete prinzipielle Trennung in Geometrie und Thematik ist als solche nicht gegeben. Dadurch ist es darüberhinaus prinzipiell möglich, ein Objekt durch verschiedene Geometrien zu repräsentieren. Dieser Aspekt ist vor allem dann von Interesse, wenn Raster- und Vektordaten zu integrieren sind oder eine maßstabsabhängige Generalisierung gewünscht wird (WOODSFORD 1995, o.S.).

Wie das Beispiel in Abbildung 10 und Abbildung 11 zeigt, können gemeinsame Geo­metrie- und Sachattribute in einer übergeordneten Superklasse definiert werden, womit die redundante Definition in jeder einzelnen Klasse bzw in jedem Layer und der dazuge­hörigen Tabelle vermieden wird. Änderungen und Erweiterungen der Funktionalität blei­ben damit auf einige Oberklassen beschränkt (FRITSCH/ANDERS 1996, S.8)

In der praktischen Anwendung ist der systemgepflegte Objektidentifikator von Bedeutung. Dadurch entfällt die Verwaltung von Schlüsselattributen durch den Anwender, die insbe­sondere bei hybriden Systemen einen kritischen Punkt darstellen. Fehler in der Zuordnung zwischen Geometrie- und Sachdaten durch veränderte Schlüsselfelder können aufwendige Korrekturarbeiten erfordern. Die vom System vergebene OID ist für die gesamte Lebens­zeit des Objektes gültig und kann nicht durch den Anwender unabsichtlich verändert werden (FRITSCH/ANDERS 1996, S. 7f.).

4.4.3 Vorteile in der Softwareentwicklung

Für den Bereich der Softwareentwicklung ist der Vorteil vorrangig in der Wiederver­wendbarkeit und einfachen Erweiterungsmöglichkeit von bereits bestehendem Pro­grammcode zu sehen, was durch die Konzepte der Kapselung und des Polymorphismus ermöglicht wird. Dies ist insbesondere im GIS-Bereich von Bedeutung, da Geo-Informationsysteme eine Vielzahl von verschiedenen Anwendungen unterstützen sollen (FRITSCH/ANDERS 1996, S. 8). Dazu werden sog. Software-Biliotheken wie die Microsoft Foundation Classes (MFC) oder die Visual Component Library (VCL) von Inprise verwendet, die die Funktionalität des Betriebssystem kapseln und es einem An­wendungsprogrammierer erlauben, durch eine einfache Ableitung eigene Applikationen zu erstellen, für die lediglich die spezifischen Eigenschaften zu ergänzen sind (TOTH 1997, S.1110). Beispielsweise stellt die MFC eine Klasse „CBitmap“ zur Verfügung, die Methoden zum Erstellen und Manipulieren von Rastergrafiken enthält. Eine davon abge­leitete Klasse könnte in einer GIS-Implementierung um Fähigkeiten zur Georeferenzierung oder zu Overlay-Operationen erweitert werden. Im GIS-Bereich bietet das SMALLWORLD-System die Programmiersprache MAGIK an, mit deren Hilfe man - aufbauend auf der angebotenen GIS-Funktionalität - eigene Anwendungen entwickeln kann (BILL 1996, S. 331 f.). Beispiele für objektorientierte Klassenbibliotheken, die die GIS-Grundfunktionalität kapseln und Anwendungsentwicklern als Basis für eigene Pro­gramme dienen, sind OOGDM (VOIGTMANN 1997), die Geographic Foundation Class Library (QUIAN 1998) und CARIS++ (UNIVERSAL SYSTEMS 1998).

© 2014 Zeit in Geografischen Informationssystemen (GIS), Frank Hellwich