Dreidimensionale Darstellung und Simulation von Planetenbewegungen anhand der Keplerschen Gesetze

Simulation von Planetenbewegungen mit OpenGL, Qt und C++


Ausarbeitung, 2012

91 Seiten, Note: 1,0


Leseprobe

Inhaltsverzeichnis

Abkurzungs- und FremdwOrterverzeichnis

Abbildungsverzeichnis

Listingverzeichnis

1. Abstract

2. Einleitung

3. Aufgabenstellung

4. Entwicklungsumgebung
4.1. Auswahl der Programmiersprache
4.2. Integrierte Entwicklungsumgebung (IDE)
4.3. Modellierungswerkzeuge
4.4. Datenbank
4.5. Versionsverwaltungssystem
4.6. Eingesetzte Frameworks
4.7. Zusatzliche Zeichnungen
4.8. Arbeitsumgebung
4.8.1. Hardware
4.8.2. Software

5. LOsungsstrategie
5.1. Konzeption und Modellierung
5.1.1. Das Visual Paradigm Projekt
5.1.2. Uberarbeitung der Use-Cases
5.1.3. Datenmodell
5.1.4. Programmnavigation
5.1.5. Klassenmodell
5.1.6. Paketdiagramm
5.2. Mathematische Hintergriinde und notwendige Parameter
5.2.1. Keplers erstes Gesetz
5.2.2. Keplers zweites Gesetz
5.2.3. Keplers drittes Gesetz
5.2.4. Dimensionierung der Parameter
5.2.5. Planetenpositionen darstellen
5.2.6. Echtzeitsimulation
5.2.7. Weitere mogliche Implementierungsstrategie

6. Umsetzung des mathematischen Modells
6.1. Umsetzung des ersten Keplerschen Gesetzes
6.2. Umsetzung des zweiten Keplerschen Gesetzes
6.3. Umsetzung des dritten Keplerschen Gesetzes
6.4. Korrektur der Korrektur
6.5. Korrektur der numerischen Fehler

7. Das Qt-Creator Projekt

8. Implementierung
8.1. Prototypisches Vorgehen (Spikes)
8.2. Datenmodell
8.3. Architekturmodell
8.3.1. Model-View-Controller
8.3.2. Datenzugriffsschicht
8.3.3. Modellschicht
8.3.4. Prasentationsschicht
8.4. Simulation
8.4.1. Initialisierung
8.4.2. Berechnung
8.4.3. Darstellung
8.4.4. Navigation

9. Publikation
9.1. Quelloffen
9.2. Lizenz

10. Ausblick
10.1. Verbesserung der Simulation
10.2. Verbesserung der Visualisierung
10.3. Verbesserung der Benutzerfreundlichkeit
10.4. Softwaretechnische Paketstruktur

11. Fazit

12. Erkiarung

Literaturverzeichnis

A. Pflichtenheft

Abkurzungs- & Fremdworterverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

1. Das vollstandige Use-Case-Diagramm

2. Das Datenmodell als Entity Relationship Diagram

3. Die Programmnavigation als Zustandsdiagramm

4. Das Klassendiagramm der Komponente Visualisierung

5. Das Klassendiagramm der Klasse SolarSystemSimulation

6. Das Paketdiagramm der Anwendung

7. Ellipse mit relevanten Bezeichnern

8. Die Projektstruktur des Qt-Creator-Projekts

9. Die schematische Darstellung des MVC-Konzepts (eigene Darstellung)

10. Schematische Darstellung des Repository-Musters (eigene Darstellung)

11. Ausschnitt aus dem Klassendiagramm fur die Daten-Komponente

12. Verteilungsdiagramm der Anwendung

13. Ausschnitt aus dem Klassendiagramm fur die Modell-Komponente

14. Ausschnitt aus dem Klassendiagramm fur die GUI-Komponente

15. Screenshot der Ubersicht aller Himmelskorper

16. Sequenzdiagramm der Verknupfung von Oberflache und Modellschicht

17. Das Sequenzdiagramm fur die Initialisierung vor dem Start einer Simulation

18. Das Sequenzdiagramm fur den Ablauf der Berechnung

19. Darstellung der 4x4-Matrix zur Transformation (eigene Darstellung)

20. Das Sequenzdiagramm fur den Ablauf der Visualisierung

21. Die Perspective-Komponente dargestellt in einem Komponentendiagramm

Listingverzeichnis

1. Zuriicksetzen des Winkels, welcher die Planetenposition beschreibt, ohne Fehlerkorrektur

2. Zurucksetzen des Winkels, welcher die Planetenposition beschreibt, mit Fehlerkorrektur

3. Trigger- und Triggerfunktion zur Uberprufung eines zentralen Sterns

4. Beispiel fur das Signal & Slots Konzept

5. Anweisungen zum Initialisieren eines neuen Planetenobjekts

6. Anweisungen zum Berechnen der neuen Planetenposition

7. Anweisungen zum Berechnen einer Umlaufbahn

8. Anweisungen zum Zeichnen einer Spahre mit Materialeigenschaften

9. Anweisungen zum Zeichnen eines Sterns

