Molapse Poor man s MOLAP

Transcriptie

1 Molapse Poor man s MOLAP Freark van der Berg, (s ) f.i.vanderberg@student.utwente.nl Robert Dahmen, (s ) r.j.dahmen@student.utwente.nl Harold Bruintjes, (s ) h.y.bruintjes@student.utwente.nl Sandra Drenthen, (s ) s.drenthen@student.utwente.nl Cecill Etheredge, (s ) c.e.etheredge@student.utwente.nl 18 juli 2009

2 Inhoudsopgave 1 Inleiding Achtergrond Aanleiding Visie Indeling Analyse Domeinanalyse Probleem/doel Bestaande software Gebruikers Omgeving Requirementanalyse Functionele eisen Niet-functionele eisen Grafisch Scenarioanalyse Scenario 1 - Jaar met hoogste cijfers Scenario 2 - Plaats met hoogste cijfers Scenario 3 - Moeilijkste vak voor Student Scenario 4 - Kijkcijfers Architectureel ontwerp Keuzes Structuur Talen Libraries Gedetailleerd ontwerp Interface Globaal Input Grid Dimensielijst Options Oriëntatietool i

3 4.1.7 Manipulatie Aggregates Animaties Grafisch ontwerp Globaal Grid GUI Database Configuratie Testen Acceptatietest Visualisatie Besturing Standaard OLAP-operaties Diverse databases Scenario-testen Scenario 1 - Jaar met hoogste cijfers Scenario 2 - Plaats met hoogste cijfers Scenario 3 - Moeilijkste vak voor Student Scenario 4 - Kijkcijfers Compatibiliteit Evaluatie Begeleiding Planning Samenwerking Communicatie Eindresultaat Conclusie Verklarende Woordenlijst 34 Glossary 36 Bibliografie 36 A Diagrammen 37 B Handleiding 41 B.1 Compileren van de software B.2 Starten van de software B.3 Input B.4 Betekenissen en werking B.5 Databases B.5.1 Veranderen van database B.5.2 Nieuwe database aanmaken ii

4 Hoofdstuk 1 Inleiding 1.1 Achtergrond In dit project staat het begrip on-line analytic processing centraal. Onder de naam OLAP biedt deze databasetechnologie de mogelijkheid om op een snelle en efficiënte manier multidimensionale databases te analyseren. Kort gezegd houdt dit voor ons geval in dat informatie uit een complexe database kan overzichtelijk worden weergegeven via een driedimensionale spreadsheet. OLAP wordt door veel bedrijven gebruikt om nuttige informatie te extraheren uit grote databases met ruwe data. Door middel van een aantal standaardoperaties - slice, dice en rollup - is de ruwe data om te vormen tot bruikbare informatie die bijvoorbeeld gebruikt kan worden om de efficiëntie van de bedrijfsvoering te verhogen of bij het ontdekken van trends bij veiligheidsvraagstukken, criminaliteitbestrijding of milieu-analyse [Dix08, MAM06]. 1.2 Aanleiding Dhr. M. van Keulen is docent van het vak Data Warehousing and Data Mining waarin de theorie van OLAP wordt behandeld. Om voor studenten een duidelijk beeld te scheppen wat OLAP precies inhoudt, is er software nodig die de werking van OLAP op een database kan visualiseren. Het gebruik van dergelijke software zou studenten helpen om de achterliggende theorie te begrijpen omdat, zoals het spreekwoord luidt, een plaatje meer zegt dan duizend woorden. Ruim voor de start van het ontwerpproject staat de samenstelling van het team vast. Dit team, bestaande uit mensen met ervaring in verschillende richtingen als graphics en scripting, kan zich goed vinden in de keuze voor het ontwerpproject. Daarnaast wordt extra motivatie gevonden in het feit dat het uiteindelijke product ook daadwerkelijk in collegezalen gebruikt zal gaan worden. 1

5 1.3 Visie Voor dit ontwerpproject is in het voorgaande jaar door een ander team reeds een implementatie ontwikkeld en afgeleverd. Deze eerdere versie bleek helaas niet geheel aan de verwachtingen te voldoen door problemen met onder andere de grafische weergave en de gebruikersinterface. Voor het doeleinde van dit project zijn beide punten echter van belang, omdat zonder een duidelijke grafische weergave de werking van OLAP niet duidelijk zal zijn. Ook wanneer het niet duidelijk is welke invloed de gebruikersinterface op het weergegeven model heeft, zal dit het begrip onder studenten belemmeren. Omdat ons team reeds ervaring heeft met het ontwikkelen van grafische software, verwachten wij echter een zeer degelijk en bruikbaar product af te kunnen leveren dat aan alle gestelde verwachtingen zal voldoen. 1.4 Indeling Dit verslag beschrijft het ontwerpproces van dit project. In hoofdstuk 2 wordt begonnen met de analyse: het gedetailleerd bepalen van de eisen en het doel van het project. Hierna komt het architectureel ontwerp (hoofdstuk 3) aan bod waarbij in grote lijnen wordt opgesteld wat er moet gebeuren om de eerder gestelde doelen te bereiken. Vervolgens wordt dit in het gedetailleerde ontwerp (hoofdstuk 4) verder uitgewerkt tot het algehele ontwerp, waarna tot de daadwerkelijke implementatie kan worden overgegaan. Het geïmplementeerde prototype wordt vervolgens getest (hoofdstuk 5) en tot slot kijken we terug op het hele proces voor de totstandkoming van het prototype in de evaluatie (hoofdstuk 6). 2

6 Hoofdstuk 2 Analyse 2.1 Domeinanalyse Probleem/doel Het doel van het project is het ontwerpen van een stuk software dat in staat is om het effect van OLAP operaties op een multidimensionale database te visualiseren. De software dient de data uit een onderliggende database driedimensionaal weer te geven door middel van een matrix van kubussen of cellen, de zogenaamde grid. Deze grid dient, naast gedraaid en vergroot of verkleind te kunnen worden, de meest belangrijke OLAP-operaties (zie paragraaf 2.2.1) weer te kunnen geven. Verder zullen er diverse voorbeelddatabases bijgeleverd worden waarmee de verschillende doeleinden van OLAP gedemonstreerd kunnen worden Bestaande software PowerOLAP PowerOLAP is professionele OLAP software die zich vooral op efficiëntie en gebruikersgemak richt en zich daarbij niet bezighoudt met het duidelijk visualiseren wat het effect van alle operaties is die uitgevoerd worden. Dit is niet nodig bij de doeleinden waar deze software voor wordt gebruikt: het daadwerkelijk gebruiken van OLAP en het extraheren van bruikbare informatie uit enorme databases. Het gebrek aan sprekende visualisatie maakt dit softwarepakket ongeschikt voor OLAP demonstraties tijdens colleges. Daarnaast maakt PowerOLAP slechts gebruik van tweedimensionale spreadsheets om de data inzichtelijk te maken [PAR]. Koffie Koffie is het prototype ter visualisering van MOLAP dat door het voorgaande team is ontworpen. De software voert OLAP operaties uit, maar de visualisering van deze operaties laat ernstig te wensen over. Omdat deze visualisering uitermate belangrijk is, blijkt Koffie praktisch ongeschikt om voor dit doeleinde gebruikt te worden. Echter blijken de tekortkomingen van deze software wel waardevol tijdens het ontwerpproces van onze software. 3

