INF2120 Prosjektoppgave i modellering. Del 1

Transkript

1 INF2120 Prosjektoppgave i modellering Del 1 Håkon Ulvestad haakonu@ifi.uio.no Jonas Winje jonaw@ifi.uio.no Amaia Santacoloma amaiac@ifi.uio.no Rakel Johnsen rakelj@ifi.uio.no Våren 2006

2 Innledning Prosjektoppgaven dreier seg om å utvikle et privat overvåkningssystem som kan brukes ved hjelp av mobiltelefon og datamaskin. Basaltjenesten inkluderer å melde seg av og på tjenesten via sms, og at brukeren kan se hvor han er i verden via Google Earth på en datamaskin. Videre har vi valgt å legge vekt på sms-tjenester, selv om det godt kan tenkes at vi vil se nærmere på andre muligheter i forbindelse med Google Earth i neste del av oppgaven. Vi vil først beskrive systemets funksjonalitet på et overordnet plan ved hjelp av et use-case diagram med tilhørende beskrivelse. Videre vil vi forklare detaljene og systemets interne deler mer inngående ved hjelp av composite structure diagrammer, klassediagrammer og sekvensdiagrammer. Når det gjelder PATS og posisjonering er vi klar over at vi ikke kan posisjonere brukere for ofte og konstant, selv om tjenestene vi inkluderer kan få det til å fremstå slik. Vi forutsetter også at PATS posisjonerer nøyaktig, selv om vi vet at dette ikke er tilfelle. Dette gjelder spesielt for tjenestene som innebærer varsling om man er i nærheten av en annen bruker etc. Det er stor forskjell på om man er 100 eller 1000 meter unna kompisen sin en lørdag ute på byen, men vi velger å ikke ta eventuelle feilposisjoneringer med i betraktningen. Andre spesielle forutsetninger vil nevnes der det føles naturlig. Vi har valgt å bruke engelsk tekst i alle diagrammmer, men norsk ellers i beskrivelsene. Noe blanding må derfor påregnes.

3 Use-case diagram MobUser MobUser er brukeren av systemet. Brukeren vil stort sett kommunisere med systemet via mobiltelefon, men for å benytte enkelte tjenester vil brukeren også benytte en datamaskin. Sign up as member Brukeren melder seg på tjenesten ved å sende en sms til Denne meldingen inneholder blant annet ønsket brukernavn. Dersom mobilnummeret allerede er registrert i systemet eller ønsket brukernavn er opptatt vil brukeren få en sms om dette tilbake. Tilsvarende vil han få en sms med bekreftelse dersom registreringen går i orden. Add person to buddy list Når brukeren har meldt seg på tjenesten kan han lage en buddylist. For å legge til en person i buddylisten sender han en melding til 2034 med buddyens mobilnummer. Dersom buddyen ikke er registrert som bruker av systemet vil han motta en sms med en invitasjon til å registrere seg. Dersom han er registrert bruker vil han få beskjed om hvem som har lagt han til som buddy. All videre funksjonalitet som omfatter buddyer forutsetter at buddyen også har lagt brukeren til som sin buddy, slik at buddyforholdet er gjensidig. Brukeren vil få en bekreftelse på sms hvis buddyforholdet blir gjensidig. Det følger naturlig at funksjonaliteten vil utvides slik at man også kan fjerne en buddy fra sin buddylist.

