Hovedprosjekt i data ved HIOA våren 2012

Transkript

1 Hovedprosjekt i data ved HIOA våren 2012 Informasjonsplattform for butikkdata Gruppe 10 Magnus Øren S Joakim Sjögren S Morten Sandberg S Espen Tidemand-Fossum s Magnus Helgestad Nerland S161865

2 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: Hovedprosjekt HOVEDPROSJEKTETS TITTEL Informasjonsplattform for butikkdata DATO 30/ ANTALL SIDER / BILAG 109 / 13 PROSJEKTDELTAKERE Joakim Sjögren, s Magnus Øren, s Morten Sandberg, s Espen Tidemand-Fossum, s Magnus Helgestad Nerland, s INTERN VEILEDER Weiqin Chen OPPDRAGSGIVER Creuna Norge AS KONTAKTPERSON Tore Urnes SAMMENDRAG Vi har laget en informasjonsplattform for butikkdata der vi henter informasjonen fra XML-filer. Dataen inneholder f.eks. åpningstider, adresse og tjenester butikken kan tilby. For å presentere løsningen har vi laget en webside tilpasset for håndholdte enheter. 3 STIKKORD Domenemodell-basert XML-Parsing Mobil webside

3 Forord Dette dokumentet er prosjektrapporten for hovedprosjektet til gruppe 10 ved HIOA våren Dokumentet inneholder dokumentasjon om arbeidet vi har gjort for Creuna Norge AS. Her finner man informasjon om systemutviklingsprosessen, hvordan programmet vi har laget fungerer, og oppbyggingen av programmet. Dokumentet består av fire hoveddeler: prosessrapport, produktrapport og brukerveiledning for informasjonsplattform og brukerveiledning for mobil webside. Prosjekt rapporten er ment for sensor, veileder og eventuelt de som skal drifte systemet. Andre personer med interesse for systemutvikling kan også ha utbytte av dokumentet. Dokumentet er optimalisert for lesing i papirformat, men kan også leses digitalt på gruppens nettside: Vi vil gjerne takke Creuna Norge AS for all støtte og hjelp vi har fått under prosjektet. Spesielt vil vi takke våre veiledere ved Creuna, Tore Urnes, Øystein Eriksen og Rannveig Aarnes. Videre vil vi også takke Weiqin Chen, veilederen vår ved HIOA. Skøyen, 24. mai 2012 Joakim Sjögren Magnus Øren Morten Sandberg Espen Tidemand-Fossum Magnus Helgestad Nerland

4 Innhold Del 1 Prosessrapport Del 2 Produktrapport Del 3 Brukerveiledning for informasjonsplattform Del 4 Brukerveiledning for mobil webside

5 Prosessrapport

6 Prosessrapport gruppe 10 Våren 2012 Forord Dette er prosessrapporten for prosjektet informasjonsplattform for butikkdata. Dokumentet beskriver hele systemutviklingsprosessen. Hensikten med arbeidet i dette prosjektet har vært å lage en informasjonsplattform for butikkdata som danner grunnlaget for produksjon av nye tjenester på web og mobil. Dette dokumentet er ment for sensor, veileder og eventuelt andre personer som kunne tenke seg å lese om systemutviklingsprosessen i prosjektet vårt. Rapporten er optimalisert for digital lesing, da den inneholder hyperlenker, men kan også leses i papirformat. 2

7 Prosessrapport gruppe 10 Våren 2012 Innholdsfortegnelse Forord Innledning Om Creuna Norge AS Om gruppen Dagens situasjon og visjon for ny løsning Mål og rammebetingelser Planlegging og metode Styringsdokumenter Fremdriftsplan Ukesrapporter Risikoplan Kravspesifikasjon Verktøy Dropbox Microsoft Visio Valg av utviklingsmetode Samarbeidet med oppdragsgiver Om utviklingsprosessen Generelt om scrum Fra krav til brukerhistorie til tasker Sprintmøter Den daglige scrum Taskens faser Akseptansetesting Forspill Planlegging Forberedelse Utvikling Første sprint Andre sprint Tredje sprint Fjerde sprint Testing Frislipping Resultat

8 Prosessrapport gruppe 10 Våren Oppnådde mål Visning av resultat Utfordringer under programmeringen Finne teknologien som var best til å parse XML» Sette opp arkitekturen Finne kunnskap om Entity Framework Code First Fremmednøkler ble satt til «null» Bruk av AutoMapper UnitTestingen log4net arkitektur Samarbeidet i gruppen Samarbeidet med veileder Kvalitet på prosjektet Kravspesifikasjonen og dens rolle Betydning av kravspesifikasjonen Endringer i kravspesifikasjonen Konklusjon Oppsummering Muligheter Hva kunne blitt gjort annerledes Tidsestimering Fordeling av oppgaver Dårlig definerte tasker Lite variasjon i tasker Kildehenvisning Vedlegg Fremdriftsplan Risikoplan Produkt backlogg Databasemodell Møtereferat 24.2 og Møtereferat 24.2(2)

9 Prosessrapport gruppe 10 Våren Innledning 1.1 Om Creuna Norge AS Creuna er et digitalt fullservice-byrå med 7 kontorer i Skandinavia med til sammen i overkant av 300 ansatte. I Norge har Creuna omlag 100 ansatte som holder til på Skøyen i Oslo. Creuna består av ca50 % kommunikasjon og 50 % teknologi. De tilbyr tjenester innenfor salg, markedsføring, merkevarebygging og kommunikasjon [1]. Bedriften har hatt kunder som trafikanten og skatteetaten. 1.2 Om gruppen Gruppen vår består av 5 studenter ved Ingeniørutdanningen ved Høgskolen i Oslo og Akershus. To av oss studerer Informasjonsteknologi, to studerer Anvendt Datateknologi og en Data Ingeniør. Vi har tidligere jobbet sammen innen andre fag ved HIOA og kjenner hverandre godt. Vi er mellom 22 og 25 år gamle. 1.3 Dagens situasjon og visjon for ny løsning Creuna har mye erfaring som leverandør av nettsider for dagligvarebransjen. Slike nettsider vil typisk inneholde informasjon om de forskjellige matbutikkene som kontrolleres av dagligvareaktøren. Det er vanlig at hver enkelt butikk presenteres med en egen nettside. Butikkinformasjon inkluderer åpningstider, gateadresse, kontaktdata, og en oversikt over hvilke tjenester som tilbys (tipping, bank i butikk, osv.). Nettsider for butikker genereres i stor grad automatisk. Butikkdata hentes fra en feed som eksporteres fra dagligvareaktørens grunndatasystem. Dataene lagres i løsningens Content Management System(CMS) som i sin tur genererer nettsider for butikkene. En stor ulempe med dagens løsning er at butikkdata i CMS-databasen vanskelig kan benyttes til nye tjenester. Derfor er det ønskelig at det blir utviklet en informasjonsplattform for butikkdata som tilbyr enkel tilgang til all butikkinformasjon. Tanken er at den nye informasjonsplattformen blir et slags integrasjonslag for nye tjenester basert på butikkdata. Plattformens underliggende database vil få data matet fra XML-filer, og skal lagre informasjonen på en slik måte at det er mulig å hente ut og bruke data på en enkel måte. For å demonstrere nytten av informasjonsplattformen, er en annen viktig oppgave å utvikle en tjeneste som tilbyr butikkdata via en mobil webside. Alle data for en gitt butikk må kunne hentes fra systemet, og en enkelt butikk må kunne spesifiseres på flere måter (for eksempel som butikk-id, butikknavn, etc.). Det må også være mulig å spørre systemet om alle butikker som tilfredsstiller et gitt kriterium (for eksempel alle butikker i en butikkjede, i en region, i nærheten av en lokasjon, som tilbyr en butikktjenste, etc.) Dersom tiden tillater det skal informasjonsplattformen utvides med butikkdata som ikke finnes i butikkregisterene. I første omgang er det snakk om enkelte butikktjenester og åpningstider for spesielle dager som supertorsdag, jul, påske, etc. Systemet vil derfor inneholde en master-database for slike data. Det vil være behov for et web-basert administrasjonsgrensesnitt for å legge inn og redigere nevnte butikkdata. 5

10 Prosessrapport gruppe 10 Våren Mål og rammebetingelser Resultatet av dette prosjektet skal være en informasjonsplattform for butikker som samler butikkinformasjon om ulike butikker. Butikkdata inkluderer åpningstider, adresse og hvilke tjenester butikkene tilbyr. Denne informasjonen skal kunne hentes ut og brukes i en mobil webside som skal finne informasjon om nærmeste butikk, alle butikker i en kjede og veibeskrivelse til butikken. Brukeren skal også få informasjon om hvor butikken befinner seg. Om tiden tillater det skal et administrasjonsgrensesnitt la de ansatte ved hver enkelt butikk redigere butikkinformasjon om sin butikk og oppdatere dette i databasen. Systemet skal Importere butikkdata fra feed og lagre i database Kvalitetssikre alt som legges i databasen Loggføre endringer i databasen Beregne GPS-lokasjon for butikker basert på adresse Kunne finne frem til nærmeste butikk og vise veien dit i en mobil webside Kunne legge til butikktjenester som ikke allerede ligger i databasen Kunne oppdatere/redigere butikkdata Videre i dette dokumentet skal vi dekke planleggingsprosessen og hvilke metoder vi har brukt for dette. Deretter skal vi ta for oss utviklingsprosessen, den delen av prosjektet der vi jobbet med selve programmeringen. Til slutt dekkes kravspesifikasjonen og dens rolle i prosjektet. 6

11 Prosessrapport gruppe 10 Våren Planlegging og metode God planlegging er viktig i et hvert prosjekt. Dette kapittelet presenterer først en oversikt over de forskjellige styringsdokumentene for prosjektet. Det gis også en overordnet gjennomgang av prosjektverktøy og motivasjon for valg av utviklingsmetode. 2.1 Styringsdokumenter Fremdriftsplan Fremdriftsplanen ble ferdigstilt i slutten av januar. Vi har prøvd å følge denne så godt som mulig, men da den ble laget såpass tidlig i prosjektet har noen av aktivitetene blitt fullført til andre tider enn estimert. Denne planen er også noe overordnet. Brukerhistoriene og sprintplanen er mer nøyaktig så disse har vært brukt i større grad. Fremdriftsplanen har allikevel vært et godt verktøy for å se en overordnet oversikt over aktiviteter og frister. For mer informasjon se vedlegg Ukesrapporter Vi har under hele prosjektet skrevet ukesrapporter med referat av arbeidet i uken som har gått, problemer vi har støtt på og eventuelle andre kommentarer som kan være aktuelle. Dette har vært vår form for dagbok og sammen med møterapportene har ukesrapporten vært et godt hjelpemiddel da vi hele tiden har kunnet gått tilbake å se på ting som har blitt vedtatt eller aktiviteter vi har jobbet med Risikoplan Risikoplanen er et dokument definerer problemer som kan oppstå underveis, konsekvensene av disse og hva vi kan gjøre for å hindre det. Vi har i løpet av prosjektet vært oppmerksom på mulige problemer slik at vi kan utføre de passende tiltakene for å forhindre eller håndtere dem. For mer informasjon se vedlegg Kravspesifikasjon Kravspesifikasjonen definerer hvilke krav oppdragsgiver stiller til systemet. Kravspesifikasjonen har vært et viktig dokument som har fungert som en kontrakt mellom oss og Creuna. Den har også fungert som en modell for hva systemet skal inneholde og utviklingen av productbackloggen til Scrumprosessen ble basert på punktene i kravspesifikasjonen. Kravspesifikasjonen vil beskrives i mer detalj i kapittel Verktøy Dropbox For håndtering av prosjektdokumenter, rapporter, modeller, o.l. besluttet vi å ta i bruk Dropbox. Dropbox er en web basert lagringsapplikasjon som lagrer filene man laster opp i en nettsky. Bruken av Dropbox har latt alle i gruppen ha tilgang til de forskjellige dokumentene vi har jobbet med til en hver tid. Ved å legge en fil i Dropbox mappen til gruppen blir filen lagt inn i mappen på alle maskinene våres. Nettsky-basert lagring kombinert med automatisk kopiering til hver deltagers maskin var en god løsning for å unngå tap av data. 7

12 Prosessrapport gruppe 10 Våren Microsoft Visio 2010 For all modellering har vi tatt i bruk Microsoft Visio Særlig i planleggingsfasen var dette et mye brukt verktøy. Ting som databasemodeller, flytdiagram og klassediagram har vi laget med Visio. 2.3 Valg av utviklingsmetode Vi bestemte oss for at det vil være gunstig å ta i bruk systemutviklingsrammeverket Scrum i prosjektet vårt. Vi gjorde dette fordi det er et agilt rammeverk med god støtte for å jobbe inkrementelt og iterativt. Scrum er også tilpasningsdyktig og passet dermed godt for oss som hadde liten erfaring med slike typer prosjektarbeid noe som gjorde det sannsynlig at det kom til å bli en del forandringer underveis. I tillegg valgte vi å ta i bruk Scrum fordi Creuna i stor grad bruker denne metoden. Dette gjorde at vi fikk veiledning av Creuna og at samarbeid mellom gruppen vår og bedriften var god. I kombinasjon med Scrum brukte vi elementer av Extreme Programming(XP). I likhet med Scrum er XP et agilt rammeverk og det er derfor enkelt å kombinere de to rammeverkene. Egenskapene vi brukte fra XP var først og fremst felles eierskap og parprogrammering. Med felles eierskap får gruppens medlemmer følelsen av eierskap over hele prosjektet. Hvis noen finner feil i kode så kan medlemmet endre det. Dette er en type eierskap som krever at alle tar ansvar. Parprogrammering gir oss veldig mye i starten av utviklingen. Vi har alle i gruppen litt forskjellig erfaring og kompetanse og med parprogrammering vil det jevne seg ut siden vi kan lære mye av hverandre. Vi fikk informasjon om rammeverkene fra veilederen vår på Creuna og fra boken Systemutvikling: Applikasjoner og databaser(hasle)[2]. 2.4 Samarbeidet med oppdragsgiver Vi har hatt et veldig tett samarbeid med Creuna under prosjektet. Vi fikk en egen arbeidsplass med bærbare maskiner hos Creuna og har derfor hatt muligheten til å jobbe i Creunas lokaler 3-4 dager i uken. Videre har vi fått god oppfølging av de ansatte i bedriften, med møter opp til en gang i uken. Vi har også hatt workshops sammen Creunas ansatte hvor vi har fått jobbet med ting som utviklingsrammeverk og kravspesifikasjon. Tore Urnes har vært vår kontaktperson hos Creuna. Han har gitt oss veiledning og evaluert arbeidet vårt under hele systemutviklingsprosessen. Før hver sprint har vi gjennom sprint planlegging brutt ned user stories i tasker(aktiviteter/oppgaver) og benyttet planning poker metoden for å estimere tidsbruk for hver task. Ved slutten av hver sprint har vi hatt en sprint review hvor vi har presentert sprint-leveransen for Creuna og deretter en sprint retrospective hvor man drøfter hva som fungerte og hva som fungerte mindre bra med sprinten. Scrum prosessen vil bli dekket i større grad i kapittel 3. 8

13 Prosessrapport gruppe 10 Våren Om utviklingsprosessen Fra og med 3. januar hadde vi som nevnt et fast arbeidsområde hos Creuna, med egne pulter og bærbare Dell maskiner. Dette har gjort at vi har tilbrakt nesten all tiden vår i løpet av prosjektet i Creuna sine lokaler. Dette har også gjort at vi til en hver tid har jobbet i nærheten av hverandre som har økt kommunikasjonen og samarbeidet gruppen. 3.1 Generelt om Scrum Fra krav til brukerhistorie til tasker I Scrum benyttes ikke kravspesifikasjon slik det gjøres i mange av de andre utviklingsmetodene. Når kravspesifikasjon er ferdigskrevet og fastslått gjøres kravene om til brukerhistorier og settes inn i en Product backlog. For mer informasjon se vedlegg 7.3. En brukerhistorie er bygget opp på følgende måte: Som <rolle>, Vil jeg at <mål, ønske>, Slik at <nytte>. Brukerhistorier ser løsningen fra brukerens perspektiv. Hver brukerhistorie skal beskrive en funksjonalitet som skaper verdi for kunden, og et sett med akseptansetest-kriterier vil normalt være assosiert med hver historie. Etter en nøye gjennomgang av kravspesifikasjonen og dialog med diverse Creuna-ansatte, endte vi opp med åtte brukerhistorier i Product backlog som partene var enige om at dekket kravene på en god måte. Scrum deler utviklingsprosessen opp i såkalte sprinter, hvor hver sprint har en varighet på et antall uker typisk to, tre, eller fire uker. For hver sprint velger kunden ut de høyest prioriterte brukerhistoriene fra Product backlog. De utvalgte brukerhistoriene danner grunnlag for sprintplanleggingen. Under sprint-planning samles teamet og hver brukerhistorie analyseres og diskuteres i plenum. Kunden trekkes typisk inn for å avklare eventuelle spørsmål. Brukerhistorer brytes deretter ned i én eller flere tasker. Tasker er oppgaver som én eller et par utviklere kan løse innenfor et tidsrom på noen timer eller noen få dager.. De taskene som opprettes skal dekke alle akseptansekriterium for valgte brukerhistorier. Eksempel på en task: Lage en database Opprette nødvendige klasser for validering Når en brukerhistorie er brutt ned i sine enkelte tasker, starter jobben med å estimere hver task. Det er viktig at teamet oppnår enighet om de estimatene og Scrum tilbyr en metode, Planning poker, for å sikre dette. Se delkapittel nedenfor for en beskrivelse av Planning poker-prosessen Sprintmøter På slutten av hver sprint hadde vi sprint review hvor vi presenterte sprint leveransen, det vil si ferdig implementerte brukerhistorier. Målet med møtet var å demonstrere for kunden at vi har tilfredsstilt akseptansekriteriene til de implementerte brukerhistoriene. 9

14 Prosessrapport gruppe 10 Våren Den daglige scrum Under sprinten jobbes det med å implementere de forskjellige taskene. Utviklerne i teamet står relativt fritt til å velge passende tasker å jobbe med. For å holde teamet (og scrum master) oppdatert om fremdriften, ble det hver dag klokken avholdt såkalte daily scrum-møter (også kalt standupmøter). Møtene blir holdt stående for å unngå at de skal dra ut i tid, og hvert gruppemedlem forteller hva de gjorde dagen før, hva de skal gjøre idag og hva som eventuelt hindrer dem i å få utført oppgavene. Vi skriver også opp hvor mange timer vi tror gjenstår av de forskjellige taskene og lager et burndown diagram som illustrer timer med programmering som gjenstår Taskens faser Hver av taskene i en gitt sprint befant seg til en hver tid i en av fire faser: Ready, In Progress, Testing og Complete. Umiddelbart etter en sprintplanlegging ville alle sprintens tasker befinne seg i fasen Ready. Dette betyr at tasken er klar for at man kan begynne med den. In Progress betyr at man holder på å jobbe med tasken, og i Testing har man ferdigstilt tasken, men ikke testet den enda. Testing utføres normal av et annet team-medlem enn vedkommende som implementerte tasken. Dersom testingen går bra er tasken ferdigstilt. En ferdigstilt task blir satt under Complete. Dersom testing ikke forløper tilfredsstillende, går tasken tilbake til In progress. Figur 1. Scrumboard som viser statusen til taskene På en av veggene i arbeidsområdet vårt på Creuna festet vi fire plakater for hver fase og flyttet Post-it lapper med hver task på ettersom hvilken fase tasken befant seg i. Dette ga oss en god oversikt over hva vi hadde gjort og gjenstående arbeid Akseptansetesting Akseptansetesting ble utført i slutten av hver sprint for å teste om alle akseptansekriteriene hadde blitt oppfylt. Dette ble gjort for å kvalitetssikre systemet og for at systemet skulle stå til kundens forventninger. 10

