AFSTUDEERVERSLAG
Auteur : Mathieu van der Have
Datum : 06-01-2011
Versie : v1.0
Afstudeerbedrijf : Logica Nederland BV
Divisie : Working Tomorrow
Practice : Technical Software Engineering
Bedrijfsbegeleiders : dhr. M. Stikkelorum Bedrijfsmentor : dhr. I. Kaffa
Onderwijsinstelling : de Haagse Hogeschool
Opleiding : HBO Informatica
Afstudeercoördinator : A.A. Nederend
Examinator : dr. T. Cocx
Logica is a business and technology service company, employing 39,000 people. It provides business consulting, systems integration and outsourcing to cliënts around the world, including many of Europe's largest businesses. Logica creates value for cliënts by successfully integrating people, business and technology. It is committed to long term collaboration, applying
insight to create innovative answers to cliënts’ business needs.
Logica is listed on both the London Stock Exchange and Euronext (Amsterdam) (LSE: LOG; Euronext: LOG). More information is available at www.logica.com.
Copyright statement:
This document contains information which is confidential and of value to Logica. It may be used only for the agreed purpose for which it has been provided. Logica’s prior written consent is required before any part is reproduced. Except where indicated otherwise, all names, trade marks, and service marks referred to in this document are the property of a company in the Logica group or its licensors.
Versiebeheer
Versie Omschrijving
V 0.1 Eerste opzet indeling
V 0.2 Hoofdstukindeling
V 0.3 Inleiding/opmaak
V 0.4 Bedrijfsorganisatie/inception fase
V 0.5 Verdere uitwerking inception fase + opzet elaboration fase V 0.6 Opzet gehele verslag verbeterd + elaboration fase
V 0.7 Elaboration fase uitgewerkt + Construction fase opzet V 0.8 Construction + Transition fase uitgewerkt + evaluatie
V 0.9 Nacontrole
Tabel 1-1: Versiebeheer
Distributielijst
Naam Instantie Rol / Functie
Dhr. L.C.M. van Koppen Haagse Hogeschool Begeleider
Dr. T. Cocx Haagse Hogeschool Expert
Dhr. I. Kaffa Logica Bedrijfsbegeleider/mentor
Dhr. M. Stikkelorum Logica Ter review
Dhr. B. Wesselman Logica Ter review
Titelblad
Examinandus
Naam : Mathieu van der Have
Straat / Nummer : Amalia van Solmslaan 7A Postcode / Plaats : 2391 DD
Telefoonnummer : 0614555417
E-mailadres : mathieu_vanderhave@hotmail.com
Onderwijsinstelling : Haagse Hogeschool Afstudeerrichting : Informatica
Studentnummer : 20060321
Afstudeerperioade : 2010-2.1
Begeleider/Examinator
Naam : L.C.M. van Koppen
E-mailadres : l.c.m.vankoppen@hhs.nl Telefoonnummer : 079 3208787 Expert/Examinator Naam : Dr. T. Cocx E-mailadres : t.cocx@hhs.nl Telefoonnummer : 079 3208787 Bedrijfsgegevens
Naam : Logica Nederland BV
Afdeling : Working Tomorrow
Straat / Nummer : Laan van Zuid Hoorn 70 Postcode / Plaats : 2289 GD
Bedrijfsbegeleider
Naam : Marco Stikkelorum
Telefoonnummer : +31 6 51546352
E-mailadres : Marco.stikkelorum@logica.com
Functie : Projectleader Working Tomorrow Rijswijk
Bedrijfsmentor
Naam : Ivo Kaffa
Telefoonnummer : +31 6 46151032
E-mailadres : ivo.kaffa@logica.com
Functie : Technical Project Leader
Practice Manager
Naam : Bertram Wesselman
Telefoonnummer : +31 6 53327157
E-mailadres : bertram.wesselman@logica.com
Voorwoord
Dit verslag is geschreven naar aanleiding van de afgelopen vier maanden die ik heb doorgebracht bij Logica Rijswijk. Tijdens deze vier maanden heb ik een afstudeeropdracht uitgevoerd, die in het teken stond van het maken van een iPad app, waarmee gebruikers het energieverbruik van hun apparaten binnenshuis kunnen monitoren. Ik wil Logica bedanken voor de mogelijkheid die ik heb gekregen om bij hen af te studeren.
Ik wil in het bijzonder mijn begeleider bij Logica, Ivo Kaffa, bedanken voor de hulp die hij mij heeft aangeboden tijdens het afstuderen. Hij heeft ervoor gezorgd dat ik een concrete afstudeeropdracht heb kunnen maken en ik kon altijd terecht bij hem met vragen.
Ik wil Marco Stikkelorum bedanken voor de begeleiding en de gezelligheid die hij dagelijks aanbood tijdens het afstuderen. Ook bij hem kon ik altijd terecht met vragen.
Bertram Wesselman wil ik bedanken voor de hulp die hij heeft geboden bij het opstarten van mijn project en voor de mogelijkheden die hij mij heeft geboden bij Logica. Ook voelde ik me zeer gewaardeerd door Bertram, die mij behandelde als een van de mensen uit zijn team. Niet in de laatste plaats wil ik hem daarvoor bedanken.
Mijn examinatoren, dhr. Leo van Koppen en dhr. Tim Cocx wil ik bedanken voor de gegeven feedback en de ondersteuning tijdens het afstuderen.
Mijn mede-afstudeerders wil ik bedanken voor de gezelligheid en hulp die zij mij dagelijks hebben geboden tijdens het afstuderen.
Last but not least wil ik mijn familie en vrienden bedanken die mij de gehele vier maanden de steun en motivatie hebben gegeven om door te gaan en er het allerbeste van te maken. Mathieu van der Have,
Referaat
Dit document is geschreven door Mathieu van der Have, 4e jaars HBO informatica student en
dient als afstudeerverslag voor het afstudeerproject dat is uitgevoerd voor de Haagse
Hogeschool te Zoetermeer. Het afstudeerproject is uitgevoerd bij Logica B.V. in Rijswijk en heeft als titel “de iPad als Energie Monitor”.
Descriptoren: - iPad - C#
- Objective-C
- Rational Unified Process - Unified Modeling Language
Samenvatting
Dit verslag beschrijft het opzetten en de werkzaamheden van het project wat ik heb uitgevoerd gedurende een periode van 17 weken bij Logica Rijswijk. Dit project is uitgevoerd in het kader van het afstuderen voor mijn opleiding HBO Informatica. Het project betreft het ontwikkelen van een iPad app waarmee het voor gebruikers mogelijk moet zijn om het energieverbruik van hun apparaten binnenshuis in te kunnen zien en deze te kunnen bedienen. Er is geen gebruik gemaakt van fysieke apparaten omdat dit buiten de competentie set viel. Als vervanging is gekozen voor simulaties van apparaten die tevens ontwikkeld moesten worden.
Het verslag geeft een duidelijke beschrijving van de opdracht zoals deze is gedefinieerd in de beginfase van het project.
Er wordt beschreven hoe het project is opgezet aan de hand van de RUP methodiek en hoe het gebruik maakt van de fases die RUP onderscheidt. Er wordt uitgelegd hoe de
architectuurmodellen opgezet zijn waarmee de architectuur duidelijk in beeld is gebracht. Er wordt verder beschreven wat de werkzaamheden waren tijdens het ontwikkelen van de software en waar de moeilijkheden zaten tijdens dit ontwikkelen.
Er wordt afgesloten met een product en proces evaluatie, evenals een beschrijving van het aantonen van de competenties.
IPAD ALS ENERGIE MONITOR
Titelblad
4
Voorwoord
5
Referaat
6
Samenvatting
7
1
Inleiding
10
2
Bedrijfsorganisatie
11
2.1
Logica
11
2.2
Working Tomorrow
11
2.3
Sfeer
11
2.4
Begeleiding
12
3
Afstudeerproject
14
3.1
Aanleiding
14
3.2
Doelstelling
14
3.3
Probleemstelling
15
3.4
Op te leveren producten
15
3.5
Project aanpak
15
3.6
Technieken
16
3.7
Planning
17
3.8
Project betrokkenen
19
4
Inception Fase
20
4.1
1e dagen en opzet
20
4.2
Gesprek begeleider en practice manager
20
4.3
Opstellen requirements
21
4.5
Opstellen Use Cases
23
4.6
Aanpassingen PvA/planning
25
4.7
iOS Developer en “Hello World” app
25
4.8
Evaluatie “Hello World” app
26
5
Elaboration Fase
27
5.1
Architectuurmodellen
27
5.2
Klassendiagram
27
5.3
Sequentiediagram
28
5.4
Activiteitsdiagram
29
5.5
GUI designs
30
5.6
Aanpassingen requirements
31
6
Construction Fase
32
6.1
Sockets
32
6.2
Message systeem
33
6.3
Decoding/Encoding
35
6.4
Client/Server applicatie
37
6.5
Server applicatie
37
6.6
Cliënt applicatie/simulatie
42
6.7
iPad app
44
7
Transition Fase
49
8
Evaluatie
51
8.1
Proces evaluatie
51
8.2
Product evaluatie
53
8.3
Aantonen competenties
54
Verklarende woordenlijst
55
1
INLEIDING
Dit verslag is geschreven naar aanleiding van de afstudeeropdracht “iPad als energiemonitor”. In dit verslag beschrijf ik de stappen die ik heb doorlopen tijdens mijn afstudeerproject die er voor hebben gezorgd dat ik tot een volledig eindproduct ben gekomen. Ik beschrijf de werkwijze en de keuzes die ik heb gemaakt tijdens dit afstudeerproject.
Het verslag is als volgt opgebouwd:
In hoofdstuk twee, bedrijfsorganisatie, wordt beschreven waar ik binnen Logica precies werkzaam ben geweest en hoe Logica zelf is ontstaan en wat ze uitvoert.
In hoofdstuk drie, het afstudeerproject, wordt beschreven wat de aanleiding, probleem- en doelstelling van dit afstudeerproject is.
In hoofdstuk vier, de inception fase, ga ik in op wat ik heb gedaan in deze fase, o.a. het plan van aanpak opstellen, requirements opstellen en een “Hello World” app maken en waarom ik dat zo heb gedaan.
Hoofdstuk vijf gaat in op de elaboration fase, de tweede fase binnen mijn project. Dit hoofdstuk gaat in op de architectuur van de app die ik heb gemaakt voor de iPad en de gehele architectuur daar omheen.
Op de elaboration fase volgt een construction fase. In hoofdstuk zes ga ik hier op in. Hoe heb ik eventuele problemen opgelost, welke functionaliteiten waren lastig te ontwikkelen en wat waren de keuzes die ik heb gemaakt in deze fase?
In hoofdstuk zeven komt de laatste fase binnen het project aan bod, de transition fase. In deze fase is de app getest. Hoe dat is verlopen is terug te vinden in dit hoofstuk.
Het verslag wordt afgesloten met een evaluatie van het afstudeertraject, zowel van de
producten als van het proces. Ook de vooraf gekozen competenties worden hier beschreven en aangetoond.
Tot slot wil ik hier melden dat dit verslag in de verleden tijd geschreven is, aangezien er wordt teruggekeken op mijn afstudeertraject dat ik heb uitgevoerd in de afgelopen maanden.
2
BEDRIJFSORGANISATIE
2.1
Logica
Logica is een belangrijke international speler op het gebied van IT en business services met 39.000 mensen in dienst in 36 landen. Ze bieden oplossingen en diensten aan in het domein van consultancy, design, systeem integratie , bedrijfskritische applicaties en de outsourcing van bedrijfsprocessen. Logica richt zich op vier marktsectoren – Energy Utilities en Telecom,
Finance, Public Sector, en Industrie Distribution en Transport. Door deze focus zijn ze in staat om op maat gemaakte oplossingen te bieden voor de uitdagingen waar klanten in hun specifieke markt mee te maken krijgen.
Het huidige Logica is op 30 december 2002 ontstaan uit het voormalige Logica plc. (60%) en het voormalige CMG plc. (40%). CMG was in Nederland aanzienlijk groter dan Logica, die vooral een focus had in Groot Brittannië. In 2006 zijn daar nog WM-Data (zwaartepunt in Scandinavië) en Unilog (Zwaartepunt in Frankrijk) aan toegevoegd, zodat een gespreide dekking in Europa verkregen is. In 2008 is onder leiding van de nieuwe CEO, Andy Green, een programma opgestart om van alle onderdelen binnen het bedrijf een uniforme organisatie neer te zetten - One Logica. Hierbij zijn de waarden gedefinieerd, volgens welke iedere “Logicaan” zou moeten werken: Committed, Innovative en Open. De missie die hierbij gesteld is, is “To be the most trusted innovation partner”.
2.2
Working Tomorrow
Als afstudeerder wordt je bij Logica opgenomen in het Working Tomorrow (WT) programma. Dit programma biedt studenten de mogelijkheid om af te studeren door een innovatieve opdracht uit te voeren met goede begeleiding. Ik ben opgenomen in WT bij Logica Rijswijk.
In Rijswijk heeft WT op de zesde verdieping een eigen afdeling waar bureaus staan voor ongeveer 12 afstudeerders. Ieder bureau heeft een eigen computer waarop “WT’ers” kunnen inloggen en werken. Marco Stikkelorum is de projectleider van WT in Rijswijk en was dan ook iedere dag aanwezig voor directe begeleiding. Hij is verantwoordelijk voor alles wat met WT Rijswijk te maken heeft, zoals werving en selectie van studenten, facilitaire zaken en ervoor zorgen dat het proces van afstuderen van begin tot eind correct verloopt.
Alle studenten die bij WT afstuderen zijn daarnaast ook onder gebracht in een practice die nauw aansluit bij de opdracht. Deze practice bestaat uit een team IT professionals die verschillende projecten uitvoeren, aansluitend op hun vakgebied. Ik werd ondergebracht in de practice TSE, Technical Software Engineering. Dit omdat mijn opdracht voor een groot deel programmeren bevatte (software ontwikkeling) en dat is precies wat ze doen in het TSE team, programmeren. Het TSE practice team houdt zicht bezig met het SPITS project1 en met Space projecten.
Laatstgenoemde is “classified” en daar heb ik dan ook weinig informatie over gekregen. Alle informatie die ik wel heb verkregen mag niet gedeeld worden in dit document.
2.3
Sfeer
De sfeer bij Logica is zeer aangenaam te noemen. Er wordt informeel doch zakelijk naar elkaar gekeken en men behandelt elkaar als gelijkwaardig. Ook WT’ers worden eerder aangekeken als
Young Professionals en niet als “een studentje”. Ik werd nauw betrokken bij de bezigheden van het TSE team waar ik in geplaatst werd. Zo werd ik uitgenodigd voor team meetings en practice meetings. In team meetings wordt ingegaan op de voortgang binnen de projecten die TSE uitvoert en op practice meetings wordt meer ingegaan op individuele personen. Zo kwam tijdens de practice meeting waar ik bij aanwezig was aan bod wat Logica zijn werknemers biedt en of men daar tevreden over was. Om duidelijk te maken waar WT en TSE gepositioneerd zijn binnen Logica volgt hier een organogram.
2.4
Begeleiding
Zoals eerder vermeld is Marco de projectleider bij WT Rijswijk. Hij was iedere dag aanwezig op locatie en alle afstudeerders konden dan ook naar hem toe voor directe begeleiding en vragen over algemene zaken zoals inloggegevens, afspraken verzetten, enz.
De WT architect is Edwin Essenius. Hij zorgt voor de borging van het innovatiegehalte, nieuwe opdrachten, het reviewen van PvA en eindrapportages en is bereikbaar voor algemene
technische vragen.
Ook kreeg iedere afstudeerder een persoonlijke begeleider toegewezen uit de practice waarin hij/zij is geplaatst. Mijn begeleider was Ivo Kaffa, een programmeur uit het TSE team. Met deze begeleider werd iedere week een afspraak gemaakt om de voortgang door te bespreken en als er lastige inhoudelijke vragen beantwoord moesten worden dan was Ivo de man om aan te spreken.
Als laatste stakeholder binnen logica werd aan iedere afstudeerder ook een practice manager toegewezen. Dit was in mijn geval Dhr. B. Wesselman, de manager van het TSE team. Ook hij was zeer geïnteresseerd in mijn opdracht en met hem heb ik dan ook om de 2 à 3 weken een voortgangsgesprek gehad.
Om de positie van mij binnen Logica duidelijk te maken som ik hier alle personen en afdelingen op:
- Werkzaam op de Working Tomorrow afdeling, hier zitten uitsluitend afstudeerders. - Project wordt uitgevoerd in opdracht van het TSE team (of “de practice TSE”). - Wordt binnen logica inhoudelijk begeleid door begeleider (Ivo Kaffa) en practice
manager (Bertram Wesselman) uit het TSE team.
- Directe feedback van Marco Stikkelorum, de WT projectleider Rijswijk. - Op aanvraag feedback van Edwin Essenius, de WT architect.
3
AFSTUDEERPROJECT
3.1
Aanleiding
Duurzaam energie gebruik, een term die actueel is en waar veel over gesproken wordt. Mensen moeten bewuster worden van de energie die hun apparaten dagelijks gebruiken.
Een onderzoek onder huishoudens geeft aan dat directe feedback over het actuele energieverbruik (stroom en gas) daadwerkelijk kan helpen significante besparingen te bereiken2.
Een home remote control is een systeem waarmee bepaalde apparaten binnenshuis op afstand kunnen worden bediend. Denk hierbij aan het aanpassen van de temperatuur van de
verwarming, het aan en uit schakelen van het licht en het aan en uit schakelen van de tv. Dit wordt gerealiseerd door het gebruik van een remote die daar functionaliteit voor verleend. De iPad is een tablet van fabrikant Apple en wereldwijd zijn er miljoenen exemplaren verkocht. Voor developers is het een interessant apparaat om applicaties (hierna: apps) voor te maken, aangezien er een groot publiek mee wordt bereikt. Ook voor Logica is het interessant om apps te maken, dit blijkt ook uit het feit dat Logica recentelijk een app voor medische doeleinden heeft gelanceerd voor de IPhone3.
De iPad van Apple kan gebruikt worden als remote home control omdat deze tablet de hardware biedt die benodigd is om signalen uit te zenden die door andere controllers kunnen worden opgevangen (WiFi, Bluetooth, IR).
Binnen home remote control zijn verscheidene toepassingen te verzinnen. Er bestaat op dit moment een applicatie waarmee gebruikers hun lichten aan en uit kunnen doen, hun tv aan en uit kunnen zetten en de temperatuur van hun verwarming kunnen regelen. Maar als men wil weten hoeveel energie deze apparaten gebruiken en hierover informatie wil hebben, dan zullen er functionaliteiten toegevoegd moeten worden. Logica wilde een app gaan ontwikkelen die dit realiseert en hierdoor kan assisteren bij het duurzaam gebruik van energie.
3.2
Doelstelling
Het doel van het project was om een gebruiker van een iPad inzicht te geven in het
energieverbruik binnenshuis en de gebruiker de mogelijkheid te bieden een apparaat in of uit te kunnen schakelen met behulp van een iPad app. Er moest een framework worden gemaakt waar nieuwe apparaten eenvoudig aan toe te voegen konden worden, zodat in verdere
ontwikkelingen het monitoren en inschakelen van meerdere apparaten gemakkelijk te realiseren was.
Het was niet realistisch om een volledig uitgewerkte app te maken in de tijd die ervoor was gepland. Binnen de app wordt de mogelijkheid gegeven om van één apparaat het
energieverbruik te kunnen monitoren en dit apparaat in of uit te kunnen schakelen. Mocht dit zo gemakkelijk te verwezenlijken zijn dat er nog geruime tijd over is binnen de gestelde tijd voor het project, dan was er ruimte voor uitbreiding door er voor te zorgen dat meerdere apparaten
2 http://www.ucpartners.eu/user_files/file/onderzoeksrapport_energiedisplay.pdf
3
in of uit geschakeld kunnen worden via een iPad app. De verwachtingwas echter dat met de initiële opdracht voldoende diepgang werd gerealiseerd om het afstudeertraject mee te vullen.
3.3
Probleemstelling
Er was bij aanvang van het project geen iPad app die inzicht gaf in hoeveel energie er verbruikt wordt binnenshuis, en welke apparaten daar schuldig aan zijn. Deze app moest ontwikkeld worden. De app moest ook de mogelijkheid bieden om op afstand een apparaat in of uit te kunnen schakelen, als er geconstateerd werd dat deze een bepaalde waarde aan energie verbruikte. Deze waardes waren op dat moment nog niet bekend, het was aan de gebruiker zelf of hij/zij er voor koos om het apparaat in of uit te schakelen.
3.4
Op te leveren producten
- PvA - Ontwerpen/diagrammen o Use Cases o Klassendiagram o Sequence diagram o Activity diagram o GUI design - iPad app - Cliënt/server applicatie - Afstudeerverslag - Highlight reports4- Een rapport met daarin de belangrijkste gebeurtenissen over de voorafgegane periode en een vooruitblik naar de komende periode. Dit rapport werd wekelijks opgestuurd naar begeleiders, practice manager en expert, om hun op de hoogte te houden van ontwikkelingen binnen het project.
De cliënt/server applicatie is er bij gekomen in een latere fase van het project. In paragraaf 4.4 wordt duidelijk gemaakt wat hiervoor de redenen waren. Het is echter wel een op te leveren product, vandaar dat deze applicatie ook hier wordt genoemd.
3.5
Project aanpak
Omdat het afstudeerproject een software ontwikkelingstraject betreft heb ik gekozen voor een project aanpak met behulp van de RUP methodiek. Dit is de methodiek die vanuit school wordt toegepast op projecten waar software ontwikkeling centraal staat. De keuze voor RUP is gebaseerd op eigen ervaring en in overleg met mijn begeleider bij Logica.
RUP is een iteratieve methode voor het ontwikkelen van software. Bij het indelen van de iteraties is uitgegaan van de fasering die RUP hanteert:
Iedere fase heeft verschillende doelstellingen, mijlpalen en resultaten. In overleg met mijn begeleider is de elaboration en construction fase van het project opgedeeld in iteraties. Hoe deze iteraties eruit zien en wat er in iedere iteratie en fase werd ontwikkeld is te vinden in de planning, bijlage A en wordt toegelicht in paragraaf 3.7.
Omdat rup werkt met iteraties is in overleg met mijn begeleider besloten om hier in de
elaboration en construction fase gebruik van te maken.. Dit met de gedachte dat iedere iteratie een prototype zou opleveren, waar commentaar op geleverd kon worden, wat het eindproduct ten goede zou komen. Dit heb ik dan ook gebruikt in mijn project aanpak en verwerkt in mijn planning.
Ook gaf mijn begeleider uit praktijkervaring aan dat het slim was om een week als “onvoorzien” in te plannen. Dit omdat het bij software ontwikkeling in de praktijk vaak voorkomt dat een aantal geplande taken niet volgens planning afgerond worden en men de onvoorziene week kan gebruiken om dit alsnog af te ronden. Ook deze week heb ik gebruikt in mijn project aanpak en vewerkt in mijn planning.
3.6
Technieken
Tijdens dit project worden de volgende technieken toegepast:
- Unified Modeling Language (UML): voor het ontwerpen van de benodigde architectuurmodellen en de use-cases.
- Objective-C: De taal waarin de iPad app geschreven zal worden.
- C#: De taal waarin de cliënt/server applicaties geschreven zullen worden. - TMap: Testtechniek.
- MoSCoW-analyse
Ik heb gekozen voor het gebruik van UML omdat dit voor mij een bekende techniek was en ik hier prettige ervaringen mee had vanuit school projecten. Ook gaat RUP er vanuit dat use cases worden opgesteld, hier is UML een zeer geschikte techniek voor. Bij Logica wordt ook uitvoerig gebruik gemaakt van UML, wat kan helpen bij het opstellen van de diagrammen.
Het gebruik van Objective-C als programmeertaal was geen keuze te noemen; iedere applicatie en alle software die geschreven wordt voor iOS (het OS voor mobiele systemen van Apple) worden standaard geschreven in deze taal en hier is dan ook niet vanaf te wijken. Dit is een taal waar ik niet bekend mee ben. Het is echter wel een afgeleide van de programmeertaal C (of
eerder een superset) waar ik wel enige ervaring vanuit school mee heb. Ik verwacht dan ook weinig moeilijkheden bij het leren van deze taal. Alle apps voor iOS worden ontwikkeld met behulp van de IDE van Apple, genaamd XCode. Hier zijn geen alternatieven voor. Apple geeft geen mogelijkheid om een andere IDE te gebruiken.
De keuze van C# voor de cliënt/server applicatie is wederom gebaseerd op praktijkervaring vanuit school. Ik vind C# een prettige taal om in te programmeren en kan daardoor in een beperkte tijd een goede applicatie ontwikkelen. Ook Logica gaf aan veel te programmeren met behulp van C#, wat natuurlijk goed van pas kon komen. De cliënt/server applicatie wordt ontwikkeld met behulp van de IDE van Microsoft, Visual Studio 2010. Dit omdat ik alle C# programma's die ik heb geprogrammeerd in de afgelopen jaren, geprogrammeerd heb met behulp van Visual Studio 2010.
TMap is de testmethode die voor mij het meest voor de hand lag, aangezien ik deze methode al een aantal malen heb toegepast in schoolprojecten.
3.7
Planning
De planning is opgenomen in bijlage A, te vinden achter in dit document. Dit is de planning zoals deze in de beginfase van het project is opgesteld. De planning is opgedeeld in fases en iteraties aan de hand van de RUP methodiek.
Met behulp van de ervaring die ik heb opgedaan op school heb ik de fases en iteraties als volgt ingedeeld:
Inception fase
In de inception fase wordt het PvA5 geschreven en goedgekeurd. Vanuit school had ik de
ervaring die mij zei dat twee weken genoeg moest zijn voor het schrijven en goedkeuren van het PvA. Zo heb ik deze dan ook opgenomen in mijn planning. Logica adviseerde mij vier weken te nemen voor alleen het schrijven van het PvA, dit vond ik echter een te lange tijd. Ik kon de twee weken die ik hiermee bespaarde goed gebruiken voor het schrijven van een " Hello World app" op de iPad, aangezien ik geen ervaring had met het maken van iOS applicaties.
Deze keuze heb ik dan ook doorgevoerd en achteraf ben ik hier erg blij mee, omdat de iPad app, en dan met name het ontwikkelen van deze app met behulp van XCode en Objective-C, veel problemen heeft veroorzaakt en me veel tijd heeft gekost. Als ik daar nog later mee was begonnen, en dus besloten had om in de inception fase geen "Hello World app" te ontwikkelen, had het project in gevaar kunnen komen.
Ik had initiëel het opstellen van use cases gepland in de elaboration fase, in overleg met mijn begeleider heb ik besloten deze op te stellen in de inception fase. Dit omdat use cases het gedrag van het systeem beschrijven en het was van belang om dit in een zo vroeg mogelijk stadium te weten.
De requirements opstellen is vanuit RUP gezien een activiteit die begint in de inception fase, de belangrijkste activiteit is in de elaboration fase en afgerond wordt tijdens de construction fase. Ik heb dan ook in mijn planning opgenomen dat de requirements opgesteld worden in de inception fase. Later zijn in de elaboration fase de requirements herzien, doordat de app in deze fase concreter werd, en er hiermee meer requirements naar voren kwamen.
Elaboration en Construction fase
"Belangrijk onderdeel van RUP is het iteratieve aspect". Deze zin mailde mijn begeleider bij Logica mij, nadat hij een eerste versie van mijn planning had ingezien. Ik had in de planning namelijk nog geen rekening gehouden met het iteratieve aspect. Natuurlijk was dit wel van belang, omdat dit helpt bij het ontwikkelen van de app.
Ik heb dan ook de elaboration en construction fase opgedeeld in iteraties. In deze twee fases wordt namelijk het overgrote deel van de op te leveren producten ontwikkeld. Ik besloot drie iteraties aan te houden, omdat dit paste in de 17 weken die gereserveerd zijn voor het project vanuit school.
In de eerste iteratie hield ik mij ,voor wat betreft de elaboration fase, bezig met het opstellen van de functionele ontwerpen (GUI designs) en de technische ontwerpen (Klassendiagram, Sequentiediagram, Activiteitsdiagram). Wat betreft de construction fase was het initiële idee om een begin te maken aan de iPad app. Zoals te lezen is in paragraaf 4.4 en 4.6 zijn er echter tijdens het uitvoeren van het project een aantal wijzigingen doorgevoerd, die ervoor hebben gezorgd dat ik in deze iteratie begon met het ontwikkelen van een cliënt/server applicatie. In de tweede iteratie heb ik ervoor gekozen om de technische ontwerpen te herzien, nadat het project was uitgebreid met meer software ontwikkeling (paragraaf 4.4). Nadat de eerste iteratie was voltooid heb ik ook " Requirements herzien" toegevoegd aan de planning. Dit omdat na de eerste iteratie er een aantal requirements aan de app naar voren kwamen die ik nog niet had opgesteld in de inception fase. Dit zijn de dingen waarbij het iteratieve aspect van RUP helpt, omdat ik de requirements op deze manier in een latere fase van het project kon aanpassen zonder dat dat gevolgen had voor de verdere ontwikkelingen binnen het project.
De derde iteratie stond geheel in het teken van het verder uitwerken en afronden van de iPad app en de cliënt/server applicatie. In de planning heb ik deze iteratie twee weken tijd gegeven, in werkelijkheid heeft dit wat langer geduurd. In hoofdstuk zes wordt dit nader toegelicht.
Transition fase
In de transition fase is het de bedoeling dat de app getest wordt. In de planning heb ik hier een gehele week aan gewijd, maar ook deze fase is anders verlopen dan volgens planning. Dit wordt nader toegelicht in hoofdstuk zeven.
3.8
Project betrokkenen
Bij het afstuderen zijn een aantal stakeholders betrokken. Vanuit Logica zijn dit zowel een inhoudelijk begeleider, als een practice manager. Ook vanuit school zijn stakeholders betrokken bij het project. Om dit overzichtelijk te houden heb ik alle stakeholders in een tabel geplaatst.
Naam Rol binnen project Bedrijf Functie
Ivo Kaffa Inhoudelijk begeleider Logica Technical project
leader
Bertram Wesselman Practice manager Logica Practice Manager TSE
team Marco Stikkelorum Working Tomorrow
project leider Logica Working Tomorrow project leider
Mariëlle van Mil Secretaresse Logica Secretaresse TSE team
Leo van Koppen Begeleider Haagse Hogeschool Docent
Tim Cocx Expert Haagse Hogeschool Docent
Tabel 3-1 Project betrokkenen
Ik zal in het kort toelichten wat ieders rol was binnen mijn project.
Ivo Kaffa
Ivo was mijn inhoudelijk begeleider tijdens mijn gehele afstudeerproject. Hij is werkzaam binnen het TSE (Technical Software Engineering) team en heeft veel verstand van
programmeren en software ontwikkelingsprojecten. Ik heb dan ook met hem vooral in de eerste weken van mijn afstudeerproject contact gehad om het project op te zetten en af te bakenen.
Bertram Wesselman
Bertram was mijn practice manager en in dit project te zien als mijn opdrachtgever. Hij is tevens de practice manager van het TSE team en zal per 1 januari 2011 de overstap maken naar de consulting kant van Logica.
Marco Stikkelorum
Marco is de project leider van Working Tomorrow bij Logica Rijswijk. Hij is iedere dag aanwezig op de plek waar ook alle afstudeerders een onderkomen hebben. Hij was beschikbaar voor directe vragen over het afstuderen en Logica zelf.
Mariëlle van Mil
Mariëlle was de secretaresse van het TSE team. Ik kon haar bereiken om een kamer te reserveren voor afspraken met stakeholders, of parkeerplekken voor stakeholders van buiten het bedrijf. Ook als ik problemen had met mijn computer kon ik naar Mariëlle voor oplossingen.
Leo van Koppen
Leo was mijn begeleider vanuit school. Hij is op bedrijfsbezoek geweest en hij is een van de examinatoren voor mijn afstudeeropdracht.
Tim Cocx
Tim was de expert toegewezen vanuit school. Hij was bereikbaar voor inhoudelijke vragen en ook hij is een van de examinatoren voor mijn afstudeeropdracht.
4
INCEPTION FASE
In de inception fase wordt de basis gelegd voor het project aan de hand van een plan van aanpak en een “Hello World” test applicatie. In de inception fase is een grote wijziging in het project naar voren gekomen en aan de hand van use cases het gedrag van de iPad app opgesteld.
4.1
1e dagen en opzet
Tijdens de inception fase zijn er een aantal documenten opgesteld en heb ik veel keuzes moeten maken. Door in deze fase een goede basis neer te leggen aan de hand van een afstudeerplan, plan van aanpak en een aantal gesprekken met stakeholders binnen Logica kon ik in de fases die volgden goed van start.
De fase begon met het schrijven van een afstudeerplan. Normaliter wordt dit al gedaan vóór aanvang van het afstudeertraject, maar Logica ging er van uit dat dit pas wordt opgesteld bij aanvang van het afstudeertraject. De opdracht had ik al een aantal maanden eerder gekozen uit de database bij Logica en d.m.v. een gesprek met mijn begeleider en practice manager kon ik deze opdracht verder uitwerken en hier een afstudeerplan van maken6.
4.2
Gesprek begeleider en practice manager
Het initiële doel van dit gesprek met mijn begeleider en practice manager was om de opdracht verder uit te werken, er stond namelijk nog niet veel op papier. Alleen een titel en een
beschrijving van twee à drie zinnen was aanwezig. Echter nog geen uur voordat het gesprek zou plaatsvinden kwam ik d.m.v. wat research, wat in de volgende alinea wordt toegelicht, erachter dat de opdracht zoals die beschreven was al bestond.
De opdracht was namelijk dat er een applicatie gemaakt zou worden waarmee gebruikers hun apparaten thuis konden bedienen. Door zoektermen te gebruiken op internet kwam ik op een site waar precies deze app aangeboden werd7.
In het gesprek heb ik dit dan ook gelijk gemeld en zowel Ivo (begeleider) en Bertram (practice manager) waren blij dat ik daar in de eerste dagen gelijk mee kwam. Bertram had een kennis die verstand had van domotica8. Dit was Heino Peters, een collega, werkzaam bij Logica
Eindhoven. Aan Heino hebben we de opdracht uitgelegd zoals die was en aan hem hebben we gevraagd hoe deze veranderd zou kunnen worden, zodat er ook een innovatief karakter aan meegegeven werd.
Heino kwam met het idee om energieverbruik van apparaten binnenshuis in de app te verwerken. Mensen thuis hebben in de meeste gevallen geen overzicht met actueel
energieverbruik. Als er een app op de iPad zou zijn die dit mogelijk maakt, dan zou dat een stap in de goede richting zijn. Na wat verder beraad hebben we aan de hand van de input van Heino het afstudeerplan, en dus de opdracht, definitief gemaakt.
6 Afstudeerplan te vinden in externe bijlages, nr. I. 7 http://www.control4.com/residential/products/mobile/ 8 http://www.domotica.nl/domotica.php
4.3
Opstellen requirements
Om de app te kunnen ontwikkelen, moest eerst vast worden gesteld wat de app moest kunnen. Dit heb ik vastgesteld door requirements, eisen, op te stellen. Deze eisen zijn voortgekomen uit een brainstormsessie met mijn begeleider, Ivo, van Logica. Tabel 4.1 laat de eisen zien aan de iPad app die in deze brainstormsessie naar voren zijn gekomen.
In deze brainstormsessie zijn we op een whiteboard uitgegaan van de iPad app. “Wat moet deze app nu kunnen, zowel op technisch vlak, als interface naar de gebruiker toe?”, was de vraag die we onszelf stelden.
Om de eisen overzichtelijk te houden heb ik deze ingedeeld met behulp van de prioriteit. Om de prioriteit vast te stellen van iedere eis heb ik gebruik gemaakt van de MoSCoW methode. De letters in MoSCoW staan voor:
Must have (M) – De eisen waaraan de app MOET voldoen, zonder deze eisen werkt de app niet zoals het zou moeten.
Should have (S) – De eisen die de app zou moeten hebben, als het mogelijk is.
Could have (C) – De eisen die de app zou kunnen hebben. Deze eisen worden gezien als “leuk als ze erin zitten”.
Would have (W) - De eisen die de app niet zal hebben, maar wel toegevoegd kunnen worden.
Requirements iPad app Prioriteit
Moet framework bevatten waarin apparaten
gemakkelijk toe te voegen zijn. S
Moet het mogelijk maken om het
energieverbruik van een apparaat in te kunnen zien.
M Moet verbinding kunnen maken via WiFi met
een server. M
Moet verbinding kunnen maken met een simulatie van een apparaat om dit apparaat te kunnen bedienen.
M Haalt bij opstarten last entry van de database
op de server op met betrekking tot gegevens over energieverbruik van een apparaat.
C
Bevat verschillende tabbladen C
Bevat per simulatie een apart scherm C
Stuurt push bericht naar gebruiker als verbruik simulatie boven bepaalde grens komt
W
Tabel 4-1 – requirements iPad app
In overleg met mijn begeleider zijn de prioriteiten van de eisen toegewezen. Mijn begeleider heeft aangegeven wat Logica graag zou zien in de app als deze was ontwikkeld. Eis één en twee is een hoge prioriteit toegewezen, omdat deze aanwezig moesten zijn om de architectuur aan te houden tussen de client/server applicatie en de iPad app. Welke architectuur en applicaties ik daar mee bedoel wordt in § 4.4 uitgelegd.
4.4
Grote wijziging
In de op één na laatste week van de inception fase heeft er een grote wijziging plaatsgevonden in mijn opdracht. Mijn begeleider had in zijn vrije tijd nog eens gebrainstormd over het gebruik van IR om een apparaat te monitoren en had enkele bevindingen hierover.
De grootste wijziging die hij voorstelde was het gebruik van een simulatie. Om een echt fysiek apparaat te gaan monitoren zou er gebruik gemaakt gaan worden van een Wireless Energie Monitor (WEM)s, ontwikkeld door Heino Peters9. Deze monitor was echter nog niet klaar voor
gebruik, want deze moest nog gemaakt worden, er was alleen een handleiding om hem te maken. Om dit ook nog te realiseren binnen het tijdsaspect van het project zou erg lastig worden. Het ontwikkelen van een technisch onderdeel valt ook niet binnen mijn opleiding en competenties.
Ook de ondersteuning van de iPad met betrekking tot IR liet, na wat research, te wensen over. Het gebruik van IR op de iPad gaat namelijk via een sensor die aan de iPad gekoppeld kan worden en die gemaakt wordt door een andere fabrikant dan Apple10. De fabrikanten die deze
sensors ontwikkelen, zorgen ervoor dat die sensor alleen werkt met de app die zij daar voor hebben ontwikkeld. Het zou er dus op neer komen dat als er van IR gebruik gemaakt ging worden, de hardware (de sensor) hiervoor ook gemaakt moest worden. Dit was niet realistisch binnen de tijd die er beschikbaar was. Ook omdat mijn competenties vanuit school niet
aansluiten bij het technische deel van deze vorm van een afstudeeropdracht heb ik ervoor gekozen dit niet te gaan ontwikkelen.
Met deze gedachte in het achterhoofd kwamen we samen op het idee om een simulatie te gaan gebruiken. Deze simulatie bestond uit een cliënt/server applicatie die moest gaan werken op een computer. De cliënt was dan in dit geval de simulatie van een apparaat (bijvoorbeeld een computer, lamp of tv) en de server zou de monitoring data opslaan in en database en door kunnen sturen naar de iPad via WiFi. WiFi wordt namelijk wel standaard ondersteund door de iPad en om WiFi aan te spreken heeft Apple een API beschikbaar.
Aangezien er, om het project op bovenstaande manier werkend te krijgen, software ontwikkeld moest worden, en dit beter aansloot bij mijn competentieset voor school, werd ik enthousiast over deze manier en heb ik een schema opgesteld dat de verbindingen aangaf tussen de iPad en de cliënt/server applicatie.
9 Handleiding voor het maken van een WEM te vinden in de externe bijlage, Nr. III 10 http://thinkflood.com/products/redeye-mini/
Vanaf dit punt werd de software ontwikkeling dus fors uitgebreid. Ik moest niet alleen meer een app ontwikkelen, maar ook een Cliënt/Server applicatie. Dit sloot aan bij mijn competentieset van school en dat is dan ook de reden dat ik de wijziging door heb gevoerd. Ook voor deze Cliënt/Server applicatie heb ik requirements opgesteld11.
4.5
Opstellen Use Cases
Om het gedrag van de app in kaart te kunnen brengen moesten Use cases opgesteld worden12.
Ik vond het belangrijk om use cases te gebruiken. Dit komt voort uit praktijkervaring op school, waarbij een use case in meerdere projecten geholpen heeft bij het begrijpen van het te
ontwikkelen systeem. Ook omdat RUP gebruik maakt van use cases heb ik deze opgesteld. Mijn begeleider raadde mij aan om de use cases al in een vroeg stadium van het project op te stellen, zodat ik gelijk al een goed begrip had van wat voor applicatie ik moest gaan
ontwikkelen.
Use Cases beschrijven het gedrag van een systeem (in dit geval van de app) als het reageert op een actie van buitenaf (de gebruiker). Bij het opstellen van de Use cases ben ik uitgegaan van een regel die een docent op school mij heeft geleerd:
“Doe alsof de actor een kop koffie neerzet op tafel en bij zichzelf zegt: Ik ga nu…..”
Het einde van deze zin kan gezien worden als een Use Case. Om dit te verduidelijken volgt hier een voorbeeld van een use case zoals ik die in mijn project heb opgesteld.
11 Requirements te vinden in externe bijlages, Nr. II. 12 Use cases te vinden in externe bijlages, Nr. IV
Figuur 4-2 - Voorbeeld Use Case
Iedere Use case is daarnaast ook nog uitgewerkt in een use case diagram. Dit om per use case te verduidelijken wat er gebeurt als deze use case uitgevoerd wordt.
Naam Apparaat bedienen
Use Case ID UC002
Doel Gebruiker kan met iPad een apparaat bedienen
Aannamen iPad app is opgestart en toont homescreen. Primaire actor Gebruiker
Beschrijving - Gebruiker klikt in homescreen op het apparaat dat hij/zij wil bedienen.
- iPad toont acties die uitgevoerd kunnen worden naar het apparaat toe. Als het apparaat niet gevonden kan worden treed uitzondering [apparaat niet gevonden] op.
- Gebruiker kiest een van de mogelijke acties. - iPad stuurt commando naar het apparaat waarmee
apparaat de actie uitvoerd.
Uitzonderingen [apparaat niet gevonden]. De iPad meldt dat het apparaat niet gevonden kan worden. De use case wordt afgebroken.
Resultaat Behalve als de use-case door het optreden van een uitzondering afgebroken is, wordt het apparaat bediend door de gebruiker.
4.6
Aanpassingen PvA/planning
Omdat er op dit punt een forse uitbreiding van de opdracht heeft plaatsgevonden heb ik mijn PvA en planning hier op aangepast. Er moest immers een extra applicatie geschreven worden en dit moest allemaal gepland worden. In mijn PvA beschreef ik alle extra bezigheden die bij het ontwikkelen van de client/server applicatie naar voren kwamen. Ik besloot mijn planning op de schop te gooien en heb de keuze gemaakt om in de eerste iteratie tijdens de construction fase het ontwikkelen van de server/cliënt applicatie voorrang te geven. Dit omdat ik dan een goede basis had en al ervaring had met de programmeertaal waarin de server/cliënt applicatie geschreven moest worden (C#). Ik wist dus vrij zeker dat er geen moeilijkheden op mijn pad zouden komen bij het ontwikkelen van deze applicatie. Dan zou daarna de weg vrij zijn voor het ontwikkelen van de iPad app.
4.7
iOS Developer en “Hello World” app
Omdat het ontwikkelen van een iPad app nieuw was voor mij besloot ik in deze fase van het project om een “Hello World” app te schrijven. Het doel van deze app was om op een fysieke iPad een app te draaien die na een druk op de knop “Hello World” liet zien. Dit om kennis te krijgen van de syntax van de programmeertaal Objective-C en bekend te worden met het software ontwikkelingspakket van Apple, genaamd XCode.
Voorbeeld Syntax Objective-C:
Voorbeeld Syntax C#:
Binnen Working Tomorrow is dan ook een fysieke iPad aangeschaft voor de ontwikkeling van een iPad app. XCode biedt wel de mogelijkheid om een iPad simulator te gebruiken en hierin de app te testen, maar om WiFi en andere dataverbindingen te testen moet de app getest worden op een fysieke iPad13. Voor de “Hello World” app was het niet nodig om de fysieke iPad te
gebruiken omdat deze geen WiFi verbinding zou gebruiken, maar achteraf ben ik blij dat de iPad in deze fase van het project aangeschaft is.
Om software voor Apple te mogen ontwikkelen op een fysieke iPad moet namelijk een Apple iOS developers licentie aangeschaft worden. Gelukkig is er een afdeling binnen Logica die zich bezig houdt met het ontwikkelen van mobiele toepassingen en daarvoor een Apple developers licentie heeft. Deze afdeling is werkzaam bij de afdeling van Logica in Groningen en middels email heb ik een aanvraag gedaan om de iPad te koppelen aan hun licentie, zodat ik op die specifieke iPad mijn app kon testen. Het heeft echter een zeer lange tijd geduurd (twee tot drie weken) voordat mijn iPad gekoppeld was aan de licentie. Meerdere malen in het ontwikkeltraject heb ik de foutmelding gekregen dat de iPad niet de benodigde licenties had om een app op te kunnen testen.
13 https://developer.apple.com/programs/ios/test.html
1. MyType *myType = [[MyType alloc] init];
2. [myType myTypeInstanceMethod:10];
1. MyType myType = new MyType();
Het bleek dat de afdeling in Groningen mijn aanvraag nog niet had goedgekeurd. Dit heeft er voor gezorgd dat ik de app pas in een latere fase van het project op de fysieke iPad kon testen. Dit is ook de reden dat ik blij was dat de iPad in een relatief vroeg stadium van het project aangeschaft was. Alle gebeurtenissen m.b.t. de licentie had ik namelijk niet verwacht, in eerste instantie ging ik er vanuit dat er helemaal geen licentie nodig was voor het ontwikkelen van een iPad app. Doordat de iPad in een vroeg stadium was aangeschaft heeft dit er niet voor gezorgd dat ik achterstand heb opgelopen bij het ontwikkelen van de iPad app.
Bij het ontwikkelen van de Hello World app bleek echter wel dat de software van Apple die wordt gebruikt om apps te ontwikkelen ontzettend anders is dan de software van Microsoft, waar ik al ervaring mee had. Ook Objective-C was toch erg anders dan C#. Dit had ik niet verwacht. Het viel dan ook enorm tegen om de app te maken. Ik moest eerst uitzoeken hoe XCode werkte en hoe een project wordt opgezet binnen XCode en alsof dat nog niet genoeg was moest ik met een geheel andere syntax werken dan dat ik gewend was. De Hello World app is dan ook niet zomaar in een middagje onstaan, dit heeft een week geduurd (5 werkdagen). Gelukkig had ik in de planning vier (werk)dagen ingepland voor het maken van de Hello World app. Hierdoor liep ik dus maar één dag achter op de planning, dat was nog wel in te halen.
4.8
Evaluatie “Hello World” app
Het maken van de “Hello World” app is een slimme keuze geweest omdat in de construction fase van het project bleek hoe lastig XCode en Objective-C waren. Alle ervaring die ik had opgedaan met het maken van de “Hello World” app kon ik goed gebruiken in de construction fase. Ik ben blij dat alle problemen met betrekking tot de licentie opgelost zijn in de inception fase. Als ik deze tijdens de construction fase tegen had gekomen dan had ik erg in de
problemen gekomen.
Het viel erg tegen om erachter te komen hoe XCode en Objective-C werkten. Alle problemen die ik had met de Hello World app, specifiek met XCode en Objective-C, ben ik ook tegengekomen in de construction fase van mijn project. Deze worden dus in hoofdstuk zes duidelijk.
5
ELABORATION FASE
Tijdens de elaboration fase is de architectuur van de app en de cliënt/server applicatie opgezet, om een beter beeld te krijgen over bepaalde lastige onderdelen van de te ontwikkelen app en de cliënt/server applicatie. Om een beeld te krijgen van hoe de GUI van de iPad app er ging uitzien, zijn er GUI designs gemaakt. De requirements zijn na het opstellen van deze GUI designs nogmaals onder de loep genomen.
5.1
Architectuurmodellen
Uit ervaring die opgedaan is in de projecten op school heb ik voorafgaand aan het ontwerpen van de architectuurmodellen eerst goed nagedacht welke modellen echt zouden helpen bij het ontwikkelen van de app en de cliënt/server applicatie. In overleg met mijn begeleider heb ik besloten om voor allebei de applicaties use cases inclusief use case diagrammen op te stellen, evenals een sequentiediagram. De use cases en use case diagrammen had ik al in de inception fase gemaakt.
Van de client/server applicatie heb ik tevens een klassendiagram gemaakt. Dit om voor mijzelf duidelijk te begrijpen hoe de applicatie opgebouwd moest worden.
Om verwarring te voorkomen heb ik een opsomming gemaakt van de verschillende architectuurmodellen14 die ik in dit project heb gebruikt voor de verschillende applicaties:
Architectuurmodel Client/Server
applicatie iPad app
Use cases √ √
Use case diagram √ √
Klassendiagram √ X Sequentie diagram √ √ Activiteitsdiagram √ √ GUI designs X √ Tabel 5-1 - Architectuurmodellen
5.2
Klassendiagram
Het klassendiagram is niet gemaakt in opdracht van enige stakeholders. Het is een bewuste keuze van mijzelf om deze te hebben opgesteld. Het klassendiagram is echter wel een
tussenproduct van de RUP methodiek. Omdat ik deze methodiek toe heb gepast in dit project en omdat het klassendiagram mij een duidelijk overzicht gaf van de verschillende klassen binnen de client/server applicatie besloot ik om deze op te stellen.
Figuur 5-1 – Voorbeeld klassendiagram cliënt applicatie
5.3
Sequentiediagram
Het was de bedoeling, zoals ook te zien is in figuur 4-1, dat de iPad de gegevens over het verbruik van de simulator uit de database ging ophalen die zich bevond op de server. Zo zou het mogelijk zijn om gegevens over het energieverbruik van de simulatie op te kunnen slaan zodat de gebruiker deze later terug kon kijken via de iPad en zo was er maar één verbinding nodig om gegevens op te halen vanaf de iPad, namelijk die naar de database.
Welke interactie tussen de verschillende applicaties plaats zou gaan vinden om dit te realiseren en in welke volgorde dit zou gaan gebeuren was nog niet bekend. Om tussen de twee
Het ontwerpen van de sequentiediagrammen is erg belangrijk geweest voor mij en het project. Het heeft er voor gezorgd dat ik in de Construction fase precies kon achterhalen op welke manier een functionaliteit geïmplementeerd moest worden en welke interacties er waren tussen de applicaties.
5.4
Activiteitsdiagram
Om duidelijk te maken hoe de app zich gedraagt na invoer van de gebruiker heb ik een activiteitsdiagram opgesteld. In het use case diagram wordt alleen verteld dat de app uitvoer geeft waar de gebruiker weer op kan reageren, maar wat er dan daadwerkelijk gebeurt wordt niet verteld. In de vorm van een activiteitsdiagram hoopte ik dit duidelijker te maken.
Omdat het activiteitsdiagram een overzicht gaf van wat de applicaties deden na input van de gebruiker, vond ik het belangrijk deze op te stellen, ik wilde dit namelijk in kaart hebben voordat ik de applicaties ging ontwikkelen. Later is gebleken dat het activiteitsdiagram voor de iPad app het minst heeft bijgedragen bij het ontwikkelen daarvan. Dit komt omdat het
ontwikkelen van de iPad app erg is tegengevallen. Meer hierover in paragraaf 6.7.
5.5
GUI designs
Om een duidelijk beeld te krijgen van hoe de app er uit zou komen te zien heb ik besloten om in de elaboration fase een aantal gui designs op te stellen15. Deze designs begonnen bij ruwe
schetsen en zijn later uitgewerkt met behulp van Adobe Photoshop CS5. Ik heb ondervonden dat het gebruik van GUI designs bij gesprekken met stakeholders het spreekwoord “een plaatje zegt meer dan 1000 woorden” bevestigd. Mijn practice manager had er namelijk geen idee van hoe het eindresultaat er uit zo komen te zien. Toen ik in een gesprek met hem de GUI designs liet zien gaf hij meteen aan een duidelijk beeld te hebben van de app en ik kon duidelijk aan zijn gezichtsuitdrukking zien dat dit veel van zijn vragen gelijk beantwoordde.
Deze GUI designs hebben dus niet alleen geholpen bij het aanpassen van de requirements, waar ik in paragraaf 5.6 op terug kom, maar hebben ook de communicatie tussen mij en de
stakeholders aanzienlijk makkelijker gemaakt.
15 GUI designs te vinden in externe bijlages, NR. III
5.6
Aanpassingen requirements
Bij het ontwerpen van de GUI designs heb ik rekening gehouden met de requirements, eisen, zoals deze zijn opgesteld in de inception fase. Voor iedere eis probeerde ik een oplossing te verzinnen in de vorm van o.a. knoppen en grafieken.
Bij het ontwerpen van de GUI designs kwam echter vrij snel naar voren dat er een aantal eisen nog niet waren opgenomen in de eisen die vast waren gelegd in de inception fase. Deze zijn dus in dit stadium van het project bijgevoegd. Hierna ben ik wel gelijk een gesprek aangegaan met mijn begeleider, waar we de prioriteit van de eisen hebben bepaald. In overleg is besloten de nieuwe eisen de prioriteit “Could have” (zoals gedefinieerd in de MoSCoW methode) te geven. Dit omdat de nieuwe eisen meer werden gezien als een extra toevoeging aan de app, dan een eis die noodzakelijk was om de app werkend te krijgen16.
6
CONSTRUCTION FASE
Nadat de functionele en de technische architectuur van beide applicaties vast lag, ben ik begonnen met de construction fase. In deze fase lag de focus op het ontwikkelen van de
client/server applicatie en de iPad app. Beide applicaties worden ontwikkeld aan de hand van de requirements en de architectuur zoals die zijn opgesteld in de inception en elaboration fase. In alle applicaties komen een drietal functies naar voren die gezamenlijk worden gebruikt. Dit zijn:
Socket verbindingen Message systeem
Decoding/Encoding functies
Voordat ik iedere applicatie afzonderlijk beschrijf, begin ik eerst met het beschrijven van de bezigheden die voortkwamen uit het ontwikkelen van deze drie functies. Zo ontstaat een duidelijk beeld van de architectuur die is ontwikkeld tussen de applicaties.
6.1
Sockets
Om data te verzenden via het netwerk heb ik gebruik gemaakt van sockets. Ik heb gekozen voor een socket omdat dit een van de meest gebruikte netwerkverbindingen is voor gebruik van data-overdracht en omdat het in zowel C# en Objective-C ondersteund wordt.
De poort die ik heb gebruikt is in iedere applicatie standaard ingevuld op poort 8221. Dit is gewoon een willekeurig nummer met geen verdere keuzeverantwoording, behalve dat het een poort is die niet gebruikt wordt door andere applicaties of verbindingen.
De socket wordt op de volgende manier aangemaakt:
Voorbeeld socket aanmaken
De socket wordt aangemaakt met behulp van het TCP protocol. TCP kan data in een stream versturen, wat er voor zorgt dat gegevens altijd aankomen zoals ze verstuurd werden.
Bovendien is TCP een connectie georiënteerd protocol. Het is hierdoor dus afhankelijk van een van te voren opgebouwde verbinding tussen de server en de cliënt, wat er voor zorgt dat de server kan controleren of de data correct is verzonden.
Vervolgens wordt de socket gebonden aan een IPEndPoint, waarin ook het poortnummer meegegeven wordt. De socket wordt open gezet middels de listen() methode, zodat hij kan “luisteren” naar data.
Om berichten te versturen maken de applicaties gebruik van een messagesysteem wat ik heb gemaakt voor de gehele architectuur (dus voor zowel de server/client applicatie als voor de iPad app). Dit systeem wordt toegelicht in hoofdstuk 6.2.
6.2
Message systeem
Omdat er verschillende data over en weer gestuurd moest gaan worden, moest ik een systeem inbouwen wat berichten verstuurd met deze data daarin. Ook omdat ik te maken had met meerdere ontvangers, moest er een systeem komen waarin een uniek ID mee wordt gegeven, zodat de data naar de juiste ontvanger wordt gestuurd. Er moesten namelijk meerdere simulaties aangestuurd kunnen worden door de iPad.
Dit heb ik gerealiseerd door een message systeem op te zetten. Dit message systeem bestaat uit een message, een bericht, met een bepaalde opbouw. De opbouw van een message ziet er als volgt uit:
ID
In het geval dat de cliënt applicaties een message versturen naar de iPad dan is dit ID het ID van de cliënt die het bericht verstuurd en valt dit ID te zien als afzender. Messages worden namelijk standaard doorgestuurd naar de iPad, dus in dit geval hoeft er geen ID te zijn waar de ontvanger mee wordt gedefinieerd.
In het geval dat de iPad een bericht stuurt dan is dit ID het ID van de cliënt waar de server de message naar door moet sturen en valt dit ID te zien als ontvanger.
Message type
Het type van de message, dit kunnen de volgende types zijn: Connect
Een connect message wil zeggen dat de data van de message de naam van het apparaat bevat dat de message verzendt bijv. "Computer", "iPad" of "Lamp".
Usage
Als het type van de message Usage is, dan wil dat zeggen dat de data van de message het verbruik van het apparaat bevat dat de message verzend, bijv. "0,15" of "1,25" kWh. Status
Een apparaat kan aan of uit staan. Als de message type Status is, dan bevat de data van de message de status van het apparaat dat de message verzend, "aan" of "uit" dus.
Data
De inhoud van de data is afhankelijk van het type message, zoals hierboven beschreven. Het kan zowel de naam, het verbruik als de status van een apparaat bevatten.
Separator
Om deze drie gegevens te scheiden bevat de message een scheidingsteken, in de vorm van het pipe (|) teken. De separator moest een teken zijn dat niet in de data voor kan komen, de server of een apparaat moet het zien als een scheidingsteken en niet als data. In eerste instantie koos ik voor het komma-teken. Dit gaf echter problemen, aangezien de data in sommige gevallen een float-getal bevatte, waar een komma in stond. Omdat deze komma was opgegeven als het scheidingsteken werd de message op dit punt gescheiden. Dat was niet de bedoeling. Daarom is het pipe teken gekozen, omdat deze niet in de data voorkomt.
Ter verduidelijking twee voorbeelden van een message: 1|CONNECT|Computer|
Ik heb gekozen voor deze manier van berichtverzending vanwege de uitbreidbaarheid. Het type message kan op de manier waarop het systeem nu is geïmplementeerd drie soorten bevatten, namelijk Connect, Usage en Status. Maar dit is natuurlijk uitbreidbaar. Ik kan me voorstellen dat in de toekomst messages van bijvoorbeeld het type HOUR toegevoegd zullen worden, waarin een apparaat doorgeeft hoelang het al actief is. Deze uitbreidbaarheid is mogelijk in dit message systeem.
Achteraf gezien had ik ook een afzender mee moeten sturen in het message systeem. Hier kwam ik achter toen ik de iPad app ging ontwikkelen. Deze moest namelijk berichten versturen naar de simulaties, waarin hij opgeeft dat de simulaties’ status op aan of uit moet. De server wist echter niet de berichten van de iPad te onderscheiden van de berichten van de simulaties. Dit heb ik opgelost door de message van de iPad uniek te maken. De iPad voegt namelijk een uitroepteken aan zijn data toe, zodat de server weet dat de message afkomstig is van de iPad. Op deze manier kan de server dit bericht doorsturen naar de simulaties.
Het was te risicovol om achteraf een afzender in het message systeem mee te geven. Dit omdat dan de gehele code met betrekking tot het message systeem en de decoding en encoding functies (paragraaf 6.3) aangepast moest worden. Omdat dit in een van de laatste weken van het project naar voren kwam heb ik ervoor gekozen om dit probleem op te lossen middels de manier die ik hierboven heb beschreven, waarvoor ik maar een aantal regels code hoefde aan te passen. Deze manier bracht veel minder risico met zich mee dan het geheel aanpassen van het message systeem en de decoding en encoding functies.
public void Create(short id, MessageType type, string data) {
this.id = id; this.type = type; this.data = data; }
Voorbeeld aanmaken message
NSMutableString* string = [NSMutableString stringWithString:@"!"];
[string appendString:[device1 getStatusText]];
[message Create:1 :2 :string];
[socket writeString:[message Encode]];
6.3
Decoding/Encoding
Berichten die opgezet worden met het message systeem kunnen niet zomaar over de socket verzonden worden van de ene applicatie naar de andere. Over een socket kunnen namelijk alleen maar bytes verzonden worden. De message moest dus eerst geëncodeerd worden naar ruwe byte data om over de socket verzonden te kunnen worden. Als de message eenmaal was aangekomen dan moest op de desbetreffende applicatie het bericht weer gedecodeerd worden om uitgelezen te kunnen worden door de applicatie.
Om dit te realiseren heb ik een decoding en een encoding functie opgesteld. Kort gezegd gebeurd er het volgende als een message geëncodeerd wordt:
- Er wordt een resultData[] (array) aangemaakt waar de ruwe bytes in moeten komen te staan.
- Er wordt een variabele aangeroepen met daarin de (nog leesbare) data - Deze data wordt volgens de ASCII encodering geëncodeerd.
- De data wordt in de resultData[] (array) gezet waarna de applicatie deze data kan verzenden over de socket.
Voorbeeld encoding functie
In eerste instantie werd er geëncodeerd volgens de UTF8 encodering. In hoofdstuk 6.5 wordt toegelicht waarom dit is gewijzigd in ASCII.
public byte[] Encode() {
byte[] byteData; byte[] byteID; byte[] resultData;
byteData = System.Text.Encoding.ASCII.GetBytes(data); int length = byteData.Length;
byteID = BitConverter.GetBytes(ID);
resultData = new byte[length + 5 + 1]; // '+5' because the header contains "ID|type|" ID = 2 bytes. '+1' for the last '|' resultData[0] = byteID[0]; resultData[1] = byteID[1]; resultData[2] = Convert.ToByte('|'); resultData[3] = Convert.ToByte(type); resultData[4] = Convert.ToByte('|'); for (int i = 0; i < length; ++i) resultData[i + 5] = byteData[i]; //Add the last '|' to end the message
resultData[5 + length] = Convert.ToByte('|'); return resultData;
Zoals gezegd moesten de berichten bij aankomst weer omgezet worden van bytes naar leesbare data. Dit werd gedaan in de decoderings functie. Deze functie haalt de data op en zet de bytes weer om naar leesbare data. Bij het decoderen gebeurd het volgende:
- Er wordt een char[] (array) aangemaakt met daarin de message die aangekomen is en gedecodeerd moet worden.
- Deze data wordt gedecodeerd middels de UTF8 decodering. - Er wordt een switch uitgevoerd met de Messagetype:
o In case 0: Messagetype = Connect o In case 1: Messagetype = Usage o In case 2: Messagetype = Status
- Afhankelijk van welk type message het betreft kan de applicatie de message verwerken.
Voorbeeld decoding functie
public void Decode(byte[] messageData) {
bool exception = false;
char[] chars = new char[messageData.Length];
System.Text.Decoder textDecoder = System.Text.Encoding.UTF8.GetDecoder();
int charLen = textDecoder.GetChars(messageData, 0, messageData.Length, chars, 0); id = BitConverter.ToInt16(messageData, 0); switch (Convert.ToByte(chars[3])) { case 0: type = MessageType.CONNECT; break; case 1: type = MessageType.USAGE; break; case 2: type = MessageType.STATUS; break; } }
6.4
Client/Server applicatie
Om de iPad gegevens te kunnen laten zien over het energieverbruik van een apparaat dat gesimuleerd wordt, moet deze simulatie natuurlijk wel eerst bestaan. Ik heb er dan ook voor gekozen om eerst deze applicatie te ontwikkelen. Ook het feit dat ik al bekend was met C# als programmeertaal heeft meegeholpen met deze keuze. De aanpak voor de cliënt/server
applicatie heb ik opgesplitst in twee afzonderlijke applicaties, namelijk een cliënt en een server. Ik begon met de server, omdat deze te zien is als het “hart” van de architectuur. Alle
verbindingen horen namelijk via deze server te verlopen, zowel die van de cliënt, als die van de iPad app. Overigens wil ik hier duidelijk maken dat als er vanaf dit punt wordt gesproken van een simulatie, hier een simulatie van een willekeurig apparaat mee wordt bedoeld. Dit is de cliënt in de cliënt/server applicatie.
6.5
Server applicatie
De server applicatie heb ik ontwikkeld in de programmeertaal C#. Aan deze applicatie kon ik vrij gemakkelijk al een begin maken, aangezien ik al tijdens mijn studie ervaring had opgedaan met C#. Ik hoefde geen ervaring meer op te doen met Visual Studio, aangezien ik deze IDE al kende.
Ik heb dan ook de requirements erbij gepakt die ik had opgesteld aan de cliënt/server applicatie en ben begonnen met een design form (GUI) waar ik de volgende functionaliteiten aan
toevoegde:
Functionaliteit Informatie
Port number textbox: Een textbox waar het poortnummer kan
worden ingevoerd.
Start Listening button Om verbinding open te zetten voor simulaties
en iPad.
Data Received textfield Tekstveld met daarin de data die wordt
ontvangen van zowel de simulaties en de iPad..
Client Informatie [Devicename]
De naam van de simulatie die is verbonden met de server
[Usage]
Het verbruik van de simulatie die is verbonden met de server
[Status]
Status van de simulatie (aan of uit)
[Switch]
Een knop om de simulatie aan of uit te kunnen zetten.
Zoals uit afbeelding 6-1 op te maken is heb ik een aantal labels toegevoegd aan de server puur voor het debuggen. In het eindproduct is het namelijk helemaal niet nodig dat de server de informatie laat zien over de simulaties, dit is de taak van de iPad. Omdat ik echter de iPad app pas later ging ontwikkelen moest ik een plek hebben om de data te kunnen laten zien die de simulatie doorgeeft aan de server. Dit was nodig voor het debuggen, ik moest natuurlijk wel weten of de data goed verzonden en ontvangen werd. Dit heb ik opgelost met behulp van deze labels. Voor de aan/uit switches naast de labels geld dezelfde redenering.
De hoofdtaak van de server was om de messages te verwerken die werden verstuurd van simulatie naar iPad en vice versa. Hiervoor moest dus verbinding worden gelegd met zowel de simulaties als met de iPad. Het was de bedoeling dat er meerdere simulaties verbonden konden worden met de server, omdat iedere simulatie een apparaat voorstelde.
Een verbinding opzetten met de simulaties was relatief eenvoudig. Beide applicaties schreef ik in C#, wat betekent dat de messages die over een weer werden gestuurd met behulp van het message systeem werden geencodeerd en gedecodeerd met de UTF8 encodering die C# standaard gebruikt. Met de labels die ik had toegevoegd aan de server kon ik zien of de message die ontvangen werd ook goed werd uitgelezen.
Op het moment dat een simulatie met de server wilde verbinden stuurde deze een connect message naar de server, waarmee hij aangaf te willen verbinden. Zoals in paragraaf 6.2 wordt uitgelegd bevat een connect message de volgende data:
ID|CONNECT|NAAM APPARAAT|
Omdat de server moest weten naar wie de messages verstuurd moesten worden was het de bedoeling dat deze zelf de ID's uit ging delen aan de simulaties die willen verbinden. Als iedere simulatie namelijk een uniek ID had dan kon de server aan de hand van het ID uit een message bepalen naar welke simulatie het bericht verstuurd moest worden. Bij het aanmelden bij de server moest de simulatie echter wel een ID meegeven, omdat anders het bericht niet goed was opgesteld en de server deze niet goed zou decoderen. Door de simulatie het ID "-1" mee te geven, ziet de server dat dit een ongeldig ID is (negatieve getallen kunnen niet voorkomen in ID's) en deelt hij zelf een geldig ID uit aan de cliënt.
Voorbeeld uitdelen ID
Een message die de server binnenkreeg moest eerst gedecodeerd worden met behulp van de decoding functie die toegelicht is in paragraaf 6.3. Als het type bericht was vastgesteld (wat in de decoding functie werd gedaan) werd er een switch toegepast:
Voorbeeld switch functie
In dit voorbeeld is de case weergegeven voor het message type CONNECT. In het geval van een connect message moest de server de data uitlezen uit het bericht, dat dus de naam bevatte van de simulatie die wilde verbinden, en deze weergeven in het label dat ik had toegevoegd voor het debuggen. Dit ging allemaal relatief eenvoudig en dit heeft dan ook geen noemenswaardige problemen opgeleverd. De messages kwamen goed aan en werden in het desbetreffende label weergegeven. switch (receivedMessage.Type) { case MessageType.CONNECT: { if (idMessage.Data.Equals("1")) lblDevice1.Text = receivedMessage.Data; if (idMessage.Data.Equals("2")) lblDevice2.Text = receivedMessage.Data; } }
Message idMessage = new Message(); if (receivedMessage.ID == -1) {
idMessage.Create(-1, MessageType.CONNECT, Convert.ToString(conns - 1));
