Grafische weergave van verkeersproblemen

Grafische weergave van verkeersproblemen Eindverslag Bachelorproject

10 Juli 2009 1291971 - Gert-Jan Deen 1258931 - Michel de Ridder 1263196 - Maarten Somhorst Technische Universiteit Delft, Faculteit Elektrotechniek, Wiskunde en Informatica

Voorwoord Elke student Media- en Kennistechnologie aan de TU in Delft sluit de bachelorfase af met een project in de vorm van een stage bij een bedrijf of aan de universiteit zelf. Het doel van dit zogenaamde bachelorproject is om concepten en technieken geleerd in eerdere fasen van de studie in de praktijk toe te passen. De start van ons bachelorproject begon met een zoektocht naar een bedrijf waar wij stage mochten én wilden lopen. Via Blackboard hebben we twee bedrijven gevonden met een interessante opdracht. We kwamen al snel tot de conclusie dat we dachten bij Tenuki het meest te gaan leren en de beste begeleiding te krijgen. Tenuki richt zich voornamelijk op het maken en onderhouden van software en diensten die gerelateerd zijn aan verkeersinformatie. Vanaf 6 april 2009 hebben wij dan ook, gedurende 12 weken, bij Tenuki ons bachelorproject gedaan. Dit resulteerde in een applicatie die actuele verkeersinformatie grafisch weergeeft op twee monitoren in de hal van het kantoor. Het verslag dat u nu leest is het eindverslag van dit bachelorproject en is bedoeld om geïnteresseerden inzicht te geven in ons project. Wij willen Tenuki bedanken voor alle tijd en moeite die zij hebben besteed aan de begeleiding van ons project. In het bijzonder willen wij David Koh en Jeroen de Grebber bedanken voor hun rol als respectievelijk Product Owner en Scrum Master en tevens voor de begeleiding binnen Tenuki. We danken David Koh en Tim Volk voor hun technische hulp. Ook willen wij de andere Tenukimedewerkers bedanken voor hun feedback op de applicatie maar ook voor de leuke en leerzame periode. Daarnaast bedanken we Peter van Nieuwenhuizen voor de waardevolle tips en opmerkingen voor zowel het project als het verslag.

Delfgauw, 10 juli 2009 Gert-Jan Deen Michel de Ridder Maarten Somhorst

2

Samenvatting De doelstelling van het project was om twee applicaties te ontwikkelen. Applicatie A, die we Erika genoemd hebben en Applicatie B. Erika moet bezoekers van het Tenuki-kantoor imponeren met recente verkeersinformatie van Europa. Applicatie B was er op gericht om historische verkeersinformatie overzichtelijk te maken. Applicatie B is in een vroeg stadium afgevallen, zodat er meer tijd besteed kon worden aan het goed afronden van Erika. De gehanteerde werkwijze gedurende het project was de Agile ontwikkelmethode SCRUM in combinatie met enkele Tenuki wijsheden. Het ontwerp van Erika is in twee delen op te splitsen, het concept en de architectuur. Om tot een goed concept te komen hebben we met behulp van PowerPoint een conceptpresentatie gemaakt. We hebben verschillende slides ontworpen en deze vervolgens aan verschillende Tenuki medewerkers laten zien. Dit leverde nuttige feedback op. Uiteindelijk zijn we gekomen tot vijf typen slides, drie statistiekslides, een fileverloopkaart en een kaartweergave met recente files. Nadat bekend was wat Erika moest gaan tonen, hebben we een architectuur ontworpen die de uitbreidbaarheid en onderhoudbaarheid van Erika garandeert. We zijn tot een architectuur gekomen waar slides van verschillende landen dezelfde klasse kunnen gebruiken, de geïnitieerde instantie van die klasse bepaalt over welk land het gaat. Dit zorgt dat Erika uitgebreid kan worden met nieuwe landen zonder dat er nieuwe slides geprogrammeerd hoeven te worden. Het converteren van de data is ook gescheiden van de presentatie van de data. Tijdens het project hebben we geprogrammeerd in de taal Delphi. We hadden nog niet eerder met Delphi gewerkt. Delphi is ons goed bevallen en het was leerzaam om met een andere programmeertaal te werken. Een belangrijk onderdeel van de implementatie is de presentatiedatabase. Deze database dient als tussenlaag tussen de ruwe data en de applicatie. Alle conversies van ruwe data naar presentatiedata worden gedaan door de update-applicatie. De structuur van de presentatiedatabase ziet er voor elk land hetzelfde uit en wordt ingevuld met de beschikbare gegevens. Hierbij is het niet noodzakelijk dat voor elk land alle gegevens beschikbaar zijn: de update-applicatie vult de gegevens aan waar mogelijk en verwerkt elk bericht dat genoeg informatie bevat en plaatst het resultaat in de presentatiedatabase. De update-applicatie hebben we losgetrokken van de weergave-applicatie om te voorkomen dat langdurige dataconversies van de update-applicatie de presentatie van de weergave-applicatie beïnvloed. De keuze voor een presentatiedatabase bleken juist. Alle historische data hoeft nu slechts één maal geconverteerd te worden. Ook zorgde het lostrekken van de updatefunctionaliteit van de weergave-applicatie voor betere scheiding van dataconversie en weergave. Daarnaast draait de slideshow nu soepeler. De kaartengine die we gekozen hebben voor de verschillende kaartweergaven is MapServer. De voornaamste redenen hiervoor waren de stabiele API van MapServer, de goede prestaties van de engine en de ervaring van Tenuki met MapServer. Over deze keuze zijn we zeer te spreken: het is een intuïtieve engine en Tenuki kon ons de basisbeginselen uitleggen. Om vervolgens wegen te kunnen tekenen en er files op te kunnen positioneren is het belangrijk om over vectordata van deze wegen te beschikken. Hiervoor waren twee goede oplossingen. We hebben gekozen voor het handmatig tekenen van wegen en hebben hiervoor een kleine applicatie ontwikkeld. 3

Om onze applicatie goed te testen hebben we gebruik gemaakt van unittests. Unittests bleken niet altijd makkelijk toe te passen, met name voor weergaven. Daarom hebben we helaas niet voor elke unit een unittest. Vaak hebben we de voordelen van test-driven development geproefd. Deze aanpak zorgde voor betere code, zowel structureel als functioneel. Met behulp van een testplan waarin we speciale gevallen beschrijven waarmee Erika en de update-applicatie moeten kunnen omgaan is de stabiliteit en robuustheid van Erika sterk verbeterd. De slideshowwisselaar is het deel van onze applicatie die ervoor zorgt dat de slides in de correcte volgorde en met de correcte duur worden afgespeeld. Tevens zorgt de slideshowwisselaar ervoor dat de overgang van slides vloeiend gebeurt. De slideshow kan worden geconfigureerd middels het configuratiebestand afspeellijst. In dit bestand kan de volgorde en duur van de weergave van slides worden geconfigureerd. Naast de slideshow kan ook de database en de typen slides worden ingesteld. De databaseconnectie kan geconfigureerd worden middels het configuratiebestand van de database. Voor elk type slide zijn verschillende instellingen configureerbaar (zoals bijvoorbeeld de titel) via het configuratiebestand slides. De uitbreidbaarheid van Erika is één van de pluspunten van de applicatie. Het benodigde werk voor het toevoegen van een nieuw land is tot een minimum beperkt. Het toevoegen van een nieuw type slide wordt ook goed ondersteund door de duidelijke interface waaraan de nieuwe slide moet voldoen. De samenwerking gedurende het project was in het begin niet optimaal, maar naarmate het project vorderde verbeterde dit. Ook het gebruik van SCRUM is goed bevallen. Het hebben van zichtbare resultaten in een vroeg stadium geeft goed de voortgang van het project weer. Daarnaast is het mogelijk om al vroeg feedback te verwerken. Een negatief aspect van SCRUM is dat het risico bestaat dat de onderhoudbaarheid niet goed wordt gewaarborgd, omdat de nadruk op resultaten ligt. Door SCRUM te combineren met test-driven development wordt dit risico beperkt. We hebben niet veel aanmerkingen op de begeleiding vanuit Tenuki gedurende het project. In het begin werden we intensief begeleid, naarmate het project vorderde was dit minder nodig. Na 12 weken werken bij Tenuki kunnen we concluderen dat we veel hebben geleerd en bereikt. We hebben veel geleerd over file-informatie, werken met kaartengines en de voordelen van een presentatiedatabase. Daarnaast hebben we ook veel geleerd over de SCRUM ontwikkelmethode. We zijn ook zeer te spreken over SCRUM. We hebben een aantal aanbevelingen die zouden bijdragen aan een nog beter product. De belangrijkste hiervan zijn:   

Er voor zorgen dat files op circulaire wegen goed wordt gemapt. Nog niet alle landen van Eurotraffic zijn toegevoegd (Zweden en Finland kunnen nog toegevoegd worden). De applicatie die de ruwe database vult crasht vaak, dit heeft als resultaat dat de ruwe database vaak ‘gaten’ bevat in de gegevens. Dit is geen onderdeel van ons product, maar een externe factor die zorgt dat ons product een incompleet beeld geeft van de werkelijkheid.

4

Verklarende woordenlijst Hier volgt een overzicht van veelgebruikte termen in dit verslag. API: Een verzameling definities waarbinnen computerprogramma’s met elkaar communiceren, de zogenaamde interface. Breakpoint: Het opzettelijk stoppen van de executie van een programma op een gewenst punt in de code om het programma te kunnen debuggen. Client-pull principe: Bij client-pull initieert de client de data overdracht. Daartegenover staat clientpush, waarbij juist de server de overdracht initieert. COM(-objecten): COM is een software-architectuur om de ontwikkeling van componentgebaseerde toepassingen te ondersteunen. Het doel van de COM-architectuur is om ontwikkelaars te stimuleren om herbruikbare software componenten te maken. Erika: Erika is de naam van onze applicatie. Een aantal van de letters van de woorden ‘Eurotraffic’ en ‘kaart’ komen er in voor, vandaar dat het deze meisjesnaam is geworden. Eurotraffic: Eurotraffic is een in Nederland gevestigde onderneming die ruwe verkeersinformatie uit vrijwel alle Europese landen inwint en verwerkt tot klantspecifieke, uniforme informatiestromen. [7] Exception: Een foutmelding die ontstaat als het programma een onverwachte situatie of handeling tegen komt. FastMM4: Een tool voor Delphi waarmee memory leaks opgespoord kunnen worden. Foreign key: Een foreign key is een referentie naar een andere tabel. De foreign key identificeert een kolom uit een tabel die refereert naar een kolom in een andere tabel. De foreign key moet de primary key zijn in de gerefereerde tabel. Google Maps: Een online dienst van Google waarmee je kaarten kunt bekijken. Global Positioning System (GPS): GPS is een commerciële naam voor een wereldwijd satellietplaatsbepalingssysteem. Graphical User Interface: Via de GUI kan de gebruiker met de computer communiceren. INSERT-statement: Het uitvoeren van een query die gegevens in de database zet. Library: Een library is een verzameling van componenten die door applicaties gebruikt kunnen worden. Memory leak: Geheugenruimte dat niet wordt vrijgegeven nadat het niet meer gebruikt wordt. Parser: Een computerprogramma of component die ingevoerde tekst omzet in een datastructuur. Product Owner: Een term uit SCRUM, welke betekent: opdrachtgever. In ons geval was dat David Koh.

5

QQQs: Een meeting waarbij we onszelf individueel de volgende vragen stelden: Wat heb je gister bereikt? Wat ga je vandaag bereiken? Zijn er beperkingen die je doel voor vandaag belemmeren? Een Q staat voor Question, vandaar de drie Q’s. Query (meervoud: queries): Een vraag aan een database om een bepaalde actie uit te voeren. Er kan data worden opgevraagd, toegevoegd, bewerkt en verwijderd. Renderen: Het genereren van een digitale afbeelding middels een computerprogramma. SCRUM: Een ontwikkelwerkwijze opgesteld door Jeff Sutherland en Ken Schwaber. Scrum Master: Een rol binnen SCRUM. De Scrum Master ziet er op toe dat het projectteam zonder belemmeringen door kan werken. Hij/zij zorgt dus dat externe partijen hun werk afleveren, maar ook dat ze het projectteam niet storen. TMC-locatiecode: Elke afslag van een rijksweg heeft een unieke code. Aan deze code zijn gegevens gekoppeld zoals GPS-coördinaten en wegnamen. XML: Een standaard voor het definiëren van formele markuptalen voor de representatie van gestructureerde gegevens in de vorm van platte tekst. Deze representatie is leesbaar voor zowel een computer als een mens.

6

Inhoudsopgave Voorwoord .............................................................................................................................................. 2 Samenvatting........................................................................................................................................... 3 Verklarende woordenlijst ........................................................................................................................ 5 Inhoudsopgave ........................................................................................................................................ 7 Inleiding ................................................................................................................................................. 10 Sectie 1: Opdrachtomschrijving ............................................................................................................ 11 1.1

Doelstelling project ............................................................................................................... 11

Product A ....................................................................................................................................... 11 Product B ....................................................................................................................................... 11 1.2

Opdrachtformulering............................................................................................................. 11

Product A ....................................................................................................................................... 11 Product B ....................................................................................................................................... 11 1.3

Eisen en beperkingen ............................................................................................................ 12

Algemene eisen en beperkingen: .................................................................................................. 12 Eisen product A: ............................................................................................................................ 12 Eisen product B:............................................................................................................................. 12 1.4

Afvallen van product B .......................................................................................................... 12

1.5

Werkwijze .............................................................................................................................. 12

Sectie 2: Ontwerp .................................................................................................................................. 14 2.1

Slideshows ............................................................................................................................. 14

2.2

Architectuur........................................................................................................................... 15

2.3

Aanpassing van het ontwerp ................................................................................................. 15

Sectie 3: Implementatie ........................................................................................................................ 17 3.1

De kaartengine ...................................................................................................................... 17

3.2

Ruwe dataverwerking............................................................................................................ 17

3.3

Presentatiedatabase.............................................................................................................. 19

Structuur ........................................................................................................................................ 20 7

Bijwerken van de data ................................................................................................................... 22 3.4

Wegen tekenen ..................................................................................................................... 23

3.5

Files tekenen.......................................................................................................................... 24

3.6

Testen .................................................................................................................................... 25

3.7

Configuratiemogelijkheden ................................................................................................... 26

3.8

Slideshowwisselaar................................................................................................................ 27

3.9

Slides...................................................................................................................................... 28

3.10

Uitbreidbaarheid ................................................................................................................... 29

Sectie 4: Fasen in het project ................................................................................................................ 31 4.1

Sprint 1 .................................................................................................................................. 31

4.2

Sprint 2 .................................................................................................................................. 32

4.3

Sprint 3 .................................................................................................................................. 33

4.4

Sprint 4 .................................................................................................................................. 34

4.5

Afrondingsfase....................................................................................................................... 36

Sectie 5: Evaluatie ................................................................................................................................. 37 5.1

Implementatie ....................................................................................................................... 37

Delphi ............................................................................................................................................ 37 Presentatiedatabase...................................................................................................................... 37 Update-applicatie .......................................................................................................................... 38 Enginekeuze................................................................................................................................... 38 Testen ............................................................................................................................................ 38 Configuratiemogelijkheden ........................................................................................................... 38 Uitbreidbaarheid ........................................................................................................................... 39 Afvallen van Opdracht B ................................................................................................................ 39 5.2

Werkwijze .............................................................................................................................. 39

Samenwerking ............................................................................................................................... 39 Gebruik van SCRUM ...................................................................................................................... 39

8

Tenuki werkwijze ........................................................................................................................... 40 Conclusie ....................................................................................................................................... 40 5.3

Tenuki .................................................................................................................................... 41

Het bedrijf...................................................................................................................................... 41 Begeleiders .................................................................................................................................... 41 Sectie 6: Conclusies ............................................................................................................................... 42 Sectie 7: Aanbevelingen ........................................................................................................................ 43 Constante datastroom uit de ruwe database ............................................................................... 43 Toevoegen van de overige landen ................................................................................................ 43 Incomplete file-informatie ............................................................................................................ 43 Uitbreiden van configuratiemogelijkheden .................................................................................. 43 Informatiebox van een kaartweergave ......................................................................................... 43 Gebruiken maken van andere soorten verkeersberichten ........................................................... 43 Weergaveduur van de slides ......................................................................................................... 44 Files op circulerende wegen .......................................................................................................... 44 Memory leaks ................................................................................................................................ 45 Tekenapplicatie van wegen ........................................................................................................... 45 Referenties ............................................................................................................................................ 46 Bijlage A: Onderzoeksverslag ................................................................................................................ 47 Bijlage B: Installatiedocumentatie......................................................................................................... 73 Bijlage C: Gebruikersdocumentatie ....................................................................................................... 75 Bijlage D: Beheerdocumentatie............................................................................................................. 78 Bijlage E: Concept slideshows ............................................................................................................... 85 Bijlage F: Voorstel Architectuur............................................................................................................. 91 Bijlage G: Testplan ................................................................................................................................. 94

9

Inleiding Tenuki is een softwarebedrijf dat gesitueerd is in Delfgauw. Het team bestaat uit drie fulltimers en tien parttimers. Het terugkerende thema bij haar projecten is ‘verkeer’, zowel op het land als op het water. De grootste klanten zijn Rijkswaterstaat en TomTom. Bij Tenuki komen informatiestromen binnen met verkeersmeldingen van een aantal landen in Europa. Deze informatie komt van de onderneming Eurotraffic en wordt door Tenuki geconverteerd naar een XML-formaat. Op dit moment is het niet grafisch inzichtelijk welke files er precies staan. Ook kan Tenuki nog niet op een makkelijke manier bekijken welke files er in het verleden voorkwamen. Bij een klacht van bijvoorbeeld TomTom kan het bedrijf nu niet op een snelle en overzichtelijke manier onderzoeken wat de oorzaak is van de klacht. Er bestaat wel een database met de file-informatie uit het verleden. Het doel van ons project is om een Tenuki-bezoeker die door de hal van het kantoor loopt te imponeren met de verkeersinformatie waar Tenuki beschikking over heeft. Hierbij kan gedacht worden aan het weergeven van files op een kaart of statistieken in een grafiek. We hebben een applicatie ontwikkeld die, door het tonen van een aantal slides in de vorm van een slideshow, verkeersinformatie verstrekt. In de eerste sectie zullen we een omschrijving geven van de opdracht en de gebruikte werkwijze. Vervolgens zullen we in sectie 2 een beschrijving geven van het ontwerpproces en wat de resultaten hiervan zijn. In sectie 3 geven we een beschrijving van de belangrijkste implementatiekeuzen die we hebben gemaakt. In sectie 4 staat een overzicht van de sprints. In de sectie 5 evalueren we deze keuzen en de werkwijze gedurende het project. In sectie 6 geven we de conclusie van het project. Tenslotte geven we in sectie 7 een aantal aanbevelingen voor het uitbreiden en verbeteren van de geproduceerde applicatie. Aan het eind van dit verslag zijn zeven bijlagen te vinden. Bijlage A is een kopie van het onderzoeksverslag dat geproduceerd is in de eerste twee weken van de stage en aangevuld is tijdens het project. Bijlage B t/m D bevatten de documentatie over de applicatie. Bijlage B bevat de installatiedocumentatie, bijlage C de gebruikersdocumentatie en bijlage D de beheerdocumentatie. Bijlage E bevat een overzicht van de ontwerpen van de verschillende slides om file-informatie te tonen en in bijlage F is het voorstel van de architectuur voor de applicatie te vinden. Het testplan die we tijdens het afronden van de applicatie hebben gemaakt is te vinden in bijlage G.

10

Sectie 1: Opdrachtomschrijving In deze sectie staat een beschrijving van de uitgevoerde opdracht met de daarbij de eisen van het te maken product.

1.1

Doelstelling project

Het doel van het project is dat de data die geconverteerd is door Tenuki (zojuist of verder in het verleden) inzichtelijk wordt gemaakt. Er moet een grafische weergave komen van de files in Europa. Het project levert twee producten op die bestemd zijn voor een verschillend soort gebruiker: Product A Het doel van de eerste opdracht is een Tenuki-bezoeker die door de hal van het kantoor loopt te imponeren door middel van de presentatie van verkeersinformatie. De gemiddelde klant of medewerker die het Tenuki-kantoor binnenkomt of verlaat moet het programma interessant vinden om naar te kijken. Product B Het doel van het tweede opdracht is om na te kunnen gaan welke geconverteerde file-informatie Tenuki over een bepaald moment heeft. Bijvoorbeeld, stel dat de klant wil weten of het klopt dat er om 13:00 uur op 6 april een file stond op de A1, dan kan er met deze tool bekeken worden of Tenuki deze file-informatie op dat tijdstip bezat. Voor iedere file is bijvoorbeeld te zien hoe lang deze file was (in meters).

1.2

Opdrachtformulering

De doelstellingen van hierboven resulteren in de volgende productbeschrijvingen. Product A Maak een programma dat bezoek van Tenuki kan imponeren met filegegevens. Hierbij kan gebruik worden gemaakt van de informatie uit de databases van Tenuki. Het is de bedoeling deze informatie op één of meerdere monitoren te presenteren. Hierbij moeten de volgende richtlijnen worden aangehouden:   

De bezoekers moeten de getoonde informatie snel kunnen begrijpen De file-informatie moet op een mooie manier worden weergegeven. In andere woorden: de bezoeker wilt graag kijken naar de representatie van de file-informatie. Het moet blijken dat de informatie zeer recent is.

Product B Maak een programma waarin Tenuki-medewerkers file-informatie uit Europa kunnen zien. De bedoeling is dat file-informatie van het heden evenals het verleden weergegeven kan worden, zodat het inzichtelijk wordt welke files er op een bepaald tijdstip stonden en waar die files zich bevonden. Ook is er te zien hoe lang deze files waren en wat de oorzaak was. Er bestaat de mogelijkheid om in te zoomen op de kaart en er overheen te bewegen zodat men bijvoorbeeld alleen de files van een land of provincie kan bekijken.

11

1.3

Eisen en beperkingen

Beide producten dienen aan een aantal eisen te voldoen, namelijk de volgende: Algemene eisen en beperkingen: - De applicaties zullen op een "normale pc" (minimaal een processor met twee cores en een kloksnelheid van 2 Ghz en 1 GB beschikbaar werkgeheugen) kunnen draaien met als besturingssysteem Windows XP of Vista. - Er wordt gewerkt volgens de Tenuki werkwijze in combinatie met de Scrummethode. - De applicaties zijn web- of desktopapplicaties, voornamelijk geschreven in de programmeertaal Delphi. - De applicaties moeten binnen 10 weken worden afgeleverd. - De applicaties moeten zonder handleiding te begrijpen zijn. - De applicaties geeft ook daadwerkelijk de juiste informatie weer (de informatie zoals in de database). - De software moet goed onderhoudbaar zijn: gestructureerd ontwerp, goed becommentarieerde code waar nodig. - De applicatie gaat getest worden aan de hand van een testplan. - Bij het laden van een kaart gebeurd dit op de achtergrond en verdwijnt de ‘verouderde’ kaart pas als de nieuwe kaart klaar is. Eisen product A: - Het resultaat van deelopdracht A mag maximaal 5 minuten achter lopen op het de huidige verkeerssituatie. - Er moet aan de hand van een configuratiebestand ingesteld kunnen worden wat de applicatie zal weergeven. - De informatie moet op een interessante manier getoond worden. - Er is geen input van de gebruiker nodig voor de applicatie. Eisen product B: - Er is inzichtelijk gemaakt voor een willekeurig tijdstip: • waar er files staan/gestaan hebben • hoe lang deze files zijn/waren • wat de oorzaak van de file is - De gebruiker moet kunnen inzoomen op de kaart. - De gebruiker moet de kaart kunnen bewegen. - De gebruiker moet het tijdstip kunnen aanpassen.

1.4

Afvallen van product B

Al in een vroeg stadium van het project is gebleken dat het realiseren van product A meer tijd kost dan van te voren gedacht. Omdat er meer prioriteit lag bij het maken van een goed werkend product A is er voor gekozen om product B te laten vervallen. Hierdoor hebben we meer tijd te kunnen besteden aan het volledige en goed afronden van product A. In de rest van het rapport zal dit product worden benoemd met ´Erika´. Er is voor Erika gekozen omdat bij eerder projecten van Tenuki vaker gekozen is voor een meisjesnaam. Erika leek ons een bijpassende naam omdat het de ‘e’ van Eurotraffic bevat en de ‘ka’ van kaart.

1.5

Werkwijze

Gedurende het project hebben we gewerkt volgens de Tenuki werkwijze in combinatie met de Scrummethode. Tijdens ons vooronderzoek hebben we uitgebreid onderzoek gedaan naar deze

12