10. Anweisungen zum Zeichnen eines Planeten

11. Anweisungen zum Zeichnen einer Umlaufbahn

12. Vermerk zur GPLv3 am Anfang einer Projektdatei

1. Abstract

This elaboration dedicates the development of a small application that handles the cal­culation and visualization of user defined planetary orbits. The reason for this topic is a project in the Software-Engineering module. The user can create own planets and stars and combine them to solar systems. Within these systems he can choose different options to set the elliptic orbits. These orbits are calculated based on the three Kepler’s laws of planetary motion. The visualization is created with a Qt application and the OpenGL framework for a complete 3D simulation.

The goal was to exercise various kinds of knowledge, gained through the three years of studies at the University of Applied Sciences in Iserlohn.

2. Einleitung

Die vorliegende Ausarbeitung wurde als Klausurleistung fur das Software-Engineering Projekt im Studiengang Angewandte Informatik des Fachbereichs Informatik und Naturwissenschaften der Fachhochschule Sudwestfalen in Iserlohn erstellt. Sie entstand auf der Idee, als abschliefiendes Projekt ein Thema inklusive Themengebiet zu wahlen, dass einen Grofiteil des in den vergangenen drei Jahren angeeigneten Wissens anzuwenden und zu vertiefen.

Wir mochten uns an dieser Stelle herzlich fur die gute Betreuung von Herrn Prof. Dr. rer. nat. Uwe Klug bedanken. Durch sein Engagement, dem Feedback zur Ausarbei­tung und der Vorlesung Software Engineering hat er entscheidend zur Ausgestaltung der Ausarbeitung beigetragen.

Unser Dank gilt auch Herrn Prof. Dr.-Ing. Fritz Mehner, der uns als Ansprechpartner beim Software-Engineering Projekt zur Verfugung stand.

Auch mochten wir Herrn Prof. Dr.-Ing. Walter Roth danken, dessen Veranstaltung EinfUhrung in die Multimediaprogrammierung uns zu dieser Ausarbeitung inspiriert hat.

Iserlohn, im Mai 2012

3. Aufgabenstellung

Die Aufgabenstellung des Projekts kann grob in zwei Bereiche unterteilt werden. Der erste Bereich umfasst die Verwaltung der vom Benutzer erfassten Stammdaten. Dazu gehoren Himmelskorper wie Planeten und Sterne und Sonnensysteme. Der andere Bereich um­fasst die Berechnung der Simulation sowie die Visualisierung der Ergebnisse. Hinter- grund fur die Berechnung sind die drei Keplerschen Gesetze fur Planetenbewegungen. Visualisiert werden sollen die Ergebnisse anhand einer dreidimensionalen Darstellung der HimmelskOrper und deren Bewegungen.

Erklartes Ziel ist neben der technischen Umsetzung der oben genannten Punkte auch ein umfangreiches und hilfreiches Benutzerhandbuch, so dass auch unbedarfte Anwender die Software ohne grofiere Schwierigkeiten bedienen konnen. Damit konnte das Ergebnis des Projekts in der Lehre eingesetzt werden. Sowohl zum Verdeutlichen von Planetenbewe­gungen, als auch zur Anwendung diverses Frameworks, Programmiersprachen und der 3D Visualisierung.

Eine detaillierte Auflistung der Zielbestimmungen sind im Pflichtenheft in Kapitel 2 ab Seite 2 aufgefuhrt. Das Pflichtenheft befindet sich als Anhang an dieser Ausarbeitung.

4. Entwicklungsumgebung

4.1. Auswahl der Programmiersprache

Die Auswahl der Programmiersprache wurde auf Basis bereits gemachter Erfahrungen ge- troffen. Im Modul Einfuhrung in die Multimediaprogrammierung wurde das Qt- und das Grafik-Framework OpenGL eingesetzt und in C++ entwickelt. Da damit sehr gute Er- fahrungen gesammelt werden konnten und weil eine Einarbeitung in eine weitere Pro- grammiersprache entfiel, kam auch fur dieses Projekt C++ zum Einsatz.

4.2. Integrierte Entwicklungsumgebung (IDE)

Auch die Wahl der Integrierten Entwicklungsumgebung wurde von bisherigen Erfah- rungen geleitet. Im Modul Einfuhrung in die Multimediaprogrammierung wurde der Qt-Creator eingesetzt. Diese IDE ist im Qt-Framework enthalten und bringt einen gu- ten Designer zur Implementierung von Benutzungsoberflachen mit. Da dadurch keine Drittprodukte eingesetzt werden mussten und auch hier eine zusatzliche Einarbeit entfiel, wurde auch in diesem Projekt mit dem Qt-Creator gearbeitet. Konkret eingesetzt wurde die Version 2.4.1.

4.3. Modellierungswerkzeuge

Grofie Teile des Projekts und der Anwendung wurden mit dem Modellierungswerkzeug Visual Paradigm in Version 8.3 modelliert. Hierfur stand eine Professional Edition Academic-Lizenz der Fachhochschule Sudwestfalen zur Verftigung, die kostenfrei genutzt werden durfte. Dieses Tool konnte wahrend des gesamten Projekts unterstutzend einge- setzt werden um Entwurfe und Programmablaufe zu visualisieren.

