HØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Valg og utfordringer

Transkript

1 HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe

2 Forord I denne rapporten skal vi skrive litt om valgene som ble tatt i utviklingsprosessen. Vi kommer til å fokusere på større valg som hadde stor innvirkning på utforming av FôrIt CDS, og vi skal også skrive litt om utfordringene og hvordan vi har prøvd å løse disse. 1

3 Innholdsfortegnelse Forord...1 Innholdsfortegnelse GUI CSS Layout Oppsett av GUI Fargevalg og tekststørrelse Feilhåndtering Checked og unchecked exceptions JSON objekter Utfordringer og begrensinger i prosjektet Samsvar med kravspesifikasjon Funksjonelle krav Ikke-funksjonelle krav Produktkrav Prosesskrav Drøfting av resultatet Plattform Webservice HTML og Java Interaksjon og flyt Begrensninger Rammebetingelser Språk

4 1 I dette kapittelet skal vi skrive litt om valg som ble tatt i forhånd til brukergrensesnittet. 1.1 GUI Som tidligere nevnt er FôrIt CDS utviklet ved hjelp av Vaadin Touchkit. Når en starter å lære seg Vaadin, er det veldig lett og sette seg inn i kodestandarder, oppsett og bruk av GUI elementer. I starten av prosjektfasen satte gruppen seg ned for å bli kjent med grensesnittet til Vaadin og hva det kunne tilby. Når en lager sin første applikasjon med Vaadin får en generert en ferdig applikasjon som inneholder noe grunnleggende brukergrensesnitt elementer. Denne genererte applikasjonen inneholder de fleste elementer som Vaadin har tilgjengelig for utviklere. Vi fant ut i en tidlig fase at dette ikke var verdt og bruke alt for mye tid på, da vi ville utvikle noe eget som det ikke hadde vært laget noe lignende av tidligere. 1.2 CSS Vaadin Touchkit kommer med mange, ferdige, genererte design oppsett. Hvis en ønsker og definere sitt eget design er dette mulig ved bruk av CSS. For at Vaadin skal bygges mot mobile enheter kommer den med et widgetset. Et Widgetset er en verktøykasse som forhåndsdefinerer GUI komponenter med et visst utseende og egenskaper. Vaadin Touchkit har som standard at de bruker Vaadin Touchkit Widgetset til dette. Når en utvikler applikasjoner i Vaadin blir det laget en XML fil kalt web.xml som inneholder informasjon om hvilket widgetset som skal brukes. Denne brukes for av webserveren Jetty sin skal kjøre programmet. Om en ønsker og redefinere design på komponenter må en da kalle på style navnet som wigdetsettet bruker på komponenten. Under følger et eksempel på et CSS kall som skal redefinere designet på en knapp..v-verticallayout.v-button {} En utfordring ved å redefinere utseende på komponenter er at Vaadin sitt widgetset har en tendens til å overskrive det utvikler har definert for komponenten i CSS. Hvis det skulle skje 3

5 en feil ved lasting av CSS når applikasjonen kjører, vil applikasjonens utseende bli seende ut som widgetsettet har satt som standard. Vi har flere steder i vår kode ønsket og definere design på veldig spesifikke komponenter som Vaadin ikke har noe godt design på. Å gjøre kall på disse enkeltelementene kan være svært tidkrevende og utfordrende. Under følger en CSS kodesnutt som definerer designet på den venstre margen i gridlayouten som definerer designet på vår tabell i OrderDetailsView..v-vertical.v-margin-left,.v-horizontal.v-margin-left { padding-left: 0!important; } Kommentaren «!important» Blir brukt som en forsikring på at widgetsettet ikke skal overskrive vårt oppsett med sine design definisjoner. 1.3 Layout Vaadin bruker Layouts for å definere posisjonen til GUI komponenter i et view. Det finnes mange forskjellige layouts som kan brukes, og de er svært enkle i bruk med masse funksjonalitet implementert. I vår applikasjon har vi valgt og bygge opp alle views ved bruk av ulike Layouts. Den mest brukte layouten har vært vertikal layout som legger komponentene under hverandre. Fordelen med å bruke layouts er at en kan legge flere ulike layouts i hverandre. På hjemskjermen til applikasjonen har vi gjort nettopp dette. Under følger et eksempel hvor vi definerer en layout inne i en eksisterende layout. final VerticalComponentGroup mainbody = new VerticalComponentGroup(); final VerticalLayout orderlayout = new VerticalLayout(); <Oppsett av GUI elementer> VerticalLayout eachorderlayout = new VerticalLayout(); 4

