Prosessdokumentasjon for Project Sunstone

Et hovedprosjekt i data ved Høgskolen i Oslo, våren 2010

Martin Haukeli Jostein Haukeli Marit Olsen

Prosessdokumentasjon for Project Sunstone 1

1.1 ForordDette er en prosessrapport som beskriver arbeidsprosessen fra ide til ferdig produkt. Dette dokumentet er beregnet for sensor, oppdragsgiver, veileder og andre som kan være interesserte i vårt arbeid.

Gruppen fant frem til oppgaven gjennom hovedprosjektsiden til HiO. Her var det uttrykt et ønske om at en studentgruppe kunne utvikle et utvidbart rammeverk for photobrowsing. Ettersom det var enighet i gruppen om at dette virket som en interessant oppgave, valgte vi å ta kontakt med Frode Eika Sandnes som hadde lagt ut oppgaven. Vi hadde vårt første møte med oppdragsgiver kort tid etter, og vi ble raskt engasjert i problemstillingen etter hvert som vi ble mer kjent med oppdragets detaljer. På grunn av vårt engasjement for denne oppgaven, samt måten den dekket våre ønsker om arbeidsmetode og bruk av Java, endte vi opp med å ta dette oppdraget.

Ved ingeniørutdanningen på HIO er det ved en tidligere anledning utviklet noen algoritmer som kan sortere bilder inn i meningsfylte kategorier. For og enkelt kunne benytte seg av algoritmene ble det uttrykt et behov for å designe og implementere en photobrowser som kunne bruke disse. Dette var grunnlaget for at dette prosjektet ble iverksatt.

Etter endt prosjektperiode var målet å ha utviklet et rammeverk som enkelt kunne videreutvikles etter behov. Eksempler på noen slike utvidelser kan være inkorporering av nye klassifikatorer, visninger i brukergrensesnittet eller metoder for uthenting av metadata.

Prosessdokumentasjon for Project Sunstone 2

InnholdsfortegnelsePROSESS- DOKUMENTASJON FOR PROJECT SUNSTONE.....................................................1

1.1 FORORD.........................................................................................................................................................1INNHOLDSFORTEGNELSE...........................................................................................................................................31.3 INNLEDNING....................................................................................................................................................4

1.3.1 Prosjektgruppen...................................................................................................................................41.3.2 Oppdragsgiver......................................................................................................................................41.3.3 Dagens situasjon..................................................................................................................................41.3.4 Mål.......................................................................................................................................................51.3.5 Rammebetingelser...............................................................................................................................51.3.6 Prosjektets navn...................................................................................................................................5

1.4 PLANLEGGING OG METODE.................................................................................................................................61.4.1 Innledende arbeid................................................................................................................................61.4.2 Fremdriftsplan......................................................................................................................................61.4.3Prosjektdagbok.....................................................................................................................................71.4.4 Veiledning............................................................................................................................................81.4.5 Verktøy.................................................................................................................................................81.4.6 Kompetanseutvikling............................................................................................................................91.4.7 Arbeid.................................................................................................................................................101.4.8 Tilbakemelding fra oppdragsgiver......................................................................................................10

1.5 OM UTVIKLINGSPROSESSEN..............................................................................................................................101.5.1 Valg....................................................................................................................................................101.5.2 Utviklingsfaser...................................................................................................................................111.5.3 Utfordringer og problemer.................................................................................................................141.5.4 Forhold til oppdragsgiver...................................................................................................................16

1.6 KRAVSPESIFIKASJONEN OG DENS ROLLE...............................................................................................................161.6.1 Rolle...................................................................................................................................................161.6.2 Endringer............................................................................................................................................16

1.7 OM RESULTATET.............................................................................................................................................171.8 AVSLUTNING.................................................................................................................................................17

1.8.1 Eget utbytte........................................................................................................................................171.8.2 Hva kunne blitt gjort annerledes........................................................................................................171.8.3 Fremtiden...........................................................................................................................................17

Prosessdokumentasjon for Project Sunstone 3

1.3 Innledning

1.3.1 ProsjektgruppenVed prosjektets oppstart var alle gruppens medlemmer godt kjent fra tidligere prosjektoppgaver ved Høgskolen i Oslo (HiO). Av den grunn mener vi at vi var kjent med de enkelte medlemmenes arbeidsmetoder og preferanser, noe som har gitt oss et godt grunnlag for planlegging og fordeling av arbeidsoppgaver. Alle på gruppen studerer ved dataingeniørutdanningen på HiO.

Det var ingen av oss som hadde noen gode kontakter å benytte oss av for å finne frem til et hovedprosjekt som dekket våre ønsker. Av denne grunn startet vi med å kontakte et par aktuelle bedrifter per e-post, og se igjennom prosjektforslagene som var blitt offentliggjort på HiO sin internettside for hovedprosjekter. Vi ønsket først og fremst å få en ekstern oppdragsgiver på grunn av mulighetene dette ville kunne gi oss til å danne et større kontaktnett. På denne måten ville vi kunne bedre mulighetene våre for å finne en attraktiv jobb etter endt utdanning. Til tross for dette endte vi opp med en intern oppdragsgiver hos HiO, noe som i ettertid har vist seg å ha fungert utmerket for vår prosjektgruppe. Vi har dessuten ingen tvil om at erfaring fra dette prosjektet vil ha en positiv og verdifull innvirking i fremtidige jobbsammenhenger.

1.3.2 OppdragsgiverVår oppdragsgiver er Høgskolen i Oslo ved Frode Eika Sandnes. Vi har hatt en svært god dialog med oppdragsgiver gjennom hele prosjekttiden. Dette har vært en viktig forutsetning for vårt engasjement for oppgaven, og har hatt en betydelig innvirkning på det endelige resultatet.

