NILS Mobil. Prosjektdokumentasjon S 1

Transkript

1 Prosjektdokumentasjon S 1

2 PROSJEKT NR Studieprogram: Dataingeinør/Informasjonsteknologi Telefon: Telefaks: TILGJENGELIGHET ÅPEN Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKTETS TITTEL NILS Mobil PROSJEKTDELTAKERE HOVEDPROSJEKT Rune Sandersen (s156153) Khai Quang Nguyen (s156188) DATO : ANTALL SIDER / BILAG 81 INTERN VEILEDER Geir Skjevling Hafsteinn Thor Ingason (s148167) OPPDRAGSGIVER Goodtech ASA ( ) KONTAKTPERSON Harald Pedersen(Manager Industrial IT) Øystein Myhre (Utvikler) SAMMENDRAG Goodtech har sammen med Nasjonalmuseet utviklet et logistikk og prosesssystem, Nasjonalmuseets Interne Logistikk System, for å holde kontroll med hvor gjenstander befinner seg, hvilken prosess de til enhver tid er i og hvilke hendelser de har vært med på. Oppgaven vår har vært å utvikle en løsning hvor det benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte løsning. Vi har gjort dette ved å utvikle en Web Applikasjon designet for mobiltelefoner som jobber parallelt med det nåværende NILS systemet. 3 STIKKORD Web-applikasjon Spring MVC JAVA Prosjektdokumentasjon S 2

3 1 Innhold Tittel side Innhold Prosessdokumentasjon Forord Gruppen Oppdragsgiver Om Goodtech Om nasjonalmuseet Hoveddel Bakgrunn for oppgaven Mål Rammebetingelser: Krav til oppgaven User stories Design og brukervennlighet Kode og vedlikehold Planlegging og metode Ukjente verktøy: Planleggingsverktøy og metodikk Scrum Fremdriftsplan Ansvarskart Utviklingsprosessen Startfasen Prosjekthjemmeside Drøfting av alternativer Prosjektdokumentasjon S 3

4 2.7 Diskusjon rundt vår avgjørelse Tilgjengelighet Grensesnitt Brukervennelighet Responsitivitet Oversikt over fordeler og ulemper Konklusjon Utviklingsløp Sprinter Testing Hva kunne vært gjort bedre? Siste ord Produktdokumentasjon Forord Gruppen Oppdragsgiver Om Goodtech Om nasjonalmuseet Bakgrunn for oppgaven Mål Mål for oppgaven Mål for gruppen Rammebetingelser: Krav til oppgaven Design og brukervennlighet Kode og vedlikehold Beskrivelse av programmet Figur 1: Brukergrensesnitt for Nils Mobil Prosjektdokumentasjon S 4

5 3.4.2 Om NILS Mobil Krav for installasjon og drift av programmet Server Sentrale datastrukturer i programmet NILS Servlet JSP: JSON Spring Rammeverket MVC Spring MVC Programmets virkemåte Plassere Søke Sekvensdiagram Oppbygning av NILS Mobil Presentasjonslaget (view) JSP Stilark Javascript/Jquery Filstruktur i presentasjonslaget Controllerlaget Filstruktur i Controller laget Model laget Filstruktur i Model Laget Testing av programmet Endelig resultat av funksjonalitetstest på forskjellige nettlesere Kommentar på testresultatet Prosjektdokumentasjon S 5

6 3.10 Kravspesifikasjonen og det endelige produktet Tilbakemelding fra kunde Utvidelsesmuligheter Vedlegg Bruksanvisning Utstyr og tilkoblinger Hvordan koble til strekkodeleser Hvordan Bruke Nils-Mobil Søke Hjelp Forprosjekt Prosjektskisse Kravspesifikasjon Dagbok Minnepenn Kilder Bøker Internett Prosjektdokumentasjon S 6

7 Prosjektdokumentasjon S 7

8 2 Prosessdokumentasjon 2.1 Forord Dette er prosessdokumentasjonen for hovedprosjektet NILS Mobil ved Høgskolen i Oslo våren Dokumentet legger fram bakgrunnen for produktet vi har laget og forteller hvilke forhold vi har arbeidet under, arbeidsmåter vi har valgt, rammebetingelser, utført arbeid, verktøy vi har tatt i bruk, og utfordringer ved arbeidet. Dokumentet er beregnet for sensorer, våre veiledere og andre personer som kan ha interesse av å lese om arbeidet vi har lagt ned i hovedprosjektet. For utfyllende informasjon om produktet samt testing og bruk av produktet henviser vi til produkt, test- og brukerdokumentasjonen som er etterfølgende selvstendige dokumenter Gruppen Gruppen bestod av Rune Sandersen, Khai Quang Nguyen og Thor Ingasson Haffsteinn. Medlemmene kjente hverandre fra tidligere prosjektarbeid og valgte å danne gruppen på grunnlag av god kommunikasjon og bra erfaring fra tidligere arbeid. Vi ønsket et hovedprosjekt hvor vi kunne ta i bruk vår kunnskap og samtidig lære noe nytt. Etter å ha sett gjennom prosjektforslagene på HiO sine sider var vi mest interessert i prosjektet Nils Mobil fra Goodtech, da det virket spennende og passet med ønskene våres, i tillegg ville det gi oss erfaring i hvordan det er å jobbe i arbeidslivet. Vi sendte en e-post angående vår interesse og fikk avtalt et møte. På møtet diskuterte vi forskjellige temaer inkludert tidligere erfaringer og kunnskapsnivå. Vi ble tilbudt oppgaven senere på dagen og takket ja. Oppgaven gikk ut på å utvikle en løsning hvor det skulle benyttes mobile enheter for registrering og kontroll over gjenstander i et logistikk system, som et alternativ til Goodtech sin PC-baserte løsning Oppdragsgiver Kunden er Nasjonalmuseet. Goodtech er vår oppdragsgiver og vil vedlikeholde og videreutvikle systemet etter levering Om Goodtech Goodtech ASA er et norsk teknologi og ingeniørkonsern som er notert på Oslo Børs. Selskapet leverer løsninger til industri og offentlig forvaltning, miljøprosjekter innenfor vann, avløp og energigjenvinning, samt tilhørende produkter og produktteknologier. Selskapet er representert med kontorer i flere geografiske regioner i Norden og Tyskland. Konsernet representerer flere internasjonale produsenter og deres produkter i det nordiske Prosjektdokumentasjon S 8

9 markedet. Goodtech har over 1000 ansatte hvor hovedtyngden av de ansatte er ingeniører og tekniske spesialister. Goodtech stilte med en veileder og to kontaktpersoner til prosjektet: Harald Pedersen var vår kontaktperson Øystein Myhre var kontaktperson og veileder Om nasjonalmuseet Nasjonalmuseet samler og bevarer, stiller ut og formidler landets mest omfattende samlinger av kunst, arkitektur og design. Museet viser faste utstillinger med verk fra egen samling og skiftende utstillinger med innlånte og egne verk. Museets visningssteder i Oslo er Nasjonalgalleriet, Museet for samtidskunst, Nasjonalmuseet Arkitektur og Kunstindustrimuseet. Utstillingsprogrammet omfatter også vandreutstillinger i inn- og utland. 2.2 Hoveddel Bakgrunn for oppgaven Goodtech har fra før laget en løsning for Nasjonalmuseet, NILS (Nasjonalmuseets Interne Logistikk System) for å holde kontroll med hvor gjenstander er, hvilken prosess de er i, og hvilke hendelser de har vært med på. Hovedhensikten med NILS er at det skal holde rede på hvor gjenstander er til enhver tid, dette gir Nasjonalmuseet oversikt over logistikkflyt og lokasjon for sine gjenstander. Systemet er hendelsesbasert og bygd opp rundt problemstillinger som «Hva har skjedd med hvilke gjenstander og når?». NILS ble opprinnelig brukt for store flyttinger og er skreddersydd for masse-registrering i denne typen prosjekter. I senere tid har det dukket opp nye behov for kontroll over mindre flyttinger, og det er et ønske om et system som gjør dette arbeidet lettere, ved bruken av mobile enheter istedenfor PC-er Mål Mål for oppgaven Målet for oppgaven var å lage et mobilt logistikk og prosess-system for registrering og kontroll over hvor gjenstander befinner seg. Systemet kommer til å jobbe side om side med det eksisterende NILS systemet, og vil gi logistikkstyring via mobile enheter som et alternativ til dagens PC-Baserte løsning Mål for gruppen Lære oss nye teknologier, metodikker og språk. Lære oss hvordan en systemutviklingsprosess fungerer i et større prosjekt enn de vi tidligere Prosjektdokumentasjon S 9

10 har hatt på HiO. Få erfaring i hvordan det er å arbeide for en reel oppdragsgiver Rammebetingelser: Applikasjonen skal lages i Java NILS har i dag et Java-basert klient-api som fortrinnsvis skal benyttes, men om dette ikke er hensiktsmessig, kan man kommunisere over HTTP med kjernesystemet. Strekkoder benyttes som informasjonsbærer. Vi ønsker at man benytter seg av åpne standarder og åpen kildekode i størst mulig grad Goodtech s infrastruktur for systemutvikling skal benyttes. Sentrale verktøy er: Scrum, Maven, Subversion, Hudson og Artifactory Aktuelle platformer: Android, J2ME og Windows Mobile. Om mulighetene åpner seg for Java på ios (iphone/ipad), vil dette også være en aktuell plattform 2.3 Krav til oppgaven User stories Brukere skal kunne: Lese strekkoder Skanne gjenstander inn på lokasjon Se hvor en gjenstand befant seg sist Søke opp gjenstander Se logistikk historikk om gjenstander som skannes eller søkes opp Plassere gjenstand på lokasjon uten bruk av strekkodeleser Søke etter gjenstander uten bruk av strekkodeleser Design og brukervennlighet Systemet skal være selvforklarende så langt det er mulig, forutsatt at brukerne har kjennskap til de begrepene som blir brukt. Designet av webapplikasjonen skal være optimalisert for smarttelefoner. Prosjektdokumentasjon S 10

11 2.3.3 Kode og vedlikehold Subversion vil bli brukt for versjonskontroll. Maven brukes for bygging av prosjekter. Vi bruker UTF8 som tegnsett. Gruppen vil bruke Spring Rammeverket for utvikling av applikasjonen. Gruppen vil benytte seg av eksisterende NILS API. 2.4 Planlegging og metode I denne delen tar vi for oss hvilke verktøy og teknologier vi brukte og hvilken utviklingsmetodikk vi benyttet oss av. Vi går også inn på hvordan planleggingen i utviklingsprosessen fungerte og hvordan vi arbeidet, vi forklarer verktøyene vi brukte i detalj da de hadde stor innvirkning på arbeidsprosessen og det ferdige produktet Ukjente verktøy: NILS NILS er basert på en industrialisert standard for logistikk og prosesstyring, NILS består av en database, som lagrer hva som skjer med hvilke gjenstander, et serverprogram med et Java- API, og en klient som kjører lokalt på brukerens maskin. Klienten og tjeneren er skrevet i Java. Rammeverket brukt i NILS er Spring. Løsningen benytter seg av strekkoder, der alle relevante gjenstander har en strekkode forbundet med seg. Ved å registrere lokasjonen til gjenstander med strekkoder får man oversikt over hvor gjenstander er nå, og hvor de har vært tidligere Servlets og JSP: JavaServerPages(JSP) er en Java teknologi som hjelper utviklere å levere dynamisk genererte websider basert på HTML,XML eller andre dokumenttyper. Det er Sun sitt svar på ASP og PHP. JSP syntaks er en miks av to grunnleggende typer, scriptlet elementer og markeringsspråk. Markeringsspråk er vanligvis standard HTML eller XML, mens scriptlet elementer er blokker med Java kode som kan mikses inn mellom markeringsspråket. Når siden blir etterspurt blir Java koden kjørt og dens output blir lagt til siden, det omringende markeringsspråket gir det ferdige resultatet Spring Rammeverket Rammeverket er utviklet av Rod Johnson og ble for første gang sluppet i juni Spring er ett åpen kildekode rammeverk laget for å adressere kompleksiteten i utvikling av Enterprise applikasjoner. Prosjektdokumentasjon S 11

