ReWarden

   

Afstudeerverslag 

 

ReWarden

                                                   

 

 

Afstudeerverslag 

ReWarden 

 

 

 

 

     

 

 

 

 

Studentnummer    440137  Naam    W.H.M. Krake  Bedrijf    Nerds & Company  Bedrijfsbegeleider    B. van Gennep 

Opleiding    HBO-ICT   Module    Afstuderen 

Jaar    2019 - 2020 

Instituut    Saxion Hogeschool Enschede  Afstudeerdocent    A. van den Berg 

 

 

Voorwoord 

Voor u ligt het resultaat van bijna twintig weken zwoegen, als het hele project  samengevat zou moeten worden in één zin zou dat zijn dat: “Het lang niet altijd van  een leien dakje ging”. Ondanks de tegenvallers waardoor de planning behoorlijk op  de schop moest en het project behoorlijk onder druk kwam te staan, tot bijna het  uitzichtloze toe, is er op doorzettingsvermogen en karakter toch een mooi resultaat  neergezet waarin vier jaar Saxion HBO-ICT: Software Engineering samenkomt.   

Bij tegenslag is vaak de hulp van een ander het meest waardevol, dit werd nog eens  extra duidelijk doordat het project niet op de werkvloer uitgevoerd kon worden  vanwege de corona crisis. Hierdoor werden de korte digitale contactmomenten,  waarin Bart namens Nerds & Company en Anthony namens Saxion, toch met enige  regelmaat bemoedigende woorden uit konden spreken, waarna weer met frisse  moed doorgezet kon worden, extra waardevol. Waarvoor dank heren! 

 

Tevens heeft het thuiswerken ervoor gezorgd dat het contact met levenspartner  Stephanie onverwacht groot werd, waardoor haar raad en advies met regelmaat  ingewonnen werd. Bedankt dat je daar altijd toe bereid was en het huishouden  tegelijkertijd ook nog draaiende hield. 

 

Bedankjes gaan als laatst nog uit naar collega afstudeerder Remco, die af en toe eens  een digitaal belletje waagde om het reilen en zeilen aan deze zijde te bevragen en  uiteraard ook over de eigen voortgang en situatie een ei kwijt te kunnen. 

   

 

 

Samenvatting 

Dit afstudeer​project heeft de naam ​‘ReWarden’ ​gekregen, ReWarden is een  samenstelling van het woord ​‘reward’ ​en het woord ​‘warden’​. Het project is zo  genoemd omdat voor dit project een applicatie is ontwikkeld waarin regels beheerd  kunnen worden, die bepalen wanneer gebruikers op internetplatforms, in dit geval  e-learnings die Nerds & Company voor haar klanten ontwikkeld, beloningen krijgen  voor activiteiten op het platform. ​‘Reward’ ​staat voor de beloning die de gebruiker  krijgt en ​‘warden’ ​betekent, vrij vertaald uit het Engels; ​‘beheerder’​. Het onderzoek  van het project, dat uiteindelijk resulteerde in het beantwoorden van de hoofdvraag: 

“Hoe kunnen we een systeem ontwerpen en ontwikkelen waarin gebruikers zonder  technische achtergrond, regels kunnen opstellen voor het toekennen van 

beloningen aan gebruikers op internetplatforms?”,​ bestond uit drie deelvragen die  op chronologische volgorde onderzocht zijn. Uit de eerste deelvraag kwam naar  voren dat de grammatica voor zogenaamde ‘productieregels’ geschikt zijn om te  gebruiken voor het opstellen van regels voor dit project. Vervolgens is onderzocht  hoe deze regels in een datastructuur opgeslagen kunnen worden, zodat ze 

opgeslagen kunnen worden in een beheerapplicatie. Hiervoor zijn meerdere  datastructuren gevonden en JSON uiteindelijk tot de meest geschikte bevonden,  met JSON-schema als validator. Toen de grammatica en het schema bekend waren  moest nog een interface ontworpen worden waardoor niet-developers in staat  worden gesteld regels te maken. Deze interface is ontworpen naar een aantal 

voorbeelden van applicaties die op hetzelfde principe gebaseerd zijn. Na het schrijven  van de conclusie van het onderzoek kon aangevangen worden met het realiseren van  de applicatie, die is gerealiseerd middels een front- en back-end architectuur met de  frameworks Angular en Rails. Postgres is gebruikt als database omdat deze goed  samenwerkt met ActiveRecord, het ‘Object Relational Mapping’ systeem van Rails.   De codebase van het project is beheerd via GitHub. Voor het schrijven van unit testen  voor de applicaties is Jasmine gebruikt voor Angular en Rspec voor Rails. Verder  wordt de applicatie gedraaid in een Docker container set up om zo te valideren dat  de juiste dependencies worden geïnstalleerd wanneer de applicatie gedeployed 

wordt op de productie omgeving.   

Versiebeheer 

Versie  Beschrijving  Opgeleverd  Aan 

0.1  Conceptversie  28-05-2020  A. van den Berg 

0.1  Conceptversie  29-05-2020  B. van Gennep 

0.9  Conceptversie  02-06-2020  Hogeschool Saxion 

1.0  Eindoplevering  15-06-2020  Hogeschool Saxion 

Tabel 1: Versiebeheer 

Inhoud 

1. Inleiding 7  2. Huidige situatie 8  2.1. Omgeving 8  2.2. Belanghebbenden 8  2.2.1. Primair 8  2.2.2. Secundair 9  2.3. Aanleiding 9  2.4. Definities en begrippen 10  3. Onderzoeksopzet en verantwoording 12  3.1. Doelstelling 12  3.2. Probleemstelling 12  3.3. Onderzoeksvragen 13  3.4. Methodiek 13  3.5. Projectgrenzen 14  4. Onderzoeksresultaten 18 

4.1. “Welke regels moeten er kunnen worden opgesteld in het systeem?” 18  4.2. “Welke datastructuur is geschikt voor het opstellen van dergelijke regels?” 23  4.3. “Aan welke voorwaarden moet de interface voldoen, zodat regels op een  overzichtelijke en duidelijke manier door de gebruiker kunnen worden 

opgesteld?” 34  5. Ontwerp en realisatie 39  5.1. Tools 40  5.1.1. VSCode[22] 40  5.1.2. Git(Hub)[23] 40  5.1.3. Docker[24] 40  5.2. Applicatie 40  5.2.1. Functionele toelichting 41  5.2.2. Technische toelichting 42  5.2.2.1. Systeem 42  5.2.2.2. Architectuur 42  5.2.2.3. Front-end 42  5.2.2.3.1. Framework/programmeertaal 43  5.2.2.3.2. Angular 43  5.2.2.3.3. Typescript/HTML/CSS 43  5.2.2.3.4. Dependencies 44  5.2.2.3.4.1. Material design 44  5.2.2.3.4.2. Formly 44   

5.2.2.3.5. Componenten 45  5.2.2.3.6. Services 46  5.2.2.3.7. Testen 46  5.2.2.4. Back-end 47  5.2.2.4.1. Framework/programmeertaal 47  5.2.2.4.2. Rails 47  5.2.2.4.3. Ruby 47  5.2.2.4.4. Database 47  5.2.2.4.5. Postgres 47 

5.2.2.4.6. Klassen & relaties 48 

5.2.2.4.6.1. Antecedents 49  5.2.2.4.6.2. Consequents 49  6. Conclusie 51  6.1. Discussie 51  6.2. Aanbevelingen 51  7. Bronvermelding 52  8. Bijlagen 54     

 

 

 

1. Inleiding 

Dit document is geschreven als afspiegeling van het proces van de opdracht:  ReWarden, die wordt uitgevoerd voor Nerds & Company B.V. uit Enschede, als  afstudeerproject in het vierde jaar van de opleiding: HBO-ICT Software Engineering  aan Hogeschool Saxion te Enschede. In de projectperiode, die plaatsvindt van 

10-02-2020 t/m 03-07-2020, is onderzoek verricht naar een manier om de herhalende  taak van het implementeren van regels, voor het toekennen van beloningen aan  gebruikers op internetplatforms, weg te nemen bij het development team en deze  door niet-technisch onderlegde betrokkenen bij de diverse projecten, te kunnen  laten opstellen. Het document bevat een beschrijving van de opdracht, de opzet en  uitvoering van het onderzoek en het ontwerp en de realisatie van een digitaal  product om de uitkomsten van het onderzoek te onderbouwen en daarmee de  onderzoeksvraag: ​“Hoe kunnen we een systeem ontwerpen en ontwikkelen waarin 

gebruikers zonder technische achtergrond, regels kunnen opstellen voor het 

toekennen van beloningen aan gebruikers op internetplatforms?” ​te beantwoorden. 

 

 

 

2. Huidige situatie 