7 2.1.3 Gebruikers De te ontwerpen software is bedoeld voor educatieve doeleinden en zal tijdens hoorcolleges van Dhr. M. van Keulen worden gebruikt om studenten een beeld te geven van de theorie achter OLAP en hoe deze gebruikt kan worden om een overvloed aan informatie inzichtelijk te maken Omgeving De software zal gedraaid worden op het systeem dat door de docent of de betreffende collegezaal ter beschikking wordt gesteld. 2.2 Requirementanalyse Functionele eisen Operaties R1: Aggregatie: Het programma zal bij het weglaten van bepaalde dimensies verschillende standaard SQL-operaties op deze dimensies kunnen uitvoeren om zodoende alle betreffende waarden samen te voegen. SUM: Het sommeren van de waarden. AVG: Het middelen van de waarden. MIN: Het minimum van de waarden. MAX: Het maximum van de waarden. R2: Slice: Het selecteren van een slice - een groep aaneensluitende cellen - over de drie verschillende assen. R3: Dice: Het selecteren van een enkele cel waarvan vervolgens meer data worden getoond uit de dimensies die voorafgaand aan de dice waren opgerold. In het geval dat er meer dan drie dimensies bestaan zal de mogelijkheid worden geboden om te selecteren welke dimensies er getoond worden en welke overige dimensies zullen worden samengevoegd. R4: Roll-up: Het samenvoegen van elementen met gelijke waarde in een dimensie met behulp van een geselecteerde standaardoperatie. R5: Drilldown: Het uitbreiden van een slice tot een nieuwe matrix van kubussen door middel van het uitklappen van een eerder samengevoegde dimensie. 4

8 R6: Pivot: De kubus moet ook gedraaid kunnen worden om de data die men wil uitlezen in beeld te krijgen. R7: Ongedaan maken: Voor het gebruiksgemak moeten al deze operaties ook ongedaan gemaakt kunnen worden. Grafisch R8: Animaties: Het duidelijk visualiseren van OLAP-operaties is de reden dat dit project opnieuw gedaan wordt. Het is dus belangrijk dat de animaties op een overzichtelijke manier weergeven hoe de data wordt gemanipuleerd en wat het resultaat van deze manipulatie is. R9: Driedimensionale weergave: Het weergeven van de multidimensionale database door middel van een driedimensionale matrix van kubussen of cellen. Gezien de technische en praktische limitaties bij het weergeven van meer dan drie dimensies zijn we van mening dat drie voorlopig voldoende overzichtelijkheid biedt. Overige dimensies worden daarom opgerold met behulp van de eerder genoemde aggregaatoperaties. R10: Aggregaties: De mogelijkheid om cellen met aggregatiedata weer te geven die voor elke rij, over elke as, een totaal weergeven met behulp van de eerder genoemde aggregaatoperaties. R11: Interface: De interface moet duidelijk ingericht en intuïtief voor de gebruiker zijn, om deze niet af te schrikken met vreemd gedrag Niet-functionele eisen Algemeen R12: Lichtgewicht: Om de software ook op oudere systemen bruikbaar te houden zullen er niet onnodig veel resources gebruikt worden. R13: Multiplatform: Om het gebruiksgemak of portabiliteit te vergroten zal de software op diverse besturingssystemen waaronder Microsoft Windows TM en Linux draaien. R14: Onderhoudbaarheid: De broncode van de software zal juist gedocumenteerd zijn en zal modulair gebouwd worden opdat in een later stadium componenten mogelijk uitgebreid, vervangen of toegevoegd kunnen worden. Ook het aanmaken en beheren van voorbeelddatabases is mogelijk met juist geformatteerde tekstbestanden. 5

9 R15: Betrouwbaarheid: De database wordt handmatig aangepast en de software zal uitgaan van de correctheid en volledigheid van de gegeven informatie. Gegeven dat aan deze eigenschap voldaan wordt, zal de software zich goed en foutloos laten schalen en gebruiken. R16: Responstijd: Ondanks dat de software mogelijk op oudere systemen gebruikt zal gaan worden, zal het systeem vlot en vloeiend reageren op wijzigingen om de werking van OLAP zo intuïtief mogelijk weer te geven Grafisch R17: Kwaliteit: Het grafische component zal degelijk en overzichtelijk worden vormgegeven. Alle weergegeven data binnen en buiten de kubus zullen goed leesbaar zijn. Tevens zal de koppeling tussen de assen in de matrix en geselecteerde dimensies duidelijk worden weergegeven. R18: Onderscheidend: Visuele elementen zullen goed onderscheidbaar zijn, gegeven het programma uiteindelijk getoond zal worden via een beamer. Hierbij valt te denken aan combinaties van kleuren met duidelijk contrastverschil. Hardware R19: Grafisch: Vanwege technische limitaties van oudere grafische kaarten is het niet mogelijk om de driedimensionale visualisatie op deze kaarten efficiënt genoeg te implementeren. De minimale systeemeisen voor de software houden daarom onder meer een grafische kaart van het type NVIDIA GeForce TM 6 (of hoger) in. Deze eis stamt uit het gebruik van Vertex Textures, een feature die slechts in nieuwe kaarten wordt ondersteund [GFG04]. Of met de systemen in de collegezalen ook aan deze eis wordt voldaan is onzeker; de computers in de practicumruimtes voldoen echter wel. R20: Geheugengebruik: De software zal gebruikt worden bij databases die klein in omvang zijn, met ten hoogste 2500 elementen. Omdat de software portable is, zal deze dan ook niet meer dan 20 MiB schijfruimte in beslag nemen. Het geheugengebruik zal niet hoger zijn dan 1 GiB; oudere systemen beschikken veelal niet over zodanige hoeveelheid intern geheugen. Database R21: Beschikbaarheid: Omdat de software portable is, zal er geen sprake zijn van afhankelijk van een internetverbinding of databaseserver. De database zal bij voorkeur lokaal draaien om de werking te garanderen op plekken waarbij eerder genoemde diensten niet beschikbaar zijn. 6

