Framework til e-læring. Af Thomas Ladiges Jørgensen s053094

Transkript

1 Framework til e-læring Af Thomas Ladiges Jørgensen s Polyteknisk Eksamensprojekt Institut for Informatik og MatematiskModellering Danmarks Tekniske Universitet Kongens Lyngby

2 Resume For at Danmark forsat kan befinde sig i toppen af det globale marked er det nødvendigt at danskerne uddanner sig og til dette er e-læring oplagt og mulighed. E- læring er fleksibelt og kan nedbryde geografiske og tidsmæssige grænser og dermed tilpasses til individuelt til eleven. I denne rapport undersøges muligheden for at lave et generelt framework til e-læring der kan bruges på tværs af platforme. Formålet med frameworket er at lette implementationen af e-læring i programmer og for dermed at være med til at udbrede brugen af e-læring. En prototype af frameworket er fremstillet i C# til.net platformen. Rapporten beskriver designet og implementationen af frameworket. For at øge anvendeligheden af frameworket er det designet så det løbende kan udvides dynamisk, i henhold til de grafiske elementer og i henhold til indholdet af en læringsproces. 2

3 Forord Denne rapport er et eksamensprojekt til civilingeniøruddannelsen på Danmark Tekniske Universitet. Den er lavet under Institut for Informatik og Matematisk Modulering. Projektet er udført af undertegnet med Bjarne Poulsen fra IMM, DTU som vejleder. På den medfølgende er kildekoden til projektet. Thomas Jørgensen 3

4 Indholdsfortegnelse 1 Introduktion Baggrund og motivation Visioner Problemstilling Krav specifikation Funktionelle krav Non-funktionelle krav Identifikation af udfordringer Benyttet teknologi Metode valg Test driven development (TDD) Test-Driven Development arbejdsgang Analyse Framework E-læring Adaptive opgaver Skalerbart framework Grafisk uafhængigt Opgave format Data management Opgaveelementer Use Case Domænemodel Delkonklusion Design af framework Overordnet designstrategi Design af opgavestruktur Adaptiv sekvens Dynamisk loading af opgave elementer Design af API Overordnet design struktur

5 3.3.2 Design af domainelag Design af datalag Design af præsentationslag Delkonklusion Implementering og test Strategi for test af frameworket Implantation af opgave XML struktur Implementering af opgaveelementer Implementation af SqlDatalag Design af database Implementation af datalag Proof of concept Proof of concept - Web portal Proof of concept - Windows program Delkonklusion Konklusion Opsummering af delkonklusioner Overordnede betragtninger Fremtidigt arbejde Henvisninger Litteratur links Bilag Paper

6 1 Introduktion Dette kapitel vil beskæftige sig med selve baggrunden for projektet samt den overordnede problemstilling: hvordan kan e-læring i højere grad blive implementeret i dagens Danmark. Der vil blive set på nogle at de mål som de førende politikere inden for området har for e-læring [2]. Der vil blive beskrevet, hvad versionen med dette projekt er og endvidere, hvilke krav skal der opfyldes for at nå denne vision. Til sidst vil de udviklingsmetoder der bliver benyttes for at opfylde kravene til projektet blive fremhævet. 1.1 Baggrund og motivation Gennem den seneste tid er der kommet mere politisk fokus på udbyttet af undervisningen i folkeskolen i form af e-learning og elektroniske tests. Samtidig er der kommet mere fokus på, at den danske befolkning skal uddanne sig ved brug af e- læring, da dette giver en mere fleksibel og individuel uddannelsesform. Det er blevet et lovkrav fra regeringens side at gøre brug af nationale tests og disse nationale tests er målrettet elever fra 6-8. klasse, både for at kunne sammenligne elevers faglige niveau på landsplan og for at give læreren bedre redskaber til at finde det individuelle faglige niveau for den enkelte elev [1]. De nationale tests skal være: it-baserede, hvilket vil sige at de skal besvares på en computer med netforbindelse. selvscorende, hvilket vil sige at man som lærer ikke skal rette dem og udregne resultater, men får resultaterne i forskellige former for rapporter, der hentes på nettet. adaptive, hvilket vil sige at de tilpasser sig den enkelte elevs faglige niveau. Internationalt set er der stor fokus på uddannelse og læring. I August 2007 afholdt Microsoft deres Imaginecup [3] konkurrence med temaet Imagine a world width better education for all hvor artiklen Educational Web Part Framework for improvement and evaluation af Thomas Ladiges Jørgensen og Peter Bach Andersen [7.2] blev udarbejdet og udvalgt som Danmarks bidrag til konkurrencen 1. Denne artikel ligger til grund for denne videre udvikling af ideerne og teknologierne. National strategi for IKT-støttet læring Undervisningsminister Helge Sander beskriver i sin publikation om national strategi for IKT 2 -støttet læring sine visioner og fremtidsudsigter for Danmark. Han skriver at, for at Danmark forsat kan holde en førerposition på det globale marked bør danskerne forsat uddanne og videreuddanne sig. Til dette er e-læring et oplagt Informations- og kommunikationsteknologi 6

7 supplement til den traditionelle uddannelsesform, da Danmark har infrastrukturen til at gøre brug af e-læring. E-læring er en fleksibel uddannelsesform, da den nedbryder de geografiske og tidsmæssige begrænsninger, der kan gøre det svært at få tid til at videreuddanne sig. Målet med strategien er dels at øge anvendelsen og kvaliteten af e-læring med henblik på at styrke kompetenceudviklingen bredt og dels at gøre Danmark til et førende land inden for e-læring[2]. For at opfylde disse mål bliver der i perioden sat mere fokus på e-læring, og der vil blive afsat 135 millioner kroner til at fremme brugen af e-learning inde for både den offentlige og private sektor. 1.2 Visioner Visionen med dette projekt er at udvikle et framework til e-læring, der understøtter både web og desktop applikationer på.net platformen. Det skal gøres nemmere at inkludere e-læring i virksomheder og offentlige institutioner som en del af læringsmaterialet til medarbejderne. Det er i dag besværligt for mindre og mellemstore virksomheder at gøre brug af e-læring i virksomheden, da der ikke eksisterer et framework til e-læring, og fordi systemudviklere derfor må lave alt fra bunden. Det er ikke alle virksomheder, der har disse ressourcer til at opbygge et intranet til brug for e-læring og de kan derfor kun gøre brug af det e-læring, der kan købes som en færdig samlet pakke. Dette giver ikke virksomhederne mulighed for at lave deres eget materiale til brug i virksomheden. Visionen med dette projekt bliver derfor at lave et framework, der gør det nemt at implementerer e-læring i web og desktop applikationer og som samtidigt er fleksibelt, så det er muligt at udvide det med nye svarmuligheder og anden grafisk visning. Fleksibiliteten gør at virksomhederne kan implementerer e-læring i deres eksisterende system ved at gøre brug af forud lavede moduler. Samtidig kan de beholde den særlige stil, de har på hjemmesiden, frem for et færdigt system, som ikke kan implementeres i virksomhedens eksisterende intranet, og som virksomheden ikke har mulighed for at udvide og modificere efter deres behov. 7

8 1.3 Problemstilling Ideen er baseret på, at det i folkeskolen skal gøres nemmere for lærere at give opgaver/prøver til elever, der er rettet mod den enkelte elev, samt at reducere den tid læreren bruger på at rette opgaver, så der bliver frigivet mere tid til at undervise eleverne. Det skal være nemmere at få indsigt i, hvilket fagligt niveau, den enkelte elev befinder sig på inden for de forskellige fag og deres undergrupper. På den måde bliver det nemmere at skride ind i tide, når en elev begynder at sakke bagud i klassen, af den ene eller den anden grund, da der i dag er ca. 25 elever i en klasse, kan det være svært for læreren at danne sig et billede af samtlige elevers niveau og motivation. For at få indsigt i de enkelte elevers faglige udvikling skal det være nemmere at lave statistik over klassen, hvilket også gavner og giver overblik, såfremt der kommer nye lærere til. Der er ofte problemer med, at eleverne ikke er på samme niveau, så nogle kæmper med opgaverne og mister motivationen til at lave lektier, fordi de ikke kan finde ud af det. De stærke elever keder sig, fordi opgaverne er for nemme og de udvikler sig derfor ikke fagligt i det det tempo, de har potentiale for. Regeringens strategi om at Danmark skal være førerne inde for e-læring stiller store krav til den offentlige og private sektor. De små og mellemstore virksomheder har ikke ressourcerne der kræves til at uddanne medarbejderne med interne e-lærings kurser, da de ikke har ressourcerne til at lave materialet og da der ikke findes nogle frameworks til at lave e-lærings materiale er det en stor opgave at integrere e-læring som en del af firmaernes interne it-struktur. 8