Viele der daraus entstandenen Resultate finden sich in dieser Ausarbeitung als Diagramme wieder. Naheres dazu befindet sich im Kapitel 5.1.1 auf Seite 7.

4.4. Datenbank

Ein Hauptmerkmal der Anwendung ist die persistente Datenspeicherung der Stammda- ten. Dadurch kann auf bereits angelegte Himmelskorper zuritckgegriffen werden, die zu immer neuen Sonnensystemen kombiniert werden. Auch die Benutzerfreundlichkeit der Simulation wird dadurch erheblich aufgewertet, da bereits erstellte Sonnensysteme immer wieder simuliert werden konnen.

Die Wahl der Datenbank wurde vom eingesetzten Framework beeinflusst. Qt bietet eine breite Palette an unterstutzten Datenbankmanagementsystemen an. Dazu gehort auch PostgreSQL. Hier stand zudem im Vordergrund, eine fremde Datenbank einzusetzen, um die Entwicklung auf dieser zu erlernen. Dieses Grund und die fehlende Unterstutzung des bekannten DBMS Firebird haben zur Wahl von PostgreSQL in Version 9.1.3 gefuhrt.

Zusatzlich wird fur Windows-Systeme noch der ODBC-Treiber in Version 9.0 eingesetzt.

4.5. Versionsverwaltungssystem

Grundlage fur die reibungslose Zusammenarbeit der Projektteilnehmer Fabian Deitel- hoff und Christof Geisler und den Austausch von Projektdateien ist ein System zur Versionsverwaltung. Eingesetzt werden zwei verschiedene Systeme.

Der Quelltext zur Entwicklung des Softwareprojekts ist auf dem Anbieter GitHub zu finden. Dieser bietet die Versionsverwaltung Git und Tools zur Verwaltung von Fehlern und Informationsseiten in Form eines Wikis an. Die Wahl viel auf GitHub zum einen durch die hervorragende Unterstutzung von Git und zum anderen, weil es sehr schnell zu einer der bekanntesten Open-Source-Plattform gewachsen ist. Das stimmt hervorragend mit den Intentionen dieses Projekts uberein, da der vollstandige Quelltext nach Abgabe der schriftlichen Ausarbeitung als Open-Source-Losung zur Verfugung gestellt wird.

Der andere Anbieter ist Bitbucket von Atlassin. Hier wurden in zwei Repositories die Dokumentationen versioniert und gepflegt. Dazu zahlt dieses Dokument und das Benutzerhandbuch. Die Wahl viel daher auf Bitbucket, weil hier die Moglichkeit besteht, private Repositories zu erstellen. GitHub verlangt dafur direkt eine monatliche Gebuhr. Die Dokumentationen, vor allem die durch viel Erfahrung aufgebauten LTEX-Vorlagen, sollen nicht als Open-Source zur Verfugung gestellt werden. Lediglich das als PDF-Datei generierte Benutzerhandbuch wird im GitHub-Repository zur Verfligung gestellt, um Anwender den Einstieg zu erleichtern.

In die Repositories eingecheckt werden alle Dateien, die wahrend der Projektarbeit ent- standen sind. Dazu zahlt vor allem der Quelltext der Anwendung, der als vollstandiges Qt-Creator-Projekt eingecheckt wurde. Auch die kompletten BIEX-Dokumente befin- den sich im Repository. Bis auf eine aktuelle Version der Dokumentation als PDF-Datei sind grundsatzlich alle Dateien ausgenommen, die durch einen Prozess generiert werden koannen.

Zusatzlich dazu wurde noch ein ausgewahlter Zwischenstand der Datenbank mit erstellten Stammdaten eingecheckt. Diese dienten vor allem als Testdaten, um sie nicht standig neu erstellen zu mussen. Da der Zwischenstand als PostgreSQL-Backup vorliegt, ist ein einfaches und vor allem automatisches Wiederherstellen moglich.

4.6. Eingesetzte Frameworks

Wie in Kapitel 4.1 auf Seite 3 schon kurz angerissen, ist das Fundament fur die Ent- wicklung der Anwendung das Qt-Framework in Version 4.8.1. Im Qt-Framework ist die Unterstutzung fur OpenGL und SQL schon eingebaut und kann uber eine Einstellung der Qt-Creator-Projektdatei aktiviert werden.

Zusatzlich wird noch das Framework Freeglut in Version 2.8.0 eingesetzt. Es ist vollstan- dig Open-Source und eine Alternative zum OpenGL Utility Toolkit (GLUT). Mithilfe von Freeglut kann an einige Stellen auf vorgefertigte Funktionen zurackgegriffen werden, die eine eigene Implementierung erleichtern oder uberflussig machen.

Weiterhin wurden im OpenGL-Umfeld einige Klassen aus dem Modul Einfuhrung in die Multimediaprogrammierung von Herrn Prof. Dr.-Ing. Walter Roth benutzt. Diese machen eine Eigenentwicklung in vielen Bereichen uberflussig, so dass die Entwicklungs- zeit fuar Funktionen der 3D-Visualisierung vermindert werden konnte.

