Dokumentation Tyr Semesterarbeit in Informatik

Transkript

1 Dokumentation Tyr Semesterarbeit in Informatik Studierender: Stefan Laubenberger Projektbetreuer: Michael Reiser HSZ-T - Hochschule für Technik Zürich 15. Februar 2011

2 Zusammenfassung Wer tagtäglich mit Computern arbeitet, kommt immer wieder in die Situation, dass er viele kleine Programme für unterschiedliche Arbeiten benötigt. Diesen Programmen fehlen oft die Möglichkeiten, das Aussehen und die Grösse der Benutzeroberfläche zu verändern oder in verschiedenen Sprachen verwendet zu werden. Diese Flut von heterogenen Programmen erschwert die Nutzung des Potentials von Computern unnötig. Hier setzt Tyr an und bietet eine Umgebung, in welcher Module jedweder Herkunft und mit beliebigem Funktionsumfang hinzugefügt werden können. Diese Module sind sehr einfach zu implementieren und haben einen privaten Daten- und DB-Container. Der Prototyp, welcher während dieser Arbeit entwickelt wurde, ist unter Open-Source GPLv2 auf GoogleCode veröffentlicht und steht allen Nutzern zur Verfügung. Abbildung 0.1 zeigt das Logo von Tyr: Abbildung 0.1.: Tyr-Logo

3 Inhaltsverzeichnis 1. Einleitung 1 2. Projektdefinition Ausgangslage Ziel der Arbeit Abgrenzung Reglement, Ablauf und Bewertungskriterien Sprache Planung Aufwandschätzung Projekt Dokumentation Software Zusammenfassung Projektplan Projekt Dokumentation Software Analyse Anwendungsfälle Lastenheft Zielbestimmungen Produkteinsatz Produktfunktionen Produktdaten Produktleistungen Qualitätsanforderungen Ergänzungen Marktsituation Software Entscheid Pflichtenheft Zielbestimmungen Produkteinsatz Produktumgebung Produktfunktionen Produktdaten Produktleistungen Benutzeroberfläche I

4 Qualitätszielbestimmungen Globale Testszenarien und Testfälle Entwicklungsumgebung Ergänzungen Glossar Entwurf Architekturübersicht Hilfsmittel Generell eingesetzte Hilfsmittel Plattformunabhängig System-Tray Module Wählbare Sprachen Skalierbare Schriften Module und Threads Data-Container Modul MusicPlayer Modul Scrambler Evaluation der Libraries Wählbare Look & Feels Skalierbare Icons DB-Container Architektur Flussdiagramm Klassendiagramme Datenstrukturen Entwicklungsumgebung Betriebssytem Programmiersprache IDE Virtualisierung Texteditor Konzeptionelle Visualisierung Office Grafik Projekthosting Wiki Versionierung Build-Prozess Testen Realisierung Projektsetup Maven Repositories Entwicklung Allgemein II

5 Paket module Paket application Modul Test Modul MusicPlayer Modul Scrambler Release Vorbereitung Betriebssysteme Projekthosting Homepage SVN Repository Wiki API Testen Globale Testszenarien und Testfälle Plattformunabhängigkeit System-Tray Module Wählbare Look & Feels Wählbare Sprachen Skalierbare Schriften Skalierbare Icons Module und Threads Data-Container DB-Container Modul MusicPlayer Modul Scrambler Benutzerdokumentation Vorbereitung Installation Windows MacOS X Unix/Linux Module Modul hinzufügen oder entfernen Modul aktivieren oder deaktivieren Deinstallation Windows MacOS X Unix/Linux Projektmanagement Angewandte Methoden Wasserfall-Modell Lastenheft III

6 Pflichtenheft Aufwandschätzung UML Flussdiagramm Wireframe Gegenüberstellung der Planung und Realisierung Projekt Dokumentation Software Zusammenfassung Zusammenfassung und Ausblick Fazit Weiterentwicklung Zusätzliche Anforderungen Dokumentation Modulideen Danksagung 113 Abkürzungsverzeichnis 114 Abbildungsverzeichnis 115 Tabellenverzeichnis 117 Listings 119 Literaturverzeichnis 120 A. Personalienblatt 122 B. Bestätigung 123 C. Anhang 124 C.1. Aufgabenstellung C.2. Kick-Off Protokoll C.3. Design-Review Protokoll C.4. Repository C.5. Wiki C.6. API C.7. Stundenerfassung IV

7 1. Einleitung Menschen, die einen Computer intensiv benutzen müssen, sehen sich oft mit der Tatsache konfrontiert, dass sie eine Unmenge an Programmen verwenden müssen, um ihre Tätigkeiten zu erledigen. Die meisten dieser Programme haben unterschiedliche Benutzeroberflächen und bieten selten die Möglichkeit, diese in Erscheinung sowie Grösse anzupassen. Erschwerend kommt hinzu, dass viele namhafte Hersteller ihre Software nur in Englisch anbieten. Die meisten dieser Programme erfüllen auch nur einen einfachen Zweck und werden trotzdem für die tägliche Arbeit benötigt. Bei mir führt dies oft zu einem überfüllten Desktop, auf dem ich dauernd die nicht mehr benötigten Programme entfernen muss. Diesem Umstand möchte ich mit dem Prototypen aus dieser Semesterarbeit Abhilfe schaffen. Seit 2007 pflege ich eine eigene Open-Source-Library namens Bogatyr. Diese vereint viele Funktionen, welche für den Endanwender kaum sichtbar sind, wie z.b. Funktionen für das Einlesen oder Schreiben von Dateien. Ein weiteres Ziel ist also, für diese Library eine Benutzeroberfläche zu schaffen. So entstand unter anderem der Name für das Programm Tyr, um die Verwandtschaft zu symbolisieren. In der vorliegenden Semesterarbeit widme ich mich der Lösung der oben beschrieben Probleme. Es wird als erstes das Projekt genau definiert, eine Planung erstellt und anschliessend ein Lastenund Pflichtenheft erstellt. Danach werden die Architektur, die benötigten Bibliotheken und die Programme zum Erstellen eines Prototypen definiert. Zusätzlich wird auf die Realisierung, das Testen der Applikation, die Hürden, die Erfolge und die Erkenntnisse eingegangen. 1

8 2. Projektdefinition 2.1. Ausgangslage Wie in der Einleitung erwähnt gibt es immer wieder Situationen, in welchen man ein kleines Programm für eine bestimmte Aufgabe benötigt, wie z.b. für das Verschlüsseln einer Datei oder das konvertieren von Bildern in ein anderes Format. Der Benutzer endet über kurz oder lang in einer Flut solcher funktional kleiner Programme und da setzt meine Idee an. Anstelle vieler Programme gibt es ein Programm, welches beliebig mit neuen Applikationen (Plugins) erweitert werden kann. Das Ziel ist es dabei, dem Plugin-Ersteller möglichst viele Freiheiten zu lassen und ihm ein klar definiertes Set an Methoden zur bidirektionalen Kommunikation zwischen Hauptapplikation und Plugin zu liefern. Das Hauptprogramm informiert das Plugin über globale Änderungen wie Sprache und umgekehrt ermöglicht es dem Plugin Informationen oder Tasks im Hauptprogramm anzuzeigen. Ein weiteres Ziel ist die Skalierbarkeit meiner Applikation, da ich immer wieder feststelle, dass viele Menschen Probleme mit der visuellen Grösse der Benutzeroberfläche haben. Leider unterstützen dies bis anhin fast keine Applikationen bzw. Betriebssysteme und ich möchte dies hier umsetzen Ziel der Arbeit Eine Open-Source-Applikation erstellen, welche im System-Tray von Linux (Gnome und K Desktop Environment (KDE)), Windows und MacOS X läuft. Sie soll beliebig mit Plugins erweitert werden können und diese bei globalen Änderungen wie z.b. Sprache und Look & Feel informieren. Diese Plugins sind unabhängige Threads und können Nachrichten an die Hauptanwendung schicken und von ihr Datenbank (DB)- und Datei-Container anfordern. Mit meiner Arbeit möchte ich folgende Ziele erreichen: Analyse und Konzepte zur Umsetzung einer System-Tray-Applikation mit Variantenvergleich. Studie zur benötigten Technologie und Tools zum Entwickeln einer Tray-Applikation mit Look & Feels, Internationalisierung und skalierbaren Schriften und Icons. Lauffähiger, öffentlicher Prototyp mit Application Programming Interface (API)-Dokumentation und Source-Code sowie zwei funktionierenden Plugins (eines zum Verschlüsseln von Dateien und einen Music-Player). 2

9 2.3. Abgrenzung Folgende Punkte werden abgegrenzt, da sie den Rahmen meiner Arbeit überschreiten würden: Die Analysen beschränken sich auf Recherchen im Internet und Büchern. Umfragen, Erhebungen sowie Feldstudien werden nicht durchgeführt. Als Programmiersprache wird Java eingesetzt Reglement, Ablauf und Bewertungskriterien Folgende Reglemente und Bewertungskriterien der Hochschule für Technik Zürich werden für die Semesterarbeit berücksichtigt: Reglement(DOS09c) Ablauf(DOS09a) Bewertungskriterien(DOS09b) 2.5. Sprache Die Semesterarbeit wird in Deutscher Sprache verfasst. Englische Ausdrücke werden immer dort verwendet, wo diese im Sprachgebrauch üblich sind. Aus Gründen der besseren Lesbarkeit der Semesterarbeit wird teilweise auf die Nennung beider Geschlechter verzichtet. In diesen Fällen ist die weibliche Form ausdrücklich inbegriffen. 3

10 3. Planung Zur Planung des Projektablaufs habe ich mir überlegt, was für Themenbereiche mein Projekt umfasst. Das Resultat sind die drei Hauptbereiche in Tabelle 3.1: Bereich Projekt Dokumentation Software Beschreibung Umfasst sämtliche Arbeiten die für einen geordneten Ablauf der Semesterarbeit seitens der Hochschule Zürich gefordert werden. Umfasst sämtliche Arbeiten die für die Dokumentation der Semesterarbeit geleistet werden müssen. Umfasst sämtliche Arbeiten die zur Erstellung eines lauffähigen Prototypen mit zwei Plugins geleistet werden müssen. Tabelle 3.1.: Definition der Planungsbereiche Anschliessend wurden alle Aufgaben in einer Tabelle eingesetzt und jeder Punkt geschätzt sowie die Meilensteine definiert. Am Schluss wurde der Projektplan mit allen Aufgaben pro Bereich erstellt Aufwandschätzung Aus meinen Erfahrungen habe ich inzwischen ein gutes Gefühl was die Projektkosten und -termine betrifft. Ich verwende meine eigene Abwandlung der Multiplikatormethode 1. Als Erstes wurde pro Bereich eine Tabelle mit allen Aufgaben in chronologischer Reihenfolge erstellt. Danach wurde jeder Punkt für sich betrachtet und dessen Aufwand geschätzt. Im zweiten Durchgang wurden die Termine abgestimmt. Dabei ist es wichtig, immer die Reihenfolge der Aufgaben einzuhalten und den Endtermin nicht aus den Augen zu verlieren. Beim dritten Durchgang rechnete ich noch eine Reserve von ca. 25% ein und setzte die Termine nochmals den neuen Werten entsprechend. Diese Technik ist relativ aufwändig, aber meiner Meinung nach ein guter Kompromiss zwischen der Analogiemethode und einer vollständigen Schätzung mit allen Anforderungen. 1 siehe Kapitel

11 Projekt Dieser Bereich beinhaltet alle Aufgaben und Meilensteine die für die Semesterarbeit erbracht werden müssen, auf diese jedoch keinen direkten Einfluss haben. Dazu zählen hauptsächlich Termine welche für einen geordneten Ablauf der Semesterarbeit seitens der Hochschule Zürich gefordert werden. Tabelle 3.2 zeigt die Aufwand- und Terminschätzung: Aufgabe Stunden Termin Beschreibung PRO Aufgabenstellung eingereicht PRO Kick-Off durchgeführt PRO Design-Review durchgeführt PRO Prototyp, API-Dokumentation und Source-Code öffentlich zugänglich gemacht PRO Abgabe der Semesterarbeit PRO Schlusspräsentation der Semesterarbeit Total Tabelle 3.2.: Aufwand- und Terminschätzung des Bereichs Projekt 5

12 Dokumentation Dieser Bereich beinhaltet alle Aufgaben und Meilensteine welche für die Dokumentation der Semesterarbeit erbracht werden müssen. Die Aufwand- und Terminschätzung ist in Tabelle 3.3 ersichtlich: Aufgabe Stunden Termin Beschreibung DOK Lastenheft erstellen DOK Marktsituation analysieren DOK Pflichtenheft erstellen DOK Analyse-Phase erfolgreich abgeschlossen DOK Architekturübersicht erstellen DOK Analyse Libraries abgeschlossen DOK Architektur erstellen DOK Analyse Tools DOK Entwurfsphase erfolgreich abgeschlossen DOK Realisierung DOK Realisierungsphase erfolgreich abgeschlossen DOK Testen DOK Test-Phase erfolgreich abgeschlossen DOK Dokumentation erstellen DOK Dokumentation erstellt DOK Projektmanagementübersicht erstellen DOK Projektmanagementübersicht erstellt DOK Zusammenfassung schreiben DOK Zusammenfassung geschrieben DOK Dokument redigieren DOK Dokument redigiert DOK Präsentation erstellen DOK Präsentation erstellt Total Tabelle 3.3.: Aufwand- und Terminschätzung des Bereichs Dokumentation 6

13 Software Dieser Bereich beinhaltet alle Aufgaben und Meilensteine welche für die Erstellung der Software für die Semesterarbeit geleistet werden müssen. Die geschätzten Aufwände und Termine zeigt die Tabelle 3.4: Aufgabe Stunden Termin Beschreibung SOF Prototyp mit zwei Plugins in der gewählten Technologie erstellen SOF Testfälle erstellen SOF Abnahme mit Testfällen durchführen SOF Code aufgeräumt und JavaDoc erstellen Total Tabelle 3.4.: Aufwand- und Terminschätzung des Bereichs Software Zusammenfassung Alle Bereiche zusammen ergeben den geschätzten Aufwand für die Semesterarbeit. Dieser ist in in Tabelle 3.5 zusammengefasst: Bereich Stunden Projekt Dokumentation Software Total Tabelle 3.5.: Geschätzter Aufwand für die Semesterarbeit 3.2. Projektplan Aus der Aufwandschätzung habe ich für jeden Bereich einen Projektplan erstellt. Mit diesem ist der Verlauf des Projekts einfach grafisch nachvollziehbar, da er über eine grobe Zeitstruktur verfügt, in welcher die Meilensteine und Aufgaben gut sichtbar sind. 7

14 Projekt In Abbildung 3.1 ist der Projektplan für den Bereich Projekt ersichtlich: Dokumentation Abbildung 3.1.: Planung des Bereichs Projekt Abbildung 3.2 zeigt den Projektplan für den Bereich Dokumentation: Abbildung 3.2.: Planung des Bereichs Dokumentation 8

15 Software Der Projektplan für den Bereich Software ist in Abbildung 3.3 ersichtlich: Abbildung 3.3.: Planung des Bereichs Software 9

16 4. Analyse 4.1. Anwendungsfälle Bevor ich mit dem Lastenheft anfangen möchte, finde ich es hilfreich, erstmals ein Anwendungsfalldiagramm aus den Zielen aus Kapitel 2.2 zu erstellen. In Abbildung 4.1 ist das Diagramm ersichtlich und in Tabelle 4.1 beschrieben: Abbildung 4.1.: Anwendungsfälle Nr Beschreibung 1 Der Benutzer kann die Sprache des Systems ändern. 2 Der Benutzer kann zwischen verschiedenen Look & Feels wählen. 3 Der Benutzer kann die Grösse der Schrift des Systems anpassen. 4 Der Benutzer kann die Grösse der Icons des Systems anpassen. 5 Der Benutzer kann Funktionen von Plugins ausführen. Tabelle 4.1.: Beschreibung der Anwendungsfälle 10

