INF2120. Gruppe 14. Innlevering 1. Våren Joakim Bjørnstad

Transkript

1 JegSerDeg INF2120 Gruppe 14 Innlevering 1. Våren 2006 Joakim Bjørnstad Jon Andreas Lind Tollefsen Abdirahman Hassan Barre

2 Innledning og forutsetninger JegSerDeg er et program som kommuniserer med brukere via SMS og hjelper til å posisjonere dem gjennom PATS og Google Earth. Modellen Utgangspunktet er Basaltjenesten. Videre har vi valgt å utvide basaltjenesten med flere avanserte funksjoner som: Hotspots og buddylister med sine underordnede funksjoner. En forutsetning er at registrering skjer i henhold til Basaltjenesten. Slik at ingen to forskjellige brukere med like brukernavn finnes. (Ifi brukernavnet benyttes) Buddylisten forutsetter at buddyer som blir lagt til er registrerte brukere og har også samtykket til at de er buddyes av vedkommende. Slik at de villig og ikke uvitende kan bli posisjonert. Vi har forutsatt at det er bare PATS som sender og mottar SMS. Slik at JegSerDeg bare utøver funksjonene og prater med PATS men ikke med mobilbruker. Kommunikasjon skjer kun mellom PATS og mobilbruker, Google Earth er ikke med. Gruppen Gruppen er vel strukturert og organisert, med leder, kontaktperson og dokumentansvarlig. Gruppen har stort sett fungert bra, alle aktive fra begynnelse til første milepæl. Med unntak av en som sluttet kurset i startfasen. Videre har vi hatt endel problemer med både RSM og Eclipse, som vi har sendt mails om. Men det har ordnet seg til slutt, selv om det tok endel tid.

3 UseCases Dette er use case diagrammet. Det viser hvilke funksjoner mobilbruker har tilgang til. Her er tanken at Hotspot og Buddy er overordnede funksjoner som inkluderer en funksjon kalt Autentikasjon som da sjekker om mobilbrukeren er registrert i databasen. For å bruke Hotspot og Buddy funksjonene må man da være en registrert bruker.

4 Meld på : Melder en ny bruker på JegSerDeg. Meld av: Melder en eksisterende bruker av JegSerDeg. Autentikasjon: Gjør et databasesjekk på om en mobilbruker er registrert i databasen fra før av. Hvis mobilbrukeren ikke er en registrert bruker så gis det feilmelding i form av en SMS. Hotspot Registrer hotspot: Lar brukeren få registrere et personlig hotspot. Det kan tenkes han/hun vil lagre huset sitt, favorittutestedet sitt, bestemors hus osv. i en egen hotspot liste slik at han/hun kan få vite avstand til det på GoogleEarth eller på SMS. Gi registrerte hotspots: Brukeren får en liste over alle sine personlige hotspots. Når brukeren da etterhvert har registrert mange hotspot er det da mulig å få ut en liste over disse via f.eks SMS. Abonner på hotspot: Brukeren får en jevnlig oppdatering på avstand til et utvalgt registrert hotspot. Stopp abonnent: Brukeren avslutter abonnent på hotspot. Fjern hotspot: Lar brukeren få fjernet et personlig hotspot. Buddy Registrer buddy: Lar brukeren legge til en annen registrert bruker i sin buddyliste som har samtykket til dette. Fjern buddy: Lar brukeren få fjernet en buddy fra sin buddyliste. Gi buddyliste: Gir brukeren en liste over alle sine buddyes. Få buddy info: Gir brukeren informasjon om avstand til en buddy.

5 Klassediagrammer Dette er klassediagrammet for oversikten over systemet. Det er 6 klasser totalt. Systemet holder rede på mobilbrukere, Databasen og kontrollerne. Systemet kommuniserer og med PATS. Databasen inneholder mange forskjellige tabeller som holder rede på brukere, posisjoner, buddyer og hotspots. JegSerDeg_Kontroller mater Databasekontrolleren med informasjon som skal tas inn, ut og sjekkes opp mot Databasen.

6 Dette Klassediagrammet viser mere om Hotspots. JegSerDeg_Kontroller er igjen bindeleddet mellom Database og en annen kontroller. I dette tilfellet Hotspot_Kontroller. Som igjen holder rede på mange hotspots. Hotspot_Kontroller har også funksjonene som er gitt i usecase diagrammet.

7 Dette Klassediagrammet viser tilsvarende som forrige. JegSerDeg_Kontrollerne holder rede på en Buddy_Kontroller som holder rede på mange Buddyes. Men her er i tillegg en Autentiser klasse som går under Autentikasjon av brukeren.

