Entwurfsdokumentation Missionsbasierte Flugplangenerierung und optimierung

Transkript

1 Entwurfsdokumentation Missionsbasierte Flugplangenerierung und optimierung Projekt: Missionsbasierte Flugplangenerierung und optimierung 1.0 Voraussetzung: Pflichtenheft Fabian Kittler Daniel Korinek Ralf Rothenberger Richard Sieder Ghislain Tchibinda Home: Dokuwiki der Projektgruppe 10 letzte Änderung: 10. Juni 2009 Gruppenmitglieder:

2 INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Einleitung Zweck des Systems Entwurfsziele Grobentwurf Architekturmuster und Systemzerlegung Model-View-Controller Übersicht Model View Controller Management persistenter Daten Datenbank properties-Dateien Sicherheit und Zugriffskontrolle Globaler Kontrollfluss Randbedingungen Feinentwurf Richtlinien der Schnittstellendokumentation Pakete Übersicht von Paketen Beschreibung der Pakete model controller view Umgang mit Paketen Entwurfsmuster Factory Singleton Facade Decorator Iterator Klassen und Schnittstellen Controller Function Plausibility Exception Model Klassen

3 INHALTSVERZEICHNIS Factoryklassen View Glossar 55 5 Referenzen 57 3

4 1 EINLEITUNG 1 Einleitung 1.1 Zweck des Systems Welchen Zweck erfüllt das Softwaresystem? Flugplaner stellt einen benutzerfreundlichen Dienst dar, der die Erstellung und das Editieren von Flughäfen, -plänen und -missionen sowie den Export der Flugpläne zur Nutzung in einer Simulation mit MLDesigner ermöglichen soll. 1.2 Entwurfsziele Welche Anforderungen soll das System erfüllen? Korrektheit: Alle Funktionen sollen ihre Aufgaben wie vorgesehen erfüllen. Zuverlässigkeit: Nach der Installation soll das System problemlos laufen. Eventuell auftretende Fehler sollen die Funktionsfähigkeit des Softwaresystems nicht beeinflussen. Erweiterbarkeit: Das System soll zum Zwecke einer zukünftigen Weiterentwicklung erweiterbar sein. Mögliche Erweiterungen könnten sein: weitere Sprachen automatische Missionsgenerierung Missionsoptimierung evtl. neue Funktionen Veränderbarkeit: Im Zuge der Weiterentwicklung soll es auch möglich sein das bestehende System zu verändern. Mögliche Änderungen könnten sein: Verbesserung der GUI Einbindung einer anderen Datenbank Verbesserung des Datenmodells nachträgliche Fehlerbeseitigung neue Version des Tools Verständlichkeit: Laufende Kommentare im Code und eine ausführliche Dokumentation sollen das Verständnis des Systems für nachfolgende Entwickler ermöglichen. Performanz: Dies betrifft vorallem die Performanz beim Navigieren auf der Weltkarte. Es soll eine flüssige Bildwiederholrate auf handelsüblichen PCs mit aktueller Grafikkarte garantiert werden. 4

5 1 EINLEITUNG Nutzerfreundlichkeit: Die grafische Benutzeroberfläche soll intuitiv bedienbar sein und auch unerfahrenen Nutzern eine einfache Interaktion mit dem System ermöglichen. Bei auftretenden Fehlern oder ungültigen Eingaben soll dem Benutzer ein entsprechender Hinweis angezeigt und die Möglichkeit einer erneuten Eingabe angeboten werden. Portierbarkeit: Das Softwaresystem soll weitestgehende Unabhängigkeit vom verwendeten Betriebssystem ermöglichen. 5

6 2 GROBENTWURF 2 Grobentwurf 2.1 Architekturmuster und Systemzerlegung Welche Architekturmuster wurden verwendet und warum? Wie ist das System unterteilt? Model-View-Controller Mit Hilfe des Model-View-Controller Architekturmuster erfolgt eine klare funktionsbezogene Trennung einzelner Systemkomponenten in die drei namensgebenden Einheiten Model, View und Controller. Die Vorteile einer solchen Trennung sind: strukturierter, funktional getrennter Systemaufbau reduzierte Komponentenabhängigkeit stark erleichterte nachträgliche Erweiterung bzw. Änderung Wiederverwendung einzelner Systemkomponenten möglich Übersicht Abbildung 1: Model-View-Controller im Kontext des Systems 6