15 Prosessrapport gruppe 10 Våren Forspill Planlegging Planleggingsfasen av prosjektet bestod av å sette forventninger til prosjektet, etablere en visjon og begynne med prototyping og testdesign. Mye av planleggingsfasen gikk med på å få en konsensus mellom oss og Creuna om hvordan plattformen skulle bli formet. Vi hadde et møte om hvilke felter i XML dokumentene som skulle føres inn i databasen og lagde deretter en foreløpig databasemodell. Ved et møte med Creuna presenterte vi datamodellen og diskuterte forandringer ved modellen. Det var viktig for oss at databasemodellen ble laget på en riktig måte da den ville være modellen vi jobbet utfra da vi laget databasen. Etter flere runder fikk vi frem den endelige databasemodellen. For mer informasjon se vedlegg 8.4. Den neste delen av planleggingsfasen bestod av å lage i alt 8 brukerhistorier som vi senere kunne gjøre om til konkrete tasks. Vi så for oss at dataflyten i det programmet vi skal lage skal se slik ut: Xml feed Dataimport Mobil webside Tjenestelag Domenemodell CRUD Database Figur 2, Dataflyt i systemet Vi laget også modeller for lagdelingen og klassediagram, verktøy som hjalp oss med å visualisere dataflyten, klassene og sammenhengen mellom de forskjellige delene av plattformen. 11

16 Prosessrapport gruppe 10 Våren Forberedelse Vi ble enige med Creuna om en overordnet fremdriftsplan og at sprinter på 2 uker vil passe bra for dette prosjektet. Med Scrum periode på 8 uker tilsvarer dette 4 sprinter. Ut fra læringshensyn ønsket vi å få til så mange sprinter som mulig, men 1-ukes sprinter ville blitt for korte. Videre anslo vi at hvert av gruppemedlemmene ville bruke 12 timer i uken på programmering. Dette tilsvarer 120 timer med utvikling per sprint og 480 timer totalt. For at alle på gruppen skal få erfaring med scrum og systemutvikling vedtok vi at vi skulle ha forskjellig scrum master for hver sprint. Se møterapport i vedlegg 7.5. I denne fasen prioriterte vi også alle brukerhistoriene. Fem av dem ble satt til prioritet en, hvilket innebærer at dette må gjøres ferdig. To stykker ble satt til prioritet to og en til prioritet tre. Prototyping Under planleggingsfasen var det viktig for oss å komme i gang med en tidlig form for prototyping slik at vi fikk prøvd oss fram på de viktigste teknologiområdene. Det var da naturlig å starte med XMLparsingen. Etter å ha kommet til enighet med Creuna om hvilke felter vi skulle hente ut ifra XMLdokumentene begynte vi å lese om forskjellige XML-parseteknologier. Vi var innom flere parseverktøy før vi kom fram til et som fungerte bra for å hente ut kun spesifikke data. Etter et par uker med prøving og feiling hadde vi en prototype som leste ut alle valgte attributter fra ett XML dokument. Det neste steget var å prøve seg fram med Entity framework code first-rammeverket som Creuna ønsket av vi skulle benytte for å realisere domenemodell og database for informasjonsplattformen. EF:CF er ny teknologi med få eksempler og lite dokumentasjon tilgjengelig. Vi gikk til innkjøp av en bok, Programming Entity Framework Code First(Lerman, Miller)[3], som viste seg å hjelpe oss litt på vei med å få en grunnforståelse. Videre fant vi en veldig bra forelesning på youtube av Sergey Barskiy som tok for seg Entity Framework Code First[4]. Vi hadde jobbet en del med å lage et utkast til ER-modell for databasen med Visio. Med utgangspunkt i den startet vi med å lage domeneklasser i Entity Framework. Den største utfordringen vi møtte skulle vise seg å være noe så trivielt som å få databasen til å bygges. Vi lurte lenge på om det var feil med connection-stringen eller om det var relasjonsfeil mellom domeneklassene som var problemet. Men vi kom etterhvert fram til en løsning og fikk opp en lokal database som speilet vår ER-modell. I tillegg satte vi oss inn i jquery Mobile rammeverket og Google Maps API. Slik at vi hadde et godt grunnlag når vi skulle starte programmeringen av websiden. På denne måten hadde vi også en god oversikt over muligheter og begrensninger i de to teknologiene. Allerede før sprint 1 var i gang hadde vi kommet ganske langt med vår prototyping som dannet et viktig grunnlag for det videre arbeidet i prosjektet. Planning poker En viktig motivasjon for å velge et godt systemutviklingsrammeverk er at det er et viktig verktøy for planlegging av tidsbruk, arbeidsmengde og fremdriften i prosjektet. Scrum tilbyr metoden Planning poker for å estimere hvor mye tid vi kom til å bruke på de forskjellige taskene i hver sprint. Planning poker forsøker å sikre at hver utvikler estimerer uavhengig av de andre samtidig som man jobber seg mot en konsensus i teamet for hvert task-estimat. Hver utvikler for utdelt åtte spillekort hvor hvert kort viser ett av de åtte første Fibonacci verdiene:0,1,2,3,5,8,13 og 21. Tallene representerer timer med programmering[5]. 12

17 Prosessrapport gruppe 10 Våren 2012 En estimeringsrunde begynner med at hver utvikler velger det kortet som best antall timer som han eller hun antar at det vil ta å implementere den valgte tasken. Når alle hadde lagt ned et kort hver, snudde alle kortene. Typisk ville det sprik i estimatene og de som hadde høyest og lavest estimater begrunnet sine valg. Deretter kjørte vi en ny runde. Etter to runder var estimatspriket typisk ganske lite, og vi endte som oftest opp med å velge det høyeste estimatet som det endelige. Dette hjalp oss å lage estimater som alle på gruppen kunne være enige om. Vi måtte tenke på faktorer som parprogrammering (dobbelt så mange timer), feilsøking og testing av taskene når vi estimerte tidsforbruket. 3.3 Utvikling Første sprint Før vi begynte med sprinten vedtok vi på et møte at vi kom til å jobbe med brukerhistorie 1 i sprint 1. Som systemeier, Vil jeg at butikkdata som kommer fra NorgesGruppen skal legges inn i databasen, Slik at databasen reflekterer oppdateringer i NorgesGruppens butikkregister. Denne brukerhistorien var svært viktig del av oppgaven og var logisk for oss å begynne med. Vi delte opp brukerhistorien i til sammen 8 tasker som vi skulle jobbe med i sprint 1. Det første som måtte gjøres var å sette opp arkitektur. Creuna var direkte involvert i prosessen, da det ble det gitt en kjapp innføring i hva som var god arkitektur. Da det var klart måtte prosjektet gjøres tilgjengelig for alle gruppemedlemmene. Det ble da satt opp en Team Foundation Server. Fra prototypefasen hadde vi et fungerende EF:CF-program som håndterte innsetting av data til database. Vi hadde også et program som hentet dataen fra XML-filene. Denne dataen ble lagt i et objekt. For så å bli sendt til innsettingsprogrammet. Det som det da var behov for å gjøre var å tilpasse programmet til ER-modellen. Sørge for at datamodellene representerte entitetene i ER-modellen på riktig måte. Endelig databasemodell var ikke klar i denne sprinten, men den var god nok til å brukes. I prototypefasen ble databasen opprettet lokalt på disk. Det var allerede opprettet en database på Creunas server vi kunne bruke, men valgte heller å teste forskjellige fremgangsmåter lokalt. I sprinten måtte vi sørge for at vi hadde mulighetene til å gjennomgå de sammen operasjonene på databasen som vi kunne gjøre lokalt. For eksempel slette, opprette og endre databasen. I innsettingsprogrammet ble det opprettet finn og opprett metoder for alle tabellene. Dessuten ble det gjort rede for oppdateringslogikk. Hovedmålet i denne sprinten var å kunne fylle databasen med data fra XML-filene uavhengig av kvaliteten på dataen. Det ble også lagt mye vekt på testing. Det ble laget tester for alle metodene i programmet. Spesielt i XML-parser klassen, hvor vi måtte sørge for at metodene hentet ut korrekt data. 13

18 Prosessrapport gruppe 10 Våren 2012 Den største grunnen til at vi klarte denne sprinten var at vi hadde dannet et godt grunnlag av kunnskap etter arbeidet med prototyping Andre sprint I sprint to valgte vi å ta inn brukerhistorien om validering av dataen som parses. Vi valgte også å ta med en av de mindre brukerhistoriene. Sprint to ble derfor bestående av følgende: Som systemeier, vil jeg at all data som legges inn i databasen skal kvalitetssikres, slik at all data som ligger i databasen er riktig. Og: Som systemeier, Vil jeg at systemet skal beregne GPS-lokasjon for butikker basert på adresse, Slik at lokasjon blir en del av butikkdata. Siden vi underestimerte hvor lang tid vi skulle bruke i den forrige sprinten var vi mer generøse med timefordelingen denne gang. Vi jobbet videre på det vi laget i første sprinten og opprettet en klasse for validering. Her valideres det som parses fra XML-feed før det legges inn i databasen. Underveis som vi implementerte kode testet vi det med verktøyet Nunit. Arbeidet gikk raskere enn vi hadde estimert og vi var ferdige allerede etter første uken, til tross for problemer med AutoMapper. Vi tok da et nytt møte med veileder og kom frem til at vi ikke skulle ta inn noen nye oppgaver. Isteden tok veileder(med arkitekt-hatten på) en quality assurance på det vi hadde fått til så langt. Vi kom så frem til at vi skulle refraktorere måten vi lagret dataen fra XMLfilene. Dette var en riktig avgjørelse og vi stod etter denne sprinten med et funksjonelt program som effektivt oppfylte alle akseptansekriterium Tredje sprint Etter at vi var ferdige med innsetning og validering av data i systemet var det naturlig og starte med logging denne sprint. I tillegg til logging valgte vi også å starte med design på websiden og lage de klassene som ligger bak den fremtidige websiden. De brukerhistorier vi delte opp til tasks denne sprint er: Som systemeier, Vil jeg at alle endringer som gjøres i databasen skal loggføres, Slik at jeg alltid kan se hvilke endringer som er blitt gjort/ ikke blitt gjort. Og: Som sluttbruker, Ønsker jeg å ha mulighet til å finne nærmeste butikk og at veien dit skal vises på kart på mobilen min, Slik at jeg enkelt skal kunne finne frem til nærmeste butikk i NorgesGruppen. I planleggingen av denne sprinten oppdaget vi at den siste av disse brukerhistoriene ikke dekket alt vi skal lage. Det innebar at vi mest sannsynlig kommer til å bruke lenger det enn hva vi først estimert. Den inneholder ikke noen ønsker eller krav om hvordan dataen skal flyttes fra databasen til websiden. 14

19 Prosessrapport gruppe 10 Våren 2012 Med tre helt forskjellige arbeidsoppgaver delte vi opp oppgavene mellom oss, slik at vi får effektivisert arbeidet. Logging var det mest krevende siden vi ikke hadde brukt disse verktøyene før. I starten eksperimenterte vi mye med logging og prøvde å finne en bra måte og bruke det på. Halvveis inn i sprinten hadde vi fortsatt ikke funnet en bra løsning på det og tok da hjelp av veileder. Det ledet til at vi etter hvert fant en bra løsning på det. Når vi funnet riktig måte å bruke det på gikk arbeidet veldig raskt og logging ble ferdig før fristen. Det gikk lettere med de to andre delene av denne sprinten. Forslag på design var ferdig allerede etter første uken og fikk bra tilbakemelding fra veileder. Arbeidet med de klassene som ligger bak websiden gikk også raskt. Men det var mye å gjøre her så det tok tid å få det ferdig. Med erfaring fra den forrige sprinten ble tidsestimeringen mye bedre i denne sprint. Vi hadde litt problemer med å få loggingen til å fungere men klarte fristen Fjerde sprint I planleggingen av den siste sprinten valgte vi å satse alt på å få websiden opp i full funksjon. Det innebar at vi, som ventet, ikke rakk å bli ferdig med alle brukerhistoriene. Isteden var målet å få alle brukerhistorier med prioritet en i boks. Det gjenstod bare den ene brukerhistorien vi hadde startet på i forrige sprint: Som sluttbruker, Ønsker jeg å ha mulighet til å finne nærmeste butikk og at veien dit skal vises på kart på mobilen min, Slik at jeg enkelt skal kunne finne frem til nærmeste butikk i NorgesGruppen. Arbeidet bestod av å utvikle en MVC-applikasjon, med jquerymobile som rammeverk for designet, og koble siden med de klassene vi laget i forrige sprint. I tillegg skulle vi også få på plass visning av butikker i kart med veibeskrivelse. Det ble raskt utarbeidet en design for siden, som forbedredes gjennom hele sprinten. Dette var bra slik at funksjonaliteten da kunne bli testet umiddelbart. Det gikk også raskt å få på plass den enkle funksjonaliteten. Arbeidet med kart gjordes først lokalt. Det gikk fort å få på plass alle funksjoner som skulle brukes og det fungerte bra. Men når vi skulle implementere det i hovedprogrammet fungerte det ikke. Her brukte vi lang tid på å tilpasse det vi gjort for å få det kjørbart. Når sprinten var ferdig hadde vi oppnådd alt som krevdes av akseptansekriteriene, men vi var ikke helt fornøyde med den mobile websiden vi hadde laget. Etter møte med veileder ble vi enige om å bruke uken etter på å endre småting og få teste alt fullt ut Testing Grunnet tidsmangel har vi ikke utført en større brukertest, vi valgte i stedet å prioritere å teste websidens funksjoner. Begrunnelsen for denne prioriteringen ligger i prosjektets fokus på systemets funksjoner. Testingen av funksjonene ble gjort manuelt, ved å gå gjennom alle websidens funksjoner for så å huke av for om funksjonen fungerte. Det ble også testet på søkefunksjonenes tidsbruk. Det ble i tillegg opprettet enhetstester på metoder i systemet for å teste om metodene returnerte ønsket verdi. Akseptansetester ble gjort etter hver sprint for å undersøke om ønskete funksjoner hadde blitt implementert i systemet, og at alle akseptansekriteriene var oppfylt. 15

20 Prosessrapport gruppe 10 Våren Frislipping Planen var at programmet skulle være ferdig etter siste sprint, den 27. april, men siden vi brukte uken etter på å refraktorere programmet og fikse programfeil, ble websiden komplett en uke etter. Etter dette lastet vi opp siden på en server slik at den ble satt i drift og kunne brukes. Når programmeringen var ferdig startet vi å fokusere alt arbeidet vårt på dokumentasjon. Den 14. mai holdt vi en presentasjon av prosjektet for utviklerne hos Creuna i deres månedlige Tech-Lab. Dette for å dele de erfaringer vi har fått i prosessen. 3.5 Resultat Etter den første uken i mai satt vi igjen med vårt ferdige produkt. Vi har laget en informasjonsplattform som henter butikkdata fra feed og lagrer dette i en database slik at man kan vise denne informasjonen i websider. Ved å gjøre dette har vi tilgjengeliggjort butikkdata slik at den kan brukes i nye tjenester. Vi har også laget en demonstrators som viser nettopp hvordan man kan ta i bruk dataen i nye tjenester. Demonstratoren er en mobil webside som tilgjengeliggjør utvalgt butikkdata fra databasen. I websiden kan man finne butikker fordelt på kjede og fylke, gjøre avanserte søk, og finne butikker i kart Oppnådde mål Når vi startet med sprintene var målet å klare alle brukerhistoriene. Samtidig var kravet å fullføre de brukerhistoriene med høyest prioritet. Under utviklingen kom vi vi frem til at vi ikke ville klare målsetningen vi hadde satt. Brukerhistoriene med minst prioritet ble valgt bort til fordel for de brukerhistoriene med høy prioritering. Når vi nå er ferdige med utviklingen har vi fullført et system vi alle er stolte over. Vi har fullført de kravene vi satte og Creuna er fornøyde med resultatet.[9.7] Visning av resultat <Link til siden vår> 16

21 Prosessrapport gruppe 10 Våren

22 Prosessrapport gruppe 10 Våren Utfordringer under programmeringen Før vi begynte på dette omfattende prosjektet hadde vi ikke så mye erfaring fra.net og ekte systemutviklingsprosjekter. Vi visste derfor at det ville bli en enorm oppgave å undersøke og ta i bruk alle teknologiene vi måtte ta i bruk. Etter å ha blitt enige om rammeverket til utviklingsprosessen ble det naturlig å ta en ting av gangen. For hver brukerhistorie kom det nye teknologier vi måtte sette oss inn i, og implementere. Noen ting lærte vi oss fort. Enkelte viste seg å bli en utfordring Finne teknologien som var best til å parse XML» Under prototypingen ble det en liten utfordring å finne fram til hvilken teknologi som passet best til å gjøre spørringer på attributter i XML-dokumentene. Vi prøvde først noe som het xquery som vi fant 18

23 Prosessrapport gruppe 10 Våren 2012 ut det ikke fungerte bra i vårt tilfelle. Dette fordi det opprinnelig ikke var laget for C#, og at det vi måtte inkludere mange ekstra teknologier. Det ble så eksperimentert med XML Reader biblioteket i.net. Dette viste seg å være et bedre alternativ. Det ble laget et program som leste XML-dokumentene med butikkdata. Dette fungerte bedre for vår del enn XMLBulkLoad og xquery. Ulempen derimot, er at dokumentet blir lest som et vanlig tekstdokument, linje for line. Dette gjorde at koden ble veldig stor. Mye på grunn at man må spare på data før leseren går videre i dokumentet, deretter hente denne dataen fra lagringssted om nødvendig. Til tross for dette er XML Reader blant de raskeste av XML-parser teknologiene. Vi fant så ut at to av de vanligste teknologiene var xpath og LinqToXML. Sistnevnte er et veldig kraftig verktøy med støtte i C#-kompilatoren, i motsetning til xpath teknologien. Likevel fant vi ut at xpath var den mest passende teknologien. Fordi spørringene er mindre kompliserte og lettere å forstå Sette opp arkitekturen Dette var en stor utfordring siden vi ikke hadde jobbet på et prosjekt i denne størrelsen før. Vi tok flere runder på oppsettet av arkitekturen med hjelp av veilederne på Creuna Finne kunnskap om Entity Framework Code First Ettersom Entity Framework Code First ble utviklet for bare omlag et år siden, finnes det begrenset med informasjon om rammeverket tilgjengelig på web. Vi har tatt i bruk youtube videoer[4] for å finne eksempler på mulige løsninger. Vi kjøpte også boken Programming Entity Framework: Code First(Lerman, Miller 2011)[3] Fremmednøkler ble satt til «null» I starten hadde vi et problem med å tilordne fremmednøkler. Mye av grunnen var nok at EFCF er en ganske ny teknologi. Dette kan ikke skje automatisk. Systemet trenger å vite hvor relasjonen skal opprettes. Dermed er det naturlig å hente fremmednøkkelobjektet fra databasen. Dette for å tilordne det nye objektets fremmedpeker; Vi kunne ha laget en spørring for å tilordne denne pekeren direkte fra database, men fordi det ikke er garantert at dette elementet eksisterer i entiteten, måtte vi også ha en metode for å opprette elementet i tillegg til en spørring Bruk av AutoMapper AutoMapper er et verktøy i C# som gjør det lettere og mappe over data mellom to objekter. Ingen av oss hadde brukt det før, hvilket gjorde at vi fikk problemer. For at verktøyet skal fungere smertefritt må begge modellene, som dataene skal sendes i mellom, ha samme navn på objektene. Dette ble løst ved at vi leste en del om det på utviklerens blogg[6] og fikk hjelp av veilederen vår Unit Testingen Når vi skulle starte å teste den første sprinten fikk vi tips fra veilederen vår om å bruke et verktøy som het Nunit. Det samler alle enhetstester i et prosjekt og kjører alle samtidig. Vi hadde litt erfaring om enhetstesting fra tidligere kurs på skolen, men vi møtte uansett noen utfordringer på veien. Tester mot to av prosjektene vi lagde, kjørte ikke i Nunit. Etter mye arbeid og research på nettsiden for Nunit[7] fant vi ut av problemet. Vi hadde brukt feil format på prosjektene for å teste de, men fant en løsning. 19