1.3.3 Dagens situasjonI dag er digitalkameraer blitt en svært vanlig eiendel blant personer over hele verden, samtidig som masseprodusering og stadig lavere kostnader gjør det mer lukrativt å gå til anskaffelse av et digitalkamera. Det blir tatt bilder i alle situasjoner og under alle omstendigheter. Disse bildene kan bli samlet på minnekort, eksterne harddisker, overført til datamaskiner eller eventuelt skrevet ut til papir. Over en tidsperiode kan dette føre til at store bildesamlinger blir lagret, som igjen kan føre til at fotografen får dårligere oversikt over samlingen og det dermed kan bli vanskeligere å finne frem til et utvalg bilder i denne. I denne situasjonen kan det være svært praktisk å ha en photobrowser som kan hjelpe brukeren med å navigere frem til et ønsket utvalg bilder.

Det finnes mange forskjellige typer photobrowsere som er tilgjengelige i 2010. De aller fleste av disse gir brukeren mulighet til å sortere bilder etter informasjon som for eksempel dato, filnavn og størrelse på bildet. Ett eksempel på dette er Google Picasa som blant annet sorterer etter disse tre egenskapene. Vi har ingen kjennskap til photobrowsere som på en enkel måte kan sortere bilder etter hvor i verden de er tatt, om det er dag eller natt, eller egendefinerte kategorier.

Det finnes digitalkameraer som bruker GPS (Global Positioning System) til å lagre informasjon om hvor bildene er tatt, men dette er ikke vanlig utstyr på de fleste kameraer.

Prosessdokumentasjon for Project Sunstone 4

De kameraene som er utstyrt med GPS, bruker også som oftest lang tid for å låse seg til satellittsignalene og er dermed ikke så praktisk i bruk. Dette gjelder spesielt der en ikke har et stillestående motiv og dermed ikke har tid til å vente på at GPS’en skal låses til signalet. De fleste digitalkameraer som produseres idag lagrer forøvrig metainformasjon som gjør det raskt og enkelt å finne mye informasjon om bildet. Eksempler på slik informasjon er innstillinger som ble brukt på tidspunktet da bildet ble tatt. Denne informasjonen blir lagret i et Exif-format (Exchangeable image file format). Slik informasjon kan vise seg svært nyttige i ettertid, ettersom den kan vise for eksempel kameramodell, dato og tid, eksponeringstid, brennvidde og mye mer. Ut fra denne informasjonen, eller ved å analysere bildets innhold, har vår oppdragsgiver laget en del algoritmer som kan implementeres i form av «klassifikatorer». Disse har mulighet til å bruke enten metadata, bildets innhold eller begge til for eksempel å finne ut omtrent hvor i verden bildene er tatt, om det er natt eller dag, eller om bildet er tatt ute eller inne. Dette gjør at man enklere kan finne frem i store bildesamlinger som gjerne er tatt på et mye tidligere tidspunkt.

1.3.4 MålMålet med oppgaven var å designe et utvidbart rammeverk for en photobrowser som kan sortere bilder i meningsfylte kategorier. Dette skulle skje basert på algoritmer som er utviklet ved ingeniørutdanningen ved HiO. Det skulle på en enkel måte være mulig å installere nye klassifikatorer i systemet uten at det må gjøres endringer i brukergrensesnittet eller andre steder i programkoden. Denne photobrowseren skal gjøre det lettere for brukere å finne frem til ønskede bilder i store samlinger.

Systemet vi skulle designe hadde noen spesielle mål, som blant annet at både brukergrensesnittet, koden og klassifikatorene skulle være utvidbare. Effektivitet i forhold til tid har vært et annet mål som vi har jobbet mye med. Eksempler på tidkrevende prosesser der dette har vært viktig er koden der bildene blir skannet, og metoden for generering av hash av bilder. Alle kravene til systemet kan leses om i kravspesifikasjonen som blir omhandlet i kapittel 3.

1.3.5 RammebetingelserDette har vært et relativt åpent prosjekt, hvor vi har hatt gode muligheter til å vurdere, samt velge blant verktøy og teknikker vi har ønsket å benytte oss av. I forbindelse med noe av den første kontakten vi hadde med oppdragsgiver kom vi inn på programmeringsspråket. Det som allerede var skrevet av kode i forbindelse med at en slik photobrowser skulle implementeres benyttet seg av Java som programmeringsspråk. Oppdragsgiver nevnte at det kunne være mulig og bruke et annet programmeringsspråk hvis det var ønskelig, noe det ikke var fra vår side. Dette førte til at vi da måtte forholde oss til at alt skulle implementeres i Java. Noen av valgene vi har gjort har ført til begrensninger i systemet. Ett eksempel på dette er vårt valg om å bruke en Apache Derby database. Som følge av dette har vi vært nødt til å bruke SQL syntaks som Derby støtter.

1.3.6 Prosjektets navnProsjektets navn er ”Project Sunstone”. Dette er et navn vår oppdragsgiver har tenkt på og som vi syntes hørtes bra ut. Bakgrunnen for denne tanken gikk tilbake til vikingtiden og

Prosessdokumentasjon for Project Sunstone 5

deres myteomspunnende måte å navigere ved hjelp av en sunstone. Dette kan leses mer om på denne siden http://www.nordskip.com/vikingcompass.html.

1.4 Planlegging og metode

1.4.1 Innledende arbeidVi ble oppmerksomme på dette prosjektet via HiO sin nettside for prosjektforslag. Vi hadde et møte med Frode E. Sandnes for å få mer informasjon om prosjektet. Her stilte vi en del spørsmål rundt muligheter for å gjøre prosjektet til et mer programmeringstungt prosjekt, ettersom den opprinnelige oppgaveformuleringen uttrykte et noe sterkt fokus på utforming av brukergrensesnittet. Dette skulle vise seg og ikke være noe problem for oppdragsgiver, og vi gikk fra møtet med et svært positivt inntrykk av dette prosjektet. Etter litt diskusjon innad i gruppen valgte vi å ta oppdraget som vårt hovedprosjekt.

