Prijs invoerapplicatie voor reisgidsen

Eindverslag

Auteur: Jeroen van de Merwe, 98003298
Periode:  2001-1
Datum: 22 juni 2001

Referaat

Merwe van de, Jeroen, Prijs-invoerapplicatie voor reisgidsen,
Rotterdam: Ezooka.com / Cipix, juni 2001

Dit document is de eindrapportage van de afstudeerperiode van Jeroen van de Merwe in het kader van de studie 'Informatievoorziening en Informatietechnologie' aan de Haagse Hogeschool. Het beschrijft het proces van het uitvoeren van het project "Prijs-invoerapplicatie voor reisgidsen" uitgevoerd bij Ezooka.com / Cipix te Rotterdam in de periode 2001-1.

De opdracht omvatte het maken van een invoerapplicatie voor reisgidsen, zodat de prijzen van de meeste reisgidsen in één database opgeslagen konden worden. Deze database kon dan vervolgens gebruikt worden door een vakantievergelijk website.

Prijs-invoerapplicatie voor reisgidsen

Stagiair

Naam:                  J. van de Merwe

Bedrijf

Naam:                  Ezooka.com / Cipix
Stagebegeleider:    Dhr. T. Schulten

Haagse Hogeschool
Sector Informatica 
Opleiding Informatievoorziening en Informatietechnologie (IVIT)
Afstudeerrichting MBIT
Examinator Dhr. T.H.M. Spaan
Assessor Dhr. B. van Strien

Descriptoren:

Voorwoord

Graag wil ik iedereen bedanken die het voor mij mogelijk hebben gemaakt mijn afstudeerperiode tot een goed einde te brengen:

Rotterdam, 21 juni 2001
Jeroen van de Merwe


Inhoud

Inleiding. 5

1     Bedrijfsbeschrijving Ezooka.com. 6

2     De opdracht 7

2.1     De probleemstelling. 7

2.2     De doelstelling van het project 7

2.3     Uitgangssituatie van mijn project 7

2.4     De huidige prijs-invoerapplicatie. 8

3     Het Plan van Aanpak 10

3.1     Uit te voeren activiteiten. 10

3.2     Methoden en technieken. 10

3.3     De planning. 11

3.4     De tussenproducten. 11

3.5     Welke eisen worden er aan de producten gesteld? 11

3.6     De risico's die zich kunnen voordoen. 12

3.7     De leden van de projectgroep. 12

3.8     De verantwoordelijkheden. 12

3.9     De bijeenkomsten. 13

4     Analyse van de prijssystematiek 14

5     Het Functioneel Ontwerp. 16

5.1     Afbakening van het product 16

5.2     De tussenproducten. 16

5.3     Het document Functioneel Ontwerp. 16

6     Het Technisch Ontwerp. 22

6.1     Normalisatie van de gegevens 22

6.2     Bachmandiagram. 23

6.3     Wintervervoer inventarisatie. 23

6.4     Gedetailleerd klassediagram. 23

6.5     Implementatie van het nieuwe databasediagram. 24

7     Het realiseren van de applicatie. 27

7.1     Aangepaste planning. 27

7.2     De implementatie van het ontwerp. 27

8     Evaluatie. 30

8.1     Procesevaluatie. 30

8.2     Productevaluatie. 30

Conclusie. 32

Bijlage 1: Literatuurlijst 33

Bijlage 2: Figurenlijst 34

Externe bijlage 1: Analyserapport van de reisgidsen

Externe bijlage 2: Het Functioneel Ontwerp

Externe bijlage 3: Het Technisch Ontwerp


Inleiding

Dit eindverslag beschrijft mijn afstudeerperiode van 12 februari t/m 22 juni.
Het verslag dient de lezer inzicht te geven in mijn opdracht, mijn aanpak van de werkzaamheden en de omvang van de opdracht.
In deze beschrijving komen alle doorlopen fasen aan bod en welke producten deze hebben opgeleverd.

Dit verslag is als volgt opgebouwd:

Eerst wordt het bedrijf beschreven waar ik mijn afstudeerperiode heb doorlopen. Daarna komt mijn opdracht aan bod die ik uitgevoerd heb bij Ezooka.com / Cipix.

Voor deze opdracht heb ik aan het begin een Plan van Aanpak(hoofdstuk 3 ) gemaakt waarin ik, voor zover mogelijk, alle taken en werkzaamheden heb geïnventariseerd en een planning gemaakt voor die taken en werkzaamheden.

Aan de hand van het Plan van Aanpak, ben ik begonnen aan de reisgidsanalyse(hoofdstuk 4 ). Van het resultaat hiervan worden in dit verslag een aantal voorbeelden gegeven.

Met behulp van deze analyse, ben ik daarna begonnen aan de use-cases in het Functioneel Ontwerp(hoofdstuk 5 ). Met behulp van deze use-cases, heb ik samen met de andere afstudeerder John van Terheijden, een concept klassediagram gemaakt.

Het concept klassediagram hebben we vervolgens uitgewerkt tot het definitieve klassediagram in het Technisch Ontwerp(hoofdstuk 6 ). Na wat problemen met de relaties in het definitieve klassediagram, zijn we begonnen aan het databaseontwerp. Hiervan is daarna ook een bachmandiagram gemaakt.

Met behulp van het Technisch Ontwerp, ben ik begonnen aan de realisatie(hoofdstuk 7 ) van mijn prijzen-invoerapplicatie.

Hierna evalueer(hoofdstuk 8 ) ik mijn afstudeerperiode, door te kijken of ik alle doelstellingen uit mijn Plan van Aanpak gehaald heb, welke eventueel niet en de reden dat ik die niet af zou hebben. Verder beschrijf ik nog of alles gegaan is zoals ik aan het begin had bedacht.

Als laatste zit er achterin het verslag nog een figurenlijst, een bronvermelding en een besluitenlijst van besluiten die tijdens het Functioneel- en Technisch Ontwerp genomen zijn.


1      Bedrijfsbeschrijving Ezooka.com

Ezooka.com is een Internet-bedrijf dat is gevestigd in Rotterdam (www.ezooka.com). Ezooka.com is begonnen in 1999 met drie werknemers. Nu werken er 20 mensen, waarvan 7 stagiair(e)s. Ezooka.com ontwikkelt op dit moment applicaties voor het ministerie van Defensie, OC&W en anderen, en doet daar aan netwerk- en systeembeheer. Ook ontwikkelen ze een Website voor de betonindustrie waar kennis uitgewisseld kan worden. Ezooka.com heeft ook al kleine Websites en urenregistratiesystemen ontwikkeld. Ook ontwikkelt Ezooka.com applicaties op basis van contact+, een programma voor adressen- en documentbeheer.
Sinds enige tijd begeeft Ezooka.com zich op de reismarkt.

Tijdens mijn afstudeertraject, is er een scheiding aangebracht in de activiteiten. Alles is gesplitst in twee groepen:

Alle travelactiviteiten worden voortgezet onder de naam Ezooka.com, de ICT-activiteiten worden onder de naam Cipix uitgevoerd. Mijn invoerapplicatie is in opdracht van Ezooka.com gemaakt door Cipix.

In sommige hoofdstukken wordt daarom gesproken over Ezooka.com, omdat deze stukken eerder geschreven zijn dan dit eindverslag. Dit betreft met name de Opdrachtomschrijving en het Plan van Aanpak.


2      De opdracht    

Het vinden van de vakantie die men zoekt is een tijdrovende zaak. Het vergelijken van prijzen van vakanties die aan de wensen voldoen valt ook niet mee. Het is bijna onmogelijk om alle reisgidsen naast elkaar te leggen en er snel de reizen uit te halen die interessant zijn. Nog moeilijker is het om van de interessante reizen de prijs te vergelijken, aangezien er vaak gebruik wordt gemaakt van toeslagen, regelingen en uitzonderingen. De ene reisgids doet bijvoorbeeld prijsopgaaf inclusief een aantal toeslagen (luchthaven belasting, éénpersoons-kamer toeslag), terwijl een andere reisgids alles exclusief afdrukt en alle toeslagen eronder vermeldt.

Ezooka.com heeft dit geconstateerd en wil op de behoefte inspringen om eenvoudig de vakantie te vinden die men zoekt en de prijzen van de aanbieders te vergelijken.

