Universiteit Gentlib.ugent.be/fulltxt/RUG01/000/895/454/RUG01-000895454...1.1 Algemene omschrijving...

Universiteit GentFaculteit Toegepaste Wetenschappen

Vakgroep Telecommunicatie en InformatieverwerkingVoorzitter: Prof. dr. ir. Herwig Bruneel

RESERVATIEMODULE MET DATABANKONDERSTEUNINGVOOR WEBSITE CICOV

DoorJan GOESAERT

Promotor: Prof. dr. Guy De TréScriptiebegeleider: ir. Tom Matthé

Afstudeerwerk ingediend tot het behalen van de academische graadvan

MASTER IN DE TOEGEPASTE INFORMATICA

Academiejaar 2004-2005

ii

Voorwoord

Graag had ik een aantal mensen willen bedanken die rechtstreeks ofonrechtstreeks hun steentje hebben bijgedragen aan de totstandkoming van diteindwerk.

Vooreerst bedank ik mijn promotor Prof. Guy De Tré en mijn scriptiebegeleiderTom Matthé voor de deskundige begeleiding en waardevolle suggesties.

Ik dank ook mijn afdelingshoofd Gerda Van Der Plas en mijnteamverantwoordelijke Kathy Ooge die mij de kans geboden hebben om dit project voorte stellen en uit te werken.

Ook bedank ik Christel Claesen die mij de toestemming heeft gegeven om deapplicatie te hosten op de servers van het departement binnenlandse aangelegenhedenvan het Ministerie van de Vlaamse Gemeenschap. Tevens bedank ik Rudi Baeyens,voor het herhaaldelijke sleutelen aan de servers om mij de nodige permissies toe tekennen.

Tot slot richt ik mij ook tot mijn vriendin die van op de eerste rij mee heeftkunnen ervaren hoe belastend de combinatie werken en universitaire studies kan zijn. Ikwaardeer haar steun, vooral in die drukke en moeilijke momenten, waar ikwaarschijnlijk zelf niet het meest genietbare gezelschap ben geweest.

Toelating tot bruikleen"De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen

en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valtonder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot deverplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit dezescriptie."

Jan Goesaert, 27 mei 2005

iii

Reservatiemodule met databankondersteuning voor website CICOVdoorJan Goesaert

Afstudeerwerk ingediend tot het behalen van de academische graad van

Master in de Toegepaste Informatica

Academiejaar 2004-2005

Promotor: Prof. dr. Guy De TréScriptiebegeleider: ir. Tom Matthé

Universiteit GentFaculteit Toegepaste Wetenschappen

Vakgroep Telecommunicatie en InformatieverwerkingVoorzitter: Prof. dr. ir. Herwig Bruneel

Samenvatting

Deze scriptie beschrijft de totstandkoming en de werking van een webgebaseerdreservatiesysteem voor de website van het CICOV (Ministerie van de VlaamseGemeenschap). De applicatie gebruikt een access databank, die werd gemodelleerd aande hand van een EER diagram en ASP/ VBScript als server side scripting technologie.

Er diende zowel een module voor de klanten als voor de beheerder te wordenvoorzien. Klanten beschikken over volgende mogelijkheden: aanmaken en aanpassenvan een gebruikersprofiel, opvragen van de beschikbaarheid van het centrum, eennieuwe reservatie doorgeven, bestaande reservaties aanpassen en het opvragen van heteigen paswoord. De beheerder heeft de mogelijkheid om de reservaties te raadplegen, enal dan niet toe te staan. Hij dient de klanten ook toe te wijzen aan een bepaalde groep,hetgeen zal zorgen voor een verschillende tariefstructuur.

Het inbouwen van de diverse voorwaarden en restricties was de belangrijksteuitdaging in dit systeem. Er moest o.a. gegarandeerd worden dat geen overlappendereservaties mogelijk waren, dat op een bepaalde dag slechts een beperkt aantaldeelnemers gebruik kon maken van het centrum, dat een reservatie minstens zevendagen op voorhand moest worden doorgegeven, enz.

Trefwoorden

Databanken, webapplicatie, ASP, reservatiesysteem, …

iv

InhoudsopgaveHOOFDSTUK 1 INLEIDING.....................................................................1

1.1 Algemene omschrijving.......................................................................................................... 11.1.1 Situering ........................................................................................................................... 11.1.2 Requirements analyse....................................................................................................... 21.1.3 Niet-functionele vereisten/ beperkingen........................................................................... 2

1.2 Beschrijving in detail ............................................................................................................. 31.2.1 Gebruikte methode ........................................................................................................... 31.2.2 Use-Case-diagram ............................................................................................................ 31.2.3 Scenario's.......................................................................................................................... 4

HOOFDSTUK 2 RESTRICTIES IN HET SYSTEEM ................................8

2.1 Generieke restricties eigen aan het project .......................................................................... 82.1.1 Overlappingen .................................................................................................................. 82.1.2 Aantallen .......................................................................................................................... 8

2.2 Specifieke restricties eigen aan dit project........................................................................... 92.2.1 Aantal groepen per dag..................................................................................................... 92.2.2 Aantal deelnemers per dag ............................................................................................... 92.2.3 Tijdstip van reserveren ..................................................................................................... 9

HOOFDSTUK 3 BESCHRIJVING VAN DE DATABANK ......................10

3.1 Ontwerp d.m.v. een ER-diagram........................................................................................ 103.1.1 Werkwijze ...................................................................................................................... 103.1.2 Bespreking...................................................................................................................... 12

3.2 Ontwerp d.m.v. een EER-diagram ..................................................................................... 153.2.1 Motivatie voor het gebruik van een EER-diagram ......................................................... 153.2.2 Bespreking...................................................................................................................... 17

3.3 Integriteit van de databank ................................................................................................. 19

HOOFDSTUK 4 BESCHRIJVING VAN DE APPLICATIE .....................20

4.1 De gebruikersmodule ........................................................................................................... 204.1.1 Inloggen.......................................................................................................................... 204.1.2 Aanmaken/ aanpassen van de persoonlijke fiche ........................................................... 224.1.3 Boeken van een nieuwe reservatie.................................................................................. 254.1.4 Het wegschrijven van de reservatie ................................................................................ 324.1.5 Aanpassen bestaande reservatie...................................................................................... 364.1.6 Aanpassen van de databank............................................................................................ 414.1.7 Overzicht reservaties per maand..................................................................................... 43

4.2 De beheerdersmodule........................................................................................................... 444.2.1 Inloggen.......................................................................................................................... 444.2.2 Overzicht en beheer reservaties...................................................................................... 44

v

4.2.3 Toekenning groepen ....................................................................................................... 47

HOOFDSTUK 5 BEVEILIGING VAN DE DATA ....................................49

5.1 Encryptie............................................................................................................................... 49

5.2 Beveiliging databank d.m.v. een paswoord........................................................................ 49

5.3 Beveiligde directory ............................................................................................................. 49

HOOFDSTUK 6 MOGELIJKE UITBREIDINGEN ..................................51

6.1 Reservatie voor meerdere dagen......................................................................................... 51

6.2 Groepen en tarieven aanpassen........................................................................................... 51

HOOFDSTUK 7 BESLUIT .....................................................................52

BIJLAGE A INHOUD CD-ROM .............................................................53

BIJLAGE B WOORDENLIJST EN AFKORTINGEN .............................54

1.1 Algemene omschrijving

1

Hoofdstuk 1 Inleiding


1.1.1 Situering

Het CICOV (centrum voor informatie, communicatie en vorming in dewelzijnssector) is al een tijdje eigendom van het ministerie van de VlaamseGemeenschap. Het centrum beschikt over een aantal vergaderzalen die zowel doorambtenaren van het Ministerie van de Vlaamse Gemeenschap als door externen kunnenworden gereserveerd. Verder beschikt het centrum over een tweetal eetzalen en eenreceptieruimte waar klanten terecht kunnen voor een lunch of koffiepauze.

Reservaties werden lange tijd op een vrij klassieke manier verwerkt. Een klantnam telefonisch contact op met het secretariaat van de afdeling AlgemeenWelzijnsbeleid van het Ministerie van de Vlaamse Gemeenschap waar de reservatiescentraal bijgehouden worden. Correspondentie tussen klant en administratie verliep duslouter langs traditionele kanalen als telefoon en post.

In 2004 werd een eerste aanzet gegeven om deze procedures enigszins tedigitaliseren. Er werd een website ontwikkeld waar klanten een voorstelling van hetCICOV konden vinden en eveneens een elektronisch reservatieformulier waarmee zijhun wensen konden doorgeven. Dit bleef echter een vrij bescheiden vooruitgangaangezien een aantal mogelijkheden niet ingebouwd waren in het systeem. Zo was hetvoor een klant niet mogelijk om in een kalender de beschikbaarheid van het centrum opbepaalde dagen op te vragen. Ook het werk van de beheerder was op deze manier nietgedigitaliseerd aangezien deze nog steeds zelf moest nagaan of het centrum op degevraagde datum al dan niet beschikbaar was, waarna deze de klant hiervan op dehoogte moest brengen. Bovendien bleek ook dat de technologie die gebruikt werd omde server side verwerking van de formuliergegevens te doen (Frontpage Server -extensies), vrij onstabiel was.

Om deze redenen rees de vraag naar een meer dynamische website met meerfunctionaliteit. Een reservatie door een klant zou niet langer per e-mail wordenverstuurd naar de beheerder maar rechtstreeks in een databank worden geplaatst. Dezedatabank zou op zijn beurt een overzicht kunnen verstrekken van de data en urenwaarop het centrum nog beschikbaar was, rekening houdend met diverse beperkingen,zoals een maximum aantal groepen en deelnemers per dag. Het werk van de beheerderwordt daardoor grotendeels beperkt tot het al dan niet goedkeuren van de aangevraagdereservaties. Klanten die meerdere malen reservaties wensen te boeken dienen bovendienslechts eenmalig te reserveren. Bij een volgend gebruik van de applicatie worden depersoonsgegevens gewoon uit de databank opgevraagd.


2

1.1.2 Requirements analyse

De vereisten van het systeem werden afgebakend via een aantal gesprekken metrechtstreeks betrokkenen, zoals de persoon die zal instaan voor het beheer van dereservaties en leidinggevenden. In afwachting van een meer uitgebouwd project werd,zoals gezegd, reeds een embryonale vorm van interactie voorzien op de huidige website.Het ging om een formulier met een reeks invulvelden dat per e-mail aan de beheerderwerd bezorgd. Bij het uitwerken van dit formulier werd al heel wat nuttige informatieverzameld m.b.t. de gewenste velden (inhoud van de databank) en de laterefunctionaliteit van het eindsysteem. Het formulier heeft al een aantal verfijningen enuitbreidingen ondergaan, op basis van de wensen van o.m. de beheerder.

In zekere zin kan men dit voorlopig formulier dan ook beschouwen als een vormvan “rapid prototype”. Uiteraard bood deze oplossing voorlopig weinig back-officefunctionaliteit maar zij kon wel een duidelijk beeld geven van de informatie die in eenlatere fase via een databank zou moeten worden beheerd.

1.1.3 Niet-functionele vereisten/ beperkingen

Hoewel het Ministerie van de Vlaamse Gemeenschap officieel het J2EEplatform als standaard heeft gekozen, blijkt dat binnen de verschillende departemententoch uiteenlopende technologieën worden gebruikt op het vlak van server side scripting.Binnen het departement WVC (Welzijn, Volksgezondheid en Cultuur) worden dewebsites anno 2005 gehost op een verouderde Netscape Enterprise 3.5.1C server. Hetwas duidelijk dat hier weinig mogelijkheden lagen voor het bouwen van een interactievewebapplicatie. Daarom werd uitgeweken naar de servers van een ander departement diegebruik maken van IIS en mogelijkheden bieden tot het gebruik van ASP endatabankkoppelingen. Om budgettaire en praktische redenen werd gekozen voor eenAccess-databank; een programma dat immers bij alle personeelsleden van het MVGgeïnstalleerd is. De keuze voor ASP en Access als basistechnologie voor deze applicatiewordt dus vooral verklaard om eerder "opportunistische" redenen en wijst niet alsdusdanig op een bepaalde voorkeur voor deze technologieën.

1.2 Beschrijving in detail

3


1.2.1 Gebruikte methode

Om de gewenste basisfunctionaliteit meer in detail te beschrijven kan gebruikworden gemaakt van een "Use - Case - diagram" en "scenario's". Op die manier wordende diverse gebruikers in kaart gebracht en wordt een zicht verschaft op de diversemodules die door het systeem moeten worden aangeleverd.

1.2.2 Use-Case-diagram

Klant

Beheerder

Reservatietoevoegen/aanpassen

Identiteits-ficheaanmaken/aanpassen

Kalender /bezettingsgraad

opvragen

Reservatiesgoedkeuren/

weigeren

Authenticatiegebruiker

Gedetailleerdoverzicht

reservaties

Groeptoekennen aan

gebruikers

Figuur 1:Use-case-diagram


4

1.2.3 Scenario's

1.2.3.1 SCENARIO IDENTITEITS- FICHE AANMAKEN/ AANPASSEN

Main Succes Scenario� De gebruiker (klant of beheerder) kan zijn persoonlijke gegevens ingeven via

een webformulier. Persoonlijke gegevens zijn: naam en voornaam, adres vande organisatie, naam van de organisatie, e-mail, telefoongegevens en paswoord.

� Anderzijds kan de gebruiker ook zijn fiche aanpassen. Na inloggen op dewebsite kan de klant een overzicht opvragen van zijn ingevulde gegevens die hijvia een webformulier kan aanpassen.

� Een gebruiker die zijn paswoord vergeten is, kan dat opvragen door zijn eerderopgegeven e-mail- adres in te vullen waarna het systeem de gegevens naar hetopgegeven e-mail-adres verstuurt.

Pre-conditions� Aanmaken van een nieuwe fiche met paswoord en een userid, waarna kan

ingelogd worden.� Ofwel gebruik maken van het eerder aangemaakte paswoord en ID om in te

loggen in de website.Triggers