werkwijzen, zodat we deze zo goed mogelijk konden toepassen. Een uitgebreid verslag is te vinden in het onderzoeksverslag (zie bijlage A). De belangrijkste punten zijn: Een project begint met het definiëren van een productbacklog. Een productbacklog bevat alle taken die bijdragen aan het behalen van het einddoel van het project. Vervolgens zal er om de twee weken een sprint worden gedefinieerd waarin gewerkt wordt aan een subdoel van het einddoel. Bij het definiëren van een sprint hoort ook het definiëren van een sprintbacklog. Een sprintbacklog bevat taken van de productbacklog die bijdragen aan het behalen van het doel van de sprint. De taken worden geformuleerd op basis van zichtbare tussenresultaten. Na het afronden van een taak is er dus een nieuw resultaat te zien. Per taak zal een urenschatting worden gemaakt. Elke ochtend begint met een QQQ meeting. QQQ (Question Question Question) staat voor de drie vragen die ieder teamlid beantwoordt: Wat heb je gisteren bereikt? Wat ga je vandaag bereiken? Zijn er belemmeringen voor het doel van vandaag? Bij een QQQ pakt iedereen één of meerdere taken van de sprintbacklog waaraan de persoon zal gaan werken. Een hulpmiddel die vaak wordt toegepast in combinatie met de Scrummethode is de burndown chart. Het is een grafiek die een indruk kan geven van de voortgang van een project. Aan het begin van iedere dag wordt door de teamleden een inschatting gemaakt van het aantal uren dat een project nog kost. Het maken van deze dagelijkse inschatting is redelijk eenvoudig omdat iedere taak op een sprint backlog apart wordt ingeschat. Omdat de urenschatting aan het begin van elke dag wordt gedaan, is de eerste dag ná de sprint ook vaak opgenomen in de grafiek. Op deze dag weet je namelijk pas zeker of alle taken van de sprint gedaan zijn of niet. Zie het onderzoeksverslag in bijlage A voor meer informatie over SCRUM. In figuur 1 is een voorbeeld te zien van een burndown chart.

Figuur 1: Voorbeeld van een burndown chart waarbij de groene lijn voor de richtlijn staat en de blauwe de werkelijke voortgang weergeeft

13

Sectie 2: Ontwerp Zodra de opdrachtomschrijving duidelijk was en het onderzoeksverslag afgerond (zie bijlage A), zijn we gaan nadenken over hoe de applicatie er uit moest gaan zien. In deze sectie zullen we uitleggen hoe we onze applicatie hebben ontworpen. Dit omvat zowel het ontwerp van de slides (hoe ziet de applicatie er uit?) als het architectuurontwerp.

2.1

Slideshows

Om een goed beeld te krijgen van hoe onze applicatie er uit moet komen te zien, zijn we PowerPointpresentaties gaan maken. Eén voor Nederland en één voor Europa. Het is de bedoeling dat deze slideshows gelijktijdig draaien op een computer met twee monitoren. Middels een simpel tekenprogramma, Google Maps en Excel hebben we allerlei slides gemaakt met kaarten en grafieken. Op deze manier konden we onze eigen ideeën uitwerken en perfectioneren. Een nog groter voordeel hiervan was dat we anderen deze ideeën konden laten zien en beoordelen. De Product Owner wist wat hij kon verwachten en Tenuki-medewerkers konden feedback geven. In dit stadium hebben we dan ook direct feedback gevraagd van Asako en Amparo, twee Tenukimedewerkers die zich voornamelijk bezig houden met de Graphical User Interfaces van de Tenukiapplicaties. Hun feedback was erg nuttig en hebben we direct verwerkt in onze slideshows. Een kaart met files bleek het meest duidelijk te zijn bij de verkeersfunctie van Google Maps die alle snelwegen groen kleurt en de snelwegen met files rood kleurt. Ook waren veel statistiekslides te onduidelijk om in 30 seconden te kunnen begrijpen. We hadden veel tijd nodig voor het ontwerpen van de statistiekslides. Ten eerste moesten we bedenken wat we precies wilden duidelijk maken en of dat ook nuttig was voor de kijker. Ten tweede lag er een uitdaging om grafieken te ontwerpen die precies duidelijk maken wat we willen laten zien, maar toch makkelijk te begrijpen zijn. Dit ontwerpproces resulteerde in een concept voor de applicatie waar we naartoe konden werken. Zie bijlage E. De slides zijn onder te verdelen in drie typen. Het eerste type slide is een kaartweergave (MapView). Dit type slide bestaat uit een weergave van een bepaald gebied op de kaart waarin de huidige verkeerssituatie wordt getoond. Aan de rechterkant van het scherm bevat deze slide de optie om een informatiebox die de vijf langste files weergeeft te tonen. Het tweede type slides is een fileverloopkaart (BuienRadarView, omdat deze slide gebaseerd is op het principe van buienradar.nl, het weergeven van buien op een kaart ten opzichte van de tijd). Dit type slide geeft het fileverloop over de tijd grafisch weer. Het laatste type slide is een statistiekweergave. Dit type slide geeft de historische file-informatie in de vorm van een grafiek weer. In de onderstaande figuur is een voorbeeld te vinden van een kaartweergave en een statistiekweergave.

Figuur 2: Voorbeeld slides van een kaartweergave (links), fileverloopkaart (midden) en statistiek (rechts). Een grotere versie van de slides is te vinden in bijlage E.

14

2.2

Architectuur

Nadat we wisten hoe het eindresultaat er uit moest komen te zien, konden we na gaan denken over de implementatie. De bedoeling was dat we alle drie op dezelfde lijn zouden zitten, maar belangrijker: dat we vanaf het begin programmeren aan een applicatie die makkelijk uitbreidbaar is. Het ontwerp van de architectuur is daarbij toonaangevend. Omdat we nog niet zo goed gewend waren aan het woord ‘module’ en omdat we niet zo goed voor ogen hadden wat het doel was van zo’n ontwerp, was ons eerste voorstel aan de Product Owner verre van duidelijk. Toen we er nog eens naar keken met het doel in ons achterhoofd lukte het ons om een goed voorstel te maken dat te vinden is in bijlage F. Uit dit voorstel is op te maken dat de applicatie die we voor ogen hadden makkelijk uitbreidbaar zou worden. Om een nieuwe kaart weergave (MapView) te maken hoeft men alleen maar een instantie te maken van MapView en de specifieke instellingen van die slide in het slideconfiguratiebestand te plaatsen. De plaats van een eventuele nieuw type slide is ook duidelijk: deze moet overerven van View. De drie configuratiebestanden uit Figuur 1 van bijlage F geven aan dat de applicatie ook instelbaar is buiten de broncode om. Mede omdat de applicatie uiteindelijk in tweevoud moet gaan draaien op dezelfde computer, hebben we er voor gekozen dat de afspeellijst van buitenaf configureerbaar is. Daarnaast is het duidelijk dat de verschillende verantwoordelijkheden goed gescheiden zijn. Weergaven zijn alleen verantwoordelijk voor de weergave van een slide en de databasecomponent voor data. De slideshowwisselaar geeft alleen aan wanneer een bepaalde slide zichzelf mag weergeven en wanneer hij zichzelf moet voorbereiden op weergave.

2.3

Aanpassing van het ontwerp

Op de statistiekslide van de drukste spitsen na zijn de concepten van de slideshows niet veranderd tijdens de implementatie. In eerste instantie hadden we een concept om de langste files van de afgelopen maand te laten zien, deze bleek niet interessant genoeg te zijn. Voor deze slide hebben we een nieuw concept verzonnen, namelijk een statistiek met de top 10 drukste spitsen van de afgelopen maand. Het ontwerp voor de architectuur is tussentijds ook aangepast aan de hand van voortschrijdend inzicht. In figuur 3 op de volgende pagina is het diagram van de uiteindelijke architectuur te zien. Er zijn drie grote dingen veranderd: 

 

De MapView (kaartweergave) en de BuienRadarView (fileverloopkaart) hadden veel code gemeenschappelijk omdat ze beiden communiceren met de kaartengine. Daarom hebben we de klasse MapHelper geïntroduceerd die beide modulen met hun taak kan helpen. De implementaties van de verschillende statistiekslides hadden niets met elkaar gemeen, dus konden gezien worden als losse klassen. De gebiedenconfiguratie is vervangen door een slideconfiguratie, omdat de slides geconfigureerd moesten worden. Voor elke slide is nu gedefinieerd welk gebied hij laat zien. Voor meer details over configuratiemogelijkheden, zie sectie 3.7.

15

Figuur 3: Architectuurontwerp, uiteindelijke versie

16

Sectie 3: Implementatie Na het ontwerpen van de slides en de architectuur kon de implementatiefase starten. In deze sectie is te lezen welke belangrijke implementatiekeuzes we hebben gemaakt.

3.1

De kaartengine

Om kaarten weer te geven in de applicaties is een kaartengine nodig. Deze geeft de mogelijkheid om een kaart op het scherm te tonen en daar objecten overheen te tekenen. We hebben tijdens de eerste weken onderzoek gedaan naar verschillende kaartengines. Van de vele verschillende soorten kaartengines hebben we op basis van stabiele API, goede documentatie en tekenmogelijkheden met de engine een keuze gemaakt van drie verschillende engines: Google Maps, MapServer en TatukGIS. Deze engines hebben we uitgebreider onderzocht aan de hand van een aantal vragen en een kleine implementatie-opdracht. Een uitgebreidere beschrijving van dit onderzoek is te vinden in het onderzoeksverslag in bijlage A. Onze keuze is gevallen op de MapServer engine. De voornaamste redenen daarvoor ten opzicht van Google Maps en TatukGIS zijn:  De stabiele API.  Hoge prestaties bij het teken van een groot aantal tekenobjecten.  Ervaring van Tenuki met deze engine.

3.2

Ruwe dataverwerking

Alle file-informatie verkrijgen we uit een externe database die alle fileberichten en wegwerkzaamheden bevat voor de landen Nederland, België, Oostenrijk, Italië, Spanje en Zwitserland. Elk land heeft zijn eigen WAYFINDER tabel, deze tabel bevat voor elk land dezelfde velden. De belangrijkste velden van de WAYFINDER tabel zijn als volgt: WAYFINDER ID

Een uniek ID per melding

SITUATION_ELEMENT_REF

Een uniek ID per ‘situation’ (file)

VERSION_TIME

De tijd van de melding

EXPIRED

Een boolean die aangeeft of de melding nog steeds geldig is

RAW_XML

De XML met gegevens over de file (wordt hieronder uitgebreid toegelicht)

CREATE_TIME

De tijd waarop de melding in de database is geplaatst

SITUATION_ELEMENT_REF is een uniek ID voor een ‘situation’. Er zijn meerdere typen meldingen in de database. Onze applicatie kijkt alleen naar de filemeldingen. Elke file heeft een uniek ID (in de vorm van het SITUATION_ELEMENT_REF). Voor één file bestaan meestal meerdere fileberichten, waarin bijvoorbeeld de lengte of locatie wijzigt. Elk van deze fileberichten heeft dezelfde SITUATION_ELEMENT_REF, om aan te geven dat de berichten bij een enkele file horen. De RAW_XML van een filebericht ziet er als volgt uit: <situationElement xsi:type="LevelOfService"> <elementReference>1 <elementVersionNumber>1

17

<elementlocation xsi:type="Method4_RDS_TMC_StretchLocation"> 817 N Westbaan 37952 Rosmalen 200 4 <secondaryLocation> 37959 Kerkdriel LOC 600 <elementTimestamps> 2009-05-22T17:01:00+02:00 <startTime>2009-05-22T17:01:00+02:00 <expiryTime>2009-05-23T17:01:00+02:00 <elementVersionTime>2009-05-22T17:41:00+02:00 6 LOS LS2

Het ‘type=LevelOfService’ geeft aan dat het om een filebericht gaat. Per file kunnen meerdere van dit soort berichten binnenkomen, die bijvoorbeeld de lengte en/of locatie updaten. Een filebericht is in principe geldig tot de EXPIRED_TIME (‘<expiry time>’) verloopt (voor Nederland standaard ingesteld op 24 uur later) of tot er een nieuw bericht voor de file binnenkomt. De VERSION_TIME (‘<elementVersionTime>’) is de begintijd van de geldigheid van het filebericht. De belangrijke (en gebruikte) velden uit de RAW_XML zijn:  alertCLocationCode, dit is de TMC-locatiecode (Traffic Message Channel)  locationName, de afslagnamen, waarbij secondary location het punt is waarop de file begint.  queueLength, de filelengte in kilometers De velden alertCDistanceFromPrimaryLocation en alertCDistanceFromSecondaryLocation geven de afstand tussen de afslag en de file weer. We gebruiken deze data niet, omdat het verschil voor de weergave van de file op de kaart klein is. Elke afslag van een rijksweg heeft een unieke TMC-locatiecode. Aan de hand van de TMClocatiecodes, kunnen uit de TMC-database de Global Positioning System (GPS) coördinaten van het begin- en eindpunt van de file worden gehaald. Met behulp van de MapServer engine kunnen deze GPS coördinaten omgezet worden naar Mercator coördinaten. Dit zijn coördinaten waarmee de MapServer werkt. Helaas zijn niet alle fileberichten altijd volledig ingevuld en ontbreken er vaak velden. De minimale informatie die we nodig achten is één locatienaam, de filelengte of de coördinaten van het begin en eindpunt van de file. De redenatie hierachter is als volgt:

18

Met slechts de locatienaam kunnen we in ieder geval aangeven dat er een file staat rond die locatie. Als we alleen de filelengte hebben, kunnen we de file nog gebruiken voor de statistieken (zoals de filelengte in een land op een bepaald tijdstip). Wanneer we slechts beschikken over beide coördinaten, dan kan de file nog wel op de kaart getekend worden. Als de locatienamen ontbreken kunnen deze vaak nog via de uitgebreide TMCtabel aan de hand van de TMC-locatiecode achterhaald worden. Daarnaast kan de filelengte berekend worden als beide locaties bekend zijn. Op het moment dat er geen locatienaam bekend is, geen filelengte en ook geen coördinaten, is de file nutteloos voor onze applicatie, daarom wordt deze file genegeerd. Deze actie wordt wel in een log geschreven, zodat het altijd terug te vinden is.

3.3

Presentatiedatabase

Zoals in de vorige paragraaf beschreven staat komt de file-informatie binnen in de vorm van fileberichten. Om vanuit deze fileberichten informatie te verkrijgen die nuttig is voor de slides van de applicatie, moeten forse conversies gedaan worden. De historische weergaven hebben veel data nodig, dus er moet veel informatie geconverteerd worden. Daarom hebben we gekozen voor een zogenaamde presentatiedatabase. Het idee achter deze database is dat de inhoud zo dicht mogelijk tegen de data aan ligt die de applicatie nodig heeft. Het voordeel is dan dat elke weergave met enkele simpele queries zijn data beschikbaar heeft. Een ander voordeel is dat nu geen dubbele data meer wordt opgehaald voor de historische informatie. Voorheen werd dezelfde data namelijk meerdere keren opgehaald, geconverteerd en weggegooid.

Figuur 4: Oude situatie waarbij voor elke slide de benodigde informatie moet worden opgehaald en converteert.

Figuur 5: Nieuwe situatie waarbij de presentatiedatabase op de achtergrond om de 10 min wordt bijgewerkt met nieuwe geconverteerde data en Erika alleen de benodigde data hoeft ophalen.

19

We hebben ervoor gekozen om bepaalde gegevens ‘dubbelop’ in de presentatiedatabase te zetten. Zo zou bijvoorbeeld de data voor de statistiekslide drukste spitsen (zie sectie 3.9) ook zijn data uit de SNAPSHOT_TOTAL_LENGTH tabel kunnen halen. Deze data zou nog wel bewerkt moeten worden. We hebben ervoor gekozen om onze presentatiedatabase zo op te zetten, dat slides geen dataconversies op de data in de presentatiedatabase hoeven te maken. Dit levert tijdwinst op bij het weergeven van slides, omdat deze extra conversie alleen gedaan hoeft te worden bij het vullen van de presentatiedatabase. Daarnaast worden hiermee de verantwoordelijkheden voor dataconversie en weergave uit elkaar gehouden. Een slide is nu alleen verantwoordelijk voor de weergave. Structuur We hebben de volgende tabellen gedefinieerd voor de presentatiedatabase: De eerste tabel is TRAFFICJAM. Een betere naam zou zijn: TRAFFICJAM_MESSAGE, omdat er eigenlijk fileberichten in opgeslagen zijn. Ter verduidelijking: Voor één file bestaan meestal meerdere fileberichten. Ieder record stelt een filebericht voor die we uit de externe database halen. Welk filebericht bij welke file hoort is net als in de externe database aangegeven met het veld SITUATION_ELEMENT_REF. Er kunnen dus meerdere fileberichten zijn met dezelfde SITUATION_ELEMENT_REF. Deze fileberichten geven informatie over dezelfde file. TRAFFICJAM ID

Een uniek ID per filebericht (dus niet per file)

COUNTRY

Het betreffende land

JAMLENGTH

De lengte van de file

ROADNAME

De naam van de weg waarop de file zich bevind

TAIL_JUNCTIONNAME

Afslagnaam van de start van de file

HEAD_JUNCTIONNAME

Afslagnaam van het eind van de file

SITUATION_ELEMENT_REF

Het unieke ID van de file (niet het filebericht)

VERSION_TIME

De tijd van het filebericht

Vervolgens de tabel TRAFFICJAM_POINT. Hierin worden de coördinaten van een file gekoppeld aan een file. Het staat niet vast hoeveel coördinaten een file heeft, als de locatie van de file bekend is dan heeft een file minimaal twee coördinaten en anders nul. Het is goed denkbaar dat een file meer dan twee coördinaten heeft, omdat het de coördinaten van de file op de weg betreft. Het staat niet vast hoeveel coördinaten een file heeft. Vandaar dat de coördinaten niet zijn opgenomen in de TRAFFICJAM-tabel. TRAFFICJAM_POINT ID

Een uniek ID per coördinaat

TRAFFICJAM

De corresponderende file (foreign key)

MERCATOR_X

Het x coördinaat in Mercator

MERCATOR_Y

Het y coördinaat in Mercator

20

Verder hebben we een tabel die bijhoudt welke tijdsloten er gedefinieerd zijn. Wij hebben er voor gekozen om van elke 10 minuten een filebeeld te hebben voor de afgelopen 30 dagen. Dit houdt in dat er voor elke 10 minuten van de afgelopen 30 dagen een tijdslot is. De tabel die deze tijdsloten bijhoudt is SNAPSHOT_TIME. SNAPSHOT_TIME ID

Een uniek ID per tijdstip

DATETIME

Tijdstip van het tijdslot

Om historisch files te kunnen weergeven is het natuurlijk belangrijk dat files aan tijdsloten worden gekoppeld. Voor deze koppeling is de tabel SNAPSHOT_TO_TRAFFICJAM. De combinatie van SNAPSHOT_TIME en TRAFFICJAM is een primary key. SNAPSHOT_TO_TRAFFICJAM SNAPSHOT_TIME

De ID van een bepaald tijdslot (foreign key)

TRAFFICJAM

De ID van de corresponderende file (foreign key)

Het doel van de presentatiedatabase was om de data zo goed mogelijk bij de presentatie op het scherm te laten aansluiten. Twee statistische weergaven (Filelengte afgelopen uren en Fileverloop trend) hebben uitsluitend filelengtes (gekoppeld aan tijdsloten) nodig. SNAPSHOT_TOTAL_LENGTH voorziet in die behoefte. SNAPSHOT_TOTAL_LENGTH SNAPSHOT_TIME

De ID van een bepaald tijdslot (foreign key)

COUNTRY

Het desbetreffende land

TOTAL_LENGTH

De corresponderende filelengte voor dat land en tijdstip

Ook de statistiekslide drukste spitsen heeft een eigen tabel met data die zeer dicht bij de presentatie ligt, namelijk TOP_RUSHHOUR. Hierin staat voor elke spits (ochtend en avond) wat de lengte was van die spits. TOP_RUSHHOUR ID

Een uniek ID per spits

START_TIME

De begintijd van de spits

END_TIME

De eindtijd van de spits

KMMIN

Het aantal kilometerminuut file tijdens de spits

COUNTRY

Het desbetreffende land

En als laatste is er een zogenaamde METADATA tabel. Deze tabel is voor de metadata, ofwel de data over data. Hierin wordt onder andere bijgehouden tot wanneer de presentatiedatabase is bijgewerkt.

21

METADATA ID

Een uniek ID per record

NAME

Het type metadata

COUNTRY

Het desbetreffende land

CONTENT

De inhoud van de metadata

Bijwerken van de data Het bijwerken van de presentatiedatabase met nieuwe data is een intensief proces. In eerste instantie hadden we dit proces in onze weergave-applicatie verweven. Dit had als voordeel dat er geen data dubbel opgehaald werd, omdat er pas nieuwe data opgehaald werd als de applicatie het nodig had. Echter het ophalen van nieuwe data vertraagde onze applicatie dusdanig dat er een andere oplossing gekozen moest worden. Er waren twee voor de hand liggende opties:  

Onze applicatie multithreaded maken Een losse applicatie maken voor het updaten

We hebben uiteindelijk voor het tweede gekozen. Dit vanwege de complexiteit die multithreaded implementaties met zich meebrengen en daarmee de bijbehorende risico’s voor de robuustheid en stabiliteit van onze applicatie. De update-applicatie De update-applicatie heeft een ingebouwde timer zodat hij elke 10 minuten (het interval tussen de tijdsloten) voor elk land een update uitvoert van LastUpdateTime tot aan de meest recente file. Dit wordt gedaan door na de update een timer aan te zetten. Gedurende de update haalt de applicatie alle fileberichten uit de ruwe database met een VERSION_TIME groter dan de LastUpdateTime. Voor elk filebericht wordt een file-object gemaakt. Dit houdt in dat de belangrijke gegevens worden ingelezen en opgeslagen. Vervolgens wordt geprobeerd om ontbrekende gegevens zo goed mogelijk aan te vullen. Dit kunnen onder meer de locatienaam, filelengte en rijkswegnaam zijn. Ook wordt geprobeerd de exacte coördinaten van de file op een weg te bepalen. Omdat er altijd afwijkende berichten kunnen zitten in de ruwe datastroom, is het onmogelijk om altijd een correcte file op te bouwen. Als er na het aanvullen nog steeds geen locatienaam, geen filelengte en geen coördinaten bekend zijn van de file, dan wordt de file genegeerd. Zie sectie 3.2 voor meer details over het al dan niet negeren van fileberichten. Na het aanmaken van de file-objecten voor elk filebericht worden eerst de tijdsloten aangemaakt in de tabel SNAPSHOT_TIME. Vervolgens wordt voor elk filebericht gekeken welke file aan welk tijdslot moet worden toegevoegd. Een filebericht wordt toegevoegd aan de tijdsloten tussen het vorige bericht en voor het volgende bericht. Als twee fileberichten in het zelfde tijdslot vallen, dan wordt alleen de laatste gebruikt. Als alle fileberichten van een bepaalde file zijn verwerkt (tot nu toe), wordt het laatste filebericht van een file niet toegevoegd aan een tijdslot, omdat het onmogelijk is om te bepalen of de file er na dat moment nog staat. Het expiry veld (EXPIRED_TIME) wordt namelijk in de praktijk altijd op 24 uur ingesteld, zodat het onbruikbaar is om te bepalen of de file niet meer geldig is. Daarom gaan we ervan uit dat een file bestaat tot aan het laatste filebericht van die file.

22

Het is belangrijk om te realiseren dat een verkeersbeeld van het verleden ook kan veranderen. Bijvoorbeeld als er een filebericht was om 09:05 en de update op dat filebericht arriveert om 09:25. Dan moet dit filebericht aan de tijdsloten 9:10 en 9:20 worden toegevoegd. Vervolgens moet de filelengte per tijdslot voor elk land worden bepaald. We hebben hiervoor een query ontworpen die dit alles in één keer toevoegt aan de database: INSERT INTO SNAPSHOT_TOTAL_LENGTH SELECT ST.ID AS SNAPSHOT_TIME, COUNTRY, SUM(JAMLENGTH) AS TOTAL_LENGTH FROM SNAPSHOT_TIME AS ST JOIN SNAPSHOT_TO_TRAFFICJAM AS STT ON ST.ID=STT.SNAPSHOT_TIME JOIN TRAFFICJAM AS T ON STT.TRAFFICJAM=T.ID GROUP BY ST.ID, COUNTRY;

Dit is een INSERT statement met daarin een SELECT statement. Alle data die nodig is in de tabel SNAPSHOT_TOTAL_LENGTH is al aanwezig in de database. Middels de SELECT verzamelen we deze informatie en middels de INSERT wordt het in de tabel gezet. De tweede regel van de query zorgt dat de database snapt welke gegevens in welke velden moeten komen. We hernoemen het 1e en 3e gegeven naar veldnamen van de doeltabel. De SELECT-query sommeert de filelengte per tijdslot per land. Het voordeel van deze query is dat er geen data over het netwerk hoeft, maar dat de database dit zelf kan afhandelen. Vervolgens wordt er bepaald hoe druk de spits is geweest voor de slide drukste spitsen. Dit wordt in de TOP_RUSHHOUR tabel geplaatst.

3.4

Wegen tekenen

Om de wegen te kunnen tekenen (en er vervolgens ook files op te kunnen positioneren) is het belangrijk om over vectordata van de wegen te beschikken. Er waren twee verschillende mogelijkheden om deze vectordata te verkrijgen:  

Uit de engine de vectordata voor wegen zien te filteren en eventueel aan de hand van de RijksDriehoek-tabel (RD-tabel) deze coördinaten te koppelen met wegnamen, indien nodig. De wegen handmatig tekenen.