10 R22: Dynamisch: De software zal bij voorkeur om kunnen gaan met verschillende databases, ongeacht of er tijdens het ontwerpen rekening gehouden is met een specifieke databaseontwerp. Zolang de database volledig en juist geformatteerd is, zal het door de software kunnen worden ingeladen. R23: Meerdere voorbeelddatabases: Door verschillende voorbeelddatabases te leveren zullen verschillende situaties kunnen worden getoond, zodat het begrip van de student zal toenemen. Het kunnen aanmaken van nieuwe voorbeelddatabases zou hierop een nuttige aanvulling zijn. 2.3 Scenarioanalyse Bij het testen van de end-user beleving wordt in plaats van use cases gebruik gemaakt van scenario s. Het verschil is dat een use case een enkele stap beschrijft, terwijl een scenario een hele reeks handelingen achter elkaar laat uitvoeren. Omdat de reactie van de software afhangt van wat er hiervoor voor handelingen zijn verricht, is het testen van scenario s hier het meest geschikt. Figuur 2.1: De indeling van de tabellen in de Grades voorbeelddatabase De Grades voorbeelddatabase bestaat uit vier tabellen: University, Course, Time en Student. Ieder hebben voor de hand liggende subdimensies waarop gegroepeerd kan worden. Hierbij moet gedacht worden aan Naam en Plaats voor University, Vaknaam en Docent voor Course, Naam en Studentnummer voor Student en Jaar en Kwartiel voor Time. Deze indeling van dimensies en subdimensies van de Grades voorbeelddatabase is te zien in Figuur 2.1. Bij alle scenario s hieronder wordt gebruik gemaakt van deze voorbeelddatabase Grades, be- 7

11 halve bij het laatste scenario Scenario 1 - Jaar met hoogste cijfers De gebruiker is een docent die wil zien in welk jaar de hoogste cijfers voor zijn vak gehaald zijn. 1. Start het programma. 2. Zorg dat van de dimensie Course het detailniveau Teacher is. 3. Zorg dat van de dimensie Time het detailniveau Year is. 4. Aggregeer Course en Time niet. 5. Aggregeer Student en University met Average. 6. Draai eventueel de grid opdat alle waardes goed leesbaar zijn. 7. Slice de kolom met de gewenste Teacher. 8. Kijk in welk jaar het hoogste gemiddelde is gehaald Scenario 2 - Plaats met hoogste cijfers De gebruiker is een student die wil zien welke plaats met Universiteit(en) jaarlijks het best presteert gekeken naar het gemiddelde cijfer. 1. Start het programma. 2. Stel het detailniveau van University in op City. 3. Stel het detailniveau van Time in op Year. 4. Stel de aggregate van Course en Student in op Average. 5. Draai eventueel de grid om het goed uitleesbaar te maken. 6. Lees uit hoe elke universiteit ieder jaar gepresteerd heeft. 7. Aggregeer eventueel Time met Average of Max om te kijken naar respectievelijk het gemiddelde of het maximum over alle jaren Scenario 3 - Moeilijkste vak voor Student De gebruiker is een studiebegeleider die wil weten met welk vak een student op een zekere universiteit het meeste moeite heeft. 1. Start het programma. 2. Zet het detailniveau van Student op StudentName. 3. Zet het detailniveau van Course op CourseName. 4. Zet het detailniveau van University op UniversityName. 5. Slice de juiste University. 6. Slice de juiste Student. 7. Aggregeer Time met Average. 8. Lees uit met welk vak de student het meeste moeite had door te kijken naar het laagst behaalde cijfer. 8

12 2.3.4 Scenario 4 - Kijkcijfers Bij dit scenario wordt gebruik gemaakt van de Ratings voorbeelddatabase, welke weergeeft wat de kijkcijfers waren voor televisieshows per demografische groep. De Ratings database bestaat uit vier tabellen: Country, Show, Demograph, Gender. De detailniveaus van elke tabel zien we als volgt: Country heeft Landsnaam en Continent. Show heeft Shownaam, Zender en Genre. Demograph heeft de leeftijdsgroep en Gender is Man of Vrouw. De gebruiker is een reclamebureau, die wil weten bij welke show in Nederland reclametijd moet worden ingekocht om jongeren zo goed mogelijk te bereiken. 1. Start het programma. 2. Zet het detailniveau van Country op CountryName. 3. Slice Nederland als Country. 4. Zet het detailniveau van Show op ShowName. 5. Zet het detailniveau van Demograph op AgeGroup. 6. Slice Jongeren als Demograph. 7. Aggregeer Gender met Average. 8. Kijk nu in de overgebleven rij naar het hoogste kijkcijfer. 9

13 Hoofdstuk 3 Architectureel ontwerp 3.1 Keuzes Om tot een architectureel ontwerp te komen heeft het team op een groot aantal gebieden keuzes gemaakt. De totstandkoming van deze beslissingen staat hieronder beschreven Structuur Model-View-Controller Volgens het ontwerppatroon Model-View-Controller, zoals beschreven in [Ree03], wordt het programma in drie componenten verdeeld: de model, view en controller. Dit patroon sluit goed aan bij de modulaire structuur van onze software. Als bijkomstigheid kunnen de onderdelen verdeeld worden over teamleden van dit project, waardoor iedereen zich kan specialiseren op zijn of haar eigen onderdeel. Het model is een multidimensionale database, welke aangesproken wordt door de controller. De controller geeft vervolgens de opdracht aan de view om deze informatie overzichtelijk weer te geven. De gebruiker kan aan de controller opdrachten tot OLAP-operaties doorgeven. Deze informatie komt bij de controller binnen die aan de database de staat na de bewerking opvraagt en deze vervolgens doorstuurt naar de view. Deze verdeling is te zien in Figuur Talen C++: C++ is een object-georiënteerde programmeertaal gebaseerd op C die uitermate geschikt is voor het implementeren van software waarbij performance en efficiëntie van belang is. In tegenstelling tot programmeertalen als Java introduceert C++ geen extra abstractielagen tussen de hardware en onze software, waardoor er niet alleen voor de grafische weergave maar 10