17 4.2. Lastenheft Das Lastenheft widerspiegelt im vorliegenden Fall der Semesterarbeit die Definition der Kapitel 2.1 und Zielbestimmungen Die Ziele sind im Kapitel 2.2 definiert Produkteinsatz Das System ist für jedermann verwendbar, der einen Rechner mit dem Betriebssystem Linux, Windows oder MacOS X besitzt. Es unterliegt keinen Beschränkungen für Modifikationen durch Dritte, da es unter Open-Source entwickelt wird. Des weiteren ist es relativ einfach möglich, eigene Plugins zu erstellen und so das System modular zu erweitern. Es wird Englisch als Verkehrssprache für den Source-Code und die API-Dokumentation eingesetzt Produktfunktionen Plattformunabhängig Gemäss StatCounter 1 ist die weltweite Verteilung der Betriebssysteme im Dezember 2010 wie in Tabelle 4.2 ersichtlich: Betriebssystem Marktanteil Windows XP 50.59% Windows % Windows Vista 15.49% MacOS X 6.25% Linux 0.76% Other 1.05% Tabelle 4.2.: Betriebssysteme und deren Marktanteile Somit kann man ganz klar erkennen, dass mit Windows beinahe 92% der Computerbenutzer erreichbar wären. Ich habe jedoch den Anspruch, mindestens 99% zu erreichen, da ich selbst einen Mac benutze und ebenfalls oft mit Unix-Systemen arbeiten muss. Die Applikation muss folglich unter den drei Hauptsystemen Linux, Windows und MacOS X funktionieren. /LF0110/ Der Benutzer hat Windows. /LF0120/ Der Benutzer hat MacOS X. /LF0130/ Der Benutzer hat Linux mit Gnome oder KDE

18 System-Tray Eines der Hauptziele des Systems ist, dem Benutzer möglichst einfach eine Vielzahl von Funktionen zur Verfügung zu stellen. Dies könnte über ein normales Programm geschehen, hat aber den Nachteil, dass es in einem Fenster laufen müsste und so unbeabsichtigt vom Benutzer geschlossen werden könnte. Persönlich tendiere ich dazu, meinen Desktop von unnötigen Fenstern zu befreien. Kaum habe ich jedoch aufgeräumt, vermisse ich das Programm wieder. Die definierten Betriebssysteme haben einen System-Tray, in welchem eine Applikation relativ unauffällig und jederzeit benutzt werden kann. Es bietet sich folglich an, das Programm dort zu platzieren. Abbildung 4.2 zeigt eine Übersicht der verschiedenen Systeme: 2 Abbildung 4.2.: System-Trays der definierten Betriebssysteme /LF0210/ Die Applikation läuft im System-Tray von Windows. /LF0220/ Die Applikation läuft im System-Tray von MacOS X. /LF0230/ Die Applikation läuft im System-Tray von Gnome (Linux). /LF0240/ Die Applikation läuft im System-Tray von KDE (Linux). Plugins Das Plugin-Konzept fand ich seit jeher eine geniale Idee, um die Funktionalität eines Programms beinahe beliebig zu erweitern. Deshalb möchte ich mit meinem System einen Rahmen bieten, welcher beliebig mit neuen Plugins erweitert werden kann. Es muss einem Entwickler einfach möglich sein, ein Plugin zu erstellen, welches dann im System erscheint. Dazu müssen gewisse Methoden zur bidirektionalen Kommunikation zur Verfügung stehen. Methoden aus Sicht des Systems an das Plugin: /LF0310/ Das Plugin muss über eine Konfiguration verfügen. /LF0320/ Das Plugin muss aktiviert und deaktiviert werden können. /LF0330/ Das Plugin muss über Sprachänderungen 3 informiert werden. 2 von links oben nach rechts unten: Windows, MacOS X, Gnome und KDE 3 das Plugin ist für seine unterstützten Sprachen selbst verantwortlich (mindestens Englisch sollte immer dabei sein) 12

19 /LF0340/ Das Plugin muss über Look & Feel-Änderungen informiert werden. /LF0350/ Das Plugin muss über Schriftgrössenänderungen informiert werden. /LF0360/ Das Plugin muss über Icongrössenänderungen 4 informiert werden. /LF0370/ Das Plugin muss über einen bevorstehenden Programmabbruch informiert werden. Methoden aus Sicht des Plugins an das System: /LF0410/ Das Plugin muss eine Mitteilung senden können, welche als Informationsbereich im System-Tray erscheint. /LF0420/ Das Plugin muss eine Aufgabe hinzufügen und entfernen können. Diese wird in einer zentralen Aufgabenübersicht des Systems übergeben und dient der Anzeige ihres Fortschritts. /LF0430/ Das Plugin kann sich korrekt skalierte Icons erzeugen lassen. Wählbare Look & Feels Aus meiner Erfahrung gefällt es vielen Benutzern, wenn sie das Look & Feel einer Applikation anpassen können. Es verleiht einen gewissen Spassfaktor und mehr Anpassung auf den persönlichen Geschmack. /LF0510/ Im System muss zwischen mindestens fünf verschiedenen Look & Feels gewählt werden können. /LF0520/ Die Plugins müssen das gewählte Look & Feel ohne Neustart übernehmen. /LF0530/ Das gewählte Look & Feel ist nach einem Neustart immer noch gesetzt. Wählbare Sprachen Die Sprache der Applikation muss wählbar sein. Das ist für mich eine Minimalanforderung an jedes Programm mit einer Benutzeroberfläche. Es ist nur ein minimaler Mehraufwand dies zu implementieren, der gewonnene Mehrwert kompensiert dies spielend. Dabei akzeptiere ich, dass das Layout des Programms nur mit Sprachen welche von links nach rechts geschrieben werden einwandfrei funktioniert. Das Plugin ist in meinem System für seine unterstützten Sprachen selbst verantwortlich. Im schlechtesten Fall, d.h. keine Sprache des Systems passt auf die mitgelieferten Sprachen des Plugins, wird dieses in der default-sprache des Plugin-Entwicklers angezeigt. /LF0610/ Im System muss mindestens zwischen Englisch und Deutsch gewählt werden können. /LF0620/ Die Plugins müssen die gewählte Sprache ohne Neustart übernehmen. /LF0630/ Die gewählte Sprache ist nach einem Neustart immer noch gesetzt. 4 das Plugin ist für seine Icons selbst verantwortlich 13

20 Skalierbare Schriften Seit viele meiner Freunde und Verwandten älter werden klagen sie oft über die Grösse der Benutzeroberfläche verschiedener Applikationen bzw. Betriebssysteme. Die führt teilweise zu obskuren Szenen, wie z.b. bei meinem Vater: er hat einen 27 Zoll imac mit wunderbaren 2560x1440 Pixeln, aber er sieht zu schlecht und betreibt ihn nur mit 1920x1200. Ein ähnliches Beispiel ist bei mir im Wohnzimmer. Da habe ich meinen MacMini an meinem 50 Zoll Fernseher angeschlossen und wenn ich FullHD-Auflösung einstelle ist die Schrift vom 2.5 Meter entfernten Sofa bereits arg klein. Deshalb möchte ich, dass mein System über skalierbare Schriften verfügt, welche gegenüber der Standardschrift des Betriebssystems angepasst werden können. /LF0710/ Im System muss mindestens zwischen sechs Schriftgrössen im Bereich von -4 Pixel bis +64 Pixel gegenüber der Standardschrift des Betriebssystems gewählt werden können. /LF0720/ Die Plugins müssen die gewählte Schriftgrösse ohne Neustart übernehmen. /LF0730/ Die gewählte Schriftgrösse ist nach einem Neustart immer noch gesetzt. Skalierbare Icons Die Gründe für skalierbare Icons sind dieselben wie für Skalierbare Schriften /LF0810/ Im System muss mindestens zwischen sechs Icongrössen im Bereich von 12 Pixel bis 128 Pixel gewählt werden können. Des weiteren muss auch keine Icons eine Option sein, da nicht jedermann Icons mag. /LF0820/ Die Plugins müssen die gewählte Icongrösse ohne Neustart übernehmen. /LF0830/ Die gewählte Icongrösse ist nach einem Neustart immer noch gesetzt. Plugins und Threads Die Plugins sind als unabhängige Threads zu implementieren, damit sie sich gegenseitig nicht beeinflussen. Somit kann jedes Plugin seine Aufgaben in Echtzeit 5 abwickeln. /LF0910/ Die Plugins müssen als unabhängige Threads entwickelt werden. Bidirektionale Kommunikation zwischen Plugins und Applikation Die Methoden für bidirektionale Kommunikation sind unter Plugins ersichtlich. Data-Container Damit nicht jedes Plugin seine eigenen Daten irgendwo auf dem Computer hinschreibt, kann es beim System einen Data-Container zum Speichern seiner spezifischen Daten anfordern. Somit können alle Plugin-Daten an einem zentralen Ort gespeichert werden. Dazu erstellt das System im Benutzerordner einen Ordner, z.b..tyr/data, in welchem die Dateien angelegt werden. Wenn 5 Diese Bezeichnung dient nur zur Veranschaulichung. In einem herkömmlichen Betriebssystem werden alle Aufgaben sequentiell abgearbeitet und erzeugen durch Multitasking(Wik10a) für den Benutzer das Gefühl der Echtzeit. 14

21 man das System deinstallieren möchte, muss man nur den Ordner.tyr löschen und alle Daten sind sauber entfernt. Dieser Container beinhaltet key-value-paare welche vorzugsweise als Extensible Markup Language (XML) beim Beenden des Programms gespeichert werden. /LF1010/ Das System stellt jedem Plugin einen Data-Container zur Verfügung. /LF1020/ Der Container beinhaltet key-value-paare. /LF1030/ Die Dateien sollten in einem Ordner als XML abgelegt werden. /LF1040/ Die Dateien werden beim Beenden des Programms geschrieben. DB-Container Falls ein Plugin eine SQL-DB benötigt, so kann dieser als DB-Container angefordert werden. Die Motivation ist ähnlich wie bei Data-Container Es soll ebenfalls im Benutzerordner ein Ordner, z.b..tyr/db, angelegt werden, in welchem für jedes Plugin eine DB-Datei abgelegt wird. Dieser Container verhält sich wie eine leere DB, d.h. es muss mittels SQL eine Datenbank sowie die dazugehörigen Tabellen anlegen und verwalten. Das System selbst macht keine SQL- Operationen, es ist nur für die Verbindung zwischen Plugin und DB-Container zuständig. /LF1110/ Das System stellt jedem Plugin einen DB-Container zur Verfügung. /LF1120/ Der Container ist leer und wird vom Plugin vollständig verwaltet. /LF1130/ Die Dateien sollten in einem Ordner als DB-Datei abgelegt werden. /LF1140/ Das System ist nur für die Verbindung zwischen Plugin und DB-Container zuständig. Plugin MusicPlayer Für meinen Geschmack sind die meisten Musikwiedergabe-Programme zu umfangreich und bieten Funktionen die ich gar nicht benötige, wie z.b. CDs brennen. Deshalb möchte ich einen einfachen Music-Player entwickeln. Er muss keine speziellen Funktionen bieten, nur Musik abspielen. /LF1210/ Der MusicPlayer kann einzelne Dateien oder ganze Verzeichnisse öffnen. /LF1220/ Der MusicPlayer verfügt über die Funktion Start zum starten des Abspielen der Dateien. /LF1230/ Der MusicPlayer verfügt über die Funktion Stop zum stoppen des Abspielen der Dateien. /LF1240/ Der MusicPlayer verfügt über die Funktion Zurück zum Abspielen der vorherigen Datei. /LF1250/ Der MusicPlayer verfügt über die Funktion Vor zum Abspielen der nächsten Datei. /LF1260/ Das zuletzt verwendete Verzeichnis oder Datei wird im Data-Container abgelegt. 15

22 Plugin Scrambler Ich komme immer wieder in die Situation, dass ich an einem Arbeitsort irgendein Tool benötige, welches ich jedoch wegen der Firewall oder dem Proxy vor Ort nicht herunterladen kann. 6 Selten hilft der Weg über ein verschlüsseltes Zip, denn viele Proxies wollen die Datei entpacken, was dann nicht geht und ich folglich die Datei nicht kriege. Eine einfache Umgehungslösung ist die Datei mit dem Advanced Encryption Standard (AES) zu verschlüsseln und sie dann so z.b. vom eigenen Web-Server herunterzuladen. Bis anhin habe ich das mittels einem Shell-Skript erledigt, fände es aber mittels einer kleinen Benutzeroberfläche bedeutend bequemer. /LF1310/ Der Scrambler kann einzelne Dateien verschlüsseln. /LF1320/ Der Scrambler kann einzelne Dateien entschlüsseln. /LF1330/ Es sind mindestens AES, Data Encryption Standard (DES) 7, Blowfish und Twofish zu implementieren. 8 /LF1340/ Die zuletzt verwendete Datei für die Verschlüsselung wird im Data-Container abgelegt. /LF1350/ Die zuletzt verwendete Datei für die Entschlüsselung wird im Data-Container abgelegt Produktdaten Es sollen mindestens folgende Daten persistent gespeichert werden: /LD100/ Tyr: Alle Daten die das System benötigt. Dazu gehören: Sprache Look & Feel Schriftgrösse Icongrösse /LD200/ Plugin: Alle Daten die das Plugin benötigt. Dazu gehören: Status aktiviert/deaktiviert /LD300/ MusicPlayer: Alle Daten die der MusicPlayer zusätzlich benötigt. Dazu gehören: zuletzt verwendetes Verzeichnis oder Datei /LD400/ Scrambler: Alle Daten die der Scrambler zusätzlich benötigt. Dazu gehören: zuletzt verwendete Datei zum Verschlüsseln zuletzt verwendete Datei zum Entschlüsseln 6 Es ist z.b. in den meisten Banken unmöglich, sobald es ein.exe oä. beinhaltet. 7 DES ist veraltet und nicht mehr sicher, trotzdem möchte ich ihn aus Kompatibilitätsgründen einbauen

23 Produktleistungen Folgende Leistungen sind für alle Funktionen des Systems umzusetzen: /LL100/ Open-Source: Die Applikation muss unter einer gängigen Open-Source-Lizenz stehen. /LL200/ Logging: Es muss ein Logging für das gesamte System eingebaut werden um allfällige Fehler besser nachzuvollziehen Qualitätsanforderungen Auf die Robustheit sowie auf die Korrektheit wird grössten Wert gelegt. Ebenso soll die Zuverlässigkeit, Benutzungsfreundlichkeit sowie die Portierbarkeit hoch sein. Effizienz und Kompatibilität sind nicht so wichtig Ergänzungen Realisierung Das vorliegende System soll mit Java und einer relationalen Datenbank realisiert werden. Es muss darauf geachtet werden, dass sämtliche Code-Änderungen nachvollziehbar sind. Ausblick auf die nächste Version Dieses System ist hier nur mit den Grundanforderungen geplant und wird bei Erfolg mit weiteren Zusätzen versehen. Folgende Anforderungen könnten in einer nächsten Version abgedeckt werden: Verwaltung der Plugins innerhalb der Applikation Installer für alle Betriebssysteme Updater für das System und die Plugins installierbare Schrift-Pakete installierbare Icon-Pakete installierbare Look & Feel-Pakete Hilfe-Funktion Fehler- und Benutzerstatistiken an 1-n Server via RESTful-Schnittstelle 4.3. Marktsituation Um zu verhindern, dass hier etwas realisiert wird, das es bereits gibt, habe ich mich entschlossen, vor dem Pflichtenheft ein Analyse der Marktsituation vorzunehmen. Dazu habe ich in Google, Bing und Yahoo 9 gesucht. Nach unzähligen Resultatseiten habe ich nur einen Mitbewerber mit einem ähnlichen Konzept gefunden. Nachfolgend werde ich darauf eingehen. 9 Suchbegriffe: system tray plugin 17

24 Software Die gefundene Software heisst TrayHelper 10 und bietet gemäss der Projekt-Homepage folgende Funktionen: Ereignis-Gedächtnisstützen Composer Prüfer PopUp-Fenster-Killer Plugins hinzufügen bzw. selber schreiben Die Software läuft nur unter Windows und die Programmierung erfolgt mit.net und einem eigenen SDK Entscheid Der Grundansatz zwischen TrayHelper und Tyr ist ähnlich, jedoch erfüllt TrayHelper fast keine der für meine Applikation geforderten Anforderungen: Nicht Open-Source sondern Shareware, d.h. Quellcode ist nicht frei. Läuft nur unter Windows und ist somit nicht Plattformunabhängig. Es hat keine wählbaren Look & Feels. Kann weder die Schrift- noch die Icongrössen ändern. Die Einzigen drei Punkte die zutreffen sind, dass es als System-Tray-Applikation läuft, die Sprachwahl unterstützt und das entwickeln von Plugins zulässt. Somit muss die Applikation selbst entwickelt werden Pflichtenheft Das Ziel des Pflichtenhefts ist aus dem Lastenheft 4.2 eine möglichst vollständige, konsistente und eindeutige Produktdefinition zu erstellen, die wiederum die Grundlage für das zu erstellende Produkt ist Zielbestimmungen Das System stellt eine System-Tray-Applikation dar, die mit Plugins erweitert werden kann. Nachfolgend sind alle Leistungen des Produktes aufgeführt. Musskriterien Funktionale Anforderungen: Die Tabellen 4.3, 4.4 und 4.5 zeigen die funktionalen Anforderungen an Tyr, MusicPlayer sowie Scrambler

25 Anforderungen LF510 - LF530 LF610 - LF630 LF710 - LF730 LF810 - LF830 Beschreibung Der Benutzer kann das Look & Feel wählen (mindestens fünf verschiedene Varianten). Der Benutzer kann die Sprache wählen (Deutsch und Englisch). Der Benutzer kann die Schriftgrösse wählen (mindestens sechs Stufen im Bereich -4 Pixel bis +64 Pixel gegenüber der Standardschrift des Betriebssystems). Der Benutzer kann die Icongrösse ändern (mindestens sechs Stufen im Bereich 12 Pixel bis 128 Pixel). Tabelle 4.3.: Funktionale Anforderungen an Tyr Anforderung LF1210 LF1220 LF1230 LF1240 LF1250 Beschreibung Der Benutzer kann einzelne Dateien oder ganze Verzeichnisse öffnen. Der Benutzer kann das Abspielen der Dateien starten. Der Benutzer kann das Abspielen der Dateien stoppen. Der Benutzer kann die vorherige Datei abspielen. Der Benutzer kann die nächste Datei abspielen. Tabelle 4.4.: Funktionale Anforderungen an MusicPlayer Anforderung LF1310 LF1320 LF1330 Beschreibung Der Benutzer kann einzelne Dateien verschlüsseln. Der Benutzer kann einzelne Dateien entschlüsseln. Der Benutzer kann zwischen verschiedenen Algorithmen wählen (AES, DES, Blowfish und Twofish). Tabelle 4.5.: Funktionale Anforderungen an Scrambler 19

26 Nicht-Funktionale Anforderungen: Die Tabellen 4.6, 4.7 und 4.8 zeigen die nicht-funktionalen Anforderungen an Tyr, MusicPlayer sowie Scrambler. Anforderungen LF LF0130 LF LF0240 LF LF0430 LF0910 LF LF1040 LF LF1140 LL100 LL200 Beschreibung Das System ist Plattformunabhängig (Windows, Linux und MacOS X). Das System läuft im System-Tray des jeweiligen Betriebssystems (Windows, Gnome, KDE und MacOS X). Erweiterbarkeit des Systems mit Plugins. Plugins sind eigene Threads. Plugins haben einen eigenen Data-Container. Plugins haben einen eigenen DB-Container. System ist Open-Source. Logging für das gesamte System. Tabelle 4.6.: Nicht-Funktionale Anforderungen an Tyr Anforderung LF1260 Beschreibung Das zuletzt verwendete Verzeichnis oder Datei wird im Data-Container abgelegt. Tabelle 4.7.: Nicht-Funktionale Anforderungen an MusicPlayer Anforderung LF1340 LF1350 Beschreibung Die zuletzt verwendete Datei für die Verschlüsselung wird im Data- Container abgelegt. Die zuletzt verwendete Datei für die Entschlüsselung wird im Data- Container abgelegt. Tabelle 4.8.: Nicht-Funktionale Anforderungen an Scrambler Wunschkriterien Tyr Erweiterbarkeit des Systems mit weiteren Sprachen. Informationen über die momentane Umgebung. 20

27 Mehr als fünf Look & Feels. Mehr als sechs Stufen für die Schriftgrösse. Mehr als sechs Stufen für die Icongrösse. MusicPlayer Zufällige Wiedergabe aller Titel. Eine Wiedergabeliste mit allen Dateien. Anzeige von Titelinformationen (z.b. Name, Laufzeit). Scrambler Mehr als vier Algorithmen implementieren. Abgrenzungskriterien Tyr Verwaltung der Plugins wird nicht eingebaut. Dies muss manuell geschehen. MusicPlayer Der MusicPlayer spielt in einer ersten Version nur MP3-Dateien, da ich selbst ausschliesslich dieses Format für meine Musikdateien verwende Produkteinsatz Anwendungsbereiche Da es sich um einen Rahmen für generische Plugins handelt, kann der Anwendungsbereich nicht eingeschränkt werden. Grundsätzlich ist alles möglich, was JavaSE 6 sowie alle Java-Bibliotheken an Funktionen bieten. Zielgruppen Mit den Zielgruppen verhält es sich genau gleich, es ist für alle Menschen mit Basiskenntnissen in Computernutzung anwendbar. Soweit keine mitgelieferte Sprachen mit der Sprache des Benutzers übereinstimmt, wird die Verkehrssprache Englisch verwendet. Betriebsbedingungen Die Betriebsbedingungen sind an diejenigen der verwendeten Hardware gekoppelt. Es ist jede Betriebsart möglich, auch 7x24 Stunden. Die Software selbst ist wartungsfrei

28 Produktumgebung Das Produkt ist weitgehend unabhängig vom Betriebssystem, sofern die nachfolgende Produktumgebung vorhanden ist. Software Der Benutzer muss auf seiner Maschine nur JavaSE 12 installiert haben. Bei dem Betriebssystem muss es sich um ein graphisches System handeln, welches auch einen System-Tray besitzt. Hardware Es gibt keine besonderen Ansprüche an die Hardware. Der Rechner sollte über mindestens folgende Peripherie verfügen: Bildschirm Zeigegerät (Maus, Touchpad) Tastatur Produktfunktionen Die Produktfunktionen sind analog den Produktfunktionen aus Kapitel Produktdaten Die Produktdaten sind analog den Produktdaten aus Kapitel Produktleistungen Es sind keine speziellen Produktleistungen definiert. 12 mindestens Version 6, siehe 22

29 Benutzeroberfläche Zur Gestaltung der Benutzeroberfläche habe ich die verschiedenen Layouts mit der Wireframe- Technik (siehe Kapitel 9.1.7) umgesetzt. Tyr Die Navigation gestaltet sich wie in Abbildung 4.3 dargestellt und in Tabelle 4.9 beschrieben: Abbildung 4.3.: Navigation in Tyr Nr Beschreibung 1 Dieser Menüpunkt wird generisch anhand der installierten Plugins erstellt und erlaubt das Ausführen deren Funktionen. 2 Der Menüpunkt Sprache öffnet ein Untermenü wie in Abbildung 4.5. Dies erlaubt das ändern der Sprache. 3 Look & Feel öffnet ein Untermenü wie in Abbildung 4.6. Dies erlaubt das ändern des Look & Feels. 4 Der Menüpunkt Schriftgrösse öffnet ein Untermenü wie in Abbildung 4.7. Dies erlaubt das ändern der Schriftgrösse. 5 Icongrösse öffnet ein Untermenü wie in Abbildung 4.8. Dies erlaubt das ändern der Icongrösse. 6 Der Menüpunkt Über öffnet ein Fenster wie in Abbildung 4.9. Dies zeigt Informationen über das Programm an. 7 Beenden schliesst die Applikation Tabelle 4.9.: Beschreibung der Navigation in Tyr 23

30 Die Abbildung 4.10 zeigt ein Fenster mit den Aufgaben von Plugins. Dieses wird automatisch angezeigt, wenn es Aufgaben abzuarbeiten hat. Abbildung 4.4.: Hauptmenü von Tyr Abbildung 4.5.: Menü zur Sprachwahl Abbildung 4.6.: Menü zur Wahl des Look & Feels 24

31 Abbildung 4.7.: Menü zur Wahl der Schriftgrösse Abbildung 4.8.: Menü zur Wahl der Icongrösse Abbildung 4.9.: Fenster mit Informationen über Tyr Abbildung 4.10.: Fenster mit den Aufgaben der Plugins 25

32 MusicPlayer Abbildung 4.12 zeigt das Hauptmenü des Plugins MusicPlayer. Innerhalb dessen gestaltet sich die Navigation wie in Abbildung 4.11 dargestellt und in Tabelle 4.10 beschrieben: Abbildung 4.11.: Navigation im MusicPlayer Nr Beschreibung 1 Öffnen... öffnet einen Java-Dateiauswahldialog. Dieser dient zum selektieren einzelner Dateien oder Verzeichnissen. 2 Der Menüpunkt Start startet die Musikwiedergabe. 3 Stop stoppt die Musikwiedergabe. 4 Der Menüpunkt Zurück spielt den vorherigen Titel ab. 5 Vor spielt den nächsten Titel ab. 6 Der Menüpunkt Über öffnet ein Fenster wie in Abbildung Dies zeigt Informationen über das Plugin an. Tabelle 4.10.: Beschreibung der Navigation im MusicPlayer Die Abbildung 4.14 zeigt ein Fenster welches die analogen Funktionen beinhaltet wie die Menüpunkte. Dieses Fenster ist permanent offen und liegt auf der obersten Ebene des Desktops, d.h. es kann auch über anderen Fenstern liegen. 26

33 Abbildung 4.12.: Hauptmenü des MusicPlayers Abbildung 4.13.: Fenster mit Informationen über den MusicPlayer Abbildung 4.14.: Fenster mit den Bedienelementen für den MusicPlayer 27

34 Scrambler Abbildung 4.16 zeigt das Hauptmenü des Plugins Scrambler. Innerhalb dessen gestaltet sich die Navigation wie in Abbildung 4.15 dargestellt und in Tabelle 4.11 beschrieben: Abbildung 4.15.: Navigation im Scrambler Nr Beschreibung 1 Verschlüsseln... öffnet ein Fenster wie in Abbildung Dies dient zum Verschlüsseln einer Datei mit allen notwendigen Parametern. 2 Der Menüpunkt Entschlüsseln... öffnet ein Fenster wie in Abbildung Dies dient zum Entschlüsseln einer Datei mit allen notwendigen Parametern. 3 Über öffnet ein Fenster wie in Abbildung Dies zeigt Informationen über das Plugin an. Tabelle 4.11.: Beschreibung der Navigation im Scrambler 28

35 Abbildung 4.16.: Hauptmenü des Scramblers Abbildung 4.17.: Fenster mit Informationen über den Scrambler Abbildung 4.18.: Fenster zum Verschlüsseln einer Datei Abbildung 4.19.: Fenster zum Entschlüsseln einer Datei 29

36 Qualitätszielbestimmungen Zur Definition der Qualitätszielbestimmungen habe ich Tabelle 4.12 erstellt: Bezeichnung Robustheit Korrektheit Zuverlässigkeit Benutzungsfreundlichkeit Effizienz Portierbarkeit Kompatibilität Erweiterbarkeit Beschreibung Die Fähigkeit eines Softwareprodukts, auch unter aussergewöhnlichen Bedingungen zu funktionieren. Die Software muss fehlerhaftes Verhalten seiner Umwelt erkennen, z.b. durch Plausibilitätsprüfungen, und in einer definierten Weise zu behandeln, so dass keine unvorhersehbaren Programmreaktionen entstehen. Die Fähigkeit eines Softwareprodukts, ihre Aufgaben exakt zu erfüllen, wie sie durch Anforderungen und Spezifikationen definiert sind. Merkmal der Softwarequalität eines Softwareprodukts. Dieses wird als zuverlässig betrachtet, wenn die Wahrscheinlichkeit für das Auftreten eines Fehlers gering ist, z.b. die Wahrscheinlichkeit für fehlerfreies Funktionieren innerhalb einer gewissen Zeitspanne oder in einer gewissen Zahl von Anwendungsfällen. Ein Grad für die vom Nutzer erlebte Nutzungsqualität bei der Interaktion mit einem System. Eine besonders einfache, zum Nutzer und seinen Aufgaben passende Bedienung wird dabei als benutzerfreundlich angesehen. Beschreibt die Leistung der Verarbeitungsgeschwindigkeit im Vergleich zum maximal möglichen. Dies wird oft als Performance-Indikator angesehen. Bestimmt den Grad der Plattformunabhängigkeit eines Softwareprodukts. Damit kann bestimmt werden, wieviel Aufwand es benötigt, es auf anderes System zu portieren. Definiert den Grad an Möglichkeiten, dass ein Softwareprodukt verschiedene Hardwarekomponenten (z.b. Geräte verschiedener Hersteller) benutzen und mit verschiedenen Softwareprodukte interagieren können muss. Bezeichnet die Leichtigkeit, mit der ein Softwareprodukt an neue Spezifikationen angepasst werden kann. Tabelle 4.12.: Erläuterung der Qualitätsziele 30

37 Aus dem Lastenheft ergeben sich die Tabelle 4.13 mit den definierten Qualitätszielbestimmungen: Robustheit Korrektheit Zuverlässigkeit Benutzungsfreundlichkeit Effizienz Portierbarkeit Kompatibilität Erweiterbarkeit sehr wichtig wichtig weniger wichtig unwichtig x x x x x x x x Tabelle 4.13.: Definierte Qualitätszielbestimmungen Globale Testszenarien und Testfälle Jede Produktfunktion aus Kapitel wird anhand von konkreten Testfällen getestet. Plattformunabhängigkeit /T0110/ Das System läuft unter Windows. /T0120/ Das System läuft unter MacOS X. /T0130/ Das System läuft unter Linux mit Gnome oder KDE. System-Tray /T0210/ Die Applikation läuft im System-Tray von Windows. /T0220/ Die Applikation läuft im System-Tray von MacOS X. /T0230/ Die Applikation läuft im System-Tray von Gnome (Linux). /T0240/ Die Applikation läuft im System-Tray von KDE (Linux). Plugins Methoden aus Sicht des Systems an das Plugin: /T0310/ Das Plugin verfügt über eine eine Konfiguration. /T0320/ Das Plugin kann aktiviert und deaktiviert werden. /T0330/ Das Plugin wird über Sprachänderungen informiert. /T0340/ Das Plugin wird über Look & Feel-Änderungen informiert. /T0350/ Das Plugin wird über Schriftgrössenänderungen informiert. /T0360/ Das Plugin wird über Icongrössenänderungen informiert. 31