Het voordeel van de eerste oplossing is dat wanneer de kaart wordt geüpdate met nieuwe wegen, je deze data ook gelijk beschikbaar hebt in je applicatie. Het nadeel van de eerste oplossing is dat het enorm ingewikkeld is om deze vectordata uit de engine te filteren. Verder is de RD-tabel alleen voor Nederland beschikbaar. Dit zou betekenen dat elk land zijn eigen benadering zou moeten hebben. Het voordeel van de wegen zelf tekenen is dat je controle hebt over de wegen en wat er wel en niet in de vectordata komt. Verder is de aanpak identiek voor elk land. Ook geeft het snel zichtbare resultaten, wat vanuit de SCRUM-optiek (zie bijlage A) belangrijk is. Het nadeel is dat wanneer wegen veranderen, dit handmatig moet worden aangepast. We hebben ervoor gekozen om zelf de wegen te tekenen, omdat we daardoor een identieke aanpak voor elk land zouden hebben en snel zichtbare resultaten konden produceren. Ook is het mogelijk om een enkele weg makkelijk aan te passen, zonder dat je afhankelijk bent van de kaart in MapServer. Wanneer bijvoorbeeld de A4 doorgetrokken wordt tussen Delft en Rotterdam, dan zou 23

het met onze oplossing binnen enkele minuten toegevoegd kunnen worden zonder dat er een nieuwe kaart van de kaartengine nodig is. We hebben een simpele applicatie ontwikkeld die het tekenen van de wegen makkelijk maakt. Deze applicatie werkt met de MapServer engine en geeft de kaart van Europa weer. De gebruiker moet op de wegen in de kaart zogenaamde wegpunten aanklikken. Tijdens het klikken op de kaart wordt de weg getekend zoals hij in onze applicatie wordt weergegeven. De weg wordt in XML-formaat op het scherm getoond zodat de gebruiker het alleen maar hoeft te kopiëren-plakken naar de XML met alle wegen. Zie beheerdocumentatie in bijlage D.

3.5

Files tekenen

Om files te kunnen tekenen op de kaart moeten ze eerst gekoppeld worden aan een weg en vervolgens op die weg gepositioneerd worden. Uit de uitgebreide TMC-tabel bepalen we aan de hand van de TMC-locatiecode de wegnaam. Deze wegnaam wordt vervolgens gematcht met de wegnamen van onze vectordata van de wegen. Wanneer het lukt om de wegnaam te koppelen aan een weg uit onze vectordata kan de file op de weg gepositioneerd worden. De coördinaten van een file liggen (vanwege de conversie van TMC naar GPS naar Mercator) niet exact op de weg. Een voorbeeld van een situatie met het begin en eindpunt van een file is hieronder weergegeven. W1 tot W6 zijn de coördinaten van de weg. J1 en J2 zijn de coördinaten van het start en eindpunt van de file.

Figuur 6: Een weg met twee filecoördinaten

Hieronder een voorbeeld met het bepalen van de positie van J2 op de weg:

Figuur 7: Locatiebepaling filepunt

24

Met behulp van de stelling van Pythagoras zijn de volgende formules te bepalen: C2 = X²+h² B2 = (A-X)²+h² Deze formules zijn te herschrijven tot: X = (A²-B²+C²) / (2 ∙ A) h = √(C² - X²) De X is nodig om de plaats op het wegstuk te bepalen en de hoogte is belangrijk om de afstand tot het wegstuk te bepalen, zodat de file op het dichtstbijzijnde wegstuk word gepositioneerd. Als X < 0 of X > A dan wordt C respectievelijk B als afstand gebruikt in plaats van h. De reden hiervoor is dat het punt niet recht boven het stuk weg zit, maar wel op dat wegpunt kan horen (zie figuur 4: speciaal geval, X > A tussen W2 en W3 en X < 0 tussen W3 en W4).

Figuur 8: Speciaal geval, X > A tussen W2 en W3 en X < 0 tussen W3 en W4

3.6

Testen

Door gebruik te maken van de werkmethode SCRUM, welke voornamelijk gericht is op eindresultaten, bestaat het risico dat de kwaliteit van de software wel eens wat minder aandacht krijgt. Om er toch voor te zorgen dat de kwaliteit van de software goed blijft hebben we de applicatie getest met o.a. behulp van unittests. Doormiddel van een unittest is aan de hand van bekende invoer te controleren of de functie de gewenste uitvoer genereert. Ook tussentijdse veranderingen kunnen hierdoor eenvoudig worden getest. Door goed onderscheid te maken tussen de data en wat er grafisch weergegeven moet worden hebben we geprobeerd zo veel mogelijk functionaliteit met behulp van unittests te testen. Zo hebben we unittests gemaakt voor belangrijke functionaliteiten, zoals het creëren en tekenen van wegen en files. Nadat gebleken is dat Erika na sprint 4 niet stabiel draaide hebben we besloten om een extra week te besteden om Erika stabieler te maken. Dit hebben we gedaan aan de hand van een testplan (zie bijlage G). In dit testplan hebben we problemen bedacht waar Erika mogelijk niet goed op zou 25

reageren. Door deze problemen na te bootsen, hebben we gekeken of Erika goed reageert. Zo niet, dan hebben we het probleem opgelost en waar mogelijk een unittest geschreven voor het probleem. Hierna zijn we de problemen weer na gaan bootsen om te controleren of Erika hier nu wel goed op reageert. We hebben de volgende probleemdomeinen geïdentificeerd:   

A: Database onbereikbaar B: Onverwachte softwareomgeving (benodigde software niet aanwezig) C: Interne problemen

We zijn onze applicatie gaan testen voor probleemdomein A en C. Probleemdomein B zou zich niet moeten voordoen indien de beheerder Erika installeert volgens de installatiedocumentatie. Een probleem waar we tegenaan liepen is dat bepaalde functionaliteit dingen grafisch weergeeft. Deze functionaliteit hebben we dan ook voornamelijk getest door het uit te voeren en met het oog te controleren. Hierbij kan gedacht worden aan:  Het weergeven van het juiste land;  Het correct toepassen van de instellingen van slides en  Het tonen van correcte informatie in de statusbar. Ook was het lastig om bepaalde databasefunctionaliteiten te controleren. Hiervoor hebben we een aparte testdatabase aangemaakt waar per test case records aan toe worden gevoegd die direct na de unittest weer worden verwijderd. Hierdoor konden we controleren of er voor een bepaald filebericht de juiste records in de database worden gezet.

3.7

Configuratiemogelijkheden

De applicatie geeft een aantal slides weer aan de hand van een in te stellen afspeellijst. Om eenvoudig wijzigen te kunnen maken in de afspeellijst hebben we besloten deze op te slaan in een XML-bestand. Hierdoor is het achteraf eenvoudig om voor een andere afspeellijst te kiezen. De instellingen van de database staan ook in een apart XML-bestand. Hierdoor kunnen eenvoudig wijzigingen worden gemaakt in de locatie van de database zonder dat de applicatie opnieuw moet worden gecompileerd. We hebben ervoor gekozen om juist deze instellingen uit een XML-bestand te halen omdat deze vermoedelijk het meest zullen worden gewijzigd. Hieronder is een voorbeeld te vinden van de instellingen van de historische database. erika ******** 192.168.32.4 /var/database/%s.gdb eurotraffic_hist

Een uitgebreide beschrijving van de database XML is te vinden in de beheerdocumentatie (zie bijlage D).

26

Naast de configuratiemogelijkheden voor de afspeellijst en de database is er ook een aantal instellingen te wijzigen voor de slides. Een voorbeeld van instellingen van de kaart weergave van Nederland is hieronder te zien. <SLIDE> KaartNL <TITLE>Nederland NL MAP <SCALEFACTOR>4000 350438 7115673 1016788 6529285 True

Een uitgebreide beschrijving over hoe deze ingesteld kan worden is te vinden in de beheerdocumentatie (zie bijlage D). In dit XML-bestand kunnen nieuwe configuraties van bestanden slides worden gedefinieerd. Ook kunnen hier nieuwe soorten slides worden toegevoegd. Naast deze instellingen zijn er ook nog andere instellingen voor de slides zoals kleuren en tijdsintervallen. We hebben er voor gekozen om deze niet uit een XML-bestand te halen. De nadruk van de applicatie moest liggen op een stabiele applicatie en niet op een uitgebreide instelbare applicatie. Wel hebben we rekening gehouden met eventuele latere uitbreiding om ook deze configuratiemogelijkheden naar een XML-bestand te verplaatsen. Zo zijn alle slides aan de hand van constanten in te stellen en staan al deze constanten op één plek opgeslagen. Een nadeel van de oplossing is dat Erika opnieuw gecompileerd moet worden om instellingen in de slides te kunnen doorvoeren. We hebben er voor gekozen om alle instellingen in XML-bestanden op te slaan, omdat Tenuki een library heeft om eenvoudig gegevens uit een XML-bestand te halen.

3.8

Slideshowwisselaar

De applicatie moet verschillende soorten weergaves van file-informatie vloeiend in elkaar over laten gaan. Om dit principe te realiseren hebben we er voor gekozen om een slideshowwisselaar te laten beslissen welke slide wanneer weergeven moet worden. Een slide krijgt hierbij een tijdsduur mee van de slideshowwisselaar. Binnen deze tijd mag de slide zelf beslissen hoe hij de tijd gebruikt en welke file-informatie hij weergeeft. Door een slide van te voren te laten voorbereiden, hebben we er voor gezorgd dat de slides beter in elkaar overlopen. Gedurende de eerste sprints duurde het ophalen van de data soms erg lang, maar gelukkig is dit gedurende het project verbeterd. In eerste instantie door het maken van een lokale database en in tweede instantie door het ophalen van nieuwe data los te trekken van Erika. Hierdoor hoeft niet bij elke slide een update te worden uitgevoerd. Ook zijn de queries die de data ophalen uit de database geoptimaliseerd.

27

Doordat het voorbereiden van de data voor de volgende slide een kleine vertraging veroorzaakt in het tonen van de huidige slide maken we gebruik van twee pagina’s die we afwisselen. Eén pagina die de huidige slide weergeeft en één pagina die de kaart of grafiek van de volgende slide voorbereidt. Door deze achter elkaar te draaien hoef de timer alleen maar de pagina’s op het juiste moment te wisselen. Ook kregen we te maken met het probleem dat de MapServer-engine maar één View tot zijn beschikking had. Zodra alle gegevens op de kaart zijn getekend renderen we een plaatje welke vervolgens wordt weergegeven. Voordat het nieuwe plaatje gerenderd wordt moet eerst alle oude data goed verwijderd worden van de kaart. Opmerking: Doordat het voorbereiden van een slide die veel informatie moet ophalen soms nog lang duurt, hebben we gesteld dat de minimale tijd dat een slide moet worden weergegeven 10 seconden is. Dit is een zeer redelijke beperking aangezien we geen slides hebben gemaakt waar men binnen 10 seconden al op is uitgekeken.

3.9

Slides

Aan de hand van de PowerPoint presentaties zijn de slides nagemaakt. Een uitgebreide omschrijving van de slide is te vinden in bijlage E. Hieronder is het eindresultaat te zien van de verschillende soorten slides in de applicatie. Hieronder zijn alleen de weergaven voor de Nederlandse slides te zien. Deze slides zijn er echter ook voor de andere toegevoegde landen.

Figuur 9: Kaart weergave Nederland (links) en Statistiek fileverloop trend van Nederland (rechts)

28

Figuur 10: Kaart weergave Delft (links) en statistiek filelengte Nederland van de afgelopen 6 uur (rechts)

Figuur 11: Fileverloop kaart (links) en top 10 drukste spitsen van Nederland (rechts)

3.10 Uitbreidbaarheid Een nieuw land toevoegen is in enkele stappen te realiseren (voor uitgebreide documentatie, zie beheerdocumentatie in bijlage D).      

De wegen van een land moeten gedefinieerd worden. De database met ruwe file-informatie van het land moet worden toegevoegd. De TMC-locatie database met GPS-coördinaten moet worden toegevoegd. De Extended TMC Database met wegnamen moet worden toegevoegd. De slides moeten gedefinieerd worden in slides.xml In onze applicatie moet een string met de landcode van dat land worden toegevoegd, zodat het als geldig land wordt beschouwd in de applicatie.

Het voordeel van de structuur van onze implementatie is dat er in de broncode slechts één kleine wijziging nodig is. Daarom kan in principe iedereen met beschikking over de juiste databases een nieuw land toevoegen. Het is niet noodzakelijk dat voor elk land alle gegevens over een file 29

beschikbaar zijn, de update-applicatie verwerkt elk filebericht waarin genoeg informatie staat om voor onze applicatie nuttig te zijn. Waar mogelijk vult de update-applicatie ontbrekende gegevens aan. Een nieuw type slide toevoegen wordt ook goed ondersteund door onze applicatie (zie beheerdocumentatie in bijlage D). Het nieuwe type slide moet overerven van de superklasse TView. Deze klasse heeft een aantal abstracte procedures die elke slide moet implementeren. Hieronder is een overzicht te zien van de structuur van TView. TView constructor Create(AOwner: TComponent; ASlideName, ACountry: String; ADuration: Integer) procedure PrepareData(); (abstract)

Hiermee wordt aangegeven dat een slide zijn data moet inladen voor de weergave.

procedure DisplayData(); (abstract)

Hiermee wordt aangegeven dat een slide zichzelf moet laten zien

function GetLastUpdate(): TDateTime;

De tijd van de laatste filemelding die is meegenomen in de slide

procedure RemoveDrawnObjects(); (abstract)

Deze procedure is met name voor de slides die de kaartengine gebruiken belangrijk. Deze slides gebruiken dezelfde kaartengine. De volgende slide kan geen bitmap maken van de kaartengine totdat de huidige slide zijn objecten van de kaartengine heeft verwijderd.

property Duration: Integer

De duration die de slide van de slideshowwisselaar heeft gekregen. Hiermee kan een slide bijvoorbeeld bepalen hoe lang hij files wilt selecteren.

property PreparingData: Boolean

Een Boolean die bepaald of een slide klaar is met het voorbereiden van de data voor de weergave.

property SlideName: String

De naam/type van de slide (E.g. StatistiekFileLengteNL)

property Title: String

De titel van de slide (E.g. “De filelengte (km) afgelopen 6 uur in Nederland”)

30

Sectie 4: Fasen in het project Tijdens het project hebben we vier sprints doorlopen. Onze sprints waren perioden van twee werkweken waarin we naar een zichtbaar resultaat toewerkten. Aan het begin van iedere sprint bepaalden we wat er gedaan moest worden en aan het einde van iedere sprint evalueerden we de sprint. Zie het onderzoeksverslag in bijlage A voor meer informatie over SCRUM. In deze sectie geven we een overzicht wat er gedaan is tijdens elke sprint en wat onze leerpunten waren. Verder laten we de burndown charts zien en proberen we te verklaren wat er gebeurd is. Zie sectie 1.5 voor meer informatie over burndown charts.

4.1

Sprint 1

Het doel voor de eerste sprint was de applicatie waarvan de basis werkte. Voordat we met deze sprint begonnen hadden we al een documentatiefase gehad. Het grootste deel van het onderzoek was klaar. Aan het begin van de sprint konden we dus beginnen met het ontwerpen van de applicatie. Details hierover zijn te lezen in sectie 2. Ondertussen hebben geprobeerd om te programmeren met de drie uitgekozen kaartengines: MapServer, Google Maps en TatukGIS. Aan het einde van de sprint hebben we nog een zeer beperkte applicatie gemaakt die liet zien dat we de engine al kunnen gebruiken en al weten hoe we grafieken moeten tekenen op het scherm. De volgende figuur bevat de burndown chart van sprint 1.

Figuur 12: Burndown chart van sprint 1

De realisatielijn van de burndown chart loopt de eerste twee dagen nog redelijk stijl. Vanaf donderdag begon het tegen te vallen. Het ontwerpen van de architectuur bleek langer te duren dan verwacht, omdat het moeilijker was dan we van tevoren dachten. Op maandag zijn er twee taken bij gekomen: een tussenpresentatie voor Tenuki en de sprintevaluatie welke we vergeten waren om op de sprint backlog te zetten. Al met al liep tijdens deze sprint de realisatielijn steeds verder weg van de richtlijn. Naast de hierboven genoemde redenen kan er gezegd worden dat we het aantal beschikbare uren van 20 uur per dag te optimistisch ingeschat hadden: het aantal uur dat we effectief kunnen werken aan de taken ligt lager. 31

Behaalde resultaten:  Ontwerp van de applicatie in de vorm van twee PowerPoint-presentaties  Ontwerp van de architectuur  Keuze gemaakt tussen kaartengines  Zeer minimale applicatie gemaakt die twee slides afwisselt Niet behaald:  Begin maken aan de applicatie (files uit de database halen en slides afwisselen) Voornemens voor volgende sprint:  Resultaten duidelijker vaststellen  Daardoor betere tijdinschatting maken  Taken meer parallel uitvoeren  Verantwoordelijkheid nemen voor onze taken  Het aantal beschikbare uren niet te optimistisch inschatten

4.2

Sprint 2

Het plan was om aan het einde van sprint 2 een werkende applicatie te laten zien met file-informatie van Nederland. Dit omvatte alle kaartslides, maar geen statistieken. Het is gelukt om de overzichtskaart van Nederland te maken plus alle vijf de regio’s die we in gedachten hadden. De fileverloopkaart is niet gelukt. De volgende figuur bevat de burndown chart van sprint 2.

Figuur 13: Burndown chart van sprint 2

Deze grafiek ziet er al wat positiever uit dan die van sprint 1. Het is ons zelfs gelukt om onder de richtlijn uit te komen op vrijdag doordat een aantal taken minder tijd kostten dan verwacht. De reden dat de realisatielijn weer boven de richtlijn verder gaat en niet veel dichter meer bij de richtlijn komt is dat we een aantal technische problemen tegen kwamen zoals memory leaks, incomplete fileberichten en files die niet op een weg getekend konden worden.

32

Behaalde resultaten:  

Overzichtskaart met files van heel Nederland Slide van een regio (Rotterdam/Den Haag, Eindhoven, Amsterdam, Utrecht) die de vijf langste files één voor één afloopt

Niet behaald:  Fileverloopkaart die de file op- en afbouw laat zien van de afgelopen twee uur in de regio Rotterdam/Den Haag. Voornemens voor volgende sprint:  Voor grote beslissingen moet afgestemd worden met de Product Owner wat belangrijk is. We moeten voorzichtiger zijn met dit zelf in te vullen.  In het vervolg beginnen we eerder met Unit tests maken. We weten nu hoe het moet en we zijn er weer van bewust hoe handig ze zijn om bugs op te sporen.  Met name tijdens de QQQs in de ochtend moeten we ons verhaal begrijpbaar houden voor de omstanders (vaak alleen de Product Owner en de Scrum Master, David en Jeroen).

4.3

Sprint 3

Deze sprint was er op gericht om alle resterende soorten slides te implementeren voor zowel Nederland als België. Dit is goed gelukt, afgezien van een slide die nog opnieuw ontworpen moest worden. Verder zijn we deze sprint begonnen met het maken van de presentatiedatabase en de implementatie daarvan. De volgende figuur bevat de burndown chart van sprint 3.

Figuur 14: Burndown chart van sprint 3

Deze grafiek ziet er nog beter uit dan die van sprint 2. De lijn daalt snel, omdat de sprintdefinitie maar 2/3 van de tijd vulde. Daarom hoeft er maar 10 uur aan taken afgerond te worden om even snel te dalen als de richtlijn. Het was wel de bedoeling dat we deze sprint tijd over zouden om wat technische probleempjes op te lossen. Woensdag de 27e is de presentatiedatbase toegevoegd aan de sprintbacklog en donderdag 28 mei waren we in Walibi, dus hebben we niets geïmplementeerd. Ook

33

de dag na de 28e verliep niet erg constant, dit komt doordat het toevoegen van de presentatiedatabase en het ontwerpen van een goede statistiek meer tijd kostte dan gedacht. Behaalde resultaten:  België: kaartweergave met informatiebox  Nederland en België: filelengte statistiek  Nederland en België: filetrend van de afgelopen 4 zelfde dagnamen  Nederland en België: buienradar Niet behaald:  De derde statistiek slide, ‘langste files van de afgelopen maand’. Uit feedback op de PowerPoint bleek dat deze er anders uit moest komen te zien. Voornemens voor volgende sprint:  Gedurende de sprint moeten we onze urenschattingen vaker aanpassen op basis van voortschrijdend inzicht. Omdat de urenschatting niet meer klopte was het nu soms niet duidelijk waar het grote werk inzat.  Nu is onze urenschatting vaak gebaseerd op een eerste ‘af’ versie. Voor de volgende keer is het handig ook tijd te plannen voor de ‘af-af’ versie.  Zodra we klaar zijn met de taken die we die dag zouden afronden het doel goed voor ogen proberen te houden. Zodat we aan taken beginnen die van nut zijn voor het sprint doel.  Vaker Asserts gebruiken om precondities te controleren en meer test-driven development toepassen zodat stukken code makkelijker met unittests zijn te controleren. Echter is het bij units als de slide show engine niet belangrijk om deze met unittests te testen.

4.4

Sprint 4

Het doel van sprint 4 werd als volgt vastgesteld: De applicatie helemaal af. Hierbij zouden de landen Zwitserland, Oostenrijk, Italië en Spanje nog worden toegevoegd. Een grote taak binnen deze sprint was de presentatiedatabase. Meer informatie over de presentatiedatabase is te vinden in sectie 3.2.

34

De volgende figuur bevat de burndown chart van sprint 4.

Figuur 15: Burndown chart van sprint 4

Na de eerst dag van de sprint prima op schema te liggen liepen we de tweede dag tegen een aantal grote problemen aan met de presentatiedatabase. Dit heeft er voor gezorgd dat we al vrij snel twee dagen achter op schema kwamen te liggen. De rest van de sprint hadden we gelukkig redelijk goed ingeschat en we konden zelfs wat tijd goed maken. Zoals in de grafiek te zien is zijn we niet geëindigd op nul uren. Er waren nog een paar kleine uitbreidingen overgebleven die weinig prioriteit hadden. Behaalde resultaten:  De volgende landen zijn toegevoegd: Zwitserland, Oostenrijk, Spanje en Italië. Dit maakt dat er in de applicatie 6 landen te zien zijn.  Alle verschillende soorten slides zijn te combineren met deze nieuwe landen.  Zeer kleine en beperkte applicatie gemaakt waarmee wegen getekend kunnen worden. Zie de gebruikersdocumentatie in bijlage B voor meer informatie.  Er is een presentatiedatabase aangemaakt die door de applicatie wordt bijgevuld met filegegevens uit de historische database. Niet behaald:  Werkende en stabiele applicatie.  Documentatie voor Erika (gebruikersdocumentatie, beheerdocumentatie en installatiedocumentatie).  De tijdsduur van een kaartweergave af laten hangen van het aantal files dat het moet langslopen.  Het verwijderen van files die meer dan 30 dagen oud zijn.  Het verwijderen van TRAFFICJAM records die niet meer nodig zijn.  Het herbouwen van de presentatiedatabase indien het filebeeldinterval wijzigt (dat is nu op 10 minuten ingesteld). Voornemens voor volgende sprint:  In de tijd die komt willen we zorgen dat er een stabiele versie van Erika komt.

35

4.5

Afrondingsfase

Omdat Erika niet langer draaide dan een paar minuten hebben we besloten om onze werktijd te verlengen en haar stabiel te krijgen. Daarbij zijn we er mee akkoord gegaan om de presentatie op de TU te doen in plaats van op Tenuki. We hadden dus nog genoeg te doen tijdens de afrondingsfase. Behaalde resultaten:  Erika draait langer dan 150 uur.  De update-applicatie is klaargemaakt om falende netwerkverbindingen en databaseservers te overleven.  De updater-applicatie verwijdert elke update alle data uit de presentatiedatabase die ouder is dan 30 dagen.  De applicatie die wegen tekent is enorm verbetert zodat er geen programmeerwerk meer aan te pas komt om wegen toe te voegen. Niet behaald: Erika draait zeer stabiel, dus het doel van de afrondingsfase is gehaald. We hebben zelfs meer werk verricht dan dat. Voornemens:  We hadden niet gedacht dat we nog zo veel kleine dingen konden verbeteren aan Erika. Er zijn veel wijzigingen aangebracht die geen significante fouten voorkomen, maar wel erg handig zijn voor de toekomstige programmeurs of de executie van het programma. Voor een volgend project moeten we er op toe zien dat we tijd inruimen voor een goede afronding van de software.

36

Sectie 5: Evaluatie In deze sectie evalueren we onze implementatie keuzes en evualeren we de werkwijze toegepast tijdens dit project.

5.1

Implementatie

