INF2120 V2005. Gruppe 2 christrc ieronnin kjetimk noushinm sjuros. Trafikanten+ Innlevering

Transkript

1 INF2120 V2005 Gruppe 2 christrc ieronnin kjetimk noushinm sjuros Trafikanten+ Innlevering

2 Intensjon Vårt trafikkoppfølgingssystem skal være et system for brukerne av rutetrafikk, ved at disse skal få detaljert informasjon om avganger med et kommunikasjonsmiddel inkludert informasjon om evt forsinkelser. Bruker skal kunne få informasjon om nærmeste stoppested i fht sin posisjon (gitt vha PATS), og hvilket tidspunkt neste eller evt ønsket kommunikasjonsmiddel går, evt hvorvidt det er forsinkelser. System definisjon Systemet er basert på at et kommuniksjonsmiddel har installert en mobil sender som angir posisjon ved å sende signaler til gitte basestasjoner. Systemet innehar en rutetabell som sjekker posisjoneringssignalene for evt forsinkelser. En bruker skal kunne sende SMS (2 alternativer) å få oppgitt informasjon om avreisested og tidspunkt i hht bruksmønsterdiagrammet. Forutsetninger Det forutsettes tilgang til et SMS-rammeverk som skal kunne finne brukers posisjon utifra mobilsignaler. Det forutsettes at det finnes et tilgjengelig system med en database som oppgir sanntidsinformasjon om alle aktive kommunikasjonsmidlers posisjoner. Det forutsettes også at systemet har kontroll på tid. Bruksmønsterdiagram : Systemet baseres på to tjenester: 1) finntrafikkinfoavposisjon Bruker sender melding(sms) til Trafikanten+ som inneholder linjevalg og destinasjon. Systemet returnerer anbefalt avreisested, basert på brukers posisjon, samt neste avreisetidspunkt for gitt rute. 2) finntrafikkinfoavavreisested Bruker sender melding(sms) til Trafikanten+ som inneholder linjevalg, ønsket avreisested og destinasjon. Systemet returnerer neste avreisetidspunkt for gitt rute fra gitt avreisested.

3 Klassediagram : SMS Denne klassen kommuniserer med det eksterne systemet (PATS). Klassens ansvar er å først syntaks-kontrollere meldingene som kommer fra PATS. Dersom meldingen er gyldig, må det sjekkes hvilke av våre to tjenester meldingen gjelder (se bruksmønsterdiagram). Meldingen splittes opp i passende biter og sendes videre til Trafikkinformasjon. Trafikkinformasjon Denne klassen er ansvarlig for å samle inn nødvendig informasjon fra de andre klassene/objektene i systemet for å kunne gi brukeren et tilfredstillende svar. Trafikkinformasjon lager en ny instans av seg selv, et Sesjonsobjekt, for hver forespørsel. Det er sesjonsobjektet som da kommuniserer videre med objekter av de andre klassene. Flere slike sesjonsobjekter kan opprettes samtidig og opererer da med hver sin unike id som skiller dem fra hverandre. Slik kan systemet enkelt behandle flere henvendelser samtidig. Trafikkinformasjon inneholder en oversikt over alle holdeplasser (objekter av klassen Holdeplass) og linjer (objekter av klassen Linje) i systemet. Linje Objekter av denne klassen representerer alle linjer i systemet, f.eks. linje 37 eller linje 20. Linje har en liste med sine holdeplasser og sine ruter (objekter av klassen Rute). Ruter kan både være aktive (i trafikk) og planlagte (skal gå om f.eks. en time, eller om to dager). Systemets tid avgjør hvilke ruter som er aktive og hvilke som ennå ikke er det i henhold til rutetabellen. Rute Objekter av denne klassen representerer unike ruter som betjener en Linje. En unik rute er f.eks. linje 37 med avgang 10:15 i fra Nydalen. En annen unik rute er linje 37 med avgang 12:15 i fra Nydalen. Transportmiddel Objekter av denne klassen representerer aktuelle transportmidler som betjener en rute. Et transportmiddel er f.eks. den bussen som betjener ruten som går kl 10:15 fra Nydalen. Transportmiddel sender sin oppdaterte GPS-posisjon til Rute ved gitte intervaller. Holdeplass Objekter av denne klassen representerer alle aktive holdeplasser i systemet. Trafikkinformasjon har en liste med samtlige holdeplasser for alle ruter, mens hvert Linje-objekt har en liste med sine aktive holdeplasser.

