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