IT1901 Informatikk Prosjektarbeid I. Sheep Locator

Transkript

1 IT1901 Informatikk Prosjektarbeid I Sheep Locator Gruppe november 2013 Thomas Gautvedt Aina Elisabeth Thunestveit Jostein Granli Geir Forslund Roar Gjøvaag

2 Innhold 1 Introduksjon Om prosjektet Om oppgaven Om gruppen Organisering Strukturering Arbeidsorganisering Møtereferat Organiseringsverktøy Facebook Trello Google Drive Git & GitHub Gantter Gruppens forkunnskaper Ansvarsområder Planlegging Risikoanalyse Kravspesifikasjon Work Breakdown Structure Tidsestimering Gantt Use case Sekvensdiagram Utviklingsprosess Scrum Organisering i Git Utviklingsverktøy Balsamiq Mockups Xcode Tekstredigeringsprogrammer LaTeX Databaseprogrammer Filopplastning Bilderedigering Nettlesere Annet I

3 5 Arkitektur Oversikt arkitektur Database Databaseoppbyggelse RESTful API Oppbygging av APIet Teknisk forklaring JSON-string App Teknisk oppbygging Ajax-kall Templates Rammeverk jquery og jquery UI Google Maps API v Underscore.js Moment.js Design Simulator Testing Enhetstesting Systemtesting Funksjonalitet Negativitets testing Ytelse Sikkerhet Stress Gjenoppretting Brukbarhetstesting Akseptansetesting Dimensjonstesting Manualer & innloggingsdetaljer Brukermanual Brukermanual Teknisk brukermanual Innloggingsdetaljer Oppsummering 23 II 23

4 1 Introduksjon 1.1 Om prosjektet Denne rapporten er skrevet for å oppsummere resultatet av prosjektet som ble gjennomført av gruppe 6 i forbindelse med faget IT1901 Informatikk prosjektarbeid I ved NTNU i Trondheim høsten Målet med dette prosjektet er å simulere en utviklingsprosess der en gruppe skal utvikle et program for en fiktiv kunde. Hovedmålet er at gruppen skal oppleve og prøve vanlige metoder og teknikker, i hovedsak Scrum, for å jobbe som en gruppe og erfare hvordan disse metodene fungerer i praksis. Et annet aspekt ved oppgaven er å videreutvikle gruppens kunnskaper om programmering. Vi har valgt å løse oppgaven ved hjelp av et RESTfult web API, som er skrevet i PHP og som snakker med en HTML5 app. Vår løsning er ytterligere forklart i kapittel Om oppgaven Oppgaven går ut på at vi skal utvikle et system for bønder til administrering av sauer. Noen av de mest vesentlige funksjonene ved dette programmet er at bonden skal ha en oversikt over alle sauene han eier og han skal kunne se hvor sauene er lokalisert på et kart. Det skal også bli sendt varsel til bonden dersom en sau er under angrep. For mer informasjon om kravspesifikasjonen se kapittel Om gruppen Gruppe 6 består av fem personer med ulik utdanningsbakgrunn og erfaring innenfor fagfeltet informatikk. Alle går pr. i dag ved linjen Bachelor i Informatikk (BIT). De 5 personene er Thomas Gautvedt 21 år som er vår mest erfarne programmerer. Aina Elisabeth Thunestveit 23 år, med bachelor i matematikk, som er den som har kommet lengst i studieløpet. Jostein Granli 21 år, første år på NTNU etter årskurs i informatikk ved høyskolen i Molde. Roar Gjøvaag 31 år, startet på informatikkstudiet i fjor etter mange år hos Nortura i Trondheimsområdet og Geir Forslund 23 år, første års student ved informatikk tidligere studier hos NTNU gjør at han befinner seg mellom første og andre årstrinn. 1

5 IT1901 Informatikk Prosjektarbeid I, Sheep Locator Gruppe 6 Figur 1.1: Fra venstre: Thomas Gautvedt, Jostein Granli, Aina Elisabeth Thunestveit, Roar Gjøvaag, Geir Forslund 2 23