12 Sentralt til Spring rammeverket er Inversion of Control containeren, containeren er ansvarlig for livssyklusen til objekter, opprettelsen av objekter, kall på initialiseringsmetoder, og konfigureringen av objekter ved å binde de sammen Dependency Injection: Spring støtter løs kobling gjennom en teknikk kjent som dependency injection(di). Når DI er tatt i bruk får objekter sine avhengigheter passivt, istedenfor å lage eller å lete opp avhengigheter Container: Spring er en container på den måten at den inneholder og håndterer livssyklusen og konfigurasjonen av objekter. I Spring kan man deklarere hvordan objekter skal opprettes, hvordan de skal bli konfigurert, og hvordan de forbinder seg med hverandre Servlet: En servlet er en Java klasse som kjører i en server applikasjon for å svare på forespørsler til klienten, de brukes vanligvis med HTTP. Typisk bruk av servlets er blant annet prosessering av data sendt inn via en Form fra presentasjonslaget og retur av forespørslene til klienten MVC MVC er en måte å dele opp en applikasjon på. Hver del skal være uavhengig av de andre, MVC står for Model View Controller Model Model utfører forretningslogikk. Forretningslogikk refererer til det som er fundamentalt for systemdesignet. For eksempel hvis en biblioteksapplikasjon var laget, ville logikken som forsikret at bibliotekskort eieren bare kunne låne opptil 5 bøker på en gang ligget i en del av Modellen View View laget er for presentasjonen av applikasjonen, i NILS Mobil består view laget av en samling JSP sider, view laget skal inneholde så lite logikk som mulig for programmeringsspråket som blir brukt Controller En controller håndterer forespørsler fra brukeren og logikk spesifikt til applikasjonen. En controllers jobb er å motta forespørsler fra en bruker via presentasjonslaget, prosessere forespørselen, kommunisere med modellen hvis nødvendig, og så sende resultatet til brukeren. Prosjektdokumentasjon S 12

13 Typisk MVC arkitektur Spring MVC Spring MVC inkluderer de fleste grunnleggende konsepter som andre MVC rammeverk. Forespørsler kommer inn via Front Controlleren, som ikke gjør noe web eller forretningslogikk, men heller delegerer til vanlige Java objekter kalt Controllers, hvor det ordentlige arbeidet blir gjort, enten ved at alt gjøres i controlleren eller med bruk av hjelpeklasser. Når arbeidet er gjort er ansvaret til Presentasjonslaget å presentere output I et rett format Front Controller En Front controller er en servlet som sender forespørsler videre til individuelle controllere, alle forespørsler til applikasjonen er kontrollert av front controlleren som igjen sender forespørsler videre til individuelle Controllere. Navnet på Spring MVC sin Front Controller er DispatcherServlet Individuelle Controllere kan bli brukt for å håndtere mange forskjellige URL er og hendelser. En standard controller i Spring er en vanlig Java klasse, hvilken Controller klasse, og hvilken metode som håndterer forespørsler i denne klassen blir bestemt av Spring sin DispatcherServlet. Forespørselhåndtering kan bli satt eksplisitt i Spring-Servlet.xml filen(applicationcontext filen), eller ved bruk av annoteringer i controller klasser hvis Spring er konfigurert for dette. Prosjektdokumentasjon S 13

14 Typisk Spring MVC hendelsesforløp Klienten spør etter en ressurs i webapplikasjonen ved å gjøre en handling i presentasjonslaget. Spring Front Controlleren oppdager etterspørselen og vil prøve å finne passende Handler Mapping. Handler Mapping er brukt til å mappe en forespørsel fra Klienten til en bestemt Controller. Front controlleren ser over de forskjellige controllerne definert i Application Context filen(spring-servlet.xml) eller via Med hjelp av Handler Adapters vil Dispatcher Servleten delegere etterspørselen til rett Controller. Controlleren behandler klientens etterspørsel og returner ett View med det som ble etterspurt av brukeren, vanligvis i form av et ModelAndView objekt. MAV objektet sendes tilbake til Front Controlleren, det valgte viewet blir vist til klienten Spring MVC arkitektur Prosjektdokumentasjon S 14

15 jquery Javascript bibliotek, en samling av javascript koder som vi har tatt i bruk, jquery ble laget med tanke på blant annet event handling, animering, og Ajax interaksjon for dynamiske websider AJAX Asynkront Javascript som gjør at siden delvis oppdateres og gir en mer interaktiv brukeropplevelse JSON JavaScript Object Notation(JSON) er en enkel måte å håndtere data på. JSON er svært godt egnet til bruk i AJAX-applikasjoner Subversion og Subclipse Ett versjonskontrollsystem som brukes til å holde rede på utviklingshistorien til en samling med filer og kataloger. Subclipse er en plug-in for Eclipse som gir mulighet for bruk av subversion I Eclipse Maven Maven er et verktøy for prosjekt håndtering og bygg automatisering. Maven bruker ett konstrukt kalt en POM(Project Object Module) for å beskrive programvaren som blir bygget, og dens avhengigheter på eksterne moduler og komponenter. 2.5 Planleggingsverktøy og metodikk I denne delen tar vi for oss hvilke planleggingsverktøy og utviklingsmetodikk vi benyttet oss av. Vi går inn på hvordan planleggingen i utviklingsprosessen fungerte og hvordan vi arbeidet Scrum Under utvikling av systemet brukte vi Scrum, en smidig prosjektmetodikk. Smidig er en fellesbetegnelse på prosjektarbeidsmetoder med fokus på kundenes skiftende behov, og med krav om fortløpende produksjon av løsninger som fungerer. Scrum metoden går kort ut på at man begynner med en kort liste av ferdige krav og tilpasser denne listen med behov underveis. Grunnlaget for utvikling av IT-funksjoner med Scrum er User-stories, de som skal bruke det nye systemet beskriver sine behov, og disse ender opp i konkrete utviklingsoppgaver. Prosjektdokumentasjon S 15

16 Vanlige Scrum begreper Produkteier Kunde og rådgiver, i vårt tilfelle Goodtech Scrum Master Personen som er ansvarlig for at Scrum prosessen går som den skal, og for at alt ligger til rette for utviklerne Bruker dette er brukeren av det ferdige produktet, i vårt tilfelle Nasjonalmuseet User-Stories En beskrivelse fra brukeren over sitt behov Backlog En liste over alle User-Stories, kravspesifikasjonen ble basert på denne Sprint En periode hvor gruppen jobber med en valgt mengde med user-stories Scrum-tavle En arbeidstavle som brukes gjennom utviklingen av prosjektet, vi brukte ScrumDo som vår arbeidstavle ScrumDO ScrumDo er en webapplikasjon som lar brukere håndtere sine Scrum baserte prosjekter, det inkluderer verktøy for å spore brukerhistorier og holde øye med burnup charten Burnup chart En av funksjonene i ScrumDo er et automatisk oppdaterende BurnUp chart som viser fremdriften gjennom hele prosjektperioden. I vår BurnUp chart vises det at det tok en stund før vi virkelig fikk løst flere av problemene. Dette var grunnet den store mengden med stoff vi måtte sette oss inn i for å utvikle gode løsninger til oppgavene i backloggen som samsvarte med JSP og SPRING MVC standarder, senere ble også noen poeng lagt til charten da vi bestemte oss for å ta i bruk Jquery og Ajax for en mer interaktivt og dynamisk side. Prosjektdokumentasjon S 16

17 Fordelen med et BurnUp chart er at det viser hvor mye arbeid som blir gjort i hver iterasjon, og den totale mengden med arbeid et prosjekt inneholder. Et BurnUp chart forandrer seg også avhengig av User-Stories som blir lagt til eller fjernet, det er ikke statisk som BurnDown charts ofte er Arbeidsflyt med Scrum Arbeid i Scrum blir gjort ved at gruppemedlemmene trekker forskjellige user-stories fra produkt backloggen og legger de i sprinter. Vi valgte 14 dagers sprinter da vi følte sprinter på 1 uke ville bli litt for korte Fremdriftsplan I fremdriftsplanen satt vi opp hva vi følte måtte være ferdig til forskjellige tidspunkter. I begynnelsen av januar ble framtidsplanen opprettet. Vi lagde framdriftsplanen så detaljert vi kunne, men fordi vi brukte en smidig utviklingsmetodikk i motsetning til fossefallmetoden var det mange usikkerheter med tanke på når ting ville være ferdig. Arbeidsmengden vi satte som mål i starten av prosjektet var å jobbe 3-4 dager i uken. I april startet vi å møte regelmessig hver dag. Prosjektdokumentasjon S 17

18 Prosjektdokumentasjon S 18

19 2.5.3 Ansvarskart Vi i gruppen valgte Rune Sandersen som gruppeleder, dette fordi han er flinkest til å organisere oss samt fordele oppgaver. Ansvarskartet viser hvilke områder hvert gruppemedlem har vært ansvarlig for. Oppgave Hovedansvar Delansvarlig Prosjektleder Rune Khai / Hafstein Designer Hafstein Khai / Rune Programmerer Hafstein / Rune Khai Webutvikler Rune Khai / Hafstein Prosessdokumentasjon Rune / Khai Hafstein Produktdokumentasjon Risikoanalyse Fremdriftsplan Alle Alle Khai Testing Rune Khai /Hafstein Sluttdokumentasjon Khai / Rune Hafstein Kvalitetssikring Alle 2.6 Utviklingsprosessen Startfasen Det første vi gjorde var å sette opp en Prosjekthjemmeside, etter at vi hadde kommet i kontakt med Goodtech ble det skrevet en statusrapport og en prosjektskisse. Etter nyttår begynte vi å jobbe heltid med prosjektoppgaven. Vi avtalte ett møte med brukerne tidlig i prosjektperioden for å få den nødvendige informasjonen vi trengte for å skrive en fullstendig kravspesifikasjon og forprosjektrapport, flere av møtene ble avlyst og utsatt og det var først i andre uke i februar vi fikk til et møte med nasjonalmuseet, dette førte til at kravspesifikasjonen og forprosjektrapporten vår ble litt forsinket. Prosjektdokumentasjon S 19

20 2.6.2 Prosjekthjemmeside Prosjekthjemmesiden ble opprettet for å presentere informasjon om hovedprosjektet for andre. Dagboken ble lagt til her, og oppdatert jevnlig. Dette for at oppdragsgiver, veileder og andre som hadde interesse for hva vi hadde gjort i prosjektperioden kunne følge med Drøfting av alternativer Etter å ha skrevet kravspesifikasjonen kom vi frem til to alternativer til løsning av oppgaven, valget sto mellom en Web-Applikasjon designet for smarttelefoner og en Android applikasjon, Android fordi applikasjonen da ville være skrevet i Java Web-applikasjon med JSP JSP brukes for å utvikle interaktive web sider med Java og var en alternativ løsning for NILS- Mobil. JSP tar bruk av MVC arkitekturen(model View Controller). Dette fungerer veldig overfladisk ved at applikasjonen er kontrollert av en sentral controller. Controlleren delegerer requests fra nettleseren til passende request handler. Brukeren vil benytte seg av webappen for bruk av NILS gjennom nettleseren på mobilen. Prosjektdokumentasjon S 20

21 Klient på Android telefoner Den lokale applikasjonen utvikles i Java og vil snakke med en webservice som gjør arbeidet med å snakke med NILS sin eksisterende server-applikasjon. Denne løsningen er helt avhengig av at koblingen mellom Android applikasjonen og Webserveren fungerer bra. Viktige punkter for vår løsning er at den i tillegg til å tilfredsstille de funksjonelle kravene må være tilgjengelig, ha intuitivt grensesnitt, og være responsiv. 2.7 Diskusjon rundt vår avgjørelse Tilgjengelighet En lokal Android applikasjon vil ikke være mer tilgjengelig en ren webapplikasjon da Android applikasjonen fortsatt må koble seg til en webservice. Lokale klienter har flere begrensninger en Web-applikasjoner, fordi man må ha den fysiske enheten applikasjonen er installert på for å benytte seg av den lokale klienten. Web applikasjoner er brukbare der man har en nettleser og vinner derfor når det kommer til tilgjengelighet, spesielt med tanke på html5 som også gir mulighet for offline bruk Grensesnitt Det er forskjeller på GUI verktøy tilgjengelig for Android applikasjoner og Web-Applikasjoner, men hver av disse har utviklet seg nok til at begge kan gi en rik brukeropplevelse. Så selv om grensesnittet er viktig var ikke det faktoren som bestemte om vi gikk for en Web- Applikasjon eller Android applikasjon Prosjektdokumentasjon S 21