38 /T0370/ Das Plugin wird über einen bevorstehenden Programmabbruch informiert. Methoden aus Sicht des Plugins an das System: /T0410/ Das Plugin kann eine Mitteilung senden, welche als Informationsbereich im System- Tray erscheint. /T0420/ Das Plugin kann eine Aufgabe hinzufügen und entfernen. Diese wird einer zentralen Aufgabenübersicht des Systems übergeben und zeigt ihren Fortschritt an. /T0430/ Das Plugin kann sich korrekt skalierte Icons erzeugen lassen. Wählbare Look & Feels /T0510/ Im System kann zwischen mindestens fünf verschiedenen Look & Feels gewählt werden. /T0520/ Die Plugins übernehmen das gewählte Look & Feel ohne Neustart. /T0530/ Das gewählte Look & Feel ist nach einem Neustart immer noch gesetzt. Wählbare Sprachen /T0610/ Im System kann mindestens zwischen Englisch und Deutsch gewählt werden. /T0620/ Die Plugins übernehmen die gewählte Sprache ohne Neustart. /T0630/ Die gewählte Sprache ist nach einem Neustart immer noch gesetzt. Skalierbare Schriften /T0710/ Im System kann mindestens zwischen sechs Schriftgrössen im Bereich von -4 Pixel bis +64 Pixel gegenüber der Standardschrift des Betriebssystems gewählt werden. /T0720/ Die Plugins übernehmen die gewählte Schriftgrösse ohne Neustart. /T0730/ Die gewählte Schriftgrösse ist nach einem Neustart immer noch gesetzt. Skalierbare Icons /T0810/ Im System kann mindestens zwischen sechs Icongrössen im Bereich von 12 Pixel bis 128 Pixel gewählt werden. Zusätzlich kann auch die Option keine Icons gewählt werden. /T0820/ Die Plugins übernehmen die gewählte Icongrösse ohne Neustart. /T0830/ Die gewählte Icongrösse ist nach einem Neustart immer noch gesetzt. Plugins und Threads /T0910/ Die Plugins sind als unabhängige Threads entwickelt. Bidirektionale Kommunikation zwischen Plugins und Applikation Die Tests für bidirektionale Kommunikation sind unter Plugins abgehandelt. 32

39 Data-Container /T1010/ Das System stellt jedem Plugin einen Data-Container zur Verfügung. /T1020/ Der Container beinhaltet key-value-paare. /T1030/ Die Dateien werden in einem Ordner als XML abgelegt. /T1040/ Die Dateien werden beim Beenden des Programms geschrieben. DB-Container /T1110/ Das System stellt jedem Plugin einen DB-Container zur Verfügung. /T1120/ Der Container ist leer und wird vom Plugin vollständig verwaltet. /T1130/ Die Dateien werden in einem Ordner als DB-Datei abgelegt. /T1140/ Das System ist nur für die Verbindung zwischen Plugin und DB-Container zuständig. Plugin MusicPlayer /T1210/ Der MusicPlayer kann einzelne Dateien oder ganze Verzeichnisse öffnen. /T1220/ Der MusicPlayer verfügt über die Funktion Start zum starten des Abspielen der Dateien. /T1230/ Der MusicPlayer verfügt über die Funktion Stop zum stoppen des Abspielen der Dateien. /T1240/ Der MusicPlayer verfügt über die Funktion Zurück zum Abspielen der vorherigen Datei. /T1250/ Der MusicPlayer verfügt über die Funktion Vor zum Abspielen der nächsten Datei. /T1260/ Das zuletzt verwendete Verzeichnis oder Datei wird im Data-Container abgelegt. Plugin Scrambler /T1310/ Der Scrambler kann einzelne Dateien verschlüsseln. /T1320/ Der Scrambler kann einzelne Dateien entschlüsseln. /T1330/ Es sind mindestens AES, DES, Blowfish und Twofish implementiert. /T1340/ Das letzte verwendete Verschlüsselungsverzeichnis wird im Data-Container abgelegt. /T1350/ Das letzte verwendete Entschlüsselungsverzeichnis wird im Data-Container abgelegt Entwicklungsumgebung Es wird darauf geachtet, dass möglichst viele Entwicklungstools kostenlos 13 und Open-Source sind. Die übrigen Entwicklungstools sind lizenzierte Versionen oder Testversionen von Namenhaften Softwareherstellern. Die Entwicklung findet auf einem MacOS X-System statt, kann aber auch auf jedem Standard- PC fortgeführt werden. 13 Freeware 33

40 Software Betriebssytem MacOS X Virtualisiert: Kubuntu TLS Ubuntu TLS Windows XP Windows 7 Programmiersprache JavaSE 6 IDE Eclipse Helios Virtualisierung VirtualBox Texteditor TextMate Konzeptionelle Visualisierung ArgoUML Balsamiq Mockups Microsoft Visio2010 Office LATEX Microsoft Project2010 OpenOffice Grafik GIMP InkScape 0.47 Versionierung Dropbox SVN Build Maven Testen VisualVM 34

41 Hardware Standard-PC der die Anforderungen an die in Punkt genannten Software erfüllt Ergänzungen Ergänzungen werden im Verlauf der Entwicklung mit in das Pflichtenheft aufgenommen. Durch die Versionierung dieses Dokuments sind Änderungen jederzeit nachvollziehbar Glossar Ein Glossar ist für dieses Pflichtenheft nicht nötig. 35

42 5. Entwurf Anmerkung: Nach Abschluss der Analysephase wurde entschieden, dass die Bezeichnung Plugin gleichbedeutend mit Modul ist. Da mir persönlich Modul besser gefällt, werde ich ab jetzt nur noch die Bezeichnung Modul anstelle von Plugin verwenden Architekturübersicht Die Architekturübersicht, hergeleitet aus den Produktfunktionen aus Kapitel 4.2.3, ist in der folgenden Abbildung 5.1 und der Tabelle 5.1 ersichtlich. Abbildung 5.1.: Architekturübersicht 36

43 Nr Beschreibung 1 Dies ist die Hauptapplikation des Systems und erfüllt die Anforderungen /LF0110/ bis /LF0240/. 2 Die Konfigurationsdatei des Systems. Hier sind die Parameter für die Applikation abgelegt, wie z.b. für das Logging (/LL200/ ). 3 Die Icons des Systems, welche zum Skalieren der Benutzeroberfläche verwendet werden. Dieser Punkt wird zum Erfüllen der Anforderungen /LF0810/ bis /LF0830/ benötigt. 4 Die verschiedenen Sprachen des Systems. Dieser Punkt wird zum Erfüllen der Anforderungen /LF0610/ bis /LF0630/ benötigt. 5 Die verschiedenen Look & Feels des Systems. Dieser Punkt wird zum Erfüllen der Anforderungen /LF0510/ bis /LF0530/ benötigt. 6 Die DB-Container für die Module. Dieser Punkt wird zum Erfüllen der Anforderungen /LF1110/ bis /LF1140/ benötigt. 7 Die Data-Container für die Module. Dieser Punkt wird zum Erfüllen der Anforderungen /LF1010/ bis /LF1040/ benötigt. 8 Dies sind die Module des Systems, wie der MusicPlayer und Scrambler. Damit werden die Anforderungen /LF0910/ sowie /LF1210/ bis /LF1350/ erfüllt. 9 Die Icons des Moduls, welche zum Skalieren seiner Benutzeroberfläche verwendet werden. Dieser Punkt wird zum Erfüllen der Anforderungen /LF0810/ bis /LF0830/ benötigt. 10 Die verschiedenen Sprachen des Moduls. Dieser Punkt wird zum Erfüllen der Anforderungen /LF0610/ bis /LF0630/ benötigt. 11 Die Konfigurationsdatei des Moduls. Hier sind die Parameter für das System abgelegt, z.b. welche Klasse zum Starten des Moduls benötigt wird. Dieser Punkt wird zum Erfüllen der Anforderung /LF0310/ benötigt. 12 Dies ist die Log-Datei des Systems und erfüllt die Leistungsanforderung /LL200/ Tabelle 5.1.: Beschreibung der Architekturübersicht 37

44 Die Schnittstelle zwischen Punkt 1 und 8 erfüllen auch die Anforderungen /LF0310/ bis /LF0430/. Die Anforderungen /LF0710/ bis /LF0730/ sind in der Grafik nicht ersichtlich, da sie innerhalb des Systems abgehandelt werden Hilfsmittel Da ich seit dem Jahr 2000 fast ausschliesslich in Java programmiere, kenne ich mich in dieser Programmiersprache sehr gut aus. Deshalb habe ich für die folgenden Anforderungen die Hilfsmittel bzw. Libraries ausgewählt, welche ich als die beste Wahl empfinde. Ich begründe meine Entscheidung jeweils kurz Generell eingesetzte Hilfsmittel Bogatyr Wenn man viele Jahre in Java programmiert, ergeben sich mit der Zeit immer wieder ähnliche Problemstellungen, wie z.b. das Einlesen einer Datei. Dies führte bei mir zu einer grossen Sammlung an Codefragmenten, welche ich dann je nach Situation einsetzen konnte. Da kam mir die Idee, eine eigene Library mit meinen oft verwendeten Funktionen zu schreiben. So eröffnete ich im Jahr 2007 ein GoogleCode-Repository und veröffentlichte im selben Jahr die erste Version von Bogatyr 1 unter der Open-Source-Lizenz GNU General Public License (GPL) Version 2. Die Library hat inzwischen einen beachtlichen Funktionsumfang, hier ein Auszug der wichtigsten Funktionen: Erweiterter Property-Mechanismus mit generischer Anbindung. Erweiterter ResourceBundle-Mechanismus mit generischer Anbindung. Applikationsskeleton als Grundlage für jedes Java-Programm. Es ist neben einem Standard- Programmrahmen auch jener für einen synchronen bzw. asynchronen Client/Server vorhanden. Unterstützung zur Umsetzung des Model View Controller (MVC)-Patterns. Modellskeleton als Grundlage für alle Modelle. Es sind viele Grundklassen, wie z.b. das Modell für Applikationsdaten, bereits vorhanden. Viewskeleton als Grundlage für alle Views. Controllerskeleton als Grundlage für alle Controller. Unterstützung bei symmetrischer und asymmetrischer Verschlüsselung. HashCode-Generator für alle gängigen Verfahren sowie eine spezielle Variante für grosse Dateien. Hilfsklassen für I/O, Netzwerk, Grafik, XML, Log etc. Profiler zum Messen des Zeitverbrauchs von Befehlen oder Funktionen in einem Programm

45 Alle Swing-Klassen wurden mit zusätzlichen Funktionen erweitert. Komprimieren von Dateien und Datenströmen. Verschiedenste Umrechnungs- und Mathematikfunktionen. Ausführen von beliebigen Applikationen. Update-Mechanismus für Dateien, z.b. um eine Applikation auf die neuste Version zu bringen. Die Library möchte ich einsetzten, da ich sie mit grösster Sorgfalt pflege und sie meistens als Grundlage all meiner Programme anwenden. Immer wenn ich während dem Programmieren an eine Stelle komme, wo ich etwas Kompliziertes machen muss, überlege ich mir, ob dieser Code an einem anderen Ort wiederverwendbar wäre. Ist dies der Fall, so integriere ich das Codefragment in meine Library und schreibe JUnit-Tests dafür. Somit wächst Bogatyr stetig und wird immer mit neuen, guten Funktionen erweitert. Bei jeder neuen Major-Version von Java wird der Code mit den neuen Funktionen erweitert oder fällt ganz raus. Durch meine durchgängigen Tests behaupte ich eine sehr gute Qualität meiner Library erreicht zu haben und möchte sie auch mit Erkenntnissen aus dieser Arbeit anreichern. Für diese Arbeit werde ich Bogatyr in der Version 0.95 verwenden. SwingLabs SwingLabs 2 ist ein Open-Source-Testprojekt von Oracle und dient dem evaluieren zukünftiger Swing-Technologien. Es beinhaltet unter anderem: Sortieren, filtern und highlightning für Tabellen, Trees und Listen Suchen-Mechanismus in allen Swing-Komponenten Automatische Ergänzung für Felder Login und Authorisierungsframework Einklappbare Panel-Komponentente Datumswahl-Komponente Verschiedene Standard- und Fehler-Dialoge Animationsframework für Swing Da Standard-Swing in Java viele Komponenten einer modernen Applikation fehlen, führt beinahe kein Weg an den SwingLabs-Erweiterungen vorbei. Ich verwende diese Library für alle meine Swing-Projekte, da sie sehr hilfreich und zuverlässig ist. Ich werde SwingLabs in der Version verwenden

46 SLF4J SLF4J 3 ist eine Fassade(Wik11a) für die bekannten Logging-Mechanismen Log4J 4, Java Logging 5 und Commons logging 6. Dies ermöglicht mir, alle Logeinträge von allen Libraries und Modulen unabhängig von der konkreten Implementierung an einen Ort zu loggen. Logback 7 ist ein Logging-Framework vom Autor von SLF4J und bietet in etwa denselben Funktionsumfang wie Log4J. Es ist jedoch moderner und besser gepflegt als Log4J 8. Java Logging und Commons logging bieten zu wenig Konfigurationsmöglichkeiten und die Log-Levels sind mir nicht granular genug, deshalb verwende ich diese Libraries nicht. Meine Wahl fällt also auf die Kombination von SLF4J und Logback. SLF4J mit Logback erfüllt die Anforderung /LL0200/ Plattformunabhängig Java ist als Programmiersprache speziell für Plattformunabhängigkeit konzipiert. Es gibt für beinahe jedes Betriebssystem eine Version von Oracle 9 sowie einen Open-Source-Version namens OpenJDK 10 welche von einer unabhängigen Gemeinschaft weiterentwickelt wird. Somit sind die Anforderungen /LF0110/ bis /LF0130/ mit der Wahl von JavaSE 6 als Programmiersprache erfüllt System-Tray Java bietet ab der Version 6 eine Klasse namens TrayIcon 11, welche die Funktionalität eines System-Trays in allen geforderten Betriebssystemen abdeckt. Dies erfüllt die Anforderungen /LF0210/ bis /LF0240/ Module Die Anforderungen an die Module kann durch keine Library abgedeckt werden und ist somit Teil der Eigenentwicklung Wählbare Sprachen Ein Lokalisierungsmechanismus ist in Java seit jeher via der Klasse ResourceBundle 12 enthalten. Ich verwende hierzu jedoch meine Bogatyr-Library, welche den Mechanismus erweitert und vereinfacht. Damit erfülle ich die Anforderungen /LF0610/ bis /LF0630/ ist schon seit Jahren auf Version 1.2 und die lang erwartete Version 2.0 ist noch immer experimentell

47 Skalierbare Schriften In allen Swing-Komponenten von Java sind die Schriftarten und -grössen beliebig änderbar. Es müssen also einfach alle Komponenten der Benutzeroberfläche des Systems mit der gewählten Schriftgrösse neu gezeichnet werden. Hiermit erfülle ich die Anforderungen /LF0710/ bis /LF0730/ Module und Threads Threading ist in Java sehr einfach möglich. Je nach Aufgabe ist die Klasse Thread 13 bzw. das Interface Runnable 14 oder aber SwingWorker 15 zu verwenden. Die Modulentwickler müssen selbst entscheiden, welche Aufgaben sie in einen Thread auslagern möchten. Da Threads möglich sind, ist auch die Anforderung /LF0910/ erfüllt Data-Container Der Data-Container ist grundsätzlich eine Java-Klasse mit einer Liste von key-value-paaren, welche als XML serialisiert werden muss. Dazu bietet Java seit der Version 5 ein eigenes Framework namens JAXB 16, welches sich inzwischen als Standard etabliert hat. Im Gegensatz zu SAX 17 gestaltet sich die Anwendung äusserst einfach, da alles über Annotationen geschieht, während bei SAX ein eigener, wenn auch vereinfachter, Parser geschrieben werden muss. Andere Libraries wie XercesJ 18 und JDOM 19 sind ebenfalls viel komplizierter und bringen insgesamt für das System keinen Vorteil gegenüber dem in Java vorhanden JAXB. Mit JAXB werden die Anforderungen /LF1010/ bis /LF1040/ erfüllt Modul MusicPlayer Java bietet einfache Methoden zum Abspielen von WAV -, SND- und MID-Dateien, jedoch keine für MP3 -Dateien. Um dieses Problem zu lösen gibt es zwei bekannte Libraries, nämlich JMF 20 und JLayer 21. JMF hat zwei gravierende Nachteile - erstens wurde es seit 2004 nicht mehr weiterentwickelt und zweitens benötigt es eine Installation von FFmpeg 22. Dies benötigt zum einen eine zusätzliche Installationsroutine und zum anderen ist es mit rund 7 MB 23 sehr gross. Des weiteren war es mir nicht möglich, die Version 2.1.1e auf meinem Mac lauffähig zu kriegen, denn es gibt keine offizielle Version für den Mac. JLayer hingegen ist vollständig in Java geschrieben und ist nur etwas mehr als 100 KB gross. Ich habe diese Library schon früher verwendet und sie funktioniert tadellos. Mit Hilfe von JLayer in der Version werden die Anforderungen /LF1210/ bis /LF1260/ erfüllt inkl. FFmpeg 41

