Comment Mapping

Comment Mapping

Afstudeeropdracht bij Liones

K.G.A. Ruis 13004948

De Haagse Hogeschool E.M. van Doorn

J.J. van der Hoek 01-06-2017

Referaat

Een onderzoek naar real-time collaboration met betrekking tot het plaatsen van opmerkingen binnen de XML editor FontoXML.

Rijswijk, Liones B.V., 2017

Afstudeerverslag geschreven door Koen Ruis, geschreven in het kader van het afstuderen van de opleiding Informatica aan de faculteit IT&Design aan De Haagse Hogeschool. Het verslag behandelt het onderzoek en ontwikkeling van een Proof of Concept dat is voltooid door Koen Ruis binnen zijn afstudeerperiode bij Liones B.V. te Rijswijk. Deze opdracht stond in het teken van real-time collaboration met betrekking tot het plaatsen van opmerkingen binnen de XML editor FontoXML.

Descriptoren: ● Afstudeerverslag ● Kwalitatief onderzoek ● UML ● C# ● ASP.NET MVC

Voorwoord

Dit document is geschreven door Koen Ruis. Op het moment van het schrijven van dit document ben ik een student aan De Haagse Hogeschool. Hier doe ik een opleiding Informatica, waarbij dit mijn afstudeeropdracht is. Voor deze opdracht heb ik onderzoek gedaan naar Comment Mapping binnen FontoXML.

Voor deze opdracht heb ik 17 weken lang onderzoek gedaan bij Liones. Dit is een bedrijf wat zich focust op het ontwikkelen van een webbased XML editor genaamd FontoXML. Bij FontoXML heb ik een onderzoek verricht naar het plaatsen van opmerkingen. Hierbij moet het mogelijk worden om met meerdere personen op hetzelfde moment opmerkingen te plaatsen.

Hierbij wil ik ook enkele mensen bedanken die mij in enige vorm hebben geholpen bij het opstellen of verbeteren van dit document. Dit zijn Bert Willems en Marijn van Butselaar vanuit FontoXML en Ed van Doorn en Cobie van der Hoek vanuit De Haagse Hogeschool. Tevens wil ik Youri Bosselaar, Erik van Leeuwen en Martin Middel bedanken voor de medewerking aan de interviews die ik binnen mijn onderzoek heb afgenomen.

Inhoudsopgave

Inleiding 1

1. FontoXML 2

1.1 Situatie vooraf 2

1.2 Student binnen FontoXML 4

2. Probleembeschrijving 6 2.1 Opdracht 7 3. Aanpak 8 3.1 Onderzoeksaanpak 8 3.2 Ontwikkelmethodiek 8 3.3 Tests 11 3.4 Planning 14 3.5 Risico’s 14 3.6 Technieken 15 4. Analyse 16 4.1 Oriëntatie 16 4.2 Onderzoek 18 4.3 Requirements 32 5. Ontwerp 36 5.1 Algoritmes 36 5.2 XML structuur 38 5.3 Scenario’s 39 5.4 Database ontwerp 43 5.5 Architectuur 44 6. Uitvoering 45 6.1 Prototype 45 6.2 Testen 47 7. Conclusie 49 8. Evaluatie 50 8.1 (Tussen)producten 50 8.2 Beroepstaken 52 Literatuurlijst 53 Achtergrondinformatie 54 Afkortingenlijst 54 Woordenlijst 54

Bijlagen 55

Bijlage A. Organogram 55

Bijlage B. Strokenplanning 56

Bijlage C. User Requirements 57

Inleiding

In dit document wordt mijn onderzoek naar Comment Mapping besproken. Als

afstudeeropdracht heb ik zeventien weken lang onderzoek gedaan naar het behoud van de locatie van opmerkingen. Eerst heb ik een onderzoek gedaan voor het vinden van een bepaalde techniek om deze opmerkingen te plaatsen en op te slaan. Vervolgens heb ik met het resultaat van het eerste onderzoek een onderzoek gedaan naar verdere technieken om deze methode te ondersteunen.

Na het onderzoek ben ik aan de slag gegaan met het ontwikkelen van een Proof of Concept in de vorm van een prototype. Hiervoor heb ik eerst een ontwerp gemaakt. Een belangrijk onderdeel binnen dit ontwerp was het beschrijven van veel verschillende scenario’s waarop een document kan wijzigen. Op basis van het ontwerp heb ik een prototype ontwikkeld. Na de ontwikkeling heb ik dit prototype getest en tenslotte heb ik een advies gegeven over het mogelijke vervolg van dit project.

1. FontoXML

FontoXML is een bedrijf dat zich richt op het maken van een XML editor waar auteurs in een gebruiksvriendelijke omgeving teksten kunnen schrijven. De documenten die de auteurs schrijven kunnen semantische waarden bevatten doordat er gebruik wordt gemaakt van XML, maar de auteurs hoeven geen kennis te hebben van XML om deze documenten te schrijven. Het product draagt dezelfde naam als het bedrijf, FontoXML.

Het bedrijf is ontstaan vanuit Liones, dat momenteel partner van FontoXML is. Liones houdt zich bezig met het ontwikkelen en onderhouden van websites. Na een vraag van een klant van Liones, is er begonnen aan een nieuw product. Dit product werd uiteindelijk FontoXML, dat naast deze klant bij meer organisaties verkocht kon worden.

Binnen Liones zijn er twee losse teams gevormd. Eén team richt zich op de ontwikkeling en implementatie van FontoXML, terwijl het andere team zich bezighoudt met de oude gang van zaken binnen Liones. Echter, het is wel mogelijk dat mensen binnen de organisatie werk verrichten voor beide teams.

1.1 Situatie vooraf

FontoXML is een tekstverwerker gebaseerd op XML, maar is te gebruiken zonder kennis te hebben over XML. Het heeft een gebruiksvriendelijke uitstraling waarmee gebruikers teksten kunnen schrijven met de juiste semantische waarden. FontoXML combineert de structuur van XML met de gebruiksvriendelijkheid van traditionele tekstverwerkers zoals Microsoft Office Word en Google Docs.

1.1.1 Structuur

De klanten die gebruik maken van FontoXML produceren documenten. Deze documenten worden nog altijd gemaakt met Microsoft Office Word. Echter, het is moeilijk om voor iedere werknemer binnen een bedrijf dezelfde stijl en structuur af te dwingen. Dit is wel mogelijk binnen de tekstverwerker van FontoXML.

De tekstverwerker maakt gebruik van XML schema’s. Een schema legt vast welke elementen binnen een document gebruikt kunnen worden. Ook legt een schema vast hoeveel een bepaald element gebruikt mag worden binnen het document of een bepaald deel hiervan. Door deze restricties dwingt de XML een vooraf bepaalde structuur af waar het document constant aan voldoet.

Naast het afdwingen van een structuur is het ook mogelijk om delen van een document pas later toe te voegen. Dit betekent dat er bijvoorbeeld aan het einde van het proces nog een deel kan worden toegevoegd met juridische informatie of andere zaken waar de auteur zelf niet verantwoordelijk voor is. De organisatie is in staat om deze informatie later aan het document toe te voegen voordat het document gepubliceerd wordt.

1.1.2 Opmaak

Consistente opmaak is belangrijk voor een bedrijf. Bij grote organisaties kan het lastig zijn om iedereen gebruik te laten maken van de nieuwste stijlen van documenten. Oudere werknemers gebruiken bijvoorbeeld een manier die zij gewend zijn van enkele jaren

geleden, een ander is in staat om een oud logo te gebruiken of een nieuwe werknemer weet nog niks van de huisstijl af en maakt zelf maar iets op basis van wat hij eerder gezien heeft. De problemen die hierboven beschreven staan, zijn opgelost binnen FontoXML. Bij het schrijven van documenten is het namelijk niet mogelijk om een huisstijl door te voeren, dit wordt pas later toegepast. De opmaak die beschikbaar is voor de gebruiker is afhankelijk van de organisatie waar hij het document voor schrijft. Elke klant kan in het schema zelf vastleggen welke mogelijkheden beschikbaar zijn binnen de FontoXML editor.

Ieder schema kan weer andere restricties hebben voor de gebruiker, de mogelijkheden die wel beschikbaar zijn, zijn terug te zien in de editor. In figuur 1.1 is een voorbeeld van de startbalk te zien waarin enkele mogelijkheden beschikbaar zijn voor het wijzigen van de opmaak van het document.

Fig 1.1. Balk aan de bovenkant van de tekstverwerker met de beschikbare opties voor opmaak.

Door de opmaak van een document los te trekken van het schrijven ervan is de klant in staat om een consistente stijl door te voeren die wordt toegepast op alle geproduceerde

documenten. Een organisatie hoeft zich met FontoXML geen zorgen meer te maken over documenten met een inconsistente stijl en kan een aparte afdeling inrichten voor het ontwikkelen en beheren van stijlen voor documenten.

1.1.3 Vergrendelen

Het is voor de klanten van FontoXML belangrijk dat er door meerdere personen aan een document gewerkt kan worden. Binnen een eenvoudige workflow van schrijven - review - publicatie, komen al meerdere personen aan bod die een document kunnen bewerken. Bij grotere documenten kan het ook voorkomen dat er meerdere auteurs aan een document willen werken.