4 Sekvensdiagram : Tjeneste 1: Sekvensdiagrammet beskriver hva som foregår når en bruker vil ha neste avgang, og sender med destinasjon, og linje.

5 Tjeneste 2: Sekvensdiagrammet beskriver hva som foregår når en bruker vil ha neste avgang, og sender med avreisested, destinasjon, og linje. Variansen mellom de to sekvensdiagrammene er i prinsippet bare det ene parameteret avreise som kun sendes med i tjeneste 2.

6 Composite structure : Diagrammet reflekterer interne samarbeid mellom klassene. Portene representerer sammenhengen mellom klassene.

7 Collaboration diagram: Collaboration diagrammet viser interaksjonen av objektene i systemet, og hvordan disse objektene assosierer seg med hverandre.

8 State machines/tilstandsmaskiner: Diagrammet SMS viser hvordan data kommer fra bruker i form av SMS fra mobiltelefon. Data behandles først ved så sjekke gyldig syntaks, splitte opp strengen i de ulike parametere og sjekke de individuelt. Feilmelding returneres om det finnes feil i syntaks, eller dataene videresendes til klasse TrafikkInfo som parametere dersom syntaks er korrekt. Antallet parametere som blir skilt ut av inputdata avgjør hvorvidt det er tjeneste 1 eller 2 som aktiveres. (jmf. Sekvesndiagram). Etterhvert returneres data fra klasse TrafikkInfo og svar genereres og returneres ut til bruker.

9 Diagrammet TrafikkInfo viser hvordan data kommer fra klasse SMS og behandles ved å sendes gjennom den gitte tjeneste bestemt av parameterantallet. De to ulike metodene etterspør de ulike data ved å kalle på klasse Linje. Når data returnerer fra klasse Linje, samles disse og returneres til klasse SMS.

10 Diagrammet Linje viser hvordan data etterspørres fra klasse TrafikkInfo og behandles ved å søke opp i de ulike dataforekomster som eksisterer innenfor de relaterte klassene samt internt i klassen Linje. Først her vil det returneres feil dersom parameter som er sendt inn er ugyldige til tross for at de har korrekt format (sjekket i SMS). Dersom data er gyldig returneres de etterspurte forekomster til klasse TrafikkInfo.

11 Diagrammet Rute viser hvordan data kommer fra klasse Linje og behandles ved å etterspørre avstand i tid til brukers avreisested. Dette gjøres ved å sjekke forekomster i faktiskrute (en tabell over den faktiske rutetiden) og ruteavvik (en tabell over avviket fra ruten/forsinkelser). Data returneres deretter til klasse Linje.

12 Diagrammet Transportmiddel viser hvordan forespørsel om posisjon kommer fra klasse Rute og behandles ved å etterspørre posisjonen som transportmiddelet har rede på selv. Posisjonen returneres deretter til klasse Rute.

13 Konklusjon/avgrensninger : Å designe et system som andre har spesifisert, viste seg å være en krevende oppgave. En del av elementene, f.eks. klassediagram, måtte gjøres mye grundigere i designfasen, og slik sett har nok resultatet endt opp et stykke ifra den originale spesfikasjonen. Vi mener allikevel at vi i vårt design har videre spesifisert og utviklet de originale tjenestene som lå i spesifikasjonen. Vi kunne sikkert ha brukt mer tid på å kommunisere med gruppen som gjorde spesifikasjonen, men både de og vi har hatt mye å gjøre i designfasen, det har derfor ikke vært utstrakt kommunikasjon mellom gruppene.