9 1.4 Krav specifikation Denne rapport beskæftiger sig med at lave et generisk framework til e-læring, som skal gøre det nemmere for udviklere af undervisnings lignende IT-systemer at gøre brug af e-læring Funktionelle krav Her vil blive listet de overordnede funktionelle krav, frameworket skal understøtte: Frameworket skal udvikles, så det kan understøtte web og desktop applikationer Med dette menes at logik- og data-delen skal kunne genbruges. Den grafiske del skal kunne udskiftes afhængigt af, hvilken platform det afvikles på. Opgaverne skal kunne være adaptive Her menes, at opgavernes sværhedsgrad løbende tilpasses brugerens niveau. Muligt at udvide frameworket med nye opgavetyper Det skal være muligt at tilføje nye moduler til frameworket, så der kan komme flere svarmuligheder og andet grafisk visning med tiden, uden at rekompilere frameworket. Opgavemanagement Frameworket skal understøtte, at opgaver kan gives til brugere, og at der kan udtrækkes data om brugernes opgaver Non-funktionelle krav Det skal være nemt at implementere frameworket i programmer, så de kan understøtte e-læring. Det skal være nemt for programmøren at implementerer e-læring i de eksisterende systemer ved at gøre brug af færdigudviklede moduler. 1.5 Identifikation af udfordringer Fleksibelt design af frameworket, så det nemt kan opdateres med tidens krav. Fleksibelt design af opgavestruktur Der skal findes en måde, hvorpå opgaverne kan repræsenteres, så det er muligt at tilføje nye opgavetyper. 9

10 1.6 Benyttet teknologi.net Framework Det er valgt at benytte.net, da det er muligt at genbruge den samme kode i web og desktop applikationer. C#.NET frameworket understøtter en række programmeringssprog som f.eks. C++, C# og VB.Net. Det er derfor op til udviklerne at vælge deres ynglings sprog når der programmeres til.net platformen. Til dette projekt er der valgt C#. Windows Presentation Foundation.NET frameworket understøtter både Winform og Windows Presentation Foundation til at udvikle grafiske brugergrænseflader til windows platformen. Microsoft har annonceret, at de stopper supporten til Winform, så derfor benyttes efterfølgeren Windows Presentation Foundation. ASP.NET Til at udvikle dynamiske web applikationer under.net frameworket bruges ASP.NET, da dette er en forholdsvis udbredt og almen kendt teknologi for webudviklere og vil falde i tråd med det i forvejen brugte. MSSQL Der findes forskellige databaser f.eks. MYSQL, MSSQL, Oracle og så videre. Der vælges Microsoft SQL Server på grund af de indbyggede funktioner til databasen i.net frameworket. XML Der bruges XML til at beskrive opgaverne. Dette er en integreret del af.net og meget dynamisk at arbejde med. XML er desuden også en bredt funderet teknologi. Der bruges XML-skema til at validere XML syntaks løbende, efterhånden som opgaver og lignende bliver defineret i XML. 10

11 1.7 Metode valg I dette afsnit vil det blive beskrevet, hvilke udviklingsmetoder der bruges igennem projektet Test driven development (TDD) Der vil blive brugt TDD i udviklingen af frameworket for at opnå et system, som er mere skalerbart hvad angår videreudvikling. Til dette benyttes der forud definerede automatiske test, som kan verificerer, at videreudvikling ikke har beskadiget eksisterende dele af frameworket. TDD er en arbejdsproces, der beskriver, hvordan man tester og udvikler software ved først at definere en eller flere tests, som svare til de krav, de enkelte moduler skal overholde. Derefter skal der laves et kodeskelet af metoder, så der ikke opstår kompileringsfejl, og herefter begynder den egentlige implementering. For hver metode er der en eller flere unittests, der verificerer, at klassen og metoderne opfylder de forud definerede krav Test-Driven Development arbejdsgang 1 Tilføj en test: Når ny funktonalitet skal tilføjes, startes der med at definere en test der afspejler kravene til funktonaliteten, inden funktionalitet implementeres. Dette tvinger programmøren til på forhånd at gennemtænke hvordan der skal interageres med klasser og metoder, inden koden til funktionaliteten implementeres, hvilket er med til at give en bedre struktur i koden, da den bliver mere modulbaseret. Skallen til de klasser og metoder, testen gør brug af, skal formes. 2 Køre alle test Den nye kode skal fejle da der kun er lavet skallen til funktonaliteten. Dette tester også at hvis testen består, er testen ikke lavet korrekt. 3 Skriv kode Skriv kode der opfylder kravene til testen, så testen består. 4 Køre alle test Kører alle tests og verificér, at de alle består. 11

12 5 Refaktoring Når hele funktionaliteten fungerer, kan koden refaktureres hvis nødvendigt, dels for at fjerne duplikeret kode, og dels for at gøre koden mere læselig og skalerbar. Der anvendes mange andre refakturerings teknikker. Gå til trin 4 for at teste, at testene stadig består. Se TDD arbejdsgang TDD arbejdsgang Det er et krav, at alle unit tests skal resultere i enten fejlet eller bestået, frem for fx et resultat af en kalkulation, som ikke er sigende og ingen udenforstående kan tolke. Derved bliver det også nemmere at bygge videre på koden. Dette gør yderligere, at det bliver mere omkostningseffektivt at teste systemet løbende, frem for at teste det manuelt, da unit test automatisk kontrollerer og automatisk genererer en rapport med de test, der er fejlet og bestået. Når der skal startes med TDD, er det en fordel at gennemføre det fra starten af udviklingsprocessen, da koden skal være lavet, så den er testbar. Ellers skal systemet refaktureres til at være testbart med unittest. Dette er også med til at sikre, at delelementerne i frameworket bliver lavet som moduler, hvorpå der skal laves unit test for at teste de enkelte dele af modulerne. Derudover kan en black box unit test teste hele modulet som en enkelt enhed. Design patterns Design patterns er en generel løsning på et gentagende problem inden for software design. Et design pattern er ikke et færdigt design, der kan implementeres med det samme. Men det er en beskrivelse af, hvordan et problem kan løses. Et problem, der kan opstå i mange forskellige software programmer. For at et design patteren kan betegnes som et decideret design pattern, skal det beskrive et konkret problem, som 12

13 opstår i mange situationer, samt give en løsning på problemet. Løsningen skal være så generel, at det ikke er bundet til en specifik situation. Fordele ved design patterne De beskriver designviden Når et pattern er beskrevet kan en anden udvikler bruge patternet. Det giver mulighed for at genbruge kendte gennemprøvede løsninger uden at opfinde den dybe tallerken hver gang. De giver et design ordforråd Objektorienteret design pattern beskriver typisk relationen og interaktion mellem klasser eller objekter, der udgør design pattern frem for den færdige løsning. En løsning, der skal tilpasses det konkrete problem. 13

14 2 Analyse Dette afsnit vil beskæftige sig med den indledende analyse af frameworket, og om hvordan det kan opbygges, så det bliver fleksibelt og skalerbart. Afsnittet kommer også med et forslag til strukturen for, hvordan en opgave kan beskrives. Der er i dag mange LMS systemer(learning Management System)[4] af forskellig art, både som open source og kommercielle systemer. Fælles for dem alle er, at de gør det muligt at give opgaver til brugerne og følge deres udvikling. De fleste af de gængse LMS systemer understøtter kun, at brugeren kan løse opgaver og bruge systemet via en web browser. Dette sætter begrænsninger, da ikke alle har adgang til internet. Der mangler en offline løsning, så man f. eks kan downloade opgaverne til en klient og løse dem offline og så synkronisere sin klient, når brugeren igen har internetforbindelse. Suppleret med dette giver det brugeren maksimal frihed. Dette projekt vil ikke beskæftige sig med at lave endnu et LMS system, men et framework til et LMS system, så det er muligt for andre at integrere et LMS system i deres eksisterende løsning. Dette giver mulighed for at få det til at fremstå som et helt system, i stedet for to systemer. Frameworket skal understøtte ASP.NET og WPF platformene, og det skal senere være muligt at udvide frameworket til andre platforme inden for.net frameworket. 2.1 Framework Frameworket skal konstrueres som et API, der kan bruges som fundament af andre udviklere, der ønsker at inkludere e-læring i deres web og desktop applikationer. Frameworket kan deles op i 2 dele ud fra funktionalitet E-læring Opgave management E-læring Dette afsnit beskriver den del af frameworket, der omhandler, hvordan e-lærings opgaverne skal udformes samt de krav, der stilles til opgaverne. E-learning er ikke noget nyt fænomen. Det startede i 1980 erne med undervisning via VHS og kassettebånd og tog fart op gennem 90 erne, da Internettet så småt begyndte at blive hvermands eje. E-læring bestod dengang i envejskommunikation, ved af brugerne læste hjemmesider og udviklede sig med tilhørende tests. I takt med at båndbredden til Internettet er øget, og folk er begyndt at tage Internettet til sig, er kvaliteten af e-læring steget, idet brugerne bliver mere og mere interaktivt indstillet i undervisningen. Desuden er e-læringen begyndt at tilpasse sig brugerens faglige 14

15 niveau ved at justere sig dynamisk. I takt med den øgede båndbredde er video og lyd også begyndt at blive en større del af læringsmaterialet. De mange nye teknologier gør, at brugeren begynder at interagere mere og mere med læringsmaterialet. I dag bliver der brugt en masse forskellige media til e-læring. Mange af dem er LMS systemer, Blogs, Podcasts, spil, Wikipedia er, etc. Det er valgt 4 områder, som er kritiske for frameworket Adaptive opgaver Skalerbart framework Grafisk uafhængigt Opgaveformat Adaptive opgaver Med adaptive opgaver menes der, at sværhedsgraden af opgaven løbende evalueres og tilpasses brugerens niveau, afhængigt af de forrige opgaver. Det kan efterlignes i en såkaldt træstruktur, hvor vejen ned gennem træet har hver sin sværhedsgrad og vejen gennem træet bestemmes af svarene i de tidligere opgaver. Hele opgaven kan betegnes som en opgavesekvens, og hver vej gennem træet kan betegnes som en opgavebranch. Se Figur opgave træstruktur. Figur opgave træstruktur Dette giver mulighed for, at opgavesekvensen bliver adaptiv, da hver vej kan repræsentere hver sin sværhedsgrad. 15