� Klikken op een hyperlink /knop (“inloggen”, “aanmaken fiche” of “paswoordvergeten”)

1.2.3.2 SCENARIO RESERVATIE TOEVOEGEN/ AANPASSEN

Main Succes Scenario� Aan de hand van een webformulier kan de gebruiker de parameters van zijn

reservatie doorgeven: datum en tijdstip, aantal deelnemers, gewenste zalen,wensen op het vlak van catering, omschrijving van de activiteit en eventueelbijkomende opmerkingen.

� De gebruiker krijgt ook een overzicht van de reservaties die hij al doorgevoerdheeft. Uit die lijst kan hij er een selecteren om aan te passen. De gegevensverschijnen vervolgens onder de vorm van een aanpasbaar webformulier. Degebruiker heeft eveneens de mogelijkheid om een eerder doorgegeven reservatiete verwijderen.

Pre-conditions� Ingelogd zijn met een geldige gebruikersnaam en paswoord� Het centrum en de gevraagde zalen moeten op die welbepaalde datum en uren

nog vrij zijn; op voorhand te controleren aan de hand van de “kalenderfunctie”op de website.


5

Post-conditions� Er wordt een mail gestuurd naar de beheerder waarin de gegevens van de nieuwe

reservatie zijn opgenomen. Dit gebeurt zowel bij het aanmaken van een nieuwereservatie als bij het aanpassen van een reeds ingevoerde reservatie.

Triggers� Klikken op een link ofwel kiezen uit een lijst met de eigen reeds doorgevoerde

reservaties.

1.2.3.3 SCENARIO KALENDER / BEZETTINGSGRAAD OPVRAGEN

Main Succes Scenario� Op de website wordt een overzicht getoond in de vorm van een kalender waarop

aangeduid is wanneer het centrum al dan niet vrij is. De gewone gebruiker kanniet zien wie wanneer heeft gereserveerd. De beheerder kan daarentegen meergedetailleerde informatie te zien krijgen met o.m. de naam van de aanvrager.(zie volgend scenario)

� Ook bij het boeken van een nieuwe reservatie zal de gebruiker kunnen merkenwanneer het centrum nog vrij is.

Pre-conditions� Geen (in een oorspronkelijk scenario werd vereist dat de gebruiker ingelogd

was)Post-conditionsTriggers

� Klikken op een link (“Overzicht”)

1.2.3.4 SCENARIO GEDETAILLEERD OVERZICHT RESERVATIES

Main Succes Scenario� Op de website wordt een overzicht getoond in de vorm van een kalender waarop

aangeduid is wanneer het centrum al dan niet vrij is.� De gewone gebruiker kan niet zien wie wanneer heeft gereserveerd. De

beheerder heeft daarentegen de mogelijkheid om de volledige details van eenbepaalde reservatie op te vragen.

Pre-conditions� Enkel de beheerder heeft de mogelijkheid om meer gedetailleerde informatie in

het overzicht te bekomen en daarvoor zal deze zich eerst als beheerder hebbenmoeten aangemeld.

Post-conditionsTriggers

� Klikken op een link (“Overzicht”).


6

1.2.3.5 SCENARIO RESERVATIES GOEDKEUREN/WEIGEREN

Main Succes Scenario� De beheerder ontvangt een mail waarin de nieuwe reservatie wordt

aangekondigd.� De beheerder krijgt een scherm te zien met een overzicht van alle ingevoerde

reservaties.� De beheerder kan een reservatie ofwel weigeren ofwel toestaan. Aanpassen is

niet mogelijk.Pre-conditions

� De beheerder moet ingelogd zijn onder zijn naam en paswoord.Post-conditions

� Aan de klant wordt een mail verstuurd waarin de beslissing van de beheerder(goedkeuring of weigering) wordt meegedeeld. De beheerder moet ook demogelijkheid krijgen om zelf nog tekst aan deze automatisch verstuurde mail toete voegen

� In de kalender die het overzicht geeft van de bezettingsgraad van het centrumworden de goedgekeurde reservaties ook weergegeven. De reservaties die (nog)niet zijn goedgekeurd worden niet weergegeven in het overzicht.

Triggers� Ontvangen van een e-mail, verstuurd door het systeem.� Klikken op een link (“beheerderspagina”)

1.2.3.6 SCENARIO GROEP TOEKENNEN AAN GEBRUIKERS

Main Succes Scenario� De beheerder ontvangt een mail nadat een nieuwe klant zich heeft geregistreerd

of nadat een bestaande klant zijn gegevens heeft gewijzigd.� De beheerder krijgt een scherm te zien met een overzicht van alle geregistreerde

klanten waarop is aangeduid wie tot welke groep behoort en aan wie nog geengroep is toegewezen.

� De beheerder kan een klant toewijzen aan drie groepen wat zal leiden tot drieverschillende tariefstructuren.

Pre-conditions� De beheerder moet ingelogd zijn onder zijn naam en paswoord

Post-conditions� De klanten krijgen een automatische prijsberekening wanneer zij een nieuwe

reservatie invoeren in het systeem of details van een bestaande reservatieopvragen.

Triggers� Ontvangen van een e-mail, verstuurd door het systeem.� Klikken op een link (“beheerderspagina”)


7

1.2.3.7 SCENARIO AUTHENTICATIE GEBRUIKER

Main Succes Scenario� Via een login-scherm waar de gebruiker paswoord en gebruikersnaam kan

ingeven krijgt deze toegang tot het systeem.� Indien het paswoord of de gebruikersnaam verkeerd zijn, krijgt de gebruiker een

nieuwe kans om zijn gegevens door te geven.Pre-conditions

� De gebruiker moet vooraf een paswoord en gebruikersnaam (e-mail-adres)hebben opgegeven dat is opgeslagen in het systeem.

Post-conditions� Afhankelijk van het soort gebruiker (klant of beheerder) krijgt deze toegang tot

de diverse modules die voor zijn type gebruiker zijn voorbehouden.Triggers

� Op de startpagina van het systeem kan de gebruiker zijn gegevens ingeven ineen webformulier.

2.1 Generieke restricties eigen aan het project

8

Hoofdstuk 2 Restricties in het systeemHet inbouwen van de nodige restricties vormt een van de centrale opdrachten in

een project als dit. Het blijkt dat deze voorwaarden zowel in deapplicatieprogrammatuur zelf als binnen het DBMS geïmplementeerd kunnen worden.

Inhoudelijk kan men de restricties van deze concrete opdracht opdelen in tweecategorieën. Er zijn vooreerst de beperkingen die inherent zijn aan elke applicatie diehet mogelijk moet maken een of andere faciliteit te reserveren. Daarnaast zijn erbepaalde condities die werden opgelegd door de opdrachtgevers van dit project, zijndede verantwoordelijken en leidinggevenden van het centrum. Deze voorwaarden zijnvooral ingegeven uit praktische en organisatorische redenen. De belangrijkste restrictiesworden kort uiteengezet in het volgende overzicht. Later zal worden uiteengezet hoedeze regels technisch werden ingebouwd in de applicatie.

2.1 Generieke restricties eigen aan het project

2.1.1 Overlappingen

Wanneer verschillende gebruikers de mogelijkheid krijgen om een keuze temaken uit een beperkt aanbod aan faciliteiten moeten regels worden afgesproken. Bijhet reserveren van zalen ligt het voor de hand dat een zaal op het zelfde moment nietdoor twee verschillende personen zal kunnen worden geboekt. Binnen dit systeemhebben de gebruikers de mogelijkheid om zelf een zaal van hun voorkeur aan te duiden.Er moet dus worden over gewaakt dat de gebruiker initieel alleen een keuze zal kunnenmaken uit de beschikbare zalen voor een gegeven datum en tijdstip. Slaagt de klant erop een of andere manier toch in om een zaal door te geven die niet meer vrij is, danmoet dit kunnen worden afgewend door de applicatie.

2.1.2 Aantallen

Niet alleen het aantal zalen is beperkt; ook de capaciteit van de ruimtes kentgrenzen. Er moeten dus controles worden voorzien die vermijden dat een klant te weinigzalen boekt voor een gegeven aantal deelnemers. Om die reden is de maximalebezetting van de zalen ook opgeslagen in de databank. Het totaal aantal deelnemers vaneen gegeven reservatie moet kleiner zijn dan de som van de capaciteit van de gevraagdezalen.

2.2 Specifieke restricties eigen aan dit project

9

Binnen deze applicatie krijgen gebruikers ook de mogelijkheid om door te gevenhoeveel deelnemers ook een middagmaal wensen. Hierbij is het niet mogelijk om meerpersonen op te geven dan het aantal deelnemers aan de activiteit. Bijkomend kunnen deklanten aangeven voor hoeveel personen een vegetarische maaltijd moet wordenvoorzien. Ook hier moet worden geverifieerd dat het aantal vegetarische maaltijden nietgroter wordt dan het aantal gewone maaltijden.

2.2 Specifieke restricties eigen aan dit project

2.2.1 Aantal groepen per dag

Op een en dezelfde dag mogen maximaal twee verschillende groepen hetcentrum reserveren. Ook al zijn er nog beschikbare zalen, toch zal het centrum alsvolzet worden beschouwd wanneer er al twee (goedgekeurde) reservaties voor eenbepaalde dag zijn geregistreerd.

2.2.2 Aantal deelnemers per dag

Op een en dezelfde dag mogen maximaal 50 deelnemers aanwezig zijn. Dezevoorwaarde kan eventueel al vervuld worden door 1 groep, dan wel door 2 groepen (ziehierboven). Voor deze regel moet wel een uitzondering worden voorzien voor hetauditorium. Wanneer alleen het auditorium wordt geboekt op een welbepaalde dag danis de toegestane maximale capaciteit 60 deelnemers.

2.2.3 Tijdstip van reserveren

Een reservatie moet minstens 7 dagen voor aanvang van de activiteit wordengeboekt. Ook wijzigingen aan een bestaande reservatie zijn niet meer mogelijk binnen 7dagen voor aanvang van de activiteit.

3.1 Ontwerp d.m.v. een ER-diagram

10

Hoofdstuk 3 Beschrijving van dedatabank


3.1.1 Werkwijze

Aan de hand van een compacte beschrijvende tekst werden de diverse entiteiten,attributen en relaties gedistilleerd. Deze tekst wordt hieronder weergegeven, waarbijook de entiteiten, relaties en attributen worden aangeduid.

- Entiteit- Attribuut- Relatie

Wanneer een klant zich voor het eerst aanmeldt wordt daarvan een fichebijgehouden. Die fiche omvat een uniek identificatienummer, naam, voornaam,organisatie van de aanvrager, adres van de organisatie, e-mail-adres van de aanvrageren telefoon en/of GSM. De klant maakt ook een paswoord aan om later in te loggen inhet systeem. Een aanvrager kan tot drie groepen behoren: ambtenaar van WVC,ambtenaar van het MVG of overige (externe) gebruikers. Deze categorieën bepalen deuiteindelijke kostprijs per persoon van de reservatie. Een reservatie kan wordengeboekt door een klant waarbij deze een of meerdere zalen kan aanduiden. De diversezalen hebben een verschillende capaciteit en verschillende faciliteiten waarover degebruikers kunnen beschikken. Voorts worden ook bijgehouden: begin en einduur,aantal deelnemers en een omschrijving van de activiteit. De gebruiker moet ook zijnwensen doorgeven betreffende de catering: hoeveel personen blijven eten en hoeveeldaarvan willen vegetarisch. Is er drank gewenst bij ontvangst, tijdens de vergadering inde voormiddag en/of tijdens de vergadering in de namidddag. Ten slotte moet degebruiker ook de mogelijkheid hebben om bijkomende opmerkingen of wensen teformuleren. De reservatie is afhankelijk van een goedkeuring door een beheerder.

Deze tekst resulteerde uiteindelijk in een eerste ER-schema dat op de volgendepagina wordt weergegeven.


11

Figuur 2: ER-diagram


12

3.1.2 Bespreking

3.1.2.1 ENTITEITEN

In dit diagram worden vijf entiteitstypes gedefinieerd. Reservatie wordt hierbijbeschouwd als een zwak entiteitstype omdat een reservatie niet kan bestaan zondertussenkomst van een gebruiker. De identificerende relatie is dan ook de relatie "boekt",die in relatie staat met het entiteitstype "gebruiker".

Ook voor de beheerder wordt in dit schema een apart entiteitstype gecreëerd.Daarbij valt direct op dat deze entiteit geen relaties heeft met andere entiteiten en dusenigszins geïsoleerd staat in het schema. Het gebruik van een "Enhanced EntityRelationship" - diagram (zie verder) kan voor deze situatie een meer elegante oplossingaanreiken.

3.1.2.2 ATTRIBUTEN

Voor de entiteitstypes "reservatie" en "gebruiker" werd ervoor geopteerd om eenapart autonummering veld toe te voegen dat fungeert als primaire sleutel. Omdat dezeentiteitstypes uiteindelijk zullen resulteren in tabellen die binnen de applicatie frequentgeraadpleegd zullen worden, kan op die manier vrij compact gerefereerd worden naarde betreffende records in de tabellen. Een samengestelde sleutel, gebaseerd op deinitiële attributen van de tabel, zou de complexiteit van de latere query's alleen maardoen toenemen.

3.1.2.3 RELATIES

In dit schema worden drie relaties onderscheiden. Tussen gebruiker en reservatiebestaan een één op meerdere relatie. Een klant kan immers meerdere reservaties boeken,terwijl een reservatie slechts door één gebruiker kan doorgevoerd zijn. Departicipatiegraad van het entiteitstype "reservatie" is hier totaal. Elke reservatie zalimmers geboekt moeten zijn door een bepaalde gebruiker.

Ook tussen "groep" en "gebruiker" bestaat een één op meerdere relatie. Eengebruiker kan immers slechts lid zijn van één groep, terwijl een welbepaalde groepuiteraard verschillende gebruikers kan omvatten. De participatiegraad van deentiteitstypes in deze relatie is niet totaal. In theorie is het immers mogelijk dat eenbepaalde groep gebruikers niet zou voorkomen in de databank (er zijn bijvoorbeeld geenexterne klanten, maar alleen ambtenaren van het ministerie die zich geregistreerdhebben in het systeem). Anderzijds is niet elke gebruiker op elk moment toegewezenaan een bepaalde groep. Het is de beheerder die de gebruikers toewijst aan een bepaaldegroep. Tussen het moment van registreren als nieuwe gebruiker en de toekenning doorde beheerder is er m.a.w. een tussenperiode waarin de entiteiten "gebruiker" nietgerelateerd zijn aan een welbepaalde groep.


