We acknowledge that this document uses material from the arc 42 architecture

template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot

Starke. For additional contributors see arc42.de/about/contributors.html

Floorball Eventer

Design Dokument

FloorballEventer

2

1 Dokument ................................................................................................................... 4

1.1 Versionen .............................................................................................................. 4

1.2 Referenzdokumente .............................................................................................. 4

1.3 Definitionen, Akronyme, Glossar ........................................................................... 4

2 Ziel und Zweck dieses Dokuments........................................................................... 5

3 Einführung und Ziele ................................................................................................. 6

3.1 Aufgabenstellung .................................................................................................. 6

3.1.1 Kernaufgabe ................................................................................................... 6

3.1.2 Art des Systems .............................................................................................. 6

3.1.3 Nutzung .......................................................................................................... 6

3.1.4 Schnittstellen ................................................................................................... 6

3.1.5 Datenhaltung ................................................................................................... 6

3.1.6 Steuerung ....................................................................................................... 6

3.1.7 Use Cases ...................................................................................................... 7

3.2 Qualitätsziele ........................................................................................................ 9

3.3 Stakeholder ........................................................................................................... 9

4 Randbedingungen ..................................................................................................... 9

4.1 Technische Rahmenbedingungen ......................................................................... 9

5 Kontextabgrenzung ................................................................................................. 10

5.1 Fachlicher Kontext ...............................................................................................10

5.1.1 Spielbegleiter .................................................................................................10

5.1.2 Zuschauer ......................................................................................................10

5.1.3 SwUni ............................................................................................................10

5.2 Technischer- oder Verteilungskontext ..................................................................11

6 Lösungsstrategie..................................................................................................... 12

7 Bausteinansicht ....................................................................................................... 13

7.1 Ebene 1 ...............................................................................................................13

7.1.1 Basismodul ....................................................................................................13

7.1.2 Audiencemodul ..............................................................................................13

7.2 Ebene 2 ...............................................................................................................14

7.2.1 Datenverwaltung ............................................................................................14

7.2.2 Spielbegleitung ..............................................................................................14

7.2.3 Persistenz ......................................................................................................15

7.2.4 Server ............................................................................................................15

7.2.5 SwUniRestClient ............................................................................................15

7.2.6 FEAudience ...................................................................................................15

7.3 Ebene 3 ...............................................................................................................16

7.3.1 Datenverwaltung (FEModData) ......................................................................16

7.3.2 Spielbegleitung (FEModGame) ......................................................................18

7.3.3 Server (FEModServer) ...................................................................................19

FloorballEventer

3

7.3.4 Audience (FEAudience) .................................................................................20

7.3.5 SwUniRestClient ............................................................................................21

8 Laufzeitansicht ........................................................................................................ 22

8.1 FEBase ................................................................................................................22

8.1.1 Shell ...............................................................................................................22

8.1.2 Bootstrapper ..................................................................................................23

8.2 Client-Server-Kommunikation ..............................................................................24

9 Implementationsdetails ........................................................................................... 26

9.1 Auffinden von Modulen ........................................................................................26

9.2 Aufbau eines Moduls............................................................................................26

9.2.1 NavigationController .......................................................................................26

9.2.2 Navigationsknoten..........................................................................................27

9.2.3 Initialisierung der Views .................................................................................28

9.3 MVVM Toolkit.......................................................................................................29

9.3.1 CViewModelBase ...........................................................................................29

9.3.2 CRelayCommand ...........................................................................................30

9.4 Speichern von Einstellungen ................................................................................30

9.5 Strafenmanagement ............................................................................................32

9.6 Messageboxen.....................................................................................................33

9.7 Styling ..................................................................................................................33

10 Typische Muster, Strukturen und Abläufe ............................................................. 34

10.1 PRISM .................................................................................................................34

10.1.1 Composition Approach .................................................................................34

10.1.2 Typische Architektur mit der Hilfe der PRISM Library ...................................34

10.1.3 Event Aggregator .........................................................................................35

10.2 MEF .....................................................................................................................35

10.3 MVVM ..................................................................................................................36

10.4 WCF ....................................................................................................................36

11 Technische Konzepte .............................................................................................. 38

11.1 Persistenz ............................................................................................................38

11.2 Benutzeroberfläche ..............................................................................................39

11.3 Verteilung .............................................................................................................39

11.4 Ausnahme-/Fehlerbehandling ..............................................................................39

11.5 Logging ................................................................................................................40

11.6 Internationalisierung .............................................................................................40

11.7 Testbarkeit ...........................................................................................................40

11.8 Unit of Work .........................................................................................................40

11.9 Repository Pattern ...............................................................................................42

FloorballEventer

4

1 Dokument

1.1 Versionen Ausgabe Version Änderungsinformation Autor 30.06.2013 0.1 Entwurf Vorlage SSC

15.09.2013 0.2 Ergänzungen SSC

21.09.2013 0.3 Ergänzungen DKE

21.09.2013 0.4 Ergänzungen SSC

26.09.2013 0.5 Kleine Korrekturen SSC

1.2 Referenzdokumente Referenz Titel / Name Autor [1] Voranalyse\SRS_Floorball Eventer Gruppe 3

[2] Konzept\FE_Glossar Gruppe 3

[3] Konzept\FE_Testkonzept Gruppe 3

[4] Konzeot\FE_Entwurf_GUI Gruppe 3

1.3 Definitionen, Akronyme, Glossar Definitionen sind dem Glossar [2] zu entnehmen.

FloorballEventer

5

2 Ziel und Zweck dieses Dokuments Dieses Dokument beschreibt die Architektur der Software-Lösung „Floorball Eventer“ (FE).

In der Einleitung werden einige Passagen gemäss SRS wiedergegeben, danach wird jeweils nur noch

auf die SRS referenziert. Für die Gliederung wurde das Template von www.arc42.com verwendet.

Die verwendeten Frameworks werden meist nur oberflächlich beschrieben. Jedoch sind jeweils Quel-

len vorhanden, unter welchen jeweils detaillierte Informationen zu finden sind.

Ein Teil der Lösungsansätze zum Bau von modularen Komponenten wurde von

