ontwerp van een webgebaseerd registratiesysteem
Post on 19-Apr-2022
2 Views
Preview:
TRANSCRIPT
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
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.
Bestaande reservatiesystemen
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).
Bestaande reservatiesystemen
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
Bestaande reservatiesystemen
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
Architectuur van het 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).
Architectuur van het registratiesysteem
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.
Architectuur van het registratiesysteem
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
Architectuur van het registratiesysteem
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
Inkomende verwijzing
A
Ja
Figuur 3-4: Functionaliteit voor de gebruiker bij registratie van scriptieverdedigingen
Architectuur van het registratiesysteem
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.
Architectuur van het registratiesysteem
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
Inkomende verwijzing
Figuur 3-5: Functionaliteit voor de beheerder bij registratiesystemen
Architectuur van het registratiesysteem
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
Architectuur van het registratiesysteem
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’.
Architectuur van het registratiesysteem
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.
Materiaal en methoden
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).
Materiaal en methoden
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.)
Resultaten en discussie
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
Resultaten en discussie
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
Resultaten en discussie
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
Resultaten en discussie
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).
Resultaten en discussie
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
Resultaten en discussie
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
Resultaten en discussie
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.
Resultaten en discussie
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.
Resultaten en discussie
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
top related