Figuur 4.1: High level werking van de architectuur
4.3 Opbouw van de architectuur
Het adaptief systeem uit Figuur 4.1 wordt opgebroken in meerdere componenten. Elk hebben ze een functie die essentieel is voor een goede werking van het systeem waarbij ook rekening gehouden wordt met de non-functional requirements zoals flexibiliteit en uitbreidbaarheid die in Sectie 4.1 besproken werden. Een eerste mogelijk probleem is welke data precies gebruikt wordt om te adapteren. Indien dezelfde soort dataobjecten als in de game gebruikt zouden worden voor analyse in het adaptieve systeem, zou het systeem sterk afhankelijk zijn van de game. Een wijziging van zo een dataobject in de game zal dan resulteren in wijzigingen in de rest van het systeem. Zo zou de score voorgesteld kunnen worden als een Integer die dan steeds doorheen het systeem gebruikt moet worden. Moest bijvoorbeeld deze Integer met de score van het spel veranderen naar een Float, zou in gans het systeem de Integer vervangen moeten worden door een Float. Hergebruik van het adaptief systeem in een nieuwe game zou moeilijker verlopen, omdat het systeem de specifieke soort dataobjecten van de vorige game gebruikt voor analyse. Tot nu toe werd nog geen rekening gehouden met het gebruik van externe bronnen voor gegevens. Indien ook deze gegevens gebruikt willen worden, zouden ze moeten omgezet worden naar de specifieke dataobjecten die gebruikt worden voor analyse. Dit zou echter betekenen dat de game zich ook moet bezighouden met de conversie van externe gegevens naar de specifieke dataobjecten. Dit is tegen het principe van separation of concerns, waar elke sectie in de software
32 HOOFDSTUK 4. GENERIEKE ARCHITECTUUR zich bezighoudt met maar één belang [39]. Bovendien zou de performantie van de serious game nadelig beïnvloed kunnen worden, moest het omzetten van de specifieke objecten erin gebeuren. Er is dus een component nodig die de conversie van een specifiek object naar een uniform object kan uitvoeren om zo het uniform object doorheen het systeem te kunnen gebruiken. Wanneer een gegeven uit de game dan verandert, hoeft enkel in de component, die zorgt voor de conversie, een wijziging aangebracht te worden.
Omwille van bovenstaande redenen, moeten gegevens voorgesteld worden door een uniform object in het adaptief systeem. Wanneer het adaptief systeem hergebruikt wordt, hoeven deze algemene objecten niet te veranderen. Een verandering van een object in de game, resulteert hier ook niet tot een aanpassing in het adaptief systeem. Uiteraard moeten gegevens van de game en van externe bronnen daarvoor eerst omgezet worden naar de objecten die gebruikt worden in het adaptief systeem en omgekeerd. Hiervoor wordt een eerste component voorzien, de interpreter. Deze component zorgt ervoor dat gegevens van de game en van externe bronnen geïnterpreteerd en omgezet kunnen worden naar uniforme objecten die door het adaptief systeem gebruikt worden voor analyse. Omgekeerd, wanneer het systeem objecten genereert, die opdrachten voor de game of analysedata bevatten, moeten deze geïnterpreteerd worden en omgezet worden naar opdrachten die de game kan begrijpen of naar data die in een systeem, dat statistische gegevens genereert, gebruikt kan worden.
De belangrijkste component is diegene die zorgt voor de analyse en het maken van beslissingen op basis van resultaten van deze analyse. Deze component, die ook in Sectie 2.4 besproken werd, wordt de adaptive engine genoemd. De objecten die de interpreter produceert na het interpreteren van de gamedata en de externe data komen hierin terecht. In de adaptive engine zullen zich één of meer modellen bevinden die de ontvangen gegevens van het spel of de externe bronnen zullen gebruiken. Zo kan een model gemaakt worden dat de gegevens analyseert en op basis van bepaalde adaptatiemethodes een nieuwe opdracht voor het spel selecteert. Er kan ook een model gemaakt worden dat alle gegevens verzamelt en hieruit analytische gegevens berekent en visualiseert. Om het systeem schaalbaar te maken kan gekozen worden om meerdere instanties van de adaptive engine te voorzien in het adaptief systeem. Dit zou kunnen nodig zijn wanneer meer dan één game gegevens naar hetzelfde adaptief systeem stuurt. Hoe dit kan
4.3. OPBOUW VAN DE ARCHITECTUUR 33 verwezenlijkt worden, wordt in sectie 4.4.3 duidelijk gemaakt. Soms is het mogelijk dat de games niet zoveel data produceren waardoor het aanmaken van een tweede adaptive engine een zwaardere operatie is dan het verwerken van de gegevens. In dat geval kan voor elk spel een apart model gemaakt worden in één adaptive engine die de nieuwe opdrachten voor elk spel zal genereren. Een gemeenschappelijk model kan de gegevens van alle games ontvangen en vervolgens hieruit globale statistieken genereren. Het gebruik van deze modellen laat toe om op veel verschillende manieren, met veel verschillende opties, games te adapteren.
Om ervoor te zorgen dat alle geïnterpreteerde gegevens op een correcte manier door een adaptive engine en de bijhorende modellen verwerkt kan worden, wordt nog een derde component voorzien. Deze component heet de integrator, wiens verantwoordelijkheid het is een bepaalde operatie van een bepaalde adaptive engine op te roepen voor een bepaald soort data. Zo een operatie kan vervolgens het ontvangen gegeven naar één of meerdere modellen sturen. Deze functionaliteit zou zich ook in de interpreter kunnen bevinden maar wordt best gesplitst om opnieuw separation of concerns te verzekeren [39]. Door de selectie van operaties in een aparte component te steken, kan een adaptive engine gemakkelijk wisselen van operaties waarna enkel een aanpassing in de data integrator nodig is. Hier moet dan enkel de mapping van een bepaald soort data op een operatie van de adaptive engine aangepast worden. Wanneer veel gegevens en veel analyse nodig is, kan het beter zijn om meerdere adaptive engines te voorzien om zo de belasting op één adaptive engine te verlagen. In de integrator kan, wanneer er meerdere adaptive engines gebruikt worden, beslist worden welk gegeven in welke adaptive engine terechtkomt. Hierdoor kan in de integrator gezorgd worden voor het balanceren van belasting wanneer met veel gegevens gewerkt wordt.
Zoals te zien is in Figuur 4.2, kan deze architectuur een hoge doorstroom aan gegevens heb- ben. Zeker wanneer real-time adaptiviteit, zie Sectie 2.2.2, aan de orde is, zal een grote hoe- veelheid data door de componenten heen stromen. Om de berichten zo efficiënt mogelijk tussen de verschillende componenten te sturen kan gebruikt gemaakt worden van het eerder besproken
observer-pattern.
34 HOOFDSTUK 4. GENERIEKE ARCHITECTUUR adaptatie. Zij moeten echter, telkens wanneer nieuwe gegevens van de game of externe bronnen beschikbaar zijn, de gegevens omzetten naar objecten die bruikbaar zijn voor de adaptive engine. Dankzij het observer pattern hoeven de interpreters zich enkel te registreren voor data waarin zij geïnteresseerd zijn. Zo kan de interpreter die staat voor het omzetten van gegevens uit de game zich registreren als observer bij bijvoorbeeld de score van de game. Telkens wanneer de score verandert, meldt de game de verandering aan de interpreter waarna de score kan opgehaald en geïnterpreteerd worden worden. Wanneer offsite adaptatie gebruikt wordt, zijn klassen niet lokaal beschikbaar en kan dit minder eenvoudig gehanteerd worden. Bij andere componenten die lokaal gegevens uitwisselen in het systeem, past dit patroon ook.
Figuur 4.2: Gedetailleerdere opbouw van de architectuur