2

Inhaltsverzeichnis

Vorwort   7

1.1  Einleitung  7

1.2  Aufbau der Diplomarbeit  9

2  Verwendete Technologien.  12

2.1  OpenGL  12

2.2  GLUT  14

2.3  glow.  15

2.4  ImageMagick.  18

2.5  omniORB  19

2.6  Xerces.  21

3  Entwurfsphase  23

3.1  Besonderheiten bei einer Darstellungskomponente für die  

Luftbildauswertung.   23

3.2  Kernanforderungen an die Darstellungskomponente  27

3.3  Designentscheidungen beim Softwareentwurf  35

4  Realisierungsphase.  43

5  Zusammenfassung und Ausblick  58

A  Literaturverzeichnis  61

B  Glossar.  65

C  Stichwortverzeichnis.  69

Konfigurationsmanagement.   71

C.1  Systeme  71

C.1.1  Entwicklung.  71

C.1.2  Zielsysteme beim Kunden.  72

C.2  Entwicklungsumgebung  73

C.3  Installation OpenGL  74

C.3.1  OpenGL unter Windows.  74

C.3.2  OpenGL unter Linux.  75

C.4  Installation GLUT  77

C.4.1  GLUT unter Windows.  77

C.4.2  GLUT unter Linux.  79

C.5  Installation glow  81

C  5 1 glow unter Windows  81

3

C.5.2  glow unter Linux.  86

C.6  Installation ImageMagick.  88

C.6.1  ImageMagick unter Windows  88

C.6.2  ImageMagick unter Linux.  91

C.7  Installation omniORB  92

C.7.1  omniORB unter Windows.  92

C.7.2  omniORB unter Linux.  95

C.8  Installation Xerces.  97

C.8.1  Xerces unter Windows  97

C.8.2  Xerces unter Linux  98

D  Demonstrationsprogramme - Übersicht  99

4

Abbildungsverzeichnis   

Abbildung  1 - Übersicht V-Modell (siehe S.24 VMOD95 )  

Abbildung  2 - Unabhängiges Konsortium von OpenGL - Architecture Review  

Board  (ARB)  

Abbildung  3 - Besonderheiten - Kombination von Raster- und Vektordaten  

GUGL04   

Abbildung  4 - Besonderheiten - Bildauflösung.  

Abbildung  5 - Besonderheiten - Georeferenzierung GEO04  

Abbildung  6 - Kernanforderungen - Konfigurierbarkeit  

Abbildung  7 - Kernanforderungen - Verteiltes System / Portabilität.  

Abbildung  8 - Kernanforderungen - generische Nutzdatenschnittstelle.  

Abbildung  9 - Kernanforderungen - Kachelformat bei Bilddaten.  

Abbildung  10 - Kernanforderungen - Pufferung der Bilddaten.  

Abbildung  11 - Kernanforderungen - Ausprägung von Vektoren CARD04  

Abbildung  12 - Kernanforderungen - Grundeigenschaften von Vektoren  

Abbildung  13 - Kernanforderungen - Interaktion mit Georeferenzierung  

Abbildung  14 - Designentscheidungen - Architektur.  

Abbildung  15 - Designentscheidungen - Standard Coding Idiom  

Abbildung  16 - Designentscheidungen - Containerklassen  

Abbildung  17 - Designentscheidungen - Observer-Muster PAT98  

Abbildung  18 - Designentscheidungen - ICD Nachrichtenstruktur.  

Abbildung  19 - Designentscheidungen - Composite-Muster  

Abbildung  20 - Designentscheidungen - Bridge-Muster  

Abbildung  21 - Realisierung - Magick Ausnahmebehandlung MAPI04  

Abbildung  22 - Realisierung - GUI der Prototyp Darstellungskomponente.  

Abbildung  23 - Realisierung - Darstellungskomponente als GlowSubwindow  

5