Tijdens het project hebben we een aantal keuzes gemaakt, maar waren dit goede beslissingen? Per implementatiekeuze zullen we evalueren of dit een goede keuze is geweest. Delphi De programmeertaal Delphi hebben we nog niet eerder gebruikt. In de eerste weken was het vooral wennen aan vrijgeven van geheugen. We waren allemaal gewend met Java te werken, waar de garbage collector het geheugengebruik regelt. Daarom hadden we in het begin veel last van zogenaamde memory leaks: delen van het geheugen die niet meer gebruikt worden, maar toch geheugenruimte bezet houden. Achteraf gezien was het een voordeel om met Delphi te werken. Delphi biedt de mogelijkheid om snel zichtbare resultaten te produceren, omdat de IDE van Delphi Windows applicaties zeer goed ondersteunt. We hadden wel meer kennis over Java, maar Tenuki was goed bekend met Delphi. Daarnaast was het leuk om een nieuwe programmeertaal te leren en was het gebruik ervan ook leerzaam. Een bijkomend voordeel was dat Tenuki een library heeft met allerlei klassen die nuttig kunnen zijn voor veel voorkomende bezigheden van een programmeur. Zo konden we de XML-parser gebruiken, zodat wij onze tijd in andere dingen konden steken. Presentatiedatabase De keuze voor een presentatiedatabase was zonder twijfel een uitstekende keuze. De keuze hiervoor heeft ons veel extra implementatie tijd gekost, maar de enorme voordelen voor het tonen van met name historische weergaven wegen hier zwaar tegen op. Zo kost het nu veel minder rekenkracht en belangrijker, minder tijd, om een historische weergave op te bouwen. Zonder presentatiedatabase kostte het voorbereiden van de statistiekslide fileverlooptrend van de afgelopen vier zelfde dagnamen meer dan tien minuten. In deze tijd zit inbegrepen dat gegevens van een hele maand worden opgehaald uit de ruwe database en worden geconverteerd. Deze slide was dus niet realistisch toonbaar met de oude structuur. Met de presentatiedatabase duurt het voorbereiden van de statistiekslide minder dan vijf seconden. In de tijd moeten alleen de gegevens uit de presentatie database te worden gehaald. Het converteren gebeurt als de data in de presentatiedatabase wordt gezet. De tijd voor het converteren is gelijk gebleven, maar het voordeel is dat deze slechts eenmalig gedaan hoeft te worden. Daarnaast is de tijd voor het converteren niet relevant voor de bovenstaande vergelijking, omdat alleen de duur van het opbouwen van een slide belangrijk is voor een vloeiend verloop van de slideshow. Verder worden er geen dubbele conversies op de data uitgevoerd, omdat de data slechts één keer geconverteerd hoeft te worden. Daarnaast hebben we nu een duidelijke scheiding van ruwe data en presentatiedata, hetgeen de applicatie een stuk overzichtelijker, dus beter onderhoudbaar maakt (Zie figuur 4 en 5 in sectie 3.3). Voor de structuur van de database hebben we ervoor gekozen om de tabellen zo in te richten dat er geen dataconversie meer gedaan hoeft te worden door de slides die data uit de presentatiedatabase lezen. Door deze keuze is er in verschillende tabellen gelijkende data te vinden. Deze indeling biedt echter veel tijdswinst voor de applicatie. Het volgende voorbeeld verduidelijkt dit. Stel om 14:00 wordt de statistiekslide drukste spitsen weergegeven, indien de data in de tabel nog bewerkt moet

37

worden, moet er eerst een bewerking worden gedaan op alle data van de afgelopen dertig dagen, om zo te komen tot de top 10 drukste spitsen van de afgelopen maand. Wanneer de slide om 15:00 weer wordt weergegeven, moet dezelfde dataconversie over de afgelopen dertig dagen plaatsvinden. Wanneer de dataconversie bij het vullen wordt gedaan, hoeft voortdurend alleen de meest recente data geconverteerd te worden (tijdens het vullen). Update-applicatie Omdat een update voor alle zes landen tussen de één en vijf minuten duurt, was het onmogelijk om dit in onze single-threaded applicatie te houden zonder dat de weergave eronder zou lijden. De mogelijke oplossingen waren een aparte update-applicatie of onze applicatie multi-threaded maken. We hebben gekozen voor de update-applicatie. De reden hiervoor was de complexiteit en de bijbehorende risico’s die het multi-threaded maken van onze applicatie met zich mee zou brengen. Achteraf gezien was het een goede keuze, aangezien het lostrekken van de applicatie weinig tijd heeft gekost en de functionaliteit van Erika flink is verbeterd. Daarnaast is de robuustheid van Erika ook verbeterd, omdat de verschillende verantwoordelijkheden beter gescheiden zijn en mocht een van de twee applicaties crashen, dan heeft dit geen directe invloed op de andere applicatie. Enginekeuze De keuze van MapServer als kaartengine lijkt een goede keuze te zijn geweest. Ten eerste had Tenuki al veel kennis over deze engine en konden we een aantal Tenuki libraries gebruiken voor deze kaartengine. Dit scheelde ons weer code en tijd. Daarnaast werkte de engine intuïtief en was het implementeren van methoden die gebruik maken van de engine daarom niet erg complex. Ook heeft de MapServer engine een grote instelbaarheid. Zo kan de mate van extra data op de kaart (bergen, steden, wegen, etc.) relatief makkelijk ingesteld worden. Daarnaast is de engine makkelijk aan te spreken vanuit de Delphi-omgeving. Testen Vaak hebben we de voordelen van test-driven development gemerkt. Deze aanpak zorgde voor betere code, zowel structureel als functioneel. Om een bepaalde unit te kunnen testen, moet je namelijk zorgen dat deze unit niet afhankelijk is van andere units voor zijn output. Dit zorgt voor ‘Loose Coupling’ (zie bijlage A); elke unit kan zelfstandig opereren en zou eventueel vervangen kunnen worden door een andere unit met dezelfde functionaliteit (en interface) zonder dat de applicatie in de problemen komt. Daarnaast kan je de werking van de code met behulp van unittests beter garanderen en falende unittests zijn ook gelijk documentatie van bugs. Wanneer de code wordt veranderd garanderen de unittests dat de code nog steeds werkt. Ook konden we makkelijk bugs traceren doordat het geval waarin het mis gaat gelijk duidelijk is. Helaas hebben we niet voor alle units unittests kunnen toepassen. Met name weergaven (wat wordt er getoond) is lastig met een unittest te testen. Daarnaast was het lastig om voor het vullen van de presentatiedatabase elk scenario te testen. Het testplan (zie bijlage G) hielp ons om Erika zeer stabiel te krijgen. Uiteindelijk heeft de Erika applicatie meer dan 150 uur zonder onderbreking gedraaid. Configuratiemogelijkheden De configuratiemogelijkheden van Erika zijn beperkt, maar de belangrijkste instellingen zijn wel extern instelbaar. Dit is in overeenstemming met de wensen van de opdrachtgever, die geen zeer uitgebreide configuratiemogelijkheden wenste. Wel zijn er een aantal instellingen, waarvan het

38

handiger geweest zou zijn als die extern instelbaar zijn. Deze zijn terug te vinden in de aanbevelingen (zie sectie 7). Uitbreidbaarheid Met name het toevoegen van landen gaat erg makkelijk in de applicatie. Dit ondervonden we zelf, toen we de applicatie uitbreidden van Nederland en België tot Nederland, België, Italië, Oostenrijk, Spanje en Zwitserland. In de code moet weinig tot niets veranderd worden. Dit is natuurlijk een voordeel van de implementatie structuur die we hebben gekozen. Het toevoegen van een nieuw type slide moet uiteraard in de code gebeuren. Maar door een goede superklasse te definiëren waaruit elke slide moet overerven, kan Erika makkelijk nieuwe typen slides weergeven en gebruiken. Afvallen van Opdracht B Het wegvallen van Opdracht B gaf ons meer tijd om Erika stabiel, robuust te maken. Daarnaast konden we de prestatie van Erika verbeteren, door ons bezig te houden met het optimaliseren van queries, databewerkingen en weergaven. Aangezien we een week meer hebben gewerkt dan vooraf voor de gehele stage gepland, was het afronden van Opdracht A blijkbaar al genoeg werk. Als we opdracht B niet hadden laten vallen zouden het twee zeer summiere applicaties zijn geworden. Nu we veel tijd hebben kunnen besteden aan het verbeteren van opdracht A, is het een applicatie geworden waar Tenuki iets mee kan. Het is onwaarschijnlijk dat dat binnen de beschikbare tijd ook was gelukt met opdracht B erbij.

5.2

Werkwijze

In deze paragraaf wordt terug gekeken op onze werkwijze gedurende de gehele stage. Samenwerking Gedurende de eerste fase van het project verliep de samenwerking niet altijd even goed. We zijn begonnen met het maken van een onderzoeksverslag. Tijdens het maken van dit verslag hebben we veel lange discussies gevoerd die soms wel korter hadden kunnen zijn. Hierdoor heeft het veel tijd gekost om het onderzoeksverslag af te ronden. Gedurende de rest van het project verliep de samenwerking veel beter. Als er een belangrijke keuze moest worden gemaakt kwamen we bij elkaar om erover te discussiëren. Zo waren we het allemaal eens met de keuzes die we hebben gemaakt. Verder hebben we voornamelijk los van elkaar aan eigen resultaten voor de applicatie gewerkt om zo productiever te zijn. Zodra we tegen een probleem opliepen haalden we er eerst een teamgenoot bij om te kijken of we er met behulp van pair-programming wel uitkwamen. Zo niet, dan konden we hulp vragen bij David. Door middel van de dagelijkse QQQs (zie sectie 1.5) hielden we elkaar op de hoogte van de voortgang. Gebruik van SCRUM Tijdens dit project hebben we gebruik gemaakt van de voor ons nieuwe methode SCRUM (zie sectie 1.5). In het begin van de stage moesten we hier nog erg aan wennen. Door dagelijks een QQQ meeting te houden, konden we elkaar op de hoogte houden van de voortgang van het project. Als we tegen een probleem aanliepen was dit gelijk te zien in de burndown chart zodat er kon worden ingegrepen. In de praktijk waren we echter wat aan de late kant om dit te melden. Het was beter geweest om al één of twee dagen eerder aan te geven dat we tegen een probleem aanliepen. Naarmate het project vorderde ging dit steeds beter. Verder waren we tijdens de QQQs niet altijd even duidelijk met het verwoorden van de resultaten die we de vorige dag hadden behaald en de 39

resultaten waar we die dag aan gingen werken. Naarmate het project vorderde ging dit wel steeds beter. Hieronder zullen we de belangrijkste voordelen en nadelen van SCRUM opsommen: Voordelen: - Veelvuldig overleggen met de opdrachtgever en je teamgenoten zorgt voor een goede verwachting . - Geen onrealistische planning aan het begin van het project maar een continue verbeterende planning . - Taken met de hoogste prioriteit voor het einddoel worden als eerste uitgevoerd. Hierdoor is er ruimte voor eventuele plotselinge veranderingen vanaf de opdrachtgever. Ook garandeert dit dat de belangrijkste dingen zijn uitgevoerd wanneer er door tijdgebrek taken moeten worden afgeschreven. - Zichtbare resultaten in een vroeg stadium. Nadelen: - Doordat de nadruk meer op resultaten ligt, bestaat het risico dat de kwaliteit van de code minder aandacht krijgt. Door gebruik te maken van testen kan ervoor worden gezorgd dat er goede code wordt geleverd. - Doordat niet alles van tevoren is gepland ontstaat er onzekerheid over tijd, kosten en functionaliteit. Daarentegen wil de opdrachtgever nog wel eens plotseling veranderingen doorvoeren waar met behulp van SCRUM rekening mee gehouden kan worden. Tenuki werkwijze De nadruk van de Tenuki-werkwijze ligt heel erg op verwachtingsmanagement. Door een goed verwachtingsmanagement weet iedereen wat de stand van zaken is en waar hij aan toe is. Verder zijn de code conventies ook erg belangrijk bij Tenuki. Door ons zo veel mogelijk aan de conventies van Tenuki te houden is de code een stuk beter leesbaar door andere Tenuki-medewerkers. We hadden enige moeite om het ‘wat’ en het ‘hoe’ te scheiden. Dit bleek onhandig te zijn als je met iemand communiceerde over een probleem of functionaliteit. Langzamerhand konden we de twee steeds beter scheiden. We moeten eerlijk bekennen dat we in onze dagelijkse bezigheden de vier stappen van Tenuki niet vaak bewust hebben toegepast. De terugkoppeling naar de opdrachtgever is in sprint 3 verkeerd gegaan, maar in sprint 4 ging dat prima. Af en toe hebben we elkaar wel gevraagd: ‘Wat wil je’ en daarna: ‘Hoe wil je dat bereiken?’ Maar verder zijn we er niet bewust mee bezig geweest. Het is ons wel duidelijk wat de vier stappen betekenen en waarom ze zeer nuttig zijn. Conclusie Of SCRUM er nu voor heeft gezorgd dat we een beter product hebben afgeleverd dan met het Waterfall-model is moeilijk te zeggen, zeker omdat we weinig praktische ervaring hebben met de Waterfall-methode. Wel hebben we gedurende de stage een aantal grote veranderingen aan de architectuur van Erika doorgevoerd. Als we gebruik hadden gemaakt van het Waterfall-model hadden we dit waarschijnlijk niet zo eenvoudig kunnen toepassen. We zijn echter wel zeer tevreden over het gebruik van SCRUM en de Tenuki werkwijze. Zo hebben we een aantal wijsheden geleerd die we later zeker nog goed kunnen gebruiken. Zo is duidelijk 40

geworden dat verwachtingsmanagement erg belangrijk is en ook het duidelijk zijn ten opzichte van elkaar en de opdrachtgever. Verder is het nuttig om altijd het doel van een taak goed voor ogen te houden.

5.3

Tenuki

Al met al hebben we zo’n 12 weken lang rondgelopen op het Tenuki-kantoor. Elke dag zaten we achter onze dubbele beeldschermen op ons bacheloreilandje. In sectie 1 is al verteld wat Tenuki is en wat ze doen. In deze paragraaf zullen we vertellen wat onze indruk is van het bedrijf en onze mening over de begeleiders. Het bedrijf Het eerst wat ons opviel is dat we redelijk snel kennis maakten met alle medewerkers in het bedrijf. Iedereen steekt ’s ochtends zijn hoofd om de hoek van ieder kantoortje en tijdens de lunch zit je met elkaar aan tafel. Dat contact met de medewerkers vonden we erg leuk. Na een paar weekjes voelden we ons al onderdeel van Tenuki, in plaats van ‘wij en zij’. We werden betrokken bij presentaties over lopende projecten en andere zaken die Tenuki bezighield. We mochten zelfs mee met het bedrijfsuitje naar Walibi World! Dit is het voordeel van een klein bedrijf, je kent iedereen snel en weet waar je ze kunt vinden. Bij Tenuki hechten ze veel waarde aan het tevreden houden van de klant. Dit doen ze door aan verwachtingsmanagement te doen en te werken met zichtbare resultaten. Dit vinden wij een waardevolle eigenschap van het bedrijf. Voordat we met de stage bij Tenuki zijn begonnen hebben we eerst een snelcursus Delphi gekregen. Tijdens deze snelcursus Delphi hebben we de basis principes van Delphi geleerd. Deze cursus is erg nuttig en is zeker een aanrader voor een eventuele toekomstige stagegroep die ook nog geen ervaring heeft met Delphi. Begeleiders Tijdens het gehele project zijn we begeleid door David en Jeroen. David is de eigenaar van Tenuki en nam de rol van Product Owner op zich. Jeroen is een programmeur die de rol van Scrum Master kreeg. Voor oplossingen voor technische problemen konden we bij David terecht, omdat hij veel ervaring heeft met programmeren en de programmeertaal Delphi. Wij zijn zeer tevreden over de inzet van onze begeleiders. Ze hebben er veel tijd in gestoken. Afgezien van de QQQs en de Review Meetings aan het einde van elke sprint, zijn ze ook betrokken geweest bij de meetings met Peter. David heeft ons tijdens het gehele traject feedback gegeven: in de beginfase over onze documentatie en de opdrachtomschrijving en in de fasen daarna over onze werkwijze en aanpak. Terugkerende thema’s waren: focus je op het doel, wees duidelijk in je communicatie naar buitenstaanders en doe het belangrijkste eerst. Jeroen heeft ons ook dezelfde soort feedback gegeven, vooral tijdens de QQQs. Op de begeleidingen hebben we niet veel aan te merken. In het begin van de stage hebben we naast de dagelijkse QQQs veel besprekingen gehouden met de Product Owner om te kijken of we op de goede weg zaten. Naarmate het project vorderde was dit minder nodig.

41

Sectie 6: Conclusies Gedurende 12 weken hebben we bij Tenuki gewerkt aan het grafisch weergeven van file-informatie. Dit bleek een zeer uitdagende en interessante opdracht. De applicatie moest niet alleen interessant en mooi zijn, maar ook robuust en stabiel. Vooral het laatste bleek een uitdaging in een instabiele omgeving, waar de database wel eens onbereikbaar kan zijn en fileberichten niet altijd volledig zijn ingevuld. Uiteindelijk zijn we erin geslaagd een zeer stabiele applicatie te ontwikkelen die meer dan 150 uur zonder onderbreking heeft gedraaid. We stonden ook voor de taak om te zorgen dat de slideshow vloeiend afgespeeld zou worden. Het converteren van data en het opbouwen van slides mochten de weergave van een slide dus niet aantasten. Dit is er goed gelukt. Zo kost bijvoorbeeld het opbouwen van een statistiekslide tijdens de spits niet meer dan vijf seconden. Dit is grotendeels te danken aan de presentatiedatabase. Deze vijf seconden zijn zeer acceptabel, want het opbouwen van een slide gebeurt tijdens de weergave van de slide ervoor. De weergave van een slide is altijd langer dan vijf seconden. Al met al kunnen we concluderen dat we veel van deze problemen goed hebben weten op te lossen en daarmee veel hebben geleerd over deze probleemdomeinen. Verder hebben we qua proces en aanpak een hoop geleerd. De werkwijze van Tenuki was nieuw voor ons, een Agile ontwikkelmethode (SCRUM) gecombineerd met een aantal Tenuki-principes. Vooral in het begin moesten we wennen aan met name de principes ‘gericht werken naar een doel’ en ‘verwachtingsmanagement’. Gelukkig leerden we naar mate het project vorderde, de werkwijze van Tenuki steeds beter toe te passen. We waren zeer te spreken over de Agile ontwikkelmethode, aangezien het hebben van een zichtbaar tussenproduct ervoor zorgt dat het voor iedereen duidelijk is hoe het staat met de voortgang van het project. Gedurende het project hebben we ook in grote mate verwachtingsmanagement toegepast, iets wat Tenuki erg belangrijk acht. Zo hebben we een zeer duidelijk concept product ontwikkeld in PowerPoint. Dit resulteerde in vroege feedback en geen (grote) verrassingen. De opdrachtgever wist wat hij kon verwachten en wij wisten waar we naar toe moesten werken. Het staat vast dat we veel van de principes die we hier geleerd hebben vaker zullen toepassen. Sterker nog: we merken dat we de principes nu al toe passen bij andere kleine projecten en tentamens.

42

Sectie 7: Aanbevelingen In deze sectie zullen we omschrijven wat er volgens ons verbeterd zou kunnen worden aan de applicatie. Ook ideeën voor waardevolle toevoegingen zijn genoemd. Constante datastroom uit de ruwe database De update-applicatie voor Erika maakt gebruik van de fileberichten uit de ruwe database. Zodra deze datastroom niet meer wordt bijgewerkt kan Erika geen juiste informatie tonen. Momenteel gebeurt het regelmatig (de datastroom houdt het ongeveer 2 dagen vol) dat de datastroom stopt met bijwerken, waarna deze weer opnieuw gestart moet worden. Wij raden daarom aan om deze datastroom stabieler te maken. Toevoegen van de overige landen Momenteel draait de applicatie alleen met de landen Nederland, België, Italië, Oostenrijk en Zwitserland. Bij Tenuki is ook file-informatie beschikbaar van de landen Spanje, Finland en Zweden. Het zou dus een leuke toevoeging zijn om ook deze landen aan de applicatie toe te voegen. Spanje is in principe al toegevoegd, maar de ruwe datastroom (WAYFINDER_ES) heeft geen VERSION_TIME bij fileberichten. Om alle slides van Erika te kunnen weergeven is het belangrijk dat het EXPIRED veld en het VERSION_TIME veld correct zijn ingevuld. Daarnaast moet de RAW_XML voldoende informatie bevatten om voor onze applicatie nuttig te zijn. (Dit houdt in: of twee TMC-locatiecodes, of één locatienaam, of een filelengte). Incomplete file-informatie De file-informatie van Spanje staat wel al in de historische database echter zijn de tijd velden (VERSION_TIME en EXPIRED_TIME) van deze berichten incorrect. Hierdoor is het nog niet mogelijk om deze informatie in onze applicatie te gebruiken. Ook de file-informatie van Italië is niet optimaal. Bij Italië wordt het EXPIRED-veld van dit land niet bijgewerkt waardoor het actuele verkeersbeeld niet te bepalen is. Uitbreiden van configuratiemogelijkheden Er zijn momenteel een aantal instellingen voor slides die nog niet uit een extern bestand gehaald worden. Dit zijn instellingen over kleuren en tijdsintervallen voor de slides. In de huidige situatie moeten deze instellingen worden meegecompileerd. Door deze uit een extern bestand te halen krijgt de gebruiker meer configuratiemogelijkheden. Hierbij zou gebruik kunnen worden gemaakt van de configuratie mogelijkheden die de library van Tenuki bevat. Informatiebox van een kaartweergave Momenteel worden de vijf langste files van een kaartweergave in de informatiebox getoond. Hierbij wordt er nog geen rekening mee gehouden of deze file zich achter de box bevindt. Hierdoor kan het voorkomen dat een file wordt geselecteerd die zich volledig achter de box bevindt. Door deze files niet in de informatiebox weer te geven wordt voorkomen dat er een file wordt geselecteerd die niet getoond kan worden. Gebruiken maken van andere soorten verkeersberichten De historische database bevat naast fileberichten ook informatie over wegwerkzaamheden. Voor een land als Spanje, waar veel wegwerkzaamheden zijn, zou het interessant zijn om ook deze informatie aan de weergaves toe te voegen.

43

Ook is er voor file-informatie bekend of het om stilstaand verkeer of langzaam rijdend verkeer gaat. Het zou een leuke toevoeging zijn om een file rood te kleuren als het om stilstaand verkeer gaat en oranje te kleuren als het om langzaam rijdend verkeer gaat. Dit zou aan de hand van de ‘’ (deze code bevindt zich in de historische database) kunnen worden bepaald. Weergaveduur van de slides De weergaveduur van een slide wordt bepaald in het configuratiebestand van de afspeellijst. Deze duur is statisch. Dat wil zeggen dat er geen rekening mee wordt gehouden hoeveel informatie er wordt getoond op de kaart. Als er op een bepaald moment geen files zijn, wordt de slide even lang laten zien als bijvoorbeeld tijdens de spits. Voor de gebruiker zou het prettiger zijn de tijdsduur af te laten hangen van de hoeveelheid data. Voor een kaartslide met een informatiebox zou dit bijvoorbeeld betekenen dat naast de standaard 5 seconden voor het weergeven van een lege kaart, de slide 5 seconden de tijd krijgt voor iedere file die hij langsloopt. Als er maar 2 files staan, wordt de slide dan 15 seconden weergegeven en als er 5 files staan, wordt de slide 5 * 5 = 25 + 5 = 30 seconden laten zien. Dit kan geïmplementeerd worden door de superklasse TView een methode te geven die aangeeft of de slide langer/korter weergegeven moet worden (eventueel hoeveel langer/korter). Na de PrepareData() weet een slide namelijk al hoeveel files hij gaat weergeven. Het slideshowtimer interval kan vervolgens aangepast worden met de extra tijd. Files op circulerende wegen Bij circulerende wegen (wegen waarvan het begin- en eindpunt gelijk is,) is een extra stap vereist om te bepalen waar de file getekend moet worden. In figuur x is het dilemma geïllustreerd waar het programma mee te maken heeft. Het linker kruisje is het eindpunt (kop) van de file en het rechterkruisje is het beginpunt (staart) van de file. Het programma moet nu de richting van de file kunnen bepalen (tegen de klok in of met de klok mee). We gaan er van uit dat dit uit het filebericht gehaald kan worden middels het rdsDirection veld. Daarnaast is er voor onze tekenfunctie een extra stap vereist. Die moet namelijk door het begin-/eindpunt van de weg kunnen tekenen. Er is al code toegevoegd aan de tekenfunctie waarmee dat mogelijk is. De richting wordt echter nog niet correct uit een filebericht gehaald.

Figuur 16: Een circulerende weg met een file waarvan het begin- en eindpunt bekend is. Zonder extra informatie is niet te bepalen welke pijl de file moet volgen.

44

Memory leaks In de applicatie lijkt een kleine memory leak te zitten. Dit concluderen we uit het feit dat de Windows Task Manager aangeeft dat de applicatie steeds meer geheugen gebruikt. Echter, na een dag of vier wordt het geheugengebruik ineens weer terug gebracht naar een lagere waarde. Wij zijn er nog niet achter gekomen waarom het geheugen gebruik oploopt en waarom hij ineens een lagere waarde krijgt. FastMM4 geeft geen meldingen over memory leaks. Tekenapplicatie van wegen De losse applicatie gemaakt voor het tekenen van wegen is momenteel erg simpel. Op dit moment kan er met deze applicatie alleen nog maar wegen worden getekend. Er ontstaat vervolgens een stuk code die handmatig naar een XML-bestand gekopieerd moet worden. Naast het toevoegen van wegen moet het verwijderen van wegen ook handmatig gebeuren. Als er tijdens het tekenen van een weg een fout wordt gemaakt moet de hele weg verwijderd worden om vervolgens de weg weer opnieuw te tekenen. Dit zijn allemaal punten die geautomatiseerd kunnen worden. Hierdoor zal de applicatie een stuk makkelijk in gebruik zijn.

45

Referenties [1]

Ken Schwaber, SCRUM Development Process http://www.jeffsutherland.com/oopsla/schwapub.pdf

[2]

Lischner, Ray. 2000. Delphi in a nutshell, A Desktop Quick Reference. O’Reilly & Associates, Sebastopol.

[3]