6 2 Organisering 2.1 Strukturering Arbeidsorganisering Det første vi gjorde var å bestemme hvordan vi skulle organisere arbeidet. Vi startet med å gjøre oss kjent med hverandres erfaringsnivåer og interesser. Etter å ha kartlagt erfaring og kompetanse i gruppen ble vi enige om hvordan Scrum-modellen (4.1) skulle løses. Det viste seg raskt at den største utfordringen til gruppen ble timeplanen, da mer eller mindre samtlige deltok i forskjellige kurs og fag det aktuelle semesteret. Dette førte til at den sammeslåtte timeplanen ikke hadde mange åpninger. Tross dette fant vi timer der alle kunne være med på arbeidsøkter og møter. Dette ble fastsatt til å være torsdager 10:15-12:00. I tillegg skulle vi ha korte Scrum-møter på tirsdager, onsdager og fredager. Bare to uker inne i prosjekter merket vi at dette ikke var en optimal løsning for vår gruppe. Arbeidsøktene og møtene fungerte bra, mens de korte møtene mellom forelesningene ikke var hensiktsmessig fordi tiden ble brukt lite effektivt. Vi bestemte oss for å revurdere møtestrukturen, ved at kortmøtene ble byttet ut med jevnlig oppdatering gjennom sosialnettstedet Facebook (2.2.1) og prosjektstyringsverktøyet Trello (2.2.2). I tillegg utvidet vi med lengere arbeidsøkter, slik at læringsutvekslingen ble maksimert. Møtene ble fastsatt til onsdager 12:15-14:00 og torsdager 10:15-12:00, med et potensielt ekstramøte på tirsdager ved behov. Arbeidsøktene ble en arena for diskusjon, problemløsing og utveksling av kompetanse. Siden samtlige i gruppen var interesserte i å få mest mulig ut av dette faget, ble det et sterkt fokus på å få muligheten til å sitte sammen. Møtene begynte alltid med en gjennomgang av forrige møtes saksliste samt eventuelle demonstrasjoner av nye funksjoner i programmet. Etter faste punkter og gjennomgang av eventuelle sprinter, ble tiden brukt til praktisk arbeid. Stort sett ble programmeringen utført på individuell basis Møtereferat Møtereferat er skrevet som oppsummering av hva som har skjedd av ekstraordinære saker og en statusrapport for applikasjonen. Møtereferatene ble i utgangspunktet ført pr. møte, men grunnet omstrukturering av møtene ble referat skrevet pr. uke (se vedlegg: møtereferat), noe som reduserte mengden dokumenter og ga en bedre oversikt i hver sprint. Ellers er formålet med møtereferatene å holde seg oppdatert på prosjektet når man er fraværende. 3

7 2.2 Organiseringsverktøy Noe som tidlig ble bestemt var bruk av hjelpemidler til prosjektet. Det finnes et bredt utvalg av organiseringsverktøy, det var derfor viktig for oss å raskt orientere oss om behov. Vi spurte oss selv hvilke hjelpemiddeler og verktøy som kunne få oss til å gjøre en bedre og mer effektiv jobb for prosjektet. Noen av verktøyene som ble tatt i bruk, ble valgt ut på bakgrunn av risikoanalysen (se vedlegg: risikoanalyse) og dens tiltak, for eksempel backup-løsning Facebook Facebook ble kommunikasjonsplattformen til gruppen, hvor medlemmene fikk gitt og mottatt raske beskjeder om eventuelle utfordringer med prosjektet og eventuelle fravær i oppkommende møter. Vi valgte denne plattformen fordi alle på gruppen allerede hadde etablert en bruker der, og fordi løsningen var godt integrert med mobiler og de dagelige rutinene til samtlige av oss Trello Hovedverktøyet i forhold til prosjektorganisering og prosjektets praktiske arbeidsoppgaver ble Trello. Trello er et rent prosjektorganiseringsverktøy, som skal være laget for mindre prosjekter som dette og verktøyet ble også anbefalt av gruppens veileder. Verktøyet kan forklares som en digital Post-it vegg, hvor man lager notater om gjøremål, delegerer oppgaver, diskuterer løsninger og funksjonalitet. Programmet er lett å bruke og skapte raskt en oversikt over arbeidsoppgavenes status. Da dette var det beste alternativet og på grunn av anbefalingen ble dette et naturlig valg for gruppen Google Drive For å dekke opp for en av våre risikoer som var backup (se vedlegg: risikoanalyse), bestemte vi oss for at alt skulle lagres i Google Drive. Med Drive fikk vi i tillegg sammarbeidet tett om rapportskrivingen, diagram- og møtereferat justering. Vi vurderte å bruke en sky-løsning som Dropbox, men bestemte oss for å kun bruke Google Drive da den tilbydde samme funksjonalitet pluss samarbeidsmulighetene som vi har hatt stor nytte av Git & GitHub Vi har brukt versjonskontrollsystemet Git for å utvikle sammen uten å måtte bekymre oss for å skrive over hverandres filer. Vi vurderte en stund å bruke SVN da det er enklere å sette seg inn i, men grunnet tidligere erfaringer på gruppen, bestemte vi oss for å bruke Git og heller gi de som ikke hadde den samme erfaringen et kort introduksjonskurs. En beskrivelse av hvordan vi har jobbet med Git finnes i kapittel Gantter Etter litt utprøving av verktøy for å utarbeide et Gantt-diagram, falt vi på et onlineverktøy ved navn Gantter 1. Dette verktøyet ble valgt først og fremst fordi det hadde funksjonaliteten vi hadde behov for, både med tanke på eksportering, muligheter for å sette underkategorier og arbeidstimer