13

Ten slotte bestaat er nog een relatie tussen de entiteitstypes "zaal" en"reservatie". Dit relatietype is een meerdere op meerdere relatie. Een reservatie magimmers meerdere zalen gebruiken en een zaal kan uiteraard door meerdere reservaties(op verschillende tijdstippen) worden gebruikt. Iedere reservatie participeert in derelatie, want een reservatie zonder zalen is niet mogelijk (totale participatie m.a.w.).Anderzijds is het in theorie mogelijk dat een bepaalde zaal nooit gereserveerd wordt,waardoor de participatiegraad langs deze kant van de relatie partieel is.

3.1.2.4 MAPPEN NAAR EEN RELATIONEEL DATABANKMODEL

Om het opgebouwde ER-schema om te zetten naar een relationeel model kan hetalgoritme worden gebruikt zoals dat beschreven wordt in hoofdstuk 7 van het boek"Fundamentals of database systems".1

De vier sterke entiteiten kunnen eenvoudig worden omgezet naar relaties met debijhorende enkelvoudige en samengestelde attributen. Ook het zwakke entiteitstype"reservatie" wordt omgezet naar een eigen relatie. Hierbij moet wel worden aangestiptdat de sleutel in dit geval niet wordt samengesteld uit de primaire sleutel van"gebruiker" en een eventueel partiële sleutel van "reservatie". Ook reservatie kanimmers gebruik maken van een ID - veld met automatische nummering in de Accessdatabank. Reservatie is m.a.w. geen "ID- afhankelijke entiteit".2

Er zijn twee 1:N relatietypes. De primaire sleutel van de relaties dieovereenkomen met de entiteitstype aan de 1-zijde van het relatietype worden dan ooktoegevoegd aan de relaties aan de N-zijde.

Hier kan ook toegelicht worden waarom het entiteitstype "beheerder" in ditschema geen relaties onderhoudt met andere entiteitstypes. Strikt genomen zoudeninderdaad twee relaties kunnen worden aangeduid waarbij "beheerder" betrokken is. Debeheerder staat immers in voor de toekenning van de groepen aan de gebruikers en zorgtook voor de goedkeuring van de reservaties. Dit zou twee 1:N relatietypes opleverenwat bij omzetting naar een relationeel databankmodel tot gevolg zou hebben dat deprimaire sleutel van "beheerder" wordt toegevoegd aan de relaties "gebruiker" en"reservatie". Nu is voorzien dat dit systeem operationeel zal worden met slechts éénbeheerder. Het gevolg hiervan zou zijn dat in de relaties "gebruiker" en "reservatie"steeds dezelfde vreemde sleutel zou worden opgenomen. Het opnemen van de primairesleutel van de tabel "beheerder" zou m.a.w. geen extra informatie toevoegen aan hetmodel omdat de beheerder per definitie gekend is.

Naast de entiteitstypes zal het M:N relatietype "gebruikt" tussen "reservatie" en"zaal" aanleiding geven tot een nieuwe relatie waarin de primaire sleutels van beidebetrokken entiteitstypes als vreemde sleutels worden opgenomen.

1 R. Elmasri and S.B. Navathe, “Fundamentals of database systems”, 4th ed., Addison-

Wesley, 20042 D. Kroenke, “Databases. Beginselen, ontwerp en implementatie”, 8ste ed., Prentice Hall, 2002,

p.57.Deze auteur onderscheidt binnen de groep van de zwakke entiteitstypes een speciaal type: de "ID

-afhankelijke entiteit". Bij zo'n entiteit bevat de identifier van de ene entiteit de identifier van een andereentiteit.


14

3.1.2.5 OVERZICHT VAN HET GECREËERDE DATABANKMODEL

Tabel 1 Databank volgens ER model

GebruikerID, Voornaam, Naam, Straat, Nummer, Stad, E-mail, Telefoon, GSM, Paswoord,Organisatie, Groep (f.k. Groep)

ReservatieID, Beschrijving, Datum, Beginuur, Einduur, Deelnemers, Eters, Vegetariërs, Drankvoormiddag, Drank ontvangst, Drank namiddag, Opmerkingen, Goedkeuring, Klant(f.k. Gebruiker)

GroepNaam, Bedrag, Omschrijving

BeheerderE-mail, Voornaam, Naam, paswoord

ZalengebruikZaal, Reservatie

ZaalNaam, Capaciteit, Flipchart, Overhead, Video, LCD - projector, Microfoon

3.2 Ontwerp d.m.v. een EER-diagram

15


3.2.1 Motivatie voor het gebruik van een EER-diagram

Zoals hoger reeds aangekaart, staat de entiteit "beheerder" enigszins geïsoleerdin het opgebouwde ER - schema. Om deze beheerder ook nauwer in het diagram tebetrekken kan gebruik worden gemaakt van het "Enhanced Entity Relationship"-model.Het gebruik van sub- en superklasses kan het schema verder verfijnen.

Via generalisatie kan een superklasse "gebruiker" worden afgelijnd metdaaronder twee subklassen "beheerder" en "klant". Een beheerder kan inderdaadopgevat worden als een bepaald type gebruiker van het systeem. Naast typischebeheerderstaken (goedkeuren reservaties, toewijzen van groepen aan klanten), kan hijimmers ook optreden als een reguliere gebruiker van het systeem. De beheerder moetimmers ook de mogelijkheid hebben om reservaties toe te voegen aan de databank. Hetis ook duidelijk dat de attributen van het entiteitstype "gebruiker" grotendeelsovereenstemmen met de attributen van het entiteitstype "beheerder".

De twee subklassen kunnen afgebakend worden door het invoeren van een"definiërend predikaat", i.c. het nieuwe attribuut "functie". Dit attribuut kan tweewaarden aannemen: "klant" en "beheerder". De subklassen van de specialisatie zijn"disjunct" (Eng.: "disjoint"). Een gebruiker kan immers niet tegelijkertijd "klant" en"beheerder" zijn in het systeem. Bovendien geldt dat de specialisatie "totaal" is. Erkunnen namelijk geen gebruikers in het systeem voorkomen die noch een beheerder,noch een klant zijn. Elke entiteit die tot de superklasse behoort moet dan ook tot een vande subklassen behoren.

Vanuit deze overwegingen kan dan ook een nieuw "Enhanced EntityRelationship"- diagram worden opgebouwd dat op de volgende pagina wordtweergegeven.


16

Figuur 3: EER-diagram


17

3.2.2 Bespreking

3.2.2.1 RELATIES, ATTRIBUTEN, SUPERKLASSE EN SUBKLASSEN

In dit schema wordt het entiteitstype "beheerder" beter geïntegreerd in hetgeheel. Beide subklassen hebben weinig specifieke attributen maar erven de attributenover van de superklasse "gebruiker". De subklassen verschillen enkel voor wat betrefthet relatietype "lid van", waarbij alleen de entiteiten "klant" betrokken zijn. Debeheerder moet immers niet worden toegewezen aan een bepaalde groep. Het relatietype"boekt" blijft echter op het niveau van de superklasse aangezien zowel de beheerder alsde klanten reservaties moeten kunnen boeken. Om dezelfde redenen als hogeraangehaald is de subklasse "beheerder" niet betrokken in relatietypes met andereentiteiten.

3.2.2.2 MAPPEN NAAR EEN RELATIONEEL DATABANKMODEL

Ook hier kan weer het algoritme worden toegepast zoals beschreven in het hogergeciteerde boek. Het algoritme biedt in stap 8 vier alternatieven. Binnen ditdatabankontwerp werd geopteerd voor optie 8C. Er worden m.a.w. geen aparte relatiesopgebouwd voor de verschillende subklassen. Binnen de relatie "gebruiker" wordt enkeleen type - attribuut "functie" ingevoegd, zodat de aanpassingen aan het eerdergecreëerde model uiteindelijk vrij beperkt blijven. Uiteraard verdwijnt in dit model welde relatie "beheerder" doordat zij vervangen wordt door een record in de tabel"gebruiker" met waarde "beheerder" voor het type- attribuut "functie".

Er werd voor deze optie gekozen omdat het weinig aangewezen lijkt een apartetabel "beheerder" te creëren waarin zich dan slechts één record zou bevinden. In deliteratuur wordt er op gewezen dat deze optie er kan toe leiden dat de databank vele"null" -waarden zal bevatten. In dit geval is die mogelijkheid echter niet aanwezigaangezien er, met uitzondering van het relatietype "lid van" geen specifieke attributenoptreden. Bovendien zal de extentie van dit schema op elk moment maar één entiteitbeheerder bevatten.


18

3.2.2.3 OVERZICHT VAN HET GECREËERDE DATABANKMODEL

Tabel 2 Databank volgens EER model

GebruikerID, Voornaam, Naam, Straat, Nummer, Stad, E-mail, Telefoon, GSM, Paswoord,Organisatie, Functie, Groep (f.k. Groep)

ReservatieID, Beschrijving, Datum, Beginuur, Einduur, Deelnemers, Eters, Vegetariërs, Drankvoormiddag, Drank ontvangst, Drank namiddag, Opmerkingen, Goedkeuring, Klant(f.k. Gebruiker)

GroepNaam, Bedrag, Omschrijving

ZalengebruikZaal, Reservatie

ZaalNaam, Capaciteit, Flipchart, Overhead, Video, LCD - projector, Microfoon

3.3 Integriteit van de databank

19

3.3 Integriteit van de databankDe diverse voorwaarden waaraan de gegevens in de applicatie moeten voldoen

worden gecontroleerd in de applicatie. In de databank werden toch een aantal controlesingevoerd die de integriteit van de gegevens moeten waarborgen. Ter illustratie wordener hier enkele opgesomd.

- RelatierestrictiesBepaalde velden mogen niet groter zijn dan andere velden (b.v. beginuur <einduur). Deze restrictie kan in de Access databank eenvoudig ingevoerdworden door gebruik te maken van expressies onder de vorm van[beginuur]<[einduur]

Deze expressies kunnen worden ingegeven in de ontwerpweergave vanAccess. Door een beperking van Access 97, de versie die in dezeapplicatie gebruikt wordt, kunnen dit soort restricties niet wordeningevoerd op het niveau van de individuele velden, maar moeten zeworden geïmplementeerd op tabelniveau.

- AttribuutrestrictiesDiverse datatypes komen voor in dit databankmodel en kunnen als zodanigook opgelegd worden in de databank (datum/tijd, numeriek, tekst, etc.)

- DomeinrestrictiesHet domein van bepaalde attributen zal b.v. enkel uit positieve gehelegetallen groter dan 0 kunnen bestaan zoals het attribuut "deelnemers" in derelatie reservatie. Ook deze voorwaarde kan opgelegd worden onder de vormvan expressies.

- DatabankrestrictiesAttributen zoals "groep" en "functie" in de relatie "fiche "kunnen bovendienslechts enkele waarden aannemen. Het attribuut "groep" is gerelateerd aan derelatie "groep" en kan enkel de primaire sleutel van die tabel als geldigewaarde bevatten. Dit kan worden afgedwongen door "referentiële integriteit"op te leggen in het dialoogvenster "relaties" van access.Het attribuut "functie" kan slechts twee waarden aannemen: "klant" of"beheerder". Mochten gegevens ooit rechtstreeks in de databank wordeningebracht, dan kan gegarandeerd worden dat enkel die twee waardenworden ingevuld. Daartoe moet dan wel een extra tabel "functies" wordengecreëerd die de twee waarden bevat. In het scherm "eigenschappen" van hetveld "fiche.functie" wordt dan opgegeven dat een keuzelijst moet wordengebruikt met als brongegevens de tabel "functies". Een gelijkaardigeprocedure kan worden gevolgd voor het veld "groep" al moeten de geldigewaarden dan wel opgezocht worden d.m.v. een query.

4.1 De gebruikersmodule

20

Hoofdstuk 4 Beschrijving van deapplicatie


4.1.1 Inloggen

4.1.1.1 MOTIVATIE VOOR BEVEILIGDE TOEGANG

Het gebruik van de applicatie wordt voorbehouden voor geregistreerdegebruikers. Wie een reservatie wil boeken zal een profiel moeten aanmaken waarin depersoonlijke gegevens van de klant werden opgenomen. Pas nadien kan wordeningelogd met het e- mail- adres als user - id en het aangemaakte paswoord.

Er kunnen diverse redenen worden aangebracht om te verantwoorden waarom detoegang tot het systeem is voorbehouden voor geregistreerde klanten. Deregistratieprocedure vormt een buffer die moet vermijden dat willekeurige bezoekersvan de website vrijblijvend gaan "experimenteren" met het systeem en op die maniernietszeggende reservaties gaan boeken. Op deze manier kan dus een zekere vorm vancontrole worden ingebouwd in de applicatie.

Ook de gebruiksvriendelijkheid voor de klant neemt hierdoor toe. Wie ooit on-line het centrum heeft gereserveerd, zal bij een volgende reservatie immers nietopnieuw alle persoonlijke gegevens dienen in te geven. Paswoord en gebruikersnaamvolstaan om de identiteitsfiche uit de databank in te laden.

Deze manier van werken kan er bovendien ook voor zorgen dat de gebruiker eenrealistische prijsberekening ontvangt. Zoals hoger reeds vermeld, is de tariefstructuurvoor de deelnemers afhankelijk van de categorie waartoe de klant behoort. Detoekenning aan de diverse groepen behoort tot de bevoegdheid van de beheerder, dieautomatisch geïnformeerd wordt wanneer iemand een nieuwe klantenfiche heeftaangemaakt. De tussenkomst van de beheerder schrijft de groepsinformatie mee in deidentiteitsfiche van de klant, waardoor deze voortaan een automatische prijsberekeningmeekrijgt. In een "open" omgeving zou dit niet mogelijk zijn en zou de klant zichzelfvolledig arbitrair een bepaalde groep kunnen toekennen.