In de volgende paragrafen geef ik een beschrijving van de afstudeeropdracht, zoals deze is overeengekomen tussen mij en Ezooka.com. De omschrijving is besproken en aangepast naar aanleiding van gesprekken met Dhr. Van Strien (als vakdocent), Dhr. Schipper en mijn bedrijfsbegeleider. Vervolgens is deze beschrijving goedgekeurd door alle genoemde personen.

2.1     De probleemstelling

Ezooka.com werkt aan twee travel Websites (ezooka.com en metvakantie.nl), waarbij voor verschillende doelgroepen, reizen vergeleken kunnen worden op basis van hun prijs. De Website metvakantie.nl is reeds ontwikkeld voor de wat minder ervaren Internet-gebruikers en is eenvoudig in gebruik. Er kan gezocht worden naar een reis aan de hand van criteria. Gevonden reizen kunnen geboekt worden. Er kunnen geen reizen vergeleken worden.

Alle prijsgerelateerde gegevens uit de verschillende reisgidsen worden opgeslagen in twee databases: een zomer- en een winterdatabase. Deze scheiding is aangebracht omdat er van zomervakanties andere zaken vastgelegd worden dan van wintervakanties. De Website metvakantie.nl gebruikt nu de eerste versie van de zomerdatabase, de Website ezooka.com moet gebruik gaan maken van allebei de databases. De structuur van de databases kan veranderen wanneer blijkt dat er voor het afstudeerproject aanpassingen nodig zijn. Om de Website ezooka.com te laten werken moeten de reizen uit de verschillende reisgidsen ingevoerd worden.

2.2     De doelstelling van het project

De Website ezooka.com moest nog ontwikkeld worden. Met de Website ezooka.com moet het mogelijk worden om op meer criteria te kunnen zoeken en wordt de mogelijkheid gegeven om prijzen te vergelijken. Deze Website is dan ook bedoeld voor de iets meer ervaren Internet-gebruikers. Ook kan met de Website ezooka.com online geboekt worden. Het moet tevens mogelijk worden dat de gebruiker nadat hij reizen heeft vergeleken, deze vergelijkingen kan opslaan in een gebruikersprofiel en later eventueel verder kan gaan met vergelijken. Ook zoekresultaten en persoonlijke gegevens kunnen dan worden opgeslagen.

Het doel van de afstudeeropdracht is het ontwikkelen van een invoerapplicatie voor de databases ten behoeve van de travel Websites van Ezooka.com, zodat de prijsgegevens van verschillende reisorganisaties ingevoerd kunnen worden. Na een grondige analyse van de reisgidsen, moet er een invoerapplicatie ontwikkeld worden die bijna alle reisgidsen (95%) ondersteunt. Voor de andere reisgidsen moet er een extra invoeroptie  komen in de applicatie, zodat ook deze gegevens opgeslagen kunnen worden. Om de invoerapplicatie te ontwikkelen zullen een functioneel en technisch ontwerp gemaakt worden.

Tijdens het technisch ontwerp wordt gekeken of het ontwerp van de aanwezige zomerdatabase voldeed. Wanneer dit niet het geval is, moet er een aangepast databaseontwerp komen. Ook wordt er onderzocht welke delen van de aanwezige database kunnen blijven bestaan. De Website metvakantie.nl blijft met de eerste versie van de zomerdatabase werken en wordt pas in een later stadium door anderen aangepast aan de nieuwe situatie.

De invoerapplicatie moet een Web-applicatie worden, zodat vanaf een willekeurige werkplek (bijv. thuiswerker) reizen ingevoerd kunnen worden. Ezooka.com heeft als doel de invoerapplicatie 1 augustus 2001 online te hebben, zodat begonnen kan worden met het invoeren van de winterreizen.

Een andere afstudeerder, dhr J.P.C. van Terheijden, gaat de Website ezooka.com ontwikkelen. Bij de realisatie van het technisch ontwerp wordt, met betrekking tot het klassediagram, met hem samengewerkt. Dit onderdeel wordt bij beide technisch ontwerpen hetzelfde, omdat dit model gebruikt gaat worden bij de communicatie tussen de databases en de applicaties.

2.3     Uitgangssituatie van mijn project

2.4     De huidige prijs-invoerapplicatie

De testapplicatie die aanwezig is, bestaat uit een aantal schermen waarmee de gegevens ingevoerd kunnen worden.

De applicatie begint bij het selecteren van de juiste accommodatie uit een reisgids. Alle accommodaties moeten eerst ingevoerd worden. Met deze invoerapplicatie kan er een andere accommodatie toegevoegd worden, wanneer deze nog niet aanwezig is. De invoerder moet hiervoor wel rechten hebben om een accommodatie toe te voegen.

Naast de accommodatie moet er ook opgegeven worden, op welke pagina uit de reisgids de accommodatie vermeld staat.


Figuur 1: Accommodatie selecteren

Nadat de juiste accommodatie geselecteerd is, moeten alle in de accommodatie beschikbare kamertypes ingevoerd worden. Een accommodatie heeft bijvoorbeeld een aantal 2-persoonskamers en een aantal 4-persoonkamers. Dan worden alleen één 2-persoonskamer en één 4-persoonskamer ingevoerd. Er is niet bekend hoeveel kamers een bepaalde touroperator heeft in een accommodatie, daarom kan dit niet ingevoerd worden. Later wordt een kamertype gekoppeld aan een vertrekdag of reisperiode, zodat de prijs ervan kan worden opgeslagen.
Van een kamertype wordt ook aangeven met hoeveel personen er minimaal en maximaal kan worden verbleven. Bij de kamertypes worden meteen de kamerfaciliteiten opgegeven. Dit zijn bijvoorbeeld een douche, airco of minibar.


Figuur 2: Kamer faciliteiten selecteren

Bij het opgeven van de faciliteiten kan ingesteld worden voor welke aanwezige kamertypes de aangegeven faciliteiten gelden, maar ook welke faciliteit voor 1 bepaald kamertype niet geldt. Dit laatste werkt sneller dan eerst alle faciliteiten opgeven en degene die niet van toepassing is over te slaan.
Nadat de kamers zijn ingevoerd, kan de invoerder de prijzen gaan invoeren. Hierbij moet hij eerst de vertrekdagen opgeven, daarna de reisduur, de periode en als laatste per ingevoerd kamertype de prijs.


Figuur 3: Prijs gegevens invoeren

Het gebruik van deze prijsinvoer is vrij ingewikkeld. Bovendien is deze methode niet toepasbaar voor alle accommodaties uit verschillende reisgidsen. Ook het invoeren van kortingen en toeslagen is met deze applicatie nog niet mogelijk. Tijdens het ontwikkelen van deze applicatie werden er zoveel aanpassingen gedaan, dat de ontwikkelaar hier niet aan is toegekomen. Deze applicatie is gebouwd zonder enig ontwerp vooraf en er is ook helemaal geen documentatie van de genomen beslissingen, tijdens de bouw van de applicatie. Vanwege deze reden was het noodzakelijk dat de persoon die deze applicatie heeft gebouwd zo af en toe aanwezig was om het één en ander toe te lichten.


3      Het Plan van Aanpak

De eerste paar dagen van mijn afstudeerperiode heb ik mezelf georiënteerd binnen het bedrijf, met name op de bestaande demo-invoerapplicatie. Deze applicatie was het uitgangspunt voor mijn afstudeerproject. Daarna ben ik begonnen met een Plan van Aanpak voor het project, zodat ik duidelijk in beeld had welke activiteiten wanneer af moesten zijn en om een compleet overzicht te hebben van mijn werkzaamheden. Daarnaast was dit Plan van Aanpak ook voor mijn afstudeerbegeleiders, zodat zij wisten waarmee ik bezig was en wat mijn planning was.

Er waren nog geen werkwijzen of standaards voor een Plan van Aanpak, dus ik kon zelf een opzet maken waarin in zelf de hoofdstukindeling kon maken. De indeling is wel gemaakt in overeenstemming met John van Terheijden (de andere afstudeerder) om deze zoveel mogelijk hetzelfde te houden.

3.1     Uit te voeren activiteiten

In deze paragraaf staan de activiteiten beschreven die uitgevoerd worden tijdens dit project.

3.2     Methoden en technieken

De invoerapplicatie wordt ontwikkeld m.b.v. de beschreven UML-technieken in 'Praktisch UML' van Warmer en Kleppe (Warmer, 1999). Binnen Ezooka.com is er een begin gemaakt met de object-georiënteerde ontwikkeling van webapplicaties, dus bestaat de wens om de invoerapplicatie te ontwikkelen m.b.v. UML. Deze technieken zijn binnen Ezooka.com nog grotendeels onbekend, ik kan dus mijn kennis van UML toepassen op mijn eigen manier.