Dit hoofdstuk bevat een beschrijving van de opdrachtgever, de primaire en 

secundaire stakeholders van het project, de aanleiding voor de opdrachtgever om de  opdracht uit te schrijven en de definities en begrippen die in het project gebruikt  worden. 

2.1. Omgeving 

Nerds & Company is een ICT-dienstverlener aan diverse bedrijven in de regio Twente  (o.a. FC Twente, Asito, RRS & Vredestein), elders in Nederland (Philips, A.O. Metalektro)  en tevens internationale klanten (Boda Borg, Adidas). Zij ontwikkelen voor hen 

diverse websites, web & native apps. Nerds & Company is verantwoordelijk voor het  gehele proces, van design, front- en back-end development, tot testing en 

maintenance. Zij zetten zich onder andere in op het gebied van strategische digitale  concepten, waarbij samen met de klant een toekomstgericht plan opgesteld wordt,  waarmee ze haar digitale doelen kan bereiken. Daarnaast ontwerpen zij 

user-interfaces & experiences, creatieve digitale campagnes en prototypes van  producten​[1]​_{. Op development gebied ontwikkelen zij front-end met Angular/VueJS}  en back- end in o.a. Ruby & Elixir. Tevens wordt er gebruik gemaakt van diverse  Content Management Systemen zoals Contentful of Netlify. Er werken op dagelijkse  basis ongeveer 35 mensen in het kantoor van Nerds & Company waarvan ongeveer  de tweederde als front- of back-end developer. De meesten zijn HBO of WO 

geschoold.   

Het project wordt uitgevoerd terwijl op dagelijkse basis wordt meegewerkt in SCRUM  team 1 van Nerds & Company. Dit team bestaat uit een product owner, een scrum  master/front-end developer, één front-end developer en drie back-end developers,  waarvan één tevens de afstudeerbegeleider is. 

2.2. Belanghebbenden 

2.2.1. Primair 

Wouter Krake  Als ontwikkelaar en uitvoerder van het project, de _{belangrijkste primaire belanghebbende.}  Nerds & Company  De opdrachtgever van het project. 

Bart van Gennep 

Bart van Gennep behartigt de belangen van de  opdrachtgever als bedrijfsbegeleider. Hij ziet erop toe  dat het project uitgevoerd wordt volgens de 

kwaliteitsstandaard van de opdrachtgever. 

Saxion Hogeschool  Het project betreft een afstudeerproject voor Saxion _Hogeschool.  Anthony van den Berg  Is als afstudeerdocent namens Saxion betrokken. 

Tabel 2.1 primaire belanghebbenden 

2.2.2. Secundair 

Klanten van Nerds & Company  Er zijn meerdere klanten van Nerds & Company geïnteresseerd om gamification toe  te passen op hun (e-learning) platforms. 

Johan Bruning 

Johan is als Chief Technology Officer van  Nerds & Company niet direct betrokken bij het  afstudeerproject, maar wel de initiator van het  idee. Hij is tevens begeleider van Remco die  op een ander onderdeel van het onderwerp  afstudeert. 

Remco Meinen 

Collega en Windesheim student die 

afstudeert op het gedeelte van de opdracht  dat events kan evalueren en hierop actie kan  ondernemen als er triggers af gaan. 

Developers van Nerds & Company 

Na de oplevering van het project is niet  duidelijk wie de verdere ontwikkeling en  nazorg gaat doen, mogelijk worden mijn  collega’s daarvoor verantwoordelijk, dat maakt  hen mogelijk ook belanghebbende. 

Joost Wiltink 

Collega afstudeerder aan de HAN op het  gebied van User Experience die als onderwerp  gamification heeft. Hoewel Joost geen 

technische implementatie maakt kunnen zijn  bevindingen wellicht interessant zijn voor de  aanpak van dit project. 

Tabel 2.2 secundaire belanghebbenden 

2.3. Aanleiding 

Er heerst een algemeen tekort aan software ontwikkelaars. Dat is een probleem  omdat de vraag naar software naar verwachting de komende jaren exponentieel zal  blijven stijgen. Bedrijven proberen daarom oplossingen te bedenken om mensen  zonder technische achtergrond en aanleg voor programmeren, toch software te  kunnen laten ontwikkelen. Dit noemt men ook wel low-code​[2]​ _{of no-code​}[3]  development. Omdat Nerds & Company de technische vaardigheden van haar  developers graag inzet om grenzen te verleggen en nieuwe creatieve oplossingen te  bedenken in plaats van herhalende taken te doen, proberen zij outside-the-box  oplossingen te vinden die de werklast van de development teams kunnen verkleinen  waardoor er meer ruimte ontstaat om creatieve ideeën te implementeren, de 

kwaliteit van de producten te verhogen en medewerkers uit te dagen zichzelf  continu te blijven verbeteren. Hierbij wordt bijvoorbeeld gekeken naar oplossingen  om herhalende taken, zoals het maken van regels voor het toekennen van 

beloningen aan gebruikers op internetplatforms door collega’s die geen technische  functie bekleden, of zelfs werknemers van de klant te kunnen laten doen. 

 

 

2.4. Definities en begrippen 

E-learning platform​

[4] 

Informatie & communicatie technologie wordt ingezet voor educatieve doeleinden  middels een web platform waar lesstof aangeboden wordt en leerroutes gevolgd  kunnen worden. 

 

Event​

[5] 

Object waarin de verandering van de state van een applicatie, die op een moment  plaatsvindt, wordt vastgelegd. Een event heeft attributen die iets over het event  zeggen, zoals een uniek identificatienummer en het tijdstip waarop het gegenereerd  is. En attributen, ook wel metadata, die iets zeggen over wat er is veranderd in de  applicatie, zoals de vorige gebruikersnaam en de huidige gebruikersnaam.

 

 

Event sourcing​

[5] 

Het gebruiken van events om de verandering van de state van een applicatie vast te  leggen noemt men ook wel event sourcing. Gebruikersinteractie met een applicatie,  bijvoorbeeld door een actie als inloggen, het wijzigen van een gebruikersprofiel of het  plaatsen van een bestelling wordt daarbij vastgelegd in een event, waarbij het 

moment waarop de actie plaatsvindt het belangrijkste attribuut van ieder event is.  Daarnaast kunnen er nog actie-specifieke attributen vastgelegd worden, bij inloggen  kan bijvoorbeeld een user id als attribuut aan het event toegevoegd worden en bij  het plaatsen van een bestelling een bestellingsnummer.  

 

Metadata​

[7] 

Attributen van een event dat gegenereerd wordt door een applicatie, dergelijke  attributen kunnen bijvoorbeeld een gebruikers id zijn, in het geval dat een event  gegenereerd wordt wanneer een gebruiker inlogt of een klantnummer wanneer een  iemand een bestelling plaatst in een webshop. 

 

Regel 

Een regel, of ook wel een business rule​[8]​ _{is een combinatie van één of meerdere}  voorwaarden en één of meerdere gevolgen. De voorwaarde van een regel moet altijd  als true of false geëvalueerd kunnen worden, wanneer de voorwaarde van een regel  true is wordt het gevolg van een regel uitgevoerd. Een voorbeeld van een regel is: “Als  een gebruiker inlogt krijgt hij een notificatie” 

 

Voorwaarde 

Gedeelte van de regel dat getoetst kan worden op ‘waar’ of ‘onwaar’, dit gebeurd op  basis van voorgekomen events. Om de regel met voorwaarde “als een gebruiker  inlogt” als ‘waar’ te evalueren moet er een event optreden met als type “logged_in”   

 

 

Wanneer de voorwaarde van een regel als ‘waar’ geëvalueerd wordt, moet het gevolg  uitgevoerd worden. Als het gevolg “krijgt hij een notificatie” is, moet de gebruiker  voor wie het event met type “logged_in” opgetreden is een notificatie krijgen. Dit  betekent dat in het event ook het id van de gebruiker opgeslagen moet worden.   

Expertsysteem 

Een expertsysteem is een computersysteem dat het besluitvormend vermogen van  een menselijke expert emuleert​[8]​_{. In het domein van het afstudeerproject is het}  expertsysteem nodig om aan de hand van events die ontvangen worden van het  e-learning platform, te kunnen evalueren of aan regels voldaan wordt en het platform  daar vervolgens over te informeren. 

 

 

3. Onderzoeksopzet en verantwoording 

De opzet en verantwoording van het onderzoek wordt uitgelegd aan de hand van de  doelstelling en probleemstelling van het project, welke onderzoeksvragen er 

geformuleerd zijn om het probleem te tackelen, de onderzoeksmethodes die  gebruikt zijn bij het uitvoeren van het onderzoek, door welke fases het project gaat  en wat daarbij de grenzen zijn die gemarkeerd kunnen worden. 

