1
PROSJEKT NR. 2012-36 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT TILGJENGELIGHET Åpen Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKTETS TITTEL CHIRP Child Reinforcement Profile DATO 30.05.2012 30.5.2012 ANTALL SIDER / BILAG PROSJEKTDELTAKERE Christian Salater, Tola Sarzali, Zunaira Afzal, Magne Hjerman, Waleed Abtidon INTERN VEILEDER Larissa Sjarbaini OPPDRAGSGIVER KONTAKTPERSON Lars Klintwall Lars Klintwall SAMMENDRAG Denne hovedprosjektoppgaven går ut på å lage en applikasjon for en tablett av typen Android. Applikasjonen skal hjelpe forskningen til Lars Klintwall, som er oppdragsgiver. Han er PhD Fellow og psykolog. En del av forskningen hans går ut på å finne en måte å hjelpe med å påvise autisme hos småbarn. Denne applikasjon som vi har laget til hovedoppgaven vår skal hjelpe han med å påvise autisme hos barn i en tidlig alder. Dette skal gjøres ved hjelp av ulike stimuli, som inkluderer bilde og video, og som vises i flere sekvenser. Denne oppgaven er eksempel på hvordan dagens teknologi kan hjelpe til med medisinsk forskning. 3 STIKKORD Android; Java Autisme Forskning 2
3
Forord Denne sluttrapporten inneholder dokumentasjon for Hovedprosjektoppgave ved HiOA, 2012. Rapporten skal beskrive produktet som har blitt laget og gi innsikt i arbeidet som er gjort i prosjektperioden. Rapporten er delt i to deler; produktrapport og prosessrapport. Oppgaven gikk ut på å lage en applikasjon til et Android nettbrett, som kan hjelpe til med å påvise autisme hos barn i en tidlig alder. Dette er en viktig del av forskningen til oppdragsgiver, Lars Klintwall, som er psykolog ved HiOA. Vi startet å jobbe med prosjektet ved semesterstart 2012. En del forarbeid ble likevel gjort høsten 2011. Prosjektperioden varte frem til 30. mai 2012. Gjennom prosjektet har vi hatt et nært samarbeid med oppdragsgiver, Lars Klintwall. Vi vil takke han for den hjelpen vi har fått fra ham i prosjektperioden og muligheten til å arbeide med oppgaven. Larissa Sjarbaini, veilederen vår ved HiOA, har ledet oss gjennom prosjektet og passet på at vi hadde kontroll på alt gjennom prosjektperioden. Hun informerte oss om det som var relevant for prosjektet. Vi vil også takke henne for hennes samarbeid. 4
5
Sammendrag Denne prosjektoppgaven gikk ut på å lage en applikasjon for et Android nettbrett. Hensikten med applikasjonen er å hjelpe til med å påvise autisme hos barn i en tidlig alder. Oppdragsgiveren vår, Lars Klintwall, har jobbet med forskning relatert til autisme, og ville se om en slik applikasjon var en bedre metode for hans arbeid om påvisning av autisme. Applikasjonen er bygget opp slik at det først kommer opp en meny. Brukeren som registreres velger mellom fire typer sekvenser, som består av ulike stimuli, med bilde og video. Her inngår bildetypene; ansikt, mønster og kontroll. Poenget er at barnet, som testes, trykker på bildene på skjermen. Ansiktstypen viser videoer med ansikter på personer som lager ulike grimaser. Mønstertypen er bilder av ulike mønstre som beveger seg. Kontrolltypen fungerer som en slags test på om barnet faktisk skjønner at det skal trykke på bildet, eller om det trykker på skjermen helt tilfeldig. Comment [1]: De ulike sekvensene er delt opp i intervaller. Mens sekvensen går er det mulighet for brukeren å trykke på skjermen, og antall trykk registreres. Brukeren i dette tilfelle er barn i alderen mellom 8 og 20 måneder. Målet er å se hva barnet foretrekker å trykke på, og hva barnet viser interesse for. Dette er en måte å påvise autisme, eller tegn til autisme, hos barn. Vi valgte å utvikle denne applikasjonen til Samsung Galaxy Tab 10.1. Vi hadde valgt å lage applikasjonen for et Android nettbrett framfor Apples ipad, og valgte dette nettbrettet fordi det var prismessig, og fordi Samsung er kjent for å levere gode produkter. Oppdragsgiver, Lars Klintwall, har allerede gjort flere tester av applikasjonen de siste to månedene. Han har ikke fått testet det endelige produktet ennå, men forbereder testene. Dette vil han fortsette med i etterkant av prosjektets slutt. Det er derfor litt tidlig å si noe om resultatet av applikasjonen, og om det faktisk kan påvise autisme. Denne typen forskning krever en del tid og flere brukertester for at det skal være mulig å få noen klare resultater. 6
Innholdsfortegnelse HOVEDPROSJEKT... 2 Forord... 4 Sammendrag... 6 Innledning... 10 Produktdok umentasjon 1. Beskrivelse av produktet... 10 1.1 Sammendrag... 10 1.2 Standardsekvens... 13 1.3 Peekaboosekvens... 13 1.4 Auditiv sekvens... 13 1.4 Flervalgssekvens... 14 2. Kravspesifikasjon... 15 2.1 Funksjonelle krav... 15 2.2 Ikke-funksjonelle krav:... 16 2.3 Oppdateringer og endringer til krav... 17 3. Programmering... 18 3.1. Android... 18 3.2. Java... 18 4. Database... 19 4.1 Tabeller... 19 4.1.1 Person... 19 4.1.2 Sekvens... 19 4.1.3 PersonSekvens... 19 4.1.4 SekvensTid... 19 5. Videreutvikling av produktet... 20 6. Brukerveiledning... 21 6.1 Installasjon av programmet... 21 6.2 Trykkeforståelse... 21 6.3 Oppstart... 22 6.4 Lagre og slette person... 22 6.5 Visning av sekvensinformasjon... 23 6.6 Innstillinger... 24 6.7 Kjøring av sekvens... 25 7
6.7.1 Standardsekvens... 25 6.7.2 Peekaboosekvens... 27 6.7.3 Auditiv sekvens... 29 6.7.4 Flervalgssekvens... 30 7. Brukertesting... 33 7.1 Veileder... 33 7.2 Barn... 33 Prosessdokumentasjon 1. Innledning... 35 1.1 Om gruppen... 35 1.2 Definisjon av oppgaven... 35 2. Bakgrunn... 35 2.1 Oppdragsgiver... 35 2.2 Autisme... 36 2.3 Teknologi... 36 2.3.1 Valg av oppgave... 36 2.4 HiOA veileder... 37 3. Mål og rammebetingelser... 37 4. Planlegging... 38 4.1 Arbeidsplan... 38 4.2 Fremdriftsplan (Gant diagram)... 39 4.3 Risikoplan... 40 Startprosess... 41 5. Prosess/analyse og arbeidsmetode... 41 5.1 Valg av utviklingsmetoder, arbeidsmetoder... 41 5.2 Samarbeid... 42 5.3 Valg og Prioriteringer... 42 5.3.1 ios vs Android... 42 5.3.2 Animerte Gif-filer... 43 5.3.3 Tilfeldig trykk på skjermknappene... 43 6. Utviklingsfaser... 44 6.1 Forstudie... 44 6.2 Programmering... 44 6.3 Prototyper... 44 8
6.3.1 Første prototype... 44 6.3.2 Andre prototype... 45 6.3.3 Tredje prototype... 45 6.3.4 Fjerde prototype... 46 6.3.5 Femte prototype... 46 6.3.6 Beta v1.0... 46 6.3.7 Beta v1.1... 46 6.4 Kodestruktur... 47 6.5 Brukergrensesnitt... 55 7. Utviklingsverktøy... 58 7.1 Microsoft Project 2010 (logo)... 58 7.2 Eclipse og Android SDK (logo)... 58 7.3 Dropbox (logo)... 58 7.4 Google Docs (Nå Google Drive) (logo)... 59 7.5 Saros (logo)... 59 7.6 AVS video converter (logo)... 59 7.7 Samsung Galaxy Tab 10.1 (logo)... 60 8. Modellering... 61 8.1 Klassediagram... 61 8.2 Sekvensdiagram... 62 9. Avslutning og Konklusjon... 65 10. Kilder, referanser, vedlegg... 66 9
Produktdokumentasjon Innledning Dette dokumentet består av produktdokumentasjonen til hovedprosjektoppgaven vår. Produktet vi har laget er en applikasjon som skal brukes i forskningen til oppdragsgiver, Lars Klintwall. Applikasjonen er beregnet på barn mellom 8 og 20 måneder, og skal brukes for å se etter tidlige tegn på autisme. 1. Beskrivelse av produktet 1.1 Sammendrag Denne delen av rapporten beskriver produktet i detalj. Det vises også til alle muligheter og funksjoner ved hjelp av bilder og forklaringer. Først forklarer vi menyen og hvordan den skal brukes og navigeres i. Deretter forklarer vi innstillingene. Så kommer vi til visning og forklaring av alle sekvenstypene. De blir forklart i rekkefølge fra venstre til høyre, sett fra menyen inne i programmet. Det er også i denne rekkefølgen de ble utviklet av gruppen. Programmet er laget slik at når man starter opp, vises menyen til programmet. Her kan vi starte programmet og registrere testpersoner. Når det velges en person får vi fram et valg mellom de ulike sekvensene, og en liste med resultater fra tidligere tester. 10
1. Søkefelt for å søke opp en eller flere personer som har blitt testet. 2. Liste over testpersoner. 3. Knapp tar deg videre til siden der du legger til nye testpersoner. 4. Knapp for å avslutte programmet. 5. Informasjonsfelt om valgt testperson. 6. Valg over sekvenser. 7. Knapp som tar deg videre til innstillingsmenyen. 8. Liste over tidligere sekvenser. 9. Liste over antall trykk på de intervallene på en valgt sekvens i sekvenslisten(8). 10. Sprettoppmeny for å velge antall intervaller i en sekvens. 11. Innskivningsfelt for antall sekunder hvert intervall skal ha i en sekvens. 12. Knapp for å lagre verdiene angitt i felt 10 & 11. Feltene i listen kan trykkes på for å vise informasjon om den valgte testen. Da vises det hvilket intervall det ble trykket i, og antall trykk innenfor det intervallet. Hvis det ikke ble trykket under et intervall, vises ikke intervallet i resultatlisten. 11
På bildet over ser du en knapp oppe til høyre som heter Innstillinger. Hvis man trykker på den kan brukeren bestemme antall intervaller og hvor lenge hvert intervall skal vare. Man kan velge mellom tre, seks og ni antall intervaller. Det er fordi en sekvens er bygd opp av tre og tre blokker som inneholder en av hver intervalltype: ansikt, mønster, og kontroll. Applikasjonen innholder fire typer sekvenser: 12
1.2 Standardsekvens Tre typer videoer som avspilles i henholdsvis ansikt, mønster og kontroll. Ansiktstypen er en video av en person som ser inn i kamera og smiler og lager grimaser. Mønstertypen er en repeterende bevegelse av en nesten hypnotiserende sort og hvitt mønster. Kontrolltypen er en svart skjerm som står stille. Under avspilling av alle intervalltypene er det lagt et rutenett over skjermen. Rutenettet blir borte ved trykk, men kommer tilbake etter 1 sekund hvis det ikke blir trykket på nytt. Rutenettet er vist på bildet under. 1.3 Peekaboosekvens Denne sekvensen er videoklipp av en person som holder hendene foran ansiktet. Når det blir trykket i skjermen starter videoen og ansiktet vises. Neste intervall er mønster. Her ligger rutenettet oppå videoen som i standard, men videoen er også stoppet. Trykker man på skjermen starter mønstervideoen og rutenettet går bort. I peekaboosekvensen er det ikke kontrolltype. 1.4 Auditiv sekvens Den auditive sekvensen består av ansiktstype og mønstertype, altså ikke noe kontrolltype. Videre er sekvensen laget slik at ved trykk vil ikke bare rutenettet bli borte, men lyden vil også settes opp. I standardsekvensen har videoklippene ikke noe lyd i det hele tatt. I auditiv sekvens er lyden lav først, men ved trykk vil lydnivået justeres opp. På ansiktstypen vil lydsporet være stemmen til personen i videoklippet. I mønstertypen er lyden en form for alarm eller jevn sirene som også får justert lydnivået oppover ved trykk. Hvis det ikke blir trykket på nytt innen 1 sekund, vil lyden justeres ned og rutenettet legger seg oppå bildet igjen. 13
1.4 Flervalgssekvens I flervalgssekvensen vises alle intervalltypene samtidig, plassert som på bildet under. Her går det an å trykke på en type om gangen. Det vil si at hvis du trykker på ansiktstypen vil rutenettet foran ansiktet gå bort. Hvis det blir trykket like etterpå i en annen type vil rutenettet legge seg over ansiktet og bli borte fra den intervalltypen som ble trykket på. På den måten oppfører programmet seg etter hvordan det blir trykket og hvilken intervalltype det har blitt trykket innenfor. Når intervalltiden er over blir det lagt ut tre nye bilder, en av hver type. Men denne gangen har de en ny posisjon på skjermen. 14
2. Kravspesifikasjon 2.1 Funksjonelle krav Brukerkrav Applikasjonen skal ha: En meny Fire typer sekvenser Video Video uten lyd Peekaboo Flervideovalg Funksjonalitet for lagring av personer Funksjonalitet for sletting av personer Mulighet til søk av personer Oversikt over resultater, statistikk Startknapp Avsluttknapp Knapp for legg til personer Knapp for innstillinger Sletting av person Comment [2]: Systemkrav Ved å trykke på legg til person knappen, skal det komme opp to inputfelt: navn og alder Avsluttknappen skal avslutte hele programmet Ved å holde inn navnet på person i sidemeny, skal det være mulighet for sletting av person Ved valg av person skal alle de mulige sekvensene komme opp Det skal være en lytter for sekvensene, som fungerer under kjøring av sekvensene Lytteren skal registrere antall trykk i en sekvens Lytteren skal vise data på hvilket intervall det har blitt registrert trykk For å søke etter en person, skal det være mulig å skrive inn navn i søkefeltet Etter å ha utført en sekvens, skal resultatet komme opp i listen over tidligere sekvenser Ved å trykke på innstillinger, skal det være mulig å endre tid på intervaller i sekvensen, og velge antall intervaller 15
2.2 Ikke-funksjonelle krav: Produktkrav All data skal lagres i en database Krav til brukervennlighet: baseres på barn og er tilpasset denne forskningen(godkjennelse fra oppdragsgiver) Visning av resultater Resultater skal vises systematisk for hver bruker Eksterne krav Krav fra oppdragsgiver, Lars Klintwall Krav om at det ikke skal brukes noe som er ulovlig ifølge skolens regler F. eks rot-tilgang til nettbrett bryter garantien Brukergrensesnitt Skal dekke hele skjermen Tydelig skrift Oversiktlig liste over testpersoner, og deres sekvenser. Nøytral farge i brukergrensesnittet for å ha et profesjonelt utseende. Rammekrav i systemet Backup Gruppen skal passe på at alle dokumenter og kode er lagret, og at det gjort backup av alt. Her ble det brukt: Dropbox Ekstern harddisk 16
2.3 Oppdateringer og endringer til krav Underveis i prosjektet har det kommet endringer til krav i prosjektet, etter ønske fra oppdragsgiver. Endringer av tid på intervallene i sekvensen: I starten av prosjektet bestemte oppdragsgiveren at tiden på intervallene skulle være på 30 sekunder. Senere i prosjektet ble det bestemt at tiden skulle endres til 15 sekunder. Endring av touch funksjonalitet; interaksjon mellom bruker og skjerm: Før var det klikk: registrering av trykk skjer ved å fjerne hånden fra skjermen. Nå touch: registrering av trykk skjer med en gang etter trykk på skjerm. Nye stimuli: bilde og video. Gjennom prosjektperioden har oppdragsgiver kommet med krav om å legge til nye bilder og videoer i sekvensene. Det er han som gir oss bilder/videoer som skal settes i programmet Endringer i resultatside I tidlige versjoner av programmet viste vi resultatene av sekvensene etter hver sekvens. Dette var før vi hadde laget meny, og resultatdata ble ikke lagret separat for hver person. For å gjøre resultatene mer oversiktlig satte vi krav, i fellesskap med oppdragsgiver, om å vise resultatene for hver person i menyen. Ikke strekk ut bilder Oppdragsgiver bestemte at bildene ikke skulle fylle hele skjermen, men at vi isteden beholdt opprinnelig størrelse. Dette var for å få klare resultater på om barnet faktisk trykker på bildet, og ikke bare hvilken som helst sted på skjermen Endringer av stimuli: kontroll typen I start bestod denne typen stimuli av ulike farger; blå, gul, grønn. Etter hvert i prosjektet ble det bestemt av oppdragsgiver at denne typen stimuli skulle kun bestå av svart skjerm. Comment [3]: Disse endringene ble gjort på grunnlag av resultatene fra brukertesting. Oppdragsgiveren mente at disse endringer ville gjøre resultatene mer presise. 17
3. Programmering 3.1. Android Android er et åpent operativsystem som er utviklet av Google. Android er basert på en modifisert versjon av Linux kjernen og en av fordelene med Android er at det er fritt å lage egne applikasjoner. Android har kommet i flere versjoner. Versjon 1 og 2 er begrenset til bruk for smarttelefoner og versjon 3 brukes til nettbrett, mens fra og med versjon 4 bruker smarttelefoner og nettbrett samme operativsystem. 3.2. Java Java er et programmeringsspråk utviklet av Sun Microsystems. Den driver avanserte applikasjoner og spill og inneholder en rekke funksjoner som gjør at språket egner seg spesielt godt for tjenester på internett. Java blir levert med et stort bibliotek av klasser og metoder, blant annet for bygging av grafiske grensesnitt og for kommunikasjon over internett. 18
4. Database Vi har valgt å bruke en database til lagring av dataene fra bruk av applikasjonen. I databasen lagres personene som blir registrert. Lagring av resultater skjer også i databasen. Sekvensene som blir utført lagres med tidspunkt for utførelse. I tillegg til dette lagres antall klikk på skjermen, og hva slags sekvens som blir utført. 4.1 Tabeller Databasen er bygget opp av fire tabeller: 4.1.1 Person Persontabellen inneholder informasjon om testpersonen. Dette gjelder navn, alder og dato for registrering av personen. Vi vet at denne applikasjonen lagrer barn i databasen, men vi følger en grunnleggende modell og kaller derfor tabellen Person. Persontabellen har relasjon til PersonSekvens-tabellen. 4.1.2 Sekvens Sekvenstabellen inneholder informasjon om sekvenstypen og dato for utført sekvens. På samme måte som persontabellen, har sekvenstabellen en relasjon til PersonSekvens-tabellen. Sekvenstabellen har også en relasjon til SekvensTid-tabellen. 4.1.3 PersonSekvens PersonSekvens-tabellen er en konsekvens av databasestruktur som sier at det ikke skal være mange til mange relasjon mellom to tabeller. Denne tabellen binder ulike sekvenser til en gitt person. På denne måten kan vi fremstille sekvensene en person har hatt. Tabellen består av sekvensid, personid, sekvenstype og dato for når sekvensen ble gjort. 4.1.4 SekvensTid SekvensTid-tabellen inneholder tidspunkt for interaksjon, hvilket intervall i sekvens og kategori. 19
5. Videreutvikling av produktet Oppdragsgiver, Lars Klintwall, har kommet med et ønske om å fortsette å utvikle denne applikasjonen. Dette er på grunnlag av flere brukertester, og nye ideer fra oppdragsgiver som kan hjelpe forskningen hans. Vi har diskutert denne muligheten, og har lyst til å videreutvikle denne applikasjonen i sommer. Oppdragsgiver vil holde oss oppdatert på mail i tiden fremover. Muligheter til videreutvikling av programmet: Opptak av foreldre til videoer for sekvensene: Dette blir slik som det ble diskutert i start av prosjekt. Se under avsnitt om startprosess i prosessdokumentasjon. Sekvens med to bilder; mønster og ansikt Ved å trykke på bilde, blir den forstørret eller fremhevet, slik at barnet kan se litt mer nøye på det valgte bilde. Treningssekvens: Dette går ut på å lage en testsekvens til å lære barnet hvordan den trykker på skjerm, en slags opplæringssekvens. Poenget er at barnet skal skjønne hvordan den skal trykke på skjermen. Lyd på mønster intervall nå har kun en sekvens med ansikter som har lyd Bilder i sekvenser skal kunne komme opp helt tilfeldig. Foreløpig er det slik at bildene er indeksert i en viss rekkefølge, slik at samme rekkefølge på bilder vises hver gang programmet kjører. Opptak av barnet mens det testes Dette blir for å se hvordan barnet reagerer under utførelse av testene. 20
6. Brukerveiledning I denne delen blir det beskrevet hvordan man skal installere programmet, hvordan en bruker skal bruke programmet, og det blir vist alle funksjoner som er mulig. 6.1 Installasjon av programmet For å installere programmet laster man inn Chirp.apk til programmet. Apk-filen ligger på CDen som vedlegg. Ved å bruke en filutforsker som for eksempel ASTRO file manager kan man åpne apk-filen og installere applikasjonen. Da vil programmet bli installert, med mindre det ikke kommer en feilmelding. Det som står igjen er å legge inn videoene som blir brukt i sekvensene. De finner du i CD pakket sammen i en zip-fil som heter Movies.zip. Pakk ut alle videoene før du overfører dem til emulatoren eller nettbrett. Filene skal ligge i mappen Movies. I emulatoren finner du Movies mappen i /mnt/sdcard/movies. For nettbrett legger du filene i /mnt/sdcard/movies-mappen på minnekortet. VIKTIG: Sørg for å legge videofilene i riktig mappe eller så vil ikke applikasjonen fungere! 6.2 Trykkeforståelse Først skal vi forklare litt rundt hvordan trykkingen fungerer i applikasjonen. Når man er i menyen bruker man enkle trykk for valg av lagret barn og på alle knapper og lister. I listen over testbarn er det mulig å gjøre et langt trykk, at man trykker og holder inne. Under kjøring av sekvens, uansett type, blir det bare registrert trykk hvis man trykker i et felt i midten. Feltet er usynlig, men det ligger som et lag på toppen av videoen. I det neste bilde er trykkfeltet markert med en rød ramme for alle intervalltypene. 21
6.3 Oppstart Slik ser det ut ved oppstart: Her er det to knapper som gjør følgende: Legg til en person Avslutte programmet 6.4 Lagre og slette person Når man trykker på legg til person knappen kommer dette frem: Fyll inn feltene med ønsket data, og trykk på legg til person oppe til høyre. Da vil personen bli lagret. Når det er gjort ser man med en gang at personen blir lagt til i listen til venstre som vist i bildet under. Her la vi til Atle som er 12 måneder gammel. 22
For å slette en person fra programmet trykker du på personen du skal slette. Hvis det er vanskelig å finne personen kan du bruke søkefeltet som du ser i bildet over. Når du har funnet personen trykk og hold inne på personen i listen. Da vil du se denne: Trykk på den og personen vil være slettet fra programmet. All lagret data tilknyttet den personen vil også bli fjernet. 6.5 Visning av sekvensinformasjon Ved å trykke på en person vil man se bildene som vist på bildet under. Her er det trykket på bildet lengst til venstre som representerer standardsekvensen. For å starte den valgte sekvensen trykker man på den grønne startknappen. Vi har fire mulige sekvenser å velge mellom; Standard-, Peekaboo-, Auditiv-, og Flervalgssekvens. (Opplistet fra venstre mot høyre på bildet over). Det har blitt kjørt en sekvens. For å se antall trykk og hvilke intervaller det har blitt trykket innenfor, velg personen du skal undersøke. Da ser man dette igjen: Legg merke til at det nå er et felt under «tidligere sekvenser». 23
Trykk på den og videre informasjon om den sekvenskjøringen vil bli vist som på bildet under: I dette eksempelet ble det trykket en gang i hvert intervall. 6.6 Innstillinger På bildet over ser du også en Innstillinger-knapp nede til høyre. Ved å trykke på den ser du dette: I innstillinger kan du sette antall intervaller og hvor lenge hvert intervall skal vare. Trykker man på feltet for antall intervaller dukker denne opp: Velg hvor mange intervaller som ønskes, og hvor lenge de skal vare, og det vil bli lagret når man trykker på lagreknappen. 24
6.7 Kjøring av sekvens Programmet har fire typer sekvenser. I denne delen av brukerveiledningen forklares det hvordan å starte og bruke alle sekvensene. Sekvensene blir forklart i rekkefølge ut ifra menylinjen fra venstre mot høyre. 6.7.1 Standardsek vens Nå skal vi demonstrere en sekvenskjøring av type standardsekvens. Her har vi valgt standard sekvens(bildet under), og trykker på start-knappen. Da vil bildet over fylle opp skjermen. Om det ikke blir trykket vil gitteret legge seg oppå bildet. 25
Det er vist på bildet over. Deretter vil neste intervall starte etter så lang tid som er angitt i innstillingene. Det er fast rytme på hva slags type intervall som kommer. Først ansikt, så mønster, og til slutt en kontrolltype som bare er en blank skjerm. I bildet over ser vi en av type mønster uten gitter. 26
På det neste bildet er det blitt lagt på gitteret, slik som på ansiktstypen, fordi det ikke har blitt trykket. Etter alle de tre typene har gått gjennom vil enten sekvensen avslutte eller fortsette ut ifra hvordan innstillingene er stilt inn. 6.7.2 Peekaboosekvens Får å starte peekaboosekvensen velger man bildet nummer to fra venstre, og trykker på startknappen. Sekvenstypen Peekaboo består av en eller flere videoer hvor en person har skjult ansikt. 27
Når barnet trykker på skjermen vises ansiktet som du ser på bildet under. Det neste intervallet består av mønstertypen. Denne fungerer på samme måte som ansikt. 28
Videoen starter, men så stopper den etter en liten stund. Hvis det blir trykket på skjermen vil videoen starte igjen. 6.7.3 Auditiv sekvens Får å starte denne sekvensen trykker du på bildet som vist på bildet under, slik at det står Du har valgt: Auditiv. Ved auditiv sekvens spilles det av videoer, på samme måte som standard, med lyd. Forskjellen mellom standard og auditiv er at ved trykk vil lydnivået til videoen settes høyt opp. Gitteret går bort på samme måte som i standard. 29
6.7.4 Flervalgssekvens Nå skal vi se på flervalgssekvensen (multiple). For å starte flervalgssekvensen trykk på personen som skal testes og der etter på sekvensbildet som er lengst til høyre. Da vil det stå: Du har valgt:multiple. Trykk på den grønne startknappen og sekvensen vil starte. Når sekvensen starter vil du se noe som ligner på dette: 30
Her ligger alle intervalltypene på en vannrett linje. Trykker man på mønster- eller ansiktstypen vil gitteret bli borte på den som blir trykket på, som vist på bildet under. Hvis det blir trykket på en annen type enn den som tidligere ble trykket på, vil gitteret bytte plass. Det kan du se på bildet under. 31
Når tiden går ut, som settes i innstillinger, vil intervalltypene bytte plass på skjermen. Intervalltypene og gitteret reagerer på samme måte som forklart tidligere i dokumentet. Når alle intervallene er fullført kommer du tilbake til menyen og kan derfra se på resultater. 32
7. Brukertesting 7.1 Veileder Hovedprosjektets veileder, Larissa Sjarbaini, var ikke med på å prøve selve applikasjonen men hun ble forklart hvordan den fungerer. Sjarbaini fulgte også med på utviklingen underveis og på prototypene. 7.2 Barn Programmet ble prøvd på 20 barn. Det ble brukt forskjellige prototyper avhengig av hvor langt programmet hadde kommet. Variasjonen var stor på hvordan barna håndtererte nettbrettet. Comment [4]: 33
Noen viste interesse fra første stund, mens andre heller ville se på mamma eller andre ting i rommet. Når den først fanget barnets oppmerksomhet var det tydelig at barnet forstod at det skulle bli trykket på skjermen for å se bildet klart. Likevel så var det også noen som bare trykket og hamret på skjermen. Her er et barn som tester stimuli. Bildet over viser en av de tidligere prototypene som ble brukt til testing. 34
Prosessdokumentasjon 1. Innledning Dette dokumentet inneholder prosessdokumentasjon for hovedprosjekt ved HiOA 2012, ved utdanningsretning for dataingeniør. Målet med dette dokumentet er å presentere prosessen til prosjektet. Ved en eventuell videreutvikling av produktet, vil det også være nødvendig, blant annet fordi det viser til bakgrunn til prosjektet og avgjørelser som ble gjort underveis. 1.1 Om gruppen Gruppen består av 5 studenter som går siste år dataingeniør; Christian Salater, Tola Sarzali, Magne Hjermann, Zunaira Afzal og Waleed Abtidon. Hjemmesiden for hovedprosjektet vårt kan ses ved å trykke på denne linken: http://www.stud.hio.no/~s163469/hovedprosjekt/index.html. 1.2 Definisjon av oppgaven Oppgaven vår gikk ut på å lage en applikasjon for en Samsung Galaxy Tab 10.1 av typen Android. Denne applikasjonen har til hensikt å hjelpe med å påvise autisme hos småbarn. Dette skal gjøres ved en rekke stimuli, med bilde og video. De ulike sekvensene med stimuli skal kunne si noe om interessenivået til et barn, og dette skjer ved at barnet trykker på skjermen. 2. Bakgrunn 2.1 Oppdragsgiver Oppdragsgiveren for dette prosjektet er Lars Klintwall, som er psykolog og doktorgradsstipendiat. Det vil si at han har mulighet til å bruke denne oppgaven til sin doktorgrad. Han jobber med forskning relatert til autisme. Han ønsker å bruke denne applikasjonen til å påvise autisme hos barn i en tidlig alder, og teste barn med og uten autisme for å se hva slags stimuli de foretrekker. Denne applikasjonen skal bli testet på barn mellom 8 og 20 måneder. Testing av barn som allerede har blitt diagnostisert med autisme er eldre enn 20 måneder, men de har en IQ nivå som er like stor som et normalt barn i ett års alderen. Oppdragsgiver ønsket å få laget denne applikasjonen på et nettbrett og kontaktet derfor HiOA. 35
2.2 Autisme Autisme er en utviklingsforstyrrelse, som også betegnes som en gjennomgripende utviklingsforstyrrelse (GUF). Autisme fører til negative virkninger på utviklingen av sosiale evner, språk og kommunikasjon. Personer som har autisme viser også tydelige atferdsforstyrrelser. De viser litt annerledes reaksjoner til omgivelsene enn det normale mennesker ville ha vist, og de har ganske snevre interesser. Symptomene ved autisme kan vanligvis påvises innen de første tre leveårene til et barn. Likevel er det slik noen ganger at det oppdages senere i livet. Det er viktig at dette påvises så tidlig som mulig, for at det ikke skal påvirke barnets utvikling i så stor grad. Jo tidligere det blir påvist, jo tidligere kan vi hjelpe med å tilpasse forhold for barnet. Kommunikasjon med mennesker og andre sosiale evner utvikles i et tidlig stadium hos barn, og derfor er det viktig å tilrettelegge for dette hos barn med autisme så tidlig som mulig. Denne tilstanden er tre til fire ganger så vanlig hos gutter enn hos jenter. Likevel varierer symptomene fra person til person. Hos noen er det av stor betydning, og det virker veldig utviklingshemmende, mens for andre så har det ikke så stor påvirkning i deres liv. 2.3 Teknologi Denne oppgaven kombinerer dagens teknologi med forskning, og er dermed veldig aktuelt for fremgang innen forskningen til Lars Klintwall. Applikasjonen skal gjøre det lettere å håndtere autisme, ettersom det skal kunne bli påvist i et tidlig stadium. Bruk av nettbrett til denne forskningen vil gjøre at resultatene blir mer tilgjengelig for ulike brukergrupper. På grunn av interaksjon mellom bruker og nettbrett(touch), vil det også være lettere å dokumentere resultatene på en mer oversiktlig måte. Det har blitt brukt flere metoder til påvisning av autisme gjennom årene. En metode som blir brukt kalles for eye-tracking. Denne metoden går ut på å vise bilder manuelt til barnet, og se hvor de viser mest oppmerksomhet. Det er denne ideen som blir brukt i applikasjonen også, og målet er å se om det virker bedre med en slik applikasjon, enn manuelt. Applikasjonen har bare til hensikt å påvise autisme. Videre går forskning til Lars Klintwall på å tilpasse utvikling av barn med autisme. Hvis det blir påvist tidlig, er det lettere å håndtere det slik at det får minimalt effekt på barnets utvikling ellers. 2.3.1 Valg av oppgave Denne oppgaven virket veldig spennende og utfordrende, og det var grunnen til at vi ble interessert i å kontakte oppdragsgiver. Det første møte med oppdragsgiver var på 30. november 2011. På dette møte ble vi kjent med oppdragsgiveren, Lars Klintwall. Vi diskuterte oppgaven, og hvordan vi kunne tenkt å lage den. Alle på gruppen kom med innspill, og vi bestemte ganske raskt for at dette var oppgaven vi ville jobbe med til vårt hovedprosjekt. 36
2.4 HiOA veileder Veilederen vår ved HiOA var Larissa Sjarbaini. Vi hadde møte med henne hver tirsdag, med unntak på røde dager, gjennom hele prosjektperioden. Larissa arrangerte et øvelsesforedrag for oss og sammen med noen andre hovedprosjektgrupper. Det var et kort foredrag om oppgaven vår og hvor langt vi hadde kommet. Opplegget var ment som en øvelse på å holde foredrag og presentere oppgaven foran andre. 3. Mål og rammebetingelser Målet med denne oppgaven er å lage en applikasjon som skal brukes til å påvise autisme hos barn. Det vil si at applikasjonen klarer å registrere og gi riktige resultater av interaksjon mellom barn og stimuli fra nettbrett. Slik at det er mulig å finne ut av om det er en sammenheng mellom preferanser til stimuli og autisme tidligere. Det er vanligvis ikke mulig å påvise autisme for barn under 3 år. Denne applikasjonen som vi har utviklet skal brukes for å påvise autisme hos barn enda tidligere. Rundt ett års alderen. Fordelen med å finne en tidligst mulig diagnose på autisme gjør at man kan starte behandling tidligere. Hensikten med å lage denne applikasjonen til en nettbrett, er å se om dette er en bedre måte å teste barn enn de andre metodene som har blitt brukt til nå. Etter første møte med oppdragsgiver, Lars Klintwall, hadde vi diskutert krav til oppgaven: Comment [5]: Den skal bestå av en sekvens som skal inneholde flere bilder og videoer, med ansikter og mønster. Registrering av barnets frekvens av interaksjon. Lagring av registrerte handlinger(brukerdata/brukerinput). Lage statistikk over resultatene. Opptelling av antall trykk. Tidsteller; tid mellom sekvensene. Mulighet av opptak: Brukere kan selv legge inn bilder og video. Håndtering av bilder; hente bilder og filmer fra mapper. Bildefremviser (bildevideo), lage en type galleri. Lyd. Når det gjaldt krav til hvordan vi skulle implementere dette, fikk vi lov av oppdragsgiver til å komme med innspill. Gjennom startfasen i prosjektet ble det gjort noen endringer i krav med tilføying og fjerning av krav, f.eks. opptaksmulighet av foreldre som stimuli. Disse ble diskutert og fastsatt i felleskap mellom oppdragsgiver og gruppen. En oppdatert og fullstendig kravspesifikasjon har vi skrevet i produktdokumentasjonen. Siden vi jobbet med denne oppgaven til vårt hovedprosjekt på HiOA, hadde vi en allerede fastsatt tidsramme. Oppgaven skal være ferdig innen 30.5.2012. Likevel har oppdragsgiveren 37
sagt at det vil bli mulighet for oss å jobbe med å videreutvikle applikasjonen hvis det blir behov etter prosjektperioden også. Når det gjelder kostnadsbetingelser så har vi ikke hatt noen bestemte tall. Oppdragsgiveren har selv tatt ansvar for å kjøpe et nettbrett til testing av programmet, og andre kostnader dersom det blir behov for det under arbeidet, f. eks kjøp av nødvendig litteratur. 4. Planlegging I planleggingsfasen lagde vi arbeids- og fremdriftsplan, slik at vi kunne sette opp en oversikt over alt som skal gjøres gjennom prosjektet samt hvilke tidsfrister vi må holde for å få prosjektet utført tidsnok. Denne planen ble endret litt underveis i prosjektet, ettersom det ble gjort noen få endringer i krav, men det hjalp oss likevel med å ha kontroll gjennom prosjektet. 4.1 Arbeidsplan Lage 1. prototype 25.01.2012 En sekvens som teller antall trykk med et bilde/video i bakgrunn, m/tidspunkt Forprosjektrapport 27.01.2012 Arbeidsplan 27.01.2012 Fremdriftsplan 27.01.2012 Kravspesifikasjon 24.02.2012 Lage 2. Prototype Funksjonalitet: Lage flere forskjellige sekvenser med bilder, video(med en angitt tidsramme) Lagring av resultater Send resultat for hver sekvens til en database Diagrammer/modeller 15.03.2012 Oppdatert kravspesifikasjon 16.04.2012 Prosessrapport 27.04.2012 Videre funksjonalitet til applikasjonen: Begrenset trykkområde 10.04.2012 Meny 20.04.2012 Alternative sekvens( Peekaboo ) 20.04.2012 Sekvens med Lyd 20.04.2012 Lagring av resultater 26.04.2012 Statistikk, (filtrering) 26.04.2012 Fjerde sekvens 04.05.2012 Ferdig produkt 09.05.2012 Produktrapport 25.05.2012 Testdokumentasjon 18.05.2012 Brukerdokumentasjon 18.05.2012 Lage Plakat 29.05.2012 Fremføring lage presentasjon 10.06.2012 38
4.2 Fremdriftsplan (Gant diagram) Vi har laget en fremdriftsplan som viser arbeidsoppgavene som gruppen utfører og dato for når det skal være utført. Vi har laget denne planen for å strukturere arbeidet og ha oversikt over hva gruppen skal gjøre til enhver tid. For å lage Gant diagram brukte vi Microsoft Project 2010. Valget falt på dette verktøyet fordi det brukes ofte i arbeidslivet og det er enkelt å tegne diagrammer med Microsoft Project. 39
4.3 Risikoplan Risikoplanen er et hjelpemiddel som gir gruppen oversikt over hva som kan gå galt i løpet av et prosjekt for å kunne hindre trusler og være forberedt på dersom noe skulle ha gått galt. Risikoplanen inneholder beskrivelse av risikoen, sannsynligheten for at risikoen inntreffer, vurdering av risikoen, respons og måten man kan forebygge risikoen på i tilfelle den skulle inntreffe. Risiko Sannsynlighet Vurdering Respons Forebygging Manglende motivasjon Middels Medlemmer mangler motivasjon og utsetter ting som må gjøres innen fristen. Utsettelser av oppgaver kan føre til konflikter med milepælplanen. Medlemmene må jobbe aktivt med prosjektet, ikke utsette frister og holde kontakt med gruppa. Tap av data Lav Tekniske problemer som fører til tap av data. Jobbe så effektivt som mulig Lagre og ta backup. Bruke "Google Docs" for styringsdokumenter og Dropbox for lagring av filer. Gratis passasjerer Lav Gr uppemedlemmer som ikke gjør arbeidsoppgavene sine God kommunikasjon i gruppen, og å motivere de som er umotivert Medlemmene må motivere hverandre og ha lagånd. Sykdom/ fravær Middels Gr uppemedlem rammes av sykdom eller er ikke til stedet. Fordele arbeidsoppgaver mellom friske medlemmer eller dele dokumenter på Dropbox slik at personen som er syk kunne jobbe hjemmefra. Vanskelig å forebygge sykdom. Ellers bør man spise sunt og holde seg frisk. Tap av gruppemedlem Lav Gr uppemedlem faller fra studiet. Arbeidsoppgaver fordeles på nytt. Bygge god stemning innad i gruppen Konflikter Lav Det oppstår konflikter mellom gruppemedlemmer eller uenighet om arbeidsmåten. Gr uppa bør skape lagånd og inkludere alle medlemmene i fellesskap. Ha et godt gruppemiljø og unngå krangling og man skal være ærlig hvis man er uenig med de andre medlemmene. 40
Startprosess Arbeidsprosessen til prosjektet begynte allerede etter første møte med oppdragsgiver i slutten av november. Oppdragsgiver viste fram produktet han så for seg med en PowerPoint presentasjon. I denne presentasjonen hadde han et utgangspunkt av forskjellige stimuli sekvenser som vi skulle bygge på videre. Powerpoint presentasjonen som oppdragsgiveren viste er satt som vedlegg. Applikasjonens hensikt er å vise sekvenser bestående av bilder og videoer. Det som vises på skjermen skal fange barnets oppmerksomhet, og barnet skal trykke på skjermen av det han/hun finner interessant. Vi bestemte oss raskt for hvilket nettbrett som vi fant best å programmere i, og hvilket utviklingsverktøy som var nødvendig for implementering(se 5.3.1 ios Vs Android). Innlevering av første prototype ble satt til 25.januar. Hensikten med å ha denne prototypen klar så tidlig var å gi en viss innsikt for hvordan programmet skulle operere. Det var også en motivasjon for oss å lære strukturen for Android programmering siden dette da var nytt for oss. 5. Prosess/analyse og arbeidsmetode 5.1 Valg av utviklingsmetoder, arbeidsmetoder Scrum Scrum er en agil utviklingsprosess. Det er stor fokus på oppgaver, der deltakerne blir oppfordret til å løse problemer selv, og det gis ikke noen fastbestemt metode for å løse oppgaven. Gruppelederen kalles scrummaster, og har en del ansvar, men likevel er det slik at ansvaret fordeles ganske likt mellom alle i prosjektgruppen. Prosessen starter med at prosjektgruppen og oppdragsgiveren lager en liste over alt som skal gjøres, og lager en slags kravspesifikasjon. Arbeidsperioden er delt opp i flere intervaller, som hver kalles for en sprint. Disse sprintene går gjerne over en tidsperiode på 30 dager. Videre lages det en sprintlogg, en aktivitetsliste, for alt som skal gjøres innen hver sprint. Den daglige scrum innebærer at prosjektgruppen møtes en gang hver dag for å gi hverandre statusoppdateringer. Etter hver sprint gjør prosjektgruppen en demonstrasjon av det som er laget eller gjort til nå. 41
Arbeidsprosess: På første møte mellom prosjektgruppen og oppdragsgiver, diskuterte vi oppgaven og satte opp en liste over alle krav til programmet som skulle utvikles. Til forskjell fra en normal sprint, jobbet vi med intervaller på to eller tre uker. Dette var mest på grunn av at prosjektet vårt har så kort tidsramme i forhold til de fleste andre prosjekter som utføres i arbeidslivet. Etter hver møte med oppdragsgiver satte vi opp en aktivitetsliste for hva som skulle gjøres til neste møte. Gruppen møttes flere ganger i uka for å jobbe med prosjektet, og oppdatere hverandre. Under utvikling av applikasjonen utnyttet vi oss mye av par-programmering. Denne metoden var veldig nyttig for vår egen del. Det gjorde at vi hadde bedre oversikt over programmeringen gjennom prosjektperioden. Vi møttes to til tre ganger i uken til å jobbe med programmeringsdelen. 5.2 Samarbeid Vi har samarbeidet ved hjelp av scrum-metoden. Da har vi hatt møter hvor vi har sett på hva som er gjort og hva som skal gjøres. Etter møtene løste vi problemer i par eller individuelt. Når vi samlet oss til neste møte presenterte vi hva vi hadde gjort for hverandre, og kritiserte og innførte det til resten av prosjektet. 5.3 Valg og Prioriteringer 5.3.1 ios Vs Android Det første viktige valget vi gjorde som gruppe var å velge hvilken plattform vi skulle utvikle for. Oppdragsgiver ville ha produktet sitt på et nettbrett. Vi hadde da valget mellom å utvikle til Apple sitt produkt: ipad, eller et nettbrett som bruker Google sitt operativsystem: Android. Vi valgte å bruke operativsystemet Android som plattform. Dette er fordi det finnes mer utviklingsverktøy for Android på Windows enn for, for eksempel, ipad. Der er det litt begrenset hva de har tilgjengelig av utviklingsverktøy utenfor deres Mac operativsystem. Det finnes også et større utvalg når det gjelder nettbrettutgaver til Android. De finnes i både store og små utgaver, med eller uten 3G. Nettbrettet som vi har valgte i fellesskap med oppdragsgiver var Samsung Galaxy Tab 10.1. En annen fordel med å velge Android som plattform, er at programmeringsspråket som brukes her er Java. Fordelen med dette er at alle vi på gruppen er kjent med språket. Det hjelper oss med å utvikle videre forståelse av applikasjonsutvikling. Vi kunne dermed også bruke Eclipse, et utviklerverktøy vi har blitt kjent med gjennom studiet. En alternativ løsning til oppgaven ville ha vært, som nevnt, å lage applikasjonen til ipad, med operativsystemet ios. Dette krever andre utviklingsverktøy som vi ikke er kjent med. I tillegg er det flere begrensninger på hvor mye av nødvendig funksjonalitet vi kunne ha oppnådd på en slikt nettbrett. 42
En annen ulempe med dette er at det er dyrere å lage applikasjonen for ipad. Her er det en årlig kostnad på $99 USD. Android er i utgangspunktet gratis, men for å legge programmet ut på Android Market ville det ha vært en engangsavgift på $25 USD. Siden produktet vi lager ikke skal være tilgjengelig for alle, er ikke det nødvendig. Så hvis vi legger vekt på økonomisk lønnsomhet, så er Android et bedre valg. En fordel med ios er likevel at det er veldig populær nå for tiden. Det kunne også ha vært en god erfaring for oss å prøve forskjellige programmeringsspråk. Programmeringsspråket som brukes til ios, er Objective C, et programmeringsspråk som er likt C, med ny syntaks og kodeord. 5.3.2 Animerte Gif-filer Vi fikk animerte gif bilder av filformatet.gif fra oppdragsgiver for å bruke som stimuli i mønsterintervallene i sekvensen. Dette var vanskelig å få til fordi Android har veldig begrenset støtte for å vise animasjonen i bildet. Som løsning på dette problemet konverterte vi bildene til videoer med formatet mp4, og viste disse på samme måte som videofilene i personintervallene. 5.3.3 Tilfeldig trykk på skjermknappene Vi fikk tilbakemelding etter første brukertesting at det hendte at barna kom bort i skjermknappene som er navigasjonsknapper til systemet. Disse knappene ble ganske forstyrrende under testing, da de blant annet lukket programmet og førte til at testen ikke ble fullt gjennomført. En mulighet for å fikse dette var å fjerne funksjonaliteten til eller skjule knappene under kjøring av programmet. Men for å få det til var det nødvendig å skaffe rot-tilgang til systemet. Vi ville da hatt mulighet til og direkte endre funksjonalitet til skjermknappene. Men ved å roote ville vi da ha brutt garantien på nettbrettet. Vi forhørte oss med hovedprosjektansvarlig om dette likevel var greit å gjøre, men fikk beskjed at det ikke var lurt siden dette er et offisielt prosjekt tilknyttet skolen, og brudd på regelverk. Vi kom til slutt frem til det og fysisk hindre tilgang til knappene var den beste løsningen. Dette ble gjort med flere lag teip over skjermknappene. Vi la da til knapper i menyen i programmet for å erstatte nettbrettets mangel på skjermknappene. Nettbrettet skulle bare brukes til å teste ut programmet. 43
6. Utviklingsfaser 6.1 Forstudie Forprosjekt Forprosjektet vårt er skrevet i startfasen av prosjektet. Den inneholder en innledende beskrivelse av prosjektet, og en analyse av oppgaven ved start av prosjekt. Dette har vært en viktig del av planleggingsfasen, fordi det har hjulpet oss med å få oversikt over selve oppgaven ganske tidlig. Se vedlegg 1 Comment [6]: Comment [7]: Androidprogrammering For å lage denne applikasjonen har vi lært oss Android programmering. Dette var nytt for oss siden vi ikke hadde jobbet med å lage slike programmer før. Noe som likevel var til vår til fordel, var at vi skulle bruke programmeringsspråket java som vi har lært oss igjennom studiet. På grunn av dette ble det enklere for oss å sette oss i det. Flere av gruppemedlemmene hadde også faget Applikasjonsutvikling som valgfag dette semesteret. Dette faget gikk ut på å lære å utvikle programmer til Android, og var derfor veldig nyttig for oss til hovedprosjektet. Andre steder som har vært med på opplæringen har vært AndroidDevelopers og StackOverflow dersom vi har hatt spørsmål om gjennomførelse 6.2 Programmering Android programmering er en utvidelse av Java programmering med et eget klassebibliotek som gjør en applikasjon kompatibel med Android-baserte enheter. Activity, Service, BroadcastReceiver er blant flere klasser fra biblioteket som kan brukes av Java klassen, og disse initialisere metoder som referer til Android biblioteket. En applikasjon har en aktivitet som initialiserer funksjoner OnCreate(). Denne metoden viser hva som skal startes ved oppstart av aktivitet. Utseende og interface defineres av en eller flere XML-oppslag. Her defineres knapper, felter, farge og ramme for hvordan programmet skal se ut. Applikasjonen kan ha flere aktiviteter, men bare en aktivitet som kjører om gangen. Disse aktivitetene kan starte hverandre og kjøre i bakgrunn eller lukkes ved overgang med onstop() metode. 6.3 Prototyper 6.3.1 Første prototype Den første prototypen inneholdt en video av et av gruppemedlemmene. Dette var for å teste hvordan vi kunne legge inn videoer i sekvensen. Videre laget vi en funksjon for å registrere antall trykk på skjermen. Prototype 1 var skrevet i Android versjon 2.3 API nivå 9 (for smarttelefoner med 3,7 skjerm). 44
6.3.2 Andre prototype I denne prototypen brukte vi Gif-filer som format til bilder i sekvensen. Dette var ikke særlig optimalt, pga begrenset støtte for animerte Gif-filer. Gif-filen strakk vi for å dekke hele skjermen. Prototypen hadde versjon 3.0 API nivå 11 (for nettbrett). Vi bruker denne versjonen for resten av prototypene. 6.3.3 Tredje prototype I den andre prototypen hadde vi laget den første sekvensen; denne var uten fade funksjonalitet og uten lyd. Det er denne sekvensen vi har videreutviklet til det vi kaller standardsekvens nå. Den består av de tre intervalltypene; ansikt, mønster, og kontroll. De første videoene var av litt dårligere kvalitet når det gjelder lyd og bilde. Eksempel på gammel versjon av ansiktstypen Eksempel på gammel versjon av kontrolltypen 45
6.3.4 Fjerde prototype I denne prototypen brukte vi videoer, med mp4 format, i stedet for bilder. Grunnen til det var at det er ikke er noe særlig støtte av kontroll over avspilling av Gif-filer. Det var derfor mye lettere å konvertere filene til mp4-filer som er et kjent format for håndholdte enheter fordi filene ikke bruker mye diskplass og oppløsningen passer til skjermen. Vi gjorde denne konverteringen ved hjelp av et program som heter AVS Video Converter. Vi la på en fadefunksjon som gjorde at lysstyrken ble lavere hvis man ikke trykket på bildet innen tre sekunder. Oppdragsgiver mente også at de animerte kontrollbildene var for stimulerende til å være en kontrolldel, dette endret vi til å bli til en solid farge i stedet. 6.3.5 Femte prototype Her retter vi på sekvensen vi hadde laget fra før, i forhold til endringer som var ønsket av oppdragsgiver. Vi endret lengden på fade-funksjonen som var på sekvensen, og lengden på hvert intervall i sekvensen. Vi lagde også en resultatskjerm som kom etter man har vært gjennom hele sekvensen. Den viste antall trykk innenfor hver kategori (ansikt, mønster, eller kontroll) og tidspunktet der det ble trykket. 6.3.6 Beta v1.0 I denne prototypen lagde vi meny og mer generell funksjonalitet, derfor kaller vi ikke det ikke prototype lenger. Vi er nå i beta-stadiet. Denne versjonen inneholdt meny til programmet vårt, to nye typer sekvenser, og lagring av brukere og tilhørende data. Menyen er oppdelt i to deler; en liste på venstre over personer eller brukere, og et hovedvindu som fyller opp resten av nettbrettskjermen. I hovedvinduet viser det data fra valgt person fra listen, hvilke sekvenser som er kjørt og resultater. Øverst i hovedvinduet er det en meny med bilder av de forskjellige sekvensene. Man starter valg sekvens med å trykke på bildet. Dette er likt som i produktet som vi leverte. 6.3.7 Beta v1.1 Dette er den nyeste utgaven av programmet, og er versjonen vi leverte til oppdragsgiver. Denne oppdateringen gikk ut på å rette opp i små feil. Vi rettet opp måten data ble presentert i listene i menyen sånn at det ble mer tydelig hvilket intervall det ble trykket innenfor. Vi la også til HiOA-logoen som bakgrunn i menyen. 46
6.4 Kodestruktur Applikasjonen vår er satt opp med en hovedaktivitet som initialiserer meny. Dette skjer da i OnCreate() metoden. Som vist ovenfor opprettes det objekter som da bindes til XML-oppslaget med en findviewbyid() metode. Interface bestemmes av setcontentview() hvor du da bestemmer rammen og innhold for hva som skal vises ved start av valgt aktivitet. Ved valg av barn fra listen vil det komme en meny med liste over tidligere sekvenser, mulighet for å endre innstillinger og valg for å starte en sekvenstype. For å gi knapper og bilder funksjonalitet har vi satt lyttere på objektene, og dette er satt opp i en privat klasse. 47
Som vist ovenfor blir lytterobjektet sendt videre gjennom parameteren og dersom den fyller kriteriene for spørringen vil programmet kjøre den gitte metoden. Ved start av en sekvens opprettes det arrays hvor det settes path og verdier. 48
Lengden for hvert array hentes fra innstillinger som bestemmes før start av sekvens. Etter initialisering av alle arrays blir det gjort kall på setsekvens() metoden, hvor det er globale variabler som øker for hvert intervall, og boolean verdier som bestemmer om det enten skal vises ansikt, mønster eller kontroll. Disse bestemmer da hvilken indeks det skal gjøres kall på og hvilken array det skal brukes. Disse vises da i VideoView format som er et verktøy for vising av videofiler i java. Objektet har fått navnet video og blir gitt en adresse for hvem video det skal vises. 49
Som vist i koden ovenfor vil variabler øke og boolean verdier forandret avhenging av hvilke kriterier de fyller. Alle ender med kall på intervall() metoden, men gir forskjellige resultater avhenging av i hvilken indeks de er. 50
Ovenfor vises det intervall() metoden som tar i bruk CountDownTimer. Dette er et nedtellingsobjekt som kan importeres fra java-biblioteket. Som antall intervaller bestemmes det også tid for hvert intervall i innstillinger før start av sekvens. Ved start av metode starter animasjonen som viser et sort rutenett foran bilde som gjør det utydelig for hva som vises i videoen. Ved trykk på skjermen vil da denne forsvinne med en animasjon (se eksempel nedenfor), og registrere det i databasen. Animasjonen som viser et stort rutenett foran bilde vil da komme opp igjen foran videoen i løpet av ett sekund dersom personen ikke har trykket på skjermen. 51
Når tiden er ferdig vil metoden gjøre kall på en onfinish() metode som ligger lokalt i intervall() metoden. Her vil den kjøre gjennom en spørring som finner ut om sekvensen er ferdig. Dersom den er ferdig vil tidspunkt, sekvenstype, sekvensid og personid lagres i databasen og lukke aktiviteten. Om det derimot fortsatt er flere intervaller igjen vil den sette video på pause og gjøre den kall på setsekvens() metoden som nå har andre verdier enn det den hadde før kjøring av intervall() metoden. 52
Disse metodene vil da gjøre kall på hverandre i gitt rekke følge(som vist ovenfor) og avslutte aktiviteten når antall intervaller er passert. I databaseklassen tar vi i bruk av SQLITE. Dette er et databaseverktøy som er integrert med java. Denne er veldig lett og begrenset på hvilke verdier den kan ha, noe som kan være en ulempe dersom man skal ha et litt mer avansert oppsett av et system i en database. Klassen vår starter med en liste av datafelter som står for databasenavn, tabellnavn, attributter for de ulike tabellene og objekt som refererer til en privat klasse som tar i bruk SQLITE. Som en standard struktur til Android har man en Oncreate() metode som initialiserer metoder og verdier, og den private klassen oppretter tabellene ved oncreate(). 53
Kommandoen for oppretting av tabell blir skrevet som en String og deretter sendt som parameter i en execsql() metode. Denne metoden vil ta imot et String objekt og utføre kommandoen som den er skrevet og returnere feilmelding dersom det er skrevet feil. Resten av klassen består så av metoder som inneholder ulike spørringer avhengig av hvilke metoder de skal brukes i. I disse metodene tar vi bruk av en Cursor som importeres fra java biblioteket og som vil returnere en referanse til det resultatet som er returnert. 54
For å kunne kjøre spørringer bruker vi objekt fra SQLiteDatabase som returnerer spørringens resultat. Referansen får da en verdi avhengig om det finnes noe i tabellen som fyller kriteriene og sendes videre til metoden den brukes i. 6.5 Brukergrensesnitt Utseende på hvordan programmet skulle bli ble bestemt i en veldig tidlig fase av prosjektet. Vi lagde fort en skisse for hvordan brukergrensesnittet skulle være og hvordan det skulle forandre seg ved overgang. Slik så skissen ut ved første utkast For å få dette til å fungere har vi inkludert flere XML-oppslag i en hoved XML-fil. Av disse har vi inkludert barneliste.xml, personmeny.xml, leggtilperson.xml og prefview.xml. barneliste.xml viser en liste over registrerte barn med navn og alder i måneder. personmeny.xml viser en liste over alle tidligere sekvenser et barn har hatt og muligheten for å starte en ny sekvens. Man kan også komme til prefview.xml ved trykk på Innstillinger knappen. leggtilperson.xml vil komme opp ved trykk på Legg til person knappen og vil legge til et nytt barn. Utseende vil da veksle mellom XML-filenes synlighet ved behov. 55
Alle XML-filene inkluderes i en hoved XML-fil som heter meny.xml. I meny.xml bestemmes posisjon og størrelse for de ulike XML-filene som er inkludert. Meny er todelt med en liste over barn på venstre side som vises til enhver tid, mens alt i innholdramme veksles imellom. Innholdsramme består av personmeny.xml, leggtilpersonmeny.xml og prefview.xml. Ved start av aktivitet vil det kjøres clearallexml() som skjuler alle XML-filer i innholdsramme. Ved trykk av et barn fra barneliste.xml vises personmeny.xml og alle sekvenser for gitt barn settes i sekvenslisten. Dersom barnet ikke har noen tidligere sekvenser vil sekvenslisten stå tom. 56
Ved trykk på Innstillinger knappen blir prefview.xml synlig. Ved klikk av lagreknappen i prefview.xml vil clearallexml() kjøres på nytt og personmeny.xml vises igjen. På denne måten vil meny da ha en fin flyt og kan enkelt navigeres. 57
7. Utviklingsverktøy 7.1 Microsoft Project 2010 Microsoft Project er et verktøy som brukes for å administrere prosjekter og lage Gant diagrammer. Hensikten med dette programmet er å kontrollere tidsplaner, organisere arbeidet mellom gruppemedlemmer og sørge for at prosjektet blir utført innen fristen. Vi har valgt dette programmet for å lage en timeplan som vi har ofte brukt og det gjør enklere å tegne diagrammer. 7.2 Eclipse og Android SDK Eclipse er en editor som støtter programmeringsspråket java. Den inneholder en utviklingspakke(sdk), som inkluderer Eclipse Java Development Tools som gir et integrert utviklingsmiljø med en inkrementell java kompilator, og en full modell av javas kildekode-filer som gjør det mulig å utvikle og analysere. Comment [8]: Android SDK (Software Development Kit) tilbyr klassebiblioteker og verktøy som er nødvendig for å få programmer til å fungere på Android-baserte enheter. I tillegg til dette tilbyr det en emulator for kjøring av Android programmer. Denne emulatoren bruker minnet og systemresurser til datamaskinen som har startet den opp. Dette gjør at vi kan spesifisere hvor mye minne emulatoren har, om den skal ha internett-tilkobling, og om den skal bruke kamera(f.eks. webcam som mange laptopper har). SQLite er inkludert i Android SDK, og inneholder metodene som er nødvendig til oppbygging av databasen til systemet. Ved hjelp av SQLite kan vi også lage såkalte spørringer som brukes til å hente ønsket informasjon ut av databasen. 7.3 Dropbox Dropbox er en nettbasert tjeneste. Der kan man laste opp filer av hvilken som helst type, slik at man har tilgang på de fra enhver datamaskin med internettilgang. Dropbox gir muligheten til å dele mapper og filer til mange personer samtidig. For at dette skal gjøres, må de ha sin egen konto på Dropbox, og de må inviteres til mappen for å få tilgang til filene der. På denne måten kan man dele filer og informasjon, på en dynamisk måte, frem og tilbake mellom flere parter. På Dropbox er det slik at en person som laster opp filer har en maks grense målt i gigabyte. Vi brukte Dropbox til å dele en felles mappe for gruppen, og laste opp det vi gjorde. Slik kunne alle på gruppen få tilgang til all oppdatert stoff. Vi delte også en mappe med vår veileder, og en med vår oppdragsgiver. Slik ble det lettere for gruppen å holde dem oppdatert med det nødvendige i prosjektet. Veilederen og oppdragsgiveren kunne også sende oss informasjon på denne måten. 58
7.4 Google Docs (Nå Google Drive) Google Docs er en nettbasert kontorpakke som brukes til å dele dokumenter med andre. De delte dokumentene kan endres av flere personer samtidig og endringene vil bli gjort for alle i sanntid. Google Docs har vi brukt til å dele flere filer/dokumenter gjennom prosjektperioden. Dette ble mest brukt under gruppemøtene når vi planlegget hva vi skulle gjøre til neste gang vi møttes. Referater fra møtene med oppdragsgiver ble lagt inn der, slik at alle kunne se hva som skulle gjøres til neste møte. Det var ganske effektivt siden alle kunne gjøre endringer samtidig, og notere samtidig. 7.5 Saros Saros er et tillegg til Eclipse for å dele og synkronisere kode mellom brukere i sanntid. En person som deler prosjektet sitt, oppretter en sesjon som blir utgangspunktet for koden. Verten kan da invitere andre brukere til sin sesjon, og de vil da kunne se og endre på samme versjon av koden som verten deler under hele sesjonen. Fordelen med Saros er nettopp dette, det at man alltid har nyeste versjon hele tiden og kan teste på endringene til en annen bruker uten å pushe, pulle og committe i rekkefølge som kan bli forvirrende dersom man ikke har oversikt. Ulempen med Saros er at det ikke finnes noen versjonskontroll, som gjør at det ikke er noe tilgang til tidligere versjoner av koden. Det er da vanskelig å gå tilbake til en fungerende versjon av koden dersom en ødelegger det. Vi brukte Saros fordi vi satte ofte i par og jobbet med samme, og slik fikk vi teste hverandres funksjoner med en gang. 7.6 AVS Video Converter AVS Video Converter er et program som konverterer og setter sammen videoklipp til den lengden og formatet som vi ønsket. Programmet har veldig mange muligheter, men vi brukte stort sett konvertering fra Gif-filer til mp4-format og fra wmv-format til mp4-format. Mp4- format er formatet som er beregnet på håndholdte enheter sånn som Samsung nettbrett. Det var derfor viktig for oss å ha mediafiler på mp4-format. Grunnen til at vi valgte dette programmet over andre konverteringsprogrammer, er fordi AVS Video Converter hadde en unik funksjon. Vi kunne legge flere Gif-filer sammen til en mp4- formats video. Dette var viktig fordi de gif-filene vi fikk var veldig kort lengde på. De varte mellom 0,1 sekunder til 0,7 sekunder. Hvis vi brukte så korte videoklipp ville det henge seg i applikasjonen fordi da måtte den laste inn videoen mange ganger. Så det vi gjorde da var å legge den samme Gif-filen etter hverandre mange ganger. Når det var gjort konverterte vi alle filene til en mp4-fil. Den nye mp4-filen ville nå ha en lengde som var kompatibel med applikasjonen. 59
7.7 Samsung Galaxy Tab 10.1 Samsung Galaxy Tab 10.1 Utvikler: Samsung Teknologi: TFT 16 millioner farger Oppløsning: 1280 x 800 piksler (WXGA) Type: 10,1" Vekt: 565 gram Størrelse: (H x B x D) 175,3 x 256,7 x 8,6 mm Operativsystem: Android 3.1 ( Honeycomb) Samsung Galaxy Tab 10.1 er en Android nettbrett produsert av Samsung. Nettbrettet tilhører den neste generasjonen av Samsung Galaxy Tab serien som består av 10.1 modellene, 8.9 modellen og 7.7 modellen. Samsung Galaxy Tab 10.1 har kommet i tre ulike modeller med henholdsvis 16, 32 og 64GB lagringskapasitet, der hver modell enten leveres med bare WiFi, eller med både WiFi og 3G-tilkobling. 60
8. Modellering 8.1 Klassediagram 61
8.2 Sekvensdiagram Nedenfor står det diagrammer for de ulike sekvensene i programmet. Disse representerer metodekall fra forskjellige aktiviteter til hverandre og returverdien. Ovenfor vises det et sekvensdiagram og interaksjon mellom listepersoner, som er av ListView objekt, og Databaseklassen. 62
Ovenfor vises det et sekvensdiagram og interaksjon mellom sekvensliste, som er et ListView objekt, og Databaseklassen. I likhet med de forrige diagrammene viser denne en interaksjon mellom flere aktiviteter og databaseklassen. Aktivitet er hovedaktiviteten og den initialiserer ett av de resterende aktivitetsklassene. Når de aktivitetene ender vil man bli navigert tilbake til hovedaktiviteten. 63
8.3 Aktivitetsdiagram 64
9. Avslutning og Konklusjon Denne applikasjonen er et hjelpemiddel i forskningen til Lars Klintwall. Han har testet applikasjonen flere ganger under utviklingen de siste to månedene. Dette var for å se om vi var på riktig vei med utvikling av programmet. Når det gjelder resultatet av løsningen, er det for tidlig å si noe om hvorvidt bruk av denne applikasjonen kan hjelpe til med å påvise autisme. I slike forskningsprosjekter tar det som regel en stund før det er mulig å få noen konkrete resultater. I tiden fremover vil Lars Klintwall fortsette å teste denne applikasjonen på flere barn. Vi har likevel fått tilbakemeldinger fra Klintwall angående funksjonalitet av applikasjonen. Han er veldig fornøyd med produktet. Dette er en av grunnene til at han vil jobbe med oss etter at vi er ferdig med prosjektet også, for videreutvikling av applikasjonen. Muligheter for videreutvikling er nevnt i produktdokumentasjonen. Vi synes at dette har vært en utfordrende og morsom oppgave å jobbe med, der vi har fått testet våre datakunnskaper på en ny måte. Når det gjelder resultater, så har vi oppnådd alle krav som ble satt i start av prosjektet. Vi har i tillegg fått oppfylt flere av de kravene som ble satt underveis i prosjektet av oppdragsgiver, etter tidlige tester av programmet. Denne oppgaven har mulighet til å bli mye større dersom den skal brukes i et stort omfang av forskningsmetoder, og det er mye funksjonalitet som fortsatt kan implementeres. Derfor måtte vi selv definere hvor mye funksjonalitet vi har mulighet til å implementere i forhold til prosjektets tidsramme. Vi implementerte først den funksjonaliteten og de kravene som ble diskutert og satt i starten av prosjektet. Etter hvert som vi fikk flere krav fra oppdragsgiver under prosjektet, ble vi enige med han om å gjøre så mye som vi hadde tid til. Ved prosjektets slutt har vi nå en fungerende applikasjon, som kan brukes til å teste barn for tegn på autisme. 65