8 2.3 Gruppens forkunnskaper Gruppen består i hovedsak av studenter ved informatikkstudiet og majoriteten er på 2. året som Thomas Gautvedt, Jostein Granli og Roar Gjøvaag, mens Aina Elisabeth Thunestveit og Geir Forslund følger et mindre tradisjonelt studieløp. Ellers er gruppen satt sammen av meget forskjellige personligheter og bakgrunner. Thomas Gautvedt Arbeidserfaring som webutvikler Programmeringserfaring Nesten ti års erfaring med PHP, HTML, Javascript, CSS, jquery og databasesystemer, samt generell kunnskap om Java, Python, Objective C og C# Aina Elisabeth Thunestveit Bachelor i matematikk Programmeringserfaring Jostein Granli Generell Java, Python, Objective C, C# og generelt om databaser Programmeringserfaring Geir Forslund Generell Visual basic, Java, Python, databaser og strategisk webdesign Programmeringserfaring Roar Gjøvaag Generell Java og databaser Programmeringserfaring Generell Java, Python og databaser 2.4 Ansvarsområder Alle i gruppen har deltatt i alle deler av prosessen, men ansvarsområdene har vært formelt fordelt innad i gruppen. Ansvarsområdene er delt ut etter ønske og forkunnskaper. Områdene definerer ikke nødvendigvis hvem som har gjort jobben innenfor de enkelte områdene. Personen som har hatt hovedansvaret for at jobben ble gjennomført, har også fungert som en ressurs oppimot området det skulle gjelde. Thomas Gautvedt Hovedprogrammerer Git-ansvarlig App-medhjelper Aina Elisabeth Thunestveit Simulator-ansvarlig Testing Jostein Granli 5 23

9 App-medhjelper Diagram-ansvarlig Geir Forslund Databaseansvarlig App-hovedansvarlig Roar Gjøvaag Scrum-master API-ansvarlig Rapportansvarlig Git-ansvarlig har vært personen som har gått igjennom kode og godkjent pullrequsts når arbeidet var fullført. Mer informasjon om hvordan vi har jobbet og organisert i Git er beskrevet i kapittel

10 3 Planlegging 3.1 Risikoanalyse Dette var noe av det første gruppen satte i gang med, for å være forberedt på utfordringer vi kunne møte allerede fra starten. Risikoanalysen (se vedlegg: risikoanalyse) ble utarbeidet ved idèmyldring, tidligere erfaringer og tips fra veileder. Det essensielle spørsmålet var, Hvilke risikoer kan man stå ovenfor i et slikt prosjekt?. Samtlige punkter i analysen ble så gradert ved å sette en poengverdi for frekvens og konsekvens. Disse ble så multiplisert og dannet vår prioriteringsliste. Prioriteringslisten viste oss hvilke punkter vi måtte være ekstra oppmerksomme på. Deretter iverksatte vi forebyggende tiltak i forhold til prioriteringen. Se vedlegget for en mer grundig forklaring av hvert enkelt risikopunkt og dets forebyggende- og strakstiltak. I retroperspektiv ser vi også at denne listen var i henhold til faktiske forhold, men vi har vært relativt skånet for utfordringer og deres konsekvenser. Fravær fra møtene var den hyppigste, men denne typen risiko hadde svært lav konsekvens. Hadde vi ikke iverksatt forebyggende tiltak kunne dette vært destruktivt for prosjektet. 3.2 Kravspesifikasjon Vår tolkning av kravspesifikasjonen er ganske lik kundens (se vedlegg: kundens kravspesifikasjon). Underveis i prosjektet fikk vi opplyst at vi ikke skulle legge stort fokus på kravspesifikasjonens feilsituasjoner. Det er derfor ikke nevnt i vår kravspesifikasjon Vår kravspesifikasjon: Brukeren skal ha et passord og et brukernavn for å få tilgang til systemet Hver sau skal rapporterer sin lokasjon tre ganger i døgnet. Rapporteringen til samtlige sauer er spredt utover for å begrense påkjenningen på systemet. Brukeren og eventuelle varslingsadresser som er lagt til i systemet skal motta varsel både i applikasjonen og på e-post, dersom en sau er under angrep. Vi benytter en webapp som kommuniserer med en webserver (se kapittel 5 for oppbygging av arkitekturen) Større tilpasningsdyktighet Kan brukes på enheter som de fleste allerede eier og bærer med seg stort sett overalt Løsningen kan benyttes så lenge man har dekning for mobildata, praktisk under oppgaver som for eksempel sauesanking da man gjerne befinner seg i høyfjellet. Brukeren slipper noen form for installasjon, dette vil senke terskelen for å ta i bruk applikasjonen. 7