3.1. Doelstelling 

Omdat het bedrijf dus graag wil dat de developers bezig zijn met vernieuwende  onderwerpen in plaats van herhalende taken, is de eerste doelstelling van dit project;  onderzoeken op welke manier een applicatie ontwikkeld kan worden waarmee  niet-developers in staat worden gesteld regels op te stellen, voor het toekennen van  beloningen aan gebruikers op internetplatforms. Wanneer het onderzoek is afgerond  is de tweede doelstelling het realiseren van een applicatie, gebaseerd op de 

uitkomsten van het onderzoek, waarmee bewezen wordt dat niet-developers in staat  zijn bovengenoemde regels op te stellen en te beheren. Nerds & Company heeft  behalve de e-learning platforms ook een applicatie ontwikkeld die op basis van  informatie van slimme sensoren in machines, de status van de machine en de status  van het bijbehorende productieproces kan weergeven. Daarnaast zien zij in de  toekomst ook mogelijkheden op het gebied van e-commerce, bijvoorbeeld door het  geven van korting wanneer een klant vaker besteld in één maand, of wanneer deze  voor een bepaald bedrag besteld. Aangezien hier ook het: ‘als voorwaarde dan  gevolg’ principe op toegepast kan worden dient er tijdens het onderzoek en de  realisatie rekening gehouden te worden met de mogelijkheid van het schrijven van  regels voor deze beide platform soorten. 

3.2. Probleemstelling 

Nerds & Company ontwikkelt voor haar klanten enkele vergelijkbare e-learning  platforms, met hierin verschillende terugkerende onderwerpen, zoals bijvoorbeeld  een (media)bibliotheek, leerroutes met verschillende onderwerpen en gamification​[10]  door middel van een beloning wanneer een doel wordt behaalt. Deze monolithische  applicaties worden vanaf de grond opgebouwd, waarbij de terugkerende 

onderwerpen niet tot nauwelijks kunnen worden hergebruikt. Het kost iedere keer  veel tijd en geld om voor een nieuwe applicatie deze herhalende onderwerpen te  ontwikkelen. Nerds & Company ervaart dit als een probleem omdat het bedrijf haar  developers graag de ruimte biedt om vernieuwende dingen te doen, om zo de 

kwaliteit van de producten te verhogen en medewerkers te motiveren om zichzelf op  technisch vlak continu te blijven verbeteren.  

 

 

3.3. Onderzoeksvragen 

Om de onderzoeksvraag ​“Hoe kunnen we een systeem ontwerpen en ontwikkelen 

waarin gebruikers zonder technische achtergrond, regels kunnen opstellen voor het  toekennen van beloningen aan gebruikers op internetplatforms?” ​te kunnen 

beantwoorden zijn drie deelvragen opgesteld: 

- “Welke regels moeten er kunnen worden opgesteld in het systeem?”  - “Welke datastructuur is geschikt voor het opstellen van dergelijke regels?”  - “Aan welke voorwaarden moet de interface voldoen, zodat regels op een 

overzichtelijke en duidelijke manier door de gebruiker kunnen worden  opgesteld?” 

 

Vervolgens is gekeken met welke onderzoeksmethodes deze vragen beantwoord  kunnen worden. 

3.4. Methodiek 

De onderzoeksmethodiek voor dit project is gebaseerd op: De methodenkaart in de  beroepspraktijk van ICT & Media​[11]​_.  

 

Voor het beantwoorden van de eerste deelvraag is eerst voornamelijk in het ‘veld’ en  in de ‘bieb’ gewerkt en op internet gezocht naar het concept van ‘als voorwaarde dan 

gevolg’ regels of ook wel business rules. Om met de gevonden resultaten vervolgens  een grammatica te bouwen is in het ‘lab’ een set voorbeeld regels opgesteld die  vervolgens getoetst is om de grammatica te valideren. Om daarna deelvraag twee te  kunnen beantwoorden is wederom in het ‘lab’ met de grammatica die uit deelvraag  één naar voren is gekomen een ontwerp gemaakt in JSON-schema waarmee het  schrijven van correct geformatteerde regels in een JSON datastructuur kan worden  afgedwongen. Omdat de datastructuur de communicatie vormt tussen het expert  systeem en deze applicatie, zijn er initieel afzonderlijke ontwerpen gemaakt die  daarna met elkaar vergeleken zijn. De verschillen zijn bediscussieerd en gezamenlijk  is daarna tot een ‘definitief’ ontwerp gekomen. Dit ontwerp is vervolgens weer getest  door een set voorbeeldregels op te stellen in JSON en te toetsen aan het schema. Om  de laatste deelvraag te beantwoorden is in de ‘werkplaats’ een eerste prototype van  de applicatie gebouwd met enkele user-interface elementen om een regel te kunnen  opstellen. Deze applicatie is vervolgens met een kleine instructie aan een aantal  niet-developers van Nerds & Company gegeven, om te valideren dat zij met de  interface een regel kunnen bouwen. Op basis van de uitkomsten van deze ‘lab’ test  zijn in de ‘werkplaats’ verbeteringen in het ontwerp aangebracht en de uiteindelijke  applicatie ontwikkeld waarmee de onderzoeksvraag beantwoord wordt. 

3.5. Projectgrenzen 

De duurtijd van het project is zoals reeds vermeld 20 weken, deze vindt plaats van  10-02-2020 t/m 03-07-2020. Waarbij de laatste twee weken gereserveerd zijn ter  beoordeling van het afstudeerportfolio. De doelstelling van het project is het  realiseren van een applicatie waarin gebruikers zonder technische achtergrond,  regels kunnen opstellen voor het toekennen van beloningen aan gebruikers op  internetplatforms. Een duidelijke grens die hierbij gemarkeerd kan worden, is dat  voor de daadwerkelijke implementatie van een werkend systeem waarmee deze  beloningen toegekend kunnen worden, er in de bestaande e-learning platforms nog  de functionaliteit ingebouwd zal moeten worden voor het genereren en versturen  van events. Omdat dit een verkennend project is valt dat buiten de scope. Om het  domein waarin gewerkt wordt te visualiseren en daarin de afbakening van de  opdracht duidelijk weer te geven is de volgende schematische weergave van het  domein getekend: 

 

 

Afbeelding 3.1 Domein   

Regel Configuratie Applicatie 

Het ontwikkelen van deze applicatie is de opdracht van dit afstudeerproject. De  applicatie dient een vertaalhulp te zijn voor niet-developers bij het opstellen van  regels voor het toekennen van beloningen aan gebruikers op internetplatforms. De  grafische user interface moet de gebruiker in staat stellen regels op te stellen, waarna  de applicatie de regels kan exporteren in een datastructuur, welke geïnterpreteerd  kan worden door het expertsysteem.  

 

Expertsysteem 

Het expertsysteem beschikt over een set regels die in de regel configuratie applicatie  voor een Nerds & Company Cloud Platform opgesteld zijn. Met deze regels in het  geheugen kan het expertsysteem, aan de hand van een reeks events die verzonden  worden vanuit het platform, controleren of aan de voorwaarden van een regel 

voldaan wordt. Als dat het geval is kan het expertsysteem een event terugsturen naar  het platform, met de informatie welke regel is ‘af gegaan’ en welke gebruiker het om  gaat. Hierna kan het platform de beloning aan de gebruiker uitkeren. Deze applicatie  wordt door een student van Hogeschool Windesheim als afstudeerproject 

ontwikkeld.   

Nerds & Company Cloud Platforms 

Dit zijn de platforms die Nerds & Company ontwikkeld voor haar klanten, dit zijn  onder andere e-learnings, een machinestatus monitor en e-commerce. De platforms  worden in de cloud gehost bij Heroku en zij sturen events naar het expertsysteem in   

verschillende situaties, bijvoorbeeld wanneer gebruikers inloggen of een doel 

behalen. Tevens kunnen de platforms ook events van het expertsysteem ontvangen,  zodat zij op de hoogte gesteld kunnen worden wanneer ze een beloning moeten  uitreiken. Het gaat in eerste instantie om e-learning platforms waar gebruikers  beloningen krijgen na het behalen van een doel, maar het bedrijf wil dat bij de 

realisatie rekening gehouden wordt met eventuele toekomstige toepassing op onder  andere, een machine status monitor en e-commerce. 

 

Binnen scope  Buiten scope 

Een geschikte definitie voor regels onderzoeken 

en opstellen.  Onderzoeken hoe beloningen toegekend kunnen worden.  Ontwerpen van een geschikte datastructuur 

waarin de regels kunnen worden opgeslagen.  Een systeem ontwikkelen dat beloningen kan toekennen.  Realiseren van een applicatie waarin een 

