DELLEVERANSE 3 INF2120 GRUPPE 12 Av Jon G. Berentsen Geir A. Nilsen Lailuma Arezo
Innledning: Hensikten med vår oppgave er, fremdeles, å lage et overvåkningssystem basert på posisjonering av mobiltelefon. Systemet skal kunne tilby følgende tjenester: - Kommunikasjonen mellom systemet og brukerne foregår vha sms. - Posisjonere registrerte brukere når de ber om det, og ikke ved tidsintervaller. - Få beskjed om de befinner seg i nærheten av såkalte hotspots ved posisjonering. - De skal kunne få informasjon om hvor en annen samtykket bruker befinner seg relativt til dem selv, ut i fra gitte regler. Som registrert bruker følger også en rekke påfølgende tjenester. De skal kunne melde seg på og av. 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. Revidert spesifikasjon: Vi er nå ferdig med implementasjonen hvor målet har vært å få et kjørende system ut av designen. Underveis i prosessen har vi gjort en del revideringer i forhold til innhold i tjenestene. Etter del-leveranse 2 ble vi kritisert for å ha en for komplisert struktur, med 3 indre kompositstrukturer i system kompositen. Dette har vi valgt å beholde da vi mener at dette letter implementasjon av selvstendige tjenester og rutingen mellom de forskjellige partene. Endringer fra forrige drop: - I Userhandler tilstadsmaskin (sm) har vi fjernet tilstanden som sjekker om databasen er oppe og kjører. - I databasen har vi utvidet attributtet pos i tabellene Users og UserHS til 3 attributter, posx, posy og timedate. - Vi har gått vekk fra å rute på parametre. I stedet lages det nye signaler som det rutes på. - Vi har etablert et signalhierarki, bl.a for å lette rutingen og antall signaler. - Sm DB_Handler er endret til å jobbe synkront mot databasen. - Verifisering av brukere i DB er overlatt til den enkelte sesjon. - Alle opplagte feil i klassifiseringen av porter og ruting av signaler er korrigert. - I komposit struktur PositionUser har vi fjernet sm PosBuddies og nearanyhotspots. PosBuddies tjenesten er flyttet til komposit struktur BuddyServices og nearanyhotspots er trukket inn i PosOneUser som en del av tjenesten. - PosOneUser er utvidet betraktelig med verifisering i DB og posisjonering av bruker.
Implementasjon Målet med med implementasjonen har vært å få opp en tjeneste som fungerer, med den strukturer vi hadde satt opp. Ved å gå over til en tjenesteorientert design gikk det greit å implementere tjenester hver for oss innad i gruppen, fordi kohesjonen mellom tjenestene var ikke-eksisterende. Det eneste tjenestene benyttet seg av som var felles var resultatene, i vårt tilfelle, resultater skrevet til databasen. Disse kunne vi enkelt imitere ved å legge testverdier manuellt inn i databasen. Dette gjorde også testingen av de enkelte tjenestene enklere, da de kunne testes hver for seg. Vi opplevde også at den forsåvidt kompliserte strukturen lettet ruting og det å legge til nye tjenester. Det kan forekomme noen feil ved feil bruk av buddy-tjenestene. De fungerer som de skal ved vanlig bruk, men produserer ikke alltid korrekte feilmeldinger til bruker. Vi har sett oss nødt til å la dette ligge grunnet tidspress.
Diagrammer i systemet: DB_relasjons-design: Alle brukere av systemet er registret som en tuppell i tabellen Users.Username må være unik og user_id vil alltid være unik. Posx beskriver breddegraden og posy beskrive lengegraden, begge er float. Timedate beskriver når siste posisjonering av bruker som en string hentet fra objektet Date i java.util. Alle hotspot er er registrert som en tuppell i tabellen userhs. En hotspot har en eier, user_id, som må finnes i tabellen users. HSname må være unik. Posx og posy er det samme som i users for en hotspot. I tabellen buddylist er en tuppell forholdet mellom en owner og en buddy. Dette forholdet er alltid refleksivt i tabellen. Det er 3 tabeller i databasen til sammen.
Signaler: Verd å merke seg SessionAnswer, som har mange underklasser (se neste side). Dette brukes aktivt i systemet for å lette rutingen.
Komposit Struktur JSD: Dette er hovedoversikten av systemet. UserHandler og DbHandler er to sm og PositionSrvices, HSController og BuddySErvices er 3 komposit strukturer. I tillegg har vi definert 4 public string variable i JSD, BUDDY_SERVICES, POS_SERVICES, HOTSPOT_SERVICES og phoneservices. De 3 første sendes med som attributter i signaler for å lette rutingen. Den siste er for å definere tlf-nr som brukes, i vårt tilfelle 2034. Det er også lagt inn variable med passord og login til databasen her.
Tilstandsmaskinen UserHandler: Fungerer som en ruter i systemet. All kommunikasjon fra SMS porter til andre deler av sytemet og fra dbhandler til de 3 kompositene rutes her. Mao. signealer som har mer enn en mulig mottaker. Sms-ruting foregår ved å parse den innkommende Sms og trekke ut den kommandoen/tjenesten bruker ønsker å få utført. Dette testes det på i junction'en øverst i bildet. Andre signaler, PosResult og SessionAnswer-signaler, blir behandlet mer direkte.
Tilstandsmaskin DB_Handler: Fungerer som en ren "SQL-spørremaskin". Alt blir trigget på innkommende signaler. Sql blir utført, filer skrevet og returverdier sendt, i en vending.
Komposit struktur PositionServices: Denne inneholder to sm, posservicecontroller med multiplisitet 1 og positiononeuser med multiplisitet *. PosServiceController fungerer som en ruter til de enkelte posoneuser-sesjoner. Den står også for generering av disse.
Tilstandsmaskin PosServiceController: Ruter de forkjellige signalene som kommer inn til riktig port, som igjen finner riktig sesjon. Har en variabel session_counter som gir sesjonene et unikt nummer.
Tilstandsmaskin positiononeuser: Sesjoner av denne blir generert etter behov. Verifiserer brukere i DB. Posisjonerer bruker. Oppdaterer brukers posisjon og initisierer sjekk mot hotspots.
Komposit Struktur HScontroller: Denne inneholder to sm, HotspotServicesController med multiplisitet 1 og CreatHotspot med multiplisitet *. HotSpotController fungerer som en ruter til de enkelte CreatHotspot. Den står også for generering av disse.
Tilstandsmaskin HotspotServicesController: Ruter de forkjellige signalene som kommer inn til riktig port, som igjen finner riktig sesjon. Har en variabel session_counter som gir sesjonene et unikt nummer.
Tilstandsmaskin CreateHotspot: Sesjoner av denne blir generert etter behov. Verifiserer brukere i DB, posisjonerer hotspot og lagrer hotspots i DB.
Komposit struktur BuddyServices: Inneholder 3 sm. BuddyController tar seg av kreasjon og ruting til sesjoner av sm AddBuddySession og PosBuddySession. Disse kan sende signaler til dbhandler og til Smsportene.
Tilstandsmaskin Buddycontroller: Ruter og sesjonshåndterer. De to nederste trigger kreasjoner av de forskjellige sm, mens SessionAnswer er div. svar til disse.
Tilstandsmaskin addbuddy: Sjekker først om buddy er en bruker i systemet (påkrevd). Sjekker så bruker. Posisjonerer bruker og skriver ham til databasen.
Tilstandsmaskin posbuddies: Henter ut alle buddy'ene til en bruker. Sender ut PosRequest og venter på tilbakemelding. Posisjonerer så bruker og oppdaterer hans posisjoner i databasen. Ber så om å få skrevet KMLfila.
Testspesifikasjon Testcaser: 1. Legge til en mobil (statisk id) som allerede finnes. Forventet utfall: Sms med melding om at du allerede er registrert. Mulige feilmeldinger: * Feilkjøringer i systemet. * Beskjed om at du er lagt inn i sytemet. 2. Slette en hotspot som allerede er slettet / ikke eksisterer. Forventet utfall: Sms med melding om at hotspoten ikke finnes i din profil. Mulige feilmeldinger: * Feilkjøringer i systemet. * Beskjed om at hotspoten er slettet fra din profil. 3. Posisjonere buddy'er og få ut kml fila. Forventet utfall: Beskjed om at din posisjon er oppdatert. En KML fil med posisjoner av nyere dato. Mulige feilmeldinger: * Feilkjøringer i systemet. * KML fil med gammel data. * Ingen posisjonering skjer. * Ingen posisjonering av buddy'er
Kjøring av test nr 3. Resultat: OK, men mangler bruker i kml fila. Fra JFTrace: KML fila: <?xml version="1.0" encoding="utf-8"?> <kml xmlns="http://earth.google.com/kml/2.0"> <Folder> <name>g12 inf2120 Google Positioner</name> <open>1</open> <Placemark> <name>per</name> <description>wed May 31 22:28:05 GMT+01:00 2006</description> <Point> <coordinates>10.4511,59.5435,0</coordinates> </Point> </Placemark> </Folder> </kml>