24 Prosessrapport gruppe 10 Våren log4net arkitektur I prosjektet var det et krav at vi skulle logge alt ved prosessering av dataimport og database access. Vi ble anbefalt av vår veileder å bruke et tool til.net som heter log4net. Dette er et verktøy som skal gjøre det enkelt å innføre log statements i kode. Når vi implementerte dette skulle vi lage et eget logging prosjekt. I dette prosjektet skulle vi lage en logwrapper, som inneholder de forskjellige nivåene vi kan logge på, som man kunne kalle på i de andre prosjektene. Vi møtte på en utfordring ved at vi ikke fikk loggeren til å høre på app.config en fra logging prosjektet ved kall på den i andre prosjekter. App.config er det som bestemmer hvilke filer logg skal skrives til og hva som skal logges. Vi løste etterhvert problemet med at vi måtte sende med stien til den app.config en vi ville bruke i hvert kall på logwrapper. 3.7 Samarbeidet i gruppen Gruppen har under dette prosjektet hatt et svært nært samarbeid. Vi har til en hver tid jobbet i Creuna sine lokaler på Skøyen hvor vi som oftest har vært fulltallige. Gjennom daglige «stand up meetings» har vi holdt oss oppdatert på hva de andre på gruppen har jobbet med og eventuelle problemer de har støtt på. Parprogrammering har gjort at vi ved mange oppgaver har vært to stykker som har sittet ved en maskin. Dette har som nevnt gjort at vi har kunnet dele erfaringer og kunnskap. Det har også gjort at vi har hatt et ekstra par med øyne under mye av kodingen og feilsøkingen har blitt effektivisert av den grunn. Ingen konfrontasjoner eller krangler har oppstått i prosjekttiden, og vi har hatt en god dialog gjennom hele perioden. 3.8 Samarbeidet med veileder Vi bestemte oss ved vårt første med ved Weiqin, vår veileder på HiOA, at vi skulle møtes annenhver uke. På møtene snakket vi om fremdriften i prosjektet og diskuterte eventuelle problemer eller spørsmål vi måtte ha. Da vi har fått tilstrekkelig veiledning hos Creuna har møtene med Weiqin vært mindre hyppig enn først planlagt, med møter omlag hver tredje uke. I uke 13 hadde vi en midtveisevaluering hvor vi presenterte arbeidet vårt for Weiqin og de andre gruppene hun er veileder for. Dette ga oss en mulighet til å forberede oss for den prosjektpresentasjonen i midten av juni. Vi fikk tilbakemelding om både innhold og presentasjonsferdighetene våre, samt at vi fikk ideer fra de andre gruppene om ting vi kan gjøre annerledes. 3.9 Kvalitet på prosjektet For å sørge for at kvaliteten på sluttproduktet vårt er så høy som mulig, har vi brukt en rekke hjelpemidler. Testing har vært en viktig del av kvalitets sjekkingen. Gjennom akseptansetesting har vi forsikret oss om at produktet vårt tilfredsstiller kundens akseptansekrav. Enhetstesting har gjort at vi har fått testet hver enkelt bit av systemet. Videre har parprogrammering vært til stor hjelp, da det har gjort at det har blitt lettere å finne eventuelle feil eller svakheter i koden. Når en jobber med programmering alene er det fort at man kan gjøre feil og et par ekstra øyne på koden kan være til svært god hjelp. 20

25 Prosessrapport gruppe 10 Våren Kravspesifikasjonen og dens rolle Gjennom møter med Øystein, Rannveig og Tore ved Creuna i slutten av januar, definerte vi krav til informasjonsplattformen. Dette resulterte i en kravspesifikasjon. Denne ble delt opp i funksjonelle og ikke funksjonelle krav. Se kravspesifikasjonen i kapittel 1.1 i produktrapporten. 4.1 Betydning av kravspesifikasjonen Kravspesifikasjonen har vært et svært viktig styringsdokument i systemutviklingsprosessen. Den har gjort oss oppmerksomme på kundenes krav til det endelige produktet og har fungert som en skisse til hvordan funksjonaliteten i produktet ville bli. Videre har kravspesifikasjonen gjort at det til en hver tid har vært enighet om de tekniske rammene rundt prosjektet. Brukerhistoriene vi laget var basert på kravspesifikasjonen og det er brukerhistoriene vi i stor grad har tatt i bruk i scrum prosessen for å dele opp arbeidsmengde i sprintene. 4.2 Endringer i kravspesifikasjonen Vi har tatt i bruk det første utkastet av kravspesifikasjonen gjennom hele prosjektet. Ingen forandringer har blitt gjort i kravspesifikasjonen. Kravene til administrasjonsgrensesnittet for masterdata har derimot utgått da dette tilhørte en brukerhistorie med lav prioritet. Brukerhistorien hadde kun vært aktuell om vi hadde hatt mye tid til overs mot slutten av prosjektet, men dette har ikke vært tilfelle. 21

26 Prosessrapport gruppe 10 Våren Konklusjon 5.1 Oppsummering Vi har gjennom dette prosjektet tilegnet oss utrolig mye kunnskap om forskjellige aspekter ved systemutviklingsprosessen. Vi hadde gjennom fag ved HiOA fått teoretisk kunnskap om systemutvikling, men den praktiske kunnskapen var minimal. Det har derfor vært svært lærerikt for oss å få jobbet med systemutvikling i praksis. Vi har erfart hvor viktig planlegging, roller og analyse er i ett prosjekt. Gjennom scrum møter, sprint-review, retrospective og planning, har vi erfart nytteverdien av et godt brukt systemutviklingsrammeverk. I denne prosessen har vi også benyttet oss av nye teknologier som vi selv har måttet sette oss inn i. Det har vært en slitsom, men svært givende prosess. Noen av teknologiene har vært så nye at selv de ansatte ved Creuna har lite erfaring på området. Entity Framework Code First(EF:CF) er et eksempel på dette. Siden vi har tatt i bruk mange teknologier som har vært nye for oss har vi lest oss opp på mye nytt stoff. Det at vi også har fått brukt det i praksis har ført til at vi har lært svært mye nytt. Etter svært mye jobbing med et program for å hente ut informasjon fra XML dokumenter, putte det i databasen og deretter hente ut informasjonen igjen for en webservice, var det svært tilfredsstillende å få sett resultatet av dette arbeidet bli tatt i bruk i den mobile websiden. Vi er svært fornøyd med det endelige resultatet og utbyttet vi har hatt av prosjektarbeidet. 5.2 Muligheter Til tross for at vi har blitt ferdig med produktet vi definerte i kravspesifikasjonen, kan en rekke utvidelser bli gjort. For matbutikker vil det kunne være aktuelt å implementere en produktdatabase på web, slik at man kan se hva slags varer en gitt butikk fører. Dette kunne blitt inkorporert med vårt system slik at man kunne samle all produktinformasjon i en gitt kjede og gjøre søk i den mobile webside etter forskjellige varer. Videre kunne man ha vist spesielle tilbud på varer, unikt for hver butikk. Informasjonsplattformen er også overførbar til andre typer bedrifter, men visse forandringer på modellen må naturligvis gjøres. Sett bort i fra dette kan systemet brukes av de fleste butikkjeder med butikkinformasjon som man ønsker å samle informasjon og deretter vise det på en mobilwebside. 5.3 Hva kunne blitt gjort annerledes I sprint-retrospektive møtene har vi diskutert hva som har vært bra og dårlig i sprinten. Her følger en liste over de viktigste punktene Tidsestimering I de to første sprintene var tidsestimeringen ikke bra. Dette skyldes at vi aldri hadde brukt Scrum i praksis og var derfor usikre på om vi hadde estimert tidsbruken og arbeidsmengden. I den første sprinten hadde vi estimert for lite tid og i sprint to, for mye. Dette forandret seg i tredje sprint da vi estimerte timer bedre. Hadde vi estimert tiden bedre kunde vi ha unngått skippertak i slutten av sprinter. Men vi kan ikke se at det skulle ha påvirket resultatet på noen måte. 22

27 Prosessrapport gruppe 10 Våren Fordeling av oppgaver I noen sammenhenger kunne vi bedre ha tilordnet oppgaver til hver sprint slik at alle fikk muligheten til å bidra, om ikke like mye, men mer til hver sprint. Ofte, med programmeringsoppgaver, ble fordelingen av arbeidsoppgaver ubalansert. Spesielt tidlig i utviklingsfasen var dette et problem. Dette kunne kanskje vært løst hvis vi hadde fokusert mer på parprogrammering. Da kunne gruppemedlemmer med mindre programmeringserfaring og kjennskap fått involvert seg mer Dårlig definerte tasker I første sprintplanleggingen fikk vi mye hjelp av veileder til å bryte ned brukerhistorier til tasker. Vi hadde ikke gjort det før så hjelpen var nødvendig. Vi hadde problemer med å forstå noen av taskene, siden de var veldig teknisk definerte. Dette gjorde at vi spanderte mye tid på stand-ups i denne sprinten. I planleggingen til den andre sprinten la vi stor vekt på å definere taskene slik at vi skulle skjønne de bedre. Dette ledet til at vi fikk litt for mange tasker og tidsestimeringen ble dårligere. Vi lærte av våre feil og i de to siste sprintene definerte vi taskene mye bedre. Hadde vi brukt mer tid på å definere taskene bedre i de to første sprintene hadde vi trolig fått et litt bedre grunnlag, og kanskje ikke trengt å gjøre så mye arbeid på å refraktorere etter sprint to Lite variasjon i tasker Ofte, spesielt med programmeringsoppgaver, ble fordelingen av arbeidsoppgaver noe ubalansert. Tidlig i utviklingsfasen var dette et problem, da EF:CF løsningen ble skapt. Dette kunne vært løst med at man i tidligere sprinter hadde hatt flere varierte oppgaver. Oppgaver som da ikke bare fokuserte på back-end delen av programmet. Vi kunne for eksempel på et tidligere stadium begynt med presentasjonsdelen av prosjektet. Da med å lage design til web-siden, opprette htmlsider, implementere GoogleMaps API kart og opprette presentasjonsmodeller. Det hadde ikke vært nødvendig å bruke data fra database i starten, men det kunne heller bli brukt såkalt «mockdata». Ved å gjøre dette kunne vi heller ha brukt mer tid i siste sprinten på kvalitetssikring, og på å fikse eventuelle feil. Vi kunne også fokusert mer på back-end delen til websiden i den siste sprinten. 23

28 Prosessrapport gruppe 10 Våren Kildehenvisning Hasle, T(2008). Systemutvikling Applikasjoner og databaser. Cappelen Damm AS, Oslo, Norge. 3. Lerman, J og Miller, R(2011). Programming Entity Framework: Code First. O Reilly Media Inc., Sebastopol, USA. 4. Sergey Barskiy - Using Code First (Code Only) approach with Entity Framework,

29 Prosessrapport gruppe 10 Våren Vedlegg 7.1 Fremdriftsplan 25

30 Prosessrapport gruppe 10 Våren Risikoplan Risiko Sannsynlighet Konsekvens Tiltak Sykdom Høy Fordele mer arbeid på resten av gruppen. I verste fall må ting nedprioriteres. Ha god oversikt over oppgaver slik at det blir enkelt å fordele arbeid. Frafall fra gruppen Manglende kompetanse Rekker ikke milepæl Rekker ikke innlevering Lav Middels Middels Arbeidsmengde øker per medlem. Reprioritere delløsninger, kvaliteten på oppgaven kan reduseres. Bruker unødvendig tid til å komme frem til løsning. Fremdriftsplanen endres og vi får mindre tid til etterfølgende oppgaver. Ha god oversikt over oppgaver, god dokumentasjon over arbeidsoppgaver. Alle på gruppen må være godt forberedt på oppgaver de blir tildelt. God planlegging og bruk av agile utviklingsmetoder. Lav Ikke bestått, karakter trekk. God planlegging, fokus på milepæler og delinnleveringer. Tap av data Lav Kritisk for prosjektet, kan føre til at prosjektet ikke kan ferdigstilles. Må gjøre arbeid på nytt. Konflikter Høy Vanskeligheter med å arbeide sammen, dårlig effektivitet. Eventuell frafall fra gruppen. Manglende veiledning Akseptansetest feiler Manglende dokumentasjon For stor arbeidsmengde i sprint Lav Høy Middels Høy Vi ender opp med et produkt som ikke oppfyller arbeidsgiverens krav. Bruke tid på å rette opp eventuelle feil eller mangler. Vanskelig å fullføre prosjektrapport. Vanskelig for enkelte å sette seg inn i funksjonalitet. Må flytte oppgaver til neste sprint. Mindre tid til kommende oppgaver Alltid ta backup. Backup på flere steder. Bruke tjenester med versjonskontroll. God konfliktløsning. Ta tak i problemer tidlig. Samarbeidsavtale. Holde avtaler, god kommunikasjon, ha jevnlige møter. Skriftlig avtale. Gode krav og mål. Spesifikke User Stories. Klare retningslinjer for dokumentasjon. Bruk av dagbok og ukesrapporter. Vanskelig å forutse, men ta læring av forrige sprint. Gode prioriterings lister. 26

31 Prosessrapport gruppe 10 Våren Produkt backlog B1 Brukerhistorie Som systemeier, Vil jeg at butikkdata som kommer fra NorgesGruppen skal legges inn i databasen, Slik at databasen reflekterer oppdateringer i NorgesGruppens butikkregister. Akseptansekriterium Systemet skal oppdatere databasen, med data hentet fra XML-dokumenter Systemet skal legge til en ny butikk når dataen fra NorgesGruppen inneholder en ny butikk Systemet skal kunne slettemerke data B2 Brukerhistorie Som administrator av databasen, vil jeg at det skal være mulig å legge til spesielle åpningstider for butikkene, Slik at disse kan vises på butikkhjemmesidene. Akseptansekriterium Butikkansvarlig skal kunne legge til spesielle åpningstider Butikkansvarlig skal kunne endre spesielle åpningstider Administrator skal kunne legge til spesielle åpningstider Administrator skal kunne endre spesielle åpningstider B3 Brukerhistorie Som administrator av databasen, vil jeg at det skal være mulig å legge til butikktjenester som ikke allerede ligger i databasen, Slik at vi kan vise nye tjenester på butikkhjemmesidene. Akseptansekriterium Butikkansvarlig og administrator skal kunne legge til/endre tjenester Nye tjenester som butikkansvarlig ønsker å legge til må valideres av administrator 27

32 Prosessrapport gruppe 10 Våren 2012 B4 Brukerhistorie Som systemeier, Vil jeg at all data som legges inn i databasen skal kvalitetssikres, Slik at all data som ligger i databasen er riktig. Akseptansekriterium Data som ikke blir godkjent skal ikke legges inn i databasen Data som blir godkjent skal legges inn i databasen Feil ved validering av data skal loggføres B5 Brukerhistorie Som systemeier, Vil jeg at alle endringer som gjøres i databasen skal loggføres, Slik at jeg alltid kan se hvilke endringer som er blitt gjort/ ikke blitt gjort. Akseptansekriterium Systemet skal ha en logg over endringer i databasen Loggen skal inneholde informasjon som gjør det enkelt å feilsøke systemet B6 Brukerhistorie Som systemeier, Vil jeg at systemet skal beregne GPS-lokasjon for butikker basert på adresse, Slik at lokasjon blir en del av butikkdata. Akseptansekriterium Systemet skal finne LatLong for butikkene ved hjelp av spørringer mot Google Maps Databasen skal inneholde LatLong for alle butikker B7 Brukerhistorie Som administrator, 28

33 Prosessrapport gruppe 10 Våren 2012 ønsker jeg å ha muligheten til å redigere/oppdatere butikkdata, Slik at eventuelle feil kan rettes opp. Akseptansekriterium Via admingrensesnittet skal det bære mulig å endre data i databasen Via admingrensesnittet skal det bære mulig å legge til data i databasen Administratorer skal ha tilgang til admingrensesnittet B8 Brukerhistorie Som sluttbruker, Ønsker jeg å ha mulighet til å finne nærmeste butikk og at veien dit skal vises på kart på mobilen min, Slik at jeg enkelt skal kunne finne frem til nærmeste butikk i NorgesGruppen. Akseptansekriterium Sluttbruker skal kunne få informasjon om nærmeste butikk Sluttbruker skal kunne få informasjon om alle butikker i en gitt kjede Sluttbruker skal kunne få informasjon om en gitt butikk Sluttbruker skal kunne få veibeskrivelse til butikk Sluttbruker skal få informasjon om hvor han/hun befinner seg 29

34 Prosessrapport gruppe 10 Våren Databasemodell OperatingRegion PK OperatingRegionID OperatingRegionName OperatingRegionNO WholeSale PK WholeSalePartyID WholeSalePartyNO WholeSaleName StoreChain PK StoreChainID StoreChainName FK1 StoreConceptID StoreChainNO StoreConcept PK StoreConceptID StoreConceptName FK1 OperatingRegionID FK2 RegionID StoreConceptNO Municipality PK MunicipalityID MunicipalityName PostalCode PK PostalCode City Region PK RegionID RegionName FK1 StoreConceptID RegionNO Days PK DayID DayName Address PK AddressID FK1 CountyID FK2 MunicipalityID Type FK3 PostalCode County PK CountyNO CountyName Time PK TimeID TimeToOpen TimeToClose OpeningHours PK OpeningHoursID FK1 DayID FK2 TimeID Closed FK3 StoreID FK5 SpecialDaysID Service PK ServicID Name Type StoreServices PK StoreServiceID FK1 StoreID FK2 ServicID DateFrom DateTo StoreAddress PK StoreAddressID FK1 AddressID StreetAddress FK2 StoreID LatLong Telecom PK TeleID Type Number FK1 StoreID SpecialDays PK SpecialDaysID Name Date Store PK StoreID FK7 StoreConceptID FK8 WholeSalePartyID FK5 OperatingRegionID FK6 RegionID Name OrganizationNO StoreNO Action Active Akkurat 1 0-n 1-n 0-1

35 Prosessrapport gruppe 10 Våren Møtereferat 24.2 og Møtereferat 24.2(2) Møte med/hos Creuna Til stede: Morten Sandberg S Magnus Øren S Joakim Sjögren S Magnus Helgestad Nerland S Espen Tidemand-Fossum S Fra Creuna: Tore Urnes Rannveig Aarnes Tid: Agenda: Grovestimering av hele product backlog og lage fremdriftsplan Vi ville med dette møte planlegge arbeidsmengden i brukerhistoriene for å finne ut hvordan fremdriftsplanen kom til å se ut. Dette gjøres ved å rangere brukehistoriene. Vi begynte med å se kalenderen for å finne ut hvor mange sprinter vi kom til å få tid til og når vi burde være ferdig med de forskjellige delene av prosjektet. Sprint 1 begynner i uke 9. Det er ønskelig å få til så mange sprinter som mulig slik at vi får mye erfaring. Med sprinter på 2 uker i en periode på 8 uker ser det ut til at vi kommer til å få tid til 4 sprinter. Uke Sprint Brukerhistorier 9 1 B B B1, B B1, B B5,B6 14 Påske 15 3 B5, B B B8 Vi anser 12 timer med utvikling i uken per person i gruppen under utviklingsfasen. 12*5 timer i uken tilsvarer 120 timer med utvikling per sprint og 480 timer totalt. Estimering av arbeidsmengde: B1 (Prioritet 1): Svært viktig og en av brukerhistoriene vi bør begynne med i sprint 1. B1 vil føre til mye arbeid. Det kan tenkes at det kun er denne brukerhistorien vi har tid til å jobbe med i sprint 1. Fibonacci: 21. Estimert til Ca. 170 timer. 31

