In de eerste plaats bedank ik de medewerkers van Mobile Health Unit (MHU), en in het bijzonder Prof. Dr. Lars Grieten, Thijs Vandenberk, Wilco Waaijer en Thomas Reyskens voor de mogelijkheid om stage te lopen bij het bedrijf. Ook de begeleiding was uitstekend. Zij gaven enorm veel aandacht aan de begeleiding van de stagiairs.
Vervolgens bedank ik Philippe Haldermans, de hogeschoolpromotor. Zijn feedback was essentieel voor de documentatieopdrachten, zoals het portfolio en het eindwerk, en de onderzoeksopdracht.
Daarnaast gaven de taallectoren deskundig taaladvies bij het schrijven van het eindwerk en de projectomschrijving, waarvoor ik hen dankbaar ben.
Verder bedank ik de medewerkers van hogeschool PXL. Afdelingshoofd Francis Vos en opleidingscoördinator Tristan Fransen gaven mij de unieke kans om opnieuw te studeren aan de PXL. Ze stonden me samen met de medewerkers van het secretariaat en de trajectbegeleiders bij met raad en daad omtrent de administratieve formaliteiten en keuzes in het studietraject. Ook bedank ik stagecoördinator Marijke Willems om zich te bekommeren om alle administratie en coördinatie rond de stage.
Tot slot bedank ik mijn mede-stagiairs, Ali Eren, Laurens Pouders, Yannick Sneijers en Michiel Deprez met wie ik heel wat prettige en leerrijke momenten heb mogen beleven en vlot heb samengewerkt.
Inhoudsopgave
Abstract
De Mobile Health Unit (MHU) is een multidisciplinaire onderzoekseenheid in het domein van de mobiele gezondheidszorg. Deze structurele samenwerking tussen Universiteit Hasselt, Jessa ziekenhuis en Ziekenhuis Oost-Limburg heeft als doel klinische expertise te combineren met academische kennis. De stageopdracht is het ontwikkelen van een module in de bestaande applicatie Dharma. Het onderzoek gaat over de vergelijking van de PHP-frameworks Laravel en CodeIgniter. Het resultaat van het onderzoek bepaalt het framework voor de stageopdracht.
Om klinische waarden van patiënten buiten het ziekenhuis op te volgen, vanop afstand werd eerder al het Dharma-platform ontwikkeld. Om een correcte interpretatie van deze waarden te garanderen, is er vaak bijkomende informatie nodig. Zo kan de bloeddruk van een patiënt bijvoorbeeld hoger zijn na het sporten. Kennis van deze omgevingsfactoren is belangrijk om de gegevens accuraat te kunnen interpreteren. Om deze informatie te verkrijgen wordt een mobiele applicatie ontwikkeld waarmee patiënten (dynamische) vragenlijsten kunnen invullen. Deze applicatie maakt een vlottere communicatie tussen patiënt en zorgverlener mogelijk. Het doel van deze stage is de basisontwikkeling van de back-end met de bijhorende beheerderspanelen voor deze mobiele applicatie. Daarnaast is er de mogelijkheid voor patiënten om vragenlijsten online in te vullen waarna de antwoorden worden opgeslagen in de databank.
Via de beheerderspanelen kunnen vragen worden aangemaakt, onderverdeeld in groepen, en als vragenlijst worden opgesteld. Vragen kunnen hierbij getriggerd worden op basis van het antwoord op voorgaande vraag. Ook kan een aanvraag tot invullen van een vragenlijst gedaan worden. Bovendien is het mogelijk om vragen te sturen naar patiënten die getriggerd worden op basis van bepaalde meetresultaten.
De back-end moet geïntegreerd worden in het bestaande systeem. Dit systeem werd ontwikkeld met behulp van de programmeertaal PHP en het CodeIgniter-framework, maar wordt herschreven met behulp van het Laravel-framework.
Doordat de vraag speelde of het aangewezen is om de nieuwe uitbreiding te ontwikkelen binnen het oude CodeIgniter-systeem of het nieuwere Laravel-systeem, is een diepgaand onderzoek naar de voor- en nadelen van beide frameworks nodig. Naast een vergelijkende studie van CodeIgniter en Laravel, wordt er nagegaan welke andere frameworks in aanmerking komen voor deze opdracht.
Op basis van het onderzoeksresultaat wordt de uitbreiding tijdens deze stage met het Laravel-framework ontwikkeld. Verder worden HTML, CSS, Bootstrap, Javascript, JQuery, en een aantal Javascript- en JQuery-plug-ins gebruikt voor de ontwikkeling van de front-end van de beheerderspanelen.
Lijst van gebruikte afkortingen en symbolen
MHU Mobile Health Unit
PHP PHP: Hypertext Processor, programmeertaal
MVC Model-view-controller, paradigma dat gebruikt wordt in diverse frameworks
API Application Programming Interface
RDBMS relational database management system
OOP Object oriented programming
RAD Rapid application development
Lijst van begrippen
Laravel specifiek PHP-framework
CodeIgniter specifiek PHP-framework
CakePHP specifiek PHP-framework
Symfony specifiek PHP-framework
Model Deel van de MVC-architectuur. Het model representeert het databaseschema
Controller Deel van de MVC-architectuur. De controller geeft de gegevens door aan die views die de gegevens presenteren aan de gebruiker
View Deel van de MVC-architectuur. De views presenteren de gegevens aan de gebruiker
Routing Manier om een link naar de juiste code te laten verwijzen binnen een MVC-framework
Unit-test Code die een ander afgebakend deel van de code test
Scaffolding Manier om binnen een MVC-framework automatisch code te genereren voor bijvoorbeeld de meest gangbare databankoperaties
MongoDB specifieke Niet-relationele databank
ElasticSearch specifieke zoek-server
Composer Pakketmanager
Doctrine ORM-systeem
Namespace
Propel ORM-systeem
Deel 1: Stageverslag
1 Bedrijfsvoorstelling
Mobile Health Unit (MHU) is een kennisplatform voor mobiele gezondheidstoepassingen en is een initiatief vanuit de faculteit Geneeskunde en Levenswetenschappen van de Universiteit Hasselt (UHasselt). MHU is gevestigd in het Jessa Ziekenhuis te Hasselt en in het Ziekenhuis Oost-Limburg te Genk, waar de stage plaatsvindt. Het belangrijkste doel is het wetenschappelijk ondersteunen van eHealth onderzoek.
De focus ligt op multidisciplinair wetenschappelijk onderzoek rond de toepassing van informatie- en communicatietechnologie ten dienste van de gezondheidszorg. Naast de medische en klinische aspecten worden ook de technologische, de socio-economische, de psychologische en de ethische aspecten belicht en onderzocht. Dit wordt mogelijk doordat MHU de samenwerking over de faculteitsgrenzen van de UHasselt coördineert evenals de samenwerking met externe onderzoeks-partners.
MHU treedt op als partner voor ondernemingen actief in de zorgsector die innovatieve medische technologie willen testen en valideren in de klinische praktijk. Door het aanbieden van een klinische proeftuin in combinatie met een wetenschappelijk onderbouwde evaluatie stimuleert MHU de economische valorisatie en de integratie van nieuwe technologie op de werkvloer.
Als aanspreekpunt voor alle betrokken partijen in mobile health wil MHU samenwerking faciliteren tussen zorgverstrekkers, industrie, onderzoeksinstellingen, overheid en zorgverzekeraars. Daarnaast werkt MHU mee aan het opstellen van richtlijnen en/of normen voor de uitgebreide implementatie van afstandsmonitoring binnen de zorgsector.
Via zijn diensten tracht MHU de digitale innovatie in de huidige zorgsector wetenschappelijk te onderbouwen en op die manier te faciliteren. Zo streeft MHU naar een efficiënte en kosteneffectieve zorgorganisatie, met behoud van de zorgkwaliteit als antwoord op de toekomstige zorgkloof.
2 Voorstelling stageopdracht
2.1 Probleemstelling
Om klinische waarden van patiënten buiten het ziekenhuis op te volgen vanop afstand werd eerder al het Digital Health Research-platform Mobile Health (Dharma) ontwikkeld. Deze klinische waarden hebben vaak meer informatie nodig om geïnterpreteerd te worden. Zo kan bijvoorbeeld de bloeddruk van een patiënt hoger zijn na het sporten. Kennis van deze omgevingsfactoren is belangrijk. Dharma kan een aantal medische gegevens van patiënten registreren vanop afstand, door middel van sensoren, en maakt deze gegevens beschikbaar voor zorgverleners en artsen. Deze informatie is niet altijd even bruikbaar omdat context rond deze gegevens ontbreekt. Door extra informatie te verstrekken worden de cijfers waardevoller en krijgen ze meer betekenis.
2.2 Doelstellingen
Het doel is om meer informatie te verkrijgen van patiënten en zo meer context te creëren rond metingen. Een mobiele applicatie wordt ontwikkeld waarmee patiënten (dynamische) vragenlijsten kunnen invullen. Met dynamisch wordt bedoeld dat op basis van antwoorden op voorgaande vragen, volgende vragen kunnen gesteld worden. Het doel van deze stage is de basisontwikkeling van de back-end met beheerderspanelen voor deze mobiele applicatie, waardoor communicatie tussen patiënt en zorgverlener mogelijk wordt. Deze back-end moet integreren met het bestaande systeem, Dharma, dat oorspronkelijk geschreven werd met behulp van het CodeIgniter-framework en wordt herschreven met behulp van het Laravel-framework. Bijgevolg wordt ook de uitbreiding tijdens deze stage met behulp van het Laravel-framework ontwikkeld.
2.2.1 Vragen en groepen
Allereerst moet een onderzoeker vragen kunnen aanmaken en deze kunnen onderverdelen in groepen. Er zijn vier verschillende soorten vragen: meerkeuzevragen, ja-neevragen, schaal-vragen en open vragen. In het geval van een meerkeuzevraag moeten er mogelijke antwoorden kunnen toegevoegd worden en in het geval van schaalvragen een limiet.
2.2.2 Vragenlijsten
Een tweede doelstelling is de mogelijkheid om vragenlijsten op te stellen aan de hand van de aangemaakte vragen en groepen. Deze vragen en groepen moeten daarbij doorzocht kunnen worden. Vervolgens moeten er vervolgvragen kunnen worden gedefinieerd die enkel gesteld worden wanneer een antwoord aan specifieke voorwaarden voldoet.
2.2.3 Antwoorden
Verder moeten deze vragenlijsten ingevuld kunnen worden door een patiënt. Een e-mail moet worden gestuurd naar de patiënt met daarin een link naar de betreffende vragenlijst. De antwoorden die de patiënt geeft worden opgeslagen in de databank en indien van toepassing moeten de conditionele vragen worden getoond.
2.2.4 Triggers
Ten slotte moeten vragenlijsten automatisch getriggerd kunnen worden aan de hand van meetresultaten bij de patiënt.
2.3 Technologieën
2.3.1 PHP
De ontwikkeling van de back-end gebeurt met behulp van de programmeertaal PHP. Deze scripttaal wordt vooral gebruikt om dynamische websites te bouwen. Bij de eerste versie van 1995 stond de afkorting voor “Personal Home Page tool”. Tegenwoordig staat de afkorting voor “PHP: Hypertext Preprocessor”. Het is dus een recursief acroniem dat veel toepasselijker is omdat de taal voor veel meer gebruikt wordt dan enkel persoonlijke webpagina’s.
PHP wordt meestal gebruikt voor het verwerken van gegevens tot Hyper Text Markup Language (HTML). Het is een server-side scripttaal. De code wordt door de webserver uitgevoerd. Dit betekent dat de PHP-code uitgevoerd wordt voordat de browser iets doet. Daardoor kan er dynamisch HTML-code gegenereerd worden, die vervolgens naar de browser gestuurd wordt. [1]
2.3.2 Laravel
Laravel is het gebruikte framework voor deze opdracht. Het staat bekend voor elegante expressieve syntax, eenvoud en leesbaarheid. Het framework heeft uitgebreide documentatie en ondersteunt migraties die teamwork vergemakkelijken. Een eigen ORM, een handig routingsysteem, en eenvoudige authenticatiemechanismen maken Laravel ideaal voor het bouwen van moderne onderhoudbare PHP-webapplicaties. [2]
2.3.2.1 Artisan
Laravel bevat de handige tool Artisan om commando’s uit te voeren via de opdrachtprompt. Via deze tool kunnen bepaalde bestanden, met een bijhorende basisstructuur, automatisch gegenereerd worden, zoals models en controllers. Ook het uitvoeren van databankmigraties kan via deze tool.
2.3.2.2 Eloquent
Het ingebouwde ORM van Laravel, Eloquent voorziet een simpele implementatie van het ActiveRecord-patroon om het werken met de databank te vergemakkelijken. Iedere tabel in de databank heeft een corresponderende model-klasse die gebruikt wordt om te communiceren met die tabel. Model-klassen zorgen er voor dat query’s kunnen worden uitgevoerd op de gegevens in de tabellen, en dat nieuwe gegevens kunnen worden toegevoegd. [3]
Eloquent speelt een grote rol in het stageproject, vooral voor het leggen van, soms recursieve, relaties tussen tabellen.
2.3.2.3 Blade
Laravel bevat het eenvoudige en krachtige templatingmechanisme Blade. Het verschil met andere populaire templatingmechanismen is dat Blade het gebruik van normale PHP-code in views toelaat. Alle views worden gecompileerd naar PHP-code en bewaard in het cachegeheugen tot ze gewijzigd worden. Daarom veroorzaakt dit templatingmechanisme geen overhead. [4]
Alle views in het stageproject gebruiken Blade.
2.3.2.4 Laravel SD
Laravel SD is een handige tool om databank-schema’s te maken, exporteren en zelfs te delen. Met deze schema’s kunnen automatisch klassen voor Laravel gegenereerd worden zoals bijvoorbeeld migratieklassen en model-klassen. [5]
De allereerste migratie- en model-klassen voor het stageproject zijn gegenereerd met behulp van Laravel SD.
2.3.3 Composer
Composer is een dependency-manager voor PHP die helpt om alle bibliotheken voor het project te declareren, beheren en updaten. Composer installeert bibliotheken en pakketten per project en niet globaal, hoewel dat wel mogelijk is. Composer is geïnspireerd op npm en bundler. [6]
Composer beheert de afhankelijkheden voor het stageproject, en installeert alle nodige bibliotheken en pakketten automatisch bij een nieuwe installatie na het uitvoeren van een eenvoudig commando.
2.3.4 CodeIgniter
CodeIgniter is een krachtig PHP-framework met een kleine voetafdruk, gebouwd voor ontwikkelaars die een eenvoudige elegante gereedschapskist nodig hebben om volledige webapplicaties te bouwen. [7]
2.3.5 JavaScript
Met de populaire client-side programmeertaal JavaScript kunnen webpagina’s interactief gemaakt worden. [8]
De officiële naam van JavaScript is ECMAScript. Het is een lichte scripttaal die door de browser geïnterpreteerd wordt bij het laden van een pagina. Dit zorgt voor verschillen bij het uitvoeren in verschillende browsers. Om dat probleem op te lossen zijn er handige bibliotheken zoals jQuery. [9]
JavaScript wordt vaak gebruikt in het stageproject. Onder andere het laden en tonen van conditionele vragen na het beantwoorden van een andere vraag gebeurt met behulp van JavaScript.
2.3.6 jQuery
Het doel van jQuery is het werken met JavaScript te vergemakkelijken. jQuery is een lichte bibliotheek voor JavaScript waarmee er meer bereikt kan worden met minder code. Het verpakt taken die vaak worden uitgevoerd in JavaScript en meerdere regels code vergen in handige methodes die in één regel kunnen worden opgeroepen.
Complexe taken zoals het uitvoeren van AJAX-calls en het manipuleren van het document object model (DOM) worden eenvoudig met jQuery.
Ook CSS is makkelijker te manipuleren met jQuery. Verder kunnen er methodes aan HTML-events gekoppeld worden en visuele effecten en animaties getoond worden.
Er bestaan heel wat handige plug-ins voor jQuery, die het werk nog meer vergemakkelijken.
JavaScript op de gewenste manier laten reageren in verschillende browsers kan moeilijk zijn, omdat alle browsers dit op een andere manier interpreteren. jQuery zorgt er voor dat code op exact dezelfde wijze wordt uitgevoerd in verschillende browsers, zelfs in oude browsers zoals Internet Explorer 6. [10]
Waar er in het stageproject JavaScript gebruikt wordt, is dit met de hulp van jQuery. Bovendien bevat het project heel wat jQuery-plug-ins.
2.3.7 AJAX
Met Asynchronous JavaScript And XML (AJAX) kunnen delen van een webpagina geüpdatet worden zonder de volledige pagina te herladen. Door kleine hoeveelheden gegevens uit te wisselen met de server kunnen webpagina’s asynchroon worden geüpdatet. Op die manier kunnen er snelle en dynamische webpagina’s gemaakt worden. Klassieke webpagina’s zonder AJAX moeten volledig herladen worden om nieuwe informatie te tonen. [11]
Om na te gaan welke vraag de volgende vraag is na het beantwoorden van een vraag wordt er in het stageproject een AJAX-call gestuurd naar de back-end. Door AJAX te gebruiken kan deze vraag dynamisch getoond worden op dezelfde pagina zonder deze volledig te herladen.
2.3.8 Twitter Bootstrap
Bootstrap is het populairste HTML-, CSS- en JavaScript-framework om responsieve mobile-first web-projecten te ontwikkelen. Bootstrap maakt front-end web-ontwikkeling sneller en makkelijker voor ontwikkelaars van alle niveaus en projecten van alle groottes. Het is goed gedocumenteerd en bevat heel wat aangepaste HTML- en CSS-componenten, en jQuery-plug-ins. Bootstrap is open source en wordt gehost, ontwikkeld en onderhouden op GitHub. [12]
Bootstrap vormt de basis voor de font-end-ontwikkeling van het stageproject want het gebruikte Inspinia-thema is hierop gebaseerd.
2.3.9 Inspinia-thema met diverse plug-ins
Het Inspinia-thema is een eerste-klasse-template voor het bouwen van beheerderspanelen. Deze volledig responsieve administratordashboardtemplate is gebouwd met het Bootstrap 3 Framework, HTML5, CSS3 en media-query’s. Het bevat een grote collectie herbruikbare user-interface-componenten (UI-componenten) en jQuery-plug-ins. [13]
Dharma, de applicatie waarvoor een module tijdens de stage ontwikkeld wordt is ontwikkeld met behulp van het Inspinia-thema. Om dezelfde huisstijl te behouden en geen onderdelen toe te voegen voor een feature waarvoor er al een plug-in aanwezig is in het project werd voor die module ook dit thema gebruikt.
2.3.10 Javascript- en JQuery-plug-ins
In het project is gebruik gemaakt van een aantal plug-ins voor JavaScript en jQuery. Sommigen worden standaard met het Inspinia-thema geleverd, anderen niet. De belangrijkste gebruikte plug-ins zijn Nestable, DataTables, en Bootstrap Validator.
2.3.10.1 Nestable
De Nestable-plug-in maakt het mogelijk een hiërarchische lijst te maken met drag-and-drop-functionaliteit. Het is oorspronkelijk bedoeld als een experiment van de maker, maar past perfect binnen het project en maakt deel uit van het Inspinia-thema. [14]
In het stageproject werd deze plug-in gebruikt om groepen en subgroepen op een hiërarchische manier weer te geven. Ook conditionele vragen worden op een duidelijke manier weergegeven met behulp van deze plug-in.
2.3.10.2 DataTables
DataTables is een jQuery-plug-in die geavanceerde interactiecomponenten toevoegt aan HTML-tabellen. Zo worden er in het project paginering en zoekfuncties toegevoegd aan tabellen via deze plug-in. [15]
2.3.10.3 Bootstrap Validator
De Validator-plug-in valideert formulieren automatisch in de front-end, vooral via standaardattributen van HTML 5. Alle formulieren in het project gebruiken deze plug-in voor hun validatie. [16]
2.3.11 MySQL databank
MySQL is het meest populaire open-source SQL-databankbeheersysteem, en wordt verdeeld en ondersteund door Oracle Corporation. De databanken zijn relationeel en de servers snel, betrouwbaar, schaalbaar en makkelijk te gebruiken. [17]
Ook in het stageproject wordt deze populaire relationele databank gebruikt.
2.3.12 RESTful webservices
Representation State Transfer (REST) dat in de meeste gevallen het HTTP-protocol gebruikt is een architecturale stijl voor het ontwerpen van applicaties die gebruik maken van een netwerk. RESTful applicaties gebruiken HTTP-requests om gegevens op te slaan, te updaten, te lezen en te verwijderen. Het is een eenvoudiger en lichter alternatief voor complexe mechanismen zoals Simple Object Access Protocol (SOAP). [18]
REST gebruikt een specifiek systeem om URL’s op te bouwen. De applicatie die tijdens de stage ontwikkeld wordt, gebruikt dit systeem zo veel mogelijk.
2.3.13 JSON
JavaScript Object Notation (JSON) is een syntax om informatie op een georganiseerde toegankelijke manier voor te stellen of te bewaren. De gegevens blijven leesbaar voor mensen en zijn op een logische manier te bereiken. [19]
Het is een eenvoudiger alternatief voor XML en is onafhankelijk van programmeertalen. [20]
In het stageproject wordt het JSON-formaat gebruikt om gegevens door te geven vanuit de back-end aan de views na AJAX-calls.
2.3.14 Xampp
Xampp is een populaire ontwikkelomgeving voor PHP. Het is volledig gratis en makkelijk te installeren. Het bevat alles wat nodig is om een PHP-applicatie te bouwen zoals een geschikte webserver en databank. [21]
Omdat Xampp één van de meest eenvoudige ontwikkelomgevingen is om te installeren en om mee te werken werden alle lokale ontwikkelingen met behulp van Xampp getest.
2.3.15 PhpStorm
PhpStorm is een Integrated Development Environment (IDE) die gebouwd is op het IntelliJ-platform van JetBrains. Deze IDE is echter toegespitst op web-ontwikkeling en PHP. [22]
Deze tool is handig omdat het de code en structuur begrijpt en daardoor helpt bij het ontwikkelen. Zo heeft ze onder andere handige functies om code te refactoren. Deze IDE ondersteunt ook front-end-technologieën zoals JavaScript. [23]
Deze IDE is vaak een grote hulp bij het schrijven van code. Wanneer bijvoorbeeld een variabele of methode van naam moet veranderen kan PhpStorm deze naam automatisch laten veranderen op alle plaatsen in het project waar dat nodig is.
2.3.16 XDebug
De XDebug-extensie voor PHP helpt bij het debuggen van PHP-scripts door waardevolle informatie te verstrekken zoals stacktraces in errorboodschappen, geheugenallocatie en bescherming te bieden tegen oneindige loops en recursie. [24]
Deze debugger is een enorme hulp bij het uitvoeren van de stageopdracht. Door breekpunten te plaatsen op strategische locaties kan de IDE op ieder gewenst moment de inhoud van variabelen tonen. Het alternatief is via PHP-code de inhoud van variabelen dumpen in het browservenster. Het nadeel daarvan is dat er op die manier geen controle is over het verloop de uitvoering van de code. Via de debugger kan er stap voor stap bekeken worden welke inhoud bepaalde variabelen hebben. Op die manier kan vaak snel opgespoord waarom code niet reageert zoals verwacht.
2.3.17 HTML 5
Hyper Text Markup Language (HTML) is de alom gekende mark-up-taal om webdocumenten te beschrijven met behulp van tags. [25]
HTML, de taal waarmee webpagina’s gemaakt worden, is relatief makkelijk te leren en toch zeer krachtig. [26]
De laatste standaard is HTML 5, die het nog makkelijker maakt voor web-ontwikkelaars en makers van browsers om standaarden te volgen. Het zorgt voor snellere, betere en consistentere gebruikerservaringen. [27]
Uiteraard zijn alle views in het stageproject opgebouwd met HTML5, in combinatie met het templatingmechanisme van Laravel, Blade.
2.3.18 CSS 3
Cascading Style Sheets (CSS) beschrijft hoe HTML-elementen getoond moeten worden op diverse media, en in het geval van de stageopdracht het scherm. Het bepaalt de lay-out van meerdere pagina’s tegelijk. [28]
Kleuren, lettertypes, groottes, achtergrondafbeeldingen, en vele andere lay-out-eigenschappen worden bepaald door CSS.[29]
CSS 3 is de laatste standaard voor CSS en is volledig achterwaarts compatibel met oudere versies. [30]
Het Inspinia-thema en Bootstrap gebruiken CSS extensief. Soms is het echter nodig om aangepaste CSS-regels te definiëren.
2.3.19 Firebug
Firefox is een populaire gratis webbrowser die werkt op Linux, Mac en Windows. [31]
Deze browser wordt tijdens de stage vaak gebruikt om code uit te voeren en te testen. De extensie Firebug vergemakkelijkt daarbij het debuggen van de front-end. Hiermee wordt het mogelijk om JavaScript, CSS en HTML live te veranderen, debuggen en monitoren in iedere webpagina.
Zo kan Firebug de inhoud van variabelen tracken via JavaScript-code die in de browser geschreven wordt. Ook de netwerk-monitor is heel handig om de resultaten van AJAX-calls te bekijken. Zo wordt de oorzaak van eventuele problemen snel duidelijk. [32]
2.3.20 Git
Het meest gebruikte modern versiecontrolesysteem is GIT, een open-source-project van de maker van Linux. Aangezien GIT een gedistribueerde architectuur heeft is het een voorbeeld van een Hence Distributed Version Control System (DVCS). In GIT is de lokale versie van de code een repository die de volledige geschiedenis van alle veranderingen kan bewaren.
PhpStorm kan deze geschiedenis dan ook makkelijk tonen. Op deze manier moet code tijdelijk in commentaar staan omdat een oude versie altijd terug geopend kan worden en de gewenste delen terug toegevoegd kunnen worden aan de huidige versie. [33]
2.3.20.1 Gitflow
Gitflow is een gekend branching-model voor Git. Nieuwe features worden gebouwd in feature-branches die vertakkingen zijn van de develop-branch. Afgewerkte features worden terug samengevoegd met deze branch. Wanneer het tijd is voor een nieuwe release wordt er een release-branch gemaakt als vertakking van de develop-branch. De code in de release-branch wordt uitgevoerd op een testomgeving. Als er tijdens het testen problemen opduiken worden deze rechtstreeks op deze branch opgelost. Als de toepassing klaar is voor een release wordt deze aan de master-branch en aan de develop-branch toegevoegd. De master wordt vanaf dan enkel nog samengevoegd met release-branches en hotfix-branches. [34]
Een variant van GitFlow, die ook door de MHU-medewerkers gebruikt wordt, is de gebruikte strategie voor het stageproject.
2.3.21 SourceTree
Als alternatief voor de Git-shell is er een grafische tool die SourceTree heet. Deze vergemakkelijkt het werken met Git. Alle repository’s kunnen beheerd worden met deze simpele interface. Dit is makkelijk voor ontwikkelaars met beperkte Git-ervaring. Voor ervaren ontwikkelaars is vooral de kracht een pluspunt. [35]
2.3.22 Trello
Trello is a samenwerkingstool om projecten te beheren op een bord door middel van kaartjes. Zo kan er in één oogopslag gezien worden wie aan welk onderdeel werkt. [36]
3 Uitwerking stageopdracht
3.1 Procesbeschrijving
3.1.1 Aanpak
Na het bestuderen van een eindwerk van een vorige stagiair dat een mogelijk databankmodel voor de opdracht behandelt, wordt aan de hand hiervan het databankmodel opgesteld.
Om na te gaan of het databankmodel voldoet aan alle eisen en een werkende applicatie kan opleveren, wordt een eerste prototype ontwikkeld. In eerste instantie wordt het CodeIgniter-framework hiervoor gebruikt om al snel te beslissen dit met Laravel te doen. Dit prototype focust op de basisfunctionaliteit, zonder daarbij rekening te houden met lay-out, gebruikerservaring, validatie en beveiliging. Het prototype heeft de functionaliteit om vragen, antwoorden, en vragenlijsten aan te maken, en om deze te laten beantwoorden door een patiënt waarna de antwoorden bekeken kunnen worden.
Het allereerste databankmodel wordt net zo vaak aangepast als nodig om een werkende applicatie te maken, met flexibiliteit naar de toekomst toe in het achterhoofd. Dit gebeurt enkele keren tijdens het ontwikkelen van het prototype. Door eerst een prototype te maken alvorens aan de eigenlijke ontwikkeling te beginnen, worden mogelijke problemen met de databank al duidelijk in een vroeg stadium en kunnen problemen in een later stadium vermeden worden.
Als het prototype klaar is, en het databankmodel op punt staat, kan de applicatie ontwikkeld worden, zonder integratie in Dharma, maar met alle nodige functionaliteit, validatie en de juiste lay-out.
De volgende stap is het implementeren van de ontwikkelde functionaliteit in de eigenlijke applicatie Dharma, gevolgd door het uitbreiden van bepaalde features. Daarna volgt en testfase waarbij gevonden bugs worden verbeterd.
3.1.2 Analyse
De analyse houdt vooral het opstellen en perfectioneren in van het databankmodel voor de basisfuncties aan de hand van het prototype. Een echte functionele analyse is niet nodig, omdat de MHU-medewerkers een duidelijk beeld hebben van hun verwachtingen, die telkens alvorens de ontwikkeling van een onderdeel aan te vatten besproken worden. Indien nodig wordt het databankmodel hieraan aangepast.
De technische analyse gebeurt vooral tijdens het ontwikkelen. De technische werking van de onderdelen wordt besproken met de medewerkers, om het project op technisch vlak zoveel mogelijk te laten aansluiten bij hun manier van ontwikkelen. Voor complexere onderdelen hebben zij een duidelijk beeld van de werking en geven zij meer duiding.
3.1.3 Implementatie
3.1.3.1 Databankmodel, migraties en seeds
De basisversie van het databankmodel, opgesteld voor het prototype, wordt naarmate het project vordert aan de noden aangepast. Het is belangrijk om op een flexibele manier met de databank te kunnen werken. Rechtstreeks de databank bewerken met een tool getuigt niet van vakmanschap. Via migraties kunnen tabellen in de databank aangemaakt en bewerkt worden. Dit zijn klassen binnen het Laravel-project die een databank bewerken wanneer ze worden uitgevoerd. Ook zijn deze bewerkingen makkelijk omkeerbaar met een eenvoudig commando. Op deze manier kan wie de code van het project op zijn computer plaatst makkelijk de structuur van de databank genereren.
Doordat de volledige databank opgebouwd is met behulp van migraties kan het project heel makkelijk, inclusief databank, geïnstalleerd worden op een server of op een lokale computer. Wanneer er een aanpassing moet gebeuren aan de databank wordt een nieuwe migratie gemaakt die deze aanpassing doorvoert. Dit is de manier waarop het hoort, zeker wanneer er al een versie van het project in productie is met de databank.
Aangezien de module eerst extern ontwikkeld wordt, buiten Dharma, worden op het moment dat de code wordt geïmplementeerd in het echte systeem, de aanpassingsmigraties per tabel samengevoegd in dezelfde klasse om de code zuiver te houden.
Om de gegevens in de vragentypes en mediumtypes waarop de applicatie gebaseerd is te laten overeen komen met de gegevens in de databank is er een statische seeder die altijd moet worden uitgevoerd en daarom ook geïntegreerd is in het installatiescript. Deze seeder vult de twee betreffende tabellen met gegevens die opgeslagen zijn in de constanten binnen de applicatie. Deze zelfde constanten worden gebruikt in de code om te refereren naar vragentypes en mediumtypes. Zo kunnen er in de databank relaties gelegd worden met deze tabellen en is de code aangepast aan de juiste gegevens in de databank.
Naast de statische seeder zijn er een aantal seeders die dummydata generen zodat de werking van de applicatie getest kan worden.
Het eerste databankmodel blijkt tijdens het ontwikkelen van het prototype niet te voldoen. Met dit databankmodel is het niet mogelijk om de antwoorden op vervolgvragen op te slaan. Daarom is een aanpassing nodig, samen met meer flexibiliteit, zodat het model meer voorbereid is op potentiële wijzigingen van eisen in de toekomst. Het reeds ontwikkelde deel van de functionaliteit dat was gebaseerd op dit model wordt ook herschreven. Daardoor is het databankmodel en de applicatie niet enkel voorzien op vervolgvragen tot op één niveau, maar ook op vervolgvragen op meerdere niveaus.
Laravel blijkt standaard moeilijk met samengestelde primaire sleutels te kunnen omgaan. Daarom is het afgeraden om deze sleutels te gebruiken want ze maken bepaalde databankoperaties, zoals verwijderen en updaten, onmogelijk, tenzij de Laravel-code zou worden overschreven, wat ook afgeraden is. Een migratie waarbij er een extra kolom wordt toegevoegd met de naam ‘id’ die fungeert als primaire sleutel corrigeert het databankmodel naar de manier waarop Laravel het verwacht.
3.1.3.2 Prototype
3.1.3.2.1 CodeIgniter
In eerste instantie wordt het prototype ontwikkeld met behulp van PHP en het CodeIgniter-framework. Het doel is deels het opfrissen van CodeIgniter-kennis, omdat het project met dit framework ontwikkeld zou worden. Toch wordt al gauw beslist om de nieuwe module meteen met Laravel te ontwikkelen om dubbel werk te vermijden. Uit deze beslissing vloeit ook het onderwerp voor het onderzoek voort, namelijk een vergelijking van CodeIgniter en Laravel, met betrekking tot de opdracht.
3.1.3.2.2 Laravel
Het gebrek aan voorkennis van Laravel eist een studieperiode.
Vanaf het moment dat iedere stagiair zijn eigen afgebakende opdracht heeft moet er nog steeds samengewerkt worden. Daarom heeft iedere stagiair ook eigen branches in de Git-repository om op te werken in plaats van op de develop-branch.
De handige tool Laravel SD, om database-schema’s visueel weer te geven, genereert automatisch controller-klassen, model-klassen en migratie-klassen. Hoewel ze een prima basis vormen bevatten deze klassen uiteraard enkel de simpelste implementaties waaraan de echte functionele code kan worden toegevoegd.
Het eerste ontwikkelde deel van het prototype is een pagina om vragen aan te maken en hieraan een vraagtype te koppelen. Deze types kunnen multiple-choice-vragen, ja-nee-vragen, open vragen of schaal-vragen zijn. De eenvoudige pagina heeft enkel basisfunctionaliteit zonder geavanceerde aspecten zoals validatie en afwerking.
Verder zijn er eenvoudige interfaces om mogelijke antwoorden aan multiple-choice-vragen toe te voegen, vragenlijsten op te stellen, aanvragen tot invullen van vragenlijsten te maken, zodat ze verstuurd kunnen worden en vragenlijsten in te vullen.
In het prototype wordt er om vragenlijsten in te vullen één vraag per pagina gesteld. Op die manier is het iets eenvoudiger om, al dan niet conditionele, vervolgvragen te bepalen en te laten tonen. Voor een eerste prototype volstaat dit. De uiteindelijke applicatie moet er meerdere vragen per pagina tonen.
Aangezien het doel van het prototype enkel het testen van het systeem en de databank is, bevat het enkel de basiselementen. Validatie is bijvoorbeeld niet aanwezig. Toch moet het prototype in beperkte mate ook gebruiksvriendelijk zijn, zodat MHU-medewerkers zonder technische achtergrond ook kunnen vaststellen dat het systeem werkte.
3.1.3.3 Uitwerking met Inspinia-thema
Vertrekkende vanuit het prototype wordt ieder onderdeel verder uitgewerkt met het Inspinia-thema, dat Dharma, de applicatie waarvan de vragenmodule deel moet uitmaken, ook gebruikt.
Naast het uitwerken van de features uit het prototype worden er ook nieuwe features toegevoegd en het databankmodel hieraan aangepast.
Experimenten met Inspinia en haar diverse handige plug-ins zijn een goede voorbereiding op de ontwikkelingsfase. Ondertussen diepen de MHU-medewerkers het beeld dat zij hebben van de uiteindelijke applicatie verder uit. De oude versie van Dharma die beschikbaar is op een testomgeving is de inspiratie voor de lay-out..
3.1.3.3.1 Vragengroepen
De mogelijkheid om vragen in groepen in te delen is een nieuwe feature die niet in het prototype aanwezig is. De groepen moeten subgroepen kunnen hebben, die in de visuele voorstelling ingesprongen weergegeven worden. Een recursief systeem met het Blade templatingmechanisme waarbij een partiële view zichzelf aanroept via het @include-statement maakt dit mogelijk.
Dit systeem heeft een correcte validatie, zowel aan de front-end als in de back-end. Groepen kunnen bewerkt of verwijderd worden. Bij het verwijderen van groepen worden de bijhorende vragen verplaatst naar de bovenliggende groep, als die aanwezig is. Hier is ook validatie belangrijk. Een subgroep mag immers bovenliggende groep hebben die al één van zijn subgroepen is. Verder heeft de tabel waarin de groepen worden weergegeven pagineringfunctionaliteit en een knop om vragen aan groepen toe te voegen.
De plug-in DataTables, waarmee de groepen werden weergegeven, is uiteindelijk vervangen door de plug-in NestableLists. Hierdoor verdwijnt de pagineringfunctionaliteit, maar wordt de groepenstructuur overzichtelijker weergegeven.
3.1.3.3.2 Vragen en antwoorden
Aan de gemaakte groepen moeten vragen kunnen gekoppeld worden. Deze vragen moeten kunnen worden aangemaakt, met bijhorende antwoorden in het geval van een multiple-choice-vraag en met een limiet in het geval van een schaalvraag.
3.1.3.3.3 Vragenlijsten
De beperkte functionaliteit van het prototype om vragenlijsten op te stellen wordt uitgebreid en geperfectioneerd. Ook de lay-out wordt aangepast met het Inspinia-thema. Een zoekfunctie om de juiste vraag te vinden die aan een lijst moet worden toegevoegd wordt met behulp van JavaScript en JQuery ontwikkeld.
Om een standaardvraag toe te voegen onderaan de lijst moet het systeem kunnen nagaan welke de voorgaande vraag voor deze vraag is. Dit is niet noodzakelijk de laatste vraag in de databank voor de betreffende lijst, maar wel de laatste hoofdvraag voor die lijst. Enkele recursieve methodes bepalen welke vraag de voorgaande vraag voor een standaardvraag is.
Door op een vraag te klikken in het vragenoverzicht moet deze worden toegevoegd aan een vragenlijst. Om niet een groot aantal form-elementen aan de pagina toe te voegen wordt hiervoor een Ajax-call gebruikt in combinatie met jQuery, gevolgd door een verversing van de pagina.
Bij het weergeven van de opvolgvragen en de vragenlijsten moeten vragen met een voorwaarde altijd voor de vragen zonder voorwaarde getoond worden en niet omgekeerd of door mekaar. Het bepalen van de volgorde van de vragen gebeurt via de PHP-functie sortBy() in combinatie met een query die aangeeft of een opvolgvraag een voorwaarde heeft.
Met aangepaste validatieregels in de back-end wordt er voor gezorgd dat een vraag geen twee standaard opvolgvragen kan hebben en geen twee opvolgvragen met dezelfde voorwaarde. In de front-end-validatie wordt er onder andere voor gezorgd dat per vraag een zelfde conditie of een standaardvraag geen 2 keer kan voorkomen.
3.1.3.3.4 Versturen van aanvragen
Aanvragen tot invullen van een vragenlijst gebeurt via e-mail, een notificatie op de smartphone of beide. De databanktabel met aanvragen heeft een kolom die de gekozen media vertegenwoordigen. De stagiair die aan de API werkt, heeft een functie geschreven die notificaties naar de smartphone stuurt. Voor het versturen van e-mails wordt het verzendadres en het versleutelde wachtwoord opgeslagen als omgevingsvariabelen in het .env-bestand. In de constanten van de applicatie is de sleutel opgeslagen om het wachtwoord te decoderen.
3.1.3.3.5 Beantwoorden van vragen
In het eerste prototype wordt er telkens één vraag per pagina getoond omdat vervolgvragen zo makkelijker bepaald en getoond kunnen worden. Een vereiste is echter dat in de uiteindelijke applicatie meerdere vragen per pagina getoond worden.
Dit zorgt voor de vraag op welke manier de conditionele vragen getoond moeten worden. Met conditionele vragen kan er nooit voorspeld worden hoeveel vragen er op één pagina getoond zullen worden, resulterend in soms zeer lange pagina’s. Een andere vraag is op welke manier moet worden aangegeven dat het om een vervolgvraag gaat, zodat er context kan worden gegeven aan de patiënt.
Iedere pagina moet drie hoofdvragen tonen. Dit aantal wijzigen in de code moet makkelijk zijn. De conditionele vragen moeten tussen de andere vragen worden geschoven wanneer er een antwoord wordt gegeven dat hiertoe leidt. In de titel van deze conditionele vraag staat er een verwijzing naar de vraag waarvan deze vraag een voorwaardelijk vervolg is.
Bij de antwoorden wordt een loader voorzien, die aangeeft dat er een volgende vraag gezocht wordt. Deze loader geeft ook aan dat het gegeven antwoord wordt opgeslagen. Indien dit gelukt is komt er een vinkje voor het antwoord en anders niet.
Wanneer een antwoord veranderd wordt moet niet alleen dit antwoord aangepast worden in de databank, maar ook de antwoorden op conditionele vragen die bij dit antwoord horen moeten verwijderd worden uit de databank. Bovendien moeten deze vragen dan ook van het scherm verdwijnen.
In de back-end-validatie wordt er via conditionele validatieregels gecontroleerd of de antwoorden wel degelijk bij vragen horen die voor die patiënt en voor die specifieke logica van conditionele vragen horen.
Vragenlijsten moeten zeer vlot kunnen worden ingevuld zonder dat er gewacht moet worden op het verwerken van een vorige vraag.
Soms wordt er aan meerdere voorwaarden voldaan, bijvoorbeeld bij overlappende condities op schaalvragen. Daarom is het nodig dat er in dit specifieke geval meerdere vragen worden teruggestuurd. De front-end is er op voorzien om deze vragen ook te kunnen tonen. Deze vragen moeten ook weer verwijderd worden bij wijziging van een antwoord.
De plug-in Bootstrap Validator verzorgt de front-end-validatie. De plug-in JQuery Steps zorgt voor de verdeling van vragen over verschillende pagina’s. De next-knop van de steps-plug-in is geen submit-knop maar een a-tag. Daarom moet deze via JavaScript onbruikbaar gemaakt worden bij een niet geldig ingevulde pagina.
Antwoorden van een half ingevulde vragenlijst moeten ook automatisch worden getoond bij het opnieuw openen van diezelfde aanvraag.
Daarom moeten de juiste conditionele vragen vanuit de back-end meegestuurd worden naar de front-end, samen met de antwoorden. Ook alle volgende conditionele vragen in de boomstructuur moeten getoond worden met hun antwoorden. Wanneer er een ander antwoord gekozen wordt moeten deze ook weer verdwijnen. Het is geen optie om de functies voor het tonen van conditionele vragen in de front-end te hergebruiken, omdat deze Ajax-calls sturen naar de back-end want daardoor worden de vragen als het ware opnieuw beantwoord.
Via recursieve functies en recursieve relaties worden de juiste vragen aan de hand van de antwoorden opgehaald in de back-end. Via eager loading worden deze vragen, en de antwoorden meegestuurd naar de front-end. In de front-end worden data-attributen, id-attributen en CSS-klassen aan bepaalde tags meegegeven om duidelijk te maken welke vragen op welke volgen en wanneer welke vragen verwijderd moeten worden.
3.1.3.4 Implementatie in Dharma
Om de ontwikkelde features te implementeren in Dharma wordt er op de Git-opslagplaats van MHU waarop het Dharma-project zich bevindt voor iedere feature, bijvoorbeeld groepen, lijsten of aanvragen, een nieuwe branch gemaakt. Als een aantal features geïmplementeerd zijn worden de bijhorende branches samengevoegd met de master-branch. Deze master-branch fungeert als test-branch, of de develop-branch zoals ze in termen van Gitflow genoemd wordt. Alles op deze branch wordt via Jenkins automatisch gedeployed op een testomgeving, zodat de MHU-medewerkers de applicatie uitgebreid kunnen testen. Bugfixes gebeuren ook op deze branch. Deze branch zal later worden samengevoegd met de staging-branch om een release voor te bereiden. Wanneer de release klaar is wordt deze samengevoegd met de production-branch. Deze branch is degene waarop de eigenlijke applicatie zoals ze gebruikt wordt is geïnstalleerd. Als er nog bugfixes nodig zijn in dat stadium zullen er kleine aftakkingen op deze branch gemaakt worden om deze uit te voeren. Ondertussen kan er dan aan een volgende release gewerkt worden op de andere branches, op dezelfde manier als beschreven. De nieuwe features voor een volgende release komen op die manier niet op de productie-omgeving terecht bij een bugfix. Deze bugfixes worden dan vanuit de productie-omgeving binnengehaald op de master-branch, zodat ze ook geïmplementeerd zijn bij het ontwikkelen van nieuwe features.
Om de Dharma-gebruikers te koppelen aan de vragenmodule is er authorisatie nodig. Een patiënt kan geen vragenlijsten invullen die voor een andere patiënt bestemd zijn. Ook kan een patiënt geen lijsten aanmaken, aanvragen versturen of vragen beheren. De verschillende panelen zijn geïntegreerd in specifieke bestaande pagina’s van Dharma. Er zijn koppelingen tussen studies en vragenlijsten en tussen patiënten en aanvragen. De routes, of met andere woorden de URL’s zijn ook aangepast aan de schema’s binnen Dharma.
3.1.3.5 Instellen van alarmen
Een belangrijke feature is de mogelijkheid tot het instellen van alarmen, met andere woorden, het koppelen van vragenlijsten aan thresholds. Wanneer er een meetresultaat binnen komt in Dharma moet er nagegaan worden of er een threshold is ingesteld voor deze waarde en parameter, in combinatie met de specifieke studie waaraan de betreffende patiënt deelneemt, en of er aan deze threshold een vragenlijst gekoppeld is. Indien nodig moet de juiste vragenlijst verstuurd worden naar de smartphone-applicatie.
In de mobiele app moet het mogelijk zijn om te zien of een vragenlijst manueel is doorgestuurd of op basis van een meting. Daarom is er een extra veld toegevoegd aan de databanktabel met aanvragen. Voor het instellen van thresholds op zich is er al een interface. Vragenlijsten aan thresholds toekennen vereist een extra interface.