16 2.1.3 Skalerbart framework For at gøre frameworket mere skalerbart i forhold til grafisk layout og svarmuligheder, skal der være lav kobling mellem frameworket s opgaver og de elementer, der udgør opgaven. Dette illustreres på Figur Opgaveelementer Opgave Opgaveelement Billede Media Svarmulighedder Tekst Figur Opgaveelementer Denne struktur giver mulighed for at udvide opgavetyperne, så programmørerne kan ændre layout og svarmuligheder. Den lave kobling kan opnås på to forskelige måder enten via statiske eller dynamiske opgaveelementer. Statisk definering af opgaveelementer Ved statisk definering af opgaveelementer er det et krav, at frameworket kender til alle de forskellige opgaveelementer. Ved at udvikle efter et Factory design pattern[5], kan de forskellige opgaveelementer derefter bruges dynamisk, ved at alle opgaveelementerne overholder et fælles interface. Dynamisk Definering af opgaveelementer Ved dynamisk definering af opgaver, er det ikke nødvendigt for frameworket at kende til de forskellige opgaveelementer, og det giver derfor en meget lav kobling mellem frameworket og opgaveelementerne. Ved at gøre brug af et Factory pattern, kan de forskellige opgaveelementer derefter loades dynamisk ved at gøre at brug af reflection. Dette kræver dog information om, hvilken assembly fil og klasse, der skal bruges til at instantiere opgaveelementet. Det er et krav, at alle opgaveelementer implementerer et fælles interface, så de forskellige elementer kan behandles generelt. 16

17 Krav Metode Statisk definering af opgave elementer Dynamisk Definering af opgave elementer Genkompilerer ved nye opgaveelementer Ja Nej Fleksibilitet Mellem Høj Nemhed Mellem Lav Tabel 1 fleksibilitet og anvendelighed Statisk vs Dynamisk opgaveelementer. På baggrund af ovenstående analyse opnås der mest mulig fleksibilitet ved dynamisk definering af opgaveelementer, da reflection gør det muligt at udvide samlingen af opgaveelementer uden at genkompilere frameworket Grafisk uafhængigt For at frameworket kan bruges i både web og desktop applikationer er det nødvendigt at kunne udskifte den grafiske brugerflade, da programmeringsdomænet er vidt forskelligt på de to platforme. Web platformen beskriver brugergrænsefladen via HTML og på desktop platformen beskrives brugergrænsefladen via WPF. Da disse to sprog ikke er kompatible, skal det være muligt at skifte det grafiske layout afhængigt af den anvendte platform. For at gøre dette, introduceres et layer pattern[6] der beskriver, hvordan hvert lag har deres ansvar: lag 1 beskriver det grafiske layout, hvor lag 2 beskriver logikken bag layoutet. Ved at gøre brug af denne metode vil det også være muligt at udvide frameworket med nye grænseflader til fx silverlight og andre nyere teknologier Opgave format Der skal defineres et format til at lagre opgaver i. Det skal være fleksibelt, så det både kan håndtere og behandle de gamle og håndtere, at der kommer nye opgavetyper til. Da frameworket ikke definerer, hvordan opgaverne skal repræsenteres grafisk, skal formatet til datarepræsentation indeholde information om, hvilke data der er gyldige for den givne opgave. Til dette kan der bruges XML. Denne teknologi kan definere opgavernes data, og et XSD 3 - eller DTD 4 -skema kan bruges til at beskrive, hvilke data XML dokumentet indeholder. Dette udgør et fleksibelt design, idet det er muligt at udvide XML-skemaer med tiden, ud over hvad der blev implementeret på selve designtidspunktet. Nye opgaver kan tilføjes uden at API et skal ændres. Det er XSDeller DTD-skemaerne, der definerer de enkelte opgaver. Fordelen ved XSD i forhold til 3 XML Schema Definition 4 Document Type Definition 17

18 DTD er, at XSD er defineret via XML, hvilket gør det nemmere for dem, der allerede kender til XML, at tiføje til et XSD-skema frem for et DTD-skema. DTD understøtter ikke namespaces, som er en måde at adskille XML-elementer fra hinanden. Desuden skal der laves et XML skema til at validere strukturen i en opgavesekvens, således at opgaverne lever op til den ønskede struktur Data management Dette delafsnit vil beskrive den del af frameworket, der omhandler management, altså håndtering af opgaver/statistik i relation til brugerne. På baggrund af kravspecifikationen skal det være muligt at håndtere opgaverne. Fordi dette er et framework frem for et færdigt system, udbyder frameworket ingen grafiske komponenter til at håndtere opgaver/statistik, men derimod en række interfaces til at interagere med frameworket. Dette giver udviklerne mulighed for selv at bestemme layoutet. Managementdelen af frameworket omhandler hvordan der holdes styr på de opgaver der findes i systemet. Det er i selve datadelen af frameworket, der skal findes en struktur til at holde styr på opgaverne i systemet og de opgaver der er givet ud til brugere. Til dette er en relationsdatabase et fordelagtigt valg, fordi det er en gennemprøvet løsning. Frem for at frameworket implementerer et datalag, der kommunikerer med en database, giver det en mere fleksibel løsning. Frameworket definerer interfaces til håndtering af statistik og opgaver, som ikke låser frameworket til en bestemt datastruktur. Dette giver mulighed for at for at lave en konkret implementation af interfacene til f.eks. MSSQL, MYSQL, Oracel og XML som datastruktur til frameworket. Managementdelen af frameworket kan opdeles i 2 områder 1. Opgavehåndtering 2. Statistik Opgavehåndtering Frameworket skal definere et interface til opgavehåndtering, der skal have følgende funktioner Give opgaver til brugere. Slette opgaver fra brugere. Oploade nye opgavesekvenser til opgavepuljen. Slette opgavesekvenser fra puljen. Søge i opgavepuljen. Søge opgaver hos brugere 18

19 Give opgaver til brugere Funktionen skal give en opgave til en eller flere brugere samt at definere, hvilken emnegruppe /undergruppe opgaven tilhører og hvornår opgaven skal være løst for at give bedre mulighed for at lave specificeret statistik. Fx at kunne give en opgave til bruger1 og bruger2 med emnegruppe matematik og undergruppe addition/division. Slette opgaver fra brugere Funktionen skal slette en opgave fra en eller flere brugere. Oploade nye opgaver til opgavepulje Funktionen skal oploade en ny opgavesekvens til puljen over opgavesekvenser. En opgavesekvens indeholder følgende filer: XML dokument, som definerer opgavesekvensen, XML skemaer og filer, der bliver brugt i opgaverne. Slette opgavesekvens fra pulje Slette en opgavesekvens fra opgavepuljen. Dog kun hvis opgavesekvensen ikke er givet ud til brugere. Søge i opgave pulje Funktionen skal retunere en liste af opgaversekvenser, der passer på søgekreteriet. Da alle opgavesekvenser indeholder en liste af tags, der beskriver opgaven, kan disse bruges til at søge efter opgavesekvenser. Søge opgaver hos brugere Funktionen skal returnere en liste af opgavesekvenser ud fra søgekriterierne: Elev Emnegruppe Undergruppe Til/fra dato Løst til tiden Elev Den elev, der skal findes opgavesekvenser for. Emnegruppe Den emnegruppe af opgavesekvenser der skal medtages (valgfri). Undergruppe Den undergruppe af opgavesekvenser der skal medtages (valgfri). Til fra dato Et tidsrum for, hvilke opgavesekvenser, der skal medtages i den statistiske søgning (valgfri). 19

20 Løst til tiden Om opgavesekvenser skal være løst til tiden (valgfri) Statistik Da frameworket ikke leverer noget grafisk interface til at illustrere statistik, men kun et interface til at udtrække statistik, skal dette interface levere en objektstruktur, der afspejler den statiske søgning. Denne objektstruktur skal kunne databindes til f.eks. GridView og andre komponenter, der kan vise data. Dette stiller krav til objektstrukturen, nemlig at den bliver implementeret så den opfører sig på samme måde som en DataTable i.net. Objektstrukturen returneres ved en statisk søgning og skal indeholde Opgavenavn Opgave id Score Løst til tiden Løst dato Bruger Givet dato For at kunne lave et statistisk udtræk, skal det være muligt at specificere, hvilket data der skal returneres ud fra søge kriterierne Elever Emnegruppe Undergruppe Til fra dato Løst til tiden Ovenstående elementer er de samme som ved søgning efter opgavesekvenser. 20

21 2.2 Opgaveelementer Frameworket defineres via design by contract[7] for opgaveelementer, der udgør elementerne i en opgave, hvilket giver mulighed for at udvide opgaveelementerne. For at øge brugbarheden af frameworket, skal der defineres nogle standardopgaveelementer, så frameworket kan tages i brug uden at først at skulle udvikle opgaveelementerne. Frameworket skal stille følgende elementer til rådighed. Multiple choice modul Modulet skal understøtte brugen af multiple choice: brugeren skal kunne definere et antal valg og hvilke valg, der er rigtige. Textbox modul Et input felt,hvor brugeren kan skrive fri tekst. Det skal være defineret, hvad den rigtige tekst er. Image modul Skal kunne vise et billede, hvor dimensionerne vælges. Media modul En mediaplayer, der kan afspille fx WMA og MP3 filer. Table modul For at kunne speficere hvor de forskelige opgaveelementer skal stå grafisk på opgaven skal der defineres en tabel med rækker og kolonner som det kendes fra en HTML table. Text moduel Fri tekst hvor det er muligt at skifte font, størrelse og farve. 21