36 Prosessrapport gruppe 10 Våren 2012 B2 (prioritet 3): Denne er ikke like viktig og kan ventes med til slutten av prosjektet B3 (Prioritet 2): Fibonacci: 13 B4 (Prioritet 1): Denne er knyttet opp mot B1 og kan vurderes som viktig. Fibonacci: 8 B5 (Prioritet 1): Ganske straightforward arbeid. Fibonacci: 5 B6 (Prioritet 1): Denne er også knyttet opp mot B1 og litt opp mot B4. Creuna har allerede litt kode som kan brukes og vi har allerede begynt prototyping. Fibonacci: 5 B7 (prioritet 2): Fibonacci: 13 B8 (Prioritet 1): Dette skal være en kryssplattform med interaksjonsdesign og medfører mye arbeid. Fibonacci: 21 Estimert til 170 timer Da vi kun har rundt 480 timer med utviklingstid vil det kunne være aktuelt og kun jobbe med Prioritet 1 Brukerhistoriene. 32

37 Prosessrapport gruppe 10 Våren 2012 Møte nr.2 hos Creuna Til stede: Morten Sandberg S Magnus Øren S Joakim Sjögren S Magnus Helgestad Nerland S Espen Tidemand-Fossum S Fra Creuna: Tore Urnes Tid: Agenda: Sprintplanlegging for sprint 1 Vi vil under møtet jobbe med å bryte ned user stories i mindre tasks eller oppgaver. Brukerhistorie 1 består av tre hovedfunksjoner: parse data, persistere data og flytte inn i databasen og til slutt flytte filen inn i en ny katalog, ett slags arkiv. Vi delte brukerhistorien inn i tasker: Tasker: 1. Sørge for at det finnes xpather for hvert element som skal leses inn i XML feeden. 2. Opprette parse objektklasser 3. Sette opp og bygge en lagdelt arkitektur der tjenestelaget og domeneobjektene er i et lag (prosjekt i Visual Studio) og parsingen foregår på et annet lag. Et lag for enhetstesting og presentasjon(weblag) må også lages 4. Sette opp Team Foundation Server og importere arkitekturen 5. Lage domeneklasser (EFCF) 6. Lage Domain Model Creator 7. Sette opp database 8. Filhåndtering Deretter spilte vi planning poker hvor alle la ned kort med fibonacci verdier(0,1,1,2,3,5,8,13,21.) som representerer antall timer med programmering vi tror hver task vil ta. Når alle hadde vist verdien på sitt kort, diskuterte vi hvorfor vi tro r tasken kommer til å ta så mange timer. Etter en ny runde kommer vi frem til en verdi alle er enig i. Planning Poker: 33

38 Prosessrapport gruppe 10 Våren 2012 Task Antall timer Sum:

39 Produktrapport Informasjonsplattform for butikkdata Gruppe 10 Magnus Øren S Joakim Sjögren S Morten Sandberg S Espen Tidemand-Fossum s Magnus Helgestad Nerland S161865

40 Produktrapport gruppe 10 våren 2012 Forord Dette dokumentet er skrevet for fagfolk med kompetanse innen informasjonsteknologi og beskriver tekniske aspekter ved Informasjonsplattform for butikkdata en løsning levert til Creuna AS i forbindelse med Bachelor-prosjekt ved HiOA. Produktrapporten er myntet på folk som skal drifte eller modifisere systemet, eller som trenger å sette seg inn i systemet. Man bør ha kunnskap om.netbasert systemutvikling for å ta i bruk dette dokumentet. Videre bør man ha kjennskap til XML, HTML, CSS, og SQL. Denne rapporten gir en teknisk beskrivelse av Informasjonsplattform for butikkdata. Informasjonsplattformen er et integrasjonslag som eksponerer utvalgte virksomhetsdata på en slik måte at det enkelt kan lages nye tjenester basert på dataene. Rapporten starter med å presentere mål og rammebetingelser for prosjektet og løsningen. Et viktig krav fra kunden, Creuna AS, var at det skulle utvikles en demonstrator-tjeneste basert på informasjonsplattformen. En kort gjennomgang av demonstratorens design presenteres derfor i kapittel 2. Løsningen er bygget rundt en standard tre-lags systemarkitektur. En oversikt over arkitekturen presenteres i kapittel 3, mens hvert lag belyses i mer detalj i påfølgende kapitler. Kapittel 8 omhandler sikkerhet. Utvalgte nøkkelteknologier, samt utviklingsverktøy gjennomgås i kapitlene 9 0g 10. En testrapport presenteres i kapittel 11. Til slutt diskuteres mulige utvidelser i kapittel 12. 2

41 Produktrapport gruppe 10 våren 2012 Innholdsfortegnelse Forord Mål og Rammebetingelser Kravspesifikasjon Funksjonelle krav Krav til database Krav til Importjobb Krav til tjenestelaget Krav til Client/Web Services Krav til admingrensesnitt for masterdata Ikke funksjonelle krav Krav til database Krav til importjobb Krav til tjenestelaget Krav til Client/Web Services Samsvar mellom kravspesifikasjon og løsning Domenemodellen Systemarkitektur Design av demonstrator Interaksjonsdesign Kartfunksjonalitet Import av data fra feed XML-Parsing Fra XML-feed til ParseObjekter Retningslinjer for validering Kritiske verdier Ikke kritiske verdier Metodene GoogleMaps geocoding Filhåndtering Bruk av Entity Framework 4.1 Code First Relasjonsdefinering Fluent API eksempler DataAnnotations Bruk av Lazy Loading Oppdatering og innsetting av data i database

42 Produktrapport gruppe 10 våren Find-metodene og Create-metodene Cascade-deleting Tjenestelaget BusinessLogic Finn butikk Søk på butikk Finn nærmeste DataAccessClass Finn butikk i fylke og kjede Søk på butikk Finn nærmeste Presentasjonslaget Kort om MVC Kommunikasjon med databasen Views Controllers Models jquery Mobile jquery Mobile syntaks jquery Mobile i løsningen CSS Sikkerhet Teknologier Xpath og Xdocument (Xpath select under Xdocument) Entity Framework Code First jquery mobile, HTML5, CSS Google Maps API AutoMapper Verktøy Microsoft Visual Studio Microsoft SQL server Team Foundation Server Testing Alle funksjoner Overordnede funksjoner Søkefunksjoner

43 Produktrapport gruppe 10 våren Systemets funksjoner Enhetstesting Akspetansetestkriterier Videre muligheter Nye funksjoner Kildehenvisning Vedlegg Flytdiagram Klassediagram Databasemodell

44 Produktrapport gruppe 10 våren Mål og Rammebetingelser Hensikten med informasjonsplattformen er å tilgjengeliggjøre virksomhetsdata, i dette tilfellet butikkdata, og benytte informasjonen på måter som tidligere har vært vanskelig eller umulig. Programmet benytter seg av XML-filer som datagrunnlag. Utvalgte butikkdata i XML-filene blir hentet ut, validert og lagt i en database opprettet av programmet. Denne databasen danner så datagrunnlaget for informasjonsplattformen. For å demonstrere hva databasen kan benyttes til har vi utviklet en tjeneste i form av en webside som tilgjengelig gjør deler av informasjonen i databasen. Websiden er spesielt tilpasset for bruk med håndholdte enheter. Den skal i tillegg til å gi viktig informasjon om butikkene, ha mulighet for å vise butikkene i kart med kjørerute mellom brukerens posisjon og butikken. 1.1 Kravspesifikasjon Gjennom møter med Creuna i slutten av januar, definerte vi krav til informasjonsplattformen. Dette resulterte i en kravspesifikasjon. Denne ble delt opp i funksjonelle og ikke funksjonelle krav. Kravene fikk prioriteringsverdier fra 1-5 der 1 har høyeste prioritet og 5 har laveste prioritet Funksjonelle krav Følgende er en kort oppsummering av funksjonelle krav for løsningen Krav til database En SQL-database hvor en skal kunne lagre dataen sendt fra tjenestelaget og administrasjonsgrensesnittet. Det skal være mulig å lese, skrive, slette og oppdatere data. Krav P 1-5 Kommentar Lagre data til informasjonsplattformen 1 Mulighet for å legge til tjenester som ikke er i feed 2 Mulighet for å legge til spesielle åpningstider Krav til Importjobb Et program som henter data fra XML-dokumentene, parser og tilegner attributter til dataen. For så å sende det videre til tjenestelaget. Krav P 1-5 Kommentar Implementere samtlige aksjoner (ny slett oppdater) 1 Kvalitetssikring av data som kommer fra NorgesGruppen 1 Endringer skal loggføres 1 Beregne lokasjon for butikker basert på adresse Krav til tjenestelaget En felles plattform for å lese, skrive, oppdatere og slette data i databasen. Bruker spørringer for å interagere med databasen. Får data fra importjobb og sender data til web service. Krav P 1-5 Kommentar Det skal brukes samme oppdatering, sletting (slette merking) 1 og legge til rutiner for alle lag Det skal opprettes rutiner for å legge til nye tjenester for butikkene 3 6

45 Produktrapport gruppe 10 våren Krav til Client/Web Services Tjeneste for å formidle og behandle informasjon fra databasen til web/mobilapplikasjoner. Krav P 1-5 Kommentar Finn nærmeste butikk og vis i kart på mobil 1 Skaff lokasjon (tast inn/gps/...) 2 Web Service som returnerer butikkdata for nærmeste butikk 1 (lokasjon, navn, adresse, åpningstid) Kunne hente gitt butikk 2 Kunne hente alle butikker for kjede Krav til admingrensesnitt for masterdata Gjør det mulig og manuelt å administrere informasjon i databasen. F.eks. å legge inn data som ikke finnes i XML-dokumentene. Dette kravet ble gitt prioritet 4, og kravet er ikke blitt konkretisert Ikke funksjonelle krav Krav til database Krav P 1-5 Kommentar Databasemodellen skal følge normalform 1 Databasen skal bruke syntetiske nøkler 1 Databasedesignen skal være oversiktlig 2 Masterdata skal slettemerkes Krav til importjobb Krav P 1-5 Kommentar Det skal utføres enhetstester etter hver sprint 2 Systemet skal lese inn nye data fra NorgesGruppen og 5 oppdatere hver dag De siste dokumentene som inneholder dataen skal lagres 4 Systemet skal bruke Entity Framework Krav til tjenestelaget Krav P 1-5 Kommentar Importjobb og Web services skal bruke tjenestelaget Krav til Client/Web Services Krav P 1-5 Kommentar Kryssplattform web teknologi HTML5, jquery Mobile, 1 CSS3 Når en sluttbruker bruker tjenesten skal lite data brukes 2 7

46 Produktrapport gruppe 10 våren Samsvar mellom kravspesifikasjon og løsning Løsningen samsvarer i stor grad med kravene stilt i kravspesifikasjonen. Krav til database, importjobb, webside og tjenestelaget (ikke rutiner for å legge til nye tjenester i butikkene) ble alle levert. Krav til administrasjonsgrensesnitt for masterdatabase ble nedprioritert. Siden informasjonsplattformen i stor grad ikke er en master-database, er administrasjon mindre viktig. Løsningen leverer derfor ikke slik administrator-funksjonalitet. I tillegg ble ikke rutiner for å legge til nye tjenester i butikkene implementert. Som man ser ut i fra kravspesifikasjonen er dette krav med lavere prioriteter. 8

47 Produktrapport gruppe 10 våren Domenemodellen Dette dokumentet beskriver en løsning innen domenet butikkdata. I tidlig fase av prosjektet ble det brukt mye tid på å sette seg inn i de forskjellige konseptene som inngår i butikkdatadomenet. Målet var å ende opp med en domenemodell for alle butikkdata som skulle inngå i informasjonsplattformen. Samarbeid med domeneeksperter hos Creuna var viktig i domenemodelleringsprosessen, og vi endte til slutt opp med modellen, representert ved hjelp av et Entity-Relationship diagram, som er gjengitt i vedlegg Sentralt i domenemodellen er konseptet butikk (Store). En butikk har navn samt en unik id. I tillegg vil det være assosiert en eller flere adresser (StoreAddress) med hver butikk. Adresser kan være av forskjellige typer, f.eks. adresse for leveranser, og inkluderer også kommuneinformasjon (Municipality). En stor dagligvareaktør vil typisk eie mange butikker og butikkene er typisk organisert i butikkjeder med egne butkikkonsepter (StoreConcept). I tillegg så organiseres butikker i regioner (Region) og driftsregioner (OperatingRegion). Åpningstider (OpeningHours) og butikktjenester (StoreServices) er viktige butikkdata. Domenemodellen kan representere både vanlige åpningstider og åpningstider for spesielle dager (SpecialDays) som offentlige helligdager, men også butikkspesifikke dager som super-torsdag. Butikktjenester er ting som tipping, bank i butikk, etc. Her tillater domenemodellen at nye typer tjenester kan legges til etterhvert. For å visualisere ting som dataflyt i systemet, relasjonene mellom objekter i databasen, og lagdeling har vi laget modeller i MS Visio. Modelleringen av entitet relasjons-modellen har tatt mest tid, og den er også viktigst. Siden programmet vårt bruker teknologien Entity Framework Code First, innebærer det at vi lager alle entiteter fra ER-modellen som modeller i programmet. Disse modellene har en sentral rolle i programmet. Vi jobbet med databasemodellen i flere iterasjoner i tett samarbeid med Creuna for å sikre at vi laget systemet slik «kunden» ville ha det. Vi laget et konseptuelt klassediagram som viser objektene involvert i problemområdet og relasjonen mellom klassene. Dette har gjort det lettere for oss å forstå hvordan delene i det fremtidige systemet vil henge sammen. Se klassediagram i vedlegg Videre har vi også laget et flytdiagram som beskriver dataflyten i informasjonsplattformen. Den gjør det lettere å forstå relasjonen mellom de forskjellige delene i systemet og hvordan de samhandler. Programmet starter med å ta inn XML-dokumenter som leses inn, valideres og mappes over til Domenemodellen via tjenestelaget. Databasen generes med domenemodellen som mal. For å hente ut informasjonen brukes tjenestelaget og mapper valgt data fra domenemodellen til de modellene som brukes av websiden. Se flytdiagram i vedlegg

48 Produktrapport gruppe 10 våren Systemarkitektur Basert på en moderne flerlagsarkitektur, med domenedrevet design som et viktig overordnet prinsipp, har vi laget følgende arkitektur: Domenelaget med domeneobjekter er sentralt i arkitekturen. Database og dataaksess ligger under domenelaget; tjeneste- og presentasjonslag ligger over. Det inngår en rekke rammeverk som komponenter i løsningen. Database og dataaksess realiseres ved hjelp av Microsofts Entity Framework-rammeverk. Den såkalte Code First-metoden ble benyttet hvor databasen auto-genereres fra domenemodell-klasser annotert med EF:CF-attributter. Dette er en helt ny måte å realisere persistente objekter på i.net-baserte løsninger. Et sentralt prinsipp i arkitekturen er å redusere avhengigheter mellom lagene så mye som mulig. Særlig er det viktig å redusere avhengigheten til domeneobjekter slik at endringer i domenemodellen ikke medfører store vedlikeholdsoppgaver i de andre lagene. Det defineres egne objekttyper i de forskjellige lagene som automatisk mappes til og fra domeneobjekter ved hjelp av AutoMapperrammeverket. En fordel med denne løsningen er at man slipper å håndtere kompliserte domeneobjektgrafer i presentasjonslaget, men kan i stedet generere skreddersydde dataoverføringsobjekter som på en enkel måte gir tilgang til kun de butikkdata som trengs for de spesifikke presentasjons-views. Løsningen er myntet på å støtte web-baserte tjenester, og spesielt mobil-tilpassede websider.god mobil-støtte vil typisk fordre at generert HTML holdes på et så konsist nivå som mulig. ASP.NET 10

49 Produktrapport gruppe 10 våren 2012 Model View Controller 3 er et rammeverk som forenkler håndtering av HTTP-forespørsler og bedre kontroll på generering av HTML. I tillegg benytter løsningen jquery Mobile-rammeverket for å lage web grensesnitt som egner seg for mobiler med trykkeskjerm. 11

50 Produktrapport gruppe 10 våren Design av demonstrator For å demonstrere informasjonsplattformens muligheter ønsket Creuna at vi utviklet en mobil webapplikasjon som tilgjengeliggjør utvalgte data i databasen. Grunnen til at en mobil og andre håndholdte enheter ble valgt som plattform for demonstratoren, ligger i Creuna sin visjon om den mobile utviklingen, hvor mobile enheter spiller en større og større rolle i brukerens hverdag. Dette er i henhold til mobile first prinsippet som blir stadig viktigere[1]. Mobile first innebærer blant annet at man starter med mobil-versjonen når man utvikler tjeneste. Mobile tjenester kan realiseres på mange måter. Plattform-spesifikke mobilapplikasjoner har lenge vært rådende. Slike såkalte native applikasjoner må utvikles spesielt for hver plattform (ios, Android varianter, Windows Phone, etc.). Dette kan bli veldig dyrt og det har derfor i det siste vokst frem alternative plattformer som baserer seg på web-teknologi. Man skiller mellom hybride plattformer og rene web-plattformer. Creuna har valgt å satse på det siste. Blant rene web-plattformer har man på den ene siden plattformer som støtter mobile webapplikasjoner og på den andre siden mobile websider. Mobile webapplikasjoner implementeres typisk i JavaScript og HTML5 og kjører i nettleser lokalt på den mobile enheten. Mobile websider benytter mindre JavaScript og består av websider som genereres på en server. Creuna ønsket at demonstratoren skulle basere seg på mobil webside teknologi. 4.1 Interaksjonsdesign Da vi jobbet med interaksjonsdesignet lå fokuset vårt på at vi skulle ha en enkel, men funksjonell webside, men også at den tilfredsstilte akseptansekriteriene i brukerhistorien: Sluttbruker skal kunne få informasjon om nærmeste butikk Sluttbruker skal kunne få informasjon om alle butikker i en gitt kjede Sluttbruker skal kunne få informasjon om en gitt butikk Sluttbruker skal kunne få veibeskrivelse til butikk Sluttbruker skal få informasjon om hvor han/hun befinner seg Etter å ha bestemt funksjonaliteten til websiden, laget vi et flytdiagram for å visualisere arkitekturen. Diagrammet var et godt verktøy for å gjøre funksjonene i websiden så tilgjengelig for brukeren som mulig og for å lage en intuitiv flyt i websiden. For mer informasjon se vedlegg Da en mulig arkitektur var på plass laget vi en prototype med Post-it-lapper for å få et visuelt bilde på websidens flyt og for å prøve oss frem med det grafiske brukergrensesnittet. Senere gikk vi videre med prototypen, ved å lage grafisk brukergrensesnitt og interaksjonsdesign i Balsamiq Mockups, et verktøy for trådramming. På denne måten fikk vi en prototype med brukergrensesnitt og fungerende interaksjon, og en god forståelse for hvordan websiden ville fungere. 12