8 Composite Structure JegSerDeg I composite structure diagrammet er det 6 parts. mobilbruker kommuniserer kun med PATS igjennom portene mb og pats. Siden sms går enten fra PATS til mobilbruker og omvendt. PATS kommuniserer kun med JegSerDeg_Kontroller. JegSerDeg_Kontroller prater i tillegg med Buddy_Kontroller og Databasekontroller. Databasekontroller kommuniserer med Database. Kommunikasjonen kan gå begge veier gjennom de aktuelle portene. I tillegg har JegSerDeg to formelle porter som ikke er avbildet. Input og output mellom PATS.

9 Sekvensdiagrammer Følgende seksvensdiagrammer er med: meldpaa > jsd_meldpaa meldav Autentikasjon > jsd_autentikasjon sjekkposisjon hotspot reghotspot > jsd_reghotspot fjernhotspot gireghotspots abonnerhotspot stoppabonnement > jsd_stoppabonnement buddy registrerbuddy > jsd_registrerbuddy fjernbuddy faabuddyinfo gibuddyliste > jsd_gibuddyliste Forklaring på diagrammene står under hvert diagram.

10 meldpaa melder en ny bruker på JegSerDeg. I meldpaa sendes en SMS med IFI brukernavn til PATS. Som finner den statiske IDen, den blir sendt videre med brukernavn og id til JegSerDeg. JegSerDeg gjør en insert med brukernavn og id til Database. Tilbakemeldingen sier om det ble vellykket eller ikke. Hvis insert ny bruker i Database gikk bra, sendes en SMS med bekreftelse til mobilbruker. Hvis ikke, sendes en feilmelding. Dette er rammet inn i en Combined Fragment, alt. Her er det en ref til jsd_meldpaa i JegSerDeg lifelinen (neste side).

11 jsd_meldpaa viser hva som skjer inne i JegSerDeg lifelinen i et underliggende nivå. Her er det JegSerDeg_Kontroller som sender melding til Database_kontroller at brukernavn og id skal legges til Database. Deretter blir brukernavn og id forsøkt lagt til i Database. En tilbakemelding fra Database kommer til Database_kontroller som sender en tilbakemelding til JegSerDeg_Kontroller. Her er det en CF, alt med gates ok eller feil som sender meldinger om bekreftelse eller feil ut av jsd_meldpaa.

12 Autentikasjon sjekker om et brukernavn er i databasen, slik at vedkommende har tilgang til alle funksjonene. I starten sender mobilbruker en sms med sitt brukernavn og hvilken tjeneste man vil benytte. Deretter gis en melding til JegSerDeg med brukernavnet, iden og tjenesten. En melding fra JegSerDeg går så til Database som gjør et oppslag på brukernavn, for så å sende tilbakemelding. Deretter er det en CF opt hvis tilbakemelding fra Database var negativ så vil feilmelding bli sendt til mobilbruker at man må registrere seg. Hvis tilbakemelding fra Database var positiv så skjer ingenting

13 Dette sekvensdiagrammet beskriver hva som skjer en bruker autentiserer seg. Det kommer inn en melding fra PATS serveren som inneholder et brukernavn, id og en ønsket tjeneste. Tjenesten og autentikasjonen kommer samtidig siden man må være en registrert bruker for å kunne bruke tjeneste som JegSerDeg tilbyr. De forskjellige kontrollerene snakker sammen, og finner ut om brukeren er lagt til i databasen. Sender så en retur/tilbakemelding til PATS, om brukeren har lov til å utføre sin forespurte tjeneste.

14 meldav melder en registrert bruker av JegSerDeg systemet. For å sjekke om brukeren er en registrert bruker, så ligger det en ref Autentikasjon oppå alle lifelines. Etter positivt svar fra Autentikasjon så blir det gjort forsøk på å fjerne brukernavnet fra databasen. En bekreftelse kommer til mobilbruker hvis alt gikk bra, hvis fjern gikk galt av en eller annen grunn gis det feilmelding.

15 I sjekkposisjon er det en klokke som har en lifeline som starter når tiden nå er større enn våknetiden. Den får JegSerDeg til å våkne, gir posisjonen til PATS som returnerer en ny posisjon. Så skjer en av to ting. Enten har klokka timet ut, da får JegSerDeg posisjonen, gir den videre til PATS som oppdater posisjonen i forhold til hotspottet. Til slutt sendes en sms med avstand til hotspot. Ellers har mobilbruker flyttet på seg, og gammel posisjon gis, ny posisjon oppdateres og avstand blir sendt som sms.

16 Overblikk over hotspot tjenestene, med referanser.

17 reghotspot registrerer et nytt personlig hotspot for en mobilbruker. Hvis Autentikasjon gir grønt lys så legges hotspotet til Database. Videre gis det tilbakemelding om det gikk bra. Det sendes melding om det gikk ok eller om det ble feil til slutt tilbake til mobilbruker.