6 eachorderlayout.addcomponent(ordernolabel); HorizontalLayout buttonlayout = new HorizontalLayout(); <Oppretter knapper og egenskaper for disse> eachorderlayout.addcomponent(buttonlayout); orderlayout.addcomponent(eachorderlayout); mainbody.addcomponent(orderlayout); Ovenstående kodesnutt er hentet fra FôrIt CDS sitt HomeView og viser hvordan vi har definert layout inni flere layouts. Vi oppretter en mainbody layout som inneholder en orderlayout med en egen ordrelayout for hver ordre som skal vises. Denne layouten inneholder igjen en horisontal layout som skal legge til noen knapper ved siden av hverandre. Under følger en figur som viser en sammenheng mellom de forskjellige layoutene i hjemskjermen. Rødt - mainbody Gult - orderlayout og eachorderlayout Brunt - buttonlayout 5

7 Figur Viser hjemskjermen til applikasjonen hvor layouts er merket ut. 1.4 Oppsett av GUI I en tidlig fase ble det bestemt at applikasjonen skulle være enklest mulig å bruke. Vårt mål var at en ikke skulle trenge mer enn fem minutter på å lære seg å navigere rundt i FôrIt CDS. For å oppnå dette fulgte vi to prinsipper: KISS-prinsippet (Keep It Simple Stupid ) o Prinsippet handler om å ikke overkomplisere applikasjonen og den funksjonalitet. Selv om koden kan være komplisert, er det viktig at dette ikke blir gjenspeilt i bruken. En god måte å løse dette problemet på, er å ha ryddig kode, og planlegge utforming av logikken før den blir laget 5 trykk regelen o En bruker skal ikke bruke mer enn 5 trykk for å navigere rundt i applikasjonen. 6

8 Figur Sitemap FôrIt CDS som viser hvordan en kan navigere seg rundt i applikasjonen. Om en f.eks. står i kartvinduet, og ønsker å navigere seg til informasjonsvinduet, skal det ikke mer enn 4 trykk til før bruker har kommet til sitt ønskede vindu. 1.5 Fargevalg og tekststørrelse I applikasjonen har vi valgt å bruke fargekombinasjoner som skal tilfredsstille kravene om universell utfordring (For mer informasjon, vennligst lest kravspesifikasjon som finnes vedlagt i sluttrapport). FôrIt CDS er bygget opp av blått, grått og hvitt med rødt på feilmeldinger, og oransje på punkter på kartet. Etter å ha gjort litt research er dette farger som passer godt sammen. Hvis en fargeblind skulle brukt vår applikasjon, ville ikke han hatt problemer med å lese tekst som blir skrevet ut på skjerm. Kombinasjonen av rødt og grønt, kan for mange være en utfordring. Vi har valgt og ikke bruke dette i vår applikasjon. Fonten brukt i applikasjonen skal være så stor og enkel som mulig å lese. Målgruppen for brukere til applikasjonen er personer mellom 30 og 60 år som gjerne har litt dårlig syn. Både på farger og tekst er derfor viktig at vi bruker et design som er lett og lese. 7