51 Produktrapport gruppe 10 våren 2012 Figur 3. Interaksjonsdesign laget i Balsamiq Mockups Bildene viser fra venstre til høyre: forsiden av websiden, informasjonsside for butikk, finn nærmeste butikk og til slutt kartfunksjonen. Under selve programmeringen av websiden ble det gjort mindre endringer i brukergrensesnitt og funksjoner. 4.2 Kartfunksjonalitet Websiden inneholder en kartfunksjonalitet som viser lokasjon til butikkene i informasjonsplattformen. Brukeren kan velge å vise butikkene i nærhetene av han i kartet. Brukeren kan også velge å få ruten til en gitt butikk basert på brukerens nåværende posisjon. Websiden benytter Google Maps API for å vise kart og plassere markører på dette. Google Maps API benyttes også til å vise en markør for brukerens posisjon og for å vise ruten fra brukerens markør til en gitt butikk. Ved å ta i bruk adressene til butikkene får man gjennom Google Maps gjort om denne adressene til GPS koordinater som deretter kan bli brukt til å finne frem til stedene i et kart. Lat/Long verdiene blir etter at de kommer fra Google Maps puttet inn i databasen med butikkdata slik at det kan hentes ut igjen ved en annen anledning. 13

52 Produktrapport gruppe 10 våren Import av data fra feed Dette kapitlet tar for seg import av butikkdata fra feed. Feeden består av et sett med XML-filer, hvor hver fil inneholder informasjon om én butikk. Selve import-prosessen kan deles inn i følgende steg: Data hentes ut fra XML-dokumenter og legges i mellomliggende-objekter(intermediateobjekter) Validering av data utføres GPS-koordinater hentes fra Google XML-filene blir kopiert og flyttet til en ny mappe Objektene legges i en Container-objekter Det sendes en samling av Container-objekter til NG.Service. Program Stegene over utføres alle i XML-Parser modulen i tjenestelaget i systemarkitekturen som ble presentert i kapittel 3. For å lagre importerte butikkdata som persisterte domeneobjekter i databasen, utføres i tillegg følgende steg i tjenestelagets Service modul: Instansierer DbContext-objekt Sletter utgått data Oppretter ny poster 5.1 XML-Parsing Parser.cs henter XML-dokumenter fra server hos oppdragsgiver. Disse blir så lagt inn i ett Streng array, før hver enkel indeks blir aksessert. Parser.cs tilbyr følgende funksjonalitet: Metoder for å hente ut data fra XML-feed Validator-kall GEO location-kall Filhåndteringsmetode Bruk av XPath XPath et spørrespråk benyttes til å aksessere noder i XML-dokumenter[4]. Når det skal hentes ut data fra et XML-dokument i Parser.cs lastes det inn av et XElement-objekt. For å danne et node-tre og for å kunne ta i bruk XPath, legges XElement-objektet over i et XDocumentobjekt. Fordi XML-dokumentene har såkalte «namespaces» må dette registreres i XDocument for å så kunne foreta spørringer. Videre må det utføres NULL-sjekker på resultatet før eventuelt verdier kan hentes ut. xpath eksempel: xdoc.xpathselectelement("/ns:customers/ns:customer[@action='update']/ns:customerstatus/../ns:" + "Affiliation[ns:Relationship='StoreConcept']/ns:Name", xnm); 5.2 Fra XML-feed til ParseObjekter For å transportere dataen fra Parser-klassen til innsettingsprogrammet er det definert et sett med parseobjekter. Disse objektene korresponderer med domenemodellobjektene, noe som gjør lettere å overføre data med AutoMapper-teknologien. Gjennom datainnhentingsprosessen tilordnes variablene i 14

53 Produktrapport gruppe 10 våren 2012 objektene verdier fra XML-skjemaene. Det blir opprettet et ParseObjectContainer-objekt som har som formål å samle alle ParseObjects. Før ParseObject-objektene kan legges inn i kontaineren må dataen i dem valideres. 5.3 Retningslinjer for validering Virksomhetsdataene som feeden er basert på vil typisk vedlikeholdes manuelt, og det må forventes at enkelte informasjonselementer vil innehold feil. Det er derfor viktig at alle data valideres så godt det lar seg gjøre før de lagres i databasen. Vi kategoriserer feil i butikkdataene på to måter, kritisk og ikkekritiske Kritiske verdier Kritiske mangler medfører at datasettet blir vanskelig å ta i bruk i databasen fordi noen av de mest sentrale verdiene mangler. Dette fører til at datasettet i sin helhet ikke vil inkluderes. Kritiske verdier StoreNo OrganinzationNo StoreName Action Ikke kritiske verdier Ikke-kritiske mangler kan innebære at det mangler lokasjonsdata, eller mangler i informasjon om forskjellige tjenester en butikk tilbyr. Denne dataen skal ikke inkluderes. Den settes til null i Validator-klassene. Det kan også være avhengighetsforhold mellom data. For eksempel mellom fylke og poststed. Ved fravær av eller feil i data i en av disse postene skal begge settes til null Metodene I Valideringstestene undersøkes hovedsakelig at verdiene eksisterer. Hva som vektlegges avgjøres av hvilken datatype verdien er av. Datatype Streng NULL-sjekk EmptyString-sjekk Regular Expression Pattern test(regular Expression) Datatype Integer Antall siffer 5.4 Google Maps GEO coding Kunden ønsker at GPS-koordinater lagres for hver butikk i løsningen, men slike lokasjonsdata er dessverre ikke tilgjengelige i feeden. Eneste data om butikklokasjon som er tilgjengelig er butikkenes adresser. Det ble derfor bestemt at en ekstern Google-tjeneste skulle benyttes for å skaffe GPSkoordinater for hver gateadresse i feeden.. Systemet sender en forespørsel til Google med lokasjonsinformasjon og får tilbake et XML-skjema med koordinater. Dataen kan enkelt hentes ut med hjelp av XML Reader eller XPath. 15

54 Produktrapport gruppe 10 våren 2012 I klassen tas det stilling til nøyaktigheten på resultatet. Basert på søkeparameterne tilordnes det en nøyaktighetsgrad for hvert resultat. Denne graderingskalaen er basert på graderingskalaen til Google Maps API. Her tilordnes det verdier fra 0-10 hvor 10 angir høyest nøyaktighet. Mindre spesifikk lokasjonsinformasjon vil gi lavere nøyaktighetsgrad. For eksempel, mangler i adresselinje vil ofte gi flere resultater, og er dermed lite nøyaktig. Den vil dermed få nøyaktighetsgrad mindre enn åtte. 16

55 Produktrapport gruppe 10 våren 2012 url = string.format(" +1} +2} +3} + &output=xml&oe=utf8&sensor=false", this.addressline, this.city + ", ", this.postalcode, this.country); wc = new WebClient(); wc.baseaddress = url; try sr = new StreamReader(wc.OpenRead(url)); } catch (Exception e) } readresults(sr); XElement xel = XElement.Load(sr); XElement result; XDocument xdoc = new XDocument(xEl); XMLReader reader = xdoc.createreader(); XMLNamespaceManager xnm = new XMLNamespaceManager(reader.NameTable); //metode 1 xnm.addnamespace("ns", " XMLTextReader xreader = new XMLTextReader(sr); result = xdoc.xpathselectelement("/ns:kml/ns:response/ns:placemark[@id='p1']/ns:point/ns:coordin ates", xnm); if (result!= null) s = result.value.split(new char[] ',' }); longitude.add(s[0]); latitude.add(s[1]); } //Metode 2 try } while (xreader.read()) if (xreader.name.equals("coordinates")) s = xreader.readstring().split(new char[] ',' }); longitude.add(s[0]); latitude.add(s[1]); } xreader.movetonextattribute(); } 17

56 Produktrapport gruppe 10 våren Filhåndtering Når dataen fra feeden har blitt validert og lagret i løsningens database, arkiveres XML-filene på serveren. Filene lagres i en mappe med dato for importen med butikkens navn som filnavn, slik at det skal være enkelt å finne butikkene. 5.6 Bruk av Entity Framework 4.1 Code First Code First tillater programmereren å opprette en database rett fra kode. Dette gir god tidlig i utviklingsprosessen. En ulempe med denne metoden (med EF 4.1) derimot, er at alle endringer i databasemodellen medfører at databasen må slettes og opprettes på nytt. Muligheten for å migrere data er inkludert i senere versjoner av EF (EF 4.3), men da vi startet med prosjektet fantes ikke denne versjonen. Domenemodellene representerer tabellene i databasen. I disse modellene må man angi datatyper, nøkler og eller annen metadata. For å gjøre dette kan man enten bruke DataAnnotations eller Fluent API. Sist nevnte er et metode-basert grensesnitt laget for å gjøre kode mer forståelig. På denne måten kan man fortelle systemet hva som skal være nøkler, relasjonene en tabell har, samt en rekke regler for slett og endre [3] Relasjonsdefinering public override void onmodelcreate(dbmodelbuilder modelbuilder) modelbuilder.entity<someentity>().hasrequired(s=>s.somekey).withmany(l=>l.primarykey).hasforeignkey(s=>s. somekey); modelbuilder.entity<someentity>().hasmany(s=>s.otherentities).withoptional(oe=>oe.someentities); modelbuilder.entity<someentity>().hasrequired(s=>s.somekey).withmany(l=>l.primarykey).hasforeignkey(s=>s. somekey); 5.7 Fluent API eksempler Definere fremmednøkkel: modelbuilder.entity<someentity>().hasrequired(s=>s.somekey).withmany(l=>l.primarykey).hasforeignkey(s=>s.so mekey); Ved bruk av DataAnnotations legger man til Attributter ved hver enkel variabel deklarasjon. 5.8 DataAnnotations En vanlig måte å definere relasjoner på er ved å inkludere pekere til andre objekter i domenemodellene. For å definere en-til-mange eller mange-til-mange relasjoner bruker vi ICollectionsamlinger. I EF så er det ikke nødvendig å spesifisere hva som skal være fremmednøkler. Dette blir automatisk tilordnet, men er i utgangspunktet til ikke-identifiserende relasjoner. Dette er relasjoner hvor begge sidene av en relasjon ikke er avhengig av hverandre. 18

57 Produktrapport gruppe 10 våren 2012 public class Service [Key] public int ServiceID get; set; } [Required] [StringLength(10)] public string Type get; set; } [StringLength(25)] public string Name get; set; } } public virtual ICollection<StoreServices> StoreServicess get; set; } I CodeContext-klassen har vi lagd DbSet av domenemodellene. Det er dette som skal utgjøre tabellene i databasen. Når CodeContext-klassen instansieres, kalles det på databasen. Før dette har Init-klassen eksekvert. Dermed er det funnet ut hvorvidt databasen eksisterer, og hvilke operasjoner som skal foretas mot databasen ved initialisering. Hvis databasen eksisterer og ikke skal slettes ved initialisering, vil ikke Seed-metoden i CodeContext klassen kjøres. Databasen skal bare slettes og opprettes igjen, hvis tabelldefinisjonen endrer seg gjennom domenemodellene. 5.9 Bruk av Lazy Loading Lazy Loading vil si at elementene objektet er i relasjon med, ikke nødvendigvis vil lastes inn med en gang. Ved å gjøre et kall på en «ICollection»-samling vil det automatisk gjøres et søk mot databasen og finne relaterte objekter. Dette gjør det svært enkelt å hente ut data fra databasen uten å måtte utrykke eksplisitt gjennom spørringer hva man vil ha ut. Det er vanlig at man definerer «ICollection»-samlingen med modifiseringen virtual. Dette påkreves av EF for at det skal kunne være mulig å initialisere Lazy Loading funksjonaliteten Oppdatering og innsetting av data i database Program-klassens hovedformål er å utføre innsettingsinstruksjoner mot databasen. Her overføres dataen fra ParseObjects til domenemodellene. Program består hovedsakelig av 3 typer metoder. Create() Find() Delete() Databasen skal bli periodisk oppdatert. Nylig oppdaterte XML-filer vil ligge i en egen mappe som programmet vil ta i bruk. Når «Parser»-programmet er ferdig returneres det en List<> med ParseObjectContainer-objekter. For hvert ParseObjectContainer-objekt vil det foretas en sletteoperasjon på den mest sentrale tabellen i databasen, Store. Når en «Store-entry» forsvinner vil alle «children» av denne «entryen» forsvinne. Det er dette man kaller Cascade-Deleting. Når slettmetoden er ferdig eksekvert, vil opprettmetodene utføres. Det er vanlig å flette sammen data gjennom en Update-metode. En av grunnene til at vi ikke valgte denne metoden var av tidsmessige årsaker. Bruk av Update-metode ville krevd flere kodelinjer, men hadde vi hatt mer tid så ville vi nok brukt denne metoden. 19

58 Produktrapport gruppe 10 våren Find-metodene og Create-metodene For hvert objekt utføres det Find-metoder for å finne ut om dataen allerede eksisterer. Hvis det gjør det vil det da bare være å opprette en relasjon ved å sette fremmednøkkelen. Hvis den ikke eksisterer, må det opprettes en «entry» før det kan opprettes en relasjon. Alle Create-metodene er returmetoder. Hvis et objekt suksessfullt settes inn i databasen, så returneres objektet. Hvis operasjonen ikke kan foretas vil det returneres NULL. Da kan det ikke opprettes en relasjon, men programmet vil fortsatt sette inn resten av datasettet hvis det er mulig. I Createmetodene bruker metoden savechanges() og add(object<table>) i DbContext. Dette for å kunne legge til objekter i tabeller og lagre endringer Cascade-Deleting Som nevnt tidligere i dokumentet, er det tatt i bruk Cascade deleting. Det vil si at hvis man sletter et foreldre-objekt, så vil alle barn-(children-noder)relasjoner også slettes[4]. I EF kan man enkelt aktivere denne funksjonaliteten på to måter. Det er slik at i hvis pekere til foreldre objekter har attributtet Required, vil Cascade deleting blir aktivert automatisk. Den andre metoden går ut på å eksplisitt definere slette regler gjennom Fluent- API grensesnittet. Dette bidrar til at koden blir mer oversiktlig. modelbuilder.entity<entity1>().hasrequired(s => s.entity2.withrequiredprincipal(a => a.entity1).willcascadeondelete(false); 20

59 Produktrapport gruppe 10 våren Tjenestelaget Tjenestelaget er et kombinert BusinessLogic- og DataAccesslag. Dette gjorde vi siden vi bare trengte en klasse for hvert lag. Vi laget altså BusinessLogicClass og DataAccessClass. 6.1 BusinessLogic Oppgaven til denne klassen er: Motta data fra controlleren i presentasjonslaget, etter hva som brukeren har tastet Sende det videre til DataAccessClass, som returnerer data brukeren etterspør Mappe over dataen til ViewModels i presentasjonslaget BusinessLogic inneholder mange forskjellige spørringer for å kunne gi presentasjonslaget akkurat det den trenger. Programmet inneholder tre større deler, disse er: Finn butikk gjennom fylke og kjede Søk på butikk eller avansert søk Finn nærmeste og vise i kart Finn butikk Når brukeren trykker på finn butikk i programmet kalles følgende metode i BusinessLogic: public List<ConceptModel> mapconceptname() List<String> s = searchconceptsname(); List<ConceptModel> concept = new List<ConceptModel>(); ConceptModel cm; foreach (String q in s) cm = new ConceptModel(); cm.concept = q; concept.add(cm); } List<ConceptModel> query = concept.orderby(x => x.concept).tolist(); query.reverse(); cm = new ConceptModel(); cm.concept = "Alle kjeder"; query.add(cm); query.reverse(); return query; } Det første som skjer i denne metoden er et kall på searchconceptsname som returnerer en liste med alle kjeder som ligger i databasen. Dataen som mappes over til en liste med concept(kjede) modeller. Det er denne modell som brukes til å vise frem kjedene på websiden. Når alle kjeder er mappet over sorteres listen i alfabetisk rekkefølge og legger på et valg for alle kjeder først i listen. På samme måte fungerer metoden som henter fylker fra databasen. Når brukeren har valgt fylke kalles en metode som finner de butikkene i valgt kjede og i valgt fylke. Den metoden ser slik ut: 21

60 Produktrapport gruppe 10 våren 2012 public List<StoreModel> mapstorecountyconcept(string sc, String c) List<StoreModel> storemodel = new List<StoreModel>(); List<Store> store = new List<Store>(); if (sc.equals("alle kjeder") && c.equals("alle fylker")) store = findall(); else if (sc.equals("alle kjeder")) store = searchbycounty(c); else if (c.equals("alle fylker")) store = searchbyconcept(sc); else store = searchbycountyconcept(sc, c); foreach (Store s in store) Mapper.CreateMap<Store, StoreModel>(); StoreModel sm = Mapper.Map<Store, StoreModel>(s); storemodel.add(sm); } return storemodel; Parameterne } som kommer inn er kjede og fylke. Først sjekker programmet om brukeren har valgt «Alle kjeder» og/eller «Alle fylker». Avhengig av hva brukeren har valgt kalles det på metoder som finner de aktuelle butikkene. Når det er gjort mappes butikkene over i til ViewModels og settes inn i en liste før den returneres til controlleren. Neste gang klassen kommer i bruk er når brukeren funnet en butikk som denne vil ha mer informasjon om. Da vil all informasjon om butikken mappes over til ViewModels og vises på skjermen til brukeren Søk på butikk Programmet inneholder to forskjellige typer søk. Enkelt søk etter navn, og avansert søk. Når brukeren søker etter navn kalles følgende metode: public List<StoreModel> mapstore(string txt) List<StoreModel> storemodel = new List<StoreModel>(); List<Store> store = searchbyname(txt); foreach (Store s in store) Mapper.CreateMap<Store, StoreModel>(); StoreModel sm = Mapper.Map<Store, StoreModel>(s); storemodel.add(sm); } return storemodel; } Som parameter kommer det brukeren søkte etter. Den brukes når det gjøres en spørring mot databasen i searchbyname, som returnerer en liste med butikker som inneholder teksten brukeren skrevet. Etter det mappes dataen over til ViewModels som legges i en liste og returneres. For avansert søk brukes en annen metode: 22

61 Produktrapport gruppe 10 våren 2012 public List<StoreModel> advancedsearch(string county, String concept, String city, int postal, String service, Boolean sunday, Boolean open) List<Store> query = new List<Store>(); StoreModel store; List<StoreModel> result = new List<StoreModel>(); if (postal!= 0) List<Store> stores = dac.findstorebypostal(postal); if (stores.count == 0) return null; } query = checkpostal(stores, county, concept, city, service, sunday, open); foreach (Store st in query) store = new StoreModel(); store.name = st.name; result.add(store); } return result; else if (concept!= null) List<Store> stores = dac.findstorebyconcept(concept); if (stores.count == 0) return null; query = checkconcept(stores, county, city, postal, service, sunday, open); foreach (Store st in query) store = new StoreModel(); store.name = st.name; result.add(store); } return result; } else if (service!= null) List<Store> stores = dac.findstorebyservice(service); if (stores.count == 0) return null; query = checkservice(stores, county, concept, city, postal, sunday, open); foreach (Store st in query) store = new StoreModel(); store.name = st.name; result.add(store); } return result; } else return null; } Vi har rangert alle variabler som sendes med etter hvilken som vil returnere færrest butikker, slik at det videre søket blir mindre. I eksemplet er det bare tatt med tre av syv variabler. Hvis brukeren har valgt kjede(concept) og en tjeneste(service) vil metoden gå inn i den andre if-setningen. Der finner programmet alle butikker i valgt kjede og kaller på metoden checkconcept. Den metoden gjør spørringer på alle de andre variablene som er oppgitt og etter hver sjekk filtreres butikker ut. Metoden returnerer alle butikker som har valgte verdier. Deretter settes alle butikker inn i en liste som 23

