Sie sind auf Seite 1von 128

Beuth Hochschule fr Technik Berlin University of Applied Sciences Erstgutachter: Prof. Dr. Edlich Zweitgutachter : Prof. Dr.

Solymosi

Entwurf und Entwicklung einer universellen Softwareentwicklungsumgebung in der Cloud

Masterarbeit eingereicht von Charles Bourasseau Matrikelnummer: 778447 Fachsemester: 4 Kunigundenstrae 1 (II) 12105 Berlin Abgabetermin: 03.09.2012

Danksagung

Als erstes mchte ich mich bei Herrn Prof. Dr. Edlich von der Beuth Hochschule fr Technik Berlin fr die Vorlesungen im Bereich Cloud-Computing sowie fr die uerst hilfreiche und durchgehend untersttzende Betreuung dieser Arbeit herzlich bedanken. Ohne ihn wrde diese Arbeit nicht in dieser Qualitt bestehen. Ebenfalls bedanken mchte ich mich bei Herrn Prof. Dr. Solymosi von der Beuth Hochschule fr Technik Berlin fr die Betreuung des Projektes. Auch mchte ich mich fr die Hilfe, die mir nicht nur whrend dieser Arbeit, sondern whrend des gesamten Studiums seitens der Studienverwaltung sowie der Sekretariate im Fachbereichs VI der Beuth Hochschule fr Technik Berlin zuteilwurde, bedanken. Beide Entitten waren immer bereit mir zu helfen oder mich an weitere Kontakte zu vermitteln. Weiterhin danke ich auch Julia Bauer, Jenny F. Schneider sowie Roman Preuss fr deren Hilfeleistungen, Ratschlge und Kritik, die mir fr diese Arbeit sehr geholfen haben. Nicht zuletzt gilt mein Dank meinen Freunden und meiner Familie fr ihre moralische Untersttzung whrend der Masterarbeit sowie des Studiums insgesamt.

Charles Bourasseau Berlin, September 2012

Diese Arbeit ist urheberrechtlich geschtzt. 2012 Charles Bourasseau Das Projekt, das im Rahmen dieser Arbeit produziert wurde, ist unter der Lizenz GNU General Public License Version 3 frei verfgbar. Einige Softwares, die in dieser Arbeit benutzt wurden, unterliegen teilweise anderen Lizenzen. Kontakt zum Autor ber E-Mail: charles.bourasseau@gmail.com Die aktuelle Version der Software befindet sich auf der CD, die dieser Arbeit beiliegt, im Ordner Repository. Der Inhalt der CD befindet sich unter diese URL: http://bit.ly/masterarbeit-bourasseau-cdrom-zip Das Video befindet sich unter dieser URL: http://bit.ly/masterarbeit-bourasseau-video Die Masterarbeit befindet sich als PDF unter dieser URL: http://bit.ly/masterarbeit-bourasseau-pdf

Inhaltsverzeichnis 1. Einleitung ...................................................................................................................................................... 1 1.1 Problemstellung ................................................................................................................................... 2 1.2 Zielstellung ........................................................................................................................................... 3 2. Aufgabenstellung .......................................................................................................................................... 4 2.1 Konzept ................................................................................................................................................ 4 2.2 Software-Design ................................................................................................................................... 5 2.3 Benutzeroberflchen-Design ................................................................................................................ 5 2.4 Implementierung.................................................................................................................................. 6 2.5 Test.................................................................................................................................................... 7 2.6 Zusammenfassung................................................................................................................................ 8 3. Fachliches Umfeld ......................................................................................................................................... 9 3.1 IDE-Grundlagen .................................................................................................................................... 9 3.1.1 Geschichte ................................................................................................................................. 9 3.1.2 Aktuelle Lsungen ...................................................................................................................... 9 3.1.3 Typische Funktionalitten ........................................................................................................ 10 3.2 Grundlagen des Cloud-Computing ...................................................................................................... 11 3.2.1 Definition ................................................................................................................................. 12 3.2.2 Geschichte ............................................................................................................................... 12 3.2.3 Aktuelle Einsatz ........................................................................................................................ 13 3.3 Auswertung des Cloud-Software-Editors ............................................................................................ 13 3.3.1 Kriterien ................................................................................................................................... 13 3.3.2 Cloud9 ..................................................................................................................................... 14 3.3.3 Koding...................................................................................................................................... 16 3.3.4 ShiftEdit ................................................................................................................................... 17 3.3.5 CodeRun .................................................................................................................................. 18 3.3.6 Codeanywhere ......................................................................................................................... 19 3.3.7 GoinCloud ................................................................................................................................ 20 3.3.8 EXo Cloud IDE .......................................................................................................................... 21 3.4 Zusammenfassung.............................................................................................................................. 22 4. Pflichtenheft ............................................................................................................................................... 23 4.1 Zielbestimmung .................................................................................................................................. 23 4.1.1 Musskriterien ........................................................................................................................... 23 4.1.2 Sollkriterien ............................................................................................................................. 24 4.1.3 Kannkriterien ........................................................................................................................... 25 4.1.4 Abgrenzungskriterien ............................................................................................................... 26 4.2 Produkteinsatz ................................................................................................................................... 26 4.2.1 Anwendungsbereiche .............................................................................................................. 26

4.2.2 Zielgruppen .............................................................................................................................. 26 4.2.3 Betriebsbedingungen ............................................................................................................... 27 4.3 Produkt .............................................................................................................................................. 27 4.3.1 Produktbersicht ..................................................................................................................... 27 4.3.2 Produktfunktionen ................................................................................................................... 27 4.3.3 Produktdaten ........................................................................................................................... 31 4.3.4 Produktleistungen .................................................................................................................... 32 4.4 Qualittsanforderungen ..................................................................................................................... 33 4.5 Benutzeroberflche ............................................................................................................................ 34 4.6 Technische Produktumgebung ........................................................................................................... 36 4.6.1 Software .................................................................................................................................. 36 4.6.2 Hardware ................................................................................................................................. 36 4.6.3 Entwicklungsschnittstellen ....................................................................................................... 37 4.7 Zusammenfassung.............................................................................................................................. 37 5. Systementwurf............................................................................................................................................ 38 5.1 Architektur ......................................................................................................................................... 38 5.1.1 Globale Architektur .................................................................................................................. 38 5.1.2 Server-Architektur ................................................................................................................... 40 5.1.3 Client-Architektur .................................................................................................................... 43 5.2 Datenbank-Schema ............................................................................................................................ 45 5.3 Zusammenfassung.............................................................................................................................. 46 6. Realisierung ................................................................................................................................................ 47 6.1 Programmiersprachen ........................................................................................................................ 47 6.1.1 Client ....................................................................................................................................... 47 6.1.2 Server ...................................................................................................................................... 47 6.1.3 Datenbank ............................................................................................................................... 53 6.2 Bibliotheken ....................................................................................................................................... 54 6.2.1 Client ....................................................................................................................................... 54 6.2.2 Server ...................................................................................................................................... 57 6.3 Dokumentation .................................................................................................................................. 63 6.4 Zusammenfassung.............................................................................................................................. 63 7. Test ............................................................................................................................................................. 65 7.1 Servertests ......................................................................................................................................... 65 7.2 Browsertests ...................................................................................................................................... 67 7.3 Zusammenfassung.............................................................................................................................. 69 8. Ergebnisse................................................................................................................................................... 70 8.1 Bestehende Probleme ........................................................................................................................ 71 8.1.1 Ajax vs. Socket ......................................................................................................................... 71 8.1.2 Zugriff auf die Festplatte .......................................................................................................... 72

8.1.3 Abhngigkeit von Amazon ........................................................................................................ 73 8.2 Positiver Aspekt.................................................................................................................................. 74 8.2.1 JavaScript als Programmiersprache .......................................................................................... 75 8.2.2 Tests ........................................................................................................................................ 75 8.3 Zusammenfassung.............................................................................................................................. 75 9. Zusammenfassung ...................................................................................................................................... 76 9.1 Zuknftige Mglichkeiten ................................................................................................................... 78 10. Abkrzungsverzeichnis ................................................................................................................................ 80 11. Literaturverzeichnis .................................................................................................................................... 81 12. Anhang ....................................................................................................................................................... 84

Abbildungsverzeichnis

Abbildung 1 Anteil der Internetnutzer in Deutschland von 2001 bis 2011 ............................................. 1 Abbildung 2 Vereinfachtes Schema des Projektes ................................................................................. 3 Abbildung 3 Beispiel eines Wireframes .................................................................................................. 4 Abbildung 4 Google Trends zum Wort Cloud-Computing zwischen 2004 und 2012 ............................ 11 Abbildung 5 Werbekampagne von Microsoft Cloud vs. Claude ........................................................ 12 Abbildung 6 Cloud9-Logo ..................................................................................................................... 14 Abbildung 7 Koding-Logo ..................................................................................................................... 16 Abbildung 8 ShiftEdit-Logo ................................................................................................................... 17 Abbildung 9 CodeRun-Logo .................................................................................................................. 18 Abbildung 10 Codeanywhere-Logo ...................................................................................................... 19 Abbildung 11 GoinCloud-Logo.............................................................................................................. 20 Abbildung 12 eXo Cloud-IDE-Logo ........................................................................................................ 21 Abbildung 13 Allgemeine Erklrung des Prototyps .............................................................................. 35 Abbildung 14 Client-Server-Architektur ............................................................................................... 38 Abbildung 15 Globale Architektur des Projektes .................................................................................. 39 Abbildung 16 Server-Architektur .......................................................................................................... 40 Abbildung 17 Entitten-Klassen ........................................................................................................... 41 Abbildung 18 Connector-Vererbung .................................................................................................... 41 Abbildung 19 SSHFS-Beispiel ................................................................................................................ 42 Abbildung 20 Festplatten-Zugriff-Klassen ............................................................................................ 43 Abbildung 21 Software-Installation-Klasse ........................................................................................... 43 Abbildung 22 Clientseitige Architektur-Controllers und Views ............................................................ 44 Abbildung 23 Entity-Relationship-Model ............................................................................................. 45 Abbildung 24 Stellung des Nuage-Servers ............................................................................................ 48 Abbildung 25 SSHFS mit zwei Servern .................................................................................................. 60 Abbildung 26 Fs2http-Beispiel-Anfrage ................................................................................................ 61 Abbildung 27 Dateibaum vs. Projektansicht ......................................................................................... 71 Abbildung 28 Beispiel eines Tree-Panels .............................................................................................. 72

Tabellenverzeichnis

Tabelle 1 Vor- und Nachteile von Cloud9 ............................................................................................. 15 Tabelle 2 Vor- und Nachteile von Koding ............................................................................................. 16 Tabelle 3 Vor- und Nachteile von ShiftEdit ........................................................................................... 17 Tabelle 4 Vor- und Nachteile von CodeRun .......................................................................................... 18 Tabelle 5 Vor- und Nachteile von Codeanywhere ................................................................................ 19 Tabelle 6 Vor- und Nachteile von GoinCloud ....................................................................................... 20 Tabelle 7 Vor- und Nachteile von eXo Cloud IDE .................................................................................. 21 Tabelle 8 Qualittsanforderungen ....................................................................................................... 34 Tabelle 9 Struktur des Mens............................................................................................................... 36 Tabelle 10 Vor- und Nachteile von Python ........................................................................................... 50 Tabelle 11 Vor- und Nachteile von PHP ................................................................................................ 50 Tabelle 12 Vor- und Nachteile von Java ............................................................................................... 51 Tabelle 13 Vor- und Nachteile von JavaScript ...................................................................................... 51 Tabelle 14 Hufigkeit der Node.js-Updates .......................................................................................... 53 Tabelle 15 Vor- und Nachteile von MySQL ........................................................................................... 53 Tabelle 16 Vor- und Nachteile von MongoDB ...................................................................................... 54 Tabelle 17 Vor- und Nachteile von jQuery ........................................................................................... 55 Tabelle 18 Vor- und Nachteile von Yahoo! UI....................................................................................... 55 Tabelle 19 Vor- und Nachteile von ExtJS .............................................................................................. 56 Tabelle 20 Vor- und Nachteile von Dhtmlx ........................................................................................... 57 Tabelle 21 Servertest-Cases ................................................................................................................. 67 Tabelle 22 Browsertest-Cases .............................................................................................................. 69 Tabelle 23 Bearbeitungsstand der Musskriterien ................................................................................. 70 Tabelle 24 Bearbeitungsstand der Sollkriterien ................................................................................... 70 Tabelle 25 Bearbeitungsstand der Kannkriterien ................................................................................. 70 Tabelle 26 Bearbeitungsstand der Extrakriterien ................................................................................. 71

Listingverzeichnis

Listing 1 Synchrone HTTP-Anfrage ....................................................................................................... 49 Listing 2 Asynchrone HTTP-Anfrage ..................................................................................................... 49 Listing 3 Verbesserte asynchrone HTTP-Anfrage .................................................................................. 52 Listing 4 Fs2http-Konfiguration ............................................................................................................ 60 Listing 5 Erweiterte Fs2http-Konfiguration .......................................................................................... 62 Listing 6 Dox-Kommentar-Beispiel ....................................................................................................... 62 Listing 7 Markdox-Beispiel ................................................................................................................... 63 Listing 8 Vows-Beispiel ......................................................................................................................... 66 Listing 9 Beispiel-Ausfhrung von Tests ............................................................................................... 66 Listing 10 CasperJS-Beispiel .................................................................................................................. 68 Listing 11 CasperJS-Screenshot-Beispiel ............................................................................................... 69 Listing 12 Lschen-Funktion ................................................................................................................. 73

1. Einleitung
Das aus dem Englischen stammende Wort Cloud, zu Deutsch Wolke, bezeichnet einen Bereich der Informatik, der unsere Welt grundlegend verndert hat und auch zuknftig noch weiter beeinflussen wird. Der Name dieser Technik weckt in uns die Vorstellung realer Wolken. Diese groen Wasserreservoirs, deren Entstehungs- und Abregungsprozesse nicht vom Menschen beeinflusst werden knnen, sind Bestandteil und gewissermaen auch Grundlage unseres tglichen Lebens. Das Prinzip der Cloud bezieht sich auf eben dieses Bild der stndigen Verfgbarkeit und Autonomie, auch wenn es sich in der Informatik um Daten handelt, und nicht um Wassermolekle. Die in der Datenwolke gespeicherten Daten stehen einer Person folglich immer und berall online zur Verfgung. Das Cloud-Computing ist eine Reaktion auf die weltweit steigende Internetnutzung, auf die die Informatik zu reagieren versucht. In Deutschland beispielsweise ist die Anzahl der Internetnutzer von 37 Prozent der Bevlkerung im Jahr 2001 auf etwa 75 Prozent im Jahr 2011 gestiegen (siehe Abbildung 1, vgl. Statista GmbH 2012). Gleichzeitig wuchs die Anzahl von internetfhigen Gerten: Neben Laptops besitzen immer mehr Menschen Smartphones, Tablets und andere Gerte. Steigende Nutzerzahlen sowie eine wachsende Anzahl internetfhiger Gerte bedeuten fr die Betreiber von Webseiten eine erhhte Nachfrage und damit ein steigender Bedarf an Ressourcen.

Abbildung 1 Anteil der Internetnutzer in Deutschland von 2001 bis 2011

Dieser hohe Anstieg der Internetnutzung stellt fr Webserver eine Herausforderung dar, denn jeder einzelne Computer verfgt nur ber eine begrenzte Kapazitt. Zu viele Nutzer lasten die Ressourcen eines Servers aus, sodass an diesen keine neuen Anfragen mehr gestellt werden knnen. Es gibt aber Methoden und Technologien, die diesem Problem Abhilfe schaffen, wie zum Beispiel die Methode der Skalierung. Statt einen einzigen Computer als Webserver zu verwenden, werden mehrere Maschinen verbunden und teilen sich die Aufgaben. Die Skalierung ist ein technisches Grundverfahren des IT-Bereichs Cloud-Computing. Mit Hilfe von Technologien wie der Virtualisierung wird das Management von Servern vereinfacht.

Das Cloud-Computing ist nicht nur die technische Antwort auf unser verndertes Nutzungsverhalten, es hat umgekehrt auch unsere Internetnutzung verndert. Software-As-A-Service (kurz: SaaS) findet inzwischen immer mehr Anwendung, sei es fr E-Mails, Texte, Dokumente, Fotos, Spiele usw. Fr fast jede Software gibt es inzwischen eine SaaS-Alternative. Die Mobilitt, die die Cloud dem Menschen ermglicht, ist eine der wichtigsten Eigenschaften des Cloud-Computing. Im Urlaub, auf Geschftsreise oder auf dem Weg zur Arbeit ist es uerst praktisch, wenn man immer ber die gleiche Software verfgt und dieselben Daten nutzen kann. Egal ob auf dem Handy, Laptop oder Tablet, dank der Cloud knnen die Arbeitsaufgaben von berall aus erledigt werden. Ist die Revolution des Cloud-Computing damit bereits an ihrem Ende angekommen und wurden alle denkbaren Grenzen erreicht und ausgereizt? Oder gibt es Applikationen, deren Umwandlung in eine Software-As-A-Service-Variante zu schwierig oder gar unmglich ist? Um Antworten auf diese Fragen zu geben, soll in der hier vorliegenden Arbeit eine Entwicklungssoftware in eine SaaS-Form umgewandelt werden, wie nachfolgend erlutert wird.

1.1 Problemstellung
Das Projekt, das in dieser Arbeit entwickelt wird, beschftigt sich mit einem speziellen Problem des Cloud-Computing, nmlich der Programmierung in der Cloud. Ohne die Cloud mssen Entwickler, die von unterwegs aus arbeiten oder ihre Ergebnisse Kunden prsentieren wollen, einen Laptop mit smtlicher Entwicklungssoftware mit sich fhren. Dies kann in bestimmten Situationen sehr umstndlich sein. Auerdem mssen manche Entwickler mit verschiedenen Versionen einer Sprache entwickeln knnen. Natrlich existieren dafr Version-Manager-Tools, wie zum Beispiel Rvm1 fr Ruby, aber die Nutzung solcher Programme ist mitunter kompliziert und setzt hufig nicht nur Kenntnisse in der Programmiersprache, sondern auch ber das Tool sowie das Betriebssystem voraus. Zudem erschwert eine klassische Software die Kollaboration. Dateien mssen zum Beispiel per E-Mail ausgetauscht werden und knnen verloren gehen. Auch hierfr existiert bestimmte Software, die sogenannten Version-Control-Systeme (VCS), wie zum Beispiel Git oder SVN. Fr die Nutzung solcher Programme bentigt man allerdings bestimmte Vorkenntnisse und die Software muss zuvor installiert werden. Ein weiteres Problem besteht darin, dass man andere Programme wie Webserver, Framework usw. installieren muss, um den Quellcode ausfhren zu knnen. Mit einem browserbasierten Software-Editor in der Cloud knnen alle eben beschriebenen Probleme gelst werden. Zum einen ist die Kollaboration in der Cloud vereinfacht, denn andere Mitarbeiter oder Kunden knnen eingeladen werden, um sich das Projekt anzuschauen oder davon teilzunehmen. Zum anderen ist keine Software-Installation mehr ntig. Des Weiteren knnen in der Cloud Daten viel einfacher dupliziert, geteilt oder modifiziert werden, weshalb kein Dateien-Management
1

Mehr Informationen zum Projekt unter https://rvm.io/ (Stand: 21.06.2012).

mehr erforderlich ist. Letztlich gehen mit einem browserbasierten Software-Editor keine Daten mehr verloren oder werden zerstrt.

1.2 Zielstellung
In dieser Arbeit soll ein Cloud-basierter Software-Editor entworfen und entwickelt werden. Das Projekt wurde Nuage" genannt, was Wolke auf Franzsisch bedeutet. Cloud-basiert bedeutet, dass keine Dateien heruntergeladen und gespeichert werden mssen und stattdessen alle Operationen auf einem Server laufen. Folgende Eigenschaften soll der Software-Editor erfllen: 1. Fr die Verwendung des Projektes soll ein Browser ausreichen. 2. Der Editor muss universell sein und keine Einschrnkungen bezglich der Programmiersprachen aufweisen. 3. Damit der Benutzer ber mehr Freiheit und Mobilitt verfgt, sollen smtliche Dateien auf einem Server gespeichert werden knnen. Eine browserbasierte Software besitzt gegenber herkmmlicher Software mehrere Vorteile. Sie bentigt lediglich eine Internetverbindung, weswegen man von berall aus, sei es im Restaurant oder auf dem Flughafen, weiterarbeiten kann und entsprechend Zeit spart. Auerdem kann man seinen Arbeitsplatz frei whlen und muss nicht mehr zwingend ins Bro gehen. Des Weiteren ist kein spezieller Computer, etwa mit hoher Rechenleistung oder ausreichend Speicherplatz, erforderlich. Um auf die eigenen Daten zugreifen zu knnen, braucht man sich nur online einzuloggen. Das ist insofern praktisch, als dass beim Kunden keine Software-Installation mehr vorzunehmen ist, um die Funktionsweise des Produktes bis ins Detail zeigen zu knnen (inklusive Quellcode und Server-Integration). Browserbasierte Applikationen sind mit Handys verwendbar. Diese Mglichkeit soll jedoch im Rahmen der Arbeit an dieser Stelle nur erwhnt, nicht aber dezidiert behandelt werden.

Abbildung 2 Vereinfachtes Schema des Projektes

Die Dateien sollen auf dem Server der Benutzer gespeichert werden. Dieser wird Entwicklungsserver genannt, weil dort die eigentliche Software entwickelt wird (siehe Abbildung 2). Das bedeutet, dass der Server des Editors ein Server-Management anbieten muss, damit die Benutzer die Entwicklungsserver verwalten knnen. Mit dem Server-Verwaltungsfeature ist es mglich, die Projekte oder Kunden auf verschiedene Server aufzuteilen. 3

2. Aufgabenstellung
Wie in der Einleitung besprochen, soll eine Software bzw. eine Webseite entwickelt werden, mit der programmiert werden kann. Weil es sich um ein Programmierungsprojekt handelt, wird nach dem klassischen Strukturplan fr eine solche Arbeit vorgegangen (vgl. Friedlein 2001, S. 4f.). Nachfolgend werden die dabei zu bearbeitenden Aufgaben genauer beschrieben.

2.1 Konzept
In der Projektkonzeption wird die Grundidee des Projektes entwickelt. An diesem Punkt stellt sich die Frage, was genau programmiert werden soll. Hauptfunktionalitten, die die Software am Ende des Projektes knnen soll, mssen zunchst geplant werden. In dieser Phase werden die technischen als auch die Software-Design-Probleme nur wenig beachtet. Trotzdem kann es vorkommen, dass Funktionalitten geplant werden, die sich spter als nicht umsetzbar herausstellen. Diese sollten so frh wie mglich entdeckt werden. Daher sollte eine grobe erste technische Prfung vorgenommen werden. Das Software-Design kann an spterer Stelle des Projektes erarbeitet werden. Die Konzeption des in dieser Arbeit realisierten Projektes wird nachfolgend im Kapitel Pflichtenheft (siehe S. 23) vorgestellt. Dort sind auch Use-Case-Diagramme zu finden. Zudem werden an dieser Stelle die Hauptfeatures des Projektes erklrt, d. h. hier findet sich eine Beschreibung dessen, was die Software alles knnen soll. Whrend der Konzeptionsphase wird ein Prototyp erstellt. Dieser enthlt die Grundstrukturen des Projektes und hilft dabei, einen berblick ber das Projekt zu gewinnen. Man spricht in diesem Zusammenhang auch von einem Wireframe-Prototypen. Ein Wireframe ist ein Schwarz-Wei-Schema, das die Struktur der Benutzeroberflche skizzenhaft zeigt. Somit ist sichergestellt, dass man sich in der Konzeption nicht in Details verliert, sondern sich auf die wesentlichen Inhalte, Ideen und Funktionen konzentriert (vgl. Snyder2003, S. 10). Abbildung 3 zeigt einen Ausschnitt eines WireframeBeispiels. Fr das Projekt der vorliegenden Masterarbeit wurden mehrere solcher Wireframes erstellt (siehe Anhang S. 115).

Abbildung 3 Beispiel eines Wireframes

2.2 Software-Design
Mit Hilfe des Pflichtenhefts soll die Software-Architektur entwickelt werden. Diese Phase ist sehr wichtig, weil auf ihr die Implementierung basiert. Alle geplanten Funktionen der Software, d. h. jegliche Anforderungen sowie alle Muss- und Kannkriterien mssen dafr beachtet werden. Auerdem sollte man sich auch ber die Zukunft der geplanten Software Gedanken machen. Die Entscheidungen, die in dieser Phase getroffen werden, haben Auswirkungen auf das gesamte Projekt. Das Treffen ungnstiger Entscheidungen, kann das dazu fhren, dass man spter grere nderungen an der Software vornehmen muss, was wiederum Zeit und Geld kostet. Es ist wichtig, dass das SoftwareDesign ausreichend Flexibilitt besitzt, damit weitere nderungen spter vorgenommen werden knnen (vgl. Budgen 2003, S. 57). In dieser Phase werden folgende Dokumente erstellt: Architektur-Design: Dank dieses Schemas kann man die grobe Architektur nachvollziehen. Es macht verstndlich, aus welchen Bestandteilen sich die Software zusammensetzt und wie die verschiedenen Teile der Software interagieren knnen. Es ist wichtig, dass eine Software sinnvoll strukturiert wird, damit man die Komplexitt der Implementierung reduziert. Klassendiagramm: Dieses Schema zeigt, wie die Software intern programmiert wird. Gewhnlich sind diese Diagramme mit Hilfe von UML gezeichnet. Dank dieses Standards kann jeder verstehen, wie die Software funktioniert, ohne dass man den gesamten Quellcode durchlesen muss. In diesem Schema werden Klassen, Benutzeroberflchen, Methoden, Eigenschaften usw. definiert. Wenn das Software-Design sich ndert, sollten auch die Dokumente dementsprechend aktualisiert werden.

Das Architektur-Design und das Klassendiagramm werden im Kapitel Systementwurf genauer erklrt (siehe S. 38).

2.3 Benutzeroberflchen-Design
In dieser Phase wird die visuelle Darstellung der Software entworfen und entwickelt. Laut der ISO/IEC 9126-1 umfasst der Begriff Usability folgende Kriterien (vgl. ISO/IEC 2001, S. 9f.): Verstndlichkeit (Understandability): Dieses Kriterium verlangt, dass alle Komponenten der Software einfach zu verstehen sein sollen. Der Nutzer kann demnach leicht erkennen, wie das Produkt funktioniert und wie er es anwenden knnte, um spezifische Aufgaben zu erledigen. Erlernbarkeit (Learnability): Dieser Begriff meint den Lernprozess, mit dem sich Nutzer die Software aneignen. Es geht um die Frage, wie schnell und wie einfach neue Nutzer in die Software einsteigen knnen. Wenn der Einstieg nicht leicht ist, dann besteht die Gefahr, dass Nutzer ein Angebot der Konkurrenz der eigenen Software vorziehen. Bedienbarkeit (Operability): Alle Komponenten des Produktes sollen ohne Schwierigkeiten bedient werden knnen. Attraktivitt (Attractiveness): Die Software muss optisch ansprechend sein, damit die Nutzungsmotivation steigt.