9 1.6 Feilhåndtering Applikasjonen er laget slik at den skal logge all feil som oppstår. Når applikasjonen kjøres for første gang blir det opprettet en mappe som heter logs i kjøremappen til applikasjonen. Hvis et unntak blir kastet når applikasjonen blir kjørt, logges dette i loggfilen istedenfor å bli skrevet til konsollen. For at applikasjonen skal være enklere og drifte har vi valgt å løse feilhåndtering på denne måten. En sluttbruker får ikke noe ut av å lese feilmelding som oppstår ved feil når den kjøres. Det er det utviklere og drifter som har. Vi valgte derfor å lage en egen feilmelding-skjerm som forteller sluttbruker at noe er skjedd, og at vi jobber med å løse problemet. I en tidlig fase av prosjektet hadde vi veiledning med vår kodeveileder Øystein Myhre. Han viste oss en del standarder når det kommer til logging av feil. Etter dette satte vi en standard for applikasjonen at feilmeldinger skal logges på høyest mulig nivå for å få med alle potensielle feilmeldinger som kan oppstå. 1.7 Checked og unchecked exceptions I Java er det et skille mellom checked og unchecked exceptions. Unchecked exceptions er unntak/som blir kastet som følge av feil i koden. Dette var være unntak som NullPointerException eller IllegalStateExeption. Disse unntakene må ikke behandles in metoden hvor de blir kjørt da feilen som forårsaker disse kan være så mangt. De blir først oppdaget under kompilering av koden. Checked exceptions blir kastet når det er noe feil i miljøet rundt programmet. Dette kan være feil i input som bruker skriver inn, feil i kommunikasjon med webservice. Disse feilene må behandles, da programmet må vite hva det skal gjøre hvis de kastes. For mer detaljer om hvordan vi har løst feilhåndtering, vennligst se vår vedlagte Produktrapport. 8

10 1.8 JSON objekter Webservicen som skal hente data fra FôrIt databasen til vår klient kommuniserer via en URL som klienten vår mottar. Webservicen returnerer data som JSON arrayer og JSON objekter. Når vi skal konvertere disse dataene til våre klientobjekter, har vi parset URL-en, og fått returnert innholdet som en tekststreng. Vi har deretter konvertert tekststrengen til JSON objekter som igjen blir lagret som våre objekter. Siden applikasjonen som skal settes ut i produksjon ligger på Goodtech sitt lokale nettverk, har vi valgt å gjøre om applikasjonen ørlite grann for få kjørt den utenfor Goodtech sine lokaler. Istedenfor at klienten kommuniserer med webservicen via URL, har vi valgt og lage noen lokale JSON filer med samme innhold som webservicen ville returnert. I koden vår har vi derfor laget to metoder som leser fil-innholdet, og returnerer det på samme måte som webservicen ville gjort. For å få vist mest mulig av logikken vi har laget til produktet, har vi valgt å bruke lokale JSON filer i produktet vi leverer. I vår oppgavetekst fra Goodtech står det spesifisert at vi ikke skal lage noen databaseløsning til applikasjonen. Vi har derfor ikke gjort dette i vårt leveringsprodukt heller, for at forskjellene skal være minimale. Under følger et eksempel på en JSON fil vi har lagt ved i klienten. Om en ønsker å se alle JSON filene vi har brukt, ligger dette i /main/webapp/resources mappen. [ { "factoryid":1, "orderid":83013, "orderlineno":1, "itemsize":0, "articleno":"304829", "articlename":"salmon GROUP VI1000AQSG 50ABLK", "plannedweight": , "loadedweight": , 9

11 "actualweight": } ] Koden over viser et JSON objekt for en ordrelinje. Dette er hentet fra filen CustomerOrderLines83012.json 2 Utfordringer og begrensinger i prosjektet Siden tidlig oppstart ble det bestemt at vi skulle bruke Vaadin Touchkit til å utvikle applikasjonen vår i. Programmer kodet med Vaadin Touchkit må kjøres som en webapplikasjon og ikke som en lokal mobilapplikasjon. Om gruppen hadde fått velge hadde vi valgt å lage en lokal app, da mulighetene er mye større i forhold til komponenter, design, interaktivitet mellom views, og kode. En native applikasjon har ikke behov for å kjøre i en nettleser. Det vil kjøre lokalt på enheten og applikasjonen kan da bruke diskplass direkte på telefonen istedenfor på en server. Når vi utvikler mot web er det en del faktorer en må ta stilling til. Den viktigste av de alle vil være databruk. Siden FôrIt CDS skal kjøres på mobile enheter vil sluttbrukerne sende og motta mye mobildatatrafikk. Dette koster igjen en del penger over tid, og vårt mål blir da og lage en applikasjon bruker minst mulig datatrafikk. En annen ulempe er hastighet på dynamikken i applikasjonen. På it-språket blir dette ofte kalt lagging. Dette motvirkes ved å kun vise komponenter som er helt nødvendig. Mye av våre views er derfor bygget opp ved hjelp av egendefinerte metoder som gjør denne jobben enklere for applikasjonen. Eksempelvis vil være vår ordrelinjetabell, som er et gridview med en svært enkel tabell i. I starten brukte vi Vaadin sin forhåndsdefinerte tabell, men det viste seg at denne var svært lite responsiv i bruk på mobile enheter. I tillegg var kompabiliteten begrenset på ulike nettlesere. 10