14 Figuur 3.1: De Model-View-Controller verdeling van het project ook het koppelen van de libraries, die hieronder genoemd worden, een directere aanpak voor implementatie mogelijk is. SQL: SQL is de facto standaard voor het opvragen en aanpassen van informatie in relationele databases. MDX is een alternatieve taal, die speciaal gecreëerd is voor het gebruik met OLAP. Echter is er geen MDX library die voldoet aan de portability eis en heeft het team reeds ervaring met SQL, wat tot de keuze voor SQL logischer maakt. Bennu: Voor de controller van de software bestaat de keuze uit het gebruik van een programmeertaal zoals C/C++ of een scripttaal als Lua of Bennu. Deze laatste hebben als voordeel dat alle programmacode in een interpreter wordt uitgevoerd en zich daarom beter leent voor het eenvoudig aanpassen en testen van code, wat weer ten gunste komt van de ontwikkeling. In veel gevallen, waaronder Bennu, is de interpreter geschikt om gedraaid te worden op diverse platformen. Bennu is een scripttaal die ons een voordeel biedt met van het gebruik van processen, de implementatie van threads op scriptniveau, die het mogelijk maken om onder andere animaties te parallelliseren. Deze parallellisatie zorgt ervoor dat meerdere animaties onafhankelijk van elkaar kunnen worden uitgevoerd en zodoende vlekkeloos in elkaar over kunnen lopen en kunnen worden gemengd. Het verbinden van extra functionaliteit in de vorm van libraries is zeer eenvoudig. De koppeling tussen Bennu (controller) en de overige libraries (model en view) blijft op deze manier dan ook beperkt tot een lichte taak. 11

15 3.1.3 Libraries SQLite Deze lichtgewichte open-source library laat zich heel gemakkelijk integreren en draait in tegenstelling tot andere libaries als MySQL en PostgreSQL in een lokaal proces in plaats van een server. SQlite slaat de gehele database op in een enkel bestand, welke eenvoudig mee te nemen is, of in het geheugen van het lokale proces. In het laatste geval neemt de responsiviteit ook in hoge mate toe omdat er praktisch geen informatie wordt weggeschreven. SDL (Simple DirectMedia Layer) SDL is een abstractielaag tussen de software en het besturingssysteem dat het ontwikkelen van platformonafhankelijke software bevordert. SDL heeft zichzelf bewezen als een goede library voor het afhandelen van invoer en uitvoer vanwege zijn efficiëntie en gemak. Verder is SDL reeds in Bennu geïntegreerd, wat het gebruik van deze functionaliteit vergemakkelijkt. OpenGL Deze openbare en gestandaardiseerde specificatie wordt gebruikt voor alles omtrent de grafische weergave van de software. Het alternatief, Direct3D, valt af omdat deze niet voldoende ondersteuning biedt voor meerdere platformen. Vanwege eerdere ervaringen met OpenGL is de keuze dan ook logisch. 12

16 Hoofdstuk 4 Gedetailleerd ontwerp 4.1 Interface Globaal De layout van de GUI (Graphical User Interface) is samen met het model te zien in Figuur 4.1. Deze layout bestaat uit de dimensielijst (linksboven), het operatiemenu (linksonder) en de orientatietool (rechtsonder). De visualisatie van de database, waarin de resultaten van de operaties zichtbaar zijn, is te vinden in het midden van het scherm. Figuur 4.1: Een impressie van de software, bestaande uit de weergave van het model en de interface. 13

17 4.1.2 Input Het toetsenbord en de muis vormen het gereedschap van Molapse. Hiermee kan de GUI worden bediend, instellingen gewijzigd en operaties uitgevoerd. De voornaamste input is afkomstig voor de muis; het programma is bijna volledig met de muis te besturen. Op het keyboard zitten extra mogelijkheden: het maken van een screenshot, discomodus, isometrische modus, automatische rotatie van de grid en opslaan en laden van de staat van de Grid. De verschillende inputmogelijkheden zijn hier uiteengezet en toegelicht. Voor een interface is het belangrijk dat de mogelijkheden intuïtief zijn, omdat de gebruiker dan minder hoeft te wennen aan vreemde mogelijkheden en hierdoor niet wordt afgeschrikt. De interface is daarom eenvoudig gebleven. Linkermuisknop Ingedrukt houden in combinatie met een muisbeweging zorgt voor rotatie van de weergave. Opties (bijvoorbeeld checkboxes of radiobuttons) kunnen worden geselecteerd. Rechtermuisknop Door te klikken op het grid of de achtergrond wordt de geselecteerde actie in het operatiemenu respectievelijk uitgevoerd of ongedaan gemaakt. Door te klikken op de teksten in de dimensielijst wordt een menu getoond waarin respectievelijk een operatie (voor detail of aggregaat) geselecteerd kan worden. Scrollwielknop Verandert de huidige geselecteerde as waarop operaties worden uitgevoerd. Scrollwiel omhoog/omlaag Zorgt voor het in- en uitzoomen van de weergave. Naast input van de muis is er een aantal toetsen met functionaliteit. Deze zijn hieronder omschreven. 14

18 Escape Sluit het programma af. Escape is een zeer gebruikelijke methode om een programma af te sluiten en kan daarom bij Molapse niet ontbreken. + Zoomt in. Werkt voor de reguliere + en de + op het numpad. - Zoomt uit. Werkt voor de reguliere - en de - op het numpad.. S D I A F11 F12 Maakt screenshot. Een screenshot is een grafische uitdraai van wat er zich op dat moment in het venster bevindt. Schakelt discomodus aan/uit. Deze modus laat zien dat de grid veel snelle kleurveranderingen ondersteunt en toont mogelijkheden voor toekomstige functionaliteit door de kleur van een cel af te laten hangen van de waarde in die cel. Schakelt isometrische modus aan/uit. Deze modus vervangt het perspectief met een orthografische/isometrische weergave waar de diepte van een object geen effect heeft op grootte van de projectie. Deze modus is enkel als experiment toegevoegd om te bepalen of de leesbaarheid van de informatie op deze manier wordt vergroot. Helaas is dit vaak niet het geval omdat enkel de buitenste cellen van de grid goed zichtbaar zijn. Schakelt automatisch ronddraaien aan/uit. Deze modus biedt mogelijkheden voor een demonstratie. Slaat huidige staat van het model op. De eerder opgeslagen staat wordt verwijderd. Laadt de laatst opgeslagen staat van het model. Indien er geen opgeslagen staat is of indien deze niet in te laden is, wordt er niets veranderd Grid De grid, de rode matrix dat de driedimensionale weergave van de database verzorgt, is te vinden in het midden van het scherm. In paragraaf is te lezen dat deze grid op diverse manieren te manipuleren is. Voor het koppelen van de linkermuisknop aan de rotatie is gekozen omdat dit het meest natuurlijk is; de meest primaire functionaliteit is geplaatst op de meest primaire muisknop. De rechtermuisknop is gekozen voor het uitvoeren van de actie, omdat dit na het roteren de meest primaire actie is en zodoende een prominente plaats eist. Het scrollwiel leent zich uitstekend voor het in- en uitzoomen van de grid. Dan rest nog het veranderen van de as en is er nog één knop over op de muis: de scrollwielknop, ook wel de middelste knop genoemd. 15