Usability-Konformitt (Usability Compliance): Die Usability-Konformitt einer Software sorgt dafr, dass die Nutzer schneller unbekannte Funktionen verstehen knnen. Es ist zum Beispiel wichtig, dass Farben konsequent verwendet werden.

Obwohl diese Phase, in der das Benutzeroberflchen-Design nach Usability-Kriterien entwickelt wird, fr den Erfolg eines Projektes zwingend notwendig ist, wird sie in dieser Arbeit nicht intensiv behandelt. Dennoch werden in der Projektentwicklung und Umsetzung, auf der der Schwerpunkt dieser Arbeit liegt, die Grundlagen des Benutzeroberflchen-Designs beachtet.

2.4 Implementierung
Die Implementierungsphase ist die Kernaufgabe eines Entwicklungsprojektes. Die Arbeit an dieser Aufgabe basiert auf dem Software-Design. Die getroffenen Entscheidungen des Software-Designs werden aufgenommen und umgesetzt. In der Regel wird die Programmierung anhand des Klassendiagramms, des Architektur-Designs, der Prototypen und des Pflichtenhefts realisiert. In dieser Phase geht es aber nicht allein um die Fertigstellung der Programmierung. Folgende weitere Etappen sind zudem notwendig: Auswahl der Sprache und Technologien: Vor Programmierungsbeginn muss man die Programmiersprache und Technologien der Software auswhlen. Unter Umstnden hngen diese von den Anforderungen oder der Architektur ab. Wenn sie bei der Implementierung jedoch frei gewhlt werden knnen, so sollten diese Entscheidungen ganz am Anfang der Phase getroffen werden. Bibliotheken und Framework-Recherche: Ein weiterer wesentlicher Punkt, zu Beginn der Projektphase, ist die umfassende Recherche nach Projekten, die man fr die eigene Software nutzen kann. Auf diese Weise kann die Entwicklung beschleunigt werden. Tool-Suche: Bevor man mit der Programmierung beginnt, sollte klar sein, mit welcher Software und welchen Tools gearbeitet wird. Datei-Editoren, Debugger-Tools und ProjektManagement-Tools gehren zu den wichtigsten Werkzeugen, die fr die Programmierung bentigt werden. Programmierung: Diese Etappe beinhaltet die Kernarbeit der Entwicklung, in der der Quellcode geschrieben wird. Verfassen der Dokumentation: Eine gute Software muss umfassend dokumentiert werden. Die Dokumentation erleichtert nicht nur die Weiterentwicklung, sondern auch die Benutzung des Programms. Sie umfasst verschiedene Formen z. B.: o Bedienungsanleitung: Die Bedienungsanleitung hilft neuen Nutzern beim Einstieg in die Software. o Kommentar im Quellcode: Dank der Kommentare im Quellcode werden komplexe Bestandteile der Software verstndlich erklrt. o Ticket: Ein Ticketsystem untersttzt das Bugs-Tracking und das Features-Listing.

Die Implementierung der in dieser Arbeit entwickelten webbasierten Software wird im Kapitel Realisierung (siehe S. 47) vorgestellt. An dieser Stelle werden die fr das Projekt verwendeten Sprachen, Technologien, Bibliotheken und Tools erlutert und begrndet. Die Bedienungsanleitung 6

befindet sich im Anhang (siehe Anhang S. 86) und der Quellcode wurde auf der beiliegenden CD dokumentiert (siehe Ordner Repository).

2.5 Test
Es gibt verschiedene Art und Weisen, eine Software zu testen. In der Testphase des Projektes kommt es darauf an, welche Ziele mit einem Test verfolgt werden. Vor Testbeginn sollte daher definiert werden, was genau erreicht werden soll. Folgende Ziele, die teilweise sehr unterschiedlich sind, knnen whrend der Testphase eines Projektes erreicht werden: Die Anzahl von Fehlern im Quellcode reduzieren. Die Benutzeroberflche verbessern. Die Performance sichern. Die Funktionalitten besttigen. nderungen im Quellcode beschleunigen.

Um die verschiedenen Ziele zu erreichen, stehen unterschiedliche Testformen zur Verfgung, die kurz erlutert werden sollen: Unit-Tests: Bei Unit-Tests wird mit Hilfe von Testklassen der Quellcode berprft. Ziel ist es, soviele einzelne Funktionen der Software wie nur mglich zu testen. Unit-Tests sollten einfach gehalten werden. Sie sollten sich zudem auf den Test der Methoden beschrnken und nicht die Interaktion zwischen Klassen oder Services einer Software testen (vgl. Hamill 2004, S. 1f.). Funktionelle Tests: Mit Hilfe der Dokumente, die whrend der Analyse sowie der SoftwareDesign-Phasen erstellt wurden, kann man funktionelle Tests entwickeln. Sie prfen, ob der Quellcode diese Dokumente korrekt umsetzt und ob sie richtig implementiert sind (vgl. Kaner/Falk/Nguyen 1999, S. 52). Integrationstests: Integrationstests berprfen, ob die Klassen oder Komponenten miteinander wie erwartet funktionieren. Diese Testform kann man als erweitere Form von UnitTests verstehen, weil sie die Interaktion zwischen Klassen testen. Usability-Tests: Usability-Tests sind mitunter sehr kostenintensiver. Sie werden von tatschlichen Nutzern ausgefhrt. Diese Testpersonen haben bestimmte Aufgaben zu erledigen. Die Idee ist dabei, dass man die Usability der Software extern prft (Dumas/Redish 1999, S. 22f.). Last-Tests: Mit Last-Tests kann die Performance einer Software evaluiert und getestet werden. Bezogen auf eine Webseite geht es zum Beispiel darum, wie vielen Nutzern der Server innerhalb weniger Sekunden antworten kann.

Fr die Testphase sind des Weiteren folgende Prozessfragen zu beantworten: Wann werden die Tests durchgefhrt? Wann werden die Tests korrigiert? Wer korrigiert die Tests? usw.

Es existieren spezielle Tools wie z. B. das kontinuierliche Integrations-System, die solche Prozessaufgaben erleichtern. Im Kapitel Test (siehe S. 65) werden die Tests des in dieser Arbeit entwickelten Projektes prsentiert. Es wird erklrt, welche Tests realisiert und welche weggelassen wurden. Auerdem werden die Test-Ergebnisse vorgestellt.

2.6 Zusammenfassung
In diesem Kapitel wurden die verschiedenen Schritte, die die Struktur dieser Arbeit bilden, erlutert. Es wurde aufgezeigt, dass die Aufgaben dieses Projektes nach und nach ausgefhrt werden und in den einzelnen Kapiteln dieser Arbeit vorgestellt werden. Diese Gliederung ist fr die Entwicklung des Produktes wichtig, weil das Projekt somit zeitlich und fachlich strukturiert wird. Fnf Phasen wurden vorgestellt: 1. In der Konzeptphase wurden die Ideen und Visionen fr das Produkt gesammelt und beschrieben. Dabei wird in dieser Phase zuerst untersucht, wie die konkurrente Software sich entwickelt hat. Die Vor- und Nachteile bereits existierender Produkte mssen herausgefunden werden. Anschlieend werden Use-Case-Diagramme und das Pflichtenheft produziert, um die Software detailliert zu beschreiben. 2. Das Software-Design ist dafr da, den zuknftigen Quellcode zu strukturieren. Anhand des Pflichtenheftes und der Use-Case-Diagramme wird entschieden, wie das Programm am besten aufgebaut sein sollte. 3. Whrend der Benutzeroberflchen-Design-Phase muss die GUI des Produktes produziert werden. 4. In der Implementierungsphase wird der Quellcode produziert. Anhand dessen, was bis hierhin vorbereitet und erarbeitet wurde, muss die Software geschrieben werden. 5. Um zu prfen, dass die Implementierung die richtigen Ergebnisse ausgibt, muss das Projekt getestet werden. Dies geschieht whrend der Testphase. In dieser Phase werden nicht nur Tests fr das Produkt geschrieben, sondern diese mssen auch von Menschen durchgefhrt werden. Nachdem die Phasen des Projektes beschrieben wurden, widmet sich diese Arbeit der Einfhrung in die Thematik sowie der Untersuchung von Alternativlsungen.

3. Fachliches Umfeld
Bevor es um die Projektimplementierung geht, soll das sogenannte Fachliche Umfeld der Arbeit vorgestellt werden. Zuerst werden die Grundlagen von Software-Editoren sowie des CloudComputing vorgestellt. Dabei soll auf die Geschichte, Funktionalitten, Anbieter usw. genauer eingegangen werden. Anschlieend wird ein kurzer Vergleich von Cloud-Software-Editoren vorgenommen.

3.1 IDE-Grundlagen
Eine integrierte Entwicklungsumgebung (aus dem Engl.: integrated development environment, kurz: IDE) ist ein Texteditor, der die Entwicklung der Software untersttzt. Das Programm kann den Entwicklern unter anderem in den folgenden Bereichen helfen: Beschleunigung der Arbeit Fehlersuche Qualittsverbesserung Verschaffung eines besseren berblicks

Manche IDEs knnen verschiedene Programmiersprachen editieren; Eclipse, NetBeans, IntelliJ IDEA sind Beispiele dafr. Andere konzentrieren sich auf eine bestimmte Sprache wie zum Beispiel WebStorm (fr JavaScript und PHP), PHPEdit (fr PHP), PyDev (fr Python) usw. Editor-Programme werden oft durch Plug-ins erweitert. Diese werden von der Community erstellt, dabei knnen beispielsweise neue Funktionen hinzugefgt oder bereits existierende Funktionen erweitert werden.

3.1.1 Geschichte
Schon im Jahre 1975 wurde die erste integrierte Entwicklungsumgebung erstellt (vgl. Computerwoche.de, o.V. 1975). Diese Technologie wurde von Softlab Munich, Maestro I genannt, entwickelt. Es handelte sich dabei damals um einen groen Erfolg und die IDE wurde weltweit, insbesondere in die USA, exportiert (vgl. Spiegel.de, o.V. 1983). Maestro I hatte zwar wenig zu tun mit den Editoren, wie man sie heutzutage kennt, trotzdem war es fr jene Zeit ein groer Schritt. Im Jahre 1990 wurde Softbench von IBM prsentiert. Ziel dieses Editors war es, C, C++ und spter COBOL zu untersttzen. Softbench ist dafr bekannt, der erste Editor mit einem Plug-in-System, wie man es heute kennt, zu sein. Die Benutzer hatten die Mglichkeit, die Software so anzupassen, dass es genau den Anforderungen der Programmierer gerecht wurde (vgl. Lienhart 1997, S. 1ff).

3.1.2 Aktuelle Lsungen


Heutzutage existieren vielsprachige Multiplattform-Editoren. Diese ermglichen, dass Programmierer aus unterschiedlichen Bereichen die gleichen Tools nutzen knnen. Die Eigenschaften der Vielsprachigkeit und die Multiplattform-Mglichkeit sind natrlich von Vorteil. Der Editor wird von einer greren Anwendergruppe benutzt, wodurch Bug-Reports, Bug-Fixings, Plug-ins und Programmierungen schnell durchgefhrt werden knnen. Die heute bekanntesten IDEs sind unter anderem Eclipse, Net9

beans, Xcode und IntelliJ IDEA. Textmate, SublimeText, Vim und Emacs sind zwar auch sehr beliebt, gehren aber eher in der Kategorie der Texteditoren als in die einer integrierten Entwicklungsumgebung. Eine IDE bietet mehr Funktionen als ein Texteditor (siehe nchster Abschnitt "Typische Funktionalitten"). Beide sind nicht voneinander abgrenzbar, weil ein Editor mit Hilfe von Plug-ins die gleichen Features wie eine IDE besitzen kann.

3.1.3 Typische Funktionalitten


Man findet in einer IDE fast immer die gleichen Hauptfunktionalitten (vgl. Makarov 2009): Syntax-Highlighting: Diese Funktionalitt ist fr die IDE ein Musskriterium. Der Quellcode wird entsprechend der Programmiersprache gefrbt. Die Lesbarkeit wird dadurch verbessert. Plug-ins: Wie bereits erwhnt, bietet ein Plug-in-System die Mglichkeit, den Editor ohne groen Aufwand weiterzuentwickeln. Kleine Softwareanteile knnen geschrieben und in die IDE eingebunden werden. Dadurch werden neue Funktionen geschaffen. Autocomplete: Diese Funktion wird auch Code-Completion genannt und gibt whrend der Programmierung Vorschlge. Wenn der Programmierer beginnt, ein Wort zu schreiben, wird der Editor das mgliche Ende suchen und dieses dem Benutzer vorschlagen. Auerdem ist wichtig, dass die Code-Completion auch den Quellcode der Programmierer analysiert und damit alle mglichen Vorschlge anbietet. Navigation: Wenn man eine Klasse programmiert, muss man oft zu Methoden oder anderen Klassen springen. Manche IDEs bieten die Mglichkeit, per Klick- und/oder Tastenkombinationen zu einer bestimmten Klasse oder Methode zu springen. Dafr muss die IDE den Quellcode analysieren und indexieren. Dann wei der Editor, in welcher Datei sich welche Teile der Software befinden. Damit ist es dann mglich, von A nach B zu springen. Fehler- und Warnungs-Highlighting: In der Entwicklungsphase kommt es hufig vor, dass Zeichen vergessen werden, wie beispielweise das Semikolon. Das Fehler- und WarnungsHighlighting ist dafr da, solche Fehler sofort sichtbar zu machen. Hierbei wird auch der Quellcode analysiert und die Syntax geprft. Wenn Fehler gefunden werden, wird der Benutzer darber informiert. Fr die Analyse kann man beispielweise den Quellcode einfach kompilieren. Refactoring und Code-Generation: Wenn der Quellcode veraltet oder schlecht implementiert wurde, muss man ihn umbauen. Diese Aufgabe nennt sich Refactoring (vgl. Fowler 2000, S. xviii). Dabei kann man dank einer Analyse der Software auch dem Programmierer helfen. Will man beispielsweise eine Klasse umbenennen, wird der Editor alle Stellen finden, an denen sich der Name der Klasse befindet und durch einen neuen Namen ersetzen. Debugging: Debug-Funktionen helfen bei der Fehlersuche. Im Debug-Mode kann der Programmierer Breakpoints im Quellcode setzen. An diesen Stellen wird die Ausfhrung der Software gestoppt. Es ist dann mglich, die Variablen der Prozesse zu sehen und die Ausfhrung Schritt fr Schritt weiterzuverfolgen und durchzufhren. Integration von anderen Softwares: IaaS, PaaS, SaaS, Version-Control-Systems, Dokumentation, Datenbank usw. sind Systeme und Softwares, die man gern in die IDE integrieren mchte. Diese Funktionalitten werden oft mit Hilfe von Plug-ins geschaffen. Suche: Die Suche- und Suche-und-Ersetzen-Funktion in Software-Editoren tragen wesentlich dazu bei, das Durchsuchen von Texten zu vereinfacheren. 10

Manche Funktionen sind trivial und knnen problemlos implementiert werden. Syntax-Highlighting und die Suchfunktion knnen ohne oder bereits mit einer kleinen Analyse des Quellcodes durchgefhrt werden. Andere Features wie Code-Completion und Refactoring bentigen eine ausfhrliche Analyse der Software, deswegen sind sie schwieriger zu implementieren. Schlielich sind Plattformund sprachenspezifische Funktionen noch aufwendiger zu implementieren.

3.2 Grundlagen des Cloud-Computing


Cloud-Computing ist heutzutage ein wichtiger Bereich der Informatikbranche. Dank Cloud-Computing wird nicht nur die Mobilitt verbessert, sondern es knnen zudem groe Datenmengen gespeichert werden, die einer Vielzahl von Benutzern zugnglich sind. Seit 2007 taucht der Begriff CloudComputing laut Google (vgl. Google Trends 2012) immer hufiger in den Suchanfragen auf. Die Abbildung 4 stammt aus Google Trends und zeigt zwei Tendenzen. Die obere Kurve zeigt die weltweite Hufigkeit der Begriffssuche Cloud-Computing im Verlauf der letzten Jahre. Die untere Kurve zeigt die Anzahl von Artikeln in Google News, die den Begriff Cloud-Computing beinhalten. Es wird deutlich, wie sehr das Interesse dafr zugenommen hat.

Abbildung 4 Google Trends zum Wort Cloud-Computing zwischen 2004 und 2012

Seit 2007 steigen beide Kurven, davor war laut Google die Menge an Informationen zu gering, um bewertet zu werden. Diese Abbildung zeigt, dass der Bereich des Cloud-Computings immer wichtiger wird. Im Jahre 2011 hat Microsoft eine Werbekampagne zum Thema Cloud-Computing gestartet. Zielgruppe sind nicht nur Fachleute, sondern auch alle anderen Benutzer. Die Idee der Kampagne ist ein Vergleich zwischen Cloud (Cloud-Computing) und Claude (eine fiktive Figur, humorvoll dargestellt).

11

Abbildung 5 Werbekampagne von Microsoft Cloud vs. Claude

Mit diversen Werbungen (z. B. siehe Abbildung 5) will Microsoft seine Cloud-Computing-Produkte bekannt machen. Cloud-Computing ist also nicht nur eine technische Verbesserung, sondern auch eine neue Mglichkeit fr Nichtfachleute.

3.2.1 Definition
Es gibt noch keine offizielle Definition fr den Begriff Cloud-Computing. Schriftsteller und Wissenschaftler sind jedoch bereits darum bemht, eine geeignete Definition zu erarbeiten. CloudComputing nutzt die Virtualisierung von Ressourcen, um elektronische Dienste anzubieten. Eine Definition knnte wie folgt lauten (Baun/Kunze/Nimis 2011, S. 4): "Unter Ausnutzung virtualisierter Rechen- und Speicherressourcen und moderner Web-Technologien stellt Cloud-Computing skalierbare, netzwerk-zentrierte, abstrahierte IT-Infrastrukturen, Plattformen und Anwendungen als on-demand Dienste zur Verfgung. Die Abrechnung dieser Dienste erfolgt nutzungsabhngig." Cloud-Computing ist also eine neue Methode, um elektronische Ressourcen anzubieten. Doch die Idee vom Cloud-Computing existiert schon seit langem.

3.2.2 Geschichte
Schon Anfang der 60er Jahre sagte John McCarthy, ein Informatiker und Erfinder der Programmiersprache Lisp, dass computation may someday be organized as a public utility (Wang/Ranjan/Chen 2011, S. 5). 1966 schrieb Douglas Parkhill in seinem Buch The Challenge of the Computer Utility, dass mit Computer-Dienstprogrammen hnlich wie mit Gas, Strom und Wasser verfahren werden sollte: vom Staat betrieben und von der Bevlkerung benutzt. Ideen und Konzepte fr das Cloud-Computing waren in den 60er Jahre bereits vorhanden. Die technologischen Mglichkeiten und den Bedarf gab es damals aber noch nicht. Richtig angefangen hat Cloud-Computing erst 2000 mit dem Begriff Software-as-a-Service (kurz: SaaS) (SIIA 2001, S. 4). 12

Im Jahre 2002 startete Amazon, heute einer der wichtigsten Akteure im Cloud-Computing, seine bekannten Amazon-Web-Services (AWS). 2006 wurde Amazon-EC2 fr eine ffentliche Betaversion geffnet. 2010 hat die National Aeronautics and Space Administration (NASA) und Rackspace Hosting, OpenStack publiziert. OpenStack ist ein Infrastructure-as-a-Service (IaaS) Projekt, was mit Hilfe dreier Komponenten (Compute, Object-Storage und Image-Service) eine Open-Source-Cloud bietet.

3.2.3 Aktuelle Einsatz


Amazon-EC2
Amazon-EC2 ist ein Teil des AWS-Angebots von Amazon. Der bekannte Webshop ist mit diesem Produkt seit 2006 offiziell auf dem Markt. Seit dem 10. November 2010 wird der ganze Amazon.com Webshop von EC2 gehostet (AmazonWebServices 2011).

Rackspace
Rackspace wurde im Jahre 1996 gegrndet und ist einer der grten Konkurrenten von EC2. Laut der Webseite von Rackspace (vgl. Rackspace 2012) arbeiten ber 180 000 Unternehmen mit Rackspace.

OpenStack
Wie bereits im Abschnitt Geschichte (siehe Abschnitt 3.2.2 S. 12) erwhnt, wurde OpenStack von Rackspace und der NASA 2010 verffentlicht. OpenStack bietet gleichzeitig ein Open-Source-Projekt sowie Open-Standards. ber 170 Unternehmen sind in dieses Projekt involviert, wie zum Beispiel Dell, AMD, Intel, Cisco, Canonical, HP, NEC, Deutsche Telekom usw. Das Angebot vieler CloudAnbieter basiert darauf. Die Cloud-Computing-Angebote variieren heutzutage sehr. Manche Produkte, wie Rackspace und EC2, sind schon sehr bekannt und gut implementiert. Man sollte innovative Lsungen wie OpenStack jedoch nicht vergessen oder unterschtzen.

3.3 Auswertung des Cloud-Software-Editors


Dieser Vergleich wurde zwischen dem 25. und 28. April 2012 durchgefhrt und dient in erster Linie dazu, einen guten berblick ber die aktuell vorherrschenden Angebote zu geben. Die verschiedenen Cloud-IDEs knnen sich natrlich in Laufe der Zeit ndern.

3.3.1 Kriterien
Die Kriterien, mit denen die Cloud-IDE bewertet werden, sind die gleichen wie bei einer ganz gewhnlichen Softwarebewertung (vgl. Wheeler 2011). Nachfolgend werden die Kriterien kurz beschrieben und jedes betrachtetes Produkt danach bewertet. Anschlieend wird eine Vor- und Nachteilsliste erstellt, um den Vergleich deutlicher zu machen. Die Kosten werden bei diesem Vergleich jedoch nicht behandelt. 13

Funktionalitten: Untersucht wird, was die Software leisten kann und wie ntzlich die Features sind. Support: Dieses Kriterium bewertet, wie sich die Software in der Zukunft entwickeln wird. Zwei Punkte werden dabei untersucht: o Wie schnell werden Bugs entdeckt und korrigiert? o Wie oft werden neue Features implementiert? Performance: Wie schnell der Server antwortet, ist fr die Cloud-Software sehr wichtig. Man ist aufgrund der Desktopanwendungen an eine gewisse Geschwindigkeit gewhnt. Die Umstellung auf Cloud sollte keinen Nachteil der Leistung darstellen. Skalierbarkeit: Hier werden die folgenden beiden Fragen untersucht: o Wie gut skaliert die Plattform? o Sind die verwendeten Technologien gut skalierbar? Dieses Kriterium ist gerade fr Cloud-Anwendungen sehr relevant. Die Nutzer werden auf den gleichen Servern arbeiten. Wenn eine Skalierung nicht mglich ist, wird die Plattform sehr langsam bzw. nicht lauffhig.

Usability: Unter Usability sind mehrere Aspekte gefasst (vgl. U.S. Government s.d.): o Erlernbarkeit: Wie schnell knnen neue Nutzer die Software erlernen? o Effiziente Nutzung: Wie produktiv verwendet der angelernte Nutzer die Software? o Einprgsamkeit: Ist die Software konsequent aufgebaut? z. B. Haben alle grnen Knpfe die gleiche Funktion? o Fehlerhufigkeit und Ernsthaftigkeit: Ist die Software so aufgebaut, dass die Nutzer wenig Fehler machen? Wenn Fehler auftreten, wie ernsthaft sind diese? o Subjektive Zufriedenheit: Macht dem Nutzer das Programm Spa? Betrachtet werden besonders die zwei ersten Punkte: Erlernbarkeit und effiziente Nutzung. Flexibilitt/Anpassbarkeit: Die Flexibilitt misst inwiefern, die Software in ungeplanten Situationen reagiert. Ist sie agil genug, um sinnvoll zu funktionieren oder wird das Programm einen Fehler anzeigen bzw. blockieren. Unter Anpassbarkeit versteht man, inwieweit der Nutzer die Software anpassen kann. Ist es mglich und wie schwer ist es, neue Funktionalitten zu ndern oder hinzuzufgen? Interoperabilitt: Kann die Software mit anderen Programmen oder Systemen kommunizieren? Bei Cloud-Lsungen befinden sich die Daten nicht mehr auf dem Computer, sondern auf dem Server, welche dem Benutzer nicht gehren. Ohne ffentliche APIs kann die Software nicht mit anderen Produkten interagieren.

3.3.2 Cloud9

Abbildung 6 Cloud9-Logo

14

Cloud92 existiert seit 2010 und zielt hauptschlich auf die JavaScript-Entwicklung. Der Editor untersttzt 24 Programmiersprachen, aber nur Node.js ist in der Cloud ausfhrbar. Fr die anderen Sprachen muss man auf einem Server oder lokal den Repository auschecken. Hierbei helfen die Git- und Mercurial-Integration. Cloud9 enthlt einen Shell-Terminal, der allerdings aus Sicherheitsgrnden nicht alle Unix-Befehle enthlt. Dieses Shell-Terminal ist eigentlich nachgebaut und nur wenige Shell-Befehle wurden implementiert, z.B. cd, ls, rm, pwd, git, hg usw. Auerdem bietet Cloud9 Deployment-Funktionen, um die Software auf die Plattform-As-A ServiceAnbieter zu installieren. Vier Anbieter werden untersttzt: Joyent no.de, Heroku, Microsoft Azure und Cloud Foundry. Hinter Cloud9 steht ein Unternehmen, das den Editor entwickelt und verkauft. Trotzdem steht die komplette Software Open Source unter der GNU-GPL-Lizenz und befindet sich in Github (vgl. Cloud 9 2010). Das ist fr Bugfixing und die Entwicklung von Features natrlich optimal, da zwei unabhngige Entitten beteiligt sind: das Unternehmen und eine Community. Die Web-Anwendung verluft flssig und relativ schnell. Problematisch wird es, wenn man lngere Dateien editieren will. Das Kopieren und Einfgen mehrerer tausend Zeilen kann die Webseite blockieren. Cloud9 basiert auf Node.js. Laut dem Unternehmen kann der Editor horizontal skalieren (vgl. Hemel 2012). Das ist natrlich von Vorteil fr Cloud-Lsungen. Cloud9 ist einfach in der Bedienung. Viele Tastenkombinationen, die man von DesktopAnwendungen kennt, stehen zur Verfgung. Die Web-Anwendung ist wie ein ganz normaler Editor aufgebaut, wodurch der Einstieg sehr leicht ist. Der Editor ist mit einem Extension Manager ausgestattet, der die Installation der Plug-ins ermglicht. Zurzeit mssen Plug-ins erst auf dem Server installieret werden. Das bedeutet, dass man eine eigene Installation von Cloud9 vornehmen muss, um die gewnschten Plug-ins zu installieren. Vorteile Git, Mercurial, Github, Bitbucket Tastenkombinationen PaaS-Anbieter integriert (Joyent no.de, Heroku, Microsoft Azure, Cloud Foundry) 24 Programmiersprachen mit Highlighting Open Source3 Nachteile Nur Node.js ausfhrbar Keine vollstndige Shell-Terminal Keine gehostete Datenbank

