Vereinsmitgliederverwaltung mit Computerstatic.sws.bfh.ch/download/MT-11-01-04-doc.pdf · JDO Java Data Objects, ein ORM Standard JPA Java Persistence API, ein ORM Standard MVC Model

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

[email protected]

Experte: Prof. Dr. Stephan Fischli

Berner Fachhochschule

Wankdorffeldstrasse 102

3014 Bern

031 848 32 74

[email protected]

Betreuer: Dipl. Ing. Daniel Aeschbacher

Präsident Guild42.ch

Lutertalstrasse 37

3065 Bolligen

079 822 68 47

[email protected]

mailto:[email protected]



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


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


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


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


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


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

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://code.google.com/intl/de-CH/webtoolkit/

http://www.martinfowler.com/eaaDev/ModelViewPresenter.html

http://de.wikipedia.org/wiki/Rational_Unified_Process

http://www.guild42.ch/

http://www.ergo-online.de/site.aspx?url=html/software/verfahren_zur_beurteilung_der/beurteilung_der_software_ergo.htm

http://www.ergo-online.de/site.aspx?url=html/software/verfahren_zur_beurteilung_der/beurteilung_der_software_ergo.htm

http://java.net/projects/petstore

http://java.sun.com/developer/technicalArticles/javase/swingappfr/

http://vaadin.com/home


http://code.google.com/p/instant-webapp/

http://www.oliverlehmann.com/project-management-sources/Nasa-Hundred-Rules-for-Project-Managers.pdf

http://www.oliverlehmann.com/project-management-sources/Nasa-Hundred-Rules-for-Project-Managers.pdf


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.


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


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.


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


6.1.2.2 Newsletter


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


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


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


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


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


6.1.2.7 Beiträge


FA-BE1 Beitragszahlungen Die Beitragszahlungen der Mitglieder können verwaltet

werden

Soll

6.1.2.8 Vereinsartefakte


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


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


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


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


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»


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


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


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


6.2.3.3 UC3.3 - Benutzer ändern


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



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


Mailinglisten Namen ändern:

1. Benutzer selektiert Mailliste aus Auswahlliste

2. Im Eingabefeld wird der Listenname angezeigt und kann geändert

werden


Mailinglisten Empfänger ändern:



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:


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



Auslöser Benutzer selektiert entsprechende Ansicht „Personen“

Hauptszenarios Person suchen:

1. Sämtliche Personen werden in einer Tabelle dargestellt

Person erstellen:


2. Eingabefelder werden leer, Personendetails können erfasst werden


Person ändern:

1. Benutzer selektiert Person aus Auswahlliste

2. In den Eingabefeldern werden Personendetails angezeigt und können

geändert werden


Person löschen:



3. Bei Bestätigung der Warnung wird die Person gelöscht

Engagements verwalten:


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



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



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



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:


2. Eingabefelder werden leer, Anlassdetails können erfasst werden


Anlass ändern:

1. Benutzer selektiert Anlass aus Auswahlliste

2. In den Eingabefeldern werden Anlassdetails angezeigt und können

geändert werden


Anlass löschen:

1. Benutzer selektiert Anlass aus Auswahlliste


3. Bei Bestätigung der Warnung wird der Anlass gelöscht

Alternativszenario Zu „Anlass löschen“:



Nachbedingungen Die Änderungen sind gespeichert

Die Änderungen sind auf der „Selfcare Portal“ Ansicht sichtbar

6.2.8 UC8 - Newsletters verwalten/versenden

Akteure Benutzer



Auslöser Benutzer selektiert entsprechende Ansicht „Newsletters“

Hauptszenarios Newsletter suchen:

1. Sämtliche Newsletters werden in einer Tabelle dargestellt

Newsletter erstellen:


2. Eingabefelder werden leer, Newsletter Details können erfasst werden

3. Es können Empfängerlisten ausgewählt sowie einzelne

Empfängeradressen eingegeben werden


Newsletter ändern:

1. Benutzer selektiert Newsletter aus Auswahlliste

2. In den Eingabefeldern werden Newsletter Details angezeigt und

können geändert werden


Newsletter löschen:

1. Benutzer selektiert Newsletter aus Auswahlliste



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“


4. Bei Bestätigung der Warnung wird der Newsletter gesendet

Alternativszenario Zu „Newsletter löschen“:


Zu „Newsletter senden“:


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




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


Vorbedingungen Anonymer Benutzer ist für Anlass angemeldet


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