11 Systemet er dimensjonert for at over 200 bønder og sauer skal kunne håndteres samtidig. Responstiden til systemet skal være bra selv med høy belastning. Se for systemtesting av ytelse. 3.3 Work Breakdown Structure Formålet ved å sette opp et WBS-diagram (se vedlegg: Work Breakdown Structure) er å skaffe en oversikt over hovedoppgavene i prosjektet for å forenkle organisering og tidsestimering. Vi valgte å dele inn WBS i fem deler: organisering, planlegging, utvikling, testing og rapportering. Dette gjorde organiseringen av underpunktene enklere. 3.4 Tidsestimering Dette er veldig viktig for at man skal klare å levere et ferdig produkt i henhold til kravspesifikasjonene. Vi laget et Gantt-diagram for å ha en god oversikt som vi kunne følge. Da vi laget denne estimerte vi ut i fra vår egen erfaring, råd fra stud.ass og det som kom frem i forelesningene. Vi hadde i tillegg to faste holdepunkter i prosessen, midtveispresentasjonen og selvfølgelig leveringsfristen. De fleste av oss hadde ikke noe særlig erfaring med større prosjekt som dette, men vi hadde alle programmeringserfaring fra vår tid ved NTNU. Oppgavene som måtte gjøres ble lagt i sprinter basert på backlogen.(se vedlegg: backlog, sprinter og burndown chart), som vi deretter plasserte i Ganttdiagrammet vårt. Da vi hadde kommet frem til punktene vi trengte, estimerte vi timer på de forskjellige oppgavene. Vi hadde som mål å holde oss innenfor 10 timer pr. person pr. uke og med sprinter på to uker hadde vi ca. 20 timer pr. person i hver sprint. Sprintene ble lagt opp slik at de sammenfalt i stor grad med møtene våre med stud.ass. Det førte til at vi hele tiden fikk en indikasjon på hvordan vi lå an. Vi erfarte at ikke alle estimeringene våre holdt vann, både den ene og den andre veien. Heldigvis hadde vi tatt våre forholdsregler, og hadde god kontroll da det viste seg at vi måtte justere litt på estimeringen. Dette er detaljert forklart i vedlegget om risikoanalyse og illustrert i burndown chart. 3.5 Gantt Gantt-diagram er en type stolpediagram, som skal illustrere planen for prosjektet. I utgangspunktet skal den sette start- og sluttdatoer for sprinter og individuelle aktiviteter. Gantt-diagrammet har tatt utgangspunkt i Work Breakdown Structure og tidsestimeringen vi gjorde. Diagrammet gir raskt en oversikt over hvor mye som er gjort og hvor mye som står igjen, med forbehold om at tidsestimeringen er riktig. 3.6 Use case Use case er et svært enkelt diagram for å se overordnet oppbygging av systemet. Vi har laget et enkelt Use case-diagram for å illustrere de forskjellige valgene og tingene som brukeren, systemet og sauen kan foreta seg. Se vedlegget om Use case-diagram for mer detaljer. 8 23

12 3.7 Sekvensdiagram Hensikten med et sekvensdiagram er å se flyten og levetiden til ulike objekt, i tillegg til hvilke funksjoner som blir kjørt. I en vanlig Java-applikasjon, lever objektet gjennom hele programmet sin kjøretid, så sant du ikke dreper det manuelt eller det ikke er i bruk og blir plukket opp av Java sin garbage collection. Siden vi har laget en webapplikasjon vil vi i vårt tilfelle ikke få utnyttet sekvensdiagrammet til sitt fulle, fordi hvert brukerobjekt dør ved et nytt kall. Det brukeren får returnert i en forespørsel er borte til neste gang. Vi har allikevel laget noen sekvensdiagram som du kan se i vedlegget sekvensdiagram. 9 23

13 4 Utviklingsprosess 4.1 Scrum Scrum er et iterativt og inkrementellt utviklingsrammeverk for programvare-prosjekter og er en av modellene innenfor smidig programvareutvikling. Rammeverkets fokus er å ha et fleksibelt miljø der gruppen skal jobbe mot et felles mål og hvor samlokalisering av gruppemedlemmene er en viktig del. Fokuset førte til tett og hypping kommunikasjon innad i gruppen. Dette blir ofte oppnådd med hyppige Scrum-møter, som er korte daglige møter der alle i gruppen oppdaterer hverandre om status i prosjektet. Andre prinsipper innenfor Scrum, er det innebygde fleksibilitets prinsippet. Det i motseting til andre tradisjonelle rammeverk som er mer avhengig av forutsigbarhet og omfattende planlegging. Hvordan Scrum implementeres i prosjekter varierer mye, alt i fra mange applikasjonsverktøy til meget enkle redskaper som lapper på en tavle. Vi valgte å bruke en del organiseringsverktøy (se 2.2 for komplett liste) da det forenklet organiseringen. Gruppen skal også ha en Scrum-master som skal stå for den organisatoriske tilretteleggelsen for gruppen. Scrum-master skal ikke være en gruppeleder, men bindeleddet mellom gruppen og kunde, som i vårt tilfelle var stud.ass. Ellers skal denne personen prøve å fjerne hindringer og legge til rette for at gruppens arbeid skal kunne gjennomføres mest mulig effektivt. Personen skal også være utfordreren i gruppen, ved å stille de vanskelige spørsmålene samtidig som han/hun hever gruppens fokus og arbeidsmål. Gruppen valgte Roar Gjøvaag som Scrum-master, da han var den første som tok initiativ til at gruppen skulle samles tidlig i prosjektet og samtidig påtok seg mye av det organisatoriske ansvaret. Han hadde også prosjekterfaring fra tidligere. Summen av dette gjorde valget enkelt da posisjonen som Scrum-master skulle fylles. 4.2 Organisering i Git Git fungerer slik at prosjekter er delt opp i såkalte repositories. Man kan se på dette som et lagringssted for kode. Da vi hadde tre prosjekter opprettet vi tre repositories i Git, et for REST-APIet, en for appen og en for simulatoren. Git fungerer også slik at hvert enkelt repository er delt opp i branches. Det vil i all enkelhet si at koden kan være forskjellig i to brancher og når de samles så merges koden sammen og Git er smart nok til å skjønne hvilke endringer som skal overskrive utdatert innhold. Si at du lager en ny branch fra Develop og fikser en feil i en fil. Når denne fila er lagret og endringene er sendt til Git, så kan disse branchene merges sammen igjen. Git har da oppdaget at den nye branchen har endringer som ikke finnes i Develop og syr disse endringene sammen. Ved bruk av Git har vi derfor unngått å ha problemer med at folk skriver i samme filer og skriver over hverandres endringer. Vi har prøvd å kjøre et ryddig miljø hvor alle repositoriene har basert seg på Develop hvor vi har merget inn endringer, fikser og ny kode. Git-ansvarlig har gått over pull-requests (som det heter når man ønker å merge noe sammen), og sett at koden var god nok. Har det vært mangler eller feil har forespørselen blitt avslått og ytterlige endringer blitt krevd. På denne måten har vi klart å utelukke en god del bugs 10

