Eindverslag - Home | TU Delft Repositories

Technische Universiteit Delft

TI3800 Bachelorproject

Mobiel Notificatie Systeem

Eindverslag

Auteurs:Edwin van den HoudtManWai Shing

Begeleiders:Cor-Paul Bezemer (TU Delft)

Eugene Pattikawa (Exact)Peter Spanjer (Exact)

Delft, 11 juli 2013

Voorwoord

Dit document is het eindverslag van het bachelorproject van de opleiding Technische Informaticaop de TU Delft dat door Edwin van den Houdt en ManWai Shing is uitgevoerd.

Hierbij willen we graag de volgende personen bedanken:

Cor-Paul Bezemer (TU Delft Begeleider), voor zijn begeleiding gedurende het project, de zeergewaardeerde feedback op onze documentatie en het feit dat wij altijd terecht konden met al onzevragen.

Eugene Pattikawa (Projectbegeleider, Exact), voor de begeleiding van het project binnen Exacten hulp bij de administratieve procedures die wij moesten doorlopen gedurende het project.

Peter Spanjer (Technische begeleiding, Exact), voor de diverse tips die we gekregen hebben tijdensdit project en waar we altijd terecht konden voor al onze praktijk vragen.

1

Samenvatting

Dit is het eindverslag van het bachelorproject van de opleiding Technische Informatica op de TUDelft. In dit verslag beschrijven we onze stage bij Exact. De stappen die zijn genomen van hetopstellen van de eisen tot aan de conclusie hebben we vastgelegd in dit verslag.

Exact is een Nederlands softwarebedrijf dat in 1984 is opgericht. Sinds een paar jaar richt Exactzich ook op het ontwikkelen van mobiele apps, die werken op Android of iOS. Om deze activiteitennog beter in real-time te kunnen monitoren is het van belang dat de apps uitgerust worden metde mogelijkheid om notificaties te kunnen ontvangen.

Voor ons bachelorproject doen we daarom onderzoek naar het versturen van mobiele notificaties.Wij zijn uiteindelijk gekomen tot de volgende onderzoeksvraag:

Hoofdvraag: Welke eisen en technische implicaties zijn er verbonden aan het implementerenvan een applicatie voor het versturen van mobiele notificaties naar aanleiding van gebeurtenissengegenereerd door een webapplicatie?

Om op een antwoord te komen op onze onderzoeksvraag willen we graag een notificatie systeemimplementeren, dat uit de volgende componenten bestaat:

Notificatie ApplicatieEen applicatie die in staat is om gebeurtenissen af te vangen van de webapplicatie. Dezegebeurtenissen worden vervolgens omgezet naar notificaties. Uiteindelijk worden de notifi-caties volgens een correct formaat naar verschillende mobiele platforms verstuurd. Hierbijwordt rekening gehouden met welk type notificatie naar welke gebruiker moet (welk OS).

Android Demo AppEen eenvoudige Android applicatie, waarmee uiteindelijk de verstuurde notificatie ontvangenkan worden en correct kan worden weergegeven.

De eerste stap dat we genomen hebben is het opstellen van de belangrijkste functionele en niet-functionele eisen waar het notificatie systeem aan moet voldoen. De functionele eisen beschrijvenwat het systeem moet doen voor de gebruiker. De voorwaarden waaraan gehouden moeten wordentijdens de implementatie van het systeem wordt aangegeven door de niet-functionele eisen.

Vervolgens gebruiken we de opgestelde eisen om het functioneel ontwerp te maken dat de functi-onaliteit van het systeem beschrijft in de vorm van use cases. Met de use cases kunnen we eenbeter beeld schetsen over de werking van de features.

Het technisch ontwerp dat we in onze derde stap hebben gemaakt, geeft een technisch overzichtvan de verschillende componenten van de Notificatie Applicatie. De Notificatie Applicatie bestaatuit drie componenten:

• Een Notification Trigger die gebruikt wordt om handmatig twee soorten notificatie berichtente genereren. Een persoonlijke notificatie en een notificatie voor iedereen die zich op eenbepaalde Topic heeft geabonneerd.

• Een Message Broker die de notificatie berichten koppelt met gebruikers die zich voor eenTopic hebben aangemeld.

• Een Dispatcher die voor de communicatie verzorgt van de push service als het versturen vande daadwerkelijke notificatie.

Na het ontwerpen hebben we een testplan opgesteld om de kwaliteit van ons prototype te garan-deren. In het testplan geven we aan welke maatregelen er getroffen worden om de code te testen.Ook zullen de beperkingen worden aangegeven met betrekking tot niet testbare onderdelen.

Tijdens de implementatie worden de Notificatie Applicatie en de Android Demo App geımplementeerd.Hierbij wordt er rekening gehouden met de resultaten van de voorgaande stappen.

2

Vanwege de beperkte ontwikkeltijd is gekozen voor het ontwikkelen van een notificatie systeemdat in eerste instantie de focus legt op het Android platform. Maar het prototype zal flexibel zijnzodat het toevoegen van andere platformen eenvoudig is.

Het antwoord op de hoofdvraag hebben we gegeven door het implementeren van ons notificatiesysteem. Puur afgaand op de “requirements evaluatie” zijn we geslaagd in het bereiken van deeisen die we aan het begin van dit project gesteld hebben. Hiermee hebben we met ons prototypelaten zien wat er allemaal bij komt kijken indien een notificatie systeem ontwikkeld moet wordendat gebeurtenissen gegenereerd door een webapplicatie verwerkt.

3

Inhoudsopgave

Voorwoord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1 Inleiding 6

2 Probleemstelling 7

3 Requirements Analysis 83.1 Functionele Eisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Notificatie Applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.2 Android Demo App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Niet-Functionele Eisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.1 Notificatie Applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2 Android Demo App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Functioneel Ontwerp 124.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


5 Technisch Ontwerp 205.1 Klasse-Niveau Beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 Testplan 246.1 Automatische Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2 Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3 Statische Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.4 Handmatige Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.5 Performance Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.6 Software Improvement Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 Implementatie 267.1 Notification Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.2 Message Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.3 Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.4 Android Demo App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8 Requirements Evaluatie 298.1 Functionele Eisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


8.2 Niet-Functionele Eisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.2.1 Uitbreidbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.2.2 Onderhoudbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.2.3 Betrouwbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

9 Reflectie 339.1 Edwin van den Houdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339.2 ManWai Shing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

10 Conclusie 35

A Plan van Aanpak 37

4

B Orientatieverslag 51

C Bestudeerde Technieken/Tools 72

D Taakverdeling 73

E SIG Moment 1: 14-06-2013 74

F SIG Moment 2: 05-07-2013 75

5

1 Inleiding

Exact1 is een Nederlands softwarebedrijf dat in 1984 is opgericht. Ze bieden oplossingen aan diealle belangrijke zakenprocessen ondersteunen voor het midden- en kleinbedrijf. Ze ontwikkelencloudgeorienteerde oplossingen en maatwerk voor industrieen als accountancy, retail en profes-sionele diensten en fabricage.

Sinds een paar jaar richt Exact zich ook op het ontwikkelen van mobiele apps, die op het Androidof iOS platform werken. Met behulp van deze apps kunnen ze een betere dienst aanbieden voorklanten die een beter real-time inzicht willen van hun zakelijke activiteiten. Om deze activiteitennog beter in real-time te kunnen monitoren is het van belang dat de apps uitgerust worden metde mogelijkheid om notificaties te kunnen ontvangen.

In dit verslag beschrijven we onze stage bij Exact. De stappen die zijn genomen van het opstellenvan de eisen tot aan de conclusie hebben we vastgelegd in dit verslag.

Dit verslag zit als volgt in elkaar. In hoofdstuk 2 beschrijven we onze probleemstelling. Hierwordt omschreven wat we tijdens onze stage bij Exact willen onderzoeken. Een overzicht van debelangrijkste functionele en niet-functionele eisen over ons prototype, het notificatie systeem, gevenwe in hoofdstuk 3. In hoofdstuk 4 wordt het functioneel ontwerp gegeven dat de functionaliteitvan het systeem beschrijft. Hoofdstuk 5 beschrijft het technisch ontwerp van het systeem. Omde kwaliteit van het eindproduct te garanderen is het van belang dat de implementatie goed isgetest. Dit beschrijven we in hoofdstuk 6. In hoofdstuk 7 geven we een globaal overzicht van deuiteindelijke implementatie. Alle onderdelen waaruit het systeem bestaat zullen worden toegelichten de werking ervan zal beschreven worden. In hoofdstuk 8 evalueren we de eisen van het systeemom te zien in hoeverre ze in ons systeem zijn geımplementeerd. Hoofdstuk 9 bevat onze persoonlijkereflectie verslagen. We beschrijven onze ervaringen over het bachelorproject. En tot slot wordt inhoofdstuk 10 onze conclusie gegeven die het antwoord geeft op de hoofdvraag.

1http://www.exact.nl

6

http://www.exact.nl

2 Probleemstelling

Exact wil graag de mogelijkheid hebben om notificaties te kunnen versturen naar de gebruikersvan hun mobiele applicaties. Het versturen van notificaties gaat op grond van gebeurtenissen diegegenereerd worden vanuit de webapplicatie. Een voorbeeld hiervan is het bijhouden van urenregistratie. Voor bepaalde gebruikers is het mogelijk om de uren registratie in de webapplicatiebij te houden. In het geval een gebruiker vergeten is om zijn uren te registreren, kan daar eenherinnerings-gebeurtenis voor worden gegenereerd. Aan de hand van zo een gebeurtenis zal ereen notificatie (herinnering) verstuurd worden naar de desbetreffende gebruiker die zich voor dezenotificatie Topic heeft aangemeld. Een Topic is een notificatie categorie waar een gebruiker zichop kan abonneren.

Tijdens de orientatiefase hebben we onderzoek gedaan naar het versturen van mobiele notificatiesen onze bevindingen vastgelegd in ons orientatieverslag dat in meer detail terug te lezen is inbijlage B. Wij zijn uiteindelijk gekomen tot de volgende onderzoeksvraag:


We beantwoorden deze vraag in de rest van dit verslag.

7

3 Requirements Analysis

Dit hoofdstuk bevat een overzicht van de belangrijkste functionele en niet-functionele eisen, waarhet prototype, het notificatie systeem, dat beschreven is in het Plan van Aanpak in bijlage A, aanmoet voldoen. Aan de hand van ons literatuuronderzoek uit de orientatiefase hebben we samenmet Exact de eisen opgesteld.

De eisen worden geclassificeerd met behulp van de MoSCoW2 methode. Daarmee wordt deprioriteit van iedere eis aangegeven. De eisen worden als volgt geclassificeerd:

Must: zijn eisen die geımplementeerd moeten worden om het systeem succesvol te kunnen noe-men.

Should: zijn eisen die niet per se noodzakelijk zijn om het systeem te laten werken, maar ze zijnbelangrijk genoeg om geımplementeerd te worden in de eerste versie van het systeem. Inhoge nood mag ervan worden afgeweken.

Could: zijn eisen die het liefst wel geımplementeerd worden, maar indien er niet genoeg tijd isvoor de implementatie is dat niet noodzakelijk.

Would: eisen hoeven in deze versie van het systeem niet te worden geımplementeerd. In volgendeversies zou gekozen kunnen worden om ze alsnog te implementeren.

Bij het beschrijven van de eisen zullen we gebruik maken van bepaalde terminologie. Om verwar-ring te voorkomen geven we een beschrijving van de termen die we zullen gebruiken:

Topic: een Topic is een notificatie categorie waarop een gebruiker zich kan abonneren. Eengebeurtenis hoort bij een bepaalde Topic en een gebruiker kan zich abonneren op een bepaaldeTopic.

Abonnement: een abonnement beschrijft welke gebruiker voor welk Topic heeft geabonneerd.

3.1 Functionele Eisen

Deze paragraaf geeft een overzicht van alle functionele eisen3 voor het systeem. De functioneleeisen beschrijven wat het systeem moet doen voor de gebruiker. Volgens de MoSCoW methodewordt voor elke component van het systeem de functionele eisen gegeven. Het notificatie systeembestaat uit de volgende componenten:



Tijdens ons project richten we in eerste instantie op het Android platform. In ons Orientatieverslagin bijlage B is te lezen dat voor de ontwikkeling op het iOS platform een developer license nodigis die we tijdens het project niet tot onze beschikking hebben. We hebben daarom gekozen omvoor ons prototype te richten op het Android platform. Daarnaast was vanwege de beperkteontwikkeltijd een betere keuze om ons te concentreren op een platform en meer tijd te besteden

2https://en.wikipedia.org/wiki/MoSCoW_Method3http://en.wikipedia.org/wiki/Functional_requirement

8

https://en.wikipedia.org/wiki/MoSCoW_Method

http://en.wikipedia.org/wiki/Functional_requirement

aan het ontwerpen van een uitbreidbaar systeem. Het prototype zal daarom flexibel zijn zodat hettoevoegen van andere platformen eenvoudig is. Dit zullen we in hoofdstuk 5 beschrijven.

3.1.1 Notificatie Applicatie

1. Must Have

(a) Gebeurtenissen afvangen van een demo webapplicatieMet behulp van een demo webapplicatie kan handmatig bepaalde gebeurtenissen gege-nereerd worden. Indien zo een gebeurtenis tot een Topic behoort, moet die afgevangenworden.

(b) Verbinding opzetten tussen Notificatie Applicatie en Google Cloud Messa-ging (Android)De verbinding verzorgen tussen de Notificatie Applicatie en de Google Cloud Messaging(GCM) server.

(c) Gebruikers ophalen behorend bij een bepaalde TopicBij een gegeven Topic moeten de gebruikers opgehaald worden die zich voor deze Topichebben geabonneerd.

(d) Versturen van een persoonlijke notificatieHet versturen van een persoonlijke notificatie naar een gebruiker die zich heeft geabon-neerd op een bepaalde Topic.

(e) Versturen van een groep notificatieHet versturen van een groep notificatie naar alle gebruikers die zich hebben geabonneerdop een bepaalde Topic.

(f) Abonnementen toevoegenVoeg een abonnement toe als een gebruiker zich op een bepaalde Topic heeft geabon-neerd. Een abonnement beschrijft op welke Topic een gebruiker zich heeft geabonneerd.

(g) Abonnementen verwijderenVerwijder een abonnement als een gebruiker zich voor een bepaalde Topic heeft afge-meld.

(h) Gebruiker toevoegenEen lijst van gebruikers. Een gebruiker moet hieraan toegevoegd kunnen worden.

(i) Verzoeken afvangen en verwerken van de Android Demo AppVerzoeken van de Android Demo App moeten afgevangen worden en vervolgens ver-werkt worden. Voorbeelden hiervan zijn het registreren van de gebruiker, abonnerenop een Topic en het afmelden van een Topic.

2. Should Have

(a) Handmatig notificaties versturenVia een Demo Webapplicatie handmatig notificaties versturen.

(b) Afmeldingen abonnement bijhoudenEen lijst bijhouden met alle afmeldingen.

9

3. Could Have

(a) Quality of ServiceBijhouden of bericht correct is verzonden en zo niet nog een keer proberen te verzenden.

(b) Gebeurtenissen afvangen voor de Exact Online webapplicatieDe Exact Online webapplicatie genereert bepaalde gebeurtenissen. Indien zo een ge-beurtenis tot een Topic behoort, moet die afgevangen worden.

4. Would/Won’t Have

(a) Ondersteuning voor andere mobiele platformenNotificatie verzenden naar andere mobiele platformen (bijvoorbeeld: iOS, WindowsMobile, etc).

3.1.2 Android Demo App

1. Must Have

(a) Registreren van de Android Demo AppDe Android Demo App die geınstalleerd is op een Android telefoon moet zich kunnenregistreren bij de GCM server en vervolgens bij de Notificatie Applicatie.

(b) Notificaties ontvangen op de Android Demo AppVerstuurde notificaties moeten ontvangen en weergegeven worden op de Android DemoApp.

2. Should Have

(a) Abonneren op een TopicDe gebruiker moet zich kunnen abonneren op een bepaalde Topic.

(b) Afmelden voor een TopicDe gebruiker moet zich kunnen afmelden voor een bepaalde Topic.

3. Could Have

(a) Opties voor aangemelde Topics aanpassenBepaalde Topics kunnen meerdere opties bevatten, de gebruiker moet deze kunneninstellen. Een voorbeeld hiervan is het aangeven van de frequentie voor het ontvangenvan de notificatie.

(b) Verwerk ontvangen notificatieEen actie afhandelen die hoort bij een specifieke notificatie. Bijvoorbeeld, applicatie inbepaalde scherm van een mobiele applicatie opstarten.


(a) Profiel instellingen per mobiele telefoonPer mobiele telefoon die een gebruiker heeft kan hij zelf bepalen welke notificatie hijwilt ontvangen. Bij eerste keer aanzetten kan hij een profiel nemen van een andergeregistreerde mobiele telefoon die ook van deze gebruiker is.

10

3.2 Niet-Functionele Eisen

In deze paragraaf beschrijven we de niet-functionele eisen4, waar het systeem aan moet voldoen.Deze eisen hebben niet met de functionaliteit van het systeem te maken. Ze kunnen gezienworden als voorwaarden waaraan gehouden moeten worden tijdens de implementatie van hetsysteem.


1. Must Have

(a) UitbreidbaarheidEenvoudig nieuwe platforms kunnen toevoegen, waar notificaties naar verstuurd kunnenworden.

(b) OnderhoudbaarheidHet systeem moet eenvoudig te onderhouden zijn. Met minimale inzet moet nieuwefunctionaliteit toegevoegd kunnen worden.

(c) BetrouwbaarheidHet systeem moet in staat zijn om grote hoeveelheden aan notificaties af te handelenzonder storingen.

2. Should HaveGeen.

3. Could Have

(a) API voor notificaties versturenEen API voor eenvoudige integratie met andere applicaties.

4. Would/Won’t HaveGeen.


1. Must HaveGeen.

2. Should Have

(a) GebruiksvriendelijkheidDe interfaces voor de mobiele applicatie moeten gebruiksvriendelijk zijn.

3. Could HaveGeen.

4. Would/Won’t HaveGeen.

In het volgende hoofdstuk beschrijven we het functioneel ontwerp van het systeem dat gebaseerdis op de verkregen eisen.

4https://en.wikipedia.org/wiki/Non-functional_requirement

11

https://en.wikipedia.org/wiki/Non-functional_requirement

4 Functioneel Ontwerp

In dit hoofdstuk wordt het functioneel ontwerp van het systeem gepresenteerd. Het functioneelontwerp omschrijft de functionaliteit van het systeem (features) en is gebaseerd op de eisen diewe in het vorige hoofdstuk hebben opgesteld. Dit ontwerp vormt een belangrijk deel van hetfunctioneel ontwerp proces, omdat het gebruikt kan worden om te toetsen of de ontwikkelaars ende opdrachtgever dezelfde applicatie in gedachte hebben.

Met behulp van use cases zullen we in de volgende paragraaf de functionaliteit beschrijven van hetsysteem. Hiermee kan een beter beeld geschetst worden over de werking van de features.

4.1 Use Cases

Deze paragraaf beschrijft de features van het systeem met behulp van use cases. De use cases zijngebaseerd op de functionele eisen die de features van het systeem representeren. Hierbij worden deuse cases van de niet-functionele eisen niet gegeven, omdat ze niet direct de features representerenvan het systeem. Om consistent te blijven met het vorige hoofdstuk worden de use cases in dezelfdevolgorde gepresenteerd als de eisen.

In de use cases zullen we gebruik maken van de volgende actoren:

Demo Webapplicatie: een eenvoudige webapplicatie waar gebeurtenissen gegenereerd kan wor-den. Een voorbeeld hiervan is het handmatig versturen van een notificatie bericht.

Notificatie Applicatie: ons prototype dat onder andere zorgt voor de afhandeling van de ge-beurtenissen (opvangen en verwerken) en het verzenden van de notificatie.

Android Demo App: de Android applicatie, die notificaties kan ontvangen, geınstalleerd op hetAndroid toestel van de gebruiker.

Gebruiker: een gebruiker van de Android Demo App. Hij kan zich registreren bij de NotificatieApplicatie en zich abonneren op een Topic voor het ontvangen van een notificatie.

GCM server: de Google Cloud Messaging server zorgt voor het geven van een registratie IDaan de Android Demo App en het verzenden van de notificatie naar de Android DemoApp afkomstig van de Notificatie Applicatie.


1. Must HaveIn dit gedeelte worden de use cases gegeven voor de features die geımplementeerd moetworden tijdens de implementatie.

• Use case S1Feature: Gebeurtenissen afvangen van een demo webapplicatieSamenvatting: Met behulp van een demo webapplicatie kan handmatig bepaalde ge-beurtenissen gegenereerd worden. Indien zo een gebeurtenis tot een Topic behoort,moet die afgevangen worden.Preconditie: De gegenereerde gebeurtenissen behoren tot een Topic die abonneerbaaris.

Stappen:

1. De Demo Webapplicatie genereert een gebeurtenis.

2. De Notificatie Applicatie vangt deze gebeurtenis af.

Resultaat: De Notificatie Applicatie heeft een gebeurtenis afgevangen.

12

• Use case S2Feature: Verbinding opzetten tussen Notificatie Applicatie en Google CloudMessaging (Android)Samenvatting: De verbinding verzorgen tussen de Notificatie Applicatie en de GoogleCloud Messaging (GCM) server.Preconditie: De Notificatie Applicatie heeft de benodigde gegevens om gebruik tekunnen maken van de Google Services.

Stappen:

1. De Android Demo App registreert zich bij de GCM server om push berichten teontvangen.

2. De GCM server registreert deze Android Demo App en geeft een registratie IDterug.

3. De Android Demo App geeft deze registratie id door aan de Notificatie Applicatie.

4. De Notificatie Applicatie kan berichten verzenden via de GCM server naar deAndroid Demo App.

Resultaat: Er is een verbinding opgezet tussen de Android Demo App en de GCMserver.

• Use case S3Feature: Gebruikers ophalen behorend bij een bepaalde TopicSamenvatting: Bij een gegeven Topic moeten de gebruikers opgehaald worden die zichvoor deze Topic hebben geabonneerd.Preconditie: Gebruikers hebben zich geabonneerd op bepaalde Topics en de DemoWebapplicatie heeft een gebeurtenis gegenereerd.

Stappen:

1. De Notificatie Applicatie vangt de gebeurtenis af.

2. De Notificatie Applicatie bekijkt de lijst van gebruikers en zoekt naar de gebruikersdie voor deze Topic hebben geabonneerd.

Resultaat: De Notificatie Applicatie weet welke groep gebruikers op deze Topic heeftgeabonneerd.

• Use case S4Feature: Versturen van een persoonlijke notificatieSamenvatting: Het versturen van een persoonlijke notificatie naar een gebruiker diezich heeft geabonneerd op een bepaalde Topic.Preconditie: De Notificatie Applicatie krijgt een gebeurtenis binnen om een persoonlijkenotificatie te versturen naar een bepaalde Topic. (Use case: S1-S3)

Stappen:

1. De Notificatie Applicatie verifieert of de desbetreffende gebruiker zich heeft gea-bonneerd op die Topic.

2. Indien ja, dan wordt de notificatie verstuurd naar de desbetreffende gebruiker,anders wordt het genegeerd.

Resultaat: De gebruiker krijgt de notificatie binnen of krijgt niks binnen.

13

• Use case S5Feature: Versturen van een groep notificatieSamenvatting: Het versturen van een groep notificatie naar alle gebruikers die zichhebben geabonneerd op een bepaalde Topic.Preconditie: De Notificatie Applicatie krijgt een gebeurtenis binnen om een groepnotificatie te verzenden naar een bepaalde Topic. (Use case: S1-S3)

Stappen:

1. De Notificatie Applicatie haalt alle gebruikers op die zich geabonneerd hebben opdeze Topic.

2. De Notificatie Applicatie verzendt de notificatie naar de gebruikers.

Resultaat: De gebruikers die zich geabonneerd hebben op deze Topic krijgen een noti-ficatie binnen.

• Use case S6Feature: Abonnementen toevoegenSamenvatting: Voeg een abonnement toe als een gebruiker zich op een bepaalde Topicheeft geabonneerd. Een abonnement beschrijft op welke Topic een gebruiker zich heeftgeabonneerd.Preconditie: De Notificatie Applicatie heeft een lijst van Topics waarop geabonneerdkan worden.

Stappen:

1. Een gebruiker abonneert op een Topic.

2. De Notificatie Applicatie voegt een nieuw abonnement toe.

Resultaat: Een nieuw abonnement is toegevoegd aan de lijst van abonnementen.

• Use case S7Feature: Abonnementen verwijderenSamenvatting: Verwijder een abonnement als een gebruiker zich voor een bepaaldeTopic heeft afgemeld.Preconditie: De Notificatie Applicatie heeft een lijst van Topics waar gebruikers zichvan kan afmelden.

Stappen:

1. Een gebruiker meldt zich af van een Topic.

2. De Notificatie Applicatie verwijdert het abonnement uit de lijst.

Resultaat: Het abonnement is verwijderd uit de lijst van abonnementen.

• Use case S8Feature: Gebruiker toevoegenSamenvatting: Een lijst van gebruikers. Een gebruiker moet hieraan toegevoegd kunnenworden.Preconditie: De Notificatie Applicatie heeft een lijst van gebruikers en de gebruikerbevindt zich in de Android Demo App.

Stappen:

1. De gebruiker meldt zich aan bij de Notificatie Applicatie.

2. De Notificatie Applicatie voegt de gebruiker toe aan de lijst van gebruikers.

Resultaat: De gebruiker is toegevoegd aan de lijst van gebruikers.

14

• Use case S9Feature: Verzoeken afvangen en verwerken van de Android Demo AppSamenvatting: Verzoeken van de Android Demo App moeten afgevangen worden envervolgens verwerkt worden. Voorbeelden hiervan zijn het registreren van de gebruiker,abonneren op een Topic en het afmelden van een Topic.

Stappen:

1. De gebruiker doet een verzoek via de Android Demo App.

2. De Notificatie Applicatie krijgt het verzoek binnen en verwerkt dit door de bijbe-horende procedure aan te roepen.

Resultaat: Het verzoek is ontvangen en verwerkt.

2. Should HaveDit deel beschrijft de use cases die ontworpen zijn voor de features die geımplementeerddienen te worden tijdens het project. In hoge nood mag ervan worden afgeweken.

• Use case S10Feature: Handmatig notificaties versturenSamenvatting: Via een Demo Webapplicatie handmatig notificaties versturen.Preconditie: De gebruiker bevindt zich op de notificatie verzend pagina. (Use case:S1-S3)

Stappen:

1. De gebruiker ziet een pagina met een formulier om een notificatie op te stellen.

2. De gebruiker vult de betreffende velden in en klikt op een verzend knop.

3. De Notificatie Applicatie verstuurt de notificatie.

Resultaat: De gebruiker heeft handmatig een notificatie verstuurd.

• Use case S11Feature: Afmeldingen abonnement bijhoudenSamenvatting: Een lijst bijhouden met alle afmeldingen.Preconditie: Er bestaat een lijst van gebruikers en er komt een verzoek binnen om zichaf te melden voor een bepaalde notificatie. (Use case: S1 en S7)

Stappen:

1. De Notificatie Applicatie krijgt een verzoek binnen voor het afmelden van eenbepaalde Topic.

2. De Notificatie Applicatie meldt de gebruiker af van de desbetreffende Topic.

3. De Notificatie Applicatie registreert de afmelding.

Resultaat: De afmelding van de gebruiker is geregistreerd.

15

3. Could HaveIn dit gedeelte worden de use cases gegeven voor de features die het liefst wel geımplementeerdworden, maar indien er niet genoeg tijd is voor de implementatie is dat niet noodzakelijk.

• Use case S12Feature: Quality of ServiceSamenvatting: Bijhouden of bericht correct is verzonden en zo niet nog een keerproberen te verzenden.Preconditie: Notificatie is aangemaakt. (Use case: S1 en M1)

Stappen:

1. De Notificatie Applicatie verstuurt de notificatie naar de gebruiker.

2. De Android Demo App geeft een respons terug over de ontvangen notificatie.

3. De Notificatie Applicatie ontvangt de status van de verzonden notificatie.

4. Indien notificatie niet met succes is ontvangen, dan wordt de notificatie opnieuwverzonden.

Resultaat: De notificatie is ontvangen, eventueel na meerdere pogingen.

• Use case S13Feature: Gebeurtenissen afvangen voor de Exact Online webapplicatieSamenvatting: De Exact Online webapplicatie genereert bepaalde gebeurtenissen. In-dien zo een gebeurtenis tot een Topic behoort, moet die afgevangen worden.Preconditie: De gegenereerde gebeurtenissen behoren tot een Topic die abonneerbaaris.

Stappen:

1. De Exact Online webapplicatie genereert een gebeurtenis.

2. De Notificatie Applicatie vangt deze gebeurtenis af.

Resultaat: De Notificatie Applicatie heeft een gebeurtenis afgevangen van de ExactOnline webapplicatie.

4. Would/Won’t HaveDit deel beschrijft de use cases voor de features die in deze versie van het systeem nietworden geımplementeerd. In volgende versies zou gekozen kunnen worden om ze alsnog teimplementeren.

• Use case S14Feature: Ondersteuning voor andere mobiele platformenSamenvatting: Notificatie verzenden naar andere mobiele platformen (bijvoorbeeld:iOS, Windows Mobile, etc).Preconditie: De Notificatie Applicatie heeft de benodigde gegevens voor het verzendenvan een notificatie.

Stappen:

1. De Notificatie Applicatie verzorgt voor het opzetten van een verbinding om eennotificatie te verzenden naar het betreffende platform.

2. Stap 2: De Notificatie Applicatie verzendt de notificatie.

Resultaat: De notificatie is verzonden naar het betreffende platform mobiel apparaat.

16


1. Must Have

• Use case M1Feature: Registreren van de Android Demo AppSamenvatting: De Android Demo App die geınstalleerd is op een Android telefoon moetzich kunnen registreren bij de GCM server en vervolgens bij de Notificatie Applicatie.Preconditie: Mobiele telefoon is verbonden met internet en heeft de Android DemoApp geınstalleerd die het ontvangen van GCM notificatie ondersteund. (Use case: S9)

Stappen:

1. De Android Demo App registreert zich bij de GCM server.

2. De GCM server geeft een registratie ID terug aan de Android Demo App.

3. De Android Demo App registreert zich met de registratie ID bij de NotificatieApplicatie.

Resultaat: De Android Demo App is geregistreerd bij de Notificatie Applicatie.

• Use case M2Feature: Notificaties ontvangen op de Android Demo AppSamenvatting: Verstuurde notificaties moeten ontvangen en weergegeven worden op deAndroid Demo App.Preconditie: Mobiele telefoon is verbonden met internet en heeft de Android DemoApp geınstalleerd die het ontvangen van GCM notificatie ondersteund. (Use case: S1-S3, S4 of S5 en M1)

Stappen:

1. De gebruiker krijgt een notificatie binnen op zijn Android Demo App.

2. De Android Demo App toont de notificatie aan de gebruiker.

Resultaat: De gebruiker heeft een notificatie binnengekregen.

2. Should Have

• Use case M3Feature: Abonneren op een TopicSamenvatting: De gebruiker moet zich kunnen abonneren op een bepaalde Topic.Preconditie: De gebruiker bevindt zich in de Android Demo App. (Use case: S9 enM1)

Stappen:

1. De gebruiker abonneert voor een Topic.

2. De Notificatie Applicatie krijgt het verzoek binnen en verwerkt dit.

Resultaat: De gebruiker is geabonneerd op de desbetreffende Topic.

17

• Use case M4Feature: Afmelden voor een TopicSamenvatting: De gebruiker moet zich kunnen afmelden voor een bepaalde Topic.Preconditie: De gebruiker bevindt zich in Android Demo App en is aangemeld voor eenTopic. (Use case: S9 en M1)

Stappen:

1. De gebruiker meldt zich af voor een Topic waarop hij heeft geabonneerd.

2. De Notificatie Applicatie krijgt het verzoek binnen en verwerkt dit.

Resultaat: De gebruiker is afgemeld van de desbetreffende Topic.

3. Could Have

• Use case M5Feature: Opties voor aangemelde Topics aanpassenSamenvatting: Bepaalde Topics kunnen meerdere opties bevatten, de gebruiker moetdeze kunnen instellen. Een voorbeeld hiervan is het aangeven van de frequentie voorhet ontvangen van de notificatie.Preconditie: De gebruiker bevindt zich in de Android Demo App en heeft zich aange-meld voor een Topic. (Use case: S9, M1 en M3)

Stappen:

1. De gebruiker gaat naar de instellingen.

2. De Android Demo App toont een lijst van Topics waarop de gebruiker zich heeftgeabonneerd.

3. De gebruiker kiest een Topic om de extra opties aan te passen.

4. De gebruiker stelt de extra opties in en bevestigt deze.

Resultaat: De gebruiker heeft de gekozen Topic de extra opties ingesteld.

• Use case M6Feature: Verwerk ontvangen notificatieSamenvatting: Een actie afhandelen die hoort bij een specifieke notificatie. Bijvoor-beeld, applicatie in bepaalde scherm van een mobiele applicatie opstarten.Preconditie: Android Demo App heeft notificatie ontvangen. (Use case: S4 of S5, M1en M2

Stappen:

1. De gebruiker klikt op de ontvangen notificatie.

2. Een bepaalde actie behorende bij die specifieke notificatie wordt opgestart.

3. De gebruiker ziet een bepaalde scherm of applicatie voor zich.

Resultaat: Een bepaalde scherm/applicatie is opgestart.

18


• Use case M7Feature: Profiel instellingen per mobiele telefoonSamenvatting: Per mobiele telefoon die een gebruiker heeft kan hij zelf bepalen welkenotificatie hij wilt ontvangen. Bij eerste keer aanzetten kan hij een profiel nemen vaneen ander geregistreerde mobiele telefoon die ook van deze gebruiker is.Preconditie: De gebruiker bevindt zich in de Android Demo App. (Use case: S9 enM1)

Stappen:

1. De gebruiker gaat naar de instellingen.

2. Het systeem toont een optie om een eerdere profiel te nemen.

3. Indien gebruiker een eerdere profiel neemt, dan wordt voor deze mobiel op dezelfdenotificatie categorieen geabonneerd als de genomen profiel.

4. Indien gebruiker geen eerdere profiel neemt, dan kan de gebruiker kiezen voor denotificatie categorieen waarvoor hij zich wil abonneren.

5. De gebruiker bevestigt zijn keuze.

Resultaat: De gebruiker gebruikt een eerdere profiel of stelt een nieuwe in.

In het volgende hoofdstuk wordt het technisch ontwerp gegeven van het systeem. Het technischontwerp beschrijft het ontwerp in termen van technische specificaties. Met behulp van het functi-oneel ontwerp kan het technisch ontwerp getoetst worden.

19

5 Technisch Ontwerp

Om beter inzicht te verkrijgen in het systeem zal er een technisch overzicht gegeven worden van deverschillende componenten die het systeem zal bevatten. Dit overzicht bestaat uit UML diagram-men en een beknopte beschrijving van de werking per component. Ook zal er een uitgebreidereklasse-diagram gegeven worden.

De notificatie applicatie zal bestaan uit de volgende drie componenten:

• Een Notification Trigger

• Een Message Broker

• Een Dispatcher

Tijdens de implementatie van de componenten zal er rekening gehouden worden met de mogelijk-heid om nieuwe Push Service implementaties toe te voegen. Het toevoegen moet kunnen gebeurenzonder dat er veel code herschreven moet worden.

De Notification Trigger wordt gebruikt om handmatig twee soorten notificatie berichten te gene-reren. De ene notificatie bericht is bedoeld voor iedereen die zich op een bepaalde Topic hebbengeabonneerd. De andere soort notificatie bericht is gekoppeld aan zowel een Topic als een bepaaldepersoon. Zodra een notificatie bericht is gegenereerd zal de Message Broker op de hoogte wordengesteld en de afhandeling verder verzorgen. De Notification Trigger kan uitgebreid worden met demogelijkheid om te reageren op gebeurtenissen uit een andere applicatie.

De Message Broker koppelt notificatie berichten met de gebruikers die zich voor een Topic hebbenaangemeld. Indien er een persoonlijk bericht verstuurd moet worden, controleert de MessageBroker of de persoon zich ook daadwerkelijk heeft geabonneerd op de specifieke Topic. Degecombineerde informatie wordt doorgestuurd naar de Dispatcher. De geabonneerde gebruikersbevinden zich in een database, waar de Message Broker mee kan communiceren. Gebruikerskunnen zich ook via de Message Broker abonneren op Topics.

De Dispatcher heeft kennis van de externe push service die ondersteund wordt. Iedere pushservice heeft een specifieke implementatie van de notificatie nodig en een specifieke manier vancommuniceren met de service. De Dispatcher moet dus in staat zijn om per ondersteund mobieletoestel de juiste implementatie te verzorgen voor zowel de communicatie met de push service alsvoor het versturen van de daadwerkelijke notificatie.

20

Figuur 1: Componenten diagram.

21

De database zal volgens het volgende model worden ingericht. Iedere gebruiker kan 0 of meermobiele toestellen bezitten. De gebruiker kan op 0 of meer categorieen zijn geabonneerd. Iedereabonnement bestaat tevens uit een gebruiker en een categorie.

Figuur 2: Database model.

5.1 Klasse-Niveau Beschrijving

Om een overzicht te krijgen van het systeem zou u in figuur 3 het UML-diagram kunnen zien vanhet systeem. Per klasse wordt een beknopte beschrijving gegeven. We maken onderscheid in eennotificatie dat getoond wordt op een mobiel toestel en de Notification object die wij gebruiken inons systeem.

De Notification object is de implementatie van de daadwerkelijke databestand die verwacht wordtdoor de externe Push Service. De externe Push Service is vervolgens in staat om met behulp vanhet bestand de juiste telefoon te adresseren met de juiste notificatie bericht. De telefoon ontvangtvervolgens de correcte notificatie, in dit geval dus het juiste berichtje.

Om het aanpassen van onze implementatie in de toekomst te vereenvoudigen hebben we veelvuldiginterfaces gebruikt in ons ontwerp. Het toevoegen van nieuwe implementaties van PushServices ende bijbehorende Notificaties en PushChannels wordt daardoor ook eenvoudiger. De Dispatcher-Client is niet op de hoogte van de daadwerkelijke implementatie en kent alleen de interface van dePushServices.

We maken gebruik van het factory design pattern om de creatie van objecten op een centrale locatieaf te handelen [2]. Hierdoor wordt het eenvoudiger om nieuwe implementaties van PushServicesin het systeem te koppelen. De DispatcherClient wordt door gebruik te maken van de PushServi-ceFactory ’dom’ gehouden over de daadwerkelijke implementatie van de PushService.

De implementatie van de PushService is verantwoordelijk voor het maken van de juiste Notificationobject. Dit object wordt meegegeven aan de PushChannel, die verantwoordelijk is voor decommunicatie met de externe Push Service. Beide instanties zijn gebonden aan een specifiekePushService, vandaar dat beide objecten met behulp van een factory method worden aangemaakt.Er is in dit geval niet gekozen voor een complete factory klasse, omdat beide objecten specifiek bijeen bepaalde PushService implementatie horen. Iedere PushService is dus in staat om de juisteimplementatie van de Notification en PushChannel aan te maken en te gebruiken.

De PushChannel is zoals gezegd verantwoordelijk voor de communicatie met de externe PushService die wordt aangesproken door het systeem. Via de PushChannel wordt de daadwerkelijkeNotificatie object verstuurd.

22

De MessageBrokerClient communiceert door middel van een DataAccessLayer met de database.Zodra een bericht voor een Topic binnenkomt zal de Broker de geabonneerde gebruikers in com-binatie met het bericht doorgeven aan de DispatcherClient.

De DispatcherClient zorgt ervoor dat de gebruikers toestellen, afhankelijk van hun OS, wordenbehandeld door de juiste PushService. Ieder OS maakt namelijk gebruik van een eigen specifiekePush Service. Met behulp van de PushServiceFactory worden de ondersteunde PushServicesaangemaakt om de notificatie daadwerkelijk te versturen naar de externe Push Service.

Figuur 3: Klasse-diagram op klasse-niveau.

23

6 Testplan

Om de kwaliteit van het eindproduct te garanderen is het van belang dat de implementatie goedis getest. Door het goed testen van de code kan er ook worden aangegeven dat de functionaliteitdie in de requirements document is opgesteld ook daadwerkelijk goed functioneert. Door gebruikte maken van geautomatiseerde unit tests kan er gedurende de levensloop van de implementa-tie controles worden uitgevoerd en daarmee garanties worden gegeven over de werking van decode.

Dit document zal aangeven welke maatregelen er getroffen worden om de code te testen. Ookzullen beperkingen worden aangegeven met betrekking tot niet-testbare onderdelen.

6.1 Automatische Tests

Door gebruik te maken van automatische tests wordt het eenvoudiger om na iedere build alle testste draaien en daarmee te garanderen dat alle functionaliteit nog steeds intact is. Het uitvoerenvan automatische test zullen wij aan de hand van unit test en andere statische tests doen.

6.2 Unit Tests

De implementatie zal getest worden door gebruik te maken van unit-tests en handmatige tests.Visual Studio beschikt intern over de mogelijkheid om unit-tests te draaien, die wij zullen gebrui-ken. Met behulp van unit-tests kan er gegarandeerd worden dat iedere methode en klasse naarbehoren blijft functioneren. Deze tests dienen uitgevoerd te worden na iedere build van de codeen alle tests moeten slagen voordat de code wordt “gecommit” naar de server. Dat betekent datde code commit geen build errors mag bevatten.

6.3 Statische Tests

Er zullen ook statische tests uitgevoerd worden om de kwaliteit van de code te waarborgen.In eerste instantie zal Visual Studio de meeste basis statische controles uitvoeren, zoals hetcontroleren of de juiste datatypes worden meegegeven. Verder zal er gebruik gemaakt wordenvan de Statische Analyse tool die in Visual Studio is ingebouwd. Deze tool zorgt voor informatieover de manier waarop de code is ontwikkeld en geeft aanbevelingen over hoe bepaalde zaken zoalsperformance, design en veiligheid verbeterd zouden kunnen worden. Deze plugin maakt gebruikvan de Design Guidelines 5 die door Microsoft zijn opgesteld om robuust en onderhoudbaar codemee te schrijven.

6.4 Handmatige Tests

De Android Demo App zal alleen aan handmatige tests onderworpen worden. Aan de hand van deopgestelde requirements (zie hoofdstuk 3) zal de Android client getoetst worden. De overige codezal ook aan handmatige tests onderworpen worden. Aan de hand van use cases die zijn opgesteld(zie hoofdstuk 4.1) zal de samenwerking tussen alle losse componenten worden getest.

5http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

24

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

6.5 Performance Tests

Gedurende het implementeren van het prototype zal er gebruik gemaakt worden van kleine setstestdata. Door gebruik te maken van kleine overzichtelijke sets data kan er eenvoudiger wordengecontroleerd of bepaalde functionaliteit naar behoren werkt. De data bestaat uit een gevuldedatabase met ten minste twee topics en twee gebruikers die beschikken over verschillende abonne-menten. De ene gebruiker is op beide topics geabonneerd en de ander alleen op eentje. Zo hebbenwe een topic waar twee gebruikers voor zijn geabonneerd en een ander waar er maar een gebruikervoor is geabonneerd. In tabel 1 vind u een voorbeeld van de testdata.

Users Topics SubscriptionsUser 1 Topic 1 (User 1 - Topic 1)User 2 Topic 2 (User 1 - Topic 2)- - (User 2 - Topic 2)

Tabel 1: Voorbeeld database testdata

Om inzicht te verkrijgen over de performance van de software zal er een gesimuleerde test plaats-vinden waarin de response tijd van de applicatie wordt gemeten. We zullen meten hoe lang hetduurt om batches varierend tussen de 10 en 1000 notificaties per keer te versturen. In dit gevalvullen we de database met 1000 testgebruikers. Iedere gebruiker beschikt over een enkele device.Vervolgens maken we vier topics aan. Ieder topic heeft een x aantal abonnees. De eerste topicheeft 1 abonnee, de tweede 10, de derde 100 en de vierde 1000. We versturen vervolgens viernotificatie berichten naar de vier verschillende topics. Tussen iedere aanroep wordt er gemetenhoe lang het duurt voordat de notificatie verzonden is. De resultaten zullen we presenteren inhoofdstuk 8.

Het versturen van test notificaties naar meerdere Android toestellen is gebonden aan de hoe-veelheid Android telefoons waarover wij kunnen beschikken. Wij kunnen indien nodig overtwee testtelefoons beschikken. Daarmee kunnen we testen of het versturen van notificaties naarmeerdere telefoons mogelijk is. De meeste tests zullen overigens gebruik maken van de AndroidSimulator 6.

6.6 Software Improvement Group

De Software Improvement Group (SIG) zal de code twee keer controleren gedurende de loop vanhet project. Eenmaal halverwege het project en andermaal aan het einde. De SIG zal de codedeels met de hand en deels met geautomatiseerde tools beoordelen op kwaliteit. De feedback vande SIG zal in principe over genomen worden en verwerkt worden in de implementatie. Indien datniet mogelijk is zal er in het eindverslag een verklaring daarvoor worden gegeven.

6http://developer.android.com/tools/help/emulator.html

25

http://developer.android.com/tools/help/emulator.html

7 Implementatie

De implementatie is gebaseerd op het technisch ontwerp, dat beschreven staat in hoofdstuk 5.Dit hoofdstuk zal een globaal overzicht geven van de uiteindelijke implementatie. Alle onder-delen waaruit het systeem bestaat zullen worden toegelicht en de werking ervan zal beschrevenworden.

7.1 Notification Trigger

Door middel van een demo website is het mogelijk om notificatie berichten te versturen. Dewebsite is geımplementeerd door gebruik te maken van een standaard ASP.NET MVC website 7.Met behulp van twee verschillende formulieren is het mogelijk om een bericht te versturen naariedereen die zich voor een Topic heeft geabonneerd of naar een individuele persoon, indien die ookheeft geabonneerd op de specifieke Topic.

Om het mogelijk te maken voor een Android Applicatie om zichzelf automatisch te registrerenop ons systeem, beschikt onze website ook over een ASP.NET Web-API 8. Door middel van httpaanroepen die gebruik maken van een JSON 9 formaat is het mogelijk voor onze Android demo-appom via het netwerk met het systeem te communiceren.

De website beschikt ook over een ASP.NET Web-API. Door middel van de API wordt het mogelijkvoor de Android demo-app om met het systeem te communiceren. De API maakt het mogelijkvoor een Android demo-app om een registratie sleutel in de database op te slaan. De demo-appkan daarmee ook zichzelf aan of afmelden voor een Topic.

Figuur 4: Screenshot Notification Trigger.

7http://www.asp.net/mvc8http://www.asp.net/web-api9http://www.json.org

26

http://www.asp.net/mvc

http://www.asp.net/web-api

http://www.json.org

7.2 Message Broker

De Message Broker communiceert met de database via de DataAccesLayer. De DataAccesLayermaakt vervolgens gebruik van het Entity-framework 10 (EF) van Microsoft. EF is een object-relational mapper, daarmee is het mogelijk om data die in een database is opgeslagen weer tegeven als een object. Hiermee is het mogelijk om met een database te communiceren, zonderdaadwerkelijk SQL queries te schrijven [3]. Door gebruik te maken van de Code-First conventies ishet mogelijk om de database in te richten door het database-model als object-georienteerde klassente implementeren. De EF zorgt er vervolgens voor dat de juiste tabellen worden aangemaakt. Hetwisselen van database is erg eenvoudig, men hoeft alleen in een configuratie bestand aan te gevenwelke database gebruikt moet worden. In codefragment 1 vind u een voorbeeld van een model datvolgens code-first conventies is opgesteld. De klasse komt overeen met een tabel in de Database.Relaties tussen andere klassen kunnen worden weergegeven door naar een ander model te verwijzenin je klasse, zoals we zien bij UserDevices.

Listing 1: Voorbeeld ORM model volgens code-first conventies.

public class User{

public int UserId { get ; s e t ; }public int UserName { get ; s e t ; }

public v i r t u a l I C o l l e c t i o n <UserDevice> UserDevices { get ; s e t ;}}

Zodra de broker de juiste gebruikers uit de database heeft ontvangen wordt de Dispatcher aange-roepen. De broker is namelijk niet op de hoogte van de verschillende soorten platforms die hetsysteem kan bedienen. De Dispatcher bezit deze kennis wel. In hoofdstuk 7.3 zullen wij er verderop ingaan.

7.3 Dispatcher

De taak van de Dispatcher is om de notificaties om te zetten in het platform specifieke formaatdat verlangd wordt van de push services. De Dispatcher is in staat om via een Enum typeautomatisch te controleren of een bepaalde push service wordt ondersteund. Zodra een nieuwtype wordt toegevoegd gaat de Dispatcher er automatisch vanuit dat de specifieke implementatieklaar is en gebruikt kan worden.

De Dispatcher is dus in staat om alle gebruikerstoestellen te sorteren naar ondersteunde pushservice om vervolgens de platform specifieke notificaties mee op te bouwen en uiteindelijk via hetjuiste kanaal de notificatie ook daadwerkelijk te versturen.

Zoals in hoofdstuk 3 staat beschreven is de Dispatcher in staat om notificaties naar Android toe-stellen te versturen door gebruik te maken van de Google Cloud Messaging (GCM) service.

Wij denken dat een programmeur met SSL en Socket kennis het systeem binnen anderhalve weekgereed zou kunnen maken om notificaties naar Apple toestellen te kunnen versturen. Het enigedat lastiger zal zijn is de SSL verbinding opzetten en onderhouden tussen het systeem en de Applepush service. Apple legt namelijk veel restricties op het opzetten van een verbinding [1].

10http://msdn.microsoft.com/en-us/data/ef.aspx

27

http://msdn.microsoft.com/en-us/data/ef.aspx

7.4 Android Demo App

De Android sample is een kleine Android app die beschikbaar is gesteld door Google. De app isvervolgens omgebouwd zodat het in staat is om notificaties van het systeem te kunnen ontvangenen weer te geven. Daarbij is de sample in staat om zichzelf automatisch bij de GCM service aan temelden en de ontvangen registratie sleutel meteen door te sturen naar onze notificatie applicatie,waar de registratie sleutel wordt gekoppeld aan de desbetreffende gebruiker. Vervolgens is degebruiker in staat om zich aan en af te melden voor een bepaalde Topic.

Figuur 5: Screenshot Android Notification Sample.

28

8 Requirements Evaluatie

In dit hoofdstuk evalueren we de eisen die we in hoofdstuk 3 hebben opgesteld. We zullen defunctionele en de niet-functionele eisen evalueren waarbij de verificatie samen met Exact zijnuitgevoerd.

8.1 Functionele Eisen

We evalueren in deze paragraaf de functionele eisen waarbij we aangeven in hoeverre we aan deeisen hebben voldaan. Voor elke eis geven we aan of deze wel (4) of niet (8) is geımplementeerd.We beschrijven ook hoe dit geımplementeerd is binnen ons systeem.


1. Must Have(a) Gebeurtenissen afvangen van een demo webapplicatie 4

(b) Verbinding opzetten tussen Notificatie Applicatie en Google Cloud Messaging (An-droid)

4

(c) Gebruikers ophalen behorend bij een bepaalde Topic 4

(d) Versturen van een persoonlijke notificatie 4

(e) Versturen van een groep notificatie 4

(f) Abonnementen toevoegen 4

(g) Abonnementen verwijderen 4

(h) Gebruiker toevoegen 4

(i) Verzoeken afvangen en verwerken van de Android Demo App 4

1. (a) Gebeurtenissen afvangen van een demo webapplicatieGebeurtenissen gegenereerd uit de Demo Webapplicatie worden afgevangen door deNotificatie Applicatie.

(b) Verbinding opzetten tussen Notificatie Applicatie en Google Cloud Messa-ging (Android)Deze functie is volledig geımplementeerd. Er wordt door de Notificatie Applicatie eenverbinding opgezet tussen de Notificatie Applicatie en de GCM server. De NotificatieApplicatie kan vervolgens berichten versturen via de GCM server.

(c) Gebruikers ophalen behorend bij een bepaalde TopicZodra een notificatie verstuurd wordt naar een bepaalde Topic wordt door de NotificatieApplicatie alle gebruikers opgehaald die op deze Topic hebben geabonneerd.

(d) Versturen van een persoonlijke notificatieDeze functie is geımplementeerd. Wanneer een persoonlijke notificatie wordt verstuurdnaar een bepaalde Topic wordt door de Notificatie Applicatie geverifieerd of de ontvan-ger is geabonneerd op de desbetreffende Topic. Zo ja dan wordt de notificatie verzondennaar de ontvanger anders wordt er geen notificatie verzonden. Een persoonlijke notifi-catie kan via ons Demo Webapplicatie verzonden worden.

(e) Versturen van een groep notificatieWanneer een groep notificatie wordt verstuurd naar een bepaalde Topic, dan krijgenalle gebruikers die zich hebben geabonneerd op deze Topic een notificatie. Een groepnotificatie kan via ons Demo Webapplicatie verzonden worden.

29

(f) Abonnementen toevoegenVia de Android Demo App kan bij de Notificatie Applicatie geabonneerd worden opeen Topic.

(g) Abonnementen verwijderenVia de Android Demo App kan bij de Notificatie Applicatie afgemeld worden van eenTopic, mits de gebruiker zich eerder heeft geabonneerd op deze Topic.

(h) Gebruiker toevoegenDe gebruiker kan via de Android Demo App zich registreren bij de Notificatie Applicatie.

(i) Verzoeken afvangen en verwerken van de Android Demo AppDe Notificatie Applicatie kan verzoeken afvangen en verwerken die afkomstig zijn vande Android Demo App. Na het ontvangen wordt de bijbehorende procedure gestart omhet verzoek af te handelen.

2. Should Have(a) Handmatig notificaties versturen 4

(b) Afmeldingen abonnement bijhouden 4

2. (a) Handmatig notificaties versturenVia de Demo Webapplicatie kan handmatig een persoonlijk bericht worden verstuurdnaar een gebruiker die voor een bepaald Topic heeft geabonneerd (persoonlijke no-tificatie) of er kan een bericht worden verstuurd naar alle mensen die zich hebbengeabonneerd op de betreffende Topic (groep notificatie).

(b) Afmeldingen abonnement bijhoudenDeze functie is geımplementeerd in het systeem. Wanneer een gebruiker zich afmeldtvan een Topic dan wordt het abonnement op inactief gezet. In de database is het danmogelijk om een lijst van afmeldingen op te vragen.

3. Could Have(a) Quality of Service 8(b) Gebeurtenissen afvangen voor de Exact Online webapplicatie 8

3. (a) Quality of ServiceDeze functionaliteit is niet geımplementeerd.

(b) Gebeurtenissen afvangen voor de Exact Online webapplicatieDeze functionaliteit is niet geımplementeerd.

4. Would/Won’t Have(a) Ondersteuning voor andere mobiele platformen 8

4. (a) Ondersteuning voor andere mobiele platformenHet uitbreiden naar andere platformen kan later worden toegevoegd indien bekend isom welke platformen het gaan. Dit kan dan als een extra module in ons Dispatchercomponent komen.

30


1. Must Have(a) Registreren van de Android Demo App 4(b) Notificaties ontvangen op de Android Demo App 4

1. (a) Registreren van de Android Demo AppVia de Android Demo App kan de gebruiker zich registreren bij de Notificatie Applicatie,waarbij hij vervolgens notificaties kan ontvangen als hij voor een bepaalde Topic heeftgeabonneerd.

(b) Notificaties ontvangen op de Android Demo AppDe Android Demo App kan berichten ontvangen die vanuit de notificatie server wordtverzonden en toont het bericht.

2. Should Have(a) Abonneren op een Topic 4(b) Afmelden voor een Topic 4

2. (a) Abonneren op een TopicVia de Android Demo App kan de gebruiker zich abonneren op een bepaalde Topic.

(b) Afmelden voor een TopicVia de Android Demo App kan de gebruiker zich afmelden voor een bepaalde Topic.Nadat de gebruiker is afgemeld van deze Topic krijgt hij geen notificaties meer binnenals er notificaties wordt verstuurd naar deze Topic.

3. Could Have(a) Opties voor aangemelde Topics aanpassen 8(b) Verwerk ontvangen notificatie 8

3. (a) Opties voor aangemelde Topics aanpassenDeze functionaliteit is niet geımplementeerd.

(b) Verwerk ontvangen notificatieDeze functionaliteit is niet geımplementeerd.

4. Would/Won’t Have(a) Profiel instellingen per mobiele telefoon 8

4. (a) Profiel instellingen per mobiele telefoonDeze feature kan later worden toegevoegd die geıntegreerd kan worden met een bestaandgebruikers database, zodat voor elk gebruiker bekend is welke andere mobiele apparatenhij nog geregistreerd heeft.

Na het uitvoeren van de requirements evaluaties blijkt dat alle must haves en should haves zijngeımplementeerd. Ons Notificatie Applicatie is hiermee voorzien van de kern functionaliteit.

31

8.2 Niet-Functionele Eisen

In deze paragraaf geven we aan in hoeverre we rekening hebben gehouden met de niet-functioneleeisen.

8.2.1 Uitbreidbaarheid

Aangezien alleen de Dispatcher op de hoogte is van de uiteindelijke implementaties van de nieuwepush services, zal het niet nodig zijn om in de rest van het systeem aanpassingen te maken. Zodraer nieuwe devices in de database voorkomen zullen ze automatisch verwerkt worden door hetsysteem. Ons architectuur maakt gebruik van interfaces en zorgt dus ervoor dat het toevoegenvan nieuwe platforms eenvoudig zal zijn.

8.2.2 Onderhoudbaarheid

Wij scoren volgens de Software Improvement Group (SIG) 4 van de 5 sterren die ze uitgevenvoor onderhoudbaarheid (zie bijlage E). We kunnen dus stellen dat onze implementatie zodanigin elkaar zit dat het goed onderhoudbaar is.

8.2.3 Betrouwbaarheid

We hebben een test uitgevoerd waarin we berichten sturen naar Topics waar respectievelijk 1, 10,100 en 1000 gebruikers zich voor hebben aangemeld. Per verstuurde bericht hebben we gemetenhoe lang het duurt voor ons systeem om de notificatie daadwerkelijk te versturen naar de externepush service. We hebben deze meting 100 keer uitgevoerd en het gemiddelde daarvan genomen.Zie tabel 2.

Topic #Abonnees Tijd (in ms)1 1 72 10 103 100 1324 1000 1012

Tabel 2: De tijdmeting voor het versturen van notificaties in milliseconden

We zien dat het versturen van 1000 berichten ongeveer 1 seconde duurt, waardoor we kunnenconcluderen dat het systeem in staat is om veel berichten in korte tijd te versturen.

32

9 Reflectie

Dit hoofdstuk bevat de persoonlijke reflectie verslagen van Edwin van den Houdt en ManWaiShing.

9.1 Edwin van den Houdt

Nu het bacheloreindproject bijna ten einde is gekomen durf ik te zeggen dat ik tevreden kanterugblikken op het resultaat van de afgelopen twaalf weken. Hoewel het een enorm stressvolletijd is geweest, heb ik er ook van kunnen genieten.

Er is niet een project geweest waarin vrijwel alle aspecten van Software Engineering in samen-komen. De meeste TU projecten hebben een duidelijk afgebakend doel, waardoor het vanaf hetbegin duidelijk is waar je project zal eindigen. Behalve de algemene beschrijving die door Exact opBlackboard is geplaatst, was er voor dit project eigenlijk niets van tevoren vastgesteld. Het trajectvan requirements opstellen vond ik daardoor erg uitdagend. De gesprekken die we met Eugenehebben gevoerd waren nuttig om het doel van het project duidelijker voor ogen te krijgen.

Aangezien het schrijven van documenten niet mijn sterkste punt is, heb ik daar helaas niet vankunnen genieten. Gelukkig was de feedback, van onze TU begeleider Cor-Paul, op onze draftserg duidelijk en streng, daardoor waren we instaat om alle documenten naar een hoger niveau tetillen.

Gesprekken met Cor-Paul waren tijdens de eerste helft van ons project erg nuttig om ons de juisterichting in op te sturen. Wij hadden namelijk gedurende het eerste deel van het project pechdat de Exact Online afdeling erg druk was met hun eigen deadlines. Hierdoor konden wij lastigantwoorden krijgen op technische vragen die wij tijdens het opstarten hadden. Problemen diebetrekking hadden op Visual Studio en de .NET omgeving waren waarschijnlijk minder proble-matisch geweest als we daar iemand over konden aanspreken. Gelukkig konden we in week drievan onze implementatie bij Peter terecht. Hij heeft ons vanaf toen goed ondersteund op technischgebied, vandaar dat we Peter uiteindelijk hebben gevraagd om officieel onze technische begeleiderte zijn.

Tijdens dit project ben ik er ook achtergekomen dat ik heel snel problemen overdenk. Daardoorwil ik heel snel bepaalde problemen oplossen die niet per se opgelost hoeven te worden. Gelukkigwist Peter me dan weer de goede richting in te sturen, door mij duidelijk te maken dat ik me op derequirements moet focussen. Hopelijk ben ik bij volgende projecten in staat om de focus beter terichten op de aangestelde requirements waardoor ik geen tijd verlies aan het oplossen van onnodigeproblemen. Overigens denk ik dat mijn stressniveaus daardoor ook veel lager zullen zijn.

Door uiteindelijk op de afdeling bij Peter te mogen zitten hebben we ook kunnen proeven van eenprofessionele werkomgeving. Dit vond ik erg leuk en het gaf het project een leuke extra dimensie.Na verschillende brainstormsessies en meetings hebben we ook een beeld gekregen van hoe datsoort zaken bij Exact wordt aangepakt.

Hoewel we er nog niet zijn kan ik met een opgeheven hoofd terug kijken op een voor mij geslaagdproject.

33

9.2 ManWai Shing

Vanaf het begin wist ik al dat bij het bachelorproject alle kennis die we tot nu toe hebben geleerdgetoetst zal worden. Maar het toepassen van alle kennis in een bedrijfsopdracht is voor mij weereen geheel nieuwe uitdaging. Dat was te merken aan het begin van het project.

Bij het begin van het project moesten we vaststellen wat wij precies voor het bedrijf dienen tedoen. Aangezien de opdrachtomschrijving niet concreet is opgesteld gaf dit ons de gelegenheid ommeer eigen inbreng te geven, wat het een stuk uitdagender maakt. Maar tegelijkertijd werd het ookeen stuk lastiger, omdat we moeten inschatten of ons idee haalbaar is binnen onze planning.

Tijdens het uitvoeren van dit project heb ik gemerkt dat samenwerken de kern is tot het voltooienvan veel taken. Je leert altijd van anderen zelfs als je al bekend bent met het onderwerp. Eengoede samenwerking zorgt voor een prettige werksfeer, bij ons was dit ook het geval tijdensde implementatie. Het is fijn om te weten dat er mensen zijn om je heen die je graag willenhelpen.

De feedback die we tijdens onze documentatie review hebben gehad van onze TU begeleider vondik zeer leerzaam. Vooral omdat ik niet zo goed ben in Nederlands heeft dit mij geholpen, want hetgoed kunnen opschrijven van ideeen is al een kunst op zichzelf. Ook de adviezen en de “know-hows”die we hebben gekregen tijdens het uitvoeren van ons project bij Exact, waren erg waardevol. Hetzijn dingen die we niet zomaar uit de boeken kunnen halen.

Natuurlijk heb ik ook fouten gemaakt tijdens dit project. Fouten waarvan ik heb kunnen leren.Immers je onthoudt het beter als je iets een keer verkeerd hebt gedaan. Maar het is het waard alsje uiteindelijk een werkend product ziet. Ik kijk er naar uit om mijn kennis die ik heb opgedaantijdens de uitvoering van dit project te gebruiken en verder uit te breiden in de toekomstigeprojecten.

34

10 Conclusie

Voor dit bachelorproject hebben we onderzoek gedaan naar het versturen van mobiele notificaties.Exact richt zich de laatste jaren ook op het ontwikkelen van mobiele apps, die op het Android ofiOS platform werken. De mogelijkheid om ten alle tijden notificaties te kunnen versturen naareen mobiele applicatie kan cruciaal zijn voor een goede gebruikerservaring. Bepaalde applicatieshebben er baat bij om real-time te kunnen communiceren met hun mobiele applicatie en daarmeedirect nieuwe informatie met de gebruiker te kunnen delen. Daarom is het voor Exact interessantom de mogelijkheden te bekijken die eventueel in de toekomst geıntegreerd kan worden in haarmobiele apps.

We hebben een notificatie systeem geımplementeerd, dat als een “proof of concept” dient. Hetsysteem bestaat uit een Notificatie Applicatie en een Android Demo App. De Notificatie Applicatieis in staat om gebeurtenissen af te vangen en een notificatie te verzenden. Terwijl de Android DemoApp zich kan registreren en de verstuurde notificatie kan ontvangen en weergeven. Hiermee hebbenwe een volledige cirkel gemaakt van het verzenden van een notificatie naar de gebruiker tot hetontvangen van de notificatie.

Vanwege de beperkte ontwikkeltijd is gekozen voor het ontwikkelen van een notificatie systeemdat in eerste instantie de focus legt op het Android platform. Maar het prototype zal flexibelzijn zodat het toevoegen van andere platformen eenvoudig is. Enkel het toevoegen van een pushservice implementatie van het specifiek platform binnen de Dispatcher zal genoeg zijn om eennieuw mobiel platform te ondersteunen voor het versturen van een notificatie.

Aan het begin van dit project hebben we als onderzoeksvraag:


Het antwoord op de hoofdvraag hebben we gegeven door het implementeren van ons notificatiesysteem. Puur afgaand op de “requirements evaluatie” zijn we geslaagd in het bereiken van deeisen die we aan het begin van dit project gesteld hebben. Hiermee hebben we met ons prototypelaten zien wat er allemaal bij komt kijken indien een notificatie systeem ontwikkeld moet wordendat gebeurtenissen gegenereerd door een webapplicatie verwerkt.

We hopen dat Exact ons prototype kan gebruiken om verder onderzoek te kunnen doen naar hetversturen van mobiele notificatie. En we wensen ze nog veel succes in de toekomst.

35

Referenties

[1] Apple. About local notifications and push notifications. http://developer.

apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/

RemoteNotificationsPG/Introduction.html/, 2013. [Online; geraadpleegd 29-april-2013].

[2] Microsoft. Exploring the factory design pattern. http://msdn.microsoft.com/en-us/

library/ee817667.aspx, 2013. [Online; geraadpleegd 6-meil-2013].

[3] Wikipedia. Object-relational mapping. https://en.wikipedia.org/wiki/

Object-relational_mapping, 2013. [Online; geraadpleegd 24-juli-2013].

36

http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html/



http://msdn.microsoft.com/en-us/library/ee817667.aspx

http://msdn.microsoft.com/en-us/library/ee817667.aspx

https://en.wikipedia.org/wiki/Object-relational_mapping

https://en.wikipedia.org/wiki/Object-relational_mapping

A Plan van Aanpak

37




Plan van Aanpak



Eugene Pattikawa (Exact)

Delft, 4 mei 2013

Voorwoord

Dit document vormt het Plan van Aanpak dat hoort bij het Bachelorproject dat door ManWaiShing en Edwin van den Houdt zal worden uitgevoerd. In het Plan van Aanpak zal duidelijkworden welk probleem er gedurende het project zal worden opgelost. Er wordt vastgelegd welkeverantwoordelijkheden de opdrachtgever en de projectleden hebben. Bovendien zal er een beschrij-ving gegeven worden over hoe het project gefaseerd zal worden en overige afspraken worden ookvastgelegd.

1

Samenvatting

Dit is het Plan van Aanpak voor de Bachelorproject voor de opleiding Technische Informaticaaan de TU Delft. De opdrachtgever voor het project is Exact. De opdrachtgever biedt webapplicaties aan die zakelijke activiteiten ondersteunen. Om met de huidige trend van smartphonesen dus mobiele applicaties mee te gaan, hebben ze ook een eigen mobiele applicatie ontwikkeld.De mobiele applicatie geeft de gebruikers de mogelijkheid om gegevens in te zien die via de webapplicatie zijn ingevoerd.

De opdrachtgever wil graag de mogelijkheid hebben om notificaties te versturen naar de mobielegebruikers op basis van gebeurtenissen in hun web applicatie. Het versturen van notificaties gaatop grond van gebeurtenissen die gegenereerd worden vanuit de webapplicatie. Een voorbeeldhiervan is het bijhouden van uren registratie. Voor bepaalde gebruikers is het mogelijk om deuren registratie in de webapplicatie bij te houden. In het geval een gebruiker vergeten is omzijn uren te registreren, kan daar een herinnerings-gebeurtenis voor worden gegenereerd. Aande hand van zo een gebeurtenis zal er een notificatie (herinnering) verstuurd worden naar dedesbetreffende gebruiker die zich voor deze notificatie Topic heeft aangemeld. Een Topic is eennotificatie categorie waar een gebruiker zich op kan abonneren.

Tijdens dit project zal met een duur van 3 maanden een “proof of concept” worden gerealiseerdvan een notificatie systeem. Dit prototype zal bestaan uit de volgende componenten:



Verder worden in dit Plan van Aanpak de eisen en verwachtingen van de opdrachtgever en hetprojectteam behandeld. Het product zal ontwikkeld worden volgens de AGILE methode. Dithoudt in dat er iedere week een applicatie opgeleverd dient te worden die werkt en getest is. Eenander bijkomend voordeel van deze ontwikkelmethode is dat eventuele veranderingen in de eisenopgevangen kunnen worden.

Betrokken personen zijn:

Eugene Pattikawa - vertegenwoordiger van de opdrachtgever

Cor-Paul Bezemer - projectbegeleider namens de TU Delft

Edwin van den Houdt - student Technische Informatica

ManWai Shing - student Technische Informatica

2

Na afronding van het project zullen de volgende producten worden opgeleverd:

Orientatieverslag

Plan van Aanpak

Requirements en Analysis Document

Functional Design Document

Technical Design Document

Testplan

Implementatie (prototype Notificatie Systeem)

Feedback SIG

Eindverslag inclusief reflectie

Geleerde/bestudeerde technieken

3

Inhoudsopgave

Voorwoord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1 Introductie 5

2 Project opdracht 62.1 Projectomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Doelstelling project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Opdrachtformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Op te leveren producten en diensten . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Eisen en beperkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6 Voorwaarden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Aanpak en tijdsplanning 83.1 Orientatiefase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Ontwerpfase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Implementatiefase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.4 Testfase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.5 Afrondingsfase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.6 Tijdsplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Projectinrichting 104.1 Organisatie en personeel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Financiering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Rapportering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.4 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Kwaliteitsborging 11

A Tijdsplanning 12

4

1 Introductie

Exact is een Nederlands softwarebedrijf dat in 1984 is opgericht. Ze bieden oplossingen aan die allebelangrijke zakenprocessen ondersteunen voor het midden- en kleinbedrijf. Ze ontwikkelen cloud-georienteerde oplossingen en maatwerk voor industrieen als accountancy, retail en professionelediensten en fabricage.

Sinds een paar jaar richt Exact zich ook op het ontwikkelen van mobiele apps, die werken opAndroid of iOS. Met behulp van deze apps kunnen ze een betere dienst aanbieden voor klantendie een beter real-time inzicht willen van hun zakelijke activiteiten. Om deze activiteiten nogbeter in real-time te kunnen monitoren is het van belang dat de apps uitgerust worden met demogelijkheid om notificaties te kunnen ontvangen. In onze orientatiefase hebben we onderzochtwelke eisen en technische implicaties er zijn verbonden aan het implementeren van zo een mobielnotificatie systeem. Dit is in detail terug te lezen in ons Orientatieverslag.

Dit document zal inzicht geven in de doelstelling van het project en uitleg geven over welkemaatregelen getroffen worden om het project te laten slagen. Als er uiteindelijk wordt afgewekenvan dit Plan van Aanpak, dan zal dat in het eindverslag toegelicht worden.

Het document zit als volgt in elkaar. In hoofdstuk 2 zal het project in detail worden beschreven.Hoofdstuk 3 zal vervolgens ingaan op de aanpak van de probleemstelling en een tijdsplanningpresenteren. Daarna zal er in hoofdstuk 4 ingegaan worden op de projectinrichting. Hier krijgenwe inzicht in de administratieve kant van het project. Als laatste zal hoofdstuk 5 ons inzicht gevenover de maatregelen die worden getroffen om de kwaliteit van het project te waarborgen.

5

2 Project opdracht

In dit hoofdstuk beschrijven we het project, de producten die opgeleverd moeten worden en welkeeisen en beperkingen we stellen aan dit project.

2.1 Projectomgeving

De opdrachtgever heeft verschillende webapplicaties ontwikkeld waar klanten zich op kunnen abon-neren. Ze hebben voor de iOS en Android platformen elk een mobiele applicatie gemaakt diegegevens gebruikt uit hun webapplicaties. De mobiele applicatie dient momenteel meer als eengebruiksvriendelijke tool om de klanten de mogelijkheid te bieden via hun mobiel bij hun gegevenste komen. Er is nog geen sprake van notificaties die real-time de gebruikers op de hoogte houdenvan hun zakelijke activiteiten.

2.2 Doelstelling project

Het doel van het project is om een notificatie systeem op te zetten waarmee “alerts” en notificatiesverstuurd kunnen worden vanuit zakelijke applicaties in de cloud, naar (applicaties/toestellenvan) mobiele gebruikers. Gebruikers van deze mobiele applicaties moeten in staat zijn om dezenotificaties te ontvangen. Het versturen van notificaties gaat op grond van gebeurtenissen diegegenereerd worden vanuit de webapplicatie. Een voorbeeld hiervan is het bijhouden van urenregistratie. Voor bepaalde gebruikers is het mogelijk om de uren registratie in de webapplicatiebij te houden. In het geval een gebruiker vergeten is om zijn uren te registreren, kan daar eenherinnerings-gebeurtenis voor worden gegenereerd. Aan de hand van zo een gebeurtenis zal ereen notificatie (herinnering) verstuurd worden naar de desbetreffende gebruiker die zich voor dezenotificatie Topic heeft aangemeld. Een Topic is een notificatie categorie waar een gebruiker zichop kan abonneren.

2.3 Opdrachtformulering

In dit project wordt een prototype van het notificatie platform gerealiseerd waarmee notificatiesverstuurd kunnen worden naar mobiele applicatie gebruikers. Dit prototype zal bestaan uit devolgende componenten:



6

2.4 Op te leveren producten en diensten

Na afronding van het project zullen de volgende producten worden opgeleverd:

• Orientatieverslag

• Plan van Aanpak

• Requirements en Analysis Document

• Functional Design Document

• Technical Design Document

• Testplan

• Implementatie (prototype Notificatie Systeem)

• Feedback SIG

• Eindverslag inclusief reflectie

• Geleerde/bestudeerde technieken

2.5 Eisen en beperkingen

Het uiteindelijke product zal bestaan uit de componenten zoals beschreven in paragraaf 2.3 endient als een “proof of concept”. Het prototype moet het mogelijk maken om gebeurtenissen op tevangen van de webapplicatie en deze vervolgens om te zetten naar notificaties. Deze notificatiesmoeten uiteindelijk ontvangen worden op het mobiele apparaat.

De notificatie mogelijkheid zal in eerste instantie gericht worden op het Android platform. Voorhet iOS platform is voor de ontwikkeling een developer license nodig die we tijdens het projectniet tot onze beschikking hebben. Maar het prototype zal flexibel zijn zodat het toevoegen vanandere platformen eenvoudig is.

2.6 Voorwaarden

De projectleden dienen aan de hand van de “Eisen en beperkingen” in paragraaf 2.5 de produc-ten op te leveren die vermeld staan onder “Op te leveren producten en diensten” in paragraaf2.4.

De opdrachtgever ondersteunt de projectleden voor de levering van de benodigde bronnen terbehulp van de ontwikkeling van de producten.

De projectleden hebben per week een gesprek met de projectbegeleider dat als controlepunt vande projectstatus dient.

7

3 Aanpak en tijdsplanning

Dit hoofdstuk zal inzicht geven in de fases die de projectleden zullen doorlopen. Per fase wordtaangegeven welke activiteiten er verricht moeten worden. In bijlage A staat een gedetailleerdetijdsplanning, waarop per week te zien is welke activiteiten afgerond moeten worden.

3.1 Orientatiefase

In de orientatiefase is er onderzoek gedaan naar de eisen en technische implicaties die verbondenzijn aan het implementeren van een server en client applicatie voor het versturen van mobielenotificaties. Het onderzoek zal gebruik maken van bronnen op het internet, papers en eventueelboeken uit de bibliotheek. Het resultaat hebben we beschreven in het Orientatieverslag. Uithet onderzoek blijkt dat notificaties versturen met push meer voordelen biedt dan pull. De iOSen Android platformen beschikken beide over hun eigen Push Server Notificatie systemen, diewe kunnen gebruiken voor het implementeren van ons prototype. Als architectuur zal gekozenworden voor een event-driven messaging architectuur. Momenteel gaat ons voorkeur uit naar hetPublish/Subscribe model. Aan het einde van onze orientatiefase leveren we het Orientatieverslagen het Plan van Aanpak op.

3.2 Ontwerpfase

Tijdens de ontwerpfase wordt een start gemaakt met vier documenten, namelijk het RequirementsAnalysis Document (RAD), Functional Design Document (FDD), Technical Design Document(TDD), en een Testplan. Aan het einde van deze fase dienen de documenten af te zijn. Aan dehand van deze documenten wordt het op abstract niveau duidelijk hoe het project daadwerkelijkgeımplementeerd kan worden. In het RAD zal met behulp van het MoSCoW1 model wordenbeschreven aan welke eisen het systeem moet voldoen en tevens worden de prioriteiten aangegeven.Nadat de eisen bekend zijn kan met behulp van het FDD een beeld worden geschetst over dewerking van de features. Aan de hand van UML-diagrammen zal op abstract niveau duidelijkworden hoe het systeem in elkaar gezet gaat worden. Vervolgens bepalen we in het TDD dearchitectuur van het systeem. Uiteindelijk zullen we met behulp van het Testplan beschrijven hoehet systeem getest zal worden om te toetsen of het voldoet aan de gestelde eisen.

3.3 Implementatiefase

Tijdens de implementatiefase zal aan de hand van de RAD, FDD en TDD daadwerkelijk codeworden ontwikkeld. Voor de server kant zal er gebruik gemaakt worden van het .NET framework enals ontwikkelomgeving zal Visual Studio gebruikt worden. De client kant (Android) zal ontwikkeldworden in Java met behulp van Eclipse IDE. Na afronding van deze fase zal er een werkendeprototype af zijn van het systeem. Tijdens de implementatie wordt gebruik gemaakt van AgileDevelopment. Dit houdt in dat er iedere week een applicatie opgeleverd dient te worden diewerkt en getest is. Een ander bijkomend voordeel van deze ontwikkelmethode is dat eventueleveranderingen in de eisen opgevangen kunnen worden.

1https://en.wikipedia.org/wiki/MoSCoW_Method

8

3.4 Testfase

Gedurende de testfase zal de implementatie uitbundig getest worden aan de hand van het Testplan.In deze fase wordt de code voor het eerst opgestuurd naar de Software Improvement Group (SIG).Aan de hand van de feedback van de SIG kunnen wij conclusies trekken over de kwaliteit van decode. Aanbevelingen worden na ontvangst verwerkt.

3.5 Afrondingsfase

Tijdens de afrondingsfase zal het Eindverslag met de bevindingen van dit project opgesteld worden.Zodra alle aanbevelingen van de SIG zijn doorgevoerd zal de code opnieuw worden opgestuurdvoor de eindevaluatie. Vervolgens zal het project worden afgesloten met een presentatie waarinhet project wordt tentoongesteld.

3.6 Tijdsplanning

In bijlage A is de tijdsplanning weergegeven. Daarin wordt per week aangegeven welke takengedaan dienen te worden en in welke fase van het project we ons bevinden. In week 25 is minderwerk ingepland om ruimte te geven voor voorbereidingen van eventuele herkansingen in de ten-tamenweek daarna. Er is vervolgens ruim tijd genomen ter afronding van alle verslagen en hetprototype.

9

4 Projectinrichting

Het doel van projectinrichting is het zichtbaar maken van de wijze waarop de projectmanager vanplan is het project in te richten om de opdracht uit te voeren volgens de voorgestelde aanpak. Devolgende punten zullen daar onderdeel van zijn. Ook andere afspraken over de projectinrichtingworden hier opgenomen.

4.1 Organisatie en personeel

Het projectteam bestaat uit twee personen, Edwin van den Houdt en ManWai Shing. Beide ledenzijn verantwoordelijk voor het succesvol afronden van het project. Een ieder dient evenveel tijd teinvesteren in de documentatie en daadwerkelijke implementatie van het project. Daarbij dienende projectleden zichzelf in te lezen in technieken die ze nog niet kennen vanuit de opleiding. Deprojectleden ontvangen directe begeleiding vanuit de TU Delft van Cor-Paul Bezemer. VanuitExact zal Eugene Pattikawa de begeleiding verzorgen.

4.2 Financiering

Voor het project zijn geen financieringsmogelijkheden. Alle onderdelen dienen ontwikkeld te wor-den op bestaande systemen. Er is dus geen ruimte om software/hardware aan te schaffen voor hetproject.

4.3 Rapportering

De communicatie met de opdrachtgever loopt voornamelijk via de email. Rapporten worden tenalle tijden in pdf formaat aangeleverd. De projectleden zullen alle rapporten in LaTeX2 schrijven.Om ervoor te zorgen dat rapporten altijd naar een originele staat terug gebracht kunnen wordenna veranderingen zal er gebruik gemaakt worden van Git3 en als remote repository zal gebruikgemaakt worden van Github4. De programma code zal ook gebruik maken van Git, wel zal deremote repository op de Team Foundation Service5 (TFS) worden ondergebracht. Los van deschriftelijke communicatie zullen de projectleden wekelijks met de begeleiders samen komen om teoverleggen hoe de voortgang ervoor staat.

4.4 Resources

In verband met toegang krijgen tot de juiste broncode en ontwikkel omgeving zal onderzochtworden of de projectleden een laptop kunnen ontvangen van Exact gedurende het project. Indiendat niet het geval is zullen de projectleden gebruik maken van hun eigen laptops. Er is bij Exactin principe geen vaste werkplek voor ons aanwezig, de projectleden dienen zich flexibel in te stellenen wellicht in de kantine te werk te gaan.

2http://www.latex-project.org3http://git-scm.com4http://www.github.com5http://tfs.visualstudio.com

10

5 Kwaliteitsborging

De kwaliteit van het project kan worden gewaarborgd door het projectteam als de opdrachtgever.Beide partijen dienen aandacht hieraan te besteden om de kwaliteit te verhogen. We zullenhieronder aangeven hoe beide partijen de kwaliteit van het project kunnen beınvloeden.

Projectteam:

• Tussentijdse feedback op rapportages van projectbegeleider en opdrachtgever verwerken.

• Beoordelen van elkaars implementatie. Door elkaars code te bekijken kunnen de projectledenvan elkaar leren, fouten verbeteren en elkaar aanvullen.

• Best practices en conventies. Door best practices en conventies aan te houden is de codebeter te begrijpen en te onderhouden. Fouten kunnen hierdoor ook verminderd worden.

• Aanbevelingen van SIG verwerken. Tijdens het project wordt de implementatie code naarSIG gestuurd ter beoordeling. Door de aanbevelingen te verwerken kunnen de projectledende kwaliteit van de code verhogen.

• Gebruik maken van ontwikkelomgeving. Door gebruik te maken van ontwikkelomgevingwordt de implementatie vereenvoudigd en daarmee de kans op fouten verkleind.

• Gebruik maken van een Version Control System voor programmering. Hierdoor is het mo-gelijk om aanpassingen te volgen en eventueel terug te trekken bij problemen. Dit bevordertde samenwerking tussen projectleden.

Opdrachtgever:

• Eisen en verwachtingen duidelijk verwoorden. Indien de eisen en verwachtingen helder zijnverwoord, kan het resultaat beter aansluiten.

• Tussentijdse voortgang evaluatie. Als de opdrachtgever periodiek de voortgang in de gatenhoudt is de kans op uitloop of problemen kleiner.

• Tussenproducten valideren. Indien de opdrachtgever periodiek de tussenproducten valideert,is de kans op een aansluitende eindproduct groter.

11

A Tijdsplanning

Week - datum Fase Deliverables Beschrijving

16 - (17-04-2013) - - Kennismaken Exact en inzicht verkrijgen in op-dracht.

17 - (22-04-2013 t/m 26-04-2013) Orientatie Concreet opdracht omschrijving Opdracht beter uitwerken en eisen en beperkingen inbeeld krijgen. Relevante papers opzoeken

18 - (29-04-2013 t/m 03-05-2013) Orientatie - Probleem analyse. Enquete afnemen. Literatuuron-derzoek afronden

19 - (06-05-2013 t/m 10-05-2013) Ontwerp Orientatieverslag + Plan van aanpak Starten met RAD, FDD, TDD en Testplan20 - (13-05-2013 t/m 17-05-2013) Ontwerp + Implementatie RAD + FDD + TDD + Testplan Afronden documentatie en start maken met Imple-

mentatie21 - (20-05-2013 t/m 24-05-2013) Implementatie - implementeren22 - (27-05-2013 t/m 31-05-2013) Implementatie - implementeren23 - (03-06-2013 t/m 07-06-2013) Implementatie Prototype prototype af24 - (10-06-2013 t/m 14-06-2013) Test Code naar SIG Code integreren met Exact codebase25 - (17-06-2013 t/m 21-06-2013) - Aanbeveling van SIG ontvangen (Witteweek)26 - (24-06-2013 t/m 28-06-2013) Implementatie + Test Concept eindverslag Feedback verwerken27 - (01-07-2013 t/m 05-07-2013) Afronding Eindcode naar SIG Afronding eindverslag + werken aan presentatie28 - (08-07-2013 t/m 12-07-2013) Afronding Presentatie presenteren

12

B Orientatieverslag

51




Orientatieverslag



Eugene Pattikawa (Exact)

Delft, 7 mei 2013

Samenvatting

In dit orientatieverslag doen we verslag van ons vooronderzoek naar het verzenden van mobielenotificaties. De focus van ons onderzoek hebben we gelegd op de volgende vraag:


Ter behulp van onze onderzoeksvraag maken we gebruik van de volgende deelvragen:

Deelvraag 1:Wat zijn de verschillen tussen en de voor- en nadelen van de pull en push techniek?

Deelvraag 2:Wat zijn de mogelijkheden op de huidige mobiele platformen met betrekking tot notificatie-systemen?

Deelvraag 3:Welke event-driven messaging architecturen bestaan er die geschikt zijn voor een notificatie-systeem?

Uit ons onderzoek is gebleken dat het verzenden van notificaties via push techniek de meestevoordelen biedt tegenover de pull techniek. De iOS en Android platformen beschikken beide overhun eigen Push Server Notificatie systemen, die we kunnen gebruiken voor het implementeren vanons prototype. Als architectuur zal gekozen worden voor een event-driven messaging architectuur.Momenteel gaat ons voorkeur uit naar het Publish/Subscribe model dat het meeste aansluit oponze verwachting van het te implementeren systeem.

1

Inhoudsopgave

Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Inleiding 3

2 Probleemstelling 4

3 Push vs Pull 63.1 Pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.1 Simulatie Push via Pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2.2 Universele Push Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Mobiele Platforms 84.1 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1.1 Apple Push Notification Server (APNS) . . . . . . . . . . . . . . . . . . . . 84.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2.1 Google Cloud Messaging (GCM) . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Event-Driven Messaging 145.1 Event-Driven Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.2 Publish/Subscribe model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Conclusie 17

Referenties 18

2

1 Inleiding

Middels dit orientatieverslag willen wij inzicht verkrijgen in de mogelijke technieken die van paskunnen zijn voor het opzetten van een platform waarmee notificaties verstuurd kunnen wordennaar mobiele gebruikers van Exact. De mogelijkheid om ten alle tijden notificaties te kunnenversturen naar een mobiele applicatie kan cruciaal zijn voor een goede gebruikerservaring. Bepaaldeapplicaties hebben er baat bij om real-time te kunnen communiceren met hun mobiele applicatieen daarmee direct nieuwe informatie met de gebruiker te kunnen delen.

Om ten alle tijden notificaties te kunnen versturen naar mobiele applicaties is een persistenteverbinding nodig tussen de applicatie en een server die de notificatie verstuurt. De iOS en Androidplatformen beschikken over hun eigen Push Server Notificatie systemen waarmee het mogelijk isom via een persistente verbinding een notificatie naar een mobiele telefoon te versturen, waarvande applicatie niet per se is geopend.

De notificatie systemen van zowel iOS als Android zullen onderzocht worden om inzicht te verkrij-gen in welke protocollen dan wel voorwaarden gesteld worden aan het gebruik daarvan. Verderzal er gekeken worden naar bestaande oplossingen voor het versturen van notificaties en wordende voor- en nadelen daarvan uiteengezet.

Bij dit onderzoek zal rekening gehouden worden met het uiteindelijke doel van het Bachelor eind-project, namelijk het ontwikkelen van een software product. Ons eindproduct zal bestaan uit devolgende componenten:



Dit document zit als volgt in elkaar. In hoofdstuk 2 beschrijven we onze probleemstelling. Hierwordt omschreven wat we in dit rapport willen onderzoeken. In hoofdstuk 3 kijken we naar deverschillen tussen en de voor- en nadelen van de Pull en Push techniek. In hoofdstuk 4 beschrijvenwe de mobiele platforms op het gebied van notificatiesystemen. Het onderzoeken van de Event-Driven Messaging architecturen doen we in hoofdstuk 5. Tot slot geven we onze conclusie inhoofdstuk 6.

3

2 Probleemstelling

Exact1 is een Nederlands softwarebedrijf dat in 1984 is opgericht. Ze bieden oplossingen aan diealle belangrijke zakenprocessen ondersteunen voor het midden- en kleinbedrijf. Ze ontwikkelencloudgeorienteerde oplossingen en maatwerk voor industrieen als accountancy, retail en professio-nele diensten en fabricage.

Exact wil graag de mogelijkheid hebben om notificaties te kunnen versturen naar de gebruikersvan hun mobiele applicaties. Het versturen van notificaties gaat op grond van gebeurtenissen diegegenereerd worden vanuit de webapplicatie. Een voorbeeld hiervan is het bijhouden van urenregistratie. Voor bepaalde gebruikers is het mogelijk om de uren registratie in de webapplicatiebij te houden. In het geval een gebruiker vergeten is om zijn uren te registreren, kan daar eenherinnerings-gebeurtenis voor worden gegenereerd. Aan de hand van zo een gebeurtenis zal ereen notificatie (herinnering) verstuurd worden naar de desbetreffende gebruiker die zich voor dezenotificatie Topic heeft aangemeld. Een Topic is een notificatie categorie waar een gebruiker zichop kan abonneren.

Het moet mogelijk zijn om eenvoudig verschillende soorten notificaties te versturen die door hetsysteem automatisch worden gegenereerd aan de hand van gebeurtenissen. Het versturen vande notificaties zal eventueel ook handmatig kunnen via een administratie paneel. Bijvoorbeeldnotificaties die verstuurd worden om technische redenen (onderhoud) of voor marketing doeleinden(bijvoorbeeld nieuwe features kenbaar maken).

In dit document doen wij verslag van ons onderzoek naar de mogelijkheden voor het versturenvan dergelijke notificaties. Tijdens ons onderzoek hebben we de focus gelegd op de volgendevraag:


In dit document doen we verslag van ons orienterend onderzoek naar het antwoord op deze on-derzoeksvraag. Ter ondersteuning van onze onderzoeksvraag zullen we gebruik maken van devolgende deelvragen.

Deelvraag 1: Wat zijn de verschillen tussen en de voor- en nadelen van de pull en push tech-niek?Om notificaties te versturen kan er gebruik gemaakt worden van pull en/of push technie-ken. We bekijken deze twee technieken om te bepalen welke geschikt kan zijn voor hetnotificatiesysteem.

Deelvraag 2: Wat zijn de mogelijkheden op de huidige mobiele platformen met betrekking totnotificatiesystemen?Naast de gebruikte technieken is de manier waarop notificaties verstuurd worden ook afhan-kelijk van de gebruikte mobiele platformen. Op dit moment zijn de meest gebruikte plat-formen iOS, Android en Windows Mobile [11]. Door de genoemde platformen te bekijkenkunnen we inzicht verkrijgen over de mogelijkheden met betrekking tot het notificatiesys-teem.

Deelvraag 3: Welke event-driven messaging architecturen bestaan er die geschikt zijn voor eennotificatiesysteem?Er bestaan verschillende software architecturen, maar niet elke architectuur is even geschiktom een notificatie systeem mee te ontwikkelen. Voor het notificatiesysteem is het onderandere van belang dat gebeurtenissen afgehandeld kan worden en gebruikers zich kunnenaan- en afmelden voor notificaties.

1http://www.exact.nl

4

Na onze orientatie willen we een prototype maken van een notificatiesysteem. Dit systeem zalbestaan uit de volgende componenten:



5

3 Push vs Pull

Om notificaties te versturen kan er gebruik gemaakt worden van pull en/of push technieken. Wijzullen het verschil tussen beide technieken uitleggen. Beide technieken worden gebruikt om com-municatie tussen een client en een server te verwezenlijken. Het verschil zit uiteraard in de manierwaarop dat gebeurt. Als er sprake is van pull, dan zal de client zelf regelmatig informatie van deserver opvragen (pullen). In het geval van push zal de server juist de client op de hoogte houdenvan veranderingen (pushen), zonder dat de client daar expliciet om moet vragen [5, 6].

3.1 Pull

Het pull model is gebaseerd op het request/response paradigma, ook wel data polling of gewoonpolling genoemd [13]. In dit model verstuurt de client een verzoek naar de server en de serverreageert daar synchroon of asynchroon op. Deze manier van communiceren komt er dus op neerdat de client informatie van de server moet trekken (pullen). Verder geldt voor een pull modeldat alle interactie tussen de client en de server, alleen door de client wordt geınitieerd. Hetzelfdegeldt ook voor het huidige opzet van het web, het HTTP protocol maakt namelijk gebruik vaneen pull model [5]. Dat is dan ook de reden waarom het niet triviaal is om gebruik te maken vanpush communicatie op het web. In paragraaf 3.2.1 zullen we uitleggen hoe het mogelijk is om metbehulp van pull technieken, gesimuleerde push communicatie tot stand te krijgen.

3.2 Push

Met behulp van push is het mogelijk om berichten naar een client te sturen zonder dat de clientdaar om heeft gevraagd [5]. Een groot voordeel hiervan is dat het eenvoudiger wordt om real-timecommunicatie tussen client en server te verwezenlijken, zonder dat de client daar actief naar moetpollen. Door het gebruik te maken van push kan er CPU last van de client deels overgenomenworden door de server [13]. Ook kan er daardoor minder bandbreedte gebruikt worden op hetnetwerk. In het geval van clients die op mobiele telefoons draaien, kan het gebruik maken vanpush betekenen dat de accu langer meegaat, aangezien de processor niet constant verbinding hoeftte maken met een of meerdere servers.

3.2.1 Simulatie Push via Pull

Het is mogelijk om push te simuleren met behulp van pull verzoeken, dit kan op twee manierenbereikt worden [5]. Ten eerste door heel vaak verzoeken naar de server te sturen of er iets nieuwsaanwezig is. Een groot nadeel hiervan is dat het van zowel de client als de server een procesintensieve oplossing is. Ten tweede kan er gebruik gemaakt worden van long-polling. In dezeopzet wordt er niet meteen een response verstuurd op een verzoek als er geen veranderingen zijnplaatsgevonden. De server houdt de verbinding voor een bepaalde tijd, over het algemeen 45seconden. Als in de tussentijd niets is veranderd zal de server de verbinding verbreken en de clientvragen om opnieuw verbinding te maken.

3.2.2 Universele Push Interface

Om push berichten naar verschillende services te versturen hebben Brustel et al. [6] een UniversalPush Interface (UPI) ontworpen, dit model kan het ontwerpen van een algemene push serviceapplicatie ondersteunen. Met de UPI wordt de complexiteit van de details en protocollen van deonderliggende push technologieen die horen bij de push servers van Google, Apple en Microsoftgeabstraheerd. Deze architectuur kan de basis vormen van onze implementatie.

6

In figuur 1 hieronder zien we de UPI architectuur die is voorgesteld [6]. Daarin zien we dat er eenpush facade is geplaatst tussen de push producenten en de concrete push systeem. De facade istransparant, ook al speelt het ook de rol van push producent. De push facade transformeert hetontvangen bericht om in een formaat die de push service verwacht. Het bericht kan vervolgensworden afgeleverd bij de juiste push systeem interface. Als laatst wordt het bericht afgeleverd aande gebruiker.

Figuur 1: Universal Push Interface architectuur [6].

De producent maakt gebruik van een unieke code om het bericht bij de juiste gebruikers af televeren. De code is opgemaakt uit twee delen. De ene deel is opgemaakt uit een code om aan tegeven welk push systeem gebruikt moet worden en de ander is de unieke code dat hoort bij hettoestel van de gebruiker.

7

4 Mobiele Platforms

Om inzicht te krijgen over de mogelijkheden die verschillende mobiele platforms bieden, zullen wijin dit hoofdstuk de mogelijkheden per mobiele platform uiteenzetten. Aangezien iOS en Androidmomenteel het grootste marktaandeel bezitten (respectievelijk 18.8% en 68.3%) [11], zullen wij dietwee uitgebreid onderzoeken. Ver daaronder op plek 3 en 4 vinden we respectievelijk BlackberryOS en Microsoft Mobile. Er wordt overigens verwacht dat Microsoft Mobile binnen 3 jaar bijna 5keer meer marktaandeel dan nu zal bezitten. Blackberry OS blijft hangen rond een schamele 4%[11] waardoor het niet aantrekkelijk lijkt om voor Blackberry OS te ontwikkelen.

Voor zowel iOS als Android zullen we gedetailleerd beschrijven hoe de push servers werken diedoor beide platforms beschikbaar worden gesteld. De push mogelijkheden van Microsoft Mobilezullen we globaal beschrijven. Gezien het geringe gebruik van Blackberry OS en het feit dat Exactdaar totaal niet mee bezig is zullen wij die niet behandelen.

Het is overigens niet mogelijk om push berichten naar mobiele toestellen van de eerder genoemdemobiele platforms te sturen zonder gebruik te maken van hun push service. Om push berichten teversturen naar mobiele toestellen is het namelijk nodig om een persistent IP verbinding te kunnenopzetten met het toestel. Hoewel we ons tijdens het project zullen richten op een enkele platform,hopen we dat ons overzicht ondersteuning kan bieden in de toekomst om push notificaties naareen ander platform te versturen.

4.1 iOS

Apple heeft voor zijn mobiel platform iOS ontwikkeld, een mobiele operating systeem dat veel corefunctionaliteit deelt met de desktop OS van Apple, OS X. Met behulp van de iOS SDK2 en Xcode3

IDE4 is het mogelijk om applicaties te ontwikkelen die kunnen draaien op iOS [2]. Het is voor eengroot deel mogelijk om applicaties te ontwikkelen zonder dat je daarvoor een betaald developeraccount nodig hebt. Om je app beschikbaar te stellen via de App Store [3] is het overigens welnoodzakelijk om een developer account te hebben, zo een account voor individuele ontwikkelaarskost 99 dollar per jaar [4].

Om push berichten te kunnen versturen naar iOS toestellen is het noodzakelijk om gebruik temaken van de Apple Push Notification Server (APNS) [1]. Over het algemeen biedt Apple nietde mogelijkheid voor apps om op de achtergrond te draaien. Zonder die mogelijkheid zou eenexterne server dus nooit een mobiele app kunnen bereiken tenzij die op de voorgrond draait. Hoede APNS werkt zullen we hieronder gedetailleerd beschrijven.

4.1.1 Apple Push Notification Server (APNS)

De push server van Apple maakt het mogelijk voor ontwikkelaars om push notificaties te sturennaar specifieke mobiele applicaties. De server onderhoud een versleutelde “persistent IP” verbin-ding tussen de server en de telefoon. Daardoor wordt het technisch mogelijk om push notificatieste versturen zonder dat een specifieke applicatie hoeft te draaien op de telefoon [1].

Om push notificaties te versturen via de APNS moet de ontwikkelaar in het bezit zijn van eengeldig SSL certificaat waarmee een versleutelde verbinding tussen de applicatie server en de APNSmee opgezet kan worden. Ervaring met TLS/SSL en streaming sockets wordt aanbevolen doorApple [1].

2Software Development Kit3https://developer.apple.com/xcode/4Integrated Development Environment

8

Notificatie versturenIn figuur 2 zien we een abstracte representatie van het pad dat een notificatie aflegt voordat diete zien is op een mobiele telefoon. Verderop zullen we in detail beschrijven hoe de communicatietussen de provider, APNS en client tot stand komt. De provider verstuurt een notificatie naarde APNS, vervolgens stuurt de APNS de notificatie door naar de desbetreffende iPhone. Denotificatie wordt dan weergegeven ongeacht of de applicatie is afgesloten of open staat. Indienjuist ingesteld kan de notificatie de mogelijkheid bieden om de desbetreffende applicatie op testarten. Als dat niet het geval is zal er alleen een bericht getoond worden.

Figuur 2: Notificatie pad van provider naar client app.

Een verbinding tussen de provider en de APNS komt tot stand via een TLS en peer-to-peerauthenticatie [1]. De interface maakt gebruik van een TCP socket ontwerp waarmee binaire inhoudverstuurd kan worden, zie figuur 4 voor een schematisch overzicht van zo een pakketje. Hieronderin figuur 3 zien we schematisch hoe de verbinding tot stand komt. Een zelfde soort verbindingwordt opgesteld tussen de client en de APNS.

Figuur 3: TLS authenticatie schema tussen provider en APNS.

De binaire interface is asynchroon. Bovendien heeft Apple twee gateways vrijgegeven waarovercommunicatie met de APNS mogelijk is [1]. Er wordt onderscheid gemaakt tussen productieen ontwikkel omgevingen. Respectievelijk zijn dat de binaire interfaces, gateway.push.apple.com,poort 2195 en gateway.sandbox.push.apple.com, port 2195 [1]. Figuur 4 laat schematisch de noti-ficatie payload zien.

9

Notificatie payloadPer verbinding wordt aangeraden om de notificaties in batches over de verbinding te versturenvoor optimale performance [1].

Figuur 4: Notificatie payload.

IdentifierEen arbitraire waarde die deze notificatie identificeert. Dit is dezelfde identifier die wordtteruggestuurd in een error-response pakketje als APNS de notificatie niet kan interpreteren.

ExpiryEen vast UNIX datum uitgedrukt in seconden (UTC) die aangeeft wanneer de notificatieniet meer valide is en kan worden verwijderd. De expiry waarde gebruikt big endian. Alsde expiry waarde positief is, dan zal APNS proberen om de notificatie tenminste een keer teversturen. Specificeer nul (of een waarde minder dan nul) om de APNS opdracht te gevende notificatie niet op te slaan als die niet aan is gekomen op de client.

Token lengthDe lengte van de device token (big endian).

Device tokenDe device token in binaire vorm.

Payload lengthDe lengte van de payload (big endian). De payload mag niet meer dan 256 bytes zijn enmag niet eindigen op een null.

PayloadDe notificatie payload.

De error pakketjes kunnen de volgende foutmeldingen bevatten:

Status code Description0 No errors encountered1 ”Processing error2 Missing device token3 Missing topic4 Missing payload5 Invalid token size6 Invalid topic size7 Invalid payload size8 Invalid token10 Shutdown255 None (unknown)

Best practices verbindingen opzettenAls een ontwikkelaar veel notificaties tegelijkertijd wilt verzenden, raadt Apple die ontwikkelaarsaan om meerdere connecties te maken naar dezelfde gateway en de notificaties over die verbindingente verdelen. Door dat te doen wordt de performance verbeterd ten opzichte van het gebruik vaneen enkele verbinding [1]. Verder wordt ook opgemerkt dat een verbinding niet meerdere kerenper dag geopend en gesloten mag worden. Zodra de APNS dat constateert wordt de verbinding

10

afgesloten en behandeld alsof er een denial-of-service aanval plaatsvindt. Alleen in het geval dateen ontwikkelaar een keer per dag notificaties verstuurt naar zijn gebruikers wordt aangeraden omde verbinding af te sluiten.

Feedback dienstApple heeft een feedback dienst waarmee dagelijks kan worden opgevraagd welke toestel tokensniet meer in gebruik zijn [1]. Zo wordt het mogelijk om te voorkomen dat er onnodig notificatiesverstuurd worden naar toestellen die niet meer in gebruik zijn. De dienst houdt een lijst mettokens bij per applicatie. Indien er meerdere applicaties geregistreerd zijn moeten er dus ookmeerdere verzoeken gedaan worden.

De verbindingsinterface is vergelijkbaar met de dienst voor het versturen van push berichten. Deproductie feedback is te vinden via feedback.push.apple.com op poort 2196 en tijdens het testenvia feedback.sandbox.push.apple.com op poort 2196 [1].

4.2 Android

Android is het mobiele platform van Google. Applicaties in Android kunnen ontwikkeld wordenmet behulp van de Android SDK, Java Development Kit (JDK) en Eclipse IDE met de ingebouwdeAndroid Developer Tools (ADT) plugin [8]. Voor het ontwikkelen van Android applicaties is hetniet nodig om een betaald developer account te hebben. Om je applicatie beschikbaar te stellenvia Google Play, de digitale distributie platform voor Android, heb je een Google Play publisheraccount nodig. Dit account heeft alleen de eenmalige inschrijvingskosten van 25 dollar [9].

Android gebruikt de Google Cloud Messaging (GCM) om push berichten te sturen naar An-droid applicaties op Android toestellen. In de volgende paragraaf omschrijven we de werking vanGCM.

4.2.1 Google Cloud Messaging (GCM)

GCM maakt het mogelijk voor ontwikkelaars om via hun eigen applicatie servers push berichtente sturen naar Android toestellen. Dit kan een simpel bericht zijn dat aan de Android applicatievertelt dat er nieuwe data is om opgehaald te worden van de server of een bericht van maximaal4kb aan data. De Android applicatie hoeft niet op de achtergrond te draaien om dit bericht teontvangen. Het systeem geeft dit namelijk door aan de desbetreffende applicatie via een “Intent”.Een Intent is een soort wrapper om een activity heen. Het is een abstracte omschrijving van eenoperatie die uitgevoerd gaat worden. Een activity wordt binnen Android gebruikt om processenaan te duiden.

Om push notificaties te versturen via GCM moet de ontwikkelaar in het bezit zijn van een Googleaccount. Met de Google account kan vervolgens via de Google API Console de Google CloudMessaging service aangezet worden [10]. Een Android telefoon die een applicatie geınstalleerdheeft met de GCM functie registreert zichzelf bij de GCM server bij het opstarten. De applicatiekrijgt dan een registratie ID van de GCM server die vervolgens door de applicatie server gebruiktwordt om via de GCM server een bericht te sturen naar deze Android telefoon.

Bij het versturen van notificaties via de GCM worden ID’s en tokens gebruikt in verschillendefases om alle partijen te verifieren en om te zorgen dat het bericht naar de correcte plaats gaat.Hieronder volgt een lijst met de gebruikte ID’s en tokens:

Sender IDHet projectnummer bij het aanmaken van een nieuw project via Google API Console. Ditwordt gebruikt in het registratie proces om een Android applicatie te identificeren dat toe-gestaan is om berichten te versturen naar het toestel.

11

Application IDDe Android applicatie in kwestie die registreert om berichten te ontvangen. Deze applicatiewordt geıdentificeerd door de “package name” van het AndroidManifest.xml bestand. Ditbestand bevat essentiele informatie die het Android systeem nodig heeft om de applicatieuit te voeren. De Application ID zorgt ervoor dat de berichten naar de correcte Androidapplicatie gaan.

Registration IDEen uniek nummer dat door de GCM server wordt uitgegeven aan de Android applicatie omberichten te mogen ontvangen. Dit nummer wordt vervolgens door de Android applicatieverzonden naar de applicatie server. Deze zal dit nummer gebruiken om elk toestel teidentificeren dat zich heeft geregistreerd om berichten te ontvangen voor een gegeven Androidapplicatie. Een Registration ID is dus gebonden aan een bepaalde Android applicatie die opeen bepaalde toestel draait.

Sender Auth TokenEen API sleutel die de applicatie server de toegang geeft om gebruik te maken van de GoogleServices. Deze sleutel wordt meegestuurd wanneer de applicatie server een bericht stuurtvia de GCM server naar de Android telefoon.

Levenscyclus van GCMTijdens het gebruik van GCM server zijn er drie hoofdprocessen te onderscheiden [10]: inschakelenvan de GCM, een bericht sturen en een bericht ontvangen.

Inschakelen van de GCMHet inschakelen van de GCM houdt in dat een Android applicatie op een mobiel apparaat zichregistreert om berichten te ontvangen. De volgende stappen worden doorlopen:

1. De eerste keer dat een Android applicatie de bericht service gebruikt, zendt die een registratieIntent naar de GCM server. Deze registratie Intent omvat de Sender ID en de AndroidApplicatie ID.

2. Als de registratie een succes is, dan zendt de GCM server een Intent die een Registration IDgeeft aan de Android applicatie.

3. Om de registratie af te ronden, stuurt de Android applicatie de Registration ID naar deapplicatie server. De applicatie server slaat normaal gesproken deze Registration ID op ineen database.

Een bericht sturenVoordat een applicatie server een bericht kan versturen naar een Android applicatie moeten devolgende punten waar zijn.

• De Android applicatie heeft een Registration ID die het toestaat om berichten te ontvangenvoor een bepaald toestel.

• De applicatie server heeft de Registration ID opgeslagen.

• Een API key moet beschikbaar zijn om berichten mee te verzenden.

Indien aan de bovenstaande eisen worden voldaan dan wordt de volgende stappen doorlopen bijhet verzenden van een bericht door een applicatie server:

1. De applicatie server zendt een bericht naar de GCM server.

12

2. Google zet het bericht in de wachtrij of slaat het bericht op indien het toestel waarnaar hetverstuurt moet offline is.

3. Wanneer het toestel online is, wordt het bericht verzonden.

4. Op het toestel zelf wordt het bericht door het Android systeem naar de specifieke Androidapplicatie verzonden via een Intent. De Android applicatie hoeft niet te draaien voordat diehet bericht ontvangt.

5. De Android applicatie verwerkt het bericht.

Een bericht ontvangenEen Android applicatie die geınstalleerd is op een mobiele toestel doorloopt de volgende stappenom een bericht te ontvangen:

1. Het systeem ontvangt de binnen gekomen bericht en haalt de data eruit indien aanwezig.

2. Het systeem geeft de sleutel/waarde paren door aan de desbetreffende Android applicatie ineen Intent als een verzameling van extra’s.

3. De Android applicatie verwerkt de data.

4.3 Windows Mobile

Met behulp van Windows Push Notification Services (WNS) is het mogelijk om push berichten teversturen naar telefoontoestellen die draaien op Windows Mobile Phone. Voorwaarde is wel datje een developer account aanmaakt dat 37 euro per jaar kost.

De communicatie met de push dienst maakt gebruik van HTTP verzoeken over een Secure Soc-kets Layer (SSL). De authenticatie tokens maken gebruik van OAuth 2.0, een open authenticatiestandaard [15].

Er volgt nu in het kort uitleg hoe de dienst gebruikt kan worden. Je app dient een verzoek in bijde Notification Client Platform (NCP) om een push notificatie kanaal te ontvangen [15]. De NCPvraagt dan WNS om een kanaal te openen. De kanaal wordt teruggegeven in de vorm van eenUniform Resource Identifier (URI), dat kanaal wordt ook verstuurd naar je app.

Vervolgens verstuurt je app via een callback service de URI naar je eigen server. Het is deverantwoordelijkheid van de ontwikkelaar om deze verbinding veilig op te zetten met behulp vanweb standaarden [15]. Zodra je server een notificatie klaar heeft staan om te versturen kan diegebruik maken van WNS om de notificatie via de URI te verzenden naar het toestel.

13

5 Event-Driven Messaging

Notificaties worden over het algemeen aan de hand van gebeurtenissen binnen de applicatie gegene-reerd. Binnen een applicatie wordt op een knop gedrukt, dan wordt er een gebeurtenis gegenereerddie een notificatie opstuurt. Het is dus een natuurlijke keuze om aan de hand van event-drivenmessaging onderzoek te doen naar de aanbevolen architecturen op dat gebied. We zullen in dithoofdstuk een overzicht geven van wat event-driven architectuur is en wat het Publish/Subscribemodel voorstelt en wat de voordelen daarvan zijn voor het versturen van notificaties.

5.1 Event-Driven Architectuur

Event-driven architectuur (EDA) is een structuur waarin elementen worden geactiveerd door ge-beurtenissen. Een gebeurtenis, in de ondernemende zin, is een status verandering van een onder-nemersproces die ook invloed heeft op de uitkomst van het proces [12].

De architectuur is extreem los gekoppeld en heel erg gedistribueerd [14]. Zo weet de maker van eengebeurtenis alleen dat het gebeurtenis is verstuurd. Verder heeft die geen kennis van de processendie daarna verlopen. Het is dus erg lastig om een gebeurtenis te volgen door het netwerk vanprocessen.

De meest belangrijke componenten van een EDA zijn [12, 14]:

Event source of generatorDe oorsprong van een gebeurtenis, bijvoorbeeld een applicatie of een ondernemersproces.

Event ontvangers of consumentenDe ontvangers zijn geınteresseerd in bepaalde gebeurtenissen. Ze zijn in staat om de func-tionaliteit van een gebeurtenis uit te voeren of om de gebeurtenis te publishing in de vormvan bijvoorbeeld een alert.

Event sensorsLuistert of er gebeurtenissen plaatsvinden

Event verwerkersVerwerkt gegenereerde gebeurtenissen, zodat ze verstuurd kunnen worden naar de juisteontvangers.

Er zijn drie verschillende processen om gebeurtenissen mee te verwerken[14]:

Simple event processing (SEP)SEP heeft betrekking op simpele gebeurtenissen die afgeleid zijn van een direct merk-baar/meetbaar verandering. Zo een verandering resulteert in een aantal acties die onmid-dellijk afgehandeld worden. SEP wordt normaal gesproken gebruikt om real-time processenmee aan te sturen om vertragingen en kosten mee te verkleinen.

Event stream processing (ESP)In ESP bestaan er ’gewone’ gebeurtenissen en ’interessante’ gebeurtenissen. ’Gewone’ ge-beurtenissen worden gescreend en bepaald of er iets ’interessants’ in staat om te versturennaar de aangemelde processen. Het is met ESP mogelijk om real-time inzicht te verkrijgenin ondernemersprocessen, waardoor er real-time beslissingen genomen kunnen worden.

Complex event processing (CEP)Met behulp van CEP is het mogelijk om uit een samenstelling van “gewone” gebeurtenisseneen complexe gebeurtenis uit te genereren. Complexe gebeurtenissen kunnen ermee wordengeconstateerd, zodat er adequaat op gereageerd kan worden. CEP maakt dus ook gebruikvan ingewikkelde algoritmen die gebeurtenissen kunnen interpreteren en matchen met dejuiste acties.

14

5.2 Publish/Subscribe model

Het Publish/Subscribe model biedt de mogelijkheid voor zenders, de publishers, om berichten testuren naar ontvangers, de subscribers. Publishers maken berichten aan van bepaalde klassen.Subscribers kunnen dan zich abonneren op bepaalde klassen die voor hun interessant zijn zonderdat ze iets afweten van de publishers [7].

In veel pub/sub systemen worden berichten van de publishers verzonden naar een tussenpersoondie een message broker wordt genoemd. De subscribers abonneren dan via deze broker. Dezebroker zorgt dan voor de filtering van berichten en heeft voornamelijk als functie om berichten opte slaan en door te sturen van publishers naar subscribers. De broker kan daarnaast ook nog eenrij bijhouden om prioriteiten te geven aan berichten voordat hij ze verstuurt. Hieronder in figuur 5is grafisch weergegeven hoe de relaties zijn tussen de publisher, broker en subscriber [6].

Figuur 5: Publish/Subscribe broker [6].

Er bestaan drie varianten van het pub/sub model waarmee je berichten kan versturen naar sub-scribers: List-Based Publish/Subscribe, Broadcast-Based Publish/Subscribe, and Content-BasedPublish/Subscribe.

List-Based Publish/SubscribeBij List-Based Publish/Subscribe wordt een subject geıdentificeerd en wordt een lijst van subscri-bers bijgehouden van dit subject. Wanneer een gebeurtenis optreedt heeft dit subject de taak omde subscribers hierover een melding te geven.

Broadcast-Based Publish/SubscribeBroadcast-Based Publish/Subscribe bereikt hetzelfde resultaat als List-Based Publish/Subscribe,maar benadert het op een andere manier. Een event publisher creeert een bericht en verspreidt ditvervolgens naar het Local Area Network (LAN). Een service op elke client bekijkt het onderwerp-regel. Wanneer een client een match vindt tussen de onderwerpregel en waarvoor hij geabonneerdis, dan wordt het bericht verwerkt. Anders wordt het bericht genegeerd.

Content-Based Publish/SubscribeContent-Based Publish/Subscribe is vergeleken met de voorgaande twee implementaties flexibeler.Berichten worden namelijk op een intelligente manier naar hun eindbestemming geleid doordat ergekeken wordt naar de inhoud van het bericht [18].

Het gebruik van het pub/sub model biedt de volgende voordelen[16, 6]:

• “Lowered coupling”. De publisher is niet op de hoogte van het aantal subscribers, de iden-tities van de subscribers en welk bericht type ze voor ingeschreven zijn. Beiden kunnenonafhankelijk van elkaar werken zonder oponthoud [17].

15

• Pub/sub model biedt een betere schaalbaarheid dan traditioneel client-server model.

• Verbeterde veiligheid. De communicatie infrastructuur transporteert de berichten alleennaar applicaties die zich hebben ingeschreven bij het corresponderende onderwerp [16].

Behalve voordelen heeft het pub/sub model ook nadelen:

• Geen garantie van levering van berichten. Door de ontkoppeling van publisher met subscriberis het moeilijk om na te gaan of een bericht met succes is ontvangen.

16

6 Conclusie

In dit orientatieverslag doen we verslag van ons vooronderzoek naar het verzenden van mobielenotificaties. Exact richt zich de laatste jaren ook op het ontwikkelen van mobiele apps, die ophet Android of iOS platform werken. De mogelijkheid om ten alle tijden notificaties te kunnenversturen naar een mobiele applicatie kan cruciaal zijn voor een goede gebruikerservaring. Bepaaldeapplicaties hebben er baat bij om real-time te kunnen communiceren met hun mobiele applicatieen daarmee direct nieuwe informatie met de gebruiker te kunnen delen. Daarom is het voor Exactinteressant om de mogelijkheden te bekijken die eventueel in de toekomst geıntegreerd kan wordenin haar mobiele apps.

De focus van ons onderzoek hebben we gelegd op de volgende vraag:


Ter behulp van onze onderzoeksvraag maken we gebruik van de volgende deelvragen:

Deelvraag 1:Wat zijn de verschillen tussen en de voor- en nadelen van de pull en push techniek?

Deelvraag 2:Wat zijn de mogelijkheden op de huidige mobiele platformen met betrekking tot notificatie-systemen?

Deelvraag 3:Welke event-driven messaging architecturen bestaan er die geschikt zijn voor een notificatie-systeem?

Uit ons onderzoek is gebleken dat het verzenden van notificaties via push techniek de meestevoordelen biedt tegenover de pull techniek. De iOS en Android platformen beschikken beide overhun eigen Push Server Notificatie systemen, die we kunnen gebruiken voor het implementeren vanons prototype. Als architectuur zal gekozen worden voor een event-driven messaging architectuur.Momenteel gaat ons voorkeur uit naar het Publish/Subscribe model dat het meeste aansluit oponze verwachting van het te implementeren systeem.

17

Referenties

[1] Apple. About local notifications and push notifications. http://developer.

apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/

RemoteNotificationsPG/Introduction.html/, 2013. [Online; geraadpleegd 29-april-2013].

[2] Apple. Develop apps for ios. https://developer.apple.com/technologies/ios/, 2013.[Online; geraadpleegd 29-april-2013].

[3] Apple. ios developer program - distribute. https://developer.apple.com/programs/ios/distribute.html, 2013. [Online; geraadpleegd 29-april-2013].

[4] Apple. Which developer program is for you? https://developer.apple.com/programs/

which-program/, 2013. [Online; geraadpleegd 29-april-2013].

[5] Engin Bozdag, Ali Mesbah, and Arie Van Deursen. A comparison of push and pull techniquesfor ajax. In Web Site Evolution, 2007. WSE 2007. 9th IEEE International Workshop on, pages15–22. IEEE, 2007.

[6] Jonas Brustel and Thomas Preuss. A universal push service for mobile devices. In Complex,Intelligent and Software Intensive Systems (CISIS), 2012 Sixth International Conference on,pages 40–45. IEEE, 2012.

[7] Patrick Th Eugster, Pascal A Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. Themany faces of publish/subscribe. ACM Computing Surveys (CSUR), 35(2):114–131, 2003.

[8] Google. Developer tools. http://developer.android.com/tools/, 2013. [Online; geraad-pleegd 29-april-2013].

[9] Google. Get started with publishing. http://developer.android.com/distribute/

googleplay/publish/, 2013. [Online; geraadpleegd 29-april-2013].

[10] Google. Google cloud messaging for android. http://developer.android.com/google/

gcm/, 2013. [Online; geraadpleegd 29-april-2013].

[11] International Data Corporation (IDC). Worldwide mobile phone growth expected to drop to1.4% in 2012 despite continued growth of smartphones, according to idc. http://www.idc.

com/getdoc.jsp?containerId=prUS23818212#.UL56zI5JA21/, 2012. [Online; geraadpleegd2-mei-2013].

[12] Olga Levina and Vladimir Stantchev. Realizing event-driven soa. In Internet and WebApplications and Services, 2009. ICIW’09. Fourth International Conference on, pages 37–42.IEEE, 2009.

[13] Jean-Philippe Martin-Flatin. Push vs. pull in web-based network management. In Inte-grated Network Management, 1999. Distributed Management for the Networked Millennium.Proceedings of the Sixth IFIP/IEEE International Symposium on, pages 3–18. IEEE, 1999.

[14] Brenda M Michelson. Event-driven architecture overview. Patricia Seybold Group, 2, 2006.

[15] Microsoft. Push notification overview (windows store apps). http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx/, 2012. [Online; geraadpleegd 2-mei-2013].

[16] Microsoft. Publish/subscribe. http://msdn.microsoft.com/en-us/library/ff649664.

aspx, 2013. [Online; geraadpleegd 02-mei-2013].

[17] Ivana Podnar, Manfred Hauswirth, and Mehdi Jazayeri. Mobile push: Delivering contentto mobile users. In Distributed Computing Systems Workshops, 2002. Proceedings. 22ndInternational Conference on, pages 563–568. IEEE, 2002.

18

[18] Wesley W Terpstra, Stefan Behnel, Ludger Fiege, Andreas Zeidler, and Alejandro P Buch-mann. A peer-to-peer approach to content-based publish/subscribe. In Proceedings of the2nd international workshop on Distributed event-based systems, pages 1–8. ACM, 2003.

19

C Bestudeerde Technieken/Tools

In deze bijlage geven we een overzicht van de technieken en tools die we tijdens het bachelorprojecthebben geleerd.

Visual Studio Gebruik maken van de Visual Studio IDE van Microsoft.

LaTeX Documenten samenstellen in LaTeX. Gebruik maken van de juiste packages bleek tijdbesparend om de opmaak in orde te krijgen.

Git Werken met git als source control. Git hebben we gebruikt voor zowel de code als de LaTeXdocumenten. Overigens hebben we de code op een Team Foundation Server gehost en dedocumenten op Github.

C# Programmeren met C-Sharp.

Entity Framework Een ORM van Microsoft, waardoor communicatie met de database zonderhet schrijven van query’s kan verlopen.

Google Cloud Messaging(GCM) We zijn in staat om met de GCM server te communicerenen daarmee een notificatie te versturen naar een mobiele telefoon.

Android framework Door het schrijven van de Android Demo App hebben we kennis gemaaktmet het maken van Android applicaties.

72

D Taakverdeling

We hebben per onderdeel aangegeven wie verantwoordelijk was voor het opleveren van bepaaldeelementen tijdens het project. Deze punten geven ook aan hoe de werklast was verdeeld voorde genoemde punten, met betrekking tot het schrijven van de documentatie en ook voor hetimplementeren van de code.

Plan van AanpakHoofdstukken schrijven evenredig verdeeld.

OrientatieverslagHoofdstukken schrijven evenredig verdeeld.

Requirements fase- Edwin: Technisch ontwerp en testplan.- ManWai: Requirements en functioneel ontwerp

Implementatie fase- Edwin: Notificatie systeem en architectuur implementeren.- ManWai: Unit tests, Android App implementeren en testen.

Documenten en code inleveren- ManWai

73

E SIG Moment 1: 14-06-2013

[Analyse]

“De code van het systeem scoort bijna 5 sterren op ons onderhoudbaarheidsmodel,wat betekent dat de code bovengemiddeld onderhoudbaar is. De hoogste score is netniet behaald door een lagere score voor Unit Size.

Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeldlang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elkonderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhoudenwordt. Vanwege de omvang van dit systeem zien we dat de enkele methode ‘Seed’in de class ‘SubscriptionInitializer’ ervoor zorgt dat de hoogste score niet is behaald.Binnen deze methode zijn weliswaar aparte stukken functionaliteit te vinden welkege-refactored kunnen worden naar aparte methodes, bijvoorbeeld een ‘addTopics’-methode, maar gegeven de huidige omvang van de methode is het opsplitsen nietmeteen noodzakelijk. Mocht de methode groeien dan is het wel aan te raden deze opte splitsen.

Over het algemeen scoort de code bovengemiddeld, hopelijk lukt het om dit niveaute behouden tijdens de rest van de ontwikkelfase. De aanwezigheid van test-code is inieder geval veelbelovend, hopelijk zal het volume van de test code ook groeien op hetmoment dat er nieuwe functionaliteit toegevoegd wordt.” Dennis Bijlsma, SIG

74

F SIG Moment 2: 05-07-2013

[Hermeting]

“In de tweede upload zien we dat het codevolume in omvang is verdubbeld, terwijlde score voor onderhoudbaarheid ongeveer hetzelfde is gebleven.

Bij Unit Size zien we dat de voorbeelden die in de vorige analyse werden genoemdinmiddels zijn opgesplitst. Helaas is het niet gelukt om deze aanpak structureel doorte voeren, waardoor de deelscore voor Unit Size niet significant omhoog is gegaan.

Het is positief om te zien dat de hoeveelheid testcode is verdubbeld.Uit deze observaties kunnen we concluderen dat de aanbevelingen van de vorige

evaluatie grotendeels zijn meegenomen in het ontwikkeltraject.” Dennis Bijlsma, SIG

75

Eindverslag - Home | TU Delft Repositories

Documents

Transcript of Eindverslag - Home | TU Delft Repositories