BabeLLab Et netværksbaseret sproglaboratorium

Transkript

1 BabeLLab Et netværksbaseret sproglaboratorium Eksamensopgave i: Projektkursus Systemudvikling 2011 Søren Frejstrup Grav Petersen, CPR: KU-Bruger: cng863, Eksamensnummer: 21 Instruktor: Andreas Frisch Gruppe-id: A0-4 Gruppemedlemmer: Thomas Nørskov Nielsen Martin Simon Haugaard Ruben Nielsen Kursus-id: 5100-B3-Førsteårsprojekt/Fl/01 Afleveret d. 20 juni 2011

2 Dette værk er en eksamensopgave omhandlende et førsteårsprojektkursus i datalogi skrevet af Søren Frejstrup Grav Petersen, Datalogisk Institut, Det Naturvidenskabelig Fakultet, Københavns Universitet, Danmark. Dokumentet, herunder layout og typografi er trykt ved hjælp af L A TEX2 ε i dokumentklassen extarticle. Brødteksten er trykt med Computer Modern 12pt med margin på 1.08in. Forsidebilledet er en skitse over udbredelsen af de forskellige sprogstammer i verden.[7] Layout og typografi er fremstillet af forfatterne ved hjælp af følgende L A TEX2 ε pakker: inputenc, fontenc, babel, amsfonts, amsmath, float, geometry, graphicx, color, url, tikz, multirow, rotating, sidecap, caption, listings. Alle figurer benyttet i dokumentet, bortset fra forsidebilledet, er originale, og er konstrueret med freeware programmet Diagram Designer[20] og L A TEX2 ε s egne funktioner. i

3 Indhold 1 IT-projektet Oversigt Uddrag af problemområdet Anvendelsesområdet Endelig model Brugergrænsefladen Programdokumentation Uddrag af implementationen Om samarbejdet Forholdet udadtil Forholdet indbyrdes i gruppen Refleksion over resultat og forløb Styrker og svagheder samt samspil mellem projektaktiviteterne Forbedringer Diskussion af udvalgt artikel Tilgang til systemudvikling og erfaringer Ligheder og forskelle mellem artikel og kursuslitteratur Litteraturliste 20 A Første prototype 22 A.1 Valg af prototype A.2 En elev og en lærers brugergrænseflade A.3 Navigeringsdiagrammer A.4 Evaluering og resultat af første prototype A.5 Analyse og diskussion af evaluering A.6 Konklusion af første prototype B Anden prototype 27 B.1 Navigeringsdiagram B.2 Evaluering af anden prototype B.3 Resultat af evaluering B.4 Analyse og diskussion af evaluering B.5 Konklusion af anden prototype C Eksempel på kode 36 C.1 Online_db_mod klassen D Uddrag af Javadoc 49 D.1 Package control D.2 Package database D.3 Package exceptions D.4 Package makedatabases D.5 Package view ii

4 E Referater 50 E.1 Første møde med ITMEDIA, KUA 9/ E.2 Sproglaboratoriebesøg v. Nina Møller Andersen 16/ E.3 Sproglaboratoriebesøg v. Elena Lorentzen 21/ E.4 Workshop v. ITMEDIA for alle interesserede 23/ E.5 Møde med ITMEDIA, KUA 4/ E.6 Møde med ITMEDIA, KUA 6/ iii

5 Figurer 1 MVC-klassediagram Tilstandsdiagram for elev Tilstandsdiagram for lærer Klassediagram Navigeringsdiagram for system lærer Interface - Classroom Editor Brugergrænseflade for en elev Brugergrænseflade - Øvelse Samarbejde og kommunikation Elev grænseflade Elev grænseflade - Open Exercise Elev grænseflade - Submit Answer Lærer grænseflade - Create Exercise Lærer grænseflade - Classroom Editor Lærer grænseflade - Add Student Lærer navigeringsdiagram Lærer navigeringsdiagram Login Skærm Velkomstskærm Brugergrænseflade for en elev Brugergrænseflade - Øvelse Brugergrænseflade - Optag Brugergrænseflade - Hide overview Brugergrænseflade - Change Brugergrænseflade - Change Navigeringsdiagram anden prototype iv

6 Ordliste Til at begynde med, vil jeg kort komme med en række grundbegreber, som jeg vil benytte mig af i opgaven. Grunden til at jeg nævner disse her, er for klart at definere, hvem/hvad jeg hentyder til, når jeg fremover benytter nedenstående begreber, samt at introducere begreber, som det ikke kan forventes, at læseren er bekendt med på forhånd. Kunden ITMEDIA, som er en underafdeling af Det Humanistiske Fakultet ved Københavns Universitet( ITMEDIA [12]). Systemet/programmet IT-systemet, som jeg, i samarbejde med min gruppe, har fremstillet under navnet BabeLLab. Sproglaboratorium Et undervisningslokale med arbejdsstationer beregnet til brug af sprogstuderende. Øvelseselement Et element der repræsenterer en side i en øvelse. Elementet kan indeholde alt fra lydafspillere, lydoptagere til helt almindelig tekst. 1 IT-projektet Jeg vil i dette afsnit forklare om IT-projektet, og hvad dette indebar af analyse og udvikling. 1.1 Oversigt Jeg vil her komme med en skematisk oversigt over projektforløbet. Dette vil jeg gøre i form af figur 1 på side 2. For at lægge ekstra vægt på brugerkontakt, har jeg valgt at beskrive disse i følgende, som også kan findes i figuren under samme nummerering: 1 Indledende møde med kunde. Her tog vi ud og mødte vores kunde for første gang. Se bilag E.1 for referat. 2 Møde m. bruger. En del af analysen af problemområdet. Her fik vi fortalt hvorledes det nuværende system fungerede og kom selv ud og prøvede systemet. Se bilag E.2 for referat. 3 Møde m. bruger. En del af analysen af anvendelsesområdet. Her mødtes vi med en bruger, som allerede anvendte et computerbaseret sproglaboratorium, men godt kunne tænke sig udvidet funktionalitet. Se bilag E.3 for referat. 4 Workshop. En del af analysen af anvendelsesområdet. Her lavede vi en workshop sammen med mulige brugere af vores system. Til denne udførte vi en såkaldt Affinity Diagramming (fra What is Affinity Diagramming? [8]). Se bilag E.4 for referat. 5 Møde m. kunde. Evaluering af papirsprototype. Her mødtes vi med vores kunde for at evaluere vores første prototype. Se bilag E.6 for referat og A for beskrivelse. 6 Møde m. bruger. Evaluering af den kørbare prototype. Her mødtes vi med en bruger for at evaluere vores anden prototype. Se bilag B for beskrivelse.

7 2 1 IT-PROJEKTET Brugerkontakt Analyse Design Prototyper Evaluering Analysedel Udviklingsdel Problemområde Anvendelsesområde 1. prototype 2. prototype 2Møde m. bruger 3Møde m. bruger 6Møde m. bruger 1Indledende møde m. kunde 4Workshop 5Møde m. kunde Analyse af problemområde Analyse af anvendelsesområde Design af komponenter Design af arkitektur Papirsprototype Kørbar prototype Papirsprototype Kørbar prototype Tid Figur 1: Oversigt over projektforløb. Alle tilfælde af brugerkontakt er yderligere uddybet på side 1.

8 1.2 Uddrag af problemområdet Uddrag af problemområdet Jeg vil her beskrive nogle af de centrale fænomener fra analysen af problemområdet: Aktørerne Elev og Lærer. De to brugertyper vi endte med at have med i vores system, var eleven og læreren. Vi valgte kun at have disse to med, da disse var de eneste der skulle interagere med vores system, og der således ikke var brug for f.eks. en administrator. Den eneste væsentlige forskel der er på en elev og en lærer, er at eleven har begrænsede muligheder i forhold til læreren. Dette afspejler sig i, at en lærer har adgang til at administrere hold af elever, fremstille nye øvelser, samt at rette elevers besvarelser, hvorimod en elev grundlæggende kun kan besvare øvelser. Objektet Øvelse. Det mest centrale fænomen fra vores problemområde viste sig at være en øvelse. En øvelse består i abstrakt forstand af en skal, som i princippet kan indeholde en vilkårlig mængde eller type af information, det være sig video, lyd, interaktive medier eller blot tekst. Sproglaboratorierne på Humanistisk Fakultet ved Københavns Universitet fungerer i øjeblikket kun med tekst og lyd, hvortil vi i vores projekt derfor har valgt at koncentrere os om disse, dog med senere mulig udvidelse af video og interaktive medier. En øvelse kan derfor bestå af tekst og lyd, som en elev kan besvare også enten i form af tekst eller lyd. Hændelsen Indtale besvarelse. Det sidste centrale fænomen fra vores problemområde er muligheden for at besvare en øvelse. En elev skal i form af tekst eller lyd kunne besvare en øvelse. Dette foregår ved at eleven efter afspilning af en fremmedsproget tekst, selv skal forsøge at udtale teksten. Dette forsøg optages i systemet, og eleven kan herefter vælge om han/hun vil gemme sit forsøg til senere rettelse af en lærer. 1.3 Anvendelsesområdet Jeg vil her komme ind på i hvilke situationer vores system skal anvendes. Vores system skal anvendes i tre forskellige områder. Det første område involverer både læreren og eleven, hvor de to andre vil være fokuseret på læreren hhv. eleven. Disse tre områder vil have nogle fælles egenskaber, men da de fysisk fungerer på vidt forskellige måde, vil jeg beskrive hver af disse seperat i følgende: Første anvendelsesområde - Sproglaboratorium Det første område er det sædvanlige sproglaboratorium miljø, der består af en eller flere lærere og en eller flere elever. Vores system kan i denne situation indgå på samme måde, som det er tilfældet i et oprindeligt sproglaboratoriumlokale. I dette tilfælde skal vores system tage over for båndoptagere og tekst i form af papir. Lærerne og eleverne behøver ikke nødvendigvis at være placeret i samme lokale, da vores system også er åbent overfor fjernlæring. Dette ses i form af, at der ikke nødvendigvis skal være fysisk kontakt mellem lærer og elev, men at denne kontakt blot kan ske via internettet. Den fysiske kontakt vil selvfølgelig fjerne nogle umiddelbare problemer, da eleven i så fald kan få hjælp direkte af læreren både til programmet og til øvelserne, men den er ikke nødvendig for at systemet fungerer.

9 4 1 IT-PROJEKTET Andet anvendelsesområde - Selvundervisning Det andet område vores system skal fungere i, er situationen, hvor en studerende besvarer en øvelse uden en lærer til at vejlede sig. Der er i dette område ikke noget krav om, at den studerende skal have internetforbindelse, da alt materiale blot kan gemmes lokalt til senere synkronisering med den centrale database. I denne forstand skal vores IT-løsning altså fungere som en offline-klient, der omtrent giver den studerende de samme muligheder, som en almindelig undervisningssituation vil give. I dette anvendelsesområde indgår læreren altså ikke Tredje anvendelsesområde - Administrering Det tredje problemområde omhandler situationen, hvor en lærer ønsker at fremstille øvelser til brug i undervisningssituationer. Her skal læreren have mulighed for at uploade lydfiler til den centrale database, lave øvelser, der kan tilgå databasen for at hente lydfiler, samt administrere disse øvelser. I dette anvendelsesområde indgår eleven altså ikke Brugsscenarier Her vil jeg beskrive to forskellige scenarier, som systemet bl.a. skal bruges til. Dette vil jeg gøre ud fra følgende tilstandsdiagrammer (se figur 2 og figur 3) og de efterfølgende forklaringer. Til tilstandsdiagrammerne skal det bemærkes, at lærer udover de viste mulighder også har samme muligheder som en elev. Disse har jeg dog ikke valgt at tage med i figur 3, da de lige så tydeligt kan ses ud fra figur 2. Endvidere skal det også bemærkes, at både en elev og en lærer til enhver tid kan vende tilbage til startskærmen, dog vil dette i de fleste tilfælde resultere i et tab af data. Figur 2: Tilstandsdiagram for elev.

10 1.4 Endelig model 5 Figur 3: Tilstandsdiagram for lærer. De to scenarier som jeg vil beskrive følger nu, hvor jeg vil gå ud fra, at læreren eller eleven har udgangspunkt ved startskærmen: Fremstille øvelse Når en lærer vælger at fremstille en øvelse, skal han/hun åbne et Ny øvelse -vindue. I dette vindue kan læreren tilføje eller fjerne såkaldte øvelseselementer, som vil blive repræsenteret i øvelsen som én side. Et øvelseselement kan indeholde både lyd og tekst, som læreren selv vælger. Læreren tilføjer nu de ønskede øvelseselementer og øvelsen gemmes, hvortil læreren bliver returneret til startskærmen. Besvare øvelse Når en elev ønsker at besvare en øvelse, skal elev først og fremmest åbne den ønskede øvelse. Herfra kan eleven bladre igennem øvelsens øvelseselementer, og give en besvarelse på hver enkelt af dem. Når eleven er tilfreds med sin besvarelse, kan han/hun vælge at afslutte øvelsen og aflevere sin besvarelse, som altså består af en besvarelse til hver enkelt øvelseselement i øvelsen, eller eleven kan vælge at gemme de svar han/hun har lavet og aflevere dem på et andet tidspunkt. Sidstnævnte mulighed er brugbar, hvis eleven ikke har tid eller lyst til at besvare samtlige øvelseselementer på det givne tidspunkt, hvortil eleven senere hen vil kunne genoptage besvarelsen af øvelsen. 1.4 Endelig model Her vil jeg beskrive den endelig model over IT-projektet. For at beskrive modellen, har jeg valgt at fremstille et klassediagram, der viser strukturen mellem klasserne i

11 6 1 IT-PROJEKTET det endelige system, som ses på figur 4. I denne model har jeg valgt at benytte mig af associaseringsstrukturen til at vise de indbyrdes relationer mellem klasserne. Endvidere har jeg benyttet aggregeringsstrukturen mellem en øvelse og dets øvelseselementer, en øvelse og en besvarelse, samt en delbesvarelse og en besvarelse. Grunden til at jeg har gjort dette er, at både et øvelseselement samt en besvarelse ikke kan eksistere uden at være tilknyttet én bestemt øvelse, da et øvelseselement er en del af en øvelse, og en besvarelse kan ses som en udvidelse af en øvelse. Endvidere kan en delbesvarelse heller ikke eksistere uafhængigt af en besvarelse. Øvelse-Øvelseselement -aggregeringen er af typen Helhed-Del, Øvelse-Besvarelse -aggregeringen er af typen Beholder-Indhold, og Besvarelse-Delbesvarelse er af typen Helhed-Del som defineret i Objektorienteret analyse & design [14, s. 77]. Til sidst har jeg valgt at beskrive en lærer og en elev som generaliseringer af en bruger. Dette har jeg gjort, da en lærer og en elev deler mange egenskaber, som derfor kan opsummeres i en abstrakt klasse, nemlig brugerklassen. Figur 4: Jeg vil nu beskrive de centrale fænomener, som jeg beskrev i sektion 1.2, ved følgende: Aktørerne Elev og Lærer. Disse to indgår som klasser i den endelige model, og er en generalisering af brugerklassen. En lærer er forbundet til en øvelse og en lydfil som forfatter af disse, og er forbundet til en klasse som underviser for denne. En elev er forbundet til en besvarelse som forfatter og til en klasse som medlem i klassen. Sidstnævnte relation vil normalt blive betragtet som en aggregering,

