Lokasjons- og kontekstbaserte tjenester - Department of Computer ...

4 PROTOTYPING 61
scope, slik det er implementert i denne oppgaven, inneholder kun en unik ID og et
navn, men det er ogs˚a mulig ˚a legge inn alternative attributter som en beskrivelse,
dato for opprettelse, eier osv. Dette støtter opp under forslaget i AROUND ved at
systemet skal slippe ˚a søke igjennom hele det tilgjengelige informasjonsrommet,
se avsnitt 3.5.
Oppgaven har tidligere sagt at et scope kan inneholde en eller flere tjenester. Dette
skaper en en-til-mange relasjon. Men for at en tjeneste ikke kun kan eksistere
i et scope, var det nødvendig ˚a dele opp relasjonen mellom scope og tjeneste.
Slik modellen er implementert ble det opprettet en ekstra entitet, S S (Scope
til Service), som løser opp denne mange-til-mange relasjonen i to en-til-mange
relasjoner. Se Figur 16. Tjeneste er her beskrevet som “Service”.
Et scope kan n˚a inneholde flere tjenester, og vice versa, men samme problem
oppst˚ar n˚ar et scope skal knyttes til en lokasjon: En lokasjon kan være knyttet
til flere enn et scope, og et scope kan være knyttet til flere lokasjoner. Igjen
har modellen en mange-til-mange relasjon. Denne ble delt opp i to en-til-mange
relasjoner ved ˚a innføre en entitet L S (Lokasjon til Scope), p˚a samme m˚ate som
for scope til tjenester. Forskjellen er her at lokasjon, slik definert i modellen,
kan være: campus, bygning, etasje eller rom. Entiteten L S inneholder derfor en
attributt “Coverage” som sier hvilken av disse omr˚adene som dekkes og hvilken
lokasjon (for omr˚adet “Room” hvilket rom, for omr˚adet “Floor” hvilken etasje
osv.) det er snakk om.
Figur 16: Relasjonen mellom lokasjon og informasjon i FUMBLE
Denne modellen skaper en relasjon mellom lokasjonsdata og informasjonsdata som
utnytter strukturen i lokasjonshierarkiet og som samtidig støtter b˚ade informasjon
og tjenester. For ˚a utdype dette litt s˚a er informasjonsdata knyttet til lokasjonsdata
p˚a en slik m˚ate at systemet slipper ˚a traversere lokasjonshierarkiet for ˚a finne
fram til korrekt lokasjon. M˚aten modellen støtter b˚ade informasjon og tjenester er
vha. attributten URL i entiteten Service, ved ˚a legge ut informasjonen p˚a en webside,
eller ved at informasjonen skrives inn i “Alt description”. Her bør det ta en
avgjørelse som systemet skal kunne lagre informasjon internt (i Alt description)
og via eksterne websider, eller at informasjon kun kan knyttes til systemet via
eksterne websider.