48 Modul Scrambler Java bietet auch in der SE-Version ein ganzes Kryptografie-Paket 24, jedoch sind darin keine Provider enthalten. Dies bedeutet, dass keine Algorithmen vorhanden sind, denn diese gibt es nur in der EE-Version, welches ich aber nicht verwenden möchte. Zum Glück gibt es auch da eine Open-Source-Providersammlung namens Bouncy Castle 25. Sie beinhaltet beinahe alle weltweit verfügbaren Kryptografie-Algorithmen und unterliegt im Gegensatz zur EE-Version keinerlei Exportbeschränkungen. Auch diese Library verwende ich seit vielen Jahren in hochsensiblen Umfeldern und ich habe noch keine negativen Erfahrungen damit gemacht. Mit Hilfe von Bouncy Castle in der Version 1.45 werden die Anforderungen /LF1310/ bis /LF1350/ erfüllt Evaluation der Libraries Hier folgen die Analysen und getroffenen Entscheidungen der zu verwendenden Libraries im Tyr Wählbare Look & Feels Java liefert in der Standardinstallation vier Look & Feels wie in Abbildung 5.2 ersichtlich: 26 Abbildung 5.2.: Java Look & Feels von links oben nach rechts unten: Metal, Nimbus, CDE und System 42

49 Da die Anforderung besteht, mindestens fünf Look & Feels zu implementieren, müssen zusätzliche Varianten eingebaut werden. Dazu habe ich einige bekannte Open-Source Look & Feels Libraries aufgeschrieben und angeschaut:(pho08) EaSynth 27 JGoodies Looks 28 LiquidLNF 29 NimROD 30 SkinLF 31 Substance 32 Entscheidung Ausser Substance bieten alle oben genannten Libraries lediglich ein zusätzliches Look & Feel. Da ich nicht pro Look & Feel eine Library hinzufügen möchte, fällt meine Wahl auf Substance. Dieses bietet bereits über 20 eingebaute Look & Feels und funktionierte in der Evaluationsphase einwandfrei. Das Look & Feel Substance in der Version 6.1 erfüllt die Anforderungen /LF0510/ bis /LF0530/ Skalierbare Icons In den meisten Open-Source Icon-Paketen sind die Icons als Bitmap- und als Vektorgrafik vorhanden. Generell würde es sich anbieten, die Vektorgrafiken zu verwenden. Während meinen Nachforschungen habe ich jedoch nur eine Java-Library gefunden, die Scalable Vector Graphics (SVG) lesen kann. Diese Library heisst Batik 33 und ich habe sie auch schon eingesetzt um JFreeChart 34 Charts in JasperReports 35 zu exportieren. Das Problem dieser Library ist zum einen die Grösse von 8.5 MB und zum anderen ist sie ziemlich langsam. Deshalb werde ich die Icons als Bitmap verwenden und selbst skalieren. Um gute Ergebnisse zu erzielen, müssen die Icons in zwei verschiedenen Grössen vorhanden sein, nämlich 32x32 und 128x128 Pixel. Folgende Icon-Pakete habe ich angeschaut: Tango Desktop Project Das Tango Desktop Project 36 hat das Ziel, Benutzern eine einheitlichere Benutzeroberfläche zu ermöglichen. Es stellt Entwicklern ein einheitliches Icon-Paket zur Verfügung, denn die unterschiedliche Gestaltung der grafischen Benutzeroberflächen von Windows, MacOS X, KDE und

50 Gnome machen es es Entwicklern schwer, Programme optisch zu integrieren. Programme, die Icons benutzen, die dem Tango-Stil folgen, passen sich in den verschiedenen Oberflächen gut an. Dieses Paket ist sehr weit verbreitet und wird in vielen Open-Source-Programmen verwendet. Es ist Public Domain und bietet Icons in allen benötigten Grössen als Bitmap sowie auch als SVG. Abbildung 5.3 zeigt eine Übersicht der Icons: Abbildung 5.3.: Icons des Tango Desktop Project Crystal Clear Crystal Clear 37 ist ein Icon-Paket vom brasilianischen Designer Everaldo Coelho und hat einen grossen Einfluss auf die Benutzeroberfläche KDE. Es ist unter der GNU Lesser General Public License (LGPL) und bietet Icons in allen benötigten Grössen als Bitmap sowie auch als SVG. Eine Übersicht der Icons folgt in Abbildung 5.4: Abbildung 5.4.: Icons vom Crytal Clear-Paket Nuvola Nuvola 38 ist ein Icon-Paket vom italienischen Designer David Vignoni und ist sehr beliebt bei Programmen für die Benutzeroberfläche KDE und Gnome. Es ist ebenfalls LGPL und bietet Icons in allen benötigten Grössen als Bitmap sowie auch als SVG. In Abbildung 5.5 ist eine Auswahl der Icons zu sehen: Abbildung 5.5.: Icons vom Nuvola-Paket

51 Entscheidung Alle drei Pakete bieten hochwertige Icons für mein System. Da alle Open-Source sind, werde ich jeweils pro Anwendungsfall das meiner Meinung nach schönste Icon auswählen und verwenden. Es sind also alle Icon-Pakete zugelassen. Die Icon-Pakete Tango, Crystal Clear und Nuvola erfüllen die Anforderungen /LF0810/ bis /LF0830/ DB-Container Der DB-Container ist eine Klasse, welche eine Structured Query Language (SQL)-Verbindung zwischen dem Modul und der ihr unbekannten DB-Datei herstellt. Die SQL-Datenbank muss eine einfache Datei zum persistieren verwenden und es sollte keine DB-Installation auf der ausführenden Maschine nötig sein, da der Benutzer keine zusätzliche Software installieren müssen sollte. Um zu einer Entscheidung zu kommen, welche DB einzusetzen ist, habe ich mir als Erstes die bekannten Open-Source-Datenbanken aufgeschrieben(wik11c): CouchDB 39 db4o 40 Derby 41 H2 42 HSQLDB 43 MySQL 44 PostgreSQL 45 SQLite 46 Die beiden Datenbanken db4o und CouchDB sind keine relationalen Datenbanken und sind somit nicht einsetzbar

52 Vergleich der Datenbanksysteme Derby H2 HSQLDB MySQL PostgreSQL SQLite Version Sprache Java Java Java C, C++ C C Lizenz Apache Dual BSD Dual BSD gemeinfrei Licencse (Eclipse (Kommer- 2.0 oder ziell und Mozilla) GPL) Embedded (Java) ja ja ja nein nein nein In-Memory Mode ja ja ja nein nein ja Sicherheitsrollen ja ja ja ja ja ja Transaktionen ja ja ja je nach ja nein DB Volltextsuche nein ja ja ja ja ja Sequenzen nein ja ja nein ja nein Limit und Offset nein ja ja ja ja nein Information Schema nein ja ja ja ja nein Dateien pro DB viele wenige wenige viele viele wenige Verschlüsselte DB ja ja ja nein nein nein Grösse 3 MB 1 MB 1 MB 4 MB 6 MB 1 MB Tabelle 5.2.: Vergleich der Datenbanken Entscheidung In der Tabelle 5.2 ist ersichtlich, dass MySQL, PostgreSQL und SQLite keine Embedded- Unterstützung für Java anbieten und somit auf dem Rechner des Benutzers installiert werden müssten. Somit schliesse ich diese Datenbanken aus den weiteren Betrachtungen aus. Übrig bleiben die reinen Java-Datenbanken Derby, H2 und HSQLDB. Derby hat keine Volltextsuche, kein Limit und Offset, erstellt viele Dateien und ist mit 3 MB die Grösste Library. Der letzte Punkt ist auch der Hauptgrund, weshalb ich mich gegen Derby entscheide. Ich möchte die Grösse von Tyr nicht unnötig mit Libraries aufblähen. Bleiben also noch H2 und HSQLDB. Hier ist die Entscheidung sehr schwer. H2 ist ein Fork von HSQLDB und dieses ist folglich bereits länger verfügbar und ausgereifter. Dies bestätigt auch das Suchergebnis von Google - zu HSQLDB findet man Seiten, während es bei H2 nur knapp sind. Des weiteren habe ich persönlich mehr Erfahrung mit HSQLDB, weshalb ich mich dafür enscheide. Die Datenbank HSQLDB in der Version 2.0 erfüllt die Anforderungen /LF1110/ bis /LF1140/

53 5.4. Architektur Nach Abschluss der Evaluation der Libraries ergibt sich die in Abbildung 5.6 dargestellte und in Tabelle 5.3 erklärte Architektur: Abbildung 5.6.: Architektur 47

54 Nr Beschreibung 1 Tyr ist Hauptklasse des Systems. Sie wird als Erstes gestartet und initialisiert alle benötigten Klassen. 2 ModelApplication beinhaltet die Applikationsinformationen wie Name und Version. Des weiteren befinden sich dort die Properties (standard.properties) und der Localizer für die Mehrsprachigkeit. Benötigt für die Anforderungen /LF0610/ bis /LF0630/. 3 ControllerTyr steuert den gesamten Ablauf des Systems, liest und speichert dessen Konfiguration. Weiter verwaltet er den Zugriff auf die Icons und repräsentiert den Callback für das Modul. Benötigt für die Anforderungen /LF0310/ bis /LF0830/. 4 ControllerModule steuert alle Module des Systems. Er liest sie ein und informiert sie über Änderungen an den globalen Einstellungen. 5 ModuleConfig beinhaltet die Modulinformationen wie Name und Version. Des weiteren befinden sich dort die Properties (standard.properties) und der Localizer für die Mehrsprachigkeit. 6 ModuleData ist der Data-Container des Moduls. Benötigt für die Anforderungen /LF1010/ bis /LF1040/ 7 ModuleDb ist der DB-Container des Moduls. Benötigt für die Anforderungen /LF1110/ bis /LF1140/. 8 Module ist das eigentliche Modul. Benötigt für die Anforderungen /LF1210/ bis /LF1350/. Tabelle 5.3.: Beschreibung der Architektur 48

55 Flussdiagramm Das Flussdiagramm mit den Hauptfunktionen des Systems ist in der Abbildung 5.7 und der Tabelle 5.4 ersichtlich: Abbildung 5.7.: Flussdiagramm der Hauptfunktionen 49

56 Nr Beschreibung 1 Nach dem Programmstart liest das Programm als Erstes seine Properties, Sprachen und Konfiguration ein. Danach sucht es alle Module und liest deren Konfiguration, Data- und DB-Container und startet jedes aktive Modul. 2 Wählt der Benutzer eine Funktion eines Moduls, wird diese durch das Modul ausgeführt. Der Kontrollfluss der Hauptapplikation und der anderen Module wird dadurch nicht beeinträchtigt und erfüllt somit die Anforderung /LF0910/. 3 Der Benutzer wechselt die Sprache. Die Hauptapplikation und sämtliche aktiven Module werden über das Ereignis via Listener informiert. Erfüllt die Anforderungen /LF0610/ bis /LF0630/. 4 Der Benutzer wechselt das Look & Feel. Die Hauptapplikation und sämtliche aktiven Module werden über das Ereignis via Listener informiert. Erfüllt die Anforderungen /LF0510/ bis /LF0530/. 5 Der Benutzer ändert die Schriftgrösse. Die Hauptapplikation und sämtliche aktiven Module werden über das Ereignis via Listener informiert. Erfüllt die Anforderungen /LF0710/ bis /LF0730/. 6 Der Benutzer ändert die Icongrösse. Die Hauptapplikation und sämtliche aktiven Module werden über das Ereignis via Listener informiert. Erfüllt die Anforderungen /LF0810/ bis /LF0830/. 7 Beim Beenden des Programms werden sämtliche Module aufgefordert, ihre Arbeiten abzuschliessen, d.h. z.b. eine Applikation mit DB muss ihre Transaktionen committen. Anschliessend werden die Konfiguration sowie alle Data-Container geschrieben und das System beendet. Tabelle 5.4.: Beschreibung des Flussdiagramms 50

57 Klassendiagramme Nachfolgend sind die Hauptklassen des Systems aufgezeigt und beschrieben. In Abbildung 5.8 ist die Legende der verschiedenen Pakete ersichtlich: Abbildung 5.8.: Legende der Klassendiagramme Module Das Paket module ist das Kernstück von Tyr. Die Hauptapplikation sowie alle Module basieren auf dessen Basisklassen. Die Klasse Callback aus Abbildung 5.9 dient dem Modul zur Kommunikation mit dem Hauptprogramm und repräsentiert die Anforderungen /LF0410/ bis /LF0430/ : Abbildung 5.9.: Callback Ein Icon liegt als Bitmap in mindestens zwei verschiedenen Grössen vor, nämlich als 32x32 Pixel und als 128x128 Pixel. Die Skalierfunktion müsste dann für jede Grösse einen eigenen Parameter bieten. Dies vereinfacht die Klasse ScalableIcon aus Abbildung Sie stellt die Icons in den benötigten Grössen bereit und hilft beim Erfüllen der Anforderungen /LF0810/ bis /LF0830/ : Abbildung 5.10.: ScalableIcon 51

58 Die Klasse Module aus Abbildung 5.11 ist die Basisklasse für jedes Modul und deckt die Anforderungen /LF0310/ bis /LF0370/ sowie /LF0910/ ab: Abbildung 5.11.: Module 52

59 Die Klasse ModuleConfig aus Abbildung 5.12 ist die Konfiguration des Moduls und beinhaltet unter anderem Informationen über Name, Version, zu startende Klasse und zusätzliche Libraries: Abbildung 5.12.: ModuleConfig 53

60 Die Klasse ModuleData aus Abbildung 5.13 ist der Data-Container für die Module mit einigen Datentypen als key-value-paare. Hiermit werden die Anforderungen /LF1010/ bis /LF1040/ erfüllt: Abbildung 5.13.: ModuleData Die Klasse ModuleDb aus Abbildung 5.14 ist der DB-Container für die Module mit einigen Hilfsfunktionen für SQL-Befehle. Damit werden die Anforderungen /LF1110/ bis /LF1140/ erfüllt: Abbildung 5.14.: ModuleDb 54

61 Application Das Paket application wiederspiegelt die Hauptapplikation und besteht aus den nachfolgenden Klassen. Die Klasse Tyr aus Abbildung 5.15 ist die Startklasse des Systems und liest die Properties und Sprachen ein. Anschliessend übergibt es die Kontrolle dem ControllerTyr: Abbildung 5.15.: Tyr Die Klasse TyrData aus Abbildung 5.16 ist die Konfiguration des Systems und speichert Daten wie z.b. die gewählte Sprache, Look & Feel, Schrift- und Icongrösse. Es erfüllt die Anforderungen /LF0530/, /LF0630/, /LF0730/ und /LF0830/ : Abbildung 5.16.: TyrData 55

62 Die Klasse ControllerTyr aus Abbildung 5.17 steuert den gesamten Ablauf des Systems und liest und speichert dessen Konfiguration. Des weiteren verwaltet er den Zugriff auf die Icons und repräsentiert den Callback für das Modul: Abbildung 5.17.: ControllerTyr Die Klasse ControllerModule aus Abbildung 5.18 steuert alle Module des Systems. Er liest sie ein und informiert sie über Änderungen an den globalen Einstellungen: Abbildung 5.18.: ControllerModule 56

63 Test Das Modul Test besteht aus der Klasse Test aus Abbildung Die Klasse leitet von ModuleAbstract ab, welche Teil des module-pakets ist und bereits einen Grossteil des Implementationsaufwands erledigt. An diesem Beispiel sieht man, dass in TestImpl nur noch die Methoden geschrieben werden müssen, welche Modulspezifisch sind. Nur das Modul weiss z.b. was im Falle einer Schriftgrössenänderung mit seinen GUI-Elementen zu tun ist: Abbildung 5.19.: Test 57