4.7. Zusatzliche Zeichnungen

FUr Abbildungen und Zeichnungen wird das Programm Microsoft Visio in der Ver­sion 2010 eingesetzt. Das Programm steht uns liber das MSDN Software Center zur Verfugung, fur dass die Fachhochschule Sudwestfalen die sogenannte Acedemic Alliance Licence besitzt. So kann es von Studierenden kostenlos aus dem Portal heruntergeladen werden.

Mit dem Programm wurden in der Vergangenheit bei anderen Ausarbeitungen schon gute Erfahrungen gesammelt.

4.8. Arbeitsumgebung

4.8.1. Hardware

Die Entwicklung und der Test der Anwendung fanden auf den Systemen der beiden Pro- jektteilnehmer statt. Folgende Konfigurationen wurden dabei verwendet.

System 1

Ein Desktop-System, ausgestattet mit einem Intel i7 2007K, der liber vier physisch vorhandene Kerne mit je 3,5 GHz Taktfrequenz verfugt. Die Gesamtgrofie des verfugbaren Arbeitsspeichers betragt 16 GB.

System 2

Ein Desktop-System, ausgestattet mit einem Intel Core 2 Quad, der uber vier phy­sisch vorhandene Kerne mit je 2,66 GHz Taktfrequenz verfugt. Die Gesamtgrofie des verfugbaren Arbeitsspeichers betragt 8 GB.

4.8.2. Software

Auf einigen Systemen wurden virtuelle Maschinen eingesetzt, um die Entwicklung vom Host-System zu trennen. Die folgende Aufstellung gibt an, welche Betriebssoftware auf den Host- und Gastsystemen zum Einsatz kamen.

System 1

Auf dem Host ist Windows 7 64 bit vorhanden. Als virtuelle Maschine wurde Virtual Box von Oracle in Version 4.1.8 eingesetzt. Als Gastsystem wurde ein Windows 7 32 bit verwendet, dass auf zwei physische Kerne und 6 GB Arbeitsspeicher zuriickgreifen konnte.

System 2

Auf dem zweiten System ist ein natives Linux Fedora 16 (Verne) 64 Bit vorhanden, dass den Kernel in Version 3.3.7-1.fc16.86_64 benutzt.

5. Losungsstrategie

5.1. Konzeption und Modellierung

Vor Beginn der Implementierung fanden mehrere iterative Schritte zur Konzeption und Modellierung der Anwendung statt. Ziel dieser iterativen Phasen war es, die in der Anfor- derungsanalyse und im Pflichtenheft beschriebenen Anforderungen in ein erstes Modell zu uberftihren. Ergebnis dieser Modellierung war das Daten- und ein erstes Klassenmo- dell, sowie die Programmnavigation. Zusatzlich wurde deutlich, dass die Use-Cases ge- ringfugig angepasst werden mussten. Diese Resultate werden in den nachsten Kapiteln naher erlautert.

5.1.1. Das Visual Paradigm Projekt

Wie in Kapitel 4.3 auf Seite 4 schon kurz angedeutet, war Visual Paradigm ein wichtiges Werkzeug in der Konzeptions- und Modellierungsphase. Damit wurden im Projektverlauf 18 Diagramme erstellt, die sich auf die folgenden Diagrammtypen verteilen:

- Anwendungsfalldiagramme
- Klassendiagramme
- Sequenzdiagramme
- Zustandsdiagramme
- Komponentendiagramme
- Verteilungsdiagramme
- Paketdiagramme
- Entity Relationsship Diagramme

Zur Erstellung der Diagramme war das Buch Lehrbuch der Objektmodellierung von Frau Heide Balzert [14] sehr hilfreich.

Daruber hinaus wurden kaum weitere Mechanismen von Visual Paradigm benutzt. Auf die Transformation von Diagrammen untereinander wurde aufgrund von Zeitmangel fur die notwendige Einarbeitung verzichtet. Da auch nicht angestrebt wurde, Quelltext mit Visual Paradigm zu generieren, war dieser Umstand verschmerzbar.

5.1.2. Uberarbeitung der Use-Cases

In der Konzeptionsphase wurde deutlich, dass es fur die Benutzbarkeit der Anwendung aufierst sinnvoll ist, dem Anwender die Moglichkeit zu geben, einige Parameter der Simula­tion anzupassen. Dazu gehoren die Auswahlmoglichkeiten, ob die Planetenumlaufbahnen und das Koordinatensystem sichtbar sind oder nicht. Auch die Einstellung, ob Kollisionen erkannt und gemeldet werden, kann dazu gezahlt werden.

Auch eine Ausdifferenzierung zwischen Visualisierung und Simulation erschien pas- send. Das verdeutlicht die Unterschiede der beiden Bereiche. Die Visualisierung ist nur fur

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Das vollstandige Use-Case-Diagramm.

die Anzeige der in der Simulation berechneten Ergebnisse zustandig und nicht gleichzeitig fur die Berechnung.