Tabelle 1 Vor- und Nachteile von Cloud9

2 3

Mehr Informationen zum Projekt unter http://c9.io/ (Stand: 26.04.2012). Mehr Informationen zum Projekt unter https://github.com/ajaxorg/cloud9 (Stand: 26.04.2012).

15

3.3.3 Koding

Abbildung 7 Koding-Logo

Koding4 befindet sich immer noch in der Betaversion, frher hie der Editor Kodingen. Die Plattform bietet einen sozialen webbasierten Cloud-Editor. Ruby, Python Perl, PHP sowie Node.js sind bei Koding editierbar und ausfhrbar, es werden aber auch Standardsprachen wie HTML und CSS untersttzt. Koding hostet fr die Entwicklung auch Datenbanken. MongoDB, MySQL, SqLite und PostgreSQL werden untersttzt. Das Shell-Terminal wird in die Benutzeroberflche integriert, leider drfen Benutzer aus Sicherheitsgrnden keine Root-Rechte besitzen. Das kann insofern problematisch sein, wenn zum Beispiel besondere PHP-Plug-ins bentigt werden. Koding bietet die Mglichkeit, Open-Source-Projekte zu importieren, um schnell mit der Programmierung anfangen zu knnen. Das Koding-Team ist in sozialen Netzwerken wie Twitter sehr aktiv. Im Editor selbst ist zudem ein Forum integriert. Dort findet man Hilfe fr die Nutzung von Koding, aber auch Programmierungshilfe von der Community. Der Editor kann bis zu mehrere tausend Zeilendateien problemlos editieren. Beim Speichern wird er jedoch langsamer oder kann sogar zum Stillstand kommen. Zwar ist die Software im Vergleich zu hnlichen Editoren anders aufgebaut, dennoch scheint der Editor auch fr neue Benutzer einfach und verstndlich zu sein, weil er doch intuitiv bedienbar ist. Leider sind in der aktuellen Version von Koding keine Anpassungen mglich. Im Moment kann man FTP in Koding verknpfen. SVN, Git und Mercurial werden in der Endversion zur Verfgung stehen. Vorteile MongoDB und MySQL gehostet Community mit Code-Sharing, Forum usw. Shell-Terminal integriert Ruby, Python Perl, PHP, Node.js ausfhrbar App-Katalog mit Open-Source-Projekten Nachteile Nicht anpassbar Keine Sudo-Rechte in Shell-Terminal

Tabelle 2 Vor- und Nachteile von Koding

Mehr Informationen zum Projekt unter http://koding.com/ (Stand: 26.04.2012).

16

3.3.4 ShiftEdit

Abbildung 8 ShiftEdit-Logo

ShiftEdit5, entwickelt von ShiftCreate, ermglicht die Entwicklung im Browser durch das Verknpfen ber FTP und Dropbox. Das Ziel von ShiftEdit ist es, einen Editor zu erstellen, der mit Dropbox und FTP funktioniert. Wie bei Cloud9 kann man bis zu 24 Programmiersprachen editieren, leider besitzt der Editor keine Funktion fr die Ausfhrung von Programmen. ShiftEdit enthlt einen Real-Time-Syntax-Checker, der nach jedem neuen Buchstaben aufgerufen wird. Fr die Entwicklung ist dieses Feature eine gute Eigenschaft, weil viele Entwickler oftmals daran gewhnt sind, diese Funktion auf dem IDE-Desktop zu haben. ShiftEdit bietet nur mit SVN und keiner anderen Control-System-Version (VCS) wie Git oder Mercurial, eine Integration. Die Verknpfung mit dem Server kann nur ber Dropbox oder FTP laufen, diese Mglichkeiten sind sehr beschrnkt und nicht fr alle Unternehmen geeignet. Auerdem bietet ShiftEdit kein Shell-Terminal. Der Code ist zwar nicht Open Source, aber es existiert ein Bug-TrackingSystem, wo man ber Probleme und Bugs berichten kann. ShiftEdit ist wie ein gewhnlicher Editor aufgebaut, der Nutzer verliert sich nicht auf der Benutzeroberflche. Eine negative Eigenschaft gibt es jedoch: Zum Speichern muss man sich entweder mit Dropbox oder ein FTP verknpfen. Es ist nicht mglich, ohne diesen Vorgang zu programmieren. Man kann Code-Snippets speichern und wiederfinden. Es ist zudem mglich, Farben des Editors zu ndern. Auerdem untersttzt der Editor SVN, FTP und Dropbox. Fr den Beginn der Programmierung ist FTP oder Dropbox zwingend erforderlich. Vorteile Google/Facebook-Anmeldung FTP- und Dropbox-Support mit Unix-FilePermission Revision-Historie 24 Programmiersprachen mit Highlighting Real-time-Syntax-Errors SVN-Untersttzung Nachteile Kein anderes Version-Control-System auer SVN Keine Shell-Terminal Code nicht ausfhrbar Nur mit FTP oder Dropbox nutzbar

Tabelle 3 Vor- und Nachteile von ShiftEdit


5

Mehr Informationen zum Projekt unter http://shiftedit.net/ (Stand: 26.04.2012).

17

3.3.5 CodeRun

Abbildung 9 CodeRun-Logo

Das Ziel von CodeRun6 ist es hauptschlich, die Microsoft-Entwicklung in der Cloud zu erleichtern. CodeRun untersttzt viele Microsoft-Produkte und Programmiersprachen, wie C#, ASP.NET, WCF, Silverlight und WPF. Es kann aber auch in PHP, JavaScript oder CSS programmiert werden. Andere Sprachen, wie Ruby, Node.js oder Python sind nicht mglich. Ein Vorteil von CodeRun ist, dass es viele Template-Projekte gibt, um schnell in ein Thema einzusteigen. Jquery, Jquery-UI, Google-Maps, Chrome-Extension, Facebook-Connect, ASP, YUI, ExtJS sind Beispiele hierfr. Die Templates enthalten die notwendigen Dateien fr die Entwicklung und sie lassen sich einfach editieren, um sie weiterzuentwickeln. Der Quellcode kann mit dem Debugging-Tool und Break-Point untersucht werden. Die Software ist jedoch manchmal langsamer; wenn man die Anwendung ausprobieren will, muss man beispielweise einige Sekunden warten, bis man sie testen kann. CodeRun lsst sich gut bedienen. Die Web-Anwendung enthlt nicht sehr viele Features, daher bleiben die Mens klar und gut strukturiert. Es ist leider nicht mglich, den Editor anzupassen. Man kann keine Farben ndern, keine Plug-ins hinzufgen usw. Der Anpassbarkeitsgrad ist also sehr niedrig. Benutzer knnen den Quellcode herunterladen oder ihn mit Hilfe der URL in soziale Netzwerke oder per E-Mail verteilen. Vorteile Visual-Studio-Projekt-Import Code-Completion Debug mit Breakpoint Sharing per URL Nachteile Nur 6 Programmiersprachen werden untersttzt Keine Shell-Terminal Keine Control-System-Version Kein gehostete Datenbank

Tabelle 4 Vor- und Nachteile von CodeRun

Mehr Informationen zum Projekt unter http://coderun.com/ (Stand: 26.04.2012).

18

3.3.6 Codeanywhere

Abbildung 10 Codeanywhere-Logo

Seit 2011 entwickelt Ademptio das Produkt Codeanywhere 7, eine Cloud-IDE mit FTP- und DropboxVerknpfung. hnlich wie ShiftEdit untersttzt Codeanywhere FTP und Dropbox. Fnf Programmiersprachen werden untersttzt: HTML, PHP, JavaScript, CSS, und XML. PHP wird sogar auf dem Server von Codeanywhere ausgefhrt. Wenn man weder FTP noch Dropbox hat, kann man auch auf dem Server von Ademptio entwickeln. Mglich ist zudem die Entwicklung mit Git durch Github. Weiterhin bietet Ademptio Mobile-Anwendungen fr sein Produkt. iPhone, iPad, Android und Blackberry werden untersttzt und ermglichen es, die Entwicklung unterwegs durchzufhren. Auerdem wird fr Premium-Nutzer MySQL angeboten. Das Team von Codeanywhere antwortet gern ber soziale Netzwerke wie Twitter und Facebook. Der Editor wird regelmig aktualisiert. Die Verknpfung mit Github und Dropbox ist sehr leistungsfhig. Auch hier wird der Editor langsamer, wenn man mehrere tausend Zeilen in einer Datei bearbeitet. Manche Elemente der Benutzeroberflche fehlen. Beispielweise fehlt ein Men im oberen Bereich. Dennoch findet man die Funktionen, die man bentigt, z. B. mit Hilfe des Rechtsklicks. Vorteile FTP-Support (mit Unix-Rechte) und DropboxUntersttzung MySQL (nur fr Premium-Nutzer) Mobile-App (iPhone, iPad, Android, Blackberry) Nachteile Nur 6 Programmiersprachen untersttzt Keine Shell-Terminal Nicht anpassbar Keine Control-System-Version

Tabelle 5 Vor- und Nachteile von Codeanywhere

Mehr Informationen zum Projekt unter https://codeanywhere.net/ (Stand: 26.04.2012).

19

3.3.7 GoinCloud

Abbildung 11 GoinCloud-Logo

GoinCloud8 ist eine neue Cloud-IDE, die sich noch in der Betaversion befindet. Ziel von GoinCloud ist die Entwicklung von PHP-Projekten. Dennoch untersttzt es auch andere Programmiersprachen, wobei die genaue Liste untersttzter Sprachen auf der Webseite nicht auffindbar ist und daher unklar ist. Bei der Erstellung von Projekten kann man entscheiden, ob man Open-Source-Projekte wie Drupal, Wordpress, Magento usw. importieren mchte. Die Dateien werden dann automatisch kopiert und man kann nach wenigen Minuten mit dem Programmieren beginnen. Die Dateien knnen entweder auf dem Server von GoinCloud oder auf dem Server vom Benutzer mit Hilfe von SSH oder FTP gehostet werden. MySQL und PhpMyAdmin werden ebenfalls von GoinCloud gehostet. Es gibt im Moment leider keine anderen Datenbanken. GoinCloud ist noch relativ jung und sehr aktiv. Ein Forum ermglicht die Kommunikation zwischen Benutzer und Unternehmen. GoinCloud ist wie eine Desktop-Anwendung aufgebaut und fr neue Nutzer relativ einfach zu bedienen. Die reduzierte Anzahl von Features ermglicht eine einfache und klare Strukturierung der Mens. Farbe, Schriftgre und Schriftart sind anpassbar, darber hinaus bietet der Editor keine weiteren Anpassungsmglichkeiten. Vorteile FTP und SSH auf den GoinCloud-Server MySQL und PhpMyAdmin Importieren eigener Server Import von Open-Source-Projekten mglich Nachteile Shell-Terminal nicht im Browser integriert (zustzliche SSH-Clients notwendig) Version Control-System nur mit SSH Nur MySQL

Tabelle 6 Vor- und Nachteile von GoinCloud

Mehr Informationen zum Projekt unter http://goincloud.com/ (Stand: 26.04.2012).

20

3.3.8 EXo Cloud IDE

Abbildung 12 eXo Cloud-IDE-Logo

Die Firma eXo entwickelt den Editor eXo Cloud-IDE9 und versucht sich damit zwischen Entwickler und PaaS-Anbieter zu positionieren. eXo Cloud IDE untersttzt nur wenige Programmiersprachen: HTML, JavaScript, PHP, Java, Groovy und Ruby. Der Editor bietet Templates, die man zum Projektstart nutzen kann. Es ist sogar mglich, seine eigenen Templates zu speichern und spter zu verwenden. eXo Cloud IDE bietet zudem eine Git-Integration, um die Zusammenarbeit mit anderen Leuten zu erleichtern. Der Editor begleitet den Entwickler bishin zur Installation beim PaaS-Anbieter, bei dem CloudBees, Cloud Foundry, Heroku und Red Hat OpenShift integriert werden. eXo Cloud IDE luft zunchst relativ schnell. Bereits ab 3000 Dateizeilen wird der Editor jedoch sehr langsam. Das ist insofern problematisch, als dass 3000 Zeilen sehr schnell erreicht sind. eXo Cloud IDE ist wie eine Desktop-IDE aufgebaut und fr neue Benutzer nicht ungewhnlich. Die Web-Anwendung ist klar strukturiert und man findet schnell die gesuchte Funktion. Ein Vorteil von eXo Cloud IDE ist sein Anpassbarkeitsgrad. Mens, Tastenkombinationen und Formatierung knnen problemlos gendert werden. Zum Beispiel knnen Benutzer, die kein Git brauchen, dieses Men einfach verschwinden lassen. Vorteile Git-Integration PaaS-Anbieter integriert (CloudBees, CloudFoundry, Heroku, Red-Hat-OpenShift) Zusammenarbeit mglich Guter Anpassbarkeitsgrad Nachteile Nur 6 Programmiersprachen Keine Shell-Terminal Keine gehostete Datenbank

Tabelle 7 Vor- und Nachteile von eXo Cloud IDE

Mehr Informationen zum Projekt unter http://www.cloud-ide.com/ (Stand: 26.04.2012).

21

3.4 Zusammenfassung
Die Suche nach Alternativlsungen ist fr den Erfolg eines Projektes wichtig, da das Produkt somit besser positioniert werden kann. Man kann die Strken und Schwchen der Konkurrenten besser einschtzen. Auerdem ist es so mglich, sich ein genaueres Bild von den Funktionalitten des Produktes zu machen. Zuerst wurde eine Einfhrung in IDE vorgenommen, wo die Hauptfunktionalitten eines Editors erlutert wurden. Im Anschluss daran wurde das Cloud-Computing kurz vorgestellt und einige CloudAnbieter prsentiert. Letztlich fand eine kurze Evaluierung des Cloud-Software-Editors statt. Mehrere Lsungen wurden vorgestellt und deren Vor- und Nachteile gelistet. Nach dieser Einfhrung in die Thematik knnen das Pflichtenheft sowie die Use-Case-Diagramme erstellt werden.

22

4. Pflichtenheft
Nachdem in Kapitel Eins (siehe S. 1) das Projekt einleitend beschrieben wurde, in Kapitel Zwei (siehe S. 4) die Aufgaben- und Zielstellung des Projektes vorgestellt wurden und in Kapitel Drei (siehe S. 9) die Software-Alternativen des fachlichen Umfelds dargestellt wurden, soll nun das in dieser Arbeit entwickelte Projekt im Detail beschrieben werden. Das Pflichtenheft enthlt alle wesentlichen Informationen darber, wie das Projekt letztlich aussehen und funktionieren soll. Darin werden die Funktionen der Software genauer erlutert (siehe nachfolgender Abschnitt Zielbestimmung, siehe S. 23). Im Abschnitt Produkteinsatz (siehe S. 26) wird darauf eingegangen, wie die Software benutzt werden kann. Es wird erklrt, von wem und in welcher Umgebung die Software zum Einsatz kommen soll. Im Abschnitt Produkt (siehe S. 27) werden unterschiedliche Sachverhalte thematisiert. Zunchst wird eine allgemeine Beschreibung ber das entwickelte Produkt gegeben und im Anschluss daran die Features der Software im Abschnitt Produktfunktionen (siehe S. 27) detailliert. Informationen ber die Speicherung der Daten werden im Abschnitt Produktdaten (siehe S. 31) geliefert. Des Weiteren wird in den nachfolgenden Abschnitten auf die Qualittsanforderungen (siehe S. 33) sowie die Benutzeroberflche (siehe S. 34) genauer eingegangen. Der letzte Abschnitt befasst sich schlielich mit der Technischen Produktumgebung (siehe S. 36).

4.1 Zielbestimmung
Das Ziel des Projektes ist es, eine universelle Software-Entwicklungsumgebung in der Cloud zu entwerfen und zu entwickeln. Das Projekt ist also ein Software-Projekt, in dem ein Programmeditor erstellen werden soll. Neu hieran ist, dass dieser Editor in der Cloud luft und universell ist. Cloudbasiert bedeutet, dass man kein spezielles Programm auer einem Browser, wie zum Beispiel Chrome, Firefox oder Opera, installieren muss. Hinter dem Wort universell steckt, dass damit prinzipiell alles entwickelt und jede Sprache verwendet werden kann. Es soll folglich vermieden werden, dass nur in einer bestimmten Sprache programmiert werden kann oder bestimmte Programmiersprachen ausgeschlossen sind.

4.1.1 Musskriterien
Die Musskriterien enthalten eine Reihe Features, die auf jeden Fall, d. h. zwangslufig fr das Projekt erforderlich sind. Wenn eine dieser Funktionen nicht erfllt sein sollte, gilt das Projekt als gescheitert.

Authentifizierung
Das System soll in seiner Benutzung sicher sein. Persnliche Daten eines Nutzers drfen demnach nicht fr andere Nutzer sichtbar sein. Der Nutzer muss zudem die Mglichkeit haben, sich zu registrieren, einzuloggen, auszuloggen und die persnlichen Daten, wie beispielweise die E-Mail-Adresse und das Passwort, ndern zu knnen.

23

Server-Management
Die Software-Editierung soll direkt auf dem Server der Benutzer laufen. Deshalb muss es fr die Benutzer mglich sein, den eigenen Server zu managen. Dazu gehren Funktionen wie Server hinzufgen, listen, modifizieren und lschen, die ber die Benutzeroberflche gettigt werden knnen mssen. Im Moment wird nur Linux als Betriebssystem untersttzt. Das bedeutet, dass die Benutzer zunchst einmal nur auf einem Linux-Server entwickeln knnen. Die Untersttzung von Mac OS, Windows und anderen Betriebssystemen verbleibt vorerst in der Liste der Abgrenzungskriterien. Um die Erstellung von Entwicklungsservern zu vereinfachen, ist die Integration eines IaaS-Anbieters erforderlich.

Filebrowser
Eine weitere wichtige Funktion eines Programmeditors ist die Fhigkeit, Dateien editieren zu knnen. Beim Editieren sind die folgenden vier Grundaktionen zu beachten: das Kreieren, Lesen, Modifizieren und das Lschen.

Dateieneditor
Das Editieren von Dateien soll dank Syntax-Highlighting vereinfacht werden. Es soll zudem in verschiedenen Sprachen mglich sowie leicht erweiterbar sein. Ein Minimum von 20 verschiedenen Sprachen ist erforderlich.

Plug-in-System
Fr die Erweiterung des Editors muss ein Plug-in-System vorhanden sein. Diese Erweiterungen sollen es ermglichen, die Benutzeroberflche sowie die Logik des Editors zu ndern. Musskriterien, Sollkriterien und Kannkriterien knnen mit Hilfe eines Plug-ins integriert werden. Die Plug-ins sind mit dem Editor modifizierbar.

Editorkonfiguration
Die Anpassbarkeit des Editors ist von zentraler Bedeutung. Aus diesem Grund soll der Benutzer den Editor selbststndig konfigurieren knnen. Erforderlich sind zumindest die Modifikation der Schriftart sowie der Schriftgre. Auerdem sollte der Benutzer seine persnlichen Daten, wie E-Mail-Adresse, Name und Passwort etc. ndern knnen, wie oben bereits erwhnt wurde.

4.1.2 Sollkriterien
Die sogenannten Sollkriterien sind die Zielfunktionen des Projektes. Es sind Funktionen, die einen groen Mehrwert fr das Produkt bieten. Fr den Erfolg des Projektes mssen diese Kriterien mehrheitlich erfllt sein.

Software-Installation
Nicht nur fr die Entwicklung wird Speicherplatz fr die Quellcode-Dateien auf der Festplatte bentigt, sondern auch fr die Installation von zustzlicher Software wie Webserver, Datenbanken, Bibliotheken etc. Ein zentrales Ziel des Projektes ist die Funktion, ber eine Oberflche Software fr den Server zu suchen und zu installieren. Des Weiteren soll auf Unix-Kenntnisse verzichtet werden kn24

nen. Diese waren bisher Voraussetzung dafr, um mit der Programmierung berhaupt beginnen zu knnen.

Shell-Terminals
Verfgen einige Benutzer jedoch ber gute Unix-Kenntnisse, sollen diese dennoch Befehle zum Server schicken knnen. Shell-Terminals sollen im Editor ebenso zur Verfgung stehen wie in Putty10 oder in anderen SSH-Clients. Wie das Projekt selbst, sollen auch die Shell-Terminals im Browser laufen.

Version-Control-System-Integration
Version-Control-Systeme (kurz: VCS) gehren zu den wichtigsten Tools eines Entwicklers. Dank dieses Features knnen Benutzer mit VCS-Tools, wie Git und SVN, arbeiten. Ziel dieser Funktion ist es, mindestens ein VCS-Tool zu integrieren, mit dem der Quellcode in ein Repository ein- und ausgecheckt werden kann.

4.1.3 Kannkriterien
Die nachfolgenden Kriterien sind nicht zwingend fr den Erfolg des Projektes erforderlich und knnen fakultativ erfllt werden. Da sie einen Mehrwert fr das Projekt ausmachen, sollen sie dennoch an dieser Stelle erwhnt werden. Nachdem alle Muss- und Sollkriterien erfllt wurden, kann mit der Bearbeitung der Kannkriterien begonnen werden. Bereits whrend der Umsetzung der Muss- und Sollkriterien sollte man die Kannkriterien im Blick behalten. Ihre Realisierung sollte nicht aufgrund von Fehlentscheidungen, die whrend der Realisierung des Projektes getroffen wurden, verhindert werden.

Unix-Dateirechte
Dateirechte stellen einen wichtigen Aspekt in der Sicherheit eines Unix-Systems dar. Ohne die richtigen Rechte kann man bestimmte Dateien nicht editieren. Der Nutzer kann die Unix-Rechte ber die Benutzeroberflche ndern. So knnen Dateien von verschiedenen Nutzern gendert werden.

Debugger
Des Weiteren soll der Benutzer mit einer integrierten Benutzeroberflche sein Programm debuggen knnen. Damit ist die Verwendung einer unbegrenzten Anzahl von Programmiersprachen gemeint. Als Nachweis der Umsetzbarkeit reicht aber eine Programmiersprache aus, insofern damit gezeigt werden konnte, dass das gleiche Feature fr eine andere Programmiersprache implementiert werden konnte.

Outline
Klassen und Methoden, die von Benutzern programmiert werden, sollen auf einer gut strukturierten Oberflche gelistet werden. Die Analyse des Quellcodes muss in Echtzeit passieren. Wie bei den Kannkriterien der Debugger, soll dieses Feature universell sein, d. h. es muss fr mehrere Program-

10

Mehr Informationen zum Projekt unter http://www.putty.org/ (Stand: 22.06.2012).

25

miersprachen implementiert werden knnen. Fr den Erfolg des Projektes ist aber nur eine Programmiersprache erforderlich.

Refactoring
Der Nutzer sollte mit Hilfe der Benutzeroberflche die Mglichkeit haben, sein Programm schnell ndern zu knnen. Fr den Erfolg dieses Kriteriums ist die automatische nderung eines Klassenoder eines Methoden-Namens fr das ganze Projekt beispielsweise eine wichtige Voraussetzung.

4.1.4 Abgrenzungskriterien
Die Abgrenzungskriterien sind eine Liste von Kriterien, die nicht erfllt sein mssen. Dank dieser Liste kann man sich besser auf das Projekt konzentrieren.

Untersttzung der GUI-Entwicklung


Nicht erwnscht ist die Untersttzung einer graphischen Oberflche mit den Desktop-Technologien wie Qt oder Swing. Die einzigen untersttzten Oberflchen sind Webpages, die im Browser mit Hilfe von HTML, CSS und JavaScript laufen.

Windows- und Mac-OS-Untersttzung


In Abschnitt Musskriterien (siehe S. 23) wurde bereits erwhnt, dass das Server-Management ein Musskriterium ist. Im ersten Schritt werden nur Linux-Server untersttzt. Die Untersttzung von Windows- und Mac-OS-Servern ist fr den Erfolg des Projektes nicht zwingend erforderlich.

4.2 Produkteinsatz
In diesem Abschnitt wird beschrieben, wie das Produkt benutzen wird.

4.2.1 Anwendungsbereiche
Ziel des Produktes ist es, einen mobilen, effizienten und universellen Software-Editor zu bauen. Dieses Programm soll von Firmen genutzt werden, um externe Mitarbeiter zu untersttzen. Mit dem Software-Editor knnen Entwickler, Produktmanager und Lead-Programmierer ohne SoftwareInstallation von berall aus und mit jedem Computer weiterarbeiten. Natrlich funktioniert das Produkt auch In-House.

4.2.2 Zielgruppen
Die Hauptzielgruppe des Projektes sind Entwickler, die in der Web-Entwicklung ttig sind. Fr sie soll der Editor das zentrale Tool der Arbeit sein. Die komplette Entwicklung muss im Software-Editor stattfinden. Aber auch andere Zielgruppen sind denkbar, wie zum Beispiel System-Administratoren, die die Zugnge zum Server von berall brauchen. Fr den System-Administrator ist die Nutzung dieses Projek26

tes von Vorteil, weil der Editor ber smtliche grundlegenden Tools verfgt, wie zum Beispiel ber Shell-Terminals oder Dateien-Editoren. Mitarbeiter, die viel unterwegs sind, brauchen oftmals stndigen Zugang zum Server der Firma. Gerade fr sie kann der Editor besonders hilfreich sein, weil sie mit dem Editor kompletten Zugang zu allen Servern haben.

4.2.3 Betriebsbedingungen
Das System muss tglich 24 Stunden ohne Blockierung sowie wartungsfrei laufen. Des Weiteren muss es auf einem normalen Linux-System laufen. Die Installation von zustzlicher Software auf dem Server ist mglich.

4.3 Produkt
4.3.1 Produktbersicht
Das Projektziel ist die Entwicklung eines Software-Editors mit integrierter Server-Verwaltung. Die Anwendungsfalldiagramme befinden sich im Anhang (siehe S. 111).