14 og problemer allerede tidlig i utviklingsprosessen ved å være veldig kritisk til egen kode. 4.3 Utviklingsverktøy Balsamiq Mockups Balsamiq Mockups ble tidlig brukt for å raskt og enkelt skape bilder/mockups av hvordan vi så for oss at programmet skulle se ut. Vi gjorde dette for å gjøre den videre utviklingsprossessen lettere da vi som gruppe hadde visualisert det endelige resultatet. Det endelige resultatet ble i stor grad likt slik vi hadde skisset det ut i starten. Noen endringer ble gjort underveis, men i all hovedsak fungerte skissene som et godt utgangspunkt gjennom utviklingen (se vedlegg: Mockups) Xcode Vi brukte Xcode som er et Integrert utviklingsmiljø (eller IDE på engelsk) på Mac OS X for å utvikle blant annet iphone-apps. Xcode kommer med en komplett simulator for iphone som gjorde det enkelt for oss å teste hvordan webappen kom til å se ut og føles på en mobil enhet Tekstredigeringsprogrammer Da prosjektet vårt hovedsaklig har bestått av PHP, HTML, JavaScript og CSS som i bunn og grunn er rene tekstfiler, har medlemmene på gruppen stått veldig fritt til å velge sine egne tekstredigeringsprogrammer. Av tidligere erfaringer ble Notepad++ og Sublime Text 3 anbefalt. På Mac OS X ble Coda også brukt. Disse programmene er relativt like og tilbyr på autofullføring av metoder, syntaks-fremheving og mange andre funksjoner som gjør utvikling og programmering enklere LaTeX Vi valgte å skrive rapporten i LaTeX, i stedet for Word som alle har god kjennskap til, fordi vi hadde hørt at det var et godt verktøy for tekstformatering og ønsket å lære oss noe nytt. Noen på gruppen har benyttet LaTeX før og dette gjorde overgangen lettere for resten. At vi har brukt LaTeX er årsaken til at rapporten er noen sider for lang, dette grunnet mye white-space i LaTeX sin formatering Databaseprogrammer Ettersom vi brukte MySQL (5.2), har vi benyttes oss en del av phpmyadmin, som er et grafisk grensesnitt for database-administrasjon. phpmyadmin er ett av de mest populære administrasjonsverktøyene for MySQL og er derfor standard software på de fleste servere. Dette er årsaken til at vi har brukt det. I tillegg har vi også benyttet oss av MySQL Workbench og Sequel Pro som også er databaseadministrasjonsverktøy Filopplastning For å laste opp filer på forskjellige servere har vi utelukkende brukt Filezilla som støtter filoverføring over FTP- og SFTP-protokollene. Samtidig har også tekstredigeringsprogrammet Notepad++ integrert FTP-støtte, som vi har brukt når vi har utviklet rett i utviklingsmiljøet Bilderedigering For å lage logoer, ikoner og andre grafiske elementer har vi benyttet oss av Photoshop CS6. Noe av grafikken er basert på gratis vektor-filer som vi har funnet på nettet, men det meste er laget fra bunnen av. Alle Photoshop-filene ligger i app-prosjektmappen

15 4.3.7 Nettlesere For å teste hvordan appen og simulatoren fungerer har vi benyttet oss av de mest vanlige nettleserne. Det inkluderer de nyeste versjonene av Opera, Chrome, Firefox og Safari. Dette ga oss riktignok bare et halvveis korrekt bilde da appen er laget og utformet for mobile enheter. I tillegg til å teste og utvikle i disse nettleserne har vi benytttet oss av Safari på ios og Chrome på Android-systemer Annet Vi har tatt i bruk en rekke biblioteker i appen for å gjøre arbeidet med utviklingen så enkel som mulig. Disse er listet opp under arkitektur-forklaring i neste kapittel

