Ontwerp van een webgebaseerd registratiesysteem

UNIVERSITEIT GENT

____________________

FACULTEIT INGENIEURSWETENSCHAPPEN

VAKGROEP ELEKTRONICA EN INFORMATIESYSTEMEN

Voorzitter: Prof. dr. ir. J. Van Campenhout

____________________

Academiejaar 2005 – 2006

Ontwerp van een

webgebaseerd registratiesysteem

door

ir. Julie Deleu

ir. Katja D’haeyer

Promotor : Prof. dr. ir. K. De Bosschere

Scriptiebegeleider: Dr. ir. M. Ronsse

Scriptie voorgedragen tot het behalen van de academische graad van

MASTER IN DE TOEGEPASTE INFORMATICA

De auteur en de promotors geven de toelating deze scriptie voor consultatie beschikbaar te stellen en

delen ervan te kopiëren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot

de verplichting uitdrukkelijk de bron te vermelden bij het aanhalen van resultaten uit deze scriptie.

The author and the promoters give the permission to use this thesis for consultation and to copy parts

of it for personal use.

Every other use is subject to the copyright laws; more specifically the source must be extensively

specified when using results from this thesis.

06 juni 2006

De promotors,

Prof. dr. ir. Koen De Bosschere Dr. ir. Michiel Ronsse

De auteurs,

ir. Julie Deleu ir. Katja D’haeyer

Woord vooraf

Deze scriptie vormt het eindpunt van een aanvullende opleiding Toegepaste Informatica. Een

opleiding die een goedgevuld programma aan lessen, practica en examens bevat. Daarin verschillen

we niet van andere studenten. Ook zij nemen, ingedeeld in groepen, deel aan bovengenoemde

evenementen. Graag wilden wij het inschrijven voor deze evenementen vergemakkelijken en

overzichtelijker maken. Vandaar dat wij ervoor gekozen hebben om als scriptie een webgebaseerd

registratiesysteem te ontwikkelen. Deze opdracht kon echter niet tot een goed einde gebracht worden

zonder de hulp en steun van een aantal mensen. Deze mensen willen we hier nog eens speciaal

bedanken.

Vooreerst zouden we onze promotor, Prof. dr. ir. K. De Bosschere willen bedanken voor zijn goede

raad en bijsturingen bij deze scriptie. Ook onze begeleider, Dr. ir. M. Ronsse, willen we bedanken

omdat hij steeds antwoord wist te geven op onze talloze vragen.

Tot slot zouden we ook onze ouders willen bedanken om ons de kans te geven om ons, na onze eerste

opleiding, nog een jaartje achter de schoolbanken te laten plaatsnemen om deze aanvullende studie te

volgen. Het was een interessant en leerrijk jaar waarbij we ontzettend veel bijgeleerd hebben.

Overzicht

Ontwerp van een webgebaseerd registratiesysteem

door

ir. Julie Deleu

ir. Katja D’haeyer

____________________

Scriptie ingediend tot het behalen van de academische graad van

Master in de Toegepaste Informatica

Academiejaar 2005-2006

____________________

Promotor: Prof. dr. ir. K. De Bosschere

Scriptiebegeleider: Dr. ir. M. Ronsse

____________________

Universiteit Gent

Faculteit Ingenieurswetenschappen

Vakgroep Elektronica en Informatiesystemen

Voorzitter: Prof. dr. ir. J. Van Campenhout

Samenvatting:

Dit eindwerk had als doel een webgebaseerd registratiesysteem te ontwerpen zodat het indelen van de

studenten in groepen op een eenvoudige manier kan verlopen. Tijdens het academiejaar worden de

studenten vaak verdeeld in kleinere groepen om deel te nemen aan examens, practica en dergelijke.

Daar waar het indelen in groepen vroeger handmatig en op een ad hoc manier gebeurde, is het

tegenwoordig veel efficiënter om hiervoor gebruik te maken van het Internet. De webapplicatie

beschikt eerst en vooral over de mogelijkheid om gemakkelijk evenementen toe te voegen door de

verantwoordelijke. Tevens is de verantwoordelijke in staat evenementen te wijzigen of te verwijderen.

Het belangrijkste deel is uiteraard het in- en uitschrijven van de studenten. Deze applicatie laat toe dat

studenten kunnen kiezen waar en wanneer ze aan een evenement deelnemen. De student krijgt ook de

mogelijkheid om te kiezen bij welke groep hij/zij aansluit.

Trefwoorden: reservatiesysteem, webapplicatie, MySQL, PHP

Inhoudsopgave

1 INLEIDING___________________________________________________________________________ 1

2 BESTAANDE RESERVATIESYSTEMEN ________________________________________________ 2

3 ARCHITECTUUR VAN HET REGISTRATIESYSTEEM ___________________________________ 6

3.1 CONCEPTEN VAN REGISTRATIESYSTEMEN ________________________________________________ 6

3.1.1 Use-Case _______________________________________________________________________ 6

3.1.2 Toegang tot het systeem ___________________________________________________________ 7

3.1.3 Functionaliteit voor de gebruiker ____________________________________________________ 8

3.1.4 Functionaliteit voor de beheerder___________________________________________________ 11

3.2 ONTWIKKELING VAN HET REGISTRATIESYSTEEM__________________________________________ 13

3.2.1 Problematiek ___________________________________________________________________ 13

3.2.2 Resulterende databank ___________________________________________________________ 14

4 MATERIAAL EN METHODEN ________________________________________________________ 16

4.1 MYSQL _________________________________________________________________________ 16

4.2 HYPERTEXT PREPROCESSOR (PHP) ____________________________________________________ 17

4.3 JAVASCRIPT ______________________________________________________________________ 17

4.4 LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL (LDAP)____________________________________ 18

5 RESULTATEN EN DISCUSSIE ________________________________________________________ 19

5.1 CONTROLE VAN DE GEBRUIKERS ______________________________________________________ 20

5.2 AANMAKEN VAN EEN EVENEMENT_____________________________________________________ 20

5.3 REGISTREREN VOOR EEN EVENEMENT __________________________________________________ 24

5.4 WIJZIGEN OF VERWIJDEREN VAN EEN EVENEMENT ________________________________________ 25

5.5 GROOTTE VAN DE WEBAPPLICATIE_____________________________________________________ 28

6 BESLUIT ____________________________________________________________________________ 29

7 LITERATUURLIJST__________________________________________________________________ 31

Inleiding

1

1 Inleiding

In het kader van de flexibilisering van het onderwijs wil de Vlaamse regering de onderwijsinstellingen

meer kansen geven om in te spelen op de behoeften van de verscheidene doelgroepen. Door het

aanbieden van keuzemogelijkheden aan de studenten, kan elke student naargelang zijn eigen behoefte

en interesse een studieprogramma samenstellen. Een gevolg van deze flexibiliseringsmaatregelen is

dat de leerinhoud, het studietijdstip, het tempo van de studievoortgang,… verschillen van student tot

student. Dit brengt problemen met zich mee wanneer studenten tijdens het academiejaar aan

gebeurtenissen in groep deelnemen, waarbij het indelen in groepen meestal op een ad hoc manier

gebeurt. De groepen worden arbitrair bepaald (bvb. alfabetisch op naam) of er wordt een intekenblad

voorzien. Het is duidelijk dat dit met de komst van de flexibilisering geen efficiënte manier van

werken is. Daarom zou het beter zijn om voor de studenten een systeem te voorzien dat toelaat om

voor bepaalde gebeurtenissen via het web in te schrijven. Hierdoor wordt het mogelijk om eender waar

en wanneer in te schrijven. De tijd van het missen van practica door afwezigheid in de les is dus

voorgoed voorbij...

Het doel van deze scriptie is het ontwerpen van een webgebaseerd registratiesysteem. Hier kunnen

professoren en assistenten gebeurtenissen (evenementen) ingeven waarvoor studenten zich nadien

kunnen registreren. De studenten worden meestal in groepen ingedeeld. Zo’n groep kan een klas zijn

maar het kan evengoed gaan om meerdere klassen die hetzelfde examen afleggen of een klas die

opgesplitst wordt om aan een practicum deel te nemen. Uiteraard moeten studenten hiervan op de