Vorbedingungen


Hauptszenario 1. Anonymer Benutzer füllt Formular aus

2. Anonymer Benutzer klickt „Senden“

Alternativszenario

Nachbedingungen Antrag ist gespeichert


6.2.13 UC13 – Von Mailinglisten abmelden


Vorbedingungen


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


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


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


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


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,

[email protected]

INFO: 2011-08-16 01:08:57 (User: m): Deleted Engagement:

Mitglied, 01.08.2011-31.08.2011 (SFr. 20.00) of Person: Ukel Urs,

[email protected]

6.3.2.5 FA-M5-T3 Logfile Engagement

Wenn ein Engagement gelöscht wird, soll dies im Logfile festgehalten werden.

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


Mitglied, 01.08.2011-31.08.2011 (SFr. 20.00) of Person: Ukel Urs,

[email protected]

6.3.3 Newsletter

6.3.3.1 FA-N1-T1, Newsletter kann nur einmal gesendet werden

Vorbedingungen Es existiert ein Newsletter der bereits versendet wurde („Gesendet Am“ Feld

enthält einen Wert)

Instruktionen -

Erwartetes Resultat „Senden“ Knopf ist deaktiviert

6.3.3.2 FA-N3-T1, Abmelden Mailinglisten

Vorbedingungen Eine E-Mail Adresse ist auf diversen Mailinglisten eingetragen

Instruktionen Via Selfcare View Abmeldung von allen Mailinglisten beantragen

Erwartetes Resultat E-Mail Adresse ist aus allen Mailinglisten entfernt, Bestätigungsmail wurde

versendet

6.3.4 Benutzerverwaltung

6.3.4.1 FA-B2-T1 Login

Vorbedingungen Benutzer ist abgemeldet

Instruktionen Korrekten Benutzername und Passwort eingeben

„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


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


6.3.5 Internationalisierung und Lokalisation

6.3.5.1 FA-ME1-T1, Sprache umstellen via GUI


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



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


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



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



Im Dialog die neue Sprache „German“ (oder „Deutsch“) wählen

Bestätigen

http://vemico-guild42-dev.appspot.com/?lang=en

http://vemico-guild42-dev.appspot.com/?RegisterForEvent&lang=en


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


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..*


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


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


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/


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/


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


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/


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.


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


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.


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


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..*


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..*


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..*


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


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.


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.


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


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


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).


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


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


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.

http://localhost:7777/?FullScreenSampleView


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/


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..*


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


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


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

http://java.sun.com/


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.


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


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


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


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


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.


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.


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





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/

https://appengine.google.com/

http://vemico.vemico-guild42.appspot.com/


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

http://www.python.org/download/releases/2.7.2/

http://code.google.com/intl/de-DE/appengine/downloads.html

http://code.google.com/intl/de-DE/appengine/downloads.html

https://appengine.google.com/


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/


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/


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.

http://guild42.ch/vemico/BenutzerhandbuchVemico.pdf


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


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


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/

http://www.microsoft.com/



http://www.eclipse.org/downloads/

http://code.google.com/intl/de-DE/eclipse/

http://vaadin.com/eclipse

http://www.datanucleus.org/downloads/eclipse-update

http://www.eclipse.org/subversive/downloads.php

http://sourceforge.net/projects/datanucleus/files/

http://vaadin.com/download

http://code.google.com/intl/de-DE/webtoolkit/


http://vaadin.com/directory#addon/confirmdialog

http://www.mysql.com/downloads/mysql/5.5.html#downloads

http://www.mysql.com/downloads/mysql/5.5.html#downloads

http://www.mysql.de/products/workbench/


http://www.junit.org/

http://easymock.org/

http://ant.apache.org/

http://www.sparxsystems.com/




http://balsamiq.com/products/mockups

http://subversion.tigris.org/

http://www.ganttproject.biz/


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»


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.

http://code.google.com/p/instant-webapp/source/checkout


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.


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.


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“.


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


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


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


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


A. Planung

Abbildung 42 Planung


B. Generiertes DB Model Das Bild wurde mit dem Tool „MySQL Workbench“ generiert.

Abbildung 43 Generiertes MySQL DB Modell


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.

Documents

Vereinsmitgliederverwaltung mit Computerstatic.sws.bfh.ch/download/MT-11-01-04-doc.pdf · JDO Java Data Objects, ein ORM Standard JPA Java Persistence API, ein ORM Standard MVC Model