4.3.2 Produktfunktionen
In diesem Abschnitt werden die Funktionen des Produktes im Detail beschrieben. Die Muss-, Sollund Kannkriterien, die fr das Nuage-Projekt umgesetzt wurden, werden aufgezhlt und genauer beschrieben. Die hier zu beschreibenden Funktionen gehren jeweils zu einer Gruppe, so gehrt [AUTH-01] zum Beispiel zu der Gruppe Authentifizierung. Gruppen sowie Funktionen besitzen eine Kriterienkategorie. Es ist aber auch mglich, dass beide nicht der gleichen Kriterienkategorie zugeordnet werden. Wenn eine Funktion zum Beispiel weniger wichtig ist, kann es sein, dass sie als Kannkriterium markiert ist, obwohl ihre Gruppe zu den Musskriterien gehrt.

Musskriterien
Authentifizierung

[AUTH-01]

Der Nutzer kann sich mit E-Mail-Adresse und einem Passwort registrieren. Eine Validierung der E-Mail-Adresse ist nicht erforderlich.

[AUTH-02]

Mit Hilfe seiner E-Mail-Adresse und seines Passworts kann sich der Nutzer einloggen.

[AUTH-03]

Der Nutzer kann sich ausloggen. Um sich wieder einzuloggen, braucht der Nutzer nur die E-Mail-Adresse und das Passwort erneut einzugeben.

27

[AUTH-04]

Der Nutzer kann seine persnlichen Daten, d. h. die E-Mail-Adresse und das Passwort, selbststndig ndern.

Server Management

[SM-M-01]

Der Nutzer kann neue Server einbinden. Dazu stehen ihm zwei Mglichkeiten zur Verfgung. Entweder gibt er die IP des Servers und den Benutzernamen an, mit dem man eine SSH-Verbindung ffnen kann oder er whlt einen IaaS-Anbieter aus. Bei der ersten Mglichkeit wird versucht, eine SSH-Verbindung aufzubauen. Die zweite Mglichkeit baut darauf, dass beim IaaS-Anbieter ein neuer Server erstellt wird, um dort zu programmieren. Fr beide Flle sollte bei einem Fehler des Verbindungsaufbaus der Benutzer informiert werden.

[SM-M-02]

Der Nutzer kann alle eigenen Server in einer Tabelle sehen.

[SM-M-03]

Der Nutzer kann einen Server modifizieren.

[SM-M-04]

Der Nutzer kann einen Server lschen.

[SM-M-05]

Der Nutzer kann einen Server starten, stoppen und erneut starten.

Filebrowser

[FB-M-01]

Der Nutzer kann Dateien und Ordner auf den Servern listen.

[FB-M-02]

Der Nutzer kann Dateien und Ordner auf den Servern kreieren.

[FB-M-03]

Der Nutzer kann Dateien und Ordner auf den Servern modifizieren.

[FB-M-04]

Der Nutzer kann Dateien und Ordner auf den Servern lschen.

[FB-M-05]

Der Nutzer kann die Unix-Rechte von Dateien und Ordnern auf den Servern ndern.

Dateieneditor

[DE-M-01]

Der Quellcode ist farblich hervorgehoben, wenn der Nutzer ihn editiert.

28

[DE-M-02]

Der Nutzer kann bestimmen, welche Programmiersprache er verwendet, die dann jeweils anders gefrbt ist.

Plug-in-System

[PS-M-01]

Der Nutzer kann Plug-ins listen.

[PS-M-02]

Der Nutzer kann Plug-ins kreieren.

[PS-M-03]

Der Nutzer kann Plug-ins modifizieren.

[PS-M-04]

Der Nutzer kann Plug-ins lschen.

[PS-M-05]

Der Nutzer kann Plug-ins aktivieren.

[PS-M-06]

Der Nutzer kann Plug-ins deaktivieren.

[PS-M-07]

Mit den Plug-ins knnen neue Knpfe zu den Mens und Kontext-Mens hinzugefgt werden.

Editorkonfiguration

[EK-M-01]

Der Nutzer kann die Schriftart des Editors auswhlen.

[EK-M-02]

Der Nutzer kann die Schriftgre des Editors auswhlen.

Sollkriterien
Software-Installation

[SM-S-01]

Der Nutzer kann Software, die installiert werden soll, ohne Shell-Befehle suchen.

[SM-S-02]

Der Nutzer kann neue Software auswhlen und installieren.

29

Shell-Terminal

[SC-S-01]

Der Nutzer kann im Browser eine SSH-Verbindung mit einem Server ffnen, nutzen und wieder schlieen.

[SC-S-02]

Der Nutzer kann mehrere Verbindungen pro Server ffnen.

Version-Control-System-Integration

[VCS-S-01]

Der Nutzer kann ein Repository auschecken.

[VCS-S-02]

Der Nutzer kann Dateiennderungen einchecken.

[VCS-S-03]

Der Nutzer kann Dateiennderungen auschecken.

Kannkriterien
Server Management

[SM-K-01]

Der Nutzer kann Server klonen und teilen.

[SM-K-02]

Der Nutzer kann weitere Nutzer-Zugnge zu einem Server vergeben.

Plug-in-Systeme

[PS-K-01]

Der Nutzer kann Plug-ins importieren.

[PS-K-02]

Der Nutzer kann Plug-ins exportieren.

[PS-K-03]

Der Nutzer kann mit anderen Nutzern Plug-ins teilen.

Unix-Dateirechte

[UD-K-01]

Der Nutzer kann die Unix-Rechte von Dateien und Ordnern auf den Servern ndern.

30

Debugger

[DG-K-01]

Der Nutzer kann Break-Points in den Quellcode einfgen und lschen.

[DG-K-02]

Der Nutzer kann die Software im Debug-Modus starten.

[DG-K-03]

Der Nutzer kann die Software Step-by-Step laufen lassen.

[DG-K-04]

Der Nutzer kann Variablen sehen und kontrollieren.

Outline

[OL-K-01]

Der Nutzer kann die Struktur (Funktionen, Klassen, Klassenmethoden usw.) einer Klasse sehen.

[OL-K-02]

Der Nutzer kann durch die Liste navigieren und direkt auf die Zeile der Deklaration springen.

Refactoring

[RF-K-01]

Der Nutzer kann fr bestimmte Dateien den Namen einer Klasse ndern. Voraussetzung dafr ist, dass die nderung die Software nicht zerstrt.

Version-Control-System-Integration

[VCS-K-01]

Der Nutzer kann Konflikte mit Hilfe einer Benutzeroberflche lsen.

4.3.3 Produktdaten
Nachfolgend werden alle Daten, die vom System gespeichert werden, aufgezhlt und kurz erklrt.

Information ber den Nutzer


Gespeichert werden folgende nutzerbezogene Daten: ID: Eindeutige String oder Integer sind ntig, um den Nutzer zu identifizieren. E-Mail-Adresse: Die E-Mail-Adresse des Nutzers, mit der der Nutzer sich einloggen kann. Passwort: Das Passwort des Nutzers, das er zum Login verwendet. Access-Token fr IaaS-API: Alle erforderlichen Daten fr die Authentifizierung bei dem IaaSAnbieter. 31

Informationen ber die Server


ID: Eindeutige String oder Integer sind ntig, um den Server zu identifizieren. Name: Der Name des Servers. Typ: Der Typ des Servers, zum Beispiel: o SSH: Server vom Typ SSH, kein besonderer IaaS-Anbieter o AWS: Amazon-Web-Service-Typ o andere IaaS-Anbieter Inhaber: Inhaber des Servers. Gste: Die Menge der Nutzer-IDs, die Zugang zum Server haben. Status: Der Status des Servers, zum Beispiel: o unknown: Das System kann den Status des Servers nicht identifizieren. o pending: Der Server fhrt gerade hoch oder herunter. o running: Der Server luft. o deleted: Der Server wurde gelscht. o stopped: Der Server ist aus. IP: IP des Servers. Hostname: Der Hostname des Servers. User: Der Username des Servers, mit dem man eine SSH-Verbindung ffnen kann.

Informationen ber die Plug-ins


ID: Eindeutige String oder Integer sind ntig, um den Plug-in zu identifizieren. Name: Der Name des Plug-ins. Beschreibung: Die Beschreibung des Plug-ins. Quellcode: Der Quellcode des Plug-ins. Inhaber: Der Inhaber des Plug-ins.

4.3.4 Produktleistungen
Das Produkt soll folgende Anforderungen erfllen: Zur Speicherung der Daten wird eine Datenbank benutzt. Gespeicherte Daten werden nicht verschlsselt. Bei Fehleingaben, Fehlermeldungen oder Warnungen soll dem Nutzer Bescheid gegeben werden. Der Nutzer soll ber die Mglichkeit verfgen, Fehler selbststndig zu korrigieren.

32

4.4 Qualittsanforderungen
Produktqualitt Sehr gut Gut Normal Nicht relevant

Funktionalitt

Angemessenheit

Richtigkeit

Interoperabilitt

Ordnungsmigkeit

Sicherheit

Zuverlssigkeit

Reife

Fehlertoleranz

Wiederherstellbarkeit

Benutzbarkeit

Verstndlichkeit

Erlernbarkeit

Bedienbarkeit

33

Effizienz

Zeitverhalten

Verbrauchsverhalten

nderbarkeit

Analysierbarkeit

Modifizierbarkeit

Stabilitt

Prfbarkeit

bertragbarkeit

Anpassbarkeit

Installierbarkeit

Konformitt

Austauschbarkeit

Tabelle 8 Qualittsanforderungen

4.5 Benutzeroberflche
Die Benutzeroberflche soll in einem Browser laufen. Die Installation von Browser-Plug-ins oder zustzlicher Software ist nicht erlaubt. Fr das Projekt wurden Wireframes-Prototypen produziert. Sie befinden sich im Anhang (siehe S. 115). 34

Die Abbildung 13 zeigt eine Kleinausgabe des Hauptprototyps. Darin sind die fnf Hauptbereiche der Benutzeroberflche definiert, die mit unterschiedlichen Farben gekennzeichnet wurden:

Abbildung 13 Allgemeine Erklrung des Prototyps

1 - Der obere, orangegefrbte und mit der Ziffer eins versehene Teil auf der Abbildung 13 ist der Kopfteil der Software. Dort befindet sich das Hauptmen, welches immer prsent sein muss. Die Struktur des Mens wird nachfolgend in der Tabelle 9 gezeigt. Im Hauptmen sind darber hinaus Buttons zu sehen. Diese stammen nicht vom Editor selbst, sondern sie mssen von Plug-ins definiert werden. 2 - Der blaue linke Bereich auf der Abbildung 13 wird hauptschlich verwendet, um einen Dateienbaum anzuzeigen. Wenn der Nutzer auf eine Datei doppelklickt, dann soll der Inhalt der Dateien im mit der Ziffer drei markierten Bereich angezeigt werden. 3 - Im mittleren, roten Bereich ist der Hauptbereich des Editors zu sehen. In dem mit der Ziffer drei markierten Bereich werden Dateien editiert. Wenn mehrere Dateien geffnet sind, dann kann der Nutzer mittels eines Tab-Systems zwischen den offenen Dateien einfach hin und her wechseln. 4 - Der vierte, grne Bereich rechts auen hlt Platz fr zustzliche Informationen, wie zum Beispiel fr das Outline, bereit. Hier knnen Plug-ins ein eigenes Tab kreieren und darin Informationen oder Formulare anzeigen. 5 - Der letzte, mit grauer Farbe hinterlegte Bereich, ist ebenfalls durch eine Tab-Struktur gekennzeichnet. An dieser, mit der Ziffer fnf markierten Stelle, werden die SSH-Verbindungen angezeigt. Auerdem sollen auch Informationen, Warnungen oder Fehler im Form von Logs angezeigt werden, wie die nachfolgenden Stze beispielhaft demonstrieren sollen:
[WedOct 11 14:32:52 2000] [info] File /home/user/filesuccessfullysaved [WedOct 11 14:32:52 2000] [error] Unableto open thefile /home/root/file, Permissiondenied.

35

Datei Neu ffnen Schlieen Logout Server Neu Liste

Bearbeiten Ausschneiden Kopieren Einfgen Hilfe Dokumentation About


Tabelle 9 Struktur des Mens

Einstellungen Editor Konto

4.6 Technische Produktumgebung


4.6.1 Software
Der Software-Editor muss zwingend im Browser laufen. Folgende Browser mssen fr den Erfolg des Projektes daher untersttzt werden: Firefox 9+ Chrome 17+ Internet Explorer 9+ Safari 5+ Opera 11+

Mobile Browser sind im Moment noch nicht erforderlich. Die Server-Technologien sollten frei whlbar sein. Die Nutzung von zustzlicher Software auf dem Server ist dann mglich, wenn diese in der Installationsanleitung dokumentiert werden. Der NuageServer muss auf einem Betriebssystem mit mindestens der Version 3.2+ von Linux laufen. Fr die persistenten Daten ist eine Datenbank erforderlich. Auch hier sind die Technologien frei whlbar.

4.6.2 Hardware
Der Server muss mindestens auf dieser Hardware laufen: 613 MB Arbeitsspeicher 1 GHz Prozessor 30 GB Festplatte 32-bit oder 64-bit Plattform

36

4.6.3 Entwicklungsschnittstellen
Eine Entwicklungsschnittstelle muss entwickelt und dokumentiert werden. Diese soll den Entwicklern bei der Plug-in-Entwicklung helfen.

4.7 Zusammenfassung
In diesem Kapitel wurde das Projekt genau spezifiziert. Die Ziele sowie die Funktionen des Produktes wurden in Form von Kriterien erlutert. Um die Kriterienliste bersichtlicher zu machen, wurden die Kriterien verschiedenen bergruppen zugeordnet wie zum Beispiel Authentifizierung, Server- Management, Filebrowser, Dateieneditor, Plug-in-System usw. Diese Gruppen wurden nach Prioritt angeordnet, von den Musskriterien bis hin zu den Kannkriterien. So kann man sich schnell einen berblick ber das Projekt und seine Features verschaffen. Auerdem wurden die Umgebungen des Produktes dargestellt, sowohl die technische, die z. B. die Hardware- und Software-Anforderungen (siehe S. 36) umfasst, als auch die operative, die den Anwendungsbereich und die Zielgruppen beinhaltet (siehe S. 26). Anhand des Pflichtenheftes wird im nchsten Kapitel der Systementwurf der Software vorgestellt.

37

5. Systementwurf
Zwischen der Erstellung des Pflichtenhefts und der Implementierung der Software muss der Systementwurf des Projektes durchgefhrt werden. Dieses Kapitel beschftigt sich mit dieser Phase. Hier werden die Architekturen des Clients und des Servers erlutert sowie das Datenbank-Schema entworfen.

5.1 Architektur
Es soll eine Web-Applikation, bestehend aus einem Server und einem Client, entwickelt werden. Die Nutzung von Browser Plug-ins wie Flash und Silverlight sind laut Pflichtenheft nicht erlaubt. Fr die Kommunikation zwischen Server und Client kommt das HTTP-Protokoll zum Einsatz (siehe Abbildung 14).

Abbildung 14 Client-Server-Architektur

5.1.1 Globale Architektur


Fr die Architektur sind drei Hauptbereiche von Bedeutung: Damit der Editor Dateien editieren kann, mssen diese auf die Festplatte des Entwicklungsservers bertragen werden. Leider ist dies nicht ohne einen Zwischenschritt mglich, weswegen ein Web-Server bentigt wird, der per HTTP-Anfragen erreichbar ist und die Zugriffe auf die Festplatte durchfhren kann. Der Nutzer soll die Server managen knnen, indem er neue Server erstellen, auflisten, modifizieren und lschen kann. Diese Informationen mssen in einer Datenbank gespeichert werden, welche sich ebenfalls auf dem Web-Server befindet. Fr die bermittlung der Daten wird eine HTTP-API zur Verfgung gestellt. Fr die Administration der Entwicklungsserver werden SSH-Verbindungen bentigt, welche hierfr extra eingerichtet werden. Es existieren bereits Projekte, die diese Funktionalitt bieten und daher im Editor integriert werden sollen.

Die globale Architektur sieht schlielich wie folgt aus:

38

Abbildung 15 Globale Architektur des Projektes

Die Abbildung 15 zeigt die globale Architektur des Projektes. Auf der linken Seite befindet sich der Nutzer. Ihm steht ein normaler Internet-Browser zur Verfgung, welcher nur HTTP-Anfragen verarbeiten kann. Diese werden dem Server des Editors bermittelt und wenn es notwendig ist, zum Entwicklungsserver weitergeleitet. Dies ist beispielweise bei einem Festplatten-Zugriff oder einer SSHVerbindung der Fall. Das Server-Management, das mit Hilfe der APIs von IaaS-Anbietern wie Rackspace oder AmazonWeb-Services umgesetzt wurde, bildet einen weiteren groen Teil des Projektes. Generell bieten Infrastructure-As-A-Service-Anbieter eine API-Schnittstelle, um Server zu managen, die mit WebProtokollen wie beispielsweise SOAP oder HTTP angesprochen werden knnen. Amazons API untersttzt zum Beispiel SOAP und HTTP, womit verschiedene Aktionen durchgefhrt werden knnen: Server knnen mit dem RunInstances-SOAP-Befehl erstellt werden (vgl. Amazon-WebServices 2012, S. 359ff.). Server knnen mit dem TerminateInstances-SOAP-Befehl gelscht werden (Ebd., S. 373f.). Server knnen mit dem StartInstances-SOAP-Befehl gestartet werden (Ebd., S. 369f.). Server knnen mit dem StopInstances-SOAP-Befehl gestoppt werden (Ebd., S. 359f.). Server knnen mit dem RebootInstances-SOAP-Befehl neu gestartet werden (Ebd., S. 319f.).

Der Server muss mit dem Namen des Nutzers angemeldet werden, wofr er nur eine Access-Key-ID und einen Secret-Access-Key bentigt. Beide werden fr die Verschlsselung der Kommunikation verwendet und mssen deswegen in der Datenbank gespeichert werden. Die in Abbildung 15 zu sehenden Entwicklungsserver stellen die Arbeitspltze der Nutzer dar. Hier werden die Dateien editiert und die jeweils vom Nutzer bentigte Software installiert. Diese Server knnen von IaaS-Anbietern kommen, wie in Abbildung 15 bei den Entwicklungsservern 4 und 5 zu sehen ist, oder von anderen Anbietern kommen, wie dies bei den Entwicklungsservern 1, 2 und 3 der Fall ist. Der Editor bentigt hingegen nur eine valide SSH-Verbindung.

39

5.1.2 Server-Architektur
Entwickelt wird ein einziger Web-Server, der fr alle Komponenten, wie den Editor, die SSHVerbindungen, das Server-Management, Datenbank-Verbindungen und viele mehr, zustndig ist. Damit der Quellcode strukturiert ist, werden die Komponenten wie in Abbildung 16 zu sehen voneinander getrennt.

Abbildung 16 Server-Architektur

Ein HTTP-Server bekommt alle Anfragen der Nutzer und analysiert diese, um herauszufinden, an welche Komponente die Anfrage gerichtet war und leitet sie dementsprechend weiter. In den meisten Fllen wird die Analyse nur wie folgt anhand der URL durchgefhrt: 1. http://<domain name>/ssh-proxy leitet die Anfrage an einen SSH-Proxy weiter. 2. http://<domain name>/harddisk leitet die Anfrage an einen Festplatten-Zugriff weiter. 3. usw. Ein Web-Applikation-Framework-Projekt wie beispielsweise Symfony11, Spring12 oder Django13, wird fr die Implementierung der HTTP-Serverkomponente benutzt, weshalb kein Design fr den HTTPServer in der Design-Phase entworfen wird. Die Auswahl des Frameworks und der Programmiersprache soll whrend der Implementierung evaluiert und gettigt werden.

11 12

Mehr Informationen zum Projekt unter http://symfony.com/ (Stand 26.05.2012). Mehr Informationen zum Projekt unter http://www.springsource.org/ (Stand 26.05.2012). 13 Mehr Informationen zum Projekt unter https://www.djangoproject.com/ (Stand 26.05.2012).

40

Die Verbindung zur Datenbank wird ber den HTTP-Server erstellt und jede Komponente kann ber den Datenbank-Mapper darauf zugreifen.

Abbildung 17 Entitten-Klassen

Zur einfacheren Programmierung sollen Object-Relational-Mapper (ORM) fr relationale Datenbanken oder Object-Document-Mapper (ODM) fr dokumentorientierte Datenbanken eingesetzt werden. Ziel dieses Mapper ist es, die Komplexitt der Datenbank zu abstrahieren, indem die Datenbankanfragen in einer Klasse konzentriert werden. Die verschiedenen Komponenten der Server knnen dann die Methode der Klasse ausfhren, um Anfragen an die Datenbank zu stellen. Der Mapper enthlt auch alle Entitten als Klassen, drei sollen hier implementiert werden: Nutzer, Server und Plug-in (siehe Abbildung 17).

Abbildung 18 Connector-Vererbung

Der IaaS-Client ist fr das Server-Management zustndig und kmmert sich um die Aufrufe der IaaSAnbieter, um zum Beispiel Server zu erstellen, zu lschen und zu starten. Wie oben bereits erwhnt, findet die Kommunikation mit dem IaaS-Anbieter ber HTTP- oder SOAP-Anfragen statt. Damit verschiedene IaaS-Anbieter untersttzt werden knnen, sollen diese Anfragen in Klassen abstrahiert 41

werden und je nach Anbieter spezialisiert werden knnen (siehe Abbildung 18). Dies hat zwei Vorteile, zum einen gewinnt man an Flexibilitt und zum anderen sinkt die Komplexitt. Die Festplatten-Zugriffskomponente ist fr das Editieren von Ordnern und Dateien zustndig. Damit diese Komponente auf die Festplatten der neu hinzugefgten Server zugreifen kann, wird eine gltige SSH-Verbindung bentigt. Um sicherzustellen, dass eine solche Verbindung mglich ist, werden neue Server beim Hinzufgen auf ihre Gltigkeit hin berprft. Zur Reduktion der Komplexitt wird das Software-Projekt SSHFS14 benutzt, welches ein auf dem SSH-Protokoll basiertes Dateisystem bereitstellt (vgl. Szeredi 2012). Mit Hilfe dieses Projektes kann man das Dateisystem des Servers in das Dateisystem des Clients einbinden (siehe Beispiel in Abbildung 19).

Abbildung 19 SSHFS-Beispiel

Der Vorteil ist, dass Dateien des Servers als lokale Dateien angezeigt werden. Pro Entwicklungsserver ist eine SSHFS-Instanz notwendig, was durch die folgenden zwei Klassen realisiert wird. Eine Klasse ist fr das Einbinden zustndig und die andere fr die Dateienzugriffe (siehe Abbildung 20).

14

Mehr Informationen zum Projekt unter http://fuse.sourceforge.net/sshfs.html (Stand: 22.06.2012).

42

Abbildung 20 Festplatten-Zugriff-Klassen

Die Software-Installation soll ebenfalls mit Hilfe von SSH durchgefhrt werden. Normalerweise wird die Installation von Software mit Hilfe von Package-Managern wie yum, apt-get oder aptitude durchgefhrt. Daher muss, bevor eine Software gesucht oder installiert werden soll, zuvor ermittelt werden, welcher Package-Manager verwendet wird. Die Klasse des Software-Installers muss daher auch alle Shell-Befehle, wie Suche, Installation, Deinstallation usw., der jeweiligen Package-Manager enthalten (siehe Abbildung 21).

Abbildung 21 Software-Installation-Klasse

Eine Alternative zum Software-Installer wre der Einsatz einer Configuration-Management-Software (SCM) wie Chef15 oder Puppet16.

5.1.3 Client-Architektur
Clientseitig muss ein Programm geschrieben werden, welches fr die grafische Darstellung des Editors und die Kommunikation mit dem Server zustndig ist. Auch fr diesen Teil muss ein Framework wie Jquery17 oder ExtJS18 ausgewhlt werden.

15 16

Mehr Informationen zum Projekt unter http://www.opscode.com/chef/ (Stand: 22.06.2012). Mehr Informationen zum Projekt unter http://puppetlabs.com/ (Stand: 22.06.2012). 17 Mehr Informationen zum Projekt unter http://jquery.com/ (Stand: 26.05.2012). 18 Mehr Informationen zum Projekt unter http://www.sencha.com/products/extjs/ (Stand: 26.05.2012).

43

Die Grund-Architektur des Clients kann jedoch schon entworfen werden und soll auf dem MVCPattern basieren. Das MVC-Pattern wurde in den 70er Jahren von Trygve Reenskaug fr die SmalltalkPlattform entwickelt (Siehe Fowler, Martin 2002, S. 330). Dieses Pattern besteht aus drei wichtigen Bestandteilen: Model, View und Controller. Das Model soll alle Daten sowie Methoden, verhltnismig zur Domain enthalten. Der View ist fr die grafische Darstellung zustndig. Anhand der Eingabe des Nutzers manipuliert der Controller die Models und lsst die Views sich neu zeichnen (Siehe Fowler, Martin 2002, S. 330). Die Idee ist, dass jeder Bereich der Benutzeroberflche mit einer View und einem Controller reprsentiert wird. Im Kapitel Pflichtenheft wurden alle GUI-Bereiche definiert (siehe Abbildung 13, Seite 35): Kopfteil der Software Linke Tabs Hauptbereich des Editors Rechte Tabs Unterer Bereich

Abbildung 22 Clientseitige Architektur-Controllers und Views

44

Wie in Abbildung 22 zu sehen ist, sind alle Controller unabhngig voneinander. Sie besitzen nur eine Referenz zum so genannten Applikationsobjekt. Dieses Objekt ist ein Singleton (eine einzige Instanz fr das gesamte Programm) und fr die Synchronisierung der Web-Apps zustndig. Die Kommunikation zwischen den Controllern findet in diesem Objekt statt. Wenn der Nutzer beispielsweise im linken Bereich (blau) auf eine Datei doppelklickt, muss der Controller das Applikationsobjekt darber informieren, dass eine Datei geffnet werden soll. Ein groer Vorteil ist, dass die Controller lose gekoppelt sind. Wenn sich ein Controller ndert, muss nur die Applikationsklasse gendert werden und nicht alle Controller der einzelnen Bereiche. Die einzelnen Modelle gehren ebenfalls zur clientseitigen Architektur. Hierbei handelt es sich um dieselben Klassen wie bei der serverseitigen Architektur (siehe Abbildung 17, S. 41): Server, Plug-in und Nutzer.

5.2 Datenbank-Schema
Erst whrend der Implementierung soll ein passendes Datenbanksystem gewhlt werden. Trotzdem steht das Schema, bestehend aus den Entitten Benutzer, Server und Plug-ins, schon fest.