hoogte gebracht worden en moeten er afspraken gemaakt worden voor wat betreft indeling, plaats,

datum, tijd,… Tegenwoordig kan dit uiteraard het vlotst via internet. Studenten blijken immers al eens

afwezig te zijn of ze hebben nevenactiviteiten waardoor ze op bepaalde momenten niet kunnen

deelnemen aan een evenement. Via het web krijgen ze de vrijheid om in te tekenen voor evenementen

die doorgaan op momenten die hun het best passen. Bovendien zijn ze in staat om de uren en de plaats

na te kijken waar ze zich ook bevinden. Zolang er een computer met internetverbinding voorhanden is

tenminste. Een bijzonder punt van aandacht hierbij is het aanbieden van de nodige flexibiliteit.

Registraties moeten gemakkelijk toegevoegd of gewijzigd kunnen worden, studenten uit een groep

moeten verwittigd kunnen worden als het evenement gewijzigd wordt, ...

In het tweede hoofdstuk van dit eindwerk wordt op basis van een literatuurstudie een overzicht

gegeven van reeds bestaande reservatiesystemen. Het derde hoofdstuk bevat een woordje uitleg bij het

ontwerp en de architectuur van het reservatiesysteem. In hoofdstuk vier worden de gebruikte tools

besproken. Het vijfde hoofdstuk omvat de resultaten en de bespreking van de webapplicatie. Tot slot

worden de bevindingen samengevat in het besluit.

Bestaande reservatiesystemen

2

2 Bestaande reservatiesystemen

Een computerreserveringssysteem of –reservatiesysteem (CRS) is een computersysteem dat gebruikt

wordt voor het registreren van reserveringen. De grotere CRS-systemen staan ook bekend onder de

term Globaal Distributie Systeem (GDS). De eerste geautomatiseerde reserveringssystemen werden

opgezet door luchtvaartmaatschappijen ter vervanging van het kaartensysteem. Tegenwoordig worden

reserveringssystemen in vele andere sectoren toegepast. Er werden al webgebaseerde

registratiesystemen ontworpen voor tal van toepassingen zoals luchthavens, hotels, sportcomplexen,

autoverhuurbedrijven, theaters, bibliotheken,...

Bij de reservatiesystemen dient er een onderscheid gemaakt te worden tussen twee types. Enerzijds

zijn er de reservaties voor een lange periode bvb. bij hotels, autoverhuurbedrijven waarbij de klant een

maandplanning te zien krijgt. Anderzijds zijn er reservatiesystemen voor korte periodes zoals bvb. in

sportclubs waarbij een dagplanning weergegeven wordt.

Een blik op het internet maakt duidelijk dat reservatiesystemen frequent in sportclubs gebruikt

worden. Menig tennisclub en bowlingbaan laten toe om online een baan te reserveren. De

functionaliteit van deze systemen is echter sterk verschillend. In sommige gevallen, zoals bij

tennisclub Olympos (http://www.tcolympos.com/asp/wplan0.asp), krijgt men voor een bepaalde dag

een rooster te zien waarbij elke kolom een andere baan voorstelt. De eerste kolom geeft per rij de

opeenvolgende uren weer. Een kleursysteem maakt duidelijk welke banen reeds voor een bepaald

tijdstip en duur gereserveerd zijn en welke niet. Nadeel hier is dat er met een vast uurrooster gewerkt

wordt. Zo is men bvb. verplicht om van 9u tot 10u te reserveren of van 10u tot 11u. Reserveren van

9u30 tot 10u30 behoort niet tot de mogelijkheden. Ook anderhalf uur spelen is enkel mogelijk door te

reserveren voor twee uur. Andere systemen trachten meer op de noden van de gebruiker in te spelen

door voor elk terrein een andere indeling van het uurrooster te voorzien.

Gelukkig bestaan er ook andere systemen. Systemen die de gebruiker toelaten om een willekeurig

begin- en einduur in te geven. Het systeem gaat dan na of deze reservering mogelijk is. Omdat de

gebruiker niet zou moeten gokken naar vrije uren, wordt er voor een bepaalde dag een overzicht

gegeven van de reeds gereserveerde banen en uren. Reserveren van een beschikbare baan en tijdstip

gebeurt via een formulier waarin de persoonlijke gegevens, de gewenste baan en het tijdstip ingevuld

worden. Een aantal demo’s hiervan zijn te bekijken op de website van Wiversoft

(http://www.wiversoft.be/online_demo.php). Dit bedrijf maakt software op maat en ontwikkelt o.a.

reserveringsprogramma’s.


3

Vervolgens kan de verwerking van de formulieren op twee manieren gebeuren. Ofwel wordt dit

gemaild naar de beheerder. Hierbij wordt de databank niet onmiddellijk aangepast. De beheerder

maakt dan de reservering definitief via een update van de databank. Ofwel wordt de databank wel

aangepast na het ingeven van de reservering door de klant. De reservering is dan onmiddellijk

zichtbaar naar andere klanten toe. Wel is het zo dat de beheerder deze reserveringen nog steeds moet

bevestigen. Ook een combinatie van bovenstaande twee mogelijkheden is mogelijk.

Opvallend bij deze systemen in sportclubs is het ontbreken van de mogelijkheid om een reservering

aan te passen of te annuleren. Uiteraard gaat het hier om de kleinere, eenvoudigere systemen. Daarom

werden de reservatiesystemen bij reisbureaus en hotels eens van naderbij bekeken. Deze bieden meer

functionaliteit maar zijn qua gebruik eerder voorbehouden aan het personeel. Voor de klant is het wel

mogelijk om een formulier met zijn/haar wensen in te vullen doch de bevestiging is meestal

weggelegd voor het personeel. Van hen wordt er verwacht dat ze goed met een reservatiesysteem

kunnen omgaan en in menig vacature uitgaande van deze sector is kennis van systemen als Fidelio,

Winner, Gaspra, Amadeus, BTN, JIL, Galileo een vereiste. Momenteel zijn er echter steeds meer

hotels die toelaten om de beschikbaarheid op een bepaalde datum te controleren en/of om online een

kamer te reserveren. Bij het reserveren dienen klanten hun persoonlijke gegevens door te geven maar

ook hun kredietkaartnummer. Na reservatie krijgt men een bevestigingsnummer. Dit nummer, in

combinatie met de naam waaronder gereserveerd werd of de laatste vier cijfers van het

kredietkaartnummer, laat toe om reservaties te wijzigen of te annuleren.

Dergelijke systemen zijn ook meer dan louter een reservatiesysteem. Zo moeten deze systemen

overboekingen toelaten met een minimum aan risico en proberen ze de vraag te voorspellen op basis

van gegevens uit het verleden. Daarnaast bepalen ze de prijs van een kamer of een reis naargelang het

aantal reservaties dat er reeds gebeurd is en naargelang de tijd die nog rest om ervoor te reserveren

bvb. bij last-minute reizen. Bedoeling is om via dynamische prijsvoering de winst te maximaliseren

(Meidan & Chiu, 1995).

Bij de vliegtuigmaatschappijen is het eveneens aan de klant om zelf een reservering te maken en deze

te bevestigen na het ontvangen van een e-mail. Echter de functionaliteit beperkt zich hier tot het

ingeven van persoonlijke gegevens en de gewenste vlucht op een bepaalde datum en tijdstip in een

gewenste prijsklasse. Men krijgt vervolgens een selectie van de mogelijke vluchten te zien waaruit dan

gekozen kan worden. De prijzen van de vluchten worden opnieuw zo bepaald dat ze zorgen voor een

winstmaximalisatie. Zo zullen de prijzen dalen naarmate er meer tijd verstrijkt en er nog maar weinig

reservaties gebeurd zijn.

Ook parkingreserveringssystemen worden gekoppeld met een systeem voor winstmaximalisatie.

Bijkomend zullen de variabele parkingprijzen het parkinggedrag bijsturen bvb. minder verkeer in het

stadscentrum door verhoogde parkingtarieven (Teodorovic & Lucic, 2005).


4

Toch zijn er ook systemen die niet werken met winstmaximalisatie en overboekingen. Ze werken met

een vaste prijs en een vast aantal plaatsen. Men vindt ze bvb. terug op websites waar online tickets

kunnen gereserveerd worden. De meeste van zulke sites gaan na of er nog tickets over zijn en laten

dan toe om ze aan te kopen via een kredietkaart of overschrijving. De tickets worden bezorgd via de

post of zijn op te halen aan de kassa. Echter bepaalde websites van concertzalen en theaters bieden

meer functionaliteit. Zo is er de webstek van het Kaaitheater (www.kaaitheater.be). De website

voorziet in het aankopen van tickets (zie Figuur 2-1). Daarnaast kan men intekenen op een wachtlijst

wanneer ze uitverkocht zijn.

Figuur 2-1: Zaalplan voor het reserveren van tickets bij het Kaaitheater


5

Bijzonder is het feit dat men tijdens het reserveren voor een bepaalde voorstelling een zaalplan te zien

krijgt. De beschikbare plaatsen worden aangeduid door een leeg cirkeltje. Reserveren kan door de

gewenste prijscategorie te kiezen en vervolgens een cirkeltje aan te klikken. Men kan zoveel cirkeltjes

aanklikken als men wenst en daarna de gemaakte keuze(s) bevestigen. Men krijgt een overzicht van de

bestelling en men kan nog andere reservaties toevoegen.

In geen enkel geval konden de registratiesystemen gebruikt worden voor het aanmaken van en

registreren voor bepaalde evenementen als een examen of een scriptieverdediging. Vooral de

opsplitsing van evenementen in sessies en groepen ontbrak. Waar die opsplitsing wel gebeurde, kon er

geen informatie aan deze onderdelen meegegeven worden. Bovendien hebben deze bestaande

systemen, naast een hoge kostprijs, doorgaans een te uitgebreide functionaliteit. In het kader van dit

eindwerk waren al die extra’s overbodig zodat eventueel een bestaand systeem moest omgebouwd

worden. Dit was echter ook geen optie aangezien deze systemen grotendeels op maat gemaakt worden

door gespecialiseerde bedrijven. Deze bedrijven willen de code van deze systemen dan ook niet

vrijgeven. Daarom restte er slechts één mogelijkheid meer en dat was zelf aan de slag gaan.

Aangezien het in deze scriptie gaat om een heel specifieke toepassing, was het opportuun om een

systeem te ontwerpen dat afgestemd is op de noden van student en lesgever. Het grote verschil bestaat

er immers in dat de evenementen waarvoor men kan inschrijven relatief beperkt zijn en dat de

voorwaarden waaronder deze doorgaan, vastgelegd worden door de lesgever.

Vooraleer van start te gaan, werd het huidige reservatiesysteem van de vakgroep ELIS bekeken. Dit

systeem werkt met sessies die bestaan uit een aantal groepen. Elke sessie bevat de specifieke

informatie, waaronder plaats en tijdstip, voor een bepaalde activiteit. Wanneer een activiteit over

meerdere tijdstippen of plaatsen gespreid wordt, moet er telkens een andere sessie aangemaakt

worden. De verschillende sessies van eenzelfde activiteit worden apart weergegeven wat het overzicht

van de activiteit negatief beïnvloedt.

De docenten hebben de mogelijkheid om bij een bepaalde sessie een vraag te stellen aan de studenten.

Het systeem laat echter niet toe dat de studenten een antwoord ingeven. De docent is tevens niet in

staat om vlot sessiegegevens aan te passen. Deze minpunten van het huidige reservatiesysteem

dienden als uitgangsbasis voor het ontwerp van een nieuw registratiesysteem.

Architectuur van het registratiesysteem

6

3 Architectuur van het registratiesysteem

3.1 Concepten van registratiesystemen

In dit onderdeel worden de concepten die bij een registratiesysteem van toepassing zijn besproken. Er

wordt begonnen met een Use-Case view. Deze schetst de algemene functionaliteit van het systeem.

Vervolgens wordt de toegang tot het systeem besproken. Er wordt afgerond met een bespreking van de

functionaliteit voor de gebruiker en de beheerder.

3.1.1 Use-Case

Een belangrijk aspect bij het modelleren van een systeem is de functionaliteit die het systeem biedt

zoals gezien door de ogen van de gebruikers. In UML (Unified Modeling Language) kan dit aspect

gemodelleerd worden in de Use-Case view. Het belangrijkste onderdeel hierbij zijn de Use-

Casediagrammen. Deze diagrammen geven de externe gebruikers van het systeem weer en hun relatie

tot de Use-Cases die het systeem aanbiedt (Greefhorst & Maat, 1997). Figuur 3-1 toont een dergelijk

diagram waarin de functionaliteit van een registratiesysteem is gemodelleerd.

Gebruiker Beheerder

Overzicht

evenementen

Inschrijven

Uitschrijven

Wijzigen

Aanmaken

evenementen

Registratiesysteem

Overzicht

evenementen

«uses»

«uses»

«extends»

Verwijderen

«extends»

«extends»«uses»

Legende

Systeem

Use-Case Communicates-relatie

Uses-relatie Extends-relatie

Actor

Figuur 3-1: Use-Casediagram van een registratiesysteem


7

Een Use-Case beschrijft een typische interactie tussen een gebruiker en een systeem. Het beschrijft

een compleet stuk functionaliteit dat een systeem aanbiedt aan een gebruiker en dat een voor de

gebruiker observeerbaar resultaat oplevert. De actoren in dergelijke diagrammen zijn diegenen die het

systeem gebruiken. Een actor communiceert met een systeem door het sturen of ontvangen van

informatie en kan dus zowel een mens als een ander systeem representeren (Greefhorst & Maat, 1997).

In Figuur 3-1 is er een actor ‘Gebruiker’ en een actor ‘Beheerder’ aanwezig. Het feit dat zij deelnemen

in een bepaalde Use-Case wordt weergegeven met een communicates-relatie. Zo zal de actor

‘Gebruiker’ interageren met het registratiesysteem wanneer deze een overzicht van de evenementen

opvraagt, een evenement bekijkt of zich in- of uitschrijft. De actor ‘Beheerder’ kan eveneens een

overzicht van de evenementen opvragen maar kan deze ook editeren. Daarnaast kan men als

‘Beheerder’ ook evenementen aanmaken.

Behalve relaties tussen actoren en Use-Cases kunnen in een Use-Casediagram ook relaties tussen Use-

Cases onderling aangegeven worden. Zo kan een extends-relatie gebruikt worden om aan te geven dat

een bepaalde Use-Case een uitbreiding of variatie is op een andere Use-Case (Greefhorst & Maat,

1997). In Figuur 3-1 toont een dergelijke relatie aan dat de Use-Cases ‘Wijzigen’ en ‘Verwijderen’ een

uitbreiding zijn van de Use-Case ‘Overzicht evenementen’ voor het geval dat de actor de ‘Beheerder’

is. Tenslotte kan een uses-relatie gebruikt worden om gedrag te modelleren dat door meerdere Use-

Cases gebruikt wordt. Bij een registratiesysteem gaat het hier om het ‘Inschrijven’ en ‘Uitschrijven’

door de actor ‘Gebruiker’. Deze Use-Cases maken immers gebruik van de Use-Case ‘Overzicht

evenementen’.

3.1.2 Toegang tot het systeem

Wanneer men wenst gebruik te maken van een registratiesysteem, moet het systeem eerst weten om

welke type actor het gaat (zie Figuur 3-2). Er moet dus ingelogd worden. Via de login en een daaraan

gekoppeld kenmerk kan het systeem nu een onderscheid maken tussen de actoren. Aangezien het

registratiesysteem ontwikkeld wordt voor gebruik door studenten, assistenten en professoren, zal in

deze scriptie gebruik gemaakt worden van het al dan niet aanwezig zijn van een vakgroepnummer in

de LDAP-databank van de UGent. Afhankelijk hiervan krijgt men toegang tot de geschikte

functionaliteit. Dit is voor de gebruiker een weergave van de evenementen waarvoor deze zich zal

kunnen in- of uitschrijven (zie verder in 3.1.3). Voor de beheerder is het eveneens mogelijk om de

evenementen te bekijken, maar deze is ook in staat om nieuwe evenementen aan te maken of

bestaande te editeren en te verwijderen (zie ook 3.1.4).


8

Figuur 3-2: Systeemtoegang bij registratiesystemen

3.1.3 Functionaliteit voor de gebruiker

Wanneer men als gebruiker ingelogd is in het registratiesysteem, kan men een bepaald evenement uit

de weergave nader gaan bekijken. Het overzicht van dit evenement geeft dan alle noodzakelijke

informatie weer zoals

• onderwerp

• verantwoordelijke

• of het evenement uit meerdere delen bestaat

• tijdstip(pen)

• plaats(en)

• wie is al ingeschreven

• het aantal vrije plaatsen

Deze informatie zal ook gebruikt worden bij de werking van het registratiesysteem in

gebruikersmodus (zie Figuur 3-3). Zo wordt er bepaald of een gebruiker reeds ingeschreven is.


9

Naargelang het antwoord op deze vraag, kan de gebruiker beschikken over een bepaalde

functionaliteit. Wordt deze vraag negatief beantwoord, dan moet er nagegaan worden of er nog wel

plaats vrij is voor die persoon. Is dit het geval, dan kan deze zich gaan inschrijven. Eventueel kan

hierbij nog extra informatie meegegeven worden bvb. door het invullen van een formulier. Tenslotte

wordt de naam van de gebruiker en de meegegeven informatie toegevoegd aan het overzicht van het

evenement. Wanneer de gebruiker achteraf merkt dat hij/zij een fout heeft ingegeven of bepaalde

gegevens wil aanpassen, dan moet het systeem toelaten dat deze gegevens vlot kunnen gewijzigd

worden.

Natuurlijk kan het steeds voorkomen, dat men niet meer kan aanwezig zijn bij het evenement. Daarom

moet het mogelijk zijn om uit te schrijven waardoor anderen de kans krijgen om zich alsnog in te

schrijven. Eventueel kan men terug inschrijven voor hetzelfde evenement maar dat doorgaat op een

moment dat beter geschikt is. Uiteraard moeten er dan ook nog plaatsen vrij zijn.

Overzicht bepaald

evenement

Reeds

ingeschreven?

Ja

Max bereikt ?

Neen

Neen

Uitschrijven

Inschrijven

Functionaliteit voor gebruikerAlgemeen

Gegevens

wijzigen

Inschrijven niet

meer mogelijk

Ja

Legende

Toestand

Actie Beslissing

Inkomende verwijzing

A

Figuur 3-3: Algemene functionaliteit voor de gebruiker bij registratiesystemen


10

Het kan eveneens voorkomen dat mensen wensen deel te nemen aan een evenement en dat ze zich

hiervoor in groepen moeten verdelen. Er wordt bvb. een quizavond gepland en men verwacht dat men

deelneemt in groepen van vier. Het registratiesysteem moet dan een groepsnaam laten ingeven en deze

weergeven in het overzicht. Uiteraard is het handiger wanneer enkel de persoon die als eerste inschrijft

de groepsnaam opgeeft. Voor de andere groepsleden kan het dan volstaan om de naam te verifiëren,

kwestie dat ze toch voor de juiste groep inschrijven. In het kader van deze scriptie kan er eerder

gedacht worden aan het verdedigen van een scriptie (zie Figuur 3-4). Men werkt doorgaans alleen of

per twee aan een scriptie.

Overzicht scriptie-

verdedigingen

Reeds

ingeschreven?

Ja

Max bereikt ?Neen

Neen

Uitschrijven

Inschrijven

Functionaliteit voor gebruikerSpecifiek voor scriptieverdedigingen

Andere leden

ingeschreven?

Scriptietitel

opgeven Neen

OK Scriptietitel

verifieren

Niet OK

Gegevens

wijzigen

Ja

Inschrijven niet

meer mogelijk

Legende

Toestand

Actie Beslissing


A

Ja

Figuur 3-4: Functionaliteit voor de gebruiker bij registratie van scriptieverdedigingen


11

Wanneer deze moet verdedigd worden, verwacht men dus - op bepaalde tijdstippen - een groep

bestaande uit één of twee personen. Om deze groepen nauwkeuriger te kunnen duiden, is het

interessant om er een kenmerk aan te verbinden. In het voorbeeld van de quizavond is dit kenmerk de

groepsnaam. Bij een scriptieverdediging is de scriptietitel het meest geschikt.

3.1.4 Functionaliteit voor de beheerder

Wanneer men als beheerder inlogt in het registratiesysteem, kan men uiteraard een bepaald evenement

uit de weergave nader gaan bekijken. Toch moet het systeem voor de beheerder meer functionaliteit

bieden (zie Figuur 3-5). Enerzijds moeten evenementen gewijzigd of zelfs verwijderd kunnen worden.

Hierbij is het belangrijk dat de gebruikers op de hoogte gebracht kunnen worden van eventuele

wijzigingen. Anderzijds moeten evenementen kunnen aangemaakt worden.

Bij het aanmaken en wijzigen van een evenement of bij het toevoegen van bepaalde aspecten, moet het

systeem een geschikt formulier weergeven. Men spreekt hierbij van sjablonen omdat het formulier

aangepast wordt aan de omstandigheden. Deze sjablonen zorgen ervoor dat de gebruiker die gegevens,

die voor een bepaald geval van toepassing zijn, kan invullen of aanpassen. Hierbij wordt er vermeden

dat de beheerder met de algemene structuur van de databank geconfronteerd wordt.

Vooraleer de gegevens naar de databank weggeschreven worden, moet er natuurlijk gecontroleerd

worden of alle verplichte velden ingevuld zijn. Daarnaast moet het systeem controleren of deze

gegevens wel geldig zijn bvb. bij het ingeven van de uren mag 25:12 niet geaccepteerd worden. Is er

niet voldaan aan deze twee bovenstaande criteria, dan wordt er melding gemaakt van de fouten. De

beheerder wordt vervolgens teruggebracht naar het invulformulier waar deze de nodige correcties kan

aanbrengen.


12

Aanmaak van een

evenement

Gegevens

invoeren

Verplichte velden

ingevuld?

Controle OK?

Neen

Neen

Weergave

evenement

Ja

Toevoegen

Wijzigen

Verwijderen

Ja

Evenement

verwijderen

Eventueel mail

versturen

Functionaliteit voor beheerder

Controle OK?

Verplichte velden

ingevuld?

Ja

Ja

Neen

Neen

B

Legende

Toestand

Actie Beslissing


Figuur 3-5: Functionaliteit voor de beheerder bij registratiesystemen


13

3.2 Ontwikkeling van het registratiesysteem

Wanneer een bepaalde activiteit gepland wordt, spreekt men van een evenement. Elk evenement kan

bestaan uit één of meerdere sessies. Het reservatiesysteem zorgt ervoor dat personen, in het bijzonder

studenten, zich voor bepaalde sessies kunnen registreren. Hiertoe dienen ze zich in te schrijven in een

groep. Immers sessies bestaan op hun beurt uit één of meerdere groepen van elk een bepaald aantal

personen. Wanneer een sessie maar één groep bevat, dient men zich in te schrijven bij de betreffende

sessie. De groepen binnen één sessie kunnen al dan niet parallel zijn d.w.z. elke groep kan al dan niet

op dezelfde datum en tijdstip en/of dezelfde plaats verwacht worden.

3.2.1 Problematiek

Bij het ontwerpen van de databank voor het registratiesysteem diende er een antwoord geformuleerd te

worden op de volgende vragen: ‘Wat is een sessie?’, ‘Wat is een groep?’ en ‘Welke zijn de

eigenschappen daarvan?’. In het bijzonder moest er uitgemaakt worden of het gebouw, het lokaal, de

datum, het begin- en het einduur kenmerken zijn van een sessie of van een groep. Er was m.a.w. een

tijd-ruimte probleem. Meer bepaald moesten de tijd en de ruimte opgesplitst worden en dit op een

zodanige manier dat de algemenere informatie bij een sessie terechtkwam terwijl de specifieke

informatie bij een groep werd getoond. Hierna volgen een paar voorbeelden om deze problematiek te

illustreren.

Een sessie van bvb. een practicum kan op een bepaalde dag doorgaan waardoor de datum een

eigenschap van de sessie is. Enerzijds kunnen de studenten dan in groepen ingedeeld worden

naargelang het aantal beschikbare computerlokalen. Het gebouw en het lokaal zijn hier dan een

eigenschap van de groep. Anderzijds kan elke groep in hetzelfde computerlokaal verwacht worden

maar op verschillende tijdstippen. Het gebouw en het lokaal zijn dan eigenschappen van de sessie,

terwijl het tijdstip (het begin- en einduur) afhankelijk is van de groep.

Bij een examen kunnen er twee sessies zijn, bvb. een mondeling en een schriftelijk deel. De

mondelinge sessie kan verspreid zijn over meerdere dagen waardoor de datum verschilt van groep tot

groep. De datum is hier dan ook een groepseigenschap. Dit heeft tot gevolg dat ook het begin- en

einduur groepseigenschappen zijn. Naargelang er bij elke groep overhoord wordt in hetzelfde gebouw

en lokaal, zijn deze gegevens eigenschappen van de sessie of de groep.

Uiteindelijk werd beslist om alle eigenschappen bij groep te plaatsen. Om te voorkomen dat er

redundante gegevens weergegeven worden bij de webapplicatie, wordt er na het ophalen van de

gegevens getest welke eigenschappen bij alle groepen van een bepaalde sessie gelijk zijn. De gegevens


14

die bij alle groepen gelijk zijn, worden bij de sessie uitgeschreven. De andere gegevens worden bij hun

specifieke groep geplaatst.

3.2.2 Resulterende databank

De resulterende databank bestaat uit vier tabellen. Elke tabel, behalve ‘Deelname’, bevat een kolom

met unieke ID-nummers. Deze worden gebruikt als primaire sleutel (primary key, PK). Bij

‘Deelname’ vormt de combinatie van het groepsnummer en de login de primaire sleutel. Figuur 3-6

geeft het schema van de databank weer. De attributen die gedefinieerd werden als primaire sleutel zijn

onderlijnd.

De relaties tussen de verschillende tabellen hebben allemaal een kardinaliteit van 1:N. Dit geeft aan

hoeveel entiteiten op een gegeven ogenblik betrokken zijn in een relatie. Een evenement kan meerdere

sessies bevatten. Een sessie kan in verschillende groepen gedeeld worden. Een groep kan uit meer dan

één student bestaan waardoor een groep meerdere deelnames omvat.

Figuur 3-6: Databankschema

Een eerste tabel ‘Evenement’ groepeert alle informatie over de evenementen. Ten eerste wordt het

type evenement (evType) zoals een examen, practicum of scriptieverdediging bijgehouden. Daarnaast

ook de naam (evNaam), de verantwoordelijke (evVerantw), het aantal sessies (evAantSes) en een

eventuele mededeling (evMedeling).

De gegevens van de sessies worden opgeslagen in een tweede tabel ‘Sessie’. Deze tabel heeft als

attributen: de naam (seNaam), het type (seType) zoals bvb. mondeling of schriftelijk bij een

examenevenement, de duur van de sessie (seVolJaar), het aantal groepen (seAantGr) en een eventuele

vraag (seVraag) aan de gebruikers. Eveneens wordt een vreemde sleutel (seEv) opgeslagen die

verwijst naar het bijhorende evenement in de tabel ‘Evenement’.


15

De tabel ‘Groep’ bevat alle kenmerken van de groepen: de naam (grNaam), het gebouw (grPlaats), het

lokaal (grLokaal), de datum (grDatum), het beginuur (grBeginuur), het einduur (grEinduur) en het

aantal studenten in de groep (grAantSt). In het geval van een scriptieverdediging wordt per groep de

scriptietitel bijgehouden (grAntw). Tevens wordt ook hier een vreemde sleutel (grSe) bijgehouden die

verwijst naar de overeenkomstige sessie uit de tabel ‘Sessie’.

In de laatste tabel ‘Deelname’ wordt bijgehouden welke studenten bij welke groepen ingeschreven

zijn. Deze tabel heeft 3 attributen, nl. de naam van de student (deLogin), het ID van de groep (deGr)

waartoe de student behoort en het antwoord op een gestelde vraag (deAntw). Zoals reeds vermeld kan

er per sessie een vraag (seVraag) gesteld worden. Bij het inschrijven krijgt de gebruiker de

mogelijkheid daarop een antwoord te geven.

Materiaal en methoden

16

4 Materiaal en methoden

In dit eindwerk werd gebruik gemaakt van verschillende tools. Voor het opstellen van de databank

werd MySQL als databankbeheerssysteem gebruikt. Met behulp van de scripttaal Hypertext

Preprocessor (PHP) werd de informatie uit de databank gelezen en weergegeven op de website als

HyperText Markup Language (HTML)-pagina's. Met JavaScript werden dynamische en interactieve

webpagina’s gegenereerd.

4.1 MySQL

MySQL is een open-source, relationeel databankbeheerssysteem. Open-source software is software

waarvan de code in te kijken en te veranderen is. Een databank waarvan de informatie zich in

verschillende tabellen bevindt, is een relationele databank. De tabellen bestaan uit rijen (records) en

kolommen (velden). Elke rij beschrijft juist één entiteit. Binnen een rij worden nooit gegevens

bijgehouden over meerdere entiteiten en één entiteit wordt binnen één tabel nooit beschreven over

meerdere rijen. Elke rij is daarenboven uniek. Elke kolom beschrijft precies één attribuut van een

entiteit en in elke rij is de betekenis van het attribuut dezelfde. Verschillende tabellen kunnen met

elkaar verbonden worden door een kolom toe te voegen waarin een verwijzing naar een record in een

andere tabel wordt opgenomen. De keuze voor een relationele databank volgt uit het feit dat de

gegevens op een efficiënte manier opgeslagen kunnen worden. Wanneer de gegevens in een

relationele databank goed gestructureerd zijn, wordt duplicatie van gegevens tot een minimum beperkt

en worden er fouten in de gegevensverwerking voorkomen (De Tré, 2006).

Met behulp van de Structured Query Language (SQL) kan de databank bevraagd of gewijzigd worden.

SQL is een standaardtaal die voor vrijwel alle relationele databankbeheerssystemen gebruikt kan

worden. Enkele voorbeelden van relationele databanksystemen die SQL gebruiken zijn: Oracle,

Sybase, Microsoft SQL Server, Microsoft Access, Ingres en natuurlijk MySQL.

Het beheren van de MySQL-databank gebeurde met phpMyAdmin. Dit is een in PHP (zie 4.2)

geschreven tool die bedoeld is om op een gemakkelijke manier MySQL-databanken via het internet en

een browser te beheren. Het programma kan onder andere databanken aanmaken en verwijderen;

tabellen aanmaken, verwijderen en veranderen; gegevensvelden toevoegen, wijzigen en verwijderen;

SQL-statements uitvoeren en informatie exporteren.


17

MySQL is bijzonder goed geschikt voor het ontwikkelen van webtoepassingen en is bovendien gratis.

De ontwikkelaars ervan werken nog steeds aan de verbetering en uitbreiding van dit

databankbeheerssysteem. Daarnaast is MySQL extreem snel wanneer men werkt met kleine tot

middelgrote databanken. Doch biedt het minder functionaliteit dan relationele databanken.

Desondanks is dit nog steeds voldoende voor de meeste gebruikers (Greenspan & Bulger, 2001) .

4.2 Hypertext Preprocessor (PHP)

PHP is een server-side scriptingtaal die toelaat dynamische webpagina’s te creëren. Een PHP-pagina is

een HyperText Markup Language (HTML)-pagina die extra informatie (code) bevat. Bij het oproepen

van een PHP-pagina wordt de opgenomen PHP-code eerst door de webserver uitgevoerd, vandaar de

naam server-side scripttaal. Het resultaat, een HTML-pagina, wordt door de server naar de cliënt

gestuurd en door de browser verwerkt.

De keuze voor PHP in deze scriptie volgt uit het feit dat het vrij eenvoudig aan te leren is. Wanneer

zich problemen stellen, is er een waaier van websites beschikbaar. Eveneens kan men de hulp inroepen

van andere gebruikers wanneer men bvb. een fout in de code niet vindt. Bepaalde gebruikers werken

ook mee aan de voortdurende verbetering en uitbreiding van deze open-sourcetaal. Een ander voordeel

van PHP is dat het werkt onder bijna alle bekende besturingssystemen waaronder WindowsNT/2000

en UNIX. Gevolg is dat deze taal een goede compatibiliteit biedt. Daarnaast biedt PHP talrijke

ingebouwde functies die gegevenstoegang verzekeren voor het merendeel van de webtoepassingen

(Greenspan & Bulger, 2001).

4.3 JavaScript

Met de introductie van JavaScript ontstonden de eerste mogelijkheden om webpagina’s interactief te

maken. JavaScript is een scriptingtaal die tussen de HTML-code geschreven wordt. Er bestaat zowel

client-side als server-side JavaScript. Bij client-side JavaScript worden de programma’s direct

uitgevoerd door de browser van de bezoeker, waardoor snelle reacties mogelijk zijn. Er kan op acties

van de gebruiker gereageerd worden door nieuwe vensters te openen of door bewegende effecten te

starten en te stoppen. Een voordeel van JavaScript is dat het, in tegenstelling tot VBScript,

ondersteund wordt door Internet Explorer, Netscape Navigator en vele andere webbrowsers. In deze

toepassing werd gebruik gemaakt van client-side JavaScript voor het toevoegen van sessies en groepen

aan een evenement (W3Schools Online Web Tutorials, 2006).


18

4.4 Lightweight Directory Access Protocol (LDAP)

LDAP maakt centraal opgeslagen, gestructureerde data toegankelijk over het netwerk. Het

netwerkprotocol biedt de mogelijkheid om data snel te kunnen raadplegen vanuit diverse

programma’s. De LDAP-server van de Universiteit Gent bevat heel wat informatie zoals naam,

paswoord, e-mailadres, telefoonnummer,... van professoren, medewerkers en studenten. Via LDAP

kunnen deze gegevens opgevraagd worden. In dit eindwerk zal LDAP gebruikt worden om, aan de

hand van de login, gegevens van de gebruikers op te halen.

Deze databank zal ook gebruikt worden om de toegang tot de webapplicatie te regelen op basis van

een login en een paswoord. Deze combinatie is voor elke gebruiker uniek en laat toe om de gebruiker

te identificeren. UGent biedt via WebAuth de mogelijkheid om de paswoorden in een webapplicatie te

verifiëren.

Resultaten en discussie

19

5 Resultaten en discussie

Het reservatiesysteem bestaat uit drie delen. Het eerste deel betreft de aanmaak van een evenement

door de verantwoordelijke. De mogelijkheid voor de studenten om zich gemakkelijk in en uit te

schrijven vormt het tweede deel. Tenslotte moet de verantwoordelijke in staat zijn om een aangemaakt

evenement te wijzigen of te verwijderen. Figuur 5-1 geeft een overzicht van alle PHP-pagina’s die de

webapplicatie bevat. De rechthoeken geven de naam van de PHP-scripts weer. De pijlen duiden aan

hoe de scripts onderling verbonden zijn met elkaar. De exacte functies van de scripts worden in dit

hoofdstuk verder besproken.

overzicht logoutindexWebAuth

login

examen

examen2

examen3

practica

practica2

practica3

thesis

thesis2

thesis3

terug naar

index

inschrijven

scriptieinschrijven2

verwijder

wijzig

terug naar

overzicht

editEv

editEv2

editSe

editSe2

editGr

editGr2

Figuur 5-1: Overzicht van de PHP-scripts die de webapplicatie bevat (De rechthoeken geven de naam van

de PHP-scripts weer. De pijlen duiden aan hoe de scripts onderling verbonden zijn met elkaar.)


20

5.1 Controle van de gebruikers

De toegang tot de webapplicatie is beperkt tot de mensen die werken of studeren aan de Universiteit

Gent. Deze mensen beschikken over een unieke gebruikersnaam/paswoordcombinatie. De UGent

WebAuth-toepassing staat in voor het correct in- en uitloggen van de gebruikers. De belangrijkste

scripts van de webpagina worden weergegeven in Figuur 5-2. Na het inloggen komen de gebruikers op

de hoofdpagina (index.php) terecht. Hier wordt een overzicht gegeven van de evenementen waarvoor

men zich kan registreren. Door op het gewenste evenement te klikken, krijgt de gebruiker alle

informatie omtrent dit evenement te zien (overzicht.php). Na het uitloggen komt de gebruiker uiteraard

opnieuw terecht op de login-pagina van WebAuth.

Figuur 5-2: In- en uitloggen (De rechthoeken geven de naam van de PHP-scripts weer. De pijlen duiden

aan hoe de scripts onderling verbonden zijn met elkaar.)

5.2 Aanmaken van een evenement

In dit eindwerk werd een reservatiesysteem ontwikkeld zodat studenten voor bepaalde evenementen

kunnen inschrijven via het web. Deze evenementen worden aangemaakt door een docent of een

verantwoordelijke, vanaf hier beheerder genoemd. De beheerder kan hiervoor kiezen uit een lijst van

sjablonen. De sjablonen laten momenteel de aanmaak van evenementen als examens,

scriptieverdedigingen en practica toe. Deze lijst kan uiteraard nog verder uitgebreid worden.

Het is niet mogelijk voor studenten om een evenement aan te maken. Immers men moet behoren tot

een bepaalde vakgroep om aanzien te worden als een mogelijke beheerder. Dit wordt gecontroleerd

aan de hand van de login. Via LDAP wordt nagegaan of de persoon die inlogt over een

vakgroepnummer beschikt. Indien dit het geval is, wordt er na het inloggen een overzicht met de

geregistreerde evenementen en een sjablonenlijst weergegeven. Het is ook niet mogelijk om als

student toevallig op een pagina terecht te komen waar een evenement aangemaakt kan worden.

Immers elke pagina controleert, alvorens verder te gaan, of diegene die ingelogd is over een

vakgroepnummer beschikt. Figuur 5-3 geeft een overzicht van de scripts waarmee de evenementen


21

aangemaakt worden. Naargelang het type van het evenement komt de beheerder op examen.php,

thesis.php of practica.php terecht.

Figuur 5-3: Aanmaak van een evenement (De rechthoeken geven de naam van de PHP-scripts weer. De

pijlen duiden aan hoe de scripts onderling verbonden zijn met elkaar.)

Het aanmaken van een evenement gebeurt aan de hand van sjablonen. Dit zijn specifieke formulieren,

aangepast aan de omstandigheden. Dit laat de beheerder toe om die gegevens, die voor een bepaald

geval van toepassing zijn, in te vullen. Hierbij wordt er vermeden dat de beheerder met de algemene

structuur van de databank geconfronteerd wordt.

Nadat de beheerder een keuze heeft gemaakt uit de sjablonenlijst om een bepaald type evenement in te

voeren, komt hij op de ‘evenement’-pagina terecht. Als voorbeeld wordt hier de aanmaak van een

examen genomen (zie Figuur 5-4). In dit geval komt de beheerder dus op examen.php terecht. Hier

voert hij eerst de naam van het evenement in en een eventuele mededeling. Om dubbele gegevens in

de databank te voorkomen, is het onmogelijk om twee evenementen met dezelfde naam aan te maken.

Het type en de verantwoordelijke van het evenement moeten niet ingevuld worden omdat deze reeds

gekend zijn. Aan de hand van de keuze van de beheerder staat het type (examen, scriptieverdediging


22

of practicum) van het evenement reeds vast. De naam van de verantwoordelijke wordt bepaald uit de

login. Vervolgens kan de naam van de eerste sessie en een eventuele vraag, die de beheerder aan de

studenten wil stellen, ingevuld worden. Wanneer het evenement een examen is, is er nog een keuzelijst

voorzien om het type (mondeling of schriftelijk) van de sessie aan te duiden. Bij een practicum kan er

aangevinkt worden of dit het volledige semester doorgaat of niet. De beheerder kan zoveel sessies

toevoegen als hij wil. Telkens wanneer een sessie toegevoegd wordt, worden de gegevens van de

voorgaande sessie overgenomen. Op die manier wordt vermeden dat identieke gegevens meermaals

ingevuld moeten worden. Door op OK te klikken, bevestigt de beheerder de ingevulde gegevens en

komt hij op de ‘sessie’-pagina terecht, als alle verplichte velden ingevuld zijn tenminste. Zoniet, krijgt

de beheerder een waarschuwing waarin staat welke verplichte velden niet ingevuld zijn. Via de Go

Back-link keert de beheerder terug en kunnen de lege, verplichte velden alsnog ingevuld worden.

Figuur 5-4: De ‘evenement’-pagina

Op de ‘sessie’-pagina (examen2.php) worden alle gegevens van het net ingevoerde evenement en de

bijhorende sessies weergegeven. Bij elke sessie staat er standaard één groep waar de beheerder de

naam, het gebouw, het lokaal, de datum, het aantal studenten per groep, het begin- en het einduur kan

invullen (zie Figuur 5-5). Er is tevens een link voorzien naar de website van het Centraal

Auditoriumbeheer waar de beheerder kan nagaan welke lokalen er nog vrij zijn. De reservatie van de

gewenste lokalen kan direct gebeuren waardoor misverstanden voorkomen worden. Net als bij de


23

sessies kan de beheerder zoveel groepen toevoegen als nodig en worden de gegevens van de

voorgaande groep overgenomen. Wanneer een scriptieverdediging aangemaakt wordt, zullen het

begin- en het einduur van de volgende groep automatisch aangepast worden door een half uur bij te

tellen bij de voorafgaande. De ingevulde gegevens worden bevestigd door op de OK-knop te klikken.

Opnieuw wordt er gecontroleerd of de verplichte velden ingevuld zijn.

Figuur 5-5: Deel van de ‘sessie’-pagina

Wanneer alles correct ingevuld is, worden alle evenement-, sessie- en groepsgegevens via één

transactie (examen3.php) opgeslagen in de databank. De bedoeling is om te vermijden dat er

onvolledige gegevens in de databank terecht komen wanneer de aanmaak van een evenement plots

onderbroken wordt. Tot slot krijgt de beheerder een overzicht te zien van het net aangemaakte

evenement (overzicht.php).

Om de webapplicatie te beveiligen, worden de ingevoerde gegevens gecontroleerd vóór ze opgeslagen

worden in de databank. Dit gebeurt via de PHP-functie ‘addslashes’. Deze functie voegt backslashes

(\) toe voor de aanhalingstekens (‘ en “) en de backslashes. Om de slashes terug te verwijderen wordt

de functie ‘stripslashes’ gebruikt.

Op die manier is de databank beschermd tegen SQL-injection-aanvallen. SQL-injection is een vrij

actuele manier om een webapplicatie te hacken. Vooral online invulformulieren zijn hier kwetsbaar

voor, in het bijzonder als de ingevoerde gegevens rechtstreeks in een SQL-statement (opdrachten aan

de databank) ingevuld worden. Wanneer een bezoeker dan in plaats van normale informatie SQL-

statements in het formulier ingeeft, kan deze onrechtmatig toegang krijgen tot de databank van de

website (Seminarie "(Web) Application Assurance en Secure Coding", 2006).


24

5.3 Registreren voor een evenement

In principe zijn het enkel de studenten die in staat moeten zijn om zich te registreren voor een

evenement. Echter iedereen die inlogt op de site, kan zich inschrijven voor een evenement. Dit wil

zeggen professoren, medewerkers en studenten. De beheerder zelf heeft ook de mogelijkheid om zich

in te schrijven voor een door hem aangemaakt evenement. Dit kan nuttig zijn wanneer de beheerder

een evenement aanmaakt waaraan hij zelf wenst deel te nemen. Of wanneer een lijst afgedrukt wordt

met alle deelnemers die voor een bepaald evenement ingeschreven zijn. Figuur 5-6 toont de scripts van

de webapplicatie die zorgen voor het in- en uitschrijven van de gebruiker. De cursieve tekst in de

figuur geeft de acties van de gebruiker weer.

Figuur 5-6: In- en uitschrijven door de gebruikers (De rechthoeken geven de naam van de PHP-scripts

weer. De pijlen duiden aan hoe de scripts onderling verbonden zijn met elkaar.)

Na het inloggen krijgt de student het hoofdscherm (index.php) te zien met een overzicht van de

evenementen waarvoor hij/zij kan inschrijven. Door op het gewenste evenement te klikken, wordt alle

informatie omtrent de verschillende sessies en groepen van dit evenement weergegeven

(overzicht.php). Wanneer de student voor een bepaalde sessie nog niet is ingeschreven, is er bij elke

groep van deze sessie een knop ‘Inschrijven’ voorzien. Op deze manier kunnen studenten zich op een

eenvoudige manier inschrijven in een groep naar keuze. Uiteraard mag hierbij het maximum aantal

studenten per groep nog niet bereikt zijn. Indien dit wel het geval is, zal men voor deze groep niet


25

meer kunnen inschrijven. Als de sessie maar één groep bevat, krijgt de student uiteraard de

mogelijkheid zich voor de gewenste sessie in te schrijven. Naargelang er een sessievraag is, wordt er

voorzien om een antwoord in te geven (inschrijven2.php). Wanneer laatstejaarstudenten inschrijven

voor hun scriptieverdediging, wordt bijkomend de titel van de scriptie en het aantal studenten

gevraagd aan de eerste persoon die inschrijft bij een bepaalde groep (scriptie.php). Wanneer er per

twee aan gewerkt werd, zal de tweede persoon enkel de titel moet verifiëren alvorens deze in de groep

kan inschrijven.

Na het inschrijven keert de student terug naar de pagina van het gekozen evenement. Bij de gekozen

groep wordt de naam en de richting van de student in kwestie weergegeven alsook een knop

‘Uitschrijven’ en een knop ‘Wijzigen’. De naam en de richting van de student worden aan de hand van

de login opgevraagd via LDAP (zie 4.4). De knop ‘Uitschrijven’ zorgt ervoor dat de student in staat is

om zich uit te schrijven voor een bepaalde groep en terug in te schrijven bij een andere. Met de knop

‘Wijzigen’ kan de student zijn/haar antwoord op de sessievraag wijzigen. Een student kan enkel

zijn/haar gegevens wijzigen. De applicatie laat immers niet toe dat een student gegevens van andere

studenten kan wijzigen. Door te klikken op de naam van een medestudent kan de ingelogde student

deze een mail sturen.

5.4 Wijzigen of verwijderen van een evenement

Enkel de beheerder van een bepaald evenement kan het evenement wijzigen of verwijderen. De scripts

van de webapplicatie die daarvoor gebruikt worden, worden weergegeven in Figuur 5-7. De cursieve

tekst duidt de mogelijke acties aan van de beheerder. Wanneer de beheerder op het door hem

aangemaakte evenement klikt, ziet hij hetzelfde als wat de student te zien krijgt. Daarenboven beschikt

de beheerder nog over de mogelijkheid om een mail te sturen naar alle studenten van een bepaalde

groep of sessie. Ook bestaat de mogelijkheid om een student uit een groep te verwijderen via de

‘Schrap’-knop (verwijder.php). Bijkomend is de beheerder in staat om bepaalde zaken te wijzigen. Zo

kan door het aanklikken van de knop ‘Wijzigen’ bij een bepaalde groep het aantal studenten in die

groep gewijzigd worden of de datum, het uur en het gebouw aangepast worden. Er wordt hierbij echter

wel gecontroleerd of het gewijzigde aantal studenten in een groep groter of gelijk is aan het aantal

ingeschreven studenten in die groep. Indien dit niet het geval is, moet de beheerder eerst een aantal

personen schrappen in die groep.

Door het aanklikken van de ‘Toevoegen’-knop bij een specifieke sessie kan een groep toegevoegd

worden. Via ‘Wijzigen’ bij sessie kunnen de sessiegegevens veranderd worden. Uiteraard kunnen ook

de gegevens van het evenement gewijzigd worden of kan er een nieuwe sessie binnen dit evenement


26

aangemaakt worden (editEv.php). Binnen evenement kan het evenementtype echter niet meer

gewijzigd worden omdat er vanuit gegaan werd dat men een examen niet zal veranderen in bvb. een

practicum.

Figuur 5-7: Wijzigen en verwijderen in het overzicht van een evenement (De rechthoeken geven de naam

van de PHP-scripts weer. De pijlen duiden aan hoe de scripts onderling verbonden zijn met elkaar.)

De beheerder kan alles dus nog aanpassen in deze weergave (zie Figuur 5-8). Bij het wijzigen van een

groep of sessie verschijnt een invulformulier, respectievelijk editGr.php of editSe.php, waarin alle

gegevens van die groep of sessie al staan ingevuld. De beheerder hoeft dus enkel de gegevens aan te

passen waar nodig. Zoals in 5.3 besproken werd, wordt ook hier telkens gecontroleerd of de verplichte

velden ingevuld zijn. Het verwijderen van een bepaalde groep, sessie of het volledige evenement

gebeurt met de knop ‘Verwijderen’. Na het aanbrengen van wijzigingen of verwijderen is het mogelijk

om een mail te sturen naar alle betrokken studenten.


27

Figuur 5-8: Aangemaakt evenement bestaande uit één sessie

Er werd tevens gedacht om de mogelijkheid te voorzien om evenementen te verwijderen of te

verbergen wanneer deze voorbij waren. Deze functionaliteit werd echter niet voorzien. Hierdoor kan

men achteraf nog opzoeken hoe de indeling van een evenement precies in elkaar zat en wie waarvoor

ingeschreven was. Het is dan aan de beheerder om zijn/haar evenementen te verwijderen wanneer

hij/zij deze niet meer nodig heeft. Zoals reeds vermeld beschikt de beheerder hiervoor over de nodige

functionaliteit.


28

5.5 Grootte van de webapplicatie

Figuur 5-9 geeft een idee van de omvang van de code. Per functionaliteit van de site wordt het aantal

lijnen code weergegeven. De webapplicatie bevat in totaal 24 PHP-scripts en is goed voor 2300 lijnen

code. Zoals verwacht neemt het aanmaken van een evenement het grootste deel van de scripts (zie

Figuur 5-3) en bijgevolg ook van de code in beslag. Daarna volgen respectievelijk de functionaliteiten

editeren, overzicht en registreren.

0

200

400

600

800

1000

overzicht aanmaken registreren editeren

PHP-scripts

Co

de (

aan

tal

lijn

en

)

Figuur 5-9: De verschillende functionaliteiten van de webapplicatie met de grootte van hun code

Besluit

29

6 Besluit

Het doel van deze scriptie was het ontwikkelen van een webgebaseerd registratiesysteem. Het systeem

zorgt ervoor dat studenten op een vlotte manier kunnen in- en uitschrijven voor de evenementen

(examens, practica en scriptieverdedigingen) waaraan ze moeten deelnemen. Het laat tevens toe dat

deze evenementen door beheerders aangemaakt worden. Bovendien is het mogelijk om deze

evenementen achteraf nog te wijzigen of om deze geheel of gedeeltelijk te verwijderen.

Uit literatuuronderzoek bleek dat het niet mogelijk was om te vertrekken van een bestaand

registratiesysteem. Deze systemen zijn doorgaans complex en duur. Daarenboven beschikken ze niet

over de functionaliteit die hier beoogd wordt. Er werd dan ook geopteerd om zelf een systeem te

ontwerpen dat afgestemd is op de noden van de student en de lesgevers. De architectuur van het

reservatiesysteem is gebaseerd op evenementen die bestaan uit één of meerdere sessies. Hiervoor

kunnen studenten zich inschrijven. Deze sessies bestaan op hun beurt uit één of meerdere groepen van

elk een bepaald aantal studenten.

Voor deze studie werd een relationele databank gekozen omdat de gegevens op een efficiënte manier

opgeslagen kunnen worden. MySQL werd als databankbeheerssysteem gebruikt. Het beheren van de

MySQL-databank gebeurde met phpMyAdmin, de bevraging met SQL. Bij het ontwerpen van de

databank moest er afgerekend worden met een tijd-ruimte probleem. Er moest uitgemaakt worden of

het gebouw, het lokaal, de datum, het begin- en het einduur kenmerken zijn van een sessie of van een

groep. Het probleem werd opgelost door alle eigenschappen bij de groepen te plaatsen. Bij het

uitschrijven wordt er getest welke eigenschappen bij de groep uitgeschreven moeten worden en welke

bij de sessie. De webapplicatie zelf werd met PHP en JavaScript gecreëerd.

In dit eindwerk werd er rekening gehouden met de minpunten van het vorige reservatiesysteem. Dit

systeem stelde elke activiteit voor als een sessie die bestaat uit een aantal groepen. Wanneer een

activiteit over meerdere tijdstippen of plaatsen gespreid wordt, moest er een andere sessie aangemaakt

worden. Doordat elke sessie apart weergegeven werd, ging het overzicht van deze activiteit verloren.

Daarom werd er besloten om een activiteit in het nieuwe reservatiesysteem weer te geven als één

evenement dat opgesplitst kan worden in sessies. Net zoals in het vorige systeem, bevatten deze

sessies één of meerdere groepen.

Voorheen had de docent reeds de mogelijkheid om bij een bepaalde sessie een vraag te stellen aan de

studenten. Een antwoord hierop kon echter niet geregistreerd worden. Het nieuwe systeem verhelpt dit

euvel. Verder ontbrak het de docent aan mogelijkheden om sessiegegevens vlot aan te passen. Het

Besluit

30

nieuwe systeem laat toe dat informatie van het evenement, de sessies en de groepen aangepast kan

worden via een interactief overzicht. Via hetzelfde overzicht kunnen er in een evenement sessies en

groepen toegevoegd of verwijderd worden. Studenten kunnen hiervan telkens op de hoogte gebracht

worden. Tenslotte dienden met het voorgaande systeem alle activiteiten te worden aangemaakt via

hetzelfde formulier. Door het gebruik van sjablonen, moet nu enkel die informatie ingegeven worden

die voor de aanmaak van een bepaald evenement van toepassing is. Deze informatie kan immers

verschillen naargelang het soort evenement dat aangemaakt wordt.

Het nieuwe reservatiesysteem voorziet dat er per sessie één vraag gesteld kan worden. Naar de

toekomst toe kan dit uitgebreid worden door een extra tabel toe te voegen waarin een aantal

standaardvragen opgeslagen worden. De beheerder kan hieruit dan een aantal vragen selecteren

waarop de gebruikers moeten antwoorden. Deze antwoorden worden dan bij hun deelname aan een

bepaalde groep opgeslagen en worden weergegeven bij het overzicht van het betreffende evenement.

Tijdsgebrek zorgde ervoor dat een aantal zaken niet verwezenlijkt konden worden. Zo is er nog de

behoefte aan een controle van de gegevens – die men in de talrijke formulieren kan invullen – alvorens

deze in de databank ingevoerd worden. Wanneer bvb. tijdstippen ingevuld worden die niet mogelijk

zijn, zou er een foutmelding moeten weergeven worden. Tevens moet de mogelijkheid voorzien

worden om deze fouten dan te corrigeren.

Inhoudsopgave

31

7 Literatuurlijst

De Tré, G. (2006). Databanktechnologie. Cursus, Universiteit Gent, Faculteit

Ingenieurswetenschappen.

Greefhorst, D. & Maat, M. (1997). Unified Modeling Language, een overzicht. Software

Engineering Research Centre, 42p.

Greenspan, J. & Bulger, B. (2001). MySQL/PHP Databank applicaties. Academic Service, Den

Haag, 589p.

Kaaitheater. (2006). http://www.kaaitheater.be

Meidan, A. & Chiu, H. (1995). Hotel reservation methods – a discriminant analysis of practices in

English Hotels. Int. J. Hospitality Management, 14, p 195-208.

PHP Hypertext Preprocessor. (2006). http://www.php.net

Seminarie "(Web) Application Assurance en Secure Coding". (2006). http://www.ascure.com

Tennisclub Olympos. (2006). http://www.tcolympos.com/asp/wplan0.asp

Teodorovic, D. & Lucic, P. (2005). Intelligent parking systems. European Journal of Operational

Research.

Wiversoft. (2006). http://www.wiversoft.be/online_demo.php

W3Schools Online Web Tutorials. (2006). JavaScript Tutorial. http://www.w3schools.com

Ontwerp van een webgebaseerd registratiesysteem

Documents

Transcript of Ontwerp van een webgebaseerd registratiesysteem