4 Add hotspot Brukeren kan lagre spesielle steder som hotspots. Dette gjøres ved å sende en melding til 2034, hvor navnet på hotspoten samt eventuelle koordinater oppgis. Dersom koordinater ikke oppgis vil systemet sette koordinatene, og dermed hotspoten, til det stedet brukeren befinner seg når han sender meldingen. Brukeren vil få en bekreftelse på sms om at hotspoten er lagret dersom ikke navnet på hotspoten eller koordinatene er lagret fra før. I så fall vil han få beskjed om dette. Det følger naturlig at funksjonaliteten vil utvides slik at man også kan fjerne hotspots. Add dynamic hotspot En dynamisk hotspot er en blanding av en buddy og en vanlig hotspot, altså en ting som beveger seg. Dette kan for eksempel være buss, trikk, danskebåten, romskip eller lignende. Vi vet lite om hvordan disse identifiserer og posisjonerer seg, men vi går ut i fra at de er tilknyttet noe som tilsvarer et mobiltelefonnummer. For å lagre en dynamisk hotspot sender brukeren en melding til 2034 med navnet til den dynamiske hotspoten samt identifikator for denne. Også her følger det naturlig at dynamiske hotspots skal kunne fjernes. Warn if close to buddy or hotspot Dersom brukeren ønsker å varsles hver gang han er i nærheten av en buddy eller en statisk/dynamisk hotspot sender han en melding til 2034 og ber om dette. Brukeren, buddyer og hotspots vil da posisjoneres jevnlig, og systemet vil sende brukeren en sms for hver buddy eller hotspot han er i nærheten av. Hvilken avstand som skal tilsvare "i nærheten" har vi ikke avgjort enda, men det vil nok dreie seg om meter. Funksjonen kan tenkes utvides til at brukeren selv spesifiserer denne verdien, og at han kan velge å varsles kun om han er i nærheten av dynamiske hotspots (utelate buddyer og statiske hotspots, og omvendt), eller spesifiserte buddies/hotspots. Stop warn Dersom brukeren vil skru av varslingen må han sende en sms hvor han gir beskjed om dette. Bekreftelse vil gis på sms, eventuelt en feilmelding om varslingsfunskjonen ikke var aktivert i utgangspunktet. Find distance to buddy or hotspot Brukeren kan finne ut hvor langt unna og i hvilken himmelretning en buddy eller hotspot befinner seg ved å sende en sms med navnet til buddyen eller hotspoten til 2034 og be om dette. Svaret gis via sms, og brukeren kan foreløpig ikke sende mer enn en forespørsel per sms. Position with Google Earth Brukeren kan be om å få se sin posisjon i verden via Google Earth ved å sende en sms med ønske om dette til Posisjoneringssystemet vil generere en fil som sier noe om posisjoneringen, og brukeren må sette Google Earth til å lese denne fila. I første omgang er det jo vi som er utviklere av systemet som er brukere, og denne fila kan lagres lokalt på datamaskinen(e) som kjører systemet. Etter hvert bør det genereres en unik url for hver fil tilknyttet en bruker, slik at man kan bruke tjenesten på hvilken datamaskin som helst. Da vil brukeren få en sms i retur hvor denne url en er spesifisert. Sign off service Brukeren kan melde seg av tjenesten og slette sine opplysninger ved å sende en sms til Bekreftelse på vellykket sletting gis via sms, det samme med eventuelle feilmeldinger (hvis mobilnummeret for eksempel aldri er registrert).

5 Klassediagram Positioning System er beskrevet i 3 ulike nivåer. På det høyeste nivået er den i kontakt med både PATS laben og GoogleEarth. På neste nivå har systemet en Controller enhet som består av tre andre enheter: - UserController administrerer det som har med brukerne å gjøre. - BuddyController holder rede på brukeren sine buddies. - HotspotController tar vare på dynamiske og statiske hotspots. På siste nivå har vi brukerne, buddies og hotspots: MobUser er klassen som definerer brukerne. Disse blir identifisert gjennom navn og telefonnummer. I tillegg har de ett atributt for x og y koordinatene. Buddy klassen har en peker til en bruker, siden hver buddy må være registrert i systemet som bruker også. Hotspotsene vil bli behandlet som statiske eller dynamiske. Forskjellen ligger på atributtet phonenr. Dersom denne er null, vil den bli behandlet som statisk, siden enhver dynamisk hotspot krever bruk av en mobiltelefon. Statiske hotspots har da faste koordinater, mens dynamiske hotspots sine koordinater blir skrevet om. En hotspot blir identifisert gjennom navn og evt koordinatene.

6 Composite Structure diagram System (nivå I) Viser hvilke deler i hele systemet (ikke bare delen vi lager) som kommuniserer med hvilke. Brukeren, MobUser, sender og mottar meldinger fra PositioningSystem, og kan bruke Google Earth for å sjekke posisjonen sin. PositioningSystem bruker PATS for å posisjonere brukere, og skriver filer "til" (som leses av) Google Earth. PositioningSystem (nivå II) Controller har kontakt med delene utenfor PositioningSystem, og de andre Controller-klassene. Controller delegerer oppgaver videre til MobUser-, Buddy- og HotSpotController.

7 Sekvensdiagrammer sd SignUp MobUser (brukeren) sender en melding til PositioningSystem for å melde seg på tjenesten. Dersom registreringen går i orden får brukeren bekreftelse på dette via sms. Dersom telefonnummeret allerede er registrert får han beskjed om dette via sms. Dersom brukernavnet er opptatt får han beskjed om dette via sms. sd PS_SignUp Controller ber MobUserController om å opprette en ny bruker. MobUserController bekrefter eller gir feilmelding.

8 Sd SignOff MobUser (brukeren) sender en melding til PositioningSystem for å melde seg av tjenesten. Dersom registreringen går i orden får brukeren bekreftelse på dette via sms. Dersom telefonnummeret ikke er registrert som medlem brukeren beskjed om dette via sms. Sd PS_SignOff Controller ber MobUserController om å slette en bruker. MobUserController bekrefter eller gir feilmelding.

9 sd AddBuddy MobUser legger til en person i buddylisten ved å sende en melding til PositioningSystem med buddyens mobilnummer. Dersom Buddyen er registrert bruker og har lagt til MobUser som sin buddy vil han få beskjed om hvem som har lagt han til som buddy. MobUser vil få bekreftelse på sms om at buddyen er lagt til. Dersom Buddyen er registrert bruker men ikke har MobUser som buddy, vil han få beskjed om hvem som har lagt han til som buddy. MobUser vil få beksjed på sms om at buddyforholdet ikke er gjensidig. Dersom buddyen ikke er registrert som bruker av systemet (PotentialUser) vil han motta en sms med en invitasjon til å registrere seg. MobUser vil motta en sms med beskjed om at PotentialUser har blitt invitert.

10 sd PS_AddBuddy Controller sjekker med MobUserController om brukeren er registrert. Dersom brukeren er registrert sjekker Controller med BuddyController om det eksisterer et forhold mellom MobUser og Buddyen fra før. Hvis dette finnes fullføres forholdet til et gjensidig buddyforhold. Hvis ikke settes buddyen på hold til han eventuelt legger til MobUser som sin buddy.

11 sd AddHotSpot Brukeren sender sms til posisjoneringssystemet og ber om å få lagt til en hotspot. Dersom brukeren inkluderer koordinater, vil hotspot bli lagt til med disse. Hvis koordinater ikke inkluderes vil posisjoneringssystemet be PATS om å posisjonere brukeren og hotspot vil bli lagt til med disse koordinatene. sd PS_AddHotSpot Controller mottar meldingen fra brukeren og ber HotSpotController opprette en ny hotspot HotSpotController sjekker med PATS hvor bruker befinner seg hvis brukeren ikke har angitt koordinater i meldingen, oppretter en ny HotSpot og sender denne tilbake til Controller. Controller ber MobUserController legge til denne HotSpoten for denne brukeren.

12 sd AddDynamicHotSpot Brukeren sender sms til Posisjoneringssystemet med telefonnummer til et dynamisk hotspot og får bekreftelse eller feilmelding tilbake. sd PS_AddDynamicHotSpot Controller mottar meldingen fra brukeren og ber HotSpotController lage en ny dynamisk HotSpot. HotSpotController sender hotspot eller feilmelding tilbake til controller. Controller ber deretter MobUserController om å legge til denne hotspoten for brukeren. Tilbakemelding sendes til bruker.

13 sd CloseToBuddyOrHotspot Brukeren sender melding om at han/hun vil advares hvis hun er innenfor rekkevidde av buddies eller hotspots. Systemet vil da gjevnlig posisjonere brukeren og søke igjennom (posisjonere om nødvendig) posisjonene til buddies og hotspots for å sjekke om avstanden fra brukeren til denne er mindre enn en gitt radius. Brukeren vil få en sms per buddy/hotspot som er innen rekkevidde.

14 sd PS_CloseToBuddyOrHotspot Brukeren ber systemet varsle dersom den nærmer seg en buddy eller en hotspot. Controlleren mottar meldingen, som videresender meldingen til UserController. Denne ber PATS om koordinatene til brukeren, som blir stadig oppdatert og sendt til UserController, som sender dem tilbake til Controlleren. Controlleren gir også beskjed til BuddyController om å be PATS om koordinatene til brukerens buddier. Controlleren mottar koordinatene til buddiene også. Dersom koordinatene til brukeren og en av buddiene er nærmere en viss avstand, får brukeren en varsling om det. Stort sett det samme gjelder for hotspotsene. Controlleren gir beskjed til HotspotController om å be PATS om koordinatene til hotspotsene. Dersom det dreier seg om dynamiske hotspot ber HotSpotController PATS om å spore disse. Koordinatene til hotspotsene blir sendt til Controller, som igjen sammenligner dem med brukeren sine koordinater og eventuelt varsler brukeren hvis den nærmer seg en hotspot.

15 sd StopWarn Brukeren sender melding om at han/hun ikke lenger vil ha advarsel om buddies/hotspots er innen rekkevidde og mottar bekreftelse eller feilmelding. sd PS_StopWarn Brukeren ber systemet slutte å varsle om nærme buddies eller hotspots. Systemet mottar meldingen i Controller, som sender med mobilnummeret til UserController og ber om å avslutte loopen. Dersom varsling ikke var aktivert får brukeren beskjed om det, ellers får den bekreftelse på at varsling nå er av.

16 sd DistanceTo Brukeren sender sms til posisjoneringssystemet og ber om å få vite hvor en buddy/hotspot befinner seg i forhold til seg selv. Systemet vil da be PATS om å posisjonere brukeren. Hvis det dreier seg om en buddy vil så systemet be PATS om å posisjonere denne og. For hotspots trengs posisjonering kun hvis det dreier seg om dynamiske hotspots. Brukeren vil så få tilbakemelding med koordinatene og himmelretningen (i forhold til brukeren) til buddy/hotspot.

17 sd GoogleEarthPositioning Hvis brukeren ønsker å se posisjoneringen i systemet i GoogleEarth, må han/hun sende en sms til posisjoneringssystemet som ber PATS spore brukeren. Systemet vil så skrive en fil som GoogleEarth kan lese og returnere denne til brukeren på sms. Brukeren kan så be GoogleEarth om å lese denne filen (fra serveren hvor posisjoneringssystemet kjører) som så vil vise posisjoneringen eller gi feilmelding.