gebruiker zonder technische achtergrond  regels kan opstellen en beheren. 

Een systeem ontwikkelen dat  events kan monitoren 

Testen van de applicatie tijdens de 

implementatiefase.  Doorontwikkeling en nazorg aan de gerealiseerde producten.  Opleveren van afstudeerportfolio met 

technische documentatie, een afstudeerverslag  en de gerealiseerde code. 

 

Tabel 3.1 Afbakening 

4. Onderzoeksresultaten 

In dit document zijn de resultaten van de deelvragen samengevat. Het onderzoeks  document dat is opgeleverd bevat een uitgebreide uitwerking van iedere deelvraag  en voor de verklaring van eventuele onduidelijkheden, die vanwege de 

samenvattende wijze waarop dit hoofdstuk is geschreven ontstaan, wordt 

geadviseerd het hoofdstuk ‘Onderzoeksresultaten’ in het onderzoeksdocument te  raadplegen. 

4.1. “Welke regels moeten er kunnen worden opgesteld 

in het systeem?” 

Om te bepalen welke regels er moeten kunnen worden opgesteld in het systeem is  het van belang om eerst te kijken wat een regel is en op welke manier deze 

geïnterpreteerd kan worden door een expertsysteem. Expertsystemen gebruiken  menselijke expertkennis om problemen op te lossen, die normaalgesproken opgelost  worden door menselijke intelligentie​[12]​_{. In de context van deze opdracht kan dat}  vertaald worden naar het feit dat een mens, vanwege zijn natuurlijke begrip voor  semantiek, aan een geschreven regel gemakkelijk kan zien wat de voorwaarden en  eventuele gevolgen zijn die daarbij horen. Deze kennis zal dus vertaald moeten  worden naar een weergave die een computer kan interpreteren. Zo’n vertaling kan  gedaan worden met zogenaamde business rules of ook wel production rules, dit zijn  regels waarvan de voorwaarde, of ook wel ‘antecedent’, altijd als ‘waar’ of ‘onwaar’  geëvalueerd kan worden​[8]​_{, waarna het gevolg, of ook wel ‘consequent’, wel of niet zal}  worden uitgevoerd. Production regels kunnen met de volgende grammatica ontleed  worden​[13]​_: 

 

<production rule> ::= ​if​ <antecedent> ​then​ <consequent> ​fi  <antecedent> ::= <disjunction> {​and​ <disjunction>}∗ 

<disjunction> ::= <condition> {​or​ <condition>}∗  <consequent> ::= <conclusion> {​also​ <conclusion>}∗  <condition> ::= <predicate>(<variable>,<constant>)  <conclusion> ::= <action>(<variable>,<constant>)  <predicate> ::= same | notsame | greaterthan | . . .  <action> ::= add | remove | . . . 

 

Om te valideren dat de regels waarmee binnen het domein gewerkt wordt voldoen  aan bovenstaande criteria, is een set van relatief simpele tot vrij complexe regels  samengesteld in de volgende tabel: 

   

 

Regels e-learning 

1.  Als een gebruiker een doel behaalt krijgt hij een beloning. 

2.  Als een gebruiker twee keer een doel behaalt krijgt hij een beloning.  3.  Als een gebruiker als eerste een doel behaalt krijgt hij een beloning. 

4.  Als een gebruiker voor een datum een doel behaalt krijgt hij een beloning.  5.  Als een gebruiker een doel behaalt binnen een periode krijgt hij een beloning.  6.  Als een gebruiker drie keer een doel behaalt binnen een periode krijgt hij een 

beloning. 

7.  Als twee gebruikers van een team een doel behalen krijgt het team een beloning.  8.  Als de gebruikers van een team vaker dan vijf keer een doel behalen binnen een 

periode krijgt het team een beloning. 

Tabel 4.1 Regels e-learning   

Het bedrijf heeft als requirement voor de implementatie van deze opdracht, dat de  applicatie, naast de reeds beschreven e-learnings, inzetbaar moet kunnen zijn voor  meerdere toepassingen die in het domein aanwezig zijn. Om te valideren dat de  implementatie van het systeem ook met regels voor de machinestatus monitor en  e-commerce overweg kan, is een kleine set regels gedefinieerd: 

 

Regels machinestatus monitor & e-commerce 

1.  Als een machine een minuut geen status bericht heeft verzonden krijgt hij een  korte storing 

2.  Als een machine een half uur geen status bericht heeft verzonden en hij heeft  een korte storing krijgt hij een lange storing. 

3.  Als een machine een storing heeft en hij verzendt een statusbericht krijgt hij een  groene status. 

4.  Als een klant een bestelling plaatst van meer dan €100,- krijgt hij een  kortingscode. 

5.  Als een klant twee keer een bestelling plaatst in één maand krijgt hij op de  volgende bestelling 50% korting. 

6.  Als een klant twee maanden lang geen bestellingen plaatst krijgt hij een  herinneringsmail. 

Tabel 4.2 Regels machinestatus monitor & e-commerce   

Met deze collectie van regels kan gekeken worden of de regels binnen het domein  voldoen aan het principe van een productieregel: 

 

  Afbeelding 4.1 Regel 1 volgens statement    

Volgens bovenstaande afbeelding is direct duidelijk dat deze regel voldoet aan het  productieregel principe, echter dient deze verder ontleed te worden om te zien welke 

data tussen het platform en het expertsysteem middels events. Deze events zullen  dus data moeten bevatten waaraan afgeleid kan worden dat de antecedent waar is. 

 

Afbeelding 4.2 Antecedent eenvoudige regel ontleed    Als de antecedent van de eerste regel verder ontleed wordt komen daar twee 

zogenaamde condities uit die beide een predicaat bevatten met daarbij een variabele  of een constante. Deze predicaten hebben betrekking op het event dat ervoor kan  zorgen dat het expertsysteem kan controleren of er aan de antecedent van deze  regel voldaan wordt; dat event moet namelijk een user_id bevatten en van het type  “completed_goal” zijn.  

 

Een zelfde analyse kan gemaakt worden van een complexere regel: 

Afbeelding 4.3: Complexe regel ontleed 

 

Hier is direct te zien dat de antecedent een stuk complexer is dan de vorige regel,  wanneer deze verder ontleed wordt is dat nog beter te zien: 

 

Afbeelding 4.4 Antecedent complexe regel ontleed   

Deze antecedent kan, afgeleid van de predicaten, ook als volgt uitgeschreven  worden:  

 

Er moet van start_date tot end_date vaker dan vijf keer een event voorkomen met  type “completed_goal” welke een user_id bevat en een overeenkomend team_id 

 

Nu de antecedenten van een tweetal regels ontleed zijn, is duidelijk te zien dat er  verschillende predicaten nodig zijn voor het vergelijken van events en de data die zij  bevatten. Op basis van de set voorbeeld regels kan gesteld worden dat event data  vergeleken moet kunnen worden op basis van: 

- Relationele operatoren, bij het vergelijken van waardes 

- Tijd, wanneer het moment waarop iets gebeurd van belang is 

- Herhaling, wanneer het van belang is dat iets vaker (of juist niet) voorkomt   

Relationele operatoren 

Wanneer waardes vergeleken moeten worden met elkaar, bijvoorbeeld of een  gebruiker die inlogt ouder is dan 18 (​greaterThanOrEquals(age, 18)​).  

Of wanneer het twee events moeten zijn die door leden van hetzelfde team zijn  afgevuurd (​equals(team_id)​). De relationele operatoren die binnen het systeem als  predicaat gebruikt moeten kunnen worden zijn: 

- Equals  - Not equals  - Greater than  - Less than 

- Greater than or equals  - Less than or equals 

  Tijd 

Bij het werken met tijd kunnen drie verschillende ‘soorten’ tijd vastgesteld worden,  iets kan voor of na een datum plaatsvinden, iets kan in een periode tussen twee  datums plaatsvinden of iets kan in een periode van een tijdseenheid plaatsvinden,  bijvoorbeeld iedere minuut, dag, week of jaar. Meten of een event voor of na een  datum voorkomt kan gedaan worden met de relationele operatoren; greaterThan en  lessThan, en het meten van een periode tussen twee datums kan met een 

combinatie van beide. Definiëren of iets in een periode van een tijdseenheid  plaatsvindt is een stuk complexer, het starten van die periode kan door meerdere  triggers veroorzaakt worden: 

- Een periode wordt gestart door een of meerdere events, bijvoorbeeld als een  gebruiker ergens aan begint. De periode eindigt wanneer aan de einde  voorwaarden voldaan wordt of wanneer de timer afloopt. 

- Een periode wordt gestart doordat een nieuwe week begint en eindigt  wanneer de week voorbij is. 