22 2.3 Use Case Der er opstillet tre Use Cases for frameworket, der afspejler nogle af de krav, der er bestemt. Da dette er et framework der er opstillet Use Cases for og ikke et færdigt program, behandler Use Casene mere funktionalitet generelt, frem for en konkret beskrivelse af, hvordan brugeren skal interagere med systemet. Da frameworket ikke udgør noget funktionsdygtigt produkt, før det bliver implementeret i et givent system, er der fundet tre Use Cases, som der skal honoreres. Der er opstillet Use Cases for 3 kerne funktionaliteter i frameworket 1. Opload en ny opgave til systemet. 2. Give en opgave til en bruger. 3. Brugeren løser en opgave. ID: UC1 Bruger Lærer Use case: upload ny opgave til databasen. Forudsætning Der er opsat et system til e-læring med frameworket implementeret. Forløb 1. Læreren definerer en opgave via XML. 2. En ZIP fil oprettes, indeholdende XML opgaven, XML skemaer og andre filer, der skal bruges til opgaven. 3. Filen oploades til databasen. Postkondition Opgaven er blevet tilføjet til databasen. 22

23 Use case: Giv opgave til bruger ID: UC2 Bruger Lærer Forudsætning UC1 Forløb 1. Søg efter en opgave 2. Vælg opgave 3. Giv opgaven til brugerne og definer en emnegruppe/undergruppe, opgaven skal tilhøre. f.eks. gruppe-matematik med undergruppe addition/division. Postkondition Opgavedelen er blevet tilføjet de samlede opgaver, brugeren skal løse. 23

24 Use case: Løs opgavesekvens ID: UC3 Bruger Elev Forudsætning UC2 Forløb 1. Eleven vælger den opgavesekvens, der skal løses 2. While flere opgaver - Løs opgave - Næste opgave vises for bruger, afhængigt af tidligere svar End While Postkondition Opgavesekvensen er løst, og XML en for opgaven bliver opdateret med brugerens svar, og der gives et antal point for opgavesekvensen 24

25 2.4 Domænemodel Der er opstillet en domænemodel, som skitserer den overordnede klassestruktur for frameworket, der viser sammenhængen mellem klasserne. Domænemodellen fokuserer på, hvordan klasserne til at generere opgaverne interagerer. Datalaget er undladt, og der fokuseres kun på den essentielle del af frameworket. Figur Domænemodel for framework Domænemodellen beskriver, hvordan en AssignmentSequence, som er den klasse, der beskriver en samlet opgave, kan indeholde en eller flere Assignments og IfElseAktiviteter. En IfElseActivitet kan indeholde 2 eller flere IfElseBranches, som igen kan indeholde en eller flere Assignments og IfElseAktiviteter. En Assignment er den klasse, der indeholder information om en opgave i en opgavesekvens. En Assignment kan indeholde flere AssingmentResources, som er referencer til de lyd-, billed- og videofiler, der tilhører en opgave. En Assignment indeholder derudover en eller flere IassignmentContents, som er de elementer, der udgører selve opgaven. 25

26 2.5 Delkonklusion Analysen af frameworket har taget udgangspunkt i den overordnede kravspecifikation og den indledende diskussion over, hvad den skal indeholde. Analysen af frameworket blev delt i to dele, e-lærings og opgave management. Ved analysen af e-læringsdelen blev der fundet 4 områder, der krævede videre analyse for løsninger: Adaptive opgaver Skalerbart framework Grafisk uafhængigt Opgave format Det blev valgt at definere opgavesekvensen via XML, da det er muligt at lave skemaer til at validere opgavesekvensen for fejl. Det blev konstateret, at frameworket bedst kan udvides med nye opgaveelementer, når opgaveelementerne bliver loadet dynamisk via f.eks. reflection. Det blev derudover bestemt, at det er bedst med en lagdeling af frameworket, fordi frameworket skal være målrettet alle grene af.net, og fordi præsentationslaget skal kunne udskiftes afhængigt af, hvilken platform frameworket afvikles på. Ved analysen af data managementdelen bør datalaget af frameworket designes via design by contract, for ikke at binde frameworket til en bestemt datastruktur. I stedet skal der defineres et interface, datalaget skal overholde. Der blev desuden fundet frem til hvilke funktioner, datalaget skal udbyde. Der blev defineret en række Use Cases for senarierne. 26

27 3 Design af framework Dette kapitel omhandler designet af frameworket på baggrund af analysen. Det beskriver et design, der sikrer en fleksibel og skalerbar opgavestruktur, hvordan API et er opbygget, hvordan opgaverne repræsenteres i API et og hvordan der opnås et fleksibelt datalag ved design by contract. 3.1 Overordnet designstrategi Den overordnede designstrategi handler om at designe frameworket, så det er skalerbart og fleksibelt over for fremtidige udvidelser og ændringer. Der vil blive lagt vægt på at bruge arkitektur og design patterns til design af frameworket s API for at anvende gennemprøvede designløsninger, samt for at gøre det nemmere for andre udviklere at videreudvikle frameworket. Frameworket s API vil blive designet via moduler, som hver har et fast ansvar og fast definerede interfaces for at give et mere fleksibelt design i henhold til vedligeholdelse, da hvert modul kan udskiftes, uden at det har indflydelse på de andre moduler. Det øger også mulighederne for at være flere personer om at udvikle/videreudvikle frameworket samtidig, da hver person kan udvikle de forskellige moduler og sammensætte dem løbende. Der vil blive brugt unit test til at teste de forskellige moduler af frameworket s API for at minimere antallet af fejl. Ved at gøre brug af unit test er det med til at sikre at eksistere funktionalitet ikke bliver beskadet ved videre udvikling af frameworket. 3.2 Design af opgavestruktur Dette delkapitel vil beskrive, hvordan opgavestrukturen kan beskrives via XML og XML skemaer, og hvordan opgavestrukturen kan blive adaptiv, så opgaven automatisk tilpasser sig brugerens niveau. Desuden vil kapitlet omhandle, hvilke krav der skal stilles til XML strukturen for, at der er nok information til at delopgaveelementet kan loades dynamisk. Som diskuteret i analysen blev det fastlagt at bruge XML til at beskrive opgavestrukturen. Dette afsnit vil beskrive strukturen for XML skemaet for opgavesekvensen, samt hvilke overvejelser der ligger bag. Ved at gøre brug af et XML skema til at validere XML en, kan der bruges standardiserede værktøjer til validering. Dette er valgt frem for at skrive et program, der specifikt er beregnet til valideringen af opgavestrukturen, hvilket vil være unødigt tidskrævende. Ved at gøre brug af XML skemaer, kan brugerne selv vælge deres foretrukne programmer til at skrive XML og importere skemaer til programmer, der derefter kan validere XML en. Mange programmer kan give intellisense under udvikling af XML til specifikke og 27

28 standardiserede XML skemaer. Strukturen i en opgavesekvens kan beskrives via BNF 5 : Den nedenstående BNF algoritme illustrerer, hvordan de forskellige elementer i opgavesekvensen interagerer med hinanden for at give en gyldigt opgavesekvens. BNF algoritmen kan dog ikke beskrive, hvilke attributter de forskellige elementer kan indeholde. AssignmentSequence::=< Resources >&<Assignment> [<Assignment> <IfElseActivety>] Resurces::=<Resource> Assignment::=[OpgaveElementer] IfElseActiverty::=<IfElseBranch>[<IfElseBranch>] IfElseBranch::= <Expression>& <SubAssignment> [<SubAssignment> <IfElseActiverty>] Expression::=[LastPoint BranchePoint TotalPoint Default] Her gives en beskrivelse af de forskellige elementer, der udgør opgavesekvensen og deres XML attributter. Attributterne vil blive beskrevet i følgende skema Navn Type begrænsning Statisk Default Valgfri Navn: navnet på attributten. Type: hvilken type attributten er, f.eks. string, integer eller boolean. Begrænsning: om der er restriktion på værdien, f.eks. at værdien skal være mellem Statisk: om værdien kan sættes af brugeren. Default: om der er en default værdi hvis ingen angives. Valgfri: om det er en værdi, der skal udfyldes. AssignmentSequence Beskrivelse: Rod elementet for XML strukturen, der indeholder al information for den givne opgavesekvens, hvilke eksterne filer der skal bruges, samt alle de forskellige opgaver, der udgør den samlede opgave. Attributer: Navn Type begrænsning Statisk Default Valgfri AssignmentName string nej nej nej Nej 5 Backus Naur Form 28

