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: charles.bourasseau@gmail.com

Die aktuelle Version der Software befindet sich auf der CD, die dieser Arbeit beiliegt, im Ordner „Repository“.

Der Inhalt der CD befindet sich unter diese URL: http://bit.ly/masterarbeit-bourasseau-cdrom-zip

Das Video befindet sich unter dieser URL: http://bit.ly/masterarbeit-bourasseau-video

Die Masterarbeit befindet sich als PDF unter dieser URL: http://bit.ly/masterarbeit-bourasseau-pdf

Inhaltsverzeichnis

1. Einleitung ...................................................................................................................................................... 1

1.1 Problemstellung ................................................................................................................................... 2

1.2 Zielstellung ........................................................................................................................................... 3

2. Aufgabenstellung .......................................................................................................................................... 4

2.1 Konzept ................................................................................................................................................ 4

2.2 Software-Design ................................................................................................................................... 5

2.3 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>')

* // => '&lt;script&gt;&lt;/script&gt;'

*

* @param {String} html string to be escaped

* @return {String} escaped html

* @api public

*/

exports.escape = function(html){

return String(html)

.replace(/&(?!\w+;)/g, '&amp;')

.replace(/</g, '&lt;')

.replace(/>/g, '&gt;');

};

Listing 6 Dox-Kommentar-Beispiel

Markdown ist eine Klartextsyntax, die entweder ohne Umwandlung gelesen oder in andere Formate

wie HTML oder Microsoft Word umgewandelt werden kann. Vorteil an Markdown ist, dass die Syntax

sehr einfach ist und sich deswegen gut transformieren 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 : 'valid@example.com'

password : 'test'

, this.callback

return

'we got no error': (err, req, body) ->

assert.isNull err

assert.equalreq.statusCode, 200

)

Listing 8 Vows-Beispiel

Das Listing 8 zeigt einen Beispiel-Test, einen sogenannten “Batch”. Die Batches werden 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': 'valid@example.com',

'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:

ssh ec2-user@ec2-23-22-69-111.compute-1.amazonaws.com

Installation of needed Libraries

First check that your instance is updated, if not please do it.

$ sudo yum update

Then you need to install the group "Development Tools". It contains gcc and other tools useful for

the development.

$ sudo yum groupinstall "Development Tools"

This package is for Node.js

$ sudo yum install openssl-devel

Git should be already install, if not you need to do it.

$ sudo yum install git

This package is for Nuage Server

$ sudo yum install libxml2-devel.x86_64

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

> nuage-editor@0.1.0 test /home/charles/Repositories/Nuage

> vows test/vows/*-test.coffee --spec

♢ Try the AWS Cloud Connector library

when loading fixtures

✓ we got no error

when Creating an ec2 instance with valid parameters

✓ we got no error

when waiting that instance is running

✓ we got no error

when checking that the created instance is running

✓ we got no error

✓ instance is running

when stopping the created instance

✓ we got no error

✓ current state is stopping

when waiting that instance is stopped

✓ we got no error

when checking that the created instance is stopped

✓ we got no error

✓ instance is stopped

when starting the created instance again

✓ we got no error

✓ current state is pending

when waiting that instance is running again

✓ we got no error

when restarting the created instance

✓ we got no error

when deleting the created instance

✓ we got no error

✓ current state is shutting-down

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

> nuage-editor@0.1.0 casperjs /home/charles/Repositories/Nuage

> sh test/casperjs/test.sh

PASS Anonymous user should be redirected

PASS User is NOT redirected after sending wrong credentials

PASS Anonymous user should be redirected

PASS User is redirected after sending right credentials

PASS 4 tests executed, 4 passed, 0 failed.

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