Bacheloroppgave

Interaktivt bord til restaurant

B019 - G24 Lise G Hauslo Silje F Abrante Lars Thomas T Tollefsen 16.05.2019 Avdeling for informasjonsteknologi

HØGSKOLEN I ØSTFOLDAvdeling for InformasjonsteknologiRemmen1757 HaldenTelefon: 69 21 50 00URL: www.hiof.no

BACHELOROPPGAVE

Prosjektkategori:Utvikling

X Fritt tilgjengelig

Omfgang i studiepoeng:20

(30/122029)

Fritt tilgjengelig etter

Fagomrade:Informatikk og informasjonssystemer

(X) Tilgjengelig etter avtale medoppdragsgiver

Tittel:Utvikling av interaktivt restaurantbord

Dato:23. april 2019

Forfatterere:Silje Fedreheim Abrante, Lise Gellein Hauslo, Lars ThomasThorsby Tollefsen

Veileder:Kolleger ved HiØ/IT, HiOA/IU,UiO/IFI

Avdeling / Program:Avdeling for Informasjonsteknologi (alle programmer)

Gruppenummer:BO19-G24

Oppdragsgiver:HiØ/IT

Kontaktperson hos oppdragsgiver:Lars Thomas Thorsby Tollefsen

Ekstrakt:Abstract kommer her

3 emneord: FooBarFooBar

Forord

Denne oppgaven er skrevet av to informatikk studenter og en informasjonssystemer student i for-bindelse med vart bachelorprosjekt pa Høgskolen i Østforld for varen 2019. Oppgaven er gitt avTidbit AS som ønsket et samarbeid med IT-studenter for a utvikle en prototype til et interaktivtrestaurantbord. Vi valgte denne oppgaven da vi synes det var en oppgave med mange ulike utford-ringer og store muligheter til bade a bruke var kunnskap og kompetanse som vi har fatt gjennom2.5ar pa studiet og lære noe nytt underveis. Vi synes ogsa det er spennende at oppgaven gir et inn-blikk i hvordan det er a jobbe med digitalisering og utvikling av interaktive løsninger i samarbeidmed en startup bedrift. I denne rapporten skal vi beskrive var prosess og dokumentere utviklingenav en prototype av Tidbits interaktive restaurantbord.

Sammendrag

i

Takk Til

Vi ønsker a takke var veileder, Susanne Koch Stigberg, for god hjelp under skriveprosessen. Takketvære hennes mange tips og forslag til forbedringer har dokumentet vart blitt vesentlig bedre. Viønsker ogsa a takke Tidbit for a ha gitt oss sjansen til a arbeide med det interaktive bordet, og somstartup-bedrift oppmuntret oss til a komme med innspill til funksjonalitet. Videre er det pa plass atakke Ted Magnus Sørlie, som har bidratt med assistanse til teknisk hjelp.

iii

Innhold

Sammendrag i

Takk Til iii

Figurliste vii

Tabelliste ix

Kodeliste xi

1 Introduksjon 11.1 Prosjektgruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Veileder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Oppdragsgiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Oppdraget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Formal, leveranser og metode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Rapportstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Kartlegging 72.1 Kravspesifikasjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Funksjonelle krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Ikke funksjonelle krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Relaterte systemer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Teknologi og utstyr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Programmeringssprak og annen teknologi . . . . . . . . . . . . . . . . . . . . . 132.7 Lagring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.8 Kommunikasjonsprotokoller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Design 173.1 Systemoversikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Bruksmønstre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Sekvensdiagrammer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Valg av hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5 Valg av programvare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Implementasjon 274.1 Pre-prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Systemutvidelser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

v

vi INNHOLD

4.3 Hoved prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Testing 315.1 Hensikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Testlokasjoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.3 Utstyr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.4 Funksjonstesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.5 Stresstesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.6 Laste ned oppdateringer til systemet . . . . . . . . . . . . . . . . . . . . . . . . 325.7 Sikkerhetstesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Diskusjon 33

7 Konklusjon 35

8 Videre utvikling 37

Bibliografi 39

Register 41

Figurer

1.1 Oppdraget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

10figure.2.111figure.2.212figure.2.312figure.2.413figure.2.513figure.2.614figure.2.714figure.2.814figure.2.915figure.2.103.1 Systemoversikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Bruksmønster - Restaurant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Bruksmønster - Bruker sender bestilling . . . . . . . . . . . . . . . . . . . . . . 203.4 Bruksmønster - Bordstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5 Sekvensdiagram - Legg til matrett . . . . . . . . . . . . . . . . . . . . . . . . . 233.6 Sekvensdiagram - Bruker sender bestilling . . . . . . . . . . . . . . . . . . . . . 243.7 Sekvensdiagram - Endre bordstatus . . . . . . . . . . . . . . . . . . . . . . . . . 25

vii

Tabeller

1.1 Prosjektbeskrivelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

ix

Kodeliste

xi

Kapittel 1

Introduksjon

1.1 Prosjektgruppen

Gruppen bestar av to informatikkstudenter og en student fra informasjonssystemer. Gruppemed-lemmene har tidligere jobbet sammen pa prosjekter og oppgaver, og har derfor valgt a samarbeidepa dette prosjektet.

Silje Fedreheim Abrante

Silje er informatikk student fra Bergen med interesse for back-endutvikling, datamodellering, agile arbeidsmetoder og datasikkerhet. Hunhar tidligere jobbet som kundekonsulent i Oslo kommune og medteknisk support.

Lise Hauslo

Lise Hauslo er informatikkstudent fra Fredrikstad med interesse fordatabasesystemer, store datamengder og maskinlæring og hvordanoptimalisere disse teknologiene. Hun har tidligere jobbet med datasupport for sma firmaer.

Lars Thomas Thorsby Tollefsen

Lars er informasjonssystemstudent fra Vestfold med interesse forspillutvikling og prosjektstyring. Han har tidligere jobbet medfreelancing innen IT med videoredigering, utvikling og prosjektstyringhos bade norske og utlandske selskaper.

1

2 Kapittel 1. Introduksjon

1.2 Veileder

Veilederen for prosjektet er Susanne Koch Stigberg. Hun jobber som foreleser ved høgskolen i Øst-fold og underviser i interaksjonsdesign og ulike programmeringsfag. Hennes forskningsinteresseer i mobil interaksjonsdesign. Ved hjelp av et human-centered perspektiv og deltagende design,undersøker hun hvordan vi kan integreres med teknologi mens vi er i bevegelse.

1.3 Oppdragsgiver

Oppdragsgiver er Tidbit AS som bestar av Andre Lier og Emil Hamborgstrøm. Bedriften jobbermed a digitalisere restaurantbesøk ved a tilby et interaktiv bord til restauranter for a ta restauranterinn i fremtiden samtidig som Tidbit ikke ønsker a eliminere all kundekontakten med servitør.

1.4 Oppdraget

Figur 1.1: Oppdraget

Oppdraget var i den orginale oppgavebeskrivelsen kun en stykk prototype, men 14 januar2019 kom oppdragsgiver med forespørsel om a lage to prototyper, og videre med ønske a ha pre-prototypen klar til 6 februar 2019. Oppdragsgiver fikk tak i en restaurant som skulle legges ned, ogfikk sjansen til a benytte restauraten dagen etter nedleggelse, den 6 februar 2019. Det var ønskeligfra oppdragsgivers side a teste prototypen pa en fokusgruppe i samme scenarioet og miljø somendelig produkt skal benyttes i.

Gruppen valgte a si ja til forespørselen til tross for kun 23 dagers frist pa pre-prototype, for detførste med tanke pa oppdragsgiver, som en start-up bedrift er avhengig av sponsorer og kan bruke