- Een periode wordt gestart voor een bepaalde tijd, bijvoorbeeld 10 dagen, en  eindigt wanneer de 10 dagen voorbij zijn. 

De eerste komt terug in regel 6 in tabel 4.1 : ​“Als een gebruiker drie keer inlogt in een 

periode krijgt hij een beloning”.​ Hierbij zal de periode beginnen wanneer er een 

verstrijkt. Bij de antecedent: ​“Als een gebruiker in een week de meeste doelen 

behaalt”, ​wordt iedere zaterdag of zondag (afhankelijk van wanneer de week nieuwe 

begint) om 23:59, de gebruiker gekozen en begint de periode overnieuw. Als de  antecedent niet ​“in een week” ​maar ​“in zeven dagen” ​zou zijn zou iedere zeven  dagen de periode opnieuw beginnen, vanaf de start van de eerste periode.​ ​Om deze  drie vormen te kunnen implementeren zullen een drietal predicaten toegevoegd  moeten worden aan de reeds bestaande lijst van relationele operatoren 

- Duration 

Deze krijgt als argumenten startvoorwaarden, eindvoorwaarden en een tijd  mee, waarbinnen aan de alle voorwaarden voldaan moet worden. 

- Time unit 

Deze krijgt als argument een tijdseenheid als interval mee, bijvoorbeeld dag,   week of maand en voorwaarden waaraan voldaan moet worden binnen de  tijdseenheid 

- Period 

Deze krijgt als argument een periode als interval mee, dus bijvoorbeeld tien  dagen en voorwaarden waaraan voldaan moet worden binnen de tijdseenheid   

Herhaling 

In de regels: ​“Als een gebruiker twee keer een doel behaalt krijgt hij een beloning” ​of 

“Als een klant twee keer een bestelling plaatst in één maand krijgt hij op de  volgende bestelling 50% korting”​, komt herhaling voor. De laatste regel is eerder al 

ontleed waarbij het predicaat ​counts​ naar voren kwam, met counts kan herhaling  vastgesteld worden, hiervoor kan het volgende predicaat toegevoegd worden: 

- Counts 

Deze krijgt als argument een event mee en het aantal keer dat deze voor moet  komen. 

 

Als laatste predicaat is er nog ​contains​, dit is niet per sé een predicaat waarmee data  vergeleken kan worden, die afdwingt wanneer iets plaatsvindt of die herhaling  impliceert, maar die valideert of een bepaalde waarde voorkomt in het event. Als een  regel betrekking heeft op een gebruiker verwacht het systeem op z’n minst dat het  event een user_id bevat. 

 

Terugkijkend naar de definitie van een regel bevat deze ook op antecedent en  consequent niveau operatoren: 

 

<antecedent> ::= <disjunction> {​and​ <disjunction>}∗  <disjunction> ::= <condition> {​or​ <condition>}∗  <consequent> ::= <conclusion> {​also​ <conclusion>}∗   

De ​and​ (​&&​) en de ​or​ (​||​) operators kunnen hier onderscheiden worden, dit zijn geen  relationele operatoren maar logische operatoren, logische operatoren worden 

gebruikt om simpele statements aan elkaar te koppelen waardoor het geheel geldig 

is wanneer één van de statements true is (​or​), of alle statements true zijn (​and​). Om  het ​and​ keyword te kunnen realiseren, dient de datastructuur een array van condities  te bevatten die allemaal ​true​ moeten zijn om aan de antecedent te voldoen. In  overleg met de opdrachtgever, om tijd te besparen tijdens de initiële ontwikkeling  van dit project, is ervoor gekozen om de ​or​ operator niet te implementeren, omdat  dit feitelijk hetzelfde is als het schrijven van losse regels met verschillende 

antecedents en overeenkomende consequents. Wanneer aan een antecedent  voldaan wordt kan er een enkele conclusion in de consequent zitten, bijvoorbeeld bij  de eerdere regel; ​“als een gebruiker een doel behaalt krijgt hij een beloning”,​ maar  het is logisch dat er ook regels kunnen zijn waar meerdere conclusions in de 

consequent zitten. Het keyword ​also​ dwingt dit af en zorgt ervoor dat bij het  schrijven van de datastructuur, de consequent een array van conclusions zal  bevatten. Een conclusion bestaat uit een action met een variabele: 

 

<conclusion> ::= <action>(<variable>,<constant>)   

In de context van een e-learning platform zou bijvoorbeeld het geven van een badge  de action kunnen zijn, en de user_id van de gebruiker de variabele. Omdat de 

consequent uit één of meerdere conclusions bestaat is het ook mogelijk om de  gebruiker een beloning te geven, maar evengoed het team waar hij onderdeel van is  een andere beloning. 

4.2. “Welke datastructuur is geschikt voor het opstellen 

van dergelijke regels?” 

Er is een datastructuur nodig waarin de regels die opgesteld worden door een  gebruiker in de grafische user interface kunnen worden opgeslagen, zodat deze  geïnterpreteerd kunnen worden door een expertsysteem. Voor het definiëren van  zo’n datastructuur zijn diverse schema standaarden beschikbaar waarvan XML​[14]​_,  YAML​[15]​ _{en JSON Schema​}[16]​ _{de meest voor de hand liggende zijn. Voor ieder van deze}  zijn diverse schema validators beschikbaar in diverse programmeertalen. Vanwege  de leesbaarheid valt XML voor het bedrijf direct al af, omdat er in XML veel ‘overhead’  nodig is om declaraties te kunnen doen, te zien in onderstaande afbeelding: 

 

 

Hierdoor is het schema op zichzelf moeilijk leesbaar, van de overgebleven leesbare  kandidaten wordt binnen het bedrijf JSON het meest gebruikt, vandaar dat de keus  hierop is gevallen. 

 

Om een dergelijk schema op te kunnen zetten zijn een aantal keys nodig​[17]​_:  - $schema

Het ​$schema​ keyword betekent dat het schema geschreven is naar de  specifieke versie van de standaard die is gebruikt in de value van​ $schema​.  - $id

Definieert een URI voor het schema, ofwel de plaats op het wereldwijde web  waar het schema gedefinieerd is, alle verdere URI referenties binnen het  schema zijn extensies van deze URI. 

- title & description

Deze keywords zijn descriptief, ze voegen geen constraints toe aan de data die  gevalideerd wordt maar verduidelijken het doel van het schema. 

- type

Dit is het eerste constraint voor het schema en in dit geval dient het een JSON  object te zijn. 

 

{

"$schema": ​"http://json-schema.org/draft-07/schema#"​,

"$id": _​"http://github.com/nerds-and-company/rewarden-specifications/schema.json"_​, "title": ​"Rule schema"​,

"description": ​"A schema to which rules for the Rewarden system must resolve"​, "type":​ "object"

}  

Vervolgens kan aan het schema de key properties​[18]​ _{toegevoegd worden, alle keys die} 

in properties gedefinieerd staan, worden getoetst op aanwezigheid in het object dat  tegen het schema gevalideerd wordt. Met de eerste property key; ​name​, kan 

aangegeven worden om welke regel het gaat, name heeft een beschrijvende functie,  zodat duidelijk is wat er in de verdere definitie staat. Met de key; ​version​ kan 

bijgehouden worden welke versie van de regel het is, hierdoor kunnen in de 

toekomst mogelijke wijzigingen van regels bijgehouden worden. In het resultaat van  de eerste deelvraag is reeds naar voren gekomen dat een regel bestaat uit een  antecedent met één of meerdere voorwaarden en een consequent met één of  meerdere acties. Deze keys zijn dan ook als type array gedefinieerd. Beide array’s  hebben verder de keys ​"contains"​ en ​"items"​. Contains dwingt af dat de array  tenminste één object bevat waarnaar gerefereerd wordt en items dwingt af dat alle  objecten in de array van het type zijn waarnaar gerefereerd wordt.​ Verder heeft iedere  regel minimaal één antecedent en één consequent nodig om van nut te zijn, dit  wordt afgedwongen met de key ​"minItems": 1​. 

"properties": {

"name": { "type": _​"string"_​ },

"version": { "enum": [_​"0.1"_​] }, "antecedents": { "type": ​"array"​, "contains": { "$ref": ​"#/definitions/requiredAntecedent" },

"items": { "$ref": ​"#/definitions/antecedent"​ }, "minItems": _​1 }, "consequents": { "type": ​"array"​, "contains": { "$ref": ​"#/definitions/action" },

"items": { "$ref": ​"#/definitions/action"​ }, "minItems": _​1

} },

"additionalProperties": _​false_​,

"required": [​"name"​, ​"version"​, ​"antecedents", "consequents"​]

Als laatste is voor het schema nog gedefinieerd dat, behalve de keys in de  "properties"​, geen andere keys gedefinieerd mogen worden middels 