FontoXML heeft voor het samenwerken aan een document een vergrendelingsmechanisme geïmplementeerd in het product. Binnen FontoXML wordt er gebruik gemaakt van optimistic locking. Zodra een auteur begint met schrijven wordt er automatisch op de achtergrond een gevraagd aan de server of het deel vergrendeld kan worden. Zodra de auteur de

toestemming krijgt om het te vergrendelen, is het voor andere auteurs niet meer mogelijk om dat deel van het document aan te passen. Als twee auteurs tegelijk een document proberen te bewerken, zal slechts één het document kunnen vergrendelen. Het werk van de andere auteur zal verdwijnen zodra het document is vergrendeld.

Door delen van een document te kunnen vergrendelen is de eerste stap gezet voor het samenwerken binnen FontoXML. Echter, is de huidige implementatie niet altijd gewenst, aangezien het er vanuit gaat dat gebruikers FontoXML correct gebruiken. Hierdoor kan het voorkomen dat een persoon heel lang een document vergrendeld houdt, waardoor andere gebruikers niks kunnen doen.

1.2 Student binnen FontoXML

Binnen de organisatie werk ik onder Bert Willems, waar hij een onderzoek verricht voor real-time collaboration. Voor FontoXML is dit een onderwerp dat hoog op het spreekwoordelijke verlanglijstje staat. Hiervoor ben ik zorgvuldig aan de slag gegaan, aangezien er op de uitkomst van deze opdracht verder gebouwd zal worden om real-time collaboration verder te implementeren binnen FontoXML.

Op de volgende pagina is het organogram van Liones te zien in figuur 1.2. Dit organogram is ook te vinden als grotere versie als bijlage A. Het organogram is opgesteld door de

organisatie zelf en is ook terug te vinden op de website van Liones.

Bert heeft de technische leiding binnen de organisatie. Hij weet wat er ontwikkeld moet worden en zal zelf ook ontwikkelen voor het product. Bert wordt ook veel betrokken bij het technische overleg met klanten, waardoor hij af en toe niet aanwezig is op kantoor. Binnen het organogram dat te zien is in figuur 1.2 vervult Bert de taak van architect voor FontoXML. Naast Bert heb ik meer collega’s die hem ondersteuning kunnen bieden bij mijn

afstudeeropdracht. Marijn van Butselaar dient als tweede begeleider van mij en kan naast Bert goede input bieden voor de opdracht. Marijn is zelf ook ontwikkelaar voor FontoXML en is in staat om mij hierin te ondersteunen.

Verder kan Tom Groeneboer ook hulp bieden, mocht dit nodig zijn. Hij is een developer die zich voornamelijk bezighoudt met de ontwikkeling aan de backend van het product. Tom werkt aan nieuwe features, maar houdt zich ook bezig met het oplossen van bugs. Tevens is hij de persoon die zich binnen Liones bezighoudt met integratie.

Verder is het mogelijk om bij iedereen binnen de organisatie aan te kloppen voor hulp. Binnen Liones is iedereen heel toegankelijk en bereid om te helpen. Ook zijn er veel verschillende kennis en expertise aanwezig waar ik gebruik van zou kunnen maken. Zelf werk ik binnen de organisatie binnen Research & Development onder leiding van Bert. Dit valt direct onder FontoXML binnen het organogram van figuur 1.2. Bert is

verantwoordelijk voor mij, maar mijn opdracht staat los van de dagelijkse gang van zaken binnen de organisatie.

De communicatie met de opdrachtgever is belangrijk binnen dit project. Iedere week vindt een contactmoment plaats met Bert en Marijn om de huidige voortgang te bespreken.

2. Probleembeschrijving

FontoXML heeft een product ontwikkeld voor auteurs. De basis van dit product is een XML editor die het mogelijk maakt om teksten te schrijven met de juiste semantische waarden. Tevens is het voor een organisatie mogelijk om een huisstijl toe te passen op de

documenten, zodat de tekst gepubliceerd kan worden.

Samenwerken speelt een steeds belangrijkere rol in het proces van het schrijven, reviewen en publiceren van teksten. Samenwerken aan een document moet steeds vaker ook op hetzelfde moment kunnen plaatsvinden. Hier wil FontoXML ook oplossingen voor realiseren om zo meer functionaliteiten te kunnen bieden voor klanten en het gebruiksgemak van het product nog verder te verbeteren.

Binnen de wereld waar FontoXML in opereert, is het mogelijk dat meerdere auteurs samen aan een artikel of boek werken. Op dit moment is het mogelijk om tijdens het schrijven een deel van het document te vergrendelen. Door de tekst te vergrendelen is het voor andere auteurs niet mogelijk om dit deel van het document te wijzigen. Tot op heden kunnen

auteurs alleen zien dat een item of deel ervan vergrendeld is, maar niet wie dit heeft gedaan. FontoXML wil voor de auteurs en reviewers functionaliteiten inbouwen voor betere

communicatie. Hierbij kan gedacht worden aan het verbeteren van het verkrijgen en vrijgeven van vergrendelingen, een chatfunctie voor auteurs en reviewers of het plaatsen van opmerkingen door meerdere personen op hetzelfde moment. Deze communicatie zal real-time moeten plaatsvinden, om zo tijd te kunnen besparen. Het kan voorkomen dat meerdere personen op hetzelfde moment tijd hebben om aan een document te werken, maar op dit moment is het alleen mogelijk om delen van het document te vergrendelen. Verder is het mogelijk om in FontoXML opmerkingen te plaatsen in het document. Echter, het is hierbij niet mogelijk om met meerdere gebruikers op hetzelfde moment opmerkingen te plaatsen. Op het moment dat een document vergrendeld is, is het niet mogelijk om hier opmerkingen bij te plaatsen. Hierdoor moet de gebruiker wachten op degene die het document heeft vergrendeld om zelf aan het werk te gaan.

2.1 Opdracht

Deze opdracht bevat een onderzoek naar het plaatsen van opmerkingen binnen FontoXML. Tevens zal er op basis van het onderzoek een Proof of Concept in de vorm van een

prototype worden ontwikkeld. Dit prototype wordt eerst ontworpen, vervolgens gebouwd en getest. Met het Proof of Concept kan worden aangetoond dat de ontworpen manier

daadwerkelijk functioneert.

Het doel van de opdracht is het ontwikkelen van een oplossing om opmerking te kunnen plaatsen in een XML document dat ondertussen door anderen gewijzigd kan worden. De technieken die hiervoor gebruikt kunnen worden komen naar boven in het onderzoek dat wordt verricht. Vervolgens worden deze technieken verder uitgelicht in het ontwerp van het Proof of Concept. Het prototype dat binnen het Proof of Concept ontwikkeld wordt heeft als doel om aan te tonen dat opmerkingen geplaatst kunnen worden en de juiste positie kunnen behouden.

De complexiteit van deze opdracht komt naar boven als er gesproken wordt over de positie van deze opmerkingen. Binnen een document wordt een opmerking geplaatst op een deel van de tekst. Zodra het document gewijzigd wordt, moet de opmerking op hetzelfde deel van de tekst blijven staan.

Om een beeld te schetsen van de complexiteit van deze opdracht moet gedacht worden aan het volgende scenario: Gebruiker A is bezig met het bewerken van een XML Document, waarbij hij tekst toevoegt, verwijdert en verplaatst. Ondertussen heeft gebruiker B ook het document openstaan, hij kan het document niet wijzigen, maar heeft wel de mogelijkheid om opmerkingen toe te voegen. Echter, gebruiker B kan niet de wijzigingen zien die gebruiker A maakt in het document, hij heeft dus een oudere versie van het document voor zich.

Zodra de gebruikers klaar zijn, moet er weer één versie van het document worden gevormd. Hierbij moeten de opmerkingen van gebruiker B worden gepositioneerd op het gewijzigde document van gebruiker A. Hiervoor zal eerst het verschil tussen de versies van het document bepaald moeten worden en vervolgens op basis hiervan de posities van de geplaatste opmerkingen van gebruiker B op de tekst van gebruiker A moeten worden geplaatst.

3. Aanpak

In dit hoofdstuk wordt de aanpak beschreven binnen de opdracht. Het project bestaat uit verschillende fases, waarbij gedacht kan worden aan analyse, ontwerp, ontwikkeling en testen. Door de verschillende fases van deze opdracht, zijn er voor bepaalde fases

verschillende aanpakken nodig. Zo wordt in dit hoofdstuk de aanpak van de onderzoeken uit de analyse behandeld, maar ook de ontwikkelmethode die binnen het afstuderen is gebruikt.

3.1 Onderzoeksaanpak

Binnen dit project ga ik een groot onderzoek verrichten, dit bestaat uit twee delen. Het eerste deel is het algemene onderzoek, gevolgd door een vervolgonderzoek gericht op de

technische aspecten van het onderwerp.

Beide onderzoeken binnen het afstuderen zijn kwalitatieve onderzoeken. Voor deze onderzoeken worden vragen opgesteld die met behulp van literatuurstudie en interviews worden beantwoord. De interviews worden vooraf voorbereid, dit zal ik doen door vragen op te stellen zodat ik goed het interview kan leiden. Afhankelijk van de antwoorden die ik krijg op mijn vragen kan ik hier verder op doorvragen en daarmee afwijken van de vooraf opgestelde vragen.

Bij het algemene onderzoek ga ik onderzoek naar de mogelijke oplossingen die bekend zijn binnen het vakgebied. Dit onderzoek kan breed worden, maar op basis van de conclusie van dit onderzoek kan ik een gerichter onderzoek verrichten in het technische onderzoek.