Abbildung 23 Entity-Relationship-Model

Abbildung 23 zeigt das Entity-Relationship-Model mit den einzelnen Entitten und deren Relationen. Das Model wurde relativ einfach gestaltet, um die Flexibilitt und Anpassbarkeit des Systems zu verbessern.

45

5.3 Zusammenfassung
In diesem Kapitel wurde das Software-Design vorgestellt. Anhand des Pflichtenheftes wurde ein Entwurf des Systems erstellt. Dabei wurde zuerst die globale Architektur prsentiert, damit man die Kommunikation zwischen dem Benutzer, dem Nuage-Server und den Entwicklungsservern nachvollziehen kann. Dann wurde die Client- und Server-Architektur beschrieben. In diesen zwei Abschnitten (siehe S. 40 und 43) wurden Klassendiagramme vorgestellt, um den Quellcode, der in der Implementierung produziert wird, zu strukturieren. Auerdem wurden technische Besonderheiten, wie das Einbinden von Festplatten mit Hilfe des SSHFS-Projektes, erlutert. Dies ist ein wichtiger Punkt fr dieses Projekt, da davon ein Groteil der Architektur abhngt. Aus diesem Grund wurden diese technischen Besonderheiten noch vor der Implementierung untersucht. Anschlieend wurde das Datenbank-Schema bekanntgegeben.

46

6. Realisierung
In diesem Kapitel geht es um die Phase der Implementierung. Wie bereits im Kapitel Aufgabenstellung (siehe S. 4) erwhnt, wird in dieser Phase das Software-Design in Quellcode-Zeilen transkribiert. Bezglich des Software-Designs und der Software-Architektur mssen grundlegende Entscheidungen getroffen werden, wie zum Beispiel die Festlegung auf die Programmiersprachen und Bibliotheken. Die zwei ersten Abschnitte dieses Kapitels befassen sich mit der Erklrung dieser Auswahl. Dieses Kapitel wird dann mit einer Zusammenfassung beendet.

6.1 Programmiersprachen
Die Auswahl einer Programmiersprache ist eine wichtige Entscheidung fr ein Software Projekte. Im Pflichtenheft sowie im Design ist keine Auswahl festgelegt - weder fr den Browser, noch fr den Server. Nachfolgend wird zunchst die Entscheidung fr die Programmiersprache der Benutzeroberflche erklrt, anschlieend auf die Auswahl fr den Server eingegangen.

6.1.1 Client
Im Pflichtenheft dieses Projektes steht, dass die Benutzungsoberflche in einem Browser laufen soll und keine Installation von zustzlicher Software erforderlich sein sollte (siehe Abschnitt Benutzeroberflche S. 34). Gesucht ist also eine Programmiersprache, die im Browser luft und mit der man Benutzeroberflche bauen kann. JavaScript ist fr die Programmierung im Browser fast die einzige Mglichkeit. Die Sprache JavaScript ist fast in jedem Browser verfgbar und bentigt keine Installation von zustzlicher Software (Dionisio/Toal 2011). Im Browser ist JavaScript fr die Logik zustndig. Die Sprache kann aber nicht die Darstellung von graphischen Elementen leisten, dafr werden CSS und HTML bentigt.

6.1.2 Server
Wie es in der globalen Architektur des Projektes (siehe Abbildung 15 S. 39) bereits gesehen wurde, steht der Server des Projektes im Mittelpunkt des Systems. Auf der einen Seite stellen die Nutzer mit Hilfe des HTTP-Protokolls Anfragen, auf die der Server Antworten soll. Auf der anderen Seite sind die Entwicklungsserver zu sehen. Diese werden mit Hilfe des SSH-Protokolls erreicht, um verschiedene Informationen herauszufinden (beispielsweise Daten der Festplatte). Auerdem muss der Sever mit dem API eines PaaS-Anbieters kommunizieren.

47

Abbildung 24 Stellung des Nuage-Servers

Die Abbildung 24 zeigt die Hauptaufgabe des Nuage-Servers. Diese kann in vier Schritte aufgeteilt werden, die mit Zahlen gekennzeichnet wurden. 1. Zuerst startet der Nutzer eine Anfrage, wie zum Beispiel die Frage Was befindet sich im Ordner XYZ. 2. Weil die Dateien auf dem Entwicklungsserver zu finden sind, muss der Server diese Anfrage weiterleiten. 3. Der Entwicklungsserver wird also gefragt und gibt eine Antwort zurck. 4. Der Nuage-Server bekommt diese Antwort, bersetzt sie fr das HTTP-Protokoll und leitet sie an den Nutzer weiter. Das Problem ist allerdings, dass der Nuage-Server zwischen Anfrage 2 und Antwort 3 warten muss, weil die Netzwerk-bertragung sowie die Suche im Dateibaum ein paar Millisekunden bis Sekunden dauern kann (In Abbildung 24 ist der Bereich rot markiert). Dieses Problem ist im Computerbereich unter dem Namen Input/Output (I/O) bekannt. Wenn ein Prozess Netzwerke, Ressourcen, Dateiinhalte oder andere Ein- und Ausgaben abrufen will, muss er aufgrund der Latenz (zum Beispiel wegen des Netzes oder wegen der Festplatte) warten. Fr Proxy-Applikationen wie dieses Projekt kann die Latenz problematisch sein. Wenn der Entwicklungsserver zu lange zum Antworten braucht, wartet der Prozess mehr als er tatschlich arbeitet.

48

Fr das dargestellte Problem gibt es mehrere Lsungen: das sogenannte Multithreading und die ereignisorientierte Programmierung. Im Multithreading enthlt der Prozess mehrere Threads. Ein Thread kann wie ein leichter Prozess angesehen werden. Ein Thread erhlt seine eigenen Daten und Instruktionen (vgl. Padua 2011, S. 1223). Wenn ein Thread blockiert ist, knnen andere Threads, sofern das Betriebssystem Mehrprozessbetriebe untersttzt, weiter arbeiten. Ein weiter Vorteil von Multithreading ist zudem, dass die Performanzen mit einem Mehrkernprozessor verbessert werden. Die Kernel knnen gleichzeitig mehrere Threads bearbeiten. Andererseits ist die Programmierung mit Threads auch komplizierter. Man muss die verschiedenen Threads synchronisieren und in extremen Fllen knnen Threads sich sogar blockieren. Die Idee von ereignisorientierter Programmierung hingegen ist eine komplett andere. Das ganze Programm luft nur in einem Thread. Mit synchronem Aufruf wrde im Quellcode eine HTTP-Anfrage so aussehen, wie im Listing 1 dargestellt ist.
var request = require('request'); var url = 'http://www.beuth-hochschule.de'; var result = requestSync(url); print(result); ...
Listing 1 Synchrone HTTP-Anfrage

