Universitetet i Oslo Institutt for informatikk Leveranse 2 - inf2120 Gruppe 9 Mads Andre Bergdal Neeru Bhardwaj Saqib Riaz Trond Arne Sørby 29. april 2005
2
1 Innledning Vi har nå designet et system kalt Trafikanten Pluss, et system hvor reisende kan få dynamisk oppdatert ruteinformasjon. Utgangspunktet for denne leveransen er spesifikasjonen av Trafikanten Pluss-systemet gitt av Gruppe 8. 1.1 Forutsetninger Vi forutsetter at alle holdeplassene har en kjent posisjon, og at denne posisjonen er registrert i vår statiske database. Videre forutsetter vi at det ikke er noen vesensforskjell mellom ulike transportmidler som buss, båt, tog eller trikk; systemet vil derfor ikke skjelne mellom de ulike typene. Vi ser videre bort fra eventuelle endringer av rutene, opprettelse av nye holdeplasser og lignende. Systemet vil således være begrenset til virkeligheten slik den er nå. Vi forutsetter at vi alltid kan skaffe oss oppdatert informasjon om hvor hvert enkelt transportmiddel finnes. 1.2 Interessenter Selv om systemet også kan være til nytte for de ansatte i trafikkselskapet, vil de primære interessentene være passasjerene. 2 Revidert spesifikasjon I den opprinnelige spesifikasjonen var det beskrevet en rekke tjenester: Brukeren sender SMS, og systemet svarer med SMS, beste alternativ. Brukeren sender SMS med NESTE, og får neste alternativ som SMS. Brukeren sender SMS med KART, og får kart via MMS. Brukeren sender SMS med forespørsel om alle nærliggende stasjoner, og får tilbakemelding om så mange stasjoner det er plass til i en enkelt melding. Vi har i designet valgt å begrense oss til kun de to første tjenestene. Karttjenesten ville vært spennende å implementere, men vi kan ikke se at det ville være gjennomførbart med de ressurser som er tilgjengelige for oss. Sekvendsdiagrammene er sterkt modifisert fra delleveranse 1, da vi nå vet mer om grensenittet til de eksterne tjeneste vi benytter det var ønskelig å løse flerbrukerproblematikken på en god måte 3
2.1 Sd TrafikantenPluss Vi har tatt med det overordnete sekvensdiagrammet fra den opprinnelige spesifikasjonen, med lett modifiserte navn (FinnRute tilsvarer FinnPunkter, FinnAvgang tilsvarer TilPunkt og FinnHoldeplass tilsvarer FraPunktTil- Punkt). Vi har som tidligere nevnt begrenset tjenestetilbudet, og konsentrert oss om å gjennomføre FinnAvgang. 2.2 Sd FinnAvgang Med utgangspunkt i sd TilPunkt fra leveranse 1 har vi nå laget et nytt sekvensdiagram, som er mer spesifikt og konkret. I tillegg viser diagrammet at vi håndterer flere samtidige brukere parallelt. Sekvensdiagrammet viser oss to konkrete hendelser hvor Pelle og Proffen sender sms for å få informasjon om sine avganger. Pelle skal til Høybråten, mens Proffen skal til Majorstua. Brukerne får melding fra sentralen om mulige avganger i ønskede retninger, med rutenummer og klokkeslett for første avgang. Vi ser at hvis Pelle eller Proffen ønsker å få tidspunkt for neste avgang i samme retning, sender de en SMS med kodeordet NESTE og får så tilsendt sms med tidspunktet for den neste avgangen. 2.3 Sd FinnAvgangSystem Dette er den detaljerte dekomponeringen av systemlivslinjen fra det forrige diagrammet. La oss følge gangen for Pelle: SMSsystemet (PATS) mottar SMSen fra Pelle (melding 1), og sender den videre til kontrollobjektet (2) i vårt system. Kontrollobjektet lager så et sesjonsobjekt (3) for Pelle, og sender kommandoen fra SMSen til sesjonsobjektet (8). Sesjonsobjektet ber så PATS finne ut hvor Pelle befinner seg (12), og får svaret som koordinater (13). Sesjonsobjektet ber så rutetabellobjektet om å finne den nærmeste relevante holdeplassen (14/15). Deretter spør sesjonsobjektet Trafikantenobjektet om status for denne holdeplassen (16) og får svaret som en XML-fil som inneholder dynamisk informasjon om de nærmeste avganger fra holdeplassen (17). Sesjonsobjektet finner utifra dette den neste avgangen, og får PATS til å sende Pelle en SMS med informasjonen (18/19). Hva som skjer hvis Pelle så sender en SMS med kodeordet NESTE er beskrevet i sekvensdiagrammet sd FinnAvgangSystemNeste. 10 minutter etter at sesjonsobjektet ble opprettet, vil kontrolleren avslutte sesjonen (22). 2.4 Sd FinnAvgangSystemNeste Sender bruker kodeordet NESTE til systemet, så skjer ett av to: Hvis brukerens sesjonsobjekt fremdeles eksisterer, ber kontrolleren det om neste avgang. Sesjonsobjektet har allerede informasjonen den trenger, og beregner neste avgang utifra dette og sender SMS til bruker. Hvis sesjonsobjektet derimot 4
ikke finnes (dvs at det er over 10 minutter siden den første meldingen), vil bruker få SMS med feilmelding. 3 Design Her kommer en spesifisering av diagrammene for designmodellen. 3.1 Klassediagram Klassediagrammet består av fem objekter: 1. SMSsystem, er PATS-laben som blir brukt til kommunikasjon mellom systemet og mobilenheten til brukeren. Den kan motta og sende sms, og spørre om posisjon til mobiltelefon. 2. Kontroller, håndterer kommunikasjonen mellom SMSsystemet og de aktuelle sesjonene. Kontrolleren består av en SesjonsManager, en SesjonsBygger og en Beslutningstaker. 3. Sesjon, tar seg av kommunikasjonen mellom brukeren og systemet. Det kan være mange sesjoner samtidig tilknyttet systemet. 4. Trafikanten kommuniserer med Trafikantens eksisterende system, og gir systemet dynamisk informasjon om framkomstmidlene, i form av XML-fil. 5. Rutetabell gjør spørringer mot databasen med rutetabeller. Dette brukes til å hente informasjon om framkomstmidlenes ordinære rutetider. 3.2 Composite Structure 3.2.1 CS Trafikanten Pluss Composite Structure diagrammet av Trafikanten Pluss viser hvordan objektene kommuniserer med hverandre. Brukeren kommuniserer med Trafikanten Pluss gjennom SMSsystemet (PATS). SMSsystemet er knyttet til kontroller og sesjoner. Trafikanten Pluss systemet kan ha mange sesjoner på en gang, uten at det påvirker noen av de andre sesjonene. Hver sesjon henter ut dynamisk informasjon om fremkomstmidlene fra Trafikanten (dagens system) gjennom XML fil. Statisk informasjon blir hentet fra rutetabell for hver sesjon. 3.2.2 CS kontroller Kontroller fra CS Trafikanten Pluss har en Beslutningstaker som spør SesjonsManager om sesjonen allerede finnes. Finnes den ikke ber Beslutningstakeren Sesjonsbyggeren om å opprette et nytt sesjonsobjekt. 5
3.3 State Machines 3.3.1 Sm Kontroller Kontrollerens hovedtilstand vil være venterpåmelding. I denne tilstanden vil kontrolleren få ett av to signaler: tilholdeplass eller neste. Behandlingen av disse signalene er beskrevet i henholdsvis smbehandlerfinnholdeplass og smbehandlerneste. 3.3.2 Sm BehandlerFinnHoldeplass Utgangspunktet er at kontrolleren har fått signalet tilholdeplass. Kontrolleren vil så vente på om SesjonsManageren finner referert sesjon eller ikke. Får vi null som svar fra SesjonsManageren trigges lagsesjon og vi går over i tilstanden Venter På ny Sesjon. Når sesjonen er laget vil sesjonsid returneres. 3.3.3 Sm BehandlerNeste Utgangspunktet er at kontrolleren har fått signalet BehandlerNeste. Kontrolleren vil så vente på om SesjonsManageren finner referert sesjon eller ikke. Hvis sesjonobjektet blir funnet blir det returnert. Hvis det ikke blir funnet får vi null som returverdi. 3.3.4 Sm Sesjon Tilstandsmaskinen for sesjonsobjektet er relativt sekvensiell. Etter at sesjonsobjektet har blitt laget med create, havner vi i den initielle tilstanden. Når sesjonsobjektet får signalet tilholdeplass(destinsasjon, Tidspunkt, Id) vil det sende sendsms(pats, FinnPos(Id) ) og havne i tilstanden venterpåposisjon. Når koordinatene til posisjonen er kjent er det posisjon(koordinatene) som er triggeren, og setter i gang finnholdeplass(koordinater, destinasjon). Sesjonen kommer i tilstanden venterpåholdeplass. Når holdeplassen er kjent for sesjonen, blir finnframkomstmidler(holdeplass) satt i gang, mens sesjonen kommer inn i tilstanden VenterPåFramkomstmiddel. Når sesjonen vet om framkomstmidler, blir førstealternativ satt i gang. Sesjonen går inn i tilstanden Venter, hvor den befinner seg i 10 minutter, før sesjonen blir drept. I Venter kan triggeren være finnneste, som setter i gang nestealternativ. 3.3.5 Sm Rutetabell Fra start går rutetabell inn i Venter, hvor den venter på trigger som finnholdeplass(koordinater), og da returnerer Holdeplass. 6
3.3.6 Sm Trafikanten Sm Trafikanten Fra start går Trafikanten inn i Venter, hvor den venter på trigger som finnholdeplass(koordinater, destinasjon), og da returnerer Holdeplass. 7