VEMICO - Berner Fachhochschule

VEMICO - Berner Fachhochschule
Projektdokumentation
VEMICO
Vereinsmitgliederverwaltung mit Computer
Masterthesis Nummer:
MT-11-01.04
Datum:
Version:
22. September 2011
1.0
Abstract:
Es soll eine Webapplikation gebaut werden, welche die
Vereinsmitgliederverwaltung sowie die Newsletter Administration
erleichtert.
Die Applikation soll idealerweise sowohl in der "Cloud" (Google App Engine)
als auch auf konventioneller, lokaler Infrastruktur lauffähig sein.
Schlüsselwörter:
Google App Engine, Java, Vaadin, Cloud Computing
Verfasser:
Mischa Christen
Genossenweg 23
3012 Bern
079 350 55 79
[email protected]
Experte:
Prof. Dr. Stephan Fischli
Berner Fachhochschule
Wankdorffeldstrasse 102
3014 Bern
031 848 32 74
[email protected]
Betreuer:
Dipl. Ing. Daniel Aeschbacher
Präsident Guild42.ch
Lutertalstrasse 37
3065 Bolligen
079 822 68 47
[email protected]
Seite 1 von 83
Masterthesis MT-11-01.04 VEMICO
1 Änderungskontrolle
Version
0.1
0.2
0.3
0.4
1.0
Änderung
Erste Version
Anforderungen und Planung nach erster Review
Sitzung überarbeitet
Use Cases nach zweitem Review überarbeitet
Vor finalem Review
Finale Version
Datum
15.5.2011
21.5.2011
Author
Mischa Christen
Mischa Christen
24.06.2011
18.09.2011
22.09.2011
Mischa Christen
Mischa Christen
Mischa Christen
Seite 2 von 83
Masterthesis MT-11-01.04 VEMICO
2 Inhalt
1
Änderungskontrolle .............................................................................................................................. 2
3
Literaturverzeichnis .............................................................................................................................. 7
4
Begriffe und Abkürzungen .................................................................................................................... 8
5
Einführung .......................................................................................................................................... 10
6
5.1
Zweck und Struktur des Dokuments .......................................................................................... 10
5.2
Ausgangslage .............................................................................................................................. 10
5.3
Problemstellung.......................................................................................................................... 10
5.4
Lösung......................................................................................................................................... 10
Requirements Model .......................................................................................................................... 11
6.1
Anforderungen ........................................................................................................................... 11
6.1.1
Verifikation der Anforderungserfüllung ............................................................................. 11
6.1.2
Funktionale Anforderungen ............................................................................................... 11
6.1.3
Nichtfunktionale Anforderungen ....................................................................................... 13
6.2
Use Cases .................................................................................................................................... 15
6.2.1
UC1 - Anmelden .................................................................................................................. 16
6.2.2
UC2 - Neues Passwort verlangen........................................................................................ 16
6.2.3
UC3 - Benutzer und Rechte verwalten ............................................................................... 17
6.2.4
UC4 - Mailinglisten verwalten ............................................................................................ 18
6.2.5
UC5 - Personendaten verwalten......................................................................................... 19
6.2.6
UC6 - Mitgliederbeiträge verwalten ................................................................................... 20
6.2.7
UC7 - Anlässe verwalten ..................................................................................................... 20
6.2.8
UC8 - Newsletters verwalten/versenden .......................................................................... 21
6.2.9
UC9 - Daten importieren/exportieren ................................................................................ 21
6.2.10
UC10 - Anmelden für Anlass ............................................................................................... 22
6.2.11
UC11 - Abmelden von Anlass.............................................................................................. 22
6.2.12
UC12 - Mitgliedschaft beantragen...................................................................................... 22
6.2.13
UC13 – Von Mailinglisten abmelden .................................................................................. 23
6.2.14
UC14 – Kontaktdaten verwalten ........................................................................................ 23
6.3
Akzeptanztestfälle ...................................................................................................................... 24
6.3.1
Mitgliederstamm ................................................................................................................ 24
6.3.2
Mitgliederdaten .................................................................................................................. 25
6.3.3
Newsletter .......................................................................................................................... 26
6.3.4
Benutzerverwaltung ........................................................................................................... 26
6.3.5
Internationalisierung und Lokalisation ............................................................................... 27
6.3.6
Spezifische nichtfunktionale Anforderungen ..................................................................... 27
6.4
User Interface Model.................................................................................................................. 28
Seite 3 von 83
Masterthesis MT-11-01.04 VEMICO
6.5
Domain Model ............................................................................................................................ 29
6.5.1
7
Design Model ...................................................................................................................................... 30
7.1
Technologiestudie ...................................................................................................................... 30
7.1.1
Ziele und Anforderungen.................................................................................................... 30
7.1.2
Rahmenbedingungen ......................................................................................................... 30
7.1.3
Standards und Best Practices ............................................................................................. 31
7.1.4
Kommunikationsframeworks für GWT ............................................................................... 32
7.1.5
Anwendungsframeworks für GWT ..................................................................................... 32
7.1.6
Persistenzframeworks für Google App Engine ................................................................... 33
7.1.7
Buildtools ............................................................................................................................ 34
7.1.8
Produktivitätstools ............................................................................................................. 35
7.1.9
Auswahl, Entscheid und Begründung ................................................................................. 36
7.2
System Overview ........................................................................................................................ 37
7.2.1
Vaadin Framework Architecture ........................................................................................ 38
7.2.2
Vaadin Client Side Architecture .......................................................................................... 39
7.3
Object Model .............................................................................................................................. 40
7.3.1
Anwendungsgerüst ............................................................................................................. 40
7.3.2
Modulkonzept .................................................................................................................... 41
7.4
Physical Data Model ................................................................................................................... 42
7.4.1
Fachklassen Modell ............................................................................................................ 42
7.4.2
Autorisierungsmodell ......................................................................................................... 43
7.5
8
Fachliche Entitäten ............................................................................................................. 29
Deployment Model ..................................................................................................................... 44
7.5.1
Deployment in Google AppEngine...................................................................................... 44
7.5.2
Deployment in Apache Tomcat .......................................................................................... 44
Implementation .................................................................................................................................. 45
8.1
Design Entscheide....................................................................................................................... 45
8.1.1
„Selfcare“ Funktionalität .................................................................................................... 45
8.1.2
Verwendung des „appfoundation“ Frameworks................................................................ 45
8.2
Java Code .................................................................................................................................... 46
8.2.1
Java Doc .............................................................................................................................. 46
8.2.2
Java Package Struktur ......................................................................................................... 46
8.3
Die Anwendung .......................................................................................................................... 47
8.3.1
8.4
Das Thread Local Pattern.................................................................................................... 47
Modul Konzept ........................................................................................................................... 48
8.4.1
8.4.2
Entwicklerhandbuch ........................................................................................................... 48
Navigation........................................................................................................................... 51
Seite 4 von 83
Masterthesis MT-11-01.04 VEMICO
8.4.3
8.5
Databinding ........................................................................................................................ 52
Persistenz.................................................................................................................................... 54
8.5.1
Anpassungen am Appfoundation Persistence Layer .......................................................... 54
8.5.2
Plattformspezifische Klassen .............................................................................................. 55
8.5.3
Integration Test .................................................................................................................. 55
8.5.4
Zwischenfazit Persistenz Schicht ........................................................................................ 56
8.6
Internationalisierung .................................................................................................................. 57
8.7
Autorisierung .............................................................................................................................. 57
8.8
Logging........................................................................................................................................ 58
8.9
Exception Handling ..................................................................................................................... 58
9
Test ..................................................................................................................................................... 59
9.1
Testreport Akzeptanz Test.......................................................................................................... 59
9.2
Testreport System Test............................................................................................................... 60
9.2.1
Zusammenfassung .............................................................................................................. 60
9.2.2
Spezifische nichtfunktionale Anforderungen ..................................................................... 61
9.2.3
Allgemeine nichtfunktionale Anforderungen ..................................................................... 62
9.2.4
Testreport Unit Test ........................................................................................................... 63
10
Deployment .................................................................................................................................... 64
10.1
Betriebshandbuch ...................................................................................................................... 64
10.1.1
Anwendungs Konfiguration ................................................................................................ 64
10.1.2
Google App Engine ............................................................................................................. 64
10.1.3
Tomcat mit MySQL ............................................................................................................. 67
10.2
11
Benutzerhandbuch ..................................................................................................................... 69
Configuration Management ........................................................................................................... 70
11.1
Entwicklungsumgebung.............................................................................................................. 70
11.1.1
11.2
Hilfsmittel ........................................................................................................................... 71
Projektstruktur ........................................................................................................................... 72
11.2.1
Entwicklungsprozess........................................................................................................... 72
11.2.2
Vemico Projekte ................................................................................................................. 72
11.2.3
IWA Projekte ....................................................................................................................... 73
12
Project Management ...................................................................................................................... 74
12.1
Vorgehensmodell........................................................................................................................ 74
12.2
Lieferobjekte............................................................................................................................... 75
12.3
Planung ....................................................................................................................................... 76
13
13.1
Abschluss ........................................................................................................................................ 77
Fazit ............................................................................................................................................ 77
Seite 5 von 83
Masterthesis MT-11-01.04 VEMICO
13.2
Erkenntnisse ............................................................................................................................... 77
13.2.1
Vielfalt der Frameworks und Tools..................................................................................... 77
13.2.2
Google App Engine ............................................................................................................. 77
13.3
Mögliche Verbesserungen und Erweiterungen .......................................................................... 78
13.3.1
Implementation .................................................................................................................. 78
13.3.2
Fachliches ........................................................................................................................... 78
13.4
Ausblick IWA ............................................................................................................................... 79
13.4.1
Mehr Flexibilität.................................................................................................................. 79
13.4.2
Maven Support ................................................................................................................... 79
13.4.3
Weitere Plattformen........................................................................................................... 79
13.4.4
Vaadin Add On .................................................................................................................... 79
13.4.5
IDE Plugins .......................................................................................................................... 79
13.5
Trivia ........................................................................................................................................... 79
14
Abbildungen ................................................................................................................................... 80
A.
Planung ............................................................................................................................................... 81
B.
Generiertes DB Model ........................................................................................................................ 82
C.
Ergonomie Test Report ....................................................................................................................... 83
Seite 6 von 83
Masterthesis MT-11-01.04 VEMICO
3 Literaturverzeichnis
[1] Scott W. Ambler. (2011, Apr.) The Agile Unified Process. [Online].
http://www.ambysoft.com/unifiedprocess/agileUP.html
[2] Google. (2011, May) Google Web Toolkit. [Online]. http://code.google.com/intl/de-CH/webtoolkit/
[3] Martin Fowler. (2011, June) martinfowler.com. [Online].
http://www.martinfowler.com/eaaDev/ModelViewPresenter.html
[4] Wikipedia. (2011, Apr.) Wikipedia. [Online]. http://de.wikipedia.org/wiki/Rational_Unified_Process
[5] Guild42.ch. (2011, Apr.) Guild42.ch. [Online]. http://www.guild42.ch
[6] Mischa Christen, Themeneingabe Masterthesis MT-11-01.04, Apr. 7, 2011.
[7] Prof. Dr. Jochen Prümper. (2011, May) http://www.ergo-online.de. [Online]. http://www.ergoonline.de/site.aspx?url=html/software/verfahren_zur_beurteilung_der/beurteilung_der_software_ergo.htm
[8] Oracle. (2011, June) Java Pet Store. [Online]. http://java.net/projects/petstore
[9] Oracle. (2011, June) Using the Swing Application Framework. [Online].
http://java.sun.com/developer/technicalArticles/javase/swingappfr/
[10] Vaadin Ltd. (2011, June) Vaadin Homepage. [Online]. http://vaadin.com/home
[11] Kim Lepännen. (2011, June) Vaadin AppFoundation. [Online].
http://vaadin.com/directory#addon/appfoundation
[12] Mischa Christen. (2011, September) Instant Web App. [Online]. http://code.google.com/p/instant-webapp/
[13] Jerry Madden. (2011, June) oliverlehmann.com. [Online]. http://www.oliverlehmann.com/projectmanagement-sources/Nasa-Hundred-Rules-for-Project-Managers.pdf
Seite 7 von 83
Masterthesis MT-11-01.04 VEMICO
4 Begriffe und Abkürzungen
Begriff
AUP
Cloud Computing
CRUD
GWT
Google App Engine
IDE
IaaS
I18n
JDO
JPA
MVC
MVP
ORM
POJO
PaaS
Erklärung
Der „Agile Unified Process“ [1]
Bei Cloud Computing werden Teile des zu nutzenden Systems nicht mehr beim
Benutzer, sondern bei einem entfernten Anbieter betrieben und via Internet
benutzt. Die ausgelagerten Systemteile befinden sich „in der Wolke“. Abhängig
davon, welche Teile ausgelagert werden unterscheidet man SaaS, PaaS und IaaS.
Die Motivation hinter Cloud Computing ist es, selber keine Systeme zu
entwickeln, zu warten oder zu betreiben und somit Zeit und/oder Kosten zu
sparen.
Create, Read, Update, Delete: Die typischen Operationen auf Daten
Das Web Framework „Google Web Toolkit“ [2]. Für das vorliegende Projekt
wurde die Version 2.3 verwendet. GWT erlaubt es, Web Anwendungen in Java zu
programmieren. Die Übersetzung in (browserspezifisches) HTML und Javascript
übernimmt GWT.
Ein PaaS Dienst von Google. Google App Engine bietet Hosting für
Webapplikationen auf den Servern von Google. Bis zu einem gewissen
Ressourcenverbrauch ist der Dients kostenlos, anschliessend wird
verbrauchsabhängig abgerechnet.
Integrated Development Environment. Entwicklungsumgebung zur Herstellung
von Software
Infrastructure as a Service: Die minimale Form von Cloud Computing. Ein
Anbieter stellt Infrastruktur Dienste (Hardware, Betriebssystem, Speicher) zur
Verfügung.
Beispiele: Klassisches Hosting, Amazon Simple Storage Service (S3), Amazon EC2.
Abkürzung für „Internationalization“, Internationaliserung auf Englisch hat 18
Buchstaben zwischen dem ersten (I) und letzten Buchstaben (n)
Java Data Objects, ein ORM Standard
Java Persistence API, ein ORM Standard
Model View Controller: Ein Pattern, welches hilft die Darstellungslogik von der
Geschäftslogik zu trennen
Model View Presenter: Ein Pattern das, ähnlich wie das MVC Pattern, hilft die
Darstellungslogik von der Geschäftslogik zu trennen. Gemäss Martin Fowler [3]
gibt es zwei Ausprägungen, eine davon ist die „Passive View“ wo die
Darstellungskomponente nur noch minimalste, ausschliesslich Darstellungslogik
enthält
Object Relational Mapping: Persistieren und wieder in den Arbeitspeicher lesen
von Objekten, möglichst automatisch
Plain Old Java Object: Eine „normale“ Java Klasse im Sinne von dass keine
speziellen Interfaces implementiert werden müssen oder von einer bestimmten
Klasse geerbt werden muss
Plattform as a Service: Cloud Computing in der mittleren Ausprägung, ein
Anbieter stellt eine Laufzeitumgebung mit verschiedenen Diensten zur Verfügung
welche man für seine Applikationen nutzen kann.
Seite 8 von 83
Masterthesis MT-11-01.04 VEMICO
RUP
SaaS
Vaadin
VM
Beispiele: Google App Engine, Cloudfondry, Windows Azure, Force.com
Der „Rational Unified Process“ [4]
Software as a Service: Cloud Computing in der Maximalausprägung, der Benutzer
braucht nur noch einen Webbrowser.
Beispiele: Gmail, Google Docs, Salesforce.
Ein „Rich Internet Application“ (RIA) Java Framework. Der Grossteil der
Programmlogik läuft auf dem Server (Java Servlet basiert). Auf der Client Seite
wird auf GWT aufgesetzt.
Virtuelle Maschine, die Java Laufzeitumgebung
Seite 9 von 83
Masterthesis MT-11-01.04 VEMICO
5 Einführung
Any sufficiently advanced technology is indistinguishable from magic.
(Arthur C. Clarke)
5.1 Zweck und Struktur des Dokuments
Der vorliegende Bericht dient der Dokumentation dieser Masterthesis. Mit dem Experten wurde
vereinbart, anstelle von (wie in größeren Projekten üblich) vielen verschiedenen Dokumenten für
Anforderungen, Design, Projektmanagement etc. zwecks Übersichtlichkeit möglichst alles in einem
einzigen Dokument festzuhalten.
Die fachliche Dokumentation ist grundsätzlich in Deutsch gehalten. Dort wo gängige englische
Ausdrücke etabliert sind, werden diese verwendet (zum Beispiel Use Case). Begriffe aus dem
verwendeten Vorgehensmodel (AUP) werden ebenfalls unverändert in Englisch übernommen, um den
Bezug einfach herstellen zu können. Technische Artefakte sind wie allgemein üblich ebenfalls in Englisch
dokumentiert.
Die Struktur des Dokuments folgt sinngemäß den Disziplinen, beziehungsweise den Lieferobjekten der
gewählten Vorgehensmethodik AUP. Details zu AUP finden sich im Absatz „Vorgehensmodell“ im Kapitel
„Project Management“.
5.2 Ausgangslage
Der Verein Guild42.ch [5] führt in Bern Veranstaltungen zu Themen aus dem Bereich der Software
Entwicklung durch. Die Anlässe sind dank Sponsoren- und Mitgliederbeiträgen für die Teilnehmer
kostenlos.
5.3 Problemstellung
Die gesamte Vereinsadministration wie die Pflege der Mitgliederdaten und Mailinglisten, Kontrolle der
Beitragszahlungen und so weiter geschieht heute vollständig „von Hand“ einzig mit Hilfe eines Wikis.
Der E-Mail Versand erfolgt ebenfalls manuell: Sowohl Vereinsmitglieder als auch weitere Interessierte
erhalten vor den Veranstaltungen einen E-Mail Newsletter. Nach einem Anlass erhalten die Teilnehmer
eine E-Mail mit den Unterlagen der Veranstaltung.
Obwohl die Anzahl der Vereinsmitglieder und Anlässe recht überschaubar ist, ist der Administrationsaufwand erheblich.
5.4 Lösung
Es soll eine Webapplikation gebaut werden, welche die erwähnten Tätigkeiten unterstützt und
vereinfacht. Die Anwendung soll modular aufgebaut sein, so dass eine Erweiterung mit zusätzlichen
Funktionsmodulen einfach möglich ist.
Als eingebaute „Technologiestudie“ soll untersucht werden, ob die Applikation so gebaut werden kann,
dass sie einerseits in der Google App Engine als auch in einem konventionellen Servlet Container (zum
Beispiel Apache Tomcat) betrieben werden kann.
Weiterhin soll untersucht werden, welche Tools den Entwicklungszyklus einer solchen Applikation
bestmöglich unterstützen.
Seite 10 von 83
Masterthesis MT-11-01.04 VEMICO
6 Requirements Model
Im AUP [1] Requirements Model sind neben den klassischen Anforderungen auch die folgenden Modelle
enthalten:




Use Cases
Akzeptanztestfälle
User Interface
Domain Model
6.1 Anforderungen
Die Anforderungen sind gemäß Projektantrag [6] in drei Kategorien („Muss“, „Soll“, „Kann“) priorisiert.



„Muss“: Zwingende Anforderung, wird diese nicht umgesetzt ist das Produkt nicht im
erwarteten Umfang brauchbar
„Soll“: Nützliche Anforderung, welche den Nutzen des Produkts erheblich steigert
„Kann“: Das Fehlen der Anforderung schränkt den Nutzen des Produkts nur unmerklich ein
6.1.1 Verifikation der Anforderungserfüllung
Die Anforderungen sollen einerseits durch automatisierbare Unittests verifiziert werden, andererseits
sollen für die Integrations-, System- und Akzeptanztests Testfälle erstellt und manuell durchgeführt
werden.
6.1.2 Funktionale Anforderungen
Die funktionalen Anforderungen sind in verschiedene Funktionsgruppen unterteilt.
6.1.2.1 Mitglieder
ID
Titel
FA-M1
Mitgliederstamm
FA-M2
Mitgliederhistorie
FA-M3
Anmeldung
Neumitglied
FA-M4
„Self-Care“
FA-M5
Log
Anforderung
Vereinsmitglieder können mit ihren Kontaktdaten (Name,
Email) und der Rolle im Verein verwaltet (Suchen, erfassen,
editieren, löschen) werden
Die Rollen im Verein werden historisiert und können
angezeigt werden
Ein neues Mitglied kann sich online anmelden (in Sinne
eines Antrages zur Aufnahme) und bekommt ein
Bestätigungsmail
Das Vereinsmitglied kann seine Kontaktdaten selbstständig
verwalten
Die Änderungen an den Mitgliederdaten werden
aufgezeichnet und können eingesehen werden
Priorität
Muss
Muss
Soll
Soll
Kann
Seite 11 von 83
Masterthesis MT-11-01.04 VEMICO
6.1.2.2 Newsletter
ID
Titel
FA-N1
Newsletter
erstellen
FA-N2
Verteilerlisten
FA-N3
„Opt-Out“
Funktion
FA-N4
Newsletter Archiv
FA-N5
Andere Kanäle
6.1.2.3 Veranstaltungen
ID
Titel
FA-V1
Veranstaltungen
FA-V2
Anmelden
FA-V3
Medien
FA-V4
Abmelden
Anforderung
Es können Newsletters erstellt und an Verteilerlisten
verschickt werden
Es können Newsletter Verteilerlisten verwaltet werden
Es gibt eine "Self-Care Opt-Out" Funktion, um keine
Newsletters mehr zu erhalten
Die verschickten Newsletter werden gespeichert (mit der
Veranstaltung verknüpft)
Die Newsletter können auch auf Kanälen wie Social Media,
SMS etc. verschickt werden
Priorität
Muss
Anforderung
Die Veranstaltungen können verwaltet werden
Teilnehmer können sich für Veranstaltungen anmelden
Die Präsentationen der Veranstaltungen können hochbzw. runtergeladen und verwaltet werden
Teilnehmer können sich für Veranstaltungen abmelden
Priorität
Muss
Muss
Kann
Soll
Kann
Kann
6.1.2.4 Benutzerverwaltung
ID
Titel
Anforderung
FA-B1
Verwaltung
Es können Benutzer verwaltet werden
FA-B2
Anmeldung
Der Benutzer muss sich authentifizieren
FA-B3
Rollenmodell
Benutzer können Rollen zugewiesen werden. Einer Rolle
können Rechte zugewiesen werden
FA-B4
Passwort
Der Benutzer kann sein Passwort selber setzen und im
Verlustfall vom System ein Neues anfordern
6.1.2.5 Import/Export
ID
Titel
FA-I1
Import/Export
Muss
Muss
Priorität
Muss
Muss
Muss
Soll
Anforderung
Sämtliche Nutzdaten der Anwendung sollen via die
Weboberfläche in Files exportiert und von Files Importiert
werden können
6.1.2.6 Internationalisierung und Lokalisation
ID
Titel
Anforderung
FA-ME1
Internationalisier- Die Anwendung ist lokalisierbar. Benutzer können zwischen
rung
den verschiedenen Sprachen wählen. Die Lokalisierung in
verschiedene Sprachen an sich ist nicht Teil dieser
Anforderung
FA-ME2
Lokalisierung
Die Anwendung kann in Deutsch bedient werden
Priorität
Kann
Priorität
Soll
Muss
Seite 12 von 83
Masterthesis MT-11-01.04 VEMICO
6.1.2.7 Beiträge
ID
Titel
Anforderung
FA-BE1
Beitragszahlungen Die Beitragszahlungen der Mitglieder können verwaltet
werden
6.1.2.8 Vereinsartefakte
ID
Titel
FA-VA1
Vereinsartefakte
Priorität
Soll
Anforderung
Dokumente wie Protokolle etc. können hochgeladen und
verwaltet werden
Priorität
Kann
6.1.3 Nichtfunktionale Anforderungen
Die nichtfunktionalen Anforderungen sind unterteilt in für diese Arbeit spezifische, sowie allgemeine
Anforderungen an eine Anwendung.
6.1.3.1 Spezifische nichtfunktionale Anforderungen
ID
Titel
Anforderung
SNFA-1
Laufzeitumgebung Die Applikation kann sowohl auf einem konventionellen
Applikationsserver (oder Servlet Container) als auch in der
Google App Engine Umgebung betrieben werden
SNFA-2
Persistenz
Die Applikation kann automatisch oder konfigurativ auf die
entsprechenden Persistenzmöglichkeiten der jeweiligen
Plattform eingestellt werden
SNFA-3
Benutzerkonten
Der Benutzer kann sich mit der gleichen Identifikation
authentifizieren, unabhängig wie oder wo die Anwendung
betrieben wird
SFNA-4
Dokumentation
Die gemachten Untersuchungen in Bezug auf SNFA-1 – 3
der
sind unabhängig vom Resultat dokumentiert
Portabilitätsfragen
SNFA-5
EntwicklungsDie Projektdokumentation enthält einen Bericht über die
prozess,
eingesetzten Tools und Frameworks (Spring Roo, Spring
Frameworks und
Toolsuite, GWT GUI Designer, GWT MVP etc.) und die
Tools
damit gemachten Erfahrungen
6.1.3.2 Allgemeine nichtfunktionale Anforderungen
ID
Titel
Anforderung
ANFA-1
Zuverlässigkeit
Die Daten werden gesichert oder können gesichert werden
ANFA-2
Leistung und
Die Antwortzeiten liegen für interaktive Vorgänge unter
Effizienz
fünf Sekunden
ANFA-3
Änderbarkeit
Das System ist so strukturiert, dass zusätzliche
Funktionalität einfach eingebaut werden kann
ANFA-4
Sicherheit
Schützenswerte Daten (speziell Mitgliederdaten) müssen
vor unberechtigtem Zugriff via Benutzeroberfläche oder
Webserver geschützt sein.
Priorität
Soll
Soll
Soll
Muss
Muss
Priorität
Muss
Muss
Muss
Muss
Seite 13 von 83
Masterthesis MT-11-01.04 VEMICO
ANFA-5
ANFA-6
Korrektheit der
Funktionalität
Ergonomie
Abgrenzung: Weitergehende Sicherheitsmassnahmen wie
zum Beispiel Verschlüsselte Kommunikation oder
Datenablage ist nicht erforderlich
Es existieren automatische Unittests um das Funktionieren
der Kernfunktionalität zu verifizieren
Die Anwendung soll nach den Kriterien des ISONORM
9241/10 Fragebogens [7] geprüft werden und ein
genügendes Resultat erzielen
Muss
Muss
Seite 14 von 83
Masterthesis MT-11-01.04 VEMICO
6.2 Use Cases
Obwohl es sich bei den vorliegenden Use Cases (im Gegensatz zu Business Use Cases mit
Anforderungscharakter) eher um System Use Cases1 mit Design Charakter handelt, werden sie trotzdem
hier im Kapitel Requirements Model aufgeführt, um kompatibel mit dem AUP zu bleiben.
Auf oberster Stufe präsentieren sich folgende Anwendungsfälle.
uc Use Case Model
Vemico
UC3 - Benutzer und
Rechte verwalten
UC10 - Anmelden für
Anlass
UC2- Neues Passw ort
v erlangen
Administrator
UC4 - Mailinglisten
v erw alten
UC11 - Abmelden v on
Anlass
«include»
«extend»
UC5 - Personendaten
v erw alten
«include»
Anonymer Benutzer
«include»
UC1 - Anmelden
UC12 - Mitgliedschaft
beantragen
«extend»
«include»
UC6 - Mitgliederbeiträge
v erw alten
Vorstandsmitglied
«include»
UC13 - Von Mailinglisten
abmelden
«include»
UC7 - Anlässe v erw alten
«include»
«include»
UC8 - New sletters
v erw alten/v ersenden
UC9 - Daten importieren
und exportieren
Vereinsmitglied
UC14 - Kontaktdaten
v erw alten
Abbildung 1 Use Case Model
1
http://en.wikipedia.org/wiki/Use_case#Business_vs._System_Use_Cases
Seite 15 von 83
Masterthesis MT-11-01.04 VEMICO
6.2.1 UC1 - Anmelden
Akteure
Benutzer
Vorbedingungen
 Benutzer ist im System bekannt
 Benutzer ist nicht angemeldet
 Benutzer hat Anmeldedaten eingegeben
Auslöser
 Benutzer klickt auf den „Anmelde“ - Button
Hauptszenario
1. Anmeldedaten werden erfolgreich geprüft
2. Benutzer wird am System angemeldet
3. „Welcome Screen“ wird angezeigt
Alternativszenario
1. Anmeldedaten werden nicht erfolgreich geprüft
2. Ein Fehler wird angezeigt
Nachbedingungen
 Benutzer ist am System angemeldet
 Angemeldeter Benutzer wird im „Header“ Bereich angezeigt
6.2.2 UC2 - Neues Passwort verlangen
Das ist eine Erweiterung zum Use Case „UC1- Login“.
Akteure
Vorbedingungen
Auslöser
Hauptszenario
Alternativszenario
Nachbedingungen
Benutzer
 Benutzer ist im System bekannt
 Benutzer ist nicht angemeldet
Benutzer klickt auf „Passwort vergessen“
1. Benutzer gibt seine E-Mail Adresse ein
2. System findet Benutzerdaten, setzt neues Passwort und sendet dieses
per E-Mail an den Benutzer
2a. Falls die E-Mail Adresse nicht gefunden wird, oder E-Mail nicht
verschickt werden kann wird ein Fehler angezeigt
Neues Passwort ist im System gesetzt, E-Mail ist versendet
Seite 16 von 83
Masterthesis MT-11-01.04 VEMICO
6.2.3 UC3 - Benutzer und Rechte verwalten
Das ist ein abstrakter Use Case.
Akteure
Vorbedingungen
Benutzer
Benutzer ist angemeldet
Benutzer hat entsprechende Berechtigung
uc UC3 - Benutzer und Rechte v erw alten
UC3.1 - Benutzer
suchen
UC3.2 - Benutzer
erstellen
UC3 - Benutzer und
Rechte verwalten
UC3.3 - Benutzer
ändern
UC3.5 Rollen und
Module v erw alten
UC3.4 - Benutzer
löschen
Abbildung 2 UC3 - Benutzer und Rechte
6.2.3.1 UC3.1 - Benutzer suchen
Auslöser
Benutzer selektiert Benutzerverwaltungsansicht
Hauptszenario
Sämtliche Benutzer werden in einer Tabelle dargestellt
Alternativszenario
Nachbedingungen
6.2.3.2 UC3.2- Benutzer erstellen
Auslöser
Benutzer selektiert Benutzerverwaltungsansicht
Hauptszenario
1. Benutzer klickt „Neu“
2. Eingabefelder werden ausgefüllt
3. Benutzer klickt „Speichern“
Alternativszenario
Nachbedingungen
 Neuer Benutzer ist angelegt
 E-Mail Adresse des neuen Benutzers wurde in der entsprechenden
System - Mailingliste eingetragen
Seite 17 von 83
Masterthesis MT-11-01.04 VEMICO
6.2.3.3 UC3.3 - Benutzer ändern
Auslöser
Benutzer selektiert Benutzerverwaltungsansicht
Hauptszenario
1. Benutzer wählt den zu ändernden Benutzer in der Auswahlliste
2. Detaildaten werden in den Eingabefeldern angezeigt und werden
geändert
3. Benutzer klickt speichern
Alternativszenario
Nachbedingungen
Neue Benutzerdaten sind gespeichert
6.2.3.4 UC3.4 - Benutzer löschen
Auslöser
Hauptszenario
1. Benutzer selektiert Benutzer und klickt den „Löschen“ Button
2. Es wird eine Warnung angezeigt
3. Bei Bestätigung der Warnung wird der Benutzer gelöscht
Alternativszenario
3a. Warnung wird nicht bestätigt, es passiert nichts
Nachbedingungen
6.2.3.5 UC3.5 - Rollen und Module verwalten
Eine Berechtigung besteht aus der Kombination Rolle und Modul.
Auslöser
Hauptszenario
Alternativszenario
Nachbedingungen
Benutzer selektiert „Rollen und Module“ Ansicht
Benutzer erstellt, modifiziert oder löscht Berechtigungen
Benutzer erfasst neue Rolle
Berechtigungen sind persistiert
6.2.4 UC4 - Mailinglisten verwalten
Akteure
Benutzer
Vorbedingungen
 Benutzer ist angemeldet
 Benutzer hat entsprechende Berechtigung
Auslöser
Benutzer selektiert entsprechende Ansicht
Hauptszenarios
Mailingliste suchen:
1. Sämtliche Mailinglisten werden in einer Tabelle dargestellt
Mailingliste erstellen:
1. Benutzer klickt „Neu“ Button
2. Eingabefeld wird leer, Listenname kann vergeben werden
3. Benutzer klickt „Speichern“
Mailinglisten Namen ändern:
1. Benutzer selektiert Mailliste aus Auswahlliste
2. Im Eingabefeld wird der Listenname angezeigt und kann geändert
werden
3. Benutzer klickt „Speichern“
Mailinglisten Empfänger ändern:
1. Benutzer selektiert Mailliste aus Auswahlliste
Seite 18 von 83
Masterthesis MT-11-01.04 VEMICO
Alternativszenario
Nachbedingungen
2. In einer zweiten Auswahlliste werden Empfänger angezeigt
3. Empfänger können neu erstellt, geändert oder gelöscht werden
4. Benutzer klickt „Speichern“ um die Anpassung zu speichern
Mailingliste löschen:
1. Benutzer selektiert Mailliste aus Auswahlliste
2. Benutzer klickt „Löschen“
3. Bei Bestätigung der Warnung wird der Benutzer gelöscht
Zu „Mailinglisten Empfänger ändern“:
3a. Benutzer wählt im System bereits bekannte Person aus dem „Person
hinzufügen“ DropDown und die Eingabefelder werden automatisch
abgefüllt
Zu „Mailingliste löschen“:
3a. Warnung wird nicht bestätigt, es passiert nichts
Änderungen sind persistiert
6.2.5 UC5 - Personendaten verwalten
Akteure
Benutzer
Vorbedingungen
 Benutzer ist angemeldet
 Benutzer hat entsprechende Berechtigung
Auslöser
Benutzer selektiert entsprechende Ansicht „Personen“
Hauptszenarios
Person suchen:
1. Sämtliche Personen werden in einer Tabelle dargestellt
Person erstellen:
1. Benutzer klickt „Neu“ Button
2. Eingabefelder werden leer, Personendetails können erfasst werden
3. Benutzer klickt „Speichern“
Person ändern:
1. Benutzer selektiert Person aus Auswahlliste
2. In den Eingabefeldern werden Personendetails angezeigt und können
geändert werden
3. Benutzer klickt „Speichern“
Person löschen:
1. Benutzer selektiert Person aus Auswahlliste
2. Benutzer klickt „Löschen“
3. Bei Bestätigung der Warnung wird die Person gelöscht
Engagements verwalten:
1. Benutzer selektiert Person aus Auswahlliste
2. In einer weiteren Tabelle werden die Engagements einer Person
angezeigt und können mit den üblichen Funktionen verwaltet werden
Alternativszenario
Zu „Person erstellen“:
1a. Benutzer öffnet „Anträge“ Sicht
2a. Benutzer wählt einen Antrag aus Auswahlliste
3a. Benutzer klickt „übernehmen“
Zu „Person löschen“:
Seite 19 von 83
Masterthesis MT-11-01.04 VEMICO
3a. Warnung wird nicht bestätigt, es passiert nichts
Nachbedingungen


Daten sind gespeichert
Die geänderten Datensätze enthalten ein „Worklog“ Felder wo der
erstellenden sowie der letzte ändernde Benutzer sowie das jeweilige
Datum gespeichert ist
6.2.6 UC6 - Mitgliederbeiträge verwalten
Das ist eine Erweiterung zum „UC5 – Personendaten verwalten“
Akteure
Vorbedingungen
Auslöser
Hauptszenario
Benutzer
 Benutzer ist angemeldet
 Benutzer hat entsprechende Berechtigung