19 Figuur 4.2: Initieël concept (links) en uiteindelijke implementatie van de dimensielijst (rechts) Dimensielijst Het eerste concept van de dimensielijst is te zien in Figuur 4.2. Elke rij behoort tot één dimensie. Aan de linkerkant van een rij is de naam van de dimensie te zien; daarnaast bevindt zich een dropdownlijst waaruit de aggregaatoperatie gekozen kan worden; het derde element is een dropdownlijst waaruit het detailniveau van de dimensie gekozen kan worden; als laatste is er een vierkant waarmee de dimensie heen en weer gesleept kan worden. Via het slepen kan de volgorde van de dimensies worden bepaald. Deze lijst is van groot belang voor het beheren van wat er in de grid getoond moet worden. Het selecteren van het detailniveau en het veranderen van een aggregaatoperatie zijn alleen in dit menu mogelijk. Daarnaast speelt de volgorde van de dimensies een grote rol bij aggregaatoperaties als Min en Max. Dit probleem is gemakkelijker uit te leggen aan de hand van een voorbeeld. Neem de volgende tweedimensionale matrix. as X Y Wanneer eerst de X as wordt opgerold met de aggregaatoperatie Max en daarna Y met Sum, dan is het resultaat = 5. Wanneer dit andersom gedaan wordt: eerst Y met Sum en X met Max, dan is het resultaat max(2, 4) = 4. De verschillen met de uiteindelijke versie in Figuur 4.2 zijn gering. Omdat de gebruikte GUI library geen dropdownlijsten ondersteunt, is er gekozen voor een menu dat getoond wordt zodra op de rechtermuisknop geklikt wordt. Het vierkant waarmee gesleept zou kunnen worden is vervangen door twee aparte knoppen, die de desbetreffende dimensie één omhoog of één omlaag laten bewegen. Dit is gedaan omdat het aanzienlijk eenvoudiger te implementeren en niet minder intuïtief te begrijpen is Options Hier bevinden zich de opties voor het selecteren van de operaties voor de aggregates en het selecteren van de editmodus zoals wordt beschreven in paragrafen en Het selecteren van de editmodus kan door middel van een drietal radiobuttons. De radiobuttons 16

20 maken het mogelijk dat slechts één van de opties geselecteerd kan worden. Het selecteren van de Base Operation heeft invloed op de aggregatie van de waardes indien een detailniveau wordt gebruikt Oriëntatietool Met dit kompas is getracht de navigatie voor de gebruiker te vergemakkelijken: het toont de oriëntatie van de assen, geeft aan welke dimensies er op die assen zitten en laat zien welke as momenteel geselecteerd is. Omdat het kompas meedraait met de grid, is dit te alle tijden goed te zien Manipulatie Slice De werking van een slice hangt af van de geselecteerde as. Het uitvoeren van eenslice gaat als volgt: 1. Selecteer de slice modus (zie Edit Mode). 2. Klik en houd rechtermuisknop vast boven één van de slices die gewenst zijn. 3. Sleep de muiscursor zodanig dat hij zich boven een andere slice bevindt. 4. Laat de rechtermuisknop los. Hierdoor worden de slices die zijn aangewezen en alle daartussen opgelicht uit de grid. Overige slices zullen worden weggehaald. Unslice De werking van een unslice hangt af van de geselecteerde as. Om een dimensie vrij te maken vanslices, is het mogelijk een unslice uit te voeren en dit gaat als volgt: 1. Selecteer de slice modus (zie Edit Mode). 2. Klik met de rechtermuisknop naast de grid, dus op de (zwarte) achtergrond. Dit zal alleslices op de huidig geselecteerde as verwijderen en zodoende de gehele dimensie met de huidige detail tonen. Dice Het uitvoeren van een dice gaat als volgt: 1. Selecteer de dice modus (zie Edit Mode). 2. Klik met de rechtermuisknop op een box. De dimensies op de huidige assen (posities 1, 2 en 3) zullen de rollup SQL SELECT krijgen, met als geselecteerd waarde die van de geselecteerde box. Vervolgens zullen tot drie dimensies toe de rollup SQL NONE krijgen en verplaatst worden naar de eerste plaats in de dimensielijst. De drie dimensies die hiervoor in aanmerking komen zullen worden gezocht op volgorde van hun posities, van boven naar onder, vanaf de vierde positie. dimensies die al SQL SELECT hebben worden overgeslagen. 17

21 Undice Het uitvoeren van een undice gaat als volgt: 1. Selecteer de dice modus (zie Edit Mode). 2. Klik met de rechtermuisknop naast de grid, dus op de (zwarte) achtergrond. De eerste dimensies, van boven naar onder, die SQL SELECT als rollup hebben, worden verplaatst naar de eerste drie plaatsen in de dimensielijst en krijgen de rollup SQL NONE. dimensies die hiertoe zijn verplaatst zullen zo nodig SQL SUM krijgen. Als er geen dimensies met SQL SELECT zijn, gebeurt er niets. Rollup De werking van eenslice hangt af van de geselecteerde as. Het uitvoeren van een rollup gaat als volgt: 1. Selecteer de rollup modus (zie Edit Mode). 2. Klik met de rechtermuisknop op de grid. De dimensie op de geselecteerde as zal de rollup SQL SUM krijgen. Deze operatie is te wijzigen in de lijst van dimensies. Drilldown De werking van eenslice hangt af van de geselecteerde as. Het uitvoeren van een drilldown gaat als volgt: 1. Selecteer de rollup modus (zie Edit Mode). 2. Klik met de rechtermuisknop op de grid. De dimensie op de geselecteerde as zal de rollup SQL NONE krijgen. Een ander uitvoering is als volgt: 1. Selecteer de rollup modus (zie Edit Mode). 2. Klik met de rechtermuisknop naast grid, dus op de (zwarte) achtergrond. Er komt een menuutje te voorschijn, met de namen van dimensies waarop een drilldown kan worden uitgevoerd. 3. Selecteer één van die dimensies. De gekozen dimensie zal worden verplaatst naar de geselecteerde as en zal de rollup SQL NONE krijgen Aggregates Aggregates zijn de cellen die zich om de grid heen bevinden. Deze grijze cellen bevatten de aggregatiewaarde van een rij, slice of de gehele grid. Dit maakt het makkelijk voor de gebruiker om snel de aggregatiewaarden van een rij of slice te zien zonder de operatie eerst uit te voeren. De cellen kunnen worden geactiveerd via het optiemenu waar ook gekozen kan worden wélke aggregatie wordt getoond: Sum, Average, Minimum of Maximum. 18