1.5. Formal, leveranser og metode 3

fokusgruppe intervjuet i søknader om økonomiske midler. For det andre for a fa bedre samarbeid-sprossess med oppdragsgiver og innsikt i deres behov. Og for det tredje med tanke pa utviklingenav systemet da pre-prototypen kunne gi verdifull informasjon til a ta med i utviklingen av pre-prototypen.

Pre-Prototype I pre-prototypen er det behov for et grafisk webgrensesnitt som kan benyttespa Samsung Galaxy tablet slik at kunden kan se restaurantens meny. Oppdragsgiver star for tab-lets. Grensesnittet implementeres gjennom enkle designskisser gitt av oppdragsgiver. Restaurantsgrensesnitt pa kjøkkenet viser bordnummeret, retten og antall, og viser i tillegg om en kunde hartilkalt servitør. Informasjonen fra kundegrensesnittet skal lagres i strukturert filformat.

Main prototype Systemet gruppen skal utvikle er et bord med en interaktiv touch skjerm inte-grert i bordplaten. Fra skjermen kan restaurantgjestene bestille mat, drikke og tilkalle servitør vedbehov. Bordet overstyrer restaurantens eksisterende kassesystem, og er a anse som et �Plug-and-play� system. Det er behov for et restaurant kontrollpanel med styringsvalg for bestillinger ogmeny.

Utover oppgavebeskrivelsen er det ønskelig at systemet handterer a lagre store mengder data,som oppdragsgiver pa et senere tidspunkt skal benytte for a skaffe seg innsikt i kundemønster og-oppførsel. Oppdragsgiver star for analysen av dataene. Videre utover oppgavebeskrivelsen er detønskelig at front-end design skal implementeres etter enkle designskisser fra oppdragsgiver.

Oppdragsgiver star for bord og touchskjerm. Tidbit ønsker a bruke Raspberry Pi som datama-skin hvis passende. Utenom det star gruppen fritt til a velge programmeringssprak, lagringssystemog datakommunikasjon. Under er original bildebeskrivelse.

Prosjektforslag Bacheloroppgaven Avdeling for Informasjonsteknologi, HiØ

1.5 Formal, leveranser og metode

1.5.1 Formal

Formalet er a utvikle en prototype for en restaurants interaktive bestillingsskjerm som er inte-grert i bordet. Dette skal igjen bidra til a effektivisere bestillingsprosessen samt tilrettelegge for aanalysere og handtere bestillingene pa en mer automatisert mate.

1.5.2 Leveranser høgskolen i Østfold

Ved prosjektslutt skal det leveres følgende til høgskolen i Østfold som del av bacheloroppgavenvaren 2019:

• Gruppekontrakt

• Prosjektkontrakt

• Hjemmeside

• Forprosjektrapport

• Hoveddokument

4 Kapittel 1. Introduksjon

Prosjektnavn: Interaktivt bord til restauranterOppdragsgiver: Tidbit ASKontaktpersoner: Andre Lier (CEO) / Sigvart Andersen (Styreleder)

Prosjektbeskrivelse:Utvikling av programvare til en prototype for testing hos varekunder.

Hva gjør denne oppga-ven nyttig/interessant?

Det interaktive bordet utvikles med fokus pa Nordisk designsom tar restauranter inn i fremtidens teknologi uten a elimine-re kundekontakten med servitører.Selskapet har allerede landetkunder som Olivia, Delikatessen og Fabel. Vi skal ogsa delta iakselerator-programmet til Blender Collective og muligens EkerExpress. Det er flere interesserte investorer, bl.a. Fredriksborg Ei-endom. Mye av interfacen er designet, men det er store muligheterfor a pavirke.

Krav til studentenes for-kunnskaper:

Rasberry Pi, evt. utvikling av programvare med hardware fra varleverandør. Vi er apne for forslag til kodesprak.

Krav til spesielt utstyr(hard-ware/software,verktøy og annet utstyr):

Vi skaffer det som trengs.

Annet:Interaktive skjermer og utstyr er allerede bestilt. Andre partnere iprosjektet er GDM, Loyds, Drivhuset Østfold, Blender Collecti-ve, Eker Design og Agera Venture.

Tabell 1.1: Prosjektbeskrivelse

• Pre-Prototype

• Main prototype

• Prosjektplakat

• Refleksjonsnotater

• Prosessraport

1.5.3 Leveranser Tidbit AS

Ved prosjektslutt skal det leveres en Main prototype som oppdragsgiver kan benytte pa et interaktivbord. Denne Main prototypen bestar av software til en bordskjerm og til et enkelt kontrollpanelsom kommuniserer med bordet. Det er mulig for restauranten a styre kontrollpanelet.

• Pre-Prototype

• Main prototype

1.5.4 Metode

Gruppen velger a bruke agile arbeidsmetoder. Spesifikt, vil gruppen kombinere de to agile arbeids-metodene SCRUM og Extreme Programming for sikre flyt under skrive- og utviklingsprossesen.

1.6. Rapportstruktur 5

Intensjonen med dette valget er for a sikre at oppdragsgivers interesse blir ivaretatt og at kommuni-kasjon mellom gruppens medlemmer er pa høyt niva. Videre, ved a holde oppdragsgiver involverti prosessen kan gruppen kan fa kontinuerlige tilbakemeldinger og evalueringer slik at nødvendigejusteringer i programmet kan gjøres underveis. Dette er særlig viktig da oppdragsgiver oppmuntrergruppen til a komme med ideer til funksjonalitet.

1.6 Rapportstruktur

I Kapittel 2, presenteres kravspesfikasjonen til prosjektet. Basert pa kravspesifikasjonen kommeren liste over teknologikriterier gruppen valgte basert pa kravspesifikasjone. Til slutt kommer enkartlegging av teknologier som er aktuelle til prosjektet basert pa kravspesifikasjonen og kriterie-listen. Deretter, i kapittel 3 gis det en systemoversikt med konseptskisse, bruksmønstre, sekvens-diagrammer og en seksjon om hvorfor gruppen valgte ut teknologiene de gjorde. Videre, i kapittel4 dokumenteres implementasjonen av systemet med skisser og kodeforklaringer. Det blir ogsa settpa prosjekts funksjonalitet og tiltenkt virkemate. Utover, i kapittel 5, legges det frem testing ogevaluering av systemet med testlokasjoner, utstyr og de ulike testene som ble utført. Derpa, i ka-pittel 6 forklares det hva gruppen har tilegnet av erfaring under prosjektet, om malene ble nadd,og hva gruppen kunne gjort bedre. Avslutningsvis, i kapittel 7 kommer en konklusjon som tar forseg de fremtredende delene av diskusjonskapittlet.

Kapittel 2

Kartlegging

2.1 Kravspesifikasjon

2.1.1 Beskrivelse

Denne seksjonen omhandler beskrivelser av løsninger og krav til utvikling av interaktiv restaurant-bord for Tidbit AS. Beskrivelsene innholder funksjonelle og ikke-funksjonelle krav for at systemetskal bli realisert. Da oppdragsgiver er lite IT-kyndig, er det lagt vekt pa a ikke bruke et teknisksprak i kravspesifikasjonen, men heller med hensyn til oppdragsgiver a bruke et sprak som enkeltkommuniserer hvilke behov systemet implementerer.

2.1.2 Omfang

Systemet skal utvikles som et en prototype av et framtidig verktøy for a effektivisere og digitali-sere bestillingsprosessen pa restauranter. Systemet har to typer sluttbrukere: kunde og servitør. Iprototypen skal kunden ha mulighet til a legge inn bestillinger, og tilkalle servitør via en skjerm pabordet. Servitøren skal kunne se bestillinger og tilkallinger som er kommet inn og behandle disse.

