HOVEDPROSJEKT. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs Plass, 0130 Oslo Besøksadresse: Holbergs Plass, Oslo

Transkript

1

2

3 PROSJEKT NR TILGJENGELIGHET Åpen Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs Plass, 0130 Oslo Besøksadresse: Holbergs Plass, Oslo Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Noark 5 - Dokumentfangst DATO 27. mai 2011 ANTALL SIDER / BILAG 142 PROSJEKTDELTAKERE Daniel Brunstad Diakoff Lars-Erik Arnesen Joakim Vorren INTERN VEILEDER Eva Hadler Vihovde OPPDRAGSGIVER Høgskolen i Oslo KONTAKTPERSON Thomas Sødring SAMMENDRAG Oppgaven har gått ut på å lage løsninger på to problemer presentert av oppdragsgiveren. Den ene løsningen er en arkiveringsløsning for meldinger på Facebook, den andre er en arkiveringsløsning for tekstmeldinger på smarttelefoner. Applikasjonene er utviklet i henholdsvis ASP.NET, C# og Java. I tillegg brukes det HTML, CSS, JavaScript, Facebook SDK og Facebook Graph API i Facebookapplikasjonen og Android SDK i Mobilapplikasjonen. For kommunikasjon med Noark-kjernen benyttes SOAP. Som web- og arbeidsserver bruker vi Microsoft Windows Server 2008 med Team Foundation Server. Vi har lagt ned svært mye arbeid i dette prosjektet, og er blitt meget fornøyd e. 3 STIKKORD Facebook Tekstmeldinger Arkiv

4

5 Forord Dette er rapporten for hovedprosjektgruppe 33, Den inneholder fire deler: Prosessrapporten, produktrapporten, brukermanual for FIR og brukermanual for Marc. Rapporten er skrevet av Daniel Brunstad Diakoff, Lars-Erik Arnesen og Joakim Vorren og ble utarbeidet i april/mai Det er et forord for hver del i rapporten som sier litt om hva delen inneholder, og hva som er likt med andre deler. Prosjektet har gått ut på å utvikle programvare som har som hensikt å sende journalføringspliktige dokumenter inn til en Noark server. Det endelige produktet består av tre programmer (FIR, Marc for mobil, og Marc for PC). Kildekoden er tilgjengelig på prosjektets hjemmeside på denne adressen: På denne siden finnes også dokumentasjonen i sin helhet. Oslo, 27. mai 2011

6

7 Prosessdokumentasjon... 2 Produktdokumentasjon Brukerveiledning FIR Brukerveiledning Marc Ordliste & terminologier

8

9

10

11 Forord Denne delen av rapporten vil ta for seg de tekniske sidene av applikasjonene. Den er delt opp slik at hver applikasjon har sitt eget kapittel som tar for seg alt ved den applikasjonen. Kapittel 1 (innledningen) og 2 (det endelige produktet) er de samme som kapittel 1 og 2 i produktdokumentasjonen. Det er derfor ikke nødvendig å lese disse kapitlene dersom De har lest de tilsvarende i produktdokumentasjonen.

12

13 Innholdsfortegnelse 1 Innledning Om Noark Dagens situasjon Vårt prosjekt Gruppen Oppdragsgiver Det endelige produktet Facebookapplikasjon (FIR) Mobil- og skrivebordsapplikasjon Planlegging og forberedelser Gruppen blir til Valg av oppgave Analyse Kostnad Mål og rammebetingelser Oppstartsfasen Roller i gruppen Samarbeid og møter Styringsdokumenter Metodikk Rapid Application Development Teknologier Noark Valg av utviklingsverktøy Facebookapplikasjon Mobil -og skrivebordsapplikasjon Utviklingsteknologier NET Android Andre tekniske hjelpemidler Dropbox Google Docs Utviklingsprosessen FIR (Facebookapplikasjon) Kommunikasjon med Facebook Side 6 av 135

14 6.1.2 FIR Tidlig prototype Fra skrivebordsapp til webapp Utvikling i henhold til kravspesifikasjon Marc (Android applikasjon) Selvlæring i Android Fra daemon til full brukerinteraksjon Utvikling i henhold til kravspesifikasjon Utfordring med meldinger Eksportering til XML Marc (skrivebordsapplikasjon) Oppsett av Noark Testing Brukertesting FIR Marc Foredrag for målgruppen Kravspesifikasjonen og dens rolle Kravspesifikasjon Endringer etter oppdragsgivers ønsker Innfrielse av kravene Avslutningsfase Ferdigstilling av prosjektet Konklusjon Kilder Vedlegg Arbeidsplan Fremdriftsplan Risikoanalyse Side 7 av 135

15 Side 8 av 135

16 Side 9 av 135

17 Prosessdokumentasjon Kapittel 1: Innledning 1 Innledning Dette kapittelet er identisk med kapittel 1 i prosessdokumentasjonen, og det er derfor ikke nødvendig å lese det dersom du har lest den. Denne delen består av prosessdokumentasjon. Først vil du få en innføring i prosjektet, gruppen og oppdragsgiver. 1.1 Om Noark Norsk arkivstandard (Noark) er en standard for elektroniske journalsystemer som stiller krav til arkivstruktur, metadata og funksjonalitet. Noark 5 skal kunne brukes for alle typer arkivdanning, uavhengig av teknologisk løsning og type organ. Alle former for aktiviteter som skaper dokumenter som det er viktig å sørge for at oppbevares og gjenfinnes i autentisk form, skal i prinsippet inngå i en løsning for arkivdanning. Dette er helt uavhengig av offentlig eller privat sektor, om dokumentene inngår i tradisjonell saksbehandling, hvor mange år de skal oppbevares eller om de skal avleveres til depotarkiv. Noark 5 er den siste utgaven av Noark-standarden, og ble publisert sommeren Fra og med mars 2011 er Noark 5 versjon 3.0 gjeldende versjon. Figur 1.1: Noark 5 kjernen Side 10 av 135

18 Kapittel 1: Innledning Noark 5 Dokumentfangst 1.2 Dagens situasjon Mye av informasjon som finnes på nettet i dag er ikke i et format som passer til å lagre i et dokument. Se f.eks. Facebook grupper(master i Hardanger), informasjonen som kommer ut herifra kunne vært fint å fått dokumentert, men er vanskelig pga. formatet det er i. Kommunikasjon per SMS mellom politikere og andre som jobber i offentlig virksomhet, blir i dag ikke arkivert eller gjort tilgjengelig for ande. Et problem som ble tydelig da Jens Stoltenberg sendte en SMS til DnB Nor-sjefen i 2008, hvor det ble kritisert om at en politiker hadde hatt uoffisiell kontakt om politiske beslutninger. Ved hjelp av Noark og nødvendig programvare på mobiltelefonen skal det være mulig å arkivere denne type kommunikasjon. 1.3 Vårt prosjekt I forbindelse med oppdragsgivers arbeid med Noark 5, og et ønske om dokumentfangst fra utradisjonelle kilder, har vi utviklet 3 applikasjoner. En mobilapplikasjon som gjør tekstmeldinger tilgjengelig for en skrivebordsapplikasjon. Denne skrivebordsapplikasjonen tar seg av journalføring og arkivering til Noark-arkivet. Det er også utviklet en facebookapplikasjon som i likhet med skrivebordsapplikasjonen tar seg av journalføringen og arkivering, men da med meldinger fra Facebook. 1.4 Gruppen Prosjektgruppen består av tre it-studenter ved Høgskolen i Oslo: Joakim Vorren 22år, Lars-Erik Arnesen 24år og Daniel Brunstad Diakoff 21år. Alle tre kjenner hverandre godt fra tidligere prosjekter i forbindelse med bachelorgraden i informasjonsteknologi. 1.5 Oppdragsgiver Høgskolen i Oslo (HiO) ble opprettet 1. august 1994 og er landets største høgskole med studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelorstudier og over 20 masterstudier. Forskning og utvikling (FOU) ved Avdeling for journalistikk, bibliotek- og informasjonsfag (JBI) består pr av 3 professorer, 18 f. amanuenser, 1 forsker, 6 lektorer, 20 høgskolelektorer, 1 høgskolelærer og 7 dr. gradsstipendiater. Blant fagpersonaler er det 15 med dr. grad. Vår kontaktperson, Thomas Sødring er førsteamanuensis ved JBI og har i lengre tid jobbet med utvikling av Noark 5. Side 11 av 135

19 Prosessdokumentasjon Kapittel 2: Det endelige produktet 2 Det endelige produktet Dette kapittelet er identisk med kapittel 2 i prosessdokumentasjonen, og det er derfor ikke nødvendig å lese det dersom du har lest den. Her følger en kort beskrivelse av produktet vi har laget. Mer informasjon om funksjonalitet og bruk vil komme i produktdokumentasjonen og brukerveiledningen. 2.1 Facebookapplikasjon (FIR) Facebookapplikasjonen, eller Facebook Information Retriever som vi har døpt den, har som funksjon å hente og lagre informasjon som brukeren definerer som journalføringspliktig. Figur 2.1: Facebookapplikasjon (FIR) Applikasjonen henter inn alle grupper, sider og arrangementer som brukeren administrerer. Brukeren kan så velge en gruppe, side eller arrangement han vil journalføre, velge hvilke meldinger han vil ha med, merke disse og få opp en forhåndsvisning. Er brukeren fornøyd, kan han/hun velge å sende inn og dokumentet vil bli gjort om til et format Noark kan håndtere, og lagres i arkivet. Side 12 av 135

20 Kapittel 2: Det endelige produktet Noark 5 Dokumentfangst Figur 2.2: Dataflyt til facebookapplikasjon (FIR) 2.2 Mobil- og skrivebordsapplikasjon Den andre løsningen består av to applikasjoner. Den ene er en mobilapplikasjon på Android som viser deg en liste over personer du har sendt meldinger med, enten med navn du har lagret i kontaktlisten din, eller med nummer om du ikke har de lagret. Du kan videre velge personer, og lagre meldinger fra disse på minnekortet til mobilen i en XML fil. Denne filen kan enkelt transporteres til PC og deretter videre inn til Noark. Figur 2.3: Dataflyt til Marc Når du nå kobler mobilen til PC-en skal vi ta i bruk den andre delen av løsningen. Dette er en skrivebordsapplikasjon som finner mobilen, og henter ut meldingene som vi nå har lagret på mobilens minnekort. Her kan du igjen velge personer, og hvilke meldinger fra valgt person du vil ha arkivert. Etter dette er det bare å velge send inn, og meldingene blir gjort om til et format Noark kan håndtere og arkiveres i arkivet. Figur 2.4: Marc (mobilapplikasjon) Side 13 av 135

21 Prosessdokumentasjon Kapittel 2: Det endelige produktet Figur 2.5: Marc (skrivebordsapplikasjon) Side 14 av 135

22 Kapittel 3: Planlegging og forberedelser Noark 5 Dokumentfangst 3 Planlegging og forberedelser Dette kapittelet tar for seg den tidlige begynnelsen av prosjektet. Handler om hvordan gruppen ble til, valg av oppgave, analyse av kostnader, mål og rammebetingelser vi satt oss og hvilke ressurser vi har hatt tilgang på under prosjektperioden. 3.1 Gruppen blir til En varm ettermiddag sensommeren 2010, tre studenter, Lars-Erik, Joakim, og Daniel setter seg ned på en pub på Aker Brygge for å diskutere hovedprosjekt. Alle er på sisteåret bachelor i Informasjonsteknologi og alle er klare for et nytt studieår. De diskuterer å ta med et fjerde medlem, men dessverre har han ikke nok studiepoeng til å melde seg opp til hovedprosjekt. Like greit, han droppet ut uken etterpå. Diskusjonen fortsetter, de bestemmer seg for kun å være 3 på gruppen. 3.2 Valg av oppgave Oppgaven valgte vi etter at vi hadde vært innom en del andre prosjektforslag først. Vi hadde først en mulig avtale med KS om de kunne stå for hovedprosjekt til oss. De hadde dessverre ingen mulige hovedprosjekt for oss, så vi begynte å se oss om etter andre mulige prosjekt. Vi fant et spennende et for Accenture, der vi sendte inn søknad. Vi holdt godt øye med prosjektsiden til hovedprosjektet denne tiden, for å se etter prosjekt. Fant et prosjekt der som gikk ut på å utvikle Noark standarden. Siden vi enda ikke hadde hørt fra Accenture tok vi kontakt med kontaktpersonen for Noark-prosjektet. Vi fikk kjapt tilbakemelding og hadde en introduksjon til prosjektet. Vi ringte Accenture og hørte, der vi fikk vite at de ikke hadde noe til oss. Da var egentlig valget enkelt, og vi gikk for prosjektet. 3.3 Analyse Her skrives det om analyser vi gjennomførte før vi startet med prosjektet Kostnad Som det kan leses ovenfor benyttet vi stort sett programmer som er kommersielle. Normalt vil man måtte betale Microsoft for å få løst ut lisensene. Det slapp vi siden Høgskolen i Oslo er medlem av et samarbeid, MSDN Academic Alliance, som ga oss mulighet til å bruke Microsoft-produktene i undervisningssammenheng. Android SDK og Eclipse er også gratis. Side 15 av 135

23 Prosessdokumentasjon Kapittel 3: Planlegging og forberedelser 3.4 Mål og rammebetingelser Målet med prosjektet er å påvise eller avkrefte om det er mulig å få informasjon fra nyere sosiale medier (Facebook, tekstmeldinger) i et Noark format. For å besvare denne teorien har vi utviklet tre applikasjoner. Facebook-applikasjon o Henter meldinger fra grupper, arrangementer og sider på Facebook. o Krever at brukeren er administrator eller eier av informasjonen som innhentes. o Bearbeider informasjonen før det arkiveres i Noark-arkivet. Mobilapplikasjon for lagring av tekstmeldinger o Lagrer tekstmeldinger på mobilen. Skrivebordsapplikasjon for arkivering av tekstmeldinger o Henter tekstmeldinger fra mobiltelefon. o Sender tekstmeldinger til arkiv. Side 16 av 135

24 Kapittel 4: Oppstartsfasen Noark 5 Dokumentfangst 4 Oppstartsfasen Oppstartsfasen omhandler rollefordeling innad i gruppen, møter og samarbeid, styringsdokumenter vi har opprettet og hvilken metodikk vi har brukt (RAD). 4.1 Roller i gruppen For samarbeidet i gruppen var det viktig å dele inn i roller, slik at alle fikk et ansvarsområde de kunne fokusere mere på. Selv om rollene ble bestemt på forhånd, har vi i stor grad arbeidet på tvers av disse, uten problem. Gruppeleder, kontaktperson og en sekretær ble valgt, men under hele prosjektet har vi hatt fokus på å ta avgjørelser i felleskap for å sikre kvaliteten i arbeidet vi gjorde. Navn Daniel Brunstad Diakoff Joakim Vorren Lars-Erik Arnesen Hovedrolle Gruppeleder Kontaktperson Sekretær Gruppeleder Som leder for gruppen har han det overværende ansvaret når det gjelder samarbeidet. Ansvarsområder innebærer reservasjon av grupperom, avtale møter, kontaktperson ved sykdom eller andre komplikasjoner. Kontaktperson Har ansvar for kontakten med oppdragsgiver. Det innebærer å avtale møter, svare på henvendelser fra oppdragsgiver. Sekretær Hovedansvaret ligger i å skrive møtereferat, ferdigstille dokumenter og delegere ansvar for dokumentskriving til de andre gruppemedlemmene. 4.2 Samarbeid og møter Fra Høgskolen i Oslo fikk vi Eva Hadler Vihovde som veileder for prosjektet. Vihovde har vært en viktig og god ressurs når det gjelder utforming og skriving av rapport, tilbakemeldinger underveis og til rådføring hvis det var noe gruppen lurte på. Gruppen har hatt fokus på å møtes så ofte som mulig under prosjektperioden. Vi hadde derfor faste dager i uken hvor vi jobbet sammen og diskuterte løsninger på problemer og hva som måtte gjøres framover. På grunn av dette nære samarbeidet hadde alle til enhver tid noe å gjøre, og når det dukket opp spørsmål om hvordan ting skulle løses, ble de ofte løst i plenum. Side 17 av 135

25 Prosessdokumentasjon Kapittel 4: Oppstartsfasen Vår oppdragsgiver Thomas Sødring var i likhet med Vihovde en viktig og god ressurs å ha for gruppen. Sødring veiledet og underviste gruppen om Noark 5 og dens oppbygning, noe som vi var svært avhengig av for å løse oppgaven. 4.3 Styringsdokumenter Kapittelet tar for seg styringsdokumenter og deres rolle i prosjektet Arbeids og fremdriftsplan Arbeidsplanen var et av de første dokumentene vi opprettet. Denne inneholder milepæler for når ting skal være ferdig. Gjennom hele prosjektet har vi prøvd å følge denne. Siden arbeidsplanen ble satt opp helt i starten av prosjektet, er det punkter vi har hatt med som har forsvunnet, rett og slett fordi vi ikke har sett noe behov for disse punktene i prosjektet. Andre punkter som vi gjerne skulle hatt mer tid til (testing) har måttet blitt nedprioritert for å få andre ting ferdig i tide. Arbeidsplanen er en del av vedlegget. Fremdriftsplanen er en grafisk versjon av arbeidsplanen. Her kan du se hvor mye tid vi har satt av til de forskjellige punktene, og hvilke punkter som kan jobbes parallelt med. Risikoanalyse Risikoanalysen er delt opp i 3 deler. En del som tar for seg mulige trusler, sannsynligheten for at de oppstår og konsekvensen av trusselen. En annen del tar for seg forhindrende arbeid, det vil si hva vi kan gjøre for å minimalisere sjansen for at en trussel vil oppstå. Vi har her navnet på trusselen og strategien for å minimalisere. Den siste delen er begrensende arbeid, det vil si når uhellet først er ute. Det er her delt opp i risikodel og strategi for å begrense uhellet. Prosjektdagbok Når gruppen kommer til sluttfasen av prosjektet er det ikke alltid like lett å huske alle valg og beslutninger man tok underveis. En prosjektdagbok ble opprettet i starten av prosjektet for å dokumentere hele prosessen. Det er et viktig dokument som gruppen har brukt under hele perioden for å skrive ned de problemene, valgene og spørsmålene som dukket opp. Etter hver arbeidsdag ble gruppen enig om hva som skulle være med fra den dagen og sekretæren skrev det ned. Under utviklingsfasen var dagboken veldig nyttig for å se hva de andre gruppemedlemmene hadde gjort. Vi kunne lettere hjelpe hverandre hvis vi støtet på problemer, og vi hadde allerede spørsmålene klare når vi skulle i møter med oppdragsgiver og veileder. Kravspesifikasjon Vi satte opp en kravspesifikasjon etter oppdragsgivers ønsker og de undersøkelsene vi hadde gjort. For å lage en kravspesifikasjon undersøkte vi blant annet Facebooks Side 18 av 135