Whrend der Anfrage muss der Thread warten. Im Gegensatz zum Multithreading geht das Programm in der ereignisorientierten Programmierung weiter und erledigt den Rest des Programms spter (siehe Listing 2).
var request = require('request'); var url = 'http://www.beuth-hochschule.de'; var callback = function (result) { print(result); // Diese Zeile wird nach der Anfrage ausgefhrt } request(url, callback); ...
Listing 2 Asynchrone HTTP-Anfrage

Nach der Anfrage geht der Prozess hier weiter. Sobald die Antwort der HTTP-Anfrage zurckkommt, wird die Callback-Funktion ausgefhrt. Der Vorteil dieser Methode ist, dass das Programm nie auf eine Antwort wartet. Deswegen ist es fr I/O-Aktionen eine sehr performante Lsung. Die asynchrone Programmierung kann allerdings unperformant fr Applikationen, die viele CPU-Ressourcen brauchen. Wenn der CPU mit einer lngeren Aufgabe beschftigt ist, dann kann er keine weiteren erledigen. Fr die Performanz des Projektes ist es wichtig, dass eine dieser zwei Lsungen in der Programmiersprache mglich ist. Folgende Sprachen kommen in Frage und werden nun kurz evaluiert, um eine Entscheidung zu treffen: Python, PHP, Java, JavaScript.

49

Python
Python ist eine Skriptsprache und erschien im Jahre 1991. Sie luft auf verschiedenen Betriebssystemen: Windows, Mac und Unix. Die Typisierung von Python ist stark und dynamisch, was bedeutet, dass alle Variablen einen bestimmten Typ haben, dieser sich aber whrend der Laufzeit ndern kann. Mit dem Web-Framework Tornado19 kann man einen nicht blockierenden Web-Server aufbauen. Tornado basiert auf epoll, was ein I/O event notification facility (Linux man-pages 2009) ist. Die Tornado Web-Server laufen also asynchron. Vorteile Nicht blockierende Web-Server wie Tornado Objektorientierte Nachteile Situation zwischen Python 2.7 und Python 3.0 (vgl. Python 2012) ist unklar

Tabelle 10 Vor- und Nachteile von Python

PHP
Im Jahre 1995 erschien die Skriptsprache PHP. Genau wie Python luft PHP auf Windows, Mac und Unix. Die Typisierung von PHP ist ebenfalls dynamisch, jedoch auch schwach (bzw. weak auf Englisch). Einer der Unterschiede zur starken Typisierung ist, dass der Typ einer Variable implizit ist. Das heit, dass der Interpreter die Typkonvertierungen je nach Operation vornimmt. Fr eine Addition werden zum Beispiel die zwei Summanden in Integer konvertiert, selbst wenn eine Variable vom Typ String ist. Seit PHP 5.4 enthlt PHP einen Web-Server. Dieser sollte aber nur fr die Entwicklung und die Umsetzung von Tests benutzt werden (vgl. PHP 2012). Man muss also einen anderen Server wie beispielsweise Apache20 oder Nginx21 verwenden. Beide nutzen das Multithreading (vgl. The Apache Software Foundation 2012; Sysoev 2012). Nginx basiert aber auch auf ereignisorientierter Programmierung (vgl. Kleinman 2012). Vorteile Sehr populr Objektorientiert Nachteile Schwache Typisierung kann zu Missverstndnissen fhren

Tabelle 11 Vor- und Nachteile von PHP

Java
Wie PHP ist auch Java im Jahre 1995 erschienen. Die aktuelle Version von Java ist die Version 7.0.4 (Stand: 23.06.2012). Die Typisierung der Sprache ist stark und statisch. Statisch bedeutet, dass der Typ einer Variablen sich nie ndern wird.

19 20

Mehr Informationen zum Projekt unter http://www.tornadoweb.org/ (Stand: 06.06.212). Mehr Informationen zum Projekt unter http://httpd.apache.org/ (Stand: 06.06.212). 21 Mehr Informationen zum Projekt unter http://nginx.org/ (Stand: 06.06.212).

50

Es existieren viele Implementierungen von Java-Web-Servern wie zum Beispiel Tomcat22, Glassfish23 oder auch Jetty24. Die Mglichkeiten mit Java sind vielfltig. Vorteile Vielfltige Mglichkeiten Objektorientiert Nachteile berblick ber alle Java-Technologien schwierig zu behalten

Tabelle 12 Vor- und Nachteile von Java

JavaScript
JavaScript ist ebenfalls eine Skriptsprache und hat wie PHP eine schwache und dynamische Typisierung. Sie wurde ebenfalls im Jahre 1995 offiziell prsentiert. Ursprnglich war sie fr den NetscapeBrowser gedacht (vgl. Netscape 1995). Bereits im Jahre 1996 wurde JavaScript in den NetscapeEnterprise-HTTP-Server integriert (vgl. Wayner 2011). JavaScript ist eine ereignisorientierte Programmiersprache. Im Browser wird sie oft benutzt, um Events wie Klicks oder Tastendrcke einzufangen und dann darauf zu reagieren. Im Jahre 2009 wurde von Ryan Dahl Node.js25 prsentiert. Node.js ist ein JavaScript-Framework, das auf dem Google V8 JavaScript-Engine basiert 26. Ziel dieses Frameworks ist es, eine ereignisorientierte Basiskomponente fr Applikationen anzubieten die viele Daten enthalten oder in Echtzeit abgerufen werden sollen. Vorteile Gleiche Sprache fr Server und Client Objektorientiert Nachteile Asynchroner Aufruf kann ungewhnlich fr den Programmierer sein

Tabelle 13 Vor- und Nachteile von JavaScript

Fr das Projekt wurde aus verschiedenen Grnden JavaScript ausgewhlt. JavaScript ist objektorientiert und im Gegenteil zu Java nicht sehr umfangreich. Es gibt zum Beispiel in der Sprache selbst keine Vererbung. Objektorientierung ist bei JavaScript prototypenbasiert. Der Haupteigenschaft von prototypenbasierter Programmierung ist, dass die Klassen dynamisch gehalten sind. Sie knnen sich also whrend der Laufzeit noch ndern. Der Vorteil dabei ist, dass man Flexibilitt gewinnt, jedoch mit dem Risiko fr das Programm ein schlechteres Pattern zu entwickeln. JavaScript hat auerdem eine groe Community, die sehr aktiv ist. Die Sprache wird clientseitig und serverseitig benutzt. Viele Bibliotheken, die fr clientseitige Zwecke entwickelt wurden, funktionieren auch serverseitig. Die Mitarbeiter, die fr das Front-End zustndig sind, knnen, ohne eine neue Sprache zu lernen, auch fr das Back-End arbeiten. Neue Mitarbeiter brauchen weniger Zeit, um das
22 23

Mehr Informationen zum Projekt unter http://tomcat.apache.org/ (Stand: 06.06.2012). Mehr Informationen zum Projekt unter http://glassfish.java.net/ (Stand: 06.06.2012). 24 Mehr Informationen zum Projekt unter http://jetty.codehaus.org/jetty/index.html, (Stand: 06.06.2012). 25 Mehr Informationen zum Projekt unter http://nodejs.org/ (Stand: 07.06.2012). 26 Mehr Informationen zum Projekt unter http://code.google.com/p/v8/ (Stand: 07.06.2012).

51

Produkt zu lernen. Weil die gleiche Sprache clientseitig und serverseitig benutzt wird, kann man auch den gleichen Quellcode fr beide Seiten benutzen. Man muss ihn folglich nur einmal schreiben. Zudem sind Aktualisierungen einfacher vorzunehmen (Hughes-Croucher/Wilson 2012). Der Nachteil von JavaScript ist, dass die asynchronen Aufrufe fr den Programmierer sehr ungewhnlich sein knnen. Die Skriptsprache funktioniert daher nicht wie eine synchrone Programmierung, bei der man von oben nach unten liest (siehe Listing 1 und Listing 2). Es ist aber mglich, den Quellcode so zu strukturieren, dass er besser lesbar wird (siehe Listing 3; Die Callback-Funktion wird whrend der Anfrage definiert). Problematisch ist hier, dass der Quellcode wegen der Einrckung mehr nach rechts rckt.
var request = require('request'); var url = 'http://www.beuth-hochschule.de'; request(url, function (result) { print(result); }); ...
Listing 3 Verbesserte asynchrone HTTP-Anfrage

Wie bereits erwhnt wurde Node.js im Jahre 2009 entwickelt. Das Framework ist fr eine solche Komponente relativ neu, weshalb Updates fr Node.js auch relativ hufig erforderlich sind. Zwischen den Versionen 0.6.13 und 0.6.19 gab es im Durchschnitt einen Abstand von 13,83 Tagen zwischen den zwei nchsten Versionen (siehe Tabelle 14; Schlueter, Isaac 2012). Mochte man aus Sicherheitsund/oder Performanzgrnden die aktuelle Software haben so muss man sehr oft die Node.jsPlattform updaten. Daher sollte man darauf achten, dass die Software, die man entwickelt, nach einer Aktualisierung immer noch mit der neusten Version kompatibel ist. Fr diese Aufgabe knnen automatisierte Unit-Tests und funktionale Tests sehr ntzlich sein.

Version

Datum

Tage nach letztem Update

v0.6.19

06.06.2012

22

v0.6.18

15.05.2012

11

v0.6.17

04.05.2012

v0.6.16

30.04.2012

21

v0.6.15

09.04.2012

17

52

v0.6.14

23.03.2012

v0.6.13

15.03.2012

nicht bercksichtigt

Tabelle 14 Hufigkeit der Node.js-Updates

6.1.3 Datenbank
Um Daten festzuhalten, wurde im Pflichtenheft die Nutzung einer Datenbank genannt (siehe S. 32). Fr diese Auswahl kamen zwei Projekte in Frage: Mysql und MongoDB. Andere Datenbanken wurden ebenfalls kurz evaluiert, worauf jedoch nicht eigegangen werden soll.

MySQL
MySQL ist ein relationales Datenbanksystem, welches im Jahre 1994 von Michael Widenius und David Axmark entwickelt wurde. Heute gehrt das Projekt zu Oracle und ist eines der bekanntesten Open-Source-Datenbankprojekte. Der Bekanntheitsgrad von MySQL ist ein Vorteil, da zahlreiche Hilfestellungen und Dokumentation zu MySQL-Anwendung existieren. Das Projekt wird seit 2010 von Oracle untersttzt (vorher war es Sun Microsystems). Man kann also davon ausgehen, dass sich das Projekt weiterentwickelt wird. MySQL ist am CAP-Theorem, an der Konsistenz (Consistency) sowie der Erreichbarkeit (Availability) orientiert. Vorteile Sehr bekannt Von einer Firma getragen Nachteile Wenig MySQL-Node.js-Module

Tabelle 15 Vor- und Nachteile von MySQL

MongoDB
MongoDB ist eine NoSQL-dokumentenorientierte Datenbank. Es wurde im Jahre 2007 von der Firma 10gen entwickelt. Das Projekt ist erst seit 2009 als Open Source verfgbar. Ziel dieses Projektes ist es, eine flexible und skalierbare Datenbank anzubieten. MongoDB erreicht die Kriterien Konsistenz (Consistency) und Aufteilungstoleranz (Partition Tolerance), des CAP-Theorems. Der Vorteil von MongoDB fr das Nuage-Projekt ist, dass es JSON-formatorientiert ist. Man kann nicht nur serialisierte, sondern auch echte JSON-Daten verschicken und speichern. Auerdem kann mit Hilfe von MapReduce oder der Suchfunktion im gespeicherten JSON-Zustand gesucht und damit gefiltert werden. Fr ein serverseitiges JavaScript-Projekt ist dies ein Vorteil, da JSON in JavaScript hufig verwendet wird. Aus diesem Grund gibt es auch viele Module, die die Untersttzung von MongoDB im Node.js anbieten. Auerdem werden bei MongoDB-Query-Funktionen und MapReduce in JavaScript geschrieben.

53

Vorteile Sehr gut skaliert JSON speichern und suchen MongoDB ist populrer in der Node.jsCommunity JavaScript-Funktionen fr die Suche

Nachteile Insgesamt weniger bekannt

Tabelle 16 Vor- und Nachteile von MongoDB

Gewhlt wurde die MongoDB-Datenbank hauptschlich aufgrund seiner Verwandtschaft zu JavaScript. Nachdem die clientseitige sowie die serverseitige Sprache gewhlt wurden, ist die Auswahl der Datenbank die letzte technische Grundentscheidung dieses Projektes. Hier kann man bereits beobachten, dass alle bis jetzt gewhlten Technologien JavaScript sehr hneln. Fr das Projekt ist dies sicherlich ein Vorteil.

6.2 Bibliotheken
Bibliotheken sind fr die Softwareentwicklung vor zentraler Bedeutung, denn sie ermglichen die erneute Nutzung von Komponenten und/oder Klassen. Statt fr jedes Projekt immer die gleichen Artefakte zu schreiben, wird man eher allgemeingltige Softwareteile schreiben, die anpassbar sind. In diesem Abschnitt werden die Bibliotheken, die in diesem Projekt verwendet als auch extra dafr geschrieben wurden, vorgestellt.

6.2.1 Client
Es existieren viele JavaScript Frameworks. Zwei Eigenschaften sind fr dieses Projekt besonders wichtig. Wie schon im Systementwurf erwhnt wurde, ist ein MVC-Framework ntig (siehe Abschnitt Client-Architektur Seite 43). Dieses Feature soll fr die Struktur des Quellcodes sorgen. Das zweite besonders wichtige Feature der Bibliothek sind die fertigen graphischen Elemente. Da es in diesem Projekt auch um die Entwicklung einer Oberflche geht, muss die Bibliothek die BenutzeroberflcheEntwicklung untersttzen. Natrlich ist es auch mglich, zwei Bibliotheken miteinander zu kombinieren, sofern die Kombination zusammen weitere Vorteile mit sich bringt.

JQuery jQuery-UI Backbone.js27


JQuery ist heutzutage die bekannteste JavaScript Library (vgl. Lemay/Colburn 2011, S. 461.). Sie bietet Grundfeatures fr die Entwicklung von JavaScript im Browser. Ajax-Anfragen, DOM-ElementeManipulationen und CSS-Manipulationen sind drei von den Hauptfeatures. Leider werden weder GUI-Elemente noch MVC-Pattern mitgeliefert. JQuery bietet nur Hilfsmethoden, um die JavaScript-Entwicklung zu erleichtern.

27

Verfgbar unter der Lizenz MIT/GNU GPL v2.0, mehr Informationen zu den Projekten unter http://jquery.com/; http://backbonejs.org/ und http://jqueryui.com/ (Stand: 09.06.2012).

54

Fr die GUI-Entwicklung mit jQuery ist jQuery-UI sehr beliebt. Diese Bibliothek ist eine Sammlung von GUI-Elementen, und umfasst einen Autocompleter, Datepicker, Progressbar, Tabs usw. Fr jQuery wurden auch zahlreiche Plug-ins von der Community entwickelt, die weitere GUI-Elemente anbieten. Backbone.js ist eine relativ kleine Bibliothek, um eine Web-App clientseitig zu entwickeln. Mit diesem Projekt kann man JavaScript-MVC-Applikationen entwickeln. Die Nutzung von jQuery mit Backbone.js wird fr dieses Projekt von den Autoren des Projektes Backbone.js empfohlen (vgl. DocumentCloud 2012), es bleiben aber trotzdem drei unterschiedliche Projekte. Selbst wenn die Bibliotheken heute, kompatibel sind kann man nicht sicher sein, ob dies fr die Zukunft auch so bleibt. Diese Lsung ist robust und sehr flexibel, aber sie bietet nicht alle Funktionalitten, die man braucht um gute GUI zu bauen. Die Elemente sind sehr spezifisch und unvollstndig, um eine Benutzeroberflche zu strukturieren. Vorteile Sehr bekannt Open Source Nachteile Drei unterschiedliche Projekte Kein Page-Layout-System (Ohne Plug-in) Kein Design-Tool

Tabelle 17 Vor- und Nachteile von jQuery

Yahoo! UI28
Yahoo! UI (kurz: YUI) wurde, wie der Name vermuten lsst, von Yahoo! entwickelt. YUI bietet wie jQuery die Grundfunktionalitten einer JavaScript Library (Ajax-Aufrufe, DOM-ElementManipulationen, CSS-Manipulationen usw.). Dazu stehen auch UI-Elemente zur Verfgung wie ein Autocompleter, Kalender, Charts usw. Eine neue Funktionalitt bei YUI ist das App-Framework. Dieses Feature ist die Antwort von Yahoo! auf Backbone.js. Es bietet ein MVC-Pattern, um Web-Apps zu strukturieren. Leider wird YUI von der Community nicht so gut untersttzt wie jQuery (vgl. Lemay/Colburn 2011, S. 461.). Deswegen gibt es nur wenige Plug-ins und Tutorials. Vorteile Untersttzt von Yahoo! Open Source Nachteile Kleinere Community als jQuery Kein Design-Tool

Tabelle 18 Vor- und Nachteile von Yahoo! UI

28

Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter http://yuilibrary.com/ (Stand: 09.06.2012).

55

ExtJS29
Sencha Inc. ist eine relativ neue Firma, die Frameworks, Tools und Dienste fr HTML5- und JavaScript-Web-App bietet. Sencha Inc. entwickelt ExtJS, eine JavaScript-Bibliothek, die auf interaktive JavaScript-Applikationen spezialisiert ist. ExtJS ist hnlich wie YUI und bietet ebenfalls bestimmte Grundfunktionalitten einer JavaScriptLibrary, UI-Elemente sowie MVC-Pattern an. ExtJS bringt aber andere Features mit, wie zum Beispiel ein verbessertes Vererbungssystem. Sencha entwickelte auch ein Tool namens Sencha Architect 2. Es ist eine Desktop-Applikation, die bei der Entwicklung von ExtJS-Projekten die Entwickler untersttzt. Man kann damit nicht nur Quellcodes schreiben, sondern auch per Drag-and-Drop GUI bauen. Die Entwicklung wird mit diesem Tool beschleunigt. Das Tool ist nicht kostenlos, aber eine Gratisversion ist 30 Tage lang verfgbar. Ein Nachteil von ExtJS besteht in der Lizenz. Es sind zwei Mglichkeiten fr Projekte, die mit ExtJS gebaut sind, gegeben. Entweder kauft man das Produkt und kann damit das gebaute Projekt verkaufen oder man nimmt die Open-Source-Version von ExtJS. Dafr muss man das gebaute Projekt aber auch Open Source verteilen. Vorteile Untersttzt von Sencha Inc. Gutes MVC-Framework Zahlreiche GUI-Elemente GUI-Tools Nachteile Lizenz kommerziell oder Open Source

Tabelle 19 Vor- und Nachteile von ExtJS

Dhtmlx30
Dhtmlx ist die Alternative zu YUI und ExtJS. Es ist ebenfalls ein kommerzielles Produkt mit OpenSource-Lizenz. Features sind die Grundfunktionalitten einer JavaScript-Library und UI-Elemente. Leider wurde kein MVC-Pattern implementiert. Wie Sencha Architect 2 ist DHTMLX-Visual-Designer ein Design Tool. Mit diesem man kann GUI bauen, ohne zu programmieren. Leider sind die Features dieses Tools nicht so umfangreich wie bei Sencha Architect 2. Der Vorteil von Dhtmlx ist die gegebene Back-End-Integration. Die Firma bietet Konnektoren fr verschiedene Sprachen, z. B. werden PHP, ASP.NET, JAVA, und ColdFusion untersttzt. Leider gibt es keinen Konnektor fr Node.js (vgl. DHTMLX LTD 2012).

29

Verfgbar unter einer kommerzielle Lizenz oder unter GNU GPL v3.0, mehr Informationen zum Projekt unter http://www.sencha.com/products/extjs/ (Stand: 09.06.2012). 30 Verfgbar unter einer kommerzielle Lizenz oder unter GNU GPL v2.0, mehr Informationen zum Projekt unter http://dhtmlx.com/ (Stand: 21.08.2012).

56

Vorteile Back-End Konnektoren (aber nicht fr Node.js)

Nachteile Lizenz kommerziell oder Open Source Kein Node.js-Konnektoren Design-Tool nicht sehr umfangreich

Tabelle 20 Vor- und Nachteile von Dhtmlx

Fr das Projekt dieser Arbeit wurde ExtJS gewhlt. Entscheidend war, dass dieses Tool eine robuste Library ist. Viele GUI-Elemente sind schon definiert und man findet zudem Element um die Benutzeroberflche zu strukturieren. Sencha Architect 2 ist fr das Projekt ebenfalls von Vorteil, weil es die GUI-Entwicklung beschleunigt.

6.2.2 Server
Im Node.js sind Bibliotheken unter dem Begriff Modul (Auf Engl. Module) zu finden. Ein Modul kann von anderen Modulen abhngig sein. Node-Package-Manager (kurz: NPM) wurde von Isaac Z. Schlueter entwickelt, dem aktuellen Leiter des Node.js Projektes (vgl. Young 2012). NPM ist das Haupt-Repository, in dem mehr als 10 000 Module gelistet sind31. Hier sollen nun nur die Module prsentiert werden, von denen der Editor abhngig ist.

CoffeeScript32
CoffeeScript ist eine Sprache, die im JavaScript kompiliert werden kann. Es enthlt einen Parser sowie einen Compiler. Ziel ist es, die Syntax von JavaScript zu verbessern.

IcedCoffeeScript33
IcedCoffeeScript ist ein Fork von CoffeeScript. Die Idee des Autors ist es, Features fr asynchrone Aufrufe anzubieten, was das Original CoffeeScript noch nicht kann.

Express34
Express ist ein Web-Developement Framework. Es ermglicht die Entwicklung von performanten und flexiblen Web-Apps und Webseiten. Die Bibliothek ist sehr bekannt und man findet viele Module die Express erweitern.

Jade35
Jade ist ein Template-Engine fr Node.js. Dank Jade kann man HTML produzieren, die Daten enthalten. Es ist das quivalent zu Apache Velocity 36 fr JavaScript.

31 32

Mehr Informationen zum Projekt unter http://search.npmjs.org/ (Stand: 08.06.2012). Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter http://coffeescript.org/ (Stand: 08.06.2012). 33 Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter http://maxtaco.github.com/coffee-script/ (Stand: 03.07.2012). 34 Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter http://expressjs.com/ (Stand: 08.06.2012). 35 Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter http://jade-lang.com/ (Stand: 08.06.2012). 36 Mehr Informationen zum Projekt unter http://velocity.apache.org/ (Stand: 08.06.2012).

57

Mongoose37
Mongoose ist ein Object-Relational-Mapping-Projekt (kurz: ORM) fr MongoDB und Node.js. Mit diesem Projekt ist es mglich, ein Datenbankschema fr MongoDB zu definieren. Dann kann man Daten hinzufgen und wieder abfragen.

Mongoose-auth38
Basierend auf dem Modul Everyauth39 bietet dieses Modul die Authentifizierung fr ein Express Projekt mit Hilfe von Mongoose.

Underscore40
Underscore ist eine Sammlung von Basisfunktionen, die in JavaScript nicht standardmig sind. Die Bibliothek kann serverseitig und clientseitig benutzen werden.

Aws2js41
Aws2js ist eine Implementierung vom AWS-API-Client. Damit kann man mit der API von Amazon kommunizieren, um so zum Beispiel Server zu kontrollieren.

Log4js42
Dies ist die Implementierung von Log4js43 fr JavaScript. Mit diesem Projekt werden die Log-Dateien des Editors produziert.

Async44
Async ist eine bekannte Bibliothek von Node.js und bietet asynchrone Hilfsmittel. Damit kann man zum Beispiel parallele asynchrone Aufrufe von Funktionen machen.

Mkdirp45
Mkdirp bietet eine rekursive Ordnererstellung fr Node.js.

Rimraf46
Sowie Mkdirp bietet Rimraf ein rekursives Lschen von Ordnern (sowie rm -rf in Shell-Skript).

37 38

Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter http://mongoosejs.com/ (Stand: 08.06.2012). Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter http://mongoosejs.com/ (Stand: 08.06.2012). 39 Mehr Informationen zum Projekt unter http://everyauth.com/ (Stand: 08.06.2012). 40 Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter http://underscorejs.org/ (Stand: 08.06.2012). 41 Siehe Webseite fr die Lizenz - https://github.com/SaltwaterC/aws2js (Stand: 08.06.2012). 42 Verfgbar unter der Lizenz Apache 2.0, mehr Informationen zum Projekt unter https://github.com/nomiddlename/log4js-node (Stand: 08.06.2012). 43 Mehr Informationen zum Projekt unter http://log4js.berlios.de/ (Stand: 08.06.2012). 44 Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter https://github.com/caolan/async/ (Stand: 08.06.2012). 45 Verfgbar unter der Lizenz MIT/X11, mehr Informationen zum Projekt unter https://github.com/substack/node-mkdirp (Stand: 08.06.2012). 46 Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter https://github.com/isaacs/rimraf (Stand: 08.06.2012).

58

Vows47
Mit Vows kann man asynchrone Tests realisieren. Die Tests dieses Editors wurden mit Hilfe dieses Projektes gemacht. SSHFS, Fs2http und Markdox sind drei Module, die extra fr den Nuage-Editor geschrieben wurden. Deswegen werden dafr die Beschreibungen detaillierter sein als fr die anderen Bibliotheken.

SSHFS-node48
SSHFS-node ist ein Modul, mit dem entfernte Server mit Hilfe des SSH-Protokolls montieren werden knnen. Es basiert auf dem Projekt SSHFS 49. Vorteil dieses Projektes ist, dass Dateien einer externen Maschine als lokale Dateien angesehen werden. Eine bertragung ber SSH oder FTP ist daher nicht mehr notwendig. Zwar wird die bertragung trotzdem stattfinden, aber muss nicht vom Entwickler programmiert werden. Alle Dateisystemfunktionen wie readFile, writeFile, stat, readdir 50 funktionieren damit auf externen Dateien. Die genaue Funktionsweise von SSHFS wurde im Kapitel Systementwurf erlutert (siehe S. 42). Dieses Modul bietet nur zwei ffentliche Funktionen an: mount() und umount(). mount (user, host, mountpoint, callback); umount (mountpoint, force, callback); Die mount()-Funktion ist fr das Einbinden der Dateien verantwortlich. Fr diese Funktion mssen Benutzername, Domne oder IP des Servers sowie das Ordnerziel, d. h. der Montageort gegeben sein. Optional kann eine Callback-Funktion gegeben werden, die mit mglichen Fehlermeldungen ausgefhrt wird. Die umount()-Funktion trennt die montierten Ressourcen wieder. Nur ein Argument ist Pflicht, nmlich das Ordnerziel. Beim sogenannten Abbinden besteht manchmal das Problem, dass Aktionen noch laufen, zum Beispiel Lesen- oder Schreibaktionen. Wenn man mit dem Abbinden nicht warten mchte, kann man als ersten optionalen Parameter ein Boolean geben, um zu entscheiden, ob das Abbinden erzwungen werden soll. Der letzte optionale Parameter ist eine Callback-Funktion. Dieses Modul ist vom SSHFS-Projekt abhngig. Sollte der SSHFS-Befehl nicht auf dem Computer installiert sein, wird das Modul nicht funktionieren.

Fs2http51
Fs2http ist die Abkrzung fr Filesystem to HTTP und ist ein Node.js Modul. Es wurde gebaut, um Express-Applikationen zu erweitern. Diese Erweiterung ist fr Dateiennderungen zustndig. Die Idee ist, ein Mapping zwischen den Node.js-Filesystem-Funktionen52 und dem HTTP-Protokoll zu bauen.
47 48

Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter http://vowsjs.org/ (Stand: 08.06.2012). Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter https://github.com/cbou/sshfs-node (Stand: 08.06.2012). 49 Mehr Informationen zum Projekt unter http://fuse.sourceforge.net/sshfs.html (Stand: 10.06.2012). 50 Mehr Informationen zum Projekt unter http://nodejs.org/api/fs.html (Stand: 10.06.2012). 51 Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter https://github.com/cbou/fs2http (Stand: 08.06.2012). 52 Dokumentation unter http://nodejs.org/api/fs.html (Stand: 11.06.2012).

59

Die wichtigen Funktionen wie rename()53, stat()54, writeFile()55 usw. werden als Route fr Express dargestellt. Eine Route ist eine URL, die im Express definiert ist. Wenn eine HTTP-Anfrage mit der richtigen URL ankommt, dann wird der Server antworten.
var express = require('express'); var fs2http = require('fs2http'); var app = module.exports = express.createServer(); // App benutzt hier fs2http fs2http.use(app); app.listen(3000);
Listing 4 Fs2http-Konfiguration

Die Verwendung dieses Modules ist relativ unkompliziert. Listing 4 zeigt die klassische Konfiguration eines Express-Servers. Das Modul Fs2http kann auch berschrieben werden. Man kann zum Beispiel die Standard-URL modifizieren oder die Pfade der Dateien ndern und damit Teile der Festplatte gegen Schreib- und Leseaktionen schtzen. Es ist zudem mglich Middleware zu definieren. In Express werden MiddlewareFunktionen ausgefhrt, bevor die eigentliche Route-Funktion ausgefhrt wird. Damit kann man zum Beispiel Nutzer, die nicht eingeloggt sind, zum Anmeldung-Formular weiterleiten.

Abbildung 25 SSHFS mit zwei Servern

Im Projekt dieser Arbeit wird Middleware dazu benutzt, um verschiedene Entwicklungsserver zu untersttzen. Im Kapitel Systementwurf (siehe S. 42) wurde gezeigt, dass auf dem Nuage-Server das Projekt SSHFS integriert wurde, um Entwicklungsserver zu montieren. Wenn zwei Server montiert wurden, stellt sich die Situation wie in Abbildung 25 dar. Wenn ein Nutzer des Servers 1 z. B. die Datei /home/user/file lesen mchte, muss so die Datei /mnt/server1/home/user/file gelesen werden. Es

53 54

Dokumentation unter http://nodejs.org/api/fs.html#fs_fs_rename_path1_path2_callback (Stand: 11.06.2012). Dokumentation unter http://nodejs.org/api/fs.html#fs_fs_stat_path_callback (Stand: 11.06.2012). 55 Dokumentation unter http://nodejs.org/api/fs.html#fs_fs_writefile_filename_data_encoding_callback (Stand: 11.06.2012).

60

ist aber aus Sicherheitsgrnden nicht erwnscht, dass Nutzer den vollstndigen Pfad kennen. Aus diesem Grund werden Middlewares benutzt. Wenn eine Anfrage nach der Datei /home/user/file des Servers 1 gestellt wird (siehe Abbildung 26), so muss das Serverobjekt in der Datenbank anhand der HTTP-Anfrage zuerst gefunden werden. Die ID des Servers liegt im Request-Objekt und dort wird der gefundene Server angebunden (siehe HTTPAnfrage zwischen Etappe 1 und 2 der Abbildung 26). Anschlieend wird der Entwicklungsserver eingebunden, was Aufgabe der Middleware middleware.mounter() ist, sofern noch nicht geschehen. Whrend der Route-Funktion wird die Methode updatePath() ausgefhrt. Sie bersetzt den Pfad /home/user/file in /mnt/home/user/file. Am Ende wird die richtige Datei gelesen und die Antwort mit dem angefragten Inhalt der Datei zurck geschickt.

Abbildung 26 Fs2http-Beispiel-Anfrage

Die updatePath()-Methode wird nicht in dem Fs2http-Modul definiert, sondern direkt bei der Konfiguration der Express-Server. Listing 5 zeigt die erweitere Konfiguration des Moduls Fs2http. Hier werden die Middleware-Funktionen sowie die updatePath() definiert. Damit kann das Modul allgemeingltig bleiben und dennoch weiter angepasst werden.
var express = require('express'); var fs2http = require('fs2http'); var middleware = require('middleware');

61

var app = module.exports = express.createServer(); fs2http.middleware = [middleware.cloudCallCheck, middleware.findServer, middleware.mounter]; fs2http.updatePath = function(req, res, path, callback) { newPath = req.server.getMountpoint() + '/' + path callback(newPath); } // App benutzt hier fs2http fs2http.use(app); app.listen(3000);
Listing 5 Erweiterte Fs2http-Konfiguration

Markdox56
Markdox ist eine Software, mit der Dokumentationen auf der Grundlage von Quellcode generiert werden knnen. Auch diese Software wurde speziell fr das Projekt der Arbeit entwickelt. Es basiert auf Dox57 sowie dem Markdown-Format58. Dox ist ein Node.js-Modul, das die Dokumentation vom Quellcode extrahiert. Hauptschlich liest die Software den Kommentar (im Javadoc-Format, siehe Listing 6) und gibt eine Ausgabe im JSON. Danach muss dieses JSON-Objekt in eine lesbare Version transformiert werden.
/** * Escape the given `html`. * * Examples: * * utils.escape('<script></script>') * // => '&lt;script&gt;&lt;/script&gt;' * * @param {String} html string to be escaped * @return {String} escaped html * @api public */ exports.escape = function(html){ return String(html) .replace(/&(?!\w+;)/g, '&amp;') .replace(/</g, '&lt;') .replace(/>/g, '&gt;'); };
Listing 6 Dox-Kommentar-Beispiel

Markdown ist eine Klartextsyntax, die entweder ohne Umwandlung gelesen oder in andere Formate wie HTML oder Microsoft Word umgewandelt werden kann. Vorteil an Markdown ist, dass die Syntax sehr einfach ist und sich deswegen gut transformieren lsst.

56 57

Verfgbar unter der Lizenz MIT, mehr Informationen zum Projekt unter https://github.com/cbou/markdox (Stand: 03.07.2012). Mehr Informationen zum Projekt unter https://github.com/visionmedia/dox/ (Stand: 03.07.2012). 58 Mehr Informationen zum Projekt unter http://daringfireball.net/projects/markdown/ (Stand: 03.07.2012).

62

Markdox basiert auf der Ausgabe von Dox und transformiert sie in ein Markdown-Format. Man kann dieses Projekt entweder mit einer Shell-Befehl oder als Node.js-Modul nutzen. Nachfolgend ist ein Verwendungsbeispiel von Markdox in Node.js abgebildet (siehe Listing 7).
var markdox = require('markdox'); var file = 'lib/parser.js'; var output = 'doc/parser.md'; markdox.process(file, output, function(){ console.log('Documents generated with success'); });
Listing 7 Markdox-Beispiel

6.3 Dokumentation
Die Bedienungsanleitung und Entwickler-Dokumentation u. a. sind wichtige Dokumente, die whrend des Projektes erstellt werden. Folgende unterschiedliche Funktionen erfllt die Dokumentation: Sie lehrt neuen Nutzern, wie man die Software bedienen kann. Dies ist das Hauptziel der Bedienungsanleitung. Sie erklrt, wie man die Software installiert. Mit Hilfe der Installationsanleitung knnen die Betreiber der Software besser verstanden werden. Sie erleichtert es zudem, die verschiedenen Schritte durchzufhren, damit die Software schnell angewendet werden kann. Besonders bei SaaS-Produkten ist dieses Dokument wichtig, denn die Installation funktioniert nicht wie eine Desktop-Applikation-Installation. Zum Beispiel muss auch die Datenbank per Hand installiert werden. Diese Etappen werden in der Installationsanleitung genau beschrieben und nachvollziehbar gemacht Fr die Weiterentwicklung der Software, etwa um die Software zu erweitern oder um Plugins zu entwickeln, sind tiefergehende Informationen notwendig. Das Design-ArchitekturDiagramm und Implementierungsspezifikation stellen technische Details dar. Sie werden in diesem Bericht im Kapitel Systementwurf umfassend dargestellt. Auerdem befindet sich auf der CD eine Entwicklungsdokumentation, die die von dem Quellcode generierte Dokumentation enthlt. Hier werden die Methoden und Klassen beschrieben (siehe Ordner Dokumentation auf der CD).

6.4 Zusammenfassung
Im diesem Kapitel wurde die Realisierung des Projektes erlutert. Es wurde gezeigt, dass JavaScript als Sprache fr die server- und clientseitige Implementierung am besten geeignet ist. Der Server wurde mit Node.js gebaut, unter anderem mit Hilfe des Modules Express. Im Browser wurde ExtJS benutzt. Die Bibliothek enthlt alle Vorteile eines guten JavaScriptFrameworks. Eine gute Dokumentation ist gegeben und ein effizientes MVC-Pattern wurde implementiert. Des Weiteren existieren bereits zahlreiche GUI-Elemente. Sencha Inc. (der Hersteller von ExtJS) bietet ein Design-Tool, um GUI fr ExtJS schnell zu kreieren. Um Daten zu persistieren, wurde MongoDB, hauptschlich wegen seiner hnlichkeit zu JavaScript, gewhlt. Am Ende dieses Kapitels 63

wurden Module prsentiert, die speziell fr dieses Projekt geschrieben wurden: SSHFS-node, Fs2http und Markdox. SSHFS-node und Fs2http spielen eine groe Rolle beim Zugriff auf Dateien ber das HTTP-Protokoll. Markdox ist fr die Generierung von Entwicklerdokumentation zustndig.

64

7. Test
Wie bereits im Kapitel Aufgabenstellung ausgefhrt, ist die Testphase fr ein Software-Projekt von enormer Bedeutung (siehe S. 7). Dafr existieren verschiedene Kontrollmglichkeiten und Verfahren. Im Folgenden werden zwei wichtige Methoden prsentiert: die White-Box und die Black-Box. Black-Box: Mit der Black-Box-Methode werden Tests von einer auenstehenden Person, welche keine Kenntnisse ber die Implementierung und das Design besitzt, erarbeitet. Der Entwickler dieser Tests wei lediglich, welche Ergebnisse erwartet werden. Der Vorteil der Black-Box-Methode ist die vollkommene Unabhngigkeit der Tests von der Implementierung. Wenn man den Quellcode nicht lesen kann, hat man keine Vorurteile, ob er richtig oder falsch ist. Man geht davon aus, dass es Bugs gibt. White-Box: Bei der White-Box-Methode sind die Test-Entwickler mit dem gesamten System genausten vertraut. Sie kennen die Architektur, das Design und die Implementierung. Die Tests werden anhand dieser Informationen realisiert. Der Vorteil der White-Box-Methode liegt darin, dass die Tester prfen knnen, welche Teile des Quellcodes nicht getestet wurden. Mit dieser Methode kann man sicherstellen, dass smtliche Bereiche getestet werden. Beide Methoden ergnzen sich somit hervorragend, weshalb man optimalerweise beide Formen zur Anwendung bringt. Zuerst werden Black-Box-Tests entwickelt. Danach kann man sich den Quellcode anschauen und fr jene Stellen, die von der Black-Box nicht getestet wurden, weitere Tests entwickeln.

Diese Arbeit wurde von einer Einzelperson entworfen, weshalb es nicht mglich war, mehrere Entwickler einzubinden. Die Tests, die hier programmiert wurden, sind also White-Tests. Whrend des Projektes wurden regelmig weitere Tests entwickelt, denn es war wichtig, dass die Features wie geplant funktionieren. Aus diesem Grunde wurden hauptschlich funktionelle Tests erarbeitet. Es gibt zwei Typen von Tests in diesem Projekt: Servertests und Browsertests. Beide werden im nchten Abschnitt nher behandelt.

7.1 Servertests
Die Entwicklung des Projektes hat mit dem Server begonnen, deswegen wurden zuerst verschiedene Servertests entwickelt. Sie rufen nur die URLs auf und kontrollieren die Antworten auf ihre Richtigkeit hin. Der Vorteil liegt darin, dass die Tests unabhngig von der GUI sind. Die Tests wurden, wie der Server, mit Node.js beziehungsweise mit der LibraryVows 59 geschrieben. Vows ist ein TestFramework fr Node.js. Es ermglicht JavaScript auf dem Server zu testen. Die Tests wurden, wie der Server, im CoffeeScript geschrieben.
suite.addBatch( 'when login with valid user': topic: () -> request.post url: 'http://localhost:3000/login' json:
59

Mehr Informationen zum Projekt unter http://vowsjs.org/ (Stand: 18.06.2012).

65

email : 'valid@example.com' password : 'test' , this.callback return 'we got no error': (err, req, body) -> assert.isNull err assert.equalreq.statusCode, 200 )
Listing 8 Vows-Beispiel

Das Listing 8 zeigt einen Beispiel-Test, einen sogenannten Batch. Die Batches werden gleichmig nach und nach gestartet. Man kann also mit dem ersten Batch einen Benutzer einloggen (wie im Listing 8) und danach eine geschtzte URL anfragen. Die Tests werden mit einem Shell-Befehl gestartet und die Fehler werden im Terminal aufgezeigt (siehe Listing 9).
$ vows test/login-test.coffee --spec Try login when loading fixtures we got no error when login with bad user we got no error when login with valid user we got no error when calling editor should have editor when logging out should be logged out when calling editor again should ask for password OK 6 honored (0.623s)
Listing 9 Beispiel-Ausfhrung von Tests

Damit die Tests anlaufen knnen, muss die Datenbank vorher gestartet werden. Der Vorteil von Vows ist, dass es ein Node.js-Modul ist, weswegen die Servertests gut im Projekt integriert sind. Aus diesem Grund wird der Nuage-Server automatisch gestartet. Dies gilt genauso fr die Dummydaten, nmlich jene Daten, welche am Anfang jedes Tests durchgefhrt werden. Dieses Verfahren vereinfacht die Ausfhrung der Tests. Es ist ein Vorteil fr kontinuierliche Integration, was unter anderem bedeutet, dass die Tests nach jedem Commit gemacht werden. Mit diesem Verfahren wurden verschiedene Features getestet. Die Tabelle 21 listet alle Bereiche des Projektes, die getestet wurden, auf. Auerdem sind auch Beispiel-Batches gegeben. Die komplette Liste der Ausgaben der Servertests befindet sich im Anhang (siehe S. 105).

66

Getestete Bereiche

Beispiel-Batch

Typ

Abstract-Connector-Class

Server-Status-Mapping-Test

Unit-Test

AWS-Connector

Server kreieren, Server starten, Server stoppen usw.

Unit-Test

SSH-Connector

Server kreieren, Server lschen usw.

Unit-Test

Fs2http-Integration

Ordner lesen

Funktionstest

Fs2http mit neuem Server

Server kreieren, Server montieren, Dateien lesen Funktionstest und schreiben

Login

Einloggen, Editoranfrage

Funktionstest

Server

Server kreieren, Server starten, Server stoppen usw.

Funktionstest

Server-Modell

Shell-Befehl schicken

Unit-Test

Timestampable Plug-in)

