Sluttrapport Magne Rodem og Jan-Erik Strøm 18. juni 2006
1 Forord Dette er en sluttrapport som er utviklet i forbindelse med prosjektet J2ME-applikasjon for nettsentrisk adressebok, som har pågått fra januar 2006 til mai 2006. Prosjektet har blitt gjennomført av Magne Rodem og Jan-Erik Strøm som avsluttende hovedprosjekt ved Høgskolen i Sør-Trøndelag, linje for ingeniørutdanning. Prosjektet inngår i faget BO805D Hovedprosjekt. Fagets hjemmeside oppgir følgende læremål: Studentene skal: [1] lære å planlegge tid og arbeidsmengde. integrere kunnskap fra flere fag. lære å skrive en teknisk rapport. lære å dokumentere et mindre programsystem, eventuelt et nettverk e.l. lære å teste et mindre system. lære å presentere en problemstilling for et publikum. lære å ha vanskelige oppdragsgivere. kunne drøfte og bli enig med andre om standarder, grensesnitt og strukturer. Når vi nå ser tilbake på prosjektperioden, kan vi fastslå at alle disse målene har blitt nådd. Prosjektet har vært utfordrende, lærerikt og spennende. Det har hovedsaklig gitt oss mer innsikt i utvikling for mobile enheter, hvor minnekapasiteten er lav, og ressursbruk bør holdes til et minumum. I tillegg har vi fått erfaring på nye områder som Web Services, SOAP og XML. Vi har fått bruk for kunnskap fra tidligere fag, samtidig som det har vært nødvendig å bruke tid på egenopplæring for å tilegne seg kunnskap om nye og ukjente områder. Vi har gjennom arbeid med prosjektdokumentasjonen fått erfaring med å skrive tekniske rapporter, da spesielt med tanke på å kunne forklare de valgene vi tok underveis og dokumentere hvordan systemet fungerer. Vi håper det vi har utviklet og dokumentert i dette prosjektet vil være av verdi både for oppdragsgiver og eventuelt andre interresserte. Magne og Jan-Erik 31.mai 2006 2
Innhold 1 Forord 2 2 Oppgavebeskrivelse 4 3 Hvordan ble oppgaven løst? 5 3.1 Utviklingsmodell.................................... 5 3.2 Programvare og verktøy................................. 5 4 Gjennomføring av prosjektet 6 4.1 Prosess......................................... 6 4.2 Mål og krav....................................... 6 4.3 Statusrapporter og timelister.............................. 7 5 Videre arbeid 9 5.1 Hva er gjort?...................................... 9 5.2 Hva gjenstår?...................................... 9 6 Referanser 10 7 Revisjonshistorie 10 3
2 Oppgavebeskrivelse Telenor Mobil tilbyr i dag tjenesten ProffNet til sine bedriftskunder. Denne tjenesten fungerer som en hussentral på mobilen som blant annet gir brukerne økt fleksibilitet og mulighet til å styre egen tilgjengelighet. Brukerne kan selv stille inn hvordan innkommende anrop skal behandles når de er opptatt eller ikke tilgjengelig. Dette kan gjøres via Internett, WAP eller på mobiltelefonen. En administrator kan ved hjelp av et en web-basert løsning melde medlemmer inn og ut av bedriftens ProffNett, og hver enkelt bruker kan administrere sitt eget abonnement ved å benytte Telenor Mobils webside. Hver bruker i ProffNett får sitt eget internnummer (3-7 siffer), og brukerne har da en nettsentrisk adressebok for oppslag. Denne ønsker man at brukeren skal kunne aksessere direkte fra telefonen. En bruker skal kunne slå opp i adresseboka for å hente ned kontakter som brukeren deretter kan ringe til. Det vil i denne sammenheng også være nyttig for en bruker å kunne lagre kontakten i sin lokale adressebok. ProffNett har allerede en nettsentrisk adressebok som er tilgjengelig via et web-basert grensesnitt. Da brukerne av ProffNett ikke alltid har tilgang til PC med Internettoppkobling, vil det være hensiktsmessig å kunne aksessere adresseboken fra telefonen via en J2ME-applikasjon. De fleste av dagens mobiltelefoner har støtte for GPRS eller 3G, som blant annet gir økt overføringshastighet og en kontinuerlig oppkobling mot datanettverket. Dette har den fordelen at brukeren slipper å ringe opp for hver gang han ønsker å aksessere Internett. Dermed kan en J2ME-applikasjon raskt og enkelt koble seg opp mot en adressebok som gjøres tilgjengelig på Internett. 4
3 Hvordan ble oppgaven løst? 3.1 Utviklingsmodell Siden prosjektgruppen består av to personer som har jobbet sammen på tidligere prosjektet, ble utviklingsmodell valgt på bakgrunn av tidligere erfaringer. Vi er begge tilhengere av iterativ og inkrementell utvikling, og ønsket å ta i bruk denne metodikken i dette prosjektet også. Det betydde at vi jobbet med de ulike kravene i inkrementer. Først fant vi fram til dem, så ble de utdypet, designet og implementert. I motsetning til fossefallsmetoden, hvor man jobber med noe bestemet i bestemte perioder for så å legge dette bak seg og begynne med noe nytt, lar iterativmetoden oss være fleksible når det gjelder endringer av krav. Dette fanges opp av selve itereringen. Når det gjelder de ulike dokumentene som skulle skrives underveis, kom vi fram til at det var mest hensiktsmessig å følge skolens maler, selv om det betydde at vi følgte en slags fossefallsteknikk hvor det ene dokumentet følger det andre. Likevel har disse dokumentene blitt gått gjennom og revidert i ulike iterasjoner etter hvert som kravene har endret seg, da særlig mot slutten av prosjektperioden. 3.2 Programvare og verktøy Vi har benyttet tekstmanipuleringsspråket/typesettingspråket LaTeX for å skrive de ulike dokumentene. Fordelen med dette var at vi slapp å tenke på formateringen og kunne konsentrere oss om innholdet i stedet. I tillegg inneholder LaTeX en del funksjoner som gjør det lettere å skrive tekniske rapporter, for eksempel utlisting av kildekode, visning av figurer og fleksibel tabellutforming. Konfigurasjonsstyringsverktøyet CVS ble benyttet fra første dag. All dokumentasjon og kildekode som ble utviklet underveis ble lagt under versjonskontroll slik at vi begge hadde tilgang til materialet til enhver tid. I tillegg opprettet vi en web-side som inneholdt all prosjektdokumentasjon. Denne websiden synkroniserte seg mot CVS-området vårt for å alltid inneholde siste versjon av dokumentene. I tillegg har vi brukt modelleringsverktøyene Poseidon og Microsoft Visio. Programmeringen ble gjort i utviklingsverktøyet NetBeans 5.0. Dette verktøyet har integret støttet for J2EE og J2ME, noe som gjorde utviklingen lettere for oss, da vi kunne konsentrere oss om selve oppgaven, og ikke styre med å sette opp alle parametre og konfigurasjonsinstillinger for de ulike modulene gjennom kommandolinjen. I tillegg har NetBeans en rik og kraftig kodeeditor, som er med på å minimere syntaksfeil gjennom syntax highlighting, code completion og integrert javadoc for API-klasser. Det følger også med en debugger som ble flittig brukt til å fange opp logiske feil, i tillegg til god CVS-støtte. 5
4 Gjennomføring av prosjektet 4.1 Prosess Da vi satte i gang med prosjektet i januar var mye uklart. Vi hadde et vagt bilde av hva vi skulle utvikle, men var usikre på detaljene rundt systemet. I januar og februar var det meningen at vi skulle ha prosjektet på deltid, da vi hadde mange andre fag og også et annet prosjekt å ta hensyn til. Derfor ble det ikke så mye jobbing de to første månedene. Vi fikk imidlertid laget en forstudierapport hvor vi fikk satt oss ned og tegne noen rammer og mål for prosjektet. Det ble i denne perioden mest egenopplæring og administrativ jobbing, som f.eks. oppsett av CVS-område og hjemmeside for prosjektet. Vi jobbet i AITeLs lokaler under hele prosjektperioden. Her hadde vi et prosjektrom som vi delte med en annen gruppe som også jobbet med hovedprosjekt. Dette fungerte smertefritt. Etter en heftig eksamensperiode i begynnelsen av mars var de fleste andre fag og prosjekter unnagjort, og vi kunne konsentrere oss mer om hovedprosjektet. Etter et møte med oppdragsgiver fikk vi mer informasjon angående det vi skulle utvikle, og svar på ting vi lurte på. Dette førte etterhvert til av vi utarbeidet en kravspesifikasjon hvor vi fant framt til, og beskrev, de krav som gjaldt for prosjektet. Vi innså at det også måtte en del egenopplæring til, da det var behov for å ta i bruk en del teknologier og standarder som vi var lite kjent med. Deretter gikk arbeidet stort sett i å kombinere koding med design og dokumentasjon, samtidig som vi passet på å være fleksible og åpne med tanke på at endringer kunne skje underveis. Dette fikk vi erfare da vi programmerte oss inn i et hjørne med J2ME-applikasjon. Måten vi tegnet opp brukergrensesnitt på var lite effektivt, og det var vanskelig å legge til nye funksjoner til applikasjonen uten å brekke eksisterende funksjonalitet. Dette førte til at vi begynte fra nytt av med en litt annen angrepsvinkel. Gjennom å gjenbruke mye av det allerede eksisterende MIDP-API et ble resultatet et mye mer fleksibelt system, spesielt når det gjaldt feilhåndtering og utvidelse av funksjonalitet. Etter å ha utviklet en prototyp, inviterte vi oppdragsgiver nedover for å se på det vi hadde jobbet med. Vi fikk god respons og gode forslag til utvidelser og nye funksjoner. 4.2 Mål og krav I forstudierapporten ble vi enige med oppdragsgiver om følgende mål for prosjektet: Effektmål Oppdragsgiver ønsker å se en J2ME-applikasjon med et godt og brukervennlig brukergrensesnitt som vil fungere som en prototype og dermed demonstrerer hvilke muligheter en slik applikasjon har med tanke på å tilfredsstille bedriftskunder som ønsker mer avanserte telefonløsninger. Resultatmål Det skal utvikles en applikasjon for mobiltelefoner som ved å koble seg opp mot en nettsentrisk adressebok skal kunne hente ned kontakter som er registrert i bedriftens register over ansatte. Applikasjonen skal fungere på et utvalg av mobiltelefoner. Vi mener at den applikasjonen som vi har utviklet er brukervennlig og tilbyr et fint brukegrensenitt som fungerer etter sin hensikt. Et av de viktigste områdene vi jobbet med for å imøtekomme effektmålet 6
var å gjøre kontaktene mest mulig tilgjengelige for brukeren slik at det krevdes minimum innsats fra han for å finne det han var ute etter. Gjennom søkefunksjonen og navigasjonen synes vi at vi har løst dette på en god måte. Applikasjonen tilbyr funksjonalitet som tilfredstiller de behov eventuelle kunder måtte ha. Vi har nevnt i resultatmålet at applikasjonen skal fungere på et utvalg av mobiltelefoner. Dette stemmer forsåvidt, da vi ikke har hatt mulighet til å teste applikasjonen på andre telefoner enn våre egne. Applikasjonen er derimot skrevet slik at den skal fungere på alle telefoner som støtter MIDP 2.0. I tillegg tas det i bruk alternative pakker fra J2ME, blant annet PIM, for å aksessere den lokale adresseboken i telefonen. For eksempl, selv om telefonen støtter MIDP 2.0, behøver den ikke å støtte PIM. Dette har vi tatt i betraktning, og brukeren vil få melding hvis hans telefon mangler støtte for enkelte funksjoner. Det største problemet i forbindelse med støtte av ulike telefoner har vært ulik implementasjon av de såkalte soft buttons på telefonen. Dette er taster som typisk brukes for å navigere gjennom skjermbilder. I MIDP er hver knapp på telefonen knyttet mot en spesiell verdi, men denne verdien kan variere fra modell til modell. Som nevnt tidligere har vi bare hatt mulighet til å teste på våre egne telefoner, og vet lite hvilke verdier andre telefoner bruker. Vi har imidlertid lagt inn en tilbakefallsmetode som gjør at brukeren kan bruke tastene 1 og 3 for å simulere henholdsvis venstre og høyre soft button. Ellers mener vi at vi har oppfylt de krav som er spesifisert i kravdokumentet med tanke på brukbarhet, ytelse og pålitelighet. Applikasjonen er lett å bruke og er ikke til hinder for vanlig bruk. Dataoverføringen tar som regel ikke altfor lang tid og feilmeldinger inneholder beskrivende tekst uten noen form for teknisk språk. Applikasjonens størrelse holder seg under grensen på 100kB som vi hadde satt. Når det gjelder ytelsen ved dataoverføring, satte vi som krav at det ikke skulle ta mer enn fem sekunder å hente ned en kontakt, og at det ideelt sett ikke burde ta mer enn et sekund. Resultatet slik det er nå er at tiden varierer veldig, alt fra tre sekunder til ti sekunder. Det vi fant ut var at dette gjelder uansett hvor stor datamende som overføres. For eksempel testet vi med først å hente ned kun én kontakt, og deretter 20. Tiden det tok å overføre var tilnærmet lik begge gangene. Dette viser at det er selve oppkoblingen som er flaskehalsen her. Forskjellen mellom å overføre få og mange kontakter er derimot ikke så stor. 4.3 Statusrapporter og timelister Vi har loggført 429.5 timer hver i dette prosjektet. Fullstendige timelister med statusrapporter for hver uke foreligger som vedlegg til innleveringen. Den er også å finne på den medlagte CD en. Under vises en oversikt over totalt antall timer per arbeidsart, og en graf som viser arbeidsfordelingen utover prosjektperioden. 7
Arbeidets art Timer Magne Timer Jan-Erik Totalt Egen opplæring 40 50 90 Utarbeidelse/revisjon av av framdriftsplan 5 1 6 Administrasjon av eget arbeid 20 9 29 Kravspesifikasjon 24 16 40 Konstruksjon/design av programvare 13 65 78 Prototyping 102.5 87 189.5 Implementasjon 97 42 139 Feilretting av program 23 43 66 Utarbeidelse av systemdokumentasjon 67 90 157 Presentasjoner med forberedelse 8 8 16 Møte med veileder hos oppdragsgiver 8.5 7.5 16 Møte med veileder hos avdelingen 5.5 6 11.5 Utarbeidelse av forstudierapport 5 5 10 Totalt 429.5 429.5 859 Figur 1: Fordeling av timer over prosjektperioden. 8
5 Videre arbeid 5.1 Hva er gjort? Det er utviklet en J2ME-applikasjon som kommuniserer med en Web Service for å aksessere et kontaktregister for å fungere som en adressebok. Fra applikasjonen kan brukeren søke etter kontakter på fornavn eller etternavn, eller bla i kontakter. Når han har funnet fram til ønsket kontakt, kan han videre velge å ringe eller sende tekstmelding til vedkommende. Han kan også velge å lagre kontakte på sin telefon, eller dele kontakten med andre. Applikasjonen bruker et selvutviklet UI-bibliotek som tilbyr et enkelt og brukervennlig brukergrensesnitt. 5.2 Hva gjenstår? Det er en hel rekke funksjoner som vi har hatt lyst til å se bli implementert i systemet: Opplasting av kontakter I enkelte tilfeller vil det være fordelaktig for brukerne å kunne laste opp kontakter til tjeneren direkte fra deres egen lokale adressebok. Dette skal kunne la seg gjøre ved å hente en kontakt inn i applikasjonen ved hjelp av PIM, for deretter å sende denne inn til tjeneren for lagring. Velge flere kontakter og lagre disse i telefonens adressebok Applikasjonen støtter nå kun lagring av én kontakt i gangen. Ved å modifisere applikasjonens liste-komponent, vil man kunne gi støtte for å velge flere kontakter og lagre disse samtidig. Synkronisering Vi kan se for oss at brukerne ønsker å ha sin lokale adressebok synkronisert opp mot den nettsentriske adresseboken. Denne funksjonen vil kunne benytte de to ovenstående funksjonene. Bedre feilmeldinger fra tjeneren Dersom noe går galt internt på tjenersiden, vil tjeneren kun returnere null tilbake til klientene. Klientene vil dermed ikke få beskjed om hva som er galt. Administrator må sjekke tjenerens logg for å finne ut hva problemet er. Bedre avbryt-funksjon Vi har erfart at telefonene låser seg dersom vi forsøker å stanse en tråd som mottar data fra nettverket. Av den grunn har vi valgt å ikke stoppe nettverkstråden dersom brukeren klikker Avbryt mens dataoverføring pågår. Tråden får altså kjøre ferdig, men vi lar være å vise nedlastede data på skjermen. Man bør her ta sikte på å finne en metode som stanser dataoverføringen dersom brukeren klikker Avbryt. 9
6 Referanser [1] AITeL HIST, Hjemmeside for faget BO805D Hovedprosjekt http://aitel.hist.no/fag/hpr/ 7 Revisjonshistorie Dato Versjon Beskrivelse 22.05.2006 1.0 Første utgave 30.05.2006 1.1 Gjort klart dokumentet til innlevering 10