16 5 Arkitektur 5.1 Oversikt arkitektur I dette prosjektet har vi valgt å lage en webapp som enkelt kan integreres i smarttelefoner som iphone, Windows-Phone og modeller som kjører Android. Vi valgte å gå for en webapp-løsning fordi dette er mye enklere å lage enn en Native-app 1. En webapp er ikke annet enn en nettside som presenteres som et eget program. Prosjektet er satt opp slik at selve appen ikke er noe annet enn HTML5, CSS 2 og Javascript. Javascriptet snakker til backend-systemet som er et RESTful-API skrevet i PHP 3. Kommunikasjonen mellom APIet og appen er forklart i kapittel om Ajax. APIet lagrer data i en MySQL-database. 5.2 Database Da vi skulle velge database-løsning sto valget mellom MySQL og PostgreSQL. Disse løsningene er i grunn veldig like og valget falt på MySQL hovedsaklig fordi gruppen hadde mer erfaring med dette fremfor PostgreSQL. I tillegg ønsket vi å drifte det ferdige produktet på en stabil server hvor vi ikke trengte å tenke på oppe- og responstid. Thomas Gautvedt eier allerede en webserver hos Webhuset og vi valgte tidlig i planleggingsfasen å bruke de som webhotell. Webhuset tilbyr MySQL-servere, men ikke PostgreSQL, og dette var også en faktor som påvirket oss. MySQL er verdens nest mest brukte databasesystem, så vi visste at vi gikk til et alternativ som var godt utprøvd og stabilt Databaseoppbyggelse Databasen er bygget opp slik at brukere og system er separert med en mange-til-mange-relasjon. Dette betyr at et system kan ha flere brukere. Vi syntes dette virket logisk om en gård skulle ønske å ha flere brukere i sitt system (for eksempel bonde og nabobonden). På samme måte er relasjonen mellom sauer og system satt opp. En sau kan høre til flere systemer. Vi har gjort dette med sikt på videreutvikling. Slik det er satt opp nå vil dette skape problemer med varsling, men kan på sikt føre til at flere bønder kan samarbeide om en flokk sauer. Om dette er et helt realistisk bilde har vi ikke undersøkt, men det er satt opp slik at det er mulig. Se vedlegg om videreutvikling for mer detaljer. Til sammen består databasen av åtte tabeller hvor to av disse brukes til mange-til-mange-relasjoner. I tillegg brukes tre til lagring av bruker, system og sau. De resterende tre databasene lagrer informasjon om varsling, logg-innlegg og masterpassord som brukes for å logge inn i simulatoren. Vi tilpasset databasen slik at all tekst lagres som UTF-8, som sikrer at vi ikke får problemer med tegnsetting og spesialtegn i det norske alfabetet. Alle felter som e-post, navn osv er lagret såpass sto- 1 Med andre ord programmert i programmeringsspråket som støttes av operativssytemet til mobilen. 2 Cascading Style Sheet. 3 Hypertext Preprocessor. Et populært serverside programmeringsspråk. 13

17 re at ingen burde komme i en situasjon hvor et realistisk navn eller e-post er for langt å lagre i databasen. I tillegg har vi utnyttet indekser på IDer i alle tabellene som gjør at oppslag går mye fortere. IDer er satt til auto_increment som gjør at IDene alltid vil være unike for hver tabell. For mer informasjon om databaseoppbyggingen, se vedlegg om databasediagram. 5.3 RESTful API I planleggingsfasen kom vi frem til at vi ønsket å lage et API for å servere data til appen. I en ordentlig webapp skal ikke appen selv snakke med databasen, men snakke til et API som tar for seg henting av informasjon og returnerer dette til webappen som behandler og viser data slik det selv vil. Med en slik løsning kan APIet brukes i forskjellige programmer uten å måtte skrives spesfikt for det ene eller det andre. Det er også en mye mer moderne løsning og er noe som er mye brukt for tiden. Det er derfor ikke noe problem å få hjelp på Internett, eller finne eksempler på hvordan løsningen kan utvikles og struktureres. Vi diskuterte flere forskjellige API-løsninger. I all hovedsak så vi på løsninger for Websockets, RESTløsninger og SOAP. Vi valgte tidlig å gå bort fra SOAP fordi vi innså at det kom til å bli en stor jobb å programmere en komplett SOAP-løsning. Vi valgte også å gå bort fra Websockets for å få appen til å fungere på flest mulig mobile enheter, da Websockets er en teknologi som ikke fungerer på de eldste mobilene. Vi valgte derfor å gå for et RESTfult API Oppbygging av APIet APIet er skrevet i PHP. Vi diskuterte lenge valget mellom PHP og Python. Flesteparten hadde mest erfaring med Python fra tidligere fag på NTNU, og vi kunne for eksempel laget et RESTfult API med Webrammeverket Bottle i Python. Problemet var at vi ønsket å implementere en løsning for templates også, dette er beskrevet i kapittel Vi kunne mest sannsynlig tilplasset Bottle til å fungere slik vi ville, men endte til slutt opp med å skrive et rammeverk helt fra bunn av selv. Da vi skulle begynne på scratch var det mye enklere å gjøre dette i PHP. PHP er ett av de mest brukte programmeringsspråkene i hele verden, og store nettsider som Facebook og Wikipedia er skrevet i dette språket. Vi visste dermed at vi gikk til et stabilt, populært og mye testet språk. Thomas har også programmert i dette språket tidligere, og anbefalte det da det ansees for å være veldig enkelt, raskt og med god implementasjon mot databaser Teknisk forklaring Hele APIet er skrevet med en objektorientert tilnærming. I bunn av systemet er klassen REST. REST-klassen har metoder for å sjekke at brukeren er logget inn, sjekker om metoder og data som kreves er sendt med forespørselen, samt en rekke andre metoder som brukes av systemet. De forskjellige Controller-klassene extender REST-klassen. Når en forespørsel kommer til systemet blir forespøreselen sendt til fila index.php. I index.php inkluderes alle filer vi trenger, setter tidssoner, og definerer hvilke data systemet skal returnere. Her er det også en klasse som heter Loader. Denne klassen laster inn riktig Controller som skal behandle forespøreselen. Eksempel på en forespørsel: /sheep/10?method=get&access_token=[...] Loader-klassen fungerer slik at den ser på det første ordet av forespøreselen og sjekker om det finnes en Controller-klasse som heter dette. I eksempelet ovenfor vil den sjekke om det finnes en fil som heter 14 23