"additionalProperties": false​. Tevens zijn ook alle keys uit ​"properties"​ verplicht.   

De basis van een regel is nu in het schema gedefinieerd, vervolgens is gekeken hoe  de events, operaties op de data daarin, tijdsgebonden voorwaarden en herhalingen in  het schema gedefinieerd kunnen worden. Om de herbruikbaarheid van objecten  binnen het schema te vergroten en daarmee herhalende declaraties te vermijden  hebben de makers van JSON-schema het keyword ​"definitions"​ geïntroduceerd.  Hierin kunnen alle sub-schema’s van het schema gedefinieerd worden zodat ze  middels een referentie met de key ​"$ref"​ herbruikbaar zijn. 

"definitions": { "requiredAntecedent": { "type": ​"object"​, "oneOf": [ { "$ref": ​"#/definitions/antecedents/event"​ }, { "$ref": ​"#/definitions/antecedents/duration"​ }, { "$ref": _​"#/definitions/antecedents/period"_​ }, { "$ref": ​"#/definitions/antecedents/time_unit"​ }, { "$ref": ​"#/definitions/antecedents/count"​ } ] }, "antecedent": { "type": ​"object"​, "oneOf": [ { "$ref": _​"#/definitions/requiredAntecedent"_​ },  

{ "$ref": ​"#/definitions/antecedents/greater_than"​ }, { "$ref": _​"#/definitions/antecedents/greater_than_or_equal"_​ }, { "$ref": ​"#/definitions/antecedents/less_than"​ }, { "$ref": ​"#/definitions/antecedents/less_than_or_equal"​ } ] } }

De definitions bevatten als eerste de verplichte antecedenten, op de vorige pagina  was al te zien dat de antecedenten array minimaal 1 van de verplichte antecedenten  bevat, door middel van het keyword ​contains​. De verplichte antecedenten zijn dan  ook de antecedenten die een event kunnen bevatten, omdat er zonder events geen  regels af kunnen gaan. Verder bevat het de definitie van een antecedent, welke uit  ieder van de predicaten kan bestaan die in deelvraag één naar voren gekomen zijn.   

"antecedents": { "event": {

"type": _​"object"_​, "properties": {

"type": { "const": ​"event"​ }, "name": { "type": _​"string"_​ }, "attributes": {

"type": ​"array"​,

"items": { "$ref": ​"#/definitions/eventAttribute"​ }, "minItems": 1

} },

"required": [​"type"​, ​"name"​, ​"attributes"​], "additionalProperties": _​false

} }  

Vervolgens zijn de individuele antecedenten gedefinieerd, de belangrijkste  antecedent die gedefinieerd is, is het event. Events hebben als properties: 

- type

Dit is een standaard property van alle antecedenten, hieraan kan het  expertsysteem onderscheiden om welke antecedent het gaat. 

- name

De naam van het event, bijvoorbeeld ​“logged_in” ​of ​“completed_goal”  - attributes

Metadata welke het event moet bevatten om de benodigde operaties voor de  regel te kunnen uitvoeren, dit is een referentie naar de hieronder 

gedefinieerde attributen.   

"eventAttributes": { "variable": {

"type": _​"object"_​, "properties": {

"type": { "const": ​"variable"​ }, "name": { "type": _​"string"_​ }, "key": { "type": ​"string"​ } },

"required": [​"type"​, ​"name"​, ​"key"​], "additionalProperties": _​false

},

"value": {

"type": ​"object"​, "properties": {

"type": { "const": ​"value"​ }, "name": { "type": ​"string"​ },

"value": { "type": [​"string"​, ​"number"​, "integer"​ ​, ​"boolean"​, ​"null"​] } },

"required": [​"type"​, ​"name"​, ​"value"​], "additionalProperties": ​false

} }

Een event kan variabelen en values bevatten, een voorbeeld van een variabele kan  bijvoorbeeld user_id zijn, die bij ieder event verschillend is. Maar ook een value, die  bijvoorbeeld kan valideren dat de gebruiker die het event afgevuurd heeft een  administrator is. Dit zou er in een regel als volgt uit kunnen zien: 

  "attributes": [{ "type": _​"variable"_​, "name": ​"user_id"​, "key": ​"x" }] "attributes": [{ "type": _​"value"_​, "name": ​"is_admin"​, "value": ​true }]

Duration is de volgende antecedent die in het schema gedefinieerd is en is in dit  document als voorbeeld genomen voor de andere verplichte antecedenten. Zoals  reeds vermeld heeft de duration een array van ​start_antecedents​, wanneer deze  antecedenten voorgekomen zijn begint de timer te lopen, de waarde van deze timer  wordt meegegeven in seconden in de value van de key ​interval​. Wanneer 

vervolgens alle ​end_antecedents​ voorkomen of wanneer de timer afloopt, wordt deze  gestopt. 

"duration"​: { "type": ​"object"​, "properties": {

"type": { "const": _​"duration"_​ },

"interval": { "type": ​"integer"​, "minimum": ​1​ }, "start_antecedents": {

"type": _​"array"_​,

},

"end_antecedents": { "type": ​"array"​,

"items": { "$ref": ​"#/definitions/antecedent"​ }, "minItems": ​1

} },

"required": [​"type"​, ​"interval", ​ ​"start_antecedents"​, ​"end_antecedents"​], "additionalProperties": ​false

}

Om dit te verduidelijken is hieronder een voorbeeld gedefinieerd van een regel waar  duration in voorkomt:    { "name": ​"completed_topic_in_30_minutes"​, "antecedents": [{ "type": ​"duration"​, "interval": ​1800​, "start_antecedents": [{ "type": _​"event"_​, "name": ​"started_topic"​, "attributes": [{ "type": ​"variable"​, "name": _​"user_id"_​, "key": ​"i" }] }], "end_antecedents": [{ "type": ​"event"​, "name": ​"finished_topic"​, "attributes": [{ "type": ​"variable"​, "name": ​"user_id"​, "key": ​"j" }] }] }] }

Kortgezegd wordt de timer gestart wanneer er een logged_in event binnenkomt met  een user_id en beëindigd wanneer er nog een logged_in event binnenkomt met  dezelfde user_id. Dit wordt afgedwongen door de equals antecedent die keys ​i​ & ​j  met elkaar vergelijkt. Wanneer de timer van 1800 seconden afloopt en de 

end_antecedent nog niet voldaan is wordt hij ook beëindigd. ​_{De antecedenten ​event​,} 

duration​, ​period​, ​time_unit​ & count behoren tot de verplichte antecedenten, omdat 

een regel ten minste één van deze moet bevatten, om op basis van de events die  uitgewisseld worden tussen een cloud platform en het expertsysteem, te kunnen  verifiëren of aan de antecedent van een regel voldaan wordt.  

  "antecedent": { "type": _​"object"_​, "oneOf": [ { "$ref": ​"#/definitions/requiredAntecedent"​ }, { "$ref": ​"#/definitions/antecedents/equal"​ }, { "$ref": _​"#/definitions/antecedents/not_equal"_​ }, { "$ref": ​"#/definitions/antecedents/greater_than"​ }, { "$ref": ​"#/definitions/antecedents/greater_than_or_equal"​ }, { "$ref": ​"#/definitions/antecedents/less_than"​ }, { "$ref": _​"#/definitions/antecedents/less_than_or_equal"_​ } ] }

Omdat deze antecedenten allemaal operatoren zijn is de definitie in de specificatie  vergelijkbaar. Hieronder is een voorbeeld van de ​equal​ antecedent gedefinieerd  welke beschikt over de volgende property keys: 

- type

Dit is wederom de antecedent type specificatie waardoor het expertsysteem  bij het interpreteren van de regel kan vaststellen welke operatie er verricht  moet worden 

- compares

Een array van ​compareAttributes​ waarop de operator moet worden toegepast  Deze attributen worden op de volgende pagina verder gespecificeerd.

"​equal​"​: {

"type": ​"object"​, "properties": {

"type": { "const": ​"equal"​ }, "compares": {

"type": ​"array"​,

"items": { "$ref": _​"#/definitions/compareAttribute"_​ }, "minItems": ​2

} },

"required": [_​"type"_​, _​"compares"_​], "additionalProperties": ​false

}

De compareAttributes zoals hieronder gespecificeerd bevatten variabele of gegeven  waardes, vergelijkbaar met de manier waarop dit in de eventAttributes voorkomt.  Echter worden voor de compareAttributes alleen de keys ​type​, ​key​ en ​value  gedefinieerd: 

- type

Definitie van het type compareAttribute, dit kan ​variable​ of ​value​ zijn, hieraan 

- key

In het geval van een variable heeft deze een key, de key is een verwijzing naar  een eventAttribute welke vergeleken moet worden. 

- value