3.2 Ontwikkelmethodiek

Voor dit project heb ik gekozen om gebruik te maken van de watervalmethode. Ik heb voor waterval gekozen omdat ik na de oriëntatie binnen mijn project een duidelijk beeld heb over de wensen en eisen aan dit project. Hierbij weet ik echter nog niet alle requirements van het project, maar deze zullen tijdens het verzamelen van de requirements naar boven komen. Binnen FontoXML zijn een aantal stakeholders met verschillende achtergronden. Deze stakeholders hebben voor FontoXML zelf ook al requirements opgesteld. Delen van deze requirements kan ik gaan gebruiken binnen dit project. Tevens zijn er een aantal valkuilen die reeds bekend zijn binnen de organisatie. De mensen met de verschillende expertises kunnen mij helpen deze valkuilen te omzeilen.

FontoXML maakt gebruik van Scrum als ontwikkelmethodiek, maar ik heb gekozen om hiervan af te wijken. Voor dit project is het mogelijk om met een watervalmethode te werken, omdat het hier gaat om een afgebakende wens binnen het bedrijf. Vooraf zijn bepaalde wensen en eisen aan het project al duidelijk aanwezig. Echter, ik zal deze wensen en eisen nog wel moeten vertalen naar requirements voordat ik hiermee aan de slag kan gaan. Tevens ga ik door middel van verschillende interviews op zoek naar requirements van andere personen binnen de organisatie.

Binnen het afstuderen is geen gebruik gemaakt van het watervalmodel dat is beschreven door Royce, maar is er gewerkt met het Sashimi-model. Het model van Royce beschrijft dat de fases strikt gescheiden van elkaar zijn. Hierdoor is het niet mogelijk om aanpassingen te doen in de vorige fase als deze eerder al is afgerond. Vaak blijkt er juist dat er wel

terugkoppeling nodig is naar de vorige fase. (Matković & Tumbas, 2010, p.166)

Bij dit project wordt dus niet stevig vastgehouden aan de strikte versie van de

watervalmethode beschreven door Royce. Binnen dit project wordt gebruik gemaakt van het Sashimi model beschreven door Peter Degrace, waarin overlap tussen fases bestaat. Met deze overlap is het mogelijk om wijzigingen aan te brengen in het ontwerp zodra hier tijdens de ontwikkeling tegenaan wordt gelopen. Hierdoor is het mogelijk om het project nog licht bij te sturen, mocht dit nodig zijn.

Fig 3.1. Het Sashimi-model volgens Peter Degrace.

Voor deze opdracht zal ik uitgebreid kijken naar de requirements. Dit ga ik doen door meerdere interviews te houden met verschillende mensen binnen de organisatie. De

personen zullen geselecteerd worden op basis van de expertise en zeggenschap binnen de organisatie. Binnen een watervalmodel is het (bijna) niet mogelijk om later nog requirements toe te voegen, waardoor ik vooraf veel tijd zal moeten besteden om alle requirements boven water te krijgen.

Het model zoals is te zien in figuur 3.1 is terug te zien in de strokenplanning die is gemaakt voor deze opdracht. De strokenplanning is te vinden als bijlage B van dit document. Binnen deze planning is overlap tussen de verschillende fases te zien, wat aansluit bij het Sashimi model.

Er is binnen het afstuderen bewust niet gekozen voor Scrum of een andere agile methode. Voor deze opdracht staan de requirements vast aan het begin van de opdracht, wat beter past bij de waterval methode dan bij een agile methode. De gedachte achter een agile methode is het flexibel kunnen werken, waarbij nog niet alle requirements aan het begin bekend zijn. Bij Agile groeit het product iedere sprint, maar groeien ook de requirements. Deze nieuwe requirements kunnen dan meegenomen worden in een nieuwe sprint.

Voor het gehele project zal ik gebruik maken van de watervalmethode. Echter, ik ga voor het ontwikkeldeel van mijn project gebruik maken van Evolutionary Prototyping, zoals is te zien in figuur 3.2. Deze methode zal verder worden beschreven in paragraaf 3.2.1 van dit document.

Door de beperkte tijd van dit project, ben ik opzoek gegaan naar een methode die dit zou ondersteunen. Door Evolutionary Prototyping toe te passen binnen mijn ontwikkelingsfase is dit mogelijk. Deze methode staat mij toe om in overleg met de opdrachtgever de juiste route voor dit project te kiezen. Hij heeft invloed op het resultaat van het prototype. Het prototype dient binnen dit project alleen voor het aantonen van de oplossing uit het onderzoek.

Fig 3.2. Ontwikkelmethode van het gehele project schematisch weergegeven.

3.2.1 Evolutionary Prototyping

Voor de softwareontwikkelmethode heb ik gekozen voor Evolutionary Prototyping

(Mourzenko, 2014), aangezien het gaat om het ontwikkelen van een prototype. Binnen deze methode zal eerst een basis prototype worden ontwikkeld en vervolgens worden er

uitbreidingen op deze basis ontwikkeld, zoals is te zien in figuur 3.3. Deze uitbreidingen zijn niet gebonden aan een bepaalde vaste tijdsduur zoals bij een Agile ontwikkelmethode. Ook heb ik voor deze methode gekozen door de onzekerheid rondom de implementatie van het ontwerp. Binnen het ontwerp zal ik nadenken over de mogelijke implementatie. Hiervoor zal ik ook moeten denken over de algoritmes die ik moet gaan gebruiken.

Fig 3.3. Evolutionary Prototyping schematisch weergegeven. (Mourzenko, 2014)

Uiteindelijk gaat het binnen dit project om een prototype, dit betekent dat niet alles perfect hoeft te zijn. Voor dit project ga ik zelfs nog een stukje verder, hier gaat het voornamelijk om een technisch prototype. Dit zal betekenen dat ik geen aandacht zal besteden aan de gebruiksvriendelijkheid, maar al mijn aandacht zal besteden aan de functionaliteiten van het prototype.

3.3 Tests

Voor de testen die uitgevoerd worden binnen dit project, zal ik een testplan opstellen. Binnen dit plan komen de risicogebieden van het prototype aan bod. Deze risicogebieden zijn

geïdentificeerd op basis van een testrisicoanalyse, waar op basis van verschillende rollen punten zijn gegeven aan risicogebieden. Op basis van deze risicoanalyse ga ik de

teststrategie ontwikkelen.

3.3.1 Testplan

Na het ontwerp kan er worden begonnen aan de uitvoering van dit ontwerp. Voordat het daadwerkelijke ontwikkelen van het prototype begint, heb ik een testplan opgesteld. Dat testplan is na het ontwikkelen van het prototype uitgevoerd.

3.3.1.1 Testbasis

De testbasis voor dit project bestaat uit de requirements en het ontwerp van de applicatie. De requirements zijn eerder in het project opgesteld en zullen nu worden gebruikt om tests rond op te stellen. De requirements bieden de uitgangspunten waar de applicatie op getest moeten worden. Het ontwerp beschrijft verder in detail hoe de applicatie moet gaan werken. In het ontwerp is een document opgenomen waarin veel situaties beschreven staan, dit zal als input van het testplan gebruikt worden.

3.3.1.2 Teststrategie

De teststrategie legt vast welke stappen er genomen worden bij het testen. Hierin is een risicoanalyse opgesteld om de risico’s goed in beeld te kunnen brengen, het grootste risico zal het zwaarst getest worden binnen dit traject.

Testrisicoanalyse

Bij de testrisicoanalyse (De Grood, 2008, p93-101) is bepaald wat de belangrijkste punten van de applicatie zijn. Dit heb ik gedaan door verschillende rollen aan te nemen en op basis daarvan punten te geven aan de onderwerpen. De rollen die ik gebruikt heb voor de

verdeling zijn de afnemers, de bouwers en de projectverantwoordelijken. Onder de afnemers behoren de gebruikers van de applicatie, de bouwers zijn de mensen die de applicatie ontwikkelen en de projectverantwoordelijken zijn de opdrachtgevers van dit project. Elke rol mocht 18 punten verdelen over de onderwerpen. Bij deze verdeling is het alleen mogelijk om 1, 3, 5 of 9 punten te geven. Hierbij geeft 9 punten aan dat het onderwerp van cruciaal belang is voor de werking van het systeem. 5 punten geeft een belangrijk

onderwerp aan, maar hier zijn fouten toegestaan mits er een workaround aanwezig is. Bij 3 punten gaat het om een niet cruciaal onderwerp wat het beoogde resultaat niet in gevaar zal brengen. Bij 1 punt wordt het onderwerp bij voorkeur wel getest, maar slechts met een beperkte diepgang.

Na de testrisicoanalyse bleek dat de mapping van de opmerking de hoogste prioriteit heeft. Dit wordt dan ook het beste getest om zeker te zijn dat hier zo weinig mogelijk fouten in aanwezig zijn. Alles rondom de opmerkingen zelf en de reacties daarop hebben de laagste punten gekregen. Deze hebben daarom niet veel prioriteit binnen het testtraject. De uitkomst van de testrisicoanalyse is te zien in tabel 3.1.

Risicogebied Totaal

Mapping - Positie wijzigen 27 Mapping - Verschil bepalen 19

Comments - Toevoegen 4

Comments - Oplossen 2

Comments - Bewerken 0

Reacties - Toevoegen 1

Reacties - Reageren 1

Tabel 3.1. Puntenverdeling van de testrisicoanalyse.

Matrices

Na het opstellen van de testrisicoanalyse wist ik waar de focus van het testtraject zou komen te liggen. Hierop heb ik op basis van enkele kwaliteitsattributen een strategiematrix gemaakt. Hierin wordt aangegeven welke testen worden uitgevoerd voor de verschillende

kwaliteitsattributen, samen met de prioriteit hiervan.

Tevens heb ik een techniekenmatrix opgesteld, hierin wordt er per testsoort en risiconiveau aangegeven welke testtechnieken worden toegepast. Hierbij is te zien dat de risicogebieden met een hoger risico zwaarder getest worden. De techniekenmatrix is te zien in tabel 3.2.

Testsoort Risicocategorie Laag Risicocategorie Midden Risicocategorie Hoog Risicocategorie Kritisch Moduletest ● AT statement coverage ● AT statement coverage ● AT branch coverage ● AT condition coverage Systeemtest ● EP valide ● Syntax ● EP valide + invalide ● Syntax ● BVA valide ● Syntax ● BVA valide + invalide ● Syntax ● C/E Acceptatietest ● Error guessing ● Exploratory testing ● Exploratory testing ● CRUD ● PCT branch coverage ● CRUD Tabel 3.2. Techniekenmatrix

3.3.1.3 Planning

Binnen het testplan heb ik een losse planning opgesteld voor het testtraject. Deze planning is hieronder te zien in tabel 3.3. Het testtraject heeft in deze planning nog maar twee weken, terwijl er in het afstudeerplan en het plan van aanpak nog drie weken voor stonden

ingepland. De verkorting van het traject heeft te maken met de uitloop van het ontwerp, al levert dit verder geen problemen op voor het project.

Week 15 Week 16 Week 17

15-05 - 19-05 22-05 - 26-05 29-05 - 02-06 Taak Ma Di Wo Do Vr Ma Di Wo Do Vr Ma Di Wo Do Vr Testtraject - - - x - - Testrapportage - x - - Risicocategorieën x Kritisch - - - x Hoog - - x Middel - - x Laag - x

Tabel 3.3. Planning voor het testtraject.

Binnen het testtraject zullen ook enkele reviews plaatsvinden met de opdrachtgever, maar deze sessie zijn onderhevig aan wijzigingen, waardoor deze niet in de planning zijn opgenomen. Deze sessies zullen plaatsvinden in week 15 en week 16 van het project. Elk van deze weken zullen minstens één review sessie hebben, mocht het nodig zijn kunnen er meer worden ingepland.

3.4 Planning

De planning voor dit project staat in de tabel hieronder, ook staan hier de tussenproducten die worden opgeleverd aan het einde van de fase. Binnen deze planning worden meerdere fases gegeven, deze komen overeen met de verschillende fases van het watervalmodel, wat is besproken in paragraaf 3.2 van dit document.

Binnen tabel 3.4 zijn de verschillende fases opgenomen met het resultaat daarvan en de verwachte tijdsbesteding. Echter, hier is geen overlap zichtbaar, deze overlap zal worden toegepast wanneer dit nodig zal zijn. Zo kan het voorkomen dat bij de ontwikkeling in week 8 nog enkele wijzigingen in het ontwerp moeten plaatsvinden. In deze planning zit dus nog wat speling als het gaat om de tijdsverdeling.

Fase Resultaat Weken

1. Oriëntatie Plan van Aanpak Week 1

2. Onderzoek Onderzoeksrapport Week 2-4

3. Requirements Requirements document Week 2-4

4. Ontwerpen Ontwerpdocument Week 5-7

5. Ontwikkelen Prototype Week 8-13

6. Testen Testrapport Week 14-16

7. Afronden afstudeerdossier Afstudeerdossier Week 17 Tabel 3.4. Tijdschema voor de verschillende fases van de afstudeeropdracht.

3.5 Risico’s

Dit project heeft enkele risico’s die in deze paragraaf behandeld zullen worden. Tevens wordt hier beschreven wat de mogelijke vervolgstappen zijn als deze risico’s zich voordoen. Later in dit document wordt mogelijk teruggekeken naar deze oplossingen, als deze risico’s zich voordoen binnen het project.

● Uitloop van een fase ● Extra requirements ● Onoplosbare complexiteit ● Te grote scope

Bij het uitlopen van een fase vindt hierover overleg plaats met de opdrachtgever. Iedere week wordt de voortgang besproken met de opdrachtgever, hierdoor wordt tevens de voortgang bewaakt. Mocht er toch uitloop plaatsvinden binnen dit project, zal dit in goed overleg met de opdrachtgever gecontroleerd plaatsvinden. Bij een mogelijk gevaar, worden er beslissingen genomen om dit tegen te gaan. Zodra het geen gevaar oplevert, zal de uitloop plaatsvinden en binnen de planning mogelijk iets geschoven worden.

Bij het toevoegen van meer requirements later in het proces, komt er een overleg om de waarde van deze nieuwe requirements te bepalen. Uitgezonderd van kritische, nieuwe requirements worden de nieuwe requirements direct buiten de scope van het project geplaatst. Het is zeer onwaarschijnlijk dat er na het verzamelen van de requirements nog kritische requirements boven komen, doordat de requirements voor dit project gebaseerd zijn op de bestaande wensen en ideeën voor het product zelf. Mocht het voorkomen dat er nieuwe requirements boven water komen, worden deze buiten de scope van dit project geplaatst. Dit is bepaald in overleg met de opdrachtgever.

Bij onoplosbare complexiteit zal ik eerst overleg hebben met mijn begeleiders. In overleg met hen zal bepaald worden wat er met deze complexiteit gedaan moet worden. Afhankelijk van de impact op het project kan besloten worden deze complexiteit buiten de scope van het project te plaatsen. Hierbij kan een notitie worden gemaakt dat hiervoor nog verder

onderzoek nodig zal zijn.

Naarmate het project zal vorderen, is het makkelijker om te bepalen wat een goede scope is voor het project. Bij signalen van een te grote scope, zal de scope worden aangepast in overleg met de opdrachtgever van het project. Het aanpassen van de scope is uiteraard ook mogelijk als er signalen zijn van een te kleine scope. Hierbij kan gekozen worden om meer functionaliteiten op te nemen in het project.

3.6 Technieken

Het prototype wordt ontwikkeld in C#, dit is gekozen doordat er binnen de organisatie meer met deze taal gewerkt wordt. Ook heb ik enige ervaring met deze taal, wat het werk

efficiënter maakt. Om in C# te programmeren maak ik gebruik van Visual Studio 2015. Verder maak ik gebruik van .NET Framework 4.6 en ASP.NET 4.6. Binnen het prototype wordt ook gebruik gemaakt van WebSockets. Dit wordt gebruikt voor de communicatie tussen de client(s) en de server en hiervoor wordt gebruik gemaakt van SignalR 2.2.1. (SignalR, 2017)

Tevens wordt er gewerkt met DeltaXML. (DeltaXML, 2017) Deze library wordt gebruikt om het verschil tussen twee XML-documenten te bepalen. Hier wordt binnen dit project veel gebruik van gemaakt om de wijzigingen in een stuk XML te detecteren. DeltaXML zal binnen dit project gebruikt worden om het verschil te bepalen van een document dat door een andere editor is bewerkt.

4. Analyse

Binnen dit hoofdstuk wordt het analyse deel van het afstuderen behandeld. Dit deel bevat de eerste drie fases die beschreven staan in de planning in paragraaf 3.4 van dit document. Dit is de oriëntatie, het onderzoek en de requirements.

4.1 Oriëntatie

Op de eerste dag van mijn afstudeertraject bij Liones kreeg ik de aanbeveling van mijn begeleiders om te starten met een oriëntatiefase. Dit geeft meer inzicht over de

mogelijkheden met FontoXML. Ook kan ik op deze manier kijken wat er nog meer beschikbaar is op de markt en wat hierbij de mogelijkheden kunnen zijn.

Binnen mijn opdracht zal ik gaan werken aan de verbetering van real-time collaboration binnen FontoXML. Hierbij was aan het begin van de opdracht nog weinig over bekend wat de exacte invulling hiervan zou zijn. Eerder was al wel aangegeven dat er misschien iets gedaan zou kunnen worden met het verkrijgen en vrijgeven van een lock op een deel van een document, maar het was niet bevestigd dat dit de opdracht zou worden.

Door de onzekerheid rondom de exacte opdracht, heb ik mij georiënteerd op het hele

onderwerp. Dit bevat real-time collaboration in combinatie met XML en de mogelijkheden die reeds beschikbaar zijn op de markt. Tijdens deze oriëntatie heb ik gezocht naar manieren hoe ik samenwerking in een document kan realiseren.

Tevens heb ik een demo gehad met FontoXML om zelf te ervaren wat de mogelijkheden met het product zijn. Hierbij heb ik zelf een beter beeld van de applicatie kunnen krijgen en de functionaliteiten ervan. Met dit beeld is het voor mij ook makkelijk om te begrijpen wat mijn collega’s bedoelen met bepaalde uitspraken die binnen die organisatie veel gebruikt worden.

Binnen mijn oriëntatie heb ik vele zoektermen gebruikt om informatie te vergaren, maar de belangrijkste hierin was Real-time collaboration XML. Verder heb ik ook veel gekeken naar Operational Transform en Differential Synchronization. Dit zijn algoritmes die het mogelijk maken om meerdere mensen tegelijk aan een document te laten werken. Naast deze twee algoritmes ben ik tijdens mijn oriëntatie ook nog Conflict-free Replicated Data Types tegengekomen voor het tegelijk samenwerken aan een document.