Abbildung  24 - Realisierung - Strukturierung von OpenGL-Funktionen (siehe  

S.47  WRIGHT04 )  

Abbildung  25 - Realisierung - Texture Mapping bei OpenGL (siehe  

WRIGHT04  )  

Abbildung  26 - Realisierung - Dreidimensionales Texture Mapping (siehe  

WRIGHT04  )  

Abbildung  27 - Realisierung - Quadrantenarchitektur und Zoomverhalten.  

Abbildung  28 - Dokumentenübersicht  

Abbildung  29 - Realisierungsabdeckung des Prototyps  

Abbildung  30 - OpenGL - Architektur unter Windows SGL04  

Abbildung  31 - glow - Anlegen des neuen Projektes unter Visual Studio  

Abbildung  32 - glow - Projekt mit zugewiesenen Quelldateien  

Abbildung  33 - glow - Eintrag der Präprozessoranweisungen  

Abbildung  34 - glow - Includeverzeichnisse bei Projekten.  

Abbildung  35 - glow - Bibliothekverzeichnisse bei Projekten.  

Abbildung  36 - ImageMagick - Einstellungen des Dialogs Target Setup  

Abbildung  37 - ImageMagick - Einstellungen des Dialogs System Setup  

Abbildung  38 - ImageMagick - Auswahl der aktiven Konfiguration.  

Abbildung  39 - omniORB - Eintrag des Namensdienstes in die  

Windowsregistrierung   

Abbildung  40 - Demonstrationsprogramme  

Unternehmen

Das Thema dieser Diplomarbeit wurde ausgegeben durch die

Vorwort

1.1 Einleitung

Der Bereich Softwareentwicklung ist geprägt von Schnelllebigkeit und zunehmender Komplexität der Anforderungen. Auftraggeber legen

demgegenüber bei Individuallösungen immer mehr Wert auf Eigenschaften wie Portabilität, Konfigurierbarkeit und Erweiterbarkeit. Die Gegenüberstellung des Marktverhaltens bei der Software- und Systemtechnik und Anforderungen der Kunden an solche Produkte macht deutlich, dass die Realisierung von Unikaten nicht mehr praktikabel ist. Daher steigt die Tendenz zur Entwicklung von universell einsetzbaren Modulen mit generischen Schnittstellen zunehmend. Der Einsatz universeller Module bei Kundenlösungen verkürzt die Entwicklungsdauer und erhöht trotzdem die Softwarequalität. Dieser Ansatz soll als Motivation für das vorliegende Projekt dienen. Die Darstellungskomponente soll sich durch Eigenschaften wie Plattformunabhängigkeit, Konfigurierbarkeit, generische Schnittstellen und Erweiterbarkeit auszeichnen (vergleiche [STE05]).

Zielsetzung

Ziel der Diplomarbeit ist die „Erstellung einer prototypischen

Darstellungskomponente für Raster- und Vektordaten, lauffähig unter Linux und Windows“. Der Schwerpunkt bei der Durchführung liegt dabei auf der Entwurfsphase des Projektes. Nach der Entwurfsphase wird eine Prototypsoftware gemäß den zuvor erstellten technischen Dokumenten realisiert. Die Prototypsoftware erhebt keinerlei Anspruch auf Vollständigkeit. Der Prototyp soll als Bestätigung für den erstellten Entwurf dienen und die Designentscheidungen rechtfertigen.

Beim Entwurf und der Realisierung des Prototyps ist auf eine vollständige Dokumentation zu achten, damit bei der Fortführung dieses Projektes eine möglichst große Informationsbasis gegeben ist (vergleiche [STE05]). Die Ergebnisse der Diplomarbeit (Entwurf, Prototyp) sollen als Basis für die Entwicklung einer generischen Darstellungskomponente dienen, die als Modul in operationellen Systemen integriert werden kann.

1.2 Aufbau der Diplomarbeit