18 Formålet med dette sekvensdiagrammet er å vise hvordan en hotspot blir opprettet. Det som er spesielt her er at vi først sjekker om hotspotet finnes fra før ellers, lager vi et nytt hotspot objekt, ved gjøre en new. Deretter er det database kontrolleren sitt ansvar å inserte dette objektet inn i databasen. Alt ettersom det går eller ikke vil det bli sendt tilbake en passende retur til PATS serveren. Objektet dør når inserten er gjort.

19 fjernhotspot fjerner et personlig hotspot til en registrert mobilbruker. Dette verifiseres ved hjelp av ref Autentikasjon. finnhotspot(sted) sjekker om hotspottet som blir bedt fjernet er i Database. Tilbakemelding til JegSerDeg sier om det finnes eller ikke finnes et slikt hotspot. Hvis det fantes så blir det fjernet med en gang, og en bekreftelse SMS blir sendt til mobilbruker. Hvis ikke det fantes blir en SMS feilmelding sendt.

20 gireghotspots gir en liste over alle personlige hotspots til en bruker på forespørsel. Hvis Autentikasjon gikk greit så sendes det en forespørsel til Database om den kan gireghotspots. Så kommer en loop som gir ett og ett hotspot til JegSerDeg hvor det da blir puttet i en enkel tekstliste. Deretter sendes hele listen tilbake til PATS som sender listen som SMS til mobilbruker.

21 abonnerhotspot gjør at en bruker kan abonnere på et (eller flere) personlige hotspot. Etter godkjent Autentikasjon sjekkes om hotspottet finnes. Posisjonen blir returnert til JegSerDeg. Så looper sjekkposisjon helt til det bes om at tjenesten avsluttes (neste). Ellers kommer det feilmelding.

22 stoppabonnement avslutter et eksisterende abonnement på et hotspot. Etter autentikasjon sendes det meldinger om det gikk bra eller dårlig. Det som skjer inne i JegSerDeg kommer på neste side (jsd_stoppabonnement)

23 Bruker må autentisere seg. Det sjekkes så om bruker og hotspot fantes fra før. Database kontrolleren fjerner hotspotet, og en retur blir sendt helt tilbake til PATS.

24 Oversikt over buddy tjenestene, med referanser.

25 sd registrerbuddy registrerer en buddy til mobilbrukerens buddylisten. Etter godkjent autentikasjon skal finnesbuddy sjekke om buddyen finnes i databasen. Hvis buddyen finnes i basen, sendes det et feil tilbakemelding til mobilbrukeren. Hvis buddyen finnes ikke buddylisten skal leggtilbuddy legge buddyen i databasen og de skal sendes OK tilbakemelding til mobilbrukeren.

26 Dette sekvensdiagrammet tilsvarer det som omhandler å legge til en hotspot. Den eneste forskjellen er at vi her lager et Buddy objekt som blir puttet inn i databasen. Objektet terminerer også her.

27 sd fjernbuddy skal fjerne en buddy i mobilbrukerens buddyliste. Hvis autentikasjonen går greit skal finn sjekke buddyen finnes i Database. Hvis buddyen finnes i database skal det sendes en tilbakemelding til JegSerDeg som fjerner buddyen i databasen. Mobilbrukeren får enten en ok SMS tilbakemelding hvis buddy sletting går greit eller en feil SMS tilbakemelding hvis buddyen finnes ikke i basen.

28 sd faabuddyinfo skal gi informasjon om hvor buddy befinner seg til mobilbrukeren. Etter autentikasjonen går greit skal JjegSerDeg behandle mobilbrukerens forspørsel og sjekke om buddyen finnes i databasen. Hvis buddyen finnes i basen skal faaposisjon finne hvor buddyen befinner seg og videre skal det sendes en OK tilbakemelding som inneholder posisjonen buddyen befinner seg til mobilbrukeren. Hvis buddyen finnes ikke i basen eller PATS kan ikke posisjonere buddien, skal det sendes en feil tilbakemelding til buddien.

29 sd gibuddyliste gir mobilbrukeren liste over alle sine buddyes. Hvis Autentikasjon gikk greit så sendes det en forespørsel til Database om den kan gi buddylisten. Deretter kommer en loop som gir listen til JegSerDeg. Så sendes videre hele listen tilbake til PATS som sender listen som SMS til mobilbruker.

30 Det foregår først en autentikasjon, for å finne ut om brukeren har lov til å utføre denne tjenesten. Hvis så blir buddy_kiontrolleren bedt om å få ta i en liste over alle denne brukerens buddyer. Database_Kontrollerene snakker i sin tur med databasen,og får tilbake en liste som blir bygget opp i buddy_kontrolleren før den blir sendt tilbake til PATS serveren. Vi har ikke beskrevet alle slike tjenester siden, alle vil ligne på denne. De eneste vi har laget spesielt er når buddyer og hotspots blir laget.