Daraufhin wurden die Anwendungsfalle im Anwendungsfalldiagramm angepasst. Abbil­dung 1 zeigt das geanderte Use-Case-Diagramm. Im Vergleich mit der Abbildung aus dem Pflichtenheft sind die Anwendungsfalldiagramme Parameter anpassen dazugekommen. Diese sind jeweils einmal im bereits vorhandenen System Visualisierung und im neu dazugekommenen System Simulation gruppiert.

5.1.3. Datenmodell

Um die vom Anwender erstellen Himmelskorper und Sonnensysteme auch uber die Lauf- zeit der Anwendung hinweg erhalten zu konnen, wurde eine relationale Datenbank als persistenter Speicherort ausgewahlt. Die Wahl viel dabei konkret auf eine PostgreSQL- Datenbank, da hier die Unterstutzung seitens Qt durch ODBC- oder native PostgreSQL- Treiber auf den Plattformen Linux und Windows sehr gut ist.

Abbildung 2 zeigt das dazu modellierte Datenmodell als Entity Relationship Diagram.

Die drei in der Abbildung dargestellten Tabellen bilden die Entitaten Sonnensystem, Himmelskorper und die Verknupfung untereinander ab. Eindeutig identifiziert werden Eintrage in den Tabellen SolarSystem, HeavenlyBody uber numerische Primarschlussel. Lediglich die Verknupfungstabelle SolarSystemToHeavenlyBody hat einen komplexen Primaorschluossel, der alle Spalten der Tabelle umfasst. Hintergrund dieser Designentschei- dung ist die Anforderung, dass ein Planet auch mehrfach zu einem Sonnensystem hinzu- gefugt werden darf, wenn sich mindestens ein auf das Sonnensystem bezogener Parameter unterscheidet. So konnen in der Simulation zwei gleiche Planeten gezeigt werden, die sich

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Das Datenmodell als Entity Relationship Diagram.

zum Beispiel in der Bahnabweichung unterscheiden.

Eine weitere Beziehung wurde zwischen dem zentralen Stern und dem Sonnensystem, in dem er sich befindet, modelliert. Diese stellt sicher, dass nur Himmelskorper benutzt werden, die in der Tabelle HeavenlyBody vorhanden sind.

Um die Integritat der Daten weiter sicherzustellen, werden Datenbanktrigger einge- setzt. Diese dienen der Uberprufung, ob als Planet eines Sonnensystems auch wirklich ein Himmelskorper vom Typ P und als zentraler Stern tatsachlich ein HimmelskOrper vom Typ S ausgewahlt wird. Diese Uberprufungen sind selbstverstandlich auch noch in der Oberflache vorhanden und werden uber aussagekraftige Fehlermeldungen an den Anwen- der gemeldet. Trotzdem ist es wichtig, auch die Datenbank vor direkten Manipulationen zu schtitzen. Die genaue Implementierung dieser Datenbanktrigger wird im Kapitel 8.2 auf Seite 28 naher beschrieben.

5.1.4. Programmnavigation

Die waahrend der Ausarbeitung des Pflichtenhefts erstellten Oberflaachen-Mockups dienten zur groben Orientierung des Aufbaus und der Navigationsmoglichkeiten in der Benut- zungsoberflache. Vor der Implementierung dieser Oberflachen wurde die Programmnaviga­tion mittels eines Zustandsdiagramms uberpruft. Das Resultat ist in Abbildung 3 abge- bildet.

Der in diesem Diagramm abgebildete Zustandsautomat stellt hauptsachlich die Fenster als Zustande und die maglichen Funktion als Tansitionen zwischen diesen Zustanden dar. Der Zustand Simulation stellt zwar kein eigenstandiges Fenster dar, sondern ist eher

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Die Programmnavigation als Zustandsdiagramm.

eine Komponente zur Anzeige der OpenGL-Oberflache, wurde aber trotzdem als Zustand modelliert, um alle Funktionen des Hauptfensters besser erklaren zu konnen. Viele der im Hauptfenster angebotenen Funktionen steuern direkt einen Zustand der Simulation. Zum einen die Anzeige, zum anderen die dahinter liegenden Berechnung.

Durch die Modellierung dieser Programmnavigation wurden noch einige kleine Schwach- stellen der Oberflachen-Mockups festgestellt. Durch die gute Visualisierung konnten diese aber schnell beseitigt werden. Die vollstandigen und in der aktuellen Version finalen Be- nutzungsoberflachen sind im beiliegenden Benutzerhandbuch abgebildet.

5.1.5. Klassenmodell

Nachdem durch die Konzeption und Modellierung klar war, welche Anforderungen um- gesetzt und welche Daten in welcher Form im Datenmodell abgespeichert werden sollen, wurde der technische Aufbau der Anwendung durch mehrere Klassenmodelle konkreti- siert.

Aufgrund von guten Erfahrungen in der Studienzeit durch das Model-View-Controller Architekturmuster, stand schnell fest, dieses auch im aktuellen Projekt einzusetzen. Die­se Entscheidung hat naturlich grofien Einfluss auf die modellierten Klassenmodelle und die Aufteilung in Pakete beziehungsweise Komponenten. Aufgrund der Grofie der erstell- ten Abbildungen ist es leider nicht moglich, diese vollstandig an dieser Stelle zu zeigen. Stellvertretend werden im Folgenden zwei Klassendiagramme gezeigt.