De genoemde algoritmes zijn gericht op tekstdocumenten en niet op de gestructureerde data binnen een XML-document. Deze XML-documenten kunnen strengere regels hebben waar rekening mee gehouden moet worden tijdens het aanpassen hiervan.

Echter, tijdens mijn oriëntatie bleek dat het werken aan een XML-document te complex zou zijn voor een afstudeeropdracht. Dit heeft te maken met de structuur die een XML-document afdwingt. Het is zeer complex om een XML-document aan te passen met meerdere

gebruikers tegelijk en op hetzelfde moment een document valide te houden. Binnen FontoXML moet een document altijd valide zijn.

XML heeft een boomstructuur. Deze structuur bestaat uit nodes die elk weer nieuwe nodes kunnen bevatten. Tussen deze nodes kunnen relaties liggen. De regels over deze relaties kunnen vastgelegd worden in een schema. Dit kan bijvoorbeeld afdwingen welke elementen kunnen worden toegevoegd onder een bepaalde node. Ook kan hierin worden vastgelegd hoe vaak een bepaald element kan voorkomen onder een bepaalde node.

Zodra er maar één element aanwezig mag zijn in een document en twee gebruikers proberen op hetzelfde moment dit element aan te maken, is het niet mogelijk om beide wijzigingen te behouden. Hierbij zou het systeem een beslissing moeten maken welk element behouden wordt, om het document valide te houden. Dit kan echter weer gegevensverlies opleveren, wat ook weer onwenselijk is binnen FontoXML.

Aan het einde van mijn oriëntatie heb ik een overleg gehad met mijn begeleiders. Bij dit overleg werd aangegeven welke mogelijkheden beschikbaar waren in hun ogen. Het ging hierbij om de betere communicatie rondom locks, waarbij de locks ook dynamisch

vrijgegeven zouden kunnen worden om het werk te kunnen versnellen. De andere

mogelijkheid was omtrent het toevoegen van opmerkingen met meerdere personen tegelijk. Op basis van de keuzes die ik tot mijn beschikking had na het overleg met mijn begeleiders en tevens opdrachtgevers, heb ik een keuze gemaakt. Deze keuze wijkt af van de opdracht die beschreven staat in mijn afstudeerplan. Waar ik daar had beschreven hoe ik aan de slag zou gaan met het vergrendelen van een document, heb ik nu gekozen voor het toevoegen en stabiel houden van opmerkingen met meerdere personen tegelijk. Dit terwijl het ook mogelijk is dat er wijzigingen plaatsvinden in het document en/of meerdere versies beschikbaar zijn.

Door mijn oriëntatie heb ik een goed genoeg beeld gekregen om een plan van aanpak voor de rest van het project op te stellen. Dit plan is gebaseerd op de nieuwe keuze voor het project. De uitkomsten van dit plan zijn terug te lezen in hoofdstuk 3 over de aanpak van dit project.

Ik heb voor de opdracht rondom het plaatsen van opmerkingen gekozen omdat deze opdracht aanvankelijk heel afgebakend leek, later bleek dit onderwerp vrij complex te zijn. Bij de opdracht voor het verbeteren van de communicatie rondom de locks waren nog een aantal open punten in het verhaal van Bert, terwijl dit bij de opmerkingen niet het geval was.

4.2 Onderzoek

Aanvankelijk zou ik een onderzoek doen naar het plaatsen van opmerkingen binnen FontoXML en vervolgens beginnen aan een ontwerp voor een prototype. Echter, aan het einde van het eerste onderzoek bleven veel vragen over, waardoor een vervolgonderzoek nodig was om antwoord te krijgen op deze vragen. Hierdoor wordt er in dit hoofdstuk gesproken over een algemeen onderzoek en een technisch onderzoek.

Het algemene onderzoek is een combinatie van een literatuurstudie en het afnemen van interviews. Dit is gekozen om een beeld te krijgen van de ideeën binnen FontoXML aan de ene kant, maar aan de andere kant ook de kennis over real-time collaboration van experts mee te kunnen nemen in het onderzoek.

Naast een algemeen onderzoek wordt er binnen deze opdracht ook een technisch onderzoek verricht. Dit tweede onderzoek gebruikt het eerste onderzoek als basis. De uitkomsten van het algemene onderzoek bieden de input voor het technische onderzoek. Dit onderzoek is dan ook meer gericht op de limitaties en edge cases van de gekozen

oplossing.

4.2.1 Algemeen onderzoek

Het eerste onderzoek binnen het afstuderen is gericht op de algemene zaken rond het plaatsen van comments binnen FontoXML. De hoofdvraag die binnen dit onderzoek is beantwoord is “Wat is de beste manier voor FontoXML om comments real-time te plaatsen?” Om deze vraag te kunnen beantwoorden is de hoofdvraag opgedeeld in verschillende

deelvragen.

Deze deelvragen geven inzicht in de wensen van de organisatie. Voor de wensen zijn tevens interviews afgenomen met werknemers van Liones. Bij de keuze voor de beste manier heb ik ook gekeken naar de mogelijke manieren die beschikbaar zijn. Deze manieren zijn bekeken tijdens de literatuurstudie van het onderzoek.

De deelvragen van het algemene onderzoek staan hieronder beschreven. Twee deelvragen zijn verder opgesplitst met verschillende subvragen. Deze subvragen zorgen voor een beter en breder antwoord op de deelvraag. Of doordat deze vragen zijn ontstaan in een gesprek met mijn begeleiders, maar overlap hadden met een van de deelvragen.

● Welke manieren bestaan er om comments real-time te verwerken? ● Welke features zijn gewenst voor de comments?

○ Moeten comments aanpasbaar zijn? ○ Zijn suggesties ook comments?

○ Moet een comment toegevoegd kunnen worden aan een selectie? ● Wat moet er gebeuren bij een error?

○ Wat moet er gebeuren als een comment de server niet bereikt?

● Wat moet er gebeuren als er meerdere comments op dezelfde plaats en tijd worden geplaatst?

De criteria voor het kiezen van de oplossing is van groot belang voor het antwoord op de hoofdvraag. Deze criteria worden gebruikt om een afweging te maken van de mogelijke oplossingen die tijdens dit onderzoek naar voren komen. De oplossingen verschillen op een aantal punten, waaronder de geschatte moeilijkheid van de implementatie en de impact op de architectuur van FontoXML.

Met de volgende criteria zal rekening worden gehouden binnen dit onderzoek: ● Geschatte moeilijkheid van de implementatie

● Heeft een server nodig om te functioneren ● Impact op de architectuur

● Voldoet aan gewenste features

Welke manieren bestaan er om comments real-time te verwerken?

Binnen dit onderzoek is er gekeken naar vier verschillende manieren om comments real-time te verwerken. Deze manieren zijn Operational Transformation, Differential

Synchronization, Conflict-free Replicated Data Types en een externe service. De eerste drie manieren zijn gericht op het verwerken van de opmerkingen in het document zelf. Bij de externe service worden de opmerkingen losgehaald van het document.

Operational Transformation

Operational Transformation (OT) zorgt ervoor dat meerdere tekstdocumenten met elkaar worden gesynchroniseerd. Deze synchronisatie wordt uitgevoerd na iedere operatie. Bij deze synchronisatie wordt een transformatie uitgevoerd om de synchronisatie te voltooien. Hier komt dan ook de naam vandaan.

Fig 4.1. Het basisprincipe van Operational Transformation. Verkregen van “Basic idea behind OT” van Nusnus, https://en.wikipedia.org/wiki/Operational_transformation/

In figuur 4.1 is het basisprincipe van OT weergegeven. Hierin is goed te zien dat na een operatie, deze ook plaatsvindt, dankzij een transformatie, bij andere clients die bezig zijn in hetzelfde document. In dit voorbeeld is geen server opgenomen waar ook nog een kopie van het document staat.

Differential Synchronization

Differential Synchronization werkt volgens het diff-match-patch principe. Dit houdt in dat er eerst een verschil wordt gezocht tussen een aangepast document en het origineel. De verschillen hiervan komen in een diff bestand terecht. Dit bestand wordt vervolgens naar de server gestuurd, waar een patch wordt toegepast op het document wat op de server staat. Mogelijke wijzigingen in het document wat op de server staat wordt op dezelfde manier verstuurd naar de client. Het verbeterde model van Fraser is te zien in figuur 4.2.

Fig 4.2. Uitgebreide versie van Differential Synchronization. (Fraser, 2009)

Conflict-free Replicated Data Types

Verder is het mogelijk om gebruik te maken van Conflict-free Replicated Data Types

(CRDT). Deze data types hebben een Strong Eventual Consistency (SEC), wat inhoudt dat ze uiteindelijk consistent met elkaar zijn, maar niet direct zodra iemand begint met een wijziging (Shapiro et al., 2011).

Het is mogelijk om een omgeving te maken om samen te werken met XML files door het gebruik van CRDTs (Martin et al., 2011). Een functionaliteit om aanpassingen ongedaan te maken behoort ook tot de mogelijkheden. Zodra er aanpassingen worden verricht, wordt dit niet direct verstuurd naar andere gebruikers. Dit kan complexe situaties veroorzaken als er een aanpassing ongedaan wordt gemaakt.