22 2.7.3 Brukervennelighet Funksjonaliteten til en Web-Applikasjon vil være begrenset med tanke på at det ikke er mulig å manipulere enheten som blir brukt eller opprette et grensesnitt mot strekkodeleseren, men grunnfunksjonaliteten er fortsatt tilstede da alle strekkodelesere er konfigurert til å gi ut strekkoden i det området som er merket på skjermen, på samme måte som tastetrykk fra et tastatur. En Android applikasjon ville vært mer brukervennlig med tanke på dette, men innebærer også at man er låst til Android og de strekkodeleserene grensesnittet er satt opp for, mens en web applikasjon vil fungere så lenge strekkoden blir lest, eller skrevet, inn i en tekstboks. Det er muligheter for å automatisere merking av tekstbokser ved hjelp av f.eks. JavaScript i en web-applikasjon, så selv om Android vinner på brukervennlighet mener vi at en webapplikasjon er det beste alternativet med tanke på platform/hardware uavhengighet Responsitivitet De fleste lokale applikasjoner er mer responsive en webapplikasjoner(avhengig av maskinvare på enheten), men med dagens utbredelse av relativt høy båndbredde tror vi ikke responsiviteten til web applikasjonen kommer til å være et problem. Android applikasjonen ville likevel vært avhengig av en webservice på dette området så hastigheten på nettverket vil fortsatt ha mye å si Oversikt over fordeler og ulemper I tillegg til argumentene ovenfor satt vi opp en liste med punkter for og imot de to løsningene, for å hjelpe oss med å trekke en beslutning. Krav/egenskap Webapplikasjon Poeng Android Poeng Tilgjengelighet Installasjon og oppdatering av Programvare Web applikasjoner kan bli aksessert fra alle enheter som har tilgang til internett. Hvis man har tilgang til en PC, telefon eller tablet vil man kunne bruke applikasjonen Oppdatering av webapplikasjonen skjer uten at brukere må installere eller laste ned noe. Webapplikasjonen kan oppdateres uten å distribuere eller installere 90 Plattform og versjonsavhengighet. Nasjonalmuseet må forholde seg til Android telefoner for brukere av NILS-Mobil. Hvis et grensesnitt skrives mot en strekkodeler blir man bundet til den maskinvaren 50 Oppdatering av programvare innebærer at brukere må laste ned klienten på nytt istedenfor at web applikasjonen forandrer seg(distribusjon). Applikasjoner må bli installert på hver enhet Prosjektdokumentasjon S 22

23 Arbeidsfordeling Bruk av eksisterende API Brukervennelighet Grafisk brukergrensesnitt Responsitivitet Sikkerhet programvare på klienter. Arbeid blir tatt hånd om av webapplikasjonen(utenom Javascript som kjører lokalt) Ved utvikling av webapplikasjon kan vi benytte oss av NILS API'et Ikke mulig å manipulere enheten som blir brukt, eller opprette et grensesnitt mot strekkodeleseren, men grunnfunksjonaliteten er fortsatt tilstede Det er forskjeller på GUI verktøy tilgjengelig for Android applikasjoner og Web-Applikasjoner, men hver av disse har utviklet seg nok til at begge kan gi en rik brukeropplevelse. GUI på Android vil være helt tilpasset mobilen, dette kan muligens gi en litt bedre opplevelse Helt avhengig av nettverkshastighet, det er mulig at en webapplikasjon vil føles litt tregere enn en ren Android applikasjon Kryptering eller sikring på en annen måte må skje i begge tilfeller da informasjon må sendes over nett 0 En webservice vil ta seg av mesteparten av arbeidet, Android applikasjonen må ta seg av Http og GUI 0 Ved utvikling av Android applikasjon kan vi fortsatt bruke NILS API'et for webservicen -60 Mer brukervennlig med tanke på dette, en Android applikasjon vil ha full kontroll over oppførselen til mobilen og man kan derfor kontrollere enheten og opprette grensesnitt mot strekkodelesere De fleste lokale applikasjoner er mer responsive enn webapplikasjoner(avhengig av maskinvare på enheten), men avhengigheten av å koble til en webservice gjør at dette ikke betyr mye, brukeren er fortsatt avhengig av nettverkshastigheten Sum Prosjektdokumentasjon S 23

24 2.7.6 Konklusjon Grunnet diskusjonen ovenfor kom vi frem til at en webapplikasjon ville være den beste løsningen for NILS Mobil. Web Applikasjonen ville være plattformuavhengig og derfor kjørbar uansett om du brukere benyttet seg av mobiler IOS, Android, Windows eller en annen plattform, og fordi webløsningen ligger på en server trenger en ikke bekymre seg om distribusjon og brukere slipper å måtte oppdatere og installere applikasjonen. 2.8 Utviklingsløp Utviklingsløpet for NILS Mobil strakk seg over 6 Sprinter, i vårt forslag av User-Stories som ble sendt til Nasjonalmuseet fikk vi svar på at det kun var grunnleggende innskanning og søkefunksjoner som var etterspurt. Gjennom hver iterasjon forbedret vi, og utviklet nye funksjoner for NILS Mobil, som vi viste til Øystein og fikk nyttig respons på hva som kunne gjøres bedre Sprinter Første Sprint - Feb 21, Feb 28, 2011 Da vi hadde bestemt oss for å utvikle NILS Mobil som en Web-applikasjon satt vi oss inn i web-programmering for Java, som ingen av oss hadde vært borte i før. Vi brukte også lang tid på å få en forståelse for hvordan det eksisterende NILS systemet fungerte, samt hvilken funksjonalitet vi hadde tilgang til fra NILS API et. Vi satt opp en testapplikasjon der vi hentet ut og endret på informasjon i NILS-databasen gjennom webapplikasjonen med bruk av NILS API et. Etter et møte med Øystein der vi viste vår testversjon og diskuterte arkitekturen kom vi frem til at vi ville gå vekk fra bruk av ren JSP med servlets, til utvikling med Spring MVC Sprint - Mar 03, Mar 17, 2011 Spring innebar flere endringer sammenlignet med den ordinære formen for Java vi var vandt med, konsepter som var nye for oss var blant annet inversion of control og dependency injection som skrevet tidligere, mye av denne sprinten ble brukt på å lære oss Spring MVC, lese dokumentasjon, og gå igjennom testprosjekter Sprint - Mar 18, Apr 1, 2011 Vi ferdigutviklet vår første kjørbare løsning av Nils-Mobil i denne sprinten. Løsningen fungerte ved at brukeren først markerte et tekstfelt på mobilen, så begynte innskanning av strekkoder separert med ett semikolon, vi delte så opp teksten hvor den første delen representerte ID for en lokasjon, mens de resterende representerte gjenstander. Etter brukeren var ferdig med skanning ville han så trykke ok og bli tatt til neste side for en oversikt over endringer som kom til å bli gjort, og så et valg for endelig godkjenning av Prosjektdokumentasjon S 24

25 endring av lokasjon for de innskannede gjenstandene. Dette var en fungerende løsning, men etter diskusjon i gruppen kom vi fram til at den ikke var like interaktiv som vi ønsket, vi tenkte oss frem til at det ville vært bedre hvis man for hver strekkode som ble skannet inn, fikk informasjon om gjenstanden det dreide seg om, den gamle plasseringen, og hvor den nå ville bli plassert. Designet på siden begynte også å ta form i løpet av denne Sprinten og ble testet på prosjektgruppen sine mobiler Sprint - Apr 04, Apr 18, 2011 Etter å ha undersøkt hvordan vi kunne løse dette problemet kom vi frem til at vi ville bruke Jquery og AJAX for å fremstille endringer interaktivt, ved bruk av Ajax implementerte vi også funksjonalitet som gjorde at tekstboksen ble automatisk merket, og at teksten ble fjernet etter hver innskanning av strekkode. Etter noe finpuss på applikasjonen hadde vi en gjennomgang av koden med Øystein hvor vi fikk positiv respons på funksjonaliteten og det grafiske designet til applikasjonen Sprint Mai 02, Mai 16, 2011 Bortsett fra diverse små endringer var det største problemet nå Html kode som lå blandet med Java Scriptlets i JSP sidene. Problemet oppsto ved innskanning av strekkoder, som førte til et Ajax kall til en controller som returnerte en annen JSP side Når AJAX kallet ble trigget av Javascriptet førte det til at en annen JSP side ble satt inn i websiden brukeren befant seg på. Utseende og responsmessig fungerte dette bra, men førte til veldig rotete kode og en kodestil som ikke er mye i bruk lenger Noen år tilbake var det vanlig med Java og Html blandet sammen i JSP sider, men på grunn av uryddig kode og problemer fra designerne sin side med å forstå html og Java i samme fil er det ikke lenger i bruk. Vi vurderte å løse problemet ved å returnere JSON fra controlleren som så ble plukket opp av Javascript og plassert i en HTML tabell, eller ved å bruke expression language for å aksessere det vi trenger på den måten så vi slapp bruk av Java i JSP filene. Dette viste seg å være en større oppgave en gruppen hadde forutsett, og det begynte å bli knapt med tid. Vi manglet fortsatt noen enhetstester av systemet og ikke minst mye dokumentasjon. Mai den 15 hadde vi en brukerdemonstrasjon på Nasjonalmuseet sine lokaler, vi fikk vite at vår løsning ble ansett som enkel å bruke og svært hensiktsmessig, at designet virket Prosjektdokumentasjon S 25

26 gjennomtenkt og funksjonell, og at det så ut som NILS Mobil dekket deres behov på en utmerket måte. Nasjonalmuseet ønsket også støtte for søk på museumsnummer, lokasjon og mulighet for flere enn ett logistikkobjekt i tabellen, dette ble vi ferdig med i neste sprint Sprint Mai 23, Mai 31, 2011 Vi løste problemet med scriptlets i JSP ved å ta i bruk en av de nye funksjonene i Spring 3, som støtter Ajax med JSON som en del av Spring MVC. Spring 3 støtter generering av JSON responser og binding av JSON forespørsler med bruk av spring programmeringsmodellene. JSON dataen vi får tilbake fra controlleren blir så konvertert til HTML med bruk av Javascript, på denne måten fjernet vi alle scriptlets fra NILS Mobil siden. I slutten av denne sprinten var det ferdiggjøring av dokumentasjon og finpussing av kode vi drev med, vi gjorde alt klart til innlevering, vi la vi også ut en kjørbar løsning på Goodtech så sensorer kunne se hvordan løsningen fungerte 2.9 Testing Gjennom prosjektperioden har vi testet løsningen på samme måte som brukere vil benytte seg av løsningen, samt litt testing ved bruk av enhetstester, begrenset pga vanskeligheten med å enhetsteste spring Controllere. For testing av JavaScript benyttet vi oss av Firebug, en utvidelse til Firefox, som lot oss se kodefeil i scriptene våres samt resultatet av HTTP Post og HTTP Get forespørsler mot web applikasjonen Vi har også demonstrert programmet for nasjonalmuseet og latt brukere der prøve løsningen, tilbakemeldingen fra nasjonalmuseet var positiv og de var veldig fornøyd med løsningen. Nasjonalmuseet ser på hovedprosjekt NILS Mobil som et svært spennende prosjekt som har utviklet gode løsninger som det sterkt behov for, og som ser ut til å dekke behov på en utmerket måte Hva kunne vært gjort bedre? Gruppen føler at det meste har gått bra gjennom prosjektarbeidet, hvis vi skulle gjort noe annerledes ville det vært å ferdiggjøre produktet tidligere slik at vi ville fått mer tid til å gå gjennom prosjektdokumentasjonen med arbeidsgiver og veileder. Mangel på enhetstester er også noe vi skulle gjort bedre, vi undervurderte vanskeligheten ved å skrive nyttige enhetstester og problematikken rundt enhetstesting av Spring Controllere. Prosjektdokumentasjon S 26

