INF 2120-PROSJEKT: <DROP 2 GRUPPE 7> ATLE WANDSVIK DAMIR NADIC SOHAIL AHMED CHAUDRY LARS ANTHONY LAMPAY FOZIA SAEED
1. INTRODUKSJON Traffikanten pluss systemet er et system som gir brukere mulighet til å få oppdaterte rutetider ved bruk av SMS. Systemet skal være i stand til å håndtere flere brukere samtidig. Systemet tilbyr 3 tjenester. Disse er getroute som gir brukeren de 5 neste avgangene. getmore som gir brukeren ytterligere 5 avganger, og gethelp som er en funksjonalitet som gir brukeren hjelp til hvordan benytte tjenestene systemet tilbyr. 1.1 Forutsetninger Vi forutsetter at vi har tilgang til en database eller lignende som inneholder alle ruter med oppdaterte rutetider, stoppesteder med posisjon og at vi har et eksternt system som kan ta imot og sende SMSmeldinger, samt gir mulighet til å kunne posisjonere en gitt mobiltelefon. Vi forutsetter også at brukeren som skal benytte systemet befinner seg i oslo-området. inf2120-tpsystem-project (04/28/05) Page 1
2 SPESIFIKASJONER For å begrense omfanget av oppgaven har vi valgt å modellere funksjonaliteten for get5nextdepartuers og gethelp. Vi har med andre ord valgt å se bort fra GetDelays funksjonaliteten, som vi følte var den minst sentrale delen av systemet. Vi har måttet foreta noen endringer i sekvensdiagrammene, disse endringene har ingen påvirkning på de opprinnelige funksjonalitetene. Men vi så at endringene var hensiktsmessige i forhold til å gjøre systemet bedre. I tillegg til dette har vi lagt til en ny funksjonalitet som heter getmore. Denne gir brukeren anledning til å be om flere avganger. 2.1 Beskrivelse av funksjonalitet getroute getroute er den mest sentrale funksjonaliteten. Den gir brukeren mulighet til å få de 5 neste avgangene. Brukeren kan velge å spesifisere hvor han ønsker å dra fra, til og når. Dersom brukeren ikke oppgir hvor han vil dra fra finner systemet næremeste stoppested ved hjelp av posisjonering av brukerens mobiltelefon. Dersom brukeren ikke spesifiserer noen tid går systemet ut fra at det er tiden nå som skal brukes, og finner mulige ruter som oppfyller dette. Dette betyr da at tid og avgangsstasjon er valgfrie parametere, mens ønsket destinasjon må alltid være med i meldingen som brukeren sender til systemet. Eks: getroute blindern, stortinget, 13:00 Denne vil gi de 5 neste avgangene fra blindern til stortingen fra kl 13:00 gethelp gethelp funksjonaliteten tilbyr en mulighet for brukeren å få hjelp til hvordan han bruker tjenestene. Brukeren kan da spesifisere en kommando han ønsker å få hjelp til (for eksempel getroute). Dersom ingen kommando er spesifisert, eller systemet ikke gjenkjenner kommandoen sendes det en generell hjelpetekst til brukeren. getmore Etter at brukeren har bedt om getroute, kan brukeren be om getmore. Brukeren vil da få tilsendt de 5 rutene som er etter de 5 han fikk tilsendt ved getroute. getmore trenger ingen parameter, da systemet vil huske hva brukeren sendt da han ba om getroute. Systemet vil altså benytte de samme parameterene. Vi har her satt en tidsbegrensning på 10 min. Etter denne tidsperioden fjerner systemet denne informasjonen, og brukeren må da sende getroute, med nye parametere dersom han ønsker flere avganger. En begrensning ved denne funksjonaliteten er at dersom du sender getmore flere ganger, vil brukeren få tilsendt de samme 5 rutene. Vi kunne gjort det slik at systemet husket hvilke ruter som har blitt sendt til brukeren, og dermed sendt 5 nye ruter hver gang brukeren ba om getmore. Men vi har for enkelhets skyld valgt å se bort fra denne begrensningen. Grunnen til at vi valgte å legge til denne, kanskje litt basale funksjonaliteten, var for gjøre mer bruk av sesjonskontroll. Siden ingen i gruppen hadde gjort noe tilsvarende før, syntes vi dette var en spennende side ved systemet, men vi ble kanskje klar over denne litt for sent i prosessen. Siden denne funksjonaliteten medførte små endringer av de sekvensdiagrammene, og tilstandsmaskinene vi allerede hadde, men gjorde at behovet for sesjonskontroll kom klarer frem valgte vi å legge til denne. inf2120-tpsystem-project (04/28/05) Page 2
Generelt Systemet er lagt opp slik at dersom brukeren sender inn feil kommandoer til systemet, vil systemet returnere en generell hjelpetekst. Dersom brukeren sender riktig kommando, men feil parametere vil systemet returnere en hjelpetekst for gitt kommando. Begrensninger Slik systemet er tenkt nå, gir det ikke mulighet for brukeren å bestemme hvilke typer transportmiddel han ønsker. Det betyr at man kan få for eksempel en rute for t-bane, to for trikk og to for buss. Systemet er heller ikke istand til å håndtere overganger til andre linjer. Og som tidligere nevnt, er systemet kun tilgjengelig for bruk i oslo-området 2.2 Beskrivelse av sesjonskontroll Vi så et behov for en sesjonkontroll, siden systemet måtte kunne håndtere flere brukere samtidig. For å få dette til måtte vi bruke en sesjonskontroll. Måten vi har gjort dette på er å si at en sesjonskontroller holder rede på alle sesjoner som finnes i systemet. Når en bruker sender en melding til systemet sjekker sesjonskontrolleren om det finnes en sesjon for denne brukeren. Hvis det eksisterer en sesjon for denne brukeren sender sesjonskontrolleren tekstmeldingen til riktig sesjonsobjekt. Ellers vil sesjonskontrolleren opprette et nytt sesjonsobjekt, og sende tekstmeldingen hit. Vi ser i etterkant at vi nok kunne gjort dette på en annen, og litt bedre måte. Slik vi har det nå, vil alle delene i systemet (queryhandler, SMSHandler osv) være en del av sesjonsobjektet. Dette betyr at vi opprettet nesten hele systemet hver gang en bruker sender en SMS. En litt smarter løsning ville nok vært å legge alle ting som ikke har noe med selve sesjonen og gjøre utenfor sesjonsobjektet, og bare la dette holde på verdier/objekter som er relevant, og forskjellig, for hver sesjon. Grunnen til løsningen vi valgte var at vi så denne som den greieste å utvide med etter at vi gjennom hele prosessen hadde hatt fokus på at det var kun en bruker om gangen. inf2120-tpsystem-project (04/28/05) Page 3
2.3 Endringer i sekvensdiagrammene Vi har gjort en del endringer i skvensdiagrammene som vi fikk som utgangspunkt fra gr.9. Grunnen til disse endringene forklares mer i detalj under avsnitt for hvert enkelt sekvensdiagram, men generelt er endringene gjort fordi vi følte det var hensiktsmessig. 2.3.1 sd 5nextDepartures Her har vi endret slik at systemet tar imot en SMS og sender ut en SMS. Vi har lagd et nytt sekvensdiagram som vi refererer til, sd controller. Dette gjorde vi for å legge til sesjonskontrolleren vi så behov for. Alt boksen som var her opprinnelig har vi egentlig flyttet til sd getdepartures. Vi har også gjort endringer på parametere. Returmeldingen (replymsg) er den SMS-meldingen systemet sender til brukeren. Innholdet i denne vil variere etter hva brukeren ber om (eks. ruter eller hjelpetekst). 2.3.2 sd controller Dette er et nytt sekvensdiagramm. Vi hadde behov for dette fordi vi ville at systemet skulle kunne håndtere mer enn en bruker samtidig. Her får vi inn en SMS-melding. Det første vi gjør er å sjekke om det allerede eksisterer en sesjon for denne brukeren. Dersom det ikke gjør det oppretter vi en ny sesjon, og sender meldingen videre til denne. Hvis det eksisterer en sesjon for denne brukeren sender vi bare meldingen videre til denne sesjonen. Når sesjonsobjektet er ferdig, og har funnet den nødvendige informasjonen genererer den en replymsg og sender denne til sesjoncontroller, som igjen sender den vider til brukeren. Vi har også lagt inn en timer som sier at etter 10 minutter skal sesjonsobjektet gi melding til sesjonskontrolleren om at den skal slette dette sesjonsobjektet. Se forøvrig avsnitt 2.1 getmore og 2.2 beskrivelse av sesjonskontroll. 2.3.3 sd SP_getDepartuers splittcommandpar() Her så vi oss nødt til å legge inn en metode for å kunne splitte opp den sms-meldingen vi får inn i systemet. Dette er nødvendig for kunne sjekke hva slags kommando brukeren har gitt, samt hvilke parametere den inneholder. checkcode() Etter at sms-meldingen er splittet opp i kommando, og parametere (fromstop, tostop, time) så vi det som nødvendig å sjekke om kommandoen som er gitt er gyldig, og om de riktige parameterene er sendt med. Vi har, i sekvensdiagrammet definert code som hele meldingen systemet mottar. Dersom der er noe feil i denne, sender vi en hjelpetekst tilbake til brukeren. Ellers så sjekker vi hvilken kommando som er gitt, og finner relevant informasjon, og returnerer dette til brukeren. Andre endringer I tillegg til dette så vi det nødvendig å legge til en alt-boks der vi, hvis kommandoen er getroute og vi har gyldige parametere, finner avganger og returnerer disse. Dersom kommandoen er ukjent, eller gethelp returnerer vi hjelp på et gitt emne, eller bare en generell hjelpetekst. Vi har også lagt til den nye funksjonaliteten for getmore beskrevet i detalj i avsnitt 2.1 getmore. inf2120-tpsystem-project (04/28/05) Page 4
2.3.4 sd FindDepartures Her har vi endret option boksen for getsystemtime. I stedet for å gå til DatabaseControl for å hente systemtid, gjør vi dette i QueryHandler. En endring vi har gjort er å si at brukeren ikke kan bestemme numberof, som opprinnelig var tenkt til at brukeren kunne si hvor mange ruter han ønsket å få tilsendt. Vi har derimot bestemt at ved getroute og getmore skal brukeren alltid få 5 avganger. Vi har beholdt numberof i sekvensdiagrammet fordi systemet trenger en mulighet for å si hvor mange avganger som skal hentes. Når brukeren ber om getmore henter systemet egentlig de 10 neste utfra de parameteren som var gitt når brukeren sendte getroute. Systemet returnerer de 5 siste av disse 10, som da vil være de 5 avgangene etter de 5 brukeren fikk ved getroute. Vi har gjort det slik av enkelhetsgrunner. Vi kunne løst dette på en annen måte, ved å ta vare på de avgangene systemet allerede har sendt til brukeren og kun returnert 5 nye. Dette ville da gjort at getmore funksjonaliteten ville kunne brukes mer enn en gang. Denne løsningen ville medført vesentlige endringer. Siden vi la til denne nye funksjonaliteten for å benytte oss mer av sesjonshåndteringen valgte vi den enkleste løsningen. 2.3.5 sd SP_findStop Her er det kun gjort navneendringer på kall og meldinger. Opprinnelig findposition(telephone#) currentposition findstop(currentposition) Erstattet med findposition(staticid) currentposition(x,y) findcloseststop(x,y) 2.3.6 sd_gethelp Her så vi det nødvendig å legge til en chktopic for å finne ut om kommandoen som det spørres om hjelp til er en gyldig kommando. Hvis kommandoen er gyldig returnerer systemet hjelp til denne kommandoen, ellers returnerer systemet en generell hjelpetekst. inf2120-tpsystem-project (04/28/05) Page 5
3 COMPOSITE STRUCTURE Composite structure - Collaboration Diagrammet viser en oversikt over hvordan de ulike delene av systemet kommuniserer/samhandler med hverandre. Brukeren sender en sms melding til service provider som sender denne videre til sesjonskontrolleren, her blir det sjekket om det eksisterer en sesjon med tilhørende ID fra før av. Hvis ikke denne finnes, lager sesjonskontrolleren en ny sesjon ellers blir meldingen sendt videre i den riktige sesjonen. Composite structure - Class Diagrammet viser kommunikasjonen mellom de interne delene av systemet. Når en sms melding mottas av smshandler splittes meldingen (kommando og parametere) og sender den videre til queryhandler. queryhandler spiller en viktig rolle i systemet da det kommuniserer med PositionObject, HelpObject og DatabaseControl. inf2120-tpsystem-project (04/28/05) Page 6
Composite Structure - Collabration Composite Structure - Class inf2120-tpsystem-project (04/28/05) Page 7
4 SEKVENSDIAGRAMMER Sd 5nextDepartures inf2120-tpsystem-project (04/28/05) Page 8
Sd controller inf2120-tpsystem-project (04/28/05) Page 9
Sd SP_getDepartures inf2120-tpsystem-project (04/28/05) Page 10
Sd finddepartures inf2120-tpsystem-project (04/28/05) Page 11
Sd SP_findStop inf2120-tpsystem-project (04/28/05) Page 12
Sd gethelp inf2120-tpsystem-project (04/28/05) Page 13
5 TILSTANDSMASKINER Sm_sessionController inf2120-tpsystem-project (04/28/05) Page 14
SMSHandler inf2120-tpsystem-project (04/28/05) Page 15
queryhandler inf2120-tpsystem-project (04/28/05) Page 16
Sm_helpObject inf2120-tpsystem-project (04/28/05) Page 17