29 Resources Beskrivelse: Indeholder listen af ressourcer, der beskriver hvilke eksterne filer, der skal bruges til at gengive opgaven grafisk, f. eks lyd, billeder, video filer på metadata niveau. Attributer: Navn Type begrænsning Statisk Default Valgfri ID ID nej nej nej nej FileName string nej nej nej nej Content string ja nej nej nej Assignment Beskrivelse: Repræsenterer en opgave. Opgaven indeholder de elementer, der udgør opgaven, f.eks. opgavetekst, video, lyd og forskellige svarmuligheder. Attributer: Navn Type begrænsning Statisk Default Valgfri Title string nej nej nej nej ID ID Ja nej nej nej IfElseActiverty og IfElseBranch Beskrivelse: Hvilken vej igennem opgavesekvensens træstruktur der skal vælges, afhængigt af hvad der er svaret i de forrige opgaver. Attributer: Ingen. Expression Beskrivelse: Bruges til at validere, om en IfElseBranch betingelse er opfyldt. Attributer: Navn Type begrænsning Statisk Default Valgfri Expression string Ja nej nej nej OpgaveElementer Beskrivelse: OpgaveElementer er alle de dele, der udgør den samlede opgave, såsom grafiske/svarmuligheders komponenter. XML skemaet skal designes, så det ikke er nødvændigt at Hardcode hvilke komponenter en opgave kan indeholde. Opgaveelementer skal have følgende attributter. Attributer: Navn Type begrænsning Statisk Default Valgfri AssemblyFile string ja Ja nej Class string ja ja nej 29

30 3.2.1 Adaptiv sekvens For at opfylde kravene om opgavesekvensen som adaptiv, skal opgaverne i opgavesekvensen løbene evalueres, efter hvilke opgaver der skal efterfølge hinanden, afhængigt af de tidligere svar. Dette kan gøres ved, at der bliver givet et antal point for hver opgave, og på baggrund af hvor mange point der opnås i opgavesekvensen, vælges den næste opgave, så niveauet bliver individuelt tilpasset. Se Figur Figur Gennemløb af opgavesekvens. For at opnå den adaptive del, skal der vælges en vej i gennem opgaven afhængigt af antal point opnået tidligere i opgaven. Det fungerer som et enten/eller valg, hvor der skal vælges et af mindst to mulige valg. Der kan evalueres på følgende 4 forskellige måder, med forskellige point typer til hver måde: LastPoint: point opnået i sidste opgave. BranchePoint: point opnået i sidste enten/eller valg. TotalPoint: point opnået i alt i gennem hele opgavesekvensen. Default: Hvis fx kriteriet for at gå en bestemt vej igennem opgavesekvensen ikke opfyldes, skal der altid være en alternativ vej at falde tilbage på. 30

31 Derudover er der valgt følgende operatorer til at validere de opnåede point: GreaterEqual LessEqual Equa GreaterThen LessThen Derved er det muligt at validere et udtryk, som bestemmer vejen gemmen opgaven Dynamisk loading af opgave elementer For at kunne opfylde kravet om, at opgaven skal kunne videreudvikles med nye opgavetyper, uden at API et skal recompiles, skal indholdet i opgavene loades dynamisk. Derfor bruges reflection. Reflection kræver som minimum af information at vide, hvilken assembly fil der skal bruges, samt hvilken klasse, der skal instantieres samt namespacet, der høre til den klasse, der skal instantieres, da der kan være flere klasser med samme navn. Derfor kan der stilles krav til alle opgaveelementer, at de indeholder følgende attributter: AssemblyFile og Class beskriver hvilken fil samt klasse, der skal loades i opgaven. Ved at gøre de 2 attributter fixed, er det ikke op til opgave-designeren at holde styr på, hvilke klasser der er forbundet til specifikke XML elementer, men kun op til APIdesigneren. 3.3 Design af API Dette afsnit vil beskæftige sig med designet af det API, der danner grundlag for et generisk framework til e-læring. Endvidere er der overvejelser bag arkitekturen for API et, samt for hvordan datalaget kan designes via design by contract. Der beskrives hvordan der laves en XML-til-objekt mapping for at gengive XML opgaven via objekt struktur Overordnet design struktur Følgende afsnit vil beskrive den overordnede designstruktur for API et. På baggrund af analysen blev det besluttet, at frameworket skal kunne implementeres i ASP.NET og Windows presentations foundation applikationer, for at give større anvendelsesmuligheder. For ikke at binde frameworket til en bestemt datastruktur/database blev det lagt fast i analysen, at frameworket definerer et interface til datastrukturen. På baggrund af de ovenstående krav er der blevet brugt en 3-lags arkitektur, som vist på Figur Overordnet lagdeling af API. 31

32 Figur Overordnet lagdeling af API. Ved dette 3 lags Architectural patteren opnås lav kobling mellem lagene, hvilket er en nødvendighed for at opfylde kravene om at præsentationslaget og datalaget kan udskiftes, afhængigt af hvilken platform API et afvikles på eller hvilket data storage, der bruges. Præsentationslag Domæne specifik grafisk brugergrænseflade til at vise opgaver. Dette giver en mere fleksibel struktur, da præsentationslaget kan udskiftes afhængigt af, hvilken platform frameworket skal afvikles på. Dette øger også fleksibiliteten af frameworket, da det gør frameworket skalerbart, så det nemt kan udvides til andre.net platforme, f.eks. Silverlight. Domainelag Domainelaget indeholder logikken til at håndtere opgavesekvensen, og til at vælge hvilke opgaver, der skal vises, afhængigt af brugerens svar. Domainelaget er uafhængig af, hvilket.net platform der benyttes. Det er domainelagets opgave at mappe opgaverne, der er beskrevet via XML til en objekt struktur, samt at dynamisk loade opgaveelementer via reflection. Datalag Dette lag er ansvarlig for at hente og gemme opgavedata, samt at udtrække statistik om brugere. Datalaget kan udskiftes afhængigt af, hvilken datastruktur der bruges, for ikke at tvinge udviklerne til at bruge en bestemt datastruktur. Denne fleksibilitet opnås ved at gøre brug af udviklingsmetoden design by contract, hvor datalaget definerer et interface, som de konkrete implementationer af datalaget skal overholde. Der vil blive lavet en implementation af kontrakten til en MSSQL database. 32

33 Den overordnede designstruktur et ikke tilstrækkeligt for at begynde at implementerer API et, men beskriver den overordnede struktur for designet. Ved at bruge et lagdelt design opnås et mere fleksibelt og skalerbart design, hvor de forskellige moduler kan byttes ud uden at skulle redesigne resten af API et. For at opnå den lave kobling mellem de forskellige lag, bliver der brugt design pattern Dependency injection[9], der beskriver, hvordan der kan opnås lav kobling mellem 2 moduler ved at indsætte det ene modul i det andet, frem for at have hardcoded relationerne modulerne imellem Design af domainelag Dette afsnit vil beskæftige sig med designet af de kritiske dele af domainelaget, altså hvordan opgaven kan mappes til en objektstruktur og hvordan opgaveelementerne skal designes, så det er muligt at loade dem dynamisk, samt hvordan opgaveelementerne skal designes for at blive platformsuafhængige Objekt XML mapping For at API et kan arbejde med opgavesekvensen, skal den mappes til en objektstruktur, der gengiver opgaven og dens sammensætning. Dette kendes også fra relationsdatabaser som O/R mapping[8], hvor data bliver konverteret fra et domæne til et andet. Ved at mappe opgavesekvensens XML til en objekt struktur gives følgende klassediagram for strukturen på Figur Opgavesekvens objekt struktur. AssignmentSequence +Tags : List<string> +Description : string +AssignmentName : string 1 1 AssignmentResources 1 * AssignmentResource +UID : string +FileName : string -Content : string +Data : byte[] * IAssignmentContent 1 IfElseBranche 1 IFElseActivertiy +Title : string +ID : string Assignment * 1 1 * IAssignmentContent +PointType : string +Expression : string +Value : int Expression Figur Opgavesekvens objekt struktur 33

34 Figur viser klassediagrammet over opgavesekvensens XML, når den er mappet til en opgavestruktur. Det ses, at den minder meget om XML strukturen, og at AssignmentSequence indeholder et objekt af typen AssignmentResources, der har en liste af AssignmentResource, som indeholder information om de eksterne filer. AssignmentSequence indeholder derudover 1 eller flere IassignmentContent, som er et fælles interface for IFElseActivertiy og Assignment, da det ikke er muligt at gemme to forskellige objekttyper i én liste. IFElseActivertiy og Assignment kunne gemmes i hver deres liste, men det vil give problemer med overholdelse af den rækkefølge, defineret i XML dokumentet. IFElseActivertiy indeholder 2 eller flere IFElseBranche, som er veje gennem træet, IFElseBranche indeholder et Expression objekt, der validerer om en branches kriterier er opfyldt. IFElseBranche indeholder ligesom AssignmentSequence en liste af IassignmentContent, da der i en branche både kan være opgaver og aktiviteter. Assignment kan indeholde 1 eller flere IAssignmentContent som er et fælles interface for alle opgave elementer, IAssignmentContent kan indeholde nul eller en AssignmentResource Opgaveelementer I afsnit blev det beskrevet, hvordan opgavesekvensen mappes fra XML til en objektstruktur. Dette afsnit vil beskrive, hvordan opgaveelementerne mappes til en objektstruktur, og hvordan opgaveelementerne skal designes for at blive platformuafhængig. For at designe opgaveelementerne, så de kan blive platformuafhængige, er der valgt at konstruere en 2-lags deling, så logik og gui interfacet deles i hver deres klasse. På den måde kan gui interface udskiftes afhængigt af, hvilken platform frameworket afvikles på, og logiklaget kan genbruges. Dette er vist på Figur Opgaveelementernes arkitektur Opgaveelementernes arkitektur IAssignmentContent definere interfacet som alle opgaveelementer skal implementerer. Det er derefter den konkrete implantation af opgaveelementerne 34