Bei dieser ersten Konzeption und Modellierung der technischen Aspekte der Anwendung wurde allerdings nur ein grobes Modell entwickelt. Die Klassenmodelle wurden mit wich- tigen Instanz- und Klassenvariablen und Methoden ausgestattet. Ebenso wurde sehr viel Wert auf die Modellierung der Abhangigkeiten und Assoziationen gelegt. Die Klassen wurden aber nicht bis ins letzte Detail durchgeplant. Erfahrungsgemafi verschlingt dieser Prozess bei dieser Art von Anwendung zu viel Zeit und muss im spateren Verlauf doch angepasst werden. Die zwei Beispiele, die im Folgenden gezeigt werden, sind das Resultat einer Mischung aus Planung und Reverse Engineering mit Visual Paradigm.

Zu diesem Zeitpunkt im Modellierungsprozess standen, bedingt durch das erstellte Da­tenmodell, die zu speichernden Daten schon ziemlich genau fest. Auch das grundsatzliche Verstandnis fur die Navigation der Benutzungsoberflachen war durch die Konzeption der Programmnavigation vorhanden. Was noch fehlte war die konkretere technische Vorstel- lung der Visualisierung und der Simulation. Da diese beiden Bereiche zentrale Punkte der Anwendung darstellen, wurden die dafuar notwendigen Klassendiagramme als erstes konzipiert.

Abbildung 4 zeigt die Klassen der Komponente Visualisierung. Sie tibernehmen Teil- aufgaben der Visualisierung mittels OpenGL-Funktionen. So kann die Klasse Star3d einen Stern darstellen. Die Klasse Planet3d ist hingegen fur die Darstellung eines Planeten zustandig und benutzt dafur die Klasse Orbit3d, die eine Umlaufbahn zeichnet.

Durch die Konzeption dieser Abhangigkeiten wurde schnell deutlich, wie die Visualisierung der Planeten und Planetenbewegungen technisch in der Anwendung umgesetzt werden

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Das Klassendiagramm der Komponente Visualisierung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Das Klassendiagramm der Klasse SolarSystemSimulation. sollten.

Direkt im Anschluss wurde die Komponente Simulation modelliert. Das dazugeharige Klassendiagramm ist in Abbildung 5 abgebildet. Es enthalt nur die Klasse SolarSystem­Simulation. Sie ist vollstandig flir die Berechnung und das Anstofien der Zeichenroutine zustandig. Zusatzlich enthalt sie noch den Algorithmus zur Kollisionserkennung.

5.1.6. Paketdiagramm

Ein Paketdiagramm kann ein hervorragendes Mittel sein, um die wachsende Struktur der Anwendung im Auge behalten zu konnen. Wahrend der Entwicklung der Anwendung SolarSystemSimulation wurde mit Visual Paradigm ein Paketdiagramm erstellt und gepflegt, dass die Abhangigkeiten auf einer etwas abstrakteren Ebene als die Klassendia- gramme darstellt.

Abbildung 6 zeigt dieses Paketdiagramm. Eindeutig zu sehen sind die unidirektionalen Abhangigkeiten. Gerade vom Paket GUI aus Richtung Modell und von diesem aus weiter Richtung Daten. Diese Tatsache hangt direkt mit dem Vorgehen nach dem MVC-Prinzip zusammen.

Leider wurden diese Pakete nur in der Verzeichnisstruktur der Anwendung beriicksichtigt. Auch die Programmiersprache C++ erlaubt den Einsatz von Namensraumen, die liber das Schlusselwort namespace eingefuhrt werden kannen. Dadurch ware die Aufteilung auf Paketen auch aus technischer Sicht komplett. Aktuell wird nur aus organisatorischer Sicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Das Paketdiagramm der Anwendung.

eine Paketstruktur unterstutzt. Weitere Informationen zu moglichen Verbesserungen sind im Kapitel 10 ab Seite 54 zusammengefasst.

5.2. Mathematische Hintergriinde und notwendige Parameter

Theoretische Uberlegungen im Vorfeld der Implementierung

Die Berechnung der Umlaufbahnen soll nach den drei Keplerschen Gesetzen geschehen. Dabei werden ideale Bedingungen angenommen. Abweichungen von den Umlaufbahnen werden nicht simuliert.

Der mathematische Schwerpunkt bei der Umsetzung liegt im Nachvollziehen und im vi- suellem Umsetzen der von Kepler in den beiden ersten Dekaden des 17. Jahrhunderts beschriebenen Gesetze.

Die gegen Ende des 17. Jahrhunderts von Isaak Newton hergeleiteten Gravitationsge- setze werden in dieser Ausarbeitung nicht angewendet. Es sei aber erwahnt, dass diese in sehr engem Zusammenhang mit der detaillierteren Berechnung von nicht idealisierten Umlaufbahnen von sehr grofier Bedeutung sind.

Insbesondere die Aussage von Keplers drittem Gesetz nimmt die spater von Isaak Newton hergeleiteten Zusammenhange bezuglich der Anziehungskraft zwischen Massen vorweg. [1] [2]