12 1.5 Brugergrænsefladen 7 men da en elev både kan eksistere uden at være tilmeldt en klasse, og kan være tilmeldt flere klasser på samme tid, vil aggregeringsstrukturen ikke virke her. Objektet Øvelse. En øvelse er forbundet til en klasse som lektie for klassens medlemmer. En øvelse har to andre klasser (øvelseselement og besvarelse), som er aggregeret op i klassen, som beskrevet tidligere. Hændelsen Indtale besvarelse. Denne hændelse er beskrevet ved klasserne Besvarelse, Øvelseselement og Øvelse. En elev opretter en besvarelse ved at oprette en række delbesvarelser til øvelseselementer og aflevere dem i en samlet besvarelse. 1.5 Brugergrænsefladen Jeg vil her komme med en række af eksempler på hvorledes brugergrænsefladen til vores system ser ud. Dyberegående forklaring af alle eksemplerne ses i figurteksten under den tilhørende figur. Før jeg kommer med konkrete skærmbilleder, vil jeg dog først vise et navigeringsdiagram for at vise hvorledes skærmbillederne hænger sammen. Dette følger i figur 5. Figur 5: Navigeringsdiagram for system. Dette diagram repræsenterer mulighederne i vores system. En lærer har adgang til alle mulighederne, mens en elev ikke har adgang til mulighederne omkranset med stiplede linier. Det første eksempel jeg vil komme ind på, er et uddrag fra vores første prototype. Den første prototype vi fremstillede, var en papirsprototype, og uddraget som jeg har valgt, ses på figur 6. Uddraget omhandler klasseeditoren, som er yderst vigtig for en lærer, da det bl.a. er her en lærer kan tilgå sine klasser og give eleverne lektier for. Grunden til, at jeg har valgt dette eksempel, er at udover at lave øvelser, er det her læreren vil komme til at bruge mest tid i vores system.

13 8 1 IT-PROJEKTET Figur 6: Dette vindue repræsenterer klasseeditoren, hvor en lærer kan administrere sin klasser. I dette kan læreren se sine aktuelle klasser, og ved at trykke på New Class -knappen kan læreren oprette en ny klasse. Ved at markere en bestemt klasse kan læreren se klassen elever til højre. Herfra kan læreren fjerne eller tilføje en eller flere elever ved knapperne Remove From Class og Add Student(s) To Class. Figur 7: Ovenstående vindue er brugergrænsefladen for en elev. I venstre side har eleven et overblik og sine klasser og øvelser. Eleven kan herfra vælge at åbne en øvelse eller navigere rundt i den træbaserede menu, samt se en velkomstbesked i højre side.

14 1.6 Programdokumentation 9 Resten af eksemplerne på brugergrænsefladen er fra vores anden prototype, som er en kørbar Java-prototype. Det første eksempel jeg vil komme ind på, er startskærmen for en elev, som ses på figur 7, hvorfra en elev kan benytte alle de funktionaliteter, som vores system giver ham/hende adgang til. Jeg har valgt at tage dette med her, da det er væsentligt at vise, hvorledes systemet åbnes op for brugeren for at give et helhedsindtryk af systemets udseende. Figur 8: Ovenstående vindue repræsenterer, at en elev har åbnet en øvelse fra menuen til venstre i vinduet. Eleven kan herfra vælge at afspille lydøvelsen med Play -knappen eller indspille sin egen lyd med Record -knappen. Til sidst kan eleven vælge at bladre mellem øvelsens sider ved at benytte Next - og Previous -knapperne i bunden af skærmen, og trykke submit for at aflevere sin besvarelse. Det sidste eksempel jeg vil komme ind på, er øvelsesvinduet, som ses på figur 8. Dette er den mest centrale del for en elev, da det er her eleven læser og lytter til øvelser, og giver sin besvarelse. Det er dette vindue, som vil være det en elev vil bruge langt størstedelen af sin tid på under brugen af vores system, hvilket er grunden til at jeg har taget det med her. 1.6 Programdokumentation Jeg har valgt at beskrive, hvilke Java-klasser i vores program der svarer til klasserne i analysedelen som programdokumentation. Derudover kan resten af klasserne og deres sammenhæng ses i et udsnit af vores Javadoc, som jeg har vedlagt i bilag D. Det skal her bemærkes, at alle klasserne overført fra analysedelen er placeret i pakken database, hvor de fungerer som en indre struktur for systemet. Udover denne pakke, er der pakkerne control, som indeholder opstartsklasserne, view, som indeholder grænsefladen, exceptions, som indeholder undtagelser og makedatabases, som indeholder funktionaliteten til at skrive til og fra databaser. Klasserne overført fra analysedelen er som følger:

15 10 1 IT-PROJEKTET Exercise Svarer til øvelsesklassen. ExElement Svarer til øvelseselementklassen. Group Svarer til klasseklassen. Solution Svarer til besvarelsesklassen. Teacher Svarer til lærerklassen. Student Svarer til elevklassen. User Svarer til den abstrakte brugerklasse. En udførbar udgave af programmet, samt hele javadoc en kan hentes på denne url 1. Zip-filen skal udpakkes og herefter kan BabelLap.jar åbnes for at åbne systemet. Systemet er testet til at køre på Windows Vista, Windows XP og Ubuntu alle med den nyeste opdatering af Java. Javadoc en er at finde i mappen javadoc, og kan åbnes via filen index.html. 1.7 Uddrag af implementationen Delopgaven som jeg har udvalgt, omhandler hvorledes vi kunne oprette forbindelse til vores server via vores system uden at brugeren blev involveret rent teknisk, samt hvorledes vi vil kunne sørge for at data i databasen på serveren er konsistent. Da vores system er afhængigt af, at alt data kan hentes og gemmes på serveren, er dette en vital opgave for at systemet kommer til at virke. Dette er en relativ vanskelig opgave via Java, og da ingen af os i gruppen havde erfaring med dette, synes jeg at denne opgave både var udfordrende og interessant. Selve problemet bestod altså i at skrive en klasse, som både kunne varetage forbindelsen til serveren, men samtidig også holde styr på de relevante SQL-kald til databasen på serveren. Måden vi løste dette problem på, var ved at skrive en klasse kaldet Online_db_mod (Se bilag C.1). Når en instans af denne klasse bliver oprettet, vil vores system forsøge at oprette forbindelse til serveren via Java-pakken com.mysql.jdbc.driver som kan hentes fra (se [6]). Ved at indlæse denne pakke kan vi nu oprette en sikker forbindelse til serveren, og endvidere kan vi også via denne pakke kalde præcis de SQL-kald som vi ønsker til serveren. Det eneste problem der nu manglede, er hvorledes vi kunne holde data på serveren konsistent. Med konsistent mener jeg her, hvorledes vi kan sørge for f.eks. at en lærer ikke modificerer en øvelse samtidig med, at en elev henter denne øvelse. I dette tilfælde og lignende kan vi altså risikere, at elever og lærere ikke ser samme indhold i systemet. Måden vi løste dette på, var ved at benytte os af transaktioner og ved at holde forbindelsen til serveren på et minimum. For at holde forbindelsen til serveren i så kort tid som muligt, har vi lavet en funktion i klassen Online_db_mod, som sørger for at afbryde forbindelsen. Denne funktion kan man nu kalde, lige så snart man har kaldt de ønskede SQL-kald. Samtidig kan vi ved at benytte transaktioner sørge for, at kun én klient har adgang til serveren ad gangen, hvortil vi undgår inkonsistens. Der er dog en enkelt hage ved denne metode, nemlig såkaldt lag forbundet ved transaktioner. Men da vi kun benytter forbindelsen til simple SQL-kald, og disse er yderst hurtige, er dette ikke et problem, som brugerne af systemet vil lægge mærke til. 1 Hvis denne imod forventning skulle være nede kan Java_Prototype.html alternativt benyttes.

16 11 2 Om samarbejdet Jeg vil i dette afsnit komme ind på samarbejdet mellem de berørte parter i udviklingsprocessen bag systemet, samt det indbyrdes forhold i vores gruppe som systemudviklere. 2.1 Forholdet udadtil I forbindelse med vores projekt har der været tre parter involveret: Vores kunde, brugere og os selv i gruppen som udviklere. Kommunikationen der har foregået mellem de tre parter i løbet af projektet illustreres på figur 9. De to sorte pile illustrerer den primære faktiske kommunikation, mens den grå pil illustrerer kommunikation, der måske burde have foregået eller kun foregik i mindre grad, men dette vil jeg komme ind på senere. Jeg vil først beskrive forholdet mellem kunden og os som udviklere og derefter forholdet mellem brugerne og os som udviklere. Til sidste vil jeg runde af med fortælle, hvorledes kommunikationsprocesserne i fællesskab havde fungeret, hvis der havde været en højere grad af kommunikation mellem kunde og brugere. Figur 9: Samarbejde og kommunikation Vi har i løbet af vores projekt både mødt vores kunde fysisk samt kommunikeret med kunden via . kommunikationen er kun foregået ved mindre spørgsmål, som vi skulle have afklaret samt planlægning af møder og forløb. Dette har gjort, at kunden har kunnet følge med i alle faser af udviklingsforløbet, uden at vi har måtte mødes unødigt ofte. Den fysiske kontakt mellem kunden og os er foregået ved møder, hvor vi primært har talt, om hvad kunden ønskede af produktet. I løbet af disse møder er der særligt et enkelt emne der springer ud, og bortset fra dette har vores kunde ikke blandet sig i vores udviklingsproces, medmindre vi har taget kontakt til dem. Dette anser vi som værende positivt, da vi så har kunnet koncentrere os fuldstændig om det analytiske arbejde og udviklingsprocessen bag systemet. Jeg vil nu forklare om emnet, der særligt sprang ud: Under workshoppen (som nævnt på side 1) som vi holdte med brugerne, fortalte en af brugerne, at han benyttede sig af en webbaseret løsning (kaldet Moodle [16]), der næsten opfyldte vores kundes ønske. Da vores kunde ønskede at være til stede ved denne workshop, både for at hjælpe os med projektet, og for at møde et lille udvalg af de mulige brugere, blev kunden her klar over denne løsning fandtes. Vores kunde ønskede herefter, at vi skulle lave en Java-baseret løsning, så brugere kunne benytte Moodle s funktionaliteter, men ikke behøvede at have en webbrowser åben, som er kravet ved Moodle. Dette krævede at vi både lavede en PHP-del samt en Java-del, og til gengæld

17 12 2 OM SAMARBEJDET ville vi så slippe for at skulle arbejde med databasedesign. Vi begyndte herefter så småt i udviklingsgruppen at sætte os ind i Moodle s opbygning og kildekode. Vores kunde fandt dog senere hen ud af i samarbejde med os i udviklingsgruppen, at de alligevel ikke ønskede, at vi skulle benytte os af Moodle. Dette resulterede i, at vi herefter skulle skifte fra at arbejde med PHP og Java til nu at arbejde med SQL og Java. Grunden til dette ønske var, både af hensyn til os som udviklere, og vi dermed ikke behøvede at koncentrere os om at få PHP og Java til at arbejde sammen, men også af hensyn til dem selv, da det omkostningsmæssigt er langt sværere at få en Moodle-server op at køre end en SQL-server. Til gengæld måtte vi nu selv sørge for at sætte databasen på serveren op. Om dette skifte har resulteret i mere eller mindre arbejde for os som udviklere er svært at sige, da vi ikke nåede at planlægge vores udviklingsarbejde i første omgang før skiftet, men vi har i hvert fald brugt unødigt meget tid på at sætte os ind i Moodle s opbygning. Man kan så diskutere om vi har fået noget ud af at undersøge Moodle s system rent analytisk, men dette mener jeg ikke er relevant at tage op her. Vi har igennem IT-projektet også mødtes med en række brugere, hvor vi primært har valgt at koncentrere os om at interviewe lærere, da vi mener, at lærere har mere at bidrage med i modsætning til elever til vores system i udviklingsfasen. Dette ses bl.a. i at en stor del af vores system er direkte henvendt til lærerne og ikke eleverne. Disse møder har foregået i diverse sproglaboratorier tilhørende Humanistisk Fakultet ved Købehavns Universitet, hvor vi har på førstehånd har kunnet erfare, hvorledes sproglaboratorier virker og er bygget op. Vi har mødtes med mange forskellige brugere i løbet af projektet. Da disse brugere indbyrdes har været forskellige, vil jeg forsøge at beskrive forholdet til vores brugere ved at trække på fælles egenskaber blandt brugerne. Grundlæggende har brugerne været meget interesserede i vores projekt, da nye ITløsninger ofte har et positivt klang over sig, og vores system specielt vil komme dem til stor gavn i undervisningen. Dette gjorde det selvfølgelig langt nemmere for os i udviklingsgruppen via interviews at få interessante detaljer med både i analysedelen samt udviklingsdelen, da brugerne da var langt mere engagerede i at vores projekt skulle lykkes. I løbet af projektet sørgede vi for kun at mødes med én bruger ad gangen, da vi på denne måde kunne koncentrere os fuldt om, hvad den enkelte bruger havde at sige til projektet. Det eneste tidspunkt vi mødtes med flere bruger på en gang var ved vores workshop. Ved denne workshop fremgik det tydeligt, at brugerne ikke var klar over hvad de i fællesskab ønskede sig af vores projekt. De havde hver især en given undervisningsmetode, som de gerne vil have trumfet igennem i vores system. Dette afspejler sig i, at mange af vores potentielle brugere før vores workshop ikke havde mødt hinanden til trods for, at de alle var ivrige brugere af sproglaboratorier på Humanistisk Fakultet. Det var derfor op til os som udviklere at samle brugernes ønsker til et fælles sæt af ønsker, som derfor blev målet med workshoppen. Til sidst vil jeg som sagt runde af med at fortælle lidt om, hvordan det fælles forhold kunne have fungeret bedre. Hvis der havde været en større grad af kommunikation mellem kunde og brugere, havde vi som udviklere ikke behøvet at bruge tid på at opsøge brugerne selv, og kunden havde ydermere også haft lang større indflydelse på projektets forløb. Endvidere havde kunden også i fællesskab med brugerne kunne sætte en kravsspecifikation op til os, før vi overhovedet gik i gang med projeket. Dette havde gjort, at vi ikke havde haft brug for at lave den samme mængde undersøgelser før udviklings-