2.1.3 Systemet

Systemet bestar av en touch skjerm, et bord, en raspberry pi og programvare spesifisert i dettedokumentet. Ved hjelp av programvaren skal kunder pa en restaurant kunne bestille mat via entouch-skjerm plassert pa et bord. Bestillingene skal lagres i en database og vises i et brukergrense-snitt for servitøren. Servitøren skal sa kunne behandle bestillingen. Det skal ogsa være mulighetfor a tilkalle servitør fra kundens brukergrensesnitt. Prototypen skal kunne brukes til testing/pre-sentasjon hos Tidbit AS sine kunder/interessenter. Utviklingen av prototypen er BO19 - G24 sinbachelor oppgave.

2.2 Funksjonelle krav

2.2.1 Menyvisning

1. Kunden skal kunne se restaurantens meny.

2. Kunde skal kunne velge antall av vare/matrett og legge den til i bestillingen

3. Kunden skal kunne se prisen pa mat og drikke

7

8 Kapittel 2. Kartlegging

4. Kunden skal kunne se allergen liste.

2.2.2 Bestilling

1. Kunden skal kunne se et sammendrag av bestillingen og enten akseptere eller redigere førbestillingen sendes

2.2.3 Tilkalle servitør

1. Kunden skal kunne tilkalle servitør ved hjelp av knapp

2. Kunden skal kunne tilkalle servitør for betaling ved hjelp av knapp.

2.2.4 Behandle bestillinger i kontrollpanel

1. Servitør / personale skal kunne se innkommende bestillinger

2. Innkommende bestillinger skal besta av vare(r), antall, bordnumer og tidspunkt.

3. Servitør skal kunne markere bestillingen som behandlet, servert, betalt.

2.2.5 Behandle henvendelser i kontrolpanel.

1. Servitør skal til enhver tid kunne se en oppdatert oversikt over hvilke bord som har pakalthjelp.

2. Servitøren skal kunne registrere at et bord har fatt hjelp

2.2.6 Behandle meny i kontrolpanel

1. Restauranten skal kunne legge til, endre eller slett matrett.

2. Restauranten skal kunne legge til, endre eller slette drikkevarer.

2.2.7 Betaling

1. Betaling funksjonalitet handteres av oppdragsgiver.

2. Integrering med kassesystem handteres av oppdragsgiver.

2.3 Ikke funksjonelle krav

2.3.1 Brukergrensesnitt

Det skal implementeres to enkle brukergrensesnitt etter skisse fra oppdragsgiver. Det ene bru-kergrensesnittet er grafisk rettet mot kunden. Det andre brukergrensesnitter er et kontrollpaneltil restauranten som inneholder bestillinger, henvendelser og menyoversikt. Det avtales dato forlevering av skisse. Etter denne datoen kan ikke skissen endres.

2.3.2 Kostnad

Systemet skal utvikles pa mest kostnadseffektive mate.

2.4. Relaterte systemer 9

2.4 Relaterte systemer

Det finnes et spekter av digitale løsninger som effektiviserer bestilling av mat ute i restaurantbran-sjen. Det Vi har sett pa følgende digitale løsninger som har klare likhetstrekk med vart prosjekt ogsom er i bruk i norske restauranter pr dags dato. Basert pa besøk som kunder pa de ulike restau-rantene har vi gjort følgende observasjoner.

2.4.1 McDonalds og Burger King

McDonalds og Burger King har digitale bestillingsløsning i sine restauranter. Deres system bestaroverordnet av interaktive skjermer ute i restauranten som kundene bestiller mat pa. Bestillingenblir sa sendt til skjermer pa kjøkkenet og bestillingsnummeret vises pa en skjerm i restauranten iet felt for lages”. Nar besillingen er klar for henting flyttes bestillingsnummeret fra lagestil klarfor henting”. Kunden henter sa maten sin i kassen. Mc donalds har ogsa testet ut bordservering iforbindelse med bestilling av mat pa skjerm. Brukeren ma da ta med seg et skilt med bordnummerpa og taster inn bordnummeret pa bestillingsskjermen.McDonalds og Burger King sine løsninger med bestillings-skjermer ved kasseomradet krever in-gen innlogging eller brukerkontoer som kunden ma ha for a kunne bestille mat. Dette er noe viogsa kommer til a unnga i var løsning. Bestillings-skjermene er hos McDonalds og Burger Kingplassert i kasseomradet. Da disse restaurantene er fast-food restauranter er dette en løsning somfungerer siden det ikke er sa stor fokus pa det a sitte lenge og spise pa den typen steder og det ogsaer vanlig a ta med maten for a spise den et annet sted. Var løsning kommer derimot til a bli bruktpa litt finere(?) restauranter hvor det er mer vanlig a sitte lengre og hvor det er vanlig a først finneseg et bord og sa bestille mat ved bordet. Derfor vil det være mer hensiktsmessig a bruke skjermerpa bordene i var løsning.

2.4.2 Pincho nation

Restaurantkjeden Pincho nation bruker en mobilapp for bade reservering av bord, bestilling avmat og drikke, betaling og tilkalling av servitør. Kunden laster ned en app i forkant av besøket ogbestiller bord. Nar kunden kommer til restauranten blir man møtt av en hovmester som viser entil bordet man har bestilt. Sa legger man inn bordnummer i appen g begynner a bestille mat ogdrikke. Nar bestillingen er klar far kunden en pushvarsel pa telefonen om at maten eller drikkenkan hentes ved kjøkkenet eller i baren. Man kan legge inn flere bestillinger fra samme enhet. Narman skal betale kan man velge mellom a betale i appen eller a tilkalle en servitør som kan ta imotbetaling med kort eller kontanter.Pinchos løsning er noe lik det vi skal utvikle i den forstaelse at det er snakk om en digital be-stillingsløsning for bestilling av mat og drikke som brukes ved bordet. Det er derimot ulikt varløsning da deres løsning er en app som ma lastes ned. Dette kan føre til at personer som ikke hareller ikke ønsker a laste ned appen eller personer som ikke har en smarttelefon blir ekskludert. Ivar løsning finnes appen i selve bordet og brukere trenger ingen profil for a bruke teknologien.

2.5 Teknologi og utstyr

2.5.1 Kriterier

Med bakgrunn i kravspesifikasjonen valgte gruppen a se pa følgende kriterier i kartleggingen overteknologi og utstyr:

10 Kapittel 2. Kartlegging

• Tekniske egenskaper Er utstyret kraftig nok til a løse oppgavene etter problemstillingen?

• Kostnad Oppdragsgiver er en start-up bedrift med begrenseet øknomiske midler og dettelegger føringer pa prisen til utstyret.

• Tilgjenglighet Prosjektet er pa en kort periode pa 6 mander, og det ma taes hensyn til atutstyr ma være pa plass før utviklingsfasen av prossessen.

• Oppdragsgiver Oppdragsgiver kom med ønske om Single-Board Computer og henvistevidere til Raspberry Pi som arbeidsmodell. Dette blir vurdert opp mot annen teknologi.

• Forhandskunnskap om teknologien Hvis gruppen har forhandskunnskap om teknologienvil det bli en ryddigere og mer effektiv utviklingsprosess.

2.5.2 Single Board Computer (SBC)

En Single-Board computer er en pc bygd pa et singelt kretskort, og inneholder funksjonnelle kom-ponenter som mikroprosessor, I/O, minne og andre nødvendige egenskaper. Antallet kretskort,strømkretser og koblinger er redusert i SBC, dette gjør SBC rimeligere i pris, plassbesparende, oglett i vekt. Sett pa bakgrunn av prosjektets krav ville en tradisjonell datamaskin vært sløsende ipris, kraft og størrelse. Alle SBC-ene gruppen har sett pa bruker ARM arkitektur.[1]