7 2 GROBENTWURF Model Diese Einheit beinhaltet und organisiert ausschließlich die verwendeten Datenmodelle (z.b.: Datenbank,.properties-Dateien, etc.). Dabei ist das Model unabhängig von der Präsentation (View), kennt jedoch den Controller View Verantworlich für die Darstellung der vom Controller erhaltenen Daten. Desweiteren wird jegliche Nutzerinteraktion von dieser Schicht realisiert.view kennt dabei den Controller, jedoch nicht das Model Controller Der Controller ist für die Steuerung des Programmablaufes und die Verwaltung der von View generierten Daten verantworlich. Als einzige Komponente in diesem Architekturmuster kennt der Controller sowohl Model als auch View. 7

8 2 GROBENTWURF 2.2 Management persistenter Daten Wie werden persistente Daten vom System gespeichert und verwaltet? Die Speicherung der Daten wird zweckgebunden auf 2 unterschiedliche Arten erfolgen Datenbank In der Datenbank werden hauptsächlich alle Daten gespeichert mit denen die Missionserstellung erfolgt. Diese Daten können/werden sich im Verlauf des Programmes häufig ändern. Die Einstellungen der Datenbank werden in einer.xml-datei festgehalten, dies betrifft unter anderem die Adresse der Datenbank, Benutzername und Passwort für den Zugriff auf die Datenbank. Der Zugriff auf die Datenbank erfolgt nur über die Factory-Klassen (siehe Klassen und Schnittstellen). Dem Benutzter wird es nicht erlaubt sein eigene SQL-Anweisungen vom Programm aus auszuführen. Die Daten der Datenbank sind folgendermaßen organisiert: Abbildung 2: Struktur der internen Datenhaltung 8

9 2 GROBENTWURF properties-Dateien In den.poperties-dateien werden die Daten gespeichert, welche sich nicht häufig ändern und nicht im direkten Sinne etwas mit der Missionsplanung zu tun haben. Die.poperties-Dateien werden im Verzeichnis des Programmes gespeichert. Der Zugriff auf die.properties-dateien erfolgt nur über die Factory-Klassen (siehe Klassen und Schnittstellen). Abbildung 3: Struktur der externen Datenhaltung 9

10 2 GROBENTWURF 2.3 Sicherheit und Zugriffskontrolle Welche sicherheitsrelevanten Anforderungen soll das System erfüllen? Eine Zugriffskontrolle erfolgt im wesentlichen nicht. Es wird davon ausgegangen dass nur die jeweils berechtigten Personen Zugriff auf das Programm haben. Einzige Ausnahme bildet die Datenbank, für die ein Benutzername und Passwort notwendig sind. 10

11 2 GROBENTWURF 2.4 Globaler Kontrollfluss Welche Abläufe finden im System statt und wie werden diese organisiert? Der gesamte Kontrollfluss des Systems orientiert sich am verwendeten MVC-Modell und wird zentral durch den Controller und synchrone Call/Return - Aufrufe gesteuert. Die nachfolgenden Sequenz-Diagramme sollen einen groben Ablauf der Kommunikation zwischen GUI, Controller und Model abhandeln, wobei die Aufmerksamkeit auf GUI - Controller liegt. 11

12 2 GROBENTWURF createplanetype Bei der Erzeugung von Flugzeugtypen ruft die GUI vom Interface des Controllers die Funktion createplanetype auf. Danach ist das Problem für die GUI abgearbeitet. Der Controller überprüft die Eingaben wieder auf Fehler und versucht über die Modelschnittstelle den Flugzeugtyp zu erstellen. Sollte dabei wieder ein Fehler auftreten, so ruft der Controller eine der Benachrichtigungsfunktionen der GUI auf. Ganz unten wird wieder der Normalfall dargestellt. Die anderen create- und add- Methoden laufen im Grunde äquivalent ab und bedürfen daher keiner weiteren Erläuterung. Abbildung 4: Ablauf von createplanetype 12

13 2 GROBENTWURF createairport Abbildung 5: Ablauf von createairport 13

14 2 GROBENTWURF addairport Abbildung 6: Ablauf von addairport 14

15 2 GROBENTWURF createflightplan Abbildung 7: Ablauf von createflightplan 15

16 2 GROBENTWURF createmission Abbildung 8: Ablauf von createmission 16

17 2 GROBENTWURF addstation Abbildung 9: Ablauf von addstation 17