Het kan ook mogelijk zijn dat een eventAttribute vergeleken moet worden  met een vaste waarde, hiervoor is value toegevoegd, deze kan bestaan uit een  string, een getal, boolean waarde of null. Null kan gebruikt worden wanneer  een eventAttribute niet voor mag komen. 

 

Om de functionaliteit van compareAttributes te verduidelijken is op de volgende  pagina een voorbeeld gedefinieerd. 

  "​compareAttribute​"​: { "type": _​"object"_​, "oneOf": [ { "$ref": ​"#/definitions/compareAttributes/variable"​ }, { "$ref": ​"#/definitions/compareAttributes/value"​ }, ] }, } "_​compareAttributes_​"_​: { "variable": { "type": ​"object"​, "properties": {

"type": { "const": _​"variable"_​ }, "key": { "type": ​"string"​ } },

"required": [_​"type"_​, _​"key"_​], "additionalProperties": ​false

},{

"value": {

"type": _​"object"_​, "properties": {

"type": { "const": ​"value"​ },

"value": { "type": [​"string"​, ​"number"​, "integer"​ ​, ​"boolean"​, ​"null"​] } },

"required": [​"type"​, ​"value"​], "additionalProperties": ​false

}, } 

 

Stel dat de volgende regel actief is voor een cloud platform binnen het domein:   

“Als iemand inlogt die achttien jaar of ouder is, krijgt hij een beloning”   

Het expert systeem zal dan, op het moment dat er een ​“logged_in”​ event 

binnenkomt moeten vergelijken of het eventAttribute age, een waarde heeft die  groter dan of gelijk aan 18 is. Dit zal in de datastructuur als volgt gedefinieerd kunnen  worden:  { "name": ​"logged_in_older_than_18"​, "antecedents": [{ "type": ​"event"​, "name": _​"logged_in"_​, "attributes": [{ "type": ​"variable"​, "name": ​"user_id"​, "key": _​"i" },{ "type": ​"variable"​, "name": _​"age"_​, "key": ​"j" }] },{ "type": _​"greater_than_or_equal"_​, "compares": [{ "type": ​"variable"​, "key": ​"j" },{ "type": ​"value"​, "key": ​18 }] }] }

Het expertsysteem verwacht voor deze regel dus een “logged_in” event met een  user_id​ en ​age​ als metadata variabelen en zal vervolgens de operatie 

“greater_than_or_equal” uitvoeren op de waarde in de variabele met ​"key": "j" ​en  het getal 18. Vanzelfsprekend zullen andere operaties op een vergelijkbare manier  geïmplementeerd worden. 

 

Het laatste onderdeel van de datastructuur is de consequents property. In deelvraag  één is duidelijk geworden dat wanneer aan de voorwaarden van een regel voldaan  wordt, er één of meerdere consequents kunnen zijn. Een gebruiker kan bijvoorbeeld  een beloning krijgen en tegelijkertijd het team waar hij in zit ook.  

  "consequents": { "type": ​"array"​, "contains": { "$ref": ​"#/definitions/action" },

"items": { "$ref": ​"#/definitions/action"​ },

Tevens is duidelijk geworden dat de consequent van een regel uit één of meerdere  acties kan bestaan, een dergelijke actie wordt door middel van een event door het  expertsysteem naar het platform gecommuniceerd en bevat de volgende properties: 

- type

Hieraan kan het platform herkennen dat het actie is die het terugkrijgt van het  expertsysteem 

- rule_name

Een referentie naar de naam van de regel die al eerder gedefinieerd is, 

hierdoor weet het platform bij welke regel de actie hoort, dit kan bijvoorbeeld  gebruikt worden voor het geven van een notificatie. 

- attributes

Dit zijn de attributen van de actie, deze kunnen per platform verschillen, een  e-commerce zal bijvoorbeeld een kortingscode als attribuut kunnen hebben  en een machine monitor een status attribuut. 

- targets

Hierin kunnen de entiteiten binnen het platform worden gespecificeerd die de  attributen toegewezen moeten krijgen.  

"action": {

"type": ​"object"​, "properties": {

"type": { "const": ​"action"​ }, "rule_name": { "$ref": ​"#/name"​ }, "attributes": {

"type": _​"array"_​,

"items": { "$ref": ​"#/definitions/actionAttribute"​ }, "minItems": ​1

},

"targets": { "type": ​"array"​,

"items": { "$ref": ​"#/definitions/actionAttribute"​ }, "minItems": ​1

} },

"required": [​"type"​,​ "rule_name", ​ ​"attributes"​, ​"targets"​], "additionalProperties": _​false

}

"actionAttribute": { "type": _​"object"_​, "properties": {

"type": { "type": ​"string"​ }, "id": { "type": ​"string"​ } },

"required": [_​"type"_​, _​"id"_​], "additionalProperties": ​false

} } 

De definitie van het actionAttribute op de vorige pagina, wordt ingezet voor zowel  het toevoegen van attributen als het toevoegen van targets aan de actie. Het gaat  hier namelijk om entiteiten binnen het cloudplatform waar de actie naartoe gestuurd  wordt. Een actionAttribute bevat de volgende keys: 

- type

Het type van de entiteit binnen het platform, in het geval van een attribute  kan dit bijvoorbeeld gaan om type ​badge​, ​certificate​, ​coupon​ of ​status​.  Wanneer het een target is kan dit bijvoorbeeld ​user_id​ zijn. 

- id

Het identificatienummer van het gespecificeerde type.   

Om het afstudeerverslag niet te lang te maken is in de bijlagen ter verduidelijking  een overzicht van het gehele schema bijgevoegd. 

4.3. “Aan welke voorwaarden moet de interface voldoen, 

zodat regels op een overzichtelijke en duidelijke manier 

door de gebruiker kunnen worden opgesteld?” 

Nu is onderzocht welke regels er opgesteld moeten kunnen worden en in welke  datastructuur deze opgeslagen kunnen worden, beslaat het laatste deel van het  onderzoek misschien wel het belangrijkste aspect van het systeem, de grafische user  interface, of kortweg GUI​[19]​_{. Hiermee worden namelijk niet-developers in staat} 

gesteld om regels te maken. Om te onderzoeken aan welke voorwaarden een  geschikte interface kan voldoen is eerst via Google gezocht naar voorbeelden van  reeds bestaande implementaties met voorwaarden en gevolgen, dit is gedaan met  de zoekterm ‘if then rule interface’. Een eerste voorbeeld dat hiervan gevonden is, is  de e-mail applicatie die standaard in macOS zit. Hierin kunnen regels opgesteld  worden voor het automatisch afhandelen van inkomend e-mailverkeer. Er kunnen  één of meerdere voorwaarden gesteld worden waaraan het inkomende 

e-mailverkeer moet voldoen. Deze voorwaarden kunnen bijvoorbeeld zijn dat het van  een bepaald domein afkomstig is of bepaalde content bevat. Vervolgens kunnen één  of meerdere acties gemaakt worden, om op het inkomende e-mailverkeer toe te  passen. Bijvoorbeeld het afspelen van een bijzondere notificatie, het inkomende  bericht te verplaatsen naar een bepaalde mailbox, of het te markeren als gelezen.  

Afbeelding 4.6 macOS email app  Wat opvalt is dat de gebruiker door de interface gedwongen wordt bepaalde keuzes  te maken, de gebruiker kan zelf invoeren waaraan de voorwaarde getoetst moet  worden, maar wordt gedwongen te kiezen of deze gedeeltelijk of geheel overeen  moet komen. Daarnaast kan de gebruiker alleen middels een dropdown kiezen uit  welke data van het e-mailbericht de voorwaarde getoetst kan worden, waarbij de  developers van Apple zelf hebben gevalideerd dat die data altijd aanwezig is in een  e-mailbericht. Ook kan een alleen een reeds bestaande mailbox geselecteerd worden  waar het bericht naartoe verplaatst moet worden. Hierdoor wordt met de inrichting  van de interface afgedwongen dat de gebruiker valide regels opstelt. 

 

In het analyseren van de grammatica van een regel in deelvraag 1 en het ontwerpen  van de datastructuur in deelvraag 2 is reeds naar voren gekomen dat alle 

communicatie tussen de platforms en het expertsysteem geschiedt op basis van  events. Hierdoor is in de datastructuur al te zien dat de verplichte antecedenten;  ‘event’ of ‘antecedenten waarin een event voorkomt’ zijn. Om middels de interface de  gebruiker te dwingen om tenminste één event in een regel te laten voorkomen, kan  door middel van het conditioneel renderen van elementen afgedwongen worden dat  een gebruiker eerst een verplichte antecedent kiest waarna overige mogelijkheden  beschikbaar worden.  

 

In de interface van ReWarden komt dit er als volgt uit te zien:   

  Afbeelding 4.7 ReWarden regels overzicht   

Het menu aan de linkerzijde bestaat uit de volgende drie keuzes:  - Events 

Hier kunnen events gedefinieerd worden die het cloud platform naar het  expertsysteem stuurt wanneer er een verandering van de state is, bijvoorbeeld  als een gebruiker inlogt of er een machine een status update stuurt, bij het  definiëren van een event kan de gebruiker metadata toevoegen waar, bij het  maken van regels, operaties op toegepast kunnen worden. 

- Actions 

Bij het opstellen van regels kan gekozen worden uit een vaste set acties die  van tevoren zijn gemaakt op de Actions pagina. Een action kan voor een  e-learning bijvoorbeeld het toekennen van een badge zijn, hierbij zal dan een  badge type gespecificeerd moeten worden en het target waar deze badge  aan toegekend kan worden, bijvoorbeeld een gebruiker of een team. In het  geval van een e-commerce kan een action het toekennen van een tegoedbon  zijn, met een tegoedbon type en een targettype. 

- Rules 

Dit is de pagina die te zien is in het voorbeeld waar de set regels die actief is  voor het platform beheerd kan worden. 

 

Afbeelding 4.8 ReWarden regel toevoegen modal 1

Door middel van conditioneel renderen zijn initieel alleen de nodige ‘if’ en ‘then’  velden zichtbaar. In het ‘if’ veld dient eerst één van de verplichte antecedenten, uit  deelvraag 2 gekozen te worden. Totdat dat gebeurt is zijn alle andere mogelijkheden  wel zichtbaar maar niet beschikbaar om aan te klikken, op deze manier wordt de  gebruiker onbewust gedwongen een valide regel op te stellen. Met het grote plus  teken aan de rechterzijde van het ‘If’ blok kunnen meerdere voorwaarden 

toegevoegd worden aan de regel, wanneer een voorwaarde nog niet compleet is, is  deze disabled. Hierdoor wordt de gebruiker gedwongen valide regels op te stellen.   

Wanneer vervolgens één van de verplichte antecedenten gekozen is worden de  velden getoond die bij die antecedent beschikbaar moeten zijn. In het voorbeeld is  bijvoorbeeld gekozen voor het antecedenttype ‘Event’. Hierna moet logischerwijs  gekozen worden om welk type event het gaat, in het voorbeeld zijn op de Events  pagina reeds drie events gedefinieerd, waaruit gekozen kan worden; logged_in,  started_subject en finished_subject. 

 

  Afbeelding 4.9 ReWarden regel toevoegen modal 2   

Een ander voorbeeld van een verplichte antecedent is duration, wanneer deze in de  dropdown geselecteerd wordt, toont de applicatie de velden die passen bij deze  antecedent, in de datastructuur kwam al naar voren dat een duration gestart kan  worden door het voorkomen van één of meerdere events, en beëindigd kan worden  doordat voorwaarden ofwel events voorkomen, waardoor de voorwaarde als true  geëvalueerd wordt. Tevens kan deze ook beëindigd worden wanneer de timer  afloopt. 

Op de volgende pagina is hiervan een voorbeeld te zien, als de duration geselecteerd  is worden de velden ‘Time in seconds’ ‘Started by’ en ‘Ended by’ getoond en kunnen  deze worden ingevuld. 

 

   

In bovenstaande afbeelding is ook het ‘Then’ blok duidelijk zichtbaar. Hier kunnen  één of meerdere acties aan toegevoegd worden met het grote plusteken aan de  rechterzijde. In de dropdown voor het selecteren van een actie kan gekozen worden  uit de acties die op de ‘Actions’ pagina gedefinieerd zijn. 

 

Wanneer de gebruiker een actie gekozen heeft, bijvoorbeeld het toekennen van een  badge, kan bij het kiezen van targets, gekozen worden uit de metadata die in één van  de events in de voorwaarden zit. Op deze manier wordt de gebruiker onbewust 

gedwongen een valide regel te maken.   

Als er tenminste één voorwaarde en één gevolg aan de regel zijn toegevoegd kan  deze opgeslagen worden. 

 

 

 

5. Ontwerp en realisatie 

Nadat in de onderzoeksfase de datastructuur en grafische user interface ontworpen  zijn kon de applicatie gerealiseerd gaan worden. Deze werkzaamheden hebben  plaatsgevonden in de realisatiefase, waarbij eerst een ontwerp gemaakt is van de  applicatie en vervolgens de realisatie gedaan is naar het ontwerp. In dit hoofdstuk  wordt het proces beschreven dat daarbij doorlopen is en worden de resultaten  gepresenteerd. 

5.1. Tools 

In de implementatiefase zijn er verschillende tools gebruikt om de ontwikkeling van  de applicatie te faciliteren. in dit hoofdstuk wordt kort behandeld welke tools er  gebruikt zijn en waarom juist voor deze tools gekozen is. 

5.1.1. VSCode[22] 

Bij aanvang van de opleiding werd voornamelijk Java software ontwikkeld in IntelliJ  van JetBrains, dit is een specifieke ‘integrated development environment’ of wel IDE,  voor Java applicaties. De applicatie voor dit project is in andere programmeertalen  ontwikkeld die het meest gebruikt worden bij de opdrachtgever. Daarom is gekozen  voor een IDE die meerdere programmeertalen ondersteund. Aangezien de 

meerderheid van de medewerkers binnen het bedrijf met VSCode werkt en daar  positief over zijn, is gekozen om dit project hiermee te realiseren. 

5.1.2. Git(Hub)[23] 

De opdrachtgever bewaart alle broncode van haar applicaties in GitHub repositories.  Daarom wordt versiebeheer voor de code van deze applicatie vanzelfsprekend ook in  een GitHub repository van het bedrijf gedaan zodat deze makkelijk overdraagbaar is  aan het einde van het project. 

5.1.3. Docker[24] 

Om er zeker van te zijn dat op de server waarop de appicatie gehost wordt, bij het  deployen van de applicatie de juiste dependencies geïnstalleerd worden, wordt de  applicatie tijdens de implementatiefase lokaal via Docker gerund. Docker is een tool  waarmee tijdens lokale ontwikkeling, middels zogenaamde ‘containers’ een Linux​[25]  server ge-emuleerd kan worden, waarop de applicatie gedraaid wordt. Op deze  manier kan een developer zelf configureren hoeveel processorkernen en geheugen  de applicatie tot zijn beschikking heeft. Hierdoor wordt de kans op eventuele fouten  bij het deployen op de server verkleind. 

5.2. Applicatie 

Voor het ontwerp van de applicatie worden een functioneel en technisch ontwerp  opgeleverd, vanwege de omvang van dit document is gekozen om hier een korte  toelichting op de gemaakte keuzes toe te voegen. 

5.2.1. Functionele toelichting 

Onderstaande tabel geeft de requirements weer die voor de ontwikkeling van de  applicatie zijn opgesteld. Gebaseerd op deze lijst zijn de userstories gemaakt die als  leidraad golden voor de ontwikkeling van het systeem. 

 

Requirements  Functioneel Prioritei

t 

1.  In het systeem moeten regels gedefinieerd kunnen worden.  F  M  2.  Het systeem moet als losstaande applicatie gedeployed 

kunnen worden.  F  M 

3.  Het systeem moet de gedefinieerde regels kunnen  exporteren zodat deze ingeladen kunnen worden in het  expertsysteem. 

F  M 

4.  Het systeem moet een grafische user-interface hebben.  NF  M  5.  De interface van het systeem moet ervoor zorgen, dat niet 

technisch onderlegde gebruikers, regels kunnen opstellen.  NF  M  6.  In het systeem zouden regels beheerd (opslaan en 

bewerken) moeten kunnen worden. 

F  S 

7.  Het systeem zou regels via het web moeten kunnen 

communiceren naar het expertsysteem  F  C 

8.  In de interface van het systeem zou, op basis van event  history, zichtbaar kunnen zijn hoe relevant de regel is die  gedefinieerd wordt. 

F  W 

9.  Het systeem zou in bestaande front-end frameworks (Vue, 

Angular, React) geïntegreerd moeten kunnen worden.  NF  W  Tabel 5.1 Requirements   

   

Op basis van de requirements is een algemeen use-case diagram gemaakt die laat  zien op welke wijze de gebruiker interactie kan hebben met de applicatie: 

 

Afbeelding 5.1 Use case diagram    Er zijn drie algemene interacties voor het beheren van events, acties en regels. Met  enkele screenshots wordt toegelicht hoe zo’n interactie in z’n werk gaat: 

  In het lijstoverzicht kan de gebruiker events, acties en regels beheren, er is een knop  voor het toevoegen, een delete knop voor het verwijderen, en een edit knop voor het