2.5.3 Tynn klient

Tynn klient er en en terminal-løsning hvor fler sma terminal maskiner (se figur 2.1) et kobletopp mot en felles tjener (server) via et lokalt nettverk. Tynnklienetene er typisk plassert pa hverarbeidsstasjon og har tilkoblingsmuligheter for skjerm, mus tastatur etc. Klienten fungerer somet mellomledd mellom brukerne og den sentrale maskinen og derfor kjøres ikke programmer ogaplikasjoner pa klienten men i en egen instans pa den sentrale maskinen. [2]

Figur 2.1: Eksempel pa tynn klient terminal maskinvare. Aleutia E3. 1

2.5. Teknologi og utstyr 11

2.5.4 ARM arkitektur

ARM arkitektur er en prosessorarkitektur er utviklet av ARM holdings som gir ut lisenser til pro-dusenter som bruker deres teknologi. Det som kjennetegner prosessorer med ARM arkitektur erat de har lavt strømforbruk. Prossessorer med ARM arkitektur er blandt annet mye brukt i mobi-le enheter, spillkonsoller og single board computers som eksempelvis RasberryPi og ODROID-N2. Prosessorer med ARM arkitektur støtter et bredt spekter av bade integrerte og sanntids-opperativsystemer. Deriblant en rekke 32bits linux distribusjoner.[3]

2.5.5 Raspberry Pi

Raspberry Pi er en single-board datamaskin fra Raspberry Pi Foundation pa størrelse med etkredittkort. Den første modellen ble lansert den 29 Februar 2012. [4] Maskinen brukes gjernetil a lære seg programmering eller til elektroniske smaprosjekter. Den kan ogsa gjøre mer kraf-tige arbeidsoppgaver som en vanlig datamaskin, slik som surfing pa internett, regneark og spillespill.[5]

Raspberry Pi 3 Model B

Raspberry Pi 3 Model B (se figur 2.2) er Raspberry Pi Foundation sin tredje generasjon av maski-nen. Maskinen er utstyrt med fire USB innganger, en composite video port og HDMI utgang. Denkan ogsa skryte pa seg en Quad Core 1.2GHz Broadcom 64-bit CPU sammen med 1GB RAMmed bade bluetooth og WiFi. For lagring bruker den som de tidligere modellene et Micro SD kortsom ma kjøpes separat. Pa dette kortet vil man ha operativsystemet den lille maskinen skal bruke.Hele maskinen bruker en helt vanlig Micro USB inngang til strømforsyning. Prisen ligger pa ca400 kroner.

Figur 2.2: Raspberry Pi 3 Model B 2

2.5.6 ODROID N2

ODROID-N2 (se figur 2.3) er en single-board computer som er utviklet av hardkernel. Hardkernelhar et spekter av enheter med ulike bruksomrader og komponenter. Modellen N2 ble lansert 2019.Den har en firekjernet prosessor med ARM arkitektur bestaende av ARM Cortex-A73 og en tokjer-net Cortex-A53 cluster og Mali-G52 grafikkprosessor. Kapasiteten er pa 1.8Ghz pa A73 kjernene.Den har 4GB RAM. Maskinen har flere grensesnitt for inn og utdata. De som er relevante for

12 Kapittel 2. Kartlegging

vart prosjekt fire usb 3.0 porter, en micro USB 2.0, kortspor for micro SD kort, ethernet port oghdmi2.0 utgang. ODROID-N2 støtter android pi og linux opperativsystemer. [6] Prisen ligger paca 700kr.

Figur 2.3: ODROID-N2 3

2.5.7 NanoPi-A64

NanoPi-A64 er en single-board datamaskin med høy ytelse designet av FriendlyElec. Den kanminne litt om tidligere nevnte Raspberry Pi, men med flere av funksjonene strippet bort for a badespare plass og kutte kostnadene. Maskinen har like mye RAM som tidligere nevnte, nemlig 1GB.Den har ogsa en 64-bit Quad-core 1.152Ghz Cortex-A53 CPU. Den har ogsa bade WiFi og enmini-HDMI utgang. [7]

Figur 2.4: NanoPi-A64 4

2.6. Programmeringssprak og annen teknologi 13

Maskin Pris Bilde inngang USB CPU WifiRaspberry Pi 400kr HDMI 4 stk Broadcom 64-bit Quad Core 1.2GHz JaOdroid 700kr HDMI 4 stk Cortex-A73 Quad Core 1.8GHz NeiNanoPi 200kr mini-HDMI 2 stk Cortex-A53 64-bit Quad-core 1.152GHz Ja

2.6 Programmeringssprak og annen teknologi

2.6.1 HTML

HTML (HyperText Markup Language) er et markeringssprak som brukes til a strukturere oppinnhold pa nettsider. HTML er standardisert av W3C (www consortium)[8]

Figur 2.5: Html 5 logo5

2.6.2 CSS

CSS (Cascading Stylesheets) brukes til a stilere HTML dokumenter. CSS er standardisert av W3C(www consortium).[9]

2.6.3 JavaScript

JavaScript er et intrepretert programmeringssprak med mulighet for objektorientering. Spraketbrukes sammen med HTML og CSS for a utvikle nettsteder med funksjonalitet.[10]

2.6.4 jQuery

jQuery er et JavaScript bibliotek som har et mangfold av egenskaper. Det gjør blant annet ting sommanipulasjon av HTML og animasjoner mye enklere a utføre. Som JavaScript fungerer dette overet mangfold av nettlesere.[11]

Figur 2.6: jQuery logo 6

2.6.5 PHP

PHP: Hypertext Preprocessor, eller bare PHP som det kalles, er et open-source alt mulig program-meringssprak som er spesielt brukt i webutvikling og kan ogsa brukes direkte i HTML kode.[12]

14 Kapittel 2. Kartlegging

Figur 2.7: PHP logo 7

2.6.6 C

C er et høy- til mellomniva sprak.[13] Programmeringssprakets standardbiblioteker og syntax ersenest standardisert i ISO/IEC 9899:2018.[14] C er pa grun av dets portabilitet og kompabilitetmed mange operativsystemer og kompilatorer godt egnet for alt fra sma datamaskiner til storesupermaskiner.[15]

2.6.7 C++

C++ er et høyniva programmeringssprak med mulighet for lavniva minne behandling. Spraket erobjektorientert og syntaksen er bygget pa programmeringsspraket C sin syntaks. C++ er Standar-disert av ISO og den siste standarden er ISO/IEC 14882:2017.[16]

2.6.8 Java

Java er bade et objektorientert programmeringssprak og en databehandlingsplatform først utgitt avSun Microsystems i 1995.[17] Det er gratis a laste ned og et av verdens mest populære sprak ogover femten milliardere enheter kjører Java i dag.[18]

Figur 2.8: Java logo 8

2.6.9 Python

Python er et kraftig objektorientert programmeringssprak. Spraket er veldig attraktivt for de somhar lyst til a drive med hurtigere utviklingsprosesser ettersom spraket har en enkel syntax og erenkelt a lære seg. Python støtter og oppfordrer til en modulær arbeidsstruktur. [19]

Figur 2.9: Ruby logo 9

2.7. Lagring 15

2.6.10 Ruby

Ruby er et dynamisk, open-source programmeringsprak som støtter objektorientert, funksjonellog imperativ programmering. Ruby er laget med tanke pa a ha en av de mest lesbare syntaksene.Det støtter automatisk minne handtering.[20]

Figur 2.10: Ruby logo 10

2.6.11 Ajax