64 Datenstrukturen Neben den binären Dateien wie Icons und ander Libraries, liegen die übrigen Datenstrukturen in zwei Formaten vor, nämlich als Properties- und als XML-Dateien. Nachfolgend werden die verwendeten Dateien und Strukturen aufzeigt. standard.properties Die standard.properties aus Listing 5.1 werden für den ersten Programmstart verwendet, damit sich das System initialisieren kann. Dabei handelt es sich um unveränderliche key-value-paare für diverse Parameter. Die Parameter, welche zur Laufzeit ändern können, z.b. directory.module werden in der Tyr Data (TDA)-Datei für Tyr gespeichert und in allen nachfolgenden Ausführungen von dort gelesen. 1 l o c a l i z e r. base = net / l a u b e n b e r g e r / t y r / t y r 2 d i r e c t o r y. module =. / modules / Listing 5.1: standard.properties tyr.properties Die tyr.properties sind die Sprachdateien als unveränderliche key-value-paare. Das Listing 5.2 zeigt die Sprachdatei in der Standardsprache und das Listing 5.3 die Übersetzung in Deutsch. 1 a c t i o n. c l o s e = Close 2 a c t i o n. c l o s e. t o o l t i p = Close t h i s window 3 a c t i o n. c l o s e. mnemonic = C Listing 5.2: tyr.properties in der Standardsprache Listing 5.3: tyr-de.properties in Deutsch 1 a c t i o n. c l o s e = S c h l i e s s e n 2 a c t i o n. c l o s e. t o o l t i p = S c h l i e s s e n des F e n s t e r s 3 a c t i o n. c l o s e. mnemonic = S TMC In den Tyr Module Configuration (TMC)-Dateien werden die Modulkonfigurationen als XML- Struktur abgelegt. Ein Beispiel des Test-Moduls ist in Listing 5.4 ersichtlich: Listing 5.4: TMC 1 <?xml v e r s i o n = 1.0 encoding = UTF 8 s t a n d a l o n e = yes?> 2 <moduleconfig> 3 <i n s t a n t i a t e d > T11 :22: :00 </ i n s t a n t i a t e d > 4 <name>test </name> 5 <v e r s i o n >0.15</ v e r s i o n > 6 <build >115</ build > 7 <created > T11:22:00+01:00 </ created > 8 <UUID>f e b b 2 1 f e 52e bfd4 dcc0fd2cc074 </UUID> 9 <url >http : / / dev. l a u b e n b e r g e r. net/</ url > 10 <persons > 11 <i n s t a n t i a t e d > T11 :22: :00 </ i n s t a n t i a t e d > 12 <name>laubenberger </name> 13 <forename>stefan </forename> 14 <birthday > T00:00:00+01:00 </ birthday > 15 <gender>male</gender> 16 <s t r e e t >B u l l i n g e r s t r a s s e 53</ s t r e e t > 58

65 17 <zip >8004</ zip > 18 <c i t y >Zuerich </c i t y > 19 <country>switzerland</country> 20 <phonenumber> </phoneNumber> 21 < >laubenberger@ gmail. com</ > 22 <url >http : / /www. l a u b e n b e r g e r. net </url > 23 <r o l e s >DEVELOPER</r o l e s > 24 <r o l e s >OWNER</r o l e s > 25 </persons > 26 <debug>f a l s e </debug> 27 <j a r s >tyr module t e s t. j a r </j a r s > 28 <moduleclass>net. l a u b e n b e r g e r. t y r. module. t e s t. TestImpl </moduleclass> 29 <l o c a l i z e r B a s e >net / l a u b e n b e r g e r / t y r /module/ t e s t / t e s t </ l o c a l i z e r B a s e > 30 <logo >net / l a u b e n b e r g e r / t y r /module/ t e s t / i c o n / s m a l l / l o g o. png</logo > 31 <logolarge >net / l a u b e n b e r g e r / t y r /module/ t e s t / i c o n / l a r g e / l o g o. png</logolarge > 32 </moduleconfig> TDA In den TDA-Dateien werden die Data-Container als XML-Struktur abgelegt. Folgendes Listing 5.5 deckt die Datenanforderung /LD100/ ab: Listing 5.5: TDA für Tyr 1 <?xml v e r s i o n = 1.0 encoding = UTF 8 s t a n d a l o n e = yes?> 2 <tyrdata> 3 <i n s t a n t i a t e d > T02 :29: :00 </ i n s t a n t i a t e d > 4 <directorymodule >./ modules</directorymodule > 5 <directorydata >/Users / s l a u b e n b e r g e r /. t y r / data </directorydata > 6 <directorydb >/Users / s l a u b e n b e r g e r /. t y r /db</directorydb> 7 <language>german</language> 8 <lookandfeel>org. p u s h i n g p i x e l s. substance. api. s k i n. MarinerSkin </lookandfeel> 9 <f o n t S i z e O f f s e t >2</ f o n t S i z e O f f s e t > 10 <i c o n S i z e > 11 <entry> 12 <key>x</key> 13 <value >20</value> 14 </entry> 15 <entry> 16 <key>y</key> 17 <value >0</value> 18 </entry> 19 </i c o n S i z e > 20 </tyrdata> Die Datenanforderung /LD200/ wird mit folgendem Listing 5.6 erfüllt: Listing 5.6: TDA für Module 1 <?xml v e r s i o n = 1.0 encoding = UTF 8 s t a n d a l o n e = yes?> 2 <moduledata> 3 <i n s t a n t i a t e d > T02 :29: :00 </ i n s t a n t i a t e d > 4 <data> 5 <entry> 6 <key>key. module. enabled </key> 7 <value>true </value> 8 </entry> 9 </data> 10 </moduledata> 59

66 5.5. Entwicklungsumgebung Hier werden die Programme, welche zum entwickeln des Systems dienen, kurz erläutert und deren Einsatz begründet. Grundsätzlich halte ich mich an die Liste aus dem Pflichtenheft im Kapitel , ergänze diese aber falls nötig mit weiteren Software-Komponenten Betriebssytem Folgende Tabelle 5.5 zeigt die während der Entwicklung eingesetzten Betriebssyteme: Name Hersteller Version Architektur Lizenz Kubuntu (Linux) Ubuntu Foundation (TLS) x86 (32 Bit) diverse MacOS X Apple x86 (64 Bit) kommerziell Ubuntu (Linux) Ubuntu Foundation (TLS) x86 (32 Bit) diverse Windows XP Microsoft XP (Professional) x86 (32 Bit) kommerziell Windows 7 Microsoft 7 (Professional) x86 (32 Bit) kommerziell Tabelle 5.5.: Eingesetzte Betriebssyteme Die Entwicklung findet auf MacOS X statt, da dies das Betriebssystem meines Rechners ist. Die restlichen vier Systeme werden als virtuelle Maschinen ausgeführt und dienen hauptsächlich zum Testen des Systems und zum Ausführen spezieller, betriebssystemabhängiger Software, wie z.b. Microsoft Visio2010 oder Microsoft Project2010. Die Betriebssysteme Ubuntu und Kubuntu decken die Anforderung an die Benutzeroberflächen Gnome und KDE ab. Weiterführende Informationen Name Kubuntu MacOS X Ubuntu Windows XP Windows 7 URL Tabelle 5.6.: Weiterführende Informationen zu den Betriebssytemen 60

67 Programmiersprache JavaSE 6 ist als Programmiersprache für das System festgelegt. Die Tabelle 5.7 zeigt die verwendeten Versionen: Name Hersteller Version OS Architektur JDK Sun (Oracle) Windows x86 (32 Bit) MacJDK Apple MacOS X x86 (64 Bit) OpenJDK Sun (Oracle) Linux x86 (32 Bit) Tabelle 5.7.: Eingesetzte Versionen von Java Weiterführende Informationen Name JDK MacJDK OpenJDK URL Tabelle 5.8.: Weiterführende Informationen zu den eingesetzten Versionen von Java IDE Grundsätzlich ist es dem Entwickler überlassen, in was für einer Umgebung er seinen Code schreibt. Java kann in jedem Texteditor geschrieben und auf der Konsole kompiliert werden. Eine Integrated Development Environment (IDE) nimmt einem aber viel Arbeit ab, in dem sie den Code automatisch vervollständigen, debuggen und testen kann. Tabelle 5.9 zeigt die verwendeten IDEs: Name Hersteller Version Lizenz Eclipse Eclipse Foundation Helios (SR1) EPLv1 IntelliJ JetBrains (Ultimate) kommerziell Tabelle 5.9.: Eingesetzte IDEs Eclipse Eclipse verwende ich seit Jahren in der täglichen Arbeit und kenne es deshalb am besten. Ich kann damit sämtliche Arbeiten zum Erstellen und Testen von Java-Programmen erledigen. Es wird somit als Hauptentwicklungswerkzeug eingesetzt. 61

68 IntelliJ Ich finde IntelliJ die beste Java-IDE. Leider ist sie nicht sehr verbreitet, da sie lange Zeit nur als kostenpflichtige Version verfügbar war. Seit Version 9 gibt es eine freie Community-Version und weiterhin eine kommerzielle Variante Namens Ultimate. Diese beinhaltet viel mehr Funktionen und unteranderem die beste Code-Analyse die ich kenne. Da mein System eine Open-Source-Software ist, erhalte ich die Ultimate-Version ebenfalls gratis; das finde ich sehr freundlich von JetBrains. Weiterführende Informationen Name Eclipse IntelliJ URL Tabelle 5.10.: Weiterführende Informationen zu den eingesetzten IDEs Virtualisierung Alle Betriebssysteme ausser MacOS X führe ich in einer virtuellen Maschine aus. Dazu muss eine Virtualisierungssoftware eingesetzt werden. Neben den kommerziellen Varianten VMWare 49 und Paralles 50 gibt es auch eine sehr gute Open-Source-Lösung namens VirtualBox 51. Diese Software ist schon seit Jahren bei meinem Arbeitgeber im produktiven Einsatz und ich selbst nutze sie auch seit einiger Zeit und bin damit sehr zufrieden. Ich werde die Betriebssysteme auf VirtualBox Version installieren und einrichten. VirtualBox kann die virtuellen Maschinen im OVA/OVF -Format importieren und exportieren, wodurch die Portabilität zwischen anderen Herstellern gewährleistet ist Texteditor TextMate 52 Version ist ein sehr guter, aber kostenpflichtiger Texteditor für MacOS X. Hauptsächlich benutze ich ihn zum schreiben der LATEX-Dokumente und zum editieren diverser Textdateien. Eine freie Alternative wäre z.b. jedit

69 Konzeptionelle Visualisierung Zum Darstellen des Systems habe ich die Programme aus Tabelle 5.11 verwendet: Name Hersteller Version OS Lizenz ArgoUML freie Entwickler alle EPLv1 Balsamiq Mockups Balsamiq alle kommerziell (Trial) Visio Microsoft 2010 (Professional) Windows kommerziell Tabelle 5.11.: Eingesetzte Programme für konzeptionelle Visualisierung ArgoUML ArgoUML ist eines der wenigen Unified Modeling Language (UML)-Werkzeuge auf Open-Source- Basis. Es dient zur Beschreibung, Modellierung und Code-Generierung von Softwaresystemen. Ich verwende es zum Erstellen der Klassendiagramme. Balsamiq Mockups Mit Balsamiq Mockups können auf sehr einfache Art und Weise Wireframes erstellt werden. Visio Visio ist eine Visualisierungssoftware zum Darstellen verschiedenster Abläufe und Zusammenhänge. Ich verwende es zum Erstellen von Architekturübersichten, Fluss- und Anwendungsfalldiagrammen. Weiterführende Informationen Name ArgoUML Balsamiq FreeMind Visio URL Tabelle 5.12.: Weiterführende Informationen zu den eingesetzten Programmen für konzeptionelle Visualisierungen 63

70 Office Die typischen Office Aufgaben, wie Dokumentation, Tabellen und Planung habe ich mit folgender Software aus Tabelle 5.13 erledigt: Name Hersteller Version OS Lizenz LATEX Leslie Lamport LATEX 2ε alle LPPL 1.3 OpenOffice Oracle alle LGPL Project Microsoft 2010 (Professional) Windows kommerziell Tabelle 5.13.: Eingesetzte Office-Programmme Latex LATEX vereinfacht die Verwendung des professionellen Textsatzprogrammes TEX. Ich verwende es zum Erstellen der gesamten Dokumentation der Semesterarbeit. OpenOffice OpenOffice ist ein Büropaket bestehend aus Textverarbeitung, Tabellenkalkulation, Datenbank, Zeichnungsprogramm und einer Präsentationssoftware. Für die Semesterarbeit verwende ich die Tabellenkalkulation und Präsentationssoftware. Project Mit Project kann mann sehr gut die Terminplanung von Projekten erfassen. Ich verwende es zum Erstellen des Projektplans. Weiterführende Informationen Name LATEX OpenOffice Project URL Tabelle 5.14.: Weiterführende Informationen zu den eingesetzten Office-Programmmen 64

71 Grafik Um Icons in in beliebigen Grössen zu exportieren und diverse Grafiken nachzubearbeiten, benötige ich ein Vektor- und Bitmap-Grafikprogramm. Die Tabelle 5.15 zeigt die zu verwendenden Grafikprogramme: Name Hersteller Version OS Lizenz Typ GIMP GIMP-Team alle GPLv2 Bitmap InkScape InkScape Community 0.47 alle GPLv2 Vektor Tabelle 5.15.: Eingesetzte Grafik-Programmme GIMP GIMP ist ein etabliertes Bitmap-Grafikprogramm und reicht bei weitem für meine Anforderungen wie z.b. Grössen- und Farbanpassungen von Bitmap-Bildern. InkScape InkScape ist ein verbreitetes Vektorprogramm. Damit kann ich z.b. Icons selbst erstellen oder die Icon-Libraries in beliebigen Grössen exportieren. Weiterführende Informationen Name GIMP InkScape URL Tabelle 5.16.: Weiterführende Informationen zu den eingesetzten Grafik-Programmmen Projekthosting Es gibt viele Seiten, die Projekthosting anbieten, wie z.b. SourceForge 54, GitHub 55 und GoogleCode 56. Da ich bereits Bogatyr in GoogleCode hoste, habe ich mich entschieden, es für Tyr ebenfalls zu verwenden. Es gibt auch einige gute Gründe dafür: Versionskontrollenanbindung für SVN 57 und Mercurial

72 Eingebaute Plattform zur Problem- und Fehlerverfolgung. Projektdokumentation kann über das eingebaute Wiki gemacht werden. Eigener Download-Bereich für die Software. Bietet für Projekte alle verbreiteten Open-Source-Lizenzen, wie z.b. BSD, EPL, LGPL und GPL. Es gehört zu Google, d.h. ihre Suchmaschine hat das Projekt und dessen Fortschritt ständig aktuell indexiert. Tyr veröffentliche ich unter Open-Source GPLv2 auf GoogleCode und erfülle somit auch gleich die Anforderung LL Wiki Ich möchte für meine Unterstützung während der Arbeit diverse Wiki-Seiten einrichten, wie z.b. ToDo und Meilensteine. Diese Anforderung kann ich über das gewählte Projekthosting abdecken Versionierung Die Versionskontrolle des Projekts ist durch das Projekthosting abgedeckt und ich entscheide mich für die Variante SVN, da ich dieses gut kenne und weiss, dass es einwandfrei funktioniert. Da ich jedoch an diversen Computern arbeite und meine Daten immer verfügbar haben möchte, verwende ich zusätzlich Dropbox 59 zur automatischen Dateisynchronisation. Es bietet gratis 2 GB Webspace und hat ebenfalls eine eingebaute Versionskontrolle, wodurch ich SVN nur noch für grössere Änderungen verwende Build-Prozess Lange Zeit habe ich den Build- und Deployprozess in vielen meiner Java-Entwicklungen mit Ant 60 erledigt. Letztes Jahr musste ich für meinen Arbeitgeber eine Software mit Maven2 61 realisieren. Der Funktionsumfang erschien mir erdrückend und so las ich das Buch Maven2 (Spi09) von Martin Spiller. Danach war Einiges besser verständlich und je mehr ich damit arbeitete, umso grösser wurde meine Begeisterung. Inzwischen erstelle ich alle neuen Java-Projekte mit Maven und werde es auch für die Semesterarbeit einsetzen Testen Um das Laufzeitverhalten der Applikation im Detail zu betrachten, gibt es in Java seit Version 6 ein mitgeliefertes Programm Namens VisualVM 62. Mit dessen Hilfe kann jeder Java-Prozess des Computers analysiert werden und Informationen wie Speicher- und Zeitverbrauch ausgelesen werden

