vereinsmitgliederverwaltung mit computerstatic.sws.bfh.ch/download/mt-11-01-04-doc.pdf · jdo java...
TRANSCRIPT
Seite 1 von 83 Masterthesis MT-11-01.04 VEMICO
Projektdokumentation
VEMICO Vereinsmitgliederverwaltung mit Computer
Masterthesis Nummer: MT-11-01.04
Datum: 22. September 2011
Version: 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
Experte: Prof. Dr. Stephan Fischli
Berner Fachhochschule
Wankdorffeldstrasse 102
3014 Bern
031 848 32 74
Betreuer: Dipl. Ing. Daniel Aeschbacher
Präsident Guild42.ch
Lutertalstrasse 37
3065 Bolligen
079 822 68 47
Seite 2 von 83 Masterthesis MT-11-01.04 VEMICO
1 Änderungskontrolle
Version Änderung Datum Author
0.1 Erste Version 15.5.2011 Mischa Christen
0.2 Anforderungen und Planung nach erster Review
Sitzung überarbeitet
21.5.2011 Mischa Christen
0.3 Use Cases nach zweitem Review überarbeitet 24.06.2011 Mischa Christen
0.4 Vor finalem Review 18.09.2011 Mischa Christen
1.0 Finale Version 22.09.2011 Mischa Christen
Seite 3 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
5.1 Zweck und Struktur des Dokuments .......................................................................................... 10
5.2 Ausgangslage .............................................................................................................................. 10
5.3 Problemstellung .......................................................................................................................... 10
5.4 Lösung ......................................................................................................................................... 10
6 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 4 von 83 Masterthesis MT-11-01.04 VEMICO
6.5 Domain Model ............................................................................................................................ 29
6.5.1 Fachliche Entitäten ............................................................................................................. 29
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 Deployment Model ..................................................................................................................... 44
7.5.1 Deployment in Google AppEngine...................................................................................... 44
7.5.2 Deployment in Apache Tomcat .......................................................................................... 44
8 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 Das Thread Local Pattern .................................................................................................... 47
8.4 Modul Konzept ........................................................................................................................... 48
8.4.1 Entwicklerhandbuch ........................................................................................................... 48
8.4.2 Navigation ........................................................................................................................... 51
Seite 5 von 83 Masterthesis MT-11-01.04 VEMICO
8.4.3 Databinding ........................................................................................................................ 52
8.5 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 Benutzerhandbuch ..................................................................................................................... 69
11 Configuration Management ........................................................................................................... 70
11.1 Entwicklungsumgebung .............................................................................................................. 70
11.1.1 Hilfsmittel ........................................................................................................................... 71
11.2 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 Abschluss ........................................................................................................................................ 77
13.1 Fazit ............................................................................................................................................ 77
Seite 6 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 7 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.ergo-
online.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/project-
management-sources/Nasa-Hundred-Rules-for-Project-Managers.pdf
Seite 8 von 83 Masterthesis MT-11-01.04 VEMICO
4 Begriffe und Abkürzungen Begriff Erklärung
AUP Der „Agile Unified Process“ [1]
Cloud Computing 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.
CRUD Create, Read, Update, Delete: Die typischen Operationen auf Daten
GWT 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.
Google App Engine 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.
IDE Integrated Development Environment. Entwicklungsumgebung zur Herstellung
von Software
IaaS 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.
I18n Abkürzung für „Internationalization“, Internationaliserung auf Englisch hat 18
Buchstaben zwischen dem ersten (I) und letzten Buchstaben (n)
JDO Java Data Objects, ein ORM Standard
JPA Java Persistence API, ein ORM Standard
MVC Model View Controller: Ein Pattern, welches hilft die Darstellungslogik von der
Geschäftslogik zu trennen
MVP 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
ORM Object Relational Mapping: Persistieren und wieder in den Arbeitspeicher lesen
von Objekten, möglichst automatisch
POJO 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
PaaS 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 9 von 83 Masterthesis MT-11-01.04 VEMICO
Beispiele: Google App Engine, Cloudfondry, Windows Azure, Force.com
RUP Der „Rational Unified Process“ [4]
SaaS Software as a Service: Cloud Computing in der Maximalausprägung, der Benutzer
braucht nur noch einen Webbrowser.
Beispiele: Gmail, Google Docs, Salesforce.
Vaadin 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.
VM Virtuelle Maschine, die Java Laufzeitumgebung
Seite 10 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 Administrations-
aufwand 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 11 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 Anforderung Priorität
FA-M1 Mitgliederstamm
Vereinsmitglieder können mit ihren Kontaktdaten (Name,
Email) und der Rolle im Verein verwaltet (Suchen, erfassen,
editieren, löschen) werden
Muss
FA-M2 Mitgliederhistorie
Die Rollen im Verein werden historisiert und können
angezeigt werden
Muss
FA-M3 Anmeldung
Neumitglied
Ein neues Mitglied kann sich online anmelden (in Sinne
eines Antrages zur Aufnahme) und bekommt ein
Bestätigungsmail
Soll
FA-M4 „Self-Care“
Das Vereinsmitglied kann seine Kontaktdaten selbstständig
verwalten
Soll
FA-M5 Log Die Änderungen an den Mitgliederdaten werden
aufgezeichnet und können eingesehen werden
Kann
Seite 12 von 83 Masterthesis MT-11-01.04 VEMICO
6.1.2.2 Newsletter
ID Titel Anforderung Priorität
FA-N1 Newsletter
erstellen
Es können Newsletters erstellt und an Verteilerlisten
verschickt werden
Muss
FA-N2 Verteilerlisten Es können Newsletter Verteilerlisten verwaltet werden Muss
FA-N3 „Opt-Out“
Funktion
Es gibt eine "Self-Care Opt-Out" Funktion, um keine
Newsletters mehr zu erhalten
Muss
FA-N4 Newsletter Archiv Die verschickten Newsletter werden gespeichert (mit der
Veranstaltung verknüpft)
Soll
FA-N5 Andere Kanäle Die Newsletter können auch auf Kanälen wie Social Media,
SMS etc. verschickt werden
Kann
6.1.2.3 Veranstaltungen
ID Titel Anforderung Priorität
FA-V1 Veranstaltungen Die Veranstaltungen können verwaltet werden Muss
FA-V2 Anmelden Teilnehmer können sich für Veranstaltungen anmelden Muss
FA-V3 Medien Die Präsentationen der Veranstaltungen können hoch-
bzw. runtergeladen und verwaltet werden
Kann
FA-V4 Abmelden Teilnehmer können sich für Veranstaltungen abmelden Kann
6.1.2.4 Benutzerverwaltung
ID Titel Anforderung Priorität
FA-B1 Verwaltung Es können Benutzer verwaltet werden Muss
FA-B2 Anmeldung Der Benutzer muss sich authentifizieren Muss
FA-B3 Rollenmodell Benutzer können Rollen zugewiesen werden. Einer Rolle
können Rechte zugewiesen werden
Muss
FA-B4 Passwort Der Benutzer kann sein Passwort selber setzen und im
Verlustfall vom System ein Neues anfordern
Soll
6.1.2.5 Import/Export
ID Titel Anforderung Priorität
FA-I1 Import/Export Sämtliche Nutzdaten der Anwendung sollen via die
Weboberfläche in Files exportiert und von Files Importiert
werden können
Kann
6.1.2.6 Internationalisierung und Lokalisation
ID Titel Anforderung Priorität
FA-ME1 Internationalisier-
rung
Die Anwendung ist lokalisierbar. Benutzer können zwischen
den verschiedenen Sprachen wählen. Die Lokalisierung in
verschiedene Sprachen an sich ist nicht Teil dieser
Anforderung
Soll
FA-ME2 Lokalisierung Die Anwendung kann in Deutsch bedient werden Muss
Seite 13 von 83 Masterthesis MT-11-01.04 VEMICO
6.1.2.7 Beiträge
ID Titel Anforderung Priorität
FA-BE1 Beitragszahlungen Die Beitragszahlungen der Mitglieder können verwaltet
werden
Soll
6.1.2.8 Vereinsartefakte
ID Titel Anforderung Priorität
FA-VA1 Vereinsartefakte Dokumente wie Protokolle etc. können hochgeladen und
verwaltet werden
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 Priorität
SNFA-1 Laufzeitumgebung Die Applikation kann sowohl auf einem konventionellen
Applikationsserver (oder Servlet Container) als auch in der
Google App Engine Umgebung betrieben werden
Soll
SNFA-2 Persistenz Die Applikation kann automatisch oder konfigurativ auf die
entsprechenden Persistenzmöglichkeiten der jeweiligen
Plattform eingestellt werden
Soll
SNFA-3 Benutzerkonten Der Benutzer kann sich mit der gleichen Identifikation
authentifizieren, unabhängig wie oder wo die Anwendung
betrieben wird
Soll
SFNA-4 Dokumentation
der
Portabilitätsfragen
Die gemachten Untersuchungen in Bezug auf SNFA-1 – 3
sind unabhängig vom Resultat dokumentiert
Muss
SNFA-5 Entwicklungs-
prozess,
Frameworks und
Tools
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
Muss
6.1.3.2 Allgemeine nichtfunktionale Anforderungen
ID Titel Anforderung Priorität
ANFA-1 Zuverlässigkeit Die Daten werden gesichert oder können gesichert werden Muss
ANFA-2 Leistung und
Effizienz
Die Antwortzeiten liegen für interaktive Vorgänge unter
fünf Sekunden
Muss
ANFA-3 Änderbarkeit Das System ist so strukturiert, dass zusätzliche
Funktionalität einfach eingebaut werden kann
Muss
ANFA-4 Sicherheit Schützenswerte Daten (speziell Mitgliederdaten) müssen
vor unberechtigtem Zugriff via Benutzeroberfläche oder
Webserver geschützt sein.
Muss
Seite 14 von 83 Masterthesis MT-11-01.04 VEMICO
Abgrenzung: Weitergehende Sicherheitsmassnahmen wie
zum Beispiel Verschlüsselte Kommunikation oder
Datenablage ist nicht erforderlich
ANFA-5 Korrektheit der
Funktionalität
Es existieren automatische Unittests um das Funktionieren
der Kernfunktionalität zu verifizieren
Muss
ANFA-6 Ergonomie Die Anwendung soll nach den Kriterien des ISONORM
9241/10 Fragebogens [7] geprüft werden und ein
genügendes Resultat erzielen
Muss
Seite 15 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.
Abbildung 1 Use Case Model
1 http://en.wikipedia.org/wiki/Use_case#Business_vs._System_Use_Cases
uc Use Case Model
Vemico
Vorstandsmitglied
Anonymer Benutzer
UC1 - Anmelden
UC3 - Benutzer und
Rechte verwaltenUC10 - Anmelden für
Anlass
UC5 - Personendaten
v erwalten
UC7 - Anlässe v erwalten
UC4 - Mailinglisten
v erwalten
UC11 - Abmelden v on
Anlass
UC6 - Mitgliederbeiträge
v erwalten
UC12 - Mitgliedschaft
beantragen
UC9 - Daten importieren
und exportieren
UC2- Neues Passwort
v erlangen
UC8 - Newsletters
v erwalten/v ersenden
UC13 - Von Mailinglisten
abmelden
UC14 - Kontaktdaten
v erwalten
Administrator
Vereinsmitglied
«include»
«include»
«extend»
«include»
«include»
«include»
«include»
«include»
«extend»
«include»
Seite 16 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 Benutzer
Vorbedingungen Benutzer ist im System bekannt
Benutzer ist nicht angemeldet
Auslöser Benutzer klickt auf „Passwort vergessen“
Hauptszenario 1. Benutzer gibt seine E-Mail Adresse ein
2. System findet Benutzerdaten, setzt neues Passwort und sendet dieses
per E-Mail an den Benutzer
Alternativszenario 2a. Falls die E-Mail Adresse nicht gefunden wird, oder E-Mail nicht
verschickt werden kann wird ein Fehler angezeigt
Nachbedingungen Neues Passwort ist im System gesetzt, E-Mail ist versendet
Seite 17 von 83 Masterthesis MT-11-01.04 VEMICO
6.2.3 UC3 - Benutzer und Rechte verwalten
Das ist ein abstrakter Use Case.
Akteure Benutzer
Vorbedingungen Benutzer ist angemeldet
Benutzer hat entsprechende Berechtigung
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
uc UC3 - Benutzer und Rechte v erwalten
UC3.1 - Benutzer
suchen
UC3.2 - Benutzer
erstellenUC3.4 - Benutzer
löschen
UC3 - Benutzer und
Rechte verwalten
UC3.3 - Benutzer
ändern
UC3.5 Rollen und
Module v erwalten
Seite 18 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 Benutzer selektiert „Rollen und Module“ Ansicht
Hauptszenario Benutzer erstellt, modifiziert oder löscht Berechtigungen
Alternativszenario Benutzer erfasst neue Rolle
Nachbedingungen 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 19 von 83 Masterthesis MT-11-01.04 VEMICO
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
Alternativszenario 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
Nachbedingungen Ä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 20 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 Benutzer
Vorbedingungen Benutzer ist angemeldet
Benutzer hat entsprechende Berechtigung
Auslöser Benutzer selektiert Ansicht „Personen“
Hauptszenario 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 21 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
Benutzer hat entsprechende Berechtigung
Auslöser Benutzer selektiert entsprechende Ansicht „Newsletters“
Hauptszenarios 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
Alternativszenario 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
Nachbedingungen 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 22 von 83 Masterthesis MT-11-01.04 VEMICO
Vorbedingungen Benutzer ist angemeldet
Benutzer hat entsprechende Berechtigung
Für Import: Es sind keine Daten im System vorhanden
Auslöser Benutzer selektiert entsprechende Ansicht „Import/Export“
Hauptszenario 1. Benutzer selektiert Quell- bzw. Zielfile
2. Benutzer klickt „Upload“ bzw. „Download“
Alternativszenario 2a. Bei Upload wird eine Warnung angezeigt falls bereits Daten im System
vorhanden sind
Nachbedingungen 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 E-
Mail 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 23 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 Benutzer
Vorbedingungen Benutzer ist angemeldet und hat entsprechende Rechte
Auslöser Vereinsmitglied meldet sich an um seine eigenen Kontaktdaten zu editieren
Hauptszenario 1. Vereinsmitglied meldet sich am System an
2. Kontaktdaten werden angezeigt (nur die eigenen)
3. Kontaktdaten werden editiert und gespeichert
Alternativszenario
Nachbedingungen Kontaktdaten sind mutiert
Seite 24 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 25 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 Es existiert eine Person mit einer E-Mail Adresse
Instruktionen Es wird eine weitere Person mit der gleichen E-Mail Adresse erfasst, entweder
via „Mitglieder“ View oder via „Anträge“ View
Erwartetes Resultat 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 Person ist erstellt
Instruktionen Personendaten ändern
Erwartetes Resultat 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 Es existiert eine Person mit Engagement(s)
Instruktionen Person löschen
Erwartetes Resultat 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,
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,
6.3.2.5 FA-M5-T3 Logfile Engagement
Wenn ein Engagement gelöscht wird, soll dies im Logfile festgehalten werden.
Vorbedingungen Es existiert ein Engagement
Instruktionen Engagement löschen
Erwartetes Resultat Es existiert ein Logfile Eintrag, zum Beispiel: INFO: 2011-08-16 01:08:57 (User: m): Deleted Engagement:
Seite 26 von 83 Masterthesis MT-11-01.04 VEMICO
Mitglied, 01.08.2011-31.08.2011 (SFr. 20.00) of Person: Ukel Urs,
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
„Anmelden“ Schaltfläche drücken
Erwartetes Resultat 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 Es existiert ein Benutzer mit einer E-Mail Adresse
Instruktionen Es wird eine weiterer Benutzer mit der gleichen E-Mail Adresse erfasst
Erwartetes Resultat Es wird eine Fehlermeldung angezeigt
Seite 27 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
Im Dialog die neue Sprache wählen
Bestätigen
Erwartetes Resultat 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
Im Dialog die neue Sprache wählen
Bestätigen
Browser schliessen
Browser wieder öffnen und zum Login Screen navigieren
Erwartetes Resultat 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
Im Dialog die neue Sprache „German“ (oder „Deutsch“) wählen
Bestätigen
Einloggen
Erwartetes Resultat Anwendung wird in Deutsch ausgeführt
6.3.6 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 28 von 83 Masterthesis MT-11-01.04 VEMICO
Einloggen
Erwartetes Resultat 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 29 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.
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.
class Application Domain Model
Person Rolle
AnlassNewsletter
Mailingliste
Mitglieds Antrag
Mitgliederbeitrag
1
bezahlt für eine Zeitspanne
1
1
stellt einen
1
1
hat Liste der Teilnehmer
1
0..*
wird verschickt an
1..*
0..*
nimmt teil an
0..*
0..*
bezieht sich auf
1
1..*
hat in einer
Zeitspanne
10..*
Enthält
1..*
Seite 30 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 Anwendungs-
Frameworks 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 31 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 32 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 33 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 34 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 35 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 36 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 37 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
Browser
Vaadin Client Engine
Servlet
GWT
Vaadin Framework
Instant Web App IWA
JPA
VEMICO Application
VEMICO
Module A
VEMICO
Module B
JavaMail
IWA
Module A
VEMICO
Module X
Appfoundation
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 38 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 39 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 40 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
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).
class Application Class Model
«interface»
IWA::ModuleView
Vaadin::
Application
IWA::IwaApplication
«interface»
Appfoundation::
View
IWA::MainWindow
ConcreteView
IWA::
ModuleRegistry
ConcreteModule
Appfoundation::
ViewHandler
«interface»
Appfoundation::
ViewContainer
Vaadin::Window Appfoundation::
Permissons
Appfoundation::
SessionHandler
Appfoundation::
Lang
«interface»
IWA::Module
«interface»
Appfoundation::
IFacade
ConcretePresenter«interface»
IWA::
ModulePresenter
Appfoundation::
FacadeFactory
Appfoundation::
JPAFacade
IWA::
AbstractModulePresenter
IWA::
AbstractModuleView
IWA::
AbstractModule
Appfoundation::
User
VemicoApplication
1
1
0..*
1
1..*
Seite 41 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.
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
class Module Concept Class Model
«interface»
IWA::Module
«interface»
IWA::ModuleView
ConcreteModule
IWA::
ModuleRegistry
ConcreteView ConcretePresenter
«interface»
Appfoundation::
View
«interface»
IWA::
ModulePresenter
«interface»
UI
IWA::
AbstractModuleView
IWA::
AbstractModulePresenter
IWA::
AbstractModule
«interface»
IWA::IwaModuleUI
IWA::
IwaApplication
1
1
1
1..*1 0..*
Seite 42 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
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
class Entity Class Model
Person
- name: String
- firstName: String
- emailAdress: String
- sex: Sex
Engagement
- dateEnd: Date
- dateStart: Date
- role: Role
- feePaid: float
Mailinglist
- name: String
Ev ent
- name: String
- speaker: String
- weblink: String
- date: Date
Newsletter
- name: String
- subject: String
- content: String
- recipients: Set<String>
- ccRecipients: Set<String>
- bccRecipients: Set<String>
- dateSent: Date
MembershipApplication
- date: Date
- role: Role
- name: String
- firstName: String
- emailAddress: String
- sex: Sex
- remarks: String
An engagement makes
a person to a society
member
Participants of an
event are identified
through the respective
mailinglist
Recipient
- email: String
Google App Engine
DataStore does not
support many-to-many
relationships
Google App Engine
does not support
sensible inheritance
10..* 0..11
1 0..*
Seite 43 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.
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.
class Authorization Class Model
ModulePermission
- roleName: String
- moduleName: String
Appfoundation::
User
Appfoundation::
Role
IWA::
AbstractModule
No real Foreign Keys,
relation by String value
Seite 44 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 45 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 46 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 Inhalt
ch.ood.iwa IwaApplication, IwaContextListener und allgemeine Hilfsklassen
ch.ood.iwa.authorization Klassen für das Autorierungskonzept
ch.ood.iwa.module Allgemeine Modul Konzept
ch.ood.iwa.module.presenter Abstrakte und konkrete Presenter Klassen
ch.ood.iwa.module.presenter.util Hilfsklassen für die Presenter und FormFieldFactories
ch.ood.iwa.module.ui View Klassen für die Module
ch.ood.iwa.sample Die IWA Beispiel Anwendung
ch.ood.iwa.ui Visuelle Hilfsklassen
8.2.2.2 Package Struktur VEMICO
Im VEMICO Projekt sind die VEMICO Anwendungsspezifischen Packages enthalten.
Package Inhalt
ch.ood.vemico VEMICO Application und allgemeine Hilfsklassen
ch.ood.vemico.model Das VEMICO Domain Model
ch.ood.vemico.model.container Container für das Databinding
ch.ood.vemico.module Die VEMICO Module
ch.ood.vemico.module.presenter Konkrete Presenter Klassen für die Module
ch.ood.vemico.module.presenter.util Hilfsklassen für die Presenter und FormFieldFactories
ch.ood.vemico.module.ui View Klassen für die Module
Seite 47 von 83 Masterthesis MT-11-01.04 VEMICO
8.3 Die Anwendung Die VEMICO Anwendung ist als Vaadin Anwendung eigentlich ein Java Servlet.
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
class ApplicationMain
Appfoundation::
InternationalizationServ let
Vaadin::
VaadinApplicationServ let
Vaadin::
GAEApplicationServ let
Vaadin::
ApplicationServ let
VemicoApplication
IWA::
IwaApplication
Vaadin::
Application
Servlet, defined
in web.xml
Servlet, defined in
web.xml
IWA::
IwaContextListenerListener, defined in
web.xml
Seite 48 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 49 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 50 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 51 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 52 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 53 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.
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.
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
class Forms
View Form
FormFieldFactory
BeanItem Pojo
1
itemDataSource
class Table
Table BeanItemContainer Pojo
containerDataSource 0..*
Seite 54 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 55 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 56 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 57 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 58 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 59 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 Resultat
Mitglieder
FA-M1, Mitgliederstamm Muss UC5 - Personendaten verwalten OK
FA-M2, Mitgliederhistorie Muss UC5 - Personendaten verwalten OK
FA-M3, Anmeldung Neumitglied Soll UC12 - Mitgliedschaft beantragen OK
FA-M3-T1, Log Ablehnung Mitgliedschaft OK
FA-M4, "Self Care" Soll UC14 - Kontaktdaten bearbeiten OK
FA-M4-T-1, Eindeutige E-Mail Adresse Person OK
FA-M5, Log Mitgliederdaten Kann UC5 - Personendaten verwalten OK
FA-M5-T1, Audittrail OK
FA-M5-T2, Logeintrag Person OK
FA-M5-T3, Logeintrag Engagement OK
Newsletter
FA-N1, Newsletter erstellen/senden Muss UC8 - Newsletter verwalten/versenden OK
FA-N1-T1, Newsletter nur einmal senden OK
FA-N2, Verteilerlisten Muss UC4 - Mailinglisten verwalten OK
FA-N3, "Opt-Out" Funktion Muss UC13 - Von Mailinglisten abmelden OK
FA-N3-T1, Abmelden Mailinglisten OK
FA-N4, Newsletter Archiv Soll UC8 - Newsletter verwalten/versenden OK
FA-N5, Andere Kanäle Kann Nicht implementiert
Veranstaltungen
FA-V1, Veranstaltungen verwalten Muss UC7 - Anlässe verwalten OK
FA-V2, An Veranstaltungen anmelden Muss UC10 - Anmelden für Anlass OK
FA-V3, Medien verwalten Kann Nicht implementiert
FA-V4, Von Veranstaltung abmelden Kann UC11 - Abmelden von Anlass OK
Benutzerverwaltung
FA-B1, Verwaltung Muss UC3.1 - Benutzer suchen OK
Seite 60 von 83 Masterthesis MT-11-01.04 VEMICO
UC3.2 - Benutzer erstellen OK
UC3.3 - Benutzer ändern OK
UC3.4 Benutzer löschen OK
FA-B2, Authentifizierung Muss FA-B2-T1, Login OK
FA-B2-T2, Fehlerhaftes Login OK
FA-B3, Rollenmodell Muss UC3.5 - Rollen und Module verwalten OK
FA-B4, Passwort verlangen Soll UC2 - Neues Passwort verlangen OK
FA-B4-T-1, Eindeutige E-Mail Adresse Benutzer OK
Import/Export
FA-I1, Import/Export der Nutzdaten Kann Nicht implementiert (Backup/Restore: ANFA-1)
Internationalisierung
FA-ME1, Internationalisierung Soll FA-ME1-T1, Sprache umstellen via GUI OK
FA-ME1-T2, Gewählte Sprache Browser Cookie OK
FA-ME1-T3, Sprache umstellen via URL OK
FA-ME2, Lokalisierung in Deutsch Muss FA-ME2-T1, Lokalisation in Deutsch OK
Mitgliederbeiträge
FA-BE1, Beiträge verwalten Soll UC6 - Mitgliederbeiträge verwalten OK
Vereinsartefakte
FA-V1, Vereinsartefakte verwalten Kann Nicht implementiert
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 Soll OK
SNFA-2 Persistenz Soll OK
SNFA-3 Benutzerkonten Soll OK
SNFA-4 Dokumentation Portabilität Muss OK
SNFA-5 Dokumentation Entwicklungprozess/Tools Muss OK
Allgemeine NFA
ANFA-1 Zuverlässigkeit Muss OK
ANFA-2 Leistung/Effizienz Muss OK
ANFA-3 Änderbarkeit Muss OK
ANFA-4 Sicherheit Muss OK
ANFA-5 Korrektheit Muss OK
ANFA-6 Ergonomie Muss OK
Seite 61 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 62 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 63 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 64 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 Beispielwert Erklärung
mail.host mail.bluewin.ch SMTP Mailhost (für Google App Engine irrelevant)
iwa.mail.sender.mail [email protected] Absenderadresse für E-Mails (zum Beispiel das „Lost Password“ Mail)
iwa.mail.sender.name Guild42 Absendername für E-Mails (zum Beispiel das „Lost Password“ Mail)
iwa.languages de;en Unterstützte Sprachen, im ISO-639 Format und Semikolon separiert. Die entsprechenden Texte werden im file WEB-INF/translations.xml definiert
iwa.app.name Vemico Applikationsname (frei wählbar)
iwa.environment VEMICO-TEST Umgebungsname (frei wählbar)
vemico.newsletter.receiver.mail [email protected] Empfängeradresse für Newsletters (Die Empfänger werden „Bcc“ hinzugefügt)
vemico.newsletter.receiver.name Undisclosed Recipients Empfängername für Newsletters
vemico.newsletter.sender.mail [email protected] Absenderadresse für Newsletters. In der Google App Engine muss dies ein eingetragener Administrator der Applikation sein.
vemico.newsletter.sender.name Guild42 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 65 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 backend@name 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 66 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/de-
DE/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://vemico-
guild42-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 67 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\META-
INF\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 68 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 69 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 70 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.
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
cmp Dev Env
Eclipse IDE
Tomcat 6 MySQL
Jetty Serv let
Container
Local DataStore
deploy and run
deploy and run
Seite 71 von 83 Masterthesis MT-11-01.04 VEMICO
11.1.1 Hilfsmittel
Für die VEMICO und IWA Entwicklung wurden folgende Hilfsmittel eingesetzt.
Zweck Software Referenz
Betriebssystem Microsoft Windows 7 Professional 64 bit
http://www.microsoft.com
Java JDK JDK 1.6.0, Build 25
http://www.oracle.com/technetwork/java/javase/downloads/index.html
App Engine SDK Google GAE SDK for Java 1.5.2
http://code.google.com/intl/de-DE/appengine/downloads.html#Google_App_Engine_SDK_for_Java
IDE Eclipse 3.6 J2EE (Helios)
http://www.eclipse.org/downloads/
Eclipse Plugins Google Vaadin Datanucleus Subversive
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
JPA Provider Datanucleus 1.1.5
http://sourceforge.net/projects/datanucleus/files/
Webframework Vaadin 6.6.2 http://vaadin.com/download
Browser Rendering Toolkit Google GWT 2.3
http://code.google.com/intl/de-DE/webtoolkit/
Vaadin Add-On’s Appfoundation 1.3.5 Confirmdialog 1.1.1
http://vaadin.com/directory#addon/appfoundation http://vaadin.com/directory#addon/confirmdialog
Datenbank MySQL 5.5 http://www.mysql.com/downloads/mysql/5.5.html#downloads
Datenbank Admin Tool MySQL Workbench 5.2
http://www.mysql.de/products/workbench/
Servlet Container Apache Tomcat 6
http://tomcat.apache.org/download-60.cgi
Unittests JUnit Easymock
http://www.junit.org/ http://easymock.org/
Build Tool Apache Ant http://ant.apache.org/
Grafiken Enterprise Architect Visio Powerpoint
http://www.sparxsystems.com/ http://www.microsoft.com http://www.microsoft.com
Dokumente Word http://www.microsoft.com
GUI Protoyping Balsamiq Mockup
http://balsamiq.com/products/mockups
Versionsverwaltungssysten Subversion http://subversion.tigris.org/
Planung Gantt Chart http://www.ganttproject.biz/
Seite 72 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.
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.
cmp Eclipse
Vemico
Vemico_Tomcat6
IWA
Vaadin
App Engine Libraries
Tomcat / MySQL Libraries
«import»
«use»
«use»
«use»
«use»
«use»
«use»
Seite 73 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 74 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 75 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 76 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 77 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 Wiederverwendungs-
Potential 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 78 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 79 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 80 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 81 von 83 Masterthesis MT-11-01.04 VEMICO
A. Planung
Abbildung 42 Planung
Seite 82 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 83 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.