4.1.1.2 TECHNISCHE REALISATIE

De gegevens uit het inlog - formulier worden doorgegeven naar een volgende,tussenliggende pagina en gebruikt in een querystring waarmee de databank wordtbevraagd. Enkele fragmenten van de gebruikte code wordt hieronder weergegeven.


21

session("fout")=""wie=CStr(request.form("email"))pas=CStr(request.form("paswoord"))connStr = "Driver={Microsoft Access Driver (*.mdb)};"connStr = connSTr & "DBQ=" & server.mappath("cicov.mdb")set conn = server.createobject("adodb.connection")conn.open connStr,"",""set rs2 = Server.CreateObject("ADODB.Recordset")rs2.Open "SELECT * FROM fiche WHERE email='"&wie&"'",conn,adOpenstatic,adLockPessimistic

if rs2("paswoord")=pas then

session("id")=rs2("id")session("fout")=""Session.Timeout=30response.redirect("klantindex.asp")

else

session("fout")="E-mail-adres of paswoord is nietcorrect"

response.redirect("index.asp")

end if

In deze code wordt gebruik gemaakt van een ADODB recordset - object ("rs").Binnen deze applicatie zal evenwel meestal gebruik gemaakt worden van eenconnection object (zie volgende paragraaf voor een korte vergelijking en evaluatie vanbeide methodes).

Indien aan de voorwaarde is voldaan (opgegeven paswoord komt overeen metpaswoord in de databank), wordt een sessie -variabele aangemaakt die de primairesleutel ("ID") bevat uit de tabel "gebruiker" en wordt de gebruiker doorverwezen naarde startpagina voor klanten. Deze variabele wordt binnen de applicatie doorgegeven enzal op de diverse pagina's gebruikt worden om te controleren of de gebruiker weldegelijk ingelogd is. Is dit niet het geval, dan wordt de gebruiker teruggestuurd naar delogin- pagina. Een andere sessie-variabele zorgt voor het doorgeven van een eventuelefoutboodschap naar de login-pagina.

In een eerste ontwerp werden slechts 2 pagina’s gebruikt, nl. een login-pagina eneen klantenindex-pagina. Deze laatste bevatte dan ook de asp-code die verantwoordelijkis voor het controleren van de klantengegevens. Deze methode had echter als nadeel datniet kon teruggekeerd worden naar deze indexpagina zonder telkens opnieuw hetpaswoord en e-mail-adres door te geven aan de pagina. Wanneer binnen de applicatieteruggelinkt werd naar deze pagina werd de gebruiker teruggestuurd naar de login-pagina waar naar zijn paswoord en e-mail-adres werd gevraagd.


22

Om de index-pagina toch te kunnen hergebruiken in het systeem worden deinloggegevens daarom doorgestuurd naar een tussenliggende pagina die instaat voor deverwerking van de login-informatie. Op de nieuwe indexpagina voor klanten volstaathet nu om te controleren of er een geldige sessie is tot stand gebracht om de gebruikertoegang te verlenen. Een nieuwe gebruiker die zijn gegevens pas heeft doorgegeven kannu b.v. automatisch worden doorverwezen (“response.redirect”) naar de klanten-index-pagina, omdat bij het aanmaken van de nieuwe fiche terzelfdertijd een sessie-id werdaangemaakt. Dit was in het oorspronkelijke ontwerp niet mogelijk omdat deklantenindex-pagina paswoord en e-mail van de klant verwachtte als input van eenformulierveld.

Op de klantenindex-pagina krijgt de klant ten slotte ook de mogelijkheid omterug uit te loggen uit het systeem. Hiervoor wordt een hyperlink naar dezelfde paginagebruikt waarin de waarde van een variabele “loguit” op “true” wordt gezet. In dezelfdeif-then-constructie die controleert of er een geldige sessie is, wordt deze variabelegeëvalueerd. Om de bestaande sessie af te breken wordt gebruik gemaakt van demethode “session.abandon”.

4.1.1.3 ADODB RECORDSET OBJECT VS. CONNECTION OBJECT

Om gegevens via ASP uit de databank te halen, te schrijven, aan te passen of teverwijderen, bestaan ruw geschetst twee manieren. Men kan een zogenaamd recordsetobject aanmaken, dan wel gebruik maken van het connection object. In het eerste gevalkan gebruik worden gemaakt van de eigen methodes van het recordset-object zodat infeite geen beroep moet worden gedaan op SQL.

In het tweede geval zal steeds een SQL querystring moeten worden opgestelddie dan als parameter wordt doorgegeven aan de methode "execute" van het connection-object.

De eerste werkwijze heeft als voordeel dat zij vaak compacte, overzichtelijke enal bij al vrij eenvoudige code oplevert. De tweede methode heeft echter als voordeel datzij in principe sneller is en minder belasting zou meebrengen voor de server. Hetgebruik van standaard SQL maakt deze methode ook generieker en minder gebondenaan specifieke technologie van een welbepaalde producent.

4.1.2 Aanmaken/ aanpassen van de persoonlijke fiche

4.1.2.1 INVOEGEN/ AANPASSEN VAN DE GEGEVENS

Via een webformulier wordt de klant gevraagd om een aantal gegevens door tegeven die weggeschreven zullen worden naar de tabel "fiche". Dit formulier bevatuiteraard de attributen zoals die hierboven werden afgebakend in het EER diagram. Deverwerking van het formulier gebeurt door een andere ASP–pagina. Ook hier wordtvoor het wegschrijven naar de databank gebruik gemaakt van het recordset-object.Ter illustratie:


23

…connStr = "Driver={Microsoft Access Driver (*.mdb)};"connStr = connSTr & "DBQ=" & server.mappath("cicov.mdb")set conn = server.createobject("adodb.connection")conn.open connStrset rs = Server.CreateObject("ADODB.Recordset")naam = trim(CStr(Request.Form("naam")))rs.Open "fiche", conn, adOpenDynamic, adLockPessimisticrs.AddNewrs("naam") = naam…

Zoals hoger aangehaald hoeft in deze werkwijze geen beroep te worden gedaanop SQL. Ook het openen van de betrokken tabel kan gebeuren via de methode "open".Bij het updaten van een bepaalde record moet echter wel een SQL-query wordengebruikt die de betrokken record selecteert. In vergelijking met het voorgaande wordt decode dan als volgt aangepast.

rs.Open "SELECT * FROM fiche WHERE id="&wie&"",conn,adOpenDynamic,adLockPessimisticrs.updaters("naam") = naam

De variabele "wie" bevat de waarde van de sessievariabele, die, zoals hogeraangehaald, de primaire sleutel bevat van de klantenfiche van de ingelogde persoon.

4.1.2.2 VALIDATIE VAN DE GEGEVENS

Het doorgeven van parameters via de URL-string houdt een zekerbeveiligingsrisico in. In casu wordt het ID-nummer van de klant die zijn gegevens wenstaan te passen weergegeven in de URL:

http://wwwpre.binnenland.vlaanderen.be/ngob/jan_g/project/fiche.asp?id=14

Het kost weinig moeite om het nummer in de URL te veranderen en op diemanier te proberen de gegevens van iemand anders te bekomen. Het spreekt voor zichdat dit niet alleen een probleem van beveiliging vormt maar ook een mogelijkeschending van de privacy. Om dit soort misbruik te voorkomen is een bijkomendecontrole ingebouwd. Het ID-nummer uit de URL-string wordt vergeleken met het ID-nummer in de sessievariabele. Indien deze niet overeenkomen, wordt de gebruikerdoorverwezen naar de login-pagina. Om foutmeldingen te vermijden indien geen url-parameter werd opgegeven, zal ook in dit geval de gebruiker worden doorgestuurd naarde login-pagina.


24

Er wordt ook gecontroleerd of de datatypes van de input wel geldig zijn. Hetveld "nummer" moet b.v. numeriek zijn wat gecontroleerd kan worden met de methode"isnumeric" van VB-script. Een aantal velden mogen ook niet leeg blijven, zoals naam,e-mail, paswoord , enz. Hiertoe wordt een booleaanse variabele bijgehouden, samen meteen string die een gepaste foutmelding genereert.

Evenmin gewenst is het gebruik van HTML-code in de invoervelden. Hoewel deaangebrachte schade waarschijnlijk beperkt kan blijven, wordt dit bij voorkeur tochopgevangen in het systeem. In bepaalde gevallen zou een gebruiker immers de correctewerking van het formulier kunnen verstoren. Binnen ASP kan voor deze situatiesberoep worden gedaan op de methode "HTMLEncode" van het Server Object. Dezemethode neemt de input als parameter en zal ervoor zorgen dat eventuele HTML-tagsworden omgezet naar de corresponderende "escape characters". Op die manier zal dezeHTML-code niet worden uitgevoerd door de browser maar gewoon op het schermworden getoond. Ter illustratie:

naam= trim(CStr(Request.Form("naam")))naam=server.HTMLEncode(naam)

Ten slotte dient er ook gegarandeerd te worden dat eenzelfde e-mail-adres niettweemaal kan voorkomen in het systeem. Het e-mail-adres vervult immers eenbelangrijke rol in deze applicatie: het fungeert als gebruikersnaam, kan gebruikt wordenom een vergeten paswoord terug te mailen en het wordt gebruikt voor de communicatietussen beheerder. Het e-mail-adres dient echter vooral om samen met het ingegevenpaswoord de gebruiker uniek te identificeren (zie hierboven). Indien hetzelfde e-mail-adres tweemaal in de databank zou voorkomen in combinatie met hetzelfde paswoord,zou de hoger beschreven query twee rijen als resultaat opleveren en wordt de werkingvan het systeem onvoorspelbaar. In feite vormt het e-mail-adres dus een alternatievesleutel van de tabel "fiche". Om die reden wordt bij het aanmaken en aanpassen van deidentiteitsfiche gecontroleerd of een bepaald e-mail adres al niet voorkomt in dedatabank. Bij het aanpassen van de gegevens moet dan wel gegarandeerd worden dat heteigen e-mail-adres niet mee in de controle wordt opgenomen. Zoniet zou een gebruikerdie zijn gegevens aanpast maar zijn e-mail-adres onveranderd laat de melding krijgendat het e-mail-adres al voorkomt in de databank.

4.1.2.3 VERSTUREN VAN ELEKTRONISCHE BERICHTEN

De beheerder moet op de hoogte gebracht worden van een nieuwe of aangepasteidentiteitsfiche. Op dat moment zal hij de gebruiker immers moeten toewijzen aan eenbepaalde groep waardoor de nieuwe klant zijn tariefstructuur kent. Daarom zal hetsysteem zorgen voor een automatische mail naar de beheerder, zodra de nieuwegegevens in de databank werden geplaatst.


25

De servers waar de applicatie wordt gehost kunnen gebruik maken van de"Jmail" e-mail component.3 Deze software volstaat ruimschoots om het elektronischberichtenverkeer van deze applicatie te ondersteunen. Er kan een mailserver wordenopgegeven die de berichten zal verwerken, een adres voor de ontvanger, een onderwerpvoor de mail en uiteraard ook de body-tekst met de velden uit de databank, er kanworden aangeduid of de berichten als HTML, dan wel als tekst moeten wordenverstuurd, enz.

4.1.3 Boeken van een nieuwe reservatie

4.1.3.1 KALENDERPAGINA

De pagina "kalender" vormt een van de centrale pagina's in het systeem. Op dezepagina krijgt de gebruiker een zicht op de beschikbaarheid van de zalen op diversedagen en diverse uren. Wanneer een zaal op een bepaald tijdstip vrij is wordt een linkweergegeven waarvan de URL een aantal parameters van de reservatie bevat (datum,beginuur, toegestaan einduur, etc.) Wanneer het centrum volzet is, hetzij door een teveelaan groepen, hetzij door een teveel aan deelnemers, wordt dit aan de gebruikermeegedeeld en kan hij geen links aanklikken.

Deze pagina is ook bereikbaar voor gebruikers die niet ingelogd zijn. Op dezemanier krijgen derden ook een beperkt zicht op de beschikbaarheid van het centrum.Verdere acties zijn dan uiteraard niet toegestaan. Indien een gebruiker op een van delinks zal klikken om naar de volgende pagina te navigeren zal hij worden doorverwezennaar de startpagina waar hij kan inloggen.

Op deze manier wordt een zekere controle vooraf ingebouwd. Het systeem zalimmers enkel die zalen aanbieden waarvoor gecontroleerd is dat zij op welbepaaldedagen en tijdstippen nog vrij zijn. Deze werkwijze kan echter niet volstaan als bufferom te vermijden dat ongewenste boekingen in de databank terechtkomen (zoals verdernog zal worden besproken). Deze manier van werken moet dus eerder beschouwdworden als een dienstverlening naar de klant die op voorhand al kan nagaan of eenbepaalde reservatie mogelijk is of niet.

Om deze functionaliteit te realiseren, bevat deze pagina twee zelf gecodeerdeVB-script-functies, nl. de functie "printdagen" en de functie "printreservaties". Dediverse restricties die hoger werden opgesomd worden geverifieerd aan de hand vanenkele SQL-queries. Deze technieken worden hierna meer in detail besproken.

3 Jmail is een product van Dimac Development. Een beschrijving van de component kan

gevonden worden op de website http://www.dimac.net/


26

4.1.3.2 DE FUNCTIE "PRINTDAGEN"

Deze functie toont de gebruiker een overzicht met de dagen van de maand naarkeuze. De gebruiker kan de maand en het jaar van zijn keuze selecteren in een dropdown box. De waarden van deze velden worden dynamisch gegenereerd via VB-script-code, waarbij er voor wordt gezorgd dat de laatste keuze die de gebruiker gemaakt heeftgeselecteerd wordt. Naast het huidige jaar zal de gebruiker telkens de keuze krijgen uitde 2 voorgaande jaren en de 2 komende jaren.