12 Nettlesere og design var også et problem under utvikling. Når en utvikler mot web i dag er det svært mange nettlesere som brukes. Vi måtte derfor ta høyde for å lage en applikasjon som på best mulig måte ville fungere på tvers av flere nettlesere. 3 Samsvar med kravspesifikasjon Følgende kapittel henvender seg til kravspesifikasjonen som er ett vedlegg i sluttrapporten. Kapittelet tar for seg i hvor stor grad applikasjonen har oppfylt de spesifiserte kravene til det endelige produktet. 3.1 Funksjonelle krav Vi kan se at alle de prioriterte funksjonelle kravene som ble lagt frem i kravspesifikasjonen har blitt oppfylt. Applikasjonen har en innloggingsmulighet som videresender en bruker til et vindu hvor en kan se relevant data for hvem som er logget inn og hva som er blitt bestilt. En kan se aktive ordre og hvor de befinner seg på et kart. En kan også se alle ordrelinjer for hver ordre. Systemet har også en egen side hvor det er muligheter for å få litt informasjon om leverandøren EWOS, Goodtech og om applikasjonen FôrIt CDS. Systemet har også implementert funksjonalitet for å skrive ut driftsmeldinger, men siden dette enda ikke er implementert i databasen til EWOS og i vår webservice blir ikke dette skrevet ut. Vi kan også se at de aller fleste kravene for ønsket funksjonalitet er implementert i applikasjonen. Det blir loggført feil og det finnes en side hvor en kan endre språket. Det å vise forventet ankomst for befrakteren har også blitt implementert i klientdelen av systemet. Problemet er det samme da EWOS sine databaser ikke får inn noen data fra skipene om når de forventer å komme frem. Ikke noe av tilleggsfunksjonaliteten har blitt lagt til i applikasjonen grunnet tidsbegrensning og kun leserrettigheter til EWOS sine databaser. Det vil være fullt mulig å legge til dette ved et senere tidspunkt for Goodtech. 11

13 3.2 Ikke-funksjonelle krav Ikke funksjonelle krav er krav som beskriver kvalitetene til et system. I vår kravspesifikasjon skrev vi om to typer ikke funksjonelle krav. Produktkrav og prosesskrav Produktkrav Vi skrev at bruker ikke skulle bruke mer enn 5 trykk for å navigere seg rundt i applikasjonen. Som nevnt i kapittel 1.4 er dette kravet utført. Vårt mål var å lage applikasjonen så enkel som mulig slik at terskelen for å lære bruk av applikasjonen skulle være lavest mulig. Etter tilbakemeldinger fra sluttbrukere har det kommet frem at disse kravene er oppfylt. Vi testet applikasjonen på personer i aldere år. Dette er personer som er innenfor applikasjonens målgruppe, som tilbakemelding fikk vi at applikasjonen var lett og navigere i, samt at funksjoner var selvforklarende. Krav som kommer til ytelse har vi testet i egne utviklingsmiljøer. Applikasjonen trenger svært lite ytelse for å kjøre fint Prosesskrav Dette er krav som omhandler arbeidsprosessen. På forhånd bestemte vi ar gruppen skulle arbeide etter KISS prinsippet, og ha sprinter etter SCRUM prinsippet på to uker. Den eneste endringen vi gjorde her, var å definere en sprint til ti dager. Totalt i hele prosjektet har vi hatt 5 sprinter. For mer informasjon om sprintene, les i den vedlagte produktdokumentasjonen. 4 Drøfting av resultatet Resultatet av vår applikasjon kan tolkes på mange måter. Oppgaven vi fikk var veldig spesifikk med hva som var ønsket av funksjonalitet, og vi har prøvd og følge denne oppgavebeskrivelsen som en mal gjennom hele prosjektet. I begynnelsen av prosjektfasen var det ikke bestemt hvem som skulle kode backend-logikken og hvordan denne skulle utføres. Vi bestemte derfor på daværende tidspunkt å putte dette på vent frem til prosjektansvarlig hadde fått diskutert med EWOS og sine kollegaer. På 12