18 2.2 Forholdet indbyrdes i gruppen 13 processen, samt at brugerne havde haft en bedre fornemmelse af hvad projektet i sidste ende ville komme til at omhandle. Til gengæld var det på denne måde ikke sikkert, at vi ville ende op med et produkt af samme kvalitet, da vores kravsspecifikation jo har været igennem en analytisk proces, som man ikke kan forvente af kunden og brugerne i fællesskab. Ligeledes kan det heller ikke forventes af kunden, at de har gjort denne slags forarbejde inden de sætter projektet igang. Alt i alt ville vi både før og under projektet have haft stor gavn af, at kunden havde taget initiativ til at tage kontakt med brugerne, da dette ville have taget noget arbejdsbyrden fra os. Dog hører denne arbejdsbyrde ofte også med til et IT-projekt, så det er ikke noget vi kunne forvente af vores kunde, men hvis kunden havde ønsket mere indflydelse i projektforløbet, var dette klart vejen at gå. 2.2 Forholdet indbyrdes i gruppen Det indbyrdes forhold i gruppen er meget karakteriseret ved, at vi alle havde meget forskellige kvalifikationer samt arbejdesmetoder. For ikke at hænge nogen ud her i opgaven, vil jeg ikke beskrive specifikke personer, men snarere beskrive personernes egenskaber som en del af fællesskabet i gruppen. Generelt var vi som sagt meget forskellige individer, som resulterede i at vi påtog os forskellige roller under forløbet. Nogle var gode til at beskrive ting analytisk, mens andre var bedre til den tekniske del af projektet. Denne rollefordeling skete i løbet af projektet, og alle medlemmer faldt automatisk ind i den rolle de var bedst til. Dette havde både positive og negative sider. På den positive side resulterede dette i, at dem der lavede tingene også var de bedste til det, mens det på den negative side resulterede i, at alle ikke fik lov at være med hele vejen rundt i alle de aspekter af projektet de ønskede. Endvidere er en negativ konsekvens af dette også, at projektet manglede en klart defineret leder, der kunne holde overblik og fortælle alle hvad de skulle lave. I stedet lavede folk bare det de var bedst til, hvortil nogle områder måske blev forsømt på tidspunkter de ikke burde. Med hensyn til planlægning af forløbet, gjorde vi allerede i begyndelsen af projektet meget ud af at lave en dagsorden for hvert møde, vi havde internt i gruppen. Dette gjorde vi bl.a. for at sikre, at vi nåede de tidsfrister der var sat for os, samt at få overblik over opgaverne der skulle laves. Dagsordnerne blev lavet i et fælles medium ( Google Docs [10]), så alle kunne være med til at planlægge. Disse dagsordner brugte vi senere i projektforløbet til at uddelegere arbejdsopgaver, ved at folk kunne skrive sig på en ting, der skulle laves ved næste møde. Nogle medlemmer havde i løbet af projektet svært ved at holde sig til tidsplanen mht. mødetider og var svære at kommunikere med. Dette skabte en smule splid i begyndelsen, da nogle medlemmer så pådrog sig flere arbejdsbyrder end andre til visse tider, for at være sikker på at tingene blev lavet. Vi erkendte at dette var et problem, og vi fik afhjulpet dette under selve udviklingsfasen ved at indføre en ny arbejdsmetode, hvor vi benyttede en CVS-server til at arbejde sammen over (mht. programmering). Dette gjorde at vi ikke i samme grad behøvedes at mødes, for at det gik fremad med projektet, samtidig med at arbejdsbyrden blev nogenlunde ligeligt fordelt, da man så kunne følge med i at andre fik lavet de uddelegerede opgaver. Når nøgleopgaver under forløbet ikke blev løst tilfredsstillende, forsøgte andre at tage over for at opgaven blev løst indenfor tidsrammen. Bagefter diskuterede vi så i fælles-

19 14 3 REFLEKSION OVER RESULTAT OG FORLØB skab hvorledes vi kunne undgå disse, og om det var et resultat af forkert uddelegering af opgaver. Et konkret eksempel på dette, er review-opgaverne vi fik stillet i forbindelse med at skulle aflevere rapporter. Her var det ikke altid at disse blev prioriteret højst af medlemmerne, der havde fået dem uddelegeret, og andre måtte derfor i sidste ende træde til og hjælpe med at få strikket et review sammen. Denne arbejdsmetode er ikke holdbar i længden, men da projektet strakte sig over et relativt kort forløb, og metoden til dels var et resultat af de indlagte tidsrammer, føler jeg at denne metode var den rigtige at anvende i den givne situation. 3 Refleksion over resultat og forløb Jeg vil i dette afsnit reflektere over resultatet og forløbet af IT-projektet. Til dette vil jeg først komme ind på nogle af de styrker og svagheder, der var omkring planlægningen af projektforløbet, samt samspillet mellem de forskellige projektaktiviteter. 3.1 Styrker og svagheder samt samspil mellem projektaktiviteterne En af de væsentligste styrker ved de tidlige aktiviter i projektforløbet, nemlig analysedelen, var at den gav os en solid bund både teoretisk men også analytisk i forhold til projektet vi kastede os ud i. Analysen gjorde os i stand til at påbegynde modelleringen af systemet, inden vi overhovedet havde nået at komme til enighed om et fælles programmeringssprog, hvilket endvidere sørgede for, at vi fik tænkt systemet igennem før vi nåede til at konkretisere det. Endvidere sørgede planlægningen af projektforløbet også, at vi under hele forløbet havde overblik over de ting vi havde nået, og stadig skulle nå. Ydermere virkede de indlagte deadlines meget positivt, da forløbet således blev splittet op i mindre overskuelige dele, i stedet for at alting skulle laves til en fælles deadline til sidst i forløbet. Dette kan sammenlignes lidt med Extreme Programming [11], hvor man tilstræber mange små releases og altså dermed mange små deadlines. Igennem projektforløbet kan man sige, at vi fulgte en noget forsimplet udgave af spiral modellen A spiral model of software development and enhancement [4], hvor vi nåede at fremstille og evaluere to prototyper. Vores udgave af modellen var forsimplet, da vi således kun nåede igennem to iterationer, og ikke havde risiko analyser med i vores spiral, som de er påtænkt i modellen, dog benyttede vi os samtidig også af de sædvanlige OOAD-aktiviteter, såsom analyse og design, som vi fik indopereret i de tidlige stadier af spiralen. En ulempe ved ikke at følge spiralmodellen i denne forsimplede udgave var, at vi ikke nåede særlig mange iterationer, hvilket netop er styrken ved spiralmodellen. Vores planlægning var derimod fokuseret på at grundlaget skulle være sikret, før vi overhovedet gik igang med de iterative udviklingsfaser. På denne måde kan man sige at vi lagde os tæt op af vandfaldsmodellen A spiral model of software development and enhancement [4] i begyndelsen, og senere hen skiftede til spiralmodellen. Vi nåede dertil altså ikke at få særlig mange forbedringer ud af vores prototypeevalueringer, men opnåede dog alligevel en indsigt i styrken af disse. En svaghed ved projektforløbet var den manglende projektetablering i begyndelsen. Her kunne jeg godt have ønsket, at rollerne blandt gruppemedlemmerne var mere fastlagte,

20 3.1 Styrker og svagheder samt samspil mellem projektaktiviteterne 15 og jeg kunne godt have ønsket en leder, som kunne holde overblik og fortælle hvad de forskellige medlemmer skulle arbejde med i de forskellige faser. Med hensyn til samspillet mellem systemaktiviteterne, kan man sige at analysen grundlagde klasserne for design af modelkomponenten samt selve implementationen. Den gav overblik, over hvilke fokusområder der var nødvendige, og hvilke funktionaliteter der var påkrævede, hvilket hjalp til at mindske byrden under selve designfasen, da vi så ikke behøvede at analysere og designe samtidig. Selve designfasen gav indblik i hvor arbejdsfokus skulle lægges under de efterfølgende aktiviteter, dog kunne jeg godt have ønsket at denne fase lå tidligere. I vores forløb (jvf. afsnit 1.1), lå denne fase oveni udviklingen af den første prototype, hvilket trak fokus væk fra vigtigheden af at designe en god model og arkitektur til systemet, som det er tilskyndet i What is Software Architecture? [3]. Endvidere trak implementationsfasen også meget på designfasen, og da disse to faser noget af tiden overlappede, blev designet i visse tilfældet lavet ad hoc til løsninger i implementationen. Dette er ikke positivt, da vi i så fald kommer til at trække på sprogspecifikke løsninger, i stedet for løsninger som virker uafhængigt af implementationen, som det er tilfældet i Programming as theory building [15]. I takt med at vi fik udviklet vores prototyper, erfarede vi, at væsentlige dele af vores model måtte omstruktureres. Dette indebar bl.a. muligheden om en superlærer med specielle rettigheder i vores system, som dog viste sig unødvendig under evaluering af den anden prototype (se bilag B). På denne måde fik evalueringsprocessen væsentlig indflydelse på designfasen, som derved resulterede i den tidligere nævnte spiral model, som vi fulgte. Selve dokumentationen af projektet, og her tænker jeg analyse- og designdokumenter, hjalp medlemmerne til at holde fælles overblik og arbejde sammen. Disse gjorde at vi konkret kunne diskutere og designe løsninger i fællesskab, hvortil flere perspektiver blev vendt, end hvis et enkelt medlem f.eks. havde stået for designfasen. Endvidere forsøgte vi også i høj grad at dokumentere implementationen, her i form af Javadoc, så andre gruppemedlemmer nemt kunne sætte sig ind i specifikke programmeringsmetoder et bestemt gruppemedlem havde foretaget sig. Dette gjorde det f.eks. muligt for en udvikler at benytte sig af en anden udviklers klasser og funktioner uden at sætte sig ind i selve programmeringen af denne klasse. Med hensyn til kommunikation og samarbejde blev disse to aktiviteter væsentligt forbedret efter vi fik oprettet en fælles CVS-server (Concurrent Versions System), som det også er nævnt i afsnit 2.2. Før oprettelsen af CVS-serveren benyttede vi i langt større grad dagbogsformen, som den er beskrevet i Back to thinking mode: diaries for the management of information systems development projects [13], til at samarbejde og kommunikere igennem. I [13] er kommunikation igennem dagbøger ikke et emne, men da vores dagbøger blev lavet i et fælles medie ( Google Docs [10]), følte vi, at vi på denne måde nemt kunne strukturere kommunikationen samt holde styr på, hvad der var blevet aftalt mellem de forskellige medlemmer. Til sidst fungerede samarbejdet ofte som en slags mini-scrum, hvor ordet scrum er som defineret i Extreme Programming [11]. I stedet for den oprindelige definition af scrum, som består af en gruppe af udviklere, benyttede vi os ofte af muligheden for at planlægge i fællesskab, uddelegere opgaver og efter disse er fuldført, planlægge nye opgaver. På denne måde kan man opfatte medlemmerne i min gruppe som mini-

21 16 3 REFLEKSION OVER RESULTAT OG FORLØB scrums, som altså fungerede på samme måde som scrums i Extreme Programming [11]. 3.2 Forbedringer For at vores projekt ville være forløbet mere optimalt, er der en række forbedringer, som man i et tilsvarende forløb med fordel kunne inkludere. En af disse er en klar projektetableringsfase i begyndelsen af forløbet, som det er nævnt i Professionel Systemudvikling [1]. I denne fase kunne man undersøge hinandens styrker og svagheder, og ud fra dette kunne man opsætte nogle roller som skulle holde igennem projektet. Endvidere kunne man også udnævne en ansvarlig, som havde til opgave at holde overblik over processen og lede de fælles møder i gruppen. Til sidstnævnte tænker jeg en form for scrumleder, som det er nævnt i Extreme Programming [11]. Herudover kunne man også forsøge at gøre designfasen mere uafhængig og ikke lave den samtidig med udviklingen af prototyper, da den så ofte bliver til ad hoc løsninger. Udviklerne bør derfor tilstræbe at gøre som i Programming as theory building [15], hvor designløsningerne er uafhængige af implementeringen af disse. Strukturen af kommunikationen, som vi foretog via Google Docs [10], kunne forbedres på mange måder. Nogle af disse kunne være at sikre at data ikke forsvandt, hvis f.eks. et medlem kom til at fjerne noget fra et dokument, som ikke skulle have været fjernet. Mens andre kunne være at gå over til en anden kommunikationsstruktur, hvor man oprettede en forum-lignende struktur, hvor man kunne oprette indlæg under forskellige emner, og disse indlæg bliver gemt i en fælles database. På denne måde kunne man strukturere samtalerne mellem medlemmerne, og hermed sørge for at holde irrelevant information væk fra vigtige emner. Dette ville også gøre, at medlemmerne bedre ville kunne holde overblik over hvilke områder, der mangler arbejdsfokus på. Metoden jeg derfor ville foreslå, ville være en blanding af dagbøger, som foreslået i Back to thinking mode: diaries for the management of information systems development projects [13], og et fælles forum for diskussion af vigtige emner vedrørende de forskellige udviklingsfaser. Endvidere oplevede vi også situationer, hvor programdokumentationen ikke levede op til den standard den burde. Dette skabte komplikationer og spildt tid i forbindelse med implementeringen, hvortil en klar forbedring var, at alle lavede klar og tydelig dokumentation i programmeringsfasen (i vores tilfælde Javadoc) på en fælles måde. Til sidst kunne en forbedring være at gennemløbe flere iterationer i forbindelse med prototype- og evalueringsfaserne, som det ses i A spiral model of software development and enhancement [4]. Disse gav tydelige resultater, og forbedrede på mange måde systemet, hvortil en forøgelse af disse ville være med til at give et langt bedre slutresultat. Dog skal mængden af iterationer ikke påvirke de andre udviklingsfaser negativt, så de skal selvfølgelig gøres med måde. Betingelserne for at disse forbedringer kan opsættes som retningslinier for et andet systemudviklingsprojekt, er at der er ordentlig tid til den analytiske del, hvilket kræver, at den udenforstående ledelse af projektet har tillid til udviklerne, da der ikke kommer nogle konkrete resultater i denne fase. Endvidere kræver det også, at der er tid nok til at et passende antal iterationer af prototyper og evaluering kan foregå for at opnå det bedst mulige resultat. En udenforstående ledelse kunne sagtens kræve at få udleveret en aktuel prototype som slutprodukt, hvor der måske i virkeligheden var brug for flere iterationer til trods for at produktet vir-