Externe service

De laatste mogelijkheid is het ontwikkelen van een externe service met een database waar de opmerkingen in worden opgeslagen. Deze externe service zal, zoals de naam doet vermoeden, naast de huidige architectuur staan, maar zal wel geïntegreerd moeten worden in de editor van FontoXML.

Een externe service met opmerkingen zou toegevoegd kunnen worden als add-on binnen de huidige architectuur. Deze add-ons worden naar de wensen van de klant wel of juist niet toegevoegd aan het systeem dat zij besteld hebben. Hierdoor is het niet per se nodig dat een klant een database moet toevoegen als hij opmerkingen wil hebben in de editor.

Welke features zijn gewenst voor de comments?

Op basis van de gesprekken met de begeleiders zijn er enkele features bedacht. Deze features zijn gevat in de deelvragen die hieronder worden behandeld. Deze vraag in combinatie met de deelvragen zijn gesteld in de interviews met de verschillende stakeholders naast de opdrachtgever zelf.

Martin Middel heeft aangegeven dat hij graag een mogelijkheid ziet om opmerkingen te archiveren. De opmerkingen worden dus niet zomaar opgelost of verwijderd, maar blijven bestaan. Deze gearchiveerde opmerkingen moeten ook ergens terug te zien kunnen zijn. Tevens zou Martin Middel de komst van een chat mogelijkheid ook wel graag zien. Hiermee bedoelt hij dat het mogelijk is om te kunnen chatten met een collega als zij beiden actief zijn in het document. Hierbij is het makkelijker om met elkaar te communiceren over de kwaliteit van het document. (M. Middel, interview, Februari 21, 2017)

Moeten comments aanpasbaar zijn?

Comments kunnen aanpassen kan veel tijd en moeite schelen voor personen die bezig zijn met de review van een document. Binnen de huidige implementatie missen hier nog enkele functionaliteiten die wel gewenst zijn binnen de applicatie. Zo is het op dit moment niet mogelijk om een opmerking aan te passen zonder deze te verwijderen en weer opnieuw aan te maken. (Y. Bosselaar, interview, Februari 15, 2017)

Zijn suggesties ook comments?

Suggesties maken is een onderdeel van het review proces. Dit kan heel handig zijn voor de gebruiker om, naast het gebruik van comments, ook suggesties te doen voor aanpassingen. Deze functionaliteit is dan ook zeker gewenst binnen FontoXML.

Het is echter niet mogelijk om nieuwe elementen toe te voegen aan de suggestie. De

implementatie binnen het feedback platform van het Internationaal Atoomenergieagentschap (IAEA) staat alleen een suggestie toe van de tekst binnen een paragraaf. Grotere suggesties met meerdere elementen die worden toegevoegd, aangepast of verwijderd is nu niet aan de orde. Dit kan gedaan worden door het document aan te passen in plaats van een grote suggestie te geven.

Kortom, suggesties zijn geen comments, maar zijn wel een onderdeel van het review proces. Suggesties hoeven alleen de tekst binnen een paragraaf aan te kunnen passen en niet het toevoegen, aanpassen en verwijderen van een of meerdere elementen te

ondersteunen.

Moet een comment toegevoegd kunnen worden aan een selectie?

Een opmerking kan in de standaard editor alleen worden toegevoegd op een punt. Dit heeft te maken met de huidige implementatie. De limitaties van deze implementatie zorgen ervoor dat het alleen mogelijk is om een comment alleen op een bepaald punt van het document te plaatsen. De huidige implementatie maakt gebruik van comments. Deze

draft-comments kunnen niet over een bepaalde selectie worden geplaatst doordat de huidige implementatie alleen de inhoud van de opmerking binnen de draft-comment tags staat. Dus de mogelijkheid om een comment toe te kunnen voegen over een selectie is iets wat graag wordt toegevoegd aan FontoXML. De huidige implementatie binnen de standaard editor voldoet alleen niet aan deze eisen en zal dus aangepast moeten worden.

Wat moet er gebeuren bij een error?

Allereerst is voorkomen uiteraard beter dan het geven van een error. Wanneer dit niet mogelijk is moet er kort, maar toch met genoeg detail voor de gebruiker, worden

doorgegeven wat er mis is gegaan. Daarnaast moet er beschreven staan wat de gebruiker moet doen om de fout zelf op te lossen of om hulp in te schakelen voor het oplossen van de fout. (Y. Bosselaar, interview, Februari 15, 2017)

Wat moet er gebeuren als een comment de server niet bereikt?

Zodra een server niet beschikbaar is terwijl een gebruiker een comment probeert te versturen, moet er een time-out komen om de client te stoppen met het versturen van de opmerking. Deze time-out mag niet te lang zijn, maar ook zeker niet te kort. Volgens Martin moet het plaatsen van een opmerking bijna direct gebeuren. (M. Middel, interview, Februari 21, 2017)

Wat moet er gebeuren als er meerdere comments op dezelfde plaats en tijd

worden geplaatst?

In de meest ideale situatie zou het niet uit mogen maken dat een comment op dezelfde plaats en tijd wordt geplaatst. Dit zou geen effect mogen hebben op het systeem. Helaas is dit niet mogelijk voor alle mogelijkheden die worden beschreven bij de eerste deelvraag van dit onderzoek.

4.2.1.1 Interviews

De interviews zijn om, zoals hierboven al vermeld staat, beter inzicht te krijgen van de ideeën binnen FontoXML. Maar dit biedt ook de mogelijkheden om achter mogelijke

beperkingen te komen. Deze beperkingen zullen worden afgewogen om uiteindelijk tot een oplossing te komen. Binnen deze paragraaf wordt allereerst een toelichting gegeven op de personen die zijn geïnterviewd binnen dit onderzoek, vervolgens wordt er per persoon een korte samenvatting gegeven.

Voorafgaand aan de interviews zijn er vragen opgesteld die behandeld worden tijdens een interview. Deze vragen zijn terug te vinden in het onderzoeksrapport. Tevens is de

uitwerking van de interviews te vinden in het rapport. Op basis van de uitwerking zijn de deelvragen in het onderzoek behandeld. De interviews die worden afgenomen hebben andere intenties en dus ook andere vragen. Terwijl het ene interview meer gericht is op de functionaliteiten die belangrijk zullen zijn voor de gebruikers, gaan de andere interviews meer over de technische wensen van het project.

Youri Bosselaar

Een van de interviews is gehouden met Youri Bosselaar, hij werkt als UX-designer. Dit houdt onder andere in dat hij zich bezighoudt met gebruikersonderzoek, trainingen geven en de requirements van FontoXML. Bij gebruikersonderzoek kijkt hij hoe de gebruikers van FontoXML de applicatie gebruiken en waar nog ruimte is voor verbetering. Na het uitrollen van de applicatie bij een bedrijf geeft Youri ook trainingen om nieuwe gebruikers wegwijs te maken met FontoXML. Als laatste houdt hij zich bezig met de requirements van de

applicatie, iets wat in verbinding staat met het gebruikersonderzoek.

Het interview met Youri was gericht op de wensen van de gebruikers van FontoXML. Zoals hierboven staat vermeld, werkt Youri mee aan de requirements voor het product. Dit was te merken tijdens het interview.

Mijn vragen waren gericht op mogelijke functionaliteiten rondom het plaatsen van

opmerking, zoals het reageren op een opmerking, het geven van feedback aan de gebruiker en het kunnen aanpassen van een document. Steeds gaf Youri aan wat de klanten van FontoXML zouden willen rondom deze onderwerpen.

Zo is het zeer gewenst om te reageren op opmerkingen, dit is echter in de huidige

implementatie niet mogelijk. Voor het geven van feedback, zou dit kunnen helpen voor de duidelijkheid aan de gebruiker, maar hiervoor is een implementatie zoals de vinkjes van Whatsapp overbodig. Verder is het in de ogen van Youri niet nodig om opmerkingen te kunnen plaatsen zodra een andere gebruiker het document aan het wijzigen is.

Tevens werd mij tijdens dit interview duidelijk dat de vraag naar opmerkingen niet heel groot was, toch zouden een aantal klanten goed gebruik kunnen maken van dit soort

functionaliteiten. Dit zijn vooral organisaties met een wat grotere workflow als het gaat om het opstellen van een document. Hierbij kan gedacht worden aan een workflow met een deel gereserveerd voor de review van het document.

Martin Middel

Een ander interview was met Martin Middel, hij werkt als developer voor het FontoXML platform. Martin richt zich voornamelijk op JavaScript binnen FontoXML. Verder is hij bezig met schema validatie en XPath binnen de organisatie. Martin staat verder van de klant dan Youri en kan dan ook meer informatie geven over de backend van het product.

De wensen van Martin hadden meer focus op de mogelijke functionaliteiten van de

applicatie. De opzet van dit interview had ik ook meer gericht op dit onderwerp, aangezien Martin een technische functie heeft binnen de organisatie. Martin heeft mij tevens inzicht kunnen geven in de architectuur van FontoXML, zoals is te zien in paragraaf 1.2.4 van dit document.