Om dit project te realiseren ga ik Macromedia Dreamweaver Ultradev 4 gebruiken, in combinatie met Microsoft SQL-server. Dit laatste draait op de server, waar de winter- en zomer database op staan. Dreamweaver Ultradev 4 is ook al een applicatie die binnen Ezooka.com gebruikt wordt voor het maken van websites, zodat de keuze voor deze applicatie erg voor de hand ligt.

3.3     De planning

Hier volgt de planning van de uit te voeren activiteiten.

Activiteit\Week

7 (11-2)

8 (18-2)

9 (25-2)

10 (4-3)

11 (11-3)

12 (18-3)

13 (25-3)

14 (1-4)

15 (8-4)

16 (15-4)

17 (22-4)

18 (29-4)

19 (6-5)

20 (13-5)

21 (20-5)

22 (27-5)

Bestuderen reisgidsen

                               

Functioneel Ontwerp

                               

-          Analyserapport

                               

-          Systeemeisen

                               

-          Use-cases

                               

-          Schermindelingen

                               

-          Schermverloopdiagram

                               

Technisch Ontwerp

                               

-          Klassendiagram

                               

-          Beschrijving klassendiag.

                               

-          Sequentiediagrammen

                               

Realiseren

                               

Testen

                               

Legenda:

 

Planning voor de gehele activiteit

 

Planning voor de onderdelen van een activiteit

3.4     De tussenproducten

Na het afronden van iedere fase, wordt er een document opgeleverd. Dit zijn achtereenvolgens:

3.5     Welke eisen worden er aan de producten gesteld?

In deze paragraaf worden de kwaliteitseisen beschreven die ik heb toegepast na elke fase om de fasen te beoordelen op kwaliteit. Deze kwaliteitseisen heb ik ook zelf opgesteld, omdat deze nog niet aanwezig waren bij Ezooka.com.

Documenten / rapporten:

Elke keer nadat een fase is afgerond en er één van de in de vorige paragraaf genoemde documenten opgeleverd wordt, wordt dat document besproken met de projectgroep.

1.      Het analyserapport is gereed wanneer:

2.      Het Functioneel Ontwerp is gereed wanneer:

3.      Het Technisch Ontwerp is gereed wanneer:

Prijs-Invoerapplicatie voor reisgidsen

Wanneer de invoerapplicatie gereed is, is het mogelijk om met de applicatie:

3.6     De risico's die zich kunnen voordoen

Aan dit project waren een aantal risico's verbonden:

3.7     De leden van de projectgroep

De projectgroep voor het ontwikkelen van de invoerapplicatie bestaat uit:

naam

functie

Eugène de Bruin

Algemeen coördinator

Michiel Wessels

Projectleider

Jeroen van de Merwe

Functioneel- en technisch ontwerper / programmeur

Michiel Crefcoeur

Programmeur testapplicatie

3.8     De verantwoordelijkheden

Eugène de Bruin was tijdens mijn afstudeerperiode de algemeen coördinator van het invoerproject. Hij hield zich bezig met functionele beslissingen, zoals welke reisgidsen wel of niet ondersteunen in de invoerapplicatie.

De projectleider van mijn afstudeerproject was Michiel Wessels. Hij hield de voortgang van het project in de gaten en bepaalde de functionele eisen, aangezien hij al betrokken geweest was bij de demo-invoerapplicatie.

Wat voortgang en inhoud van de op te leveren documenten e.d. was ik zelf verantwoordelijk. Ik werd zo af en toe wel een beetje gestuurd in de volgorde van werkzaamheden, maar de ontwikkeling is volgens mijn planning opgezet. Ook kon ik bepalen wat de onderdelen van het Functioneel- en Technisch Ontwerp werden. Dit gebeurde wel in overleg, maar omdat ze bij Ezooka.com daar geen kennis voor hadden kon ik ze daarin sturen.

Michiel Crefcoeur heeft de demo-invoerapplicatie geprogrammeerd. Hij was mijn aanspreekpunt voor uitleg over genomen beslissingen tijdens de ontwikkeling van de demo. Deze konden van toepassing zijn op mijn project, aangezien ik van voor af aan zou beginnen.

3.9     De bijeenkomsten

Iedere maandagmorgen is er een kort overleg geweest, waarin de stand van zaken besproken werd. Bij grote problemen kon er een extra vergadering ingepland worden, om een oplossing te vinden of om belangrijke beslissingen te nemen.


4      Analyse van de prijssystematiek

Voordat ik kon beginnen aan het ontwerp van de invoerapplicatie, moest ik eerst alle reisgidsen in kaart brengen. Alle prijsgerelateerde gegevens moesten geïnventariseerd worden, zodat er met behulp van deze gegevens modules gemaakt konden worden. Met behulp van deze modules kan er in de toekomst makkelijk een nieuwe methode van een reisgids samengesteld worden. De methoden van de reisgidsen verschillen bij de prijsgerelateerde gegevens in de prijsbijlage. 

Prijsgerelateerde gegevens zijn:

Als eerste heb ik een selectie gemaakt in de bij Ezooka.com beschikbare reisgidsen. Hierbij heb ik de belangrijkste gidsen als eerste gepakt. Vervolgens heb ik per reisgids de prijsbijlage bekeken waarin alle prijzen, kortingen en toeslagen vermeld stonden. Ik ben begonnen met het inventariseren van de aanwezigheid van een aantal onderdelen. Per reisgids heb ik gekeken of:

Het bleek dat dit niet bij elke gids allemaal vermeld stond. Deze gidsen moeten anders benaderd worden of in ieder geval nader onderzocht worden of deze ook daadwerkelijk ingevoerd gaat worden.

Na het inventariseren van de basisonderdelen, heb ik een aantal categorieën gedefinieerd die volgens mij voor de definitieve boekingsprijs belangrijk zijn.
Die onderdelen zijn:

Van alle categorieën die ik hierboven genoemd heb, ben ik toen gaan inventariseren welke gegevens allemaal in de prijsbijlage van de gids voorkwamen. Hierdoor ontstond er een overzicht op welke vlakken de reisgidsen van elkaar verschilden (zie hoofdstuk 1 en verder in Externe bijlage: Analyse van reisgidsen).

Met behulp van de gemaakte tabellen, kon ik per categorie een lijst maken waarin de verschillende gegevens stonden die nodig waren om de betreffende onderdelen uit alle reisgidsen op te kunnen slaan. Zie voor een voorbeeld, onderstaande tabellen.

Prijzen

Per persoon

[ ] per verblijf [ ] nacht [ ] acco [ ] week
[ ] luchthaven belasting
[ ] vervoer
[ ] verblijfsbelasting
[ ] brandstoftoeslag
[ ] transfers (van luchthaven, naar hotel v.v.)
[ ] hostess service
[ ] sport en entertainment
[ ] accommodatie
[ ] excursies


Wintervervoer

  • prijs inclusief bij accommodatie, verlengingsprijs voor een week is de autoprijs
  • acco prijzen inclusief autovervoer, ander vervoer per toeslag
  • prijzen vervoer per bestemming / land, per vertrekdag, per reisduur
  • My Way heeft soms de accoprijs inclusief vervoer, soms exclusief
  • Per acco, per vervoersoort, per vertrekdag
  • Per vervoer,  per vertrekdag
  • Per vertrekdag / periode, per leeftijd.
  • De vluchten zijn bij de betreffende acco inclusief (Club Med)
  • Verlenging per aankomstdag (Club Med)
  • NBBS heeft bij Alpen Express tariefgroepen (A: kost … B: kost …)
  • Vrij Uit, per tariefklasse, per coupé, vertrekdata
  • Soms ook losse transferprijzen van luchthaven naar hotel / verblijf

Voor het inventariseren van alle gegevens heb ik hulp gehad van een andere part-time medewerker van Ezooka.com. Hij heeft mij geholpen met een deel van de wintergidsen, omdat dit mij anders teveel tijd ging kosten en ik de planning had moeten aanpassen.

Met behulp van deze tabellen kon ik beginnen aan het Functioneel Ontwerp, omdat ik nu precies in beeld had welke gegevens er nodig waren bij de invoer van de prijzen, toeslagen, enz.

Het wintervervoer is apart geïnventariseerd, omdat dit sterk afwijkt van het zomervervoer. In de zomer zijn alle, in de gids vermelde, prijzen inclusief naar de vakantiebestemming.
In de winter is het in bijna alle gidsen mogelijk om een accommodatie los van het vervoer te boeken. Per accommodatie zijn er dan een aantal vervoersvormen mogelijk die los geboekt moeten worden. Om dit te kunnen opslaan, zijn andere gegevens nodig.

Deze gegevens zijn op dezelfde manier geïnventariseerd als de zomervakanties. Per categorie (prijzen, toeslagen, kortingen, enz.) zijn de benodigde gegevens opgesomd en met behulp daarvan zijn er weer lijsten gemaakt met alle benodigde gegevens om het wintervervoer van alle reisgidsen op te kunnen slaan.


5      Het Functioneel Ontwerp

Voor de ontwikkeling van de invoerapplicatie, bestond bij Ezooka.com de wens om dit met behulp van de UML-technieken te doen. Het was de bedoeling dat de applicatie objectgeoriënteerd ontwikkeld werd. Ze hadden echter zelf weinig ervaring met UML, waardoor John en ik ons niet hoefden te houden aan een bepaalde standaard. Bij aanvang van mijn afstudeerperiode besloot ik om de bestaande applicatie in het begin links te laten liggen, om een compleet frisse kijk te houden op de nieuwe invoerapplicatie. Tijdens de ontwikkeling van de bestaande applicatie waren er namelijk nogal wat problemen met betrekking tot de prijsinvoer van de accommodaties waar van tevoren geen rekening mee gehouden was.

5.1     Afbakening van het product

De invoerapplicatie die ik moest maken, betrof alleen het selecteren van een accommodatie uit een reisgids en het invoeren van alle relevante prijsgegevens van deze accommodatie. Het gedeelte dat voor het invoeren van de accommodaties, landgegevens en plaatsgegevens nodig is, werd door iemand anders geschreven.

Verder werd aan het begin vastgesteld dat er geen rondreizen of autovakanties opgeslagen / verkocht gingen worden, omdat deze teveel problemen met zich meebrengen op organisatorisch en op verkopen gebied.

5.2     De tussenproducten

De tussenproducten tijdens het Functioneel Ontwerp waren:

5.3     Het document Functioneel Ontwerp

Het systeemontwerp van de invoerapplicatie bestaat uit een Functioneel- en Technisch Ontwerp. De UML technieken, die wij gingen gebruiken, worden meestal niet sequentieel gebruikt, maar vaak naast elkaar en recursief. Tijdens het ontwerpen van het ene diagram komen er weer punten naar boven die bij het andere diagram nog niet zijn meegenomen. Dan kan het andere diagram gewoon weer aangepast worden. Het Functioneel- en Technisch Ontwerp zijn dus voor een deel tegelijkertijd gemaakt.

In het Functioneel Ontwerp heb ik de use-cases en een concept klassediagram opgenomen. Dit klassediagram wordt dan in het Technisch Ontwerp verder uitgewerkt. De use-cases heb ik, steeds in overleg, samen met Michiel Wessels gemaakt. Nadat deze volgens ons geheel in beeld gebracht waren, zijn John en ik begonnen met het inventariseren van kandidaat-klassen. Dit hebben we gedaan door van alle gemaakte Functionele Ontwerpen [1] de meest relevante zelfstandige naamwoorden op een rij te zetten. Dit werd een flinke lijst en is opgenomen in het Technisch Ontwerp (zie Externe bijlage 3: Technisch Ontwerp). Vanuit deze lijst is een concept klassediagram gemaakt. Verder heb ik nog een schermverloopdiagram gemaakt om aan te geven in welke volgorde de prijsgegeven ingevoerd zouden gaan worden en zijn er twee concept invoerschermen gemaakt om een beeld te geven hoe de invoerapplicatie er ongeveerd uit ging zien.

5.3.1   Systeemeisen

Bij het begin van het Functioneel Ontwerp, waren er een aantal eisen waaraan de invoerapplicatie minimaal aan moest voldoen. Deze eisen kwamen voort uit de al bestaande invoerapplicatie.

1.      Ezooka.com wilde dat de gebruiker iedere actie terug moest kunnen vinden op het scherm. Het zou namelijk voor kunnen komen dat de invoerder van zijn plaats moet, om iets te vragen aan de beheerder. Wanneer hij dan terug zou komen, kan het zijn dat hij vergeten is wat hij zojuist gedaan heeft en zou fouten kunnen maken in de invoer.

2.      Bij het invoeren van reisgidsen moet de invoerder getimed worden, zodat achteraf bepaald kan worden hoe lang de invoerder over het invoeren van één reisgids en het aantal reisgidsen dat hij ingevoerd heeft.

De in de bestaande invoerapplicatie volgorde van invoeren van de prijsgegevens, bleek door de afhankelijkheid van sommige gegevens de enige juiste volgorde te zijn. Deze is dus overgenomen uit de bestaande invoerapplicatie.

De volgorde:
Accommodatie à Kamertype à Kamer faciliteiten à Prijzen à Toeslagen à Kortingen à Aanbiedingen à Vervoer.

5.3.2   Use-cases

Eén van de eerste diagrammen die binnen UML gebruikt worden zijn use-cases. Hiermee wordt alle interactie beschreven die plaatsvindt tussen de gebruiker en het systeem. Met behulp van deze use-cases is het dan vervolgens mogelijk om de functionaliteit te bepalen van het systeem.

In het geval van mijn prijsinvoer-applicatie werden het nogal wat use-cases. Door het maken van deze diagrammen kregen Michiel Wessels en ik een duidelijk beeld van de informatie die het systeem nodig had en de gegevens die de invoerder moet invoeren om alle reisgidsen op te slaan. Voor het maken van use-cases bestond nog geen standaard bij Ezooka.com. Na mijn analyse van de reisgidsen, was John al begonnen aan de use-cases voor zijn afstudeeropdracht. Hierdoor had hij al een indeling en opmaak gemaakt voor de use-case tabellen. Deze heb ik overgenomen en steeds gebruikt bij het maken van mijn use-cases.

Hieronder een voorbeeld van een use-case zoals deze in het Functioneel Ontwerp staan (zie Externe bijlage 2: Functioneel Ontwerp).


Figuur 4: Voorbeeld use-casediagram

In dit diagram worden aan de linkerkant de actoren afgebeeld welke interactie hebben met het systeem. Binnen het vierkant, dat een stukje van het systeem voorstelt, staan de verschillende onderdelen van die use-case. Elk onderdeel heeft ook een unieke code. Wanneer het blijkt dat een onderdeel nog meer onderdelen bevat, wordt deze in een nieuwe use-case uitgewerkt. Hierbij wordt de code van de nieuwe use-case die van dat onderdeel. De onderdelen krijgen altijd als code, de code van de use-case plus een uniek volgnummer.
Verder worden onderdelen die maar door één onderdeel gebruikt worden gekoppeld aan dat onderdeel met een stippellijn (bijv. O_04_02 in Figuur 4). Dit is om aan te geven dat ze alleen bij dat onderdeel horen en ook alleen door dat onderdeel aangeroepen worden.
Van dit use-casediagram worden use-casebeschrijvingen gemaakt. De beschrijving van dit diagram ziet er als volgt uit:

K_01

Kamer toevoegen
Actoren Invoerder, beheerder
Aannamen De invoerder kan het kamertype selecteren (K_01_01) en kan opgeven wat het minimaal en maximaal aantal personen is wat in de kamer kan verblijven (K_01_02).
Beschrijving De invoerder kan één van de voorkomende kamers toevoegen aan een ingevoerde accommodatie.
Resultaat Uitzonderingen

Alle use-cases krijgen tijdens het maken een code (linksboven in). Deze code komt terug in de use-casebeschrijving, zodat makkelijk de beschrijving en het diagram bij elkaar gezocht kunnen worden. Deze code moet uniek zijn binnen Ezooka.com, zodat ook later bepaald kan worden bij welk project de use-case hoorde en kan de use-case eventueel opnieuw gebruikt worden. In de use-casebeschrijving wordt een beschrijving gegeven van de functionaliteit van de use-case. Hierbij worden ook de functies van de verschillende onderdelen beschreven. Deze worden dan, met de code van het betreffende onderdeel erachter, vermeld in de beschrijving.
Uit de use-cases bleek dat bij toeslagen en kortingen dezelfde acties plaatsvinden. In overleg met Michiel Wessels heb ik toen besloten om deze twee samen te voegen in één klasse/tabel. De ene keer komt er namelijk een bedrag bij, de andere keer gaat er een bedrag af. Verder zijn deze zaken gelijk. De nieuwe klasse/tabel heet mutatie.
Een mutatie kan horen bij een reisgids of een vakantie en kan een bepaalde periode geldig zijn. Om te bepalen in welke volgorde toeslagen en kortingen berekend worden moet van een mutatie een prioriteit ingesteld kunnen worden.
Per mutatie moet ook een status aangegeven kunnen worden. Een status kan zijn verplicht, inbegrepen, optioneel, op locatie, korting, enz.
Voor alle aanbiedingen (3 nachten krijgen = 2 nachten betalen), wordt een aparte klasse/tabel aangemaakt, omdat deze nogal verschilt in velden dan de mutaties.

5.3.3   Concept klassediagram

Na het inventariseren van alle use-cases, hebben John en ik alle een lijst gemaakt van alle relevante zelfstandige naamwoorden uit alledrie de Functionele Ontwerpen. Hieruit zijn we gaan strepen, met als criteria de genoemde punten uit het boek 'Praktisch UML' (Warmer, 1999). Deze punten beschrijven hoe je een kandidaat klasse kan herkennen uit een hele groep zelfstandige naamwoorden. Deze kandidaat klassen hebben we ook weer opgesomd en verduidelijkt doormiddel van een beschrijving.

Uit de lijst met kandidaatklassen, hebben de uiteindelijke klassen geselecteerd die we beschreven hebben in een modeldictionary. Met deze klassen hebben we een concept klassediagram gemaakt (zie Figuur 5 ).


Figuur 5: Concept klassediagram

Tijdens het maken van het concept klassediagram, moeten de relaties tussen de klassen bepaald worden. Dit bleek een moeilijke opgave. Iedere keer als we het diagram bespraken met onze projectleiders, kwamen er weer punten naar boven waardoor de relaties tussen bepaalde klassen aangepast moesten worden.
We hebben toen besloten, het meest logische diagram te behouden voor het functioneel ontwerp en een andere benadering te kiezen om tot de goede relaties te komen. We zijn toen begonnen met het databaseontwerp in hoop hier overeenkomsten te vinden met het klassediagram en zo de relaties in beeld te krijgen.

5.3.4   Mogelijke systeemoplossingen

Bij het analyseren van de reisgidsen kwamen er een aantal mogelijke manieren naar boven, over de opbouw van de invoerapplicatie.

5.3.5   Gekozen systeemoplossing

Bij het maken van de use-cases, kwam echter naar boven dat alle reisgidsen wel dezelfde gegevens gebruiken om de prijzen vermelden, alleen toont iedere reisgids zijn prijzen op een andere manier. Bij de ene gids worden de reizen per periode per kamer afgebeeld en bij een andere gids worden de prijzen per reisduur per kamer per periode afgebeeld.
In overleg met mijn projectleider heb ik er toen voor gekozen om een applicatie te ontwikkelen waarin eerst een reisgids gekozen wordt, voordat er prijzen ingevoerd gaan worden. Bij het invoeren van de prijzen wordt er een html-tabel opgebouwd die overeenkomt met de tabel in de reisgids, zodat de invoerder de prijzen in één keer kan overtypen. Voordat er accommodaties en kamers ingevoerd kunnen worden, moet de methode van de reisgids wel bekend zijn. Deze moet eerst ingevoerd zijn door iemand die alle methodes van de reisgidsen vastlegt. Hierdoor is er een groep invoerders bij gekomen: de reisgidsinvoerders. Deze kunnen ook gelijk alle gegevens invoeren die voor de hele gids gelden, zoals kinderkortingen en vroegboekkortingen. Deze kunnen echter ook verschillen per accommodatie, ze komen dan niet bij de reisgids.

De reisgidsinvoerders hoeven fysiek niet persé te verschillen van de andere invoerders, maar de groep is bedoeld om onderscheid aan te brengen bij het ontwerp van de invoerapplicatie. Deze groep zal nog niet gebruikt worden bij mijn invoerapplicatie, maar wel bij de invoerapplicatie om de reisgidsgegevens in te voeren.

5.3.6   Schermindelingen

Om een eerste indruk te geven van hoe mijn invoerapplicatie eruit ging zien, heb ik een aantal niet werkende demoschermen gemaakt. Tevens kon ik hiermee een begin maken van de applicatie, zodat ik bij het begin van de realisatie gelijk aan de scripts kon beginnen.


Figuur 6: Nieuw inlogscherm

In bovenstaande figuur kan de invoerder of de beheerder zich aanmelden bij de invoerapplicatie. Wanneer hij / zij nog niet is aangemeld, is het menu boven in het scherm niet toegankelijk. Alle opties zijn dan nog uitgeschakeld.

Figuur 7: Nieuwe schermindeling

Tijdens de functioneel ontwerp-fase was niet geheel duidelijk welke gegevens er ingevoerd moesten worden om alle reisgidsen op te kunnen slaan. Hierdoor was niet geheel duidelijk welke velden er in de schermen aanwezig moesten zijn en zijn de demoschermen slechts een aanzet tot de definitieve schermen.
De indeling is als volgt:

Van de demoschermen van de invoerapplicatie is een schermverloopdiagram (zie Figuur 8 ) gemaakt, zodat duidelijk wordt in welke volgorde schermen zichtbaar worden en in welke volgorde de gegevens ingevoerd gaan worden.

5.3.7   Schermverloopdiagram


Figuur 8: Schermverloopdiagram

Het schermverloopdiagram heb ik opgedeeld in twee gedeelten:

In het selectiegedeelte worden de gegevens geselecteerd, zoals de touroperator, de reisgids en de accommodatienaam, waarvoor in een latere fase van de invoerapplicatie de prijzen, toeslagen, kortingen e.d. ingevoerd gaan worden.

In het invoergedeelte worden deze prijsgegevens ingevoerd bij de geselecteerde accommodatie van de betreffende touroperator.

Dit verloopdiagram was vooral bedoeld om overzicht te houden in de complexe structuur van de invoermethode. Daarnaast was het ook bedoeld voor Ezooka.com om de gehele structuur en functionaliteit van de invoerapplicatie gedocumenteerd te hebben voor een eventuele opvolger die aan de invoerapplicatie gaat werken.


6      Het Technisch Ontwerp

Met behulp van de in het Functioneel Ontwerp gemaakte use-cases, kon er begonnen worden met het maken van een technisch ontwerp met daarin het definitieve klassediagram, de beschrijvingen van alle klasse en operaties, een sequentiediagram en een aangepast databaseontwerp.

Bij aanvang van het maken van het Technisch Ontwerp, verliep alles volgens de door mij gemaakte planning.

6.1     Normalisatie van de gegevens

Na de eerste fase van het klassediagram ontwerp, kwamen John en ik er niet uit wat betreft de relaties van de klassen tot elkaar. Iedere keer wanneer we dachten een goed diagram te hebben, kwam er wel weer iets boven waardoor er verschillende relaties veranderden of niet klopten. We hebben toen besloten om het klassediagram even te laten liggen en te beginnen met het databaseontwerp. We hoopten via het databaseontwerp een ander inzicht te krijgen in de verschillende relaties. Het databaseontwerp komt namelijk in de meeste gevallen overeen met het klassediagram, omdat een klasse veelal lijkt op een database tabel.

Als eerste stap maakten we weer een lijst met mogelijk relevante gegevens die opgeslagen zouden moeten worden. Deze lijst met gegevens gingen we vervolgens normaliseren.

Het normalisatieproces gaat volgens een aantal stappen. Deze stappen moeten sequentieel uitgevoerd worden op de lijst met gegevens. Het normaliseren zorgt ervoor dat er in de database, gegeven niet dubbel opgeslagen (redundantie) worden. Doormiddel van relaties aan te leggen tussen tabellen, worden alle tabellen gekoppeld.

Eerste normaalvorm:

Alle procesgegevens worden uit de lijst verwijderd. Procesgegevens zijn gegevens die berekend kunnen worden doormiddel van andere, in de lijst aanwezige, gegevens.

Tweede normaalvorm:

Van de lijst met gegevens, wordt er een sleutel aangewezen. Alle gegevens die meerdere keren kunnen voorkomen ten opzichte van de gehele of een gedeelte van de sleutel worden uit de lijst verwijderd. De sleutel of een deel daarvan worden ook onderaan in die lijst opgenomen. Vervolgens herhaald dit proces zich, totdat alle gegevens maar één keer voorkomen ten opzichte van de sleutel.

Derde normaalvorm:

Wanneer er in de groepen met gegevens zich gegevens bevinden die onderling ook nog een relatie hebben, worden deze eruit gehaald en in een nieuwe groep geplaatst. Vervolgens wordt hiervan een sleutel gekozen en geplaatst in de groep van waaruit de groep is ontstaan.
(Voorbeeld: een werknemer hoort bij één afdeling en heeft één chef. Een afdeling echter heeft ook altijd één chef. Dan wordt bij werknemer een verwijzing opgenomen naar afdeling, waarna de chef van de werknemer achterhaald kan worden.)

Dit normalisatieproces leverde het eerste representatiemodel op. Dit model was nog op basis van onze eigen inventarisatie van gegevens. Van dit model konden we het volgende Bachmandiagram maken.

6.2     Bachmandiagram


Figuur 9: Bachmandiagram

Dit diagram geeft schematisch de onderlinge relaties van de tabellen weer doormiddel van lijnen. Deze lijnen geven allemaal een '1 op veel' relatie weer. Dit wil zeggen dat bijvoorbeeld de tabel touroperator meerdere reisgidsen kan hebben, maar dat een reisgids maar bij één touroperator hoort.

Een Bachmandiagram is met name handig bij het implementeren van de applicatie waarbij gegevens uit de tabellen moeten worden gelezen en moeten worden weergegeven. Bij het weergeven moeten velden, zoals bijvoorbeeld accommodatieType, niet worden weergegeven als een getal of code, maar als omschrijving. Om deze omschrijving te kunnen tonen moet deze uit een andere tabel gehaald worden. Met behulp van dit diagram is het dan makkelijk opzoeken hoe die tabel heet en het overzicht te behouden in de complexe structuur van de database.

6.3 Wintervervoer inventarisatie

Tijdens het ontwerpen van het nieuwe database model, werd verder duidelijk dat we nog steeds te weinig wisten over het wintervervoer om een universele oplossing te vinden. Ik heb toen een stapel wintergidsen gepakt en ben alle verschillende gegevens over het wintervervoer nog een keer gaan inventariseren.

Per winterreisgids heb ik opgeschreven hoe de prijs van het vervoer vermeld stond, inclusief / exclusief kortingen en toeslagen. Een complete lijst van de inventarisatie staat in paragraaf 1.2 van het Functioneel Ontwerp (zie Externe bijlage 2: Het Functioneel Ontwerp).

Nadat deze wijzigingen in beeld waren gebracht, konden we het eerste representatiemodel compleet maken met behulp van deze wijzigingen en konden we de reeds gebruikte velden uit de bestaande database die wij nog niet in ons ontwerp hadden opgenomen invoegen. Hierdoor ontstond volgens ons een compleet databaseontwerp.

    

6.4 Gedetailleerd klassediagram

Na het maken van het databaseontwerp, hebben John en ik het concept klassediagram er naast gelegd om te vergelijken. Het bleek dat er nog een aantal relaties niet in het klassediagram verwerkt zaten en dat er een aantal anders waren. We hebben toen het klassediagram aangepast. Hieruit is het definitieve klassediagram gekomen.


Figuur 10: Gedetailleerd klassediagram

Volgens het boek 'Praktisch UML' horen er in een definitief klassediagram ook de meest relevante attributen en methoden. Dit werden er nogal wat en daarom hebben we besloten om deze niet in het diagram op te nemen, maar deze op te sommen in het Technisch Ontwerp en er tevens een beschrijving van te geven.

6.5 Implementatie van het nieuwe databasediagram

Na het afronden van het Technisch Ontwerp, was er een nieuw databaseontwerp. Samen met John heb ik dit ontwerp toegepast op de bestaande database. Dit was nogal een ingrijpende verandering aangezien de database bijna helemaal veranderd was. Naast het aanpassen van de database zelf, hebben we ook het databasediagram aangepast. Dit diagram kan gemaakt worden in SQL-server 7 zelf, op basis van de aanwezige tabellen in de database. Dit diagram was echter te groot om op te nemen in dit eindverslag, het beslaat namelijk 24 a4-tjes.

Tijdens het implementeren van het door ons ontworpen databasemodel, kwamen we nog op een aantal punten die we over het hoofd hadden gezien of die we gewijzigd hebben.

De eerste grote wijziging betrof de in het concept klassediagram genoemde 'reis'. Deze naam leverde nogal wat verwarring op met betrekking tot het vervoer van huis naar de vakantiebestemming. tabel reis gaat nu prijsperiode heten. Een prijsperiode is een kamer in een bepaalde periode met een bepaalde prijs. Een kamer is een bepaald kamertype in een bepaalde accommodatie, aangeboden in een bepaalde reisgids. De periode is geen aparte tabel en bestaat hier uit een van de volgende verzamelingen gegevens:

Daarna kwamen we er achter dat we de classificatie van de accommodaties vergeten waren mee te nemen in ons ontwerp. De meeste gidsen gebruiken sterren als classificatiemethode, maar een aantal gidsen hebben een eigen manier van accommodaties classificeren met zijn eigen waarde oordeel daaraan. Eén gids heeft bijvoorbeeld dakjes, de ander heeft bergtoppen. Zo kan een accommodatie 3 dakjes krijgen in de eerste gids en in de andere krijgt hij 4 bergtopjes, terwijl het om dezelfde accommodatie gaat. Om dit ook op te kunnen slaan kwam er in de tabel kamer een veld bij: classificatie. In het veld classificatieType kan worden vastgelegd van welk type de classificatie is: sterren, dakjes, bergjes, enz.

De tabel accommodatietype was ook nog niet aanwezig binnen ons databasemodel. Van een accommodatie moet ook aangegeven kunnen worden of het een hotel is of een appartementencomplex. Wij hebben ervoor gekozen om dit type op te slaan bij de kamers van een accommodatie. Op deze manier is het mogelijk om ook accommodaties op te slaan die zowel hotelkamers hebben als appartementen verhuren.

Aanwezige faciliteiten van accommodaties en kamers was ook niet aanwezig binnen ons ontwerp. Deze tabellen hebben we rechtstreeks overgenomen uit de bestaande database. Hiervoor is gekozen om ook de inhoud die reeds ingevoerd was, te kunnen behouden. We hebben wel een andere naamgeving gebruikt.

Verder komt er een tabel ‘Vol’ bij, waar een kamers en accommodaties aan toegevoegd kunnen worden en als volgeboekt kunnen worden aangemerkt. Een ‘volboeking’ bevat een van de volgende verzamelingen gegevens:

Aangezien er twee soorten reizen zijn (winter- en zomerreizen), moeten deze allebei worden opgeslagen. Er is voor gekozen om dit in twee verschillende databases te doen, zodat de reizen makkelijk gescheiden blijven.
De hele database, die John en ik hebben ontworpen, is daarom na het realiseren één op één gekopieerd.

Nadat ook de bovenstaande punten waren opgenomen in ons ontwerp, konden ik beginnen met de realisatie van mijn invoerapplicatie.


7      Het realiseren van de applicatie

Aan het begin van het Technisch Ontwerp deed zich ook nog een voor mij onverwachte gebeurtenis voor. Er werd besloten om de reisactiviteiten stop te zetten (zie paragraaf 8.1 ). Hierdoor werd de toekomst voor mijn invoerapplicatie nogal onzeker, omdat niet zeker was of de applicatie ooit nog gebruikt ging worden. Er werd besloten om in ieder geval toch de belangrijke onderdelen van de invoerapplicatie te realiseren en de onderdelen met een mindere prioriteit te laten liggen. Op deze manier zou er een applicatie (of een deel ervan) komen die zou kunnen dienen als een demonstratie van de capaciteiten van Cipix [2] op het gebied van content management. Tevens zou er dan nog geprobeerd kunnen worden om het concept voor de applicatie te verkopen aan een reisorganisatie die eventueel geïnteresseerd is.

7.1     Aangepaste planning