35 der dekoder XML en og står for at opdatere de samlede antal point, der er opnået gennem opgaveløsningen. IAssignmentContent har 3 properties, som bliver fastsat, når opgaveelementet bliver instantieret. XmlData, er det XML, som udgør opgaveelementet, Resurce er en referance til resourceobjektet, indeholdende information om ressourcen (hvis der er en). Og Parrent er en reference til den opgave opgaveelementerne tilhører. IAssignmentGui er et fælles interface for alle opgaveelementernes grafiske brugergrænseflade der skal implementeres før det er muligt at behandle alle GUI elementer ens, da de nedarver fra forskellige baseklasser afhængigt af på hvilken platform de skal afvikles. For at opgaveelementerne kan vises på tværs af platforme, skal der være en implementering af GUI laget til hver platform, fordi platformene viser data til skærmen forskelligt. IAssignmentContent har funktionen GetGFXContent, der tager en type at GFXType til at bestemme hvilken implementation af GUI laget der skal retuneres Dynamisk loading af opgaveelementer Som beskrevet i analysen skal opgaveelementerne loades dynamisk, så det er muligt senere at tilføje nye opgaveelementer uden at recompile Frameworket. I afsnit blev det beskrevet, hvordan XML en til opgavesekvensen blev designet for at muliggøre brugen af reflection. Denne funktion loader opgaveelementerne dynamisk, ved at opgaveelementerne har 2 attributter: AssemblyFile og Class til at identificere, hvilken fil og klasse, der skal bruges til at instantiere objektet. For at loade opgaveelementerne dynamisk, bliver der gjort brug af en hjælpeklasse, der dynamisk loader opgaveelementet gennem reflection og returnerer et objekt af typen IAssignmentContent, der er et fælles interface for alle opgaveelementer. Dette gør det muligt at udvide frameworket med nye opgaveelementer senere hen, ved at der blot laves et XML skema for opgaveelementet samt en klasse, der implementerer IAssignmentContent i en assembly fil. Nye elementer vil på den måde kunne loades uden at recompliere framewoket. Dette giver også mulighed for 3-parts udviklere at bidrage til frameworket med nye opgavetyper. Det er et krav, at alle assembly filer er i en bestemt mappe, så frameworket ved, hvorfra filerne skal loades. Figur beskriver, hvordan opgaveelementerne loades dynamisk. 35

36 ::AssignmentSequence <<create>> Assignment <<create>> AssignmentContentFactory While more assignment content content=loadcontent(xml) Load opgaveelement via reflection <<create>> OpgaveElement XmlData=xml Resource=resurces[resurceId] Parrent=parrent Init Add(content) Sekvensdiagram load opgaveelementer dynamisk Assignment gemmengår alle XML nodens børn og kalder LoadContent i AssignmentContentFactory, der dekoder XML noden for, hvilken klasse der skal loades i hvilken assembly, og om opgaveelementer gør brug af ressourcer. Når opgaveelementet er instancieret via reflection konverteres det til typen IAssignmentContent, hvor objektet får en reference til det XML, der beskriver opgaveelementet, da hvert opgaveelement ved, hvordan det skal dekode XML en for at opfylde kravene til opgaveelementet. Desuden får opgaveelementet en reference til den ressource der skal bruges, og en reference til den opgave der er dens forælder og til sidst kaldes Init på opgaveelementet hvor XML en bliver dekodet for at være klar til brug. Elementet bliver tilføjet til listen over opgaveelementer i opgaven. 36

37 Loading af ressourcer For at frameworket kan vise billeder, video og så videre, gør frameworket brug af eksterne ressourcer som f.eks. filer og ressourcer på Internettet, der ikke er indeholdt i den XML, der definerer opgaven, da dette kunne give store XML filer, der tager lang tid at loade. Det er ikke alle ressourcer, der bliver brugt i en opgavesekvens; dette er afhængigt af, hvilke opgaver, der bliver vist for brugeren. Da frameworket ikke kræver en bestemt datastruktur, men i stedet for definerer et interface, som datalaget skal overholde, kan de ressourcer, frameworket gør brug af, komme mange steder fra. Hvis der skal defineres en måde, hvorpå alle ressourcer kan behandles og loades generelt, løses dette ved, at alle ressourcer nedarver fra en baseklasse, og at ressourcerne loades via factory design pattern. Dette giver følgende udvidelser til klassediagrammet, som vist på Figur Klassediagram med ressource factory. 1 ResourceFactory +CreateInstance(in node : XmlNode) : AssignmentResource FileFactory SqlResourceFactory +CreateInstance(in node : XmlNode) : AssignmentResource +CreateInstance(in node : XmlNode) : AssignmentResource AssignmentSequence +Tags : List<string> +Description : string +AssignmentName : string AssignmentResources 1 * AssignmentResource +UID : string +FileName : string -Content : string +Data : byte[] 1 * IAssignmentContent SqlResource FileResource HttpResource IfElseBranche 1 IFElseActivertiy 2..* 1 +PointType : string +Expression : string +Value : int Expression +Title : string +ID : string Assignment * IAssignmentContent Figur Klassediagram med ressource factory På klassediagrammet fremgår det, at der er blevet tilføjet ResourceFactory, som en baseklasse, FileFactory og SqlResourceFactory, som er konkrete implementationer af ResourceFactory til at loade de konkrete implementationer af AssignmentResource. Ved at gøre brug af en baseklasse til ressourcer, gives der et mere fleksibelt design, fordi ressourcer til frameworket kan komme flere steder fra, f.eks. fra filer eller databaser. API et kan udvides til i fremtiden at hente ressourcer fra f.eks. billeder 37

38 eller video tjenester på Internettet ved at lave en ny implementering af AssignmentResource, der henter disse data samt en factory til at instantiere den nye klasse. Factory design pattern medfører, at det ikke er nødvendigt at hardcode hvilke implementeringer af AssignmentResourcs, der skal bruges, når ressourcene skal loades. I stedet gives en factory til AssignmentResources, som ved, hvilken instans af AssignmentResources, der skal loades. Dette giver et mere fleksibelt design, idet det bliver muligt (ved runtime) at ændre hvorfra/hvordan ressourcerne skal loades Design af datalag Dette afsnit vil beskrive, hvordan datalaget er designet for at opnå en skalerbar struktur, der er nem at udvide til andre datastrukture. I analysen blev det fastlagt at designe datalaget, så det kan udskiftes afhængigt af, hvilken datastruktur, der anvendes. Design by contract løser dette problem. Der defineres et interface, som alle implementationer af datalaget skal implementere. Interfacet til datalaget definerer hvordan der interfaces til datalaget via metoder og objekter. Se Figur Datalag klassediagram. Figur Datalag klassediagram Ovenstående klassediagram beskriver hvilke klasser, der udgør datalaget i API et. IDataLayer er det interface, alle implementationer af datalaget skal implementere, som har metoder til at tilføje nye opgaver til systemet, give opgaver til brugere og hente statistik om brugerne. 38

39 BaseAssignmentData er baseklasse for AssimentData og UserAssignmentData, som indeholder alle informationer om en opgave, XML dokumentet der beskriver opgaven, samt de XML skemaer, der skal bruges til at validere XML en og de ressourcer, opgaven kræver. AssignmentResources er baseklasse for opgaveressourcer, der har information om ressourcen og dens data. IDataDelayedLoading interfacet bruges til at loade XML og data ressourcer, når de skal bruges, frem for at loade alle data på en gang. Dette øger performance, når en opgave skal loades. BaseAssignmentData kan gøre brug af delayed loading til at loade XML og assignment ressourcedata for at reducere loading tiden af objektet, da det er den klasse, der indeholder alt information om opgaver i systemet. Det er ikke altid nødvendigt at XML og ressource data bruges. Hvis der skal vises en liste over løste opgaver, kan UserAssignment objekterne bindes til et datagrid for at vise, hvilke opgaver der er løst. Derefter bliver XML en og ressourcedata ikke brugt unødigt. Hvis det bliver nødvendigt at se på den XML, der udgør opgaven, kan den loades, så snart der er brug for det. Se Figur Loading af UserAssignmentData for et sekvensdiagram, hvor data loades via delayed loading 39

40 Figur Loading af UserAssignmentData Design af præsentationslag De forrige afsnit har beskæftiget sig med designet af logikken i frameworket, hvordan det skal designes, så det er skalerbart og fleksibelt i forhold til udvidelser i fremtiden. For at gøre det nemt at bruge frameworket, skal der designes en række ekstra komponenter, så opgaverne kan vises på de forskellige platforme, ASP.NET, WPF. Komponenterne skal designes som standardkomponenter, der kan trækkes ind på userinterfacet på samme måde som de standardkomponenter, der følger med til.net Frameworket. Komponenterne skal designes som en wizard, så de kan vise opgaver. En wizard er brugervenlig og har eksempelvis en knap, så brugeren selv kan gå videre til næste opgave. 40