Benutzer selektiert Ansicht „Personen“
Die Mitgliederbeiträge werden als Attribut eines Engagements geführt, die
Verwaltung passiert daher innerhalb des Use Cases „UC5 – Personendaten
verwalten“
Alternativszenario
Nachbedingungen
6.2.7 UC7 - Anlässe verwalten
Akteure
Benutzer
Vorbedingungen
 Benutzer ist angemeldet
 Benutzer hat entsprechende Berechtigung
Auslöser
Benutzer selektiert entsprechende Ansicht „Anlässe“
Hauptszenarios
Anlass suchen:
1. Sämtliche Anlässe werden in einer Tabelle dargestellt
2. Die via „Selfcare Portal“ angemeldeten Teilnehmer sind in einer
zweiten Auswahlliste ersichtlich
Anlass erstellen:
1. Benutzer klickt „Neu“ Button
2. Eingabefelder werden leer, Anlassdetails können erfasst werden
3. Benutzer klickt „Speichern“
Anlass ändern:
1. Benutzer selektiert Anlass aus Auswahlliste
2. In den Eingabefeldern werden Anlassdetails angezeigt und können
geändert werden
3. Benutzer klickt „Speichern“
Anlass löschen:
1. Benutzer selektiert Anlass aus Auswahlliste
2. Benutzer klickt „Löschen“
3. Bei Bestätigung der Warnung wird der Anlass gelöscht
Alternativszenario
Zu „Anlass löschen“:
Seite 20 von 83
Masterthesis MT-11-01.04 VEMICO
3a. Warnung wird nicht bestätigt, es passiert nichts
Nachbedingungen


Die Änderungen sind gespeichert
Die Änderungen sind auf der „Selfcare Portal“ Ansicht sichtbar
6.2.8 UC8 - Newsletters verwalten/versenden
Akteure
Benutzer
Vorbedingungen
 Benutzer ist angemeldet
Auslöser
Hauptszenarios
Alternativszenario
Nachbedingungen
 Benutzer hat entsprechende Berechtigung
Benutzer selektiert entsprechende Ansicht „Newsletters“
Newsletter suchen:
1. Sämtliche Newsletters werden in einer Tabelle dargestellt
Newsletter erstellen:
1. Benutzer klickt „Neu“ Button
2. Eingabefelder werden leer, Newsletter Details können erfasst werden
3. Es können Empfängerlisten ausgewählt sowie einzelne
Empfängeradressen eingegeben werden
4. Benutzer klickt „Speichern“
Newsletter ändern:
1. Benutzer selektiert Newsletter aus Auswahlliste
2. In den Eingabefeldern werden Newsletter Details angezeigt und
können geändert werden
3. Benutzer klickt „Speichern“
Newsletter löschen:
1. Benutzer selektiert Newsletter aus Auswahlliste
2. Benutzer klickt „Löschen“
3. Es wird eine Warnung angezeigt
4. Bei Bestätigung der Warnung wird der Newsletter gelöscht
Newsletter senden:
1. Benutzer selektiert Newsletter aus Auswahlliste wo mindestens ein
Empfänger erfasst ist
2. Benutzer klickt „Senden“
3. Es wird eine Warnung angezeigt
4. Bei Bestätigung der Warnung wird der Newsletter gesendet
Zu „Newsletter löschen“:
4a. Warnung wird nicht bestätigt, es passiert nichts
Zu „Newsletter senden“:
4a. Warnung wird nicht bestätigt, es passiert nichts
Zu „Newsletter senden“:
 In der Auswahlliste wird „Gesendet Am“ mit dem aktuellen
Zeitstempel nachtgeführt
6.2.9 UC9 - Daten importieren/exportieren
Akteure
Benutzer
Seite 21 von 83
Masterthesis MT-11-01.04 VEMICO
Vorbedingungen
Auslöser
Hauptszenario
Alternativszenario
Nachbedingungen
 Benutzer ist angemeldet
 Benutzer hat entsprechende Berechtigung
 Für Import: Es sind keine Daten im System vorhanden
Benutzer selektiert entsprechende Ansicht „Import/Export“
1. Benutzer selektiert Quell- bzw. Zielfile
2. Benutzer klickt „Upload“ bzw. „Download“
2a. Bei Upload wird eine Warnung angezeigt falls bereits Daten im System
vorhanden sind
Die Daten sind exportiert, bzw. importiert
6.2.10 UC10 - Anmelden für Anlass
Akteure
Anonymer Benutzer
Vorbedingungen
Auslöser
Anonymer Benutzer ruft entsprechende Seite im Selfcare Portal auf
Hauptszenario
1. Anonymer Benutzer selektiert Anlass und gibt Name, Vorname und EMail Adresse ein
2. Anonymer Benutzer klickt „Anmelden“
3. Bestätigung wird angezeigt, E-Mail wird versendet
Alternativszenario
3a. Falls Benutzer bereits angemeldet ist wird ein Fehler angezeigt
Nachbedingungen
Benutzer ist in die Liste der Teilnehmer des Anlasses eingetragen
6.2.11 UC11 - Abmelden von Anlass
Akteure
Anonymer Benutzer
Vorbedingungen
Anonymer Benutzer ist für Anlass angemeldet
Auslöser
Anonymer Benutzer ruft entsprechende Seite im Selfcare Portal auf
Hauptszenario
1. Anonymer Benutzer selektiert Anlass und gibt E-Mail Adresse ein
2. Anonymer Benutzer klickt „Abmelden“
3. Bestätigung wird angezeigt, E-Mail wird versendet
Alternativszenario
3a. Falls E-Mail Adresse nicht gefunden wird, wird ein Fehler angezeigt
Nachbedingungen
Benutzer ist aus Liste der Teilnehmer des Anlasses entfernt
6.2.12 UC12 - Mitgliedschaft beantragen
Akteure
Anonymer Benutzer
Vorbedingungen
Auslöser
Anonymer Benutzer ruft entsprechende Seite im Selfcare Portal auf
Hauptszenario
1. Anonymer Benutzer füllt Formular aus
2. Anonymer Benutzer klickt „Senden“
Alternativszenario
Nachbedingungen
Antrag ist gespeichert
Seite 22 von 83
Masterthesis MT-11-01.04 VEMICO
6.2.13 UC13 – Von Mailinglisten abmelden
Akteure
Anonymer Benutzer
Vorbedingungen
Auslöser
Anonymer Benutzer ruft entsprechende Seite im Selfcare Portal auf
Hauptszenario
1. Anonymer Benutzer füllt Formular aus
2. Anonymer Benutzer klickt „Austragen“
Alternativszenario
Nachbedingungen
Entsprechendes Personenobjekt hat „receivesEmail“ - Flag auf „false“ gesetzt
6.2.14 UC14 – Kontaktdaten verwalten
Beim Verwalten der Kontaktdaten ist es wichtig, dass die Benutzer nur Ihre eigenen Daten sehen und
editieren können (Benutzer erstellen allerdings Ihre Daten nicht selber). Um das zu erreichen gibt es
zwei Möglichkeiten:


Explizites Einrichten entsprechender Berechtigungen pro Benutzer auf den jeweiligen
Datenobjekten durch den Administrator
Implizites berechtigen, z.B. durch Speichern des Benutzernamens auf dem Personenobjekt
In einer ersten Version des Systems wird die zweite Variante umgesetzt, der Pflegeaufwand für die erste
Variante wäre zu hoch.
Akteure
Vorbedingungen
Auslöser
Hauptszenario
Alternativszenario
Nachbedingungen
Benutzer
Benutzer ist angemeldet und hat entsprechende Rechte
Vereinsmitglied meldet sich an um seine eigenen Kontaktdaten zu editieren
1. Vereinsmitglied meldet sich am System an
2. Kontaktdaten werden angezeigt (nur die eigenen)
3. Kontaktdaten werden editiert und gespeichert
Kontaktdaten sind mutiert
Seite 23 von 83
Masterthesis MT-11-01.04 VEMICO
6.3 Akzeptanztestfälle
Als Ergänzung zu den Use Cases wurden weitere Testfälle zur Verifikation der funktionalen
Anforderungen erstellt. Akzeptanz Testfälle sind in AUP [1] Teil des Requirements Model und werden
deshalb an dieser Stelle aufgeführt.
AUP verweist zur Strukturierung von Testfällen auf die Webseite agilemodeling.com1, von wo die
vorliegende Struktur übernommen wurde.
6.3.1
Mitgliederstamm
6.3.1.1 FA-M1-T1, Neue Person
Vorbedingungen
Es existiert keine Person mit einer bestimmten E-Mail Adresse
Instruktionen
Es wird eine neue Person erfasst, entweder via „Mitglieder“ View oder via
„Anträge“ View
Erwartetes Resultat  In der Systemmailingliste „All“ ist die neue Person eingetragen

Es wurde ein Benutzer mit der Rolle „Member“ erstellt. Der
Benutzername, das Passwort und die E-Mail Adresse entsprechen der
E-Mail Adresse der Person
6.3.1.2 FA-M1-T2, Person löschen
Vorbedingungen
Es existiert eine Person
Instruktionen
Person löschen
Erwartetes Resultat  In der Systemmailingliste „All“ ist die Person ausgetragen

Der Benutzer mit der entsprechenden Person ist gelöscht
6.3.1.3 FA-M1-T3, Person ändern
Vorbedingungen
Es existiert eine Person
Instruktionen
Name und E-Mail Adresse der Person ändern
Erwartetes Resultat  In der Systemmailingliste „All“ ist die neue Email Adresse nachgeführt
 Die Daten des entsprechenden Benutzers sind nachgeführt
6.3.1.4 FA-M1-T4, Person ändern nach Opt Out
Vorbedingungen
Es existiert eine Person
Instruktionen
 Mit den Angaben der Person den Use Case UC13 – Abmelden von
Mailinglisten ausführen
 E-Mail Adresse der Person ändern
Erwartetes Resultat In der Systemmailingliste „All“ ist die neue Email Adresse nicht wieder
eingetragen worden
1
http://www.agilemodeling.com/artifacts/acceptanceTests.htm
Seite 24 von 83
Masterthesis MT-11-01.04 VEMICO
6.3.2
Mitgliederdaten
6.3.2.1 FA-M3-T1, Log Ablehnung Mitgliedschaft
Vorbedingungen
Es existiert ein Mitgliedschaftsantrag
Instruktionen
Antrag ablehnen
Erwartetes Resultat Es existiert ein Log Eintrag, zum Beispiel:
INFO: 2011-08-16 01:51:32 (User: m): Der Mitglieds Antrag für B
A([email protected]) wurde abgelehnt
6.3.2.2 FA-M4-T1, Eindeutige E-Mail Adresse Person
Da die Synchronisation der Benutzer und Mitgliederdaten im „Selfcare“ Fall via Username passiert und
als Username die E-Mail Adresse genommen wird, soll eine Personen E-Mail Adresse eindeutig sein.
Vorbedingungen
Instruktionen
Erwartetes Resultat
Es existiert eine Person mit einer E-Mail Adresse
Es wird eine weitere Person mit der gleichen E-Mail Adresse erfasst, entweder
via „Mitglieder“ View oder via „Anträge“ View
Es wird eine Fehlermeldung angezeigt
6.3.2.3 FA-M5-T1, Audittrail
Änderungen an Personendaten werden mittels „Audittrail“ (Felder „Erstellt am“, „Erstellt von“,
„Geändert am“, „Geändert von“) aufgezeichnet.
Vorbedingungen
Instruktionen
Erwartetes Resultat
Person ist erstellt
Personendaten ändern
Audittrail Felder enthalten korrekte Werte
6.3.2.4 FA-M5-T2 Logfile Person
Wenn eine Person gelöscht wird, soll dies im Logfile festgehalten werden.
Vorbedingungen
Instruktionen
Erwartetes Resultat
Es existiert eine Person mit Engagement(s)
Person löschen
Es existiert ein Logfile Eintrag der gelöschten Person und deren Engagements,
zum Beispiel:
INFO: 2011-08-16 12:36:07 (User: m): Deleted Person: Ukel Urs,
[email protected]
INFO: 2011-08-16 01:08:57 (User: m): Deleted Engagement:
Mitglied, 01.08.2011-31.08.2011 (SFr. 20.00) of Person: Ukel Urs,
[email protected]
6.3.2.5 FA-M5-T3 Logfile Engagement
Wenn ein Engagement gelöscht wird, soll dies im Logfile festgehalten werden.
Vorbedingungen
Instruktionen
Erwartetes Resultat
Es existiert ein Engagement
Engagement löschen
Es existiert ein Logfile Eintrag, zum Beispiel:
INFO: 2011-08-16 01:08:57 (User: m): Deleted Engagement:
Seite 25 von 83
Masterthesis MT-11-01.04 VEMICO
Mitglied, 01.08.2011-31.08.2011 (SFr. 20.00) of Person: Ukel Urs,
[email protected]
6.3.3
Newsletter
6.3.3.1 FA-N1-T1, Newsletter kann nur einmal gesendet werden
Vorbedingungen
Es existiert ein Newsletter der bereits versendet wurde („Gesendet Am“ Feld
enthält einen Wert)
Instruktionen
Erwartetes Resultat „Senden“ Knopf ist deaktiviert
6.3.3.2 FA-N3-T1, Abmelden Mailinglisten
Vorbedingungen
Eine E-Mail Adresse ist auf diversen Mailinglisten eingetragen
Instruktionen
Via Selfcare View Abmeldung von allen Mailinglisten beantragen
Erwartetes Resultat E-Mail Adresse ist aus allen Mailinglisten entfernt, Bestätigungsmail wurde
versendet
6.3.4
Benutzerverwaltung
6.3.4.1 FA-B2-T1 Login
Vorbedingungen
Benutzer ist abgemeldet
Instruktionen
 Korrekten Benutzername und Passwort eingeben
Erwartetes Resultat



„Anmelden“ Schaltfläche drücken
Es wird der „Welcome“ Screen angezeigt
Oben rechts wird der angemeldete Benutzer angezeigt
6.3.4.2 FA-B2-T2 Fehlerhaftes Login
Vorbedingungen
Benutzer ist abgemeldet
Instruktionen
 Falschen Benutzername oder falsches Passwort eingeben
 „Anmelden“ Schaltfläche drücken
Erwartetes Resultat Es wird ein Fehler angezeigt
6.3.4.3 FA-B4-T1, Eindeutige E-Mail Adresse Benutzer
Damit die Passwort Anforderung via E-Mail Adresse funktioniert muss eine Benutzer E-Mail Adresse
eindeutig sein.
Vorbedingungen
Instruktionen
Erwartetes Resultat
Es existiert ein Benutzer mit einer E-Mail Adresse
Es wird eine weiterer Benutzer mit der gleichen E-Mail Adresse erfasst
Es wird eine Fehlermeldung angezeigt
Seite 26 von 83
Masterthesis MT-11-01.04 VEMICO
6.3.5
Internationalisierung und Lokalisation
6.3.5.1 FA-ME1-T1, Sprache umstellen via GUI
Vorbedingungen
Benutzer ist abgemeldet
Instruktionen
 Link „Sprache ändern“ wählen
Erwartetes Resultat
 Im Dialog die neue Sprache wählen
 Bestätigen
Login Screen wird in der gewählten Sprache angezeigt
6.3.5.2 FA-ME1-T2, Gewählte Sprache Browser Cookie
Vorbedingungen
Benutzer ist abgemeldet
Instruktionen
 Link „Sprache ändern“ wählen
Erwartetes Resultat
 Im Dialog die neue Sprache wählen
 Bestätigen
 Browser schliessen
 Browser wieder öffnen und zum Login Screen navigieren
Login Screen wird in der zuletzt gewählten Sprache angezeigt
6.3.5.3 FA-ME1-T3, Sprache umstellen via URL
Vorbedingungen
Benutzer ist abgemeldet
Instruktionen
 Im Browser an die VEMICO URL den Parameter Zusatz „?lang=en“ (für
Englisch) anfügen, zum Beispiel:
 http://vemico-guild42-dev.appspot.com/?lang=en oder
 http://vemico-guild42-dev.appspot.com/?RegisterForEvent&lang=en
 Seite laden
Erwartetes Resultat Login Screen wird in der gewählten Sprache angezeigt
6.3.5.4 FA-ME2-T1, Lokalisation in Deutsch
Vorbedingungen
Benutzer ist abgemeldet
Instruktionen
 Link „Sprache ändern“ wählen
Erwartetes Resultat
6.3.6
 Im Dialog die neue Sprache „German“ (oder „Deutsch“) wählen
 Bestätigen
 Einloggen
Anwendung wird in Deutsch ausgeführt
Spezifische nichtfunktionale Anforderungen
6.3.6.1 SFNA1-T1, Anwendung läuft in GAE und Apache Tomcat
Vorbedingungen
Benutzer ist abgemeldet
Instruktionen
 Link „Sprache ändern“ wählen
 Im Dialog die neue Sprache „German“ (oder „Deutsch“) wählen
 Bestätigen
Seite 27 von 83
Masterthesis MT-11-01.04 VEMICO
Erwartetes Resultat
 Einloggen