14 samme tid hadde vi flere ting og stri med, så vi anså ikke dette som et problem. Det ble bestemt at vi skulle bruke dummy-data i applikasjonen inntil backend-logikken ble bestemt. Applikasjonen vår er utviklet ved hjelp av Vaadin Touchkit sitt rammeverk. Vaadin er et verktøy som er en videreutvikling av Google Web Toolkit (også kalt GWT). GWT er Googles eget rammeverk og blir brukt til utvikling av webapplikasjoner mot pc. Vaadin arver egenskaper og funksjoner til GWT og skal tilby brukere en mer spesifiserte funksjoner rettet mot webben. I starten tilbød Vaadin er rammeverk mot utvikling av webapplikasjoner til pc. De siste to årene har det blitt utviklet et rammeverk mot mobiltelefoner som vi har brukt til utvikling av vår applikasjon. 4.1 Plattform Når vi startet opp med utvikling av FôrIt CDS var det fortsatt ikke implementert støtte for Windows Phone i Vaadin Touchkit. Android og ios var de mobile operativsystemene som var støttet og vi fokuserte derfor på å lage en applikasjon optimalisert for disse. Hvis en skal lage en såkalt native-applikasjon er det begrenset med støtte. Det er derfor viktig at en utvikler i et veldig spesifisert utviklingsmiljø som er rettet mot et spesielt mobilt operativsystem og versjon av dette operativsystemet. Hvis en oppdatering til for eksempel Android blir sluppet, kan det være nødvendig for utvikler og rekompilere prosjektet, endre i moduler og kode for å få prosjektet til å kjøre på den nye versjonen. I tillegg er det stor forskjell i logikk og oppsett av en ios applikasjon kontra en Android applikasjon. I praksis må en derfor lage to applikasjoner. I vårt tilfelle skulle vi lage en webapplikasjon som ikke tar i bruk verktøyet som native-applikasjoner bruker. Vi trengte derfor ikke tenke på begrensninger i forhold til hva som går på hvilken plattform. Allikevel har det vært flere begrensninger og utfordringer vi har støtt på i prosjektet. 4.2 Webservice Etter hvert i prosjektet ble det bestemt at Goodtech skulle utvikle en webservice som vår applikasjon skulle kommunisere med. Webservicen skulle totalt utføre tre spørringer mot 13

15 FôrIt databasen og returnere disse i form av JSON objekter som vi skulle lese og presentere på en god måte i vår applikasjon. Siden denne webservicen ligger utenfor oppgavedefinisjon har gruppen valgt og se bort fra denne i arbeidet. Vi har vært med å definere krav og ønsker hvilke data som hentes, men vår hovedoppgave har vært utvikling av selve klienten. FôrIt databasen ligger på Goodtech sitt lokale nettverk, og man har kun tilgang til denne databasen om man kjører FôrIt CDS innenfor dette nettverket. For at vi skal få brukt det meste av vår produktlogikk i innlevering av hovedprosjekt, har vi valgt å opprette noen lokale JSON filer i prosjektet som bruker den samme logikken som webservicen bruker. Derfor vil den som evaluerer vårt produkt kunne se nøyaktig det samme som en sluttbruker vil se. Grunnen for at vi valgte å bruke lokale JSON filer har vært at vår oppgavedefinisjon omfattet klienten og arbeid ut til datalaget hvor webservicen ligger. De dataene som webservicen returnerer er helt like de lokale JSON filene vi har laget og det er derfor vi har valgt å bruke disse. 4.3 HTML og Java Vaadin applikasjoner kan kodes direkte i Java. Når prosjekter kjøres vil det kjøres på en lokal server under utvikling. Under bygging og kjøring av applikasjonen vil det genereres HTML kode ut ifra Java koden vi har skrevet. Designet i applikasjonen er satt ved hjelp av CSS. Hvis en kjører applikasjonen, åpner den i browseren og inspiserer siden vil en kun finne maskingenerert HTML kode med Vaadin og GWT navn. Det vil derfor være svært vanskelig å replikere vår side kun ved å se på HTML. 4.4 Interaksjon og flyt For informasjon om programoppbyggning, vennligst les i produktdokumentasjonen. Under følger et use-case diagream som skildrer flyten i FôrIt systemet 14