Delphi Basics - Documentatie http://www.delphibasics.co.uk

[4]

InterBase Express Reference (Delphi library)

[5]

Delphi Help bij Borland Delphi Professional 7

[6]

MapServer 4 Documentatie

[7]

Welkom op de website van EuroTraffic http://www.eurotraffic.org Bezocht op 9 juli 2009

46

Bijlage A: Onderzoeksverslag

Grafische weergave van verkeersproblemen Onderzoeksverslag

1291971 - Gert-Jan Deen 1258931 - Michel de Ridder 1263196 - Maarten Somhorst Technische Universiteit Delft, Faculteit Elektrotechniek, Wiskunde en Informatica

47

Inhoudsopgave 1.

Inleiding ......................................................................................................................................... 49

2.

Werkwijze ...................................................................................................................................... 49

3.

4.

5.

6.

2.1

Tenuki’s algemene aanpak .................................................................................................... 49

2.2

Agile programming ................................................................................................................ 50

2.3

Agile programming: SCRUM .................................................................................................. 51

2.4

Tenuki’s toepassing van SCRUM ........................................................................................... 53

Programmeren .............................................................................................................................. 54 3.1

Java vs. Delphi ....................................................................................................................... 54

3.2

Design patterns ..................................................................................................................... 57

3.3

Programmeerstijl ................................................................................................................... 57

Verkeersinformatie........................................................................................................................ 58 4.1

Definitie van file .................................................................................................................... 58

4.2

Typen files.............................................................................................................................. 59

4.3

Hoe worden de files waargenomen ...................................................................................... 59

Kaartrendertechnieken ................................................................................................................. 59 5.1

Verschillen tussen raster- en vectorkaarten ......................................................................... 60

5.2

Tenuki’s ervaringen met kaartrender-technieken ................................................................ 61

Kaartengine keuze ......................................................................................................................... 61 6.1

Op zoek naar de geschikte engine......................................................................................... 61

6.2

MapServer ............................................................................................................................. 62

6.3

Google Maps.......................................................................................................................... 62

6.4

TatukGIS ................................................................................................................................ 63

6.5

Voorstel ................................................................................................................................. 63

Referenties ............................................................................................................................................ 65 Bijlage I: Keuze kaartengine .................................................................................................................. 66 Vragen ............................................................................................................................................... 66 Antwoorden....................................................................................................................................... 66

48

1. Inleiding Bij het starten van een nieuw project is vooronderzoek vaak van groot belang, omdat niet alle kennis direct beschikbaar of toepasbaar is. Het project betreft het grafisch weergeven van de verkeersproblemen. Omdat we bij Tenuki gebruik zullen gaan maken van de voor ons nieuwe taal Delphi voelen we ons genoodzaakt om kennis te verwerven over deze programmeertaal. Ook zullen we bij Tenuki gebruik gaan maken van de werkwijze die ze bij Tenuki gebruiken. Om deze zo goed mogelijk te kunnen toepassen gaan we deze onderzoeken. Naast de programmeertaal en de werkwijze is het ook belangrijk om goed te begrijpen wat de verkeersinformatie precies inhoud en hoe we dit het beste kunnen weergaven. Dit gaan we tijdens ons onderzoek ook onderzoeken. Om deze verkeersinformatie uiteindelijk grafisch te weergeven zullen we gebruik gaan maken van een kaart engine. Om een goede engine te kunnen kiezen gaan we kaartrendertechnieken en een aantal verschillende kaart engines onderzoeken. In dit verslag laten we zien welke onderzoeken we hebben gedaan tijdens het project. Een groot gedeelte van de onderzoeken zal worden gedaan voordat we zijn begonnen met het ontwerp van de applicaties. In hoofdstuk 2 zullen we de werkwijze en ontwikkelmethode van Tenuki onderzoeken. In hoofdstuk 3 gaan we onderzoek doen naar de programmeermiddelen en methoden die we zullen gebruiken. In hoofdstuk 4 gaan we onderzoeken uit welke informatie verkeersinformatie bestaat. In hoofdstuk 5 gaan we kaartrendertechnieken onderzoeken en in hoofdstuk 6 gaan we een aantal verschillende kaart engines onderzoeken, waarna we hieruit een keuze maken.

2. Werkwijze Elk bedrijf heeft zo zijn eigen werkwijze. Tenuki maakt gebruik van de agile programming methode SCRUM. In dit hoofdstuk wordt eerst uitgelegd wat Tenuki’s algemene aanpak is. Vervolgens wordt Agile programming en SCRUM uitgelegd, waarna wordt uitgelegd hoe Tenuki deze toepast.

2.1

Tenuki’s algemene aanpak

Een goede Tenuki-medewerker volgt de volgende stappen voor ieder project/taak: 1. 2. 3. 4.

Overeenstemming bereiken over WAT je gaat doen Plan met opdrachtgever afstemmen over HOE je dat gaat bereiken Op tijd melden als er blokkeringen zijn, de verwachtingen op elkaar afstemmen Draag het over aan de opdrachtgever, waarbij duidelijk moet zijn wat er af is en waar het te vinden is

Een belangrijk principe binnen Tenuki is verwachtingsmanagement. Het idee is dat je de verwachting van je opdrachtgever moet managen. Bij elk van deze stappen wordt met behulp van terugkoppeling gecontroleerd of de opdrachtgever en opdrachtnemer dezelfde verwachting hebben. Waar je verder aan kunt denken is het vroegtijdig laten zien van prototypen. Dit maakt dat de opdrachtgever in een vroeg stadium feedback kan leveren, zodat wijzigingen nog makkelijk gemaakt kunnen worden en de klant uiteindelijk een resultaat in handen krijgt waar zij tevreden mee is. Dit komt heel duidelijk terug in de SCRUM-methodiek die verderop in dit hoofdstuk wordt uitgelegd.

49

2.2

Agile programming

Agile software development bestaat uit een groep ontwikkelingsmethoden die gebaseerd is op vergelijkbare principes. In 2001 zijn deze principes opgesteld in een zogenoemd ‘Agile Manifesto’ door 17 mensen die verschillende nieuwe ontwikkelmethoden representeerden. Onder andere Ken Schwaber en Jeff Sutherland, de bedenkers van de SCRUM methode, hebben meegewerkt aan het opstellen van de Agile Manifesto. Als we kijken naar een ander model dan zien we dat bijvoorbeeld het ‘waterfall’ model gericht is op een gestructureerde methode. Het nadeel van dit model is dat alles van te voren wordt gepland, waardoor het moeilijk is om op veranderingen te reageren. De agile methode gaat hier flexibeler mee om. Bij het Agile model wordt om de paar weken een klein stukje werkende en geteste code geproduceerd. Gedurende het gehele project worden er steeds kleine stukjes werkende code bijgewerkt of toegevoegd. Hierbij kan rekening worden gehouden met eventuele tussentijdse veranderingen. De volgende waarden werden opgesteld [3]: 



 

Individuen en interacties boven processen en gereedschappen Het is beter de nadruk te leggen op de gebruikers van de software. Zo is het beter om software te hebben waar de gebruikers goed mee overweg kunnen in plaats van dat er uitgebreide maar lastige tools worden gebruikt. Werkende software boven begrijpelijke documentatie Het is belangrijker dat de software doet wat de opdrachtgever wil in plaats van dat de software niks doet maar er hele uitgebreide documentatie van beschikbaar is. Door de principes uit Agile Manifesto aan te houden blijft de software onderhoudbaar. Samenwerking met de klant boven contractonderhandelingen Dit voorkomt ook dat er bij eventuele vertragingen gelijk naar het contract worden verwezen. Reageren op verandering boven het volgen van een plan Zorg voor een open relatie met de klant. Sta open voor plotselinge nieuwe functionaliteit van de opdrachtgever. Dit gaat echter wel gepaard met dat er eventuele minder belangrijke functionaliteit verdwijnt.

De belangrijkste principes uit Agile Manifesto [3]:      

De hoogste prioriteit is om de klant tevreden te stellen middels een vroegtijdige en doorlopende oplevering van waardevolle software Verwelkom veranderende eisen, zelfs laat in de ontwikkeling. Agile processen bevatten verandering voor het concurrentievoordeel van de klant Lever werkende software veelvuldig op, elke paar weken tot paar maanden, met een voorkeur voor kortere tijdsintervallen Zakenmensen en ontwikkelaars werken dagelijks samen tijdens de gehele loop van het project Bouw projecten middels gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en het vertrouwen dat zij de klus klaren De meest efficiënte en effectieve methode om informatie over te brengen binnen en aan een ontwikkelteam is middels face-to-face communicatie 50

   

Werkende software is de primaire maat van vooruitgang Continue aandacht voor technische correctheid en goede ontwerpen Eenvoud Op vaste tijden reflecteert het team op aspecten die effectiever kunnen en verandert de aanpak van deze aspecten zodanig.

2.3

Agile programming: SCRUM

In 1995 hebben Jeff Sutherland en Ken Schwaber een paper gepresenteerd over een ontwikkelwerkwijze genaamd SCRUM. De volgende korte toelichting van SCRUM komt grotendeels uit het paper van Schwaber. [1] Een sleutel principe van SCRUM is de erkenning dat tijdens een project klanten hun mening veranderen over wat ze willen en nodig hebben en dat onvoorziene uitdagingen niet makkelijk opgelost kunnen worden in een traditionele planning. Daarom gebruikt SCRUM een empirische aanpak, namelijk het accepteren dat het probleem niet volledig begrepen of gedefinieerd kan worden en in plaats daarvan concentreren op het maximaliseren van de mogelijkheden van het team om snel iets te leveren en te reageren op opkomende requirements. [2] Ontwikkelingsfasen SCRUM definieert 3 fasen in de ontwikkeling van een product. [1] 1. Pregame  Planning: Creëer een backlog, dit is een high-level document voor het gehele project met alle vereiste functionaliteiten. Definitie van een nieuwe release is gebaseerd op de huidige backlog, samen met een schatting van de tijd en kosten. Wanneer een nieuw systeem wordt ontwikkeld, bestaat deze fase uit zowel conceptualisering als analyse.  Architectuur: Ontwerp hoe de backlog items geïmplementeerd zullen worden. Deze fase bestaat voornamelijk uit high level design en het creëren/ aanpassen van de systeem architectuur 2. Game  Sprints: Ontwikkeling van de nieuwe release functionaliteit, continu onderhevig aan de variabelen van tijd, eisen, kwaliteit, kosten en concurrentie. 3. Postgame  Closure: Product gereedmaken voor release, inclusief complete documentatie. Vergaderingen Er zijn vier typen vergaderingen: Daily SCRUM: Elke dag tijdens de sprintfase is er een (korte) vergadering over de project status. Deze vergadering heeft specifieke richtlijnen, de belangrijkste zijn:  De vergadering is elke dag om dezelfde tijd en dezelfde locatie en start precies op tijd  De vergadering duurt 15-20 minuten  Alle deelnemers staan (houdt de vergaderingen kort)

51

Tijdens de vergadering worden aan elke teamgenoot drie vragen gesteld:   

Wat heb je gisteren bereikt? Wat wil je vandaag bereiken? Zijn er problemen die het bereiken van je doel belemmeren?

Sprint Planning Meeting: Op het begin van een sprint wordt de Sprint Planning Meeting gehouden. Hierin wordt geselecteerd wat er gedaan gaat worden (items geselecteerd vanuit de product backlog in de sprint backlog). Vervolgens wordt er geschat hoeveel tijd er nodig is per item en gekeken wat af te krijgen is gedurende de sprint. De vergadering mag maximaal acht uur duren. Sprint Review Meeting: Aan het eind van een sprint worden twee vergadering gehouden, waaronder de “Sprint Review Meeting”. Op de Sprint Review Meeting worden alle items van de sprint backlog gereviewed, zowel items die afgerond zijn als items die nog niet afgerond zijn. De items die af zijn worden gepresenteerd aan de opdrachtgever/gebruikers. De vergadering mag maximaal vier uur duren. Sprint Retrospective: Ook wordt er aan het einde van een sprint een “ Sprint Retrospective Meeting” gehouden. Tijdens deze meeting reflecteren alle teamgenoten op de afgelopen sprint. De basisvragen die gesteld worden tijdens zo een reflectie zijn:  Wat ging er goed tijdens de sprint?  Wat kan er verbeterd worden in de volgende sprint? Het hele SCRUM proces kan in het schema uit figuur 17 worden weergegeven:

Figuur 17: SCRUM proces

52

2.4

Tenuki’s toepassing van SCRUM

In deze paragraaf geven we een beschrijving hoe Tenuki de hiervoor genoemde technieken toepast. Principes De belangrijkste principes van Tenuki, die afstammen uit Agile ontwikkelmethoden, zijn:  Resultaten benoemen en zichtbaar maken in de context van de opdrachtgever Het resultaat moet begrijpbaar zijn voor de opdrachtgever. Zo weet de opdrachtgever wat hij kan verwachten en kan hij het resultaat controleren  Doe het belangrijkste eerst Richt de opdracht op wat volgens de opdrachtgever het belangrijkste is. Meestal heb je meer tijd nodig dan van te voren gepland. Door het belangrijkste eerst te doen, zitten de voor de opdrachtgever belangrijkste punten er in ieder geval in. Ook krijg je eerder feedback voor de belangrijke taken welke je vervolgens kan bijwerken.  Doe niet meer dan nodig Op eventuele toekomstige doelen ga je niet in. Zo hoeft er geen rekening te worden gehouden dat er in de toekomst misschien nieuwe functies worden toegevoegd. Door de manier van programmeren kunnen deze later worden verwerkt. Eenvoud Kies als insteek simpel en niet makkelijk. Dus een eenvoudig, goed te begrijpen oplossing in plaats van een oplossing die voor nu het minste tijd/moeite kost. Hierdoor wordt de software niet complexer dan nodig is en is het beter te onderhouden  Verwelkom veranderende eisen (embrace change) Het uiteindelijke doel is om de opdrachtgever tevreden te stellen, niet om zo goed mogelijk te voldoen aan de oorspronkelijk gedefinieerde opdracht. Door de opdrachtgever nauw bij de opdracht te betrekken en open te staan voor tussentijdse veranderingen creëer je een open relatie met de opdrachtgever. Dit zorgt ervoor dat de verwachtingen met elkaar overeenkomen en dat de opdrachtgever tevreden kan zijn. Fasen Wat betreft verschillende fasen in de ontwikkeling, identificeert Tenuki net als de SCRUM methode een pre-game. Echter volgt hier geen volledige planning en volledig ontwerp uit (zoals in bijvoorbeeld het waterval proces). Er zijn wel specifieke taken in het begin, zoals bijvoorbeeld de architectuur ontwerpen. In de beginfase wordt geen gedetailleerd designdocument opgesteld voor de gehele applicatie, maar een globaal ontwerp. Gedurende de sprints worden kleine stukken code zoals een module ontworpen, geïmplementeerd en getest. Er wordt met een combinatie van incrementeel programmeren en evolutionair programmeren uit Agile gewerkt. Waarbij in de begin fase meer incrementeel wordt gewerkt, door het toevoegen van nieuwe features. In een latere fase wordt er meer evolutionair gewerkt, door bepaalde functies uit te breiden of te verbeteren. Planning De planninggame uit Extreme Programming wordt toegepast. In deze planninggame worden drie verschillende knoppen gedefinieerd waaraan ‘gedraaid’ kan worden.  Tijd en geld (resources)  Functionaliteit

53

De projectplanning kan middels deze ‘knoppen’ getuned worden. Echter, voor elke sprint is de planning strikt. Dat wil zeggen dat het duidelijk is wat er gedaan moet worden gedurende de sprint en dat de sprintduur vast staat (twee weken in het geval van Tenuki). Een product is pas echt af wanneer de opdrachtgever het resultaat als zodanig heeft beoordeeld (bij Tenuki noemen ze dit ‘af-af’). Toepassing Elke dag beginnen we met een Daily SCRUM, de zogenaamde QQQ (Question, Question, Question). Omdat we op deze manier elke dag moeten aangeven wat we hebben bereikt, gaan bereiken en wat ons belemmert, is het makkelijker tijdig te alarmeren (verwachtingsmanagement, punt 3 Tenuki stappenplan). Het product backlog word zo vroeg mogelijk opgesteld. Later kunnen nog nieuwe items worden toegevoegd. Elke twee weken definiëren we vanuit de product backlog een sprint voor de komende twee weken. Hierbij worden de punten met de hoogste prioriteit geselecteerd. Aan het eind van een sprint wordt een Sprint Review meeting gehouden. Hierin reviewen we wat we hebben bereikt in de sprint, en wat niet. Deze resultaten worden gepresenteerd in de context van de opdrachtgever. Het 4-stappenplan van Tenuki is er voor bedoeld om gestructureerd projecten en taken uit te voeren. Het zorgt dat beide partijen (opdrachtgever en uitvoerder) op één lijn zitten, zodat de opdracht efficiënt uitgevoerd kan worden. Men past het niet toe op bijvoorbeeld ieder item in de product backlog, maar voor niet-triviale items op deze backlog kan het verstandig zijn om het ‘4-stappenplan’ te volgen. Ook op andere niveaus kun je het 4-stappenplan toepassen, bijvoorbeeld op het niveau van een heel project.

3. Programmeren Een aantal belangrijke eisen waar tijdens het programmeren rekening mee gehouden moet worden zijn: onderhoudbaarheid en werkende code. Bij Tenuki wordt de nadruk op onderhoudbaarheid gelegd. Door de code goed onderhoudbaar te maken, is het voor de mensen die de code later eventueel willen gebruiken of aanpassen een stuk makkelijk deze te begrijpen. Om er voor te zorgen dat onze code onderhoudbaar wordt, gebruiken we de technieken en principes beschreven in paragraaf 3.3. Als voorbereiding voor het programmeren, hebben we eerst onderzoek gedaan naar de verschillen tussen Delphi en Java. Verder hebben we onderzocht of Tenuki bepaalde structuren gebruikt en welke stijl ze tijdens het programmeren aanhouden.

3.1

Java vs. Delphi

Tot op heden hebben we allemaal nog geen ervaring met Delphi. Om deze reden gaan we eerst onderzoeken wat de belangrijkste verschillen zijn tussen Java en Delphi. We hebben Java gekozen omdat dit een taal is waar we allemaal ervaring mee hebben. Object-Oriented Programming Object georiënteerd programmeren is gebaseerd op het principe dat er een systeem wordt gemaakt bestaand uit objecten, waarbij elk object gemaakt is vanuit de definitie van een klasse. Zowel Java als

54

Delphi zijn object georiënteerde talen. Dit betekent echter niet dat beide talen precies dezelfde benadering hebben van OOP. Belangrijke technieken die bij OOP gebruikt worden zijn: overerving / polymorfisme en inkapseling. Deze begrippen zullen we nader toelichten. Inkapseling Om de toegang van code te regelen gebruiken beide talen de keywords public, private en protected. Delphi heeft één relevant extra keyword, namelijk published. In tegenstelling tot Java is er in Delphi geen toegangsniveau gespecificeerd voor een package. Waar protected in Java de package members ook toegang biedt, is het in Delphi alleen toegankelijk voor de unit (het bestand) zelf en overerfde klassen. Om in Delphi hetzelfde effect te krijgen moet je de package klassen in dezelfde unit definiëren. Het verschil is dat deze klassen dan ook toegang hebben tot de private(!) delen van die klasse. Het enige verschil tussen public en published is dat een published declaratie de compiler vertelt om Runtime Type Information op te slaan in de Virtual Method Table. Elke klasse heeft een unieke Virtual Method Table. Meestal wordt de base class TPersistent gebruikt voor de klassen die published declarations nodig hebben. Overerving / Polymorfisme Zowel in Java als in Delphi heeft een klasse maximaal één base class. Wel kunnen voor klassen in zowel Java als Delphi meerdere interfaces geïmplementeerd worden. Bij beide talen is het mogelijk gebruik te maken van ‘Late binding’. Dit houdt in dat in de hoofdklasse de methode wordt gedefinieerd en dat de implementatie in de subklasse wordt uitgewerkt. In Java kan een methode standaard ‘ge-override’ worden. In Delphi kan dit standaard niet en moet de methode eerst als ‘virtual’ of ‘dynamic’ benoemd worden voordat deze de andere methode kan overriden. Garbage Collector Een garbage collector is een soort verzamelaar die alle vuilnis (objecten in het geheugen die geen referenties meer hebben) opruimt. Deze verzamelaar beheert het geheugen en zorgt er voor dat het niet onnodig vol komt te zitten. De Java Virtual Machine bevat een eigen garbage collector die constant op de achtergrond draait. Omdat je geen directe controle hebt over het geheugengebruik, kan dit nadelige gevolgen hebben voor de prestatie van toepassingen. Delphi heeft geen eigen garbage collector en dus moet de programmeur zijn eigen objecten opruimen. Dit kan eenvoudig gedaan worden via destructors. In het geval van interfaces, strings en dynamic arrays kan gebruik worden gemaakt van reference counting. De compiler houdt bij wanneer interface references, string en dynamische arrays worden aangemaakt, en wanneer ze buiten bereik (scope) raken. Exceptie-afhandeling Exceptie-afhandeling is het op een simpele manier fouten afhandelen van een stuk code van een programma met als doel een programma meer robuust te maken. Java en Delphi maken beide gebruik van het ‘try-catch-principe’ (bij Delphi wordt deze ‘try’ en ‘except’ genoemd). Dit houdt in dat er een stuk code wordt geprobeerd uit te voeren (‘try’). Indien dit fout gaat wordt de exceptie opgevangen door de ‘catch’, zodat hier de fout afgehandeld kan worden. Omdat bij Delphi objecten niet automatisch uit het geheugen worden verwijderd, is het belangrijk om een niet-gebruikt object weer op te ruimen, bijvoorbeeld in een finally Block. Zo voorkomt men memory leaks.

55

Platform onafhankelijkheid Een taal is meer platform onafhankelijk als de taal of toepassing werkt op een groter aantal systeemplatformen, zoals Linux en Windows. De Java compiler vertaalt de Java broncode naar binaire code en vervolgens voert de Java Virtual Machine deze code uit. Omdat er voor de meeste platformen een Java Virtual Machine is kunnen deze bestanden op meerdere platformen worden uitgevoerd. Ook de taal Delphi draait op meerdere platformen. De ene versie ondersteunt meerdere platformen dan de andere. Zo maken ze bij Tenuki gebruik van Delphi 7 omdat deze ook onder Linux draait. Bestand structuur Beide talen hebben een andere opbouw van de structuur van de code. Zo bestaat een Java-bestand uit een klasse waarin verschillende functies worden gedefinieerd. Een Delphi-bestand (unit) bestaat eigenlijk uit twee delen: de interface en de implementatie. In het interfacegedeelte wordt de klasse gedefinieerd met de methoden en in het implementatiegedeelte staat de implementatie van de in de interface genoemde methoden. Doorgeven van parameters Bij methoden is het mogelijk om parameters mee te geven. In Java is het mogelijk allerlei soorten data mee te geven aan een methode. Bij Delphi kan er worden gekozen uit vier verschillende typen parameters: Variabele: Een variabele parameter geeft alleen de referentie door en mag tussendoor worden gewijzigd. ( Input / output ) Out: Een out parameter werkt hetzelfde als een variabele parameter, het resultaat van deze parameter kan worden opgevraagd. ( Output ) Constante: Een constante parameter is binnen de functie constant en kan niet van waarde worden veranderd. Waarde: Een waarde parameter geeft alleen de waarde door. ( Input ) Een duidelijk verschil tussen Java en Delphi is dat je bij Java alleen hoeft aan te geven wat voor soort parameter het is (String, Integer, etc..), terwijl er bij Delphi rekening mee kan worden gehouden wat er met de parameter gebeurt en hoe je de parameter wilt teruggeven. Overzicht In tabel 1 is een overzicht te vinden van de hierboven genoemde belangrijkste verschillen tussen Java en Delphi. Java

Delphi

Object-Oriented Programming

“Pure” OOP

“Hybrid” OOP

inkapsellering

public, private, protected

public, private, protected ( published, automated )

overerving / Polymorfisme

final en override

virtual / dynamic en override

bevat Garbage Collector

ja

nee

exceptie-afhandeling

‘try’ en ‘catch’

‘try’, ‘except’ en ‘finally’

platform onafhankelijk

ja ( uitgebreid )

ja ( Windows / Linux )

bestand structuur

methoden

worden

gelijk interface / implementatie 56

geschreven type parameters

niet op te geven

var, out, const en value

Tabel 1: Overzicht eigenschappen Java en Delphi

3.2

Design patterns

Het idee van een design pattern (ontwerppatroon) is dat programmeurs op hoog niveau met elkaar kunnen praten over de technische implementatie van een applicatie. Het is een soort uitbreiding van het jargon. Een pattern die op Tenuki toegepast wordt is de Converter pattern, welke binnen Tenuki ontwikkeld is. Een toepassing van dit patroon zou een groep klassen kunnen zijn waarbij eentje relevante informatie bevat en de anderen deze informatie kunnen omzetten (convert) naar een ander formaat. Zo kun je een converter hebben die informatie omzet in een XML-formaat en een andere converter die de informatie omzet naar een Excel-sheet. Het voordeel is dat je de informatie gescheiden hebt van de 'omzet-logica'. De ervaring van Tenuki is dat het loont om in gesprek te zijn over de design patterns. Zodra iedereen op dezelfde manier kijkt naar de betekenis van zo'n pattern is het makkelijker communiceren.