22 4.1.9 Animaties Het doel van Molapse is om de werking van OLAP op een grafische manier uit te leggen ten einde duidelijk te maken hoe de verschillende operaties werken. Dit wordt gedaan met behulp van animaties. Deze animaties zorgen ervoor dat de verschillende operaties worden uitgebeeld en zo is te zien wat er met de database gebeurt. Alle animaties zijn als volgt geimplementeerd: Slice Deze operatie selecteert enkele slices op de huidige actieve as. De overige slices zullen vervolgens niet meer in de grid getoond worden. Om dit uit te beelden worden de slices die niet geselecteerd zijn naar de zijkant bewogen en langzaam uitgefaseerd terwijl de geselecteerde slices naar het midden worden verplaatst. Unslice Deze operatie maakt alle selecties (via de bovenstaande operatie) op de huidige actieve as ongedaan. Dit betekent dat er mogelijk slices bijkomen. Om dit uit te beelden worden deze nieuwe slices langzaam geintroduceerd via de zijkanten terwijl alle huidige slices verplaatst worden naar hun toekomstige positie. Rollup Deze operatie zorgt ervoor dat van de dimensie op de huidige actieve as alleen het totaalresultaat getoond wordt bestaande uit de optelling, gemiddelde, het minimum of maximum van de waarden. Om dit uit te beelden wordt de grid samengeperst op deze as. Dit toont aan dat het resultaat een totaal is van alle cellen. Drilldown Deze operatie zorgt ervoor dat de dimensie op de huidige actieve as, waarvan op het moment enkel een totaalresultaat gebruikt wordt, volledig zal worden weergeven op het geselecteerde detailniveau. Om dit uit te beelden wordt de grid uiteengetrokken op deze as, zodat dat het lijkt alsof de cellen uit het totaalresultaat ontstaan, wat uiteraard ook het geval is. Dice Deze operatie selecteert op alle huidige getoonde dimensies het item behorende bij de één cel. Vervolgens wordt op maximaal drie dimensies een gls(op:drilldown) uitgevoerd. Omdat deze operatie slechts bestaat uit andere operaties, bestaat de animatie ook uit deze animaties. Deze worden samengevoegd tot één animatie. Undice Deze operatie voert het tegenovergestelde van de dice uit. Deze operatie bestaat dan ook geheel uit een combinatie van andere operaties. 4.2 Grafisch ontwerp Het grafische gedeelte omvat het eerder in paragraaf beschreven view-component uit het Model-View-Controller paradigma en is verantwoordelijk voor het correct weergeven van de database zoals deze in het model wordt beschreven. Verder dient dit onderdeel er ook voor om de grafische interface op het laagste niveau te tekenen. Omdat er sprake is van een enkel model, is er gekozen om het grafische gedeelte volgens het singleton pattern op te zetten. Dit waarborgt dat er maar één instantie van dit onderdeel 19

23 kan zijn en dat de controller altijd exact weet welk object benaderd dient te worden voor een bepaalde grafische handeling. Het grafische gedeelte is opgesplitst in drie hoofddelen: de klassen Renderer, Grid en GUI Globaal De klasse Renderer is verantwoordelijk voor het initialiseren en afbreken van de grafische omgeving en het aanspreken van de juiste weergaveklassen in de software. Dit is dan ook de enige klasse die aangeroepen kan worden om daadwerkelijk iets te tekenen op het scherm; in dit geval worden de andere klassen in het grafische gedeelte door deze klasse zelf aangeroepen. Een hulpklasse hierbij is de ShaderManager, die ervoor zorgt dat speciale programma s ter ondersteuning van de weergave, zogeheten shaders, op de grafische kaart kunnen worden uitgevoerd Grid De klasse Grid verzorgt de weergave van het daadwerkelijke databasemodel en de bijbehorende oriëntatietool. Omdat de controller de grid, in verband met onderandere animaties, op meerdere onderscheidende niveaus moet kunnen benaderen bestaat er een basisklasse Entity waaruit de verschillende niveaus - box, slice, grid, aggregates en aggregate slices - als klassen worden geimplementeerd. Door de klasse van het juiste niveau aan te spreken kan de view zodoende op eenvoudige en efficiënte wijze worden gemanipuleerd. Figuur 4.3: Links: voorbeeldmodel met een selectie van slices (blauw). Midden: voorbeeldmodel met aggregaatcellen (grijs). Rechts: oriëntatietool met huidige dimensies. Zoals bekend wordt het model weergegeven als een matrix van kubusvormige cellen met tekstwaarden. De kleurkeuze van de cellen in het model bestaat uit twee kleuren met duidelijk contrastverschil - donkerrood (normale weergave) en lichtblauw (geselecteerde cellen) - en daarnaast een grijze kleur voor de weergave van aggregaatcellen, zoals te zien is in figuur 4.3. De tekstwaarden worden door middel van het industriële lettertype DIN 1451 in witte kleur weergegeven [Deu86]. Dit lettertype heeft zich bewezen als een zeer leesbaar lettertype en is daarom uitermate geschikt voor onze weergave van tekst. Zoals uit de figuur blijkt, worden de tekstwaarden voor betere leesbaarheid in het niet geaggregeerde gedeelte in het grijs (in tegenstelling tot wit) weergegeven wanneer de aggregaatcellen zichtbaar zijn. 20