27 2.11 Siste ord Gjennom utvikling av NILS Mobil har vi lært veldig mye, blant annet hvordan utvikling av større løsninger fungerer i arbeidslivet, hvordan det er å ta i bruk Scrum i utvikling av prosjekter, kundekontakt og hvordan vi kan levere et produkt som best passer til deres ønsker. Vi har også lært mye om utviklingsmetodikker og en mengde verktøy som brukes til utvikling i arbeidslivet. I mer enn 5 måneder hva vi jobbet med prosjektet og vi føler alle at vi har fått god erfaring i hvordan det er å jobbe med et stort prosjekt i en bedrift fra denne tiden. Vi vil først og fremst takke Goodtech for at vi fikk tilbudt oppgaven, og at de har stilt med eksterne veiledere som har hjulpet oss mye under prosjekt perioden. Vi vil spesielt nevne Øystein Myhre som har vært en sentral person i prosjektoppgaven vår, han har hjulpet oss med diverse verktøy var nye for oss vært til god hjelp når vi har hatt problemer. Vi takker Harald som har vært i mye kontakt med brukere og hjulpet oss med å kontakte diverse forhandlere til anskaffelse av strekkodeleser, samt kommet med nyttige innspill om planlegging før møter og hvordan vi skal forholde oss til kunder. Vi takker Eivind, representanten for Nasjonalmuseet har hjulpet oss med brukerhistorier og redegjøring for brukerne sine ønsker og vi vil takke for et godt samarbeid. Vi takker også vår interne veileder Geir Skjevling. Prosjektdokumentasjon S 27

28 Prosjektdokumentasjon S 28

29 3 Produktdokumentasjon 3.1 Forord Dette er produktdokumentasjonen for NILS Mobil, hovedprosjekt ved Høgskolen i Oslo våren 2011 Dokumentet beskriver NILS Mobil med fokus på det tekniske, i dokumentet finner du informasjon om produktet vi har utviklet, samsvaret mellom kravspesifikasjonen og produktet, sentrale datastrukturer, produktets oppbygning og virkemåte. og en oversikt over Hovedprogrammet og underprogrammer. Dokumentet er beregnet for sensorer, våre veiledere og andre som har interesse av å lese om det tekniske rundt NILS Mobil, det forutsettes at leseren av denne produktrapporten er kjent med Java og utvikling av web-applikasjoner Gruppen Gruppen består av Rune Sandersen, Khai Quang Nguyen og Hafsteinn Thor Ingason. Medlemmene kjente hverandre fra tidligere prosjektarbeid og valgte å danne gruppen på grunnlag av god kommunikasjon og bra erfaring fra tidligere arbeid. Etter å ha sett gjennom prosjektforslagene på HiO sine sider var vi mest interessert i prosjektet Nils-Mobil fra Goodtech, da det virket spennende og passet med ønskene vi hadde, i tillegg ville det gi oss erfaring i hvordan det er å jobbe i arbeidslivet. Vi sendte en E-post angående vår interesse og fikk avtalt et møte. På møtet diskuterte vi forskjellige temaer inkludert tidligere erfaringer og kunnskapsnivå. Vi ble tilbudt oppgaven senere på dagen og takket ja. Oppgaven gikk ut på å utvikle en løsning hvor det skulle benyttes mobile enheter for registrering og kontroll over gjenstander i et logistikk system, som et alternativ til Goodtech sin PC-baserte løsning Oppdragsgiver Kunden er Nasjonalmuseet. Goodtech er vår oppdragsgiver og vil vedlikeholde og videreutvikle systemet etter levering Om Goodtech Goodtech ASA er et norsk teknologi- og ingeniørkonsern som er notert på Oslo Børs. Selskapet leverer løsninger til industri og offentlig forvaltning, miljøprosjekter innenfor vann, avløp og energigjenvinning, samt tilhørende produkter og produktteknologier. Selskapet er representert med kontorer i flere geografiske regioner i Norden og Tyskland. Konsernet representerer flere internasjonale produsenter og deres produkter i det nordiske markedet. Goodtech har over 1000 ansatte hvor hovedtyngden av de ansatte er ingeniører og tekniske spesialister. Prosjektdokumentasjon S 29

30 Goodtech stilte med en veileder og to kontaktpersonener til prosjektet: Harald Pedersen var vår kontaktperson, Øystein Myhre var vår kontaktperson og veileder Om nasjonalmuseet Nasjonalmuseet samler og bevarer, stiller ut og formidler landets mest omfattende samlinger av kunst, arkitektur og design. Museet viser faste utstillinger med verk fra egen samling og skiftende utstillinger med innlånte og egne verk. Museets visningssteder i Oslo er Nasjonalgalleriet, Museet for samtidskunst, Nasjonalmuseet Arkitektur og Kunstindustrimuseet. Utstillingsprogrammet omfatter også vandreutstillinger i inn- og utland. 3.2 Bakgrunn for oppgaven Goodtech har fra før laget en løsning for Nasjonalmuseet, NILS (Nasjonalmuseets Interne Logistikk System) for å holde kontroll med hvor gjenstander er, hvilken prosess de er i, og hvilke hendelser de har vært med på. Hovedhensikten med NILS er at det skal holde rede på hvor gjenstander er til enhver tid, dette gir Nasjonalmuseet oversikt over logistikkflyt og lokasjon for sine gjenstander. Systemet er hendelsesbasert og bygd opp rundt problemstillinger som «Hva har skjedd med hvilke gjenstander og når?». NILS ble opprinnelig brukt for store flyttinger og er skreddersydd for masse-registrering i denne typen prosjekter. I senere tid har det dukket opp nye behov for kontroll over mindre flyttinger, og det er et ønske om et system som gjør dette arbeidet lettere, ved bruken av mobile enheter istedenfor PC-er. 3.3 Mål Mål for oppgaven Målet for oppgaven var å lage et mobilt logistikk og prosess-system for registrering og kontroll av hvor gjenstander befinner seg. Systemet kommer til å jobbe side om side med det eksisterende NILS systemet, og vil gi logistikkstyring via mobile enheter gjennom en applikasjon som et alternativ til dagens PC-Baserte løsning Mål for gruppen Lære oss nye teknologier, metodikker og språk. Lære oss hvordan en systemutviklingsprosess fungerer i et større prosjekt en de vi tidligere har hatt på HiO. Få erfaring i hvordan det er å arbeide med en reel oppdragsgiver. Prosjektdokumentasjon S 30

31 3.3.3 Rammebetingelser: Applikasjonen skal lages i Java NILS har i dag et Java-basert klient-api som fortrinnsvis skal benyttes, men om dette ikke er hensiktsmessig, kan man kommunisere over HTTP med kjernesystemet. Strekkoder benyttes som informasjonsbærer. Vi ønsker at man benytter seg av åpne standarder og åpen kildekode i størst mulig grad Goodtech s infrastruktur for systemutvikling skal benyttes. Sentrale verktøy er: Scrum, Maven, Subversion, Hudson og Artifactory Aktuelle platformer: Android, J2ME og Windows Mobile. Om mulighetene åpner seg for Java på ios (iphone/ipad), vil dette også være en aktuell plattform Krav til oppgaven User stories Brukere skal kunne: Lese strekkoder Skanne gjenstander inn på lokasjon Se hvor en gjenstand befant seg sist Søke opp gjenstander Se logistikk historikk om gjenstander som skannes eller søkes opp Plassere gjenstand på lokasjon uten bruk av strekkodeleser Søke etter gjenstander uten bruk av strekkodeleser Design og brukervennlighet Systemet skal være selvforklarende så langt det er mulig, forutsatt at brukerne har kjennskap til de begrepene som blir brukt. Designet av webapplikasjonen skal være optimalisert for smarttelefoner. Prosjektdokumentasjon S 31

32 3.3.6 Kode og vedlikehold Subversion vil bli brukt for versjonskontroll. Maven brukes for bygging av prosjekter. Vi bruker UTF8 som tegnsett. Gruppen vil bruke Spring Rammeverket for utvikling av applikasjonen. Gruppen vil benytte seg av eksisterende NILS API. 3.4 Beskrivelse av programmet Vi vil i dette kapittelet gjøre rede for funksjonaliteten som tilbys i NILS Mobil. Vi beskriver programmet, hva som er hensikten med det, og hva det gjør rent prinsipielt Figur 1: Brukergrensesnitt for Nils Mobil Om NILS Mobil NILS Mobil er en web-applikasjon og logistikksystem som tilbyr skanning og søk på logistikkobjekter og lokasjoner i NILS systemet. Applikasjonen er tilpasset for bruk på smarttelefoner men kan også tas i bruk på PC-er og andre enheter med tilgang til internett. Det har vært en forutsetning for gruppen at applikasjonen skal være tilgjengelig på så mange steder som mulig, webapplikasjonen kan tas i bruk på alle enheter med tilgang til internett, og kan brukes til skanning på alle enheter der det er tilgang til internett og støtte for bluetooth, det er også mulighet til å skrive inn strekkoder manuelt. Prosjektdokumentasjon S 32

33 3.5 Krav for installasjon og drift av programmet Server Programmet er skrevet i Java og benytter seg av eksisterende NILS database, som kjører på en MySQL server. Klientsiden av programmet vil kreve at brukeren kjører en hvilken som helst enhet med nettleser og støtte for Javascript, støtte for bluetooth er gunstig hvis brukere skal foreta skanning av gjenstander. 3.6 Sentrale datastrukturer i programmet NILS NILS er basert på en industrialisert standard for logistikk og prosesstyring, NILS består av en database, som lagrer hva som skjer med hvilke gjenstander, et serverprogram med et Java- API, og en klient som kjører lokalt på brukerens maskin. Klienten og tjeneren er skrevet i Java. Rammeverket brukt i NILS er Spring. Løsningen benytter seg av strekkoder, der alle relevante gjenstander og lokasjoner har en strekkode forbundet med seg. Ved å registrere lokasjonen til gjenstander med strekkoder får man oversikt over hvor gjenstander er nå, og hvor de har vært tidligere Servlet En servlet er en Java klasse som kjører i en server applikasjon for å svare på forespørsler til klienten, de brukes vanligvis med HTTP. Typisk bruk av servlets er blant annet prosessering av data sendt inn via en Form fra presentasjonslaget og retur av forespørslene til klienten JSP: JavaServerPages(JSP) er en Java teknologi som hjelper utviklere å levere dynamisk genererte websider basert på HTML,XML eller andre dokumenttyper. Det er Sun sitt svar på ASP og PHP. JSP syntaks er en miks av to grunnleggende typer, scriptlet elementer og markeringsspråk. Markeringsspråket er vanligvis standard HTML eller XML, mens scriptlet elementer er blokker med Java kode som kan mikses inn mellom markeringsspråket. Når siden blir etterspurt blir Java koden kjørt og dens output blir lagt til siden, det omringende markeringsspråket gir det ferdige resultatet. Prosjektdokumentasjon S 33

34 3.6.4 JSON JavaScript Object Notation(JSON) er en enkel måte å håndtere data på. JSON er svært godt egnet til bruk i AJAX-applikasjoner, våre controller metoder returnerer JSON objekter, som blir konvertert til HTML av Javascript og stylet av CSS Spring Rammeverket Rammeverket er utviklet av Rod Johnson og ble for første gang sluppet i juni Spring er et åpen kildekode rammeverk laget for å adressere kompleksiteten i utvikling av Enterprise applikasjoner. Sentralt til Spring rammeverket er Inversion of Control containeren, containeren er ansvarlig for livssyklusen til objekter, opprettelsen av objekter, kall på initialiseringsmetoder, og konfigureringen av objekter ved å binde de sammen Dependency Injection: Spring støtter løs kobling gjennom en teknikk kjent som dependency injection(di). Når DI er tatt i bruk får objekter sine avhengigheter passivt, istedenfor å lage eller å lete opp avhengigheter Container: Spring er en container på den måten at den inneholder og håndterer livssyklusen og konfigurasjonen av objekter. I Spring kan man deklarere hvordan objektene skal bli opprettet, hvordan de skal bli konfigurert, og hvordan de forbinder seg med hverandre MVC MVC er en måte å dele opp en applikasjon på. Hver del skal være uavhengig av de andre, MVC står for Model View Controller Model Model utfører forretningslogikk. Forretningslogikk refererer til det som er fundamentalt for systemdesignet. For eksempel hvis en biblioteksapplikasjon var laget, ville logikken som forsikret at bibliotekskort eieren bare kunne låne opptil 5 bøker på en gang ligget i en del av Modellen View View laget er for presentasjonen av applikasjonen, i NILS Mobil består view laget av en samling JSP sider, view laget skal inneholde så lite logikk som mulig for programmeringsspråket som blir brukt Controller En controller håndterer forespørsler fra brukeren og logikk spesifikt til applikasjonen. En controllers jobb er å motta forespørsler fra en bruker via presentasjonslaget, prosessere Prosjektdokumentasjon S 34

