Oberon Interactive B.V.
Travelbase Beheer Applicatie Auteur: Benno Crombeen Begeleider: Egbert Hulsman Januari 2012
Inhoudsopgave Inhoudsopgave
2
1. Inleiding
4
2. Oriëntatie
5
2.1 Oberon Interactive
5
2.2 Mijn functie binnen Oberon Interactive
5
3. Probleemomschrijving
7
3.1 Huidige situatie
7
3.2 Gewenste situatie
8
3.3 Kader
9
4. Project aanpak
11
5. Uitwerking
13
5.1 Requirements
13
5.2 Analyse
15
5.3 Ontwerp
15
5.4 Implementatie
22
5.5 Testen
24
5.7 Uitrol
25
6. Resultaat
28
7. Conclusie
29
8. Reflectie
31
8.1 Situatie
31
8.2 Taken
31
8.3 Acties
31
8.4 Resultaat
32
8.5 Reflectie
33
Bijlage I Use Case Diagram:
35
Bijlage II Use Cases:
37
Bijlage III: Klassen diagram
53
2
Bijlage IV Database schema
55
Bijlage V Schermen van de applicatie
56
Literatuur
59
3
1. Inleiding Deze scriptie is geschreven als afstudeeropdracht voor de deeltijd opleiding Informatica aan de Hogeschool van Amsterdam. Het onderwerp van deze scriptie is de realisatie van de Travelbase beheer applicatie. Dit is een onderdeel van het Travelbase pakket. Met Travelbase kunnen eigenaren van huisjes en hotels ervoor zorgen dat ze op Internet te boeken zijn. In het volgende hoofdstuk zal eerst het bedrijf Oberon Interactive B.V. worden beschreven. In dit hoofdstuk zal ook de opdrachtomschrijving uitgewerkt worden. Hier wordt de afbakening van dit stuk software in beschreven.
4
2. Oriëntatie 2.1 Oberon Interactive Oberon Interactive is een multimedia bureau dat zowel voor eigen klanten als bureaus werkt. Binnen Oberon worden vooral interactieve toepassingen gemaakt. Dat zijn onder andere reclamecampagnes die worden weggezet op Facebook of Hyves. Verder worden er momenteel veel mobiele applicaties ontwikkeld voor verschillende platformen, zoals iPhone, Android en Blackberry. Oberon is in 1993 opgericht door Hans-‐Peter Harmsen, Martijn Lemmens en Douwe Osinga. In 2005 is Oberon samen gegaan met Media-‐Id. Media-‐Id had toen een bestaand software pakket waarmee huisjes en hotels geboekt konden worden. Dit systeem is later TOR gaan heten en is in gebruik genomen door de VVV Texel en de VVV’s van de andere eilanden. Momenteel werken er bij Oberon 12 mensen, de organisatiestructuur van Oberon is in het volgende plaatje weergegeven.
Oberon InteracVve management (Hans-‐Peter Harmsen, Gert Braun, Richard de Boer) Mobile Developers
Web developers
Stagiair
Designers Stagiair
Figuur 1, organogram Oberon Interactive B.V.
2.2 Mijn functie binnen Oberon Interactive Binnen Oberon Interactive ben ik senior developer. Als zodanig ben ik vooral bezig met webdevelopment. Ik pleeg daarvoor onderhoud aan de bestaande web-‐applicaties en ben momenteel bezig met het opzetten en realiseren van het nieuwe product Travelbase.
5
Binnen Oberon gebruiken we voor de backend systemen van de web applicaties verschillende programmeertalen zoals PHP, Python en C#. De online boekingssystemen die nu draaien zijn echter in PHP geschreven en het onderhoud is dan ook voornamelijk in PHP. De voorkant is HTML en JavaScript, de nieuwe systemen worden voornamelijk opgeleverd in HTML 5.
6
3. Probleemomschrijving Oberon heeft momenteel het product TOR (Texel Online Reserveringssysteem) draaien waarmee VVV organisaties huisjes en hotels via internet boekbaar kunnen maken. Het TOR systeem heeft onder andere de volgende functionaliteiten: •
Een publiekelijk toegankelijke zoek en boek tool, waarmee bezoekers van de website op basis van een datum, een duur en enkele zoekcriteria zoals plaats, sauna een object kunnen boeken
•
Een afgeschermd deel voor de VVV om te zien welke boekingen er zijn gemaakt en om nieuwe objecten toe te voegen aan het systeem
•
Een inlogdeel voor een logiesverstrekker om de gegevens van zijn/haar eigen object te beheren, zoals teksten, plaatjes en kenmerken van het object. Verder kan er per dag een beschikbaarheid en een prijs voor het object worden beheerd. Hieronder vallen last-‐minute kortingen en eventueel andere afwijkende prijzen.
De grootste afnemer van dit stuk software is de VVV van Texel. Het boekingssysteem wordt verder ook gebruikt door de VVV Ameland, VVV Terschelling en door de VVV Zeeland. Al deze pakketten zijn verkocht als maatwerkpakketten. Dat houdt in dat de afnemer tegen betaling extra functionaliteiten kan laten ontwikkelen voor het product. Het grootste deel van deze pakketten werkt op dezelfde manier, maar er zijn in de boekingsprocessen aanpassingen gedaan om het pakket naar wens van de desbetreffende afnemer op te leveren.
3.1 Huidige situatie Het product TOR is momenteel een software pakket dat door partijen kan worden ingekocht en tegen betaling kan worden aangepast naar de wensen van de afnemer. Dit betekent dat er voor de afnemer een behoorlijke initiële investering is om het product aan te schaffen. Daar staat tegenover dat de afnemer wel invloed heeft om wijzigingen, al dan niet tegen betaling, door Oberon te laten doen aan het systeem. Het product TOR is zeven jaar geleden voor het eerst opgezet en steeds verder doorontwikkeld. Bij de start van het product is er nooit nagedacht over de levensduur van het software pakket. Nadat het verkocht is aan VVV Texel, bleek dat er ook andere partijen waren geïnteresseerd in hetzelfde
7
pakket. Bij de doorverkoop van het pakket TOR aan andere partijen is gekozen voor de volgende strategie. •
Kopie maken van de bestaande broncode
•
Kopie maken van de bestaande databasestructuur
•
Broncode aanpassen naar specifieke wensen van de afnemer
•
Database aanpassen naar specifieke wensen van de afnemer
In het begin laten de eisen en wensen van de afnemers behoorlijk dicht bij elkaar. Het onderhoud van het totale systemen, met betrekking tot bugfixes en aanpassingen was op dat moment nog niet een groot probleem. In de loop der jaren zijn de pakketten door de wensen van die afnemers steeds verder uit elkaar komen te liggen. Hierdoor is bijvoorbeeld het implementeren van een koppeling met een derde partij steeds lastiger en meer werk geworden per pakket. Dit vanwege het feit dat er per pakket specifieke implementaties moeten worden gedaan.
3.2 Gewenste situatie In de huidige marktsituatie is gebleken dat er nog steeds veel partijen zijn die interesse hebben in een product met de functionaliteiten die in TOR aanwezig zijn. Volgens Oberon Interactive is het echter niet wenselijk om het bestaan van het huidige systeem op de in de vorige paragraaf beschreven wijze te blijven verkopen. In de loop der jaren is het product TOR qua code slechts uitgebreid en niet gerefactored. Refactoring wil zeggen dat de code opnieuw wordt gerangschikt om de onderhoudbaarheid en uitbreidbaarheid van de code te waarborgen. Om code te kunnen refactoren zijn test cases door middel van unit tests onontbeerlijk. Een unit test is een methode die een bepaald stukje afgebakende broncode test op zijn werking. Het is het kleinste deel in een stuk software dat op zichzelf staand kan worden getest. In het volledig TOR systeem is geen enkele unit test aanwezig. Hierdoor is het refactoren moeilijker geworden, aangezien er dan na een aanpassing in de broncode de volledige applicatie door een gebruiker handmatig nagelopen moet worden. De bedoeling is om het nieuwe systeem beter onderhoudbaar en testbaar te maken door gelijk in het begin unit tests te ontwerpen voor de software. Ook is het de bedoeling om de volledige code up-‐to-‐date te krijgen met de nieuwste standaarden.
8
Een ander groot belangrijk punt is het licentie model waarop Travelbase van TOR verschilt. TOR is steeds verkocht voor een vaste prijs per afnemer, in combinatie met webserverhuur en een onderhoudscontract. Travelbase zal worden weggezet onder een ASP licentie. Het ASP model houdt in dat de software op een server van Oberon Interactive zal komen te draaien. De afnemer zal verder dus geen kosten hebben per installatie. Oberon verdient in dit model geld per gemaakte boeking door een bezoeker. De initiële kosten voor een afnemer vallen op deze manier weg. Wie er juridische eigendom heeft over de informatie moet nog verder uitgekristalliseerd worden. De grote drijfveer van Travelbase zal ook een REST API server worden waarmee in de toekomst meerdere partijen kunnen koppelen. In eerste instantie zullen wij er zelf ook een web-‐applicatie aan koppelen.
3.3 Kader Het totale pakket is een behoorlijk omvangrijk pakket. Het software pakket zal daarom ook incrementeel worden ontwikkeld en opgeleverd. Het eerste deel is de beheerapplicatie. Dit is het onderdeel waar logiesverstrekkers in kunnen loggen om hun eigen object te beheren. Dat betekent het kunnen beheren van teksten, foto’s en kenmerken van hun object. Ook het beheer van aankomstdagen, vertrekdagen, prijzen en voorraad. Dan gaat het hier om zowel de standaardprijs per nacht als de specifiek aangepaste prijs bij een bepaalde datum. De eindoplevering van dit project is dan ook een afgebakend stuk software. De onderliggende infrastructuur waarop Travelbase verder kan bouwen behoort ook bij dit project. Projectdoelstellingen: •
Opzetten en realiseren van Travelbase leden applicatie
Aanpak:
•
Verzamelen van de requirements Travelbase leden applicatie
•
Analyseren van Travelbase leden applicatie
•
Ontwerp van de architectuur van Travelbase leden applicatie
•
Implementeren van de Travelbase leden applicatie
•
Testen van de Travelbase leden applicatie
•
Uitrollen van de Travelbase leden applicatie
9
Het onderhouden van de Travelbase beheer applicatie zal buiten de scope van dit project vallen. Aangezien dit een onderdeel is dat naar verwachting op een veel later tijdstip zal plaatshebben en niet binnen de termijn van deze afstudeerscriptie valt.
10
4. Project aanpak Voor de aanpak van dit project hebben we binnen het Travelbase team van Oberon besloten om een afgeleide van de SCRUM1 methode toe te passen. Een deel van de bestaande functionaliteiten hebben in het software product TOR al bewezen hoe waardevol ze zijn. Deze functionaliteiten kunnen met hun gedetailleerde manier van werken bijna volledig naar Travelbase worden overgeheveld. Het verschil met een SCRUM aanpak, is dat we de applicatie voor de ontwikkeling opdelen in kleine stukjes, maar op de achtergrond een groter geheel hebben. Dat is de basisinfrastructuur van Travelbase. Dit gaat door de meerdere losse applicaties heenlopen en van te voren zullen we dus nadenken over deze architectuur om alle applicaties te ondersteunen. Per deel applicatie zoals bij de ledenapplicatie bekijken we welke functionaliteiten per oplevering aanwezig zijn en deze worden naar prioriteit ingedeeld. Eigenlijk bouwen we hier twee applicaties naast elkaar, die tegelijkertijd goed op elkaar moeten aansluiten. Dit gieten we in dezelfde SCRUM sprints.
Figuur 2, Grafische weergave SCRUM cyclus2 Binnen de SCRUM methode zijn de volgende rollen te herkennen: Teamleden, Product eigenaar en Scrum Master. De Product Eigenaar bepaald de prioriteiten voor de volgende oplevering. De 1 http://www.axosoft.com/ontime/videos/scrum 2 http://nl.wikipedia.org/wiki/Scrum_(softwareontwikkelmethode)
11
Teamleden zorgen dat het product wordt gebouwd en de SCRUM Master is de project manager die het schema in de gaten houdt. Binnen het Travelbase team bij Oberon geven we aan al deze rollen invulling. Richard de Boer is de Product Eigenaar. Gert Braun is de Scrum Master binnen het tam. Leslie Kleuver, Richard van Willigen en ikzelf zijn de Teamleden. Richard heeft als Product Eigenaar ook veel contact met de klanten en bepaalt mede vanuit hun wensen de functionaliteiten en de prioriteiten.
12
5. Uitwerking 5.1 Requirements Zoals hierboven uitgelegd is Travelbase een eigen product van Oberon. Met Travelbase willen we qua licentie model een nieuwe weg inslaan voor de toekomst. De meeste requirements komen dan ook uit Oberon zelf. Uiteraard zijn de wensen en ervaringen van de gebruikers die met het eerdere systeem TOR hebben gewerkt hiervoor wel de basis. In het verleden is ook een haalbaarheidsonderzoek geweest binnen Oberon, om te onderzoeken of een dergelijke applicatie met zulke functionaliteiten wel in de markt gezet kan worden. De uitkomst van dit onderzoek valt buiten het bereik van deze scriptie, en op basis van dat onderzoek is dit hele Travelbase traject gestart. De requirements zijn op te splitsen in twee hoofdgroepen. De functionele en de niet-‐functionele requirements. De niet-‐functionele requirements zijn weer in twee subgroepen onder te verdelen: •
Product requirements, eisen aan het gedrag van de applicatie
•
Organisatorische requirements, standaarden in de ontwikkelorganisatie
5.1.1 Niet functionele requirements Product requirements: •
De eerste versie van de beheerapplicatie is toegankelijk via de webbrowser, door middel van HTML.
•
De beheerapplicatie moet geschikt zijn om in de toekomst het mobiele platform te kunnen bedienen.
•
De beheerapplicatie dient op Windows, Mac en Linux in meerdere browsers ondersteunt te worden (Google Chrome, Internet Explorer 7,8,9, Firefox, Safari)
Organisatorische requirements: •
De beheerapplicatie dient testbaar te zijn door middel van Unit Tests.
13
•
De broncode dient opgeslagen te worden op een versiebeheersysteem. In dit geval wordt gebruik gemaakt van Mercurial (python), dat goed op Apple, Windows en Linux platformen werkt.
5.1.2 Functionele requirements Binnen Oberon is Richard de Boer product eigenaar van Travelbase. Hij heeft de meeste ervaring met TOR en heeft als zodanig ook de requirements opgesteld voor Travelbase. De ervaringen van logiesverstrekkers en de feedback op TOR dienen hiervoor als leidraad. De beheerapplicatie van Travelbase heeft vanuit het bedrijfsoogpunt een aantal actoren en een aantal objecten, waarmee wordt gewerkt. Het doel van deze applicatie is het beheren van gegevens door een gebruiker. Er kunnen teksten, beschikbaarheid en prijzen worden aangepast. De objecten waarbinnen men bij Travelbase werkt zijn: •
Organisatie (Hotel, Park)
•
Accommodatie (Vakantiehuisje, Hotelkamer)
Een accommodatie hoort altijd bij een organisatie. Verder is de beheerapplicatie een afgeschermde applicatie, waar men alleen met een gebruikersnaam en wachtwoord in kan komen. Wanneer een gebruiker is ingelogd kan hij een aantal verschillende rollen aannemen. Hij kan eigenaar zijn van een organisatie, hij kan eigenaar zijn van een accommodatie en hij kan beheerder zijn van een accommodatie. In de tekst staat bewust het woordje en, aangezien deze rollen elkaar niet uitsluiten. Aan de hierboven beschreven rollen hangen ook een aantal rechten. Een eigenaar van een organisatie mag gegevens van de organisatie aanpassen. Voor een accommodatie ligt het iets complexer. Daar is een onderverdeling tussen eigenaar een beheerder. De beheerder mag alle gegevens van een accommodatie aanpassen, teksten, prijzen, voorraad. Een eigenaar van een accommodatie mag de hoeveelheid beschikbare items van een accommodatie aanpassen. Hiermee kan worden afgedwongen dat er voorraad voor eigen gebruik wordt afgeboekt. Het overzicht van alle beschreven requirements is te vinden in Bijlage I en II. Daar staan alle functionele specificaties uitgewerkt in use case diagrammen en use cases.
14
5.2 Analyse De analyse fase wordt doorlopen om het product beter te begrijpen. Wanneer we in kaart hebben gebracht wat er precies ontwikkeld moet worden, en hoe deze onderdelen met elkaar moeten samenwerken kunnen we ook het ontwerp van het systeem goed neerzetten. De basis voor deze analyse fase zijn de documenten die we voor de requirements fase hebben geproduceerd. Op basis van de beschreven use cases weten we hoe gebruikers van het systeem interactie hebben met het systeem zelf. Communicatie binnen het systeem hebben we nog niet beschreven, dat is iets wat we in deze fase boven tafel proberen te krijgen. In deze analysefase zullen we een aantal stappen doorlopen. De eerste stap in de analyse fase is het vinden van classes die binnen het systeem van belang zijn. Met deze classes, modelleren we de werkelijkheid binnen ons systeem. De gevonden classes noteren we in een klassendiagram. Nadat we classes bij elkaar hebben, is de tweede stap het uitzoeken van de onderlinge verbanden tussen deze classes. Deze verbanden kunnen de vorm aannemen van associatie, overerving, compositie of aggregatie. De derde stap in deze fase is het zoeken van de attributen die bij de gevonden classes horen. Deze eigenschappen zijn ook weer belangrijk voor de modellering van het systeem. Op basis van de use cases die we hebben gevonden hebben we een klassendiagram gemaakt die in bijlage III is bijgevoegd.
5.3 Ontwerp Nadat de analyse fases met betrekking tot het achterhalen van de functionaliteiten en statische en dynamische analyses zijn afgerond, gaan we de ontwerp fase in. In de vorige fasen is vooral gekeken naar wat het product moet doen, nu ligt de nadruk op hoe we dat gaan doen. Zoals eerder beschreven is de beheerapplicatie van Travelbase slechts een onderdeel van het totale Travelbase systeem. Het is wel het eerste deel van Travelbase dat zal worden opgeleverd. In deze ontwerpfase is het dan ook noodzakelijk om verder te kijken dan alleen de beheerapplicatie en ervoor te zorgen dat er mogelijkheden zijn om de toekomstige onderdelen hier aan te koppelen. 5.3.1 Systeem topologie De beheer applicatie moet volgens de requirements een web-‐gebaseerde applicatie worden. Dit is belangrijk voor de topologie van het systeem. De communicatie van de computer van de eindgebruiker met de webserver zal via Internet gaan. Vanwege de variatie en het natuurlijke verloop binnen de gebruikersgroep, is het belangrijk om flexibel nieuwe gebruikers toegang te
15
kunnen geven binnen het systeem. Eveneens is het belangrijk dat ongewenste gebruikers kunnen worden verwijderd. De gebruikers zullen niet tot één organisatie behoren en vanaf verschillende locatie via Internet willen inloggen. Het gebruik van een Intranet valt hierdoor af. Ook een VPN is hier niet van toepassing, aangezien de gebruiker verder niet bij bestanden, anders dan de web-‐interface op de webserver hoeft te kunnen komen. Naast het gebruik van de webserver door Travelbase, zal er ook een database server komen te draaien. Deze database server draait op dezelfde LAN als de webserver. Via een intern Gigabit verbinding zijn deze twee servers met elkaar verbonden. Hierdoor wordt de maximale verbindingssnelheid tussen deze twee servers gewaarborgd. Deze opstelling geeft de mogelijkheid om in de toekomst de database zowel horizontaal als verticaal te partitioneren. De database komt dan in een cluster te hangen. Dit komt de schaalbaarheid van de Travelbase applicatie ten goede.
Figuur 3, globale topologie systeem. 5.3.2 Technologie keuze Nu de topologie van het systeem bekent is, kunnen er keuzes worden gemaakt voor de technologieën die worden gebruikt om dit systeem te realiseren. Deze keuzen zijn niet alleen afhankelijk van de topologie, maar zeker ook van de kennis die er binnen het bedrijf Oberon Interactive is. Het is niet handig om een exotische technologie te kiezen, waar weinig mensen mee kunnen werken, of waarvan het moeilijk is om aan goede mensen te komen.
16
PHP, HTML5 en JavaScript: De programmeertaal waarin voornamelijk de backend van het systeem is geschreven is PHP. Hierbij is ervoor gekozen om minimaal versie 5.3 te gebruiken, daar zitten ten opzichte van de voorgaande versies aanzienlijke verbeteringen in. Aangezien de server in eigen beheer is, was er geen probleem om voor deze versie te kiezen. De user interface is gebouwd in HTML5, dat wordt de nieuwe standaard. In HTML5 zitten ten opzichte van de voorgaande versies ook meer mogelijkheden, zoals bijvoorbeeld locatiebepaling en een meer semantische opmaak van de pagina. Aan HTML5 zit wel het nadeel, dat het nog niet door alle browsers volledig wordt ondersteund, vooral de Microsoft Internet Explorer browsers blijven op dit vlak nog wat achter. Er zijn wel frameworks met extra CSS en JavaScript bibliotheken die deze oneffenheden wegpoetsen. Een voorbeeld daarvan is HTML5 boilerplate3. Dit hebben wij dan ook gebruikt voor de basis. Om het effect van een vloeiende desktop interface te benaderen maken we veel gebruik van JavaScript. Het is in de beheerapplicatie voor de eindgebruiker dan ook belangrijk om JavaScript tot de beschikking te hebben. Zonder JavaScript zal de applicatie niet werken, met de doelgroep die wordt aangesproken verwachten we niet dat er op dat vlak problemen zullen ontstaan. Om de browserverschillen met betrekking tot JavaScript op te heffen, maken we gebruik van jQuery4. Naast het opheffen van de browserverschillen, zitten er in deze library nog meer handige tools, zodat de productiviteit ook flink omhoog gaat. Om ervoor te zorgen dat er niet een enorm groot JavaScript bestand ontstaat, wat lastig te onderhouden wordt, hebben we gekozen op een Model/View/Controller implementatie in de JavaScript laag toe te passen. Hiervoor gebruiken we Backbone.js5 als basis. Het gevolg is dat de JavaScript logica kan worden verdeeld over meerdere bestanden met elk hun eigen verantwoordelijkheid. Deze bestanden worden asynchroon ingeladen in de browser op het moment dat ze nodig zijn. Database: We hebben ervoor gekozen om de eerste versie van Travelbase te laten draaien op een MySQL database. Dit is een Open Source database waarmee we bij Oberon Interactive veel ervaring hebben. We maken wel gebruik van de InnoDB specifieke database engine met de utf-‐8 karakterset. Met InnoDB kunnen we referentiële integriteit afdwingen, waardoor de database zelf minder snel inconsistent zal worden. MySQL ondersteunt ook views, triggers en stored procedures, waardoor we eventuele databasespecifieke logica ook goed in het systeem kunnen verwerken. De database queries worden wel zoveel mogelijk geschreven als standaard SQL. Het is de bedoeling om Travelbase te gaan draaien op een PostgreSQL database, wanneer er meerdere klanten voor komen. 3 http://html5boilerplate.com/ 4 http://jquery.com/ 5 http://documentcloud.github.com/backbone/
17
Een PostgreSQL database, is beter schaalbaar dan een MySQL database. PostgreSQL kan zowel horizontaal als verticaal schalen. Er kunnen indexes binnen de database op bereiken worden gelegd. MySQL gaat in sommige gevallen wat vreemd om met statistische queries, bij MySQL is het mogelijk om in een statistische query irrelevante informatie op te vragen, bij PostgreSQL is dat niet mogelijk. Uiteindelijk zal PostgreSQL de database van onze keuze worden, echter door de opleverdatum en de momentele hoge beschikbaarheid van kennis over MySQL is ervoor gekozen om de eerste klant op een MySQL database te laten draaien. 5.3.3 Subsysteem opdeling Zoals eerder genoemd, is de beheer applicatie slechts een onderdeel van de totale Travelbase applicatie. Deze beheerapplicatie zal een eigen werkwijze en grafisch ontwerp krijgen. Vanwege de populariteit op dit moment van mobiele apparaten, willen we de mogelijkheid open houden om hier in de toekomst op in te spelen. Uiteindelijk heb ik de keus gemaakt om een aparte REST (REpresentationale State Transfer) server op te zetten, die verantwoordelijk is voor het ophalen en het opslaan van de informatie in Travelbase. Het voordeel hiervan is dat er een API beschikbaar komt die het volledige Travelbase pakket dekt. Er kunnen dan door diverse partijen op diverse platformen applicaties worden ontwikkeld die gebruik maken van deze API. De REST server zal uit oogpunt van compatibiliteit zowel XML als JSON kunnen communiceren. De REST server zal gebruik maken van het volledige HTTP protocol, dat wil zeggen dat de server POST, GET, PUT en DELETE zal implementeren. Ook de HTTP status codes zoals gedefinieerd door het World Wide Web Consortium (W3C)6 zal in acht worden genomen. Dit betekent dat een object door middel van een http DELETE request kan worden verwijderd. In de volgende tabel de implementatie van de requests op de REST server zoals die worden gebruikt. GET
Opvragen en ontvangen van een document gespecificeerd door een URL
POST
Verzend gegevens naar een specifiek document op de server, dit kan aanmaken of vervangen zijn van het document op de desbetreffende URL
PUT
Verzend gegevens naar de server en maak een document aan, of vervang een document. Hiermee wordt een volledig document vervangen, of aangemaakt op de URL
DELETE
Verwijder het document van de server
HEAD
Ontvang de headers van het document (handig voor controle op de http status code)
6 http://www.w3.org/Protocols/rfc2616/rfc2616-‐sec10.html
18
Met de term document in de bovenstaande tabel wordt de representatie bedoeld van een bepaalde resource, zoals bijvoorbeeld een accommodatie binnen Travelbase. Met de term headers in de bovenstaande tabel wordt bedoeld, het onderdeel van het request dat in text de inhoud van het request beschrijft. De REST server zal in de praktijk vooral belangrijk zijn voor de ontwikkelaars binnen Oberon en eventueel andere partijen die met Travelbase willen gaan koppelen. De eindgebruiker zal voor de beheer applicatie een website gebruiken. De REST server zelf is onderverdeeld in meerdere lagen. In de REST server implementeren we drie lagen, de Database laag, Business laag en de Interface laag. De Database laag is hier de relationele database die wordt gebruikt om de gegevens op te slaan. In de Business laag bevinden de objecten die gemodelleerde entiteiten implementeren. De bovenste laag is de Interface laag. Dit is voor de REST server niet zozeer een grafische interface als wel de implementatie van de verschillende communicatieprotocollen. Hierin zit de vertaling van de data naar JSON of XML.
Interface laag Business laag Database Figuur 4, de lagen binnen het systeem
19
De web-‐gebaseerde beheerapplicatie zal voor de gebruiker een website zijn. De gebruiker zal hier moeten inloggen om zich toegang tot het systeem te verschaffen. Vervolgens komt de gebruiker een op website met verschillende onderdelen om zijn objecten te beheren. In de toekomst schept dit de mogelijkheid om meerdere web-‐gebaseerde applicaties te koppelen aan de REST server zoals bijvoorbeeld de zoek applicatie, die op basis van ingegeven criteria beschikbare objecten aan de gebruiker toont.
Figuur 5, De REST server, met andere de koppelen applicaties 5.3.4 Concurrency Een onderdeel van de applicatie waar ook over is nagedacht is concurrency. Vooral de beschikbaarheid, dat wil zeggen het aantal nog boekbare eenheden van een logie, is hier belangrijk. Voor het aanpassen van prijzen op een bepaalde dag, of het aanpassen van teksten worden geen extra maatregelen ingebouwd. De activiteit van eigenaren voor het wijzigen van prijzen en teksten zal niet dusdanig zijn dat daar extra maatregelen voor worden ingebouwd. Voor de beschikbaarheid, bouwen we op procesmatig niveau wel extra controle in. Speciaal voor het boeken zullen we een reserveringsprincipe inbouwen dat een object voor een klant reserveert. Dit object wordt na annuleren of verlopen van een vooraf ingestelde tijdsduur weer vrijgegeven. Voor de beheer applicatie heeft dit ook een gevolg. De beschikbaarheid kan niet verminderd worden door de eigenaar, in een hoeveelheid die minder is dan de klant via de zoekapplicatie heeft gereserveerd. Dit om teleurstelling bij de klant te voorkomen.
20
5.3.5 Beveiligingsbeleid De Travelbase REST server is niet zomaar voor iedereen vrij toegankelijk. De informatie in het systeem willen we ontsluiten via een bepaald aantal applicaties, die gebouwd zijn door partijen waarmee Oberon Interactive een contract heeft voor het gebruik van deze informatie. Op de resources op de REST server zijn meedere lagen van authenticatie van toepassing. •
Unieke authenticatie voor applicaties die gebruik maken van de REST server
•
Authorisatie van de applicaties om te bepalen of deze applicaties wel van requests gebruik mogen maken
•
Unieke authenticatie voor gebruikers die via een applicatie bewerkingen doen op de resources van Travelbase
•
Authorisatie van de gebruiker, om te bepalen of deze wel de resources van Travelbase mag bekijken of mag bewerken
Er moet een unieke authenticatie aanwezig zijn voor verschillende applicaties die contact maken met de REST server. Om ervoor te zorgen dat men op Internet niet zomaar gebruik kan maken van onze REST server, willen we een authenticatie mechanisme implementeren. Hiervoor hebben we grofweg drie verschillende mogelijkheden. -‐
Standaard HTTP authenticatie
-‐
OAuth
-‐
Versleuteling met een private sleutel van de request naar de server
Tussen de bovenstaande authenticatie mechanismen zitten een aantal verschillen. Bij standaard HTTP authenticatie worden gebruikersnaam en wachtwoord verstuurd over de verbinding, alhoewel dit over een beveiligde HTTPS verbinding zal gaan is niet geheel wenselijk. Ook de browser implementatie, die zorgt voor een popup scherm waarin men kan inloggen en niet kan uitloggen totdat de browser is afgesloten is niet heel erg mooi. OAuth authenticatie zoals geïmplementeerd is vooral om een gebruiker heen gebouwd. Deze vorm wordt geïmplementeerd door onder andere Facebook. Het idee hierachter is dat de gebruiker aan verschillende applicaties toestemming geeft om zijn gegevens te bewerken. Dit sluit niet aan bij de gedachte die we voor Travelbase hebben. Voor Travelbase willen we de mogelijkheid hebben om een
21
andere partij een applicatie te laten schrijven die gebruik kan maken via de REST server. De verwachting is voorlopig niet zo dat er heel veel partijen een koppeling willen maken met Travelbase. Deze manier van authenticatie is vooral ook gericht op het web. Voor server-‐server communicatie is deze methode minder geschikt. Bij de nieuwe implementatie van het OAuth protocol, versie 2.0 wordt de server-‐server communicatie aanzienlijk beter. Deze versie is alleen op dit moment nog in ontwikkeling. Versleuteling met een private sleutel van de requests naar de server sluit het meeste aan bij de architectuur van Travelbase. Een partij krijgt een private sleutel gekoppeld aan een gebruikersnaam. Met deze private sleutel wordt het volledige request versleuteld. Dit gebeurd voor zowel de GET, PUT, POST en DELETE requests. Op de server wordt de geldigheid gecontroleerd, en wordt bepaald of het request uitgevoerd wordt. 5.3.6 Subsysteem communicatie De verschillende subsystemen zullen zoals eerder aangegeven onderling communiceren via JSON of XML. JSON is gedefinieerd als lichtgewicht tegenhanger van XML in de RFC 46277. XML bestaat al langer communicatie middel tussen verschillende systemen. De officiële versie wordt door het World Wide Web Consortium (W3C) beschreven8.
5.4 Implementatie De implementatie is door een team van vier personen gedaan. Zelf ben ik bezig geweest met de opzet van de REST server. Als basis hiervoor heb ik gekozen voor FRAPI9. Dat is een open source REST server. Zelf ben ik ook deelnemer aan dit project. Vooral PHP specifieke caching door middel van APC zit goed in dit framework. Ook het aanmaken van URL’s en het vervolgens daar achter koppelen van de business logica gaat in dit systeem erg gemakkelijk. Verder zijn er voor alle delen van dit systeem Unit Testen geschreven. Na het doen van enkele aanpassingen aan het autorisatie gedeelte van het systeem, was het makkelijk om via de Unit Tests te achterhalen of het geheel nog goed werkte. Vervolgens zijn we begonnen met het implementeren van de Use Cases op API niveau. Dit heb ik samen gedaan met Jonathan Staats. Dit is een student informatica aan de Universiteit van Amsterdam die in de zomervakantie als vakantiebaan heeft geholpen met het door ontwikkelen van de API. 7 http://tools.ietf.org/html/rfc4627 8 http://www.w3.org/XML/ 9 https://github.com/frapi/frapi
22
Samen met Les Kleuver heb ik vervolgens de opzet gemaakt voor de Javascript bibliotheken binnen onze applicatie. Om een zo rijk mogelijke gebruikers ervaring te creëren willen we dat de applicatie waar mogelijk asynchroon werkt. De gebruiker hoeft dan niet elke keer te wachten totdat de volledige pagina opnieuw is geladen. Een nadeel van deze techniek is dat er in de praktijk zeer veel gebruik gemaakt gaat worden van callbacks in de code. Dit kan een nogal onoverzichtelijke brei worden. Met ondersteuning van de JavaScript frameworks Backbone en Requirejs hebben we de opzet zo gemaakt, dat de structuur een stuk overzichtelijker wordt. We hebben ervoor gezorgd dat de routering van de in te laden templates en Javascript bestanden bepaald wordt door dat stukje tekst wat in de URL achter het # teken staat. De zogenaamde dash. Dat stukje tekst achter de dash is de controller. Vanuit dit bestand is goed af te leiden welke view er vervolgens wordt ingeladen. De models binnen het JavaScript framework worden ook op meerdere plaatsen binnen de applicatie gebruikt. Les en Richard van Willigen zijn zich vervolgens begonnen met het werkend maken van de widgets op de pagina’s. Ik heb mij voornamelijk bezig gehouden met de koppeling tussen de AJAX calls van de beheer applicatie en de opslag op de REST server. Ook het ophalen van de gegevens van de REST server valt hier onder. Hier heb ik een speciale helper laag tussen gebouwd die controleert of de gebruiker is ingelogd en die de calls naar de REST server signeert met een API key en een API versleuteling. Deze tussenlaag is ook de netwerk verbinding op socket niveau tussen de serverkant van de beheer applicatie en de REST API server. In de Javascript, waarvan de broncode makkelijk te bekijken is, hoeven we dan niet de API privé sleutel en versleutelingsmethode prijs te geven. Dit is een extra beveiligingsmaatregel die is genomen. Tijdens de implementatie zijn we weinig problemen tegengekomen. Voor een deel komt dit door de dagelijkse meeting van ongeveer tien minuten. Hierin bespraken we de voortgang van de vorige dag. De problemen die iemand was tegengekomen en wat er op deze dag gedaan ging worden. De communicatielijnen bleven hierdoor erg kort. Op deze manier blijven de eventuele problemen ook nooit lang liggen. Er kan gelijk iemand bijspringen of meekijken. Ook is iedereen binnen het team op de hoogte van de totale status van het product. Tijdens de ontwikkeling hebben we ook van een aantal tools gebruik gemaakt. We hebben een Jenkins Continous Integration server. Deze kan de broncode van het versiebeheer systeem uitchecken. Vervolgens kan hij de Unit Tests runnen van de API en de documentatie, uit de broncode genereren. Dit was een extra controle op de werkzaamheden die zijn uitgevoerd. Voor de Javascript hebben we geen gebruik gemaakt van Unit Tests, aangezien de echte logica die business kritiek is, op
23
de REST server wordt gecheckt. Het grootste belangrijkste punt in de JavaScript applicatie is de cross browser werking. Dat blijft toch vooral handwerk.
5.5 Testen De beheerapplicatie wordt op een aantal verschillende manieren getest. Het bijzondere van deze applicatie is dat het een eigen applicatie is. Het is dan ook noodzaak om scherp te blijven kijken naar het eigen product. Het testen van de REST server gebeurd door middel van een suite van Unit Tests. Door het schrijven van een test, wordt van te voren bepaald waar de actie op en de werking van de API aan dient te voldoen. Het systeem wordt in kleine stukjes opgebroken zodat er modulair kan worden getest. De te testen units dienen zo klein mogelijk te zijn. Op deze manier zijn alle onderdelen van de REST server getest. Er zijn testen voor de database laag, voor de interne routering van de URL naar de gewenste resources en er zijn testen voor het interne caching mechanisme. Ook de domein modellen die in de applicatie worden gebruikt zijn testbaar door middel van deze Unit Testen. Deze Unit Tests zijn geschreven op het PHPUnit10 test framework. Dit is het meest uitgebreide test framework binnen de PHP programmeertaal. PHPUnit wordt ook gezien als de PHP tegenhanger van het bekende JUnit, wordt door vele Java ontwikkelaars wordt gebruikt. PHPUnit is ook in staat op Code Coverage rapporten te genereren. Hiermee kan precies achterhaald worden, welke onderdelen van de applicatie niet door een test wordt afgevangen. Er kan op basis daarvan iets worden gezegd over de hoeveelheid geteste code van de applicatie. De HTML en Javascript van de beheer applicatie worden niet door middel van Unit Tests beschreven. Er zijn wel enkele test frameworks voor het testen van Javascript code, maar binnen onze applicatie heeft dit niet veel toegevoegde waarde. De daadwerkelijke gegevens die op het beeldscherm gerepresenteerd worden, komen van de REST server. Ook de wijzigingen en nieuwe gegevens die naar de REST server worden verstuurd worden aan de kant van de REST server nog getest op geldigheid. De enige validaties die in de Javascript applicatie worden gedaan zijn controles op het leeg zijn van een veld, of het hebben van een valide email adres. Dit soort testen zijn te simplistisch om daar een volledig test framework voor op te zetten. Bovendien geldt voor de Javascript dat de weergave en echte fouten in de code waardoor de pagina niet goed wordt weergegeven uitdrukkelijk wordt getest in de handmatige browsertest. 10 http://www.phpunit.de/manual/3.6/en/index.html
24
Naast het testen op de specifieke werking en functionaliteiten van het systeem wordt er binnen Oberon Interactive een interne acceptatie test gedaan. Dit is voor een deel inherent aan onze werkwijze. Binnen de Pivotal Tracker tool, die ons ondersteunt in onze SCRUM aanpak, hebben we de mogelijkheid om een taak op één van de volgende statussen te zetten: •
Gestart
•
Gepauzeerd
•
Afgeleverd
•
Geaccepteerd
•
Afgewezen
Hierbij is dan de volgende werkwijze afgesproken. De ontwikkelaar die op dat moment bezig is met de Javascript implementatie van een bepaalde functie moet de REST API server voor die functionaliteit accepteren. De persoon die de HTML en het ontwerp heeft gemaakt moet dan op zijn beurt de werking van de Javascript functionaliteit accepteren. Als laatste is het de product eigenaar in de persoon van Richard de Boer die de volledige functionaliteit moet accepteren of afwijzen. Het idee hierachter is dat er door meerdere mensen binnen Oberon naar de functionaliteit wordt gekeken. Hierbij is er ook altijd de eis dat de software op meerdere platformen in meerdere verschillende browsers moet werken. Aan het einde van een sprint wordt er dan over alle opgeleverde functionaliteiten een besluit genomen of deze sprint wordt geaccepteerd. Als laatste zal de beheerapplicatie een acceptatietest ondergaan bij onze eerste klant voor dit systeem. Dat is de VVV Friesland. Deze krijgt een account waarmee ingelogd kan worden. Er wordt dan eveneens fictieve data in het systeem gezet. Met deze fictieve data kan de onderneming de applicatie testen. De feedback die wij hier op terugkrijgen zal verwerkt worden. Het kan zijn dat de applicatie hier op wordt aangepast. Het kan ook zijn dat we, aangezien het geen maatwerkpakket is, met goede argumenten deze klant kunnen overtuigen van het waarom we voor deze oplossing hebben gekozen. Nadat de klant akkoord is, zullen alle aangeleverde gegevens worden ingeladen in de applicatie. Vanaf dat moment kunnen de logiesverstrekkers die lid zijn van VVV Friesland inloggen in de applicatie en hun gegevens gaan bijhouden.
5.7 Uitrol De beheer applicatie van Travelbase wordt in verschillende fasen uitgerold. We hebben voor de uitrol twee verschillende omgevingen. We hebben een zogenaamde ‘stage’ omgeving. Hierop kan de
25
klant inloggen om de nieuwste wijzigingen en functionaliteiten te testen. Deze omgeving draait op een eigen database, zodat de gemaakte wijzigingen geen invloed hebben op de productie database. Daarnaast draait de applicatie in de ‘live’ omgeving. Dit is de echte omgeving waar het systeem draait. De beheer applicatie is een compleet nieuwe applicatie, ook voor de klant. In deze applicatie zijn bijzonder veel verschillende functionaliteiten te vinden. Voor het uitrollen hebben de applicatie hebben wij gekozen voor een gefaseerde aanpak, die goed aansluit bij de wensen van de klant. De volgorde van de opgeleverde delen is als volgt: Onderdeel
Omschrijving
Geplande datum
Beheer organisatie
Beheer adresgegevens, foto’s, categorieën
07-‐12-‐2011
Eigendom accommodatie
Beheer adresgegevens, faciliteiten, foto’s
04-‐01-‐2012
Beheer accommodatie
Zelfde als eigendom accommodatie, maar ook
08-‐02-‐2012
beschikbaarheid en prijzen Voor het uitrollen van het systeem hebben we geen geautomatiseerde straat. Voornamelijk heeft dit twee oorzaken. De eerste is dat er momenteel nog weinig servers in het spel zijn. De tweede reden is dat er voor PHP gebaseerde web applicaties een build tool bestaat, Phing11. Echter, tot op dit moment heeft Phing geen ondersteuning voor Mercurial versiebeheer. Dit betekent, dat de Phing build tool niet automatisch de broncode kan uitchecken uit de repository. Een ander issue is dat Phing niet in staat is om na een falende Unit Test, een rollback te doen naar de vorige versie. Wat dan over zou blijven als voordeel van Phing, is dat het in staat is om database delta’s in de database te verwerken. Binnen Oberon hebben wij echter een database vergelijkingstool geschreven die in staat is om een delta SQL te genereren door twee databases te vergelijken. Deze SQL kan vervolgens eenvoudig op de database uitgevoerd worden. Ondanks dat er geen geautomatiseerde uitrol is, hebben we wel een uitrol procedure. De broncode die ‘live’ gezet mag worden krijgt een tag in ons versiebeheersysteem. De broncode die binnen ons versiebeheersysteem Mercurial is opgeslagen, wordt naar de ‘live’ server gepulled. De broncode kan dan naar de gewenste tag worden ge-‐update. Dit gebeurd niet automatisch gelijk na binnenhalen van de broncode. Indien we de REST API server opnieuw uitrollen, herstarten we ook de Apache webserver, om de PHP opcode cache en de APC cache te legen.
11 http://www.phing.info/trac/
26
Voordat er een update actie wordt gedaan is het ook de verantwoordelijkheid van de ontwikkelaar die het systeem ‘live’ zet om te kijken om de Unit Testen nog steeds allemaal groen zijn. Dat wil zeggen dat de Unit Testen niet mogen falen op het systeem.
27
6. Resultaat De beheer applicatie is intern getest en opgeleverd. De hoofdfunctionaliteiten voor het invoeren van de gegevens van Organisaties, Objecten en boekbaarheid zit er in. De testen die op het systeem zijn gedaan zijn interne acceptatie testen en de eerder beschreven Unit Testen. De eerste uitrolfase is ook reeds doorlopen. Voor de klant hebben we de aangeleverde organisaties ingeladen. De klant kan nu in de applicatie de gegevens controleren en waar nodig aanvullen. Dit geldt uiteraard ook voor de achterban, dat wil zeggen de huisjes eigenaren zelf. Op de verschillende computersystemen die binnen Oberon draaien werkt de applicatie zoals deze zou moeten werken. Door de vele kleine calls die gemaakt worden naar de server is de applicatie zeer responsief. Tot nu toe hebben we nog geen vertragingen in het systeem opgemerkt. Ook werkt de applicatie cross-‐platform en cross-‐browser. Wellicht dat er in het ‘wild’ nog enkele configuraties bestaan die niet veel voorkomen en waarvoor nog een aanpassing gedaan dient te worden. Qua visueel ontwerp zijn wij zelf zeer tevreden. De applicatie is wijds opgezet en heeft de kenmerken van de tegenwoordige moderne web applicaties. We hebben hier ook uit het oogpunt van usability naar gekeken. Ontwerp is altijd natuurlijk wel een kwestie ook van smaak. We hebben er ook voor gewaakt om er teveel een visueel ontwerp hoogstandje van de te maken. Volgens ons is het voor de gebruiker van verschillende niveaus een duidelijke heldere applicatie in het gebruik. Plaatsen van de knoppen en de layout hebben we getracht zo consistent en duidelijk mogelijk te maken. Vanuit Oberon zijn we naast de visuele verbetering ook blij op het effect wat we denken te bereiken door de applicatie op deze manier op te zetten. Volgens ons is de applicatie nu veel meer schaalbaar dan de vorige applicatie die we hadden draaien. Ook kunnen we in de toekomst met veel meer gemak andere platformen koppelen met de REST API voor het ontsluiten van de gegevens uit Travelbase. In Bijlage V zijn er enkele screenshots van een aantal onderdelen uit de applicatie bijgevoegd.
28
7. Conclusie Wanneer we kijken naar de broncode die we nu hebben en de opzet die we nu hebben gemaakt voor de applicatie kunnen we wel stellen dat de herstructurering van de applicatie goed is gelukt. De oude applicaties waren per afnemer een kopie van de broncode. Door het inzetten van een REST API server hebben we nu een basis van waaruit we qua business logica werken. Dit geeft ons ook de mogelijkheid om de applicatie steeds op te schalen, aangezien deze laag los staat van de echte representatie laag. Ook is de applicatie nu klaar voor toekomst. Zeker omdat we binnen Oberon verwachten dat mobiele apparaten een steeds grotere vlucht zullen nemen. Door middel van de REST API server zullen we voor allerlei platformen een applicatie kunnen bouwen die volgens de manier van het desbetreffende platform kan verbinden met de server. Zo is het ontsluiten van de informatie naar meerdere platformen/kanalen zeer goed uit te voeren. Door het implementeren van de authenticatie module op de REST API server is er voor gezorgd dat niet iedereen zomaar de informatie uit het systeem kan trekken. Partijen die daar voor ons toegang tot krijgen zullen echter zeker in staat zijn om de informatie op een door hun gewenste manier te ontsluiten. Met betrekking tot de API kunnen hebben we de basis, het raamwerk nu beschikbaar. We kunnen steeds meer calls aan het systeem toevoegen om op deze manier andere applicaties te ontwikkelen. Eén van de eerste applicaties die op dit systeem verder zal worden gebouwd is de zoek en boek applicatie. Op basis van parameters als vertrek, locatie, logie type, verblijfsduur en aantal personen zullen beschikbare objecten worden getoond aan de gebruiker. Hiervoor kunnen dezelfde domein objecten worden gebruikt als voor de beheer applicatie. Voor zulke applicaties geldt ook weer dat er verschillende platformen aan kunnen worden gekoppeld die via JSON zullen communiceren met deze API. De beheerapplicatie is door zijn asynchrone opzet, zeer responsief geworden. De gebruiker hoeft niet steeds te wachten tot een pagina volledig is herladen, maar door middel van asynchrone server calls wordt steeds een stukje informatie in het scherm geladen. Door het aanbrengen van structuur in de JavaScript bibliotheken hebben we gezorgd, dat de broncode nog steeds goed is te onderhouden. Nieuwe functionaliteiten toevoegen op specifieke plekken in de applicatie is geen probleem, aangezien duidelijk is, welk stukje code verantwoordelijk is, voor dat deel van de applicatie. Doordat we nu gebruik maken van de RequireJS bibliotheek kunnen we de JavaScript bestanden gemakkelijk scheiden en hun eigen verantwoordelijkheid geven. Een nadeel hiervan is wel dat de webserver meerdere requests moet afhandelen. RequireJS bezit ook een optimalisatie tool. Hiermee kunnen deze meerdere bestanden samengevoegd worden tot één geheel. Tot nu toe hebben we
29
deze tool nog niet ingezet, wanneer de applicatie door een grotere gebruikersgroep ‘live’ is uitgeprobeerd zullen we dat echter zeker doen. De meeste aanpassingen zullen dan in de loop van de tijd zijn doorgevoerd. Dan wordt optimaliseren een steeds belangrijkere stap. Een andere te nemen vervolgstap op basis van de huidige applicatie kan zijn het overzetten van de database naar een PostgreSQL database zijn. Die database heeft qua schaalbaarheid meer mogelijkheden dan een MySQL database. Door onze huidige ingerichte omgeving hebben we voor echter toch gekozen voor deze MySQL database. Door implementatie van het DataMapper Pattern van Fowler kunnen we relatief makkelijk switchen in de toekomst. Ook hierbij is het handig dat we zoveel mogelijk gebruik hebben gemaakt van standaard SQL syntax. De beslissing wanneer en of we uiteindelijk om zullen gaan naar een PostgreSQL database zal deels van het totale aantal gebruikers gaan afhangen.
30
8. Reflectie Het binnen Oberon Interactive uitgevoerde project had een vast kader. Om de reflectie wat duidelijker weer te geven wil ik dat weergeven door middel van de STARR-‐methode. Hierin kunnen we de Situatie, de Taken, de Acties, het Resultaat en de Reflectie beschrijven.
8.1 Situatie De situatie, zoals eerder in het verslag beschreven is het starten met de ontwikkeling van een nieuwe applicatie om logiesverstrekkers de mogelijkheid te geven hun objecten online boekbaar te maken. Als uitgangspunt is hier een bestaande applicatie genomen, die wordt herschreven naar de nieuwe software standaarden.
8.2 Taken Binnen het project zijn er een aantal taken door mij uitgevoerd. •
Beschrijven / ophelderen van de use cases
•
Vertalen van use cases naar een analyse van een nieuw systeem
•
Maken van een ontwerp voor het systeem
•
Ontwikkelen van het systeem
•
Documenteren van het systeem
8.3 Acties Voor het beschrijven / ophelderen van de use cases heb ik een aantal gesprekken gehad met Richard de Boer. Dat is binnen Oberon degene met de meeste achtergrond op het gebied van de boekingssoftware. Naar aanleiding van deze gesprekken zijn de use cases steeds duidelijker geworden en uiteindelijk beschreven in het use case document (zie Bijlage III). Voor mij was het belangrijk om op dit moment inzicht te krijgen in de functionaliteiten die horen bij deze nieuwe applicatie. Ook de verschillen tussen de bestaande applicatie en de nieuwe applicatie werden hier duidelijk. Naar aanleiding van de use cases zijn we begonnen met het maken van een analyse voor het nieuwe systeem. Op basis van de in de use cases beschreven entiteiten hebben we kunnen zien welke
31
objecten er binnen het systeem erg belangrijk zijn. Deze hebben we vervolgens in een klasse diagram en een database schema gegoten. Na het maken van de analyse heb ik een voorstel gedaan voor de topologie van de totale applicatie. In overleg hebben we besloten om een REST API server te ontwikkelen en hier vervolgens de verschillende applicaties aan te koppelen. Dit gaf ons het gevoel om zowel schaalbaar te blijven en ook om het systeem voor te bereiden op de toekomst, met meerdere platformen. Binnen het team werd deze conclusie gelijk breed gedragen. Alleen met het punt beveiliging zijn we even bezig geweest. Hier hebben we verschillende manieren voor onderzocht, omdat we de REST API server niet zonder meer naar buiten willen openzetten. Vervolgens zijn we binnen het team begonnen met de implementatie van de REST server en van de HTML. Op de HTML kant hebben we een aantal nieuwe technieken losgelaten die ervoor zorgen dat de verantwoordelijkheden per stukje broncode goed zijn gescheiden. Tijdens het ontwikkelen heb ik vooral met Les Kleuver nog wel discussie gehad over de manier waarop we beheerapplicatie zouden koppelen met de REST server. Les wilde graag alles aan de JavaScript kan houden. Zelf wilde ik met betrekking tot de beveiliging van de calls er een dunne laagje op de server tussen zetten. Dit omdat ik niet wilde dat de private key via de JavaScript achterhaald kon worden door gebruikers. Uiteindelijk was Les dit ook met mij eens. Tijdens het ontwikkelen van de beheer applicatie bleken we overigens binnen het team allemaal op één lijn te zitten. Dit nieuwe systeem moet uiteraard ook worden gedocumenteerd. Er bestaat een zekere mate van documentatie in de code van de applicatie. Tijdens het schrijven van de software wordt gebruik gemaakt van commentaren in de broncode die door middel van de tool phpDocumenter kunnen worden verwerkt als documentatie. Mijn rol hierin was vooral het documenteren van mijn code en zorgen dat de andere teamleden dat ook deden.
8.4 Resultaat Het resultaat van de in de vorige paragraaf beschreven acties zijn de klassendiagrammen, het database ontwerp en ook de uiteindelijk geïmplementeerde applicaties. De uitwerking van de gekozen oplossingen zoals de REST API en de losse beheerapplicaties is goed gelukt. De onderdelen zijn ook daadwerkelijk opgeleverd en worden nu ingezet bij een de achterban van de klant, zodat die hun informatie in het systeem kunnen gaan aanvullen.
32
8.5 Reflectie Tijdens de discussies binnen het team over de richting van de nieuwe applicaties bleken we het behoorlijk met elkaar eens te zijn. Af en toe waren er wat kleine verschillen van over specifieke implementaties, maar met de discussies hierover hielden we elkaar scherp en zijn we uiteindelijk tot de beste oplossing gekomen. Vooral de manier waarop we de API zouden beveiligen hebben we uitvoerig doorgenomen. Met betrekking tot de applicatie was het in het begin lastig dat ik net nieuw ben komen werken bij Oberon, speciaal voor dit project. Ik had ook geen verdere domein kennis van vakantiehuisjes en de verhuur daarvan. In de beginperiode heb ik mij die achtergrond ook echt eigen moeten maken. Hiervoor heb ik een aantal overleg sessies gehad met Richard de Boer. Dit heeft zeer verhelderend gewerkt. Verder is Oberon een relatief klein bedrijf, zodat terugkoppeling op de werkvloer ook behoorlijk makkelijk is. Hierdoor heb ik toch relatief snel mijn domeinkennis kunnen opvijzelen. Een behoorlijke dosis domeinkennis komt zeker ook van pas bij de analyse fase. Daarin hebben we toch de hoofdobjecten binnen het systeem boven water gekregen. Hiervoor heb ik eerst zelf een opzet gemaakt. Deze hebben we later nog binnen het team uitvoerig besproken. Zo hebben we voorkomen dat er kleine, maar toch belangrijke puntjes binnen de analyse zijn weggelaten. Voor het opzetten van de REST API ben ik voornamelijk uitgegaan van de ervaringen die ik in de afgelopen jaren heb opgedaan als programmeur. De uiteindelijke response in JSON van de server heb ik steeds doorgesproken met het teamlid wat op dat moment bezig was met de HTML applicatie. We hebben steeds geprobeerd om ervoor te zorgen dat de calls op tijd opgeleverd waren, zodat ophalen en opslaan snel lukte. Deze manier van samenwerken verliep erg vlotjes. Voor de HTML applicatie hebben we een aantal nieuwe JavaScript bibliotheken gebruikt. Hierdoor hebben we bepaalde onderdelen van de applicatie behoorlijk gerefactored. We zijn wel achtergebleven met de documentatie van de broncode. Dat is een punt dat we nu nog moeten oppakken en bijwerken. Gelukkig is de naamgeving van de functies en variabelen wel duidelijk genoeg dat de werking van deze functies niet lastig is te achterhalen. Wat we achteraf wat beter hadden kunnen doen is het nadenken over het design en de flow van de applicatie. We zijn behoorlijk snel begonnen met de bouw van de applicaties. We hadden hiervoor ook al snel wireframes beschikbaar. Alleen het omzetten van de wireframes naar een echt visueel ontwerp hebben we te laat opgepakt. Ook hebben we latere aanpassingen aan de use cases niet doorgevoerd in de wireframes. Hierdoor zijn tijdens het ontwikkelen van de HTML applicatie af en toe wat gaten ontstaan. Zo moest er nog een definitief ontwerp komen voor formuliervelden en is af
33
en toe de flow van de applicatie toch wat aangepast. De volgende keer moeten we dit van te voren beter en eerder oppakken.
34
Bijlage I Use Case Diagram: In deze bijlage een overzicht van de Use Cases die door een eigenaar en/of een beheerder van een object kunnen worden uitgevoerd. Voor de duidelijkheid hebben we in de afbeelding alleen de nummering aangehouden zoals hieronder gedefinieerd. Use Case nummer
Beschrijving
BU1
Toegang tot de beheer applicatie
BU2
Wachtwoord wijzigen
BU3
Eigen gegevens wijzigen
BU4
Organisatiegegevens inzien
BU5
Organisatie algemene gegevens wijzigen
BU6
Accommodatie gegevens inzien
BU7
Accommodatie algemene gegevens wijzigen
BU8
Locatie wijzigen van accommodatie of accommodatiegroep
BU9
Foto’s wijzigen van een accommodatiegroep of accommodatie
BU10
Opties wijzigen
BU11
Toeslagen wijzigen
BU12
Kenmerken wijzigen
BU13
Wachtwoord vergeten
BU14
Boekbaarheidsgegevens accommodatie bekijken
BU15
Beschikbaarheid accommodatie wijzigen
BU16
Standaardboekbaarheidsgegevens accommodatie wijzigen
BU17
Boekbaarheidsgegevens accommodatie wijzigen
35
36
Bijlage II Use Cases: Toegang tot de beheer applicatie (B.U1) Samenvatting
Een gebruiker verschaft zich toegang tot de gegevens van de accommodaties die onder zijn beheer vallen.
Rollen
Beheerder, Eigenaar
Uitgangspunt
De gebruiker heeft een account
Omschrijving
-‐
De beheerder gaat naar het webadres
-‐
De beheerder vult zijn loginnaam of e-‐ mailadres in
-‐
De beheerder vult verborgen zijn wachtwoord in
-‐
De beheerder geeft aan of hij ingelogd wilt blijven
-‐ Uitzonderingen
De beheerder klikt op inloggen
De beheerder weet zijn logingegevens niet:
De beheerder klikt op ‘Hoe log ik in?’ en heeft daar de mogelijkheid op basis van zijn e-‐mailadres zijn wachtwoord op te vragen of via een formulier een vraag te stellen (aan Travelbase of regionale organisatie) Wachtwoord wijzigen (B.U2) Samenvatting
De gebruiker wil het wachtwoord waarmee hij inlogt in de beheer applicatie wijzigen.
Rollen
Beheerder, Eigenaar
Uitgangspunt
De gebruiker is ingelogd in de beheer applicatie (B.U1).
Omschrijving
1. De gebruiker klikt op wachtwoord wijzigen en komt op de wachtwoord
37
wijzigen pagina. 2. De gebruiker vult verborgen zijn huidige wachtwoord in. 3. De gebruiker vult verborgen zijn nieuwe wachtwoord in. 4. Tijdens het typen ziet de gebruiker of het nieuwe wachtwoord voldoet aan de eisen: minimaal 6 karakters 5. De gebruiker krijgt feedback over de kwaliteit van het wachtwoord 6. De gebruiker vult verborgen nogmaals zijn nieuwe wachtwoord in. 7. De gebruiker klikt op bevestigen. 8. De gebruiker krijgt de melding dat het wachtwoord is gewijzigd en dat hij wordt doorverwezen naar de inlogpagina om opnieuw in te loggen. 9. De bestaande instellingen voor altijd ingelogd blijven worden gewist. 10. De gebruiker wordt doorverwezen naar de login pagina. Uitzonderingen
Het oude wachtwoord is onjuist: De gebruiker krijgt de melding dat het oude wachtwoord onjuist is en wordt doorverwezen naar de wachtwoord wijzigen pagina. De nieuwe wachtwoorden zijn ongelijk: De gebruiker krijgt de melding dat de nieuwe wachtwoorden ongelijk zijn en wordt doorverwezen naar de wachtwoord wijzigen pagina.
Eigen gegevens wijzigen (B.U3) Samenvatting
De gebruiker wil zijn eigen gegevens wijzigen. Hieronder vallen o.a. e<mailadres,
38
NAW, rekeningnummer en zakelijke gegevens. Rollen
Beheerder, eigenaar
Uitgangspunt
De gebruiker is ingelogd in de beheers applicatie (B.U1).
Omschrijving
1. De gebruiker klikt op mijn account en komt op de pagina waar de eigen gegevens getoond worden waar hij per onderdeel (algemeen, contact, NAV, financieel, etc.) op wijzigen kan klikken. 2. De gebruiker klikt op wijzigen van een van de onderdelen. 3. De gebruiker kan de gegevens aanpassen. 4. De gebruiker klikt op opslaan. 5. De gebruiker krijgt de melding dat de gegevens zijn opgeslagen en komt weer in het mijn account scherm.
Uitzonderingen
De ingevulde gegevens voldoen niet: De gebruiker krijgt de melding welke gegevens niet voldoen en kan verder gaan met aanpassen. De beheerder wil wijzigen afbreken: De gebruiker klikt op annuleren tijdens het wijzigen en komt terug in het mijn account scherm zonder dat de wijzigingen zijn toegepast.
Organisatiegegevens inzien (B.U4) Samenvatting
De beheerder wil de gegevens van een organisatie (algemene gegevens van een aantal accommodaties, zoals hotel of vakantiepark) inzien.
Rollen
Beheerder 39
Uitgangspunt
De beheerder is ingelogd in de beheer applicatie (B.U1) en heeft minimaal één organisatie onder zijn beheer.
Omschrijving
1. De beheerder klikt op accommodaties. 2. De beheerder ziet een overzicht van alle accommodaties onder zijn beheer. Alle accommodaties worden aangeduid met de naam, de hoofdfoto en een visuele indicatie van de beschikbaarheid in de huidige maand. Indien accommodaties in een accommodatiegroep vallen worden deze daarbij gegroepeerd. Bij een accommodatiegroep wordt de naam en hoofdfoto getoond. De beheerder klikt op de accommodatiegroep. 3. De beheerder ziet de gegevens van de organisatie opgedeeld in onderdelen (adres, locatie, omschrijving, foto’s, openingstijden, faciliteiten, opties en toeslagen). Indien de beheerder het beheer heeft over de organisatie kan hij op wijzigen klikken per onderdeel.
Organisatie algemene gegevens wijzigen (B.U5) Samenvatting
De beheerder wil de algemene gegeven van een organisatie wijzigen.
Rollen
Beheerder
Uitgangspunten
De beheerder zit op de organisatie gegevens pagina (B.U4).
Omschrijving
1. De beheerder klikt op de wijzigen knop bij de gegevens die hij wil wijzigen. 2. De beheerder kan de gegevens aanpassen.
40
3. Indien de gegevens in meerdere talen moet worden ingegeven kan hij voor onbekende talen een vertaling opvragen (via Google translate API) op basis van de Nederlandse gegevens, maar krijgt daarbij de melding dat de vertaling mogelijk van slechte kwaliteit is. 4. De beheerder klikt op opslaan. 5. De beheerder krijgt de melding dat de gegevens zijn opgeslagen en komt weer op de accommodatiegroep gegevens pagina. Uitzonderingen
De ingevulde gegevens voldoen niet: De beheerder krijgt de melding welke gegevens niet voldoen en kan verder gaan met aanpassen. De beheerder wil wijzigen afbreken: De beheerder klikt op annuleren tijdens het wijzigen en komt terug op de accommodatiegroep pagina zonder dat de wijzigingen zijn toegepast. De gegevens voor vreemde talen zijn niet ingegeven: De vertalingen worden automatisch opgehaald (via Google translate API) en de beheerder krijgt de melding dat de vertalingen zijn gevuld, maar mogelijk van slechte kwaliteit zijn.
Accommodatie gegevens inzien (B.U6) Samenvatting
De gebruiker wil de gegevens van een accommodatie inzien.
Rollen
Beheerder, Eigenaar
41
Uitgangspunt
De gebruiker is ingelogd in de beheer applicatie (B.U1) en heeft minimaal één accommodatie onder zijn beheer.
Omschrijving
1. De gebruiker klikt op accommodaties. 2. De gebruiker ziet een overzicht van alle accommodaties onder zijn beheer. Alle accommodaties worden aangeduid met de naam, de hoofdfoto en een visuele indicatie van de beschikbaarheid in de huidige maand. Indien accommodaties in een accommodatiegroep vallen worden deze daarbij gegroepeerd. Bij een accommodatiegroep wordt de naam en hoofdfoto getoond. De beheerder klikt op de accommodatie. 3. De gebruiker ziet de gegevens van de accommodatie opgedeeld in onderdelen (adres, locatie, omschrijving, foto’s, sleuteladres, openingstijden, faciliteiten, opties, toeslagen en kortingen). De gegevens die de accommodatie mogelijk erft van de accommodatiegroep worden wel getoond, maar zijn niet te wijzigen. Hij kan op wijzigen klikken per onderdeel.
Accommodatie algemene gegevens wijzigen (B.U7) Samenvatting
De gebruiker wil de algemene gegeven van een accommodatie wijzigen.
Rollen
Beheerder, Eigenaar
Uitgangspunten
De gebruiker is ingelogd in de beheer applicatie (B.U1) en heeft minimaal één Accommodatie-‐ of accommodatie groep onder
42
zijn beheer. Omschrijving
1. De gebruiker klikt op de wijzigen knop bij de gegevens die hij wil wijzigen. 2. De gebruiker kan de gegevens aanpassen. 3. Indien de gegevens in meerdere talen moet worden ingegeven kan hij voor onbekende talen een vertaling opvragen (via Google translate API) op basis van de Nederlandse gegevens, maar krijgt daarbij de melding dat de vertaling mogelijk van slechte kwaliteit is. 4. De gebruiker klikt op opslaan. 5. De gebruiker krijgt de melding dat de gegevens zijn opgeslagen en komt weer op de accommodatie gegevens pagina.
Uitzonderingen
De ingevulde gegevens voldoen niet: De gebruiker krijgt de melding welke gegevens niet voldoen en kan verder gaan met aanpassen. De beheerder wil wijzigen afbreken: De gebruiker klikt op annuleren tijdens het wijzigen en komt terug op de accommodatie pagina zonder dat de wijzigingen zijn toegepast. De gegevens voor vreemde talen zijn niet ingegeven: De vertalingen worden automatisch opgehaald (via Google translate API) en de beheerder krijgt de melding dat de vertalingen zijn gevuld, maar mogelijk van slechte kwaliteit zijn.
43
Locatie wijzigen van accommodatie of accommodatiegroep (B.U8) Samenvatting
De gebruiker wil de locatie wijzigen bij een accommodatie of accommodatiegroep.
Rollen
Beheerder, Eigenaar
Uitgangspunten
De gebruiker zit op de accommodatie of accommodatiegroep gegevens pagina (B.U4 of B.U6).
Omschrijving
1. De gebruiker klikt op de wijzigen knop voor het wijzigen van de locatie. 2. De gebruiker ziet een kaart met daarop een pin bij de huidige locatie (of de locatie van het dorp als er geen locatie is ingesteld). 3. De gebruiker kan de pin verplaatsen. 4. De gebruiker kan de kaart besturen (zoom, etc.) 5. De gebruiker klikt op opslaan om de nieuwe locatie te bevestigen.
Uitzonderingen
De kaart laadt niet De gebruiker krijgt de melding dat het wijzigen van de locatie momenteel niet mogelijk is en krijgt de mogelijkheid om ‘support’ te vragen.
Foto’s wijzigen van een accommodatiegroep of accommodatie (B.U9) Samenvatting
De gebruiker wil de foto’s wijzigen bij een accommodatie of accommodatiegroep.
Rollen
Beheerder, Eigenaar
Uitgangspunten
De gebruiker zit op de accommodatie< of groep gegevens pagina (B.U4 of B.U6).
Omschrijving
1. De gebruiker klikt op de wijzigen knop voor het wijzigen van de foto’s. 2. De gebruiker kan nu de volgorde van
44
de foto’s wijzigen door deze te slepen. 3. De gebruiker kan een foto verwijderen door op verwijderen te klikken. 4. De gebruiker kan de titel van de foto aanpassen (in verschillende talen). 5. De gebruiker kan een nieuwe foto (max 10) toevoegen door deze te uploaden en de titel in te geven. Uitzonderingen
Het bestand dat is geüpload is onjuist De gebruiker krijgt de melding dat het bestand onjuist is en krijgt de aanleverspecificaties te zien. De gegevens voor vreemde talen zijn niet ingegeven De vertalingen worden automatisch opgehaald (via Google translate API) en de gebruiker krijgt de melding dat de vertalingen zijn gevuld, maar mogelijk van slechte kwaliteit zijn.
Opties wijzigen (B.U10) Samenvatting
De gebruiker wil de opties wijzigen bij een accommodatie of accommodatiegroep.
Rollen
Beheerder, Eigenaar
Uitgangspunten
De gebruiker zit op de accommodatie of accommodatiegroep gegevens pagina (B.U4 of B.U6).
Omschrijving
1. De gebruiker klikt op de wijzigen knop voor het wijzigen van de opties. 2. De gebruiker ziet alle opties die er zijn met bij reeds ingestelde opties de periodes waarvoor ze gelden en welk tarief is ingesteld. Opties hebben een naam en een tariefstructuur (per dag,
45
per persoon, etc.). 3. De gebruiker kan een periode dat een optie geldt verwijderen door op verwijderen te klikken. 4. De gebruiker kan de periode, het tarief en het te kiezen aantal van een optie aanpassen. 5. De gebruiker kan een optie laten gelden door daarbij een nieuwe periode aan te maken en daarbij het tarief en het te kiezen aantal in te geven. Uitzonderingen
De periode overlapt met een andere periode bij de accommodatie De gebruiker krijgt een melding dat er een overlap is met de vraag om de laatst ingevoerde leidend te laten zijn. Als de gebruiker ja klikt, dan worden de andere periodes die overlappen ingekort om het sluitend te maken. Als de gebruiker nee klikt, wordt de nieuwe periode ingekort (en/of opgeknipt) om sluitend te maken. Overlap in periodes is niet mogelijk. De periode overlapt met een andere periode bij de accommodatiegroep De gebruiker krijgt bij het invoeren voor een accommodatie een melding dat er een overlap is met een optie die is ingesteld in de accommodatiegroep en dat deze altijd leidend zijn en niet kunnen worden overschreven.
Toeslagen wijzigen (B.U11) Samenvatting
De gebruiker wil de toeslagen wijzigen bij een accommodatie of accommodatiegroep.
46
Rollen
Beheerder, Eigenaar
Uitgangspunten
De beheerder zit op de accommodatie of accommodatiegroep gegevens pagina (B.U4 of B.U6).
Omschrijving
1. De gebruiker klikt op de wijzigen knop voor het wijzigen van de toeslagen. 2. De gebruiker ziet alle toeslagen die er zijn met bij reeds ingestelde toeslagen de periodes waarvoor ze gelden en welk tarief is ingesteld. Toeslagen hebben een naam en een tariefstructuur (per dag, per persoon, etc.). 3. De gebruiker kan een periode dat een toeslag geldt verwijderen door op verwijderen te klikken. 4. De gebruiker kan de periode, het tarief en het te kiezen aantal van een toeslag aanpassen. 5. De gebruiker kan een toeslag laten gelden door daarbij een nieuwe periode aan te maken en daarbij het tarief en het te kiezen aantal in te geven.
Uitzonderingen
De periode overlapt met een andere periode bij de accommodatie De gebruiker krijgt een melding dat er een overlap is met de vraag om de laatst ingevoerde leidend te laten zijn. Als de gebruiker ja klikt, dan worden de andere periodes die overlappen ingekort om het sluitend te maken. Als de gebruiker nee klikt, wordt de nieuwe periode ingekort (en/of opgeknipt) om sluitend te maken. Overlap in periodes is niet mogelijk. De periode overlapt met een andere periode
47
bij de accommodatiegroep De gebruiker krijgt bij het invoeren voor een accommodatie een melding dat er een overlap is met een toeslag die is ingesteld in de accommodatiegroep en dat deze altijd leidend zijn en niet kunnen worden overschreven. Kenmerken wijzigen (B.U12) Samenvatting
De gebruiker wil de kenmerken, ook wel faciliteiten van een organisatie of accommodatie wijzigen
Rollen
Beheerder / Eigenaar
Uitgangspunten
De gebruiker zit op de accommodatie of organisatie wijzig pagina
Omschrijving
1. De gebruiker klikt op de knop voor het wijzigen van de kenmerken 2. De gebruiker ziet alle beschikbare en reeds ingestelde kenmerken, een kenmerk kan een ja/nee of een invulwaarde hebben (bijv douche ja, oppervlakte 20m2) 3. De gebruiker kan reeds ingestelde kenmerken wijzigen 4. De gebruiker kan ingestelde kenmerken verwijderen door ze uit vinken of nieuwe kenmerken toevoegen door ze aan te vinken
Uitzonderingen
Wachtwoord vergeten (B.U13) Samenvatting
De beheerder/eigenaar, is zijn wachtwoord kwijt en wil een nieuw wachtwoord
48
ontvangen Rollen
Beheerder, Eigenaar
Uitgangspunten
De beheerder/eigenaar is niet ingelogd in de applicatie
Omschrijving
1. De gebruiker klikt op wachtwoord vergeten 2. De gebruiker vult zijn emailadres in 3. Het systeem controleert het emailadres 4. Het systeem genereert een nieuw wachtwoord 5. Het systeem slaat het wachtwoord op 6. Het systeem stuurt een email met het nieuwe wachtwoord naar de gebruiker
Uitzonderingen
Het opgegeven email adres bestaat niet De gebruiker krijgt de melding dat het email adres niet bekend is bij het systeem De SMTP server werkt niet De gebruiker krijgt een melding dat de service momenteel niet beschikbaar is
Boekbaarheidsgegevens accommodatie bekijken (B.U14) Samenvatting
De gebruiker bekijkt de ingestelde waarden per week. Hier is een overzicht te zien van de beschikbaarheid per, of aankomst mogelijk is, of vertrek mogelijk is en de prijs per nacht
Rollen
Beheerder/Eigenaar
Uitgangspunten
De pagina start met het overzicht van de huidige week, met navigatie mogelijkheden naar andere weken
Omschrijving
1. De gebruiker navigeert naar de week waarvan hij de gegevens wilt bekijken 2. De gebruiker ziet detailinformatie van de prijs, het hoeveelheid eenheden
49
beschikbaar per accommodatie per dag, of aankomst mogelijk is en of vertrek mogelijk is Uitzonderingen
De beheerder heeft meer bewerkingsmogelijkheden dan de eigenaar. De eigenaar heeft alleen mogelijkheden om de beschikbaarheid te wijzigen. De beheerder kan hier alle gegevens aanpassen.
Beschikbaarheid accommodatie wijzigen (B.U15) Samenvatting
De gebruiker kan per dag, of over een aangegeven periode de beschikbare hoeveelheid (in eenheden) van een accommodatie wijzigen
Rollen
Beheerder/Eigenaar
Uitgangspunten
De gebruiker zit op de beschikbaarheidoverzicht pagina (B.U14)
Omschrijving
1. De gebruiker klikt op de link om de beschikbaarheid over een periode te wijzigen 2. De gebruiker ziet een popup waarin een einddatum en een begindatum geselecteerd kan worden. Ook de toe te passen beschikbaarheid 3. De gebruiker klikt op toepassen 4. Het systeem veranderd de beschikbaarheid over de aangegeven periode 5. De gebruiker veranderd de beschikbaarheid op 1 specifieke dag, door op de plus, de min te klikken of een nieuw getal in te voeren 6. Het systeem slaat deze wijziging direct op
50
Uitzonderingen
De Eigenaar ziet in dit scherm minder informatie dan de beheerder
Standaardboekbaarheidsgegevens accommodatie wijzigen (B.U16) Samenvatting
De gebruiker kan hier de standaard boekbaarheids gegevens invullen. Hier wordt aangegeven op welke weekdag aankomst en vertrek mogelijk is. Ook kan worden aangegeven wat de prijs per weekdag is.
Rollen
Beheerder
Uitgangspunten
De gebruiker zit op de beschikbaarheidoverzicht pagina (B.U14)
Omschrijving
1. De gebruiker klikt op de link, standaardgegevens aanpassen 2. Er komt een popup te voorschijn, met per weekdag een invulveld voor prijs, een vinkje voor aankomst mogelijk en een vinkje voor vertrek mogelijk 3. De gebruiker klikt op opslaan 4. Het systeem slaat de gegevens op en sluit de popup
Uitzonderingen
Boekbaarheidsgegevens accommodatie wijzigen (B.U17) Samenvatting
De gebruiker kan per dag of per periode de prijs en de aankomst en vertrekdagen van een accommodatie aanpassen om de standaard gegevens te overschrijven
Rollen
Beheerder
Uitgangspunten
De Beheerder zit op de beschikbaarheidoverzicht pagina (B.U14)
Omschrijving
1. De gebruiker navigeert naar de dag waarvan deze de gegevens wilt
51
wijzigen 2. De gebruiker vinkt de aankomst mag aan of uit 3. Het systeem slaat dit direct op 4. De gebruiker vinkt vertrek mag aan of uit 5. Het systeem slaat dit direct op 6. De gebruiker vult een prijs in voor een bepaalde dag 7. Het systeem slaat dit direct op 8. De gebruiker klikt op prijs voor periode wijzigen 9. Het systeem toont een popup, waarin de gebruiker de start datum, de einddatum en een prijsinvoerveld toont 10. De gebruiker vult de gegevens in en drukt op opslaan 11. Het systeem slaat de gegegevens op 12. De gebruiker klikt op aankomst of vertrekdag voor een periode wijzigen 13. Het systeem toont een popup, waarin de gebruiker de start en einddatum kan selecteren. Per weekdag vinkt de gebruiker vertrek en/of aankomst mogelijk en drukt op opslaan 14. Het systeem voert de gegevens door voor de aangegeven periode Uitzonderingen
52
Bijlage III: Klassen diagram
53
54
Bijlage IV Database schema In deze bijlage wordt het database schema van Travelbase weergegeven. Hierbij moeten een aantal opmerkingen worden geplaatst. Zoals te zien in het schema is er een Translation tabel en een TranslationEntry tabel. Middels deze tabellen wordt er bepaald wat de tekst van de kolommen beschrijving van een organisatie is per taal. Datzelfde geldt voor bijvoorbeeld de faciliteiten. Wanneer al deze relaties in dit schema zouden worden getoond, zou het schema te onoverzichtelijk worden.
55
Bijlage V Schermen van de applicatie
Het inlogscherm van de beheerapplicatie, waar gebruikers kunnen inloggen.
56
Het dashboard waar de gebruiker zijn Ondernemingen en Accommodaties kan bekijken. Hier ziet de gebruiker gelijk welke objecten aan zijn account zijn gekoppeld.
Het scherm waarin de gebruiker een detailoverzicht ziet van een object.
Via dit scherm kan een gebruiker zijn gegevens wijzigen.
57
Media toevoegen kan via een popup.
Hier ziet de gebruiker het overzicht van de beschikbaarheid en de prijzen die bij een bepaalde dag hoort. De gebruiker kan via dit scherm ook de aanpassingen maken.
58
Literatuur Mike O’Doherty (2005). Object-‐Oriented Analysis & Design. West Sussex: John Wiley & Sons ltd. Ian Sommerville, (2007). Software Engineering. Essex: Pearson Education Limited
59