Im folgenden Kapitel wird zunächst auf das Vorgehensmodell bei der Durchführung der Diplomarbeit eingegangen. Im Anschluss werden die bei diesem Projekt verwendeten Technologien erläutert.

Das Kapitel 3 bildet den Hauptteil dieser Arbeit. In diesem Kapitel wird zunächst auf Besonderheiten eingegangen, die im Hinblick auf das Ergebnis zu berücksichtigen sind. Weiterhin werden in diesem Kapitel die entscheidenden Anforderungen erläutert. Ergänzt werden die Anforderungen durch die zentralen Designentscheidungen des Softwareentwurfs. Im Kapitel 4 sind die bei der Implementierung gesammelten Erfahrungen zusammengefasst. Kapitel 6 bietet dem Leser anschließend noch eine Zusammenfassung des Projektes und einen Ausblick für die Weiterentwicklung.

Abgerundet wird diese Arbeit durch einen ausführlichen Anhang, der besonders für Entwickler von Bedeutung ist, da er ein Kapitel über das Konfigurationsmanagement umfasst.

Vorgehensmodell

Die Vorgehensweise bei dieser Arbeit erfolgt gemäß V-Modell für Produktentwicklung. Da es sich um ein reines Softwareentwicklungsprojekt handelt, kommt an dieser Stelle das Submodell für Softwareentwicklung zum Einsatz (siehe Abbildung 1 - Übersicht V-Modell (siehe S.24 [VMOD95])).

Bezogen auf das V-Modell (siehe Abbildung 1 - Übersicht V-Modell (siehe S.24 [VMOD95])) erfolgt an dieser Stelle die Einschränkung auf die Teilschritte SWE1 bis SWE6, da die Hauptaufgabe im Entwurf der Darstellungskomponente besteht.

Im Rahmen dieser Diplomarbeit gehen dabei aus der Entwurfsphase die folgenden Dokumente hervor:

• Afo (Anwenderforderungen)

• TAnf (Technische Anforderungen)

• Softwarearchitekturdokument

• ICD (Interface Control Document)

• CRC-Karten (Class-Responsibility-Collaborators)

• Softwareentwurfsdokument

Bei der Darstellungskomponente handelt es sich um eine Komponente und nicht um ein Gesamtsystem, weshalb die Erstellung einer Systemarchitektur an dieser Stelle entfällt.

Die Kernaussagen aller Entwurfsdokumente sind in Kapitel 3

zusammengefasst. Da durch ein Vorgehensmodell die Qualität einer Arbeit qualitativ erhöht werden soll, bietet der Anhang dieser Diplomarbeit zusätzlich noch ein Kapitel 0 über Konfigurationsmanagement. In diesem Kapitel wird die gesamte Entwicklungsumgebung festgehalten. Dies ermöglicht die Reproduzierbarkeit der während der Diplomarbeit verwendeten Umgebung und leistet somit ebenfalls einen Beitrag zur Qualitätssicherung.

Der Teilbereich SWE6 - Implementierung (siehe Abbildung 1 - Übersicht V-Modell (siehe S.24 [VMOD95])) erfolgt im Rahmen dieser Arbeit nur in Form einer Prototypanwendung zur Bestätigung und Demonstration des erstellten Entwurfs. Der Prototyp soll als Basis für die vollständige Implementierung dienen.

2 Verwendete Technologien

2.1 OpenGL

OpenGL gilt als die erste Umgebung zur Entwicklung von portablen und interaktiven 2D und 3D Grafikanwendungen [GL04]. Die Grafikbibliothek ist 1992 von dem Unternehmen Silicon Graphics, Inc. (SGI) in der Öffentlichkeit vorgestellt worden. Das Unternehmen nahm dabei die eigene Grafikbibliothek IRIS GL als Grundlage für die Realisierung von OpenGL. Ziel von SGI war es, einen neuen 3D Grafikstandard ins Leben zu rufen [WRIGHT04].