26 Kapittel 4: Oppstartsfasen Noark 5 Dokumentfangst personvernpolicy, Noark sitt grensesnitt, samt utviklingsverktøy og rammeverk for Android for å nevne noen. Kravspesifikasjonen skulle hjelpe oss til å få en felles forståelse og enighet av produktet. Rammer og betingelser var også viktig i vår sammenheng, da vi har applikasjoner som må samhandle med hverandre. 4.4 Metodikk Som et FoU-prosjekt basert på en proof of concept løsning har vi i løpet av prosjektet vært opptatt av å produsere regelmessige utgaver av applikasjonene i kortere iterasjoner. Oppdragsgiver hadde ingen krav til utviklingsmetodikk, men ønsket å være en del av prosessen som en veileder når det kom til elektronisk journalføring og arkivering. Prototyping ble benyttet i starten for å redusere risker for misforståelser mellom oppdragsgiver og gruppen. Vi fikk også en bedre forståelse av produktet og de kravene vi måtte stille. Tilbakemeldingene vi fikk på prototypen ble brukt til videreutvikling av applikasjonene. Dette førte til at vi kom raskt i gang med utviklingen av det endelige produktet og at det resultatet av det også reflekter de ønskene oppdragsgiver hadde Rapid Application Development Rapid application development (RAD) er en utviklingsmetodikk som bruker minimalt med planlegging til fordel for prototyping. Utvikling av programmet er en del av planleggingen. Det medfører at programvaren blir raskere utviklet og det er lettere å forandre på kravene underveis. Det starter med at man i første fase analyserer og utformer data- og prosessmodeller. I neste fase blir kravspesifikasjonen verifisert ut i fra prototyping. Og til slutt forandrer man modellene. Disse fasene gjentas iterativt. Fordelene med RAD er at det fremmer samarbeid i gruppen og dynamisk samling av krav. Ulempene er at man er avhengig av en sammenhengende gruppe og individuelle engasjement i prosjektet. Beslutninger som blir tatt er avhengig av en kompetent gruppe hvor alle kan bidra og i mindre grad av en sentralisert prosjektledelse. Figur 4.1: RAD Side 19 av 135

27 Prosessdokumentasjon Kapittel 4: Oppstartsfasen I en tradisjonell metodikk er man mye mer fastbundet til en plan og følger de samme kravene under hele prosjektet. Feil og misforståelser blir ikke rettet opp i like fort og man ender opp med å bruke mye tid på slutten. Krav fra kunden kan ha blitt endret når man er ferdig, og man risikerer i verste fall å måtte starte helt på nytt. Figur 4.2: Tradisjonell metodikk Side 20 av 135

28 Kapittel 5: Teknologier Noark 5 Dokumentfangst 5 Teknologier Dette kapittelet handler om hvilke teknologier vi har brukt under prosjektet. Det tar for seg oppbyggingen av Noark, argumentasjoner for valg av utviklingsverktøy, hvilke utviklingsverktøy vi har brukt i de forskjellige applikasjonene og andre tekniske hjelpemidler som har blitt brukt til blant annet versjonskontrollering og fildeling. 5.1 Noark Noark 5 indre kjerne er utviklet som tjeneste orientert arkitektur (TOA) av masterstudenter ved Dublin City Univirsity. TOA tankegangen går ut på å utvikle komponenter som lett kan settes sammen og integreres. Med en TOA kjøres programmet i en klient/tjener modell. Selve programmet som i vårt tilfelle er Noark, kjører i en applikasjonsserver som f.eks. JBOSS. Klientprogrammet kompileres mot grensesnittet til programmet i applikasjonsserveren og vil da kunne kommunisere over et grensesnitt så lenge det ikke endres. Applikasjonene som vi har utviklet i forbindelse med dette prosjektet kan sees på som klient i denne modellen. Figur 5.1: Tjenesteorientert arkitektur Noark-kjernen er bygget opp av flere lag med tjenestelaget på toppen som et grensesnitt ut til andre applikasjoner. Tjenestelaget oppretter en kontrakt som klientene er nødt til å ta i bruk for å kommunisere med tjeneren. For å beskrive tjenesten brukes WSDL, en velkjent standard måte for å etablere dialog mellom klient og tjener. Virksomhetslogikklaget er laget under tjenestelaget og hvor logikken er delt inn i klassestrukturer. Under virksomhetslogikken finner vi det ORM-baserte lagringslaget. I motsetning til tradisjonell opprettelse av en database, hvor vi først designer databasestrukturen, for så å tilpasse virksomhetslogikken i forhold til det, vil man med ORM-løsningen bruke data fra virksomhetslogikken til å beskrive datastrukturene i databasen, og en logisk beskrivelse av sammenhengen mellom de ulike data i systemet. Modellen viser også hva som skjer når bestemte hendelser inntrer og hvordan objektene i databasen oppfører seg. En fordel med ORM er at man ikke trenger å administrere databasen ved endringer i Side 21 av 135