Ajax er ikke et sprak eller et verktøy, men et konsept som beskriver en tilnærming til a bruke eksis-terende teknologier sammen. Ajax star for Asynchronous JavaScript + XML og inkluderer HTMLeller XHTML, Cascading Style Sheets, JavaScript, Document Object Model, XML, XSLT, og vik-tigst XMLHttpRequest objekt. Ajax benyttes til a øke hastigheten og responstid fordi postback ereliminert.[21]

2.6.12 Cookies

Cookies, eller informasjonskapsler, er data som sendes fra en server til brukernes nettleser. Nett-leseren kan lagre cookies og sende det tilbake med neste forespørsel til samme server. Cookiesbrukes primært til sesjonshandtering, personalisering og sporing.[22]

2.7 Lagring

2.7.1 CSV

CSV (comma separated values) er et filformat som brukes ved lagring av data i tekstfiler. Datalagres i en struktur som kan sammenlignes med rader og kolonner ved bruk av skilletegn og linje-skift. CSV brukes ofte til a overføre data mellom forskjellige programmer siden filformatet erkompatibelt med mange forskjellige programmeringssprak.[23] Eksemplel pa CSV struktur:

Navn , a l d e r , a d r e s s eNavnesen , 2 9 , v e i g a t a

2.7.2 JSON

Json (JavaScript Object Notation) er et tekstfilformat som kan brukes til a utveksle og lagre data.Formatet JSON kan sammenlignes med en assosiativ array ved at tekst lagres i navn-verdi parmellom krøllparanteser.[24] Eksempel pa JSON struktur:

{navn : navnesen , a l d e r : 2 9 , a d r e s s e : v e i g a t a }

16 Kapittel 2. Kartlegging

2.7.3 Cassandra

Apache Cassandra database er et distribuert, wide column store database system. Det er beregnetpa a lagre og handtere store mengder data. Cassandra er desentralisert. En wide column storedatabase kan sammenlignes med en flerdimensjonal key-value store database som bestar av raderog kolonner hvor navnet og formatet pa kolonnene kan variere fra rad til rad.[25]

2.7.4 CouchDB

Apache CouchDB er et dokumentorientert noSQL database arkitektur.[26] Data lagres i dokumen-ter med JSON struktur og har et intuitivt API basert pa JSON og HTTP. Databasearkitekturen eroptimalisert for lagring og behandling av store datamengder ved hjelp av replikering og distribue-ring av data i cluster [5].

2.7.5 Hive

Apache Hive er et rammeverk skrevet i Java som er bygget pa toppen av Apache Hadoop. Hadooper det originale rammeverket bygget for a handtere og analysere store datamengder. Hive gir etSQL-lignende grensesnitt for a spørre etter dataen som er lagret. Hive var originalt utviklet avFacebook til Apache tok over utviklingen. 11

2.8 Kommunikasjonsprotokoller

2.8.1 HTTP

HTTP er en distribuert applikasjonskontroll som kjører pa toppen av TCP/IP protokollen og dannergrunnlaget for kommunikasjon pa World Wide Web. HTTP star for Hypertext Transfer Protocol ogsiden 2015 har HTTP/2 vært standarden med HTTP/3 som foreslatt etterfølger. Tim Berners-Leestartet utviklingen av HTTP ved CERN i 1989. [27]

2.8.2 HTTPS

HTTPS er som sin navnebror HTTP, men at den bruker Transport Layer Security(TLS) for a ha ensikrere kommunikasjon for brukeren. Dette stopper blant annet ”man-in-the-middle”angrep, somer nar kommunikasjonen blir snappet opp og endret underveis til brukeren. 12

11https://en.wikipedia.org/wiki/ApacheH ive12https://en.wikipedia.org/wiki/HTTPS

Kapittel 3

Design

Dette kapittelet tar for seg hvorfor gruppen har tatt valgene om hvilken teknologi som skal an-vendes i systemet. Valgene som blir gjort i dette kapittlet er utgangspunkt for implementeringen ikapittel 4.

3.1 Systemoversikt

Hele systemet i figur 3.1 er delt opp i tre komponenter med kassesystem eksportering som enseparat del. De tre komponentene er “Interaktiv bordskjerm”, “Database” og “Kontrollpanel”.

Pa “Interaktiv bordskjerm” komponenten vil gjesten være bruker. Det er her bestillinger skjer,samt endring i status om gjesten trenger assistanse fra en servitør. Gjesten kan se og gjøre endringertil sin bestilling. Gjesten kan bare endre sin bordstatus, som vil si at de trykker pa en knapp fora tilkalle servitøren for assistanse. Oppdatering fra databasen vil kunne stenge av bordet for brukfra kontrollpanelet og oppdatere menyen ut i fra endringer som gjøres pa dette i kontrollpanelet.Gjestens bestilling og eventuelle endringer i bordstatus vil oppdateres til databasen.

I kontrollpanelet vil servitør/kokk kunne se bestillinger, samt endre pa statusen til hvert bord.Sjef eller restaurantansvarlig vil her ha muligheten til a fjernstyre bordene ved a endre om det skalvære mulig a bestille fra bordene bord for bord. Her er ogsa muligheten for a legge til, fjerne ogendre retter pa restaurantens meny.

Kassasystem komponenten er hvor muligheten for a eksportere bestillinger ut i JSON formatsom i fremtiden kan implementeres av kassesystemer for a fa bestillinger direkte inn i deres sys-temer.

3.2 Bruksmønstre

3.2.1 Beskrivelse

Her presenteres tre eksempler pa sentral funksjonalitet i form av bruksmønstre. Bruksmønstreneer direkte knyttet til hvert sitt punkt i kravspesifikasjonen.

3.2.2 Hensikt

Bruksmønstre skal illustrere konkrete mal som en bruker ønske a oppna, og forklare hvordanmalene stegvis blir oppadd i systemet. De belyser ogsa hvordan systemet reagerer under vanlighendelsesflyt og under variasjoner i bruken.

17

18 Kapittel 3. Design

Figur 3.1: Systemoversikt

3.2.3 Som en restaurant ønsker jeg a legge til matrett

Dette bruksmønsteret (se figur 3.2) er basert pa punkt 2.2.6 i kravspesifikasjonen.

Aktør: Restaurant.

Trigger: En restaurant ønsker a legge inn ny matrett pa menyen

Pre-betingelse: En ansatt pa restauranten ma ha tilgang til restaurantens kontrollpanel medmenyoversikt.

Post-betingelse

• Min: Restauranten legger til ny matrett og databasen lagrer matretten.

3.2. Bruksmønstre 19

Figur 3.2: Bruksmønster - Restaurant

• Max: Restauranten legger til ny matrett, databasen lagrer matretten, og systemet viser denoppdaterte menyen til kunder med en gang.

Normal hendelsesflyt:

1. En ansatt gar inn pa restaurantens kontrollpanel over menyoversikt.

2. Den ansatte trykker pa legg til matrett knappen.

3. Den ansatte fyller inn navn pa retten, pris, og allergen liste.

4. Den ansatte trykker pa godkjenne knappen og retten lagres.

5. Databasen viser den oppdaterte menyen til kunder med en gang.

Variasjoner:

1. Restauranten far ikke brukt kontrollpanelet.

(a) Restauranten far tilbakemelding om feilen i systemet.

2. Restauranten legger til feil informasjonen om matretten.

(a) Restauranten kan bruke endre knappen.

(b) Restauranten kan bruke slette knappen.

3. Databasen er nede eller fungerer ikke optimalt.

(a) Informasjonen blir ikke lagret i databasen.

(b) Informasjonen blir lagret, men menyen kundene ser blir ikke oppdatert.

(c) Restauranten kan forsøke pa nytt.

20 Kapittel 3. Design