16 Figur Use-case diagram som viser den logiske sammenhengen mellom handling og aktører i FôrIt systemet. 4.5 Begrensninger Selv om Vaadin Touchkit skal kunne kjøre på alle plattformer er det fortsatt en del begrensninger når det kommer til komponenter og valg av layout /design. Et aspekt hvor dette kommer til uttrykk er i forskjellige nettlesere. Selv om applikasjonen kjører pent i Google Chrome, betyr ikke det at den kjører like pent i Internet Explorer for Windows Phone. Vi har derfor måtte teste applikasjonen opp mot forskjellige browsere jevnlig under utvikling. Noen komponenter har derfor blitt egendefinert i ettertid for at de skal kunne kjøre slik vi vil på tvers av operativsystemer og nettlesere. Den ferdige applikasjonen vår skal kunne kjøres på både mobile og stasjonære klienter uansett operativsystem og nettleser. Oppgaven vår var veldig spesifikk og vi har hatt klare retningslinjer til hva sluttbruker skal kunne se. For å få til denne funksjonaliteten har det ligget mange timer med arbeid og mange linjer med kode som har vært skrevet mange ganger før vi har vært fornøyde. Takket være vår veileder Øystein Myhre har vi hele tiden fått kode revidert og applikasjonen har blitt jevnlig testet under utvikling. For mer informasjon om testing og produktet, vennligst se på Produkt og testrapport som finnes vedlagt i dokumentasjonen. 15

17 4.6 Rammebetingelser Ved start på utviklingsfasen ble det allerede satt veldig klare rammebetingelser på hva som skulle utvikles, og på hvilken måte dette skulle gjøres. Det var opp til gruppen og finne best mulig måte og få utviklet en applikasjon som tilfredsstilte kravene som var satt. For å få til dette var det mye planlegging og analyser som skulle til. Analysearbeidet og planlegging av applikasjonen tok flere uker og var essensielt for å være kapable til å produsere det som var ønsket av EWOS. For mer informasjon om analyseprosessen, vennligst se kapittel om dette i produktrapporten. Hvis vi skal vurdere applikasjonen som en helhet opp mot oppgavebeskrivelsen, kan vi med trygghet si at vi er svært fornøyd med produktets resultat. Applikasjonen er svært enkel i bruk, den kjører på alle plattformer uten problem, designet er laget på en slik måte at ingen skal ha problemer med å lese hva som står, og fargekombinasjonene er satt i henhold til prinsippene om universell utforming. (For mer informasjon, vennligst se på produktrapport). Hele veien har vi vært veldig nøye på å dokumentere alt vi gjør. Alle skisser er tatt bilder av, vi har skrevet dagbok for hver dag, gjøremålslister er laget for hver dag, og vi har prøvd og følge sprintene vi planla til punkt og prikke. Når vi har blitt tidlig ferdig med planlagte funksjoner har vi valgt å implementere ønsket funksjonalitet. I starten av prosjektarbeidet satte vi opp en språkfunksjon som en ønsket funksjonalitet, men utover i prosjektfasen bestemte vi at språk skulle implementeres. Siden det er sannsynlighet for at applikasjonen skal føres til utlandet er det ønskelig å få applikasjonen i engelsk format. Dette har vi fått til, og bruker kan velge om han vil kjøre applikasjonen på norsk eller engelsk. Når en bruker velger hvilket språk som blir satt, så lagres dette i en cookie og nettleseren husker språket bruker satt neste gang vedkommende logger på i FôrIt CDS. 4.7 Språk En utfordring med FôrIt CDS sin funksjon av språk er at all data som blir returnert fra webservicen kommer på norsk. Dette er data som vi ikke har mulighet til å få oversatt da denne dataen sendes over nett og ikke er lokalt lagrede tekststrenger. Hvis applikasjonen 16

18 skal brukes i utlandet må det utvikles en egen database for de engelske kundene hvor all informasjon blir lagret på engelsk, da vil applikasjonen kjøre alt på engelsk. Vi har lagt opp til funksjonalitet slik at dette skal være mulig, men dette har ikke vært klart fra Goodtech sin side. 17