Beuth Hochschule für 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
Kunigundenstraße 1 (II)
12105 Berlin
Abgabetermin: 03.09.2012
Danksagung
Als erstes möchte ich mich bei Herrn Prof. Dr. Edlich von der Beuth Hochschule für Technik Berlin für
die Vorlesungen im Bereich Cloud-Computing sowie für die äußerst hilfreiche und durchgehend un-
terstützende Betreuung dieser Arbeit herzlich bedanken. Ohne ihn würde diese Arbeit nicht in dieser
Qualität bestehen.
Ebenfalls bedanken möchte ich mich bei Herrn Prof. Dr. Solymosi von der Beuth Hochschule für
Technik Berlin für die Betreuung des Projektes.
Auch möchte ich mich für die Hilfe, die mir nicht nur während dieser Arbeit, sondern während des
gesamten Studiums seitens der Studienverwaltung sowie der Sekretariate im Fachbereichs VI der
Beuth Hochschule für Technik Berlin zuteilwurde, bedanken. Beide Entitäten 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 für deren Hilfeleis-
tungen, Ratschläge und Kritik, die mir für diese Arbeit sehr geholfen haben.
Nicht zuletzt gilt mein Dank meinen Freunden und meiner Familie für ihre moralische Unterstützung
während der Masterarbeit sowie des Studiums insgesamt.
Charles Bourasseau
Berlin, September 2012
Diese Arbeit ist urheberrechtlich geschützt.
© 2012 Charles Bourasseau
Das Projekt, das im Rahmen dieser Arbeit produziert wurde, ist unter der Lizenz „GNU General Public License Version 3“ frei verfügbar. Einige Softwares, die in dieser Arbeit benutzt wurden, unterliegen teilweise anderen Lizenzen.
Kontakt zum Autor über E-Mail: [email protected]
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 Benutzeroberflächen-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 Lösungen ...................................................................................................................... 9
3.1.3 Typische Funktionalitäten ........................................................................................................ 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 Produktübersicht ..................................................................................................................... 27
4.3.2 Produktfunktionen ................................................................................................................... 27
4.3.3 Produktdaten ........................................................................................................................... 31
4.3.4 Produktleistungen .................................................................................................................... 32
4.4 Qualitätsanforderungen ..................................................................................................................... 33
4.5 Benutzeroberfläche ............................................................................................................................ 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 Abhängigkeit 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 Zukünftige Möglichkeiten ................................................................................................................... 78
10. Abkürzungsverzeichnis ................................................................................................................................ 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 Erklärung des Prototyps .............................................................................. 35
Abbildung 14 Client-Server-Architektur ............................................................................................... 38
Abbildung 15 Globale Architektur des Projektes .................................................................................. 39
Abbildung 16 Server-Architektur .......................................................................................................... 40
Abbildung 17 Entitäten-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 Qualitätsanforderungen ....................................................................................................... 34
Tabelle 9 Struktur des Menüs............................................................................................................... 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 Häufigkeit 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-Ausführung von Tests ............................................................................................... 66
Listing 10 CasperJS-Beispiel .................................................................................................................. 68
Listing 11 CasperJS-Screenshot-Beispiel ............................................................................................... 69
Listing 12 Löschen-Funktion ................................................................................................................. 73
1
1. Einleitung Das aus dem Englischen stammende Wort „Cloud”, zu Deutsch „Wolke“, bezeichnet einen Bereich
der Informatik, der unsere Welt grundlegend verändert hat und auch zukünftig noch weiter beein-
flussen wird. Der Name dieser Technik weckt in uns die Vorstellung realer Wolken. Diese großen
Wasserreservoirs, deren Entstehungs- und Abregungsprozesse nicht vom Menschen beeinflusst wer-
den können, sind Bestandteil und gewissermaßen auch Grundlage unseres täglichen Lebens. Das
Prinzip der Cloud bezieht sich auf eben dieses Bild der ständigen Verfügbarkeit und Autonomie, auch
wenn es sich in der Informatik um Daten handelt, und nicht um Wassermoleküle. Die in der „Daten-
wolke“ gespeicherten Daten stehen einer Person folglich immer und überall online zur Verfügung.
Das Cloud-Computing ist eine Reaktion auf die weltweit steigende Internetnutzung, auf die die In-
formatik zu reagieren versucht. In Deutschland beispielsweise ist die Anzahl der Internetnutzer von
37 Prozent der Bevölkerung im Jahr 2001 auf etwa 75 Prozent im Jahr 2011 gestiegen (siehe Abbil-
dung 1, vgl. Statista GmbH 2012). Gleichzeitig wuchs die Anzahl von internetfähigen Geräten: Neben
Laptops besitzen immer mehr Menschen Smartphones, Tablets und andere Geräte. Steigende Nut-
zerzahlen sowie eine wachsende Anzahl internetfähiger Geräte bedeuten für die Betreiber von Web-
seiten eine erhöhte 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 für Webserver eine Herausforderung dar, denn jeder
einzelne Computer verfügt nur über eine begrenzte Kapazität. Zu viele Nutzer lasten die Ressourcen
eines Servers aus, sodass an diesen keine neuen Anfragen mehr gestellt werden können. 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 Ma-
schinen 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 Ma-
nagement von Servern vereinfacht.
2
Das Cloud-Computing ist nicht nur die technische Antwort auf unser verändertes Nutzungsverhalten,
es hat umgekehrt auch unsere Internetnutzung verändert. Software-As-A-Service (kurz: SaaS) findet
inzwischen immer mehr Anwendung, sei es für E-Mails, Texte, Dokumente, Fotos, Spiele usw. Für fast
jede Software gibt es inzwischen eine SaaS-Alternative.
Die Mobilität, die die Cloud dem Menschen ermöglicht, ist eine der wichtigsten Eigenschaften des
Cloud-Computing. Im Urlaub, auf Geschäftsreise oder auf dem Weg zur Arbeit ist es äußerst prak-
tisch, wenn man immer über die gleiche Software verfügt und dieselben Daten nutzen kann. Egal ob
auf dem Handy, Laptop oder Tablet, dank der Cloud können 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 unmöglich ist? Um Antworten auf diese Fragen
zu geben, soll in der hier vorliegenden Arbeit eine Entwicklungssoftware in eine SaaS-Form umge-
wandelt werden, wie nachfolgend erläutert wird.
1.1 Problemstellung Das Projekt, das in dieser Arbeit entwickelt wird, beschäftigt sich mit einem speziellen Problem des
Cloud-Computing, nämlich der Programmierung in der Cloud. Ohne die Cloud müssen Entwickler, die
von unterwegs aus arbeiten oder ihre Ergebnisse Kunden präsentieren wollen, einen Laptop mit
sämtlicher Entwicklungssoftware mit sich führen. Dies kann in bestimmten Situationen sehr um-
ständlich sein.
Außerdem müssen manche Entwickler mit verschiedenen Versionen einer Sprache entwickeln kön-
nen. Natürlich existieren dafür Version-Manager-Tools, wie zum Beispiel Rvm1 für Ruby, aber die
Nutzung solcher Programme ist mitunter kompliziert und setzt häufig nicht nur Kenntnisse in der
Programmiersprache, sondern auch über das Tool sowie das Betriebssystem voraus.
Zudem erschwert eine klassische Software die Kollaboration. Dateien müssen zum Beispiel per E-Mail
ausgetauscht werden und können verloren gehen. Auch hierfür existiert bestimmte Software, die
sogenannten Version-Control-Systeme (VCS), wie zum Beispiel Git oder SVN. Für die Nutzung solcher
Programme benötigt man allerdings bestimmte Vorkenntnisse und die Software muss zuvor instal-
liert werden.
Ein weiteres Problem besteht darin, dass man andere Programme wie Webserver, Framework usw.
installieren muss, um den Quellcode ausführen zu können.
Mit einem browserbasierten Software-Editor in der Cloud können alle eben beschriebenen Probleme
gelöst werden. Zum einen ist die Kollaboration in der Cloud vereinfacht, denn andere Mitarbeiter
oder Kunden können eingeladen werden, um sich das Projekt anzuschauen oder davon teilzuneh-
men. Zum anderen ist keine Software-Installation mehr nötig. Des Weiteren können 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).
3
mehr erforderlich ist. Letztlich gehen mit einem browserbasierten Software-Editor keine Daten mehr
verloren oder werden zerstört.
1.2 Zielstellung In dieser Arbeit soll ein Cloud-basierter Software-Editor entworfen und entwickelt werden. Das Pro-
jekt wurde „Nuage" genannt, was „Wolke“ auf Französisch bedeutet. Cloud-basiert bedeutet, dass
keine Dateien heruntergeladen und gespeichert werden müssen und stattdessen alle Operationen
auf einem Server laufen. Folgende Eigenschaften soll der Software-Editor erfüllen:
1. Für die Verwendung des Projektes soll ein Browser ausreichen.
2. Der Editor muss universell sein und keine Einschränkungen bezüglich der Programmierspra-
chen aufweisen.
3. Damit der Benutzer über mehr Freiheit und Mobilität verfügt, sollen sämtliche Dateien auf
einem Server gespeichert werden können.
Eine browserbasierte Software besitzt gegenüber herkömmlicher Software mehrere Vorteile. Sie
benötigt lediglich eine Internetverbindung, weswegen man von überall aus, sei es im Restaurant oder
auf dem Flughafen, weiterarbeiten kann und entsprechend Zeit spart. Außerdem kann man seinen
Arbeitsplatz frei wählen und muss nicht mehr zwingend ins Büro gehen. Des Weiteren ist kein spezi-
eller Computer, etwa mit hoher Rechenleistung oder ausreichend Speicherplatz, erforderlich. Um auf
die eigenen Daten zugreifen zu können, braucht man sich nur online einzuloggen. Das ist insofern
praktisch, als dass beim Kunden keine Software-Installation mehr vorzunehmen ist, um die Funkti-
onsweise des Produktes bis ins Detail zeigen zu können (inklusive Quellcode und Server-Integration).
Browserbasierte Applikationen sind mit Handys verwendbar. Diese Möglichkeit soll jedoch im Rah-
men der Arbeit an dieser Stelle nur erwähnt, 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 Entwicklungs-
server verwalten können. Mit dem Server-Verwaltungsfeature ist es möglich, die Projekte oder Kun-
den auf verschiedene Server aufzuteilen.
4
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 für 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. Hauptfunktionalitäten, die die Software am Ende des
Projektes können soll, müssen zunächst geplant werden. In dieser Phase werden die technischen als
auch die Software-Design-Probleme nur wenig beachtet. Trotzdem kann es vorkommen, dass Funkti-
onalitäten geplant werden, die sich später als nicht umsetzbar herausstellen. Diese sollten so früh
wie möglich entdeckt werden. Daher sollte eine grobe erste technische Prüfung vorgenommen wer-
den. Das Software-Design kann an späterer 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 erklärt, d. h. hier findet sich eine Beschreibung dessen, was die
Software alles können soll.
Während der Konzeptionsphase wird ein Prototyp erstellt. Dieser enthält die Grundstrukturen des
Projektes und hilft dabei, einen Überblick über das Projekt zu gewinnen. Man spricht in diesem Zu-
sammenhang auch von einem Wireframe-Prototypen. Ein Wireframe ist ein Schwarz-Weiß-Schema,
das die Struktur der Benutzeroberfläche skizzenhaft zeigt. Somit ist sichergestellt, dass man sich in
der Konzeption nicht in Details verliert, sondern sich auf die wesentlichen Inhalte, Ideen und Funkti-
onen konzentriert (vgl. Snyder2003, S. 10). Abbildung 3 zeigt einen Ausschnitt eines Wireframe-
Beispiels. Für das Projekt der vorliegenden Masterarbeit wurden mehrere solcher Wireframes erstellt
(siehe Anhang S. 115).
Abbildung 3 Beispiel eines Wireframes
5
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. jegli-
che Anforderungen sowie alle Muss- und Kannkriterien müssen dafür beachtet werden. Außerdem
sollte man sich auch über die Zukunft der geplanten Software Gedanken machen. Die Entschei-
dungen, die in dieser Phase getroffen werden, haben Auswirkungen auf das gesamte Projekt. Das
Treffen ungünstiger Entscheidungen, kann das dazu führen, dass man später größere Änderungen an
der Software vornehmen muss, was wiederum Zeit und Geld kostet. Es ist wichtig, dass das Software-
Design ausreichend Flexibilität besitzt, damit weitere Änderungen später vorgenommen werden
können (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 verständlich, aus welchen Bestandteilen sich die Software zusammensetzt und wie die
verschiedenen Teile der Software interagieren können. Es ist wichtig, dass eine Software
sinnvoll strukturiert wird, damit man die Komplexität der Implementierung reduziert.
Klassendiagramm: Dieses Schema zeigt, wie die Software intern programmiert wird. Ge-
wöhnlich 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, Benutzeroberflächen, Methoden, Ei-
genschaften usw. definiert. Wenn das Software-Design sich ändert, sollten auch die Doku-
mente dementsprechend aktualisiert werden.
Das Architektur-Design und das Klassendiagramm werden im Kapitel „Systementwurf“ genauer er-
klärt (siehe S. 38).
2.3 Benutzeroberflächen-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.):
Verständlichkeit (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 könnte, um spezifische Aufgaben zu erledi-
gen.
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 können. 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 können.
Attraktivität (Attractiveness): Die Software muss optisch ansprechend sein, damit die Nut-
zungsmotivation steigt.
6
Usability-Konformität (Usability Compliance): Die Usability-Konformität einer Software sorgt
dafür, dass die Nutzer schneller unbekannte Funktionen verstehen können. Es ist zum Bei-
spiel wichtig, dass Farben konsequent verwendet werden.
Obwohl diese Phase, in der das Benutzeroberflächen-Design nach Usability-Kriterien entwickelt wird,
für den Erfolg eines Projektes zwingend notwendig ist, wird sie in dieser Arbeit nicht intensiv behan-
delt. Dennoch werden in der Projektentwicklung und Umsetzung, auf der der Schwerpunkt dieser
Arbeit liegt, die Grundlagen des Benutzeroberflächen-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 Klassen-
diagramms, 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 Pro-
grammiersprache und Technologien der Software auswählen. Unter Umständen hängen die-
se von den Anforderungen oder der Architektur ab. Wenn sie bei der Implementierung je-
doch frei gewählt werden können, so sollten diese Entscheidungen ganz am Anfang der Pha-
se getroffen werden.
Bibliotheken und Framework-Recherche: Ein weiterer wesentlicher Punkt, zu Beginn der
Projektphase, ist die umfassende Recherche nach Projekten, die man für 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 Soft-
ware und welchen Tools gearbeitet wird. Datei-Editoren, Debugger-Tools und Projekt-
Management-Tools gehören zu den wichtigsten Werkzeugen, die für die Programmierung
benötigt werden.
Programmierung: Diese Etappe beinhaltet die Kernarbeit der Entwicklung, in der der Quell-
code 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 verständlich erklärt.
o Ticket: Ein Ticketsystem unterstützt 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 für das Projekt verwendeten
Sprachen, Technologien, Bibliotheken und Tools erläutert und begründet. Die Bedienungsanleitung
7
befindet sich im Anhang (siehe Anhang S. 86) und der Quellcode wurde auf der beiliegenden CD do-
kumentiert (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, kön-
nen während der Testphase eines Projektes erreicht werden:
Die Anzahl von Fehlern im Quellcode reduzieren.
Die Benutzeroberfläche verbessern.
Die Performance sichern.
Die Funktionalitäten bestätigen.
Änderungen im Quellcode beschleunigen.
Um die verschiedenen Ziele zu erreichen, stehen unterschiedliche Testformen zur Verfügung, die
kurz erläutert werden sollen:
Unit-Tests: Bei Unit-Tests wird mit Hilfe von Testklassen der Quellcode überprüft. Ziel ist es,
soviele einzelne Funktionen der Software wie nur möglich zu testen. Unit-Tests sollten ein-
fach gehalten werden. Sie sollten sich zudem auf den Test der Methoden beschränken und
nicht die Interaktion zwischen Klassen oder Services einer Software testen (vgl. Hamill 2004,
S. 1f.).
Funktionelle Tests: Mit Hilfe der Dokumente, die während der Analyse sowie der Software-
Design-Phasen erstellt wurden, kann man funktionelle Tests entwickeln. Sie prüfen, ob der
Quellcode diese Dokumente korrekt umsetzt und ob sie richtig implementiert sind (vgl. Ka-
ner/Falk/Nguyen 1999, S. 52).
Integrationstests: Integrationstests überprüfen, ob die Klassen oder Komponenten mitein-
ander wie erwartet funktionieren. Diese Testform kann man als erweitere Form von Unit-
Tests verstehen, weil sie die Interaktion zwischen Klassen testen.
Usability-Tests: Usability-Tests sind mitunter sehr kostenintensiver. Sie werden von tatsäch-
lichen Nutzern ausgeführt. Diese Testpersonen haben bestimmte Aufgaben zu erledigen. Die
Idee ist dabei, dass man die Usability der Software extern prüft (Dumas/Redish 1999, S. 22f.).
Last-Tests: Mit Last-Tests kann die Performance einer Software evaluiert und getestet wer-
den. Bezogen auf eine Webseite geht es zum Beispiel darum, wie vielen Nutzern der Server
innerhalb weniger Sekunden antworten kann.
Für die Testphase sind des Weiteren folgende Prozessfragen zu beantworten:
Wann werden die Tests durchgeführt?
Wann werden die Tests korrigiert?
Wer korrigiert die Tests?
usw.
8
Es existieren spezielle Tools wie z. B. das kontinuierliche Integrations-System, die solche Prozessauf-
gaben erleichtern.
Im Kapitel „Test“ (siehe S. 65) werden die Tests des in dieser Arbeit entwickelten Projektes präsen-
tiert. Es wird erklärt, welche Tests realisiert und welche weggelassen wurden. Außerdem werden die
Test-Ergebnisse vorgestellt.
2.6 Zusammenfassung In diesem Kapitel wurden die verschiedenen Schritte, die die Struktur dieser Arbeit bilden, erläutert.
Es wurde aufgezeigt, dass die Aufgaben dieses Projektes nach und nach ausgeführt werden und in
den einzelnen Kapiteln dieser Arbeit vorgestellt werden. Diese Gliederung ist für die Entwicklung des
Produktes wichtig, weil das Projekt somit zeitlich und fachlich strukturiert wird.
Fünf Phasen wurden vorgestellt:
1. In der Konzeptphase wurden die Ideen und Visionen für das Produkt gesammelt und be-
schrieben. Dabei wird in dieser Phase zuerst untersucht, wie die konkurrente Software sich
entwickelt hat. Die Vor- und Nachteile bereits existierender Produkte müssen herausgefun-
den werden. Anschließend werden Use-Case-Diagramme und das Pflichtenheft produziert,
um die Software detailliert zu beschreiben.
2. Das Software-Design ist dafür da, den zukünftigen Quellcode zu strukturieren. Anhand des
Pflichtenheftes und der Use-Case-Diagramme wird entschieden, wie das Programm am bes-
ten aufgebaut sein sollte.
3. Während der Benutzeroberflächen-Design-Phase muss die GUI des Produktes produziert
werden.
4. In der Implementierungsphase wird der Quellcode produziert. Anhand dessen, was bis hier-
hin vorbereitet und erarbeitet wurde, muss die Software geschrieben werden.
5. Um zu prüfen, dass die Implementierung die richtigen Ergebnisse ausgibt, muss das Projekt
getestet werden. Dies geschieht während der Testphase. In dieser Phase werden nicht nur
Tests für das Produkt geschrieben, sondern diese müssen auch von Menschen durchgeführt
werden.
Nachdem die Phasen des Projektes beschrieben wurden, widmet sich diese Arbeit der Einführung in
die Thematik sowie der Untersuchung von Alternativlösungen.
9
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 Cloud-
Computing vorgestellt. Dabei soll auf die Geschichte, Funktionalitäten, Anbieter usw. genauer einge-
gangen werden. Anschließend 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 unterstützt. Das Programm kann den Ent-
wicklern unter anderem in den folgenden Bereichen helfen:
Beschleunigung der Arbeit
Fehlersuche
Qualitätsverbesserung
Verschaffung eines besseren Überblicks
Manche IDEs können verschiedene Programmiersprachen editieren; Eclipse, NetBeans, IntelliJ IDEA
sind Beispiele dafür. Andere konzentrieren sich auf eine bestimmte Sprache wie zum Beispiel Web-
Storm (für JavaScript und PHP), PHPEdit (für PHP), PyDev (für Python) usw. Editor-Programme wer-
den oft durch Plug-ins erweitert. Diese werden von der Community erstellt, dabei können beispiels-
weise neue Funktionen hinzugefügt oder bereits existierende Funktionen erweitert werden.
3.1.1 Geschichte
Schon im Jahre 1975 wurde die erste integrierte Entwicklungsumgebung erstellt (vgl. Computerwo-
che.de, o.V. 1975). Diese Technologie wurde von Softlab Munich, „Maestro I“ genannt, entwickelt. Es
handelte sich dabei damals um einen großen 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 für jene Zeit ein großer Schritt.
Im Jahre 1990 wurde Softbench von IBM präsentiert. Ziel dieses Editors war es, C, C++ und später
COBOL zu unterstützen. Softbench ist dafür bekannt, der erste Editor mit einem Plug-in-System, wie
man es heute kennt, zu sein. Die Benutzer hatten die Möglichkeit, die Software so anzupassen, dass
es genau den Anforderungen der Programmierer gerecht wurde (vgl. Lienhart 1997, S. 1ff).
3.1.2 Aktuelle Lösungen
Heutzutage existieren vielsprachige Multiplattform-Editoren. Diese ermöglichen, dass Programmierer
aus unterschiedlichen Bereichen die gleichen Tools nutzen können. Die Eigenschaften der Vielspra-
chigkeit und die Multiplattform-Möglichkeit sind natürlich von Vorteil. Der Editor wird von einer grö-
ßeren Anwendergruppe benutzt, wodurch Bug-Reports, Bug-Fixings, Plug-ins und Programmierungen
schnell durchgeführt werden können. Die heute bekanntesten IDEs sind unter anderem Eclipse, Net-
10
beans, Xcode und IntelliJ IDEA. Textmate, SublimeText, Vim und Emacs sind zwar auch sehr beliebt,
gehören aber eher in der Kategorie der Texteditoren als in die einer integrierten Entwicklungsumge-
bung. Eine IDE bietet mehr Funktionen als ein Texteditor (siehe nächster Abschnitt "Typische Funkti-
onalitäten"). Beide sind nicht voneinander abgrenzbar, weil ein Editor mit Hilfe von Plug-ins die glei-
chen Features wie eine IDE besitzen kann.
3.1.3 Typische Funktionalitäten
Man findet in einer IDE fast immer die gleichen Hauptfunktionalitäten (vgl. Makarov 2009):
Syntax-Highlighting: Diese Funktionalität ist für die IDE ein Musskriterium. Der Quellcode
wird entsprechend der Programmiersprache gefärbt. Die Lesbarkeit wird dadurch verbessert.
Plug-ins: Wie bereits erwähnt, bietet ein Plug-in-System die Möglichkeit, den Editor ohne
großen Aufwand weiterzuentwickeln. Kleine Softwareanteile können geschrieben und in die
IDE eingebunden werden. Dadurch werden neue Funktionen geschaffen.
Autocomplete: Diese Funktion wird auch Code-Completion genannt und gibt während der
Programmierung Vorschläge. Wenn der Programmierer beginnt, ein Wort zu schreiben, wird
der Editor das mögliche Ende suchen und dieses dem Benutzer vorschlagen. Außerdem ist
wichtig, dass die Code-Completion auch den Quellcode der Programmierer analysiert und
damit alle möglichen Vorschläge anbietet.
Navigation: Wenn man eine Klasse programmiert, muss man oft zu Methoden oder anderen
Klassen springen. Manche IDEs bieten die Möglichkeit, per Klick- und/oder Tastenkombinati-
onen zu einer bestimmten Klasse oder Methode zu springen. Dafür muss die IDE den Quell-
code analysieren und indexieren. Dann weiß der Editor, in welcher Datei sich welche Teile
der Software befinden. Damit ist es dann möglich, von A nach B zu springen.
Fehler- und Warnungs-Highlighting: In der Entwicklungsphase kommt es häufig vor, dass
Zeichen vergessen werden, wie beispielweise das Semikolon. Das Fehler- und Warnungs-
Highlighting ist dafür da, solche Fehler sofort sichtbar zu machen. Hierbei wird auch der
Quellcode analysiert und die Syntax geprüft. Wenn Fehler gefunden werden, wird der Benut-
zer darüber informiert. Für die Analyse kann man beispielweise den Quellcode einfach kom-
pilieren.
Refactoring und Code-Generation: Wenn der Quellcode veraltet oder schlecht implemen-
tiert 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 de-
nen sich der Name der Klasse befindet und durch einen neuen Namen ersetzen.
Debugging: Debug-Funktionen helfen bei der Fehlersuche. Im Debug-Mode kann der Pro-
grammierer Breakpoints im Quellcode setzen. An diesen Stellen wird die Ausführung der
Software gestoppt. Es ist dann möglich, die Variablen der Prozesse zu sehen und die Ausfüh-
rung Schritt für Schritt weiterzuverfolgen und durchzuführen.
Integration von anderen Softwares: IaaS, PaaS, SaaS, Version-Control-Systems, Dokumenta-
tion, Datenbank usw. sind Systeme und Softwares, die man gern in die IDE integrieren möch-
te. Diese Funktionalitäten werden oft mit Hilfe von Plug-ins geschaffen.
Suche: Die „Suche-“ und „Suche-und-Ersetzen“-Funktion in Software-Editoren tragen we-
sentlich dazu bei, das Durchsuchen von Texten zu vereinfacheren.
11
Manche Funktionen sind trivial und können problemlos implementiert werden. Syntax-Highlighting
und die Suchfunktion können ohne oder bereits mit einer kleinen Analyse des Quellcodes durchge-
führt werden. Andere Features wie Code-Completion und Refactoring benötigen eine ausführliche
Analyse der Software, deswegen sind sie schwieriger zu implementieren. Schließlich sind Plattform-
und 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 Mobilität verbessert, sondern es können zudem große Datenmengen gespeichert
werden, die einer Vielzahl von Benutzern zugänglich sind. Seit 2007 taucht der Begriff „Cloud-
Computing“ laut Google (vgl. Google Trends 2012) immer häufiger in den Suchanfragen auf. Die Ab-
bildung 4 stammt aus Google Trends und zeigt zwei Tendenzen. Die obere Kurve zeigt die weltweite
Häufigkeit 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 deut-
lich, wie sehr das Interesse dafür 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. Zielgrup-
pe sind nicht nur Fachleute, sondern auch alle anderen Benutzer. Die Idee der Kampagne ist ein Ver-
gleich zwischen Cloud (Cloud-Computing) und Claude (eine fiktive Figur, humorvoll dargestellt).
12
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 Möglichkeit für Nichtfachleute.
3.2.1 Definition
Es gibt noch keine offizielle Definition für den Begriff Cloud-Computing. Schriftsteller und Wissen-
schaftler sind jedoch bereits darum bemüht, eine geeignete Definition zu erarbeiten. Cloud-
Computing nutzt die Virtualisierung von Ressourcen, um elektronische Dienste anzubieten. Eine De-
finition könnte 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 Verfügung. Die Abrechnung dieser Dienste erfolgt nut-
zungsabhängig."
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 Programmier-
sprache 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 Com-
puter-Dienstprogrammen ähnlich wie mit Gas, Strom und Wasser verfahren werden sollte: vom Staat
betrieben und von der Bevölkerung benutzt.
Ideen und Konzepte für das Cloud-Computing waren in den 60er Jahre bereits vorhanden. Die tech-
nologischen Möglichkeiten 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).
13
Im Jahre 2002 startete Amazon, heute einer der wichtigsten Akteure im Cloud-Computing, seine be-
kannten Amazon-Web-Services (AWS). 2006 wurde Amazon-EC2 für eine öffentliche Betaversion
geöffnet.
2010 hat die National Aeronautics and Space Administration (NASA) und Rackspace Hosting, Open-
Stack 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 Pro-
dukt 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 gegründet und ist einer der größten 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) erwähnt, wurde OpenStack von
Rackspace und der NASA 2010 veröffentlicht. 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 Cloud-
Anbieter 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 Lösungen wie OpenStack
jedoch nicht vergessen oder unterschätzen.
3.3 Auswertung des Cloud-Software-Editors Dieser Vergleich wurde zwischen dem 25. und 28. April 2012 durchgeführt und dient in erster Linie
dazu, einen guten Überblick über die aktuell vorherrschenden Angebote zu geben. Die verschiedenen
Cloud-IDEs können sich natürlich 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 ge-
wöhnlichen Softwarebewertung (vgl. Wheeler 2011). Nachfolgend werden die Kriterien kurz be-
schrieben und jedes betrachtetes Produkt danach bewertet. Anschließend wird eine Vor- und Nach-
teilsliste erstellt, um den Vergleich deutlicher zu machen. Die Kosten werden bei diesem Vergleich
jedoch nicht behandelt.
14
Funktionalitäten: Untersucht wird, was die Software leisten kann und wie nützlich die Fea-
tures 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 für die Cloud-Software sehr wichtig. Man
ist aufgrund der Desktopanwendungen an eine gewisse Geschwindigkeit gewöhnt. Die Um-
stellung 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 für Cloud-Anwendungen sehr relevant. Die Nutzer werden auf
den gleichen Servern arbeiten. Wenn eine Skalierung nicht möglich ist, wird die Plattform
sehr langsam bzw. nicht lauffähig.
Usability: Unter Usability sind mehrere Aspekte gefasst (vgl. U.S. Government s.d.):
o Erlernbarkeit: Wie schnell können neue Nutzer die Software erlernen?
o Effiziente Nutzung: Wie produktiv verwendet der angelernte Nutzer die Software?
o Einprägsamkeit: Ist die Software konsequent aufgebaut? z. B. Haben alle grünen
Knöpfe die gleiche Funktion?
o Fehlerhäufigkeit 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.
Flexibilität/Anpassbarkeit: Die Flexibilität misst inwiefern, die Software in ungeplanten Situ-
ationen reagiert. Ist sie agil genug, um sinnvoll zu funktionieren oder wird das Programm ei-
nen Fehler anzeigen bzw. blockieren. Unter Anpassbarkeit versteht man, inwieweit der Nut-
zer die Software anpassen kann. Ist es möglich und wie schwer ist es, neue Funktionalitäten
zu ändern oder hinzuzufügen?
Interoperabilität: Kann die Software mit anderen Programmen oder Systemen kommunizie-
ren? Bei Cloud-Lösungen befinden sich die Daten nicht mehr auf dem Computer, sondern auf
dem Server, welche dem Benutzer nicht gehören. Ohne öffentliche APIs kann die Software
nicht mit anderen Produkten interagieren.
3.3.2 Cloud9
Abbildung 6 Cloud9-Logo
15
Cloud92 existiert seit 2010 und zielt hauptsächlich auf die JavaScript-Entwicklung. Der Editor unter-
stützt 24 Programmiersprachen, aber nur Node.js ist in der Cloud ausführbar. Für die anderen Spra-
chen muss man auf einem Server oder lokal den Repository auschecken. Hierbei helfen die Git- und
Mercurial-Integration.
Cloud9 enthält einen Shell-Terminal, der allerdings aus Sicherheitsgründen nicht alle Unix-Befehle
enthält. Dieses Shell-Terminal ist eigentlich nachgebaut und nur wenige Shell-Befehle wurden im-
plementiert, z.B. cd, ls, rm, pwd, git, hg usw.
Außerdem bietet Cloud9 Deployment-Funktionen, um die Software auf die Plattform-As-A Service-
Anbieter zu installieren. Vier Anbieter werden unterstützt: 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 für Bugfixing und die Entwicklung von Features natürlich optimal, da zwei unabhängige
Entitäten beteiligt sind: das Unternehmen und eine Community.
Die Web-Anwendung verläuft flüssig und relativ schnell. Problematisch wird es, wenn man längere
Dateien editieren will. Das Kopieren und Einfügen mehrerer tausend Zeilen kann die Webseite blo-
ckieren.
Cloud9 basiert auf Node.js. Laut dem Unternehmen kann der Editor horizontal skalieren (vgl. Hemel
2012). Das ist natürlich von Vorteil für Cloud-Lösungen.
Cloud9 ist einfach in der Bedienung. Viele Tastenkombinationen, die man von Desktop-
Anwendungen kennt, stehen zur Verfügung. 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 ermög-
licht. Zurzeit müssen Plug-ins erst auf dem Server installieret werden. Das bedeutet, dass man eine
eigene Installation von Cloud9 vornehmen muss, um die gewünschten Plug-ins zu installieren.
Vorteile Nachteile
Git, Mercurial, Github, Bitbucket
Tastenkombinationen
PaaS-Anbieter integriert (Joyent no.de, He-roku, Microsoft Azure, Cloud Foundry)
24 Programmiersprachen mit Highlighting
Open Source3
Nur Node.js ausführbar
Keine vollständige Shell-Terminal
Keine gehostete Datenbank
Tabelle 1 Vor- und Nachteile von Cloud9
2 Mehr Informationen zum Projekt unter http://c9.io/ (Stand: 26.04.2012). 3 Mehr Informationen zum Projekt unter https://github.com/ajaxorg/cloud9 (Stand: 26.04.2012).
16
3.3.3 Koding
Abbildung 7 Koding-Logo
Koding4 befindet sich immer noch in der Betaversion, früher hieß der Editor Kodingen. Die Plattform
bietet einen sozialen webbasierten Cloud-Editor.
Ruby, Python Perl, PHP sowie Node.js sind bei Koding editierbar und ausführbar, es werden aber
auch Standardsprachen wie HTML und CSS unterstützt. Koding hostet für die Entwicklung auch Da-
tenbanken. MongoDB, MySQL, SqLite und PostgreSQL werden unterstützt.
Das Shell-Terminal wird in die Benutzeroberfläche integriert, leider dürfen Benutzer aus Sicherheits-
gründen keine Root-Rechte besitzen. Das kann insofern problematisch sein, wenn zum Beispiel be-
sondere PHP-Plug-ins benötigt werden. Koding bietet die Möglichkeit, Open-Source-Projekte zu im-
portieren, um schnell mit der Programmierung anfangen zu können.
Das Koding-Team ist in sozialen Netzwerken wie Twitter sehr aktiv. Im Editor selbst ist zudem ein
Forum integriert. Dort findet man Hilfe für 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 für neue Benutzer einfach
und verständlich zu sein, weil er doch intuitiv bedienbar ist. Leider sind in der aktuellen Version von
Koding keine Anpassungen möglich.
Im Moment kann man FTP in Koding verknüpfen. SVN, Git und Mercurial werden in der Endversion
zur Verfügung stehen.
Vorteile Nachteile
MongoDB und MySQL gehostet
Community mit Code-Sharing, Forum usw.
Shell-Terminal integriert
Ruby, Python Perl, PHP, Node.js ausführbar
App-Katalog mit Open-Source-Projekten
Nicht anpassbar
Keine Sudo-Rechte in Shell-Terminal
Tabelle 2 Vor- und Nachteile von Koding
4 Mehr Informationen zum Projekt unter http://koding.com/ (Stand: 26.04.2012).
17
3.3.4 ShiftEdit
Abbildung 8 ShiftEdit-Logo
ShiftEdit5, entwickelt von ShiftCreate, ermöglicht die Entwicklung im Browser durch das Verknüpfen
ü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
für die Ausführung von Programmen. ShiftEdit enthält einen Real-Time-Syntax-Checker, der nach
jedem neuen Buchstaben aufgerufen wird. Für die Entwicklung ist dieses Feature eine gute Eigen-
schaft, weil viele Entwickler oftmals daran gewöhnt sind, diese Funktion auf dem IDE-Desktop zu
haben.
ShiftEdit bietet nur mit SVN und keiner anderen Control-System-Version (VCS) wie Git oder Mercuri-
al, eine Integration. Die Verknüpfung mit dem Server kann nur über Dropbox oder FTP laufen, diese
Möglichkeiten sind sehr beschränkt und nicht für alle Unternehmen geeignet. Außerdem bietet Shift-
Edit kein Shell-Terminal. Der Code ist zwar nicht Open Source, aber es existiert ein Bug-Tracking-
System, wo man über Probleme und Bugs berichten kann.
ShiftEdit ist wie ein gewöhnlicher Editor aufgebaut, der Nutzer verliert sich nicht auf der Benutzer-
oberfläche. Eine negative Eigenschaft gibt es jedoch: Zum Speichern muss man sich entweder mit
Dropbox oder ein FTP verknüpfen. Es ist nicht möglich, ohne diesen Vorgang zu programmieren.
Man kann Code-Snippets speichern und wiederfinden. Es ist zudem möglich, Farben des Editors zu
ändern. Außerdem unterstützt der Editor SVN, FTP und Dropbox. Für den Beginn der Programmie-
rung ist FTP oder Dropbox zwingend erforderlich.
Vorteile Nachteile
Google/Facebook-Anmeldung
FTP- und Dropbox-Support mit Unix-File-Permission
Revision-Historie
24 Programmiersprachen mit Highlighting
Real-time-Syntax-Errors
SVN-Unterstützung
Kein anderes Version-Control-System außer SVN
Keine Shell-Terminal
Code nicht ausführbar
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).
18
3.3.5 CodeRun
Abbildung 9 CodeRun-Logo
Das Ziel von CodeRun6 ist es hauptsächlich, die Microsoft-Entwicklung in der Cloud zu erleichtern.
CodeRun unterstützt 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 möglich.
Ein Vorteil von CodeRun ist, dass es viele Template-Projekte gibt, um schnell in ein Thema einzustei-
gen. Jquery, Jquery-UI, Google-Maps, Chrome-Extension, Facebook-Connect, ASP, YUI, ExtJS sind
Beispiele hierfür. Die Templates enthalten die notwendigen Dateien für die Entwicklung und sie las-
sen 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 lässt sich gut bedienen. Die Web-Anwendung enthält nicht sehr viele Features, daher blei-
ben die Menüs klar und gut strukturiert.
Es ist leider nicht möglich, den Editor anzupassen. Man kann keine Farben ändern, keine Plug-ins
hinzufügen usw. Der Anpassbarkeitsgrad ist also sehr niedrig.
Benutzer können den Quellcode herunterladen oder ihn mit Hilfe der URL in soziale Netzwerke oder
per E-Mail verteilen.
Vorteile Nachteile
Visual-Studio®-Projekt-Import
Code-Completion
Debug mit Breakpoint
Sharing per URL
Nur 6 Programmiersprachen werden unter-stützt
Keine Shell-Terminal
Keine Control-System-Version
Kein gehostete Datenbank
Tabelle 4 Vor- und Nachteile von CodeRun
6 Mehr Informationen zum Projekt unter http://coderun.com/ (Stand: 26.04.2012).
19
3.3.6 Codeanywhere
Abbildung 10 Codeanywhere-Logo
Seit 2011 entwickelt Ademptio das Produkt Codeanywhere7, eine Cloud-IDE mit FTP- und Dropbox-
Verknüpfung.
Ähnlich wie ShiftEdit unterstützt Codeanywhere FTP und Dropbox. Fünf Programmiersprachen wer-
den unterstützt: HTML, PHP, JavaScript, CSS, und XML. PHP wird sogar auf dem Server von Codean-
ywhere ausgeführt. Wenn man weder FTP noch Dropbox hat, kann man auch auf dem Server von
Ademptio entwickeln. Möglich ist zudem die Entwicklung mit Git durch Github.
Weiterhin bietet Ademptio Mobile-Anwendungen für sein Produkt. iPhone, iPad, Android und Black-
berry werden unterstützt und ermöglichen es, die Entwicklung unterwegs durchzuführen. Außerdem
wird für Premium-Nutzer MySQL angeboten.
Das Team von Codeanywhere antwortet gern über soziale Netzwerke wie Twitter und Facebook. Der
Editor wird regelmäßig aktualisiert.
Die Verknüpfung mit Github und Dropbox ist sehr leistungsfähig. Auch hier wird der Editor langsa-
mer, wenn man mehrere tausend Zeilen in einer Datei bearbeitet.
Manche Elemente der Benutzeroberfläche fehlen. Beispielweise fehlt ein Menü im oberen Bereich.
Dennoch findet man die Funktionen, die man benötigt, z. B. mit Hilfe des Rechtsklicks.
Vorteile Nachteile
FTP-Support (mit Unix-Rechte) und Dropbox-Unterstützung
MySQL (nur für Premium-Nutzer)
Mobile-App (iPhone, iPad, Android, Black-berry)
Nur 6 Programmiersprachen unterstützt
Keine Shell-Terminal
Nicht anpassbar
Keine Control-System-Version
Tabelle 5 Vor- und Nachteile von Codeanywhere
7 Mehr Informationen zum Projekt unter https://codeanywhere.net/ (Stand: 26.04.2012).
20
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 unterstützt es auch andere Pro-
grammiersprachen, wobei die genaue Liste unterstützter 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 möchte. Die Dateien werden dann automatisch kopiert und
man kann nach wenigen Minuten mit dem Programmieren beginnen.
Die Dateien können 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 ermöglicht die Kommunikation zwischen
Benutzer und Unternehmen.
GoinCloud ist wie eine Desktop-Anwendung aufgebaut und für neue Nutzer relativ einfach zu bedie-
nen. Die reduzierte Anzahl von Features ermöglicht eine einfache und klare Strukturierung der Me-
nüs. Farbe, Schriftgröße und Schriftart sind anpassbar, darüber hinaus bietet der Editor keine weite-
ren Anpassungsmöglichkeiten.
Vorteile Nachteile
FTP und SSH auf den GoinCloud-Server
MySQL und PhpMyAdmin
Importieren eigener Server
Import von Open-Source-Projekten möglich
Shell-Terminal nicht im Browser integriert (zusätzliche SSH-Clients notwendig)
Version Control-System nur mit SSH
Nur MySQL
Tabelle 6 Vor- und Nachteile von GoinCloud
8 Mehr Informationen zum Projekt unter http://goincloud.com/ (Stand: 26.04.2012).
21
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 unterstützt nur wenige Programmiersprachen: HTML, JavaScript, PHP, Java, Groovy
und Ruby. Der Editor bietet Templates, die man zum Projektstart nutzen kann. Es ist sogar möglich,
seine eigenen Templates zu speichern und später 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 läuft zunächst relativ
schnell. Bereits ab 3000 Dateizeilen wird der Editor jedoch sehr langsam. Das ist insofern problema-
tisch, als dass 3000 Zeilen sehr schnell erreicht sind.
eXo Cloud IDE ist wie eine Desktop-IDE aufgebaut und für neue Benutzer nicht ungewöhnlich. Die
Web-Anwendung ist klar strukturiert und man findet schnell die gesuchte Funktion. Ein Vorteil von
eXo Cloud IDE ist sein Anpassbarkeitsgrad. Menüs, Tastenkombinationen und Formatierung können
problemlos geändert werden. Zum Beispiel können Benutzer, die kein Git brauchen, dieses Menü
einfach verschwinden lassen.
Vorteile Nachteile
Git-Integration
PaaS-Anbieter integriert (CloudBees, Cloud-Foundry, Heroku, Red-Hat-OpenShift)
Zusammenarbeit möglich
Guter Anpassbarkeitsgrad
Nur 6 Programmiersprachen
Keine Shell-Terminal
Keine gehostete Datenbank
Tabelle 7 Vor- und Nachteile von eXo Cloud IDE
9 Mehr Informationen zum Projekt unter http://www.cloud-ide.com/ (Stand: 26.04.2012).
22
3.4 Zusammenfassung Die Suche nach Alternativlösungen ist für den Erfolg eines Projektes wichtig, da das Produkt somit
besser positioniert werden kann. Man kann die Stärken und Schwächen der Konkurrenten besser
einschätzen. Außerdem ist es so möglich, sich ein genaueres Bild von den Funktionalitäten des Pro-
duktes zu machen.
Zuerst wurde eine Einführung in IDE vorgenommen, wo die Hauptfunktionalitäten eines Editors er-
läutert wurden. Im Anschluss daran wurde das Cloud-Computing kurz vorgestellt und einige Cloud-
Anbieter präsentiert.
Letztlich fand eine kurze Evaluierung des Cloud-Software-Editors statt. Mehrere Lösungen wurden
vorgestellt und deren Vor- und Nachteile gelistet. Nach dieser Einführung in die Thematik können das
Pflichtenheft sowie die Use-Case-Diagramme erstellt werden.
23
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 enthält alle wesentlichen Informationen darüber, wie das Projekt letztlich aussehen
und funktionieren soll. Darin werden die Funktionen der Software genauer erläutert (siehe nachfol-
gender Abschnitt „Zielbestimmung“, siehe S. 23). Im Abschnitt „Produkteinsatz“ (siehe S. 26) wird
darauf eingegangen, wie die Software benutzt werden kann. Es wird erklärt, von wem und in welcher
Umgebung die Software zum Einsatz kommen soll. Im Abschnitt „Produkt“ (siehe S. 27) werden un-
terschiedliche Sachverhalte thematisiert. Zunächst wird eine allgemeine Beschreibung über das ent-
wickelte 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 Ab-
schnitten auf die „Qualitätsanforderungen“ (siehe S. 33) sowie die „Benutzeroberfläche“ (siehe S. 34)
genauer eingegangen. Der letzte Abschnitt befasst sich schließlich mit der „Technischen Produktum-
gebung“ (siehe S. 36).
4.1 Zielbestimmung Das Ziel des Projektes ist es, eine universelle Software-Entwicklungsumgebung in der Cloud zu ent-
werfen und zu entwickeln. Das Projekt ist also ein Software-Projekt, in dem ein Programmeditor er-
stellen werden soll. Neu hieran ist, dass dieser Editor in der Cloud läuft und universell ist. Cloud-
basiert bedeutet, dass man kein spezielles Programm außer einem Browser, wie zum Beispiel Chro-
me, 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. zwangsläufig für das Projekt
erforderlich sind. Wenn eine dieser Funktionen nicht erfüllt sein sollte, gilt das Projekt als geschei-
tert.
Authentifizierung Das System soll in seiner Benutzung sicher sein. Persönliche Daten eines Nutzers dürfen demnach
nicht für andere Nutzer sichtbar sein. Der Nutzer muss zudem die Möglichkeit haben, sich zu regist-
rieren, einzuloggen, auszuloggen und die persönlichen Daten, wie beispielweise die E-Mail-Adresse
und das Passwort, ändern zu können.
24
Server-Management Die Software-Editierung soll direkt auf dem Server der Benutzer laufen. Deshalb muss es für die Be-
nutzer möglich sein, den eigenen Server zu managen. Dazu gehören Funktionen wie Server hinzufü-
gen, listen, modifizieren und löschen, die über die Benutzeroberfläche getätigt werden können müs-
sen. Im Moment wird nur Linux als Betriebssystem unterstützt. Das bedeutet, dass die Benutzer zu-
nächst einmal nur auf einem Linux-Server entwickeln können. Die Unterstützung 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 er-
forderlich.
Filebrowser Eine weitere wichtige Funktion eines Programmeditors ist die Fähigkeit, Dateien editieren zu können.
Beim Editieren sind die folgenden vier Grundaktionen zu beachten: das Kreieren, Lesen, Modifizieren
und das Löschen.
Dateieneditor Das Editieren von Dateien soll dank Syntax-Highlighting vereinfacht werden. Es soll zudem in ver-
schiedenen Sprachen möglich sowie leicht erweiterbar sein. Ein Minimum von 20 verschiedenen
Sprachen ist erforderlich.
Plug-in-System Für die Erweiterung des Editors muss ein Plug-in-System vorhanden sein. Diese Erweiterungen sollen
es ermöglichen, die Benutzeroberfläche sowie die Logik des Editors zu ändern. Musskriterien, Sollkri-
terien und Kannkriterien können 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 selbstständig konfigurieren können. Erforderlich sind zumindest die Modifikation der Schriftart
sowie der Schriftgröße. Außerdem sollte der Benutzer seine persönlichen Daten, wie E-Mail-Adresse,
Name und Passwort etc. ändern können, wie oben bereits erwähnt wurde.
4.1.2 Sollkriterien
Die sogenannten Sollkriterien sind die Zielfunktionen des Projektes. Es sind Funktionen, die einen
großen Mehrwert für das Produkt bieten. Für den Erfolg des Projektes müssen diese Kriterien mehr-
heitlich erfüllt sein.
Software-Installation Nicht nur für die Entwicklung wird Speicherplatz für die Quellcode-Dateien auf der Festplatte benö-
tigt, sondern auch für die Installation von zusätzlicher Software wie Webserver, Datenbanken, Biblio-
theken etc. Ein zentrales Ziel des Projektes ist die Funktion, über eine Oberfläche Software für den
Server zu suchen und zu installieren. Des Weiteren soll auf Unix-Kenntnisse verzichtet werden kön-
25
nen. Diese waren bisher Voraussetzung dafür, um mit der Programmierung überhaupt beginnen zu
können.
Shell-Terminals Verfügen einige Benutzer jedoch über gute Unix-Kenntnisse, sollen diese dennoch Befehle zum Ser-
ver schicken können. Shell-Terminals sollen im Editor ebenso zur Verfügung stehen wie in Putty10
oder in anderen SSH-Clients. Wie das Projekt selbst, sollen auch die Shell-Terminals im Browser lau-
fen.
Version-Control-System-Integration Version-Control-Systeme (kurz: VCS) gehören zu den wichtigsten Tools eines Entwicklers. Dank dieses
Features können Benutzer mit VCS-Tools, wie Git und SVN, arbeiten. Ziel dieser Funktion ist es, min-
destens 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 für den Erfolg des Projektes erforderlich und können
fakultativ erfüllt werden. Da sie einen Mehrwert für das Projekt ausmachen, sollen sie dennoch an
dieser Stelle erwähnt werden. Nachdem alle Muss- und Sollkriterien erfüllt wurden, kann mit der
Bearbeitung der Kannkriterien begonnen werden. Bereits während der Umsetzung der Muss- und
Sollkriterien sollte man die Kannkriterien im Blick behalten. Ihre Realisierung sollte nicht aufgrund
von Fehlentscheidungen, die während der Realisierung des Projektes getroffen wurden, verhindert
werden.
Unix-Dateirechte Dateirechte stellen einen wichtigen Aspekt in der Sicherheit eines Unix-Systems dar. Ohne die richti-
gen Rechte kann man bestimmte Dateien nicht editieren. Der Nutzer kann die Unix-Rechte über die
Benutzeroberfläche ändern. So können Dateien von verschiedenen Nutzern geändert werden.
Debugger Des Weiteren soll der Benutzer mit einer integrierten Benutzeroberfläche sein Programm debuggen
können. 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 für eine andere Programmiersprache implementiert werden
konnte.
Outline Klassen und Methoden, die von Benutzern programmiert werden, sollen auf einer gut strukturierten
Oberfläche 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 für mehrere Program-
10 Mehr Informationen zum Projekt unter http://www.putty.org/ (Stand: 22.06.2012).
26
miersprachen implementiert werden können. Für den Erfolg des Projektes ist aber nur eine Pro-
grammiersprache erforderlich.
Refactoring Der Nutzer sollte mit Hilfe der Benutzeroberfläche die Möglichkeit haben, sein Programm schnell
ändern zu können. Für den Erfolg dieses Kriteriums ist die automatische Änderung eines Klassen-
oder eines Methoden-Namens für das ganze Projekt beispielsweise eine wichtige Voraussetzung.
4.1.4 Abgrenzungskriterien
Die Abgrenzungskriterien sind eine Liste von Kriterien, die nicht erfüllt sein müssen. Dank dieser Liste
kann man sich besser auf das Projekt konzentrieren.
Unterstützung der GUI-Entwicklung Nicht erwünscht ist die Unterstützung einer graphischen Oberfläche mit den Desktop-Technologien
wie Qt oder Swing. Die einzigen unterstützten Oberflächen sind Webpages, die im Browser mit Hilfe
von HTML, CSS und JavaScript laufen.
Windows- und Mac-OS-Unterstützung In Abschnitt „Musskriterien“ (siehe S. 23) wurde bereits erwähnt, dass das Server-Management ein
Musskriterium ist. Im ersten Schritt werden nur Linux-Server unterstützt. Die Unterstützung von
Windows- und Mac-OS-Servern ist für 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. Die-
ses Programm soll von Firmen genutzt werden, um externe Mitarbeiter zu unterstützen. Mit dem
Software-Editor können Entwickler, Produktmanager und Lead-Programmierer ohne Software-
Installation von überall aus und mit jedem Computer weiterarbeiten. Natürlich funktioniert das Pro-
dukt auch In-House.
4.2.2 Zielgruppen
Die Hauptzielgruppe des Projektes sind Entwickler, die in der Web-Entwicklung tätig sind. Für 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 Zu-
gänge zum Server von überall brauchen. Für den System-Administrator ist die Nutzung dieses Projek-
27
tes von Vorteil, weil der Editor über sämtliche grundlegenden Tools verfügt, wie zum Beispiel über
Shell-Terminals oder Dateien-Editoren.
Mitarbeiter, die viel unterwegs sind, brauchen oftmals ständigen Zugang zum Server der Firma. Ge-
rade für 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 täglich 24 Stunden ohne Blockierung sowie wartungsfrei laufen. Des Weiteren muss
es auf einem normalen Linux-System laufen. Die Installation von zusätzlicher Software auf dem Ser-
ver ist möglich.
4.3 Produkt
4.3.1 Produktübersicht
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-, Soll-
und Kannkriterien, die für das Nuage-Projekt umgesetzt wurden, werden aufgezählt und genauer
beschrieben. Die hier zu beschreibenden Funktionen gehören jeweils zu einer Gruppe, so gehört
„[AUTH-01]“ zum Beispiel zu der Gruppe „Authentifizierung“. Gruppen sowie Funktionen besitzen
eine Kriterienkategorie. Es ist aber auch möglich, 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 gehört.
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 einlog-gen.
[AUTH-03] Der Nutzer kann sich ausloggen. Um sich wieder einzuloggen, braucht der Nutzer nur die E-Mail-Adresse und das Passwort erneut einzugeben.
28
[AUTH-04] Der Nutzer kann seine persönlichen Daten, d. h. die E-Mail-Adresse und das Pass-wort, selbstständig ändern.
Server Management
[SM-M-01] Der Nutzer kann neue Server einbinden. Dazu stehen ihm zwei Möglichkeiten zur Verfügung. Entweder gibt er die IP des Servers und den Benutzernamen an, mit dem man eine SSH-Verbindung öffnen kann oder er wählt einen IaaS-Anbieter aus. Bei der ersten Möglichkeit wird versucht, eine SSH-Verbindung aufzubauen. Die zweite Möglichkeit baut darauf, dass beim IaaS-Anbieter ein neuer Server erstellt wird, um dort zu programmieren. Für beide Fälle sollte bei einem Fehler des Ver-bindungsaufbaus 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 löschen.
[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 löschen.
[FB-M-05] Der Nutzer kann die Unix-Rechte von Dateien und Ordnern auf den Servern än-
dern.
Dateieneditor
[DE-M-01] Der Quellcode ist farblich hervorgehoben, wenn der Nutzer ihn editiert.
29
[DE-M-02] Der Nutzer kann bestimmen, welche Programmiersprache er verwendet, die dann jeweils anders gefärbt 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 löschen.
[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 können neue Knöpfe zu den Menüs und Kontext-Menüs hinzuge-fügt werden.
Editorkonfiguration
[EK-M-01] Der Nutzer kann die Schriftart des Editors auswählen.
[EK-M-02] Der Nutzer kann die Schriftgröße des Editors auswählen.
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 auswählen und installieren.
30
Shell-Terminal
[SC-S-01] Der Nutzer kann im Browser eine SSH-Verbindung mit einem Server öffnen, nut-zen und wieder schließen.
[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 Dateienänderungen einchecken.
[VCS-S-03] Der Nutzer kann Dateienänderungen auschecken.
Kannkriterien
Server Management
[SM-K-01] Der Nutzer kann Server klonen und teilen.
[SM-K-02] Der Nutzer kann weitere Nutzer-Zugänge 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 än-
dern.
31
Debugger
[DG-K-01] Der Nutzer kann Break-Points in den Quellcode einfügen und löschen.
[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 Deklarati-
on springen.
Refactoring
[RF-K-01] Der Nutzer kann für bestimmte Dateien den Namen einer Klasse ändern. Vo-
raussetzung dafür ist, dass die Änderung die Software nicht zerstört.
Version-Control-System-Integration
[VCS-K-01] Der Nutzer kann Konflikte mit Hilfe einer Benutzeroberfläche lösen.
4.3.3 Produktdaten
Nachfolgend werden alle Daten, die vom System gespeichert werden, aufgezählt und kurz erklärt.
Information über den Nutzer Gespeichert werden folgende nutzerbezogene Daten:
ID: Eindeutige String oder Integer sind nötig, 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 für IaaS-API: Alle erforderlichen Daten für die Authentifizierung bei dem IaaS-
Anbieter.
32
Informationen über die Server ID: Eindeutige String oder Integer sind nötig, 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.
Gäste: Die Menge der Nutzer-ID’s, 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 fährt gerade hoch oder herunter.
o running: Der Server läuft.
o deleted: Der Server wurde gelöscht.
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 nötig, 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 erfüllen:
Zur Speicherung der Daten wird eine Datenbank benutzt.
Gespeicherte Daten werden nicht verschlüsselt.
Bei Fehleingaben, Fehlermeldungen oder Warnungen soll dem Nutzer Bescheid gegeben
werden.
Der Nutzer soll über die Möglichkeit verfügen, Fehler selbstständig zu korrigieren.
33
4.4 Qualitätsanforderungen Produktqualität Sehr gut Gut Normal Nicht relevant
Funktionalität
Angemessenheit x
Richtigkeit x
Interoperabilität x
Ordnungsmäßigkeit x
Sicherheit x
Zuverlässigkeit
Reife x
Fehlertoleranz x
Wiederherstellbarkeit x
Benutzbarkeit
Verständlichkeit x
Erlernbarkeit x
Bedienbarkeit x
34
Effizienz
Zeitverhalten x
Verbrauchsverhalten x
Änderbarkeit
Analysierbarkeit x
Modifizierbarkeit x
Stabilität x
Prüfbarkeit x
Übertragbarkeit
Anpassbarkeit x
Installierbarkeit x
Konformität x
Austauschbarkeit x
Tabelle 8 Qualitätsanforderungen
4.5 Benutzeroberfläche Die Benutzeroberfläche soll in einem Browser laufen. Die Installation von Browser-Plug-ins oder zu-
sätzlicher Software ist nicht erlaubt.
Für das Projekt wurden Wireframes-Prototypen produziert. Sie befinden sich im Anhang (siehe S.
115).
35
Die Abbildung 13 zeigt eine Kleinausgabe des Hauptprototyps. Darin sind die fünf Hauptbereiche der
Benutzeroberfläche definiert, die mit unterschiedlichen Farben gekennzeichnet wurden:
Abbildung 13 Allgemeine Erklärung des Prototyps
1 - Der obere, orangegefärbte und mit der Ziffer eins versehene Teil auf der Abbildung 13 ist der
Kopfteil der Software. Dort befindet sich das Hauptmenü, welches immer präsent sein muss. Die
Struktur des Menüs wird nachfolgend in der Tabelle 9 gezeigt. Im Hauptmenü sind darüber hinaus
Buttons zu sehen. Diese stammen nicht vom Editor selbst, sondern sie müssen von Plug-ins definiert
werden.
2 - Der blaue linke Bereich auf der Abbildung 13 wird hauptsächlich verwendet, um einen Dateien-
baum 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 geöffnet sind, dann kann der
Nutzer mittels eines Tab-Systems zwischen den offenen Dateien einfach hin und her wechseln.
4 - Der vierte, grüne Bereich rechts außen hält Platz für zusätzliche Informationen, wie zum Beispiel
für das Outline, bereit. Hier können 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 gekenn-
zeichnet. An dieser, mit der Ziffer fünf markierten Stelle, werden die SSH-Verbindungen angezeigt.
Außerdem sollen auch Informationen, Warnungen oder Fehler im Form von Logs angezeigt werden,
wie die nachfolgenden Sätze 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.
36
Datei
Neu
Öffnen
Schließen
Logout
Bearbeiten
Ausschneiden
Kopieren
Einfügen
Einstellungen
Editor
Konto
Server
Neu
Liste
Hilfe
Dokumentation
About
Tabelle 9 Struktur des Menüs
4.6 Technische Produktumgebung
4.6.1 Software
Der Software-Editor muss zwingend im Browser laufen. Folgende Browser müssen für den Erfolg des
Projektes daher unterstützt 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 wählbar sein. Die Nutzung von zusätzlicher Software auf dem
Server ist dann möglich, wenn diese in der Installationsanleitung dokumentiert werden. Der Nuage-
Server muss auf einem Betriebssystem mit mindestens der Version 3.2+ von Linux laufen.
Für die persistenten Daten ist eine Datenbank erforderlich. Auch hier sind die Technologien frei
wählbar.
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
37
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 erläutert. Um die Kriterienliste übersichtlicher zu machen, wurden die
Kriterien verschiedenen Übergruppen zugeordnet wie zum Beispiel Authentifizierung, Server- Ma-
nagement, Filebrowser, Dateieneditor, Plug-in-System usw. Diese Gruppen wurden nach Priorität
angeordnet, von den Musskriterien bis hin zu den Kannkriterien. So kann man sich schnell einen
Überblick über das Projekt und seine Features verschaffen.
Außerdem 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 An-
wendungsbereich und die Zielgruppen beinhaltet (siehe S. 26).
Anhand des Pflichtenheftes wird im nächsten Kapitel der Systementwurf der Software vorgestellt.
38
5. Systementwurf Zwischen der Erstellung des Pflichtenhefts und der Implementierung der Software muss der Syste-
mentwurf des Projektes durchgeführt werden. Dieses Kapitel beschäftigt sich mit dieser Phase. Hier
werden die Architekturen des Clients und des Servers erläutert sowie das Datenbank-Schema ent-
worfen.
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. Für 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
Für die Architektur sind drei Hauptbereiche von Bedeutung:
Damit der Editor Dateien editieren kann, müssen diese auf die Festplatte des Entwicklungs-
servers übertragen werden. Leider ist dies nicht ohne einen Zwischenschritt möglich, weswe-
gen ein Web-Server benötigt wird, der per HTTP-Anfragen erreichbar ist und die Zugriffe auf
die Festplatte durchführen kann.
Der Nutzer soll die Server managen können, indem er neue Server erstellen, auflisten, modi-
fizieren und löschen kann. Diese Informationen müssen in einer Datenbank gespeichert wer-
den, welche sich ebenfalls auf dem Web-Server befindet. Für die Übermittlung der Daten
wird eine HTTP-API zur Verfügung gestellt.
Für die Administration der Entwicklungsserver werden SSH-Verbindungen benötigt, welche
hierfür extra eingerichtet werden. Es existieren bereits Projekte, die diese Funktionalität bie-
ten und daher im Editor integriert werden sollen.
Die globale Architektur sieht schließlich wie folgt aus:
39
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 Verfügung, welcher nur HTTP-Anfragen verar-
beiten kann. Diese werden dem Server des Editors übermittelt und wenn es notwendig ist, zum Ent-
wicklungsserver weitergeleitet. Dies ist beispielweise bei einem Festplatten-Zugriff oder einer SSH-
Verbindung der Fall.
Das Server-Management, das mit Hilfe der APIs von IaaS-Anbietern wie Rackspace oder Amazon-
Web-Services umgesetzt wurde, bildet einen weiteren großen Teil des Projektes. Generell bieten
Infrastructure-As-A-Service-Anbieter eine API-Schnittstelle, um Server zu managen, die mit Web-
Protokollen wie beispielsweise SOAP oder HTTP angesprochen werden können. Amazon’s API unter-
stützt zum Beispiel SOAP und HTTP, womit verschiedene Aktionen durchgeführt werden können:
Server können mit dem RunInstances-SOAP-Befehl erstellt werden (vgl. Amazon-Web-
Services 2012, S. 359ff.).
Server können mit dem TerminateInstances-SOAP-Befehl gelöscht werden (Ebd., S. 373f.).
Server können mit dem StartInstances-SOAP-Befehl gestartet werden (Ebd., S. 369f.).
Server können mit dem StopInstances-SOAP-Befehl gestoppt werden (Ebd., S. 359f.).
Server können mit dem RebootInstances-SOAP-Befehl neu gestartet werden (Ebd., S. 319f.).
Der Server muss mit dem Namen des Nutzers angemeldet werden, wofür er nur eine Access-Key-ID
und einen Secret-Access-Key benötigt. Beide werden für die Verschlüsselung der Kommunikation
verwendet und müssen deswegen in der Datenbank gespeichert werden.
Die in Abbildung 15 zu sehenden Entwicklungsserver stellen die Arbeitsplätze der Nutzer dar. Hier
werden die Dateien editiert und die jeweils vom Nutzer benötigte Software installiert. Diese Server
können 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 benötigt hingegen nur eine valide SSH-Verbindung.
40
5.1.2 Server-Architektur
Entwickelt wird ein einziger Web-Server, der für alle Komponenten, wie den Editor, die SSH-
Verbindungen, das Server-Management, Datenbank-Verbindungen und viele mehr, zuständig 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 wel-
che Komponente die Anfrage gerichtet war und leitet sie dementsprechend weiter. In den meisten
Fällen wird die Analyse nur wie folgt anhand der URL durchgeführt:
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
für die Implementierung der HTTP-Serverkomponente benutzt, weshalb kein Design für den HTTP-
Server in der Design-Phase entworfen wird. Die Auswahl des Frameworks und der Programmierspra-
che soll während der Implementierung evaluiert und getätigt werden.
11 Mehr Informationen zum Projekt unter http://symfony.com/ (Stand 26.05.2012). 12 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).
41
Die Verbindung zur Datenbank wird über den HTTP-Server erstellt und jede Komponente kann über
den Datenbank-Mapper darauf zugreifen.
Abbildung 17 Entitäten-Klassen
Zur einfacheren Programmierung sollen Object-Relational-Mapper (ORM) für relationale Datenban-
ken oder Object-Document-Mapper (ODM) für dokumentorientierte Datenbanken eingesetzt wer-
den. Ziel dieses Mapper ist es, die Komplexität der Datenbank zu abstrahieren, indem die Daten-
bankanfragen in einer Klasse konzentriert werden. Die verschiedenen Komponenten der Server kön-
nen dann die Methode der Klasse ausführen, um Anfragen an die Datenbank zu stellen. Der Mapper
enthält auch alle Entitäten als Klassen, drei sollen hier implementiert werden: Nutzer, Server und
Plug-in (siehe Abbildung 17).
Abbildung 18 Connector-Vererbung
Der IaaS-Client ist für das Server-Management zuständig und kümmert sich um die Aufrufe der IaaS-
Anbieter, um zum Beispiel Server zu erstellen, zu löschen und zu starten. Wie oben bereits erwähnt,
findet die Kommunikation mit dem IaaS-Anbieter über HTTP- oder SOAP-Anfragen statt. Damit ver-
schiedene IaaS-Anbieter unterstützt werden können, sollen diese Anfragen in Klassen abstrahiert
42
werden und je nach Anbieter spezialisiert werden können (siehe Abbildung 18). Dies hat zwei Vortei-
le, zum einen gewinnt man an Flexibilität und zum anderen sinkt die Komplexität.
Die Festplatten-Zugriffskomponente ist für das Editieren von Ordnern und Dateien zuständig. Damit
diese Komponente auf die Festplatten der neu hinzugefügten Server zugreifen kann, wird eine gülti-
ge SSH-Verbindung benötigt. Um sicherzustellen, dass eine solche Verbindung möglich ist, werden
neue Server beim Hinzufügen auf ihre Gültigkeit hin überprüft. Zur Reduktion der Komplexität wird
das Software-Projekt SSHFS14 benutzt, welches ein auf dem SSH-Protokoll basiertes Dateisystem be-
reitstellt (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
für das Einbinden zuständig und die andere für die Dateienzugriffe (siehe Abbildung 20).
14 Mehr Informationen zum Projekt unter http://fuse.sourceforge.net/sshfs.html (Stand: 22.06.2012).
43
Abbildung 20 Festplatten-Zugriff-Klassen
Die Software-Installation soll ebenfalls mit Hilfe von SSH durchgeführt werden. Normalerweise wird
die Installation von Software mit Hilfe von Package-Managern wie yum, apt-get oder aptitude durch-
geführt. Daher muss, bevor eine Software gesucht oder installiert werden soll, zuvor ermittelt wer-
den, 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 ent-
halten (siehe Abbildung 21).
Abbildung 21 Software-Installation-Klasse
Eine Alternative zum Software-Installer wäre der Einsatz einer Configuration-Management-Software
(SCM) wie Chef15 oder Puppet16.
5.1.3 Client-Architektur
Clientseitig muss ein Programm geschrieben werden, welches für die grafische Darstellung des Edi-
tors und die Kommunikation mit dem Server zuständig ist. Auch für diesen Teil muss ein Framework
wie Jquery17 oder ExtJS18 ausgewählt werden.
15
Mehr Informationen zum Projekt unter http://www.opscode.com/chef/ (Stand: 22.06.2012). 16 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).
44
Die Grund-Architektur des Clients kann jedoch schon entworfen werden und soll auf dem MVC-
Pattern basieren. Das MVC-Pattern wurde in den 70er Jahren von Trygve Reenskaug für die Smalltalk-
Plattform 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, verhältnismäßig zur Domain enthalten. Der View ist für
die grafische Darstellung zuständig. Anhand der Eingabe des Nutzers manipuliert der Controller die
Models und lässt die Views sich neu zeichnen (Siehe Fowler, Martin 2002, S. 330).
Die Idee ist, dass jeder Bereich der Benutzeroberfläche mit einer View und einem Controller reprä-
sentiert 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
45
Wie in Abbildung 22 zu sehen ist, sind alle Controller unabhängig voneinander. Sie besitzen nur eine
Referenz zum so genannten Applikationsobjekt. Dieses Objekt ist ein Singleton (eine einzige Instanz
für das gesamte Programm) und für die Synchronisierung der Web-Apps zuständig. Die Kommunika-
tion zwischen den Controllern findet in diesem Objekt statt. Wenn der Nutzer beispielsweise im lin-
ken Bereich (blau) auf eine Datei doppelklickt, muss der Controller das Applikationsobjekt darüber
informieren, dass eine Datei geöffnet werden soll.
Ein großer Vorteil ist, dass die Controller lose gekoppelt sind. Wenn sich ein Controller ändert, muss
nur die Applikationsklasse geändert werden und nicht alle Controller der einzelnen Bereiche.
Die einzelnen Modelle gehören 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 während der Implementierung soll ein passendes Datenbanksystem gewählt werden. Trotzdem
steht das Schema, bestehend aus den Entitäten Benutzer, Server und Plug-ins, schon fest.
Abbildung 23 Entity-Relationship-Model
Abbildung 23 zeigt das Entity-Relationship-Model mit den einzelnen Entitäten und deren Relationen.
Das Model wurde relativ einfach gestaltet, um die Flexibilität und Anpassbarkeit des Systems zu ver-
bessern.
46
5.3 Zusammenfassung In diesem Kapitel wurde das Software-Design vorgestellt. Anhand des Pflichtenheftes wurde ein Ent-
wurf des Systems erstellt. Dabei wurde zuerst die globale Architektur präsentiert, damit man die
Kommunikation zwischen dem Benutzer, dem Nuage-Server und den Entwicklungsservern nachvoll-
ziehen 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 Implemen-
tierung produziert wird, zu strukturieren.
Außerdem wurden technische Besonderheiten, wie das Einbinden von Festplatten mit Hilfe des
SSHFS-Projektes, erläutert. Dies ist ein wichtiger Punkt für dieses Projekt, da davon ein Großteil der
Architektur abhängt. Aus diesem Grund wurden diese technischen Besonderheiten noch vor der Im-
plementierung untersucht. Anschließend wurde das Datenbank-Schema bekanntgegeben.
47
6. Realisierung In diesem Kapitel geht es um die Phase der Implementierung. Wie bereits im Kapitel „Aufgabenstel-
lung“ (siehe S. 4) erwähnt, wird in dieser Phase das Software-Design in Quellcode-Zeilen transkri-
biert. Bezüglich des Software-Designs und der Software-Architektur müssen grundlegende Entschei-
dungen getroffen werden, wie zum Beispiel die Festlegung auf die Programmiersprachen und Biblio-
theken. Die zwei ersten Abschnitte dieses Kapitels befassen sich mit der Erklärung dieser Auswahl.
Dieses Kapitel wird dann mit einer Zusammenfassung beendet.
6.1 Programmiersprachen Die Auswahl einer Programmiersprache ist eine wichtige Entscheidung für ein Software Projekte. Im
Pflichtenheft sowie im Design ist keine Auswahl festgelegt - weder für den Browser, noch für den
Server. Nachfolgend wird zunächst die Entscheidung für die Programmiersprache der Benutzerober-
fläche erklärt, anschließend auf die Auswahl für den Server eingegangen.
6.1.1 Client
Im Pflichtenheft dieses Projektes steht, dass die Benutzungsoberfläche in einem Browser laufen soll
und keine Installation von zusätzlicher Software erforderlich sein sollte (siehe Abschnitt
„Benutzeroberfläche“ S. 34). Gesucht ist also eine Programmiersprache, die im Browser läuft und mit
der man Benutzeroberfläche bauen kann.
JavaScript ist für die Programmierung im Browser fast die einzige Möglichkeit. Die Sprache JavaScript
ist fast in jedem Browser verfügbar und benötigt keine Installation von zusätzlicher Software (Dioni-
sio/Toal 2011). Im Browser ist JavaScript für die Logik zuständig. Die Sprache kann aber nicht die
Darstellung von graphischen Elementen leisten, dafür werden CSS und HTML benötigt.
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). Außerdem muss der Sever mit
dem API eines PaaS-Anbieters kommunizieren.
48
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 zurück.
4. Der Nuage-Server bekommt diese Antwort, übersetzt sie für 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, Dateiin-
halte oder andere Ein- und Ausgaben abrufen will, muss er aufgrund der Latenz (zum Beispiel wegen
des Netzes oder wegen der Festplatte) warten. Für Proxy-Applikationen wie dieses Projekt kann die
Latenz problematisch sein. Wenn der Entwicklungsserver zu lange zum Antworten braucht, wartet
der Prozess mehr als er tatsächlich arbeitet.
49
Für das dargestellte Problem gibt es mehrere Lösungen: das sogenannte Multithreading und die er-
eignisorientierte Programmierung. Im Multithreading enthält der Prozess mehrere Threads. Ein
Thread kann wie ein leichter Prozess angesehen werden. Ein Thread erhält seine eigenen Daten und
Instruktionen (vgl. Padua 2011, S. 1223). Wenn ein Thread blockiert ist, können andere Threads, so-
fern das Betriebssystem Mehrprozessbetriebe unterstützt, weiter arbeiten. Ein weiter Vorteil von
Multithreading ist zudem, dass die Performanzen mit einem Mehrkernprozessor verbessert werden.
Die Kernel können gleichzeitig mehrere Threads bearbeiten. Andererseits ist die Programmierung mit
Threads auch komplizierter. Man muss die verschiedenen Threads synchronisieren und in extremen
Fällen können Threads sich sogar blockieren.
Die Idee von ereignisorientierter Programmierung hingegen ist eine komplett andere. Das ganze Pro-
gramm läuft nur in einem Thread. Mit synchronem Aufruf würde 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
Während der Anfrage muss der Thread warten. Im Gegensatz zum Multithreading geht das Pro-
gramm in der ereignisorientierten Programmierung weiter und erledigt den Rest des Programms
später (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 ausgeführt
}
request(url, callback);
...
Listing 2 Asynchrone HTTP-Anfrage
Nach der Anfrage geht der Prozess hier weiter. Sobald die Antwort der HTTP-Anfrage zurückkommt,
wird die Callback-Funktion ausgeführt. Der Vorteil dieser Methode ist, dass das Programm nie auf
eine Antwort wartet. Deswegen ist es für I/O-Aktionen eine sehr performante Lösung. Die asynchro-
ne Programmierung kann allerdings unperformant für Applikationen, die viele CPU-Ressourcen brau-
chen. Wenn der CPU mit einer längeren Aufgabe beschäftigt ist, dann kann er keine weiteren erledi-
gen.
Für die Performanz des Projektes ist es wichtig, dass eine dieser zwei Lösungen in der Programmier-
sprache möglich ist. Folgende Sprachen kommen in Frage und werden nun kurz evaluiert, um eine
Entscheidung zu treffen: Python, PHP, Java, JavaScript.
50
Python Python ist eine Skriptsprache und erschien im Jahre 1991. Sie läuft auf verschiedenen Betriebssyste-
men: Windows, Mac und Unix. Die Typisierung von Python ist stark und dynamisch, was bedeutet,
dass alle Variablen einen bestimmten Typ haben, dieser sich aber während 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 Nachteile
Nicht blockierende Web-Server wie Tornado
Objektorientierte
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 läuft PHP auf Windows, Mac und
Unix. Die Typisierung von PHP ist ebenfalls dynamisch, jedoch auch schwach (bzw. weak auf Eng-
lisch). Einer der Unterschiede zur starken Typisierung ist, dass der Typ einer Variable implizit ist. Das
heißt, dass der Interpreter die Typkonvertierungen je nach Operation vornimmt. Für eine Addition
werden zum Beispiel die zwei Summanden in Integer konvertiert, selbst wenn eine Variable vom Typ
String ist.
Seit PHP 5.4 enthält PHP einen Web-Server. Dieser sollte aber nur für die Entwicklung und die Um-
setzung von Tests benutzt werden (vgl. PHP 2012). Man muss also einen anderen Server wie bei-
spielsweise Apache20 oder Nginx21 verwenden. Beide nutzen das Multithreading (vgl. The Apache
Software Foundation 2012; Sysoev 2012). Nginx basiert aber auch auf ereignisorientierter Program-
mierung (vgl. Kleinman 2012).
Vorteile Nachteile
Sehr populär
Objektorientiert
Schwache Typisierung kann zu Missver-ständnissen führen
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 Mehr Informationen zum Projekt unter http://www.tornadoweb.org/ (Stand: 06.06.212). 20 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).
51
Es existieren viele Implementierungen von Java-Web-Servern wie zum Beispiel Tomcat22, Glassfish23
oder auch Jetty24. Die Möglichkeiten mit Java sind vielfältig.
Vorteile Nachteile
Vielfältige Möglichkeiten
Objektorientiert
Ü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 Typisie-
rung. Sie wurde ebenfalls im Jahre 1995 offiziell präsentiert. Ursprünglich war sie für den Netscape-
Browser gedacht (vgl. Netscape 1995). Bereits im Jahre 1996 wurde JavaScript in den Netscape-
Enterprise-HTTP-Server integriert (vgl. Wayner 2011). JavaScript ist eine ereignisorientierte Pro-
grammiersprache. Im Browser wird sie oft benutzt, um Events wie Klicks oder Tastendrücke einzu-
fangen und dann darauf zu reagieren.
Im Jahre 2009 wurde von Ryan Dahl Node.js25 präsentiert. Node.js ist ein JavaScript-Framework, das
auf dem Google V8 JavaScript-Engine basiert 26. Ziel dieses Frameworks ist es, eine ereignisorientierte
Basiskomponente für Applikationen anzubieten die viele Daten enthalten oder in Echtzeit abgerufen
werden sollen.
Vorteile Nachteile
Gleiche Sprache für Server und Client
Objektorientiert
Asynchroner Aufruf kann ungewöhnlich für den Programmierer sein
Tabelle 13 Vor- und Nachteile von JavaScript
Für das Projekt wurde aus verschiedenen Gründen JavaScript ausgewählt. JavaScript ist objektorien-
tiert 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 proto-
typenbasierter Programmierung ist, dass die Klassen dynamisch gehalten sind. Sie können sich also
während der Laufzeit noch ändern. Der Vorteil dabei ist, dass man Flexibilität gewinnt, jedoch mit
dem Risiko für das Programm ein schlechteres Pattern zu entwickeln.
JavaScript hat außerdem eine große Community, die sehr aktiv ist. Die Sprache wird clientseitig und
serverseitig benutzt. Viele Bibliotheken, die für clientseitige Zwecke entwickelt wurden, funktionie-
ren auch serverseitig. Die Mitarbeiter, die für das Front-End zuständig sind, können, ohne eine neue
Sprache zu lernen, auch für das Back-End arbeiten. Neue Mitarbeiter brauchen weniger Zeit, um das
22 Mehr Informationen zum Projekt unter http://tomcat.apache.org/ (Stand: 06.06.2012). 23
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).
52
Produkt zu lernen. Weil die gleiche Sprache clientseitig und serverseitig benutzt wird, kann man auch
den gleichen Quellcode für beide Seiten benutzen. Man muss ihn folglich nur einmal schreiben. Zu-
dem sind Aktualisierungen einfacher vorzunehmen (Hughes-Croucher/Wilson 2012).
Der Nachteil von JavaScript ist, dass die asynchronen Aufrufe für den Programmierer sehr ungewöhn-
lich sein können. 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 möglich, den Quellcode
so zu strukturieren, dass er besser lesbar wird (siehe Listing 3; Die Callback-Funktion wird während
der Anfrage definiert). Problematisch ist hier, dass der Quellcode wegen der Einrückung mehr nach
rechts rückt.
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 erwähnt wurde Node.js im Jahre 2009 entwickelt. Das Framework ist für eine solche
Komponente relativ neu, weshalb Updates für Node.js auch relativ häufig 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 nächsten Versionen (siehe Tabelle 14; Schlueter, Isaac 2012). Mochte man aus Sicherheits-
und/oder Performanzgründen die aktuelle Software haben so muss man sehr oft die Node.js-
Plattform updaten. Daher sollte man darauf achten, dass die Software, die man entwickelt, nach
einer Aktualisierung immer noch mit der neusten Version kompatibel ist. Für diese Aufgabe können
automatisierte Unit-Tests und funktionale Tests sehr nützlich 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 4
v0.6.16 30.04.2012 21
v0.6.15 09.04.2012 17
53
v0.6.14 23.03.2012 8
v0.6.13 15.03.2012 nicht berücksichtigt
Tabelle 14 Häufigkeit der Node.js-Updates
6.1.3 Datenbank
Um Daten festzuhalten, wurde im Pflichtenheft die Nutzung einer Datenbank genannt (siehe S. 32).
Für 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 Da-
vid Axmark entwickelt wurde. Heute gehört 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 unterstützt (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 Nachteile
Sehr bekannt
Von einer Firma getragen
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 verfügbar. Ziel dieses Projektes ist es,
eine flexible und skalierbare Datenbank anzubieten. MongoDB erreicht die Kriterien Konsistenz (Con-
sistency) und Aufteilungstoleranz (Partition Tolerance), des CAP-Theorems.
Der Vorteil von MongoDB für das Nuage-Projekt ist, dass es JSON-formatorientiert ist. Man kann
nicht nur serialisierte, sondern auch echte JSON-Daten verschicken und speichern. Außerdem kann
mit Hilfe von MapReduce oder der Suchfunktion im gespeicherten JSON-Zustand gesucht und damit
gefiltert werden. Für ein serverseitiges JavaScript-Projekt ist dies ein Vorteil, da JSON in JavaScript
häufig verwendet wird. Aus diesem Grund gibt es auch viele Module, die die Unterstützung von
MongoDB im Node.js anbieten. Außerdem werden bei MongoDB-Query-Funktionen und MapReduce
in JavaScript geschrieben.
54
Vorteile Nachteile
Sehr gut skaliert
JSON speichern und suchen
MongoDB ist populärer in der Node.js-Community
JavaScript-Funktionen für die Suche
Insgesamt weniger bekannt
Tabelle 16 Vor- und Nachteile von MongoDB
Gewählt wurde die MongoDB-Datenbank hauptsächlich aufgrund seiner Verwandtschaft zu Ja-
vaScript. Nachdem die clientseitige sowie die serverseitige Sprache gewählt wurden, ist die Auswahl
der Datenbank die letzte technische Grundentscheidung dieses Projektes. Hier kann man bereits
beobachten, dass alle bis jetzt gewählten Technologien JavaScript sehr ähneln. Für das Projekt ist
dies sicherlich ein Vorteil.
6.2 Bibliotheken Bibliotheken sind für die Softwareentwicklung vor zentraler Bedeutung, denn sie ermöglichen die
erneute Nutzung von Komponenten und/oder Klassen. Statt für jedes Projekt immer die gleichen
Artefakte zu schreiben, wird man eher allgemeingültige Softwareteile schreiben, die anpassbar sind.
In diesem Abschnitt werden die Bibliotheken, die in diesem Projekt verwendet als auch extra dafür
geschrieben wurden, vorgestellt.
6.2.1 Client
Es existieren viele JavaScript Frameworks. Zwei Eigenschaften sind für dieses Projekt besonders wich-
tig. Wie schon im Systementwurf erwähnt wurde, ist ein MVC-Framework nötig (siehe Abschnitt
“Client-Architektur“ Seite 43). Dieses Feature soll für 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 Oberfläche geht, muss die Bibliothek die Benutzeroberfläche-
Entwicklung unterstützen. Natürlich ist es auch möglich, zwei Bibliotheken miteinander zu kombinie-
ren, 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 bie-
tet Grundfeatures für die Entwicklung von JavaScript im Browser. Ajax-Anfragen, DOM-Elemente-
Manipulationen und CSS-Manipulationen sind drei von den Hauptfeatures.
Leider werden weder GUI-Elemente noch MVC-Pattern mitgeliefert. JQuery bietet nur Hilfsmetho-
den, um die JavaScript-Entwicklung zu erleichtern.
27 Verfügbar 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).
55
Für 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. Für 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 für 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 für die Zukunft auch so bleibt.
Diese Lösung ist robust und sehr flexibel, aber sie bietet nicht alle Funktionalitäten, die man braucht
um gute GUI zu bauen. Die Elemente sind sehr spezifisch und unvollständig, um eine Benutzerober-
fläche zu strukturieren.
Vorteile Nachteile
Sehr bekannt
Open Source
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 lässt, von Yahoo! entwickelt. YUI bietet wie
jQuery die Grundfunktionalitäten einer JavaScript Library (Ajax-Aufrufe, DOM-Element-
Manipulationen, CSS-Manipulationen usw.). Dazu stehen auch UI-Elemente zur Verfügung wie ein
Autocompleter, Kalender, Charts usw. Eine neue Funktionalität bei YUI ist das App-Framework. Die-
ses 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 unterstützt wie jQuery (vgl. Lemay/Colburn 2011, S.
461.). Deswegen gibt es nur wenige Plug-ins und Tutorials.
Vorteile Nachteile
Unterstützt von Yahoo!
Open Source
Kleinere Community als jQuery
Kein Design-Tool
Tabelle 18 Vor- und Nachteile von Yahoo! UI
28 Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter http://yuilibrary.com/ (Stand: 09.06.2012).
56
ExtJS29 Sencha Inc. ist eine relativ neue Firma, die Frameworks, Tools und Dienste für HTML5- und Ja-
vaScript-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 Grundfunktionalitäten einer JavaScript-
Library, 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 unterstützt. Man kann damit nicht nur Quell-
codes 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 verfügbar.
Ein Nachteil von ExtJS besteht in der Lizenz. Es sind zwei Möglichkeiten für Projekte, die mit ExtJS
gebaut sind, gegeben. Entweder kauft man das Produkt und kann damit das gebaute Projekt verkau-
fen oder man nimmt die Open-Source-Version von ExtJS. Dafür muss man das gebaute Projekt aber
auch Open Source verteilen.
Vorteile Nachteile
Unterstützt von Sencha Inc.
Gutes MVC-Framework
Zahlreiche GUI-Elemente
GUI-Tools
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 Open-
Source-Lizenz. Features sind die Grundfunktionalitäten 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 bau-
en, ohne zu programmieren. Leider sind die Features dieses Tools nicht so umfangreich wie bei Sen-
cha Architect 2.
Der Vorteil von Dhtmlx ist die gegebene Back-End-Integration. Die Firma bietet Konnektoren für ver-
schiedene Sprachen, z. B. werden PHP, ASP.NET, JAVA, und ColdFusion unterstützt. Leider gibt es
keinen Konnektor für Node.js (vgl. DHTMLX LTD 2012).
29
Verfügbar 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 Verfügbar unter einer kommerzielle Lizenz oder unter „GNU GPL v2.0“, mehr Informationen zum Projekt unter http://dhtmlx.com/
(Stand: 21.08.2012).
57
Vorteile Nachteile
Back-End Konnektoren (aber nicht für No-de.js)
Lizenz kommerziell oder Open Source
Kein Node.js-Konnektoren
Design-Tool nicht sehr umfangreich
Tabelle 20 Vor- und Nachteile von Dhtmlx
Für das Projekt dieser Arbeit wurde ExtJS gewählt. Entscheidend war, dass dieses Tool eine robuste
Library ist. Viele GUI-Elemente sind schon definiert und man findet zudem Element um die Benutzer-
oberfläche zu strukturieren. Sencha Architect 2 ist für 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 abhängig 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
präsentiert werden, von denen der Editor abhängig ist.
CoffeeScript32 CoffeeScript ist eine Sprache, die im JavaScript kompiliert werden kann. Es enthält einen Parser so-
wie 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 für asynchrone
Aufrufe anzubieten, was das Original CoffeeScript noch nicht kann.
Express34 Express ist ein Web-Developement Framework. Es ermöglicht 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 für Node.js. Dank Jade kann man HTML produzieren, die Daten enthal-
ten. Es ist das Äquivalent zu Apache Velocity36 für JavaScript.
31 Mehr Informationen zum Projekt unter http://search.npmjs.org/ (Stand: 08.06.2012). 32 Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter http://coffeescript.org/ (Stand: 08.06.2012). 33
Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter http://maxtaco.github.com/coffee-script/ (Stand: 03.07.2012). 34 Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter http://expressjs.com/ (Stand: 08.06.2012). 35 Verfügbar 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).
58
Mongoose37 Mongoose ist ein Object-Relational-Mapping-Projekt (kurz: ORM) für MongoDB und Node.js. Mit
diesem Projekt ist es möglich, ein Datenbankschema für MongoDB zu definieren. Dann kann man
Daten hinzufügen und wieder abfragen.
Mongoose-auth38 Basierend auf dem Modul Everyauth39 bietet dieses Modul die Authentifizierung für ein Express Pro-
jekt mit Hilfe von Mongoose.
Underscore40 Underscore ist eine Sammlung von Basisfunktionen, die in JavaScript nicht standardmäßig 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 für 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 für Node.js.
Rimraf46 Sowie Mkdirp bietet Rimraf ein rekursives Löschen von Ordnern (sowie ‘rm -rf’ in Shell-Skript).
37 Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter http://mongoosejs.com/ (Stand: 08.06.2012). 38 Verfügbar 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 Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter http://underscorejs.org/ (Stand: 08.06.2012). 41 Siehe Webseite für die Lizenz - https://github.com/SaltwaterC/aws2js (Stand: 08.06.2012). 42 Verfügbar 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
Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter https://github.com/caolan/async/ (Stand: 08.06.2012). 45 Verfügbar unter der Lizenz „MIT/X11“, mehr Informationen zum Projekt unter https://github.com/substack/node-mkdirp (Stand:
08.06.2012). 46 Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter https://github.com/isaacs/rimraf (Stand: 08.06.2012).
59
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 für den Nuage-Editor geschrieben wurden.
Deswegen werden dafür die Beschreibungen detaillierter sein als für die anderen Bibliotheken.
SSHFS-node48 SSHFS-node ist ein Modul, mit dem entfernte Server mit Hilfe des SSH-Protokolls montieren werden
können. Es basiert auf dem Projekt SSHFS49. 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, readdir50 funktionie-
ren damit auf externen Dateien. Die genaue Funktionsweise von SSHFS wurde im Kapitel
„Systementwurf“ erläutert (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 für das Einbinden der Dateien verantwortlich. Für diese Funktion müssen
Benutzername, Domäne oder IP des Servers sowie das Ordnerziel, d. h. der Montageort gegeben
sein. Optional kann eine Callback-Funktion gegeben werden, die mit möglichen Fehlermeldungen
ausgeführt wird.
Die umount()-Funktion trennt die montierten Ressourcen wieder. Nur ein Argument ist Pflicht, näm-
lich 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
möchte, 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 abhängig. Sollte der SSHFS-Befehl nicht auf dem Computer in-
stalliert sein, wird das Modul nicht funktionieren.
Fs2http51 Fs2http ist die Abkürzung für “Filesystem to HTTP” und ist ein Node.js Modul. Es wurde gebaut, um
Express-Applikationen zu erweitern. Diese Erweiterung ist für Dateienänderungen zuständig. Die Idee
ist, ein Mapping zwischen den Node.js-Filesystem-Funktionen52 und dem HTTP-Protokoll zu bauen.
47 Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter http://vowsjs.org/ (Stand: 08.06.2012). 48 Verfügbar 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 Verfügbar 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).
60
Die wichtigen Funktionen wie rename()53, stat()54, writeFile()55 usw. werden als „Route“ für 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 mo-
difizieren oder die Pfade der Dateien ändern und damit Teile der Festplatte gegen Schreib- und Lese-
aktionen schützen. Es ist zudem möglich Middleware zu definieren. In Express werden Middleware-
Funktionen ausgeführt, bevor die eigentliche Route-Funktion ausgeführt 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 un-
terstützen. 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 Da-
tei /home/user/file lesen möchte, muss so die Datei /mnt/server1/home/user/file gelesen werden. Es
53 Dokumentation unter http://nodejs.org/api/fs.html#fs_fs_rename_path1_path2_callback (Stand: 11.06.2012). 54 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).
61
ist aber aus Sicherheitsgründen nicht erwünscht, dass Nutzer den vollständigen 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 HTTP-
Anfrage zwischen Etappe 1 und 2 der Abbildung 26).
Anschließend wird der Entwicklungsserver eingebunden, was Aufgabe der Middleware middle-
ware.mounter() ist, sofern noch nicht geschehen.
Während der Route-Funktion wird die Methode updatePath() ausgeführt. 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 zurück geschickt.
Abbildung 26 Fs2http-Beispiel-Anfrage
Die updatePath()-Methode wird nicht in dem Fs2http-Modul definiert, sondern direkt bei der Konfi-
guration 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 allge-
meingültig bleiben und dennoch weiter angepasst werden.
var express = require('express');
var fs2http = require('fs2http');
var middleware = require('middleware');
62
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 können. Auch diese Software wurde speziell für 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. Hauptsächlich liest die Software den Kommentar (im Javadoc-Format, siehe Listing 6) und gibt eine Ausgabe im JSON. Da-nach muss dieses JSON-Objekt in eine lesbare Version transformiert werden.
/**
* Escape the given `html`.
*
* Examples:
*
* utils.escape('<script></script>')
* // => '<script></script>'
*
* @param {String} html string to be escaped
* @return {String} escaped html
* @api public
*/
exports.escape = function(html){
return String(html)
.replace(/&(?!\w+;)/g, '&')
.replace(/</g, '<')
.replace(/>/g, '>');
};
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 lässt.
56 Verfügbar unter der Lizenz „MIT“, mehr Informationen zum Projekt unter https://github.com/cbou/markdox (Stand: 03.07.2012). 57 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).
63
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 während
des Projektes erstellt werden. Folgende unterschiedliche Funktionen erfüllt die Dokumentation:
Sie lehrt neuen Nutzern, wie man die Software bedienen kann. Dies ist das Hauptziel der Be-
dienungsanleitung.
Sie erklärt, wie man die Software installiert. Mit Hilfe der Installationsanleitung können die
Betreiber der Software besser verstanden werden. Sie erleichtert es zudem, die verschiede-
nen Schritte durchzuführen, damit die Software schnell angewendet werden kann. Beson-
ders 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
Für die Weiterentwicklung der Software, etwa um die Software zu erweitern oder um Plug-
ins zu entwickeln, sind tiefergehende Informationen notwendig. Das Design-Architektur-
Diagramm und Implementierungsspezifikation stellen technische Details dar. Sie werden in
diesem Bericht im Kapitel „Systementwurf“ umfassend dargestellt. Außerdem befindet sich
auf der CD eine Entwicklungsdokumentation, die die von dem Quellcode generierte Doku-
mentation enthält. Hier werden die Methoden und Klassen beschrieben (siehe Ordner „Do-
kumentation“ auf der CD).
6.4 Zusammenfassung Im diesem Kapitel wurde die Realisierung des Projektes erläutert. Es wurde gezeigt, dass JavaScript
als Sprache für 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 enthält alle Vorteile eines guten JavaScript-
Frameworks. Eine gute Dokumentation ist gegeben und ein effizientes MVC-Pattern wurde imple-
mentiert. Des Weiteren existieren bereits zahlreiche GUI-Elemente. Sencha Inc. (der Hersteller von
ExtJS) bietet ein Design-Tool, um GUI für ExtJS schnell zu kreieren. Um Daten zu persistieren, wurde
MongoDB, hauptsächlich wegen seiner Ähnlichkeit zu JavaScript, gewählt. Am Ende dieses Kapitels
64
wurden Module präsentiert, die speziell für dieses Projekt geschrieben wurden: SSHFS-node, Fs2http
und Markdox. SSHFS-node und Fs2http spielen eine große Rolle beim Zugriff auf Dateien über das
HTTP-Protokoll. Markdox ist für die Generierung von Entwicklerdokumentation zuständig.
65
7. Test Wie bereits im Kapitel „Aufgabenstellung“ ausgeführt, ist die Testphase für ein Software-Projekt von
enormer Bedeutung (siehe S. 7). Dafür existieren verschiedene Kontrollmöglichkeiten und Verfahren.
Im Folgenden werden zwei wichtige Methoden präsentiert: die White-Box und die Black-Box.
Black-Box: Mit der Black-Box-Methode werden Tests von einer außenstehenden 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 Unabhängigkeit 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 prüfen können, welche Teile des Quellcodes nicht getestet wur-
den. Mit dieser Methode kann man sicherstellen, dass sämtliche Bereiche getestet werden.
Beide Methoden ergänzen 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 für jene Stellen, die von der Black-Box nicht getestet wur-
den, weitere Tests entwickeln.
Diese Arbeit wurde von einer Einzelperson entworfen, weshalb es nicht möglich war, mehrere Ent-
wickler einzubinden. Die Tests, die hier programmiert wurden, sind also White-Tests. Während des
Projektes wurden regelmäßig weitere Tests entwickelt, denn es war wichtig, dass die Features wie
geplant funktionieren. Aus diesem Grunde wurden hauptsächlich funktionelle Tests erarbeitet. Es
gibt zwei Typen von Tests in diesem Projekt: Servertests und Browsertests. Beide werden im nächten
Abschnitt näher 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 unabhängig von der GUI sind. Die Tests wurden, wie der
Server, mit Node.js beziehungsweise mit der LibraryVows59 geschrieben. Vows ist ein Test-
Framework für Node.js. Es ermöglicht 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).
66
email : '[email protected]'
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 gleichmäßig
nach und nach gestartet. Man kann also mit dem ersten Batch einen Benutzer einloggen (wie im
Listing 8) und danach eine geschützte URL anfragen. Die Tests werden mit einem Shell-Befehl gestar-
tet 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-Ausführung von Tests
Damit die Tests anlaufen können, 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 für die Dummydaten,
nämlich jene Daten, welche am Anfang jedes Tests durchgeführt werden. Dieses Verfahren verein-
facht die Ausführung der Tests. Es ist ein Vorteil für 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. Außerdem sind auch Beispiel-Batches gegeben. Die komplette
Liste der Ausgaben der Servertests befindet sich im Anhang (siehe S. 105).
67
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 löschen usw. Unit-Test
Fs2http-Integration Ordner lesen Funktionstest
Fs2http mit neuem Server Server kreieren, Server montieren, Dateien lesen und schreiben
Funktionstest
Login Einloggen, Editoranfrage Funktionstest
Server Server kreieren, Server starten, Server stoppen usw. Funktionstest
Server-Modell Shell-Befehl schicken Unit-Test
Timestampable (Modell-Plug-in)
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 prüfen. Man kann sich jedoch nicht sicher sein,
dass ein Feature funktioniert, solange man nicht die GUI testet. Dafür 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 möglich, dass es zwischen dem Browser und dem HTML/CSS-Code ein Kompatibilitäts-
problem gibt. Dafür muss man Screenshots machen und diese entweder manuell oder auto-
matisch prüfen.
68
Das zweite Problem ist, dass es zu JavaScript-Fehlern kommen kann. Diese können die Nut-
zung des Programms blockieren. Um dies zu vermeiden reicht es, wenn der JavaScript-
Quellcode ausgeführt und darauf überprüft wird, dass es keine Fehler gibt.
Für die Browsertests wurde CasperJS60 benutzt. Dieses Projekt basiert auf PhantomJS61, einem kopf-
losen Webkit mit einer JavaScript-Schnittstelle. Das heißt, dass PhantomJS mit Hilfe des Webkit-
Projektes62 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 angekündigt (Step 2). Er soll die Login-URL aufrufen. Es wird
überprüft, ob der Statuskode der richtige ist (Step 3). Danach werden im Login-Formular die E-Mail-
Adresse sowie das Passwort hinzugefügt und das Formular validiert (Step 4). Die Tests und der kopf-
lose Browser sind voneinander unabhängig. Deswegen muss abgewartet werden, bis die Anfrage des
Benutzer-Einloggens beendet ist (Step 5). Nach einer Sekunde wird getestet, ob das Einloggen erfolg-
reich 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': '[email protected]',
'password': 'bad pass',
, false
@click '.btn-login'
# Step 5
@wait 1000, ->
@test.assertUrlMatch new RegExp(config.url.login), 'User is NOT re-
directed 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 prüfen. Zusätzlich kann das Projekt auch das Aussehen der Web-App prüfen. Mit
CasperJS ist es möglich, Screenshots zu machen (siehe Listing 10).
60 Mehr Informationen zum Projekt unter http://casperjs.org/ (Stand: 19.06.2012). 61 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).
69
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 erläutert. Die Tests erfüllen
gleich mehrere Aufgaben. Sie können dazu beitragen, dass bereits einmal aufgetretene Fehler zu-
künftig sicher vermieden werden. Außerdem kann man beispielsweise überprüfen, 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.
70
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. Für andere, ähn-
liche Projektentwicklungen ist eine Evaluation aber wichtig, denn die Ergebnisse werden in dieser
Phase präsentiert und evaluiert. Aufbauend auf den positiven und negativen Seiten eines Projektes
können spätere Projekte verbessert werden.
In diesem Kapitel soll es zunächst um die Schwierigkeiten und Herausforderungen in dieser Arbeit
gehen und im Anschluss daran um die positiven Aspekte des Projektes. Abschließend wird sich dieses
Kapitel mit den zukünftigen Einsatzmöglichkeiten des Projektes beschäftigen.
Tabelle 23, Tabelle 24 und Tabelle 25 zeigen alle im Kapitel „Pflichtenheft” beschriebenen Kriterien
(siehe S. 23) in Abhängigkeit ihres letzten aktuellen Bearbeitungsstandes (erledigt, teilweise erledigt
oder nicht erledigt).
Tabelle 26 zeigt Kriterien, die während der Entwicklung entdeckt wurden. Sie waren so wichtig, dass
sie vor den Kannkriterien erledigt wurden.
Kriterien Stand
Authentifizierung erledigt
Server-Management erledigt
Filebrowser erledigt
Dateieneditor erledigt
Plug-in-System erledigt
Editorkonfiguration erledigt
Tabelle 23 Bearbeitungsstand der Musskriterien
Kriterien Stand
Software-Installation teilweise erledigt
Shell-Terminal erledigt
Version-Control-System-Integration erledigt
Tabelle 24 Bearbeitungsstand der Sollkriterien
Kriterien Stand
Unix-Dateirechte nicht erledigt
Debugger nicht erledigt
Outline nicht erledigt
Refactoring nicht erledigt
Tabelle 25 Bearbeitungsstand der Kannkriterien
71
Kriterien Stand
Projektansicht erledigt
Tabelle 26 Bearbeitungsstand der Extrakriterien
Wie aus Abbildung 27 hervorgeht, wurden keine Kannkriterien bearbeitet. Stattdessen wurde eine
Projektansicht erstellt, die im Pflichtenheft nicht erwähnt wurde. Damit können 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 (sie-
he Abbildung 27).
Abbildung 27 Dateibaum vs. Projektansicht
8.1 Bestehende Probleme Für Entwicklungsprojekte ist es wichtig, eventuelle Probleme nach Fertigstellung der Arbeit zu identi-
fizieren. Wenn Schwierigkeiten bereits vor Projetbeginn bekannt sind, können sie entweder komplett
vermieden oder bei Eintritt leichter behoben werden. An dieser Stelle werden lediglich die techni-
schen Probleme gelistet sowie deren mögliche Lösungen. Für Unternehmensprojekte sollten darüber
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 für die Kommunikation mit dem Server zustän-
dig ist. In diesem Fall ist also nur die serverseitige Logik zu programmieren, damit Dateien oder Ord-
ner kreiert, gelistet, geändert und gelöscht werden können. Der Vorteil der Vorgehensweise, ExtJS zu
verwenden, ist es, Arbeit, Zeit und Geld zu sparen. Aus diesem Grund wurde sich für die Verwendung
von ExtJS entschieden.
72
Abbildung 28 Beispiel eines Tree-Panels
Der Nachteil daran ist, dass man von der Implementierung von ExtJS abhängig ist. In diesem Fall be-
trifft es die Kommunikation zwischen dem Server und dem Browser mit Hilfe von HTTP-Anfragen.
Wenn ein Ordner gelöscht werden soll, muss die ganze Kommunikation per HTTP übertragen wer-
den. Wenn die serverseitige Logik zu lange dauert, weil zum Beispiel zu viele Dateien zu löschen sind,
dann bricht der Browser die Kommunikation ab. Das wiederum hat zum Nachteil, dass nicht ange-
zeigt wird, ob das Löschen 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 für „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 längerem unterstützen 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 anschließend werden dort Nachrichten
ausgetauscht. Wenn eine Nachricht abgeschickt wurde, erhält man eine Bestätigung, ob die Nach-
richt 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 Unter-
stützung von Websockets anbieten. Eine mögliche Lösung 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 für dieses Projekt ein Kernfeature. Sie müssen schnell, sicher und
zuverlässig erfolgen können. Während des Systementwurfs wurde entschieden, die Zugriffe mit Hilfe
des Projektes SSHFS sowie des Node.js-Moduls SSHFS-node zu realisieren (siehe Abschnitt „Server-
Architektur“, Seite 40). Während der Entwicklung wurde aber festgestellt, dass in manchen Situatio-
nen das SSHFS-Projekt zu langsam reagierte.
Die Operationen mit Rekursion können lange dauern, falls es viele Dateien und Ordner gibt. In Linux
zum Beispiel müssen Ordner mit Inhalt rekursiv gelöscht werden, d. h. wenn man einen Ordner mit
Unterordnern oder Unterdateien löschen will, wird das Betriebssystem erst die Unterdateien und
Unterordner löschen. Das SSHFS-Projekt ist eine Dateisystem-Implementierung, in der die Kommuni-
73
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 dafür entschieden, diese spezielle Operation ohne SSHFS zu realisie-
ren. Das Löschen 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 Löschen-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, serv-
er.getHostOrIp(), path);
child = exec command, (err, stdout, stderr)->
if err
logger.errorutil.format('Deletion of %s failed', path) + ' ' +
err + ' ' + stderr
callback(err)
Listing 12 Löschen-Funktion
Diese Lösung hat jedoch einen Nachteil. SSHFS benutzt einen internen Cache. Wenn man eine Datei
mit SSHFS löscht, dann wird der Cache aktualisiert. Wenn man aber die Datei per SSH ohne Hilfe von
SSHFS löscht, dann wird SSHFS für 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 gelöscht markieren. Aus diesem Grund muss der Cache von SSHFS deaktiviert
werden.
Man könnte auch untersuchen, welche anderen Projekte statt SSHFS nutzbar wären. Mit Hilfe des
FTP-Protokolls oder Webdav zum Beispiel können Dateien und Ordner ebenfalls editiert werden. Es
sollte aber überlegt werden, ob die Nutzung solcher Protokolle keine Sicherheitsrisiken birgt. Außer-
dem ist die Installation von zusätzlicher Software für FTP und Webdav erforderlich. Ein SSH-Server ist
bei der Installation des Betriebssystems oft standardmäßig installiert und aktiviert.
Des Weiteren besteht kein Mechanismus, um die Unix-Rechte einer Datei zu ändern. Auf Linux-
Servern müssen manche Konfigurationsdateien mit Administratorrechten geändert werden. Für die
Entwicklung ist aber nicht erwünscht, dass Dateien mit Administratorrechten bearbeitet werden.
Deswegen wurde dieses Feature als Kannkriterium in dem Pflichtenheft spezifiziert (siehe Abschnitt
„Unix-Dateirechte“, S. 25). Aus zeitlichen Gründen konnte dieses Feature nicht implementiert wer-
den.
8.1.3 Abhängigkeit von Amazon
Das Projekt dieser Arbeit basiert auf dem IaaS-Angebot von Amazon, der Elastic-Compute-Cloud
(EC2). Dieses Produkt ist gut etabliert und zuverlässig. Alle Features, die für das Projekt nötig sind,
wie Servermanipulationen und Sicherheitskonfigurationen, sind vorhanden. Gleichzeitig besteht die
Gefahr einer Abhängigkeit von Amazon. Es sind insgesamt mehrere Abhängigkeitsfaktoren zu be-
trachten:
74
Technische Features: Zu Beginn eines Projektes ist es schwer abzuschätzen, ob später mög-
licherweise Features von der Cloud gebraucht werden, die nicht von Amazon unterstützt
werden. Dieses Problem kann die Entwicklung des Editors blockieren. Außerdem ist man ge-
genüber Problemen, die in der Cloud selbst auftreten, machtlos. Wenn eine technische Stö-
rung bei Amazon auftritt, können die Entwickler mit dem Editor nicht arbeiten. Dies ist be-
sonders problematisch, wenn Störungen zu ungünstigen Zeitpunkten passieren. Des Weite-
ren hat man auch keinen Einfluss auf die Performance der Cloud. Bei Amazon dauert die Er-
stellung eines Servers ungefähr eine Minute. In dieser Zeit kann der Entwickler nicht anfan-
gen zu arbeiten.
Kosten: Eine Abhängigkeit besteht des Weiteren von den Preisen, die Amazon verlangt. Für
die EC2 muss pro Stunde gezahlt werden. Für produktive Server ist dieser Umstand kein
Problem, weil sie ständig von Besuchern benutzt werden. Für Entwicklungsserver allerdings
ist die Nutzung der Server anderes gelagert. Sie ist vom Projekt abhängig, deshalb kann es
sein, dass manche Server zu groß für das Projekt sind. Das größte Problem hinsichtlich des
Kostenfaktors ist aber, dass man auch dann zahlen muss, wenn die Server nicht benutzt wer-
den. Wenn der Entwickler zum Beispiel für andere Projekte arbeitet, müssen trotzdem die
Server bezahlt werden. Natürlich ist es möglich, die Server automatisch herunterzufahren,
wenn sie nicht benutzt werden. Wie aber kann sichergestellt werden, dass die Server wirklich
nicht in Benutzung sind? Ein mögliches Problem könnte 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 ursprünglich gemeinsam von der Nasa und
Rackspace entwickelt wurde und das dieses Problem umgeht. Dabei handelt es sich um das soge-
nannte OpenStack. Dieses Projekt wurde im Kapitel „Fachliches Umfeld“ (siehe Abschnitt
„OpenStack“, S. 13) bereits erwähnt.
Wenn man den Editor auf Basis von OpenStack umsetzen würde, hätte man die Chance, die Cloud,
auf der die Entwicklungsserver laufen, zu beeinflussen. Man könnte zudem Lösungen entwickeln,
damit die Erstellung von Servern schneller funktioniert. Allerdings gibt es hier einige andere Heraus-
forderungen und Probleme, die man vorher lösen müsste, wie zum Beispiel im Bereich Sicherheit
oder Verfügbarkeit der Entwicklungsserver. Es gibt keine eindeutige Lösung zwischen EC2, OpenStack
oder anderen IaaS-Anbieter. Die Entscheidung hängt davon ab, was genau umgesetzt werden soll
und wie das Produkt (der Editor) gewünscht ist.
8.2 Positiver Aspekt Nicht nur Probleme sind bei der Projektabschlussphase zu diskutieren. Es ist wichtig, auch positive
Aspekte des Projektes zu erwähnen. In diesem Abschnitt werden einige gute technische Entschei-
dungen präsentiert.
75
8.2.1 JavaScript als Programmiersprache
Wie bereits im Kapitel „Realisierung“ betrachtet, ist die Logik des Projektes nur mit der Programmier-
sprache JavaScript entwickelt worden (siehe S. 54). Clientseitig bestehen dahingehend fast keine
anderen Möglichkeiten, serverseitig wurde Node.js (ein JavaScript-Framework) ausgewählt und für
die Datenbank wurde sich für MongoDB entschieden. MongoDB ist teilweise in JavaScript geschrie-
ben. Außerdem werden Suchfunktionen wie MapReduce oder Query in JavaScript geschrieben.
Die Entscheidung für diese Programmiersprache hat viele Vorteile mit sich gebracht. In der Web-App-
Entwicklung ist es häufig der Fall, dass man einen Server sowie eine Client-Software entwickeln muss.
Beide hängen 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 können server- und clientseitig genutzt werden.
8.2.2 Tests
Während des Projektes wurden regelmäßig 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 darüber, ob Features und
Funktionen wie angedacht laufen. Außerdem lässt sich eine getestete Software besser modifizieren
(Refactoring).
8.3 Zusammenfassung Dieses Kapitel gab einen Rückblick auf das gesamte Projekt. Alle positiven und negativen Aspekte der
Arbeit sind hier vorgestellt worden. Dies ist für zukünftige Projekte besonders wichtig, da von den
Fehlern als auch von den Erfolgen profitiert werden kann.
In diesem Kapitel wurden ausschließlich technische Probleme präsentiert z. B. die Kombination zwei
verschiedener Projekte (SSHFS und SSH), um den Zugriff auf die Festplatten zu gewährleisten. Dies
kann bei zukünftigen Entwicklern, die das Nuage-Projekt fortsetzen wollen, zu Missverständnissen
führen. Bisher wurde jedoch keine Alternative gefunden.
Ein anderer wichtiger Punkt ist die Abhängigkeit von Amazon. Wie bereits erwähnt, kann es später zu
Schwierigkeiten kommen, wenn das IaaS-Angebot von Amazon sich ändert oder aber, wenn sich die
Anforderungen des Nuage-Servers ändern.
76
9. Zusammenfassung In der vorliegenden Arbeit ging es um die Entwicklung einer universellen, Cloud-basierten Entwick-
lungsumgebung. Das Ziel war die Konzeption eines Entwurfes sowie die Erstellung einer Software.
Demzufolge wurde das Projekt in einem ersten Schritt präsentiert und anschließend in allen seinen
Entwicklungsetappen von der Idee bis zur Umsetzung beschrieben.
Die Arbeit folgte den klassischen Schritten eines Softwareprojektes. Jedes Kapitel widmet sich detail-
liert jeweils einem Schritt:
Die Kapitel „Einleitung“ (siehe S. 1) und „Fachliches Umfeld“ (siehe S. 9) behandelten die Pro-
jektinitiierungsphase. Einleitend wurde eine kurze Einführung in die Thematik gegeben. Dann
wurde in Kapitel Eins die Problematik dargestellt, gefolgt von einer möglichen Lösung, die in
dieser Arbeit erarbeitet wurde. Im zweiten Kapitel wurde dann eine Auswahl von Cloud-
Lösungen, Desktop-Editoren und Cloud-Editoren präsentiert und evaluiert, wodurch ein
Überblick über die gesamte Thematik gegeben wurde.
Das Kapitel vier enthält das „Pflichtenheft“ (siehe S. 23). Dort wurde das Projekt genau spezi-
fiziert. Die Ziele sowie die Funktionen des Produktes wurden in Form von Kriterien erläutert.
Dies verhalf dazu, eine Übersicht über das Projekt zu haben, um den Systementwurf zu er-
stellen. Außerdem wurden die Umgebungen des Produktes dargestellt, sowohl die techni-
sche, 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 präsentiert
wurde. Außerdem wurden technische Besonderheiten, wie das Einbinden von Festplatten
mit Hilfe des SSHFS-Projektes, erläutert.
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 er-
läutert. Dabei sind zunächst die letzten noch offenen Entscheidungen getroffen worden, z. B.
die Auswahl der Programmiersprachen und die Bibliotheken. Außerdem wurden die Open-
Source-Projekte, die speziell für diese Arbeit geschrieben wurden, genauer präsentiert. Diese
Software-Programme sind unter der MIT-Lizenz frei verfügbar.
Das Kapitel „Test“ (siehe S. 65) stellt dar, wie die für das Projekt vorgenommenen Tests ent-
wickelt wurden und geht zudem darauf ein, welche Tools für die Testentwicklung verwendet
wurden. Test-Szenarien (siehe S. 67 und S. 69) sowie deren Ausgaben (siehe Anhang, S. 105)
wurden vorgestellt. Damit lässt sich erkennen, welche Anteile der Software getestet wurden,
um zum Beispiel neue Tests zu schreiben, was wiederum die Zuverlässigkeit des Programms
verbessert.
Schließlich 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 für zukünftige Projekte zu ziehen. Außerdem wurden technische Entscheidungen, wie
z. B. die Auswahl der Programmiersprache, kurz evaluiert. Dies kann für zukünftige Projekte
von Bedeutung sein.
77
Wie bereits erwähnt, wurde in dieser Arbeit ein universeller Software-Editor entwickelt, der in einer
Cloud läuft. Dieses Programm nennt sich „Nuage“. Das Wort ist die französische Übersetzung für 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 weiterge-
arbeitet werden kann. Es ist keine zusätzliche Software mehr notwendig, sondern lediglich eine In-
ternetverbindung. Diese Eigenschaft macht den größten Vorteil des Projektes aus. Wie eine Webseite
kann dieser Editor von jedem Computer der Welt aus benutzt werden, der über eine Internetverbin-
dung verfügt. Der Editor kann in kritischen Situationen sehr effizient sein, wie z. B. wenn die Software
dringend reparieren werden muss. Darüber hinaus enthält der Editor aber auch andere Qualitäten.
Ein anderes wichtiges Ziel des Produktes war es, seine Universalität zu gewährleisten. Der Editor
wurde nicht nur für eine bestimmte Programmiersprache oder Technologie entwickelt, sondern kann
für jedes Software-Projekt, unabhängig von der verwendeten Programmiersprache, verwendet wer-
den. Der Vorteil ist, dass man nicht mehrere Tools erlernen muss, sondern sich auf eines konzentrie-
ren kann. Der Nachteil ist aber, dass die Entwicklung dieses Editors schwieriger war. Man muss uni-
verselle Konzepte entwickeln, die für jede Sprache verwendbar sind. Dies kann mitunter sehr kom-
plex sein, da Sprachen, Systeme und Plattformen sehr unterschiedlich sein können.
Der Editor basiert auf der Technik der Cloud. Das bedeutet, dass die Entwicklung von Programmen
auf den Entwicklungsserver stattfinden. Diese Server gehören dem Benutzer. Mit Hilfe des Nuage-
Servers können im Browser Dateien bearbeitet oder SSH-Zugänge erstellt werden, um Befehle zu
verschicken. Weil die Entwicklungsserver nicht zum Editor gehören, haben Benutzer kompletten Zu-
griff auf die Server und können 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 persönlich konfigurieren können. Bisher sind Schriftart und
Schriftgröße 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 möglich, die Benutzer-
oberfläche anzupassen, um neue Funktionen hinzuzufügen. Im Rahmen dieser Arbeit wurden ein
paar Plug-ins beispielhaft programmiert, wie z. B. die Git-Integration. Man kann sich auch viele weite-
re Möglichkeiten vorstellen, wie z. B. Datenbanken-Management, IaaS-, PaaS- und SaaS-Integration
oder spezielle Framework-Features.
Doch diese neuen Möglichkeiten können hohe Sicherheitsrisiken mit sich bringen. Die Plug-ins wer-
den oft von der Community entwickelt, weshalb nicht auszuschließen ist, dass manche davon Viren
enthalten können. Ein Plug-in beispielsweise, welches für IaaS-Integration zuständig ist, könnte
gleichzeitig die Berechtigungsnachweise der IaaS stehlen. Dieses Sicherheitsrisiko besteht für alle
Projekte mit Plug-in-Systemen. Es ist zudem Aufgabe der Community, Systeme, wie z. B. Bewertungs-
systeme, zu entwickeln, um schädigende Applikationen abzuwehren. Außerdem wäre es möglich,
dass der Betreiber des Editors die Plug-ins selber kontrolliert. Diese zwei Kontrollen wären optimal.
Die Gefahr, dass ein unerwünschter Plug-in trotz Kontrollen dennoch akzeptiert wird, bleibt jedoch
bestehen.
78
9.1 Zukünftige Möglichkeiten 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 könnten, um den
Editor zuverlässiger und effizienter zu machen. Zum Beispiel könnte Websocket statt AJAX für die
Kommunikation zwischen dem Server und den Browsern benutzet werden (siehe S. 71). Dank Web-
socket würden lange Anfragen nicht mehr einfach abbrechen.
Außerdem könnte der Zugriff auf die Festplatte verbessert werden. Im Moment ist eine Mischung
aus SSHFS und SSH für diese Aufgabe zuständig. Obwohl die aktuelle Methode zuverlässig und funk-
tionell ist, wäre es besser, eine Methode zu finden, die nicht aus einer technologischen Mischung
besteht. Für spätere Entwicklungen wäre dies einfacher nachzuvollziehen.
Das Produkt kann mit Plug-ins erweitert werden. Das Plug-in-System ist im Moment klein und ein-
fach. Für eine intensive Nutzung des Editors würde diese Erweiterungsmethode aber nicht ausrei-
chen. Es fehlen Features, beispielsweise für die Installation von Plug-ins. Derzeit ist die Installation
von Plug-ins sehr aufwendig. Die Nutzer müssen 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 durchgeführt werden, erst muss das Plug-in gelöscht werden, um dann mit
der neueren Version nochmal installiert zu werden. Alle diese manuellen Schritte könnten vermieden
werden, wenn man das Plug-in-System verbessern würde. Man könnte zum Beispiel ein Repository
kreieren, um alle Plug-ins zentral zu speichern. Damit könnten die Installation und die Aktualisierung
automatisch ablaufen.
Weiterhin stellt sich die Frage, welche IaaS-Anbieter oder Open-Source-Projekte man nutzen möchte,
um die Entwicklungsserver zu managen. Im Moment sind zwei Möglichkeiten programmiert: Ama-
zon-EC2 und Server per SSH. Die erste Variante ist für neue Benutzer sehr hilfreich, weil sie anfangs
keine Server benötigen. Dieser wird für 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. Für die Zukunft muss sich daher die Frage gestellt werden,
welchen genauen Zweck das Projekt weiterhin erfüllen soll, um anschließend entscheiden zu können,
welche IaaS-Lösungen integriert werden müssen.
Zum Beispiel könnte für einen internen Editor einer Firma eine selbsgehostete Open-Source-IaaS-
Lösung, wie OpenStack, genutzt werden. Der Vorteil hierbei läge darin, dass man die komplette Kon-
trolle über die Entwicklungsserver selbst hätte. Für Firmen, die schon Rackspace oder Amazon nut-
zen, ist ein solches System möglicherweise dennoch nicht geeignet. Die Entscheidung hängt 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 Bu-
siness-Modell passen.
Eine Möglichkeit wäre, alle IaaS-Integrationen mit Hilfe von Plug-ins zu realisieren. Zuerst müsste
evaluiert werden, ob es möglich wäre, mit Hilfe von JavaScript vom Browser aus mit den API-
Schnittstellen zu kommunizieren. Wenn das der Fall ist, dann kann man ein Plug-in pro IaaS-Anbieter
entwickeln.
79
Auf das Geschäftsmodell wurde in dieser Arbeit bisher nicht näher eingegangen, obwohl eine solche
SaaS-Software wie der vorgestellte Editor neue Möglichkeiten bietet. Im Gegensatz zu Desktop-
Applikationen ermöglichen Software-As-A-Service-Programme es, eine genaue Messung der aktuel-
len Nutzung der Benutzer vorzunehmen. Daher kann nur die Zeit gezählt werden, in der man das
Programm tatsächlich genutzt hat. Für Amazon-EC2-Instanzen wird zum Beispiel pro Stunde abge-
rechnet, statt monatlich wie bei anderen Hosts. Soll dieser Editor zur Nutzung käuflich erwerblich
sein, so sollte vorher untersucht werden, welches Geschäftsmodell sich am besten eignen würde.
Schließlich wurde während der Erstellung dieser Arbeit ein funktioneller Software-Editor entwickelt.
Dieser kann von seinem Entwicklungszustand her bereits genutzt werden, um damit andere Pro-
gramme zu erstellen. Der Editor kann zudem erweitert werden und um neue Funktionen ergänzt
werden. Allerdings sollte in diesem Fall zunächst untersucht werden, wie er am besten verwendet
wird bzw. für welche Zwecke er in der Firma oder auf dem Markt dienlich sein könnte.
80
10. Abkürzungsverzeichnis
AWS Asynchronous JavaScript and XML
AWS Amazon Web Services
CSS Cascading Style Sheets
DOM Document Object Model
EC2 Elastic Compute Cloud
FTP File Transfer Protocol
GUI Graphical User Interface
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
I/O Input/Output
IDE Integrated Development Environment
JS JavaScript
MVC Model View Controller
NASA National Aeronautics and Space Administration
NPM Node Package Manager
ODM Object Document Mapping
ORM Object Relational Mapping
PaaS Platform As A Service
PHP Hypertext Preprocessor
S3 Simple Storage Service
SaaS Software As A Service
SCM Software Configuration Management
SSH Secure Shell
SSHFS SSH Filesystem
SVN Subversion
TCP Transmission Control Protocol
UML Unified Modeling Language
URL Uniform Resource Locator
VCS Version Control Systems
WWW World Wide Web
XML Extensible Markup Language
81
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 Dy-namische 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. München: Com-puterwoche 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. München: 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).
82
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. Ge-nève: ISO copyright office. S. 9-10.
Kaner C./Falk J.L/Nguyen H. Q. (1999): Testing Computer Software. New York: Wiley Computer Pub-lishing. S. 52.
Kleinman, Sam (2012): Basic Nginx Configuration - Linode Library URL: http://library.linode.com/web-servers/nginx/configuration/basic (Stand: 06.06.2012).
Lemay, Laura/Colburn, Rafe (2011): Web Publishing with HTML and CSS. Indianapolis: Sams Publish-ing. 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/man-pages/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-php-ides-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/newsrelease67.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).
83
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 In-dustry 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 Appli-cations. 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) Pro-grams. 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).
84
12. Anhang
85
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
86
Bedienungsanleitung
In diesem Abschnitt werden drei Anleitungen präsentiert:
„Quick Start“ erklärt die ersten Schritte in dem Editor.
Die Anleitung „Start to Code“ erläutert, wie man mit der Programmierung beginnt.
In „Advanced Features“ werden die fortgeschrittenen Features präsentiert.
Diese Anleitungen wurden zwischen dem 15. und dem 20. Juli 2012 verfasst. Es kann folglich sein,
dass manche Screenshots bereits veraltet sind.
Damit ein größeres 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.
87
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.
88
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".
89
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 cre-
ate a new project.
Open the file browser and navigate to the home directory.
90
Then create a new folder by right-clicking on the directory ec2-user and then click on "Create fold-
er".
You can name it 'my-new-project' and click on ”Save”.
91
Now you can create a project in this folder. Just right-click on the folder and click on "Create Pro-
ject".
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.
92
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 pro-
ject".
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.
93
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.
94
After that you can compile your new program:
$ gcc main.c
and execute it:
$ /a.out.
95
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 direc-
tory 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".
96
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.
97
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 Re-
place”. A confirmation should appear in the Log tab:
[Monday, July 16th 2012, 2:26:41] [debug] start shell command grep -ri "World" /home/ec2-user/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.
98
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 that’s 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 infor-
mation 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.
99
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".
100
Settings will change in real-time, you can open a file or a plugin code to see how your code is chang-
ing.
101
Nuage Installation
In diesem Abschnitt wird die Installation des Nuage-Editors auf einem Server präsentiert. Damit ein
größeres 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:
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
102
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
103
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:
104
{ "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".
105
Ausgaben der Tests
In diesem Abschnitt werden die Ausgaben der Tests präsentiert. Sie wurden am 13. Juli 2012 ausge-
führt. Zuerst werden Server-Tests aufgezeigt und im Anschluss daran die Browsertests.
Servertests
[ec2-user@domU-12-31-38-04-8A-1B ~]$ npm test
> [email protected] 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
106
♢ 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
107
✓ 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
108
✓ 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
109
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
110
♢ 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
> [email protected] 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.
111
Use-Case-Diagramme
Hier werden die Use-Cases, die während der Realisierung des Pflichtenhefts gemacht wurden, dar-
gestellt. Die Funktionen sind gruppiert und markiert, um zu zeigen, ob sie Muss- Soll- oder Kannkri-
terien sind. Die Legende wurde wie folgt definiert: die Musskriterien sind rot, die Sollkriterien gelb
und die Kannkriterien sind grün markiert.
112
113
114
115
Wireframe-Prototypen
In diesem Teil des Anhangs werden die Prototypen des Projektes präsentiert. Diese wurden am An-
fang der Arbeit erstellt, um eine Analyse vorzunehmen. Allerdings wird hier nur ein Teil der
Wireframes gezeigt, die komplette Liste befindet sich auf der CD63.
Login-Formular
63 Siehe Ordner „Prototypen“ auf der CD.
116
Hauptscreen des Editors
117
„Suchen und Ersetzen“-Funktion
118
Server-Liste
119
Server Löschen Bestätigung