Roommates: Rapport for hovedoppgave

of 83/83
i Roommates En applikasjon for å gjøre bofellesskap enklere. Gruppedeltakere / Real Kode: Gjermund Bjaanes, Johann Eckhoff og Katrine Myklevold
  • date post

    13-Jan-2017
  • Category

    Software

  • view

    147
  • download

    5

Embed Size (px)

Transcript of Roommates: Rapport for hovedoppgave

  • i

    Roommates

    En applikasjon for gjre bofellesskap enklere.

    Gruppedeltakere / Real Kode:

    Gjermund Bjaanes,

    Johann Eckhoff og

    Katrine Myklevold

  • ii

    Hovedoppgave

    Gruppen har utviklet en mobil applikasjon. Applikasjonen brukes for kommunikasjon i

    samboersituasjoner. Man kan sende notater til hverandre, fre utlegg og lage huskelister.

    Dette er organisert slik at brukerne kan logge seg inn. Disse brukerne kan knyttes opp mot en

    husholdning, hvor all informasjon som blir postet, blir delt med de andre medlemmene.

    SAMMENDRAG

    DA-2014-02 OPPGAVE NR

    TILGJENGELIGHET

    PEN

    ETTER AVTALE

    KONFIDENSIELL

    Besksadr.: Raveien 215 3184 Borre Tlf: 33031000, Fax: 33031100

    Institutt for ingenirutdanning i Vestfold

    Roommates - En applikasjon for gjre bofelleskap enklere.

    NORSK OPPGAVETITTEL

    Roommates - An application to make shared housing easier.

    ENGELSK OPPGAVETITTEL

    75

    DATO LEVERT

    ANTALL SIDER

    Gjermund Bjaanes

    Johann Eckhoff

    Katrine Myklevold

    FORFATTER(E)

    Egen

    OPPDRAGSGIVER

    Veileder: Thomas Nordli

    REF. /VEILEDER(E)

    Applikasjon, Multiplattform, Skylsning

    3 STIKKORD

  • iii

    SAMMENDRAG (forts.)

    Applikasjonen synkroniserer data over skyen ved hjelp av et back-end-system som heter

    Parse. Dette er et system med en NoSQL-database, sttte for push-meldinger og tjenerside-

    kode. Her ligger databasen hvor alle brukerdata er lagret, samt tjenerside-kode for utfre

    visse oppgaver. Applikasjonen er laget og testet for brukes p alle enheter som kjrer iOS,

    samt mobiltelefoner som kjrer Android 4.0 og oppover.

    Gjennom prosjektet er det blitt brukt en systemutviklingsmetode som heter inkrementell

    utvikling. Denne metoden gr ut p at systemet leveres i inkrementer, hvor ny funksjonalitet

    blir lagt til for hvert inkrement. Applikasjonen er utviklet i tre inkrementer.

    Gruppen har gjennom prosjektet ftt kunnskap innen programmering mot Android og iOS,

    samt bruk av 3. parts biblioteker og dets dokumentasjoner. Gruppen har ogs tilegnet seg

    erfaring med strre prosjektarbeid og metoder rundt dette.

    For videre utvikling er det planlagt gi applikasjonen ut p Apple App Store og Google Play.

    Dette krever at det blir satt hyere krav til applikasjonens kvalitet. Da er det behov for nye

    runder med beta-testing, samt utarbeidelse av en konomisk plan for hvordan fremtidige

    utgifter til drift av back-end skal finansieres.

  • iv

    Skjemaet skal leveres sammen med besvarelsen.

    Obligatorisk erklring Jeg erklrer herved at min:

    Eksamensbesvarelse i emnekode: FE-BAC3000 Fakultet: TekMar

    1. er utfrt av undertegnede. Dersom det er et gruppearbeide, blir alle involverte holdt ansvarlig og alle skal undertegne blanketten.

    2. ikke har vrt brukt til samme/en annen eksamen ved HVE eller et annet institutt/ universitet/hgskole innenlands eller utenlands.

    3. ikke er kopi eller avskrift av andres arbeid, uten at dette er korrekt oppgitt.

    4. ikke refererer til eget tidligere arbeid uten at dette er oppgitt.

    5. har oppgitt alle referanser/kilder som er brukt i litteraturlisten.

    Jeg/vi er kjent med at brudd p disse bestemmelsene er betrakte som fusk og

    behandles i hht. 18 i Forskrift om eksamen og studierett ved HBV og U-loven Kap. 4

    4-7.

    Dato: Sted:

    Underskrift1: Kand.nr.:

    Ved gruppebesvarelse m alle gruppas deltagere undertegne:

    Underskrift: Kand.nr.: Underskrift: Kand.nr.:

    Underskrift: Kand.nr.:

    1 Hvis erklringen leveres inn elektronisk via Fronter er underskrift ikke ndvendig, skriv da inn navn.

  • v

    Hovedprosjektets tittel:

    Roommates - En applikasjon for gjre bofellesskap enklere.

    Forfatternes navn:

    Gjermund Bjaanes, Johann Eckhoff og Katrine Myklevold

    Kurs/avdeling:

    Ingenirfag, Datateknikk. Avdeling TekMar

    Dato: _______________________

    Rett til innsyn, kopiering og publisering av hovedprosjekt

    Biblioteket og avdelingene fr ofte foresprsler om kopi eller innsyn i hovedprosjekt. Biblioteket nsker gjre gode hovedprosjekt tilgjengelig ved publisere dem i papirutgave og legge dem p internett. Hgskolen trenger studentenes tillatelse til dette.

    Hovedprosjektet vil fortsatt vre forfatterens ndsverk med de rettigheter det gir.

    Hgskolens bruk vil ikke omfatte kommersiell bruk av studenters hovedprosjekt.

    Tillater du/dere at din/deres hovedprosjekt blir publisert bde i papir og nettutgave ?

    ___ ja ___ nei

    Signatur av alle forfattere:

  • vi

    Forord Denne rapporten er utarbeidet som en del av eksamineringen av FE-BAC3000, Bachelor oppgave.

    Hensikten med denne rapporten er vise hvordan prosjektet har blitt gjennomfrt, hvordan

    systemet er satt sammen, hvilke utfordringer som har oppsttt underveis, hvordan disse er hndtert

    og hva resultatet av prosjektet ble.

    Rapporten er utarbeidet av prosjektgruppen: Gjermund Bjaanes, Johann Eckhoff og Katrine

    Myklevold. Vi er alle studenter ved Ingenirfag, Datateknikk, Hgskolen i Buskerud og Vestfold.

    Takk til Vi nsker takke vr veileder gjennom prosjektet, Thomas Nordli, for hjelp med tekniske

    sprsml, konstruktiv kritikk og veiledning generelt underveis.

    Vre dyktige sprkvaskere: Astrid Bjaanes og Roald Bjaanes som har hjulpet oss med f

    rapporten p et bedre sprklig niv.

    Under betatesting har vi hatt god hjelp av Marlene Angelica Sjonsti Bjrnsen og dne Aalmo. De

    har testet applikasjonen vr og gitt konstruktive tilbakemeldinger.

    Til slutt vil vi takke Paul Hegarty fra Stanford University. Vi har ikke hatt direkte kontakt med han,

    men han har likevel hjulpet oss veldig med opplringen i utvikling til iOS. Hans forelesninger som

    ligger tilgjengelig p nettet har srget for en solid forstelse av plattformen. Den inspirasjon han

    har gitt oss, kan ikke verdsettes hyt nok.

  • vii

    Innholdsfortegnelse

    Forord ............................................................................................................................... vi

    Takk til .............................................................................................................................. vi

    1 Innledning ................................................................................................................... 2

    1.1 Bakgrunn for oppgaven ........................................................................................ 2

    1.2 Problemstilling ...................................................................................................... 2

    1.3 Problemformulering .............................................................................................. 2

    1.4 Mlformulering ..................................................................................................... 3

    1.4.1 Prosjektml ................................................................................................... 3

    1.4.2 Produktml .................................................................................................... 3

    1.4.3 Prosessml ................................................................................................... 3

    1.5 Rapportens oppbygning ....................................................................................... 3

    2 Kravspesifikasjon ........................................................................................................ 4

    2.1 Funksjonelle krav ................................................................................................. 4

    2.2 Ikke-funksjonelle krav ........................................................................................... 8

    3 Valg av teknologi ......................................................................................................... 9

    3.1 Valg av plattformer ............................................................................................... 9

    3.2 Valg av back-end ................................................................................................. 9

    4 Designspesifikasjon ...................................................................................................10

    4.1 Systemoversikt ....................................................................................................10

    4.2 Systemarkitektur .................................................................................................10

    4.3 Datadesign ..........................................................................................................11

    4.3.1 Role ..............................................................................................................13

    4.3.2 Household ....................................................................................................13

    4.3.3 User .............................................................................................................14

    4.3.4 Note .............................................................................................................14

    4.3.5 Event ............................................................................................................15

    4.3.6 Invitation .......................................................................................................16

    4.3.7 TaskList ........................................................................................................16

    4.3.8 TaskListElement ...........................................................................................17

    4.3.9 Installation ....................................................................................................17

    4.3.10 Expense .....................................................................................................18

    5 Prosess og metoder ...................................................................................................19

    5.1 Utvikling ..............................................................................................................19

  • viii

    5.1.1 Utviklingsmodell ...........................................................................................19

    5.1.2 Kodestandard ...............................................................................................20

    5.1.2.1 Navnsetting ............................................................................................20

    5.1.2.2 Innrykk ....................................................................................................21

    5.1.2.3 Krllparentes-posisjon ............................................................................21

    5.1.3 Versjonskontroll ............................................................................................22

    5.1.4 Utviklingsverkty ..........................................................................................22

    5.1.4.1 Integrerte utviklingsmiljer (IDE) .............................................................22

    5.1.4.2 Brukergrensesnittmodellering .................................................................24

    5.1.4.3 Diagrammer ............................................................................................24

    5.1.5 Testing .........................................................................................................25

    5.1.5.1 Enhetstesting ..........................................................................................26

    5.1.5.2 Systemtesting .........................................................................................28

    5.1.5.3 Godkjenningstesting ...............................................................................28

    5.2 Prosjekt ...............................................................................................................29

    5.2.1 Gruppestruktur .............................................................................................29

    5.2.2 Evernote .......................................................................................................29

    5.2.3 Gantt-diagram ..............................................................................................30

    5.2.4 Prosjektstyringsverkty ................................................................................31

    6 Resultat......................................................................................................................31

    6.1 Produkt ...............................................................................................................31

    6.1.1 Produktml ...................................................................................................31

    6.1.2 Kildekode .....................................................................................................31

    6.1.2.1 Samtidighet (Concurrency) .....................................................................32

    6.1.2.2 Facebook ................................................................................................32

    6.1.2.3 iOS .........................................................................................................33

    6.1.2.4 Cloud Code ............................................................................................39

    6.1.2.5 Android ...................................................................................................40

    6.1.3 Brukergrensesnitt .........................................................................................46

    6.1.3.1 Applikasjonens Innhold ...........................................................................47

    6.1.3.2 Navigasjon ..............................................................................................48

    6.1.3.3 Fonts og farger .......................................................................................48

    6.1.3.4 Forskjeller ...............................................................................................49

    6.2 Prosjekt ...............................................................................................................51

    6.2.1 Prosjektml ..................................................................................................51

    6.2.2 Tidsbruk .......................................................................................................51

    7 Konklusjon .................................................................................................................53

  • ix

    7.1 Hvis gruppen startet p nytt.................................................................................53

    7.2 Veien videre ........................................................................................................53

    8 Litteraturliste ..............................................................................................................55

    9 Begrepsliste ...............................................................................................................59

    10 Vedlegg ....................................................................................................................61

    11 Appendiks - Bakgrunnsteori .....................................................................................62

    11.1 iOS ....................................................................................................................62

    11.1.1 Brukergrensesnitt .......................................................................................62

    11.1.2 Versjoner ....................................................................................................62

    11.1.3 ObjectiveC ................................................................................................62

    11.1.3.1 Syntaks .................................................................................................63

    11.1.4 iOS Software Development Kit ...................................................................65

    11.1.4.1 Rammeverk ..........................................................................................65

    11.1.4.2 SDK Innhold: Abstraksjonslag ..............................................................65

    11.1.5 Apples App Store .......................................................................................67

    11.2 Android ..............................................................................................................67

    11.2.1 Brukergrensesnitt .......................................................................................68

    11.2.2 Versjoner ....................................................................................................68

    11.2.3 Java ...........................................................................................................68

    11.2.3.1 Dalvik Virtual Machine ..........................................................................68

    11.2.3.2 Syntaks .................................................................................................68

    11.2.4 XML Extensible Markup Language ..........................................................69

    11.2.5 Android Software Development Kit .............................................................69

    11.2.5.1 Arkitektur ..............................................................................................70

    11.2.6 Google Play ................................................................................................71

    11.3 Parse.................................................................................................................71

    11.3.1 Teknologi ....................................................................................................71

    11.3.2 Sikkerhet ....................................................................................................71

    11.3.2.1 Autentisering.........................................................................................72

    11.3.2.2 Konfidensialitet .....................................................................................72

    11.3.2.3 Autorisasjon ..........................................................................................72

    11.3.3 NoSQL .......................................................................................................72

    11.4 Versjonskontroll med Git ...................................................................................73

  • Side 2 av 75

    1 Innledning

    1.1 Bakgrunn for oppgaven Prosjektet er ikke gitt av en arbeidsgiver, men er i stedet en id formet og utviklet av

    prosjektgruppen.

    1.2 Problemstilling Hvordan lage en helhetlig lsning/applikasjon for praktiske problemstillinger knyttet til

    samboerskap, p tvers av plattformer?

    1.3 Problemformulering I valget av oppgave bestemte prosjektgruppen seg for se p problemstillinger i forhold til

    kryssplattformutvikling, lagring av data i skyen og mobile applikasjoner. Gruppen oppdaget et

    behov alle hadde i forhold til samkjring av aktiviteter knyttet til samboerskap. Dette er noe veldig

    mange studenter m forholde seg til, og gruppen bestemte seg derfor for utforske disse omrdene

    og det som mtte dukke opp underveis i forhold til dette.

    Samtidig s gruppen en mulighet til gjre et prosjekt der det kunne trekkes mange paralleller til

    andre programfag fra studiet og dermed ta i bruk kunnskap som er opparbeidet. Gruppen nsker

    blant annet bruke formelle systemutviklingsmetoder for effektivisere og kvalitetssikre arbeidet.

    Gruppen nsket ogs se p muligheten for flere niver med testing. Det var nsket fokusere p

    enhets-testing, automatisk testing og manuell testing (etterhvert ogs med utvidet publikum for

    Alpha/Beta-testing). Dette er kunnskap og ferdigheter som mtte tilegnes bde fr og underveis i

    prosjektet. Det var nskelig med et godt testet og solid sluttprodukt.

    Som tidligere nevnt ville gruppen gjre et prosjekt knyttet til kryssplattformutvikling og lagring av

    data i skyen. Valget falt p lage en mobilapplikasjon til de to strste mobilplattformene: Android

    og iOS. Her valgte gruppen se p utfordringer knyttet til utvikle til to plattformer samtidig,

    spesielt knyttet til kode og design. I forhold til skylagring ville gruppen bruke et ferdig BaaS-

    system (Back-end as a Service) med ferdige rammeverk for de forskjellige utviklingsplattformene

    som er valgt bruke.

    Selve applikasjonen var tenkt som en roommates-app for samboere/studenter. Denne applikasjonen

    skulle inneholde handleliste, utlegg, vaskelister, felles beskjeder etc. Dette er aktiviteter som de

    fleste som er i samboerskap eller bofellesskap kan ha nytte av ha sentralisert og lett tilgjengelig.

    Dette er ogs et behov som ikke er srlig godt dekket av andre tilbud p markedet per i dag. Det

    finnes andre som har gjort forsk p dette, men de er etter gruppens mening ikke srlig gode.

    Eksempler p applikasjoner gruppen har prvd som prver tilby det samme er Roommat.es til

    iOS, og HomeSlice til Android og iOS. Ingen av disse applikasjonene dekker alle behovene

    gruppen har, og gruppen mener problemet kan lses p en bedre mte enn det som allerede er gjort.

  • Side 3 av 75

    1.4 Mlformulering

    1.4.1 Prosjektml Gruppen nsket med dette prosjektet utvikle et produkt som fungerer og som kan brukes til

    daglig. Systemet skulle synkronisere over skyen, vre tilgjengelig for s mange brukere som mulig

    og vre lett bruke. Erfaringen gruppen nsket tilegne seg i dette prosjektet, ville vre veldig

    relevant for arbeidslivet og gjre gruppens medlemmer mer attraktive i arbeidsmarkedet.

    Gruppen mtte utforske og fordype seg i omrder som tidligere var relativt ukjente. Dette var ment

    gi lring som er relevant og realistisk i forhold til en arbeidslivsituasjon. Siden prosjektet var

    omfattende av natur, ville det vre naturlig lre mye om strre programvareutviklingsprosjekter.

    1.4.2 Produktml Gruppen nsket lage en applikasjon som skulle fungere p tvers av kjente plattformer og

    synkronisere smlst mellom disse. Gruppen ville lse et problem som alle medlemmene har hatt;

    utfordringer tilknyttet til samboerskap og bofellesskap. Disse utfordringene skulle bli lettere mte

    for alle ved lage en applikasjon som sentraliserer informasjon og oppgaver tilknyttet bofellesskap.

    Applikasjonen skulle ogs vre lett bruke og ha et intuitivt brukergrensesnitt for at den skulle

    vre enklere ta i bruk. Gruppen nsket gjre hverdagen lettere for alle som bor i et

    bofellesskap, enten de har store problemer med f det til fungere fra fr, eller bare vil gjre det

    lettere for seg selv og de de bor sammen med.

    1.4.3 Prosessml Med dette prosjektet nsket gruppen lre mer om alt som er knyttet til programvareprosjekter;

    prosjektarbeid, programmering, systemutviklingsmetoder, testing og dokumentasjon.

    1.5 Rapportens oppbygning Rapporten er bygd opp av disse hovedpunktene

    Kravspesifikasjon o Liste med krav, skrevet for beskrive egenskaper og tjenester som kreves av

    systemet.

    Valg av teknologi o Beskriver teknologiene som er valgt for lse problemet og tilfredsstille kravene i

    kravspesifikasjonen.

    Designspesifikasjon o Dokumentasjon av systemets arkitektur og datadesign.

    Prosess og metoder o Beskriver prosesser, metoder og verkty som er benyttet for utvikle systemet.

    Resultat o Beskriver resultatet av prosjektet og produktet som er laget.

    Konklusjon o Slutning p prosjektet og sammenfatter resultatene fra prosjektet.

    Litteraturliste o Liste over alle kilder som er brukt i rapporten.

    Begrepsliste o Liste over ord og begreper som er brukt i rapporten, og en forklaring p disse.

    Appendiks - Bakgrunnsteori o Utdypende forklaring av teorien bak en del av teknologien som er brukt. Den gir

    en innsikt i applikasjonen som er produsert og systemet som en helhet.

  • Side 4 av 75

    2 Kravspesifikasjon Prosessen med skrive en kravspesifikasjon definerer egenskaper og tjenester som kreves av

    systemet.

    Kravene er ment som en beskrivelse av systemets funksjonalitet, egenskaper og begrensninger.

    2.1 Funksjonelle krav Funksjonelle krav er grunnleggende funksjoner i systemet. De beskriver bestemt funksjonalitet som

    systemet skal ha.

    Funksjonelt krav #1: Bruker skal kunne registrere bruker med e-post og selvvalgt passord.

    Bruker skal kunne registrere seg med sin egen e-post og passord direkte fra applikasjonen. E-post

    fungerer som brukernavn.

    Registrering av bruker skal skje i applikasjonen, men autentiserer mot Parse sine tjenere.

    Funksjonelt krav #2: Bruker skal kunne resette passordet sitt dersom bruker har glemt

    passordet sitt.

    Fra innloggingsskjermen skal bruker kunne fylle inn e-post og f tilsendt en e-post med veiledning

    for stille tilbake passordet sitt.

    Funksjonelt krav #3: Bruker skal kunne registrere ny bruker med Facebook.

    Dette skal fungere p samme mte som andre applikasjoner som benytter seg av Facebook-

    innlogging: Applikasjonen har en knapp med Facebook som sender bruker til Facebook hvor

    bruker godkjenner at applikasjonen skal f tilgang til de ressurser som applikasjonen ber om.

    Deretter blir bruker sendt tilbake til den originale applikasjonen som fr data fra Facebook som blir

    brukt til registrere bruker.

    Nr man registrere seg med Facebook skal det automatisk lages en ny bruker til applikasjonen som

    er p lik linje med vanlige brukere i applikasjonen, bortsett fra at man ikke kan endre brukerdata.

    Man skal ogs kun kunne logge inn via Facebook etter man frst har registrert med e-post-adressen

    fra Facebook.

    Registrering og innlogging med Facebook skal skje med samme knapp rett fra

    innloggingsskjermen.

    Funksjonelt krav #4: Bruker skal kunne lage felles beskjeder som alle medlemmer av

    bofellesskapet kan se i applikasjonen.

    Bruker skal kunne skrive beskjeder direkte i applikasjonen som blir tilgjengelig for alle brukere av

    bofellesskapet.

    Beskjeden skal komme opp i en meldingsstrm i applikasjonen til alle brukere som er medlem av

    bofellesskapet.

    Funksjonelt krav #5: Bruker skal kunne f beskjed om nye hendelser i bofelleskapet (nye

    beskjeder, nye personer osv.).

    Brukere av et bofellesskap skal kunne f meldinger i form av push-meldinger ved nye hendelser og

    felles beskjeder.

    Dersom en bruker skriver en felles beskjed, skal alle andre i bofellesskapet f en push-melding om

    at det har kommet en ny felles beskjed. P samme mte, dersom en annen viktig hendelse skjer i

    bofellesskapet (som for eksempel at en ny liste eller utlegg er lagt til), skal det bli sendt ut en push-

    melding om dette.

  • Side 5 av 75

    Hendelser skal ogs komme opp i en hendelses-strm direkte i applikasjonen slik at brukere av

    bofellesskapet kan g igjennom alle hendelser som har vrt.

    Funksjonelt krav #6: Bruker skal kunne f opp alle detaljer om en hendelse i hendelses-

    strmmen.

    Bruker skal kunne velge en hendelse fra hendelsesstrmmen og f opp alle detaljer som er lagret

    om den hendelsen.

    Funksjonelt krav #7: Bruker skal kunne opprette lister.

    Bruker skal kunne opprette nye lister og sette egenvalgte navn p listene.

    Nr en liste blir opprettet skal det opprettes en event i systemet som vises i hendelses-strmmen.

    Hendelsen skal fortelle hvilken bruker som opprettet listen.

    Funksjonelt krav #8: Bruker skal kunne g inn p alle lister for se listelementer og gjre

    endringer p listen.

    Bruker skal kunne velge en liste for g inn p listen. Inne p listen skal bruker kunne se alle

    listeelementer for listen, samt gjre endringer p listen (som for eksempel slette listen, endre navn

    osv.).

    Funksjonelt krav #9: Bruker skal kunne opprette listeelementer i alle lister.

    Bruker skal kunne opprette nye listelementer i alle lister som er tilknyttet bofelleskapet, uavhengig

    om det er bruker som opprinnelig laget listen.

    Funksjonelt krav #10: Bruker skal kunne redigere alle lister og markere dem som fullfrt.

    Bruker skal kunne redigere navn, slette og markere lister som fullfrt.

    Nr en liste blir markert som fullfrt skal det opprettes en event i systemet som vises i hendelses-

    strmmen. Hendelsen skal fortelle hvilken bruker som markerte listen som fullfrt.

    Funksjonelt krav #11: Bruker skal kunne redigere alle listelementer og markere dem som

    fullfrt.

    Bruker skal kunne redigere navn, slette og markere listeelementer som fullfrt.

    Funksjonelt krav #12: Bruker skal kunne se hvem som har markert en liste som fullfrt.

    Nr noen har markert en liste som fullfrt, skal det vre mulig se i bde hendelses-strmmen og i

    liste-oversikten hvem som har markert listen som fullfrt.

    Funksjonelt krav #13: Bruker skal kunne se hvem som har markert et listelement som

    fullfrt.

    Nr noen har markert et listelement som fullfrt, skal det vre mulig se inne p listen hvem som

    har fullfrt listelementet.

    Funksjonelt krav #14: Bruker skal kunne logge seg inn med en registrert bruker.

    Dersom en bruker har registrert seg i systemet skal brukeren kunne logge inn p systemet og f

    tilgang til sine ressurser.

    Funksjonelt krav #15: Bruker skal kunne opprette nytt bofellesskap.

    Dersom en bruker ikke er medlem av et eksisterende bofellesskap, skal brukeren har mulighet til

    opprette et eget bofellesskap med selvvalgt navn.

    Funksjonelt krav #16: Bruker skal kunne invitere andre brukere til eksisterende

    bofellesskap.

  • Side 6 av 75

    Alle brukere av et bofellesskap skal ha muligheten til invitere andre brukere i systemet til

    bofellesskapet. Invitasjon skal skje ved referere til andre brukere med deres e-post-adresse.

    Invitasjon skal kun fungere dersom e-post-adressen allerede er registrert i systemet.

    Funksjonelt krav #17: Bruker skal kunne motta invitasjon og godta denne for bli meldt inn

    i eksisterende bofellesskap.

    Nr en bruker har mottatt en invitasjon skal bruker kunne godta denne for melde seg inn i

    bofellesskapet.

    Det skal kun vre mulig godta invitasjoner dersom bruker ikke allerede er medlem av et

    bofellesskap.

    Nr en bruker fr en invitasjon, skal dette varsles med en push-melding til bruker.

    Nr en bruker godtar en invitasjon, skal det opprettes en event i systemet om hendelsen som vises i

    bofellesskapets hendelsesstrm. Det skal ogs sendes en push-melding til alle medlemmer av

    bofellesskapet om hendelsen.

    Funksjonelt krav #18: Bruker skal kunne se oversikt over hvem som er med i bofellesskapet.

    Bruker skal ha mulighet til se en oversikt over hvem som er medlem av bofellesskapet som

    bruker er medlem av.

    Oversikten skal vise e-post, navn og bilde for hvert enkelt medlem av bofellesskapet.

    Funksjonelt krav #19: Bruker skal kunne melde seg ut av bofellesskapet.

    Bruker skal ha mulighet til melde seg ut av bofellesskapet.

    Nr en bruker melder seg ut av et bofellesskap skal det opprettes en event i systemet om hendelsen

    som vises i bofellesskapets hendelsesstrm. Det skal ogs sendes en push-melding til alle

    medlemmer av bofellesskapet om hendelsen.

    Funksjonelt krav #20: Bruker skal kunne se oversikt over utlegg i bofellesskapet.

    Bruker skal kunne g inn p en utleggsoversikt og se alle utlegg i bofellesskapet.

    Funksjonelt krav #21: Bruker skal kunne hvilke utlegg som er gjort opp og hvilke som ikke

    er det.

    Bruker skal kunne se i oversikten over utlegg i bofellesskapet hvilke utlegg som det er gjort opp

    for, og hvilke som fremdeles er uoppgjort.

    Funksjonelt krav #22: Bruker skal kunne se hvor mye bruker skylder p et utlegg.

    Bruker skal kunne se i oversikten over utlegg i bofellesskapet hvor mye bruker skylder p hvert

    enkelt utlegg (dersom bruker er en av de skyldige i utlegget).

    Funksjonelt krav #23: Bruker skal kunne se hvor mye andre brukere skylder bruker for et

    utlegg.

    Bruker skal kunne se i oversikten over utlegg i bofellesskapet hvor mye andre brukere skylder

    bruker p hvert enkelt utlegg (dersom bruker er den som det er skyldt penger til i utlegget).

    Funksjonelt krav #24: Bruker skal kunne legge til utlegg.

    Bruker skal kunne legge til nye utlegg.

    En dialog skal komme opp nr bruker skal legge til nytt utlegg hvor bruker fyller ut flgende

    informasjon:

    Navn p utlegg (pkrevd felt)

    Belpet tilsammen som skyldes (pkrevd felt)

  • Side 7 av 75

    Detaljer om utlegget (valgfritt felt)

    Hvilke brukere som er skyldige i utlegget

    Belpet skal deles likt p alle som er med p utlegget.

    Dersom bruker som legger til utlegget er satt opp til vre med p utlegget blir automatisk bruker

    satt som ferdig betalt, da den som gjr utlegget allerede har betalt sin del.

    Dersom bruker ikke skal vre med p utlegget, men har betalt utlegget for noen andre, kan bruker

    velge seg selv bort fra listen og da vil belpet deles p de som faktisk skal betale.

    Bruker som legger til belpet er automatisk markert og blir satt som betalt.

    Eksempel:

    Belp: 1000. Bruker har betalt for utlegget og 3 andre i bofellesskapet var med p utlegget. Dermed

    skal de 3 andre brukerne betale 250 hver (siden bruker ogs er med p utlegget). I oversikten over

    utlegg str det at bruker er skyldt 750. Hos de andre brukerne som er med p utlegget vil oversikten

    si at de skylder 250 for utlegget.

    Funksjonelt krav #25: Bruker skal kunne se all informasjon om alle utlegg.

    Alle brukere skal kunne g inn p alle utlegg for se informasjon om utlegget som er valgt:

    Navn p utlegg

    Belp tilsammen

    Detaljert tilleggsinformasjon om utlegget

    Hvilke brukere som har betalt

    Hvilke brukere som ikke har betalt

    Hva hver enkelt bruker skylder (skal vre samme belp, da totalbelpet blir delt p brukere som er med p utlegget)

    Funksjonelt krav #26: Bruker skal kunne gjre endringer i utlegg som bruker selv har lagt

    til.

    Bruker skal kunne endre utlegg som bruker selv har lagt til. Det vil si at det kun er brukeren som er

    skyldt penger som kan gjre endringer p et utlegg. Alle andre brukere i bofellesskapet kan kun se

    p utlegget, men ikke endre det.

    Endringer som bruker skal kunne gjre p sine egne utlegg:

    Endre navn p utlegg

    Endre belp tilsammen p utlegget

    Endre detaljert tilleggsinformasjon om utlegget

    Slette utlegget

    Sette brukere som betalt p utlegget

    Sette brukere som ikke betalt p utlegget

    Legge til brukere p utlegget

    Fjerne brukere fra utlegget

  • Side 8 av 75

    2.2 Ikke-funksjonelle krav Ikke-funksjonelle krav er systemets egenskaper som sikkerhet, plitelighet og tilgjengelighet.

    Ikke-funksjonelt krav #1: Systemet skal ha data lagret i skyen.

    Data som tilhrer systemet, brukere, innlegg og annen informasjon, skal vre lagret og vre

    tilgjengelig fra en back-end-tjeneste.

    Ikke-funksjonelt krav #2: Systemet skal synkronisere data lagret lokalt til skyen.

    Data som blir produsert lokalt p klienter, skal synkroniseres til skyen og vre tilgjengelig for

    andre som har rettigheter til dataene.

    Ikke-funksjonelt krav #3: Systemet skal ha klienter slik at de fleste brukere har mulighet til

    bruke det.

    Systemet skal ha klienter tilgjengelig for et s bredt spekter med brukere som mulig, slik at s

    mange som mulig har mulighet til benytte seg av systemet.

    Ikke-funksjonelt krav #4: Systemet skal ha klienter som har plattformspesifikke grensesnitt

    En klient av systemet som er laget for en spesifikk plattform skal ha utseende og brukergrensesnitt

    som passer plattformen og dens retningslinjer for dette.

    Ikke-funksjonelt krav #5: Ingen skal kunne logge inn p andres brukere.

    Systemet skal vre sikkert nok til at datainnbrudd p systemet ikke skal vre trivielt.

    Det er ikke mulig beskytte mot at noen kan finne andres passord, men dette kan minimeres ved

    krav om passord som er vanskelige gjette.

    Ikke-funksjonelt krav #6: Ingen skal kunne se andres bofellesskap.

    Systemet skal vre sikkert nok til at datainnbrudd p systemet ikke skal vre trivielt.

    Bruker skal kun kunne f tilgang til det bofellesskapet som bruker selv er medlem av.

    Ikke-funksjonelt krav #7: Ingen skal kunne gjre ting p andres vegne.

    Bruker skal ikke kunne legge inn beskjeder eller andre ting p vegne av andre brukere.

    Dersom bruker fullfrer en liste skal det vre tydelig hvem som har markert listen som fullfrt.

    Bruker skal ikke ha tilgang til endre andre brukeres utlegg.

    Ikke-funksjonelt krav #8: Innholdet skal vre tilgjengelig s ofte som mulig

    Back-end m vre responsiv nok til kunne svare p foresprsler og levere data til de fleste tider.

    Noe nedetid er forvente fra alle tjenester som tilbyr back-end.

  • Side 9 av 75

    3 Valg av teknologi For lse problemet som er valgt var det viktig velge riktig teknologi. Mye tid ble brukt p

    underske teknologier og plattformer, samt utforske mulige alternativer. Disse skulle tilfredsstille

    kravene som var satt, og vre realistiske bruke for prosjektgruppen (bde i prosjekttiden og i

    tiden etter prosjektet er ferdig).

    3.1 Valg av plattformer For kunne bruke en applikasjon som gjr bofellesskap enklere var det behov for en plattform som

    var tilgjengelig "p farten". De fleste er p farten nr ting skal gjres og beskjeder skal gis. De

    fleste i bofelleskaps-situasjoner er unge mennesker, som ogs er kjent for ha smarttelefoner.

    Valget ble fokusere p mobile plattformer.

    Valget av plattformer falt naturlig p iOS og Android p bakgrunn av at det er det de aller fleste

    mennesker har (Mobile/Tablet Operating System Market Share, 2014). Gruppen har forskjellige

    mobile enheter og samtlige av disse bruker iOS eller Android som operativsystem. Gruppen er

    kjent med plattformene og har en god forstelse av retningslinjene for brukergrensesnitt p begge.

    Gruppens medlemmer mener at begge plattformene ogs har store fordeler som skiller disse fra

    andre. Android er gratis utvikle til, det lett distribuere applikasjoner og er den mest utbredte i

    verden. iOS har gode verkty for lage profesjonelle applikasjoner, er meget populrt, det lett

    distribuere applikasjoner, og det har et meget aktivt utviklermilj p internett.

    Sett i forhold til kryssplattformutvikling ble det fokusert p at resultatet skulle vre tilgjengelig p

    de viktigste mobile plattformene. Klientene skulle vre native for sin plattform, og samtidig vre

    realistiske utvikle innenfor de gitte tidsrammene. I stedet for velge for eksempel

    utviklingsplattformene Xamarin eller Qt som fokuserer p kjre samme kode p alle klienter (p

    tvers av plattformer), falt valget p utvikle to separate klienter. Dette grunnet gruppens mindre

    kjennskap med C# (Xamarin) og C++/QML (Qt). Utviklingsplattformene var ogs mindre stttet

    av de fleste back-end-tjenestene som fantes p markedet.

    Valget av plattformer dekker ikke-funksjonelle krav #3 og #4.

    3.2 Valg av back-end Da prosjektgruppen skulle velge hvilken back-end lsning som skulle brukes i prosjektet falt valget

    p Parse fordi det hadde mye av funksjonaliteten som var nsket innebygd. Parse hadde ogs et

    API som s meget ryddig og praktisk ut.

    Det var behov for en database hvor dataene kunne lagres slik at de var tilgjengelig overalt. Videre

    mtte denne kunne integreres mot prosjektets valgte plattformer: Android og iOS. Dette tilbd

    Parse, sammen med en brukerhndtering som har gjort at gruppen kunne fokusere p andre deler av

    oppgaven.

    Parse hndterer innlogginger, lagring av passord, tilgangskontroll p objekter og vedlikehold av

    tjenere.

    En ting gruppen s p som et mulig problem med Parse var begrenset offline-sttte, men valgte

    allikevel benytte oss av tjenesten. Som nevnt i appendikset er det kommet en ny oppdatering

    nylig som legger til bredere offlinesttte til Android, og det er annonsert det samme til iOS i nr

    fremtid. Dette betyr at det i fremtiden vil vre enklere implementere dette i prosjektet om det

    skulle vre nskelig.

    Andre alternativer som har vrt oppe til diskusjon er Apstrata og Stackmob. Apstrata tilbyr

    tilsvarende funksjonalitet som Parse, og kunne nok vrt brukt for dekke prosjektets krav. Til slutt

    ble Parse valgt p grunn av en tilsynelatende bedre dokumentasjon og at de tilbd mer gratis bruk

    enn Apstrata. Stackmob ble vurdert som et alternativ, men dette ble ogs forkastet grunnet Parse

  • Side 10 av 75

    sin tilsynelatende enklere dokumentasjon. Stackmob ble senere kjpt av PayPal, og lagt ned i

    februar. (Larson, 12)

    Valget av back-end dekker ikke-funksjonelle krav #1, #2, #3, #5, #6, #7 og #8.

    4 Designspesifikasjon Hensikten med designspesifikasjonen er vre en dokumentasjon av systemets arkitektur og

    datadesign. Designspesifikasjonen skal vre s detaljert at en annen gruppe med utviklere skal

    kunne plukke opp denne, og lage et tilsvarende sluttprodukt.

    Designspesifikasjonen gjenspeiler den siste versjonen av designdokumentet som har blitt skrevet i

    lpet av prosjektets lpetid.

    Designdokumentet har blitt utvidet, revidert og oppdatert i begynnelsen av hvert inkrement i

    prosjektet, slik som inkrementell utvikling tilsier.

    Selve designdokumentet som er skrevet under utviklingen ligger som vedlegg.

    4.1 Systemoversikt Systemet skal bruke en ferdig lsning for back-end som heter Parse. Her ligger det databaselsning

    i form av NoSQL, brukerhndtering (innlogging, registrering, glemt passord), tjener-side

    JavaScript-kode, push-meldinger, lagring, sosiale funksjoner og administrasjon.

    Systemet fungerer slik at all data ligger lagret i Parse ("skyen") og applikasjonen bestr av klienter.

    Klientene har ikke alle data selv, men hndterer en del av opprettingen og lagringen av dem (sender

    data til Parse). I stedet snakker klientene med Parse for f tak i dataene de har behov for.

    Parse skal ogs hndtere noe automatisk kode i sin Cloud Code-modul. Cloud Code er kode som

    kan kalles p fra klienten, men som ligger lagret og blir kjrt p Parse sine tjenere. Dette gjr at

    man kan gjre automatisk behandling av objekter sentralt, i stedet for mtte implementere

    logikken p alle klienter. Det gjr gjenbruk av kode enklere.

    4.2 Systemarkitektur

    Figur 1: Systemarkitektur for prosjektet

    Systemet er bygget opp av to hovedmoduler: klient og back-end. Hver av disse har undermoduler

    som er vesentlige for funksjonaliteten i systemet.

    Parse SDK, og hele back-end er ferdig utviklet og kommer fra Parse. Det som i all hovedsak er

    utviklet er klient-koden, databasen og Cloud Code-biten.

  • Side 11 av 75

    Klienten skal bygges opp av to deler. Den frste er selve applikasjonen. Dette er klientkoden.

    Denne hndterer brukere direkte. Klientkoden bruker Parse sitt SDK for prate mot back-end-API'

    et. Her gis det tilgang til database, push-meldinger og de andre tjenester som Parse sin back-end

    tilbyr. Back-end API'et tilbyr ogs en buffer-lsning som gjr det mulig gjre sprringer offline,

    men lagring av data lar seg for yeblikket ikke gjre i SDK'et (dette er blitt forespeilet som en

    kommende forbedring i SDK'et).

    SDK'et gjr all kommunikasjon mot back-end over HTTPS og SSL og srger derfor for

    tilstrekkelig sikkerhet under datahndtering.

    4.3 Datadesign En User er medlem av et Household, men medlemslisten ligger lagret i en Role som er tilknyttet

    Household-et. Det skal dermed vre n Role per Household.

    Ved opprettelse av et Household lages det automatisk en Role som knyttes til Household-et

    gjennom navnet sitt som er p formen "household-" (f.eks. hvis et nytt

    household har id="UlKu48h8ZN" vil name-feltet til Role-objektet vre "household-

    UlKu48h8ZN"). I Role-en ligger alle medlemmene av Household-et.

    Role er en spesiell klasse i Parse som brukes for sette rettigheter p objekter via en RBAC

    implementasjon i Parse sin ACL. Alle medlemmer av en Role fr tilgang til alle objekter som Role-

    objektet har tilgang til.

    Klassene er koblet tett sammen og er avhengig av en del samhandling. En User er medlem av et

    Household gjennom en Role som er tilknyttet det respektive Household-et. En Note er skrevet av en

    User og hrer til et Household.

    Parse tilbyr et sett med ferdig definerte klasser som kan brukes og utvides med egne felter. De

    klassene som er tatt i bruk, er User, Role og Installation. Resten er egendefinerte klasser. Feltene

    markert med tykk skrift, er de som er lagt til, resten flger med automatisk.

    Visse felter er like for alle klassene og blir automatisk oppdatert og hndtert av Parse:

    objectId

    o objectId er en unik ID. Alle objekter har sine egne unike ID'er.

    o Denne er garantert unik for alle objekter i en gitt klasse (kan med andre ord i teorien ha duplikate objectId'er p tvers av klasser).

    createdAt

    o createdAt beskriver datoen objektet ble opprettet.

    updatedAt

    o updatedAt beskriver datoen objektet sist ble oppdatert.

    ACL

    o ACL (Access Control List) beskriver hvem som har rettigheter til skrive og lese objektet.

    Kan enten settes til enkeltbrukere, eller til Role-objekter.

    o Blir ikke oppdatert av Parse.

    o Denne styres av utvikler for lse ned data.

    All data som hentes blir lagret i datastrukturene som Parse sitt SDK for hver plattform tilbyr. Disse

    fremstr for brukere av SDK'et som key-value store-datastruktur (dictionary/hash-map).

  • Side 12 av 75

    Figur 2: Datadesign tegnet i UML

  • Side 13 av 75

    Datadesignet er bygd opp av klasser i Parse sin NoSQL-lsning. Et bilde av klassene og deres

    relasjoner ses i figur 2.

    4.3.1 Role Role-klassen er en klasse som er bygget inn i Parse. De to viktigste feltene i bruk er name og

    users.

    Navnefeltet m vre unikt, da det er dette som brukes for lokalisere objektet i databasen. Role

    skal kun brukes i forbindelse med Household (se beskrivelse av Household) i dette prosjektet.

    En Role i Parse blir brukt til sette ACL p andre objekter. Man setter ACL p et annet objekt med

    enten brukere eller roller og spesifiserer om det er tilgang til lese og/eller skriverettigheter

    (eventuelt nekt p tilgang). Det er i dette prosjektet benyttet til lse ned tilganger p alt som har

    med et Household gjre. Siden medlemslisten til et Household ligger lagret i Household-ets

    respektive Role fr alle medlemmer tilgang til objekter hvor Role-en settes i ACL.

    Spesielle felter i Role:

    I Role-klassen finnes det en del felter som flger med, men som ikke er standard p vanlige Parse-

    klasser.

    roles (Relation): En rolle kan vre medlem av andre roller. Denne er ikke i bruk i dette prosjektet.

    users (Relation): Liste over brukere som er medlem av rollen. Denne blir brukt som brukerlisten til bofellesskapet.

    name (String): Navnet p rollen. Denne blir brukt til referere til objektet, i stedet for objectId. Feltet skal ha navn p formen "household-".

    Relasjoner i Role:

    En Role skal ha 1 Household.

    4.3.2 Household Household-klassen beskriver et bofellesskap. Hvert bofellesskap knytter brukere opp mot seg selv

    som medlemmer gjennom sin respektive Role. For hver eneste Household skal det vre et Role-

    objekt som hrer til denne. Det er i dette Role-objektet hvor medlemslisten til bofellesskapet ligger

    lagret.

    Et Household skal kun lages via Cloud Code-funksjonen som heter "createNewHousehold".

    Egendefinerte felter i Household:

    householdName (String): Navnet p bofellesskapet.

    Relasjoner i Household:

    Et Household skal ha 0 eller flere User.

    Et Household skal ha 1 Role.

    Et Household skal ha 0 eller flere Note.

  • Side 14 av 75

    4.3.3 User User-klassen beskriver en bruker. Den er bygget inn i Parse og er utvidet for dette bruket (se tykke

    felter i ER-diagrammet). Hvert objekt er en unik bruker og kan ses p som en brukerkonto.

    Egendefinerte felter i User:

    displayName (String): I stedet for fornavn og etternavn er det ett felt hvor man kan velge hvilket navn som skal vises hos deg og hos andre brukere.

    profilePicture (File): En bilde-fil som brukeren selv kan laste opp som sitt profilbilde.

    Spesielle felter i User:

    I User-klassen finnes det en del felter som flger med, men som ikke er standard p vanlige Parse-

    klasser.

    username(String): Brukernavnet til brukeren (skal vre samme som email)

    password(String): Passordet til brukeren (kryptert og skjult for alle)

    email(String): E-post-adressen til brukeren

    authData (authData): Felt som blir brukt ved autentisering med sosiale medier (gjres automatisk av Parse)

    Relasjoner i User:

    En User skal ha 0 eller flere Household.

    En User skal ha 0 eller flere Note.

    4.3.4 Note Note-klassen beskriver et felles notat/beskjed i et Household. Det er en beskjed som er skrevet av

    en User som er medlem av et Household og kan ses av alle andre brukere som er medlem av det

    samme Household-et (dette styres av Household-ets sin Role som blir satt som ACL).

    Egendefinerte felter i Note:

    body (String): Selve notatet og informasjonen som skal vises til brukere

    createdBy (Pointer): Peker til brukeren som har opprettet objektet

    household (Pointer): Peker til bofellesskapet objektet er knyttet til.

    Relasjoner i Note:

    En Note skal ha 1 User

    En Note skal ha 1 Household

  • Side 15 av 75

    4.3.5 Event Event-klassen beskriver en hendelse i et bofellesskap. Den brukes for kunne vise en strm av

    hendelser til brukere i et bofellesskap, slik at man kan holde seg oppdatert ved kun ta et overblikk

    over hendelses-strmmen.

    Event er bygget opp av et type-system. Typen hendelse er definert ved tall og hendelsene som er

    implementert i klient og cloud-code er som flger:

    0: Ny bruker i bofellesskapet

    1: En bruker har forlatt bofellesskapet

    2: Ny Liste (TaskList)

    3: Liste har blitt markert som fullfrt

    4: Nytt utlegg (Expense)

    5: Utlegg har blitt gjort opp (Expense settled)

    En Event opprettes automatisk med Cloud Code og skal aldri lages direkte av en klient. Klienten

    bruker kun type-systemet for avgjre hvordan informasjonen i et Event-objekt skal vises til

    bruker.

    Egendefinerte felter i Event:

    type (Number): Hvilken type hendelse objektet handler om (se forklaring over).

    household (Pointer

  • Side 16 av 75

    4.3.6 Invitation Denne klassen beskriver en invitasjon til et Household. Den blir sendt fra en User til en annen.

    En Invitation kan aksepteres med en Cloud Code-funksjon som heter "acceptInvitation". Nr en

    Invitation er akseptert er den inviterte brukeren medlem av bofellesskapet som invitasjonen gjelder

    for.

    Egendefinerte felter i Invitation:

    household (Pointer): Peker til det bofellesskapet som invitasjonen gjelder for.

    inviter (Pointer): Peker til brukeren som har invitert.

    invitee (Pointer): Peker til brukeren som har blitt invitert til bofellesskapet.

    Relasjoner i Invitation:

    En Invitation skal ha 1 User (inviter)

    En Invitation skal ha 1 User (invitee)

    En Invitation skal ha 1 Household

    4.3.7 TaskList TaskList representerer en liste som inneholder en mengde med TaskListElement-er. Disse er tenkt

    som gjremlslister for brukere av et Household. En TaskList er tenkt som en liste med elementer

    som kan krysses av. For eksempel en handleliste, hvor selve tingen som skal kjpes inn er

    TaskListElement-et og selve handlelisten er en TaskList.

    Disse er felles for alle brukere av et Household. Alle brukere av Household-et som TaskList-en er i

    kan legge til, fjerne og redigere alt i TaskList-en.

    Egendefinerte felter i TaskList:

    listName (String): Navnet til listen (for eksempel handleliste, vaskeliste eller todo).

    household (Pointer): Peker til bofellesskapet som listen er laget for.

    createdBy (Pointer): Peker til brukeren som har opprettet listen.

    done (Boolean): En boolsk verdi som beskriver om listen er fullfrt eller ikke.

    Relasjoner i TaskList:

    En TaskList skal ha 1 User (createdBy)

    En TaskList skal ha 1 Household

    En TaskList skal ha 0 eller flere TaskListElement

  • Side 17 av 75

    4.3.8 TaskListElement TaskListElement er underelementer av en TaskList. Disse er tenkt som gjreml som kan utfres og

    markeres som ferdige nr de er blitt gjort. Mer informasjon under TaskList.

    Egendefinerte felter i TaskListElement:

    elementName (String): Navnet p elementet (for eksempel vaske badet eller kjpe melk).

    taskList (Pointer): Peker til listen som elementet hrer til i.

    createdBy (Pointer): Peker til brukeren som har opprettet elementet.

    finishedBy (Pointer): Peker til brukeren som har markert elementet som ferdig.

    Relasjoner i TaskListElement:

    En TaskListElement skal ha 1 User (createdBy)

    En TaskListElement skal ha 0-1 User (finishedBy)

    En TaskListElement skal ha 1 TaskList

    4.3.9 Installation Installation blir brukt til hndtere push-meldinger. Hver enhet som installerer applikasjonen blir

    registrert som en Installation. Med andre ord er en Installation en enhet (iOS-enhet eller Android-

    enhet). Hver enhet skal ha en, og bare en, Installation.

    Nr en push-melding skal lages, s gjres det en sprring etter Installation-objekter som er knyttet

    til en bruker eller et household, avhengig av hvem meldingen er ment for.

    Egendefinerte felter i Installation:

    user (Pointer): Peker til brukeren som er logget inn p enheten

    household (Pointer): Peker til bofellesskapet som innlogget bruker er medlem av.

    Relasjoner i Installation:

    En Installation skal ha 0-1 User (user)

    En Installation skal ha 0-1 Household (household)

  • Side 18 av 75

    4.3.10 Expense Expense-klassen beskriver utlegg. Den blir brukt for holde orden p utlegg som er gjort i et

    bofellesskap. Brukeren som har gjort et utlegg blir oppfrt i owed, mens de som skal vre med p

    betale, blir lagt i en liste som heter notPaidUp.

    Etter hvert som pengene blir betalt tilbake vil brukerne flyttes fra notPaidUp til PaidUp av

    brukeren som er skyldt penger. Klassen inneholder ogs et felt for navn p utlegget, et for hvor

    mye som er lagt ut og et for en nrmere beskrivelse av utlegget.

    Egendefinerte felter i Expense:

    name(String): Navnet p utlegget.

    owed(Pointer ): Peker til brukeren som gjorde utlegget.

    notPaidUp(Array): Liste over de brukerne som ikke har betalt tilbake.

    paidUp(Array): Liste over de brukerne som har betalt tilbake.

    totalAmount(Number): Hvor mye som ble lagt ut.

    household(Pointer): Peker til householdet utlegget hrer til.

    details(String): Utfyllende detaljer om utlegget.

    Relasjoner i Expense:

    En Expense skal ha 1 User (Owed)

    En Expense skal ha 0 eller flere User (notPaidUp)

    En Expense skal ha 0 eller flere User (paidUp)

    En Expense skal ha 1 Household

  • Side 19 av 75

    5 Prosess og metoder Gruppen har benyttet flere prosesser, verkty og metoder for lse oppgaven. Disse har gjort

    fremgang og utvikling raskere og mer strukturert.

    5.1 Utvikling

    5.1.1 Utviklingsmodell De fleste programvareprosjekter benytter seg av utviklingsmodeller for ha en klar plan flge

    gjennom utviklingen av prosjektet. En slik utviklingsprosess srger for en strmlinjeformet

    utvikling som er forutsigbar og tydelig. Det skal aldri vre tvil om hva neste steg i prosjektet er.

    Prosjektet har blitt utviklet med en variant av inkrementell utviklingsmodell.

    Inkrementell utviklingsmodell baserer seg p tanken om at man starter med en initial forstelse av

    et problem og utvikler denne i inkrementer frem til man har en ferdig lsning.

    Hvert inkrement bestr hovedsakelig av fire deler: Kravspesifikasjon, designspesifikasjon,

    utvikling og til slutt validering og testing. Ved starten p hvert nye inkrement gr forrige inkrement

    inn som utgangspunkt til endringer og forbedringer.

    En inkrementell utviklingsprosess kan ses p som i figur 3:

    Figur 3: Inkrementell utviklingsprosess

    Inkrementell utvikling er en utviklingsmetode som lar prosjekter justere krav og utvikling

    underveis. Dette skjer fordi planlegging og kravspesifikasjon skjer i begynnelsen av hvert

    inkrement. Det er p dette punktet at inkrementell utvikling skiller seg spesielt ut i fra den mer

    tradisjonelle waterfall-modellen hvor et prosjekt i praksis er ett stort inkrement, og all planlegging

    gjres p begynnelsen av prosjektet.

    Inkrementell utvikling kan ligne veldig p iterativ utvikling, men skiller seg ut ved at iterativ

    utvikling ofte har kortere og mindre spesifiserte inkrementer. For eksempel har et inkrement i

    inkrementell utvikling et sett med krav som skal implementeres, mens iterativ utvikling gjerne har

    en satt tidsperiode hvor man skal implementere s mye som mulig i stedet. Dette frer til at iterativ

    utvikling har flere og mer forutsigbare tider p slipp av programvare, mens inkrementell utvikling

    har mer funksjonalitet i hver inkrement.

    Gruppen valgte inkrementell utvikling fremfor sin nrt beslektede iterativ utvikling og den mer

    tradisjonelle waterfall-metoden da kravene p forhnd ikke var helt fastsatt og mest sannsynlig

    ville endre seg i lpet av prosjektets utviklingstid.

  • Side 20 av 75

    5.1.2 Kodestandard Fr utvikling ble det satt opp en kodestandard for koden som skulle skrives. Dette ble gjort slik at

    koden skulle bli ryddig og lik for alle som skulle jobbe med den.

    Standarden er ikke veldig detaljert, s utgangspunkt ble satt til Google sin kodestandard for pene

    kildekode-prosjekter.

    De detaljene som har blitt spesielt definert for prosjektet, er som flger:

    5.1.2.1 Navnsetting

    Lange deskriptive navn fremfor forkortelser.

    Eksempler:

    UIButton *settingsButton;

    Figur 4: Riktig

    UIButton *setBut;

    Figur 5: Feil. Forkortelser som er vanskelige forst

    Stor forbokstav i klassenavn og camelCase overalt

    Eksempler:

    class MinKlasse { public void minFunksjonSomGjoerNoe() {...} }

    Figur 6: Riktig

    class minKlasse { public void Funksjon() {...} public int enannenfunksjon() {...} }

    Figur 7: Feil

    5.1.2.1.1 Android-spesifikt

    Navnet p java-filene i Android, som er av en spesifikk Android-klasse, skal slutte p navnet til

    klassen.

    Det vil si at filer lett kan identifiseres som Activity-filer, Fragment-filer osv.

    Eksempler

    Riktig: LoginActivity.java

    Riktig: FeedFragment.java

    Feil: Login.java

    Feil: Feed.java

    Riktig: Event.java (denne er en subklasse av ParseObject, men er ikke relevant til Android rent

    spesifikt)

    Feil: EventParseObject.java (dette vil vre for vidlftig og har ingen hensikt)

  • Side 21 av 75

    Layout-filer skal ha sm bokstaver og ordene deles med understrek. Typen layout skal vre frste

    ord i filnavnet.

    Eksempler:

    Riktig: activity_main.xml

    Riktig: dialog_new_note.xml

    Riktig: fragment_me.xml

    Feil: main.xml, main_acitivity.xml

    Feil: new_note_dialog.xml, noteDialog.xml, note_dialog.xml

    Feil: me.xml

    5.1.2.2 Innrykk

    Innrykk skal ikke vre tabulatortegn, men i stedet best av 4 mellomromstegn.

    Med andre ord:

    Tab = 4 mellomrom

    5.1.2.3 Krllparentes-posisjon

    Krllparenteser skal settes p samme linje som funksjons- og klassenavn, med unntak av der

    funksjons- og klassenavnene er s lange at de gr over flere linjer.

    Eksempler:

    public void funksjon() { ... }

    Figur 8: Riktig

    private double annenFunksjon() { ... }

    Figur 9: Feil

    public void langtFunksjonsNavnSomMDelesOverFlereLinjer(int index, double value) { ... }

    Figur 10: Riktig bruk av unntak

    public void langtFunksjonsNavnSomMDelesOverFlereLinjer(int index, double value) { ... }

    Figur 11: Feil bruk av unntak

  • Side 22 av 75

    5.1.3 Versjonskontroll Gruppen har valgt Git som versjonskontrollsystem og med dette en sentralisert Git-tilbyder som

    heter Github og befinner seg p www.github.com. Github tilbyr en enkel og rask lsning med bde

    privat og offentlig oppbevaring av data. Prosjektet har under utviklingen ligget i en privat

    oppbevaring som kun gruppens medlemmer har hatt tilgang til lese og skrive til.

    Git ble valgt for versjonskontroll fordi dette er en de mest brukte programvarene for dette

    (Freeman, 2013), samt at gruppens medlemmer hadde kunnskap og erfaring med Git fra tidligere.

    Det finnes flere gode Git-tilbydere, men Github passet bedre med tanke p enkelhet og

    funksjonalitet. Muligheten til utforske, ske og bla seg igjennom nvrende og tidligere

    versjoner av kildekoden sentralt, har gjort mange utviklingsoppgaver enkle.

    5.1.4 Utviklingsverkty Utviklingsverkty er en vesentlig del av et prosjekt og mye tid har blitt brukt p velge riktig

    verkty til jobben som skal gjres. Verktyene gjr arbeid lettere, ker produktivitet og er viktige

    for at gruppens medlemmer skal trives i arbeidet. Drlige verkty kan felle store deler av et

    prosjekt, mens gode og riktige verkty kan fremme kvalitet.

    Gruppen har i lpet av utviklingen brukt en rekke verkty for gjennomfre prosjektet - alt fra

    integrerte utviklingsmiljer (IDE) til verkty for prosjektstyring og modellering av

    brukergrensesnitt.

    Verktyene er valgt etter gruppens preferanser og hva som har passet best for prosjektet.

    5.1.4.1 Integrerte utviklingsmiljer (IDE)

    Prosjektet har brukt mange programmeringssprk og plattformer under utviklingen og det har

    derfor blitt brukt flere IDE'er.

    Valgene er blitt gjort basert p hva som er sett p som standard og hva som er gruppens egne

    preferanser.

    5.1.4.1.1 Android

    Til utvikling av Android-klienten valgte gruppen Android Studio.

    Android Studio er et nytt IDE fra Google som skal erstatte Eclipse med ADT Plugin. Android

    Studio er bygget p et Java IDE som heter IntelliJ IDEA og har lagt til Android-spesifikke verkty

    som gjr utvikling av Android-applikasjoner lettere. (Getting Started with Android Studio, u..)

    Android Studio har meget god sttte for syntaks-fremheving, faktorisering av kode som tar hensyn

    til Android-spesifikk deler, integrasjon med Android sitt SDK, en layout-editor med trekk-og-slipp

    og mange andre nyttige funksjoner.

  • Side 23 av 75

    Figur 12: Skjermdump Android Studio

    5.1.4.1.2 iOS

    Da det ikke er mange gode alternativer til IDE'er for iOS-utvikling falt valget naturlig p Xcode.

    Andre alternativer mangler sttte for WYSIWYG-editor (What You See Is What You Get) og

    krever som regel Xcode for gjre elementre oppgaver som simulering.

    Xcode er et program for Mac, laget av Apple Inc. og har sttte for alle steg i utviklingen av en iOS-

    applikasjon.

    Xcode er en utviklingsplattform laget spesielt for utvikling til Apple sine produkter og gjr en

    meget solid jobb p akkurat dette. Xcode har god sttte for syntaks-fremheving, debugging,

    brukergrensesnitt-generering (WYSIWYG) og har en simulator som lar utviklere simulerer

    applikasjonene sine p iPhone og iPad. Simulatoren er rask og har mange funksjoner for simulere

    enheter p en troverdig mte.

    Figur 13: Skjermdump Xcode

  • Side 24 av 75

    5.1.4.1.3 Cloud Code

    Cloud Code er kun JavaScript og til dette har IDE'et Coda 2 blitt brukt.

    Coda 2 er et program laget av Panic Inc til Mac OS X. Programmet kan kjpes fra Apple Mac Store

    og sttter en rekke programmeringssprk til web.

    Dette verktyet ble valgt, da syntaks-fremhevingen er meget godt, samt at gruppen hadde tilgang til

    denne fra fr prosjektets start.

    Coda 2 ble brukt til skrive selve koden, men ikke til opplastning av koden til Parse. Dermed

    fungerte Coda 2 mer som en tekst-editor enn et IDE. Parse har egne kommandolinjebaserte verkty

    for opplastning av Cloud Code til Parse sine egne tjenere.

    5.1.4.2 Brukergrensesnittmodellering

    Det har i designfasen blitt laget modeller av brukergrensesnittet som har blitt brukt for gjre

    implementasjon av en sammensveiset brukeropplevelse enklere og lettere under utvikling og

    implementasjon.

    Brukergrensesnittmodelleringen er gjort i et verkty for iPad som heter AppCooker. Dette

    verktyet har latt gruppen tegne opp brukergrensesnitt for iOS. Android sitt brukergrensesnitt er

    oversatt med skjnn for srge for en tilsvarende opplevelse som iOS-brukergrensesnittet, men

    som fremdeles oppleves som en Android-applikasjon.

    Figur 14: Skjermdump AppCooker

    5.1.4.3 Diagrammer

    Til tegne og lage diagrammer er LucidChart av Lucid Software Inc. brukt.

    LucidChart er en webapplikasjon for lage flytskjemaer, UML-diagrammer og figurer. Med et

    enkelt grensesnitt basert p trekk-og-slipp, samt en bred implementasjon av UML var valget av

    diagramverkty relativt enkelt.

    UML har spesifikasjoner som i mange applikasjoner er drlig og mangelfullt implementert.

    LucidChart var den eneste som hadde alle elementene som prosjektet hadde behov for innebygd.

    Diagrammer har frst og fremst blitt brukt i designspesifikasjonsdokumentene for beskrive

    systemarkitektur og databasedesign.

  • Side 25 av 75

    Figur 15: Skjermdump LucidChart

    5.1.5 Testing Testing er en viktig del av ethvert prosjekt, srlig programvareprosjekter, da disse har veldig

    mange muligheter til feil. Det f luket ut feil er helt essensielt for kunne levere et

    tilfredsstillende produkt.

    Programvaretesting deles gjerne opp i niver, basert p hva de tester og omfanget av testene.

    Teknikkene for de forskjellige nivene er mange og varierende. Det finnes ulike synspunkter p

    hvilke niver av programvaretesting som er ndvendige og hvilke som er mest ndvendige. Det de

    fleste dog er enige om er at testing er ndvendig.

    Figur 16: Software Testing Niver (Software Testing Levels, u..)

    Fire ofte brukte niver p testing er (i stigende omfangsgrad) enhetstesting, integrasjonstesting,

    systemtesting og godkjenningstesting. (Software Testing Levels, u.) Se figur 16.

    Prosjektet valgte bruke enhetstesting, systemtesting og godkjenningstesting.

  • Side 26 av 75

    5.1.5.1 Enhetstesting

    Enhetstesting er en type testing som skal teste en liten enhet av koden, isolert fra resten av

    systemet. Man tester gjerne en klasse eller en funksjon direkte, og fjerner alle avhengigheter fra

    andre deler av systemet, slik at kun det som skal testes faktisk blir testet.

    Figur 17: Avhengigheter og Dependency Injection

    Problemet er beskrevet i figur 17. En enhet skal testes, men har avhengigheter som igjen har mange

    avhengigheter. Feil i avhengighetene kan lage feil i testen, selv om feilen ikke ligger i enheten som

    skal testes. Derfor lager man etterligninger av avhengighetene som man injiserer inn i enheten som

    skal testes. Etterligningen oppfrer seg som avhengigheten, men er fullstendig kontrollert av

    utvikleren. Dette kalles for Dependency Injection (DI).

    Et eksempel p bruk av Dependency Injection er hvis en enhet skal hente ned informasjon fra en

    sentralisert tjener, bearbeide informasjonen og returnere resultatet. Enheten bruker en annen enhet

    (avhengighet) som kobler seg til den sentraliserte tjeneren og laster ned informasjonen. Det man

    nsker teste er at enheten bearbeider data p korrekt mte og returnerer (eventuelt fornuftige og

    korrekte feilmeldinger) som den skal. Dersom den sentraliserte tjeneren ikke er oppe vil testen

    feile, uavhengig om enheten er korrekt eller ikke. Dette lses ved lage en etterligning av enheten

    som laster ned informasjonen. Etterligningen vil oppfre seg p samme mte som enheten den

    etterligner, men vil levere et sett med falsk informasjon som er testbar.

    5.1.5.1.1 Problemer med enhetstester i prosjektet

    Enhetstesting var ment som en del av prosjektet helt fra forprosjektet. Det ble fjernet fra prosjektet

    grunnet hyt tidsbruk for skrive testene. Skulle prosjektet bli dekket av enhetstester, ville ikke

    resultatet blitt like godt gjennomfrt som det faktisk ble.

    Denne delen beskriver forskene som ble gjort p implementasjon av enhetstesting, og hvilke

    problemer som dukket opp.

    Enhetstester ble forskt implementer tre ganger i lpet av prosjektet.

  • Side 27 av 75

    5.1.5.1.1.1 Frste forsk

    I frste forsk ble enhetstestene skrevet uten bruke Dependency Injection. Dette frte til tester

    som hadde mange avhengigheter, som gjorde det tilnrmet umulig garantere at en test fungerte

    hver gang. I tillegg ble det gjort implisitte nettverks-kall som frte til at testene ble trege veldig

    fort.

    For at enhetstester skal vre mest effektive br de kunne kjres ofte for finne regresjoner i koden.

    Dette ble vanskeligjort fordi det tok mange minutter kjre testene, selv for sm mengder med

    tester.

    5.1.5.1.1.2 Andre forsk

    Etter at frste forsk mtte skrotes (slette alle tester og g tilbake til ingen tester) var det fremdeles

    et sterkt nske om ha enhetstesting som en del av prosjektet. Lsningen ble bruke mer korrekte

    enhetstester med bruk av Dependency Injection.

    Fr Dependency Injection kunne brukes mtte all logikk separeres inn i klasser og funksjoner med

    Dependency Injection implementert. Dette var mye arbeid som kunne vrt unngtt om feilene i

    frste forsk ikke hadde blitt gjort.

    Det viste seg at selve testene ble veldig omfattende og kompliserte. Grunnen til dette var mest

    sannsynlig en systemarkitektur som ikke er helt ideell. For skrive en enkel test hvor enheten

    brukte Parse sine tjenere til gjre noe som helst, innebar det mange linjer kode.

    Siden Parse sitt API bruker statiske objekter var det ikke mulig bruke Dependency Injection

    direkte p disse. Det frte til et forsk p fange opp nettverkskallene til Parse og gi en falsk

    respons for sikre at responsen var den samme hver gang. Det innebar manuell skriving av HTTP-

    responser som mtte etterligne HTTP-responsene fra Parse sine tjenere.

    Grunnen til at det var behov for etterligne HTTP-responsene var fordi det ikke var mulig

    etterligne Parse sine klasser (for separere ut avhengigheter). Parse sine klasser er statiske, noe

    som gjr at de ikke kan injiseres, og dermed heller ikke kan etterlignes. Dermed mtte i stedet

    Parse sitt API injiseres p nettverksniv med egne HTTP-responser. For kunne etterligne

    responsen fra Parse mtte pakker fra Parse sniffes ved bruk av nettverkssniffere. Dette lot seg gjre

    ved godta alle sertifikater p iOS simulatoren. Alt dette gjorde skrivingen av en test til en meget

    tidskrevende aktivitet.

    En enhetstest for en enhet som skulle hente ned siste notater for et bofellesskap endte opp med bli

    betydelig lengre enn selve enheten.

    Dette var heller ikke et brukbart alternativ, og kunne ikke i praksis gjennomfres for et prosjekt av

    denne strrelsen.

    5.1.5.1.1.3 Tredje forsk

    I det tredje (og siste) forsket var mye lrt. Bruk av Dependency Injection var fremdeles

    lsningen, men Parse sitt statiske API gjorde dette vanskelig.

    Lsningen ble lage en wrapper til Parse sitt API. Det vil si en ikke-statisk klasse som pakker inn

    Parse sitt statiske API til noe som kan injiseres i en kontekst hvor Dependency Injection er brukt.

    En slik antistatisk klasse kan etterlignes og dermed brukes til Dependency Injection.

    Dette innebar nok en gang en omskriving av betydelige mengder kildekode for kunne

    gjennomfres, samt at nye tester mtte skrives.

    Den nye lsningen gjorde testene betydelig mindre, men samtidig langt mer omfattende fordi det

    etterligne alle avhengighetene er en komplisert jobb.

    Grunnet kompleksiteten av testene og tiden det tok skrive de, ble nok en gang enhetstestene

    fjernet fra prosjektet. Denne gangen for godt.

  • Side 28 av 75

    Problemet kunne vrt unngtt om hele prosjektet hadde hatt en annen struktur med mindre

    avhengigheter i hver enhet.

    Det var ikke forsvarlig skrive om hele prosjektet p det tidspunktet som dette var kommet til. Det

    ville innebre alt for mye tid og arbeid som ikke ville gitt nok tilbake for tiden lagt inn i det.

    Ved fjerning av testene og strukturen som var lagt opp rundt enhetstesting var dette resultatet av

    opplastning til git:

    94 files changed, 957 insertions(+), 4053 deletions(-)

    Figur 18: Utskrift fra git etter fjerning av tester og struktur rundt

    3000 linjer med kode ble slettet over 94 filer totalt (dette gjaldt kun iOS). Dette utgjorde en

    betydelig del av prosjektet og styrket valget om til slutt fjerne testene.

    5.1.5.2 Systemtesting

    Systemtesting er den testprosessen hvor man tester et sammensatt, fungerende system. Det er i

    dette tilfellet vrt gjort ved teste applikasjonen manuelt.

    Testing av hele systemet har vrt gjort flere ganger i lpet av hvert inkrement. Systemtestingen har

    blitt gjort ved bruke et skjema med avkryssing. Skjemaet har forskjellig funksjonalitet som skal

    testes, og dersom funksjonalitet fungerer som ventet, krysses det av for den.

    Figur 19: Utklipp fra testdokument

    Ved legge til nye manuelle tester for hvert inkrement, har all funksjonalitet blitt testet ved hvert

    inkrement. Dette gjr at samtidig som man tester ny funksjonalitet, testes det ogs for regresjoner.

    5.1.5.3 Godkjenningstesting

    Godkjenningstestingen er testing for akseptabilitet, om systemet blir godtatt av brukere. Testingen

    avgjr om systemet flger kravene som er satt og om det er klart for levering.

    Godkjenningstestingen i prosjektet har blitt gjort helt p slutten av prosjektet med en betatest for

    iOS og Android. Gruppen fant noen brukere som kunne prve systemet i egen kontekst og som

    kunne gi tilbakemeldinger p systemet og melde om feil.

    Det er ikke blitt gjort stort med tilbakemeldingene fra betatesten, da denne ble utfrt helt p slutten

    av prosjektet. Feil som ble rapportert, er det eneste som er hndtert i etterkant. Tilbakemeldingene

    er dog notert og kan vurderes i videre utvikling av prosjektet.

    Det ble meldt nske om mer veiledning i applikasjonen, slik at brukerne lettere kan vite hva ting

    kan brukes til og hvordan de skal brukes.

    Det ble ogs meldt om noe forvirrende navn p den delen som er ment for felles beskjeder. I dag

    heter den "Notes", noe som kan vre litt tvetydig.

    Testingen ga en god indikasjon p ting som burde endres, og staker ut veien for videre utvikling av

    prosjektet.

  • Side 29 av 75

    5.2 Prosjekt For at et prosjekt skal kunne utfres effektivt og plitelig er det ofte behov for bygge opp en

    gruppestruktur, styrket av verkty for prosjektstyring og informasjonsflyt. Gruppen har hele tiden

    hatt en flat struktur, hvor alles mening har veid like tungt vedrrende valg som er gjort underveis. I

    dette kapittelet flger gruppens oppbygning, samt de forskjellige verktyene som er blitt benyttet

    underveis.

    5.2.1 Gruppestruktur Selv om gruppen har hatt en flat struktur uten en utnevnt leder har det blitt fordelt srlige

    ansvarsomrder p de forskjellige medlemmene. De forskjellige ansvarsomrdene er fordelt slik:

    Katrine Myklevold

    Design av brukergrensesnitt

    Utvikling til iOS

    Testrutiner

    Testing

    Gjermund Bjaanes

    Implementasjon av database, samt Cloud Code i Parse

    Utvikling til iOS

    Utvikling til Android

    Johann Eckhoff

    Utvikling til Android

    Testing

    Hndtering av Beta-testing

    5.2.2 Evernote Til felles notater og smdokumenter har Evernote fra Evernote Corporation blitt brukt.

    Evernote er en kryssplattform notat-applikasjon. Den lar brukere lage notatbker og skrive alle

    slags mulige notater (med rikt innhold som tekst, bilder og lyd). Gruppen har hatt en delt notatbok

    som har blitt brukt til alle notater og smdokumenter underveis i prosjektet.

    I den delte notatboken har det ligget mye informasjon som har vrt greit kunne referere til under

    utviklingen. Eksempler p dette er testskjemaer, designbestemmelser og kodestandard.

  • Side 30 av 75

    Figur 20: Skjermdump Evernote

    5.2.3 Gantt-diagram Et Gantt-diagram er et diagram for illustrere tidsplanleggingen i et prosjekt. Det viser nr ting er

    planlagt starte, hvor lang tid det er planlagt bruke p det og nr det skal vre ferdig.

    For produsere Gantt-diagrammer til prosjektet har et pent-kildekode-program som heter Gantt

    Project blitt brukt.

    Gantt Project er en kryssplattform-applikasjon som er enkel bruke og har tilstrekkelig

    funksjonalitet til produsere Gantt-diagrammer.

    Figur 21: Skjermdump Gantt Project

  • Side 31 av 75

    5.2.4 Prosjektstyringsverkty Gruppen har benyttet seg av en web-applikasjon som heter Trello.

    Trello lar brukere sette opp en digital arbeidstavle som representerer prosjektet man jobber med. P

    tavlen kan man sette opp lister hvor hver liste kan ha kort som representerer en oppgave.

    Kortene (oppgavene) har navn og kan inneholde tidsfrister, hvilke medlemmer av gruppen som har

    blitt satt til gjre oppgaven og mer detaljert informasjon om oppgaven.

    Figur 22: Skjermdump fra Trello (tatt fra gruppens egen tavle)

    Gruppen har brukt Trello gjennom hele prosjekttiden for holde styr p oppgaver og tidsfrister.

    Verktyet har srget for at gruppen har holdt en st kurs hele tiden og ftt gjort unna oppgaver

    innen rimelig tid.

    6 Resultat Resultatet av prosjektet er avgjort av produktet og prosjektets ml.

    6.1 Produkt Produktet er to klienter og en back-end, satt sammen til et system som fungerer i henhold til de

    kravene som er satt.

    Klientene fungerer hver for seg og sammen. Kommunikasjon mellom klienter skjer implisitt ved at

    brukere kommuniserer seg i mellom via data som er lagret i back-end.

    6.1.1 Produktml Gruppen mener de har lykkes i lage en applikasjon som oppfyller mesteparten av produktmlet,

    og kan gjre samboerskapssituasjoner enklere.

    Gruppen har ftt tilbakemeldinger p applikasjonen som bekrefter dette, men det er ogs mottatt

    noen negative tilbakemeldinger. Disse gr ut p at lringskurven for komme i gang er litt bratt.

    Det er ytret nsker om en veiledning som tar brukeren gjennom hovedfunksjonaliteten til

    applikasjonen frste gang man tar den i bruk. Allikevel mener gruppen at produktmlet er delvis

    oppndd.

    6.1.2 Kildekode Dette kapittelet forklarer litt om hvordan koden er lagt opp i klientene og demonstrer noen

    teknikker og metoder som er brukt i prosjektet.

  • Side 32 av 75

    6.1.2.1 Samtidighet (Concurrency)

    Begge klientene gjr nettverkskall utenfor hovedtrdene, men det er ikke implementert manuelt

    med trder eller samtidighets-API'er. Dette er i stedet brukt implisitt ved benytte metoder fra

    Parse sitt API som arbeider i bakgrunnen.

    Parse sitt API har sttte for samtidighet, og bruker call-back's for varsle klientene om at de er

    ferdige med laste ned og bearbeide.

    ParseQuery query = new ParseQuery("Expense"); query.getInBackground(expenseObjectId, new GetCallback() { @Override public void done(Expense expense, ParseException e) { ... } });

    Figur 23: Sprring i Android med Parse sitt API

    [PFUser logInWithUsernameInBackground:username password:password block:^(PFUser *user, NSError *error) { ... }];

    Figur 24: Sprring i iOS med Parse sitt API

    Android-koden i figur 23 og iOS-koden i figur 24 er bruker begge Parse sitt API for gjre

    nettverkskall mot Parse sine tjenere. Begge har en call-back som blir utfrt nr API'et er ferdig med

    jobben den skal gjre.

    6.1.2.2 Facebook

    Applikasjonen er integrert mot Facebook ved at man kan registrere seg som bruker av

    applikasjonen ved hjelp av profildetaljene sine fra Facebook. For dette brukes en kombinasjon av

    Parse sitt Facebook-API og Facebook sin egen SDK. Nr brukeren logger inn med Facebook, vil

    han bli spurt om applikasjonen skal f tilgang til profildetaljene sine. Disse blir s lagret som en ny

    bruker i databasen hos Parse. Dette gjr at det ikke tillates endre profildetaljer for en bruker som

    er logget inn via Facebook.

    I figur 25 (Android-kode) og figur 26 (iOS-kode) kan man se hvordan man kaller p Parse sin

    Facebook-integrasjon for logge inn med Facebook.

    ParseFacebookUtils.logIn(permissions, this, new LogInCallback() {

    @Override

    public void done(ParseUser parseUser, ParseException e) {

    // When login is done, the data fields are updated with the details

    // from the facebook user

    ...

    });

    Figur 25: Innlogging med Facebook p Android

    [PFFacebookUtils logInWithPermissions:permissionsArray block:^(PFUser *user, NSError *error) { // When login is done, the data fields are updated with the details // from the facebook user ... }];

    Figur 26: Innlogging med Facebook p iOS

  • Side 33 av 75

    6.1.2.3 iOS

    Koden til iOS er skrevet utelukkende i Objective-C og bruker Parse sitt iOS SDK.

    6.1.2.3.1 Struktur

    Koden til iOS har endret struktur flere ganger i lpet av prosjektet, som en flge av ny kunnskap og

    et nske om eksperimentere.

    Grunnet enhetstestenes bortgang var det ikke behov for separere all logikk fra View Controllers.

    Derfor er koden lagt opp slik at hver View Controller inneholder all relatert logikk. Dette har gjort

    noen klasser litt lengre enn de hadde behvd vre, men har gjort at utviklingen av disse har gtt

    betydelig fortere. Dette er ogs mten Parse har gjort ting i sine eksempler og veiledninger.

    For illustrere forskjellene har en innloggingsskjerm med separert logikk en liten View Controller-

    klasse som hndterer bruker-input og viser feilmeldinger, og en lengre hjelpeklasse for hndtere

    selve innlogging og feil fra Parse sine tjenere. Dette ville vrt en klart bedre struktur, men grunnet

    tidsbegrensninger ble ikke dette gjort.

    Slik det er gjort i prosjektet, har innloggingsskjermen kun View Controller-klassen som inneholder

    hndtering av brukerinput, kommunikasjon mot Parse, hndtering av feil og visning av disse til

    bruker.

    lage hjelpeklasser til alle interaksjoner mot Parse viste seg vre mye repeterende kode, noe

    som tyder p at deler av strukturen ikke er ideell. Det ble ogs mye repeterende kode ved kutte ut

    hjelpeklassene fullstendig, s en lsning som er "perfekt" er ikke funnet for dette prosjektet.

    Den beste lsningen ville vrt lage et lite sett med generiske hjelpeklasser. Dette var ikke noe

    gruppen fikk tid til gjennomfre.

  • Side 34 av 75

    6.1.2.3.2 MVC-mnsteret

    MVC (Model-View-Controller) design-mnsteret dreier seg om den globale arkitekturen i et

    program. Derfor er det et hyniv-mnster. MVC designmnsteret klassifiserer gjenstander etter de

    generelle rollene de spiller i applikasjonen. Et MVC design-mnster kan ogs omfatte flere

    MVC'er. Man drar nytte av tilpasse MVC'en for sitt eget design fordi mange gjenstander i disse

    programmene har en tendens til vre mer gjenbrukbare. Dette gjr at applikasjoner enklere kan

    tilpasse seg dersom krav endres eller hvis man trenger utvide applikasjonen. (Model View

    Controller, 2012)

    I MVC designmnsteret finnes det tre typer objekter: Model-objekter, view-objekter og controller-

    objekter. Modell-objekter er hva applikasjonen er (men ikke hvordan den er vist). Controller-

    objekter (eller View Controller) kontrollerer hvordan model-objekter blir presentert til brukeren

    (UI-logikk). View-objekter er brukergrensesnitt-elementer som controlleren styrer og bruker for

    presentere model-objekter.

    View Controlleren kan alltid snakke direkte til sine Model-objekter og til sine View-objekter.

    Model-objekter og View-objekter skal ikke snakke med hverandre. (Model View Controller, 2012)

    Det finnes flere mter implementere MVC i en iOS-applikasjon. Den mest ryddige mten er

    separere all logikk som ikke er direkte avhengig av data eller skjermelementer ut av View

    Controlleren. Dette har lett for innebre svrt mange klasser, en god del mer kode og litt mer

    rotete struktur i prosjektet. Samtidig har det en tendens til bli mindre klasser, er mer testbart og

    lettere forst hvordan View Controlleren jobber.

    Prosjektet har benyttet seg av en annen variant av MVC, der mesteparten av logikken ligger i View

    Controlleren, og modellene er enkle objekter (som for eksempel tabeller). Dette er for gjre

    utvikling raskere og fordi det ikke var noen klare fordeler med separere ut all logikken. Dette gjr

    ogs at iOS- og Android-versjonene har likere struktur.

    I en typisk skjerm kan View-delen vre skjermelementer som er laget i Xcode sin Storyboard (dra-

    og-slipp). Knapper, tekstfelter, oversikter og tabeller er typiske skjermelementer som er en del av

    View'et.

    Figur 27: Skjermdump fra Xcode. Viser et View

    Modellen kan for eksempel vre en liste med objekter som skal vises p skjermen p et eller annet

    vis.

    // Model @property (strong, nonatomic) NSArray *unfinishedTaskLists; // of TaskList *