DELLEVERANSE 2 INF2120 GRUPPE 12. Jon G. Berentsen Geir A. Nilsen Lailuma Arezo

Transkript

1 DELLEVERANSE 2 INF2120 GRUPPE 12 Av Jon G. Berentsen Geir A. Nilsen Lailuma Arezo

2 Innledning: Hensikten med vår oppgave er å lage et overvåkningssystem basert på posisjonering av mobiltelefon. Overvåkningssystemet skal posisjonere registrerte brukere når de ber om det. De slik skal kunne få informasjon om hvor en annen samtykket bruker befinner seg relativt til demselv. Kommunikasjonen mellom systemet og brukerne foregår vha sms. Som registrert bruker får publikum tilgang til en rekke tjenester. De skal kunne melde seg av og på. Registrerte brukere deles inn i buddylister, og medlemmer av en byddyliste skal kunne få informasjon om hverandre, men ikke om medlemmer av andre buddylister. Man skal også kunne posisjonere steder, såkalte hotspots. Vi er nå ferdig med designprosessen, og neste steg er implimentasjon og eventuelt noe redesign.vi kommer til å basere sluttdokumentet for leveransen på dette dokumentet. Vi har gått over til et mer tjeneste spesifikt system. Det lages tilstandsmaskiner etter hvert som tjenester blir forespurt. Disse blir så destruert når tjenesten er utført. Spesifikasjon: Brukerforutsetninger: Brukeren har mobiltelefon med telenor abonnement. Vedkommede befinner seg i Norge, og har dekning. Personen må kunne håndtere mobiltelefon og smsfunksjonen. En bruker er enten påmeldt eller avmeldt, inaktiv er en tilstand en bruker ikke kan være i. Melder man seg av mister man hele "profilen" sin i systemt. Systemforutsetninger: Systemprogrammet vårt er oppe og kjører hele tiden. Definisjon av en BuddyList: De som er i buddylisten, er de du kan få posisjonen til. Hver bruker har en buddyliste. Hvis en buddy aksepterer din buddy-request havner han i din og du i hans buddyliste. Brukere i listen er synlig for hverandre, innebærer synlighet begge veier og ikke bare en vei. Ved sletting av en buddy blir man fjernet fra hverandres buddyliste, og ikke synlig for hverandr lengre. Definisjon av en BuddyHotSpot: Når en bruker registrerer en BuddyHS vil alle i brukerens BuddyListe få et tilbud om å adoptere denne HS. HS blir da lagt til i buddyens HS liste. OBS! Når man melder seg av tjenesten må man slettes fra alle Buddylister man er medlem av. Definisjon av Dynamiske HotSpot: To registrerte brukere. Ide om at buddy og dynamiske HS er nestendet samme. En DynHS vil ikke ha en buddyliste/muligheten til å lage HS. //* Revidert spesifikasjon: Tjenesten BuddyHotSpot er fjernet. Vi har tatt hensyn til feilmeldinger. Skjer det en (kritisk) feil, f.eks at DB ikke vil r/w, så stenger vi ned alle aktive sesjoner.

3 Kml fila genereres når man benytter tjenesten posbuddies og bare da. Når man ber om en posisjonering sjekkes man opp mot sine registrerte hotspots, men ikke buddies. Vi skiller ikke mellom Dynamisk hotspot og buddy. Diagrammer i systemet: Tilstandsmaskinen UserHandler: Dette er den største og mest aktive delen av systemet. Her gjøres parsing av SMS meldingen, slik at en kan velge hva en skal gjøre videre. En SMS melding består av tjeneste og argument(ene) til tjenesten. Den tar seg også av rutingen av forespørsler fra sessjonene som har blitt behandlet i DB_hanler og skal tilbake til sesjonene. Userhandler starter ved oppstart, henter inn brukere fra databasen., om databasen er ok ligger den og lytter på sms meldinger eller db meldinger. Om det skjer noe feil avsluttes programmet.

4 DB_relasjons-design: En bruker kan være medlem i flere buddylister. Og en liste kan kun eies av en bruker. På samme måte kan en bruker ha flere hotspot, og hver hotspot kan kun tilhøre en bruker. Liste er bare et begrep for å lette forståelsen av systemet. Disse listene oppstår bare når man gjør spørringer mot db og får listen som retur. Signaler: Disse signalene trigger tilstandsmaskiner til å gå over til neste tilstand. Dbreply: sendes som svar fra DB opp til sesjoner. Har to attributter som kan brukes litt forskjellig. Dbreplylist: same som dbreply, bare at den returnerer en liste, f.eks en buddyliste. Error: den trigger feilsekvens UserPos: returnerer en brukers posisjon DbReguest: sender en forespørsel til DB Compare: brukes for å sammenlikne to koordinater Timermsg: brukes for å sende tilstandsmaskiner i finalstate dersom de har eksistert for lenge

5 Tilstandsmaskin DB_Handler: DB_Handler mottar alle kall mot databasen. Dette kan deles i tre områder: Det som har med brukerhåndtering å gjøre (adduser, removeuser), buddyhåndtering (addbuddy, removebuddy, osv) og hotspot (gethotspots osv). Brukerhåndtering: DBHandler sjekker først om brukeren eksisterer i systemet, hvis ikke lagres brukeren i systemet og det sender en sms-bekreftelse. Hvis brukeren allerede eksisterer, får han beskjed om det, og det skjer ikke noe utover det. Buddyhåndtering: Oppdaterer buddylisten som ligger i db. Hotspothåndtering: Oppdaterer en bestemt brukers hotspots.

6

7 Komposit Struktur JSD: Dette er den overornede kompositstrukturen for systemet vårt. UserHandler og DB_Handler er tilstandsmaskiner. PositionServices, BuddyServices og HotSpotServices er komposit strukturer. Hele systemet er bygd opp rundt UserHandler. Mye av kommunikasjonen går fra -Services til DB_Handler til UserHandler og tilbake til -Services. Scenario: Sms kommer inn fra en bruker. UserHandler sjekker typen tjeneste brukeren ønsker utført. Hvis det er en buddytjeneste, sendes den til BuddyServices. Hvis det er en hotspottjeneste, sendes den til HotSpotServices osv. Sms til bruker går direkte fra tjenestene.

8 Komposit Struktur BuddyServices: Buddyservices håndterer alt som har å gjøre med buddytjenesten. Alle parteneer tilstandsmaskiner. Vi har mao en tilstandsmaskin for hver tjeneste.. Controller initieres i starten og kjører hele tiden. Det lages en addbuddy og en removebuddy tilstandsmaskin for hver gang en tjeneste blir etterspurt av en bruker, og termineres etter at tjenesten har utført kommandoen.

9 Tilstandsmaskin controller: Controller initieres i starten og kjører hele tiden. Den mottar signal fra UserHandler som ber om en tjeneste. Den utfører så ett av tre mulige tjenesteroperasjoner: å registrere/slette en bruker fra en buddyliste i DB, eller bare å oversende en liste med buddies som er registrert på en brukers kontoprofil.

10 Tilstandsmaskin addbuddy: Når metoden addmybuddy blir kalt så skjer følgende: Denne operasjonen sjekker at både bruker og buddy eksisterer i DB. Bruker1 sender sms til bruker2 og spør om han vil bli buddy. Hvis han ikke mottar svar innen en viss tid, så får han beskjed om at bruker2 ikke svarer/ er det ensbetydende med at han svarer nei. Hvis han svarer ja, så registreres denne relasjonen i DB og det gis beskjed til bruker1 før den dør. På samme måte får bruker1 beskjed hvis bruker2 svarer nei.

11 Composite Structure HotSpotService: HotSpotservices håndterer alt som har å gjøre med hotspottjenesten. Alle partene er tilstandsmaskiner. Vi har igjen en tilstandsmaskin for hver tjeneste. Det lages en addhotspot og en removehotspot tilstandsmaskin for hver gang en tjeneste blir etterspurt av en bruker, som avsluttes etter at tjenesten har utført kommandoen.

12 Tilstandsmaskin HotSpotController: controller initieres i oppstarten og kjører hele tiden. Den mottar signal fra UserHandler som ber om en tjeneste. Den utfører så ett av to mulige tjenesteoperasjoner: å registrere eller å slette en hotspot fra DB.

13 Tilstandsmaskin addhotspot: DB mottar et signal om å gjøre en sjekk på bruker. Det lages en hotspot som lagres i DB med relasjon til brukeren, og det sendes bekreftelse til bruker. Hvis bruker derimot ikke eksisterer i DB, får bruker beskjed om det. addhotspot kalles med en brukerid og et navn som identifiserer posisjonen. Først så sjekkes det at brukeren er gyldig, i så fall så sendes en melding til PATS via WaitForPosUserResponse-metoden. Denne kan feile f.eks dersom PATS er nede, men normalt vil det nye hotspotet lagres via StoreTheNewHotspot. Når hotspotet blir lagret blir det sendt en melding tilbake til brukeren om dette.

14 Komposite Structure PositionServices: Controller initieres i starten og kjører hele tiden. Den mottar signal fra UserHandler som ber om en tjeneste. Avhengig av argument utføres så ett av tre mulige tjenesteoperasjoner.

15 Tilstandsmaskin PosServiceController:

16 Tilstandsmaskin nearanyhotspot: Denne tilstandsmaskinen beskriver et scenario der bruker spør systemet om å få nærmeste hotspot i forhold til hvor brukeren befinner seg. JSD sender med en liste med hotspot. nearanyhotspots mottar brukerid, gjør et oppslag via PATS for å få posisjonen, så gjør et søk i databasen for å finne nærmeste posisjoner, og så returnerer det nærmeste.

17 Tilstandsmaskin posbuddies: Gangen i systemet er som følger: PosBuddies gjør et oppslag i databasen og produserer en liste over alle vennene til den gjeldende brukeren. For hver buddy opprettes det en singlebuddy. SingleBuddy kaller posoneuser som gjør et oppslag mot PATS og rapporterer posisjonen til buddien tilbake til brukeren. Deretter legger singlebuddy posisjonen inn i databasen. Input: Output: Denne tilstandsmaskinen opprettes når brukeren spør JSD om å få en liste over hvor sine buddies er for øyeblikket. posbuddies mottar et signal fra userhandler om å foreta en sjekk på om bruker eksisterer i systemet. CreatePosSingleUserBuddies kaller posoneuser for hver bruker som gjeldende bruker har som buddies.

18 Tilstandsmaskin posoneuser:

19 Tilstandsmaskin PosAllusers: Denne tilstandsmaskinen gjør kommunikasjonen mot PATS.

20 Sekvensdiagrammer

21

22

23

24

25

26

27

28