35 forespørselen, kommunisere med modellen hvis nødvendig, og så sende resultatet til brukeren. informasjonen, kommunisere med modellen hvis nødvendig, og så sende outputen til brukeren Figur 2: Typisk MVC arkitektur Spring MVC Spring MVC inkluderer de fleste grunnleggende konsepter som andre MVC rammeverk. Forespørsler kommer inn via Front Controlleren, som ikke gjør noe web eller business logic men heller delegerer til vanlige Java objekter kalt Controllers, hvor det ordentlige arbeidet blir gjort, enten ved at alt gjøres i controlleren eller ved bruk av hjelpeklasser. Når arbeidet er gjort er ansvaret til presentasjonslaget å presentere output I et rett format, I vårt tilfelle HTML i JSP sider Front Controller En front controller er en servlet som sender forespørsler videre til individuelle controllere, det er også brukt i blant annet Struts og Core J2EE, alle forespørsler til applikasjonen er kontrollert av front controlleren. Individuelle Controllere kan bli brukt for å håndtere mange forskjellige URL s og hendelser. En standard controller i Spring er en vanlig Java klasse. Hvilken Controller klasse, og hvilken metode som håndterer forespørsler i denne klassen blir bestemt av Spring sin DispatcherServlet(i vårt tilfelle Spring-Servlet.xml). Forespørselhåndtering kan bli satt eksplisitt i Spring-Servlet.xml filen(applicationcontext filen), eller ved bruk av annoteringer i controller klasser hvis Spring er konfigurert for dette, slik vi har gjort. Prosjektdokumentasjon S 35

36 Eksempel på mapping via annotering, brukeren får tilsendt plassering.jsp etter kall på /plassering.htm Typisk Spring MVC hendelsesforløp Klienten spør etter en ressurs i webapplikasjonen ved å gjøre en handling i presentasjonslaget. Spring Front Controlleren oppdager etterspørselen og vil prøve å finne passende Handler Mapping. Handler Mapping er brukt til å mappe en forespørsel fra Klienten til dens Controller ved å se over de forskjellige controllerne definert i Application Context filen(spring- Servlet.xml) eller via Med hjelp av Handler Adapters vil Dispatcher Servleten delegere etterspørselen til rett Controller. Controlleren prosesseserer klientens etterspørsel og returner ett View med det som ble spurt etter av brukeren, vanligvis i form av et ModelAndView objekt. MAV objektet sendes tibake til Front Controlleren, det valgte viewet blir rendret til klienten. Prosjektdokumentasjon S 36

37 Figur 3: Spring MVC arkitektur 3.7 Programmets virkemåte Dette er en kort beskrivelse av NILS Mobil fra brukerens ståsted. Dette kapittelet er nyttig å lese for å få en forståelse for hvordan applikasjonen virker og hvordan den ser ut. For en fullstendig beskrivelse med flere bilder fra programmet anbefaler vi å lese brukermanualen. Når brukeren går inn på NILS Mobil vil personen får opp et brukergrensesnitt med 3 knapper, Plassere, Søke og Hjelp Prosjektdokumentasjon S 37

38 3.7.1 Plassere Etter at brukeren har gått inn på Plassere vil tekstboksen være markert og klar for innskanning eller skriving av strekkode. Applikasjonen fungerer slik at brukeren først skanner inn lokasjonen, og så gjenstandene som skal plasseres på lokasjonen. For hver strekkode som skannes inn vil brukeren få tilbakemelding på om skanningen var vellykket eller ikke i form av en feilmelding eller oversikt over valgt lokasjon og objekter som har blitt skannet inn. Etter at brukeren har skannet inn ønsket antall strekkoder kan han velge å bekrefte gjenstandene sin nye lokasjon eller trykke tilbake og avbryte. Prosjektdokumentasjon S 38

39 3.7.2 Søke Etter at brukeren har gått inn på søke vil tekstboksen være markert og klar for innskanning eller skriving. Brukeren kan velge å søke på Logistikk ID, Museumsnummer eller strekkoden til en lokasjon og få opp informasjon rundt dette. Ved søk på logistikkobjekter vises ID, ObjektID, Betegnelse, Museums NR og nåværende lokasjon, mens ved søk på lokasjon vises ID, objektid, Betegnelse og Museumsnr for Gjenstander på lokasjonen, brukeren kan også trykke vis hendelser for en oversikt over hvilke hendelser som har skjedd med gjenstanden. Prosjektdokumentasjon S 39

40 3.7.3 Sekvensdiagram Simpelt sekvensdiagram for å gi et inntrykk av dataflyten i NILS Mobil Prosjektdokumentasjon S 40