De waarden van deze velden leveren de parameters voor de eigenlijke functie"printreservaties" (zie verder). De functie "printdagen" drukt de dagen van de maand afen ordent die in een HTML-tabel. Elke cel bevat een hyperlink naar de huidige paginawaarbij de parameters van de datum in de URL-string worden meegegeven. Klikken opdeze link zal m.a.w. de functie herladen met de nieuwe parameters. De datum vanvandaag wordt in een ander kleur weergegeven. Uiteraard wordt erover gewaakt dat degeproduceerde HTML- code geldig is volgens de regels van het W3 - consortium en datb.v. tabelrijen gesloten worden, cellen binnen een rij worden opgenomen, enz.

Veel webformulieren bieden data louter statisch aan (b.v. in een drop down boxmet een dag-, maand- en jaarveld), waarbij niet uitgesloten kan worden dat onbestaandedata worden ingegeven (b.v. 31 februari). Door de data onder deze vorm te presenterenkan dit worden vermeden. Op deze manier kunnen ook schrikkeljaren wordenopgevangen.

Een niet onbelangrijk detail is het gebruik van de "OK"- knop waarmee degebruiker een andere maand en een ander jaar kan selecteren. Veel webformulierenzullen deze extra knop achterwege laten en het versturen van de formuliergegevensregelen d.m.v. een stukje javascript - code dat reageert op events als "onChange".Binnen het Ministerie van de Vlaamse Gemeenschap wordt deze werkwijze echterontraden. Geleidelijk aan wil men immers komen tot toegankelijke websites die ookdoor blinden en slechtzienden kunnen bekeken worden met zgn. blindenbrowsers. Hetgebruik van een webformulier dat steunt op het "onChange"-attribuut, maakt hetonmogelijk om te navigeren door het formulier op basis van het toetsenbord en is dusontoegankelijk voor deze categorie van gebruikers.

Manipulatie van de URL-string, al dan niet kwaadwillig, blijft ook hiermogelijk. Een gebruiker zou in de URL eventueel een onbestaande datum kunneninschrijven (b.v. 32/13/2006). Om dit soort incidenten te vermijden kan een beroepworden gedaan op de foutbehandeling van VBScript. Aan het begin van de code wordtvolgende code ingevoerd:

On Error Resume Next

Onderaan komt dan:if Err then

response.redirect("kalender.asp")end if

Op deze manier wordt de pagina herladen met de datum van vandaag als input voor defunctie.


27

4.1.3.3 CONTROLE VAN DE RESTRICTIES

Zoals hoger al werd uiteengezet, moet er met diverse restricties rekening wordengehouden. De controle hiervan is belangrijk omdat zij uiteindelijk de output van defunctie "printreservaties" zal bepalen. Zoals wel vaker het geval is, kan bepaaldefunctionaliteit in deze applicatie op diverse wijzen worden gerealiseerd. Ook hierzouden de restricties allicht kunnen worden gecontroleerd d.m.v. ASP/VBScript - codemaar het gebruik van SQL-queries vormt allicht een eenvoudiger en compacteralternatief.

"SELECT * FROM zalengebruik,reservatie WHEREreservatie.datum=#"&maand&"-"&dag&"-"&jaar&"# ANDreservatie.id=zalengebruik.reservatie AND goedkeuring='1'ORDER BY beginuur,einduur"

Deze query haalt alle reservaties op met de datum zoals gekozen door degebruiker. De bevraging van de Access-databank moet gebeuren in het formaat maand -dag - jaar omdat dit anders ongewenst resultaten oplevert (alhoewel de gegevens weldegelijk worden weggeschreven in het formaat dag - maand - jaar en ook zo wordengetoond in de tabel van de databank).

De reservaties die wel al ingevoerd zijn, maar nog niet goedgekeurd door debeheerder worden door deze query dus niet opgehaald en zullen dus ook niet wordenweergegeven in het overzicht. Voor de functie "printreservaties" zal blijken dat hetbelangrijk is dat de recordset geordend wordt op basis van beginuur en vervolgens opeinduur.

SELECT sum(deelnrs) as aantal FROM reservatie WHEREreservatie.datum=#"&maand&"-"&dag&"-"&jaar&"# ANDgoedkeuring='1'"

Op deze manier wordt nagegaan of het totaal aantal toegestane aanwezigen vooreen bepaalde dag nog niet werd overschreden.

SELECT count(id) as aantal FROM reservatie WHEREreservatie.datum=#"&maand&"-"&dag&"-"&jaar&"# ANDgoedkeuring='1'

Deze query telt het aantal groepen dat op een bepaalde dag verondersteld wordtaanwezig te zijn.


28

4.1.3.4 DE FUNCTIE "PRINTRESERVATIES"

Per zaal zal deze functie een overzicht in tabelvorm afprinten, waarbij de reedsgereserveerde uren worden gemarkeerd. De beschikbare uren worden weergegeven dooreen cel waarbinnen een aanklikbare hyperlink is opgenomen. Deze hyperlink leidt debezoeker naar een volgende pagina en bevat een aantal gegevens van de aangevraagdereservatie (zaal, beginuur, maximaal einduur, etc.).

De functie zal in eerste instantie controleren of de restricties al dan niet vervuldzijn en eventueel de mededeling "het centrum is volzet" afprinten.

if not (groepen_totaal>=2 or aantal_totaal>=50) then…else response.write("<table border=""0""width=""100%""><tr><td><fontcolor=""red""><b>VOLZET</b></font><br>Het centrum is volzetop deze datum. Gelieve een andere datum tekiezen...</td></tr></table>")end if

Indien er nog geen twee groepen of 50 deelnemers aanwezig zijn op eenbepaalde datum, zal de rest van de functie worden uitgevoerd. Er wordt gecontroleerd ofeen bepaalde zaal (parameter van de functie) in de recordset voorkomt. Indien dat hetgeval is worden begin - en einduur bijgehouden in twee arrays.

while not rs.eofif rs("zaal")=zaal then

starturen(tel)=rs("beginuur")einduren(tel)=rs("einduur")tel=tel+1

end ifrs.MoveNext

wend

Door gebruik te maken van een "for" - lus die variabelen van het type "time"gebruikt, kunnen de uren van de dag per kwartier worden doorlopen.

start=TimeSerial(8, 30, 00)eind=TimeSerial(17, 15, 00)stap=TimeSerial(00, 15, 00)for i= start to eind step stap…next


29

Binnen de lus wordt gecontroleerd of een bepaald tijdstip al gereserveerd is ofniet. Daartoe wordt de eerder gecreëerde array terug opgeroepen die doorlopen wordtaan de hand van een nieuwe variabele

if Timeserial(hour(i),minute(i),00) =Timeserial(hour(starturen(tel2)),minute(starturen(tel2)),00)then

Indien effectief een reservatie voor de betreffende zaal wordt gevonden, neemteen "while" - lus de taak van de "for"-lus over en zal zij de betreffende uren tot en methet einduur van de vergadering in een bepaalde kleur afdrukken. Uiteraard moet de"counter" van de "for"-lus in deze geneste lus verder worden aangepast en moet na hetbeëindigen van de lus de teller "tel2", die oorspronkelijk op 0 werd geïnitialiseerd,aangepast worden.

while Timeserial(hour(i),minute(i),00) <Timeserial(hour(einduren(tel2)),minute(einduren(tel2)),00)

response.write "<tr><tdbgcolor=""red"">"&hour(i)&"u"&minute(i)&"</td></tr>"i=i+stap

wendtel2=tel2+1

Indien geen reservatie (meer) wordt gevonden, neemt het tweede deel van de lusover. Eerst moet gecontroleerd worden of i de herhalingsvoorwaarde nog niet heeftoverschreden (i werd immers verder geïncrementeerd in de while-lus). Het einduur vaneen eventuele reservatie wordt bijgehouden in een variabele die wordt weggeschrevenin de URL-string en die op een volgende pagina zal dienen om het ultieme einduur vaneen bepaalde reservatie te bepalen. De URL-string bevat voorts ook nog gegevens zoalsde naam en de voornaam van de aanvrager, de datum van aanvraag en de gevraagdezaal.

if not i>=eind then

dag=request.querystring("dag")maand=request.querystring("maand")jaar=request.querystring("jaar")

if not starturen(tel2)="" then

limiet=starturen(tel2)

else

limiet=eind


30

end if

response.write "<tr><td bgcolor=""#EEEEEE""><a href=""reservatie.asp?dag="&dag&"&maand="&maand&"&jaar="

&jaar&"&start="&i&"&zaal="&zaal&"&naam="&naam&"&voornaam="&voornaam&"&limiet="&limiet&""">"&hour(i)&"u"&minute(i)&"</a></td></tr>"

end if

4.1.3.5 VOORSTELLING VAN DE VERGADERZALEN

Boven de tabellen waarin de reservatiestatus wordt weergegeven, staat de naamvan de zaal met daarachter een hyperlink naar een pop-up-venster waarin de zalenworden voorgesteld. Het gebruik van javascript-code om een pop-up-venster te creëren,houdt risico’s in op het vlak van toegankelijkheid van de website. Oudere browsers ofzgn.blindenbrowsers ondersteunen niet noodzakelijk javascript. Daarom wordt de URLvan het pop-up-venster ook nog eens opgenomen in een zgn. “noscript”-tag diezichtbaar wordt wanneer de browser geen javascript ondersteunt.

De inhoud van de pagina’s met de zaleninformatie, nl. het overzicht van defaciliteiten, wordt quasi volledig dynamisch uit de databank gepuurd. Zowel de namenvan de velden als de inhoud ervan worden opgebouwd via VBScript-code.

for each veld in rs.fieldsif not (veld.name="naam" or veld.name="capaciteit") then

if rs(veld.name) then

response.write("<li>"&veld.name&"</li>")

end if

end ifnext

4.1.3.6 VERDERE INVULLING VAN DE RESERVATIE

Op de pagina kalender kan de gebruiker al een eerste keuze maken over degewenste zaal en het gewenste tijdstip. De verdere specificaties kunnen wordeningevuld op een volgende pagina.

Op deze pagina is het startuur dat op de vorige pagina werd geselecteerd alingevuld. Het einduur mag vrij worden gekozen al moet rekening worden gehouden methet beginuur van een eventuele volgende vergadering. Hiervoor wordt de variabele"limiet" gebruikt die op de vorige pagina werd aangemaakt. Met behulp van dezetijdswaarde wordt een drop down box gegenereerd met de beschikbare tijdstippen.Opnieuw wordt hiervoor een "for" lus gebruikt die variabelen van het type "time"gebruikt.


31

<select size="1" name="einduur"><%begin=CDate(request.querystring("start"))begin=TimeSerial(hour(begin), minute(begin), 00)eind=CDate(request.querystring("limiet"))eind=TimeSerial(hour(eind), minute(eind), 00)stap=TimeSerial(00, 15, 00)

for i=begin+stap to eind step stap%><option value="<%=i%>"> <%=hour(i)&":"&minute(i)%></option><%next%>

</select>

Een aantal waarden die op deze pagina worden weergegeven zijn ook van belangvoor de volgende pagina en worden doorgegeven via een "verborgen" formulierveld.Ter illustratie:

<input type="hidden" name="beginuur"value="<%=request.querystring("start")%>">

4.1.3.7 BEVESTIGING VAN DE RESERVATIE

Vooraleer de gegevens naar de databank worden weggeschreven, krijgt degebruiker nog een tussenscherm aangeboden waarop de voorlopige gegevens van diensreservatie worden samengevat. Op deze pagina krijgt de gebruiker ook een overzichtvan andere zalen die op het gekozen tijdstip nog vrij zijn. Deze gegevens worden opvolgende manier uit de databank opgevraagd.

mijnquery = "SELECT zaal FROM zalengebruik,reservatie WHEREreservatie.datum=#"&datumquery&"# ANDreservatie.id=zalengebruik.reservatie AND goedkeuring='1'AND ((#"&beginuur&"# between beginuur AND (einduur-Timeserial(00,15,00))) OR (#"&einduur&"# betweenbeginuur+(timeserial(00,15,00)) AND einduur) OR ((einduur-(Timeserial(00,15,00))) between #"&beginuur&"# AND#"&einduur&"#) OR ((beginuur+Timeserial(00,15,00)) between#"&beginuur&"# AND #"&einduur&"#))"mijnquery="SELECT naam FROM zaal WHERE naam NOT IN("&mijnquery&")"

Op deze manier bevat de recordset de zalen die op een gegeven moment nog vrijzijn. Deze zalen worden dan onderaan de pagina gepresenteerd met een aanklikbarecheckbox.

Op deze pagina krijgt de gebruiker ook al een raming van de kosten van zijnreservatie op basis van het aantal deelnemers en de groep waartoe de klant behoort. Hetbepalen van de groep en het bijhorende bedrag gebeurt als volgt.


32

SELECT fiche.groep as welke, groep.bedrag as hoeveel FROMgroep RIGHT JOIN fiche ON groep.naam=fiche.groep WHEREfiche.id="&wie&"

Een "right join" is hier aangewezen omdat het mogelijk is dat een groep nog nietis toegewezen en de recordset in zo'n geval dus leeg zou zijn. Het bedrag van dereservatie kan vervolgens worden bepaald via een eenvoudige berekening.

if CStr(bepaalgroep("welke"))="0" then

bedrag="Automatische berekening is voorlopig nog nietmogelijk.<br>De beheerder dient u eerst een groep toe tekennen."

else

bedrag=CInt(request.form("deelnrs"))*CInt(bepaalgroep("hoeveel"))&" euro"

end if

4.1.4 Het wegschrijven van de reservatie

4.1.4.1 NOODZAAK VOOR EEN TWEEDE CONTROLE

In de interface van de kalenderpagina werd reeds een controle voorafingebouwd, waardoor het in principe niet mogelijk zou zijn om b.v. overlappendereservaties te boeken. Dit systeem kan echter niet volstaan om de integriteit van dedatabank te beschermen. Er kunnen minstens 2 risico's optreden waardoor de gegevensin de databank niet langer beantwoorden aan de opgelegde restricties.

1. Concurrerende gebruikersIn theorie is het mogelijk dat twee gebruikers min of meer op hetzelfde moment

gebruik maken van het systeem. Stel dat gebruiker A op een bepaald tijdstip "t" inlogt inhet systeem en de status van een bepaalde datum "d" opvraagt. Het is mogelijk dat hetcentrum op datum "d" vrij is en de gebruiker gaat er dus van uit dat zijn reservatie kandoorgaan. Om een of andere reden wacht gebruiker A echter met het boeken van zijnreservatie en ondertussen logt gebruiker B op tijdstip "t"+5' in in het systeem.Gebruiker B wil een reservatie boeken op dezelfde datum als gebruiker A. Omdat dezelaatste zijn reservatie nog niet heeft doorgevoerd zal gebruiker B er van uitgaan dat hetcentrum vrij is en zijn reservatie boeken, zonder te wachten. De beheerder ontvangtdeze reservatie per elektronische post en keurt deze onmiddellijk goed op b.v. "t"+15'.Dit betekent dat het centrum op datum "d" (minstens gedeeltelijk) niet langer vrij is.Indien gebruiker A op tijdstip "t"+20' verder wil gaan met zijn reservatie en zijnwebpagina niet ververst zal de informatie die hij ontvangen heeft, niet langer consistentzijn. Op deze manier kan er dus alsnog een dubbele boeking ontstaan.


33

Het moet gezegd dat deze situatie vrij theoretisch is. Het bovenstaande scenariozou zich bovendien ook moeten afspelen in een tijdsbestek van 30 minuten. Indiengebruiker A langer wacht met ageren zal hij immers geconfronteerd worden met eensessie-time-out, waardoor hij opnieuw moet inloggen. Hierna zal de informatie die hijopvraagt uit de databank wel up-to-date zijn.

2. Manipulatie van de URL-stringOmdat de gegevens van de kalenderpagina worden doorgegeven via de URL-

string zijn zij in principe gemakkelijk vatbaar voor wijzigingen. Een malafide gebruikerzou b.v. de zaalnaam kunnen wijzigen of de begin- en einduren van een bepaaldereservatie. De kalenderpagina genereert enkel URL's voor zalen en uren die nog vrijzijn, maar deze gegevens kunnen niet beschermd worden tegen manuele aanpassingenvan de gebruikers.

Om deze redenen is er nood aan een tweede controle vlak voor de data naar dedatabank worden weggeschreven. Uiteraard zouden bovenstaande situaties ook wel doorde beheerder kunnen worden gedetecteerd.

De controle van deze restricties gebeurt op een vrij analoge manier als eerderuiteengezet. De verschillende voorwaarden worden gecheckt d.m.v. een reeks queries en"if - then" - constructies waarbinnen een booleaanse variabele waar of vals wordtgemaakt. Ondertussen wordt ook een cumulatieve foutmelding bijgehouden in eensessie-variabele (“fout”) die eventueel teruggekoppeld kan worden naar de voorgaandepagina's. Ter illustratie:

checkzalenSQL="SELECT * FROM reservatie, zalengebruik WHEREreservatie.id=zalengebruik.reservatie ANDreservatie.datum=#"&datumquery&"#"

checkzalenSQL=checkzalenSQL&" AND goedkeuring='1' AND((#"&beginuur&"# between beginuur AND (einduur-Timeserial(00,15,00))) OR (#"&einduur&"# betweenbeginuur+(timeserial(00,15,00)) AND einduur) OR ((einduur-(Timeserial(00,15,00))) between #"&beginuur&"# AND#"&einduur&"#) OR ((beginuur+Timeserial(00,15,00)) between#"&beginuur&"# AND #"&einduur&"#))"

set checkzalen=Conn.execute(checkzalenSQL)

overlappingen=checkzalenSQL&" AND zaal IN('"&zaal1&"','"&zaal2&"','"&zaal3&"','"&kleine&"','"&auditorium&"')"

set overlappingen=conn.execute(overlappingen)if not overlappingen.eof then

while not overlappingen.eof


34

session("fout")=session("fout")&"<br>deze zaal isniet meer vrij: "&overlappingen("zaal")overlappingen.movenextoverlappingenok=false

wend

else

overlappingenok=true

end if

In de hierboven opgenomen query wordt gebruik gemaakt van de operator"between" om na te gaan of de uren van een bepaalde reservatie overlappen met reedsbestaande en goedgekeurde reservaties. In access evalueert deze operator ook als waarindien de expressie gelijk is aan de grenswaarden. Dit had tot gevolg dat reservaties dieb.v. eindigden op het moment dat een andere reservatie begon niet werden toegelaten inhet systeem. Om die reden moesten correcties worden ingebouwd waarbij de ene keer15 minuten (Timeserial(00,15,00)) werden bijgeteld en een andere keer 15 minutenwerden afgetrokken.

Via een aantal tests is gebleken dat deze methode toch nog problemen zoukunnen opleveren indien beginuur en einduur slechts 15 minuten van elkaar verschillen.Omdat een reservatie van een kwartier uiteindelijk vrij zinloos is, werd daarom eenbijkomende restrictie in het systeem ingebouwd die oplegt dat een reservatie minstenseen half uur in beslag moet nemen.

4.1.4.2 EXTRA CONTROLES

- Toereikende capaciteitEr wordt gecontroleerd of de capaciteit van de gekozen zalen toereikend is voor

het gevraagde aantal deelnemers. De gegevens over de geselecteerde zalen zijnbeschikbaar in het formulier van de voorgaande pagina en worden in 5 variabelengeplaatst. De waarde van de formuliervelden komt overeen met de namen van de zalenin de tabel zalen van de databank. Indien een zaal niet geselecteerd is, zal dit een legevariabele opleveren.

zaal1=CStr(Request.Form("zaal1"))zaal2=CStr(Request.Form("zaal2"))zaal3=CStr(Request.Form("zaal3"))kleine=CStr(Request.Form("kleine"))auditorium=CStr(Request.Form("auditorium"))

testcapaciteitSQL="SELECT sum(capaciteit)as aantal FROM zaalWHERE naam='"&zaal1&"' OR naam='"&zaal2&"' ORnaam='"&zaal3&"' OR naam='"&auditorium&"' ORnaam='"&kleine&"'"

set testcapaciteit=conn.execute(testcapaciteitSQL)


35

if testcapaciteit("aantal")<deelnrs then

session("fout")=session("fout")&"<br>De capaciteitvan de door u gekozen zalen is ontoereikend"testcapaciteitok=false

else

testcapaciteitok=true

end if

- Juiste verhoudingen deelnemers - personen die middagmaal nemenEr wordt gecontroleerd of het aantal personen die een middagmaal wensen niet

groter is dan het aantal deelnemers en of het aantal vegetarische maaltijden niet groter isdan het aantal aangevraagde maaltijden. Ook gebeurt er een controle op het ingeven vannegatieve getallen. Deze programmacode vraagt weinig toelichting en kan desgewenstteruggevonden worden op de bijgeleverde CD-ROM.

- Minstens 1 zaal opgevenDoor manipulatie van de URL-string zou het eventueel mogelijk zijn om geen

enkele zaal te selecteren. Daarom wordt nagegaan dat minstens 1 zaal geselecteerdwerd. Ook voor deze code kan verwezen worden naar de CD-ROM.

- Geldige datumZoals hoger uiteengezet kan een reservatie niet voor een activiteit die plaatsvindt

op minder dan 7 dagen van de reservatiedatum. Uiteraard is het ook niet wenselijk datreservaties geboekt worden op een datum die in het verleden ligt. Door aanpassing vande parameters in de URL zou het eventueel ook mogelijk kunnen zijn om een reservatiete boeken waarvan het beginuur later is dan het einduur of die begint vóór 8:30u ofeindigt ná 17:30u. Ook dit oneigenlijk gebruik wordt opgevangen in het systeem. Voorde code wordt andermaal verwezen naar de CD-ROM.

- Verplichte veldenEen aantal gegevens moeten verplicht worden doorgegeven zoals een

omschrijving van de activiteit. Wanneer dit veld dan ook niet is ingevuld, zal detransactie niet kunnen doorgaan.

4.1.4.3 UPDATE VAN DE DATABANK

De verschillende controles die hierboven werden geschetst leveren telkens eenbooleaanse variabele op die nadien gebruikt wordt in een if - then -controlestructuur.Pas wanneer aan alle voorwaarden is voldaan kan het eigenlijke aanpassen van dedatabank gebeuren. Zoniet wordt de gebruiker teruggeloodst naar de reservatiepagina enkrijgt hij de foutboodschap te lezen die gegenereerd werd bij het controleren van derestricties.

Het wegschrijven naar de databank verloopt in een aantal stappen. Er moetenimmers twee tabellen worden aangepast: de tabel reservatie en de tabel zalengebruik. Ineerste instantie wordt een nieuwe record reservatie toegevoegd aan de tabel reservatie.


36

SQL = "INSERT INTO reservatie(beschr,datum,beginuur,einduur,deelnrs,eters,veget,drankontv,drankvoorm,dranknam,opm,klant)"SQL = SQL & " VALUES ('" & beschr & "','" & datum & "','" &beginuur& "','" & einduur& "','" & deelnrs& "','" & eters&"','" & veget& "','" & drankont& "','" & drankvoorm& "','" &dranknam& "','" & opm& "','" & klant& "')"

Vervolgens moet de tabel zalengebruik worden aangepast. Daartoe is deprimaire sleutel ("ID") nodig van de nieuw toegevoegde reservatie. Deze waarde kan alsvolgt worden gevonden. Door het gebruik van automatische nummering binnen Accesszal het primaire sleutelveld immers automatisch de hoogste waarde hebben voor een pasingevoerde record.

SELECT * FROM reservatie WHERE id=(SELECT max(id) FROMreservatie)

Met dit gegeven kan vervolgens de tabel zalengebruik worden aangevuld. Er zalwel telkens moeten worden gecontroleerd of een bepaalde zaal al dan niet gekozen werddoor de klant. Dit resulteert voor elk van de 5 zalen in de volgende code (waarbijuiteraard telkens de naam van de zaal wordt aangepast).

if not zaal1="" thenSQL="INSERT INTO zalengebruik(zaal,reservatie)"SQL=SQL & "VALUES ('"& zaal1&"','"&reservatieid&"')"Conn.Execute(SQL)

end if

4.1.4.4 BERICHTGEVING AAN DE BEHEERDER

Zoals dat ook het geval is bij het aanmaken van een nieuwe identiteitsfiche,wordt de beheerder na een reservatie per e-mail op de hoogte gebracht van de nieuwereservatie.

4.1.5 Aanpassen bestaande reservatie

4.1.5.1 OVERZICHT

Een klant heeft de mogelijkheid om een lijst op te vragen van de reservaties diehij zelf heeft doorgevoerd. Per reservatie krijgt de klant vier mogelijkheden:

- Bewerken (alle parameters van de reservatie kunnen worden aangepastbehalve datum en tijdstip)


37

- Tijdstip Datum en /of uur wijzigen (tijdstip van de reservatie kan wordengewijzigd maar niet de andere parameters)

- Annuleren (verwijderen van de reservatie)- Bekijken (detailfiche van de reservatie zonder mogelijkheid tot wijzigen)

Op het eerste gezicht kan het eigenaardig lijken om het beheer van de eigenreservatie op te splitsen in vier verschillende componenten. Er kunnen een aantalargumenten worden aangehaald om deze keuze te verantwoorden.

Vooreerst lijkt het aannemelijk dat een klant meestal niet tegelijkertijd de datumen de parameters van een reservatie zal wensen aan te passen. In het eerste geval zalgewoon een ander tijdstip gewenst worden voor een reservatie die voor het overigeongewijzigd kan blijven. In het tweede geval zal de klant gewoon enkele details aan eenbestaande reservatie wensen te wijzigen, waarbij het tijdstip ongewijzigd mag blijven.Indien toch beide kenmerken van de reservatie moeten aangepast worden, lijkt hetlogischer om deze reservatie gewoon te verwijderen en een nieuwe te boeken.

Op deze manier wordt de klant terug verwezen naar de kalenderpagina waar hij apriori een overzicht krijgt van de mogelijke data en zalen, wat klantvriendelijker is daneerst alle parameters van een reservatie te wijzigen om dan te moeten vaststellen dat dereservatie niet kan worden geboekt wegens allerlei restricties. Een volledige aanpassingvan een bestaande reservatie blijft binnen deze optiek overigens mogelijk maar zal danin twee stappen moeten gebeuren.

De applicatiecode voor deze opties bevindt zich binnen eenzelfde pagina,waarbij de verschillende modules opgeroepen worden aan de hand van de waarde vaneen variabele in de URL.

4.1.5.2 DE DETAILFICHE VAN DE RESERVATIE

In een eerste ontwerp werden alle gegevens van de reservatie gepresenteerdonder de vorm van formuliervelden. Zoals uiteengezet mochten deze formulierveldenniet zonder meer worden aangepast. De editeerbare velden werden bepaald aan de handvan de URL parameter "actie". Om de velden die niet mogen worden aangepast uit teschakelen werd gebruik gemaakt van het HTML - attribuut "disabled". Per veld moestdus worden gecontroleerd welke actie de gebruiker had gekozen en indien nodig zou dewebpagina het attribuut "disabled" in de HTML- code inschrijven bij het betreffendeveld. Dit gebeurde aan de hand van de volgende statements:

<%if not actie="bewerk" then%> disabled <%end if%>


38

Het grote minpunt aan deze werkwijze lag echter in het feit dat het attribuut"disabled" niet ondersteund bleek te worden door browsers als Netscape 4.5. Allevelden bleven m.a.w. editeerbaar. Hoewel deze browser totaal verouderd is, wordt hijanno 2005 toch nog vrij frequent gebruikt binnen het Ministerie van de VlaamseGemeenschap. Daarom werd uiteindelijk voor een alternatieve werkwijze gekozen,waarbij formuliervelden enkel gebruikt werden om data te presenteren die ook effectiefmogen worden aangepast. De niet aanpasbare gegevens zullen verschijnen onder devorm van statische tekst. De details over de technische uitwerking komen verder aanbod.

De checkboxes die aangeven welke keuzes de gebruiker heeft gemaakt op hetvlak van dranken worden aangevinkt door het attribuut "checked" op de gepasteplaatsen in te schrijven in de HTML-code.

mijnquery="SELECT * FROM zalengebruik,reservatie WHEREreservatie.id="&wat&" ANDzalengebruik.reservatie=reservatie.id"Set rs = Conn.Execute(mijnquery)

if rs("drankvoorm")="ja" then response.write("checked")end if

4.1.5.3 BEWERKEN VAN DE RESERVATIE

Werkwijze met het attribuut "disabled"De gegevens van de reservatie kunnen op vrij eenvoudige manier uit de

databank worden opgevraagd en weergegeven in de formuliervelden. Het correctweergeven van de zalen is iets complexer. Ook hier is het immers wenselijk om degebruiker op voorhand de kans te ontnemen om een zaal te boeken die reedsgereserveerd werd. Deze functionaliteit kan gerealiseerd worden aan de hand van tweekleine zelf gecodeerde VB- script- functies.

In eerste instantie worden de zalen opgevraagd die al niet meer vrij zijn op degegeven datum. Binnen deze recordset worden ook de zalen opgenomen die degebruiker in kwestie zelf heeft gereserveerd. Deze situatie moet dan ook wordenopgevangen in de applicatiecode. Dezelfde SQL-query die toegepast werd bij hetwegschrijven van de reservatie, kan hier opnieuw worden gebruikt.

De eerste functie biedt gelijkaardige functionaliteit als hoger beschreven, nl. hetinschrijven van het attribuut "checked" in de code, wanneer een bepaalde zaalgereserveerd werd door de gebruiker. Indien dit het geval is, wordt tevens een booleanbijgehouden die zijn belang zal hebben in de volgende functie.


39

function check(zaal,bzaal)do while not rs.eof

if rs("zaal")=zaal thenresponse.write("checked")

bzaal=trueexit do

end if rs.movenext loop rs.movefirstend function

Een tweede functie zorgt ervoor dat reeds gereserveerde zalen niet meer kunnenworden geselecteerd door de gebruiker. Dit mag echter niet gebeuren met de zalen diedoor de gebruiker zelf werden geselecteerd. De gebruiker moet immers de mogelijkheidkrijgen om deze zalen eventueel niet langer aan te vinken. Daartoe dient de boolean diein de functie hiervoor werd aangemaakt. Het attribuut "disabled" zal enkel in de HTML- code worden geschreven wanneer de zaalnaam (parameter van de functie) gevondenwordt in de recordset rs3 (reeds geboekte reservaties op een bepaalde datum) én nietgevonden werd in de recordset rs (eigen reservaties).

function disabled(zaal,bzaal)do while not rs3.eof

if rs3("naam")=zaal and not bzaal thenresponse.write("disabled")exit do

end ifrs3.movenext

loopif not rs3.bof then

rs3.movefirstend if

end function

De HTML- code voor de respectievelijke zalen ziet er dan ook als volgt uit. Terillustratie:

<input type="checkbox" name="zaal2" value="zaal2"><%check "zaal2",zaal2%> <%disabled "zaal2",zaal2%>

Werkwijze zonder het attribuut disabled Omdat de hiervoor beschreven werkwijze onvoldoende ondersteund werd in ouderebrowsers moest een alternatief worden uitgewerkt, dat weliswaar nog enigszins konbogen op de oorspronkelijk uitgewerkte code. Afhankelijk van de door de gebruikergekozen actie zullen de gegevens nu verschijnen onder de vorm van een formulierveld,dan wel onder de vorm van niet editeerbare tekst. Ter illustratie:


40

<%if actie="bewerk" then%> <input type="text" name="deelnrs" size="3"value="<%=rs("deelnrs")%>">(maximum toegestaan: <%=50-aantal_totaal%>)<%else%>

<%=rs("deelnrs")%>

<%end if%>

Hiervoor moesten ook de hoger beschreven functies "disabled" en "check"worden aangepast.

function check(zaal,bzaal,zaalnaam)bzaal=false

do while not rs.eof

if rs("zaal")=zaal then

bzaal=trueresponse.write("<input type=""checkbox""

checked name="""&zaal&"""value="""&zaal&""">"&zaalnaam&"<br>")

exit do

end ifrs.movenext

looprs.movefirst

end function

function disabled(zaal,bzaal,zaalnaam)

bezet=falseif not rs3.bof then

rs3.movefirst

end ifdo while not rs3.eof

if (rs3("naam")=zaal and not bzaal) then

bezet=true

end ifrs3.movenext


41

loop

if not bezet and not bzaal then

response.write("<input type=""checkbox""name="""&zaal&""" value="""&zaal&""">"&zaalnaam&"<br>")

end if

end function

4.1.5.4 TIJDSTIP WIJZIGEN

Het wijzigen van datum en / of tijdstip kan opnieuw gebeuren aan de hand vande hoger beschreven kalender functie. De gebruiker krijgt de dagen van een bepaaldemaand dus gepresenteerd onder de vorm van een HTML- tabel waarmee vermedenwordt dat onbestaande data worden opgegeven. Deze tabel moet worden ingeschrevenin de bestaande tabel met het overzicht van de reservatiegegevens.

4.1.5.5 RESERVATIE BEKIJKEN

In deze weergave zijn alle velden niet editeerbaar. Enerzijds overlapt dit schermwel met de module "bewerken" maar op deze manier wordt wel vermeden dat eengebruiker per ongeluk gegevens wijzigt, terwijl hij gewoon zijn reservatie wenst teraadplegen.

4.1.5.6 RESERVATIE VERWIJDEREN

Deze functionaliteit wordt besproken in het volgende hoofdstuk.

4.1.6 Aanpassen van de databank

Het aanpassen van de databank gebeurt op een volgende ASP-pagina waar degepaste code geselecteerd wordt aan de hand van de waarde van de variabele "actie".

4.1.6.1 VERWIJDEREN VAN EEN RECORD

Bij het verwijderen van een reservatie moet er rekening mee worden gehoudendat deze informatie verspreid is over twee tabellen in de databank, nl. de tabel reservatieen de tabel zalengebruik. Er zijn dan ook twee queries nodig om de reservatie teverwijderen.


42

DELETE * FROM reservatie WHERE reservatie.id="&wat&"DELETE * FROM zalengebruik WHEREzalengebruik.reservatie="&wat&"

4.1.6.2 BEWERKEN BESTAANDE RESERVATIE

Vooraleer de aangepaste gegevens naar de databank kunnen worden geschrevenmoeten opnieuw de verschillende controles gebeuren die eerder al werden beschrevenbij de bespreking van de verwerking van een nieuwe reservatie. De manier van werkenis dan ook vrij analoog met de methodes die daar besproken werden. Indien aan een vande voorwaarden niet is voldaan wordt de gebruiker terug verwezen naar de vorigepagina met een aangepaste foutmelding als feedback. De queries zullen uiteraardverschillen naargelang de gegevens die de gebruiker wenst te wijzigen:

Bij het aanpassen van het tijdstip moet enkel de tabel reservaties wordenaangepast. Belangrijk hierbij is dat het veld goedkeuring terug op '0' wordt gezet omdatde beheerder zich nu opnieuw zal moeten uitspreken over de gewijzigde reservatie.

UPDATE reservatie SETdatum=#"&datumquery&"#,beginuur=#"&beginuur&"#,einduur=#"&einduur&"#, goedkeuring='0' WHERE id="&wat&""

Bij aanpassing van de andere parameters van de reservatie kunnen zowel degegevens van de tabel reservaties als de tabel zalengebruik gewijzigd zijn. Controlerenwelke velden al dan niet gewijzigd zijn door de gebruiker in vergelijking met deoorspronkelijke record is vrij omslachtig. Om die reden worden alle velden van derecord aangepast.

UPDATE reservatie SETbeschr='"&beschr&"',deelnrs="&deelnrs&",eters="&eters&",veget="&veget&",drankontv='"&drankontv&"',drankvoorm='"&drankvoorm&"',dranknam='"&dranknam&"',opm='"&opm&"', goedkeuring='0' WHERE id="&wat&""

De informatie over de gebruikte zalen in de tabel "zalengebruik" kan echter nietop een analoge manier up-to-date worden gebracht. Een reservatie kan immers meerderezalen bevatten wat dan ook meerdere records in de tabel zal opleveren. Daarom wordende oude gegevens in de tabel zalengebruik eerst gewist en worden vervolgens deaangepaste gegevens opnieuw ingeschreven. Dit laatste gebeurt uiteraard op eenidentieke manier als hoger beschreven bij de bespreking van de verwerking van eennieuwe reservatie.


43

4.1.7 Overzicht reservaties per maand

Om de gebruiker ook een zicht te bieden op de status van het centrum permaand, werd nog een aparte overzichtspagina gecreëerd. Op deze pagina wordt detoestand van het centrum weergegeven per maand. De opbouw van deze pagina isgrotendeels gebaseerd op de hoger beschreven functie “printdagen” waaraanbijkomende functionaliteit werd toegevoegd. Net zoals bij de pagina “kalender” is geenlogin vereist en kunnen “gasten” de informatie zonder meer consulteren.

De pagina geeft grafisch en tekstueel weer welke reservaties op een gegeven dagnog mogelijk zijn. Daartoe wordt in de code gecontroleerd hoeveel groepen en hoeveeldeelnemers op een bepaalde dag aanwezig zijn. Om de gegevens van een welbepaaldemaand te presenteren wordt gebruik gemaakt van volgende query-string:

SELECT * FROM reservatie WHERE reservatie.datum>=#"&maand&"-1-"&jaar&"# AND reservatie.datum <=#"&maand&"-"&dagen&"-"&jaar&"# AND goedkeuring='1' ORDER BYbeginuur,einduur

Afhankelijk van het aantal deelnemers en groepen wordt de inhoud van eenvariabele bepaald. De waarde van deze variabele verwijst naar een “CSS-class” in destylesheet, waar een achtergrondafbeelding en voorgrondskleur worden vastgelegd. Elkecel van de tabel bevat een cijfer met de dag van de maand waarachter een link zit naarde pagina kalender voor de geselecteerde datum. Twee grafische knoppen bieden demogelijkheid om naar de volgende, dan wel de vorige maand te navigeren. Voor decode kan worden verwezen naar de CD-ROM

4.2 De beheerdersmodule

44

4.2 De beheerdersmoduleVoor de beheerder werden een aantal specifieke modules ontwikkeld. Daarnaast

kan de beheerder ook grotendeels gebruik maken van de functionaliteit die ook voor degewone gebruikers ter beschikking is. Deze modules worden hier uiteraard niet opnieuwbesproken.

4.2.1 Inloggen

Uiteraard moet er voor de beheerder een eigen controle gebeuren op de login-gegevens. Ook hier wordt daarvoor een tussenliggende pagina gebruikt die dient alsdoorgeefluik tussen de login-pagina en de eigenlijke hoofdpagina van de beheerder. Omde gegevens van de beheerder terug te vinden in de databank kan gebruik gemaaktworden van het “discriminerende attribuut” “functie”. Alleen de record in de tabel“fiche” waar dit veld de waarde “beheerder” heeft, kan immers de gegevens vanbeheerder bevatten. De corresponderende code wordt dan ook:

wie=CStr(request.form("email"))pas=CStr(request.form("paswoord"))rs.Open "SELECT * FROM fiche WHERE functie='beheerder'",conn,adOpenstatic,adLockPessimisticif rs("paswoord")=pas and rs("email")=wie then

session("beheerder")=rs("id")session("id")=rs("id")Session.Timeout=30response.redirect("beheerder.asp")session("fout")=""

elsesession("fout")="E-mail-adres of paswoord is niet

correct"response.redirect("loginbeheerder.asp")

end if

Er wordt dus ook een gebruikerssessie (session(“id”)) toegekend aan debeheerder. Daarmee heeft hij ook toegang tot de modules van gewone gebruikers en kanhij desgewenst ook zelf reservaties gaan toevoegen.

4.2.2 Overzicht en beheer reservaties

De beheerder kan op twee manieren een overzicht krijgen van de reservaties vanhet centrum. De eerste manier is min of meer analoog met het hoger beschrevenoverzicht per maand voor de gebruikers. De tweede mogelijkheid laat de gebruiker toeom het overzicht te verfijnen aan de hand van een aantal criteria die hij kan doorgevenvia een webformulier.


45

4.2.2.1 GRAFISCH OVERZICHT PER MAAND

De functionaliteit zoals hoger beschreven bij de gebruikersmodule werdovergenomen met enkele aanpassingen. De beheerder moet immers de mogelijkheidkrijgen om de detailgegevens van een bepaalde reservatie te consulteren.

Voor elke dag in het overzicht wordt gecontroleerd of voor die welbepaaldedatum een reservatie aanwezig is in de databank. Indien dat het geval is dan wordenbegin- en einduur van deze reservatie weergegeven in de tabel met een link naar deovereenkomstige detailpagina (zie verder).

for i=1 to day(dagen)…

WHILE NOT rs.EOF

if day(rs("datum"))=i then

id=rs("id")beginu=formatdatetime(rs("beginuur"),4)eindu=formatdatetime(rs("einduur"),4)response.write("<ahref=""detailbeheerder.asp?id="&id&""">"&beginu&" tot "&eindu&"</a><br>")

else

response.write(" <br>")

end if

rs.MoveNextwend

…next

Uiteraard mag de bevraging van de databank hier niet alleen de reservatiesopleveren die goedgekeurd werden, zoals hoger. De voorwaarde “goedkeuring='1'”wordt dus niet opgenomen in de querystring.

4.2.2.2 OVERZICHT OP BASIS VAN CRITERIA

De beheerder beschikt ook over de mogelijkheid om een overzicht te verkrijgendat beantwoordt aan een aantal criteria. De lijst met reservaties kan wordenweergegeven op basis van de criteria “goedkeuring”, “klant”, “maand” en “jaar”. Deverschillende criteria kunnen uiteraard worden gecombineerd zodat het b.v. mogelijk isom van een bepaalde klant de niet goedgekeurde reservaties van een bepaalde maand opte vragen.

De input van de formuliervelden wordt gebruikt om inhoud toe te kennen aanvariabelen die als onderdeel van een querystring fungeren.

Ter illustratie:


46

maand=request.form("maand")jaar=request.form("jaar")

if not maand="" and not jaar="" then

zoekmaand=" AND month(reservatie.datum)="&maand&" ANDyear(reservatie.datum)="&jaar&""

else

zoekmaand=""

end if

De querystring wordt bijgevolgd opgebouwd aan de hand van de keuzes die doorde beheerder zijn gemaakt.