18 sheepcontroller.php. Dersom denne ikke finnes vil systemet returnere en feilmelding. Hvis Controller-klassen finnes i systemet vil den opprette en instans av denne klassen. Når det skjer vil scriptet gå i en variabel i REST-klassen som heter $path og sjekke hvilke metode den skal kalle. I eksempelet ovenfor vil den kalle en funksjon som heter sheep_single. REST-APIer er bygget på et prinsipp hvor et verb bestemmer hvilke handling som skal utføres. Denne har vi kalt method i vårt system. Get vil si å hente ut data, Post vil sette inn ny data (for eksempel å legge til en ny sau), Put vil oppdatere informasjon på et eksisterende element og Delete vil slette et element. I eksempelet ovenfor ønsker vi å hente ut data om sau med ID 10. Dersom sauen eksisterer og den finnes i systemet som brukeren er logget inn i, vil dataen returneres som en JSON-string. Se vedlegg om klasse-diagram for mer informasjon om oppbyggingen av REST-APIet JSON-string JSON står for JavaScript Object Notation 4 og er et format for å utveksle data. Sammenlignet med XML (som er det samme), er JSON lett lesbart for mennesker og tar mindre plass enn tilsvarende XML. Ettersom vi har utviklet en mobilapplikasjon som kanskje ikke alltid har Wifi-tilkobling men heller 3G eller GSM, ønsket vi å gjøre overføringen av data så liten som overhode mulig. En typisk JSON-string kan se slik ut: {"code":121,"msg":no user has this access_token"} Denne stringen kan enkelt gjøres om til et objekt som Javascript kan loope eller lese av. Metoder for å kode og dekode objekter og JSON-stringer er innebygget i alle moderne lettlesere og dette har blitt en svært populær og mye brukt standard. 5.4 App Selve appen er skrevet i HTML, CSS og Javascript. I tillegg brukes en del grafikk i form av.png og.jpeg-bilder. HTML tar for seg oppbyggingen av appen og inkluderer de bibliotekene vi bruker, scriptene vi trenger og stilsettingen i form av CSS-filer. Vi har valgt å bruke HTML5 fordi alle nettlesere på mobile enheter støtter denne standarden, og vi slapp å tenke på andre nettlesere, som for eksempel utdaterte versjoner av Internet Explorer. Det er brukt en standard CSS-fil for å stilsette hvordan appen skal se ut. Mer om dette under design i kapittel Teknisk oppbygging Appen er bygget opp med med en klasse kalt base.js i bunn. Denne klassen holder styr på alle metodene og snakker med APIet. Mellom APIet og selve appen har vi script.js. Her er alle hendelselytterne 5. Når en bruker ønsker å logge inn fyller han/hun ut e-post og passord og trykker på Logg inn-knappen. Script.js har en lytter på Logg inn-knappen og sjekker om alle feltene er fylt ut korrekt. Dersom brukeren har glemt å fylle ut enten e-post eller passord vil systemet klage. Hvis alt er ok vil dataen blir sendt videre til base-klassen. I base.js blir dataen tatt i mot og et Ajax-kall sendt til APIet. Base.js sjekkes svaret fra APIet og man logger enten inn eller får beskjed om at passord og brukernavn er feil Javascript EventListeners 15 23

19 5.4.2 Ajax-kall Ajax er en teknologi som er helt sentral i webapps. Tanken bak webapps er at de aldri kan gå fra en side til en annen. Dette kan sammenlignes ved å være på forsiden til vg.no og deretter trykke seg inn på en artikkel. Nettleseren blir hvit og alt innholdet blir lastet på nytt. Dette kalles en sidelastning. Dersom dette utføres i en webapp vil mobilen hoppe ut av webappen og heller gå over til nettleseren på mobilen. På grunn av dette er alt som skjer i en webapp nødt til å skje på en side uten sidelastninger. Dette gjøres ved en teknologi som kalles Ajax. Ajax står for Asynchronous JavaScript and XML og ble populært på starten av millieniumet. Med Ajax kan man gjøre en forespørsel til nettside og laste litt innhold uten å gjennomføre en komplett sidelastning som krever at all dataen lastes på nytt. På nettsider som Facebook og Twitter brukes Ajax masse for å gjøre responstiden så liten som mulig ved å kun laste det som brukeren velger å se. På Facebook kan du for eksempel åpne og lukke et chatvindu uten at man må gjennomføre en sidelastning. Tilsvarende kan man sende og motta svar i chatvinduet via Ajax. Når en bruker ønsker å se data om en sau, eller logge inn, blir tilsvarende Ajax-forespørsler gjort til APIet som returnerer en JSON-string. Systemet leser JSON-stringen og bestemmer deretter hva som skal skje Templates Da webappen benytter seg av Ajax som kun inneholder den faktiske dataen vi ønsker å motta, må vi ha et sted hvor vi definerer hvordan HTML-markupen skal se ut. Dette er en oppskrift på hvordan vi ønsker at dataen skal presenteres. Vi har lagd APIet slik at man også kan spesifisere hvilke templates man ønsker å motta med en forespørsel. En enkel template kan se slik ut: <div class="block"> <div class="block-top"> <h2>logger</h2> </div> <div class="block-body"> <ul> <%= inner %> </ul> </div> </div> Vi bruker deretter rammeverket Underscore.js til å erstatte og fylle inn verdier for spesielle tags. I dette tilfellet vil listen med logger erstatte taggen inner. Underscore.js er forklart i kapittel Rammeverk I appen har vi valgt å bruke en rekke Javascript-rammeverk for å gjøre utviklingsjobben enklere for oss selv jquery og jquery UI Vi har brukt jquery og jquery UI massivt i appen. Dette er i all hovedsak fordi rammeverket gjør Javascript mye enklere å skrive. Vi har masse Ajax-kall og animasjoner, og med jquery blir disse tingene mye enklere å skrive enn å måtte definere egne metoder i helt ren Javascript. Vi har inkludert jquery UI (som er en utvidelse av jquery-biblioteket) fordi man trenger UI for å kunne animere farger og et par andre spesielle tilfeller som vi kom over i løpet av utviklingen

20 Google Maps API v3 Da vi bestemte oss for å inkludere kart og markører falt valget fort på Google Maps APIet. I all hovedsak fordi dette var det beste alternativet vi kunne finne, det er lett og fordi flere på gruppa hadde vært borti det tidligere. Google Maps er også skrevet i Javascript, som gjorde det veldig enkelt for oss å implementere i prosjektet vårt Underscore.js Med templates fra APIet bruker vi Underscore.js til å fylle inn data. Hvordan templates hentes fra APIet er forklart i kapittel Underscore.js er et lite bibliotek som brukes som template-prosessor og template-motor. Med dette biblioteket kan vi legge til tags i templatene som blir erstattet med faktiske verdier fra APIet. Et eksempel på dette er å finne i seksjonen om templates som det er referert til ovenfor. Vi kunne skrevet vår egen parser for å gjøre dette, men Underscore.js gjorde alt vi ønsket, og ble et naturlig valg etter anbefalinger og testing Moment.js Moment.js er et bibliotek for dato- og tids-behandling i Javascript. Man kan gi biblioteket en dato og den kan enkelt regne ut hvor lenge det er siden. Vi hadde bruk for en slik funksjon et par steder i appen, og i stedet for å gjøre dette manuelt bestemte vi oss for å bruke Moment.js til denne jobben Design Designet i appen er basert på andre apps og blitt bestemt etter mockups vi lagde da vi planla hvordan de forskjellige skjermbildene skulle se ut. Vi har prøvd å gjøre appen lik andre apps som brukere er godt kjent med. Eksempler på disse kan være Facebook, Twitter og Spotify. Vi har gjort oppbyggingen lik på alle sidene, slik at for eksempel lagre-knappen ikke er på forskjellige steder, men man alltid kan forvente at de er å finne på det samme stedet. 5.5 Simulator Simulatoren er laget kjapt og enkelt og fungerer som en normal side i PHP. Den benytter seg av jquery og Ajax-kall i likhet appen, samt Google Maps API. Her kan man logge inn, velge hvilke system man skal simulere, og simulere bevegelser på sauene i sanntid. Her er det også gjort mulig at man kan få simuleringen kan gå fortere enn den faktiske tiden. Dette er hovedsakelig for å teste og sjekke hvordan det vil se ut i appen. Simulatoren er satt opp slik at sauene sender data tre ganger om dagen. Den teller antall sauer i systemet, ganger med tre og deler på 24 timer. Man får da intervallet på hvor ofte simulatoren skal sende en oppdatering. Dette går på rundgang på alle sauene. I tillegg kan man dra sauene rundt på kartet og klikke på en av dem for å angripe eller drepe dem. Simulatoren simulerer hvordan systemet ville fungert i virkeligheten og knytter alle sauene til sin fiktive chip. Med denne chip-iden sendes en forspørsel til APIet som bestemmer hvilke handlinger som skjer. Disse handlingene kan være en normal forflyttelse, angrep eller at en sau har dødd