29 Prosessdokumentasjon Kapittel 5: Teknologier virksomhetslogikken. Ved en forandring av virksomhetslogikken vil databasen automatisk reflektere endringene som ble gjort. I det nederste laget finner vi en relasjonsdatabase der all informasjons som blir avlevert til Noark havner. Figur 5.2: Lagene i Noark-kjernen. 5.2 Valg av utviklingsverktøy Dette kapittelet tar for seg prosessen vi gjennomgikk for å velge utviklingsverktøy. Vi stod ganske fritt med tanke på å utvikle dette prosjektet. Oppdragsgiver hadde ikke satt noe begrensing på valg av programmeringsspråk, kun det at vi må kunne kommunisere med Noark tjeneren som kommuniserer gjennom SOAP. Vi kom tidlig fram til at vi skulle bruke.net(c#) i det integrerte utviklingsmiljøet Microsoft Visual Studio Til utviklingen av mobilapplikasjonen kom vi til slutt fram til at vi skulle bruke Android SDK & emulator sammen med Eclipse. Samarbeidet i gruppen foregikk ved hjelp av versjonskontrollsystemet Microsoft Team Foundation og Microsoft SQL Server 2008 som ble installert på en server som kjører Microsoft Windows Server 2008 med IIS (Internet Information Services). Dette muliggjorde at vi kunne dele kildekoden mellom oss og ha den samme versjonen på tvers av maskinene vi jobber på. Datamaskiner som ble brukt som server under prosjektarbeidet, ble satt opp av gruppen selv. Side 22 av 135

30 Kapittel 5: Teknologier Noark 5 Dokumentfangst Valg av mobilplattform Før vi kunne velge hvilken mobilplattform vi ville utvikle for måtte vi finne ut hvilken plattform som ga oss mulighet til å få tak i all informasjonen vi ønsket. Vi satte derfor i gang med å finne ut hvilke funksjoner som vi trodde vi ville trenge for å kunne utføre oppgaven på en tilfredsstillende måte. Valget stod mellom Android, Windows Phone 7 og ios. Android Android er åpen kildekode og er eid av Google Inc. Dette operativsystemet er basert på linux. Det er den største smarttelefonplattformen, med over applikasjoner tilgjengelig på Android Marked. Dette gjør det lettere å finne eksempler på kode som utfører noe lignende av funksjonene vi var ute etter. Android har også en veldig informativ hjemmeside for utviklere, hvor du finner all informasjon du skulle ønske. Applikasjoner på Android blir skrevet i Java. Windows Phone 7 Windows Phone 7 er eid av Microsoft og er etterfølger til Windows Mobile. Applikasjoner blir skrevet i C# som betyr at vi kan bruke Visual Studio til å programmere i. Negative ting ved dette operativsystemet er at det er såpass nytt at det funksjonsmessig ikke er på samme nivå som konkurrentene, det er ikke bakoverkompatibelt og veldig få applikasjoner er ute i forhold til Android og ios. ios ios, også kjent som iphone OS, er Apple sitt mobile operativsystem. Var opprinnelig kun for iphone, men er senere blitt utviklet til å fungere med ipod, ipad og Apple TV. ios er basert på Mac OS X, som er et Unix operativsystem. Apples App Store inneholder mer enn ios applikasjoner, mer enn Android har på sitt Android Marked. ios blir skrevet i Objective-C. Det positive med å utvikle for dette operativsystemet er at det finnes mye dokumentasjon på Internett. Det negative er at det kun er lagt til rette for å programmere på Mac med Xcode som utviklingsverktøy. Endelig valg Valget falt til slutt på Android. Vi fant ut at dette ville være den plattformen som ville gi oss nok fleksibilitet til å kunne løse oppgaven. Vi var aldri helt sikre i begynnelsen på hvordan vi skulle gå fram for å lage mobilapplikasjonen, så det at det ligger så mange eksempler på nettet programmert på Android gjorde det lettere for oss å komme fram til en løsning Facebookapplikasjon For å lage Facebookapplikasjonen har vi benyttet oss av ASP.NET med C# som programmeringsspråk. Det var i grunn ingen andre alternativer vi vurderte utenom C#, da vi allerede hadde funnet en utviklingspakke (SDK) for Facebook for dette språket. Side 23 av 135

31 Prosessdokumentasjon Kapittel 5: Teknologier Når det kommer til uthenting av informasjon fra Facebook, blir dette tilbudt gjennom Facebooks Graph API, hvor man mottar informasjonen i JSON format, som lett lar seg håndtere. Applikasjonen kjøres på en Microsoft Windows Server 2008 maskin som vi har satt opp hos en av gruppemedlemmene Mobil -og skrivebordsapplikasjon Mobilapplikasjonen benytter seg av Android SDK og med programmeringsspråket Java. Den er laget for Android 2.1 og programmert i Eclipse Helios. Skrivebordsapplikasjonen er utviklet i C#. Det var lite tvil om det fra begynnelsen av, siden språket ikke har noe å si da informasjonen blir sendt mellom mobilen og datamaskinen i XML format. 5.3 Utviklingsteknologier Dette kapittelet tar for seg teknologiene vi har brukt under utviklingen av applikasjonene NET.NET rammeverket er i dag en av de mest brukte utviklingsplattformene i verden. For å kunne programmere mot Facebook krevde det at vi brukte eksterne biblioteker som lett kunne integreres i rammeverket. Facebook C# SDK Facebook C# SDK hjelper.net utviklere å lage applikasjoner som kan integrere med Facebook. Før utviklingen av facebookapplikasjonen kunne begynne, var vi nødt til å finne en måte å hente ut informasjon fra Facebook på som tokk hensyn til brukerens sikkerhet og de personvernsinnstillingene de har satt for sin konto. En relativ ny API kalt Graph gjorde det mulig å hente det ut som JSON eller XML objekter. Det fantes ingen offisiell utviklingsplattform for C# fra Facebook, så vi brukte litt tid på å finne en alternativ løsning. På Codeplex, Microsoft sin egen møteplass for fri programvare, fant vi Facebook C# SDK, som inkluderer den samme funksjonaliteten som den offisielle utviklingsplattformen Android Android er et mobilt operativsystem opprinnelig utviklet av Android Inc, et firma som ble kjøpt av google i Android er basert på en modifisert versjon av Linuxkjernen. Google og andre medlemmer av Open Handset Alliance har samarbeidet om Androids Side 24 av 135

32 Kapittel 5: Teknologier Noark 5 Dokumentfangst utvikling og lansering. The Android Open Source Project (AOSP) har i oppgave å vedlikeholde og videreutvikle Android. Android er verdens mestselgende smarttelefonplattform. 5.4 Andre tekniske hjelpemidler Kapittelet omhandler teknologier brukt til versjonskontroll, fildeling og rapportskriving Dropbox Dropbox er en nettjeneste som synkroniserer filer man har liggende lokalt på sin datamaskin med en nettverksharddisk eller skyen som mange vil kalle det. Ved å installere denne tjenesten hos alle gruppemedlemmene, kunne vi dele dokumenter med hverandre og sikre at alle hadde siste versjon til enhver tid. I tillegg til å ta sikkerhetskopi av filene, knytter den også de opp mot versjonskontroll. Det hjelper oss å finne tilbake til en gitt versjon når vi måtte ønske Google Docs Google Docs eller Google Dokumenter som det kalles på norsk, er en gratis nettbasert kontorpakke utviklet av Google som inneholder programmer som tekstbehandling, regneark og presentasjon. Gruppen brukte Google Docs til å skrive dokumenter, møteplanlegging og dele ressurser vi fant på Internett. Fordelene med Google Docs er at redigering av et gitt dokument kan gjøres av flere personer samtidig, og endringer vil for de andre brukerne gjengis med det samme (i sanntid). Side 25 av 135

33 Prosessdokumentasjon Kapittel 6: Utviklingsprosessen 6 Utviklingsprosessen Vi kom godt i gang med prosjektet før juleferien, og satte i gang med høy arbeidslyst på nyåret. På dette tidspunktet ønsket vi å programmere mobilapplikasjonen for Windows Phone 7, fordi da kunne vi programmert alle applikasjonene i.net rammeverket. I begynnelsen brukte vi god tid på teste ulike teknologier, og prøvde oss frem for å finne mulige løsninger på problemstillingen. Vi så på fordeler og ulemper ved de forskjellige mobilplattformene rett over jul for å finne ut om vi kunne holde oss til et programmeringsspråk. Se punkt 5.2 for begrunnelse for valget vi gjorde. Videre ble det gjort undersøkelser på hvilken måte som egnet seg best for å hente ut informasjon fra Facebook og hva som måtte gjøres for å få det i et format Noark kunne håndtere. Endringer i Facebook applikasjonen, hvorfor og mer om prosessen ved informasjonsuthenting kan leses i punkt 6.1. For å lære om utviklingsprosessen til mobil -og skrivebordsapplikasjonen, fra opplæring i Android, prosessen fra daemon til full brukerinteraksjon og løsning av problemer se punkt FIR (Facebookapplikasjon) Kapittelet tar for seg utviklingen av Facebookapplikasjonen. Hvordan applikasjonen kommuniserer med Facebook, tidlig prototype, utviklingen fra skrivebordsapplikasjon til webapplikasjon og utvikling i henhold til kravspesifikasjonen Kommunikasjon med Facebook Før utviklingen av FIR kunne begynne, var vi nødt til å undersøke hvordan vår applikasjon kunne kommunisere med Facebook. Facebook har i dag et mye brukt grensesnitt kalt Graph API, som lar utviklere hente informasjon fra Facebook til egne applikasjoner. Informasjonen i API-et blir presentert som JSON-objekter (f.eks. personer, bilder, arrangementer og sider) og koblingene mellom dem (f.eks. vennerelasjoner, delt innhold og bildetekster). Vi gjorde noen testforsøk mot Graph for å se hva slags informasjon vi fikk, hvordan formatet var, og hva som krevdes av rettigheter for å få tilgang til informasjonen. Resultatene av forsøkene, gjorde at vi ville fortsette med Graph. Det gjenstod bare å ta det i bruk i applikasjonen med en SDK. Som det kan leses i kapittel i avsnittet om Facebook C# SDK var det den beste SDK-en for vårt formål og utviklingsmiljø. Med dette implementert i applikasjonen kunne vi med metoder innebygget i SDK-en kommunisere med Facebook over Graph API. Noe av tiden gikk også til å lære seg SDKen og prøve nye versjoner etter hvert som vi utviklet FIR. Side 26 av 135

34 Kapittel 6: Utviklingsprosessen Noark 5 Dokumentfangst FIR Tidlig prototype Etter at undersøkelsene av Facebooks programmeringsgrensesnitt ble gjennomført satte vi i gang med å utvikle en prototype som skulle vise at det gikk an å hente meldinger fra en gruppe på Facebook. Det første som ble gjort da var å registrere en applikasjon på Facebook. Vi fikk da en applikasjons-id som kunne benyttes i programmet slik at vi kunne koble oss opp mot Facebook og få tilgang til informasjonen som lå der. Vi bygde opp applikasjonen i tre lag med et datatilgangslag, virksomhetslogikklag, og presentasjonslag. Lagdelingen ble gjort fordi vi ville sikre at koden var klar til gjenbruk ved en senere anledning og at det ville være mye lettere å flytte på koden når det lå i egne lag eller klassebibliotek enn om vi hadde det blandet sammen. Prototypen hadde et felt for ID til facebookgruppen og et felt for antall meldinger som skulle hentes. Meldingene som kom inn presenterte vi med en avhukingsboks for å illustrere at det gikk an å velge dem. Figur 6.1: Første prototype av FIR I løpet av noen få dager var prototypen klar og vi tokk den med til oppdragsgiver for å få tilbakemeldinger. Vi ble klar over at det var et sterkere ønske om en webapplikasjon fordi det ville være mere tilgjengelig for brukerne og i mindre grad plattformavhengig. Det var ikke mange funksjoner i denne utgaven, men den beviste likevel noe elementært. At det var mulig å hente informasjonen fra Facebook. Vi hadde oppnådd en milepæl og var sikre på at det ville være mulig å jobbe videre med dette. Side 27 av 135

35 Prosessdokumentasjon Kapittel 6: Utviklingsprosessen Fra skrivebordsapp til webapp Fra den første prototypen brukte vi mye av koden i det som skulle bli den andre prototypen, en webapplikasjon. Applikasjonen kjørte fra en webserver til en av gruppemedlemmene og ble da implementert inn i Facebook i en så kalt iframe. Med en iframe-løsning kjører applikasjonen i et eget vindu integrert inne i Facebook. Denne prototypen ble også presentert under en forelesning til oppdragsgiver hvor to andre fra samme avdeling, journalistikk, bibliotekog informasjonsfag deltok. Tilbakemeldingene var positive og vi følte at dette var mer i trå med det oppdragsgiver hadde sett for seg. Det var lite funksjonalitet på dette tidspunktet grunnet mangel på en Noark kjerne vi kunne jobbe mot. Dessverre oppstod det en del komplikasjoner når vi skulle begynne å programmere funksjonaliteten i applikasjonen. Det oppstod problemer som det å bevare tilstanden til en avhukingsboks og flytte informasjon fra en side til en annen. iframe er nok mer egnet hvis man kun skal presentere én side, og ikke navigere mellom flere. Figur 6.2: Filtrering i FIR Vi var derfor nødt til å gå bort i fra den integrerte iframe-løsningen og bevege oss over på en dedikert applikasjon som lå utenfor, men som likevel kunne oppleves som en del av Facebook. Applikasjonen kunne fortsatt kjøre fra den samme webserveren og koden fra de tidligere prototypene ble overført. Etterhvert som vi utviklet nye prototyper og tiden gikk, gjorde Facebook endringer i programmeringsgrensesnittet og vi måtte oppdatere vår kunnskap fortløpende for å ta det i bruk. Applikasjonen har til dette tidspunktet ikke hatt mange funksjoner fordi vi ville være sikre på at vi hadde en god plattform å bygge på. Vi implementerte mulighet for å hente meldinger fra arrangementer og sider i tillegg til grupper som allerede var fra før. For å gi et bedre bilde av hva en slik applikasjon kan brukes til, ble det også utviklet en egen filtreringsfunksjon. Den fikk en søkefelt for å finne igjen innhold i meldinger, datosortering for å finne tilbake til meldinger fra en bestemt dato eller periode og sortering på type melding (status, bilde og kobling). Oppdragsgiver Sødring, hadde nå klargjort en versjon av Noark-kjernen som vi kunne ta i bruk og teste mot. En JBoss-server ble satt opp på en av gruppemedlemmenes bærbare datamaskin med Sødrings Noark 5 kjørende. Vi importerte kontrakten (WSDL) fra Noark inn i facebookapplikasjonen og kunne umiddelbart ved bruk av SOAP-meldinger kommunisere med Noark. Side 28 av 135

36 Kapittel 6: Utviklingsprosessen Noark 5 Dokumentfangst Figur 6.3: Endelig versjon av FIR Selv om versjonen av Noark vi fikk av Sødring var uferdig og manglet en del fra å være komplett, var det vi hadde oppnådd et bevis på at det var mulig å hente meldinger fra Facebook og arkivere det i et arkiv. Det er viktig å være klar over at arkivet ikke var tilpasset facebookmeldinger på noe som helst måte fordi Sødring hadde mer fokus på å få en fungerende versjon som vi kunne ta i bruk. Som en følge av at Noark-kjernen var så lite tilpasset, ble veldig lite metadata til meldingene tatt vare på. Selve innholdet i meldingen og hvem som hadde opprettet den ble lagt i arkivet Utvikling i henhold til kravspesifikasjon Med facebookapplikasjonen hadde vi som mål å hente meldinger fra Facebook og arkivere dem i et arkiv. Vi fant det nødvendig å få utarbeidet krav til funksjonaliteten rundt dette målet. Vi var også nødt til å ta hensyn til personvern og utforming av utseende til applikasjonen. Da vi utviklet de første prototypene av applikasjonen ble det også mer klart hvilke krav som var reelle og kunne bli gjennomført innen for tidsrammene vi hadde. 6.2 Marc (Android applikasjon) Utvikling i Android har vært en spennende og lærerik reise. Hadde absolutt ingen erfaring med å programmere mobilapplikasjoner før prosjektet. Det er vel kanskje litt Side 29 av 135

37 Prosessdokumentasjon Kapittel 6: Utviklingsprosessen derfor at mobilapplikasjonen er den delen av produktet vårt som har gjennomgått de største endringene siden vi satte i gang dette prosjektet. Kravspesifikasjonen var ganske åpen på denne applikasjonen, og eneste kravet fra oppdragsgiver var at meldingene skulle kunne hentes ut av telefonen og håndteres av Noark Selvlæring i Android Som beskrevet tidligere er Android et javabasert mobiloperativsystem. Gikk derfor i gang med oppfriskning av våre javakunnskaper før vi satte i gang å lese oss opp på Android. Hjemmesiden til Android (developer.android.com) har gitt oss mye god informasjon, og er veldig fint bygget opp for folk som ønsker å lære å programmere i Android. Denne siden har blitt flittig brukt gjennom hele utviklingsprosessen. Alt fra oppsett av programmeringsverktøy til tutorials på forskjellige programmer, til informasjon om klassene og deres metoder finnes her Fra daemon til full brukerinteraksjon Oppdragsgiver var veldig åpen når det kom til mobilapplikasjonen. Vi hadde derfor noen brainstormingsøkter med både oppdragsgiver og alle gruppemedlemmene, der vi drøftet forskjellige løsninger. Det første vi kom fram til var en daemon. En deamon er en prosess som går i bakgrunnen på et operativsystem, uten noen form for brukerinteraksjon. Denne ville starte opp på telefonen ved oppstart, for så å ligge i bakgrunn og vente på at bruker sender eller mottar meldinger. Den ville så sende meldingen som er sendt eller mottatt til brukerens epostkonto, eller til en applikasjon vi lager selv. Vi var usikre på hvor mye tid vi ville legge i applikasjonen, og nedprioriterte den endel de første ukene. Etter noen uker, mer opplæring i Android, og enda et møte med veileder, tok vi igjen opp kravspesifikasjonen til mobilapplikasjonen. Vi lå såpass godt an med FIR at vi bestemte oss for å utvikle en skrivebordsapplikasjon sammen med mobilapplikasjonen. Gikk dermed bort fra ideen om å sende meldingene til mobileierens epostkonto. Mobilapplikasjonen skulle fortsatt være en daemon. Nå kom derimot utfordringene. Det er ikke mulig å lagre utgående meldinger i Android med en lytter. Se for problemene som oppstod med lagring og uthenting av meldinger. Igjen satt vi oss ned og leste gjennom nettsider og Android sin utviklerside. Løsningen vi fant var content providers. Vil du lese mer teknisk om dette må du se i produktdokumentasjonen. Kort fortalt så er en content provider en måte for Android å hente og lagre data på. Du har content provider for SMS, kontakter og epost. Nå hadde vi kommet til et punkt i programmeringen hvor vi måtte finne ut hva som ville være mest hensiktsmessig, fortsette med daemon eller gi brukeren mulighet til å interagere. Med content provider hadde vi nå tilgang direkte på innboksen, og kunne hente SMS som vi ville. Om vi nå skulle fortsatt med daemon ville en lokal versjon av innboksen oppdateres for hver melding du mottar. Vi så for oss at dette ville bli en svært tidkrevende prosess og kun ville irritere brukeren. Samtidig vil applikasjonen kun oppdatere meldingene når brukeren mottar meldinger, men ikke når de blir sendt. Side 30 av 135

38 Kapittel 6: Utviklingsprosessen Noark 5 Dokumentfangst Med brukerinteraksjon ville brukeren selv kunne velge hvilke kontakter han/hun vil lagre meldinger fra, og når de skal lagres. På denne måten vil vi unngå mye uønsket venting. Vi vil heller ikke trenge en lytter på mottatte SMS. Løsningen blir å gi brukeren mulighet til å interagere med programmet. Igjen setter vi oss ned og besøker utviklersiden til Android. Vi oppretter også noen klasser for å få mer struktur i programmet. Klassene som er opprettet og deres hensikt kan leses om i produktdokumentasjonen. Mobilapplikasjonen begynner å ta form; det dukker ikke opp noen store problemer ved utvikling av GUI. Etter tungvint eksportering av applikasjon til mobil, der blant annet et digitalt sertifikat må signeres har vi endelig noe som fungerer på telefonen. Programmet kjører utrolig tregt på telefonen, så vi optimaliserer koden og legger til en splash screen (velkomstskjerm) som brukeren kan se på mens programmet laster. Tegner et ikon til applikasjonen og sier oss klare til å begynne med testing. Hvordan testingen foregikk, kan du lese om i kapittel 7 avsnitt Utvikling i henhold til kravspesifikasjon Som nevnt over hadde vi ikke store kravspesifikasjonen til mobilapplikasjonen. Vi har endret både kravspesifikasjonen og programmet etterhvert som vi har fått bedre kunnskap om Android og mobilprogrammering generelt. Endringer som har blitt gjort i programmet har blitt gått over med oppdragsgiver, som har kommet med ønsker, som vi igjen har lagt til i kravspesifikasjonen og implementert i programmet Utfordring med meldinger Første problemene vi støtet på var at det ikke var noen lytter ved utgående SMS. Derfor ville daemonen vår ikke fungere optimalt, fordi den kun vil ha mulighet til å lagre innkommende meldinger. Siden vi ikke hadde mulighet til å lagre utgående meldinger, måtte vi se oss om etter andre løsningsalternativer. Løsningen var content providers som nevnes ovenfor. Her lagres meldingene ikke når de blir mottatt, men hentes ut fra mobilen sin innboks og lagres på minnekortet. Denne prosessen viste seg å være spesielt tungvint ved bruk av daemon så vi gikk over til å ha brukerinteraksjon. Andre problemer vi støtte på var blant annet det å kunne knytte melding til kontakt. Løste dette ved å hente content provideren til kontaktene og lage en kontaktliste. Knyttet så denne opp mot en liste av meldinger hentet ut av content provideren til innboks. Se produktdokumentasjonen for teknisk beskrivelse Eksportering til XML Ble tidlig klart at formatet vi skulle bruke på meldingene vi sendte ut skulle være i XML. XML står for Extensible Markup Language og brukes til å lagre og transportere data. Formatet på XML filen er samme som brukes på iphone, så i teorien skal Side 31 av 135

39 Prosessdokumentasjon Kapittel 6: Utviklingsprosessen skrivebordsapplikasjonen også kunne lese XML-filer som er hentet ut fra en iphone. Vi støtte også på noen småproblemer med XML-formateringen, fordi spesialtegn som < og > vil ødelegge for programmene. Løsningen ble da å endre disse tegnene der de forekommer i meldingene så koden ville kjøre normalt. 6.3 Marc (skrivebordsapplikasjon) Som nevnt i forrige delkapittel, bestemte vi oss for å utvikle en skrivebordsapplikasjon i tillegg til mobilapplikasjonen. Vi gjorde dette da det vil gi brukeren bedre kontroll over hva som skal arkiveres. Det ville i lengden vært et irritasjonsmoment for brukeren å kun bruke en mobilapplikasjon til formålet programmet er beregnet for. Skrivebordsapplikasjonen var tenkt å være et meget enkelt program som kun har som formål å gi brukeren en oversikt over meldinger, organisert etter kontakt, og gi ham/henne muligheten til å velge enkeltmeldinger for så å sende dette inn til Noark. Vi la også til et enkelt søkesystem, som kan benyttes for å søke etter avsender og innhold i meldinger. 6.4 Oppsett av Noark I begynnelsen av prosjektet hadde vi ingen Noark-kjerne til disposisjon fordi oppdragsgiver ikke hadde den klar. Vi fikk opplyst at det fantes en åpen utgave av Noark kalt Friark. Fra Friark sin nettside( kan vi lese: Friark utvikles av Machina AS og har som mål å bli en implementasjon av en Noark-5 indre kjerne. Løsningen er åpen kildekode, og tilgjengelig som fri og åpen programvare (GPL lisens). På det tidspunktet vi lastet ned kildekoden til Friark fantes det lite dokumentasjon om hvordan vi skulle ta det i bruk. En virtuell maskin (VM) med Ubuntu ble installert på en av gruppens datamaskiner, og etter utallige forsøk klarte vi til slutt å få det til å kjøre, men måtte legge det fra oss da vi oppdaget at vi ikke hadde en mulighet til å kommunisere med Friark fra applikasjonene våre. Vi bestemte oss for å ta kontakt med oppdragsgiver for å høre om det var mulig å ta i bruk Noark-kjernen hans. Det løste seg ved at vi fikk en gjennomgang av koden og de forskjellige lagene i Noark, hvor det endte med at en av datamaskinene til gruppen ble overrukket til oppdragsgiver slik at han kunne installere det for oss. I løpet av en ettermiddag hadde vi en fungerende Noark-kjerne kjørende og testing av applikasjonene mot kjernen ble en realitet. Side 32 av 135

40 Kapittel 7: Testing Noark 5 Dokumentfangst 7 Testing Dette kapittelet tar for seg testing, og gjør rede for hvorfor vi har prioritert andre ting foran testing. 7.1 Brukertesting FIR Testing av FIR har blitt nedprioritert. I fremdriftsplanen ble det ikke satt mye tid testing fordi vi valgte å fokusere på å få til et fungerende produkt, for så å gå over til å skrive dokumentasjon. Det ble gjort litt brukertesting av applikasjonen for Riksarkivet. Mer om brukertesting kan leses i avsnitt Brukertest Vi har hatt minimalt med bruktertesting pga. følgende faktorer: Testing ble nedprioritert i fremdriftsplanen Å få tak i testsubjekter har vist seg problematisk av følgende grunner: o Mangel på en Noark-kjerne som var tilgjengelig for flere datamaskiner enn bare maskinene vi utviklet på. o Programvaren har ikke blitt lagt ut på Facebook og gjort tilgjengelig for andre. Vanskelig å ta i bruk for testsubjekter. Likevel har vi fått til noen brukertester. Du kan lese om disse i produktdokumentasjonen Marc Testingen av mobilapplikasjonen er noe som har blitt nedprioritert. Vi satt ikke opp mye tid til testing i fremdriftsplanen, vi valgte heller å fokusere på å få til et fungerende produkt, for så å gå over til å skrive dokumentasjon. Vi har fått tatt litt brukertesting av applikasjonen som kan leses om i avsnitt Vi har hatt minimalt med bruktertesting pga. følgende faktorer: Testing ble nedprioritert i fremdriftsplanen Få tak i testsubjekter har vist seg problematisk av følgende grunner: o Brukeren må ha en Android telefon nyere en 2.1. Programvaren har ikke blitt lagt ut på Android Market, så vanskelig å laste ned i forhold til andre androidapplikasjoner. Noen brukertester har vi derimot fått til. Dette kan du lese om i produktdokumentasjonen. Side 33 av 135

41 Prosessdokumentasjon Kapittel 7: Testing 7.2 Foredrag for målgruppen Oppdragsgiver inviterte oss til en av hans forelesninger om Noark der han ønsket at vi skulle presentere vårt prosjekt og ha en demo av applikasjonene vi hadde utviklet. Publikum bestod av personer fra Riksarkivet som var til stede for å lære om Noark 5, så vi følte derfor at det ville være verdifullt for oss med denne presentasjonen siden de er i målgruppen. Etter en demo av både FIR og Marc hadde vi en spørsmålsrunde hvor både oppdragsgiver og de fra Riksarkivet kom med spørsmål. Og til slutt ble det litt tid til utprøving av applikasjonene. Det hele ble en lærerik presentasjon. Vi fikk spørsmål om ting vi ikke hadde tenkt på tidligere og så ting fra et annet ståsted. Side 34 av 135

42 Kapittel 8: Kravspesifikasjonen og dens rolle Noark 5 Dokumentfangst 8 Kravspesifikasjonen og dens rolle Hvordan kravspesifikasjonen har forandret seg gjennom prosjektet og hvordan endringer i kravspesifikasjonen har påvirket produktet er hva dette kapittelet handler om. 8.1 Kravspesifikasjon 1.0 I og med at prosjektet utspeilet seg som proof of concept og oppdragsgiver ikke hadde noen formening om hvordan det skulle løses teknologisk ble det vanskelig å lage en kravspesifikasjon fra starten av. Den første kravspesifikasjonen dekker de kravene vi mente var nødvendig for at applikasjonene skulle besvare spørsmålet om det var mulig å arkivere meldinger fra mobil og Facebook. 8.2 Endringer etter oppdragsgivers ønsker Etter utviklingen av første prototype til FIR fikk vi tilbakemelding fra oppdragsgiver om at det var et sterkere ønske om en webapplikasjon enn skrivebordsapplikasjon som det på tidspunktet var. Endringer i kravspesifikasjonen måtte gjøres siden skrivebordsapplikasjoner og webapplikasjoner har noen fundamentale forskjeller. Det var noen likheter ved applikasjonene, men nye krav måtte skrives som følge av de endringene og overgangen til en webapplikasjon. Grunnen til at oppdragsgiver ønsket en webapplikasjon var at applikasjonen skulle være en facebookapplikasjon som man kan legge til fra Facebooks applikasjonsbibliotek. Den nye webapplikasjonen ble derfor opprettet som en facebookapplikasjon med en applikasjons-id fra Facebook. Tilbakemeldinger fra oppdragsgiver har også påvirket Marc. I første utkast til kravspesifikasjonen skulle Marc kun være mobilapplikasjon med relativt lite funksjoner. Etter videre samtaler med oppdragsgiver endret vi Marc til også å inneholde en skrivebordsapplikasjon for håndtering av SMS. 8.3 Innfrielse av kravene Kravene i kravspesifikasjonen ble drøftet lenge i gruppen, vi ville være sikre på at de kravene vi satt utenfor oppdragsgivers ønsker skulle bli møtt. Det ene kravet fra arbeidsgiver i kravspesifikasjonen, innhenting og formatering av informasjon fra Facebook, ble møtt tidlig i utviklingen av applikasjonene. Vi gikk derfor tilbake til kravspesifikasjonen og la inn flere krav til utviklingen av FIR, muligheten til å lagre både vegger og sider, ikke bare grupper. Kravene til de andre applikasjonene ble senere møtt, men med tidsfristen vi hadde kunne vi ikke implementere andre ønskede funksjoner uten at implementeringen av disse funksjonene ville komme i veien for andre prioriteringer. Side 35 av 135

43 Prosessdokumentasjon Kapittel 9: Avslutningsfase 9 Avslutningsfase Dette kapittelet tar for seg avslutningsfasen av prosjektet, med rapportskriving og veiledningstimer. 9.1 Ferdigstilling av prosjektet Da det var 1 måned av prosjektet igjen før det hele skulle leveres ble det satt fokus på å skrive prosjektrapporten. Vi var rådet av veileder Vihovde til å sette av så mye tid fordi rapportskriving er en tidkrevende prosess. Vi var ferdig med utviklingen av applikasjonene i henhold til planen i slutten av april. Gruppen opprettet et dokument som bestemte strukturen i rapporten med inndeling av kapitler og avsnitt til delene i rapporten. Det ble lettere å forholde seg til hva som skulle skrives når alt var forhåndsbestemt. Dokumentet med strukturen ble lastet opp på Google Docs slik at alle kunne delta samtidig i skrivingen. Veiledningstimene ble holdt hyppigere i denne fasen enn tidligere og utkast av rapporten ble levert til veileder for vurdering. Vi satte stor pris på at en fagperson kunne gi sin tilbakemelding slik at vi kunne gjøre rapporten interessant og lærerik. Side 36 av 135

44 Kapittel 10: Konklusjon Noark 5 Dokumentfangst 10 Konklusjon Hvordan kan informasjon fra SMS og Facebook (sosiale medier) journalføres og arkiveres i et standardformat? Følgende problemstilling har vi utarbeidet, og jobbet med for å løse. Prosjektoppgaven har vist seg som en spennende og lærerik utfordring. Etter et halvt år med dette prosjektet, har vi gått fra en problemstilling til å kunne bevise at konseptet var mulig. Vi har utarbeidet en løsning bestående av applikasjoner som lar personer og bedrifter dokumentere sin egen og andres kommunikasjon i sosiale medier og SMS. Det bekrefter at det ikke handler om hvilket format innholdet er i. Så lenge innholdet er journalføringspliktig, er det kun en teknologisk utfordring. For oppdragsgiver dekker produktet alle kravene som ble satt i starten av prosjektet. Produktet har også en verdi for oppdragsgiver, i den form at produktet har vist at dokumentfangst av sosiale medier ikke er en teknisk umulighet, og har allerede rukket å påvirke debatten rundt journalføring av sosiale medier. Produktet dekker et voksende behov, siden sosiale medier blir oftere og oftere brukt til å formidle informasjon. Produktet har nærmest uendelige bruksmuligheter innenfor dokumentfangst. Vi kan se det for oss i bruk i mindre bedrifter som bruker Facebook eller SMS for å kommunisere i sin daglige virksomhet. Vi kan se det for oss i bruk av politikere og andre offentlige personer som på en enklere måte kan dokumentere sin egen og andres kommunikasjon i det offentlige rom. Ved videre utvikling av produktet kan også privatpersoner dokumentere all ønskelig kommunikasjon. Det gir de mulighet til å ha full oversikt over egne avtaler, samtaler o.l. Se for deg produktet bli utvidet til å gjelde Twitter, eller andre sosiale medier. Programmet kan hjelpe til å samle alt av informasjon du deler med verden på alle ønskelige måter, samler de i et format som er standardisert, og gir deg full oversikt over alle dine utsagn og samtaler. Vi har brukt mye tid på forskning, utvikling og å tilegne oss kunnskap om nye teknologier som TOA, Android, Noark og Facebook, noe vi pent har sett oss nødt til siden vi transporterer informasjon mellom mange forskjellige programmeringsspråk og plattformer. Underveis har vi møtt på mange utfordringer, både programmeringsmessig og teknisk. Under utviklingen av mobilapplikasjonen dukket det opp flere utfordringer, som skyldes at den gikk fra ingen brukerinteraksjon til full brukerinteraksjon. Av tekniske utfordringer har oppsett av en Noark-kjerne på egen hånd vært en utfordring, men som løste seg til slutt. Vi ønsker å takke veileder for å ha støttet oss med veiledningstimer og kommet med tilbakemeldinger. Vil også takke oppdragsgiver for informasjon om Noark og muligheten til å fremføre produktet foran Riksarkivet, som gjorde det mulig å få nyttige Side 37 av 135

45 Prosessdokumentasjon Kapittel 10: Konklusjon tilbakemeldinger og som lot oss forbedre produktet. Det er blant annet takket være disse at vi har klart å levere et produkt vi er veldig godt fornøyd med. Vi er sikre på at vi har levert et produkt som oppfyller oppdragsgivers krav og kan påstå at applikasjonene er et godt bevis på at det er mulig å hente informasjon fra SMS og Facebook, for så å journalføre og arkivere det i et standardformat(noark). Side 38 av 135

46 Kapittel 11: Kilder Noark 5 Dokumentfangst 11 Kilder Høgskolen i Oslos hovedprosjekt side Riksarkivet og statsarkivene Noark 5 Norsk Arkivråd SMS må arkiveres (artikkel) Fredrikstad Blad Må journalføre Facebook-melding (artikkel) Regjeringen Høyring om endringar i arkivforskrifta Riksarkivarens råd om journalføring av sosiale medier Journalføring og arkivering av meldinger på sosiale medier Side 39 av 135

47 Prosessdokumentasjon Kapittel 12: Vedlegg 12 Vedlegg 12.1 Arbeidsplan Beskrivelse Ferdig Statusrapport:Hvem vil vi jobbe med, type prosjekt, plassering for prosjekt Prosjektskisse: Tittel, medlemmer, oppdragsgiver, kontaktperson, beskrivelse Opprette hjemmeside for prosjektdagbok, styringsdokumenter, annen info Desember Forprosjekt: Forprosjektrapport, arbeidsplan, fremdriftsplan Velge programmeringsmetode, språk, ramme Jobbe med kravspesifikasjonen, sette ramme rundt prosjektet Forberede til presentasjon av forprosjekt-rapport Presentasjon av forprosjekt-rapport Snakke med arbeidsgiver, gå igjennom kravspesifikasjonen. Revurdere Nytt utkast av kravspesifikasjon Sett opp server med Microsoft Windows server 2008 og ISS Installere Microsoft Team Foundation og Microsoft SQL Server Kravspesifikasjon Kunne hente ut informasjon fra facebook og formatere til xml Kunne hente informasjon fra sms og formatere det til xml Formatere xml til NOARK format Utvikle gui for skrivebordsapplikasjonen Utvikle gui for mobilapplikasjonen Intern testing av applikasjoner Ekstern testing av applikasjoner Finpussing av kode, kommentarer mm Ny runde av ekstern testing? Evt ny runde av finpussing Forberede til presentasjon av prosjektet. Uke 22 Presentasjon av prosjekt. Uke 23 Sluttføring av kode for de forskjellige applikasjonene Sluttdokumentasjon Forberede hovedprosjektpresentasjon Hovedprosjektpresentasjon Side 40 av 135

48 Kapittel 12: Vedlegg Noark 5 Dokumentfangst 12.2 Fremdriftsplan Oppgaver Desember Januar Februar Mars April Mai Juni Uke: < Forprosjekt Statusrapport Prosjektskisse Prosjektside Forprosjektrapport Presentasjoner Forprosjektpresentasjon Prosjektpresentasjon Hovedprosjekt-presentasjon Startfase Arbeidsplan (opprette) Fremdriftsplan/Milepælsplan (opprette) Grov Kravspesifikasjon Risikoanalyse (opprette) Gjennomføringsfase Detaljert kravspesifikasjon Skisser, GUI-eksempler Koding Koding Marc (mobilapplikasjon) Koding FIR Koding Marc (desktopapplikasjon) Fullføringsfase Prosessrapport Produktrapport Brukerdokumentering Testing Enhetstesting Bruker-test Løpende oppgaver Føre prosjektdagbok Oppdatere Arbeidsplan Oppdatere Fremdriftsplan/Milepælsplan Oppdatere Risikoanalyse Oppdatere Kravspesifikasjon Fikse evnt bugs i produktet Side 41 av 135

49 Prosessdokumentasjon Kapittel 12: Vedlegg 12.3 Risikoanalyse Mulige Trusler Risiko Sannsynlighet Konsekvens Sykdom (langvarig) Høy Middel Obligatoriske oppgaver i andre fag Høy Lav Forsovelser Høy Lav Dårlig motivasjon Middels Middel Interne konflikter Middels Middel Sykdom (kortvarig) Middels Lav Menneskelige feil Middels Lav Dårlig planlegging Lav Middel Mangler kompetanse Lav Middel For liten tid Lav Middel Tap av data Lav Høy Terrorisme Lav Høy Tyveri Lav høy Naturlige katastrofer Lav Høy Utstyrs eller programmeringsfeil Medium Medium XXS (Cross server scripting) Lav Medium SQL - Injection Lav Høy DOS Angrep Lav Middel Svindel Lav Middel Dødsfall (familie) Lav Høy Forhindrende arbeid (unngå risikoer) Risiko Sykdom (langvarig) Obligatoriske oppgaver i andre fag Forsovelser Dårlig motivasjon Interne konflikter Sykdom (kortvarig) Menneskelige feil Dårlig planlegging Mangler kompetanse For liten tid Tap av data Dødsfall (familie) Terrorisme Tyveri Naturlige katastrofer Utstyrs eller programmeringsfeil XXS (Cross server scripting) SQL - Injection DOS Angrep Svindel Strategi Spise sunt, ta vitaminer Ta hensyn til disse i estimeringen av tid Legge seg tidlig Jobbe med måte, ha det morro Klare arbeidslinjer Ta vitaminer Dobbelsjekking Prioritere tidlig planlegging Lære seg opp om mulige temaer i prosjektet tidlig Sette milepæler Ha backup Forberede på mulige dødsfall Ha backup på annen lokasjon, forsikring. Ha backup, forsikring Ha backup på annen lokasjon, forsikring. Sjekke utstyr regelmessig, dobbelsjekking. Sette oss inn i SDK/API. Ha sikker kode, regelmessig oppdateringer. Ha sikker kode, regelmessig oppdateringer. Ha sikker kode, regelmessig oppdateringer. Ha backup, forsikring. Begrensende arbeid (når uhellet først er ute) Risiko Sykdom (langvarig) Obligatoriske oppgaver i andre fag Forsovelser Dårlig motivasjon Interne konflikter Sykdom (kortvarig) Menneskelige feil Dårlig planlegging Mangler kompetanse For liten tid Tap av data Dødsfall (familie) Terrorisme Tyveri Naturlige katastrofer Utstyrs eller programmeringsfeil XXS (Cross server scripting) SQL - Injection DOS Angrep Svindel Strategi Fordele arbeidsoppgavene / jobbe hjemme Ta igjen det tapte med ekstra arbeid Ringe og vekke Ta en pause for å motivere Stemmer over Jobbe hjemme (hvis mulig) Reparere feil, lære av dette Gå over planleggingen, revurdere fremdriftsplan. Lese, spørre faglærer Kutte ned på funksjoner. Skrive ned tapt data fortest mulig mens det er friskt i minne. Trøste Sjekke utstyr, reparere skader Anmelde, hente backup, inkassere forsikring Sjekke utstyr, reparere skader. Rette opp feil, reparere utstyr, gi beskjed til leverandør om feil Gjøre koden din mer sikker, rette opp feil som har oppstått, evt gå tilbake til en tidligere versjon. Gjøre koden din mer sikker, rette opp feil som har oppstått, evt gå tilbake til en tidligere versjon. Lukke porter, endringer i brannmur, restarte server. Anmelde, hente backup, inkassere forsikring. Side 42 av 135

50

51

52

53 Forord Produktdokumentasjon er om hvordan applikasjonene er bygget i motsetning til prosessdokumentasjonen som handler om hvorfor applikasjonen er bygget opp som den er. For mer bakgrunnsinformasjon om hvilke valg og utfordringer vi hadde under konstruksjonen av applikasjonene, kan du lese kapittel 5 om teknologier og kapittel 6 om utviklingsprosessen i prosessdokumentasjonen. Denne dokumentasjonen vil være interessant for deg som ønsker å vite mer om hvordan applikasjonene virker, og for deg som skal bygge videre på applikasjonen senere. Du kan lese om hvordan arkitekturen til applikasjonene og det bakomliggende er organisert, hvilke verktøy som kreves for å åpne og endre på dem, og teknologiene vi har brukt med lenker til videre fordypning. For deg som leser denne dokumentasjonen vil det være en fordel, men ikke nødvendig, å ha kjennskap og erfaring med programmering, gjerne objektorienterte programmeringsspråk som Java eller C#. Det vil også være en fordel å kjenne til Android-plattformen og dens utviklingsmiljø. Det vil fremkomme eksempler på kode vi har skrevet til applikasjonene.

54

55 Innholdsfortegnelse 13 Innledning Om Noark Dagens situasjon Vårt prosjekt Gruppen Oppdragsgiver Det endelige produktet Facebookapplikasjon (FIR) Mobil- og skrivebordsapplikasjon FIR Krav til utvikler Beskrivelse av programmet Brukergrensesnitt og design Applikasjonsarkitektur Modellaget DAL-laget BLL-laget GUI-laget Teknisk arkitektur Klienter/Nettlesere IIS Applikasjon NET Framework Windows Server Utviklingsmiljø Dataarkitektur Kommunikasjon med Facebook Testing Videreutvikling Installasjon Facebook applikasjon Publisere applikasjonen på en server Marc (mobilapplikasjon) Krav til utvikler Side 48 av 135

56 16.2 Beskrivelse av produktet Brukergrensesnitt og design Applikasjonsarkitektur Android prosjekt SRC GEN Android versjonsnummer Assets RES AndroidManifest.xml Tekniske utfordringer Teknisk arkitektur Applikasjonslaget Rammeverklaget Biblioteker Android Runtime Linux Kernel Dataarkitektur XML-struktur Testing Videreutvikling Installasjon Marc (skrivebordsapplikasjon) Krav til utvikler Beskrivelse av produktet Brukergrensesnitt og design Applikasjonsarkitektur Modellaget (Model) Viewlaget (Marc) Data Access Layer (DAL) Business Logic Layer (BLL) Teknisk arkitektur Utviklingsmiljø Dataarkitektur Testing Videreutvikling Installasjon Side 49 av 135

57 18 Kilder Vedlegg Side 50 av 135

58 Side 51 av 135

59 Produktdokumentasjon Kapittel 13: Innledning 13 Innledning Dette kapittelet er identisk med kapittel 1 i prosessdokumentasjonen, og det er derfor ikke nødvendig å lese det dersom du har lest den. Denne delen består av prosessdokumentasjon. Først vil du få en innføring i prosjektet, gruppen og oppdragsgiver Om Noark Norsk arkivstandard (Noark) er en standard for elektroniske journalsystemer som stiller krav til arkivstruktur, metadata og funksjonalitet. Noark 5 skal kunne brukes for alle typer arkivdanning, uavhengig av teknologisk løsning og type organ. Alle former for aktiviteter som skaper dokumenter som det er viktig å sørge for at oppbevares og gjenfinnes i autentisk form, skal i prinsippet inngå i en løsning for arkivdanning. Dette er helt uavhengig av offentlig eller privat sektor, om dokumentene inngår i tradisjonell saksbehandling, hvor mange år de skal oppbevares eller om de skal avleveres til depotarkiv. Noark 5 er den siste utgaven av Noark-standarden, og ble publisert sommeren Fra og med mars 2011 er Noark 5 versjon 3.0 gjeldende versjon. Figur 13.1: Noark 5 kjernen Side 52 av 135

60 Kapittel 13: Innledning Noark 5 Dokumentfangst 13.2 Dagens situasjon Mye av informasjon som finnes på nettet i dag er ikke i et format som passer til å lagre i et dokument. Se f.eks. Facebook grupper(master i Hardanger), informasjonen som kommer ut herifra kunne vært fint å fått dokumentert, men er vanskelig pga. formatet det er i. Kommunikasjon per SMS mellom politikere og andre som jobber i offentlig virksomhet, blir i dag ikke arkivert eller gjort tilgjengelig for ande. Et problem som ble tydelig da Jens Stoltenberg sendte en SMS til DnB Nor-sjefen i 2008, hvor det ble kritisert om at en politiker hadde hatt uoffisiell kontakt om politiske beslutninger. Ved hjelp av Noark og nødvendig programvare på mobiltelefonen skal det være mulig å arkivere denne type kommunikasjon Vårt prosjekt I forbindelse med oppdragsgivers arbeid med Noark 5, og et ønske om dokumentfangst fra utradisjonelle kilder, har vi utviklet 3 applikasjoner. En mobilapplikasjon som gjør tekstmeldinger tilgjengelig for en skrivebordsapplikasjon. Denne skrivebordsapplikasjonen tar seg av journalføring og arkivering til Noark-arkivet. Det er også utviklet en facebookapplikasjon som i likhet med skrivebordsapplikasjonen tar seg av journalføringen og arkivering, men da med meldinger fra Facebook Gruppen Prosjektgruppen består av tre it-studenter ved Høgskolen i Oslo: Joakim Vorren 22år, Lars-Erik Arnesen 24år og Daniel Brunstad Diakoff 21år. Alle tre kjenner hverandre godt fra tidligere prosjekter i forbindelse med bachelorgraden i informasjonsteknologi Oppdragsgiver Høgskolen i Oslo (HiO) ble opprettet 1. august 1994 og er landets største høgskole med studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelorstudier og over 20 masterstudier. Forskning og utvikling (FOU) ved Avdeling for journalistikk, bibliotek- og informasjonsfag (JBI) består pr av 3 professorer, 18 f. amanuenser, 1 forsker, 6 lektorer, 20 høgskolelektorer, 1 høgskolelærer og 7 dr. gradsstipendiater. Blant fagpersonalet er det 15 med dr. grad. Vår kontaktperson, Thomas Sødring er førsteamanuensis ved JBI og har i lengre tid jobbet med utvikling av Noark 5. Side 53 av 135

61 Produktdokumentasjon Kapittel 14: Det endelige produktet 14 Det endelige produktet Dette kapittelet er identisk med kapittel 2 i prosessdokumentasjonen, og det er derfor ikke nødvendig å lese det dersom du har lest den. Her følger en kort beskrivelse av produktet vi har laget. Mer informasjon om funksjonalitet og bruk vil komme i produktdokumentasjonen og brukerveiledningen Facebookapplikasjon (FIR) Facebookapplikasjonen, eller Facebook Information Retriever som vi har døpt den, har som funksjon å hente og lagre informasjon som brukeren definerer som journalføringspliktig. Figur 14.1: Facebookapplikasjon (FIR) Applikasjonen henter inn alle grupper, sider og arrangementer som brukeren administrerer. Brukeren kan så velge en gruppe, side eller arrangement han vil journalføre, velge hvilke meldinger han vil ha med, merke disse og få opp en forhåndsvisning. Er brukeren fornøyd, kan han/hun velge å sende inn og dokumentet vil bli gjort om til et format Noark kan håndtere, og lagres i arkivet. Side 54 av 135

62 Kapittel 14: Det endelige produktet Noark 5 Dokumentfangst Figur 14.2: Dataflyt til facebookapplikasjon (FIR) 14.2 Mobil- og skrivebordsapplikasjon Den andre løsningen består av to applikasjoner. Den ene er en mobilapplikasjon på Android som viser deg en liste over personer du har sendt meldinger med, enten med navn du har lagret i kontaktlisten din, eller med nummer om du ikke har de lagret. Du kan videre velge personer, og lagre meldinger fra disse på minnekortet til mobilen i en XML fil. Denne filen kan enkelt transporteres til PC og deretter videre inn til Noark. Figur 14.3: Dataflyt til Marc Når du nå kobler mobilen til PC-en skal vi ta i bruk den andre delen av løsningen. Dette er en skrivebordsapplikasjon som finner mobilen, og henter ut meldingene som vi nå har lagret på mobilens minnekort. Her kan du igjen velge personer, og hvilke meldinger fra valgt person du vil ha arkivert. Etter dette er det bare å velge send inn, og meldingene blir gjort om til et format Noark kan håndtere og arkiveres i arkivet. Side 55 av 135

63 Produktdokumentasjon Kapittel 14: Det endelige produktet Figur 14.4: Marc (mobilapplikasjon) Figur 14.5: Marc (skrivebordsapplikasjon) Side 56 av 135

64 Kapittel 15: FIR Noark 5 Dokumentfangst 15 FIR Dette kapittelet vil ta for seg oppbyggingen av Facebook Information Retriever, samt ting som er nødvendig for utviklere å vite når det kommer til videreutvikling Krav til utvikler Det er et åpenbart krav at eventuelle utviklere som skal jobbe med denne applikasjonen må ha kunnskap om og erfaring med ASP.NET og programmering i C#. Det vil også være behov for kunnskap om XML og oppbyggingen av en XML-fil, samt SOAPmeldinger og hvordan disse fungerer. Utviklere bør også ha kjennskap til Model-View- Controller arkitektur, da denne applikasjonen baserer seg på den. Det er forøvrig en fordel å ha erfaring med Facebook SDK og Facebook Graph, men ikke en nødvendighet da dette vil bli forklart lenger ut i dokumentet Beskrivelse av programmet Programmet er en nettbasert arkiveringsløsning for meldinger skrevet på vegger på Facebook. I den tilstand programmet er i dag, kan den hente ut meldinger fra grupper, arrangementer og sider (som for eksempel en bedrifts side på Facebook) Brukergrensesnitt og design Et ikke-funksjonelt krav vi satte til produktet er at det skulle se ut som og føles som Facebook. Dette vil gjøre at brukeren raskt vil skjønne hvordan alt er og hvordan ting fungerer. Designtiden av denne applikasjonen var derfor ikke særlig tidkrevende, da layout, fonter og grafikk allerede var bestemt. Når det kommer til elementer vi introduserer for brukere (som for eksempel filtreringsfunksjonen) har vi laget dette så likt som Facebook antakeligvis hadde laget det som mulig Applikasjonsarkitektur Applikasjonen er bygd opp i Visual Studio med en klassisk lagdeling. Arkitekturen til applikasjonen baserer seg på Model-View-Controller (MVC), en velkjent og mye brukt lagdelingsteknikk som går ut på at man med et modellag, et presentasjonslag og et kontrollerlag, kan separere forretningslogikken fra visningen og persisteringen av data. Det medfører en mer robust og fleksibel kode som er lettere å forholde seg til når det er flere utviklere på samme prosjekt. Se Figur 15.1 for en illustrasjon av applikasjonsarkitekturen til FIR. Side 57 av 135

65 Produktdokumentasjon Kapittel 15: FIR Figur 15.1: Applikajonsarkitektur til FIR FIR er i dagens tilstand ment til å kommunisere med en Noark-kjerne, men det settes ingen hindring for at en ny utvikler kan koble applikasjonen til en annen kjerne eller et annet system for arkivering. Det kan løses ved at en utvikler endrer litt på klassene i DAL-laget. Mappestruktur FIR er en Visual Studio 2010-løsning bestående av tre klassebiblioteker og en nettside. Se Figur Modellaget Modellaget finner vi i klassebiblioteket Model. Dette laget inneholder alle modellene som brukes i de andre lagene. Når DAL-laget skal hente informasjon fra Facebook blir det instansiert objekter av klassene i modellaget. Nesten hver klasse i dette laget med unntak av SearchIn er en representasjon av et objekt i Facebook. Likt for alle klassene i modellaget er at de har metoder for å hente og endre egenskapene. Her følger en beskrivelse av klassene i modellen: fbgroup En gruppe, arrangement og side i Facebook representerer vi med klassen fbgroup. Klassen inneholder ID, navn, en beskrivelse og en liste over meldinger. Den inneholder også metoder for å legge til meldinger og endre hele meldingslisten i tillegg til den vanlige konstruktøren. Side 58 av 135

66 Kapittel 15: FIR Noark 5 Dokumentfangst ifbmessage En Facebook-feed består av forskjellige type meldinger. Derfor har vi opprettet et grensesnitt som heter ifbmessage for å representere de egenskapene og metodene som er felles for alle meldinger. fbmessage fbmessage er en abstrakt klasse som tar i bruk grensesnittet ifbmessage. Klassen definerer de egenskapene og metodene som alle meldinger er nødt til å ta i bruk. Egenskapene i denne klassen er id, type melding, melding, beskrivelse, fra hvem meldingen er fra, dato for når den ble opprettet og liste av kommentarer til meldingen. Metodene i klassen er for å legge til kommentar i kommentarlisten, for endre kommentarlisten. fbmessagelink fbmessagelink representerer en melding av typen link. Den implementerer den abstrakte klassen fbmessage og dens egenskaper og metoder, men har også egne egenskaper som bilde, link, navn, bildetekst og ikon. fbmessagephoto fbmessagephoto representerer en melding av typen photo, altså en bildemelding. Den implementerer den abstrakte klassen fbmessage og dens egenskaper og metoder, men definerer også egne egenskaper som bilde, link, ikon og objekt id. Figur 15.2: fbmessagestatus Mappestruktur i FIR fbmessagestatus representerer en melding av typen status. Det vil si at denne meldingen kun inneholder tekst og har derav ingen egenskaper som ikke finnes i den abstrakte fbmessage. fbcomment fbcomment representerer en kommentar til en melding. Den inneholder egenskapene id, melding, fra hvilken bruker og dato for når den ble opprettet. Den inneholder kun en konstruktør og metoder for å endre egenskapene. fbuser fbuser brukes for å lage et brukerobjekt som representerer den personen som har skrevet en melding eller kommentar. Det vil si ved instansiering av objekter av klassene fbmessage og fbcomment blir det også instansiert et fbuser objekt. Egenskapene til denne klassen er id og navn. Den inneholder kun en konstruktør og metoder for å endre id og navn. fbuserme fbuserme er en klasse som brukes når en bruker logger seg inn i applikasjonen. Da instansierer applikasjonen et objekt av fbuserme-klassen. Egenskapene vi finner i Side 59 av 135

67 Produktdokumentasjon Kapittel 15: FIR denne klassen er en liste av grupper, arrangementer, sider og en link til brukerens område på Facebook. Hver liste i fbuserme er liste av klassen fbgroup. Metodene i klassen er for å legge til og endre hele listen. SearchIn Denne klassen er en enum -klasse og fungerer som en hjelpeklasse for filtreringsfunksjonaliteten i applikasjonen. Når en bruker velger å filtrere, vil klassen bli brukt til å si om det ble filtrert i meldinger, kommentarer eller begge DAL-laget DAL er en forkortelse for Data Access Layer eller datahåndteringslag på norsk. Dette laget har en viktig funksjon for enhver applikasjon som skal lagre eller hente data. I FIR er dette laget ansvarlig for kommunikasjon med Facebook og Noark. Det vil si at all data som kommer fra Facebook og som skal arkiveres i Noark må gjennom det samme laget. For å kommunisere med Noark er det implementert en service reference (tjenestereferanse) til Noark. Denne referansen kan sammenlignes med en vanlig referanse til et klassebibliotek, hvor man får tilgang til metodene, men i stedet får tilgang til metodene på tjenesten. En pakkereferanse til Facebook C# SDK gjør det mulig å hente data fra Facebook. Det kan leses mer om Facebook C# SDK i prosessdokumentasjonen, kapittel DAL-laget er bygget opp med tre klasser, fbgrouprep og fbusermerep og fbcommentrep. Klassen fbgrouprep inneholder en metode som innhenter data fra Facebook ved hjelp av Facebook C# SDK og instansierer objekter ut av det. Metoden heter getgroup, men brukes til å hente meldinger fra arrangementer og sider i tillegg til grupper. Første utsnitt av denne metoden kan sees i Figur I første linje i utsnittet ser vi at det blir opprettet en ny klient til Facebook. Denne klienten er en del av Facebook C# SDK som lar oss kommunisere med Facebook. Klienten tar en Access Token som paramater. Hvordan denne Access Token blir til og hvordan vi kan få tak i den, kan det leses i avsnittet om autentisering i kapittel I linje to ser vi et eksempel på bruk at den nye datatypen i C# 4.0 kalt dynamic. Dynamic representerer et objekt hvor metodene og egenskapene blir løst ved kjøring. Det vil si at kompilatoren ikke vet noe om operasjonene som kan gjøres på objektet. Fordelene med å bruke denne datatypen er at den er veldig fleksibel. Hvis Facebook endrer på objektstrukturen sin, krever ikke det at vi må laste ned en ny SDK, men at vi endrer på hvilke egenskaper og metoder vi forventer at de dynamiske dataypene skal ha. På høyre side av likhetstegnet brukes klientens get-metode med id som parameter for å hente objektet om gruppen, arrangement eller siden man vil hente. På linje tre er det beskrivelsen (description) til objektet som skal legges i en streng. Men siden noen objekter ikke har en beskrivelse krever det at vi sjekker om den er null. Hvis den er null, settes den til en tom streng. Side 60 av 135

68 Kapittel 15: FIR Noark 5 Dokumentfangst Linje seks oppretter et nytt objekt av typen fbgroup med egenskapene til objektet fra Facebook som parameter. Mer om fbgroup kan leses i forrige kapittel: (Modellaget). var fb = new FacebookClient(AccessToken); dynamic group_get = fb.get(group_id); String description = group_get.description; if (description == null) description = ""; fbgroup group = new fbgroup(group_get.id, group_get.name, description); Figur 15.3: Utsnitt av metoden getgroup i klassen fbgrouprep på DAL-laget Klassen fbgrouprep har en metode som tar i mot objekter og sender dem til Noark med SOAP-meldinger BLL-laget BLL er en forkortelse for Business Logic Layer eller virksomhetslogikklag på norsk. Dette laget spiller en viktig rolle for applikasjonen og filtreringsfunksjonaliteten. GUIlaget eller nettsiden, forholder seg kun til BLL-laget og de metodene den tilbyr. Når brukeren vil filtrere innholdet i meldingene og kommentarene vil det kalles på en metode som heter SearchInPost i klassen fbgroupcontrol i BLL-laget. Metoden er programmert slik at den tar i mot tre parametre: liste av meldinger, liste av søkeord og et objekt av typen enum som sier om den skal filtrere meldinger, kommentarer eller begge. Den går så gjennom hver melding og hver kommentar, leser innholdet, og sender det til en annen metode som heter StringExistsInString. Den metoden vil finne ut om innholdet faktisk inneholder en gitt streng. Metoden returnerer en boolsk verdi på om det ble funnet eller ikke. Når SearchInPost har gått gjennom det hele, returnerer den til slutt en liste av meldinger som inneholdt det man søkte etter GUI-laget GUI er en forkortelse for Graphical User Interface eller presentasjonslag på norsk. Dette laget brukes for å kommunisere med brukeren. Når brukeren interagerer med applikasjonen er det GUI-laget som tar for seg kallet på BLL-laget. I FIR er GUI-laget en nettside med aspx-sider som inneholder de kontrollerne og HTMLkoden som brukeren vil se når applikasjonen kjører. Mye av koden i disse aspx-sidene blir generert dynamisk når brukeren navigerer seg i applikasjonen. Et eksempel på at det er dynamisk vil være når brukeren ønsker å se meldingene til en gruppe. Da blir meldingene hentet fra Facebook gjennom BLL- og DAL-laget for å så å bli dynamisk generert som HTML-kode i aspx-siden Group.aspx. GUI-laget er delt opp slik at alle aspx-sidene blir generert inne i en master-side. Denne master-siden inneholder de elementene som alltid skal vises i applikasjonen uansett hvilket innhold brukeren velger. Figur 15.4 viser hvilke elementer som blir generert i master-siden. Side 61 av 135

69 Produktdokumentasjon Kapittel 15: FIR Figur 15.4: Elementene i master-siden I GUI-laget ligger det også en mappe som heter css med en CSS fil kalt site.css i. Denne CSS-filen definerer hvilken stil som aspx-sidene skal bruke når de vises i nettleseren til brukeren. I samme laget finner vi også mappen img som inneholder alle bildene som applikasjonen bruker Teknisk arkitektur Dette kapitlet handler om det tekniske rundt applikasjonen, hvilke komponenter som står bak og hvilken betydning de har for at applikasjonen skal fungere. Side 62 av 135

70 Kapittel 15: FIR Noark 5 Dokumentfangst Klienter/Nettlesere Figur 15.5: Teknisk arkitektur til FIR Siden applikasjonen er en webapplikasjon, kreves det at man bruker en nettleser for å ta den i bruk. Som illustrasjonen i Figur 15.5 viser, kommuniserer alle webklienter med applikasjonen via IIS. IIS autentiserer forespørselen hvis nødvendig og lokaliserer den forespurte ressursen (som en ASP.NET applikasjon). Hvis klienten er autorisert, blir ressursen gjort tilgjengelig IIS IIS er en webapplikajonsserver som kjører applikasjonen. IIS er utviklet av Microsoft. Den lytter vanligvis på TCP port 80 for innkommende HTTP-forespørsler og legger dem i en kø, ventende på å bli prosessert. En HTTP-forespørsel går gjennom en rekke steg, kalt hendelser, i kjernen til IIS. ved hver hendelse, prosesseres en del av forespørselen, slik som autentisering av brukeren eller legge til informasjon i hendelsesloggen. Når forespørselen har gått gjennom alle hendelsene, blir responsen returnert Applikasjon Applikasjonen er utviklet i utviklingsmiljøet Visual Studio 2010 med C# og.netrammeverket. For mer informasjon om oppbyggingen til applikasjonen, se kapittel NET Framework Microsoft.NET Framework er programmeringsmodellen av.net-plattformen for å lage, rulle ut og kjøre XML nettbaserte tjenester og alle typer applikasjoner for både maskin og nett. Side 63 av 135

71 Produktdokumentasjon Kapittel 15: FIR Windows Server 2008 Windows Server 2008 er et serveroperativsystem fra Microsoft. Det er systemet som kjører applikasjonsserveren IIS Utviklingsmiljø Programmet brukt til selve utviklingen av produktet er Microsoft Visual Studio Ved å bruke dette programmet har vi hatt mulighet til å bruke det innebygde versjonskontrollsystemet (Team Foundation), noe som har gjort det enkelt for oss å dele kildekoden under utviklingen Dataarkitektur I dette kapittelet kan du lese om hvordan dataflyten er i FIR ved at data kommer fra Facebook og blir arkivert ved hjelp av Noark-kjernen Kommunikasjon med Facebook Facebook har en mekanisme for å la applikasjonen interagere med data fra brukerne. Graph API er en kraftig men likevel enkel RESTful API. Når applikasjonen trenger informasjon fra brukerne, vil du på en eller annen måte bruke Graph API. Figur 3.3 er et diagram som viser hvordan facebookapplikasjoner kommuniserer med Graph API. I eksempelet vil brukeren ha informasjon om en gruppe. Side 64 av 135

72 Kapittel 15: FIR Noark 5 Dokumentfangst Figur 15.6: Kommunikasjon med Facebook gjennom Graph API Applikasjonen kan også kommunisere direkte med Facebook via JavaScript. Her er et eksempel: Vår applikasjon inneholder følgende JavaScript kode som logger brukeren ut av Facebook. function fblogout() { FB.logout(function (response) { // user is now logged out window.location = Index.aspx ; }); } Figur 15.7: Eksempel på JavaScript-kommunikasjon med Facebook Facebook returnerer responsen i JSON og blir tolket av applikasjonen til å logge ut brukeren og vise ham forsiden. Se Figur 15.8 for en enkel illustrasjon av hvordan kommunikasjonen foregår. Side 65 av 135

73 Produktdokumentasjon Kapittel 15: FIR Figur 15.8: Kommunikasjon med Facebook gjennom JavaScript og Graph API Facebook Graph API Graph API lar deg lese og skrive objekter og koblinger i Facebook sin social graph. Det er ganske enkelt å bruke og ligner veldig på RESTful-arkitekturen. For å forstå API-en, er vi nødt til å tenke at hver ting i Facebook er objekter: bilder, arrangementer, kommentarer, venner, tagger, grupper, osv. og vi må vite at hvert objekt i Facebook har en unik identifikator, en ID. Hvis man f.eks. har lyst til å hente informasjon om organisasjonen Bevar Hardanger kan vi skrive denne adressen i nettleseren: Nå vil du se responsen i JSON format, mest sannsynlig noe som ligner på Figur 15.9: { } "id": " ", "name": "Bevar Hardanger!", "picture": " "link": " "category": "Organization", "likes": , "website": "...", "username": "bevarhardanger", "mission": "...", "description": "REGJERINGEN vil bygge en 90 km lang 420 kv kraftlinje tvers gjennom Hardanger.\nMonstermastene er opp til 45m h\u00f8ye og kraftgaten vil bli 40 meter bred \n\n\nvestlandsfjordene er k\u00e5ret til verdens fremste reisem\u00e5l av National Geographic i 2004 og 2009.\n" Figur 15.9: JSON respons fra Facebook Graph API Side 66 av 135

74 Kapittel 15: FIR Noark 5 Dokumentfangst Det er også mulig å spørre API-en ved å bruke brukernavnet (username) som parameter og vi vil få det samme resultatet: Graph API vil vise noe av informasjon som privat og offentlig. Ved å lese på Graph API referansesiden kan man lære om hvilke informasjoner som er private og offentlige, og hvilke rettigheter som kreves for å få tak i dem (se under Connections overskriften). En type informasjon som vi kan få fra Graph API er feed: Vi vil da få noe som ligner på Figur Side 67 av 135

75 Produktdokumentasjon Kapittel 15: FIR { } "data": [ { "id": " _ ", "from": { "name": "Arnhild Kristine Hagen", "id": " " }, "to": { "data": [ { "name": "Bevar Hardanger!", "category": "Organization", "id": " " } ] }, "message": "Først må det jo avklares om hvem som har rett. Treng Bergen mere strøm eller ikke.", "type": "status", "created_time": " T21:16: ", "updated_time": " T21:16: " }, { "id": " _ ", "from": { "name": "Arnhild Kristine Hagen", "id": " " }, "to": { "data": [ { "name": "Bevar Hardanger!", "category": "Organization", "id": " " } ] }, } Figur 15.10: En feed fra Bevar Hardanger sin gruppe i JSON format Feed-objektet består av et array av meldingene som er skrevet i Bevar Hardanger. Autentisering Facebook bruker OAuth 2.0 protokollen for autentisering og autorisering. Mer informasjon om Facebook autentisering kan leses på: Der forklares det veldig godt, men vi vil summere prosessen med en enkel illustrasjon. Side 68 av 135

76 Kapittel 15: FIR Noark 5 Dokumentfangst Facebook sin OAuth 2.0 involverer tre forskjellige steg: brukerautentisering, applikasjonautorisering og applikasjonautentisering. Brukerautentisering sikrer at brukere er den de sier de er. Applikasjonautorisering sikrer at bruker vet akkurat hvilken informasjon og tilganger de gir til applikasjonen. Applikasjonautentisering sikrer at bruker gir sin informasjon til den riktige applikasjonen og ikke en annen. Når alle disse stegene er fullført, mottar applikasjonen en access token som lar applikasjonen få tilgang til informasjonen. Denne prosessen er illustrert i Figur Side 69 av 135

77 Produktdokumentasjon Kapittel 15: FIR Figur 15.11: Autentisering og autorisering i FIR Side 70 av 135

78 Kapittel 15: FIR Noark 5 Dokumentfangst 15.6 Testing Utføring av testing har blitt nedprioritert av flere grunner. Mer om det kan leses i kapittel 7 i prosessdokumentasjonen. Likevel utførte vi noen brukertester med ansatte fra Riksarkivet. Brukertesten bestod av en datamaskin med Noark-arkiv installert i en Ubuntu-VM. FIR ble kjørt i et Windows miljø i nettleseren Google Chrome. Nedenfor følger et eksempel med observasjoner på testen vi utførte. Observasjon av brukerne Scenario: Logge seg inn med sin egen Facebook, velge gruppe, arrangement eller side i menyen, velge ut meldinger man vil arkivere og lagre dem. Observasjoner: Ingen problemer med å skjønne programmet, virket normalt, noen grupper kunne det ikke hentes meldinger fra, lagring av meldinger ble ikke gjort da de ikke ville lagre sine personlige meldinger. Merknad: Applikasjonen ba ikke om nok privilegier fra brukeren ved innlogging, noe som medførte at meldinger ikke kunne leses fra noen grupper Videreutvikling For denne applikasjonen er det flere muligheter for videreutvikling. Slik applikasjonen er utviklet vil det ikke være noe problem å hente inn meldinger fra andre steder på Facebook enn grupper, arrangementer og sider. Vi ser også mulighet for at man kan arkivere på flere steder enn kun Noark. En slik applikasjon vil kunne vokse på lik linje med det vi ser i sosiale medier, fordi nye krav til journalføringspliktige dokumenter kan komme som følge av det Installasjon Facebook applikasjon Før du kan ta i bruk applikasjonen er det nødvendig å opprette en applikasjon på Facebook. Det er nødvendig for å motta en applikasjon-id og en hemmelig kode (secret) slik at applikasjonen kan kommunisere med Facebook. Først besøker du Facebook sin utviklerside og oppretter en ny applikasjon. Side 71 av 135

79 Produktdokumentasjon Kapittel 15: FIR Figur 15.12: Opprettelse av ny facebookapplikasjon Skriv inn det navnet du ønsker som applikasjonsnavn, som My Application, godta vilkårene og trykk Create Application knappen. Etter å ha gått gjennom en sikkerhetskontroll vil du bli presentert Basic Information som skal inneholde den grunnleggende informasjonen om din nye applikasjon. Figur 15.13: Grunnleggende informasjon om facebookapplikasjon Etter at du har lagt inn informasjonen om applikasjonen, skal du legge inn URL-en til applikasjonen som du har kjørende på en server. Denne URL-en skal fylles inn under Core Settings i Web Site. I samme vindu vil du også få opplyst Application ID og Application Secret som vi skal bruke senere i installasjonen. Side 72 av 135

80 Kapittel 15: FIR Noark 5 Dokumentfangst Figur 15.14: Innstillinger for facebookapplikasjon Publisere applikasjonen på en server Installasjon av Noark blir ikke dekket i denne rapporten. Vi antar i denne veiledningen at Noark er installert på en server. Før applikasjonen kan installeres, må den konfigureres til å kommunisere med riktig Noark server. Dette endres ved å åpne kildekoden i Visual Studio og finne Noark5 tjenestereferansen illustrert i Figur Figur 15.15: Noark5 tjenestereferanse Denne filen skal man høyreklikke på og velge Configure Service Reference.... Da får man opp dialogboksen sett i Figur Her endrer man det markerte feltet til adressen til wsdl-filen man fikk når man installerte Noark på serveren. Trykk deretter OK. Side 73 av 135

81 Produktdokumentasjon Kapittel 15: FIR Figur 15.16: Konfigurasjon av tjenestereferanse Deretter må du endre på web.config filen i ExternalFIR prosjektet. Finn linjen som er illustrert i Figur <facebooksettings appid="..." appsecret="..."/> Figur 15.17: Application ID og secret i web.config Her fyller du ut appid og appsecret med de verdiene du fikk når du fullførte opprettelsen av facebookapplikasjonen (se kapittel ). Dette gjøres siden Facebook krever at applikasjonen som henter ut informasjon skal være autorisert. Applikasjonen må installeres på en Microsoft Windows server med IIS 7. Denne guiden tar ikke for seg FTP publisering, da det vil være åpenbart for en som har satt opp FTP server, hvordan man publiserer en nettside til den. Side 74 av 135

82 Kapittel 15: FIR Noark 5 Dokumentfangst For å installere applikasjonen på en server må du først og fremst publisere prosjektet. For å gjøre dette, høyreklikk du på ExternalFIR for så å velge Publish Web Site. Når du har gjort dette får du opp en dialog som spør om hvor den publiserte siden skal lagres. Lag en ny mappe og husk hvor det er. Sørg for at Allow this precompiled site to be updatable ikke er merket av (se Figur 15.18). Figur 15.18: Publisering av nettside På serveren, åpne Internet Information Services og utvid Sites. Dersom det ikke kjører en applikasjon i Default Web Site kan denne benyttes til facebookapplikasjonen. Sørg først og fremst for at en port fører til serveren uten å bli brukt til noe annet. Vanligvis benyttes port 80, og dette er standard i Default Web Site. Sørg for at porten i IIS tilsvarer den du har tilegnet den (dette endres i Bindings under Actions i sidebaren i raden som er type http ). Deretter må du sørge for at.net versjonen i IIS er den korrekte. Dette gjøres i Application Pools som du finner på høyresiden av vinduet. Her må du finne raden som har likt navn som siden du nettopp opprettet. Figur 15.19:.NET versjon i IIS Høyreklikk på denne og velg Basic Settings. Under.NET Framework version skal det stå.net Framework v4.0.xx (se Figur 15.19) Nå som IIS er oppe og går, kan du høyreklikke på Default Web Site under Sites og velge Explore. Hit kan du kopiere filene du publiserte tidligere i guiden. Side 75 av 135

83 Produktdokumentasjon Kapittel 16: Marc (mobilapplikasjon) 16 Marc (mobilapplikasjon) Dette kapittelet vil ta for seg oppbyggingen av Mobildelen av Message Archiver (Marc) samt informasjon til utviklere angående videreutvikling og vedlikehold Krav til utvikler Eventuelle utviklere som skal jobbe med denne applikasjonen må ha kunnskap om og erfaring med programmering i Java. Det vil også være behov for kunnskap om XML og oppbyggingen av en XML-fil. Utviklere bør også ha kjennskap til Eclipse og hvordan et Android prosjekt er bygget opp i dette programmet, da denne applikasjonen er laget i Eclipse med Android SDK. Utvikleren bør også ha kjennskap til Android Beskrivelse av produktet Mobilappalikasjonen er del av en todelt løsning for arkivering av SMS. Denne delen av applikasjonen tar for seg innhenting av SMS fra telefonen, og formaterer denne informasjonen til XML som skrivebordsapplikasjonen kan håndtere Brukergrensesnitt og design Brukergrensesnittet på applikasjonen er bygget opp for at brukeren skal enklest mulig kunne sette seg inn i programmet og dets bruksområde. Både i brukergrensesnittet og designet har det blitt lagt ned mye tanker om hvordan vi skal gjøre programmet mest mulig effektivt, både for erfarne brukere og nybegynnere. Mål Et mål vi hadde når vi utviklet denne applikasjonen var at Marc sin mobildel skulle være så enkel som mulig. Den skulle ha et minimalt antall knapper, og skulle være lett for alle smarttelefon-eiere å navigere applikasjonen. Designvalg I mobilapplikasjonsdelen av Marc har vi en splashscreen som møter brukeren (se Figur 16.1). Figur 16.1: Splashscreen Denne har samme utseende som forsiden på denne dokumentasjonen. Denne splashscreenen har egentlig som funksjon å gi brukeren noe å se på mens applikasjonen laster, men har også den funksjonen og vise brukeren at det er en Noark applikasjon, fordi den følger samme tema. Side 76 av 135

84 Kapittel 16: Marc (mobilapplikasjon) Noark 5 Dokumentfangst Figur 16.2: Skjermbilde av mobilapplikasjonen Ellers er plassering av knapper satt på bunnen av skjermbildet, dette for å tvinge brukeren til å lese all informasjon som står ovenfor før han/henne ser knappene og trykker på dem(se Figur 16.2). En OK boks er lagt til etter meldingene er lagret eller ikke lagret for at brukeren skal få tilbakemelding på om oppgaven han nettopp utførte ble vellykket eller ikke. Hadde det kun vært en melding som poppet opp og ble borte av seg selv er det mulig brukeren hadde sett bort å ikke fått med seg meldingen, noe som ville ført til at brukeren ble usikker på om han hadde fått lagret eller ikke. Meny I mobilapplikasjonsdelen av Marc har vi en veldig enkel meny. Som nevn i designvalg har vi kun to knapper som alltid vil ligge på bunnen av skjermen. Menyen er delt opp i tre deler. Toppdel, midtdel og bunndel. I toppdelen ligger navnet på programmet. I midtdelen ligger informasjonen og nederst ligger knappene. Eneste delen som endrer seg gjennom programmet er midtdelen, der det først gis informasjon om bruk, for så å være scrollområde for kontaktene Applikasjonsarkitektur Dette kapittelet tar for seg oppbygningen av et Android prosjekt, og tekniske utfordringer vi har møtt på under programmeringen av denne applikasjonen Android prosjekt Applikasjonen er bygd opp i Eclipse med standard Android project structure. Denne strukturen deler opp delene av applikasjonen i forskjellige lag. Etter at du har opprettet et prosjekt i Eclipse vil du få struktur som ligner på den i Figur Videre skal vi nå ta for oss kort hva hver mappe inneholder SRC Denne mappen inneholder Java kildekode som vi har laget. Fra Figur 16.3 ser du alle klassene vi har opprettet til denne applikasjonen. Filene inne i denne mappen vil bli organisert etter pakkestrukturen. Denne er lik /src mappen som er i alle vanlige Javaprosjekter. Side 77 av 135

85 Produktdokumentasjon Kapittel 16: Marc (mobilapplikasjon) InteractiveArrayAdapter.java: Er en adapter som lytter til checkboxen. Hvis checkboksen blir valgt vil dataen som er knyttet til den endret. Kontakt.java: Klasse som tar seg av set og get metoder til kontaktobjektet. Melding.java: Klasse som tar seg av set og get metoder til meldingsobjektet. NoarkSMS.java: Kjøreklassen. Her opprettes UI og kode for opprettelse av XML fil ligger her. Splash.java: En aktivitet som starter en tråd som viser splashscreen under boot GEN Dette er også en kildekode mappe, men inneholder filer som blir generert automatisk av Android plattformen. Blant de genererte filene er R klassen, som kan sees på figuren. Rammeverket vil generere denne R klassen Android versjonsnummer I denne mappen er bibliotekene (jars) som trengs til prosjektet. I Figur 16.3 kan du se at den inneholder rammeverkets JAR-fil. Denne mappen er lik /lib mappen som finnes i alle Java prosjekter. Vi bruker Android versjon 2.1, selv om nyeste versjon er 2.3. Dette har med testing å gjøre. Vi hadde tilgang på en androidtelefon med versjon 2.1, og siden vi ville være sikre på at programmet ville fungere på denne telefonen valgte vi å programmere i Android versjon Assets Denne mappen inneholder eksterne ressurser som blir brukt i applikasjonen, akkurat som res folderen. Hovedforskjellen er at her blir ressursene lagret i råformat og kan kun bli lest av programmet. Denne folderen brukes ikke under dette prosjektet, fordi vi rett og slett ikke har noen ressurser som kun trengs å leses av programmet RES Denne mappen inneholder all eksterne ressurser (bilder, datafiler og så videre) som blir brukt av Android applikasjonen. Disse eksterne ressursene blir referert til i applikasjonen. I denne mappen er det i tillegg 3 undermapper. Figur 16.3: Prosjektstruktur Side 78 av 135

86 Kapittel 16: Marc (mobilapplikasjon) Noark 5 Dokumentfangst /res/drawable Denne mappen inneholder alle bilder. Alle bildene og ikonene vi har bruk i applikasjonen har vi lagt her, dvs. ikon vi bruker til applikasjonen og splashscreen som vises under oppstart. /res/layout Denne mappen inneholder alle definisjonene av brukergrensesnittet. Disse filene er lagret som XML filer. main.xml: Tar for seg hovedutseendet til applikasjonen. rowbuttonlayout.xml: Tar for seg radene av avkrysningsbokser til kontaktene. splashscreen.xml: Tar for seg velkomstskjermen til applikasjonen. /res/values Denne mappen inneholder XML filer, som inneholder nøkkelverdier som blir referert til i applikasjonen. Disse XML filene deklarerer Arrays, farger, dimensjoner, strings osv. Ideen med å ha disse verdiene i en separat XML fil er så verdiene kan bli brukt basert på det lokale språket uten å trenge å endre på kildekoden. Dette er nyttig om du vil ha flere språkvalg på applikasjonen. Vi har ingen foreløpige planer om å ha andre språk på applikasjonen, og har derfor hardkodet disse verdiene inn i kildekoden istedenfor AndroidManifest.xml Dette er en XML fil som inneholder metadata om Android applikasjonen, og er en viktig fil for alle Android prosjekter. Denne inneholder informasjon om aktivteter, views, services osv. Den inneholder også en liste over brukertillatelser som trengs for å kunne kjøre applikasjonen. Side 79 av 135

87 Produktdokumentasjon Kapittel 16: Marc (mobilapplikasjon) Figur 16.4: AndroidManifest.xml Som man kan se i Figur 16.4 har vi bedt om tilgang til å kunne lese kontakter, lese SMS, skrive til minnekort og lese telefontilstand. Vi trenger alle disse for å kunne utføre oppgavene vi ønsker. Du ser de to aktivitetene NoarkSMS og Splash. Dette er hovedprogrammet, og velkomstvinduet Tekniske utfordringer Møtt på endel utfordringer gjennom utviklingen av denne applikasjonen. Som det kan leses i prosessdokumentasjonen har denne applikasjonen gjennomgått endel endringer siden den først ble påtenkt. En utfordring var det å få hentet informasjon ut av mobilen. Anbefaler å lese del om Content Resolvers, del om SQLite og lese om URI (Uniform Resource Identifier) på en.wikipedia.org om du ikke har kunnskap om dette fra før. Side 80 av 135

88 Kapittel 16: Marc (mobilapplikasjon) Noark 5 Dokumentfangst Figur 16.5: Uthenting av SMSer Figur 16.5 viser hvordan vi har gått frem for å hente informasjon ut av mobilen. Opprettet en Uri som parser ContentResolveren til inbox. Nå vil denne URI-en inneholde en tabell i SQLite format. For hver linje i tabellen gjør vi om hver kolonne til tekstverdier. Deretter sjekker vi om nummeret er større en 8. Dette er fordi nummer kan være eller Så tar vi de siste 8 sifrene og oppretter telefonnummeret. Setter så type til Received, Sent eller Unknown avhengig av verdi på type. Når alt dette er gjort oppretter vi et meldingsobjekt og legger dette objektet i en liste over meldingsobjekter. Utfordringen nå var å knytte dette meldingsobjektet til en kontakt sin meldingsliste. Side 81 av 135

89 Produktdokumentasjon Kapittel 16: Marc (mobilapplikasjon) Figur 16.6: Knytte melding til rett kontakt Løsningen kan leses i Figur Vi har her tre for each løkker som sjekker om meldingobjektet har samme nummer som et av numrene til et kontaktobjekt. Den ser igjennom alle numrene til alle kontaktobjektene. Hvis programmet finner en kontakt legger det til meldingen i kontakten sin meldingsliste. Om kontakten ikke blir funnet betyr det at meldingen er fra en person som ikke er i kontaktlisten, og det blir derfor opprettet et nytt kontaktobjekt. Vi ønsker kun å vise kontakter som det har blitt sendt meldinger med, så går derfor igjennom kontaktlisten og oppretter en ny kontaktliste som kun inneholder disse kontaktene. Deretter returnerer vi denne listen Teknisk arkitektur Applikasjonen er utviklet i Android. Under ser du en figur som beskriver oppbyggingen av komponentene i den tekniske arkitekturen til Android. For mer informasjon om oppbygging av applikasjonen, se avsnitt 4.3 i produktdokumentasjonen Side 82 av 135

90 Kapittel 16: Marc (mobilapplikasjon) Noark 5 Dokumentfangst Applikasjonslaget Figur 16.7: Teknisk arkitektur til Android Android kommer med et sett kjerneapplikasjoner. Dette er blant annet en klient, SMS program, kalender, kart, nettleser, kontakter og mange andre. Alle disse applikasjonene er skrevet i Java Rammeverklaget Ved å tilby en åpen utviklingsplattform, gir Android utviklere muligheten til å bygge komplekse og innovative applikasjoner. Utviklere kan fullt utnytte enhetens hardware, få tak i plasseringsinformasjon, kjøre bakgrunnsprogrammer, sette alarmer, legge til varslinger i statusbaren og mye mer. Side 83 av 135

91 Produktdokumentasjon Kapittel 16: Marc (mobilapplikasjon) Utviklere har full tilgang til det samme rammeverkets API som blir brukt av kjerneapplikasjonene. Applikasjonsarkitekturen er designet for å gjøre det lettere å bruke komponenter om igjen, hvilken som helst applikasjon kan publisere sin hensikt, som andre applikasjoner igjen kan bruke, det vil si så lenge de er innenfor sikkerhetsbegrensningen som er satt av rammeverket. Dette betyr at vi kunne ha laget en egen SMS applikasjon uten de store utfordringene, som kunne sendt og mottatt SMS vi kan lagre på mobilen som vi ønsker. Vi hadde da tatt i bruk kjerneapplikasjonen som sender SMS, tatt i bruk dens metoder og videre implementert nye til vi hadde fått en helt ny applikasjon. Under alle disse applikasjonene kjører det tjenester og systemer, inkludert: Views: Kan brukes til å bygge applikasjoner. Inkluderer lister, rutenett, tekstbokser, knapper, og til og med innebygget nettleser. Content Providers: gir applikasjoner adgang til data fra andre applikasjoner, og gir de tilgang til å dele egen data. Vi har brukt content providers blant annet til å få tak i kontakter som ligger i kontaktlista og meldinger som ligger i innboks. Resource Manager: Gir tilgang til ressurser som ikke er kode, eks lokaliserte stringer, bilder og layout filer. Notification Manager: Gir applikasjoner mulighet til å vise tilpassede meldinger i statusbaren Activity Manager: Tar seg av livssyklusen til applikasjoner. Det vi har gjort i vår applikasjon er å bruke Content Provider for å få adgang til data fra kjerneapplikasjonene; kontaktapplikasjonen og SMS applikasjonen. Denne informasjonen ligger i en SQLite databaseformat, som vi skal ta mer for oss i kapittel Biblioteker Android inkluderer C/C++ biblioteker som blir brukt av forskjellige komponenter i Android systemet. Utviklere kan bruke disse bibliotekene gjennom Androids applikasjonsrammeverk. Nedenfor følger noen av kjernebibliotekene: System C bibliotek: Standard C system bibliotek, laget for Linux baserte enheter. Media bibliotek: Støtter avspilling og opptak av mange populære lyd og videoformat. Støtter også bildefiler. Surface Manager - tar seg av tilgang til skjermen og tar seg av de 2D og 3D grafiske lagene for flere applikasjoner. LibWebCore: Moderne nettleserkjerne som kjører Android nettleseren. SGL: 2D grafikkmotoren. 3D biblioteker: En implementasjon basert på OpenGL ES 1.0API. Bruker enten hardware 3D akselerajon (der det er mulig) eller den inkluderte 3D programvaren. FreeType: bitmap og vektor font gjengivelse. SQLite: En kraftig og lett relasjonsdatabasemotor tilgjengelig for alle applikasjoner. Side 84 av 135

92 Kapittel 16: Marc (mobilapplikasjon) Noark 5 Dokumentfangst Android Runtime Hver androidapplikasjon kjører i sin egen prosess, med sin egen instans av Dalvik virtuelle maskin. Dalvik ble skrevet for at en enhet skal kunne kjøre flere VMer effektivt. Dalvik VM kjører filer i Dalvik Executable (.dex) format som er optimalisert for å være minnebesparende. VM-en er registerbasert, og kjører klasser kompilert av en Javakompilator som har blitt transformert til.dex format av et dx verktøy. Dalvik VMen er avhengig av underliggende funksjonalitet i Linux-kernelen, som ved bruk av tråder og minnehåndtering på lavnivå Linux Kernel Android er avhengig av Linux versjon 2.6 for kjernesystemets tjenester som sikkerhet, minnehåndtering og prosesshåndtering. Kernelen fungerer også som et abstrakt lag mellom hardware og resten av programvaren Dataarkitektur Figur 16.8: Dataarkitekturen i Marc Figur 16.8 illustrerer dataflyten i applikasjonen. Den viser hvordan meldingene blir hentet fra en SQLite databasestruktur, for så å bli lagt i en XML fil av mobilapplikasjonen. Skrivebordsapplikasjonen leser så denne XML fila, og sender nødvendig informasjon inn til en Noark-server i standardformatet XML-struktur XML filen har følgende struktur: Side 85 av 135

93 Produktdokumentasjon Kapittel 16: Marc (mobilapplikasjon) <SMSExport> <SMSMessage> <Kind>Sent</Kind> <DateTime> :50: </DateTime> <Name>Ola Nordmann</Name> <Number> </Number> <Message>Dette er en melding</message> </SMSMessage> </SMSExport> Figur 16.9: Strukturen i XML-filen Punktene er hentet fra Content Provideren til SMS som er i SQLite databasestruktur. Denne inneholder flere punkter enn de vi har tatt med, men er ikke vesentlige for at applikasjonen skal fungere Testing Som det kan leses i prosessdokumentasjonen så har testing blitt nedprioritert. Selv med nedprioriteringen har vi fått til noen brukertester. Vi hadde fått tak i 3 testpersoner som hver hadde en androidtelefon å teste på. Alle telefonene hadde Android 2.1 eller nyere. Brukerne fikk i oppgave å kjøre programmet som vanlig mens vi observerte dem. Nedenfor følger et eksempel på testen vi utførte på brukerne. Observasjon av bruker 1 Scenario: Starte programmet, velge kontakter og lagre disse. Observasjoner: Ingen problemer med å skjønne programmet, kontaktene kom opp uten problemer, fikk valgt og lagret uten feilmeldinger. Merknader: Ingen. Alle 3 brukerne vi observerte ga oss samme informasjon som bruker 1. Selv om 3 personer er litt liten brukergruppe å gå ut ifra, har vi fått et greit inntrykk om at programmet fungerer som det skal Videreutvikling Det er mange muligheter til videreutvikling på denne applikasjonen. Det kan være tungvint å måtte koble telefonen til PC-en for å kunne hente meldinger. En mulighet ville vært å istedenfor å lagre meldingene på telefonen, så sendes de til en webserver. Her kan da brukeren gå inn på en nettside å endre på meldingene sine, for så å sende de inn til Noark. Side 86 av 135

94 Kapittel 16: Marc (mobilapplikasjon) Noark 5 Dokumentfangst En annen mulighet ville vært å gi brukeren mulighet til å også velge meldinger han/hun vil lagre Installasjon For å installere programmet trenger du en androidtelefon med versjon 2.1 eller nyere. Du må laste ned applikasjonen og godta tilgangen applikasjonen skal ha på telefonen din. Applikasjonen ligger ikke ute på Android Market, så du er nødt til å krysse av for å godkjenne usignert programvare. Side 87 av 135

95 Produktdokumentasjon Kapittel 17: Marc (skrivebordsapplikasjon) 17 Marc (skrivebordsapplikasjon) Dette kapittelet vil ta for seg oppbyggingen av skrivebordsapplikasjonsdelen av Marc. For mobilapplikasjonsdelen, se kapittel Krav til utvikler Eventuelle utviklere som skal jobbe videre med dette prosjektet må ha kunnskap til.net rammeverket, samt C#, XML og noe erfaring med SOAP. Utviklere burde også ha kjennskap til MVC arkitekturen Beskrivelse av produktet Dette programmet er skrivebordsapplikasjonen som skal benyttes ved siden av mobilapplikasjonen Marc. Den henter inn meldinger som er lagret på mobil, og gir brukeren mulighet til å finpusse valgene han/hun gjorde på mobilen før meldingene blir sendt til Noark Brukergrensesnitt og design Brukergrensesnittet på applikasjonene er bygget opp for at brukeren skal enklest mulig kunne sette seg inn i programmet og deres bruksområde. Både i brukergrensesnittet og designet har det blitt lagt ned mye tanker om hvordan vi skal gjøre programmet mest mulig effektivt, både for erfarne brukere og nybegynnere. I skrivebordsapplikasjonen for Marc fant vi ut at det ikke var nødvendig med så mange valg, da dens oppgave var veldig enkel; den skulle kun hente inn meldinger fra mobil, og sende valgte inn i arkiv Applikasjonsarkitektur Også denne applikasjonen benytter seg av MVC standarden, og kun små endringer i DAL laget vil gjøre det mulig å endre hvilken server som benyttes til lagring Modellaget (Model) Modellaget er det som i løsningen sees som Model. Her finner man hovedsakelig MessageModel og ContactModel. Disse kan sees på som maler til henholdsvis meldinger og kontakter. Ellers finner man også GlobalVariables som er et lagringsobjekt der meldingene man velger blir lagret for så å bli sendt inn til Noark. Til slutt finner man MessageKind som kun er en enum, som er en slags liste over godtatte verdier for Kind feltet (om meldingen er sendt eller mottatt). Side 88 av 135

96 Kapittel 17: Marc (skrivebordsapplikasjon) Noark 5 D Viewlaget (Marc) Viewlaget er det prosjektet som heter Marc. Dette prosjektet tjener som brukergrensesnittet til applikasjonen. Her finner man følgende filer: Main.cs Denne filen er hovedvinduet til applikasjonen ChooseDevice.cs Dialogvinduet hvor man velger hvilket tilkoblet enhet som skal brukes ContactListItem.cs En rad i listen over kontakter som vises i Main.cs MessageListItem.cs En rad i listen over meldinger assosiert med valgt kontakt i Main.cs I tillegg finner man også mappen img som inneholder alle grafiske elementer som benyttes i brukergrensesnittet Data Access Layer (DAL) Dette laget benyttes for å hente ut data fra den valgte enheten. Den har også en service reference til Noark serveren som den behandlede dataen skal sendes til. MessageRep.cs brukes til å hente meldinger fra mobilen, mens NoarkRep.cs brukes til å kommunisere med Noark serveren. Figur 17.1: Mappestruktur i Marc (skrivebordsapplikasjon) Business Logic Layer (BLL) Dette prosjektet tjener som et mellomledd mellom Marc og DAL Teknisk arkitektur Under er det en figur som illustrerer den tekniske arkitekturen av en applikasjon som kjører på en Windows maskin. Side 89 av 135

97 Produktdokumentasjon Kapittel 17: Marc (skrivebordsapplikasjon) Figur 17.2: Arkitekturen i en applikasjon i Windows Denne figuren er todelt. Den øverste delen er selve applikasjonen, mens den nederste er systemressursene den bruker. Applikasjonen kommuniserer med systemressursene via.net rammeverket Utviklingsmiljø Programmet brukt til selve utviklingen av produktet er Microsoft Visual Studio Ved å bruke dette programmet har vi hatt mulighet til å bruke det innebygde versjonskontrollsystemet (Team Foundation), noe som har gjort det enkelt for oss å dele kildekoden under utviklingen Dataarkitektur Applikasjonen kommuniserer med mobilen kun ved å finne en XML fil liggende et spesifikt sted på mobilens SD-kort. Denne XML-filen er bygd opp slik: Side 90 av 135

98 Kapittel 17: Marc (skrivebordsapplikasjon) Noark 5 D <SMSExport> <SMSMessage> <Kind>Sent</Kind> <DateTime> :50: </DateTime> <Name>Ola Nordmann</Name> <Number> </Number> <Message>Dette er en melding</message> </SMSMessage> </SMSExport> 17.6 Testing Figur 17.3: En melding i XML format Det har vært minimalt med brukertesting av også dette programmet. Grunnen til det er hovedsakelig at det ble nedprioritert da vårt prosjekt er et såkalt proof of concept. Det vil si at det vi har laget er et bevis på at problemstillingen er løsbar, og at programmet er ment å videreutvikles Videreutvikling Mulighetene for videre utvikling av programmet er mange. Det kan for eksempel være lokal lagring av meldinger og lagring av økter - det vil si at man kan lagre endringer gjort, og fortsette der man slapp neste gang man åpner programmet. En annen videreutvikling kan være å automatisere installasjonsprosessen. I den tilstand programmet er i nå, må det gjøres endringer i programkoden for å angi hvilken Noark server det skal koble seg til (se 17.8). Man kan eventuelt også gi muligheten til å ha en liste over forskjellige servere, hvor man kan velge en server man ønsker å sende til Installasjon Installasjon av Noark blir ikke dekket i denne rapporten. Vi antar i denne veiledningen at Noark er installert på en server. Før programvaren kan installeres på en brukers maskin, må den konfigureres til å kommunisere med riktig Noark server. Dette endres ved å åpne kildekoden i Visual Studio og finne Noark5 tjenestereferansen illustrert i Figur Figur 17.4: Noark5 tjenestereferanse Denne filen skal man høyreklikke på og velge Configure Service Reference.... Da får man opp dialogboksen sett i Figur Her endrer man det markerte feltet til adressen til wsdl filen man fikk når man installerte Noark på serveren. Trykk deretter OK. Side 91 av 135

99 Produktdokumentasjon Kapittel 17: Marc (skrivebordsapplikasjon) Figur 17.5: Konfigurasjon av tjenestereferanse Når dette er gjort skal man kunne publisere applikasjonen. Først høyreklikker man Solution Marc (5 projects) og velger Build Solution. Når den er ferdig med det, finner man prosjektet MarcInstaller, høyreklikker på det, og velger Build. Når det så står Build succeeded nederst til venstre kan man navigere seg til /Marc/MarcInstaller/Debug/ og finne MarcInstaller.msi. Denne filen kan benyttes for å installere programmet. Side 92 av 135

100 Kapittel 18: Kilder Noark 5 Dokumentfangst 18 Kilder Microsoft Developer Network (MSDN),.NET Framework 4 Class Library Reference Android Developers Reference Facebook Graph API Facebook C# SDK Side 93 av 135

101 Produktdokumentasjon Kapittel 19: Vedlegg 19 Vedlegg 19.1 Kravspesifikasjon Funksjonelle krav Informere medlemmer av grupper, arrangementer og sider. Administratorer av grupper, arrangementer og sider skal informere medlemmene om at meldingene kan bli arkivert. Innhenting av informasjon fra Facebook Applikasjonen skal kunne hente informasjon fra Facebook. Brukere autentiserer og godtar applikasjon Brukere av applikasjonen må autentiserer seg ved å logge inn på Facebook og godta at applikasjonen får tilgang til informasjon om Facebook-kontoen. Få oversikt over grupper, arrangementer og sider Brukere skal få se en liste av grupper, arrangementer og sider de administrerer på Facebook i applikasjonen. Se nyhetsoppdatering (feed) til grupper, arrangementer og sider En bruker skal kunne velge en gruppe, arrangement og side og kunne se de meldingene som har blitt skrevet på feed-en. Filtrere feed Brukere skal kunne filtrere meldinger og kommentarer som er hentet inn fra en gruppe, arrangement eller side. De skal kunne søke etter stikkord i innholdet i meldingene, finne meldinger fra en dato eller tidsperiode og sortere på type melding. Mulighet til å velge den informasjonen som skal arkiveres Brukere skal kunne velge meldinger og kommentarer de ønsker å arkivere. Se oversikt over resultatet fra utvelgelsen Etter at brukere har valgt de meldingene og kommentarene de ønsker å arkivere, skal de kunne se en oversikt over det de har valgt før de sender det til arkivet. Krav for arkivering Applikasjonen skal arkivere data i Noark-kjernen. Arkiveringen av meldingene skal gå over SOAP. WSDL til Noark-kjernen skal brukes. Ikke-funksjonelle krav Programvarestøtte Skal fungere på de fleste PC-er. Side 94 av 135

102 Kapittel 19: Vedlegg Noark 5 Dokumentfangst Ytelseskrav Skal ikke gå utover ytelsen til PC-en. Lagring av informasjon Skal kunne lagre all informasjon som en wall har. Pålitelighetskrav Applikasjonen skal ha en høy oppetid og den skal være sikker i bruk. Brukervennlighetskrav Applikasjonen skal ha et kjent utseende. Den skal følge Facebook i knapper, plassering, menyer osv. Etiske krav Applikasjonen skal ikke gi ut informasjon om personer som ikke ønsker å få informasjonen om seg selv lagret i en Noark server. Lovmessige krav Applikasjonen skal ikke bryte personvernloven på noen måte. Funksjonelle krav til mobilapplikasjonen Laste opp SMS, både sendte og mottatte. Mobilapplikasjonen skal kunne lese både sendte og mottatte SMS som ligger på telefonen, og laste disse opp. Velge kontakter Brukeren skal ha mulighet til å velge hvilke kontakter han vil laste opp SMS fra. Laste opp Applikasjonen skal kunne laste opp SMS til en skrivebordsapplikasjon. Ikke-funksjonelle krav til mobilapplikasjonen Programvarestøtte Skal fungere på mobiltelefoner som har Android 2.1 OS eller nyere. Ytelseskrav Skal ikke gå utover ytelsen til telefonen. Krav til lagringskapasitet Skal kunne lagre all informasjon på et SD-kort. Funksjonelle krav til skrivebordsapplikasjonen Innhenting av informasjon Applikasjonen skal kunne hente inn SMS sendt av mobilapplikasjonen. Side 95 av 135

103 Produktdokumentasjon Kapittel 19: Vedlegg Velge SMS Brukeren av applikasjonen skal kunne velge hvilke SMS som skal lagres. Meldingshåndtering Skal motta en XML fil fra mobilapplikasjonen, så sende denne inn til en Noark server i SOAP format. Kontakthåndtering Mulighet til å sette opp SMS i en samtale, til og fra. Skal kunne velge meldinger fra forskjellige kontakter. Meldingsformatering Formatere SMS-ene til et format som passer for Noark. Ikke-funksjonelle krav til skrivebordsapplikasjonen Programvarestøtte Skal fungere på de fleste PC-er. Ytelseskrav Skal ikke gå utover ytelsen til PC-en. Side 96 av 135

104

105

106

107 Forord Dette produktet er en del av hovedprosjektoppgaven til gruppe 33 vår Produktet er en facebookapplikasjon kalt FIR som har som hensikt å lagre facebookmeldinger i en Noark standard. For å bruke denne applikasjonen trengs det ingen forkunnskaper. Brukerdokumentasjonen er skrevet for deg som skal bruke applikasjonen. Det vil beskrives hvordan man kan bruke den. Om du har lest prosessdokumentasjonen eller produktdokumentasjonen kapittel 2 Det endelige produktet, kan du hoppe over innledningen.

108

109 Innholdsfortegnelse 20 Innledning Installasjon Brukerveiledning Innlogging i Facebook Hente meldinger Filtrere meldinger Filtrere på innhold Filtrere på dato Filtrere på type melding Fullføre filtreringen Velge meldinger som skal arkiveres Arkivere de valgte meldingene Side 102 av 135

110 Side 103 av 135

111 Brukerveiledning FIR Kapittel 20: Innledning 20 Innledning Facebookapplikasjonen eller Facebook Information Retriever som vi har døpt den har som funksjon å hente og lagre informasjon som brukeren definerer som journalføringspliktig. Applikasjonen henter inn alle grupper, sider og arrangementer som brukeren administrerer. Brukeren kan så velge en gruppe, side eller arrangement han vil journalføre, velge hvilke meldinger han vil ha med, merke disse og få opp en forhåndsvisning. Er brukeren fornøyd kan han/hun velge å sende inn og dokumentet vil bli gjort om til et format Noark kan håndtere, og lagres i arkivet. Figur 20.1: Dataflyt i facebookapplikasjonen Side 104 av 135

112 Kapittel 21: Installasjon Noark 5 dokumentfangst 21 Installasjon Installasjon av facebookapplikasjonen FIR krever at du har en noarktjeneste tilgjengelig og modifiserer programvarekoden deretter. Du er også nødt til å opprette en applikasjon på Facebook. For å se hvordan alt dette gjøres, se produktdokumentasjon 15.8 om installasjon. Side 105 av 135

113 Brukerveiledning FIR Kapittel 22: Brukerveiledning 22 Brukerveiledning Starter du FIR, får du et velkomstbilde som ser ut som Figur 4.1. Applikasjonen er delt inn i tre hovedseksjoner som vi skal forholde oss til videre i denne veiledningen. Navigasjonen øverst som lar deg navigere tilbake til hjemmeområdet og din profil på Facebook samt en mulighet for å logge deg inn og ut av Facebook direkte fra applikasjonen. På venstre side, under FIR NOARK -logoen, er det en meny som lar deg velge hvilke gruppe, arrangement eller side du skal hente meldinger fra. I samme meny finner du nederst noen linker til informasjon om Noark og offentlighetsloven som kan være nyttig for deg som skal arkivere. I midten av applikasjonen er området hvor informasjonen du velger fra menyen vises. Figur 22.1: Velkomstbildet i FIR 22.1 Innlogging i Facebook Før du kan gå videre med applikasjonen er du nødt til å logge deg inn på Facebook. Det kan du gjøre direkte fra applikasjonen dersom du ikke er logget inn fra før. 1. Klikk Logg inn øverst til høyre i applikasjonen, og du vil få opp et vindu som ser ut som i Figur Fyll inn din epostadresse og passord og klikk Login. Side 106 av 135

114 Kapittel 22: Brukerveiledning Noark 5 dokumentfangst Figur 22.2: Innloggingsvindu 2. Om dette er første gang du bruker denne applikasjonen, er du også nødt til å godta at applikasjonen får tilgang til informasjon om din Facebook-konto. Du vil nå se et vindu som i Figur For å gå videre må du klikke Allow. Figur 22.3: Tillatelse til å hente ut informasjon fra din Facebook-konto 22.2 Hente meldinger 1. Etter at du har logget inn vil det nå ha dukke opp, i venstre meny, grupper, arrangementer og sider som du administrerer eller eier. Se Figur Klikk på en av dem. 2. Hvis den du valgte inneholder meldinger, vil det vises i midten av applikasjonen. Se Figur Figur 22.4: Menyen fylt med grupper, arrangementer og sider Side 107 av 135

115 Brukerveiledning FIR Kapittel 22: Brukerveiledning Figur 22.5: Meldingene vises i midten etter at du valgte i menyen 22.3 Filtrere meldinger Skal du filtrere meldingene på innhold, dato eller type, kan du gjøre det til høyre i bildet. Alle filtreringsmåtene kan kombineres sammen. Se Figur Figur 22.6: Filtrering av meldinger Side 108 av 135

116 Kapittel 22: Brukerveiledning Noark 5 dokumentfangst 22.4 Filtrere på innhold I feltet under Søkestreng kan du filtrere meldingene og/eller kommentarer på innhold. 1. Skriv inn det du vil søke etter i feltet. Se Figur Du kan søke etter stikkord slik: forsinket tog uten anførselstegn, og den vil finne meldinger og kommentarer som inneholder forsinket og tog uavhengig av hverandre. Ønsker du å søke etter en setning kan du bruke anførselstegn. Figur 22.7: Felt for søkestreng 2. Velg om du vil filtrere meldinger eller kommentarer, eller begge Filtrere på dato Skal du finne meldinger fra en gitt dato eller periode kan du velge fra dato og til dato. se Figur Figur 22.8: Datofiltrering 1. Klikk på feltet under fra dato og du får noe som ligner Figur Klikk på feltet under til dato og du får noe som ligner Figur Side 109 av 135

117 Brukerveiledning FIR Kapittel 22: Brukerveiledning Figur 22.9: Datofiltrering (fra dato) Figur 22.10: Datofiltrering (til dato) 22.6 Filtrere på type melding Skal du filtrere meldinger på type kan du gjøre det her. Hvis alle eller ingen typer er valgt, hentes alle meldinger. Hvis en er valgt som f.eks. status hentes kun statusmeldinger. Se Figur Figur 22.11: Filtrering på type melding 22.7 Fullføre filtreringen Når du har funnet ut hvordan du vil filtrere, klikker du på Filtrer. Se Figur Figur 22.12: Filtreringsknapper 22.8 Velge meldinger som skal arkiveres 1. Når du finner fram til meldingene eller kommentarene du vil arkivere kan du klikke på avhukingsboksene og de skal være valgt. Se Figur Side 110 av 135

118 Kapittel 22: Brukerveiledning Noark 5 dokumentfangst Figur 22.13: Valgte meldinger 2. Hvis du ønsker å velge alle meldinger og kommentarer klikker du på Velg alle. Det samme gjelder om du vil fjerne de valgene du har gjort, da klikker du Nullstill valg. Se Figur Arkivere de valgte meldingene Når meldingene og kommentarene du vil arkivere er valgt, er det neste som skal gjøres å faktisk arkivere dem. 1. Klikk på Sjekk ut som du finner øverst til høyre. Se Figur Figur 22.14: Sjekk ut-knapp for å arkivere meldinger og kommentarer 2. Du skal nå se en side med kun de meldingene og kommentarene du valgte. Se Figur Side 111 av 135

119 Brukerveiledning FIR Kapittel 22: Brukerveiledning Figur 22.15: Meldinger og kommentarer som skal arkiveres 3. Hvis meldingene og kommentarene du ser stemmer med det du valgte, kan du klikke på Bekreft og de vil bli arkivert. Hvis du vil endre på utvalget, kan du klikke på Tilbake. Se Figur Figur 22.16: Bekreft- og tilbakeknapp Side 112 av 135

120

121

122

123 Forord Dette produktet er endel av hovedprosjektoppgaven til gruppe 33 vår Produktet har som hensikt å lagre SMS meldinger i en Noark standard. Leseren av denne brukermanualen skal ikke trenge noen forkunnskaper for å installere og bruke denne programvaren, utenom kunnskap om hvordan bruke en Android telefon og pc. Denne manualen inneholder informasjon om installasjon og bruk av programmet. Den er delt opp i to deler, en for mobildelen og en for skrivebordsdelen av applikasjonen. Om du har lest prosessdokumentasjonen eller produktdokumentasjonen kapittel 2 Det endelige produktet som også er en del av dette prosjektet har du alt fått informasjon om programmet og kan hoppe over innledningen.

124

125 Innholdsfortegnelse 23 Innledning Installasjon Mobilapplikasjon Skrivebordsapplikasjon Brukerveiledning Mobilapplikasjon Manual Referanser Skrivebordsapplikasjon Side 118 av 135

126 Side 119 av 135

127 Brukerveiledning Marc Kapittel 23: Innledning 23 Innledning Dette programmet er en todelt applikasjon. Den ene er en mobilapplikasjon på Android som viser deg en liste over personer du har sendt meldinger med, enten med navn du har lagret i kontaktlisten din, eller med nummer om du ikke har de lagret. Du kan videre velge personer, og lagre meldinger fra disse på minnekortet til mobilen i en XML fil. Denne filen kan enkelt transporteres til PC. Når du nå kobler mobilen til PC-en skal vi ta i bruk den andre delen av løsningen. Dette er en skrivebordsapplikasjon som finner mobilen, og henter ut meldingene som vi nå har lagret på mobilens minnekort. Her kan du igjen velge personer, og hvilke meldinger fra valgt person du vil ha arkivert. Etter dette er det bare å velge send inn, og meldingene blir gjort om til et format Noark kan håndtere og arkiveres i arkivet. Side 120 av 135

128 Kapittel 24: Installasjon Noark 5 Dokumentfangst 24 Installasjon Dette kapittelet tar for seg installasjon av mobil og skrivebordsapplikasjonen Mobilapplikasjon For å installere programmet trenger du en Android-telefon med versjon 2.1 eller nyere. Du må laste ned applikasjonen og godta tilgangen applikasjonen skal ha på telefonen din. Applikasjonen ligger ikke ute på Android Market, så du er nødt til å krysse av for å godkjenne usignert programvare. Om du vil installere programmet fra nettet: Gå til fra mobiltelefonen Godta installasjonen Husk å krysse av for installasjon av usignert programvare. Om du skal installere programmet fra PC: Last ned Astro File Manager til din Android telefon fra Android Market. Installer Astro File Manager. Koble din Android telefon til maskinen din. Velg Diskstasjon. Monter som diskstasjon. Last ned NoarkMobil.apk fra PC-en til mobilen. Finn fila gjennom Astro File Manager og trykk på den. Du vil da få spørsmål om du vil installere. Husk å krysse av for usignert programvare Skrivebordsapplikasjon Installasjon av skrivebordsapplikasjonen krever per dags dato modifisering av programvarekoden. For å se hvordan dette gjøres se produktdokumentasjonen kapittel Side 121 av 135

129 Brukerveiledning Marc Kapittel 25: Brukerveiledning 25 Brukerveiledning Dette kapittelet tar for seg brukerveiledningen til mobil og skrivebordsapplikasjonen Mobilapplikasjon Manual Velkomstskjermen er det første brukeren møter(figur 25.1). Figur 25.1: Velkomstskjerm Etter velkomstskjermen vil det dukke opp et skjermbilde lik Figur Du får her videre informasjon om hva du må gjøre. Velg Hent kontakter for å få opp alle kontaktene du har sendt melding med. Trykk på Hent kontakter og du kommer til neste skjermbilde. Figur 25.2: Startbilde Side 122 av 135

130 Kapittel 25: Brukerveiledning Noark 5 Dokumentfangst Etter å ha trykket på Hent Kontakter kommer det et skjermbilde opp som er lik Figur Her kan du velge mellom alle de du har sendt meldinger med. Med navn om de er i kontaktlista, med nummer om de ikke er. Trykk på kontakter du vil lagre. Figur 25.3: Valg av kontakter Kontaktene er nå valgt som i Figur Trykk igjen for å fjerne valget. Når du er fornøyd trykk Lagre. Figur 25.4: Lagring Om alt går som det skal vil du få samme skjermbilde som Figur Trykk OK og du finner meldingene dine på minnekortet ditt, under en mappe som heter Meldinger i en fil som heter melding.xml. Du er nå ferdig med mobildelen, og må gå over til skrivebordsapplikasjonen for å fortsette. Figur 25.5: Skjermbilde av vellykket lagring Side 123 av 135

131 Brukerveiledning Marc Kapittel 25: Brukerveiledning Referanser Hent kontakter Har som formål å hente ut kontakter fra telefonen. Om knappen trykkes, vil alle kontakter personen har sendt meldinger med vises i en liste. Feilmeldinger: Ingen Meldinger: Ingen Denne knappen skal kun trenges å trykkes én gang per kjøring Avhukingsboks Har som formål å huke av kontakt (velge) Ved avhuking vil kontakten som boksen tilhører bli lagret når Lagre-knappen trykkes. Feilmeldinger: Ingen Meldinger: Ingen Denne knappen kan hukes av/på uten at det har noen virkning på programmet. Programmet vil kun sjekke verdien til avhukingsboksen når Lagre-knappen blir trykket. Lagre Har som formål å lagre valgte kontakters meldinger. Om knappen trykkes vil alle meldingene til valgte kontakter bli lagret. Feilmeldinger: Meldingene er ikke lagret o External Storage not available - Denne feilmeldingen kommer når SD-kortet ikke er tilgjengelig. Sjekk at telefonen har SD-kort. Om telefonen er koblet til PC-en i diskmodus er ikke SDkort tilgjengelig. o Det skjedde en feil under lagring - Applikasjonen kunne ikke lagre. Meldinger: Meldingene er lagret o Programmet avsluttet normalt og meldingene er lagret på SD-kortet. Hver gang knappen trykkes vil valgte kontakters meldinger lagres. Tidligere valgte kontakters meldinger vil slettes fra applikasjonens XML-fil Skrivebordsapplikasjon Hvis du nå har brukt mobilapplikasjonen for å velge kontakter du ønsker å sende meldinger fra, kan du fortsette med å åpne Marc på din datamaskin. Når programmet har blitt åpnet ser du skjermbildet illustrert i Figur Side 124 av 135

132 Kapittel 25: Brukerveiledning Noark 5 Dokumentfangst Figur 25.6: Startskjermen i Marc Sørg for at mobilen er tilsluttet datamaskinen via USB, og at tilkoblingsmodusen er diskstasjon (monter som diskstasjon). Du kan nå fortsette med å velge Hent fra telefon i verktøylinjen. Du vil da få opp en dialogboks som spør deg hvilken enhet (se Figur 25.7). Figur 25.7: Velg enhet - dialogboks Merk at navnet på din Android-telefon ikke vil vises, du må derfor sørge for at du velger riktig diskbokstav ved å dobbeltsjekke i Windows Explorer eller tilsvarende. Trykk OK når dette er gjort. Side 125 av 135

133 Brukerveiledning Marc Kapittel 25: Brukerveiledning Figur 25.8: Liste over kontakter Figur 25.9: Meldinger assosiert med valgt kontakt Du må nå tillate programmet å jobbe seg gjennom meldingene. Programmet er ferdig når du får opp en liste på venstresiden av hovedvinduet som illustrert i Figur Du kan nå velge en kontakt i listen, for å få opp meldingene assosiert med denne kontakten. Du vil da få noe lignende som skjermbildet i Figur Her kan du nå velge flere meldinger som du ønsker å sende inn til Noark. Klikk på dem en gang for å legge til i listen som skal sendes inn, klikk igjen for å fjerne. Figur 25.10: Valg av meldinger Side 126 av 135

134 Kapittel 25: Brukerveiledning Noark 5 Dokumentfangst Du kan veksle fritt mellom kontakter, og legge og fjerne meldinger som du vil. Når du er ferdig, trykker du Send til Noark knappen i verktøylinjen (se Figur 25.11). Figur 25.11: Send til Noark Side 127 av 135