I løpet av oppstartsprosessen ble det utviklet en prosjektskisse og en forprosjektrapport. Disse ligger som vedlegg til prosjektrapporten.

1.4.2 FremdriftsplanVårt viktigste verktøy for planlegging av arbeidsflyten igjennom prosjekttiden har vært Gantt-diagrammet vi valgte å utvikle tidlig i prosjektet. Ved å ta oss tid til å anslå hvor lang tid vi vil bruke på de viktigste applikasjonsdelene, har vi kunnet følge dette diagrammet som en overordnet arbeidsplan. Gantt diagrammer ligger om vedlegg 1 og 2.

EndringerVi startet med å lage et Gantt-diagram i Microsoft Excel, men ved en senere anledning fant vi ut at vi ønsket en enklere måte å oppdatere diagrammet på. Dermed bestemte vi oss for å finne et program som egnet seg bedre til tegning av Gantt-diagrammer. Etter å ha brukt litt tid på leting etter et godt alternativ, endte vi opp med å bruke programmet GanttProject, som hadde alle funksjoner vi ønsket å benytte. Disse diagrammene ligger med som vedlegg i denne rapporten.

Vi har kun følt behov for å oppdatere Gantt-diagrammet ved en anledning. Disse endringene ble gjort fordi vi på daværende tidspunkt innså at vi trengte lengre tid på flere deler av prosjektet, og at vi ønsket å jobbe med flere av disse delene samtidig.

I den første versjonen av Gantt-diagrammet var det beregnet at klassifikatorbasisen skulle være ferdig etter kun 21 dager. Vi fant fort ut at dette ville være svært upraktisk, ettersom klassifikatorbasisen var avhengig av at andre deler av rammeverket ble utviklet samtidig. Ettersom det ikke var viktig å fullføre klassifikatorbasisen på dette stadiet, valgte vi å planlegge en utvikling av denne parallelt med implementeringen av rammeverket. Noe som i ettertid har sett ut til å fungere utmerket.

Milepælen som beskrev utredning av datastrukturen ble også endret fra første til andre versjon av diagrammet. Dette ble gjort fordi vi følte vi ikke hadde nok detaljer klare omkring denne milepælen på daværende tidspunkt. På denne måten kunne vi unngå å sette uønskede begrensninger på datastrukturen på et tidlig stadium. Isteden bestemte vi oss for å bruke mars måned på å fullføre denne implementasjonen.

Prosessdokumentasjon for Project Sunstone 6

Implementeringen av API/rammeverket endret vi slik at vi startet tidligere med dette enn planlagt i versjon en. Dette ble gjort fordi vi ønsket å komme raskt igang med implementering av arkitekturen vi designet tidligere.

GUI delen var i første versjon kun satt opp fra slutten av mars til midten av mai måned. I versjon to delte vi opp denne slik at vi skisserte GUI i løpet av februar måned, og implementerte dette fra slutten av mars til midten av mai. På denne måten fikk vi en bedre oversikt over hvilke løsninger som ville være mest fornuftige, både i forhold til komponenter som skulle kommunisere med GUI, og de enkelte delene av brukergrensesnittet.

Vi har kun beregnet en til to dager til å lage et selvinstalleringsprogram. Dette er et avvik fra Gantt-diagrammet som beskriver at denne prosessen vil ta opp til en uke. Grunnen til dette er at vi ønsker å benytte tiden helt frem til innlevering, og at vi allerede har gjort en del undersøkelse og dermed har klart for oss hvordan vi ønsker å lage installasjonsprogrammet.

Test cases har vi endret fra tre uker til 4 uker, for å gi bedre rom for gjennomføring av dette. En grunn til dette var vårt ønske om å utvide testcase med fler bilder, og vurdere om disse var tilfredsstillende.

Tiden som var satt av til testklassifikatorer ble økt fra omtrent en og en halv måned til rundt to måneder og en uke. Dette gjorde vi for å kunne utvikle disse parallelt med andre deler av rammeverket. Dette har gjort det lettere for oss å se hvordan det er å utvikle en klassifikator.

I første versjon har vi skrevet innlevering som en egen milepæl, denne har vi valgt å fjerne helt fra andre versjon, ettersom dette er noe vi har jobbet med litt underveis i hele prosjektet og mye på slutten av prosjektperioden.

GjennomføringI all hovedsak har overholdt milepælene i det seneste gantt-diagrammet. Mot slutten av prosjektperioden feilberegnet vi tiden litt. Her burde vi satt fristen for å få ferdig programmet en del tidligere enn det vi gjorde, slik at vi kunne hatt mer tid til å konsentrere oss om dokumentasjonsskrivingen. Annet en dette føler vi at planlegging av arbeidet har gitt tilfredsstillende resultater.

1.4.3ProsjektdagbokVi har underveis i prosjektet ført en prosjektdagbok. Dette har vi gjort for å huske viktige hendelser som har skjedd underveis i prosjektperioden. Denne dagboken har hjulpet oss mye på slutten av prosjektet når prosjektrapporten skulle ferdigskrives. Det har vært en stor fordel å ha tilgang til notater og stikkord om hva som har skjedd underveis, slik at viktige detaljer ikke blir glemt like enkelt.

Måten vi har valgt å gjøre dette på er å opprette en passordbeskyttet hjemmeside med en WordPress blogg for prosjektets medlemmer. Her har alle på gruppen hatt muligheter til å legge inn og modifisere notater på en ryddig måte ved hjelp av datoer og klokkeslett.