Figur 3.3: Bruksmønster - Bruker sender bestilling

3.2.4 Som en bruker sender jeg ferdig bestilling til database

Dette bruksmønsteret er basert pa punkt 2.2.2 i kravspesifikasjonen.

Aktør: Gjest.

Trigger: En gjest ønsker a sende inn sin bestilling

Pre-betingelse: Gjesten ma ha valgt noe som skal bestilles

Post-betingelse

• Min: Gjesten sender inn sin bestilling fra systemet.

• Max: Gjesten sender inn sin bestilling fra systemet og far tilbakemelding at bestillingen ermotatt av databasen.

Normal hendelsesflyt:

1. En gjest trykker pa knappen for a sende inn bestillingen

2. Bestillingen valideres

3. Bestilling sendes til databasen

4. Bestilling mottas av database

5. Databasen sier ifra til systemet at bestillingen er mottatt

6. Systemet viser til brukeren at bestillingen er mottatt

3.2. Bruksmønstre 21

Variasjoner:

1. Validering av bestilling feiler

(a) Feilmelding sendes til hovedsystem

(b) Feilmelding vises hos gjest

2. Databasen mottar ikke bestillingen fra systemet

(a) Feilmelding sendes til hovedsystem

(b) Feilmelding vises hos gjest

3.2.5 Som en servitør endrer jeg bordstatus

Dette bruksmønsteret (se figur 3.4) er basert pa punkt 2.2.5 i kravspesifikasjonen.

Figur 3.4: Bruksmønster - Bordstatus

Aktør: Servitør

Trigger: Servitør tykker pa knapp for endring av bordstats.

Pre-betingelse:

1. Kunde har trykket pa knapp for a tilkalle hjelp

2. Bordet har fatt status hjelp ønsket.

Post-betingelse:

1. Bordstatus er endret til 0/Hjelp ikke tilkalt.

2. Knappen for tilkall servitør aktiveres hos kunde slik at de igjen kan tilkalle hjelp.

22 Kapittel 3. Design

Normal hendelsesflyt: Servitøren trykker pa knappen for bordstatus slik at statusen settes tilba-ke til 0/ønsker ikke hjelp.

Variasjoner:

1. Kontakt med database er brutt og bordstatus blir ikke oppdatert.

(a) Send feilmelding til brukergrensesnitt

3.3 Sekvensdiagrammer

3.3.1 Beskrivelse

I denne seksjonen finnes tre sekvensdiagrammer som relaterer til de tre bruksmønstrene alleredepresentert.

3.3.2 Hensikt

Sekvensdiagrammene skal fa frem flyten i systemet og hvordan de ulike delene snakker sammen.Videre, skal de belyse hvordan rekkefølgen pa flyten er. Sekvensdiagrammene setter fokuset painteraksjonen mellom objektene.

3.3.3 Restaurant legger til matrett

3.3.4 Bruker sender ferdig bestilling til database

3.3.5 Servitør endrer bordstatus

3.4 Valg av hardware

3.4.1 Single-Board computer eller tynnklient

Single-Board computer vs Tynnklient

Gruppen av valgt a bruke en single-board datamaskin pa grunnlag av at dette vil være løsningensom vil være lettest a implementere for a vise frem prototypen i form av at det krever veldig liteoppsett utenom a innstalere et operativsystem pa den lille datamaskinen. Denne løsningen viserseg ogsa a bli en billigere løsning pa prototypen for oppdragsgiver. Tynnklientløsningen vil ikke ginoen store fordeler i en prototype, men vil bringe med ulempen om ukjent territorium for gruppenog en høyere pris.

Valg av SBC

Gruppen har valgt a bruke Raspberry Pi. Dette valget har vi tatt pa grunn av kostnad, tilgjen-gelighet og oppdragsgivers ønske. Kostnaden faller et sted midt i mellom de tre alternativene vihar sett pa, men den har ogsa alt vi trenger uten a matte kutte bort noe. Den har ogsa en full-størrelse HDMI inngang som forenkler ting. Maskinen er ogsa lett tilgjengelig bade pa høgskolenfor utlan, men ogsa i butikker om det skulle være nødvendig a fa tak i noen pa kort tid. Det varogsa oppdragsgivers ønske om at denne maskinen skulle tas i bruk om ingen bedre valg kunnerettferdiggjøres pa grunnlag av funksjoner som er nødvendig.

3.5. Valg av programvare 23

Figur 3.5: Sekvensdiagram - Legg til matrett

3.5 Valg av programvare

3.5.1 Programmeringsprak og annen teknologi

Pre-Prototype

Gruppen hadde kort tid med 23 dager fra forespørsel til det grafiske websnittet skulle testes og eva-lueres pa kunder. Dette innebar at programmeringspraket var noe gruppen matte ha forhandskunnskapom. Gruppen valgte a ga for HTML, JavaScript og CSS, da alle pa gruppen har hatt erfaring meddisse sprakene fra fagene webutvikling og innføring i programmering. Forøvrig, ble PHP og AJAXbrukt til a handtere kommuniaksjon mellom bordet og servitørview. Gruppen sa pa a bruke cookiestil a differensiere mellom bordene pa restauranten, men da oppgragsgiver ombestemte seg og valg-te a plassere alle kundene pa et bord, var dette overflødig.

Main prototype

Gruppen valgte a bruke Python som programmeringsprak da dette er et sprak som er kraftig, mensamtidig har en ukomplisert syntax. I tillegg hadde to av gruppens tre medlemmer forhandskunnskapom Python, noe som gjorde det enklere enn om alle gruppemedlemmene skulle lært seg et nyttsprak.

24 Kapittel 3. Design

Figur 3.6: Sekvensdiagram - Bruker sender bestilling

3.5.2 Lagring

Pre-prototype

I utviklingen av pre-prototypen valgte vi a lagre data i fil ved bruk av CSV struktur. Dette valgetble gjort pa bakgrunn av at vi hadde begrenset tid og at vi derfor ønsket a lage en enkel løsningmed teknologi vi allerede kjenner godt til. Mengden data som skulle lagres var ogsa liten dapre-prototypen ble utviklet spesielt til en brukertest pa restaurant. Systemet skulle testes med firenettbrett som kundene skulle bestille mat og tilkalle servitør pa og et nettbrett som servitørenkunne se innkommende bestillinger og om noen hadde tilkalt hjelp pa. Med dette hadde vi barefire bestillinger og bordstatus som skulle lagres og behandles. Da vi sa at dette var lett løselig medlagring i fil valgte vi a ga for denne løsningen.

3.5. Valg av programvare 25

Figur 3.7: Sekvensdiagram - Endre bordstatus

Main prototype

3.5.3 Kommunikasjonsprotokoller

Pre-prototype

I pre-prototypen har vi valgt a gjøre det enklest mulig med bruk av HTTP over den sikrere HTTPS.Dette valget gjorde vi pa grunnlag av tidsrammen som var satt for ferdigstilling av pre-prototype.Av sikkerhetsmessige arsaker hadde vi valgt a bruke HTTPS

Hoved prototype

Kapittel 4

Implementasjon

I dette kapittlet presenteres implementasjonen av pre-prototypen og Main prototypen, og funksjo-naliteten og den tiltenkte virkematen.

4.1 Pre-prototype

Introduksjon til pre-prototype.

4.1.1 Servitørvisning

Servitørvisning er den delen av systemet som vises for servitøren. Koden i waiterview.js bestar avsyv funksjoner beskrevet under. Funksjonen til servitørvisning er a vise alle bestillinger som harkommet inn fra kunder samt om et bord har trykket pa en knapp for a fa assistanse fra en servitør.

bootup()

