EINDVERSLAG
Projectgroep
Willem-Jan Meerkerk
Ruben Vroegindeweij
Johnny Verhoeff
Koos van der Linden
Opdrachtgever
TU Coach
Project coördinator
Project coördinator
Matéo Mol
Bas Jansen
Felienne Hermans
Martha Larson
TU Delft, 24-6-2014
SAMENVATTING
Spreadsheets spelen een belangrijke rol in allerlei industrieën en in allerlei verschillende domeinen.
De manier waarop spreadsheets ingevuld worden, laat echter vaak te wensen over. Er zitten vaak
fouten in gecompliceerde spreadsheets, zoals lege cellen, veranderde formaten, verwijzingen naar
niet-bestaande cellen, enzovoorts.
In de praktijk blijkt dat spreadsheets vaak door meerdere mensen beheert en ingevuld worden. Het
zou in dit geval wenselijk zijn om regels op te stellen waaraan een ingevulde spreadsheet zou moeten
voldoen. Dit zou kunnen voorkomen dat (gedeeltelijk) fout ingevulde spreadsheets uitgewisseld
worden binnen een organisatie.
Infotron wil een oplossing aanbieden voor dit probleem: het incorrect en onvolledig invullen van
spreadsheets. Hiervoor wil het een systeem genaamd DeliverXL op de markt brengen dat een maker
van een spreadsheet template de mogelijkheid geeft voorwaarden te stellen aan het invullen van
deze spreadsheet. Wij, vier derdejaarsstudenten aan de Technische Universiteit te Delft, zijn deze
uitdaging voor het bacheloreindproject aangegaan. Bij dit project is het de bedoeling te laten zien dat
men in staat is om succesvol een volledig softwareproject te doorlopen.
Het ontwikkelde eindproduct DeliverXL biedt de mogelijkheid om op gebruiksvriendelijke manier
voorwaarden voor een spreadsheet op te geven. In het systeem is er onderscheid gemaakt tussen
managers die spreadsheets van voorwaarden voorzien, en submitters die ingevulde spreadsheets
inleveren. Managers hebben een overzicht van alle ingeleverde en gecontroleerde spreadsheets.
Submitters hebben een overzicht van alle spreadsheets die ze nog moeten invullen. Bij het inleveren
van een ingevulde spreadsheet wordt het bestand automatisch door het systeem gecontroleerd en
ontvangt de submitter uitgebreide feedback mocht het bestand niet goed ingevuld zijn.
De ontwikkeling van DeliverXL is opgedeeld in zogenaamde milestones. Aan het einde van elke
milestone was een werkend product beschikbaar. Het product is ontwikkeld als webapplicatie met
een Model View Controller opdeling. Doordat het systeem uitgebreid is getest is de kwaliteit van het
eindproduct gewaarborgd. De implementatie is door feedback van de Software Improvement Group
kwalitatief verbeterd, waardoor de code goed te onderhouden is en geschikt is voor uitbreiding.
Het product zoals het nu is, zou in principe in huidige staat op de markt gebracht kunnen worden.
Toch zouden wij adviseren, op basis van feedback uit het bedrijfsleven, nog extra functionaliteit toe
te voegen om het product commercieel aantrekkelijker te maken.
INHOUD
Samenvatting........................................................................................................................................... 2
Voorwoord .............................................................................................................................................. 5
1. Inleiding ............................................................................................................................................... 6
2. Probleembeschrijving en -analyse....................................................................................................... 7
2.1. Context ......................................................................................................................................... 7
2.2. Opdrachtomschrijving .................................................................................................................. 7
2.3. Eisen ............................................................................................................................................. 8
3. Proces ................................................................................................................................................ 10
3.1. Ontwikkelmethode ..................................................................................................................... 10
3.2. Milestones .................................................................................................................................. 10
3.3. Proces verslag ............................................................................................................................. 13
3.4. Praktijkonderzoek....................................................................................................................... 14
3.5. Reflectie ...................................................................................................................................... 15
4. Ontwerp............................................................................................................................................. 17
4.1. Soort applicatie........................................................................................................................... 17
4.2. Het uitlezen van een Excel bestand............................................................................................ 17
4.3. Programmeertaal ....................................................................................................................... 18
4.4. Dataopslag .................................................................................................................................. 18
4.5. Programmastructuur .................................................................................................................. 19
4.6. API voor het weergeven van een Excel interface ....................................................................... 20
5. Implementatie ................................................................................................................................... 21
5.1. Model ......................................................................................................................................... 21
5.1.1. Data klassen......................................................................................................................... 21
5.1.2. Database: Entity Framework ............................................................................................... 29
5.2. View ............................................................................................................................................ 33
5.2.1. Weergave van een model in de view .................................................................................. 33
5.2.2. View van models met hiërarchie ......................................................................................... 34
5.2.3. Bootstrap ............................................................................................................................. 35
5.2.4. Handsontable ...................................................................................................................... 35
5.2.5. Overige frameworks ............................................................................................................ 37
5.3. Controller.................................................................................................................................... 38
5.3.1. Algemeen............................................................................................................................. 38
5.3.2. HomeController ................................................................................................................... 39
3
5.3.3. BaseController ..................................................................................................................... 40
5.3.4. AccountController ............................................................................................................... 40
5.3.5. ConstraintSetController ..................................................................................................... 41
5.3.6. UploadedFileController ...................................................................................................... 42
5.4. Utils............................................................................................................................................. 43
5.5. Controle van voorwaarden ......................................................................................................... 45
5.6. Deployment ................................................................................................................................ 50
5.7. Evaluatie ..................................................................................................................................... 51
5.7.1. Testmethoden ..................................................................................................................... 51
5.7.2. Testuitkomsten .................................................................................................................... 52
5.7.3. SIG feedback ........................................................................................................................ 54
6. Conclusie ........................................................................................................................................... 55
7. Aanbevelingen ................................................................................................................................... 56
7.1. Extra milestones ......................................................................................................................... 56
7.2. Toelichting op extra milestones ................................................................................................. 57
Referenties ............................................................................................................................................ 58
Bijlagen .................................................................................................................................................. 59
4
VOORWOORD
Als afsluiting van de Bachelor Technische Informatica aan de Technische Universiteit in Delft dient
een bacheloreindproject gedaan te worden. Bij dit project is het de bedoeling te laten zien dat men
in staat is om succesvol een volledig softwareproject te doorlopen. Het bacheloreindproject waar dit
rapport verslag van doet is uitgevoerd bij het bedrijf Infotron met Matéo Mol als opdrachtgever en
Bas Jansen als begeleider van de TU.
In dit verslag wordt uitgelegd hoe het product DeliverXL tot stand gekomen is en hoe het
ontwikkelproces verlopen is. Hierin wordt regelmatig terug gegrepen op het plan van aanpak en het
onderzoeksrapport, twee documenten aan het begin van het project zijn opgesteld. Er wordt vanuit
de opdrachtomschrijving toegewerkt naar een probleemstelling en uitgelegd waarom het geleverde
product een oplossing is voor dit probleem. Een ander team moet door het lezen van het eindverslag
in staat zijn het systeem te gebruiken of op het systeem voort te bouwen.
5
1. INLEIDING
Spreadsheets worden veel gebruikt in allerlei industrieën. Ze zijn het gereedschap voor financiële
analyse en domineren ook in andere domeinen, zoals logistiek en planning. De flexibiliteit en de
onmiddellijke feedback zorgen ervoor dat ze makkelijk te gebruiken zijn voor mensen zonder
programmeervaardigheden. De manier waarop mensen spreadsheets invullen en onderhouden laat
vaak te wensen over. Er zitten vaak fouten in gecompliceerde spreadsheets, zoals lege cellen,
veranderde formaten, verwijzingen naar niet-bestaande cellen, enzovoorts.
Een spreadsheet wordt vaak gemaakt alsof maar één persoon ermee te maken gaat krijgen. Maar in
de praktijk blijkt ze gemiddeld gebruikt te worden door ruim 13 verschillende personen en voor meer
dan vijf jaar. Daarnaast ontbreekt bij ongeveer twee derde van alle spreadsheets een uitleg of
documentatie. Er wordt ongeveer zeven miljard dollar op jaarbasis verspild als gevolg van incorrect
gebruik van spreadsheets [1]. Als alle problemen verholpen kunnen worden, zouden bedrijven
efficiënter kunnen werken en minder geld hoeven te spenderen aan het achteraf oplossen van
fouten die door een spreadsheet veroorzaakt zijn.
Het incorrect invullen van zo’n spreadsheet is een veel voorkomend probleem. Vooral bij bedrijven
die regelmatig gebruik maken van spreadsheets is dit het geval. Neem bijvoorbeeld het bedrijf van
Eric. Eric is werkgever van een bedrijf met dertig werknemers. Het bedrijf houdt zich bezig met de
financiën van individuele personen en helpt deze personen bij hun inkomsten- en uitgavenpatroon.
Omdat een cliënt vaak door meerdere werknemers geholpen wordt, worden spreadsheets gebruikt
om de financiën in kaart te brengen. Echter vullen de werknemers van het bedrijf de spreadsheets
verschillend van elkaar in, wat vaak tot verwarring leidt.
Infotron wil een oplossing aanbieden voor dit probleem: het incorrect en onvolledig invullen van
spreadsheets. Hiervoor wil het een systeem genaamd DeliverXL op de markt brengen dat een maker
van een spreadsheet template de mogelijkheid geeft voorwaarden te stellen aan het invullen van
deze spreadsheet. Wij, vier derdejaarsstudenten aan de Technische Universiteit te Delft, zijn deze
uitdaging voor het bacheloreindproject aangegaan.
Het doel van DeliverXL is om op een gebruiksvriendelijke manier een set van voorwaarden op te
geven waaraan een ingevulde spreadsheet dient te voldoen. Een ingevulde spreadsheet kan
hiertegen automatisch gevalideerd worden, waardoor de persoon die de spreadsheet heeft ingevuld
direct inzicht krijgt in mogelijke fouten. Op deze manier wordt het ontvangen van foutief of
onvolledig ingevulde bestanden verhinderd.
In dit rapport wordt verslag gedaan van de ontwikkeling van DeliverXL en uitgelegd hoe dit product
een oplossing is voor het genoemde probleem. Hiervoor wordt allereerst in hoofdstuk 2 een
probleembeschrijving- en analyse gegeven, waar onder andere de eisen aan DeliverXL verder worden
gespecificeerd. In hoofdstuk 3 wordt de ontwikkelmethode en het ontwikkelproces besproken, met
daarbij een korte reflectie hierop. Vervolgens wordt in hoofdstuk 4 het ontwerp van DeliverXL
uitgelegd, waarna in hoofdstuk 5 een bespreking volgt van belangrijke elementen uit de
implementatie. Deze twee hoofdstukken zijn hoofdzakelijk bedoeld voor lezers met ervaring als
softwareontwikkelaar, om een beeld te geven van de achterliggende werking van DeliverXL.
Als afsluiting wordt in hoofdstuk 6 geconcludeerd of het benoemde doel behaald is, waarna tenslotte
in hoofdstuk 7 een overzicht volgt van aanbevelingen om dit ontwikkelproces voort te zetten.
6
2. PROBLEEMBESCHRIJVING EN -ANALYSE
In dit hoofdstuk wordt ingegaan op het probleem waar DeliverXL een oplossing voor moet bieden.
Allereerst wordt de context van dit probleem toegelicht, om zo meer inzicht te krijgen in het
probleem. Vervolgens wordt ingegaan op de opdrachtomschrijving met daarbij de analyse die hierop
is uitgevoerd. Tenslotte volgt er een opsomming van de eisen aan DeliverXL.
2.1. Context
Veel organisaties hebben centraal personeel voor het consolideren van getallen in spreadsheets,
voor zowel financiële als andere doeleinden. Deze getallen komen van verschillende werknemers van
verschillende afdelingen binnen een organisatie. Vaak wordt er geklaagd over de kwaliteit van de
aangeleverde spreadsheets door het centrale personeel. Na het maken van een spreadsheet wordt
er vanuit gegaan dat de spreadsheet correct is. Uit onderzoek blijkt echter dat 86% van de
onderzochte spreadsheets incorrect is [2].
De fouten die worden gemaakt in spreadsheets kunnen op een aantal manier worden
onderverdeeld. De volgende onderscheiding wordt gemaakt door Panko [3]:
Kwantitatieve en kwalitatieve fouten
Een eerste onderverdeling is het onderscheid tussen kwalitatieve en kwantitatieve en fouten.
Kwalitatieve fouten hebben te maken met de opbouw en structuur van een spreadsheet. Een zwak
spreadsheetontwerp kan hierbij voor latere problemen zorgen, bijvoorbeeld foutieve aanpassingen.
Kwantitatieve fouten hebben te maken met de invoer van spreadsheets. Deze fouten zijn weer onder
te verdelen in mechanische, weglatings-, en logicafouten.
Mechanische, weglatings- en logicafouten
Mechanische fouten zijn simpele fouten aan de invoer, zoals typefouten of het door elkaar halen van
punten en komma’s bij de invoer van getallen. Weglatingsfouten slaan op ontbrekende gegevens in
een spreadsheet, bijvoorbeeld het vergeten in te vullen van een cel of het ontbreken van een
werkblad. Hierdoor is het model niet volledig en kunnen mogelijk formules niet geëvalueerd worden.
Logicafouten komen voor bij het opstellen van formules. Voorbeelden hiervan zijn het gebruik van
onjuiste functienamen, het opnemen van incorrecte ranges in een functie of formules die resulteren
in een fout. Ook het verkeerd overzetten van een formule hoort bij deze fouten.
Life cycle fouten
Een spreadsheet wordt soms meer dan vijf jaar gebruikt en door meer dan dertien personen
onderhouden. Tijdens de life cycle van een spreadsheet worden verschillende processen uitgevoerd,
zoals ontwerp, analyse, invullen en testen. Tijdens elk van deze stadia kunnen er fouten optreden; dit
worden life cycle fouten genoemd.
2.2. Opdrachtomschrijving
Vanuit de opdrachtgever was er een duidelijke opdrachtformulier, de oorspronkelijke versie hiervan
is te vinden in Bijlage A. De opdracht houdt in dat er een programma genaamd DeliverXL moet
worden ontwikkeld wat veel van de eerder beschreven problemen met spreadsheets kan oplossen.
Dit programma streeft ernaar het mogelijk te maken op een gebruiksvriendelijke manier
voorwaarden op te geven waaraan een spreadsheet dient te voldoen. Op basis van de opgestelde
voorwaarden moet een ingevulde spreadsheet automatisch gevalideerd kunnen worden, waardoor
7
direct duidelijk wordt welke mogelijke fouten er in de spreadsheet aanwezig zijn. Afhankelijk van het
resultaat van de validatie kan een spreadsheet alleen worden ingeleverd als er aan alle voorwaarden
wordt voldaan.
Van het projectteam wordt verwacht een werkende demo van DeliverXL te kunnen geven binnen
tien à elf weken. Al het werk dat tijdens het project gedaan wordt, dient goed gedocumenteerd te
worden, zodat een ander team het programma verder kan ontwikkelen zodra ze de documentatie
gelezen hebben. Onderdeel van het project is ook een beginfase, waarin het projectteam een analyse
doet van het probleem en nadenkt over planning en onderzoek.
Onderdeel van de probleemanalyse was het maken van een flow-chart op basis van de
opdrachtomschrijving, zoals te zien in Figuur 1. Deze flow-chart maakt de functionaliteit van
DeliverXL inzichtelijk en is tot stand gekomen na gesprekken met opdrachtgever. Tijdens deze
gesprekken is besproken wat de opdrachtgever van het systeem verwacht en hoe het in zijn visie zou
moeten werken.
Figuur 1 - Flowchart van het gebruik van DeliverXL
2.3. Eisen
Een volgende stap van de probleemanalyse was het maken van een lijst van eisen aan DeliverXL,
waardoor de opdrachtomschrijving verder gespecificeerd en concreet gemaakt wordt. De lijst van
eisen is opgesteld volgens de MoSCoW methode, wat een afkorting is voor must have, should have,
could have en would have. Deze manier maakt het mogelijk om de eisen onder te verdelen in
verschillende prioriteit. Hieronder volgt de lijst met eisen, opgesteld in de vorm van user stories.
Must have
 Als een manager wil ik mijn bestaande spreadsheet template van voorwaarden voorzien.
Voorwaarden omvatten:
o Een cel is (niet) leeg.
o Een cel bevat (niet) een nummer tussen bepaalde waardes/een datum/tekst/een
getal.
8












o Een cel bevat (g)een fout.
o Een cel bevat (g)een formule.
Als een werknemer wil ik weten of een mijn ingeleverde spreadsheet voldoet aan de
voorwaarden die zijn opgesteld door de manager.
Als een manager en als werknemer wil ik dat het systeem gebruiksvriendelijk is.
Als een manager wil ik mijn voorwaardensets kunnen wijzigen en verwijderen.
Als een werknemer wil ik feedback ontvangen wanneer de spreadsheet niet voldoet.
Als een manager wil ik een overzicht van alle spreadsheettemplates en de door de
werknemer ingeleverde spreadsheetbestanden hebben.
Als een manager, werknemer en als administrator wil ik kunnen inloggen op het systeem.
Als een manager wil ik voorwaardensets kunnen toewijzen aan werknemers.
Als een werknemer wil ik een overzicht hebben van alle toegewezen voorwaardensets.
Als een werknemer wil ik dat het systeem mij van de toegewezen templates voorziet.
Als een manager wil ik een overzicht hebben van alle correct ingeleverde bestanden.
Als een administrator wil ik een overzicht hebben van alle gebruikers.
Als een administrator wil ik gebruikers kunnen toevoegen, wijzigen en verwijderen.
Should have
 Als een manager wil ik mijn voorwaardenset met andere managers kunnen delen.
 Als een manager wil ik de overzichten van ingeleverde bestanden filteren.
 Als een manager wil ik voorwaarden opstellen voor reeksen van cellen.
 Als een manager wil ik voorwaarden opstellen op de gehele spreadsheet.
Could have
 Als een manager wil ik de template kunnen vervangen.
 Als een manager wil ik posities van voorwaarden op één of meerdere cellen kunnen
verplaatsen.
9
3. PROCES
In dit hoofdstuk wordt besproken hoe het ontwikkelproces van DeliverXL is verlopen en welke
aanpak hierbij is gekozen. Allereerst wordt de ontwikkelmethode beschreven, met daarbij een
opsomming van de gebruikte milestones. Daarna wordt er verslag gedaan van het verloop van het
proces en ten slotte volgt een korte reflectie hierop.
3.1. Ontwikkelmethode
Aan het begin van het ontwikkelproces is ervoor gekozen het gehele project op te delen in
zogenaamde milestones. Dit zijn prototypes van het product waarbij telkens nieuwe functionaliteit
wordt toegevoegd. Door te starten met een eenvoudig prototype en deze bij iedere milestone uit te
breiden met meer functionaliteit, was er al vanaf het begin van de ontwikkelfase een werkend
product. Bovendien waren de milestones een duidelijke afbakening van subonderdelen van het
product. Deze aanpak is een variant van het incremental build model, waarbij de ontwikkeling van
het eindproduct wordt opgedeeld in meerdere componenten die achter elkaar kunnen worden
ontwikkeld.
Verder was het van belang om het ontwikkelproces zo flexibel mogelijk te houden. Het was immers
goed mogelijk dat de functionaliteit in de loop van het ontwikkelproces nog zou veranderen,
bijvoorbeeld op basis van feedback van de opdrachtgever. Daarom is ervoor gekozen om te werken
volgens een vorm van Scrum, waarbij gewerkt is met sprints van één week. Aan het eind van iedere
week kon er zodoende een meeting zijn, waarbij een demonstratie werd gegeven van de huidige
versie van DeliverXL. Hierdoor was de opdrachtgever actief betrokken bij het ontwikkelproces en kon
er gecontroleerd worden of de ontwikkeling nog in lijn is met de ideeën van de opdrachtgever.
Uiteindelijk is er een combinatie van het incremental build model en Scrum gebruikt; zie het
onderzoeksverslag in Bijlage C voor een uitgebreidere toelichting van deze ontwikkelmethoden. De
milestones werden wel van te voren vastgesteld, maar per sprint werd in overleg met de
opdrachtgever vastgesteld welke functionaliteit ontwikkeld zou worden.
3.2. Milestones
Hieronder volgt een opsomming van de milestones van DeliverXL, zoals grotendeels vastgesteld aan
het begin van het project. Tijdens het ontwikkelproces zijn er naar aanleiding van het overleg met de
opdrachtgever en de TU coach items toegevoegd aan de milestones, deze items zijn groen
gemarkeerd. Rood gemarkeerde items zijn achteraf niet opgenomen in de milestones.
Milestone 1
 Webformulier met de mogelijkheid om een vastgesteld Excel bestand te uploaden. Dit
Excel bestand bevat enkel drie cellen: één met een naam, één met een leeftijd en één
met een geboortedatum.
 Uitlezen van het geüploade Excel bestand.
 Controleren van drie voorwaarden: cel is van het type tekst, getal of datum. Cellen die
gecontroleerd worden zijn hardcoded en komen overeen met het vastgestelde Excel
bestand.
 Weergave van het resultaat: OK of niet OK.
10
Milestone 2
 Webformulier waar meerdere voorwaarden kunnen worden opgeven (voorwaardenset).
Per voorwaarde wordt er een cel en het datatype (tekst, getal, datum) ingevuld.
 In het formulier kan ook een naam voor de voorwaardenset worden opgegeven.
 Bij het uploadformulier kan met een dropdown menu een voorwaardenset gekozen
worden om het Excel bestand mee te controleren.
 Voorwaarden in een voorwaardenset kunnen ook aangepast en verwijderd worden.
Milestone 3
 Mogelijkheid om in te loggen als gebruiker. Gebruikers staan hardcoded opgeslagen in de
database; een gebruiker kan een manager en/of werknemer zijn. Een manager heeft
toegang tot het formulier waar voorwaarden kunnen worden opgegeven, een
werknemer heeft toegang tot het formulier om Excel bestanden te uploaden.
 Manager kan bij het maken van een voorwaardenset werknemers(s) selecteren.
 Manager kan bij het maken van een voorwaardenset andere manager(s) selecteren als
beheerder van die voorwaardenset.
 Dropdown menu bij het uploadformulier bevat alleen voorwaardensets die zijn
toegewezen aan de ingelogde werknemer.
Milestone 4
 Manager heeft een overzicht van alle correct geüploade bestanden.
 Werknemer heeft een overzicht van alle door hem geüploade bestanden.
 Manager ontvangt een email notificatie wanneer een correct bestand is geüpload.
Milestone 5
 Na het uploaden van een Excel bestand wordt er tekstuele feedback gegeven wanneer er
fouten in het bestand voorkomen.
 Meer verschillende voorwaarden kunnen aan cellen worden opgelegd:
o Leeg / niet leeg
o Bevat (g)een formule
o Bevat (g)een fout
o Getal / datum tussen bepaalde waardes
o Tekst bevat minimaal / maximaal aantal tekens
 Alle soorten voorwaarden zijn uitgebreid getest (unit tests) met veel verschillende
combinaties.
Milestone 6
 Manager kan bij het maken van een voorwaardenset de Excel template uploaden.
 Werknemer heeft een overzicht van alle aan hem toegewezen voorwaardensets en kan
hier de Excel template downloaden.
 Bij het uploaden van het Excel bestand wordt de daarbij horende voorwaardenset
automatisch geselecteerd (op basis van metadata).
Milestone 7
 Manager heeft een overzicht van al voorwaardensets die hij kan beheren.
 Manager kan voorwaardensets ook wijzigen en verwijderen. Bij het wijzigen van een
voorwaardenset kunnen de naam, de voorwaarden en de toegewezen managers en
werknemers van deze voorwaardenset worden aangepast.
11

Manager kan bij het wijzigen van een voorwaardenset ook een nieuwe Excel template
uploaden (mits deze niet conflicterend is met de huidige voorwaarden).
 Werknemer heeft na het uploaden van een correct bestand een knop om het bestand op
te sturen naar de manager (dit gebeurt niet meer automatisch). Voor de manager zijn
enkel de opgestuurde bestanden zichtbaar, de werknemer ziet zowel de geüploade als
opgestuurde bestanden.
 Werknemer kan de geüploade bestanden verwijderen.
 Manager kan de opgestuurde bestanden verwijderen.
 Manager heeft per voorwaardenset een overzicht van de werknemers die zijn
toegewezen aan deze voorwaardenset. In dit overzicht is per werknemer zichtbaar of er
al een bestand is opgestuurd.
 Eventuele fouten in het programma worden op een nette manier weergeven.
Milestone 8
 De lijst met geüploade / opgestuurde bestanden kan gefilterd worden (bijvoorbeeld op
voorwaardenset, datum, werknemer).
 De lijst met voorwaardensets van de manager wordt uitgebreid met een link naar de
gefilterde lijst met opgestuurde bestanden voor die voorwaardenset.
 De lijsten met geüploade / opgestuurde bestanden, voorwaardensets en templates
kunnen gesorteerd worden.
Milestone 9
 Nieuwe gebruikersrol ‘administrator’ wordt toegevoegd. Een administrator heeft een
overzicht van alle gebruikers.
 Gebruikers kunnen door de administrator beheerd worden (toegevoegd, aangepast en
verwijderd).
 Een ingelogde gebruiker heeft de mogelijkheid om zijn eigen accountgegevens aan te
passen.
Milestone 10
 De manager kan in een gebruiksvriendelijke interface de voorwaarden invoeren.
Milestone 11
 Meer voorwaarden kunnen worden toegevoegd aan cellen, bijvoorbeeld:
o Voorwaarden kunnen ook geformuleerd worden als ‘bevat’. Bijvoorbeeld:
- Een cel bevat een getal.
- Een cel bevat tekst.
 Meer voorwaarden kunnen worden toegevoegd, die niet gebaseerd zijn op een enkele
cel. Bijvoorbeeld:
o De Excel template is niet aangepast (niet-lege cellen uit de Excel template zijn
dus hetzelfde als in het geüploade Excel bestand).
o Voorwaarden op een reeks cellen:
- Voor elke cel in een reeks geldt dezelfde voorwaarde.
- Voor een functie over de reeks geldt een voorwaarde (zoals som,
gemiddelde).
o Voorwaarden op de gehele spreadsheet:
- De spreadsheet bevat een minimum/maximum tabbladen.
- De spreadsheet bevat geen fouten.
12
o
Voorwaarden zijn generiek te formuleren door het invullen van een
Excelformule, die een boolean retourneert, bijvoorbeeld:
=EN(ISGETAL(A1); IS.ONEVEN(A1); GROTER.DAN(A1;100))1
3.3. Proces verslag
Het project is grofweg onderverdeeld in een plannings-, onderzoeks-, implementatie- en
afrondingsfase.
In de eerste week, de planningsfase, was de aandacht vooral gericht op het schrijven van een plan
van aanpak (zie Bijlage B) en twee afspraken met de opdrachtgever en de TU coach. Er was al een
redelijk concrete opdrachtomschrijving (zie Bijlage A); op basis hiervan is er allereerst een
eenvoudige flowchart gemaakt om de functionaliteit van DeliverXL in hoofdlijnen duidelijk te krijgen
(zie Figuur 1 in paragraaf 2.2). Deze flowchart is ter bevestiging tijdens de eerste meeting aan de
opdrachtgever getoond en het bleek inderdaad dat dit overeen kwam met zijn visie van DeliverXL.
Vervolgens is er vanuit de opdrachtomschrijving een lijst met eisen opgesteld (zie paragraaf 2.3),
waarbij er al meer moest worden nagedacht hoe bepaalde functionaliteit van DeliverXL zou gaan
werken. Omdat deze eisen uiteindelijk erg concreet waren, was het vrij eenvoudig om op basis
hiervan de milestones op te stellen. Uiteindelijk is er met deze milestones en de deliverables een
planning gemaakt voor het hele project. De planning voor de implementatiefase was uiteraard onder
voorbehoud, aangezien er voor een Scrum-achtige aanpak is gekozen.
In de tweede week, de onderzoeksfase, is er onderzoek gedaan naar het domein, het te ontwikkelen
systeem en het ontwikkelproces. De resultaten van dit onderzoek zijn verwerkt in het
onderzoeksrapport (zie Bijlage C). De domeinanalyse was bedoeld om een goed beeld te krijgen van
de context van het probleem en welke huidige oplossingen er al ontwikkeld zijn. Het onderzoek naar
het systeem was erg nuttig omdat er in deze fase goed nagedacht kon worden welke
programmeertalen, database systemen, programmastructuur, API’s, testmethoden e.d. gebruikt
konden gaan worden. Naast het feit dat er zo goed onderbouwde beslissingen gemaakt konden
worden, was er ook voldoende tijd om de benodigde software te installeren, tutorials te volgen en
een Git repository in te richten. Hierdoor was al het voorbereidende werk voor de implementatiefase
al gedaan.
In week 3 t/m 9, de implementatiefase, is er hard gewerkt aan de milestones. Omdat het project met
vier personen gedaan wordt, was er voldoende ruimte om de taken te verdelen. Voor een sprint
waren vaak meerdere milestones ingepland, waardoor er tegelijk aan verschillende functionaliteit
gewerkt kon worden. Hierbij kon optimaal gebruik gemaakt worden van branches (Git); iedere
milestone werd ontwikkeld op een aparte branch.
Tijdens de implementatiefase zijn er regelmatig afspraken geweest met de opdrachtgever en TU
coach (gemiddeld één keer per week). Sommige afspraken werden gecombineerd, waarbij zowel de
TU coach als de opdrachtgever aanwezig waren. Dit had als voordeel dat de feedback van beide
personen gecombineerd kon worden. De afspraken waren erg nuttig, omdat niet alleen de voortgang
werd gedemonstreerd, maar er ook concrete verbeter- en uitbreidingspunten naar boven kwamen.
Deze konden zo mogelijk direct worden meegenomen in het ontwikkelproces.
Daarnaast is er tijdens de implementatiefase ook tweemaal een bezoek gebracht aan klanten die het
1
Zie paragraaf 5.5 voor een toelichting waarom deze functionaliteit niet geïmplementeerd is.
13
product DeliverXL mogelijk willen gaan gebruiken (het Scheepvaartmuseum in Amsterdam en
Dijksterhuis Accountants- en Advieskantoor in Breda). Hier konden er al kleine demonstraties
gegeven worden van DeliverXL, maar er zijn vooral nuttige gesprekken gevoerd. Zo werd er bij deze
bedrijven besproken welke problemen zij nu daadwerkelijk in de praktijk ondervinden bij het invullen
van Excel sheets en er zijn ook suggesties gegeven voor extra functionaliteit voor DeliverXL. Zie
paragraf 3.4 voor de uitkomsten van deze meetings.
In week 9 t/m 11 (afrondingsfase) lag de focus vooral op het schrijven van het eindrapport, het
afronden van de code en het voorbereiden van een eindpresentatie.
3.4. Praktijkonderzoek
Om een beter beeld te krijgen van het gebruik van spreadsheets in de praktijk zijn twee bedrijven
bezocht en is besproken hoe DeliverXL voor hun van toegevoegde waarde zou kunnen zijn. Uit deze
gesprekken zijn verschillende uitbreidingsmogelijkheden gekomen, die in deze paragraaf staan
uitgewerkt.
Scheepvaartmuseum in Amsterdam
Op 20 mei 2014 is er samen met de opdrachtgever een meeting geweest met Patrick Buenk,
werkzaam bij het Scheepsvaartmuseum in Amsterdam. De volgende uitbreidingsmogelijkheden
kwamen in dit gesprek naar voren (in de vorm van user stories):











Als manager wil ik bij het invoeren van voorwaarden onderscheid kunnen maken tussen een
waarschuwing en een fout.
Als werknemer wil ik feedback ontvangen over mijn geüploade bestand waarbij onderscheid
wordt gemaakt tussen waarschuwingen en fouten. Bestanden met alleen waarschuwingen
kunnen wel ingeleverd worden.
Als manager wil ik structuurvoorwaarden opgeven, opgegeven wordt wat de structuur van
een formule moet zijn (bijvoorbeeld de vermenigvuldiging van twee waarden: =X*Y).
Als manager wil ik in een overzicht hebben welke werknemers voor een voorwaardenset al
een bestand hebben ingeleverd (geïmplementeerd in milestone 7).
Als manager wil ik de voorwaarde op kunnen leggen dat een bestand geen verborgen
tabbladen heeft.
Als manager wil ik de voorwaarde op kunnen leggen dat numerieke invoer van een bepaalde
valuta is.
Als manager wil ik de voorwaarde kunnen opleggen dat een cel bepaalde voorwaardelijke
opmaak heeft.
Als manager wil ik de voorwaarde op kunnen leggen dat een cel niet begint of eindigt met
een spatie.
Als manager wil ik de voorwaarde kunnen opleggen dat een cel een bepaalde opmaak heeft.
Als manager wil ik notities kunnen maken bij een voorwaarde.
Als manager en als werknemer wil ik kunnen zien wat er veranderd is aan een spreadsheet
ten opzichte van de template.
14
Dijksterhuis Accountants- en Advieskantoor in Breda
Op 22 mei 2014 is er samen met de opdrachtgever een meeting geweest met Peter Roovers,
werkzaam bij Dijksterhuis Accountants- en Advieskantoor in Breda. Hier kwamen de volgende
uitbreidingsmogelijkheden naar voren:




Als manager wil ik relatieve voorwaarden op kunnen stellen tussen cellen. Bijvoorbeeld de
ene waarde van B2 moet kleiner zijn dan de waarde van B1.
Als manager wil ik de voorwaarde op kunnen stellen of er consequent een punt of komma
gebruikt wordt bij de invoer van getallen.
Als manager wil ik een voorwaarde kunnen opleggen die het aantal te accepteren waardes
beperkt. Bijvoorbeeld: B3 bevat alleen ‘man’ of ‘vrouw’.
Als manager wil ik voorwaardelijke voorwaarden op kunnen stellen. Dit betekent dat slechts
aan een bepaalde voorwaarde hoeft te worden voldaan als een andere voorwaarde geldig is.
Bijvoorbeeld: als B4 niet leeg is, moet B5 een getal bevatten.
3.5. Reflectie
Terugkijkend op het proces en het verloop van het project, is het beeld zeker positief. Als
projectteam hebben we het bacheloreindproject als goed geslaagd en leerzaam ervaren en zijn we
tevreden met het ontwikkelde product DeliverXL.
De opgestelde planning bleek een goed handvat en een goede inschatting van het werk. Gedurende
het project is vaak teruggepakt op de vooraf opgestelde milestones; het bleek erg nuttig te zijn om
vooraf een duidelijke specificatie te hebben van de te ontwikkelen functionaliteit. Er is af en toe van
de milestones afgeweken, voornamelijk door meer functionaliteit toe te voegen dan vooraf
benoemd. Verder is het als positief ervaren om aan het einde van elke milestone een werkend
product te hebben. Hierdoor kon op elk moment een demo gegeven worden van een recente versie
van DeliverXL.
Pas aan het einde, bij milestone 10 en 11, is het niet volledig gelukt om de oorspronkelijke planning
aan te houden. Dit kwam vooral omdat er bij milestone 10 na redelijk wat implementatiewerk
overgestapt is naar een ander framework voor de Excel weergave en er aan het eind van het project
ook nog eens veel tijd besteed moest worden aan het eindverslag. Verder liep de implementatiefase
erg goed en is er volgens schema gewerkt.
Achteraf gezien hadden sommige punten misschien wel beter gekund. Bij de eerste vier milestones is
er veel tijd geïnvesteerd in het schrijven van tests, die later weer moesten worden aangepast toen de
functionaliteit van de eerste milestones vervangen werd in opvolgende milestones. Het bleek dat er
teveel implementatiecode werd getest, in plaats van daadwerkelijke functionaliteit. Vanaf dat
moment is er bewust voor gekozen om ons te richten op functionele tests, die in principe niet sterk
gerelateerd zijn aan implementatiecode. Zo zijn er bijvoorbeeld voor milestone 5 rond de 200 tests
gemaakt die de voorwaarde checking controleren, wat een duidelijk voorbeeld is van belangrijke
functionaliteit van DeliverXL.
Achteraf gezien, zou het filteren en sorteren van lijsten in milestone 8 pas later geïmplementeerd
hoeven zijn. Deze milestone voegt namelijk geen must-have functionaliteit toe, en heeft toch
behoorlijk wat ontwikkeltijd in beslag genomen. Deze tijd had beter aan milestone 10 of 11 besteed
kunnen zijn.
15
Als laatste mag nog genoemd worden dat de onderlinge samenwerking tijdens het proces erg goed
verlopen is. Tijdens de implementatiefase is er regelmatig een informele vergadering geweest waarin
taken verdeeld werden. Omdat er elke dag gezamenlijk in dezelfde ruimte werd gewerkt waren
snelle communicatie en directe beslissingen mogelijk. Dit heeft ertoe geleid dat er echt als team aan
DeliverXL gewerkt kon worden.
16
4. ONTWERP
Voor DeliverXL zijn er voorafgaand aan de programmeerfase een groot aantal features omschreven.
Deze features zijn opgedeeld volgens de MoSCoW methode. De features werden doormiddel van een
combinatie van het incremental build model en scrum geïmplementeerd. Deze methode legde wel
een beperking op de ontwerpfase, want veel van de onderdelen die in de ontwerpfase konden
worden uitgevoerd, zijn tijdens de implementatiefase gedaan vanwege de werkmethode.
Toch is hier voor gekozen om flexibiliteit van functionaliteit tijdens de programmeerfase te kunnen
garanderen. In de ontwerpfase zijn er een aantal belangrijke beslissingen genomen voor de bouw van
DeliverXL, zoals het soort applicatie dat DeliverXL zou worden en de programmeertaal. Hierbij is
vooral rekening gehouden met de service die DeliverXL moest gaan bieden en welke keuzes daar het
best bij pasten.
In dit hoofdstuk zullen deze keuzes worden beschreven die tijdens de onderzoeksfase zijn gemaakt.
Er zal niet verder worden ingegaan op de niet gekozen alternatieven. Een uitgebreide uitleg, waarbij
ook de alternatieven worden besproken staat in het onderzoeksrapport (zie Bijlage C).
4.1. Soort applicatie
Er is al vroeg in het ontwerp een keuze gemaakt wat voor soort applicatie DeliverXL moest gaan
worden, omdat deze keuze samenhing met verschillende vervolg ontwerpkeuzes. Er is voor gekozen
om DeliverXL als webapplicatie te ontwikkelen. Dit heeft verschillende voordelen ten opzichte van de
alternatieven. De voordelen van een webapplicatie ten opzichte van de alternatieven zijn dat een
webapplicatie:



via de browser ondersteuning biedt aan alle platformen.
makkelijk bereikbaar is voor meerdere gebruikers (administratoren, managers en
werknemers).
bij de ontwikkeling veel ondersteuning kan hebben van een breed scala aan geschikte
programmeertalen, frameworks en libraries.
Vanuit het besluit om DeliverXL als webapplicatie te ontwikkelen kon er verder worden onderzocht
welke ontwerpstappen het beste voor DeliverXL waren. Omdat de functionaliteit van DeliverXL voor
een groot gedeelte afhangt van het uitlezen van Excel sheets was een logische keuze om als tweede
onderzoek te doen naar alle mogelijkheden die hiervoor zijn.
4.2. Het uitlezen van een Excel bestand
Ondanks de keuze voor de soort applicatie zijn er meerdere API’s en manieren om Excel sheets uit te
lezen, in verschillende programmeertalen. Veelgebruikte manieren om Excel sheets uit te lezen zijn
onderzocht. Uiteindelijk is er gekozen voor de API Gembox die alle benodigde functionaliteit bevat
die nodig is voor het uitlezen van spreadsheets. Gembox is een professionele oplossing, en het
bedrijf (Infotron) bezit al een licentie voor Gembox, omdat het voor andere applicaties wordt
gebruikt.
Wat de keuze voor Gembox doorslaggevend maakte:


Gembox is onafhankelijk van Microsoft Excel.
Gembox is efficiënter en sneller dan andere methoden die op de achtergrond gebruik maken
van Microsoft Excel.
17


Gembox heeft een uitgebreide documentatie en veel voorbeelden.
Naast Excel bestanden worden ook andere formaten ondersteund, zoals ODS, CSV, HTML,
PDF en XPS.
Omdat Gembox ook andere formaten ondersteunt blijft eventuele uitbreiding naar deze
bestandsformaten voor DeliverXL mogelijk. Daarnaast blijkt Gembox minimaal alle functionaliteit te
hebben die de alternatieve API’s ook hebben.
4.3. Programmeertaal
Zoals besloten is in de eerste paragraaf zal DeliverXL als webapplicatie ontwikkeld worden. Vanwege
deze keuze blijven er een select aantal opties voor te gebruiken programmeertalen over. Om een
definitieve keuze te maken is er meegenomen welke Excel API’s er voor de taal beschikbaar waren en
of distributie van de taal en de API mogelijk was.
De knoop was moeilijk door te hakken welke programmeertaal gebruikt moest worden, omdat het
verschil in benodigde mogelijkheden niet extreem groot is. Daarom is ook de opdrachtgever,
Infotron, extra geraadpleegd. De voorkeur van een Excel API lag bij het gebruik van Gembox volgens
Infotron zoals in voorgaande paragraaf uitgelegd, wat het gebruik van C# of VB.NET als
programmeertaal zou impliceren.
Vanwege de voorkeur voor Gembox, viel ook de voorkeur voor de ASP.NET omgeving. Ook heeft de
opdrachtgever al diverse andere programma’s, zoals PerfectXL, die gebruik maken van de .NET
programmeeromgeving en geprogrammeerd zijn in Visual C#. Vanwege deze reden en de ervaring in
C# ten opzichte van het beste alternatief (PHP in combinatie met PHPExcel) is gekozen voor C# met
Visual Studio 2013.
4.4. Dataopslag
Voor DeliverXL zijn verschillende vormen van data te noemen, die opgeslagen dienen te worden. Van
te voren te onderscheiden waren in ieder geval:




Template Excel bestanden die samengesteld zijn door de manager.
Excelbestanden die ingevuld zijn door de werknemer en goedgekeurd door het systeem.
Voorwaardensets die van toepassing zijn op een template Excel bestand.
Gegevens van de gebruikers die nodig zijn.
De template Excel bestanden en de ingevulde Excel bestanden moeten in ieder geval als bestanden
opgeslagen worden op een server, omdat het een webbased systeem is.
Voor de overige data (waaronder de verwijzingen naar de opgeslagen bestanden) is gekozen om
gebruik te maken van een database als dataopslag. Hiervoor zijn een aantal redenen. Allereerst is de
data die het systeem zal opslaan geschikt om in een database opgeslagen te worden. Hier gelden de
algemene voordelen van een database ten opzichte van een filesysteem. Een database is sneller,
geavanceerder en geschikter om te indexeren. Met een database kan door relaties en voorwaarden
op te geven ook op een makkelijke manier beveiliging ingebouwd worden die de validiteit van de
data verzekerd.
In navolging van de keuze voor Visual C# en Visual Studio is ook gekozen voor Microsoft SQL Server
Express 2014. Er is gekeken naar alternatieven, maar voor deze is uiteindelijk niet gekozen. Ten
18
eerste biedt Visual Studio uitgebreide ondersteuning voor integratie van Microsoft SQL Server
Express. De alternatieven missen deze uitgebreide integratie en ondersteuning. Verder speelde mee
dat Infotron voor het systeem PerfectXL al Microsoft SQL Server Express gebruikt. Het systeem maakt
gebruik van een lokaal databasebestand.
Tijdens de ontwikkelfase is gekozen om niet een lokaal databasebestand te gebruiken, dat wil zeggen
een database die op het zelfde systeem uitgevoerd wordt als de webapplicatie. In plaats daarvan is
gekozen om de database op een server uit te voeren. Dit heeft als voordeel dat er door het
ontwikkelteam elk met dezelfde database gewerkt kan worden. Deze database zal later zonder veel
moeite op dezelfde server uitgevoerd kunnen worden als de webapplicatie.
Ook is er gekozen om met het Entity Framework2 te werken. Dit framework maakt het mogelijk dat je
met relationele databases kan werken door objecten in het domein zelf te gebruiken. Bij het gebruik
van Entity Framework is er keuze tussen Code First te gebruiken of Database First. Er is gekozen om
Code First te gebruiken. De belangrijkste reden hiervoor is dat de alternatieven geen makkelijke
mogelijkheid bieden om veranderingen op de database toe te passen met behoud van data.
Bij Code First hoeft er (vrijwel) geen rekening met de database gehouden te worden, doordat het
opgestelde model in de code automatisch gemapped (overgezet) wordt naar het databasemodel.
4.5. Programmastructuur
Als programmastructuur voor DeliverXL is er voor Model View Controller (zie Figuur 2) gekozen. In
een programma die het model van de Model View Controller (MVC) gebruikt, is de view de Graphical
User Interface (GUI), waar in het geval van DeliverXL de HTML, CSS en Javascript zit. De controller
verwerkt handelingen die meestal het gevolg zijn van de gebruiker. Het model representeert de
informatie waarmee het programma werkt.
MVC heeft als nadeel dat het wat omslachtig kan zijn om iets aan te passen, want dat moet vaak
gebeuren in de view, model en controller. Het heeft veel voordelen ten opzichte van het alternatief:
Het model heeft een duidelijk gedefinieerde project architectuur, dit zorgt ervoor dat het minder
snel complex wordt om te begrijpen hoe alles in elkaar zit. MVC leent zich uitstekend voor testen,
want het model, de view en de controller kunnen alle drie apart van elkaar getest worden. Met MVC
kan ook gemakkelijk met een team samengewerkt worden binnen één project: de view, model en
controller kunnen alle drie los van elkaar bewerkt worden. Nog een voordeel is dat de MVC structuur
buitengewoon goed ondersteund wordt door Visual Studio, met onder andere het aanmaken van
nieuwe Views, models en Controllers.
Figuur 2 - Model View Controller
2
http://msdn.microsoft.com/en-us/data/ef.aspx
19
4.6. API voor het weergeven van een Excel interface
Omdat het doel is een gebruiksvriendelijke interface te bieden voor het opzetten van voorwaarden
voor een Excel sheet, is er gezocht naar een library die ondersteuning biedt voor het weergeven van
een Excel sheet in een webinterface. Door de Excel sheet zelf weer te geven, is het voor de gebruiker
(in dit geval de manager) mogelijk om met een visuele omgeving te werken in plaats van alleen maar
met tekst en web formulieren. Een idee is bijvoorbeeld dat de gebruiker een cel kan selecteren om
vervolgens via een menu of button aan die cel (of aan een groep cellen) een voorwaarde toe te
voegen.
Er bleek een groot aantal mogelijkheden te bestaan om dit aan te pakken. Tijdens de onderzoeksfase
is er gekozen voor de optie jQuery.Sheet. Tijdens de implementatiefase is van die keuze afgeweken.
Er is uiteindelijk gekozen voor Handsontable3. Handsontable is een relatief simpele API, het neemt als
invoer een door komma’s gescheiden tabel en maakt daar een weergave van die lijkt op de Excel
weergave. Deze API biedt vrijwel alles wat nodig is voor DeliverXL. Er is de mogelijkheid om een sheet
weer te geven, cellen kunnen hierin geselecteerd worden, er kunnen opmaak opties opgegeven
worden, enzovoort. Functionaliteit die mist is onder andere het weergeven van meerdere tabbladen,
het evalueren van formules en het weergeven van samengevoegde cellen. Omdat de API relatief
simpel is, zou deze hoogstwaarschijnlijk makkelijk uit te breiden of aan te passen zijn.
De optie waar tijdens de onderzoeksfase voor werd gekozen was jQuery.Sheet4. jQuery.Sheet biedt
een hele reeks aan mogelijkheden om tabellen weer te geven en te bewerken. Een groot voordeel
van jQuery.Sheet is de mogelijkheid om de tabeldata als JSON of XML data te importeren. Verder is
het in staat om een groot aantal formules correct weer te geven en kunnen er meerdere tabbladen
worden weergeven. Het enige minpunt is de mate waarin het mogelijk is de interface in te stellen. Er
zijn slechts twee opties: of de interface is alleen lezen (met geen opties), of de interface is compleet
(met alle opties om aan te passen). Om de interface dus zo te maken dat aan de eisen voor DeliverXL
wordt voldaan zullen er delen van de API aangepast of uitgebreid moeten worden. Dit bleek echter
arbeidsintensiever dan tijdens de onderzoeksfase was verondersteld.
Ondanks de uitgebreidere functionaliteit van jQuery.Sheet is er gekozen voor Handsontable. Bij
gebruik van Handsontable waren namelijk veel minder aanpassing aan de interface vereist.
Daarnaast was de missende functionaliteit van Handsontable makkelijker toe te voegen. Ook was
Excelweergave veel makkelijker passend te maken in DeliverXL, omdat de interface met
Handsontable makkelijk aan te passen viel met Bootstrap. Bootstrap is namelijk ook gebruikt voor de
interface van DeliverXL. Meer over Bootstrap in paragraaf 5.2.3.
3
4
http://handsontable.com/
http://visop-dev.com/Project+jQuery.sheet
20
5. IMPLEMENTATIE
In dit hoofdstuk wordt uitgelegd hoe de applicatie is geïmplementeerd. Naar aanleiding van de
opdeling van het programma in model, view en controller, is ook dit hoofdstuk opgedeeld in deze
drie delen. Ook de code die opgedeeld is onder de naam Utils wordt besproken. Verder wordt er nog
toegelicht hoe de webapplicatie gepubliceerd kan worden op een webserver. Als laatste zal in dit
hoofdstuk nog aan de orde komen hoe de code getest is en op welke manier de code kwaliteit
gewaarborgd is.
5.1. Model
Het model in de Model View Controller aanpak representeert de data van het programma. In het
model worden de klassen gedefinieerd waarin staat aangegeven welke velden een bepaalde entiteit
heeft en welke logica daarachter zit. Bijvoorbeeld: een account bevat een gebruikersnaam,
emailadres en wachtwoord. Deze model klassen worden gebruikt in de view om informatie weer te
geven, en in de controller om acties uit te voeren. De informatie in het model staat opgeslagen in
een database.
In dit hoofdstuk wordt de implementatie van het model uitgelegd. Allereerst wordt een overzicht
gegeven van alle klassen in DeliverXL waarbij uitgelegd wordt hoe dit geïmplementeerd is, waarna
wordt uitgelegd hoe het Entity Framework wordt gebruikt om de informatie op te slaan in de
database.
5.1.1. Data klassen
In Figuur 3 staat een klassendiagram met daarin de vier belangrijkste klassen van DeliverXL. Per
klasse wordt uitgelegd waar dit model voor dient en welke keuzes hierbij gemaakt zijn, toegelicht
met enkele voorbeelden uit de implementatie. Hierbij komen ook de subklassen aan bod. Als laatste
wordt besproken wat een view model is en hoe hier bij DeliverXL gebruik van wordt gemaakt.
21
Figuur 3 - Klassendiagram van vier belangrijke klassen van DeliverXL
Account
De klasse Account representeert een gebruiker in het systeem. Deze klasse bevat onder andere de
volgende velden: Name, Email en Password. De naam wordt gebruikt om op een normale manier
naar de persoon te verwijzen, zoals om te laten zien wie een bestand geüpload heeft. Het emailadres
en wachtwoord worden gebruikt om mee in te loggen, waarbij het emailadres ook gebruikt wordt
om emailberichten naar die gebruiker te sturen. Dit wordt bijvoorbeeld gedaan bij het sturen van een
notificatie naar de manager om te laten weten dat een werknemer een bestand succesvol
opgestuurd heeft.
Verder heeft de klasse Account nog drie velden, namelijk IsAdministrator, IsManager en
IsSubmitter. Deze velden worden gebruikt om bepaalde rechten te geven aan een gebruiker, met
behulp van een boolean (true/false). Alle genoemde rollen sluiten elkaar niet uit, het is mogelijk
dat een gebruiker meerdere rollen tegelijkertijd heeft. Hieronder een uitleg van de drie rollen:


Als een gebruiker de rol van administrator heeft dan deze gebruiker andere gebruikers
beheren. Dit houdt in dat er nieuwe gebruikers kunnen worden aangemaakt, bewerkt en
verwijderd. Ook kunnen door de administrator de rechten van administrator, manager en
submitter per account toegewezen worden.
Als een gebruiker de rol van manager heeft kan deze gebruiker voorwaardensets aanmaken
(uploaden van een template), wijzigen en verwijderen. Een manager kan per voorwaardenset
de managers toewijzen (om de voorwaardenset te beheren) en submitters toewijzen (om
bestanden te kunnen opsturen voor deze voorwaardenset). Daarnaast heeft de manager een
overzicht van alle opgestuurde bestanden.
22

Als een gebruiker de rol van submitter heeft kan deze gebruiker templates downloaden die
de manager voor deze gebruiker beschikbaar heeft gesteld. Vervolgens kan een submitter de
ingevulde spreadsheet uploaden, waarna de validatie plaatsvindt. Als een bestand aan alle
voorwaarden voldoet, kan het opgestuurd worden naar de manager.
Aan de hand van attributen kunnen er voorwaarden gelegd worden op de velden. Attributen worden
in vierkanten haken boven de definitie van een veld geplaatst. Hieronder een voorbeeld van de
klasse Account:
public class Account
{
[Required]
[MaxLength(50)]
public string Name { get; set; }
[Required]
[DataType(DataType.EmailAddress)]
[EmailAddress]
[MaxLength(50)]
public string Email { set; get; }
(...)
}
Het attribuut Required betekent dat dit veld verplicht moet worden ingevuld. Het MaxLength
attribuut geeft aan dat dit veld een maximum lengte heeft, waardoor in de database die ruimte
beschikbaar kan worden gesteld. Bij het veld Email worden ook nog attributen gebuikt om aan te
geven dat het gaat om een emailadres. Hierdoor wordt dat er gecontroleerd dat de string voldoet
aan enkele eisen, bijvoorbeeld dat er een @-teken in de string aanwezig is en er een punt op de
juiste plaats staat.
De methode IsInRole maakt het mogelijk om te controleren of een gebruiker een bepaalde rol
heeft. Dit wordt op veel plekken in het programma gebruikt, om toegang tot bepaalde acties in een
controller te limiteren voor een specifieke rol. Deze controle wordt gedaan met het Authorize
attribuut, wat verder in paragraaf 5.3.1 wordt uitgelegd.
ConstraintSet
De klasse ConstraintSet representeert een voorwaardenset in het systeem. Een voorwaardenset
heeft een Name, waardoor er in het programma makkelijk naar verwezen kan worden. De velden
CreatedBy en DateAdded worden gebruikt om op te slaan welke manager op welke tijdstip deze
voorwaardenset heeft aangemaakt. Bij het aanmaken van een voorwaardenset moet de manager
een template bestand uploaden, waarvan het pad naar dit geüploade bestand (op de server) wordt
opgeslagen in het veld TemplateFilePath.
De gebruikers die deze voorwaardenset mogen beheren worden opgeslagen in het veld Managers,
wat een lijst is van Account objecten. De gebruikers die bestanden mogen opsturen voor deze
voorwaardenset staan opgeslagen in het veld Submitters. Alle bestanden die uiteindelijk worden
geüpload door de submitters, staan opgeslagen in de lijst van UploadedFiles. Tenslotte bevat een
ConstraintSet nog het veld Constraints, waarin de voorwaarden staan opgeslagen waar een
geüpload bestand aan moet voldoen.
23
UploadedFile
De klasse UploadedFile representeert een geüpload bestand in het systeem. Een geüpload bestand
is gekoppeld aan een gekozen voorwaardenset; deze verwijzing staat opgeslagen in het veld
ConstraintSet. Een geüpload Excel bestand wordt opgeslagen op de server, waarvan het pad naar
dit bestand wordt opgeslagen in het veld FilePath. In de velden UploadedBy en UploadedAt wordt
opgeslagen door welk account en op welk tijdstip dit bestand is geüpload.
Bij het uploaden van het bestand wordt direct gevalideerd of het bestand aan alle voorwaarden van
de gekozen voorwaardenset voldoet. Het resultaat van deze validatie (true/false) wordt
opgeslagen in het veld ValidationResult. Hier is voor gekozen omdat de validatie van het Excel
bestand dan niet telkens opnieuw hoeft worden uitgevoerd, bijvoorbeeld bij het tonen van een lijst
van alle geüploade bestanden. Alleen bij het wijzigen van de voorwaarden zou de validatie eigenlijk
opnieuw moeten worden uitgevoerd, al wordt daar in de huidige versie nog geen rekening mee
gehouden (zie aanbevelingen in hoofdstuk 7).
Als laatste bevat deze klasse nog twee velden Submitted en SubmittedAt. Als een geüpload bestand
voldoet aan alle eisen gesteld in de voorwaardenset, dan heeft de submitter de keuze om het
bestand naar de manager op te sturen. Op dat moment wordt het boolean-veld Submitted op true
gezet en voor SubmittedAt de huidige datum en tijd ingevuld. Pas wanneer een bestand opgestuurd
is, wordt het zichtbaar voor de toegewezen managers. Het SubmittedAt veld heeft een ? achter zijn
type, wat betekend dat het ook geen waarde kan bevatten (nullable). Dit is het geval als een bestand
nog niet opgestuurd is.
Bij deze klasse is ook gebruikt gemaakt van attributen. Hieronder een voorbeeld van de klasse
UploadedFile:
public class UploadedFile
{
[Display(Name = "Uploaded at")]
public DateTime UploadedAt { get; set; }
[Display(Name = "Submitted at")]
public DateTime? SubmittedAt { get; set; }
}
Er wordt hier gebruik gemaakt van het Display attribuut, wat ervoor zorgt dat in de view een
gebruikersvriendelijke naam kan worden weergeven (in plaats van de directe naam van het veld).
Constraint
De klasse Constraint representeert alle voorwaarden in het systeem. Omdat er een verschillende
soorten voorwaarden door DeliverXL ondersteund worden, is er voor ieder soort voorwaarde een
aparte klasse gemaakt. Vervolgens is er een uitgebreide klassenhiërarchie van alle voorwaarden
gemaakt, waarvan een overzicht zichtbaar is in Figuur 4.
24
Figuur 4 - Klassendiagram Constraint (inclusief subklassen)
Constraint is een abstracte klasse, hiervan kunnen dus geen objecten worden aangemaakt. Hier is
voor gekozen omdat deze klasse geen concrete voorwaarde voorstelt. Hetzelfde geldt voor de
klassen CellConstraint en FileConstraint, beide zijn eveneens abstract en erven over van
Constraint.
Het veld Inverted in Constraint maakt het mogelijk om een voorwaarde eenvoudig te inverteren
(bijvoorbeeld 'A2 is niet leeg’). De DisplayName en de InvertedDisplayName velden worden
25
gebruikt in de view om een gebruiksvriendelijke omschrijving van de voorwaarde weer te geven.
Afhankelijk van het veld Inverted wordt DisplayName of InvertedDisplayName gebruikt.
De methode FeedbackString wordt gebruikt om aan de submitter kenbaar te maken waarom aan
een voorwaarde niet voldaan is. Deze methode is abstract, dat wil zeggen dat alle subklassen deze
methode moeten implementeren. Dit is logisch, aangezien elke voorwaarde zijn eigen feedback moet
geven waarom die voorwaarde niet geldt.
De methode Check wordt aangeroepen wanneer een voorwaarde wordt gecontroleerd, ongeacht
welke subklasse het is. Deze methode roept de methode CheckConstraint aan retourneert het
resultaat; als de voorwaarde geïnverteerd is wordt het resultaat op geïnverteerd. Het voordeel
hiervan is dat niet iedere voorwaarde rekening hoeft te houden met het veld Inverted, maar dit
door de hoogte klasse Constraint wordt gedaan. CheckConstraint is een abstracte methode, en
moet dus ook door elke voorwaarde geïmplementeerd worden.
De daadwerkelijke voorwaarden worden geïmplementeerd in de subklassen van CellConstraint en
FileConstraint. Elke klasse implementeert zijn eigen CheckConstraint en FeedbackString
methoden, en heeft verder een eigen DisplayName en InvertedDisplayName. Er volgt nu een
overzicht van alle concrete voorwaarden, waarbij kort wordt uitgelegd wat elke voorwaarde
representeert:









CompareConstraint: vergelijkt de waarde van een cel met een opgegeven waarde, zoals een
getal of een datum. De vergelijkingen die gemaakt kunnen worden zijn: gelijk aan, groter
dan, kleiner dan, groter of gelijk aan en kleiner of gelijk aan.
Voorbeeld: “A1 bevat een waarde groter dan 100.”
DataTypeConstraint: controleert het datatype van een cel. Datatypes die ondersteund
worden door DeliverXL zijn: tekst, getallen, valuta, datums en booleans. Deze voorwaarde
impliceert dat een cel niet leeg mag zijn.
Voorbeeld: “A2 bevat een waarde van het datatype datum.”
EmptyConstraint: controleert of een cel leeg is.
Voorbeeld: “A3 is niet leeg.”
ErrorConstraint: controleert of een cel een Excel fout bevat, zoals #DEEL/0! of #N/B.
Voorbeeld: “A4 bevat geen fout.”
FormulaConstraint: controleert of een cel een formule bevat.
Voorbeeld: “A5 bevat een formule.”
TextLengthConstraint: vergelijkt de tekst lengte van een cel met een getal. De vergelijkingen
die gemaakt kunnen worden zijn: gelijk aan, groter dan of kleiner dan. Deze voorwaarde
werkt niet enkel op cellen met tekst, maar bijvoorbeeld ook op getallen.
Voorbeeld: “A6 heeft een tekst lengte van minimaal 3 karakters.”
ErrorFileConstraint: controleert of een Excel bestand een fout bevat, zoals #DEEL/0! of #N/B.
Voorbeeld: “Administratie.xlsx bevat geen fout.”
NumberOfSheetsConstraint: vergelijkt het aantal werkbladen in een Excel bestand met een
opgegeven getal. De vergelijkingen die gemaakt kunnen worden zijn: gelijk aan, groter dan,
kleiner dan, groter of gelijk aan en kleiner of gelijk aan.
Voorbeeld: “Administratie.xlsx bevat minimaal 3 tabbladen.”
TemplateFileNotChangedConstraint: controleert of de oorspronkelijke Excel template niet is
aangepast, d.w.z. niet-lege cellen uit de Excel template zijn hetzelfde als in het geüploade
26
Excel bestand.
Voorbeeld: “De template van Administratie.xlsx is niet aangepast.”
Position
Voor voorwaarden van het type CellConstraint geldt dat die
voorwaarde altijd van toepassing is op een cel (of reeks cellen).
Hiervoor heeft CellConstraint een veld genaamd Position,
waarvan in Figuur 5 een klassendiagram staat. De klasse
FileConstraint bevat niet het Position veld, omdat deze type
voorwaarden voor de gehele spreadsheet gelden.
Position bevat een veld WorkSheet, waarin staat opgeslagen voor
welk werkblad deze voorwaarde geldt. Op dit moment bevat
DeliverXL nog geen typen voorwaarden die alleen voor een werkblad
gelden (daarom is Position ook abstract), maar het laat wel
mogelijkheden voor uitbreiding in de toekomst open.
CellPosition is een subklasse van Position en bevat ook een veld
Cell. Hierdoor bestaat CellPosition dus zowel uit een werkblad als
een cel, een combinatie die voor veel voorwaarden wordt gebruikt.
Bij deze klassen wordt ook gebruikt gemaakt van attributen, zie
hieronder de implementatie van Position en CellPosition:
Figuur 5 - Klassendiagram Position
public abstract class Position
{
[Required]
[MaxLength(31)]
public string WorkSheet { get; set; }
}
public class CellPosition : Position
{
[Required]
[MaxLength(16)]
[RegularExpression(@"^[a-zA-Z-]+[0-9-]+$",
ErrorMessage = "A cell must start with letters and end with numbers.")]
public string Cell { get; set; }
}
Het is duidelijk dat WorkSheet en Cell verplicht zijn en een maximale lengte hebben. Verder moet
het veld Cell aan een speciale voorwaarde voldoen, namelijk een reguliere expressie. Met behulp
27
van deze reguliere expressie wordt gecontroleerd of een cel begint met één of meer letters, gevolgd
door één of meer cijfers. Als dit niet het geval is wordt er in de view een foutmelding weergegeven,
zoals opgegeven in het RegularExpression attribuut.
Als laatste in de hiërarchie van Position is de klasse CellRangePosition. Deze klasse heeft een
extra veld EndCell, wat samen met het veld Cell uit CellPosition een reeks definieert. De positie
in CellConstraint is van het type CellPosition, wat dus zowel een enkele cel of een reeks cellen
kan zijn.
View models
Een view model is aangepaste versie van een normaal model zoals hierboven besproken, wat
bedoeld is voor het gebruik in de view. Een view model laat extra velden of attributen toe die niet in
een normale model klasse horen. Daarnaast maakt view model het ook mogelijk om juist velden weg
te laten, mochten deze niet van toepassing zijn in een bepaalde view.
Een voorbeeld waarbij een view model als uitbreiding dient is het AccountViewModel. Dit view
model bevat een extra veld om het wachtwoord te bevestigen wanneer er een nieuw account
geregistreerd wordt:
public class AccountViewModel
{
[Unique(EntityType = typeof(Account),
ErrorMessage = "An account with this email already exists.")]
public string Email { set; get; }
[Required]
[DataType(DataType.Password)]
[StringLength(50, MinimumLength = 6,
ErrorMessage = "The password must have at least 6 characters.")]
public string Password { get; set; }
[Required]
[DataType(DataType.Password)]
[Display(Name = "Confirm Password")]
[Compare("Password",
ErrorMessage = "The password and confirmation password do not match.")]
public string ConfirmPassword { get; set; }
}
Het veld ConfirmPassword is niet nodig in het normale Account model, dan zou het wachtwoord
immers dubbel worden opgeslagen. De controller werkt nu op basis van het AccountViewModel,
alleen daar hoeft te worden gecontroleerd of tweemaal hetzelfde wachtwoord is opgegeven. De
controller maakt vervolgens de mapping van een view model naar een normaal model. Voor de
veiligheid wordt hier ook nog geëist dat het wachtwoord minimaal zes tekens bevat met behulp van
het attribuut StringLength.
Verder staat hier een nieuw attribuut boven het veld Email, namelijk Unique. Dit attribuut eist dat er
geen Account mag worden aangemaakt met een emailadres wat reeds bestaat. Omdat er moet
worden ingelogd met het emailadres, moet deze uiteraard uniek zijn. Het Unique attribuut is niet
standaard aanwezig in C#, daarom is dit attribuut zelf geïmplementeerd.
28
Een voorbeeld van een view model is waarbij velden zijn weggelaten is het
UploadedFileViewModel:
public class UploadedFileViewModel
{
[Required(ErrorMessage = "Please upload a file")]
[Display(Name = "Excel file")]
[ValidateExcelFile]
public HttpPostedFileBase File { get; set; }
[Display(Name = "Constraint set")]
public int ConstraintSet { get; set; }
}
Bij het uploaden van een bestand hoeft enkel de File en de ConstraintSet te worden opgegeven.
De rest van de velden van UploadedFile worden in de controller gegenereerd, zoals UploadedAt en
ValidationResult.
Overigens wordt hier weer een nieuw attribuut geïntroduceerd, namelijk ValidateExcelFile. Met
dit attribuut wordt direct bij het uploaden al gecontroleerd of het bestand een geldig Excel bestand
is, en dus door de ExcelReader kan worden gelezen. Dit attribuut is ook zelf geïmplementeerd.
5.1.2. Database: Entity Framework
Hiervoor is uitgelegd hoe de model klassen zijn gedefinieerd in C#. Deze klassen worden gebruikt bij
de uitvoer van het programma, maar daarnaast is het nodig om de gegevens op te slaan in een
database. Het Entity Framework is verantwoordelijk voor de mapping van het model tussen de
klassen en de database.
Er is gekozen voor de Code First aanpak, waardoor de database structuur dus automatisch wordt
gegenereerd op basis van de gedefinieerde klassen. Er geldt niet dat automatisch alle model klassen
worden omgezet naar de database. De daadwerkelijke mapping wordt opgegeven in een DbContext,
die in dit geval DeliverXLContext heet. Hierin staat gespecificeerd van welke klassen er een DbSet
moet worden gemaakt:
public
public
public
public
public
DbSet<Account> Accounts { get; set; }
DbSet<ConstraintSet> ConstraintSets { get; set; }
DbSet<Constraint> Constraints { get; set; }
DbSet<Position> Positions { get; set; }
DbSet<UploadedFile> UploadedFiles { get; set; }
Deze aanpak maakt het mogelijk om ook klassen te definiëren die niet in de database komen, wat
bijvoorbeeld nuttig is in het geval van view models.
Uiteindelijk worden de opgegeven klassen door het Entity Framework gemodelleerd in een Entity
Data Model. Figuur 6 geeft een overzicht van het gegenereerde Entity Data Model van DeliverXL.
Meer toelichting over verschillende elementen uit het Entity Data Model volgen in de loop van dit
hoofdstuk.
29
Figuur 6 - Entity Data Model van DeliverXL
Genereren van de database
Het Entity Framework genereert op basis van het Entity Data Model de structuur van de database
met behulp van een DbInitializer. Er zijn verschillende varianten hiervan, tijdens het ontwikkelen
van DeliverXL is er in de beginfase voor gekozen om de database telkens opnieuw te genereren als
30
het model is aangepast. De DbInitializer bevat een Seed methode die telkens uit wordt
uitgevoerd wanneer er een nieuwe database wordt gegenereerd. Dit maakt het mogelijk om bij
iedere wijziging de database automatisch te vullen met dezelfde testdata (zoals testaccounts en een
voorwaardenset).
Uiteindelijk ziet de gegenereerde database structuur (SQL) door het Entity Framework er zo uit zoals
weergegeven in Figuur 7.
Figuur 7 - Structuur SQL database van DeliverXL
Hieronder wordt een verdere uitleg gegeven over enkele belangrijke elementen uit het Entity Data
Model en de gegenereerde SQL structuur.
Relaties
In Figuur 6 wordt duidelijk dat het Entity Data Model veel overeenkomsten heeft met het
klassendiagram van DeliverXL. Een verschil is dat in het Entity Data Model ook de relaties tussen de
verschillende entiteiten zijn gespecificeerd. Een Account kan bijvoorbeeld in meerdere
ConstraintSets voorkomen, maar iedere ConstraintSet bevat een verwijzing naar één account.
Dit is een zogenaamde 1:n relatie, en is in Figuur 6 zichtbaar met 1 - *. Er is ook een 1:n relatie tussen
ConstraintSet en UploadedFile.
Een ander type relatie die voorkomt is een 1:1 relatie, in dit geval tussen CellConstraint en
Position. Dit is een logische keuze, omdat hiermee van iedere CellConstraint precies één
31
Position wordt opgeslagen en andersom. Een 1:1 relatie moet in het Entity Framework expliciet
worden opgegeven, dit kan eenvoudig met de Fluent API:
// Specify one-to-one relation between CellConstraint and Position
modelBuilder.Entity<Position>()
.HasRequired(e => e.Constraint)
.WithRequiredDependent(s => s.Position)
.WillCascadeOnDelete(true);
Daarnaast zijn er ook nog m:n relaties tussen Account en ConstraintSet, waarmee de managers en
submitters van een ConstraintSet worden vastgelegd. Een Account kan van meerdere
ConstraintSets manager/submitter zijn, en een ConstraintSet kan meerdere Accounts als
manager/submitter hebben. Ook deze m:n relaties moeten in het Entity Framework expliciet worden
opgegeven:
// Specify many-to-many relations between ConstraintSet and Account
modelBuilder.Entity<ConstraintSet>()
.HasMany(c => c.Managers)
.WithMany(a => a.CanManageConstraintSets)
.Map(q =>
{
q.ToTable("ManageConstraintSet");
q.MapLeftKey("ConstraintSetID");
q.MapRightKey("AccountID");
});
Hiërarchie
Het Entity Data Model bevat ook de hiërarchie tussen verschillende klassen. Deze hiërarchie kan
uiteindelijk in de database niet behouden worden, omdat alle data wordt opgeslagen in platte
tabellen. Daarom is de standaard aanpak van het Entity Framework dat van een superklasse (bijv.
Constraint) alle subklassen (bijv. CompareConstraint, DataTypeConstraint, etc.) naar dezelfde
tabel gemapped worden. In een apart veld Discriminator wordt bijgehouden van welk type een
record oorspronkelijk was. Deze aanpak heet Table per Hierarchy (TPH).
Vaak zullen subklassen extra velden hebben ten opzichte van hun superklasse, bijvoorbeeld de
velden CompareType en CompareValue van CompareConstraint. Bij de mapping naar één tabel
worden alle velden van de subklassen toegevoegd aan de velden van de superklasse, zoals zichtbaar
in de definitie van de Constraint tabel in Figuur 7. Uiteraard zijn deze velden alleen van toepassing
voor één subklasse, in andere gevallen wordt er NULL ingevuld. Een mogelijk nadeel is dat de
samengevoegde tabel vol kan komen te staan met veel NULL waarden, zoals bijvoorbeeld zichtbaar
wordt in Figuur 8.
32
Figuur 8 - Voorbeeld van de database inhoud van tabel Constraint
Het Entity Framework biedt de mogelijkheid om aparte tabellen te maken voor subklassen; deze
aanpak heet Table per Type (TPT). In dat geval worden de velden van de superklasse in de hoofdtabel
ingevuld, en specifieke velden voor die subklasse in een aparte tabel. Bij DeliverXL wordt deze
methode bijvoorbeeld toegepast bij Position tabel. Dit moet expliciet worden opgegeven met
behulp van de Fluent API:
// Apply Table-Per-Type (TPT) Inheritance for Position
modelBuilder.Entity<CellPosition>().ToTable("Position");
5.2. View
In de Model View Controller aanpak verzorgt de view de informatieweergave. Bij een strikte
scheiding beschrijft de view enkel de user interface en worden er geen berekeningen of andere
controles gedaan. In dit hoofdstuk wordt de implementatie van de view toegelicht, waarbij
verscheidene onderwerpen aan bod zullen komen. Als eerste wordt uitgelegd hoe een model wordt
weergegeven met behulp van Razor code. Daarna wordt uitgelegd op welke manier deze techniek
gebruikt is om modellen met hiërarchie weer te geven. Ten slotte worden de frameworks besproken
die gebruikt zijn voor de implementatie van de views.
5.2.1. Weergave van een model in de view
Zoals in paragraaf 5.1 is uitgelegd, bevat een model de definitie van de informatie waarmee gewerkt
wordt. In de view wordt deze informatie weergegeven. Daarom is het verstandig om views strongly
typed te maken; er wordt precies opgeven welke klasse een view verwacht, alleen dit type klasse kan
worden weergegeven met deze view. De view code is een samenvoeging van client-side code (zoals
HTML, Javascript en CSS), en server side code (in dit geval Razor code). Een versimpelde versie van
ConstraintSetCreateViewModel, de view voor het aanmaken van een voorwaardenset, ziet er als
volgt uit:
33
@model DeliverXL.Models.ConstraintSetCreateViewModel
<h2>@ViewBag.Title</h2>
<hr>
@using (var form = Html.Bootstrap().Begin(new Form()))
{
@Html.HiddenFor(model => model.ID)
@form.ControlGroup().TextBoxFor(model => model.Name)
<div class="form-actions">
@Html.Bootstrap().SubmitButton().Text("Create").Class("btn-primary")
@Html.Bootstrap().ActionLinkButton("Cancel", "Index")
</div>
}
Op de eerste regel wordt gespecificeerd voor welk type model deze view geldig is. Daarna wordt er
een HTML Bootstrap formulier begonnen waarbinnen twee HTML inputs voor twee attributen van
het model worden gemaakt: een input van het type ‘hidden’ voor het veld ID en een input van het
type ‘text’ voor het veld Name. Dit stuk code laat goed zien hoe Razor en HTML door elkaar gebruikt
kunnen worden, en hoe eenvoudig het hiermee is om views te maken.
Op deze manier zijn voor elk model enkele views gemaakt. Meestal heeft een model meerdere usecases, zoals toevoegen, bewerken en weergeven. Daarnaast wordt er vaak ook nog een lijstweergave
van een model gemaakt.
Tabel 1 toont een opsomming van alle views die DeliverXL op dit moment kent (behalve de partial
views van het model Constraint, zie paragraaf 5.2.2). Elk van deze views staat in verbinding met
een gelijknamige action in bijbehorende controller. In paragraaf 5.3 wordt uitgelegd wat elk van die
actions doet. In Bijlage E zijn enkele screenshots te vinden van onderstaande views.
Tabel 1 - Overzicht van alle views in DeliverXL
ConstraintSet
SubmittedFile
Account
Overig
Create
Add
Create
Home
Edit
Uploads (lijst)
Edit
Error views
Index (lijst)
Result
Index (lijst)
Manage
Submissions (lijst)
Login
ManageSheet
SubmittedBy
Templates (lijst)
5.2.2. View van models met hiërarchie
In eerste opzicht leek deze manier van implementeren gemakkelijk, maar in de praktijk werd al gauw
tegen de beperkingen aangelopen. De grootste hiervan was het ontbreken van ondersteuning voor
hiërarchie in de model klassen.
Zoals in het paragraaf 5.1.1 te lezen is, heeft het model Constraint een uitgebreide hiërarchie.
DataTypeConstraint is bijvoorbeeld een subklasse van CellConstraint, wat vervolgens weer een
subklasse van Constraint is. Om een DataTypeConstraint toch goed weer te geven, is gebruik
34
gemaakt van partial views. Partial views zijn niet volledige weergaves van een model en bevatten
vaak één (vaker terugkerend) element, zoals de menubalk. Uiteindelijk is er een view gemaakt voor
Constraint waarin alles wat de subklassen gemeen hebben wordt weergegeven. Deze view roept
vervolgens afhankelijk van het type voorwaarde de desbetreffende partial view aan voor het
weergeven van voorwaarde-specifieke elementen.
5.2.3. Bootstrap
Om alles goed te kunnen weergeven, is gebruik gemaakt van verschillende frameworks. Bootstrap is
daar één van. Bootstrap is een front-end framework dat het ontwikkelen van websites makkelijker
maakt. Voor DeliverXL is van Bootstrap gebruik gemaakt voor het weergeven van alle interface
elementen, zoals menu’s, knoppen, tabellen, enzovoorts. Op deze manier is een consistente lay-out
voor de hele webapplicatie gewaarborgd en hoeft er niet onnodig veel tijd gebruikt te worden om
interface elementen te ontwerpen. Figuur 9 toont een voorbeeld van de interface, waarbij
verschillende Bootstrap elementen zichtbaar zijn (menu balk, titels, iconen, tabelweergave, e.d.).
Figuur 9 - Voorbeeld van verschillende Bootstrap elementen in gebruik bij DeliverXL
Standaard wordt Bootstrap toegepast door simpelweg de juiste HTML code met CSS klassen van
Bootstrap te gebruiken. Bij DeliverXL wordt echter gebruik gemaakt van nog een extra framework,
namelijk TwitterBootstrapMVC5. Hiermee is de integratie van ASP.NET MVC en Bootstrap nog
eenvoudiger, omdat alle Bootstrap elementen in de views automatisch kunnen worden gegenereerd
met behulp van Razor code. Het code voorbeeld in paragraaf 5.2.1 laat zien hoe dit wordt toegepast.
Voor TwitterBootstrapMVC is een licentie nodig als Bootstrap 3, de laatste versie van Bootstrap,
wordt gebruikt. Het gebruik van TwitterBootstrapMVC voor Bootstrap versie 2.3.2 is wel gratis,
daarom hebben we voor deze versie gekozen in DeliverXL. Deze versie biedt meer dan voldoende
mogelijkheden ten opzichte van het uitgebreidere Bootstrap 3.
5.2.4. Handsontable
Een ander gebruikt framework is Handsontable voor de weergave van de Excel bestanden in een
web-interface. Handsontable maakt het mogelijk om op basis van een eenvoudige Javascript-array
(de Excel data) een volledige weergave van een Excel sheet op te nemen. Handsontable kent talloze
opties en mogelijkheden voor het maken van de weergave. Het resultaat is te zien in Figuur 10.
5
https://www.twitterbootstrapmvc.com/Documentation/V2
35
Figuur 10 - Voorbeeldweergave van een simpel Excel bestand
Hieronder is een voorbeeld te hoe de initialisatie van Handsontable werkt:
$("#excelTable").handsontable({
data: getExcelData(),
minSpareRows: 10,
minSpareCols: 10,
colHeaders: true,
rowHeaders: true,
stretchH: 'all',
readOnly: true,
});
De Javascript-array met de Excel data, die in C# gegenereerd wordt vanuit het Excel bestand, ziet er
bijvoorbeeld als volgt uit:
var getExcelData = (function () {
return {
"Blad1": [
["Naam", null],
["Leeftijd", null],
["Ingeleverd op", null],
[]
],
"Blad2": [ [] ],
"Blad3": [ [] ]
}
})();
36
Aanvankelijk was er gekozen om jQuery.Sheet te gebruiken voor de weergave van de Excel
bestanden. Dit is geprobeerd, maar uiteindelijk bleek de uitgebreide functionaliteit en ingewikkelde
code opbouw van jQuery.Sheet meerdere malen in de weg te zitten om gemakkelijk toegepast te
worden voor DeliverXL. Handsontable bleek achteraf toch een veel beter alternatief, vooral vanwege
goede uitbreidingsmogelijkheden.
De werking van Handsontable is op meerdere punten uitgebreid. Allereerst was er in Handsontable
geen ondersteuning voor meerdere werkbladen; er is een balk gemaakt (in de stijl van Bootstrap)
met de mogelijkheid om te wisselen van werkblad. Bij het wisselen van een werkblad wordt de
nieuwe data ingeladen in Handsontable en wordt bovendien de URL aangepast. Dit maakt het
mogelijk via een directe link terug te keren naar dezelfde pagina met het gekozen werkblad
automatisch geopend.
Verder is er een eigen context menu toegevoegd, wat verschijnt als met de rechtermuisknop op een
cel wordt geklikt. In dit menu zijn de opties ‘Add constraint’ en ‘View constraints’ aanwezig, die een
eigen Javascript functie aanroepen waardoor er dan acties kunnen worden uitgevoerd.
Tenslotte is de renderer van Handsontable uitgebreid zodat zelf de weergave van de cellen bepaald
kan worden. Dit was nodig om opgemaakte tekst (bijvoorbeeld vetgedrukt, schuingedrukt, ander
lettertype en andere tekstkleur) in de cellen te kunnen tonen, wat uiteraard regelmatig in Excel
bestanden voorkomt. Daarnaast wordt de achtergrondkleur van een cel vervangen als er
voorwaarden op die cel gelden. Hierdoor heeft de gebruiker in één oogopslag overzicht van alle
voorwaarden op het Excel bestand.
5.2.5. Overige frameworks
Naast Bootstrap en Handsontable zijn nog verschillende andere frameworks gebruikt. jQuery is
gebruikt om het programmeren in Javascript makkelijker te maken en op een eenvoudige wijze te
opereren met de DOM (Document Object Model). Zowel Bootstrap als Handsontable maken ook
gebruik van jQuery. Verder is er gebruik gemaakt van jQuery-tmpl voor het dynamisch genereren en
invullen van elementen in de DOM. Zo is er bijvoorbeeld in de weergave van de Excel sheet de
mogelijkheid om van een bestaande voorwaarde het type te veranderen. Hiervoor wordt met een
enkele aanroep naar jQuery-tmpl de HTML code van voorwaarde-specifieke elementen vervangen,
door de code die in van te voren in een template staat opgegeven. Een voorbeeld van zo’n template
(versimpeld) is die van DataTypeConstraint:
<script type="text/x-jquery-tmpl" id="DataTypeConstraintTemplate">
<div>
<label for="DataType">Data type</label>
<div class="controls">
<select id="DataType" name="DataType">
<option selected="selected">Text</option>
<option>Number</option>
<option>Date</option>
<option>Boolean</option>
<option>Currency</option>
</select>
</div>
</div>
</script>
37
Naast jQuery-tmpl is er ook nog gebruikt gemaakt van jQuery-validate om client-side validatie van de
invoervelden uit te voeren. Het voordeel hiervan is dat er niet onnodig veel aanroepen naar de
server nodig zijn en veel functionaliteit direct client-side in de browser wordt uitgevoerd.
5.3. Controller
De controller in de Model View Controller aanpak zorgt ervoor dat informatie uit de models aan de
view wordt doorgegeven, en interpreteert de acties van de gebruiker. Daardoor is de controller vaak
afhankelijk van zowel het model als de view. De controllers van DeliverXL hebben toegang tot de
database en bevatten allerlei methoden om zogenaamde acties uit te voeren.
De acties van alle soorten gebruikers zijn onderverdeeld in verschillende categorieën, namelijk Home,
Base, Account, ConstraintSet en UploadedFile. Voor ieder van deze categorieën bestaat er een
controller klasse. In dit hoofdstuk worden allereerst de controllers in hun algemeenheid besproken,
waarna van iedere controller de actiemethoden worden toegelicht.
5.3.1. Algemeen
Omdat niet iedere gebruiker alle acties mag uitvoeren en dus niet alle methoden mag uitvoeren
wordt er gebruik gemaakt van autorisatie. Autorisatie wordt als volgt in een controller voor een
methode of zelfs de hele controller klasse aangegeven:
[Authorize(Roles = "RoleName")]
In plaats van RoleName wordt aangegeven, gescheiden met een komma, welke rollen er
geautoriseerd zijn om de methode uit te voeren. Als een methode is geautoriseerd en een gebruiker
nog niet is ingelogd dan wordt de inlog methode van AccountController aangeroepen. De
gebruiker kan dan alsnog geautoriseerd zijn voor de methode. Dit Authorize attribuut maakt
gebruik van de methode IsInrole die gedefinieerd staat in de klasse Account, om op te vragen of
een gebruiker die rol vervult.
Daarnaast gebruiken controllers vaak private methoden waaronder de methoden beginnend met
‘populate’. Deze methoden zijn bedoeld om extra data afkomstig van de database mee te geven aan
de view doormiddel van de ViewBag.
De controllers van DeliverXL maken vaak gebruik van de methoden en extensies in Utils klassen. Deze
methoden worden meerdere malen in verschillende klassen aangeroepen en zijn daarom in Utils
geplaatst om dubbele code te voorkomen. Tijdens het behandelen van de controllers zal er worden
verwezen naar Utils. Een uitgebreidere uitleg van Utils is te vinden in paragraaf 5.4.
Bij het opvragen van een lijst of een element uit de database wordt gebruik gemaakt van Linq
expressies. Een voorbeeld daarvan is hier te zien voor de Index methode van
ConstraintSetController:
38
[Authorize(Roles = "Manager")]
public ActionResult Index(string sort, string order)
{
List<ConstraintSet> constraintSets = db.ConstraintSets
.Where(cs => !cs.Deleted && cs.Managers.Select(s => s.ID).Contains(User.ID))
.OrderBy(cs => cs.ID)
.SortConstraintSets(sort, order);
return View(constraintSets);
}
Verderop in dit hoofdstuk wordt uitgelegd wat deze methode precies doet. Wat het voordeel is van
het gebruik van Linq-expressies, is dat deze werken via lazy-loading. Pas in de laatste stap van de
expressie wordt er daadwerkelijk een aanroep naar de database gedaan. Dit verminderd het
dataverkeer tussen de controller en de database en voorkomt grote berekeningen in de controller
terwijl de database daar efficiënter in is.
Het bovenstaande stuk code vraagt een lijst van voorwaardensets op. Vaak gebeurt het ook dat er
precies één element per ID wordt opgevraagd. Daarvoor is dan deze code gebruikt:
if (id == null)
return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
ConstraintSet constraintSet = db.ConstraintSets.FindById(id);
if (constraintSet == null)
return NotFound();
else if (!constraintSet.Managers.Contains(User))
return Forbidden();
Hiermee worden de standaardcontroles uitgevoerd bij het opvragen van een element. Bestaat het
element? Heeft de gebruiker toegang tot het element? Als dit niet het geval is wordt de
bijbehorende foutmelding weergegeven, zoals die gedefinieerd zijn in BaseController (zie
hieronder).
5.3.2. HomeController
Allereerst is er de standaard controller waar de Index methode wordt
aangeroepen zodra er geen controller wordt gespecificeerd in de URL
(dit staat in RouteConfig.cs). Daarom is deze controller logischerwijs
de HomeController genoemd.
Deze controller bevat alleen de Index methode die de
ontvangstwebpagina verzorgt. Er wordt in deze controller geen gebruik
gemaakt van een andere actiemethode of een model zoals in het klasse
diagram van Figuur 11 te zien is.
39
Figuur 11 - Klassendiagram
HomeController
5.3.3. BaseController
BaseController is net als HomeController geen grote klasse. Deze
controller wordt gebruikt voor standaard methoden die vanuit alle
controllers moeten kunnen worden aangeroepen en attributen die alle
controllers moeten bevatten. De controllers die deze methoden en
attributen nodig hebben erven over van BaseController.
Iedere controller kan, door het overerven van BaseController, het
User attribuut gebruiken om de gegevens van het ingelogde account te
kunnen gebruiken, mits er een gebruiker ingelogd is natuurlijk. Dit is
mogelijk door de volgende code uit BaseController:
Figuur 12 - Klassendiagram
BaseController
protected virtual new Account User
{
get { return HttpContext.User as Account; }
}
Ook hebben de controllers de methoden om standaard http excepties te kunnen retourneren dankzij
BaseController. Dit zijn de methoden NotFound en Forbidden zoals te zien is in Figuur 12.
5.3.4. AccountController
AccountController is minder basaal dan de vorige twee
controllers en werkt met het model Account. De
methoden in deze controller kunnen onder andere
accounts aanpassen, toevoegen, verwijderen en opvragen.
Dit wordt gedaan door gebruik te maken van de
DeliverXLContext, wat een verbinding is met de
database via het Entity Framework. De administrator heeft
in AccountController meer bevoegdheden dan de
manager en de submitter.
Een overzicht van de methoden is te zien in Figuur 13. De
verschillende actiemethoden zullen hieronder worden
uitgelegd.




Figuur 13 - Klassendiagram AccountController
Index: De Index methode is alleen toegankelijk voor administrators. Deze methode haalt de
accounts uit de database en geeft deze door aan de view.
LogIn: Zodra de gebruiker zijn inloggegevens heeft ingevuld wordt de POST versie van de
LogIn methode uitgevoerd. Als de inloggegevens kloppen, wordt er een ticket van de
ingebouwde klasse FormsAuthentication aangemaakt met de juiste accountdata. Dit wordt
gedaan zodat iedere controller en view de accountdata/gebruikersdata kan opvragen door
het User attribuut op te vragen. User is een instantie van Account. Het ticket wordt gemaakt
in de private methode GenerateLoginCookie.
LogOut: De LogOut methode verwijdert het ticket van het account dat is gemaakt tijdens het
inloggen.
Create: Met deze methode kan een nieuw account aangemaakt of geregistreerd worden.
Een administrator moet bij het maken van een account minimaal één rol toekennen aan het
40


account om ‘lege’ accounts te voorkomen. Er wordt een bevestigings-e-mail gestuurd naar
de nieuwe gebruiker. Als een persoon zich registreert dan krijgt het account standaard de rol
submitter.
Edit: Met de Edit methode kan het eigen account aangepast worden. Iedereen kan zijn
eigen account aanpassen, maar er kunnen niet andere rollen worden toegewezen. Een
administrator is wel in staat rollen toe te wijzen aan andere accounts. Na het aanpassen
moet een account minimaal één rol hebben.
Delete: Met deze methode kan een administrator accounts (behalve zijn eigen account)
verwijderen. Verwijderen gebeurt door het veld Deleted op true te zetten.
5.3.5. ConstraintSetController
In ConstraintSetController staan methoden om met
ConstraintSets te werken, zoals weergegeven in Figuur 14.
De manager heeft toegang tot het aanmaken, verwijderen en
aanpassen van voorwaardensets en voorwaarden. Submitters
mogen, als de manager daar toestemming voor heeft gegeven,
uploaden voor bepaalde voorwaardensets. Hieronder staan de
verschillende methoden van de ConstraintSetController:







Index: Index zorgt voor een overzicht van de
voorwaardensets die door de ingelogde manager
beheerd mogen worden.
Templates: De Templates methode zorgt voor een
overzicht van voorwaardensets voor een submitter.
Create: Met Create kan een manager nieuwe
voorwaardensets aanmaken. Er wordt opgeslagen
Figuur 14 - Klassendiagram
welke accounts de voorwaardenset mogen beheren en
ConstraintSetController
welke accounts bestanden mogen uploaden en verzenden voor de voorwaardenset. Dit
wordt expliciet aangegeven door de manager die de voorwaardenset maakt. Het template
bestand, dat submitters kunnen downloaden, wordt opgeslagen door middel van
UploadHelper in Utils.
ClearSubmissions: Als een manager de verzonden bestanden van een bepaalde
voorwaardenset niet meer nodig heeft, omdat hij de bestanden heeft gedownload kan hij
deze bestanden verwijderen door middel van deze methode. Omdat de boolean Deleted op
true gezet wordt, behoudt het systeem de data. Op deze manier wordt hier dataverlies
uitgesloten.
Delete: Met de Delete methode kan een manager een voorwaardenset verwijderd op de
bekende manier door de boolean Deleted op true te zetten. Op dezelfde manier worden
alle geüploade bestanden verwijderd.
Download: Zowel managers als submitters mogen een template bestand downloaden dat bij
een voorwaardenset hoort als de manager of submitter daarvoor bevoegd is. Het bestand
krijgt voordat het wordt gedownload een extra property in de meta data waarin het ID van
de bijbehorende voorwaardenset wordt vermeld. Als het bestand wordt ingevuld en weer
wordt ingeleverd hoeft door de submitter niet meer worden aangegeven bij welke
voorwaardenset het bestand hoort.
Edit: Managers kunnen via deze methode de voorwaardenset aanpassen. Ook kan de
template worden veranderd. Dit kan echter niet gebeuren als er in het template bestand
werkbladen zijn verwijderd of van naam gewijzigd.
41



Manage: De manager kan met deze methode voorwaardensets aanpassen door voorwaarden
toe te voegen, aan te passen of te verwijderen. Als deze methode de nieuwe voorwaarden
krijgt, wordt er achterhaald welke voorwaarden zijn toegevoegd, verwijderd en aangepast.
Daarop volgend worden er voor deze drie groepen aanpassingen gedaan aan de database.
ManageSheet: Ook de ManageSheet methode zorgt ervoor dat een manager voorwaarden
kan toevoegen, aanpassen en verwijderen. De wijze waarop de manager dit kan doen
verschilt met die van de Manage methode. Aanpassingen aan de voorwaarden worden
uitgevoerd met behulp van Ajax aanroepen naar de methoden Constraint en Constraints.
SubmittedBy: De manager kan via deze methode te zien krijgen welke bevoegde submitters
wel en welke niet voor een bepaalde voorwaardenset een bestand hebben verzonden. De
methode is ervoor om de manager een duidelijk beeld te geven over de voortgang van de
ingeleverde bestanden. In het geval dat er gebruik wordt gemaakt van periodiek inleveren
dan kan de manager dit overzicht voor een voorwaardenset resetten door middel van de
eerder uitgelegde ClearSubmissions methode.
5.3.6. UploadedFileController
Het model waaraan UploadedFileController is gerelateerd,
is het UploadedFile model. UploadedFileController heeft
methoden die de aanpassingen aan de database van de
UploadedFiles en de weergave voor de gebruiker van de
UploadedFiles verzorgt. Het klassendiagram is te zien in
Figuur 15. Ook kan deze controller checks uitvoeren op
ingeleverde bestanden en de gebruiker via commentaar in de
bestanden en in de views laten weten of het bestand aan de
voorwaarden van de manager voldoet en wat er in conflict is
met de voorwaardenset. Hier volgt een overzicht van alle
methoden:







Submissions: Deze methode geeft voor een manager
Figuur 15 - Klassendiagram
UploadedFileController
een lijst met ingeleverde bestanden terug.
Uploads: Uploads geeft voor een submitter een lijst met zijn geüploade bestanden terug.
Download: Met deze methode kan een manager een ingeleverd bestand downloaden.
DownloadResult: DownloadResult laat een submitter zijn geüploade bestand downloaden.
Er wordt commentaar toegevoegd aan de cellen die in conflict zijn met de opgelegde
voorwaarden. Hierbij wordt gebruik gemaakt van de private methode PutCommentsInFile
die gebruik maakt van ExcelParser en ExcelReader (zie paragraaf 5.4).
Result: De Result methode is alleen toegankelijk voor een submitter. De submitter kan via
deze methode direct het resultaat van een UploadedFile opvragen met het commentaar bij
conflicterende voorwaarden die opnieuw gecontroleerd worden.
Add: Om als submitter een UploadedFile toe te voegen wordt deze methode aangeroepen.
Bij het downloaden van een template wordt het ID van de bijbehorende voorwaardenset in
de metadata van het bestand gezet. Zo mogelijk wordt dit ID weer uit het bestand
uitgelezen. Het bestand wordt direct gecontroleerd volgens de bijbehorende
voorwaardenset. Het resultaat wordt opgeslagen.
Send: Met de methode Send verstuurt een submitter een bestand naar de managers. Dit kan
alleen als het bestand voldoet aan de voorwaardenset. Het versturen gebeurt door de
42

boolean Submitted op true te zetten. De managers worden op de hoogte gebracht van een
verzonden bestand doormiddel van een mail.
Delete: Door de boolean Delete van een UploadedFile object op true te zetten wordt
een bestand verwijderd. Managers kunnen alleen naar hen verstuurde bestanden
verwijderen. Submitters kunnen alleen niet verzonden bestanden verwijderen.
5.4. Utils
De klassen in Utils zijn ervoor om dubbele code in bijvoorbeeld de controllers te voorkomen. De
klassen worden vaak meerdere malen in de controllers gebruikt en zorgen ervoor dat de code in de
controllers overzichtelijk blijft. Dit hoofdstuk zal de klassen van Utils behandelen die belangrijk zijn
voor de werking van de controllers. Dit betreft de klassen voor het controleren van een spreadsheet,
het uitlezen van spreadsheets en het sorteren en filteren van lijsten. Deze klassen functioneren als
hulp voor voornamelijk de controllers.
ExcelParser
De ExcelParser wordt gebruikt om een Excelsheet op verschillende onderdelen checks uit te
voeren. De belangrijkste methode is dan ook de Parse methode die ook van groot belang is voor de
werking van DeliverXL, omdat deze methode resultaat terug geeft over de checks op een bestand.
De Parse methode krijgt als invoer een UploadedFile die gecontroleerd moet worden. Doormiddel
van die invoer wordt de gerelateerde voorwaardenset opgehaald en daarnaast wordt om de
Excelsheet te kunnen lezen een ExcelReader aangemaakt. Deze kan worden gemaakt door het pad
van de UploadedFile mee te geven aan de constructor van ExcelReader. De ExcelReader is ook
een klasse van Utils en wordt later in dit hoofdstuk behandeld. Zodra er een ExcelReader is en een
ConstraintSet, kan er een check worden uitgevoerd over de verschillende voorwaarden. De
voorwaarden hebben een methode die resultaat geeft of de Excelsheet, aan de opgegeven
voorwaarden voldoet. Deze checkmethoden maken gebruik van de ExcelCellExtension klasse die
ook later zal worden uitgelegd.
De resultaten van de checks op de verschillende voorwaarden worden uiteraard meegenomen in het
resultaat van de Parse methode. De controllers kunnen met die resultaten de gebruiker feedback
geven en de gebruiker op de hoogte brengen van de status van hun ExcelSheet.
ExcelReader
De ExcelReader is ervoor om ExcelSheets uit te lezen doormiddel van Gembox. Hier staat dus de
Gembox licentie aangegeven en ook de sleutelnaam voor de metadata van het bestand, als deze
gedownload wordt. Doormiddel van het pad van het bestand kan er een ExcelFile worden
ingeladen. Op basis van de methoden van de klasse ExcelFile zijn er in ExcelReader methoden
geschreven die bijvoorbeeld benodigde instanties van Gembox klassen zoals ExcelCell, ExcelRange
of ExcelWorksheet kunnen retourneren. Hier wordt de vertaalstap gemaakt van de klassen van
DeliverXL naar wat er van een ExcelFile nodig is.
ExcelCellExtension
Zoals bij de ExcelParser naar voren is gekomen wordt er bij het controleren van voorwaarden
gebruik gemaakt van deze klasse. Zoals de naam van de klasse, ExcelCellExtension, doet
vermoeden verschaft deze klasse extensies voor de ExcelCell klasse gedefinieerd in de Gembox
API. Deze extensies zorgen voor leesbare code in de check methoden van de Constraint models.
43
Deze check methoden kunnen op instanties van ExcelCell worden aangeroepen. Deze extensies
retourneren bruikbare data voor het checken van voorwaarden zoals of een Excel cel een fout bevat,
een datum is, kleiner is dan een bepaalde waarde, het datatype van een cel et cetera. De logica van
het checken van een voorwaarde gebeurt vooral in deze klasse. Doordat de check methoden van de
Constraint klassen gebruik maken van deze extensies blijven ze overzichtelijk en wordt dubbele
code vermeden.
Een voorbeeld van zo’n methode is de methode IsText, die true retourneert als de waarde in een
cel tekst is, die geschreven is omdat Gembox niet altijd correct kan bepalen of een waarde tekst is. In
paragraaf 5.5 worden de implementaties in detail besproken van deze en andere methoden.
FilterHelper
De FilterHelper bevat de klasse UploadedFileFilterHelper die controllers de mogelijkheid geeft
om UploadedFiles te filteren. Het is namelijk voor te stellen dat het aantal geüploade bestanden
vrij groot is en daardoor filteren overzichtelijkheid waarborgt. Ook bevat deze klasse de methode die
een BootstrapActionLink voor de view retourneert zodat er makkelijk een link wordt gemaakt in
de view om te kunnen filteren.
De FilterOn methode kan worden gebruikt in de controller om UploadedFiles te filteren. Aan deze
methode wordt meegegeven op welke waarden van de attributen van UploadedFile moeten
worden gefilterd. Deze methode roept voor ieder attribuut een speciale methode aan die de
UploadedFiles filtert op de meegegeven waarde.
SortHelper
Het sorteren van een verzameling instanties van een klasse wordt op een groot aantal plaatsen
gedaan om de gebruiksvriendelijkheid van DeliverXL te verhogen. Het was belangrijk voor de
onderhoudbaarheid van de code deze sorteerbaarheid generiek te maken. Daarom werkt
SortHelper onafhankelijk van de klasse waar de instanties van zijn. Ook geeft SorterHelper
methoden om een ActionLink en een sorteericon terug te geven. Hier is een stuk voorbeeld code
om een lijst te sorteren:
public static List<T> SortIQueryable<T>(Dictionary<string,
Func<IQueryable<T>, IOrderedQueryable<T>>> dict,
IQueryable<T> toBeSorted, string sort, bool orderDescending)
{
if (sort == null || !dict.ContainsKey(sort))
return toBeSorted.ToList<T>();
List<T> sortedList = dict[sort](toBeSorted).ToList<T>();
if (orderDescending)
sortedList.Reverse();
return sortedList;
}
SortIQueryable verwacht ten eerste een Dictionary die een string als sleutel heeft en een
functie voor IQueryable. Ook moet er worden meegegeven welke IQueryable moet worden
gesorteerd, waarop moet worden gesorteerd en of de volgorde aflopend is. De functie kan de
44
instanties sorteren door gebruik te maken van de functie die de waarde is van de Dictionary. Een
voorbeeld van zo’n Dictionary is als volgt:
var dict = new Dictionary<string, Func<IQueryable<ConstraintSet>,
IOrderedQueryable<ConstraintSet>>>()
{
{ "Name", list => list.OrderBy(cs => cs.Name) },
{ "DateAdded", list => list.OrderBy(cs => cs.DateAdded) },
{ "CreatedBy", list => list.OrderBy(cs => cs.CreatedBy.Name) },
{ "Constraints", list => list.OrderBy(cs => cs.Constraints.Count()) },
{ "SubmittedFiles", list => list.OrderBy(cs => cs.SubmittedFiles.Count()) },
};
De models waarop gesorteerd moet worden hoeven alleen een Dictionary terug te kunnen geven
die per sleutelwoord de juiste sorteerfunctie teruggeeft. Het model kan dus zelf de functie geven die
de SortHelper als een oplopende sorteerfunctie zal behandelen.
5.5. Controle van voorwaarden
Dit hoofdstuk behandelt hoe de voorwaarden die gecreëerd zijn door de manager gecontroleerd
worden. De methoden die besproken worden zijn extensies van de ExcelCell klasse en worden
aangeroepen door de Check methoden van de verschillende voorwaarden. Alle voorwaarden kunnen
geïnverteerd worden zoals uitgelegd in paragraaf 5.1. En als laatste wordt ook nog uitgelegd welke
en waarom sommige voorwaarden niet geïmplementeerd zijn.
CompareConstraint
In de klasse CompareConstraint wordt de voorwaarde op de volgende manier gecontroleerd: Er
wordt eerst gekeken of de cel geen fout bevat, als de cel namelijk een fout bevat dan kan er
natuurlijk niks vergeleken worden. Als de cel geen fout bevat dan wordt er gekeken van welk data
type de inhoud van de cel is, afhankelijk daarvan wordt de correcte vergelijk methode aangeroepen.
Hier volgt een versimpeld stuk code om een vergelijking uit te voeren:
public bool CompareTo(string constraintValue, CompareType type)
{
if (ContainsError())
throw new InvalidExcelValueInputException("The cell results in an
error. Cannot compare the value of this cell.");
if (IsNumber())
return CompareToNumber(constraintValue, type);
else if (IsCurrency())
return CompareToCurrency(constraintValue, type);
else if (IsDateTime())
return CompareToDateTime(constraintValue, type);
else if (IsBoolean())
return CompareToBoolean(constraintValue, type);
else if (IsText() || IsEmpty())
return CompareToText(constraintValue, type);
}
Elke vergelijk methode is anders voor elk data type.
45
DataTypeConstraint
Een voorwaarde van type DataTypeConstraint controleert of de inhoud van een cel aan een
bepaalde data type voldoet. Data types waar op gecontroleerd wordt zijn: tekst, getal, datum,
booleaanse waarden en valuta. De manier waarop deze voorwaarde gecontroleerd wordt, is als
volgt: Er wordt naar het data type gekeken wat de manager opgegeven heeft, en vervolgens wordt er
een methode aangeroepen die controleert of de inhoud van de cel ook daadwerkelijk van dat data
type is. Voor elk data type is er een aparte methode die dat controleert. Nu volgen versimpelde
stukken code van de methoden die de data typen controleren gevolgd door uitleg:
public bool IsBoolean()
{
if (IsEmpty() || ContainsError())
return false;
return CellDataType() == CellDataType.Boolean && !IsText();
}
Een cel is zeker niet van type Boolean wanneer hij leeg is of een fout bevat. Daarom wordt er eerst
daarop gecontroleerd. Om te verifiëren dat het wel om een Boolean gaat, wordt er gekeken of er
sprake van het type Boolean is en bovendien of het geen tekst is. Dit wordt gedaan omdat er ook in
een cel kan staan ‘WAAR’ of ‘TRUE’ als tekst en dit zijn geen booleaanse waarden.
public bool IsNumber()
{
if (IsEmpty() || ContainsError())
return false;
if (NumberFormat().Contains("E+") || NumberFormat().Contains("%"))
return true;
return CellDataType() == CellDataType.Number && !IsDate() && !IsText();
}
Om te controleren of iets een getal is, moet de cel wederom niet leeg zijn en geen fout bevatten. Als
er in de format string een ‘E+’ of een ‘%’ voorkomt dan is het automatisch een getal, want een ‘E+’
betekent namelijk een wetenschappelijke notatie van een getal en de ‘%’ betekent een breuk. Als
aan die condities niet voldaan is, dan wordt er gecontroleerd of het data type Number heeft en het
geen datum en geen tekst is. Er wordt expliciet op datum gecontroleerd omdat Excel een datum
opslaat als getal, wanneer deze datum gegenereerd is door een methode.
46
public bool IsDate()
{
if (IsEmpty() || ContainsError() || IsTextNumberFormat()))
return false;
if (CellDataType() == CellDataType.Date)
return !(Value.Year < 1900);
if (CellDataType() == CellDataType.Number
&& (new string[] { "m", "d", "y" })
.Any(c => NumberFormat().Contains(c)))
{
if (Value.Year >= 1900) return true;
}
DateTime dateTime;
return (CellDataType().Equals(CellDataType.Text)
&& DateTime.TryParse(Value, out dateTime));
}
Om te controleren of iets een datum is, wordt er weer gecontroleerd of de cel niet leeg is en geen
fout bevat en geen format string is waarmee een stuk tekst bedoeld wordt. Als aan die condities niet
voldaan is, wordt er vervolgens gecontroleerd of het van het type datum is. Zo ja, dan wordt er nog
naar het jaartal van de datum gekeken. Er wordt gecontroleerd of de datum vóór het jaar 1900
plaatsvond, want Excel heeft geen ondersteuning voor data vóór dit jaartal. Gembox heeft hier
gebruik van gemaakt door tijdsaanduidingen op te slaan als DateTime objecten in het jaar 1899.
Daarna wordt gekeken of de cel een getal is, vanwege een methode die een datum kan genereren,
maar deze opslaat als getal. Om dit te controleren wordt er naar de format string gekeken, als deze
een ‘m’, ‘d’ of ‘y’ bevat dan is het een datum mits na 1900 vanwege de beperkte ondersteuning voor
data in Excel. Als zelfs hierna nog oordeel geveld kan worden of het een datum is, dan wordt er met
C# de inhoud van de cel als datum geparsed. Het resultaat daarvan moet dan het uitsluitsel geven.
public bool IsTime()
{
if (IsEmpty() || ContainsError() || IsTextNumberFormat())
return false;
DateTime date;
if (CellDataType() == CellDataType.Date)
date = (DateTime)Value;
else if (CellDataType() == CellDataType.Text)
DateTime.TryParse(Value, out date);
else
return false;
return IsTimeSimple(date);
}
In Excel wordt er een onderscheid gemaakt tussen een datum en een tijd, terwijl er in ASP.NET
daarvoor één struct is, genaamd DateTime. Dus hier moest ook een aparte methode voor komen
47
en een het data type datum geldt dan ook als iets een datum of tijd is. De methode IsTimeSimple
controleert of er een ‘m’, ‘h’ of ‘s’ in de format string staat. Voor de rest werkt deze methode bijna
hetzelfde als IsDate.
public bool IsText()
{
if (IsEmpty() || ContainsError())
return false;
if (IsTextNumberFormat())
return true;
return CellDataType() == CellDataType.Text && !IsDate();
}
private bool IsTextNumberFormat()
{
return Style.QuotePrefix || NumberFormat().Equals("@");
}
Om te kijken of iets van data type tekst is, wordt er weer gekeken of de cel niet leeg is en geen fout
bevat. Als de format string met een apostrof of een ‘@’ begint dan betekent dat Excel expliciet
aangeeft dat het tekst is. Als dat ook niet het geval is wordt er nog gekeken of het geen datum is,
vanwege de beperkte ondersteuning en dan wordt er gekeken of het daadwerkelijk tekst is.
public bool IsCurrency()
{
if (IsEmpty() || ContainsError())
return false;
return NumberFormat().Contains("#,##")
|| NumberFormat().Contains("#.##");
}
Als laatste het data type, valuta. Hier wordt gecontroleerd of de format string hekjes bevat zoals
boven aangegeven. Dit is de manier van Excel om aan te geven dat de waarde van een cel een valuta
is.
EmptyConstraint
Als deze voorwaarde opgegeven is voor een cel, dan moet de cel leeg zijn. Dit wordt gecontroleerd
door de waarde van de cel op te vragen en te kijken of die gelijk is aan de null waarde. Die waarde
kent de Gembox API eraan toe als de cel leeg is.
ErrorConstraint
Deze voorwaarde kan worden gebruikt om op te geven of een cel wel of geen fout mag bevatten. Dit
wordt in de code op de volgende manier gecontroleerd:
48
public bool ContainsError()
{
if (CellDataType().Equals(CellDataType.Date))
{
var date = (DateTime)cell.Value;
if (date.Year < 1900 && !IsTimeSimple(date))
return true;
}
else if (IsFormula() && SystemType().Equals(typeof(string)))
{
return cell.Value[0].Equals("#"[0]);
}
return false;
}
Als de cel een van het type datum is maar het is geen tijd en de datum is vóór het jaar 1900 dan moet
het wel een fout zijn in Excel. Een andere manier waarop een fout kan ontstaan is doordat een
formule wordt gebruikt om iets uit te rekenen. In dat geval dat is de cel een formule en begint de
inhoud met een ‘#’. Anders heeft de cel geen fout.
FormulaConstraint
Als de manager deze voorwaarde oplegt op een cel, dan kan er geëist worden dat de cel een formule
bevat. De Gembox API maakt het mogelijk om dit gemakkelijk te controleren door naar het formula
veld van de cel te kijken. Als dit veld gelijk is aan de null waarde dan is het geen formule, anders
wel.
TextLengthConstraint
Met deze voorwaarde kan gecontroleerd worden of de inhoud van cel aan een bepaalde lengte
voldoet. Hier kan dan nog vergeleken worden of de lengte groter, kleiner of gelijk aan een bepaalde
lengte moet zijn. Bij de lengte van de inhoud van de cel wordt er gekeken naar de format string
alsmede de inhoud. Als er bijvoorbeeld 0.75 als inhoud staat en de format string is gelijk aan ‘?/?’
dan betekent dat Excel een breuk weergeeft, namelijk 3⁄4. De lengte hiervan is dan gelijk aan drie.
ErrorFileConstraint
Deze voorwaarde werkt het zelfde als de ErrorConstraint, maar dan op het gehele Excel bestand.
Omdat een Excel bestand veel kolommen en rijen kan bevatten wordt via de Gembox API opgevraagd
wat de laatste kolom en rij die ingevuld zijn, dit wordt gedaan per tabblad. Vervolgens wordt er voor
elke cel in die reeks de Check methode uitgevoerd die gedefinieerd staat in de klasse
ErrorConstraint. Als de Check methode dus maar één keer true terug geeft, is er niet voldaan aan
de voorwaarde.
NumberOfSheetsConstraint
Deze voorwaarde kan een beperking opleggen aan de hoeveelheid tabbladen die een Excel bestand
mag bevatten. Er kan een waarde opgegeven worden waarmee vergeleken moet worden. De
vergelijk methoden zijn: gelijk aan, groter of gelijk aan, kleiner of gelijk aan, groter dan en kleiner
dan.
49
TemplateChangedConstraint
Deze voorwaarde maakt het mogelijk om iemand alleen de lege cellen van een template in te laten
invullen. Als een cel dus niet leeg is in het template bestand, dan mag die niet worden veranderd. Als
de cel wel leeg is, dan mag die wel ingevuld worden.
Niet geïmplementeerde voorwaarden
In hoofdstuk 3.1 is aangegeven dat er een onderdeel van milestone 11 niet geïmplementeerd is. De
reden dat de mogelijkheid om een voorwaarde generiek te formuleren door het invullen van een
Excelformule niet is geïmplementeerd, ligt aan een beperking van de Gembox API. De formule die de
manager samenstelt, moet geëvalueerd worden op het moment dat een werknemer een Excel
bestand upload. Het evalueren van die formule kan niet gedaan worden door Gembox. Dit betekent
dat er een andere API gebuikt moest worden. Er werd ook een API gevonden die dat wel kan, maar
de gratis versie was gelimiteerd tot vijf tabbladen en 150 rijen per blad. De betreffende API heet:
Spire.Xls. De gratis versie is dus geen optie, aangezien in het bedrijfsleven er in één spreadsheet wel
meer dan vijf tabbladen kunnen voorkomen. De betaalde versie was volgens de opdrachtgever ook
geen optie, omdat Infotron al geïnvesteerd had in de Gembox API en Spire dusdanig duur was dat het
beter zou zijn om deze feature te schrappen.
5.6. Deployment
Uiteindelijk is het van belang om DeliverXL als webapplicatie te publiceren op een webserver. In de
ontwikkelfase hebben alle teamleden DeliverXL uitgevoerd op hun ontwikkelmachine (laptop). Deze
versie kan lokaal gedraaid worden (inclusief de database) om te kijken hoe de nieuwe features eruit
zien of om de gehele website te testen.
De website moet natuurlijk ook toegankelijk gemaakt worden voor de werknemers van de klant. Dit
betekent dat de webapplicatie moet draaien op een server waar alle gebruikers bij kunnen. Dit kan
bijvoorbeeld een gehoste server zijn die bereikbaar is voor het gehele internet, maar het kan een
server in een bedrijfsnetwerk zijn, waardoor de webapplicatie alleen intern bereikbaar is.
In beide gevallen moeten DeliverXL op die server worden gezet en moet er verbinding worden
gemaakt met een database server. Omdat DeliverXL in Visual Studio ontwikkeld is, is er de
mogelijkheid om direct vanaf de ontwikkelmachine de website op de server te zetten (zie Figuur 16).
De server moet daar natuurlijk wel geschikt voor zijn; systeemvereisten zijn Microsoft Windows en
een installatie van IIS. In Visual Studio kan een Publish profile gemaakt worden, waardoor met één
druk op de knop de laatste versie van DeliverXL uitgerold kan worden op de server. In dit Publish
profiel wordt ook expliciet de verbinding met de database server opgegeven; in het geval van de
server van Infotron is dit dezelfde machine.
Het deployment diagram van Figuur 16 toont dat ontwikkelaars kunnen verbinden met de web
server en met de SQL server. Ze zijn in namelijk in staat een deployment uit te voeren van zowel de
website en de database. De gebruiker kan verbinden met de web server door middel van het
HyperText Transfer Protocol (HTTP) en heeft geen directe toegang tot de database. De web server
kan wel met de database verbinden door middel van het Tabular Data Stream (TDS) protocol zoals
weergegeven in Figuur 16. De gebruiker heeft de web server dus nodig om met de database te
verbinden.
50
Figuur 16 - Deployment diagram van DeliverXL
5.7. Evaluatie
In dit hoofdstuk wordt besproken wat gedaan is om de code zo goed mogelijk te testen. Ook wordt
de feedback van de Software Improvement Group (SIG) besproken en hoe die feedback
meegenomen is in de volgende iteraties van het project.
5.7.1. Testmethoden
Voor elk project is het belangrijk om de code goed te testen. In het algemeen geldt: code die niet
getest is, is niet af. Om de meeste code te testen in de kleinste vorm mogelijk, gebruiken we unit
tests. In Visual Studio zijn standaard testmogelijkheden ingebouwd, maar deze functies zijn niet
volledig. Zo ontbreekt bijvoorbeeld de mogelijkheid om klassen te mocken (simuleren van objecten,
waarbij de programmeur zelf het gedrag kan bepalen van het object). Door een test framework als
NUnit te gebruiken, zijn er veel uitgebreidere mogelijkheden om te testen. Dit framework wordt ook
al gebruikt bij Infotron voor het testen van PerfectXL.
Voor de acceptance tests wordt het framework Selenium gebruikt. Dit framework maakt het mogelijk
om acties die een tester uitvoert op een webpagina op te nemen en weer af te spelen op een andere
snelheid, hierdoor kan er veel sneller getest worden. Op deze manier kan ook de interface getest
worden. Met dit framework kunnen tests geschreven worden in Visual C# die via de API van
Selenium de website van DeliverXL testen.
Voor het testen van DeliverXL waren beide software pakketten nodig, want ze vervullen beide een
andere rol. Een unit test framework test kleine delen van de functionaliteit, bijvoorbeeld een
methode of een functie. Een acceptance test zal het systeem als geheel testen, zodat er getest kan
worden of de functionaliteit van de applicatie aan de specificaties voldoet.
51
5.7.2. Testuitkomsten
Om veel acties te testen die de gebruiker kan uitvoeren, hebben de unit tests een referentie punt
nodig om te weten wat er in de database staat. Hiervoor zijn er setup en teardown functies. De setup
functie kan de database bijvoorbeeld geheel leeg maken en vullen met data. De data staat hardcoded
in een klasse beschreven, hierdoor weet het programma altijd wat zich in de database bevindt en
wat er mee gedaan kan worden tijdens een test. De setup functie kan worden geactiveerd voor elke
unit test, of voor elke klasse waar unit tests worden uitgevoerd.
De teardown functie kan worden geactiveerd elke keer als een unit test stopt, hetzij als hij slaagt of
faalt. De functie kan ook worden geactiveerd na elke klasse waarin unit tests worden uitgevoerd. De
bedoeling van deze functie is bijvoorbeeld om gecreëerde bestanden te verwijderen of om de
database connectie te sluiten.
Bij het testen is er veel tijd besteed aan het testen van de check methoden van voorwaarden, die
door de gebruiker opgegeven kunnen worden. Het was heel belangrijk om dit te testen, omdat dit de
belangrijkste functionaliteit is van het programma. Bovendien omvatten de check methoden een
groot stuk code, waarbij het niet altijd even logisch is, wat voor type de inhoud van een cel is. De
reden hiervoor is dat men bij Excel iets kan invullen in een cel en dat Excel hierin iets herkend, zoals
een datum of een getal. Maar de gebruiker kan ook expliciet aangeven of het een valuta, datum of
tekst moet zijn. Hier moet dus goed op gecontroleerd worden. En er moet ook nog rekening
gehouden worden met het feit dat Excel een datum niet als datum herkent als deze vóór 1 januari
1900 is.
Om alle checker methoden te testen, is gebruik gemaakt van test driven development (TDD). Dit
betekent dat er eerst unit tests geschreven zijn en daarna pas aan de implementatie voor de checker
methoden gewerkt is. Deze unit tests zijn geschreven door eerst in een Excel bestand allerlei
mogelijke invoer in te typen en zelf na te denken over een logische uitkomst per voorwaarde. Zie
Figuur 17 voor hoe dit bestand er uit ziet.
52
Figuur 17 - Excel bestand met per voorwaarde type een tabblad met mogelijke invoer. Op het weergegeven tabblad is te
zien wat het data type van elke cel behoort te zijn. Voor elke cel op het tabblad zijn er meerdere tests geschreven.
De implementatie werd zo groot en omslachtig, dat er soms dubbele brokken code in stonden. Dit is
uiteraard niet wenselijk omdat de code dan een stuk minder goed onderhoudbaar wordt. Er is toen
besloten om na de implementatie van de checker methoden, toen alle tests slaagden, de code te
verplaatsen en te herstructureren. In zo’n soort geval is het handig om al veel test cases geschreven
te hebben, want als er nu code veranderd wordt dan hoeft men alleen de tests uit te voeren om te
weten of de code nog wel klopt.
Gedurende het project is er veel tijd geïnvesteerd om de code goed te testen. In Tabel 2 is te zien
welke testklassen gemaakt zijn. Deze tests zijn opgedeeld in vier soorten.
De eerste soort is de controller-test. Bij deze tests worden de controllers getest of de uitvoer van een
actie bij een controller overeenkomt met de verwacht uitkomst. Wat het moeilijk maakte om dit te
testen is dat tijdens het uitvoeren van de test er geen http request bestond, in tegenstelling tot
normale uitvoering van de controller-code. Hiervoor was het dus nodig om de server en request
objecten te mocken. De tweede soort tests zijn de Utils-test. Bij deze tests worden de methoden van
de Utils-klassen getest. De derde soort tests zijn de Contraint-tests. Deze tests zijn dus zoals
hiervoor beschreven en te zien in Figuur 17 gemaakt op de check code van de Constraint-klassen te
testen. De laatste soort tests zijn de tests die de overige model klassen testen.
Tabel 2 - Een overzicht van alle tests opgedeeld per soort en per klasse
Testklasse
Aantal tests Testklasse
Controller-tests
Aantal tests
Constraint-tests
AccountControllerTest
10
CompareConstraintTest
107
ConstraintSetControllerTest
9
DataTypeConstraintTest
50
HomeControllerTest
1
EmptyConstraintTest
20
53
HomeSeleniumTest
1
SubmittedFileControllerTest 22
ErrorConstraintTest
30
ErrorFileConstraintTest
4
NumberOfSheetsConstraintTests 6
Utils-tests
TemplateChangedConstraintTest 6
DatabaseHelperTest
5
TextLengthConstraintTest
ExcelParserTest
10
ExcelReaderTest
7
FilterHelperTest
18
AccountTest
12
SortHelperTest
22
ConstraintTest
10
Overige model-tests
ValidateExcelFileTest
5.7.3. SIG feedback
De implementatie van DeliverXL is door SIG beoordeeld op kwaliteit en onderhoudbaarheid. Toen
ongeveer 75% van de projectduur verlopen was, is de code opgestuurd naar SIG om beoordeeld te
worden. De volledige eerste feedback is te vinden in Bijlage D. Hier volgt een samenvatting van de
eerste feedback:
-
-
-
-
Unit Size
Bij dit criteria wordt er gekeken naar de lengte van methoden. Het viel SIG op dat er één
methode bovengemiddeld lang was, namelijk: DeliverXLInitializer.Seed. In deze
methode wordt de database met testdata geïnitialiseerd.
Unit Interfacing
Hier wordt er gekeken naar de parameterlijst van methoden. Bij één methode werd er
gevonden dat de parameter lijst bovengemiddeld lang was, namelijk bij:
SubmittedFileController.Uploads. De manier waarop de filteropties doorgestuurd
werden aan deze methode zorgde ervoor dat er een lange lijst met optionele parameters
was.
Module Coupling
Hier was het voornaamste punt dat er soms meer dan één klasse werd gedefinieerd in een
enkel bestand. Dit komt volgens SIG de onderhoudbaarheid van de code niet ten goede.
Testen
De aanwezigheid van de test-code is goed.
Er is geprobeerd deze feedback zou goed mogelijk te verwerken voordat de code voor de tweede
keer opgestuurd zou worden. Daarvoor zijn onder andere de volgende wijzigingen toegepast.
Voor het punt ‘Unit Size’ is de code grondig doorgespit om te kijken welke methoden nog meer
bovengemiddeld lang zijn en als het mogelijk was deze methoden opgesplitst in kleinere methoden.
Het punt ‘Unit Interfacing’ is op het moment van schrijven nog niet opgelost, vanwege tijdgebrek in
verband met het schrijven van het eindverslag. Maar dit punt wordt zeker in de komende dagen
aangepakt. Een mogelijke oplossing voor dit punt zou kunnen zijn, om een dictionary object mee te
geven in plaats van een lange parameter lijst te specificeren.
En het laatste aanpak punt ‘Module Coupling’ is opgelost door alle klassen in een apart bestand te
definiëren.
De maximale haalbare score van SIG is vijf sterren; DeliverXL haalde drie sterren waardoor het een
gemiddeld onderhoudbaar systeem is na de eerste feedback ronde.
54
6. CONCLUSIE
Het doel van dit bacheloreindproject was het ontwikkelen van een programma genaamd DeliverXL,
waarmee op een gebruiksvriendelijke manier voorwaarden kunnen worden opgegeven waaraan een
spreadsheet dient te voldoen. Op basis hiervan kunnen ingevulde spreadsheets automatisch worden
gevalideerd en is direct duidelijk of een spreadsheet fouten bevat of niet.
Vanuit de oorspronkelijke opdrachtformulering (te lezen in Bijlage A) is tijdens de plannings- en
onderzoeksfase dit doel duidelijker verwoordt in de vorm van user stories, zoals te lezen is in
hoofdstuk 2. Op basis van deze eisen kan worden beoordeeld in welke mate dit project geslaagd was.
Uiteindelijk is de doelstelling van het project gehaald, omdat het eindproduct DeliverXL inderdaad de
mogelijkheid biedt op een gebruiksvriendelijke manier voorwaarden op te stellen voor een
spreadsheet en gebruikers duidelijke feedback ontvangen over hun ingeleverde spreadsheet. Alle in
hoofdstuk 2 benoemde ‘must-have’ en sommige ‘should-have’ eisen zijn succesvol in het
eindproduct verwerkt. De uiteindelijke functionaliteit omvat in hoofdlijnen:




Een manager kan een bestaande spreadsheettemplate uploaden en van verschillende
soorten voorwaarden voorzien in de vorm van een voorwaardenset.
Een werknemer kan de aan hem toegewezen spreadsheettemplates downloaden, invullen en
vervolgens uploaden om deze tegen de opgestelde voorwaarden te valideren.
Een werknemer krijgt te zien of zijn ingeleverde spreadsheet voldoet aan de voorwaarden
die zijn opgesteld en ontvangt feedback als dit niet het geval is.
Een manager heeft een overzicht van alle succesvol ingeleverde spreadsheetbestanden en
kan deze downloaden.
DeliverXL zou in principe in huidige staat op de markt gebracht kunnen worden. Toch zouden wij
adviseren, op basis van feedback uit het bedrijfsleven, eerst nog extra functionaliteit toe te voegen
om het product commercieel aantrekkelijker te maken. Enkele aanbevelingen hierover zijn te vinden
in hoofdstuk 7.
Het project was niet alleen succesvol in de zin dat alle eisen zijn behaald; het ontwikkelproces is
daarnaast ook erg goed verlopen en er heeft een goede samenwerking plaatsgevonden tussen de
teamleden, de opdrachtgever en de TU coach. De opdrachtgever kijkt als volgt terug op dit project:
“Johnny, Ruben, Koos en Willem-Jan hebben buitengewoon goed werk afgeleverd. Ze hebben niet
alleen intelligent geprogrammeerd, maar zijn ook in staat geweest te denken vanuit het
perspectief van de klant. Bovendien hebben ze de juiste balans gevonden tussen planmatig werken
in milestones en pragmatisch omgaan met verrassingen en mogelijkheden. Als het aan Infotron
ligt wordt dit slimme viertal ook betrokken in de vervolgstappen, waarin het commercieel
exploiteerbaar maken van DeliverXL voorop staat.” – Matéo Mol, directeur Infotron.
55
7. AANBEVELINGEN
Gedurende het project zijn er bij verschillende meetings met mogelijke afnemers van DeliverXL
meerdere extra functionaliteiten benoemd die DeliverXL een waardevoller product zouden maken.
Sommigen van deze zijn tijdens het project al opgepakt (zie paragraaf 3.2), omdat ze makkelijk te
implementeren waren en goed bleken te passen in het ontwikkelproces. Toch zijn is er nog een
heleboel nuttige functionaliteit die aan DeliverXL zou kunnen worden toegevoegd, waar in dit
hoofdstuk voorstellen voor worden gedaan.
7.1. Extra milestones
Omdat de ontwikkelmethode met milestones goed is bevallen, worden de aanbevelingen ook gedaan
in de vorm van milestones. De ontwikkelvolgorde is vanzelfsprekend een advies.
Milestone 12
 Het is mogelijk om voorwaardelijke voorwaarden op te stellen, in de vorm: als
Voorwaarde1 geldt, controleer dan Voorwaarde2. Een voorbeeld hiervan is: ‘als cel B10
niet leeg is, mogen cel C10 t/m E10 ook niet leeg zijn’.
 Voorwaardelijke voorwaarden kunnen met elkaar gecombineerd worden d.m.v. ‘en’ en
‘of’ operatoren. De vorm van de voorwaarden wordt dan:
o Als Voorwaarde1 en Voorwaarde2 en Voorwaarde3 gelden, controleer dan
Voorwaarde4.
o Als Voorwaarde1 geldt, controleer dan Voorwaarde2, Voorwaarde3 en
Voorwaarde4.
Milestone 13
 Een manager moet een voorwaardenset eerst publiceren voordat werknemers
bestanden voor deze voorwaardenset kunnen uploaden en opsturen.
 Bij het wijzigen van een gepubliceerde voorwaardenset (d.w.z. een wijziging van de
spreadsheet template of het wijzigen van voorwaarden) wordt een nieuwe versie van die
voorwaardenset gemaakt.
 Het uploaden van Excel bestanden om te controleren met oudere versies van
voorwaardensets is niet mogelijk. Waar mogelijk wordt automatisch gecontroleerd met
de nieuwere versie.
 Opgestuurde bestanden voor verouderde versies van voorwaardensets blijven bestaan,
maar kunnen door de manager alsnog geweigerd worden. De werknemer die dat
bestand opgestuurd heeft, wordt in dat geval op de hoogte gesteld.
Milestone 14
 Extra soorten voorwaarden kunnen worden opgegeven, zoals:
o Het Excel bestand heeft (g)een verborgen tabbladen.
o Een cel bevat een waarde met een bepaalde valuta.
o Komma’s en punten worden niet foutief (door elkaar) gebruikt.
o Een cel bevat voorwaardelijke opmaak.
o Een cel bevat specifieke invoer, zoals:
- Een e-mailadres
- Een telefoonnummer
- Een postcode
- Een adres
- Een IBAN banknummer
56
Milestone 15
 Bij het opgeven van een voorwaarde is er de mogelijkheid om de voorwaarde als
waarschuwing te laten fungeren.
 Het resultaat van een voorwaarde is niet alleen beperkt tot goed of fout, maar kan ook
een waarschuwing opleveren. Het is mogelijk om een bestand met waarschuwingen op
te sturen naar de manager.
Milestone 16
 Bij het opstellen van voorwaarden wordt gecontroleerd of een voorwaarde in conflict is
met andere voorwaarden. In dat geval wordt de voorwaarde niet geaccepteerd.
7.2. Toelichting op extra milestones
Voornamelijk milestone 12 is uit gesprekken met mogelijke afnemers naar voren gekomen. Als je
bijvoorbeeld een formulier hebt voor een nieuw personeelslid waarin je moet opgeven of er sprake is
van een auto van de zaak (zoals te zien in Figuur 18), hoeft er alleen gecontroleerd te worden op de
andere velden wanneer bij auto werkgever ‘ja’ is ingevuld.
Figuur 18 - Voorbeeld van een Excel template waar voorwaardelijke voorwaarden nuttig zouden kunnen zijn
Op het moment dat in cel D35 ‘ja’ ingevuld staat, zijn er meerdere voorwaarden die gecontroleerd
moeten worden: D36 bijvoorbeeld mag bijvoorbeeld niet leeg zijn en in cel H36 moet tekst staan
volgens de regels van een kenteken.
Milestone 13 wordt als belangrijk gezien omdat in de praktijk niet verwacht hoeft te worden dat een
voorwaardenset een statisch gegeven is. In sommige gevallen zullen herhaaldelijk wijzigingen
toegepast worden op een voorwaardenset of de spreadsheet template. Het is dan alleen niet
duidelijk wat er moet worden gebeuren met reeds opgestuurde bestanden die al gevalideerd zijn,
het is goed mogelijk dat deze opeens niet meer geldig zijn. Bovendien is ook niet duidelijk hoe moet
worden omgegaan met werknemers die nog een oude versie van de spreadsheet template hebben.
De voorgestelde oplossing in milestone 13 is slechts één van de mogelijke oplossingen. Een andere
mogelijkheid is om toe te staan dat een voorwaardenset gewijzigd wordt, maar dat alle opgestuurde
bestanden verwijderd worden en alle geüploade bestanden opnieuw geëvalueerd worden.
Milestone 14 is vooral bedoeld om DeliverXL als commercieel product aantrekkelijker te maken. Het
spreekt voor zich dat een bedrijf de aankoop van DeliverXL eerder zou overwegen als er een breed
scala aan soorten voorwaarden beschikbaar wordt gesteld. Mogelijk is het voor een bedrijf
bijvoorbeeld erg belangrijk om automatisch postcodes of IBAN nummers te controleren, waardoor
DeliverXL slechts zal worden aangeschaft als deze functionaliteit aanwezig is.
In navolging op de opdeling volgens het MoSCoW model uit paragraaf 2.3, verdienen milestones 12,
13 en 14 de benoeming ‘should-have’. Dit is tenslotte functionaliteit die duidelijk een toevoeging is
aan DeliverXL, de andere milestones hebben iets minder prioriteit omdat ze het gebruik van
DeliverXL enkel eenvoudiger maken.
57
REFERENTIES
[1] F. F. J. Hermans, Analyzing and visualizing spreadsheets, Delft, 2012.
[2] R. R. Panko, „What we know about spreadsheet errors,” Journal of End User Computing, vol. 10,
nr. 2, pp. 15-21, 1998.
[3] R. R. Panko, „Spreadsheet Errors: What We Know. What We Think We Can Do.,” in Proceedings of
the Spreadsheet Risk Symposium (European Spreadsheet Risks Interest Group), Greenwich,
England, 2000.
58
BIJLAGEN
Als bijlagen zijn nog enkele documenten aan dit eindverslag toegevoegd. Het gaat hierbij om
documenten die in de loop van het proces gemaakt zijn.
Bijlage A: Originele productomschrijving
In de originele productomschrijving is te lezen wat de oorspronkelijke opdrachtomschrijving is, die
geschreven is door Infotron.
Bijlage B: Plan van aanpak
Dit document is een verzameling afspraken waarin wordt vastgelegd wat het ‘probleem’ is dat
opgelost gaat worden in het project. Er wordt vastgelegd waaraan de opdrachtgever en de
projectleden moeten voldoen. Bovendien wordt beschreven hoe het project gefaseerd zal worden en
worden overige afspraken vastgelegd.
Bijlage C: Onderzoeksrapport
Het onderzoeksrapport vat de resultaten van de onderzoeksfase samen. In dit rapport moeten de
keuzes bij de aanpak van het probleem verantwoord worden. Hierin worden ook alternatieve
oplossingen onderzocht en vergeleken. In dit document worden keuzes omtrent programmeertalen,
frameworks, software architectuur etc. gemotiveerd.
Bijlage D: SIG feedback (1e versie)
Gedurende het project is tweemaal de code van het te leveren eindproduct DeliverXL opgestuurd
naar the Software Improvement Group (SIG). SIG heeft de broncode beoordeeld en van feedback
voorzien. De feedback op de eerste versie is te lezen in deze bijlage.
Bijlage E: Screenshots
In deze bijlage zijn screenshots van DeliverXL opgenomen om een indruk te geven hoe DeliverXL eruit
ziet.
59
BIJLAGE A
ORIGINELE PRODUCTOMSCHRIJVING
Originele opdrachtomschrijving
Project description
The case: Many organizations have central staffs for consolidating (financial and non financial)
numbers into spreadsheets. These numbers are coming from different employees or departments
within the organization. Often central staffs complain about the quality of the numbers that are
delivered. Empty cells, Non existing numbers, changed formats, etcetera. It is one of the biggest daily
Excel frustrations of controllers in large companies. The solution: Let’s make DeliverXL to solve this
problem! DeliverXL will be an easy to use web application to check whether delivered spreadsheet
information is correct or not. Much better than Excel templates. A great solution that reduces
controllers’ frustrations extremely. The app must be easy to use for very non-technical people, like
teammanagers in healthcare, teammanagers in factories, secretaries, etcetera. This is how DeliverXL
can work (but has to be discussed with you!): 1) Central staff set up the input validation rules in an
easy to fill spreadsheet and a webform, such as amount ranges between maximum and minimum,
cell types (strings, enumerations), non empty cells, spreadsheet template not altered, etc. 2)
Department-employee put the numbers in the spreadsheet. For all relevant departments 3)
Department-employee upload the spreadsheet on our web app 4) Automatically analyses by
DeliverXL 5) If ok -> central staff receives correct spreadsheet, department-employee gets thank-you
message 6) If not ok -> department-employee gets a list of improvement suggestions and he / she
has to upload e new file. New product, based on new and existing knowledge: Infotron already has a
product called PerfectXL. PerfectXL checks spreadsheets for technical risks (try it on beta.infotron.nl).
The main technical challenge consists of providing a way of specifying the input validation rules, and
subsequently checking them. To construct DeliverXL, the existing spreadsheet analysis infrastructure
of Infotron can be reused. Some other challenges: - Translating a webform (with questions about
requirements for the delivered spreadsheets) into automatic checks in the data - Making everything
as simple as possible for very non-technical users - Working with different languages (c#, ASP.NET,
HTML)
Company description
Infotron: Infotron is a spin-off of the TU Delft, started in 2011 by assistant Professor Felienne
Hermans and professor Arie van Deursen. Since summer 2013, CEO Matéo Mol joined the company.
PerfectXL is Infotron’s most important product. PerfectXL is the tool to understand, control and
improve spreadsheets. Customers are PwC, Roland Berger, SNSReaal and others. Infotron works
closely together with ProSE, Professionalizing Spreadsheet Engineering: at the Software Engineering
Research Group; funded by STW Infotron is base in Delft (TU) and Amsterdam.
BIJLAGE B
PLAN VAN AANPAK
DeliverXL - plan van aanpak
Projectgroep:
Willem-Jan Meerkerk
Ruben Vroegindeweij
Johnny Verhoeff
Koos van der Linden
Met begeleiding van:
Opdrachtgever: Mateo Mol
TU Coach: Bas Jansen
Project coördinator: Felienne Hermans
Project coördinator: Martha Larson
TU Delft, 25-4-2014
SAMENVATTING
Tijdens dit project wordt er gewerkt voor het bedrijf Infotron waarbij het op te leveren
softwareproduct DeliverXL genoemd zal worden. Bij het ontwikkelen van het product zal de
opdrachtgever de begeleider zijn vanuit Infotron. De coach van de Technische Universiteit Delft (TU
coach) zal zich vooral richten op het proces en kan daarbij ook voor ondersteuning gevraagd worden.
Het plan van aanpak kan als een verzameling afspraken worden gezien waarin een aantal belangrijke
zaken worden vastgelegd tussen de opdrachtgever, de TU coach en de projectleden. Dit wordt
gedaan om duidelijk te hebben wat er van elkaar verwacht mag worden.
Het probleem waarvoor een software-oplossing moet komen is als volgt gedefinieerd: ‘het incorrect
en onvolledig invullen van spreadsheets’. DeliverXL zal zich vooral richten op organisaties waarin het
gebruik van spreadsheets groot kan zijn en waarbij soms ook veel personeel dezelfde spreadsheet in
moet vullen.
Om een volledig systeem te ontwikkelen zijn er een aantal milestones gemaakt waarbij voor iedere
milestone functionaliteit wordt toegevoegd. Ook is er een planning gemaakt die aangeeft wat de
geschatte duur is van de milestones. Ieder teamlid heeft één of meerde vaste taken gekregen
waarvoor deze persoon verantwoordelijk is. Om de kwaliteit te waarborgen zijn er een aantal
afspraken gemaakt over vergaderingen, testen, stijlen, commentaar en het versiebeheersysteem.
Met behulp het programma Teamwork worden takenlijsten en milestones bijgehouden.
Het plan van aanpak is geldig als zowel de opdrachtgever als de TU coach als de software
ontwikkelaars het plan van aanpak goedkeuren. Als dit niet het geval is, dient de partij aan te geven
waarom het niet wordt goedgekeurd. Dan zullen de partijen rond de tafel gaan en zal het plan
mogelijk worden aangepast. Eventuele grote wijzigingen aan het plan van aanpak zullen schriftelijk
worden doorgegeven aan de opdrachtgever en de TU coach.
INHOUD
Samenvatting........................................................................................................................................... 2
Voorwoord .............................................................................................................................................. 4
1. Inleiding ............................................................................................................................................... 5
2. Projectopdracht ................................................................................................................................... 6
Projectomgeving.................................................................................................................................. 6
Opdrachtformulering .......................................................................................................................... 6
Op te leveren producten en diensten ................................................................................................. 6
Eisen en beperkingen .......................................................................................................................... 7
3. Aanpak en tijdsplanning ...................................................................................................................... 9
Milestones ........................................................................................................................................... 9
Tijdsplanning ..................................................................................................................................... 11
4. Projectinrichting ................................................................................................................................ 12
5. Kwaliteitsborging ............................................................................................................................... 13
Afspraken TU coach, opdrachtgever en interne meetings................................................................ 13
Testen ................................................................................................................................................ 13
Stijl en commentaar .......................................................................................................................... 13
Pair programming .............................................................................................................................. 13
Versiebeheersysteem en features .................................................................................................... 13
3
VOORWOORD
Het is belangrijk alvorens er gewerkt gaat worden aan het product DeliverXL voor Infotron een plan
van aanpak te hebben. Dit plan van aanpak kan als een verzameling afspraken gezien worden waarin
een aantal belangrijke zaken worden vastgelegd tussen de opdrachtgever, de TU coach en de
projectleden. Deze drie partijen moeten instemmen met het plan van aanpak zodat de partijen van
elkaar weten wat er van elkaar verwacht kan worden. Er wordt overeengekomen en omschreven wat
het probleem is dat opgelost gaat worden tijdens het project. Ook is het plan van aanpak er om een
goede samenwerking tussen de opdrachtgever, de TU coach en de projectleden te bewerkstelligen
en om aan elkaars eisen en verwachtingen te kunnen voldoen.
4
1. INLEIDING
Voor spreadsheets gelden vaak voorwaarden aan hoe een spreadsheet moet worden ingevuld. Het
incorrect invullen van zo’n spreadsheet is echter een veel voorkomend probleem. Vooral bij
middelgrote en grote bedrijven die regelmatig gebruik maken van spreadsheets is dit het geval.
Neem bijvoorbeeld het bedrijf van Eric.
Eric is werkgever van een bedrijf met dertig werknemers. Het bedrijf houdt zich bezig met de
financiën van individuele personen en helpt deze personen bij hun inkomsten- en uitgavenpatroon.
Omdat een cliënt vaak door meerdere werknemers geholpen wordt, worden spreadsheets gebruikt
om de financiën in kaart te brengen. Echter vullen de werknemers van het bedrijf de spreadsheets
verschillend van elkaar in. Dit leidt tot verwarring.
Infotron wil een oplossing aanbieden voor dit probleem: het incorrect en onvolledig invullen van
spreadsheets. Hiervoor wil het een systeem, DeliverXL, op de markt brengen dat een maker van een
spreadsheet template de mogelijkheid geeft voorwaarden te stellen aan het invullen van deze
spreadsheet. Infotron zoekt softwaredevelopers die dit systeem willen gaan maken.
Wij, vier derdejaarsstudenten, van de Technische Universiteit te Delft (TU Delft), willen en mogen
deze uitdaging voor het bachelor project aangaan. Het is belangrijk een duidelijk plan van aanpak te
hebben om goed te kunnen samenwerken en aan de eisen te voldoen van zowel de opdrachtgever
Infotron als de projectleiding van de TU Delft. Zowel de opdrachtgever als de TU coach als de
softwaredevelopers moeten het plan van aanpak goedkeuren. Als dit niet het geval is, dient de partij
aan te geven waarom het niet wordt goedgekeurd. Dan zullen de partijen rond de tafel gaan en zal
het plan mogelijk worden aangepast.
In het tweede hoofdstuk zal de projectopdracht worden uitgewerkt en omschreven. In hoofdstuk
drie wordt toegelicht welke stappen er worden genomen tijdens het project en zal er een
tijdsplanning worden gegeven. Het vierde hoofdstuk zal aangeven hoe de taken, rollen en
rapportering zijn georganiseerd. Ten slotte zal er in hoofdstuk vijf worden aangegeven wat de
kwaliteit zal waarborgen.
5
2. PROJECTOPDRACHT
Om helder te hebben wat de opdracht is waar de komende weken aan gewerkt gaat worden, wordt
dat hier verder gespecificeerd.
Projectomgeving
Spreadsheets worden veel gebruikt in allerlei industrieën: ze zijn het gereedschap voor financiële
analyse en domineren ook in andere domeinen, zoals logistiek en planning. De flexibiliteit en de
onmiddellijke feedback zorgen ervoor dat ze makkelijk te gebruiken zijn voor mensen zonder
programmeervaardigheden.
Veel organisaties hebben centraal personeel voor het consolideren van getallen in spreadsheets,
voor zowel financiële als andere doeleinden. Deze getallen komen van verschillende werknemers van
verschillende afdelingen binnen een organisatie. Vaak wordt er geklaagd over de kwaliteit van de
aangeleverde spreadsheets door het centrale personeel. Voorbeelden zijn onder andere: lege cellen,
veranderde formaten, verwijzingen naar niet-bestaande cellen, etc.
Een spreadsheet wordt vaak geschreven alsof er maar één persoon mee te maken gaat krijgen. Maar
in de praktijk blijkt ze gemiddeld gebruikt te worden door ruim 13 verschillende personen en voor
meer dan vijf jaar. Daarnaast ontbreekt bij ongeveer twee derde van alle spreadsheets een uitleg. Er
wordt ongeveer zeven miljard dollar op jaarbasis verspild als gevolg van incorrect gebruik van
spreadsheets.
Als alle problemen verholpen kunnen worden, worden veel bedrijven efficiënter en hoeven minder
geld te spenderen het later oplossen van fouten die door een spreadsheet veroorzaakt zijn.
Opdrachtformulering
De opdracht houdt in dat er een programma gemaakt dient te worden die veel van de beschreven
problemen probeert op te lossen. Het programma zal DeliverXL genoemd worden en streeft ernaar
om op een gebruiksvriendelijke manier zonder voorkennis regels op te geven waaraan een
spreadsheet dient te voldoen. Hierdoor weten mensen die de spreadsheet invullen gelijk of hun
spreadsheet adequaat is of niet en kunnen gelijk veranderingen aanbrengen. Hierbij zal in het vervolg
van dit verslag een niet ingevulde spreadsheet een (spreadsheet)template genoemd worden.
Er wordt van de projectgroep verwacht een werkende demo te kunnen geven binnen tien à elf
weken. Al het werk dat tijdens het project gedaan wordt, dient goed gedocumenteerd te worden,
zodat een ander team het programma verder kan ontwikkelen zodra ze de documentatie gelezen
hebben.
Op te leveren producten en diensten
Naast het te ontwikkelen product DeliverXL zijn er ook nog andere op te leveren producten. Daarvan
volgt hieronder een overzicht:
Plan van aanpak
Dit document is een verzameling afspraken waarin wordt vastgelegd wat het ‘probleem’ is dat
opgelost gaat worden in het project. Er wordt vastgelegd waaraan de opdrachtgever en de
6
projectleden moeten voldoen. Bovendien wordt beschreven hoe het project gefaseerd zal worden en
worden overige afspraken vastgelegd.
Onderzoeksrapport
Het onderzoeksrapport vat de resultaten van de onderzoeksfase samen. In dit rapport moeten de
keuzes bij de aanpak van het probleem verantwoord worden. Hierin worden ook alternatieve
oplossingen onderzocht en vergeleken. In dit document worden keuzes omtrent programmeertalen,
frameworks, software architectuur etc. gemotiveerd. Dit onderzoeksrapport dient ongeveer tien
pagina’s te bevatten.
SIG code
Gedurende het project zal tweemaal de code van het te leveren eindproduct DeliverXL opgestuurd
worden naar the Software Improvement Group (SIG). SIG zal de broncode beoordelen en van
feedback voorzien. De feedback op de eerste versie moet dan meegenomen worden bij de code voor
de tweede versie. Het eindverslag gaat verder in op deze feedback en wat er mee gedaan is.
Eindproduct: DeliverXL
Het resultaat van het project is een werkend programma genaamd DeliverXL. De opdrachtgever
verwacht dat hij dit product met niet al te veel aanpassingen op de markt kan brengen samen met
andere spreadsheet analyse tools. Eisen voor dit product worden hierna bij het kopje Eisen en
Beperkingen verder uitgewerkt.
Eindverslag
Het eindverslag wordt uitgelegd hoe het product tot stand gekomen is, en hoe het proces verlopen
is. Hierin wordt terug gegrepen op het onderzoeksrapport. Het verslag moet duidelijk maken wat er
gedurende traject geleerd is, en waarom het geleverde product een oplossing is voor het genoemde
probleem. Een ander team moet door het lezen van het eindverslag in staat zijn om het systeem te
gebruiken of op voort te bouwen. Dit eindverslag dient ongeveer 30-50 pagina’s te bevatten.
Eindpresentatie
In de eindpresentatie wordt het hele project gepresenteerd, vanaf de planning tot en met de
evaluatie. In deze presentatie wordt uitgelegd op welke manier het omschreven projectdoel is
bereikt en wordt een demonstratie van het eindproduct gegeven.
Eisen en beperkingen
Om nog specifieker vast te leggen waaraan het eindproduct moet voldoen, volgt hier een lijst van
eisen in de vorm van user stories, opgedeeld volgens de MoSCoW methode:
Must have
- Als een manager wil ik mijn bestaande spreadsheet template van voorwaarden voorzien.
Voorwaarden omvatten:
o Een cel is (niet) leeg.
o Een cel bevat (niet) een nummer tussen bepaalde waardes/een datum/tekst/een getal.
o Een cel bevat (g)een fout.
o Een cel bevat (g)een formule.
- Als een werknemer wil ik weten of een mijn ingeleverde spreadsheet voldoet aan de
voorwaarden die zijn opgesteld door de manager.
- Als een manager en als werknemer wil ik dat het systeem gebruiksvriendelijk is.
7
-
Als een manager wil ik mijn voorwaardensets kunnen wijzigen en verwijderen.
Als een werknemer wil ik feedback ontvangen wanneer de spreadsheet niet voldoet.
Als een manager wil ik een overzicht van alle spreadsheettemplates en de door de werknemer
ingeleverde spreadsheetbestanden hebben.
Als een manager, werknemer en als administrator wil ik kunnen inloggen op het systeem.
Als een manager wil ik voorwaardensets kunnen toewijzen aan werknemers.
Als een werknemer wil ik een overzicht hebben van alle toegewezen voorwaardensets.
Als een werknemer wil ik dat het systeem mij van de toegewezen templates voorziet.
Als een manager wil ik een overzicht hebben van alle correct ingeleverde bestanden.
Als een administrator wil ik een overzicht hebben van alle gebruikers.
Als een administrator wil ik gebruikers kunnen toevoegen, wijzigen en verwijderen.
Should have
- Als een manager wil ik mijn voorwaardenset met andere managers kunnen delen.
- Als een manager wil ik de overzichten van ingeleverde bestanden filteren.
- Als een manager wil ik voorwaarden opstellen voor reeksen van cellen.
- Als een manager wil ik voorwaarden opstellen op de gehele spreadsheet.
Could have
- Als een manager wil ik de template kunnen vervangen.
- Als een manager wil ik posities van voorwaarden op één of meerdere cellen kunnen verplaatsen.
Om duidelijk te hebben wat niet verwacht hoeft te worden van het te ontwikkelen systeem, volgt
hier een lijst van beperkingen:
- Het systeem werkt alleen met spreadsheets gemaakt in Microsoft Excel 2007 of nieuwer.
- Het systeem is een web-based applicatie.
8
3. AANPAK EN TIJDSPLANNING
Dit hoofdstuk bespreekt de fasering van het project, waarbij wordt aangegeven hoe de op te leveren
producten kunnen worden afgerond en aan de in hoofdstuk 2 gestelde eisen kan worden voldaan.
We hebben hiervoor het hele project opgesplitst in milestones; prototypes van het product waarbij
telkens nieuwe functionaliteit wordt toegevoegd. Door te starten met een eenvoudig prototype en
deze bij iedere milestone uit te breiden met meer functionaliteit, is er al vanaf het begin van de
ontwikkelfase een werkend product. Bovendien zijn de milestones een duidelijke afbakening van
subonderdelen van het product.
Milestones
Hieronder volgt een opsomming van de milestones. Merk op dat de genoemde functionaliteit niet
per definitie bindend is, maar in de beginfase van het project een goed idee geeft waar we naartoe
willen werken. Het is goed mogelijk dat in de loop van het project bepaalde ideeën over het product
veranderen, waardoor de functionaliteit mogelijk gewijzigd kan worden.
Milestone 1
- Webformulier met de mogelijkheid om een vastgesteld Excel bestand te uploaden. Dit
Excel bestand bevat enkel drie cellen: één met een naam, één met een leeftijd en één
met een geboortedatum.
- Uitlezen van het geüploade Excel bestand.
- Controleren van drie voorwaardes: cel is van het type tekst, getal of datum. Cellen die
gecontroleerd worden zijn hardcoded en komen overeen met het vastgestelde Excel
bestand.
- Weergave van het resultaat: OK of niet OK.
Milestone 2
- Webformulier waar meerdere voorwaarden kunnen worden opgeven (voorwaardenset).
Per voorwaarde wordt er een cel en het datatype (tekst, getal, datum) ingevuld.
- In het formulier kan ook een naam voor de voorwaardenset worden opgegeven.
- Bij het uploadformulier kan met een dropdown menu een voorwaardenset gekozen
worden om het Excel bestand mee te controleren.
Milestone 3
- Mogelijkheid om in te loggen als gebruiker. Gebruikers staan hardcoded opgeslagen in de
database; een gebruiker kan een manager en/of werknemer zijn. Een manager heeft
toegang tot het formulier waar voorwaarden kunnen worden opgegeven, een
werknemer heeft toegang tot het formulier om Excel bestanden te uploaden.
- Manager kan bij het maken van een voorwaardenset werknemers(s) selecteren.
- Manager kan bij het maken van een voorwaardenset andere manager(s) selecteren als
beheerder van die voorwaardenset.
- Dropdown menu bij het uploadformulier bevat alleen voorwaardensets die zijn
toegewezen aan de ingelogde werknemer.
Milestone 4
- Manager heeft een overzicht van alle correcte geüploade bestanden.
Milestone 5
9
-
Na het uploaden van een Excel bestand wordt er tekstuele feedback gegeven wanneer er
fouten in het bestand voorkomen.
- Meer verschillende voorwaarden kunnen aan cellen worden opgelegd:
o Leeg / niet leeg
o Bevat (g)een formule
o Bevat (g)een fout
o Getal / datum tussen bepaalde waardes
o Tekst bevat minimaal / maximaal aantal tekens
Milestone 6
- Manager kan bij het maken van een voorwaardenset de Excel template uploaden.
- Werknemer heeft een overzicht van alle aan hem toegewezen voorwaardensets en kan
hier de Excel template downloaden.
- Bij het uploaden van het Excel bestand wordt de daarbij horende voorwaardenset
automatisch geselecteerd (op basis van metadata).
Milestone 7
- Manager heeft een overzicht van al voorwaardensets die hij kan beheren.
- Manager kan voorwaardensets ook wijzigen en verwijderen. Bij het wijzigen van een
voorwaardenset kunnen de naam, de voorwaarden en de toegewezen managers en
werknemers van deze voorwaardenset worden aangepast.
Milestone 8
- De lijst met correct geüploade bestanden kan gefilterd worden (bijvoorbeeld op
voorwaardenset, datum, werknemer).
- De lijst met voorwaardensets van de manager wordt uitgebreid met een link naar de
gefilterde lijst met correct geüploade bestanden voor die voorwaardenset.
Milestone 9
- Nieuwe gebruikersrol ‘administrator’ wordt toegevoegd. Een administrator heeft een
overzicht van alle gebruikers.
- Gebruikers kunnen door de administrator beheerd worden (toegevoegd, aangepast en
verwijderd).
Milestone 10
- De manager kan in een gebruiksvriendelijke interface de voorwaarden invoeren.
Milestone 11
- Meer voorwaarden kunnen worden toegevoegd aan cellen, bijvoorbeeld:
o Voorwaardes kunnen ook geformuleerd worden als ‘bevat’. Bijvoorbeeld:
 Een cel bevat een getal.
 Een cel bevat tekst.
- Meer voorwaarden kunnen worden toegevoegd, die niet gebaseerd zijn op een enkele
cel. Bijvoorbeeld:
o De Excel template is niet aangepast (niet-lege cellen uit de Excel template zijn
dus hetzelfde als in het geüploade Excel bestand).
o Voorwaarden op een reeks cellen:
 Voor elke cel in een reeks geldt dezelfde voorwaarde.
 Voor een functie over de reeks geldt een voorwaarde (zoals som,
gemiddelde).
o Voorwaarden op de gehele spreadsheet:
10
o
 De spreadsheet bevat een minimum/maximum tabbladen.
 De spreadsheet bevat geen fouten.
Voorwaardes zijn generiek te formuleren door het invullen van een Excelformule,
die een boolean retourneert, bijvoorbeeld:
=EN(ISGETAL(A1); IS.ONEVEN(A1); GROTER.DAN(A1;100))
Tijdsplanning
Het project wordt onderverdeeld in een plannings-, onderzoeks-, implementatie- en afrondingsfase.
In de plannings-, onderzoeks- en afrondingsfase werken we vooral toe naar de in hoofdstuk 2
genoemde deliverables. Hieronder een overzicht van alle in te leveren deliverables met een
inleverdatum:
Deliverable
Planning
Geplande inleverdatum
Plan van aanpak (draft)
Eind week 1
24 april 2014
Plan van aanpak (final)
Eind week 1
25 april 2014
Onderzoeksrapport (draft)
Eind week 2
1 mei 2014
Onderzoeksrapport (final)
Begin week 3
7 mei 2014
Code evaluatie SIG 1
Eind week 8
13 juni 2014
Eindrapport (draft)
Week 9
18 juni 2014
Eindrapport (final)
Week 10
24 juni 2014
Code evaluatie SIG 2
Week 10
26 juni 2014
Eindproduct
Week 11
1 juli 2014
Eindpresentatie
Week 11
1 juli 2014
Tijdens de implementatiefase van het project willen we volgens de Scrum methode werken, waarbij
we iteraties van een week zullen gebruiken. Aan het begin van iedere week maken we een lijst van
taken uit bovenstaande milestones die we aan het einde van de week voltooid willen hebben.
Uiteraard is er in de loop van het ontwikkeltraject ruimte voor terugkoppeling van de opdrachtgever
en de TU coach. Daarvoor hebben we bij voorkeur elke week een afspraak met de opdrachtgever en
de TU coach.
Hieronder een inschatting hoeveel tijd we voor bovenstaande milestones verwachten nodig te
hebben, met daarbij een indicatie wanneer deze milestones afgerond zijn. Merk op dat dit schema
uiteraard in de loop van het ontwikkeltraject kan veranderen, aangezien we gekozen hebben voor
een Scrum aanpak.
Sprint Milestone Planning
Geplande einddatum
1
1
Eind week 3
9 mei 2014
2
2, 3
Eind week 4
16 mei 2014
3
4, 5
Eind week 5
23 mei 2014
4
6, 7, 8
Eind week 7
6 juni 2014
5
9, 10
Eind week 8
13 juni 2014
6
11
Eind week 9
20 juni 2014
11
4. PROJECTINRICHTING
Voor de inrichting van het project hebben we puntsgewijs al enkele afspraken gemaakt. Voor de
organisatie gaat het om de volgende afspraken:
-
Johnny is contactpersoon voor de twee bedrijven die interesse getoond hebben voor het te
maken product: accountantskantoor Dijksterhuis en het Scheepvaartmuseum.
Willem-Jan is verantwoordelijk voor het overige mailcontact. Hieronder valt het contact met
Mateo Mol en Bas Jansen.
Koos is verantwoordelijk voor het bijhouden van de teamwork taken en milestones. Ieder
werkt zijn eigen taken bij.
Ruben is verantwoordelijk voor het notuleren van externe gesprekken.
Willem-Jan is verantwoordelijk voor het inleveren van de code bij SIG.
Koos is verantwoordelijk voor het inleveren van verslagen.
Johnny is verantwoordelijk voor het regelen van een werkplek.
Voor de administratie en rapportering gaat het om de volgende afspraken:
-
Met behulp van het programma Teamwork (teamwork.com) worden takenlijsten, milestones
etc. bijgehouden. Ook kan via dit programma gecommuniceerd worden.
Tijdens vergaderingen wordt er genotuleerd.
Tijdens de implementatiemethode wordt er aan het begin van een milestone vergaderd.
Aanpassingen in dit plan van aanpak worden schriftelijk gedeeld met de opdrachtgever
Mateo Mol en met de TU coach Bas Jansen.
12
5. KWALITEITSBORGING
Een goede kwaliteit van code en documentatie is nodig voor dit project, omdat de code mogelijk gaat
worden gebruikt door andere ontwikkelaars. De code en documentatie moeten dus begrijpelijk en
makkelijk uit te breiden zijn. Ook moet het programma betrouwbaar zijn en aan de gestelde eisen
voldoen. Om deze doelen te behalen zijn er een aantal regels en afspraken gemaakt omtrent de
kwaliteitsborging.
Afspraken TU coach, opdrachtgever en interne meetings
Zowel met de TU coach als met de opdrachtgever wordt er regelmatig gesproken over het werk dat is
gedaan, het product, het proces en de vooruitblik naar het vervolg van het project. Bij voorkeur
vinden deze gesprekken één keer per week plaats. Ook zal er minimaal één keer per week een
interne meeting zijn. Er kunnen daarnaast ook extra meetings zijn.
Testen
Het testen van het systeem is belangrijk om de kwaliteit van de code te waarborgen. Daarom is
ervoor gekozen iedere iteratie testen uit te voeren. Er zal op verschillende manieren worden getest.
Mogelijke manieren van testen zijn unittests en gebruikerstests. Ook zal het systeem vaak door de
projectleden getest worden door het systeem te draaien en de mogelijkheden uit te proberen.
Stijl en commentaar
Om de code overzichtelijk te houden zullen de software ontwikkelaars dezelfde programmeerstijl
trachten te gebruiken. De standaard programmeerstijl behorende bij een programmeertaal zal
worden gehanteerd tenzij anders is afgesproken. Ook wordt gebruik gemaakt van commentaar bij de
code voor de huidige programmeurs maar ook voor de mogelijke doorontwikkelaar.
Pair programming
In sommige gevallen, zoals het schrijven van moeilijke stukken programma, is er een voorkeur om te
programmeren in paren. Dit is uit ervaring een goede manier gebleken om kwaliteit te waarborgen.
Bij problemen kan er direct worden ingesprongen door de tweede persoon en er vindt snel controle
van code en commentaar plaats. Echter bij simpele stukken code zal er alleen worden
geprogrammeerd en waarbij nodig samenwerking plaatsvindt met één of meerdere teamleden.
Versiebeheersysteem en features
Het versiebeheersysteem dat gebruikt gaat worden is Git. Met dit systeem is het mogelijk aanpassing
te zien en ongedaan te maken. Er kan via berichten commentaar worden gegeven op of vragen
worden gesteld over stukken code. Als er nieuwe features aan het systeem worden toegevoegd
dienen deze features in een nieuwe branch te worden gemaakt. Een branch is een tak die
afzonderlijk is vanaf het hoofdprogramma. Als de code is goed gekeurd, getest en werkend is
bevonden dan mag de branch worden samengevoegd met de hoofdbranch.
13
BIJLAGE C
ONDERZOEKSRAPPORT
DeliverXL - onderzoeksrapport
Projectgroep:
Willem-Jan Meerkerk
Ruben Vroegindeweij
Johnny Verhoeff
Koos van der Linden
Met begeleiding van:
Opdrachtgever: Mateo Mol
TU Coach: Bas Jansen
Project coördinator: Felienne Hermans
Project coördinator: Martha Larson
TU Delft, 7-5-2014
SAMENVATTING
Voordat we daadwerkelijk starten met het ontwikkelen van DeliverXL hebben we eerst onderzoek
gedaan met betrekking tot het domein, het te ontwikkelen systeem en het ontwikkelproces. Dit
onderzoek heeft ons meer inzicht gegeven in de context van het probleem en heeft ons daarbij ook
gestimuleerd om goed na te denken over het systeem dat we willen ontwikkelen. Uit dit onderzoek
zijn concrete keuzes voortgekomen die goed zijn overwogen en vergeleken met alternatieven.
Uiteindelijk is iedere gemotiveerde keuze een argument waarom onze aanpak tot de optimale
oplossing voor DeliverXL moet leiden.
Uit de domeinanalyse is gebleken dat bedrijven bijzonder veel problemen ervaren met spreadsheets.
Er zijn huidige oplossingen voor dit probleem, bijvoorbeeld de data validatie in Microsoft Excel. Toch
is DeliverXL uniek omdat het een web applicatie is, meer mogelijkheden biedt, gericht is op meerdere
gebruikers in een bedrijf en expliciet feedback geeft op het ingeleverde Excel bestand.
Er is gekozen om DeliverXL te ontwikkelen als web applicatie omdat het hierdoor geschikt is voor
meerdere gebruikers op alle platformen. Als API voor het uitlezen van Excel bestanden hebben we
gekozen voor Gembox, vanwege uitgebreide functionaliteit en belang vanuit het bedrijf Infotron.
DeliverXL zal worden geprogrammeerd in C#, in combinatie met het ASP.NET framework voor web
applicaties. Daarnaast wordt gebruik gemaakt van een Microsoft SQL Server Express 2014 database,
wat een logische keuze is in combinatie met C# en de ontwikkelomgeving Visual Studio 2013. De
code zal gestructureerd worden volgens het Model View Control (MVC) patroon, omdat hierdoor de
software architectuur overzichtelijk blijft en het systeem goed getest kan worden. Als test framework
is gekozen om NUnit te gebruiken voor de unit tests en Selenium voor de acceptance tests. Een
geschikte manier om een Excel interface in een web applicatie te tonen is jQuery.Sheet, wat we
willen gebruiken om de voorwaarden voor een Excel bestand op een gebruikersvriendelijke manier
te kunnen opgeven.
Wat betreft het ontwikkelproces is er gekeken naar een geschikte ontwikkelmethode en het
versiebeheer. Uiteindelijk zullen we een combinatie van het incremental build model en Scrum
toepassen tijdens de ontwikkelfase van ons project, omdat dit een gestructureerde maar toch
flexibele aanpak is. Als versiebeheer wordt een repository voor DeliverXL op Github gebruikt.
2
INHOUD
Samenvatting........................................................................................................................................... 2
Voorwoord .............................................................................................................................................. 4
1. Inleiding ............................................................................................................................................... 5
2. Domeinanalyse .................................................................................................................................... 6
2.1 Huidige problemen met Excel sheets ............................................................................................ 6
2.2 Gerelateerd werk........................................................................................................................... 6
2.3 Unieke functionaliteit van DeliverXL ............................................................................................. 8
3. Systeem ............................................................................................................................................. 10
3.1 Soort applicatie............................................................................................................................ 10
3.2 API voor het uitlezen van een Excel bestand .............................................................................. 10
3.3 Programmertaal .......................................................................................................................... 11
3.4 Dataopslag ................................................................................................................................... 12
3.5 Programmastructuur ................................................................................................................... 13
3.6 API voor het weergeven van een Excel interface ........................................................................ 14
3.7 Testmethodes .............................................................................................................................. 15
4. Ontwikkelproces ................................................................................................................................ 16
4.1 Ontwikkelmethode ...................................................................................................................... 16
4.2 Versiebeheer ............................................................................................................................... 18
Referenties ............................................................................................................................................ 19
3
VOORWOORD
Het is belangrijk alvorens er gewerkt gaat worden aan het product DeliverXL voor Infotron,
onderzocht te hebben hoe het product het beste gemaakt kan worden. Daarom is aan de
ontwikkelfase van het product een onderzoeksfase voorafgegaan. In dit onderzoeksrapport worden
de belangrijkste conclusies van dit onderzoek vermeldt en toegelicht. De ontwikkeling van deze
applicatie en van dit onderzoek vindt plaats in het kader van ons bachelor eindproject aan de TU
Delft onder begeleiding van de firma Infotron.
4
1. INLEIDING
Spreadsheets worden veel gebruikt in allerlei industrieën. Ze zijn het gereedschap voor financiële
analyse en domineren ook in andere domeinen, zoals logistiek en planning. De flexibiliteit en de
onmiddellijke feedback zorgen ervoor dat ze makkelijk te gebruiken zijn voor mensen zonder
programmeervaardigheden. De manier waarop mensen spreadsheets invullen en onderhouden, laat
vaak te wensen over. Er zitten vaak fouten in gecompliceerde spreadsheets, zoals lege cellen,
veranderde formaten, verwijzingen naar niet-bestaande cellen, et cetera.
Een spreadsheet wordt vaak geschreven alsof er maar één persoon mee te maken gaat krijgen. Maar
in de praktijk blijkt ze gemiddeld gebruikt te worden door ruim 13 verschillende personen en voor
meer dan vijf jaar. Daarnaast ontbreekt bij ongeveer twee derde van alle spreadsheets een uitleg. Er
wordt ongeveer zeven miljard dollar op jaarbasis verspild als gevolg van incorrect gebruik van
spreadsheets [1]. Als alle problemen verholpen kunnen worden, worden veel bedrijven efficiënter en
hoeven minder geld te spenderen aan het later oplossen van fouten die door een spreadsheet
veroorzaakt zijn.
Het doel van het te leveren product, DeliverXL, is om op een gebruiksvriendelijke manier zonder
technische voorkennis regels op te geven waaraan een spreadsheet dient te voldoen. Hierdoor
weten mensen die de spreadsheet invullen gelijk of hun spreadsheet adequaat is of niet en kunnen
gelijk veranderingen aanbrengen.
In dit onderzoeksrapport is onderzocht of er al andere programma’s bestaan die kunnen helpen bij
het beter invullen van spreadsheets en waarom DeliverXL zich hiervan onderscheidt. Verder wordt in
dit rapport beschreven welke overwegingen gemaakt zijn op het gebied van de gebruikersinterface,
in welke programmeeromgeving(en) gewerkt gaat worden, welke database gebruikt gaat worden,
hoe er getest zal worden en alternatieve oplossingen. Als laatste zal het onderzoek van het
ontwikkelproces besproken worden, hierbij is gedacht aan methode om software te maken, welk
versiebeheersysteem gebruikt wordt en hoe de documentatie bijgehouden wordt.
5
2. DOMEINANALYSE
Het probleem waarvoor DeliverXL zal worden ontwikkeld is: ‘het incorrect en onvolledig invullen van
spreadsheets’. Om te garanderen dat DeliverXL toegevoegde waarde zal hebben, is het is belangrijk
een goed beeld te hebben van het domein van dit probleem. Hierbij zullen we kijken naar
specificaties van het probleem, mogelijke huidige oplossingen en de functies die DeliverXL uniek
maken. In dit hoofdstuk worden de uitkomsten van het onderzoek beschreven.
2.1 Huidige problemen met Excel sheets
Na het schrijven van een spreadsheet wordt er vanuit gegaan dat de spreadsheet correct is. Uit
onderzoek blijkt echter dat 86% van de onderzochte spreadsheets incorrect is [2]. De fouten die
worden gemaakt in spreadsheets kunnen op een aantal manieren worden onderverdeeld. De
volgende onderscheidingen worden gemaakt door Panko [3]:
Kwantitatieve en kwalitatieve fouten
Incorrectheden kunnen worden onderverdeeld in kwantitatieve fouten en kwalitatieve fouten. Een
kwantitatieve fout zorgt voor een fout bij minstens één variabele op de onderste regel. Kwalitatieve
incorrectheden hebben te maken met een zwak spreadsheetontwerp die voor latere problemen
kunnen zorgen zoals foute aanpassingen.
Mechanische, weglatings- en logicafouten
De kwantitatieve fouten kunnen ook worden onderverdeeld in een aantal groepen namelijk
mechanische, weglatings-, en logicafouten. Mechanische fouten zijn simpele fouten zoals een
typefout en een nummer of punt in de verkeerde cel zetten door een enter bij de invoer van een
formule. Het weglaten van iets dat in het model moet zitten behoort tot de weglatingsfouten. Het
model is zodoende niet volledig en dit kan invloed hebben op interpretatie van de data. Logicafouten
komen voor bij het gebruiken van het verkeerde algoritme tijdens het maken van een formule. Ook
het verkeerd overzetten van zo’n algoritme behoort tot deze fouten.
Life cycle fouten
Het system van de spreadsheet heeft daarnaast ook een life cycle van soms meer dan vijf jaar en
wordt soms door meer dan dertien personen onderhouden. Hieronder vallen de processen zoals
analyse, ontwerpen, invullen, testen et cetera. Eén of meerdere fouten kunnen in elk van deze stadia
van de cycle voorkomen. Ook na de ontwikkeling kunnen zich nieuwe fouten voordoen in de
spreadsheet zolang de spreadsheet gebruikt wordt.
2.2 Gerelateerd werk
Nu bestaat de vraag: ‘bestaan er gerelateerde werken of huidige oplossingen voor het probleem
waar DeliverXL een oplossing voor moet bieden?’. Als dit zo is dan moet er worden nagedacht of
DeliverXL unieke functionaliteit bevat en unieke onderdelen heeft vergeleken met deze oplossingen
en dus een toegevoegde waarde heeft op de huidige markt. Uit het onderzoek blijkt dat vergelijkbare
systemen schaars zijn. Daarnaast zijn er ook een aantal systemen die oplossingen kunnen berekenen
aan de hand van opgestelde voorwaarden in plaats van checken of een spreadsheet aan bepaalde
voorwaarden voldoet.
6
Microsoft Excel
Excel heeft vergelijkbare functionaliteit aan de service die DeliverXL gaat bieden. Dit programma
heeft namelijk zelf ook de mogelijkheid om voorwaarden op te stellen. Dit kan via de tab ‘Gegevens’
in het vak ‘Hulpmiddelen voor gegevens’. Er kan bijvoorbeeld worden opgegeven welke type de
invoer van een cel moet zijn en bijvoorbeeld tussen welke waarden de invoer van de cel mag liggen.
Dit kan worden aangegeven in het scherm van gegevens validatie zoals wordt weergegeven in Figuur
1.
Figuur 1 - Screenshot invoerscherm gegevensvalidatie van Microsoft Excel 2010
Ook kan er een beschrijving worden meegeven en kunnen er meerdere soorten meldingen worden
ingesteld wat in Figuur 2te zien is. De voorwaarden van Microsoft Excel zijn ter validatie van de
invoer van de cellen.
Figuur 2 - Screenshot invoerbericht en foutmelding van Microsoft Excel
7
Plug-ins en andere systemen
DeliverXL gaat spreadsheets valideren op een opgestelde set voorwaarden. Zoals eerder is vermeld
zijn vergelijkbare systemen met DeliverXL schaars. Er zijn meerdere systemen die in plaats van
spreadsheets valideren op voorwaarden spreadsheets invullen op basis van een aantal voorwaarden.
Dit is dus niet dezelfde functionaliteit als DeliverXL zal aanbieden, maar is wel gerelateerd. Een
voorbeeld van zo’n systeem die is onderzocht is NExSched [4]. NExSched is een plug-in voor
Microsoft Excel voor het oplossen van een aantal voorwaarden. De gebruiker kan voorwaarden
invoeren doormiddel van een aantal knoppen. Dit systeem is gebruiksvriendelijk, omdat er weinig
moeite moet worden gedaan om een groot aantal voorwaarden te stellen en doordat deze
voorwaarden doormiddel van de front-end van Microsoft Excel kunnen worden geformuleerd. De
visuele interface van de tool NExSched is dus gelijk aan die van Microsoft Excel op het nieuwe menu
item ‘Solve Constraints’ na zoals is te zien in Figuur 3.
Figuur 3 - Screenshot Microsoft Excel met NExSched plug-in overgenomen uit [4]
Ook gerelateerde werken worden genoemd waaronder XcelLog en PredCalc die als meest prominent
worden genoemd [4]. Deze programma’s zijn gericht op het maken van een oplossing naar aanleiding
van invoer/set voorwaarden. Een ander voorbeeld van een gerelateerd programma is het CsSolver
systeem [5]. Het maakt voorwaarden doormiddel van een taal die standaard rekenkundige,
relationele en logische operatoren ondersteund. Wat DeliverXL uniek maakt ten opzichte van deze
tools, systemen en vooral van de bestaande functionaliteit van Excel zal in het volgende gedeelte
worden beschreven. De functionaliteit van Microsoft Excel ligt duidelijk dichter bij DeliverXL dan
NExSched en CsSolver, omdat DeliverXL en Microsoft Excel zich bezig houdt met de verificatie van
invoer door opgestelde voorwaarden en niet met het generen van een oplossing die voldoet aan
opgestelde voorwaarden. In het volgende hoofdstuk zal duidelijk worden gemaakt wat DeliverXL
uniek maakt.
2.3 Unieke functionaliteit van DeliverXL
DeliverXL is in staat om onder andere mechanische- en weglatingsfouten op te lossen. DeliverXL
verifieert de invulling van een spreadsheet en onderscheidt zich zo van de systemen die een
oplossing generen voor een bepaald probleem.
Daarnaast is DeliverXL een web applicatie (zie hoofdstuk 3.1), wat een groot voordeel is van dit
systeem. Gebruikers kunnen doormiddel van het systeem elkaar van de benodigde documenten
voorzien. Het systeem bevat een documentenbeheer zodat iedere gebruiker de voor hem/haar
bedoelde documenten te zien kan krijgen.
8
Ook zal DeliverXL een gebruiksvriendelijke interface bevatten die de gebruiker zo min mogelijk het
idee geeft dat hij/zij als programmeur te werk gaat. Veel gebruikers van het systeem hebben
namelijk geen of weinig ervaring met programmeren en soms zelfs ook weinig ervaring met
Microsoft Excel. DeliverXL moet ook voor deze gebruiker intuïtief en makkelijk te gebruiken zijn.
Het systeem zal de gebruiker van feedback kunnen voorzien. Hierdoor kan de gebruiker in één
oogopslag de verbeterpunten voor zijn ingevulde Excel sheet zien en hierdoor eenvoudig eventuele
fouten verbeteren. Dit is een stuk makkelijker dan dat de gebruiker zelf alle gegevens moet
controleren of ze aan de voorwaarden voldoen.
Tenslotte zal het systeem uitgebreide en complexe voorwaarden kunnen stellen aan een
spreadsheet. Het is bekend dat doormiddel van Microsoft Excel voorwaarden kunnen worden
opgesteld. Hier zitten echter beperkingen aan, zoals het op kunnen stellen van maar één
voorwaarderegel per cel en het op kunnen stellen van voorwaarden over reeksen van cellen. Ook
vult DeliverXL de mogelijkheden van Excel aan en waarborgt de gebruiksvriendelijkheid ook bij de
bestaande functionaliteiten van Microsoft Excel.
9
3. SYSTEEM
Tijdens het onderzoek is onderzocht hoe het systeem DeliverXL gebouwd zal worden. In dit
hoofdstuk zal aan de orde komen welke keuzes gemaakt zijn over de bouw van het systeem en
waarom die keuzes gemaakt zijn.
3.1 Soort applicatie
Er zijn verschillende mogelijkheden welk soort applicatie DeliverXL uiteindelijk gaat worden.
Allereerst is het mogelijk om DeliverXL als standalone applicatie te ontwikkelen, waardoor het dus
simpelweg op een lokale computer zou worden uitgevoerd. Maar deze optie beperkt zich tot één
computer, terwijl DeliverXL juist makkelijk door meerdere gebruikers moet kunnen worden gebruikt.
Een andere mogelijkheid is het maken van een plug-in voor Excel. Zo’n plugin is wel makkelijk te
distribueren over meerdere computers, maar dit kost extra tijd en moeite om te beheren. Bovendien
moet DeliverXL dan ondersteuning bieden aan meerdere platformen (Windows, Mac, Linux) of
meerdere versies van Excel, wat ook extra moeite kost bij het ontwikkelen.
Daarom de keuze om DeliverXL als web applicatie te ontwikkelen. Hierdoor bieden we niet alleen
makkelijk ondersteuning via de browser aan alle platformen, maar is het systeem ook makkelijk
bereikbaar voor meerdere gebruikers (managers en werknemers). Er is een breed scala aan
programmeertalen, frameworks en libraries die geschikt zijn voor het ontwikkelen van web
applicaties. Hierdoor kunnen we nog voldoende verder onderzoek doen en ons toespitsen op de
optimale keuze voor DeliverXL.
3.2 API voor het uitlezen van een Excel bestand
Omdat een groot deel van de functionaliteit van DeliverXL afhangt van het uitlezen van Excel sheets,
is het een logische keuze om eerst onderzoek te doen naar welke mogelijkheden hier allemaal voor
zijn. We hebben al vastgesteld dat DeliverXL een web applicatie moet worden, maar dan alsnog zijn
er veel API’s en manieren om Excel sheets uit te lezen, in verschillende programmeertalen. Daarom
zullen we ons onderzoek in eerste instantie richten op drie veelgebruikte manieren om Excel sheets
uit te lezen.
Excel Object Model
Microsoft biedt zelf de mogelijkheid om te interacteren met Microsoft Excel via het Excel Object
Model1, wat ondersteuning biedt voor C# en Visual Basic via de COM interop interface. Hiermee is
het mogelijk om gebruik te maken van objecten uit Excel, zoals Application, Workbook, Worksheet
en Range. Deze objecten zijn gemaakt om Excel te besturen vanuit een ander programma. Voor het
uitlezen van een Excel sheet komt het er dus op neer dat Microsoft Excel zelf in de achtergrond
wordt geopend, waarna via de objecten acties kunnen worden uitgevoerd (zoals het openen van een
tabblad en uitlezen van celwaarden). Dit vereist echter dat Microsoft Excel is geïnstalleerd op de
computer/server waar DeliverXL wordt uitgevoerd, wat een beperking is voor ons systeem; het
wordt op die manier teveel afhankelijk van Microsoft Excel. Daarnaast is het erg inefficiënt om op
deze manier gegevens uit te lezen uit een Excel sheet, omdat hier heel Microsoft Excel niet voor
nodig is en gestart hoeft te worden.
1
http://msdn.microsoft.com/en-us/library/wss56bz7.aspx
10
We zijn simpelweg op zoek naar een manier om efficiënt de data uit een Excel bestand te lezen
zonder dat hier een volledig programma zoals Microsoft Excel voor nodig is.
Andere mogelijkheden
Uit verder onderzoek is gebleken dat er veel goede API’s zijn voor verschillende programmeertalen.
Een aantal voorbeelden zijn PHPExcel (PHP), Apache POI (Java), LibXL (C++) en Gembox (C# en VB). Al
deze API’s zijn in staat om Excel bestanden uit te lezen, waarna de gegevens uit de Excel sheet direct
kunnen worden opgevraagd (uit het geheugen). Hierbij bieden de API’s veel functionaliteit, zoals het
uitlezen van eigenschappen, tabbladen, rijen, kolommen, cellen en opmaak, maar ook data validatie
(per cel), het evalueren van formules en nog veel meer. In ieder geval zijn dit meer dan voldoende
mogelijkheden die we voor DeliverXL nodig hebben, dus in feite zouden we elk van deze API’s
kunnen gebruiken.
Gembox
Uiteindelijk moet er toch een keuze gemaakt worden, en het lijkt ons het beste om gebruik te maken
van Gembox2. Dit is namelijk een professionele oplossing, en het bedrijf (Infotron) heeft al een
licentie voor Gembox omdat het voor andere applicaties wordt gebruikt. Aangezien gebleken is dat
Gembox minimaal alle functionaliteit heeft die de alternatieve API’s ook hebben, is het een logische
keuze om Gembox te gebruiken.
Uiteindelijk zijn we met een oplossing als Gembox niet meer afhankelijk van Microsoft Excel; Gembox
blijkt bovendien veel efficiënter te zijn. Daarnaast heeft Gembox uitgebreide documentatie en
voorbeelden, zodat het gebruik ervan makkelijk is. De programming interface van Gembox is zo
gemaakt dat naast Excel bestanden ook andere formaten worden ondersteund (zoals ODS, CSV,
HTML, PDF en XPS). Dit maakt DeliverXL op dit niveau ook geschikt voor eventuele uitbreiding naar
andere bestandsformaten.
3.3 Programmeertaal
Zoals hiervoor al vastgesteld is, zal DeliverXL als webapplicatie ontwikkeld worden. Als men een
programma voor de browser schrijft, denkt men in eerste instantie aan PHP. PHP wordt door circa
82% van de websites gebruikt3, op het moment van schrijven. In PHP kan men ook object
georiënteerd programmeren en er is een goede Excel API voor beschikbaar, namelijk PHPExcel, zoals
in de vorige paragraaf behandeld is. Bovendien zijn PHP en PHP Excel gratis om te gebruiken en gratis
om te distribueren.
Een andere mogelijkheid om een programma te schrijven dat in de browser gebruikt wordt, is via het
ASP.NET framework. Voor de .NET omgeving is ook een goede Excel API geschreven namelijk
GemBox. Omdat DeliverXL moet werken in de browser kunnen we in de .NET omgeving kiezen voor
twee talen, namelijk: Visual C# en Visual Basic. Op één teamlid na heeft niemand ervaring met Visual
Basic. Daarentegen heeft iedereen ervaring met Visual C#, daardoor zou de voorkeur hierin dus gaan
naar Visual C#.
Als ontwikkeling omgeving heeft Microsoft de Integrated Development Environment (IDE) genaamd
Visual Studio. Hier is ook een open source alternatief voor genaamd Mono, ontwikkeld door Xamarin.
Deze IDE maakt het mogelijk om op een Mac of Linux machine ook in de .NET omgeving te werken.
2
3
http://www.gemboxsoftware.com/spreadsheet/overview
http://w3techs.com/technologies/details/pl-php/all/all
11
De keuze is dus tussen PHP of ASP.NET. Voor het team was de knoop moeilijk door te hakken. Beide
omgevingen bieden voordelen. De knoop is uiteindelijk door gehakt door onze opdrachtgever,
Infotron. Zoals in de vorige paragraaf al was gezegd, heeft Infotron een licentie voor GemBox.
Vanwege de voorkeur voor GemBox, viel ook de voorkeur voor de ASP.NET omgeving. Ook heeft
onze opdrachtgever al diverse andere programma’s zoals PerfectXL die gebruik maken van de .NET
programmeeromgeving en geprogrammeerd zijn in Visual C#. Vanwege deze reden, en de ervaring in
C# ten opzichte van Visual Basic is dus uiteindelijk gekozen voor C# met Visual Studio 2013.
3.4 Dataopslag
Voor DeliverXL zijn verschillende vormen van data te noemen die opgeslagen dienen te worden. Van
te voren te onderscheiden zijn in ieder geval:
-
Template Excel bestanden samengesteld door de manager
Excelbestanden die ingevuld zijn door de werknemer en goedgekeurd door het systeem
Voorwaardensets op een template Excel bestand
Gebruikersgegevens
De template Excel bestanden en de ingevulde Excel bestanden zullen in ieder geval als bestanden
opgeslagen moeten worden op een server, omdat het systeem webbased zal draaien.
Voor de overige data (waaronder de verwijzingen naar de opgeslagen bestanden) is gekozen om
gebruik te maken van een database als dataopslag. Hiervoor zijn een aantal redenen. Allereerst is de
data die het systeem zal opslaan geschikt om in een database op geslagen te worden. Hier gelden de
algemene voordelen van een database ten opzichte van een filesysteem. Een database is sneller,
geavanceerder en geschikter om te indexeren. Met een database kan door relaties en constraints op
te geven ook op een makkelijke manier beveiliging ingebouwd worden die de validiteit van de data
verzekerd.
In navolging van de keuze voor C# en Visual Studio is ook gekozen voor Microsoft SQL Server Express
2014. Er is gekeken naar alternatieven zoals MySQL, SQLLite, PostgreSQL, maar voor deze is
uiteindelijk niet gekozen. Ten eerste biedt Visual Studio uitgebreide ondersteuning voor integratie
van Microsoft SQL Server Express, meer dan voor de genoemde alternatieven. Verder speelde mee
dat Infotron voor het systeem PerfectXL al Microsoft SQL Server Express gebruikt. Het systeem maakt
gebruik van een lokaal databasebestand.
Voor tijdens de ontwikkelfase is gekozen om niet een lokaal databasebestand te gebruiken (dat wil
zeggen een database die op het zelfde systeem uitgevoerd wordt als de webapplicatie). In plaats
daarvan is gekozen om de database op een server uit te voeren. Dit heeft als voordeel dat er door
het ontwikkelteam elk met dezelfde database gewerkt worden. Deze database zal later zonder veel
moeite op dezelfde server uitgevoerd kunnen worden als de webapplicatie.
Ook is er gekozen om met het Entity Framework4 te werken. Dit framework maakt het mogelijk dat je
met relationele databases kan werken door objecten in het domein zelf te gebruiken. Bij het gebruik
van Entity Framework is er keuze tussen Code First te gebruiken of Database First. Er is gekozen om
Code First te gebruiken. De belangrijkste reden hiervoor is dat het andere alternatief niet een
makkelijke mogelijkheid biedt om veranderingen op de database toe te passen met behoud van data.
4
http://msdn.microsoft.com/en-us/data/ef.aspx
12
Bij Code First hoeft er (vrijwel) geen rekening met de database gehouden te worden, doordat het
opgestelde model in de code automatisch gemapt wordt naar het databasemodel.
3.5 Programmastructuur
Voor de structuur van een programma dat in de .NET omgeving geschreven is zijn de volgende
modellen beschikbaar: Model View Controller (zie Figuur 4) en het Event Driven Model (zie Figuur 5).
Beide modellen kunnen worden gebruikt in Visual C#. Het Event Driven Model wordt traditioneel
gebruikt voor het bouwen van webpagina’s in ASP.NET.
Het heeft echter een aantal nadelen: Er is geen vaste project architectuur gedefinieerd, hierdoor kan
de code snel slordig worden en unit testen wordt door het Event Driven Model bijna onmogelijk
gemaakt, terwijl goed testen voor elk project belangrijk is.
Figuur 4 - Event driven model
In een programma die het model van de Model View Controller (MVC) gebruikt, is de View de
Graphical User Interface (GUI), waar in het geval van DeliverXL de HTML, CSS en Javascript zit. De
Controller verwerkt handelingen die meestal het gevolg zijn van de gebruiker. Het Model
representeert de informatie waarmee het programma werkt.
MVC heeft als nadeel dat het wat omslachtig kan zijn om iets aan te passen, want dat moet vaak
gebeuren in de view, model en controller. Het heeft veel voordelen ten opzichte van het Event
Driven Model: Het model heeft een duidelijk gedefinieerde project architectuur, dit zorgt ervoor dat
het minder snel complex wordt om te begrijpen hoe alles in elkaar zit. MVC leent zich uitstekend
voor testen, want het model, de view en controller kunnen alle drie apart van elkaar getest worden.
Met MVC kan ook gemakkelijk met een team samengewerkt worden binnen één project: de view,
model en controller kunnen alle drie los van elkaar bewerkt worden. Nog een voordeel is dat de MVC
structuur buitengewoon goed ondersteund wordt door Visual Studio, met onder andere het
aanmaken van nieuwe views, models en controllers.
13
Figuur 5 - Model View Controller model
Door deze factoren is Model View Controller gekozen voor het structuur van DeliverXL.
3.6 API voor het weergeven van een Excel interface
Omdat het doel is een gebruiksvriendelijke interface te bieden voor het opzetten van voorwaarden
voor een Excel sheet, is er gezocht naar een library die ondersteuning biedt voor het weergeven van
een Excel sheet in een webinterface. Door de Excel sheet zelf weer te geven, is het voor de gebruiker
(in dit geval de manager) mogelijk om met een visuele omgeving te werken in plaats van alleen maar
met tekst en webforms. Een idee is bijvoorbeeld dat de gebruiker een cel kan selecteren om
vervolgens via een menu of button aan die cel (of aan een groep cellen) een voorwaarde toe te
voegen.
Er bleek een groot aantal mogelijkheden te bestaan om dit aan te pakken. Het aantal hiervan is te
groot om hier allemaal te behandelen; we zullen slechts de 3 meest belovende libraries bespreken.
De eerste is Excel Mashup5, van Microsoft. Deze API biedt bijna alles wat je maar kan wensen voor
het weergeven van een Excel bestand in een webomgeving. De keuze was al bijna gemaakt toen er
één groot en definitief nadeel gevonden werd. Mashup vereist dat een Excel bestand als publiek
bestand beschikbaar is op OneDrive (Microsofts online dataopslag). Dit vereist dus dat een bestand
publiek gemaakt wordt en op een externe server wordt opgeslagen; daardoor valt deze optie af.
De tweede optie is Handsontable6. Handsontable is een relatief simpele API. Het neemt als invoer
een door komma’s gescheiden tabel en maakt daar een weergave van die lijkt op de Excel weergave.
Deze API biedt vrijwel alles wat nodig is voor DeliverXL. Er is de mogelijkheid om een sheet weer te
geven, cellen kunnen hierin geselecteerd worden, er kunnen opmaak opties opgegeven worden,
enzovoort. Functionaliteit die mist is onder andere het weergeven van meerdere tabbladen, het
evalueren van formules en het weergeven van samengevoegde cellen. Omdat de API relatief simpel
is, zou deze hoogstwaarschijnlijk makkelijk uit te breiden of aan te passen zijn.
De derde optie die hier genoemd wordt is jQuery.Sheet7. jQuery.Sheet biedt een hele reeks aan
mogelijkheden om tabellen weer te geven en te bewerken. Een groot voordeel van jQuery.Sheet is
de mogelijkheid om de tabeldata als JSON of XML data te importeren. Verder is het in staat om een
groot aantal formules correct weer te geven en kunnen er meerdere tabbladen worden weergeven.
Het enige minpunt is de mate waarin het mogelijk is de interface in te stellen. Er zijn slechts twee
5
http://www.excelmashup.com/jsapi/index
http://handsontable.com/
7
http://visop-dev.com/Project+jQuery.sheet
6
14
opties: of de interface is alleen lezen (met geheel geen opties), of de interface is compleet (met alle
opties om aan te passen). Om de interface dus zo te maken dat aan de eisen voor DeliverXL wordt
voldaan zullen er delen van de API aangepast of uitgebreid moeten worden.
Uiteindelijk was het dus vooral de keuze tussen Handsontable en jQuery.Sheet. Omdat beide
mogelijkheden niet direct te gebruiken zijn (er moet het een en ander worden aangepast), is
uiteindelijk gekozen om jQuery.Sheet te gebruiken. Die keuze is gemaakt omdat de functionaliteit
van jQuery.Sheet veel uitgebreider is dan die van Handsontable.
3.7 Testmethodes
Voor elk project is het belangrijk om de code goed te testen. In het algemeen geldt: code die niet
getest is, is niet af. Om de meeste code te testen in de kleinste vorm mogelijk, gebruiken we unit
tests. In Visual Studio zijn standaard testmogelijkheden ingebouwd, maar deze functies zijn niet
volledig. Zo ontbreekt bijvoorbeeld de mogelijkheid om klassen te mocken (simuleren van objecten,
waarbij de programmeur zelf het gedrag kan bepalen van het object). Door een test framework als
NUnit te gebruiken, zijn er veel uitgebreidere mogelijkheden om te testen. Andere populaire unit test
frameworks zijn bijvoorbeeld: xUnit, Testdriven.Net en Moq. Deze frameworks hebben bijvoorbeeld
ook allemaal ondersteuning om klassen te mocken en kunnen ook gebruikt worden in combinatie
met .NET. Omdat NUnit toch het meest gebruikt wordt en er in ons team ook al ervaring is met dit
framework, hebben we de keuze voor hiervoor gemaakt. Daarnaast wordt dit test framework ook al
gebruikt bij Infotron voor het testen van PerfectXL.
Voor de acceptance tests wordt het framework Selenium gebruikt. Dit framework maakt het mogelijk
om acties die een tester uitvoert op een webpagina op te nemen en weer af te spelen op een andere
snelheid, hierdoor kan er veel sneller getest worden. Op deze manier kan ook de interface getest
worden. Met dit framework kunnen tests geschreven worden in C# die via de API van Selenium de
website van DeliverXL testen.
Voor het testen van DeliverXL hebben we beide software pakketten nodig, want ze vervullen beide
een andere rol. Een unit test framework test kleine delen van de functionaliteit, bijvoorbeeld een
methode of een functie. Een acceptance test zal het systeem als geheel testen, zodat er getest kan
worden of de functionaliteit van de applicatie aan de specificaties voldoet.
15
4. ONTWIKKELPROCES
Naast de opbouw van het systeem is ook onderzocht op welke manier het ontwikkelproces vorm
gaat krijgen. In dit hoofdstuk komt aan de orde wat de conclusies hiervan zijn, en hoe tot die
conclusies gekomen is.
4.1 Ontwikkelmethode
Er zijn verschillende mogelijke methoden waarop we de softwareontwikkeling van DeliverXL kunnen
uitvoeren. Het is belangrijk om een geschikte methode te vinden, omdat iedere methode zijn eigen
voor- en nadelen in het ontwikkelproces van DeliverXL. Om aan het eind van het project een
kwalitatief goed product te hebben is ook de keuze van geschikte ontwikkelingsmethode van belang.
Watervalmodel
Een traditionele aanpak is volgens het watervalmodel (zie Figuur 6), waarin de ontwikkeling in
verschillende fasen achtereenvolgens wordt uitgevoerd. Door het expliciet doorlopen van deze fasen
kan er meer duidelijkheid komen in het project, omdat er veel wordt gedocumenteerd en de fasen
sequentieel worden uitgevoerd. Een groot nadeel is dat deze methode erg tijdrovend is, terwijl vaak
tijdens het ontwikkelproces bepaalde eisen nog wel eens kunnen wijzigen of niet haalbaar blijken te
zijn. Uiteindelijk ontstaat volgens de watervalmethode pas aan het eind van het ontwikkeltraject
daadwerkelijk een product, waarna er nog maar weinig tijd over is voor verbeteringen op basis van
feedback van de opdrachtgever. Een eindproduct volgens de watervalmethode voldoet dus niet per
definitie meer aan alle ideeën die de opdrachtgever op dat moment heeft.
Figuur 6 - Watervalmodel
Incremental build model
Een andere softwareontwikkelmethode is volgens het incremental build model (zie Figuur 7). Hierbij
wordt de ontwikkeling van het eindproduct opgedeeld in meerdere componenten, die achter elkaar
kunnen worden ontwikkeld. Iedere iteratie wordt opgedeeld in een aantal fasen die
achtereenvolgens worden uitgevoerd. Uiteindelijk eindigt iedere iteratie met een werkend prototype
wat getoond kan worden aan de opdrachtgever. Deze methode is dus een combinatie van het
watervalmodel en de ideeën van prototyping.
Een voordeel is dat de opdrachtgever nu niet alleen een eindproduct afgeleverd krijgt, maar ook in
de loop van het ontwikkeltraject prototypes te zien krijgt en zodoende wordt betrokken bij het
16
ontwikkelproces. Een nadeel is dat tijdens iedere iteratie nog steeds een vast aantal fasen wordt
doorlopen, wat in veel gevallen tijdrovend kan zijn.
Figuur 7 - Incremental build model
Scrum
Een meer flexibelere methode van softwareontwikkeling is Scrum (zie Figuur 8), waarbij ook wordt
gewerkt met iteraties (sprints). Allereerst is er een product backlog, een prioriteitenlijst waarop alle
functionele eisen van het product staan, vaak in de vorm van user-stories. Voor iedere sprint worden
in overleg met de product owner de belangrijkste user-stories geselecteerd en opgenomen in de
sprint backlog; dit is wat het ontwikkelteam in deze sprint wil bereiken. In deze korte sprints worden
user-stories omgezet naar werkende functionaliteiten in het product, inclusief documentatie en
tests. Een sprint wordt afgesloten met een demonstratie van het product aan de product owner en
een evaluatie.
Het voordeel van deze aanpak is niet alleen dat de opdrachtgever beter bij het ontwikkelproces
wordt betrokken, maar ook dat in volgende sprints rekening gehouden wordt met veranderende
eisen van de opdrachtgever.
Figuur 8 – Scrum
17
Gekozen ontwikkelmethode
Uiteindelijk kiezen wij bij de ontwikkeling van DeliverXL voor een combinatie van het incremental
build model en Scrum. We hebben namelijk op basis van de eisen van te voren nagedacht in welke
kleinere componenten we ons systeem willen opdelen (in de vorm van milestones). We willen tijdens
het ontwikkeltraject gaan werken in sprints van een week, waarbij we van te voren wel een planning
hebben gemaakt welke milestones we verwachten te ontwikkelen in welke sprints. De keuze voor
een vorm van Scrum hebben we gemaakt omdat we toch veel flexibiliteit willen tijdens het
ontwikkelproces; het is goed mogelijk dat bepaalde eisen nog veranderen of niet haalbaar blijken.
Door iedere week te kiezen welke functionaliteit we gaan implementeren hebben we nog alle
vrijheid hoe DeliverXL er uiteindelijk uit gaat zien. Bovendien kunnen we na elke sprint telkens een
uitgebreider prototype van DeliverXL tonen aan de opdrachtgever, zodat zij goed op de hoogte
blijven van onze voortgang.
4.2 Versiebeheer
Tijdens het ontwikkelen van DeliverXL worden er door meerdere personen aan gewerkt. Op ieder
moment kan iedereen een andere versie ten opzichte van elkaar hebben. Er is dus een
versiebeheersysteem nodig die de verschillende versies, oftewel takken, bij elkaar kan samenvoegen.
Alle wijzigingen moeten ook worden opgeslagen zodat als later er iets niet werkt bijvoorbeeld, de
code gemakkelijk opgehaald kan worden van een eerdere versie waar alles wel werkte.
Bij de ontwikkeling van PerfectXL heeft Infotron gebruik gemaakt van het versiebeheersysteem git.
Git maakt het mogelijk om alle bovenstaande zaken te realiseren behalve het samenwerken met
anderen, git maakt namelijk gebruik van lokale repositories. Om samen met anderen te werken aan
een programma moeten deze repositories op een soort server gezet worden, dit kan bijvoorbeeld
met GitHub maar en zijn meerdere van dit soort diensten. Infotron heeft een GitHub account die het
bovendien mogelijk maakt om privé projecten aan te maken. Normaal is een project op GitHub voor
iedereen te zien, privé projecten kunnen worden gedeeld met een select groepje mensen.
Een versiebeheersysteem is geschikt voor files die gebuikt worden bij het ontwikkelen van een
programma, omdat dit allemaal op tekst gebaseerde bestanden zijn. Dit betekent dat als er een tak
wordt samengevoegd met een andere tak in het versiebeheersysteem, twee bestanden op dezelfde
locatie met dezelfde naam samengevoegd kunnen worden omdat er gezien kan worden wat de
verschillen zijn. Database files zijn over het algemeen geen tekst gebaseerde bestanden, maar binary
bestanden. Dit betekent als men twee takken gaat samenvoegen er een conflict kan optreden als de
database bestanden niet hetzelfde zijn. Er moet dan een keuze gemaakt worden tussen het ene of
het andere bestand, hierbij gaat hoogst waarschijnlijk data verloren. Voor deze reden moet er een
database server gebruikt worden. Deze server zal buiten het bereik van het versiebeheer komen te
staan, die wij zelf up-to-date zullen houden.
18
REFERENTIES
[1] F. F. J. Hermans, "Analyzing and visualizing spreadsheets," Delft, 2012.
[2] R. R. Panko, "What we know about spreadsheet errors," Journal of End User Computing, vol. 10,
no. 2, pp. 15-21, 1998.
[3] R. R. Panko, "Spreadsheet Errors: What We Know. What We Think We Can Do.," in Proceedings of
the Spreadsheet Risk Symposium (European Spreadsheet Risks Interest Group), Greenwich,
England, 2000.
[4] S. Chitnis, G. Gupta and M. Yennamani, "NExSched: Solving Constraint Satisfaction Problems with
the Spreadsheet Paradigm," Department of Computer Science The University of Texas at Dallas,
2006.
[5] A. Felfernig, G. Friedrich, D. R. C. Jannach and M. Zanker, "Developing constraint-based
applications with spreadsheets," Developments in Applied Artificial Intelligence. Springer Berlin
Heidelberg, pp. 197-207, 2003.
19
BIJLAGE D
SIG EERSTE FEEDBACK
SIG evaluatierapport
De code van het systeem scoort 3 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de
code gemiddeld onderhoudbaar is. Een hogere score is niet behaald door lagere scores voor Unit
Size, Unit Interfacing, en Module Coupling.
Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het
opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te
begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. Binnen de langere methodes in
dit systeem, zoals bijvoorbeeld DeliverXLInitializer.Seed(), zijn aparte stukken functionaliteit te
vinden welke ge-refactored kunnen worden naar aparte methodes. Commentaarregels zoals
bijvoorbeeld '// Add data for Account' en '// Add data for Constraint & Position' zijn een goede
indicatie dat er een autonoom stuk functionaliteit te ontdekken is. Het is aan te raden kritisch te
kijken naar de langere methodes binnen dit systeem en deze waar mogelijk op te splitsen.
Voor Unit Interfacing wordt er gekeken naar het percentage code in units met een bovengemiddeld
aantal parameters. Doorgaans duidt een bovengemiddeld aantal parameters op een gebrek aan
abstractie. Daarnaast leidt een groot aantal parameters nogal eens tot verwarring in het aanroepen
van de methode en in de meeste gevallen ook tot langere en complexere methoden. Een voorbeeld
hiervan is SubmittedFileController.Uploads(), waarbij zowel het aantal als het type parameters niet
echt handig is. De start- en einddatum worden nu als string meegegeven, terwijl jullie hier eigenlijk
een date of datetime voor willen hebben (en niet elke willekeurige string). De combinatie start/end
date komt ook vrij vaak voor, dus jullie zouden kunnen overwegen om een DateRange type te
introduceren.
Voor Module Coupling wordt er gekeken naar het percentage van de code wat relatief vaak wordt
aangeroepen. Normaal gesproken zorgt code die vaak aangeroepen wordt voor een minder stabiel
systeem omdat veranderingen binnen dit type code kan leiden tot aanpassingen op veel
verschillende plaatsen. In jullie geval komt de lagere score niet zozeer doordat bestanden te veel
verantwoordelijkheid bevatten, maar omdat jullie meerdere classes in hetzelfde bestand
combineren. Het is in de meeste programmeertalen, inclusief C#, een best practice om één class per
bestand te definiëren. Jullie hebben deze indeling waarschijnlijk gekozen omdat jullie het "zonde"
vinden om voor zo'n kleine class een nieuw bestand te maken, maar deze aanpak wordt
problematisch als de classes gaan groeien.
De aanwezigheid van test-code is in ieder geval veelbelovend, hopelijk zal het volume van de testcode ook groeien op het moment dat er nieuwe functionaliteit toegevoegd wordt.
BIJLAGE E
SCREENSHOTS
Overzicht van views in DeliverXL
Figuur 1 - Overzicht van voorwaardensets voor de manager
Figuur 2 - Formulier voor het aanmaken van een nieuwe voorwaarde set
Figuur 3 - Overzicht van voorwaarden sets / templates voor de werknemer
Figuur 4 - weergave van een positief resultaat bij een upload van een correct bestand
Figuur 5 - Weergave van een negatief resultaat inclusief suggesties bij het upload en van een bestand die niet voldoet
Figuur 6 - Overzicht voor een werknemer van al zijn geuploade bestanden
Figuur 7 - Overzicht voor de manager van alle naar hem opgestuurde gecontroleerde bestanden
Figuur 8 - Overzicht voor de manager van alle werknemers die een bestand moeten inleveren
Figuur 9 - Overzicht voor een administrator van alle gebruikers
Figuur 10 - Weergave van een Excel bestand in DeliverXL
Figuur 11 - Weergave van voorwaarden op een cel
Figuur 12 - Lijstweergave van voorwaarden

Inhoud - Bureau Vrijwilligerswerk Pijnacker

Een export maken van de gegevens

WIK brief uitleg niet btw plichtig

Fotograferen met ID-Link

Werkwijze foto inlezen in Excel 1. Foto bestand even op

OVERZICHT EXTRA OEFENINGEN OFFICE 5/6

Voortgangsrapportage via Excel Voortgangs add-on

www.desocialekaart.be Gegevens exporteren als ingelogde gebruiker

Sla dit formulier op!

WinMens – CQ Index