Die Bibliothek besteht derzeit aus ca. 250 unabhängigen Funktionen zur Spezifizierung von Objekten und Operationen. OpenGL stellt dabei jedoch keine Schnittstelle auf hohem Abstraktionsniveau bereit. Alle noch so komplexen Modelle müssen über die Verknüpfung von geometrischen Primitiven vom Anwender selbst erzeugt werden [SHR04].

Abbildung 2 - Unabhängiges Konsortium von OpenGL - Architecture Review Board (ARB)

Als Vorteile erweisen sich für den Anwendungsentwickler die im Folgenden aufgeführten Argumente [GL04]:

• OpenGL ist heute ein weit verbreiteter Industriestandard dessen Spezifikation durch ein unabhängiges Konsortium (siehe Abbildung 2 -Unabhängiges Konsortium von OpenGL - Architecture Review Board) gepflegt wird.

• OpenGL ist bereits seit über 7 Jahren für eine Vielzahl von Plattformen verfügbar.

• OpenGL ist immer abwärtskompatibel, weshalb bestehende Anwendungen trotz neuer Versionen einsatzbereit bleiben.

• Anwendungen produzieren konsistente grafische Resultate unabhängig von Betriebssystem oder Fenstersystem.

• Das Design von OpenGL erlaubt es, dass Hardwareinnovationen über den OpenGL Extension Mechanismus verfügbar werden.

• OpenGL ist bezüglich der Zielplattform skalierbar.

• OpenGL ist für eine Vielzahl von Programmiersprachen verfügbar wie z. B. Ada, C, C++, Fortran, Python, Perl und Java

2.2 GLUT

Das OpenGL Utility Toolkit (GLUT) ist ein fenstersystem- und plattformunabhängiges Toolkit zur Realisierung von OpenGL Anwendungen. Es ist darauf ausgelegt, schnell und einfach OpenGL Anwendungen zu erstellen. Daher stellt GLUT auch keine vollständige API für grafische Oberflächen bereit. Es sollte nur für Anwendungen mit kleinem und mittlerem Schwierigkeitsgrad verwendet werden. Bei Anwendungen mit aufwendiger grafischer Oberfläche sollte stattdessen auf ein zielsystembasiertes Toolkit zurückgegriffen werden [GLUT04].

Die Verwendung von GLUT bringt folgende Vorteile und Eigenschaften mit sich [GLUT04]:

• Fenstersystemunabhängig

• Plattformunabhängig

• Callback gesteuerte Ereignisbehandlung

• Idle-Routine und Timerfunktionalität

• Unterstützung von mehreren Fenstern beziehungsweise Grafikkontexten zur selben Zeit

2.3 glow

glow ist ein plattformunabhängiges Toolkit, das ein objektorientiertes Framework zur Erstellung von interaktiven Anwendungen bereitstellt. Unter interaktiven Anwendungen sind in diesem Fall Anwendungen zu verstehen, die für die Grafikdarstellung Bibliotheken wie OpenGL oder Mesa verwenden. Das Kernstück von glow bildet der Wrapper für GLUT.

Durch den objektorientierten Ansatz von glow bietet diese Bibliothek jedoch mehrere Vorteile gegenüber GLUT. glow bietet nicht nur Wrapper für GLUT Funktionalität an, sondern auch eine Reihe von konfigurierbaren GUI-Elementen. Durch Vererbungsmechanismen wird dem Anwender zusätzlich die Möglichkeit geboten, auf einfache Weise eigene GUI-Elemente zu erzeugen beziehungsweise bestehende GUI-Elemente für den eigenen

Verwendungszweck zu spezialisieren [GLOW04]. Die Wrapperbibliothek ist für „write-once-compile-anywhere“ [GLOW04] Entwicklung konzipiert. Eine Anwendung, die auf glow basiert, sollte daher auf jedes System portabel sein, auf dem OpenGL und GLUT verfügbar sind.

Im Folgenden sind die Merkmale von glow laut Webseite aufgelistet (originalgetreu übernommen [GLOW04]):