62 Produktrapport gruppe 10 våren 2012 returneres. Dette er en tungvinn metode og vi har funnet en bedre løsning på det, men vi rakk aldri å implementere den Finn nærmeste For denne funksjonen kalles det på en metode i DataAccessClass og resultatet mappes over til ViewModels. public List<StoreInfoModel> getstoresnearby(string lat, String lng) } Mapper.CreateMap<Store, StoreModel>(); List<Store> l = dac.getstoresnearby(lat, lng).tolist(); List<StoreInfoModel> List = new List<StoreInfoModel>(); int i = 0; StoreInfoModel sim; foreach (var item in l) sim = new StoreInfoModel(); sim.name = item.name; sim.latitude = item.storeadresses.first().latitude; sim.longitude = item.storeadresses.first().longitude; sim.telephone = item.telecoms.first().number; List.Add(sim); } return List; 6.2 DataAccessClass Oppgaven for denne klassen er: Ta imot variabler fra BusinessLogic Foreta spørringer mot databasen Sende resultat tilbake til BusinessLogic Finn butikk i fylke og kjede Med utgangspunkt i samme eksempel som i BusinessLogic(6.1.1) ser metoden slik ut: public List<Store> findstorebyconceptcounty(string Concept, String county) var q = context.countys.where(c => c.countyname.equals(county)).selectmany(c => c.addresses).where(a=>a.type.equals("work")).selectmany(a => a.storeaddresses).select(sa => sa.store).where(s => s.storeconcept.storeconceptname.contains(concept)).tolist(); return q; } Metoden finner County, hvor CountyName er lik County-parameteren. Hvert County-element har 0-n Adresses, som igjen har 0-n StoreAddresses, hvor hvert element har et Store-element. Hvert Store elementet har en StoreConcept. Da kan vi filtrere ut alle Store-elementer som ikke har StoreConcept, hvor StoreConceptName er lik Concept. Da finner vi alle Store elementer i et gitt fylke, under et gitt konsept. Dette returneres til BusinessLogic Søk på butikk Dette er en enkel spørring der vi sjekker butikknavnet i databasen mot det brukeren har søkt etter: 24

63 Produktrapport gruppe 10 våren 2012 public List<Store> findstoresbyname(string name) var query = (from s in context.stores where s.name.contains(name) select s).tolist(); return query; } Finn nærmeste For å finne nærmeste butikk/butikker må det gjøres rede for brukerens GEO-posisjon. Når dette er funnet sendes dataen til denne metode i DA. public IQueryable<Store> getstoresnearby(string lat, String lng) IQueryable<StoreAddress> storeaddresses = context.stores.selectmany(s => s.storeadresses).where(sa => sa.latitude!= null && sa.longitude!= null).asqueryable(); IQueryable<Store> store = storeaddresses.where(sa => sa.latitude!= null && sa.longitude!= null).select(s=>s.store).asqueryable(); } List<Store> newresult=getstoresnearbyhelper1(store, lat, lng); store = newresult.asqueryable(); return store; Den finner alle butikker som har koordinater. Metoden bruker en hjelpe-metode som bruker haversinemetode og sammenligner avstanden. Hvis avstanden fra brukeren er mindre en to kilometer skal butikken returneres. Haversine-metoden ser slikt ut: public double HaversineDistance(string longpos1, string latpos1, string longpos2, string latpos2, DistanceUnit unit) longpos1 = longpos1.replace('.', ','); latpos1 = latpos1.replace('.', ','); longpos2 = longpos2.replace('.', ','); latpos2 = latpos2.replace('.', ','); double latitudepos1 = double.parse(latpos1); double latitudepos2 = double.parse(latpos2); double longitudepos1 = double.parse(longpos1); double longitudepos2 = double.parse(longpos2); double R = (unit == DistanceUnit.Kilometers)? 3960 : 6371; var lat = ToRadians(latitudePos2 - latitudepos1); var lng = ToRadians(longitudePos2 - longitudepos1); var h1 = Math.Sin(lat / 2) * Math.Sin(lat / 2) + Math.Cos(ToRadians(latitudePos1)) * Math.Cos(ToRadians(latitudePos2)) * Math.Sin(lng / 2) * Math.Sin(lng / 2); } var h2 = 2 * Math.Asin(Math.Min(1, Math.Sqrt(h1))); return R * h2; I metoden oversettes Streng-verdiene til double-verdier. Dette for å kunne ta i bruk Haversinemetoden, som regner ut avstanden mellom to sett med koordinater. Haversine er en formel som er viktig i navigasjon, som gir korteste veien på en sfære mellom to punkter fra sine lengdegrader og breddegrader. [5] 25

64 Produktrapport gruppe 10 våren 2012 Da har vi settet blir sendt til BA, hvor det mappes over til ViewModels-objekter. Klart til å sendes til presentasjon og vises på kart. 26

65 Produktrapport gruppe 10 våren Presentasjonslaget Presentasjonslaget er delen av løsningen som er eksponert mot brukerne, og består av den mobile websiden. Websiden er utviklet som et ASP.NET MVC3 prosjekt med Razor som syntaks. 7.1 Kort om MVC MVC (Model View Controller) er et designmønster for utvikling av løsninger med et grafisk brukergrensesnitt. MVC fordeler oppgaver i tre forskjellige type filer som sammen produserer brukergrensesnittet med ønsket data. Model er ansvarlig for dataen som skal vises, views er ansvarlig for det grafiske utseende og Controllers står for funksjonaliteten til de forskjellige elementene. [6] 7.2 Kommunikasjon med databasen Avhengig av hva brukeren trykker på kalles forskjellige metoder i controlleren. Controlleren sender med informasjon om hva brukeren har trykket på og kaller på metoder i klassen BusinessLogic som ligger i tjenestelaget. BusinessLogic kaller deretter på klassen DataAccessClass som utfører spørringer mot databasen og returnerer ønsket domenemodeller. BusinessLogic mapper så over nødvendig informasjon til ViewModels i presentasjonslaget. Dataene i modellen blir så tatt i bruk i tilhørende view og vises dermed for brukeren. 7.3 Views Views er klassene i MVC3-prosjektet som står for det grafiske brukergrensesnittet til websiden. Prosjektet består av 16.cshtml-filer som gjør opp views. Da websiden har en del kode som skal vises på alle sidene, har vi en fil, _Layout.cshtml. Hvor kode som skal være persistent over alle sidene ligger. Følgende kodeeksempel er _Layout.cshtml. 27

66 Produktrapport gruppe 10 våren 2012 <!DOCTYPE html> <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso " /> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>norgesgruppen - butikksøk</title> <link rel="stylesheet" href="/content/site.css" /> <link rel="stylesheet" href=" min.css" /> <script type="text/javascript" src=" <script type="text/javascript" src=" min.js"></script> <script type="text/javascript" src=" <script type="text/javascript" src=" </head> <body> <!-- /Page1Header--> <div data-role="header" data-theme="a" data-id="head1" data-position="fixed"> <a href="index.html" data-rel="back" data-theme="a" data-icon="arrow-l">tilbake</a> <h1> Butikksøk</h1> <a href="@url.action("search", "home")" data-role="button" data-inline="true" dataicon="search" class="ui-btn-right" data-theme="a" > Søk</a> </div> <!-- /Page1Navbar --> <div id="navbarheader" data-role="header" data-position="fixed"> <div data-role="navbar"> <!-- /NavbarList --> <ul> <li><a href=@url.action("index", "store")>finn butikk</a></li> <li><a href=@url.action("nearbystores", "home")>finn nærmeste</a></li> </ul> </div> Koden som er persistent gjør opp head-delen av html-koden og jquery header og navigasjonsmeny(navbar) </body> samt tilhørende knapper. «@RenderBody()» substitueres med koden i </html> ønsket view når tilhørende side skal vises. Koden som blir sendt til klienten er dermed en sammensetning av _LayOut.cshtml og ønsket view. 7.4 Controllers Websiden har tre kontrollere: homecontroller.cs, mapcontroller.cs og storecontroller.cs. Controllerens oppgave er å kontrollere dataflyten og gjøre det smidig. Målet var å bruke lite kode i controllerene så det er enkelt å endre og vedlikeholde. 28

67 Produktrapport gruppe 10 våren 2012 public class storecontroller : Controller BusinessLogic bl = new BusinessLogic(); private static String concept; private static String county; public ActionResult Index() var k = bl.mapconceptname(); return View(bl.mapConceptName()); } public ActionResult County(string id) concept = id; return View(bl.mapCountyName()); } public ActionResult Stores(string id) county = id; return View(bl.mapStoreCountyConcept(concept,id)); } public ActionResult Details(string id) StoreInfoModel sim = bl.getinfostore(id); return View(bl.getInfoStore(id)); } Detter } er all kode i controlleren storecontroller. Denne delen av programmet tillater brukeren og velge fylke og kjede. Brukeren får etter det opp alle butikker som ligger i valgt fylke tilhørende valgt kjede. Når brukeren trykker på «Finn butikk» kalles metoden Index. Den fyller modellen for denne view med alle de forskjellige kjeder som ligger i databasen. Når det er valgt kalles County, den inneholder en parameter som er valgt kjede som lagres i denne klassen. Metoden fyller siden opp modellen med alle fylker som vises i det neste viewet. Når brukeren har valgt fylke og kjede kalles metoden Stores. Den har også en parameter, det er valgt fylke. Med hjelp av fylke og kjede kalles en metode som returnerer en liste med alle butikker som er i valgt kjede og som ligger i valgt fylke. Disse butikker mappes over til modellen for neste view å vises i en liste for brukeren. Når brukeren velger å få mer informasjon om en butikk kalles Details. Parameteren som sendes med er navnet på butikken og brukes for å mappe over all informasjon om butikken til modellen for neste view. 7.5 Models Modellen som brukes ligger i et eget prosjekt, ViewModels. Modellene inneholder samme variabler som i Domene Modellene, men er tilpasset det som skal vises på skjermen. Det er unødvendig for oss å mappe over informasjon som hvilken region butikken tilhører eller hvilke leverandører butikken bruker. Her følger et eksempel på den modellen som viser detaljert butikkinformasjon: 29

68 Produktrapport gruppe 10 våren 2012 public class StoreInfoModel public String Name get; set; } public String get; set; } public String Fax get; set; } public String Telephone get; set; } public String StreetAddress get; set; } public int Postal get; set; } public String City get; set; } public String Latitude get; set; } public String Longitude get; set; } public String OpenMonday get; set; } public String CloseMonday get; set; } public String OpenTuesday get; set; } public String CloseTuesday get; set; } public String OpenWednesday get; set; } public String CloseWednesday get; set; } public String OpenThursday get; set; } public String CloseThursday get; set; } public String OpenFriday get; set; } public String CloseFriday get; set; } public String OpenSaturday get; set; } public String CloseSaturday get; set; } public String OpenSunday get; set; } public String CloseSunday get; set; } public List<String> services get; set; } } Modellen bruker attributter fra forskjellige entiteter i databasen. 7.6 jquery Mobile jquery Mobile er et rammeverk for utvikling av webapplikasjoner for mobiler og håndholdte enheter[7]. Creuna ønsket at demonstratoren skulle bygges som en ren web-plattform, i form av en webside tilpasset bruk på mobil og andre håndholdte enheter. Valget falt dermed på jquery Mobile som verktøy for å tilpasse det grafiske brukergrensesnittet, slik at det funger optimalt på mobiler og andre håndholdte enheter jquery Mobile syntaks JQuery Mobile benytter seg av et JavaScript bibliotek og tilhørende CSS-filer for å genere elementer som skal vises. For å kalle på Java Scriptene bruker JQuery Mobile en syntaks hvor man angir en «data-role» i taggen til elementet. Rollen bestemmer egenskapene og oppførselen til elementet. Utseendet til elementet bestemmes med «data-theme»-attributtet. JQuery Mobile kommer som stander med tre temaer a, b og c. Ved å sette «data-theme»-attributtet til en av disse tilegnes de riktige reglene fra CSS-filene. I tillegg er det en rekke regler som tilegnes elementene gjennom «data-role»-attributtet. Følgende figur viser hvordan man deklarerer et element og tilleggs attributter i JQuery Mobile. 30

69 Produktrapport gruppe 10 våren 2012 <div data-role="header" data-theme="a" data-id="head1" data-position="fixed"> Her setter elementet «header», data-theme settes til «a», en data-id settes for å gjøre den persistent over flere siden og data-position settes til «fixed» for at den til en hver til skal være på toppen av skjermen. I tillegg til disse er det en rekke andre attributter som kan settes tilegnes til forskjellige elementer.[8] Standard oppsett for en JQuery Mobile-applikasjon består av en standard semantisk html-fil. I tillegg refereres det til to CSS-filer og to JavaScript-filer som JQuery Mobile benytter seg av. Alt av innhold legges i «body» og kan bestå av en eller fler siden. Hver side settes i tag med «data-role»-attributtene satt til «page» og en selvvalgt «id»-attributt. På denne måten vil en jquery Mobile-applikasjon kun bestå av en html-fil selv om det er snakk om flere sider jquery Mobile i løsningen Vi bruker JQuery Mobile på en annerledes måte en vanlig. Vi har valgt å bruke JQuery Mobile til å generere oppsettet og utseende på siden, men i stedet for å legge alle siden i samme html og navigere mellom disse med innebygde JQuery Mobile kall. Bruker vi JQuery Mobile til å utforme innholdet i viewsene i MVC3-prosjektet. På denne måten har vi en webside hvor JQuery Mobile brukes for å tilpasse innholdet til mobiler og andre håndholdte enheter. 7.7 CSS3 CSS3 benyttes som stilark for å definere utseende på applikasjonen. I likhet med HTML5 er CSS3 også noe som benyttes av JQuery Mobile. I tillegg til CSS3 elementer som text-shadow og boxshadow, benytter vi oss av webkit og moz for å generere avrundende hjørner og gradient. Dette betyr at siden ikke vil se lik ut i webkit-baserte nettlesere og Mozilla Firefox, som den vil gjøre i F. eks. Internet Explorer. Da sistnevnte ikke har støtte for webkit eller moz attributtene. Standard JQuery-Mobile-elementer har en rekke regler som definerer forskjellige attributter:.ui-btn-up-a,.ui-btn-hover-a,.ui-btn-down-a font-family: Helvetica,Arial,sans-serif; text-decoration: none; } I dette eksempelet defineres det regler for attributtene «font-family» og «text-decoration». Defineringen gjelder for elementer med data-role satt til button og data-theme satt til a. Og gjelder både for når knappen er oppe, holdes over og når den er trykket ned. I _Layout.cshtml blir linket til to stilark. Hvorav ett ligger lokalt på serveren og det andre ligger sentralt på en av jquery sine servere. Stilarket som ligger lokalt står for farger, type-fonter, skygger, avrunding av hjørner osv. og er i stor del tilpasset til denne applikasjonen. Det sentrale stilarket har regler som sørger for at elementer tilpasser seg riktig i forhold til hverandre og at siden er tilpasset mobil og andre håndholdte enheter. Vi har derfor valgt å ikke gjøre noen tilpasninger i denne. Tilpasningen av det lokale stilarket ble delvis gjort i JQuery Mobile sin «Themroller»[9], hvor en del tilpasninger ble gjort til utseende på elementene. Videre tilpasning ble gjort i Visual Studios I tillegg ble det opprettet til en del regler for elementer som ikke er en del av jquery Mobile. Disse reglene ligger øverst i den lokale CSS-filen. 31

70 Produktrapport gruppe 10 våren Sikkerhet Sikkerhet er en viktig det av et hvert system. Og spesielt viktig er det i systemer hvor hele eller deler av løsningen skal eksponeres mot offentligheten. Vi har tatt utgangspunkt i OWASP sin liste fra 2010[10] over de ti største truslene mot it-systemer. Når vi har vurdert trusselbildet mot systemet. MVC-prosjektet er den eneste delen av systemet som skal gjøres tilgjengelig for offentligheten. Vi har derfor kun vurdert sikkerheten ut ifra den delen av systemet. Følgende er et utvalg av truslene fra OWASP sin liste, som vi mente var gjeldene for systemet. Etter hvert punkt følger en forklaring på hvilke tiltak vi har gjort for å prøve å hindre den type angrep: Injection o Systemet bruker metoder som kalles på fra kontrollerne for å utføre spørringer mot databasen. Det er ikke mulig å utføre spørringer direkte fra websiden til databasen. Det er dermed ingen fare for sql-injections mot databasen i systemet. Cross-Site-Scripting o Systemet har ingen funksjonalitet hvor en bruker kan generere innhold som vises hos en annen bruker. Med mindre en angriper klarer å endre innholdet i.cshtml filen og på den måten lage en permanent endring i html-koden som vises for brukerne. Dette har vi vurdert til lite sannsynlig da angriperen da må få tilgang til å endre filer på server websiden ligger på. Insecure Direct Object References o Grunnet den lagdelte arkitekturen er den ingen andre deler en MVC-prosjektet som er eksponert for brukerne. Security Misconfiguration o I stor del handler dette om å holde rammeverket oppdatert. I prosjektet benyttes NuGet Packet Manager for å hente utvidelser. Ved å ta i bruk NuGet er det lett å se når det har kommer oppdateringer til utvidelsene, og laste dem ned. På denne måten er det lett å holde rammeverket oppdatert. Failure to restrict URL Access o Systemet har ingen eksponerte sider som ikke er tilgjengelig for alle. Derfor er det ingen fare for at brukere får tilgang til sider vi ikke ønsker. Punkter i listen som vi har vurdert som ikke gjeldene for vårt system er punkter som går på kapring av sesjoner, kryptering av brukerdata (passord Ol.), autentisering av brukere, kryptering av datatrafikk og omdirigering til andre sider. Begrunnelsen for at vi ikke har sett på disse punktene som trusler er at systemet ikke lagrer noen form for sensitiv brukerdata, det er ingen sensitiv data som sendes fra klient til tjener og det er ingen omdirigering til eksterne sider. Dermed er det ingen fare for at brukeres sensitive data skal komme på avveie. 32

71 Produktrapport gruppe 10 våren Teknologier I løpet av prosjektets løp benyttet vi oss av en rekke teknologier og rammeverk vi tidligere ikke hadde vært borte i. Følgende er en liste over teknologier vi har benyttet i prosjektet Xpath og Xdocument (Xpath select under Xdocument) Før vi begynte med Scrum prosessen i slutten av februar, hadde vi allerede begynt å se på mulige løsninger for et program som kunne hente ut informasjon fra XML dokumentene. Vi brukte noen uker hvor vi testet ut forskjellige teknologier i prototypingen. Blant annet xquery og XML Reader. Etterhvert kom vi frem til en løsning som vi syntes funket bra. For å hente ut data fra XML dokumentene sendt fra NorgesGruppen tok vi i bruk XpathSelectElement i en Xdocument klasse. Xpath brukes for å hente ut informasjon gjennom mapping-spørringer for noder i et XML dokument. 9.2 Entity Framework Code First Framework Entity Code First er den nyeste metoden innenfor Entity Framework, et.net basert rammeverk for objekt orientert mapping. Det som skiller Code First fra de tidligere metodene, «database first» og «model first» er at man definerer opp modellen ved å lage.net klasser og deretter bruke attributter i Entity Framework. Fordelen med EFCF er at det er svært enkelt å bruke, om ønskelig kan man la databasen bli laget automatisk ut ifra klassene og man har full kontroll over kodingen, da det ikke blir auto generert kode som er vanskelig å forandre på. I tillegg er det mulighet for å droppe og recreate databasen hver gang man gjør en endring i modellen. I model first og database first jobber man i en designer som auto genererer klasser. Etter at vi hentet ut informasjonen vi trengte fra XML dokumentene ved bruk av Xpath og Xdocument, tok vi i bruk Entity Framework: Code First for å opprette og fylle databasen med dataene. 9.3 jquery mobile, HTML5, CSS3 I frontenden av plattformen har vi laget en web/mobiltjeneste som formidler og behandler informasjon fra databasen. jquery Mobile er et web-rammeverk til å utvikle web-applikasjoner for håndholdte enheter. jquery Mobile utvikles av jquery project team og kan fritt brukes til private og kommersielle formål under MIT- eller GPL Version 2 lisens. jquery Mobile benytter seg av HTML5, JavaScript og tilhørende CSS-filer for å genere elementer tilpasset håndholdte enheter. HTML5 brukte vi for å strukturere innholdet i applikasjonen. JQuery Mobile rammeverket bruker HTML5 som sitt markup language, og er grunnen til at vi benyttet oss av HTML5. Vi brukte dermed deler av HTML5 indirekte ved å ta i bruk JQuery Mobile. Websiden følger standard HTML semantikk hvor applikasjonens innhold dvs. alt av tekst og JQuery Mobile elementer ligger i «body». På samme måte benytter jquery Mobile seg av CSS3 som stilark for å definere utseende. JQuery Mobile benytter seg av CSS3 elementer box-shadow og text-shadow, i tillegg til elementer fra tidligere CSS-utgaver. Webkit og moz elementer blir også benyttet i stilarkene. 9.4 Google Maps API For å realisere funksjonene «Finn Nærmeste» og «Vis Nærmeste i Kart», er det tatt i bruk Google Maps API v3. Den gode api en, de mange funksjonene og den frie lisensen var grunnene til at vi valgte å ta i bruk Google Maps. Google Maps API er fri å bruke så lenge kartfunksjonene er fritt 33

