Lokasjons- og kontekstbaserte tjenester - Department of Computer ...
Lokasjons- og kontekstbaserte tjenester - Department of Computer ... Lokasjons- og kontekstbaserte tjenester - Department of Computer ...
4 PROTOTYPING 57 Figur 14: Fumble : Lokasjon. – Type: For enklere ˚a kunne gruppere og søke i tilgjengelig informasjon har Fumble adoptert type-begrepet fra Gazetteers. Dette gjør at det er enkelt ˚a finne alle tjenester som er knyttet til en type, og man trenger derfor ikke søke igjennom all informasjonen[16] for ˚a f˚a fram spesifikk informasjon. Funksjonen gjør det mulig ˚a opprette en ny type som øyeblikkelig blir tilgjengelig for ny informasjon (se punktet under). Fumble implementerer kun et niv˚a med typer, da dette viser hvordan en slik oppdeling er med p˚a ˚a gruppere informasjonen. Gazetteers deler opp i flere niv˚aer av typer, der første niv˚a gir et bredt søk, mens niv˚a lengre ned gir et smalt søk. – Legg til informasjon: Dette er den viktigste administrative funksjonen i informasjonsdelen. Ved ˚a fylle ut feltene under “Add information” knyttes informasjonen som blir lagt inn til den lokasjonen som er oppgitt. N˚ar en bruker befinner seg p˚a angitt lokasjon, vil informasjonen være tilgjengelig for brukeren (se punktet under). For ˚a legge inn informasjon, m˚a brukeren avgjøre om denne er av en type som allerede eksisterer, eller om det m˚a opprettes en ny type for denne tjenesten (se punktet over). Det viktigste steget i denne funksjonen er ˚a avgjøre p˚a hvilket niv˚a tjenesten skal være: Skal den alltid være tilgjengelig (global)? Eller skal den kun være tilgjengelig i et bestemt rom? Et feil valg her kan føre til at informasjon ikke kommer opp, eller kommer opp selv om brukeren ikke har nytte av den ut i fra gjeldene lokasjon. Det m˚a ogs˚a knyttes et navn til informasjonen, som skal beskrive hva slags omr˚ade informasjonen er ment ˚a dekke og hva slags type informasjon det er snakk om. Dette er tatt med for ˚a forenkle gjenfinningsarbeidet n˚ar informasjon eksisterer i systemet. Et siste punkt som m˚a være med er “Alternative description”. Informasjon kan ikke eksistere i systemet uten en alternativ beskrivelse. Grunnen til dette er at hvis det ikke
58 4 PROTOTYPING knyttes en URL til informasjonen, er det denne beskrivelsen som dukker opp i systemet. Her er det mulig˚a skrive inn flere linjer med informasjon (ved ˚a trykke enter i feltet), og for ˚a kunne legge inn dekkende beskrivelser. URL, som er det siste feltet, er et valgfritt felt. Hvis det eksisterer en webside for informasjonen eller tjenesten, kan denne legges inn her, hvis ikke s˚a kan den være blank. Hvis den er blank er det bare den alternative beskrivelsen som inneholder en beskrivelse av informasjonen. Knyttes det derimot en webside til informasjonen, kan brukeren enkelt klikke seg fram til denne (se punktet under). Denne koblingen til eksterne websider er viktig for at et slikt system skal integreres enkelt med eksisterende systemer. Det argumenteres for en slik kobling i [8]. – Tilgjengelig informasjon: Dette er den viktigste brukerfunksjonen i informasjonsdelen, og det er denne funksjonen en bruker ville ha hatt tilgang til i et ferdig system. Mesteparten av metodene beskrevet her er implementert for ˚a gjøre denne funksjonen tilgjengelig. Denne funksjonen gjør Fumble i stand til ˚a presentere hva som befinner seg “her”. Dette er alts˚a hovedfunksjonen i et kontekstavhengig system. Det ble valgt en tre-visning (tree view) som grunnlag for presentasjonen, fordi dette er foresl˚att som den beste m˚aten ˚a vise hierarkisk data p˚a i .NET. I tre-visningen finner vi igjen de samme niv˚aene som vi kjenner fra lokasjonsdelen, med unntak av “Campus” og lokasjonsnavnet. Grunnen til dette er at lokasjonsdelen antar at det er “Gløshaugen” det er snakk om som campus uansett, og informasjonsdelen opererer med relasjoner p˚a romniv˚a, ikke innad i rommene. Begge disse forskjellene ville ikke eksistert i et ferdig system. Funksjonen f˚ar lokasjon fra lokasjonsdelen av programmet, og benytter dette til ˚a avgjøre hva som skal presenteres som tilgjengelig informasjon. Global informasjon eller globale tjenester blir undersøkt først, det vil i praksis si at prototypen sjekker om det finnes noen relasjoner til “Campus”-niv˚aet. Dette blir gjennomført uansett, alts˚a uavhengig av om lokasjon er tilgjengelig eller ikke (avsnitt 6.4). S˚a sjekkes hvert niv˚a for relasjoner, først bygning, s˚a etasje og til slutt rom. Relasjoner som oppfyller kravet til posisjon blir hentet fra databasen og presentert i en tre visning (Tree view) som vist i Figur 15. • Nettleser: Siden det ble valgt ˚a presentere informasjon vha. websider og integrere Fumble mot andre webbaserte system, ble en nettleser implementert. Alternativt ville ha vært ˚a la gjeldende nettleser 26 p˚a klienten starte for ˚a presentere informasjonen\tjenestene. Ulempen ville da være at det kunne bli mange ˚apne nettlesere, og brukeren bli oversvømt av informasjon. Fordelen er at brukeren kan bruke den nettleseren de vanligvis bruker. Ved ˚a integrere en nettleser har programmet full kontroll over hva som blir presentert. 26 Gjeldene nettleser vil ofte være Internet Explorer, men kan ha blitt erstattet av feks. Opera eller FireFox.
- Page 17 and 18: 6 2 STATE OF THE ART 2.1.1 Lokasjon
- Page 19 and 20: 8 2 STATE OF THE ART fastsl˚a at e
- Page 21 and 22: 10 2 STATE OF THE ART Se ogs˚a avs
- Page 23 and 24: 12 2 STATE OF THE ART 2.2.3 Metadat
- Page 25 and 26: 14 2 STATE OF THE ART graphs with p
- Page 27 and 28: 16 2 STATE OF THE ART 2.3.2 RADAR R
- Page 29 and 30: 18 2 STATE OF THE ART sisjonsavheng
- Page 31 and 32: 20 2 STATE OF THE ART det ikke fore
- Page 33 and 34: 22 2 STATE OF THE ART som befinner
- Page 35 and 36: 24 3 MITT SYSTEM 3.2 Brukere av sys
- Page 37 and 38: 26 3 MITT SYSTEM Appendix B. Bruker
- Page 39 and 40: 28 3 MITT SYSTEM Figur 4: Systemstr
- Page 41 and 42: 30 3 MITT SYSTEM stavhengig system.
- Page 43 and 44: 32 3 MITT SYSTEM Figur 6: Mulige ka
- Page 45 and 46: 34 3 MITT SYSTEM AROUND-arkitekture
- Page 47 and 48: 36 3 MITT SYSTEM I de neste punkten
- Page 49 and 50: 38 3 MITT SYSTEM logge seg inn i de
- Page 52 and 53: 4 PROTOTYPING 41 4 Prototyping P˚a
- Page 54 and 55: 4 PROTOTYPING 43 vil være unik for
- Page 56 and 57: 4 PROTOTYPING 45 Figur 12: Signalst
- Page 58 and 59: 4 PROTOTYPING 47 oppgaven og det er
- Page 60 and 61: 4 PROTOTYPING 49 en del av samme sy
- Page 62 and 63: 4 PROTOTYPING 51 4.3.1 Valgt teknol
- Page 64 and 65: 4 PROTOTYPING 53 - Navnetyper inneh
- Page 66 and 67: 4 PROTOTYPING 55 - Finn lokasjon: D
- Page 70 and 71: 4 PROTOTYPING 59 Figur 15: Fumble :
- Page 72 and 73: 4 PROTOTYPING 61 scope, slik det er
- Page 74 and 75: 4 PROTOTYPING 63 muligens fordi enk
- Page 76 and 77: 4 PROTOTYPING 65 AP ID MAC Signal N
- Page 78 and 79: 4 PROTOTYPING 67 Utover dette har i
- Page 80 and 81: 4 PROTOTYPING 69 Figur 19: Informas
- Page 82: 4 PROTOTYPING 71 4.8 Oppsummering p
- Page 85 and 86: 74 5 TESTING OG EVALUERING AV FUMBL
- Page 87 and 88: 76 5 TESTING OG EVALUERING AV FUMBL
- Page 89 and 90: 78 5 TESTING OG EVALUERING AV FUMBL
- Page 91 and 92: 80 5 TESTING OG EVALUERING AV FUMBL
- Page 93 and 94: 82 5 TESTING OG EVALUERING AV FUMBL
- Page 95 and 96: 84 5 TESTING OG EVALUERING AV FUMBL
- Page 97 and 98: 86 5 TESTING OG EVALUERING AV FUMBL
- Page 99 and 100: 88 5 TESTING OG EVALUERING AV FUMBL
- Page 101 and 102: 90 5 TESTING OG EVALUERING AV FUMBL
- Page 103 and 104: 92 5 TESTING OG EVALUERING AV FUMBL
- Page 105 and 106: 94 6 KONKLUSJON OG VIDERE ARBEID in
- Page 107 and 108: 96 6 KONKLUSJON OG VIDERE ARBEID M
- Page 110 and 111: REFERANSER 99 Referanser [1] A9. A9
- Page 112 and 113: REFERANSER 101 [22] Ole Hestnes og
- Page 114 and 115: A TERMINOLOGI 1 Appendix A Terminol
- Page 116 and 117: B KRAVSPESIFIKASJON 3 Alternative c
4 PROTOTYPING 57<br />
Figur 14: Fumble : Lokasjon.<br />
– Type: For enklere ˚a kunne gruppere <strong>og</strong> søke i tilgjengelig informasjon<br />
har Fumble adoptert type-begrepet fra Gazetteers. Dette gjør at det er<br />
enkelt ˚a finne alle <strong>tjenester</strong> som er knyttet til en type, <strong>og</strong> man trenger<br />
derfor ikke søke igjennom all informasjonen[16] for ˚a f˚a fram spesifikk<br />
informasjon. Funksjonen gjør det mulig ˚a opprette en ny type som øyeblikkelig<br />
blir tilgjengelig for ny informasjon (se punktet under). Fumble<br />
implementerer kun et niv˚a med typer, da dette viser hvordan en slik<br />
oppdeling er med p˚a ˚a gruppere informasjonen. Gazetteers deler opp i<br />
flere niv˚aer av typer, der første niv˚a gir et bredt søk, mens niv˚a lengre<br />
ned gir et smalt søk.<br />
– Legg til informasjon: Dette er den viktigste administrative funksjonen<br />
i informasjonsdelen. Ved ˚a fylle ut feltene under “Add information”<br />
knyttes informasjonen som blir lagt inn til den lokasjonen som er<br />
oppgitt. N˚ar en bruker befinner seg p˚a angitt lokasjon, vil informasjonen<br />
være tilgjengelig for brukeren (se punktet under). For ˚a legge inn<br />
informasjon, m˚a brukeren avgjøre om denne er av en type som allerede<br />
eksisterer, eller om det m˚a opprettes en ny type for denne tjenesten<br />
(se punktet over). Det viktigste steget i denne funksjonen er ˚a avgjøre<br />
p˚a hvilket niv˚a tjenesten skal være: Skal den alltid være tilgjengelig<br />
(global)? Eller skal den kun være tilgjengelig i et bestemt rom? Et feil<br />
valg her kan føre til at informasjon ikke kommer opp, eller kommer opp<br />
selv om brukeren ikke har nytte av den ut i fra gjeldene lokasjon. Det<br />
m˚a <strong>og</strong>s˚a knyttes et navn til informasjonen, som skal beskrive hva slags<br />
omr˚ade informasjonen er ment ˚a dekke <strong>og</strong> hva slags type informasjon<br />
det er snakk om. Dette er tatt med for ˚a forenkle gjenfinningsarbeidet<br />
n˚ar informasjon eksisterer i systemet. Et siste punkt som m˚a være med<br />
er “Alternative description”. Informasjon kan ikke eksistere i systemet<br />
uten en alternativ beskrivelse. Grunnen til dette er at hvis det ikke