Anwendung wird in Deutsch ausgeführt
6.4 User Interface Model
Das komplette User Interface Model befindet sich im separaten, navigierbaren Dokument
Vemico/doc/uimodel/VemicoUserInterfaceModel.pdf.
Grundsätzlich entspricht der Aufbau einer klassischen, konventionellen Desktop Anwendung mit
Header, Navigation und Content Bereich.
Header
Navigation
Content
Abbildung 3 User Interface Main Layout
Als Navigationsmenü kommt eine „Accordeon“ Komponente zum Einsatz, was im Prinzip ein vertikales
„TabbedPanel“ ist.
Der Content Bereich der einzelnen Ansichten ist meist nach der „Master-Detail“1 Metapher aufgebaut.
1
http://de.wikipedia.org/wiki/Master-Detail-Beziehung
Seite 28 von 83
Masterthesis MT-11-01.04 VEMICO
6.5 Domain Model
Das Domain Model zeigt die beteiligten Entitäten aus fachlicher Sicht. Die technische Umsetzung wird im
Design Model definiert.
6.5.1 Fachliche Entitäten
Aus fachlicher Sicht lässt sich das folgende Domain Model zeichnen.
class Application Domain Model
Mitglieds Antrag
1
stellt einen
1
Mailingliste
hat in einer
Zeitspanne
Person
Enthält
0..*
1..*
1..*
1..*
0..*
1
1
1
bezahlt für eine Zeitspanne
hat Liste der Teilnehmer
wird verschickt an
Rolle
nimmt teil an
1
Mitgliederbeitrag
0..*
0..*
New sletter
Anlass
bezieht sich auf1
0..*
1
Abbildung 4 Domain Model
Die Verwaltung der Teilnehmer eines Anlasses geschieht über die entsprechende Anlass Mailingliste. Die
Vereinsrolle und der Mitgliederbeitrag haben beide die Eigenschaft, dass sie für eine bestimmte Zeit
gelten. Dieser Tatsche soll bei der technischen Modellierung Rechnung getragen werden.
Seite 29 von 83
Masterthesis MT-11-01.04 VEMICO
7 Design Model
Vollkommenheit ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt,
sondern dann, wenn nichts mehr weggelassen werden kann.
(Antoine de Saint-Exupéry, "Wind, Sand und Sterne", 1939)
7.1 Technologiestudie
Bevor die Architektur, das technische Detail Design und der Entwicklungsprozess, bzw. die
Entwicklungsumgebung festgelegt werden können, sollen mögliche Alternativen geprüft und bewertet
werden.
7.1.1 Ziele und Anforderungen
Neben der speziellen Anforderung, dass als Laufzeitumgebung sowohl die „Cloud“ (Google App Engine)
als auch ein konventioneller Servlet Container (Apache Tomcat) unterstützt werden muss, erfordern
typische (Web-) Anwendungen wie die Vorliegende meistens immer die gleichen Grundfunktionalitäten:






(Client-/Server) Kommunikation
Authentifizierung und Autorisierung
Konzept zur Modularisierung der Applikationsteile (im Sinne von loser Kopplung und Kapselung)
Lebenszyklus der Applikation
Persistenz
Internationalisierung, Error Handling, Logging
Ein Auftraggeber möchte normalerweise nicht, dass sich seine Entwickler mit diesen typischen
Problemen herumschlagen, weil man sich dadurch in der Regel nicht von der Konkurrenz abheben kann.
Ein Entwickler soll sich auf die Implementierung der eigentlichen Geschäftslogik konzentrieren können.
Ein allgemeines Ziel, und damit auch ein implizites Ziel bei der vorliegenden Masterthesis ist es,
möglichst Bestehendes zu nutzen und nicht „das Rad neu zu erfinden“.
Die VEMICO Anwendung soll auf einem möglichst kompletten Anwendungsframework aufgebaut
werden oder ein solches schaffen, damit die Applikation auf einfache Weise erweitert werden kann
(vergleiche auch Anforderung ANFA-3).
7.1.2 Rahmenbedingungen
Da es sehr viele Entwicklungsumgebungen, Build- und Produktivitätstools sowie AnwendungsFrameworks gibt, sollen gewisse Einschränkungen helfen, den Rahmen dieser Arbeit nicht zu sprengen:




Als Entwicklungsumgebung soll Eclipse zum Einsatz kommen, da es hierfür aktuell wohl die
meisten Erweiterungen („Plugins“) gibt
Für das Rendering der visuellen Komponenten im Browser soll GWT eingesetzt werden
Als Cloud Zielplattform soll Google App Engine dienen, das es sich um ein (bis zu einer gewissen
Quota) kostenloses PaaS Angebot handelt
Der konventionelle Infrastruktur soll aus Apache Tomcat und MySQL, die am weitesten
verbreitete frei verfügbare Kombination von Servlet Container und relationaler Datenbank
Seite 30 von 83
Masterthesis MT-11-01.04 VEMICO
7.1.3 Standards und Best Practices
Wenn es für etwas einen Standard gibt, kann man typischerweise auf eine Implementation des
Standards zur Lösung eines wiederkehrenden Problems zurückgreifen. Wo Standards fehlen, helfen oft
„Best Practices“ (Muster, Konventionen) weiter. Beispiele:




In der JavaEE Welt gibt es neben vielen Standards sogenannte „Blueprints“ welche eine
Referenzarchitektur für JavaEE Anwendungen vorgeben. Eine Möglichkeit, eine eigene JavaEE
AJAX Applikation zu schreiben ist es, die Java Pet Store Applikation [8] herunterzuladen und
darauf aufzubauen
In der Microsoft Welt, wo „Visual Studio“ die de-facto Standard Entwicklungsumgebung ist, wird
der typische Aufbau einer Client Anwendung durch die verschiedenen „Wizards“ vorgegeben
Der JSR-296 [9] spezifiziert ein Framework für eine typische Java Swing Desktop Applikation
Mit Eclipse RCP und neu mit Eclipse E4 existiert eine weiterer de-facto Standard für Java
Desktop Anwendungen. Statt Swing wird das native Standard Widget Toolset „SWT“ eingesetzt,
die Plattform bietet die typischen Dienste wie Logging etc. als OSGI Services. Eclipse basierte
Frameworks wie Scout1 oder Riena2 versprechen einen noch rascheren Aufbau eigener multi-tier
Business Anwendungen.
Für das Problem „wie ist eine etwas grössere GWT Applikation aufgebaut“ gibt es keinen Standard.
GWT „Out-of-the-box“ bietet zwar seit Version 2.1 sein aus „Activities und Places“ (entspricht
Presenters und Views) bestehendes „MVP Framework“ sowie eine EventBus Implementierung. Dieses ist
aber eher auf klassische „web-style“ Anwendungen zugeschnitten, „application-style“ wird nicht
unmittelbar unterstützt. Die Google MVP Dokumentation3 sagt dazu:
„What about apps with multiple panels in the same window whose state should all be saved
together in a single URL? GWT 2.1 does not attempt to provide a generic implementation of a composite
Place; however, your app could create a CompositePlace, CompositeActivity, and
CompositePlace.Tokenizer classes that delegate to the constituent members. In this case, only the
composite objects would need to be registered with your app's ActivityMapper and
PlaceHistoryMapper.“
Aus diesem Grund existieren einige Anwendungsframeworks (welche in erster Linie MVP Support
bieten) sowie Persistenz- und Kommunikationsframeworks, welche mit den Anwendungsframeworks
kombiniert werden können. Selbst für die Internationalisierung hat man die in GWT die Wahl zwischen
drei Techniken.
Diese vielen Kombinationsmöglichkeiten bieten einerseits eine sehr grosse Flexibilität, führen aber auch
dazu, dass sich jedes Projekt von neuem Gedanken zum Aufbau seiner Anwendung machen muss und
jede Anwendung schlussendlich anders aufgebaut ist.
In den folgenden Kapiteln werden einige Frameworks und Tools beschrieben.
1
http://www.eclipse.org/scout/
2
http://www.eclipse.org/riena/
3
http://code.google.com/intl/de-CH/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html#How_to_navigate
Seite 31 von 83
Masterthesis MT-11-01.04 VEMICO
7.1.4 Kommunikationsframeworks für GWT
Da reine GWT Anwendungen grundsätzlich als HTML/Javascript Applikationen im Browser laufen,
braucht es zur Kommunikation zu einem Server eine geeignete Infrastruktur.
7.1.4.1 GWT-RPC
GWT-RPC1 war die ursprüngliche, von Google selber angebotene Alternative zu den „http client classes“2
(native http Kommunikation). Man kann durch Implementieren, beziehungsweise Erben von Interfaces
und Klassen einigermassen einfach ein sehr flexibles Service Layer bauen.
7.1.4.2 RequestFactory
Im Gegensatz zu GWT-RPC ist das ebenfalls von Google selber angebotene „RequestFactory“ vor allem
für datenzentrierte Anwendungen und typische CRUD Funktionen gedacht. Man kann für Entities (im
Sinne von JPA oder JDO) Proxies generieren, welche die Client-Server Kommunikation weitgehend
kapseln. Man braucht weniger zu schreiben als bei GWT-RPC, ist dafür weniger flexibel.
7.1.5 Anwendungsframeworks für GWT
Anwendungsframeworks bieten in der Regel über die reine Kapselung der Client/Server Kommunikation
vor allem Unterstützung bei der Modularisierung einer Applikation.
7.1.5.1 GWTP (GWT Platform)
Die Hauptfeatures des sehr aktiven Projekt GWTP3 sind ein MVP Modell, „Dependency Injection“ und
Unterstützung für Suchmaschinen Indexierung. Das Framework ist recht mächtig, ein solides Verständnis
der GWT Konzepte ist jedoch Voraussetzung um es zu nützen.
7.1.5.2 MPV4G
„MPV for GWT“4 verfolgt ähnliche Ziele wie GWT Platform, ist aber ein wenig einfacher gehalten und hat
einige gute Beispiele, welche als Basis für eine eigene Implementation dienen können.
7.1.5.3 Vaadin
Vaadin [10] geht einen ganz anderen Weg als die ersten beiden Frameworks. Hier wird auschliesslich
Server Code programmiert, die ganze Kommunikation zu den GWT Client Komponenten wird vom
Vaadin gekapselt. Obwohl es möglich ist, ausschliesslich in Java zu programmieren, sind zumindest
rudimentäre CSS und HTML Kenntnisse hilfreich.
Als „Add-On“ zu Vaadin existiert die sogenannte „appfoundation“ [11], welche einige der typischen, in
einer Webapplikation benötigten Funktionalität (siehe Kapitel „Ziele und Anforderungen“) zur
Verfügung stellt.
1
http://code.google.com/intl/de-CH/webtoolkit/doc/latest/DevGuideServerCommunication.html#DevGuideRemoteProcedureCalls
2
http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/http/client/package-summary.html
3
http://code.google.com/p/gwt-platform/
4
http://code.google.com/p/mvp4g/
Seite 32 von 83
Masterthesis MT-11-01.04 VEMICO
7.1.6 Persistenzframeworks für Google App Engine
Die Persistenzschicht der Google App Engine ist keine traditionelle relationale Datenbank sondern der
„Google Data Store“. Der Data Store basiert auf dem Google BigTable1 Konzept und ist optimiert für
grosse Datenmengen, welche zwar stetig wachsen aber eher selten ändern. Er wird oft mit einer (recht
grossen) Map verglichen. Zugriff auf den Datastore ist auf drei Arten möglich:



Low Level API (für Java, Python und GO)
JDO
JPA
7.1.6.1 Objectify
Objectify2 setzt auf dem Google Datastore Java Low Level API auf und erlaubt es mit POJO‘s und
Annotationen (ähnlich wie JPA) zu arbeiten.
7.1.6.2 Twig-persist
Twig3 beansprucht für sich, noch einfacher als Objectify zu funktionieren, wie die folgenden
Gegenüberstellungen illustrieren sollen.
Abbildung 5 Objectify vs. Twig
Bei den Klassendefinitionen kann mit Twig eine Abstraktionsstufe höher als mit Objectify gearbeitet
werden.
Abbildung 6 Objectify vs. Twig
Auch der Zugriff auf Felder eines Entitätsobjekts sieht ein wenig einfacher aus.
1
http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/de//papers/bigtable-osdi06.pdf
2
http://code.google.com/p/objectify-appengine/
3
http://code.google.com/p/twig-persist/
Seite 33 von 83
Masterthesis MT-11-01.04 VEMICO
7.1.6.3 JPA
Der JPA Standard scheint sich in der Java EE Welt je länger je mehr durchzusetzen. Es existieren viele
Implementationen, in der Google App Engine wird Datanucleus (vormals bekannt als „JPOX“)
verwendet. JPA ist für den Einsatz mit relationalen Systemen ausgelegt, entsprechend eingeschränkt ist
der in der App Engine zur Verfügung stehende Funktionsumfang1.
7.1.6.4 JDO
In der Google App Engine kann auch mittels JDO (ebenfalls via Datanucleus) auf den Datastore
zugegriffen werden. JDO ist zwar nicht ausschliesslich für die Verwendung mit relationalen Systemen
konzipiert, aber auch der Funktionsumfang von JDO ist in der App Engine erheblich eingeschränkt2.
Die Apache JDO Webseite3 bietet übrigens einen kompakten Vergleich von JDO und JPA.
7.1.7 Buildtools
Der Build Vorgang eines Softwareproduktes umfasst typischerweise Schritte wie kompilieren, testen,
Bauen eines ausführbaren Artefaktes, Reports erstellen, Deployment auf einen (Test-)Rechner und so
weiter. Build Tools lassen eine Definition und Automatisierung dieses Vorgangs zu.
7.1.7.1 Eclipse
In Eclipse (wie auch in anderen IDE‘s) lässt sich bei einem Projekt der Buildvorgang via die grafische
Oberfläche beeinflussen.
7.1.7.2 Ant
Mit Apache Ant lassen sich Build Scripts deklarativ definieren, für viele Aufgaben gibt es vordefinierte
sogenannte „Tasks“. Als Ergänzung zur Abhängigkeitsverwaltung (Bibliotheken) bietet sich Apache Ivy
an.
7.1.7.3 Maven
Das Problem mit Ant ist, dass es keine Vorgaben macht zur Projektstruktur oder zum Projekt „Lifecylce“.
Das führt dazu, dass jedes Projekt ein wenig anders aussieht und immer wiederkehrende Sachen immer
wieder von neuem definiert werden.
Apache Maven folgt dem „Convention over Configuration“ Ansatz und geht davon aus, dass 80% aller
Software Projekte immer etwa die gleichen Schritte erfordern. Man muss also nur Abweichungen von
der „Norm“ explizit konfigurieren, wenn man sich an die „Norm“ hält, ist der Rest implizit bereits
definiert.
Sowohl für Ant und Ivy als auch für Maven existieren Erweiterungen für die gängigen IDE‘s.
1
http://code.google.com/intl/de-CH/appengine/docs/java/datastore/jpa/overview.html
2
http://code.google.com/intl/de-CH/appengine/docs/java/datastore/jdo/
3
http://db.apache.org/jdo/jdo_v_jpa.html
Seite 34 von 83
Masterthesis MT-11-01.04 VEMICO
7.1.8
Produktivitätstools
7.1.8.1 SpringRoo
Die Idee hinter SpringRoo1 ist es, beim Entwickeln in oder neben der Entwicklungsumgebung eine
interaktive Kommandozeile (Shell) offen zu haben, wo mit einfachen Kommandos ganze, immer
wiederkehrende Befehlsketten, also „Makros“ ausgelöst werden können um Konfigurationen und Code
zu generieren.
Spring Roo basiert auf Maven und ist erweiterbar: es existieren Erweiterungen für GWT, App Engine,
JPA, Vaadin und so weiter.
Das Ganze ist ein interessanter Ansatz, in der Praxis ergeben sich die folgenden Probleme:
1. Ein Tool zu haben, welches einen Haufen Code und Konfigurationsfile generiert ist gut, ein
Framework zu verwenden welches mit wenig Code und Konfiguration auskommt ist besser.
2. Je nach Technologie Stack ist die Integration der verschiedenen notwendigen Erweiterungen in
eine Entwicklungsumgebung nicht ganz unproblematisch, weil es plötzlich verschiedene Plugins
für dieselben Artefakte gibt welche sich in die Quere kommen können. Die Lösung solcher
Probleme kann recht zeitaufwändig sein und rentiert nur, wenn man anschliessend öfters
gleichartige Projekte hat.
3. Die meisten Plugins für SpringRoo gehen aus nachvollziehbaren Gründen von einem
„homogenen“ Architekturstack (zum Beispiel nur eine Persistenz Plattform) aus. Natürlich
können die speziellen Änderungen nach erfolgter, erstmaliger Generierung von Hand eingebaut
werden. Das macht aber nur dann Sinn, wenn der Aufwand unter Punkt 2 in einem vernünftigen
Verhältnis steht.
7.1.8.2 Maven Shell
Der Hauptidee von Maven Shell2 ist es, dass man ständig eine VM am Laufen hat damit bei häufigem
Durchlaufen des Maven Build Prozesses nicht immer Zeit verloren wird mit dem Laden der VM.
1
http://www.springsource.org/roo/why
2
http://shell.sonatype.org/
Seite 35 von 83
Masterthesis MT-11-01.04 VEMICO
7.1.9 Auswahl, Entscheid und Begründung
Aufgrund der grossen Anzahl von Architekturen, Frameworks, Tools und deren mögliche Kombinationen
würde ein vollständiges und systematisches Auswahlverfahren den Rahmen der vorliegenden Arbeit
sprengen. Es wird daher „heuristisch“, aufgrund der Erfahrungen beim Ausprobieren in der
Prototypingphase entschieden.
Eine komplette Übersicht der schlussendlich eingesetzten Technologien findet sich im Kapitel
„Configuration Management“.
7.1.9.1 Architektur
Für das vorliegende Projekt scheint das Vaadin Framework zusammen mit dem „appfoundation“ Add-On
und JPA/Datanucleus als Persistenzschicht als die beste Wahl. Vaadin und „appfoundation“ bieten
zusammen ein reichhaltiges Fundament für eine typische Webapplikation.
Die anderen Anwendungsframeworks bieten einen zu wenig kompletten Funktionsumfang, die
untersuchten Persistenzframeworks funktionieren nur in der Google App Engine.
Gemäss den Vorgaben im Kapitel „Ziele und Anforderungen“