18 2 GROBENTWURF search* Die Suchfunktionen für die entsprechenden Datentypen verlaufen im wesentlichen immer gleich. Die GUI ruft den Controller auf, dieser versucht im Model etwas zu finden. Falls ein Fehler auftritt wird über die Schnittstelle der GUI wieder ein Fehler ausgegeben. Abbildung 10: Ablauf von searchplanetype 18

19 2 GROBENTWURF Abbildung 11: Ablauf von searchexistingairport 19

20 2 GROBENTWURF Abbildung 12: Ablauf von searchairport 20

21 2 GROBENTWURF Abbildung 13: Ablauf von searchflightplan 21

22 2 GROBENTWURF Abbildung 14: Ablauf von searchmission 22

23 2 GROBENTWURF importpdf Der Benutzer hat sich über die GUI ein PDF-Dokument ausgewählt um einen Flugplan auszulesen. Die GUI verwendet importpdf von der Controller-Schnittstelle, um den Pfad zu übergeben. Die GUI wird sich im folgenden darum nicht mehr kümmern. Falls beim Auslesen der Datei Fehler auftreten oder beim Einlesen Plausibilitäten verletzt werden, wird vom Controller aus ein Pop-Up Fenster der GUI aufgerufen, in dem der Controller darauf hinweist, dass etwas nicht in Ordnung ist. Dafür stehen die Methoden yesnomessage(string Message) und okdetailmessage(string Message, String Details) zur Verfügung. Falls ein erfolgreicher Import aller Flugpläne des PDF-Dokuments möglich ist, wird das Subsystem Model aufgerufen und die Flugpläne werden erstellt (in der Datenbank). Abbildung 15: Ablauf von importpdf 23

24 2 GROBENTWURF 2.5 Randbedingungen Welche Bedingungen und Einschränkungen des Projekts sind bereits vorgegeben? Entwurfsanforderungen, die an das System gestellt werden. Das System soll eine grafische Benutzeroberfläche bereitstellen, die folgende Elemente enthalten soll: zoombare Weltkarte, auf der Flughäfen anhand ihrer GPS-Koordinaten gelöscht und hinzugefügt werden können Visualisierung von Verbindungen zwischen Flughäfen Liste hinzugefügter Flughäfen Liste möglicher Anschlussflüge für Stationen bei der Missionserstellung bearbeitbare Tabelle aller erstellten Missionen Es soll eine Schnittstelle zum Import von Flugplänen aus entsprechenden PDF-Dateien existieren. Es soll zwischen den Sprachen Deutsch und Englisch gewählt werden können. Der Benutzer kann einen Initialzustand bestehender Flughäfen oder alle aktuell hinzugefügten Flughäfen, Flugpläne und Missionen exportieren und importieren. (Speichern und Laden) Erstellte Missionen sollen im.csv-format exportiert werden können. Die interne Datenhaltung des Systems soll über eine Datenbank erfolgen. Alle Datenbankinhalte sollen vor der Aufnahme auf Plausibilität geprüft werden. Die Produktumgebung des fertigen Systems soll ein handelsüblicher Desktop-PC sein. Es kann keine Internetverbindung für das Softwaresystem garantiert werden. Bei der Interaktion mit der Weltkarte soll eine flüssige Bildwiederholrate von mindestens 20 fps gewährleistet sein. Das System soll plattformunabhängig mindestens auf Windows- und Linux-Betriebssystemen arbeiten. Quelloffene Programmierung und gute Dokumentation werden zur Gewährleistung von Änderbarkeit und Wartbarkeit vorausgesetzt. 24

25 3 Feinentwurf 3.1 Richtlinien der Schnittstellendokumentation Welche einheitlichen Vorgaben existieren zur Dokumentation von Schnittstellen? Die Dokumentation des Quelltextes wird mit Hilfe des Programmes Doxygen erstellt. Dieses Tool ermöglicht es, aus dem kommentierten Quelltext eine Dokumentation in Form von html-, LaTex-,... Dateien zu erstellen. Die Art der Dokumentation entspricht im wesentlichen der von Javadoc. Es werden Pakete, Interfaces, Klassen, Methoden und Attribute dokumentiert. Wobei in Klassen nur ein kurzer Kommentar steht, was die betreffenden Methoden machen. Die Ausführliche Dokumentation der Methoden erfolgt dann in den Interfaces. Ausgenommen sind Klassen die kein Interface besitzten oder private Methoden haben, in ihnen werden die Methoden direkt kommentiert. Attribute sollten so ausfürlich wie nötig kommentiert werden. Zu jeder/-m Klasse/Interface gehören die Namen der Personen die an dieser Datei mitgearbeitet haben. 25

26 3.2 Pakete In welche Pakete ist das System unterteilt? Pakete sind Sammlungen von zusammengehörenden Java-Klassen Übersicht von Paketen Abbildung 16: Übersicht über die Paketstruktur des Systems 26

27 3.2.2 Beschreibung der Pakete Die Pakete unterteilen sich gemäß MVC-Muster in Controller, Model und View. Dadurch wird die Trennung von Anzeige, Steuerung und Datenstruktur erreicht. In jedem der Pakete erfolgt nochmal eine Unterteilung in api und impl. Im api-paket werden die Schnittstellen definiert, über die die Klassen miteinander kommunizieren. Im impl-paket erfolgt die eigentliche Implementierung der Klassen. Nicht jede Klasse hat auch ein Interface, so kann es vorkommen, dass sich in den impl-paketen mehr Klassen befinden werden als in den api-paketen model Im model-paket wird die Datenstruktur der verwendeten Objekte festgelegt und wie sie gespeichert werden. Im weiteren teilt sich das Paket in 2 Unterpakete auf, in die Strukturen und die Funktionen auf diesen. om: In diesem Paket ist die Struktur der Objekte definiert, die zur Laufzeit benötigt werden. factory: Hier erfolgt die Erzeugung und der Speicher- bzw. Lade-Vorgang der Objekte aus dem om-paket, da man nur innerhalb des model-paketes die Klassen kennen und verwenden soll. Diese Pakete unterteilen sich jeweils in db und file, was auf die Art der Speicherung der Daten zurückzuführen ist. db: Diese Klassen werden innerhalb der Datenbank gespeichert. file: Die Speicherung dieser Klassen erfolgt in.properties-dateien controller Im controller-paket wird die globale Steuerung des Programmes festgelegt und die Eingaben aus dem view-paket geprüft und verwaltet, um einen integren Datenbestand zu gewärleisten. Desweiteren werden hier auch die Informationen für den view vorbereitet und verarbeitet, damit er diese ohne Aufwand nutzen kann. Dazu werden die Funktionen in folgende Pakete unterteilt: exception: In diesem Paket sind die Fehler mit ihren Behandlungen definiert, es erfolgt auch gegebenenfalls eine Benachrichtigung des view. function: Die Hauptfunktionalitäten des controller-paketes werden hier beschrieben. Dies sind zum einen die Umwandlung der Daten in die entsprechenden Formate für model und view. Weiterhin werden verschiedene Berechnungen und Umrechnungen durchgeführt. Ebenso ist hier die Schnittstelle zum view festgelegt. plausibility: Hier sind die verschiedenen Plausibilitäten festgehalten, die für bestimmte Funktionen des controller-paketes geprüft und erfüllt werden müssen. 27

28 view Im view-paket ist zum einen die gesamte Darstellung der GUI mit ihren Aktionen festgelegt und zum anderen die Schittstelle für Nachrichten, die vom controller aus gesendet werden können. Eventuell wird im Verlauf der Implementierung hier eine weitere Unterteilung des Paketes erfolgen, welche aber zur Zeit nicht festgelegt wird, um flexibel zu bleiben Umgang mit Paketen Das Übersetzen von Dateien aus Paketen, Ausführung von Programmen in Paketen und Importieren von Klassen laufen wie bei allen anderen Java Programmen ab. Eine Einleitung dafür findet man in der Java Documentation. Hier noch ein kleines Beispiel für Import von Klassen, die in Paketen als public deklariert sind. import flp.model.api.om.db.iairport; bwz. import flp.model.api.om.db.*; //für den bedarfsmäßigen Import von beliebigen public Klassen aus dem Paket 28

29 3.3 Entwurfsmuster Welche Entwurfsmuster werden wo, wie und wofür verwendet? Factory Das Factory Pattern wird zu Erstellung von Objekten innerhalb des Models benötigt Singleton Singleton ist ein Erzeugungsmuster und verhindert, dass verschiedene Komponenten, wie die GUI oder der Controller mehrmals existieren Facade Dieses Entwurfsmuster dient der leichteren Erweiterbarkeit und Veränderbarkeit zwischen GUI und Controller Decorator Das Decorator Entwurfsmuster wird bei unserem Programm hauptsächlich in der GUI verwendet um verschiedene Funktionen leichter erweiterbar zu gestalten Iterator Der Iterator wird zum iterieren über Listen benötigt, bei der Verwaltung von Daten aus der Datenbank. 29

30 3.4 Klassen und Schnittstellen Auflistung aller Klassen mit ihren Schnittstellen Controller Function Das nachfolgende Klassenmodell ist eine vereinfachte Darstellung des tatsächlichen Interfaces vom Controller für die GUI. Sie dient hauptsächlich der Dokumentation der wesentlichen Methoden, die von der GUI aufgerufen werden können. Diese werden alle im Function-Paket des Controllers zusammengefasst. Abbildung 17: Controllerschnittstelle 30

31 Plausibility Die im Plausibility-Paket enthaltenen Klassen dienen der Plausibilitätsprüfung der verschiedenen Eingabedaten und bieten zu diesem Zweck jeweils eine dem Controller allein bekannte check-methode an. Darüberhinaus enthalten sie noch einige private Hilfsmethoden. AirportPlausibility Überprüft die Plausibilität eines Flughafens. Abbildung 18: Struktur von AirportPlausibility FlightplanPlausibility Überprüft die Plausibilität eines Flugplanes. Abbildung 19: Struktur von FlightplanPlausibility MissionPlausibility Überprüft die Plausibilität einer Mission, wobei die Plausibilität einzelner Stationen durch MissionStationPlausibility geprüft wird. Abbildung 20: Struktur von MissionPlausibility 31

32 MissionStationPlausibility Überprüft die Plausibilität einer einzelnen Missionsstation unter Vorgabe einer konkreten Mission und der Position der Station im Rundkurs. Abbildung 21: Struktur von MissionStationPlausibility PlaneTypePlausibility Überprüft die Plausibilität eines Flugzeugtypen. Abbildung 22: Struktur von PlaneTypePlausibility 32

33 Exception FPException FPException stellt eine abstrakte Klasse dar, die von der Java-Klasse Exception abgeleitet ist und die öffentliche Methode handle() bereitstellt. Alle restlichen im Exception- Paket enthaltenen Klassen sind von FPException abgeleitet und implementieren die überschriebene handle()-methode zur Ausnahmebehandlung. Desweiteren enthalten alle Exceptions, denen bei der Erzeugung Variablen übergeben werden, diese als private Attribute. AirportExceptions AirportFileNotAccessibleException() AirportIATAAlreadyExistsException(String iata) AirportICAOAlreadyExistsException(String icao) AirportNotExistingException(String iata) AirportNotAddedException(String iata) IdenticalAirportsException(String iata) InvalidAirportIATAException(String iata) InvalidAirportICAOException(String icao) InvalidTimeZoneException(int timezone) InvalidGPSException(int latitudedegree, int latitudeminute, int longitudedegree, int longitudeminute) NoAirportFoundException() FlightplanExceptions FlightPlanNotExistingException(IFlightPlan flightplan) FlightPlanAlreadyInUseException(IFlightPlan flightplan) FlightPlanAlreadyExistsException(IPlaneType planetype, IAirport departure, IAirport arrival, int departuretime, int arrivaltime, int distance, int flighttime, Day day) InvalidDistanceException(int distance) InvalidFlightTimeException(int flighttime) InvalidDayException(Day day) InvalidDepartureTimeException(int departuretime) InvalidArrivalTimeException(int arrivaltime) NoFlightPlanFoundException() 33

34 PlaneTypeExceptions PlaneTypeFileNotAccessibleException() PlaneTypeNotExistingException(IPlaneType planetype) PlaneTypeIATAAlreadyExistsException(String iata) PlaneTypeMismatchException(IPlaneType planetype1, IPlaneType planetype2) InvalidRangeException(int range) InvalidConsumptionException(int consumption) InvalidRegenerationException(int regeneration) NoPlaneTypeFoundException() MissionExceptions MissionIncompleteException() StationsNotConnectedException(IFlightPlan station1, IFlightPlan station2) TargetOutOfRangeException(int distance, int range) InvalidStayTimeException(int staytime) NoMissionFoundException() FunctionExceptions DatabaseNotAccessibleException() PDFNotFoundException(String path) ParsingException() 34

35 3.4.2 Model Klassen Die Klassen sind die wesentlichen Objekte, die an der Missionsplanung beteiligt sind. Darüber hinaus wird das Datenmodell für Ressourcen definiert, welche aber (noch) nicht in das Programm eingebunden werden, sondern zur Erweiterbarkeit des Programms für spätere Funktionen beitragen sollen. Alle Methoden, die Klassen haben, sind ausschließlich Getter und Setter für die Attribute der Klassen. Die Namen der Getter und Setter ergeben sich aus get bzw. set und dem Attributnamen. Abbildung 23: Gesamtstruktur der Model-Klassen 35

36 Airport implementiert IAirport Aufgenommener Flughafen: Ein Flughafen, der auf der Karte oder aus einer Liste ausgewählt werden kann um Flugpläne und Missionen zu erstellen. Abbildung 24: Struktur von Airport CabinCrew implementiert ICabinCrew Kabinen-Crew: Der Teil der Besatzung eines Flugzeuges, der sich um die Versorgung der Passagiere kümmert. Abbildung 25: Struktur von CabinCrew 36

37 Crew implementiert ICrew Besatzung:Abstrakte Klasse für die Modellierung der Flugbegleitung. Abbildung 26: Struktur von Crew Employee implementiert IEmployee Pesonal: Abstrakte Klasse für die Modellierung der Angestellten. Abbildung 27: Struktur von Employee 37

38 Flightplan implementiert IFlightplan Flugplan: Ein Flug der von einem Start (-flughafen) zu einem Ziel (-flughafen) innerhalb einer bestimmten Zeit mit einem bestimmten Flugzeugtyp fliegt. Abbildung 28: Struktur von Flightplan Mechanic implementiert IMechanic Mechaniker: Personal welches sich um die Reparatur der Flugzeuge kümmert. Abbildung 29: Struktur von Mechanic 38

39 Mission implementiert IMission Mission: Ein Rundflug besteht aus vielen Missionsstationen und bildet eine Schleife eines Flugzeuges. Beginnt und endet an einem bestimmten Flughafen. Abbildung 30: Struktur von Mission MissionStation implementiert IMissionStation Missionsstation: Ein Teilflug einer Mission, stellt die Verbindung zwischen Missonen und Flugplänen her. Abbildung 31: Struktur von MissionStation 39

40 PilotCrew implementiert IPilotCrew Piloten-Crew: Der Teil der Besatzung eines Flugzeuges, der das Flugzeug steuert. Abbildung 32: Struktur von PilotCrew Ressource implementiert IRessource Ressource: Ein Betriebsmittel, das zum Erstellen einer Missionsstation ge- bzw. verbraucht wird. Abbildung 33: Struktur von Ressource 40

41 Desweiteren existieren 2 weitere Klassen für Flugzeugtypen und existierende Flughäfen, die im wesentlichen der Speicherung von Daten dienen. Auch hier sind alle Methoden ausschließlich Getter und Setter. ExistingAirport implementiert IExistingAirport Existierender Flughafen: Ein Flughafen der nur zur Speicherung der Daten dient, er kann jederzeit aufgenommen werden um mit ihm zu arbeiten. Abbildung 34: Struktur von ExistingAirport PlaneType implementiert IPlaneType Flugzeugtyp: Die verschiedenen Typen von Flugzeugen mit ihren Eigenschaften. Abbildung 35: Struktur von PlaneType 41

42 Factoryklassen Es wird/soll dem View und Controller nicht erlaubt sein Instanzen der Klassen direkt zu erstellen. Dies soll ausschließlich durch die Methoden der Factory-Klassen geschehen. Somit soll die Erzeugung von nicht existenten Objekten vermieden werden und ein einheitlicher Umgang mit ihnen erfolgen. Abbildung 36: Gesamtstruktur der Factoryklassen mit Datenbankanbindung 42

43 Abbildung 37: Gesamtstruktur der Factoryklassen mit.property-file-anbindung 43

44 AirportFactory implementiert IAirportFactory, abgeleitet von DatabaseFactory Abbildung 38: Struktur von AirportFactory 44

45 CabinCrewFactory implementiert ICabinCrewFactory, abgeleitet von DatabaseFactory Abbildung 39: Struktur von CabinCrewFactory DatabaseFactory (abstrakt) Abbildung 40: Struktur von DatabaseFactory 45

46 ExistingAirportFactory implementiert IExistingAirportFactory, abgeleitet von FileFactory Abbildung 41: Struktur von ExistingAirportFactory FileFactory (abstrakt) Abbildung 42: Struktur von FileFactory 46

47 FlightplanFactory implementiert IFlightplanFactory, abgeleitet von DatabaseFactory Abbildung 43: Struktur von FlightplanFactory ImportExportFactory implementiert IImportExportFactory, abgeleitet von DatabaseFactory Abbildung 44: Struktur von ImportExportFactory 47

48 MechanicFactory implementiert IMechanicFactory, abgeleitet von DatabaseFactory Abbildung 45: Struktur von MechanicFactory MissionFactory implementiert IMissionFactory, abgeleitet von DatabaseFactory Abbildung 46: Struktur von MissionFactory 48

49 PilotCrewFactory implementiert IPilotCrewFactory, abgeleitet von DatabaseFactory Abbildung 47: Struktur von PilotCrewFactory PlaneTypeFactory implementiert IPlaneTypeFactory, abgeleitet von FileFactory Abbildung 48: Struktur von PlaneTypeFactory 49

50 Alle Factoryklassen (außer der ImportExportFactory, DatabaseFactory, FileFactory) haben einige Methoden als Gemeinsamkeit: create, delete, deleteall, getall, getbyid (außer bei AirportFactory, dort wird diese Funktion durch getiata realisiert), createall (außer ExistingAirportFactory und PlaneTypeFactory), update. Diese Methoden unterscheiden sich nur Aufgrund ihrer Parameter, die beispielsweise zur Erstellung der jeweiligen Klasse notwendig sind. Deswegen werden sie allgemein, stellvertetend für alle Klassen beschrieben. create Attribute: Daten der Objekte Rückgabewert: Objekt der jeweiligen Klasse Beschreibung: erstellt ein Objekt der jeweiligen Klasse, speichert es in der Datenbank und gibt es zurück delete Attribute: Objekt der jeweiligen Klasse Rückgabewert: - Beschreibung: löscht das Objekt der jeweiligen Klasse aus der Datenbank deleteall Attribute: - Rückgabewert: - Beschreibung: löscht alle Objekte der jeweiligen Klasse aus der Datenbank getall Attribute: - Rückgabewert: Liste von Objekten der jeweiligen Klasse Beschreibung: gibt alle Objekte der jeweiligen Klasse aus die sich in der Datenbank befinden getbyid / getbyiata Attribute: long id / String iata Rückgabewert: Objekt der jeweiligen Klasse Beschreibung: sucht ein Objekt nach einem gegebenen Primärschlüssel createall Attribute: Feld von Daten der Objekte Rückgabewert: - Beschreibung: Objekte werden in die Datenbank aufgenommen (mit Primärschlüssel) update Attribute: Objekt der jeweiligen Klasse Rückgabewert: - Beschreibung: speichert vorgenommene Änderungen an dem Objekt 50

51 Zusätzliche Methoden der anderen Klassen: AirportFactory/ExistingAirportFactory getbyicao Attribute: String icao Rückgabewert: Airport Beschreibung: sucht den Flughafen mit dem gegebenen ICAO-Code getbylikeiata Attribute: String iata Rückgabewert: Liste von Flughafen Beschreibung: sucht die Flughäfen, bei denen der gegebene String Teil ihres IATA- Codes ist getbylikeicao Attribute: String icao Rückgabewert: Liste von Flughafen Beschreibung: sucht die Flughäfen, bei denen der gegebene String Teil ihres ICAO-Codes ist getbylikename Attribute: String name Rückgabewert: Liste von Flughafen Beschreibung: sucht die Flughäfen, bei denen der gegebene String Teil ihres Namens ist FlightplanFactory MissionFactory getbydata Attribute: IAirport departure, IAirport arrival, int departuretimefrom, int departuretimeuntil, String planetype, Day day Rückgabewert: Liste von Flugplänen Beschreibung: sucht nach Flugplänen, die die angegebenen Daten haben (falls ein null-wert gegeben wird wird dieser Teil ignoriert) getbydate Attribute: boolean defect, IFlightplan flightplan Rückgabewert: Liste von Missionen Beschreibung: sucht nach Missionen die die angegebenen Daten haben (falls ein null-wert gegeben wird wird dieser Teil ignoriert) 51

52 ImportExportFactory exportairports Attribute: Liste von Flughäfen Rückgabewert: - Beschreibung: schreibt die übergebenen Flughäfen in eine Datei im Angegebenen Verzeichnis exportflightplans Attribute: Liste von Fluplänen Rückgabewert: - Beschreibung: schreibt die übergebenen Flupläne in eine Datei im Angegebenen Verzeichnis exportmissions Attribute: Liste von Missionen Rückgabewert: - Beschreibung: schreibt die übergebenen Missionen in eine Datei im Angegebenen Verzeichnis exportmissionstations Attribute: Liste von Missionsstationen Rückgabewert: - Beschreibung: schreibt die übergebenen Missionsstationen in eine Datei im Angegebenen Verzeichnis importairports Attribute: - Rückgabewert: - Beschreibung: liest die Daten für die Flughäfen aus einer Datei im Angegebenen Verzeichnis, ruft impliziet die import-methode der jeweiligen Factory auf importflightplans Attribute: - Rückgabewert: - Beschreibung: liest die Daten für die Flupläne aus einer Datei im Angegebenen Verzeichnis, ruft impliziet die import-methode der jeweiligen Factory auf importmissions Attribute: - Rückgabewert: - Beschreibung: liest die Daten für die Missionen aus einer Datei im Angegebenen Verzeichnis, ruft impliziet die import-methode der jeweiligen Factory auf importmissionstations Attribute: - Rückgabewert: - 52

53 Beschreibung: liest die Daten für die Missionsstationen aus einer Datei im Angegebenen Verzeichnis, ruft impliziet die import-methode der jeweiligen Factory auf setlocation Attribute: String location Rückgabewert: - Beschreibung: Setzt den Ort für den Import/Export der Datenbank inhalte 53

54 3.4.3 View Die Klassen der GUI stehen größtenteils noch nicht fest, die Schnittstelle wurde aber schon spezifiziert: Abbildung 49: GUI-Schnittstelle Desweiteren wurde bereits ein Prototyp angefertigt, der das zukünftige Aussehen der Benutzeroberfläche widerspiegeln soll. Abbildung 50: Prototyp der GUI 54

55 4 GLOSSAR 4 Glossar Definition aller wichtigen Begriffe zur Sicherstellung einer einheitlichen Terminologie. AWT steht für Abstract Window Toolkit und ist eine Standard-API für die Erstellung einer GUI für Java-Programme. csv steht für Comma Separated Value und ist eine Textdatei, deren Werte durch Kommas getrennt sind. Flugpläne sind die von der Fluggesellschaft erhaltenen Daten, die Flüge charakterisieren. Flugplaner ist das Tool, das im Rahmen des Softwareprojektes entwickelt wird GPS steht für Global Positioning System und ist ein satellitengestütztes Navigationssystem. GUI steht für Graphical User Interface und bezeichnet die grafische Benutzeroberfläche. HS steht für Hautpseminar. IATA-Codes dienen der eindeutigen Identifizierung von Flughäfen, sie werden von der IATA (International Air Transport Association) vergeben. ICAO-Codes dienen der eindeutigen Identifizierung von Flughäfen, sie werden von der ICAO (International Civil Aviation Organization) vergeben. Kurzstreckenflüge sind Flüge unter 1620 Meilen. Langstreckenflüge sind Flüge mit 1620 Meilen und mehr. Meilen Gemeint sind nautische Meilen. Diese entsprechen 1852 Metern (gemäß DIN 1301 und ISO 31-1). Missionen sind zusammgestellte Flüge eines Flugzeuges mit dem selben Start- und Zielflughafen. MLDesigner ist eine integrierte Plattform zur Modellierung und Analyse der Architektur, Funktion und Leistungsfähigkeit von High-Level-Systementwürfen - entweder als System für sich oder als System im Umfeld eines größeren Systems oder Szenarios (d.h. Missionen). MVC steht für Model-View-Controller und ist ein Architekturmuster Plausibilitätprüfung bestimmt Stimmigkeit/Zulässigkeit von Flugplänen/Missionen. Regenerationszeit ist die Zeit, die eine Crew benötigt, um erneut arbeiten zu können, nachdem sie ihre maximale Arbeitszeit erreicht hat. SVN steht für Subversion und ist ein Programm zur Versionsverwaltung von Dateien. 55

56 4 GLOSSAR SWP steht für Softwareprojekt. SWT steht für Standard Widget Toolkit und ist eine von IBM entwickelte Bibliothek für die Erstellung einer GUI für Java-Programme. UTC steht für Universal Time Coordinate (koordinierte Weltzeit) und ist das verwendete Format für Zeitangaben. 56

57 5 REFERENZEN 5 Referenzen Angabe benutzter Quellen und Referenzen Java-API Informationen zur Dokomentierung des Tools Einfaches Beispiel für das Decorater-Entwurfsmuster Zweites Beispiel für das Decorater-Entwurfsmuster Observer Entwurfsmuster mit UML Beispiel von Wikipedia MVC-Artikel von Wikipedia Allgemeine Information zum Entwurf Informationen zum Entwurf aus der Softwaretechnik-Vorlesung Informationen über das deutsche Flugrecht GPS Umrechnung von Koordinaten in Distanz 57