24 Om te zorgen dat duidelijk zichtbaar is dat er met drie dimensies wordt gewerkt en om meer inzicht te bieden op waarden die zich in de grid (in tegenstelling tot die aan het oppervlak) bevinden, wordt de grid met een bepaalde mate van transparantie getekend. Dit betekent dat elementen doorschijnend zijn zodat ook achterliggende elementen kunnen worden gelezen. De grafische hardware verwacht doorschijnende objecten in een bepaalde volgorde aangeleverd te krijgen. Alle objecten dienen dus gesorteerd te worden doorgestuurd. Dit is een relatief intensieve rekenkundige bewerking, dus is er gekozen om een deel van deze taak aan de grafische kaart over te laten. Om dit te bewerkstelligen zijn er zogeheten shaders nodig die via de klasse ShaderManager worden aangesproken. Dit verklaart de extra eisen die eerder in paragraaf aan de grafische kaart werden gesteld. Figuur 4.4: Het gebruik van omranding van cellen (links) in vergelijking met een model zonder omranding (rechts). De cellen zijn in het eerste geval duidelijker te onderscheiden. Omdat verschillende elementen visueel duidelijk onderscheidbaar moeten blijven is er gekozen om alle cellen in het model met omranding te tekenen, zoals te zien is in figuur 4.4. Ook deze omranding maakt gebruik van shaders, waardoor er nagenoeg geen nadelige invloed op de snelheid van de software ontstaat. De oriëntatietool (zie figuur 4.3) wordt weergegeven met drie verschillend gekleurde lijnstukken op het scherm, waarbij elke lijnstuk gelijk ligt aan een van de drie assen van de grid. Aan elk uiteinde wordt de naam van de dimensie die aan die as verbonden is weergeven. In het geval er geen dimensie is die aan de as kan worden verbonden, dan wordt enkel het lijnstuk getekend. Omdat het van belang is dat de oriëntatie van de grid duidelijk wordt weergeven, wordt de naam van een dimensie gekleurd aan de hand van de huidige oriëntatie. Teksten die verder in de achtergrond liggen worden donkerder getekend dan teksten op de voorgrond. Om aan te geven welke as momenteel actief is (d.w.z. op welke as de bewerkingen uitgevoerd worden) wordt het corresponderende lijnstuk en de tekst in een lichtere kleur getekend dan die van de overige assen GUI De klasse GUI is verantwoordelijk voor het daadwerkelijk tekenen van de grafische interface. De interface (controller) verzorgt de elementen van de GUI en handelt de gebeurtenissen van de GUI af, waardoor deze klasse voornamelijk dient als een laag tussen het daadwerkelijke 21

25 grafische gedeelte en het logische plaatsen en beheren van de elementen uit de GUI. 4.3 Database Het databasegedeelte omvat het eerder in paragraaf beschreven model-component uit het Model-View-Controller paradigma. Omdat het voor het uiteindelijke doel van de software niet nuttig is om waarden aan te passen, is de keuze gemaakt om dit model niet schrijfbaar te maken. In geen enkel geval verandert de database nadat deze is ingelezen, wat de ontwikkeling ten goede komt; zo hoeft er geen aandacht aan extra foutcontrole van ingevoerde data besteed te worden. Er wordt dan ook van een correct geformuleerde en foutloze database uitgegaan die compleet is. Met dit laatste wordt bedoeld dat er voor elk elemententupel uit elke dimensie een waarde bestaat. De opbouw van de database is te zien in in Figuur 4.5. Omdat het programma bij het starten geen verdere kennis heeft van de database die gebruikt zal worden, is het nodig het programma op weg te helpen met een bootstraptabel. In deze tabel staat alle informatie geformuleerd die nodig is om de rest van de database te kunnen gebruiken, namelijk: Het aantal dimensies. De naam van alle dimensies met bijbehorende detailniveaus. De naam van de facttabel en van de factkolom in die tabel. Elke dimensie is in de database ondergebracht in een eigen tabel en heeft als kolommen de detailniveaus die beschreven staan in de bootstraptabel. Door de implementatie van de bootstraptabel kan het aantal detailniveaus per dimensie niet groter zijn dan het totale aantal dimensies omdat er niet genoeg kolommen zijn in de bootstraptabel voor de overige detailniveaus. Elke dimensie heeft naast detailniveaus een unieke identifier met de naam <Dimensie> Id als primary key. Deze primary key is in de facttabel een foreign key. De facttabel moet compleet zijn en heeft zo voor elk tupel van dimensies (als foreign keys) een waarde in de factkolom. Bij het gebruik van een detailniveau voor een dimensie, wordt de facttabel met alle dimensietabellen samengevoegd door een NATURAL JOIN, wat door de garantie van de primary en foreign keys automatisch verzorgd wordt. Op deze gecombineerde tabel kan vervolgens geselecteerd worden op detailniveaus in plaats van alleen op unieke identifiers. Voor meer informatie met betrekking tot het correct aanmaken van nieuwe databases en de precieze opbouw van de database, wordt verwezen naar Appendix B.5.2. Bij het starten van het programma vraagt de controller eerst informatie over de database op, zoals welke dimensies er zijn en welke detail levels iedere dimensie heeft. Na het initialiseren voert het databasegedeelte enkel queries uit op de database wanneer de controller de huidige state van het model opvraagt. De controller stuurt het volgende mee: 1. De dimensies. 22

26 Figuur 4.5: Structuur van de Sales voorbeelddatabase 2. De methode waarop de dimensies worden geaggregeerd. 3. Het detailniveau per dimensie. 4. De elementen waarop per dimensie gesliced is. Het model gebruikt deze informatie om de juiste SQL query via een iteratief proces te genereren. Om te beginnen wordt de facttabel met alle andere dimensies met behulp van natural join samengevoegd. SQLite heeft weliswaar geen ondersteuning voor foreign key constraints, maar door te eisen dat geen twee kolommen in de dimensie tabellen dezelfde naam hebben, kan gezorgd worden dat de kolommen uit de facttabel elk horen bij een dimensie. Een natural join van de facttabel met alle dimensietabellen zorgt er dan ook voor dat er een grote tabel gecreëerd wordt met alle informatie die mogelijk nodig is voor verdere bewerkingen. Om ervoor te zorgen dat in het begin alle informatie beschikbaar blijft en niet samengevoegd wordt, wordt er gegroepeerd op alle detailniveaus met behulp van de GROUP BY instructie. Echter, als er bij een dimensie een detailniveau is gekozen, dan zullen alle waarden die moeten worden samengevoegd met de base operatie worden samengevoegd. Deze baseoperatie is instelbaar, maar niet per dimensie. Om deze query wordt voor elke dimensie een nieuwe SQL query geformuleerd. Dit resulteert in een geneste query die even diep nest als er dimensies zijn. Bij elk niveau wordt er gekeken 23

