Verbesserung von Testbarkeit, Entwicklungskomplexität und

D EPARTMENT I NFORMATIK
Verbesserung von Testbarkeit,
Entwicklungskomplexität und Architektur
—
Austausch der Oberflächentechnologie einer
Web-Anwendung
D IPLOMARBEIT
Eingereicht von: Sönke T HIESEN
Matr.-Nr.: 5598749
[email protected]
Erstgutachter: Prof. Dr. Horst O BERQUELLE
Zweitgutachter: Dr. Wolf-Gideon B LEEK
Hamburg, April 2009
iii
Danksagung
Diese Arbeit ist nicht die Leistung eines Einzelnen. All denen, die einen Beitrag geleistet haben,
möchte ich an dieser Stelle meinen Dank aussprechen.
Professor Horst Oberquelle, dem Erstgutachter dieser Arbeit, der sich bereit erklärt hat diese
Arbeit zu betreuen. Danke, dass sie diese Arbeit ermöglicht haben.
Doktor Wolf-Gideon Bleek, dem Zweitgutachter dieser Arbeit, der mich während des gesamten
Zeitraums unterstützt hat. Danke, für die Zeit, die du für mich aufgebracht hast.
Nadja Stoppel, meiner Frau fürs Leben, für ihre Geduld und Unterstützung. Danke, dass es dich
gibt !i!
Salim Rechenberg, für zeitnahes, kompetentes Feedback, nicht nur während dieser Arbeit, auch
während des Studiums. Danke, für deine Hilfe.
Ilker Daricili, für Inspiration und Ablenkung, ebenfalls auch während des Studiums. Danke, für
deine Hilfe.
Heidrun Thiesen, meiner Mutter, fürs fleißige und schnelle Korrekturlesen. Danke, dass du für
mich dem Computer getrotzt hast.
Und natürlich danke ich allen meinen Freunden und Bekannten, die es mir nicht übel genommen
haben, dass ich so lange beschäftigt war. Danke, fürs Warten.
Inhaltsverzeichnis
iv
Inhaltsverzeichnis
1 Einleitung
1.1
1.2
1.3
1
Motivation und Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1
2.2
2.3
2.4
Konzepte . . . . . . . . . . . . .
2.1.1 Testen . . . . . . . . . . .
2.1.2 Entwicklungskomplexität
2.1.3 Software-Architektur . . .
2.1.4 Entwicklungssprache . . .
2.1.5 Fachlogik . . . . . . . . .
2.1.6 Entwurfsmuster . . . . . .
2.1.7 Vorgehensmodell . . . . .
2.1.8 Refactoring . . . . . . . .
Technologien . . . . . . . . . . .
2.2.1 Servlet . . . . . . . . . .
2.2.2 Cascading Style Sheets . .
2.2.3 Hibernate . . . . . . . . .
2.2.4 Spring . . . . . . . . . . .
CommSy . . . . . . . . . . . . .
2.3.1 JCommSy . . . . . . . . .
Zusammenfassung . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Architekturmodell . . . . . . . . . . . . . . .
Überarbeitetes Architekturmodell . . . . . .
3.2.1 Refactorings . . . . . . . . . . . . .
Trennung von Fachlogik und Präsentation . .
3.3.1 Fachlogik des CommSy . . . . . . .
3.3.2 Fachlogik in der Präsentationsschicht
3.3.3 Refactoring . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Architektur des JCommSy
3.1
3.2
3.3
3.4
1
1
2
3
3
4
6
7
8
8
8
8
9
9
10
10
10
11
11
11
12
12
13
15
16
16
17
17
20
Inhaltsverzeichnis
v
4 Eine neue Oberächentechnologie
4.1
4.2
4.3
4.4
4.5
4.6
21
Bisherige Oberflächentechnologie . . .
4.1.1 JSP-Dokumente . . . . . . . .
4.1.2 Fragmente und Ausstatter . . .
Verfügbare Oberflächentechnologien . .
Kriterienkatalog . . . . . . . . . . . . .
4.3.1 Arbeitshypothese . . . . . . . .
4.3.2 Harte Kriterien . . . . . . . . .
4.3.3 Weiche Kriterien . . . . . . . .
Bewertung anhand des Kriterienkatalogs
4.4.1 Falsche Ebene . . . . . . . . .
4.4.2 Kein reines Java . . . . . . . .
4.4.3 Nicht lebendig . . . . . . . . .
4.4.4 Nicht kompatibel . . . . . . . .
Evaluation durch Prototypen . . . . . .
4.5.1 Umfang der Prototypen . . . . .
4.5.2 Bewertung der Prototypen . . .
4.5.3 Auswertung und Auswahl . . .
Zusammenfassung . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Realisierung der neuen Benutzungsoberäche
5.1
5.2
5.3
5.4
Integration . . . . . . .
5.1.1 Schnitt . . . .
5.1.2 Konfiguration .
Benutzungsoberfläche .
Technische Interaktion
Zusammenfassung . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Testbarkeit . . . . . . . . . . . . . . . .
6.1.1 Vor dem Technologiewechsel .
6.1.2 Nach dem Technologiewechsel .
6.1.3 Fazit . . . . . . . . . . . . . . .
Entwicklungskomplexität . . . . . . . .
6.2.1 Vor dem Technologiewechsel .
6.2.2 Nach dem Technologiewechsel .
6.2.3 Fazit . . . . . . . . . . . . . . .
Architektur . . . . . . . . . . . . . . .
6.3.1 Vor dem Technologiewechsel .
6.3.2 Nach dem Technologiewechsel .
6.3.3 Fazit . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Auswirkungen des Technologiewechsels
6.1
6.2
6.3
6.4
21
21
22
23
25
25
26
27
28
28
28
28
29
29
30
31
38
39
40
41
42
46
47
47
50
50
52
53
54
55
55
58
60
60
61
61
62
63
Inhaltsverzeichnis
vi
7 Schlussbemerkungen
7.1
7.2
Fazit . . . . . . . . . . . . . . . . . . . .
7.1.1 Ergebnisse dieser Arbeit . . . . .
7.1.2 Verallgemeinerung der Ergebnisse
7.1.3 Rückblick . . . . . . . . . . . . .
Ausblick . . . . . . . . . . . . . . . . . .
64
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
64
65
66
67
Literaturverzeichnis
68
Sonstige Verzeichnisse
72
Inhalt der CD-ROM
74
Kapitel 1 Einleitung
1
Kapitel 1
Einleitung
Die Motivation diese Arbeit zu schreiben und die Zielsetzung mit der dies geschah, werden
in diesem Kapitel beschrieben. Gefolgt von einer Beschreibung des Aufbaus dieser Arbeit und
einem kurzen Abschnitt über Konventionen, die für diese Arbeit gelten.
1.1 Motivation und Zielsetzung
Während des Studiums habe ich an einem Projekt teilgenommen, dass die Weiterentwicklung
des JCommSy zum Inhalt hatte. Durch dieses Projekt habe ich den Untersuchungsgegenstand
dieser Arbeit, das JCommSy, kennengelernt. Über einen Zeitraum von mehreren Monaten habe ich am JCommSy gearbeitet und ein persönliches Interesse an der Weiterentwicklung des
JCommSy entwickelt. Während dieser Zeit ist aufgefallen, dass die Einarbeitungszeit beim
JCommSy sehr lang ist, hauptsächlich weil die Beteiligten von der Komplexität des Systems
überwältigt waren. Bei einem Universitäts-Projekt mit einer Laufzeit von 13 Wochen ist eine
kurze Einarbeitungszeit wichtig, um produktiv arbeiten zu können. Diese Arbeit soll die Komplexität für Entwickler am JCommSy reduzieren.
Ein weiterer Punkt, der im Entwicklungsalltag auffiel, ist, dass das Ausführen von Tests, bei
denen die Benutzungsoberfläche involviert war, viel Zeit in Anspruch genommen hat (über 30
Minuten). Auch dieser Aspekt des JCommSy soll durch diese Arbeit verbessert werden.
Während des Projekts war auch die Architektur des JCommSy Thema in Diskussionsrunden. Es
gab nur eine grobe Beschreibung, aber schon gegenüber dieser gab es Verletzungen im System.
Die Architektur soll ebenfalls durch diese Arbeit verbessert werden.
Als Mittel, um Verbesserungen von Testbarkeit, Entwicklungskomplexität und Architektur zu
erreichen, wurde ein Wechsel der Oberflächentechnologie gewählt. Hauptsächlich, weil die bisher verwendetet JSP-Technologie an vielen der Probleme beteiligt war. Die Benutzbarkeit der
Oberfläche spielte dabei keine Rolle.
1.2 Aufbau
Die Arbeit ist folgendermaßen aufgebaut:
Im Kapitel Grundlagen werden wichtige Begriffe definiert, Konzepte, Technologien und das
CommSy eingeführt.
Unter Verwendung der vermittelten Begriffe wird im Kapitel Architektur des JCommSy eine
Untersuchung der Architektur des JCommSy vorgenommen. In dem Zusammenhang werden
vorbereitende Arbeiten, eine Architekturüberarbeitung und ein Refactoring der Fachlogik, geschildert.
Das Kapitel Eine neue Oberflächentechnologie beschreibt nach welchen Gesichtspunkten die
1.3 Konventionen
2
neue Oberflächentechnologie ausgewählt und wie dabei im einzelnen vorgegangen wurde.
Die neu implementierte Oberfläche wird in Kapitel Realisierung der neuen Benutzungsoberfläche kurz beschrieben, ihre Konfiguration und Integration ins JCommSy werden ausführlicher
beschrieben.
Dann werden die Auswirkungen des Technologiewechsels im gleichnamigen Kapitel untersucht.
Die Situation vor und nach dem Austausch wird für die Aspekte Testbarkeit, Entwicklungskomplexität und Architektur beschrieben und je ein Fazit gezogen, ob eine Verbesserung eingetreten
ist.
Im letzten Kapitel Schlussbemerkungen werden die Ergebnisse dieser Arbeit noch einmal konkret formuliert und eine Verallgemeinerung dieser angestrebt. Ein Rückblick bewertet den Prozess, in dem diese Arbeit erstellt wurde, und ein Ausblick zeigt auf, was noch getan werden
könnte.
1.3 Konventionen
Klassen- und Packagenamen, sowie andere programmiersprachliche Konstrukte, werden in einer speziellen Schriftart dargestellt, z. B. CommSyServlet.
Zwischen männlicher und weiblicher Form wird in dieser Arbeit nicht unterschieden. Eine Nennung der männlichen Form impliziert immer auch die weibliche Form, z. B. ist mit Entwickler
auch Entwicklerin gemeint.
Kapitel 2 Grundlagen
3
Kapitel 2
Grundlagen
Im Verlauf dieser Arbeit werden Konzepte, Technologien und Anwendungen genannt, die nicht
jedem Leser geläufig sind oder bei denen unterschiedliche Auffassungen möglich sind. In diesem Kapitel werden die wichtigsten Begriffe eingeführt und können in den darauffolgenden Kapiteln als gemeinsame Basis für Argumentationsketten verwendet werden. Leser, die mit dem
Themengebiet bereits vertraut sind, können dieses Kapitel überspringen und gegebenenfalls einzelne Begriffe nachschlagen. In jedem Fall sollte die Definition 2.1.4 Entwicklungskomplexität
auf Seite 5 beachtet werden, da der Begriff für diese Arbeit selbst definiert wird.
2.1 Konzepte
Neben den Konzepten Testbarkeit, Entwicklungskomplexität und Architektur, die bereits im Titel erwähnt werden, werden auch Fachlogik, Entwicklungssprache, Entwurfsmuster, Vorgehensmodell und Refactoring eingeführt.
2.1.1 Testen
„Unter dem Testen von Software wird jede (im Allgemeinen stichprobenartige)
Ausführung eines Testobjekts verstanden, die der Überprüfung des Testobjekts dient.
Die Randbedingungen für die Ausführung der Tests müssen festgelegt sein. Ein
Vergleich zwischen Soll- und Istverhalten des Testobjekts dient zur Bestimmung,
ob das Testobjekt die geforderten Eigenschaften erfüllt.“
[SL05, S. 8-9]
Als Ziele beim Testen führen Spillner und Linz den Nachweis von Fehlern, die Bestimmung von
Qualität, das Erhöhen des Vertrauens in das Programm und die Vorbeugung von Fehlern an.
Durch das Testen einer Anwendung kann im Allgemeinen nur die Abwesenheit von bestimmten
Fehlern, nicht aber die Fehlerfreiheit nachgewiesen werden [SL05, S. 10].
Man unterscheidet verschiedene Testarten, die auf verschiedenen Abstraktionsebenen testen.
Komponententests und Akzeptanztests sind für diese Arbeit relevant und werden im Folgenden
definiert.
2.1.1.1 Komponententests
Die Definition für Komponententests wurde von Spillner und Linz übernommen.
Definition 2.1.1 (Komponententest):
Der Komponententest prüft, ob jeder einzelne Softwarebaustein (Komponente) für
sich die Vorgaben seiner Spezifikation erfüllt.
[SL05, S. 41]
2.1 Konzepte
4
Komponententests machen das Testen einer Anwendung beherrschbar, weil der Fokus auf kleinen Programmteilen liegt, die unabhängig voneinander getestet werden. Sie erleichtern das Finden und Beheben von Fehlern, da der auftretende Fehler einer Komponente zugeordnet werden
kann. Außerdem ermöglichen sie durch ihre Unabhängigkeit das parallele Ausführen von Testfällen [Mye04, S. 91].
Komponententests können als Black-Box- oder White-Box-Tests ausgelegt sein. Für Black-BoxTests ist kein Wissen über die internen Vorgänge des Testobjekts nötig. Die Testfälle werden aus
den Spezifikationen abgeleitet [SL05, S. 109]. White-Box-Tests gehen auf den genauen Quelltext des Testobjekts ein, um z. B. Fehlerfälle zu testen [SL05, S. 108].
2.1.1.2 Akzeptanztests
Die Definition für Akzeptanztests wurde von Johannes Link übernommen.
Definition 2.1.2 (Akzeptanztest):
Akzeptanztests spezifizieren (. . . ) Funktionalität des Gesamtsystems aus Sicht der
Anwender.
[Lin05, S. 10]
Die Akzeptanztests können als Maß für den Projektfortschritt verwendet werden, indem die
Implementierung von gewünschten Funktionen überprüft wird. Eine Möglichkeit diese Tests
durchzuführen, ist Eingaben eines Benutzers zu simulieren und die Ausgabe des Programms zu
verifizieren.
2.1.1.3 Testbarkeit
Aus dem Standard 610.12-1990 der IEEE wurde die Definition von Testbarkeit übernommen.
Definition 2.1.3 (Testbarkeit):
Testbarkeit: Das Maß, um dass ein System oder eine Komponente die Festlegung
von Testkriterien unterstützt und die Performanz von Tests zur Feststellung, ob
diese Testkriterien erfüllt wurden.
[IEE90, S. 76]
Sowohl die Möglichkeit Tests zu formulieren, als auch die Geschwindigkeit, mit der die Tests
ausgeführt werden können, spielen eine Rolle. Beide Faktoren können durch die Verwendung
von Werkzeugen und Test-Rahmenwerken beeinflusst werden.
2.1.2 Entwicklungskomplexität
In der Literatur gibt es keine gängige Definition für den Begriff Entwicklungskomplexität.
„Menschen müssen sich anstrengen, um Software zu entwerfen, zu verstehen und
zu implementieren.“
[Lil08, S. 6]
2.1 Konzepte
5
Angelehnt an diese Aussage von Carola Lilienthal, wird der Begriff für diese Arbeit selbst definiert.
Definition 2.1.4 (Entwicklungskomplexität):
Der Begriff der Entwicklungskomplexität ist ein Sammelbegriff für die Anstrengungen, die ein Entwickler bewältigen muss, um eine Anwendung zu entwerfen,
zu verstehen und zu implementieren. Alle verfügbaren Entlastungen wirken positiv
auf die Entwicklungskomplexität ein.
Zu den Anstrengungen, die bewältigt werden müssen, zählt. . .
• . . . die Komplexität der fachlichen Anforderungen. Der Ausschnitt der realen Welt, der
durch das System unterstützt werden soll, hat eine eigene Komplexität. Sie muss von
einem Entwickler zumindestens teilweise verstanden werden, um an dem System arbeiten
zu können.
• . . . die Größe des Systems. Sie kann über die Anzahl der Quelltextzeilen abgeschätzt werden.
• . . . die Anzahl der eingesetzten Technologien, ihr Heterogenität und Komplexität. Je mehr
Technologien eingesetzt werden, die sich in der Benutzung unterscheiden, desto Größer
ist die Belastung für einen Entwickler.
• . . . die Anzahl der eingesetzten Entwicklungssprachen und ihre Komplexität. Jede Sprache
muss beherrscht werden, damit das System und die inneren Vorgänge verstanden und
verändert werden können.
• . . . die Anzahl der notwendigen Konfigurationsdateien, ihre Größe und Komplexität. Wenn
eine Konfiguration angepasst werden soll, muss der Entwickler wissen, welche Einstellung welchen Aspekt des Systems verändert.
• . . . die Anzahl der Subsysteme und ihre Abhängigkeiten.
Bei der Bewältigung der Anstrengungen kann der Entwickler unterstützt werden. Diese Entlastung kann in Form von Werkzeugen, Vorgehensmodellen, angebotenen Abstraktionen, Modularisierung, Dokumentation, u. a. erfolgen.
Werkzeugunterstützung kann auch entlasten, wenn sie nur für ein Teil des Systems verfügbar ist.
Der Großteil der Werkzeugunterstützung wird von der Entwicklungsumgebung zur Verfügung
gestellt. Syntax-Hervorhebung, automatische Quelltextformatierung und Autovervollständigung
sind nur einige Beispiele aus dieser Kategorie.
Vorgehensweisen und die damit verbundenen Techniken können viele Arbeitsschritte vereinfachen oder den Entwicklungsprozess positiv beeinflussen. Paarprogrammierung und Refactorings
sind Techniken, die einzelne Entwickler entlasten können.
Eine Abstraktion des Systems kann das Verständnis erleichtern und effiziente Kommunikation
ermöglichen. Eine Architekturbeschreibung und Entwurfsmuster sind solche Abstraktionen.
2.1 Konzepte
6
Ein in Module aufgeteiltes System hat den Vorteil, dass ein Entwickler sich mit einem einzelnen
Modul befassen kann. Die Entwicklungskomplexität wäre dementsprechend geringer.
2.1.3 Software-Architektur
Eine Software-Architektur dient der Kommunikation [CKK02, S. 3]. Als Abstraktion vom System ermöglicht sie allen Beteiligten zu kommunizieren, obwohl diese unterschiedliche Sichten
auf das System haben. Außerdem kann sie als Schablone betrachtet werden, um über Analysen
oder Veränderungen zu sprechen.
Definition 2.1.5 (Software-Architektur):
Die Software-Architektur ist die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur
Umgebung, sowie Prinzipien, die den Entwurf und die Evolution des Systems
bestimmen.
[RH06, S. 1]
Eine Software-Architektur dokumentiert Designentscheidungen [CKK02, S. 11]. Designentscheidungen, die sich auf Komponenten und ihre Beziehungen auswirken, werden zu einem
Teil der Architektur.
Eine Architektur kann ein wiederverwendbares Modell sein [CKK02, S. 13]. Die gleiche Abstraktion lässt sich auch auf andere Systeme anwenden oder ein System lässt sich anhand der
vorgegeben Abstraktion entwickeln.
Definition 2.1.6 (Architekturbeschreibung):
Eine Architekturbeschreibung ist eine Menge von Modellen (also z. B. textuelle Spezifikationen oder grafische Diagramme wie die UML-Diagramme), die die
Software-Architektur dokumentieren.
[RH06, S. 36]
Eine Architekturbeschreibung fasst alle vorhandenen Informationen (Modelle) über die Architektur eines Systems zusammen. Wenn eine Abbildung verwendet wird, um eine Architektur zu
visualisieren, ist es in der Regel ein Modell das visualisiert wird (Sicht) und nicht die vollständige Architekturbeschreibung.
Auch ein System, dessen Architektur nicht durch Modelle erfasst wird, hat eine Architektur.
Vorhandene Modelle entsprechen nicht immer dem tatsächlichen System. Aus diesem Grund
unterscheidet man zwischen der Ist- und der Soll-Architektur [Lil08, S. 39]. Die Ist-Architektur
ist die tatsächliche Architektur des Systems. Sie kann durch Analysen festgestellt und beschrieben werden. Die Soll-Architektur ist die gewünschte Architektur des Systems. Sie liegt in Form
einer Architekturbeschreibung vor. Unterschiede zur Ist-Architektur können ermittelt werden.
Sie werden als Architekturverletzungen bezeichnet [Lil08, S. 64].
2.1 Konzepte
7
Definition 2.1.7 (Architekturstil):
Ein Architekturstil legt Arten von Architekturelementen fest und gibt Architekturregeln an, die die Schnittstellen und Beziehungen der Architekturelemente
einschränken.
[Lil08, S. 29]
Beispiele für Architekturstile sind Pipes & Filters, Schichtenarchitektur und Subsystemarchitektur, nachzulesen in Buschmann [BL00] und Lilienthal [Lil08]. In einer Schichtenarchitektur
sind Komponenten Schichten zugeordnet [BCK98, S. 100]. Jede Schicht hat nur Beziehungen zu
unterliegenden Schichten. Wenn Beziehungen ausschließlich zur benachbarten Schicht erlaubt
sind, spricht man von einer strengen oder strikten Schichtenarchitektur [Lil08, S. 30].
2.1.4 Entwicklungssprache
Entwicklungssprache ist der Oberbegriff für technische Sprachen, die bei der Entwicklung eines Softwaresystems zum Einsatz kommen. In dieser Arbeit werden zwei Arten von Entwicklungssprachen unterschieden: Programmiersprache und Auszeichnungssprache. Eine Programmiersprache dient zur Beschreibung von Datenverarbeitungsstrukturen und -prozessen auf einer
Maschine [Obe90].
Definition 2.1.8 (Programmiersprache):
Eine Programmiersprache ist ein notationelles System zur Beschreibung von Berechnungen in Maschinen und Menschen lesbarer Form.
[Lou94, S. 3]
Für diese Arbeit relevante Beispiele für Programmiersprachen sind Java [GJSB05] und JavaScript [FF02].
Definition 2.1.9 (Auszeichnungssprache):
Eine Auszeichnungssprache (engl. Markup Language) beschreibt neben Daten
auch ihre Eigenschaften und Verarbeitungsinformationen.
Für diese Arbeit relevante Beispiele für Auszeichnungssprachen sind Extensible Markup Language (XML)[HM02], HyperText Markup Language (HTML)[MN05], Cascading Style Sheets
(CSS)[Sch04a] und Java Server Pages (JSP)[TSL04]. TEX ist ebenfalls eine Auszeichnungssprache, aber für diese Arbeit nur indirekt relevant.
Folgendes kann als Abgrenzung der beiden Spracharten dienen. Auszeichnungssprachen beschreiben Struktur, Programmiersprachen beschreiben Anweisungen.
2.1 Konzepte
8
2.1.5 Fachlogik
Für den Begriff Fachlogik gibt es in der Informatik viele Synonyme. Geschäftslogik, Anwendungslogik, Business-Logic, Domain-Logic und funktionale Logik sind bekannte Vertreter. Sie
alle beschreiben den Teil einer Anwendung, der durch die Aufgabenstellung selbst motiviert ist
und nichts mit der technischen Implementierung zu tun hat [DEF+ 08, S. 45].
2.1.6 Entwurfsmuster
Das Konzept von Entwurfsmustern wurden maßgeblich von Gamma et al. geprägt [GHJV94].
Sie dienen als Lösungsschablone für wiederkehrende Entwurfsprobleme in der Softwareentwicklung und sollen die Wiederverwendung von erfolgreichen Entwürfen erleichtern.
Definition 2.1.10 (Entwurfsmuster):
Ein Entwurfsmuster benennt, abstrahiert und identifiziert die relevanten Aspekte einer allgemeinen Entwurfsstruktur. (. . . ) Das Entwurfsmuster identifiziert die
teilnehmenden Klassen und Objekte, die Rollen, die sie spielen, die Interaktion
zwischen den Rollen und die ihnen zugeteilten Aufgaben.
[GHJV09, S. 4]
2.1.7 Vorgehensmodell
Die Definition eines Vorgehensmodells wurde von Helmut Balzert übernommen.
Definition 2.1.11 (Vorgehensmodell):
Jede Software-Entwicklung soll in einem festgelegten organisatorischen Rahmen
erfolgen. Ein Prozess-Modell – auch Vorgehensmodell genannt – beschreibt einen
solchen Rahmen. In ihm wird festgelegt, welche Aktivitäten in welcher Reihenfolge
von welchen Personen erledigt werden und welche Ergebnisse (. . . ) dabei entstehen und wie diese in der Qualitätssicherung überprüft werden.
[Bal00, S. 54]
Einige der Vorgehensmodelle, die großen Einfluss auf die heutige Auffassung von Softwareentwicklung hatten, sind das Wasserfallmodell [Roy87], das V-Modell [Ver00, S. 32-38], der
Rational Unified Process [Kru03] und Extreme Programming [BA04].
2.1.8 Refactoring
Die interne Struktur eines Softwaresystems zu verändern ist eine Aktivität, die in verschiedenen
Vorgehensmodellen auftritt. Eine strukturierte Umsetzung dieser Aktivität bietet das Refactoring.
2.2 Technologien
9
Definition 2.1.12 (Refactoring):
Ein Refactoring ist eine Änderung an der internen Struktur einer Software, um sie
[die Struktur] leichter verständlich zu machen und einfacher zu verändern, ohne
ihr [der Software] beobachtbares Verhalten zu ändern.
[Fow00, S. 41]
2.2 Technologien
Neben Konzepten sind konkrete Technologien im Fokus dieser Arbeit. Die Servlet-Technologie
und die damit verbundenen Technologien Java Server Pages, Tag-Bibliotheken und Cascading
Style Sheets, genauso wie die Rahmenwerke Hibernate und Spring.
2.2.1 Servlet
Die Servlet-Technologie ist Teil der Java 2 Platform Enterprise Edition (J2EE) und dient der
Entwicklung von Web-Anwendungen. Sie stellt eine Programmierschnittstelle bereit und verbirgt technische Details (Abstraktion). Sie arbeitet auf Basis des Hypertext Transfer Protocols
(HTTP) und erlaubt es der Anwendung auf HTTP-Anfragen zu reagieren, HTTP-Antworten zu
senden und mit dem Servlet-Container zu interagieren, indem sie eine Servlet-Klasse (Servlet)
implementiert [TSL04, S. 23-25].
2.2.1.1 Java Server Pages
Die Java-Server-Pages-Technologie (JSP-Technologie) stellt eine andere Sicht auf Servlets dar.
In einem Dokument wird der Inhalt einer HTML-Seite in spezieller Syntax formuliert (die verwendete Auszeichnungssprache heißt ebenfalls JSP). Aus diesem Dokument wird ein Servlet
generiert, das bei Ausführung die gewünschte HTML-Seite ausliefert. Bei der Formulierung
von JSP-Dokumenten können neben HTML-Syntax auch verschiedene JSP-Elemente, Direktiven, Aktionen und Skripte, verwendet werden. Direktiven dienen zur Übermittlung von Informationen an den JSP-Compiler. Aktionen greifen auf Funktionen zu, die im Servlet-Container
implementiert sind. Skripte erlauben es Java-Quelltext in die JSP einzubauen.[TSL04, S. 26-32]
2.2.1.2 Tag-Bibliotheken
Über eine Direktive können Tag-Bibliotheken in JSP-Dokumenten verfügbar gemacht werden.
Diese Tag-Bibliotheken stellen neue Funktionalität bereit, die in HTML-ähnlicher Syntax verwendet werden kann. Sie unterstützen das Bestreben, auf Skripte in JSP-Dokumenten zu verzichten, so dass die JSP-Dokumente von Web-Designern bearbeitet werden können und nicht
nur von Programmieren [TSL04, S. 32].
2.2 Technologien
10
2.2.2 Cascading Style Sheets
Cascading Style Sheets (CSS) ist ein einfaches, standardisiertes System zur Konfiguration des
Designs einer Internet-Seite [Sch04a, S. xi]. In einer CSS-Datei wird festgelegt, wie ein Bereich
dargestellt werden soll, der durch einen Bezeichner (Klasse) im Quelltext der Internet-Seite gekennzeichnet ist. So wird der Inhalt von der grafischen Gestaltung getrennt. Das Anpassen oder
Verändern des Designs einer Internet-Seite kann einfach durch die Verwendung einer anderen
CSS-Datei erreicht werden.
2.2.3 Hibernate
Moderne Programmiersprachen wie Java haben eine objektorientierte Sicht auf Geschäftsdaten,
die Geschäftsdaten selbst sind aber von relationaler Natur [BK05, S. xi]. Um die Lücke zwischen
relational und objektorientiert zu schließen, kann man objektrelationale Mapper (OR-Mapper)
einsetzen. Hibernate ist ein solcher OR-Mapper für Java.
Hibernate kann von der konkret eingesetzten Datenbank abstrahieren, indem die Datenbankanfragen in Hibernate Query Language (HQL) oder über Criteria-Objekte formuliert werden.
2.2.3.1 Mapping
Die Abbildung von Objekten und ihren Beziehungen auf Relationen in der Datenbank erfolgt
durch das Hibernate-Mapping. Diese Metadaten enthalten Informationen über die Abbildung
von Klassen auf Tabellen, Eigenschaften auf Spalten, Abhängigkeiten auf Fremdschlüssel und
Java-Typen auf SQL-Typen [BK05, S. 75] .
2.2.4 Spring
Das Spring-Rahmenwerk soll das Entwickeln von Java-Anwendungen vereinfachen und gute
Programmierpraktiken fördern. Es bietet zahlreiche Module, die einzeln verwendet werden können und integriert vorhandene Rahmenwerke, wie z. B. Hibernate. Spring ist eine leichtgewichtige Alternative zu den in J2EE vorhandenen Komponenten [ZLMG08, S. 19].
2.2.4.1 Dependency Injection
Ein zentrales Modul von Spring ist der Dependency-Injection-Mechanismus (DI-Mechanismus).
Zeitner et al. beschreiben diesen Mechanismus folgendermaßen:
„Durch DI werden den Objekten von einer unabhängigen dritten Partei Serviceobjekte zugewiesen, ohne dass die Objekte wissen (oder wissen müssen), welche Serviceobjekte sie tatsächlich bekommen. Die Objekte kennen nur die Schnittstelle,
wie diese Services angesprochen werden müssen. Welcher Service das tatsächlich
ist, entzieht sich ihrer Kenntnis.“
[ZLMG08, S. 37]
2.3 CommSy
11
2.3 CommSy
Das CommSy ist ein webbasiertes System zur Unterstützung vernetzter Projektarbeit. Es ist
Open-Source-Software und wurde 1999 an der Universität Hamburg am Fachbereich Informatik
ins Leben gerufen. CommSy steht für Community System und wird unter dem Grundsatz entwickelt, dass Wissen dadurch entsteht, dass sich Menschen gemeinschaftlich mit ihrer Wirklichkeit
auseinandersetzen, um sie zu begreifen und zu verändern [BKOP02, S. 7].
Ein CommSy-Portal ist in Räume aufgeteilt, die der Kommunikation und Koordination kleiner
geschlossener Gruppen dienen. Um Zugang zu einem Raum zu erlangen, muss eine Mitgliedschaft beantragt werden. In einem Raum können u. a. Ankündigungen gemacht, Termine festgehalten, Materialien gesammelt und Diskussionen geführt werden. Die einzelnen Aktivitäten
sind entsprechenden Rubriken zugeordnet [CT08].
2.3.1 JCommSy
Das CommSy ist in der Skriptsprache PHP implementiert worden. PHP ist einfach zu erlernen
und bietet zahlreiche Bibliotheken, die besonders für Web-Entwickler interessant sind [Jee05].
Was Skriptsprachen fehlt, sind Strukturierungsmöglichkeiten innerhalb des Quelltexts und ein
strenges Typkonzept. Diese Nachteile führen u. a. zu schlechter Wartbarkeit bei großen Systemen [Jee05].
Um diese Nachteile im ständig wachsenden CommSy nicht zu haben, wurde eine Migration
von PHP nach Java angestoßen. Java ist eine objektorientierte Programmiersprache, die sowohl
Strukturierungsmöglichkeiten, als auch Typisierung bietet.
Die Umstellung erfolgt schrittweise und vertikal, d. h. es wird eine Rubrik nach der anderen, von
der untersten bis zur obersten Schicht, in Java implementiert [Jee05]. Noch nicht implementierte
Rubriken und Funktionen werden an das PHP-CommSy weitergeleitet.
In dieser Arbeit wird das CommSy unter verschiedenen Namen aufgeführt. CommSy wird verwendet, wenn das Konzept der Anwendung gemeint ist, PHP-CommSy, wenn die Implementierung in PHP gemeint ist und JCommSy wenn die Implementierung in Java gemeint ist.
2.4 Zusammenfassung
Die Konzepte Testen, Entwicklungskomplexität, Software-Architektur, Fachlogik, Entwurfsmuster, Entwicklungssprache, Vorgehensmodell und Refactoring wurden vorgestellt. Dabei wurden Definitionen für Komponententest, Akzeptanztest, Testbarkeit, Entwicklungskomplexität,
Software-Architektur, Architekturbeschreibung, Architekturstil, Entwurfsmuster, Vorgehensmodell, Programmiersprache, Auszeichnungssprache und Refactoring gegeben.
Danach wurden die wichtigen Technologien Servlet, CSS, Hibernate und Spring, genauso wie
der Untersuchungsgegenstand CommSy eingeführt.
Kapitel 3 Architektur des JCommSy
12
Kapitel 3
Architektur des JCommSy
Mit der Architektur des JCommSy haben sich bereits andere Diplomarbeiten befasst. Die zuletzt
abgeschlossene ist die von Henning Schwentner [Sch08]. Zwischen jener Arbeit und dem Beginn dieser Arbeit fanden keine größeren Änderungen am JCommSy statt. Trotzdem entsprach
die Architekturbeschreibung nicht genau dem Ist-Zustand des Systems. Einige Systemteile wurden nicht betrachtet und Verletzungen toleriert.
Um die kommenden Veränderungen an der Architektur besser feststellen und bewerten zu können, sollte zunächst eine überarbeitete Architekturbeschreibung erstellt werden. Zusammen mit
zwei anderen Diplomanden (Ilker Daricili [Dar09] und Salim Rechenberg [Rec09]) habe ich
eine Schichtung gesucht, die das aktuelle System möglichst gut widerspiegelt. Zuständigkeiten
sollten in Schichten gekapselt und die Abhängigkeiten zu anderen Schichten minimiert werden. Außerdem sollte die Java-Package-Struktur1 der Anwendung die Architekturbeschreibung
abbilden.
3.1 Architekturmodell
Servlets
Ausstatter
Fragmente
Services
Items
Fachwerte
(a) Original
(b) Auffassung als Schichtenarchitektur
Abbildung 3.1: Architektur des JCommSy nach Schwentner [Sch08, S. 57]
1 Java-Packages
werden im Folgenden als Packages bezeichnet
3.2 Überarbeitetes Architekturmodell
13
Das Wissen über die Architektur eines Systems wird in einer Architekturbeschreibung zusammengefasst. Henning Schwentner hat dies im Rahmen seiner Diplomarbeit [Sch08] für das
JCommSy getan. Zentraler Bestandteil seiner Architekturbeschreibung ist das in Abbildung
3.1(a) auf Seite 12 gezeigte Architekturmodell. Er sagt ebenfalls aus, dass sich dieses Modell
als Schichtenarchitektur auffassen lässt. Zur Verdeutlichung habe ich dies einmal explizit getan,
siehe Abbildung 3.1(b) auf Seite 12. In beiden Abbildungen stehen die Pfeile für Abhängigkeiten zwischen Systemteilen.
Wenn man das JCommSy genauer betrachtet, bzw. daran entwickelt, fällt auf, dass einige Aspekte des Systems nicht in dem Modell auftauchen. Die JSPs zur Erstellung der Oberfläche finden
keine Beachtung, obwohl sie eine wichtige Rolle für das JCommSy spielen. Wahrscheinlich ist
dies darin begründet, dass das zur Architekturanalyse verwendete Werkzeug (Sotoarc2 ) nur die
in Java beschriebenen Systemteile betrachten kann. Ein weiterer Punkt ist das Ausblenden der
zahlreichen Hilfsfunktionen (Utilities), die von überall aus dem System zugegriffen werden. Sie
sind in den dargestellten Schichten verborgen, ohne die durch sie entstehenden Abhängigkeiten
zu berücksichtigen.
Dies führt zu der Frage, ob es sich um ein Modell der Soll- oder Ist-Architektur handelt. Wenn
man davon ausgeht, dass die abgebildeten Abhängigkeiten vollständig sind, muss es sich um
eine Soll-Architektur handeln. Der Systemzustand wich in einigen Punkten vom Modell ab.
Diese Verletzungen wurden bei einer Untersuchung mit dem Sotoarc-Werkzeug deutlich. Die
Architekturbeschreibung lässt sich nicht vollständig im Quelltext wiederfinden, was z. B. durch
Zuordnung zu Packages möglich wäre.
Was in diesem Modell aber deutlich wird, ist die Kapselung von Technologien in einzelnen
Schichten. In der Servletschicht wird eben genau diese Technologie konzentriert. Die Benutzung von Hibernate wird in der Serviceschicht verborgen.
Ausgehend von der Motivation Henning Schwenters, die enge Kopplung des JCommSy an das
Servlet-Rahmenwerk zu beseitigen, ist dies also eine treffende Architekturbeschreibung. Für
meine Arbeit benötige ich aber eine allgemeinere Architekturbeschreibung und ein entsprechendes Architekturmodell. Sie soll sich an Zuständigkeiten von Systemteilen orientieren und möglichst genau das System widerspiegeln, ohne Aspekte auszublenden.
3.2 Überarbeitetes Architekturmodell
Die Überarbeitung der Architekturbeschreibung habe ich zusammen mit Ilker Daricili und Salim
Rechenberg durchgeführt. Beide schreiben ebenfalls eine Diplomarbeit, die sich mit der Architektur des JCommSy befasst.
Der erste Schritt bei der Überarbeitung war eine Analyse mit dem Sotoarc-Werkzeug. Die
Abhängigkeiten der einzelnen Systemkomponenten können dort bis auf Methodenaufrufe und
Variablen-Typen genau betrachtet werden. Ausgehend von der Systemstruktur (Packages) haben
wir einzelne Systemteile (Klassen und Packages) Schichten zugeordnet. Die Schichten selbst
2 http://www.hello2morrow.com/products/sotoarc
3.2 Überarbeitetes Architekturmodell
Schichtenarchitektur des
JCommSy
14
Präsentationsschicht (detailliert)
servlet
jsp, tag
outfitter
fragment
Technologie
presentation
util
logic
Struktur
service
Serviceschicht (detailliert)
item
api
Schnittstelle
impl
Implementierung
domainvalue
Abbildung 3.2: Überarbeitete Architektur des JCommSy
und auch die Zuordnung sind durch Zuständigkeiten motiviert. Tiefe Zugriffe, über Schichten
hinweg, sollten vermieden werden, stellen aber keine Architekturverletzung dar.
presentation
Die Präsentationsschicht soll alles enthalten, was mit der Erzeugung der eigentlichen Benutzungsoberfläche und deren Interaktion zu tun hat. Angefangen mit den JSP-Dateien
und Tag-Bibliotheken über das Servlet-Rahmenwerk bis zu den Ausstattern und Fragmenten. Fragmente sind Java-Klassen, die Daten für einzelne Anzeigeelemente enthalten. Die
Ausstatter befüllen diese Fragmente mit den benötigten Daten. Für die genannten Subsysteme haben wir die erlaubten Abhängigkeiten noch einmal explizit formuliert (Pfeile in
Abbildung 3.2 auf Seite 14).
logic
In der Logikschicht sollen die Systemelemente gesammelt werden, die die Fachlogik der
Anwendung implementieren. Bei der Analyse konnten wir keine Klassen ausmachen, die
diesen dedizierten Zweck hatten.
service
Dienste sollen in dieser Schicht bereitgestellt werden, beispielsweise das Verwalten von
Elementen. Als Besonderheit soll hier darauf geachtet werden, eine strikte Trennung von
Schnittstelle (api-Package) und Implementierung (impl-Package) zu gewährleisten. Alle zur Schnittstelle der Schicht gehörenden Klassen und Interfaces3 sollen in einem Sub3 Interface:
Vollständig abstrakte Klasse, die sowohl einen Typ, als auch eine Schnittstelle definiert.
3.2 Überarbeitetes Architekturmodell
15
system vereint werden. Zugriffe auf dieses Subsystem sind von höherliegenden Schichten erlaubt. Die implementierenden Klassen gehören in ein anderes Subsystem, das ausschließlich vom api-Package aufgerufen werden darf (siehe Serviceschicht-Ausschnitt in
Abbildung 3.2 auf Seite 14).
item
Alle Elemente (fachlich motivierte Klassen), die im JCommSy Verwendung finden, sollen
aus dieser Schicht stammen. Ankündigung und Raum sind typische Vertreter.
domainvalue
Fachwerte gehören in die unterste Schicht. Sie repräsentieren fachlich motivierte Klassen,
für die Wert-Semantik4 gilt z. B. Status-Klassen oder ID-Klassen.
util
Hilfsfunktionen, die sich nicht genauer zuordnen lassen oder von verschiedenen Schichten aus zugänglich sein müssen, sollen in dieser Schicht gesammelt werden. Diese Lösung wurde gewählt, als ein Kompromiss zwischen redundantem Quelltext und Kapselung der einzelnen Schichten. Redundanten Quelltext würde man erhalten, wenn man die
Hilfsfunktionen in jeder Schicht bereitstellt, um keine Abhängigkeiten zu erhalten. Die
Kapselung würde man aufweichen, wenn Schichten auf Hilfsfunktionen anderer Schichten zugreifen, nur um keinen Quelltext zu duplizieren. Bei unserem Kompromiss ist der
Quelltext für die Hilfsfunktionen nur einmal zentral vorhanden und es enstehen nur Abhängigkeiten zu einem separaten Subsystem.
Ein Aspekt, der in diesem Architekturmodell keine Beachtung findet, ist der Migrations-Aspekt
des JCommSy. Alle Systemelemente, die sich mit der Migration von PHP zu Java befassen (siehe
Kapitel 2.3.1 auf Seite 11), sollen in einer Migrationsschicht (migration) gesammelt werden.
Diese Schicht wird obsolet, sobald die Migration abgeschlossen ist.
Die aufgeführten Schichten sollen sich im System als Packages wiederfinden, die Subsysteme
als Unter-Packages. Alle erlaubten Abhängigkeiten, auch die der Subsysteme, haben wir in einer
Architekturbeschreibung für das Sotoarc-Werkzeug festgehalten. Diese Kombination erlaubt es,
das System einfach in das Sotoarc-Werkzeug einzulesen und die Architektur zu überprüfen.
3.2.1 Refactorings
Das überarbeitete Architekturmodell war zwar nahe am eigentlichen System, zwischen Ist- und
Soll-Architektur gab es jedoch noch Differenzen.
Ein Großteil der Package-Struktur musste umgebaut werden, um die Architekturvorstellungen
widerzuspiegeln. Jede Schicht sollte ihr eigenes Package bekommen und jedes Subsystem ein
Unter-Package. Teilweise gab es diese Packages schon, aber sie waren an der falschen Stelle in
der Package-Hierarchie und teilweise stimmte der Inhalt nicht. Im Verlauf dieses Refactorings
wurde die Package-Hierarchie verändert und falsch einsortierte Klassen wurden verschoben.
Zu diesem Zeitpunkt konnte man im Sotoarc-Werkzeug erkennen, wo es noch Zugriffe bzw.
4 Für
weitere Informationen zu Wert-Semantik verweise ich auf MacLennan [Mac82].
3.3 Trennung von Fachlogik und Präsentation
16
Abhängigkeiten gab, die unsere überarbeitete Architekturvorstellung verletzten. Diese Verletzungen haben wir schrittweise beseitigt.
Die Entkopplung vom Servlet-Rahmenwerk aus der Diplomarbeit von Henning Schwentner
[Sch08] haben wir als Subsystem-Einteilung in der Präsentationsschicht wieder aufgenommen
und zulässige Abhängigkeiten definiert. Die Trennung von Schnittstelle und Implementierung
der Dienste haben wir explizit gemacht.
Nachdem wir diese Refactorings durchgeführt hatten, spiegelte die Package-Struktur die Schichtenarchitektur wider und es gab keine Verletzungen mehr. Ist- und Soll-Architektur stimmten
überein. Die Logikschicht blieb jedoch leer, denn bis zu dem Zeitpunkt gab es keine Klassen,
die ausschließlich oder überwiegend Fachlogik enthielten.
3.3 Trennung von Fachlogik und Präsentation
Eine leere Logikschicht hieß nicht, dass das JCommSy über keine Fachlogik verfügte, sondern
dass sie im System verteilt war.
Im Rahmen dieser Arbeit soll der Präsentationsquelltext ausgetauscht werden. Für Fachlogik,
die sich in diesem Quelltext befindet, heisst das, dass sie für die neue Oberfläche nicht mehr
zur Verfügung steht. Eine Neuimplementierung würde bedeuten, bereits erprobten Quelltext zu
verwerfen und Arbeitsaufwand doppelt aufzubringen. Es liegt also nahe, die Fachlogik zu identifizieren und von der Präsentation zu trennen, bevor der Austausch vorgenommen wird.
Zunächst muss man ermitteln, was die Fachlichkeit des CommSy ausmacht. Ohne dieses Wissen ist es schwer, Anzeigelogik von Fachlogik zu unterscheiden. Dann muss man die Logik im
System finden und in eigene Klassen verschieben.
Die Trennung von Fachlogik und Präsentation und alle Überlegungen hierzu habe ich zusammen
mit Salim Rechenberg durchgeführt.
3.3.1 Fachlogik des CommSy
Wie bereits erwähnt, müssen Überlegungen dazu angestellt werden, was die Fachlichkeit des
CommSy ausmacht. Die Dienste der service-Schicht zählen zur Fachlichkeit, da sie die Verwaltung der Elemente implementieren und deren Konsistenz sicherstellen. Das Speichern und
Bereitstellen von Elementen ist ein zentraler Bestandteil des CommSy. Die Dienste bieten eine
CRUD-Schnittstelle5 an, die als Basis für die übrige Fachlogik dient. Die Unterbringung in einer
eigenen Schicht ist dadurch ausreichend gerechtfertigt.
Die eigentliche Fachlogik setzt sich aus dem Erstellen, Verändern und Löschen von Einträgen
zusammen (Gruppen, Ankündigungen, Anmerkungen, etc.). Hinzu kommt die Validierung von
Inhalten, z. B. „Was ist ein gültiges Datum?“, „Was ist eine gültige Uhrzeit?“, aber auch „Welche
Eingabefelder müssen ausgefüllt sein?“. Die Verknüpfung von Elementen (Netznavigation) und
5 CRUD
= Create (Datensatz anlegen), Retrieve (Datensatz abfragen), Update (Datensatz aktualisieren), Delete
(Datensatz löschen)
3.3 Trennung von Fachlogik und Präsentation
17
das Verwalten von Statusinformationen (neu, gelesen, ungelesen) zählen ebenfalls zur Fachlogik. Genauso wie die Benutzerauthentifizierung und Verwaltung der Rechte einzelner Benutzer
(Wer darf was im System tun?).
Dies ist keine vollständige Auflistung der Fachlogik, es spiegelt lediglich den Stand unserer
Überlegungen zum Zeitpunkt des Refactorings wider. Darüber hinaus wird die Fachlogik des
CommSy ständig erweitert und eine vollständige Liste wäre nur von kurzer Gültigkeit.
Nachdem geklärt war, was gesucht wird, musste der entsprechende Quelltext isoliert werden.
3.3.2 Fachlogik in der Präsentationsschicht
Ausgehend von unserer Erfahrung mit dem System und mit dem Wissen was genau wir suchen,
haben wir schnell die entsprechenden Klassen gefunden. Ein Großteil der Fachlogik wurde durch
die Ausstatter-Klassen (Outfitter) abgewickelt. Sie haben Zustandsüberprüfungen gemacht
und Elemente verändert. Die eigentliche, namensgebende Aufgabe war jedoch das Ausstatten
der Fragmente mit den benötigten Daten für die Anzeige. Dies galt für alle Rubriken und deren
Ausstatter.
Damit war klar welche Quelltextteile für eine Wiederverwendung herausgezogen werden mussten. Ein Refactoring stand an.
3.3.3 Refactoring
Die Struktur des Systems sollte verändert werden, ohne das nach außen sichtbare Verhalten zu
verändern (siehe Fowler [Fow99]). Bevor so eine große Änderung gemacht wird, sollte man sich
ein paar Gedanken zum Vorgehen machen.
3.3.3.1 Planung
Zunächst muss geplant werden, welche Systemteile umstrukturiert werden sollen. Welche Klassen sind betroffen und wie genau soll die neue Struktur aussehen. Es muss aber auch geplant
werden, wie bei dem Refactoring vorgegangen wird. Wo fängt man an und in welchen Schritten
geht man vor.
Im Folgenden wird erläutert wie die neue Struktur im Detail aussehen sollte:
Für die aus den Ausstattern extrahierte Fachlogik brauchten wir eine angemessene Abstraktion,
die einzelne, fachliche Aktionen kapselt. Sie sollten benennbar und wiederverwendbar sein, ohne
zu Quelltextduplizierung zu führen. Wir haben dafür auf das bewährte Befehl-Entwurfsmuster
(Command-Pattern) nach Gamma et al. [GHJV94] zurückgegriffen. Jede fachliche Aktion wurde zu einem ausführbaren Befehlsobjekt. Für Gemeinsamkeiten konnten Oberklassen verwendet
werden. Die Validierung der Eingabewerte sollte in der Befehlsklasse stattfinden, genauso wie
sie festlegen sollte, was nach der Ausführung des Befehles passiert (z. B. Weiterleitung an eine
andere Seite des CommSy). Die Befehlsklasse sollte ebenfalls die Manipulation der Elemente
(erzeugen, verändern, löschen) übernehmen. Die dafür erforderlichen Eingaben vom Benutzer
sollte es von dem bereits im System integrierten Parameter-Objekt erhalten (ParamBean). Die
Befehlsklassen, die einen Eintrag (Gruppe, Ankündigung, . . . ) bearbeiten, sollten zusätzlich ein
3.3 Trennung von Fachlogik und Präsentation
18
Objekt bereitstellen, das temporäre, nicht persistierte Informationen enthält (ItemEditBean).
Ein Servlet (LogicServlet) sollte dafür sorgen, dass die benötigten Befehle zum richtigen
Zeitpunkt6 erzeugt und ausgeführt werden.
Da die Struktur des Oberflächenquelltexts hierfür verändert werden musste, haben wir uns dazu
entschlossen, einen weiteren Aspekt bei diesem Refactoring mit einzubeziehen. Die Zuständigkeiten der einzelnen Klassen sollten fokussiert werden. Um genau zu sein, sollte eine Klasse nur
eine Aufgabe übernehmen. Wir strebten nicht nur eine Trennung von Anzeigelogik und Fachlogik an, sondern auch eine Trennung nach Zuständigkeiten. Im Detail heißt das, jede JSP arbeitet
auf genau einem Fragment als Modell für die Anzeige. Für jedes Fragment gibt es genau einen
Ausstatter, der es mit Daten aus den Elementen und ItemEditBeans versorgt. Manipulationen
an den Elementen werden ausschließlich von den entsprechenden Befehlen vorgenommen. Diese sind auch dafür verantwortlich, ItemEditBeans für die Ausstatter zur Verfügung zu stellen.
Eine ItemEditBean ist an eine fachliche Aktion (Befehl) gekoppelt, alle betroffenen Ausstatter teilen sich diese Bean. Das Zusammenspiel der einzelnen Komponenten ist noch einmal in
Abbildung 3.3 auf Seite 19 dargestellt. Die Färbung der Komponenten ist nach ihrer Schichtenzugehörigkeit gewählt (siehe Abbildung 3.2 auf Seite 14).
Alle beteiligten Klassen haben klare Aufgaben, die sie wahrnehmen.
Nach der Beschreibung der Struktur folgt eine Beschreibung des Vorgehens:
Das LogicServlet sollte als erstes etabliert werden, um Befehle ausführen zu können. Danach
sollte ein Interface für Befehle formuliert werden. Dieses Interface sollte nach und nach um die
Implementierungen der einzelnen fachlichen Aktionen ergänzt werden. Hierfür sollte im Wesentlichen der Quelltext aus den Ausstattern in die neuen Befehle verschoben werden. Im gleichen Schritt sollten die Ausstatter im Sinne ihrer fokussierten Zuständigkeit aufgeräumt werden.
Gleiches galt für die JSPs.
Damit war der Plan fertig, es folgte die Ausführung.
3.3.3.2 Ausführung
Der erste Schritt bei einem Refactoring ist immer das Ausführen der vorhandenen Tests. Wenn
die semantisch nicht veränderten Tests vor und nach dem Refactoring erfolgreich sind hat man
es geschafft die Struktur ohne das nach außen sichtbare Verhalten zu verändern. Vorausgesetzt
die Anwendung ist vollständig durch Tests abgedeckt.
Das war auch unser Ziel für das JCommSy. Leider gab es beim JCommSy keine vollständige
Testabdeckung, also mussten wir sicherstellen, dass die erfolgreich durchlaufenden Tests auch
die vom Refactoring betroffenen Funktionalitäten abdeckten. Die Akzeptanztests hatten für die,
von uns als fachliche Aktionen (Fachlogik) identifizierte Funktionen, eine ausreichende Abdeckung. Die wesentlichen Funktionen wurden durch simulierte Oberflächeninteraktion aufgerufen
und auf korrektes Verhalten überprüft.
Wir haben mit einem Befehls-Typ angefangen (NewItemCommand) und ihn dann für alle Rubriken (Ankündigungen, Termine und Gruppen) implementiert. Dabei haben wir immer darauf
6 als
Reaktion auf eine bestimmte Benutzereingabe; an der richtigen Stelle im Kontrollfluss
3.3 Trennung von Fachlogik und Präsentation
JSP
ze
ig
tD
ate
n
an
Fragment
erzeugt
füllt mit Daten
Servlet
Befehl
füllt mit Daten
EditBean
holt Daten
Ausstatter
holt Daten
benutzt
Dienste
19
Material
Abbildung 3.3: Zusammenspiel der Systemkomponenten (Auswahl) beim Editieren eines Eintrags, Farben dienen der Zuordnung zu Schichten, siehe Abbildung 3.2 auf Seite
14.
geachtet, möglichst viel Funktionalität in einer Oberklasse zusammenzufassen, um in allen Rubriken davon profitieren zu können. Schnell sind wir dabei auf Probleme gestoßen, weil die Ausstatter mehrere Aufgaben übernommen hatten (Erzeugung und Aktualisierung von Elementen,
Erzeugung und Aktualisierung von EditBeans, Erzeugung und Aktualisierung von Fragmenten, Hochladen von Dateien, Verknüpfung zu anderen Elementen, Validierung von Benutzereingaben) und dies nicht ausreichend dokumentiert war. Um diesen Umstand zu verbessern, haben
wir die oben beschriebene Trennung nach Aufgaben durchgeführt. Als Nebeneffekt hatten wir
über längere Zeiträume nicht kompilierfähigen Quelltext. An sich einfache Änderungen haben
viele Änderungen in anderen Klassen nach sich gezogen, die notwendig waren, um das System
wieder in einen konsistenten Zustand zu bringen .
Analog zu den Veränderungen am produktiven Quelltext, mussten auch die vorhandenen Tests
angepasst und gegebenenfalls neue Tests geschrieben werden.
Am Ende hatten wir drei Arten von Befehlen für jede Rubrik (bearbeiten, speichern, erstellen), einige spezielle (Gruppe beitreten/verlassen, Datei hochladen) und zwei generische Befehle (rubrikübergreifend: abbrechen, löschen).
Mit diesem Refactoring haben wir alles erreicht, was wir erreichen wollten.
3.4 Zusammenfassung
20
3.3.3.3 Ausblick
Der Grundstein für eine strukturierte Logikschicht ist gelegt. Darauf aufbauend sind noch weitere Arbeiten möglich. Weitere Aspekte der Fachlichkeit des CommSy könnten betrachtet und
in die Logikschicht integriert werden.
Die im Zuge der Migration von PHP nach Java noch umzustellenden Rubriken können leicht mit
Befehlen versehen werden. Abstrakte Oberklassen und generische Befehle halten den Arbeitsaufwand gering.
3.4 Zusammenfassung
Dieses Kapitel hat einen Überblick über die Architektur des JCommSy gegeben und Maßnahmen erläutert, die als Vorbereitung für die Diplomarbeit dienten.
Die Architekturbeschreibung für das JCommSy wurde angepasst, um Schichten zu erhalten, die
durch Zuständigkeiten definiert werden. Beschreibung und System wurden in Einklang gebracht,
indem alle Verletzungen beseitigt wurden. Bei der Anpassung wurden zwei Konzepte berücksichtigt, Kapselung von Technologie und Trennung von Schnittstelle und Implementierung.
Es wurde ein expliziter Systemteil herausgearbeitet, der die Fachlichkeit des JCommSy kapselt.
Er wurde in das bestehende System und seine Konzepte integriert. Die Struktur der Präsentationsschicht wurde durch klare, fokussierte Zuständigkeiten vereinfacht. Der PräsentationsQuelltext wurde isoliert und somit austauschbar gemacht.
Ein sauberer Ausgangspunkt für diese Diplomarbeit wurde geschaffen.
Kapitel 4 Eine neue Oberflächentechnologie
21
Kapitel 4
Eine neue Oberächentechnologie
Im Rahmen dieser Diplomarbeit sollen verschiedene softwaretechnische Aspekte des JCommSy
verbessert werden. Dies soll durch einen Austausch der Oberflächentechnologie erreicht werden. Die neu eingeführte Technologie ist demnach von zentraler Bedeutung für diese Arbeit. In
diesem Kapitel wird beschrieben wie bei der Auswahl vorgegangen wurde und was für Eigenschaften der Technologien bzw. Rahmenwerke dabei eine Rolle spielten.
Zunächst wird die bisher im JCommSy eingesetzte Oberflächentechnologie beschrieben. Danach wird eine Liste verfügbarer Rahmenwerke aufgestellt und der Auswahlprozess erläutert.
Am Ende steht eine fundierte Entscheidung für ein konkretes Rahmenwerk.
4.1 Bisherige Oberächentechnologie
Alle für einen Austausch in Frage kommenden Technologien müssen die Aufgabe der bisher
eingesetzten Technologie übernehmen. Aus diesem Grund wird kurz erläutert, welche Technologie bisher zum Einsatz kommt und wie sie funktioniert.
Die Erzeugung der Benutzungsoberfläche erfolgt beim JCommSy durch JSP-Technologie (siehe Kapitel 2.2.1.1 auf Seite 9). Die einzelnen Seiten der Web-Anwendung werden in JSPDokumenten beschrieben. Diese Dokumente werden zu Servlets (siehe Kapitel 2.2.1 auf Seite
9) kompiliert, die wiederum eine HTML-Seite erzeugen. Das Ergebnis wird in einem Browser1
angezeigt.
4.1.1 JSP-Dokumente
Die JSP-Dokumente des JCommSy sind modular aufgebaut. Jedes Oberflächenelement wird in
einem eigenen JSP-Dokument beschrieben und eine Seite wird aus einer Kombination dieser
Elemente zusammengefügt. Ein Element kann andere Elemente enthalten. In Abbildung 4.1 auf
Seite 22 ist eine Auszug des JCommSy zu sehen, bei dem die einzelnen Oberflächenelemente
durch schwarze Ränder hervorgehoben sind. Diese Struktur hat den Vorteil, dass die einzelnen
Elemente wiederverwendet werden können. Die JSP-Dokumente sind beherrschbar und wartbar,
im Gegensatz zu großen Dokumenten, die eine ganze Seite beschreiben.
Für die JSP-Dokumente des JCommSy gibt es eine Konvention, die vorschreibt, so wenig Programmlogik wie möglich, in den JSP-Dokumenten zu formulieren2 . Es ist zwar möglich beliebige Programmlogik innerhalb der JSP-Dokumente zu implementieren, dieser Quelltext ist jedoch
nur schwer zu testen. Auf die Testbarkeit von JSP-Dokumenten wird in Kapitel 6.1.1 auf Seite
52 genauer eingegangen.
1 Anwendung
2 JSPs
zum Betrachten von Internetseiten.
sollen sich auf die Darstellung von Daten beschränken, weil sie keine testbare Schnittstelle haben.
4.1 Bisherige Oberflächentechnologie
22
Abbildung 4.1: Das JCommSy mit aktivierten Rahmen um jedes Oberflächenelement.
Tag-Bibliotheken
CommSy-spezifische Funktionen (z. B. Zugriff auf Programmeinstellungen), die in den JSPDokumenten benötigt werden, werden in Tag-Bibliotheken (Tag-Libraries, siehe Kapitel 2.2.1.2
auf Seite 9) realisiert. Diese Programmlogik befindet sich in Java-Klassen und kann somit gut
getestet werden.
4.1.2 Fragmente und Ausstatter
Fragmente und Ausstatter sind Teil der Präsentationsschicht. Sie stellen Informationen in einer
Baumstruktur zur Verfügung, die auf die JSP-Dokumente und deren Modularität zugeschnitten
ist.
Dieser Teil der Präsentationsschicht (siehe Abbildung 4.2 auf Seite 23, Struktur) ist unabhängig
4.2 Verfügbare Oberflächentechnologien
23
von der Oberflächentechnologie (JSP/Servlet) und könnte von einer neuen Oberflächentechnologie wiederverwendet werden.
Präsentationsschicht (detailliert)
servlet
jsp, tag
outfitter
fragment
Technologie
Struktur
Abbildung 4.2: Präsentationsschicht des JCommSy
4.2 Verfügbare Oberächentechnologien
Im Folgenden wird beschrieben, was für Rahmenwerke (Oberflächentechnologien) als Alternativen zur Verfügung standen und nach welchen Kriterien ein konkretes Rahmenwerk ausgewählt
wurde.
Es gibt viele Java-Rahmenwerke zum Erstellen von Web-Anwendungen, sie werden auch JavaWeb-Frameworks genannt. Eine umfassende Liste zu erstellen und die verschiedenen Eigenschaften gegeneinander abzuwägen liegt außerhalb des Rahmens dieser Diplomarbeit. Ohne eine umfassende Liste findet man nicht zwangsläufig das am Besten geeignete Rahmenwerk, es ist
jedoch möglich ein passendes Rahmenwerk zu finden, wenn man eine Liste mit angemessenem
Umfang erstellt.
Angemessen heißt für diese Arbeit, dass eine Liste von populären und verbreiteten Rahmenwerken erstellt wurde. Die meisten Einträge dieser Liste entstammen einer intensiven Internetrecherche. Ergänzt wurde die Liste durch Gespräche mit Entwicklern, die Erfahrung in diesem
Bereich haben.
Die umfangreiche, wenn auch nicht vollständige, Liste hat 57 Einträge. In Tabelle 4.1 auf Seite
25 sind alle betrachteten Rahmenwerke aufgeführt. Neben dem Namen und der Internetseite des
Rahmenwerks wird auch eine Bemerkung angegeben. Sie gibt entweder den Hauptgrund an,
warum das jeweilige Rahmenwerk nicht ausgewählt wurde, oder beschreibt, wie weiter mit dem
Kandidaten verfahren wurde.
Es konnte nicht jedes Rahmenwerk im Detail untersucht werden. Deswegen wurden Anforderungen formuliert, an denen sich die einzelnen Kandidaten, anhand ihrer Produktbeschreibung,
bewerten lassen.
4.2 Verfügbare Oberflächentechnologien
Rahmenwerk
Anvil
Aranea
Aurora
Barracuda
Brill
Calyxo
Caramba
Chrysalis
Click
Cocoon
DWR
Echo 3
Flexive
GWT
Hamlets
Helma
IT Mill
Jaffa
Japple
JAT
JOSSO
JPublish
JspWidget
Jucas
Jwic
JZeno
Macaw
Makumba
Maverick
Mentawai
MyFaces
openxava
OXF
Portlet
Pustefix
RAP
Restlet
Internetseite
http://njet.org/
http://www.araneaframework.org/
http://www.auroramvc.org/aurora-web/
http://www.barracudamvc.org/
http://www.brillframework.org/
http://calyxo.org/
http://www.carambacomponents.org/
http://chrysalis.sourceforge.net/
http://incubator.apache.org/click/
http://cocoon.apache.org/
http://directwebremoting.org/
http://echo.nextapp.com/site/
http://www.flexive.org/
http://code.google.com/webtoolkit/
http://hamlets.sourceforge.net/
http://helma.org/
http://www.itmill.com/itmill-toolkit/
http://jaffa.sourceforge.net/
http://www.japple.org/
http://www.myjavaserver.com/
http://www.josso.org/
http://code.google.com/p/jpublish/
http://edu.uuu.com.tw/jspwidget/
http://jucas.sourceforge.net/
http://www.jwic.de/
http://www.jzeno.org/
http://www.1729.com/macaw/
http://www.makumba.org/
http://mav.sourceforge.net/
http://www.mentaframework.org/
http://www.myfaces.org/
http://www.openxava.org/
http://www.orbeon.com/oxf/
http://developers.sun.com/portalserver/
http://pustefix-framework.org/
http://www.eclipse.org/rap/
http://www.restlet.org/
24
Bemerkung
keine reines Java
keine reines Java
nicht lebendig
nicht lebendig
keine reines Java
keine reines Java
nicht lebendig
keine reines Java
falsche Ebene
keine reines Java
falsche Ebene
Prototyp
keine reines Java
Prototyp
falsche Ebene
keine reines Java
Prototyp
nicht lebendig
nicht lebendig
keine reines Java
falsche Ebene
falsche Ebene
nicht lebendig
falsche Ebene
keine reines Java
Prototyp
falsche Ebene
keine reines Java
falsche Ebene
falsche Ebene
keine reines Java
keine reines Java
keine reines Java
falsche Ebene
keine reines Java
nicht kompatibel
falsche Ebene
Fortsetzung auf der nächsten Seite.
4.3 Kriterienkatalog
25
Fortsetzung von der letzten Seite.
Rahmenwerk
RIFE
Roma
RSF
Sofia
Stripes
STRUTS
Swinglets
Swingweb
Tapestry
ThinWire
Turbine
Verge
Vraptor
Vroom 2
WebOnSwing
Webwork
Wicket
wingS
ZK
ZTemplates
Internetseite
http://rifers.org/
http://www.romaframework.org/
http://www2.caret.cam.ac.uk/rsfwiki/
http://www.salmonllc.com/
http://www.stripesframework.org/
http://struts.apache.org/
http://www.javelinsoft.com/swinglets/
http://swingweb.sourceforge.net/
http://tapestry.apache.org/
http://www.thinwire.com/
http://turbine.apache.org/
http://www.inversoft.com/products/verge
http://www.vraptor.org/
http://vroom.sourceforge.net/
http://webonswing.sourceforge.net/
http://www.opensymphony.com/webwork/
http://wicket.apache.org/
http://wingsframework.org/
http://www.zkoss.org/
http://www.ztemplates.org/
Bemerkung
keine reines Java
nicht kompatibel
keine reines Java
keine reines Java
keine reines Java
keine reines Java
nicht lebendig
nicht lebendig
keine reines Java
Prototyp
falsche Ebene
nicht lebendig
falsche Ebene
falsche Ebene
nicht lebendig
keine reines Java
Prototyp
Prototyp
Prototyp
falsche Ebene
Tabelle 4.1: Java-Rahmenwerke zum Erstellen von Web-Anwendungen
4.3 Kriterienkatalog
Für eine sinnvolle Bewertung vieler Rahmenwerke ist ein einheitliches, strukturiertes Vorgehen
erforderlich. Jedes Rahmenwerk muss nach den selben Kriterien bewertet werden, ohne dass
Detailfragen den Bewertungs-Prozess dominieren.
Der Bewertungsmaßstab wurde anhand eines Kriterienkatalogs formuliert. Die einzelnen Kriterien wurden in zwei Kategorien unterteilt. Harte Kriterien beziehen sich auf notwendige Eigenschaften, deren Nicht-Erfüllung ein Rahmenwerk disqualifiziert. Weiche Kriterien beziehen
sich auf gewünschte Eigenschaften, die sich positiv auf eine Bewertung auswirken, aber nicht
zum Ausschluss eines Rahmenwerks führen. Der Kriterienkatalog soll folgende Aspekte berücksichtigen. Die Arbeitsweise des Rahmenwerks, eingesetzte Technologien, Funktionsumfang und
bekannte Grenzen. Anforderungen, die durch das JCommSy entstehen, sollen ebenfalls berücksichtigt werden. Eine genaue Aufzählung der Kriterien folgt in Kapitel 4.3.2 auf Seite 26.
4.3.1 Arbeitshypothese
Bei der Formulierung der Kriterien spielte, neben den fachlichen und technischen Anforderungen, meine Arbeitshypothese eine wichtige Rolle. Sie hat viele Entscheidungen in dieser Arbeit
4.3 Kriterienkatalog
26
stark beeinflusst.
Arbeitshypothese:
Eine Verbesserung von Testbarkeit, Entwicklungskomplexität und Architektur lässt
sich beim JCommSy erreichen, wenn als Oberflächentechnologie eine reine JavaLösung gewählt wird, d. h. die Oberflächenbeschreibung ausschließlich mit Java
erfolgt.
Entstanden ist diese Hypothese, durch die Erfahrungen, die ich bei der Entwicklung von JavaAnwendungen gesammelt habe. Die Werkzeugunterstützung der gängigen Entwicklungsumgebungen für Java-Quelltext ist sehr vielseitig (Syntax-Hervorhebung, Autovervollständigung,
zahlreiche Refactorings, Quelltext-Navigation, u. a.). Die Testmechanismen für Java-Quelltexte
sind erprobt und werden durch entsprechende Werkzeuge unterstützt.
4.3.2 Harte Kriterien
Die notwendigen Eigenschaften sollen durch folgende Kriterien sichergestellt werden:
Lebendigkeit:
Das CommSy und somit auch das JCommSy werden ständig erweitert. Sowohl
was die Funktionalität betrifft, als auch was die Oberfläche betrifft3 . Die Umgebungen, in
denen das CommSy genutzt wird, ändern sich ebenfalls. Zum einen werden neue Kundenkreise gewonnen4 und zum anderen ändern sich die Browser und Computer, auf denen das
CommSy angezeigt wird. Das ausgewählte Rahmenwerk sollte diesem ständigen Wandel
nicht im Wege stehen, besser wäre es, wenn es diesen unterstützt.
Um mit Veränderungen umgehen zu können, muss das Rahmenwerk sich weiterentwickeln und auf neue Rahmenbedingungen eingehen. Dies ist nur gegeben, wenn das Rahmenwerk durch eine aktive Entwicklergemeinde oder eine Firma betreut wird. Regelmäßig erscheinende, neue Versionen des Rahmenwerks, die Fehler beheben und neue Funktionalität bereitstellen, stellen ein wichtiges Kriterium für die Auswahl dar.
Für den Moment ein ausgereiftes und stabiles Rahmenwerk zu haben, reicht nicht aus.
reines Java:
Eine grafische Benutzungsoberfläche für eine Java-Web-Anwendung kann auf
verschiedene Arten beschrieben werden (XML, UIML5 , Java, JSP, HTML, u. a.). Beschreibungen in XML-Dialekten oder speziell entworfene Sprachen kommen für diese
Arbeit nicht in Frage. Ein Rahmenwerk-Kandidat muss die Möglichkeit bieten, die Oberfläche ausschließlich mit Java-Quelltext zu beschreiben, um der Arbeitshypothese (siehe
Seite 26) zu genügen.
Kompatibilität:
Ein weiteres Kriterium ist die Kompatibilität zu den bestehenden Komponenten des JCommSy. Genauer gesagt, zu den Komponenten, die auch nach dem Technologiewechsel noch benutzt werden sollen. Kritisch sind Technologien, wie zum Beispiel
3 siehe
http://www.commsy.net/Software/Historie
„effective webwork GmbH“ vertreibt das CommSy als Dienstleistung.
5 User Interface Markup Language (siehe Phanouriou [Pha00])
4 Die
4.3 Kriterienkatalog
27
Hibernate und Spring, die Anforderungen an den Kontrollfluss oder die Typhierarchie haben.
Mit einem Rahmenwerk, welches diese drei Kriterien erfüllt, sollte es möglich sein, eine neue
Benutzungsoberfläche für das JCommSy zu entwickeln und dabei die Testbarkeit, die Entwicklungskomplexität sowie die Architektur zu verbessern.
4.3.3 Weiche Kriterien
Wünschenswerte Eigenschaften sollen durch folgende Kriterien in die Bewertung einfließen:
einfache Konguration:
Die Konfiguration des Rahmenwerks sollte so erfolgen, dass Änderungen im System (zum Beispiel das Umbenennen einer Klasse mittels Refactoring) keine manuelle Anpassung der Konfiguration erfordern. Das Rahmenwerk könnte nach dem
Prinzip „Konventionen über Konfiguration“6 arbeiten, oder in das Refactoring-Werkzeug
der Entwicklungsumgebung integrierbar sein.
Komponentenvielfalt:
Mit den, vom Rahmenwerk bereitgestellten, grafischen Komponenten,
sollte mindestens das erreicht werden können, was beim PHP-CommSy bereits möglich
ist (beispielsweise Tabellen, aufklappbare Elemente, Überblend-Effekte).
Die Komponentenvielfalt sollte Raum für zukünftige Entwicklungen bieten, z. B. das Einbinden von Videos erlauben.
anpassbare Stile:
Der grafische Stil der Benutzungsoberfläche sollte über externe, austauschbare Stilbeschreibungen definierbar sein. Das Aussehen der Anwendung (Abstände, Farbe, Schriften, etc.) lässt sich so flexibel für einzelne Benutzer oder Räume ändern. Am
besten wären CSS-Dateien (siehe Kapitel 2.2.2 auf Seite 10), da diese verbreitete Technologie bereits im (J)CommSy eingesetzt wird.
direkte Verwendung fachlicher Objekte:
Kann man die fachlichen Objekte und Klassen direkt als Modell für die Komponenten der Oberfläche verwenden, ist keine Abbildung von
String oder Integer-Werten auf fachliche Objekte mehr notwendig. Man kann direkt mit
den Referenzen arbeiten und muss nicht auf IDs zurückgreifen. Modell und Anzeige synchron zu halten, sowie Interaktionen mit dem restlichen System erfordern weniger Aufwand. Der Quelltext wird lesbarer, da eine Indirektionsschicht wegfällt.
Lizenz und oene Quellen:
Das (J)CommSy selbst ist quelloffen und verwendet ausschließlich quelloffene Rahmenwerke. Das neue Rahmenwerk sollte diesem Trend folgen.
Auch die jeweils verwendete Lizenz muss Beachtung finden. Nicht-kostenfreie Rahmenwerke befinden sich außerhalb des Projektbudgets dieser Diplomarbeit.
Mit diesen zusätzlichen Kriterien können die Rahmenwerk-Kandidaten genauer bewertet werden und sich voneinander abheben.
6 Convention
over Configuration (CoC) siehe Esser [Ess08]
4.4 Bewertung anhand des Kriterienkatalogs
28
4.4 Bewertung anhand des Kriterienkatalogs
Im nächsten Schritt wurden die 57 Rahmenwerke anhand des Kriterienkatalogs bewertet. Bei 49
Rahmenwerken konnte schnell ein hartes Kriterium ausgemacht werden, dass nicht erfüllt wurde. Diese Rahmenwerke wurden dann nicht weiter untersucht. Aus diesem Grund wurde auch
keine Tabelle angelegt, in der für jedes Rahmenwerk angegeben ist, welche Kriterien erfüllt
wurden und welche nicht. Ein effizientes Vorankommen stand bei der Evaluierung der Rahmenwerke im Vordergrund.
Die benötigten Informationen wurden der Produktbeschreibung, FAQ7 oder einer Kurzanleitung
auf der Internetseite des jeweiligen Rahmenwerks entnommen.
Die im Folgenden angeführten Gründe für den Ausschluss von Rahmenwerken stellen den offensichtlichsten Grund (nicht erfülltes Kriterium) dar. In der Regel gab es auch weitere Gründe,
die aber nicht mehr betrachtet werde mussten.
4.4.1 Falsche Ebene
Bei 15 Rahmenwerken gebe ich als Grund für das Streichen von der Kandidaten-Liste „falsche
Ebene“ an.
Diese Rahmenwerke sind nicht selbstständig dazu in der Lage, eine Benutzungsoberfläche aus
Quelltext zu generieren. Sie greifen dafür auf andere Rahmenwerke zurück, die größtenteils in
der Liste der möglichen Rahmenwerke vertreten sind. Der eigentliche Fokus der 15 Rahmenwerke liegt in einer höheren Abstraktionsebene (z. B. kombinieren von einzelnen Teilanwendugen
zu einer großen Anwendung) oder anderen Aspekten einer Web-Anwendung (z. B. Verwendung
des Model-View-Controller Entwurfsmusters8 ).
Dieser Grund hat nicht direkt etwas mit den formulierten Kriterien zu tun, sondern stellt eine Grundvoraussetzung dar. Die beiden auszutauschenden Rahmenwerke müssen ihren Fokus
auf der selben Ebene haben. Das JSP-Rahmenwerk gibt somit die Ebene vor (Erzeugung der
Benutzungsoberfläche).
4.4.2 Kein reines Java
Das Kriterium „reines Java“ konnte von 22 Rahmenwerken nicht erfüllt werden.
Viele Rahmenwerke benutzten speziell erweitertes HTML oder eine XML-Beschreibung, um
eine Benutzungsoberfläche zu generieren. Das gesuchte Rahmenwerk sollte die Möglichkeit
bieten, die Benutzungsoberfläche in Java zu beschreiben.
4.4.3 Nicht lebendig
Von den verbliebenen Rahmenwerken wurden 10 als nicht lebendig eingestuft.
7 Frequently
8 siehe
Asked Questions (häufig gestellte Fragen)
Reenskaug [Ree79]
4.5 Evaluation durch Prototypen
29
Bei einigen Rahmenwerken war die Internetseite nicht mehr erreichbar und kein Hinweis auf
eine neue Adresse zu finden. Diese Rahmenwerke wurden als nicht mehr lebendig eingestuft.
Die restlichen, so eingestuften Rahmenwerke hatten innerhalb der letzten achtzehn Monate keine
neue Version herausgebracht und es konnten kein Hinweis auf Weiterentwicklungen gefunden
werden.
4.4.4 Nicht kompatibel
„Nicht kompatibel“ lautet der Grund bei 2 Rahmenwerken.
Der eigentliche Kern des Kompatibilitäts-Kriteriums liegt in der technologischen Kompatibilität. Die beiden ausgeschiedenen Kandidaten waren jedoch auf Prozess-, bzw. Design-Ebene
inkompatibel.
Das eine Rahmenwerk setzt voraus, dass bei der Entwicklung nach DDD9 vorgegangen wird.
Dies ist beim JCommSy nicht der Fall.
Das andere Rahmenwerk setzt voraus, dass die Web-Anwendung als Eclipse10 -Plugin realisiert
wird. Dies ist technisch möglich, bedeutet aber einen erheblichen Mehraufwand.
Von den ursprünglich 57 Kandidaten waren an dieser Stelle noch 8 Rahmenwerke im Rennen.
Mit dieser stark reduzierten Auswahl wurden genauere Untersuchungen durchgeführt.
4.5 Evaluation durch Prototypen
Die Überprüfung der Kriterien anhand von Informationen aus den Internetseiten der Rahmenwerke konnte bei 8 Rahmenwerken keine ungewollten Eigenschaften identifizieren. Um eine
fundierte Wahl treffen zu können, wurden diese Rahmenwerke einem Praxis-Test unterzogen.
Zuvor nicht erkennbare Eigenschaften sollten so aufgedeckt und überprüft werden.
Für jedes der 8 Rahmenwerke sollte ein Prototyp entwickelt werden, der mit dem bestehenden
JCommSy zusammenarbeitet. Durch das praktische Arbeiten mit den Rahmenwerken sollte klar
werden, wo ihre Stärken und Schwächen liegen.
In der Softwaretechnik unterscheidet man 3 Arten von Prototypen (siehe Floyd [BFK+ 84, S.
1-18]). Explorative Prototypen werden verwendet, um bei einer unklaren Problemstellung die
Anforderungen an die Anwendung zu ermitteln. Bei diesem Vorgang lernen die Entwickler den
Anwendungsbereich besser kennen. Experimentelle Prototypen werden erstellt, wenn technische
Aspekte der Anwendung zu testen sind. Die Entwickler können dadurch besser abschätzen, was
machbar ist und was nicht. Ein evolutionärer Prototyp wird ständig weiterentwickelt und erlaubt
es den Entwicklern, auf sich ständig ändernde Randbedingungen zu reagieren.
Zusätzlich kann man zwischen horizontalen und vertikalen Prototypen unterscheiden. Ein horizontaler Prototyp stellt nur eine Oberfläche zur Verfügung, ohne darunterliegende Funktionalität.
Ein vertikaler Prototyp stellt eine Funktion zur Verfügung, von der Oberfläche bis zur untersten
Schicht implementiert.
Für die Evaluation werden experimentelle, vertikale Prototypen erstellt.
9 Domain-Driven
10 verbreitete
Design nach Evans [Eva04]
Entwicklungsumgebung, siehe http://www.eclipse.org/
4.5 Evaluation durch Prototypen
30
4.5.1 Umfang der Prototypen
Der Umfang der Prototypen war für alle Rahmenwerke gleich. Er wurde bewusst gering gewählt,
um den zeitlichen Aufwand klein zu halten. Der Prototyp, des am Ende gewählten Rahmenwerks, sollte als Basis für die neue Benutzungsoberfläche dienen und weiterentwickelt werden.
1. Das Rahmenwerk muss zunächst in das JCommSy integriert werden. Bibliotheken müssen bereitgestellt und rahmenwerk-spezifische Einstellungen vorgenommen werden. Die
Funktionalitäten des Rahmenwerks müssen zur Laufzeit (im Servlet-Container11 ) zur Verfügung stehen.
Bei diesem ersten Schritt wird die Kompatibilität mit dem Servlet-Container und den bereits vorhandenen Bibliotheken des JCommSy überprüft. Die Konfigurationsdateien müssen angepasst und die Rahmenwerkbibliotheken zu den Bibliotheken des JCommSy kopiert werden.
2. Die Implementierung eines Anmelde-Systems (Anmeldung über Benutzername und Kennwort) soll sicherstellen, dass die Interaktion mit dem JCommSy in beide Richtungen funktioniert. Im Speziellen gilt dies für die, über Spring (siehe Kapitel 2.2.4 auf Seite 10)
verfügbar gemachten, Dienste.
Java-Klassen müssen implementiert werden, die eine Anmeldeseite anbieten und auf den
ApplicationContext von Spring zugreifen können.
3. Für das Erzeugen einer Portal-Übersicht (Auflistung aller verfügbaren Portale auf einem
CommSy-Server) müssen weitere Dienste verwendet werden, dies sollte aber kein Problem darstellen, nachdem das Anmelde-System funktioniert.
Der Prototyp muss Portal-Materialien verwenden, die vom JCommSy persistiert wurden.
Dies stellt sicher, dass das Rahmenwerk mit Hibernate (siehe Kapitel 2.2.3 auf Seite 10)
zusammenarbeiten kann.
Es muss außerdem mit der Lokalisierung des JCommSy umgegangen werden, d. h. die
Informationen aus den Portal-Materialien müssen in der richtigen Sprache angezeigt werden.
Für die grafische Aufbereitung der Informationen kommen einige Standardkomponenten
zum Einsatz. Durch den Umgang mit diesen Komponenten gewinnt man einen praxisnahen Eindruck von der Komplexität und Flexibilität des Rahmenwerks.
Weitere Java-Klassen müssen hierfür realisiert werden. Die von den Diensten erhaltenen
Materialien müssen als Modell für graphische Elemente hinterlegt werden.
Es wurden 8 Prototypen entwickelt. Nicht alle wurden zuende entwickelt, da sich in einigen
Fällen Eigenschaften bemerkbar machten, die ein Fortführen überflüssig machten. Eine genaue
Bewertung der Prototypen folgt.
11 Das
JCommSy verwendet einen Apache Tomcat als Servlet-Container (inklusive Jasper als JSP-Compiler) und
einen Apache Web-Server.
4.5 Evaluation durch Prototypen
31
4.5.2 Bewertung der Prototypen
Im Folgenden werden die Erkenntnisse aus dem Bau der Prototypen zusammengefasst. Jedes der
8 Rahmenwerke wird anhand des Kriterienkatalogs bewertet. Auch subjektive Eindrücke aus der
praktischen Umsetzung fließen in die Bewertung ein. Die Prototypen wurden im September/Oktober 2008 entwickelt.
4.5.2.1 Echo 3
Das Echo-Rahmenwerk lag zum Zeitpunkt der Evaluierung in der Version 3.0.b1 vor. Es ließ
sich problemlos in das JCommSy integrieren, d. h. es gab keine Konflikte mit bestehenden Programmbibliotheken oder dem verwendeten Servlet-Container.
Harte Kriterien:
Lebendigkeit:
Am 2. Juni 2008 ist die erste Beta-Version von Echo 3 erschienen. Echo 3 ist
eine Weiterentwicklung von Echo 2, welches weiterhin gewartet wird. Die Firma NextApp
betreut dieses Rahmenwerk. Neue Versionen sind regelmäßig erschienen und es gibt keine
Anzeichen dafür, dass es in Zukunft nicht mehr so sein wird.
reines Java:
Die Beschreibung der Benutzungsoberfläche kann vollständig in Java erfolgen.
Echo 3 verhält sich für einen Entwickler ähnlich wie Swing oder SWT (Standard Widget
Toolkit)12 bei einer Java-Desktop-Anwendung.
Kompatibilität:
Die Echo 3 Bibliotheken, sowie die Konfiguration des Rahmenwerks konnten
in das JCommSy integriert werden. Das Zusammenspiel mit Spring und Hibernate war
problemlos.
Alle harten Kriterien werden erfüllt.
Weiche Kriterien:
einfache Konguration:
Die Konfiguration des Rahmenwerks ist minimal und muss nur angepasst werden, wenn die Servlet-Klasse, die als Einstiegspunkt ins System dient, ihren
Namen ändert. Alle anderen Einstellungen erfolgen im Java-Quelltext.
Komponentenvielfalt:
Es gibt eine Reihe von Standardkomponenten (Textfelder, Knöpfe,
Listen, u. a.) und komplexe Komponenten (beispielsweise: Kalender, Kontextmenüs). Das
Standard-Aussehen dieser Komponenten überzeugt nicht. Die meisten von Ihnen sehen
wie aneinandergefügte Rechtecke aus.
anpassbare Stile:
Das Aussehen der einzelnen Komponenten lässt sich über CSS-Dateien
steuern.
12 Komponentenbibliotheken
zum Erstellen grafischer Oberflächen für Desktop-Anwendungen.
4.5 Evaluation durch Prototypen
32
direkte Verwendung fachlicher Objekte:
Echo 3 unterstützt beliebige Objekte als ModellInhalt. Es kann eine Klasse angegeben werden, die bei Bedarf die Daten aus dem Modell
für die Anzeige aufbereitet (Renderer).
Lizenz und oene Quellen:
Das Echo-Rahmenwerk ist quelloffen und wird unter der Mozilla Public License13 vertrieben.
Auch die weichen Kriterien werden erfüllt. Lediglich die grafischen Komponenten können nicht
voll überzeugen. Echo 3 ist somit ein guter Kandidat für die neue Oberflächentechnologie.
4.5.2.2 GWT
Das GWT-Rahmenwerk (Google Web Toolkit) kam in Version 1.5.0 (1.5 RC 1) zum Einsatz.
Eine Besonderheit von GWT ist der Java-nach-JavaScript14 -Compiler. Der Entwickler schreibt
seine Anwendung in Java und kann mit diesem Compiler JavaScript daraus generieren. Diese
Skripte können dann im Browser ausgeführt werden. Die Rechenlast wird auf alle Nutzer der
Anwendung verteilt und die Netzwerkkommunikation reduziert. Die Integration in das JCommSy war kompliziert, da der GWT-Compiler bestimmte Strukturen voraussetzt und einen weiteren
Schritt im Bau-und-Auslieferungs-Zyklus darstellt.
Harte Kriterien:
Lebendigkeit:
Das GWT-Rahmenwerk wird kontinuierlich weiterentwickelt. Mit Google steht
eine große Firma hinter diesem Projekt. Hinzu kommt eine aktive Nutzer- und Entwicklergemeinde.
reines Java:
Auch dieses Rahmenwerk verhält sich für einen Entwickler wie Komponentenbibliotheken von Java-Desktop-Anwendungen. Die Beschreibung erfolgt ausschließlich in
Java.
Kompatibilität:
Da ein Teil des Java-Quelltexts zu JavaScript übersetzt wird, steht in diesem
Teil nur eine Untermenge von Java zur Verfügung. Bestimmte Funktionalitäten werden
vom Compiler nicht unterstützt15 . Das hat Auswirkungen auf die Verwendbarkeit von
bestehenden Systemteilen des JCommSy.
Das Verwenden von Materialien, die durch Hibernate persistiert wurden, war mit GWT
nicht möglich.
Als klar wurde, dass das Kompatibilitäts-Kriterium von GWT nicht erfüllt werden konnte, habe
ich diesen Prototypen abgebrochen und mit dem nächsten Kandidaten weiter gemacht.
13 siehe
http://echo.nextapp.com/site/license/mpl
ist eine Skriptsprache, die hauptsächlich in Web-Browsern eingesetzt wird.
15 Genauere Informationen werden in der JRE Emulation Reference angegeben.
14 JavaScript
4.5 Evaluation durch Prototypen
33
4.5.2.3 IT-Mill-Toolkit
Das IT-Mill-Toolkit wurde in der Version 5.2.5 evaluiert. Bei der Integration in das JCommSy
traten keine Probleme auf.
Harte Kriterien:
Lebendigkeit:
Die Version 4 wird noch gewartet, die Version 5 wird von einer aktiven Entwicklergemeinde weiterentwickelt. Fast alle 2 Wochen steht eine neue Version bereit. Betreut und vermarktet wird das Rahmenwerk von der Firma IT Mill.
reines Java:
Die Entwicklung erfolgt in Java. Der Aufbau des Quelltexts gleicht dem von
Java-Desktop-Anwendungen, deren Benutzungsoberfläche mit Swing oder SWT realisiert
wird.
Kompatibilität:
Beim Bau des Prototypen wurden keine Inkompatibilitäten festgestellt. Hibernate und Spring konnten problemlos verwendet werden.
Die harten Kriterien werden von diesem Rahmenwerk erfüllt.
Weiche Kriterien:
einfache Konguration:
Die Konfiguration dieses Rahmenwerks ist minimal und muss nur
angepasst werden, wenn die Servlet-Klasse, die als Einstiegspunkt ins System dient, ihren
Namen ändert. Alle anderen Einstellungen erfolgen im Java-Quelltext.
Komponentenvielfalt:
Das Rahmenwerk liefert einen Reihe von Standardkomponenten
(Textfelder, Knöpfe, Listen, u. a.), sowie eine Reihe von erweiterten Komponenten (beispielsweise: Text-Editoren, Tabellen). Das Ein- und Ausklappen einzelner Komponenten
ist nicht möglich. Diese Funktion des PHP-CommSy kann nicht nachgebildet werden. Das
Aussehen der Komponenten ist ansprechend, hat aber ein typisches Erscheinungsbild, das
sich in der eigenen Anwendung zwangsweise wiederfindet.
anpassbare Stile:
Zur Verwendung von CSS-Dateien für die Anpassung der Benutzungsoberfläche wird geraten. Verfügbare Befehle und Eigenschaften sind gut dokumentiert.
direkte Verwendung fachlicher Objekte:
Das Rahmenwerk sieht spezielle Behälter vor,
um Datenobjekte aufzunehmen. Es können Klassen angegeben werden, die aus diesen
Behältern die Daten für die Anzeige generieren. Fachliche Objekte als Modell zu verwenden, ist mit diesem Mechanismus möglich.
Lizenz und oene Quellen:
Das IT Mill Toolkit ist quelloffen und wird unter der ApacheLizenz in Version 2.0 16 vertrieben.
16 http://www.apache.org/licenses/LICENSE-2.0.html
4.5 Evaluation durch Prototypen
34
Das einzige Kriterium, dass von diesem Rahmenwerk nicht voll erfüllt wird, ist das grafische
Komponenten Kriterium. Es kommt somit für die neue Oberflächentechnologie in Frage, ist
aber kein optimaler Kandidat.
4.5.2.4 JZeno
Der Prototyp für das JZeno-Rahmenwerk wurde mit der Version 1.1.0 entwickelt. Bei der Integration in das JCommSy gab es keine Probleme.
Harte Kriterien:
Lebendigkeit:
Neue Versionen des Rahmenwerks gibt es in regelmäßigen Abständen. Eine
Entwicklergruppe von etwa 14 Personen pflegt das Rahmenwerk und nimmt Weiterentwicklungen vor. Eine aktive Nutzergemeinde, die an der Verbesserung des Rahmenwerks
mitwirkt, gibt es nicht.
reines Java:
Die Struktur der Oberfläche und die Interaktion der Komponenten wird in Java
beschrieben. Andere Sprachen sind nicht notwendig.
Kompatibilität:
Hibernate, Spring und alle anderen Technologien des JCommSy konnten problemlos zusammen mit JZeno verwendet werden.
Bei den harten Kriterien erreicht dieses Rahmenwerk drei von drei Punkten.
Weiche Kriterien:
einfache Konguration:
Die Konfiguration des Rahmenwerks erfolgt zentral in einer
Properties-Datei17 . Alle Klassennamen sind vollqualifiziert und somit unkritisch für einfache Refactorings (z. B. Umbenennen/Verschieben einer Klasse).
Komponentenvielfalt:
Auch dieses Rahmenwerk liefert Standardkomponenten und erweiterte Komponenten. Sie wirken flach und vermitteln kein Anwendungsgefühl18 . Des Weiteren stehen keine Effekte zur Verfügung (Ein-/Ausklappen), wie sie im CommSy Verwendung finden.
anpassbare Stile:
Layout und Stil werden über Manager-Klassen gesteuert. Diese können
nach eigenem Ermessen implementiert werden. Eine einfache, direkte Nutzung von CSS
ist nicht möglich. Für eine Verwendung von CSS müsste eine Manager-Klasse, die CSS
interpretiert, entwickelt werden.
direkte Verwendung fachlicher Objekte:
Als Modell für die grafischen Komponenten können fachliche Objekte verwendet werden. Die Interpretation dieser Objekte für die Anzeige wird von Objekten übernommen, die man selbst angeben (und implementieren) kann.
4.5 Evaluation durch Prototypen
35
Lizenz und oene Quellen:
JZeno ist ein quelloffenes Rahmenwerk und wird unter der
GNU19 Lesser General Public License (LGPL)20 vertrieben.
Wie das vorherige Rahmenwerk, erfüllt auch dieses nahezu alle Kriterien. Nur bei 2 weichen
Kriterien (grafische Komponenten und anpassbare Stile) müssen Einschränkungen gemacht werden. JZeno ist ein weiterer, wenn auch nicht optimaler, Kandidat für die neue Oberflächentechnologie des JCommSy.
4.5.2.5 ThinWire
Das ThinWire-Rahmenwerk lag zum Zeitpunkt der Evaluierung in der Version 1.2 vor. Es lies
sich problemlos in das JCommSy integrieren.
Harte Kriterien:
Lebendigkeit:
Das Rahmenwerk wird von einer Entwicklergemeinschaft gepflegt, ohne kommerzielle Unterstützung. Die Entwickleraktivität ist gering und weist eine abnehmende
Tendenz auf (nur 3 kleine Veränderungen am Projekt in den letzten 6 Monaten). Die aktuellste Version (1.2) ist vom 17. September 2007.
reines Java:
Die Implementierung der Benutzungsoberfläche erfolgt in Java.
Kompatibilität:
Die Verwendung von Hibernate stellte kein Problem dar. Die Verwendung
von Spring wurde vom Rahmenwerk nicht unterstützt.
Zwei harte Kriterien werden von ThinWire nur teilweise erfüllt. Das reines Java Kriterium wird
zwar erfüllt, die Umsetzung hat aber einen starken Nachteil: Alle Größen und Positionen von
Komponenten müssen explizit angegeben werden (in Pixeln). Andere Rahmenwerke verfolgen
in dieser Hinsicht bessere Konzepte und erfüllen die anderen harten Kriterien voll. Der Prototyp
für ThinWire wurde an dieser Stelle abgebrochen.
4.5.2.6 Wicket
Version 1.3.4 des Wicket-Rahmenwerks wurde für diesen Prototyp verwendet.
Harte Kriterien:
Lebendigkeit:
Das Wicket-Rahmenwerk wird von der Apache Software Foundation betreut
und veröffentlicht regelmäßig neue Versionen.
17 Textdatei,
die Name-Wert-Paare von Eigenschaften enthält.
Verhalten und Rückmeldung ähneln der einer lokalen Anwendung.
19 GNU = rekursives Akronym von GNU’s Not Unix
20 Lizenz siehe http://www.gnu.org/licenses/lgpl.html
18 Aussehen,
4.5 Evaluation durch Prototypen
36
reines Java:
Die Komponenten, deren Verhalten und Inhalt werden im Java-Quelltext beschrieben. Das Zusammenstellen zu einer Benutzungsoberfläche geschieht durch spezielle
HTML-Tags in einem HTML-Dokument.
Kompatibilität:
Das Zusammenspiel von Hibernate/Spring und Wicket funktioniert und ist gut
dokumentiert.
Die Entscheidung, für das Wicket-Rahmenwerk einen Prototyp zu entwickeln, wurde unter der
Annahme getroffen, dass sehr wenig der Oberflächenbeschreibung im HTML-Quelltext geschieht. Eine genauere Betrachtung (als Vorbereitung auf den Bau des Prototypen) zeigte jedoch, dass der HTML-Quelltext einen nicht unerheblichen Teil der dynamischen und statischen
Struktur der Oberfläche enthält. Im Java-Quelltext werden die Komponenten definiert und im
HTML-Quelltext werden diese zusammengefügt und verknüpft. Das reine Java Kriterium wird
von Wicket nicht erfüllt.
Unter diesen Voraussetzungen wurde darauf verzichtet, den Prototypen weiter zu verfolgen.
4.5.2.7 wingS
Zum Zeitpunkt des Prototypbaus war Version 3.2.1 des wingS-Rahmenwerks aktuell. Die Integration mit dem JCommSy verursachte keine Probleme.
Harte Kriterien:
Lebendigkeit:
Das Rahmenwerk hat eine Entwicklergemeinschaft von etwa 30 Personen. Die
zuletzt veröffentlichte Version ist vom April 2008. Davor gab es etwa alle 6 Monate eine
neue Version. Seit der letzten Version hat die Aktivität der Entwickler stetig abgenommen
und in den letzten 6 Wochen gab es keine Aktivität mehr.
reines Java:
Auch dieses Rahmenwerk erlaubt eine Beschreibung der Benutzungsoberfläche
ähnlich zu Swing oder SWT.
Kompatibilität:
Bei der Verwendung von Spring, Hibernate und anderen Technologien traten
keine Probleme auf.
Die harten Kriterien sind erfüllt, allerdings lässt sich die Lebendigkeit nicht hundertprozentig
einordnen.
Weiche Kriterien:
einfache Konguration:
Die Konfiguration dieses Rahmenwerks ist einfach gehalten. Sie
enthält nur ein Element (Klassenname), welches Veränderungen unterworfen sein kann.
Dieser Klassenname ist vollqualifiziert und kann deshalb von Refactorings mit berücksichtigt werden.
4.5 Evaluation durch Prototypen
37
Komponentenvielfalt:
Standardkomponenten und erweiterte Komponenten sind verfügbar.
Ihr Aussehen ist klobig, da die meisten Komponenten wie einfache Rechtecke aussehen.
Das Fehlen von Animationen und lokal ausgeführten Aktionen (alles läuft über den Server) führt zu einem statischen Erscheinungsbild, ohne echtes Anwendungsgefühl (keine
RIA21 ).
anpassbare Stile:
CSS-Dateien lassen sich problemlos verwenden, um das Aussehen der Anwendung zu steuern.
direkte Verwendung fachlicher Objekte:
Das Rahmenwerk ist darauf ausgelegt, beliebige
Objekte als Datenmodell zu benutzen. Für die Anzeige werden Objekte angegeben, die
aus den Daten die entsprechenden Anzeigeelemente generieren.
Lizenz und oene Quellen:
WingS ist ein quelloffenes Rahmenwerk, das unter der GNU
LGPL vertrieben wird.
Die nicht eindeutige Lebendigkeit und die grafischen Komponenten, die nicht überzeugen konnten, machen einen Einsatz für das JCommSy unwahrscheinlich. Trotz der 6 Kriterien in denen
wingS bestehen konnte.
4.5.2.8 ZK
Der letzte Prototyp wurde mit dem ZK-Rahmenwerk in Version 3.0.7 erstellt. Das Einpflegen in
das JCommSy verursachte keine Probleme.
Harte Kriterien:
Lebendigkeit:
Es gibt sowohl eine aktive Entwicklergemeinde, als auch eine aktive Nutzergemeinde. Neue Versionen erschienen in der Regel jeden Monat. Alte Versionszweige
werden weiterhin gewartet. Die Firma Potix Corporation entwickelt und vermarktet ZK
und bietet kommerziellen Support.
reines Java:
Eine der Alternativen, mit der man in ZK die Benutzungsoberfläche beschreiben
kann, ist reines Java. Viele Beispiele und der Großteil der Dokumentation sind allerdings
nicht für die Java Variante ausgelegt.
Der Java-Quelltext ist ähnlich zu Anwendungen, die Swing oder SWT verwenden.
Kompatibilität:
Das Arbeiten mit Spring und ZK ist möglich und gut dokumentiert. Hibernate
arbeitet problemlos mit ZK zusammen. Beim Bau des Prototypen traten keine Inkompatibilitäten auf.
21 RIA
= Rich Internet Application
4.5 Evaluation durch Prototypen
38
Das ZK-Rahmenwerk erfüllt alle harten Kriterien. Die Dokumentation für die reine Java Variante könnte besser sein. Es ist jedoch möglich die Beispiele, die nicht für die Java Variante sind,
als Hilfestellung für Java zu verwenden.
Weiche Kriterien:
einfache Konguration:
Wie bei den übrigen Rahmenwerken müssen einige Einstellungen
einmalig in vorhandenen Konfigurationsdateien vorgenommen werden. In einer ZKeigenen Konfigurationsdatei wird der Einstiegspunkt (Klasse) in das System angegeben.
Der Klassenname ist vollqualifiziert und kann von Refactorings mit erfasst werden.
Komponentenvielfalt:
Die zur Verfügung stehenden Komponenten decken alle Bereiche ab,
die dieses Kriterium fordert. Das Aussehen und Verhalten ist ansprechend und lässt ein
Anwendungsgefühl entstehen.
anpassbare Stile:
Das Aussehen der Anwendung und der einzelnen Komponenten lässt sich
über CSS-Dateien steuern.
direkte Verwendung fachlicher Objekte:
Auch dieses Rahmenwerk bietet die Möglichkeit
auf fachliche Objekte als Modell-Inhalte zurückzugreifen. Für die Aufbereitung der Daten
kann dann ein spezielles Objekt angegeben werden. Für einfache Fälle gibt es vorgefertigte Klassen, man kann aber auch eigene Klassen implementieren.
Lizenz und oene Quellen:
ZK ist quelloffen und wird unter zwei verschiedenen Lizenzen
vertrieben. Für Entwickler, die ihre Anwendung unter der GNU General Public License
(GPL22 ; oder einer vergleichbaren Lizenz) veröffentlichen wollen, gilt die GNU GPL in
Version 3. Für Entwickler, deren Anwendung kostenpflichtig vertrieben werden soll, gibt
es eine kommerzielle Lizenz. Für das JCommSy findet das erste Lizenzmodell Anwendung.
Das ZK-Rahmenwerk erfüllt alle Kriterien und ist ein guter Kandidat für das JCommSy.
4.5.3 Auswertung und Auswahl
Die Bewertung von allen 8 Prototypen lag nun vor. GWT, ThinWire und Wicket wurden vorzeitig
abgebrochen, weil klar wurde, dass sie für einen Einsatz im JCommSy nicht in Frage kommen.
Das wingS-Rahmenwerk konnte nur knapp als tauglich gewertet werden und ist somit nur die
letzte Alternative. IT Mill Toolkit und JZeno konnten besser abschneiden, wiesen aber deutliche
Defizite auf. Echo 3 und ZK sind die beiden Rahmenwerke, die sich als Favoriten herausstellten.
Beide konnten dem Kriterienkatalog voll entsprechen.
Es kann aber nur ein Rahmenwerk zum Einsatz kommen, um den Technologieaustausch zu vollziehen. Die objektiven Kriterien haben keinen klaren Sieger hervorbringen können. Um dennoch
22 siehe
http://www.gnu.de/documents/gpl.de.html
4.6 Zusammenfassung
39
zu einer eindeutigen Wahl zu kommen, habe ich mich auf meine subjektiven Erfahrungen beim
Bau der Prototypen berufen. Zwei Aspekte waren dabei für mich wichtig: Mit welchem Rahmenwerk ließ es sich leichter und effizienter entwickeln und bei welchem Prototypen gefiel mir
das Resultat am besten, sowohl das Aussehen, als auch die Benutzung der Benutzungsoberfläche
betreffend.
Die Wahl fiel auf das ZK-Rahmenwerk. Ausgehend vom angefertigten Prototyp habe ich die
Benutzungsoberfläche des JCommSy auf dieses Rahmenwerk umgestellt. Wie ich dabei genau
vorgegangen bin, wird im nächsten Kapitel beschrieben.
4.6 Zusammenfassung
Zunächst wurde beschrieben, wie der Systemteil aufgebaut ist, dessen Austausch angestrebt
wird. Dann wurde aufgezeigt, wie zahlreich die Alternativen für diesen Austausch sind. Mit 57
Rahmenwerken wurde keine vollständige, aber eine sehr umfangreiche Liste zusammengestellt.
Um der Anzahl Herr zu werden, wurde ein Kriterienkatalog aufgestellt.
Er enthält 3 harte Kriterien, deren Erfüllung notwendig ist. Lebendigkeit, um sicherzustellen,
dass das Rahmenwerk in Zukunft weiterentwickelt wird. Das Reines-Java-Kriterium stellt die
Anforderung, dass das Rahmenwerk eine Beschreibung der Benutzungsoberfläche in Java ermöglicht. Kompatibilität zum JCommSy wird ebenfalls gefordert.
Und der Kriterienkatalog enthält 5 weiche Kriterien, deren Erfüllung wünschenswert ist. Das
neue Rahmenwerk soll einfach konfigurierbar sein. Es soll eine Komponentenvielfalt bieten, um
das PHP-CommSy nachbauen oder übertreffen zu können. Anpassbare Stile sollen eine einfache Individualisierung erlauben. Die direkte Verwendung fachlicher Objekte als Modell für die
Oberflächenkomponenten ist eine weitere gewünschte Eigenschaft. Eine kostenlose Lizenz und
offene Quellen ist der letzte Punkt des Kriterienkatalogs.
Nach dem Anwenden des Kriterienkatalogs auf die Liste der Rahmenwerke, verblieben 8 Alternativen. Die genauere Untersuchung erfolgte durch den Bau von 8 Prototypen. Die Auswertung
der Prototypen zeigte 2 Rahmenwerke gleichauf an der Spitze der möglichen Alternativen. Für
die letzte Entscheidung nahm ich meine persönlichen Eindrücke und Erfahrungen zur Hilfe und
entschied mich für das ZK-Rahmenwerk.
Kapitel 5 Realisierung der neuen Benutzungsoberfläche
40
Kapitel 5
Realisierung der neuen
Benutzungsoberäche
In diesem Kapitel wird beschrieben, wie die neue Benutzungsoberfläche in das bestehende
JCommSy-System integriert wurde, wie dessen Konfiguration erfolgt und welche Systemteile
wiederverwendet werden. Das Aussehen und Verhalten der Benutzungsoberfläche wird ebenfalls beschrieben.
Entscheidungen, die die Entwicklung der Benutzungsoberfläche betreffen, werden in diesem
Kapitel nachvollziehbar gemacht. Testbarkeit, Architektur und Entwicklungskomplexität werden jedoch weder beschrieben, noch bewertet. Dafür ist Kapitel 6 Auswirkungen des Technologiewechsels vorgesehen.
Die Entwicklung der neuen Benutzungsoberfläche wurde mit dem Bau des ZK-Prototypen bereits begonnen. Nach der Entscheidung für das ZK-Rahmenwerk wurde dieser über einen Zeitraum von mehreren Wochen weiterentwickelt. Zum Ende der Entwicklungsarbeiten standen neben den Funktionalitäten des Prototypen (Portalübersicht, Anmeldesystem und Raumübersicht)
noch folgende Funktionalitäten zur Verfügung: Eine Hauptseite mit Reitern für jede Rubrik, ein
Menü mit möglichen Aktionen, eine Such-Funktion, Nutzungshinweise und eine Detail-Ansicht
für Ankündigungen.
5.1 Integration
Wie bei der Bewertung des ZK-Prototypen bereits erwähnt (siehe 4.5.2.8 auf Seite 37), verursachte das Einbinden der ZK-Bibliotheken in das JCommSy-System keine Probleme. Es ist
sogar möglich, die bisherige und die neue Oberflächentechnologie parallel zu betreiben. Dies
hat den Vorteil, dass das JCommSy wie gewohnt benutzt werden kann und parallel dazu die
neue Benutzungsoberfläche entwickelt werden kann, ohne dass mehrere Anwendungen oder
Entwicklungszweige gepflegt werden müssen.
Bei der Migration von PHP nach Java kommt eine Weiche zum Einsatz, die für den Nutzer
einen nahtlosen Übergang zwischen dem Systemteil, der bereits in Java implementiert ist, und
dem PHP-System ermöglicht. Eine solche Weiche kommt für das ZKommSy (JCommSy mit
ZK Oberfläche) nicht in Frage, weil kein nahtloser Übergang möglich ist. Das ZKommSy unterscheidet sich im Aussehen und Verhalten vom PHP-/JCommSy. Ein Wechsel von einer ZKommSy Seite zu einer PHP-/JCommSy Seite wäre für einen Nutzer verwirrend. Um während der
Entwicklungsphase alle Funktionalitäten des CommSy nutzen zu können, habe ich mich dafür
entschieden, beide Oberflächen parallel zu betreiben. Sie sind über verschiedene Pfade auf dem
selben Server erreichbar (PHP-/JCommSy: . . . /Commsy, ZKommSy: . . . /zk/ZKRichlet).
5.1 Integration
41
5.1.1 Schnitt
Beim JCommSy ist die Oberflächentechnologie in einer Architekturschicht, der Präsentationsschicht, gekapselt, d. h. alle darunter liegenden Schichten sind unabhängig von der eingesetzten
Technologie. Von dieser Eigenschaft kann das ZKommSy profitieren, weil diese Schichten wiederverwendet werden können, ohne Anpassungen vornehmen zu müssen. Konkret bedeutet das,
dass Fachlogik, Dienste, Elemente, Fachwerte und Hilfsklassen, also ein Großteil des JCommSy, problemlos auch vom ZKommSy verwendet werden können (siehe Abbildung 3.2 auf Seite
14).
Der einzige Systemteil, der beim Technologieaustausch Veränderungen unterworfen ist, ist die
Präsentationsschicht. Sie enthält einen Teil, der von der Oberflächentechnologie abhängig ist
und einen unabhängigen Teil (siehe Abbildung 5.1 auf Seite 41). Der technologieabhängige
Teil, bestehend aus Servlets, Tags und JSPs, muss in jedem Fall neu implementiert werden. Der
unabhängige Teil ist stark auf die Struktur der angezeigten Seiten angepasst. Er hält die Daten
für die Anzeige in einem vereinfachtem Format bereit.
Präsentationsschicht (detailliert)
servlet
jsp, tag
outfitter
fragment
Technologie
Struktur
Abbildung 5.1: Präsentationsschicht des JCommSy
Eine Wiederverwendung des Struktur-Teils sollte erfolgen, wenn die neue Benutzungsoberfläche
eine ähnliche Struktur aufweist und auf ein vereinfachtes Format der Daten angewiesen ist. Die
Oberfläche des ZKommSy soll direkt auf Elementen arbeiten (direkte Verwendung fachlicher
Klassen, siehe 4.3.3 auf Seite 27) und die Struktur der Seiten soll frei wählbar sein, um die Möglichkeiten der neuen Technologie voll ausschöpfen zu können. Aus diesem Grund habe ich mich
dazu entschieden, eine alternative Präsentationsschicht zu implementieren, ohne den StrukturTeil wiederzuverwenden. Der Austausch der Oberflächentechnologie entspricht dadurch dem
Austausch der Präsentationsschicht des JCommSy (siehe Abbildung 5.2 auf Seite 42).
Es gibt zwei Klassen in der Präsentationsschicht, die nach dem Austausch noch benötigt werden.
Sie haben keine Aufgabe, die an die Präsentation gebunden ist, hängen aber von der gleichen
Technologie ab, wie die Oberfläche des JCommSy. Aus diesem Grund sind sie dieser Schicht
zugeordnet worden. Zum einen handelt es sich um die Klasse RequestListener, sie wird dazu
5.1 Integration
presentation
(JSP)
42
presentation
(ZK)
util
logic
service
item
domainvalue
Abbildung 5.2: Architektur des JCommSy mit parallelen (alternativen) Präsentationsschichten.
benutzt nach jedem bearbeiteten Request die Datenbankverbindung zu schließen. Die andere
Klasse ist ContextListener, die für die Initialisierung der Dienste verantwortlich ist.
Wenn man von diesen Ausnahmen absieht, wird eine Schicht des Systems durch eine neue ersetzt. Es gibt eine klare Grenze zwischen dem Teil, der wiederverwendet wird, und dem Teil,
der neu implementiert wird.
5.1.2 Konguration
Damit die neue Technologie verwendet werden kann, um eine neue Benutzungsoberfläche zu
generieren, müssen einige Einstellungen vorgenommen werden.
Im Deployment Descriptor (web.xml)1 des JCommSy müssen die in Quelltext 5.1 auf Seite 42
gezeigten Zeilen ergänzt werden. Sie sorgen dafür, dass der Server weiß an welche Objekte er
Anfragen an das ZK-Rahmenwerk bzw. die ZK-Benutzungsoberfläche weiterleiten muss. Außerdem wird festgelegt, unter welchem Pfad die ZK-Benutzungsoberfläche bereitgestellt wird.
<listener>
<description>
Used to cleanup when a session is destroyed
</description>
<display-name>ZK Session Cleaner</display-name>
<listener-class>
org.zkoss.zk.ui.http.HttpSessionListener
</listener-class>
1 Ein Deployment Descriptor (Einsatz-Beschreibung) enthält die Konfiguration, um eine Web-Anwendung in einem
Servlet-Container zu starten.
5.1 Integration
43
</listener>
<servlet>
<description>ZK loader for evaluating ZK pages</description>
<servlet-name>zkLoader</servlet-name>
<servlet-class>
org.zkoss.zk.ui.http.DHtmlLayoutServlet
</servlet-class>
<!-- Specifies URI of the update engine(DHtmlUpdateServlet). -->
<init-param>
<param-name>update-uri</param-name>
<param-value>/zkau</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>zkLoader</servlet-name>
<url-pattern>*.zul</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>zkLoader</servlet-name>
<url-pattern>*.zhtml</url-pattern>
</servlet-mapping>
<servlet>
<description>The asynchronous update engine for ZK</description>
<servlet-name>auEngine</servlet-name>
<servlet-class>
org.zkoss.zk.au.http.DHtmlUpdateServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>auEngine</servlet-name>
<url-pattern>/zkau/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>zkLoader</servlet-name>
<url-pattern>/zk/*</url-pattern>
</servlet-mapping>
Quelltext 5.1: Konfiguration des ZK-Rahmenwerks im Deployment Descriptor (web.xml).
Ebenfalls im Deployment Descriptor werden die Einstellungen für den Dependency Injection2
Mechanismus von Spring vorgenommen. Die Angaben für die ZK-Benutzungsoberfläche wurden zusammengefasst und in eine Datei (zkContext.xml) ausgelagert. Diese Datei wird, wie
in Quelltext 5.2 auf Seite 44 zu sehen, in den Deployment Descriptor eingebunden.
2 Benötigte
Abhängigkeiten werden bei der Objekterzeugung von Außen (in diesem Fall vom Spring-Rahmenwerk)
beigesteuert und müssen nicht vom erzeugenden oder erzeugten Objekt verwaltet werden.
5.1 Integration
44
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/applicationContext.xml
/WEB-INF/databaseContext.xml
/WEB-INF/jmxContext.xml
/WEB-INF/outfittersContext.xml
/WEB-INF/commandContext.xml
/WEB-INF/announcementOutfittersContext.xml
/WEB-INF/cxf.xml
/WEB-INF/zkContext.xml
</param-value>
</context-param>
Quelltext 5.2: Spring Konfiguration für ZK im Deployment Descriptor (web.xml).
In der Datei zkContext.xml (Quelltext 5.3 auf Seite 44) werden die einzelnen Abhängigkeiten
der Oberflächen-Klassen angegeben, so dass Spring dazu in der Lage ist, Objekte von ihnen zu
erzeugen.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<!-- PortalOverview -->
<bean id="portalOverview"
class="de.unihamburg.informatik.jcommsy.zk.pages.PortalOverview"
scope="prototype">
<constructor-arg ref="portalService" />
</bean>
<!-- PortalLogin -->
<bean id="portalLogin"
class="de.unihamburg.informatik.jcommsy.zk.pages.PortalLogin"
scope="prototype">
<constructor-arg ref="userService" />
</bean>
<!-- RoomDetail -->
<bean id="roomDetail"
class="de.unihamburg.informatik.jcommsy.zk.pages.RoomDetail"
scope="prototype">
<constructor-arg ref="userService" />
<constructor-arg ref="announcementService" />
</bean>
5.1 Integration
45
<!-- RoomsOverview -->
<bean id="roomsOverview"
class="de.unihamburg.informatik.jcommsy.zk.pages.RoomsOverview"
scope="prototype">
<constructor-arg ref="roomService" />
</bean>
<!-- AnnouncementDetailPage -->
<bean id="announcementDetailPage"
class=
"de.unihamburg.informatik.jcommsy.zk.pages.AnnouncementDetailPage"
scope="prototype">
<constructor-arg ref="announcementService" />
<constructor-arg ref="appointmentService" />
<constructor-arg ref="groupService" />
<constructor-arg ref="materialService" />
<constructor-arg ref="todoService" />
<constructor-arg ref="discussionService" />
<constructor-arg ref="linkService" />
</bean>
</beans>
Quelltext 5.3: Dependency Injection Konfiguration (zkContext.xml).
Die Konfiguration des ZK-Rahmenwerks erfolgt in einer optionalen Datei (zk.xml). Wenn Einstellungen von den Standardwerten abweichen sollen, muss man sie in dieser Datei spezifizieren.
Das ZKommSy hat dort, wie in Quelltext 5.4 auf Seite 45 zu sehen, den Einstiegspunkt ins System (Richlet) und den Pfad, unter dem dieser erreichbar ist, konfiguriert.
<zk>
<richlet>
<richlet-name>ZKRichlet</richlet-name>
<richlet-class>
de.unihamburg.informatik.jcommsy.zk.ZKRichlet
</richlet-class>
</richlet>
<richlet-mapping>
<richlet-name>ZKRichlet</richlet-name>
<url-pattern>/ZKRichlet</url-pattern>
</richlet-mapping>
</zk>
Quelltext 5.4: Konfiguration des ZK-Rahmenwerks (zk.xml).
Das Einbinden einer eigenen CSS-Datei erfolgt im Java-Quelltext. Ein Beispiel wird in Quelltext 5.5 auf Seite 46 gezeigt. In der angegebenen CSS-Datei können neue Stile definiert oder
ZK-eigene überschrieben werden. Jedem ZK-Objekt kann im Java-Quelltext einer dieser Stile
zugewiesen werden. Es ist ebenfalls möglich in der Datei zk.xml den Standard-Stil für eine
ZK-Klasse zu ändern, diese Änderung gilt dann für alle Objekte dieser Klasse.
5.2 Benutzungsoberfläche
46
final Style style = new Style("css/ZKommSy.css");
style.setPage(page);
final Button okButton = new Button("Ok");
okButton.setSclass("myButtonStyleInCss");
okButton.setPage(page);
Quelltext 5.5: Einbinden einer CSS-Datei.
5.2 Benutzungsoberäche
Bei der Migration des CommSy von PHP nach Java wird darauf geachtet, die Benutzungsoberfläche des PHP-CommSy mit Java-Mitteln genau nachzubauen. Dieser Anspruch wurde nicht für
die Benutzungsoberfläche des ZKommSy übernommen. Vielmehr sollen alle Möglichkeiten, die
die neue Technologie bereithält, ausgenutzt werden. Dies hat dazu geführt, dass die Aufteilung
der einzelnen Seiten ähnlich zu der des PHP-/JCommSy ist, aber das Aussehen und Verhalten
teilweise abweicht.
Die Entwicklung der neuen Oberfläche musste in einem begrenzten Zeitrahmen erfolgen (November/Dezember 2008). Aus diesem Grund stehen nicht alle Rubriken und Funktionen, die im
JCommSy zur Verfügung stehen, auch im ZKommSy zur Verfügung. Einige Funktionen wurden
nur rudimentär realisiert, um die Machbarkeit zu demonstrieren und um mit dem System arbeiten
zu können. Dies gilt für die Portalübersicht, den Anmeldemechanismus und die Raumübersicht
(siehe Abbildung 5.3 auf Seite 48).
Andere Funktionen wurden nur auf der Benutzungsoberfläche angedeutet, haben aber keine Implementation hinterlegt. In diese Kategorie fallen die ausführbaren Aktionen, die Such-Funktion
und die Rubriken Termine und Gruppen (auf den Abbildungen 5.4 auf Seite 49 und 5.5 auf Seite
49 durch rote Rechtecke hervorgehoben).
Für die ausimplementierten Aspekte gilt, dass bewusst wenig Zeit in das Layout investiert wurde,
weil die grafische Gestaltung einer Anwendung in der Regel zeitintensiv ist und für diese Arbeit
nur eine untergeordnete Rolle spielt. Es wurde eine Hauptseite realisiert, die eine Übersicht über
einen betretenen CommSy-Raum bietet (siehe Abbildung 5.4 auf Seite 49). Für jede Rubrik
des CommSy ist ein Reiter vorgesehen, der wiederum eine Übersicht der jeweiligen Elemente
enthält. Der Ankündigungen Reiter enthält eine Liste aller erstellten Ankündigungen, die sich
sortieren lässt und deren Größe wählbar ist.
Jede Ankündigung ist auswählbar und verfügt über eine Detailansicht (siehe Abbildung 5.5 auf
Seite 49). Die Verknüpfung von Elementen untereinander (Netznavigation) ist ebenfalls realisiert.
Ein wesentlicher Unterschied zum PHP-/JCommSy, in Bezug auf die Struktur der Benutzungsoberfläche, ist in der Detailansicht eines Elements zu finden. Bisher wurde für die Detailansicht
eine neue Seite aufgebaut, die wie die Übersichtsseite aussah, wo jedoch die Liste der Elemente
durch die Informationen des ausgewählten Elements ersetzt wurde. Beim ZKommSy werden für
Detailansichten neue Fenster innerhalb der selben Seite angezeigt. Sie sind frei verschiebbar und
5.3 Technische Interaktion
47
es können mehrere gleichzeitig geöffnet werden. Die Hauptseite bleibt die ganze Zeit über im
Hintergrund sichtbar und muss nicht neu geladen werden, wenn man eine Detailansicht wieder
verlässt.
Ein weiterer Punkt, der zu einer besseren Bedienbarkeit durch den Nutzer beitragen soll, ist
das Verhalten beim Wechsel von einer Rubrik zu einer anderen. Bisher war ein Wechsel der
Rubrik ein Aufruf einer neuen Seite. Im ZKommSy wird nur ein anderer Reiter sichtbar gemacht,
ohne dass die Informationen der vorherigen Rubrik (Reiter) auf Nutzerseite verloren gehen. Dies
hat zur Folge, dass das Zurückwechseln ohne Zeitverlust durch Client-Server-Kommunikation
erfolgen kann.
Die Reaktionszeit der Elementlisten wurde ebenfalls verbessert. Bisher wurde für das Anzeigen
eines neuen Satzes von Elementen eine neue Seite vom Server angefordert. Beim ZKommSy
wird immer ein weiterer Satz an Daten zwischengespeichert und bereits angeforderte Daten
gehen nicht verloren (Cache). Dies erlaubt ein schnelles Blättern durch die Liste von Elementen
in beide Richtungen.
5.3 Technische Interaktion
Der Aufruf der ZKommSy-Anwendung durch den Browser eines Nutzers, führt auf dem Server
dazu, dass ein neues Objekt der ApplicationInstance-Klasse erzeugt wird. Alle Anfragen
des Nutzers werden im Folgenden von diesem Objekt verarbeitet.
Das ApplicationInstance-Objekt erzeugt die grafischen Komponenten und deren unterliegende Modelle, um sie an den Browser auszuliefern. Interaktionen des Benutzers mit diesen
Komponenten resultieren in Akutalisierungsanfragen. Diese Anfragen werden von der UpdateEngine des ZK-Rahmenwerks verabeitet. Die Modelle der grafischen Komponenten werden verändert und der neue Zustand an den Browser übermittelt. Gegebenenfalls werden neue Komponenten und Modelle erstellt und ausgeliefert.
5.4 Zusammenfassung
Bei der Realisierung der neuen Benutzungsoberfläche konnten fast alle Systemteile der JCommSy wiederverwendet werden. Die alte Präsentationsschicht wird durch eine neue mit dem ZKRahmenwerk entwickelte Präsentationsschicht ausgetauscht. Bis diese Schicht vollständig ist,
können beide Oberflächen parallel betrieben werden.
Die Konfiguration des ZK-Rahmenwerks wurde beschrieben, genauso wie die Funktionen, die
im Rahmen dieser Diplomarbeit implementiert werden konnten. Unterschiede zum PHP- und
JCommSy wurden dabei benannt.
Die neue Benutzungsoberfläche soll den Anwendern eine bessere Bedienbarkeit bieten, dies
wurde unter anderem durch verbesserte Reaktionszeiten und die Verwendung von Fenstern vorangetrieben.
5.4 Zusammenfassung
(a) Portalübersicht
(b) Anmeldemechanismus
(c) Raumübersicht
Abbildung 5.3: Rudimentär implementierte Funktionen des ZKommSy.
48
5.4 Zusammenfassung
Abbildung 5.4: Hauptseite des ZKommSy.
Nicht implementierte Funktionen sind rot hervorgehoben.
Abbildung 5.5: Detailansicht einer Ankündigung.
Nicht implementierte Funktionen sind rot hervorgehoben.
49
Kapitel 6 Auswirkungen des Technologiewechsels
50
Kapitel 6
Auswirkungen des Technologiewechsels
Der Austausch der Oberflächentechnologie wurde im vorangegangenen Kapitel beschrieben.
Die Auswirkungen auf die, im Fokus dieser Arbeit stehenden, softwaretechnischen Aspekte –
Testbarkeit, Entwicklungskomplexität und Architektur – werden in diesem Kapitel beschrieben.
Dafür wird die Anwendung vor dem Austausch (JSP-Technologie) und nach dem Austausch
(ZK-Technologie) analysiert und bewertet. Für die Nachher-Analyse wird nicht der Parallelbetrieb von JSP- und ZK-Oberfläche angenommen, sondern ausschließlich das ZKommSy. Bewertet werden nicht nur direkte, sondern auch indirekte Folgen des Technologieaustauschs.
Die zusätzlichen Möglichkeiten, die das ZKommSy bietet, werden nicht betrachtet. Jene Aspekte
werden im Ausblick (Kapitel 7.2 auf Seite 67) behandelt.
6.1 Testbarkeit
Um die entstandenen Auswirkungen zu bestimmen und zu bewerten, wird als erstes die Testbarkeit des JCommSy, vor und nach dem Technologiewechsel, genauer betrachtet. Von den
Testarten, die in Kapitel 2.1.1 Testen genannt werden, wird für die Testbarkeit nur der Komponententest betrachtet. Diese Testart hat direkten Einfluß auf die Programmiertätigkeit, weil
der Fokus dieser Tests auf der gleichen Abstraktionsebene liegt.
Folgende Aspekte gehören zur Testbarkeit:
• Kann ein Systemteil bzw. eine Funktion getestet werden?
• Wie lange dauert ein Test?
• Können die Tests einfach und direkt formuliert werden oder müssen Umwege beschritten
werden, um eine Funktionalität zu testen? Ein Test mit Umweg wäre z. B. ein Test, der
eine Komponente testen soll und dafür ein Reihe von Arbeitsschritten in der Anwendung
ausführt, anstatt die Komponente zu erzeugen und die entsprechenden Operationen an
diesem Objekt aufzurufen.
• Können bestimmte Entwicklungsmethoden und Techniken angewendet werden (z. B. Extreme Programming1 oder Test-Driven-Development2 )?
Die Testbarkeit einer Anwendung ist aus verschiedenen Gründen wichtig:
1 Extreme Programming ist eine agile Vorgehensweise (in der Softwareentwicklung) nach Beck und Andres [BA04].
2 Test-Driven-Development
steht für die testgetriebene Entwicklung einer Anwendung nach Beck [Bec02].
6.1 Testbarkeit
51
Qualitätsmerkmal:
Tests können als Qualitätsmerkmal für eine Anwendung herangezogen
werden. Dies gilt für die Auftraggeber, das Management und die Entwickler gleichermaßen. Der Auftraggeber kann sicherstellen, dass die von ihm gewünschte Funktionalität
verfügbar und korrekt implementiert ist. Das Management kann aus den Testergebnissen
Rückschlüsse auf den Status einer Anwendung ziehen, ohne Detailkenntnisse zu haben.
Die Entwickler können Vertrauen zur Anwendung aufbauen und Änderungen durchführen, weil sie die Möglichkeit haben, jederzeit zu überprüfen, ob die Anwendung sich so
verhält, wie es durch die Tests vorgegeben ist.
Abstraktion:
Das Formulieren der Tests stellt eine andere Sicht auf das zu lösende Problem
dar, als die eigentliche Programmiertätigkeit. Von den einzelnen Schritten zur Berechnung
des Problems wird abstrahiert und die zu testende Funktionalität als Black-Box betrachtet. Die Spezifikation der gewünschten Funktionalität steht dabei im Vordergrund. Diese
Abstraktion unterstützt den Entwickler u. a. dabei, das Geheimnisprinzip (nach Parnas
[Par72]) zu wahren.
Kommunikation:
Die Tests kommunizieren das gewünschte Verhalten einer Anwendung. Für
Entwickler stellen die Tests einen Teil der Dokumentation der Anwendung dar (siehe Beck
und Andres [BA04, S. 26, 97]).
Wartung:
Wenn eine Anwendung das Stadium der Wartung erreicht hat, ist es besonders wichtig, auf Tests zurückgreifen zu können. Der Quelltext kann auch noch nach langer Zeit
verändert werden, ohne Seiteneffekte im System befürchten zu müssen, da die Tests diese
aufdecken würden (siehe Beck und Andres [BA04, S. 26, 97]). Beim Beheben von Fehlern
in der Anwendung kann man ein erneutes unbemerktes Auftreten des Fehlers verhindern,
indem zuerst ein Test geschrieben wird, der den Fehler aufdeckt, und den Fehler danach
beseitigt.
Vorgehensmodelle:
Es gibt Vorgehensmodelle, bzw. Techniken die ohne Tests nicht bzw.
nicht sinnvoll anwendbar sind. Ein Beispiel: Wenn man eine Anwendung agil3 entwickeln
möchte, kommen verschiedene Techniken zum Einsatz, auf die dies zutrifft. Beispielsweise sind Test-Driven-Development und größere Refactorings ohne Komponententests nicht
möglich, gemeinsamer Quelltext und kontinuierliche Integration werden durch die Anwesenheit von Tests erleichtert. Ein Überblick über diese Techniken wird in Beck und Andres
[BA04] gegeben.
Feedback:
Das Ausführen eines Test gibt dem Entwickler direktes Feedback, ob der geschriebene Quelltext wie gewünscht arbeitet. Weicht das Verhalten ab, erleichtert dieses Feedback die Fehlersuche (siehe Beck und Andres [BA04, S. 50-51]). Je schneller die Tests
ausgeführt werden können, desto öfter und direkter erhält der Entwickler dieses Feedback.
3 Agile
Softwareentwicklung ist ein Sammelbegriff für Techniken und Vorgehensmodelle, die dem agilen Manifest
(siehe http://www.agilemanifesto.org/) entsprechen. Leichtgewichtigkeit und menschliche Bedürfnisse stehen im
Vordergrund.
6.1 Testbarkeit
52
6.1.1 Vor dem Technologiewechsel
Im JCommSy kommen verschiedene Test-Rahmenwerke zum Einsatz, um verschiedene Bereiche der Anwendung zu testen.
Der Java-Quelltext wird mit Hilfe von Komponententests überprüft, dafür werden die Rahmenwerke JUnit4 und Cactus5 verwendet. Es werden nicht alle Java-Methoden getestet, obwohl dies
in den meisten Fällen möglich wäre. Dies liegt daran, dass viele verschiedene Entwickler mit
verschiedenen Ansichten und Erfahrungsständen am JCommSy mitgewirkt haben und es versäumt wurde, entsprechende Tests zu schreiben.
Um zu ermitteln, wie viel vom Java-Quelltext durch die vorhandenen Tests abgedeckt wird,
kommt das Analyse-Werkzeug Cobertura6 zum Einsatz. Laut dem Werkzeug liegt die Zeilenabdeckung (Prozentsatz der Quelltextzeilen, die während der Tests durchlaufen werden) bei 59
Prozent und die Zweigabdeckung (Prozentsatz der bedingten Anweisungen und Verzweigungen, die während der Tests durchlaufen werden) bei 71 Prozent. Zu beachten ist, dass Cobertura
in der aktuellen Konfiguration die Tests, die mit dem Cactus-Rahmenwerk durchgeführt werden, nicht berücksichtigt. Die ermittelten Werte beziehen sich auf den Java-Teil des Systems
und nicht auf das Gesamtsystem.
Die Dauer eines kompletten Testdurchlauf (∼1000 Tests) beträgt momentan ca. 30 Sekunden.
Das ergibt einen Durchschnitt von 0, 03 Sekunden pro Test.
Der JSP-Quelltext kann nicht direkt getestet werden. Beim JCommSy behilft man sich, indem
die erzeugte Oberfläche durch Akzeptanztests geprüft wird. Diese Tests führen Operationen auf
Benutzereingabe-Ebene aus und überprüfen das Resultat. Durch dieses Verfahren kann der JSPQuelltext indirekt mit getestet werden. Es ist aber nicht möglich, einzelne Teile gezielt zu testen (wie bei Java-Quelltext über Methoden), da der JSP-Quelltext immer als Ganzes in HTML
übersetzt wird. Was überprüft werden kann, ist die HTML-Ausgabe. Dies geschieht zum einen
mit dem Tidy7 -Rahmenwerk, dass überprüft, ob der generierte HTML-Quelltext eine korrekte
Syntax hat, und zum anderen mit dem HttpUnit8 -Rahmenwerk, dass für Akzeptanztests verantwortlich ist.
Die Dauer eines kompletten Testdurchlauf (∼30 Tests) beträgt momentan ca. 900 Sekunden.
Das ergibt einen Durchschnitt von 30 Sekunden pro Test.
Das restliche System wird nicht gezielt getestet, dazu gehören das Hibernate-Mapping9 , die
CSS-Dateien, der JavaScript-Quelltext und die übrigen Konfigurationsdateien. Die Akzeptanztests stellen lediglich sicher, dass die Anwendung gestartet werden kann und somit keine schwerwiegenden Fehler existieren. Für die meisten genannten Bereiche gibt es Möglichkeiten, direkt
zu testen: Hibernate-Mappings lassen sich per Komponententests testen (JUnit), die CSS-Stile
mit Hilfe von CSSTidy10 und der JavaScript-Quelltext mittels JSUnit11 . Die Konfigurationen
4 http://www.junit.org/
5 http://jakarta.apache.org/cactus/
6 http://cobertura.sourceforge.net/
7 http://jtidy.sourceforge.net/
8 http://httpunit.sourceforge.net/
9 Abbildung
von Java-Objekten auf Tabellen und Spalten in einer relationalen Datenbank.
10 http://csstidy.sourceforge.net/
11 http://www.jsunit.net/
6.1 Testbarkeit
Java
Hibernate
Mapping
Konfiguration
(XML + Properties)
53
JSP
+
TagBibliotheken
CSS
einfach und
direkt testbar
nur indirekt oder
teilweise testbar
Java
Script
Abbildung 6.1: Testbarkeit des JCommSy (Größe der Systemteile entspricht einer Abschätzung
der Wichtigkeit und des Umfangs im realen System. Die Anordnung dient der
Übersichtlichkeit.)
lassen sich teilweise durch Schema-Beschreibungen auf korrekte Syntax überprüfen.
Das Anwenden von agilen Vorgehensmodellen (z. B. SCRUM12 oder Extreme Programming)
und den damit verbundenen Techniken ist möglich, da ein Großteil des Systems durch Tests abgedeckt ist. Dies bietet ausreichend Sicherheit, um z. B. Refactorings durchzuführen. Bestimmte
Techniken, wie beispielsweise Test-Driven-Development, können nur auf den Java-Teil des Systems angewendet werden.
Die Testbarkeit des JCommSy wird in Abbildung 6.1 auf Seite 53 noch einmal verdeutlicht.
6.1.2 Nach dem Technologiewechsel
Durch den Technologiewechsel hat sich für den Java-Teil des Systems nichts verändert, wenn
man davon absieht, dass er größer geworden ist. Die Oberfläche ist nun ebenfalls in Java beschrieben und kann mit den bereits erwähnten Mitteln getestet werden.
Die Ausführungsdauer und die Anzahl der Tests hat sich nicht wesentlich verändert.
Der JSP-Teil des Systems fällt durch den Technologiewechsel weg. Die neue Technologie arbeitet nicht mehr mit einzelnen HTML-Seiten, die ausgeliefert werden, sondern tauscht Datenobjekte per JavaScript aus und die neue Oberfläche unterscheidet sich von der alten, wie in Kapitel
5.2 auf Seite 46 beschrieben. Aus diesen Gründen funktionieren die Akzeptanztests nicht mehr
und müssen angepasst werden. Bei diesem Schritt wäre ein Wechsel des Test-Rahmenwerks
von HttpUnit auf das aktuellere HtmlUnit13 sinnvoll. Auf eine Anpassung im Rahmen dieser
Arbeit wurde verzichtet, da die indirekten Tests des JSP-Quelltexts durch direkte Komponententests des Java-Quelltexts der Oberfläche ersetzt wurden. Genau wie bei der Entwicklung des
12 Agiles
Vorgehensmodell nach Schwaber [Sch04b].
13 http://htmlunit.sourceforge.net/
6.1 Testbarkeit
54
einfach und
direkt testbar
Java
nur indirekt oder
teilweise testbar
Hibernate
Mapping
Konfiguration
(XML + Properties)
CSS
Abbildung 6.2: Testbarkeit des ZKommSy (Größe der Systemteile entspricht einer Abschätzung
der Wichtigkeit und des Umfangs im realen System. Die Anordnung dient der
Übersichtlichkeit.)
JCommSy, haben auch in dieser Arbeit die Komponententests Vorrang vor den Akzeptanztests,
aufgrund ihres großen Einflusses auf die Entwicklungstätigkeiten. Die erzeugte Benutzeroberfläche (HTML-Ausgabe) wird auch nicht mehr durch das Tidy-Rahmenwerk auf korrekte Syntax
überprüft. Es ist zwar möglich die Ausgabe des ZK-Rahmenwerks mit Tidy zu überprüfen, ist
aber nicht sinnvoll, da man bei der Beschreibung der Benutzungsoberfläche im Java-Quelltext
keinen direkten Einfluss auf die Syntax der späteren HTML-Ausgabe hat. Das Rahmenwerk
verbirgt diese Details vor dem Benutzer, und das ist auch gut so.
Für das restliche System hat sich nur eine Änderung ergeben: Es gibt keinen JavaScript-Teil
mehr. Alle benötigten JavaScript-Funktionalitäten werden vom ZK-Rahmenwerk bereitgestellt
und müssen nicht mehr selbst implementiert werden.
Die oben genannten Entwicklungsmethoden und Techniken lassen sich nun besser anwenden,
da ein größerer Teil des Systems durch Komponententests abgedeckt ist. Es ist sogar möglich
die Oberfläche nach dem Test-Driven-Development-Ansatz zu entwickeln.
Die Testbarkeit des ZKommSy wird in Abbildung 6.2 auf Seite 54 noch einmal verdeutlicht.
6.1.3 Fazit
Die Testbarkeit des JCommSy wurde durch den Austausch der Oberflächentechnologie verbessert. Bisher gut testbare Systemteile sind nach wie vor gut testbar. Ein schlecht testbarer Teil
(JSP-Quelltext) wurde durch gut testbaren Java-Quelltext ersetzt. Die Tests der Oberfläche sind
jetzt schneller und direkter, was besonders wichtig für regelmäßiges Feedback ist. Die Rahmenbedingungen für das Anwenden von agilen Vorgehensmodellen wurde verbessert, auch für die
Oberfläche ist jetzt ein Vorgehen nach Test-Driven-Development möglich.
Veranschaulicht wird das Ergebnis durch einen Vergleich der beiden Abbildungen 6.1 auf Seite
53 und 6.2 auf Seite 54: Der Grün-Anteil beim ZKommSy ist größer als beim JCommSy.
6.2 Entwicklungskomplexität
55
Aufgrund der Entscheidung, dass die neue Benutzungsoberfläche im HTML-Quelltext von der
bisherigen Benutzungsoberfläche abweichen darf, funktionieren die vorhandenen Akzeptanztests (ca. 30 Stück) nicht mehr. Es ist aber möglich diese Tests anzupassen, so dass sie mit der
neuen Oberfläche arbeiten können.
Die Testbarkeit der Anwendung wurde um das gleiche Maß verbessert, um das der Java-Anteil
der Anwendung erhöht wurde. Die Arbeitshypothese 1 (siehe Seite 26) wurde für den Aspekt
der Testbarkeit bestätigt.
6.2 Entwicklungskomplexität
Die Auswirkungen des Technologiewechsels auf die Entwicklungskomplexität werden durch
einen Vergleich der Situation vor und nach dem Wechsel bestimmt und bewertet. Ein Aspekt
der Entwicklungskomplexität, die Komplexität der fachlichen Anforderungen, kann nicht durch
einen Technologiewechsel beeinflusst werden und wird deshalb nicht betrachtet.
Um einen direkten Vergleich zu ermöglichen, werden die meisten Beobachtungen in Zahlen
gefasst. Die Entstehung und Aussagekraft der Werte wird im Einzelnen erläutert.
6.2.1 Vor dem Technologiewechsel
Das JCommSy umfasst ca. 95.000 Zeilen Quelltext, die sich verschiedenen Teilsystemen zuordnen lassen. Eine Übersicht wird in Tabelle 6.1 auf Seite 55 gegeben. Die Werte wurden ermittelt,
indem für jede Quelltext-Datei die Zeilenanzahl aufaddiert wurde. Eine Unterscheidung, ob die
jeweiligen Zeilen leer waren, nur eine Klammer oder nur einen Kommentar enthielten, wurde nicht vorgenommen. Die Werte sollen als Anhaltspunkt für die Größe eines Systemteils im
Verhältnis zu anderen Systemteilen dienen.
Teilsystem
Java
Properties
JSP
Tag-Bibliotheken
XML
JavaScript
Hibernate Mapping
Sonstiges
CSS
Summe
Zeilen
74.753
7.057
4.198
3.227
2.815
1.064
941
708
612
95.375
Dateien
634
9
45
20
22
3
31
5
1
770
Anteil in %
78,4
7,4
4,4
3,4
3,0
1,1
1,0
0,7
0,6
100,0
Tabelle 6.1: Anzahl der Quelltextzeilen pro Teilsystem des JCommSy.
6.2 Entwicklungskomplexität
56
Bei der Entwicklung und dem Betrieb des JCommSy werden verschiedene Technologien14 verwendet. Um zu ermitteln, wie viele es sind, wurden alle eingebundenen Bibliotheken und externen Anwendungen gezählt. Die eingebundenen Bibliotheken konnten teilweise zusammengefasst werden, weil sie zur selben Technologie gehörten. Es wurden nur Bibliotheken berücksichtigt, die direkt benutzt wurden. Für den Java-Teil konnte dies durch Auswertung der
import-Anweisungen überprüft werden. Der so ermittelte Wert kann als Größenordnung und
Vergleichswert herangezogen werden.
Insgesamt wurden 32 verschiedene Technologien gezählt. Davon sind 21 eingebundene Bibliotheken (Activation, AjaxAnyWhere, Axis, Cactus, Commons BeanUtils, Commons FileUpload, Commons IO, CXF, EasyMock, EhCache, Hibernate, HttpUnit, Java EE, JAX-RPC,
JUnit, Log4J, SAX, JSP, Spring, Tidy und WSS4J).
Die restlichen 11 Technologien sind externe Anwendungen:
• Ant kompiliert die Anwendung und liefert sie aus.
• Apache fungiert als Webserver.
• Checkstyle hilft bei der Einhaltung der Quelltextkonventionen.
• Cobertura überprüft die Testabdeckung.
• CruiseControl dient als Werkzeug der kontinuierlichen Integration.
• Eclipse wird als Entwicklungsumgebung genutzt.
• Findbugs unterstützt die Entwickler bei der Fehlervermeidung.
• MySQL dient als Datenbank.
• PHP-CommSy übernimmt die nicht in Java implementierten Funktionalitäten.
• Subversion fungiert als Versionsverwaltung des Projekts.
• Tomcat ist der Servlet-Container des JCommSy.
Die bereits in Kapitel 6.1 Testbarkeit vorgenommene Aufteilung des JCommSy in verschiedene
Teilsysteme legt nahe, dass das JCommSy nicht vollständig in Java beschrieben ist (siehe Abbildung 6.1 auf Seite 53). Es kommen insgesamt 6 Entwicklungssprachen zum Einsatz. Java,
um die Anwendung selbst zu entwickeln. JSP15 und Hypertext Markup Language (HTML) für
die Beschreibung der Benutzungsoberfläche. JavaScript dient als Sprache bei der Entwicklung
von eigenen Animationen und Funktionen für die HTML-Oberfläche. Die Extensible Markup Language (XML) wird in verschiedenen Dialekten für Konfigurationsdateien und die TagBibliotheken eingesetzt. Als Formatierungssprache wird Cascading Style Sheets (CSS) verwendet.
14 Auffassung
des Technologiebegriffs in dieser Arbeit: Eine Technologie stellt eine Funktionalität bereit. Verschiedene Technologien unterscheiden sich durch Art der Benutzung und Art der Funktionalität.
15 JSP ist sowohl die Bezeichnung für die Technologie, als auch für die dort verwendete Sprache.
6.2 Entwicklungskomplexität
57
Bei so vielen verschiedenen Technologien und Entwicklungssprachen wundert es nicht, dass
die Anzahl der Konfigurationsdateien ebenfalls groß ist. Insgesamt 65 Konfigurationsdateien
konnten ausgemacht werden. Jede davon steuert einen anderen Teil des JCommSy. Hibernate
wird durch 33 Dateien konfiguriert, die Spring Konfiguration befindet sich in 10 Dateien und die
restlichen Technologien und Anwendungen verteilen sich auf 22 weitere Konfigurationsdateien.
Nachdem ein Überblick gegeben wurde, was für Anstrengungen von den Entwicklern bewältigt werden müssen, um am JCommSy zu arbeiten, werden nun die entlastenden Faktoren besprochen. Die Werkzeugunterstützung ist für die verschiedenen Systemteile des JCommSy unterschiedlich gut. Im Java-Teil stehen viele ausgereifte und anpassbare Mechanismen zur Verfügung, z. B. Autovervollständigung, Syntax-Hervorhebung, automatische Quelltexterzeugung,
Typhierarchie, Aufrufhierarchie, Quickfixes und das Einblenden von JavaDoc-Texten. Das Anwenden von verschiedenen Refactorings ist ebenfalls möglich, bekannte Vertreter sind das Umbenennen oder Verschieben eines Artefakts, Extrahieren eines Interfaces und das Umwandeln
einer lokalen Variable in ein Feld.
Die Werkzeugunterstützung für die anderen Systemteile ist schlechter. Beim Entwickeln der
JSP-Dokumente muss sich der Entwickler mit Syntax-Hervorhebung, Dokumentationseinblendungen und einer rudimentären Autovervollständigung abfinden. Refactorings stehen nicht zur
Verfügung. Die Refactorings des Java-Teils sind aber dazu in der Lage, Änderungen auch auf
alle Text-enthaltenden Dateien anzuwenden (einschließlich JSP-Dokumente). Dieser Vorgang
ist jedoch fehlerträchtig und muss vom Entwickler sorgfältig überwacht werden. Das gleiche
gilt für alle XML-Dokumente, einschließlich der Tag-Bibliotheken und Hibernate Mappings. In
den Properties-Dateien muss man sich mit Syntax-Hervorhebung begnügen. Beim Bearbeiten
von CSS- oder JavaScript-Dateien hat man zusätzlich noch eine ausgeprägte Autovervollständigung. Zusammenfassend kann man sagen, dass die Werkzeugunterstützung für das JCommSy
größtenteils sehr gut ist, ausgenommen sind die Bereiche JSP, Konfiguration und die Hibernate
Mapping.
Einzelne Aspekte ließen sich durch andere/weitere Werkzeuge oder Erweiterungen verbessern,
den JCommSy-Entwicklern stehen solche aber nicht zur Verfügung.
In Bezug auf Vorgehensmodelle und Techniken unterliegt das JCommSy kaum Einschränkungen. Lediglich die eingeschränkte Testbarkeit erschwert ein Vorgehen nach dem Test-DrivenDevelopment-Ansatz, bzw. das Anwenden von agilen Techniken.
Ein weiteres Mittel zur Entlastung der Entwickler ist das Verwenden und Bereitstellen von Abstraktionen. Beim JCommSy finden sich Abstraktionen in Form von einer Architekturbeschreibung und dem Gebrauch von Entwurfsmustern. Die aktuellste Architekturbeschreibung stammt
aus der Diplomarbeit von Henning Schwenter [Sch08], siehe auch Kapitel 3.1 auf Seite 12. Sie
findet sich teilweise in der Java-Package-Struktur der Java-Klassen wieder. Nicht-Java-Elemente
werden nicht mit beschrieben. In einigen Punkten weicht die beschriebene Architektur von der
Ist-Architektur des JCommSy ab. Die Architekturbeschreibung stellt eine gute Abstraktion der
JCommSy-Anwendung dar, auch wenn sie nicht in allen Details korrekt ist.
Entwurfsmuster kommen an verschiedenen Stellen im Java-Quelltext vor. Beispielsweise wird
für die Fragmente das Composite-Muster nach Gamma [GHJV94] verwendet und in der Klasse
AbstractIndexOutfitter das Factory-Method-Muster, ebenfalls nach Gamma.
6.2 Entwicklungskomplexität
58
Die Dokumentation des JCommSy ist teilweise gut und teilweise nicht vorhanden. Das gilt für
alle Systemteile des JCommSy gleichermaßen. Die Quelltext-Kommentare in Java-, JSP- und
Konfigurationsdateien sind in der Regel sehr hilfreich. Es gibt aber auch Dateien, in denen kein
einziger Kommentar zu finden ist.
Da Komponententests das gewünschte Verhalten einer Anwendung dokumentieren, können die
Tests des JCommSy vorhandene Quelltext-Kommentare ergänzen und fehlende teilweise ausgleichen.
Die Dokumentation außerhalb des Quelltexts ist nicht immer aktuell. Die für das Entwickeln am
JCommSy vorhandenen Anleitungen sind seit längerer Zeit nicht mehr angepasst worden, bieten
einem Entwickler aber dennoch Hilfestellung. Aktuellere Dokumente werden in einer laufenden
CommSy-Anwendung16 gesammelt und können dort eingesehen werden.
Der letzte entlastende Faktor ist die Modularisierung17 . Das JCommSy ist strukturiert aufgebaut und es gibt viele Komponenten, die sich wiederverwenden lassen, z. B. wenn eine weitere
Rubrik in Java implementiert werden soll. Die Entkopplung der einzelnen Komponenten wurde
zuletzt durch die Diplomarbeit von Henning Schwenter vorangetrieben, indem die Technologieabhängigkeit der Oberflächenklassen reduziert wurde.
6.2.2 Nach dem Technologiewechsel
Beim Austausch der Oberflächentechnologie und der Neuimplementierung der Benutzungsoberfläche wurde nur ein Teil des JCommSy verändert. Die daraus entstandenen Veränderungen an
der Entwicklungskomplexität werden im Folgenden erläutert. Alle nicht angesprochenen Aspekte sind unverändert geblieben. Einige der Änderungen sind nicht direkt auf den Technologieaustausch zurückzuführen, sondern auf die Überarbeitung der Architektur (Kapitel 3.2 auf Seite 13)
und das Logik-Refactoring (Kapitel 3.3 auf Seite 16).
Die Anzahl der Quelltextzeilen ist durch den Austausch auf ca. 91.000 (vorher 95.000) zurückgegangen. Die Systemteile JSP, Tag-Bibliotheken, JavaScript und CSS wurden entfernt. Der
XML-Teil ist durch neue Konfigurationsdateien leicht gewachsen. Der Java-Teil ist durch neue
Klassen und Tests stark gewachsen. Die anderen Systemteile sind unverändert geblieben.
Da der Funktionsumfang des ZKommSy noch nicht dem Funktionsumfang des JCommSy entspricht, lassen sich die Zahlen nicht direkt vergleichen. Man muss berücksichtigen, dass der
Java-Teil weiter wachsen wird. Sobald das Design der Anwendung behandelt wird, wird auch
wieder ein CSS-Teil vorhanden sein. Die Gesamtgröße der Anwendung wird bei gleicher Funktionalität über der des JCommSy liegen, u. a. weil es mehr Tests und Quelltext-Kommentare
gibt.
Die Anzahl der eingesetzten Technologien wurde um 2 reduziert. Die Bibliotheken von JSP und
Tidy werden nicht mehr benötigt, dafür kam die ZK-Bibliothek hinzu. Da kein Weichenmechanismus zu einem PHP-CommSy benutzt wird, fällt diese externe Anwendung ebenfalls weg.
Insgesamt sind 30 Technologien im Einsatz.
16 http://free.commsy.de/
17 Modularisierung:
Die einzelnen Komponenten eines Systems wiederverwendbar machen, siehe [Mey97].
6.2 Entwicklungskomplexität
Teilsystem
Java
Properties
XML
Hibernate Mapping
Sonstiges
Summe
Zeilen
79.176
7.057
2.877
941
708
90.759
(vorher)
(74.753)
(7.057)
(2.815)
(941)
(708)
(95.375)
Dateien
661
9
24
31
5
730
(vorher)
(634)
(9)
(22)
(31)
(5)
(770)
59
Anteil in %
87,2
7,8
3,2
1,0
0,8
100,0
(vorher)
(78,4)
(7,4)
(3,0)
(1,0)
(0,6)
(90,4)
Tabelle 6.2: Anzahl der Quelltextzeilen pro Teilsystem des ZKommSy. Werte vor dem Technologietausch in Klammern.
Die verwendeten Entwicklungssprachen wurden durch den Austausch der Oberflächentechnologie auf 3 reduziert. Java wird zur Beschreibung der Anwendung und der Oberfläche verwendet.
XML wird nur noch für das Hibernate Mapping und verschiedene Konfigurationsdateien eingesetzt. Die Formatierungssprache CSS ist ebenfalls geblieben.
Die Zahl der Konfigurationsdateien liegt beim ZKommSy bei 67, ist also um 2 gestiegen. Die
beiden Konfigurationsdateien, die neu hinzugekommen sind, werden in Kapitel 5.1.2 Konfiguration auf Seite 42 beschrieben.
An der Werkzeugunterstützung der einzelnen Systemteile hat sich durch den Austausch nichts
verändert. Da aber einige Teile mit schlechter Werkzeugunterstützung weggefallen sind und der
Systemteil mit der besten Werkzeugunterstützung (Java) gewachsen ist, hat sich die Gesamtsituation in Bezug auf die Werkzeugunterstützung verbessert.
Für die Anwendbarkeit von Vorgehensmodellen und Techniken gilt dasselbe, wie für die Werkzeugunterstützung. Schlecht testbare Systemteile sind entfernt worden und gut testbare gewachsen, wodurch sich die Gesamtsituation in Bezug auf Vorgehensmodelle und Techniken verbessert hat. Beispielsweise ist es jetzt möglich, die Benutzungsoberfläche nach dem Test-DrivenDevelopment-Ansatz mit direkten Komponententests zu entwickeln.
Die verfügbaren Abstraktionen haben sich durch das Überarbeiten der Architektur und das
Logik-Refactoring noch einmal verbessert, nicht durch den eigentlichen Technologieaustausch.
Die Architekturbeschreibung ist umfassender und beinhaltet jetzt auch Nicht-Java-Elemente. Istund Soll-Architektur stimmen überein, was die Abstraktion ebenfalls aufwertet. Die Abbildung
der Architekturbeschreibung auf die Java-Package-Hierarchie, verbessert die Verbindung von
Abstraktion und Abstrahiertem (Quelltext).
Die Verwendung von Entwurfsmustern wurde beim Logik-Refactoring fortgesetzt. Dort findet
das Command-Muster nach Gamma [GHJV94] Anwendung.
Klarere Konventionen und werkzeuggestützte Überprüfung führen zu einer besseren Dokumentation innerhalb des Java-Quelltexts, als in den übrigen Systemteilen. Durch den größeren JavaAnteil hat sich die Dokumentation verbessert.
Die Modularisierung innerhalb der Präsentationsschicht des ZKommSy ist nicht so gut wie die
des JCommSy. Dies liegt hauptsächlich daran, dass im ZKommSy nur eine Rubrik implementiert
ist. Wiederverwendbare Komponenten zu implementieren und zu verwenden, ergibt erst Sinn,
6.3 Architektur
60
wenn die Komponenten mehrfach benötigt werden (siehe Beck [BA04, S. 51-53] in Bezug auf
inkrementelles Design).
6.2.3 Fazit
Die Entwicklungskomplexität des JCommSy wurde durch den Austausch der Oberflächentechnologie reduziert.
1. Die von einem Entwickler zu überwindenden Anstrengungen wurden reduziert:
Die Größe der Anwendung wurde verringert. Aus 9 Teilsystemen wurden 5 (-44%) und aus
95.375 Zeilen Quelltext wurden 90.759 (-5%). Wichtiger ist aber die Reduzierung der Quelltextzeilen, die nicht in Java geschrieben sind, von 20.622 auf 11.583 (-44%). Denn es sind diese
Quelltextzeilen, die schlecht getestet werden können und bei denen der Entwickler wenig durch
Werkzeuge unterstützt werden kann.
Das Senken der eingesetzten Technologien von 32 auf 30 (-6%) und die Erhöhung der Konfigurationsdateien von 65 auf 67 (+3%) machen keinen erkennbaren Unterschied für die Entwicklungskomplexität, da die Veränderungen zu gering sind.
Die Halbierung der Entwicklungssprachen von 6 auf 3 (-50%) sorgt für eine deutlich geringere
Belastung der Entwickler.
2. Die Entlastungen für Entwickler wurden erhöht:
Die Werkzeugunterstützung, die Anwendbarkeit von Vorgehensmodellen und die Dokumentation wurden um das gleiche Maß verbessert, um das der Java-Anteil der Anwendung erhöht
wurde.
Die zur Verfügung stehenden Abstraktionen wurden durch die Überarbeitung der JCommSyArchitektur und das Logik-Refactoring verbessert. Beide Arbeitsschritte dienten der Vorbereitung des Technologieaustauschs.
Die gute Modularisierung des JCommSy konnte nicht vollständig beibehalten werden. Dies liegt
hauptsächlich daran, dass die neue Benutzungsoberfläche noch nicht vollständig implementiert
ist. Eine konsequent fortgesetzte Implementierung, würde zu einer gleichwertigen Modularisierung führen.
Die starke Korrelation von der Verbesserung der einzelnen Aspekte der Entwicklungskomplexität und der Verwendung von Java als Entwicklungssprache bestätigt die Arbeitshypothese 1
(siehe Seite 26).
6.3 Architektur
Die Architektur des JCommSy wurde in dieser Arbeit schon mehrfach beschrieben und diskutiert. Hier werden 3 Versionen von Soll- und Ist-Architektur betrachtet:
1. Die Version vor Beginn dieser Arbeit. Die Soll-Architektur wurde aus der Diplomarbeit
von Henning Schwentner ennommen (siehe Kapitel 3.1 auf Seite 12). Die Ist-Architektur
wurde durch eine Analyse mit dem Sotoarc-Werkzeug ermittelt.
6.3 Architektur
61
2. Die Version nach der Überarbeitung durch Salim Rechenberg, Ilker Daricili und mich zu
Beginn dieser Arbeit (siehe Kapitel 3.2 auf Seite 13). Ist- und Soll-Architektur stimmen
überein.
3. Die Version nach dem Technologieaustausch (ohne Parallelbetrieb; siehe Kapitel 5.1.1 auf
Seite 41). Ist- und Soll-Architektur stimmen überein.
Die Veränderungen von Version 2 zu Version 3 sind nur minimal, da ein problemloser Austausch
der Präsentationsschicht vorgenommen wurde. Aus diesem Grund wird im Vorher-Kapitel von
Version 1 ausgegangen und im Nachher-Kapitel von Version 2. Die beschriebenen Veränderungen stammen zwar nicht direkt aus dem Technologiewechsel, resultieren aber aus den Vorbereitungen dafür.
6.3.1 Vor dem Technologiewechsel
Servlets
Ausstatter
Fragmente
Services
Items
Fachwerte
Abbildung 6.3: Architektur des JCommSy nach Schwentner [Sch08] (Version 1)
Die Soll-Architektur wird in Abbildung 6.3 auf Seite 61 gezeigt. Die Ist-Architektur weicht
in einigen Punkten von dieser Beschreibung ab (Architekturverletzungen). Nicht-Java Teile der
Anwendung werden in dieser Architekturbeschreibung nicht erfasst. Aus der Abbildung wird
ersichtlich, dass es verschiedene Komponenten (Schichten) mit definierten Aufgaben gibt. Genauere Informationen sind in Kapitel 3.1 auf Seite 12 zu finden.
6.3.2 Nach dem Technologiewechsel
Durch die Vorbereitungen für den Technologieaustausch hat sich die Architektur des JCommSy verändert. Eine überarbeitete Architekturbeschreibung ist in Abbildung 6.4 auf Seite 62 zu
sehen. Die Ist- und Soll-Architektur stimmen überein, d. h. es gibt keine Architekturverletzungen mehr. Die Architekturbeschreibung findet sich in vereinfachter Form in der Java-PackageHierarchie des Quelltextes wieder. In dieser Version der Architekturbeschreibung werden ebenfalls einige nicht-Java Anwendungsteile erfasst.
6.3 Architektur
62
Die Fachlogik der Anwendung findet sich in einer eigenen Komponente (Schicht) wieder und
ist nicht mehr über die anderen Schichten verteilt.
Die klare Trennung von Schnittstelle und Implementierung (Entkopplung siehe Stevens, Meyers
und Constantine [SMC79]) der Diensteschicht wird in der Architekturbeschreibung erfasst und
in der Anwendung durchgesetzt.
Schichtenarchitektur des
JCommSy
Präsentationsschicht (detailliert)
servlet
jsp, tag
outfitter
fragment
Technologie
presentation
util
logic
Struktur
service
Serviceschicht (detailliert)
item
api
Schnittstelle
impl
Implementierung
domainvalue
Abbildung 6.4: Überarbeitete Architektur des JCommSy (Version 2)
6.3.3 Fazit
Sowohl die Architekturbeschreibung, als auch die Architektur selbst wurden verbessert, nicht
durch die neue Technologie, aber durch den Austauschvorgang. Die Vorbereitungen, die nötig
waren, um den Austausch der Oberflächentechnologie vorzunehmen, führten zu diesen Verbesserungen. Die Notwendigkeit der Vorbereitungen resultiert aus grundlegenden softwaretechnischen Prinzipien, wie Wiederverwendung (Logik-Refactoring) und Abstraktion (Überarbeitung
des Architekturmodells).
Die Verbesserungen sind die Übereinstimmung von Ist- und Soll-Architektur, die Abbildung der
Architekturbeschreibung auf die Java-Package-Hierarchie und die Kapselung der Fachlogik in
eine eigene Architekturschicht.
Der erfolgreiche und problemlose Austausch einer ganzen Architekturschicht hat bewiesen, dass
das JCommSy und seine Architektur u. a. über die Eigenschaften Flexibilität und Erweiterbarkeit verfügen (siehe Fayad und Cline [FC96]). Ausschlaggebend hierfür sind Prinzipien der
Softwaretechnik (Modularität und Geheimnisprinzip), die von den Entwicklern des JCommSy
umgesetzt worden sind.
6.4 Zusammenfassung
63
6.4 Zusammenfassung
In diesem Kapitel wurden die Auswirkungen des Technologieaustauschs im Einzelnen beschrieben und bewertet. Für alle betrachteten Bereiche konnte eine Verbesserung festgestellt werden,
was dem Ziel dieser Arbeit entspricht.
Die Testbarkeit konnte verbessert werden, weil JSP und Tag-Bibliotheken durch Java ersetzt
wurden. Es gibt jetzt schnellere und direktere Tests für die Oberfläche. Warum Testbarkeit wichtig ist und in wie weit die einzelnen Systemteile des JCommSy testbar sind, wurde ebenfalls
erläutert.
Die Entwicklungskomplexität konnte verringert werden, indem die zu bewältigenden Anstrengungen reduziert wurden und die Entlastung für die Entwickler verbessert wurde. Die Anzahl
der Entwicklungssprachen wurde halbiert (von 6 auf 3) und die Anzahl der Teilsysteme konnte
von 9 auf 5 reduziert werden. Die Werkzeugunterstützung, die Anwendbarkeit von Vorgehensmodellen und die Dokumentation wurde durch den größeren Java-Anteil im System ebenfalls
verbessert. Auch die im JCommSy verwendeten Abstraktionen wurden aufgewertet, durch die
Vorbereitungen auf den eigentlichen Technologieaustausch.
Architekturbeschreibung und Architektur wurden ebenfalls durch diese Vorbereitungen verbessert. Es steht jetzt eine aktualisierte Version von beiden zur Verfügung, einzelne Bereiche wurden
überarbeitet und es gibt keine Architekturverletzungen mehr. Durch den vollzogenen Wechsel
konnten Flexibilität und Erweiterbarkeit des JCommSy nachgewiesen werden.
Die aufgestellte Arbeitshypothese 1 (siehe Seite 26) wurde durch die eingetretenen Verbesserungen, die in zwei von drei Fällen direkt auf die Verwendung von Java zurückzuführen sind,
bestätigt.
Kapitel 7 Schlussbemerkungen
64
Kapitel 7
Schlussbemerkungen
Dieses Kapitel wird die Diplomarbeit abschließen, indem die wichtigsten Aspekte noch einmal
zusammengefasst werden. Offene Fragen und ausstehende Arbeiten werden benannt, so dass sie
weiterverfolgt werden können.
7.1 Fazit
Während dieser Arbeit wurden Veränderungen am JCommSy vorgenommen, um daraus softwaretechnische Erkenntnisse zu gewinnen. Diese Erkenntnisse werden hier konkret formuliert.
Darauf aufbauend wird ein Versuch unternommen, diese Erkenntnisse zu verallgemeinern.
Das Erstellen dieser Arbeit war ein Lernprozess. Rückblickend würde ich einige Aufgaben anders angehen. Auch das ist ein Ergebnis dieser Arbeit und wird festgehalten.
7.1.1 Ergebnisse dieser Arbeit
Aus den Untersuchungen vor und nach dem Technologieaustausch wurden eine Reihe von Erkenntnissen gewonnen. Die im Folgenden als Ergebnisse formulierten Aussagen sollen diese
Erkenntnisse widerspiegeln.
Ergebnis 1:
Durch den Austausch der Oberflächentechnologie kann die Testbarkeit einer Anwendung verbessert werden.
Schlecht testbare Systemteile wurden entfernt, gut testbare wurden erweitert. Komponententests für die Oberfläche sind jetzt schnell und direkt möglich, was auch ein agiles Vorgehen bei der Softwareentwicklung unterstützt.
Ergebnis 2:
Durch den Austausch der Oberflächentechnologie kann die Entwicklungskomplexität verringert werden.
Die Homogenisierung des JCommSy hat die zu überwindenden Anstrengungen (Anzahl
der Entwicklungssprachen und Teilsysteme) reduziert und die Entlastungen (Werkzeugunterstützung, Vorgehensmodelle und Dokumentation) erhöht. Durch die Vorbereitungen
auf den Austauschprozess wurden die vorhandenen Abstraktionen ebenfalls verbessert.
Ergebnis 3:
Durch den Austausch der Oberflächentechnologie kann die Architektur indirekt
verbessert werden.
Nicht die verwendete Technologie hat eine Veränderung bewirkt, sondern der AustauschProzess. Während der Vorbereitungen, die aus softwaretechnischer Sicht notwendig waren, wurde die Architektur (und deren Beschreibung) überarbeitet, um eine solide Basis
für Durchführung und Bewertung des Technologiewechsels zu haben. Außerdem wurde
7.1 Fazit
65
die Fachlogik des JCommSy identifiziert und durch ein Refactoring zu einem eigenen
Architektur-Artefakt gemacht.
Ergebnis 4:
Durch den Austausch der Oberflächentechnologie können Eigenschaften einer Architektur nachgewiesen werden.
Der problemlose Austausch einer ganzen Architekturschicht beweist Flexibilität und Erweiterbarkeit.
Ergebnis 5:
Die Arbeitshypothese wurde bestätigt.
Die Arbeitshypothese 1 (siehe Seite 26) besagt, dass eine Verbesserung von Testbarkeit,
Entwicklungskomplexität und Architektur des JCommSy möglich ist, wenn man eine reine Java-Lösung als Oberflächentechnologie einsetzt. Dieser Fall ist eingetreten.
Diese Ergebnisse gelten für den Rahmen, der durch diese Arbeit vorgegeben wurde. Zum einen
das JCommSy, mit seinen Stärken und Schwächen. Zum anderen der Kriterienkatalog und das
gewählte Vorgehen für den Austausch. Zu den Stärken des JCommSy gehören die ausgereifte Architektur, die gute Modularisierung und die bewährte Quelltextbasis. Zu den Schwächen
gehören die große Anzahl eingesetzter, heterogener Technologien und die damit Verbundenen
Auswirkungen auf Testbarkeit und Entwicklungskomplexität. Der Kriterienkatalog und das Vorgehen beim Austausch wurden bereits detailliert beschrieben.
7.1.2 Verallgemeinerung der Ergebnisse
Ausgehend von den eben formulierten Ergebnissen, lassen sich Verallgemeinerungen formulieren, die auch auf andere Situationen anwendbar sind.
Damit die Ergebnisse Gültigkeit haben, muss die ausgetauschte Technologie keine Oberflächentechnologie sein. Relevant ist nur, ob die bisherige Technologie Schwächen in Form von schlechter Testbarkeit oder schlechter Werkzeugunterstützung aufweist oder das Gesamtsystem heterogen ist, in Bezug auf Entwicklungssprachen und eingesetzte Technologien. Die Verbesserung
von Testbarkeit, Entwicklungskomplexität und Architektur wurde größtenteils auf die Umstellung eines weiteren Systemteils auf Java zurückgeführt. Aber es ist nicht die Java-Technologie,
die diese Verbesserungen hervorgebracht hat, sondern die Verfügbarkeit von Werkzeugen, TestRahmenwerken und Vorgehensmodellen für Java. Daraus kann man eine Regel ableiten, die
allgemein auf Softwareentwicklungsprojekte anwendbar ist:
Werkzeugunterstützung, Verfügbarkeit von Test-Rahmenwerken und Kompatibilität zu
Vorgehensmodellen sollten eine wesentliche Rolle bei der Technologieauswahl spielen.
Werkzeugunterstützung ist ein sehr wichtiger Aspekt bei der Entwicklung von Software. Durch
die geeigneten Werkzeuge kann ein Entwickler schneller, qualitativ hochwertigeren Quelltext erzeugen. Der gesamte Entwicklungsprozess wird durch die vorhandenen Werkzeuge beeinflusst.
Das (automatische) Überprüfen von Systemeigenschaften wie Testabdeckung oder Architekturverletzungen hat nicht nur einen Mehrwert für die Entwickler, sondern auch für das Management
und die Kunden.
7.1 Fazit
66
7.1.3 Rückblick
Während der Erstellung dieser Arbeit wurden viele inhaltliche und prozessbezogene Entscheidungen getroffen. Im Nachhinein können diese Entscheidungen anhand der Ergebnisse und der
aufgetretenen Probleme bewertet werden.
Die Entscheidung, die Architektur des JCommSy vor dem Technologieaustausch zu überarbeiten und ein Refactoring der Fachlogik durchzuführen, hat sich als richtig erwiesen. Es hat Zeit
gekostet diese Arbeitsschritte durchzuführen, hatte aber den Vorteil, dass man sie unabhängig
voneinander erledigen konnte (geringere Komplexität). Hätte ich gleich mit dem Technologieaustausch begonnen, wären viele Probleme erst dann aufgetreten und hätten die eigentlichen
Arbeiten unterbrochen oder gestört.
Bei den ersten Überlegungen zu dieser Diplomarbeit wurde als Zieltechnologie das GoogleWeb-Toolkit anvisiert. Die Untersuchungen während dieser Arbeit haben gezeigt, dass das keine
gute Lösung gewesen wäre. Ein Vergleich der verfügbaren Rahmenwerke zu machen, war die
richtige Entscheidung. Der dafür angelegte Kriterienkatalog und die erstellten Prototypen haben
sich als gutes Mittel erwiesen, um eine große Anzahl an Rahmenwerken zu analysieren.
Folgende Entscheidungen waren nicht optimal und fallen in die Kategorie „Das würde ich beim
nächsten Mal anders machen“.
Beim Erstellen der Prototypen und durch den Austausch der Oberflächentechnologie habe ich
neue Erkenntnisse gewonnen. Um diesen Erkenntnissen gerecht zu werden, wären folgende Kriterien im Kriterienkatalog sinnvoll:
Die Dokumentation, vor allem API-Dokumentation1 , sollte stärker ins Gewicht fallen. Beim
täglichen Umgang mit dem Rahmenwerk verursacht eine nicht ausreichende Dokumentation
Zeitverzögerungen und Fehler bei der Implementierung.
Um in Tests auf Mock-Objekte2 zurückgreifen zu können, sollte darauf geachtet werden, dass
das Rahmenwerk dem Prinzip folgt, von Interfaces und nicht von konkreten Klassen abzuhängen. Stehen Interfaces zur Verfügung können Objekte, die für einen Test aufwendig initalisiert
werden müssten, durch einfache Mock-Objekte ersetzt werden.
Das Verändern von Details auf der Benutzungsoberfläche kann je nach Rahmenwerk einfach,
sehr aufwendig oder unmöglich sein. Dieses Kriterium sollte ebenfalls Beachtung bei der Wahl
der Oberflächentechnologie finden.
Bei der Implementierung der neuen Benutzungsoberfläche ist Zeit in Detailarbeiten geflossen,
die besser für eine breitere Implementierung der CommSy-Funktionalitäten und Rubriken hätte
verwendet werden können. Davon abgesehen wäre mehr Zeit für diese Phase der Diplomarbeit
wünschenswert gewesen, um JCommSy und ZKommSy direkter vergleichen zu können.
Formale Kriterien für die Auswertung des Technologieaustauschs hätten diesen Arbeitsschritt
sehr vereinfacht. Die optimale Lösung wären (automatisch) generierte Metriken gewesen. Das
Definieren solcher Metriken wäre ein interessantes Thema für eine eigene Diplomarbeit. In dieser Arbeit konnte dieses Verfahren nicht angewendet werden.
1 Die
Application-Programming-Interface-Dokumentation (Programmierschnittstellen-Dokumentation) enthält Beschreibungen für Interfaces, Klassen, Methoden und Felder.
2 Platzhalterobjekte, die in Tests verwendet werden (siehe Machinnon u. a. [MFC01]).
7.2 Ausblick
67
7.2 Ausblick
Nicht alle Arbeiten, die im Rahmen dieser Diplomarbeit begonnen wurden, konnten vollständig
durchgeführt werden.
Beim Logik-Refactoring wurden die wichtigsten Implementierungen der Fachlogik gefunden
und extrahiert. Es ist aber anzunehmen, dass noch weitere Aspekte der Fachlogik in verschiedenen Systemteilen enthalten sind. Weitere Analysen und Refactorings sind notwendig, um diese
Arbeiten abzuschließen.
Im ZKommSy ist nur eine Rubrik implementiert und es fehlen noch Funktionen, die im JCommSy bereits verfügbar sind. Die Oberfläche muss erweitert werden, so dass die anderen Rubriken
und Funktionen zugänglich sind.
Bei der Gestaltung der neuen Oberfläche wurde der Schwerpunkt nicht auf ein ausgefeiltes Design gelegt. Viele Möglichkeiten, die das ZK-Rahmenwerk bietet, wurden nicht ausgeschöpft.
Das Feindesign des ZKommSy steht noch aus.
Neben den noch ausstehenden Arbeiten, ergaben sich auch weiterführende Ideen beim Erstellen
dieser Arbeit.
Das Benutzungsmodell des CommSy könnte erweitert werden, um den Möglichkeiten Rechnung
zu tragen, die die neue Oberflächentechnologie bietet. Direkte Manipulation, Drag-n-Drop, dynamisches Layout und die Verwendung von Fenstern sind nur einige dieser Möglichkeiten.
Es könnte ein anderer Technologieaustausch (andere Technologie oder andere Anwendung) vorgenommen werden, um die Ergebnisse dieser Arbeit zu bestätigen oder zu widerlegen. Vor allem
für die verallgemeinerten Aussagen wäre das interessant.
Unabhängig von den noch ausstehenden Arbeiten konnte gezeigt werden, dass durch einen Technologieaustausch wichtige softwaretechnische Aspekte eines Systems verbessert werden können.
Literaturverzeichnis
68
Literaturverzeichnis
[BA04]
B ECK, Kent ; A NDRES, Cynthia: Extreme Programming Explained: Embrace
Change (Xp). 2. Addison-Wesley Longman, Amsterdam, 2004. – ISBN 0321278658
[Bal00]
BALZERT, Helmut: Lehrbuch der Software-Technik - Software-Entwicklung. 2.
Spektrum Akademischer Verlag, 2000. – ISBN 3–8274–0480–0
[BCK98]
BASS, Len ; C LEMENTS, Paul ; K AZMAN, Rick: Software Architecture in Practice.
1. Addison-Wesley, 1998. – ISBN 0–201–19930–0
[Bec02]
B ECK, Kent: Test Driven Development. By Example. Addison-Wesley Longman,
Amsterdam, 2002. – ISBN 9780321146533
[BFK+ 84] B UDDE, R. ; F LOYD, C. ; K UHLENKAMP, K. ; M ATHIASSEN, L. ; Z ÜLLIGHOVEN,
H.: Approaches to Prototyping. Springer-Verlag, 1984. – ISBN 9780387134901
[BK05]
BAUER, Christian ; K ING, Gavin: Hibernate in Action. Manning Publications, 2005.
– ISBN 1932394–15–X
[BKOP02] B LEEK, Wolf-Gideon ; K RAUSE, Detlev ; O BERQUELLE, Horst ; PAPE, Bernd: Vernetzt, Verteilt, Verloren? Das "Wissensprojekt"Wintertagung. In: Medienunterstütztes Lernen - Beiträge von der WissPro-Wintertagung 2002, 2002, S. 7–10
[BL00]
B USCHMANN, Frank ; L ÖCKENHOFF, Christiane: Pattern-orientierte Softwarearchitektur: ein Pattern-System. Addison-Wesley, 2000. – ISBN 3–8273–1282–5
[CKK02]
C LEMENTS, Paul ; K AZMAN, Rick ; K LEIN, Mark: Evaluation Software Architectures - Methods and Case Studies. Addison-Wesley, 2002. – ISBN 0–201–70482–X
[CT08]
C OMM S Y-T EAM:
CommSy Eine Kurzbeschreibung zum Einstieg,
2008.
http://www.commsy.net/uploads/Software/commsy_
kurzbeschreibung.pdf
[Dar09]
DARICILI, Ilker: Entwicklung eines J2ME-Clients für eine bestehende WebAnwendung - Auswirkungen der Integration auf Architektur, Kontrollfluss und Benutzungsmodell, Universität Hamburg, Diplomarbeit, 2009
[DEF+ 08] D UNKEL, Jürgen ; E BERHART, Andreas ; F ISCHER, Stefan ; K LEINER, Carsten
; KOSCHEL, Arne: Systemarchitekturen für verteilte Anwendungen. Carl Hanser
Verlag Münschen, 2008. – ISBN 978–3–446–41321–4
[Ess08]
E SSER, Friedrich: Java 6 Core Techniken: Essentielle Techniken für Java-apps.
Oldenbourg Wissenschaftsverlag, 2008. – ISBN 3486584111
[Eva04]
E VANS, Eric: Domain-driven Design: Tackling Complexity in the Heart of Software.
Addison-Wesley, 2004. – ISBN 0321125215
Literaturverzeichnis
69
[FC96]
FAYAD, Mohamed ; C LINE, Marshall P.: Aspects of software adaptability. In: Commun. ACM 39 (1996), Nr. 10, S. 58–59. – ISSN 0001–0782
[FF02]
F LANAGAN, David ; F ERGUSON, Paula: JavaScript: The Definitive Guide. 4.
O’Reilly & Associates, 2002. – ISBN 0–596–00048–0
[Fow99]
F OWLER, Martin: Refactoring: Improving the Design of Existing Code. Boston,
MA, USA : Addison-Wesley Professional, 1999. – ISBN 0–201–48567–2
[Fow00]
F OWLER, Martin: Refactoring: Wie Sie das Design vorhandener Software verbessern. Addison-Wesley, 2000. – ISBN 3–8273–1630–8
[GHJV94] G AMMA, Erich ; H ELM, Richard ; J OHNSON, Ralph ; V LISSIDES, John M.: Design
Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1994. – ISBN 9780201633610
[GHJV09] G AMMA, Erich ; H ELM, Richard ; J OHNSON, Ralph ; V LISSIDES, John: Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software. AddisonWesley, 2009. – ISBN 978–3–8273–2824–3
[GJSB05] G OSLING, James ; J OY, Bill ; S TEELE, Guy ; B RACHA, Gilad: The Java language
specification. 3. Dpunkt Verlag, 2005. – ISBN 0–321–24678–0
[HM02]
H AROLD, Elliotte R. ; M EANS, W. S.: XML in a Nutshell: A Desktop Quick Reference. 2. O’Reilly, 2002. – ISBN 0–596–00292–0
[IEE90]
IEEE (Hrsg.): IEEE Standard Glossary of Software Engineering Terminology. IEEE
Standards Board, 1990 (Std 610.12-1990). – ISBN 1–55937467–X
[Jee05]
J EENICKE, Martti: Architecture-Centric Software Migration for the Evolution of
Web-based Systems. In: Workshop on Architecture-Centric Evolution (ACE 2005),
2005 (ECOOP)
[Kru03]
K RUCHTEN, Philippe: The Rational Unified Process: An Introduction. 3. AddisonWesley, 2003. – ISBN 0–201–70710–1
[Lil08]
L ILIENTHAL, Carola: Komplexität von Softwarearchitekturen, Stile und Strategien,
Universität Hamburg, Diss., 2008
[Lin05]
L INK, Johannes: Softwaretests mit JUnit. 2. Dpunkt Verlag, 2005. – ISBN
3898643255
[Lou94]
L OUDEN, Kenneth C.: Programmiersprachen - Grundlagen, Konzepte, Entwurf. 2.
International Thomson Publishing GmbH, 1994. – ISBN 3–929821–03–6
[Mac82]
M AC L ENNAN, B. J.: Values and objects in programming languages. In: SIGPLAN
Not. 17 (1982), Nr. 12, S. 70–79. – ISSN 0362–1340
Literaturverzeichnis
70
[Mey97]
M EYER, Bertrand: Object-oriented Software Construction. (Prentice-Hall International Series in Computer Science). 2. A. Prentice Hall International, 1997. – ISBN
9780136291558
[MFC01]
Kapitel Endo-Testing: Unit Testing with Mock Objects. In: M ACHINNON, T. ;
F REEMAN, S. ; C RAIG, P.: Extreme Programming Examined. Addison-Wesley,
2001
[MN05]
M ÜNZ, Stefan ; N EFZGER, Wolfgang: HTML Handbuch. Franzis-Verlag, 2005. –
ISBN 3–7723–6654–6
[Mye04]
M YERS, Glenford J.: The Art of Software Testing. 2. John Wiley & Sons, Inc., 2004.
– ISBN 0–471–46912–2
[Obe90]
O BERQUELLE, Horst ; U NIVERSITÄT H AMBURG (Hrsg.): Programmiersprachen Unterlagen zur Prüfungsvorbereitung. Universität Hamburg, 1990
[Par72]
PARNAS, D. L.: On the criteria to be used in decomposing systems into modules.
In: Commun. ACM 15 (1972), Nr. 12, S. 1053–1058. – ISSN 0001–0782
[Pha00]
P HANOURIOU, Constantinos: UIML: A Device-Independent User Interface Markup
Language, Virginia Polytechnic Institute and State University, Diss., 2000
[Rec09]
R ECHENBERG, Salim: Wechselwirkungen zwischen Performance und Architektur –
Analyse, Optimierung und Evaluation am Beispiel des JCommSy, Universität Hamburg, Diplomarbeit, 2009
[Ree79]
R EENSKAUG, Trygve: THING-MODEL-VIEW-EDITOR / Xerox PARC. 1979 (5).
– Forschungsbericht
[RH06]
R EUSSNER, Ralf (Hrsg.) ; H ASSELBRING, Wilhelm (Hrsg.): Handbuch der
Software-Architektur. 1. Dpunkt Verlag, 2006. – ISBN 3898643727
[Roy87]
ROYCE, W. W.: Managing the development of large software systems: concepts
and techniques. In: ICSE ’87: Proceedings of the 9th international conference on
Software Engineering. Los Alamitos, CA, USA : IEEE Computer Society Press,
1987. – ISBN 0–89791–216–0, S. 328–338
[Sch04a]
S CHMITT, Christopher: CSS Cookbook. 1. O’Reilly, 2004. – ISBN 0–596–00576–8
[Sch04b]
S CHWABER, Ken: Agile Project Management with Scrum (Microsoft Professional).
Microsoft Press Corp., 2004. – ISBN 9780735619937
[Sch08]
S CHWENTNER, Henning: Wider die enge Kopplung: Große Refactorings in einem
Prozess zur Entflechtung von Anwendung und Rahmenwerk, Universität Hamburg,
Diplomarbeit, 2008
[SL05]
S PILLNER, Andreas ; L INZ, Tilo: Basiswissen Softwaretest. 3. Dpunkt Verlag,
2005. – ISBN 3–89864–358–1
Literaturverzeichnis
71
[SMC79]
Kapitel Structured design. In: S TEVENS, W. ; M YERS, G. ; C ONSTANTINE, L.:
Classics in software engineering. Upper Saddle River, NJ, USA : Yourdon Press,
1979. – ISBN 0–917072–14–6, S. 205–232
[TSL04]
T URAU, Volker ; S ALECK, Krister ; L ENZ, Christopher: Web-basierte Anwendungen
entwicklen mit JSP 2. 2. Dpunkt Verlag, 2004. – ISBN 3–89864–235–6
[Ver00]
V ERSTEEGEN, Gerhard: Projektmanagement mit dem Rational Unified Process.
Springer Verlag, 2000. – ISBN 3–540–66755–5
[ZLMG08] Z EITNER, Alfred ; L INNER, Birgit ; M AIER, Martin ; G ÖCKELER, Thorsten: Spring
2.5. Addison-Wesley, 2008. – ISBN 978–3–8273–2622–5
Sonstige Verzeichnisse
72
Sonstige Verzeichnisse
Abbildungsverzeichnis
3.1
3.2
3.3
Architektur des JCommSy nach Schwentner [Sch08, S. 57] . . . . . . . . . . .
Überarbeitete Architektur des JCommSy . . . . . . . . . . . . . . . . . . . . .
Zusammenspiel der Systemkomponenten beim Editieren eines Eintrags . . . .
12
14
19
4.1
4.2
Das JCommSy mit aktivierten Rahmen um jedes Oberflächenelement. . . . . .
Präsentationsschicht des JCommSy . . . . . . . . . . . . . . . . . . . . . . . .
22
23
5.1
5.2
5.3
5.4
5.5
Präsentationsschicht des JCommSy . . . . . . . . . . . . . . . . . . . . . . . .
Architektur des JCommSy mit parallelen (alternativen) Präsentationsschichten.
Rudimentär implementierte Funktionen des ZKommSy. . . . . . . . . . . . . .
Hauptseite des ZKommSy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Detailansicht einer Ankündigung . . . . . . . . . . . . . . . . . . . . . . . . .
41
42
48
49
49
6.1
6.2
6.3
6.4
Testbarkeit des JCommSy . . . . . . . . . . . . . . . . . . . . .
Testbarkeit des ZKommSy . . . . . . . . . . . . . . . . . . . .
Architektur des JCommSy nach Schwentner [Sch08] (Version 1)
Überarbeitete Architektur des JCommSy (Version 2) . . . . . .
.
.
.
.
53
54
61
62
4.1
Java-Rahmenwerke zum Erstellen von Web-Anwendungen . . . . . . . . . . .
25
6.1
6.2
Anzahl der Quelltextzeilen pro Teilsystem des JCommSy. . . . . . . . . . . . .
Anzahl der Quelltextzeilen pro Teilsystem des ZKommSy. . . . . . . . . . . .
55
59
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Tabellenverzeichnis
Quelltextverzeichnis
5.1
5.2
5.3
5.4
5.5
Konfiguration des ZK-Rahmenwerks im Deployment Descriptor (web.xml).
Spring Konfiguration für ZK im Deployment Descriptor (web.xml). . . . . .
Dependency Injection Konfiguration (zkContext.xml). . . . . . . . . . . .
Konfiguration des ZK-Rahmenwerks (zk.xml). . . . . . . . . . . . . . . . .
Einbinden einer CSS-Datei. . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
42
44
44
45
46
Quelltextverzeichnis
73
Denitionsverzeichnis
2.1.1 Komponententest . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.2 Akzeptanztest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.3 Testbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.4 Entwicklungskomplexität . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.5 Software-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.6 Architekturbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.7 Architekturstil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.8 Programmiersprache . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.9 Auszeichnungssprache . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.10Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.11Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.12Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Inhalt der CD-ROM
74
Inhalt der CD-ROM
Die beigefügte CD-ROM enthält die Quelltexte des JCommSy und des ZKommSy in der Version
vom 13.04.2009. Eine digitale Version dieser Arbeit ist ebenfalls als PDF-Dokument auf der
CD-ROM zu finden.
Datei
JCommSy.zip
Diplomarbeit.pdf
Beschreibung
ZIP-Archiv der Quelltexte des JCommSy-Projekts. Enthält
ebenfalls die ZKommSy-Quelltexte und ist für den parallelen Betrieb vorkonfiguriert.
Diese Arbeit als PDF-Dokument.
Eidesstattliche Erklärung
Ich versichere, dass ich die vorstehende Arbeit selbstständig und ohne fremde Hilfe angefertigt
und mich anderer als der im beigefügten Verzeichnis angegebenen Hilfsmittel nicht bedient
habe. Alle Stellen, die wörtlich oder sinngemäß aus Veröffentlichungen entnommen wurden,
sind als solche kenntlich gemacht.
Ich bin mit einer Einstellung in den Bestand der Bibliothek des Departments Informatik einverstanden.
Hamburg, den
Unterschrift: