Eindverslag. Technische Universiteit Delft. TI3800 Bachelorproject. Mobiel Notificatie Systeem

Technische Universiteit Delft TI3800 Bachelorproject Mobiel Notificatie Systeem

Eindverslag

Auteurs: Edwin van den Houdt ManWai Shing

Begeleiders: Cor-Paul Bezemer (TU Delft) Eugène Pattikawa (Exact) Peter Spanjer (Exact)

Delft, 11 juli 2013

Voorwoord Dit document is het eindverslag van het bachelorproject van de opleiding Technische Informatica op 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 zeer gewaardeerde feedback op onze documentatie en het feit dat wij altijd terecht konden met al onze vragen. Eugène Pattikawa (Projectbegeleider, Exact), voor de begeleiding van het project binnen Exact en 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 tijdens dit 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 TU Delft. In dit verslag beschrijven we onze stage bij Exact. De stappen die zijn genomen van het opstellen 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 Exact zich ook op het ontwikkelen van mobiele apps, die werken op Android of iOS. Om deze activiteiten nog beter in real-time te kunnen monitoren is het van belang dat de apps uitgerust worden met de 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 implementeren van een applicatie voor het versturen van mobiele notificaties naar aanleiding van gebeurtenissen gegenereerd door een webapplicatie? Om op een antwoord te komen op onze onderzoeksvraag willen we graag een notificatie systeem implementeren, dat uit de volgende componenten bestaat: Notificatie Applicatie Een applicatie die in staat is om gebeurtenissen af te vangen van de webapplicatie. Deze gebeurtenissen worden vervolgens omgezet naar notificaties. Uiteindelijk worden de notificaties volgens een correct formaat naar verschillende mobiele platforms verstuurd. Hierbij wordt rekening gehouden met welk type notificatie naar welke gebruiker moet (welk OS). Android Demo App Een eenvoudige Android applicatie, waarmee uiteindelijk de verstuurde notificatie ontvangen kan worden en correct kan worden weergegeven. De eerste stap dat we genomen hebben is het opstellen van de belangrijkste functionele en nietfunctionele eisen waar het notificatie systeem aan moet voldoen. De functionele eisen beschrijven wat het systeem moet doen voor de gebruiker. De voorwaarden waaraan gehouden moeten worden tijdens 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 functionaliteit van het systeem beschrijft in de vorm van use cases. Met de use cases kunnen we een beter beeld schetsen over de werking van de features. Het technisch ontwerp dat we in onze derde stap hebben gemaakt, geeft een technisch overzicht van de verschillende componenten van de Notificatie Applicatie. De Notificatie Applicatie bestaat uit drie componenten: • Een Notification Trigger die gebruikt wordt om handmatig twee soorten notificatie berichten te genereren. Een persoonlijke notificatie en een notificatie voor iedereen die zich op een bepaalde Topic heeft geabonneerd. • Een Message Broker die de notificatie berichten koppelt met gebruikers die zich voor een Topic hebben aangemeld. • Een Dispatcher die voor de communicatie verzorgt van de push service als het versturen van de daadwerkelijke notificatie. Na het ontwerpen hebben we een testplan opgesteld om de kwaliteit van ons prototype te garanderen. 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 systeem dat in eerste instantie de focus legt op het Android platform. Maar het prototype zal flexibel zijn zodat het toevoegen van andere platformen eenvoudig is. Het antwoord op de hoofdvraag hebben we gegeven door het implementeren van ons notificatie systeem. Puur afgaand op de “requirements evaluatie” zijn we geslaagd in het bereiken van de eisen die we aan het begin van dit project gesteld hebben. Hiermee hebben we met ons prototype laten zien wat er allemaal bij komt kijken indien een notificatie systeem ontwikkeld moet worden dat gebeurtenissen gegenereerd door een webapplicatie verwerkt.

3

Inhoudsopgave Voorwoord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2

1 Inleiding

6

2 Probleemstelling

7

3 Requirements Analysis 3.1 Functionele Eisen . . . . . . . 3.1.1 Notificatie Applicatie 3.1.2 Android Demo App . 3.2 Niet-Functionele Eisen . . . . 3.2.1 Notificatie Applicatie 3.2.2 Android Demo App .

. . . . . .

8 8 9 10 11 11 11

4 Functioneel Ontwerp 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Notificatie Applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Android Demo App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 12 12 17

5 Technisch Ontwerp 5.1 Klasse-Niveau Beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20 22

6 Testplan 6.1 Automatische Tests . . . . . . 6.2 Unit Tests . . . . . . . . . . . 6.3 Statische Tests . . . . . . . . 6.4 Handmatige Tests . . . . . . 6.5 Performance Tests . . . . . . 6.6 Software Improvement Group

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

24 24 24 24 24 25 25

7 Implementatie 7.1 Notification Trigger . 7.2 Message Broker . . . 7.3 Dispatcher . . . . . . 7.4 Android Demo App

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

26 26 27 27 28

8 Requirements Evaluatie 8.1 Functionele Eisen . . . . . . . 8.1.1 Notificatie Applicatie 8.1.2 Android Demo App . 8.2 Niet-Functionele Eisen . . . . 8.2.1 Uitbreidbaarheid . . . 8.2.2 Onderhoudbaarheid . 8.2.3 Betrouwbaarheid . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

29 29 29 31 32 32 32 32

9 Reflectie 9.1 Edwin van den Houdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 ManWai Shing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33 33 34

10 Conclusie

35

A Plan van Aanpak

37

. . . .

. . . .

. . . .

. . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

B Ori¨ entatieverslag

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 die alle belangrijke zakenprocessen ondersteunen voor het midden- en kleinbedrijf. Ze ontwikkelen cloudgeoriënteerde oplossingen en maatwerk voor industrieën als accountancy, retail en professionele diensten en fabricage. Sinds een paar jaar richt Exact zich ook op het ontwikkelen van mobiele apps, die op het Android of iOS platform werken. Met behulp van deze apps kunnen ze een betere dienst aanbieden voor klanten die een beter real-time inzicht willen van hun zakelijke activiteiten. Om deze activiteiten nog beter in real-time te kunnen monitoren is het van belang dat de apps uitgerust worden met de mogelijkheid om notificaties te kunnen ontvangen. In dit verslag beschrijven we onze stage bij Exact. De stappen die zijn genomen van het opstellen van 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. Hier wordt omschreven wat we tijdens onze stage bij Exact willen onderzoeken. Een overzicht van de belangrijkste functionele en niet-functionele eisen over ons prototype, het notificatie systeem, geven we in hoofdstuk 3. In hoofdstuk 4 wordt het functioneel ontwerp gegeven dat de functionaliteit van het systeem beschrijft. Hoofdstuk 5 beschrijft het technisch ontwerp van het systeem. Om de kwaliteit van het eindproduct te garanderen is het van belang dat de implementatie goed is getest. Dit beschrijven we in hoofdstuk 6. In hoofdstuk 7 geven we een globaal overzicht van de uiteindelijke implementatie. Alle onderdelen waaruit het systeem bestaat zullen worden toegelicht en de werking ervan zal beschreven worden. In hoofdstuk 8 evalueren we de eisen van het systeem om te zien in hoeverre ze in ons systeem zijn ge¨ımplementeerd. Hoofdstuk 9 bevat onze persoonlijke reflectie verslagen. We beschrijven onze ervaringen over het bachelorproject. En tot slot wordt in hoofdstuk 10 onze conclusie gegeven die het antwoord geeft op de hoofdvraag.

1 http://www.exact.nl

6

2

Probleemstelling

Exact wil graag de mogelijkheid hebben om notificaties te kunnen versturen naar de gebruikers van hun mobiele applicaties. Het versturen van notificaties gaat op grond van gebeurtenissen die gegenereerd worden vanuit de webapplicatie. Een voorbeeld hiervan is het bijhouden van uren registratie. Voor bepaalde gebruikers is het mogelijk om de uren registratie in de webapplicatie bij te houden. In het geval een gebruiker vergeten is om zijn uren te registreren, kan daar een herinnerings-gebeurtenis voor worden gegenereerd. Aan de hand van zo een gebeurtenis zal er een notificatie (herinnering) verstuurd worden naar de desbetreffende gebruiker die zich voor deze notificatie Topic heeft aangemeld. Een Topic is een notificatie categorie waar een gebruiker zich op kan abonneren. Tijdens de oriëntatiefase hebben we onderzoek gedaan naar het versturen van mobiele notificaties en onze bevindingen vastgelegd in ons oriëntatieverslag dat in meer detail terug te lezen is in bijlage B. Wij zijn uiteindelijk gekomen tot de volgende onderzoeksvraag: Hoofdvraag: Welke eisen en technische implicaties zijn er verbonden aan het implementeren van een applicatie voor het versturen van mobiele notificaties naar aanleiding van gebeurtenissen gegenereerd door een webapplicatie? 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, waar het prototype, het notificatie systeem, dat beschreven is in het Plan van Aanpak in bijlage A, aan moet voldoen. Aan de hand van ons literatuuronderzoek uit de oriëntatiefase hebben we samen met Exact de eisen opgesteld. De eisen worden geclassificeerd met behulp van de MoSCoW2 methode. Daarmee wordt de prioriteit van iedere eis aangegeven. De eisen worden als volgt geclassificeerd: Must: zijn eisen die ge¨ımplementeerd moeten worden om het systeem succesvol te kunnen noemen. Should: zijn eisen die niet per se noodzakelijk zijn om het systeem te laten werken, maar ze zijn belangrijk genoeg om ge¨ımplementeerd te worden in de eerste versie van het systeem. In hoge nood mag ervan worden afgeweken. Could: zijn eisen die het liefst wel ge¨ımplementeerd worden, maar indien er niet genoeg tijd is voor de implementatie is dat niet noodzakelijk. Would: eisen hoeven in deze versie van het systeem niet te worden ge¨ımplementeerd. In volgende versies zou gekozen kunnen worden om ze alsnog te implementeren. Bij het beschrijven van de eisen zullen we gebruik maken van bepaalde terminologie. Om verwarring 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. Een gebeurtenis hoort bij een bepaalde Topic en een gebruiker kan zich abonneren op een bepaalde Topic. 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 functionele eisen beschrijven wat het systeem moet doen voor de gebruiker. Volgens de MoSCoW methode wordt voor elke component van het systeem de functionele eisen gegeven. Het notificatie systeem bestaat uit de volgende componenten: Notificatie Applicatie Een applicatie die in staat is om gebeurtenissen af te vangen van de webapplicatie. Deze gebeurtenissen worden vervolgens omgezet naar notificaties. Uiteindelijk worden de notificaties volgens een correct formaat naar verschillende mobiele platforms verstuurd. Hierbij wordt rekening gehouden met welk type notificatie naar welke gebruiker moet (welk OS). Android Demo App Een eenvoudige Android applicatie, waarmee uiteindelijk de verstuurde notificatie ontvangen kan worden en correct kan worden weergegeven. Tijdens ons project richten we in eerste instantie op het Android platform. In ons Oriëntatieverslag in bijlage B is te lezen dat voor de ontwikkeling op het iOS platform een developer license nodig is die we tijdens het project niet tot onze beschikking hebben. We hebben daarom gekozen om voor ons prototype te richten op het Android platform. Daarnaast was vanwege de beperkte ontwikkeltijd een betere keuze om ons te concentreren op één platform en meer tijd te besteden 2 https://en.wikipedia.org/wiki/MoSCoW_Method 3 http://en.wikipedia.org/wiki/Functional_requirement

8

aan het ontwerpen van een uitbreidbaar systeem. Het prototype zal daarom flexibel zijn zodat het toevoegen 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 webapplicatie Met behulp van een demo webapplicatie kan handmatig bepaalde gebeurtenissen gegenereerd worden. Indien zo een gebeurtenis tot een Topic behoort, moet die afgevangen worden. (b) Verbinding opzetten tussen Notificatie Applicatie en Google Cloud Messaging (Android) De verbinding verzorgen tussen de Notificatie Applicatie en de Google Cloud Messaging (GCM) server. (c) Gebruikers ophalen behorend bij een bepaalde Topic Bij een gegeven Topic moeten de gebruikers opgehaald worden die zich voor deze Topic hebben geabonneerd. (d) Versturen van een persoonlijke notificatie Het versturen van een persoonlijke notificatie naar een gebruiker die zich heeft geabonneerd op een bepaalde Topic. (e) Versturen van een groep notificatie Het versturen van een groep notificatie naar alle gebruikers die zich hebben geabonneerd op een bepaalde Topic. (f) Abonnementen toevoegen Voeg een abonnement toe als een gebruiker zich op een bepaalde Topic heeft geabonneerd. Een abonnement beschrijft op welke Topic een gebruiker zich heeft geabonneerd. (g) Abonnementen verwijderen Verwijder een abonnement als een gebruiker zich voor een bepaalde Topic heeft afgemeld. (h) Gebruiker toevoegen Een lijst van gebruikers. Een gebruiker moet hieraan toegevoegd kunnen worden. (i) Verzoeken afvangen en verwerken van de Android Demo App Verzoeken van de Android Demo App moeten afgevangen worden en vervolgens verwerkt worden. Voorbeelden hiervan zijn het registreren van de gebruiker, abonneren op een Topic en het afmelden van een Topic. 2. Should Have (a) Handmatig notificaties versturen Via een Demo Webapplicatie handmatig notificaties versturen. (b) Afmeldingen abonnement bijhouden Een lijst bijhouden met alle afmeldingen.

9

3. Could Have (a) Quality of Service Bijhouden of bericht correct is verzonden en zo niet nog een keer proberen te verzenden. (b) Gebeurtenissen afvangen voor de Exact Online webapplicatie De Exact Online webapplicatie genereert bepaalde gebeurtenissen. Indien zo een gebeurtenis tot een Topic behoort, moet die afgevangen worden. 4. Would/Won’t Have (a) Ondersteuning voor andere mobiele platformen Notificatie verzenden naar andere mobiele platformen (bijvoorbeeld: iOS, Windows Mobile, etc). 3.1.2

Android Demo App

1. Must Have (a) Registreren van de Android Demo App De Android Demo App die ge¨ınstalleerd is op een Android telefoon moet zich kunnen registreren bij de GCM server en vervolgens bij de Notificatie Applicatie. (b) Notificaties ontvangen op de Android Demo App Verstuurde notificaties moeten ontvangen en weergegeven worden op de Android Demo App. 2. Should Have (a) Abonneren op een Topic De gebruiker moet zich kunnen abonneren op een bepaalde Topic. (b) Afmelden voor een Topic De gebruiker moet zich kunnen afmelden voor een bepaalde Topic. 3. Could Have (a) Opties voor aangemelde Topics aanpassen Bepaalde Topics kunnen meerdere opties bevatten, de gebruiker moet deze kunnen instellen. Een voorbeeld hiervan is het aangeven van de frequentie voor het ontvangen van de notificatie. (b) Verwerk ontvangen notificatie Een actie afhandelen die hoort bij een specifieke notificatie. Bijvoorbeeld, applicatie in bepaalde scherm van een mobiele applicatie opstarten. 4. Would/Won’t Have (a) Profiel instellingen per mobiele telefoon Per mobiele telefoon die een gebruiker heeft kan hij zelf bepalen welke notificatie hij wilt ontvangen. Bij eerste keer aanzetten kan hij een profiel nemen van een ander geregistreerde 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 gezien worden als voorwaarden waaraan gehouden moeten worden tijdens de implementatie van het systeem. 3.2.1


1. Must Have (a) Uitbreidbaarheid Eenvoudig nieuwe platforms kunnen toevoegen, waar notificaties naar verstuurd kunnen worden. (b) Onderhoudbaarheid Het systeem moet eenvoudig te onderhouden zijn. Met minimale inzet moet nieuwe functionaliteit toegevoegd kunnen worden. (c) Betrouwbaarheid Het systeem moet in staat zijn om grote hoeveelheden aan notificaties af te handelen zonder storingen. 2. Should Have Geen. 3. Could Have (a) API voor notificaties versturen Een API voor eenvoudige integratie met andere applicaties. 4. Would/Won’t Have Geen. 3.2.2

Android Demo App

1. Must Have Geen. 2. Should Have (a) Gebruiksvriendelijkheid De interfaces voor de mobiele applicatie moeten gebruiksvriendelijk zijn. 3. Could Have Geen. 4. Would/Won’t Have Geen. In het volgende hoofdstuk beschrijven we het functioneel ontwerp van het systeem dat gebaseerd is op de verkregen eisen.

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

11

4

Functioneel Ontwerp

In dit hoofdstuk wordt het functioneel ontwerp van het systeem gepresenteerd. Het functioneel ontwerp omschrijft de functionaliteit van het systeem (features) en is gebaseerd op de eisen die we in het vorige hoofdstuk hebben opgesteld. Dit ontwerp vormt een belangrijk deel van het functioneel ontwerp proces, omdat het gebruikt kan worden om te toetsen of de ontwikkelaars en de opdrachtgever dezelfde applicatie in gedachte hebben. Met behulp van use cases zullen we in de volgende paragraaf de functionaliteit beschrijven van het systeem. 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 zijn gebaseerd op de functionele eisen die de features van het systeem representeren. Hierbij worden de use cases van de niet-functionele eisen niet gegeven, omdat ze niet direct de features representeren van het systeem. Om consistent te blijven met het vorige hoofdstuk worden de use cases in dezelfde volgorde 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 worden. Een voorbeeld hiervan is het handmatig versturen van een notificatie bericht. Notificatie Applicatie: ons prototype dat onder andere zorgt voor de afhandeling van de gebeurtenissen (opvangen en verwerken) en het verzenden van de notificatie. Android Demo App: de Android applicatie, die notificaties kan ontvangen, ge¨ınstalleerd op het Android toestel van de gebruiker. Gebruiker: een gebruiker van de Android Demo App. Hij kan zich registreren bij de Notificatie Applicatie 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 ID aan de Android Demo App en het verzenden van de notificatie naar de Android Demo App afkomstig van de Notificatie Applicatie. 4.1.1


1. Must Have In dit gedeelte worden de use cases gegeven voor de features die ge¨ımplementeerd moet worden tijdens de implementatie. • Use case S1 Feature: Gebeurtenissen afvangen van een demo webapplicatie Samenvatting: Met behulp van een demo webapplicatie kan handmatig bepaalde gebeurtenissen gegenereerd worden. Indien zo een gebeurtenis tot een Topic behoort, moet die afgevangen worden. Preconditie: De gegenereerde gebeurtenissen behoren tot een Topic die abonneerbaar is. 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 S2 Feature: Verbinding opzetten tussen Notificatie Applicatie en Google Cloud Messaging (Android) Samenvatting: De verbinding verzorgen tussen de Notificatie Applicatie en de Google Cloud Messaging (GCM) server. Preconditie: De Notificatie Applicatie heeft de benodigde gegevens om gebruik te kunnen maken van de Google Services. Stappen: 1. De Android Demo App registreert zich bij de GCM server om push berichten te ontvangen. 2. De GCM server registreert deze Android Demo App en geeft een registratie ID terug. 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 de Android Demo App. Resultaat: Er is een verbinding opgezet tussen de Android Demo App en de GCM server. • Use case S3 Feature: Gebruikers ophalen behorend bij een bepaalde Topic Samenvatting: Bij een gegeven Topic moeten de gebruikers opgehaald worden die zich voor deze Topic hebben geabonneerd. Preconditie: Gebruikers hebben zich geabonneerd op bepaalde Topics en de Demo Webapplicatie 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 gebruikers die voor deze Topic hebben geabonneerd. Resultaat: De Notificatie Applicatie weet welke groep gebruikers op deze Topic heeft geabonneerd. • Use case S4 Feature: Versturen van een persoonlijke notificatie Samenvatting: Het versturen van een persoonlijke notificatie naar een gebruiker die zich heeft geabonneerd op een bepaalde Topic. Preconditie: De Notificatie Applicatie krijgt een gebeurtenis binnen om een persoonlijke notificatie te versturen naar een bepaalde Topic. (Use case: S1-S3) Stappen: 1. De Notificatie Applicatie verifieert of de desbetreffende gebruiker zich heeft geabonneerd 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 S5 Feature: Versturen van een groep notificatie Samenvatting: Het versturen van een groep notificatie naar alle gebruikers die zich hebben geabonneerd op een bepaalde Topic. Preconditie: De Notificatie Applicatie krijgt een gebeurtenis binnen om een groep notificatie te verzenden naar een bepaalde Topic. (Use case: S1-S3) Stappen: 1. De Notificatie Applicatie haalt alle gebruikers op die zich geabonneerd hebben op deze Topic. 2. De Notificatie Applicatie verzendt de notificatie naar de gebruikers. Resultaat: De gebruikers die zich geabonneerd hebben op deze Topic krijgen een notificatie binnen. • Use case S6 Feature: Abonnementen toevoegen Samenvatting: Voeg een abonnement toe als een gebruiker zich op een bepaalde Topic heeft geabonneerd. Een abonnement beschrijft op welke Topic een gebruiker zich heeft geabonneerd. Preconditie: De Notificatie Applicatie heeft een lijst van Topics waarop geabonneerd kan 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 S7 Feature: Abonnementen verwijderen Samenvatting: Verwijder een abonnement als een gebruiker zich voor een bepaalde Topic heeft afgemeld. Preconditie: De Notificatie Applicatie heeft een lijst van Topics waar gebruikers zich van 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 S8 Feature: Gebruiker toevoegen Samenvatting: Een lijst van gebruikers. Een gebruiker moet hieraan toegevoegd kunnen worden. Preconditie: De Notificatie Applicatie heeft een lijst van gebruikers en de gebruiker bevindt 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 S9 Feature: Verzoeken afvangen en verwerken van de Android Demo App Samenvatting: Verzoeken van de Android Demo App moeten afgevangen worden en vervolgens 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 bijbehorende procedure aan te roepen. Resultaat: Het verzoek is ontvangen en verwerkt. 2. Should Have Dit deel beschrijft de use cases die ontworpen zijn voor de features die ge¨ımplementeerd dienen te worden tijdens het project. In hoge nood mag ervan worden afgeweken. • Use case S10 Feature: Handmatig notificaties versturen Samenvatting: 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 S11 Feature: Afmeldingen abonnement bijhouden Samenvatting: Een lijst bijhouden met alle afmeldingen. Preconditie: Er bestaat een lijst van gebruikers en er komt een verzoek binnen om zich af te melden voor een bepaalde notificatie. (Use case: S1 en S7) Stappen: 1. De Notificatie Applicatie krijgt een verzoek binnen voor het afmelden van een bepaalde 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 Have In dit gedeelte worden de use cases gegeven voor de features die het liefst wel ge¨ımplementeerd worden, maar indien er niet genoeg tijd is voor de implementatie is dat niet noodzakelijk. • Use case S12 Feature: Quality of Service Samenvatting: Bijhouden of bericht correct is verzonden en zo niet nog een keer proberen 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 opnieuw verzonden. Resultaat: De notificatie is ontvangen, eventueel na meerdere pogingen. • Use case S13 Feature: Gebeurtenissen afvangen voor de Exact Online webapplicatie Samenvatting: De Exact Online webapplicatie genereert bepaalde gebeurtenissen. Indien zo een gebeurtenis tot een Topic behoort, moet die afgevangen worden. Preconditie: De gegenereerde gebeurtenissen behoren tot een Topic die abonneerbaar is. 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 Exact Online webapplicatie. 4. Would/Won’t Have Dit deel beschrijft de use cases voor de features die in deze versie van het systeem niet worden ge¨ımplementeerd. In volgende versies zou gekozen kunnen worden om ze alsnog te implementeren. • Use case S14 Feature: Ondersteuning voor andere mobiele platformen Samenvatting: Notificatie verzenden naar andere mobiele platformen (bijvoorbeeld: iOS, Windows Mobile, etc). Preconditie: De Notificatie Applicatie heeft de benodigde gegevens voor het verzenden van een notificatie. Stappen: 1. De Notificatie Applicatie verzorgt voor het opzetten van een verbinding om een notificatie 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

4.1.2

Android Demo App

1. Must Have • Use case M1 Feature: Registreren van de Android Demo App Samenvatting: De Android Demo App die ge¨ınstalleerd is op een Android telefoon moet zich kunnen registreren bij de GCM server en vervolgens bij de Notificatie Applicatie. Preconditie: Mobiele telefoon is verbonden met internet en heeft de Android Demo App 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 Notificatie Applicatie. Resultaat: De Android Demo App is geregistreerd bij de Notificatie Applicatie. • Use case M2 Feature: Notificaties ontvangen op de Android Demo App Samenvatting: Verstuurde notificaties moeten ontvangen en weergegeven worden op de Android Demo App. Preconditie: Mobiele telefoon is verbonden met internet en heeft de Android Demo App ge¨ınstalleerd die het ontvangen van GCM notificatie ondersteund. (Use case: S1S3, 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 M3 Feature: Abonneren op een Topic Samenvatting: De gebruiker moet zich kunnen abonneren op een bepaalde Topic. Preconditie: De gebruiker bevindt zich in de Android Demo App. (Use case: S9 en M1) 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 M4 Feature: Afmelden voor een Topic Samenvatting: De gebruiker moet zich kunnen afmelden voor een bepaalde Topic. Preconditie: De gebruiker bevindt zich in Android Demo App en is aangemeld voor een Topic. (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 M5 Feature: Opties voor aangemelde Topics aanpassen Samenvatting: Bepaalde Topics kunnen meerdere opties bevatten, de gebruiker moet deze kunnen instellen. Een voorbeeld hiervan is het aangeven van de frequentie voor het ontvangen van de notificatie. Preconditie: De gebruiker bevindt zich in de Android Demo App en heeft zich aangemeld 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 heeft geabonneerd. 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 M6 Feature: Verwerk ontvangen notificatie Samenvatting: Een actie afhandelen die hoort bij een specifieke notificatie. Bijvoorbeeld, applicatie in bepaalde scherm van een mobiele applicatie opstarten. Preconditie: Android Demo App heeft notificatie ontvangen. (Use case: S4 of S5, M1 en 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

4. Would/Won’t Have • Use case M7 Feature: Profiel instellingen per mobiele telefoon Samenvatting: Per mobiele telefoon die een gebruiker heeft kan hij zelf bepalen welke notificatie hij wilt ontvangen. Bij eerste keer aanzetten kan hij een profiel nemen van een ander geregistreerde mobiele telefoon die ook van deze gebruiker is. Preconditie: De gebruiker bevindt zich in de Android Demo App. (Use case: S9 en M1) 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 dezelfde notificatie categorieën geabonneerd als de genomen profiel. 4. Indien gebruiker geen eerdere profiel neemt, dan kan de gebruiker kiezen voor de notificatie categorieën 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 technisch ontwerp beschrijft het ontwerp in termen van technische specificaties. Met behulp van het functioneel 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 de verschillende componenten die het systeem zal bevatten. Dit overzicht bestaat uit UML diagrammen en een beknopte beschrijving van de werking per component. Ook zal er een uitgebreidere klasse-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 mogelijkheid om nieuwe Push Service implementaties toe te voegen. Het toevoegen moet kunnen gebeuren zonder dat er veel code herschreven moet worden. De Notification Trigger wordt gebruikt om handmatig twee soorten notificatie berichten te genereren. De ene notificatie bericht is bedoeld voor iedereen die zich op een bepaalde Topic hebben geabonneerd. De andere soort notificatie bericht is gekoppeld aan zowel een Topic als een bepaalde persoon. Zodra een notificatie bericht is gegenereerd zal de Message Broker op de hoogte worden gesteld en de afhandeling verder verzorgen. De Notification Trigger kan uitgebreid worden met de mogelijkheid om te reageren op gebeurtenissen uit een andere applicatie. De Message Broker koppelt notificatie berichten met de gebruikers die zich voor een Topic hebben aangemeld. Indien er een persoonlijk bericht verstuurd moet worden, controleert de Message Broker of de persoon zich ook daadwerkelijk heeft geabonneerd op de specifieke Topic. De gecombineerde informatie wordt doorgestuurd naar de Dispatcher. De geabonneerde gebruikers bevinden zich in een database, waar de Message Broker mee kan communiceren. Gebruikers kunnen zich ook via de Message Broker abonneren op Topics. De Dispatcher heeft kennis van de externe push service die ondersteund wordt. Iedere push service heeft een specifieke implementatie van de notificatie nodig en een specifieke manier van communiceren met de service. De Dispatcher moet dus in staat zijn om per ondersteund mobiele toestel de juiste implementatie te verzorgen voor zowel de communicatie met de push service als voor 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 meer mobiele toestellen bezitten. De gebruiker kan op 0 of meer categorieën zijn geabonneerd. Iedere abonnement 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 van het systeem. Per klasse wordt een beknopte beschrijving gegeven. We maken onderscheid in een notificatie dat getoond wordt op een mobiel toestel en de Notification object die wij gebruiken in ons systeem. De Notification object is de implementatie van de daadwerkelijke databestand die verwacht wordt door de externe Push Service. De externe Push Service is vervolgens in staat om met behulp van het bestand de juiste telefoon te adresseren met de juiste notificatie bericht. De telefoon ontvangt vervolgens de correcte notificatie, in dit geval dus het juiste berichtje. Om het aanpassen van onze implementatie in de toekomst te vereenvoudigen hebben we veelvuldig interfaces gebruikt in ons ontwerp. Het toevoegen van nieuwe implementaties van PushServices en de bijbehorende Notificaties en PushChannels wordt daardoor ook eenvoudiger. De DispatcherClient is niet op de hoogte van de daadwerkelijke implementatie en kent alleen de interface van de PushServices. We maken gebruik van het factory design pattern om de creatie van objecten op een centrale locatie af te handelen [2]. Hierdoor wordt het eenvoudiger om nieuwe implementaties van PushServices in het systeem te koppelen. De DispatcherClient wordt door gebruik te maken van de PushServiceFactory ’dom’ gehouden over de daadwerkelijke implementatie van de PushService. De implementatie van de PushService is verantwoordelijk voor het maken van de juiste Notification object. Dit object wordt meegegeven aan de PushChannel, die verantwoordelijk is voor de communicatie met de externe Push Service. Beide instanties zijn gebonden aan een specifieke PushService, 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 bij een bepaalde PushService implementatie horen. Iedere PushService is dus in staat om de juiste implementatie van de Notification en PushChannel aan te maken en te gebruiken. De PushChannel is zoals gezegd verantwoordelijk voor de communicatie met de externe Push Service die wordt aangesproken door het systeem. Via de PushChannel wordt de daadwerkelijke Notificatie 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 combinatie met het bericht doorgeven aan de DispatcherClient. De DispatcherClient zorgt ervoor dat de gebruikers toestellen, afhankelijk van hun OS, worden behandeld door de juiste PushService. Ieder OS maakt namelijk gebruik van een eigen specifieke Push Service. Met behulp van de PushServiceFactory worden de ondersteunde PushServices aangemaakt 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 goed is getest. Door het goed testen van de code kan er ook worden aangegeven dat de functionaliteit die in de requirements document is opgesteld ook daadwerkelijk goed functioneert. Door gebruik te maken van geautomatiseerde unit tests kan er gedurende de levensloop van de implementatie controles worden uitgevoerd en daarmee garanties worden gegeven over de werking van de code. Dit document zal aangeven welke maatregelen er getroffen worden om de code te testen. Ook zullen 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 tests te draaien en daarmee te garanderen dat alle functionaliteit nog steeds intact is. Het uitvoeren van 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 gebruiken. Met behulp van unit-tests kan er gegarandeerd worden dat iedere methode en klasse naar behoren blijft functioneren. Deze tests dienen uitgevoerd te worden na iedere build van de code en alle tests moeten slagen voordat de code wordt “gecommit” naar de server. Dat betekent dat de 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 het controleren of de juiste datatypes worden meegegeven. Verder zal er gebruik gemaakt worden van de Statische Analyse tool die in Visual Studio is ingebouwd. Deze tool zorgt voor informatie over de manier waarop de code is ontwikkeld en geeft aanbevelingen over hoe bepaalde zaken zoals performance, design en veiligheid verbeterd zouden kunnen worden. Deze plugin maakt gebruik van de Design Guidelines 5 die door Microsoft zijn opgesteld om robuust en onderhoudbaar code mee te schrijven.

6.4

Handmatige Tests

De Android Demo App zal alleen aan handmatige tests onderworpen worden. Aan de hand van de opgestelde requirements (zie hoofdstuk 3) zal de Android client getoetst worden. De overige code zal 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. 5 http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

24

6.5

Performance Tests

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

Topics Topic 1 Topic 2 -

Subscriptions (User 1 - Topic 1) (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 plaatsvinden waarin de response tijd van de applicatie wordt gemeten. We zullen meten hoe lang het duurt om batches variërend tussen de 10 en 1000 notificaties per keer te versturen. In dit geval vullen 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 topic heeft 1 abonnee, de tweede 10, de derde 100 en de vierde 1000. We versturen vervolgens vier notificatie berichten naar de vier verschillende topics. Tussen iedere aanroep wordt er gemeten hoe lang het duurt voordat de notificatie verzonden is. De resultaten zullen we presenteren in hoofdstuk 8. Het versturen van test notificaties naar meerdere Android toestellen is gebonden aan de hoeveelheid Android telefoons waarover wij kunnen beschikken. Wij kunnen indien nodig over twee testtelefoons beschikken. Daarmee kunnen we testen of het versturen van notificaties naar meerdere telefoons mogelijk is. De meeste tests zullen overigens gebruik maken van de Android Simulator 6 .

6.6

Software Improvement Group

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

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

25

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 onderdelen waaruit het systeem bestaat zullen worden toegelicht en de werking ervan zal beschreven worden.

7.1

Notification Trigger

Door middel van een demo website is het mogelijk om notificatie berichten te versturen. De website 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 naar iedereen die zich voor een Topic heeft geabonneerd of naar een individuele persoon, indien die ook heeft geabonneerd op de specifieke Topic. Om het mogelijk te maken voor een Android Applicatie om zichzelf automatisch te registreren op ons systeem, beschikt onze website ook over een ASP.NET Web-API 8 . Door middel van http aanroepen die gebruik maken van een JSON 9 formaat is het mogelijk voor onze Android demo-app om 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 mogelijk voor de Android demo-app om met het systeem te communiceren. De API maakt het mogelijk voor een Android demo-app om een registratie sleutel in de database op te slaan. De demo-app kan daarmee ook zichzelf aan of afmelden voor een Topic.

Figuur 4: Screenshot Notification Trigger. 7 http://www.asp.net/mvc 8 http://www.asp.net/web-api 9 http://www.json.org

26

7.2

Message Broker

De Message Broker communiceert met de database via de DataAccesLayer. De DataAccesLayer maakt vervolgens gebruik van het Entity-framework 10 (EF) van Microsoft. EF is een objectrelational mapper, daarmee is het mogelijk om data die in een database is opgeslagen weer te geven als een object. Hiermee is het mogelijk om met een database te communiceren, zonder daadwerkelijk SQL queries te schrijven [3]. Door gebruik te maken van de Code-First conventies is het mogelijk om de database in te richten door het database-model als object-georiënteerde klassen te implementeren. De EF zorgt er vervolgens voor dat de juiste tabellen worden aangemaakt. Het wisselen van database is erg eenvoudig, men hoeft alleen in een configuratie bestand aan te geven welke database gebruikt moet worden. In codefragment 1 vind u een voorbeeld van een model dat volgens 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 verwijzen in je klasse, zoals we zien bij UserDevices. Listing 1: Voorbeeld ORM model volgens code-first conventies. public c l a s s User { public int U s e r I d { g e t ; s e t ; } public int UserName { g e t ; s e t ; } }

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

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

7.3

Dispatcher

De taak van de Dispatcher is om de notificaties om te zetten in het platform specifieke formaat dat verlangd wordt van de push services. De Dispatcher is in staat om via een Enum type automatisch te controleren of een bepaalde push service wordt ondersteund. Zodra een nieuw type wordt toegevoegd gaat de Dispatcher er automatisch vanuit dat de specifieke implementatie klaar is en gebruikt kan worden. De Dispatcher is dus in staat om alle gebruikerstoestellen te sorteren naar ondersteunde push service om vervolgens de platform specifieke notificaties mee op te bouwen en uiteindelijk via het juiste kanaal de notificatie ook daadwerkelijk te versturen. Zoals in hoofdstuk 3 staat beschreven is de Dispatcher in staat om notificaties naar Android toestellen 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 week gereed zou kunnen maken om notificaties naar Apple toestellen te kunnen versturen. Het enige dat lastiger zal zijn is de SSL verbinding opzetten en onderhouden tussen het systeem en de Apple push service. Apple legt namelijk veel restricties op het opzetten van een verbinding [1]. 10 http://msdn.microsoft.com/en-us/data/ef.aspx

27

7.4

Android Demo App

De Android sample is een kleine Android app die beschikbaar is gesteld door Google. De app is vervolgens omgebouwd zodat het in staat is om notificaties van het systeem te kunnen ontvangen en weer te geven. Daarbij is de sample in staat om zichzelf automatisch bij de GCM service aan te melden 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 de gebruiker 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 de functionele en de niet-functionele eisen evalueren waarbij de verificatie samen met Exact zijn uitgevoerd.

8.1

Functionele Eisen

We evalueren in deze paragraaf de functionele eisen waarbij we aangeven in hoeverre we aan de eisen 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. 8.1.1


1. Must Have (a) Gebeurtenissen afvangen van een demo webapplicatie (b) Verbinding opzetten tussen Notificatie Applicatie en Google Cloud Messaging (Android) (c) Gebruikers ophalen behorend bij een bepaalde Topic (d) Versturen van een persoonlijke notificatie (e) Versturen van een groep notificatie (f) Abonnementen toevoegen (g) Abonnementen verwijderen (h) Gebruiker toevoegen (i) Verzoeken afvangen en verwerken van de Android Demo App

4 4 4 4 4 4 4 4 4

1. (a) Gebeurtenissen afvangen van een demo webapplicatie Gebeurtenissen gegenereerd uit de Demo Webapplicatie worden afgevangen door de Notificatie Applicatie. (b) Verbinding opzetten tussen Notificatie Applicatie en Google Cloud Messaging (Android) Deze functie is volledig ge¨ımplementeerd. Er wordt door de Notificatie Applicatie een verbinding opgezet tussen de Notificatie Applicatie en de GCM server. De Notificatie Applicatie kan vervolgens berichten versturen via de GCM server. (c) Gebruikers ophalen behorend bij een bepaalde Topic Zodra een notificatie verstuurd wordt naar een bepaalde Topic wordt door de Notificatie Applicatie alle gebruikers opgehaald die op deze Topic hebben geabonneerd. (d) Versturen van een persoonlijke notificatie Deze functie is ge¨ımplementeerd. Wanneer een persoonlijke notificatie wordt verstuurd naar een bepaalde Topic wordt door de Notificatie Applicatie geverifieerd of de ontvanger is geabonneerd op de desbetreffende Topic. Zo ja dan wordt de notificatie verzonden naar de ontvanger anders wordt er geen notificatie verzonden. Een persoonlijke notificatie kan via ons Demo Webapplicatie verzonden worden. (e) Versturen van een groep notificatie Wanneer een groep notificatie wordt verstuurd naar een bepaalde Topic, dan krijgen alle gebruikers die zich hebben geabonneerd op deze Topic een notificatie. Een groep notificatie kan via ons Demo Webapplicatie verzonden worden.

29

(f) Abonnementen toevoegen Via de Android Demo App kan bij de Notificatie Applicatie geabonneerd worden op een Topic. (g) Abonnementen verwijderen Via de Android Demo App kan bij de Notificatie Applicatie afgemeld worden van een Topic, mits de gebruiker zich eerder heeft geabonneerd op deze Topic. (h) Gebruiker toevoegen De gebruiker kan via de Android Demo App zich registreren bij de Notificatie Applicatie. (i) Verzoeken afvangen en verwerken van de Android Demo App De Notificatie Applicatie kan verzoeken afvangen en verwerken die afkomstig zijn van de Android Demo App. Na het ontvangen wordt de bijbehorende procedure gestart om het verzoek af te handelen. 2. Should Have (a) Handmatig notificaties versturen (b) Afmeldingen abonnement bijhouden

4 4

2. (a) Handmatig notificaties versturen Via de Demo Webapplicatie kan handmatig een persoonlijk bericht worden verstuurd naar een gebruiker die voor een bepaald Topic heeft geabonneerd (persoonlijke notificatie) of er kan een bericht worden verstuurd naar alle mensen die zich hebben geabonneerd op de betreffende Topic (groep notificatie). (b) Afmeldingen abonnement bijhouden Deze functie is ge¨ımplementeerd in het systeem. Wanneer een gebruiker zich afmeldt van een Topic dan wordt het abonnement op inactief gezet. In de database is het dan mogelijk om een lijst van afmeldingen op te vragen. 3. Could Have (a) Quality of Service (b) Gebeurtenissen afvangen voor de Exact Online webapplicatie

8 8

3. (a) Quality of Service Deze functionaliteit is niet ge¨ımplementeerd. (b) Gebeurtenissen afvangen voor de Exact Online webapplicatie Deze functionaliteit is niet ge¨ımplementeerd. 4. Would/Won’t Have (a) Ondersteuning voor andere mobiele platformen

8

4. (a) Ondersteuning voor andere mobiele platformen Het uitbreiden naar andere platformen kan later worden toegevoegd indien bekend is om welke platformen het gaan. Dit kan dan als een extra module in ons Dispatcher component komen.

30

8.1.2

Android Demo App

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

4 4

1. (a) Registreren van de Android Demo App Via 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 heeft geabonneerd. (b) Notificaties ontvangen op de Android Demo App De Android Demo App kan berichten ontvangen die vanuit de notificatie server wordt verzonden en toont het bericht. 2. Should Have (a) Abonneren op een Topic (b) Afmelden voor een Topic

4 4

2. (a) Abonneren op een Topic Via de Android Demo App kan de gebruiker zich abonneren op een bepaalde Topic. (b) Afmelden voor een Topic Via 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 binnen als er notificaties wordt verstuurd naar deze Topic. 3. Could Have (a) Opties voor aangemelde Topics aanpassen (b) Verwerk ontvangen notificatie

8 8

3. (a) Opties voor aangemelde Topics aanpassen Deze functionaliteit is niet ge¨ımplementeerd. (b) Verwerk ontvangen notificatie Deze functionaliteit is niet ge¨ımplementeerd. 4. Would/Won’t Have (a) Profiel instellingen per mobiele telefoon

8

4. (a) Profiel instellingen per mobiele telefoon Deze feature kan later worden toegevoegd die ge¨ıntegreerd kan worden met een bestaand gebruikers database, zodat voor elk gebruiker bekend is welke andere mobiele apparaten hij nog geregistreerd heeft. Na het uitvoeren van de requirements evaluaties blijkt dat alle must haves en should haves zijn ge¨ı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-functionele eisen. 8.2.1

Uitbreidbaarheid

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

Onderhoudbaarheid

Wij scoren volgens de Software Improvement Group (SIG) 4 van de 5 sterren die ze uitgeven voor onderhoudbaarheid (zie bijlage E). We kunnen dus stellen dat onze implementatie zodanig in 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 gemeten hoe lang het duurt voor ons systeem om de notificatie daadwerkelijk te versturen naar de externe push service. We hebben deze meting 100 keer uitgevoerd en het gemiddelde daarvan genomen. Zie tabel 2. Topic 1 2 3 4

#Abonnees 1 10 100 1000

Tijd (in ms) 7 10 132 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 kunnen concluderen 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 ManWai Shing.

9.1

Edwin van den Houdt

Nu het bacheloreindproject bijna ten einde is gekomen durf ik te zeggen dat ik tevreden kan terugblikken op het resultaat van de afgelopen twaalf weken. Hoewel het een enorm stressvolle tijd is geweest, heb ik er ook van kunnen genieten. Er is niet een project geweest waarin vrijwel alle aspecten van Software Engineering in samenkomen. De meeste TU projecten hebben een duidelijk afgebakend doel, waardoor het vanaf het begin duidelijk is waar je project zal eindigen. Behalve de algemene beschrijving die door Exact op Blackboard is geplaatst, was er voor dit project eigenlijk niets van tevoren vastgesteld. Het traject van requirements opstellen vond ik daardoor erg uitdagend. De gesprekken die we met Eugène hebben 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 van kunnen genieten. Gelukkig was de feedback, van onze TU begeleider Cor-Paul, op onze drafts erg duidelijk en streng, daardoor waren we instaat om alle documenten naar een hoger niveau te tillen. Gesprekken met Cor-Paul waren tijdens de eerste helft van ons project erg nuttig om ons de juiste richting in op te sturen. Wij hadden namelijk gedurende het eerste deel van het project pech dat de Exact Online afdeling erg druk was met hun eigen deadlines. Hierdoor konden wij lastig antwoorden krijgen op technische vragen die wij tijdens het opstarten hadden. Problemen die betrekking hadden op Visual Studio en de .NET omgeving waren waarschijnlijk minder problematisch geweest als we daar iemand over konden aanspreken. Gelukkig konden we in week drie van onze implementatie bij Peter terecht. Hij heeft ons vanaf toen goed ondersteund op technisch gebied, vandaar dat we Peter uiteindelijk hebben gevraagd om officieel onze technische begeleider te zijn. Tijdens dit project ben ik er ook achtergekomen dat ik heel snel problemen overdenk. Daardoor wil ik heel snel bepaalde problemen oplossen die niet per se opgelost hoeven te worden. Gelukkig wist Peter me dan weer de goede richting in te sturen, door mij duidelijk te maken dat ik me op de requirements moet focussen. Hopelijk ben ik bij volgende projecten in staat om de focus beter te richten op de aangestelde requirements waardoor ik geen tijd verlies aan het oplossen van onnodige problemen. 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 een professionele 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 dat soort zaken bij Exact wordt aangepakt. Hoewel we er nog niet zijn kan ik met een opgeheven hoofd terug kijken op een voor mij geslaagd project.

33

9.2

ManWai Shing

Vanaf het begin wist ik al dat bij het bachelorproject alle kennis die we tot nu toe hebben geleerd getoetst zal worden. Maar het toepassen van alle kennis in een bedrijfsopdracht is voor mij weer een 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 te doen. Aangezien de opdrachtomschrijving niet concreet is opgesteld gaf dit ons de gelegenheid om meer eigen inbreng te geven, wat het een stuk uitdagender maakt. Maar tegelijkertijd werd het ook een 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 voltooien van veel taken. Je leert altijd van anderen zelfs als je al bekend bent met het onderwerp. Een goede samenwerking zorgt voor een prettige werksfeer, bij ons was dit ook het geval tijdens de implementatie. Het is fijn om te weten dat er mensen zijn om je heen die je graag willen helpen. De feedback die we tijdens onze documentatie review hebben gehad van onze TU begeleider vond ik zeer leerzaam. Vooral omdat ik niet zo goed ben in Nederlands heeft dit mij geholpen, want het goed kunnen opschrijven van ideeën 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. Het zijn 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 als je uiteindelijk een werkend product ziet. Ik kijk er naar uit om mijn kennis die ik heb opgedaan tijdens de uitvoering van dit project te gebruiken en verder uit te breiden in de toekomstige projecten.

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 of iOS platform werken. De mogelijkheid om ten alle tijden notificaties te kunnen versturen naar een mobiele applicatie kan cruciaal zijn voor een goede gebruikerservaring. Bepaalde applicaties hebben er baat bij om real-time te kunnen communiceren met hun mobiele applicatie en daarmee direct nieuwe informatie met de gebruiker te kunnen delen. Daarom is het voor Exact interessant om de mogelijkheden te bekijken die eventueel in de toekomst ge¨ıntegreerd kan worden in haar mobiele apps. We hebben een notificatie systeem ge¨ımplementeerd, dat als een “proof of concept” dient. Het systeem bestaat uit een Notificatie Applicatie en een Android Demo App. De Notificatie Applicatie is in staat om gebeurtenissen af te vangen en een notificatie te verzenden. Terwijl de Android Demo App zich kan registreren en de verstuurde notificatie kan ontvangen en weergeven. Hiermee hebben we een volledige cirkel gemaakt van het verzenden van een notificatie naar de gebruiker tot het ontvangen van de notificatie. Vanwege de beperkte ontwikkeltijd is gekozen voor het ontwikkelen van een notificatie systeem dat in eerste instantie de focus legt op het Android platform. Maar het prototype zal flexibel zijn zodat het toevoegen van andere platformen eenvoudig is. Enkel het toevoegen van een push service implementatie van het specifiek platform binnen de Dispatcher zal genoeg zijn om een nieuw mobiel platform te ondersteunen voor het versturen van een notificatie. Aan het begin van dit project hebben we als onderzoeksvraag: Hoofdvraag: Welke eisen en technische implicaties zijn er verbonden aan het implementeren van een applicatie voor het versturen van mobiele notificaties naar aanleiding van gebeurtenissen gegenereerd door een webapplicatie? Het antwoord op de hoofdvraag hebben we gegeven door het implementeren van ons notificatie systeem. Puur afgaand op de “requirements evaluatie” zijn we geslaagd in het bereiken van de eisen die we aan het begin van dit project gesteld hebben. Hiermee hebben we met ons prototype laten zien wat er allemaal bij komt kijken indien een notificatie systeem ontwikkeld moet worden dat gebeurtenissen gegenereerd door een webapplicatie verwerkt. We hopen dat Exact ons prototype kan gebruiken om verder onderzoek te kunnen doen naar het versturen 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

A

Plan van Aanpak

37


Plan van Aanpak


Begeleiders: Cor-Paul Bezemer (TU Delft) Eugène Pattikawa (Exact)

Delft, 4 mei 2013

Voorwoord Dit document vormt het Plan van Aanpak dat hoort bij het Bachelorproject dat door ManWai Shing en Edwin van den Houdt zal worden uitgevoerd. In het Plan van Aanpak zal duidelijk worden welk probleem er gedurende het project zal worden opgelost. Er wordt vastgelegd welke verantwoordelijkheden de opdrachtgever en de projectleden hebben. Bovendien zal er een beschrijving gegeven worden over hoe het project gefaseerd zal worden en overige afspraken worden ook vastgelegd.

1

Samenvatting Dit is het Plan van Aanpak voor de Bachelorproject voor de opleiding Technische Informatica aan de TU Delft. De opdrachtgever voor het project is Exact. De opdrachtgever biedt web applicaties aan die zakelijke activiteiten ondersteunen. Om met de huidige trend van smartphones en 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 web applicatie zijn ingevoerd. De opdrachtgever wil graag de mogelijkheid hebben om notificaties te versturen naar de mobiele gebruikers op basis van gebeurtenissen in hun web applicatie. Het versturen van notificaties gaat op grond van gebeurtenissen die gegenereerd worden vanuit de webapplicatie. Een voorbeeld hiervan is het bijhouden van uren registratie. Voor bepaalde gebruikers is het mogelijk om de uren registratie in de webapplicatie bij te houden. In het geval een gebruiker vergeten is om zijn uren te registreren, kan daar een herinnerings-gebeurtenis voor worden gegenereerd. Aan de hand van zo een gebeurtenis zal er een notificatie (herinnering) verstuurd worden naar de desbetreffende gebruiker die zich voor deze notificatie Topic heeft aangemeld. Een Topic is een notificatie categorie waar een gebruiker zich op kan abonneren. Tijdens dit project zal met een duur van 3 maanden een “proof of concept” worden gerealiseerd van een notificatie systeem. Dit prototype zal bestaan uit de volgende componenten: Notificatie Applicatie Een applicatie die in staat is om gebeurtenissen af te vangen van de webapplicatie. Deze gebeurtenissen worden vervolgens omgezet naar notificaties. Uiteindelijk worden de notificaties volgens een correct formaat naar verschillende mobiele platforms verstuurd. Hierbij wordt rekening gehouden met welk type notificatie naar welke gebruiker moet (welk OS). Android Demo App Een eenvoudige Android applicatie, waarmee uiteindelijk de verstuurde notificatie ontvangen kan worden en correct kan worden weergegeven. Verder worden in dit Plan van Aanpak de eisen en verwachtingen van de opdrachtgever en het projectteam behandeld. Het product zal ontwikkeld worden volgens de AGILE methode. Dit houdt in dat er iedere week een applicatie opgeleverd dient te worden die werkt en getest is. Een ander bijkomend voordeel van deze ontwikkelmethode is dat eventuele veranderingen in de eisen opgevangen kunnen worden. Betrokken personen zijn: Eugène 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: Oriëntatieverslag 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Introductie

1 2 5

2 Project opdracht 2.1 Projectomgeving . . . . . . . . . . . 2.2 Doelstelling project . . . . . . . . . . 2.3 Opdrachtformulering . . . . . . . . . 2.4 Op te leveren producten en diensten 2.5 Eisen en beperkingen . . . . . . . . . 2.6 Voorwaarden . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

6 6 6 6 7 7 7

3 Aanpak en tijdsplanning 3.1 Oriëntatiefase . . . . . 3.2 Ontwerpfase . . . . . . 3.3 Implementatiefase . . 3.4 Testfase . . . . . . . . 3.5 Afrondingsfase . . . . 3.6 Tijdsplanning . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

8 8 8 8 9 9 9

4 Projectinrichting 4.1 Organisatie en personeel 4.2 Financiering . . . . . . . 4.3 Rapportering . . . . . . 4.4 Resources . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

10 10 10 10 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 alle belangrijke zakenprocessen ondersteunen voor het midden- en kleinbedrijf. Ze ontwikkelen cloudgeoriënteerde oplossingen en maatwerk voor industrieën als accountancy, retail en professionele diensten en fabricage. Sinds een paar jaar richt Exact zich ook op het ontwikkelen van mobiele apps, die werken op Android of iOS. Met behulp van deze apps kunnen ze een betere dienst aanbieden voor klanten die een beter real-time inzicht willen van hun zakelijke activiteiten. Om deze activiteiten nog beter in real-time te kunnen monitoren is het van belang dat de apps uitgerust worden met de mogelijkheid om notificaties te kunnen ontvangen. In onze oriëntatiefase hebben we onderzocht welke eisen en technische implicaties er zijn verbonden aan het implementeren van zo een mobiel notificatie systeem. Dit is in detail terug te lezen in ons Oriëntatieverslag. Dit document zal inzicht geven in de doelstelling van het project en uitleg geven over welke maatregelen getroffen worden om het project te laten slagen. Als er uiteindelijk wordt afgeweken van 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 tijdsplanning presenteren. Daarna zal er in hoofdstuk 4 ingegaan worden op de projectinrichting. Hier krijgen we inzicht in de administratieve kant van het project. Als laatste zal hoofdstuk 5 ons inzicht geven over 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 welke eisen en beperkingen we stellen aan dit project.

2.1

Projectomgeving

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

2.2

Doelstelling project

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

2.3

Opdrachtformulering

In dit project wordt een prototype van het notificatie platform gerealiseerd waarmee notificaties verstuurd kunnen worden naar mobiele applicatie gebruikers. Dit prototype zal bestaan uit de volgende componenten: Notificatie Applicatie Een applicatie die in staat is om gebeurtenissen af te vangen van de webapplicatie. Deze gebeurtenissen worden vervolgens omgezet naar notificaties. Uiteindelijk worden de notificaties volgens een correct formaat naar verschillende mobiele platforms verstuurd. Hierbij wordt rekening gehouden met welk type notificatie naar welke gebruiker moet (welk OS). Android Demo App Een eenvoudige Android applicatie, waarmee uiteindelijk de verstuurde notificatie ontvangen kan worden en correct kan worden weergegeven.

6

2.4

Op te leveren producten en diensten

Na afronding van het project zullen de volgende producten worden opgeleverd: • Oriëntatieverslag • 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 en dient als een “proof of concept”. Het prototype moet het mogelijk maken om gebeurtenissen op te vangen van de webapplicatie en deze vervolgens om te zetten naar notificaties. Deze notificaties moeten uiteindelijk ontvangen worden op het mobiele apparaat. De notificatie mogelijkheid zal in eerste instantie gericht worden op het Android platform. Voor het iOS platform is voor de ontwikkeling een developer license nodig die we tijdens het project niet tot onze beschikking hebben. Maar het prototype zal flexibel zijn zodat het toevoegen van andere platformen eenvoudig is.

2.6

Voorwaarden

De projectleden dienen aan de hand van de “Eisen en beperkingen” in paragraaf 2.5 de producten op te leveren die vermeld staan onder “Op te leveren producten en diensten” in paragraaf 2.4. De opdrachtgever ondersteunt de projectleden voor de levering van de benodigde bronnen ter behulp van de ontwikkeling van de producten. De projectleden hebben per week een gesprek met de projectbegeleider dat als controlepunt van de projectstatus dient.

7

3

Aanpak en tijdsplanning

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

3.1

Ori¨ entatiefase

In de oriëntatiefase is er onderzoek gedaan naar de eisen en technische implicaties die verbonden zijn aan het implementeren van een server en client applicatie voor het versturen van mobiele notificaties. Het onderzoek zal gebruik maken van bronnen op het internet, papers en eventueel boeken uit de bibliotheek. Het resultaat hebben we beschreven in het Oriëntatieverslag. Uit het onderzoek blijkt dat notificaties versturen met push meer voordelen biedt dan pull. De iOS en Android platformen beschikken beide over hun eigen Push Server Notificatie systemen, die we kunnen gebruiken voor het implementeren van ons prototype. Als architectuur zal gekozen worden voor een event-driven messaging architectuur. Momenteel gaat ons voorkeur uit naar het Publish/Subscribe model. Aan het einde van onze oriëntatiefase leveren we het Oriëntatieverslag en het Plan van Aanpak op.

3.2

Ontwerpfase

Tijdens de ontwerpfase wordt een start gemaakt met vier documenten, namelijk het Requirements Analysis 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 de hand van deze documenten wordt het op abstract niveau duidelijk hoe het project daadwerkelijk ge¨ımplementeerd kan worden. In het RAD zal met behulp van het MoSCoW1 model worden beschreven 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 de werking van de features. Aan de hand van UML-diagrammen zal op abstract niveau duidelijk worden hoe het systeem in elkaar gezet gaat worden. Vervolgens bepalen we in het TDD de architectuur van het systeem. Uiteindelijk zullen we met behulp van het Testplan beschrijven hoe het 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 code worden ontwikkeld. Voor de server kant zal er gebruik gemaakt worden van het .NET framework en als ontwikkelomgeving zal Visual Studio gebruikt worden. De client kant (Android) zal ontwikkeld worden in Java met behulp van Eclipse IDE. Na afronding van deze fase zal er een werkende prototype af zijn van het systeem. Tijdens de implementatie wordt gebruik gemaakt van Agile Development. Dit houdt in dat er iedere week een applicatie opgeleverd dient te worden die werkt en getest is. Een ander bijkomend voordeel van deze ontwikkelmethode is dat eventuele veranderingen in de eisen opgevangen kunnen worden.

1 https://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 de code. 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 opgestuurd voor de eindevaluatie. Vervolgens zal het project worden afgesloten met een presentatie waarin het project wordt tentoongesteld.

3.6

Tijdsplanning

In bijlage A is de tijdsplanning weergegeven. Daarin wordt per week aangegeven welke taken gedaan dienen te worden en in welke fase van het project we ons bevinden. In week 25 is minder werk ingepland om ruimte te geven voor voorbereidingen van eventuele herkansingen in de tentamenweek daarna. Er is vervolgens ruim tijd genomen ter afronding van alle verslagen en het prototype.

9

4

Projectinrichting

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

4.1

Organisatie en personeel

Het projectteam bestaat uit twee personen, Edwin van den Houdt en ManWai Shing. Beide leden zijn verantwoordelijk voor het succesvol afronden van het project. Een ieder dient evenveel tijd te investeren in de documentatie en daadwerkelijke implementatie van het project. Daarbij dienen de projectleden zichzelf in te lezen in technieken die ze nog niet kennen vanuit de opleiding. De projectleden ontvangen directe begeleiding vanuit de TU Delft van Cor-Paul Bezemer. Vanuit Exact zal Eugène Pattikawa de begeleiding verzorgen.

4.2

Financiering

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

4.3

Rapportering

De communicatie met de opdrachtgever loopt voornamelijk via de email. Rapporten worden ten alle 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 worden na veranderingen zal er gebruik gemaakt worden van Git3 en als remote repository zal gebruik gemaakt worden van Github4 . De programma code zal ook gebruik maken van Git, wel zal de remote repository op de Team Foundation Service5 (TFS) worden ondergebracht. Los van de schriftelijke communicatie zullen de projectleden wekelijks met de begeleiders samen komen om te overleggen hoe de voortgang ervoor staat.

4.4

Resources

In verband met toegang krijgen tot de juiste broncode en ontwikkel omgeving zal onderzocht worden of de projectleden een laptop kunnen ontvangen van Exact gedurende het project. Indien dat niet het geval is zullen de projectleden gebruik maken van hun eigen laptops. Er is bij Exact in principe geen vaste werkplek voor ons aanwezig, de projectleden dienen zich flexibel in te stellen en wellicht in de kantine te werk te gaan. 2 http://www.latex-project.org 3 http://git-scm.com 4 http://www.github.com 5 http://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 zullen hieronder 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 projectleden van elkaar leren, fouten verbeteren en elkaar aanvullen. • Best practices en conventies. Door best practices en conventies aan te houden is de code beter te begrijpen en te onderhouden. Fouten kunnen hierdoor ook verminderd worden. • Aanbevelingen van SIG verwerken. Tijdens het project wordt de implementatie code naar SIG gestuurd ter beoordeling. Door de aanbevelingen te verwerken kunnen de projectleden de kwaliteit van de code verhogen. • Gebruik maken van ontwikkelomgeving. Door gebruik te maken van ontwikkelomgeving wordt de implementatie vereenvoudigd en daarmee de kans op fouten verkleind. • Gebruik maken van een Version Control System voor programmering. Hierdoor is het mogelijk om aanpassingen te volgen en eventueel terug te trekken bij problemen. Dit bevordert de samenwerking tussen projectleden. Opdrachtgever: • Eisen en verwachtingen duidelijk verwoorden. Indien de eisen en verwachtingen helder zijn verwoord, kan het resultaat beter aansluiten. • Tussentijdse voortgang evaluatie. Als de opdrachtgever periodiek de voortgang in de gaten houdt 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

12

Week - datum 16 - (17-04-2013)

Fase -

Deliverables -

17 - (22-04-2013 t/m 26-04-2013)

Oriëntatie

Concreet opdracht omschrijving

18 - (29-04-2013 t/m 03-05-2013)

Oriëntatie

-

19 - (06-05-2013 t/m 10-05-2013) 20 - (13-05-2013 t/m 17-05-2013)

Ontwerp Ontwerp + Implementatie

Oriëntatieverslag + Plan van aanpak RAD + FDD + TDD + Testplan

21 22 23 24 25 26 27 28

Implementatie Implementatie Implementatie Test Implementatie + Test Afronding Afronding

Prototype Code naar SIG Aanbeveling van SIG ontvangen Concept eindverslag Eindcode naar SIG Presentatie

-

(20-05-2013 (27-05-2013 (03-06-2013 (10-06-2013 (17-06-2013 (24-06-2013 (01-07-2013 (08-07-2013

t/m t/m t/m t/m t/m t/m t/m t/m

24-05-2013) 31-05-2013) 07-06-2013) 14-06-2013) 21-06-2013) 28-06-2013) 05-07-2013) 12-07-2013)

Beschrijving Kennismaken Exact en inzicht verkrijgen in opdracht. Opdracht beter uitwerken en eisen en beperkingen in beeld krijgen. Relevante papers opzoeken Probleem analyse. Enquete afnemen. Literatuuronderzoek afronden Starten met RAD, FDD, TDD en Testplan Afronden documentatie en start maken met Implementatie implementeren implementeren prototype af Code integreren met Exact codebase (Witteweek) Feedback verwerken Afronding eindverslag + werken aan presentatie presenteren

B

Ori¨ entatieverslag

51


Ori¨ entatieverslag


Begeleiders: Cor-Paul Bezemer (TU Delft) Eugène Pattikawa (Exact)

Delft, 7 mei 2013

Samenvatting In dit oriëntatieverslag doen we verslag van ons vooronderzoek naar het verzenden van mobiele notificaties. De focus van ons onderzoek hebben we gelegd op de volgende vraag: Hoofdvraag: Welke eisen en technische implicaties zijn er verbonden aan het implementeren van een applicatie voor het versturen van mobiele notificaties naar aanleiding van gebeurtenissen gegenereerd door een webapplicatie? 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 notificatiesystemen? Deelvraag 3: Welke event-driven messaging architecturen bestaan er die geschikt zijn voor een notificatiesysteem? Uit ons onderzoek is gebleken dat het verzenden van notificaties via push techniek de meeste voordelen biedt tegenover de pull techniek. De iOS en Android platformen beschikken beide over hun eigen Push Server Notificatie systemen, die we kunnen gebruiken voor het implementeren van ons 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 op onze verwachting van het te implementeren systeem.

1

Inhoudsopgave Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1 Inleiding

3

2 Probleemstelling

4

3 Push vs Pull 3.1 Pull . . . . . . . . . . . . . . . . 3.2 Push . . . . . . . . . . . . . . . . 3.2.1 Simulatie Push via Pull . 3.2.2 Universele Push Interface

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

6 6 6 6 6

4 Mobiele Platforms 4.1 iOS . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Apple Push Notification Server (APNS) 4.2 Android . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Google Cloud Messaging (GCM) . . . . 4.3 Windows Mobile . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

8 8 8 11 11 13

5 Event-Driven Messaging 5.1 Event-Driven Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Publish/Subscribe model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14 14 15

6 Conclusie

17

Referenties

18

. . . .

. . . .

. . . .

. . . .

2

. . . .

. . . .

. . . .

1

Inleiding

Middels dit oriëntatieverslag willen wij inzicht verkrijgen in de mogelijke technieken die van pas kunnen zijn voor het opzetten van een platform waarmee notificaties verstuurd kunnen worden naar mobiele gebruikers van Exact. De mogelijkheid om ten alle tijden notificaties te kunnen versturen naar een mobiele applicatie kan cruciaal zijn voor een goede gebruikerservaring. Bepaalde applicaties hebben er baat bij om real-time te kunnen communiceren met hun mobiele applicatie en daarmee direct nieuwe informatie met de gebruiker te kunnen delen. Om ten alle tijden notificaties te kunnen versturen naar mobiele applicaties is een persistente verbinding nodig tussen de applicatie en een server die de notificatie verstuurt. De iOS en Android platformen beschikken over hun eigen Push Server Notificatie systemen waarmee het mogelijk is om via een persistente verbinding een notificatie naar een mobiele telefoon te versturen, waarvan de applicatie niet per se is geopend. De notificatie systemen van zowel iOS als Android zullen onderzocht worden om inzicht te verkrijgen in welke protocollen dan wel voorwaarden gesteld worden aan het gebruik daarvan. Verder zal er gekeken worden naar bestaande oplossingen voor het versturen van notificaties en worden de voor- en nadelen daarvan uiteengezet. Bij dit onderzoek zal rekening gehouden worden met het uiteindelijke doel van het Bachelor eindproject, namelijk het ontwikkelen van een software product. Ons eindproduct zal bestaan uit de volgende componenten: Notificatie Applicatie Een applicatie die in staat is om gebeurtenissen af te vangen van de webapplicatie. Deze gebeurtenissen worden vervolgens omgezet naar notificaties. Uiteindelijk worden de notificaties volgens een correct formaat naar verschillende mobiele platforms verstuurd. Hierbij wordt rekening gehouden met welk type notificatie naar welke gebruiker moet (welk OS). Android Demo App Een eenvoudige Android applicatie, waarmee uiteindelijk de verstuurde notificatie ontvangen kan worden en correct kan worden weergegeven. Dit document zit als volgt in elkaar. In hoofdstuk 2 beschrijven we onze probleemstelling. Hier wordt omschreven wat we in dit rapport willen onderzoeken. In hoofdstuk 3 kijken we naar de verschillen tussen en de voor- en nadelen van de Pull en Push techniek. In hoofdstuk 4 beschrijven we de mobiele platforms op het gebied van notificatiesystemen. Het onderzoeken van de EventDriven Messaging architecturen doen we in hoofdstuk 5. Tot slot geven we onze conclusie in hoofdstuk 6.

3

2

Probleemstelling

Exact1 is een Nederlands softwarebedrijf dat in 1984 is opgericht. Ze bieden oplossingen aan die alle belangrijke zakenprocessen ondersteunen voor het midden- en kleinbedrijf. Ze ontwikkelen cloudgeoriënteerde oplossingen en maatwerk voor industrieën als accountancy, retail en professionele diensten en fabricage. Exact wil graag de mogelijkheid hebben om notificaties te kunnen versturen naar de gebruikers van hun mobiele applicaties. Het versturen van notificaties gaat op grond van gebeurtenissen die gegenereerd worden vanuit de webapplicatie. Een voorbeeld hiervan is het bijhouden van uren registratie. Voor bepaalde gebruikers is het mogelijk om de uren registratie in de webapplicatie bij te houden. In het geval een gebruiker vergeten is om zijn uren te registreren, kan daar een herinnerings-gebeurtenis voor worden gegenereerd. Aan de hand van zo een gebeurtenis zal er een notificatie (herinnering) verstuurd worden naar de desbetreffende gebruiker die zich voor deze notificatie Topic heeft aangemeld. Een Topic is een notificatie categorie waar een gebruiker zich op kan abonneren. Het moet mogelijk zijn om eenvoudig verschillende soorten notificaties te versturen die door het systeem automatisch worden gegenereerd aan de hand van gebeurtenissen. Het versturen van de notificaties zal eventueel ook handmatig kunnen via een administratie paneel. Bijvoorbeeld notificaties 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 versturen van dergelijke notificaties. Tijdens ons onderzoek hebben we de focus gelegd op de volgende vraag: Hoofdvraag: Welke eisen en technische implicaties zijn er verbonden aan het implementeren van een applicatie voor het versturen van mobiele notificaties naar aanleiding van gebeurtenissen gegenereerd door een webapplicatie? In dit document doen we verslag van ons oriënterend onderzoek naar het antwoord op deze onderzoeksvraag. Ter ondersteuning van onze onderzoeksvraag zullen we gebruik maken van de volgende deelvragen. Deelvraag 1: Wat zijn de verschillen tussen en de voor- en nadelen van de pull en push techniek? Om notificaties te versturen kan er gebruik gemaakt worden van pull en/of push technieken. We bekijken deze twee technieken om te bepalen welke geschikt kan zijn voor het notificatiesysteem. Deelvraag 2: Wat zijn de mogelijkheden op de huidige mobiele platformen met betrekking tot notificatiesystemen? Naast de gebruikte technieken is de manier waarop notificaties verstuurd worden ook afhankelijk van de gebruikte mobiele platformen. Op dit moment zijn de meest gebruikte platformen iOS, Android en Windows Mobile [11]. Door de genoemde platformen te bekijken kunnen we inzicht verkrijgen over de mogelijkheden met betrekking tot het notificatiesysteem. Deelvraag 3: Welke event-driven messaging architecturen bestaan er die geschikt zijn voor een notificatiesysteem? Er bestaan verschillende software architecturen, maar niet elke architectuur is even geschikt om een notificatie systeem mee te ontwikkelen. Voor het notificatiesysteem is het onder andere van belang dat gebeurtenissen afgehandeld kan worden en gebruikers zich kunnen aan- en afmelden voor notificaties. 1 http://www.exact.nl

4

Na onze oriëntatie willen we een prototype maken van een notificatiesysteem. Dit systeem zal bestaan uit de volgende componenten: Notificatie Applicatie Een applicatie die in staat is om gebeurtenissen af te vangen van de webapplicatie. Deze gebeurtenissen worden vervolgens omgezet naar notificaties. Uiteindelijk worden de notificaties volgens een correct formaat naar verschillende mobiele platforms verstuurd. Hierbij wordt rekening gehouden met welk type notificatie naar welke gebruiker moet (welk OS). Android Demo App Een eenvoudige Android applicatie, waarmee uiteindelijk de verstuurde notificatie ontvangen kan worden en correct kan worden weergegeven.

5

3

Push vs Pull

Om notificaties te versturen kan er gebruik gemaakt worden van pull en/of push technieken. Wij zullen het verschil tussen beide technieken uitleggen. Beide technieken worden gebruikt om communicatie tussen een client en een server te verwezenlijken. Het verschil zit uiteraard in de manier waarop dat gebeurt. Als er sprake is van pull, dan zal de client zelf regelmatig informatie van de server opvragen (pullen). In het geval van push zal de server juist de client op de hoogte houden van 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 gewoon polling genoemd [13]. In dit model verstuurt de client een verzoek naar de server en de server reageert daar synchroon of asynchroon op. Deze manier van communiceren komt er dus op neer dat de client informatie van de server moet trekken (pullen). Verder geldt voor een pull model dat alle interactie tussen de client en de server, alleen door de client wordt ge¨ınitieerd. Hetzelfde geldt ook voor het huidige opzet van het web, het HTTP protocol maakt namelijk gebruik van een pull model [5]. Dat is dan ook de reden waarom het niet triviaal is om gebruik te maken van push communicatie op het web. In paragraaf 3.2.1 zullen we uitleggen hoe het mogelijk is om met behulp 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 client daar om heeft gevraagd [5]. Een groot voordeel hiervan is dat het eenvoudiger wordt om real-time communicatie tussen client en server te verwezenlijken, zonder dat de client daar actief naar moet pollen. Door het gebruik te maken van push kan er CPU last van de client deels overgenomen worden door de server [13]. Ook kan er daardoor minder bandbreedte gebruikt worden op het netwerk. In het geval van clients die op mobiele telefoons draaien, kan het gebruik maken van push betekenen dat de accu langer meegaat, aangezien de processor niet constant verbinding hoeft te maken met één 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 manieren bereikt worden [5]. Ten eerste door heel vaak verzoeken naar de server te sturen of er iets nieuws aanwezig is. Een groot nadeel hiervan is dat het van zowel de client als de server een proces intensieve oplossing is. Ten tweede kan er gebruik gemaakt worden van long-polling. In deze opzet wordt er niet meteen een response verstuurd op een verzoek als er geen veranderingen zijn plaatsgevonden. De server houdt de verbinding voor een bepaalde tijd, over het algemeen 45 seconden. Als in de tussentijd niets is veranderd zal de server de verbinding verbreken en de client vragen 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 Universal Push Interface (UPI) ontworpen, dit model kan het ontwerpen van een algemene push service applicatie ondersteunen. Met de UPI wordt de complexiteit van de details en protocollen van de onderliggende push technologieën die horen bij de push servers van Google, Apple en Microsoft geabstraheerd. 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 een push fa¸cade is geplaatst tussen de push producenten en de concrete push systeem. De fa¸cade is transparant, ook al speelt het ook de rol van push producent. De push fa¸cade transformeert het ontvangen bericht om in een formaat die de push service verwacht. Het bericht kan vervolgens worden afgeleverd bij de juiste push systeem interface. Als laatst wordt het bericht afgeleverd aan de gebruiker.

Figuur 1: Universal Push Interface architectuur [6]. De producent maakt gebruik van een unieke code om het bericht bij de juiste gebruikers af te leveren. De code is opgemaakt uit twee delen. De ene deel is opgemaakt uit een code om aan te geven welk push systeem gebruikt moet worden en de ander is de unieke code dat hoort bij het toestel van de gebruiker.

7

4

Mobiele Platforms

Om inzicht te krijgen over de mogelijkheden die verschillende mobiele platforms bieden, zullen wij in dit hoofdstuk de mogelijkheden per mobiele platform uiteenzetten. Aangezien iOS en Android momenteel het grootste marktaandeel bezitten (respectievelijk 18.8% en 68.3%) [11], zullen wij die twee uitgebreid onderzoeken. Ver daaronder op plek 3 en 4 vinden we respectievelijk Blackberry OS en Microsoft Mobile. Er wordt overigens verwacht dat Microsoft Mobile binnen 3 jaar bijna 5 keer 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 die door beide platforms beschikbaar worden gesteld. De push mogelijkheden van Microsoft Mobile zullen we globaal beschrijven. Gezien het geringe gebruik van Blackberry OS en het feit dat Exact daar totaal niet mee bezig is zullen wij die niet behandelen. Het is overigens niet mogelijk om push berichten naar mobiele toestellen van de eerder genoemde mobiele platforms te sturen zonder gebruik te maken van hun push service. Om push berichten te versturen naar mobiele toestellen is het namelijk nodig om een persistent IP verbinding te kunnen opzetten 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 naar een ander platform te versturen.

4.1

iOS

Apple heeft voor zijn mobiel platform iOS ontwikkeld, een mobiele operating systeem dat veel core functionaliteit 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 een groot deel mogelijk om applicaties te ontwikkelen zonder dat je daarvoor een betaald developer account nodig hebt. Om je app beschikbaar te stellen via de App Store [3] is het overigens wel noodzakelijk om een developer account te hebben, zo een account voor individuele ontwikkelaars kost 99 dollar per jaar [4]. Om push berichten te kunnen versturen naar iOS toestellen is het noodzakelijk om gebruik te maken van de Apple Push Notification Server (APNS) [1]. Over het algemeen biedt Apple niet de mogelijkheid voor apps om op de achtergrond te draaien. Zonder die mogelijkheid zou een externe server dus nooit een mobiele app kunnen bereiken tenzij die op de voorgrond draait. Hoe de 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 sturen naar specifieke mobiele applicaties. De server onderhoud een versleutelde “persistent IP” verbinding tussen de server en de telefoon. Daardoor wordt het technisch mogelijk om push notificaties te 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 een geldig SSL certificaat waarmee een versleutelde verbinding tussen de applicatie server en de APNS mee opgezet kan worden. Ervaring met TLS/SSL en streaming sockets wordt aanbevolen door Apple [1]. 2 Software

Development Kit

3 https://developer.apple.com/xcode/ 4 Integrated

Development Environment

8

Notificatie versturen In figuur 2 zien we een abstracte representatie van het pad dat een notificatie aflegt voordat die te zien is op een mobiele telefoon. Verderop zullen we in detail beschrijven hoe de communicatie tussen de provider, APNS en cliënt tot stand komt. De provider verstuurt een notificatie naar de APNS, vervolgens stuurt de APNS de notificatie door naar de desbetreffende iPhone. De notificatie wordt dan weergegeven ongeacht of de applicatie is afgesloten of open staat. Indien juist ingesteld kan de notificatie de mogelijkheid bieden om de desbetreffende applicatie op te starten. 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-peer authenticatie [1]. De interface maakt gebruik van een TCP socket ontwerp waarmee binaire inhoud verstuurd kan worden, zie figuur 4 voor een schematisch overzicht van zo een pakketje. Hieronder in figuur 3 zien we schematisch hoe de verbinding tot stand komt. Een zelfde soort verbinding wordt 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 waarover communicatie met de APNS mogelijk is [1]. Er wordt onderscheid gemaakt tussen productie en 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 notificatie payload zien.

9

Notificatie payload Per verbinding wordt aangeraden om de notificaties in batches over de verbinding te versturen voor optimale performance [1].

Figuur 4: Notificatie payload. Identifier Een arbitraire waarde die deze notificatie identificeert. Dit is dezelfde identifier die wordt teruggestuurd in een error-response pakketje als APNS de notificatie niet kan interpreteren. Expiry Een vast UNIX datum uitgedrukt in seconden (UTC) die aangeeft wanneer de notificatie niet meer valide is en kan worden verwijderd. De expiry waarde gebruikt big endian. Als de expiry waarde positief is, dan zal APNS proberen om de notificatie tenminste een keer te versturen. Specificeer nul (of een waarde minder dan nul) om de APNS opdracht te geven de notificatie niet op te slaan als die niet aan is gekomen op de client. Token length De lengte van de device token (big endian). Device token De device token in binaire vorm. Payload length De lengte van de payload (big endian). De payload mag niet meer dan 256 bytes zijn en mag niet eindigen op een null. Payload De notificatie payload. De error pakketjes kunnen de volgende foutmeldingen bevatten: Status code 0 1 2 3 4 5 6 7 8 10 255

Description No errors encountered ”Processing error Missing device token Missing topic Missing payload Invalid token size Invalid topic size Invalid payload size Invalid token Shutdown None (unknown)

Best practices verbindingen opzetten Als een ontwikkelaar veel notificaties tegelijkertijd wilt verzenden, raadt Apple die ontwikkelaars aan om meerdere connecties te maken naar dezelfde gateway en de notificaties over die verbindingen te verdelen. Door dat te doen wordt de performance verbeterd ten opzichte van het gebruik van een enkele verbinding [1]. Verder wordt ook opgemerkt dat een verbinding niet meerdere keren per 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 dat een ontwikkelaar één keer per dag notificaties verstuurt naar zijn gebruikers wordt aangeraden om de verbinding af te sluiten. Feedback dienst Apple heeft een feedback dienst waarmee dagelijks kan worden opgevraagd welke toestel tokens niet meer in gebruik zijn [1]. Zo wordt het mogelijk om te voorkomen dat er onnodig notificaties verstuurd worden naar toestellen die niet meer in gebruik zijn. De dienst houdt een lijst met tokens bij per applicatie. Indien er meerdere applicaties geregistreerd zijn moeten er dus ook meerdere verzoeken gedaan worden. De verbindingsinterface is vergelijkbaar met de dienst voor het versturen van push berichten. De productie feedback is te vinden via feedback.push.apple.com op poort 2196 en tijdens het testen via feedback.sandbox.push.apple.com op poort 2196 [1].

4.2

Android

Android is het mobiele platform van Google. Applicaties in Android kunnen ontwikkeld worden met behulp van de Android SDK, Java Development Kit (JDK) en Eclipse IDE met de ingebouwde Android Developer Tools (ADT) plugin [8]. Voor het ontwikkelen van Android applicaties is het niet nodig om een betaald developer account te hebben. Om je applicatie beschikbaar te stellen via Google Play, de digitale distributie platform voor Android, heb je een Google Play publisher account nodig. Dit account heeft alleen de éénmalige inschrijvingskosten van 25 dollar [9]. Android gebruikt de Google Cloud Messaging (GCM) om push berichten te sturen naar Android applicaties op Android toestellen. In de volgende paragraaf omschrijven we de werking van GCM. 4.2.1

Google Cloud Messaging (GCM)

GCM maakt het mogelijk voor ontwikkelaars om via hun eigen applicatie servers push berichten te sturen naar Android toestellen. Dit kan een simpel bericht zijn dat aan de Android applicatie vertelt dat er nieuwe data is om opgehaald te worden van de server of een bericht van maximaal 4kb aan data. De Android applicatie hoeft niet op de achtergrond te draaien om dit bericht te ontvangen. 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 een operatie die uitgevoerd gaat worden. Een activity wordt binnen Android gebruikt om processen aan te duiden. Om push notificaties te versturen via GCM moet de ontwikkelaar in het bezit zijn van een Google account. Met de Google account kan vervolgens via de Google API Console de Google Cloud Messaging service aangezet worden [10]. Een Android telefoon die een applicatie ge¨ınstalleerd heeft met de GCM functie registreert zichzelf bij de GCM server bij het opstarten. De applicatie krijgt dan een registratie ID van de GCM server die vervolgens door de applicatie server gebruikt wordt 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 verschillende fases om alle partijen te verifiëren en om te zorgen dat het bericht naar de correcte plaats gaat. Hieronder volgt een lijst met de gebruikte ID’s en tokens: Sender ID Het projectnummer bij het aanmaken van een nieuw project via Google API Console. Dit wordt gebruikt in het registratie proces om een Android applicatie te identificeren dat toegestaan is om berichten te versturen naar het toestel. 11

Application ID De Android applicatie in kwestie die registreert om berichten te ontvangen. Deze applicatie wordt ge¨ıdentificeerd door de “package name” van het AndroidManifest.xml bestand. Dit bestand bevat essentiële informatie die het Android systeem nodig heeft om de applicatie uit te voeren. De Application ID zorgt ervoor dat de berichten naar de correcte Android applicatie gaan. Registration ID Een uniek nummer dat door de GCM server wordt uitgegeven aan de Android applicatie om berichten te mogen ontvangen. Dit nummer wordt vervolgens door de Android applicatie verzonden naar de applicatie server. Deze zal dit nummer gebruiken om elk toestel te identificeren dat zich heeft geregistreerd om berichten te ontvangen voor een gegeven Android applicatie. Een Registration ID is dus gebonden aan een bepaalde Android applicatie die op een bepaalde toestel draait. Sender Auth Token Een API sleutel die de applicatie server de toegang geeft om gebruik te maken van de Google Services. Deze sleutel wordt meegestuurd wanneer de applicatie server een bericht stuurt via de GCM server naar de Android telefoon.

Levenscyclus van GCM Tijdens het gebruik van GCM server zijn er drie hoofdprocessen te onderscheiden [10]: inschakelen van de GCM, een bericht sturen en een bericht ontvangen. Inschakelen van de GCM Het inschakelen van de GCM houdt in dat een Android applicatie op een mobiel apparaat zich registreert om berichten te ontvangen. De volgende stappen worden doorlopen: 1. De eerste keer dat een Android applicatie de bericht service gebruikt, zendt die een registratie Intent naar de GCM server. Deze registratie Intent omvat de Sender ID en de Android Applicatie ID. 2. Als de registratie een succes is, dan zendt de GCM server een Intent die een Registration ID geeft aan de Android applicatie. 3. Om de registratie af te ronden, stuurt de Android applicatie de Registration ID naar de applicatie server. De applicatie server slaat normaal gesproken deze Registration ID op in een database. Een bericht sturen Voordat een applicatie server een bericht kan versturen naar een Android applicatie moeten de volgende punten waar zijn. • De Android applicatie heeft een Registration ID die het toestaat om berichten te ontvangen voor 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 bij het 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 het verstuurt 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 Android applicatie verzonden via een Intent. De Android applicatie hoeft niet te draaien voordat die het bericht ontvangt. 5. De Android applicatie verwerkt het bericht. Een bericht ontvangen Een Android applicatie die ge¨ınstalleerd is op een mobiele toestel doorloopt de volgende stappen om 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 in een 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 te versturen naar telefoontoestellen die draaien op Windows Mobile Phone. Voorwaarde is wel dat je een developer account aanmaakt dat 37 euro per jaar kost. De communicatie met de push dienst maakt gebruik van HTTP verzoeken over een Secure Sockets Layer (SSL). De authenticatie tokens maken gebruik van OAuth 2.0, een open authenticatie standaard [15]. Er volgt nu in het kort uitleg hoe de dienst gebruikt kan worden. Je app dient een verzoek in bij de Notification Client Platform (NCP) om een push notificatie kanaal te ontvangen [15]. De NCP vraagt dan WNS om een kanaal te openen. De kanaal wordt teruggegeven in de vorm van een Uniform 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 de verantwoordelijkheid van de ontwikkelaar om deze verbinding veilig op te zetten met behulp van web standaarden [15]. Zodra je server een notificatie klaar heeft staan om te versturen kan die gebruik 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 gegenereerd. Binnen een applicatie wordt op een knop gedrukt, dan wordt er een gebeurtenis gegenereerd die een notificatie opstuurt. Het is dus een natuurlijke keuze om aan de hand van event-driven messaging onderzoek te doen naar de aanbevolen architecturen op dat gebied. We zullen in dit hoofdstuk een overzicht geven van wat event-driven architectuur is en wat het Publish/Subscribe model 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 gebeurtenissen. Een gebeurtenis, in de ondernemende zin, is een status verandering van een ondernemersproces 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 een gebeurtenis alleen dat het gebeurtenis is verstuurd. Verder heeft die geen kennis van de processen die daarna verlopen. Het is dus erg lastig om een gebeurtenis te volgen door het netwerk van processen. De meest belangrijke componenten van een EDA zijn [12, 14]: Event source of generator De oorsprong van een gebeurtenis, bijvoorbeeld een applicatie of een ondernemersproces. Event ontvangers of consumenten De ontvangers zijn ge¨ınteresseerd in bepaalde gebeurtenissen. Ze zijn in staat om de functionaliteit van een gebeurtenis uit te voeren of om de gebeurtenis te publishing in de vorm van bijvoorbeeld een alert. Event sensors Luistert of er gebeurtenissen plaatsvinden Event verwerkers Verwerkt gegenereerde gebeurtenissen, zodat ze verstuurd kunnen worden naar de juiste ontvangers. 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 merkbaar/meetbaar verandering. Zo een verandering resulteert in een aantal acties die onmiddellijk afgehandeld worden. SEP wordt normaal gesproken gebruikt om real-time processen mee aan te sturen om vertragingen en kosten mee te verkleinen. Event stream processing (ESP) In ESP bestaan er ’gewone’ gebeurtenissen en ’interessante’ gebeurtenissen. ’Gewone’ gebeurtenissen worden gescreend en bepaald of er iets ’interessants’ in staat om te versturen naar de aangemelde processen. Het is met ESP mogelijk om real-time inzicht te verkrijgen in 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” gebeurtenissen een complexe gebeurtenis uit te genereren. Complexe gebeurtenissen kunnen ermee worden geconstateerd, zodat er adequaat op gereageerd kan worden. CEP maakt dus ook gebruik van ingewikkelde algoritmen die gebeurtenissen kunnen interpreteren en matchen met de juiste acties.

14

5.2

Publish/Subscribe model

Het Publish/Subscribe model biedt de mogelijkheid voor zenders, de publishers, om berichten te sturen naar ontvangers, de subscribers. Publishers maken berichten aan van bepaalde klassen. Subscribers kunnen dan zich abonneren op bepaalde klassen die voor hun interessant zijn zonder dat ze iets afweten van de publishers [7]. In veel pub/sub systemen worden berichten van de publishers verzonden naar een tussenpersoon die een message broker wordt genoemd. De subscribers abonneren dan via deze broker. Deze broker zorgt dan voor de filtering van berichten en heeft voornamelijk als functie om berichten op te slaan en door te sturen van publishers naar subscribers. De broker kan daarnaast ook nog een rij bijhouden om prioriteiten te geven aan berichten voordat hij ze verstuurt. Hieronder in figuur 5 is 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 subscribers: List-Based Publish/Subscribe, Broadcast-Based Publish/Subscribe, and Content-Based Publish/Subscribe. List-Based Publish/Subscribe Bij List-Based Publish/Subscribe wordt een subject ge¨ıdentificeerd en wordt een lijst van subscribers bijgehouden van dit subject. Wanneer een gebeurtenis optreedt heeft dit subject de taak om de subscribers hierover een melding te geven. Broadcast-Based Publish/Subscribe Broadcast-Based Publish/Subscribe bereikt hetzelfde resultaat als List-Based Publish/Subscribe, maar benadert het op een andere manier. Een event publisher creëert een bericht en verspreidt dit vervolgens naar het Local Area Network (LAN). Een service op elke client bekijkt het onderwerpregel. Wanneer een client een match vindt tussen de onderwerpregel en waarvoor hij geabonneerd is, dan wordt het bericht verwerkt. Anders wordt het bericht genegeerd. Content-Based Publish/Subscribe Content-Based Publish/Subscribe is vergeleken met de voorgaande twee implementaties flexibeler. Berichten worden namelijk op een intelligente manier naar hun eindbestemming geleid doordat er gekeken 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 identities van de subscribers en welk bericht type ze voor ingeschreven zijn. Beiden kunnen onafhankelijk 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 alleen naar 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 subscriber is het moeilijk om na te gaan of een bericht met succes is ontvangen.

16

6

Conclusie

In dit oriëntatieverslag doen we verslag van ons vooronderzoek naar het verzenden van mobiele notificaties. Exact richt zich de laatste jaren ook op het ontwikkelen van mobiele apps, die op het Android of iOS platform werken. De mogelijkheid om ten alle tijden notificaties te kunnen versturen naar een mobiele applicatie kan cruciaal zijn voor een goede gebruikerservaring. Bepaalde applicaties hebben er baat bij om real-time te kunnen communiceren met hun mobiele applicatie en daarmee direct nieuwe informatie met de gebruiker te kunnen delen. Daarom is het voor Exact interessant om de mogelijkheden te bekijken die eventueel in de toekomst ge¨ıntegreerd kan worden in haar mobiele apps. De focus van ons onderzoek hebben we gelegd op de volgende vraag: Hoofdvraag: Welke eisen en technische implicaties zijn er verbonden aan het implementeren van een applicatie voor het versturen van mobiele notificaties naar aanleiding van gebeurtenissen gegenereerd door een webapplicatie? 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 notificatiesystemen? Deelvraag 3: Welke event-driven messaging architecturen bestaan er die geschikt zijn voor een notificatiesysteem? Uit ons onderzoek is gebleken dat het verzenden van notificaties via push techniek de meeste voordelen biedt tegenover de pull techniek. De iOS en Android platformen beschikken beide over hun eigen Push Server Notificatie systemen, die we kunnen gebruiken voor het implementeren van ons 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 op onze 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-april2013]. [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 techniques for ajax. In Web Site Evolution, 2007. WSE 2007. 9th IEEE International Workshop on, pages 15–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. The many faces of publish/subscribe. ACM Computing Surveys (CSUR), 35(2):114–131, 2003. [8] Google. Developer tools. http://developer.android.com/tools/, 2013. [Online; geraadpleegd 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 to 1.4% in 2012 despite continued growth of smartphones, according to idc. http://www.idc. com/getdoc.jsp?containerId=prUS23818212#.UL56zI5JA21/, 2012. [Online; geraadpleegd 2-mei-2013]. [12] Olga Levina and Vladimir Stantchev. Realizing event-driven soa. In Internet and Web Applications 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 Integrated 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 content to mobile users. In Distributed Computing Systems Workshops, 2002. Proceedings. 22nd International Conference on, pages 563–568. IEEE, 2002.

18

[18] Wesley W Terpstra, Stefan Behnel, Ludger Fiege, Andreas Zeidler, and Alejandro P Buchmann. A peer-to-peer approach to content-based publish/subscribe. In Proceedings of the 2nd 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 bachelorproject hebben geleerd. Visual Studio Gebruik maken van de Visual Studio IDE van Microsoft. LaTeX Documenten samenstellen in LaTeX. Gebruik maken van de juiste packages bleek tijd besparend om de opmaak in orde te krijgen. Git Werken met git als source control. Git hebben we gebruikt voor zowel de code als de LaTeX documenten. Overigens hebben we de code op een Team Foundation Server gehost en de documenten op Github. C# Programmeren met C-Sharp. Entity Framework Een ORM van Microsoft, waardoor communicatie met de database zonder het schrijven van query’s kan verlopen. Google Cloud Messaging(GCM) We zijn in staat om met de GCM server te communiceren en daarmee een notificatie te versturen naar een mobiele telefoon. Android framework Door het schrijven van de Android Demo App hebben we kennis gemaakt met het maken van Android applicaties.

72

D

Taakverdeling

We hebben per onderdeel aangegeven wie verantwoordelijk was voor het opleveren van bepaalde elementen tijdens het project. Deze punten geven ook aan hoe de werklast was verdeeld voor de genoemde punten, met betrekking tot het schrijven van de documentatie en ook voor het implementeren van de code. Plan van Aanpak Hoofdstukken schrijven evenredig verdeeld. Ori¨ entatieverslag Hoofdstukken 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 net niet behaald door een lagere score voor Unit Size. Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. 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 welke ge-refactored kunnen worden naar aparte methodes, bijvoorbeeld een ‘addTopics’methode, maar gegeven de huidige omvang van de methode is het opsplitsen niet meteen noodzakelijk. Mocht de methode groeien dan is het wel aan te raden deze op te splitsen. Over het algemeen scoort de code bovengemiddeld, hopelijk lukt het om dit niveau te behouden tijdens de rest van de ontwikkelfase. De aanwezigheid van test-code is in ieder geval veelbelovend, hopelijk zal het volume van de test code ook groeien op het moment 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, terwijl de score voor onderhoudbaarheid ongeveer hetzelfde is gebleven. Bij Unit Size zien we dat de voorbeelden die in de vorige analyse werden genoemd inmiddels zijn opgesplitst. Helaas is het niet gelukt om deze aanpak structureel door te 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. Technische Universiteit Delft. TI3800 Bachelorproject. Mobiel Notificatie Systeem

Recommend Documents