http://www.codeproject.com/Articles/254120/PRISM-4-MEF-Application übernommen.

FloorballEventer

6

3 Einführung und Ziele In Unihockeyspielen vom Schweizer Verband übernehmen zusätzlich zum Schiedsrichter zwei bis vier

Personen als Spielbegleiter diverse Aufgaben während einer Unihockey-Partie. Dies sind: Zwischen-

resultate aufnehmen, Torschützen vermerken, Spielzeit starten und stoppen, Zeitstrafen vollziehen,

Matchrapport ausfüllen und viele mehr. Dazu haben diese Spielbegleiter meist mehrere Stoppuhren

und diverse Formulare oder Notizzettel zur Verfügung. Nach dem Spiel muss noch ein Rapport ausge-

füllt und an den Verband übermittelt werden.

Diese Art von Spielbegleitung kann in Anbetracht der heutigen technischen Möglichkeiten als veral-

tet, kompliziert und ineffizient bewertet werden. Aus dem Umfeld vieler Vereine ist deutlich zu ver-

nehmen, dass sie eine neue, automatisierte Lösung für die Unterstützung der Spielbegleiter bei der

Erledigung ihrer Aufgaben bevorzugen würden.

Ziel des Projekts ist die Entwicklung einer Softwarelösung, welche diese bisher etablierte, aber mehr

oder weniger ineffiziente Zettelwirtschaft erübrigt und somit den administrativen sowie den perso-

nellen Aufwand vereinfacht. Zusätzlich soll durch diese Softwarelösung die Attraktivität des Spiels für

die Zuschauer sowie den Veranstalter anhand live aufbereiteter Informationen, eingespielter Präsen-

tationen und Werbung sowie nachträglichem Spielbericht zusätzlich gesteigert werden.

3.1 Aufgabenstellung

3.1.1 Kernaufgabe FE ist eine Software, welche es ermöglich soll, Unihockeyspiele der Swissunihockey Liga zu begleiten.

3.1.2 Art des Systems Verteilte Windows Desktop Applikation in einem lokalen Netzwerk

3.1.3 Nutzung Spielbegleiter (Spiele, Spieler und Teams verwalten und Spiele begleiten)

3.1.4 Schnittstellen Informationsserver von SwUni (Webservice)

3.1.5 Datenhaltung Microsoft SQL Express Datenbank

3.1.6 Steuerung Ereignisgesteuert durch Benutzerinteraktionen.

FloorballEventer

7

3.1.7 Use Cases Folgend sind nur die primären Use Cases aufgelistet. Die sekundären Use Cases sind dem Use Case

Diagramm der SRS [1] zu entnehmen.

ID Use Case Actor Beschreibung UC001 Spiele verwalten Spielbegleiter Der Spielbegleiter kann Spiele importieren, löschen, edi-

tieren und neu erstellen.

UC002 Spieler verwalten Spielbegleiter Der Spielbegleiter kann Spieler importieren, löschen, edi-tieren und neu erstellen

UC003 Mannschaften verwal-ten

Spielbegleiter Der Spielbegleiter kann Mannschaften importieren, lö-schen, editieren und neu erstellen

UC004 Spiele begleiten Spielbegleiter Der Spielbegleiter kann mit Hilfe des FE Spiele begleiten (Strafen und Torschützen erfassen, Zeitmessung,…)

FloorballEventer

8

Abbildung 1 Use Case Diagramm Floorball Eventer

FloorballEventer

9

3.1.8 Fachklassen Fachklassendiagramm und -beschreibungen sind der SRS [1] Kapitel 3.3.1.1 zu entnehmen.

3.2 Qualitätsziele Die nichtfunktionalen Anforderungen sind der SRS [1] Kapitel 3.4 zu entnehmen.

3.3 Stakeholder Die Stakeholder sind der SRS [1] Kapitel 1.6 zu entnehmen.

4 Randbedingungen

4.1 Technische Rahmenbedingungen Hardware

Minimalanforderungen an die PCs, auf denen Module des FE ausgeführt werden sollen: Prozessor mit 1 GHz und SSE2-Untertützung, 2 GB RAM, 3 GB freier Festplattenspeicher, Bildschirmauflösung mindestens 1366 x 786.

Software

- Microsoft Windows 7 (32 Bit oder 64 Bit) - Microsoft .NET Framework 4.5 - Microsoft SQL Express (Version > 2008)

FloorballEventer

10

5 Kontextabgrenzung

Die folgenden beiden Unterkapitel zeigen die Einbettung des FE in seine Umgebung. Dabei wird zwi-

schen dem fachlichen Kontext und dem technischen Kontext unterschieden. Zweck dieser Kapitel ist

es, das zu entwickelnde System von allen seinen Nachbarsystemen abzugrenzen.

5.1 Fachlicher Kontext

Die folgende Darstellung zeigt das Nachbarsystem vom FE.

Abbildung 2 FE im fachlichen Kontext mit Nachbarsystem

5.1.1 Spielbegleiter Der Spielbegleiter ist für die Vorbereitung und Spielbegleitung verantwortlich.

5.1.2 Zuschauer Die Zuschauer werden über eine Anzeige über den aktuellen Spielstand informiert. Sie sind passiv

und können keinen Einfluss auf die Anzeige nehmen.

5.1.3 SwUni REST Webservice von SwUni, von welchem die benötigten Spiel-, Mannschafts- und Spielerdaten

abgefragt werden können.

FloorballEventer

11

5.2 Technischer- oder Verteilungskontext Das folgende Diagramm zeigt die Verteilung der einzelnen Bestandteile des Floorball Eventers. Wie

zu sehen ist, können beliebig viele Audience-Modul-Instanzen gleichzeitig an das Basismodul ange-

bunden werden. Die Instanzen können sowohl auf dem gleichen PC wie die Komponente FEBase

liegen aber auch auf einem anderen PC im selben Netzwerk.

Abbildung 3 Verteilungsdiagramm des FE Systems

FloorballEventer

12

6 Lösungsstrategie Gemäss SRS soll FE als modulares System entwickelt werden, welches zu einem späteren Zeitpunkt

möglichst einfach um Zusatzmodule erweitert werden kann. Weiter wäre es optimal dass die einzel-

nen Komponenten parallel weiterentwickelt werden können.

Wegen der kurzen Projektdauer bleibt wenig Zeit für eine Einarbeitung in völlig neue Themen. Aus

diesem Grund hat das Team entschieden, auf bekannte Technologien zurückzugreifen.

Das Projektteam besteht aus C#.NET Entwicklern, wodurch die Programmiersprache gegeben ist. Des

Weiteren besteht bei der Entwicklung verteilter und modularer Applikation Erfahrung mit den

Frameworks PRISM, MEF, WCF und WPF. Die bestehenden Kenntnisse sollen ins Projekt einfliessen,

in dem die genannten Frameworks genutzt werden. Daher wird auf die Evaluation weiterer alterna-

tiver Frameworks verzichtet.

FloorballEventer

13

7 Bausteinansicht Dieses Kapitel zeigt den Aufbau des FE. In diesem Kapitel werden dabei nur die grundlegenden Pake-

te beschreiben.

7.1 Ebene 1 Die Bausteine auf der ersten Ebene sind die in der SRS beschriebenen Module, von denen im Proto-

typ das Basismodul und das Audience-Modul entwickelt werden. Vorgesehen ist, das System in Fol-

geprojekten auf dieser Ebene um weitere Module zu erweitern.

Abbildung 4 Bausteine auf der ersten Ebene

7.1.1 Basismodul Zweck / Verantwortlichkeit

Hauptmodul für Datenverwaltung und Spielbegleitung.

Schnittstelle FE System intern

Beinhaltet eine Serverkomponente („FE Server“), über welche weitere FE-Module wie z.B. das Audiencemodul als Client Daten beziehen können.

Schnittstellen externe Systeme

Benutzt den REST Webservice von SwUni (Siehe Beschrei-ung nächster Ebene)

Erfüllte Anforderungen

Abdeckung Anforderungen der SRS [1] Kapitel 3.3.1

7.1.2 Audiencemodul Zweck / Verantwortlichkeit

Spieldatenanzeige für Zuschauer

Schnittstelle FE System intern

Nutzt den FE Server des Basismoduls

Erfüllte Anforderungen

Abdeckung Anforderungen der SRS [1] Kapitel 3.3.3

FloorballEventer

14

7.2 Ebene 2 Die Darstellung der Bausteine der zweiten Ebene zeigt die Hauptbausteine der einzelnen Module.

Abbildung 5 Bausteine der zweiten Ebene

7.2.1 Datenverwaltung Zweck / Verantwortlichkeit

Hauptmodul für die Datenverwaltung (Importieren, editie-ren, löschen und modifizieren von Spieler, Mannschaften und Spielen)

Schnittstelle Zugriff auf Persistenz Modul

Erfüllte Anforderungen

Abdeckung Anforderungen der SRS [1] Kapitel 3.3.1

7.2.2 Spielbegleitung Zweck / Verantwortlichkeit

Modul zum Begleiten von Spielen (u.a. Zeitmessung, Stra-fen und Tore verwalten)

Schnittstelle Zugriff auf Persistenz Modul

Erfüllte Anforderungen

Abdeckung Anforderungen der SRS [1] Kapitel 3.3.2

FloorballEventer

15

7.2.3 Persistenz Zweck / Verantwortlichkeit

Ist für den Zugriff auf die Datenbank verantwortlich.

Erfüllte Anforderungen

Alle Daten benötigten Daten werden jeweils von SwUni in die lokale DB importiert, damit nicht eine ständige Inter-netverbindung nötig ist.

7.2.4 Server Zweck / Verantwortlichkeit

Stellt Informationen über das Spiel, für welches die Spiel-begleitung läuft, für andere Module zur Verfügung.

Schnittstelle Serverteil, welcher vom Audience Modul verwendet wird.

Erfüllte Anforderungen

Wird verwendet, damit das Audience Modul auf die aktuel-len Spieldaten zugreifen kann. Die Spezifikation sieht nicht explizit eine Serverkomponen-te vor. Diese ergibt sich aber aus den getroffenen Architek-turentscheidungen.

7.2.5 SwUniRestClient Zweck / Verantwortlichkeit

Ist für den Zugriff auf den SwUni REST Webservice zustän-dig.

Erfüllte Anforderungen

Abdeckung Anforderung: - AF-3.3.1.2.1-2 (Spieler importieren) - AF-3.3.1.2.2-2 (Spiel importieren) - AF-3.3.1.2.3-2 (Mannschaft importieren)

7.2.6 FEAudience Zweck / Verantwortlichkeit

Ist für Anzeige des Spiels für welches aktuell die Spielbe-gleitung läuft zuständig.

Schnittstellen Greift auf das Servermodul zu.

Erfüllte Anforderungen

Abdeckung Anforderungen der SRS [1] Kapitel 3.3.3

FloorballEventer

16

7.3 Ebene 3

7.3.1 Datenverwaltung (FEModData)

Abbildung 6 Hauptklassen der Datenverwaltung

Dieses Modul ist für die Verwaltung der Spiel, Spieler und Teamdaten verantwortlich. Es beinhaltet

verschiedene Views, mit welchen Daten erfasst, gelöscht, modifiziert oder von SwUni importiert

werden können.

FloorballEventer

17

Im Sinne einer einheitlichen Bedienbarkeit gibt es für alle Datentypen einen einheitlichen Satz von

spezialisierten Views. Es gibt für Spieler, Spiele und Teams immer:

1. View mit Übersicht

2. View zum Editieren und Erstellen

3. View zum Importieren

In der CNavigationView wird für jedes Übersichtsview ein Navigationsknoten erstellt. Die Daten dazu

werden vom CNavigationController geholt, welche Referenzen von allen Übersichtsview verwaltet.

Folgende zusätzliche Anhängigkeiten im UML Diagramm wegen der Übersichtlichkeit weggelassen:

- Die ViewModels haben jeweils noch Referenzen die Module für den Datenbankzugriff.

- Zusätzlich haben die ImportViews jeweils noch Referenzen auf das SwUniRestClient Modul,

über welchen die die Daten vom SwUni heruntergeladen werden.

- Für die Konvertierung der Daten von SwUni in die Datenbank des FE existiert eine Konverter-

klasse.

FloorballEventer

18

7.3.2 Spielbegleitung (FEModGame)

Abbildung 7 Hauptklassen im Spielbegleiter-Baustein

Der Baustein „Spielbegleitung“ ist der Teil des FE-Basismoduls, welcher dem Spielbegleiter die Beglei-

tung eines Unihockeyspiels ermöglicht. Wesentliche Funktionen sind

- Das Auswählen des zu begleitenden Spiels

- Das Starten, Stoppen, Verändern der Spieluhr

- Das Erfassen, Ändern, Löschen von Toren

- Das Erfassen, Ändern und Löschen von Strafen

- Die regelgerechte Steuerung der Spieluhr

- Das automatische, regelgerechte Ablaufen von Strafen

Die Hauptview der Spielbegleitung ist die CMatchControllerView, gesteuert vom CMatchCon-

trollerViewModel. Darin werden die Aktionen implementiert, die für das gesamte Spiel gelten,

z.B. die Spieluhr.

Unterhalb der CMatchControllerView gibt es für das Heimteam und das Gastteam je ein

CMatchTeamControllerView mit eigenem ViewModel. Darin werden die Details implementiert,

die für beide Teams getrennt voneinander verwaltet werden müssen, z.B. die Tor- und Strafenlisten.

Die Geschäftslogik für den regelgerechten Ablauf von Spieluhr und Strafen übernehmen die Klassen

CFEGameManager respektive CFEPenaltyManager..

FloorballEventer

19

7.3.3 Server (FEModServer)

Abbildung 8 Hauptklassen im Server-Baustein

Der Baustein „Server“ stellt die Funktionalität bereit, welche zur Kommunikation zwischen dem Ba-

sismodul und den Erweiterungsmodulen von FE notwendig ist. Im Prototypen wird dadurch also die

Kommunikation zwischen Basismodul und Audience-Modul geregelt.

Der Server ist über den Event-Aggregator-Mechanismus mit den restlichen Bausteinen des Basismo-

duls verbunden. Dadurch wird der Server über Ereignisse informiert, die zu den angeschlossenen

Clients kommuniziert werden sollen, beziehungsweise kann er dadurch Datenanforderungen der

Clients an die entsprechenden Stellen im Basismodul weiterleiten.

FE nutzt das Framework WCF für die Client-Server-Kommunikation. In der Baustein-Hauptklasse

CFEServerModule ist der WCF-Server-Host implementiert, der in der Hauptsache für das Entge-

gennehmen von Verbindungsanforderungen zuständig ist. Der CFEServerController verwaltet

die bestehenden Client-Verbindungen in Form von Session-Objekten und leitet Callback-Aufrufe an

die Clients weiter. CFEServerImpl implementiert den Dienstvertrag (Contract).

FloorballEventer

20

7.3.4 Audience (FEAudience)

Abbildung 9 Hauptklassen im Baustein FEAudience

Der Baustein FEAudience dient zur Anzeige der Spielinformationen für Zuschauer und Spieler. Sie

besteht aus einer Hauptview (CAudienceView), darin eingebettet eine View für die Zeit- und Resul-

tatanzeige sowie je eine View für die Strafen- und Torlisten für Heim- und Gastmannschaft.

Im ViewModel (CAudienceViewModel) für die Klasse CAudiencView wird zudem im Konstruktor eine

Instanz des Serverproxy erzeugt. Über Callbacks kann dann der Server jeweils die aktuellen Spielda-

ten zum Audience Modul senden. Details mit einem Sequenzdiagramm sind dazu im Kapitel 8.2 zu

finden.

FloorballEventer

21

7.3.5 SwUniRestClient

Abbildung 10 Client für den REST Webservice von Swiss Unihockey

Dieses Modul ist für den Zugriff auf den SwUni REST-Service zuständig. Die Endpoints sind auf

http://api.swissunihockey.ch/ detailliert beschrieben

7.3.5.1 Abfragebeispiel

Die Abfragen sind alle gleich aufgebaut. Die Daten werden mit Hilfe eines WebRequest auf den ent-

sprechenden RESTEndpoint abgerufen. Die XML-Antwort des REST-Services wird in Objekte deseriali-

siert.

Abbildung 11 Ablauf einer Datenabfrage bei Swiss Unihockey

Für die Deserialisierung müssen die Klassen entsprechend attribuiert werden. Die Grundlagen dazu

sind unter folgendem Link gut beschrieben:

http://www.codeproject.com/Articles/483055/XML-Serialization-and-Deserialization-Part-1

FloorballEventer

22

8 Laufzeitansicht Alle zuvor beschrieben Bausteine (ausser das Audience Modul) benötigen noch einen Rahmen in

welchem Sie gestartet werden können. Dazu wird der Baustein FEBase erstellt, welche im nächsten

Kapitel beschreiben ist.

Das Audience Modul ist für sich allein startbar und versucht automatisch, sich mit dem Server zu

verbinden.

8.1 FEBase Alle Module werden von einer gemeinsamen Basis automatisch gefunden (im Bootstrapper) und in

einem einheitlichen visuellen Rahmen (der Shell) dargestellt werden können. Dies ist mit Hilfe von

PRISM und MEF realisiert.

8.1.1 Shell Die Shell definiert das Layout der Applikation auf dem höchsten Level. Details dazu sind unter

(http://msdn.microsoft.com/en-us/library/ff921075%28v=pandp.20%29.aspx ) zu finden. Für den FE

werden nur folgende beiden Regionen definiert:

Navigation Workspace

Abbildung 12 Aufteilung der Shell von FEBase in Regionen

Region Beschreibung

Navigation In diesem Bereich kann jedes Modul seinen Navigationsbaum hinzufügen.

Workpace In diesem Bereich kann jedes Modul seine Views anzeigen. Es ist jeweils immer nur eine View zur selben Zeit sichtbar.

FloorballEventer

23

8.1.2 Bootstrapper Der Bootstrapper ist für das Laden aller benötigten Komponenten verantwortlich. Dazu wird dieser

im Startup des FEBase gestartet.

Vor dem Starten des Bootstrapper wird noch eine Instanz des Loggers geholt, damit Fehler bei der

während dem Startup geloggt werden können.

Abbildung 13 Ablauf des Applikationsstarts mit Bootstrapper

Der Integrierte Bootstrapper sucht beim Starten alle Module, welche im „Modules“-Verzeichnis ne-

ben dem FEBase.exe liegen. Die einzelnen Module stellen dann jeweils ihre eigene Navigation für die

NavigationRegion und die damit verbundenen Views für den WorkspaceRegion zur Verfügung. Damit

die einzelnen Module gefunden werden müssen diese gewisse Anforderungen erfüllen, welche im

Kapitel 9 beschrieben sind.

Abbildung 14 Detaillierter Bootstrapper-Ablauf

FloorballEventer

24

8.2 Client-Server-Kommunikation Folgendes Sequenzdiagramm veranschaulicht beispielhaft die Initialisierung des FE Servers und die

Kommunikation mit dem FE Audience Modul.

Abbildung 15 Ablauf der Client Server Kommunikation

FloorballEventer

25

Zuerst wird beim Starten des FEBase der Server Host und der Server Controller erzeugt. (Ablauf 1)

Dann startet eine FEAudience-Instanz und meldet sich am Server an. Dabei wird ein ServerProxy er-

zeugt, über den später die gesamte Kommunikation zum Server läuft. (Ablauf 2)

Schliesslich erhält der Server über den EventAggregator die Meldung, dass in der Spielbegleitung ein

Spiel ausgewählt wurde. Der Server ermittelt die dazugehörigen Daten und überträgt sie als Callback-

Aufruf zu jedem angemeldeten Client (Ablauf 3).

FloorballEventer

26

9 Implementationsdetails

9.1 Auffinden von Modulen Damit ein Modul gefunden wird, muss es mit dem ModuleExport Attribute gekennzeichnet werden.

Diese Module werden dann vom PRISM automatisch gefunden.

Beispiel, Attribuierung des Datenverwaltungsmoduls FEData:

[ModuleExport(typeof(CFEDataModule))] public class CFEDataModule : IModule { public void Initialize() { var eventAggregator = ServiceLocator.Current.GetInstance<IEventAggregator>(); eventAggregator.GetEvent<CModuleLoadedEvent>().Publish((CModulLoadedEventItem)new CModulLoadedEventItem() { AssemblyName = Assembly.GetExecutingAssembly().FullName }); } }

Jedes Modul kann dann der Shell eigene Views für die Navigations- und Workspaceregionen zur Ver-

fügung stellen.

Wichtig ist dass die Module in das Verzeichnis mit der Bezeichnung „Modules“ welches neben FEBas-

e.exe liegt, gebuildet werden. Dies ist nur eine der Möglichkeiten zum Laden von Module.

9.2 Aufbau eines Moduls Jedes Modul, welches Views zur Verfügung stellen will, muss folgende Elemente aufweisen.

Abbildung 16 Notwendige Klassen für jedes Modul in FEBase

Klasse Beschreibung

NavigationView View, welche in der NavigationRegion angezeigt werden soll.

NavgationViewModel ViewModel für die NavigationView. Beinhaltet eine Instanz vom NavigationController sowie ViewObjects, welche vom Navigati-onController stammen.

9.2.1 NavigationController Der NavigationController kennt alle ViewObjects und Verknüpf diese mit den Navigation Knoten.

Dazu wird jedem Navigationknoten ein DelegateCommand angehängt. Durch ein Klick auf einen Na-

vigationsknoten wird dann die verknüpfte View in der Workspace Region angezeigt.

FloorballEventer

27

Die Klasse CViewObject hilft beim Verbinden der View mit der Navigation.

Property Beschreibung

Titel Hauptnavigationsknoten

Section Subnavigationsknoten

View View welche dargestellt werden soll, falls auf den Navigationsknoten geklickt wird.

9.2.2 Navigationsknoten Jedes Modul kann der Shell seinen eigenen Navigationsknoten hinzufügen. Damit die Navigation

gefunden wird, muss diese jedoch mit Hilfe des Attributs CViewExportAttribute exportiert wer-

den.

FloorballEventer

28

9.2.3 Initialisierung der Views Jedes Modul kann seine Views in die Shell laden, wobei alle vorhandenen Views automatisch bei der

Initialisierung gefunden werden sollen. Dazu gibt es mehrere Varianten wie ViewInjection oder

auch ViewDiscovery. Details zu diesen Methoden sind http://msdn.microsoft.com/en-

us/library/ff921075%28v=pandp.20%29.aspx zu entnehmen. Im FE wird ein erweitertes ViewDis-

covery verwendet.

Damit die Views, die ein Modul zur Verfügung stellt, automatisch vom Framework erkannt und ein-

gebunden werden, müssen die Views durch ein einheitliches Attribut ausgezeichnet werden. Dazu

wird das CViewExportAttribute implementiert.

Für das erweiterte ViewDiscovery muss dann noch im Bootstrapper ein RegionBehavior für alle

Regionen hinzugefügt werden. Dies kann wie folgt geschehen:

/// <summary> /// Configures the <see cref="T:Microsoft.Practices.PRISM.Regions.IRegionBehaviorFactory" />. /// This will be the list of default behaviors that will be added to a region. /// </summary> /// <returns></returns> protected override IRegionBehaviorFactory ConfigureDefaultRegionBehaviors() { IRegionBehaviorFactory factory = base.ConfigureDefaultRegionBehaviors(); factory.AddIfMissing("CAutoPopulateExportedViewsBehavior", typeof (CAutoPopulateExportedViewsBehavior)); return factory; }

Das Behaviour wird dann vom PRISM-Framework dann automatisch instanziiert. Als erstes impor-

tiert es über MEF alle Views, welche das Interface IViewRegionRegistration implementieren. Ist

der Import erfolgreich abgeschlossen, wird über alle Views iteriert. Bei jeder View wird über das

CViewExportAttribute ermittelt für welche Region die View verwendet werden soll. Ist die Regi-

on vorhanden wird sie dieser Region hinzugefügt.

FloorballEventer

29

9.3 MVVM Toolkit Es gibt diverse Klassen und Interfaces, welche im Zusammenhang mit MVVM häufig verwendet wer-

den. Damit diese nicht in jedem Modul neu programmiert werden müssen, sind sie in einem eigenen

Modul MVVMToolkit ausgelagert.

In diesem Kapitel werden nur die wichtigsten Klassen beschrieben.

9.3.1 CViewModelBase

Diese Klasse soll als Basisklasse für alle ViewModels verwendet werden. Sie implementiert das Inter-

face INotifyPropertyChanged, welches es dem ViewModel erlaubt, Änderungen der Werte an

die View zu notifizieren. Datengebundene Controls updaten sich somit automatisch. Das Interface

gibt lediglich das Event PropertyChanged vor. Diese soll ausgelöst werden, sobald sich ein Proper-

ty-Wert verändert hat. Im Setter des Properties muss dann nur das Event ausgelöst werden.

/// <summary> /// Gets or sets the selected team. /// </summary> /// <value> /// The selected team. /// </value> public CMannschaftViewModel SelectedTeam { get { if (_selectedTeam == null) { _selectedTeam = new CMannschaftViewModel(); } return _selectedTeam; } set { if (_selectedTeam != value) { _selectedTeam = value; OnPropertyChanged(); } } }

FloorballEventer

30

Durch die Verwendung des .NET Frameworks 4.5 kann in der Basisklasse das Attribute CallerMem-

berName verwendet werden, wodurch automatisch erkannt wird, welches Property das Event auf-

gerufen hat.

/// <summary> /// Raises this object's PropertyChanged event. /// </summary> /// <param name="propertyName">The property that has a new value.</param> public void OnPropertyChanged([CallerMemberName] string property = null) { if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(property)); }

9.3.2 CRelayCommand Diese Klasse wird in WPF-Applikationen oft verwendet. Ursprünglich stammt die Idee von :

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

CRelayCommand implementiert das Interface ICommand und ermöglicht es, die Logik des Befehls

über Delegaten zu injizieren, die an seinen Konstruktor übergeben werden. Dieser Ansatz ermöglicht

eine knappe, präzise Befehlsimplementierung in ViewModel-Klassen.

9.4 Speichern von Einstellungen Zum Speichern von Einstellungen wird Westwind.Utilies.Configuration verwendet. Details

dazu sind unter http://www.nuget.org/packages/Westwind.Utilities.Configuration beschrieben.

Um diesen zu verwenden muss von der Klasse AppConfiguration abgeleitet werden. Danach kön-

nen die eigenen Properties, welche abgespeichert werden sollen, ergänzt werden.

FloorballEventer

31

Das Lesen einer Einstellung funktioniert wie folgt:

Abbildung 17 Ablauf des Lesens der Einstellungen als Sequenzdiagramm

Anwendungsbeispiel:

/// <summary> /// Gets or sets the API key. /// </summary> /// <value> /// The API key. /// </value> public string ApiKey { get { CFEConfigurationManager.Settings.Read(); return CFEConfigurationManager.Settings.SwUniRESTApiKey; } set { if (CFEConfigurationManager.Settings.SwUniRESTApiKey != value) { CFEConfigurationManager.Settings.SwUniRESTApiKey = value; CFEConfigurationManager.Settings.Write(); } } }

FloorballEventer

32

9.5 Strafenmanagement Das schweizerischer Unihockey-Regelwerk gibt einen komplexen Ablauf der Strafenverwaltung vor.

Abbildung 18 Ablauf der Strafenverwaltung

FloorballEventer

33

9.6 Messageboxen Damit nicht jedes Modul seine eigenen MessageBoxen implementieren muss, wird die Klasse Appli-

cationController erstellt, über welche MessageBoxen, Notifications und auch PasswortBoxen ange-

fordert werden können.

Zusammen mit den Informationen, welche in der entsprechenden Messagebox angeben werden soll,

kann zusätzlich noch ein Delegate angeben werden, welches beim Schliessen der MessageBox aufge-

rufen wird.

Anwendungsbeispiel MessageBox:

CApplicationController.Current.MessageBoxRequest(new MessageBoxRequest() { Button = MessageBoxRequestButton.OK, Message = "Swissunihockey Server Fehler", Title = "Fehler" }, null); // Delegate ist null, da nach dem Bestätigen der Messagebox nichts ausgeführt werden muss.

Anwendungsbeispiel NotificationMessage:

CApplicationController.Current.Implementation.NotificationMessage("Import abgeschlossen");

9.7 Styling Das ganze Styling wird in den Resourcen Infrastruktur zentral gelagert. Alle Module sollen ihre Style

über von diesen Resourcen beziehen. Dies hat den Vorteil, dass der Style der Applikation zu einem

späteren Zeitpunkt zentral geschehen kann und nicht alle Module angepasst werden müssen. Fol-

gende Lösung wird implementiert: http://www.codeproject.com/Tips/542018/Simply-Using-WPF-

Styles-in-Other-Assemblies-or-Oth

FloorballEventer

34

10 Typische Muster, Strukturen und Abläufe

10.1 PRISM PRISM ist die Kurzbezeichnung für die „Composite Application Guidance for WPF and Silverlight“.

PRISM unterstützt die Anwender beim Bau von Applikationen mit Windows Präsentation Foundation

(WPF) Desktop Applikationen, Silverlight Rich Internet Applications (RIAs), und Windows Phone Ap-

plikationen. Hauptfokus hat dabei ein einfacheres Design, die Flexibilität und eine einfachere Wart-

barkeit der Applikation. PRISM unterstützt den Aufbau von lose gekoppelten Komponenten, welche

voneinander unabhängig entwickelt werden. Eine einfache Integration dieser Komponenten in die

Hauptapplikation ist einfach möglich.

10.1.1 Composition Approach Nach dem „Composite Approach“ entwickelte Applikationen haben u.a. folgende Vorteile:

- Einzelne Module können voneinander unabhängig zu entwickelt und getestet werden.

- Die einzelnen Module können dadurch von unterschiedlichen Entwickler / Teams entwickelt

werden.

- Es ist einfach möglich zusätzliche Funktionen in den einzelnen Modulen zu ergänzen.

Nachteile:

- Performance

- Stabilität

Detaillierte Informationen sind unter folgendem Link zu finden:

10.1.2 Typische Architektur mit der Hilfe der PRISM Library

Abbildung 19 PRISM Überblick

FloorballEventer

35

Die wichtigen Begriffe im Zusammenhang mit PRISM

Begriff Beschreibung

Shell Hauptapplikation, in welche die Module geladen werden. Sie definiert das Layout und die Struktur der Applikation, weiss aber nicht welche Module dann zur Laufzeit wirklich geladen werden. Meist beinhaltet Sie noch Services welche von allen Modulen dann verwendet werden.

Region Regionen sind logische Platzhalter, in welche die Views der einzelnen Module dargestellt werden. Dies ermöglich dass das UI Layout einer Ap-plikation verändert werden kann, ohne dass die Applikationslogik betref-fen ist.

EventAggregator Ermöglich die Kommunikation von lose gekoppelten Komponenten.

Bootstrapper Der Bootstrapper ist der „Leim“ welche die PRISM Services mit Hilfe von MEF oder Unity verbindet. Für den FE wird MEF verwendet welches im nächsten Kapitel kurz beschrieben ist.

10.1.3 Event Aggregator Die einzelnen Komponenten in einer zusammengesetzten Anwendung müssen oft miteinander

kommunizieren, jedoch sollte die Kommunikation möglichst lose gekoppelt sein. Bei diesem Problem

hilft der EventAggregator. Details dazu sind unter folgendem Link zu finden:

http://msdn.microsoft.com/en-us/library/ff921122(v=pandp.40).aspx

10.2 MEF Das Managed Extensibility Framework, kurz MEF, ist ein IoC-Framework in .NET welche die Wieder-

verwendbarkeit von Anwendungen und Komponenten unterstützt. MEF erlaubt statisch kompilierte

Assemblies dynamisch zusammenzusetzen. Durch die Verwendung dieses Frameworks können im

Nachhinein zusätzliche Module einfach erstellt werden.

http://www.just-about.net/mef-tutorial

http://mef.codeplex.com/wikipage?title=Guide&referringTitle=Home

http://msdn.microsoft.com/de-de/library/ee332203.aspx

http://blogs.microsoft.co.il/blogs/bnaya/archive/2009/11/28/mef-for-beginner-concept-part-1.aspx

http://compositewpf.codeplex.com/releases/view/55580

FloorballEventer

36

10.3 MVVM Generell wird die ganze Applikation gemäss MVVM aufgebaut.

Abbildung 20 MVVM Grundlagen

MVVM steht für das Model-View-ViewModel Pattern, welches für eine klare Trennung zwischen

Business und Präsentation Logik in einer Applikation vorsieht. Gründe sind zum Beispiel:

- bessere Wartung

- einfacheres Testen

- einfachere Erweiterbarkeit

- einfachere Codewiederverwendbarkeit.

Das MVVM Pattern sieht eine Auftrennung des UI und der darunterliegenden Business und Präsenta-

tionslogik in drei separate Elemente

View UI und UI Logik

ViewModel Präsentation Logik und Status

Model Geschäftslogik und Daten

Weitere Details sind auf folgenden Seiten zu finden:

http://msdn.microsoft.com/en-us/library/gg405484%28v=pandp.40%29.aspx

http://code.cmsstores.com/introduction-to-model-view-viewmodel-mvvm-pattern/

10.4 WCF Um die Kommunikation zwischen den verteilten Modulen von FE möglichst flexibel und standardori-

entiert zu implementieren, wird dafür das Framework Microsoft WCF eingesetzt.

Die Windows Communication Foundation (WCF, früherer Codename Indigo) ist eine dienstorientierte

Kommunikationsplattform für verteilte Anwendungen in Microsoft Windows. Sie führt viele Netz-

werkfunktionen zusammen und stellt sie den Programmierern solcher Anwendungen standardisiert

zur Verfügung.

Die WCF abstrahiert das Konzept des Endpunktes durch eine Trennung in Address, Binding und

Contract (ABC-Prinzip).

FloorballEventer

37

Die Address (Adresse) ist ein URI, der den Ort des Dienstes beschreibt und somit seine Er-

reichbarkeit für die Dienstkonsumenten kennzeichnet.

Das Binding (Anbindung) beschreibt die Art der Kommunikation, worunter unter anderem

die Merkmale der Kodierung und des Protokolls fallen.

Der Contract (Vertrag) stellt die Dienstdefinition, insbesondere die zur Verfügung gestellten

Methoden beinhaltend, dar.

(Quelle: http://de.wikipedia.org/wiki/Windows_Communication_Foundation)

Folgende Contracts für FE werden im Projekt FEContracts definiert.

- OperationContracts: Operationen, die FE-Client-Module (z.B. FEAudience) beim FEServer auf-

rufen können

- CallbackContracts: Operationen, die der FEServer bei registrierten Client-Modulen aufrufen

können muss.

- DataContracts: Datenstrukturen, die beim Aufruf von Operationen und Callbacks zwischen

Client und Server ausgetauscht werden.

Bindings und Adressen werden in der Regel über Konfigurationsdateien zur Laufzeit definiert. Zur

Vereinfachung geschieht dies im Prototyp-System jedoch hart codiert. Der Prototyp von FE verwen-

det ein ungesichertes NetTcpBinding.

Lediglich Serverport und Server-IP-Adresse können konfigurativ vom Anwender beeinflusst werden.

FloorballEventer

38

11 Technische Konzepte

11.1 Persistenz

Abbildung 21 Entitätsmodell

Die Spieldaten von FE werden in einer relationalen Datenbank gespeichert. Als DBMS wird Microsoft

SQL Server verwendet, wobei die kostenlose Express-Edition ausreichend ist.

Die Fremdschlüsselbeziehungen zwischen den Entitäten werden durch Constraints gesichert.

Löschoperationen an übergeordneten Entitäten werden an die untergeordneten kaskadiert. So

braucht sich die Applikation zum Beispiel nicht um das Löschen von Tor- und Strafendaten zu küm-

mern, wenn ein Spiel gelöscht wird.

Der Zugriff auf die Datenbank wird über das Entity Framework (EF) gekapselt. Dies bietet mehrere

Vorteile:

- Anwendungsentwicklung unabhängig vom eingesetzten DBMS

FloorballEventer

39

- Automatisches Objektrelationales Mapping

- Anwendungscode bleibt SQL-frei

Nachteilig sind der durch das EF generierte Overhead, die zusätzliche Komplexität und die Beschrän-

kung auf DBMS, für die ein EF-kompatibler Treiber verfügbar ist.

Das Transaktionsmanagement wird durch das Unit-of-Work-Konzept sichergestellt (siehe 11.8 Unit of

Work).

Das Repository-Pattern wird verwendet, um die Datenbank vom internen Datenmodell zu kapseln.

(siehe 11.9 Repository Pattern)

11.2 Benutzeroberfläche Der Aufbau der Benutzeroberfläche wird in einem separaten Dokument beschrieben. [4]

11.3 Verteilung FE wird als verteiltes System erstellt. Dadurch wird ein funktionales Netzwerk beabsichtigt: verschie-

dene Funktionsmodule von FE werden auf verschiedenen Standorten installiert und kommunizieren

miteinander. Ein Netzwerk zur Lastverteilung ist nicht vorgesehen.

11.4 Ausnahme-/Fehlerbehandling Zum Abfangen unbehandelter Ausnahmen wird ein globaler Exception-Handler verwendet. Dies er-

möglicht, dass in solchen Fällen wenigstens noch ein aussagekräftiger Log-Eintrag erstellt werden

kann, um später die Fehlersuche zu erleichtern.

FloorballEventer

40

11.5 Logging Während der Ausführung von FE werden verschiedene Informationen protokolliert (geloggt). Die zu

loggenden Informationen werden gemäss ihrer Dringlichkeit und Bedeutung in folgende Log-Level-

Kategorien eingeteilt:

Loglevel Beschreibung SYSTEM Informationen, die das Starten oder Beenden des Systems betreffen

ERROR Informationen zu Situationen, die das ordnungsgemässe Ausführen einer Operation verhin-dert haben

WARNING Informationen zu Situationen, die potenziell schädliche Auswirkungen haben können, für deren Behandlung jedoch entsprechende Abläufe implementiert sind.

INFO Generelle Informationen, um den Ablauf der regulären Benutzung des Systems rekonstruie-ren zu können, z.B. Benutzerinteraktionen

DEBUG Sämtliche sonstige Informationen insbesondere zum Zwecke der Fehleranalyse

Das Logging erfolgt über das weit verbreitete Framework Log4Net.

http://logging.apache.org/log4net/

11.6 Internationalisierung Die Anwendung wird gemäss SRS nur in Deutsch erstellt. Einzelne Begriffe sind jeweils in Englisch.

Diese sind aber allgemein verständlich.

11.7 Testbarkeit Siehe Testkonzept [3].

11.8 Unit of Work http://martinfowler.com/eaaCatalog/unitOfWork.html

Deutsche Übersetzung: Patterns für Enterprise-Application-Architekturen, Martin Fowler, mitp Verlag

Heidelberg, ISBN 978-3-8266-1378-4

Verwaltet eine Liste von Objekten, die von einer Geschäftstransaktion betroffen sind, und koordiniert

das Speichern von Änderungen sowie die Lösung von Nebenläufigkeitsproblemen.

Wenn Sie Daten aus einer Datenbank lesen oder in ihr speichern, ist es wichtig festzuhalten, was Sie

geändert haben; anderenfalls werden diese Daten nicht wieder in die Datenbank zurückgeschrieben.

Ähnlich müssen Sie neue Objekte einfügen, die Sie erzeugen, und Objekte entfernen, die Sie löschen.

Sie können die Datenbank bei jeder Änderung Ihres Objektmodells ändern, aber dies kann zu zahlrei-

chen sehr kleinen Datenbankaufrufen führen, sodass die Arbeit des Systems verlangsamt wird. Au-

ßerdem ist es dann erforderlich, eine Transaktion während der gesamten Interaktion offen zu halten,

was unpraktisch ist, wenn eine Geschäftstransaktion mehrere Anforderungen umfasst. Die Situation

ist sogar noch schlimmer, wenn Sie festhalten müssen, welche Objekte Sie gelesen haben, um inkon-

sistente Lesevorgänge zu vermeiden.

FloorballEventer

41

Ein Unit of Work hält alles fest, was Sie während einer Geschäftstransaktion tun und was die Daten-

bank verändern kann. Wenn Sie fertig sind, stellt Unit of Work fest, was alles getan werden muss, um

die Datenbank so zu ändern, dass sie mit dem Ergebnis Ihrer Arbeit konsistent ist.

In .NET wird Unit of Work mit einem unsynchronisierten Dataset realisiert … .NET liest Daten aus der

Datenbank in ein Dataset ein. Dabei handelt es sich um eine Reihe von Objekten, die wie Datenbank-

Tabellen, Zeilen und Spalten angeordnet sind. … Jede Datenzeile hat eine Version (current, original,

proposed).

FloorballEventer

42

11.9 Repository Pattern Quelle: http://www.norberteder.com/blog/post/Das-Repository-Pattern-anhand-eines-Beispiels-inkl-

Tests.aspx)

Abbildung 22 Grundlagen des Repository Patterns

Das Repository Pattern entspricht der Auftrennung zwischen Businesslogik und der Datenbeschaf-

fung, unabhängig der Datenquelle.

Ein Repository bringt eine zentrale Zuständigkeit ins Spiel. Nämlich eine zentrale Stelle, die sich da-

rum kümmert, den Zugriff zu Entität XY zu gewähren (woher auch immer) und eine Anlage/Änderung

in einem korrekten Zustand weiter zu leiten. Die Businesslogik selbst verwendet das jeweilige Reposi-

tory um auf die Daten zuzugreifen mit dem Vorteil, dass alle relevanten Stellen denselben Code

durchlaufen. Dieser muss dementsprechend nur an einer einzigen Stelle gewartet werden. Selbst

Änderungen an der Datenbeschaffung selbst bleiben der Businesslogik verborgen, da nur für das

Repository relevant.