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

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 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

4

5

CONCEPTEN VAN REGISTRATIESYSTEMEN ________________________________________________ 6

ONTWIKKELING VAN HET REGISTRATIESYSTEEM__________________________________________ 13

3.2.1

Problematiek ___________________________________________________________________ 13

3.2.2

Resulterende databank ___________________________________________________________ 14

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

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 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.

1

Bestaande reservatiesystemen

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.

2

Bestaande reservatiesystemen 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).

3

Bestaande reservatiesystemen 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

4

Bestaande reservatiesystemen 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.

5

Architectuur van het registratiesysteem

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 UseCasediagrammen. 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.

Registratiesysteem

Inschrijven

Verwijderen

Wijzigen

«uses»

«extends»

«extends»

Overzicht evenementen

Overzicht evenementen

«uses» Gebruiker

Beheerder Aanmaken evenementen

Uitschrijven

Legende Actor

Systeem

Use-Case «uses»

Communicates-relatie «extends»

Uses-relatie

Extends-relatie

Figuur 3-1: Use-Casediagram van een registratiesysteem

6

Architectuur van het registratiesysteem 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 UseCases 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 UseCases 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).

7

Architectuur van het registratiesysteem

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.

8

Architectuur van het registratiesysteem 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.

Functionaliteit voor gebruiker Algemeen

Uitschrijven

Inschrijven niet meer mogelijk Gegevens wijzigen Ja

Ja Neen

A

Overzicht bepaald evenement

Reeds ingeschreven?

Max bereikt ?

Neen

Inschrijven

Legende

Inkomende verwijzing

Toestand

Actie

Beslissing

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

9

Architectuur van het registratiesysteem 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.

Functionaliteit voor gebruiker Specifiek voor scriptieverdedigingen

Uitschrijven

Inschrijven niet meer mogelijk Gegevens wijzigen Ja A

Overzicht scriptieverdedigingen

Reeds ingeschreven?

Ja Neen

Max bereikt ?

Neen

Scriptietitel opgeven

Inschrijven

Neen

Andere leden ingeschreven? Ja

OK

Scriptietitel verifieren

Niet OK

Legende

Inkomende verwijzing

Toestand

Actie

Beslissing

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

10

Architectuur van het registratiesysteem 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.

11

Architectuur van het registratiesysteem

Functionaliteit voor beheerder

Evenement verwijderen Eventueel mail versturen

Verwijderen

Ja

Controle OK?

Wijzigen

Ja Verplichte velden ingevuld? Neen

Toevoegen

Weergave evenement

Ja

B Neen

Controle OK?

Ja Aanmaak van een evenement

Gegevens invoeren

Verplichte velden ingevuld? Neen

Legende

Inkomende verwijzing

Toestand

Actie

Beslissing

Figuur 3-5: Functionaliteit voor de beheerder bij registratiesystemen

12

Neen

Architectuur van het registratiesysteem

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

13

Architectuur van het registratiesysteem 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’.

14

Architectuur van het registratiesysteem 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.

15

Materiaal en methoden

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.

16

Materiaal en methoden 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).

17

Materiaal en methoden

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.

18

Resultaten en discussie

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.

WebAuth login

index

overzicht

logout

inschrijven

verwijder

examen

thesis

practica

editEv

editSe

editGr

examen2

thesis2

practica2

editEv2

editSe2

editGr2

examen3

thesis3

practica3

inschrijven2

scriptie wijzig

terug naar overzicht

terug naar index

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.)

19

Resultaten en discussie

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

20

Resultaten en discussie 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 21

Resultaten en discussie 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

22

Resultaten en discussie 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 SQLstatements in het formulier ingeeft, kan deze onrechtmatig toegang krijgen tot de databank van de website (Seminarie "(Web) Application Assurance en Secure Coding", 2006).

23

Resultaten en discussie

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

24

Resultaten en discussie 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

25

Resultaten en discussie 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.

26

Resultaten en discussie

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.

27

Resultaten en discussie

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.

Code (aantal lijnen)

1000 800 600 400 200 0 overzicht

aanmaken

registreren

editeren

PHP-scripts

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

28

Besluit

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

29

Besluit 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.

30

Inhoudsopgave

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

31