Tijdens het interview stelde ik een vraag met betrekking op databases, hierop kon Martin mij niet goed een antwoord geven, aangezien dit niet tot zijn functie behoort. Hierop wees hij me wel door naar Erik van Leeuwen, waar ik vervolgens ook een interview mee heb gehouden. Na het interview had Martin enkele aanvullingen, enkele functionaliteiten waren nog niet aan bod gekomen, waar ik toch eens over na zou moeten denken. Zo begon Martin over het archiveren van opmerkingen, ook had hij het over een mogelijkheid om te kunnen chatten met andere gebruikers over het document. Deze chatmogelijkheid zou het reviewproces een stuk sneller kunnen maken.

Erik van Leeuwen

Het laatste interview is gehouden met Erik van Leeuwen. Erik is net zoals Martin Middel een developer, maar wel op een heel ander terrein. Hij richt zich op dit moment op Advanced Track Changes binnen FontoXML, maar heeft zich in het verleden bezig gehouden met hosting architecturen en SaaS oplossingen.

Het interview met Erik van Leeuwen was meer gericht op de opslag van opmerkingen in een database. Mijn belangrijkste vraag aan Erik had dan ook betrekking op de opslagmethoden die binnen de organisatie al gebruikt werden en de mogelijke eisen die er gesteld zouden worden vanuit de organisatie. Het antwoord op deze vraag verbaasde mij lichtelijk, ook aangezien Martin had aangegeven dat er wel gewerkt wordt met NoSQL structuren. Erik zei dat het niet uitmaakt wat ik ga gebruiken. Zeker voor een prototype is het niet nodig om mij te binden aan een bepaalde structuur, hierbij moet ik gebruiken wat het beste uitkomt of wat het makkelijkste is om te gebruiken.

Toen ik Erik vroeg over zijn mening over opmerkingen, overviel ik hem daar een beetje mee. Het werd mij toen duidelijk dat mijn project niet bij iedereen bekend is binnen de organisatie. Hij verwees, net zoals zijn collega’s, naar het Internationaal Atoomenergieagentschap (IAEA) waar Liones een feedback portal voor heeft ontwikkeld. Dit is een platform waarop alle leden van het agentschap feedback kunnen geven op de documenten die geproduceerd worden.

4.2.1.2 Conclusie

Op basis van de criteria die eerder zijn opgesteld is het mogelijk om een oplossing te kiezen. Deze criteria zijn hieronder gevat in een tabel om zo de verschillende oplossingen te kunnen vergelijken.

Criteria OT DS CRDT Extern

Geschatte moeilijkheid van de implementatie

Complex Complex Complex Lastig

Heeft een server nodig om te functioneren Ja Ja* Ja Ja Impact op de architectuur Add-on Add-on Add-on Add-on

Voldoet aan gewenste features Ja** Ja** Ja** Ja

Tabel 4.1. Vergelijking van de criteria.

* Bij deze oplossing is voor iedere client een extra (shadow) document nodig.

** Opmerkingen worden opgeslagen in het document, met veel gearchiveerde opmerkingen kan dit een groot document opleveren.

Op basis van tabel 4.1 heb ik gekozen voor een externe service waarin de opmerkingen worden opgeslagen. Zoals is beschreven in paragraaf 4.1 van dit document is het

samenvoegen van XML complex doordat het document valide moet blijven, waardoor deze mogelijkheden zijn afgevallen. Tevens kunnen deze drie oplossingen leiden tot een groot document door vele gearchiveerde opmerkingen.

Door het kiezen van een oplossing met een externe service kwamen direct nieuwe vragen naarboven. Hiervoor is dan ook een tweede onderzoek gestart om deze vragen te kunnen beantwoorden. Dit tweede onderzoek is technischer en alleen gericht op de oplossing van het algemene onderzoek.

Het lostrekken van de comments uit het XML document heeft tot gevolg dat de comments op een bepaalde manier opgeslagen moeten worden. Tevens dienen deze opmerkingen

opgeslagen te worden met de juiste positie. Het opslaan van deze positie zal het moeilijkst zijn om correct op te slaan. Hierbij is het mogelijk dat de opmerkingen overal in het

document voor kunnen komen, deze kunnen geplaatst worden op een selectie van tekst of op hele elementen. Allemaal terwijl het document gewijzigd kan worden. Het aanpassen van deze posities wanneer het document wijzigt, zal complexe algoritmes nodig hebben om correct te kunnen functioneren.

4.2.2 Technisch onderzoek

Op basis van het algemene onderzoek wordt een technisch onderzoek verricht. Vooral belangrijk binnen dit onderzoek is het oplossen van vragen rondom de locatie van de comments. Naast de locatie van een opmerking wordt er ook gekeken naar mogelijke manieren om deze opmerkingen op te slaan. Ook wordt er gekeken welke technieken gebruikt kunnen worden om de locatie te waarborgen als het document wordt aangepast. Deze vragen hebben een gezamenlijke hoofdvraag. Deze hoofdvraag is “Hoe kan comment mapping binnen FontoXML worden geïmplementeerd?” De hoofdvraag wordt beantwoord op basis van twee deelvragen met een aantal subvragen. De deelvragen met de bijbehorende subvragen staan hieronder:

● Hoe kan de locatie van een comment gewaarborgd blijven?

○ Wat moet er gebeuren als een gebruiker (een deel van) een selectie aanpast waar een comment op staat?

○ Wat gebeurt als de plaats van de selectie veranderd?

○ Wat gebeurt als delen van de selectie waar de comment op staat wordt verplaatst?

○ Wat gebeurt als een andere editor het document aanpast? ○ Wat gebeurt als er een rollback plaatsvind?

○ Hoe wordt een comment gearchiveerd als de originele selectie niet meer bestaat?

● Welke technieken zijn beschikbaar om comments op de juiste plaats op te slaan? ○ Welke techniek past het beste?

○ Wat zijn de risico’s van de gekozen technieken?

Hoe kan de locatie van een comment gewaarborgd blijven?

Een opmerking kan gemaakt worden op een selectie van een stuk tekst. Deze selectie kan een (deel van een) woord bevatten, een zin of zelfs een hele paragraaf. De selectie vormt een ophangpunt voor een opmerking. Doordat er veranderingen plaatsvinden binnen een document kan het voorkomen dat dit ophangpunt van positie veranderd in het document. Met behulp van de subvragen wordt antwoord gegeven op verschillende situaties die plaats kunnen vinden als het document wijzigt.

Wat moet er gebeuren als een gebruiker (een deel van) een selectie aanpast waar een comment op staat?

De oplossing voor deze subvraag is vrij simpel, zodra er een aanpassing wordt verricht binnen het ophangpunt, zal deze zich aanpassen. Er zijn echter wel een aantal edge cases te behandelen bij het geven van deze oplossing.

Zo moet er nagedacht worden over wat er gebeurt als er op de rand van een ophangpunt iets wordt geplaatst. Alles wat buiten het ophangpunt gebeurt, wordt hier niet in opgenomen. Zodra de cursor naast het ophangpunt staat, zal er dus niets worden toegevoegd aan het ophangpunt van de opmerking. Niet aan de voorkant en niet aan de achterkant. Dit gebeurt ook niet als de toevoeging deel uitmaakt van het woord wat binnen het ophangpunt valt.

Wat gebeurt als de plaats van de selectie veranderd?

Logischerwijs zal hier gezegd worden dat de positie van het ophangpunt zal moeten veranderen zodra het document wordt gewijzigd. De exacte implementatie hiervan binnen FontoXML zal worden behandeld in paragraaf 4.2.

Zodra het document wijzigt, kan de positie van het ophangpunt veranderen. Dit kan

gebeuren binnen dezelfde paragraaf, maar het kan ook voorkomen dat er nieuwe paragrafen worden toegevoegd. Voor de implementatie kunnen deze twee wijzigingen verschillende gevolgen hebben.

Wat gebeurt als delen van de selectie waar de comment op staat wordt verplaatst?

Binnen FontoXML is het nog niet mogelijk om drag-and-drop te gebruiken. Echter, het moet wel mogelijk zijn om een opmerking te verplaatsen als deze wordt verplaatst door de selectie te knippen en te plakken. Hierbij moet wel de gehele selectie van de opmerking verplaatst worden. Als dit niet het geval is, zal het resterende deel van de selectie blijven staan en zal de selectie worden aangepast naar dit deel.

Als er delen gekopieerd worden uit de selectie waar een opmerking aan hangt, krijgen deze delen niet dezelfde opmerking mee. Binnen de implementatie zal een duidelijk verschil worden gemaakt tussen knippen en kopiëren van berichten. Bij kopiëren van selecties of delen daarvan worden opmerkingen niet meegenomen.

Wat gebeurt als een andere editor het document aanpast?

Zodra het document door een andere editor bewerkt wordt, zal er bij terugkomst in FontoXML gezocht moeten worden naar de selectie van de opmerking. Als het originele ophangpunt nog bestaat, moet zonodig de positie van deze selectie worden aangepast, zodat deze weer samenvalt met de laatste versie van het document.

Bestaat het originele ophangpunt niet meer, dan zal deze opmerking zonder selectie worden weergegeven. De gebruiker krijgt hier een melding van en kan op dat moment bepalen om de opmerking op te lossen. Tevens zou er ook een configuratie worden geïmplementeerd dat er voor zorgt dat dit automatisch wordt gedaan.

Wat gebeurt als er een rollback plaatsvind?

Bij een rollback wordt een oudere versie van een document teruggeplaatst. Na een rollback moet er opnieuw gekeken worden naar de ophangpunten van de opmerkingen in het document. Dit kan op dezelfde manier worden aangepakt als het bewerken van het