72 Produktrapport gruppe 10 våren 2012 tilgjengelig for brukerne[11]. Videre er det lett å implementere i nettsider, og har mange nytte funksjoner for websidens bruksområde. Ved innlasting av siden opprettes og initialiseres kartet. Da settes preferansene gitt i koden, og det hentes informasjon om brukerens lokasjon. Dette er gjort ved hjelp av en Google Maps API v3 funksjonene. Alternativet var å bruke HTML5. Dette er en bedre løsning fordi det er bedre tilpasset mobil og dermed kan bruke mobiltelefoners GPS-sender. Google Maps funksjonen derimot, henter bare GPS-data basert på IP-adresser. Deretter opprettes det markører ved hjelp av lokasjonsdata fra ViewModels. Kartet-funksjonalitet støtter flere markører. Dermed er det mulig å vise flere lokasjoner på kart samtidig. Ved visning av én butikk er det mulig å få frem kjøreinstruksjoner. Dette er også gjort med hjelp av Google-teknologi. 9.5 AutoMapper AutoMapper er et verktøy i Visual Studio som brukes til å mappe objekter i C#. Det AutoMapper gjør er altså å kopiere data som ligger i et objekt til et annet objekt av samme type. For at AutoMapper skal fungere problemfritt må variablene hete det samme i objektene. Verktøyet brukes på denne måten: Mapper.CreateMap<Fra-model, Til-model>(); Mapper.Map<Fra-model, Til-model>(data); Alle variabler, med samme navn i dem begge objektene, kopieres over med bare to linjer kode. Hadde vi ikke brukt AutoMapper ville vi fått mye mer og uoversiktlig kode. Vi brukte AutoMapper på flere steder i programmet. I klassen «Program» brukes det til å overføre dataen fra de objektene som lagret informasjonen fra XML-feeden til de objektene som settes inn i databasen. Det brukes også når vi overfører data fra databasen til presentasjonslaget i klassen «BusinessLogic». AutoMapper gjør arbeidet enklere og det blir lettere å vedlikeholde disse delene av programmet. 34

73 Produktrapport gruppe 10 våren Verktøy I løpet av prosjektet ble det benyttet er rekke verktøy for å kunne realisere løsningen Microsoft Visual Studio 2010 Systemet er utviklet i.net-rammeverket, MS Visual Studio 2010 har derfor vært et av våre mest brukte verktøy. Vi har brukt MS Visual Studio ved tidligere prosjekter, og Creuna bruker i stor grad også dette verktøyet Microsoft SQL server 2008 Vi har hatt databasen vår på en Microsoft SQL server og har bruk server manageren til å sjekke endringer i databasen. Siden vi har brukt Entity Framework Code First har databasen blitt laget automatisk utfra modellen vår, og server manageren har dermed ikke blitt brukt til å lage selve databasen eller å sette inn parametere Team Foundation Server For bedre å kunne samarbeide med koden i prosjektet bruker vi Microsofts verktøy for versjonskontroll, Team Foundation Server. Dette gjør at alle kan jobbe med de samme filene, men det medfører også at vi får beholdt de eldre versjonene av koden om noe skulle gå galt. 35

74 Produktrapport gruppe 10 våren Testing Det ble utført en rekke tester på systemets funksjoner. Dette ble gjort for å se at alle akseptansekriteriene var blitt oppfylt og for å kvalitetssikre løsningen. Forskjellige type tester ble utført på forskjellige deler av systemet. Enhetstesting ble gjort på metodene, manuelle tester ble utført på websidens funksjoner og akseptansetester ble gjort etter hver sprint. De første testene går på spesifikke funksjoner som knappetrykk og visning av riktig informasjon, senere testet vi overordnete krav til funksjoner på websiden Alle funksjoner Vi gikk systematisk gjennom alle funksjoner i websiden, og huket av for om funksjonen fungerte eller ikke. Funksjon Beskrivelse Status Beskrivelse Status Persistente elementer Header Visning ok Funksjon Navigasjonsmeny Visning ok Funksjon Tilbakeknapp Visning ok Funksjon ok Søkeknapp Visning ok Funksjon ok Finn butikk Visning ok Funksjon ok Finn nærmeste Visning ok Funksjon ok Søk Tekstboks Visning ok Funksjon ok Søkeknapp Visning ok Funksjon ok Avansert søk Visning ok Funksjon ok Søkeresultat Visning ok Funksjon ok Avansert søk Velg fylke(rullegardinmeny) Visning ok Funksjon ok Velg tjeneste(rullegardinmeny) Visning ok Funksjon ok Velg Kjede(Rullegardinmeny) Visning ok Funksjon ok Sted(tekstboks) Visning ok Funksjon ok Postnr.(tekstboks) Visning ok Funksjon ok Søndagsåpen(sjekkboks) Visning ok Funksjon ok Åpen nå(sjekkboks) Visning ok Funksjon ok Søkeknapp Visning ok Funksjon ok Søkeresultat Visning ok Funksjon ok Finn butikk Alle kjeder Visning ok Funksjon ok Liste over kjeder(alfabetisk) Visning ok Funksjon ok Alle kjeder Visning ok Funksjon ok Alle fylker Visning ok Funksjon ok Liste over fylker(alfabetisk) Visning ok Funksjon ok Finn nærmeste ok Vis alle i kart Visning ok Funksjon ok Liste over butikker i nærheten Visning ok Funksjon ok Butikkinformasjon 36

75 Produktrapport gruppe 10 våren 2012 Butikknavn Visning ok Funksjon E-post Visning ok Funksjon Fax Visning ok Funksjon telefon Visning ok Funksjon Adresse Visning ok Funksjon Postnr Visning ok Funksjon Åpningstider(mandag-søndag) Visning ok Funksjon Tjenester Visning ok Funksjon Vis kart Visning ok Funksjon ok Kart Butikkmarkører Visning ok Funksjon ok Brukermarkør Visning ok Funksjon ok Google Maps kart Visning ok Funksjon ok Startskjerm Informasjons om websiden(knapp) Visning ok Funksjon ok Informasjon om websiden Informasjon om websiden Visning ok 11.2 Overordnede funksjoner Vi gikk systematisk gjennom kravene vi hadde satt til websidens overordnete funksjoner, for å se om de kravene vi hadde stilt hadde blitt oppfylt. Funksjon Sluttbruker skal kunne få informasjon om nærmeste butikk Sluttbruker skal kunne få informasjon om alle butikker i en gitt kjede Sluttbruker skal kunne få informasjon om en gitt butikk Sluttbruker skal kunne få veibeskrivelse til butikk Sluttbruker skal få informasjon om hvor han/hun befinner seg Status ok ok ok ok ok 11.3 Søkefunksjoner Tester ble utført på tidsbruken til avansert søk for å undersøke om denne lå på et akseptabelt nivå og for å teste om alt fungerte riktig. Grunnet di over hundre forskjellige kombinasjonene av valg av søkekriterier har vi valgt å teste et utvalg vi mener er de mest sentrale. Tidsbruken vil i stor grad variere avhengig av hvor mange potensielle butikker det søkes på. Dette resultatet er derfor kun for å gi en generell oversikt over tidsbruken. I første del av testen er kun et søkekriterium valgt, etter det følger søk med to søkekriterier valgt og til slutt er det et utvalg av spørringer med tre søkekriterier. Loggingen av spørringene ble brukt for å beregne tidsbruken. 37

76 Produktrapport gruppe 10 våren 2012 Søkekriteria Tid(sekunder) Fylke <0.5 Tjeneste <0.5 Kjede <0.5 postnr. <0.5 Søndagsåpent <0.6 Åpen nå <0.7 Fylke/konsept 3,24 Fylke/kjede 3,313 Fylke/sted 0,084 Fylke/Søndagsåpent 7,593 Fylke/åpen nå 0,018 Kjede/tjeneste 3,369 Tjeneste/sted 0,083 Tjeneste/postnr. 0,043 Tjeneste/søndagsåpent 0,022 Tjeneste/åpen nå 0,016 Kjede/sted 0,048 Kjede/postnummer 0,043 Kjede/søndagsåpent 7,683 Kjede/åpen nå 0,02 Sted/søndagsåpent 0,122 Sted/åpen nå 0,017 0 Fylke/tjeneste/kjede 4,892 Fylke/tjeneste/Søndagsåpent 8,713 Fylke/tjeneste/åpen nå 3,161 Fylke/kjede/postnr. 0,04 Fylke/kjede/søndagsåpent 8,279 Fylke/kjede/åpen nå 3,148 Kjede/sted/søndagsåpen 4,484 Kjede/sted/åpen nå 3, Systemets funksjoner Vi kan med grunnlag i testresultatene konkludere med følge, når det kommer til systemets funksjoner. Systemet oppretter en database basert på domenemodellen Systemet henter data fra XML-dokumenter og legger i databasen Riktig informasjon fra XML-dokumentene ligger i riktige tabeller i databasen Systemet bruker butikkers adresse for å finne butikkers koordinater, og legger disse i databasen Websiden sender forespørsler til underliggende lag Underliggende lag sender data til websiden, basert på forespørsler fra websiden ok ok ok ok ok ok 38

77 Produktrapport gruppe 10 våren Enhetstesting I løsningen finnes det et prosjekt med navn Testing. Her har vi samlet alle enhetstester vi har utført. De kjøres i programmet Nunit og her gjennomføres alle tester samtidig og viser resultatene. En enhetstest er en test av en isolert metode. Den tester at metodene returnerer ønsket verdi. Vi har delt inn testene i 3 forskjellige prosjekt, validatortest, parsertest og lacationtest. De inneholder forskjellige tester mot andre prosjekter. Sammenlagt er det cirka 50 tester. Vi tester dem med et verktøy som heter Nunit. Da kjøres alle testene samtidig og vi får resultatet av dem raskt Akspetansetestkriterier I sprint reviewene på slutten av hver sprint presenterte vi arbeidet vårt for Creuna. Vi demonstrerte funksjonaliteten i koden vi hadde skrevet og viste at vi tilfredsstilte akseptansekriteriene i hver brukerhistorie. Et eksempel på akseptansekriterier er for brukerhistorie 1: Systemet skal oppdatere databasen, med data hentet fra XML-dokumenter Systemet skal legge til en ny butikk når dataen fra NorgesGruppen inneholder en ny butikk Systemet skal kunne slettemerke data 39

78 Produktrapport gruppe 10 våren Videre muligheter Informasjonsplattformen vi har utviklet er utviklet nettopp med tanke på å tilpasses forskjellige formål. Resultatet er en plattform hvor nye funksjoner og tjenester kan implementeres for å møte behovene til forskjellige kunder. I tillegg til muligheten til å tilpasse systemet for nye typer informasjon gjennom EFCF, kan man ved tilpasning i tjenestelaget utvikle mange nye former for eksponering av data mot brukere Nye funksjoner Følgende er en liste over noen mulige funksjoner og tjenester som kan utvikles til informasjonsplattformen. Kjørerutebeskrivelse I tillegg til den visuelle kjøreruten i kartet. Ville det vært praktisk med en punktbasert tekstlig beskrivelse av kjøreruten. Dette er en funksjon som ville gjort det lettere for brukere å forstå kjøreruten, samt gjort det mulig å gi brukeren mer informasjon om ruten. Alternativ/endring av rute Å kunne velge en alternativ rute og/eller kunne endre ruten manuelt, ville vært en bra funksjon å ha om brukeren ønsker en alternativ rute fra sin posisjon til butikken. Vise alle ønskede butikker i kart En mulig funksjon å implementere i websiden er mulighet for å vise alle butikker fra søkeresultatet etter et avansert søk, søk og finn butikk i et kart. Dette ville gitt brukeren mulighet til å vise butikker med ønskede attributter i kart. Dette ville økt funksjonaliteten i websiden betraktelig. Produktinformasjon En funksjon mange kjeder kunne trenge er en service som samler produktinformasjonen til butikker. Produktinformasjon kan være ting som pris, mengde, merke og hvilke butikker som fører varen. Ved å samle informasjon om varer i en database kan man bruke dette i en webserivce slik at f.eks. kunder har tilgang til varene som butikkene tilbyr. Applikasjoner for å vise butikkdata Etter at man har samlet butikkinformasjon ved bruk av informasjonsplattformen vår, er det ønskelig at man får brukt dataen til noe. Dette kan være en mobil webside slik vi har laget, men utallige andre løsninger kan benyttes. Man kunne for eksempel integrert funksjoner for å søke på butikkdata inn i kjedens egne nettsider. Administrasjonsgrensesnitt En av funksjonene vi hadde tenkt til å jobbe med om tiden strakk til er et administrasjonsgrensesnitt for butikkdataen. Dette vil det mulig for ansatte å legge til, fjerne eller oppdatere butikkinformasjon som ligger i databasen. 40

79 Produktrapport gruppe 10 våren 2012 Funksjon for å legge til spesielle åpningstider Dagens løsning inneholder kun vanlige åpningstider fra mandag søndag. Det vil kunne være ønskelig å legge til åpningstider for spesielle dager som høytider o.l. Dette kun man for eksempel gjøre gjennom administrasjonsgrensesnittet. 41

80 Produktrapport gruppe 10 våren Kildehenvisning Julia Lerman, Rowan Miller, Programming Entity Framework Code First, side

81 Produktrapport gruppe 10 våren Vedlegg 14.1 Flytdiagram Xml feed Dataimport Mobil webside Tjenestelag Domenemodell CRUD Database 43

82 Produktrapport gruppe 10 våren Klassediagram 44

83 Produktrapport gruppe 10 våren Databasemodell 45

84 Brukerveiledning for informasjonsplattform

85 Brukermanual for informasjonsplattform gruppe 10 Våren 2012 Forord Dette dokument er en brukermanual rettet mot utviklere som har gjort seg kjent med produktrapporten. Den forutsetter at utvikleren har en grunnforståelse for teknologiene brukt i prosjektet. Hensikten med dokumentet er å gi leseren en forståelse av Hvilke krav programmet har til utstyr og verktøy. Hvilke konfigureringer som trengs for anvendelse av programmet på en ny maskin. Hvordan man kan tilpasse programmet og anvende programmets funksjoner. 2

86 Brukermanual for informasjonsplattform gruppe 10 Våren 2012 Innholdsfortegnelse Forord Innledning Bygging og kjøring av løsningen Notasjoner og terminologi Konfigurering før bruk Konfigurering av dataimport Konfigurering av webside Konfigurering av loggfiler Tilpasninger Dataimport Database Innsettingsinstruksjoner Logging Data-aksess Forord Innledning Knapper og informasjonsside Finn butikk Finn nærmeste Søk/avansert søk Funksjoner

87 Brukermanual for informasjonsplattform gruppe 10 Våren Innledning Hensikten med løsningen er å realisere en informasjonsplattform for butikkdata. Data importeres fra en feed bestående av XML-filer, hvor hver fil inneholder data for én butikk. Butikkdata valideres så i henhold til valideringskrav. Videre lagres data i en database realisert med hjelp av EFCF. Programmet tilgjengeliggjør butikkdata gjennom dataaksess- og foretningslogikk-klasser, slik at de kan anvendes i presentasjonslaget. Systemet logger hendelser i dataimporten, slik at man kan se hvilke butikker som blir og ikke blir lagret i databasen, hva som er grunnen til at en butikk ikke valideres, hvilke felter den mangler, osv. I dataaksess-delen blir alle spørringer mot databasen logget. Loggingen av dataflyt og databaseinteraksjon forenkler feilsøking av programmet. 1.1 Bygging og kjøring av løsningen For å bygge og kjøre løsningen trengs MVS 2010 med.net rammeverk 4, SQL-server med administratorrettigheter. Løsningen består av to applikasjoner. Den ene kjører import av data til database, den andre kjører websiden. For å kjøre import av butikkdata høyreklikker man på(services -> NG.Services) og velger Set as startup project. Deretter trykker man run(f6). For å kjøre websiden høyreklikker(presentation -> NG.Presentation) man før man velger Set as startup project. Trykk så run(f6). Det anbefales å kjøre en import først slik at databasen inneholder butikkdata. 4

88 Brukermanual for informasjonsplattform gruppe 10 Våren Notasjoner og terminologi Følgende forkortelser benyttes i rapporten. EFCF: Entity Framework: Code First MVS: Microsoft Visual Studios Ved forklaring av hvor et prosjekt ligger i MVS brukes formen: («MVS-solution folder navn» -> «NG.Prosjektnavn» -> «Filnavn») Løsningen er strukturert ved at vi har delt inn de forskjellige prosjektene i MVS-solution folders slik at det er lettere å skille mellom prosjektenes funksjon og posisjon i den lagdelte systemarkitekturen. Det finnes seks solution folders: 1.Presentation, 2.Services, 3.XMLParser, 4.ParseObjects, Logging og Testing. 5

89 Brukermanual for informasjonsplattform gruppe 10 Våren Konfigurering før bruk Dette kapitlet beskriver konfigurering av løsningen. Konfigurering vil si å velge stier til katalogene som benyttes til XML-feed, loggfiler og server til connection string. 3.1 Konfigurering av dataimport Konfigureringene for dataimport er samlet i en egen konfigureringsfil som finnes ved å gå inn i (Services -> NG.Services -> App.config) Endre StoreDirectory value til den mappen du dine XML-filer ligger. Endre PathToLogConfig value til den fulle stien (Logging -> NG.Logging -> App.config) ligger. Dette gjør du ved å høyreklikke på logging sin App.config og klikk properties og marker full path. Endre File Management value til den mappen du vil dine XML-filer skal kopieres når de har blitt parset. I AllStores feltet har du mulighet til å sette value til enten «Yes» eller «No». «Yes» gjør at programmet vil parse alle XML som ligger i StoreDirectory. Om du setter den til No vil den parse gitt antall value i NumberOfEntries. Dette er greit å ha mulighet til når du bare vil parse et mindre antall XML ved f. Eks testing. 1. I connectionstring feltet legger du inn connection strengen til serveren du vil opprette databasen på. <?XML version="1.0" encoding="utf-8"?> <configuration> <appsettings> <add key="storedirectory" value="sti til mappe"/> <add key="pathtologconfig" value="sti til log config"/> <add key="filemanagement" value="sti til mappe"/> <add key="allstores" value="yes"/> <add key="numberofentries" value="100"/> <add key="connectionstring" value="server"/> </appsettings> </configuration> 3.2 Konfigurering av webside Konfigureringene for kjøring av websiden er samlet i en web konfigurasjonsfil som finnes ved å gå inn i (Presentation -> NG.Presentation -> Web.config). Her må du sette feltene PathToLogConfig og connectionstring til de samme stiene som i App.config. 1. Endre PathToLogConfig til den samme stien du satte i App.config 2. Sett connectionstring til den samme stien du satte i App.config Merk at for opprettelse av databasen trenger du nødvendige rettigheter siden EFCF krever at man må kunne slette og opprette en database på nytt. 3.3 Konfigurering av loggfiler Konfigureringene for loggfiler er samlet i en egen konfigureringsfil som finnes ved å gå inn i (Logging -> NG.Logging -> App.config) 6

