DELLEVERANSE 1 INF2120 V06

Transkript

1 DELLEVERANSE 1 INF2120 V06 GRUPPE 22 VERSION: FINAL 22 FEBRUARY, 2006 MORTEN FOLLESTAD RAYNER VINTERVOLL ANISH RAJA IVA N. IVANOVA BJØRN BRÆNDSHØI Page 1

2 REVISJONSOVERSIKT Revisjonsoversikt Versjon Forfattere Beskrivelse Dato Utkast Alle Midlertidig utkast, distribuert for siste gjennomgang av forfatterne Fullstendig All Første fullstendige utkast, dokumentet er under versjonskontroll/håndtering Page 2

3 INNHOLD 1. INTRODUKSJON INNHOLD OG FORMÅL DOKUMENTETS OPPBYGNING INNLEDNING MED FORUTSETNINGER JEGSERDEG - ET PRIVAT OVERVÅKNINGSSYSTEM FORUTSETNINGER FLERE TJENESTER Buddylister Hotspots USE CASE MODELLER INTRODUKSJON Introduksjon til use case modell Beskrivelse av aktører USE CASE MODELLER Use case modell admin/system Use case modell bruker KLASSEDIAGRAM KLASSEDIAGRAM FORKLARINGER TIL KLASSEDIAGRAMMET COMPOSITE STRUCTURE DIAGRAMMER SEKVENSDIAGRAMMER Innledning Registrere bruker JSD_regBrukerISystem Avregistrere bruker JSD_avregBrukerFraSystem Registrere hotspot JSD_RegHotspot Invitere buddy JSD_SystemInvBuddy JSD_FinnBuddy JSD_EndreBuddyLister Vis 5 nærmeste buddy JSD_finn5nærmesteBuddies estimereavstand Vis 5 nærmeste hotspot...31 Page 3

4 6.7.1 JSD_vise5nærmesteHotSpot Søke på buddy JSD_søkepåBuddy Søke på hotspot JSD_søkePåHotspot Varslingstjeneste JSD_varsling JSD_FinnBruker...39 Page 4

5 1. INTRODUKSJON 1.1 Innhold og formål Dette dokumentet presenterer en spesifikasjon av de tjenester vi tenker implementert i systemet JegSerDeg. Formålet med dokumentet er å dokumentere de tenkte funksjonalitetene systemet skal tilby vha use cases, klassediagram, composite structure diagrammer og sekvensdiagrammer. I tillegg vil disse diagrammene inneholde tekstlige beskrivelser. Dokumentet vil også gi utviklere og kunden et grunnlag for videre drøftelser omkring systemet som skal utvikles. 1.2 Dokumentets oppbygning I første del av dokumentet presenteres en innledning og de forutsetninger som gjøres og legges til grunnlag for diagrammene som beskriver systemet. I andre del presenteres objektorientert analyse/design med et use cases, klassediagram, composite structure diagrammer og sekvensdiagrammer basert på disse. Page 5

6 2. INNLEDNING MED FORUTSETNINGER 2.1 JegSerDeg - Et privat overvåkningssystem JegSerDeg er et system som skal benytte posisjonering av person(er) via deres mobiltelefon (heretter kalt brukere). Programmet skal også kunne kommunisere direkte til brukerens mobiltelefon via SMSmeldinger. Posisjoneringen av mobiltelefonen gjøres vha en tjeneste levert av Telenor ( og vil av den grunn kun fungere med mobiltelefoner som har abonnement fra Telenor. Basaltjenesten til programmet vil være en registreringstjeneste for brukeren og en posisjoneringsrutine som jevnlig finner brukerens posisjon og skriver denne til en fil med egnet format. For å kunne vise grafisk, på en terminal, hvor brukeren (mobiltelefonen) befinner seg vil denne filen kunne integreres med Google Earth (earth.google.com). Google Earth er en gratistjeneste som tilbyr en stor samling av satellittbilder som til sammen dekker store deler av jordkloden. I tillegg kan programmet vise posisjoner på kartet gitt med lengde- og breddegrader som den leser fra en eller flere filer. Vi vil utvide basaltjenesten med flere tjenester, disse vil bli beskrevet i dette dokumentet. Tjenestene er tilgjengelige for brukeren via SMS meldinger. 2.2 Forutsetninger For at tjenesten skal fungere må brukerens mobiltelefon være tilkoblet et abonnement fra Telenor. En forutsetning for at systemet skal fungere optimalt er at posisjoneringsrutinen posisjonerer alle brukerne med et kort intervall, f. eks hvert minutt. Vi vil implementere denne funksjonaliteten, men vil i tillegg vha en egnet SMS kunne slå posisjoneringsrutinen av og på. Dette vil hjelpe oss i å kjøre testperioder ute i felten uten at vi trenger la systemet gå kontinuerlig over lang tid. Flere tjenester baserer seg på å levere koordinater, hotspots, buddies eller liknende i nærheten av brukeren. I nærheten betyr innenfor 500 meter. 2.3 Flere tjenester Buddylister Hver bruker vil kunne ha sin egen liste over andre brukere såkalte buddies. For å bygge opp buddylisten inviterer man andre brukere til sin liste. Godtar mottakeren invitasjonen blir begges buddyliste oppdatert med hverandre. Følgende tjenester er basert på buddylister : Inviter Buddy Tjenesten sender en SMS til en annen bruker og inviterer han/hun til å bli brukerens buddy. Godtar denne personen dette vil de begge bli lagt til i hverandres buddyliste. Page 6

7 Slett Buddy Tjenesten lar brukeren fjerne en buddy fra buddylisten. Vis 5 Nærmeste Buddy Tjenesten sender en SMS til brukeren med lokaliseringen og avstanden til opptil fem av de nærmeste på buddylisten. Søk Etter Buddy Tjenesten lar brukeren søke etter navnet på en buddy i listen og returnerer en SMS med lokaliseringen og avstanden til denne buddyen hvis den finnes. Varsling Tjenesten lar brukeren aktivere en varslingstjeneste som hvert 15. minutt kjører tjenesten Vis 5 Nærmeste Buddy og Vis 5 Nærmeste Hotspots automatisk Hotspots Brukeren kan lagre hotspots (koordinater) sammen med en tekstlig beskrivelse samt type. Det gjøres ved å sende en SMS når brukeren befinner seg på det stedet som han vil ha lagret som en hotspot. Hotspots kan ha tre typer : Globale Globale hotspots kan sees av alle brukere. Dette kan typisk være steder som alle kan ha interesse av å vite hvor er, som togstasjoner, taxiholdeplasser, mc donalds etc. Private Private hotspots er steder som er av interesse kun for brukeren. Eksempler på dette er hjemmet, kompisers hjem og andre private plasser. Dynamiske En dynamisk hotspot er i all hovedsak en global buddy. Eksempler på dette er en bussjåfør, pizzabud etc. Følgende tjenester er basert på hotspots : Registrer Hotspot Tjenesten lar brukeren registrere et sted som en hotspot via en SMS. Hotspoten blir lagret med lengde- og breddegrad. Vis 5 Nærmeste Hotspots Tjenesten sender en SMS til brukeren med opptil fem av de nærmeste hotspotene uavhengig av hotspotens type. Page 7

8 Søk Etter Hotspot Tjenesten lar brukeren søke etter navnet på en hotspot i listen og returnerer en SMS med lokaliseringen og avstanden til denne hotspoten hvis den finnes. Varsling Tjenesten lar brukeren aktivere en varslingstjeneste som hvert 15. minutt kjører tjenesten Vis 5 Nærmeste Buddy og Vis 5 Nærmeste Hotspots automatisk. Page 8

9 3. USE CASE MODELLER 3.1 Introduksjon Introduksjon til use case modell Vi har tre primære aktører og en sekundær i vårt use case. Disse er som følger: Primære aktører Sekundære aktører Bruker PATS Administrator Systemet Brukeren er den aktøren med mobiltelefonen som bruker de forskjellige posisjoneringstjenestene fra systemet. Brukeren er ute i felten og jobber med systemet via sin mobiltelefon. Brukeren kan også sitte ved en terminal (Google Earth). Administratoren er den aktøren som jobber med systemet direkte via en terminal. Aktøren kan vedlikeholde databasen og sende SMS til brukere direkte fra terminalen. Systemet er med som aktør fordi det kontinuerlig jobber opp mot PATS laben og SMS tjenesten. Systemet er ikke avventende, men er hele tiden aktiv. PATS laben er en sekundær aktør som leverer koordinatene til en mobiltelefon til primæraktøren System etter at System har sendt en forespørsel Beskrivelse av aktører Aktør: Bruker Primær aktør Beskrivelse: En bruker er den aktøren som benytter seg av tjenestene systemet tilbyr. Brukeren har en mobiltelefon med et Telenor abonnement og kan via SMS-meldinger abonnere på forskjellige tjenester fra systemet. I tillegg kan brukeren vha Google Earth (earth.google.com) få opp sin egen (og andres via diverse tjenester) posisjon. Eksempel: Brukeren sender en SMS til 2034 (PATS laben) hvor han registrerer seg som bruker. Deretter sender brukeren en eller flere SMS hvor han/hun abonnerer på forskjellige tjenester, f.eks buddy list som lar brukeren overvåke sine venners posisjoner. Page 9

10 Aktør: Beskrivelse: Eksempel: Aktør: Beskrivelse: Administrator Primær aktør En administrator (eller system ansvarlig) kan jobbe direkte med systemet via en terminal. Administratoren kan også se hvor alle brukerne er vha Google Earth. Administratoren kan vedlikeholde databasen til systemet, fjerne uønskede brukere eller gjøre endringer hvis brukerens SMS ikke har blitt registrert. System Primær aktør Systemet er aktivt og vil hele tiden posisjonere de brukerne som er abonnenter. Eksempel: Systemet henter (via PATS laben) koordinatene til brukerne med gitte intervall, f.eks hvert minutt. Aktør: PATS laben Sekundær aktør PATS laben ( er en tjeneste levert av Telenor. Tjenesten tilbyr posisjonering av mobiltelefoner i Norge. Posisjoneringen er basert på lengde- og breddegrader. Man sender en SMS til PATS laben og får en SMS i retur med sin posisjonering. Vårt system vil jobbe direkte med PATS (via Internett) og hente ut posisjonene til systemets brukere. Beskrivelse: Eksempel: Page 10

11 3.2 Use case modeller Use case modell admin/system Page 11

12 3.2.2 Use case modell bruker Page 12

13 4. KLASSEDIAGRAM 4.1 Klassediagram Page 13

14 4.2 Forklaringer til klassediagrammet Generelt gjelder for alle klasser at en såkalt add metode ikke vil finnes, fordi vi lar konstruktøren til klassen legge til ett nytt objekt. Klasse Beskrivelse Bruker Klassen representerer hver bruker av systemet. Inneholder blant annet posisjonen til brukeren, peker til brukerens hotspoter, peker til brukerens buddyliste samt alle tjenester som brukeren kan abonnere på. Hovedklassen i systemet. Inneholder blant annet en peker til brukerene, hotspotene og metoder for å håndtere brukerne samt å posisjonere brukere. Klassen representerer en hotspot ved en lengde- og breddegrad samt type hotspot (privat, global eller dynamisk) og en tekstlig beskrivelse av hotspoten. Klassen inneholder en liste over brukere (buddies). JegSerDeg Hotspot Buddylist Melding Klassen inneholder en melding (SMS) med mottakeren og avsenderen samt en type-variabel. InterfaceToPats Representerer interfacet mellom systemet og PATS-laben som foretar posisjoneringen av mobiltelefonene. InterfaceToTelenor Representerer interfacet mellom systemet og Telenor-tjenesten som lar systemet sende og motta SMS. Page 14

15 5. COMPOSITE STRUCTURE DIAGRAMMER Page 15

16 6. SEKVENSDIAGRAMMER 6.1 Innledning Alle sekvensdiagrammer tar utgangspunkt i et lavt detaljeringsnivå, alle tjenestene har et diagram som viser kommunikasjonen mellom brukeren (mobilklienten) og systemet. Tjenestene i diagrammene er dekomponert ned ett nivå for å få en mer detaljrik oversikt. Sekvensdiagrammene bruker asynkron meldingsflyt, dette er fordi de skal brukes senere i tilstandsmaskiner. Page 16

17 6.2 Registrere bruker Det eneste som skjer her, er at en bruker sender en melding inn til systemet, og JEG SER DEG-klassen kaller addperson(), som oppretter en ny bruker. Systemet sender kvittering tilbake til bruker om hvordan det gikk. Page 17

18 6.2.1 JSD_regBrukerISystem Page 18

19 6.3 Avregistrere bruker Bruker sender en melding til systemet, systemet sjekker om bruker finnes i systemet fra før, og hvis dette er tilfelle så slettes brukeren. Brukeren mottar en kvittering for dette. Page 19

20 6.3.1 JSD_avregBrukerFraSystem Page 20

21 6.4 Registrere hotspot Mobilklienten ønsker å registere en Hotspot i systemet. Mobilklienten mottar en kvittering fra systemet om registreringen var vellykket eller ikke. Page 21

22 6.4.1 JSD_RegHotspot JegSerDeg mottar en forespørsel om å registere en hotspot. Hvis brukeren er registert i systemet (ID OK) går sekvensen videre. JegSerDeg vet selv om de globale hotspotene, men må spørre Bruker om brukeren har en personlig hotspot som heter det samme som den som førsøkes registert. Hvis en Hotspot ved samme navn ikke finnes opprettes en Hotspot og kvittering gis. Hvis en Hotspot ved samme navn finnes gis kvittering som meddeler at registreringen mislykkes. Page 22

23 6.5 Invitere buddy Mobilklienten sender en invitasjons-sms til systemet, adressert til den personen han vil legge til i sin buddyliste. Hvis systemet finner den ønskede buddyen (som bruker) og denne personen ikke finnes i avsenders buddyliste fra før av, får mottakeren en SMS som spør om han godtar invitasjonen. Hvis mottakeren godtar invitasjonen legges begge brukerene i hverandres buddyliste og kvittering sendes til begge. Hvis mottakeren ikke godkjenner invitasjonen sendes kvittering/melding til begge. Hvis ikke mottakeren av invitasjonen svarer innen en gitt tidsfrist (for eksempel 1 måned) slettes den midlertidige meldingen/oppgaven og en negativ kvittering sendes brukeren. Page 23

24 6.5.1 JSD_SystemInvBuddy Systemet sjekker først om brukeren som sender invitasjonen er registrert i systemet. Deretter finner systemet ut om mottakeren av invitasjonen er en bruker av systemet og at han/hun ikke er buddy til brukeren allerede. Etter dette er det tre alternativer: Mottakeren godtar invitasjonen, buddylistene endres og begge mottar en kvittering pr SMS. Mottakeren nekter invitasjonen og begge mottar en kvittering pr SMS. Mottakeren svarer ikke på invitasjonen, meldingen fjernes fra systemet og kvittering sendes brukeren. Page 24

25 6.5.2 JSD_FinnBuddy Etter at systemet mottar en invitasjonsforespørsel sjekker det om mottakeren eksisterer og at han ikke er registrert som buddy til avsenderen fra før av. Er dette tilfelle sendes invitasjonen til mottakeren. I motsatt tilfelle sendes en melding til avsenderen om at invitasjonen ikke kunne vidresendes. Page 25

26 6.5.3 JSD_EndreBuddyLister Mottakeren godtar invitasjonen og systemet kan legge til brukerene i hverandres buddylister. Kvittering sendes begge. Page 26

27 6.6 Vis 5 nærmeste buddy Viser hvordan kommunikasjonen mellom en mobilklient og systemet foregår. For å vise mer detaljert hva som skjer selv i systemet blir dette dekomponert til JSD_finn5nærmesteBuddies. Mobilklienten sender forespørsel om beliggenheten av de fem nærmeste buddies og systemet finner hvor de befinner seg og returnerer den relevante informasjonen. Page 27

28 6.6.1 JSD_finn5nærmesteBuddies Viser hva som skjer inne i systemet når mobilklienten sender sin forespørsel via SMS. Det første som skjer er at JSD autentiserer bruker. Selv autentiseringen er beskrevet mer detaljert i sd JSD_FinnBruker. Hvis mobilklienten finnes i systemet da blir hele lifeline -et utført. Vi tar for gitt at JSD har posisjonen til enhver bruker til hver tid. Selv buddy må også være en registrert bruker i systemet og o så fall vet JSD dens posisjon til enhver tid. For å få takk i de fem nærmeste buddies, sender JSD melding til Bruker som henter en og en buddies fra sin BuddyList. Fortløpende blir avstanden mellom en bruker til hver buddy i sin liste estimert og de fem som befinner seg nærmest blir returnert til mobilklienten. Page 28

29 6.6.2 estimereavstand Page 29

30 6.7 Vis 5 nærmeste hotspot Viser hvordan kommunikasjonen mellom en mobilklient og systemet foregår. For å vise mer detaljert hva som skjer selv i systemet blir dette dekomponert til JSD_vise5nærmesteHotSpot. Mobilklienten sender forespørsel om beliggenheten av de fem nærmeste Hot Spots. Systemet finner hvor de befinner seg og returnerer den relevante informasjonen. Page 30

31 6.7.1 JSD_vise5nærmesteHotSpot Viser hva som skjer inne i systemet når mobilklienten sender sin forespørsel via SMS. Det første som skjer er at JSD autentiserer bruker. Selv autentiseringen er beskrevet mer detaljert i sd JSD_FinnBruker. Hvis mobilklienten finnes i systemet da blir hele lifeline -et utført. Vi tar for gitt at JSD har posisjonen til enhver bruker til hver tid. Etter at en HotSpot er registrert i systemet tar JSD vare på dens posisjon til enhver tid. For å få takk i de fem nærmeste HotSpots, sender JSD melding til Bruker som henter en og en HotSpot fra sine personlige HotSpots. Fortløpende blir avstanden mellom en bruker og hver HotSpot i sin liste estimert og de fem nærmeste HotSpots blir returnert til mobilklienten. Page 31

32 6.8 Søke på buddy Her ønsker en bruker å få vite hvor en buddy befinner seg i forhold til han. Brukeren sender da inn en melding til systemet, med navnet på buddien. Systemet sjekker da i buddylisten til den som sendte meldingen, om han faktisk kan få informasjon om den han ber om. Hvis han kan det, så estimerer sysemet avstanden mellom disse to, og sender denne avstanden tilbake til brukeren. Hvis brukeren ikke har tilgang til denne buddien, så sendes det bare en kvittering tilbake om at navnet ikke finnes i buddylisten. Page 32

33 6.8.1 JSD_søkepåBuddy Page 33

34 6.9 Søke på hotspot Her skjer det samme som når brukeren ønsker å søke på en buddy. Systemet sjekker om brukeren har tilgang til å få informasjon om den HotSpoten han søker på. Hvis han har dette, så estimerer systemet avstanden, og returnerer denne. Ellers så returneres bare en kvittering om at brukeren ikke har tilgang til HotSpoten. Page 34

35 6.9.1 JSD_søkePåHotspot Page 35

36 6.10 Varslingstjeneste Det første som skjer her, er at brukeren sender en melding om å slå på varslingstjenesten. Systemet sjekker da om brukeren finnes i systemet, slik at han har tilgang til denne tjenesten. Og sender en kvittering med Varsling PÅ. Deretter går sekvensene vise5nærmestebuddies og finn5nærmestehotspot i loop, og returnerer avstanden til alle forekomster som ligger innenfor en radius av 500m fra brukeren. Dette skjer helt til brukeren sender en melding om å slå av denne tjenesten. Systemet kvitterer da til slutt at denne tjenesten er slått av. Page 36

37 JSD_varsling Page 37

38 6.11 JSD_FinnBruker FinnBruker er en slags autentiseringssekvens. Når JegSerDeg har mottatt en forespørsel om utføring av en tjeneste vil dette innebære at en brukeridentifkator (avsender e.l.) fulgte med forespørselen. JegSerDeg vil dermed ha tilgang til denne identifikatoren for hver forespørsel som kommer inn til systemet. JegSerDeg prøver å finne brukeren i systemet og setter en continuation ID OK hvis brukeren er registrert, eller ID NOK hvis brukeren ikke er registrert. Page 38