UNIVERSITETET I OSLO Institutt for informatikk. INF2120: ICU - a surveillance system, Drop 1. gisleal, eivindjo, tanxn, behrozm

Transkript

1 UNIVERSITETET I OSLO Institutt for informatikk INF2120: ICU - a surveillance system, Drop 1 gisleal, eivindjo, tanxn, behrozm 22. februar 2006

2 Systemkrav I tabellen nedenfor er en oversikt over systemkravene for ICU. Prioritet Systemkrav Use Case diagram SubscribeToService Høy Registrere en bruker i systemet Høy Høy Slette en bruker fra systemet Opprette en ny buddyliste UnsubscribeFromService CreateNewBuddylist Medium Slette en eksisterende buddyliste DeleteExistingBuddylist Høy Legge til en bruker i en buddyliste AddSelfToBuddylist Medium Slette en bruker fra en buddyliste RemoveSelfFromBuddylist Medium Få nåværende posisjon av bruker GetCurrentPosition Høy Registrere hotspots RegisterHotspot Medium Slette hotspots DeleteHotspot Lav Bestille varsling OrderHotspotNotification Lav Avbestille varsling CancelHotspotNotification

3 Systemdefinisjoner Bruker En bruker i systemet er identifisert ved en mobiltelefon. En bruker registrerer seg i systemet ved å sende en SMS til systemet via mobiltelefonen. Buddylister En buddyliste er en navngitt liste av brukere. En bruker kan være medlem av ingen, en eller flere buddylister. En buddyliste kan typisk hete Familien Nordmann, hvor Ola Nordmanns familie inngår. Ola Nordmann jobber også i Lillevik Regnskap AS, og er dermed medlem av buddylisten Ansatte - Lillevik Regnskap. At Ola Nordmann har meldt seg på disse to buddylister betyr at alle i familien samt alle på jobben til Ola Nordmann kan få opplysninger om ham. Selvsagt kan ingen i Lillevik Regnskap AS få informasjon om andre person i Olas familie. Hotspots En hotspot er i første omgang en navngitt plass i verden med en x,y koordinat typisk lengdegrad og breddegrad. Det å angi en hotspot hjelper brukere av systemet å forstå hvor en annen bruker er evt. Varsles når en selv eller en annen bruker er i nærheten av denne hotspot en. Vi har diskutert om en person også skal være en hotspot, og om vi også skal skille mellom to typer hotspots; mobile/dynamisk og faste/statiske. Dette kunne blitt implementert ved å ha et Felles interface for mobile og faste hotspots så vel som brukere. Vi har kommet frem til at dette ligger utenfor det vi ønsker å tilby av funksjonalitet.

4 Use case diagrammer Under følger beskrivelse av hver enkelt tjeneste. Subscribe to service Brukeren legger seg til tjenesten ved å sende en SMS med en statisk id til systemet. Unsubscribe from service Brukeren melder seg av systemet når som helst ved å sende en SMS til systemet om å melde seg av tjenesten. Create new buddylist Brukeren oppretter en ny buddyliste ved å sende en SMS til systemet om å opprette en ny buddyliste. Delete existing buddylist Brukeren sletter en buddyliste ved å sende en SMS til systemet om å slette brukeren fra systemet. Dette forutsetter at brukeren er den samme som opprettet buddylisten.

5 Add self to buddylist Brukeren legger seg til en buddyliste ved å sende en SMS til systemet om å melde seg på en eksisterende buddyliste. Remove self from buddylist Brukeren fjerner seg fra en buddyliste ved å sende en SMS til systemet om å melde seg av fra en eksisterende buddyliste. Get current position Brukeren får sin nåværende posisjon ved å sende en SMS til systemet om å få sin nåværende posisjon. Systemet sjekker så om det er noe hotspot i nærheten av brukeren F.eks You are now 500m from the Department of Informatics hvor Department of Informatics er et sted i relativ kort avstand fra brukeren som er registrert i systemet. Register hotspot Brukeren registrerer et hotspot ved å sende en SMS til systemet. Dersom brukeren angir koordinater i SMS-meldingen blir hotspot et definert i forhold til disse koordinatene om ikke, registreres hotspot et i forhold til nåværende posisjon. Delete hotspot Brukeren har ikke tilgang til å slette hotspots. Order hotspot notification Brukeren bestiller varsling ved å sende en SMS til systemet om å bli varslet av systemet når brukeren er i nærheten av ett hotspot. Tjenesten bestilles èn gang, og vil så varsle brukeren hver gang vedkommende er i nærheten av dette hotspot et. Brukeren kan avbestille denne tjenesten (se under). Cancel hotspot notification Brukeren avbestiller varsling ved å sende en SMS til systemet å avbestille varsling av ett eller flere hotspot.

6 Sekvensdiagrammer BuddylistCreation SMSUser representerer en bruker av systemet som sender en melding til systemet om å opprette en ny buddyliste. Dekomponerer vi livslinjen SystemBuddylistCreation ser vi følgende:

7 Først mottar SMSHandler meldingen, autentiserer brukeren og kaller kontrolleren i systemet ICU. ICU kontakter samlingen av buddylister og ber denne om å lage en ny buddyliste. Under UserAuthentication skjer følgende: Vi ser at SMSHandler kontakter Authenticator som kontrollerer at brukeren som sendte SMS-en er en eksisterende bruker i systemet.

8 BuddylistSubscription SMSUser representerer en bruker av systemet som sender en melding til systemet om melde seg på en eksisterende buddyliste. Vi dekomponerer livslinjen og ser at kontrolleren henter en buddyliste og legger til brukeren som sendte SMS-en:

9 HotspotRegistration SMSUser representerer en bruker av systemet som sender en SMS til systemet om å registrere ett hotspot i systemet. Denne operasjonen blir styrt av SystemHotspotRegistration. Pga at vi har valgt å definere hotspots relativt i forhold til brukerens posisjon har vi tatt utgangspunkt i 2 scenarioer: gitt brukerens nåværende posisjon og gitt koordinater brukeren oppgir. Systemet er tenkt å polle brukeres posisjon med gjevne tidsintervaller, og dermed oppdatere/lagre brukerens posisjon i systemet. Kommunikasjonen med PATS er derfor som optional på to nivåer; først og fremst fordi brukeren ikke gir koordinater, og videre fordi det kan være lenge siden brukeren sist ble posisjonert. Kommunikasjonen med PATS styres av FindPosition/ICUUserFindPosition. Dekomponerer vi SystemHotspotRegistration ender vi opp med følgende:

10 Dersom brukeren ikke gir koordinater i tekstmeldingen f.eks er vi nødt til å finne ut hvor brukeren er nå. Dette gjøres under ICUUserFindPosition:

11 Vi kunne også kommet til ICUUserFindPosition ved å følge FindPosition fra toppnivå: Dette diagrammet beskriver at vi muligens må kontakte PATS for å få brukerens nye posisjon. Dette skjer dersom det er lenge siden systemet sist sjekket vedkommendes posisjon. UserRegistration SMSUser representerer en bruker av systemet som sender en melding til systemet om å opprette en brukerkonto. Denne operasjonen styres av SystemUserRegistration.

12 Dekomponerer vi livslinjen SystemUserRegistration ser vi følgende: Vi dekomponerer livslinjen og ser at kontrolleren ber brukersettet om å opprette en ny bruker. Legg merke til at brukeren ikke skal autentiseres fordi brukeren ikke er en del av systemet før en brukerkonto har blitt opprettet. UserUnregistration SMSUser representerer en bruker av systemet som sender en melding til systemet om å slette en brukerkonto. Denne operasjonen styres av SystemUserUnregistration.

13 Dekomponerer vi livslinjen SystemUserUnregistration ser vi følgende: Vi dekomponerer livslinjen og ser at kontrolleren ber brukersettet om å slette brukeren. Legg merke til at brukeren må autentiseres før operasjonen kan utføres.

14 Notification SMSUser representerer en bruker av systemet som sender en melding til systemet om melde seg på en varslingsliste. Denne operasjonen styres av SystemNotification. Deretter mottar brukeren en melding tilbakefra systemet som forteller at brukeren nå er påmeldt varslingssystemet. Deretter går en del av systemet i en løkke og sjekker brukerens posisjon i forhold til hotspot et. Dersom brukeren er i nærheten, vil han motta en beskjed om dette. Dersom brukeren ønsker å melde seg av varslingstjenesten sender brukeren en beskjed til systemet om melde seg av tjenesten. Grunnen til at vi har valgt å ta med Break her er at hvis varslingstjenesten stoppes vil også Loopen stoppes.

15 Dekomponerer vi livslinjen SystemNotification ser vi følgende: Kontrolleren initierer en AlarmHandler som med jevne mellomrom avgjør om bestilleren subscriber er i nærheten av hotspot et. Dersom de er nær hverandre, sender systemet en melding til brukeren om dette. Dette pågår helt til brukeren avbestiller tjenesten. Klassediagram og komposittstrukturer

16 Komposittstruktur på overordnet nivå:

17 Komposittstruktur på system-nivå: Oppsummering Under fremstillingen av klassediagram og komposittstrukturene kom det frem at vi ikke helt har fått med oss den store sammenhengen at vi altfor tidlig hoppet til implementasjonsdetaljer. I lys av dette har vi en vag skisse over et nytt design, hvor vi deler inn systemet vårt i tjenester. Alle tjenestene blir kontrollert av en kontroller. Kontrolleren er ansvarlig for å autentisere brukeren, tolke tekstmeldingen og kalle de riktige tjenestene for å løse oppgaven. Vi har imidlertid valgt å levere vår opprinnelige løsning pga. tidsbegrensninger. Se vedlegg for overordnet klassediagram og komposittstruktur av ICU for denne tankegangen:

18 Vedlegg Det er verdt å nevne at ICU her ikke må forveksles med ICU i løsningen over, da de befinner seg på ulike nivåer.