• Object-oriented C++ API wrapper for GLUT

• Create windows, subwindows and menus with a single line of code by constructing objects.

• Operations on windows, subwindows and menus accomplished by method calls. (You do not need to juggle IDs.)

• Events reported directly to objects via virtual methods. (You do not need to keep track of callbacks.)

• Extensions to GLUT interfaces.

• Component hierarchy for organization and reuse of drawable

objects.

• Recursive activation and deactivation of components. Automatically affects event delivery.

arcball algorithm.

• Additional menu manipulation capabilities, including inserting and marking items.

• Automatic computation of additional state, including font metrics, local window positions and menu status.

• Powerful, extensible widget system.

automatically lays widgets out.

• Low-level API allows precise control of widget placement and options.

• Predefined message windows and text entry windows for quick creation of alerts and user input dialogs with a single line of code.

• Hierarchical arrangement of widgets using panels and other containers.

objects.

system.

• Large widget library.

• Source code compatible across platforms.

development.

2.4 ImageMagick

ImageMagick ist eine Framework, das Tools und Bibliotheken zum Lesen, Schreiben und Bearbeiten von Bildern bereitstellt. Insgesamt unterstützt das Framework über 90 Standardbildformate wie beispielsweise tiff, jpeg, gif u. a.. ImageMagick zeichnet sich aber nicht nur durch seine Vielzahl an unterstützten Bildformaten aus, es bietet auch aus programmiertechnischer Sicht eine breite Schnittstelle an. Bildoperationen können über die Kommandozeile, C, C++, Perl, Java, PHP, Python oder Ruby angesprochen werden [MAG04].

Auf der Webseite von ImageMagick wird die Funktionalität exemplarisch wie folgt charakterisiert (originalgetreu übernommen [MAG04]):

• Convert an image from one format to another (e.g. TIFF to JPEG)

• Resize, rotate, sharpen, color reduce, or add special effects ro an image

• Create a montage of image thumbnails

• Create a transparent image suitable for use on the Web

• Turn a group of images in a GIF animation sequence

• Create a composite image by combining several separate images

• Draw shapes or text on an image

• Decorate an image with a border or frame

• Describe the format an characteristics of an image

2.5 omniORB

omniORB ist eine Open Source CORBA Implementation. Das Toolkit wurde ursprünglich für den Einsatz in embedded systems bei der Olivetti Research Ltd. entwickelt. Der Einsatz von omniORB wurde aber ständig ausgeweitet, da dieser zu der Zeit besser war als viele kommerzielle ORBs. Am 12. Mai 1997 wurde die Version omniORB 2.2.0 unter der General Public License als Release herausgegeben. Die Weiterentwicklung erfolgte weiterhin durch die AT&T Laboratories (ehemals Olivetti). Durch deren Schließung am 24. April 2002 wurde omniORB zu einem offenen Projekt. Heute wird omniORB durch Apasphere Ltd. entwickelt und betreut [OMNI04].

omniORB besitzt laut der offiziellen Webseite in der Version 4.0.0 folgende Eigenschaften (originalgetreu übernommen [OMNI04]):

• C++ and Python language bindings.

• Adheres to the CORBA 2.6 specification.

• Support for GIOP and IIOP 1.0, 1.1 and 1.2.

• Fully multithreaded runtime.

• TypeCode and type Any.

• CORBA 2.6 DynAny interfaces.

• Dynamic Invocation and Dynamic Skeleton interfaces.

• Complete Naming Service, omniNames.

• Support for wchar, wstring and code set negotiation.

• Full long long, long double, fixed point support.

• PortableServer::Current.

• Unix domain socket transport.

• Bidirectional GIOP.

• Interoperable Secure Socket Layer transport.

• Flexible thread management.

• Interceptors.

• The following platforms are supported (although some have only been tested with earlier releases):

and above

• Fully interoperable with other CORBA ORBs.