41 Opgave Næste Grafisk layout af wizard Derud over skal opgavewizard en inkludere startopgave event, ny opgave event og slutopgave event, som udviklerne kan subscribe på, så der fx kan laves tidsmålinger på, hvor lang tid det tog brugeren at løse opgavesekvensen. Da komponenterne skal kunne afvikles på forskellige.net platforme, kan der ikke laves en komponent, der virker til alle platforme, så de må udvikles til samtlige platforme, frameworket skal afvikles på. 3.4 Delkonklusion Kapitlet har beskrevet, hvordan frameworket er designet for at opnå fleksibilitet og skalerbarhed, så frameworket kan afvikles på.nets platforme. Der er valget at gøre brug af et 3-lags design, så det er muligt af udskifte præsentationslaget afhænligt af, hvilken platform frameworket skal anvendes på. Datalaget er blevet designet via design by contract, så frameworket kan udvides med nye datalag uden at recompile hele frameworket. Det er designet hvordan XML skemaet, der skal validere opgavesekvensen, skal designes, for at det er muligt at udvide frameworket med nye opgaveelementer uden at ændre det XML skema, der beskriver opgavesekvensen eller recompile frameworket, ved at loade opgaveelementerne dynamisk via reflection. 41

42 4 Implementering og test Dette kapitel vil beskæftige sig med implementeringen af frameworket i C#, samt hvordan det testes for at sikre kvaliteten. Der vil blive lavet 2 testprogrammer som proof of concept, hvor frameworket implementeres ved at udforme programmer, der understøtter e-læring og kan teste, at frameworket kan afvikles både som web applikation og Windows applikation. Det vil blive beskrevet, hvordan det medfølgende datalag til MSSQL databasen er implementeret samt beskrive, hvilke opgaveelementer der medfølger til frameworket som standard. Desuden beskrives, hvordan de er implementeret, og hvordan nye opgaveelementer kan konstrueres. 4.1 Strategi for test af frameworket I dette afsnit beskrives strategien for at verificere, at frameworket virker korrekt. Testene af frameworket vil blive udført via unit testing. Som beskrevet i afsnit er Test-Driven Development (TDD) en metode til at teste software på, både på komponentniveau og som samlet system. Generelt er filosofien bag TDD, at der skrives tests til applikationen, før man implementerer den. Implementeringen udføres iterativt ved at gentage tre faser: Rød fase Der skrives test, der afspejler kravspecifikationen for applikationen. Testkoden gør, at applikationen ikke kan kompilere, idet der ikke er skrevet kode til applikationen endnu. Grøn fase Applikationen implementeres med det ene formål, at de skrevne tests skal køre succesfyldt. Refaktoreringsfase Koden refaktoreres, så fx duplikeret kode elimineres. Anvendte tests kan med fordel skrives vha. et Unit framework, og da.net i forvejen benyttes i implementeringen, er det indbyggede Unit testing framework et nærliggende valg. Fordelen ved at benytte TDD er, at så snart man ved, at ens tests forløber fejlfrit, er kravspecifikationen opfyldt. Derudover kan ændringer i koden kontrolleres, så ændringerne ikke har ødelagt andre dele af koden ved blot at eksekvere alle tests igen. Metoden er velegnet i implementeringen af frameworket, idet der skrives tests for hvert modul samt som en samlet enhed. Metoden er som sådan god, men kvaliteten af det færdige produkt afhænger af kvaliteten af testene. Derfor er det vigtigt at testene gennemgår alle dele af de enkelte moduler, både som de skal virke, og som de forventes at fejle, for at teste fejlhåndteringen. Ud over unittest vil der blive udviklet testprogrammer til både Web og Windows delene, som gør brug af frameworket, for at lave en proof of concept test, der tester, om frameworket kan bruges som forventet. 42

43 4.2 Implantation af opgave XML struktur Dette delafsnit vil beskrive implementeringen af det XML skema, der bruges til at validere opgavesekvensen samt beskrive, hvordan der udvikles nye opgaveelementer hvad angår krav til XML skemaet. I afsnit 3.2 blev designet bag XML skema beskrevet. Den følgende BNF algoritme beskriver, hvordan de forskellige elementer skal kunne interagere med hinanden: AssignmentSequence::=< Resources >&<Assignment> [<Assignment> <IfElseActivety>] Resurces::=<Resource> Assignment::=[ OpgaveElementer] IfElseActiverty::=<IfElseBranch>[<IfElseBranch>] IfElseBranch::= <Expression>& <SubAssignment> [<SubAssignment> <IfElseActiverty>] Expression::=[LastPoint BranchePoint TotalPoint Default] Ved at oversætte denne BNF algoritme til et XML skema, kan det defineres, hvad der er gyldig XML til at beskrive opgavesekvensen. Når der laves et XML skema, skal der også defineres et namespace, som kendes fra programmering, så det er muligt at gøre brug af flere elementer med samme navn, men differentieret ved forskellige namespaces. Normalt beskrives namespaces til XML via URL adresser, i dette tilfælde For at gøre det muligt at Assignment elementet kan indeholde forskellige opgaveelementer, sættes elementet til any og namespacet til other, så et Assignment element kan indeholde alle elementer, der er i et andet namespace. Se nedenstående udsnit af XML skema: <xs:complextype name="assignmenttype"> <xs:sequence minoccurs="1" maxoccurs="unbounded"> <xs:choice minoccurs="1" maxoccurs="unbounded"> <xs:any namespace="##other" minoccurs="1" maxoccurs="unbounded" processcontents="strict"/> </xs:choice> </xs:sequence> <xs:attribute name="title" type="xs:string"use="required"/> <xs:attribute name="id" type="a:idtype" use="required"/> </xs:complextype> Derved bliver det muligt at udvikle nye opgaveelementer fremover uden at skulle ændre i skemaet for opgavesekvensen. I afsnit blev kravne til XML skemaet beskrevet så det er muligt at gå flere veje gennem opgavesekvensen, alt afhængigt hvad brugeren har svaret på i de tidligere spørgsmål. 43

44 Vejen gennem opgavesekvensens træ kan f.eks. beskrivers via følgende XML: <IFElseActiverty> <IFElseBranch> <Expression> <BrancePoint Expression="GreatherThen">2</BrancePoint> </Expression> Assignment xml </IFElseBranch> <IFElseBranch> <Expression> <LastPoint Expression="Equal">0</LastPoint> </Expression> Assignment xml </IFElseBranch> </IFElseActiverty> IFElseActiverty beskriver, at den næste viste opgave skal vælges ud fra brugerens tidligere svar. Der er 2 gyldige veje gennem denne del af træet. IFElseBranch beskriver en konkret gren af træet, men før denne gren kan følges, skal en betingelse være opfyldt. Betingelsen beskrives via Expression, der kan indeholde følgende elementer: LastPoint: point opnået i sidste opgave. BranchePoint: point opnået i sidste gren. TotalPoint: point opnået i alt igennem hele opgavesekvensen. Default: Hvis fx kriteriet for at gå en bestemt vej igennem opgavesekvensen ikke opfyldes, skal der altid være en anden vej at falde tilbage på. Og disse elementer kan have følgende værdier i deres Expression attributter: GreaterEqual LessEqual Equa GreaterThen LessThen. til at validere, hvilken vej gennem træet der skal vælges Implementering af opgaveelementer I ovenstående afsnit blev det beskrevet hvordan opgavesekvensens XML skema blev implementeret, så det er muligt at tilføje nye opgaveelementer uden at omskrive XML skemaet. I afsnit blev der beskrevet, hvordan opgaveelementerne skal designes, for at det er muligt at udvide frameworket med nye opgaveelementer uden at recompile API et. Dette gøres gennem reflection. For at det er muligt at loade opgaveelementer ved brug af denne funktion, kræves det at API et ved, hvilken assembly den givne klasse skal instantieres af. Dette løses ved at XML skemaet, der beskriver XML en for opgaveelementet, beskriver hvilken klasse, der skal instanteres 44

45 og fra hvilken assembly. Dermed er det ikke op til brugeren af opgaveelementet at vide, hvilke klasser der skal bruges. Se nedenstående udsnit fra XLM skemaet. <xs:complextype name="assignmentelementtype"> <xs:complexcontent> <xs:attribute name="assemblyfile" fixed="assignmentcontent.dll"/> <xs:attribute name="class" fixed="assignmentcontent.element"/> </xs:complexcontent> </xs:complextype> De 2 attributter i alle opgaveelementers XML skemaer der skal definere er AssemblyFile og Class, som beskriver, hvilken fil der skal bruges til at instantierer klassen fra. Disse elementer skal være fixed, så det ikke er op til brugeren at definere, hvad AssemblyFile og Class refererer til. Hvis opgaveelementerne kan gøre brug af eksterne ressourcer, skal skemaet desuden definere følgende element, RefID, der beskriver, hvilken ressource, der skal knyttes til opgaveelementet. <xs:attribute name="refid" use="required" type="assignment:idtype"/> Nu er XML skemaet konstrueret, og derefter skal der laves de klasser, der udgør logikken og presentation for opgaveelementerne. I afsnit 0 blev designet for de interfaces der beskriver opgaveelementet fremlagt. I henhold til det fordefinerede XML skema, der beskrev opgaveelementet, skal klassen Element i namespacet AssignmentContent bruges, når elementet skal loades. Klassen skal lægges i filen AssignmentContent.dll, som beskriver logikken for opgaveelementet. Filen skal nedarve interfacet IAssignmentContent. For at gøre opgaveelementet platformsuafhængig, skal der laves et præsentationslag for de platforme, der skal understøttes. Præsentationslagene skal nedarve fra IAssignmentGui. Derved kan logiklaget give en instans af IAssignmentGui, når GetGfxContent kaldes via logiklaget med en GfxType afhængigt af, hvilken platform frameworket afvikles på. 4.3 Implementation af SqlDatalag I analysen blev det krævet, at frameworket skulle være uafhængigt af datastrukturen og i stedet definere et interface for datalaget, for derved at gøre det muligt at gøre brug af flere forskellige datastrukturer. For at gøre frameworket klar til brug medfølger der en implementering af datalaget til Microsoft SQL Server Dette afsnit vil beskrive, hvordan der laves en ny implementering af datalaget samt 45