90 Brukermanual for informasjonsplattform gruppe 10 Våren Endre stien til der du vil ha tekstfilen for aksesslogg 2. Endre stien til der du vil ha tekstfilen for importlogg 3. Endre stien til der du vil ha tekstfilen for feilmeldingslogg <appender name="accessappender" type="log4net.appender.rollingfileappender"> <file value="sti -> AccessLog.txt" /> <appender name="importappender" type="log4net.appender.rollingfileappender"> <file value="sti -> ImportLog.txt" /> <appender name="errorappender" type="log4net.appender.rollingfileappender"> <file value="sti -> Errorlog.txt" /> 7

91 Brukermanual for informasjonsplattform gruppe 10 Våren Tilpasninger Dette kapitlet presenterer forskjellige tilpasninger av løsningens funksjonalitet. Først behandles dataimport. Deretter database, innsettingsinstruksjoner og logging. 4.1 Dataimport Uthenting av nye data elementer For å hente ut nye dataelementer må det først lages en ny parse-string med et passende navn. Legg deretter inn en xdoc.xpathselectelement-spørring på ønsket XML-node. Under er et eksempel på uthenting av StoreConcept nummer som lagres i XMLStoreConcept som et ParseObject. Dette parseobjektet blir senere mappet til (Services -> NG.Services -> Program.cs) ved hjelp av AutoMapper. Så om du vil legge til flere eller endre ParseObjekter så husk å ta grep i videre i dataflytprossesen. queryresult = xdoc.xpathselectelement("/ns:customers/ns:customer[@action='update']/ns:customerstatus/../ns:affiliatio n[ns:relationship='storeconcept']/ns:partyid", xnm); if (queryresult!= null) try StoreConceptNo = (Convert.ToInt32(queryResult.Value)); } catch (FormatException fe) log.error("format on StoreConceptNo failed@ " + xstore.name); } } else log.error("storeconceptno was " + xstore.name); } Endre valideringsregler For å endre validering av ParseObjekter går du inn i: (XML Parser -> NG.XMLParser -> Validator.cs) //Critical public Boolean validatecritical(xmlstore s) if (s.name!= null && s.name.length > 0) if (s.storeno < && s.storeno > 1) if (s.active.equals("existing") s.active.equals("old") s.active.equals("new")) if (s.action.equals("update")) return true; } } } } return false; Her kan du velge om du vil legge til flere valideringsmetoder eller om du vil gjøre endringer i de som brukes. Merk at de metodene som finnes i (Validator.cs) kalles på med if-løkker i (Parser.cs). Under er et eksempel fra (Validator.cs) metoden som validerer kritiske attributter. 8

92 Brukermanual for informasjonsplattform gruppe 10 Våren Filbehandling Vi har laget en mulighet for filbehandling av XML-filene som brukes i dataimporten. Hver butikk som leses fra XML-mappen blir arkivert i valgt mappe etter å ha blitt parset. Hver fil som er blitt parset blir omdøpt til butikknavn.txt og lagret i en mappe navngitt med dataimportens dato. For å tilpasse filbehandlingen må du gå inn i (XMLParser -> NG.XMLParser -> Parser.cs) og gå til bunnen av koden. //File management String fm = ConfigurationManager.AppSettings["fileManagement"].ToString(); string date = string.format("text-0:yyyy-mm-dd_hh-mm-ss-tt}.bin", DateTime.Now); string[] splitdate = Regex.Split(date, "_"); ".XML"); ".XML"); String s = Path.GetFileName(fileEntries[i]); Boolean exists = Directory.Exists(fm + s); if (exists) File.Delete(fm + s); Directory.Move("" + fileentries[i], fm + splitdate[0] + "\\" + xstore.name); } else exists = Directory.Exists(fm + splitdate[0]); if (exists) Directory.Move("" + fileentries[i], fm + splitdate[0] + "\\" + xstore.name + } } else Directory.CreateDirectory(fm + splitdate[0]); Directory.Move("" + fileentries[i], fm + splitdate[0] + "\\" + xstore.name + } 4.2 Database Databasen i informasjonsplattformen blir generert av domeneklasser gjennom rammeverket Entity Framework Code First Legge til/ fjerne tabeller For å foreta endringer i databasetabellene forutsetter det at du har en grunnforståelse for EFCF og vet hvordan relasjoner mellom tabeller fungerer i rammeverket. Fremgangsmåten er at du går inn i prosjektet (Services -> Data) der ligger de forskjellige klassene for databasetabeller. Om du vil legge til flere felter går du inn i ønsket klasse og legger til felt. Om du vil legge til en ny tabell må du først lage den på samme måte som de andre er laget i (Services -> Data). public DbSet<Store> Stores get; set; } public DbSet<Address> Addresses get; set; } public DbSet<County> Countys get; set; } 9

93 Brukermanual for informasjonsplattform gruppe 10 Våren 2012 Deretter må den inkluderes i (Services -> DataAccess -> CodeContext.cs) på samme måte som i bildet under. Om du ønsker å fjerne en tabell fra databasen fjerner du den fra (CodeContext.cs). Det holder med å ekskludere den i (CodeContext.cs). Det vil si at du ikke nødvendigvis behøver å slette en klasse fra (Services -> Data) for at det ikke skal tas med i opprettelsen av databasen Kjøringsalternativer NG.DataAccess -> Init.cs) har du flere valgmuligheter med hva du vil programmet skal gjøre med databasen ved kjøring. Du kan for eksempel velge om databasen skal slettes og genereres på nytt ved hver kjøring. Du kan velge om databasen skal slettes og genereres på nytt kun når modellen blir endret osv. Dette er svært nyttige muligheter du har med EFCF. Under er et bilde av noen eksempler på kjøringsalternativ. namespace NG.DataAccess public class Init : //DropCreateDatabaseIfModelChanges<CodeContext> //CreateDatabaseIfNotExists<CodeContext> DropCreateDatabaseAlways<CodeContext> Forhåndsimportering av data I (Services -> NG.DataAccess -> CodeContext.cs) kan du velge å forhånds-importere data til databasen. Dette er data som legges inn før importen av parseobjektene. Veldig greit å bruke til å legge inn statisk data som navn på dager. Navn på fylker osv. protected override void Seed(CodeContext context) context.days.add(new Days() DayName = "Monday" }); context.days.add(new Days() DayName = "Tuesday" }); context.days.add(new Days() DayName = "Wednesday" }); context.days.add(new Days() DayName = "Thursday" }); context.days.add(new Days() DayName = "Friday" }); context.days.add(new Days() DayName = "Saturday" }); context.days.add(new Days() DayName = "Sunday" }); context.services.add(new Service() Name = "SESONG", Type = "Service" }); 4.3 Innsettingsinstruksjoner I NG.Service.Program utføres selve innsetting av objekter i database. I dette kapittelet tar vi for oss hvilket oppsett man kan bruke for å lage nye innsettingsmetoder Opprett-metoder Når nye tabeller opprettes kan det være lurt å lage en innsettingsmetode for denne tabellen. Da bruker man gjerne EF-metoder sammen med egne metoder. Dette kan gjøres slik: 10

94 Brukermanual for informasjonsplattform gruppe 10 Våren 2012 public void createstore(parseobjectscontainer poc) Mapper.CreateMap<XMLStore, Store>(); Store store = Mapper.Map<XMLStore, Store>(poc.Store); StoreConcept storeconcept = findstoreconcept(poc.storeconcept.storeconceptname); if (storeconcept == null) storeconcept = createstoreconcept(poc); Region region = findregion(poc.region.regionno, poc.storeconcept.storeconceptno); if (region == null) region = createregion(poc); OperatingRegion operatingregion = findoperatingregion(poc.operatingregion.operatingregionno,poc.storeconcept.storeconceptno); if (operatingregion == null) operatingregion = createoperatingregion(poc); WholeSale wholesale = findwholesale(poc.wholesale.wholesalepartyno); if (wholesale == null) wholesale = createwholesale(poc); store.storeconcept = storeconcept; store.region = region; store.operatingregion = operatingregion; store.wholesale = wholesale; } try context.stores.add(store); context.savechanges(); log.info("successfully added " + poc.store.name); } catch (Exception e) log.info("store was not added/already exists in the " + poc.store.name); } CodeContext context = new CodeContext() opprettes i starten av eksekvering av programmet. context.<tablename>.add(<object>) brukes for å gjøre klart et objekt for innsetting. context.savechanges() for å utføre operasjonen og lagre Finn-metoder For å unngå å opprette duplikater, kan det være lurt å opprette finn-metoder. Disse metodene returnerer som regel et objekt. Dette er fordi det ofte er nødvendig å tilordne pekere med disse objektene i opprettmetodene. Man kan bruke LINQ-predikatspørringer public StoreConcept findstoreconcept(string name) try StoreConcept storeconcept = context.storeconcepts.single(sc => sc.storeconceptname == name); return storeconcept; } catch (Exception e) return null; } } 11

95 Brukermanual for informasjonsplattform gruppe 10 Våren 2012 Her forventes det at kun ett element returneres. Da kan man bruke Single(). Alternativene kan for eksempel være å returner det første objektet i en liste,eller bruke Any(). Any() henter ut et hvilket som tilfredsstiller søkeparameterne. 4.4 Logging Legge til flere loggmeldinger / endre utskrift Loggingen i plattformen foregår ved at vi importerer (Logging -> NG.Logging) til prosjektet vi vil logge i. (App.config) har tre loggers: Importlogger, Accesslogger og root. Root har en egen appender som logger error og fatal fra både import og Accesslogger. Logging legges i tre forskjellige.txt-filer. Én som logger alle nivåer av import, én som logger alle nivåer av Access log, og én som logger error og fatal statements fra begge loggerne. For å legge til flere loggmeldinger instansierer du LogWrapper som vist i eksempelet under hvor du velger hvilken "logger" du vil bruke. Deretter velger du hvilket log nivå du vil ha på loggmeldingen. LogWrapper log = new LogWrapper("Importlogger"); log.error("operatingregionno was " + xstore.name); For å endre hvordan utskriften til loggfilene skal se ut endrer du layout i (App.config). <layout type="log4net.layout.patternlayout"> <conversionpattern value="%date [%thread] %level %logger: %message%newline" /> </layout> Endre nivå på logging I Log4Net fins det åtte nivåer man kan logge på, henholdsvis: OFF, FATAL, ERROR, WARN, INFO, DEBUG, ALL og TRACE. Dette gjør at det er lett å bestemme hva du vil som skal skrives til loggfilen. Jo lavere nivå du setter loggeren til å logge, desto mer logges. For å endre nivå på logging i dette prosjektet går du inn i (Logging -> NG.Logging -> App.config) der kan du endre nivå value til ønsket nivå. Se kodeeksempel under. <root> <level value="error"/> <appender-ref ref="errorappender"/> </root> <logger name="accesslogger"> <level value="all"/> <appender-ref ref="accessappender"/> </logger> <logger name="importlogger"> <level value="all"/> <appender-ref ref="importappender"/> </logger> 12

96 Brukermanual for informasjonsplattform gruppe 10 Våren Data-aksess I data-aksessklassen finner vi metodene for å hente ut butikkinformasjon fra databasen. Mange av disse metodene skal returnere spesifikke objekter, og da søker man gjerne med forskjellige parametere. Legge til nye spørringer med LINQ eller LINQ-predikatspørringer(Lamba-uttrykk) LINQ eksempel: public List<Store> findstoresbyname(string name) var query = (from s in context.stores where s.name.contains(name) select s).tolist(); if (query == null) log.info("found no stores for findstoresbyname SEARCH: " + name + "."); } else log.info("found " + query.count + " stores in findstoresbyname SEARCH: " + name + "."); } return query; } Her sendes det med en String-parmater kalt name. Denne parameteren brukes i spørringen for å hente ut alle objekter hvis navn inneholder en bestemt bokstavsekvens. Variabelen query er av datatype var og resultatet blir lagt i en liste. Datatypen var kan brukes når man er usikker på retur typen fra spørringen. Lamba-uttrykk eksempel: public List<Store> findstorebyconceptcounty(string Concept, String county) var q = context.countys.where(c => c.countyname.equals(county)).selectmany(c => c.addresses).where(a=>a.type.equals("work")).selectmany(a => a.storeaddresses).select(sa => sa.store).where(s => s.storeconcept.storeconceptname.contains(concept)).tolist(); //bedre if (q == null) log.info("found no stores for findstorebyconceptcounty SEARCH: " + Concept + "-" + county + "."); } else log.info("found " + q.count + " stores in findstorebycountyconcept SEARCH: " + Concept + "- " + county + "."); } return q; } I dette eksempelet håndteres det en spørringen med flere parametere. Her skal det hentes ut butikker ut ifra fylkesnavn og butikk-kjedekonseptnavn. 13

97 Brukermanual for mobil webside

98 Brukermanual for mobil webside gruppe 10 Våren 2012 Forord I forbindelse med hovedprosjektet Informasjonsplattform for butikkdata ble det utarbeidet en demonstrator. Denne demonstratoren gir brukere tilgang til informasjon om butikkdata, og er realisert som en webside tilpasset mobiler og andre håndholdte enheter. Brukermanualen er laget for brukere av webside. Ingen spesielle kunnskaper behøves for å ta i bruk websiden. 2

99 Brukermanual for mobil webside gruppe 10 Våren 2012 Innholdsfortegnelse Forord Innledning Knapper og informasjonsside Finn butikk Finn nærmeste Søk/avansert søk Funksjoner

100 Brukermanual for mobil webside gruppe 10 Våren Innledning Denne rapporten presenterer en brukerveiledning for en mobil applikasjon, realisert som en webside tilpasset mobiler og andre håndholdte enheter. Formålet med websiden er å vise utvalgte butikkdata, slik at brukerne kan finne informasjon som åpningstider, og lokasjon til butikker i nærheten. Websiden er tilpasset til bruk på håndholdte enheter med berøringsfølsom skjerm. For å ta i bruk websiden trengs en nettleser på en datamaskin eller håndholdt enhet. Websiden tilbyr flere måter å lete seg fram til butikker på. Brukeren kan velge butikkjede og fylke, søke på butikknavn, søke med avanserte søkekriterier samt vise de nærmeste butikkene. Brukeren får ved å velge en butikk tilgang til informasjon om butikken, som adresse, telefonnummer, åpningstider, e-post og tjenester. Websiden har en kartløsning som gir brukeren muligheten til å vise butikker i kart. Brukerens posisjon vises også i kartet. På denne måten kan websiden vise ruten mellom brukeren og en valgt butikk. Det er også mulig å vise de nærmeste butikkene på kart. Manualen er delt inn i kapitler basert på hoved funksjonaliteten til websiden: finn butikk, finn nærmeste og søkefunksjonene. I hvert kapittel ligger en kort innføring i funksjonene og en steg-for-steg guide for å utføre en ønsket handling. Til slutt er det en liste over websidens funksjoner hvor disse beskrives nærmere 4

101 Brukermanual for mobil webside gruppe 10 Våren Knapper og informasjonsside Figur 4, Finn nærmeste Figur 5, Informasjonsside 5

102 Brukermanual for mobil webside gruppe 10 Våren Finn butikk Finn butikk gjør det mulig å lete seg fram butikker ved å velge en kjede ut i fra en liste med butikkjeder for så å velge ønsket fylke. Velger man «Finn butikk» i navigasjonsmenyen kommer det opp en liste over kjeder, i tillegg er det øverst i listen en mulighet for å velge alle kjeder. Velger man en av eller alle kjedene, får man opp en liste over fylker. I tillegg til fylkene er det øverst i listen en mulighet for å velge alle fylker. Ved å velge ett av eller alle fylkene, vises en liste med alle butikker med gitt konsept i gitt fylke. Velger man så en butikk i listen vises informasjonssiden til valgt butikk, se figur 2. For å finne frem til ønsket butikk: 1. Velg Finn butikk i navigasjonsmenyen 2. Velg ett konsept eller trykk Alle kjeder 3. Velg ett fylke eller trykk Alle fylker 4. Velg en butikk i listen* For å vise ønsket butikk i kart: 1. Velg Finn butikk i navigasjonsmenyen 2. Velg ett konsept eller trykk Alle kjeder 3. Velg ett fylke eller trykk Alle fylker 4. Velg en butikk i listen* 5. Velg Vis kart *Om ingen butikker vises betyr det at ingen butikker med gitt kjede finnes i gitt fylke. 6

103 Brukermanual for mobil webside gruppe 10 Våren 2012 Figur 6, Finn butikk 7

104 Brukermanual for mobil webside gruppe 10 Våren Finn nærmeste Ved å velge Finn nærmeste i navigasjonsmenyen kommer det opp en liste med butikknavnene til de nærmeste butikkene. I tillegg er det øverst i listen en mulighet for å vise de nærmeste butikkene i et kart. Velges en butikk, vises informasjonssiden til valgt butikk, se figur 2. Velges Vis butikker i kart vises et kart med en grønn markør for brukerens posisjon og røde markører for de nærmeste butikkene. For å finne informasjon om en butikk i nærheten 1. Velg Finn nærmeste i navigasjonsmenyen 2. Velg en butikk i listen Eller 1. Velg Finn nærmeste i navigasjonsmenyen 2. Velg Vis kart» 3. Velg en butikk i kartet og trykk på butikknavnet For å vise en av de nærmeste butikkene i kart 1. Velg Finn nærmeste i navigasjonsmenyen 2. Velg en butikk i listen 3. Velg Vis kart For å vise de nærmeste butikkene i kart 1. Velg Finn nærmeste i navigasjonsmenyen 2. Velg Vis alle i kart Figur 7, finn nærmeste 8

105 Brukermanual for mobil webside gruppe 10 Våren Søk/avansert søk Websiden har to metoder for å søke etter butikker. Begge nåes ved først å trykke på søkeknappen, se figur 1. Den første søkemetoden gir brukeren mulighet til å søke på butikknavn. Den andre søkemetoden er et avansert søk. Denne nåes ved å velge Avansert søk etter å ha valgt søkeknappen. Her har brukeren mulighet til å velge mellom en rekke søkekriterier, hvor en eller flere må være valgt. Søkekriteriene er som følger: - Kjede - Fylke - Tjeneste* - Postnummer - Sted - Åpent nå - Søndagsåpent * En tjeneste er en tjeneste butikken tilbyr. Eks. Post i butikk, Bank i butikk, kontantuttak, bakeavdeling osv. Resultatet av begge søkemetodene vil være en liste over butikker som passet til kriteriene valgt. For å finne en butikk ved å søke på butikknavn: 1. Velg Søk 2. Fyll in tekstfeltet med deler av eller fullt butikknavn 3. Trykk på Søk under tekstfeltet 4. Velg ønsket butikk fra listen* Figur 8, Søk 9

106 Brukermanual for mobil webside gruppe 10 Våren 2012 For å finne en butikk ved å søke med avanserte søkekriterier: 1. Velg Søk 2. Velg Avansert søk 3. Velg en eller flere søkekriterier 4. Velg Søk nederst på siden. 5. Velg ønsket butikk fra listen* *Om ingen butikker vises, betyr det at ingen butikker passet til søkekriteria(ne)(et). Figur 9, Avansert søk 10