Prosessdokumentasjon for Project Sunstone 7

1.4.4 VeiledningGruppen fikk tildelt Frode Eika Sandnes som veileder under prosjektet. Siden han også er vår kontaktperson hos oppdragsgiver har vi hatt mye kontakt underveis i prosjektet. Spesielt i oppstarten av prosjektet fikk vi mange gode råd som har hjulpet oss med å komme i gang. Veileder har også vært lett tilgjengelig og har kunnet svare på spørsmål fortløpende der dette har vært nødvendig. På slutten av prosjektperioden har vi fått mange gode råd for hvordan dokumentasjonen bør utformes.

Vi har hatt ukentlige møter hvor F. Sandnes har fungerte både som veileder fra skolen og kontaktperson fra oppdragsgiver samtidig. Dette har medført at vi har hatt mulighet til å stille spørsmål både angående systemet vi utviklet og prosessen med prosjektet på et og samme møte. Dette har vært en effektiv måte å jobbe på som har ført til raskere svar på eventuelle spørsmål vi har hatt.

1.4.5 VerktøyGruppen har jobbet på forskjellige operativsystem og har brukt både gratis og betalte programvarer. En kort oversikt over verktøy vi har brukt underveis i prosjektet følger under.

Apache Derby Database (http://db.apache.org/derby/)Apache Derby er en åpen kildekode relasjons database som er implementert i Java. Den er tilgjengelig under Apache License, Version 2.0. Derby kan implementeres som en innebygd database i et Java program. Eclipse har også plugins som er enkle å installere for Derby databasen.

Adobe Photoshop (http://www.adobe.com/no/products/photoshop/family/)Dette er et bilderedigeringsprogram hvor det blant annet er mulig å redigere og finjustere bilder. Brukt til å lage skisser og redigere bilder i sluttdokumentasjonen.

Drew Noakes metadata-extractor (http://drewnoakes.com/code/exif/)Metadata-Extractor er et bibliotek for uthenting av Exif metadata fra JPEG bilder. Kildekoden er skrevet i Java og frigitt til Public Domain, som vil si at hvem som helst kan bruke, modifisere og redistribuere kildekoden etter behov eller ønske.

Eclipse (http://www.eclipse.org/)Eclipse Galileo er et utviklingsverktøy for å utvikle programvare. Galileo er siste versjon av programmet. Dette programmet hadde vi brukt tidligere i utdanninger og var dermed kjent med mye av dets muligheter.

Fast MD5 (http://www.twmacinta.com/myjava/fast_md5.php)Et åpent kildekode bibliotek skrevet i Java under lisensen GNU LGPL versjon 2.1, og tilbyr en enkel og svært rask implementering av MD5 hashfunksjon blant annet for bruk til hashing av filer.

GanttProject (http://www.ganttproject.biz/)GanttProject er et åpen kilde prosjektstyringsverktøy hvor en blant annet kan lage gantt-diagram som vi var interessert i.

GIMP (http://www.gimp.org/)

Prosessdokumentasjon for Project Sunstone 8

Gratis bilderedigeringsprogram hvor det blant annet er mulig å redigere og finjustere bilder. Brukt til å lage skisser og redigere bilder i sluttdokumentasjonen.

Google Picasa (http://picasa.google.com/)Gratis fotoalbum fra Google. Har også web-album hvor bilder kan lastes opp på nett.

Java SE (Standard Edition) 6 (http://java.sun.com/)Dette var den siste utgitte versjonen av programmeringsspråket Java når utviklingen av dette systemet pågikk.

Microsoft Office (http://office.microsoft.com/nb-no/default.aspx?ofcresset=1)Kontorpakke som inneholder blant annet Excel og Word. Vi har brukt regneark til å lage første versjon av gantt-diagrammet vårt. Word har blitt brukt til dokumentasjon underveis og til sluttdokumentasjonen.

Open Office (http://no.openoffice.org/)Dette er en fri kontorpakke som inneholder blant annet Calc og Writer som har vært aktuelle i vårt prosjekt.

Windows Live Messenger (http://www.windowslive.no/messenger/)Kommunikasjonsprogram for å kommunisere via internett. Dette har blitt brukt til å diskutere problemer underveis, avtale møter og annen kommunikasjon som har vært prosjektrelatert.

WordPress (http://wordpress.org/)Gratis blogg og publiseringsplattform. Kan blant annet brukes til å publisere dokumenter.

1.4.6 KompetanseutviklingFor å kunne benytte oss av Derby databasen ble vi nødt til å sette oss inn i SQL syntaksen som blir brukt av denne. Dette medførte ingen problemer for oss ettersom vi allerede hadde erfaring med både databaser og SQL syntaks ved prosjektets oppstart. Hvordan denne databasen må opprettes og hvordan drivere lastes måtte også læres.

Ettersom uthenting og bruk av Exif informasjon har en helt sentral rolle i vårt rammeverk, har vi måtte lese oss til svært mye informasjon om hvordan de ulike informasjonsfeltene fungerer, hva styrker og svakheter ved Exif er, og hvordan vi kan benytte oss av denne informasjonen i vår applikasjon. Her har vi blant annet benyttet oss av dokumenter som beskriver Exif spesifikasjonen for versjon 2.1 og 2.2 med alle detaljer. Disse dokumentene er publisert av Japan Electronics and Information Technology Industries Association, som forøvrig er organisasjonen som utviklet Exif formatet. Link til dette dokumentet: http://www.exif.org/Exif2-2.PDF

For å kunne bruke metadata-extracor biblioteket på en god måte har vi benyttet oss av javadoc samt eksempelkode som viser hvordan en kan benytte seg av dette biblioteket. Denne eksempelkoden er tilgjengelig på kildekodens hjemmeside: http://drewnoakes.com/code/exif/sampleUsage.html

Prosessdokumentasjon for Project Sunstone 9

1.4.7 ArbeidGruppen har for det meste jobbet hjemmefra, med god kommunikasjon over Live Messenger og e-post. Vi har hatt møter minimum en gang per uke der det har vært rom for diskusjoner og deling av tanker omkring viktige beslutninger. Vi har også brukt disse møtene til gjennomgang av arbeidet som er blitt gjort siden sist. På denne måten har vi sørget for at både gruppemedlemmene og oppdragsgiver har kunnet danne seg et godt oversiktsbilde av prosjektets fremgang. Fordeling av oppgaver er hovedsaklig blitt avtalt under møtene. Der det har oppstått nevneverdige problemer, har vi tatt kontakt med hverandre per e-post eller Live Messenger for å løse disse på en rask og enkel måte.

1.4.8 Tilbakemelding fra oppdragsgiverVi har hatt jevnlig kontakt med oppdragsgiver underveis i hele prosjekttiden. Oppdragsgiver har også vært vår veileder gjennom hele prosjektperioden. Verdifull tilbakemelding fra oppdragsgiver har for eksempel vært respons på vår implementering av de ulike delene av rammeverket, spesielt under planleggingen og utviklingen av disse. På denne måten har vi hele tiden kunnet sørge for at programmet oppfyller de kravene som oppdragsgiver har uttrykt. Dermed har vi enklere kunne jobbe mot et resultat som tilsvarer oppdragsgivers beskrivelse.

1.5 Om utviklingsprosessen

1.5.1 ValgVi har vært nødt til å foreta en del viktige valg i løpet av prosjektet. Disse blir nærmere beskrevet under.

UtviklingsverktøyVi valgte å bruke Eclipse som vi er kjent med gjennom utdanningen vår. Dette var enklere enn å sette oss inn i ett nytt utviklingsprogram.

DatastrukturSom vist i Gantt-diagrammet, brukte vi en del tid til å finne ut hva slags datastruktur som kunne passe vårt prosjekt. Vi har spesielt vurdert Set og forskjellige listetyper, men disse datatypene har ikke funksjonalitet for å trekke ut tilhørende verdier for en gitt nøkkelverdi. Noe som gjør disse uegnede til å identifisere verdier. Derfor endte vi opp med å bruke HashMap hvor verdier legges inn med en nøkkel og LinkedList der dette passet.

DatabaseI begynnelsen av prosjektet hadde oppdragsgiver uttrykt et ønske om en lagringsmetode som ikke implementerte en database. Etter hvert som vi undersøkte de ulike mulighetene og diskuterte disse med oppdragsgiver, ble vi enige om at en implementering av en enkel database kunne være ønskelig. Dermed begynte vi å undersøke om det fantes en god implementasjonsmulighet som passet for vårt prosjekt. Vi valgte å bruke Apache Derby database siden denne enkelt kunne integreres i vår applikasjon, er av liten størrelse og kan installeres i Eclipse ved hjelp av plugins. Den er basert på Java, JDBC og SQL standarder. Brukere av den ferdige applikasjonen vil i liten grad ha noe med databasen å gjøre.

Prosessdokumentasjon for Project Sunstone 10

BrukergrensesnittSiden vi valgte å utvikle brukergrensesnittet på en slik måte at det enkelt kunne byttes ut eller videreutvikles på et senere tidspunkt, valgte vi å dele inn de mest sentrale GUI komponentene i tre mindre visninger. Disse ble implementert med tanke på brukerens forventninger om hvordan en slik løsning ville fungere. Ved å designe brukergrensesnittet på denne måten har vi unnlatt å sette store begrensninger på utvidelsesmuligheter. For eksempel vil en kunne implementere nye visninger for bruk i rammeverket.

1.5.2 UtviklingsfaserI oppstarten av prosjektet valgte vi å arbeide etter UP-light metoden som er en lettvektsversjon av Unified Process. Vi hadde med både XP (eXtreme Programming) og Scrum i vår vurdering av utviklingsmetode.

I XP er et av hovedpunktene i utviklingen parprogrammering. Denne måten å programmere på består i at to og to personer programmerer sammen. Vi har prøvd ut denne måten i andre fag på skolen og ville ikke bruke dette i prosjektet. Det kunne også bydd på problemer at vi var tre personer på gruppen.

Scrum har korte daglige stående møter som et av sine hovedpunkter, og siden vi kom til å jobbe en god del hjemmefra ville dette by på problemer slik at vi ikke valgte denne metoden.

Vanlig UP har mange artefakter som må være med, mens i lettvektsversjonen er det ikke behov for å lage artefakter kun fordi det skal gjøres. Her lages det isteden artefakter etter behov. Arbeidet foregår iterativt og består av ulike faser. Disse fasene er idéfase, utdypningsfase, konstruksjonsfase og overgangsfase.

Vi har ikke fulgt denne utviklingsmetoden nøyaktig, men har heller brukt den som en veiledning underveis. I følge UP-light skal blant annet hver iterasjon i konstruksjonsfasen føre til ferdig dokumentert, testet og implementert produkt. Vi har kodet, skrevet kommentarer og testet underveis at det vi har gjort kodet fungerer, men har ikke alltid hatt et ferdig produkt etter hver iterasjon. Overgangsfasen har vi hatt helt mot slutten av prosjektperioden. Da drev vi med litt optimalisering av kode før systemet ble overlatt til oppdragsgiver, i denne fasen skrev vi også det meste av prosjektrapporten.

Oppstart (Idéfase)I oppstarten hadde vi svært få detaljer klare, og måtte bruke mye tid til å stille spørsmål og undersøke forskjellige muligheter. Dette var viktig for at vi skulle få et godt utbytte av prosjektarbeidet, og at oppdragsgiver skulle få levert et godt resultat. Vi forsøkte å danne oss et godt bilde av hvordan systemet skulle bygges opp etter hvert som informasjonen vi ønsket kom på plass. I Denne fasen begynte arbeidet med kravspesifikasjonen.

Ved prosjektets oppstart var det viktig for oss å undersøke de mange mulighetene for implementering av systemet. Dette fordi vi ønsket et godt strukturert system, som enkelt skulle kunne videreutvikles på et senere tidspunkt. Her endte vi opp med å designe et forenklet klassediagram som fulgte arkitekturen til en Model – View – Controller. På denne måten fikk vi en god oversikt over hvordan vi ønsket at programmet skulle henge sammen allerede fra starten, samtidig som vi ikke behøvde å bruke mye tid på å fokusere på detaljer.

Prosessdokumentasjon for Project Sunstone 11

En videreutvikling av dette diagrammet vises i produktdokumentasjonens figur 2.1 (kapittel 2.7).

Planlegging/Valg (Utdypningsfase)De aller fleste valgene vi har gjort har vært relatert til oppbyggingen av systemet, hvordan vi skulle lagre informasjonen vi hadde behov for, og hvilke biblioteker med kildekode vi har ønsket eller hatt behov for å bruke. Kravspesifikasjonen ble utdypet i denne fasen. Vi skisserte også hvordan vi ønsket at brukergrensesnittet skulle se ut. Her brukte vi både penn og papir og mer avansert bilderedigeringsprogram slik som figur 1.1 og figur 1.2 viser eksempler på.

Figur 1.1 GUI skisse

Prosessdokumentasjon for Project Sunstone 12

Figur 1.2 Grovt skissert GUI

Utvikling (Konstruksjonsfase)Siden vi er tre personer på gruppen og vi alle har ulik kodestil bydde dette på problemer i begynnelsen. Det ble skrevet uoversiktlig kode og dermed vanskeligere for oss å forstå koden som hadde blitt implementert av de andre på gruppen. På grunn av dette og for å gjøre koden enklere å forstå for eventuelle senere utviklere, har vi skrevet en kodestil. Denne er skrevet på engelsk siden oppdragsgiver har tenkt at dette rammeverket skal være åpen kildekode og dermed kan videreutvikles av andre enn norskspråklige utviklere. Denne kodestilen ligger som vedlegg.

Ettersom vi har jobbet med å utvikle programvare, har størsteparten av utviklingsfasen vært brukt på programmering. Under utviklingsfasen har vi dessuten brukt mye tid på undersøkelse av de ulike implementeringsmulighetene, slik at vi har kunnet gjøre gode beslutninger. Dette har vært svært viktig, slik at vi har kunnet ende opp med et produkt som henger sammen på en ønskelig måte. I denne fasen har vi også jobbet med å finne testcases som vi kunne bruke i testingen av systemet og til demonstrering av systemet. De bildene vi har brukt har blitt hentet fra Google Picasas web-album. Lisensen bildene er lagt under er Creative Commons (http://creativecommons.org/licenses/by-sa/3.0/). Vi har sjekket at disse bildefilene inneholder Exif-informasjon slik at de gir et resultat fra klassifikatorene når de skannes gjennom disse.

TestingVi har gjort en rekke tester underveis i prosjektet for at sikre oss at de mest tidkrevende prosessene i systemet blir utført på en effektiv måte. Disse testene har stort sett foregått ved å implementere forskjellige muligheter, for så å velge ut den som gir det mest ønskelige resultatet. De enkelte delene av rammeverket er også testet underveis ved hjelp av vanlige debuggingsmetoder, slik at vi for eksempel har kunnet vurdere om input og output fra

Prosessdokumentasjon for Project Sunstone 13

forskjellige metoder er som forventet. Vi har også utført en del testing av programflyt på det ferdige systemet helt mot slutten av prosjekttiden. Dette er for å sørge for at de ulike delene også fungerer sammen på en god måte. En mer detaljert beskrivelse av testing blir gjort rede for i testdokumentasjonen, som vil si del 4.

DokumentasjonUnderveis i prosjektet har vi prøvd å skrive ned viktige hendelser i prosjektdagboken slik at det skulle være enklere å skrive sluttdokumentasjonen når den tid kom. Prosessdokumentasjonen startet vi med først siden vi kunne hente en del informasjon fra forprosjektrapporten. Vi har også kunnet skrive ned notater i denne underveis i løpet av utviklingsfasen. Hoveddelen av denne fasen har blitt utført mot slutten av prosjektperioden.

1.5.3 Utfordringer og problemer

MainWindowVi hadde et ønske om at det i brukergrensesnittet skulle være lettvint for brukeren og flytte, minimere og forstørre de enkelte mindre vinduene. Dette viste seg ikke å være like enkelt å implementere som vi i første omgang trodde. Problemene som oppstod i forbindelse med dette var å få rett størrelse på de mindre vinduene ved forstørring og minimering. Dette problemet løste vi ved å prøve ut forskjellige metoder og velge den beste av disse. Det ble gjort forsøk på å bruke Javas funksjonalitet for interne vinduer, men vi gikk etter hvert over til å benytte oss av vanlige paneler.

ClassifierViewEttersom klassifikatorene som skal brukes i rammeverket må kunne utvikles og installeres uten behov for å rekompilere programmet, har vi måtte utvikle en fleksibel metode for visning av disse i brukergrensesnittet. Dette er gjort ved hjelp av en layout-manager som på mange måter er mer avansert en de mest brukte layout-managerne. For å mestre dette problemet har vi i stor grad benyttet oss av Javas veiledningsdokumenter tilgjengelig på Sun sine hjemmesider. Ved hjelp av disse har vi kunnet lære oss hvordan en kan implementere Swing komponenter som bruker denne layout-manageren. Vi er svært fornøyde med denne implementasjonen, ettersom vi mener den er svært plassbesparende, tiltalende og fungerer godt med muligheten vi ønsker å gi brukeren til å endre størrelse på de enkelte komponentene.

ThumbnailViewDet har vært en utfordring for oss å kunne utvikle en god visning av brukerens bilder til skjermen, ettersom de også skulle ha funksjonalitet som knapper, og kunne modifiseres rakst etter hvert som brukeren foretar valg blant klassifikatorene. Ettersom rammeverket er ment å brukes sammen med store samlinger bilder, har vi også måtte tenke ut implementasjonsmuligheter som ikke sløser med maskinens minne. For å få til dette på en god måte har vi benyttet oss av diskusjonstråder på Sun sine offisielle diskusjonsforum. Ble det stilt spørsmål om hvordan en generell thumbnailvisning kunne implementeres. Dette medførte at vi fikk råd som har hjulpet oss med å tenke ut alternative løsninger som vi kanskje ikke ellers ville ha kommet på.

Som følge av dette, fikk vi etter en kort stund tenkt ut en implementasjon som kunne løse de viktigste problemene som oppsto i vår implementasjon av thumbnailvisningen. Dermed

Prosessdokumentasjon for Project Sunstone 14

kunne vi forbedre skalerbarheten i applikasjonen med en stor margin. Den største samlingen som er testet med thumbnailviewet alene er på 10000 bilder, noe som har gått greit uten å måtte allokere mer minne til Javas virtuelle maskin. Denne implementasjonen blir beskrevet i produktrapporten med større fokus på detaljer.

CoreKlassifikatorer lastes inn dynamisk fra en mappe, her måtte vi slå opp på nettet for å finne ut hvordan man laster inn et objekt fra fil mens programmet kjører og likevel kunne bruke dette objektet som om det var en del av prosjektet. Det var også viktig å kontrollere om det innlastede objektet var av rett type.

I Core har vi hatt store utfordringer med å designe en måte å kommunisere mellom alle delene i systemet. Ettersom vi har designet et objektorientert og utvidbart system har vi laget mange deler som må snakke sammen. Dette gjøres gjennom Core. For eksempel spør brukergrensesnittet Core om hvilke bilder som skal vises i grensesnittet og dette finner Core ut av ved å bruke DatabaseWrapperen og klassifikatorene.

Core er også det som drar igang programmet ved å laste inn de forskjellige delene av systemet. Rekkefølgen er viktig og det gis også tilbakemelding til brukeren om fremdrift og status.

En klassifikator kan være avhengig av å motta verdier den behøver. Dette kan være Exif-informasjon eller informasjon fra andre klassifikatorer. Dermed må alle klassifikatorer som er installert i programmet sorteres på en slik måte at alle verdier fra andre klassifikatorer de er avhengige av å ha, allerede må være lagt inn i systemet.

Det har vært en utfordring å oppdage sykler i klassifikator avhengighet. Dette har vi løst som beskrevet i produktdokumentasjonen.

Før bilder legges til i datastrukturen hentes metadata fra bildet. Vi valgte å legge denne funksjonaliteten i en wrapper klasse vi kalte ExifWrapper. Dette gjorde vi for at man senere skulle kunne endre på hvordan metadata trekkes ut av bildet. I likhet flyttet vi alt som har med SQL og databasen å gjøre inn i en wrapper klasse vi kalte DatabaseWrapper.

Vi gjorde et forsøk på å få brukergrensesnittet til å kunne brukes mens programmet forsatt lagde miniatyrbilder. Men dette hadde en negativ konsekvens. Vi hadde ingen god måte å legge miniatyrbilder inn i brukergrensesnittet etter hvert som disse ble laget. Dermed måtte alle bilder legges inn på nytt for hvert nye miniatyrbilde som ble generert. Derfor gikk vi bort fra dette, men dette vil være en mulig utvidelse i fremtiden.

KlassifikatorenInformasjon om bilder fra må gis til klassifikatoren sånn at den kan prosessere disse og gi bildet en verdi. Ettersom det kan være snakk om flere input verdier valgte vi å bruke en generisk datastruktur. Dette betyr at man kan sende nesten hva som helst som input til en klassifikator.

Prosessdokumentasjon for Project Sunstone 15

En annen utfordring var at vi måtte sende verdier gitt av klassifikatorene til Core for lagring. Her tenkte vi først at den datastrukturen som blir sendt som input til klassifikatoren skulle modifiseres. Dette valgte vi å gå bort fra siden det ville kunne være forvirrende for klassifikatorutvikleren. Derfor valgte vi heller at klassifikatoren har to metoder for skanning; En for skanning av enkelt bilde og en for skanning av flere bilder samtidig. Verdien returneres i form av et objekt, som er en generisk datatype i Java.

Klassifikatoren er et API for å utvikle klassifikatorer. Vi har brukt mye tid på å kunne støtte alle klassifikator ideene fra oppdragsgiver og også lage et så generisk som mulig grensesnitt.

Derby DatabaseDerby støtter ikke MySQL syntaks som vi har jobbet med tidligere og dette gjorde at mange av metodene i DatabaseWrapperen måtte implementeres annerledes en vi hadde tenkt. Siden vi bestemte oss for å lagre objekter i databasen måtte dette gjøres på en måte vi aldri hadde brukt før og dette skapte litt problemer til å begynne med. En nærmere beskrivelse av hvordan vi har brukt Derby blir gitt i produktdokumentasjonen.

1.5.4 Forhold til oppdragsgiverVi har hatt en noe spesielt forhold til vår oppdragsgiver, med tanke på at han også har fungert som vår interne veileder ved Høgskolen i Oslo. Vi har ingen negative tilbakemeldinger på vårt samarbeid i løpet av prosjekttiden. Vi har følt at vi har blitt tatt seriøst, og at vi har hatt gode muligheter for å komme med innspill og spørsmål der vi har ønsket dette. Oppdragsgiver har også vært tilgjengelig per e-post gjennom hele perioden, i tillegg til ukentlige møter på høgskolen.

1.6 Kravspesifikasjonen og dens rolleKravspesifikasjonen er en egen del av rapporten og kan leses i kapittel 3.

1.6.1 RolleKravspesifikasjonen har hatt en betydelig innvirkning på arbeidet gjennom hele prosjektet, ettersom den beskriver hvilke funksjoner og muligheter vi har måtte rette oss etter. Kravspesifikasjonen har fungert som en sjekkliste som vi har kunnet bruke underveis, sammen med Gantt-diagrammet for å få oversikt over hvordan prosjektarbeidet ligger an.

1.6.2 EndringerKravspesifikasjonen ble ikke fastsatt tidlig i prosjektperioden, ettersom det var nødvendig for gruppen å sette seg godt inn i oppgaven og dens muligheter. Den ble isteden ferdigstilt et stykke ut i prosjektperioden. Et resultat av dette har vært at vi kunne finne en god løsning på en rekke viktige implementasjonsproblemer. Dessuten var det kun et fåtall krav som var fastsatt fra prosjektets oppstart. Prosjektoppgaven har vært svært åpen for innspill fra oss, angående hvordan vi ønsket å implementere rammeverket. Dermed var det behov for å ha noen møter med oppdragsgiver før vi kunne få på plass en god kravspesifikasjon. Av denne grunn og vårt valg av utviklingsmodell er ingen av kravene blitt endret siden siste iterasjon av kravspesifikasjonen.

Vi har nummerert kravene i kravspesifikasjonen slik at vi enkelt har kunnet gå igjennom denne ved prosjektets avslutning og sikre oss at hvert krav er tilfredsstilt. Dette går frem av

Prosessdokumentasjon for Project Sunstone 16

kapittel 2.4 i produktdokumentasjonen. Ettersom gjennomgang av denne har vist at alle krav er oppfylt, mener vi at det ferdige produktet står godt i samsvar med produktet som blir beskrevet i kravspesifikasjonen.

1.7 Om resultatetVi er svært fornøyde med resultatet av vårt hovedprosjekt, ettersom vi mener vi har klart å oppfylle kravene til systemet på en tilfredsstillende måte. Resultatet kunne nok blitt noe annerledes dersom vi hadde endret på noen prioriteringer i begynnelsen av prosjektet. Videre mener vi at systemet har nådd målene som ble satt for en første versjon av dette produktet.

1.8 Avslutning

1.8.1 Eget utbytteVi føler vi har fått mye ut av dette prosjektet. Vi har lært en del nytt om databaser, Exif informasjon, implementering av MVC på større programvareprosjekter og hvordan en kan jobbe effektivt på et større prosjekt uten å miste oversikten over de enkelte delene. Samtidig har prosjektet vært en spennende utfordring, der vi har hatt muligheten til å vise at vi kan mestre å lage et meningsfylt produkt for en oppdragsgiver vi ikke er kjent med fra før.

1.8.2 Hva kunne blitt gjort annerledesVi kunne ha brukt mer tid til planlegging av arbeidet, og på denne måten fått en mer jevn arbeidsprosess, i stedet for å ende opp med en skjev fordeling med spesielt mye arbeid mot slutten av prosjektet.

Dersom vi hadde påbegynt arbeidet med brukergrensesnitt på et tidligere stadium, kunne dette ha gitt oss nok tid til å feilteste produktet bedre. Ved å sette av mer tid til utvikling av GUI kunne vi også benyttet oss av akseptansetester for å forbedre rammeverket ytterligere.

Det ville vært en god ide å bruke et program for versjonskontroll til dette prosjektet. På denne måten kunne vi letter ha holdt oversikt over de mange programversjonene som er utviklet i løpet av dette prosjektet. Allikevel mener vi at vi har klart å håndtere dette på en god måte, gjennom bruk av skolens Fronter nettsted og vår egen prosjektside. Begge disse har god funksjonalitet for strukturering av filer med dato og navn.

Når det gjelder prosessen med utvikling av de ulike dokumentasjonsdelene kunne vi gjerne fordelt denne over en lengre periode. Vi kom godt igang med produsering av dokumenter i prosjektets oppstart, men det ble etter hvert programmeringen som tok overhånd. Dette har ført til at mesteparten av dokumentasjonen er skrevet mot slutten av prosjektet.

1.8.3 FremtidenOppdragsgiver hadde et ønske om at systemet skulle legges ut som åpen kilde kode slik at det kan videreutvikles av personer som har interesser innenfor emnet. Hvis dette blir gjort kan produktdokumentasjonen, testdokumentasjonen og brukermanualen relativt enkelt oversettes til engelsk slik at de som ikke er norskspråklige også kan sette seg inn i systemet. Kodestilen og vedlegget om klassifikatorutvikling er allerede skrevet på engelsk slik at disse ikke må oversettes.

Prosessdokumentasjon for Project Sunstone 17

Dette var første versjon av systemet, og det kan med fordel gjøres forbedringer med hensyn på blant annet effektivitet i forhold til tid når bilder skannes.

Vi håper denne applikasjonen kan bli til nytte for brukere og at det finnes noen som vil

videreutvikle den slik at den kan bli enda mer nyttig.

Prosessdokumentasjon for Project Sunstone 18