Del - leveranse Del 2 Inf 2120 fredag 29.4 Gruppe 1 Knut Johannes Dahle AV Catrine Myhre (catrinem@ifi.uio.no) Mehdi Zare (mehdiz@ifi.uio.no) Odd Christer Brovig (oddcb@ifi.uio.no) Christer Aas (chrisva@ifi.uio.no) Pål Vermund Knudsen (paalvk@ifi.uio.no)
Innholdsfortegnelse: Introduksjon... 3 Revidert spesifikasjon... 3 Use case diagrammer... 4 Use case fra spesifikasjon... 4 Use case fra design... 4 Klassediagrammer... 6 Klassediagram fra spesifikasjon... 6 Klassediagram fra design... 7 Beskrivelse av systemflyten... 8 Sekvensdiagrammer... 9 Sekvensdiagram fra spesifikasjon... 9 Sekvensdiagrammer fra design... 10 Sekvensdiagram behandlesms... 11 Sekvensdiagram Sesjon... 12 Sekvensdiagram FinnStoppMedNavn... 13 Sekvensdiagram FinnStoppMedPosisjon... 13 Beskrivelse av systemet med tilstands maskiner... 15 Tilstandsmaskin Overordnet... 15 Tilstandsmaskin Kontroll... 16 Tilstandsmaskin Sesjon... 17 Tilstandsmaskin Stopp... 18 Tilstandsmaskin Rutetabell... 19 Collaboration diagram... 20 Composite structure... 21
Introduksjon Trafikanten+ skal være et datasystem for både trafikkansatte og for brukere. Vi har lagt vår hovedvekt på brukere og deres ønsker. Det vi ønsker å oppnå med systemet, er at det skal bli enklere for brukere av kollektivtransport å finne rett transport til rett tidspunkt. Med dette har vi tenkt oss et system som ved at brukeren taster ønsket destinasjon ved å sende en sms, skal få i retur nærmeste transport i forhold til den posisjonen som brukeren automatisk har gitt fra seg ved at han/hun sender en sms. Vi ser også for oss at ved eventuell forsinkelse av transport, vil brukeren få oppgitt dette i samme melding. Vi forutsetter imidlertid at det som er nødvendig av utstyr som ligger utenfor vårt område i systemet fungerer som det skal. Dette er komponenter som brukers mobiltelefon, telenettet, PATS og databaser. Revidert spesifikasjon I første innlevering skulle man lage en spesifikasjon så nøye at den gruppa som skulle ta over prosjektet, ville forstå hvordan de hadde sett for seg at trafikksystemet skulle fungere sett fra utsiden. Etter å ha tatt over prosjektoppgaven til en annen gruppe har vi hatt møter med denne gruppa og fått tillatelse til å foretat noen endringer i spesifikasjonen. Fordi vi har en oppfatning av hvordan et trafikksystem bør designes for å virke i praksis, har vi sett oss nødt til å endre på en del på ting i oppgaven vi fikk overlevert. Det har også blitt noen endringer i forhold til hvordan oppgaven ble gitt, og de endringer som er gitt underveis i kurset. Vi har valgt å skrive oppgaven på norsk og derfor er noen navn blitt endret av naturlig årsak.
Use case diagrammer Use case fra spesifikasjon Viser gammelt use-case diagram med fire brukervalg, slik vi fikk det overlevert. Use case fra design
Dette use-case diagrammet viser den tjenesten vi har valgt å jobbe med, siden vi regner med at dette vil være en populær tjeneste blant brukere. Vi har valgt å avskjære oppgaven fra fire til et use-case, da vi mener det er viktig å få til en funksjon som fungerer stabilt, da oppgaven krever mye arbeid. Eventuelt kan man legge til flere tjenester ved en senere anledning hvis dette er ønskelig.
Klassediagrammer Klassediagram fra spesifikasjon Det gamle klassediagrammet fra gruppe 6 innholder en transportklasse og en rute som vi har valgt å fase ut fra den nåværende modellen. Grunnen til dette er at vi har fått ny informasjon om hvordan kommunikasjonen vil foregå med eksterne komponenter og disse komponentene vil da innholde disse klassene eller de data disse klassene representerer.
Klassediagram fra design Dette viser nytt klassediagram. Vi valgt å legge til en klasse og endre på noen av de allerede eksisterende klassene for å få en flyt som fungerer i programmet og for å tilpasse det usecaset vi har valgt. De nye klassen er sesjon som måtte legges til for å håndtere flerbrukerscenario. Vi har også Statisk database og Dynamisk database som kommuniserer med databasekomponentene som er gitt i oppgaven. Slik det gamle klassediagrammet var, synes vi det så vanskelig ut å kunne utføre oppgaven tilfredsstillende. Det var mangelfullt når det gjaldt hvilke attributter og metoder som utførte oppgaver. Det som dreide seg om oppslag om rutetider var kun til dels beskrevet i det gamle diagrammet. Dette var grunnet mangel på informasjon om hva vi kan forvente oss av utenforliggende systemer vi skal kommunisere med.
Beskrivelse av systemflyten En melding kommer inn fra brukeren og blir sendt direkte til PATS (som ligger utenfor vårt system). Denne meldingen blir så sendt til en Kontroll(-klasse) som tar seg av meldingen, hvor den blir behandlet. Etter å ha vært igjennom Kontroll har meldingen to veier å gå, avhengig av om meldingen er ny eller ikke. Er den ny opprettes et nytt Sesjonsobjekt med innsatte verdier fra brukerens melding. Fra Sesjonsobjekt går meldingen til Stopp for å sjekke destinasjonsnavnet, og gir feilmelding med eventuelle feil som oppstår underveis. Om destinasjonsnavnet er riktig vil Sesjonsobjektet sende melding til PATS for å hente ut koordinater. Når meldingen så kommer tilbake fra PATS er det kontroll som mottar denne og sette inn riktige verdier i det gitte Sesjons-objektet (identifisert av id fra PATS). Deretter blir tilstanden til Sesjons-objektet gjenopptatt der den slapp (melding til PATS). Sesjon står deretter ansvarlig for å hente ut navnet på avreisested fra Stopp basert på koordinatene det fikk fra PATS. Om det finnes et stoppested på angitte, eller nær nok, gitte koordinater vil avreise, stoppested og tid bli oversendt Rutetabell som deretter vil finne første rute mellom avreise og destinasjon, hvilket den gjør ved å slå opp i Dyndatabase og Statdatabase som slår opp i Stopp og Avganger igjen for å finne riktig stopp og avganger for transport (dette skal ligge i en database også utenfor vårt system). Modeller som viser denne flyten finner du beskrevet i denne rapporten som sekvensdiagrammer og tilstandsmaksiner.
Sekvensdiagrammer Sekvensdiagram fra spesifikasjon Viser gammelt sekvens diagram for det use-caset vi har valgt å jobbe med. Dette diagrammet viser kun deler av det gruppe 6 hadde tenkt for sin funksjonalitet, men de valgte selv å vente med å beskrive disse delene før det var gitt i oppgaven.
Sekvensdiagrammer fra design Sekvensdiagram overordnet Viser sekvensdiagram som er overordnet i figuren over. Diagrammet er nokså selvforklarende, men viser interaksjon mellom brukers mobil, via PATS / gsmsystem til det systemet vi implementerer. Vi har designet stort sett hele sekvensdiagrammet på nytt, da vi det var kommet en hel del nye utenforliggende komponenter i systemet.
Sekvensdiagram behandlesms Viser sekvensdiagram behandlesms, som illustrerer hva som skjer fra meldingen kommer fra Pats og blir sendt til Pats i retur etter å ha funnet navn på stopp og posisjon. Her er sesjon den sentrale lifeline. Det er den som styrer flyten pr. sesjon og det er beskrevet flyten i div. ref. i diagrammet.
Sekvensdiagram Sesjon Viser sekvensdiagram sesjon. Hvis sesjon finnes fra før blir koordinatene gitt det eksisterende sesjonsobjektet. Hvis dette objektet ikke finnes så lages et nytt.
Sekvensdiagram FinnStoppMedNavn viser sekvensdiagram FinnStoppNavn Sekvensdiagram FinnStoppMedPosisjon Viser sekvensdiagram FinnStoppMedPosisjon
Sekvensdiagram FinnReiseRute Viser sekvensdiagram FinnReiserute. Denne illustrerer hva som skjer når man skal finne best mulig reiserute ut ifra de rutene man har tilgjenglig i databasen.
Beskrivelse av systemet med tilstands maskiner Forklaring: Sign er signalet som sendt mellom tilstander og tilstandsmaskiner. Detaljert systemflyt finnes under Beskrivelse av systemflyten i rapporten. Tilstandsmaskin Overordnet Viser overordnet tilstansdiagram som viser hvordan maskinene henger sammen.
Tilstandsmaskin Kontroll Viser Tilstandsmaskinenen Kontroll. Tar imot nye innkommende meldinger fra PATS, og setter inn koordinater i et nytt eller eksisterende sesjonsobjekt.
Tilstandsmaskin Sesjon Viser Tilstandsmaskinenen som behandler forespørsel. Detaljert systemflyt finnes under Beskrivelse av systemflyten i rapporten.
Tilstandsmaskin Stopp Viser TilstandsmaskinMed Stopp, som illustrerer hva som skjer når man skal finne et stopp. Detaljert systemflyt finnes under Beskrivelse av systemflyten i rapporten.
Tilstandsmaskin Rutetabell Viser Tilstandsmaskin Rutetabell som illustrerer hvordan man finner best mulig rute for brukeren. Viser hvordan den finner mulige ruter i databasen og finner beste rute fra dette. Detaljert systemflyt finnes under Beskrivelse av systemflyten i rapporten.
Collaboration diagram Viser collaboration diagrammet for systemet som viser interaksjonen mellom trafikanten og de andre utforliggende systemene den kommuniserer med.
Composite structure Viser Composite Structure av trafikanten systemet som er dekomponert av collaboration diagrammet. Portene vil gjenspeile kommunikasjonen mellom komponentene i tilstandsmaskinen og sekvensdiagram.