Dette er en oppstartsfunksjon som kjøres nar siden lastes. Denne funksjonen kaller funksjoneneopenorderfile og openstatusfile pa interval pa ti sekunder.{ f u n c t i o n boo tup ( ) {

s e t I n t e r v a l ( o p e n o r d e r f i l e , 1 0 0 0 0 )s e t I n t e r v a l ( o p e n s t a t u s f i l e , 1 0 0 0 0 )

}}

openorderfile()

Denne funksjonen henter først inn dagens dato. Sa sendes en xmlhttp-forespørsel. Nar denneforespørselen er klar kalles funksjonen fetchorders som henter og behandler respons-teksten tilforespørselen til fila bestilling.dat. Variabelen med dagens dato brukes til a legge pa en unik en-ding pa filnavnet slik at ikke nettleseren leser en cachet fil.{ f u n c t i o n o p e n o r d e r f i l e ( ) {

/ / t h i s v a r i a b l e ( day ) i s i m p o r t a n t t o a v o i d c a c h i n g of t e x t f i l e i n browswerv a r day = new Date ( ) ;x m l h t t p = new XMLHttpRequest ( ) ;x m l h t t p . o n r e a d y s t a t e c h a n g e = f e t c h o r d e r s ;x m l h t t p . open ( ”GET” , ” b e s t i l l i n g . d a t ? d=”+ day , t r u e ) ;x m l h t t p . send ( ) ;

}}

27

28 Kapittel 4. Implementasjon

fetchorders()

Denne funksjonen leser inn og behandler respons teksten fra http-forespørselen. Den første if tes-ten sjekker om readystate har kode 4 og status 200 som betyr at forespørselen er vellykket. Dersomdette stemmer leses responsteksten inn og lagres i variabelen data. Sa splittes data variabelen vedny linje symbolet og lagres i variabelen orders. Variabelen output skal holde pa den ferdige listaover bestillinger. HTML elementet orderlist settes til tomt. Dette er slik at alle bestillinger skallastes inn pa nytt hver gang koden kjøres. Dette Ble gjort med tanke pa at bestillinger kan fjernesmen det ble ikke tatt i bruk i pre-prototypen. En løkke gar igjennom alle ordre pa order lista ogsplitter ved skilletegnet “,” for a dele inn bestillingen i de forskjellige rettene som er bestilt. Rette-ne lagres i variabelen orderitems. Videre lages et uordnet listeelement (HTML) som skal liste oppalle ordre. I denne lista er hver noe et nytt listeelement som skal inneholde alle rettene i orderen.Denne lista blir fylt med retter i en løkke som gar igjennom orderitems lista og legger disse til sombarnnoder.

{ f u n c t i o n f e t c h o r d e r s ( ) {i f ( x m l h t t p . r e a d y S t a t e === 4 && x m l h t t p . s t a t u s === 200){

/ / f e t c h e s r e s p o n s e T e x t from x m l h t t p r e q u e s tv a r d a t a = x m l h t t p . r e s p o n s e T e x t ;/ / s e p a r a t i n g o r d e r s byv a r o r d e r s = d a t a . s p l i t ( ”\ n ” ) ;v a r o u t p u t = ” ” ;document . ge tE lemen tById ( ” o r d e r s l i s t ” ) . innerHTML = ” ” ;v a r o r d e r s o u t = document . ge tE lemen tById ( ” o r d e r s l i s t ” ) ;/ / l o o p i n g t h r o u g h o r d e r sf o r ( v a r i =0 ; i<o r d e r s . l e n g t h ; i ++){

v a r o r d e r n r = i + 1 ;v a r o r d e r i t e m s = o r d e r s [ i ] . s p l i t ( ” , ” ) ;/ / c r e a t e l i s t o f i t e m s wi th o rde rnumberv a r u l = document . c r e a t e E l e m e n t ( ” u l ” ) ;

u l . appendCh i ld ( document . c r e a t e T e x t N o d e ( ” O r d r e n r ” + o r d e r n r ) ) ;v a r u l i d = ” u l ” + o r d e r n r ;

u l . s e t A t t r i b u t e ( ” i d ” , u l i d ) ;o r d e r s o u t . appendCh i ld ( u l ) ;

f o r ( v a r j =0 ; j<o r d e r i t e m s . l e n g t h ; j ++){v a r i t em = o r d e r i t e m s [ j ] ;v a r l i = document . c r e a t e E l e m e n t ( ” l i ” ) ;l i . appendCh i ld ( document . c r e a t e T e x t N o d e ( i t em ) ) ;v a r u l p a r e n t = document . ge tE lemen tById ( u l i d ) ;u l p a r e n t . appendCh i ld ( l i ) ;

}}

}}}

openstatusfiles()

Denne funksjonen apner bordstatusfila for a se om et bord har bett om assistanse fra servitør. Dettegjøres ved a først hente inn dagens dato og kjøre en xmlhttp-forespørsel til fila summonwaiter.dathvor dagens dato brukes som parameter for a forhindre at nettlesesen henter inn en cachet fil. Pastatusendring kalles funksjonen checkstatus()

{ f u n c t i o n o p e n s t a t u s f i l e ( ) {/ / t h i s v a r i a b l e ( day ) i s i m p o r t a n t t o a v o i d c a c h i n g of t e x t f i l e i n browswerv a r day = new Date ( ) ;

4.1. Pre-prototype 29

x h t = new XMLHttpRequest ( ) ;x h t . o n r e a d y s t a t e c h a n g e = c h e c k s t a t u s ;x h t . open ( ”GET” , ” summonwaiter . d a t ? d=”+ day , t r u e ) ;x h t . send ( ) ;

}}

checkstatus()

Denne funksjonen sjekker først at forespørselen har fatt korrekt respons før den henter inn respon-steksten. I dette tilfellet er det en boolsk verdi som enten er teksten “true” eller “false”. Videresjekker den om responsen er teksten true. Dersom teksten er true settes HTML feltet tablestatus tila vise teksten “De trenger assistanse pa bord nr1” og HTMLelementet done settes til synlig (detteer en knapp servitøren kan klikke pa nar vedkommende er ferdig med a behandle forespørselen frakundene).

{ f u n c t i o n c h e c k s t a t u s ( ) {i f ( x h t . r e a d y S t a t e === 4 && x h t . s t a t u s === 200){

/ / f e t c h e s r e s p o n s e T e x t from x m l h t t p r e q u e s tv a r d a t a = x h t . r e s p o n s e T e x t ;i f ( d a t a == ” t r u e ” ){

document . ge tE lemen tById ( ” t a b l e s t a t u s ” ) . innerHTML = ”De t r e n g e r a s s i s t a n s e p bord nr1 ” ;document . ge tE lemen tById ( ” done ” ) . s e t A t t r i b u t e ( ” s t y l e ” , ” v i s i b i l i t y : v i s i b l e ” ) ;

}}

}}

resetstatus()

Denne funksjonen kalles nar en servitør klikker pa knappen done for a markere at bordet har fatthjelp. Den overskriver fila summonwaiter.dat ved hjelp av php scriptet summonwaiter.php. Ogkaller xmlhttpstatechange

{ f u n c t i o n r e s e t s t a t u s ( ) {/ / r e s e t s t h e s t a t u s t o f a l s e / no h e l p neededv a r u r l = ” summonwaiter . php ? b s t a t u s = f a l s e ” ;xmht = new XMLHttpRequest ( ) ;xmht . o n r e a d y s t a t e c h a n g e = x m h t s t a t e c h a n g e ;xmht . open ( ”GET” , u r l , t r u e ) ;xmht . send ( ) ;

}}

xmlhttpstatechange()

Denne funksjonen endrer teksten i HTML elementet tablestatus og sjuler HTML elementet done.