(Modell- createdAt und updatedAt testen

Unit-Test

User-Server

Benutzerrechte testen

Funktionstest

Tabelle 21 Servertest-Cases

7.2 Browsertests
Die Servertests sind sehr praktisch, um den Server zu prfen. Man kann sich jedoch nicht sicher sein, dass ein Feature funktioniert, solange man nicht die GUI testet. Dafr gibt es die Browsertests. Mit der GUI gibt es zwei Hauptprobleme: Das Erscheinungsbild ist nicht gut, beispielsweise fehlt eine CSS-Datei oder ein Bild. berdies ist es mglich, dass es zwischen dem Browser und dem HTML/CSS-Code ein Kompatibilittsproblem gibt. Dafr muss man Screenshots machen und diese entweder manuell oder automatisch prfen.

67

Das zweite Problem ist, dass es zu JavaScript-Fehlern kommen kann. Diese knnen die Nutzung des Programms blockieren. Um dies zu vermeiden reicht es, wenn der JavaScriptQuellcode ausgefhrt und darauf berprft wird, dass es keine Fehler gibt.

Fr die Browsertests wurde CasperJS60 benutzt. Dieses Projekt basiert auf PhantomJS 61, einem kopflosen Webkit mit einer JavaScript-Schnittstelle. Das heit, dass PhantomJS mit Hilfe des WebkitProjektes62 einen Browser bietet, der keine GUI hat, sondern mit JavaScript gesteuert wird. CasperJS benutzt diesen Browser, um eine Testumgebung anzubieten. Das Listing 10 ist ein Beispieltest vom CasperJS. Zuerst werden das CasperJS und die Dump-Objekte kreiert (Step 1). Dann wird ein Testfall angekndigt (Step 2). Er soll die Login-URL aufrufen. Es wird berprft, ob der Statuskode der richtige ist (Step 3). Danach werden im Login-Formular die E-MailAdresse sowie das Passwort hinzugefgt und das Formular validiert (Step 4). Die Tests und der kopflose Browser sind voneinander unabhngig. Deswegen muss abgewartet werden, bis die Anfrage des Benutzer-Einloggens beendet ist (Step 5). Nach einer Sekunde wird getestet, ob das Einloggen erfolgreich war, indem man die URL testet. In einem letzten Arbeitsschritt (Step 6) werden einfach die Tests gestartet.
# Step 12 casper = require('casper').create logLevel: 'debug' verbose: false dump = require('utils').dump # Step 2 casper.start 'http://localhost:3000/login', -> # Step 3 @test.assertHttpStatus 302, 'Anonymous user should be redirected' # Step 4 @fill 'body', 'email': 'valid@example.com', 'password': 'bad pass', , false @click '.btn-login' # Step 5 @wait 1000, -> @test.assertUrlMatch new RegExp(config.url.login), 'User is NOT redirected after sending wrong credentials' # Step 6 casper.run -> @test.renderResults true
Listing 10 CasperJS-Beispiel

Wie in diesem Kapitel dargestellt wurde, ist CasperJS sehr praktisch, um Besucher zu simulieren und JavaScript-Fehler zu prfen. Zustzlich kann das Projekt auch das Aussehen der Web-App prfen. Mit CasperJS ist es mglich, Screenshots zu machen (siehe Listing 10).
60 61

Mehr Informationen zum Projekt unter http://casperjs.org/ (Stand: 19.06.2012). Mehr Informationen zum Projekt unter http://phantomjs.org/ (Stand: 19.06.2012). 62 Mehr Informationen zum Projekt unter http://www.webkit.org/ (Stand: 19.08.2012).

68

casper.start "http://www.beuth-hochschule.de/", -> @capture "beuth.png", top: 100 left: 100 width: 500 height: 400 casper.run()
Listing 11 CasperJS-Screenshot-Beispiel

Eine Liste der aktuellen Tests, die mit Hilfe von CasperJS aufgebaut wurden, befindet sich in Tabelle 22.

Getesteter Bereich

Test-Case

Einloggen

Einloggen mit valid-E-Mail und Passwort

Server

Server kreieren

Tabelle 22 Browsertest-Cases

7.3 Zusammenfassung
In diesem Kapitel wurde eine wichtige Phase des Projektes genauer erlutert. Die Tests erfllen gleich mehrere Aufgaben. Sie knnen dazu beitragen, dass bereits einmal aufgetretene Fehler zuknftig sicher vermieden werden. Auerdem kann man beispielsweise berprfen, ob ein wichtiges Feature funktioniert. In dieser Arbeit wurden sowohl Servertests als auch Browsertests eingesetzt. Mit HTTP-Anfragen haben Servertests die Route des Projektes getestet. Die Browsertests, welche auf CasperJS basieren, haben die GUI getestet.

69

8. Ergebnisse
Die Evaluation eines Projektes ist die letzte Phase der Entwicklungsarbeit. Auf das aktuelle Projekt hat diese Phase allerdings keinen Einfluss mehr, weil es zuvor abgeschlossen wurde. Fr andere, hnliche Projektentwicklungen ist eine Evaluation aber wichtig, denn die Ergebnisse werden in dieser Phase prsentiert und evaluiert. Aufbauend auf den positiven und negativen Seiten eines Projektes knnen sptere Projekte verbessert werden. In diesem Kapitel soll es zunchst um die Schwierigkeiten und Herausforderungen in dieser Arbeit gehen und im Anschluss daran um die positiven Aspekte des Projektes. Abschlieend wird sich dieses Kapitel mit den zuknftigen Einsatzmglichkeiten des Projektes beschftigen. Tabelle 23, Tabelle 24 und Tabelle 25 zeigen alle im Kapitel Pflichtenheft beschriebenen Kriterien (siehe S. 23) in Abhngigkeit ihres letzten aktuellen Bearbeitungsstandes (erledigt, teilweise erledigt oder nicht erledigt). Tabelle 26 zeigt Kriterien, die whrend der Entwicklung entdeckt wurden. Sie waren so wichtig, dass sie vor den Kannkriterien erledigt wurden. Kriterien Authentifizierung Server-Management Filebrowser Dateieneditor Plug-in-System Editorkonfiguration erledigt erledigt erledigt erledigt erledigt erledigt
Tabelle 23 Bearbeitungsstand der Musskriterien

Stand

Kriterien Software-Installation Shell-Terminal Version-Control-System-Integration teilweise erledigt erledigt erledigt

Stand

Tabelle 24 Bearbeitungsstand der Sollkriterien

Kriterien Unix-Dateirechte Debugger Outline Refactoring nicht erledigt nicht erledigt nicht erledigt nicht erledigt

Stand

Tabelle 25 Bearbeitungsstand der Kannkriterien

70

Kriterien Projektansicht erledigt

Stand

Tabelle 26 Bearbeitungsstand der Extrakriterien

Wie aus Abbildung 27 hervorgeht, wurden keine Kannkriterien bearbeitet. Stattdessen wurde eine Projektansicht erstellt, die im Pflichtenheft nicht erwhnt wurde. Damit knnen Benutzer Projekte definieren und in der Projektansicht statt im Dateibaum des Servers arbeiten. Der Vorteil dabei ist, dass die Struktur im Dateibaum verkleinert dargestellt wird und dieser damit bersichtlicher ist (siehe Abbildung 27).

Abbildung 27 Dateibaum vs. Projektansicht

8.1 Bestehende Probleme


Fr Entwicklungsprojekte ist es wichtig, eventuelle Probleme nach Fertigstellung der Arbeit zu identifizieren. Wenn Schwierigkeiten bereits vor Projetbeginn bekannt sind, knnen sie entweder komplett vermieden oder bei Eintritt leichter behoben werden. An dieser Stelle werden lediglich die technischen Probleme gelistet sowie deren mgliche Lsungen. Fr Unternehmensprojekte sollten darber hinaus auch Probleme im Management oder wirtschaftliche Schwierigkeiten betrachtet werden.

8.1.1 Ajax vs. Socket


Das Projekt wurde auf der Basis von ExtJS gebaut. Dieser bietet unter anderem GUI-Elemente sowie Store-Objekte. Die Daten werden von GUI-Elementen dargestellt und von einem Store-Objekt vom Server geholt. Das Tree-Panel zeigt beispielsweise die Dateien der Festplatte in Form eines Baumes an. Dieses Widget wird mit einem sogenannten Tree-Store verbunden (siehe Abbildung 28). Der Tree-Store ist ein clientseitiges JavaScript-Objekt, das fr die Kommunikation mit dem Server zustndig ist. In diesem Fall ist also nur die serverseitige Logik zu programmieren, damit Dateien oder Ordner kreiert, gelistet, gendert und gelscht werden knnen. Der Vorteil der Vorgehensweise, ExtJS zu verwenden, ist es, Arbeit, Zeit und Geld zu sparen. Aus diesem Grund wurde sich fr die Verwendung von ExtJS entschieden.

71

Abbildung 28 Beispiel eines Tree-Panels

Der Nachteil daran ist, dass man von der Implementierung von ExtJS abhngig ist. In diesem Fall betrifft es die Kommunikation zwischen dem Server und dem Browser mit Hilfe von HTTP-Anfragen. Wenn ein Ordner gelscht werden soll, muss die ganze Kommunikation per HTTP bertragen werden. Wenn die serverseitige Logik zu lange dauert, weil zum Beispiel zu viele Dateien zu lschen sind, dann bricht der Browser die Kommunikation ab. Das wiederum hat zum Nachteil, dass nicht angezeigt wird, ob das Lschen funktioniert hat oder nicht. Die Nutzung von HTTP-Anfragen, um neue Informationen vom Server abzurufen, ohne die Seite neu zu laden nennt sich Ajax, was fr Asynchronous JavaScript and XML steht. Dieses Verfahren ist sehr beliebt, weil es benutzerfreundlich ist. Das Problem besteht darin, wie oben bereits beschrieben, dass lange Anfragen einfach abgebrochen werden. Seit lngerem untersttzen moderne Browser die sogenannten Websockets (vgl. Deveria 2012). Websocket ist eine Web-Technologie, um eine Kommunikation zwischen Browser und Server auf der Basis von TCP zu schaffen. Ein Kanal wird einmal gebaut und anschlieend werden dort Nachrichten ausgetauscht. Wenn eine Nachricht abgeschickt wurde, erhlt man eine Besttigung, ob die Nachricht angekommen ist. Die Antwort bekommt man mit einer weiteren Nachricht. Hier gibt es kein(zu langes) Warten. Der Nachteil an dieser Vorgehensweise ist aber, dass nur wenige Libraries die Untersttzung von Websockets anbieten. Eine mgliche Lsung ist es, die Kommunikation zwischen dem Server und dem Browser selber zu schreiben.

8.1.2 Zugriff auf die Festplatte


Die Zugriffe auf die Festplatte sind fr dieses Projekt ein Kernfeature. Sie mssen schnell, sicher und zuverlssig erfolgen knnen. Whrend des Systementwurfs wurde entschieden, die Zugriffe mit Hilfe des Projektes SSHFS sowie des Node.js-Moduls SSHFS-node zu realisieren (siehe Abschnitt ServerArchitektur, Seite 40). Whrend der Entwicklung wurde aber festgestellt, dass in manchen Situationen das SSHFS-Projekt zu langsam reagierte. Die Operationen mit Rekursion knnen lange dauern, falls es viele Dateien und Ordner gibt. In Linux zum Beispiel mssen Ordner mit Inhalt rekursiv gelscht werden, d. h. wenn man einen Ordner mit Unterordnern oder Unterdateien lschen will, wird das Betriebssystem erst die Unterdateien und Unterordner lschen. Das SSHFS-Projekt ist eine Dateisystem-Implementierung, in der die Kommuni72

kation per SSH stattfindet. Jede Rekursion wird also ber das Netz vollzogen, was sehr lange dauern kann, wenn viele Dateien existieren. Aus diesem Grund wurde sich dafr entschieden, diese spezielle Operation ohne SSHFS zu realisieren. Das Lschen wurde per SSH mit einer einfachen rm -rf-Funktion umgesetzt. Die restlichen Operationen, wie das Auflisten oder das Erstellen von Dateien usw., sind jedoch im SSHFS geblieben. Listing 12 zeigt, wie die Lschen-Funktion aufgebaut ist.
fsUtils.delete = (server, path, callback) -> logger.info util.format('Try to delete %s', path) var command = util.format('ssh %s@%s rm -rf /%s', server.user, server.getHostOrIp(), path); child = exec command, (err, stdout, stderr)-> if err logger.errorutil.format('Deletion of %s failed', path) + ' ' + err + ' ' + stderr callback(err)
Listing 12 Lschen-Funktion

Diese Lsung hat jedoch einen Nachteil. SSHFS benutzt einen internen Cache. Wenn man eine Datei mit SSHFS lscht, dann wird der Cache aktualisiert. Wenn man aber die Datei per SSH ohne Hilfe von SSHFS lscht, dann wird SSHFS fr ein paar Sekunden annehmen, dass die Datei immer noch existiert. Wenn der Cache veraltet ist, wird eine Anfrage an den Entwicklungsserver geschickt und dann wird SSHFS die Datei als gelscht markieren. Aus diesem Grund muss der Cache von SSHFS deaktiviert werden. Man knnte auch untersuchen, welche anderen Projekte statt SSHFS nutzbar wren. Mit Hilfe des FTP-Protokolls oder Webdav zum Beispiel knnen Dateien und Ordner ebenfalls editiert werden. Es sollte aber berlegt werden, ob die Nutzung solcher Protokolle keine Sicherheitsrisiken birgt. Auerdem ist die Installation von zustzlicher Software fr FTP und Webdav erforderlich. Ein SSH-Server ist bei der Installation des Betriebssystems oft standardmig installiert und aktiviert. Des Weiteren besteht kein Mechanismus, um die Unix-Rechte einer Datei zu ndern. Auf LinuxServern mssen manche Konfigurationsdateien mit Administratorrechten gendert werden. Fr die Entwicklung ist aber nicht erwnscht, dass Dateien mit Administratorrechten bearbeitet werden. Deswegen wurde dieses Feature als Kannkriterium in dem Pflichtenheft spezifiziert (siehe Abschnitt Unix-Dateirechte, S. 25). Aus zeitlichen Grnden konnte dieses Feature nicht implementiert werden.

8.1.3 Abhngigkeit von Amazon


Das Projekt dieser Arbeit basiert auf dem IaaS-Angebot von Amazon, der Elastic-Compute-Cloud (EC2). Dieses Produkt ist gut etabliert und zuverlssig. Alle Features, die fr das Projekt ntig sind, wie Servermanipulationen und Sicherheitskonfigurationen, sind vorhanden. Gleichzeitig besteht die Gefahr einer Abhngigkeit von Amazon. Es sind insgesamt mehrere Abhngigkeitsfaktoren zu betrachten: 73

Technische Features: Zu Beginn eines Projektes ist es schwer abzuschtzen, ob spter mglicherweise Features von der Cloud gebraucht werden, die nicht von Amazon untersttzt werden. Dieses Problem kann die Entwicklung des Editors blockieren. Auerdem ist man gegenber Problemen, die in der Cloud selbst auftreten, machtlos. Wenn eine technische Strung bei Amazon auftritt, knnen die Entwickler mit dem Editor nicht arbeiten. Dies ist besonders problematisch, wenn Strungen zu ungnstigen Zeitpunkten passieren. Des Weiteren hat man auch keinen Einfluss auf die Performance der Cloud. Bei Amazon dauert die Erstellung eines Servers ungefhr eine Minute. In dieser Zeit kann der Entwickler nicht anfangen zu arbeiten. Kosten: Eine Abhngigkeit besteht des Weiteren von den Preisen, die Amazon verlangt. Fr die EC2 muss pro Stunde gezahlt werden. Fr produktive Server ist dieser Umstand kein Problem, weil sie stndig von Besuchern benutzt werden. Fr Entwicklungsserver allerdings ist die Nutzung der Server anderes gelagert. Sie ist vom Projekt abhngig, deshalb kann es sein, dass manche Server zu gro fr das Projekt sind. Das grte Problem hinsichtlich des Kostenfaktors ist aber, dass man auch dann zahlen muss, wenn die Server nicht benutzt werden. Wenn der Entwickler zum Beispiel fr andere Projekte arbeitet, mssen trotzdem die Server bezahlt werden. Natrlich ist es mglich, die Server automatisch herunterzufahren, wenn sie nicht benutzt werden. Wie aber kann sichergestellt werden, dass die Server wirklich nicht in Benutzung sind? Ein mgliches Problem knnte sein, dass die Entwicklungsserver von einem anderen Editor als dem Nuage-Editor benutzt werden. Hier sind aber die Kontrolle und die berwachung erschwert.

Ein generelles Problem ist, dass die Nutzer von IaaS-Angeboten keinen Einfluss auf die Cloud haben. Es gibt aber ein bekanntes Open-Source-Projekt, das ursprnglich gemeinsam von der Nasa und Rackspace entwickelt wurde und das dieses Problem umgeht. Dabei handelt es sich um das sogenannte OpenStack. Dieses Projekt wurde im Kapitel Fachliches Umfeld (siehe Abschnitt OpenStack, S. 13) bereits erwhnt. Wenn man den Editor auf Basis von OpenStack umsetzen wrde, htte man die Chance, die Cloud, auf der die Entwicklungsserver laufen, zu beeinflussen. Man knnte zudem Lsungen entwickeln, damit die Erstellung von Servern schneller funktioniert. Allerdings gibt es hier einige andere Herausforderungen und Probleme, die man vorher lsen msste, wie zum Beispiel im Bereich Sicherheit oder Verfgbarkeit der Entwicklungsserver. Es gibt keine eindeutige Lsung zwischen EC2, OpenStack oder anderen IaaS-Anbieter. Die Entscheidung hngt davon ab, was genau umgesetzt werden soll und wie das Produkt (der Editor) gewnscht ist.

8.2 Positiver Aspekt


Nicht nur Probleme sind bei der Projektabschlussphase zu diskutieren. Es ist wichtig, auch positive Aspekte des Projektes zu erwhnen. In diesem Abschnitt werden einige gute technische Entscheidungen prsentiert.

74

8.2.1 JavaScript als Programmiersprache


Wie bereits im Kapitel Realisierung betrachtet, ist die Logik des Projektes nur mit der Programmiersprache JavaScript entwickelt worden (siehe S. 54). Clientseitig bestehen dahingehend fast keine anderen Mglichkeiten, serverseitig wurde Node.js (ein JavaScript-Framework) ausgewhlt und fr die Datenbank wurde sich fr MongoDB entschieden. MongoDB ist teilweise in JavaScript geschrieben. Auerdem werden Suchfunktionen wie MapReduce oder Query in JavaScript geschrieben. Die Entscheidung fr diese Programmiersprache hat viele Vorteile mit sich gebracht. In der Web-AppEntwicklung ist es hufig der Fall, dass man einen Server sowie eine Client-Software entwickeln muss. Beide hngen zwar zusammen, sind aber eher als zwei unterschiedliche Projekte zu behandeln. Weil es sich hier um eine einzige Programmiersprache handelt, werden Server und Client sehr hnlich sein. Die gleichen Tools, Libraries und Pattern knnen server- und clientseitig genutzt werden.

8.2.2 Tests
Whrend des Projektes wurden regelmig und parallel zur Projektentwicklung Tests produziert. Auch die Module, die sofort Open Source publiziert wurden, wurden getestet. Mit Hilfe von Tests steigt das Vertrauen in die Software. Die Ergebnisse geben Aufschluss darber, ob Features und Funktionen wie angedacht laufen. Auerdem lsst sich eine getestete Software besser modifizieren (Refactoring).

8.3 Zusammenfassung
Dieses Kapitel gab einen Rckblick auf das gesamte Projekt. Alle positiven und negativen Aspekte der Arbeit sind hier vorgestellt worden. Dies ist fr zuknftige Projekte besonders wichtig, da von den Fehlern als auch von den Erfolgen profitiert werden kann. In diesem Kapitel wurden ausschlielich technische Probleme prsentiert z. B. die Kombination zwei verschiedener Projekte (SSHFS und SSH), um den Zugriff auf die Festplatten zu gewhrleisten. Dies kann bei zuknftigen Entwicklern, die das Nuage-Projekt fortsetzen wollen, zu Missverstndnissen fhren. Bisher wurde jedoch keine Alternative gefunden. Ein anderer wichtiger Punkt ist die Abhngigkeit von Amazon. Wie bereits erwhnt, kann es spter zu Schwierigkeiten kommen, wenn das IaaS-Angebot von Amazon sich ndert oder aber, wenn sich die Anforderungen des Nuage-Servers ndern.

75

9. Zusammenfassung
In der vorliegenden Arbeit ging es um die Entwicklung einer universellen, Cloud-basierten Entwicklungsumgebung. Das Ziel war die Konzeption eines Entwurfes sowie die Erstellung einer Software. Demzufolge wurde das Projekt in einem ersten Schritt prsentiert und anschlieend in allen seinen Entwicklungsetappen von der Idee bis zur Umsetzung beschrieben. Die Arbeit folgte den klassischen Schritten eines Softwareprojektes. Jedes Kapitel widmet sich detailliert jeweils einem Schritt: Die Kapitel Einleitung (siehe S. 1) und Fachliches Umfeld (siehe S. 9) behandelten die Projektinitiierungsphase. Einleitend wurde eine kurze Einfhrung in die Thematik gegeben. Dann wurde in Kapitel Eins die Problematik dargestellt, gefolgt von einer mglichen Lsung, die in dieser Arbeit erarbeitet wurde. Im zweiten Kapitel wurde dann eine Auswahl von CloudLsungen, Desktop-Editoren und Cloud-Editoren prsentiert und evaluiert, wodurch ein berblick ber die gesamte Thematik gegeben wurde. Das Kapitel vier enthlt das Pflichtenheft (siehe S. 23). Dort wurde das Projekt genau spezifiziert. Die Ziele sowie die Funktionen des Produktes wurden in Form von Kriterien erlutert. Dies verhalf dazu, eine bersicht ber das Projekt zu haben, um den Systementwurf zu erstellen. Auerdem wurden die Umgebungen des Produktes dargestellt, sowohl die technische, die z. B. die Hardware- und Software-Anforderungen (siehe S. 36) umfasst, als auch die operative, die den Anwendungsbereich und die Zielgruppen beinhaltet (siehe S. 26). Im Kapitel Systementwurf (siehe S. 38) wurde das Software-Design vorgestellt. Anhand des Pflichtenheftes wurde ein Entwurf des Systems erstellt, welcher in diesem Kapitel prsentiert wurde. Auerdem wurden technische Besonderheiten, wie das Einbinden von Festplatten mit Hilfe des SSHFS-Projektes, erlutert. Auf Basis des Pflichtenheftes und des Designs wurde im Kapitel Realisierung (siehe S. 47) die Implementierungsphase dargestellt, d. h. der technische Aufbau des Produktes wurde erlutert. Dabei sind zunchst die letzten noch offenen Entscheidungen getroffen worden, z. B. die Auswahl der Programmiersprachen und die Bibliotheken. Auerdem wurden die OpenSource-Projekte, die speziell fr diese Arbeit geschrieben wurden, genauer prsentiert. Diese Software-Programme sind unter der MIT-Lizenz frei verfgbar. Das Kapitel Test (siehe S. 65) stellt dar, wie die fr das Projekt vorgenommenen Tests entwickelt wurden und geht zudem darauf ein, welche Tools fr die Testentwicklung verwendet wurden. Test-Szenarien (siehe S. 67 und S. 69) sowie deren Ausgaben (siehe Anhang, S. 105) wurden vorgestellt. Damit lsst sich erkennen, welche Anteile der Software getestet wurden, um zum Beispiel neue Tests zu schreiben, was wiederum die Zuverlssigkeit des Programms verbessert. Schlielich wurde die Projektabschlussphase im Kapitel Ergebnisse (siehe S. 70) behandelt. Dieses Kapitel ging auf die positiven und negativen Aspekte des Projektes ein, um daraus Lehren fr zuknftige Projekte zu ziehen. Auerdem wurden technische Entscheidungen, wie z. B. die Auswahl der Programmiersprache, kurz evaluiert. Dies kann fr zuknftige Projekte von Bedeutung sein.

76

Wie bereits erwhnt, wurde in dieser Arbeit ein universeller Software-Editor entwickelt, der in einer Cloud luft. Dieses Programm nennt sich Nuage. Das Wort ist die franzsische bersetzung fr das deutsche Wort Wolke bzw. das englische Wort Cloud. Die Idee dahinter war zu zeigen, dass der entwickelte Editor, wie eine Wolke auch, nicht auf einen bestimmten Ort festgelegt ist. Das bedeutet, dass auf die eigenen Daten von berall in der Welt aus zugegriffen werden und mit ihnen weitergearbeitet werden kann. Es ist keine zustzliche Software mehr notwendig, sondern lediglich eine Internetverbindung. Diese Eigenschaft macht den grten Vorteil des Projektes aus. Wie eine Webseite kann dieser Editor von jedem Computer der Welt aus benutzt werden, der ber eine Internetverbindung verfgt. Der Editor kann in kritischen Situationen sehr effizient sein, wie z. B. wenn die Software dringend reparieren werden muss. Darber hinaus enthlt der Editor aber auch andere Qualitten. Ein anderes wichtiges Ziel des Produktes war es, seine Universalitt zu gewhrleisten. Der Editor wurde nicht nur fr eine bestimmte Programmiersprache oder Technologie entwickelt, sondern kann fr jedes Software-Projekt, unabhngig von der verwendeten Programmiersprache, verwendet werden. Der Vorteil ist, dass man nicht mehrere Tools erlernen muss, sondern sich auf eines konzentrieren kann. Der Nachteil ist aber, dass die Entwicklung dieses Editors schwieriger war. Man muss universelle Konzepte entwickeln, die fr jede Sprache verwendbar sind. Dies kann mitunter sehr komplex sein, da Sprachen, Systeme und Plattformen sehr unterschiedlich sein knnen. Der Editor basiert auf der Technik der Cloud. Das bedeutet, dass die Entwicklung von Programmen auf den Entwicklungsserver stattfinden. Diese Server gehren dem Benutzer. Mit Hilfe des NuageServers knnen im Browser Dateien bearbeitet oder SSH-Zugnge erstellt werden, um Befehle zu verschicken. Weil die Entwicklungsserver nicht zum Editor gehren, haben Benutzer kompletten Zugriff auf die Server und knnen auch ohne den Nuage-Editor arbeiten. Eine weitere wichtige Eigenschaft der Software ist ihre Anpassbarkeit. Es wurde ein Einstellungsmen integriert, damit die Benutzer den Editor persnlich konfigurieren knnen. Bisher sind Schriftart und Schriftgre konfigurierbar. Eine noch bessere Anpassbarkeit wird zudem dadurch erreicht, dass in den Editor ein Plug-in-System eingebaut wurde. Mit Hilfe von Plug-ins ist es mglich, die Benutzeroberflche anzupassen, um neue Funktionen hinzuzufgen. Im Rahmen dieser Arbeit wurden ein paar Plug-ins beispielhaft programmiert, wie z. B. die Git-Integration. Man kann sich auch viele weitere Mglichkeiten vorstellen, wie z. B. Datenbanken-Management, IaaS-, PaaS- und SaaS-Integration oder spezielle Framework-Features. Doch diese neuen Mglichkeiten knnen hohe Sicherheitsrisiken mit sich bringen. Die Plug-ins werden oft von der Community entwickelt, weshalb nicht auszuschlieen ist, dass manche davon Viren enthalten knnen. Ein Plug-in beispielsweise, welches fr IaaS-Integration zustndig ist, knnte gleichzeitig die Berechtigungsnachweise der IaaS stehlen. Dieses Sicherheitsrisiko besteht fr alle Projekte mit Plug-in-Systemen. Es ist zudem Aufgabe der Community, Systeme, wie z. B. Bewertungssysteme, zu entwickeln, um schdigende Applikationen abzuwehren. Auerdem wre es mglich, dass der Betreiber des Editors die Plug-ins selber kontrolliert. Diese zwei Kontrollen wren optimal. Die Gefahr, dass ein unerwnschter Plug-in trotz Kontrollen dennoch akzeptiert wird, bleibt jedoch bestehen.

77

9.1 Zuknftige Mglichkeiten


Der Editor ist bereits sehr umfangreich gestaltet. Dennoch gibt es Optionen und Wege, um ihn zu verbessern. Im Kapitel Ergebnisse (siehe S. 70) wurden technische Verbesserungen betrachtet. Es gibt noch einige Stellen im Quellcode, die erweitert oder umgeschrieben werden knnten, um den Editor zuverlssiger und effizienter zu machen. Zum Beispiel knnte Websocket statt AJAX fr die Kommunikation zwischen dem Server und den Browsern benutzet werden (siehe S. 71). Dank Websocket wrden lange Anfragen nicht mehr einfach abbrechen. Auerdem knnte der Zugriff auf die Festplatte verbessert werden. Im Moment ist eine Mischung aus SSHFS und SSH fr diese Aufgabe zustndig. Obwohl die aktuelle Methode zuverlssig und funktionell ist, wre es besser, eine Methode zu finden, die nicht aus einer technologischen Mischung besteht. Fr sptere Entwicklungen wre dies einfacher nachzuvollziehen. Das Produkt kann mit Plug-ins erweitert werden. Das Plug-in-System ist im Moment klein und einfach. Fr eine intensive Nutzung des Editors wrde diese Erweiterungsmethode aber nicht ausreichen. Es fehlen Features, beispielsweise fr die Installation von Plug-ins. Derzeit ist die Installation von Plug-ins sehr aufwendig. Die Nutzer mssen die Datei aus einem E-Mail-Anhang oder von einer Webseite herunterladen, um sie danach im Nuage-Server wieder hochzuladen. Die Aktualisierung muss ebenfalls manuell durchgefhrt werden, erst muss das Plug-in gelscht werden, um dann mit der neueren Version nochmal installiert zu werden. Alle diese manuellen Schritte knnten vermieden werden, wenn man das Plug-in-System verbessern wrde. Man knnte zum Beispiel ein Repository kreieren, um alle Plug-ins zentral zu speichern. Damit knnten die Installation und die Aktualisierung automatisch ablaufen. Weiterhin stellt sich die Frage, welche IaaS-Anbieter oder Open-Source-Projekte man nutzen mchte, um die Entwicklungsserver zu managen. Im Moment sind zwei Mglichkeiten programmiert: Amazon-EC2 und Server per SSH. Die erste Variante ist fr neue Benutzer sehr hilfreich, weil sie anfangs keine Server bentigen. Dieser wird fr die Entwicklung erstellt. Man kann aber auch die Server per SSH manuell einbinden. Wenn der Nutzer Projekte auf einem Server gespeichert hat, dann kann er sie im Editor einfach weiterentwickeln. Fr die Zukunft muss sich daher die Frage gestellt werden, welchen genauen Zweck das Projekt weiterhin erfllen soll, um anschlieend entscheiden zu knnen, welche IaaS-Lsungen integriert werden mssen. Zum Beispiel knnte fr einen internen Editor einer Firma eine selbsgehostete Open-Source-IaaSLsung, wie OpenStack, genutzt werden. Der Vorteil hierbei lge darin, dass man die komplette Kontrolle ber die Entwicklungsserver selbst htte. Fr Firmen, die schon Rackspace oder Amazon nutzen, ist ein solches System mglicherweise dennoch nicht geeignet. Die Entscheidung hngt davon ab, wie der IT-Bereich der Firma aufgebaut ist, aber auch von den Zielen, die mit dem Projekt erreicht werden sollen. Wenn man den Editor weiterverkaufen will, dann sollte auch die IT-Struktur zum Business-Modell passen. Eine Mglichkeit wre, alle IaaS-Integrationen mit Hilfe von Plug-ins zu realisieren. Zuerst msste evaluiert werden, ob es mglich wre, mit Hilfe von JavaScript vom Browser aus mit den APISchnittstellen zu kommunizieren. Wenn das der Fall ist, dann kann man ein Plug-in pro IaaS-Anbieter entwickeln. 78

Auf das Geschftsmodell wurde in dieser Arbeit bisher nicht nher eingegangen, obwohl eine solche SaaS-Software wie der vorgestellte Editor neue Mglichkeiten bietet. Im Gegensatz zu DesktopApplikationen ermglichen Software-As-A-Service-Programme es, eine genaue Messung der aktuellen Nutzung der Benutzer vorzunehmen. Daher kann nur die Zeit gezhlt werden, in der man das Programm tatschlich genutzt hat. Fr Amazon-EC2-Instanzen wird zum Beispiel pro Stunde abgerechnet, statt monatlich wie bei anderen Hosts. Soll dieser Editor zur Nutzung kuflich erwerblich sein, so sollte vorher untersucht werden, welches Geschftsmodell sich am besten eignen wrde. Schlielich wurde whrend der Erstellung dieser Arbeit ein funktioneller Software-Editor entwickelt. Dieser kann von seinem Entwicklungszustand her bereits genutzt werden, um damit andere Programme zu erstellen. Der Editor kann zudem erweitert werden und um neue Funktionen ergnzt werden. Allerdings sollte in diesem Fall zunchst untersucht werden, wie er am besten verwendet wird bzw. fr welche Zwecke er in der Firma oder auf dem Markt dienlich sein knnte.

79

10. Abkrzungsverzeichnis
AWS AWS CSS DOM EC2 FTP GUI HTML HTTP HTTPS I/O IDE JS MVC NASA NPM ODM ORM PaaS PHP S3 SaaS SCM SSH SSHFS SVN TCP UML URL VCS WWW XML Asynchronous JavaScript and XML Amazon Web Services Cascading Style Sheets Document Object Model Elastic Compute Cloud File Transfer Protocol Graphical User Interface HyperText Markup Language Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Input/Output Integrated Development Environment JavaScript Model View Controller National Aeronautics and Space Administration Node Package Manager Object Document Mapping Object Relational Mapping Platform As A Service Hypertext Preprocessor Simple Storage Service Software As A Service Software Configuration Management Secure Shell SSH Filesystem Subversion Transmission Control Protocol Unified Modeling Language Uniform Resource Locator Version Control Systems World Wide Web Extensible Markup Language

80

11. Literaturverzeichnis
Amazon-Web-Services (2012): Amazon Elastic Compute Cloud - API Reference. URL: http://awsdocs.s3.amazonaws.com/EC2/latest/ec2-api.pdf (Stand: 24.05.2012). AmazonWebServices (2011):AWS Cloud Tour 2011 | Australia: Event Highlights. URL: https://www.youtube.com/watch?v=uf07L1RUOW4 (Stand: 09.05.2012). Baun, Christian/Kunze, Marcel/Nimis, Jens/Tai, Stefan (2011): Cloud Computing: Web-Basierte Dynamische IT-Services. Berlin: Springer-Verlag. S. 4. Budgen, David (2003): Software Design. Essex: Pearson Education. S. 57. Cloud 9 (2010): Cloud9 IDE | Online IDE - Your code anywhere, anytime. URL: http://c9.io/ (Stand 26.04.2012). Computerwoche.de, o.V. (1975): Interaktives Programmieren als Systems-Schlager. Mnchen: Computerwoche Verlag GmbH. URL: http://www.computerwoche.de/heftarchiv/1975/47/1205421 (Stand: 08.05.2012). Deveria, Alexis (2012): When can I use Web Sockets. URL: http://caniuse.com/websockets (Stand: 03.07.2012). DHTMLX LTD (2012): Easy Binding of DHTMLX with Server-Side Database - dhtmlxConnector - PHP, .NET, Java, ColdFusion, ASP. URL: http://dhtmlx.com/docs/products/dhtmlxConnector/index.shtml (Stand: 21.08.2012). Dionisio, John David/Toal, Ray (2011): Programming with JavaScript: Algorithms and Applications for Desktop and Mobile Browser. Burlington: Jones & Bartlett Learning. S. 46. DocumentCloud (2012): Backbone.js. URL: http://backbonejs.org/ (Stand: 01.09.2012). Dumas, Joseph S./Redish, Janice (1999): A Practical Guide to Usability Testing. Portland: Intellect Books. S. 22-23. Fowler Martin (2000): Refactoring. Wie Sie das Design vorhandener Software verbessern. Mnchen: Addison-Wesly-Verlag. S. xviii. Fowler, Martin (2002): Pattern of Enterprise Application Architecture. Boston: Pearson Education. S. 330. Friedlein, Ashley (2001): Web Project Management. San Francisco: Morgan Kaufmann. S. 4-5. Goincloud (2012): Tweet. URL: http://twitter.com/#!/Goincloud/status/155401464875978752 (Stand 27.04.2012).

81

Google Trends (2012): Google Trends: cloud computing. URL: http://www.google.de/trends/?q=cloud+computing (Stand: 29.05.2012). Hamill, Paul (2004): Unit Test Frameworks. Sebastopol: O'Reilly Media, Inc. S. 1-2. Hemel, Zef (2012): Scaling Cloud9 IDE: a Tale of PAPA and MAMAs. URL: http://c9.io/site/blog/2012/04/scaling-cloud9-ide-a-tale-of-papa-and-mamas/ (Stand: 26.04.2012). Hughes-Croucher, Tom/Wilson, Mike (2012): Node: Up and Running: Scalable Server-Side Code with JavaScript. Sebastopol: O'Reilly Media, Inc. S. 4. ISO/IEC (2001): ISO/IEC 9126-1 - Software engineering - Product quality - Part 1:Quality model. Genve: ISO copyright office. S. 9-10. Kaner C./Falk J.L/Nguyen H. Q. (1999): Testing Computer Software. New York: Wiley Computer Publishing. S. 52. Kleinman, Sam (2012): Basic Nginx Configuration - Linode Library URL: http://library.linode.com/webservers/nginx/configuration/basic (Stand: 06.06.2012). Lemay, Laura/Colburn, Rafe (2011): Web Publishing with HTML and CSS. Indianapolis: Sams Publishing. S. 461. Lienhart, Deborah A. (1997): SoftBench 5.0: The Evolution of an Integrated Software Development Environment. Palo Alto: Hewlett-Packard Company. URL: http://www.hpl.hp.com/hpjournal/97feb/feb97a1.pdf (Stand: 08.05.2012). Linux man-pages (2009): epoll(7) - Linux manual page. URL: http://www.kernel.org/doc/manpages/online/pages/man4/epoll.4.html (Stand: 06.06.2012). Makarov, Alexander (2009): The Big PHP IDE Test: Why Use One And Which To Choose. Freiburg: Smashing Media GmbH. URL: http://coding.smashingmagazine.com/2009/02/11/the-big-phpides-test-why-use-oneand-which-to-choose/ (Stand: 08.05.2012). Netscape (1995): Netscape and Sun announce Javascript, the open, cross-platform object scripting language for enterprise networks and the internet. URL: http://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrele ase67.html (Stand: 06.06.2012). Padua, David (2011): Encyclopedia of Parallel Computing, Volume 4. New York: Springer Verlag. S. 1223. PHP (2012): PHP: Built-in web server - Manual. URL: http://php.net/manual/en/features.commandline.webserver.php (Stand: 06.06.2012). Python (2012): Python2orPython3. URL: http://wiki.python.org/moin/Python2orPython3 (Stand: 07.06.2012). Rackspace (2012): Meet the Great People Behind our Business Web Hosting Services. URL: http://www.rackspace.com/information/aboutus/ (Stand: 20.08.2012). 82

Schlueter, Isaac (2012): Category Archives: release. URL: http://blog.nodejs.org/category/release/ (Stand: 07.06.2012). SIIA (2001): Software as a Service: Strategic Backgrounder. Washington: Software & Information Industry Association. S. 4. Snyder, Carolyn (2003): Paper Prototyping. San Francisco: Morgan Kaufmann. S. 10. Spiegel.de, o.V. (1983): Akten auf Knopfdruck. Hamburg: SPIEGEL-Verlag. URL: http://www.spiegel.de/spiegel/print/d-14020896.html (Stand: 08.05.2012). Statista GmbH (2012): Anteil der Internetnutzer in Deutschland von 2001 bis 2012. URL: http://de.statista.com/statistik/daten/studie/13070/ (Stand: 20.06.2012). Sysoev, Igor (2012): nginx. URL: http://nginx.org/en/ (Stand: 06.06.2012). Szeredi, Miklos (2012): SSH Filesystem. URL: http://fuse.sourceforge.net/sshfs.html (Stand: 26.05.2012). The Apache Software Foundation (2012): worker - Apache HTTP Server. URL: http://httpd.apache.org/docs/current/mod/worker.html (Stand: 06.06.2012). U.S. Government (s.d.): Usability Basics. URL: http://www.usability.gov/basics/index.html (Stand 25.04.2012). Wang, Lizhe/Ranjan, Rajiv/Chen, Jinjun (2011): Cloud Computing: Methodology, Systems, and Applications. Danvers: CRC Press. S. 5. Wayner, Peter (2011): JavaScript conquers the server. URL: http://www.infoworld.com/d/application-development/javascript-conquers-the-server-969 (Stand: 06.06.2012). Wheeler, David A. (2011): How to Evaluate Open Source Software / Free Software (OSS/FS) Programs. URL: http://www.dwheeler.com/oss_fs_eval.html (Stand: 25.04.2012). Young, Alex (2012): Node Roundup: Ryan Dahl Steps Down, Thimble, Mongo Model, Banking.js, Navcodec. URL: http://dailyjs.com/2012/02/01/node-roundup/ (Stand: 08.06.2012).

83

12. Anhang

84

Anhangsverzeichnis Bedienungsanleitung ......................................................................................................................................... 86 Quick Start ................................................................................................................................................ 86 Register ............................................................................................................................................. 86 Login ............................................................................................................................................... 87 Logged in ........................................................................................................................................... 87 Start to Code............................................................................................................................................. 88 Create a server................................................................................................................................... 88 Create a project ................................................................................................................................. 89 Code................................................................................................................................................ 92 Shell. ............................................................................................................................................... 93 Advanced Features ................................................................................................................................... 95 Git. ............................................................................................................................................... 95 Search ................................................................................................................................................ 97 Plugin. ................................................................................................................................................ 98 Settings .............................................................................................................................................. 99 Nuage Installation ........................................................................................................................................... 101 Prerequisite ............................................................................................................................................ 101 Installation of needed Libraries ............................................................................................................... 101 Installation of SSHFS ............................................................................................................................... 102 Installation of MongoDB ......................................................................................................................... 102 Installation of Node.js ............................................................................................................................. 102 Installation of Nuage Server .................................................................................................................... 103 Start Nuage ............................................................................................................................................. 103 Advanced ................................................................................................................................................ 103 Ausgaben der Tests ......................................................................................................................................... 105 Servertests.............................................................................................................................................. 105 Browsertests ........................................................................................................................................... 110 Use-Case-Diagramme ...................................................................................................................................... 111 Wireframe-Prototypen .................................................................................................................................... 115

85

Bedienungsanleitung
In diesem Abschnitt werden drei Anleitungen prsentiert: Quick Start erklrt die ersten Schritte in dem Editor. Die Anleitung Start to Code erlutert, wie man mit der Programmierung beginnt. In Advanced Features werden die fortgeschrittenen Features prsentiert.

Diese Anleitungen wurden zwischen dem 15. und dem 20. Juli 2012 verfasst. Es kann folglich sein, dass manche Screenshots bereits veraltet sind. Damit ein greres Publikum von diesen Anleitungen profitieren kann, wurden alle drei auf Englisch geschrieben.

Quick Start
In this guide you will learn how to start with the Nuage Editor. It's assumed that Nuage is accessible via the following URL: http://localhost:3000.

Register
To register visit the following URL: http://localhost:3000/register. Then fill in the register form.

AWS Access Key ID and Secret Access Key are optional. If you want to use AWS EC2 Instances you need to fill in both fields. Nuage can be used with common servers through SSH, if you don't have any Amazon account.

86

With clicking the button Register, your account will be created and you will be automatically logged in.

Login
If you already have an account, visit the following URL: http://localhost:3000/login. Fill in the login form.

Logged in
After being logged in, you should see a screen like the following.

This is the interface of the Nuage Editor.

87

Start to Code
It's assumed that a user account was created and that the user is logged in. If not please read the tutorial "Quick Start".

Create a server
To insert a server, open the server list by clicking on "Server > List".

Then click on "Add server"

A new tab appears where it's possible to add a new server.

The username and hostname are of no importance for a AWS server. Then click on "File > Save".

88

A new server should be listed in the server list now.

It takes some time until the server is finished and ready to be used. It's done when you can see the files from the file browser. Right-clicking on Refresh will help here.

If you don't have any AWS account, you also can add a server through SSH. This feature only works if you fill in a valid IP and username. Furthermore you need to enter the public key of the Nuage Server in the authorized_keys file. The public key can be found at "Help > Public key".

Create a project
It's possible to start coding right now, but it's more comfortable to create a project. So you now create a new project. Open the file browser and navigate to the home directory.

89

Then create a new folder by right-clicking on the directory ec2-user and then click on "Create folder".

You can name it 'my-new-project' and click on Save.

90

Now you can create a project in this folder. Just right-click on the folder and click on "Create Project".

Then you need to fill in the form like that:

Then click save and a new project should be created on the Project viewer.

Please notice that at this point, due to a small bug, you will maybe need to refresh the page. Only in this way you can see the file of the project.

91

Code
You can now start to code. Create a new file, right-click on "New Project" and then click on "Create file".

Name it like "main.c" and after clicking on Save a new file should appear in the folder "New project".

Double-click on the file to open it. Write the code of this file, for example a simple Hello World program.

That's it, you've just written your first program with the Nuage Editor. Now you just need to compile and execute it.

92

Shell
Like any common development machine, Nuage Editor includes a Shell Terminal. It can be opened with a right-click on any directory and project, followed by a click on "Open Shell".

A new tab at the bottom of the Nuage Editor should appear.

Before you compile the program you need to install the development tools. That can be realized by writing the following: sudo yum groupinstall "Development Tools". Please notice that copy paste does not work in the shell for the moment. Confirm your input and wait a few seconds.

93

After that you can compile your new program: $ gcc main.c and execute it: $ /a.out.

94

Advanced Features
It's assumed that a user account was created and that the user is logged in. If not please read the tutorial "Quick Start". This tutorial is based on "Start to code".

Git
The Nuage Editor has an integration of Git. To create a new Git repository, just right-click on a directory or a project. Then click on "Git > Init".

The repository will be initialized and a directory ".git" will be created.

You can then commit your file to the repository. To do this, just right-click on the same directory or project. Then click on "Git > Commit".

95

You can write a message and validate it by clicking on OK.

Now the commit will be sent to the Repository. A validation message is displayed in the Log tab: [Monday, July 16th 2012, 2:08:29] [debug] start shell command cd /home/ec2-user/my-new-folder; git add .; git commit -m "first commit" on server My new server [Monday, July 16th 2012, 2:08:32] [success] shell command successfully sent

You can verify it by writing git log in a shell.

Nuage integrates 3 other Git features: Clone, Push and Pull.

96

Search
Nuage has also some search and replace functions. As usual, right-click on a directory or a project and click on "Search".

This will open a new form where it's possible to start a new search. For example, write "World" in the search field and click on Search.

To replace "world" by "Welt", just write "Welt" in the replace field and click on Search and Replace. A confirmation should appear in the Log tab: [Monday, July 16th 2012, 2:26:41] [debug] start shell command grep -ri "World" /home/ec2user/my-new-folder | wc ; grep -rl "World" /home/ec2-user/my-new-folder | xargs sed -i "s/World/Welt/g" on server My new server [Monday, July 16th 2012, 2:26:43] [success] shell command successfully sent [Monday, July 16th 2012, 2:26:43] [success] Replace successfully executed (3 replacements done). You can now reopen "main.c" to see the changes.

97

Plugin
Nuage Editor also integrates a simple but powerful plugin system. Git Integration and Search and Replace feature are both created with a plugin. You can open the list of plugins by clicking on "Edit > Plugin > List".

New users will automatically start with 3 plugins: Advanced search Saver shortcuts Git integration

With a right-click on a plugin you can see every action thats possible to do: Edit: It will open a tab to edit the name, description and version number. Edit Code: It opens a tab to edit the code of a plugin. Export: This action exports the plugin. It starts the download of a JSON file with every information about the plugin (code included). After that you can share it easily. Other users can use the function import to use your plugin. Delete: This will delete the plugin.

98

The edit form of a plugin should look like this. Here you can change the name, the description and the version of the plugin. The field Shortcut Weight is useless for the moment.

If you want to edit the code of the plugin, the Nuage editor will open a JavaScript page with the code that you can edit.

In the Developer Documentation you can find an API description that explains how to interact with the Nuage Editor. It explains, for example, how to add new Button, how to open a new tab etc.

Settings
Settings can also be changed. For the moment it's only possible to change the font size and the font family. To do this, just click on "Edit > Settings".

99

Settings will change in real-time, you can open a file or a plugin code to see how your code is changing.

100

Nuage Installation
In diesem Abschnitt wird die Installation des Nuage-Editors auf einem Server prsentiert. Damit ein greres Publikum von dieser Anleitung profitieren kann, wurde sie auf Englisch geschrieben. This guide describes how to install the Nuage Editor Server on an Amazon EC2 instance. Here are the characteristics of this instance: AMI: Amazon Linux AMI ID ami-aecd60c7 (x86_64) Instance Type: Micro (t1.micro) Public DNS: ec2-23-22-69-111.compute-1.amazonaws.com

Prerequisite
Prerequisite is a running instance with a reachable SSH server. You can open an SSH connection to this server: ssh ec2-user@ec2-23-22-69-111.compute-1.amazonaws.com

Installation of needed Libraries


First check that your instance is updated, if not please do it. $ sudo yum update Then you need to install the group "Development Tools". It contains gcc and other tools useful for the development. $ sudo yum groupinstall "Development Tools" This package is for Node.js $ sudo yum install openssl-devel Git should be already install, if not you need to do it. $ sudo yum install git This package is for Nuage Server $ sudo yum install libxml2-devel.x86_64

101

Installation of SSHFS
Download, configure, compile, install the last version of SSHFS sudo yum install fuse.x86_64 fuse-devel.x86_64 fuse-libs.x86_64 glib2-devel.x86_64 wget http://downloads.sourceforge.net/project/fuse/sshfs-fuse/2.4/sshfs-fuse-2.4.tar.gz tar xvzf sshfs-fuse-2.4.tar.gz cd sshfs-fuse-2.4 ./configure make sudo make install

Installation of MongoDB
The last version of MongoDB can be found here: http://www.mongodb.org/downloads (Date: 30.08.2012). $ wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.2.0.tgz $ tar xvzf mongodb-linux-x86_64-2.2.0.tgz Start MongoDB $ cd mongodb-linux-x86_64-2.2.0 $ mkdir data $ ./bin/mongod --dbpath data &

Installation of Node.js
Nvm (https://github.com/creationix/nvm/ Date: 09.07.2012) is a Version Manager for Node. It's easier to manage Node.js with it, so first install it. $ git clone git://github.com/creationix/nvm.git ~/nvm $ echo ". ~/nvm/nvm.sh" >> .bashrc Then open a new bash to make nvm available. $ bash Now install Node.js (this can take some times) $ nvm install v0.8.8

102

Make v0.8.1 default version $ nvm alias default v0.8.8 $ nvm use v0.8.8 Then Node.js should be available $ node --version v0.8.8

Installation of Nuage Server


Download and install Nuage Server (it could take a while too) $ npm install http://dl.dropbox.com/u/14316104/nuage.tar.gz

Start Nuage
Finally start the server $ cd node_modules/nuage $ ./bin/nuage Make sure that your server's port (here 3000) is reachable. If you use an Amazon EC2 instance, then the security group should have the right configuration. You can find more information here http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-network-security.html Then call you should be able to call this URL to login: http://ec2-23-22-69-111.compute-1.amazonaws.com:3000/login And this URL to register: http://ec2-23-22-69-111.compute-1.amazonaws.com:3000/register

Advanced
It's possible to override some configuration like port, database ... To do that, just create a json file for example: config.json. Edit it, let say you want to change the port:

103

{ "port": 80 } Then run the server like that: $ ./bin/nuage -c config.json You can find the list of all configuration possibilities in the file "config.coffee".

104

Ausgaben der Tests


In diesem Abschnitt werden die Ausgaben der Tests prsentiert. Sie wurden am 13. Juli 2012 ausgefhrt. Zuerst werden Server-Tests aufgezeigt und im Anschluss daran die Browsertests.

Servertests
[ec2-user@domU-12-31-38-04-8A-1B ~]$ npm test > nuage-editor@0.1.0 test /home/charles/Repositories/Nuage > vows test/vows/*-test.coffee --spec

Try the AWS Cloud Connector library


when loading fixtures

we got no error
when Creating an ec2 instance with valid parameters

we got no error
when waiting that instance is running

we got no error
when checking that the created instance is running

we got no error instance is running


when stopping the created instance

we got no error current state is stopping


when waiting that instance is stopped

we got no error
when checking that the created instance is stopped

we got no error instance is stopped


when starting the created instance again

we got no error current state is pending


when waiting that instance is running again

we got no error
when restarting the created instance

we got no error
when deleting the created instance

we got no error current state is shutting-down

105

Try the SSH Cloud Connector library


when loading fixtures

we got no error
when Creating an ec2 instance with valid parameters

we got no error
when checking that the created instance is running

we got no error instance is running


when stopping the created instance

we got no error
when starting the created instance again

we got no error
when restarting the created instance

we got no error
when deleting the created instance

we get no errors
when checking that the created instance is running

we got no error instance is running Try the fs2http integration


when loading fixtures

we got no error
when login with valid user

we got no error
when listing files

we got no error
when unmounting server

we got no error Try the server routes


when loading fixtures

we got no error
when login with valid user

we got no error the request is redirected


when creating a server

we got a server id
when waiting that instance is running

106

we got no error
when getting the list of all servers

we got no error we only have one server


when waiting until instance is ready to receive ssh connection

we got no error
when reading content of server root

we got no error we could see root, etc and home


when unmounting server

we got no error
when deleting the server

we got no error it worked


when getting the list of all servers again

we got no error we only have one server Try login


when loading fixtures

we got no error
when login with bad user

we got no error
when login with valid user

we got no error
when calling editor

should have editor


when logging out

should be logged out


when calling editor again

should ask for password Try the server routes


when loading fixtures

we got no error
when login with valid user

we got no error
when creating a server

we got no error
when getting information about the server

107

we got no error
when restarting the server

we got no error
when stopping the server

we got no error
when getting information about the server after stopping

we got no error
when starting the server

we got no error
when updating the server

should work
when getting the list of all servers

should work
when getting information about the updated server

should read the new name


when deleting the server

should work
when getting information about the missing server

should work
when deleting the missing server

should work
when getting the list of all servers again

should work Try the server routes


when loading fixtures

we got no error
when login with valid user

we got no error
when creating a server

we got no error
when waiting that instance is running

we got no error
when getting information about the server

we got no error
when restarting the server

we got no error
when waiting that instance is restarting (after restart)

we got no error
when stopping the server

we got no error

108

when waiting that instance is stopped

we got no error
when getting information about the server after stopping

we got no error
when starting the server

we got no error
when waiting that instance is running again

we got no error
when updating the server

should work
when getting the list of all servers

should work
when getting information about the updated server

should read the new name


when deleting the server

should work
when getting information about the missing server

should work
when deleting the missing server

should work
when getting the list of all servers again

should work Try the server routes


when loading fixtures

we got no error
when login with valid user

we got no error
when post ssh command

we got no error Try the timestampable plugin


when creating a new server

we got no error createdAt and updatedAt are equals


when waiting 3 seconds

we got no error
when updating the server

we got no error createdAt and updatedAt are not equals anymore

109

Try the server api


when loading fixtures

we got no error
when login with valid user

we got no error
when reading the list of servers

we got no error
when logging out

should be redirected
when logging in with a user without servers

should confirm authentication


when updating a server

should not work


when getting the list of servers

should have nothing


when deleting server

should fail
when reading server

should fail OK 102 honored (422.032s)

Browsertests
[ec2-user@domU-12-31-38-04-8A-1B ~]$ npm run-script casperjs > nuage-editor@0.1.0 casperjs /home/charles/Repositories/Nuage > sh test/casperjs/test.sh PASS Anonymous user should be redirected PASS User is NOT redirected after sending wrong credentials PASS Anonymous user should be redirected PASS User is redirected after sending right credentials PASS 4 tests executed, 4 passed, 0 failed.

110

Use-Case-Diagramme
Hier werden die Use-Cases, die whrend der Realisierung des Pflichtenhefts gemacht wurden, dargestellt. Die Funktionen sind gruppiert und markiert, um zu zeigen, ob sie Muss- Soll- oder Kannkriterien sind. Die Legende wurde wie folgt definiert: die Musskriterien sind rot, die Sollkriterien gelb und die Kannkriterien sind grn markiert.

111

112

113

114

Wireframe-Prototypen
In diesem Teil des Anhangs werden die Prototypen des Projektes prsentiert. Diese wurden am Anfang der Arbeit erstellt, um eine Analyse vorzunehmen. Allerdings wird hier nur ein Teil der Wireframes gezeigt, die komplette Liste befindet sich auf der CD 63.

Login-Formular

63

Siehe Ordner Prototypen auf der CD.

115

Hauptscreen des Editors

116

Suchen und Ersetzen-Funktion

117

Server-Liste

118

Server Lschen Besttigung

119