3.3

Programmeerstijl

Om onderhoudbare code te produceren wordt er bij Tenuki aan de hand van code conventies gewerkt. Voor het gebruik van de juiste naamgeving is er een aantal regels die worden gehanteerd. Omdat wij de komende twee maanden volgens de Tenuki werkwijze gaan werken, hebben wij deze code conventies onderzocht zodat wij deze ook kunnen toepassen. Naamgeving van objecten De prefix (het begin van de objectnaam) wordt bepaald aan de hand van het objecttype. Zo bestaat de naamgeving uit een afkorting voor het objecttype, gevolgd door de functie van het object. Echter kunnen er voor meerdere typen object dezelfde naamgeving bestaan. Zo wordt er bijvoorbeeld voor TCheckBox en TDBCheckBox dezelfde afkorting gebruikt. In tabel 2 staan twee voorbeelden voor de naamgeving, namelijk van een button en een checkbox. afk.

staat voor

object-type

voorbeeldnaam

voorbeeld

but

toolbar-button

TToolButton

butClose

toolbutton om te sluiten

chk

checkbox

TCheckBox, TDBCheckBox

chkDebugInfo

checkbox of moet worden

debug-info

getoond

Tabel 2: Voorbeelden van object naamgeving

Overige code conventies Voor de naamgeving van variabelen, constanten en velden (fields) is er bepaald met wat voor letter(s) deze moet beginnen. Zo beginnen constanten bijvoorbeeld altijd met een kleine letter “c”. Ook zijn er voor de methodes, functies en procedures een aantal regels opgesteld. Zo moeten bijvoorbeeld alle methodes binnen een klasse alfabetisch geordend worden. Verder zijn er regels opgesteld voor de naamgeving van een unit en een form. Zo moeten bijvoorbeeld de projectbestanden de naam krijgen van de applicatie. De volledige lijst van code conventies staat op het intranet van Tenuki.

57

Loose Coupling Dit programmeerprincipe houdt in dat elke component zoveel mogelijk zelfstandig moet zijn. Uit deze richtlijn volgt beter onderhoudbare code en het is makkelijker om te testen. Elke component moet namelijk zelfstandig kunnen functioneren. Een bijkomend voordeel is dat het makkelijker is om code te herbruiken, omdat de componenten zelfstandig opereren. Test-Driven development Bij Tenuki wordt aan Test-driven development gedaan. Test-driven development kan samengevat worden met het volgende stappenplan: 1. Voeg een test toe 2. Run alle tests en kijk of de nieuwe test faalt 3. Implementeer de functionaliteit 4. Run de tests en kijk of ze slagen 5. Refactor code Deze manier van ontwikkelen heeft een aantal voordelen. Ten eerste verzekert deze methode dat er nagedacht wordt over de specificaties en het gebruik van de implementatie. Door het volgen van dit stappenplan garandeer je ook gelijk dat het programmeerprincipe loose coupling wordt gehanteerd, anders kunnen de testcases niet geschreven worden. Verder is het erg handig voor de SCRUM werkwijze, het aantal tests dat er slaagt kan gezien worden als een bereikt doel. Wanneer je vervolgens code moet herschrijven (omdat het gebruikte algoritme bijvoorbeeld te langzaam is) dan garanderen de test-cases dat de code blijft werken. Het voordeel van deze aanpak is ook dat de meeste defecten vroeg aan het licht zullen komen en de defecten zullen makkelijker te vinden en repareren zijn in het begin, dan wanneer het project erg omvangrijk is. Wanneer je bugs in je programma hebt, dan schrijf je voordat je de bugs gaat repareren tests die deze bug checken. Als je de bug dan gerepareerd hebt, wordt er ook gegarandeerd dat deze bug gerepareerd blijft in toekomstige versies.

4. Verkeersinformatie Verkeersinformatie is informatie over de toestand op de autosnelwegen. Deze informatie bestaat uit files, omleidingen en ongelukken.

4.1

Definitie van file

Er is geen algemene definitie voor file bekend. De definitie hangt af van in welke land het zich afspeelt en van welk bedrijf de informatie vandaan komt. Zo gebruikt TomTom een andere benaming voor file dan de Verkeersinformatie Dienst en zo wordt een file in Duitsland pas tot file gerekend als de politie dit zo heeft aangegeven. Om een beeld te kunnen geven van wat een file nu precies is, hebben we voor nu de informatie van de Verkeersinofrmatie Dienst gebruikt. De Verkeersinformatie Dienst zegt dat een file een verzamelbegrip is van drie soorten verkeer [8]:  

Langzaam rijdend verkeer: verkeer dat over tenminste twee kilometer nergens harder rijdt dan 50km, maar doorgaans wel sneller dan 25 km/u Stilstaand verkeer: verkeer dat over tenminste twee kilometer vrijwel overal minder dan 25 km/u rijdt.

58



Langzaam rijdend tot stilstaand verkeer: langzaam rijdend verkeer over veelal wat grotere lengte met hierin klonten stilstaand verkeer.

4.2

Typen files

Het ontstaan van files kan in drie groepen worden verdeeld: Vast knelpuntfile Deze file wordt veroorzaakt door een knelpunt dat continue aanwezig is. Een voorbeeld van een vast knelpuntfile is als er een rijstrook wordt afgesloten en er evenveel verkeer over minder stroken moet rijden. Tijdelijk knelpuntfile Deze file wordt veroorzaakt door een tijdelijk probleem op de weg. Een voorbeeld van een tijdelijk knelpuntfile is als er een ongeluk is gebeurd. Zowel op de baan waar het ongeluk is gebeurt als de baan ernaast, waar kijkers langzamer gaan rijden, kan een file ontstaan. Periodiek knelpuntfile Deze file wordt veroorzaakt als gedurende een kort moment gas moet worden afgenomen of zelfs moet worden geremd. Een voorbeeld van een periodiek knelpuntfile is een toestroom op een oprit. Doordat er veel verkeer de snelweg op gaat, moet het overige verkeer hier rekening mee houden door te vertragen.

4.3

Hoe worden de files waargenomen

Files worden op verschillende manieren waargenomen. Eén van deze manieren is door snelheidsmetingen en intensiteit metingen van lussen in de snelweg. Aan de hand van snelheidsmetingen alleen kan niet worden geconstateerd of er zich wel of geen verkeersproblemen voordoen. Zo zou het mogelijk zijn dat er iemand op de snelweg rijdt met een snelheid van 50 km/u. Dit betekent niet gelijk dat er hier een file staat. Door de snelheid te combineren met intensiteit metingen kan er een beter oordeel worden gedaan of er zich wel of geen verkeersproblemen voordoen. Het nadeel van deze methode is dat deze lussen duur in de aanschaf zijn en er een weg voor afgesloten moet worden om deze te plaatsen. Een andere methode om files te waarnemen is met behulp van radar en kenteken camera’s. Door over een bepaald traject de kentekens van auto’s te meten kan worden bepaald hoe snel de auto heeft gereden. Ook hierbij geldt dat de intensiteit ook moet worden gemeten om een zo goed mogelijk advies te geven. Een techniek in opkomst is de files meten met behulp van kastjes in de auto. TomTom voert dit principe al uit met hun HD Traffic systeem. Door de verplaatsing over een bepaalde tijd te meten en deze te combineren met andere verkeersinformatieservices, kan een goede inschatting worden gemaakt van de verkeersdrukte op de weg. In de toekomst zal dit systeem kunnen worden toegevoegd in de kastjes van het rekeningrijden.

5. Kaartrendertechnieken Om de verkeersinformatie uiteindelijk op een kaart weer te geven willen we eerst weten wat het verschil is tussen raster- en vectorkaarten. We zullen deze aan de hand van hun eigenschappen met 59

elkaar gaan vergelijken. Daarna gaan we kijken naar de ervaringen van Tenuki met kaartrendertechnieken.

5.1

Verschillen tussen raster- en vectorkaarten

‘Wat is het verschil tussen raster- en vectorkaarten?’ Om deze vraag te beantwoorden is het belangrijk om te beseffen wat het (gezamenlijk) doel is van de raster- en vectorkaarten. Dit is het grafisch weergeven van de werkelijke wereld. In deze paragraaf maken we een korte vergelijking tussen de twee categorieën kaarten, namelijk raster- en vectorkaarten. Rasterkaarten Een voorbeeld van een rasterkaart is een satellietfoto. Het raster bestaat uit rijen en kolommen. De cellen noemen we pixels en bevatten een enkele waarde. In het geval van een satellietfoto is deze waarde een kleur, bijvoorbeeld in de vorm van een RGB-code (Red, Green, Blue). Rasterkaarten bevatten geen ‘objecten’, maar enkel ‘velden’ (een verzameling pixels). Vectorkaarten Het gebruik van vectorrepresentaties in grafische informatie systemen (GIS) komt voort uit de gedachte dat alle geografische data kan worden omschreven door relaties tussen geometrische objecten. De basis geometrische objecten die geografische entiteiten kunnen representeren zijn punten, lijnen en polygonen. Daarom worden deze objecten onderscheiden in vectorrepresentaties.  Punten (nuldimensionaal) Hierin kunnen geografische kenmerken worden weergegeven die het best gerepresenteerd worden door een enkele punt zoals bijvoorbeeld de top van een berg. Punten bevatten het minste informatie van de drie basisobjecten. Punten kunnen ook gebruikt worden om gebieden weer te geven, bijvoorbeeld steden op een wereldkaart.  Lijnen (eendimensionaal) Lijnen kunnen worden gebruikt om wegen, bruggen, dijken, spoorlijnen, grenzen, etc. weer te geven.  Polygonen (tweedimensionaal) Geografische kenmerken zoals gebieden en bepaalde structuren kunnen het best met polygonen worden weergegeven. Al deze geometrische objecten worden verbonden met een rij in een database. Hierin kunnen allerlei soorten eigenschappen worden beschreven, zoals de lengte van een lijn of de kleur van een cirkel. Vergelijking Een voordeel van rasterkaarten is dat ze statisch zijn: het is een plaatje, dus het weergeven van zo’n kaart bestaat uit het weergeven van het plaatje. Bij een vectorkaart moet eerst de weergave berekend worden. Een nadeel van een rasterkaart is dat bij het inzoomen de pixels duidelijker zichtbaar worden. Dit geeft een onduidelijker beeld naarmate er verder wordt ingezoomd. Een vectorkaart, daarentegen is makkelijker te schalen, omdat elk object in termen van geometrische objecten is gedefinieerd. Een ander nadeel van de rasterkaart is dat er significant meer schijfruimte nodig is in vergelijking met vectorkaarten. 60

Een voordeel van vectorkaarten is dat ze makkelijk te updaten zijn. Het toevoegen van een stapel objecten is vaak genoeg. In het geval van een rasterkaart moet het complete plaatje vervangen worden. Het toekennen van eigenschappen van een object gaat makkelijker bij een vectorkaart. Een weg kan bijvoorbeeld zeer gemakkelijk geel gemaakt worden. Een rasterkaart kent geen objecten waar eigenschappen van kunnen worden gewijzigd, dus hier is dat een stuk lastiger. Opmerking Volgens Helen Couclelis [9] kan er geografisch gezien op twee manieren naar de wereld worden gekeken. De wereld kan bekeken worden als een wereld met ‘objecten’ of als een wereld met ‘velden’. Wanneer een GIS niet zowel raster als vectordata ondersteunt, moet er gekozen worden aan de hand van het doel van het systeem. Als de geografie die het systeem tracht weer te geven vanuit een object perspectief moeten worden bekeken, dan is het beter om vectorkaarten te gebruiken. Als het gaat om geometrische kenmerken van de wereld, zoals bijvoorbeeld landschappen, dan is het beter rasterkaarten te gebruiken.

5.2

Tenuki’s ervaringen met kaartrender-technieken

Tenuki heeft een handvol applicaties gemaakt waar men een kaart voor nodig heeft. Voorheen gebruikte ze daar Map24 voor. De Tenuki-applicaties stuurden objecten naar de Map24-server in Duitsland en kregen een kaart terug. Dit werkte uitstekend, totdat Map24 van de ene op de andere dag de API aanpaste: de applicaties werkten niet meer omdat ze niet de objecten verstuurden die Map24 verwachtte. Men heeft er voor gekozen om de implementatie niet aan te passen op de nieuwe situatie, maar men is overgestapt op de kaartengine van PTV, genaamd Mapserver. De hoofdredenen hiervoor zijn dat Tenuki al contact had met LocatieNet (die deze engine leverde) en dat Mapserver naast een webversie ook in een lokale versie te verkrijgen is. Vanaf nu kon Tenuki kaarten renderen zonder dat een internetverbinding noodzakelijk was. Tenuki heeft een kaart van de Benelux in bezit. Mapserver heeft de functionaliteit om objecten op te slaan in een Microsoft Access Database. Een nadeel hiervan is dat het laden van grote aantallen objecten te lang duurt. Echter voor een grote hoeveelheid data is de data wel overzichtelijker. Behalve dit nadeel zijn er geen problemen waar Tenuki tegenaan is gelopen tijdens het gebruik van deze engine.

6. Kaartengine keuze Om kaarten weer te geven in de applicaties is een kaartengine nodig. Deze geeft de mogelijkheid om een kaart op het scherm te tonen en daar objecten overheen te tekenen. Omdat de kaartengine een belangrijke schakel is voor onze applicatie, wordt hieronder een vergelijking gemaakt van verschillende engines en wordt een voorstel geformuleerd.

6.1

Op zoek naar de geschikte engine

Op zoek naar een kaartengine zijn we ons eerst gaan verdiepen in welke engines er beschikbaar zijn. Op het internet zijn veel kaartengines te vinden die elk zo zijn voordelen en nadelen hebben. Enkele voorbeelden van kaartengines zijn: Google Maps, Microsoft Virtual Earth, Yahoo Maps en MapServer. 61

Belangrijke punten waaraan onze kaartengine moet voldoen zijn: het hebben van een stabiele API, er goede documentatie beschikbaar is over de engine en de mogelijkheid om objecten te tekenen via de API. Op basis van deze punten hebben we onze keuze beperkt tot drie kaart engines, zodat we deze dieper konden onderzoeken. Omdat Tenuki bij een eerder project al gebruik heeft gemaakt van de engine MapServer leek het ons verstandig om in ieder geval deze engine verder te gaan onderzoeken. Daarnaast wilden we een engine onderzoeken die gebruik maakt van een online API. Het aanbod van online kaart engines was vrij uitgebreid. Onze keuze is gevallen op de engine van Google Maps, omdat er voor deze API in verhouding tot de anderen meer en betere documentatie te vinden was. Als derde engine kozen we een engine die net als MapServer onafhankelijk is van een internetverbinding of andere computers. Omdat we naast TatukGIS geen andere engines hadden gevonden was de keuze snel gemaakt. Elk van deze engines is onderzocht aan de hand van de criteria die aan het begin van bijlage I opgesomd staan. Het resultaat daarvan is te lezen in bijlage I. Van elke engine zullen we een korte beschrijving geven en zullen we de voor- en nadelen opsommen om bijlage I samen te vatten. In de laatste paragraaf zullen we een voorstel vormen.

6.2

MapServer

Deze engine bestaat uit een grote collectie van COM-objecten (Component Object Model). Via deze COM-objecten kan de engine in Delphi worden aangestuurd. De engine heeft momenteel de beschikking over een kaart van de Benelux waarvan verschillende MapViews (gedeeltes) kunnen worden gerenderd. Deze MapViews zijn de enige zichtbare objecten van de engine. Zo’n MapView kan uit verschillende lagen bestaan, waarbij elke laag zijn eigen speciale functies en geografische data toont. Tenuki heeft een soort van API voor deze engine gebouwd. Deze API zorgt voor een goede scheiding tussen wat er grafisch weergegeven moet worden en de data. Voordelen  Tenuki is bekend met deze engine.  GIS-data kan worden verborgen en kleuren kunnen aangepast worden.  Stabiele API (Tenuki heeft zelf invloed op het al dan niet veranderen van de API).  De engine kan snel een groot aantal objecten tekenen. Nadelen  Niet automatisch een actuele kaart beschikbaar.  Objecten moeten handmatig geschaald worden aan de hand van het zoomniveau.

6.3

Google Maps

Google geeft programmeurs de mogelijkheid om (gratis) hun product Google Maps te gebruiken voor websites. Dit kan hoofdzakelijk op twee manieren: statisch en middels AJAX. Met de eerste vraagt de programmeur middels een enkele URL aan een Google server welk deel van de kaart moet worden weergegeven en welke objecten daar op getekend moeten worden. De server geeft slechts een plaatje terug. Met de AJAX API kan de programmeur niet alleen de kaart weergeven, maar er ook mee navigeren en direct objecten tekenen en verwijderen. Dit alles zonder dat de webpagina opnieuw geladen wordt. 62

Deze webgeoriënteerde engine is in de desktopapplicatie te integreren middels een Delphi Web Component. Deze component werkt als een browser en kan de Google Maps engine dus laten zien. Voordelen  De kaart wordt automatisch geüpdate.  De API is makkelijk in gebruik.  Er zijn veel voorbeelden beschikbaar en er is een grote community die programmeert met deze API. Nadelen  Er bestaat een kans dat de API in de toekomst zo verandert dat de applicatie niet meer werkt.  De snelheid is beduidend slechter dan die van MapServer als er een groot aantal tekenobjecten aan de engine wordt toegevoegd.  De statische variant heeft een limiet van 1000 views per dag.  De road en city layer zijn afgeschermd.  Er is kennis nodig van JavaScript.  De rechten die Google claimt over de informatie zijn onwenselijk.

6.4

TatukGIS

De TatukGIS Developer Kernel geeft de programmeur de mogelijkheid om een GIS-applicatie te maken middels een engine. Deze engine is verkrijgbaar in de vorm van een Delphi VCL Library. Er is directe toegang tot de klassen in deze library. De engine kan o.a. gebruik maken van ArcView shape bestanden. Deze bestanden bevatten vectordata. Voor een kaart van bijvoorbeeld Polen worden verschillende lagen over elkaar heen geplakt, bijvoorbeeld een laag met steden en een laag met wegen. Ieder object is apart opvraagbaar middels die laag. Voordelen  Het is een ‘native’ Delphi engine en verhoogt dus het programmeergemak.  GIS-data kan worden verborgen en kleuren kunnen aangepast worden. Nadelen  Het heeft een prijskaartje. Vraagtekens  

Het is onduidelijk of er steeds een actuele kaart te verkrijgen is. Er is niet bekend hoe goed de engine presteert (bijvoorbeeld bij het tekenen van 10.000 objecten).

6.5

Voorstel

Hoewel we aan elke engine ongeveer evenveel tijd hebben besteed, is er in verhouding minder bekend over TatukGIS. We schatten relatief veel tijd kwijt te zijn om hier duidelijkheid over te krijgen.

63

Daarnaast laat de engine momenteel geen grote voordelen zien ten opzichte van de andere twee. Om deze redenen valt TatukGIS af en blijven Google Maps en MapServer over. De grootste bezwaren tegen Google Maps zijn de mogelijk veranderende API en de prestaties. Het lijkt er echter op dat de implementatie makkelijker is met Google Maps dan met MapServer, onder meer door de route-functionaliteit. MapServer heeft slechts twee nadelen (objecten schalen en actuele kaart). Daar staat tegenover dat de engine een stabiele API heeft en Tenuki al veel kennis heeft over de software. Onze voorkeur gaat uit naar MapServer. Dit geeft namelijk meer zekerheid in het implementatietraject (omdat we kunnen vertrouwen op de prestaties) en in het uiteindelijke gebruik van de applicatie (omdat we er op kunnen vertrouwen dat de API niet verandert). De Product Owner ging akkoord met dit voorstel, dus in onze applicatie is de MapServer engine in gebruik genomen.

64

Referenties [1]

Ken Schwaber, SCRUM Development Process http://www.jeffsutherland.com/oopsla/schwapub.pdf

[2]

SCRUM (softwareontwikkelmethode) http://nl.wikipedia.org/wiki/Scrum_(softwareontwikkelmethode) Geraadpleegd op 8 april 2009

[3]

The Agile Manifesto Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas http://agilemanifesto.org/principles.html http://hristov.com/andrey/fht-stuttgart/The_Agile_Manifesto_SDMagazine.pdf

[4]

Comparing OOP languages: Java, C++, Object Pascal http://www.marcocantu.com/papers/ooplang.htm Geraadpleegd op 14 april 2009

[5]

Comparing Object-Oriented Featuers of Delphi, C++, C# and JAVA http://www.derangedcoder.net/programming/general/comparingObjectOrientedFeatures.ht ml#objectsAndClasses Geraadpleegd op 14 april 2009

[6]

Delphi Basics - Documentatie http://www.delphibasics.co.uk Geraadpleegd op 15 april 2009

[7]

Delphi Help Geraadpleegd op 15 april 2009

[8]

Verkeersinformatiedienst http://www.verkeersinformatiedienst.nl/ Geraadpleegd op 15 april 2009

[9]

Helen Couclelis, People manipulate objects (but cultivate fields): Beyond the raster-vector debate in GIS, Springer Berlin / Heidelberg, Volume 639/1992, 1992

65

Bijlage I: Keuze kaartengine Vragen 1. 2. 3. 4. 5. 6.

7. 8. 9. 10. 11.

Kan ik uitgaan van een stabiele API? Via welke taal communiceer je met de engine? Hoe kun je aan een nieuwe versie van de kaart komen? Is er een kaart van West-Europa bijgeleverd met de volgende landen: Nederland, Italië, Spanje, België, Zweden, Zwitserland, Oostenrijk en Finland? Lokale of externe engine? (Extra verbinding nodig?) Hoe makkelijk is de engine in gebruik? a. Op welke manier kun je tekenen op de kaart en hoe makkelijk gaat dit? Bijvoorbeeld: Hoe teken je een lijn? Kan je incrementeel dingen toevoegen aan de kaart? Hoe makkelijk is het om files weer te geven (op de gegeven plaats)? Welk(e) coördinatenstelsel(s) ondersteunt de engine? Wat is de vraagprijs voor het gebruik van de engine? Wat zijn de voorwaarden voor gebruik van de engine?

Antwoorden MapServer Hieronder is een overzicht te vinden van alle antwoorden op de vragen van hierboven voor de kaartengine MapServer. Kan ik uitgaan van een stabiele API? Omdat de kaart en server files lokaal staan opgeslagen is MapServer een stabiele API. De API hoef daarom niet noodzakelijk te worden geüpdate bij het uitkomen van nieuwe versies. Via welke taal communiceer je met de engine? Er kan via COM objecten worden gecommuniceerd met deze engine. Hoe kun je aan een nieuwe versie van de kaart komen? De huidige kaart is afkomstig van LocatieNet, via LocatieNet zal waarschijnlijk een nieuwe kaart kunnen worden besteld. Is er een kaart van West-Europa bijgeleverd met de volgende landen: Nederland, Italië, Spanje, België, Zweden, Zwitserland, Oostenrijk en Finland? Op het moment is er bij Tenuki alleen een kaart van de Benelux beschikbaar. Hier moet dus een grotere kaart voor worden aangeschaft. Lokale of externe engine? (Extra verbinding nodig?) Het is een lokale engine waarvoor geen extra verbindingen nodig zijn. Hoe makkelijk is de engine in gebruik? Als je direct met de engine wilt gaan tekenen is dit vrij lastig uit te voeren. Door middel van de API die Tenuki voor deze engine heeft geschreven is dit een stuk eenvoudiger te doen. Er kunnen teken objecten worden aangemaakt welke via dmMapServer worden toegevoegd op de kaart.

66

Kan je incrementeel dingen toevoegen aan de kaart? Elk teken object heeft een eigen unieke ID. Door middel van dit ID nummer kunnen objecten worden verwijderd van de kaart. De dmMapServer houdt een lijst bij van alle teken objecten, zodra hier wijzigen in zijn gemaakt wordt de kaart geüpdate. Bestaande objecten blijven onveranderd, nieuwe objecten worden toegevoegd op de kaart en verwijderde objecten worden verwijderd. Er hoeft dus niet elke keer een hele nieuwe kaart te worden getekend. Hoe makkelijk is het om files weer te geven (op de gegeven plaats)? Het is me tot zover alleen nog maar gelukt een lijn te tekenen met behulp van bepaalde coördinaten. Je zou met behulp van een conversie van de binnenkomende coördinaten naar de map coördinaten files kunnen weergeven. Welke coördinatenstelsels ondersteunt de engine? Deze engine werkt met mercator coördinaten dit is vergelijkbaar met het x en y coördinatenstelsel. Wat is de vraagprijs voor het gebruik van de engine? Gratis, de engine is er al. Er moet alleen een nieuwe kaart worden aangeschaft. Wat zijn de voorwaarden voor gebruik van de engine? We hebben niets kunnen vinden over de voorwaarde van deze engine Google Maps Hieronder is een overzicht te vinden van alle antwoorden op de vragen van hierboven voor de kaartengine Google Maps. De Google Maps API bestaat uit twee varianten, de ene communiceert met behulp van Javascript (AJAX) en de andere communiceert met behulp van http requests (Static). Kan ik uitgaan van een stabiele API? Bij beide alternatieven werk je met een API die online geleverd wordt door Google. Als Google een non-backwards compatible verandering maakt aan de API, dan krijg je dit één maand van te voren te horen, gedurende deze maand zijn beide API beschikbaar. (Daarna moet je de oude functionaliteiten niet meer gebruiken) Via welke taal communiceer je met de engine? Google Maps AJAX Hier communiceer je via Javascript met de Google API. Google Static Maps Hier communiceer je via HTTP requests met de Google API. Hoe kun je aan een nieuwe versie van de kaart komen? Je gebruikt de kaart van Google. Hierin heb je dus niet veel keus. Wel kun je een eigen kaart projecteren in de Google engine. Is er een kaart van West-Europa bijgeleverd met de volgende landen: Nederland, Italië, Spanje, België, Zweden, Zwitserland, Oostenrijk en Finland? Voor beide alternatieven geldt dat deze aanwezig is Lokale of externe engine? (Extra verbinding nodig?)