SELECT * FROM fiche,reservatie WHEREreservatie.klant=fiche.id ANDreservatie.goedkeuring='"&goedkeuring&"'"&zoeknaam&zoekmaand&zoekjaar&" ORDER BY reservatie.datum

In het overzicht dat aan de beheerder wordt getoond zal in elk geval met eengrafisch element worden aangeduid of de betreffende reservatie goed-of afgekeurdwerd, ofwel nog onbeslist is. Deze informatie is immers van cruciaal belang omdat debeslissing over de reservaties een van de belangrijkste taken van de beheerder vormt.

4.2.2.3 DETAILWEERGAVE RESERVATIES

Het opvragen van alle gegevens van een reservatie kan eenvoudig gebeuren viavolgende query.

SELECT * FROM fiche,reservatie,zalengebruik WHEREreservatie.klant=fiche.id ANDreservatie.id=zalengebruik.reservatie ANDreservatie.id="&wat&"

Hierbij wordt de inhoud van de variabele “wat” uiteraard bepaald door de parameter diewerd meegegeven in de URL-string met de link naar de detailpagina.

Op de pagina worden de gegevens van de reservatie niet alleen gepresenteerdaan de beheerder, maar wordt er ook een actie van zijn kant verwacht. Via een dropdown menu kan de beheerder immers een beslissing over deze reservatie doorgeven. Deactuele status van de reservatie wordt eveneens getoond aan de beheerder (goedgekeurd,niet goedgekeurd of nog niet beslist). Deze beslissing wordt vervolgens per e-mailgecommuniceerd aan de klant die de reservatie had geboekt. De beheerder kan demotivatie van zijn beslissing meesturen aan de klant via een invulveld dat ook op depagina wordt weergegeven.


47

4.2.3 Toekenning groepen

4.2.3.1 LIJST GEBRUIKERS

De beheerder kan een lijst opvragen van alle klanten die geregistreerd zijn in hetsysteem. Daarbij wordt met een grafisch element aangegeven aan welke groep degebruiker werd toegewezen. Ook de gebruikers waarvoor nog geen beslissing werdgenomen worden als dusdanig gemarkeerd. Deze functionaliteit kon eenvoudig wordengerealiseerd aan de hand van een "select case" controlestructuur.

while not rs.eofselect case rs("groep")

<%case "wvc"%> <tr><td><div align="center"><img src="groen.gif"alt="Groep WVC, 0 euro"></div></td> <td valign="top"><ahref="detailklant.asp?id=<%=rs("id")%>"><%=rs("naam")&""&rs("vnaam")%></a></td>

</tr>…

end selectrs.movenextwend

Voor de verschillende waarden die het veld "groep" kan aannemen zal dustelkens een andere afbeelding worden geselecteerd.

4.2.3.2 DETAILPAGINA FICHE KLANT

Het hiervoor beschreven overzicht bevat een lijst met links die de beheerder naarde overeenkomstige detailpagina brengt. Hier wordt een overzicht gegeven van dediverse persoonsgegevens van de klant. Daarnaast wordt ook weergegeven tot welkegroep de klant momenteel behoort.

De beheerder kan zijn beslissing doorgeven via een drop down menu waarvan deinhoud volledig uit de databank geëxtraheerd wordt. Op die manier zal dit formulierveldsteeds actueel zijn ook als de groepen worden gewijzigd.

<%while not groeprs.eof%><option value="<%=groeprs("naam")%>"><%=groeprs("omschrijving")%> (<%=groeprs("bedrag")%>euro per persoon)</option> <%groeprs.movenext

wend%>


48

Bovendien kan op deze manier ook de referentiële integriteit tussen de tabellen "fiche"en "groep" worden gewaarborgd. Het veld "groep" van de tabel fiche mag immers enkelde waarden van de primaire sleutel van de tabel "groep" bevatten. Het is net dezewaarde die via het formulier zal worden doorgegeven aan de volgende pagina die instaatvoor het aanpassen van de databank.

wie=CInt(request.form("id"))beslis=CStr(request.form("goedk"))mijnquery="UPDATE fiche set groep='"&beslis&"' WHEREid="&wie&""

De waarde "wie" werd via een verborgen formulierveld doorgegeven vanuit devoorgaande pagina's.

5.1 Encryptie

49

Hoofdstuk 5 Beveiliging van de data

5.1 EncryptieDe paswoorden van de gebruikers worden onder geëncrypteerde vorm

opgeslagen in de databank. Voor deze encryptie wordt gebruik gemaakt van het "RC4"algoritme, dat oorspronkelijk ontworpen werd door "RSA Data Security".4 Eenbelangrijk kenmerk van dit algoritme is zijn symmetrisch karakter. Dit betekent dathetzelfde algoritme gebruikt kan worden voor zowel encryptie als decryptie van de data.Decryptie van het opgeslagen paswoord is van belang wanneer een gebruiker zijnpaswoord is vergeten en gebruik maakt van de mogelijkheid om dit paswoord naar diense-mail-adres te versturen.

Het gebruik van een encryptietechniek impliceert uiteraard dat het paswoord datde gebruiker opgeeft nooit onder zijn ongecodeerde vorm kan gebruikt worden in dedatabank. Bij het inloggen zal het paswoord van de gebruiker dan ook eerst moetenversleuteld worden in de encryptiefunctie, vooraleer gecontroleerd kan worden of ditpaswoord overeenkomt met de gegevens die in de databank werden opgeslagen (ziehoger).

5.2 Beveiliging databank d.m.v. een paswoordDe toegang tot de accessdatabank wordt beschermd met een paswoord. De

ASP-pagina's die een connectie met de databank willen maken zullen dit paswoord danook moeten meesturen in hun connectiestring. Deze connectiestring zal dan volgendevorm aannemen:

connStr = "Driver={Microsoft Access Driver (*.mdb)};"connStr = connSTr & "DBQ=" & server.mappath("cicov.mdb")set conn = server.createobject("adodb.connection")conn.open connStr,"","paswoord"

5.3 Beveiligde directoryDe databank zelf wordt in een beveiligde directory geplaatst waar gewone

gebruikers in principe geen toegang toe hebben. Ook een aantal andere bestandenkunnen op deze beveiligde locatie worden opgeslagen:

- De connectiestring met bijhorend paswoord kan worden opgenomen in een"include-file", die dan in de diverse pagina's moet worden ingevoegd.

4 Een beschrijving met de bijhorende broncode is te vinden op de website

http://www.4guysfromrolla.com/webtech/010100-1.shtml#postadlink

5.3 Beveiligde directory

50

- Het algoritme dat instaat voor de encryptie van de paswoorden werdeveneens in een afzonderlijke "include-file" geplaatst. Door het in debeveiligde directory te plaatsen wordt verhinderd dat bezoekers eventueel degebruikte encryptiemethode zouden kunnen achterhalen.

6.1 Reservatie voor meerdere dagen

51

Hoofdstuk 6 Mogelijke uitbreidingenHet project dat beschreven werd in deze tekst, zal zeker nog verdere

uitbreidingen kunnen ondergaan. Een tweetal denkpistes worden hierna al kortaangeraakt.

6.1 Reservatie voor meerdere dagenHet huidige systeem laat aan een gebruiker enkel toe om een reservatie voor één

welbepaalde dag te boeken. Occasioneel kan het echter voorvallen dat een klant eenzelfde activiteit wil laten herhalen over een zekere periode.

Het boeken van zo'n recurrente activiteit mag op zich weinig problemenopleveren. Binnen de beschouwde periode wordt elke dag individueel als nieuwereservatie geboekt met de bijhorende controles (overlappingen, aantal deelnemers, etc.).De databank zal dan voor de individuele dagen telkens een aparte record aanmaken.

Het aanpassen van zo'n reservatie door de klant is dan echter minder evident. Indeze werkwijze zou de gebruiker gewoon geconfronteerd worden met een lijst vanverschillende reservaties waartussen geen onderlinge band meer is. Aanpassing zou dusenkel kunnen op het niveau van een enkele dag en niet op het niveau van de groep.

Om de link tussen de verschillende dagen van eenzelfde herhaalde activiteit tebewaren zal waarschijnlijk een kleine uitbreiding van de databank nodig zijn, waardoorwordt bijgehouden of een bepaalde reservatie herhaald wordt en zo ja over welkeperiode. De pagina's waarop de gebruiker een bestaande reservatie kan aanpassen zullendan uiteraard ook wel een aantal wijzigingen moeten ondergaan.

6.2 Groepen en tarieven aanpassenDesgewenst zou een module kunnen worden voorzien waarbij de beheerder de

mogelijkheid krijgt om groepen en de bijhorende tarieven aan te passen, toe te voegenof te verwijderen. Deze module zou ook grotendeels de technieken die in deze tekstwerden aangekaart, kunnen hergebruiken. Omdat de bestaande groepsindelingwaarschijnlijk nauwelijks zal wijzigen in de toekomst is deze functionaliteit echter nieturgent. Zoals hoger al werd vermeld, zullen andere pagina's van de website dan weldynamisch moeten kunnen inspelen op deze gewijzigde inhoud. De pagina waarop debeheerder een overzicht krijgt van de klantenfiche houdt hiermee al rekening. Hetformulierveld waarmee de groepen moeten worden toegekend wordt volledigdynamisch opgebouwd uit de databank en zal steeds actuele inhoud weergeven.

52

Hoofdstuk 7 BesluitHoewel een reservatiemodule ondertussen al een vrij klassieke applicatie mag

lijken, bood dit project toch een aantal specifieke uitdagingen. Binnen de vereisten diemoesten worden ingebouwd in het systeem, waren er een aantal die niet meteen vrijtraditioneel waren. Zo moet de applicatie niet alleen controleren op overlappingentussen reservaties, maar ook garanderen dat per dag niet meer dan 2 groepen aanwezigzijn en niet meer dan 50/60 deelnemers. Ook de rol van de beheerder was vrij specifiekvoor dit project

De restricties konden steeds geïmplementeerd door een combinatie van SQL-queries en applicatiecode, waardoor de werklast ook verdeeld werd tussen het DBMS ende webserver. In de mate van het mogelijke werd geprobeerd om de gebruiker ook apriori duidelijk te maken of een bepaalde reservatie kan doorgaan of niet. Concreetwordt dit gerealiseerd door de gebruiker vooraf een grafisch overzicht te bieden vanbeschikbare dagen, waarbij het in principe niet mogelijk is om zalen te kiezen wanneerdeze niet meer beschikbaar zijn.

Uiteraard valt niet uit te sluiten dat het systeem in de toekomst nog uitgebreid ofaangepast zal worden. De belangrijkste input hiervoor zal ongetwijfeld komen van defeedback van de gebruikers die uiteindelijk met dit systeem aan de slag zullen gaan.

53

Bijlage A Inhoud CD-ROMOp de bijgevoegde CD-ROM werd volgende informatie gebundeld:

- Broncode van de websiteAlle bestanden van de website zijn terug te vinden op de CD-ROM: asp-pagina's, include files, css, HTML-pagina's en grafische bestanden.- DatabankDe databank zoals beschreven in deze applicatie werd eveneens op de CDgeplaatst, uiteraard toegankelijk zonder paswoord.- PresentatieDe presentatie in powerpoint die getoond werd bij de verdediging werd eveneensopgenomen.- ScriptietekstDeze tekst werd in Word en PDF- formaat opgenomen op de CD.- JmailZoals in de tekst vermeld steunt de applicatie op deze component om hetelektronisch berichtenverkeer te genereren. Om de broncode van dit systeem danook volledig te doen werken, moet deze component op de server geïnstalleerdworden. De software is gratis en werd mee opgenomen op de CD-Rom.

54

Bijlage B Woordenlijst en afkortingenHoewel dit niet altijd evident is binnen het domein van de informatica werd toch

geprobeerd om Engelstalige termen en afkortingen te vermijden. De enkele vreemdewoorden die toch opgedoken zijn worden hier in de mate van het mogelijke vertaald ofverklaard.

Engelse term / afkorting Nederlandse term / verklaring

- ASP Active Server Pages (technologie van Microsoft omdynamische webpagina's aan te maken)

- Browser Bladerprogramma- Checkbox Selectievakje- Connection Verbinding- CSS Cascading Stylesheets (trapsgewijs opmaakmodel)- DBMS Database management systeem (databankbeheersysteem)- EER Enhanced / extended entity relationship (uitgebreid /

verbeterd entiteit relatie(-model))- ER Entity relationship (entiteit relatie)- HTML Hypertext markup language (opmaaktaal voor pagina's op

het wereldwijde web)- Include file Invoegbestand- Join Samenvoeging- Main succes scenario De verschillende stappen die een gebruiker zet bij een

typisch gebruik van een bepaalde module.- Pop-up-venster Flapuitvenster- Post-condition Voorwaarde die achteraf vervuld moet zijn.- Pre-condition Voorwaarde die vooraf vervuld moet zijn.- Query Zoekopdracht- Recordset Verzameling bij elkaar horende gegevens uit een databank.- Requirements Vereisten, noden- SQL Structured Query Language (standaardtaal voor interactie

met relationele databankbeheersystemen)- Server side script Stuk code uitgevoerd aan de kant van de server

("bediener")- Trigger Aanzet- URL Uniform resource locator (uniforme plaatsaanduiding)- Use-case Bepaald gebruik (van het systeem)- VB Visual Basic (bepaalde programmeertaal)- Website Webstek

Universiteit Gentlib.ugent.be/fulltxt/RUG01/000/895/454/RUG01-000895454...1.1 Algemene omschrijving...

Documents

Transcript of Universiteit Gentlib.ugent.be/fulltxt/RUG01/000/895/454/RUG01-000895454...1.1 Algemene omschrijving...