{ f u n c t i o n x m h t s t a t e c h a n g e ( ) {

i f ( xmht . r e a d y S t a t e === 4 && xmht . s t a t u s === 200){/ / i f c o n n e c t i o n s u c c e e d e d change html msgdocument . ge tE lemen tById ( ” t a b l e s t a t u s ” ) . innerHTML =” Ingen h a r b e d t om a s s i s t a n s e ” ;document . ge tE lemen tById ( ” done ” ) . s e t A t t r i b u t e ( ” s t y l e ” , ” v i s i b i l i t y : h i dde n ” ) ;

}}}

30 Kapittel 4. Implementasjon

4.1.2 Kundevisning

4.2 Systemutvidelser

Introduksjon til utvidelsene som er gjort

4.2.1 Kontrollpanel

Her har vi delt opp i tre...

Meny oppsett

Lage meny...

Fjernstyring av bord

Sikkerhet bra...

4.2.2 Beskyttelse

Passord...

4.3 Hoved prototype

4.3.1 Skisse Main prototype(Inkludert sikkerhetsbeskyttelse)

Introduksjon til Main prototype.

4.3.2 Bord/hardware

4.3.3 Kontrollpanel restaurant

Forklare hensikten med kontrollpanelet.

Bestilling

Meny oppsett

4.3.4 Sikkerhetsbeskyttelse

Forklare hensikten med sikkerhetsbeskyttelse.

Kontrollpanelet

Kapittel 5

Testing

Introduksjon

5.1 Hensikt

Hensikten med testene er for a sikre applikasjonen mot angrep og stenge smutthull. Dette er noesom ofte ikke kommer opp under vanlig utviklingstesting og en helhetlig testing av systemet vilsynliggjøre forbedringspotensialer i sikkerhet og applikasjonens grenser. Testene gjøres ogsa for asikre at kvaliteten pa prototypen lever opp til kravene satt i kravspesifikasjonen

5.2 Testlokasjoner

5.2.1 Pre-prototype

5.2.2 Main prototype

5.3 Utstyr

5.3.1 Pre-prototype

Utstyr brukt under utviklingen av pre-prototypen:

• Webhost

• Datamaskin

Utstyr brukt under brukertesting utført av TidBit:

• Webhost

• Datamaskin

• 4 stk. Nettbrett

31

32 Kapittel 5. Testing

5.3.2 Main prototype

5.4 Funksjonstesting

5.5 Stresstesting

5.6 Laste ned oppdateringer til systemet

5.7 Sikkerhetstesting

5.7.1 Injections

5.7.2 Avlytting

Kapittel 6

Diskusjon

33

Kapittel 7

Konklusjon

35

Kapittel 8

Videre utvikling

37

Bibliografi

[1] “Single-board computer,” Mar. 2019. Hentet fra:https://en.wikipedia.org/w/index.php?title=Single-board computer&oldid=887816055Dato hentet: 20.03.2019 Page Version ID: 887816055.

[2] “tynn klient,” Feb. 2018. Hentet fra: http://snl.no/tynn klient Dato hentet: 15.03.2019.

[3] “ARM architecture,” Feb. 2019. Hentet fra: Page Version ID: 885146549.

[4] “Raspberry Pi,” Mar. 2019. Hentet fra: https://en.wikipedia.org/w/index.php?title=Raspberry Pi&oldid=887687839Dato hentet: 20.03.2019 Page Version ID: 887687839.

[5] “1.2. Why CouchDB? — Apache CouchDB R© 2.3 Documentation.” Hentet fra:http://docs.couchdb.org/en/stable/intro/why.html, Hentet 20.03.2019.

[6] “ODROID-N2 – ODROID.” Hentet fra: https://www.hardkernel.com/blog-2/odroid-n2/ Hen-tet dato: 29.03.19.

[7] “Feature for NanoPi-A64the Feature for the NanoPi-A64 Board, CoreWind Technology.”Hentet fra: http://www.nanopi.org/NanoPi-A64 Feature.html Dato hentet: 20.03.19.

[8] “HTML5 is a W3c Recommendation | W3c News.” Hentet fra: htt-ps://www.w3.org/blog/news/archives/4167 Dato hentet: 20.03.2019.

[9] “Cascading Style Sheets.” Hentet fra: https://www.w3.org/Style/CSS/Overview.en.htmlHentet dato: 20.03.2019.

[10] D. Flanagan, JavaScript: The Definitive Guide. ”O’Reilly Media, Inc.”, Aug. 2006. Google-Books-ID: k0CbAgAAQBAJ.

[11] J. F. js.foundation, “jQuery.” Hentet fra: https://jquery.com/ Dato hentet:20.03.2019.

[12] “PHP: What is PHP? - Manual.” Hentet fra: http://php.net/manual/en/intro-whatis.php Datohentet: 20.03.2019.

[13] “C (programmeringssprak),” Aug. 2018. Hentet fra: htt-ps://no.wikipedia.org/w/index.php?title=C (programmeringsspr%C3%A5k)&oldid=18758315Hentet dato: 20.03.2019 Page Version ID: 18758315.

[14] “The Standard - C.” Hentet fra: http://www.iso-9899.info/wiki/The Standard Dato hentet:20.03.2019.

38

BIBLIOGRAFI 39

[15] D. M. Ritchie, “Chistory.” Hentet fra: https://wayback.archive-it.org/all/20150203070752/http://cm.bell-labs.com/cm/cs/who/dmr/chist.html Dato hentet:20.03.2019.

[16] “C++,” Mar. 2019. Hentet fra: https://en.wikipedia.org/w/index.php?title=C%2B%2B&oldid=888442259Hentet dato:20.03.2019 Page Version ID: 888442259.

[17] “What is Java and why do I need it?.” Hentet fra: htt-ps://www.java.com/en/download/faq/whatis java.xml Dato hentet: 20.03.2019.

[18] “Java Resources for Students, Hobbyists and More | go.Java | Oracle.” Hentet fra:https://go.java/index.html?intcmp=gojava-banner-java-com Dato hentet: 20.03.2019.

[19] “What is Python? Executive Summary.” Hentet fra: htt-ps://www.python.org/doc/essays/blurb/ Dato hentet: 20.03.2019.

[20] “About Ruby.” Hentet fra: https://www.ruby-lang.org/en/about/ Dato hentet:20.03.2019.

[21] “Ajax.” Hentet fra: https://developer.mozilla.org/en-US/docs/Web/Guide/AJAX Hentet dato:20.03.2019.

[22] D. M. Kristol, “HTTP Cookies: Standards, Privacy, and Politics,” arXiv:cs/0105018,May 2001. Hentet fra: http://arxiv.org/abs/cs/0105018 Dato hentet: 20.03.2019 arXiv:cs/0105018.

[23] Y. Shafranovich <ietf@shaftek.org>, “Common Format and MIME Type for Comma-Separated Values (CSV) Files.” Hentet fra: https://tools.ietf.org/html/rfc4180 Dato hentet:20.03.2019.

[24] “JSON.” Hentet fra: https://www.json.org/ Dato hentet: 20.03.19.

[25] “Apache Cassandra.” Hentet fra:http://cassandra.apache.org/ Hentet dato: 20.03.2019.

[26] “CouchDB,” Aug. 2018. Hentet fra: https://no.wikipedia.org/w/index.php?title=CouchDB&oldid=18763896Dato hentet: 15.03.2019 Page Version ID: 18763896.

[27] P. J. Leach, T. Berners-Lee, J. C. Mogul, L. Masinter, R. T. Fielding, and J. Gettys, “HypertextTransfer Protocol – HTTP/1.1.” Hentet fra: https://tools.ietf.org/html/rfc2616 Dato hentet:20.03.19.