22 17 ker færdigt. Dette kræver selvfølgelig at den udenforstående ledelse igen har tiltro til udviklerne. Til sidst kræver den gode analytiske bund før selve udviklingsprocessen påbegyndes, at problemområdet og anvendelsesområdet ikke er uoverskueligt stort, da analysedelen i så fald vil blive en kæmpe opgave, og resten af faserne kan komme til at bukke under for denne. 4 Diskussion af udvalgt artikel Jeg vil i dette afsnit diskutere den udleverede artikel The M.A.D. Experience: Multiperspective Application Development in evolutionary prototyping [19], som jeg fremover vil betegne M.A.D. 4.1 Tilgang til systemudvikling og erfaringer Jeg vil her kort på punktform beskrive de tilgange, som udviklerne i artiklen har anvendt til systemudvikling: Hurtig, evolutionær udvikling af prototyper s. 9 En metode, hvor man så hurtigt som muligt udvikler nye prototyper og evaluerer disse, og herefter gentager processen med de nye betragtninger i forbehold. Samarbejdsdesign (Cooperative design) s. 12 En udviklingsmetode, hvor brugerne bliver taget med i både designfasen samt udviklingen af brugergrænseflader, for at opnå et bedre resultat, der er mere i stil med det brugerne ønsker. UML s. 20 En metode til at fremstille modellen i form af klasser og sammenhænge mellem disse. De benytter sig bl.a. af UML-begreber som aggregering, nedarvning og associasering. Model-View-Control lignede model s. 25 En metode, som minder om Model- View-Control -metoden (se Objektorienteret analyse & design [14, s. 186] (OO- AD)), som der bl.a. gives udtryk for i følgende: (...) to achieve independence between the user interface, the model and functionality layer. [19, s. 25] Parallel modellering, design og udvikling af prototyper s. 28 En proces, hvor modellering, design og udvikling af prototyper foregår parallelt i modsætning til sekventielt. Multiperspektivitet s. 29 En metode, hvor udviklingsgruppen ikke kun består af OO-udviklere med også f.eks. etnografer o. lign. 4.2 Ligheder og forskelle mellem artikel og kursuslitteratur I dette afsnit vil jeg komme ind på forskellene mellem metoder brugt i artiklen og metoderne fra kursuslitteraturen og diskutere disse. Måden jeg vil gøre dette på, er ved at diskutere tilgangene i samme rækkefølge, som de fremgår i afsnit 4.1. Dog vil jeg kort først komme ind på hvorledes opbygningen af projeket i M.A.D kan sammenlignes med kursuslitteraturen.

23 18 4 DISKUSSION AF UDVALGT ARTIKEL Selve projektetableringsfasen, som det fremgår af Professionel Systemudvikling [1], er ikke så tydelig i M.A.D. Dog bruger de relativt meget tid i artiklen på at forklare hvad de forskellige medlemmer af udviklingsgruppen havde af roller. På denne måde kan man sige, at der i forbindelse med M.A.D -projektet blev gennemgået en projektetableringsfase, men at den blev afviklet af højere instanser, som havde til ansvar at sætte udviklingsgruppen sammen, og ikke af selve udviklingsgruppen som det er tilfældet i Professionel Systemudvikling [1]. Den hurtige og evolutionære udvikling af prototyper ses mange forskellige steder i kursuslitteraturen. Selve metoden står i stærk kontrast til OOAD-metoden, hvor det er vigtigt, at analysen af problemområdet og anvendelsesområdet, samt andre udviklingsfaser såsom design og modellering, bliver gennemført før udviklingen af prototyper. Selve metoden minder lidt om spiralmodellen fra A spiral model of software development and enhancement [4], hvor udviklingsprocessen foregår som en iterativ proces koncentreret om udviklingen af prototyper og evalueringen af disse. På samme måde er den evolutionære udvikling af prototyper i M.A.D fokuseret på, at evalueringen af en prototype hele tiden er med til at skabe og forme den næste prototype, og på denne måde opnår man en evolutionær proces, hvor resultatet hele tiden er en bedre og bedre prototype kun med de nødvendige funktionaliteter. Metoden bliver også beskrevet i No silver bullet [5, s. 180], som et middel til at fastlægge systemets krav. Dette er er også tilfælde i M.A.D, som bl.a. ses ved [19, s. 14], hvor artiklens forfattere beskriver en iterationsproces. I denne proces fremviste de en prototype overfor en række potentielle brugere, som resulterede i en evaluering af prototypen. Ud fra resultatet af denne evaluering kunne udviklerne hurtigt implementere de nye idéer og fjerne ubrugelige idéer, alt sammen indenfor en tidsgrænse på få dage. Således er systemets krav ikke fastlagt fra begyndelsen, men bliver formet alt afhængigt af hvor evalueringerne af prototyperne trækker systemet hen. Til sidste bliver den hurtige, evolutionære proces også beskrevet i fænomenet Extreme Programming [11] (XP), dog ikke direkte. I XP er en af de grundlæggende metoder at have mindre releases af prototyper og en løbende integration af funktionaliteter, som disse prototyper giver anledning til. Dette stemmer fint overens med metoden i M.A.D, hvortil man kan argumentere for, at metoden brugt i M.A.D er en blanding af OOAD og XP. Samarbejdsdesignprocessen foregår som sagt, ved at brugere og kunden er til stede i designfasen og udviklingen af brugergrænsefladen. Dette ses især i XP, hvor en anden af de grundlæggende metoder er, at man i høj grad ønsker at kunden er til stede i forbindelse med udviklingen af systemet. Dette forhindrer mange misforståelser, som kunne opstå, hvis udviklerne har fejltoklet nogle grundlæggende hændelser i problemområdet, og ligeledes vil dette også øge effektiviteten i udviklingsprocessen, da alle spørgsmål kan stilles direkte verbalt til kunden, og ikke skal igennem andre mere tidskrævende kommunikationsprocesser. I M.A.D benytter de sig også af UML til at beskrive deres model, som også er beskrevet i kursuslitteraturen ved Objektorienteret analyse & design [14, s. 324]. De beskriver selv, at de ønsker at begrænse brugen af avanceret UML, da deres model i høj grad skal kunne fortolkes tilbage til mere almindeligt menneskesprog, så udviklerne kan trække på erfaringer fra folk uden forstand på det objektorienterede paradigme. De benytter sig dog af nogle generelle UML-begreber som aggregering, associasering og

24 4.2 Ligheder og forskelle mellem artikel og kursuslitteratur 19 nedarvning, som også ses i kursuslitteraturen ved Objektorienteret analyse & design [14, Kap. 4]. Endvidere benytter de i M.A.D modellen, som ofte er beskrevet ved hjælp af UML, til at opbygge deres softwarearkitektur. I What is Software Architecture? [3] beskriver forfatterne hvorfor det er vigtigt at have softwarearkitektur med fra begyndelsen af et projekt, samt hvad arkitekturen kan gøre for udviklingsprocessen. I M.A.D benytter de sig af netop denne tilgang. De begyndte et konkret sted, og lavede ud fra dette arkitekturen ved brug af UML på blackboards, for at konkretisere udviklingsprocessen. På denne måde opnår de en let tilgang til både at forklare udenforstående hvad konkrete dele af projektet går ud på, samt internt at holde overblik over hvor i processen de er nået til. Model-View-Control-metoden Objektorienteret analyse & design [14, s. 186] består i at opdele selve arkitekturen af deres system i tre næsten uafhængige dele, nemlig modellen, brugergrænsefladen og funktionaliteten. Dette forsøger udviklerne i M.A.D også at gøre, som det ses i citatet i afsnit 4.1. De beskriver i M.A.D, hvorledes de måtte sætte meget tid af til udvikle denne uafhængighed, men at den så også gjorde dem i stand til at udvikle hver af delene hurtigere, da komplekse sammenhænge mellem f.eks. modellen og funktionaliteten så ikke behøvedes at blive taget med i betragtning. Den parallelle udvikling af modellering, design og udvikling af prototyper ses ikke i kursuslitteraturen. Denne er i direkte modstrid med den sædvanlige OOAD-metode, som det også er argumenteret for i den hurtige udvikling af prototyper. Denne metode spiller derfor også godt sammen med den hurtige metode, da disse langt fra udelukker hinanden. Endvidere er metoden også i modstrid med vandfaldsmetoden, som beskrevet i A spiral model of software development and enhancement [4], da denne påkræver at det forrige led i en kæde er fuldført og valideret før det næste led i kæden kan påbegyndes. I den parallelle metode udvikles model, design og prototype simultant og er således ikke bundet af hinanden. Dette kan både have positive og negative aspekter. De positive aspekter består i, at processen ikke forsinkes af en stor kompleks model der skal udvikles før man kan gå igang med at designe løsninger til systemet. Dette kræver selvfølgelig en hvis form for brug af scrums som nævnt i Scrum and CMMI Level 5: The Magic Potion for Code Warriors [18], som kan klare hver udviklingsdel for sig selv. De negative aspekter består derimod i, at den naturlige følge af processer i OOAD er ødelagt, hvortil forrige faser, såsom modellering og design, ikke får den retmæssige indflydelse på senere faser, såsom udvikling af prototyper. Dette er et problem, hvis man følger vandfaldsmodellen, men ikke så meget hvis man følger spiralmodellen. I spiralmodellen vil konsekvenserne af modelleringen og designfasen slå igennem i den efterfølgende iteration, og selve problematikken bag ved det at udvikle model, design og prototyper simultant vil forsvinde. I M.A.D er det derfor en yderst brugbar metode, da de ikke benytter sig af vandfaldsmodellen, og den derfor kan være med til at øge effektiviteten gevaldigt. Den sidste metode er multiperspektiviteten bag deres udviklingsproces. De øvre instanser bag projektet M.A.D har fra begyndelsen af været klar over, at dette kunne få afgørende betydning, da de sammensatte holdet af udviklere. Udviklingsgruppen bestod både af folk med systemudviklingsuddannelser, samt folk med helt andre uddannelser, som kunne være til stor nytte i visse faser af projektet. Denne metode ses

25 20 LITTERATURLISTE ikke direkte i kursuslitteraturen, men vil dog altid være til stede i et projekt, omend ikke i lige så udtænkt grad som det er tilfældet i M.A.D, da medlemmer af en udviklingsgruppe altid vil have forskellige kvalifikationer med sig. Dog er det de klart definerede roller i M.A.D, som etnograf, samarbejdsdesigner og OO-folk, der udgør det multiperspektive indblik i de forskellige faser, som udviklingsgruppen nyder godt af. Litteraturliste [1] N. E. Andersen. Professionel Systemudvikling. Teknisk Forlag, [2] D. Barnes and Kölling M. Objects First with Java. Pearson Education International, 4 edition, [3] L. Bass, P. Clements, R. Kazman, and L. Northrop. Software Architecture in Practice, chapter What is Software Architecture?, pages Pearson Education Inc., 2 edition, [4] B. Boehm. A spiral model of software development and enhancement. IEEE Computer, 21:61 72, [5] F. P. Brooks. No silver bullet. Proc. of the IFIP Tenth World Computing Conference, edited by H.-J. Kugler (1986), pages , Reprinted version from the book Brooks, F. P. (1995), The mythical man-month: Essays on software engineering, Addison-Wesley Publishing. [6] Oracle Corporation. Mysql, jdbc connector. connector/j/, Juni [7] Forsidebillede. A map which shows the distribution of all the language families in the world. the_world-3.png, Februar [8] Gerry Gaffney. What is affinity diagramming? Usability Techniques series, [9] H. Garcia-Molina, J. D. Ullman, and J. Widom. Database Systems - The Complete Book. Pearson Education International, 2 edition, [10] Google. Google docs. juni [11] J. Highsmith. Extreme programming. ead (e-business application delivery), 12:1 16, Cutter Consortium, [12] ITMEDIA. juni [13] Leif Obel Jepsen, Lars Mathiassen, and Peter Axel Nielsen. Back to thinking mode: diaries for the management of information systems development projects. Behaviour and information technology, vol. 8, 1989.

26 LITTERATURLISTE 21 [14] L. Mathiassen, A. Munk-madsen, P. A. Nielsen, and J. Stage. Objektorienteret analyse & design. Forlaget Marko ApS, 3 edition, [15] P. Naur. Programming as theory building. Microprocessing and Microprogramming, 15: , Reprinted version from Naur, P. (1992), Computing: a Human Activity, ACM, pp [16] Open Source. Moodle. april [17] SUN. Sun s hjemmeside vedrørende internationalisering af javasystemer. http: //java.sun.com/javase/technologies/core/basic/intl/faq.jsp, april [18] J. Sutherland, C. R. Jakobsen, and K. Johnsons. Scrum and cmmi level 5: The magic potion for code warriors. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 08), IEEE Computer Society, page 9 pages, [19] Michael Christensen & Andy Crabtree & Christian Heide Damm & Klaus Marius Hansen & Ole Lehrmann Madsen & Pernille Marqvardsen & Preben Mogensen & Elmer Sandvad & Lennert Sloth & Michael Thomsen. The m.a.d. experience: Multiperspective application development in evolutionary prototyping. In Proceedings of the 12th European Conference on Object-Oriented Programming (ECCOP 98), Eric Jul (Ed.). Springer- Verlag, London, UK, 13-40, [20] Michael Vinther. Diagram designer. juni 2011.

27 22 A FØRSTE PROTOTYPE A Første prototype A.1 Valg af prototype I vores første prototype har vi valgt kun at inddrage 2 af vores 3 brugergrænseflader. Dette skyldes at alle væsentlige funktioner for at køre og bruge programmet er indeholdt i de to brugere: Lærer og elev. Vi vil satse på at få disse to grænseflader fuldt implementeret inden vi tænker på det sidste, for uden disse to kan programmet ikke fungere. Udover disse to har vi tænkt os at have et administrator-grænseflade. Administratorgrænsefladen er den mest avancerede af de 3 grænseflader i det, at det skal have fuld adgang til alle funktioner, og tilmed skal have et grafisk modelleringsværktøj til at administrere MySql databasen. Der vil herunder følge en række skærmbilleder fra vores første prototype, først fra en elevs synspunkt og herefter fra en lærers synspunkt. A.2 En elev og en lærers brugergrænseflade Figur 10: Ovenstående vindue repræsenterer vores brugergrænseflade, når en elev åbner det. Fra dette vindue har en elev via en træbaseret menu til venstre i billedet adgang til de forskellige mapper med øvelser. Eleven kan herfra klikke på en valgt øvelse og benytte Open Exercise -knappen til at åbne denne i hovedvinduet (vinduet til højre). Eleven har også mulighed for ændre lydniveauet for afspilning via slideren placeret nederst i højre hjørne af vinduet. Endvidere kan eleven vælge at få mappeoversigten til at forsvinde for at få bedre overblik over en øvelse ved at benytte knappen Hide Overlay.

28 A.2 En elev og en lærers brugergrænseflade 23 Figur 11: Dette vindue viser, at en elev har åbnet en øvelse. Øvelsen består i dette tilfælde af tekst og lyd med højtlæsning af teksten. Eleven kan via Record -knappen optage sit eget forsøg på højtlæsning, herefter bliver forsøget gemt i dropdown menuen Recorded Answers, og efter nogle forsøg, kan eleven vælge at aflevere den optagelse han/hun synes ønsker. Figur 12: I dette vindue kan eleven aflevere sin besvarelse, som han optog i forrige vindue. Han kan her høre alle sine besvarelse via dropdown menuen Recorded Answers, og kan aflevere den han synes bedst om ved at trykke på Submit Answer.