Tijdens het maken van het Technisch Ontwerp liepen John en ik tegen nogal wat problemen aan. Het gehele databaseontwerp nam veel meer tijd in beslag dan eigenlijk de bedoeling was. Hierdoor is de fase Technisch Ontwerp nogal uitgelopen. Als gevolg hiervan heb ik in overleg met mijn projectleider besloten om het beheer gedeelte vooralsnog niet te implementeren en me alleen bezig te houden met het invoergedeelte. Daarnaast kwam het monitoren van de invoerder voor mij te vervallen. Dit zou dan eventueel door iemand anders later geïmplementeerd worden.

Als gevolg van het uitlopen van de fase Technisch Ontwerp, is de planning voor de realisatie aangepast.

Activiteit\Week

7 (11-2)

8 (18-2)

9 (25-2)

10 (4-3)

11 (11-3)

12 (18-3)

13 (25-3)

14 (1-4)

15 (8-4)

16 (15-4)

17 (22-4)

18 (29-4)

19 (6-5)

20 (13-5)

21 (20-5)

22 (27-5)

Realiseren

                               

Testen

                               

7.2     De implementatie van het ontwerp

Als eerste ben ik het klassediagram gaan implementeren in ASP. Deze scriptingtaal was voor mij nog redelijk onbekend, dus moest ik eerst uitzoeken hoe in ASP een klasse gedefinieerd wordt. De definitie van een klasse vond ik op de website van DevGuru (http://www.devguru.com). Deze heb ik vervolgens toegepast in bijvoorbeeld de volgende klasse.

<%

  class clTourOperator

  '- De attributen van een touroperator----------------

  public id

  public naam

  public url

  public afkorting

  '— Methoden -----------------------------------------

  public function haalOp(toId)

     'code om één touroperator uit de database te halen  

  end function 'haalOp

  '----------------------------------------------------

  public function toonTourOperators()

     'code om alle touroperators weer te geven

  end function 'toonTourOperators

  '----------------------------------------------------

  end class 'clTourOperator

%>


Het is ook nog mogelijk om attributen te definiëren die alleen gebruikt kunnen worden binnen de klasse, die kunnen gedeclareerd worden doormiddel van 'private'. Nu staat er voor de attributen het sleutelwoord 'public'. Dit wil zeggen dat het attribuut ook buiten de klasse te benaderen is. In het andere geval is het attribuut alleen te gebruiken bij methodes die gedefinieerd zijn binnen de klasse.
Om van deze klassen een voorkomen, een object, te maken moet deze eerst aangemaakt worden binnen de ASP-code. Dit gebeurt als volgt:

<%

  Dim tourOperator

  Set tourOperator = new clTourOperator

%>


Vanaf nu is 'tourOperator' een object van de klasse clTourOperator. Via tourOperator is het nu mogelijk om de attributen te vullen, zoals bijvoorbeeld de naam van de touroperator:

<%

  tourOperator.naam = "Arke Reizen"

%>


In het begin van de realisatie, moest ik erg wennen aan de syntax van de ASP scripttaal. Deze verschilt nogal van de scripttaal PHP of C++.

Na het maken van de klasses ben ik begonnen met implementeren van de invoer-applicatie. Ik ben uitgegaan van de webpagina's die reeds gemaakt waren voor de demo-applicatie. Deze demo was gewoon een uitwerking van de schermontwerpen uit het Technisch Ontwerp.

Ik ben begonnen bij het eerste scherm: het inlogscherm. Er moest een inlogscherm voor de invoerapplicatie gemaakt worden, omdat er later precies bijgehouden gaat worden welke gegevens een bepaalde invoerder heeft ingevoerd.
Er was al een inlogscherm gemaakt voor de reeds bestaande invoerapplicatie, maar om gelijk een beetje met ASP en Visual Basic Script bekent te raken, heb ik ervoor gekozen om het inloggen zelf te programmeren.

Na het inlogscherm moet er als eerste een touroperator geselecteerd worden, daarna een accommodatie die ingevoerd gaat worden en als laatste moet de reisgids van de betreffende touroperator gekozen worden waarin de geselecteerde accommodatie vermeld staat. Dit lijkt een simpele volgorde, maar er zitten wat haken en ogen aan wanneer dit geprogrammeerd moet worden met behulp van ASP en HTML. Dit komt doordat ASP op de server uitgevoerd moet worden en de keuze van de gebruiker gedaan wordt op een werkstation. Die keuze moet dan eerst doorgestuurd worden naar de server voordat deze in ASP bekend is. Dit betekent dat er een extra aantal handelingen moeten plaatsvinden voordat bijvoorbeeld de reisgidsen van één touroperator getoond kunnen worden.

Verder had ik nog een probleem met sessievariabelen. Om een soort wizard te maken waarmee stukje bij beetje een kamer ingevoerd wordt, had ik sessievariabelen nodig. Een sessievariabele is een variabele die op de server geregistreerd wordt, zodat deze in alle scripts te benaderen is. Een variabele die gedefinieerd wordt in een script is alleen te benaderen binnen dat script. Met behulp van zo'n sessievariabele hoopte ik met behulp van een aantal stappen het kamerobject te vullen. Het bleek echter tijdens de ontwikkeling, dat het niet mogelijk was om een object in een sessievariabele op te slaan. Dit kan alleen maar met normale variabelen, zoals een getal of string. Hiervoor moest ik een andere oplossing zoeken. Ik heb het toen opgelost door iedere keer bij het aanroepen van een ander script de sleutels van de records mee geven als parameter. In het andere script lees ik dan de sleutel uit en haal ik het record op uit de database. Er vinden nu wel meer database acties plaats, maar deze vinden namelijk plaats op de server en hebben dus niet of nauwelijks invloed op de invoerapplicatie zelf. Het enige wat de invoerder kan merken is dat de wachttijd groter wordt.
De gekozen oplossing was dus de beste naar mijn idee.

Tijdens het maken van het kamerfaciliteit gedeelte, kwam ik erachter dat we de faciliteiten van de kamers als velden hadden opgenomen in de database. Dit is niet handig, omdat er nooit faciliteiten makkelijk toegevoegd of verwijderd kunnen worden. John en ik hebben toen besloten om nog twee tabellen aan de database toe te voegen:

In de faciliteit-tabel staan alle faciliteiten die een kamer kan hebben. In de kamerFaciliteit-tabel wordt dan vervolgens een bepaalde kamer gekoppeld aan een faciliteit. Op deze manier is het heel gemakkelijk om een faciliteit die nog niet bestond, toe te voegen aan bestaande faciliteiten en te koppelen aan een bestaande kamer.

Mede door dit soort problemen en aanpassingen, kwam ik tot de conclusie dat mij het niet ging lukken om de applicatie in zijn geheel te realiseren. Ik heb toen overlegd met de projectleider en de opdrachtgever en zij hebben toen gezegd dat de applicatie zover mogelijk afgemaakt moest worden. Aangezien ze de applicatie niet meer zelf gingen gebruiken, was het voor hen het belangrijkst dat de applicatie in combinatie met het Functioneel- en Technisch Ontwerp, in ieder geval een beeld geeft van de mogelijkheden van de applicatie zodat het aan potentiële klanten kan worden gedemonstreerd. Op deze manier worden de mogelijkheden vergroot om de applicatie nog te verkopen en de investering die gedaan zijn enigszins terug te verdienen.


8      Evaluatie

In dit hoofdstuk evalueer ik mijn gehele afstudeerperiode. In de eerste paragraaf komt het proces aan bod. Hierin wordt teruggekeken naar het Plan van Aanpak en wordt dit naast het uiteindelijke resultaat gelegd. Er wordt bijvoorbeeld beschreven of de methodes die ik gekozen heb, wel juist waren en of alles gelopen is zoals ik aan het begin in gedachten had.

Daarna komen de producten aan bod, die opgeleverd zijn tijdens het afstuderen. Hierin wordt gekeken of de opgeleverde producten het beoogde resultaat opgeleverd hebben. Verder komt de mening van de bedrijfsbegeleider aan de orde.

8.1     Procesevaluatie

Bij aanvang van mijn afstudeerperiode, wist in eerste instantie niet goed waar ik moest beginnen. Ik ben toen een beetje op gang geholpen door mijn projectleider en Michiel Crefcoeur, de persoon die de demo-invoerapplicatie had gemaakt. Na het analyseren van de reisgidsen, kwamen de use-cases aan de orde. Tijdens het maken van die use-cases kreeg ik al aardig in de gaten dat de omvang van mijn afstudeeropdracht nogal groot was. Dit gevoel werd nog eens bevestigd, toen John van Terheijden en ik aan het Technisch Ontwerp begonnen. Het was bijna een onmogelijke opgave om alle reisgidsen in één database op te slaan.

Tijdens het maken van het Technisch Ontwerp, werden John en ik gevraagd om even te vergaderen met Eugène de Bruijn en Michiel Wessels (onze project begeleiders). Er werd ons verteld dat de travelactiviteiten van Ezooka.com stop gezet gingen worden. De hoofdreden hiervoor was de grote concurrentie op Internet in de branche.
Ons werd verzekerd dat we gewoon verder konden met onze opdrachten zonder dat dit problemen zou geven. Er zou namelijk geprobeerd worden om de producten te verkopen aan belangstellenden, zodat er nog wat investeringen terug verdiend konden worden.
Het werd hierdoor echter wel moeilijker om de vaart van de ontwikkeling erin te houden, omdat de meeste personen de motivatie kwijt waren.
Maar bij aanvang van de realisatie, kwam er toch weer enig enthousiasme naar boven. Hierdoor heb ik toch nog een deel van de invoerapplicatie kunnen realiseren.

De uitvoering van de afstudeeropdracht vind ik zelf goed verlopen. Tot aan de realisatie verliep alles volgens de door mij gemaakte planning. Alleen door de onvoorziene omvang van het gehele project, is de realisatie niet voltooid. Naar mijn mening zijn de gekozen methodes en technieken ook goed verlopen. Alleen door de complexiteit van de gegevensstructuur, hadden we een beetje problemen met het vinden van de juiste klasse associaties. Ik denk dat we dat ook goed hebben opgelost, door eerst het databaseontwerp te maken en daarna die relaties te vergelijken met het klassediagram en het laatste hierop aan te passen.

8.2     Productevaluatie

Alle tussenproducten die in het Plan van Aanpak vermeld staan heb ik tijdens mijn afstudeerperiode opgeleverd.

Als kwaliteitseisen van het analyserapport stonden vermeld:

Het analyse rapport geeft een goed beeld van de verschillen op het gebied van de prijzenvermelding in de prijsbijlagen. Er bleek wel dat de reisgidsen niet echt verschillende methodes hebben ten aanzien van de gehele prijsbijlage, maar de verschillen zitten in kleine afwijkingen binnen een categorie prijzen, zoals kortingen, toeslagen en verzorgingen en de rekenwijze waarop de totale reisprijs uitgerekend wordt. Verder is het analyserapport belangrijk geweest voor het inventariseren welke gegevens er precies allemaal opgeslagen dienden te worden. Er waren wel een aantal reisgidsen al geanalyseerd, maar nog niet op deze schaal. Tijdens de analyse heb ik alle, bij Cipix aanwezige reisgidsen, doorgewerkt en geanalyseerd.

De kwaliteitseisen voor het Functioneel Ontwerp waren:

Samen met Michiel Wessels, mijn projectleider, heb ik de use-cases gemaakt. Toen ik begon aan de use-cases had ik nog het idee dat er niet zoveel waren, maar gaande weg bleek dat er juist heel veel interactie was met het systeem. Nadat volgens ons alle interactie vast gelegd was in de use-cases waren het er een flink aantal.
Alle use-cases konden onderverdeeld worden in de verschillende modules, bestaande uit de verschillende categorieën prijzen die in de reisgidsen vermeld staan. Die zijn ook allemaal genoemd bij het resultaat van de analyse in het Functioneel Ontwerp.

De kwaliteitseisen voor het Technisch Ontwerp waren:

Bij aanvang van het Technisch Ontwerp gingen John van Terheijden en ik aan de slag met het klassediagram. Dit bleek niet zo een eenvoudige klus. Alleen met behulp van de UML-technieken is het ons niet gelukt. Om tot goede associaties te komen hebben we na het concept-klassediagram, eerst de database uitgedacht. Ook dit bleek geen eenvoudige opgave. We hebben een aantal 'denksessies' gehad waarin met samen met onze projectleiders het gegevensmodel hebben uitgedacht. Maar omdat alle reisgidsen erin moesten passen was dit zeker niet eenvoudig. Nadat we het databaseontwerp af hadden, hebben we de tabelassociaties vergeleken met die uit het concept-klassediagram en zodoende het definitieve klassediagram gemaakt. De database bleek maar op één manier te kunnen, terwijl de klasse associaties ook nog op een andere manier mogelijk waren. Doormiddel van het databaseontwerp hebben we naar mijn mening een goed klassediagram opgeleverd. Op deze manier was ook gelijk het databaseontwerp gemaakt met een geheel frisse blik. Het databasemodel is zo ontworpen dat alle modules, genoemd in het Functioneel Ontwerp, bewaard konden worden in de database.

De kwaliteitseisen van de invoerapplicatie waren:

Met de invoerapplicatie, zoals hij nu is, kan een touroperator, een accommodatie en de reisgids geselecteerd worden waar de prijzen voor ingevoerd moeten worden. Vervolgens is het mogelijk om de aanwezige kamerTypes in te voeren met de bijbehorende kamerfaciliteiten. Van deze kamers kunnen daarna de periodes opgegeven worden waarin ze beschikbaar zijn met de bijbehorende prijs.

Het is mij, door tijdgebrek, niet gelukt om kortingen, toeslagen, aanbiedingen en het wintervervoer te laten invoeren. Dit is echter niet het moeilijkste deel meer, omdat deze niet zo ingewikkeld zijn als de prijsinvoer van de kamers. Deze onderdelen betreffen slechts één record per korting, toeslag, enz. die dan vervolgens gekoppeld kunnen worden aan een prijs van een kamer in een bepaalde periode.

Het is wel gelukt om ervoor te zorgen dat er een andere methode van een reisgids geïmplementeerd kan worden. De huidige methode is de meest gebruikte. Maar wanneer er een nieuwe methode gemaakt moet worden, kan er een nieuw ASP-bestand geschreven worden dat vervolgens in de applicatie geïntegreerd kan worden.



Conclusie

Mijn afstudeerperiode is voor mijzelf succesvol verlopen. Ik heb me wel een beetje vergist in de omvang van het project, maar ik heb wel het idee dat ik een goed ontwerp voor de invoerapplicatie en een goed databaseontwerp (samen met John van Terheijden) heb gemaakt waarmee Cipix kan laten zien wat het idee achter de invoerapplicatie is en dat ze met de invoerapplicatie dit idee goed kunnen illustreren.

Deze periode was ook gelijk de eerste keer dat ik in de praktijk een grote opdracht zelfstandig moest uitvoeren. Op een aantal punten verschilt dit wel van een opdracht uitgevoerd op school (bijvoorbeeld steeds werken in groepjes), maar ik heb volgens mij goed kunnen laten zien wat ik kan.

Verder heb ik best veel waardevolle kennis opgedaan, waarvan ik ook al een klein deel heb kunnen gebruiken in een project voor mijn eigen bedrijf. Voor deze opdracht moest er namelijk een website gebouwd worden waar de prijzen van vakanties in getoond werden. Door de voor mijn afstudeeropdracht opgedane kennis over de prijsopbouw was ik in staat om dit vrij snel te realiseren.

In zijn geheel heb ik het deze periode goed naar mijn zin gehad en ondanks dat ik de invoerapplicatie niet af had, ben ik tevreden met het resultaat.



Bijlage 1: Literatuurlijst

Warmer 1999                    Jos Warmer & Anneke Kleppe, Praktisch UML,
Addison Wesley Longman, 90-6789-937-2, Deventer 1999

Internet documentatie

DevGuru                           Infinite Software Solutions, http://www.devguru.com,
1999-2001


Bijlage 2: Figurenlijst

Figuur 1: Accommodatie selecteren. 8

Figuur 2: Kamer faciliteiten selecteren. 8

Figuur 3: Prijs gegevens invoeren. 9

Figuur 4: Voorbeeld use-casediagram. 17

Figuur 5: Concept klassediagram. 18

Figuur 6: Nieuw inlogscherm. 19

Figuur 7: Nieuwe schermindeling. 19

Figuur 8: Schermverloopdiagram. 20

Figuur 9: Bachmandiagram. 23

Figuur 10: Gedetailleerd klassediagram. 24


[1] Er zijn drie Functioneel Ontwerpen gemaakt: één voor mijn invoerapplicatie, één voor het personalisatiegedeelte van John en één voor de website Ezooka.com.

[2] Cipix is de nieuwe bedrijfsnaam waar de ICT activiteiten van Ezooka.com ondergebracht worden.