27 of de dimensie geaggregeerd moet worden. Indien dit niet het geval is, blijft deze bestaan in de GROUP BY en zal deze in alle hoger geneste queries ook in de GROUP BY staan, zodat deze dimensie - eventueel samengevoegd op basis van het gegeven detailniveau - volledig wordt teruggegeven aan de controller. In het geval de dimensie wel geaggregeerd moet worden, wordt in de SELECT de juiste aggregatie toegepast met behulp van SUM, AVG, MIN of MAX. Ook wordt de dimensie op dit niveau uit de GROUP BY gegooid zodat alle waarden van die dimensie worden geaggregeerd. Ook in hoger geneste SQL queries wordt deze dimensie uit de GROUP BY gehaald om eventuele foutmeldingen te vermijden. Een voorbeeld van een geneste SQL query, waarbij de dimensie Period wordt geaggregeerd door het gemiddelde ervan te nemen, ziet er als volgt uit: 1 SELECT Uni, Stud, Period, AVG( Total3 ) AS Total4 2 FROM ( 3 SELECT Uni, Stud, Period, ( Total2 ) AS Total3 4 FROM ( 5 SELECT Uni, Stud, Period, ( Total1 ) AS Total2 6 FROM ( 7 SELECT Uni, Stud, Period, SUM( Grades ) AS Total1 FROM 8 F acttable NATURAL JOIN ( 9 U n i v e r s i t y NATURAL JOIN Student NATURAL JOIN Period 10 ) 11 GROUP BY Uni, Stud, Period 12 ) 13 GROUP BY Uni, Stud, Period 14 ) 15 GROUP BY Uni, Stud, Period 16 ) 17 GROUP BY Uni, Stud ; Het is hierbij belangrijk om te vermelden dat als er op een dimensie niet geaggregeerd hoeft te worden, er in feite niets gebeurt en er dus een nutteloze SQL query geformuleerd wordt die een identiek resultaat oplevert. Na het uitvoeren van de SQL query geeft het model het volgende terug aan de controller: 1. De naam van het detailniveau, per dimensie. 2. De labels van de zichtbare elementen, per dimensie. 3. Een array met alle waarden die overgebleven zijn. 4. De grootte van elke dimensie zodat elementen op de juiste manier uit de hierboven genoemde array gehaald kunnen worden. 4.4 Configuratie Om de verscheidene instellingen van de applicatie in te kunnen lezen en weg te schrijven is er een configuratiemodule aanwezig die uit een aantal klassen bestaat. 24

28 De hoofdklasse ConfigHandler omschrijft de standaardfuncties voor het benaderen en bewerken van configuratieinstellingen. Daarnaast verzorgt de klasse XmlHandler de daadwerkelijke implementatie door alle instellingen in te lezen en weg te schrijven als een bestand in XML-formaat. Door gebruik te maken van het XML-formaat kunnen instellingen eenvoudig gestructureerd worden opgeslagen en kunnen diverse datatypen worden gerepresenteerd. Verder is het formaat makkelijk bewerkbaar zodat door de gebruiker ook buiten de software om de configuratie eenvoudig kan worden veranderd. 25

29 Hoofdstuk 5 Testen 5.1 Acceptatietest Een acceptatietest geeft de opdrachtgever de mogelijkheid om de software in verschillende scenario s te testen. Zodoende kan de opdrachtgever eventueel probleem- en verbeterpunten van de software aangeven. Om in de laatste weken van het project zeker te zijn dat de ideeën van de opdrachtgever en die van de ontwerpprojectgroep overeenkomen, is deze acceptatietest uitgevoerd op 9 juni Visualisatie Tot de visualisatie worden het kleurschema, de leesbaarheid van de labels, het ontwerp van de interface en animaties van de software gerekend. De juistheid hiervan wordt vooral tijdens de werking met de software ervaren. De mogelijkheid om aggregatiecellen weer te geven was ten tijde van de test niet beschikbaar maar werd ten tijde van de test alsnog toegevoegd. De opdrachtgever is van mening dat de visualisatie duidelijk genoeg is en enkele details, zoals de rotatie van tekst voor betere leesbaarheid, een goede aanvulling bieden voor de gebruiker Besturing Bij de besturing wordt gekeken of de interface duidelijk en logisch reageert op input van de gebruiker en of deze in het algemeen als makkelijk ervaren wordt. Na een korte introductie van de interface is de opdrachtgever van mening dat de software op een logische manier te gebruiken is. De verschillende onderdelen in de interface volgen uit een duidelijke indeling. Tevens biedt de orientatietool volgens de opdrachtgever een goede ondersteuning bij de visualisatie en manipulatie van de database. 26

30 5.1.3 Standaard OLAP-operaties Het verifiëren van de correctheid van alle OLAP-operaties die zich in de software bevinden is uiteraard van belang. Ten tijde van de acceptatietest was de operatie dice echter nog niet beschikbaar; aan de opdrachtgever is wel beschreven hoe deze zou gaan werken. Tijdens de acceptatietest was de software in staat om in willekeurige volgorde de operaties slice en rollup uit te voeren. Daarnaast werd de mogelijkheid geboden om deze operaties ongedaan te maken. De opdrachtgever leent dan ook aan deze twee geimplementeerde operaties zijn goedkeuring Diverse databases De software zal in staat moeten zijn om een aantal diverse databases in te laden zonder vast te lopen of data foutief weer te geven. Het inladen van diverse databases zal daarom ook getest worden. Het laden van een andere database werkt in de acceptatietest volgens verwachting; de gewenste database is dan ook in het configuratiebestand te specificeren die na een herstart van de software automatisch ingeladen wordt. De opdrachtgever voorziet met het opnieuw starten van de software dan ook geen problemen. 5.2 Scenario-testen De hieronder uitgevoerde scenariotests zijn gebaseerd op de scenario s die beschreven staan in hoofdstuk Scenario 1 - Jaar met hoogste cijfers De gebruiker is een docent die wil zien in welk jaar de hoogste cijfers voor zijn vak gehaald zijn. 1. Start de software met run.bat of run.sh. 2. Rechtsklik in de dimensielijst linksboven op het detaillevel van Course en selecteer Teacher. 3. Rechtsklik in de dimensielijst linksboven op het detaillevel van Time en selecteer Year. 4. Rechtsklik in de dimensielijst linksboven op de aggregaat van Course en Time en zet deze op None, zodat ze niet geaggregeerd worden. 5. Rechtsklik in de dimensielijst linksboven op de aggregaat van Student en University en zet deze op Avg zodat hiervan het gemiddelde genomen worden. 6. Draai eventueel de grid door met de linkermuisknop ingedrukt te slepen over de grid opdat alle waardes goed leesbaar zijn. 27