29 24 A FØRSTE PROTOTYPE Figur 13: Her kan en lærer oprette en ny øvelse ved at indsætte titel, tekst og lydfiler efter behov. Herefter kan læreren vælge om øvelsen skal være tilgængelig for alle via Public/Private, se et eksempel via Preview Exercise -knappen, og afslutte med Done -knappen. Figur 14: I dette kan læreren se sine aktuelle hold under menuen Classes, og via New Class -knappen kan læreren oprette et nyt hold. Ved at markere et bestemt hold kan læreren se eleverne, der er tilmeldt holdet. Herfra kan læreren tilføje eller fjerne elever via Remove From Class - og Add New Student(s) To Class -knapperne.

30 A.3 Navigeringsdiagrammer 25 Figur 15: For at komme til dette pop-up vindue ønsker en lærer at tilføje en eller flere elever til et hold via Super Teacher grænseflade - Classroom Overview -vinduet. I dette vindue kan en lærer søge på elever via enten ID er, holdtilmeldinger, navn eller andet ved at benytte søgefeltet øverst til venstre i pop-up vinduet. Læreren vil da få returneret en liste at elever i feltet til venstre under søgefeltet som han/hun kan markere. Ved at markere disse elever kan læreren tilføje disse elever til en liste ved at benytte Add -knappen og fjerne dem igen fra denne list ved at benytte Remove -knappen. Når læreren er tilfreds med sit valg af elever, kan han/hun enten trykke på Cancel -knappen for at annullere sit valg, eller trykke på Done -knappen for at tilføje de valgte elever til det aktuelle hold. A.3 Navigeringsdiagrammer Jeg vil her komme med nogle navigeringsdiagrammer for at vise, hvorledes de tidligere viste skærmbilleder hænger sammen. A.3.1 For en lærer Figur 16: Lærer navigeringsdiagram: En lærer kan fra sit Main Window gå to veje. Han kan ændre eller lave en øvelse og han kan gå ind i sit Classroom Overview. I sidstnævnt har læreren adgang til at se sine hold, samt ændrer hvilke elever der skal være i de forskellige hold.

31 26 A FØRSTE PROTOTYPE A.3.2 For en elev Figur 17: Elev navigeringsdiagram: En elev har via sit Main Window mulighed for at åbne en øvelse. Herfra kan eleven da vælge at aflevere en besvarelse på øvelsen og/eller lukke øvelsen, hvorpå eleven bliver returneret til sit Main Window. A.4 Evaluering og resultat af første prototype For at evaluere vores første prototype holdte vi d. 6/ et møde med ITMEDIA, hvor vi præsenterede vores papirprototype for dem. Dette gjorde vi ved at udskrive ovenstående prototypevinduer på A4 ark og herefter fremvise disse for vores kunde samtidig med, at vi forklarede hvordan vinduerne hang sammen. Grunden til at vi valgte netop denne metode til at evaluere vores første prototype, er at vi på denne måde får bekræftet, at vores prototype er på rette spor i forhold til hvad vores kunder ønsker. Endvidere kan vi ved denne metode også demonstrere, hvorledes vi har tænkt de meste basale funktionaliteter ind i vores program. Disse kan vores kunde så kommentere på, og på denne måde kan vi nemt komme uden om grundlæggende misforståelser, som senere kan blive til store problemer. De tog ude på ITMEDIA godt imod vores prototype kun med få indvendinger. Vi havde oprindeligt tænkt os at basere vores system på et allerede eksisterende databasesystem (Moodle), men kom efter en kort diskussion med ITMEDIA frem til, at vi hellere selv ville konstruere en MySQL database, som vores system kan benytte. De kom også med en enkelt indvending til selve designet af prototypen. De påpegede, at det var vigtigt under vores øvelsesvindue, at scrollbaren blev erstattet med to knapper, der kunne skifte frem og tilbage mellem de forskellige sider i en øvelse. Grunden til denne modifikation er, at en elev, som skal besvare en opgave med mange sider, let kommer til at miste overblikket over opgaven, hvis vedkommende skal scrolle sig vej igennem opgaven. Det er derfor en fordel at lave knapper i stedet, så eleven let kan skifte mellem de forskellige dele af opgaven og samtidig hele tiden have overblik over, hvor han/hun er i opgaven. A.5 Analyse og diskussion af evaluering Umiddelbart er det ikke nogen særlig kompliceret opgave at ændre måden, hvorpå en elev navigerer mellem de forskellige dele af en opgave. Dette kræver, at vi splitter øvelserne op i øvelseselementer i stedet for at have hele øvelsen samlet i et objekt. Dette vil vi gøre på den måde, at man i hvert øvelseselement kan have tekst og/eller lydelementer. Ved at binde disse øvelseselementer sammen, kan man på den måde danne

32 A.6 Konklusion af første prototype 27 en hel øvelse. Endvidere kan vi herudfra også let ordne en elevs besvarelse på en øvelse efter samme stil, da dette så blot vil inkludere at kæde en besvarelse i form af en lydfil til et specifikt øvelseselement i en øvelse. A.6 Konklusion af første prototype Alt i alt skal vi til vores næste prototype ændre på vores øvelsesklasse, så en øvelse nu indeholder ét eller flere øvelseselementer. Ud over dette skal vi også kæde disse elementer sammen, men dette kan jo passende ske i øvelsesklassen, da ethvert øvelseselement er forbundet til et objekt af øvelsesklassen. Endvidere skal vi også i vores fremtidige prototyper tænke på at designe vores database. Dette kræver en smule mere arbejde af os end tidligere, men sammenlignet med arbejdet i af sætte os ind i en allerede eksisterende database, er dette klart af foretrække. B Anden prototype Den anden prototype vi har valgt at lave, er en kørbar java-udgave af den første prototype. Vi har således baseret vores brugergrænseflader på de grænseflader vi nåede frem til under udviklingen af den første prototype. Samtidig har vi også videreudviklet vores system, med henblik på de kommentarer vi fik under evalueringen af den første prototype. Dette indebærer specielt muligheden for at bladre i en øvelse for at få vist forskellige øvelseselementer. Figur 18: Ovenstående vindue repræsenterer login skærmen, som er den første skærm brugeren får vist efter systemet bliver åbnet. Her kan en bruger vælge at køre programmet i offline mode, hvorpå han/hun ikke forbinder direkte til serveren. Brugeren kan også vælge at indtaste et forudbestemt brugernavn og en hertilhørende adgangskode og på denne måde logge ind i systemet.

33 28 B ANDEN PROTOTYPE Figur 19: Ovenstående vindue giver en kort velkomstmeddelelse, samt muligheden for at brugeren kan vælge (afhængigt af brugerens rettigheder) hvilke hovedvinduer han/hun vil åbne. Figur 20: Ovenstående vindue er brugergrænsefladen for en elev. I venstre side har eleven et overblik og sine klasser og øvelserne, der hører til de valgte klasser. Endvidere bliver eleven også mødt men en velkomstbesked i højre side, når han/hun åbner dette vindue op.

34 29 Figur 21: Ovenstående vindue repræsenterer, at en elev har åbnet en øvelse fra databasen til venstre i vinduet. Eleven kan nu vælge at afspille lydøvelsen med Play -knappen eller indspille sin egen lyd med Record -knappen. Til sidst kan eleven vælge at bladre mellem øvelsens sider ved at benytte Next - og Previous -knapperne i bunden af skærmen. Figur 22: Ovenstående vindue repræsenterer, at en elev har optaget tre forsøg på en øvelse. Eleven kan nu se de tidligere optagede forsøg, og afspille dem enkeltvis ved at vælge dem fra dropdown menuen.

35 30 B ANDEN PROTOTYPE Figur 23: Ovenstående vindue repræsenterer, at en elev har en øvelse åben og derefter trykker på knappen Hide overview. Herved skjules oversigten, og gives mere plads til selve opgaven. Oversigten kan åbnes igen ved at trykke på Open overview. Figur 24: Dette vindue samt næste vindue figur 25 demonstrerer, hvorledes Change - knappen fungerer. Knappen fungerer ved at ændre oversigten fra at indholde mapper med øvelser til at indeholde mapper med elever og lærere. Det kan nu ses hvilke opgaver en elev har lavet, og hvilke klasser denne elev er tilmeldt.

36 B.1 Navigeringsdiagram 31 Figur 25: Her har brugeren trykket på Change -knappen og får nu vist en oversigt over elever og lærere. B.1 Navigeringsdiagram Figur 26: Navigeringsdiagram for anden prototype. I denne iteration af vores system, har vi ikke nået at dække alle disse funktioner, som vores papirprototype viste. Hvis vi havde, ville dette diagram ligne dem ovenfor. I forhold til ovenfor er dette diagram altså mangelfuldt, dog er vinduerne login window og user interface chooser tilføjet. B.2 Evaluering af anden prototype For at evaluere vores anden prototype, aftalte vi et møde med Christian Jensen fra Center for Internationalisering og Parallelsproglighed ved Københavns Universitet. Til dette møde præsenterede vi kort Christian for tænke-højt metoden, hvorefter vi med Christian som testperson benyttede denne metode til at teste vores system. Grunden til at vi valgte netop denne metode er, udover at vi har erfaring med den fra øvelsestimerne, at metoden giver et godt indblik i hvorledes en bruger ofte vil benytte et program af vores type.

37 32 B ANDEN PROTOTYPE Det skal hertil bemærkes, at Christian ikke er en helt uerfaren bruger af systemer der minder om vores, da han selv er meget interesseret i netop idéen om digitale sproglaboratorier. Dette ser vi både som en svaghed og en styrke. Det er en svaghed, da Christian således har en foruddannet mening om hvorledes et program som vores bør virke. Dette kan resultere i, at Christian således kommer til at springe nogle af de faldgruber over, som en normal uerfaren bruger vil falde i, og vi på denne måde ikke får tilstrækkeligt ud af vores test. På den anden side kan det også være en styrke da Christian da ved, hvorledes et program som vores fungerer bedst muligt. Han kender de almindeligste funktioner og ud fra dette kan han nemt komme med kommentarer til, hvis vores valg af design skiller sig ud fra normen på gode og/eller dårlige måder. Disse aspekter vil vi ikke kunne få fra en normal bruger (f.eks. en studerende) i samme omfang, hvortil vi vurdere at Christian fungerer som en god testperson til de tidlige prototypestadier, hvor grænseflader er under stadig udvikling. Til sidst er Christian også lærer i et sprogfag og derfor en vigtig bruger af vores program. Han kan hertil både teste elev-delen og lærer-delen, da han som sprogfaglig lærer vil have en idé om hvordan opgaver, besvarelser o.lign. vil fungere bedst. B.2.1 Selve testen Før mødet med Christian forberedte vi en liste af punkter i henhold til den valgte testmetode, som Christian skulle benytte sig af under testen. Da vores prototype stadig er under udvikling, har vi indlagt nogle punkter, hvor Christian skal tage stilling til, hvilke funktionaliteter han godt kunne tænke sig var de forskellige steder i vores program. Vi er udemærket klar over, at dette strider med den normale tænke-højt - testmetode, men da disse primært er koncentreret i slutningen af testen, og derfor ikke vil indvirke på den primære del af testen, samt at vi føler, at vi kan drage stor nytte af kommentarerne, der kommer heraf, har vi valgt at gøre dette. Disse var som følger: 1. Start programmet. 2. Åbn offline tilstand. 3. Vælg og åbn studenterskærmen. 4. Læs startmeddelelsen. 5. Find øvelserne. 6. Vælg en øvelse. 7. Beskriv for os, hvad du forventer at en studerende skal gøre i øvelsen. 8. Prøv at gøre dette. 9. Vælg og åbn en anden øvelse. 10. Åbn lærerskærmen. 11. Prøv alle knapper af. 12. Hvilke funktioner kunne du tænke dig, at der var på denne skærm? 13. Åbn kursusansvarligskærmen. 14. Hvilke funktioner kunne du tænke dig, at der var på denne skærm?

38 B.3 Resultat af evaluering 33 B.3 Resultat af evaluering I takt med at Christian fulgte den udleverede seddel, fik vi noteret følgende kommentarer: For at vurdere hvilke ting vi skal fokusere på til næste prototype, har vi valgt at give kommentarerne karakter fra 1 til 5 alt afhængig af hvor vigtig kommentaren er for den videre udvikling, hvor 5 er meget vigtig. Således kan vi i den næste prototype primært koncentrere mest os om problemerne med høje værdier, og således stadig opnå et langt bedre produkt uden at gå for meget i detaljer. Overview-vinduet, hvor man får overblik over databasen, skal være bedre struktureret. Om denne struktur skal komme fra os, eller om underviserne selv skal strukturere overblikket for deres studerende, mangler vi stadig at bestemme. Det kan være en fordel for lærere selv at kunne strukturere overblikket over øvelserne, da de i såfald kan tilpasse udseendet netop til deres elever. 3 Christian var lidt overrasket over, at man skulle benytte en træbaseret menu til at browse imellem øvelser, men han fandt hurtigt ud af at benytte denne alligevel. 1 Ordet Database skal væk fra overblikket. Alternativer kunne være Classes eller Courses. 4 Når man klikker på en øvelse, skal man kunne åbne øvelsen ved at dobbeltklikke på den. 4 Ved åbningen af en øvelse bør der komme en form for instruktion til øvelsen før denne begyndes. 4 Christian fortalte, at vores program kræver utrolig mange klik og arbejde med musen, når man skulle navigere igennem en øvelse, og at dette derfor godt kunne skabe frustration blandt brugerne. Vi bør derfor bestræbe os på at komme uden om dette i næste prototype ved at indføre en del automatik. 5 Dropdown menuen til højre for optagelsesfunktionen i en øvelse skal opdateres, og den sidste optagelse skal markeres, lige så snart en optagelse er afsluttet. 5 Når man er inde i en øvelse og åbner en anden øvelse, bør der komme en menu, der spørger om man vil afslutte den åbnede øvelse for at gøre brugeren opmærksom på, at han/hun skifter øvelse. 4 Øvelser skal klassificeres og grupperes på serveren, så det er let for en lærer at finde en bestemt type øvelse. Denne gruppering bør først ske når databasen over øvelser har nået en vis størrelse, da dette ellers er spild af tid og plads. Dette skal dog stadig overvejes, så der gøres plads til denne udvidelse. 1 Forslag til funktionalitet: I lærerskærmen skal en lærer via overbliksmenuen kunne vælge en elev og trykke åben. Herefter skal elevens status over øvelser vedkommende har lavet, og hvilke kurser/klasser eleven er tilknyttet, vises i højre vindue. 2