73 6. Realisierung 6.1. Projektsetup Maven Im Kapitel wurde Maven als Build-Tool vorgestellt. Ein Standard-Maven-Projekt hat eine fixe Struktur, die wie in Tabelle 6.1 gezeigt wird: Pfad src/main/java src/main/resources src/main/config src/test/java src/test/resources LICENSE.txt README.txt Beschreibung Java Source-Dateien Ressource-Dateien wie Bilder, Sprachen etc. Konfigurationsdateien Java Test-Source-Dateien Test-Ressource-Dateien Lizenz der Software Weiterführende Informationen Tabelle 6.1.: Standard-Maven-Projekt Die Beschreibung der Projektdefinition geschieht in einer sogenannten Project Object Model (POM)-Datei, in welcher alle Abhängigkeiten, Build- und Testanweisungen definiert sind. Listing 6.1 zeigt eine vereinfachte Darstellung eines typischen POM : Listing 6.1: Vereinfachtes POM 1 <?xml v e r s i o n = 1.0 encoding = UTF 8 s t a n d a l o n e = yes?> 2 <p r o j e c t xmlns= http : / / maven. apache. org /POM/ xmlns : x s i = http : / /www. w3. org /2001/ 3 XMLSchema i n s t a n c e 4 x s i : schemalocation= http : / / maven. apache. org /POM/ http : / / maven. apache. org / 5 maven v xsd > 6 <modelversion >4.0.0 </ modelversion> 7 <groupid>net. l a u b e n b e r g e r. tyr </groupid> 8 <a r t i f a c t I d >tyr module</ a r t i f a c t I d > 9 <packaging>j a r </packaging> 10 <v e r s i o n >0.8</ v e r s i o n > 11 <name>tyr module</name> 12 <d e s c r i p t i o n >Tyr module i n t e r f a c e </d e s c r i p t i o n > 13 <url >http : / /www. l a u b e n b e r g e r. net </url > 14 <inceptionyear >2010</ inceptionyear > <d e v e l o p e r s > </d e v e l o p e r s > <r e p o s i t o r i e s >

74 22 </ r e p o s i t o r i e s > <distributionmanagement > </distributionmanagement > <dependencies > </dependencies > <build > </build > <r e p o r t i n g > </r e p o r t i n g > 39 </p r o j e c t > Nachdem die Struktur erstellt und das POM im Root des Projekts angelegt wurden, können auf der Konsole im Projektverzeichnis die Befehle aus dem Listing 6.2 zum Erstellen des Eclipseund IntelliJ-Projekts ausgeführt werden: 1 mvn e c l i p s e : e c l i p s e 2 mvn i d e a : i d e a Listing 6.2: Eclipse- und IntelliJ-Projekte erstellen Repositories Maven holt sich alle benötigten Libraries über die Abhängigkeitsdefinitionen selbst ins lokale Repository der Entwicklermaschine. Leider sind jedoch längst nicht alle Libraries in den offiziellen Repositories, viele sind sogar nur als JAR-Datei erhältlich. Deshalb habe ich ein eigenes Repository unter angelegt. Dort hoste ich die drei benötigten Libraries Substance, JLayer und Bogatyr sowie natürlich auch Tyr Entwicklung Allgemein Einige Überlegungen und Entscheidungen vor dem Start: Interfaces Um Tyr möglichst einfach zu erweitern, sind alle Klassen als Interfaces definiert und haben eine konkrete Implementation. Properties-Mechanismus Der Default-Properties-Mechanismus in Java kann nur ISO kodierte Dateien lesen. Ich möchte aber auch andere Schriften unterstützen und benötige deshalb UTF-8. Dies löse ich mit einer Erweiterung des Localizers in Bogatyr mittels einer eigenen Kontrollklasse. 68

75 Verzeichnis Die Log-, Data- und DB-Container-Dateien werden unter dem Benutzerordner im Verzeichnis.tyr gespeichert. Bei einer Deinstallation muss nur dieses Verzeichnis und der Programmordner gelöscht werden um alles sauber zu entfernen. Logging Das Logging ist ausserhalb des Systems konfigurierbar, d.h. es kann über die Logback.xml beliebig angepasst werden. Der eingestellte Loglevel ist WARN. Im Listing 6.3 ist die ausgelieferte Konfiguration ersichtlich: Listing 6.3: Logback.xml 1 <?xml v e r s i o n = 1.0 encoding = UTF 8?> 2 <c o n f i g u r a t i o n > 3 <appender name= tyrfileappender c l a s s = ch. qos. logback. c o r e. r o l l i n g. R o l l i n g F i l e A p p e n d e r > 4 < f i l e >${ u s e r. home } /. t y r / t y r. log </ f i l e > 5 <append>true </append> 6 7 <encoder> 8 <pattern >% 4r e l a t i v e [% thread ] % 5l e v e l %l o g g e r {35} %msg%n</pattern > 9 </encoder> <r o l l i n g P o l i c y c l a s s = ch. qos. logback. c o r e. r o l l i n g. FixedWindowRollingPolicy > 12 <filenamepattern >${ u s e r. home } /. t y r / t y r. l o g.% i </filenamepattern > 13 <minindex>1</minindex> 14 <maxindex>3</maxindex> 15 </ r o l l i n g P o l i c y > <t r i g g e r i n g P o l i c y c l a s s = ch. qos. logback. c o r e. r o l l i n g. S i z e B a s e d T r i g g e r i n g P o l i c y > 18 <maxfilesize >1MB</maxFileSize > 19 </ t r i g g e r i n g P o l i c y > 20 </appender> <r o o t l e v e l = WARN > 23 <appender r e f r e f = tyrfileappender /> 24 </root > 25 </c o n f i g u r a t i o n > Im Code werden alle Konstruktoren- und Methodenaufrufe mit den jeweiligen Input- und Output-Parametern geloggt. Dazu müssen die Loglevels wie in Tabelle 6.2 konfiguriert sein: Bezeichnung Konstruktoren private Methoden public Methoden Loglevel TRACE TRACE DEBUG Tabelle 6.2.: Loglevels 69

76 Paket module Das module-paket definiert alle Klassen und Methoden für die Applikation und Module. Erweiterungen Während der Entwicklung habe ich festgestellt, das HSQLDB keinen SQL-Befehl zum Prüfen der Existenz einer Tabelle zur Verfügung stellt. Es muss auf relativ komplizierte Art im Schema nachgeschlagen werden. Diese Funktionalität habe ich vereinfacht und als Methode existstable in ModuleDb eingebaut. Herausforderungen Mit zwei grösseren Herausforderungen musste ich mich auseinandersetzen: TrayIcon Beim Start des Projekts war mir nicht bewusst, dass die Klasse TrayIcon 1 eine AWT-Klasse ist und somit über keine Swing-Features wie veränderbare GUI-Komponenten verfügt, da sie jeweils nativ implementiert wird wie Abbildung 6.1 zeigt: Abbildung 6.1.: AWT TrayIcon Nach einigem experimentieren, habe ich ein eigenes TrayIcon 2 im Bogatyr eingebaut. Der Trick ist dabei, dass ich einen neuen Konstruktor gebaut habe, welcher ein Swing-Popup-Menü akzeptiert. Des weiteren musste ich die gesamte Verwaltung des Popup-Menüs selbst übernehmen, welches sich je nach Betriebssystem unterschiedlich verhält. Dies hat mich ziemlich viel Aufwand gekostet, doch für die Lösung und den Gewinn scheint mir dies akzeptabel. ModuleData Es war nicht ganz einfach die verschiedenen Datentypen zuzulassen, insbesondere Date 3 und generische Klassen waren fordernd, da alle Werte als String 4 repräsentiert werden müssen. Ersteres habe ich mit dem ISO-8601-Format(Wik11b) umgesetzt und die Objekte serialisiere ich in ein weiteres XML-Objekt und verwende das Resultat als Wert. Erfolge Alle Klassen funktionieren einwandfrei und ich bin mit dem Resultat zufrieden

77 Paket application Das application-paket ist das Hauptprogramm und wird zum Ausführen von Tyr benötigt. Erweiterungen Es wurden viele Erweiterungen zum application-paket hinzugefügt: Locking Während der Entwicklung habe ich realisiert, dass es sich ungünstig auswirken kann, wenn ein Benutzer gleichzeitig mehrere Instanzen von Tyr laufen lässt. Dies ist vorallem darin begründet, dass pro Modul und Benutzer nur ein Data-Container und DB-Container zur Verfügung steht. Dies wiederum kann bei mehreren Instanzen zu Daten-Inkonsistenzen führen. Aus diesem Grund erstellt das System beim Applikationsstart eine Datei, welche erst beim Beenden gelöscht wird. Startet nun ein zweiter Prozess und stellt dieser fest, dass bereits eine Instanz läuft, so wird der Benutzer gefragt, was zu tun ist. Es obliegt der Entscheidung des Benutzers, ob er einen Parallelbetrieb mit den resultierenden Seiteneffekten wünscht. Look & Feel Das System kann einfach mit neuen Look & Feel-Libraries erweitert werden. Die 27 verschiedenen Look & Feels von Substance und die vier Standard-Java Look & Feels überbieten die Anforderung LF510 um ein vielfaches. Sprachen Es können beliebige Sprachen hinzugefügt werden. Für den Prototypen habe ich Sprachdateien in Deutsch, Englisch, Französisch 5, Italienisch 5 und Japanisch 5 erstellt. Somit übertreffe ich die Anforderung LF610 von nur zwei geforderten Sprachen. Schriftgrössen Die Schriftgrössen können beliebige gewählt werden. In der Implementation habe ich die Anzahl auf 12 gesetzt, was eine Verdopplung der in Anforderung LF710 geforderten sechs Stufen darstellt. Icongrössen Die Implementation der Methode getscaledicon in der Klasse ControllerTyr 5.17 ist völlig dynamisch ausgelegt, d.h es kann eine beliebige Icongrösse gewählt werden. Aus Gründen der Benutzerfreundlichkeit habe ich die Anzahl Stufen auf 12 festgelegt, was ebenfalls eine Verdopplung der in Anforderung LF810 geforderten sechs Stufen darstellt. Herausforderungen Das Studium und Ausprobieren der Substance-Library war ziemlich aufwändig. Ansonsten gab es keine erwähnenswerten Herausforderungen. 5übersetzt mit 71

78 Erfolge Die Applikation läuft und funktioniert einwandfrei unter allen geforderten Betriebssystemen und zusätzlich auch unter Unix 6. Erkenntnisse Die Icons aus dem Crystal Clear-Paket haben mir am besten gefallen und ich habe diese auch hauptsächlich eingesetzt Modul Test Dieses Modul war gar nicht geplant, doch während der Entwicklung kam mir die Idee, es zu schreiben. Mit diesem kann ich alle Funktionen von Tyr testen, wie in Abbildung 6.2 ersichtlich ist: Abbildung 6.2.: Modul Test Herausforderungen Die Umsetzung bot keine besonderen Herausforderungen. Erfolge Es hat sich gelohnt, dieses Modul zu erstellen, da ich damit alle Funktionen ausprobieren kann. Erkenntnisse Für den Threading-Test habe ich eine neue Library namens JBusyComponent 7 evaluiert. Mit dieser kann man einfach Fortschrittsanzeigen über Komponenten legen und bietet bedeutend mehr als der bekannte JProgressBar 8. 6 getestet unter OpenSolaris :

79 Modul MusicPlayer Das MusicPlayer-Modul dient zum Abspielen von MP3-Dateien. Erweiterungen Die Umsetzung hat mir viel Spass bereitet und so habe ich noch zwei neue Funktionen hinzugefügt: Zufällige Wiedergabe der Titel (de- und aktivierbar). Hinzufügen neuer Titel zur bestehenden Wiedergabeliste (de- und aktivierbar). Herausforderungen Das ganze Modul ist multi-threaded, d.h. z.b. das die Musik weiter spielt wenn die Dateisuch- Routine neue Dateien zur Wiedergabeliste hinzufügt. Dies war nicht so einfach zu lösen, denn das System muss genau wissen, welche Threads momentan aktiv sind, um sie bei Bedarf auch sauber beenden zu können. Zusätzlich musste ich die Funktionsweise der JLayer-Library kennenlernen und sie richtig einbinden. Erfolge MusicPlayer ist für mich in der vorliegenden Version schon sehr nahe an der endgültigen Fassung und ich benutze es bereits intensiv Modul Scrambler Das Scrambler-Modul dient zum Ver- und Entschlüsseln von Dateien. Erweiterungen Es wurden zwei Erweiterungen zum Scrambler-Modul hinzugefügt: Algorithmen Die 18 verschiedene symmetrischen Algorithmen von Bouncy Castle übertreffen die Anforderung T1330. Dateien Zusätzlich zu den zuletzt verwendeten Dateien für die Ver- und Entschlüsselung wird auch die jeweilige Ausgabedatei im Data-Container abgelegt. Dies erweitert die Anforderungen T1340 und T1350. Herausforderungen Die Anforderungen an das Threading sind ähnlich wie diejenigen im MusicPlayer. Der Unterschied ist, dass parallel 1-n Dateien ver- und entschlüsselt werden können, was dann auch 1-n Threads entspricht. Des weiteren musste ich die Kryptografie-Verfahren der Bouncy Castle- Library studieren und anwenden. 73

80 Erfolge Der Scrambler erfüllt für mich genau seinen Zweck, nämlich schnell und sicher Dateien zu verschlüsseln bzw. entschlüsseln. Dieses Modul hat für meine tägliche Arbeit einen grossen Nutzen Release In dieser Sektion wird der gewählte Release-Mechanismus erklärt Vorbereitung Mein Projekt ist durchgängig mit Maven verwaltet. Um einen Release durchzuführen, müssen folgende Schritte ausgeführt werden: 1. SVN checkout 9 oder update Im Verzeichnis von module das Maven Projekt erstellen Im Verzeichnis von application das Maven Projekt erstellen 11 und Libraries 12 kopieren. 4. Alle Modul mit Maven erstellen Einen Ordner Release mit den Unterverzeichnissen lib und modules erstellen. 6. Das erstellte module-jar nach Release/lib kopieren. 7. Alle benötigten Libraries aus application nach Release/lib kopieren. 8. Das erstellte application-jar, logback.xml und standard.properties nach Release kopieren. 9. Das erstellte Module nach Release/modules kopieren. Nach Abschluss dieser Punkte kann das application-jar und somit Tyr ausgeführt werden Betriebssysteme Um es den Benutzern der verschiedenen Betriebssystem so einfach wie möglich zu machen, erstelle ich pro System einen Release. Windows Die Windows-Benutzer sind es sich gewohnt, eine EXE-Datei als Programm zu erkennen und auszuführen. Deshalb erstelle ich einen Release für Windows mit dem Tool Launch4J 14, welches in Abbildung 6.3 ersichtlich ist: Um einen Release zu erstellen, muss das Verzeichnis Release nach z.b. ReleaseWindows kopiert werden. In diesem neuen Verzeichnis muss mit Launch4J das Windows-Programm generiert werden. Das Resultat ist in Abbildung 6.4 ersichtlich und kann mit Windows verwendet werden: 9 svn co tyr-read-only 10 svn up 11 mvn clean install 12 mvn dependency:copy-dependencies 13 java -jar tyr.jar

81 Abbildung 6.3.: Launch4J Abbildung 6.4.: Release für Windows 75