Die Beschreibungen in diesem Kapitel geben nicht unbedingt die spater tatsachlich umge- setzte Implementierung wieder sondern beschreiben chronologisch die Uberlegungen zur Implementierung im Vorfeld der Ausfuahrung.

5.2.1. Keplers erstes Gesetz

Keplers erstes Gesetzt besagt, dass sich die Planeten auf elliptischen Bahnen bewegen.

Dies impliziert, dass die Summe der Abstande des Planeten zu den Brennpunkten der Ellipse konstant ist. Dies ist eine allgemeingultige Aussage zu Ellipsen.

Eine Ellipse stellt die Schnittebene durch einen Kegel dar. Der Spezialfall, in dem sich diese Schnittflache senkrecht zur Achse des Kegels befindet ist der Kreis. Dieser Spezialfall soll durch die Software auch simuliert werden koannen und dient zur Angabe der Entfernung des Planeten vom zentralen Stern. Bei der Planetendefinition erfolgt somit mit der Eingabe der Entfernung des Planeten von der Sonne ebenfalls die Eingabe des Kreisradius der Ellipse bei diesem Sonderfall.

Ein weiterer Parameter zur Beschreibung der Ellipse ist deren numerische Exzentrizitat e. Mit der Angabe von Radius und Exzentrizitat sind alle Punkte einer Umlaufbahn eindeu- tig festgelegt. Der Wert fur die Exzentrizitat kann bei der Ellipse einen Wert zwischen Null (Kreis, inklusive) und Eins (Linie, exklusive) einnehmen. Der Definitionsbereich der nume- rischen Exzentrizitat wird in der Software auf einen Wertebereich von [0;0,7] beschrankt. Einen relativ hohen Wert von 0,7 fur die Simulation zuzulassen dient der Mbglichkeit eine gut erkennbare elliptische Umlaufbahn darzustellen. Bei denen die Sonne umkreisen- den Planeten ist der Merkur der Planet mit der grOfiten Exzentrizitat von 0,2056. Der Zwergplanet Pluto besitzt die Exzentrizitat 0,2488.

Auch weitere wichtige Punkte der Ellipse sind mit der Angabe von Radius und Exzentri­zitat eindeutig. Zur Veranschaulichung dient die Abbildung 7. Das Verhaltnis der beiden Halbachsen a und b wird durch (1)

Abbildung in dieser Leseprobe nicht enthalten

dargestellt. Die Brennpunkte lassen sich entsprechend mit (2) bestimmen.

Abbildung in dieser Leseprobe nicht enthalten

Als weiterer Parameter fur das Simulationsmodell erfolgt die Angabe eines Winkels zwi- schen 0 und 360. Dieser Winkel gibt die Richtung der rechten grofien Halbachse a bezogen auf das kartesische Koordinatensystem zu Beginn der Simulation an. Der zentrale Him- melskorper befindet sich im Brennpunkt F\.

In der Eingabemaske zur Definition der Planeten wird gegebenenfalls noch ein zweiter Winkel erfasst, welcher den Ort des Planeten auf der Umlaufbahn zu Beginn der Simula­tion angibt. Der Ort wird definiert als der Schnittpunkt von Umlaufbahn und dem durch diesen Winkel und dem Mittelpunkt M der Ellipse definierten Vektor. Da dieser Wert fur die prinzipielle Simulation der Bewegung nur nachrangig ist wird wahrend der Imple- mentierung entschieden, ob dieser angegeben werden kann oder nicht. Wird dieser nicht angegeben, so sind die Startpositionen alle gleich gerichtet.

5.2.2. Keplers zweites Gesetz

Kernaussage dieses Gesetzes: Die Verbindungslinie zwischen Planet und zentralem Him- melskorper uberstreicht in gleicher Zeit die gleiche Flache.

Abbildung in dieser Leseprobe nicht enthalten

Hintergrund dieser Aussage ist die nicht gleichformige Geschwindigkeit des Planeten beim Beschreiben der Umlaufbahn. An dem Punkt der Bahn, welcher dem zentralen Him- melskorper am nachsten liegt ist die Geschwindigkeit maximal. An dem Punkt der am weitesten entfernt liegt ist die Geschwindigkeit minimal. Die sich andernde Geschwindig­keit zwischen diesen Punkten wird durch die Vis-Viva-Gleichung [5] beschrieben:

Dabei ist r der Abstand des Planeten vom zentralen Himmelskorper, a die grofie Halbachse und b die Gravitationskonstante.

Um dieses Gesetz visualisieren zu kbnnen ist es nbtig, die Geschwindigkeit des Plane- ten an jeder Stelle der Umlaufbahn bestimmen zu konnen. Benbtigte Parameter um die durchschnittliche Geschwindigkeit feststellen zu konnen sind der Umfang der Ellipse und die benotigte Zeit zum einmaligen Umkreisen des zentralen Himmelskorpers. Der Ellip- senumfang wird exakt durch das Integral (4) bestimmt. Zur Vereinfachung benutzen wir fur unsere Berechnungen die Naherungsformel (5) von Ramanujan [3], welche bei einer Exzentrizitat e kleiner 0,9 noch sehr genau ist (Relativer Fehler < 10_8) [4].