auf einem möglichst kompletten Anwendungsframework aufzubauen
und „das Rad nicht neu zu erfinden“
soll ein auf „appfoundation“ basierendes Anwendungsframework gebaut werden, welches von
Anwendungen wie VEMICO wiederverwendet werden kann. Dazu muss „appfoundation“ so umgebaut
werden, dass es auch in der App Engine funktioniert. In der Prototyping Phase konnte verifiziert werden
dass dies mit vernünftigem Aufwand möglich ist.
7.1.9.2 Entwicklungsumgebung und Entwicklungsprozess
Grundsätzlich können dank den entsprechenden Plugins alle Vorgänge (kompilieren, bauen, testen,
deployen etc.) direkt aus Eclipse angestossen werden. Wo sinnvoll wird ergänzend Apache Ant
eingesetzt.
7.1.9.3 Produktivitätstools
SpringRoo bietet beim gewählten Architektur Ansatz keine geeignete Unterstützung für Generierung
von Code oder Konfigurationsfiles. Durch den Einsatz der ausgewählten Frameworks wird die zu
programmierende Menge Code aber sowieso erheblich reduziert.
Andere von SpringRoo angebotenen Möglichkeiten (zum Beispiel Deployment in die App Engine) werden
von den eingesetzten Eclipse Plugins abgedeckt. Deshalb wird auf den Einsatz von SpringRoo verzichtet.
Seite 36 von 83
Masterthesis MT-11-01.04 VEMICO
7.2 System Overview
VEMICO basiert auf dem Instant Web App (IWA) Framework [12]. Das „Instant Web App“ Framework
wird im Rahmen der vorliegenden Arbeit als eigenständige Bibliothek erstellt, um es für weitere
Anwendungen in der Art wie VEMICO wiederverwenden zu können. IWA setzt auf dem frei verfügbaren
Vaadin Framework [10] sowie dem Vaadin „Add-On“ „appfoundation“ [11] auf. Beide Bibliotheken sind
unter der Apache License 2.01 frei verfügbar.
Der grundsätzliche Systemaufbau in ist in folgendem Bild dargestellt.
ServletContainer
Servlet
VEMICO
Module A
VEMICO
Module B
VEMICO
Module X
Browser
IWA
Module A
VEMICO Application
Instant Web App IWA
GWT
Vaadin Client Engine
Appfoundation
Vaadin Framework
JavaMail
JPA
Abbildung 7 System Overview
Im IWA Framework werden alle in der Technologiestudie, Kapitel „Ziele und Anforderungen“
erwähnten, typischen Funktionalitäten welche die meisten (Web-) Applikation benötigen realisiert. So
kapselt IWA unter anderem auch den Zugriff auf Maildienste und Datenspeicher, unabhängig davon ob
die Anwendung in der Google App Engine oder in einem konventionellen Servlet Container betrieben
wird. Die Kapselung ist übrigens nicht absolut, man hat aus dem Anwendungsteil durchaus Zugriff auf
die JPA und Mail API’s.
In den folgenden Kapiteln werden sowohl IWA als auch VEMICO spezifische Aspekte betrachtet.
1
http://www.apache.org/licenses/LICENSE-2.0
Seite 37 von 83
Masterthesis MT-11-01.04 VEMICO
7.2.1 Vaadin Framework Architecture
Der grundlegende Aufbau des Vaadin Frameworks ist in der nächsten Abbildung ersichtlich.
Abbildung 8 Vaadin Framework Architecture (Quelle: http://vaadin.com)
Im Unterschied zu „nativen“ GWT Programmen läuft beim Einsatz des Vaadin Frameworks der grösste
Teil der Programmlogik serverseitig ab. GWT wird für das Rendering auf der Client Seite (Browser)
verwendet und weitgehend vom Programmierer versteckt. Der Programmierer kann grundsätzlich
gegen ein Java API entwickeln (vergleichbar mit der Java Swing Programmierung). Für das Styling der
Anwendung, oder das Layout können dann aber trotzdem wieder Web Standards wie CSS oder HTML
zum Einsatz kommen.
Seite 38 von 83
Masterthesis MT-11-01.04 VEMICO
7.2.2 Vaadin Client Side Architecture
Die in der Abbildung im vorherigen Kapitel gezeigte „Client Side Engine“ ist im nächsten Bild etwas
detaillierter abgebildet. Das Herzstück der „Client Side Engine“ ist eine GWT Erweiterung welche die
Kommunikation mit dem Server via UIDL (User Interface Definition Language) kapselt.
Abbildung 9 Vaadin Client Side Architecture (Quelle: http://vaadin.com/book)
Vaadin liefert ein “Standard Widget Set” mit, welches bei ausschliesslicher Verwendung der
(umfangreichen) Vaadin Standard Komponenten1 das zeitraubende Kompilieren der clientseitige GWT
Komponenten überflüssig macht. Es können aber durchaus eigene GWT Widgets erstellt und verwendet
werden.
1
http://demo.vaadin.com/sampler
Seite 39 von 83
Masterthesis MT-11-01.04 VEMICO
7.3 Object Model
Der Name des AUP Models „Object Model“ ist etwas irreführend, den es sind in diesem Model alle
üblichen statischen und dynamischen Modelle (Klassen-, Komponenten-, Sequenzdiagramme und so
weiter) vorgesehen.
7.3.1 Anwendungsgerüst
Die Übersicht soll das Zusammenspiel der verschiedenen Frameworks (Vaadin, Appfoundation, IWA) mit
der Anwendung VEMICO zeigen
class Application Class Model
Vaadin::
Application
IWA::Iw aApplication
Vaadin::Window
Appfoundation::
Lang
Appfoundation::
User
Appfoundation::
Permissons
1
Appfoundation::
SessionHandler
Appfoundation::
FacadeFactory
Appfoundation::
View Handler
«interface»
Appfoundation::
IFacade
IWA::
ModuleRegistry
VemicoApplication
IWA::MainWindow
1
Appfoundation::
JPAFacade
0..*
«interface»
IWA::Module
IWA::
AbstractModule
1
ConcreteModule
«interface»
Appfoundation::
View Container
«interface»
Appfoundation::
View
1..*
«interface»
IWA::ModuleView
IWA::
AbstractModuleView
«interface»
IWA::
ModulePresenter
IWA::
AbstractModulePresenter
ConcreteView
ConcretePresenter
Abbildung 10 Anwendungsgerüst
Die VEMICO Anwendung enthält, neben dem Domain Model und einigen Hilfsklassen eigentlich
ausschliesslich die fachlich relevanten Module mit Ihren Views und Presenters (im Bild in grün).
Seite 40 von 83
Masterthesis MT-11-01.04 VEMICO
7.3.2 Modulkonzept
Das Ziel des IWA Modulkonzeptes ist es, dass sich der Anwendungsentwickler möglichst auf seine
Geschäftslogik konzentrieren kann. Um ein neues Modul mit einer Ansicht zu realisieren müssen nur die
folgenden drei Klassen erstellt werden: Eine Klasse Modul, ein Klasse Presenter (welche ein UI Interface
zur losen Koppelung der View enthält) sowie eine View Klasse für die visuellen Komponenten.
class Module Concept Class Model
«interface»
IWA::Module
IWA::
ModuleRegistry
1
«interface»
IWA::ModuleView
0..*
«interface»
Appfoundation::
View
1..*
«interface»
IWA::
ModulePresenter
1
1
IWA::
Iw aApplication
IWA::
AbstractModule
1
IWA::
AbstractModuleView
IWA::
AbstractModulePresenter
«interface»
IWA::Iw aModuleUI
ConcreteModule
ConcreteView
«interface»
UI
ConcretePresenter
Abbildung 11 Vemico Modulkonzept
Beim Entwurf des Modulkonzeptes musste auf das verwendete „appfoundation“ Framework Rücksicht
genommen werden: „appfoundation“ verwendet zur Navigation das View Interface (im Bild in Gelb),
und so enthält eine View ihren Presenter. Bei einer puristischen „MVP“1 Implementation wäre das
vermutlich eher umgekehrt.
1
http://de.wikipedia.org/wiki/Model_View_Presenter
Seite 41 von 83
Masterthesis MT-11-01.04 VEMICO
7.4 Physical Data Model
Da die Google AppEngine nicht über eine relationale Datenbank verfügt und die Persistenz über JPA
abstrahiert wird, werden statt dem physikalischen Datenmodell die Entity Klassen modelliert.
7.4.1
Fachklassen Modell
class Entity Class Model
MembershipApplication
-
Google App Engine
does not support
sensible inheritance
date: Date
role: Role
name: String
firstName: String
emailAddress: String
sex: Sex
remarks: String
Google App Engine
DataStore does not
support many-to-many
relationships
Person
-
Engagement
name: String
firstName: String
emailAdress: String
sex: Sex
Recipient
-
email: String
1
0..*
-
Ev ent
Mailinglist
0..* 1
-
name: String
An engagement makes
a person to a society
member
dateEnd: Date
dateStart: Date
role: Role
feePaid: float
1
0..1 -
name: String
speaker: String
weblink: String
date: Date
New sletter
-
name: String
subject: String
content: String
recipients: Set<String>
ccRecipients: Set<String>
bccRecipients: Set<String>
dateSent: Date
Participants of an
event are identified
through the respective
mailinglist
Abbildung 12 Entity Class Model
In der Google App Engine kann ausschliesslich der Google Datastore verwendet werden. Dies hat
Einschränkungen1 für die Datenmodellierung zur Folge. Zum Beispiel sind keine many-to-many
Beziehungen modellierbar, und auch Vererbung ist nicht sinnvoll nutzbar, da ein Zugriff immer über die
konkrete Klasse erfolgen muss.
In VEMICO (und IWA) wurden diese Einschränkungen so gelöst, dass statt echter Fremdschlüssel die
problematischen Relationen über String Felder modelliert wurden. Als Konsequenz muss bei diesen
Beziehungen alleine die Anwendung die Datenkonsistenz sicherstellen.
1
http://code.google.com/intl/de-DE/appengine/docs/java/datastore/jpa/overview.html#Unsupported_Features_of_JPA
Seite 42 von 83
Masterthesis MT-11-01.04 VEMICO
7.4.2 Autorisierungsmodell
Neben den fachlichen Klassen gibt es persistente Entitäten für die Benutzer Autorisierung.
class Authorization Class Model
ModulePermission
-
Appfoundation::
User
roleName: String
moduleName: String
Appfoundation::
Role
No real Foreign Keys,
relation by String value
IWA::
AbstractModule
Abbildung 13 Autorisierungsmodell
Auch hier muss auf eine Referenzierung via String ausgewichen werden. Obwohl User und Role
gespeichert werden, werden Sie nicht via Fremdschlüssel technisch referenziert, sondern nur per
Namen logisch verknüpft.
Seite 43 von 83
Masterthesis MT-11-01.04 VEMICO
7.5 Deployment Model
Einer der Kernanforderungen ist es, dass das System sowohl in der Google AppEngine als auch auf
„konventioneller“ Infrastruktur lauffähig ist. VEMICO soll grundsätzlich „single sourced“ sein, das heisst
der genau gleiche Code soll sowohl in der App Engine als auch im Apache Tomcat lauffähig sein.
Unterschiede im Deployment machen (neben den Plattform spezifischen Bibliotheken) die
Konfigurationsfiles. Der Deployment Vorgang ist im Kapitel “Betriebshandbuch“ beschrieben. Die
Organisation des Source Code ist im Kapitel „Configuration Management“ beschrieben.
7.5.1 Deployment in Google AppEngine
Für das Deployment in der Google Appengine ist neben dem normalen web.xml ein appengine-web.xml
erforderlich wo alle App Engine spezifischen Einstellungen enthalten sind.
Abbildung 14 Deployment in Google AppEngine
7.5.2 Deployment in Apache Tomcat
Für das Deployment in Apache Tomcat sind abweichende Angaben in den abgebildeten
Konfigurationsdateien nötig.
Abbildung 15 Deployment in Apache Tomcat
Zieldatenbank spezifische Angaben sind neben den Angaben in persistence.xml im File orm.xml
enthalten.
Seite 44 von 83
Masterthesis MT-11-01.04 VEMICO
8 Implementation
Any problem in computer science can be solved with another layer of indirection.
But that usually will create another problem.
(David Wheeler)
8.1 Design Entscheide
Während der Implementation getroffene Designentscheide werden in diesem Abschnitt dokumentiert.
8.1.1 „Selfcare“ Funktionalität
Der Use Case 14 „Kontaktdaten verwalten“ sieht vor, dass ein Vereinsmitglied seine (und nur seine!)
Kontaktdaten selber verwalten kann.
Die Lösung sieht so aus, dass beim Erfassen einer Person automatisch ein Benutzer mit der E-Mail
Adresse der Person als Benutzername sowie als Passwort und der Rolle „Member“ angelegt wird. Der
Benutzername wird auf dem Person Objekt gespeichert. Beim Editieren von Personendaten werden die
entsprechenden Daten des verknüpften Benutzers automatisch synchronisiert.
Eine detailliertere Beschreibung findet sich im Benutzerhandbuch im Kapitel „Mitglieder“.
8.1.2 Verwendung des „appfoundation“ Frameworks
Da das „appfoundation“ [11] Framework an einigen Stellen angepasst werden musste (damit es in der
Google App Engine läuft, dynamisches Ändern der Sprache, Persistenz etc.) und das Projekt seit einiger
Zeit eher inaktiv ist, wurde der unter der Apache 2.0 Lizenz stehende Sourcecode direkt ins IWA Projekt
übernommen.
Seite 45 von 83
Masterthesis MT-11-01.04 VEMICO
8.2 Java Code
Dieser Abschnitt enthält einige Angaben zur Organisation des Java Source Code. Die Strukturierung der
Eclipse Projekte ist im Kapitel „Configuration Management“ beschrieben.
8.2.1 Java Doc
Die generierte JavaDoc API Dokumentation befindet sich in den Projekten im /doc/javadoc Verzeichnis.
8.2.2 Java Package Struktur
Wie im Kapitel „Configuration Management“ gezeigt, wurde der Java Source Code von IWA zwecks
Wiederverwendung in ein eigenes Projekt ausgelagert.
8.2.2.1 Package Struktur IWA
Neben dem IWA Framework enthält das IWA Projekt auch die Sourcen des modifizierten
„appfoundation“ Frameworks, für die detaillierte Beschreibung dieser Packages wird auf die
entsprechende Dokumentation ( [11]) verwiesen.
Package
ch.ood.iwa
ch.ood.iwa.authorization
ch.ood.iwa.module
ch.ood.iwa.module.presenter
ch.ood.iwa.module.presenter.util
ch.ood.iwa.module.ui
ch.ood.iwa.sample
ch.ood.iwa.ui
Inhalt
IwaApplication, IwaContextListener und allgemeine Hilfsklassen
Klassen für das Autorierungskonzept
Allgemeine Modul Konzept
Abstrakte und konkrete Presenter Klassen
Hilfsklassen für die Presenter und FormFieldFactories
View Klassen für die Module
Die IWA Beispiel Anwendung
Visuelle Hilfsklassen
8.2.2.2 Package Struktur VEMICO
Im VEMICO Projekt sind die VEMICO Anwendungsspezifischen Packages enthalten.
Package
ch.ood.vemico
ch.ood.vemico.model
ch.ood.vemico.model.container
ch.ood.vemico.module
ch.ood.vemico.module.presenter
ch.ood.vemico.module.presenter.util
ch.ood.vemico.module.ui
Inhalt
VEMICO Application und allgemeine Hilfsklassen
Das VEMICO Domain Model
Container für das Databinding
Die VEMICO Module
Konkrete Presenter Klassen für die Module
Hilfsklassen für die Presenter und FormFieldFactories
View Klassen für die Module
Seite 46 von 83
Masterthesis MT-11-01.04 VEMICO
8.3 Die Anwendung
Die VEMICO Anwendung ist als Vaadin Anwendung eigentlich ein Java Servlet.
class ApplicationMain
Servlet, defined
in web.xml
Vaadin::
Application
IWA::
Iw aApplication
IWA::
Iw aContextListener
Vaadin::
VaadinApplicationServ let
VemicoApplication
Appfoundation::
InternationalizationServ let
Vaadin::
GAEApplicationServ let
Vaadin::
ApplicationServ let
Listener, defined in
web.xml
Servlet, defined in
web.xml
Abbildung 16 Applikation
Beim Start der Anwendung übernimmt der ebenfalls in web.xml definierte IwaContextListener.java
diverse Initialisierungen, welche in den folgenden Abschnitten erwähnt sind.
8.3.1 Das Thread Local Pattern
Da verschiedene Servlet Instanzen in einer virtuellen Maschine laufen können, ist beim Einsatz von
bestimmten Patterns wie zum Beispiel dem Singleton Pattern Vorsicht geboten.
Die empfohlene Lösung für Vaadin Anwendungen ist das ThreadLocalPattern1, welches auch im
„appfoundation“ Framework sehr häufig verwendet wird.
1
http://vaadin.com/wiki/-/wiki/Main/ThreadLocal%20Pattern
Seite 47 von 83
Masterthesis MT-11-01.04 VEMICO
8.4 Modul Konzept
Das in IWA [12] realiserte Modulkonzept (siehe Abschnitt „Modulkonzept“ im Kapitel „Design Model“)
erlaubt es, mit sehr wenig Code eigene Module mit verschiedenen Ansichten zu realisieren.
Im nächsten Abschnitt gibt das Entwicklerhandbuch einen kurzen Überblick wie das Modul Konzept
verwendet wird, anschliessend sind Konzepte wie das Databinding dokumentiert.
8.4.1 Entwicklerhandbuch
Dieser Abschnitt gibt anhand des „Sample Module“, welches mit der IWA Distribution mitgeliefert wird,
eine kurze Anleitung, wie ein eigenes Modul in IWA erstellt werden kann.
Abbildung 17 IWA Sample Module
Das obenstehende Bild zeigt die IWA Demoanwendung mit dem aktivierten „Sample View“ im Modul
„Sample Modul“.
8.4.1.1 Modul
Das Modul selber erbt von AbstractModule, der Name der im Konstruktor übergeben wird (Zeile 24),
wird zur Anzeige im Navigationsbereich übersetzt, muss also im File translations.xml enthalten sein. Falls
keine Übersetzung vorhanden ist, wird der Text unverändert übernommen.
Abbildung 18 IwaSampleModule.java
Das Icon (Zeile 20) wird ebenfalls zur Anzeige im Navigationsbereich verwendet. Im Modul werden die
dazugehörigen View registriert (Zeile 27).
Seite 48 von 83
Masterthesis MT-11-01.04 VEMICO
Das Modul muss dann in der Applikationklasse (welche von IwaApplication erbt) registriert werden
(Zeile 46):
Abbildung 19 IwaSampleApplication.java
8.4.1.2 View und Presenter
Die View hat ebenfalls einen Namen der zur Anzeige im Navigationsbereich übersetzt wird.
Abbildung 20 IwaSampleView.java
Seite 49 von 83
Masterthesis MT-11-01.04 VEMICO
Zur Erstellung des Buttons (Zeile 32) könnte auch die Hilfsklasse UiFactory.java verwendet werden,
welche häufig gebrauchte Buttons fixfertig mit übersetztem Text und Icon liefert.
Die Superklasse AbstractModuleView.java wird neben dem gewünschten Layout auch mit dem
Presenter Typ und dem UI Typ parametrisiert um später mit getPresenter() einen typsicheren Zugriff auf
den Presenter zu haben. Gleichzeitig muss eine View das beim Presenter definierten UI Interface
Implementieren, damit dieser wiederum typsicher auf seine View zugreifen kann.
Der Presenter, welcher die UI Logik sowie den Zugriff auf ein Geschäftsmodell enthalten soll, ist in
unserem Beispiel relativ schlank.
Abbildung 21 IwaSamplePresenter.java
Beim Definieren der Methoden auf dem UI Interface ist im Hinblick auf die Testbarkeit Vorsicht geboten!
Grundsätzlich sollten keine visuellen Komponenten (Button) zurückgegeben werden, da diese meist
einen Haufen Interfaces implementieren
Seite 50 von 83
Masterthesis MT-11-01.04 VEMICO
8.4.1.3 Standalone, Full Screen View
Wenn eine View ohne den Header und Navigationsbereich angezeigt werden soll, kann einfach die
Methode „isFullScreen“ so überschrieben werden, dass sie true zurückgibt. Die entsprechende View
muss dann als „Full Screen View“ in der Anwendung registriert sein.
Damit diese View „von aussen“ direkt erreichbar ist (zum Beispiel via
http://localhost:7777/?FullScreenSampleView), kann in der Anwendung ein entsprechendes URL
Parameter Mapping definiert werden:
Weitere Tipps zum Einsatz von IWA finden sich auf der IWA Projektwebsite [12].
8.4.2 Navigation
Die Navigation zwischen den einzelnen Views passiert via die ViewHandler.java Klasse. Wenn eine View
den Befehl erhält sich anzuzeigen, dann wird dieser Befehl die Hierarchie hochgegeben damit auch die
Parent Klassen sichtbar werden.
Seite 51 von 83
Masterthesis MT-11-01.04 VEMICO
8.4.3 Databinding
Für das Databinding der verschiedenen Tabellen und Forms kann von den Möglichkeiten von Vaadin
profitiert werden.
Abbildung 22 Vaadin Data Model (Quelle: http://vaadin.com/book)
Die Daten sind in Key-Value Paaren organisiert, welche durch eine Property Id (PID) zu Items gehören
können. Mehrere Items (identifiziert durch eine Item Id, IID) wiederum werden in Container verwaltet.
Das Praktische dabei ist, dass ein Item ein ganz normales POJO welches gemäss den JavaBeans
Konventionen1 Getter und Setter Methoden anbietet und daher auch eine JPA Entity sein kann. Vaadin
bietet dafür einen Wrapper, die BeanItem.java Klasse an. Um ein normales POJO als Item verwenden zu
könne, ist folgende Code Zeile notwendig:
Dieses Item kann nun in Vaadin Forms verwendet werden, siehe nächster Abschnitt.
1
http://download.oracle.com/javase/tutorial/javabeans/
Seite 52 von 83
Masterthesis MT-11-01.04 VEMICO
8.4.3.1 Vaadin Forms
Für das Binding von Formularen auf einzelne Entities bietet Vaadin das Konzept der „Forms“1.
class Forms
View
Form
Poj o
BeanItem
itemDataSource
1
FormFieldFactory
Abbildung 23 Vaadin Forms
Alles was man tun muss, ist dem Form ein Item als ItemDataSource anzugeben, und Vaadin Forms
erstellt ein Formular mit einem Default Rendering für alle Properties des Items. Typischerweise will man
das Default Rendering und Verhalten beeinflussen, dies geschieht durch Angabe einer FormFieldFactory.
8.4.3.2 Tabellen
Zum Anzeigen mehrerer Entities wurden in VEMICO meist Tabellen gewählt. Zum einfachen Binden von
Objekten an Tabellen kann die Klasse BeanItemContainer.java2 benutzt werden.
class Table
Table
BeanItemContainer
containerDataSource
Poj o
0..*
Abbildung 24 Vaadin Item Container
Der BeanItem Container kann direkt mit POJO’s verwendet werden, es müssen nicht zuerst BeanItems
erstellt werden.
1
http://vaadin.com/book/-/page/components.form.html
2
http://vaadin.com/book/-/page/datamodel.container.html
Seite 53 von 83
Masterthesis MT-11-01.04 VEMICO
8.5 Persistenz
Als Datenzugriffslayer sollte für beide Zielplattformen JPA verwendet werden. Das “appfoundation” [11]
Framework bietet mit dem Interface IFacade.java eine Schnittstelle, mit welcher sämtliche Entities
welche von AbstractPojo.java erben verwaltet werden können. Bei der Klasse FacadeFactory können
verschiedene Implementationen von IFacade registriert werden und bei Bedarf wieder geholt werden.
Abbildung 25 Persistenz
Die Registrierung des richtigen JPA „persistence-unit“ Namens (aus dem persistence.xml File) passiert
beim Start der Anwendung im IwaContextListener.java. Dort wird die aktuelle Laufzeitumgebung
detektiert und der passende „persistence-unit“ Name gesetzt.
8.5.1 Anpassungen am Appfoundation Persistence Layer
Das „appfoundation“ Persistenz Modul war nicht für den Einsatz in der Google App Engine gebaut und
musste angepasst werden.
8.5.1.1 JPA Provider
Als JPA wurde ursprünglich Eclipse Link eingesetzt. In der Google App Engine wird jedoch Datanucleus
als JPA Provider verwendet. Daher wurden die entsprechenden Bibliotheken ausgetauscht. Für den
Einsatz mit Tomcat und MySQL wurden die Datanucleus RDBMS Bibliotheken ergänzt.
8.5.1.2 Entity Keys
In der gemeinsamen Superklasse aller Entities AbstractPojo.java mussten die JPA Annotationen für die
Schlüsselgenerierung von AUTO nach IDENTITY geändert werden. Um die Portabilität sicherzustellen
sind weitere, Datanucleus spezifische Annotationen1 nötig:
1
http://code.google.com/intl/de-DE/appengine/docs/java/datastore/jdo/creatinggettinganddeletingdata.html#Keys
Seite 54 von 83
Masterthesis MT-11-01.04 VEMICO
8.5.1.3 JPA Facade
Die ursprüngliche Implementation von JPAFacade.java benutzte gewisse Hilfsklassen von EclipseLink,
diese Funktionalitäten mussten ausprogrammiert werden. Ausserdem mussten gewisse Queries
angepasst werden, auch hier schien Eclipse Link ein leicht anderes JPA Verständnis als Datanucleus zu
haben.
8.5.2 Plattformspezifische Klassen
Der erwähnte „Single Source“ Ansatz wird durch eine einzige Klasse gebrochen: Newlsetter.java. Es war
nötig eine eigene Implementierung für Google App Engine und MySQL zu realisieren. Der Grund ist, dass
in GAE Strings eine maximale Länge von 500 Zeichen haben dürfen. Bei längeren Zeichenfolgen ist die
Klasse com.google.appengine.api.datastore.Text.java zu verwenden1.
8.5.3 Integration Test
Das Aufsetzen der Integrationstests für die Persistenz Schicht erfordert plattformspezifische
Einstellungen. Die eigentlichen Tests sind in als JUnit Tests in TestEntityModel.java definiert.
Abbildung 26 Persistence Integration Tests
In den Klassen TestEntityModelAgainstXY.java sind die jeweiligen Plattformspezifischen Einstellungen
enthalten, so muss zum Beispiel für GAE die Google Klasse LocalServiceTestHelper.java bemüht werden.
Die Klassen RunAllXYSpecificTests.java sind JUnit Test Suiten und dienen zur Gruppierung von
Plattformspezifischen Tests (falls weitere hinzukämen), die .launch File sind Eclipse Launch Files, um die
Tests direkt aus Eclipse zu starten (es existiert zusätzlich ein Ant File unter Vermico/scripts).
1
http://code.google.com/intl/de-DE/appengine/docs/python/datastore/typesandpropertyclasses.html
Seite 55 von 83
Masterthesis MT-11-01.04 VEMICO
8.5.4 Zwischenfazit Persistenz Schicht
An dieser Stelle soll ein kleines Zwischenfazit bezüglich der Implementation der Persistenz Schicht
gezogen werden. Durch das konsequente Verfolgen des „Single Source“ Ansatzes (gleicher Source Code
für alle Zielplattformen) und der Verwendung der „appfoundation“ Persistenz Facade (welche wegen
der Abhängigkeit von IFacade.java zu AbstractPojo.java ausschliesslich JPA unterstützen kann) muss
sinngemäss gegen den kleinsten gemeinsamen Nenner aller Plattformen programmiert werden. Dieser
ist wegen der beschränkten JPA Fähigkeiten des Google Data Store recht klein.
Als Option könnten die Datenzugriffsschicht in Richtung „DAO“1 und „Abstrakte Fabrik“2 Pattern
realisiert werden. Die Model Entities müssten von den Persistenz Entities getrennt werden. Mit
entsprechenden Factories wäre man dann in der Lage, plattformspezifische Implementierungen des
Datenzugriffs anzubieten.
Das würde dann sinngemäss etwa so aussehen:
Abbildung 27 DAO und abstrakte Fabrik (Quelle: http://java.sun.com)
Dieses Pattern in IWA zu unterstützen wäre einigermassen aufwändig, da natürlich keine spezifischen
konkreten DAO’s programmiert werden könnten
1
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
2
http://de.wikipedia.org/wiki/Abstrakte_Fabrik
Seite 56 von 83
Masterthesis MT-11-01.04 VEMICO
8.6 Internationalisierung
Zur Verwaltung der mehrsprachigen Texte konnte auf das i18n Modul von „appfoundation“
zurückgegriffen werden, die Umschaltung der Ansichten ist in IWA gelöst.
Abbildung 28 i18n
Der IwaContextListener.java initialisiert beim Start der Anwendung das separat laufende
Internationalization Servlet mit dem entsprechenden Übersetzungsfile. Diese Servlet muss im web.xml
File definiert sein damit es gestartet wird. Der Zugriff der Anwendung auf die übersetzten Texte
geschieht über die Utility Klasse Lang.java.
Das Umschalten der Sprache kann in VEMICO auf zwei Arten geschehen:


Via GUI
Via URL Parameter
In jedem Fall wird in IwaApplication.java die Methode „changeLocale“ aufgerufen, welche die ganzen
visuellen Komponenten zurücksetzt, damit sie neu und in der richtigen Sprache erstellt werden.
Ausserdem wird ein Browser Cookie gesetzt um beim nächsten Aufruf der Anwendung die zuletzt
gewählte Sprache zu übernehmen.
8.7 Autorisierung
Die im Design Model, Abschnitt „Autorisierungmodell“ beschriebene Abbildung der Berechtigungen der
verschiedenen Rollen für die jeweiligen Module wird zur Laufzeit in der Klasse MainWindow.java
interpretiert: in der Navigationsansicht erscheinen nur diejenigen Module welche einen entsprechenden
Berechtigungseintrag haben.
Für die Realisierung des Use Case 14 „Kontaktdaten verwalten“ wurde eine pragmatische Lösung via
eines eigenen „Selfcare“ Moduls (SelfcareSocietyModule.java) welches nur die „Members View“ enthält
gewählt. Der „Members Presenter“ enthält pragmatischerweise eine Methode „isSelfcare“ welche zur
Steuerung der angezeigten Daten (nur die eigenen) verwendet wird.
Seite 57 von 83
Masterthesis MT-11-01.04 VEMICO
8.8 Logging
Sowohl Google App Engine als auch Apache Tomcat unterstützen die java.util.logging API, welche über
ein properties file (logging.properties) gesteuert werden kann.
Die Klasse IwaApplication.java bietet zwei verschiedene Logging Funktionen an (log und logError), eine
für Meldungen und eine zweite welcher eine Throwable übergeben werden kann. Die zweite Methode
extrahiert und loggt den Stacktrace.
Für Google App Engine befindet sich logging.properties im Verzeichnis /war/WEB-INF, für Apache
Tomcat muss sich das File unter /war/WEB-INF/classes befinden.
8.9 Exception Handling
Eine „Besonderheit“ von Vaadin ist es, ganze Stack Traces auf visuellen Komponenten einzublenden1. Da
dies in den meisten Fällen nicht erwünscht ist (speziell weil fachliche Validationsprobleme gerne mittels
Exceptions gemeldet werden), wird in IwaApplication.java ein globaler Errorhandler gesetzt.
In Zeile 254 wird geprüft, ob es sich „nur“ um einen Validation Error handelt. Diese können an dieser
Stelle ignoriert werden, weil der zuständige Presenter sich typischerweise darum kümmert. Andere
Fehler werden geloggt und ein einem regulären Fenster angezeigt.
1
http://vaadin.com/book/-/page/rapid.exception.html
Seite 58 von 83
Masterthesis MT-11-01.04 VEMICO
9 Test
Quality is free, but only to those who are willing to pay heavily for it.
(Tom DeMarco)
AUP [1] sieht in der Disziplin „Test“ System- und Akzeptanz Tests vor.
Die fachliche Funktionalität kann dynamisch getestet werden, also durch Ausführen der Anwendung.
Dazu können direkt die Use Cases als Testfälle ausgeführt werden. Wo es keinen passenden Use Case
gibt, oder eine Verfeinerung sinnvoll ist wurden zusätzliche Testfälle definiert.
Die nichtfunktionalen Anforderungen nicht immer sinnvoll dynamisch testbar, es wurde deshalb pro
Anforderung ein Kapitel mit Beschreibung der Verifikationsart und dem Resultat erstellt.
9.1 Testreport Akzeptanz Test
Im Testreport ist jeweils die entsprechende Anforderung referenziert um gleichzeitig eine
Anforderungszuordnung machen zu können.
Anforderung
Prio.
Testfall
Mitglieder
FA-M1, Mitgliederstamm
FA-M2, Mitgliederhistorie
FA-M3, Anmeldung Neumitglied
Muss
Muss
Soll
UC5 - Personendaten verwalten
UC5 - Personendaten verwalten
UC12 - Mitgliedschaft beantragen
FA-M3-T1, Log Ablehnung Mitgliedschaft
UC14 - Kontaktdaten bearbeiten
FA-M4-T-1, Eindeutige E-Mail Adresse Person
UC5 - Personendaten verwalten
FA-M5-T1, Audittrail
FA-M5-T2, Logeintrag Person
FA-M5-T3, Logeintrag Engagement
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
FA-M4, "Self Care"
Soll
FA-M5, Log Mitgliederdaten
Kann
Newsletter
FA-N1, Newsletter erstellen/senden
Muss
Resultat
FA-N2, Verteilerlisten
FA-N3, "Opt-Out" Funktion
Muss
Muss
FA-N4, Newsletter Archiv
FA-N5, Andere Kanäle
Soll
Kann
UC8 - Newsletter verwalten/versenden
FA-N1-T1, Newsletter nur einmal senden
UC4 - Mailinglisten verwalten
UC13 - Von Mailinglisten abmelden
FA-N3-T1, Abmelden Mailinglisten
UC8 - Newsletter verwalten/versenden
Nicht implementiert
Veranstaltungen
FA-V1, Veranstaltungen verwalten
FA-V2, An Veranstaltungen anmelden
FA-V3, Medien verwalten
FA-V4, Von Veranstaltung abmelden
Muss
Muss
Kann
Kann
UC7 - Anlässe verwalten
UC10 - Anmelden für Anlass
Nicht implementiert
UC11 - Abmelden von Anlass
OK
OK
Benutzerverwaltung
FA-B1, Verwaltung
Muss
UC3.1 - Benutzer suchen
OK
OK
Seite 59 von 83
Masterthesis MT-11-01.04 VEMICO
FA-B2, Authentifizierung
Muss
FA-B3, Rollenmodell
FA-B4, Passwort verlangen
Muss
Soll
UC3.2 - Benutzer erstellen
UC3.3 - Benutzer ändern
UC3.4 Benutzer löschen
FA-B2-T1, Login
FA-B2-T2, Fehlerhaftes Login
UC3.5 - Rollen und Module verwalten
UC2 - Neues Passwort verlangen
FA-B4-T-1, Eindeutige E-Mail Adresse Benutzer
OK
OK
OK
OK
OK
OK
OK
OK
Import/Export
FA-I1, Import/Export der Nutzdaten
Kann
Nicht implementiert (Backup/Restore: ANFA-1)
Internationalisierung
FA-ME1, Internationalisierung
Soll
Muss
FA-ME1-T1, Sprache umstellen via GUI
FA-ME1-T2, Gewählte Sprache Browser Cookie
FA-ME1-T3, Sprache umstellen via URL
FA-ME2-T1, Lokalisation in Deutsch
OK
OK
OK
OK
Mitgliederbeiträge
FA-BE1, Beiträge verwalten
Soll
UC6 - Mitgliederbeiträge verwalten
OK
Vereinsartefakte
FA-V1, Vereinsartefakte verwalten
Kann
Nicht implementiert
FA-ME2, Lokalisierung in Deutsch
9.2 Testreport System Test
Es folgt nach der Zusammenfassung eine Beschreibung pro Anforderung.
9.2.1
Zusammenfassung
Anforderung
Prio. Status
Spezifische NFA
SNFA-1 Laufzeitumgebung
SNFA-2 Persistenz
SNFA-3 Benutzerkonten
SNFA-4 Dokumentation Portabilität
SNFA-5 Dokumentation Entwicklungprozess/Tools
Soll
Soll
Soll
Muss
Muss
OK
OK
OK
OK
OK
Allgemeine NFA
ANFA-1 Zuverlässigkeit
ANFA-2 Leistung/Effizienz
ANFA-3 Änderbarkeit
ANFA-4 Sicherheit
ANFA-5 Korrektheit
ANFA-6 Ergonomie
Muss
Muss
Muss
Muss
Muss
Muss
OK
OK
OK
OK
OK
OK
Seite 60 von 83
Masterthesis MT-11-01.04 VEMICO
9.2.2
Spezifische nichtfunktionale Anforderungen
9.2.2.1 SNFA-1 Laufzeitumgebung
Anforderung: Die Applikation kann sowohl auf einem konventionellen Applikationsserver (oder Servlet
Container) als auch in der Google App Engine Umgebung betrieben werden.
VEMICO läuft sowohl in der Google App Engine als auch in Apache Tomcat mit MySql als Datenbank.
Andere Plattform Kombinationen wurden aus Zeitgründen nicht explizit getestet (das Google App Engine
SDK verwendet Jetty für lokale Tests, das würde wohl also auch funktionieren).
9.2.2.2 SNFA-2 Persistenz
Anforderung: Die Applikation kann automatisch oder konfigurativ auf die entsprechenden Persistenz
Möglichkeiten der jeweiligen Plattform eingestellt werden.
IWA benutzt JPA1 als Persistenz Framework. Es detektiert automatisch die aktuelle Laufzeitumgebung (in
IwaContextListener.java) und lädt die entsprechende Konfigurationseinstellungen (persistence.xml).
9.2.2.3 SNFA-3 Benutzerkonten
Anforderung: Der Benutzer kann sich mit der gleichen Identifikation authentifizieren, unabhängig wie
oder wo die Anwendung betrieben wird.
IWA persistiert Benutzerdaten selber und hat eine eigene Authentisierungslogik welche unabhängig von
den Möglichkeiten der Laufzeitumgebung funktioniert.
9.2.2.4 SNFA-4 Dokumentation Portabilität
Anforderung: Die gemachten Untersuchungen in Bezug auf SNFA-1 – 3 sind unabhängig vom Resultat
dokumentiert.
Die Untersuchungen und Resultate finden sich im Kapitel „Implementation“ im vorliegenden Dokument.
9.2.2.5 SNFA-5 Dokumentation Entwicklungsprozess/Tools
Anforderung: Die Projektdokumentation enthält einen Bericht über die eingesetzten Tools und
Frameworks (Spring Roo, Spring Toolsuite, GWT GUI Designer, GWT MVP etc.) und die damit gemachten
Erfahrungen.
Die Untersuchungen und Resultate finden sich im Kapitel „Design Model“, Abschnitt Technologiestudie
im vorliegenden Dokument.
1
http://de.wikipedia.org/wiki/Java_Persistence_API
Seite 61 von 83
Masterthesis MT-11-01.04 VEMICO
9.2.3
Allgemeine nichtfunktionale Anforderungen
9.2.3.1 ANFA-1 Zuverlässigkeit
Anforderung: Die Daten werden gesichert oder können gesichert werden.
Das Kapitel „Betriebshandbuch“ enthält die entsprechenden Anweisungen wie eine Daten Sicherung
und Wiederherstellung auf den jeweiligen Plattformen gemacht werden kann.
9.2.3.2 ANFA-2 Leistung/Effizienz
Anforderung: Die Antwortzeiten liegen für interaktive Vorgänge unter fünf Sekunden.
Dies wurde erfolgreich auf beiden Plattformen dynamisch getestet. Das Betriebshandbuch enthält eine
Anleitung, wie die Anwendung in der App Engine als „Backend“ installiert werden kann um eine
maximale Performance zu erhalten.
9.2.3.3 ANFA-3 Änderbarkeit
Anforderung: Das System ist so strukturiert, dass zusätzliche Funktionalität einfach eingebaut werden
kann.
Dank des IWA Modulkonzeptes ist dies einfach möglich.
9.2.3.4 ANFA-4 Sicherheit
Anforderung: Schützenswerte Daten (speziell Mitgliederdaten) müssen vor unberechtigtem Zugriff via
Benutzeroberfläche oder Webserver geschützt sein (Abgrenzung: Weitergehende
Sicherheitsmassnahmen wie zum Beispiel Verschlüsselte Kommunikation oder Datenablage ist nicht
erforderlich).
VEMICO erfordert einerseits eine Anmeldung mit Benutzername und Passwort und hat anderseits eine
Rollen- und Berechtigungskonzept. VEMICO wird aufgrund des zugrundeliegenden Vaadin Framework
als Servlet auf dem Server ausgeführt und kann daher im Sinne der Anforderung als sicher gelten.
9.2.3.5 ANFA-5 Korrektheit
Anforderung: Es existieren automatische Unittests um das Funktionieren der Kernfunktionalität zu
verifizieren.
Im Kapitel „Test“ im vorliegenden Dokument ist die Testabdeckung dokumentiert.
9.2.3.6 ANFA-6 Ergonomie
Anforderung: Die Anwendung soll nach den Kriterien des ISONORM 9241/10 Fragebogens [7] geprüft
werden und ein genügendes Resultat erzielen.
Die Vorstandsmitglieder von Guild42 haben die Anwendung anhand des erwähnten Fragebogens
geprüft, es wurde ein genügendes Resultat erzielt. Im Anhang „Ergonomie Test Report“ sind die
Resultate der entsprechenden Tests dokumentiert.
Seite 62 von 83
Masterthesis MT-11-01.04 VEMICO
9.2.4 Testreport Unit Test
Der VEMICO JUnit Testreport befindet sich unter Vemico/doc/test/junitreport, das Ant File welches die
Tests ausführt und den Report generiert ist Vemico/scripts/buildJUnitReport.xml.
Abbildung 29 VEMICO JUnit Report
Der IWA JUnit Testreport befindet sich unter IwaTestGae/doc/test/junitreport, das Ant File welches die
Tests ausführt und den Report generiert ist IwaTestGae/scripts/buildJUnitReport.xml.
Abbildung 30 IWA JUnit Report
Die Persistenz Klassen werden jeweils gegen eine lokale App Engine wie auch gegen MySQL getestet.
Seite 63 von 83
Masterthesis MT-11-01.04 VEMICO
10 Deployment
> cd /pub
>more beer
(Aufschrift auf einem T-Shirt)
Die Lieferobjekte der AUP Disziplin „Deployment“ beinhalten das Betriebshandbuch (Operations
Documentation) sowie die Endbenutzer Dokumentation (User Documentation).
10.1 Betriebshandbuch
Das Betriebshandbuch enthält Anweisungen zur Installation und zum Betrieb von VEMICO.
10.1.1 Anwendungs Konfiguration
Im File /WEB-INF/iwa.properties können diverse Einstellungen vorgenommen werden.
Property
mail.host
Beispielwert
mail.bluewin.ch
iwa.mail.sender.mail
[email protected]
iwa.mail.sender.name
Guild42
iwa.languages
de;en
iwa.app.name
iwa.environment
vemico.newsletter.receiver.mail
Vemico
VEMICO-TEST
[email protected]
vemico.newsletter.receiver.name Undisclosed Recipients
vemico.newsletter.sender.mail
[email protected]
vemico.newsletter.sender.name
Guild42
Erklärung
SMTP Mailhost (für Google App Engine
irrelevant)
Absenderadresse für E-Mails (zum Beispiel das
„Lost Password“ Mail)
Absendername für E-Mails (zum Beispiel das
„Lost Password“ Mail)
Unterstützte Sprachen, im ISO-639 Format und
Semikolon separiert. Die entsprechenden
Texte werden im file WEB-INF/translations.xml
definiert
Applikationsname (frei wählbar)
Umgebungsname (frei wählbar)
Empfängeradresse für Newsletters (Die
Empfänger werden „Bcc“ hinzugefügt)
Empfängername für Newsletters
Absenderadresse für Newsletters.
In der Google App Engine muss dies ein
eingetragener Administrator der Applikation
sein.
Absendername für Newsletters
10.1.2 Google App Engine
Um eine neue Version von VEMICO in die App Engine zu installieren, muss das Vemico Projekt auf den
lokalen Rechner ausgecheckt werden. Siehe dazu das Kapitel „Configuration Management“.
10.1.2.1 Installation
Das Google App Engine SDK1 muss installiert sein. Danach kann mit dem Commandline Tool „appfcg“ die
Anwendung in die App Engine deployt werden (aktuelles Verzeichnis muss Vemic/war sein).
> appcfg update .
1
http://code.google.com/intl/de-CH/appengine/downloads.html#Google_App_Engine_SDK_for_Java
Seite 64 von 83
Masterthesis MT-11-01.04 VEMICO
Der Befehl verlangt Benutzername und Passwort eines eingetragenen Applikations Verantwortlichen
(Owner) oder Entwicklers (Developer), ersichtlich im Adminstrations Bereich des Dashboards der
jeweiligen Applikation (https://appengine.google.com/).
Das Deployment kann auch über das Google Eclipse Plugin gemacht werden:
Abbildung 31 Eclipse App Engine Deploy Dialog
10.1.2.2 Installation als Backend
Um eine bessere Performance zu erreichen, kann die Anwendung auch als „Backend“1 deployt werden.
Da dies ab einer gewissen Quota kostenpflichtig sein kann, muss zuerst via App Engine Dashboard2 das
das Billing (unter Billing|Billing Settings) aktiviert und ein Backend erstellt werden (unter
Main|Backends).
Dann muss unter war/WEB-INF ein backends.xml File erstellt werden:
Der [email protected] muss mit dem Servlet Namen (<servlet-name>) im web.xml sowie dem im
Dashboard erstellten Backend übereinstimmen.
Das Deployment wird dann über folgenden Befehl gemacht (aktuelles Verzeichnis ist Vemico/war):
> appcfg backends . update
Wichtig: Der URL der Anwendung wird dann der Backend Name vorangestellt, für Vemico lautet dann
die Adresse http://vemico.vemico-guild42.appspot.com/.
1
http://code.google.com/appengine/docs/java/backends/overview.html
2
https://appengine.google.com/
Seite 65 von 83
Masterthesis MT-11-01.04 VEMICO
10.1.2.3 Back Up und Restore
Die Python Version des Google App Engine SDK beinhaltet das „bulk loader tool“1 welches Entities aus
dem Data Store exportiert und importiert. Dazu muss einerseits eine Python Laufzeitumgebung sowie
das Google Python SDK lokal auf einem Rechner installiert werden.
Vorbedingung ist, dass die Applikation für Remote API Zugriffe eingerichtet wurde. Für eine Java
Applikation wie VEMICO muss dazu nur das web.xml file mit dem entsprechenden Servlet Mapping
ergänzt werden:
<servlet>
<servlet-name>remoteapi</servlet-name>
<servlet-class>com.google.apphosting.utils.remoteapi.RemoteApiServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>remoteapi</servlet-name>
<url-pattern>/remote_api</url-pattern>
</servlet-mapping>
1. Python 2 installieren von http://www.python.org/download/releases/2.7.2/
2. Google Python SDK installieren von http://code.google.com/intl/deDE/appengine/downloads.html
Danach kann mit folgendem Befehl (auszuführen im Installationsverzeichnis des GAE Python SDK, zum
Beipsiel C:\Google\google_appengine) der gesamte DataStore lokal gespeichert werden:
appcfg.py download_data --filename=backup.csv --application=vemico-guild42-dev -url=http://vemico-guild42-dev.appspot.com/remote_api --rps_limit=500 --bandwidth_limit=2500000 -batch_size=100
Der Befehl verlangt Benutzername und Passwort eines eingetragenen Applikations Verantwortlichen
(Owner) oder Entwicklers (Developer), ersichtlich im Adminstrations Bereich des Dashboards der
jeweiligen Applikation (https://appengine.google.com/).
Ein Restore der Daten passiert analog:
appcfg.py upload_data --filename=backup.csv --application=vemico-guild42-dev --url=http://vemicoguild42-dev.appspot.com/remote_api --rps_limit=500 --bandwidth_limit=2500000 --batch_size=100
1
http://code.google.com/intl/de-DE/appengine/docs/python/tools/uploadingdata.html
Seite 66 von 83
Masterthesis MT-11-01.04 VEMICO
10.1.2.4 Logfile
Das Logfile kann via Google App Engine Dashboard1 angeschaut werden.
Abbildung 32 GAE Dashboard
Die Log Einstellungen sind in WEB-INF/logging.properties vorzunehmen.
10.1.3 Tomcat mit MySQL
Um VEMICO auf Apache Tomcat zu deployen, muss ein Web Archive (.war) erstellt werden. Siehe dazu
das Kapitel „Configuration Management“.
10.1.3.1 Installation
Beim Herunterladen und Installieren von Apache Tomcat 6 und MySQL 5.5 ist nichts spezielles zu
beachten:


http://tomcat.apache.org/download-60.cgi
http://www.mysql.com/downloads/mysql/
Anschliessend ist ein DB Schema (zum Beispiel „vemico“ zu erstellen, sowie ein DB Benutzer (zum
Beispiel „vemico“). Das Passwort muss im vemico-x.y.z.war im file WEB-INF\classes\METAINF\persistence.xml gesetzt werden:
Anschliessend kann die Anwendung in den Tomcat Container deployt werden, am einfachsten durch
kopieren von vemico-x.y.z.jar in den webapps folder von Tomcat.
1
https://appengine.google.com/
Seite 67 von 83
Masterthesis MT-11-01.04 VEMICO
10.1.3.2 Back Up und Restore
Für MySQL existieren eine Reihe Programme zu diesem Zweck. Die frei verfügbare MySQL Standard
Adminstrationskonsole „MySQL Workbench“1 verfügt über einen eingebauten Export/Import
Assistenten:
Abbildung 33 MySQL Workbench
10.1.3.3 Logfile
Das Logging kann in WEB-INF\classes\logging.properties eingestellt werden. Standardmässig befinden
sich die Logeinträge in [Tomcat Verzeichnis]\logs\Vemico.yyyy-MM-dd.log.
1
http://www.mysql.com/downloads/workbench/
Seite 68 von 83
Masterthesis MT-11-01.04 VEMICO
10.2 Benutzerhandbuch
Das Benutzerhandbuch kann via dem „Hilfe“ Link (1) in der Anwendung erreicht werden.
Abbildung 34 Hilfelink in VEMICO
Alternativ kann das Benutzerhandbuch auch via

http://guild42.ch/vemico/BenutzerhandbuchVemico.pdf
erreicht werden, die Sourcen sind unter Vemico/doc/userguide zu finden.
Seite 69 von 83
Masterthesis MT-11-01.04 VEMICO
11 Configuration Management
If it's worth creating it's worth putting under CM control
(Scott W. Amber )
Die AUP [1] Disziplin „Configuration Management“ befasst sich mit dem (Weiter-) Entwicklungsprozess
des Systems.
11.1 Entwicklungsumgebung
Die Entwicklungsumgebung wurde so aufgesetzt, dass für beide Zielplattformen ein lokales testen und
debuggen möglich ist.
cmp Dev Env
Tomcat 6
MySQL
Jetty Serv let
Container
Local DataStore
deploy and run
Eclipse IDE
deploy and run
Abbildung 35 Entwicklungsumgebung
Für die lokale Entwicklung für App Engine Zielplattform wurde enthält das App Engine SDK einen Jetty
Servlet Container in welchen via dem Google Eclipse Plugin eine Anwendung deployt werden kann.
Abbildung 36 Lokale App Engine in Eclipse
Für lokale Tests für die Zielplattform Tomcat wurden ein Tomcat Servlet Container und eine MySQL
Datenbank lokal installiert. Via den J2EE Integrationskomponenten der Eclipse J2EE Edition kann der
Tomcat ebenfalls direkt aus Eclipse bedient werden.
Abbildung 37 Tomcat in Eclipse
Eine detaillierte Beschreibung zum Aufsetzen der Entwicklungsumgebung ist im IWA Developers Guide
beschrieben1.
1
http://code.google.com/p/instant-webapp/wiki/GettingStarted?ts=1315647013&updated=GettingStarted#Detailed_Guide
Seite 70 von 83
Masterthesis MT-11-01.04 VEMICO
11.1.1 Hilfsmittel
Für die VEMICO und IWA Entwicklung wurden folgende Hilfsmittel eingesetzt.
Zweck
Betriebssystem
Java JDK
App Engine SDK
IDE
Eclipse Plugins
JPA Provider
Webframework
Browser Rendering Toolkit
Vaadin Add-On’s
Datenbank
Software
Microsoft
Windows 7
Professional
64 bit
JDK 1.6.0,
Build 25
Google GAE
SDK for Java
1.5.2
Eclipse 3.6
J2EE (Helios)
Google
Vaadin
Datanucleus
Subversive
Datanucleus
1.1.5
Vaadin 6.6.2
Google GWT
2.3
Appfoundation
1.3.5
Confirmdialog
1.1.1
MySQL 5.5
Datenbank Admin Tool
MySQL
Workbench
5.2
Servlet Container
Apache
Tomcat 6
Unittests
JUnit
Easymock
Build Tool
Apache Ant
Grafiken
Enterprise
Architect
Visio
Powerpoint
Dokumente
Word
GUI Protoyping
Balsamiq
Mockup
Versionsverwaltungssysten Subversion
Planung
Gantt Chart
Referenz
http://www.microsoft.com
http://www.oracle.com/technetwork/java/javase/download
s/index.html
http://code.google.com/intl/deDE/appengine/downloads.html#Google_App_Engine_SDK_f
or_Java
http://www.eclipse.org/downloads/
http://code.google.com/intl/de-DE/eclipse/
http://vaadin.com/eclipse
http://www.datanucleus.org/downloads/eclipse-update
http://www.eclipse.org/subversive/downloads.php
http://sourceforge.net/projects/datanucleus/files/
http://vaadin.com/download
http://code.google.com/intl/de-DE/webtoolkit/
http://vaadin.com/directory#addon/appfoundation
http://vaadin.com/directory#addon/confirmdialog
http://www.mysql.com/downloads/mysql/5.5.html#downlo
ads
http://www.mysql.de/products/workbench/
http://tomcat.apache.org/download-60.cgi
http://www.junit.org/
http://easymock.org/
http://ant.apache.org/
http://www.sparxsystems.com/
http://www.microsoft.com
http://www.microsoft.com
http://www.microsoft.com
http://balsamiq.com/products/mockups
http://subversion.tigris.org/
http://www.ganttproject.biz/
Seite 71 von 83
Masterthesis MT-11-01.04 VEMICO
11.2 Projektstruktur
Das (Eclipse-) Hauptprojekt „Vemico“ enthält den ganzen Source Code sowie alle
plattformunabhängigen Artefakte.
cmp Eclipse
App Engine Libraries
Vemico
«use»
Vaadin
«use»
«use»
«import»
«use»
Vemico_Tomcat6
IWA
«use»
«use»
Tomcat / MySQL Libraries
Abbildung 38 Eclipse Projektstruktur
Das Projekt „Vemico_Tomcat6“ importiert den Source Code sowie alle plattformunabhängigen
Artefakte. Plattformspezifische Artefakte werden hinzugefügt oder überschrieben.
11.2.1 Entwicklungsprozess
Aufgrund des Projektumfangs besteht der Entwicklungsprozess darin, die zu ändernden Projekte aus der
Versionskontrolle auszuchecken, die Änderungen vorzunehmen und die Projekte wieder einzuchecken.
Der Deployment Vorgang ist im Kapitel „Betriebshandbuch“ beschrieben.
Naturgemäss ist bei Änderungen in der Persistenz Schicht auf die bestehenden Daten Rücksicht zu
nehmen.
11.2.2 Vemico Projekte
Die VEMICO Projekte Code sind im OOD Subversion Repository unter


svn://ood.li:1975/Mischa/Vemico
svn://ood.li:1975/Mischa/Vemico_Tomcat6
abgelegt.
Es ist ein „Readonly“ - Benutzer „svn“ mit dem Passwort „svn“ eingerichtet.
Seite 72 von 83
Masterthesis MT-11-01.04 VEMICO
11.2.2.1 Erstellen eines Web Archives
Um VEMICO in einen konventionellen Servlet Container zu deployen, muss ein Web Archive (.war)
erstell werden. Dazu muss sowohl das Vemico als auch Vemico_Tomcat6 Projekt ausgecheckt werden.
Das Erstellen des .war Files ist IDE abhängig unterschiedlich zu bewerkstelligen. In Eclipse kann dazu
einfach im Kontextmenu des Vemico_Tomcat6 Projekts Export | War File selektiert werden.
11.2.3 IWA Projekte
Der IWA Source Code ist im Google Code Subversion Repository unter
http://code.google.com/p/instant-webapp/source/checkout erreichbar:
Abbildung 39 IWA Projekte
Beim auschecken ist darauf zu achten, dass in den Location Properties in der SVN Ansicht im Tab
„Advanced“ die Option „Enable Structure Detection“ aktiviert ist. Unter Preferences|Team|SVN im Tab
„Repository“ sollte „Check out trunk content instead of project itself“ aktiviert sein, damit nur der Trunk
Inhalt direkt unter dem Project Root ausgecheckt wird.
Der Testcode in wegen den unterschiedlichen Klassenpfaden in plattformspezifische Projekte aufgeteilt.
Es gibt zusätzlich zu den .launch Files ein Ant Script welche sämtliche Tests für beide Plattformen
ausführt und den JUnit Report erstellt: IwaTestGae/scripts/buildJUnitReport.xml.
Um das iwa-x.y.z.jar file (IWA Binaries) zu erstellen, kann mit dem in Eclipse unter
Iwa/scripts/build.jardesc ein voreingestellter Dialog aufgerufen werden.
Um ein neues IWA-basiertes Projekt „from Scratch“ zu erzeugen, wird auf
Iwa/doc/developersguide/IwaDevelopersGuide.pdf verwiesen.
Seite 73 von 83
Masterthesis MT-11-01.04 VEMICO
12 Project Management
Es gibt nichts Verkehrteres, als auf Grund theoretischer Arbeiten sogleich eine Flugmaschine
fix und fertig bauen zu wollen.
Beim Herumraten und planlosen Probieren komme für die Fliegerkunst überhaupt nichts heraus.
Der Übergang müsse vielmehr planvoll und schrittweise erfolgen.
(Otto Lilienthal)
12.1 Vorgehensmodell
Aufgrund der Natur der vorliegenden Arbeit (relativ klare Anforderungen, mittlere Technologierisiken
und sehr kleines Projektteam) sollte ein eher konservatives Vorgehensmodell, welches aber trotzdem
Iterationen zulässt, zur Anwendung kommen.
Der „Agile Unified Process“ (AUP), seinerseits eine vereinfachte Varianten des „Rational Unified Process“
(RUP) kann soweit massgeschneidert werden, dass er sehr gut für dieses Projekt passt.
AUP ist „sequentiell im Grossen, iterativ im Kleinen“: In den vier Hauptphasen können die
verschiedenen Disziplinen iterativ ausgeführt werden.
Abbildung 40 Agile Unified Process (Quelle: http://www.ambysoft.com)
Es soll eher „vertikal“ vorgegangen werden: Zuerst einen exemplarischen Use Case durchgängig
implementieren, dann aufgrund der Erkenntnisse Konzepte anpassen und anschliessend die restlichen
Use Cases realisieren.
Seite 74 von 83
Masterthesis MT-11-01.04 VEMICO
12.2 Lieferobjekte
AUP sieht pro Disziplin verschiedene Lieferobjekte vor. Obwohl nur wenige zwingend sind, soll an dieser
Stelle ein kleiner Überblick der in der Disziplin „Model“ zu erstellenden Lieferobjekte gegeben werden,
nicht zuletzt um die Struktur des vorliegenden Dokumentes nachvollziehen zu können.
In der Disziplin „Model“ entstehen die meisten Lieferobjekte. AUP gruppiert die Lieferobjekte in
Requirements Model und Design Model.
Abbildung 41 Lieferobjekte in der AUP Disziplin "Model"
Um die Methodik im Detail zu erkunden kann man den AUP als .zip file von der Homepage [1]
herunterladen und lokal entpacken.
Seite 75 von 83
Masterthesis MT-11-01.04 VEMICO
12.3 Planung
Ein Plan ist nichts, Planung ist alles.
(General Dwight D. Eisenhower)
Als Basis für die Planung dienen die bereits in der Themeneingabe [6] erstellten Arbeitspakete.
Zusätzlich wurden am Kick Off Meeting folgende Meilenstein Meetings mit dem Experten und dem
Betreuer definiert:



Dienstag, 17. Mai 2011: Milestone 1, Review Anforderungen und Planung
Mittwoch, 15. Juni 2011 Milestone 2, Review Entwurf
Mittwoch, 21. September 2011: Milestone 3, Interne Präsentation
Tätigkeit
Start
Ende
Dauer
Ein Gantt Diagramm findet sich im Anhang A „Planung“.
Seite 76 von 83
Masterthesis MT-11-01.04 VEMICO
13 Abschluss
Nichts gewusst, dafür etwas gelernt.
(Flitz Flosch und Karl Kiebitz im Kindermagazin „Spick“)
Dieses Kapitel beinhaltet einige abschliessende Betrachtungen.
13.1 Fazit
Das Ziel dieser Masterthesis war es, eine Vereinsmitgliederverwaltungs Webanwendung zu bauen,
welche sowohl in der Google App Engine als auch im Apache Tomcat läuft. Dieses Ziel konnte erreicht
werden. Es wurden alle „Muss“ und „Soll“ Anforderungen sowie sogar einige „Kann“ Anforderungen
erfüllt.
Als „Nebenprodukt“ der Arbeit konnte der Teil der Anwendung welcher ein WiederverwendungsPotential hat, als eigenständiges Open Source Projekt (IWA, [12]) erstellt werden.
Die eingesetzte Methodik „ Agile Unified Process“ [1] mit der Vorgehensweise „Sequentiell im Grossen,
Iterativ im Kleinen“ hat sich für dieses Projekt sehr gut bewährt. Der Zeitplan konnte, ausser einer
anfänglichen kleinen Verzögerung (siehe im nächsten Kapitel den Abschnitt „Vielfalt der Frameworks
und Tools“), eingehalten werden.
13.2 Erkenntnisse
Auf einige Erkenntnisse soll speziell eingegangen werden.
13.2.1 Vielfalt der Frameworks und Tools
Am meisten unterschätzt hatte ich den notwendigen Zeitaufwand, um all die verschiedenen Werkzeuge,
Bibliotheken und Frameworks zu evaluieren, zum Laufen zu bringen und auszuprobieren.
13.2.2 Google App Engine
Es wird eine leistungsfähige, kostenlose Hosting Plattform versprochen. Aber „TANSTAAFL” (there ain’t
no such thing as a free lunch)1 gilt auch für Google App Engine.
Einerseits muss man bereit sein, entsprechend Zeit zu investieren um die Plattform Besonderheiten zu
erlernen. Es muss auch Zeit eingeplant werden um lückenhafte Dokumentation zu kompensieren und
Umgehungslösungen für fehlende Funktionalität zu implementieren. Die grösste Herausforderung für
typische Business Anwendungen ist sicherlich die spezielle Data Store Persistenz Schicht der Google App
Engine mit Ihren beschränkten relationalen Möglichkeiten.
Andererseits kann es sein, dass eine Anwendung in der kostenlosen Standard App Engine Konfiguration
eher etwas langsam läuft. Spürbar schneller läuft eine Anwendung im kostenpflichtigen „Backend“2
Betrieb, wo man verschiedene Kategorien von Speicher- und Rechnerleistung auswählen kann. Eine
Anleitung zum entsprechenden Deployment ist im Kapitel Betriebshandbuch enthalten.
1
http://de.wikipedia.org/wiki/TANSTAAFL
2
http://code.google.com/appengine/docs/java/backends/overview.html
Seite 77 von 83
Masterthesis MT-11-01.04 VEMICO
13.3 Mögliche Verbesserungen und Erweiterungen
Aus Zeitgründen gibt es in einigen Bereichen der Anwendung durchaus noch Potential für
Verbesserungen oder Erweiterungen an VEMICO und/oder IWA.
13.3.1 Implementation
13.3.1.1 Browser Multitab Support
Eine bekannte Einschränkung des Vaadin Frameworks ist es, dass pro Browser nur eine Session möglich
ist. Für den Einbau der ebenfalls bekannten Umgehungslösung1 müsste die „appfoundation“ library an
einigen Stellen angepasst werden. Die nächste Version von Vaadin (Version 7) stellt allerdings eine
eingebaute Lösung in Aussicht.
13.3.1.2 JPA
Aktuell werden an einigen Stellen in der Anwendung mehrere Entities nacheinander in eigenen
Transaktionen nachgeführt. Das hat natürlich zur Konsequenz dass wenn eine nachfolgende Transaktion
schiefgeht, die Vorhergehende nicht rückgängig gemacht wird.
Voraussetzung wäre der Umbau des Persistenz Layers nach spezifischer Implementation pro Ziel
Plattform wie im Kapitel „Implementation“ im Abschnitt „Persistenz“ beschrieben. Mit der aktuellen,
„nackten“ JPA Lösung lässt sich dies wegen dem unterschiedlichen Transaktionsverhalten von JPA auf
den unterschiedlichen Plattformen nicht so einfach erreichen.
13.3.1.3 Unittest Abdeckung
Die JUnit Testabdeckung ist aus Zeitgründen etwas dünn ausgefallen. Die Infrastruktur ist allerdings
vollständig eingerichtet (JUnit Basisklassen für GAE und MySQL, JUnit Report Ant Script, Easymock
Library inklusive Beispiele).
13.3.2 Fachliches
Einige Funktionen wurden nicht realisiert, und einige Erweiterungswünsche sind bereits bekannt.
13.3.2.1 Export/Import Funktion
Obwohl der Back-Up/Restore Anwendungsfall für beide Plattformen beschrieben ist und funktioniert,
wäre eine Export/Import Funktion sicher nützlich um zum Beispiel Plattform Migrations Szenarien oder
Reports mit Office Tools zu erleichtern.
13.3.2.2 Opt-In
Eine Anmeldungsfunktion für den Newsletter wäre sehr rasch realisiert.
13.3.2.3 Mitgliedschaft und Zahlungen trennen
Aktuell ergibt sich die Rolle im Verein durch Eingang der Zahlung. Diese Kopplung könnte aufgelöst
werden, Zahlungen unabhängig von der Vereinsmitgliedschaft verwaltet werden.
1
http://vaadin.com/forum/-/message_boards/view_message/158627
Seite 78 von 83
Masterthesis MT-11-01.04 VEMICO
13.4 Ausblick IWA
Es folgt ein kurzer Ausblick für mögliche Weiterentwicklungen des IWA Projektes.
13.4.1 Mehr Flexibilität
Obwohl ein Ziel von IWA die möglichst einfache Benutzung ohne viele Einstellmöglichkeiten ist, wäre in
einigen Bereichen wie zum Beispiel den Java Mail Properties eine etwas bessere Steuerbarkeit durchaus
sinnvoll.
13.4.2 Maven Support
Für das IWA Projekt mit erweitertem Benutzerkreis würde ein Umbau des IWA Projekt Struktur gemäss
Maven und ein Mavenbuild File eine Integration in verschiedene Entwicklungsumgebungen
vereinfachen.
13.4.3 Weitere Plattformen
Der Betrieb in weiteren Servlet Container müsste ohne oder mit kleinem Aufwand möglich sein (als
interner, lokaler Test Container für App Engine wird zum Beispiel Jetty verwendet). Eine neue
interessante Alternative im Cloud Bereich ist das Open Source Projekt „Cloud Foundry1“, welches unter
anderem einen hosted MySQL Dienst anbietet.
13.4.4 Vaadin Add On
Als IWA „Add-On“ würde IWA unter Umständen einen grösseren Benutzerkreis ansprechen. Das
Erstellen eines Add-On aufgrund der bestehenden Code und Dokumentation müsste mit relativ kleinem
Aufwand möglich sein2.
13.4.5 IDE Plugins
Die Integration von IWA Wizards via Plugins würde es erlauben, in der eigenen IDE dialoggeführt eine
neues IWA Projekt zu erstellen.
13.5 Trivia
Die Abkürzung „VEMICO“ ist eine Anlehnung an einige in den neunziger Jahren bei der damaligen PTT
gebauten EDV Systeme, deren Namen alle mit „CO“ (= mit Computer) endeten. Das berühmteste,
„TERCO“3 (Telefonrationalisierung mit Computer), ist heute noch in Betrieb.
1
http://www.cloudfoundry.com/
2
http://vaadin.com/directory/help
3
http://www.parlament.ch/afs/data/d/gesch/1986/d_gesch_19860104_002.htm
Seite 79 von 83
Masterthesis MT-11-01.04 VEMICO
14 Abbildungen
Abbildung 1 Use Case Model ...................................................................................................................... 15
Abbildung 2 UC3 - Benutzer und Rechte .................................................................................................... 17
Abbildung 3 User Interface Main Layout .................................................................................................... 28
Abbildung 4 Domain Model........................................................................................................................ 29
Abbildung 5 Objectify vs. Twig ................................................................................................................... 33
Abbildung 6 Objectify vs. Twig ................................................................................................................... 33
Abbildung 7 System Overview .................................................................................................................... 37
Abbildung 8 Vaadin Framework Architecture (Quelle: http://vaadin.com) .............................................. 38
Abbildung 9 Vaadin Client Side Architecture (Quelle: http://vaadin.com/book) ...................................... 39
Abbildung 10 Anwendungsgerüst .............................................................................................................. 40
Abbildung 11 Vemico Modulkonzept ......................................................................................................... 41
Abbildung 12 Entity Class Model ................................................................................................................ 42
Abbildung 13 Autorisierungsmodell ........................................................................................................... 43
Abbildung 14 Deployment in Google AppEngine ....................................................................................... 44
Abbildung 15 Deployment in Apache Tomcat ............................................................................................ 44
Abbildung 16 Applikation ........................................................................................................................... 47
Abbildung 17 IWA Sample Module ............................................................................................................ 48
Abbildung 18 IwaSampleModule.java ........................................................................................................ 48
Abbildung 19 IwaSampleApplication.java .................................................................................................. 49
Abbildung 20 IwaSampleView.java ............................................................................................................ 49
Abbildung 21 IwaSamplePresenter.java ..................................................................................................... 50
Abbildung 22 Vaadin Data Model (Quelle: http://vaadin.com/book) ....................................................... 52
Abbildung 23 Vaadin Forms........................................................................................................................ 53
Abbildung 24 Vaadin Item Container ......................................................................................................... 53
Abbildung 25 Persistenz ............................................................................................................................. 54
Abbildung 26 Persistence Integration Tests ............................................................................................... 55
Abbildung 27 DAO und abstrakte Fabrik (Quelle: http://java.sun.com) .................................................... 56
Abbildung 28 i18n....................................................................................................................................... 57
Abbildung 29 VEMICO JUnit Report ........................................................................................................... 63
Abbildung 30 IWA JUnit Report .................................................................................................................. 63
Abbildung 31 Eclipse App Engine Deploy Dialog ........................................................................................ 65
Abbildung 32 GAE Dashboard .................................................................................................................... 67
Abbildung 33 MySQL Workbench............................................................................................................... 68
Abbildung 34 Hilfelink in VEMICO .............................................................................................................. 69
Abbildung 35 Entwicklungsumgebung ....................................................................................................... 70
Abbildung 36 Lokale App Engine in Eclipse ................................................................................................ 70
Abbildung 37 Tomcat in Eclipse.................................................................................................................. 70
Abbildung 38 Eclipse Projektstruktur ......................................................................................................... 72
Abbildung 39 IWA Projekte ........................................................................................................................ 73
Abbildung 40 Agile Unified Process (Quelle: http://www.ambysoft.com) ................................................ 74
Abbildung 41 Lieferobjekte in der AUP Disziplin "Model" ......................................................................... 75
Abbildung 42 Planung................................................................................................................................. 81
Abbildung 43 Generiertes MySQL DB Modell ............................................................................................ 82
Seite 80 von 83
Masterthesis MT-11-01.04 VEMICO
A.
Planung
Abbildung 42 Planung
Seite 81 von 83
Masterthesis MT-11-01.04 VEMICO
B.
Generiertes DB Model
Das Bild wurde mit dem Tool „MySQL Workbench“ generiert.
Abbildung 43 Generiertes MySQL DB Modell
Seite 82 von 83
Masterthesis MT-11-01.04 VEMICO
C.
Ergonomie Test Report
Der ISONORM 9241/10 Fragebogen (unter Vemico/doc/test/usability) wurde von drei
Vorstandsmitgliedern des Vereins Guild42 (alles Informatiker) und einer Organisatorin ausgefüllt.
Obwohl sicher eher wohlwollend ausgefüllt und die Testgruppe schon rein von der Grösse her nicht
repräsentativ war, deckt sich das Resultat mit den Erwartungen. Aufgrund der geringen fachlichen
Komplexität empfanden die Tester die Anwendung als leicht erlern- und bedienbar.
Bei der Individualisierbarkeit ist die Bewertung eher tief, es sind für den einzelnen Benutzer ausser der
Sprachwahl und den Möglichkeiten des eingesetzten Browser auch keine Möglichkeiten vorhanden.
Seite 83 von 83
Masterthesis MT-11-01.04 VEMICO
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement