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
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.
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
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() .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() .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().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:
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.
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">
<select id="DataType" name="DataType">
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:
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 SortIQueryable(Dictionary<string, Func, IOrderedQueryable>> dict, IQueryable toBeSorted, string sort, bool orderDescending) { if (sort == null || !dict.ContainsKey(sort)) return toBeSorted.ToList(); List sortedList = dict[sort](toBeSorted).ToList(); 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, IOrderedQueryable>>() { { "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.
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.
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
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