Abbildung in dieser Leseprobe nicht enthalten

Da fur die Berechnung der Umlaufbahnen die Massen der HimmelskOrper nicht angegeben werden sollen, wird zur Umlaufbahnberechnung noch ein weiterer Parameter benotigt: Die Dauer eines Umlaufes. Im weiteren Verlauf der Geschwindigkeitsbestimmung des Planeten berechnen wir eine Konstante n, welche sich aus dem Produkt der Gravitationskonstan- te [7] und dem Gewicht des Planeten zusammensetzt. Aus diesem Grunde wird in der Eingabemaske fur die Parameter der Planeten ein Feld vorgesehen, welches die Masse des Planeten angibt. Diese Berechnung unter Einbeziehung der Gravitationskonstante bezieht sich naturlich nur auf unser Sonnensystem. Fur andere, selbst konstruierte Systeme, ist wegen den anderen Massenverhaoltnissen eine andere Gravitationskonstante anzunehmen. Der ausgegebene Wert fur die Masse ist in diesem Kontext zu betrachten.

Die Geschwindigkeit des Planeten im Aphel und im Periphel lasst sich uber die Winkel-

Abbildung in dieser Leseprobe nicht enthalten

5.2.3. Keplers drittes Gesetz

Keplers drittes Gesetz besagt, dass sich die Quadrate der Umlaufzeiten zweier Planeten wie die dritten Potenzen der grofien Bahnhalbachsen verhalten. Formel (12) verdeutlicht diese Aussage etwas.

Abbildung in dieser Leseprobe nicht enthalten

Fur die Simulation bedeutet dies, dass die Umlaufzeiten an den Abstand zum zentralen HimmelskOrper gekoppelt sind. Die Anderung der Umlaufzeit eines Planeten andert somit die Umlaufzeiten aller Planeten. Anders ausgedruckt ist die Angabe der Umlaufzeit nur bei einem Planeten notig. Die Umlaufzeiten der anderen Planeten lassen sich daraus herleiten.

5.2.4. Dimensionierung der Parameter

Die Dimensionierung der Einheiten der Parameter wird erst bei der Implementierung festgelegt. Fur die Simulation mussen die eingegebenen Werte an den moglichen Mafistab angepasst werden. Es scheint auch sinnvoller, diese Werte durch praktische Programmie- rung festzulegen als sie theoretisch herzuleiten.

5.2.5. Planetenpositionen darstellen

Es sollen alle Planetenbewegungen gleichzeitig dargestellt werden. Daraus ergibt sich, dass bei der Darstellung eines Planeten nicht darauf gewartet werden kann, bis dieser weiterbewegt werden muss. Das wurde die Bewegung der anderen Planeten behindern.

Als Losungsstrategie wird pro Planet und pro darzustellender Position ein Zahl timeToShow ermittelt, welche angibt, wie oft der Planet beim Durchlauf der Darstellungsschleife an dieser Position dargestellt werden muss. Erst, wenn dieser Zahler Null erreicht hat(wenn er denn dekrementiert wird) wird die nauchste Position berechnet und der Planet ent- sprechend bewegt. Dies gewahrleistet, dass Bewegungen aller Planeten parallel gezeigt werden konnen. Langsame, weil aufiere Planeten, haben einen hoheren Wert fur die Va­riable timeToShow.

Die Zahl timeToShow wird aus der momentanen Geschwindigkeit, der Gesamtumlaufzeit und dem Umfang der Umlaufbahn berechnet.

Die Umlaufbahn der Planeten ist Spiegelsymmetrisch. Eventuell kann dies genutzt werden, um doppelte Berechnungen zu minimieren.

[...]

Ende der Leseprobe aus 91 Seiten

Details

Titel
Dreidimensionale Darstellung und Simulation von Planetenbewegungen anhand der Keplerschen Gesetze
Untertitel
Simulation von Planetenbewegungen mit OpenGL, Qt und C++
Hochschule
Fachhochschule Südwestfalen; Abteilung Iserlohn
Veranstaltung
Software-Engineering
Note
1,0
Autor
Jahr
2012
Seiten
91
Katalognummer
V197566
ISBN (eBook)
9783656373148
ISBN (Buch)
9783656373766
Dateigröße
1195 KB
Sprache
Deutsch
Anmerkungen
Mitautor bei dieser Arbeit ist Christof Geisler.
Schlagworte
Angewandte, Informatik, Angewandte Informatik, Dreidimensional, 3D, OpenGL, Planetenbewegungen, Kepler, Keplerschen Gesetze, Projekt, Software-Engineering, Pflichtenheft, Mockups, Qt Framework, Programmiersprache C++
Arbeit zitieren
Fabian Deitelhoff (Autor), 2012, Dreidimensionale Darstellung und Simulation von Planetenbewegungen anhand der Keplerschen Gesetze, München, GRIN Verlag, https://www.grin.com/document/197566

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Dreidimensionale Darstellung und Simulation von Planetenbewegungen anhand der Keplerschen Gesetze



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden