Erstellung einer prototypischen Darstellungskomponente für Raster- und Vektordaten

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 )  10

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

  Board (ARB)  12

  Abbildung 3 - Besonderheiten - Kombination von Raster- und  Vektordaten

  GUGL04  24

  Abbildung 4 - Besonderheiten - Bildauflösung  25

  Abbildung 5 - Besonderheiten - Georeferenzierung GEO04  26

  Abbildung 6 - Kernanforderungen - Konfigurierbarkeit  28

  Abbildung 7 - Kernanforderungen - Verteiltes System Portabilität  29

  Abbildung 8 - Kernanforderungen - generische Nutzdatenschnittstelle  30

  Abbildung 9 - Kernanforderungen - Kachelformat bei Bilddaten  30

  Abbildung 10 - Kernanforderungen - Pufferung der Bilddaten  31

  Abbildung 11 - Kernanforderungen - Ausprägung von Vektoren CARD04  32

  Abbildung 12 - Kernanforderungen - Grundeigenschaften von Vektoren  33

  Abbildung 13 - Kernanforderungen - Interaktion mit Georeferenzierung  34

  Abbildung 14 - Designentscheidungen - Architektur  35

  Abbildung 15 - Designentscheidungen - Standard Coding Idiom  37

  Abbildung 16 - Designentscheidungen - Containerklassen  38

  Abbildung 17 - Designentscheidungen - Observer-Muster PAT98  39

  Abbildung 18 - Designentscheidungen - ICD Nachrichtenstruktur  40

  Abbildung 19 - Designentscheidungen - Composite-Muster  41

  Abbildung 20 - Designentscheidungen - Bridge-Muster  42

  Abbildung 21 - Realisierung - Magick Ausnahmebehandlung MAPI04  44

  Abbildung 22 - Realisierung - GUI der Prototyp Darstellungskomponente  51

  Abbildung 23 - Realisierung - Darstellungskomponente als GlowSubwindow  52

5

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

  S 47 WRIGHT04 )  53

  Abbildung 25 - Realisierung - Texture Mapping bei OpenGL (siehe S 382  

  WRIGHT04 )  54

  Abbildung 26 - Realisierung - Dreidimensionales Texture Mapping (siehe S 390  

  WRIGHT04 )  54

  Abbildung 27 - Realisierung - Quadrantenarchitektur und Zoomverhalten  57

  Abbildung 28 - Dokumentenübersicht  58

  Abbildung 29 - Realisierungsabdeckung des Prototyps  60

  Abbildung 30 - OpenGL - Architektur unter Windows SGL04  74

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

  Abbildung 32 - glow - Projekt mit zugewiesenen Quelldateien  82

  Abbildung 33 - glow - Eintrag der Präprozessoranweisungen  83

  Abbildung 34 - glow - Includeverzeichnisse bei Projekten  84

  Abbildung 35 - glow - Bibliothekverzeichnisse bei Projekten  85

  Abbildung 36 - ImageMagick - Einstellungen des Dialogs Target Setup  89

  Abbildung 37 - ImageMagick - Einstellungen des Dialogs System Setup  89

  Abbildung 38 - ImageMagick - Auswahl der aktiven Konfiguration  90

  Abbildung 39 - omniORB - Eintrag des Namensdienstes in die  

  Windowsregistrierung  93

  Abbildung 40 - Demonstrationsprogramme  99

6

Unternehmen

Das Thema dieser Diplomarbeit wurde ausgegeben durch die

EADS Deutschland GmbH

Defence and Communications Systems IRGS3, Recce & UAV GS D-88039 Friedrichshafen

7

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]).

8

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.

9

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.

10

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])).

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.

11

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.

12

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]:

13

• 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

14

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

15

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.)

• Easy reference to fonts and colors via objects.

• Clean deletion of objects by object destructors.

• Typechecked sender-receiver object classes.

• Extensions to GLUT interfaces.

• Component hierarchy for organization and reuse of drawable

16

objects.

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

• Simulation of modal windows and non-resizable windows.

• Utility components, including a 3D manipulator based on the 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.

• Widgets may appear in any number of windows and subwindows.

• High-level API creates widgets with a single line of code and 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.

• Recursive visibility and activation for widgets.

• Easy management of widget keyboard focus.

• Widget events may be reported via virtual methods or receiver objects.

• Widgets appear and behave the same across platforms.

• Custom widgets may be written and fully integrated into the system.

17

• Large widget library.

• Push buttons

• Check boxes, 3-state check boxes

• Radio buttons, radio button groups

• Menu buttons, popup menus

• Sliders, including linear and logarithmic scales

• Proportional scroll bars

• Text labels

• Editable text fields, protected text fields (for passwords, etc.)

• Organization panels, separator rules

• Source code compatible across platforms.

• Written in ANSI/ISO compliant C++.

• No platform-specific code. Supports write-once-compile-anywhere development.

18

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

19

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):

20

o Windows NT / XP / 9x with Visual C++ version 5.0 and above o Linux / EGCS 2.91 or GCC 2.95 and above o Solaris 2.{5,6,7,8} / Sun C++ version 4.2 and above, or GCC 2.95 and above o HPUX 11.00/ aC++ o SGI Irix 6.x/ SGI C++ compiler 7.2 o Digital Unix 4.0D/ DEC C++ compiler version 6.0 o IBM AIX 4.2/ IBM C Set++ 3.1.4 and xlC 5.0 (Visual Age C++ 5.0) o IBM AIX 4.3/ IBM C Set++ 3.6.6 and xlC 5.0 (Visual Age C++ 5.0) o HPUX 10.20/ aC++ (B3910 A.01.04) o OpenVMS Alpha 6.2/ DEC C++ compiler 6.2/5.5 (UCX 4.1 ECO 8) o OpenVMS Vax 6.1/ DEC C++ compiler 5.5 (UCX 4.0 ECO 1) o NextStep 3.3/ gcc-2.7.2 o Reliant Unix 5.43/CDS++ o Phar Lap’s Real Time ETS Kernel o SCO Unixware 7 o Mac OS X o Fujitsu Siemens BS2000 (with patch in the distribution) o …and many others.

• Fully interoperable with other CORBA ORBs.