41 3.8 Oppbygning av NILS Mobil Presentasjonslaget (view) Presentasjonslaget tar for seg alle visninger i applikasjonen. Laget inneholder ingen større funksjoner, all logikk som kan trekkes ut skal ligge i kontroller eller model laget, presentasjonslaget i NILS Mobil består av en samling JSP filer JSP JSP sidene ligger under WEB-INF/jsp og blir aksessert gjennom controllere Stilark Filen style.css ligger under WEB-INF/css og inneholder alle stilene som blir benyttet av presentasjonslaget. Stilene angir hvordan applikasjonen skal se ut og hvordan elementer som blant annet knapper og tekst skal vises i brukergrensesnittet. Et eksempel tatt fra style.css div.innholdsboks { -moz-border-radius: 1em 1em 1em 1em; border-radius: 8px 8px 8px 8px; margin: 10px; /* Tilpasser seg automatisk */ padding: 10px; /* 10 pixlers padding */ background: #fff; /* Hvit bakgrunn */ display: inline-block; } Generell styling av den hvite hoved diven som alt innholdet blir plassert i. display: inline-block; sørger for at innholdet ikke bruker unødvendig mye plass som for eksempel masse whitespace Javascript/Jquery JavaScript brukes for å tilføre dynamiske elementer til nettsider, javascript kode kjøres lokalt i nettleseren, enten automatisk eller som en reaksjon på brukervalg på siden. jquery er et JavaScript bibliotek, skapt for å forenkle scripting i HTML dokumenter Javascript bruksområder i NILS Mobil Automatisk markering av tekstfelt Vi bruker en utvidelse til jquery med navn Textchange for å oppdage når tekst blir endret i tekstfelt Vi bruker JavaScript for å trigge en funksjon når newline/ linefeed (enter) oppdages Konvertering fra JSON objekter til HTML tabeller JQuery-Ajax brukes for dynamisk oppdatering og kall til controllere. Prosjektdokumentasjon S 41

42 Eksempel på JavaScript funksjoner i NILS Mobil Document ready Her bindes textchange funksjonen til <Textarea> feltet som heter strekkode. Dette gjør at strekkode feltet sier ifra hver gang innholdet dens endres, funksjonen kan minne om Java sin Eventlistener. Funksjonen har vi videre utviklet til å se om det er et linefeed symbol (\n) I strekkode feltet, hvis linjeskift oppdages sendes strekkoden videre via AJAX inn til tjeneren hvor den plukkes opp av LogstikkControlleren og sendes videre til LogstikkBehandleren. Den siste funksjonen som kjøres er clear(), som fjerner alt innholdet I strekkode feltet. $(document).ready(function() { $('#strekkode').bind('textchange', function() { if($(this).val() == '\n') { clear(); } if ($(this).val().indexof('\n')!== -1) { $.post("/nils/strekkodetilplassering.htm", { strekkode : $('#strekkode').val() }, function(data) { if(data.indexof('valgt lokasjon:')!= -1) { $('#valgtlokasjon').html('<table class="fillwidth\"><tr ><td class="valgtloktd"><h3>' + data + '</h3></td></tr></table>'); $('#tilbakemelding').html(''); } else if(data.indexof('feil:')!= -1) { $('#tilbakemelding').html(data); } else { $('#lista').html(listetable(data)); if(data!= "") { $('#bekreftflytting').removeclass('btnstyleddisabled'); $('#bekreftflytting').addclass('btnstyled'); $('#bekreftflytting').removeattr("disabled"); } $('#tilbakemelding').html(''); } }); clear(); } }); }); Prosjektdokumentasjon S 42

43 ListeTable Vi har skrevet 3 forskjellige funksjoner som er egnet til hvert sitt JSON objekt av denne typen. De tolker om JSON resultatet og bygger en html tabell ut av det. Dette puttes så inni en bestemt DIV via Jquery sin.html() funksjon. //metode som tolker om ett json objekt og viser det i en html tabel function ListeTable(objArray) { var array = typeof objarray!= 'object'? JSON.parse(objArray) : objarray; var str = '<div class="scrolltablediv"><table class="fillwidth">'; for (var i = 0; i < array.length; i++) { if(i == 0) { //Setter opp overskriftene i tabellen str += '<thead class="topp"><tr><th scope="col" >ID</th><th scope="col" >Betegnelse</th><th scope="col" >Museums nr</th><th scope="col" >ObjektID</th><th scope="col" >Nåværende lokasjon</th></tr></thead><tbody>'; } //Bytter fargene på radene for annenvær rad str += (i % 2 == 0)? '<tr class="en">' : '<tr class="to">'; for (var index in array[i]) { str += '<td>' + array[i][index] + '</td>'; } str += '</tr>'; } str += '</tbody></table></div>'; return str; } Filstruktur i presentasjonslaget Hjelp.jsp Bruksanvisning for oppsett av strekkodeleser og bruk av NILS Mobil Include.jsp Inneholder funksjoner som er felles for alle sidene Index.jsp Hovedmenyen til NILS Mobil Plassering.jsp Siden for endring av lokasjon til gjenstander Sok.jsp Side for søk på lokasjoner og gjenstander Prosjektdokumentasjon S 43

44 3.8.6 Controllerlaget Controllere i NILS Mobil håndterer feedback fra brukeren og tar for seg logikk spesifikt til applikasjonen. Controllere mottar input fra presentasjonslaget, prossesserer informasjonen, kommuniserer med modellen hvis nødvendig, og sender svar på brukerens forespørsel i form av JSON eller en ny JSP side Eksempel på Controller metoder i NILS Mobil: StrekKodeTilPlassering: LogistikkController har en Portal og en LogstikkBehandler som den bruker til å hente ut og endre data, instansen av disse blir satt via Dependency Injection av Spring containeren. LogistikkControlleren sender strekkoder videre til LogistikkBehandleren som utfører arbeidet, controlleren sender inn strekkoder til behandleren og svarer med tilbakemeldinger til Javascriptet i JSP'en i form av JSON objekter. Det første som skjer i strekkodepost metoden er at den gir behandleren adgang til data med portalen (behandler.setportal(portal)). Det skal ligge ett Plasserings objekt i session, hvis det ikke gjør det så oppretter vi ett og sender strekkoden videre til behandleren. Behandleren ser etter en Lokasjon ut ifra den gitte strekkoden den første gangen. Når lokasjonen er satt blir alle de neste søkene på LogistikkObjekter. StrekKodePost metoden lager også en liste med hjelpeklassen (PlasseringsListeElement) som lagres og blir returnert som JSON objekt til siden. Prosjektdokumentasjon S 44

45 @RequestMapping(value = "/strekkodetilplassering") Object strekkodetilplassering(httpservletrequest required=true) String strekkode) { behandler.setportal(portal); stiutil = portal.opprettlokasjonfilter().getlokasjonsstiutil(); Plassering plassering = (Plassering)WebUtils.getSessionAttribute(request, "plassering"); if(plassering == null) { plassering = new Plassering(); } WebUtils.setSessionAttribute(request, "plassering", plassering); String tilbakemelding = behandler.oppdaterplassering(strekkode, plassering); if(tilbakemelding.indexof("feil:")!= -1) { return tilbakemelding; } List<PlasseringListeElement> plasseringliste = new ArrayList<PlasseringListeElement>(); for(logistikkobjekt lob : plassering.getlobset()) { String stistring = ""; for(lokasjonstubb lokstub : lob.getlokasjoner()) { stistring += lokstub.getsti(); } String lokstr = stistring!= ""? stiutil.convertstibasedonmap(stistring) : ""; //hindrer enn numberformat exception som inventerte gjenstander uten lokasjonsti forårsaker. plasseringliste.add(new PlasseringListeElement(lob.getId(), lob.getobjid().tostring(),lob.getbetegnelse(), lob.getmuseumsnr(), lokstr)); } WebUtils.setSessionAttribute(request, "plasseringliste", plasseringliste); if(plassering.getlok()!= null && plasseringliste.isempty())//dette er for å vi valgt lokasjon den aller første gangen { String valgtlok = "Valgt lokasjon: " + plassering.getlok().getnavn(); System.out.println(valgtLok); return valgtlok; } return plasseringliste; } Prosjektdokumentasjon S 45

46 strekkodetilsok strekkodetilsok sender inn strekkode til behandleren som i plassering, og returnerer en string. Behandleren lagrer resultatet i session og utifra tilbakemeldingen til strekkodetilsok så velger Javascriptet i JSP siden en riktig måte å vise resultatet = "/strekkodetilsok") String strekkodetilsok(httpservletrequest required=true) String strekkode) { WebUtils.setSessionAttribute(request, "soklob", null); WebUtils.setSessionAttribute(request, "sokrestultat", null); WebUtils.setSessionAttribute(request, "sokresultatlokasjon", null); WebUtils.setSessionAttribute(request, "sokloblist", null);//passer på at ikke det blir hengende gamle søkresultater i session, dette viste feil hendelser før behandler.setportal(portal); return behandler.sok(strekkode, request); //returnerer tilbakemelding } Filstruktur i Controller laget MappingController.Java MappingController.java brukes til å definere hvilke JSP sider brukere skal ha tilgang til, her defineres hvilke JSP sider som svarer til hvilke forespørsler fra brukere LogistikkController.Java LogistikkController brukes til å svare på HTTP GET og HTTP POST requests, og generell logikk relatert til søk og plassering i systemet. Data returneres herfra i JSON format som senere blir behandlet av Javascript i JSP sidene Model laget Model klassene i NILS Mobil gjør forretningslogikk relatert til generelle søke og plassere oppgaver, de blir kalt på av Controllerlaget. Prosjektdokumentasjon S 46

47 Eksempler på metoder i model laget: public String oppdaterplassering(string strekkode, Plassering plassering) { if(plassering.getlok() == null) { LokasjonFilter lfilt = portal_.opprettlokasjonfilter(); lfilt.setid(strekkode); Lokasjon lok = lfilt.find(); if(lok == null) { return "Feil: lokasjon ikke funnet"; } plassering.setlok(lok); return ""; } //lokasjonen er satt LogistikkObjektFilter lobfilt = portal_.opprettlogistikkobjektfilter(); lobfilt.setid(strekkode); LogistikkObjekt lob = lobfilt.find(); if(lob!= null) { plassering.addlob(lob); return ""; } return "Feil: Logistikk objekt ikke funnet"; } Metoden får parameterene strekkode og plassering fra logistikkcontrolleren. Metoden får strekkoden(fra httprequest) og Plassering objektet(fra session) den skal jobbe mot ifra LogistikkControlleren. Først sjekker vi om Plasserings objektet har fått en lokasjon, hvis Plasserings objektet ikke har noen lokasjon antar vi at strekkoden er for en lokasjon og leter etter en og gir den til Plasserings objektet. Hvis vi ikke finner noen lokasjon så returneres det en tom string og logistikkcontrolleren gir feilmelding. Når lokasjonen er blitt satt leter vi fremmover kun etter LogistikkObjekter, som plasseres i Plassering objektets lobset(java.util.set). Plassering ligger i session helt til brukeren velger bekreft eller trykker tilbake knappen Filstruktur i Model Laget HendelsesListeEleent, SokListeElement, PlasseringListeElement Hjelpeklasser for å gjøre det enklere å tolke om JSON objekter til en HTML tabeller Plassering.java Samler opp logistikkobjekter og plasserer de på lokasjon Prosjektdokumentasjon S 47

48 LogistikkBehandler.java Gjør generelle plassere og søke oppgaver 3.9 Testing av programmet Gjennom utviklingen av NILS Mobil har applikasjonen og dens funksjonalitet kontinuerlig blitt testet på gruppemedlemmene sine mobiltelefoner samt mobil emulatorer for å forsikre oss om at funksjonaliteten og brukergrensesnittet er det vi, kunden og oppdragsgiver ønsker. Større gjennomlesninger av koden har skjedd hver gang vi ble ferdige med en prototype for å se etter potensielle forbedringer og generell opprydning. Vi hadde en større brukertest i slutten av prosjektperioden, men holdt kontakt med brukerne over angående spørsmål rundt krav eller annet vi måtte lure på Endelig resultat av funksjonalitetstest på forskjellige nettlesere Nettleser/Funksjon Android(G oogle) WinMobile (Opera 9.7) ios(safari) PC(FireFox) PC(Chrome ) PC(IE) Firefox mobile Javascript(Autofocus) Ikke støtte Støtte Ikke støtte Støtte Støtte Støtte Ikke støtte Javascript(Linefeed Støtte Støtte Støtte Støtte Støtte Støtte Støtte trigger) Javascript(Clear) Støtte Støtte Støtte Støtte Støtte Støtte Støtte CSS window scaling Støtte Støtte Støtte Støtte Støtte Støtte Ikke støtte CSS button GUI Støtte Støtte Støtte Støtte Støtte Støtte Støtte CSS background gradient Støtte Støtte Støtte Støtte Støtte Støtte Støtte Funksjon(Plassere) Støtte Støtte Støtte Støtte Støtte Støtte Støtte Funksjon(Søke) Støtte Støtte Støtte Støtte Støtte Støtte Støtte Kommentar på testresultatet Ut ifra testing vår konkluderer vi at NILS Mobil er fullt brukbar på alle standard nettelsere til mobiltelefoner, og de fleste nedlastbare nettlesere. Grunnen til at autofokus ikke fungerer på noen av nettlesere er at det er deaktivert fra nettleseren sin side, vi fant ingen mulighet for å aktivere dette ved hjelp av Javascript eller på andre måter. Prosjektdokumentasjon S 48

49 3.10 Kravspesifikasjonen og det endelige produktet Alle storyene som ble lagt frem i prosjektet ble fullført. Vi føler derfor at produktet vårt samsvarer godt med kravspesifikasjonen Tilbakemelding fra kunde Nasjonalmuseet ser på hovedprosjektet NILS Mobil som et svært spennende prosjekt som har utviklet gode løsninger som det er sterkt behov for, og som også ser ut til å dekke behov på en utmerket måte. Nasjonalmuseet ser på hovedprosjekt NILS Mobil som et svært spennende prosjekt som har utviklet gode løsninger som det sterkt behov for, og som ser ut til å dekke behov på en utmerket måte. Vi ser at løsningen som prosjektet har utviklet både er en enkel og bruke, og en svært hensiktsmessig løsning for registrering av aktuelle hendelser Design knyttet til telefon og web applikasjon virker gjennomtenkt og funksjonell Utvidelsesmuligheter NILS Mobil har flere utvidelsesmuligheter, ny funksjonalitet kan legges til den nåværende applikasjonen uten større problemer. Prosjektdokumentasjon S 49

50 Prosjektdokumentasjon S 50

51 4.1 Bruksanvisning 4 Vedlegg Utstyr og tilkoblinger For å bruke NILS-Mobil trenger man følgende utstyr og tilkoblinger Utstyr Strekkodeleser som støtter Bluetooth tilkobling (Ver. 1.2 med SPP eller HID profiler) Mobil/Pad som har Bluetooth, mobilnett/wifi og med nettleser Tilkoblinger Bluetooth Nettforbindelse (Wifi eller mobilnett) Prosjektdokumentasjon S 51

52 4.1.2 Hvordan koble til strekkodeleser ios For å koble strekkodeleseren til telefonen/paden er det viktig at du har aktivert bluetooth på enhetendin. Dette gjøres ved å gå inn på Innstillinger(1.1) Generelt (1.2) Bluetooth (1.3). Her trykker du på den gråe boksen ved Bluetooth (1.4). (Skal se ut som (1.5)). Deretter vil du få opp en liste med Bluetooth enheter. Du velger da din strekkodeleser, og får da opp en liten boks hvor du må skrive inn passordet til leseren din. Når dette er gjort og passordet er korrekt vil leseren din pipe en gang som indikasjon på forbindelse. Strekkodeleseren vil nå fungere som et Keyboard Prosjektdokumentasjon S 52

53 Android For å koble strekkodeleseren til android telefonen/paden er det viktig at du har aktivert bluetooth på enhetendin. Dette gjøres ved å gå inn på Innstillinger(2.1) Trådløs og nettverk (2.2) Bluetooth-innstillinger(2.3). Her krysser du av på Bluetooth(2.4).(Skal se ut som (2.5). Deretter vil du få opp en liste med Bluetooth enheter. Du velger da navnet på strekkodeleseren din og taster inn det tilhørende passordet (2.6). De fleste Bluetooth lesere vil da pipe en gang som indikasjon for at den har fått kontakt med telefonen/paden. Strekkodeleseren vil nå fungere som et Keyboard Prosjektdokumentasjon S 53

54 4.1.3 Hvordan Bruke Nils-Mobil Når en starter opp Nils-Mobil vil det se ut som på bildet nedenfor(3.1). Her vil en få opp et brukergrensesnitt med 3 knapper. Disse knappene er Plassere, Søke og Hjelp. Hver av disse knappene har hver sin funksjon. Når en skal plassere en gjenstand på en lokasjon trykker man på Plassere. Hvis en skal søke opp en gjenstand eller lokasjon trykker man på Søke. Og når en trenger hjelp til bruk av Nils-mobil trykker en på Hjelp Plassere Når en trykker på Plassere knappen kommer følgende side opp (3.2) Tekstfelt Her legges strekkoden inn vha strekkodeleseren eller tastes koden inn manuelt med tastatur. Hvis du skriver strekkoden inn manuelt er det viktig å avslutte den med linjeskift (Enter). Prosjektdokumentasjon S 54

55 2. Bekreft knapp Denne knappen benyttes til å bekrefte flytting av gjenstander til valgt lokasjon 3. Tilbake knapp Denne knappen avbryter det du har skannet inn, dette gjelder både lokasjoner og gjenstander.ingenting vil bli flyttet og du blir sendt tilbake til hovedsiden. Brukes hvis en bruker vil starte på nytt eller skal avbryte skanningen. Når du skanner inn lokasjon valg lokasjon vises under tekstfeltet. Etter at gyldig lokasjon er valgt kan du begynne innscanning av gjenstander, for hver gjenstand som skannes inn vil ID, Betegnelse, Museums nr, Nåværende lokasjon, og Objekt ID vises som på bildet nedenfor. (3.3). Skanningen avsluttes når brukeren trykker på bekreft knappen eller tilbake knapp Valgt lokasjon Lokasjonen vises først etter at den har blitt skannet inn, og blir der helt til en bekrefter eller avbryter. 5. Gjenstandsliste Blir oppdatert fortløpende når gjenstander blir skannet inn.(ps: viktig at en skanner inn lokasjonen først) Følgene informasjon blir lagt inn i listen når den oppdateres ID Den IDen gjenstanden har som er Unik. (Alle gjenstander har sin egen ID). Betegnelse Det som identifiserer gjenstanden, beskriver hva den gjenstanden er eks stol,maleri, pult osv. Museumsnr ID til Primus (Dokumentasjonsystemet) Nåværende Lokasjon Der gjenstanden er oppbevart i dette tidspunkt. ObjektID En annen ID som en gjenstand har. Prosjektdokumentasjon S 55

56 4.1.4 Søke Når en trykker på Søke knappen vil du få mulighet til å skanne inn eller skrive inn en strekkode for å søke på en gjenstanden eller lokasjon (3.4) Tekstfelt Skriv inn ID til gjenstanden du vil søke etter. Her kan man brukestrekkodeleser eller skrive ID inn manuelt. Hvis en skriver inn Id en manuelt er det viktig å avslutte med linjeskift(enter). 2. Tilbake knapp Denne knappen vil sende brukeren tilbake til startsiden. Søket vil bli tømt. Når en har søkt på en gyldig gjenstand eller lokasjon vil en få opp følgende bilde(3.5) Fant Dette tekstfeltet vil vise deg hvor mange objekter som ble funnet ved søket ditt. Prosjektdokumentasjon S 56

57 4. Gjenstandliste Etter et søk vil treffene vises opp i en liste, på denne listen vil du få følgene informasjon: ID Den IDen gjenstanden har som er Unik. (Alle gjenstander har sin egen ID). Betegnelse Det som identifiserer gjenstanden, beskriver hva den gjenstanden er eks stol,maleri, pult osv. Museumsnr ID til Primus (Dokumentasjonsystemet) Nåværende Lokasjon Der gjenstanden er oppbevart i dette tidspunkt. ObjektID En annen ID som en gjenstand har. 5. Vis hendelse Når du trykker på denne knappen vil den vise en liste med alle hendelser som har hendt med en gjenstand. Du vil få opp ett lignende bilde når Vis hendelse trykkes 6. Hendelse Liste Denne listen vil liste opp følgende informasjon Hendelse Forteller hva som har blitt gjort med en gjenstand Til lokasjon Forteller hvor en gjenstand ble flyttet til Dato Viser dato og tid når en hendelse fant sted Hjelp Her vil du få opp en forenklet bruksanvisning. Prosjektdokumentasjon S 57

58 4.2 Forprosjekt Presentasjon: Tittel: NILS Mobil Oppgave: Utvikle en løsning hvor det skal benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte løsning til logistikk og prosesssystemet NILS Periode: 5. januar 2011 til 31. mai 2011 Prosjektgruppe: 3 Prosjektmedlemmer: Rune Sandersen, Khai Quang Nguyen og Hafsteinn Thor Ingason Veileder: Geir Skjevling Oppdragsgiver: Goodtech Kontaktpersoner: Øystein Myhre, Harald Pedersen Sammendrag: NILS-Mobil er et hovedprosjekt for IT studenter ved Høsgskolen i Oslo. Goodtech har sammen med Nasjonalmuseet utviklet logistikksystemet «Nasjonalmuseets Interne Logistikk System», for å holde kontroll med hvor gjenstander befinner seg, hvilken prosess de til enhver tid er i og hvilke hendelser de har vært med på. Oppgaven vår er å utvikle en løsning hvor det skal benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte løsning. Vi gjør dette ved å utvikle en interaktiv webapplikasjon optimalisert for nettlesere i smarttelefoner. Dagens Situasjon: Goodtech har fra før laget en løsning for nasjonalmuseet, NILS(Nasjonalmuseets Interne Logistikk System) for å holde kontroll med hvor gjenstander er, hvilken prosess de er i, og hvilke hendelser de har vært med på. Hovedhensikten med NILS er at det skal holde rede på hvor gjenstander er til envær tid, dette gir Nasjonalmuseet oversikt over logistikkflyt og lokasjon for sine gjenstander. Systemet er hendelsesbasert og bygd opp rundt problemstillinger som «Hva har skjedd med hvilke gjenstander, når, og hvem gjorde det». NILS ble oprinnelig brukt for store flyttinger og er skreddersydd for masse-registrering i denne typen prosjekter. I senere tid har det dukket opp nye behov for kontroll over mindre flyttinger, og det er et ønske om et system som gjør dette arbeidet lettere, ved bruken av mobile enheter istedenfor PCer. Oppdragsgiver: Kunden er Nasjonalmuseet. Goodtech er vår oppdragsgiver og vil vedlikeholde og videreutvikle systemet etter levering. Om Goodtech Goodtech ASA er et norsk teknologi- og ingeniørkonsern som er notert på Oslo Børs. Prosjektdokumentasjon S 58

59 Selskapet leverer løsninger til industri og offentlig forvaltning, miljøprosjekter innenfor vann, avløp og energigjenvinning, samt tilhørende produkter og produktteknologier. Selskapet er representert med kontorer i flere geografiske regioner i Norden og Tyskland. Konsernet representerer flere internasjonale produsenter og deres produkter i det nordiske markedet. Goodtech har over 1000 ansatte hvor hovedtyngden av de ansatte er ingeniører og tekniske spesialister som gir konsernet en betydelig gjennomføringsevne i sine prosjekter. Om nasjonalmuseet Nasjonalmuseet samler og bevarer, stiller ut og formidler landets mest omfattende samlinger av kunst, arkitektur og design. Museet viser faste utstillinger med verk fra egen samling og skiftende utstillinger med innlånte og egne verk. Museets visningssteder i Oslo er Nasjonalgalleriet, Museet for samtidskunst, Nasjonalmuseet Arkitektur og Kunstindustrimuseet. Utstillingsprogrammet omfatter også vandreutstillinger i inn- og utland. Eksisterende Løsning: NILS-kjernen er den grunnleggende dataprogramvaren og er baser på en industrialisert standard for logistikk og prosesstyring, kjernen består av en database, som lagrer hva som skjer med hvilke gjenstander, et serverprogram med et Java-API og en klient som kjører lokalt på brukerens maskin. NILS klienten er et program som kjører på brukerens datamaskin og brukes til å identifisere gjenstander, og å registrere hva som skjer med dem. Hendelser som NILS kan håndtere er inventering og plassering. Klienten kobler seg opp til NILS-Tjeneren gjennom en portal. Tjeneren er der logikken relatert til databseendringer ligger. Løsningen benytter seg av strekkoder, der alle relevante gjenstander har en strekkode forbundet med seg. Ved å registrere endring av lokasjon til gjenstander med strekkoder får man oversikt over hvor gjenstander er nå, og hvor de har vært tidligere. Teknisk informasjon: Klienten og tjeneren er skrevet i Java. Det er en 3 lags løsning bygd opp av Model View og Controller. Rammeverket brukt i NILS er Spring MVC. Spring MVC kan brukes i alle Java applikasjoner, og det er også extensions for bygging av webapplikasjoner med Java EE platformen, gruppen kommer til å utvikle webapplikasjonens funksjonalitet med bruk av Spring MVC, og på denne måten få erfaring med et mye brukt rammeverk og samtidig utvikle noe som lett kan brukes med det eksisterende NILS systemet. Illustrasjon av typisk MVC arkitektur. Prosjektdokumentasjon S 59

60 Arkitektur skisse av NILS(denne er veldig simpel, jeg kunne ha laget noe tilsvarende jsp arkitekturskissen lenger nede men vet ikke hvor detaljert det bør være, kunne skrevet mer om spring mvc også) Mål og rammebetingelser Mål: Målet med oppgaven er å utvikle en løsning hvor det skal benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte løsning. Løsningen vi har valgt for oppgaven har vi kommet frem til gjennom analysering av behov, dialog med brukere, beskrivelse av bruks-eksempler og kartlegging og valg av teknologisk løsning maskinvare og arkitektur. Rammebetingelser: Applikasjonen skal lages i Java Vi kommer til å utvikle webapplikasjonen i Java, ved bruk av JavaServer Pages samt teknologier med åpen kildekode NILS har et Java-basert klient-api som fortrinnsvis skal benyttes, men om dette ikke er hensiktsmessig, kan man kommunisere over HTTP med kjernesystemet. NILS systemet har en tjener som snakker med databasen, vi kommer til å benytte oss av samme tjener. Strekkoder benyttes som informasjonsbærer, dette betyr at informasjonen fra strekkoden bestemmer hvilken lokasjon man er på, og hvilken gjenstand det dreier seg om. Alle gjenstander brukt i NILS har sin egen strekkode, og alle lokasjoner er strekkodemerket. Vi vil benytte oss av åpne standarder og åpen kildekode i størst mulig grad Goodtech s infrastruktur for systemutvikling vil benyttes. Sentrale verktøy er: Scrum, Maven, Subversion, Hudson og Artifactory Prosjektdokumentasjon S 60

61 Metodikk: Under utvikling av systemet bruker vi Scrum, en smidig prosjektmetodikk. Smidig er en fellesbetegnelse på prosjektarbeidsmetoder med fokus på kundenes skiftende behov, og med krav om fortløpende produksjon av løsninger som fungerer. Scrum metoden går kort ut på at man begynner med en kort liste av ferdige krav og tilpasser denne listen med behov underveis. Grunnlaget for utvikling av IT-funksjoner med scrum er user-stories, de som skal bruke det nye systemet beskriver sine behov, og disse ender opp i konkrete utviklingsoppgaver. Løsninger /alternativer: Vi kom tidlig i prosjektet frem til to alternativer til løsning av oppgaven, disse var en Web- Applikasjon eller en Android applikasjon. Webapplikasjon med JSP: Web-applikasjon utviklet med JSP(Java Server Pages): JSP brukes for å utvikle interaktive web sider med Java og er en alternativ løsning for NILS- Mobil. JSP tar bruk av MVC arkitekturen(model View Controller). Dette fungerer veldig overfladisk ved at applikasjonen er kontrollert av en sentral controller. Controlleren delegerer requests fra nettleseren til passende request handler. Brukeren vil benytte seg av webappen for bruk av NILS gjennom nettleseren på mobilen. Klient på Android telefoner: Den lokale applikasjonen utvikles i Java og vil snakke med en webservice som gjør arbeidet med å snakke med NILS sin eksisterende server-applikasjon. Denne løsningen er helt avhengig av at koblingen mellom Android applikasjonen og Webserveren fungerer bra. Viktige punkter for vår løsning er at den i tilegg til å tilfredsstille de funksjonelle kravene må være tilgjengelig, ha intuitivt grensesnitt, og være responsiv. Prosjektdokumentasjon S 61

62 Tilgjengelighet: En lokal android applikasjon vil ikke være mer tilgjengelig en en ren webapplikasjon da android appen fortsatt må koble seg til en webservice. Lokale klienter har flere begrensninger en web-applikasjoner fordi man må ha den fysiske enheten applikasjonen er installert på for å benytte seg av den lokale klienten. Web applikasjoner er brukbare der man har en nettleser og vinner derfor når det kommer til tilgjengelighet, spesielt med tanke på html5 som også gir mulighet for offline bruk. Grensesnitt: Det er forskjeller på GUI verktøy tilgjengelig for Android applikasjoner og Web-Applikasjoner, men hver av disse har utviklet seg nok til at begge kan gi en rik brukeropplevelse. Så selv om grensesnittet er viktig er det ikke faktoren som bestemmer om vi går for en Web- Applikasjon eller Android applikasjon Brukervennelighet, gjør applikasjonen det som trengs(kravene): Funksjonaliteten til en Web-Applikasjon vil være begrenset med tanke på at det ikke er mulig å manipulere enheten som blir brukt, eller oprette et grensesnitt mot strekkodeleseren, men grunnfunksjonaliteten er fortsatt tilstede da alle strekkodelesere er konfigurert til å gi ut strekkoden i det området som er merket på skjermen, på samme måte som tastetrykk fra et keyboard. En Android applikasjon ville vært mer brukervennelig med tanke på dette, men innebærer også at man er låst til Android og de strekkodeleserene interfacet er satt opp for, mens en web applikasjon vil fungere så lenge strekkoden blir lest, eller skrevet, inn i en tekstboks. Det er muligheter for å automatisere merking av tekstbokser og automatasjon ved hjelp av feks JavaScript i en web-applikasjon, så selv om Android vinner på brukervennelighet mener vi at en webapplikasjon er det beste alternativet med tanke på platform/hardware uavhengighet Responsitivitet: De fleste lokale applikasjoner er mer responsive en webapplikasjoner(avhengig av hardware på enheten), men med dagens utbredelse av relativt høy båndbredde tror vi ikke responsiviteten til web applikasjonen kommer til å være et problem. Android applikasjonen ville likevel vært avhengig av en webservice på dette området så hastigheten på nettverket ville fortsatt hatt mye å si. I tilegg til argumentene ovenfor satt vi opp en liste med punkter for eller imot de to løsningene for å komme frem til en beslutning. Prosjektdokumentasjon S 62

63 Poeng rangeres Krav/egenskap Webapplikasjon Poeng Android Poeng Aksessering og tilgjengelighet Installasjon og oppdatering av software Arbeidsfordeling Bruk av eksisterende API Web applikasjoner kan bli aksessert fra alle enheter som har tilgang til internett. Hvis man har tilgang til en PC, telefon eller tablet vil man kunne bruke applikasjonen Oppdatering av webapplikasjonen skjer uten at brukere må installere eller laste ned noe. Webapplikasjonen kan oppdateres uten å distribuere eller installere software på klienter. Arbeid blir tatt hånd om av webapplikasjonen(utenom javascript som kjører lokalt) Ved utvikling av webapplikasjon kan vi gjennbruke NILS API'et Brukervennelighet Ikke mulig å manipulere enheten som blir brukt, eller oprette et grensesnitt mot strekkodeleseren, men grunnfunksjonaliteten er fortsatt tilstede Grensesnitt Det er forskjeller på GUI verktøy tilgjengelig for Android applikasjoner og Web- Applikasjoner, men 90 Platform og versjonsavhengighet. Nasjonalmuseet må forholde seg til android telefoner for brukere av NILS-Mobil. Hvis et interface skrives mot en strekkodeler blir man bundet til den hardwaren, man er også bundet til android mobiler fremover. 50 Oppdatering av software innebærer at brukere må laste ned klienten på nytt istedenfor at web applikasjonen forandrer seg(distribusjon). Applikasjoner må bli installert på hver enhet 0 En webservice vil ta seg av mesteparten av arbeidet, android applikasjonen må ta seg av http 0 Ved utvikling av android applikasjon kan vi fortsatt bruke NILS API'et for webservicen -60 Mer brukervennelig med tanke på dette, en android applikasjon vil ha full kontroll over oppførselen til mobilen og man kan derfor kontrollere enheten og opprette grensesnitt mot strekkodelesere Prosjektdokumentasjon S 63

64 Responsitivitet Sikkerhet hver av disse har utviklet seg nok til at begge kan gi en rik brukeropplevelse. GUI på android vil være helt tilpasset mobilen, dette kan muligens gi en litt bedre opplevelse Helt avhengig av nettverkshastighet, det er mulig at en webapplikasjon vil føles litt tregere en en ren android applikasjon Kryptering eller sikring på en annen måte må skje i begge tilfeller da informasjon må sendes over nett -10 De fleste lokale applikasjoner er mer responsive en webapplikasjoner(avhengig av hardware på enheten), men avhengigheten av å koble til en webservice gjør at dette ikke betyr mye, brukeren er fortsatt avhengig av nettverkshastigheten 0 0 Sum Prosjektdokumentasjon S 64

65 4.3 Prosjektskisse Dato/sted Høgskolen i Oslo, 3/ Prosjektgruppe Rune Sandersen, tlf Khai Quang Nguyen, tlf , s Hafsteinn Thor Ingason, tlf Oppdragsgiver Goodtech ASA, Per Krohgs vei 4, 1065 Oslo Tlf: (+47) Kontaktperson Harald Pedersen, tlf Beskrivelse av prosjektet Goodtech har sammen med Nasjonalmuseet utviklet et logistikk og prosess-system, Nasjonalmuseets Interne Logistikk System, et logistikksystem for å holde kontroll med hvor gjenstander befinner seg, hvilken prosess de til enhver tid er i og hvilke hendelser de har vært med på. Oppgaven vår går ut på å utvikle en løsning hvor det skal benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte løsning. Rammebetingelser og krav Applikasjonen skal lages i Java NILS har i dag et Java-basert klient-api som fortrinnsvis skal benyttes, men om dette ikke er hensiktsmessig, kan man kommunisere over HTTP med kjernesystemet. Strekkoder benyttes som informasjonsbærer. Vi skal benytte oss av åpne standarder og åpen kildekode i størst mulig grad Goodtech s infrastruktur for systemutvikling skal benyttes. Verktøy som skal brukes er: Scrum, Maven, Subversion, Hudson og Artifactory Aktuelle platformer: Android, J2ME og Windows Mobile. Om mulighetene åpner seg for Java på ios (iphone/ipad), vil dette også være en aktuell plattform. Prosjektdokumentasjon S 65

66 4.4 Kravspesifikasjon Innledning Hovedprosjektet utføres for Goodtech som en del av utdanningen ved Høgskolen i Oslo våren Tittel: NILS Mobil Oppgave: Utvikle en løsning hvor det skal benyttes mobile enheter for registrering og kontroll av gjenstander som et alternativ til dagens PC-baserte løsning til logistikk og prosess-systemet NILS Periode: 5. januar 2011 til 31. mai 2011Prosjektgruppe: 3 Prosjektmedlemmer: Rune Sandersen, Khai Quang Nguyen og Hafsteinn Thor Ingason Veileder:Geir Skjevling Oppdragsgiver: Goodtech Kontaktpersoner: Øystein Myhre, Harald Pedersen Bakgrunnen for prosjektet Goodtech har fra før laget en løsning for nasjonalmuseet, NILS (Nasjonalmuseets Interne Logistikk System) for å holde kontroll med hvor gjenstander er, hvilken prosess de er i, og hvilke hendelser de har vært med på. Hovedhensikten med NILS er at det skal holde rede på hvor gjenstander er til envær tid, dette gir Nasjonalmuseet oversikt over logistikkflyt og lokasjon for sine gjenstander. NILS ble oprinnelig brukt for store flyttinger og er skreddersydd for masse-registrering i denne typen prosjekter. I senere tid har det dukket opp nye behov for kontroll over mindre flyttinger, og det er et ønske om et system som gjør dette arbeidet lettere, ved bruk av mobile enheter istedenfor PCer. Om goodtech: Goodtech ASA er et norsk teknologi- og ingeniørkonsern som er notert på Oslo Børs. Selskapet leverer løsninger til industri og offentlig forvaltning, miljøprosjekter innenfor vann, avløp og energigjenvinning, samt tilhørende produkter og produktteknologier. Mål for oppgaven Vårt mål er å lage et mobilt logistikk og prosess-system for registrering og kontroll av hvor gjenstander befinner seg. Systemet kommer til å jobbe side om side med det eksisterende NILS systemet og tilby logistikkstyring via mobile enheter gjennom en webapplikasjon som et alternativ til dagens PC-Baserte løsning. Prosjektdokumentasjon S 66

67 Forord Dette dokumentet beskriver kravene til systemet og hva systemet skal gjøre. Dokumentet beskriver både funksjonelle og ikke funksjonelle krav, samt rammebetingelser. Kravspesifikasjonen er basert på funksjonelle og praktiske krav som kom i begynnelsen av prosjektet,definert i form av User-Stories fra Nasjonalmuseet, samt tekniske krav. Systembeskrivelse Utvikling Under utvikling av systemet bruker vi Scrum, en smidig prosjektmetodikk. Smidig er en fellesbetegnelse på prosjektarbeidsmetoder med fokus på kundenes skiftende behov, og med krav om fortløpende produksjon av løsninger som fungerer. Scrum metoden går kort ut på at man begynner med en kort liste av ferdige krav og tilpasser denne listen med behov underveis. Grunnlaget for utvikling av IT-funksjoner med Scrum er User-stories, de som skal bruke det nye systemet beskriver sine behov, og disse ender opp i konkrete utviklingsoppgaver. User-Stories: Brukere skal kunne: Skanne gjenstander inn på lokasjon ved hjelp av strekkodeleser Plassere gjenstand på lokasjon uten strekkodeleser Bekrefte endring av lokasjon for gjenstander Fjerne eller legge til logistikkobjekter før bekreftelse av ny lokasjon Se hvor en gjenstand befant seg før den ble flyttet Søke opp gjenstander Se logistikk historikk over gjenstander som scannes eller søkes opp Søke etter gjenstander uten bruk av strekkodelesing Prosjektdokumentasjon S 67

68 Rammekrav i systemet Applikasjonen skal lages i Java. NILS har et Java-basert klient-api som fortrinnsvis skal benyttes, men om dette ikke er hensiktsmessig, kan vi kommunisere over HTTP med kjernesystemet. Vi vil benytte oss av åpne standarder og åpen kildekode Goodtech s infrastruktur for systemutvikling benyttes. Systemet skal kunne brukes på enheter med støtte for Bluetooth Ver. 1.2 med SPP eller HID profiler som i tillegg støtter nettlesere nevnt ovenfor Strekkoder benyttes som informasjonsbærer Designmønstre Eksisterende løsning NILS-kjernen er den grunnleggende dataprogramvaren og er basert på en industrialisert standard for logistikk og prosesstyring, kjernen består av en database, som lagrer hva som skjer med hvilke gjenstander, et serverprogram med et Java-API og en klient som kjører lokalt på brukerens maskin. NILS klienten er et program som kjører på brukerens datamaskin og brukes til å identifisere gjenstander, og å registrere hva som skjer med dem. Hendelser som NILS kan håndtere er inventering og plassering. Klienten kobler seg opp til NILS-Tjeneren gjennom en portal. Tjeneren er der logikken relatert til databseendringer ligger. Prosjektdokumentasjon S 68

69 Løsningen benytter seg av strekkoder, der alle relevante gjenstander er merket med en strekkode. Ved å registrere lokasjonen til gjenstander med strekkoder får man oversikt over hvor gjenstander er nå, og hvor de har vært tidligere. Gjenstander blir plassert på nye lokasjoner ved at den strekkodemerkede lokasjonen scannes først, så gjenstandene som skal inn på lokasjonen. Endringen av lokasjon og dermed ett nytt tilegg i historikken blir så lagret i databasen. Arkitektur skisse av NILS: Arkitektur for Nils-Mobil Spring kan brukes i alle Java applikasjoner, og det er extensions for bygging av webapplikasjoner med Java EE platformen, gruppen kommer til å utvikle webapplikasjonen med bruk av Spring MVC, og på denne måten få erfaring med et mye brukt rammeverk og samtidig utvikle noe som kan brukes med det eksisterende NILS systemet. Om MVC MVC er en måte å dele opp en applikasjon på. Hver del skal være uavhengig av de andre, MVC står for Model View Controller Views Views er for presentasjonen av applikasjonen, i vårt tilfelle Java Server Pages(JSP). De inneholder så lite logikk eller intelligens som det mulig for programmeringsspråket som blir brukt. I Spring MVC blir SPEL eller EL brukt istedenfor scriplets for å minimere kode i JSP sider. Controller En controller håndterer feedback fra brukeren og logikk spesifikt til applikasjonen. En controllers jobb er å motta input fra en bruker via user interfacet, prossessere informasjonen, kommunisere med modellen hvis nødvendig, og så sende outputen til brukeren. Vanligvis ved å populere en view med relevant kontekst. Prosjektdokumentasjon S 69

70 Model Model utfører business logic. Business logic refererer til det som er fundamelt for systemdesignet. For eksempel hvis en biblioteksapplikasjon var laget, ville logikken som forsikret at bibliotekskort eieren bare kunne låne opptil 5 bøker på en gang ligget i en del av Modellen. Modellen pleier også å kontrollere aksess til application storage, som feks CRUD (creating, updating and delation) på en database. Typisk MVC arkitektur: Spring MVC: Spring MVC inkluderer de fleste grunnleggende konsepter som andre MVC rammeverk. Requests kommer inn via Front Controlleren, som ikke gjør noe web eller business logic men heller delegerer til vanlige java objekter kalt Controllers, hvor det ordentlige arbeidet blir gjort, enten ved at allt gjøres i controlleren eller med bruk av hjelpeklasser. Når arbeidet er gjort er ansvaret til Views å presentere output I et rett format, I vårt tilfelle JSP s. Hvilken Controller og hvilke metoder i controlleren som håndterer en request, og hvilken view som rendrer responsen er bestemt av handler mapping med annoteringer i controllerne eller eksplisitt i xml filen. Typisk hendelsesforløp i en webapp som bruker Spring MVC Klienten spør etter en ressurs i webapplikasjonen ved å gjøre en handling i presentasjonslaget. Spring Front Controlleren, som er implementert som en servlet, intercepter Requesten og vil prøve å finne ut passende Handler Mapping. Handler Mapping er brukt til å mappe en request fra Klienten til dens Controller ved å browse over de forskjellige controllerne definert i Konfigurasjonsfilen eller via Med hjelp av Handler Adapters vil Dispatcher Servleten delegere requesten til rett Controller. Prosjektdokumentasjon S 70

71 Controlleren prosesseserer klientens request og returner ett View populert med det som ble spurt etter av brukeren, vanligvis i form av et ModelAndView objekt. MAV objektet sendes tibake til Front Controlleren, det valgte viewet blir rendret til klienten. Spring MVC Arkitektur: Krav Design og brukervennlighet Systemet skal være selvforklarende så langt det er mulig, forutsatt at brukerne har grunnleggende kjennskaper til de begreper som blir brukt. Designet av webapplikasjonen skal være optimalisert for smarttelefoner. Kode og vedlikehold Subversion vil bli brukt for versjonkontroll. Maven brukes for bygging av prosjekter som skal sjekkes inn i Subversion. vi bruker UTF-8 som standard tegnsett. Gruppen vil bruke Spring Rammeverket for utvikling av applikasjonen. Gruppen vil benytte seg av eksisterende NILS API. Prosjektet skal baseres på MVC arkitekturen Prosjektdokumentasjon S 71