82 MacOS X Die Benutzer von MacOS X sind es gewohnt, eine APP-Datei als Programm zu erkennen und auszuführen. Deshalb erstelle ich einen Release für MacOS X mit dem Tool Jar Bundler 15, welches in Abbildung 6.5 ersichtlich ist: Abbildung 6.5.: Jar Bundler Im Jar Bundler werden alle benötigten Libraries direkt in die APP kopiert, d.h. aus dem Verzeichnis Release müssen z.b. nach ReleaseMac die Dateien logback.xml und standard.properties sowie die Module kopiert werden. In diesem neuen Verzeichnis muss mit Jar Bundler das MacOS X-Programm generiert werden. Das Resultat ist in Abbildung 6.6 ersichtlich und kann mit MacOS X verwendet werden: Abbildung 6.6.: Release für MacOS X 15 ist Teil der XCode -Entwicklungsumgebung von Apple: 76

83 Unix/Linux Für Unix und Linux gibt es viele verschiedene Paket-Mechanismen und das erschwert eine Distribution erheblich. Da meiner Meinung nach die meisten Unix- und Linux-Benutzer versierte Benutzer sind, erscheint mir die einfachste Lösung in einem Shell-Script wie in Listing 6.4: 1 #!/ bin / sh 2 3 java j a r tyr app. j a r Listing 6.4: tyr.sh Um einen Release durchzuführen, muss das Verzeichnis Release nach z.b. ReleaseUnix kopiert werden. In diesem neuen Verzeichnis muss nun die Datei tyr.sh angelegt werden. Das Resultat ist in Abbildung 6.7 ersichtlich und kann mit Unix oder Linux verwendet werden: Abbildung 6.7.: Release für Unix/Linux 6.4. Projekthosting Neben GoogleCode habe ich noch eine eigene Homepage für das Projekt eingerichtet. Nachfolgend sind die verfügbaren Ressourcen aufgeführt Homepage Die Projekt-Homepage befindet sich unter: SVN Der SVN-Server ist unter folgender URL erreichbar: Repository Das Maven-Repository befindet sich unter folgender Adresse: 77

84 Wiki Die Wiki-Seiten des Projekts befinden sich unter: API Die API von Tyr ist unter folgender URL verfügbar: 78

85 7. Testen 7.1. Globale Testszenarien und Testfälle Jeder Testfall aus Globale Testszenarien und Testfälle im Kapitel wird hier getestet und das Resultat eingetragen Plattformunabhängigkeit Tests Abbildung 7.1 zeigt den Test /T0110/ unter Windows: Abbildung 7.1.: Tyr unter Windows Die Abbildung 7.2 zeigt den Test /T0120/ unter MacOS X: Abbildung 7.2.: Tyr unter MacOS X 79

86 Die Abbildung 7.3 zeigt den Test /T0130/ unter Linux mit Gnome: Abbildung 7.3.: Tyr unter Linux Reultate Test Beschreibung Ergebnis T0110 Das System läuft unter Windows. T0120 Das System läuft unter MacOS X. T0130 Das System läuft unter Linux mit Gnome oder KDE. Tabelle 7.1.: Resultate - Plattformunabhängigkeit System-Tray Tests Die Abbildung 7.4 repräsentiert die Tests /T0210/ bis /T0240/ mit Windows, MacOS X, Gnome und KDE: 1 Abbildung 7.4.: Tyr im System-Tray von Windows, MacOS X, Gnome und KDE 1 von links oben nach rechts unten 80

87 Resultate Test Beschreibung Ergebnis T0210 Die Applikation läuft im System-Tray von Windows. T0220 Die Applikation läuft im System-Tray von MacOS X. T0230 Die Applikation läuft im System-Tray von Gnome. T0240 Die Applikation läuft im System-Tray von KDE. Tabelle 7.2.: Resultate - System-Tray Module Test Methoden aus Sicht des Systems an das Modul: Diese Tests können jederzeit mit dem Referenzmodul Test geprüft werden. Auf eine grafische Darstellung wird hier verzichtet, da in den nachfolgenden Tests jeder Punkt nochmals detailliert getestet wird. Test Beschreibung T0310 Gelöst über TMC (Listing 5.4) T0320 Gelöst über TDA (Listing 5.6) T0320 Gelöst über TDA (Listing 5.6) T0330 Gelöst über Module (Kapitel 5.11) und Test T0340 Gelöst über Module (Kapitel 5.11) und Test T0350 Gelöst über Module (Kapitel 5.11) und Test T0360 Gelöst über Module (Kapitel 5.11) und Test T0370 Gelöst über Module (Kapitel 5.11) und Tests 7.1.4, 7.1.5, und Tabelle 7.3.: Tests der Methoden aus Sicht des Systems 81

88 Methoden aus Sicht des Moduls an das System: Die nachfolgenden Abbildungen 7.5 und 7.6 zeigen den Test /T0410/ : Abbildung 7.5.: Mitteilung anzeigen Abbildung 7.6.: Mitteilung anzeigen Die nachfolgenden Abbildungen 7.7 und 7.8 zeigen den Test /T0420/ : Abbildung 7.7.: Aufgabe hinzufügen 82

89 Abbildung 7.8.: Aufgabe Der Test /T0430/ wird im Test abgehandelt. Resultate Methoden aus Sicht des Systems an das Modul: Test Beschreibung Ergebnis T0310 Das Modul verfügt über eine eine Konfiguration. T0320 Das Modul kann aktiviert und deaktiviert werden. T0330 Das Modul wird über Sprachänderungen informiert. T0340 Das Modul wird über Look & Feel-Änderungen informiert. T0350 Das Modul wird über Schriftgrössenänderungen informiert. T0360 Das Modul wird über Icongrössenänderungen informiert. T0370 Das Modul wird über einen bevorstehenden Programmabbruch informiert. Tabelle 7.4.: Resultate - Module (Systemsicht) 83

90 Methoden aus Sicht des Moduls an das System: Test Beschreibung Ergebnis T0410 kann eine Mitteilung senden, welche als Informationsbereich im System-Tray erscheint. T0420 Das Modul kann eine Aufgabe hinzufügen und entfernen. Diese wird einer zentralen Aufgabenübersicht des Systems übergeben und zeigt ihren Fortschritt an. T0430 Das Modul kann sich korrekt skalierte Icons erzeugen lassen. Tabelle 7.5.: Resultate - Module (Modulsicht) Wählbare Look & Feels Tests Die Abbildung 7.9 zeigt den Test /T0510/ : Abbildung 7.9.: Look & Feel wählen 84

91 Die nachfolgende Abbildung 7.10 gilt für die Tests /T0520/ und /T0530/ : Abbildung 7.10.: Look & Feel gesetzt Im Listing 7.1 ist der Eintrag zum Erfüllen von Test /T0530/ ersichtlich: Listing 7.1: LaF im TDA für Tyr 1 <lookandfeel>org. p u s h i n g p i x e l s. substance. api. s k i n. MagellanSkin </lookandfeel> Resultate Test Beschreibung Ergebnis T0510 Im System kann zwischen mindestens fünf verschiedenen Look & Feels gewählt werden. T0520 Die Module übernehmen das gewählte Look & Feel ohne Neustart. T0530 Das gewählte Look & Feel ist nach einem Neustart immer noch gesetzt. Tabelle 7.6.: Resultate - Wählbare Look & Feels 85

92 Wählbare Sprachen Tests Die Abbildung 7.11 zeigt den Test /T0610/ : Abbildung 7.11.: Sprache wählen Die nachfolgende Abbildung 7.12 gilt für die Tests /T0620/ und /T0630/ : Abbildung 7.12.: Sprache gesetzt Im Listing 7.2 ist der Eintrag zum Erfüllen von Test /T0630/ ersichtlich: 1 <language>japanese</language> Listing 7.2: Sprache im TDA für Tyr 86

93 Resultate Test Beschreibung Ergebnis T0610 Im System kann mindestens zwischen Englisch und Deutsch gewählt werden. T0620 Die Module übernehmen die gewählte Sprache ohne Neustart. T0630 Die gewählte Sprache ist nach einem Neustart immer noch gesetzt. Tabelle 7.7.: Resultate - Wählbare Sprachen Skalierbare Schriften Tests Die Abbildung 7.13 zeigt den Test /T0710/ : Abbildung 7.13.: Schriftgrösse wählen 87

94 Die nachfolgende Abbildung 7.14 gilt für die Tests /T0720/ und /T0730/ : Abbildung 7.14.: Schriftgrösse gesetzt Im Listing 7.3 ist der Eintrag zum Erfüllen von Test /T0730/ ersichtlich: 1 <f o n t S i z e O f f s e t >4</ f o n t S i z e O f f s e t > Listing 7.3: Schriftgrösse im TDA für Tyr Resultate Test Beschreibung Ergebnis T0710 Im System kann mindestens zwischen sechs Schriftgrössen im Bereich von -4 Pixel bis +128 Pixel gegenüber der Standardschrift des Betriebssystems gewählt werden. T0720 Die Module übernehmen die gewählte Schriftgrösse ohne Neustart. T0730 Die gewählte Schriftgrösse ist nach einem Neustart immer noch gesetzt. Tabelle 7.8.: Resultate - Skalierbare Schriften 88

95 Skalierbare Icons Tests In Abbildung 7.15 wird links die Icongrösse 32 Pixel gewählt, während im rechten Bild keine Icons selektiert werden. Dies erfüllt den Test /T0810/ : Abbildung 7.15.: Icongrösse wählen In Abbildung 7.16 ist links eine Icongrösse von 32 Pixel gewählt, während im rechten Bild keine Icons angezeigt werden. Dies erfüllt die Tests /T0820/ und /T0830/ : Abbildung 7.16.: Icongrösse gesetzt 89

96 Im Listing 7.4 ist der Eintrag zum Erfüllen von Test /T0830/ ersichtlich: 1 <i c o n S i z e > 2 <entry> 3 <key>x</key> 4 <value >32</value> 5 </entry> 6 <entry> 7 <key>y</key> 8 <value >0</value> 9 </entry> 10 </i c o n S i z e > Listing 7.4: Icongrösse im TDA für Tyr Resultate Test Beschreibung Ergebnis T0810 Im System kann mindestens zwischen sechs Icongrössen im Bereich von 12 Pixel bis 128 Pixel gewählt werden. Zusätzlich kann auch die Option keine Icons gewählt werden. T0820 Die Module übernehmen die gewählte Icongrösse ohne Neustart. T0830 Die gewählte Icongrösse ist nach einem Neustart immer noch gesetzt. Tabelle 7.9.: Resultate - Skalierbare Icons 90

97 Module und Threads Tests Grundsätzlich funktionieren die Module als unabhängige Threads 2, jedoch sind sie an den Event Dispatch Thread gekoppelt. Dies bedeutet, dass es nur einen Thread gibt, der sämtliche GUI- Elemente der Applikation überwacht. Dies wiederum impliziert, dass sämtliche Arbeiten der Module in sog. SwingWorker erledigt werden müssen, damit das GUI weiterhin ungestört funktioniert. In Abbildung 7.17 sieht man die Situation ohne Module und in Abbildung 7.18 mit einem Module und einem laufenden Thread. Dies erfüllt den Test /T0910/ : Abbildung 7.17.: Threadsituation ohne Module Abbildung 7.18.: Threadsituation mit Modulen 2 siehe Module 5.11, welches von Runnable erbt 91

98 Resultate Test Beschreibung Ergebnis T0910 Die Module sind als unabhängige Threads entwickelt. Tabelle 7.10.: Resultate - Module sind unabhängige Threads Data-Container Tests Mit dem Modul Test aus Kapitel können alle Tests für den Data-Container ausgeführt werden. Resultate Test Beschreibung Ergebnis T1010 Das System stellt jedem Plugin einen Data-Container zur Verfügung. T1020 Der Container beinhaltet key-value-paare. T1030 Die Dateien werden in einem Ordner als XML abgelegt. T1040 Die Dateien werden beim Beenden des Programms geschrieben. Tabelle 7.11.: Resultate - Data-Container 92

99 DB-Container Tests Mit dem Modul Test aus Kapitel können alle Tests für den DB-Container ausgeführt werden. Resultate Test Beschreibung Ergebnis T1110 Das System stellt jedem Modul einen DB-Container zur Verfügung. T1120 Der Container ist leer und wird vom Modul vollständig verwaltet. T1130 Die Dateien werden in einem Ordner als DB-Datei abgelegt. T1140 Das System ist nur für die Verbindung zwischen Modul und DB- Container zuständig. Tabelle 7.12.: Resultate - DB-Container Modul MusicPlayer Tests In Abbildung 7.19 ist links die Aktion ersichtlich und rechts der Dateiauswahldialog. Wird eine Datei oder ein Ordner ausgewählt, wird der Inhalt der Wiedergabeliste hinzugefügt. Dies erfüllt den Test /T1210/ : Abbildung 7.19.: Musikdatei oder -verzeichnis öffnen 93

100 Die Abbildung 7.20 zeigt den Test /T1220/ : Abbildung 7.20.: Musikwiedergabe starten Abbildung 7.21 zeigt den Test /T1230/ : Abbildung 7.21.: Musikwiedergabe beenden Die Abbildung 7.22 zeigt den Test /T1240/ : Abbildung 7.22.: Vorherige Musikdatei abspielen 94

101 Die Abbildung 7.23 zeigt den Test /T1250/ : Abbildung 7.23.: Nächste Musikdatei abspielen Im Listing 7.5 ist der Eintrag zum Erfüllen von Test /T1260/ ersichtlich: Listing 7.5: Verzeichnis oder Datei im TDA für MusicPlayer 1 <entry> 2 <key>key. d i r e c t o r y </key> 3 <value >/Volumes/ audio / music / Pink Floyd</value> 4 </entry> Resultate Test Beschreibung Ergebnis T1210 Der MusicPlayer kann einzelne Dateien oder ganze Verzeichnisse öffnen. T1220 Der MusicPlayer verfügt über die Funktion Start zum starten des Abspielen der Dateien. T1230 Der MusicPlayer verfügt über die Funktion Stop zum stoppen des Abspielen der Dateien. T1240 Der MusicPlayer verfügt über die Funktion Zurück zum Abspielen der vorherigen Datei. T1250 Der MusicPlayer verfügt über die Funktion Vor zum Abspielen der nächsten Datei. T1260 Das zuletzt verwendete Verzeichnis oder Datei wird im Data- Container abgelegt. Tabelle 7.13.: Resultate - Modul MusicPlayer 95

102 Modul Scrambler Tests In Abbildung 7.24 ist links die Aktion ersichtlich und rechts der Verschlüsselungsdialog. Dies erfüllt den Test /T1310/ : Abbildung 7.24.: Dateien verschlüsseln In Abbildung 7.25 ist links die Aktion ersichtlich und rechts der Entschlüsselungsdialog. Dies erfüllt den Test /T1320/ : Abbildung 7.25.: Dateien entschlüsseln 96

103 Abbildung 7.26 zeigt den Test /T1330/ : Abbildung 7.26.: Implementierte Codes Im Listing 7.6 ist der Eintrag zum Erfüllen von Test /T1340/ ersichtlich: Listing 7.6: Input- und Output-Verschlüsselungsdateien im TDA für Scrambler 1 <entry> 2 <key>key. scramble. input </key> 3 <value >/Users / s l a u b e n b e r g e r /Dropbox/ School / S e m e s t e r a r b e i t / t y r / r e l e a s e / base / 4 tyr app. j a r </value> 5 </entry> 6 <entry> 7 <key>key. scramble. output </key> 8 <value >/Users / s l a u b e n b e r g e r / Desktop / tyr app. j a r. enc </value> 9 </entry> Im Listing 7.7 ist der Eintrag zum Erfüllen von Test /T1350/ ersichtlich: Listing 7.7: Input- und Output-Entschlüsselungsdatei im TDA für Scrambler 1 <entry> 2 <key>key. unscramble. input </key> 3 <value >/Users / s l a u b e n b e r g e r / Desktop / tyr app. j a r. enc </value> 4 </entry> 5 <entry> 6 <key>key. unscramble. output </key> 7 <value >/Users / s l a u b e n b e r g e r / Desktop / tyr app. j a r </value> 8 </entry> 97