67

Voor beide alternatieven geldt dat het een externe engine is waarbij een internetverbinding is vereist. Hoe makkelijk is de engine in gebruik? Google Maps AJAX Op welke manier kun je tekenen op de kaart en hoe makkelijk gaat dit? Bijvoorbeeld: Hoe teken je een lijn? Een lijn tekenen is erg makkelijk, er is een functie waarin je coördinaten, lijnkleur, lijndikte, etc definieert en de lijn verschijnt op de kaart. Hierbij hoeft de kaart niet opnieuw ingeladen te worden. De mogelijkheden van de engine zijn goed gedocumenteerd op de internetpagina van de google map API. De AJAX engine is veel uitgebreider dan de Static Maps engine. Google Static Maps Op welke manier kun je tekenen op de kaart en hoe makkelijk gaat dit? Bijvoorbeeld: Hoe teken je een lijn? Een lijn tekenen is niet moeilijk, maar niet bijzonder leesbaar, omdat je een lange string moet definiëren die als parameter meegaat met de rest van de URL voor de nieuwe weergave. De Google Static Maps API geeft een beeld (GIF-, PNG-of JPEG) als antwoord op een HTTP-verzoek via een URL. Voor elke aanvraag, kan je de locatie van de kaart, de grootte van de afbeelding, het zoomniveau, de aard van de kaart, en de plaatsing van de optionele markers op locaties op de kaart meegeven. Ook kun je lijnen op de kaart tekenen. Het lastige is dat je moet onthouden welke URL je vorige keer hebt gebruikt, en deze URL moet herbouwen tot je nieuwe URL. Een voorbeeld: Stel je vorige plaatje was gegenereerd met een URL die je kan opdelen in de volgende blokken: startURL + Center + Zoom + Size + KeyAndSensor Als je nu twee lijnen wilt tekenen dan word je volgende URL: startURL + Center + Zoom + Size + KeyAndSensor + Paths Stel je wilt nu inzoomen dan wordt het: startURL + Center + (Zoom + 1) + Size + KeyAndSensor + Paths Als je nu een path wilt verwijderen moet je ook weer het hele plaatje opnieuw inladen vanuit de browser. Dus deze engine ondersteunt geen incrementele opbouw van de kaart. De look-and-feel van deze engine is niet zo prettig als die van AJAX. Functioneel gezien kan je ook een stuk minder. Kan je incrementeel dingen toevoegen aan de kaart? Google Maps AJAX Via Google Maps AJAX is dit mogelijk Google Static Maps Je kunt niet incrementeel je kaart opbouwen, in die zin dat je elke keer een nieuwe kaart moet opvragen van Google, wanneer je iets wilt toevoegen aan de kaart. Belangrijk hierbij is dat je dit slechts 1000x per dag mag doen. Dus het is belangrijk zoveel mogelijk in ‘one-go’ te doen. Hoe makkelijk is het om files weer te geven (op de gegeven plaats)? 68

Beide alternatieven werken in principe met latitude en longitude coördinaten. Als van een filebericht duidelijk is op welke latitude en longitude coördinaten hij zich bevindt, kan deze eenvoudig worden getekend. Hierbij zijn wel de tussenliggende coördinaten van de file nodig. Google Maps AJAX Hier kan je ook gebruik maken van de Google Directions, als je van twee locaties de coördinaten hebt, dan tekent Google automatisch de lijn over de rijbaan. Deze lijn kan je ook bewerken qua kleur,transparantie, etc. Het nadeel is dat twee rijbanen zo dicht op elkaar zitten dat wanneer je uitzoomt de lijnen deels over elkaar geraken en niet meer goed duidelijk is welke rijbaan een file heeft. Welke coördinatenstelsels ondersteunt de engine? Voor beide alternatieven geldt dat ze gebruik maken van latitude en longitude. Wat is de vraagprijs voor het gebruik van de engine? Beide alternatieven zijn gratis te gebruiken Wat zijn de voorwaarden voor gebruik van de engine? Voor beide alternatieven gelden de volgende licenties: 9. License Requirements. Google's licenses above are subject to your adherence to the following requirements: 9.1 Free, Public Accessibility to Your Maps API Implementation. Your Maps API Implementation must be generally accessible to users without charge. You may require users to log in to your Maps API Implementation if you do not require users to pay a fee. Unless you have entered into a separate written agreement with Google or obtained Google's written permission, your Maps API Implementation must not: (a) require a fee-based subscription or other fee-based restricted access; or (b) operate only behind a firewall or only on an internal network (except during the development and testing phase). 9.4 Responsibility for Breaches. You agree that you are solely responsible for (and that Google has no responsibility to you or to any third party for) any breach of your obligations under the Terms and for the consequences (including any loss or damage which Google may suffer) of any such breach. 11. Licenses from You to Google. 11.1 Content License. Google claims no ownership over Your Content, and You retain copyright and any other rights you already hold in Your Content. By submitting, posting or displaying Your Content in the Service, you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publicly perform, publicly display and distribute Your Content through the Service and as search results through Google Services. This license is solely for the purpose of enabling Google to operate the Service, to promote the Service (including through public presentations), and to index and serve such content as search results through Google Services. If you are unable or unwilling to provide such a license to Your Content, please see the FAQ for information on configuring your Maps API Implementation to opt out. 11.2 Brand Features License. You grant to Google a nontransferable, nonexclusive license during the Term to use Your Brand Features to advertise that you are using the Service.

69

11.3 Authority to Grant Licenses. You confirm and warrant to Google that you have all the rights, power and authority necessary to grant the above licenses.

Terms of use voor AJAX Google maps: There is no limit on the number of page views you may generate per day using the Maps API. However, if you expect more than 500,000 page views per day, please contact us in advance so we can provision additional capacity to handle your traffic. There is a limit on the number of geocode requests per day. See this FAQ for more information on what represents a geocode request and what the exact limits are. The Maps API does not include advertising. If we ever decide to change this policy, we will give you at least 90 days notice via the Google Geo Developers Blog. Your service must be freely accessible to end users. To use Google mapping technology in other types of applications, please use Google Maps API Premier. You may not alter or obscure the logos or attribution on the map. You must indicate whether your application locator) to determine the user's location.

is

using

a

sensor

(such

as

a

GPS

You may use the API (except for the Static Maps API) in websites or in software applications. For websites, please sign up with the URL where your implementation can be found. For other software applications, please sign up with the URL of the page where your application can be downloaded. Google will upgrade the API periodically, and you must update your site to use the new versions of the API. The Maps team will notify you of updates on the Google Geo Developers Blog. If we make a non-backwards compatible change, we will give you at least a month's notice to make the transition, during which both versions of the API will be available. There are some uses of the API that we just don't want to see. For instance, we do not want to see maps that identify the places to buy illegal drugs in a city, or any similar illegal activity. We also want to respect people's privacy, so the API should not be used to identify private information about private individuals. Remember that we reserve the right to suspend or terminate your use of the service at any time, so please read through the FAQ and forum posts to decide whether your site meets the Terms of Use before you begin API integration.

Terms of Use voor Static API: Audience This document is intended for website and mobile developers who want to include Google Static Maps API images within a webpage. It provides an introduction to using the API and reference material on the available parameters. Usage Limits Use of the Static Maps API requires registration of a free Maps API key. The Maps API key allows you to use the Static Maps API, as well as the standard Maps API. Use of the Google Static Maps API is also subject to a query limit of 1000 unique (different) image requests per viewer per day. Since this restriction is a quota per viewer and not per key, most developers should not need to worry about exceeding their quota. Additionally, note that requests of identical images, in general, do not count towards this limit beyond the original request.

70

If a user exceeds the limit as proscribed above, the following image will be displayed indicating that the quota has been exceeded:

This limit is enforced to prevent and this limit may be changed in hour limit or otherwise abuse the you temporarily. If you continue Maps API may be blocked.

abuse and/or repurposing of the Static Maps API, the future without notice. If you exceed the 24service, the Static Maps API may stop working for to exceed this limit, your access to the Static

TatukGIS Hieronder is een overzicht te vinden van alle antwoorden op de vragen van hierboven voor de kaartengine TatukGIS. Kan ik uitgaan van een stabiele API? Ja, want de TatukGIS Developer Kernel is verkrijgbaar in een versie met een VCL library. Deze library wordt dus lokaal gedraaid tijdens het ontwikkelen. Via welke taal communiceer je met de engine? Met Delphi. Je communiceert namelijk met delen uit de library. Zo is er een GIS-form-component die een kaart kan weergeven. Hoe kun je aan een nieuwe versie van de kaart komen? Geen informatie kunnen vinden over het aanschaffen van kaarten voor deze engine. Is er een kaart van West-Europa bijgeleverd met de volgende landen: Nederland, Italië, Spanje, België, Zweden, Zwitserland, Oostenrijk en Finland? Niet meegeleverd, maar een World Map is wel verkrijgbaar. Zie vraagprijs. Lokale of externe engine? (Extra verbinding nodig?) Lokale engine: geen internetverbinding nodig. Hoe makkelijk is de engine in gebruik? De engine kan o.a. gebruik maken van ArcView shape bestanden. Deze bestanden bevatten vectordata. Voor een kaart van bijvoorbeeld Polen worden verschillende lagen over elkaar heen geplakt, bijvoorbeeld een laag met steden en een laag met wegen. Ieder object is apart opvraagbaar middels die laag. De documentatie zorgt ervoor dat de engine makkelijker is in gebruik. Het ruim 3000 pagina’s tellende document over de gehele Developer Kernel bevat een duidelijke API met ‘code examples’. Op welke manier kun je tekenen op de kaart en hoe makkelijk gaat dit? Bijvoorbeeld: Hoe teken je een lijn? Je voegt een Shape-object toe aan een bestaande laag. De laag is opvraagbaar door de kaart-viewer (uit de form).

71

Kan je incrementeel dingen toevoegen aan de kaart? Ja, de kaart bevindt zich in het geheugen en kan aangepast worden. Hoe makkelijk is het om files weer te geven (op de gegeven plaats)? Tot nu toe kan ik werken met pixel-posities (bijvoorbeeld x=100 en y=500 in een 600x800 scherm) en coördinaten binnen een layer (geen ervaring). Welke coordinatenstelsels ondersteunt de engine? Geen informatie gevonden over welke coördinatenstelsel er gebruikt wordt in TatukGIS. Wat is de vraagprijs voor het gebruik van de engine? Een licence voor de Developement Kernel kost 1.690 dollar zonder source code en 1.990 dollar met. Licensing gaat per developer, dus voor nu kost het minimaal 3 x 1.690 = 5.070 dollar. Na aankoop heeft de gebruiker 12 maanden lang toegang tot upgrades/support/user forum. Daarna kost dat per 12 maanden 45% van de huidige aankoopprijs. De ‘World Map Data Set’ kost 200 dollar. Zonder geldig EU VAT nummer komt er nog 22% BTW bij. Wat zijn de voorwaarden voor gebruik van de engine? Over het uitrollen van applicaties: “You may deploy (install) any compiled final user applications created from the DEVELOPMENT TOOLKIT to final user workstations, free of any royalty charges, provided that the two following conditions are both true: i) The application does not expose interface), methods, classes, functions,

the

TatukGIS

API

(application

program

or properties (such as in the meaning of scripting functionality), and ii) The application is not competitive to the TatukGIS Editor product.”

Over het noemen van TatukGIS binnen de eigengemaakte applicatie: “Any final user application created using the DEVELOPMENT TOOLKIT must include the text “This product was developed using the TatukGIS Developer Kernel” either in i) the application’s About box or ii) in the area of the product documentation where appears any other copyright statements relating to 3rd party software used to create the application.”

Over het registreren van gebruikers: “You are required to provide TatukGIS with accurate and valid registration information, including your name, identity, address, telephone number, and e-mail address, and with any subsequent changes to your registration information. Supplying false, incomplete, or misleading information is a violation of this License Agreement. TatukGIS will abide by the terms of its privacy policy, which prevents it from disseminating such registration information to others without the consent of the owner of the information.”

Extra opmerkingen Ondersteuning voor Delphi 6, 7, 2005, 2006, 2007 (als VCL library).

72

Bijlage B: Installatiedocumentatie

Documentatie Erika Installatiedocumentatie

1291971 - Gert-Jan Deen 1258931 - Michel de Ridder 1263196 - Maarten Somhorst Technische Universiteit Delft, Faculteit Elektrotechniek, Wiskunde en Informatica

73

Installatiedocumentatie Dit document beschrijft hoe Erika op een computer geïnstalleerd kan worden. Erika wordt geleverd in een zip bestand. Zodra deze uitgepakt is zijn er drie mappen te zien: Documentatie, Erika en MapServer. In deze mappen staan de bestanden die nodig zijn voor de installatie.

Systeemeisen   

Windows XP SP2 of Windows Vista SP1 Processor met een kloksnelheid van minimaal 2 GHz Werkgeheugen met een grootte van minimaal 1 GB

Installeren van MapServer Als eerste moet de MapServer worden geïnstalleerd. In de map ‘MapServer’ zijn de benodigde bestanden te vinden. Om MapServer correct te installeren moeten de volgende stappen worden genomen: 1. Voeg de mapserver4 registry aan je register toe door er op te klikken 2. Voer het bestand mapserver.exe uit en laat alle instellingen op standaard staan 3. Installeer vervolgens de kaart met behulp van de PTV cd-rom. Open de setup.exe en volg de stappen. Zodra er wordt gevraagd een locatie op te geven om de kaart op te slaan kiezen we hiervoor dezelfde map als we bij mapserver.exe hebben gekozen. Als we deze op de standaard waarde hebben laten staan is dit: C:\Program Files\mapserver4. Als we nu naar C:\Program Files\mapserver4 gaan en het bestand KETest.exe openen kunnen we controleren of de kaart goed is geïnstalleerd. Als we hier een kaart zien van Europa dan is MapServer goed geïnstalleerd.

Uitvoeren van Erika Nu de MapServer goed is geïnstalleerd kunnen we Erika gaan opstarten. Dit kan door de StartErika batch te openen. Deze is te vinden in de map Erika. Dit bestand gaat er vanuit dat er twee monitoren beschikbaar zijn en zal de standaard afspeellijst afspelen. Zie de beheerdocumentatie in bijlage D voor het configureren van Erika.

74

Bijlage C: Gebruikersdocumentatie

Documentatie Erika Gebruikersdocumentatie

1291971 - Gert-Jan Deen 1258931 - Michel de Ridder 1263196 - Maarten Somhorst Technische Universiteit Delft, Faculteit Elektrotechniek, Wiskunde en Informatica

75

Gebruikersdocumentatie In dit document wordt uitgelegd hoe het programma ‘Erika’ gebruikt kan worden. Dat wil zeggen, hoe men de basisinstellingen kan wijzigen en het kan opstarten. Erika is één programma dat twee keer geopend kan worden zodat er op twee verschillende monitoren twee verschillen afspeellijsten kunnen worden getoond. In de standaard uitvoering bestaat de applicatie uit een afspeellijst voor Nederland en Europa. De afspeellijst van Nederland is te vinden in ‘nl/data/playlist.xml’ en de afspeellijst van Europa is te vinden in ‘eu/data/playlist.xml’.

Instellen van de afspeellijst Erika wordt geleverd met twee standaard afspeellijsten. Deze afspeellijsten kunnen door de gebruiker naar eigen wens worden gewijzigd. Om een afspeellijst te veranderen moet het bestand playlist.xml worden geopend. Dit bestand bevat een lijst van slides die elk een tijd meekrijgen, waarin ze hun informatie kunnen weergeven. De playlist.xml zou er als volgt uit kunnen zien: <MapServerConfig> TRUE KaartNL TrafficMotionDelft KaartCH

Er zijn drie dingen die aan dit bestand kunnen worden veranderd. 1. Door ‘ONPRIMARYMONITOR’ op TRUE of FALSE te zetten kan worden ingesteld of de applicatie die deze afspeellijst afspeelt op de primaire monitor moet worden afgespeeld of dat deze op de secundaire monitor moet worden afgespeeld. 2. Door een nieuwe track toe te voegen aan de ’playlist’, kan een nieuwe slide worden toegevoegd. Je kan een nieuwe track toevoegen door het volgende stukje code toe te voegen: slideNaam

3. Als slideNaam moet u een naam kiezen van een reeds gedefinieerde slide. In het bestand slides.xml in de map ‘data’ staan de namen van alle slides. Door het getal achter ‘DURATION’ te wijzigen kan de tijd worden ingesteld waarin de slide zijn informatie moet tonen. Dit getal is uitgedrukt in milliseconden.

Starten van Erika Zodra de afspeellijsten goed ingesteld zijn kan het programma worden opgestart. Dit kan worden gedaan door het batch-bestand StartErika.bat te openen. De applicatie zal nu twee keer worden geopend en op de juiste monitor worden weergeven.

Starten van de Updater Erika haalt haar historische data uit een presentatiedatabase. Om er voor te zorgen dat deze data up to date is moet er een ander programma worden opgestart genaamd ‘ErikaDBU’ (Erika DataBase 76

Updater). Als dit programma opgestart wordt is er een aantal buttons en een groot tekstveld zichtbaar. Bovenin het scherm staan twee buttons. De button ‘START UPDATING EVERY 10 MIN’ activeert een timer die er voor zorgt dat er om de 10 minuten een update uitgevoerd wordt tenzij hij nog bezig is met updaten. De button ‘STOP UPDATING’ stop de timer, dit zorgt er voor dat er niet meer om de 10 min wordt geüpdate. Als het updaten is gestart zal er in het tekstveld een log ontstaan die laat zien waar de updater mee bezig is. Onderin het scherm staan nog zes buttons om een enkel land handmatig te kunnen updaten.

77

Bijlage D: Beheerdocumentatie

Documentatie Erika Beheerdocumentatie

1291971 - Gert-Jan Deen 1258931 - Michel de Ridder 1263196 - Maarten Somhorst Technische Universiteit Delft, Faculteit Elektrotechniek, Wiskunde en Informatica

78

Beheerdocumentatie In dit document is een overzicht te vinden van de procedures die u moet volgen om nieuwe wegen, landen en slides toe te voegen aan de applicatie, maar ook hoe u de applicatie kan configureren.

Toevoegen van een nieuwe weg Om duidelijk te maken hoe een nieuwe weg voor een bepaald land kan worden toegevoegd zal eerst worden uitgelegd hoe de wegen opgeslagen worden. Vervolgens wordt er uitgelegd hoe hieraan een nieuwe weg kan worden toegevoegd. Hoe worden de wegen opgeslagen? In de data folder van de applicatie staat er voor elk land een apart XML-bestand (Bijv: NL-roads.xml, BE-roads.xml) met hierin de wegen voor het betreffende land. De wegen zijn opgeslagen in het volgende formaat:

/> /> /> /> /> />

Hierbij is het rijkswegnummer de naam van de weg en staan de coördinaten van de weg genoteerd in mercatorcoördinaten. Een nieuwe weg toevoegen Het toevoegen van een nieuwe weg aan een bestaand land kan worden gedaan door een stukje XMLcode zoals in het bovenstaande voorbeeld staat beschreven toe te voegen aan het XML-bestand. Omdat het niet eenvoudig is om aan de mercatorcoördinaten van de weg te komen is er een losse applicatie gemaakt die dit proces vereenvoudigt. De applicatie DrawRoads is te vinden in de tools folder. Stap 1: Als er voor het huidige land al wegen zijn gedefinieerd ga dan verder met stap 2. Er moet een nieuw XML bestand gecreëerd worden. De bestandsnaam moet als volgt zijn: ‘LANDCODE’-roads.xml, voor Nederland wordt dit bijvoorbeeld NL-roads.xml. Zet de volgende tekst in het nieuwe XML-bestand: <MapServerConfig>

79

Stap 2: Selecteer het XML-bestand in de applicatie. Dit kan middels de ‘Select XML’ knop (zie figuur 1, de rode selectie is de ‘Select XML’ knop). Zodra er op de knop is gedrukt opent een scherm waarin het juiste XML-bestand gekozen kan worden (zie figuur 18).

Figuur 18: DrawRoads, het selecteren van een XML bestand.

Stap 3: De knop ‘Draw Roads from XML’ tekent de wegen die in de XML gedefinieerd staan. Stap 4: Vul het rijkswegnummer in onder de knop ‘New Road’ (zie figuur 19, blauwe selectie).

Figuur 19: DrawRoads, het tekenen van een weg

Stap 5: Druk op de knop ‘New Road’ (zie figuur 19, rode selectie). Er wordt vanaf nu een nieuwe weg getekend tussen de punten die aangeklikt worden op de kaart. Stap 6: Klik met de rechtermuisknop op de kaart om een nieuw wegpunt te creëren. Stap 7: Herhaal stap 6 totdat de weg correct getekend is. 80

Stap 8: Druk op de knop ‘Finish Road’ (zie figuur 19, groene selectie). Stap 9: Kopieer nu de totale inhoud van de memo (zie figuur 19, oranje selectie) in het XML bestand. Hieronder staat een voorbeeld voor het toevoegen van een nieuwe weg indien de A1 al gedefinieerd is. Vergeet het bestand niet op te slaan voor u naar stap 10 gaat. “coordinaten van de A1” “De gekopieerde tekst uit de applicatie”

Stap 10: Druk op de knop ‘Draw Roads from XML’ om te controleren of de weg goed is toegevoegd aan het XML bestand. Herhaal stappen 4 tot en met 10 tot u alle wegen die u wilde toevoegen heeft toegevoegd. Wanneer u een fout heeft gemaakt, kunt u het volgende ondernemen: -

U begint de weg opnieuw: haal zelf de memo leeg en druk op ‘New Road’ zodat de tekening ook opnieuw begint.

-

U wilt verder met de weg zonder de laatste coördinaten. Doe dan het volgende: o Kopieer de coördinaten die u wilt behouden naar het XML-bestand. o Voeg ‘’ aan het eind toe en sla het bestand op. o Haal de memo leeg. o Vervolgens kunt u met ‘Draw Roads from XML’ ervoor zorgen dat de XML opnieuw wordt ingelezen. o Nu kunt u met ‘New Road’ verder tekenen. o Wanneer u klaar bent plakt u de nieuwe coördinaten achter de oude. Let op dat de weg met slechts een enkele ‘’ wordt afgesloten!

Toevoegen van een slide Het toevoegen van een slide kan worden verdeeld in twee categorieën: Het toevoegen van een bestaand soort slide voor een ander land en het toevoegen van een nieuw soort slide voor een land. Toevoegen van een bestaande slide voor een ander land Het toevoegen van een bestaand soort slide voor een ander land kan eenvoudig worden gerealiseerd door aan het bestand slides.xml in folder data een nieuwe slide toe te voegen. Een voorbeeld van een slide is:

81

<SLIDE> KaartES <TITLE>Spanje ES MAP <SCALEFACTOR>11000 -956469 5705484 806966 4026603 True

Hieronder staat een uitleg met de betekenis van deze velden: SLIDE NAME

De naam van de module, welke wordt aangeroepen in de afspeellijst

TITLE

De titel van de slide

COUNTRY

Het land van de slide

TYPE

Het type slide, momenteel zijn er 5 types: MAP, STATISTICFILELENGTE, STATISTICTOPSPITSEN, STATISTICFILEVERLOOP, TRAFFICMOTION

SCALEFACTOR

De schaalfactor van de wegen

ZOOMRECTANGLE

Hierin staan de coordinaten van de kaart waarop moet worden ingezoomed

INFORMATIONPANEL

Boolean of aan de rechterkant een informatie box moet worden weergeven

Hierbij is het belangrijk dat de volgende velden correct worden ingevuld: -

Een unieke ‘Name’ moet worden gekozen De juiste landcode moet worden gekozen, om de data uit de juiste tabel te halen Het juiste type slide moet worden gekozen. Er kan gekozen worden uit: MAP, STATISTICFILELENGTE, STATISTICFILEVERLOOP, TRAFFICMOTION, STATISTICTOPSPITSEN.

Voor de type slides met een kaart (MAP, TRAFFICMOTION) zijn de volgende velden ook nog van belang: - Een scalefactor om de wegen de juiste breedte te geven, dit is een kwestie van uitproberen. Bij de MAP van Nederland is de scalefactor bijvoorbeeld 4000 en voor de MAP van Delft 1000. - Een zogenaamde zoomrectangle die in mercatorcoördinaten aangeeft welk deel van de kaart weergegeven moet worden. LEFT is de x links op de kaart, TOP is de y aan de top van de kaart, etc. Om de juiste coördinaten te krijgen, kan er gebruik worden gemaakt van het programma ‘AMDemo’ wat bij MapServer wordt meegeleverd. Dit programma is standaard te vinden in: C:\Program Files\mapserver4. Met dit programma kan er op de kaart worden 82

