IN3405 Eindverslag Bachelorproject Applicatie Voor Aanvragen Studie Toelatingsadvies Mark Hendrikx 1358294
Olaf Sch¨ usler 1268090 Bachelorco¨ ordinator Drs. P.R. van Nieuwenhuizen Begeleider Prof.dr. A. de Bruin Opdrachtgever Dhr. M.A.F.M. Jacobs
29 juni 2010
Voorwoord Dit document is bedoeld als afsluiting van het bachelor eindproject van Mark Hendrikx en Olaf Sch¨ usler, voor het project “Alle H@nds Aan Dek”. Voor dit project is er uitgebreid samengewerkt met Martin Jacobs van Technische Natuurkunde, TU Delft, en de partners van de deelnemende universiteiten. Deze partners willen wij hier graag voor bedanken. Daarnaast hebben wij begeleiding ontvangen van dhr. de Bruin, TU Delft, bij het opstellen van de database, welke wij hier ook voor willen bedanken. Ten slotte willen wij dhr. van Nieuwenhuizen bedanken voor zijn ondersteuning tijdens het bachelorproject.
i
Samenvatting In dit document wordt samengevat het proces en de evaluatie van het bachelorproject uiteengezet. De uiteindelijke bacheloropdracht luidt als volgt: Ontwerp een programma dat op basis van de ingevulde opleidingsgegevens en historische gegevens, de commissie vergelijkbare cases geeft, zodat er een transparant advies gegeven kan worden. De applicatie zal twee type gebruikers kennen. De eerste, de kandidaat, zal met behulp van het programma een aanvraag moeten kunnen indienen voor toegang tot een Universitaire Leraren Opleiding. De tweede, de commissie, zal de aanvragen van de kandidaten moeten kunnen ontvangen, en bij het verwerken gebruik kunnen maken van vergelijkbare cases. Voor de implementatie zijn de volgende onderwerpen onderzocht: 1. Encryptie van lokale data. Er is gekozen voor versleutelde serializatie van een object. 2. Database-engine. Er is gekozen voor de database-engine InnoDB. 3. Webtalen. Er is gekozen voor de webtalen HTML, Javascript, en CSS. 4. Beveiliging. Er is gekozen voor een beveiligde TLS verbinding. Wat betreft het PvE is een onderscheid gemaakt tussen eisen voor de admin, kandidaat, toelatingscommissie, en alle gebruikers. De eisen zijn erop gericht dat de kandidaat zo weinig mogelijk hoeft in te vullen, en de commissie gebruik kan maken van vergelijkbare cases bij het verwerken van de aanvragen. Hierna is aan de hand van het PvE het ontwerp opgesteld. Het databasediagram is hierbij zo generiek mogelijk opgezet, zodat de applicatie in de toekomst kan worden uitgebreid. Vervolgens zijn de controllers en modelklassen opgesteld. Hierbij is gebruik gemaakt van model/view/controller. Tot slot zijn de view-klassen opgesteld, wat de websites zijn die de gebruikers te zien krijgen. De kandidaat vult hierbij als het ware een digitaal profiel in, waarna hij een aanvraag kan indienen. Vervolgens is aan de hand van het ontwerp de applicatie ge¨ımplementeerd. Hierbij is het ontwerp geheel aangehouden. Momenteel is het admin- en kandidaatgedeelte van de applicatie ge¨ımplementeerd. Gebruikerstests en de implementatie van het commissiegedeelte zullen plaatsvinden na het bachelorproject. Tot slot is een evaluatie gegeven van het bachelorproject. Aan de hand van een presentatie aan de projectleiders, wordt van de applicatie door de toelatingscommissies erg veel verwacht. Zelf hadden we verwacht momenteel verder te zijn met de implementatie, maar we zijn zeer tevreden met het resultaat. De komende maanden zal gewerkt worden om aan de verwachtingen te voldoen. ii
Inhoudsopgave 1 Project 1.1 Opdrachtbeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Actoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 2 3
2 Gebruikte technieken 2.1 Encryptie van lokale data 2.2 Database-engine . . . . . 2.3 Webtalen . . . . . . . . . 2.4 Beveiliging . . . . . . . .
. . . .
4 4 5 6 6
3 Planning 3.1 Voorgenomen planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Werkelijke planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 7 8
. . . .
4 Programma van eisen 4.1 Programma-eisen . . . . . . 4.1.1 Alle gebruikers . . . 4.1.2 Admin . . . . . . . . 4.1.3 Kandidaat . . . . . . 4.1.4 Toelatingscommissie 4.2 Kwaliteitseisen . . . . . . . 4.2.1 Betrouwbaarheid . . 4.2.2 Performance . . . . 4.2.3 Veiligheid . . . . . . 4.2.4 Onderhoudbaarheid 4.2.5 Bruikbaarheid . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
9 12 12 12 12 13 14 14 14 14 14 14
5 Ontwerp 5.1 Klassendiagram . . . . . . . . 5.2 Beschrijving controllerklassen 5.2.1 AdminController . . . 5.2.2 CandidateController . 5.2.3 DatabaseController . . 5.2.4 MemberController . . 5.2.5 Page . . . . . . . . . . 5.3 Beschrijving modelklassen . . 5.3.1 Actor . . . . . . . . . 5.3.2 Candidate . . . . . . . 5.3.3 Committee . . . . . . 5.3.4 Course . . . . . . . . . 5.3.5 CoursesCollection . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
15 15 18 18 18 18 18 18 19 19 19 19 19 19
iii
5.4
5.5 5.6
5.3.6 Mapping . . . . . . . . . . . . . . 5.3.7 Member . . . . . . . . . . . . . . 5.3.8 Request . . . . . . . . . . . . . . Beschrijving viewklassen . . . . . . . . . 5.4.1 Websites van admin . . . . . . . 5.4.2 Websites van kandidaat . . . . . Databaseontwerp . . . . . . . . . . . . . 5.5.1 Databasetabellen . . . . . . . . . GUI . . . . . . . . . . . . . . . . . . . . 5.6.1 Ontwerpkeuzes . . . . . . . . . . 5.6.2 Profielscherm . . . . . . . . . . . 5.6.3 Dynamisch toevoegen van HTML
6 Implementatiebeschrijving 6.1 Deelsystemen . . . . . . . . . . . 6.1.1 Database . . . . . . . . . 6.1.2 Model . . . . . . . . . . . 6.1.3 Controller . . . . . . . . . 6.1.4 View . . . . . . . . . . . . 6.2 Status . . . . . . . . . . . . . . . 6.2.1 Vaststellen doel applicatie 6.2.2 Opstellen Programma van 6.2.3 Admingedeelte . . . . . . 6.2.4 Kandidaatgedeelte . . . . 6.3 Future work . . . . . . . . . . . . 6.3.1 Commissiegedeelte . . . . 6.3.2 Testen en installeren . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . Eisen . . . . . . . . . . . . . . . . . . . .
7 Procesbeschrijving 7.1 Begeleiding en feedback . . . . . . . 7.1.1 Opdrachtgever . . . . . . . . 7.1.2 Toelatingscommissies . . . . . 7.1.3 Bachelorco¨ ordinator . . . . . 7.1.4 Begeleider . . . . . . . . . . . 7.2 Conclusie . . . . . . . . . . . . . . . 7.3 Evaluatie . . . . . . . . . . . . . . . 7.3.1 Evaluatie van Mark Hendrikx 7.3.2 Evaluatie van Olaf Sch¨ usler .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
19 19 19 20 20 20 21 22 23 23 23 24
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
25 25 25 25 26 26 27 27 27 27 27 28 28 28
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
29 29 29 29 30 30 30 31 31 33
Appendices
35
A Design Document
35
B Onderzoeksverslag
88
C Implementation document
109
D Presentatie werkpakket 4A
171
iv
Inleiding Voor velen is het bachelorproject de afsluiting van de bachelorstudie. In dit project wordt de kennis die de afgelopen jaren is verkregen, omgezet in hoogwaardige software. Om deze transitie tot stand te brengen is de kennis van de bachelor “Technisch Informatica” onvoldoende, er zijn immers verschillende onderwerpen die niet in de studie zijn behandeld. In dit document wordt het project aan de hand van het probleem, het process, en een persoonlijke evaluatie behandeld. Hierbij zal gekeken worden naar hoe het project in eerste instantie ontstond, hoe daarna de ontwikkeling gelopen is, en hoe het vervolgens in onze ogen gelopen is. Allereerst zal een duidelijke projectomschrijving worden gegeven, waardoor een beeld gevormd kan worden van de opdracht en de actoren (H1). Vervolgens zullen de gebruikte technieken, en de criteria waarop deze gekozen zijn, beschreven worden (H2). Dit hoofdstuk zal worden gevolgd door de planning (H3), het programma van eisen (H4), het ontwerp (H5), en de implementatie van de applicatie (H6). Ten slotte zal een evaluatie van het project, de begeleiding en de feedback op het product worden gegeven (H7).
1
Hoofdstuk 1
Project Gedurende het project is de opdrachtbeschrijving aan verandering onderhevig geweest. Feitelijk zijn er twee verschillende opdrachten geweest, waarbij de eerste uiteindelijk niet haalbaar bleek te zijn. Deze beide opdrachten zullen hieronder beschreven worden, gevolgd door de actoren die uiteindelijk gebruik zullen maken van het programma.
1.1
Opdrachtbeschrijving
Eerste opdracht
De opdrachtbeschrijving is:
Ontwerp een programma dat een advies geeft gebaseerd op historische gegevens. De uitleg die hieraan gegeven werd was twee¨elerlij. Aan de ene kant moest er een database komen met daarin de historische gegevens en adviezen van eerdere kandidaten, en aan de andere kant moest het systeem op basis van deze gegevens een advies genereren, wat de commissie vervolgens alleen hoeft na te kijken en goed te keuren. . Historische gegevens: Gedurende de jaren zijn er meerdere kandidaten bij de verschillende toelatingscommissies geweest die ongeveer hetzelfde advies aanvroegen. Omdat de commissies vaak niet van elkaar wisten dat deze kandidaten geweest waren, moest het werk meerdere keren overgedaan worden. Deze gegevens van de toelatingscommissies moeten gebruikt worden zodat commissies niet steeds werk overdoen, maar gebruik kunnen maken van historische adviezen. . Advies genereren: Op basis van de gegeven vooropleidingen moet er een mapping gemaakt worden op domeinen, vastgelegd door de VSNU (Vereniging van Samenwerkende Nederlandse Universiteiten). Dit gebeurt door de vakken uit een studie aan domeinen te koppelen, deze vervolgens te vergelijken met de domeinen van de doelstudie, en terug te geven aan de toelatingscommissie welke vakken de kandidaat zou moeten volgen. Tweede opdracht De opdrachtbeschrijving voor het programma is nu meer gericht op het maken van een ondersteunende applicatie: Ontwerp een programma dat op basis van de ingevulde opleidingsgegevens en historische gegevens, de commissie vergelijkbare cases geeft, zodat er een transparant advies gegeven kan worden.
2
Hiermee vervalt effectief het genereren van advies. Er hoeft namelijk alleen nog informatie getoond te worden aan de toelatingscommissie die gerelateerd is met de case waar ze op dat moment mee bezig zijn. Dit betekent dat de taak van het programma eenvoudiger geworden is, en de opdrachtomschrijving inhoudt dat opleidingen ingevoerd en beoordeeld moeten kunnen worden, op basis van bestaande adviezen of vanuit eigen inzicht.
1.2
Actoren
Binnen dit project zijn er twee groepen die gebruik zullen maken van het programma. Dit zijn enerzijds de kandidaten die toegelaten willen worden tot de universitaire lerarenopleiding, en anderzijds de toelatingscommissies die beslissen over de toelatingseisen voor de universitaire lerarenopleidingen. Kandidaat: is iemand die een eerstegraads docent wil worden in een bepaald schoolvak. Hiervoor vraagt hij aan de toelatingscommissie welke kennis hij tekort komt, welke hij vervolgens weg zal moeten werken voor hij aan de lerarenopleiding kan beginnen. Commissie: is het orgaan, aangesloten bij de universiteit, welke bepaalt wie er toegelaten zal worden tot de lerarenopleiding en welke vakken hij hiervoor nog moet doen. In deze commissie zijn een aantal rollen vertegenwoordigd: . Secretaris: handelt de communicatie met de kandidaat af en is hiermee het centrale aanspreekpunt voor de commissie. . Vakdidacticus: heeft de vakspecifieke kennis en kent vakken toe aan de vakdefici¨enties die de kandidaat heeft. . Voorzitter: is de voorzitter tijdens vergaderingen als er overlegd moet worden over de adviezen.
3
Hoofdstuk 2
Gebruikte technieken Voor het programma is er op een aantal gebieden keuzes gemaakt. Deze zijn voornamelijk gebaseerd op de mogelijkheden die onderzocht zijn in het onderzoeksverslag. Het volledige onderzoek is na te lezen in de bijlage, maar de hoofdpunten zullen in dit verslag nog kort besproken worden.
2.1
Encryptie van lokale data
Bescherming van persoonsgegevens is voor dit project een van de belangrijkste onderwerpen. Met dit in gedachte zijn er een aantal criteria opgesteld op basis waarvan de bestaande technieken worden beoordeeld. Deze criteria zijn: “coderen”, “decoderen”, “veiligheid”, “unieke sleutel”, “legaliteit”, en “geen extra software”. . Coderen/decoderen. De informatie moet eenvoudig te coderen en decoderen zijn binnen acceptabele tijd. . Veiligheid. Volgens de aanwijzingen van het college bescherming persoonsgegevens, moeten de gegevens niet bereikbaar zijn voor derden. Hiervoor is er als criterium voor gekozen dat er technieken gebruikt moeten worden die binnen afzienbare tijd niet te kraken zijn. . Unieke sleutel. De sleutel voor het coderen van de gebruikersgegevens moet voor iedere gebruiker uniek zijn. Op dit manier is het niet mogelijk voor een gebruiker om achter de gegevens van een andere gebruiker te komen. . Legaliteit/extra software. De software die nodig is voor de encryptie moet toegelaten zijn in Nederland en er moet geen extra software benodigd zijn. Oplossing In het onderzoekverslag zijn drie verschillende technieken behandeld. Deze technieken zijn: een aparte database, serialization van de gegevens, en encrypted serialization. In tabel 2.1 wordt een vergelijking van de technieken weergegeven, en wordt duidelijk dat voor encrypted serialization gekozen is gekozen.
4
Tabel 2.1: Beoordelingsmatrix oplossingen Criteria
Encrypted tion Encoderen + ++ + Decoderen + ++ + Veiligheid ++ – ++ Unieke sleutel – ++ ++ Legaliteit +/++ +/Geen extra software ++ ++ De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/-
2.2
Database
Serialization
serializa-
Database-engine
De historische gegevens en de opleidingsgegevens zullen opgeslagen moeten worden en op een zodaninge manier dat de database ten alle tijden consistent is. Verder is er nog een aantal andere criteria op basis waarvan de database beoordeeld zal worden. Deze zijn “Beschikbaarheid”, “PK/FK constraints”, “Transacties”, en “Fulltext index”. Deze zullen hieronder verder beschreven worden. . Beschikbaarheid. De engine moet standaard bij MySQL worden geleverd, en er moeten indicaties zijn dat dit de komende versies zo blijft. . Primary key/foreign key constraints. De engine moet de mogelijkheid hebben om primary key/foreign key constraints te bekrachtigen. Hierdoor is het mogelijk dat als er wat gebeurt met een record met de primary key, er automatisch een actie wordt ondernomen om de gerelateerde record(s), met de primary key als foreign key, te updaten. Hierdoor wordt de integriteit van de database beschermd. . Transacties. De engine moet werken met transacties, waardoor het mogelijk is voor een gebruiker om meerdere queries in een keer uit te voeren, en het resultaat te bekijken, zonder dat de database direct wordt ge¨ update voor de overige gebruikers. Pas als de gebruiker het commit commando heeft uitgevoerd, worden de wijzigingen voor iedereen zichtbaar. Als bijkomend voordeel kan een transactie automatisch worden teruggedraaid, en worden de wijzigingen automatisch teruggedraaid als in een transactie de verbinding van de gebruiker wegvalt. . Fulltext index. De engine moet fulltext index ondersteunen. Dit houdt in dat elk textveld (VARCHAR, CHAR, TEXT) wordt gezien als een veld wat een text bevat. Deze text kan bestaan uit verschillende woorden. Voor elk woord dat langer is dan drie characters wordt een speciale index aangemaakt, zodat deze snel kan worden gevonden. Met behulp van speciale queries is het mogelijk om naar een woord te zoeken dat deel is van een record. Het gezochte woord moet wel minimaal vier letters bevatten, want elke substring van drie characters of minder wordt automatisch genegeerd. Hierdoor is het mogelijk om in een grote hoeveelheid text zeer snel te zoeken. Oplossing In het onderzoeksverslag worden 2 implementaties van database-engines gegeven. Deze worden in de tabel hieronder (table 2.2) beschreven. Uit deze table komt duidelijk naar voren dat InnoDB de beste keuze is voor een database.
5
Tabel 2.2: Beoordelingsmatrix oplossingen Criteria MyISAM Beschikbaarheid ++ PK/FK constraints -Transacties -Fulltext index ++ De schaal van de beoordeling loopt van - - tot ++.
2.3
InnoDB + ++ ++ -Neutraal wordt aangegeven met +/-
Webtalen
Voor de webtalen hoefde er nauwelijks onderzoek gedaan te worden, aangezien de talen die over het algemeen gebruikt worden standaard zijn. Er worden binnen het project een aantal talen gebruikt, zoals “HTML5”, “PHP”, “JavaScript” en “CSS”. Deze talen worden gebruikt voor het structureren van de pagina’s, het verwerken van de dynamische gegevens zoals uit de database, het dynamisch checken van formulieren, en het stijlen van de pagina’s. . HTML5. HTML5 is een opmaaktaal die bedoeld is om websites op te bouwen, zoals het structureren in tabellen en het aangeven van formulieren. . PHP. PHP is gericht op het dynamisch werken met gegevens, zoals het ophalen van databasegegevens en het verwerken van formulieren. Dit gebeurt dynamisch op de server en wordt vervolgens in HTML in de browser weergegeven. . JavaScript. JS (JavaScript) is net als PHP een dynamische scripttaal, maar draait lokaal in plaats van op een server. Hierdoor kan deze realtime gebruikt worden voor het checken van gegevens die ter plekke ingevoerd worden in een formulier. . CSS. Voor het opmaken van een document wordt standaard CSS gebruikt. CSS be¨ınvloedt het uiterlijk van een website met behulp van style sheets. Een style sheet is eenvoudig te vervangen, waardoor de website een compleet nieuwe opmaak krijgt.
2.4
Beveiliging
Ten slotte moet het systeem niet alleen beveiligd zijn tegen aanvallen van buitenaf op het systeem, maar mogen er ook geen gegevens, bijvoorbeeld via een man-in-the-middle-attack, worden uitgelezen. Om deze aanvallen tegen te gaan, wordt gebruik gemaakt van een TLS verbinding. Bij deze verbinding wordt voor het verzenden van een bericht aan wederzijde van de connectie de informatie versleuteld, en bij ontvangen weer gedecodeerd. De implementatie is te vinden in het onderzoeksrapport.
6
Hoofdstuk 3
Planning In dit hoofdstuk wordt de planning van het project besproken. In paragraaf 3.1 staat de voorgenomen planning. Vervolgens wordt in paragraaf 3.2 de werkelijke planning behandeld.
3.1
Voorgenomen planning
status
datum 10/02/2010 15/02/2010 01/03/2010 10/03/2010 15/03/2010 26/03/2010 26/03/2010 28/03/2010 02/04/2010 05/04/2010 06/04/2010 12/04/2010 18/04/2010 25/04/2010
18/05/2010 24/05/2010 31/05/2010 10/06/2010
14/06/2010 17/06/2010 18/06/2010
27/06/2010
Ontwerpfase taak programma van eisen probleem- en actorenanalyse grafische interface programma van eisen use cases database design scenario’s use cases scenario’s klassendiagram sequence diagram grafische interface functie blokschema morfologische kaart Implementatiefase model, controller, en view development core testen beta bugfixing release candidate bugfixing Testfase release testen code testen gebruikerstesten Pilotfase manual en beheerderstools overhandigen
7
bijzonderheden concept artists impression van user interface final (na overleg met toelatingscommissies) concept concept final (na overleg met selectie) final (na overleg met selectie)
final (na overleg met selectie)
gebruikerstesten (core) gebruikerstesten (high level) gebruikerstesten (goedkeuring)
3.2
Werkelijke planning Ontwerpfase
status
datum 10/02/2010 15/02/2010 15/03/2010 26/03/2010 28/03/2010 28/04/2010 05/05/2010 05/05/2010 15/05/2010 15/05/2010
15/06/2010 01/08/2010 15/08/2010 15/08/2010 31/08/2010
31/09/2010 31/09/2010
15/10/2010
taak programma van eisen probleem- en actorenanalyse grafische interface database design use cases programma van eisen 2 programma van eisen 3 klassendiagram final versie van programma van eisen use cases final (na overleg met selectie) Implementatiefase development kandidaat en admin development commissie core testen beta bugfixing release candidate bugfixing Testfase release testen gebruikerstesten Pilotfase manual en beheerderstools overhandigen
8
bijzonderheden concept artists impression van user interface concept
model, view, controller model, view, controller gebruikerstesten (core) gebruikerstesten (high level) gebruikerstesten (goedkeuring)
Hoofdstuk 4
Programma van eisen In dit hoofdstuk zal in paragraaf 4.1 het programma van eisen worden behandeld. Vervolgens zullen in paragraaf 4.2 de kwaliteitseisen worden behandeld. Beide paragrafen bevatten slechts een beknopte samenvatting van de complete herstructurering van het toelatingsproces, zoals in hoofdstuk 2 en 3 van het ontwerpverslag is beschreven. In figuur 4.1 is de websitestructuur voor de kandidaat weergegeven. Vervolgens is in figuur 4.2 de websitestructuur voor de commissie afgebeeld.
9
Figuur 4.1: Websitestructuur voor de kandidaat
10
Figuur 4.2: Websitestructuur voor de commissie
11
4.1
Programma-eisen
In deze paragraaf zullen beknopt de voornaamste eisen aan de applicatie worden weergegeven voor de verschillende gebruikers. Voor het gehele programma van eisen kunt u hoofdstuk 2 van het ontwerpverslag raadplegen.
4.1.1
Alle gebruikers
Hieronder worden voor alle gebruikers de globale eisen weergegeven: 1. De applicatie moet webbased worden. Hierdoor is het mogelijk om de applicatie overal te gebruiken. 2. Voor het gebruiken van de functies van de applicatie, behalve een vraag stellen aan een commissie, moet een account worden aangemaakt. Hierdoor is data-opslag en accountbeheer mogelijk. 3. Bij elk invoerveld moet een uitleg beschikbaar zijn. 4. De applicatie moet duidelijke feedback geven bij het optreden van fouten. 5. De applicatie moet volledig functioneren op alle moderne browsers. Voor een overzicht van de browsers kunt u terecht in paragraaf 2.4.1 van het ontwerpverslag. 6. Mailadressen van de toelatingscommissies moeten nooit zichtbaar zijn op de website.
4.1.2
Admin
Hieronder worden voor de admin de global eisen weergegeven: 1. De admin moet een nieuwe toelatingscommissie met een secretaris kunnen toevoegen. 2. De admin moet een nieuw schoolvak kunnen toevoegen. 3. De admin moet gebruikers toegang tot de applicatie kunnen ontzeggen. 4. De admin moet de verschillende kandidaten in de database kunnen bekijken. 5. De admin moet historische gegevens toe kunnen voegen aan de database.
4.1.3
Kandidaat
Hieronder worden voor de kandidaat de globale eisen weergegeven: 1. De kandidaat moet inloggen met een bestaand, of nieuw, account. Deze beschrijving betreft stap 3 t/m 7 in figuur 4.1. 2. De kandidaat moet een vorige sessie kunnen hervatten door in te loggen. Deze beschrijving betreft stap 3 in figuur 4.1. 3. De kandidaat hoeft niet ingelogd te zijn om een vraag te stellen aan een toelatingscommissie. 4. De kandidaat moet de verwerking van zijn aanvraagkunnen zien. 5. De kandidaat moet een indicatie kunnen krijgen van zijn studielast op basis van zijn relevantste vooropleiding. Deze beschrijving betreft stap 9 in figuur 4.1. 12
6. De kandidaat moet voor het aanvragen van een advies zijn cijferlijst(en) uploaden. Deze beschrijving betreft stap 10 in figuur 4.1. 7. De kandidaat moet zijn vakkenpakketten in kunnen vullen. Hierbij moet hij de mogelijkheid hebben om de vakkenpakketten in de historische gegevens te hergebruiken, zodat hij zo min mogelijk hoeft in te voeren. Deze beschrijving betreft stap 11 t/m 13 in figuur 4.1. 8. De kandidaat moet na het invullen van zijn vakkenpakketten zijn werkervaring in kunnen vullen. Deze beschrijving betreft stap 14 in figuur 4.1. 9. De kandidaat moet zijn vakken toekennen op kern- of subdomeinen afhankelijk van de voorkeur van het schoolvak. Bij het toekennen kunnen de historische gegevens worden hergebruikt. Deze beschrijving betreft stap 15 t/m 17 van figuur 4.1. 10. De kandidaat moet een aanvraag kunnen doen door een commissie en schoolvak te selecteren, en zijn vakkenpakketten, toekenningen, werkervaring, en cijferlijst in te vullen. Deze beschrijving betreft stap 8 t/m 19 in figuur 4.1. 11. De kandidaat moet voor het definitief versturen van zijn gegevens een overzicht krijgen van de data die hij heeft ingevuld. Hierbij moet hij de mogelijkheid tot bewerken hebben.
4.1.4
Toelatingscommissie
Hieronder worden voor de toelatingcommissie de globale eisen weergegeven: 1. Het lid moet inloggen om de gezamenlijke inbox te bekijken. De secretaris krijgt na inloggen voor elk schoolvak aan de universiteit de aanvragen in een inbox te zien, de vakdidacticus slechts ´e´en schoolvak. Deze beschrijving betreft stap 1 t/m 4 in figuur 4.2. 2. Het lid moet na inloggen de gezamenlijke inbox te zien krijgen. In de inbox zijn de binnengekomen aanvragen te zien, en de status van elke aanvraag. Deze beschrijving betreft stap 5 in figuur 4.2. 3. Het controleren van de mapping, en het toekennen van de geadviseerde vakken voor het wegwerken van de vakdefici¨enties, zijn sequenti¨ele taken. Deze moeten echter door verschillende leden van de toelatingscommissie uitgevoerd kunnen worden. 4. Het lid moet de de toekenning van de kandidaat kunnen wijzigen. Deze beschrijving betreft stap 6 t/m 11 in figuur 4.2. 5. Het lid moet bij het controleren van de mapping, en het toekennen van de geadviseerde vakken, de VSNU-gids en vergelijkbare cases op kunnen roepen. Deze beschrijving betreft stap 9 en 14 in figuur 4.2. 6. Het lid moet vakken kunnen toekennen aan de vakdefici¨enties. Deze beschrijving betreft stap 12 t/m 16 in figuur 4.2. 7. Het lid moet de mogelijkheidheid hebben om het uiteindelijke advies te kunnen versturen naar de kandidaat met een optioneel persoonlijk bericht. Deze beschrijving betreft stap 18 t/m 22 in figuur 4.2.
13
4.2
Kwaliteitseisen
In deze paragraaf worden samengevat de kwaliteitseisen aan de applicatie besproken. In hoofdstuk 3 van het ontwerpverslag is een compleet overzicht gegeven van de kwaliteitseisen.
4.2.1
Betrouwbaarheid
1. Landelijk mag maximaal ´e´en keer per maand een softwarefout optreden die tot gevolg heeft dat een gebruiker zijn hoofddoelen niet kan realiseren. 2. Landelijk mag een fout waarbij de gebruiker de gebruiker gehinderd wordt in de extra functionaliteit zich eens per week voordoen. 3. Elke maand dient een backup van de database te worden gemaakt. 4. Als een bewerking niet ongedaan kan worden gemaakt, dan moet dit worden weergegeven. 5. Van het programma moet minimaal 90% van de code getest zijn met behulp van tests.
4.2.2
Performance
1. Javascript moet op de computer van de gebruiker ge¨ınstalleerd zijn, zodat snelle verificatie van input kan plaatsvinden. 2. De website moet volledig werken, en een paginaovergang mag maximaal 10 seconden duren op een computer die voldoet aan de minimale eisen zoals gesteld in paragraaf 3.2 van het ontwerpverslag.
4.2.3
Veiligheid
1. Door het optreden van een fout in het programma mag geen data verloren gaan. 2. Het programma dient bij elke mogelijke fout een eenvoudige uitleg te geven aan de gebruiker hoe deze verholpen kan worden. 3. Het programma moet een duidelijk onderscheid kennen tussen de verschillende gebruikers. Het account van de kandidaat zal na aanmaken gevalideerd moeten worden. Het account van de secretaris wordt direct in de database gezet. Het account van de vakdidacticus moet na aanmaken gevalideerd worden door de secretaris van de opgegeven toelatingscommissie.
4.2.4
Onderhoudbaarheid
1. Het gehele programma moet gedocumenteerd zijn. 2. Het programma dient opgedeeld te zijn in deelsystemen die apart vervangbaar zijn. 3. Er moet een onderhoudsdocument worden geschreven.
4.2.5
Bruikbaarheid
1. De gebruiker moet op elke pagina een hulpfunctie aan kunnen roepen. 2. De commissie moet baat hebben bij het mappen door de kandidaat. 3. De database zal moeten draaien op een server, zodat deze eenvoudig te updaten is.
14
Hoofdstuk 5
Ontwerp In dit hoofdstuk is het ontwerp van de applicatie uiteengezet. In paragraaf 5.1 wordt het klassendiagram besproken. Vervolgens zullen in paragraaf 5.2 de controllerklassen worden beschreven. Hierna worden in paragraaf 5.3 de modelklassen besproken. Vervolgens zijn in paragraaf 5.4 de viewklassen uiteengezet. Hierna wordt in paragraaf 5.5 het databaseontwerp beschreven. Tot slot worden in paragraaf 5.6 het profielscherm en de invoer van dynamische input besproken.
5.1
Klassendiagram
In deze paragraaf wordt in figuur 5.1 het klassendiagram van de controllerklassen getoond. Vervolgens worden in figuur 5.2 de modelklassen weergegeven. In de komende twee paragrafen zullen deze figuren worden besproken.
15
Figuur 5.1: Klassendiagram van de controllerklassen
16
Figuur 5.2: Klassendiagram van de modelklassen
17
5.2
Beschrijving controllerklassen
In deze paragraaf worden de controllers behandeld. Hierbij is het overzicht beperkt tot de belangrijkste functionaliteit. Voor een compleet overzicht kunt u paragraaf 2.1 van het implementatieverslag raadplegen. Voor de Admin-, Candidate-, en MemberController geldt dat deze gebruik maken van de DatabaseController om de connectie met de database te handhaven. Ook maken deze controllers gebruik van het Singleton patroon.
5.2.1
AdminController
De AdminController bevat de functies die gerelateerd zijn aan de admin. De AdminController heeft als taak de inloggegevens van de admin te controleren. Als de admin ingelogd is, dan kan een nieuw schoolvak of nieuwe toelatingscommissie worden toegevoegd. Ook kan de admin een gebruiker toegang tot de website ontzeggen. Tevens kans een admin nieuwe adminaccounts aanmaken.
5.2.2
CandidateController
De CandidateController bevat de functies die gerelateerd zijn aan de kandidaat. De CandidateController heeft als taak de inloggegevens van de kandidaat te controleren. Als de kandidaat ingelogd is, dan kan hij zijn studies, en gerelateerde toekenning voor een schoolvak, invullen. Bij het invullen van de gegevens kan de kandidaat gebruik maken van historische data, zodat de gebruiker niet alles in hoeft te vullen. Na invullen kan de kandidaat een aanvraag indienen.
5.2.3
DatabaseController
De DatabaseController bevat de functies die gerelateerd zijn aan alle gebruikers. De DatabaseController kan een verbinding aanmaken, en verbreken, met de database. Ook kan een nieuwe universiteit worden toegevoegd aan de database. In de DatabaseController zijn verschillende ophaalfuncties beschikbaar. Zo kan de gebruiker de domeinen van een schoolvak, de namen van alle vakkenpakketten die een deelstring bevatten, de namen van alle steden, de namen van alle opleidingsniveau’s, en de namen van alle universiteiten ophalen. Tevens kan de gebruiker met behulp van de DatabaseController een wachtwoord wat hij vergeten is wijzigen.
5.2.4
MemberController
De MemberController bevat de functies die gerelateerd zijn aan een lid van een toelatingscommissie. Met behulp van de MemberController kan een nieuw ledenaccount worden aangemaakt. Ook kunnen de inloggegevens van een lid worden gecontroleerd, en kan na worden gegaan of een gebruiker lid is van een commissie. Tevens kunnen de persoonlijke gegevens worden opgehaald.
5.2.5
Page
Page wordt door elke View gebruikt voor het genereren van de webpagina. Met behulp van Page kunnen de header en footer voor een HTML-pagina worden aangemaakt, en eventueel een menu voor de admin of kandidaat. Ook is het mogelijk een datuminput, numerieke-input, selector, tabel, of mailinput te cre¨eren. Tevens kan met Page een (generieke) login worden aangemaakt.
18
5.3
Beschrijving modelklassen
In deze paragraaf worden de modelklassen behandeld.
5.3.1
Actor
De Actor klasse symboliseert een gegeneraliseerde gebruiker met een uniek identificatienummer, voornaam, achternaam, login, en mailadres. Ook is een extra boolean variabele meegegeven om aan te geven of een actor-object afwijkt van de database.
5.3.2
Candidate
De Candidate klasse symboliseert een kandidaat in de database met een uniek identificatienummer, verzameling van studies, EVC, aanvragen, en de attributen van actor.
5.3.3
Committee
De Committee klasse symboliseert een comit´e in de database met een uniek identificatienummer, schoolvak, stad, leden, universiteit en uniek identificatienummer van de universiteit.
5.3.4
Course
De Course klasse symboliseert een vak in de database met een uniek identificatienummer, naam, studiepunten, mappingen, en uniek identificatienummer van de universiteit.
5.3.5
CoursesCollection
De CoursesCollection klasse symboliseert een vakkenpakket in de database met een stad, collectie van vakken, collectie van gespecialiseerde vakken, prioriteit, opleidingsniveau, universiteit en jaar.
5.3.6
Mapping
De Mapping klasse symboliseert een toekenning van een vak aan een kern- of subdomein in de database met een uniek identificatienummer van het comit´e, de domeinnaam, en de mogelijkheid om aan te geven dat de mapping gevalideerd is door de opgegeven commissie.
5.3.7
Member
De Member klasse symboliseert een lid van een toelatingscommissie in de database met een uniek identificatienummer, baan, en lijst van commissies waar de gebruiker lid van is.
5.3.8
Request
De Request klasse symboliseert een aanvraag van een kandidaat in de database met een uniek identificatienummer, schoolvak, identificatienummer van een kandidaat, stad, universiteit, en voortgang. De stad en universiteit zijn van de toelatingscommissie die het advies behandelt.
19
5.4
Beschrijving viewklassen
In deze paragraaf worden de verschillende view-klassen, de webpagina’s, besproken. Hierbij worden de websites van de leden van de toelatingscommissie niet besproken, omdat deze niet tijdens het bachelorproject zullen worden ge¨ımplementeerd.
5.4.1
Websites van admin
Deze paragraaf beschrijft de view-klassen van de admin. Website
Functie
addAdmin addArea addCommittee addHistoricalCandidate
Website voor het voegen van een admin aan de database. Website voor het toevoegen van een schoolvak aan de database. Website voor het toevoegen van een comit´e aan de database. Website voor het toevoegen van de basisgegevens van een historische kandidaat aan de database. Website voor het toevoegen van de mapping van een historische kandidaat aan de database. Website voor het toevoegen van de studies van een historische kandidaat aan de database. Website voor het toevoegen van een universiteit aan de database. Website die het menu van de admin toont met alle adminfuncties. Website voor het bannen en unbannen van een gebruiker. Website voor het veranderen van de voorkeur voor sub- of kerndomeinen van een schoolvak. Website voor het inloggen van de admin. Website voor het bekijken van alle gegevens van een kandidaat. Website voor het bekijken van de globale gegevens en een groep kandidaten.
addHistoricalMapping addHistoricalStudy addUniversity adminMenu banCandidate editPreferenceID index viewCandidate viewCandidates
5.4.2
Websites van kandidaat
Deze paragraaf beschrijft de view-klassen van de kandidaat. Website
Functie
addCourses addGradeList addMappingCourses addRequest addStudy createAccount editCandidate index profile
Website voor het toevoegen van de vakken van een studie. Website voor het toevoegen van de cijferlijst. Website voor het toevoegen van vakken aan de domeinen. Website voor het aanvragen van een advies. Website voor het toevoegen van een studie. Website voor het aanmaken van een account. Website voor het aanpassen van basisgegevens van een kandidaat. Website voor het inloggen van een kandidaat Website die overzicht toont van de ingevulde gegevens, en verwerking van de gegevens, van een kandidaat. Website voor het bekijken van een vakkenpakket. Website voor het bekijken van de mappingen van een vakkenpakket.
viewCourses viewMappings
20
5.5
Databaseontwerp
In dit hoofdstuk wordt het databaseontwerp behandeld. In figuur 5.3 is het databasediagram weergegeven. Vervolgens worden in paragraaf 5.5.1 de verschillende tabellen besproken. Voor een compleet overzicht kun u hoofdstuk 5 van het implementatieverslag raadplegen.
Figuur 5.3: Klassendiagram van de controllerklassen
21
5.5.1
Databasetabellen
In deze paragraaf wordt voor elke tabel kortweg de functionaliteit weergegeven. Website
Functie
Actor Admin Area Authorization lookup Candidate Committee Committee members Course Courses Courses collection Domain Domain content Follow up courses Mapping Member Progress Request Specialization Studylevel University
Bevat de informatie die alle gebruikers gemeen hebben. Wordt gebruikt om aan te geven dat een gebruiker admin is. Wordt gebruikt om een schoolvak op te slaan. Wordt gebruikt om de verschillende mogelijke banen van een lid op te slaan. Wordt gebruikt om de basisgegevens van een kandidaat op te slaan. Wordt gebruikt om de gegevens van een toelatingscommissie op te slaan. Wordt gebruikt om het lidmaatschap van een lid aan een comit´e te registreren. Wordt gebruikt om een vak op te slaan. Wordt gebruikt om het verplichte vakkenpakket van een studie op te slaan. Wordt gebruikt om een studie op te slaan. Wordt gebruikt om een kern- of subdomein op te slaan. Wordt gebruikt om aan te geven wat de kern-/subdomein relaties zijn. Wordt gebruikt om de geadviseerde vakken op te slaan. Wordt gebruikt om een toekenning van een vak aan een domein op te slaan. Wordt gebruikt om de basisgegevens van een lid op te slaan. Wordt gebruikt om de verwerking van een aanvraag op te slaan. Wordt gebruikt om de aanvraag van een advies te symboliseren. Wordt gebruikt om het gespecialiseerde gedeelte van een studie op te slaan. Wordt gebruikt om het opleidingsniveau van de studie te symboliseren. Wordt gebruikt om een universiteit te symboliseren.
22
5.6
GUI
In dit hoofdstuk wordt de GUI van de applicatie besproken. Ten eerste zullen in paragraaf 5.6.1 de ontwerpkeuzes worden behandeld. Vervolgens wordt in paragraaf 5.6.2 het profielscherm van de applicatie getoond. Tot slot wordt in paragraaf 5.6.3 het dynamisch invoegen van HTML behandeld. Voor een uitgebreide bespreking van de GUI kunt u hoofdstuk 4 van het implementatieverslag raadplegen.
5.6.1
Ontwerpkeuzes
In deze paragraaf worden de belangrijkste ontwerpkeuzes van de GUI besproken. Een van de belangrijkste keuzes is dat de gebruiker ten alle tijde terug moet kunnen naar een vorige stap. Bij het nemen van een stap in de applicatie, moet de gebruiker bij belangrijke beslissingen om bevestiging worden aangevraagd. Ook moet het programma sequentieel doorloopbaar zijn. Op elke pagina die de gebruiker bezoekt, moet de gebruiker een uitleg krijgen, en moet aan elk element een tooltip toegekend zijn. Mocht een gebruiker toch iets verkeerd invoeren, dan moet een duidelijke foutmelding getoond worden uitleg hoe het probleem kan worden verholpen. Tot slot moet de functionaliteit van de website op elke moderne browser volledig bruikbaar zijn. De definitie van modern is terug te vinden in paragraaf 3.2 van het ontwerpverslag.
5.6.2
Profielscherm
In deze paragraaf wordt de profielpagina van de kandidaat weergegeven. In figuur 5.6.2 is de profielpagina weergegeven, waar vanuit de kandidaat een advies aanvragen. De gegevens die de kandidaat heeft ingevuld staan overzichtelijk op de profielpagina weergegeven. Boven het menu is het clickpath weergegeven, de lijst van websites die de kandidaat bezocht heeft. Als de kandidaat “studie toevoegen” selecteert, dan kan de gebruiker via het clickpath terug, of door alle gegevens in te vullen.
Figuur 5.4: Profielpagina van de kandidaat. 23
5.6.3
Dynamisch toevoegen van HTML
In deze paragraaf wordt het dynamisch toevoegen van webelementen besproken. Op sommige pagina’s is het niet bekend hoeveel invoervelden van tevoren nodig zijn. In een ideaal geval zou het mogelijk moeten zijn om een standaard aantal velden te hebben, en vervolgens met behulp van een knop meerdere velden toe te kunnen voegen. De eerste oplossing die werd gekozen om dit te bereiken, was om gebruik te maken van de innerHTML functionaliteit van Javascript. Hiermee wordt als het ware op een opgegeven plek nieuwe HTML-code aan de pagina toegevoegd. Echter, alleen Internet Explorer bleek deze functionaliteit te ondersteunen zonder het herladen van de pagina. In de andere browsers raakte de gebruiker de data die al ingevuld was in het formulier kwijt. Document Object Model (DOM) is als tweede oplossing gekozen. DOM is een cross-platform en taalonafhankelijke conventie voor het omgaan met onder andere HTML documenten. Een voorbeeld van een DOM-object is een tekstvak. Bij het toevoegen en verwijderen van DOMobjecten met behulp van Javascript hoeft de pagina niet herladen te worden. Het resultaat is een dynamische formulier zoals weergegeven in figuur 5.6.3.
Figuur 5.5: Dynamisch toevoegen van vakken.
24
Hoofdstuk 6
Implementatiebeschrijving In dit hoofdstuk wordt een samengevatte beschrijving gegeven van de implementatie. Voor een uitgebreide implementatiebeschrijving kunt u hoofdstuk 3 van het implementatieverslag raadplegen. In paragraaf 6.1 worden de deelsystemen van de applicatie uiteengezet. Vervolgens wordt in paragraaf 6.2 de status van het project besproken. Tot slot wordt in paragraaf 6.3 een overzicht gegeven van wat er nog moet gebeuren.
6.1
Deelsystemen
In deze paragraaf worden de deelsystemen van de applicatie besproken. Globaal gezien bestaat de applicatie uit vier deelsystemen: 1. Database. Systeem dat wordt gebruikt voor het opslaan van de gegevens. 2. Model. Klassen die gebruikt worden om de gegevens uit de database weer te geven. 3. Controller. Klassen die gebruikt worden om de opdrachten van de gebruiker uit te voeren. 4. View. Websites waarmee de gebruiker zijn opdrachten opstelt.
6.1.1
Database
Voor de database is een databasemodel opgesteld, gebaseerd op het aanvraagproces zoals beschreven in het PvE in het ontwerpverslag. Dit model is gecontroleerd door de begeleider, waarna enkele wijzigingen zijn toegebracht. Uiteindelijk zijn er geen grote problemen opgetreden bij de implementatie. Het databasemodel maakt gebruik van foreign key/primary key-relaties. Deze zijn niet met de standaard MySQL database-engine MyISAM te implementeren. Zoals beschreven in paragraaf 2.2 is voor de database-engine InnoDB gekozen.
6.1.2
Model
De modelklassen zijn opgesteld als structuur om de gegevens uit de database op te slaan. Deze klassen worden actief gebruikt door de controllers. Gezien hun belangrijke rol zijn deze klassen opgesteld met behulp van pair-programming. De commissiekant zal na het bachelorproject worden ge¨ımplementeerd. Momenteel is hier bij de implementatie als deels rekening mee gehouden, doordat de modelklassen al zijn opgesteld. 25
Hierdoor worden geen problemen verwacht bij het implementeren van de commissiekant, die zouden kunnen ontstaan door de opsplitsing. Gezien de centrale rol van de modelklassen in de applicatie zijn deze getest met het PHP testframework SimpleTest. Voor elke modelklas is een aparte php-file opgesteld met de unit tests. De tests zijn met behulp van de webserver uit te voeren, en zijn aan te roepen via http://dev.schuslerproductions.nl/src/test/. Een uitgebreide beschrijving van de verschillende testmethodes is gegeven in hoofdstuk 6 van het implementatieverslag.
6.1.3
Controller
De controllerklassen zijn net als de modelklassen opgesteld met pair-programming. Bij het implementeren van de klasse is veelvuldig gebruik gemaakt van het Singleton patroon. Initieel was er ´e´en controllerklasse, de databasecontroller. Later is deze opgesplitst in de volgende vier controllers: 1. AdminController. Bevat de functies gerelateerd aan de admin. 2. CandidateController. Bevat de functies gerelateerd aan de kandidaat. 3. DatabaseController. Bevat de functies gerelateerd aan alle gebruikers. 4. MemberController. Bevat de functies gerelateerd aan de commissies. De DatabaseController beheert de connectie met de database. De AdminController, CandidateController, en MemberController maken gebruik van de DatabaseController om de SQL-queries te versturen. Om de controllerklassen te testen zijn automatische tests teveel werk, omdat hiervoor vele extra bewerk- en verwijdermethodes moeten worden ge¨ımplementeerd. Als oplossing is gekozen om manuele tests te gebruiken. Een overzicht van de verschillende tests is weergegeven in hoofdstuk 6 van het implementatieverslag.
6.1.4
View
De viewklassen zijn de websites waarvan uit de gebruiker opdrachten kan geven aan het systeem. Er zijn drie groepen van viewklassen: 1. Adminwebsites. De admin is een expertgebruiker die grote bewerkingen aan het programma kan uitvoeren, zoals het toevoegen van een nieuwe commissie of schoolvak. Gezien de admin een expertgebruiker is, is de invoer van de admin krachtiger, maar ook complexer. Zo moeten de vakken van een historisch gegeven bijvoorbeeld in een speciaal formaat worden ingevuld, wat sneller is dan apart met knoppen vakken toevoegen, zoals de kandidaat het moet doen. 2. Commissiewebsites. Momenteel zijn er nog geen websites voor de toelatingscommissies toegevoegd. Een idee van het uiterlijk van de websites kan verkregen worden door de slides van de presentatie van 17 juni te raadplegen in de bijlage. 3. Kandidaatwebsites. De kandidaat is een beginner die niet bekend is met de applicatie. Hij zal op de websites zoveel mogelijk ondersteund worden met zijn bewerkingen. Gezien de kandidaat veel gegevens in moet vullen, zijn er zoekmethodes ingezet die de gebruiker kan gebruiken om zijn invoer te beperken door gebruik te maken van historische gegevens. Aan elk element is een uitleg toegevoegd om de kandidaat te assisteren. 26
6.2
Status
In deze paragraaf wordt de status van de ontwikkeling van de applicatie besproken. In figuur 6.1 is de globale status van het project weergegeven. Het commissiegedeelte en “testen en installeren” zullen in paragraaf 6.3 worden behandeld. Voor een gedetailleerd overzicht kunt u hoofdstuk 3 in het implementatieverslag raadplegen, of de bijlage voor de slides van de bijeenkomst met de toelatingscommissies.
Figuur 6.1: Weergave van status van de ontwikkeling van de applicatie
6.2.1
Vaststellen doel applicatie
Het vaststellen van het doel van de applicatie is volledig voltooid. Hiervoor is contact opgenomen met de verschillende toelatingscommissies. Initieel was de opdracht het opstellen van expertsysteem voor het automatisch genereren van adviezen. Aan de hand van de verschillende versies van het design document bleek dit echter niet haalbaar, en is gekozen voor een hulpsysteem. Hiervoor is een paar maanden het proces van de verschillende toelatingscommissies geanalyseerd, en is een nieuw model voor het proces voorgesteld en goedgekeurd.
6.2.2
Opstellen Programma van Eisen
Het vaststellen van het programma van eisen is net als het vaststellen van het doel van de applicatie een iteratief proces geweest. Uiteindelijk is een ontwerp gemaakt voor een applicatie met een expertsysteem, en twee ontwerpen voor een hulpsysteem. Deze documenten bouwden op elkaar door, en maakten het mogelijk om een steeds beter beeld te krijgen van de eisen aan de applicatie.
6.2.3
Admingedeelte
Het admingedeelte van de applicatie is volledig ge¨ımplementeerd. De rede dat er echter 90% staat, is omdat er nog geen gebruikerstest heeft plaatsgevonden.
6.2.4
Kandidaatgedeelte
Het kandidaatgedeelte van de applicatie is volledig ge¨ımplementeerd. De rede dat er echter 90% staat, is omdat er nog geen gebruikerstest heeft plaatsgevonden.
27
6.3
Future work
In deze paragraaf worden de gedeeltes van de applicatie besproken die na het bachelorproject zullen plaatsvinden.
6.3.1
Commissiegedeelte
In het design document is het commissiegedeelte al volledig ontworpen. Wat betreft de implementatie ervan zijn echter slechts de modelklassen, en enkele functies in de MemberController ge¨ımplementeerd. De komende maanden zal de commissiefunctionaliteit worden ge¨ımplementeerd. Voor een schets van de uiteindelijke weergave kunt u in de bijlage de presentatie van 17 juni raadplegen. Ondanks dat het commissiegedeelte nog niet af is, is het al mogelijk om de applicatie te gebruiken. Zo kan de kandidaat zijn gegevens al invullen, en is het mogelijk om via de adminfunctionaliteit een overzicht te krijgen van de ingevulde data. Op basis hiervan kan de toelatingscommissie een advies opstellen, en deze versturen naar de kandidaat. Momenteel zal de applicatie echter nog niet gebruikt gaan worden, omdat er nog geen gebruikerstests hebben plaatsgevonden. In augustus wordt verwacht dat de applicatie gest kan worden met gebruikers.
6.3.2
Testen en installeren
In de vergadering met de toelatingscommissies op 17 juni is bepaald dat de gebruikerstests waarschijnlijk in augustus/september plaats zullen vinden. Wat betreft de installatie van de applicatie is momenteel nog niet veel bekend. Bij de vergadering van 17 juni is hiernaar gevraagd, maar een eenduidig antwoord kon niet worden gegeven. Zoals beschreven in het onderzoeksverslag zal een SSL-certificaat benodigd zijn. Uit dit onderzoek blijkt ook dat de server het best bij een onderwijsinstelling kan draaien die aangesloten is bij Surf, omdat het dan mogelijk is om gratis een SSL-certificaat aan te vragen. Ook zal uitgebreide toegang tot het PHP configuratiebestand benodigd zijn. Deze toegang is nodig om te website af te schermen, zodat bepaalde pagina’s niet direct toegankelijk zijn. Ook kan hiermee geforceerd worden dat er gebruik wordt gemaakt van een beveiligde SSL-verbinding, en kan de voorkeur van het karakterset op UTF-8 worden ingesteld. Hiermee wordt voorkomen dat speciale karakters zoals ‘¨ a’ onjuist worden weergegeven.
28
Hoofdstuk 7
Procesbeschrijving In dit hoofdstuk wordt het bachelorproject ge¨evalueerd. In paragraaf 7.1 wordt de begeleiding en feedback besproken. Vervolgens wordt in paragraaf 7.2 de conclusie behandeld. Tot slot wordt in in paragraaf 7.3 een persoonlijke evaluatie van het project gegeven.
7.1
Begeleiding en feedback
In deze paragraaf wordt de begeleiding tijdens het bachelorproject behandeld. Er is door vier groepen begeleiding gegeven: de opdrachtgever dhr. M. Jacobs, de bachelorco¨ordinator dhr. P. van Nieuwenhuizen, de toelatingscommissies, en begeleider dhr. A. de Bruin.
7.1.1
Opdrachtgever
Begin januari is voor het eerst contact opgenomen met de opdrachtgever, waarna vervolgens eind januari is begonnen met het bachelorproject, met als doel tien uur per week te werken. Bijna elke week in deze periode was er contact met de opdrachtgever. Vooral in de maanden januari t/m maart was dit contact erg belangrijk, gezien het applicatiedomein een unieke taal kent. In de offici¨ele bachelorprojectperiode is full-time gewerkt, en was er soms wel drie keer per week contact met de opdrachtgever. Door de opdrachtgever is uitgebreide inhoudelijke feedback gegeven op het eerste, tweede, en derde ontwerpverslag. Ook heeft hij een grote rol gespeeld in het opstellen van de presentatie voor de toelatingscommissies. Hij heeft een grote rol gespeeld in het opstellen van de applicatie.
7.1.2
Toelatingscommissies
Met de toelatingscommissies is meerdere malen contact opgenomen voor het opstellen van het programma van eisen. Elk van de drie ontwerpverslagen is door een review-groep van vier tot zes personen ge¨evalueerd. In het eerste verslag bleek dat het document te technisch was. Vervolgens is in het tweede verslag en derde verslag gebruik gemaakt van flowcharts. Hierna werd de feedback veel inhoudelijker. Een andere vorm van feedback vond plaats op 17 juni. Op deze datum is een presentatie gegeven van een half uur over de applicatie. Na deze presentatie is een half uur vragen beantwoord, en nog een uur gediscussieerd. Samenvattend was iedereen zeer tevreden over de applicatie, en waren velen zelfs positief verbaasd over de functionaliteit. Tijdens deze vergadering zijn de keuzes gemaakt die de verdere verloop van project bepalen. 29
7.1.3
Bachelorco¨ ordinator
Tijdens het project traden problemen op met de communicatie met de begeleider. Na paar maanden bleek dit communicatieprobleem in een niet vaak gebruikt mailadres te zitten. Dit probleem werd geconstateerd nadat in eind mei contact was opgenomen met de bachelorco¨ordinator. De bachelorco¨ ordinator heeft ons vervolgens aangeraden om de applicatie op te splitsen. Door deze opsplitsing was er voldoende tijd om de kwaliteit van het kandidaatgedeelte te verbeteren. Ook heeft hij feedback gegevens op het derde ontwerpverslag. Deze feedback is meegenomen in de uiteindelijke versie van dit ontwerpverslag.
7.1.4
Begeleider
Tijdens het bachelorproject hadden we de eerste maanden geen contact met de begeleider, omdat er gemaild naar een minder vaak gebruikt mailadres. Eind mei loste dit probleem zichzelf op, en is besloten het databasediagram te bespreken. Hierin bleken nog enkele fouten te zitten, die begin juni in de applicatie zijn gerepareerd.
7.2
Conclusie
Het afgelopen half jaar is zeer hard gewerkt aan het bachelorproject. In totaal is er veel meer tijd besteed aan het project dan er officieel voor staat, omdat niet duidelijk was hoeveel er precies gedaan moest worden. Naar schatting is er cumaltief minstens 40 EC in het project gestoken. De opsplitsing van de applicatie werd hierdoor als een verlichting ervaren. Helaas zijn we minder ver gekomen dan oorspronkelijk was gepland. De hoofdoorzaak was dat opdracht initieel geformuleerd was als een applicatie die de adviezen moest uitrekenen. Echter, later bleek dat alleen een hulpsysteem mogelijk was omdat de regels van het expertsysteem momenteel niet opstelbaar zouden zijn. Hierdoor hadden we drie ontwerpen nodig om tot een uiteindelijke versie te komen. Ook bleek het veel werk om het gehele applicatiedomein te begrijpen. Initieel hadden we alleen gefocust op Delft, maar later bleek dat de toelatingscommissies in Nederland ieder op hun eigen manier werken. Dit hadden we deels kunnen verhelpen door eerder contact op te nemen met de andere commissies. Wat betreft de implementatie traden er weinig problemen op. Voor de implementatie moesten webtalen zoals PHP, HTML, en Javascript bestudeerd worden. In het begin waren de implementaties van de functies soms niet optimaal. Echter naar mate de kennis van de webtalen toenam, zijn deze functies herschreven. Tijdens het bachelorproject hebben we een nieuwe workflow opgesteld voor het gehele toelatingsproces. Deze workflow wijkt soms veel af van de huidige workflow, en het was daarom ook vrij veel werk om deze door ieder geaccepteerd te krijgen. Uitendelijk is deze nieuwe workflow door iedereen zeer positief ontvangen. Uiteindelijk hebben we een prototype geleverd met een zeer groot draagvlak. Er werd zelfs gesproken om extra personen in te huren om de database te vullen met historische gegevens. Zelfs werd overwogen om de applicatie op den duur verplicht te maken als aanvraagsysteem voor een advies. Na het bachelorproject zal het commissiegedeelte van de applicatie worden gerealiseerd, waarna de gebruikerstests zullen plaatsvinden. De komende maanden gaan we de grote verwachtingen van deze applicatie waar maken.
30
7.3
Evaluatie
In deze paragraaf wordt een persoonlijke evaluatie gegeven van het project. In paragraaf 7.3.1 zal de evaluatie van Mark Hendrikx worden besproken. Vervolgens zal in paragraaf 7.3.2 de evaluatie van Olaf Sch¨ usler worden uiteengezet.
7.3.1
Evaluatie van Mark Hendrikx
Opdracht In januari kregen we het eerst te horen van de opdracht die nu ons bachelorproject is geworden. Initieel leek deze goed haalbaar, echter de praktijk wees anders uit. Na het eerste ontwerp te hebben opgesteld, hebben we dit ontwerp voorgelegd aan de toelatingscommissies buiten Delft. Hieruit bleek dat het opstellen van regels door de toelatingscommissies een veelvoud van de baten van de applicatie zouden zijn. Wellicht hadden we dit eerder aan kunnen zien komen als eerder contact op was genomen met de toelatingscommissies. Vervolgens is een nieuwe opdracht door ons opgesteld, en een workflow van het proces. Deze workflow is voorgelegd aan de verschillende commissies, die akkoord gingen. Vervolgens is een tweede ontwerp opgesteld. Er bleek echter een kleine winst in het kandidaatgedeelte te behalen. Daarom is het derde ontwerp opgesteld. Hierna is contact opgenomen met een aantal van de commissies. Deze waren zeer tevreden over het nieuwe ontwerp. Bij de vergadering van 17 juni is vervolgens is dit ontwerp behandeld. Bij deze vergadering was ieder zeer te spreken over ons idee. Concluderend kostte het een paar iteraties om de opdracht juist te krijgen, maar het resultaat kent een groot draagvlak. Wellicht had tijd bespaard kunnen worden als de opdracht initieel beter geformuleerd was. Begeleiding Wat betreft de begeleiding van de opdrachtgever hebben we erg veel contact gehad met dhr. M. Jacobs. Als expert in het applicatiedomein heeft zijn inbreng een grote invloed gehad op de applicatie. Vanuit de opleiding Technisch Informatica is begeleiding gegeven door dhr. A. De Bruin die ons heeft geholpen bij de verificatie van het databasediagram. Hij deed veel moeite om het diagram volledig te begrijpen. Aan de hand van zijn feedback is de database verbeterd. De eerste maanden hadden wij geen contact met hem door een communicatiefout. Via de bachelorco¨ ordinator konden we echter de ontbrekende informatie verkrijgen. Concluderend was de begeleiding van de opdrachtgever zeer goed. Door communicatiefouten hebben we weinig begeleiding gehad vanuit de opleiding zelf, echter de feedback die werd gegeven was zeer nuttig.
31
Samenwerking Wat betreft de samenwerking tijdens dit project heb ik als streefdoel genomen om een professionele houding aan te nemen. Uiteindelijk vind ik dat ik hier redelijk in ben geslaagd. Wat mij betreft is de samenwerking op te splitsen in twee periodes: januari t/m april en mei t/m juli. Periode 1: januari t/m april In de eerste periode is vooral gewerkt aan het onderzoeken van het domein, het leren van de webtalen, en het opstellen van de ontwerpen. In deze periode heb ik een groot gedeelte van het verslag opgesteld, en heb ik de verschillende webtalen bestudeerd. Tijdens deze periode verliep de samenwerking goed. We hebben ons hard ingezet om het ontwerp tot een succesvol einde te brengen. Zo zijn de modelklassen bijvoorbeeld met pairprogramming opgesteld, en is elk verslag door beide volledig doorgelezen en gecorrigeerd. Ook zijn de kernen van de Candidate- en DatabaseController met pair-programming opgesteld. Wel had ik in deze periode wat meer tijd voor het project nodig dan mijn projectpartner, omdat zijn kennis van webtalen beter was. Mijn projectpartner heeft er bijvoorbeeld voor gezorgd dat de HTML code voldeed aan de HTML5-standaarden, en de oplossing gevonden waarom een “¨ u” een “?” werd. Gelukkig was ik snel bijgespijkerd met behulp van een paar goede boeken. Periode 2: mei t/m juli In de tweede periode is vooral gewerkt aan het opstellen van het programma. In deze periode heb ik een groot deel van de applicatie ontwikkeld, en de presentatie voor 17 juni voorbereid en gepresenteerd. Tijdens deze periode was ik teleurgesteld in de samenwerking. Mijn projectpartner hadden vanaf begin mei problemen in de persoonlijke sfeer. Het resultaat was dat er doordeweeks relatief weinig door hem werd gedaan. Dit vond ik jammer, omdat de globale kwaliteit van zijn werk uitmuntend is. Hij heeft bijvoorbeeld een groot deel van de Page-klasse ge¨ımplementeerd, wat ertoe leidde dat we de duplicatie in de websites grotendeels konden wegwerken. In deze periode heb ik geprobeerd om de voorgang te bewaken door planningen en todo-lists op te stellen. Het effect hiervan was niet zozeer een toename in arbeid, maar vooral een duidelijk beeld van wat er nog moest gebeuren. Gezien ik een professionele houding voor het project wilde behouden, heb ik de afgelopen twee maanden de gehele week gehele dagen gewerkt en vele extra taken naar me toe getrokken. Om het proces te bewaken was dit wat mij betreft noodzakelijk. Echter, misschien heb ik hierdoor mijn projectpartner niet altijd de volle kans gegeven. Uiteindelijk kwam de applicatie wel goed, maar volgens mij hadden we meer kunnen bereiken. In totaal heb ik 25 - 30 EC in het project gestoken, wat veel meer is dan er voor staat. Een grote factor hierin was vooral dat niet duidelijk was wat er voor het bachelorproject vereist werd, het vele contact met de opdrachtgever en de commissies, maar ook deels onze samenwerking. Over het gehele project gezien ben ik van mijn mening dat mijn projectpartner voldoende tijd heeft gestoken in het project, en werk levert van zeer goede kwaliteit, echter de teleurstellende samenwerking de laatste maanden kwam erop neer dat ik deze maanden een grote meerderheid van het totale werk heb verzet. Ik vind dit spijtig, gezien mijn projectpartner meer ervaring heeft met het opstellen van websites dan ik, en daardoor over het algemeen preciezer te werk gaat. Het uiterlijk van de huidige website is bijvoorbeeld door hem ontwikkeld. Als positief punt heb ik nu wel een grondige kennis wat betreft webtalen, die ik ook zeker in de toekomst ga benutten.
32
Eindresultaat Ik ben tevreden met het eindproduct, echter wel teleurgesteld dat we niet iets verder zijn gekomen. Een van de grootste oorzaken hiervan is dat het veel tijd kostte om de juiste opdracht op te stellen. Bij de presentatie van 17 juni werd de applicatie zeer tevreden ontvangen. Er werd zelfs gesproken om extra te investeren in het project. De komende maanden gaan we de applicatie afmaken, zodat we kunnen voldoen aan de hoge verwachtingen.
7.3.2
Evaluatie van Olaf Schu ¨ sler
Opdracht Toen ik voor het eerst van het project hoorde van dhr. Jacobs, zag ik het project, na¨ıef als de beginnende ingenieur is, als een eenvoudig te realiseren iets. Er zou wel veel tijd ingestoken moeten worden, maar het zou niet al te complex worden. Vol goede moed begonnen we aan ons eerste ontwerp en begonnen we de taal van het project te leren. We liepen echter al snel tegen een aantal problemen aan waar we later contact over opnamen met de partners in het land. Vrijwel direct kwamen we erachter dat het programma zoals we het ons in eerste instantie voorstelden bij de opdracht niet haalbaar zou zijn. Later misschien wel, maar met de huidige staat van regelgeving absoluut nog niet. Effectief hebben we het hele programma van eisen toen weggegooid en zijn we opnieuw begonnen. Dit voelde absoluut onplezierig omdat we er veel tijd in gestoken hadden en het voelde alsof het voor niets was. Ook over dit programma hebben we contact opgenomen met de partners en ook hier bleken nog fundamentele fouten in te zitten. Pas na een eerste periode hadden we echt door wat de opdracht precies inhield en met het voorleggen van de 3e versie van het ontwerpverslag kwam er duidelijkheid over wat het project nou inhield en wat er dus uiteindelijk van ons verwacht werd Persoonlijk vond ik dit een van de lastigste elementen van het gehele project. Je leert tijdens je opleiding dat de klant eigenlijk nooit een idee heeft van wat hij nou precies wilt, maar stiekem ga je er, zeker in het begin, toch altijd van uit dat hij dat wel weet. Ik heb bij de opdracht zeker geleerd dat je altijd door zal moeten blijven vragen naar de regels die bestaan, de data die er is en dat je niet te lang moet blijven hangen bij de dingen die je denkt te weten, maar dat je je in moet leven in de situatie zoals hij nu bij de gebruiker bestaat. Het is belangrijk om te beginnen met een assessment van het huidige scenario en door middel van paper prototyping erachter te komen waar het probleem ligt en hoe dit op te lossen. Begeleiding Bij de begeleiding heb ik persoonlijk weinig last gehad van de periode dat we weinig tot geen contact hadden met dhr. de Bruin. In die periode moest er voornamelijk veel ontworpen worden en hiervoor kregen we meer dan genoeg hulp van dhr. Jacobs. Toch heeft het ergens wel degelijk invloed gehad op ons tijdsplan, aangezien ons databasediagram pas later in het proces gecontroleerd kon worden. Daarnaast hebben we ook lange tijd gewerkt onder de aannames dat we het hele programma in 1 keer zouden afmaken, terwijl de deadline veel dichterbij bleek te liggen. Hierdoor hebben we de laatste weken harder moeten werken.
33
Samenwerking Over de samenwerking heb ik niets dan lof. Mark heeft uitstekend zijn best gedaan en ondanks dat we het nog wel eens niet eens waren over ontwerpkeuzes zijn we er altijd goed uit gekomen en denk ik dat we een goed resultaat neer hebben gezet. Ook toen ik persoonlijke problemen had, heeft Mark erg veel werk op zich genomen zodat het project geen vertraging op zou lopen, dus ik ben zeer zeker te spreken over de samenwerking. Eindresultaat Al met al denk ik dat het eindproduct er zeker mag zijn. Vanwege de eerste bumps in the road is niet het hele project afgekomen, zoals we in het begin hoopten, maar het ziet ernaar uit dat we toch een goed werkend prototype kunnen afleveren. Dit prototype voldoet in onze ogen zeker aan de gestelde eisen voor dit project, dus over het algemeen ben ik tevreden over de manier waarop we het project doorlopen hebben en over het eindproduct zoals we dat zullen afleveren.
34
Bijlage A
Design Document
35
Voorwoord Dit document is tot stand gekomen als requirements document voor werkpakket 4a van het “Alle H@nds Aan Dek” project in opdracht van de Universitaire Leraren Opleidingen. In dit rapport vindt u een overzicht van de requirements van ons product. De requirements zijn opgesteld aan de hand van de verschillende gesprekken die we hebben gehad met de partners. Na elke serie van gesprekken is een nieuw document opgesteld om aan de nieuwe, duidelijkere eisen te voldoen. Dit document betreft de derde versie, en zal de leidraad vormen bij de implementatie van het programma. Wij danken de partners van het project voor hun tijd en feedback. Mark Hendrikx Olaf Sch¨ usler
36
Inleiding Om in de bovenbouw van de middelbare school les te geven, moet je beschikken over een eerstegraads bevoegdheid. Die behaal je door de universitaire lerarenopleiding te volgen. Om tot de lerarenopleiding toegelaten te worden, neem je contact op met een toelatingscommissie van de ULO (Universitaire Leraren Opleiding). Deze vraagt vervolgens welke opleidingen je hebt afgesloten, en welke werkervaring je bezit. Deze gegevens, en andere, worden gebruikt om een advies te genereren over de te volgen vakken om toegang te verkrijgen tot een ULO. Het is in het belang van kandidaten dat iedere toelatingscommissie eenzelfde advies geeft aan kandidaten met eenzelfde vooropleiding. Als hoofddoel van het eerste ontwerp werd daarom gesteld om een adviesprogramma op te stellen dat een advies genereert op basis van de historische gegevens en de regels in de VSNU-gids. Dit bleek echter niet haalbaar te zijn, omdat de regels niet exact genoeg waren te bepalen. Naar aanleiding van deze constatering is besloten om de insteek te veranderen naar een programma wat het proces deels automatiseert en assistentie verleent bij de verschillende keuzes. Hierbij dienen de volgende doelstellingen te worden behaald: 1. Eenzelfde advies te geven bij eenzelfde vooropleiding. Hierdoor moet het proces voor de kandidaat transparanter worden. De autonomie van de plaatselijke toelatingscommissie mag echter niet in gevaar komen. 2. Het werk van de toelatingscommissie moet verminderd worden, door de kandidaten het toekennen van de vakken aan de sub- of kerndomeinen deels uit te laten voeren. 3. De adviezen die landelijk worden gegeven, moeten voor iedere toelatingscommissie toegankelijk zijn. Hierdoor wordt het opstellen van een advies eenvoudiger. Allereerst zal de actorenanalyse worden behandeld in hoofdstuk 1. Deze zal gevolgd worden door het programma van eisen in hoofdstuk 2. Vervolgens zullen de kwaliteitseisen worden behandeld in hoofdstuk 3. Hierna zullen in hoofdstuk 4 de use cases worden behandeld. Tot slot zal in bijlage A de planning worden behandeld, en in bijlage B de definities van de verschillende termen.
37
Hoofdstuk 1
Actorenanalyse In dit hoofdstuk zal een analyse worden gegeven van de actoren die gebruik maken van het programma. Het betreft hier twee groepen: . Leden van toelatingscommissie, zijn de personen die het advies opstellen voor de kandidaten. Als een kandidaat de vakdeffici¨enties van het gegeven advies heeft weggewerkt, dan heeft deze toegang tot de Universitaire Leraren Opleiding. . Kandidaten, zijn de personen die een advies willen wat betreft hun vakdeffici¨enties. Hun uiteindelijke doel is toegang te krijgen tot de Universitaire Leraren Opleiding.
1.1
Toelatingscommissie
Het doel van de toelatingscommissie zal worden beschreven in paragraaf 1.1.1. Vervolgens zullen de problemen die optreden bij het bereiken van het doel worden beschreven in paragraaf 1.1.2. Ten slotte zullen de oplossingen voor de problemen uiteen worden gezet in paragraaf 1.1.3.
1.1.1
Doel
Een toelatingscommissie voor een schoolvak heeft als doel een advies uit te brengen aan een kandidaat wat betreft de te volgen vakken voor het wegwerken van zijn vakdefici¨enties. Als deze vakdefici¨enties weggewerkt zijn, dan heeft de kandidaat toegang tot de eerstegraads docentenopleiding. Globaal gezien gaat het opstellen van een advies als volgt: 1. De kandidaat neemt contact op met een toelatingscommissie van een schoolvak waarin deze een eerstegraads bevoegdheid wil. In sommige gevallen zal een kandidaat meerdere toelatingscommissies van een schoolvak benaderen met als doel het advies te kiezen dat het minst tijd kost. 2. Een lid van de toelatingscommissie, vaak de secretaris, ontvangt het verzoek van de kandidaat. Als de opleidingsgegevens, cijferlijst, en/of werkervaring niet zijn meegestuurd, dan wordt alsnog een bericht gestuurd naar de kandidaat om deze gegevens op te vragen. Echter, als de kandidaat slechts een indicatie wil van zijn vakdefici¨enties, dan zijn de extra gegevens wellicht niet benodigd. 3. De secretaris stuurt het werk door naar een vakdidacticus van het gewenste schoolvak. Het kan namelijk voorkomen dat een toelatingscommissie meerdere vakken adviseert. 38
4. Als de gegevens aangeleverd zijn, stelt een toelatingscommissie een advies op. Dit houdt in dat met behulp van de VSNU-gids voor het gewenste schoolvak wordt bekeken op welke kern- of subdomeinen de kandidaat vakdefici¨enties bezit. Deze taak wordt vaak gedaan door een vakdidacticus. Vervolgens wordt bepaald welke vakken een kandidaat nog moet volgen om deze vakdefici¨entie weg te werken. 5. Bij sommige toelatingscommissies zal nog een vergadering volgen waarin het advies wordt besproken, en eventueel aangepast. Uiteindelijk wordt het advies goedgekeurd, en wordt deze opgestuurd naar de kandidaat. Bij toelatingscommissies waarbij geen vergadering wordt gehouden, stuurt een lid van de toelatingscommissie, vaak de vakdidacticus, direct het advies naar de kandidaat.
1.1.2
Probleem
De toelatingscommissies hebben verschillende problemen. De volgende problemen zijn ge¨ıdentificeerd: 1. Shoppers, kandidaten die een advies proberen te krijgen bij meerdere toelatingscommissies, leiden tot verschillende problemen: (a) Doordat adviezen onderling niet gedeeld wordt, wordt voor een shopper meerdere malen een advies opgesteld. Dit leidt tot dubbel werk. (b) Als een kandidaat shopt, dan krijgt hij vaak per commissie een uniek advies. Deze adviezen kunnen in de praktijk soms veel verschillen wat betreft studielast. 2. Het toekennen van adviezen is een arbeidsintensief proces. Momenteel leidt dit soms tot een lange wachttijd. 3. De vakken die uiteindelijk worden geadviseerd door een toelatingscommissie, zijn vaak beperkt tot de eigen universitei,t en universiteiten in de omgeving. Dit leidt vaak niet tot de kortste periode om de defici¨enties weg te werken.
1.1.3
Oplossing
De problemen in paragraaf 1.1.2 zullen als volgt worden opgelost: 1. Het probleem met de shoppers zal worden tegengaan door een database op te zetten waarin historische gegevens worden bewaard, en uitgewisseld. Bij het opstellen van een nieuw advies, worden vergelijkbare historische gegevens getoond die als referentiekader kunnen dienen. Dit heeft als voordeel dat er geen dubbel werk wordt verricht, omdat slechts ´e´en toelatingscommissie het advies hoeft op te stellen. Een volgende toelatingscommissie kan gebruik maken van het gegeven advies als referentiekader, of deze zelfs direct doorsturen. Een bijkomend voordeel is men door inzicht in elkaars werk, richtlijnen op kan stellen zodat toekomstige adviezen minder verschillen. 2. Het probleem wat betreft de grote werklast voor een toelatingscommissie, en de soms lange wachttijd, zal worden aangepakt door de kandidaat deels het werk te laten doen. Het mappen van de vakken van de kandidaat op de kern- of subdomeinen van het schoolvak kost momenteel veel tijd. Door de kandidaat deze stap te laten uitvoeren, en vervolgens deze mapping te controleren, hoeft de toelatingscommissie minder werk te doen. Een bijkomend voordeel is dat de gegevens direct zijn gedigitaliseerd, dus gebruikt kunnen worden als referentiekader bij toekomstige adviezen.
39
Tevens zal de kandidaat direct na het ingeven van zijn vooropleiding(en), dus voor het invullen en mappen van zijn vakken, een indicatie krijgen van zijn studielast op basis van historische gegevens. Hierdoor kan de kandidaat al vroegtijdig beslissen om toch geen advies op te vragen, omdat de studielast wellicht te groot is. Doordat het geven van indicaties aan kandidaten wordt uitgevoerd door het systeem, wordt de toelatingscommissie ook werk bespaard. 3. Het probleem wat betreft het adviseren van vakken in de eigen omgeving, die leiden tot een suboptimaal rooster voor de kandidaat, zal gedeeltelijk in deze applicatie worden aangepakt. De geplande E-learning-trajecten in werkpakket 4 van het AHAD-project zullen vooral de oplossing voor dit probleem bieden. De applicatie kan door het tonen van vergelijkbare historische adviezen er echter wel voor zorgen dat een toelatingscommissie meer inzicht krijgt welke vergelijkbare vakken er bij andere universiteiten zijn voor het wegwerken van een vakdefici¨entie.
1.2
Kandidaten
Het doel van de kandidaat zal worden beschreven in paragraaf 1.2.1. Vervolgens zullen de problemen die optreden bij het bereiken van het doel worden beschreven in paragraaf 1.2.2. Ten slotte zullen de oplossingen voor de problemen uiteen worden gezet in paragraaf 1.2.3.
1.2.1
Doel
De kandidaat wil een advies ontvangen wat betreft de te volgen vakken voor het wegwerken van zijn vakdefici¨enties. Voor het verkrijgen van dit advies zal hij naar een toelatingscommissie gaan op de locatie waar hij waarschijnlijk zijn vakdefici¨enties wil wegwerken. Het doel van de kandidaat is de gegevens aan te leveren voor het opstellen van een advies.
1.2.2
Probleem
De kandidaten hebben verschillende problemen. De volgende problemen zijn ge¨ıdentificeerd: 1. De kandidaat wil toegang tot de ULO, maar moet eerst zijn vakdefici¨enties wegwerken. Hiervoor moet hij een overzicht krijgen wat zijn vakdefici¨enties zijn. 2. De kandidaat wil zo min mogelijk tijd besteden aan het wegwerken van de vakdefici¨enties. Hierbij betreft de definitie van tijd het aantal studiepunten, maar ook de duur voor het volgen van een rooster.
1.2.3
Oplossing
De problemen in paragraaf 1.2.2 zullen als volgt worden opgelost: 1. Voor het opvragen van het advies, zal de kandidaat contact op moeten nemen met een toelatingscommissie. Dit kan deze bereiken door naar de website te gaan van het adviesprogramma. Vervolgens dient de kandidaat zijn gegevens in te voeren en zijn voorkeur voor een locatie aan te geven. Om de wachttijd voor een advies te verminderen, worden alle gegevens door de kandidaat zelf ingevuld en wordt een voorlopige mapping van de vakken op de kern- of subdomeinen
40
door de kandidaat gemaakt. Dit gebeurt aan de hand van een omschrijving van de kernof subdomeinen. Vervolgens zal de mapping worden gecontroleerd door de toelatingscommissie, en eventueel verbeterd. Op basis van deze mapping zullen vakken bij de vakdefici¨enties worden gezocht. Het volledige advies zal naar de kandidaat worden opgestuurd. 2. Om de tijd die een kandidaat moet besteden aan het wegwerken van zijn vakdefici¨enties te beperken, zullen E-learning-trajecten worden opgezet. Het programma houdt hier rekening mee.
41
Hoofdstuk 2
Programma van Eisen In dit hoofdstuk worden de eisen weergegeven waar het systeem aan dient te voldoen. De eisen zijn onderverdeeld in verschillende categorie¨en om het geheel overzichtelijk te maken. In tabel 2.1 staan de verschillende categorie¨en beschreven. Deze categorie¨en zijn weer onderverdeeld in subcategorie¨en, zoals “kandidaat” en “toelatingscommissie”. In bijlage B zijn de definities van de gebruikte termen te raadplegen. Het belangrijkste verschil met de werkelijke situatie, is dat als in dit document wordt geschreven over een toelatingscommissie, dan betreft dit slechts ´e´en vak. In het werkelijke geval dat een toelatingscommissie bijvoorbeeld drie vakken tot zijn rekening neemt, wordt hier gesproken over drie toelatingscommissies. Tabel 2.1: Uitleg van inhoud van elke categorie in PVE Categorie
Uitleg
Invoer
Beschrijft de gegevens die de gebruiker dient in te voeren zodat de applicatie het doel van de gebruiker kan bereiken. Beschrijft de feedback en verwerking die de applicatie geeft aan de hand van de ingevoerde data. Feedback betreft de informatie die het systeem teruggeeft. Verwerking betreft het gebruik van de input door de applicatie om het doel van de gebruiker te bereiken. Beschrijft de verschillende typen accounts die er bestaan in de applicatie, en de rechten die hieraan verbonden zijn. Beschrijft de eigenschappen die de applicatie altijd moet bezitten op gedefinieerde, recente internetbrowsers. Tevens wordt het gehele proces, zie figuur 2.1 en figuur 2.2, beschreven zoals deze in de werkelijkheid wordt doorlopen door een kandidaat, respectievelijk lid van toelatingscommissie.
Feedback en verwerking
Accounts Website-eigenschappen
42
Figuur 2.1: Overzicht van kandidaatgedeelte van programmamodel. Grijs duidt gebruik van historische gegevens aan.
43
Figuur 2.2: Overzicht van het commissiegedeelte van het programmamodel. Grijs duidt gebruik van historische gegevens aan.
2.1
Invoer
Deze paragraaf beschrijft de gegevens die de gebruiker moet invoeren zodat de applicatie het doel van de gebruiker kan bereiken. De eerste deelparagraaf beschrijft de invoer van de kandidaat. De tweede paragraaf specificeert de invoer van de toelatingscommissie.
2.1.1
Kandidaat
1. De kandidaat kan inloggen met een bestaand account, door het mailadres en paswoord in te voeren waarmee hij het account heeft aangemaakt. Slechts met een account kan een advies worden aangevraagd. Deze beschrijving betreft stap 2 in figuur 2.1. 2. De kandidaat moet een account aan kunnen maken door zijn naam, mailadres, en gewenst paswoord in te vullen. Het paswoord moet tweemaal ingevoerd worden om typefouten te voorkomen. Ook moet een Captcha worden uitgevoerd. Dit is een kleine test om te voorkomen dat een computerprogramma gebruikt kan worden om accounts te genereren. Het mailadres van de kandidaat moet uniek zijn in de database. Deze beschrijving betreft stap 5 in figuur 2.1. 3. De kandidaat moet de mogelijkheid hebben om een vorige sessie te hervatten. Dit houdt in dat bestaande gegevens uit de database worden opgehaald. Opslag van gegevens vindt plaats in stap 10 tot en met 14 in figuur 2.1. Na hervatten kan de gebruiker verder gaan waar hij is gebleven. Deze beschrijving betreft stap 3 in figuur 2.1.
44
4. De kandidaat moet de volgende gegevens in kunnen voeren om een indicatie te krijgen van de studielast om de vakdefici¨enties weg te werken. Hierbij wordt de kandidaat aangeraden de toelatingscommissie in te vullen die hoort bij de universiteit waar de kandidaat zijn vakdefici¨enties wil wegwerken. Deze toelatingscommissie heeft namelijk het beste beeld van de te volgen vakken in de omgeving. Deze beschrijving betreft stap 7 in figuur 2.1. . Schoolvak . Naam bacheloropleiding(en) . Naam minor(s) . Naam master(s) . Scan cijferlijst(en) . Data behalen diploma(’s) . Naam van belangrijkste opleiding (voor indicatie) . Toelatingscommissie 5. De kandidaat kan bij het uploaden van de cijferlijst(en) slechts ´e´en bestand uploaden. Als hij meerdere cijferlijsten heeft, dan zal hij er dus een pdf-bestand van moeten maken, of het geheel opslaan in een zip-bestand. Momenteel wordt bekeken of het wat betreft rekenkracht mogelijk is dat de kandidaat de bestanden los toevoegt, waarna de website vervolgens automatisch de bestanden zipt. Deze beschrijving betreft stap 7 in figuur 2.1. 6. De kandidaat krijgt na het invoeren van de persoonlijke gegevens een schatting van de studielast om de vakdefici¨enties weg te werken. Deze indicatie is gebaseerd op de meest relevante opleiding en het geselecteerde schoolvak. Als er meerdere adviezen beschikbaar zijn, dan wordt naar de andere opleidingen gekeken om het advies wat het best overeenkomt te selecteren. Als de studielast te hoog blijkt, kan de kandidaat er voor kiezen om niet verder te gaan met de invoer. In dit geval wordt er geen advies aangevraagd. Deze beschrijving betreft stap 8 in figuur 2.1. 7. De kandidaat moet voor opleidingen, waarvan het vakkenpakket in het systeem onbekend is, het vakkenpakket in kunnen vullen. Hierbij moeten de verplichte vakken, en specialisaties, apart worden ingevuld. Het ingevulde vakkenpakket moet worden opgeslagen in de historische gegevens, zodat deze gebruikt kan worden voor toekomstige aanvragen. Deze beschrijving betreft stap 10 in figuur 2.1. 8. De kandidaat moet zijn werkervaring, en overige informatie die relevant kan zijn voor de adviesgeving, in kunnen vullen. Deze beschrijving betreft stap 11 in figuur 2.1. 9. De kandidaat moet aan kunnen geven of hij een vakkenpakket dat al bestaat in de historische gegevens kopieert en deels aanpast, of verwerpt en zelf het vakkenpakket specifieert. Een nieuwe definitie van het vakkenpakket wordt opgeslagen in de historische gegevens voor gebruik bij toekomstige aanvragen. Als er meerdere vakkenpakketten beschikbaar zijn voor een opleiding, dan moet het mogelijk zijn om er ´e´en te kiezen. Deze beschrijving betreft stap 12 in figuur 2.1. 10. De kandidaat moet mappingen, voor vakkenpakketten waarvan deze niet bekend is, in kunnen vullen. Of het mappen plaatsvindt op kern- of subdomeinen is afhankelijk van de geselecteerde locatie voor het volgen van de vakken. De voorkeur voor sub- of kerndomeinen kan per toelatingscommissie verschillen. Momenteel wordt overlegd of deze per
45
vak gelijk is te leggen, zodat het direct hergebruiken van historische adviezen mogelijk is. De ingevulde mapping wordt opgeslagen en gebruikt voor toekomstige aanvragen. Een vak in het vakkenpakket, kan aan meerdere sub- of kerndomeinen zijn toegekend. Deze beschrijving betreft stap 14 in figuur 2.1. 11. De kandidaat moet aan kunnen geven of hij een mapping die al bestaat in de historische gegevens kopieert en bewerkt, of verwerpt en zelf de mapping definieert. Een nieuwe mapping wordt opgeslagen in de historische gegevens voor gebruik bij toekomstige aanvragen. Als er meerdere mappingen beschikbaar zijn voor een vakkenpakket, dan moet het mogelijk zijn om er ´e´en te kiezen. Deze beschrijving betreft stap 15 in figuur 2.1. 12. De kandidaat moet de adviesaanvraag bevestigen voordat deze verstuurd wordt naar de ingevoerde toelatingscommissie. Deze beschrijving betreft stap 18 in figuur 2.1. 13. De kandidaat moet altijd terug kunnen gaan naar een vorige stap, zodat fouten gecorrigeerd kunnen worden. Deze beschrijving betreft het gehele proces. 14. De kandidaat moet vragen kunnen stellen aan een toelatingscommissie. Hiervoor dient de kandidaat naar de contact-pagina te gaan. Hier moet de kandidaat zijn vraag in kunnen voeren en een toelatingscommissie kunnen selecteren. Ook moet de kandidaat een willekeurige tekst op een plaatje overschrijven, een zogenaamde Captcha. Hiermee worden spambots voorkomen.
2.1.2
Toelatingscommissie
Bij de beschrijving van het adviesgevingsproces is er vanuit gegaan dat het ontvangen en nakijken van het advies, en het zoeken van de vakken bij de vakdefici¨enties, door verschillende personen wordt gedaan. In werkelijkheid kan het voorkomen dat de taken voor het opstellen van een advies anders verdeeld zijn. 1. Om toegang te krijgen tot de inbox van een toelatingscommissie, moet eerst worden ingelogd door een lid van de toelatingscommissie. Elk persoon in de toelatingscommissie heeft een apart account. De secretaris kan aangesloten zijn bij meerdere toelatingscommissies (definitie van een toelatingscommissie in het programma is een schoolvak/universiteit paar). Deze krijgt dus ook meerdere inboxen te zien na het inloggen. De vakdidacticus ziet altijd maar ´e´en inbox, gezien deze slechts gespecialiseerd is in ´e´en vak. Mocht het zo zijn dat er vakdidactici zijn die gespecialiseerd zijn in meerdere vakken, dan zullen ze voor elk schoolvak een apart account aan moeten maken, zodat de gegevens gescheiden blijven. 2. Het moet voor de toelatingcommissie mogelijk zijn om de taken te verdelen tussen meerdere leden. Bij elke adviesaanvraag kan daarom worden aangegeven: . Of men bezig is met nakijken van de mapping van de kandidaat, of het nakijken gedaan heeft. . Of men bezig is met het zoeken van vakken bij de vakdefici¨enties, of het zoeken van vakken gedaan heeft. Hiervoor moet de mapping van de kandidaat zijn nagekeken. 3. Het moet voor de toelatingcommissie mogelijk zijn om de adviesaanvragen te lezen in een gezamelijke inbox. Als de secretaris lid is van meerdere toelatingscommissies, dan worden de verschillende inboxen apart weergegeven. Hierbij wordt aangenomen dat de persoon lid is van toelatingscommissies die zich op dezelfde locatie bevinden. Deze beschrijving betreft stap 1 en stap 5 in figuur 2.2. 46
4. Het moet voor de toelatingscommissie mogelijk zijn om bij een adviesaanvraag, de website vergelijkbare cases te laten weergeven. Deze beschrijving betreft stap 2 en stap 6 in figuur 2.2. 5. Het moet voor de toelatingscommissie mogelijk zijn om de mapping van een kandidaat aan te passen. Deze beschrijving betreft stap 3 in figuur 2.2. 6. Het moet voor de toelatingscommissie mogelijk zijn om een aanvraag of (deel)advies onderling te delen zodat taken, zoals het nakijken van de vakdefici¨enties, en het zoeken van vakken bij vakdefici¨enties, verdeeld kunnen worden. Deze beschrijving betreft stap 4 in figuur 2.2. 7. Het moet voor de toelatingscommissie mogelijk zijn om vakken bij vakdefici¨enties in te vullen, en vervolgens op te slaan in de historische gegevens. Deze beschrijving betreft stap 8 in figuur 2.2. 8. Het moet voor de toelatingscommissie mogelijk zijn om het uiteindelijke advies op te sturen naar de kandidaat. Hierbij genereert het systeem automatisch de tekst. De gebruiker krijgt echter wel eerst de tekst te zien, en kan dus de tekst aanpassen om deze persoonlijker te maken. Deze beschrijving betreft stap 9 in figuur 2.2. 9. Het moet voor de toelatingscommissie altijd mogelijk zijn om een (deel)advies aan te passen. Als deze al verstuurd is naar de kandidaat, dan wordt deze niet opnieuw verstuurd. Het oude advies blijft voor de kandidaat geldig. Bij het aanpassen van een advies, wordt eigenlijk een kopie ervan aangepast. Beide adviezen blijven dus bestaan in de database. De rede hiervoor is dat andere personen nog een verwijzing naar het oude advies kunnen hebben. 10. Het moet voor de toelatingscommissie mogelijk zijn om een kandidaat, die een aanvraag heeft gedaan bij deze toelatingscommissie, te mailen voor extra gegevens. Dit kan gedaan worden door een reply te sturen op de aanvraag van de kandidaat. 11. Het moet voor de toelatingscommissie mogelijk zijn om een aanvraag van een kandidaat door te sturen naar een persoon buiten het systeem. Deze situatie doet zich bijvoorbeeld voor als de examencommissie de cijferlijst van de kandidaat wil inzien. 12. Het moet voor de toelatingscommissie mogelijk zijn om de voorkeur van de commissie in te stellen op sub- of kerndomeinen. Als de kandidaat vervolgens de toelatingscommissie selecteert, dan zal hij het mappen van zijn vakken moeten doen op de gekozen optie. 13. Het moet voor de toelatingscommissie mogelijk zijn om contact op te nemen met andere toelatingscommissies via de applicatie.
2.2
Feedback en verwerking
Deze paragraaf beschrijft de feedback en verwerking door de applicatie die weergegeven, respectievelijk uitgevoerd, wordt aan de hand van de ingevoerde data. Feedback betreft de informatie die het systeem teruggeeft. Verwerking betreft het gebruik van de input door de applicatie om het doel van de gebruiker te bereiken. De eerste deelparagraaf bij de feedback en verwerking van de kandidaat. De tweede paragraaf specificeert de feedback en verwerking van de toelatingscommissie.
47
2.2.1
Kandidaat
1. De kandidaat moet alleen een advies aan kunnen vragen als deze is ingelogd. Indien dit niet het geval is, wordt de gebruiker alsnog gevraagd om in te loggen, of een nieuw account aan te maken. Deze beschrijving stap 1 van figuur 2.1. 2. De kandidaat moet in kunnen loggen door zijn mailadres en wachtwoord in te voeren in het inlogformulier. Als deze voldoen aan een bestaand account, dan wordt de gebruiker ingelogd. Als het wachtwoord onjuist is, kan de kandidaat ervoor kiezen het wachtwoord op te laten sturen. In dat geval stuurt het systeem het wachtwoord naar het mailadres van het account. Als het mailadres onbekend is, dan wordt gevraagd of de kandidaat een nieuw account aan wil maken. Deze beschrijving betreft stap 2 in figuur 2.1. 3. De kandidaat moet de vorige sessie kunnen hervatten door in te loggen. Na het inloggen zorgt het systeem ervoor dat de gebruiker automatisch verder kan gaan waar deze gebleven is. Als er geen gegevens in de database zijn opgeslagen, dan wordt overgegaan naar het invullen van de persoonlijke gegevens (stap 7 in figuur 2.1). Is dit wel het geval, dan wordt aan de hand van de opgeslagen gegevens de sessie hervat. De status kan opgeslagen worden in stap 10 t/m 15 van figuur 2.1. Deze beschrijving betreft stap 3 in figuur 2.1. 4. De kandidaat moet de status van de verwerking van zijn aanvraag kunnen bekijken. Mogelijke stadia die het systeem kan teruggeven zijn: . Niet bekeken door secretaris . Bezig met nakijken van mapping van vakken op vakdefici¨enties . Mapping van vakken op vakdefici¨enties nagekeken . Niet bekeken door lid wat vakken toekent . Vakken bij vakdefici¨enties aan het zoeken . Voltooid Bij de teruggave wordt weergegeven welke stappen al gedaan zijn, en welke nog moeten gebeuren. Hierdoor kan de kandidaat een schatting maken van de voortgang van zijn aanvraag. Als er meerdere adviezen zijn aangevraagd, dan krijgt de kandidaat ook meerdere adviezen te zien. Als er geen advies is aangevraagd, dan krijgt de kandidaat niets te zien. Deze beschrijving betreft stap 4 in figuur 2.1. 5. De kandidaat kan een account aanmaken door zijn naam, mailadres, en paswoord in te vullen. Als het mailadres, of de naam, al gekoppeld is aan een bestaand account, dan wordt de gebruiker gevraagd of hij zijn wachtwoord wil laten opsturen, of de gegevens aan wil passen. Als de aanmaak van het account is verwerkt, dan wordt de gebruiker automatisch ingelogd. Deze beschrijving betreft stap 5 en stap 6 in figuur 2.1. 6. De kandidaat moet zijn persoonlijke gegevens, zoals opleiding(en), invullen om een advies te verkrijgen. Deze input wordt gecontroleerd. Zo moet een kandidaat minimaal een opleiding hebben afgerond, en moeten alle overige gegevens zijn ingevuld. Ook moet de scan van de cijferlijst(en) een bepaald formaat hebben, en moet de bestandsgrootte kleiner zijn dan een later bepaalde grootte. Indien dit niet het geval is, wordt een foutmelding weergegeven, en wordt gevraagd de cijferlijst opnieuw te uploaden. Dit gebeurt ook als er een fout optreedt tijdens het uploaden. Kleinere checks betreffen de geldigheid van een mailadres, of controleren van de lengte van de voornaam. Deze beschrijving betreft stap 7 in figuur 2.1. 48
7. De kandidaat krijgt na het invullen van zijn persoonlijke gegevens een indicatie van de studielast voor het wegwerken van zijn vakdefici¨enties te zien. Deze indicatie is gebaseerd op een aangegeven, belangrijkste opleiding. Als er meerdere adviezen zijn, dan wordt naar de overige opleidingen gekeken om de meest relevante te bepalen. Als deze er niet zijn, dan wordt er weergegeven dat een indicatie helaas niet kan worden opgesteld. Deze beschrijving betreft stap 8 in figuur 2.1. 8. De kandidaat moet voor de opleidingen waarvan de vakkenpakketten bekend zijn bevestigen of hij met de vakinhoud akkoord gaat, of zelf wil defini¨eren. Als er meerdere vakkenpakketten voor een opleiding zijn, dan kan de kandidaat deze inzien en er ´e´en selecteren. Het is mogelijk om een vakkenpakket te selecteren, en vervolgens deels aan te passen. In dat geval wordt een kopie van het vakkenpakket in de database opgeslagen. De oude gegevens blijven dus intact. Als hij akkoord gaat met een toekenning, dan wordt naar de volgende opleiding met een (on)bekend vakkenpakket overgegaan totdat alle opleidingen zijn verwerkt. Als de kandidaat niet akkoord gaat met een vakkenpakket, dan dient hij deze zelf te defini¨eren. Deze gegevens worden opgeslagen in de historische gegevens zodat deze in toekomst gebruikt kunnen worden. Deze beschrijving betreft stap 9, stap 12, en een deel van stap 10 in figuur 2.1. 9. De kandidaat moet voor de opleidingen waarvan de vakkenpakketten onbekend zijn, het vakkenpakket defini¨eren. Deze gegevens worden opgeslagen in de database zodat deze in toekomst gebruikt kunnen worden. Het is slechts mogelijk om verder te gaan als aan elke opleiding een vakkenpakket is toegekend. Deze beschrijving betreft stap 9 en stap 10 in figuur 2.1. 10. De kandidaat moet zijn werkervaring en overige informatie invullen nadat de vakkenpakketten voor de opleidingen van de kandidaat bekend zijn. Deze informatie dient opgeslagen te worden in de de database als onderdeel van de aanvraag. Als deze informatie succesvol is opgeslagen, dan kan pas verder worden gegaan met de volgende stap. Het is mogelijk om deze informatie niet in te vullen. Deze beschrijving betreft stap 11 in figuur 2.1. 11. De kandidaat moet de mappingen defini¨eren die nog niet bekend zijn, en bekende mappingen bevestigen. Een mapping is in deze context het toekennen van sub- of kerndomeinen aan de verschillende vakken in een vakkenpakket. Hiervoor moet het systeem eerst controleren welke vakkenpakketten al een mapping hebben die in de historische gegevens. Het toekennen aan sub- of kerndomeinen wordt bepaald uit de voorkeur van de gekozen toelatingscommissie. De nieuwe toekenning moet opgeslagen worden in de database voor toekomstig gebruik. De kandidaat kan pas naar de volgende stap als alle vakken zijn ingevuld. Deze beschrijving betreft stap 13 in figuur 2.1. 12. De kandidaat moet bij de sub- of kerndomeinen van een schoolvak een voorbeeld en omschrijving krijgen van welke vakken ertoe behoren. Hierdoor kan de kandidaat een beter beeld ontwikkelen van welk sub- of kerndomein hij toe moet kennen aan een vak. Deze beschrijving betreft 10 en 12 in figuur 2.1. 13. De kandidaat moet voor de vakkenpakketten waarvan de mapping onbekend is de mapping defini¨eren. Deze gegevens worden opgeslagen in de database zodat deze in toekomst gebruikt kunnen worden. De kandidaat dient elk vak in te vullen. Als hij niet weet waartoe een vak behoort, dan kan hij “overig” selecteren. De kandidaat kan pas verder met de volgende stap als alle vakken zijn ingevuld. Deze beschrijving betreft stap 13 en stap 14 in figuur 2.1.
49
14. De kandidaat moet voor de vakkenpakketten waarvan de mapping bekend is, bevestigen of hij met de mapping akkoord gaat, of deze zelf wil defini¨eren. Als er meerdere mappingen voor een vakkenpakket zijn, dan kan de kandidaat er ´e´en selecteren. Het is mogelijk om een mapping te selecteren, en vervolgens deels aan te passen. In dat geval wordt een kopie van de mapping in de database opgeslagen. De oude gegevens blijven dus intact. Als hij akkoord gaat, dan wordt naar de volgende (on)bekende mapping overgegaan totdat alle vakkenpakketten zijn afgelopen. Als de kandidaat niet akkoord gaat met een mapping, dan dient hij deze zelf te defini¨eren. Deze gegevens worden opgeslagen in de database zodat deze in toekomst gebruikt kunnen worden. Deze beschrijving betreft stap 13, stap 15, en een deel van stap 14 in figuur 2.1. 15. De kandidaat moet direct na het mappen van zijn vakken een overzicht krijgen welke subof kerndomeinen ontbreken. Hierbij kan de kandidaat nog terug naar de vorige stap om eventueel mappingen aan te passen. Deze beschrijving betreft stap 17 in figuur 2.1. 16. De kandidaat moet zijn aanvraag bevestigen. Als de kandidaat toch besluit zijn aanvraag niet te versturen, dan kan hij deze opslaan, zodat hij later wijzigingen aan kan brengen. Vervolgens wordt het advies doorgestuurd naar de toelatingscommissie. Een adviesaanvraag bevat de volgende gegevens: . Contactgegevens . Opleidingsgegevens . Vakinhouden . Mappingen van kandidaat . EVC . Scan van cijferlijst(en) Deze beschrijving betreft stap 18 in figuur 2.1. 17. De kandidaat moet bij elke stap in figuur 2.1 een duidelijke beschrijving krijgen wat hij in moet vullen, en waarvoor de gegevens gebruikt worden.
2.2.2
Toelatingscommissie
Bij de beschrijving van het adviesgevingsproces is er vanuit gegaan dat het ontvangen en nakijken van het advies, en het zoeken van de vakken bij de vakdefici¨enties, door verschillende personen wordt gedaan. In werkelijkheid kan het voorkomen dat de taken voor het opstellen van een advies anders verdeeld zijn. 1. Het moet voor de toelatingscommissie mogelijk zijn om een aanvraag in een inbox te ontvangen en te bekijken. De gehele toelatingscommissie deelt de inbox. De verschillende taken, controleren van mapping van kandidaat en zoeken van vakken bij vakdefici¨enties, kunnen uitgevoerd worden door verschillende personen. Men kan aan het systeem doorgeven dat een stap is voltooid, of momenteel gedaan wordt. Hierdoor wordt werk niet dubbel gedaan, en is effici¨ent verdelen van taken mogelijk. Deze beschrijving betreft stap 1 van figuur 2.2. 2. Het moet voor de toelatingscommissie mogelijk zijn dat de applicatie, bij het controleren van de vakdefici¨enties, vergelijkbare cases weergeeft uit de historische gegevens. Door vergelijkbare case te raadplegen kan de toelatingscommissie controleren of de vakdefici¨enties correct benoemd zijn. Deze beschrijving betreft stap 2 en stap 3 in figuur 2.2. 50
3. Het moet voor de toelatingscommissie mogelijk zijn dat de applicatie, bij het controleren van de vakdefici¨enties, een digitale versie van de VSNU-gids kan aanroepen. Deze beschrijving betreft stap 2 en stap 3 in figuur 2.2. 4. Het moet voor de toelatingscommissie mogelijk zijn om wijzigingen in de mapping van de kandidaat aan te brengen, en deze op te slaan in de historische gegevens. Als een persoon het advies heeft gecontroleerd, dan moet deze aan kunnen geven dat het advies gecontroleerd is. Hierdoor is het voor de leden van de toelatingscommissie duidelijk dat de taak volbracht is. Deze beschrijving betreft stap 2 en stap 3 in figuur 2.2. 5. Het moet voor de toelatingscommissie mogelijk zijn om vergelijkbare cases te laten weergeven bij het zoeken van vakken bij de vakdefici¨enties. e definitie van vergelijkbare cases wordt pas later gekozen aan de hand van de hoeveelheid historische data. Waarschijnlijk wordt het een gelijke bachelor op een gelijke locatie. Deze beschrijving betreft stap 6 en stap 7 in figuur 2.2. 6. Het moet voor de toelatingscommissie mogelijk zijn om vakken toe te kennen aan vakdefici¨enties. Het systeem dient het uiteindelijke resultaat op te slaan in de historische gegevens. Als een persoon de vakken heeft toegekend, dan moet deze aan kunnen geven dat vakken zijn toegekend. Deze beschrijving betreft stap 7 en stap 8 in figuur 2.2. 7. Het moet voor de toelatingscommissie mogelijk zijn om te zien dat een bericht succesvol verstuurd is, of dat data correct is opgeslagen in de database. Deze beschrijving betreft stap 4, stap 8 en stap 9 in figuur 2.2. 8. Het moet voor de toelatingscommissie mogelijk zijn om een (deel)advies uit te printen. Deze beschrijving is in elke deelstap mogelijk.
2.3
Accounts
Deze paragraaf beschrijft de verschillende type accounts die er bestaan in de applicatie, en de rechten die hieraan verbonden zijn. De eerste deelparagraaf beschrijft het account van de kandidaat. De tweede paragraaf specificeert het account van een lid van de toelatingscommissie. Ten slotte beschrijft de derde paragraaf het account van de admin.
2.3.1
Kandidaat
1. De kandidaat moet inloggen met een account om een advies aan te vragen. 2. De kandidaat heeft een account met de volgende mogelijkheden: . De mogelijkheid om een advies aan te vragen . De mogelijkheid om een toelatingscommissie te mailen
2.3.2
Toelatingscommissie
1. De toelatingscommissie moet inloggen met een account om de commissiefuncties te kunnen gebruiken. De secretaris kan lid zijn van meerdere toelatingscommissies (definitie van toelatingscommissie is hier een schoolvak/universiteit-koppel). Er wordt hierbij wel vanuit gegaan dat het verschillende vakken betreft. Door een vak te selecteren kan in dat geval van inbox gewisseld worden. 51
2. De toelatingscommissie heeft een account met de volgende mogelijkheden: . Het opvragen van aan een aanvraag verwante cases uit de historische gegevens . Toegang tot bewerken, maar nooit verwijderen, van gegevens die door de toelatingscommissie zijn gegenereerd. Bij het bewerken wordt eigenlijk een kopie van de data bewerkt. De oude data blijft dus in de database bestaan. Zelfs na het versturen van het advies naar de kandidaat is dit mogelijk. Het oude advies blijft voor de kandidaat echter geldig . Aangeven dat een taak voor een bepaalde aanvraag voltooid is, bijvoorbeeld dat er vakken bij de vakdefici¨enties zijn gezocht . Het bewerken van de mapping die de kandidaat heeft gemaakt, en opslaan in historische gegevens . Het opslaan van een lijst van vakken, die gezocht zijn bij de vakdefici¨enties van een kandidaat, in de historische gegevens . Het doorsturen van een advies naar de kandidaat . Het doorsturen van de gegevens van een kandidaat naar bijvoorbeeld de examencommissie. De gegevens mogen slechts doorgestuurd worden naar bepaalde groepen. Deze groepen zijn vooraf gedefinieerd, en de kandidaat moet er tijdens de aanvraag akkoord mee zijn gegaan. . De secretaris heeft als extra recht dat hij moet verifi¨eren dat de aanvrager van een account voor de toelatingscommissie, daadwerkelijk in de commissie zit.
2.3.3
Admin
1. De admin is de persoon die initieel een secretaris voor elke toelatingscommissie toevoegt aan het systeem. 2. De admin is de persoon die toegang heeft tot de hulpfuncties van de database, zodat bewerkingen, zoals het verwijderen van oude kandidaten, uitgevoerd kunnen worden. 3. De admin is de persoon heeft directe toegang tot het uitlezen, en bewerken, van de database. 4. De admin is de persoon die de voorkeur voor een toelatingscommissie op sub- of kerndomeinen moet instellen. Dit recht is niet bij de toelatingscommissie gelegd, omdat deze optie niet eenvoudig te veranderen moet zijn.
2.4
Website-eigenschappen
In deze paragraaf worden de website-eigenschappen besproken. Hieronder vallen eigenschappen, zoals op welke browser het systeem draait, maar ook welke schermen er zijn, en hoe deze eruit zien. De algemene eigenschappen zullen besproken worden in de eerste paragraaf. De overige paragrafen gaan specifiek in op een doelgroep en beschrijven de schermen die deze doelgroep tijdens het gebruik te zien krijgt.
52
2.4.1
Gebruikers
1. De volgende eisen worden aan de webbrowser gesteld: . Voor de browser “Google Chrome”, geldt dat versie 3 minimaal vereist is. . Voor de browser “Internet Explorer”, geldt dat versie 7 minimaal vereist is. . Voor de browser “Mozilla Firefox”, geldt dat versie 2 minimaal vereist is. . Voor de browser “Opera”, geldt dat versie 9 minimaal vereist is. . Voor de browser “Safari”, geldt dat versie 3 minimaal vereist is. 2. De website dient op elk van bovenstaande browsers volledig te werken wat betreft de basisfunctionaliteit van de applicatie. 3. De website hoeft niet op elke browser er hetzelfde uit te zien, maar alle knoppen en velden moeten wel zichtbaar zijn. 4. De website dient te allen tijde het mailadres van de leden van de toelatingscommissie, en degene die eraan verbonden zijn, verborgen te houden voor de kandidaat.
53
2.4.2
Kandidaat
Voor de kandidaat zal de structuur van de website bij een aanvraag eruit zien als weergegeven in figuur 2.3. Niet alle mogelijkheden zijn in het diagram opgenomen om het model niet te complex te maken.
Figuur 2.3: Overzicht van de websitestructuur bij het aanvragen van een advies door een kandidaat
54
2.4.3
Toelatingscommissie
Voor de toelatingscommissie zal de structuur van de website bij het opstellen van een advies eruit zien als weergegeven in figuur 2.4. Niet alle mogelijkheden zijn in het diagram opgenomen om het model niet te complex te maken. De aangenomen taakverdeling kan in de werkelijkheid verschillen.
Figuur 2.4: Overzicht van de websitestructuur bij het opstellen van een advies door de toelatingscommissie
55
Hoofdstuk 3
Kwaliteitseisen In dit hoofdstuk worden de eisen wat betreft de kwaliteit van het product beschreven. Hiervoor wordt gekeken naar de betrouwbaarheid van het programma, de performance van het programma en daarmee ook de minimale systeemeisen. Daarna wordt in paragraaf 3.3 de veiligheid binnen het programma beschreven. In de laatste twee paragrafen wordt de onderhoudbaarheid en de bruikbaarheid van het programma beschreven.
3.1
Betrouwbaarheid
1. Het programma mag landelijk maximaal ´e´en keer per maand crashen bij een normale frequentie van gebruik. Hierbij is een crash gedefinieerd als een gebrek in de software, waardoor de gebruiker zijn hoofddoelen niet uit kan voeren. In geen enkel geval mogen de gegevens in de landelijke database corrupt raken, of een gehele toelatingscommissie belemmerd zijn in zijn taak. 2. De tijd tussen het optreden van twee instanties van bovengenoemde crash, moet minimaal een maand zijn. 3. Kleine fouten mogen zich landelijk eens per week voordoen. Kleine fouten zijn gedefinieerd als fouten die de basisfunctionaliteit niet in gevaar brengen, maar slechts een hinder vormen in het gebruik van de software. 4. De tijd tussen twee kleine fouten, moet voor een toelatingscommissie minstens een maand zijn. Bij kandidaten geldt dat er minimaal twee weken tussen moeten zitten. 5. Elke maand dient een backup van de database te worden gemaakt. 6. Mocht een bewerking fout gaan, dan dient het systeem zoveel mogelijk zelf het probleem op te lossen. 7. Als een bewerking niet ongedaan kan worden gemaakt, dan dient dit te worden weergegeven. Voor de andere bewerkingen geldt dat het mogelijk moet zijn om terug te gaan naar de oude staat. 8. Het programma dient getest te kunnen worden met automatische en manuele tests. Hierbij dient minimaal 90% van de statements in de code getest moet zijn.
56
9. Als het aantal gebruikers dat tegelijkertijd actief is boven de 100 komt, dan dient de site nieuwe gebruikers niet toe te laten. Het tegelijkertijd actief zijn van meer dan 100 gebruikers is namelijk zeker een aanval op de website.
3.2
Performance
1. Op de computer moet Javascript ge¨ınstalleerd staan en niet geblokeerd zijn. Als aan de eis van de browser is voldaan, dan is Javascript zeker ge¨ınstalleerd. Het gebruik ervan moet echter wel zijn toegestaan door de gebruiker. 2. De website moet correct functioneren, dit betekent dat de basisfunctionaliteit volledig werkt en elke pagina overgang van pagina maximaal 10 seconden duurt, als de server onder de maximale druk is, en de computer waarmee de site wordt bekeken voldoet aan de minimale eisen, en een brower heeft die voldoet aan de eisen gesteld in paragraaf 2.4.1. Waarschijnlijk werkt het programma ook op computers die niet aan de eisen voldoen, maar hierbij is volledige functionaliteit niet gegarandeert. 3. De minimale eisen waar een computer aan dient te voldoen zijn gedefinieerd als volgt: . Processor: 1 Ghz processor . Geheugen: 128 MB . Videokaart: minimaal 16 MB geheugen . Java versie: 1.6 . Internetverbinding: 128 kB/s download en 32 kB/s upload 4. De website moet elke pagina onder 10 seconden doorgeven als het aantal kandidaten maximaal 10 is en het aantal commissieleden die tegelijkertijd actief bezig zijn met de site maximaal 10.
3.3
Veiligheid
1. Door het optreden van elk type fout in het programma, die door defecten in het programma veroorzaakte worden, mag geen data verloren gaan. 2. Het programma dient bij elke mogelijke fout aan de gebruiker weer te geven wat er fout is gegaan en hoe dit gecorrigeerd kan worden. 3. Het moet niet mogelijk zijn om als kandidaat een account te krijgen voor een toelatingscommissie. Deze eis wordt geforceerd, doordat de secretaris van de commissie waar het account wordt aangevraagd, moet controleren of de aanvrager van een account wel onderdeel is van die toelatingscommissie.
3.4
Onderhoudbaarheid
1. Het gehele programma, met andere woorden iedere methode of functie, moet gedocumenteerd zijn. 2. Het programma dient opgedeeld te zijn in deelsystemen die ieder apart vervangbaar en onderhoudbaar zijn. 57
3. De aanwezigheid van eerder genoemde tests dient het mogelijk te maken om te testen of een nieuwe versie geen nieuwe fouten bevat wat betreft de oude functionaliteit. 4. Elke methode of procedure in het programma dient gedocumenteerd te zijn. 5. Er dient een onderhoudsdocument te worden geschreven, dat hulp biedt bij het onderhouden van het programma.
3.5
Bruikbaarheid
1. De gebruiker dient eenvoudig zijn weg te kunnen vinden in het programma zonder vaak terug te hoeven vallen op de handleiding. Op de website moet altijd een hulpfunctie op te roepen zijn die informatie geeft over de pagina waar de kandidaat zich op bevindt. Het goed functioneren van deze helpfunctie zal bij de gebruikertest worden gecontroleerd. 2. De kandidaat moet gemiddeld binnen een kwartier al zijn gegevens in kunnen vullen. 3. De commissieleden moeten baat hebben bij het mappen door de kandidaten. Dit houdt in dat het niet meer tijd moet kosten om de mapping te controleren, als om hem zelf op te stellen. 4. Bij elke stap van de kandidaat, moet informatie worden gegeven die hem helpt bij het invullen van de gegevens. Hierbij moet gedacht worden aan een definitie van een kern- of subdomein als hiernaar gemapt moet worden. 5. De database, en het programma, zal op een server draaien. Dit betekent dat als er een update moet worden gedaan, dat de gebruiker niets hoeft te doen, gezien deze slechts op de server uitgevoerd hoeft te worden.
58
Hoofdstuk 4
Use Cases In dit hoofdstuk zullen de verschillende use cases worden behandeld. Een use case beschrijft “wie” met het betreffende systeem “wat” kan doen. Use cases worden vaak gebruikt als indicatie hoe ver een project gevorderd is met het implementeren van de functionaliteit. In tabel 4.1 zijn de use cases van de kandidaat kort beschreven. De use cases van de toelatingscommissie worden behandeld in tabel 4.2. In de eerste paragraaf zullen de use cases van de kandidaat worden behandeld. Vervolgens zullen in de tweede paragraaf de use cases van de toelatingscommissie uiteen worden gezet.
59
Tabel 4.1: Overzicht use cases kandidaat Use case
Pagina
1. Vraag stellen aan toelatingscommissie 2. Account inloggen 3. Sessie hervatten 4. Advies status bekijken 5. Advies aanvragen 6. Account aanmaken 7. Inloggen met nieuw account 8. Opleidingsgegevens invullen 9. Indicatie opvragen 10. Cijferlijst uploaden 11. Vakkenpakket voor elke opleiding invullen 12. Vakkenpakket in historische gegevens 13. Vakkenpakket niet bekend 14. Invullen werkervaring/overige informatie 15. Mapping voor elk vakkenpakket invullen 16. Mapping niet bekend 17. Mapping in historische gegevens 18. Overzicht sub-/kerndomeinen bekijken 19. Aanvraag bevestigen 20. Paswoord opvragen
60
Tabel 4.2: Overzicht use cases toelatingscommissie Use case
Pagina
1. Vraag beantwoorden van kandidaat 2. Voorkeur sub- of kerndomeinen wijzigen 3. Aanvragen ophalen 4. Mailen naar andere toelatingscommissie 5. Account aanmaken 6. Account keuren door secretaris toelatingscommissie 7. Account inloggen 8. Gezamenlijke inbox bekijken 9. Mapping controleren 10. Toekenning sub-/kerndomein per vak controleren/bewerken 11. Aangeven dat mapping gecontroleerd is 12. Vakken toekennen aan mapping 13. Vakken invullen bij mapping 14. Digitale VSNU-gids raadplegen 15. Aangeven dat vakken zijn toegekend 16. Advies versturen 17. Aangeven dat advies verstuurd is 18. Paswoord opvragen
61
4.1
Use cases kandidaat
In figuur 4.1 worden de namen van de use cases met betrekking tot de kandidaat weergegeven. In deze paragraaf zullen deze use cases in detail worden behandeld.
Figuur 4.1: Overzicht van de verschillende use cases met betrekking tot de kandidaat
62
De kandidaat wil een vraag stellen aan een toelatingscommissie Doel: vraag stellen aan een toelatingscommissie Samenvatting: de kandidaat heeft een vraag aan een toelatingscommissie, waar niet het aanvraag-traject voor hoeft te worden doorlopen. Voor het stellen van een vraag moet een kandidaat een toelatingscommissie selecteren, de vraag beschrijven, en een tekst van een plaatje overschrijven (captcha), zodat degene die de vraag invult zeker een persoon is Voorwaarden: de kandidaat bevindt zich op de hoofdpagina van de website # 1 2 3 4 5 6 7
Kandidaat Kandidaat selecteert “contact” op de hoofdpagina
Systeem
System toont “contact” pagina van website Kandidaat Kandidaat Kandidaat Kandidaat
selecteert toelatingscommissie typt vraag in doet Captcha-test selecteert “versturen” Systeem verstuurt bericht naar persoonlijke emailadres van secretaris Systeem toont dat bericht is gestuurd, en dat antwoord binnen paar dagen kan worden verwacht
8
Account inloggen Doel: de kandidaat wil inloggen met een account Samenvatting: de kandidaat probeert in te loggen met een account. Als het mailadres niet overeenstemt met een bestaand account, dan wordt gevraagd of de kandidaat een nieuw account wil aanmaken. Als het paswoord onjuist is, dan wordt gevraagd of het paswoord opgestuurd moet worden. Als beide gegevens juist zijn, dan wordt de kandidaat ingelogd Voorwaarden: de kandidaat bevindt zich op de hoofdpagina # 1 2 3
Kandidaat Kandidaat selecteert “advies aanvragen”
Systeem Systeem toont “advies aanvragen” intropagina
Kandidaat vult in inlogformulier zijn mailadres en wachtwoord in, en selecteert “inloggen” Bestaand account, juiste inloggegevens
4
Systeem logt kandidaat in Juist mailadres, onjuist paswoord
4
Systeem biedt aan om wachtwoord op te sturen naar mailadres Onjuist mailadres
4
Systeem biedt aan om nieuw account aan te maken
63
Sessie hervatten Doel: de kandidaat wil een vorige sessie hervatten Samenvatting: de kandidaat wil een vorige sessie hervatten. Omdat het aanvraagproces vrij lang duurt om in te vullen, wordt tussentijds de ingevulde gegevens opgeslagen in de database. Als de kandidaat de volgende keer inlogt, wordt automatisch verder gegaan waar de kandidaat was gebleven. Als er geen punt is opgeslagen, dan start het aanvraag-traject bij het begin Voorwaarden: de kandidaat bevindt zich in het “advies aanvragen” scherm # 1 2
Kandidaat Kandidaat logt in met bestaand account
Systeem Systeem controleert welke gegevens ingevuld zijn, en welke ontbreken
Sessie beschikbaar 3
Systeem toont webpagina waar de kandidaat de vorige sessie had afgesloten. Alle gegevens zijn opgehaald Sessie niet beschikbaar
3
Systeem toont “basisinvoer” scherm
Advies status bekijken Doel: de kandidaat wil de status van zijn aanvraag bekijken Samenvatting: de kandidaat wil kijken wat de verwerkingsstatus van zijn aanvraag is. Als er een advies is aangevraagd, dan is de verwerkingsstatus hiervan weergegeven. Als er meerdere adviezen zijn aangevraagd, dan is van elk advies de status zichtbaar. Als er geen advies is aangevraagd, dan wordt weergegeven dat er geen aanvraag is uitgevoerd Voorwaarden: de kandidaat bevindt zich in het “account opties” scherm, en is ingelogd # 1 2
Kandidaat Kandidaat selecteert “advies status bekijken”
Systeem Systeem checkt voor verstuurde aanvragen
Een of meer aanvragen 3
Systeem toont voor elke aanvraag de status Geen aanvragen
3
Systeem toont dat er nog geen aanvraag is gedaan
64
Advies aanvragen Doel: de kandidaat wil een advies aanvragen door naar de “advies aanvragen” pagina te gaan Samenvatting: de kandidaat is op de website van de applicatie, en wil een advies aanvragen. Hiervoor selecteert hij “advies aanvragen”. Vervolgens maakt de kandidaat een account aan, of logt met een bestaand account in Voorwaarden: de kandidaat bevindt zich op de hoofdpagina van de website van de applicatie # 1 2
Kandidaat Kandidaat selecteert “advies aanvragen”
Systeem Systeemt toont de “advies aanvragen” hoofdpagina Systeem vraagt om in te loggen met een bestaand account, of een nieuw account aan te maken
3
Account aanmaken Doel: de kandidaat wil een account aanmaken om een advies aan te vragen Samenvatting: de kandidaat wil een advies aanvragen, en wil hiervoor een nieuw account aanmaken. Hiervoor dient hij een mailadres, en tweemaal het gewenste paswoord op te geven. Als het mailadres al bekend is, dan wordt gevraagd of de gebruiker het wachtwoord wil laten versturen naar het mailadres van dit account. Als het mailadres onbekend is, dan wordt het account aangemaakt als beide paswoorden gelijk zijn. Als beide paswoorden niet gelijk zijn, dan wordt de kandidaat gevraagd om deze opnieuw in te vullen Voorwaarden: de kandidaat bevindt zich op de hoofdpagina van “advies aanvragen” # 1 2 3
Kandidaat Kandidaat selecteert “account aanmaken”
Systeem Systeem toont aanmaakformulier
Kandidaat vult mailadres en tweemaal hetzelfde paswoord in Mail onbekend, paswoorden hetzelfde
4
Systeem maakt het account aan Mail onbekend, paswoorden verschillen
4
Systeem vraagt om tweemaal hetzelfde paswoord in te vullen Mail bekend
4
Systeem neemt aan dat de kandidaat al een account had, en vraagt of het paswoord naar het mailadres moet worden verzonden
65
Inloggen met nieuw account Doel: de kandidaat wil inloggen met een nieuw account Samenvatting: de kandidaat heeft net een nieuw account aangemaakt. De kandidaat wordt door het systeem automatisch ingelogd Voorwaarden: de kandidaat heeft de gegevens voor een nieuw, geldig account ingevuld # 1
Kandidaat Kandidaat heeft aanmaakformulier ingevuld, en selecteert “aanmaken account”
2 3 4 5
Systeem
Systeem Systeem Systeem Systeem
controleert of account nog niet bestaat maakt account aan logt kandidaat in toont “basisinvoer” scherm
Opleidingsgegevens invullen Doel: de kandidaat wil zijn opleidingsgegevens invullen Samenvatting: de kandidaat wordt in het “basisinvoer” scherm gevraagd om zijn naam, schoolvak, opleidingen, en voorkeur voor toelatingscommissie in te vullen. Ook wordt gevraagd of de kandidaat akkoord gaat met de voorwaarden. Als de kandidaat niet akkoord gaat, dan wordt de website afgesloten. Als de kandidaat wel akkoord gaat, dan berekent het systeem een schatting van de studielast die het kost om de vakdefici¨enties weg te werken. Voorwaarden: de kandidaat bevindt zich in het “basisinvoer” scherm # 1
Kandidaat
2 3
Kandidaat vult de gegevens in
Systeem Systeem vraagt om naam, schoolvak, opleidingen, en voorkeur voor toelatingscommissie in te vullen Systeem vraagt of gebruiker akkoord gaat met gebruiksvoorwaarden
Kandidaat accepteert voorwaarden 4
Systeem slaat gegevens op en toont “indicatie” scherm Kandidaat verwerpt voorwaarden
4
Systeem toont bericht dat gebruiker akkoord moet gaan om verder te gaan, zo niet, dan wordt de pagina afgesloten
66
Indicatie opvragen Doel: de kandidaat wil een schatting krijgen van de grootte van zijn vakdefici¨enties Samenvatting: de kandidaat krijgt een indicatie van de studielast voor het wegwerken van zijn vakdefici¨enties. Deze schatting is gebaseerd op vergelijkbare cases in de historische gegevens. De definitie van vergelijkbaar wordt later vastgesteld op basis van het aantal gegevens in de database, waarbij gebruik gemaakt worden van de meest relevante opleiding van de kandidaat. Als er geen vergelijkbare gegevens zijn, dan wordt weergegeven dat het niet mogelijk is om een indicatie op te stellen Voorwaarden: kandidaat heeft gegevens op het “basisinvoer” scherm correct ingevuld en de voorwaarden geaccepteerd # 1
Kandidaat
Systeem Systeem vraagt vergelijkbare cases op aan de hand van ingevoerde opleidingen kandidaat
Vergelijkbare cases bekend 2
Systeem kijkt in hoeverre cases overeenkomen met de meest relevante studie, en toont studielast van meest overeenkomende case Vergelijkbare cases onbekend
2
Systeem toont dat het helaas niet mogelijk is om een schatting te maken
Cijferlijst uploaden Doel: de kandidaat wil zijn cijferlijst(en) uploaden Samenvatting: het systeem vraagt de kandidaat om de cijferlijst(en) van zijn opleiding(en) te uploaden. De kandidaat moet hierbij aangeven waar het bestand, of bestanden stuk voor stuk, op zijn computer staat, en vervolgens “uploaden” selecteren. Elk bestand mag slechts een maximale grootte hebben Voorwaarden: de kandidaat heeft ´e´en of meer opleidingen ingevuld, en bevindt zich op “cijferlijst uploaden” scherm # 1 2
Kandidaat
Systeem Systeem vraagt om cijferlijst(en) te uploaden
Gebruiker voegt elke cijferlijst stuk voor stuk toe door “cijferlijst uploaden” te selecteren
3
Systeem toont foutmelding als een cijferlijst te groot is. In dat geval moet de gebruiker opnieuw de cijferlijst uploaden Systeem comprimeert de cijferlijsten in ´e´en bestand, en slaat deze op de server op Systeem maakt koppeling in de aanvraag van de kandidaat naar het bestand toe
4 5
67
Vakkenpakket voor elke opleiding invullen Doel: de kandidaat wil de vakinhoud van elke opleiding invullen Samenvatting: in de vorige stap van het aanvraagproces heeft het systeem als input de verschillende opleidingen gekregen. Vervolgens wordt voor elke opleiding bekeken of het vakkenpakket bekend is. Als dit het geval is, dan wordt gevraagd om het vakkenpakket te bevestigen. Als het vakkenpakket onbekend is, dan moet de kandidaat deze defini¨eren. Als elke opleiding is afgelopen, dan wordt verder gegaan Voorwaarden: de kandidaat bevindt zich in het “vakkenpakket defini¨eren” scherm # 1
Kandidaat
Systeem Systeem bekijkt voor elke opleiding of het vakkenpakket in de historische gegevens staat
Vakkenpakket(en) in historische gegevens 2
Systeem vraagt om ´e´en vakkenpakket te accepteren, of allen te verwerpen Geen vakkenpakket bekend
2
Systeem vraagt de kandidaat om het vakkenpakket te defini¨eren
Vakkenpakket in historische gegevens Doel: de kandidaat wil aangeven wat hij doet met een bestaande vakkenpakket Samenvatting: de kandidaat moet voor elke opleiding, waarvan een vakkenpakket in de historische gegevens bestaat, bevestigen of hij akkoord gaat met het vakkenpakket. Als er meerdere vakkenpakketten bestaan, dan kan hij er ´e´en selecteren om te accepteren, of allen verwerpen. Ook is het mogelijk de specialisaties van een bestaand vakkenpakket aan te passen Voorwaarden: het opleiding heeft minstens ´e´en vakkenpakket in de historische gegevens # 1
Kandidaat
Systeem Systeem vindt voor een opleiding ´e´en of meer vakkenpakketten in de historische gegevens Systeem toont vakkenpakket(ten)
2 3
3
Kandidaat bevestigt een vakkenpakket De kandidaat accepteert een vakkenpakket zonder deze aan te passen Kandidaat past een bestaand vakkenpakket aan De kandidaat selecteert een vakkenpakket, en bewerkt de specialisaties
4
3 4
Het systeem maakt een nieuw record in de database aan voor de specialisaties Kandidaat verwerpt alle vakkenpakket(ten) De kandidaat verwerpt elk vakkenpakket Het systeem vraagt om het vakkenpakket van de opleiding zelf te defini¨eren
68
Vakkenpakket niet bekend Doel: de kandidaat wil zelf het vakkenpakket van een opleiding defini¨eren Samenvatting: de kandidaat moet voor elke opleiding, waarvan het vakkenpakket niet in de historische gegevens staat, of waarvan een bestaand vakkenpakket is verworpen, het vakkenpakket defini¨eren. De kandidaat kan pas verder als elke opleiding een vakkenpakket is toegekend Voorwaarden: het vakkenpakket wat ingevuld wordt, is van een opleiding waarvan het vakkenpakket is verworpen, of waarvan geen vakkenpakket in de historische gegevens bestaat # 1
Kandidaat
2
De kandidaat vult de verplichte vakken van de opleiding in De kandidaat vult de specialisatie vakken van het vakkenpakket in De kandidaat selecteert “vakkenpakket” opslaan
3 4 5
Systeem Systeem toont een leeg scherm waar het vakkenpakket ingevuld kan worden
Het systeem slaat de verplichte vakken en de specialisatievakken apart op Het systeem maakt een referentie in de database aan naar het vakkenpakket voor de aanvraag van de kandidaat
6
Invullen werkervaring/overige informatie Doel: de kandidaat wil zijn werkervaring/overige informatie invullen Samenvatting: de kandidaat heeft net aan elke opleiding een vakkenpakket toegekend, en bevindt zich nu in het “werkervaring invullen” scherm. De kandidaat vult vervolgens zijn werkervaring in en selecteert “verder” Voorwaarden: de kandidaat bevindt zich in het “werkervaring invullen” scherm # 1
Kandidaat
2
De kandidaat vult zijn werkervaring en overige relevante informatie voor de aanvraag in De kandidaat selecteert “gegevens opslaan”
3 4
Systeem Systeem toont het “werkervaring invullen” scherm
Het systeem slaat de gegevens op de in de database en koppelt deze aan de aanvraag van de kandidaat
69
Mapping voor elk vakkenpakket invullen Doel: de kandidaat wil een mapping voor elk vakkenpakket defini¨eren Samenvatting: in deze stap wordt voor elk vakkenpakket bekeken of een mapping bekend is. Als dit geval is, dan wordt gevraagd om de mapping te bevestigen. Als de mapping niet bekend is, dan moet de kandidaat deze defini¨eren. Als elk vakkenpakket is gedefinieerd, wordt overgegaan naar de volgende stap Voorwaarden: de kandidaat bevindt zich in het “Mapping defini¨eren” scherm # 1
Kandidaat
Systeem Systeem bekijkt voor elk vakkenpakket of mapping in historische gegevens bestaat
Mapping(en) in historische gegevens 2
Systeem vraagt om ´e´en mapping te accepteren, of allen te verwerpen Geen mapping bekend
2
Systeem vraagt de kandidaat om een mapping te defini¨eren
Mapping niet bekend Doel: de kandidaat wil zelf een mapping bij een vakkenpakket defini¨eren Samenvatting: de kandidaat moet voor elk vakkenpakket, waarvan de mapping niet in de historische gegevens staat, of waarvan een bestaande mapping is verworpen, de mapping defini¨eren. De kandidaat kan pas verder als elk vakkenpakket een mapping is toegekend Voorwaarden: de mapping die ingevuld wordt, is van een vakkenpakket waarvan de mapping is verworpen, of waarvan geen mapping in de historische gegevens staat # 1
Kandidaat
2
De kandidaat vult voor elk vak ´e´en of meer kernof subdomeinen in De kandidaat selecteert “mapping opslaan”
3 5 6
Systeem Systeem toont een leeg scherm waar de mapping ingevuld moet worden
Het systeem slaat de mapping op Het systeem slaat de gegevens op de in de database en koppelt deze aan de aanvraag van de kandidaat
70
Mapping in historische gegevens Doel: de kandidaat wil aangeven wat hij doet met een bestaande mapping Samenvatting: de kandidaat moet voor elk vakkenpakket, waarvan een mapping in de historische gegevens bestaat, bevestigen of hij akkoord gaat met de mapping. Als er meerdere mappingen staan, dan kan hij er ´e´en selecteren om te accepteren, of ze allemaal verwerpen Voorwaarden: het vakkenpakket, waarvan de mapping bepaald wordt, heeft minstens ´e´en mapping in de historische gegevens # 1
Kandidaat
Systeem Systeem vindt voor een vakkenpakket ´e´en of meer mappingen Systeem toont bestaande vakkenpakket(ten)
2 3
3
Kandidaat bevestigt een mapping De kandidaat accepteert een mapping zonder deze aan te passen Kandidaat past een bestaande mapping aan De kandidaat selecteert een mapping, en bewerkt deze
4
3 4
Het systeem maakt een nieuwe record in de database aan voor de mapping Kandidaat verwerpt alle maping(en) De kandidaat verwerpt elke mapping Het systeem vraagt om een mapping van het vakkenpakket zelf te defini¨eren
Overzicht sub-/kerndomeinen bekijken Doel: de kandidaat wil bekijken welke sub-/kerndomeinen hij beheerst Samenvatting: de kandidaat wil een beeld krijgen van welke sub- of kerndomeinen overdekt zijn door zijn mapping. Na het invullen van de laatste mapping, wordt deze informatie automatisch op een nieuw scherm weergegeven. De kandidaat kan hierbij altijd een stap terug, zodat hij de mappingen aan kan passen Voorwaarden: de kandidaat heeft alle mappingen bepaald # 1
Kandidaat
Systeem Systeem bekijkt welke kern- of subdomeinen (afhankelijk van voorkeur toelatingscommissie) ingevuld zijn Systeem geeft ingevulde en niet ingevulde domeinen apart weer in het “overzicht sub/kerndomeinen” scherm
2
71
Aanvraag bevestigen Doel: de kandidaat wil zijn aanvraag bevestigen Samenvatting: de kandidaat heeft alle invoerstappen doorlopen. Op de pagina is een overzicht gegeven van de invoer. Als de kandidaat zijn invoer wil wijzigen, dan kan hij deze opnieuw defini¨eren. Als de kandidaat akkoord gaat, dan kan hij “bevestigen” selecteren om de aanvraag te bevestigen Voorwaarden: de kandidaat heeft alle stappen van het aanvraagproces doorlopen, en bevindt zich in het “aanvraag bevestigen” scherm # 1
Kandidaat
Systeem Systeem controleert dat de gebruiker alle gegevens heeft ingevuld Systeem toont de vakkenpakketten, mappingen, en het overzicht van de (niet) vervulde kern- of subdomeinen
2
3 4
Kandidaat gaat akkoord met gegevens Kandidaat selecteert “accepteren”
Paswoord opvragen Doel: de kandidaat wil zijn paswoord opvragen Samenvatting: de kandidaat heeft een account aangemaakt, maar is zijn paswoord vergeten. De kandidaat gaat vervolgens naar de “paswoord opvragen” pagina, en vult zijn mailadres in. Het systeem stuurt het paswoord, wat bij het mailadres hoort, naar het opgegeven mailadres. Als het mailadres niet bekend is, dan wordt een melding teruggegeven Voorwaarden: de kandidaat bevindt zich op de hoofdpagina, en wil een paswoord opvragen # 1 2 3 4
Kandidaat Kandidaat selecteert “paswoord opvragen”
Systeem Systeem toont “paswoord opvragen” scherm
Kandidaat vult mailadres in Kandidaat selecteert “opvragen” Mailadres is bekend
5
Systeem toont dat wachtwoord naar mailadres is verzonden Mailadres is onbekend
5
Systeem toont dat account niet bestaat
72
4.2
Use cases toelatingscommissie
In figuur 4.2 worden de namen van de use cases met betrekking tot de toelatingscommissie weergegeven. In deze paragraaf zullen deze use cases in detail worden behandeld. Voor de definitie van toelatingscommissie geldt een schoolvak/universiteit-koppel.
Figuur 4.2: Overzicht van de verschillende use cases met betrekking tot de toelatingscommissie
73
Vraag beantwoorden van kandidaat Doel: de secretaris van een toelatingscommissie wil een vraag van een kandidaat beantwoorden Samenvatting: het is mogelijk dat een kandidaat, zonder account, direct een bericht via de website stuurt naar een toelatingscommissie om een vraag te beantwoorden. In dat geval komt het bericht aan bij de secretaris van de toelatingscommissie. Deze beantwoordt vervolgens het bericht en stuurt een reply Voorwaarden: aanvrager is lid van de toelatingscommissie # 1 2
Secretaris De secretaris opent in zijn eigen mailbox de aanvraag van de kandidaat De secretaris stelt een reply op, en verzendt het bericht met zijn e-mailprogramma
3
Systeem en systeem
De applicatie had als afzender van het bericht het e-mailadres van de kandidaat opgegeven, dus het bericht komt automatisch op de juiste plaats
Voorkeur sub- of kerndomeinen wijzigen Doel: een toelatingscommissie wil de voorkeur voor kern- of subdomeinen wijzigen Samenvatting: initieel heeft de toelatingscommissie een voorkeur voor sub- of kerndomeinen. Het kan voorkomen dat deze echter in de toekomst verandert. Hiervoor moet de toelatingscommissie contact opnemen met de admin. Deze verzet vervolgens de voorkeur voor de toelatingscommissie. De voorkeur kan alleen verzet worden als alle aanvragen verwerkt zijn. Bij de omzetting gaan geen gegevens verloren Voorwaarden: aanvrager is lid van de toelatingscommissie # 1
Lid Secretaris van toelatingscommissie stuurt bericht naar admin om voorkeur te veranderen
2 3
Admin en systeem
Admin ontvangt bericht en opent deze Admin controleert of er nog openstaande aanvragen zijn Admin vindt geen openstaande aanvragen
4 5
Admin verandert voorkeur Admin stuurt bericht dat voorkeur is veranderd Admin vindt openstaande aanvragen
4
Admin stuurt bericht dat openstaande aanvragen eerst verwerkt moeten worden
74
Aanvragen ophalen Doel: een lid van de toelatingscommissie wil zijn gezamenlijk mailbox bekijken Samenvatting: een lid van de toelatingscommissie wil bekijken of er nieuwe aanvragen zijn gedaan door kandidaten Voorwaarden: het lid bevindt zich op de hoofdpagina van de applicatie # 1 2
2 3 4
Lid
Systeem Het systeem vraagt om in te loggen
Lid heeft een account Het lid van de toelatingscommissie logt in met het bestaande account Lid heeft geen account Het lid van de toelatingscommissie maakt een nieuw account aan Secretaris verifieert lidmaatschap van het lid Het lid van de toelatingscommissie logt in met het nieuwe account
Mailen naar andere toelatingscommissie Doel: een lid van de toelatingscommissie wil een bericht sturen naar een andere commissie Samenvatting: een lid van de toelatingscommissie wil een bericht sturen naar een andere toelatingscommissie. Hiervoor stelt hij een bericht op en selecteert een commissie Voorwaarden: het lid is ingelogd, en bevindt zich in het “gezamenlijke inbox‘’ scherm # 1 2 3
Lid Het lid selecteert “nieuw bericht opstellen” Het lid selecteert de toelatingscommissie Het lid typt het gewenste bericht in, en selecteert “versturen”
4 5
Systeem
Het systeem stuurt het bericht naar de secretaris Het systeem geeft weer dat het bericht verzonden is Het systeem toont de gezamenlijke inbox
6
75
Account aanmaken Doel: een lid van de toelatingscommissie wil een account aanmaken voor de toelatingscommissie Samenvatting: de secretarissen hebben initieel al een account, dus het is een overig lid. Het lid selecteert op de hoofdpagina “commissie account aanmaken”. Voor het aanmaken moet de naam, de gewenste toelatingscommissie, het mailadres, en tweemaal het gewenste paswoord worden opgegeven. Als het mailadres al bekend is, dan wordt gevraagd of het wachtwoord verstuurd moet worden naar dit adres. Als het adres onbekend is, dan wordt het account aangemaakt als beide paswoorden gelijk zijn, en de secretaris het lidmaatschap van het lid bevestigt. Als beide paswoorden ongelijk zijn, dan wordt gevraagd deze opnieuw in te vullen. Voorwaarden: de kandidaat bevindt zich op de hoofdpagina van “gezamenlijke inbox bekijken“ # 1 2 3
Lid Lid selecteert “account aanmaken”
Systeem en secretaris Systeem toont aanmaakformulier
Lid vult toelatingscommissie, mailadres en tweemaal hetzelfde paswoord in Mail onbekend, paswoorden hetzelfde
4 5 6 7
Systeem slaat niet geactiveerd account op Systeem stuurt bericht naar secretaris Secretaris bevestigt dat lid werkelijk lid is Systeem maakt account aan Mail onbekend, paswoorden verschillen
4
Systeem vraagt om tweemaal hetzelfde paswoord in te vullen Mail bekend
4
Systeem neemt aan dat de kandidaat al een account had, en vraagt om het paswoord naar het mailadres van het account te verzenden
76
Account keuren door secretaris toelatingscommissie Doel: de secretaris wil een aanvraag van een account voor zijn toelatingscommissie verifi¨eren Samenvatting: de secretaris ontvangt op zijn persoonlijke e-mailadres een bericht dat een persoon lid van de toelatingscommissie wil worden. Vervolgens verifieert de secretaris of de persoon wel echt lid is van de toelatingscommissie. Als dit geval is, dan bevestigt de secretaris de aanvraag. Als dit niet het geval is, dan verwerpt de secretaris de aanvraag Voorwaarden: een persoon heeft een aanvraag gedaan om lid te worden van de commissie # 1
2
3 4 3 4
Lid Secretaris bekijkt zijn mail en treft hierbij een aanvraag van een persoon aan om een account aan te maken voor de toelatingscommissie Secretaris verifieert of persoon werkelijk lid is van de toelatingscommissie Persoon is lid van de toelatingscommissie Secretaris selecteert “accepteren” link in de mail
Systeem
Systeem bevestigt account van het lid Persoon is geen lid van de toelatingscommissie Secretaris selecteert “verwerpen” link in de mail Systeem account
verwijdert
het
niet
geactiveerde
Account inloggen Doel: het lid wil inloggen met een account Samenvatting: de lid probeert in te loggen met een account. Als het mailadres onjuist is, dan wordt gevraagd of de kandidaat een nieuw account wil aanmaken. Als het paswoord onjuist is wordt gevraagd of het paswoord opgestuurd moet worden. Als beide gegevens juist zijn, dan wordt het lid ingelogd Voorwaarden: de kandidaat bevindt zich op de hoofdpagina # 1 2 3
Lid Lid selecteert “toelatingscommissie inloggen”
Systeem Systeem toont inlogformulier
Lid vult in inlogformulier zijn mailadres en wachtwoord in, en selecteert “inloggen” Bestaand account, juiste inloggegevens
4
Systeem logt lid in Juist mailadres, onjuist paswoord
4
Systeem biedt aan om wachtwoord op te sturen naar mailadres Onjuist mailadres
4
Systeem biedt aan om nieuw account aan te maken
77
Gezamenlijke inbox bekijken Doel: een lid van de toelatingscommissie wil gezamenlijke inbox bekijken Samenvatting: een lid van de toelatingscommissie heeft de juiste inloggegevens ingevuld en heeft “inloggen” geselecteerd. Het systeem logt de gebruik in, en geeft de gezamenlijke inbox weer. Als het lid een secretaris is, dan wordt van een toelatingscommissie de gezamenlijke inbox weergegeven, en kunnen de andere worden geselecteerd om weer te geven. Voorwaarden: het lid is net door het systeem ingelogd # 1 2
Lid
Systeem Systeem logt lid in Systeem geeft gezamenlijke inbox van toelatingscommissie weer. Als het lid een secretaris is, dan wordt een inbox weergegeven, en kunnen de overige inboxen opgeroepen worden
Mapping controleren Doel: een lid van de toelatingscommissie wil een mapping controleren Samenvatting: het lid van de toelatingscommissie wil een mapping controleren. Hiervoor dient hij de aanvraag van de kandidaat te openen, en vervolgens “mapping controleren” te selecteren. Vervolgens toont het systeem de mapping Voorwaarden: het lid is ingelogd en bevindt zich in het “gezamenlijke inbox” scherm # 1 2 3 4
Lid Lid selecteert aanvraag van kandidaat in gezamenlijke inbox
Systeem
Systeem geeft aanvraag van kandidaat weer Lid selecteert “mapping controleren” Systeem geeft mapping van kandidaat weer
78
Toekenning sub-/kerndomein per vak controleren/bewerken Doel: een lid wil de mapping van een kandidaat controleren/bewerken Samenvatting: een lid heeft een mapping van de kandidaat geopend, en wil deze nakijken. Hiervoor loopt hij elk vak af, en voert hierbij acties uit. Bij deze stap is het mogelijk om de VSNU-gids te raadplegen door “VSNU-gids weergeven” te selecteren. De gids wordt dan in een apart venster geopend Voorwaarden: een mapping van een aanvraag van een kandidaat is geopend # 1 2
3
4
Lid
Systeem Systeem geeft mapping van kandidaat weer
Lid loopt elk vak af, en verwijdert bij een vak een sub- of kerndomein, of meerdere, door “verwijderen” te selecteren voor het gegeven domein Lid loopt elk vak af en selecteert toevoegen om ´e´en of meer sub- of kerndomeinen toe te voegen aan het advies. Het toevoegen van sub- of kerndomeinen is afhankelijk van de voorkeur van de commissie Optioneel selecteert het lid “VSNU-gids weergeven” om de VSNU-gids weer te geven
Aangeven dat mapping gecontroleerd is Doel: een lid wil aangeven dat de mapping van de kandidaat gecontroleerd is Samenvatting: het lid van de toelatingscommissie heeft de mapping gecontroleerd. De volgende stap is aan te geven dat dit gebeurd is Voorwaarden: de mapping van een kandidaat is onlangs gecontroleerd # 1
Lid Lid heeft alle vakken gecontroleerd en selecteert “mapping opslaan”
2
Systeem
Systeem overschrijft het oude record van de kandidaat met het nieuwe record Systeem slaat in verwerkingsstatus op dat de mapping door de toelatingscommissie is gecontroleerd. Als de mapping al eens gecontroleerd was, dan wordt aangegeven dat de toekenning van vakken overnieuw moet
3
79
Vakken toekennen aan mapping Doel: een lid van de toelatingscommissie wil vakken toekennen aan de mapping van de kandidaat Samenvatting: het lid van de toelatingscommissie wil vakken toekennen aan de mapping van de kandidaat. Hiervoor opent deze de aanvraag van de kandidaat, en selecteert “vakken toekennen”. Als de mapping is gecontroleerd, dan toont het systeem het “vakken toekennen” scherm, anders wordt weergegeven dat de mapping eerst gecontroleerd moet worden Voorwaarden: het lid is ingelogd en bevindt zich in het “gezamenlijke inbox” scherm # 1
Lid Lid selecteert aanvraag van kandidaat in gezamenlijke inbox
2 3 4
Systeem
Systeem geeft aanvraag van kandidaat weer Lid selecteert “vakken toekennen” Systeem controleert of mapping van kandidaat al gecontroleerd is Mapping van kandidaat is gecontroleerd
5
Systeem toont mapping van kandidaat en de vakdefici¨enties van de kandidaat Mapping van kandidaat is niet gecontroleerd
5
Systeem toont bericht dat de mapping eerst gecontroleerd moet worden
80
Vakken invullen bij mapping Doel: een lid wil vakken invullen voor de vakdefici¨enties van een kandidaat Samenvatting: de mapping van de kandidaat is gecontroleerd. Het systeem laat het “vakken toekennen” scherm zien. Deze bevat de mapping van de kandidaat, de vakdefici¨enties van de kandidaat, een link naar de VSNU-gids, en de mogelijkheid om aan vakdefici¨enties vakken toe te voegen, of te verwijderen Voorwaarden: “vakken toekennen” is geselecteerd, en de mapping was al gecontroleerd # 1
2 3 4 5
Lid Lid loopt elke vakdefici¨entie af en selecteert “vak toevoegen” om een vak toe te voegen aan het ontbrekende kern- of subdomein Optioneel kan een vak verwijderd worden Optioneel selecteert het lid “VSNU-gids weergeven” om de VSNU-gids weer te geven Lid selecteert “toekenning opslaan”
Systeem
Systeem controleert of voor elke vakdefici¨entie een vak is toegekend Een vakdefici¨entie is geen vak toegekend
6
Systeem geeft weer dat niet elke vakdefici¨entie een vak is toegekend, en vraagt om dit alsnog te doen Alle vakdefici¨enties zijn vakken toegekend
6
Systeem slaat de gegevens op in de database, en linkt deze aan de aanvraag van de kandidaat
Digitale VSNU-gids raadplegen Doel: een lid wil de VSNU-gids raadplegen bij het controleren van de mapping, of bij het toekennen van vakken Samenvatting: het lid wil tijdens het nakijken van de mapping van de kandidaat, of tijdens het toekennen van de vakken, de VSNU-gids raadplegen. Hiervoor selecteert hij “VSNU-gids weergeven”. Vervolgens wordt een nieuw scherm geopend met de gegevens van de VSNU-gids voor het betreffende schoolvak Voorwaarden: het lid is bezig met het controleren van de mapping, of toekennen van vakken # 1 2
Lid Lid selecteert “VSNU-gids weergeven”
Systeem Systeem opent een nieuwe pagina in een apart venster, en toont hierin de VSNU-gids voor het schoolvak
81
Aangeven dat vakken zijn toegekend Doel: een lid wil aangeven dat vakken zijn toegekend aan alle vakdefici¨enties van de kandidaat Samenvatting: het lid van de toelatingscommissie heeft vakken toegekend aan de mapping van de kandidaat. De volgende stap is aan te geven dat dit gebeurd is Voorwaarden: vakken zijn onlangs toegekend aan de mapping van de kandidaat # 1
Lid Lid heeft aan alle vakdefici¨enties vakken toegekend en selecteert “toekenning opslaan”
2
Systeem
Systeem maakt voor een nieuw record aan voor de toekenning, en koppelt deze aan de aanvraag Systeem slaat in de verwerkingsstatus op dat er vakken door de toelatingscommissie zijn toegekend
3
Advies versturen Doel: een lid wil het advies opsturen naar de kandidaat Samenvatting: een lid ziet dat een aanvraag al wel verwerkt is, maar niet verstuurd. Het lid opent deze aanvraag en selecteert “advies opstellen”. Vervolgens geeft het systeem de mapping, vakdefici¨enties, en toegekende vakken weer. Op basis van deze informatie kan het lid beslissen om het advies aan te passen. Ook toont het systeem een automatisch gegenereerd bericht. De kandidaat kan deze aanpassen. Vervolgens selecteert de kandidaat “versturen”, en wordt het advies opgestuurd Voorwaarden: het lid is ingelogd en bevindt zich in het “gezamenlijke inbox” scherm, en de geselecteerde aanvraag is nog niet verstuurd # 1 2 3 4
5 6 7
Lid Lid selecteert aanvraag van kandidaat in gezamenlijke inbox
Systeem
Systeem geeft aanvraag van kandidaat weer Lid selecteert “advies opstellen” Systeem geeft “advies opstellen” scherm weer met de mapping, vakdefici¨enties, toegekende vakken, en automatisch gegenereerd bericht Optioneel past het lid het bericht aan Lid selecteert “versturen” Systeem verstuurt advies naar e-mailadres van kandidaat
82
Aangeven dat advies verstuurd is Doel: een lid wil aangeven dat het advies naar de kandidaat is verstuurd Samenvatting: het lid van de toelatingscommissie heeft advies verstuurd. Vervolgens wordt in de verwerkingsstatus van de aanvraag opgeslagen dat het advies verstuurd is. Vervolgens wordt ook bij de toelatingscommissie in de gezamenlijke mailbox aangegeven dat het advies verstuurd is Voorwaarden: onlangs heeft een lid van de toelatingscommissie “versturen” geselecteerd # 1 2
Lid Lid heeft “versturen” geselecteerd
Systeem Systeem zet bij de verwerkingsstatus van de aanvraag dat het advies verstuurd is Systeem geeft in de gezamenlijke inbox van de toelatingscommissie weer dat het bericht verstuurd is Systeem verzendt bericht naar gebruiker
3
4
Paswoord opvragen Doel: een lid wil zijn paswoord opvragen Samenvatting: het lid van de toelatingscommissie heeft een account aangemaakt, maar is zijn paswoord vergeten. Het lid gaat vervolgens naar de “paswoord opvragen” pagina, en vult zijn mailadres in. Het systeem stuurt het paswoord, wat bij het mailadres hoort, naar het opgegeven mailadres. Als het mailadres niet bekend is, dan wordt een melding teruggegeven Voorwaarden: de kandidaat bevindt zich op de hoofdpagina, en wil een paswoord opvragen # 1 2 3 4
Lid Lid selecteert “paswoord opvragen”
Systeem Systeem toont “paswoord opvragen” scherm
Lid vult mailadres in Lid selecteert “opvragen” Mailadres is bekend
5
Systeem toont dat wachtwoord naar mailadres is verzonden Mailadres is onbekend
5
Systeem toont dat account niet bestaat
83
Bijlage A
Planning
status
status
datum 10/02/2010 15/02/2010 15/02/2010 01/03/2010 10/03/2010 15/03/2010 26/03/2010 26/03/2010 28/03/2010 02/04/2010 05/04/2010 06/04/2010 12/04/2010 18/04/2010 25/04/2010
Tabel A.1: Planning ontwerpfase taak bijzonderheden programma van eisen concept probleemanalyse actorenalayse grafische interface artists impression van user interface programma van eisen final (na overleg met toelatingscommissies) use cases concept database design scenario’s concept use cases final (na overleg met selectie) scenario’s final (na overleg met selectie) klassendiagram sequence diagram grafische interface final (na overleg met selectie) functie blokschema morfologische kaart
datum 18/05/2010 18/05/2010 18/05/2010 24/05/2010 31/05/2010 10/06/2010
Tabel A.2: Planning implementatiefase taak bijzonderheden model development controller development view development core testen gebruikerstesten (core) beta bugfixing gebruikerstesten (high level) release candidate bugfixing gebruikerstesten (goedkeuring)
84
status
datum 14/06/2010 17/06/2010 18/06/2010
Tabel A.3: Planning testfase taak bijzonderheden release testen code testen gebruikerstesten
status
datum 27/06/2010 27/06/2010
Tabel A.4: Planning pilotfase taak manual beheerderstools overhandigen en uitleg geven
85
bijzonderheden
Bijlage B
Definitielijst Begrip
Definitie
Actorenanalyse
Onderdeel van het verslag waarbij de doelen van de doelgroep worden bepaald, de problemen die optreden bij het behalen van deze doelen, en de oplossingen voor de problemen. Een advies is een formulier uitgegeven door een toelatingscommissie dat minimaal bestaat uit de vakken die de kandidaat moet volgen om zijn vakdefici¨enties weg te werken. Het wegwerken van de defici¨enties in het advies geeft toegang tot de Universitaire Leraren Opleiding. Het “Alle H@nds Aan Dek” project is een project met als doel de instroom en het studiesucces van studenten van de universitaire lerarenopleidingen te verhogen. De applicatie is onderdeel van werkpakket 4A. Onderdeel van het AHAD-project. Door E-learning-trajecten kan men door zelfstudie online een vak leren. Hierdoor is een kandidaat met een vakdefici¨entie niet aan een locatie en tijd gebonden voor het vak. Set van vakkenpakketten, mappingen, geadviseerde vakken, en cijferlijst van een kandidaat. Het betreft een gegeven wat voordat de applicatie actief is geworden is verkregen. Deze gegevens kunnen door een admin in de database worden gezet met behulp van de “historisch gegeven toevoegen” functie. Een schatting van de studielast dat het kost voor een kandidaat om zijn vakdefici¨enties weg te werken. De schatting zal in de applicatie gebaseerd worden op de opleidingen van de kandidaat. In de context van de applicatie, is een kandidaat een persoon die gebruik maakt van de applicatie om een advies aan te vragen, een indicatie wil, of contact op wil nemen met een toelatingscommissie.
Advies
AHAD
E-learning-trajecten
Historisch gegeven
. Indicatie
Kandidaat
86
Kerndomeinen
Kwaliteitseisen
Mappen Programma Van Eisen
Requirements document
Secretaris
Shopper Subdomeinen
Toelatingscommissie
Universitaire Leraren Opleiding
Vakdefici¨entie VSNU-gids
Elk schoolvak heeft een aantal kerndomeinen. Dit zijn de globale onderwerpen waar een kandidaat kennis over moet hebben om toegelaten te worden tot de Universitaire Leraren Opleiding voor het schoolvak. Eisen waar een applicatie aan moet voldoen om een kwalitatief product te zijn. Bij een kwalitatief product zijn maatregelen getroffen om het product eenvoudig onderhoud- en uitbreidbaar te maken. Betreft het benoemen van het sub- of kerndomein(en) waartoe een gevolgd vak van een kandidaat behoort. Dit onderdeel van het verslag bevat de eisen waar de applicatie aan moet voldoen om de problemen die in de actorenanalyse zijn gedefinieerd op te lossen. Een requirements document beschrijft de eisen waar een product aan moet voldoen. Dit verslag is een requirements document dat is uitgebreid met een actorenanalyse. Een secretaris is in deze applicatie gedefinieerd als de persoon die in het nieuwe proces degene is die bepaalt of een aanvraag voor een toelatingcommissie-account toegelaten of geblokkeerd wordt. Kandidaat die bij meerdere toelatingscommissies een advies aanvraagt met als doel het advies op te volgen wat hij het best vindt. De kerndomeinen die bij een schoolvak horen, zijn opgesplitst in subdomeinen. Deze subdomeinen zijn de onderwerpen waar een kerndomein uit bestaat. Een toelatingscommissie is een bevoegd team op een universiteit die een advies opstelt voor een kandidaat voor een vastgesteld schoolvak. In de applicatie is een toelatingscommissie gedefinieerd als een schoolvak/universiteit-paar. In de werkelijke situatie kan een toelatingscommissie gespecialiseerd zijn in meerdere vakken. In dat geval wordt in de applicatie de toelatingscommissie opgesplitst in meerdere toelatingscommissies. Er zijn verschillende ULO’s in Nederland. Een kandidaat heeft toegang tot een ULO als hij al zijn vakdefici¨enties, die bepaald zijn door een toelatingscommissie, heeft weggewerkt voor een bepaald schoolvak. Na het voltooien van de ULO is de kandidaat officieel een eerstegraads-docent. Een kandidaat heeft een vakdefici¨entie als deze onvoldoende kennis en ervaring bezit in een kern- of subdomein van een schoolvak. Een gids opgesteld door de Vereniging Van Universiteiten. Deze gids geeft voor elk schoolvak aan welke kern- en subdomeinen een kandidaat moet beheersen om toegelaten te worden tot de ULO.
87
Bijlage B
Onderzoeksverslag
88
Hoofdstuk 1
Inleiding Voor velen is het bachelorproject het de afsluiting van de bachelorstudie. In dit project wordt de kennis die de afgelopen jaren is verkregen, omgezet in hoogwaardige software. Om deze transitie tot stand te brengen is de kennis van de bachelor “Technisch Informatica” onvoldoende, er zijn immers verschillende onderwerpen die niet in de studie zijn behandeld. In dit document worden de problemen die tijdens het project ontstonden behandeld. Voor elk probleem worden verschillende oplossingen ge¨evalueerd. Uiteindelijk wordt aan de hand van de opgestelde criteria de beste oplossing gekozen. In hoofdstuk 2 zal de encryptie van lokale gegevens worden behandeld. Vervolgens zal in hoofdstuk 3 de keuze van de database-engine uiteen worden gezet. In hoofdstuk 4 zal een geschikte webtaal voor de applicatie worden besproken. Hierna zal in hoofdstuk 5 TLS worden behandeld. Tot slot zal voor elk probleem de gekozen oplossing worden weergegeven in hoofdstuk 6. In bijlage A is een implementatie van serialization van een object in Java gegeven.
89
Hoofdstuk 2
Encryptie lokale gegevens Dit hoofdstuk behandeld de encryptie van privacygevoelige informatie. Bij de initi¨ele opdracht van het bachelorproject zou sprake zijn van de ontwikkeling van een expertsysteem wat zou functioneren met behulp van een online database. Sommige privacygevoelige gegevens zouden echter volgens het CBP niet online mogen worden opgeslagen. Versleutelde lokale opslag werd echter wel toegestaan.
2.1
Probleem
Voor het realiseren van de software zullen privacygevoelige gegevens lokaal moeten worden opgeslagen. Deze gegevens mogen alleen door de gebruiker worden bekeken, en dienen niet door derden uitleesbaar te zijn.
2.2
Beoordelingscriteria
Om de geschiktheid van een oplossing te bepalen worden in deze paragraaf enkele criteria besproken waaraan een oplossing moet voldoen. . encoderen. De data moet binnen een paar seconden versleuteld opgeslagen kunnen worden . decoderen. De data moet binnen een paar seconden ontcijfert kunnen worden . veiligheid. De data moet niet binnen 50 jaar uitgelezen kunnen worden . unieke sleutel. De sleutel tot gegevens moet voor elke gebruiker uniek zijn . legaliteit. De opslagtechniek moet wettelijk zijn toegestaan . geen extra software. Voor het proces moet geen extra software benodigd zijn
90
2.3
Mogelijke oplossingen
In deze paragraaf worden mogelijke oplossingen voor het probleem beschreven. De oplossingen zullen behandeld worden aan de hand van de verschillende criteria zoals opgesteld in paragraaf 2.2.
2.3.1
Database Encryptie
Encryptie van een lokale database lijkt een voor de hand liggende optie. Hierbij wordt de informatie in de database versleuteld aan de hand van een gedeelde sleutel [? ]. Als een query wordt uitgevoerd om data op te vragen dan worden de gegevens door de databaseserver, die in dit geval lokaal draait, eerst gedecodeerd voordat ze verstuurd worden naar de gebruiker. Bij het opslaan van informatie in de database wordt de data door de server versleuteld voordat deze wordt opgeslagen. Er zijn twee mogelijke manieren van opslag met elk zijn voor- en nadelen. De beoordelingsmatrix van database encryptie is weergegeven in figuur 2.1. 1. Versleutelen van individuele items in de database. Bij deze aanpak wordt elk item apart versleuteld. Dit houdt in dat bij elke update maar een item gecodeerd moet worden. Bij uitlezen hoeft ook maar een item te worden gedecodeerd. Het nadeel hiervan is echter wel dat het mogelijk is om te zien dat een bepaald item meerdere malen in de database voorkomt. Op basis hiervan zou de betekenis bepaald kunnen worden en wellicht de sleutel. 2. Versleutelen van de database als een geheel. Bij deze aanpak wordt de gehele database als een blok data behandeld. Het voordeel is dat bij encryptietechnieken zoals AES [? ], het onmogelijk is om het aantal keer voorkomen van een woord te bekijken, omdat de gehele input invloed heeft op de string die als output wordt weggeschreven. Het nadeel is echter wel dat bij opvragen en updaten de gehele database wordt worden gedecodeerd, respectievelijk versleuteld [? ]. Tabel 2.1: Beoordelingsmatrix database encryptie Criteria Encoderen
Beoordeling +
Beschrijving De eerste methode is het aantrekkelijkst voor opslag, gezien deze het minste performance verlies oplevert. Het aantal keer voorkomen van een element kan worden bepaald. Echter, in de context van de applicatie zullen elementen vaak uniek zijn. Decoderen + Zelfde reden als hierboven Veiligheid ++ Als de sleutel niet bekend is, dan wordt eenvoudig aan dit criteria voldaan. Het is namelijk mogelijk om allerlei verschillende encrypties te kiezen Unieke sleutel + Er is ´e´en gedeelde sleutel, maar de lokale database wordt door ´e´en persoon gebruikt. Dus dit vormt geen probleem Legaliteit +/Voor 192 en 256 byte AES is een licentie vereist. Voor andere algoritmen bestaan vergelijkbare restricties Geen extra software Voor de opslag van de data dient een database te worden ge¨ınstalleerd De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/-
91
2.3.2
Object serializen
Bij veel programmeertalen, waaronder Java [? ], is het mogelijk om een object te serializen. Hierbij wordt een object omgezet in een tekstuele representatie. De tekstuele representatie kan op een later tijdstip weer worden omgezet in een object. Om serialization als oplossing te beschouwen, is een java klasse geschreven die de benodigde methodes implementeert. De klasse zoals beschreven in bijlage A slaat een String ArrayList geserialized op, eenmaal met, en eenmaal zonder, encryptie. Andere objecten zijn met vergelijkbare methodes mogelijk. De beoordelingsmatrix van serialization zonder encryptie is weergegeven in figuur 2.2. Tabel 2.2: Beoordelingsmatrix object serialization Criteria Encoderen
Beoordeling ++
Decoderen
++
Veiligheid
--
Unieke sleutel
--
Legaliteit ++ Geen extra software ++ De schaal van de beoordeling
2.3.3
Beschrijving Het object kan in een paar milliseconden worden omgezet in een bestand Het bestand kan in een paar milliseconden worden omgezet in een object De inhoud van het object kan direct uit worden gelezen als deze niet van te voren versleuteld is Iedereen kan het object (de)serializen als de structuur van object bekend is Er zijn geen wettelijke beperkingen Er is geen extra software benodigd loopt van - - tot ++. Neutraal wordt aangegeven met +/-
Object serializen en versleutelen
De zwaktes van serializen zonder encryptie zijn de gemeenschappelijke mogelijkheid to decoderen, en het nauwelijks versleutelen van de gegevens in het object. Beide zwaktes kunnen worden verbeterd door het object, alvorens het op te slaan in een bestand, te versleutelen met behulp van encryptie. In tegenstelling tot hashing, moet het object ook weer gedecodeerd kunnen worden. Echter, ieder persoon moet wel een unieke sleutel hebben. Dit kan bereikt worden door met accounts te werken, en het paswoord waarmee versleuteld wordt te baseren op de username en het paswoord. Een paswoord moet een bepaalde lengte hebben, dus eerst een hashing toegepast worden om het bestand een bepaald aantal letters te krijgen. In bijlage A staat een klasse beschreven die een String ArrayList object op kan slaan in een bestand. Hiervoor wordt AES-encryptie gebruikt, omdat deze wordt gezien als een van de sterkste beveiligingen, en een bestand zeker niet binnen 100 jaar te ontcijferen is [? ]. Er is gebruik gemaakt van de 128 byte key variant, omdat 192 en 256 in sommige landen niet is toegestaan, en een aparte license vereist. De beoordelingsmatrix van serialization met encryptie is weergegeven in figuur 2.3.
92
Tabel 2.3: Beoordelingsmatrix object serialization met encryptie Criteria Encoderen
Beoordeling +
Decoderen
+
Veiligheid
++
Unieke sleutel
++
Legaliteit +/Geen extra software ++ De schaal van de beoordeling
2.4
Beschrijving Het object kan binnen een seconde worden omgezet in een bestand Het bestand kan binnen een seconde worden omgezet in een object De inhoud van het object het bestand is niet uit te lezen zonder de key De sleutel kan gebaseerd worden op een combinatie van de username en paswoord Voor 192 en 256 byte AES is een licentie vereist Er is geen extra software benodigd loopt van - - tot ++. Neutraal wordt aangegeven met +/-
Oplossing
In de voorgaande paragrafen zijn verschillende oplossingen voor het probleem onderzocht. Uit de evaluatie van deze oplossingen zijn een aantal conclusies te trekken: 1. Encryptie van de database is aantrekkelijk, maar vereist extra software om de lokale op te zetten 2. Serialization zonder encryptie levert een snelle toegang tot de informatie, maar de sleutel is uniform, en de data is eenvoudig uit te lezen 3. Serialization met encryptie kost bij het wegschrijven en ophalen van de data meer tijd dan zonder encryptie, maar werkt snel genoeg. Deze oplossing vereist geen extra software Zoals weergegeven in figuur 2.4, is serialization met encryptie de beste oplossing. In de tweede versie van het programma was een lokale database echter niet meer vereist, en praktisch, omdat met een website zou worden gewerkt. Uiteindelijk is de oplossing dus niet uitgewerkt tot een deel van de applicatie. Tabel 2.4: Beoordelingsmatrix oplossingen Criteria
Database
Serialization
Encrypted serialization Encoderen + ++ + Decoderen + ++ + Veiligheid ++ – ++ Unieke sleutel – ++ ++ Legaliteit +/++ +/Geen extra software ++ ++ De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/-
93
Hoofdstuk 3
Database-engine functionaliteit Dit hoofdstuk behandeld de keuze van de database-engine. Voor de applicatie zal data moeten worden opgeslagen in een database die voor iedereen toegankelijk is. Om deze database te realiseren moet voor elke tabel een engine zijn gedefinieerd.
3.1
Probleem
De TU Delft biedt aan studenten verschillende database-engines aan [? ]. Het probleem is om een engine te kiezen die voldoet aan de criteria die in de volgende paragraaf worden gesteld. De volgende database-engines, die gebruik maken van een harde schijf, en geen MERGE functionaliteit bevatten [? ], worden door de TU Delft aangeboden: 1. MyISAM 2. InnoDB 3. BerkeleyDB
3.2
Beoordelingscriteria
Om de geschiktheid van een oplossing te bepalen worden in deze paragraaf enkele criteria besproken waaraan een oplossing moet voldoen. . Beschikbaarheid. De engine moet standaard bij MySQL worden geleverd, en er moeten indicaties zijn dat dit de komende versies zo blijft . Primary key/foreign key constraints. De engine moet de mogelijkheid hebben om primary key/foreign key constraints te bekrachtigen [? ]. Hierdoor is het mogelijk dat als er wat gebeurt met een record met de primary key, dat er automatisch een actie wordt ondernomen om de gerelateerde record(s), met de primary key als foreign key, te updaten. Hierdoor wordt de integriteit van de database beschermd . Transacties. De engine moet werken met transacties [? ], waardoor het mogelijk is voor een gebruiker om meerdere queries in een keer uit te voeren, en het resultaat te bekijken, zonder dat de database direct wordt ge¨ update voor de overige gebruikers. Pas als de gebruiker het commit commando heeft uitgevoerd, worden de wijzigingen voor iedereen
94
zichtbaar. Als bijkomend voordeel kan een transactie automatisch worden teruggedraaid, en worden de wijzigingen automatisch teruggedraaid als in een transactie de verbinding van de gebruiker wegvalt . Fulltext index. De engine moet fulltext index ondersteunen [? ]. Dit houdt in dat elk textveld (VARCHAR, CHAR, TEXT) wordt gezien als een veld wat een text bevat. Deze text kan bestaan uit verschillende woorden. Voor elk woord dat langer is dan drie characters wordt een speciale index aangemaakt, zodat deze snel kan worden gevonden. Met behulp van speciale queries is het mogelijk om naar een woord te zoeken dat deel is van een record. Het gezochte woord moet wel minimaal vier letters bevatten, want elke substring van drie characters of minder wordt automatisch genegeerd. Hierdoor is het mogelijk om in een grote hoeveelheid text zeer snel te zoeken
3.3
Mogelijke oplossingen
In deze paragraaf wordt elke engine besproken aan de hand van de gestelde criteria in paragraaf 3.2. Om de hoeveelheid gegevens enigszins te beperken, is de vergelijking van de engines beperkt tot een bespreking van de criteria. Andere criteria worden buiten beschouwing gelaten, behalve als deze grote voor- of nadelen opleveren wat betreft het gebruik in de applicatie.
3.3.1
MyISAM
MyISAM is de standaard database-engine van MySQL. MyISAM is zijn populariteit vooral te danken aan zijn eenvoudige ontwerp en uitgebreide documentatie. Wat betreft de functionaliteit doet MyISAM onder voor engines zoals InnoDB, maar de functionaliteit die wordt aangeboden sluit wel aan bij de eisen van een groot deel van de gebruikers. Naar verwachting zal MyISAM de komende jaren de standaard database blijven. Echter, met MyISAM is het niet mogelijk om primary key/foreign key constraints [? ] te gebruiken. Hierdoor moet bij aanpassing van records met de primary key, de records met de foreign key met een algoritme in de applicatie worden aangepast. Voor grote databases kan dit tot onnodig complexe algoritmes in de applicatie leiden. Ook zijn transacties met MyISAM niet mogelijk [? ]. Hierdoor is het onmogelijk om database bewerkingen ongedaan te laten maken door de engine. Echter, met MyISAM is het wel mogelijk om gebruik te maken van fulltext index [? ]. Dit maakt MyISAM dus zeer geschikt voor databases die vooral gericht zijn op het zoeken in grote hoeveelheden tekstuele data. Tabel 3.1: Beoordelingsmatrix database-engine MyISAM Criteria Beschikbaarheid PK/FK constraints Transacties
Beoordeling ++ ---
Beschrijving MyISAM is de populairste MySQL database-engine De applicatie moet deze zelf forceren De applicatie moet zelf bijhouden hoe een verandering ongedaan worden gemaakt Fulltext index ++ MyISAM biedt standaard support voor fulltext index De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/-
95
3.3.2
InnoDB
InnoDB is een van de database-engines in MySQL. InnoDB is minder populair dan MyISAM, maar levert meer functionaliteit. Historisch gezien was MyISAM sneller met de afhandeling van SELECT-statements dan InnoDB, dus had in het verleden vaak de voorkeur. Tegenwoordig is InnoDB sneller, en begint door zijn functionaliteit steeds populairder te worden. Naar verwachting zal InnoDB de komende jaren in populariteit toenemen. Met InnoDB is het mogelijk om gebruik te maken van primary key/foreign key constraints [? ]. Hierdoor is het mogelijk om bij het bestaan van een persoon-tabel, en verschillende gerelateerde ondergeschikte tabellen, dat als de record van een persoon wordt verwijderd, de records in de gerelateerde tabellen ook verdwijnen. Hierdoor blijft de database consistent, zonder dat de applicatie dit zelf hoeft te forceren. Tevens is het mogelijk om met InnoDB transacties [? ] uit te voeren. Hierdoor kan bijvoorbeeld een UPDATE-query worden uitgevoerd, en ziet alleen de gebruiker het resultaat. De wijzigingen worden in de database opgeslagen als de gebruiker de query commit. Ook is het mogelijk om een bewerking terug te draaien, een zogenaamde ROLLBACK. Het terugdraaien van de bewerkingen vindt automatisch plaats als de verzender zijn verbinding verliest met de database tijdens de transactie. Echter, met InnoDB is het niet mogelijk om fulltext index te gebruiken [? ]. Als deze functionaliteit gewenst is, dan kan een enkele tabel ook op MyISAM worden gezet, of kan elk record apart worden opgehaald en geparsed voor het gezochte woord. In dat geval zullen de primary key/foreign key constraints met die tabel wel door een applicatie moeten worden geforceerd. Tabel 3.2: Beoordelingsmatrix database-engine InnoDB Criteria Beoordeling Beschrijving Beschikbaarheid + InnoDB is een populaire MySQL database-engine PK/FK constraints ++ De constraints worden door de engine geforceerd Transacties ++ InnoDB ondersteunt transacties Fulltext index -InnoDB ondersteunt geen fulltext index De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/-
3.3.3
BerkeleyDB
BerkeleyDB is een van de database-engines in veel versies van MySQL. Wat betreft de functionaliteit is deze beter dan MyISAM, maar minder dan InnoDB. Sinds versie 5.1.12 van MySQL, is BerkeleyDB uit het pakket verwijderd [? ]. Om geen constraints op te leggen aan de versie van MySQL op de server waarop de database komt te draaien, is besloten BerkeleyDB niet te gebruiken.
96
3.4
Oplossing
In de voorgaande paragrafen zijn verschillende engines onderzocht. Uit de evaluatie van deze engines zijn een aantal conclusies te trekken: 1. MyISAM is een standaardoplossing, die in de meerderheid van de gevallen voldoet. Echter voor de applicatie zijn primary key/foreign key constraints vereist, en voor MyISAM zouden deze dan via de applicatie moeten worden geforceerd 2. InnoDB scoort op bijna alle fronten maximaal. Fulltext index is in InnoDB echter niet mogelijk. In de applicatie zal niet vaak een substring van een record worden gezocht, dus het ophalen van elk record om hierachter te komen vormt geen probleem 3. BerkeleyDB wordt al enkele jaren niet meer ondersteund, en zit sinds release 5.1.12 niet meer in het MySQL pakket Het gebruik van InnoDB voor de applicatie is aan de hand van de criteria de beste oplossing, zoals weergegeven in figuur 3.3. In deze vergelijking is BerkeleyDb buiten beschouwing gelaten, omdat hiervoor door MySQL geen support meer wordt gegeven. Tabel 3.3: Beoordelingsmatrix oplossingen Criteria MyISAM Beschikbaarheid ++ PK/FK constraints -Transacties -Fulltext index ++ De schaal van de beoordeling loopt van - - tot ++.
InnoDB + ++ ++ -Neutraal wordt aangegeven met +/-
97
Hoofdstuk 4
Webtalen Voor dit project wordt er gebruik van een vari¨eteit aan webtalen. Er is gekozen voor HTML5, PHP, CSS, JavaScript en XML. Om tot deze keuze te komen zijn er een aantal afwegingen gemaakt, zoals ”moet het programma op een server draaien, of op de computer zelf?”. De verschillende afwegingen zullen hieronder worden behandeld.
4.1
HTML5
In 2007 was er een strijd over de opvolger van HTML 4. Hiervoor werd door de W3C gekozen voor XHTML en door de WHATWG voor HTML5. Deze laatste is inmiddels geaccepteerd door de W3C, en is inmiddels gekozen tot opvolger van HTML4 [? ]. Voor dit project is gekozen voor HTML5. Aangezien de site waarschijnlijk langere tijd in de lucht zal moeten blijven, wordt er gebruik gemaakt van de nieuwste standaard. De reden dat er gekozen is voor HTML heeft te maken met het feit dat HTML een goed gedocumenteerde taal is, waarin eenvoudig een website te structureren is, en beide programmeurs hebben al ervaring met deze taal.
4.2
PHP
Voor PHP is gekozen omdat deze taal het mogelijk maakt dynamisch websites te generen. Via PHP is het mogelijk om gegevens uit een database te lezen en deze vervolgens op de site te verwerken. Daarnaast kunnen formulieren etc. ook per direct verwerkt worden. Hierdoor is het mogelijk om direct en dynamisch met gegevens te werken. Er zit echter wel een nadeel aan PHP. Aangezien de de compiler op een server draait en niet lokaal, kunnen bewerkingen alleen gedaan worden als er een nieuwe request bij de server gedaan wordt. Een request vindt bijvoorbeeld plaats als een gebruiker de verzend-knop indrukt. Hierdoor zullen gegevens alleen verwerkt kunnen worden bij het aanroepen van een nieuwe pagina, en niet werkelijk on-the-fly. Voor de meeste situaties is dit niet nodig, maar voor bijvoorbeeld het checken van de invoer kan dit onnodig gebruik van resources opleveren. Om dit probleem te ondervangen wordt JavaScript gebruikt om PHP aan te vullen.
98
4.3
CSS
In de oudere versies van HTML bestond de mogelijkheid om de opmaak ook meteen in de HTML files te verwerken. Dit leverde echter problemen op bij hergebruik van code [? ], omdat opmaakcode in de files kwam te staan. Vanwege deze reden wordt CSS gebruikt. Deze sheets bevatten de informatie voor de verschillende HTML elementen, zoals bijvoorbeeld de breedte, border-width. Door deze sheets te gebruiken hoeft in dit project maar een beperkt aantal externe stylesheet gemaakt te worden, waardoor de site een universele uitstraling heeft, en de overige programmeercode beter hergebruikt kan worden.
4.4
JavaScript
Om de formulieren die gebruikt worden bij het invullen van gegevens tijdig te kunnen controleren, en directe feedback te kunnen geven aan de gebruiker, wordt gebruik gemaakt van JavaScript. Dit is een scripttaal die op de computer van de gebruiker wordt uitgevoerd. Hierdoor kunnen acties per direct worden uitgevoerd. Er kan bijvoorbeeld gekeken worden naar toetsaanslagen, en op basis daarvan acties worden ondernomen. JavaScript dient echter alleen gebruikt te worden om het gebruik van de PHP-server te verlichten. JavaScript kan namelijk worden uitgeschakeld, wat zou kunnen leiden tot beveiligingsrisico’s. Deze functionaliteit zal dus voornamelijk gebruikt gaan worden voor het controleren of de invoer in een veld niet te lang is en hierover feedback teruggeven naar de gebruiker.
4.5
XML
Voor sommige gegevens zal geen gebruik gemaakt kunnen, of hoeven, worden van de database. In dit soort gevallen kan gebruik gemaakt worden van XML files. Dit zijn kleine bestanden die in principe in plain text op de server staan. De informatie die in deze file staan zijn bijvoorbeeld universiteiten die meedoen aan het project en hun logo’s etc. Het voordeel van XML in vergelijking met plain text, is dat XML een vastgestelde structuur heeft. Elk element krijgt een bepaalde tag mee. Hierdoor is het eenvoudiger, en minder foutgevoelig, om data terug te vinden. Men kan immers nieuwe informatie toevoegen, zonder dat de structuur verloren gaat.
99
Hoofdstuk 5
Transport Layer Security Bij het gebruik van de applicatie, zal privacygevoelige informatie worden verzonden door de gebruiker. Om te voorkomen dat deze in verkeerde handen valt, is het noodzakelijk dat de verbinding beveiligd is. Transport Layer Security (TLS) biedt hierbij de uitkomst. TLS is de opvolger van Secure Socket Layer (SSL). Met behulp van TLSl is het mogelijk om een beveiligde verbinding op te stellen tussen een client en server met behulp van cryptographie. Voor encryptie wordt gebruik gemaakt van het RSA algoritme met een key van 1024 of 2048 bit [? ]. Bij SSL was het alleen mogelijk dat de server zich valideerde met behulp van een certifaat [? ]. De client werd echter niet gevalideerd. In TLS zijn zowel verbindingen met, en zonder, clientverificatie mogelijk. In onze applicatie hoeft alleen de server te worden gevalideerd.
5.1
Opstellen van een TLS verbinding
Om een TLS, of SSL, verbinding te gebruiken, moet deze eerst worden opgesteld. Als de verbinding eenmaal is gemaakt, dan is alle data die wordt verzonden via de verbinding automatisch versleuteld [? ]. Het opstellen van de verbinding bestaat uit vier fases. Hieronder wordt een vereenvoudigde versie van het protocol besproken. Hierbij is de resumed handshake [? ] weggelaten, en wordt er vanuit gegaan dat alleen de server geauthenticeerd hoeft te worden, en de server voorkeur heeft voor een beveiligde en geauthenticeerde verbinding. 1. Onderhandelingsfase . Hierbij stuurt de client een zogenaamd ClientHello bericht [? ] met de volgende informatie: – Hoogste versie van TLS die ondersteund wordt door de client – Een lijst van CipherSuites [? ]. Een cipher suite is combinatie van encryptie, authenticatie, en een algoritme om een bericht te valideren. – Mogelijke compressie-algoritmen. . De server stuurt een ServerHello bericht [? ] met zijn voorkeur voor de items in de ClientHello message. . De server zendt een certificaat, dat geverifieerd is via een keten van geauthoriseerde websites, om zijn identiteit aan te tonen.
100
. De server zent een ServerHelloDone bericht [? ] om aan te tonen dat de onderhandeling voorbij is. . De client antwoord met een pakket met een PreMasterSecret [? ], public key, of niets, afhankelijk van de gekozen cipher. De PreMasterSecret wordt gebruikt door de client en server om eenzelfde key af te leiden, zonder dat deze daadwerkelijk verstuurd wordt. Om deze key af te leiden wordt het Diffie-Hellman algoritme [? ] gebruikt. 2. Client zendt ChangeCipherSpec . Het verzenden van de ChangeCipherSpec [? ] houdt in dat alles vanaf dat moment geauthenticeerd en versleuteld verloopt. . De client verzendt een geauthenticeerd en versleuteld bericht met een hash en een code om het bericht te valideren (Message Authentication Code [? ]) op basis van de vorige berichten van de handshake. . De server ontvangt het bericht en probeert het bericht te ontcijferen. Vervolgens worden de hash en MAC geverifieerd. Als de server hierin niet slaagt, dan is er iets fout gegaan tijdens het opstellen van de connectie, en zal dus opnieuw moeten worden opgesteld door de client. 3. Server zendt ChangeCipherSpec . Hierbij worden dezelfde stappen als bij “Client zendt ChangeCipherSpec” [? ] uitgevoerd, alleen zijn de rol van de client en server omgedraaid. 4. Verbinding opgesteld . Beide partijen zijn op de hoogte dat er een beveiligde, en geauthenticeerde, verbinding is opgesteld. De communicatie die vervolgens plaats zal vinden zal automatisch geauthenticeerd en beveiligd verlopen. De applicatie hoeft na het opstellen van de connectie dus geen speciale handelingen uit te voeren voor het verzenden van informatie.
5.2
Verkrijgen van een TLS/SSL Certificaat
Het certificaat wat bij SSL en TLS gebruikt wordt, moet van een betrouwbare bron komen. Het idee achter SSL en TLS is dat er enkele servers zijn die inherent betrouwbaar zijn, de zogenaamde certificate roots [? ]. Deze certificate roots verkopen het recht om certificaten uit te delen aan andere servers. Deze servers verkopen op hun beurt ook weer de rechten, of de certificaten zelf. Het gevolg is een keten van servers die elkaar verifi¨eren. Hoe verder men van de root af gaat, hoe onbetrouwbaarder de server. Een certificaat is essentieel voor het opstellen van een SSL of TLS verbinding, omdat deze aantoont dat de site betrouwbaar is. Het is mogelijk om zelf een certificaat te maken, zogenaamde self-signed certificaten [? ], maar dit is equivalent aan een persoon die van zichzelf zegt dat hij betrouwbaar is. Het gevolg is dat de gebruikers van de website bij het opstarten van de site een melding krijgen dat het certificaat niet betrouwbaar is. Als een SSL of TLS website door een persoon wordt bezocht, dan controleert de browser van deze persoon de keten van certificaten. Dit is mogelijk, omdat browsers initieel de adressen van vele certificate roots bezitten, maar ook omdat de server de certificaten van alle bovenstaande servers dient te bevatten. Het gevolg is een web van betrouwbare servers.
101
Voor de applicatie is een SSL of TLS verbinding vereist, omdat paswoorden worden verzonden, en de encryptie serverside plaatsvindt met PHP (SHA1). Het is geen probleem als een paswoord van een kandidaat wordt verkregen, gezien de mogelijkheden van de kandidaat beperkt zijn, maar het verkrijgen van een paswoord van een commissie kan grote schade veroorzaken. Na het vergelijken van verschillende aanbieders van certificaten, waaronder VeriSign, GoDaddy, en Comodo, is besloten dat er een keuzemenu moet worden opgesteld, zodat de partners van het project kunnen selecteren. Echter, aan de hand van commentaar op het blog, bleek dat de SURFnet aangesloten is bij Terena, en het recht heeft om abonnementen op het aanvragen van certificaten te verstrekken [? ]. De TU Delft is hierbij ook aangesloten, waardoor deze voor een relatief klein bedrag per maand, onbeperkt certificaten mag aanvragen. Daarom is geprobeerd een testserver via de TU Delft aan te vragen. Dit bleek echter niet mogelijk, omdat een certificaat voor slechts een paar maanden niet gebruikelijk is. Momenteel moet nog bepaald worden waar de server uiteindelijk komt te draaien, echter als men wil profiteren van de SURFnet-regeling, dan zal dit moeten bij SURFnet zelf, of bij een van zijn leden (de meeste universiteiten en hogescholen in Nederland).
102
Hoofdstuk 6
Conclusie Bij het cre¨eren van de applicatie traden verschillende problemen op. In dit document zijn de verschillende mogelijke oplossingen geanalyseerd. In tabel 6.1 worden de verschillende problemen en de gekozen oplossingen weergegeven. Tabel 6.1: Gekozen oplossing voor elk probleem Probleem Encryptie lokale gegevens
Oplossing Encrypted serialization, hierbij wordt een object versleuteld met een key die gebaseerd is op de loginname en paswoord, en vervolgens opgeslagen op de harde schijf. Het object kan opnieuw bekeken worden door deze te decoderen met behulp van de sleutel
Database-engine
InnoDB, deze database-engine is de enige engine die niet deprecated is in het MySQL pakket aan de TU Delft, en PK/FK constraints mogelijk maakt. Ook kan gebruik gemaakt worden van transacties en is de engine populair
Webtalen
Om correct te functioneren met toekomstige browsers, zal gebruik worden gemaakt van standaard webtalen HTML5, PHP, CSS, JavaScript en XML
Transport Layer Security
TLS zal gebruikt worden om een beveiligde verbinding op te stellen. Hiervoor zal een certificaat moeten worden aangevraagd
103
Bijlage A
Serialization 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
import import import import import import import import import import import import import
j a v a . i o . ByteArrayOutputStream ; java . io . F i l e ; java . io . FileInputStream ; j a v a . i o . FileOutputStream ; j a v a . i o . IOException ; j a v a . i o . Ob j e ctI nput Str ea m ; j a v a . i o . ObjectOutputStream ; java . s e c u r i t y . InvalidKeyException ; j a v a . s e c u r i t y . NoSuchAlgorithmException ; java . u t i l . ArrayList ; j a v a x . c r y p t o . Cipher ; j a v a x . c r y p t o . NoSuchPaddingException ; javax . crypto . spec . SecretKeySpec ;
/∗ ∗ ∗ Code i s f o r t e s t i n g and e x p l i n a t i o n p u r p o s e s , so no s p e c i a l a t t e n t i o n ∗ was p a i d t o t h e s t r u c t u r e . ∗ ∗ @author Mark He ndri k x ∗/ public c l a s s Main { /∗ ∗ ∗ Main c l a s s w r i t t e n t o t e s t a l l t h e o b j e c t s e r i a l i z a t i o n methods . ∗ These t e s t a r e f o c u s s e d on an A r r a y L i s t <S t r i n g > o b j e c t , b u t i t c o u l d ∗ have been any t y p e o f o b j e c t . ∗/ public s t a t i c void main ( S t r i n g [ ] a r g s ) throws IOException { A r r a y L i s t <S t r i n g > t e s t A r r a y = new A r r a y L i s t <S t r i n g > ( ) ; t e s t A r r a y . add ( ” t e s t 1 ” ) ; t e s t A r r a y . add ( ” t e s t 2 ” ) ; t e s t A r r a y . add ( ” t e s t 3 ” ) ; String filename = ” test . txt ” ; System . out . p r i n t l n ( ” Test : o b j e c t −> f i l e ” ) ; serializeAndWriteToFile ( testArray , filename ) ; F i l e t e s t = new F i l e ( ” t e s t . t x t ” ) ;
104
38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90
if ( test . exists ()) System . out . p r i n t l n ( ”PASS\n” ) ; else System . out . p r i n t l n ( ”FAIL\n” ) ; System . out . p r i n t l n ( ” Test : f i l e −> o b j e c t ” ) ; A r r a y L i s t <S t r i n g > t e s t A r r a y 2 = u n s e r i a l i z e F r o m F i l e ( f i l e n a m e ) ; i f ( testArray2 . equals ( testArray )) System . out . p r i n t l n ( ”PASS\n” ) ; else System . out . p r i n t l n ( ”FAIL\n” ) ; byte [ ] b y t e s = s e r i a l i z e T o B y t e s ( t e s t A r r a y ) ; byte [ ] b y t e s 2 = null ; System . out . p r i n t l n ( ” Test : o b j e c t −> b y t e a r r a y −> e n c r y p t AES −> ” + ” d e c r y p t AES” ) ; try { b y t e s 2 = doDecrypt ( doCrypto ( b y t e s , ” t e s t t e s t t e s t t e s t ” ) , ” testtesttesttest ”); } catch ( E x c e p t i o n ex ) { ex . p r i n t S t a c k T r a c e ( ) ; } i f (new S t r i n g ( b y t e s ) . e q u a l s (new S t r i n g ( b y t e s 2 ) ) ) System . out . p r i n t l n ( ”PASS ! \ n” ) ; else System . out . p r i n t l n ( ”FAIL ! \ n” ) ;
}
A r r a y L i s t <S t r i n g > t e s t A r r a y 3 = ( A r r a y L i s t <S t r i n g >) t o O b j e c t ( b y t e s 2 ) ; System . out . p r i n t l n ( ” Test : o b j e c t −> b y t e a r r a y −> e n c r y p t AES −> ” + ” d e c r y p t AES −> o b j e c t ” ) ; i f ( testArray3 . equals ( testArray )) System . out . p r i n t l n ( ”PASS ! \ n” ) ; else System . out . p r i n t l n ( ”FAIL ! \ n” ) ;
/∗ ∗ ∗ Method t h a t u n s e r i a l i z e s an o b j e c t t h a t i s r e a d from a ∗ s u p p l i e d f i l e n a m e . The method i s w r i t t e n so t h a t i t r e t u r n ∗ an A r r a y L i s t <S t r i n g >, b u t i t c o u l d have been any t y p e o f o b j e c t . ∗ @param f i l e n a m e name o f t h e s u p p l i e d t e x t f i l e ∗ @return u n s e r i a l i z e d A r r a y L i s t <S t r i n g > ∗/ public s t a t i c A r r a y L i s t <S t r i n g > u n s e r i a l i z e F r o m F i l e ( S t r i n g f i l e n a m e ) { A r r a y L i s t <S t r i n g > l i s t = new A r r a y L i s t <S t r i n g > ( ) ; try { F i l e I n p u t S t r e a m f i n = new F i l e I n p u t S t r e a m ( f i l e n a m e ) ; Ob je c tI npu tStr eam o i s = new O bj e ct I n p ut S t re a m ( f i n ) ; l i s t = ( A r r a y L i s t <S t r i n g >) o i s . r e a d O b j e c t ( ) ; ois . close (); } catch ( E x c e p t i o n e ) { e . p r i n t S t a c k T r a c e ( ) ; } return l i s t ; }
105
91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143
/∗ ∗ ∗ S e r i a l i z e a A r r a y L i s t −o b j e c t t h a t i s g i v e n as i n p u t , and ∗ w r i t e t h e o u t p u t t o f i l e . The A r r a y l i s t i s u s ed as an example , ∗ b u t i t c o u l d have been any t y p e o f o b j e c t . ∗ @param l i s t t h e l i s t t h a t i s s e r i a l i z e d ∗ @param f i l e n a m e name o f t h e f i l e t o which t h e s e r i a l i z e d o b j e c t ∗ is written ∗ @throws IOE x c e pti on ∗/ public s t a t i c void s e r i a l i z e A n d W r i t e T o F i l e ( A r r a y L i s t <S t r i n g > l i s t , S t r i n g f i l e n a m e ) throws IOException { FileOutputStream f o u t = null ; try { f o u t = new FileOutputStream ( f i l e n a m e ) ; } catch ( E x c e p t i o n e ) { e . p r i n t S t a c k T r a c e ( ) ; } ObjectOutputStream o o s = null ; try { o o s = new ObjectOutputStream ( f o u t ) ; } catch ( E x c e p t i o n e ) { e . p r i n t S t a c k T r a c e ( ) ; } oos . writeObject ( l i s t ) ; oos . c l o s e ( ) ; } /∗ ∗ ∗ This method s e r i a l i z e s an o b j e c t an c o n v e r t s i t i n t o raw b y t e s . ∗ @param l i s t t h e l i s t t h a t i s s e r i a l i z e d ∗ @return t h e l i s t s e r i a l i z e d and c o n v e r t e d i n t o b y t e s ∗ @throws IO E xc e pti on ∗/ public s t a t i c byte [ ] s e r i a l i z e T o B y t e s ( A r r a y L i s t <S t r i n g > l i s t ) throws IOException { ByteArrayOutputStream f o u t = null ; try { f o u t = new ByteArrayOutputStream ( ) ; } catch ( E x c e p t i o n e ) { e . p r i n t S t a c k T r a c e ( ) ; } ObjectOutputStream o o s = null ; try { o o s = new ObjectOutputStream ( f o u t ) ; } catch ( E x c e p t i o n e ) { e . p r i n t S t a c k T r a c e ( ) ; } oos . writeObject ( l i s t ) ; oos . c l o s e ( ) ; return f o u t . toByteArray ( ) ; } /∗ ∗ ∗ Encrypt a g i v e n b y t e a r r a y . ∗ @param message what i s t o be e n c r y p t e d
106
144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196
∗ @param password t h e k e y us ed t o e n c r y p t t h e message ∗ @return e n c r y p t e d message ∗ @throws N oS uc h Al g or i t h m E x c e p t i o n ∗ @throws I n v a l i d K e y E x c e p t i o n ∗/ public s t a t i c byte [ ] doCrypto ( byte [ ] message , S t r i n g password ) throws NoSuchAlgorithmException , I n v a l i d K e y E x c e p t i o n { // Generate a key , t h i s a random k e y . Use 128 b y t e as key , // b e c a u s e 192 and 256 a r e n o t a l l o w e d e v e r y w h e r e . // h t t p : / / j a v a . sun . com/ d e v e l o p e r / // t e c h n i c a l A r t i c l e s / S e c u r i t y /AES/AES v1 . h t m l byte [ ] raw = null ; i f ( password . l e n g t h ()==16){ raw = password . g e t B y t e s ( ) ; } else { System . out . p r i n t l n ( ” F a i l u r e , password s h o u l d be 16 l e t t e r s . ” ) ; return null ; } // S e c r e t K e y S p e c i s a c o n t a i n e r o b j e c t t o s t o r e t h e k e y // combined w i t h a t y p e o f e n c r y p t i o n S e c r e t K e y S p e c s k e y S p e c = new S e c r e t K e y S p e c ( raw , ”AES” ) ; // I n s t a n t i a t e t h e c i p h e r Cipher c i p h e r = null ; try { c i p h e r = Cipher . g e t I n s t a n c e ( ”AES” ) ; } catch ( NoSuchPaddingException ex ) { ex . p r i n t S t a c k T r a c e ( ) ; } c i p h e r . i n i t ( Cipher .ENCRYPT MODE, s k e y S p e c ) ; byte [ ] e n c r y p t e d = null ; try { e n c r y p t e d = c i p h e r . d o F i n a l ( message ) ; } catch ( E x c e p t i o n ex ) { ex . p r i n t S t a c k T r a c e ( ) ; } return e n c r y p t e d ; } /∗ ∗ ∗ De c r ypt a message s t o r e d i n a b y t e a r r a y g i v e n t h e k e y . ∗ @param e n c r y p t e d M e s s a g e t h e message t h a t i s e n c r y p t e d ∗ @param password t h e password u s ed t o d e c r y p t t h e message ∗ @return t h e d e c r y p t e d message ∗/ public s t a t i c byte [ ] doDecrypt ( byte [ ] encryptedMessage , S t r i n g password ) { byte [ ] raw = null ; i f ( password . l e n g t h ()==16){ raw = password . g e t B y t e s ( ) ; } else { System . out . p r i n t l n ( ” F a i l u r e , password s h o u l d be 16 l e t t e r s . ” ) ; return null ;
107
197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228
} S e c r e t K e y S p e c s k e y S p e c = new S e c r e t K e y S p e c ( raw , ”AES” ) ; Cipher c i p h e r = null ; try { c i p h e r = Cipher . g e t I n s t a n c e ( ”AES” ) ; } catch ( E x c e p t i o n ex ) { ex . p r i n t S t a c k T r a c e ( ) ; } try { c i p h e r . i n i t ( Cipher .DECRYPT MODE, s k e y S p e c ) ; } catch ( E x c e p t i o n ex ) { ex . p r i n t S t a c k T r a c e ( ) ; } byte [ ] o r i g i n a l = null ; try { o r i g i n a l = c i p h e r . d o F i n a l ( e n c r y p t e d M e s s a g e ) ; } catch ( E x c e p t i o n ex ) { ex . p r i n t S t a c k T r a c e ( ) ; } return o r i g i n a l ; } /∗ ∗ ∗ Method t o c o n v e r t a b y t e a r r a y t o an o b j e c t ∗ @param b y t e s b y t e a r r a y t h a t s y m b o l i z e s an o b j e c t ∗ @return o b j e c t c r e a t e d from b y t e a r r a y ∗/ public s t a t i c Obj e ct t o O b j e c t ( byte [ ] b y t e s ) { Obj e ct o b j e c t = null ; try { o b j e c t = new j a v a . i o . Ob j e ct I n pu t S t re am (new j a v a . i o . ByteArrayInputStream ( b y t e s ) ) . r e a d O b j e c t ( ) ; } catch ( E x c e p t i o n ex ) { ex . p r i n t S t a c k T r a c e ( ) ; } return o b j e c t ; }
}
108
Bijlage C
Implementation document
109
Voorwoord Dit document is tot stand gekomen als implementatie document voor werkpakket 4A van het “Alle H@nds Aan Dek” project in opdracht van de Universitaire Leraren Opleidingen. In dit rapport vindt u de motivatie voor de keuzes die zijn gemaakt in de implementatie van onze applicatie. Tijdens het project is bij grote keuzes regelmatig overleg met de verschillende betrokken partijen. Wij danken de partners van het project voor hun feedback. Wat betreft de verificatie van het databasediagram is verschillende malen contact opgenomen met onze begeleider dhr. de Bruin. Dankzij zijn feedback zijn enkelel fouten, die initieel in het databasediagram zaten, verbeterd. Wij danken hem voor zijn feedback. Mark Hendrikx Olaf Sch¨ usler
110
Hoofdstuk 1
Inleiding Om in de bovenbouw van de middelbare school les te geven, moet je beschikken over een eerstegraads bevoegdheid. Deze kun je behalen door de universitaire lerarenopleiding te volgen. Om tot de lerarenopleiding toegelaten te worden, moet je contact opnemen met een van de toelatingscommissies van de ULO (Universitaire Leraren Opleiding). Deze vraagt vervolgens welke opleidingen je hebt afgesloten, en welke werkervaring je bezit. Deze gegevens, en andere, worden gebruikt om een advies op te stellen over de te volgen vakken om toegang te verkrijgen tot een ULO. In het design document is in de probleemanalyse geconstateerd dat in de huidige situatie onnodig veel werk wordt verricht om een advies op te stellen. Het digitaliseren, en delen, van gegevens zou hierbij de uitkomst bieden. In het design document zijn de verschillende eisen aan de applicatie opgesteld. Dit document beschrijft de implementatie van deze eisen. Het domein waarvoor de applicatie is geschreven kent een unieke terminologie. Om dit document goed te begrijpen is het daarom aan te raden eerst de definitielijst door te lezen in bijlage B. In hoofdstuk 2 wordt het klassendiagram behandeld. Vervolgens wordt in hoofdstuk 3 het implementatieproces besproken. Hierna worden in hoofdstuk 4 de ontwerpkeuzes en belangrijkste schermen van de GUI beschreven. Vervolgens zullen in hoofdstuk 5 het databasediagram en de implementatie van de database worden behandeld. Vervolgens wordt in hoofdstuk 6 het testplan opgesteld, en de worden de resultaten in hoofdstuk 7 besproken. Tot slot zal in hoofdstuk 8 de conclusie worden behandeld. Wat betreft de bjilagen zal in bijlage A de planning worden behandeld. In bijlage B zal de terminologie van het applicatiedomein worden besproken.
111
Hoofdstuk 2
Klassendiagram In dit hoofdstuk zal het klassendiagram worden besproken. De controller-klassen van het klassendiagram worden in figuur 2.1 weergegeven. In figuur 2.2 zijn de model-klassen van het diagram weergegeven. Bij beide diagrammen zijn de public getters en setters, en enkele kleine klassen, weggelaten. In paragraaf 2.1 zullen de controller-klassen worden behandeld. Vervolgens zullen in paragraaf 2.2 de model-klassen uiteen worden gezet. Tot slot zullen in paragraaf 2.3 de view-klassen van het diagram, de websites, worden besproken. Voor alle diagrammen geldt dat het kandidaat- en admingedeelte volledig ge¨ımplementeerd zijn. Het commissiegedeelte van de applicatie zal later worden ge¨ımplementeerd. Echter de basis hiervan is al gedeeltelijk beschreven, en zal in dit hoofdstuk worden behandeld.
112
Figuur 2.1: Overzicht van de Controllerklassen van het klassendiagram. 113
Figuur 2.2: Overzicht van de modelklassen van het klassendiagram. 114
2.1
Controller-klassen
De controller-klassen zijn de klassen die gebruik maken de model-klassen om opdrachten, die via de view-klassen zijn opgegeven, uit te voeren. In onderstaande subparagrafen zullen de verschillende controller-klassen worden behandeld. De AdminController, CandidateController, en MemberController maken gebruik van de DatabaseController om de connectie met de database te handhaven. Tijdens het bachelorproject zijn de AdminController, CandidateController, en de DatabaseController ge¨ımplementeerd. De MemberController vormt geen onderdeel van het bachelorproject, en zal de komende maanden verder worden ge¨ımplementeerd.
2.1.1
AdminController
De AdminController bevat de methodes die gericht zijn op de admin. In onderstaande tabel worden de verschillende methodes uiteengezet.
Methode
Functionaliteit
addArea
Methode voor het toevoegen van een schoolvak met een voorkeur voor kern- of subdomeinen aan de database. Een schoolvak wordt alleen toegevoegd als deze nog niet bestaat. Methode voor het toevoegen een comit´e met een secretaris aan de database. De overige leden kunnen een account aanmaken wat door de secretaris zal worden geverifieerd. Een comit´e wordt alleen toegevoegd als deze nog niet bestaat. Methode voor het verbannen van een gebruiker. Een verbande gebruiker kan niet inloggen. Methode die gebruikt wordt om te bekijken of een mailadres en paswoord corresponderen aan een admin in de database. Deze methode wordt gebruikt om een admin in te loggen. Methode die gebruikt wordt om te bekijken of een schoolvak in de database bekend is. Deze methode wordt gebruikt bij het aanmaken van een nieuw schoolvak. Methode die gegeven een areaID en universityID bekijkt of een comit´e al in de database voorkomt. Private methode voor het aanmaken van een AdminController. Er wordt gebruik gemaakt van het Singleton pattern om ervoor te zorgen dat slechts ´e´en controller kan worden aangemaakt. Statische methode voor het aanmaken van AdminController als deze niet al bestaat. Als er al een AdminController-object bestaat, dan wordt deze geretourneerd. Methode voor het toevoegen van een nieuwe admin aan de database. Een admin wordt alleen toegevoegd als deze nog niet bestaat.
addCommittee
banActor checkAdmin
checkArea
checkCommittee construct
getInstance
registerAdmin
115
registerFullAdmin toString unbanActor updateAreaDomainpreference
2.1.2
Zelfde methode als registerAdmin, alleen kan ook een extra datum worden gespecificeerd die als registratiedatum wordt gebruikt. Methode die een string-representatie retourneert van het AdminController-object. Methode die het verbannen van een gebruiker ongedaan maakt. Deze bewerking is alleen mogelijk als de gebruiker verbannen is. Update de voorkeur van een schoolvak naar kern- of subdomeinen.
CandidateController
Deze controller bevat de methodes die gericht zijn op de kandidaat. In onderstaande tabel worden de verschillende methodes uiteengezet.
Methode
Functionaliteit
candidateExists checkCandidate
Methode om na te gaan of een kandidaat in de database bestaat. Methode die gebruikt wordt om te bekijken of een mailadres en paswoord corresponderen aan een kandidaat in de database. Deze methode wordt gebruikt om een kandidaat in te loggen. Methode om te bekijken of een kandidaat bij een commissie een aanvraag heeft ingediend. Private methode voor het aanmaken van een CandidateController. Er wordt gebruik gemaakt van het Singleton pattern om ervoor te zorgen dat slechts ´e´en controller kan worden aangemaakt. Private methode voor het aanmaken van een Candidate-object. Private methode die gebruikt wordt om een array van Courseobjecten te maken. Private methode die gebruikt wordt om een CoursesCollectionobject te maken. Private methode die gebruikt wordt om een array van Mappingobjecten te maken uit het resultaat van een SQL-query. Private methode die gebruikt wordt om een array van Requestobjecten te maken uit het resultaat van een SQL-query. Private methode voor het ophalen van specialization, courses, of follow up courses aan de hand van een gegeven vakkenpakketID, bijvoorbeeld een specializationID. Tevens worden de mappingen van de courses opgehaald. Hierbij is het mogelijk om alle mappingen op te laten halen, of alleen degene van een bepaald comit´e. Methode die een Candidate-object retourneert met de gegevens van de kandidaat waarvan het candidateID is opgegeven. Methode die een Candidate-object retourneert met de gegevens van de kandidaat waarvan het mailadres is opgegeven. Methode die de basisgegevens van alle kandidaten retourneert. Methode die de basisgegevens van alle kandidaten retourneert tussen een start- en einddatum.
checkRequest construct
createCandidate createCourses createCoursesCollection createMapping createRequest fetchCourses
getCandidateByID getCandidateByMail getCandidateList getCandidateListDates
116
getHistoricalCandidateList
Methode die de basisgegevens van alle historische kandidaten retourneert. getHistoricalCandidateListDates Methode die de basisgegevens van de historische kandidaten retourneert tussen een start- en einddatum getInstance Statische methode voor het aanmaken van CandidateController als deze niet al bestaat. Als er al een CandidateController-object bestaat, dan wordt deze geretourneerd. insertCourse Methode voor het toevoegen van een vak aan de database. insertCourseAndMapping Methode voor het toevoegen van een vak en een corresponderende mapping aan de database. insertCourseIDArrayInCourses Methode voor het toevoegen van een array van vakken aan een vakkenpakket in de database. insertCourseIDArrayInFollowUp- Methode die gegeven een array van vakken, en een folCourses low up coursesID, de aangegeven vakken opslaat als geadviseerde vakken. insertCoursesCollection Methode voor het toevoegen van een vakkenpakket aan de database. insertMapping Methode voor het toevoegen van een mapping aan de database. insertRequest Methode voor het toevoegen van een aanvraag aan de database. insertRequestFromObject Methode voor het toevoegen van een aanvraag aan de database op basis van een Request-object. loadCourses Methode voor het opstellen van een SQL-query voor het ophalen van de courses, die gerelateerd zijn aan aan het opgegeven coursesID. loadCoursesCollection Methode voor het opstellen van een SQL-query voor het ophalen van de CoursesCollections, die gerelateerd zijn aan het opgegeven candidateID. loadFollowUpCourses Methode voor het opstellen van een SQL-query voor het ophalen van de geadviseerde vakken, die gerelateerd zijn aan het opgegeven follow up coursesID. loadMapping Methode voor het opstellen van een SQL-query voor het ophalen van een mapping. loadRequests Methode voor het opstellen van een SQL-query voor het ophalen van de aanvragen, die gerelateerd zijn aan het opgegeven candidateID. loadSpecialization Methode voor het opstellen van een SQL-query voor het ophalen van de gespecialiseerde vakken, die gerelateerd aan het opgegeven specializationID. registerCandidate Methode voor het toevoegen van een nieuwe kandidaat aan de database. Een kandidaat wordt alleen toegevoegd als deze nog niet bestaat. registerFullCandidate Methode voor het toevoegen van een nieuwe kandidaat aan de database. Het verschil met registerCandidate is dat de EVC, de logindatum, en het wel/niet historisch zijn van het gegeven, mee kunnen worden gegeven.
117
registerHistoricalCandidate
removeCandidateByMail storeCourses storeCoursesCollection toString updateCandidate updateCandidates
2.1.3
Methode voor het toevoegen van een historische kandidaat aan de database. Een kandidaat wordt alleen toegevoegd als deze nog niet bestaat. Methode voor het verwijderen van een kandidaat uit de database gegevens zijn mailadres. Private methode voor het opslaan van het resultaat van een SQLquery, voor het ophalen van vakken, in een array. Private methode voor het opslaan van het resultaat van een SQLquery, voor het ophalen studies, in een array. Methode die een string-representatie retourneert van het CandidateController-object. Methode die de wijzigingen van een Candidate-object doorvoert in de database. Methode die de wijzigingen van meerdere Candidate-objecten doorvoert in de database.
DatabaseController
De DatabaseController handhaaft de connectie met de database, en biedt door alle gebruikers gebruikt kunnen worden. In onderstaande tabel worden de verschillende methodes uiteengezet.
Methode
Functionaliteit
actorExists
Methode om te bekijken of een gebruiker met een bepaald mailadres voorkomt in de database. Deze methode wordt gebruikt om te voorkomen dat een mailadres tweemaal in de database wordt opgeslagen. Methode voor het toevoegen van een universiteit aan de database als deze nog niet bestaat Methode voor het veranderen van een paswoord op basis van een hash van het oude paswoord. Deze methode wordt gebruikt om een paswoord te veranderen met behulp van een link die naar de gebruiker wordt verstuurd als deze zijn paswoord is vergeten. Methode om te controleren of de key die wordt opgegeven door een gebruiker geldig is. Hiermee wordt voorkomen dat een link van de “paswoord vergeten” functie wordt aangepast om paswoorden van andere gebruikers te wijzigen. Methode om te bekijken of een gegeven universiteit in de database bestaat. Methode voor het opzetten van de connectie met de database. Private methode voor het aanmaken van een DatabaseController. Er wordt gebruik gemaakt van het Singleton pattern om ervoor te zorgen dat slechts ´e´en controller kan worden aangemaakt. Methode voor het afbreken van de connectie met de database. Methode voor het opvragen van de accountstatus van een gebruiker. Een account kan geactiveerd, niet geactiveerd, of verbannen zijn.
addUniversity changeForgottenPassword
checkActorKey
checkUniversity connect construct
disconnect getActorStatus
118
getAreaID getAreas getAuthorizationID getCities getCommitteeAreas getCommitteeID getCommittees getConnection getCourses getCoursesCollectionCount getDomainID getDomainPreferenceID getDomainPreferences getDomains getFollowUpCoursesID getHashedPassword
getInstance
getMatchingRequiredCourses
getMatchingRequiredCoursesMapping
Methode voor het ophalen van het ID van het schoolvak gegeven de naam van het schoolvak. Methode voor het ophalen van de namen van alle schoolvakken. Methode voor het ophalen van het id van een baan gegeven de naam van de baan. Methode voor het ophalen van de namen van alle steden. Methode voor het ophalen van de committeeID, universiteitsnaam, en schoolvak, van alle commissies. Methode voor het ophalen van het committeeID gegeven een areaID en universityID. Methode om alle comit´es uit de database op te halen en op te slaan in een array van Committee-objecten. Methode voor het ophalen van de connectie met de database. Methode voor het ophalen van de vakken behorend tot een opgegeven vakkenpakketid. Methode voor het ophalen van het aantal vakkenpakketten in de database voor een gegeven kandidaat. Methode voor het ophalen van het domainID gegeven de naam van het kern- of subdomein. Methode voor het ophalen van de voorkeur voor kern- of subdomeinen van een bepaald schoolvak. Methode die de mogelijke domeinvoorkeuren retourneert (kern- of subdomein). Methode die alle kern- of subdomeinen van een schoolvak retourneert. Methode die het vakkenpakketid van de geadviseerde vakken voor een gegeven aanvraag retourneert. Retourneert een gehashte versie van het paswoord van de kandidaat. De gehashte string wordt gebruikt als sleutel bij het wijzigen van een paswoord met behulp van de “paswoord vergeten”-functie. Statische methode voor het aanmaken van DatabaseController als deze niet al bestaat. Als er al een DatabaseController-object bestaat, dan wordt deze geretourneerd. Retourneert de vakkenpakketten waarvan de naam een opgegeven deelstring bevat. Van de vakkenpakketten is naast de basisgegevens ook het id van de verzameling van de verplichte vakken meegegeven. Retourneert de vakkenpakketten waarvan de naam een opgegeven deelstring bevat. Van de vakkenpakketten is naast de basisgegevens ook het id van de verzameling van de verplichte vakken meegegeven. In tegenstelling tot getMatchingRequiredCourses is de mapping van de geretourneerde vakkenpakketten gevalideerd door een toelatingscommissie.
119
getMatchingSpecializationCourses
getMatchingSpecializationCoursesMapping
getNewFollowUpCoursesID getRequestID getStudylevelID getStudylevels getUniversities getUniversityID isConnected loadCoursesCollections setPassword toString updateActorStatus
updateLogInTime
2.1.4
Retourneert de vakkenpakketten waarvan de naam een opgegeven deelstring bevat. Van de vakkenpakketten is naast de basisgegevens ook het id van de verzameling van de gespecialiseerde vakken meegegeven. Retourneert de vakkenpakketten waarvan de naam een opgegeven deelstring bevat. Van de vakkenpakketten is naast de basisgegevens ook het id van de verzameling van de gespecialiseerde vakken meegegeven. In tegenstelling tot getMatchingSpecializationCourses is de mapping van de geretourneerde vakkenpakketten gevalideerd door een toelatingscommissie. Methode die een uniek nummer retourneert voor het aanmaken van een nieuw vakkenpakket met geadviseerde vakken. Methode die het requestID van een kandidaat retourneert, gegeven de candidateID en de committeeID die bij het request horen. Methode die het studylevelID retourneert gegeven het bijbehorende opleidingsniveau. Methode voor het ophalen van alle opleidingsniveaus. Methode voor het ophalen van de namen van alle universiteiten. Methode voor het ophalen van het id van een universiteit gegeven de naam. Methode die retourneert of er een connectie met de database is. Methode die de namen van alle vakkenpakketten uit de database ophaalt. Methode voor het wijzigen van het paswoord van een gebruiker. Methode die een string-representatie retourneert van het DatabaseController-object. Methode waarmee de accountstatus van een account wordt ge¨ update. Mogelijke invoerwaarden zijn gevalideerd, niet gevalideerd, en verbannen. Methode waarmee de logintijd van de kandidaat wordt gezet naar de huidige datum. Deze methode zorgt ervoor dat het mogelijk is om te bepalen welke accounts niet meer gebruikt worden.
MemberController
De MemberController bevat de methodes die gericht zijn op het lid van de toelatingscommissie. In onderstaande tabel worden de verschillende methodes uiteengezet. De MemberController is een groot onderdeel van het commissiegedeelte, wat na het bachelorproject zal worden ge¨ımplenteerd. Onderstaande gegevens zijn daarom incompleet.
Methode
Functionaliteit
addMemberToCommittee
Methode voor het toevoegen van een gebruiker aan een comit´e met een bepaalde taak. Methode om na te gaan of een gebruiker lid is van een comit´e. Private methode voor het aanmaken van een MemberController. Er wordt gebruik gemaakt van het Singleton pattern om ervoor te zorgen dat slechts ´e´en controller kan worden aangemaakt.
checkMemberOfCommittee construct
120
createMember getInstance
memberExists registerFullMember registerMember toString
2.1.5
Private methode voor het aanmaken van een Member-object gegeven de parameters van het object. Statische methode voor het aanmaken van MemberController als deze niet al bestaat. Als er al een MemberController-object bestaat, dan wordt deze geretourneerd. Statische methode om te bepalen of een lid bestaat in de database. Deze methode wordt gebruikt bij het registeren van een nieuw lid. Methode om een gebruiker te registreren als lid. In vergelijking met registerMember kan de logindatum worden meegegeven. Methode om een gebruiker te registeren als lid. Methode die een string-representatie retourneert van het MemberController-object.
PageController
De PageController bevat de methodes die gericht zijn op het cre¨eren van een webpagina. In onderstaande tabel worden de verschillende methodes uiteengezet.
Methode
Functionaliteit
construct
Methode voor het aanmaken van een Page-object gegeven een paginatitel, diepte van de pagina, en enkele optionele argumenten die invloed hebben op de stijl. Methode voor het aanmaken van twee tekstveldkolommen, waarbij in de linkerkolom het vak staat, en in de rechterkolom een veld om de mapping(en) van het vak in te vullen. Methode voor het aanmaken van een datumselector. Hiervoor wordt een Javascript gebruikt die een kalender toont om de datum te selecteren. Methode voor het cre¨eren van een loginscherm voor een kandidaat, commissielid, of admin. Optioneel kan een argument worden meegegeven wat het formulier geschikt maakt als loginscherm voor alle gebruikers. Methode voor het cre¨eren van een HTML textinput, inclusief Javascript-code om het mailadres te verifi¨eren. Methode voor het cre¨eren van twee HTML selectors die elkaars keuzemogelijkheid be¨ınvloeden. Methode voor het cre¨eren van een HTML textinput voor de invoer van numierieke gegevens. Er wordt automatisch Javascript-code gegeneerd die de hoogte van het getal begrenst. Methode voor het cre¨eren van een HTML paswoordinput, inclusief Javascript-code om de lengte van de invoer te verifi¨eren. Methode voor het cre¨eren van een read-only HTML textarea. Methode voor het cre¨eren van een read-only HTML textinput. Methode voor het cre¨eren van een (multiple) HTML selector, gegeven een array met keuzemogelijkheden.
createCourseAndMappingsTextfields createDateInput
createLogin
createMailInput createMultipleSelectorJS createNumInput
createPasswordInput createReadOnlyTextArea createReadOnlyTextInput createSelector
121
createTable
createTextArea createTextInput createValuedMailInput
createValuedPasswordInput
createValuedTextArea
createValuedTextInput
getAdminMenu getCandidateMenu getFooter getHeader setForm toString updateClickPath
Methode voor het cre¨eren van tabel met twee kolommen. In de linkerkolom staan de elementen van een megegeven array, in de rechterkolom staat een HTML textinput. Methode voor het cre¨eren van een HTML textarea. Methode voor het cre¨eren van een HTML textinput, inclusief Javascript-code om de lengte van de invoer te verifi¨eren. Methode voor het cre¨eren van een HTML textinput, inclusief Javascript-code om het mailadres te verifi¨eren. Ook kan een locatie worden opgegeven waar de waarde van het element kan worden opgehaald. Het gevolg is dat de textinput in staat is om gegevens te onthouden na het versturen van een formulier. Methode voor het cre¨eren van een HTML paswoordinput, inclusief Javascript-code om de lengte van de input van de gebruiker te verifi¨eren. Ook kan een locatie worden opgegeven waar de waarde van het element kan worden opgehaald. Het gevolg is dat de textinput in staat is om gegevens te onthouden na het vsturen van een formulier. Methode voor het cre¨eren van een HTML textarea. Ook kan een locatie worden opgegeven waar de waarde van het element kan worden opgehaald. Het gevolg is dat de textinput in staat is om gegevens te onthouden na het versturen van een formulier. Methode voor het cre¨eren van een read-only HTML textinput. Ook kan een locatie worden opgegeven waar de waarde van het element kan worden opgehaald. Het gevolg is dat de textinput in staat is om gegevens te onthouden na het versturen van een formulier. Methode die de HTML-code voor admin-menu retourneert. Methode die de HTML-code voor het kandidaat-menu retourneert. Methode die een footer voor alle pagina’s definieert. Methode die een header voor alle pagina’s definieert. Methode die de gegevens van een form opslaat in de Page-class, zodat deze gebruikt kunnen worden voor het verifi¨eren van de invoer. Methode die een string-representatie retourneert van het PageController-object. Methode voor het updaten van het clickPath. Het clickPath zijn de pagina’s die sequentieel door een gebruiker bezocht zijn. Hierdoor is het mogelijk om altijd een stap terug te gaan.
122
2.2
Model-klassen
De model-klassen zijn de klassen die gebruikt worden door de controller om de opdrachten die via de view-klassen zijn gegeven uit te voeren. In onderstaande paragrafen zullen de verschillende model-klassen worden behandeld.
2.2.1
Actor
De actor klasse symboliseert een gegeneraliseerde gebruiker met de volgende gegevens: . ActorID. Uniek nummer om een gebruiker te identificeren in de database. . Changed. Boolean gebruikt om te markeren dat het object afwijkt met de database. . FirstName. Voornaam van de gebruiker. . LastName. Achternaam van de gebruiker. . Login. Laatste inlogdatum. . Mail. Mailadres van de gebruiker.
2.2.2
Candidate
De candidate klasse symboliseert een kandidaat. De klasse erft van Actor, zodat de persoonlijke gegevens bewaard kunnen worden. Candidate kent de volgende extra attributen. . CandidateID. Uniek nummer om een kandidaat te identificeren in de database. . CoursesCollections. Verzameling van studies en bijbehorende vakken van een kandidaat. . EVC. Erkenning van elders verworven competenties van een kandidaat. . Requests. Verzameling van aanvragen van een kandidaat.
2.2.3
Committee
De Committee klasse symboliseert een comit´e. In de applicatie is een comit´e gedefinieerd als een “universiteit, schoolvak”-paar. In de werkelijkheid kan een comit´e meerdere schoolvakken hebben. In dat geval worden in de applicatie meerdere commissies aangemaakt. Committee kent de volgende attributen: . Area. Het schoolvak van het comit´e. . City. De naam van de stad. . CommitteeID. Uniek nummer om een comit´e te identificeren in de database. . DomainPreference. Voorkeur voor sub- of kerndomeinen van het schoolvak. . MembersArray. Array van leden van het comit´e. . University. De naam van de universiteit van het comit´e. . UniversityID. Een uniek nummer om de universiteit te identificeren.
123
2.2.4
Course
De Course klasse symboliseert een vak dat een kandidaat heeft gevolgd. Course kent de volgende attributen: . Added. Boolean gebruikt om te markeren dat een vak toegevoegd moet worden. . Changed. Boolean gebruikt om te markeren dat een object afwijkt met de database. . Course name. Naam van het vak. . CourseID. Uniek nummer om een vak te identificeren in de database. . Deleted. Boolean gebruikt om te markeren dat een vak verwijderd moet worden. . Ects. Studielast van het vak uitgedrukt in European Credits (EC). . Mapping. Array van toekenningen aan ´e´en of meer kern- of subdomeinen. . UniversityID. Uniek nummer om een universiteit te identificeren in de database.
2.2.5
CoursesCollection
De CoursesCollection klasse symboliseert een vakkenpakket van een kandidaat. CoursesCollection kent de volgende attributen: . City. Stad van een universiteit. . Courses. Verzameling van de verplichte vakken van een studie. . CoursesID. Uniek nummer van een verzameling van verplichte vakken. . Priority. Relevantie van een studie bij de bepaling van de indicatie. . Specialization. Verzameling van de gespecialiseerde vakken van een studie. . SpecializationID. Uniek nummer van een verzameling van gespecialiseerde vakken. . StudyName. Naam van een studie. . Type. Opleidingsniveau van een studie. . TypeID. Uniek nummer om het opleidingsniveau aan te geven. . University. Naam van de universiteit waar een studie wordt gegeven. . UniversityID. Uniek nummer van een universiteit in de database. . Year. Het jaar waarin het diploma voor een opleiding is behaald.
124
2.2.6
Mapping
De Mapping klasse symboliseert de toekenning van een vak aan een kern- of subdomein. Een vak kan meerdere mappingen hebben. Mapping kent de volgende attributen: . Changed. Boolean gebruikt om te markeren dat een object afwijkt met de database. . CommitteeID. Uniek nummer van het comit´e die de mapping moet controleren. . Domain name. Naam van een kern- of subdomein. . DomainID. Uniek nummer om het domein aan te geven waarop een vak is toegekend. . Validated. Boolean gebruikt om aan te geven dat een mapping gevalideerd is.
2.2.7
Member
De Member klasse symboliseert een lid van ´e´en of meer toelatingscommissies. Member kent de volgende attributen: . Committees. Lijst van commissies waarvan een gebruiker lid is. . Job. Taak van het lid in de toelatingscommissie (secretaris/vakdidacticus). . MemberID. Uniek nummer om een lid te identificeren in de database.
2.2.8
Request
De Request klasse symboliseert een aanvraag van de kandidaat aan een toelatingscommissie. Request kent de volgende attributen: . AreaID. Uniek nummer om een schoolvak te identificeren in de database. . AreaName. Naamvan een schoolvak. . CandidateID. Uniek nummer om een kandidaat te identificeren in de database. . Changed. Boolean gebruikt om te markeren dat een object afwijkt met de database. . City. Stad waar een toelatingscommissie zich bevindt. . CommitteeID. Uniek nummer om de commissie te identificeren in de database. . Follow up coursesID. Uniek nummer om de verzameling van geadviseerde vakken te identificeren in de database. . Progress. Voortgang van de verwerking van een advies. . Reply. Het (persoonlijke) antwoord op een advies door de toelatingscommissie. . RequestID. Uniek nummer om een aanvraag te identificeren in de database. . TotalECTS. Totale studielast voor het wegwerken van de vakdeffici¨enties. . University. Uuniversiteit waar een toelatingscommissie zich bevindt.
125
2.3
View-klassen
De websites, ofwel view-klassen, zijn op te splitsen in drie types: adminpagina’s, commissiepagina’s, en kandidaatpagina’s. De adminpagina’s en commissiepagina’s zijn volledig ge¨ımplementeerd. De weergave hieronder is beperkt tot de websites die voor de gebruiker beschikbaar zijn. In werkelijkheid maken de meeste websites gebruik van andere websites voor het uitvoeren van hun functionaliteit. In de versie van de applicatie die voor het bachelorproject zal worden ingeleverd, zal het commissiegedeelte niet volledig zijn ge¨ımplementeerd.
2.3.1
Adminpagina’s
In onderstaande tabel zijn de pagina’s weergegeven die corresponderen aan de admin. Website
Functie
addAdmin addArea addCommittee
Website voor het toevoegen van een nieuwe admin aan de database. Website voor het toevoegen van een een schoolvak aan de database. Website voor het toevoegen van een comit´e aan de database. Voor het toevoegen van een comit´e moet tevens een secretaris worden aangemaakt. Website voor het toevoegen van een historische kandidaat aan de database. Samen met AddHistoricalStudy, en AddHistoricalMapping, is het mogelijk om historische adviezen in de database op te slaan. Website voor het toevoegen van een mapping aan de vakken die zijn ingevoerd met behulp van AddHistoricalStudy. Samen met AddHistoricalCandidate en AddHistoricalStudy is het mogelijk om historische adviezen in de database op te slaan. Website voor het toevoegen van ´e´en of meer studies aan een historische kandidaat die is aangemaakt met behulp van AddHistoricalCandidate. Samen met AddHistoricalCandidate en AddHistoricalStudy is het mogelijk om historische adviezen in de database op te slaan. Website voor het toevoegen van een universiteit aan de database. Voor het toevoegen van een universiteit moet de stad en universiteit worden opgegeven. Hoofdscherm van de admin waarop alleen het menu zichtbaar is. Dit scherm wordt na inloggen direct getoond. Het menu zelf is op de overige adminpagina’s ook zichtbaar. Website die de mogelijkheid biedt om een kandidaat van de website te verbannen. Hierbij wordt het account van de kandidaat geblokkeerd. Tevens wordt de mogelijkheid geboden om de verbanning ongedaan te maken. Website die het mogelijk maakt om de preferentie van een toelatingscommissie voor kern- of subdomeinen aan te passen. Website voor het inloggen van de admin. Website voor het bekijken van alle gegevens van een enkele kandidaat. Website voor het bekijken van de basisgegevens van alle kandidaten. Door een specifieke kandidaat te selecteren worden de gedetailleerde gegevens van de kandidaat getoond. Tevens is het mogelijk om te filteren op alleen historische gegevens.
addHistoricalCandidate
addHistoricalMapping
addHistoricalStudy
addUniversity
adminMenu
banCandidate
editPreferenceID index viewCandidate viewCandidates
126
2.3.2
Kandidaatpagina’s
In onderstaande tabel zijn de pagina’s weergegeven die corresponderen aan de kandidaat. Website
Functie
addCourses
Website voor het toevoegen van een vakkenpakket aan de database. Deze pagina is bereikbaar vanaf addStudy. In addStudy vinkt de kandidaat de vakkenpakketten aan die hij over wilt nemen. Vervolgens worden de overgenomen vakken automatisch ingevuld bij addCourses. Hier kan de gebruiker volgens de extra vakken invullen, en de ingevulde invoer bewerken. Website die het mogelijk maakt om een gezipte collectie van cijferlijsten toe te voegen aan de server. Website voor het toevoegen van de mapping aan de studies van de kandidaat. Deze pagina is bereikbaar vanaf addRequest. In addRequest vinkt de kandidaat de vakkenpakketten aan die hij over wilt nemen. Vervolgens wordt bekeken in hoeverre deze vergelijkbaar zijn met de studies van de kandidaat. Vervolgens kan de kandidaat op de addMappingCourses-pagina de overgenomen gegevens bewerken. Website die het mogelijk maakt om een aanvraag voor een bepaald schoolvak te doen. Op deze pagina kan de kandidaat net als bij addStudy een vakkenpakket selecteren. Hierbij wordt ook het onderscheid gemaakt tussen het verplichte, en gespecialiseerde gedeelte. Als op een vakkenpakket wordt geklikt, dan wordt een aparte pagina geopend met een overzicht van de vakken, en de mappingen van elk vak. Als de kandidaat ervoor kiest om een aantal vakkenpakketten te selecteren, dan wordt bekeken welke vakken in deze vakkenpakketten overeenkomen met de vakken die de kandidaat heeft ingevuld van zijn gevolgde studies. Deze worden vervolgens op de addMappingCourses-pagina weergegeven, waarop de kandidaat ze kan bewerken. Website die het mogelijk maakt om een studie toe te voegen aan een kandidaat. De gebruiker kan alle vakken zelf invullen door “zelf vakken toevoegen” te selecteren, maar kan ook in de bestaande vakkenpakketten zoeken om (een deel van) de gegevens over te nemen. Vervolgens kan de kandidaat in addCourses de meegenomen vakkenpakketten bewerken. In addStudy wordt een onderscheid gemaakt tussen het verplichte en gespecialiseerde gedeelte van een vakkenpakket. Op elk pakket kan geklikt worden om een nieuwe pagina te openen in een apart venster met de vakken in het vakkenpakket. Het verplichte gedeelte betreft de vakken die iedereen van bijvoorbeeld Technisch Informatica volgt. De gespecialiseerde vakken zijn uniek voor het individu of een kleine groep.
addGradeList addMappingCourses
addRequest
addStudy
127
createAccount
editCandidate index
profile
viewCourses
viewMappings
Website voor het aanmaken van een kandidaat-account. Na het aanmaken van een account wordt een bericht verzonden naar de gebruiker. In dit bericht staat een link die de gebruiker moet selecteren om een account te activeren. Pas als een account geactiveerd is, is inloggen mogelijk. Website voor het aanpassen van de basisgegevens van de kandidaat, zoals zijn naam. Deze pagina is toegankelijk vanaf het profielscherm. Website voor het inloggen van de kandidaat. Na het inloggen wordt de profielpagina getoond. Tevens is het mogelijk om met behulp van deze pagina naar createAccount te gaan om een nieuw account toe te voegen. Ook kan van een bestaand account het verloren paswoord worden opgevraagd. In dat geval wordt een bericht gestuurd naar de kandidaat. In het bericht staat een link die de gebruiker moet selecteren om zijn paswoord te mogen wijzigen. Deze link is slechts eenmaal te gebruiken. Website voor het bekijken van het profiel van de kandidaat. Op deze informatie is de verwerkingsstatus van de openstaande adviezen te vinden, de ingevulde opleidingen, en verschillende mogelijkheden tot het invoeren van de profielgegevens. Tot slot wordt de mogelijkheid geboden om een nieuwe aanvraag op te stellen. Website die vanuit addStudy toegankelijk is. Op deze website worden de vakken van een vakkenpakket weergegeven dat in addStudy is geselecteerd om te bekijken. Deze pagina wordt op een nieuw scherm weergegeven. Website die vanuit addRequest toegankelijk is. Op deze website worden de vakken van een vakkenpakket, en de mappingen voor het op addRequest geselecteerde schoolvak, weergegeven. Deze pagina wordt op een nieuw scherm weergegeven.
128
Hoofdstuk 3
Implementatieproces In dit hoofdstuk wordt beschreven hoe de applicatie tot stand is gekomen. Voor de eenvoud wordt een sequentieel model aangehouden. Het kwam echter vaak voor dat revisies in vorige stappen nodig waren voordat verder kon worden gegaan. Het gehele implementatieproces is weergegeven in tabel 3.1. Tabel 3.1: Overzicht implementatieproces #
Deelproces
Pagina
1
Opzetten databasemodel
2
Opzetten database
3
Model-klassen opstellen
4
Model-klassen testen
5
Controller-klassen opstellen
6
Controller-klassen testen
7
View-klassen admin opstellen
8
View-klassen kandidaat opstellen
9
Presentatie aan de toelatingscommissies
10
Toekomst: testplan uitvoeren
11
Toekomst: commissiegedeelte opstellen
12
Toekomst: applicatie installeren
129
3.1
Opstellen databasemodel
Als eerst stap is een databasemodel opgesteld. Dit databasemodel is gebaseerd op het model van het aanvraagproces, zoals beschreven in het ontwerpverslag. In de laatste weken van het bachelorproject bleek het databasemodel volgens de begeleider een paar fouten te bevatten. Deze oplossingen zijn in een nieuwe versie van het databasemodel verwerkt. Vervolgens is het nieuwe databasemodel nogmaals gecontroleerd, waarna er geen problemen werden aangetroffen. Tijdens de verdere implemenatie van de View-klassen zijn geen nieuwe problemen meer ontdekt.
3.2
Opzetten database
Het opzetten van de database is gedaan door op de TU Delft een databaseserver aan te maken. Tijdens het gehele bachelorproject is van deze server gebruik gemaakt. In de laatste paar weken van het project is besloten een tweede databaseserver aan te maken, waar de historische gegevens op konden worden opgeslagen. Op deze manier kon doorgewerkt worden aan de applicatie, zonder dat de historische gegevens gemixt zouden raken met testdata. Uiteindelijk zal in de laatste fase van het project een andere databaseserver moeten worden gekozen. Waarschijnlijk komt deze op een van de universiteiten die aan het project meedoet te draaien.
3.3
Model-klassen opstellen
Het opstellen van de model-klassen was een van de belangrijkste onderdelen bij de implementatie. De meeste model-klassen zijn daarom ook met pair-programming opgesteld. Initieel werkten de model-klassen goed samen met de database, maar na aanpassingen aan de database aan de hand van de feedback van de begeleider, moesten de klassen worden aangepast. Bij het opstellen van de model-klassen is alvast rekening gehouden met de commissie-kant van de applicatie. Hierdoor worden er geen problemen verwacht bij het opstellen van het commissiegedeelte.
3.4
Model-klassen testen
Om zeker te zijn van de functionaliteit van de model-klassen, zijn deze uitvoerig getest voordat de controller-klassen werden opgesteld. Hierbij is gebruik gemaakt van SimpleTest, een testframework voor PHP. Voor elk van de model-klassen zijn aparte php files opgesteld met tests. Deze zijn met behulp van een webserver uit te voeren. Initieel was het schrijven van de tests veel werk, elke testfile was veel groter dan het oorspronkelijke bestand. Echter, bij het uitvoeren van de tests bleek dat het werk niet voor niets was. Als bijvoorbeeld in een getter een variabele met een net iets andere naam werd teruggegeven, dan zou Java hierop crashen omdat de variabele niet bestaat. Echter, in PHP hoeven variabelen niet ge¨ınitialiseerd te worden, en wordt zonder foutmelding null teruggegeven. Een ander probleem was het ontbreken van type-checking in PHP. Dit betekent dat PHP zelf uitzoekt wat het type van de variabele is. In enkele gevallen kan dit leiden tot onverwachte interpretaties. SimpleTest wist in beide gevallen het probleem aan het licht te brengen.
130
3.5
Controller-klassen opstellen
Net als bij de model-klassen is bij de opstelling van de kern van de controller-klassen gebruik gemaakt van pair-programming. Tijdens het opstellen van de controller is gekozen voor een Singleton pattern, zodat een object maximaal hergebruikt kan worden, en geheugengebruik wordt geminimaliseerd. Al gauw bleek de databasecontroller teveel functies zou gaan bevatten. Hierom is besloten de databasecontroller op te splitsen in vier gedeeltes: 1. AdminController. Bevat de functies van de admin. 2. CandidateController. Bevat de functies van de kandidaat. 3. DatabaseController. Bevat functies die de verbinding met de database handhaven, en functies voor alle gebruikers. 4. MemberController. Bevat de functies van de commissie. In de applicatie maken de controllers alleen gebruik van de modelklassen. Momenteel maken de controllers weinig gebruik van de models, maar vooral van losse variabelen. De rede hiervoor is dat de models soms meer willen weten dan voor de functionaliteit van de methode vereist is. In de toekomstige versie zal het gebruik van de models worden verhoogd door methodes te combineren, of de functionaliteit van methodes uit te breiden. Tevens is de PageController toegevoegd om de duplicatie onder de View-klassen te verkleinen. Elke webpagina start bijvoorbeeld met een header, en eindigt met een footer. Door deze informatie te vangen in een aparte klasse, wordt duplicatie verminderd. De PageController helpt bij het genereren van de View-klassen, dus is volgens Model/View/Control niet echt een controller. Echter, gezien zijn centrale rol bij de View-klassen wordt deze hier wel als controller benoemd.
3.6
Controller-klassen testen
Voor het testen van de controller-klassen zijn initieel testklassen opgesteld. Echter, als snel bleek dit geen eenvoudige taak, omdat voor het testen de databasefuncties moesten worden gebruikt. Als er bijvoorbeeld een database-methode getest moest worden die insert-statements gebruikt, dan moet er voor automatisch testen een extra methode worden geschreven die de data kan uitlezen, en een methode om de data weer te verwijderen. Een mogelijke oplossing is het uitbreiden van de controllers, zodat deze kunnen samenwerken met een fictieve database. Echter, dit is meer werk dan manueel testen. Daarom is besloten de controller methodes manueel te testen.
3.7
View-klassen admin opstellen
Het admingedeelte heeft vooral als doel dat de admin voor bewerkingen niet direct toegang nodig heeft tot de database. In tegenstelling tot de kandidaat, is de admin een expert in de applicatie. Hiermee is rekening gehouden door bijvoorbeeld bij de invoer van historische kandidaten vooral tekstvelden te gebruiken. De admin kan hierdoor zeer snel data invoeren, maar moet hierbij wel aan een specifiek formaat voldoen. Het implementeren van het admingedeelte leverde weinig problemen op. Een groot deel van de functies die het gedeelte gebruikt worden, worden ook gebruikt door de kandidaat.
131
3.8
View-klassen kandidaat opstellen
De kandidaat is degene die het meeste invoerwerk in de applicatie doet. Tijdens de implementatie zijn daarom maatregelen genomen om de invoer zoveel mogelijk te beperken. Een van de gebruikte methodes betreft hulp bij het invoeren van de studies en de toekenningen aan kern- of subdomeinen. Met behulp van zoekmethodes kan de kandidaat hierbij namelijk een groot deel van de informatie van andere gebruiker hergebruiken. Een andere techniek die toegepast is om de invoer voor de kandidaat te vereenvoudigen, is door de invoer niet verplicht sequentieel te maken. Na het inloggen krijgt de kandidaat direct zijn profiel te zien. Op het profiel is zichtbaar welke opleidingen zijn toegekend aan het profiel, en welke aanvragen zijn gedaan. Het toevoegen van ´e´en of meer opleidingen, en het aanvragen van een advies, hoeft niet na elkaar te gebeuren. Tevens hoeven niet eens alle opleidingen in te hoeven worden gevuld. Deze kunnen namelijk per stuk worden toegevoegd.
3.9
Presentatie aan de toelatingscommissies
Op 17 juni vond een bijeenkomst van de verschillende werkpakketten van het “Alle H@nds Aan Dek”-project plaats. Op deze vergadering is er presentatie gehouden wat betreft de voortgang van het project. De applicatie werd als een groot succes ervaren. Officieel zou de applicatie als een prototype dienen, maar er werd al gesproken op de lange duur de applicatie verplicht te maken als methode voor het aanvragen van een advies bij de toelatingscommissies. Om de effectiviteit van de applicatie te vergroten, zullen extra personen worden aangenomen voor het invoeren van historische gegevens. Door het invoeren van historische gegevens zal de kandidaat vaker gebruik kunnen maken bestaande gegevens bij het invoeren van zijn gegevens.
3.10
Toekomst: testplan uitvoeren
Voor de applicatie van het bachelorproject zijn de tests van de code zoals beschreven in hoofdstuk 6 voor de kandidaat en admin uitgevoerd. Echter, een aantal van de controllertests zijn nog niet gedaan in verband met tijdgebrek. Het grootste gedeelte betrefte de PageController, waar nog extra invoerverificatie zal moeten worden toegepast. Ook zullen er nog acceptatietests met de verschillende gebruikers moeten plaatsvinden. Deze tests zullen in een later stadium plaatsvinden.
3.11
Toekomst: commissiegedeelte opstellen
In de huidige applicatie is het commissiegedeelte van de applicatie nog niet ge¨ımplementeerd. De implementatie zal plaatsvinden in juli, en begin augustus.
3.12
Toekomst: applicatie installeren
Wat betreft de installatie van de applicatie is bij de vergadering met de toelatingscommissies gevraagd wat de uiteindelijke locatie zal worden. Momenteel wordt dit onderzocht. Zoals beschreven in het onderzoeksverslag ligt de voorkeur bij een universiteit, omdat deze vaak bij Surf zijn aangesloten, en daardoor gratis SSL-licenties kunnen aanvragen.
132
Hoofdstuk 4
GUI In dit hoofdstuk worden de belangrijkste elementen van de GUI besproken. In paragraaf 4.1 zullen de ontwerpkeuzes worden behandeld. Hierna wordt in paragraaf 4.2 het profielscherm behandeld. Tot slot zal in paragraaf 4.3 het dynamisch toevoegen van elementen aan webpagina’s worden besproken aan de hand van het “vakken toekennen”-scherm (AddCourses).
4.1
Ontwerpkeuzes
Tijdens het ontwerp van de GUI zijn verschillende beslissingen genomen om het gebruik van de applicatie zo eenvoudig mogelijk te maken. Hieronder zijn de belangrijkste beslissingen opgesomd. 1. De gebruiker moet ten alle tijde terug kunnen naar een vorige stap. 2. De gebruiker moet voor het uitvoeren van een ingewikkelde bewerking eerst om bevestiging worden gevraagd. 3. De gebruiker moet overzichtelijk kunnen werken. Dit betekent dat het hoofdproces zich slechts in ´e´en venster plaats moet vinden, en een sequenti¨ele doorloop van het programma mogelijk moet zijn. 4. De gebruiker dient op elke pagina een uitleg aan te treffen over het gebruik van deze pagina. 5. De gebruiker dient bij elk element een tooltip te kunnen bekijken die de functionaliteit van het element beschrijft. 6. De gebruiker moet gebruik kunnen maken van elke moderne browser voor het bekijken van de website. 7. De gebruiker moet duidelijke foutmeldingen krijgen als hij data verkeerd heeft ingevoerd. Om dit te implementeren is vooral gebruik gemaakt van een dynamische afbeelding achter bijna elk invoerveld. Als de gebruiker zijn gegevens invoert, zal er eerst een rood kruis zichtbaar zijn. Pas als de gegevens goed zijn ingevoerd, komt er een groene vink te staan.
133
4.2
Profielpagina
In deze paragraaf wordt de profielpagina van de kandidaat behandeld. In figuur 4.1 is de profielpagina getoond. Via de profielpagina zijn alle opties voor de kandidaat beschikbaar. Het profiel geeft een compact overzicht van de status van de invoer van de kandidaat. Zo kan de kandidaat direct zien welke opleidingen hij al heeft ingevoerd, en de status van al zijn aanvragen. Boven het menu is het clickpath weergegeven. Dit is een lijst van websites die de kandidaat bezocht heeft. Als de kandidaat bijvoorbeeld naar “cijferlijst uploaden” gaat, dan kan hij terug keren naar de profielpagina door “profiel” te selecteren in het clickpath. Momenteel moet nog een uitleg voor de kandidaat worden toegevoegd aan de pagina. De bedoeling is dat de kandidaat eerst zijn cijferlijst upload, dan ´e´en of meer opleidingen toevoegt, en vervolgens een advies aanvraagt. Als een kandidaat een advies wil aanvragen, voordat hij al zijn opleidingen heeft ingevuld, dan is dit mogelijk. Tevens kan na het aanvragen van een advies, direct een nieuw advies worden aangevraagd voor een ander schoolvak. Na elke toevoeging van gegevens wordt na de profielpagina teruggekeerd, en wordt deze automatisch ge¨ update.
Figuur 4.1: Overzicht van de profielpagina.
134
4.3
Dynamisch webelementen toevoegen
In deze paragraaf wordt het dynamisch toevoegen van webelementen besproken. Tijdens de invoer is van veel pagina’s niet bekend hoeveel invoervelden voor bijvoorbeeld vakken benodigd zijn. In dat geval zou eerst aan de kandidaat gevraagd moeten worden hoeveel elementen hij wilt. Het nadeel hiervan is dat als de kandidaat zich vergistte, dat hij de pagina opnieuw moet laden. Javascript biedt hierbij een oplossing. Initieel werd gebruik gemaakt van InnerHTML om het HTML van een bepaalde groep elementen op de pagina aan te passen, zodat er een nieuw vlak bijkwam. Echter, alleen Internet Explorer kan dit zonder opnieuw de pagina te herladen. Bij de andere browsers was het gevolg dat de ingevulde informatie van de kandidaat werd verwijderd. Document Object Model (DOM) biedt hierbij de oplossing. DOM is een cross-platform en taalonafhankelijke conventie voor het omgaan met onder andere HTML documenten. Een voorbeeld van een DOM-element is bijvoorbeeld een tekstvlak, of een knop. Met behulp van Javascript kunnen DOM-elementen worden opgesteld, en vervolgens aan een bestaande website worden toegevoegd. Het voordeel hierbij is dat de pagina niet opnieuw herladen hoeft te worden, en hiermee dus de informatie op een formulier behouden blijft. In figuur 4.2 is het toevoegen van vakken aan de een studie weergegeven. Door op “extra vak” te selecteren, wordt een leeg tekstveld boven de knop toegevoegd. Door op het rode kruis te drukken, wordt een element verwijderd. Hiervoor met behulp van het id van het element het DOM-element opgezocht en verwijderd. Het resultaat is een dynamisch formulier voor bijvoorbeeld het invullen van de vakken van een opleiding.
Figuur 4.2: Overzicht van het toevoegen van vakken aan een studie.
135
Hoofdstuk 5
Database-ontwerp In dit hoofdstuk zal het database-ontwerp worden behandeld. In paragraaf 5.1 zal de functie van elke tabel worden behandeld. Vervolgens zal in paragraaf 5.2 de implementatie van de database worden besproken. In figuur 5.1 is het databasediagram weergegeven. De pijlen geven in dit diagram de richting van de foreign-key relaties aan. De kant van de pijl met de vork betreft hierbij de foreign key. De gele uitroeptekens in de verschillende tabellen geven de primary keys aan. De rode ruiten betreffen de foreign key’s. De overige gekleurde symbolen voor de attributen duiden aan dat het type geen foreign of primary key is, maar van een bepaald type is, zoals “text” of “int”.
136
Figuur 5.1: Overzicht van het databasediagram.
137
5.1
Ontwerp van de database
In deze paragraaf wordt voor elke tabel behandeld welke ontwerpkeuzes er zijn gemaakt. De tabellen staan op alfabetische volgorde.
Actor Functie: de actor-tabel bevat de informatie die alle gebruikers gemeen hebben Primary key: actorID Foreign keys: Attributen: . actorID. Uniek identificatienummer van een gebruiker in de database. . first name. Voornaam van een gebruiker. . last name. Achternaam van een gebruiker. . mail. Mailadres van een gebruiker. . password. Paswoord van een gebruiker. . active. Status van het account. 0 is niet geactiveerd, 1 is geactiveerd, 2 is verbannen.
Admin Functie: de admin-tabel wordt gebruikt om aan te geven dat een bepaalde actor admin is Primary key: adminID Foreign keys: actorID Attributen: . adminID. Uniek identificatienummer voor een admin in de database. . actorID. Uniek identificatienummer van een gebruiker in de database.
Area Functie: de area-tabel wordt gebruikt om een schoolvak aan te geven, met zijn preferentie voor kern- of subdomeinen Primary key: areaID Foreign keys: domain preferenceID Attributen: . areaID. Uniek identificatienummer voor een schoolvak in de database. . area name. Naam van een schoolvak. . domain preferenceID. Voorkeur voor kern- of subdomeinen.
138
Authorization lookup Functie: de authorization tabel wordt gebruikt om de verschillende mogelijke banen voor een lid in de toelatingscommissie op te slaan Primary key: authorizationID Foreign keys: Attributen: . authorizationID. Uniek identificatienummer voor een baan in de database. . authorization name. Naam van een baan.
Candidate Functie: de candidate tabel wordt gebruikt om de basisgegevens van een kandidaat op te slaan Primary key: candidateID Foreign keys: actorID Attributen: . candidateID. Uniek identificatienummer van een kandidaat in de database. . actorID. Uniek identificatienummer van een gebruiker in de database. . evc. Erkenning van Verworven Competenties van een kandidaat.
Committee Functie: de committee tabel wordt gebruikt om de gegevens van een toelatingscommissie op te slaan in de database. Hierbij wordt voor toelatingscommissie de definitie vak/universiteit-paar aangenomen Primary key: committeeID Foreign keys: areaID, universityID Attributen: . committeeID. Uniek identificatienummer van een comit´e in de database. . areaID. Uniek identificatienummer van een schoolvak in de database. . universityID. Uniek identificatienummer van een opleidingsinstelling in de database.
Committee members Functie: de committee members-tabel wordt gebruikt om een lid te registeren voor een toelatingscommissie Primary key: memberID, committeeID, authorizationID Foreign keys: memberID, committeeID, authorizationID Attributen: . memberID. Uniek identificatie van een lid van een toelatingscommissie in de database. . committeeID. Uniek identificatienummer van een comit´e in de database. . authorizationID. Uniek identificatienummer van een baan in de database.
139
Course Functie: de course-tabel wordt gebruikt om een vak op te slaan in de database Primary key: courseID Foreign keys: universityID Attributen: . courseID. Uniek identificatienummer voor een vak in de database. . course name. Naam van het vak. . universityID. Uniek identificatienummer van een opleidingsinstelling in de database. . ects. Studielast van een vak uitgedrukt in ects.
Courses Functie: de courses-tabel wordt gebruikt om een verplicht vakkenpakket op te slaan in de database Primary key: coursesID, courseID Foreign keys: courseID Attributen: . coursesID. Uniek nummer van een verplicht vakkenpakket in de database. . courseID. Uniek identificatienummer van een vak in de database.
Courses collection Functie: de courses collection-tabel wordt gebruikt om een studie op te slaan in de database Primary key: Foreign keys: candidateID, coursesID, universityID, typeID Attributen: . candidateID. Uniek identificatienummer van een kandidaat in de database. . coursesID. Uniek nummer voor een verplicht vakkenpakket in de database. . specializationID. Uniek identificatienummer voor een vakkenpakket van gespecialiseerde vakken. . collection name. Naam van een studie. . universityID. Uniek identificatienummer van een opleidingsinstelling in de database. . year. Jaar waarin het diploma van een studie is gehaald. . typeID. Opleidingsniveau van een studie. . priority. Prioriteit van een studie, bepaalt relevantie voor opstellen van indicatie. . historical. Boolean om aan te geven of een advies historisch is.
140
Domain Functie: de domain-tabel wordt gebruikt om een sub- of kerndomein op te slaan in de database Primary key: domainID Foreign keys: domain preferenceID, areaID Attributen: . domainID. Uniek identificatienummer voor een domein in de database. . domain name. Naam van een domein. . domain preferenceID. Bit om te identificeren of het om een kern- of subdomein gaat. . areaID. Uniek identificatienummer voor een schoolvak in de database. . description. Beschrijving welke vakken behoren tot het domein.
Domain content Functie: de domain content-tabel wordt gebruikt om relaties aan te geven tussen domeinen Primary key: core domainID, sub domainID Foreign keys: core domainID (domainID), sub domainID (domainID) Attributen: . core domainID. Uniek identificatienummer voor een kerndomein in de database. . sub domainID. Uniek identificatienummer voor een subdomein in de database.
Domain lookup Functie: de domain lookup-tabel wordt gebruikt om de mogelijke type domeinen in op te slaan Primary key: domain preferenceID Foreign keys: Attributen: . domain preferenceID. Bit voor kern- of subdomeinen aan te duiden. . domain type. Naam van type domein, bijvoorbeeld kerndomein.
Follow up courses Functie: de follow up courses-tabel wordt gebruikt om de geadviseerde vakken in vakkenpakketten op te slaan. Primary key: follow up coursesID, courseID Foreign keys: courseID Attributen: . follow up coursesID. Uniek nummer voor een geadviseerd vakkenpakket in de database. . courseID. Uniek identificatienummer voor een vak in de database.
141
Mapping Functie: de mapping-tabel wordt gebruikt om de toekenning van een vak op te slaan Primary key: courseID, domainID, committeeID, validated Foreign keys: courseID, domainID, committeeID Attributen: . courseID. Uniek identificatienummer voor een vak in de database. . domainID. Uniek identificatienummer voor een domein in de database. . commiteeID. Uniek identificatienummer van een comit´e in de database. . validated. Boolean gebruikt om aan te geven dat de mapping gevalideerd is door een comit´e.
Member Functie: de Member-tabel wordt gebruikt om een lid van een comit´e op te slaan in de database Primary key: memberID Foreign keys: actorID Attributen: . memberID. Unieek identificatienummer van een lid in de database. . actorID. Uniek identificatienummer van een gebruiker in de database.
Progress Functie: de progress-tabel wordt gebruikt om de voortgang van de verwerking van een adviesaanvraag op te slaan in de database Primary key: progressID Foreign keys: Attributen: . progressID. Uniek identificatienummer voor de voortgang van een aanvraag. . progress. Status van de verwerking van een adviesaanvraag.
Request Functie: de Request-tabel wordt gebruikt om een aanvraag van een kandidaat op te slaan Primary key: requestID Foreign keys: candidateID, committeeID, progressID Attributen: . requestID. Uniek identificatienummer van een aanvraag in de database. . candidateID. Uniek identificatienummer van een kandidaat in de database. . committeeID. Uniek identificatienummer van een comit´e in de database. . progressID. Uniek identificatienummer behorend tot de voortgang van een aanvraag. . reply. (Persoonlijk) antwoord van een toelatingscommissie op een aanvraag. . totalECTS. De totale studielast van de geadviseerde vakken uitgedrukt in ects. . follow up coursesID. Uniek nummer voor een geadviseerd vakkenpakket in de database. 142
Specialization Functie: de specialization-tabel wordt gebruikt om de gespecialiseerde vakken van een studie op te slaan in de database Primary key: specializationID, courseID Foreign keys: courseID Attributen: . specializationID. Uniek identificatienummer van een gespecialiseerd vakkenpakket. . courseID. Uniek identificatienummer voor een vak in de database.
Studylevel Functie: de studylevel-tabel wordt gebruikt om een opleidingsniveau op te slaan in de database Primary key: typeID Foreign keys: Attributen: . typeID. Uniek identificatienummer voor een opleidingsniveau in de database. . type. Naam van opleidingsniveau.
University Functie: de university tabel wordt gebruikt op een opleidingsinstelling op te slaan in de database Primary key: universityID Foreign keys: Attributen: . universityID. Uniek identificatienummer van een opleidingsinstelling in de database. . university name. Naam van een opleidingsinstelling. . city. Stad waar een opleidingsinstelling is gevestigd.
5.2
Implementatie van de database
Om een databasemodel te implementeren is een databaseserver nodig. Op https://sql.ewi.tudelft.nl is ruimte aangevraagd voor het aanmaken van een database. Vervolgens is het databasediagram omgezet in een database. De standaard database-engine die gebruikt wordt voor het opslaan van de tabellen is MyISAM. Zoals besproken in het onderzoeksverslag is het in deze engine echter niet mogelijk om primary key/foreign key relaties te defini¨eren. Daarom is besloten de tabellen om te zetten om gebruik te maken van InnoDB. Na de omzetting kwam aan het licht dat speciale karakters soms niet goed in de database werden opgeslagen, en bij het ophalen werden omgezet in vraagtekens. Het probleem bleek te zijn dat Apache, PHP, MySQLi, en de databaseserver ieder een ander karakterset gebruikten. Na ingelezen te zijn in het gebruik van karaktersets, is besloten elk van van de modules in te stellen op het karakterset UTF-8. 143
Hoofdstuk 6
Testplan In dit hoofdstuk zal het testplan van de applicatie worden beschreven. In paragraaf 6.1 wordt het testen van de model-klassen behandeld. Vervolgens worden in paragraaf 6.2 de tests van de controller-klassen beschreven. Tot slot zal in paragraaf 6.3 het testen van de view-klassen worden behandeld.
6.1
Testen van de model-klassen
Het testen van de model-klassen zal volledig plaatsvinden met behulp van geautomatiseerde tests. Deze tests worden uitgevoerd met behulp van het SimpleTest framework.
6.1.1
Geautomatiseerde tests
Voor het testen van de model-klassen wordt gebruik gemaakt van het testframework SimpleTest. Voor elk van de model-klassen is hieronder elke test kort beschreven. Actor In het programma zal nooit een actor-object worden aangemaakt. Deze superklasse kent als subklasses Candidate en Member. In CandidateTest zullen de methodes voor actor worden getest.
144
Candidate In CandidateTest zijn de methodes voor het testen van de klasse Candidate ge¨ımplementeerd. In onderstaande tabel is een overzicht gegeven van de verschillende methodes en hun functionaliteit. Testmethode
Functionaliteit
testCandidateChanged
Nagaan dat de changed en isChanged methodes correct functioneren. Nagaan dat een lege actorID niet is toegestaan. Nagaan dat een lege candidateID niet is toegestaan. Nagaan dat een niet bestaande dag in een datum niet is toegestaan. Nagaan dat buiten een schrikkeljaar 29 februari niet is toegestaan. Nagaan dat een niet bestaande maand in een datum niet is toegestaan. Nagaan dat een mailadres met meerdere apenstaartjes niet is toegestaan. Nagaan dat een negatieve actorID niet is toegestaan. Nagaan dat een negatieve candidateID niet is toegestaan. Nagaan dat een negatief jaar in een datum niet is toegestaan. Nagaan dat actorID niet null mag zijn. Nagaan dat candidateID niet null mag zijn. Nagaan dat EVC niet null mag zijn. Nagaan dat een voornaam niet null mag zijn. Nagaan dat een achternaam niet null mag zijn. Nagaan dat een mailadres niet null mag zijn. Nagaan dat een voornaam niet langer dan 32 karakters mag zijn. Nagaan dat een achternaam niet langer dan 64 karakters mag zijn. Nagaan dat een voornaam niet korter dan 2 karakters mag zijn. Nagaan dat een achternaam niet korter dan 3 karakters mag zijn. Genereert een string-representatie, waarna de gebruiker zelf zal moeten nagaan of deze het juiste formaat is. Nagaan dat als een geldig Candidate-object wordt aangemaakt, dat de getters allen correct functioneren. Nagaan dat actorID niet nul mag zijn. Nagaan dat candidateID niet nul mag zijn. Nagaan dat het jaar in de datum niet nul mag zijn.
testCandidateEmptyActorID testCandidateEmptyCandidateID testCandidateInvalidDay testCandidateInvalidLeapYear testCandidateInvalidMonth testCandidateMultipleAtSignsInMail testCandidateNegativeActorID testCandidateNegativeCandidateID testCandidateNegativeYear testCandidateNullActorID testCandidateNullCandidateID testCandidateNullEVC testCandidateNullFirstName testCandidateNullLastName testCandidateNullMail testCandidateTooLongFirstName testCandidateTooLongLastName testCandidateTooShortFirstName testCandidateTooShortLastName testCandidateToString testCandidateValidObjects testCandidateZeroActorID testCandidateZeroCandidateID testCandidateZeroYear
145
Committee In CommitteeTest zijn de methodes voor het testen van de klasse Committee ge¨ımplementeerd. In onderstaande tabel is een overzicht gegeven van de verschillende methodes en hun functionaliteit. De klasse Committee is onderdeel van de commissiekant van de applicatie, en is dus nog maar beperkt ge¨ımplementeerd. Testmethode
Functionaliteit
testCommitteeEmptyArea
Nagaan dat een lege string als schoolvak niet is toegestaan. Nagaan dat een lege string als stad niet is toegestaan. Nagaan dat een lege committeeID niet is toegestaan. Nagaan dat een lege voorkeur voor kern- of subdomeinen niet is toegestaan. Nagaan dat een lege string als universiteit niet is toegestaan. Nagaan dat een lege universityID niet is toegestaan. Nagaan dat een negatieve commiteeID niet is toegestaan. Nagaan dat een negatieve universityID niet is toegestaan. Nagaan een schoolvak niet null mag zijn. Nagaan dat stad niet null mag zijn. Nagaan dat commiteeID niet null mag zijn. Nagaan dat de voorkeur voor kern- of subdomeinen niet null mag zijn. Nagaan dat een universiteit niet null mag zijn. Nagaan dat universityID niet null mag zijn. Nagaan dat de voorkeur voor kern- of subdomeinen niet een andere voorkeur mag zijn. Nagaan dat de voorkeur voor kern- of subdomeinen niet een andere voorkeur mag zijn. Genereert een string-representatie, waarna de gebruiker zelf zal moeten nagaan of deze het juiste formaat is. Nagaan dat als een geldig Committee-object wordt aangemaakt, dat de getters allen correct functioneren Nagaan dat committeeID niet nul mag zijn. Nagaan universityID niet nul mag zijn.
testCommitteeEmptyCity testCommitteeEmptyCommitteeID testCommitteeEmptyDomainPreferenceID testCommitteeEmptyUniversity testCommitteeEmptyUniversityID testCommitteeNegativeCommitteeID testCommitteeNegativeUniversityID testCommitteeNullArea testCommitteeNullCity testCommitteeNullCommitteeID testCommitteeNullDomainPreferenceID testCommitteeNullUniversity testCommitteeNullUniversityID testCommitteeTooLargeDomainPreferenceID testCommitteeTooSmallDomainPreferenceID testCommitteeToString testCommitteeValidObjects testCommitteeZeroCommitteeID testCommitteeZeroUniversityID
146
Course In CourseTest zijn de methodes voor het testen van de klasse Course ge¨ımplementeerd. In onderstaande tabel is een overzicht gegeven van de verschillende methodes en hun functionaliteit. Testmethode
Functionaliteit
testCourseAdd
Nagaan dat de setAdd en isAdded methodes goed functioneren. Nagaan dat het toevoegen van een array met Mappingobjecten mogelijk is. Nagaan dat de changed en isChanged methodes correct functioneren. Nagaan dat de delete en isDeleted methodes correct functioneren. Nagaan dat een lege courseID niet is toegestaan. Nagaan dat een lege ECTS niet is toegestaan. Nagaan dat een lege string als vaknaam niet is toegestaan. Nagaan dat een lege universityID niet is toegestaan. Nagaan dat een fractionele ECTS is toegestaan. Nagaan dat een negatieve courseID niet is toegestaan. Nagaan dat een negatieve ECTS niet is toegestaan. Nagaan dat een negatieve universityID niet is toegestaan. Nagaan dat het toevoegen van geen Mapping-objecten mogelijk is. Nagaan dat het niet mogelijk is om een ander object, zoals een String, als Mapping-object toe te voegen. Nagaan dat courseID niet null mag zijn. Nagaan dat ECTS niet null mag zijn. Nagaan dat een vaknaam niet null mag zijn. Nagaan dat universityID niet null mag zijn. Nagaan dat ects niet groter dan 60 mag zijn. Genereert een string-representatie, waarna de gebruiker zelf zal moeten nagaan of deze het juiste formaat is. Nagaan dat als een geldig Course-object wordt aangemaakt, dat de getters allen correct functioneren. Nagaan dat courseID niet nul mag zijn. Nagaan dat ECTS niet nul mag zijn. Nagaan dat universityID niet nul mag zijn.
testCourseArrayMapping testCourseChanged testCourseDelete testCourseEmptyCourseID testCourseEmptyEcts testCourseEmptyName testCourseEmptyUniversityID testCourseFractionalEcts testCourseNegativeCourseID testCourseNegativeEcts testCourseNegativeUniversityID testCourseNonArrayMapping testCourseNoStringMapping testCourseNullCourseID testCourseNullEcts testCourseNullName testCourseNullUniversityID testCourseTooLargeEcts testCourseToString testCourseValidObjects testCourseZeroCourseID testCourseZeroEcts testCourseZeroUniversityID
147
CoursesCollection In CoursesCollectionTest zijn de methodes voor het testen van de klasse CoursesCollection ge¨ımplementeerd. In onderstaande tabel is een overzicht gegeven van de verschillende methodes en hun functionaliteit. Methode
Functionaliteit
testCoursesCollectionAncientYear testCoursesCollectionChanged
Nagaan dat een jaar voor 1970 niet is toegestaan. Nagaan dat de changed en isChanged methodes correct functioneren Nagaan dat courses een array mag zijn. Nagaan dat courses niet null mag zijn. Nagaan dat een lege string als stad niet is toegestaan. Nagaan dat een lege coursesID niet is toegestaan. Nagaan dat een lege string als prioriteit niet is toegestaan. Nagaan dat specializationID niet leeg mag zijn.
testCoursesCollectionCoursesArray testCoursesCollectionCoursesNull testCoursesCollectionEmptyCity testCoursesCollectionEmptyCoursesID testCoursesCollectionEmptyPriority testCoursesCollectionEmptySpecializationID testCoursesCollectionEmptyStudyName testCoursesCollectionEmptyType testCoursesCollectionEmptyTypeID testCoursesCollectionEmptyUniversity testCoursesCollectionEmptyUniversityID testCoursesCollectionEmptyYear testCoursesCollectionNegativeCoursesID testCoursesCollectionNegativePriority testCoursesCollectionNegativeSpecializationID testCoursesCollectionNegativeTypeID testCoursesCollectionNegativeUniversityID testCoursesCollectionNegativeYear testCoursesCollectionNullCity testCoursesCollectionNullCoursesID testCoursesCollectionNullPriority testCoursesCollectionNullSpecializationID testCoursesCollectionNullStudyName testCoursesCollectionNullType testCoursesCollectionNullTypeID testCoursesCollectionNullUniversity testCoursesCollectionNullUniversityID testCoursesCollectionNullYear testCoursesCollectionSpecializationsArray testCoursesCollectionSpecializationsNull testCoursesCollectionToString
Nagaan dat een studienaam niet null mag zijn. Nagaan dat type niet leeg mag zijn. Nagaan dat typeID niet leeg mag zijn. Nagaan dat een lege string als universiteit niet is toegestaan. Nagaan dat universityID niet leeg mag zijn. Nagaan dat een lege string als jaar niet is toegestaan. Nagaan dat coursesID niet negatief mag zijn. Nagaan dat een prioriteit niet negatief mag zijn. Nagaan dat specializationID niet negatief mag zijn. Nagaan dat typeID niet negatief mag zijn. Nagaan dat universityID niet negatief mag zijn. Nagaan dat een jaar niet negatief mag zijn. Nagaan dat een stad niet null mag zijn. Nagaan dat coursesID niet null mag zijn. Nagaan dat een prioriteit niet null mag zijn. Nagaan dat specializationID niet null mag zijn. Nagaan dat een studienaam niet null mag zijn. Nagaan dat type niet null mag zijn. Nagaan dat typeID niet null mag zijn. Nagaan dat een universiteit niet null mag zijn. Nagaan dat universityID niet null mag zijn. Nagaan dat een jaar niet null mag zijn. Nagaan dat specializations een array mag zijn. Nagaan dat specializations null mag zijn. Genereert een string-representatie, waarna de gebruiker zelf zal moeten nagaan of deze het juiste formaat is.
148
testCoursesCollectionValidObjects testCoursesCollectionZeroPriority testCoursesCollectionZeroSpecializationID testCoursesCollectionZeroTypeID testCoursesCollectionZeroUniversityID
Nagaan dat als een geldig CourseCollection-object wordt aangemaakt, dat de getters allen correct functioneren. Nagaan dat een prioriteit niet nul mag zijn. Nagaan dat specializationID nul mag zijn. Nagaan dat typeID niet nul mag zijn. Nagaan dat universityID niet nul mag zijn.
Mapping In MappingTest zijn de methodes voor het testen van de klasse Mapping ge¨ımplementeerd. In onderstaande tabel is een overzicht gegeven van de verschillende methodes en hun functionaliteit. Testmethode
Functionaliteit
testMappingChanged
Nagaan dat de changed en isChanged methodes correct functioneren. Nagaan dat een lege committeeID niet is toegestaan. Nagaan dat een lege domainID niet is toegestaan. Nagaan dat een lege domeinnaam niet is toegestaan. Nagaan dat een negatieve CommitteeID niet is toegestaan. Nagaan dat een negatieve domainID niet is toegestaan. Nagaan dat committeeID niet null mag zijn. Nagaan dat domainID niet null mag zijn. Nagaan dat een domeinnaam niet null mag zijn. Genereert een string-representatie, waarna de gebruiker zelf zal moeten nagaan of deze het juiste formaat is. Nagaan dat een lege validated niet is toegestaan. Nagaan dat een waarde hoger dan 1 voor validated niet is toegestaan. Nagaan dat een negatieve waarde voor validated niet is toegestaan. Nagaan dat validated niet null mag zijn. Nagaan dat als een geldig Mapping-object wordt aangemaakt, dat de getters allen correct functioneren. Nagaan committeeID niet nul mag zijn. Nagaan dat domainID niet nul mag zijn.
testMappingEmptyCommitteeID testMappingEmptyDomainID testMappingEmptyDomainName testMappingNegativeCommitteeID testMappingNegativeDomainID testMappingNullCommitteeID testMappingNullDomainID testMappingNullDomainName testMappingToString testMappingSetValidatedEmpty testMappingSetValidatedGreaterThanOne testMappingSetValidatedNegative testMappingSetValidatedNull testMappingValidObjects testMappingZeroCommitteeID testMappingZeroDomainID
149
Member In MemberTest zijn de methodes voor het testen van de klasse Member ge¨ımplementeerd. In onderstaande tabel is een overzicht gegeven van de verschillende methodes en hun functionaliteit. De klasse Member is onderdeel van de commissiekant van de applicatie, en kan in de toekomst dus nog veranderen. Testmethode
Functionaliteit
testMemberEmptyJob testMemberEmptyMemberID testMemberNegativeMemberID testMemberNullJob testMemberNullMemberID testMemberToString
Nagaan dat een lege string als baan niet is toegestaan. Nagaan dat een lege memberID niet is toegestaan. Nagaan dat een negatieve memberID niet is toegestaan. Nagaan dat een baan niet null mag zijn. Nagaan dat memberID niet null mag zijn. Genereert een string-representatie, waarna de gebruiker zelf zal moeten nagaan of deze het juiste formaat is. Nagaan dat als een geldig Member-object wordt aangemaakt, dat de getters allen correct functioneren. Nagaan dat memberID nul mag zijn.
testMemberValidObjects testMemberZeroMemberID
Request In RequestTest zijn de methodes voor het testen van de klasse Request ge¨ımplementeerd. In onderstaande tabel is een overzicht gegeven van de verschillende methodes en hun functionaliteit. Testmethode
Functionaliteit
testRequestArrayFollowUpCourses
Nagaan dat followUpCourses een array mag zijn van Course-objecten. Nagaan dat de changed en isChanged methodes correct functioneren. Nagaan dat areaID niet leeg mag zijn. Nagaan dat de string van een vaknaam niet leeg mag zijn. Nagaan dat candidateID niet leeg mag zijn. Nagaan dat de string van een stad niet leeg mag zijn. Nagaan dat committeeID niet leeg mag zijn. Nagaan dat FollowUpCoursesID leeg mag zijn. Nagaan dat de string van een voortgang niet leeg mag zijn. Nagaan dat reply leeg mag zijn. Nagaan dat requestID niet leeg mag zijn. Nagaan dat totalECTS niet leeg mag zijn. Nagaan dat de string van een universiteit niet leeg mag zijn. Nagaan dat areaID niet negatief mag zijn. Nagaan dat candidateID niet negatief mag zijn. Nagaaan dat committeeID niet negatief mag zijn. Nagaan dat followUpCoursesID niet negatief mag zijn. Nagaan dat requestID niet negatief mag zijn.
testRequestCourseChanged testRequestEmptyAreaID testRequestEmptyAreaName testRequestEmptyCandidateID testRequestEmptyCity testRequestEmptyCommitteeID testRequestEmptyFollowUpCoursesID testRequestEmptyProgress testRequestEmptyReply testRequestEmptyRequestID testRequestEmptyTotalECTS testRequestEmptyUniversity testRequestNegativeAreaID testRequestNegativeCandidateID testRequestNegativeCommitteeID testRequestNegativeFollowUpCoursesID testRequestNegativeRequestID
150
testRequestNegativeTotatlECTS testRequestNullAreaID testRequestNullAreaName testRequestNullCandidateID testRequestNullCity testRequestNullCommitteeID testRequestNullFollowUpCourses testRequestNullFollowUpCoursesID testRequestNullProgress testRequestNullReply testRequestNullRequestID testRequestNullTotatlECTS testRequestNullUniversity testRequestToString testRequestValidObjects testRequestZeroAreaID testRequestZeroCandidateID testRequestZeroCommitteeID testRequestZeroRequestID
6.2
Nagaan dat totalECTS niet negatief mag zijn. Nagaan dat areaID niet null mag zijn. Nagaan dat een schoolvak niet null mag zijn. Nagaan dat candidateID niet null mag zijn. Nagaan dat een stad niet null mag zijn. Nagaan dat committeeID null mag zijn. Nagaan dat followUpCourses null mag zijn. Nagaan dat followUpCoursesID null mag zijn. Nagaan dat een voorgang niet null mag zijn. Nagaan dat reply null mag zijn. Nagaan dat requestID niet null mag zijn. Nagaan dat totalECTS niet nul mag zijn. Nagaan dat een universiteit niet null mag zijn. Genereert een string-representatie, waarna de gebruiker zelf zal moeten nagaan of deze het juiste formaat is. Nagaan dat als een geldige Request-object wordt aangemaakt, dat de getters allen correct functioneren. Nagaan dat areaID niet nul mag zijn. Nagaan dat candidateID niet nul mag zijn. Nagaan dat committeeID niet nul mag zijn. Nagaan dat requestID niet nul mag zijn.
Testen van de controller-klassen
Voor het testen van de controller-klassen zal gebruik worden gemaakt van manuele tests. Er is niet voor automatische tests gekozen, omdat deze tests de database manipuleren. Voor het uitvoeren van de tests zullen bij automatische tests vele extra delete- en insertmethodes moeten worden geschreven. Ook is het in de huidige implementatie niet mogelijk om eenvoudig de database van de methodes te scheiden.
6.2.1
Manuele tests
In de controller-klassen wordt er bijna altijd vanuit gegaan dat de input van tevoren geverifieerd is. De rede hiervoor is dat de methodes worden aangesproken vanuit de View-klassen, waar inputverificatie plaatsvindt. Om deze rede zal bij onderstaande tests vaak geen rekening worden gehouden met incorrecte input. Voor elk van de controller-klassen worden hieronder de verschillende tests beschreven.
151
AdminController In onderstaande tabel zijn de methodes voor het testen van de klasse AdminController beschreven. Testmethode
Functionaliteit
testAddAreaExisting
Nagaan dat het niet mogelijk is een bestaand schoolvak toe te voegen. testAddAreaNonExisting Nagaan dat het mogelijk is een nieuw schoolvak toe te voegen. testAddCommitteeExisting Nagaan dat het niet mogelijk is om een bestaand comit´e toe te voegen. testAddCommitteeNonExisting Nagaan dat het mogelijk is een nieuw comit´e toe tevoegen.. testBanActorExistingAlreadyBanned Nagaan dat het niet mogelijk is om een gebruiker te verbannen die al verbannen is. testBanActorExistingNotBanned Nagaan dat het mogelijk is om een gebruiker te verbannen die nog niet verbannen is. testBanActorNonExisting Nagaan dat het niet mogelijk is om een onbekende gebruiker te verbannen testCheckAdminExisting Nagaan dat een bekende admin als bekend wordt geretourneerd. testCheckAdminNonExisting Nagaan dat een onbekende admin als onbekend wordt geretourneerd. checkAreaExisting Nagaan dat een bekend schoolvak als bekend wordt geretourneerd. checkAreaNonExisting Nagaan dat een onbekend schoolvak als onbekend wordt geretourneerd. testCheckCommitteeExisting Nagaan dat een bekend comit´e als bekend wordt geretourneerd. testCheckCommitteeNonExisting Nagaan dat een onbekend comit´e als onbekend wordt geretourneerd. testConstructNotPossible Nagaan dat de constructor niet aan te roepen is. testGetInstanceOnlyOnce Nagaan dat slechts ´e´en object wordt aangemaakt. testRegisterAdminNonExisting Nagaan dat het mogelijk is om een admin te registeren als deze nog niet in de database voorkomt. testRegisterAdminTwiceOtherPassword Nagaan dat het niet mogelijk is om tweemaal een admin te registeren met ander paswoord. testRegisterAdminTwiceSameData Nagaan dat het niet mogelijk is om tweemaal een admin te registeren met dezelfde gegevens. testRegisterFullAdminNonExisting Nagaan dat het mogelijk is om een admin te registeren als deze nog niet in de database voorkomt. testRegisterFullAdminTwiceOtherPassword Nagaan dat het niet mogelijk is om tweemaal een admin te registeren met dezelfde gegevens.
152
testRegisterFullAdminTwiceSameData testToString testUnbanActorBannedUser testUnbanActorNotBannedUser testUpdateAreaDomainpreference
Nagaan dat het niet mogelijk is om tweemaal een admin te registreren met dezelfde gegevens. Nagaan dat de string representatie van het object in een correct formaat staat. Nagaan dat het mogelijk is om een verbannen actor te ontbannen. Nagaan dat het niet mogelijk is om een niet verbannen user te ontbannen. Nagaan dat het alleen mogelijk is om de domainPreference te updaten als er geen aanvragen open staan.
CandidateController In onderstaande tabel zijn de methodes voor het testen van de klasse CandidateController beschreven. Testmethode
Functionaliteit
testCandidateExistsExisting
Nagaan dat een kandidaat als bekend wordt geretourneerd als deze niet in de database bestaat. Nagaan dat een kandidaat als onbekend wordt geretourneerd als deze niet in de database bestaat.
testCandidateExistsNonExisting
testCheckCandidateExisting testCheckCandidateNonExisting testCheckRequestExisting testCheckRequestNonExisting testConstructNotPossible testCreateCandidateNotPossible testCreateCoursesNotPossible testCreateCoursesCollectionNotPossbile testCreateMappingNotPossible testCreateRequestNotPossible testFetchCoursesNotPossible testGetCandidateByIDExisting testGetCandidateByIDNonExisting testGetCandidateByMailExisting testGetCandidateByMailNonExisting testGetCandidateListEmpty
Nagaan dat een candidate-object wordt geretourneerd als een kandidaat bestaat. Nagaan dat er niets wordt retourneerd als een kandidaat niet bestaat. Nagaan dat een aanvraag als bekend wordt geretourneerd als deze in de database bestaat. Nagaan dat een aanvraag als onbekend wordt geretourneerd als deze niet in de database bestaat. Nagaan dat de constructor private is. Nagaan dat createCandidate private is. Nagaan dat createCourses private is. Nagaan dat createCoursesCollection private is. Nagaan dat createMapping private is. Nagaan dat createRequest private is. Nagaan dat fetchCourses private is. Nagaan dat een candidate-object wordt geretourneerd als een kandidaat bestaat. Nagaan dat niets wordt geretourneerd als een kandidaat niet bestaat. Nagaan dat een candidate-object wordt geretourneerd als een kandidaat bestaat. Nagaan dat niets wordt geretourneerd als een kandidaat niet bestaat. Nagaan dat als er geen kandidaten bestaan, dat een leeg array wordt geretourneerd.
153
testGetCandidateListNotEmpty
Nagaan dat als er kandidaten bestaan, dat er een array met kandidaten wordt geretourneerd. testGetCandidateListDatesEmpty Nagaan dat als er geen kandidaten tussen de beide datums bestaan, dat een leeg array wordt geretourneerd. testGetCandidateListDatesNotEmpty Nagaan dat als er kandidaten tussen de beide datums bestaan, dat een array met de kandidaten wordt geretourneerd. testGetHistoricalCandidateListEmpty Nagaan dat er geen historische kandidaten bestaan, dat er een leeg array wordt geretourneerd. testGetHistoricalCandidateListNotEmpty Nagaan dat als er historische kandidaten bestaan, dat een array met de kandidaten wordt geretourneerd. testGetHistoricalCandidateListDatesEmpty Nagaan dat als er geen historische kandidaten tussen de beide datums bestaan, dat een leeg array wordt geretourneerd. testGetHistoricalCandidateListDatesNotNagaan dat als er geen historische kandidaten tussen de Empty beide datums bestaan, dat er een array met de kandidaten wordt geretourneerd. testGetInstanceOnlyOnce Nagaan dat slechts ´e´en object wordt aangemaakt. testInsertCourseExisting Nagaan dat als een vak al bestaat in de database, dat wordt geretourneerd dat het vak al bestaat. testInsertCourseNonExisting Nagaan dat als een vak nog niet bestaat in de database, dat het vak in de database wordt opgeslagen. testInsertCourseAndMappingExisting Nagaan dat als een vak al bestaat in de database, dat het vak en de mapping niet worden aangemaakt, en dat wordt geretourneerd dat het vak al bestaat. testInsertCourseAndMappingNonExisting Nagaan dat als een vak nog niet bestaat in de database, dat het vak en de mapping in de database wordt opgeslagen. testInsertCourseIDArrayInCoursesEmpty Nagaan dat bij het opgeven van een leeg array met vakkenID’s, dat er geen fout optreedt. testInsertCourseIDArrayInCoursesNonNagaan dat bij het opgeven van een gevuld array met Empty vakkendID’s, dat de vakken worden opgeslagen als behorend tot het opgegeven vakkenpakket. testInsertCourseIDArrayInFollowUpNagaan dat bij het opgeven van een leeg array met vakCoursesEmpty kenID’s, dat er geen fout optreedt. testInsertCourseIDArrayInFollowUpNagaan dat bij het opgeven van een gevuld array met CoursesNonEmpty vakkenID’s, dat de vakken worden opgeslagen als behorend tot het opgegeven geadviseerde vakkenpakket. testInsertCoursesCollectionExisting Nagaan dat als een vakkenpakket al bestaat in de database, dat deze niet wordt toegevoegd, en dat wordt geretourneerd dat het vakkenpakket al bestaat.
154
testInsertCoursesCollectionNonExisting testInsertMappingExisting
testInsertMappingNonExisting testInsertRequestExisting
testInsertRequestNonExisting testInsertRequestFromObjectExisting
testInsertRequestFromObjectNonExisting testLoadCoursesEmpty testLoadCoursesNonEmpty testLoadCoursesCollectionEmpty
testLoadCoursesCollectionNonEmpty
testLoadFollowUpCoursesEmpty
testLoadFollowUpCoursesNonEmpty
testLoadMappingEmpty testLoadMappingNonEmpty
testLoadRequestsEmpty
Nagaan dat als een vakkenpakket niet bestaat in de database, dat deze wordt toegevoegd. Nagaan dat als een mapping al bestaat in de database, dat deze niet wordt toegevoegd, en dat wordt geretourneerd dat de mapping al bestaat. Nagaan dat als een mapping nog niet bestaat in de database, dat deze wordt toegevoegd. Nagaan dat als een aanvraag al bestaat in de database, dat deze niet wordt toegevoegd, en wordt geretourneerd dat de aanvraag al bestaat. Nagaan dat als een aanvraag nog niet bestaat in de database, dat deze wordt toegevoegd. Nagaan dat als een aanvraag al bestaat in de database, dat deze niet wordt toegevoegd, en wordt geretourneerd dat de aanvraag bestaat. Nagaan dat als een aanvraag nog niet bestaat in de database, dat deze wordt toegevoegd. Nagaan dat een leeg vakkenpakket wordt geretourneerd als een vakkenpakket geen vakken bevat. Nagaan dat een gevuld vakkenpakket wordt geretourneerd als een vakkenpakket vakken bevat. Nagaan dat er een lege verzameling van studies wordt geretourneerd als een kandidaat geen studie heeft ingevoerd. Nagaan dat er een gevulde verzameling van studies wordt geretourneerd als een kandidaat minstens ´e´en studie heeft ingevoerd. Nagaan dat een leeg geadviseerd vakkenpakket wordt geretourneerd als een kandidaat geen aangeraden vakken heeft voor een aanvraag. Nagaan dat een gevuld vakkenpakket wordt geretourneerd als een kandidaat aangeraden vakken heeft voor een aanvraag. Nagaan dat een lege verzameling van mappings wordt geretourneerd als aan een vak geen mapping is toegekend. Nagaan dat een gevulde verzameling van mappings wordt geretourneerd als een vak minstens ´e´en mapping is toegekend. Nagaan dat een lege verzameling van aanvragen wordt geretourneerd als een kandidaat geen aanvragen heeft gedaan.
155
testLoadRequestsNonEmpty
testLoadSpecializationEmpty testLoadSpecializationNonEmpty testRegisterCandidateTwiceSameData testRegisterCandidateNonExisting testRegisterCandidateTwiceOtherPassword testRegisterFullCandidateTwiceSameData testRegisterFullCandidateNonExisting testRegisterFullCandidateTwiceOtherPassword testRegisterHistoricalCandidateTwiceSameData testRegisterHistoricalCandidateNonExisting testRegisterHistoricalCandidateTwiceOtherPassword testRemoveCandidateByMailExisting testRemoveCandidateByMailNonExisting testStoreCoursesNotPossible testStoreCoursesCollectionNotPossible testToString testUpdateCandidateExisting testUpdateCandidateNonExisting updateCandidatesEmpty updateCandidatesNonEmpty
Nagaan dat dat een gevulde verzameling van aanvragen wordt geretourneerd als een kandidaat minstens ´e´en aanvraag heeft gedaan. Nagaan dat een lege verzameling van vakken wordt geretourneerd als een studie gespecialiseerde vakken kent. Nagaan dat een gevulde verzameling van vakken wordt geretourneerd als een studie gespecialiseerde vakken kent. Nagaan dat het niet mogelijk is om tweemaal een kandidaat te registeren met dezelfde gegevens. Nagaan dat het mogelijk is om een kandidaat te registeren als deze nog niet in de database voorkomt. Nagaan dat het niet mogelijk is om tweemaal een kandidaat te registeren met dezelfde gegevens. Nagaan dat het niet mogelijk is om tweemaal een kandidaat te registeren met dezelfde gegevens. Nagaan dat het mogelijk is om een kandidaat te registeren als deze nog niet in de database voorkomt. Nagaan dat het niet mogelijk is om tweemaal een kandidaat te registeren met dezelfde gegevens. Nagaan dat het niet mogelijk is om tweemaal een kandidaat te registeren met dezelfde gegevens. Nagaan dat het mogelijk is om een kandidaat te registeren als deze nog niet in de database voorkomt. Nagaan dat het niet mogelijk is om tweemaal een kandidaat te registeren met dezelfde gegevens. Nagaan dat een kandidaat wordt verwijderd als het mailadres van de kandidaat bestaat. Nagaan dat er geen fouten optreden als een onbekend mailadres wordt opgegeven. Nagaan dat storeCourses private is. Nagaan dat storeCoursesCollection private is. Nagaan dat de string representatie van het object in een correct formaat staat. Nagaan dat een bestaande kandidaat correct ge¨ update wordt. Nagaan dat als een kandidaat niet bestaat in de database, dat er geen fout optreedt. Nagaan dat als array van kandidaten leeg is, dat er geen foutmelding optreedt. Nagaan dat als een array van kandidaat niet leeg is, dat de kandidaten correct worden ge¨ update.
156
DatabaseController In onderstaande tabel zijn de methodes voor het testen van de klasse DatabaseController beschreven. Testmethode
Functionaliteit
testActorExistsExisting
Nagaan dat een gebruiker als bekend wordt geretourneerd als deze bestaat in de database. Nagaan dat een gebruiker als onbekend wordt geretourneerd als deze niet bestaat in de database. Nagaan dat het niet mogelijk is om een bestaande universiteit toe te voegen. Nagaan dat het mogelijk is een nieuwe universiteit toe te voegen. Nagaan dat het niet mogelijk is om een paswoord te wijzigen als het gehashte paswoord of het mailadres niet klopt. Nagaan dat het mogelijk is om het paswoord te wijzigen als het gehaste paswoord en het mailadres klopt. Nagaan dat als een gehasht paswoord of mailadres incorrect is, dat dit wordt geretourneerd. Nagaan dat als een gehasht paswoord en mailadres correct is, dat dit wordt geretourneerd. Nagaan dat een bekende universiteit als bekend wordt geretourneerd. Nagaan dat een onbekende universiteit als onbekend wordt geretourneerd. Nagaan dat als een connectie niet bestaat, dat een leeg object wordt geretourneerd. Nagaan dat als een connectie bestaat, dat deze wordt geretourneerd. Nagaan dat de constructor private is. Nagaan dat een bestaande verbinding verbroken wordt. Nagaan dat een leeg object wordt geretourneerd als een gebruiker niet bestaat. Nagaan dat de status van een gebruiker wordt geretourneerd als deze bestaat. Nagaan dat het areaID wordt geretourneerd als een schoolvak bestaat. Nagaan dat een leeg object wordt geretourneerd als een schoolvak niet bestaat. Nagaan dat een lege collectie van schoolvakken wordt geretourneerd als er geen schoolvakken bestaan.
testActorExistsNonExisting testAddUniversityExisting testAddUniversityNonExisting testChangeForgottenPasswordInvalid
testChangeForgottenPasswordValid testCheckActorKeyInvalid testCheckActorKeyValid testCheckUniversityExisting testCheckUniversityNonExisting testCheckConnectInvalid testCheckConnectValid testConstructNotPossible testDisconnect testGetActorStatusInvalid testGetActorStatusValid testGetAreaIDExisting testGetAreaIDNonExisting testGetAreasEmpty
157
testGetAreasNonEmpty testGetAuthorizationIDExisting testGetAuthorizationIDNonExisting testGetCitiesEmpty testGetCitiesNonEmpty testGetCommitteeAreasEmpty testGetCommitteeAreasNonEmpty
testGetCommitteeIDExisting
testGetCommitteeIDNonExisting
testGetCommitteesEmpty testGetCommitteesNonEmpty testGetConnectionExisting testGetConnectionNonExisting testGetCoursesCollectionCountEmpty testGetCoursesCollectionCountNonEmpty
testGetDomainIDExisting testGetDomainIDNonExisting testGetDomainPreferenceIDExisting testGetDomainPreferenceIDNonExisting
Nagaan dat een collectie van schoolvakken wordt geretourneerd als er minstens ´e´en schoolvak bestaat. Nagaan dat een authorizationID wordt geretourneerd als een baan bestaat. Nagaan dat een leeg object wordt geretourneerd als een baan niet bestaat. Nagaan dat een lege collectie van steden wordt geretourneerd als er geen steden bestaan. Nagaan dat er een collectie van steden wordt geretourneerd als er minstens ´e´en stad bestaat. Nagaan als dat een lege verzameling van comit´e-gegevens wordt geretourneerd als er geen comit´es bestaan. Nagaan dat een gevulde verzameling verzameling van comit´e-gegevens wordt geretourneerd als er minstens ´e´en comit´e bestaat. Nagaan dat het ID van een comit´e wordt geretourneerd als de opgegeven schoolvak/universiteit-combinatie bekend is. Nagaan dat een leeg object wordt geretourneerd als de opgegeven schoolvak/universiteit-combinatie onbekend is. Nagaan dat een lege verzameling van comit´es wordt geretourneerd als deze niet bestaan. Nagaan dat een gevulde verzameling van comit´es wordt geretourneerd als er minstens ´e´en comit´e bestaat. Nagaan dat de connectie met de database wordt geretourneerd als deze bestaat. Nagaan dat een leeg object wordt geretourneerd als er geen connectie met de database is. Nagaan dat nul wordt geretourneerd als een kandidaat geen studies heeft ingevuld. Nagaan dat aantal studies wat geretourneerd wordt gelijk is aan het aantal studies van de kandidaat als deze minstens ´e´en studie heeft. Nagaan dat als het id van een domein wordt geretourneerd als de opgegeven domeinnaam bestaat. Nagaan dat een leeg object wordt geretourneerd als de opgegeven domeinnaam niet bestaat. Nagaan dat het id van de voorkeur wordt geretourneerd als de voorkeur bestaat. Nagaan dat een leeg object wordt geretourneerd als een voorkeur niet bestaat.
158
testGetDomainPreferencesEmpty
testGetDomainPreferencesNonEmpty
testGetDomainsEmpty
testGetDomainsNonEmpty testGetFollowUpCoursesIDNonExisting testGetFollowUpCoursesIDExisting testGetHashedPasswordInvalid testGetHashedPasswordValid testGetInstanceOnlyOnce testGetMatchingRequiredCoursesEmpty
testGetMatchingRequiredCoursesNonEmpty testGetMatchingRequiredCoursesMappingEmpty
testGetMatchingRequiredCoursesMappingNonEmpty
testGetMatchingSpecializationCoursesEmpty testGetMatchingSpecializationCoursesNonEmpty
Nagaan dat een lege verzameling van mogelijke voorkeuren wordt geretourneerd als er geen mogelijke voorkeuren bestaan. Nagaan dat een gevulde verzameling van mogelijke voorkeuren wordt geretourneerd als er minstens ´e´en mogelijke voorkeur bestaat. Nagaan dat een lege verzameling van domeinen wordt geretourneerd als een schoolvak niet bestaat, of geen domeinen is toegekend. Nagaan een gevulde verzameling van domeinen wordt geretourneerd als een schoolvak minstens ´e´en domein heeft. Nagaan dat een lege verzameling wordt geretourneerd als een aanvraag geen geadviseerde vakken is toegekend. Nagaan dat een gevulde verzameling wordt geretourneerd als een schoolvak minstens ´e´en vak is toegekend. Nagaan dat een leeg-object wordt geretourneerd als een kandidaat niet bestaat. Nagaan dat het gehashte paswoord van de kandidaat wordt geretourneerd als een kandidaat bestaat. Nagaan dat slechts ´e´en object wordt aangemaakt. Nagaan dat een lege verzameling van studies wordt geretourneerd als geen een studie een naam heeft met de opgegeven deelstring. Nagaan dat een verzameling van studies wordt geretourneerd als er minstens ´e´en studie is met de opgegeven deelstring als naam, en een set met verplichte vakken heeft. Nagaan dat een lege verzameling van studies wordt geretourneerd als geen een studie een naam heeft met de opgegeven deelstring, of geen een studie wel voldoet, maar geen mappingen heeft. Nagaan dat een verzameling van studies wordt geretourneerd als er minstens ´e´en studie is met de opgegeven deelstring als naam, en een set met verplichte vakken, die gevalideerd gemapt zijn, heeft. Nagaan dat een lege verzameling van studies wordt geretourneerd als geen een studie een naam heeft met de opgegeven deelstring. Nagaan dat een verzameling van studies wordt geretourneerd als er minstens ´e´en studie is met de opgegeven deelstring als naam, en een set met gespcialiseerde vakken heeft.
159
testGetMatchingSpecializationCoursesMappingEmpty
testGetMatchingSpecializationCoursesMappingNonEmpty
testGetNewFollowUpCoursesIDEmpty testGetNewFollowUpCoursesIDNonEmpty
testGetRequestIDExisting
testGetRequestIDNonExisting
testGetStudylevelIDExisting testGetStudylevelIDNonExisting testGetStudylevelsEmpty
testGetStudylevelsNonEmpty
testGetUniversitiesEmpty testGetUniversitiesNonEmpty
testGetUniversityIDExisting testGetUniversityIDNonExisting testIsConnectedNoConnection testIsConnectedConnection
Nagaan dat een lege verzameling van studies wordt geretourneerd als geen een studie een naam heeft met de opgegeven deelstring, of geen een studie wel voldoet, maar geen mappingen heeft. Nagaan dat een verzameling van studies wordt geretourneerd als er minstens ´e´en studie is met de opgegeven deelstring als naam, en een set met gespecialiseerde vakken, die gevalideerd gemapt zijn, heeft. Nagaan dat 1 wordt geretourneerd als er niet eerder vakkenpakketten zijn geadviseerd. Nagaan dat totaal aantal geadviseerde vakkenpakketten + 1 wordt geretourneerd als er minstens ´e´en geadviseerd vakkenpakket bestaat. Nagaan dat een aanvraag wordt geretourneerd als de opgegeven kandidaat een aanvraag heeft bij de opgegeven commissie. Nagaan dat een leeg object wordt geretourneerd als de opgegeven kandidaat niet bestaat, of geen aanvraag heeft bij de opgegeven commissie. Nagaan dat een ID wordt geretourneerd als een opgegeven opleidingsniveau bekend is. Nagaan dat een leeg object wordt geretourneerd als een opgegeven opleidingsniveau niet bekend is. Nagaan dat een lege verzameling van opleidingsniveaus wordt geretourneerd als er geen opleidingsniveaus bestaan. Nagaan dat een gevulde verzameling van opleidingsniveaus wordt geretourneerd als er minstens ´e´en opleidingsniveau bestaat. Nagaan dat een lege verzameling van universiteiten wordt geretourneerd als er geen universiteiten bestaan. Nagaan dat een gevulde verzameling van universiteiten wordt geretourneerd als er minstens ´e´en universiteit bestaat. Nagaan dat een leeg object wordt geretourneerd als de opgegeven universiteit niet bestaat. Nagaan dat een ID wordt getourneerd als de opgegeven universiteit bestaat. Nagaan dat als een connectie niet bestaat, dat wordt geretourneerd dat er geen verbinding is. Nagaan dat als een connectie bestaat, dat wordt geretourneerd dat er verbinding is.
160
testLoadCoursesCollectionsEmpty
testLoadCoursesCollectionsNonEmpty
testSetPasswordInvalid
testSetPasswordValid
testToString testUpdateActorStatusInvalid testUpdateActorStatusValid testUpdateLogInTimeInvalid testUpdateLogInTimeValid
Nagaan dat er een lege verzameling van studies wordt geretourneerd als de opgegeven kandidaat geen studies heeft ingevoerd. Nagaan dat er een gevulde verzameling van studies wordt geretourneerd als de opgegeven kandidaat minstens ´e´en studie heeft ingevoerd. Nagaan dat een paswoord niet gewijzigd kan worden als het oude opgegeven paswoord onjuist is, of de opgegeven kandidaat onbekend is. Nagaan dat een paswoord gewijzigd kan worden als het oude opgegeven paswoord juist is, en de kandidaat bekend is. Nagaan dat de string representatie van het object in een correct formaat staat. Nagaan dat de status van een gebruiker niet ge¨ update wordt als de opgegeven status niet bestaat. Nagaan dat de status van een gebruiker wordt ge¨ update naar de opgegeven status als deze bestaat. Nagaan dat het niet mogelijk is om de logindatum van een gebruiker te updaten naar een ongeldige waarde. Nagaan dat het mogelijk is om de logindatum van een gebruiker te updaten naar een geldige waarde.
MemberController In onderstaande tabel zijn de methodes voor het testen van de klasse MemberController beschreven. Testmethode
Functionaliteit
testAddMemberToCommitteeExisting
Nagaan dat het mogelijk is om een lid aan een commissie toe te voegen die bestaat. Nagaan dat het niet mogelijk is om een lid toe te voegen aan een commissie die niet bestaat. Nagaan dat als de opgegeven gebruiker lid is van de opgegeven commissie, dat dit bij opvragen dit wordt geretourneerd. Nagaan dat als de opgegeven gebruiker niet bestaat, of geen lid is van de opgegeven commissie, dat dit opvragen wordt geretourneerd. Nagaan dat de constructor private is. Nagaan dat createMember private is. Nagaan dat slechts ´e´en object wordt aangemaakt. Nagaan dat als een opgegeven lid bekend is, dat dit wordt geretourneerd.. Nagaan dat als een opgegeven lid onbekend is, dat dit wordt geretourneerd. Nagaan dat het niet mogelijk is om tweemaal een lid te registeren met dezelfde gegevens.
testAddMemberToCommitteeNonExisting testCheckMemberOfCommitteeExisting
testCheckMemberOfCommitteeNonExisting testConstructorNotPossible testCreateMemberNotPossible testGetInstanceOnlyOnce testMemberExistsExisting testMemberExistsNonExisting testRegisterMemberTwiceSameData
161
testRegisterMemberNonExisting testRegisterMemberTwiceOtherPassword testRegisterFullMemberTwiceSameData testRegisterFullMemberNonExisting testRegisterFullMemberTwiceOtherPassword testToString
Nagaan dat het mogelijk is om een lid te registeren als deze nog niet in de database voorkomt. Nagaan dat het niet mogelijk is om tweemaal een lid te registeren met dezelfde gegevens. Nagaan dat het niet mogelijk is om tweemaal een lid te registeren met dezelfde gegevens. Nagaan dat het mogelijk is om een lid te registeren als deze nog niet in de database voorkomt. Nagaan dat het niet mogelijk is om tweemaal een lid te registeren met dezelfde gegevens. Nagaan dat de string representatie van het object in een correct formaat staat.
PageController In onderstaande tabel zijn de methodes voor het testen van de klasse PageController beschreven. In tegenstelling tot de andere controllers krijgt de PageController direct zijn variabelen zonder verificatie. Verificatie in de PageController is daarom noodzakelijk. Testmethode
Functionaliteit
testConstruct
Nagaan dat de controller public is en een PageControllerobject retourneert. Nagaan dat er een leeg object wordt geretourneerd als er een leeg array of onbekend committeeID wordt opgegeven. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat er een leeg object wordt geretourneerd als er een lege naam wordt opgegeven. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat de juiste HTML code wordt geretourneerd als een extended login wordt opgevraagd. Nagaan dat de juiste HTML code wordt geretourneerd als een normale login wordt opgevraagd. Nagaan dat er een leeg object wordt geretourneerd als een lege id, lege naam, negatieve min of max, of als er een getal voor min dat groter is als het getal voor max wordt meegegeven. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat er een leeg object wordt geretourneerd als het meegegeven array, of de variabele element, leeg is. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat een leeg object wordt geretourneerd als een leeg id, lege naam, negatieve min of max, of als er een getal voor min dat groter is als het getal voor max wordt meegegeven.
testCreateCourseAndMappingsTextfieldsInvalid testCreateCourseAndMappingsTextfieldsValid testCreateDateInputInvalid testCreateDateInputValid testCreateLoginExtended testCreateLoginNormal tesCreatetMailInputInvalid
testCreateMailInputValid testCreateMultipleSelectorJSInvalid testCreateMultipleSelectorJSValid testCreateNumInputInvalid
162
testCreateNumInputValid testCreatePasswordInvalid
testCreatePasswordValid testCreateReadOnlyTextAreaInvalid testCreateReadOnlyTextAreaValid testCreateSelectorInvalid
testCreateSelectorValid testCreateTableInvalid
testCreateTableValid testCreateTextAreaInvalid
testCreateTextAreaValid testCreateTextInputInvalid
testCreateTextInputValid testCreateValuedMailInvalid
testCreateValuedMailValid testCreateValuedPasswordInputInvalid
Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat een leeg object wordt geretourneerd als een leeg id, lege naam, negatieve min of max, of als er een getal voor min dat groter is als het getal voor max wordt meegegeven. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. nagaan dat een leeg object wordt geretourneerd als een lege naam wordt meegegeven. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat er een leeg object wordt geretourneerd als de meegegeven naam van het array, of de naam die het resultaat moet krijgen, leeg is. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat er een leeg object wordt geretourneerd als de meegegeven naam van het array, of de naam die het resultaat moet krijgen, leeg is. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat een leeg object wordt geretourneerd als de meegegeven naam leeg is, of het aantal rijen en kolommen kleiner dan 1 is. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat een leeg object wordt geretourneerd als een leeg id, lege naam, negatieve min of max, of als er een getal voor min dat groter is als het getal voor max wordt meegegeven. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat een leeg object wordt geretourneerd als een leeg id, lege naam, negatieve min of max, of als er een getal voor min dat groter is als het getal voor max wordt meegegeven. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat een leeg object wordt geretourneerd als een leeg id, lege naam, negatieve min of max, of als er een getal voor min dat groter is als het getal voor max wordt meegegeven.
163
testCreateValuedPasswordInputValid testCreateValuedTextAreaInvalid
testCreateValuedTextAreaValid testCreateValuedTextInputInvalid
testCreateValuedTextInputValid testGetAdminMenu testGetCandidateMenu testGetFooter testGetHeader testSetFormInvalid testSetFormValid testToString testUpdateClickPathInvalid testUpdateClickPathValid
6.3
Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat een leeg object wordt geretourneerd als de meegegeven naam leeg is, of het aantal rijen en kolommen kleiner dan 1 is. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat een leeg object wordt geretourneerd als een leeg id, lege naam, negatieve min of max, of als er een getal voor min dat groter is als het getal voor max wordt meegegeven. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat de juiste HTML code wordt geretourneerd. Nagaan dat de juiste HTML code wordt geretourneerd. Nagaan dat de juiste HTML code wordt geretourneerd. Nagaan dat de juiste HTML code wordt geretourneerd. Nagaan dat een leeg object wordt geretourneerd als een lege form of negatief getal voor size wordt meegegeven. Nagaan dat de juiste HTML code wordt geretourneerd als alle input correct is. Nagaan dat de string representatie van het object in een correct formaat staat. Nagaan dat het clickpath niet wordt uitgebreid als de meegegeven url leeg is. Nagaan dat het clickpath wordt uitgebreid als de meegegeven url correct is.
Testen van de view-klassen
In deze paragraaf wordt het testen van de view-klassen besproken. Voor het testen van de view-klassen zullen twee typen testen worden uitgevoegd: 1. Functionaliteitstest. Test in hoeverre de functionaliteit van de applicatie overeenkomt met het PvE. De functionaliteit waaraan niet zal worden voldaan zal genoteerd worden. Vervolgens zal met de opdrachtgever overlegd worden of deze eisen nog ge¨ımplementeerd moeten worden. 2. Gebruikerstest. Test in hoeverre de gebruikers tevreden zijn met de applicatie. Deze test zal plaatsvinden na het bachelorproject. Hierbij zal voor iedere doelgroep van de applicatie enkele vrijwilligers worden uitgenodigd om de applicatie te testen.
164
Hoofdstuk 7
Testresultaten In dit hoofdstuk worden de testresultaten besproken wat betreft de tests zoals besproken in hoofdstuk 6. Ten eerste worden in paragraaf 7.1 de testresultaten van de model-klassen besproken. Vervolgens worden in paragraaf 7.2 de testresulaten van de controller-klassen behandeld. Tot slot worden in paragraaf 7.3 de websites van de applicatie behandeld.
7.1
Resultaten model-klassen
In deze paragraaf worden de resultaten van de model-klassen behandeld. In paragraaf 6.1 zijn de tests van de model-klassen uiteengezet. De tests zijn ge¨ımplementeerd in testfiles met behulp van het SimpleTest framework. De tests kunnen uitgevoerd worden met behulp van een webserver. Op http://dev.schuslerproductions.nl/src/test/ kunt u zelf de tests uitvoeren. Zoals uit deze resultaten blijkt, wordt aan alle tests voldaan.
7.2
Resultaten controller-klassen
In deze paragraaf worden de resultaten van de controller-klassen behandeld. In paragraaf 6.2 zijn de tests van de controller-klassen uiteengezet. Deze tests moeten manueel uitgevoerd worden. Aan bijna alle tests wordt voldaan, zoals bij de implementatie is getest. Een uitzondering op deze regel is de Page-klasse. Momenteel wordt in deze klasse er namelijk vanuit gegaan dat de gegeven parameters correct zijn. Voor een uitgebreide test van alle methodes was helaas geen tijd. Na het bachelorproject zal elk genoemde test worden doorlopen.
7.3
Resultaten view-klassen
In deze paragraaf worden de resultaten van de view-klassen behandeld. In paragraaf 6.3 zijn de tests van de view-klassen uiteengezet. Wat betreft de functionaliteit wordt aan alle eisen van de kandidaat en admin voldaan. Echter, het commissiegedeelte van de applicatie zal nog volledig moeten worden ge¨ımplementeerd. De gebruikerstest zal plaatsvinden na het bachelorproject, als de volledige applicatie is ge¨ımplementeerd.
165
Hoofdstuk 8
Conclusie In dit verslag is een klassendiagram opgesteld waarbij een duidelijk onderscheid is gemaakt tussen Model/View/Control. Op basis van deze scheiding zijn hoofdstuk 2 de verschillende methodes voor elke klas besproken. Vervolgens is in hoofdstuk 3 het implementatieproces besproken. Uit deze omschrijving blijkt het testplan gedeeltelijk nog moet worden uitgevoerd, het commissiegedeelte opgesteld moet worden, en dat nog moet worden gekeken naar een locatie om de applicatie te installeren. Ook blijkt dat de verwachtingen van de toelatingscommissies zeer hoog zijn, en dat ze onder de indruk waren van de huidige applicatie. Hierna werden in hoofdstuk 4 de ontwerpkeuzes en belangrijkste functies van de GUI besproken. Tijdens de implementatie is rekening gehouden met deze ontwerpkeuzes, waardoor een eenvoudige user-interface aan de gebruiker wordt getoond. Vervolgens is in hoofdstuk 5 het databasemodel en de implementatie besproken. Het databasemodel is hierbij zo generiek mogelijk opgezet, zodat op een later tijdstip uitbreidingen nog mogelijk zijn. Tot slot zijn in hoofdstuk 6 het testplan, en in hoofdstuk 7 de testresultaten besproken. Deze tests zullen de basis vormen van de kwalitatieve software die door de toelatingscommissies wordt verwacht.
166
Bijlage A
Planning
status
status
datum 10/02/2010 15/02/2010 15/02/2010 01/03/2010 10/03/2010 15/03/2010 26/03/2010 26/03/2010 28/03/2010 02/04/2010 05/04/2010 06/04/2010 12/04/2010 18/04/2010 25/04/2010
Tabel A.1: Planning ontwerpfase taak bijzonderheden programma van eisen concept probleemanalyse actorenalayse grafische interface artists impression van user interface programma van eisen final (na overleg met toelatingscommissies) use cases concept database design scenario’s concept use cases final (na overleg met selectie) scenario’s final (na overleg met selectie) klassendiagram sequence diagram grafische interface final (na overleg met selectie) functie blokschema morfologische kaart
datum 18/05/2010 18/05/2010 18/05/2010 24/05/2010 31/05/2010 10/06/2010
Tabel A.2: Planning implementatiefase taak bijzonderheden model development controller development view development core testen gebruikerstesten (core) beta bugfixing gebruikerstesten (high level) release candidate bugfixing gebruikerstesten (goedkeuring)
167
status
datum 14/06/2010 17/06/2010 18/06/2010
Tabel A.3: Planning testfase taak bijzonderheden release testen code testen gebruikerstesten
status
datum 27/06/2010 27/06/2010
Tabel A.4: Planning pilotfase taak manual beheerderstools overhandigen en uitleg geven
168
bijzonderheden
Bijlage B
Definitielijst Begrip
Definitie
Actorenanalyse
Onderdeel van het verslag waarbij de doelen van de doelgroep worden bepaald, de problemen die optreden bij het behalen van deze doelen, en de oplossingen voor de problemen. Een advies is een formulier uitgegeven door een toelatingscommissie dat minimaal bestaat uit de vakken die de kandidaat moet volgen om zijn vakdefici¨enties weg te werken. Het wegwerken van de defici¨enties in het advies geeft toegang tot de Universitaire Leraren Opleiding. Het “Alle H@nds Aan Dek” project is een project met als doel de instroom en het studiesucces van studenten van de universitaire lerarenopleidingen te verhogen. De applicatie is onderdeel van werkpakket 4A. Onderdeel van het AHAD-project. Door E-learning-trajecten kan men door zelfstudie online een vak leren. Hierdoor is een kandidaat met een vakdefici¨entie niet aan een locatie en tijd gebonden voor het vak. Set van vakkenpakketten, mappingen, geadviseerde vakken, en cijferlijst van een kandidaat. Het betreft een gegeven wat voordat de applicatie actief is geworden is verkregen. Deze gegevens kunnen door een admin in de database worden gezet met behulp van de “historisch gegeven toevoegen” functie. Een schatting van de studielast dat het kost voor een kandidaat om zijn vakdefici¨enties weg te werken. De schatting zal in de applicatie gebaseerd worden op de opleidingen van de kandidaat. In de context van de applicatie, is een kandidaat een persoon die gebruik maakt van de applicatie om een advies aan te vragen, een indicatie wil, of contact op wil nemen met een toelatingscommissie.
Advies
AHAD
E-learning-trajecten
Historisch gegeven
. Indicatie
Kandidaat
169
Kerndomeinen
Kwaliteitseisen
Mappen Programma Van Eisen
Requirements document
Secretaris
Shopper Subdomeinen
Toelatingscommissie
Universitaire Leraren Opleiding
Vakdefici¨entie VSNU-gids
Elk schoolvak heeft een aantal kerndomeinen. Dit zijn de globale onderwerpen waar een kandidaat kennis over moet hebben om toegelaten te worden tot de Universitaire Leraren Opleiding voor het schoolvak. Eisen waar een applicatie aan moet voldoen om een kwalitatief product te zijn. Bij een kwalitatief product zijn maatregelen getroffen om het product eenvoudig onderhoud- en uitbreidbaar te maken. Betreft het benoemen van het sub- of kerndomein(en) waartoe een gevolgd vak van een kandidaat behoort. Dit onderdeel van het verslag bevat de eisen waar de applicatie aan moet voldoen om de problemen die in de actorenanalyse zijn gedefinieerd op te lossen. Een requirements document beschrijft de eisen waar een product aan moet voldoen. Dit verslag is een requirements document dat is uitgebreid met een actorenanalyse. Een secretaris is in deze applicatie gedefinieerd als de persoon die in het nieuwe proces degene is die bepaalt of een aanvraag voor een toelatingcommissie-account toegelaten of geblokkeerd wordt. Kandidaat die bij meerdere toelatingscommissies een advies aanvraagt met als doel het advies op te volgen wat hij het best vindt. De kerndomeinen die bij een schoolvak horen, zijn opgesplitst in subdomeinen. Deze subdomeinen zijn de onderwerpen waar een kerndomein uit bestaat. Een toelatingscommissie is een bevoegd team op een universiteit die een advies opstelt voor een kandidaat voor een vastgesteld schoolvak. In de applicatie is een toelatingscommissie gedefinieerd als een schoolvak/universiteit-paar. In de werkelijke situatie kan een toelatingscommissie gespecialiseerd zijn in meerdere vakken. In dat geval wordt in de applicatie de toelatingscommissie opgesplitst in meerdere toelatingscommissies. Er zijn verschillende ULO’s in Nederland. Een kandidaat heeft toegang tot een ULO als hij al zijn vakdefici¨enties, die bepaald zijn door een toelatingscommissie, heeft weggewerkt voor een bepaald schoolvak. Na het voltooien van de ULO is de kandidaat officieel een eerstegraads-docent. Een kandidaat heeft een vakdefici¨entie als deze onvoldoende kennis en ervaring bezit in een kern- of subdomein van een schoolvak. Een gids opgesteld door de Vereniging Van Universiteiten. Deze gids geeft voor elk schoolvak aan welke kern- en subdomeinen een kandidaat moet beheersen om toegelaten te worden tot de ULO.
170
Bijlage D
Presentatie werkpakket 4A
171
INHOUD 1. Waar staan we? 2. Applicatie 3. Kandidaat 4. Commissie 5. Admin 6. Vragen en discussie
APPLICATIE VOOR AANVRAGEN STUDIE TOELATINGSADVIES 17/06/2010
17/06/2010
Applicatie Voor Aanvragen Studieadvies
ROADMAP Roadmap
17/06/2010
Applicatie
Kandidaat
DOEL VAN APPLICATIE Commissie
Admin
Roadmap
Applicatie Voor Aanvragen Studieadvies
Applicatie
Kandidaat
Verwerken adviezen vereenvoudigen
•
Shoppers vroegtijdig opmerken
•
Gebruik van landelijke historische gegevens
•
Reduceren van verschillen
•
Transparantie van het proces
17/06/2010
•
Webbased applicatie
•
Invoer van de kandidaat
•
Taak van de ULO
•
Gebruik van historische gegevens
Commissie
Kandidaat
•
PROGRAMMA VAN EISEN Roadmap
Applicatie
Applicatie Voor Aanvragen Studieadvies
Admin
Applicatie Voor Aanvragen Studieadvies
HISTORISCHE GEGEVENS Admin
Roadmap
Applicatie
Kandidaat
172 17/06/2010
Commissie
17/06/2010
Applicatie Voor Aanvragen Studieadvies
Commissie
Admin
KANDIDAAT Roadmap
17/06/2010
Applicatie
Kandidaat
PROFIELSCHERM Commissie
Admin
Roadmap
17/06/2010
Applicatie Voor Aanvragen Studieadvies
Applicatie
Kandidaat
Commissie
Kandidaat
Commissie
ADVIES AANVRAGEN Admin
Roadmap
Applicatie
Kandidaat
Commissie
•
Opzoeken van de studie in historische gegevens
•
Schoolvak selecteren
•
Vakkenpakket zelf definiëren
•
Bestaande toekenning van een vakkenpakket hergebruiken
•
Vakkenpakket hergebruiken
•
Invullen van een toekenning
•
Selecteren en opsturen naar een commissie
17/06/2010
Applicatie Voor Aanvragen Studieadvies
17/06/2010
TOELATINGSCOMMISSIE Roadmap
Applicatie
Kandidaat
Commissie
Applicatie Voor Aanvragen Studieadvies
Admin
Applicatie Voor Aanvragen Studieadvies
INBOX BEKIJKEN Admin
Roadmap
Applicatie
Kandidaat
173 17/06/2010
Admin
Applicatie Voor Aanvragen Studieadvies
STUDIE TOEVOEGEN Roadmap
Applicatie
17/06/2010
Applicatie Voor Aanvragen Studieadvies
Commissie
Admin
TOEKENNING KANDIDAAT CONTROLEREN Roadmap
Applicatie
17/06/2010
Kandidaat
Commissie
ADVIES OPSTELLEN
Admin
Roadmap
17/06/2010
Applicatie Voor Aanvragen Studieadvies
ADMIN Roadmap
Applicatie
18/06/2010
Kandidaat
Applicatie Voor Aanvragen Studieadvies
Admin
Applicatie Voor Aanvragen Studieadvies
•
De voorkeur van elk vak voor kern- of subdomeinen
•
Een layout voor alle ULO’s
•
Locatie van de uiteindelijke applicatie
•
Certificaten
•
Alle vakken van een schoolvak opvragen
•
Uitleg bij domeinen
•
Toegang als administrator
17/06/2010
174 Applicatie Voor Aanvragen Studieadvies
Kandidaat
Vragen? Commissie
Discussie
17/06/2010
Applicatie
Applicatie Voor Aanvragen Studieadvies
Commissie
Admin