39 34 B ANDEN PROTOTYPE Forslag til funktionalitet: I lærerskærmen skal en lærer kunne åbne et alternativt billede af en øvelse. Dette skal indeholde information om, hvilke elever der har afleveret en besvarelse på øvelsen. Endvidere kan der her også være andre informationer som er relevante for en lærer (f.eks. statistiker over rigtige svar, hvor mange timer/minutters svar der er afgivet, så læreren kan prioritere sin tid, osv.). 2 Vedrørende rettelser til besvarelser, skal en rettelse kunne gives til et enkelt element i en øvelse samt generelt til hele øvelsen. 2 Rettelser til besvarelser kan være både mundtlige og skriftlige. Fordele ved mundtlige besvarelser (optaget og gemt de rigtige steder til eleven) er, at de er langt hurtigere at lave for en lærer. Dog ender dette i, at eleven ofte skal bruge længere tid på at forstå hver rettelse, end hvis rettelserne var skriftlige. 3 En elev skal kunne genaflevere en besvarelse på en øvelse. I vores nuværende udgave har vi kun tænkt muligheden for én besvarelse pr. elev pr. øvelse. Dette skal vi klart genoverveje, såfremt programmet skal benyttes i undervisning, da genafleveringer er en vigtig del i mange undervisningsformer. 4 Change -knappen skal have et nyt navn. Det er ikke klart hvad denne knap gør. Knappen skifter mellem at betragte øvelser og elever. 4 En elev skal kun have adgang til relevante øvelser. Dette gør det klart nemmere for mindre computervandte brugere at benytte systemet, da der i såfald ikke vil være lige så mange fejlvalg, de vil kunne foretage. 3 Forslag til funktionalitet: En tidspunktsfunktion som i Absalon, så en lærer kan sætte et tidspunkt, hvor en øvelse skal blive tilgængelig for de studerende. 1 Omstrukturering: En underviser bør gøres til en superunderviser. Grunden til dette er, at der på det sproglige fakultet er en anderledes struktur, end hvad vi på DIKU er vandt til. Denne struktur bygger på, at hver hold på et kursus er knyttet til en klasselærer, der varetager hvilke øvelser de studerende skal lave. Dette indebærer også muligheden for, at en sådan underviser kan fremstille nye øvelser. Dette strider imod underviser-klassen vi har lavet, da vi har antaget at en underviser blot følger instrukser fra en superunderviser/kursusansvarlig. Vi bør derfor revurdere denne klasse til næste prototype. 5 Rettigheder over øvelser bør implementeres direkte i online databasen. Dette bør gøres, da undervisere ellers kunne hælde til at være mere tilbagetrukne til at lave øvelser til vores system. En underviser bør ikke frarøves nogen som helst form for rettighed over hvad de selv fremstiller, blot fordi de gerne vil benytte vores program. Dette er af høj vigtighed lige nu, da det er yderst vanskeligt at ændre online databasens struktur senere hen i forløbet. 5 Understøttelse af ikke ascii -tegn i øvelsesvinduet. Dette er relativt vigtigt for det endelig produkt, da fremmedsprog ofte indeholder andre tegn end dem tilgængelig i ascii -tegnsystemet. Vi bør derfor i en senere prototype tilføje unicode encoding, da dette vil udvide vores brugerkreds til også at omfatte sprog uden for de vesteuropæiske sprogstammer. 4

40 B.4 Analyse og diskussion af evaluering 35 B.4 Analyse og diskussion af evaluering Ud fra karaktergivningen af kommentarerne i forrige afsnit kan vi nu let afgøre, hvilke elementer vi skal koncentrere os om i vores næste prototype. For at danne os et overblik over kommentarerne, vil vi sætte punkterne der har fået 5 og 4 op nedenfor her. Ud fra hver af disse vil vi nu kort gøre rede for eventuelle problemer disse kan skabe ved implementering i vores system, samt hvad vi kan gøre for at omgå disse problemer. B.4.1 De vigtigste Automatik Det problematiske ved dette punkt bliver at bestemme, hvilke input fra brugeren vi skal springe over og få computeren til selv at udføre. Der er nogle åbenlyse punkter, som er nemme at håndtere, nemlig implementeringen af en fælles optag/stop knap, så en elev/lærer ikke skal flytte musen efter af have trykket Record for at abryde optagefunktionen. Andre funktioner vi kan overveje at gøre automatiske er afspilning af tilknyttet lyd, så snart en elev åbner et øvelseselement. Dette sparer eleven for at skulle finde play knappen på hver seperat side af en øvelse. En yderligere funktion, som ikke nødvendigvis øger automatikken, men stadig har indflydelse på brugshastigheden af vores system, er implementeringen af genvejstaster. Man kunne for eksempel sætte Enter -knappen til at afspille opgavelydfilen i et øvelseselement og Space -knappen til at starte/stoppe optagefunktionen. Opdatering af dropdown menuen Denne implementering skaber ikke nogen forudsebare problemer. Omstrukturering af lærer-/superlærerklasserne Vi har indtil videre haft streng opdeling mellem en lærer og en superlærer. I vores næste prototype bør disse to klasser være én klasse. Dette burde ikke skabe nogen problemer, da klasserne allerede nu begge er underklasser af en fælles User -klasse, og derfor deler en masse funktionaliteter. Rettigheder Implementeringen af rettigheder over øvelser og lydfiler i vores system vil foregå i databasen. Da databasen og klientdelen til denne i vores system endnu ikke er sat op, har vi ingen problemer med at tilpasse denne, så rettigheder også er omfattet. B.4.2 De næst vigtigste Ordet Database skal fjernes fra Overview Denne implementering skaber ikke nogen forudsebare problemer. Dobbeltklikfunktion Denne implementering skaber ikke nogen forudsebare problemer. Instruktion til øvelser Denne implementering skaber ikke nogen forudsebare problemer. En instruktion kan enten blot forekomme som et ekstra øvelseselement i begyndelsen af en øvelse, eller som et seperat vindue der kommer frem når man åbner en øvelse. Den sidste løsning springer mest i øjnene på en bruger, men ødelægger idéen om at have alt samlet i ét vindue, så vi hælder mest til løsningen med et ekstra øvelseselement. Bekræftelse ved lukning af øvelse Denne implementering skaber ikke nogen forudsebare problemer. Denne bekræftelse bør komme så snart en elev foretager en

41 36 C EKSEMPEL PÅ KODE handling, som vil lukke øvelsen en elev har åben. Bekræftelsen bør komme i form af en dialogboks, som vi også har beskrevet i vores første prototype. Dette er et af de eneste tidspunkter et seperat vindue bliver åbnet, som overskygger vores hovedvindue. Vores hovedvindue skal i dette tilfælde blive inaktivt, så brugeren bliver tvunget til at tage stilling til dialogboksen før øvelsen bliver lukket. Change -knappen Denne implementering skaber ikke nogen forudsebare problemer. Understøttelse af ikke- ascii tegn Til dette punkt, har vi læst lidt om internationalisering på Sun s egen hjemmeside [17]. Ud fra dette bliver det ikke noget problem at vise unicode tegn i vores program. I Java har et tekstfelt en indbygget funktion, som vi kan benytte os af til sætte hvilken tekstfont tekstfeltet skal benytte sig af. Dette gør os i stand til at vise fremmedtegn, når vi har sat os ind i hvordan denne funktion fungere. Om vi så også skal implementere en funktion, så en bruger kan også kan indtaste unicode tegn, har vi ikke taget stilling til endnu, men dette er ikke noget, der burde give problemer i senere stadie af systemet. Et vigtigt punkt vedrørende dette er, at typen af tegn (altså skriftsproget tegntypen hører til) skal implementeres i en øvelse, så dette bør vi også implementere i vores database fra begyndelsen af, så det ikke skaber problemer senere. B.5 Konklusion af anden prototype I vores næste prototype bør vi efterstræbe, at flest muligt af ovenstående punkter bliver implementeret. Dette kræver, at vi bl.a. bør undersøge, hvilke funktionaliteter vi kan gøre automatiske, så vi kan optimere oplevelsen for brugeren mest muligt. Endvidere har det også vist sig, at vores database som vi havde forestillet os den, har fået vigtige input via testen af denne prototype, som vi ikke havde kunnet forudsige. Vi bør derfor være ekstra opmærksomme på, om der er andre punkter, som vi endnu ikke har forudset, som kan forårsage flere ændringer i vores databasedesign. C Eksempel på kode C.1 Online_db_mod klassen 1 package makedatabases ; 3 import database. E x e r c i s e ; import database. ExElement ; 5 import database. S o l u t i o n ; import database. Student ; 7 import database. Teacher ; import database. User ; 9 import view. MediaFilePlayer ; import e x c e p t i o n s. ; 11 import java. awt. Component ; 13 import java. s e c u r i t y. ; import java. s q l. DriverManager ; 15 import java. s q l. ResultSet ; import java. s q l. SQLException ; 17 import java. s q l. Connection ; import java. s q l. PreparedStatement ;