ingezoomd op het juiste gebied. Onderin de applicatie verschijnen vervolgens de coördinaten van het gebied. Toevoegen van een nieuw soort slide Om een nieuw soort slide toe te voegen aan de applicatie moet als eerste een nieuwe frameklasse worden gemaakt die overerft van TView. Het is belangrijk dat de abstracte methoden van TView worden geïmplementeerd in deze nieuwe klasse. Het creëren van deze slide moet toegevoegd worden aan de if-statements van de CreateView function in uMain.pas. Vervolgens moet de slide worden toegevoegd aan de slides.xml in de folder data. In het vorige kopje ‘Toevoegen van een bestaande slide voor een ander land’ staat uitgelegd hoe u deze kan toevoegen aan de slides.xml.

Toevoegen van een nieuw land Om een nieuw land aan de applicatie toe te voegen moeten de volgende stappen worden ondernomen: Als eerste moet er data beschikbaar zijn van het land. Dit kan worden gedaan door voor het nieuwe land een tabel WAYFINDER_’LANDCODE’ aan de eurotraffic_hist database toe te voegen. Deze tabel moet dezelfde opbouw hebben als de tabellen die er al in staan. Deze tabel zal worden gebruikt om de presentatiedatabase van de applicatie te vullen. Als tweede moeten de wegen van een land worden toegevoegd. Dit kan worden gedaan door een nieuw XML-bestand in de folder data te maken met de naam: ‘LANDCODE’-roads.xml. Dit XMLbestand moet dezelfde opbouw hebben als de bestanden die er al staan. In de paragraaf ‘Toevoegen van een nieuwe weg’ staat beschreven hoe nieuwe wegen kunnen worden toegevoegd. Als derde moet er een slide worden gedefinieerd die gebruik maakt van de data van het nieuwe land. Dit kan worden gedaan door in het bestand slides.xml in de folder data een nieuwe slide toe te voegen. In de paragraaf ‘Toevoegen van een slide’ staat uitgelegd hoe een slide kan worden toegevoegd. Als vierde moet het land worden toegevoegd aan de applicatie. Dit kan worden gedaan door de landcode toe te voegen aan cCountryCodes in uCommon.pas Vervolgens moeten ook de TMC-tabellen worden toegevoegd, zowel de extended TMC tabel (zie Extended TMC Database) als de TMC tabel met GPS-coordinaten in de eurotraffic_location database. Om het toegevoegde land te kunnen zien in de applicatie zal de slide voor het nieuwe land moeten worden toegevoegd aan de playlist. Dit kan worden gedaan door een nieuwe track aan het bestand playlist.xml in de folder data toe te voegen. Om een track toe te voegen moet een Duration mee worden gegeven als attribuut waarin de tijd dat de slide weergegeven moet worden in ms staat. Als waarde moet de uit het bestand slides.xml worden gebruikt. KaartBE

Database In de map configs staat ook een XML waarmee de databases geconfigureerd kunnen worden. Een Database field heeft een name attribuut, waarbij ‘location’, ‘historical’ en ‘presentation’ de namen 83

zijn die Erika gebruikt voor een normale executie. (In de testmode wordt onder andere gebruik gemaakt van presentation_unittest.) De betekenissen van de velden zijn als volgt: DATABASE NAME

We maken gebruik van drie verschillende databases: een historische, presentatie en locatie database.

LOGIN

De gebruikersnaam om in te loggen in de database

PASSWORD

Het wachtwoord om in te loggen in de database

IP

Het IP adres van de database

PATH

Het pad naar de database (inclusief de extensie van de database)

DATABASENAME

De naam van de database (zonder extensie)

De database met name=’ location’ zal door Erika gebruikt worden om de TMC code om te zetten in GPS. Deze database is een vereiste om files op de kaart te kunnen tekenen. De database met name=’historical’ is de database waar Erika de Eurotraffic berichten uit ophaalt. Deze database moet tabellen hebben met de naam WAYFINDER_’LANDCODE’. De database met name=’presentation’ wordt door Erika gebruikt voor de historische weergaven.

Extended TMC Database Deze database bestanden zijn voor een correcte bepaling van de wegnaam en eventueel de afslagnaam (wanneer deze niet in het filebericht zit). Deze bestanden bevinden zich in de map database/. (Indien dit gewijzigd moet worden, moet dit in uCommon.pas ook gewijzigd worden). In de map database/ staat ook een XML-document waarin de volgende velden ingevuld moeten worden: COUNTRY, het betreffende land FILENAME, de bestandsnaam inclusief extensie DBTYPE, de extensie van het bestand (op dit moment alleen support voor .tdb en .mdb databasebestanden) LOCATIONFIELD, het veld waarin de TMC-code staat in het database bestand ROADFIELD, het veld waarin het rijkswegnummer staat in het database bestand LOCATIONNAMEFIELD, het veld waarin de afslagnaam staat in het database bestand

Logs In de map data/ staat een bestand genaamd logs.txt. Hierin logt Erika alle ‘uitzonderlijke’ gevallen die het tegenkomt. De meest voorkomende gevallen zijn:   

Files waarin bepaalde informatie ontbreekt en die moeten worden aangevuld of genegeerd. Files die niet op een weg kunnen worden gemapt en dus niet getekend kunnen worden. Databaseverbinding die is weggevallen.

84

Bijlage E: Concept slideshows In deze bijlage zijn de slideshows opgenomen van Nederland en Europa. Dit is de laatste versie van het concept voor de applicatie. Het concept bestaat uit vijf verschillende soorten slides. Per soort slide zal een beschrijving worden gegeven van de slide en wat hij doet. De voorbeelden in deze bijlage geven allemaal informatie over Nederland. De slides voor de overige landen zien er gelijkwaardig uit. Er wordt dan alleen op een ander gebied ingezoomd.

Kaartweergave zonder informatiebox Dit type slide geeft de huidige verkeerssituatie weer door de files die er op dat moment staan rood te tekenen. Er wordt ingezoomd op een stukje van de kaart.

Figuur 20: Kaartweergaveslide van Nederland zonder informatiebox

85

Kaartweergave met informatiebox Dit type slide is hetzelfde als de kaartweergave, echter de top 5 langste files staan tekstueel weergegeven in een zogenaamde informatiebox. De files worden één voor één geselecteerd, zowel in de informatiebox als op de kaart. Verder zal er de mogelijkheid zijn om aan de rechterkant van de slide een informatiebox weer te geven. Deze box beschrijft de vijf langste files in het zichtbare gebied. Zodra de slide wordt getoond zal één voor één de files in de box worden geselecteerd, zodat duidelijk wordt waar de vijf langste files zich bevinden.

Figuur 21: Kaartweergaveslide van Delft met informatiebox

86

Fileverloopkaart Dit type slides zal het verloop tonen van de files van de afgelopen 2 uur in stappen van 15 minuten. Per stap in de tijd zullen de files van dat tijdstip op de kaart worden getekend. Vervolgens zal er door de tijd heen gelopen worden, zodat zichtbaar wordt hoe de files zijn op- en afgebouwd. In de rechterbovenhoek van de slide komt een informatiebox met informatie van de weergegeven situatie.

Figuur 22: Fileverloopkaartslide van Delft

87

Statistiek: Filelengte van de afgelopen 6 uur Dit type slide toont historische gegevens over de filelengte van de afgelopen 6 uur. Dit in de vorm van een grafiek.

Figuur 23: Statistiekslide, filelengte van Nederland van de afgelopen 6 uur uitgedrukt in kilometers

88

Statistiek: Fileverlooptrend van de afgelopen dezelfde dagnamen Dit type slide laat het fileverloop van de afgelopen vier dezelfde dagnamen zien. Als het vandaag bijvoorbeeld dinsdag is, dan zal het fileverloop van vandaag worden getoond tot hoever deze bekend is. Ook is het fileverloop van de vorige drie dinsdagen te zien. Hierdoor kan er vergeleken worden met eerdere dagen en kan de kijker zelf een voorspelling maken over de drukte die gaat komen.

Figuur 24: Statistiekslide, fileverlooptrend van Nederland van de afgelopen dezelfde dagnamen uitgedrukt in kilometers

89

Statistiek: Top 10 drukste spitsen van afgelopen maand Dit type slide laat de top 10 drukste spitsen van de afgelopen maand uitgedrukt in kilometerminuten (kmmin) zien. Kilometerminuten staat voor het aantal minuten dat een specifieke file met een bepaalde lengte heeft gestaan. Er wordt hierbij onderscheid gemaakt tussen avondspitsen en ochtendspitsen.

Figuur 25: Statistiekslide, top 10 drukste spitsen van de afgelopen maand uitgedrukt in kilometerminuut

90

Bijlage F: Voorstel Architectuur Het voorstel voor de architectuur voor onze applicatie, zoals we die aan de Product Owner hebben voorgelegd. Dit voorstel is goedgekeurd en hier hebben we ons aan vastgehouden bij het implementeren. Voordat er begonnen wordt met de implementatie van applicatie A ontwerpen we de structuur van de applicatie. In dit document is te vinden hoe deze structuur eruit ziet en welke keuzes daarbij zijn gemaakt. Dit is het voorstel aan de opdrachtgever. Merk op dat de structuur tijdens de implementatie veranderd kan worden. Hieronder een schets van de architectuur:

Figuur 26: Schets architectuurontwerp waarbij de rechthoeken voor de klassen en de cirkels voor configuratiebestanden staan.

Een zwarte pijl betekent dat de ene klasse de andere benadert. Een blauwe pijl betekent overerving van de bovenstaande klasse.

Eén of twee applicaties Het is de bedoeling om op twee monitoren verkeersinformatie te gaan weergeven. We hebben er voor gekozen om per beeldscherm een aparte applicatie te laten draaien. Op het eerste beeldscherm willen we de verkeersinformatie van Nederland weergeven en op het tweede beeldscherm de verkeersinformatie van Europa. Omdat beide applicaties dezelfde functionaliteit hebben, hebben we ervoor gekozen om één applicatie te maken die twee keer op één computer geopend kan worden. Voor iedere monitor wordt er een ander configuratiebestand ingelezen.

Modulen De applicatie zal bestaan uit verschillende modulen. Voor elk type weergave is er een aparte module. Deze modulen zijn onder te verdelen in drie hoofdcategorieën: weergave van de huidige files op een kaart (MapView), weergave van historische gegevens in een grafiek (StatisticView) en fileverloop over de tijd getoond op een kaart (BuienRadarView).

91

Elke weergave heeft een eigen view-object. Deze objecten blijven gedurende de looptijd van de applicatie in het geheugen. Deze view-objecten kunnen elke keer voor de weergave worden bijgewerkt met de laatste data. Mocht dit teveel geheugen in gebruik nemen dan kunnen we ervoor kiezen dat elk view-object na de weergave wordt vernietigd. Vlak voor een volgende presentatie wordt dit view-object dan opnieuw aangemaakt. Verder heeft elke MapView een eigen verbinding met de kaart engine.

Uitbreidbaarheid van de applicatie Bij het toevoegen van een nieuwe weergave moet deze als eerst aan het configuratiebestand ‘speellijst’ worden toegevoegd. Vervolgens moet er een weergave worden toegevoegd. Dit kan gedaan worden door een nieuwe module te maken de overerft van View. Er is een onderscheid tussen de volgende weergaven: Statistiek weergave Bij het toevoegen van een nieuwe soort statistiek weergave moet een nieuwe module worden aangemaakt die de StatisticView overerft. Een StatisticView moet voor elk land de statistieken af kunnen beelden. Kaart weergave Bij het toevoegen van een nieuwe kaart weergave moet een nieuwe module worden aangemaakt die de MapView overerft. BuienRadar weergave Bij het toevoegen van een buienradar weergave voor een nieuw land moet een nieuwe module worden aangemaakt die de BuienRadarView overerft. Nieuw soort weergave Bij het toevoegen van een heel nieuwe soort weergave moet een nieuwe module worden aangemaakt die de View klasse overerft.

Configuratiemogelijkheden van de applicatie De applicatie zal gebruik maken van verschillende configuratiebestanden. Er zal één configuratiebestand ‘speellijst’ zijn waarin een lijst komt te staan met welke modulen er afgespeeld moeten worden en in welk tijdbestek dit moet gebeuren. Ook komt er een configuratiebestand ‘database’ waarin alle gegevens staan om een verbinding te kunnen maken met de database. Ook zijn de instellingen van de modules te wijzigen in een configuratiebestand ‘gebieden’.

Main Hier wordt de Database en Scheduler component geïnitialiseerd.

Scheduler Elke module krijgt een bepaalde tijd om zichzelf weer te geven. De Scheduler is verantwoordelijk voor het creëren van de modulen. Ook deelt de Scheduler timeframes uit waarin een bepaalde module zichzelf mag weergeven. De Scheduler haalt de volgorde en tijdsduur van elke module uit het configuratiebestand ‘speellijst’.

92

Databasecomponent De database met file-informatie wordt regelmatig geüpdate met nieuwe informatie. Onze applicatie zal deze nieuwe gegevens verwerken via het client-pull principe. Voor onze opdracht is het acceptabel als de file-informatie vijf minuten achterblijft op de werkelijkheid. Daarom is het niet nodig om de nieuwe gegevens continue te verwerken. Als een module data opvraagt, wordt de data die de module nodig heeft geüpdate. De databasecomponent is verantwoordelijk voor de connectie met de database en het opslaan van de data in een interne structuur. Elke module praat met dezelfde databasecomponent. Wanneer een module data nodig heeft van de databasecomponent, werkt de databasecomponent zijn interne datastructuur bij. Alleen de specifieke data die opgevraagd wordt werkt de databasecomponent bij. Waar de database te vinden is en met welke inloggegevens connectie moet worden gehaald, haalt de database uit het configuratiebestand ‘database’.

93

Bijlage G: Testplan Toen na vier sprints is gebleken dat Erika nog niet stabiel draaide hebben we besloten een testplan te maken om Erika te testen op uitzonderlijke gevallen. In deze bijlage is het testplan van de laatste fase te zien. We hebben geprobeerd om de technische details tot het minimum te beperken en toch een programmeur van Tenuki de kans te geven om een test zelf uit te voeren of te bepalen of we een goede oplossing hebben gekozen.

Testplan Erika loopt niet soepel. Hij draait wat langer dan vijf minuten, maar meer dan twee uur houdt hij het nog niet vol. Ons doel is dat op 1 juli 2009 Erika stabiel is. Sowieso gaan we testen hoe Erika zich gedraagt als ze een tijdje draait. Problemen die zich voordoen proberen we op te lossen, zodat Erika langer kan draaien. Dit is natuurlijk niet genoeg, omdat er allerlei dingen kunnen gebeuren waar Erika wellicht raar op zal reageren. Vandaar dat we problemen hebben bedacht die Erika tegen zou kunnen komen. Een deel van deze problemen gaan we nabootsen en kijken of Erika goed reageert. Zo niet, dan wordt het gerepareerd. Welke problemen precies aangepakt gaan worden, is aan het eind van dit document beschreven.

Problemen Probleemdomein A: Geen data beschikbaar 1) Geen contact met de presentatiedatabase 2) Geen contact met de historische database 3) De presentatiedatabase is leeg Probleemdomein B: Onverwachte softwareomgeving 1) MapServer niet geïnstalleerd 2) Verkeerde versie van Windows? 3) Verkeerde versie van Firebird (client en server)? Probleemdomein C: Interne problemen 1) Playlist wordt niet goed geïnterpreteerd (hij slaat slides over, laat een slide korter of langer zien dan ingesteld of het verkeerde land wordt ingeladen) Gerelateerde vragen: wat gebeurd er bij een leeg of niet-bestaand XML-bestand? Wat als de playlist leeg is? Wat als er 1 item in staat? Wat als de duration op 0 staat? 2) Wordt de presentatiedatabase op een goede manier geüpdate?

Testmethoden Probleemdomein A: geen data beschikbaar (geen contact met één van de databases) Probleem 1 en 2: Geen contact met de presentatiedatabase en/of de historische database. Gewenst resultaat: de applicatie blijft afwisselend slides weergeven, maar laat zowel op het scherm als in de logbestanden zien dat er iets niet klopt. Testmethode: 1) zet een incorrect pad in het databaseconfiguratiebestand, zodat de database onvindbaar is. 2) trek de netwerkkabel uit de computer of schakel de netwerkverbinding softwarematig uit (middels Windows). Probleem 3: De presentatiedatabase is leeg.

94

Gewenst resultaat: Als er geen informatie gevonden wordt moet de slide gewoon weergegeven worden en is het duidelijk dat er geen informatie is (eventueel met het vermelden van de reden). Testmethode: Als er geen informatie is hoort Erika niet te crashen, maar gewoon de slides weer te geven. Probleemdomein B: Onverwachte softwareomgeving Probleem 1: MapServer niet geïnstalleerd Gewenst resultaat: de applicatie slaat de slides met kaarten over en laat op het scherm en in de log zien dat MapServer niet geïnstalleerd is. Testmethode: draai Erika op een computer waar MapServer niet op geïnstalleerd is. Probleem 2: Verkeerde versie van Windows Gewenst resultaat: de applicatie probeert gewoon te draaien, maar laat in de log weten dat het een ander besturingssysteem verwacht. Testmethode: draai Erika op een computer met een ander besturingssysteem (2000, XP, Vista, 7) Probleem 3: Verkeerde versie van Firebird (client en server)? Gewenst resultaat: de applicatie probeert gewoon te draaien, maar laat in de log weten dat het een andere versie van de Firebird client of server verwacht. Testmethode: 1) draai Erika met een oude Firebird versie als client. 2) draai Erika met een oude Firebird versie als server. Probleemdomein C: Interne Problemen Probleem 1: Playlist wordt niet goed geïnterpreteerd Gewenst resultaat: de applicatie doet wat er in de afspeellijst staat. Bij een lege afspeellijst wordt er slechts een melding weergegeven op het scherm. Bij een missend XML-bestand of een lege gebeurt hetzelfde. In het geval van een enkele slide wordt hij gewoon elke milliseconden ververst. Als de duration op 0 staat wordt de slide overgeslagen. Testmethode: 1) geef de afspeellijst een andere bestandsnaam, start Erika en check of het doet wat je wilt; 2) verwijder alle items uit de afspeellijst behalve een enkele, start Erika en check of het doet wat je wilt; 3) verwijder ook de laatste, start Erika en check of het doet wat je wilt; 4) maak het gehele bestand leeg en start Erika. Probleem 2: Wordt de presentatiedatabase op een goede manier geüpdate? Gewenst resultaat: de presentatiedatabase wordt geüpdate zoals verwacht. Testmethode:    

Beginnen met een lege test database. Eerst de database vullen met "huidige informatie" Updater uitvoeren Controleren of deze informatie goed in de prestatie db is gezet

95

  

Nieuwe informatie aan de db toevoegen Updater uitvoeren Controleren of ook deze data klopt o Kijken hoeveel records erbij zijn gekomen o Kijken of ook deze data goed is verwerkt  Alle records weer wissen uit beide databases Deze (unit)test doen we niet alleen met normale data, maar ook met grensgevallen.

Selectie We kiezen ervoor om probleemdomeinen A en C volledig te testen zoals beschreven. Probleemdomein B slaan we over, omdat we er van uit gaan dat de beheerder Erika installeert volgens de installatiedocumentatie (Zie bijlage C).

Testresultaten Probleemdomein A en C hebben we getest tijdens de afrondingsfase. Hieronder wordt beschreven hoe de tests gedaan zijn en wat de resultaten ervan waren. Probleemdomein A Om probleemdomein A te testen hebben we op verschillende momenten de netwerkverbinding uitgeschakeld in Windows. Acties tijdens testrun 1 1. Netwerkverbinding uitgeschakeld 2. Erika.exe starten met een afspeellijst met recente slides (alles wat begint met ‘Kaart’). Resultaten van testrun 1 Erika laat de slides zien een geeft onderaan in beeld de volgende tekst weer: “geen file-informatie beschikbaar voor deze weergave”. De test is geslaagd. Acties tijdens testrun 2 1. Netwerkverbinding ingeschakeld 2. Erika.exe starten 3. Na het weergeven van de eerste slide netwerkverbinding uitschakelen 4. Na een paar slides (zonder file-informatie) netwerkverbinding inschakelen Resultaten van testrun 2 Erika blijft goed draaien. Tussen stap 3 en 4 geeft de applicatie natuurlijk geen file-informatie weer, maar ervoor en erna wel. De test is geslaagd. Acties tijdens testrun 3 1. Netwerkverbinding ingeschakeld 2. In Delphi het project ‘ErikaDBU’ openen 3. Breakpoint zetten bij het invoegen van een nieuwe file (in de tabel TRAFFICJAM van de presentatiedatabase) in de klasse TPresentationUpdater. 4. De updater-applicatie compileren en opstarten. 5. Zodra de applicatie bij het breakpoint is aangekomen: netwerkverbinding uitschakelen.

96

6. Verder gaan met de applicatie middels de functietoetsen F8 of F9. Excepties wegklikken (want die worden afgevangen). 7. Checken of de ErikaDBU-applicatie een schermpje weergeeft met het bericht van een exceptie. Resultaten van testrun 3 Deze test faalde toen we hem voor het eerst deden. Het probleem was dat de INSERT-statement het ID terug gaf van het record dat zojuist is ingevoerd. Echter, als er geen connectie is faalt dit uiteraard en komt er niets terug. Dit hadden we nog niet afgevangen, dus gaf de applicatie een EAccessViolation (een exceptie). Nu checken we eerst of de TIBSQL (het object dat de query uitvoert en toegang heeft tot de resultaten) een veld bezit. Zo wel, dan halen we dat ID op en zo niet, dan verlaten we de functie. Test (uiteindelijk) geslaagd. Acties tijdens testrun 4 1. Netwerkverbinding ingeschakeld 2. In Delphi het project ‘ErikaDBU’ openen 3. Breakpoint zetten bij het uitlezen van het resultaat van een query naar de historische database in de klasse TTrafficJamHelper. 4. De updater-applicatie compileren en opstarten. 5. Zodra de applicatie bij het breakpoint is aangekomen: netwerkverbinding uitschakelen. 6. Verder gaan met de applicatie middels de functietoetsen F8 of F9. Excepties wegklikken (want die worden afgevangen). 7. Checken of de ErikaDBU-applicatie een schermpje weergeeft met het bericht van een Exceptie. Resultaten van testrun 4 Ook deze test faalde toen we hem de eerste keer deden. De functie FieldByName veroorzaakte een exceptie bij het ophalen van de informatie uit het veld ‘RAW_XML’. Blijkbaar heeft het object TIBQuery in dat geval de connectie nodig, terwijl andere velden uitgelezen kunnen worden zonder de connectie. De desbetreffende functie in TTrafficJamHelper wordt vroegtijdig gestopt indien één van de FieldByName-methoden zo’n soort exceptie gooit. Het programma is dan in de veronderstelling dat het een ongeldige file is, omdat ‘nil’ wordt teruggegeven. Acties tijdens testrun 5 1. Leeg de historische database en de presentatiedatabase 2. Erika.exe starten Resultaten van testrun 5 Erika wordt gewoon opgestart en geeft links onderin een melding dat er geen data beschikbaar is. Probleemdomein C Om probleemdomein C te testen hebben we de functionaliteit van de Slideshowwisselaar en de presentatiedatabase getest. De functionaliteit van de Slideshowwisselaar is met het oog gecontroleerd en de presentatiedatabase met behulp van unittests. Acties tijdens testrun 1 1. Playlist.xml in de folder data verwijderen 97

2. Erika.exe starten Resultaten van testrun 1 Erika geeft een exception dat hij bestand playlist.xml niet kan vinden. Zonder playlist.xml is het niet nodig dat Erika blijft draaien. Acties tijdens testrun 2 1. Verwijder alle tracks uit de playlist.xml in de folder data. 2. Erika.exe starten Resultaten van testrun 2 Erika wordt wel opgestart, maar heeft geen slides in de afspeellijst om af te spelen. Er verschijnt links onderin een melding dat er geen items zijn in de afspeellijst. Acties tijdens testrun 3 1. Zorgt dat er maar één track is in de playlist.xml in de folder data. 2. Erika.exe starten Resultaten van testrun 3 Om te controleren of de slideshowwisselaar goed werkt met één track moet deze ene track constant worden weergeven. Doordat het icoontje van de muisaanwijzer verandert zodra de slide wordt gewisseld weten we wanneer de slide wordt bijgewerkt. Resultaat: Erika werkt deze slide correct bij. Acties tijdens testrun 4 1. Zet de afspeelduur van de eerste track op 0 2. Erika.exe starten Resultaten van testrun 4 Als de afspeelduur op 0 wordt ingesteld wordt de slide getoond maar wordt de timer niet geactiveerd. Hierdoor zal Erika alleen deze slide laten zien en worden de volgende items uit de afspeellijst niet meer getoond. Als iemand de slide niet wilt zien moet de track gewoon worden verwijderd uit de afspeellijst. Acties tijdens testrun 5 1. Implementeer de functie om het updaten te testen, de functie om het update te testen bestaat uit de volgende stappen: a. Voeg door middel van inserts drie berichten (met dezelfde vorm als normale berichten) toe aan de wayfinder tabel in de unittest database b. Controleer of deze berichten goed worden toegevoegd c. Voer de update functie uit d. Controleer of de update the berichten goed heeft toegevoegd aan de presentatiedatabase door middel van berichten tellen en of de data klopt. e. Verwijder alle berichten die hiervoor zijn toegevoegd. 2. Start de testsuite 3. Controleer het resultaat van de testsuite Resultaten van testrun 5 Deze test is geslaagd. 98