document in een andere editor. Er zal opnieuw worden gekeken of de selectie nog bestaat en waar nodig zal de positie worden aangepast.

Een rollback zal niet vaak voorkomen, hierdoor is gekozen om geen uitgebreide historie binnen de opmerkingen bij te houden. Door deze keuze zal er bij een rollback iets meer tijd nodig zijn om het document te laden, doordat de opmerkingen mogelijk geherpositioneerd moeten worden.

Hoe wordt een comment gearchiveerd als de originele selectie niet meer bestaat?

Zodra een opmerking wordt gearchiveerd, zal deze zijn selectie behouden. Deze selectie is ook te zien als de gearchiveerde opmerking wordt bekeken. Op deze manier heeft de gebruiker een idee waar de opmerking betrekking op heeft gehad.

Bij het terugplaatsen van een opmerking, zal deze selectie helpen bij het vinden van de positie. Deze selectie kan worden gezocht binnen het document, wordt deze gevonden dan kan de positie worden aangepast. Als de selectie niet terug wordt gevonden, zal deze opmerking zonder een ophangpunt te hebben worden geopend.

Welke technieken zijn beschikbaar om comments op de juiste plaats op te

slaan?

Binnen deze deelvraag wordt gekeken naar verschillende technieken voor het opslaan van het juiste ophangpunt van een opmerking. Deze technieken hebben elk voor- en nadelen, hierdoor kan er een afweging worden gemaakt welke het beste zou passen binnen dit project.

Diff algoritme

Een mogelijke techniek die gebruikt kan worden is het gebruik van een diff algoritme. Met dit algoritme kan het verschil tussen twee versies van een document worden bepaald. GNU Diff is het bekendste diff algoritme (Cobéna et al., 2004). Echter, dit algoritme is gebaseerd op het gebruik van tekst. XML is meer dan alleen tekst, dit heeft een boomstructuur en deze structuur moet behouden blijven.

Serialize - Deserialize

Bij dit idee worden alle posities op een centrale plaats opgeslagen. Zodra een gebruiker in FontoXML het document begint te wijzigen, worden alle posities opgevraagd van de server en worden deze tijdelijk opgeslagen in het geheugen. Zodra posities veranderen in het document, worden deze direct aangepast in het geheugen. Als het document wordt

opgeslagen worden ook de nieuwe posities van de opmerkingen in de database opgeslagen.

Absolute tekstpositie

Een manier om de positie van een selectie te kunnen bewaren kan gedaan worden door het opslaan van de absolute tekstposities van de selectie. Hierbij moet gedacht worden aan de positie van het begin van de selectie en van het einde van deze selectie.

Element id’s

Bepaalde schema’s hebben id’s binnen elementen. Door aan te nemen dat ieder element een uniek id heeft binnen het document, kunnen id’s gebruikt worden voor het bepalen van een positie. Het gebruiken van id’s is een gemakkelijke manier om de positie vast te leggen, maar heeft ook enkele nadelen.

Het eerste nadeel van deze oplossing is het probleem dat niet ieder schema gebruik maakt van id’s. Hierdoor zou deze oplossing niet schema onafhankelijk zijn, terwijl dit wel een van de requirements is vanuit FontoXML. Ook is het onzeker of binnen de schema’s die wel gebruik maken van een id elk id uniek is. Zodra er binnen een document meerdere

elementen met hetzelfde id voorkomen, zal deze methode niet functioneren zoals vooraf is bedoeld.

Tevens is het niet mogelijk om alleen deze manier te gebruiken, tenzij het hele element geselecteerd wordt. Zodra er een selectie wordt gemaakt binnen een element, zal er een combinatie met een andere techniek moeten worden toegepast. Een goede combinatie zou de bovengenoemde techniek zijn, het gebruik van de absolute tekstpositie.

XPath

In tegenstelling tot het gebruik van element id’s, is het gebruik van XPath wel schema onafhankelijk. XPath kan echter ook niet alleen worden gebruikt en heeft op dit vlak

hetzelfde probleem als het gebruik van id’s. Ook hier zou een combinatie met absolute tekst posities tot een goede oplossing leiden.

Met XPath kan specifieke informatie worden opgehaald uit een XML document. Voor FontoXML zal het element worden opgehaald dat staat opgeslagen en vervolgens zal verdere posities bepaald kunnen worden met de hulp van de absolute tekstposities.

Welke techniek past het beste?

Voor het kiezen van de beste techniek, moet worden gekeken naar de voor- en nadelen van de genoemde technieken. Binnen paragraaf 4.2 worden twee categorieën behandeld, deze zullen ook los behandeld worden van elkaar. De eerste categorie gaat over de manier waarop de opmerkingen opgeslagen kunnen worden in een externe service, terwijl de tweede categorie zich focust op de juiste positie van deze opmerkingen.

Eerste categorie

Binnen de eerste categorie vallen het diff algoritme en het serialize algoritme. Hierbij is volgens de requirements het diff algoritme de beste keuze voor het gebruik met een andere editor. Het serialize algoritme heeft als grootste nadeel dat het alleen binnen FontoXML zou kunnen werken, maar zal toch worden geïmplementeerd. Binnen FontoXML zal er gebruik worden gemaakt van deze oplossing doordat de posities makkelijk aangepast kan worden. Maar voor wijzigingen buiten FontoXML zal het diff algoritme gebruikt worden.

Het diff algoritme is niet de perfecte oplossing, aangezien hier ook enkele problemen kunnen zijn met de performance. Zodra het document groot wordt, zal het algoritme meer tijd nodig hebben om het verschil te kunnen bepalen. Ondanks de mogelijke performance problemen zal er toch voor dit algoritme gekozen worden.

Tweede categorie

Binnen de tweede categorie vallen het gebruik van absolute tekstposities, element id’s en XPath. Ook bij deze categorie zal een keuze gemaakt worden op basis van de requirements en ook hier is de onafhankelijkheid van FontoXML erg belangrijk.

Het gebruik van element id’s valt af, aangezien dit niet voldoet aan het idee omtrent de schema onafhankelijkheid. Aangezien FontoXML met meerdere schema’s werkt, moet de gekozen oplossing niet afhankelijk zijn van een bepaald schema. Hierdoor wordt het systeem niet zo flexibel als gewenst en zal er voor een andere schema aan een nieuwe oplossing gewerkt moeten worden.

Het nadeel van het gebruik van alleen absolute tekstposities is dat bij iedere wijziging de positie aangepast moet worden. Bij een combinatie van XPath en tekstpositie hoeft er alleen een wijziging plaats te vinden als er soortgelijke nodes bij zijn gekomen in het pad of als er tekst is gewijzigd binnen het element.

Wat zijn de risico’s van de gekozen technieken?

De technieken die gekozen zijn in de vorige subvraag van dit document bevatten enkele risico’s die in deze paragraaf worden besproken. Deze risico’s kunnen een belangrijke rol gaan spelen in het ontwerp van het prototype of zelfs de verdere ontwikkeling hiervan.

Diff algoritme

Het risico van het diff algoritme is de tijd die dit algoritme in beslag neemt. Zodra het algoritme te lang draait, kan dit als ergernis bij de gebruiker worden ervaren. Hiervoor zal een extra use case voor gemaakt worden om de exacte handelingen te beschrijven bij een te lang draaiend algoritme.

Serialize algoritme

Bij dit algoritme kan het voorkomen dat er te weinig geheugen beschikbaar is om alle opmerkingen tijdelijk lokaal op te slaan. Hierdoor zou FontoXML voor de gebruiker trager kunnen gaan werken. Om dit risico goed te kunnen onderzoeken moeten er testen worden uitgevoerd. Tijdens deze testen zou vastgesteld kunnen worden wat het limiet is van het aantal opmerkingen wat lokaal opgeslagen kan worden.

4.2.2.1 Conclusie

Binnen dit onderzoek worden er mogelijke technieken besproken om opmerkingen op te slaan naar een externe service en hoe de positie van een opmerking opgeslagen kan worden. Uiteindelijk is gekozen om voor een diff algoritme voor het bepalen van het verschil in de positie tussen versies buiten FontoXML. Binnen FontoXML is gekozen voor het gebruik van een serialize algoritme. Voor de positie zelf is er gekozen voor een combinatie van XPath en tekstpositie.

Voor de keuze van de technieken is gekeken naar de requirements voor het systeem. Op basis van deze requirements is gekozen voor technieken die aansluiten bij de eisen rondom de onafhankelijkheid van FontoXML. Het is belangrijk dat het systeem ook werkt als er aanpassingen worden verricht buiten FontoXML.

4.2.2.2 Advies

Na het afronden van het onderzoek zijn de uitkomsten hiervan voorgelegd aan de

opdrachtgever van dit project. Hierbij heb ik een informeel advies gegeven om de uitkomsten van het onderzoek door te zetten in het Proof of Concept. De opdrachtgever heeft besloten om dit advies vervolgens te volgen, waardoor ik mij kon gaan focussen op het ontwerpen, ontwikkelen en testen van een Proof of Concept.

De opdrachtgever had al eerder gehoord wat de mogelijke routes waren tijdens de wekelijkse voortgangsbespreking. Tijdens het gesprek ging hij akkoord met de gekozen route. Volgens de opdrachtgever sluit de gekozen route goed aan op het project en is de onderbouwing hiervoor voldoende. Ook de bijbehorende risicoanalyse geeft een goed beeld van zaken die mogelijk anders kunnen lopen dan vooraf bedacht wordt.