42 C.1 Online_db_mod klassen import java. s q l. Statement ; import java. u t i l. ArrayList ; 21 import java. u t i l. Arrays ; 23 / Class f o r p a r s i n g SQL c a l l s to and from the s e r v e r. Soeren / 27 public c l a s s Online_db_mod { private static f i n a l S t r i n g SERVER_URL = " s e r v e r _ u r l " ; 29 private static f i n a l S t r i n g SERVER_PASS = " pass " ; private static f i n a l S t r i n g SERVER_USER = " user " ; 31 private Connection connection = null ; 33 public Online_db_mod ( ) throws NoConnection { try{ 35 // Loading the MySql d r i v e r Class. forname ( "com. mysql. jdbc. Driver " ) ; 37 // S e t t i n g up the connection with the database 39 this. connection = DriverManager. getconnection ( " jdbc : mysql : " + Online_db_mod.SERVER_URL 41 + " u s e r=" + Online_db_mod.SERVER_USER + "&password=" + Online_db_mod. SERVER_PASS) ; 43 // Configuring the connection 45 this. connection. setautocommit ( f a l s e ) ; 47 catch ( SQLException e ) { System. out. p r i n t l n ( e ) ; 49 throw new NoConnection ( "No connection! " ) ; 51 catch ( ClassNotFoundException e ) { System. out. p r i n t l n ( e ) ; / 57 Method f o r adding an e x e r c i s e to the authorid The ID o f the author o f the e x e r c i s e d e s c r i p t i o n A s h o r t d e s c r i p t i o n o f the e x e r c i s e x e r c i s e _ f i l e _ p a t h The f i l e path o f the e x e r c i s e. language The language o f the e x e r c i s r i g h t s The r i g h t s o b t a i n e d by the author o f t h i s e x e r c i s e. e x e r c i s e An E x e r c i s e o b j e c t c o n t a i n i n g ExElement s to be added to t he 0 i f the i n s e r t i o n was u n s u c c e s s f u l, 1 i f the query was s u c c e s s f u l. 65 / public int addexercise ( E x e r c i s e e x e r c i s e, S t r i n g d e s c r i p t i o n, S t r i n g language, S t r i n g r i g h t s ) { 67 int r e s u l t = 0 ; 69 try{ 71 // Generating t he e x e r c i s e ID S t r i n g e x e r c i s e I D = this. generatenextexerciseid ( ) ;

43 38 C EKSEMPEL PÅ KODE 73 this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 75 // Preparing s q l statement 77 PreparedStatement preparedstatement = this. connection. preparestatement ( " i n s e r t i n t o e x e r c i s e s v a l u e s (?,?,?,?,?,?) " ) ; preparedstatement. s e t S t r i n g ( 1, e x e r c i s e. getid ( ) ) ; 79 preparedstatement. s e t S t r i n g ( 2, e x e r c i s e. g e t T i t l e ( ) ) ; preparedstatement. s e t S t r i n g ( 3, d e s c r i p t i o n ) ; 81 preparedstatement. s e t S t r i n g ( 4, e x e r c i s e. parsetostring ( ) ) ; preparedstatement. s e t S t r i n g ( 5, e x e r c i s e. getauthorid ( ) ) ; 83 preparedstatement. s e t S t r i n g ( 6, language ) ; preparedstatement. s e t S t r i n g ( 7, r i g h t s ) ; 85 preparedstatement. executeupdate ( ) ; 87 // Fetching e x e r c i s e elements ArrayList<ExElement> exelements = e x e r c i s e. getelements ( ) ; 89 // I n s e r t i n g e x e r c i s e elements 91 for ( ExElement exelement : exelements ) { // S t r i n g audio_id ; 93 for ( Component comp : exelement. getelements ( ExElement. LOCATION_SOUTH) ) { i f (comp instanceof MediaFilePlayer ) { 95 // audio_id = t h i s. generatenextaudioid ( ) ; MediaFilePlayer p l a y e r = ( MediaFilePlayer ) comp ; 97 this. addexerciseelement ( exerciseid, exelement. getnumber ( ), p l a y e r. getaudioid ( ) ) ; // t h i s. addexerciseaudiofile ( audio_id, p l a y e r. g e t F i l e P a t h ( ), p l a y e r. getauthor ( ), p l a y e r. g e t D e s c r i p t i o n ( ), p l a y e r. getlanguage ( ), p l a y e r. g e t R i g h t s ( ) ) ; this. connection. commit ( ) ; 105 r e s u l t = 1 ; 107 catch ( SQLException e ) { System. out. p r i n t l n ( e ) ; return r e s u l t ; 113 / 115 Method adding an e x e r c i s e element to the e x e r c i s e I D The i d o f the e x e r c i s e. exercise_element_number The number o f the e x e r c i s e audio_id The i d o f the audio. I n t e g e r 0 i f t he query i s u n s u c c e s f u l, 1 i f the query i s s u c e s s f u l. /

44 C.1 Online_db_mod klassen public int addexerciseelement ( S t r i n g exerciseid, int exercise_element_number, S t r i n g audio_id ) { int r e s u l t = 0 ; 123 try{ 125 PreparedStatement statement = this. connection. preparestatement ( " i n s e r t i n t o exercise_audio v a l u e s (?,?,? ) " ) ; statement. s e t S t r i n g ( 1, e x e r c i s e I D ) ; 127 statement. s e t I n t ( 2, exercise_element_number ) ; statement. s e t S t r i n g ( 3, audio_id ) ; 129 statement. executeupdate ( ) ; 131 r e s u l t = 1 ; 133 catch ( SQLException e ) { 135 System. out. p r i n t l n ( e ) ; 137 return r e s u l t ; / Method adding a s o l u t i o n to the database. student_id The i d o f the s t u d e n e x e r c i s e _ i d The i d o f the e x e r c i s e. audio_file_path The f i l e path o f the audio f i l e c o n t a i n i n g the s o l u t i o solution_number The number o f which t h i s s o l u t i o n i s. exercise_element_number The e x e r c i s e element number to which t h i s s o l u t i o n b e l o n g S t r i n g c o n t a i n i n g the ID o f the a u d i o _ f i l e i n s e r t e d. I f the update was u n s u c c e s s f u l the s t r i n g w i l l be " f a l s e ". 149 / public S t r i n g addsolution ( S t r i n g student_id, S t r i n g exercise_id, S t r i n g audio_file_path, int solution_number, int exercise_ element_ number ) { 151 S t r i n g r e s u l t = " f a l s e " ; 153 try{ this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 155 PreparedStatement statement = this. connection. preparestatement ( " i n s e r t i n t o s o l u t i o n s v a l u e s (?,?,?,? ) " ) ; 157 statement. s e t S t r i n g ( 1, student_id ) ; statement. s e t S t r i n g ( 2, e x e r c i s e _ i d ) ; 159 statement. s e t S t r i n g ( 3, audio_file_path ) ; statement. settimestamp ( 4, null ) ; 161 statement. executeupdate ( ) ; 163 PreparedStatement statement2 = this. connection. preparestatement ( " i n s e r t i n t o s o l u t i o n _ a u d i o _ f i l e s v a l u e s (?,?,?,? ) " ) ; statement2. s e t S t r i n g ( 1, audio_file_path ) ; 165 statement2. s e t I n t ( 2, solution_number ) ; S t r i n g audio_id = this. generatenextaudioid ( ) ; 167 statement2. s e t S t r i n g ( 3, audio_id ) ;

45 40 C EKSEMPEL PÅ KODE statement2. settimestamp ( 4, null ) ; 169 this. connection. commit ( ) ; 171 r e s u l t = audio_id ; 173 catch ( SQLException e ) { 175 System. out. p r i n t l n ( e ) ; 177 return r e s u l t ; / Adds a new user to the database. user_id The user ID o f the first_name F i r s t name o f the user. last_name Last name o f the password Password o f the user. is_teacher Boolean parameter. True i f the user i s a teacher, f a l s e i f the user i s a s t u d e n I n t e g e r 0 i f t he query i s u n s u c c e s f u l, 1 i f the query i s s u c e s s f u l. 189 / public int adduser ( S t r i n g user_id, S t r i n g first_name, S t r i n g last_name, S t r i n g password, boolean i s_teacher ) { 191 int r e s u l t = 0 ; 193 try{ this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 195 PreparedStatement preparedstatement = this. connection. preparestatement ( " i n s e r t i n t o u s e r s v a l u e s (?,?,?,?,? ) " ) ; 197 preparedstatement. s e t S t r i n g ( 1, user_id ) ; preparedstatement. s e t S t r i n g ( 2, first_name ) ; 199 preparedstatement. s e t S t r i n g ( 3, last_name ) ; preparedstatement. s e t S t r i n g ( 4, password ) ; 201 preparedstatement. setboolean ( 5, is_teacher ) ; preparedstatement. executeupdate ( ) ; 203 this. connection. commit ( ) ; 205 r e s u l t = 1 ; 207 catch ( SQLException e ) { 209 System. out. p r i n t l n ( e ) ; 211 return r e s u l t ; / Adds a new c l a s s to the database. classname The name o f t h e c l a s s t o be added. This name should be unique

46 C.1 Online_db_mod klassen i n t 0 i f the name i s not unique and/ or the query was u n s u c c e s s f u l, 1 i f the query was s u c c e s s f u l and the c l a s s has been added. 219 / public int addclass ( S t r i n g classname ) { 221 int r e s u l t = 0 ; 223 try{ this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 225 PreparedStatement preparedstatement = this. connection. preparestatement ( " i n s e r t i n t o c l a s s e s v a l u e s (? ) " ) ; 227 preparedstatement. s e t S t r i n g ( 1, classname ) ; preparedstatement. executeupdate ( ) ; 229 this. connection. commit ( ) ; 231 r e s u l t = 1 ; 233 catch ( SQLException e ) { 235 System. out. p r i n t l n ( e ) ; 237 return r e s u l t ; 239 / 241 Method f o r adding a s t u d e n t to a c l a s classname Name o f the c l a s s o f which the s t u d e n t i s to be added to. user_id The user ID o f the s t u d e n t to be I n t e g e r 0 i f t he c l a s s does not e x i s t and/ or the query was u n s u c c e s s f u l, i f the query was s u c c e s s f u l and the s t u d e n t has been added to the c l a s s. / 247 public int addstudenttoclass ( S t r i n g classname, S t r i n g user_id ) { int r e s u l t = 0 ; 249 try{ this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 251 PreparedStatement preparedstatement = this. connection. preparestatement ( " i n s e r t i n t o student_in_class v a l u e s (?,?) " ) ; 253 preparedstatement. s e t S t r i n g ( 1, user_id ) ; preparedstatement. s e t S t r i n g ( 2, classname ) ; 255 preparedstatement. executeupdate ( ) ; 257 this. connection. commit ( ) ; 259 r e s u l t = 1 ; 261 catch ( SQLException e ) { System. out. p r i n t l n ( e ) ; return r e s u l t ;

47 42 C EKSEMPEL PÅ KODE 267 / 269 Method f o r adding a user as t e a c h e r o f a c l a s user_id The user ID o f the t e a c h e r. classname The name o f the c l a s s o f which the t e a c h e r i s to be t e a c h e r o f. I n t e g e r 0 i f t he c l a s s does not e x i s t and/ or the query was u n s u c c e s s f u l, 1 i f the query was s u c c e s s f u l and the t e a c h e r has been added to t he c l a s s. 273 / public int addteachertoclass ( S t r i n g user_id, S t r i n g classname ) { 275 int r e s u l t = 0 ; try{ 277 this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 279 PreparedStatement preparedstatement = this. connection. preparestatement ( " i n s e r t i n t o teacher_of_class v a l u e s (?,?) " ) ; preparedstatement. s e t S t r i n g ( 1, user_id ) ; 281 preparedstatement. s e t S t r i n g ( 2, classname ) ; preparedstatement. executeupdate ( ) ; 283 this. connection. commit ( ) ; 285 r e s u l t = 1 ; 287 catch ( SQLException e ) { 289 System. out. p r i n t l n ( e ) ; 291 return r e s u l t ; / Changes the password o f a user. user_id The i d o f the old_password The o l d password o f the user. new_password The new password o f t h e u s e I n t e g e r 0 i f t he query i s u n s u c c e s f u l, 1 i f the password o f the user has been change, and 2 i f the o l d password doesn t match the u s e r s c u r r e n t password. 301 / public int changepasswordofuser ( S t r i n g user_ id, char [ ] old_password, char [ ] new_password ) { 303 int r e s u l t = 0 ; 305 try{ i f ( this. checkpassword ( user_id, old_password ) ) { 307 this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 309 S t r i n g new_password_as_string = new_password. t o S t r i n g ( ) ; 311 PreparedStatement statement = this. connection. preparestatement ( " update u s e r s s e t password =? where user_id l i k e?" ) ;

48 C.1 Online_db_mod klassen 43 statement. s e t S t r i n g ( 1, new_password_as_string ) ; 313 statement. s e t S t r i n g ( 2, user_id ) ; 315 this. connection. commit ( ) ; 317 r e s u l t = 1 ; 319 else { r e s u l t = 2 ; catch ( SQLException e ) { System. out. p r i n t l n ( e ) ; return r e s u l t ; 329 / 331 Method r e t u r n i n g an e x e r c i s e x e r c i s e _ i d The i d o f the e x e r c i s e to be returned. An array c o n t a i n i n g an o b j e c t o f c l a s s E x e r c i s e. / 335 public E x e r c i s e g e t E x e r c i s e ( S t r i n g e x e r c i s e _ i d ) { E x e r c i s e ex = null ; 337 try{ 339 this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 341 Statement statement = this. connection. createstatement ( ) ; ResultSet r e s u l t S e t = statement. executequery ( " s e l e c t t i t l e, e x e r c i s e _ s t r i n g, author_id, d e s c r i p t i o n, language from e x e r c i s e s where " " lower ( e x e r c i s e _ i d ) l i k e lower ( " + e x e r c i s e _ i d + " ) " ) ; 345 while ( r e s u l t S e t. next ( ) ) { ex = new E x e r c i s e ( "", "" ) ; 347 ex. setid ( e x e r c i s e _ i d ) ; ex. s e t T i t l e ( r e s u l t S e t. g e t S t r i n g ( 1 ) ) ; 349 ex. parsefromstring ( r e s u l t S e t. g e t S t r i n g ( 2 ) ) ; ex. setauthorid ( r e s u l t S e t. g e t S t r i n g ( 3 ) ) ; catch ( SQLException e ) { 355 System. out. p r i n t l n ( e ) ; 357 return ex ; / Method r e t u r n i n g the l a t e s t s o l u t i o n to an e x e r c i s e element. student_id The i d o f the s t u d e n t who have c r e a t e d the s o l u t i o n.

49 44 C EKSEMPEL PÅ e x e r c i s e _ i d The i d o f the e x e r c i s e o f which the s o l u t i o n i s made over. exercise_element_number The e x e r c i s e element number o f which the s o l u t i o n b e l o n g s The s o l u t i o n in q u e s t i o n. 367 / public S o l u t i o n g e t S o l u t i o n ( S t r i n g student_id, S t r i n g exercise_id, int exercise_ element_ number ) { 369 S o l u t i o n s o l = null ; return s o l ; 375 / Method r e t u r n i n g a User element. user_id The i d o f the user to The user in q u e s t i o n. 379 / public User getuser ( S t r i n g user_id ) { 381 User user = null ; 383 try{ this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 385 Statement statement = this. connection. createstatement ( ) ; 387 ResultSet r e s u l t S e t = statement. executequery ( " s e l e c t first_name, last_name, password, i s_teacher from u s e r s where " + " lower ( user_id ) l i k e lower ( " + user_id + " ) " ) ; 389 while ( r e s u l t S e t. next ( ) ) { 391 int type = r e s u l t S e t. g e t I n t ( 4 ) ; i f ( type == 1) { 393 user = new Teacher ( user_id ) ; 395 else { user = new Student ( user_id ) ; 397 user. setfirstname ( r e s u l t S e t. g e t S t r i n g ( 1 ) ) ; 399 user. setsurname ( r e s u l t S e t. g e t S t r i n g ( 2 ) ) ; user. setpassword ( r e s u l t S e t. g e t S t r i n g ( 3 ). tochararray ( ) ) ; catch ( SQLException e ) { 405 System. out. p r i n t l n ( e ) ; 407 return user ; / Method r e t u r n i n g a f f i l e path o f a audio f i l e in the database. audio_id The i d o f the audio f i l e to A s t r i n g c o n t a i n i n g the f i l e path o f the s e l e c t e d audio f i l e.

50 C.1 Online_db_mod klassen / public S t r i n g g e t E x e r c i s e A u d i o F i l e ( S t r i n g audio_id ) { 417 S t r i n g r e s u l t = "" ; 419 try{ this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 421 Statement statement = this. connection. createstatement ( ) ; 423 ResultSet r e s u l t S e t = statement. executequery ( " s e l e c t f i l e _ p a t h from e x e r c i s e _ a u d i o _ f i l e s where " + " lower ( audio_id ) l i k e lower ( " + audio_id + " ) " ) ; 425 while ( r e s u l t S e t. next ( ) ) { 427 r e s u l t = r e s u l t S e t. g e t S t r i n g ( 1 ) ; catch ( SQLException e ) { System. out. p r i n t l n ( e ) ; return r e s u l t ; 437 / 439 Method r e t u r n i n g a l i s t o f o b j e c t s o f c l a s s E x e r c i s e o f s t u d e n t a s s i g n e d to the s p e c i f i c c l a s classname The name o f the c l a s s. A l i s t o f E x e r c i s e o b j e c t s. / 443 public ArrayList<Exercise > g e t E x e r c i s e s O f C l a s s ( S t r i n g classname ) { ArrayList<Exercise > e x L i s t = new ArrayList<Exercise >() ; 445 try { 447 this. connection. s e t T r a n s a c t i o n I s o l a t i o n ( Connection. TRANSACTION_SERIALIZABLE) ; 449 PreparedStatement statement = this. connection. preparestatement ( " s e l e c t exercise_id, t i t l e, e x e r c i s e _ s t r i n g, author, classname from " + " e x e r c i s e s e1 j o i n e x e r c i s e _ o f _ c l a s s e2 on " " lower ( e1. e x e r c i s e _ i d ) = lower ( e2. e x e r c i s e _ i d ) " + "where lower (? ) l i k e lower ( classname ) " ) ; 453 statement. s e t S t r i n g ( 1, classname ) ; ResultSet r e s u l t S e t = statement. executequery ( ) ; 455 while ( r e s u l t S e t. next ( ) ) { 457 E x e r c i s e ex = new E x e r c i s e ( "", "" ) ; ex. setid ( r e s u l t S e t. g e t S t r i n g ( 1 ) ) ; 459 ex. s e t T i t l e ( r e s u l t S e t. g e t S t r i n g ( 2 ) ) ; ex. parsefromstring ( r e s u l t S e t. g e t S t r i n g ( 3 ) ) ; 461 ex. setauthorid ( r e s u l t S e t. g e t S t r i n g ( 4 ) ) ; e x L i s t. add ( ex ) ; catch ( SQLException e ) {

51 46 C EKSEMPEL PÅ KODE 467 System. out. p r i n t l n ( e ) ; 469 return e x L i s t ; 471 / 473 Method adding an e x e r c i s e to a s p e c i f i c c l a s classname The name o f the c l a s s. e x e r c i s e I D The i d o f the e x e r c i s e to I n t e g e r 0 i f t he query i s u n s u c c e s f u l, 1 i f the query was s u c c e s f u l. 477 / public int addexercisetoclass ( S t r i n g classname, S t r i n g e x e r c i s e I D ) { 479 int r e s u l t = 0 ; 481 try{ PreparedStatement preparedstatement = this. connection. preparestatement ( " i n s e r t i n t o e x e r c i s e _ o f _ c l a s s v a l u e s (?,? ) " ) ; 483 preparedstatement. s e t S t r i n g ( 1, classname ) ; preparedstatement. s e t S t r i n g ( 2, e x e r c i s e I D ) ; 485 preparedstatement. executeupdate ( ) ; 487 this. connection. commit ( ) ; 489 r e s u l t = 1 ; 491 catch ( SQLException e ) { System. out. p r i n t l n ( e ) ; 493 return r e s u l t ; / Method f o r g e n e r a t i n g the next e x e r c i s e ID. a s t r i n g c o n t a i n i n g the next a v a i l a b l e e x e r c i s e ID f o r use. / 501 public S t r i n g generatenextexerciseid ( ) { int ID = 0 ; 503 S t r i n g nextid = "" ; try{ 505 // Getting the ID Statement statement = this. connection. createstatement ( ) ; 507 ResultSet r e s u l t S e t = statement. executequery ( " s e l e c t number from exercisenumber " ) ; 509 while ( r e s u l t S e t. next ( ) ) { ID = r e s u l t S e t. g e t I n t ( 1 ) ; // Updating to the next ID : PreparedStatement stmt = this. connection. preparestatement ( " update exercisenumber s e t number =? where number =?" ) ; 515 stmt. s e t I n t ( 2, ID ) ; ID = ID + 1 ; 517 stmt. s e t I n t ( 1, ID ) ; stmt. executeupdate ( ) ;

52 C.1 Online_db_mod klassen MessageDigest md = MessageDigest. g e t I n s t a n c e ( "SHA1" ) ; 521 S t r i n g input = "" + ID ; md. update ( input. getbytes ( ) ) ; 523 byte [ ] output = md. d i g e s t ( ) ; 525 nextid = this. bytetohex ( output ) ; 527 catch ( SQLException e ) { 529 System. out. p r i n t l n ( e ) ; catch ( NoSuchAlgorithmException e ) { 531 e. printstacktrace ( ) ; 533 return nextid ; 535 / 537 Method g e n e r a t i n g the next audio a s t r i n g c o n t a i n i n g the next a v a i l a b l e audio ID f o r use. 539 / public S t r i n g generatenextaudioid ( ) { 541 int ID = 0 ; S t r i n g nextid = "" ; 543 try{ // Getting the ID 545 Statement statement = this. connection. createstatement ( ) ; ResultSet r e s u l t S e t = statement. executequery ( " s e l e c t number from audionumber" ) ; 547 while ( r e s u l t S e t. next ( ) ) { 549 ID = r e s u l t S e t. g e t I n t ( 1 ) ; 551 // Updating to the next ID : 553 PreparedStatement stmt = this. connection. preparestatement ( " update audionumber s e t number =? where number =?" ) ; stmt. s e t I n t ( 2, ID ) ; 555 ID = ID + 1 ; stmt. s e t I n t ( 1, ID ) ; 557 stmt. executeupdate ( ) ; 559 MessageDigest md = MessageDigest. g e t I n s t a n c e ( "SHA1" ) ; S t r i n g input = "" + ID ; 561 md. update ( input. getbytes ( ) ) ; 563 byte [ ] output = md. d i g e s t ( ) ; nextid = this. bytetohex ( output ) ; 565 return nextid ; 567 catch ( SQLException e ) { System. out. p r i n t l n ( e ) ; 569 catch ( NoSuchAlgorithmException e ) { e. printstacktrace ( ) ; 571 return nextid ; 573

53 48 C EKSEMPEL PÅ KODE 575 / Method c o n v e r t i n g b y t e input i n t o a s t r i n g. 577 / private S t r i n g bytetohex ( byte [ ] input ) { 579 char hex [ ] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F ; 581 S t r i n g B u f f e r b u f f e r = new S t r i n g B u f f e r ( ) ; for ( int j =0; j<input. l ength ; j++) { 583 b u f f e r. append ( hex [ ( input [ j ] >> 4) & 0 x0f ] ) ; b u f f e r. append ( hex [ input [ j ] & 0 x0f ] ) ; 585 return b u f f e r. t o S t r i n g ( ) ; / Method f o r c l o s i n g the connection to the database. 591 / public void c loseconnection ( ) { 593 try { this. connection. c l o s e ( ) ; 595 catch ( SQLException e ) { System. out. p r i n t l n ( e ) ;

54 49 D Uddrag af Javadoc D.1 Package control Class Summary Control Launcher Controls the BabeLLab GUIs Launches a babellab database with Model View Control D.2 Package database Class Summary ClassroomEditor Database ExElement Exercise ExerciseBuilder Group Solution Student Teacher User An editor for administrating classes Database models a database for exercises in BabelLab The exercise element consists of a panel containing several components, a panel of text, panel with player and recorder etc. also, this class arranges all its elements in a single JPanel (ExElement extends JPanel), so it can easily be used in any GUI The Exercise class holds information about an exercise in the BabeLLab program. The ExerciseBuilder is a GUI element that allows the user to construct an Exercise within the BabeLLab program. Models a class, i.e. a group of students with one or more teachers Models an answer to an excercise A BabelLab student A BabelLab administrator Abstract class User D.3 Package exceptions Exception Summary NoConnection Exception for throwing when no connection to the online server is available D.4 Package makedatabases Class Summary Local_db_mod MakeSampleDatabase Online_db_mod ReadLocalDatabase WriteLocalDatabase Class for modifying the local database. Class for creating a sample database. Class for parsing SQL calls to and from the server. Class for reading the local database. Class for writing to the local database.

55 50 E REFERATER D.5 Package view Class Summary CommonGUI GUISelector MediaCapture MediaFilePlayer OpeningDialog OpeningWindowListener StudentGUI TeacherGUI TransparentButton Abstract class CommonGUI - Contains the components common to the four BabeLLab GUIs The dialog for choosing GUI at program startup Recorder for capturing audio, includes GUI An audio file player including GUI The opening dialog of BabelLab The user chooses between off-line or online mode, and in the latter case, enters login and password. WindowListener that closes the system, when the window is closing The GUI of a student. The GUI of a teacher. Makes a background-free JButton E Referater Referaterne i dette appendix er et uddrag af vores udviklingsprocess, som kun beskæftiger sig med det indledende arbejde. Vi har som sådan kun inddraget referater fra de møder, som har haft størst indflydelse på vores færdige produkt. E.1 Første møde med ITMEDIA, KUA 9/2-11 Til stede fra ITMEDIA: Thomas Schlichting - Webdesigner, vores umiddelbare kontakt og ITMEDIAs tovholder på projektet. Lars Palmquist, IT-medarbejder, C# erfaren. Uwe Wollin. Vi blev vist rundt og fik set de faciliteter, de har til rådighed. Undervejs mødte vi Jamie, som har med lyd og kodning at gøre. Han kunne være god at snakke med undervejs. Gennem resten af dialogen var der meget snak om Preben Philip Dømler, som arbejder med sprogsyntese. Vi kan tale med ham med hensyn til komprimering af lydfiler, hvis dette bliver aktuelt. Resten af samtalen foregik med drøftelse af afgrænsning af vores opgave. Da der jo er mange anvendelsesmuligheder, som vi på ingen måde vil kunne nå at implementere inden eksamen, er vi blevet enige om, at lægge alle vores kræfter i at lave et grundigt og godt fundament af programmet, sådan at vi, eller andre, har mulighed for let at kunne bygge videre på denne senere hen. De var alle åbne for idéen om, at bruge Java som sprogplatform, og vi blev kraftigt rådet til at bruge Eclipse, når vi skal til at kode. Der var tale om en konference i Oktober, som vi måske kan deltage i, men det kom blot som en strøtanke. Dog værd at overveje. Mobile apps blev også nævnt flere gange,

56 E.2 Sproglaboratoriebesøg v. Nina Møller Andersen 16/ men det bliver nok ikke noget vi når inden for undervisningsperioden. Men vi skal selvfølgelig tænke kompatibilitet. Der var lidt snak frem og tilbage, og intet blev aftalt helt, men de lød også meget åbne for at tilbyde lagerplads og hosting, hvis ikke vi finder andre og bedre muligheder. Den foreløbige, aftalte struktur af programmet bliver en server med en database og en webside. Websiden hoster vores Java-software, som henter og sender sin information fra databasen. Ydermere vil vi lave en offline-klient, som kan downloades til brug uden direkte adgang til internettet. Funktionsmæssigt er tingene ikke helt kommet på plads endnu med hensyn til helt præcist hvilke funktionaliteter, der skal implementeres i vores første udgave, men det bliver der sandsynligvis kastet lys over til workshoppen d Dog virkede de glade for tanken om direkte kontakt fra IP til IP, så det er værd at tænke ind. Næste kontakt bliver en Workshop d. 23/2 fra kl på KUA. Thomas (Frø) vil undersøge muligheden for at se Sproglaboratoriet onsdag d. 16/2. Thomas Schlichting vil starte et google-doc, som vi kan kommunikere med hinanden via. Her skal skrives, når der sker fremskridt med planlægning af workshop og sproglaboratoriebesøg. Navne nævnt: Nina Møller Andersen - dansk for fremmedsprogede, benytter kassettebåndsbaseret sproglaboratorium. Preben Philip Dømler - sprogforsker, ham med sprogsyntese og mad skills inden for lyd. Jamie - som sidder med lyd og kodning på ITMEDIA, KUA. Eva Tore - spansk, har udviklet et digitalt og peer-to-peer baseret læringssystem med kontakt mellem danske og spanske studerende. Elena Lorentzen - russisk, har indkøbt sproglaboratorier til Syddansk Universitet og KU. Begreber nævnt: SVN/versionering - mulighed for rollback. IKT. METAstorage database. Bottomup/topdown design. E.2 Sproglaboratoriebesøg v. Nina Møller Andersen 16/ Nina Møller Andersen benytter sproglaboratoriet til at korrigere udtalen hos folk, der allerede kan dansk (evt. underviser i dansk i udlandet). Hun benytter sproglaboratoriet som supplement til teoretisk undervisning, hvor hun gennemgår typiske intonationsog lydfejl hos udlændinge. Til lydmaterialet hører en tekstbog med højtlæsnings- og udfyldningsopgaver. Øvelsestyper: Enkelte ord. Oplæsning af sætninger og hele tekster. Gentagelse af vokaler.

57 52 E REFERATER Vores hovedmål: At komme af med kassettebåndene. At studerende kan benytte softwaren hjemmefra. Andre tip: Icelandic Online (Norge og Finland også langt fremme med fjernundervisning). Nina kontakter os med hensyn til lignende systemer. Udskriftsystemer (Clan). Folk vi bør tale med: Dorthe Dunker: Datalog/Sprogforsker. Prof. Franz Gregorsen. Juni Arnfast. Sprogforandringscenteret (har lyddatabaser), bygning 27, KUA. E.3 Sproglaboratoriebesøg v. Elena Lorentzen 21/ Vores produkt er lavet. Sanako har alle de funktionaliteter, vi havde tænkt os at komme i vores sproglab. Dog er Sanako dyrt, og det kører kun på Windows. Derfor er det hverken egnet til communitydrevet sproglæring, brugerudvikling af nye features eller til fjernundervisning i en tid hvor flere og flere studerende bruger Mac/Linux. Vi vil lave en "light-udgave, som har de basale funktioner. Derudover vil vi få en database stablet på benene til deling af lyde og øvelser. Vi har set det digitale sproglaboratorium, Sanako, i aktion. Vi vil fortsat fokusere på kun at lægge en bund med det mest basale. Elenas ønsker til features, som Sanakos produkt (installationen i sproglaboratoriet i Snorresgade 17-19) ikke har: At kunne indskyde bemærkninger under undervisning. At kunne kommunikere med sine elever med skrift. At tilføje lydklip under undervisningen. At kunne vælge at se tekster, mens man taler. Lidt ligesom karaoke. At kunne dele alt dynamisk og hurtigt uden alle mulige restriktioner. Video-feed på øvelser til mundaflæsning. At kunne inddrage nyheder (video, tekster). At kunne skrive undertekster til disse nyheder. Røntgenillustration af mundens bevægelse under udtale. Vi vil tale med Jamie fra ITMEDIA om lydformater (vi skal være sikre på, at vi får brugt nogle åbne formater, så vi ikke kommer i klemme med rettigheder). Elena slår fast, at muligheden for at kunne imitere sin lærer, er vigtig (dvs. at et videolink er nødvendigt i fjernundervisningssammenhæng). Andre noter: IPA - internationalt fonetisk alfabet. Abdul - ingeniør, kommer til workshoppen.

58 E.4 Workshop v. ITMEDIA for alle interesserede 23/ E.4 Workshop v. ITMEDIA for alle interesserede 23/ Tilstedeværende ud over gruppen: ITMEDIA, Humanistisk Fakultet, Københavns Universitet: Thomas Schlichting, webudvikler. Uwe Wollin, chefkonsulent. Annette Pedersen, E-læringskonsulent. Institut for Tværkulturelle Og Regionale Studier, Københavns Universitet: Rolf-Dieter Lutzen, lektor i russisk, tidligere underviser ved Forsvarets Sprogskole. Guy Geffen, studeiadjunkt i hebraisk. Martin Schou Madsen, studieadjunkt i balkanstudier. Institut for engelsk og romanske sprog, Københavns Universitet: Thora Vinther, lektor emeritus i spansk. Fokus på anvendelse af teknologi i undervisningen, film slides osv. Christian Jensen, adjunkt i engelsk, underviser i udtale. Institut for Nordiske Studier og Sprogvidenskab, Københavns Universitet: Preben Philip Dømler, akademiingeniør, (eksperimentel fonetik). Forsvarets Sprogskole: Abdul Qudus, datamatiker, underviser i pashto. Benytter Forsvarets Sprogskoles sproglaboratorier (Sanako) dagligt og har opbygget eget site på Moodle, som opfylder mange af hans behov bedre. Ved fremmødet bød Thomas Schlichting os og deltagerne velkommen, og forklarede de grundlæggende rammer. Der blev lagt vægt på, at vi naturligvis ikke kan lave et helt færdigt stykke software, men at vores udvikling fremad igennem forløbet er det centrale. ITMEDIAs interesse består i at finde en nyere og mere moderne tilgang til sproglaboratorier, som kan bruges på KU. Thomas Frø åbnede med en præsentation af vores mål og visioner, og gav et oplæg til debat. Herefter afholdt gruppen en affinity map session, hvor alle kom med input. E.5 Møde med ITMEDIA, KUA 4/4-11 D. 4/4 mødtes gruppen om den anden delrapport, og vi endte med at aftale at dele nogle af emnerne ud. De tre af os med bedst tid vælger hver en artikel og skriver review, og så har vi lagt en plan for næste uge, så vi kan nå at få rapporten færdig.

59 54 E REFERATER E.6 Møde med ITMEDIA, KUA 6/4-11 D. 6/4 vi mødtes med ITMEDIA for at få godkendt vores kravspecifikation og for at fremvise vores første prototype. Vi snakkede meget om Moodle og om hvordan vi var endt med at vælge den løsning. Vi endte med helt at aftale at tage Moodle af tegnebrættet, da det præsenterer flere komplikationer end fordele. Hermed satser vi nu på en Java platform med adgang til en MySql database, og dette vil være de to eneste teknologier i brug. Prototypen tog de rigtig godt imod. Vi havde lavet en række eksempler på skærmbilleder og forklaret om vores ideer til brugerfladen. De havde kun få idéer til forbedring, herunder en scrollbar, som skulle fjernes og så et par ønsker til design, som nok desværre ikke kan realiseres indenfor vores tidsgrænse til sommer. disse designidéer indefatter bl.a. en cursor, som viser hvor i teksten man er henne, når man spiller lydfilen fra øvelsen (se Prototypen for overblik).