46 beskrive den konkrete implementering af datalaget til en Microsoft SQL server Det vil blive gennemgået, hvordan databasen er designet, og hvordan datalaget bliver implementeret, samt hvilke klasser, der skal nedarves fra og hvorfor Design af database Det er valgt at designe databasen, så den består af 5 tabeller. Den første tabel er til alle opgavesekvenser, som i databasen kaldes Assignments. Tabellen indeholder en beskrivelse af opgavesekvenser, navnet på den pågældende sekvens, hvornår den blev oprettet, hvem der oprettede den samt den XML, der beskriver opgavesekvensen. Assignments gør brug af en anden tabel, AssignmentsResources, til at bevare informationer om de ressourcer, der bliver brugt i opgaverne. Denne tabel gør brug af one-to-many relationship princippet, da Assignments kan have 0, 1 eller flere ressourcer. Tredje tabel, AssignmentsTag, indeholder de tags, der er med til at beskrive opgavesekvensen, og som bruges, når der søges efter opgaver. Fjerde tabel, AssignmentXMLSchemas, indeholder alle de XML skemaer, en opgavesekvens bruger, det vil sige XML skemaet, der beskriver opgaven, samt de skemaer, der beskriver opgaveelementerne. Den femte tabel, UserAssignments, indeholder information om de opgavesekvenser, der er givet ud til brugerne af systemet. Tabellen indeholder information om, hvilken elev, der har fået opgaven, en reference til Assignments for at vide, hvilken opgave det er, AssignmentsXml, som er en kopi af Assignments XML, som bliver overskrevet med brugerens svar, når opgaven er løst. Derudover indeholder tabellen feltet Date, der angiver, hvornår opgaven blev givet og HandInDate, som er den dato, opgaven skal afleveres. Subject og SubSubject er en kategori og underkategori, opgaverne får, så det er nemmere at lave statistik på brugerne. På den måde kan man fx få en gennemsnitsscore af alle opgaver. Selve Date er den dato, opgaven er blevet afleveret, og hvis den ikke er afleveret, har feltet værdien null. Point er det antal point, der er opnået i opgavesekvensen. 46

47 4.3-1 Databasediagram Implementation af datalag For at implementere et datalag til MSSQL server, er der lavet konkrete implementeringer af de interfaces og baseklasser, der er med til at udgøre datalaget. Dette fremgår af figur MSSQL datalag Selve interfacet til datalaget er IDatalayer, der beskriver, hvordan opgaver findes og gemmes. IDataDelayedLoading kan interfaces, hvis der ønskes, at klassen AssignmentData og UserAssignmentData skal kunne gøre brug af delayed loading. For at klassen AssignmentSequence, som er den klasse, der repræsenter en opgavesekvens, kan gøre brug af de ressourcer, der ikke er bundet til et bestemt datalag, skal der laves en implementation af klasserne ResourceFactory og AssignmentResource. RessourceFatory s opgave er at instantiere et objekt af typen AssignmentResource, alt afhængigt af datastrukturen. SqlResourceFactory s opgave er at kreere instanser af typen SqlResource, når funktionen CreateInstance kaldes, for derved at undgå at AssignmentSequince bliver hardcodet til en bestemt datastruktur. I stedet gør den brug af Factory design patteren, hvor den gives en factory til AssignmentSequince typen, som har til opgave at instantiere ressourcer, for derved opnået en lav kobling mellem AssignmentSequince og ressourcerne af typen AssignmentResource. Der bruges delayed loading til implementeringen af SQL Server 2005 datalaget for at optimere loadingstiderne. Ved at lave en implementation af IDataLayerDelayedLoading kan klasserne AssignmentData og UserAssignmentData loade XML data og XML skemaerne, når de skal bruges, frem for det øjeblik, objektet bliver oprettet. 47

48 IDataLayer IDataDelayedLoading +AddNewAssignment() : int +FindAssignment() : AssignmentData +FindAssignments() : List<AssignmentData> +GetResources() : List<AssignmentResource> +GetResource() : AssignmentResource +AddAssignmentToUser(in users) +AddAssignmentToUser() +GetUserAssignments() +GetUserAssignment() : UserAssignmentData +SaveUserAssignment(in assignmentdata : UserAssignmentData) IDataLayer +SqlDatabase(in CconnectionString : string) +AddNewAssignment() : int +FindAssignment() : AssignmentData +FindAssignments() : List<AssignmentData> +GetResources() : List<AssignmentResource> +GetResource() : AssignmentResource +AddAssignmentToUser(in users) +AddAssignmentToUser() +GetUserAssignments() +GetUserAssignment() : UserAssignmentData +SaveUserAssignment(in assignmentdata : UserAssignmentData) ResourceFactory +GetAssignmentXml(in assignmentuid : int) : string +GetUserAssignmentXml(in assignmentuid : int) : string +GetData(in resourceid : int) : <unspecified> +GetData(in assignmentid : int, in resourceid : string) : <unspecified> +GetAssignmentXmlSchemas(in assignmentuid : int) : <unspecified> SqlDelayedLoading +SqlDelayedLoading(in connectionstring : string) : SqlDelayedLoading +GetAssignmentXml(in assignmentuid : int) : string +GetUserAssignmentXml(in assignmentuid : int) : string +GetData(in resourceid : int) : <unspecified> +GetData(in assignmentid : int, in resourceid : string) : <unspecified> +GetAssignmentXmlSchemas(in assignmentuid : int) : <unspecified> AssignmentResource +ResurceType : ResurcesContents +UID : string +FileName : string +FullFileName : string +Data : Byte[] +CreateInstance(in node : XmlNode) : AssignmentResource SqlResourceFactory +CreateInstance(in node : XmlNode) : AssignmentResource +SqlResourceFactory(in connectionstring : string, in assignmentid : int) : SqlResourceFactory SqlResource +ResurceType : ResurcesContents +UID : string +FileName : string +FullFileName : string +Data : Byte[] +SqlResource() : SqlResource MSSQL datalag 4.4 Proof of concept Dette afsnit vil omhandle, hvordan det verificeres, om frameworket lever op til de overordnede krav, der er specificeret i kravspecifikationen. For at verificere de overordnede krav, vil der blive lavet 2 programmer som proof of concept : Et program, som en simpel webportal der udbyder e-læring og et Windows program, der understøtter e-læring. I analysen blev der fundet frem til Use Cases, der beskriver, hvordan det bør være muligt at bruge frameworket til de Use Cases, der skal afspejles i de 2 proof of concept programmer. De 4 overordnede krav er Frameworket skal udvikles, så det kan understøtte web og desktop applikationer Opgaverne skal kunne være adaptive. Muligt at udvide frameworket med nye opgavetyper. Opgavemanagement Det første krav opfyldes ved, at samme opgave kan løses i begge programmer. Det andet krav opfyldes ved, at de rigtige svar vælges gennem opgavesekvensen og de forventede opgaver vises efterfølgende. Der er desuden unit test, der tester den adaptive del af opgaverne. 48

49 Det tredje krav opfyldes ved, at der udvikles to moduler med opgaveelementer, med mulighed for anvendelse i en opgavesekvens, der kan vises i de to programmer. Det fjerde krav opfyldes ved at det er muligt at oploade nye opgaver og give dem til brugerne, og se statistik over opgaverne Proof of concept - Web portal Første proof of concept program er en simpel webportal, der understøtter e-læring og management. Portalen består af to dele, et lærermodul og et elevmodul. Lærermodulet består af en oversigt, hvor det er muligt at følge elevernes udvikling og overvåge, hvilke opgaver der er stillet se Oversigt over opgaver givet til en studerende Oversigt over opgaver givet til en studerende Desuden består lærermodulet af en håndteringsfunktion af opgaverne, så læren selv kan stille opgaver til brugerne se Oversigt over opgaver i systemet Oversigt over opgaver i systemet 49

50 Elevmodulet består af to dele, hvor eleven i den ene del kan se, hvilke opgaver der er stillet se Oversigt over den studerendes opgaver Oversigt over den studerendes opgaver I den anden del løses de opgaver, der er tilgængelige. Se Screenshot: når en opgave løses i en webportal Proof of concept - Windows program Det andet program, der er udviklet som proof of concept for frameworket, er et Windows Presentation Foundation program, der understøtter at brugere kan løse opgaver. Programmet skal kun understøtte elevdelen, altså hvor eleven kan vælge en opgave og derefter løse den. Den kritiske del af frameworket er at kunne gengive opgaverne på forskellige platforme. Eleven kan vælge en opgave fra listen over opgaver se Oversigt over den studerendes opgaver. 50

51 4.4-5 Oversigt over den studerendes opgaver Når den opgave der skal løses er valgt, skiftes der til del af programmet hvor det er muligt at løse opgaver se Screenshot: når en bruger løser opgaver i et WPF program Screenshot: når en bruger løser opgaver i et WPF program 51