Trafikanten Pluss, delleveranse 2. Gruppe 8 Eivind Hasle Amundsen [eivinha] og Eigil Moe [eigilmo]

Transkript

1 Trafikanten Pluss, delleveranse 2 Gruppe 8 Eivind Hasle Amundsen [eivinha] og Eigil Moe [eigilmo] 29. april 2005 Innledning I delleveranse 2 har vi jobbet med spesifikasjonene til gruppen vi kritisterte i første runde, altså gruppe 7 og gjort et nytt design. Vi har gjort noen store og noen mindre modifikasjoner/endringer. Flere er gjort i samtale med gruppe 7. På mange måter var vi uenig med hvordan gruppe 7 hadde valgt å løse oppgaven på. Vi har kuttet flere ting som vi mener er urelevant til oppgaven. Etter vår forståelse av selve oppgaven, går dette på hvordan en bruker kan benytte seg av Trafikanten Pluss på best mulig måte. Vi følte at gruppe 7 hadde valgt å konsentrere seg mest om hvordan man kunne administrere systemet på best mulig måte. Sikkert bra. Men det var ikke slik vi oppfattet oppgaven. Vi kuttet disse leddene og konsentrerte oss om brukeren og systemet. Gruppe 7 manglet kvalitetssikring. Vi måtte lese oppgaven deres nøye og et titalls ganger før vi forsto hva de faktisk hadde tenkt og hvor vi skulle starte å jobbe med deres spesifikasjoner. Vi har gått i utgangspunkt deres oppgave og ikke implemetert noen av våre egne spesifikasjoner fra delleveranse 1. Vi syntes det var interessant å sette oss inn i en annen gruppes oppgave å se hvordan de hadde løst dette. Helt fra frustrasjon til å ta tak i oppgaven slik den var fremstilt. Vi endte opp med to stykker på gruppen. Noe som har fungert greit. Mindre kokker, mindre søl. Men dog igjen, mer arbeid per mann. Flere ting, av denne grunn, har kanskje blitt forenklet og kommer ikke like godt frem i forhold til hvordan vi kunne tenke oss oppgaven i sin helhet til slutt.

2 Forutsetninger Vi er sterkt uenig om at brukeren må være eller er registrert for å kunne bruke systemet. Et mobilnummer er unikt, så hva er egentlig da vitsen med å registrere seg på et slikt system som dette? Systemet vil da bli vanskelig for kunden å bruke og ikke minst, du vil sannsynligvis miste store deler av kundegruppen. Mest, tror vi, fordi folk ikke vil bruke ekstra penger på å sende unødige meldinger via sms for å bruke en tjeneste som burde være enkelt å ta i bruk. Et fint utgangspunkt er at man bør tenke seg til hva folk flest klarer og hva folk flest gidder å bruke tid/penger på. Vi har selvfølgelig ikke slettet dette, da det er en del i henhold til deres oppgave. Så dette er beholdt. Oppgaven forutsetter at det finnes et ytre system som håndterer sms og sender dette til TPSystem. TPSystem fungerer som (eller egentlig inneholder) kontrolleren i systemet. Dette gjelder også GPS-systemet som finner kundens posisjon. I tillegg finnes det en database hvor informasjon hentes som ruter, tider og stopper. Innimellom i oppgaven skisserer vi flere forutsetninger. Interressenter Det er passasjer som skal bruke systemet. Administrasjonen bryr vi oss lite om. Revidert domenemodell (klassediagram) Dette klassediagrammet er på domenenivå. Det vil si at klassene ikke er ekte klasser som skal programmeres i for eksempel Java, men konseptuelle klasser som i seg selv vil romme minst én eller flere reelle klasser.

3 Klassen User er i realiteten en mobiltelefon, og befinner seg utenfor applikasjonsområdet vårt. I virkelighetsområdet opptrer den kun som en aktør, dvs. en igangsetter for de ulike bruksmønstrene. SyntaxControl er en del av programmet i seg selv, men den forrige gruppa har valgt å skille denne ut konseptuelt fra resten av systemet, og vi beholder denne fremstillingen. Det samme gjelder klassen UserControl, som strengt tatt kunne ha vært en del av det programmerbare systemet, eller kontrollenhet om man vil. TPSystem er altså vår kontroller. Videre har vi sløyfet klassen RouteStop, da mange til mange-koblinger er helt lovlig. Klassen Route representerer ett transportmiddel n gang, f.eks. linje 5 mot Mortensrud den 4. april 2005 kl. 14:01. Klassen vil derfor kunne få veldig mange objekter. PublicTransport representerer ett fysisk kjøretøy. Vi har her valgt å fjerne subklassene fra delleveranse 1, da vi mener denne inndelingen er helt uvesentlig for vårt prosjekt ikke minst fra det sentrale systemets ståsted. Til sist har vi skissert attributter vi mener befinner seg på et overordnet nivå, og som derfor hører naturlig hjemme i denne reviderte domenemodellen.

4 Eksempel på detaljering Her er et eksempel på hva en av de konseptuelle klassene, nemlig PublicTranport, inneholder (sett i forhold til systemet). Diagrammet representerer applikasjonen. Ser vi på hele interesseområdet, vil klassen også omfatte de faktiske, fysiske transportmidlene. I systemet finnes altså en klasse PTgpslink som sørger for kommunikasjon mellom eksempelvis en fysisk buss og dennes representasjon i systemet. Denne virtuelle representasjonen finnes i klassen PTvirtual. En scheduler sørger for å holde orden på å oppdatere status, lokasjon etc. for alle transportmidlene. Det er altså PTscheduler sitt ansvar å sørge for at alt i den tilhørende klassen PTvirtual er oppdatert. Komposittdiagrammet ovenfor viser hvordan PublicTransport er bygget opp.

5 Sekvensdiagram: sd usetpsystem Det mest generelle sekvensdiagrammet er sd usetpsystem, som beskriver all den overordnede oppførelsen til systemet. Klassene er hentet fra domenemodellen. Også her er utgangspunktet delleveranse 1, men endringene er ganske store. Først og fremst har vi valgt å sløyfe noen bruksmønstre, og dermed er sekvensdiagrammene sd regdelays, sd delaystats og sd manageroutes fjernet helt. Vi har imidlertid valgt å beholde løsningen med at brukere skal registrere seg før det gis tilgang. alt-boksen som sjekker syntaksen er utvidet til å omfatte hele resten av modellen. I tillegg gir TPSystem-klassen direkte tilbakemelding til brukeren i stedet for å gå den noe merkelige omveien til SyntaxControl (husk at TPSystem er en konseptuell klasse som i implementasjonen vil bestå av flere klasser se klassens komposittdiagram for mer informasjon).

6 Sekvensdiagram: sd registeruser Her er det ingen endringer i forhold til delleveranse 1. Klassen UserControl inneholder et register over brukere og deres rettigheter, samt (public) metoder for å oppdatere seg.

7 Sekvensdiagram: sd getroute Dette sekvensdiagrammet manglet nesten totalt fra delleveranse 1, og vi har derfor forsøkt å konstruere kommunikasjon med de allerede eksisterende klassene (selv om det var fristende å lage egne). Diagrammet representerer det mest sentrale bruksmønstret for hele systemet. Først og fremst er det bestandig klassen TPSystem som sender og mottar meldinger. I diagrammet har vi valgt å bruke synkrone meldinger, og samtidig gir vi rom for kun ett alternativt tilfelle nemlig Route not found. Hvert av disse kallene kunne fint hatt sine negative returmeldinger. For å holde det enkelt har vi sett bort fra dette. Klassene PublicTransport og Stop har vi tatt med fordi vi mener det er viktig å hente informasjon om transportmidlers posisjon og status for holdeplasser. Det er viktig å merke seg at dette ikke betyr at virkelige busser og virkelige holdeplasser kontaktes hver gang for å sjekke status. Vi befinner oss som kjent på domenenivå, og det kan derfor være tranportmidlenes og holdestedenes representasjon i systemet som konsulteres, fremfor de fysiske enhetene. Det skilles altså ikke mellom applikasjonsog interesseområder her, og det er heller ikke meningen. Implementasjonsspørsmål venter vi altså med.

8 Tilstandsmaskin: sm SyntaxControl SyntaxControl venter på meldinger fra brukeren (dvs. fra SMS-sentralen). Dersom syntaksen ikke er korrekt, genereres det et svar til brukeren allerede her, dvs. at vi ikke går innom klassen TPSystem, og det er SyntaxControl som meddeler brukeren om feilen. Hvis syntaksen er korrekt, kjøres henvendelsen videre (se sekvensdiagram).

9 Tilstandsmaskin: sm TPSystem TPSystem venter helt til den mottar en syntaktisk korrekt henvendelse fra SyntaxControl. Den kan få tre mulige utfall fra brukerkontrollen: Registrering ikke i orden, bruker ber om registrering TPSystem kaller på registrering og venter til dette er fullført Registrering ikke i orden, bruker ber om ruteopplysninger TPSystem genererer feilmelding og sender til brukeren Registrering i orden, bruker ber om ruteopplysninger TPSystem venter på tilbakemelding fra Route Videre sørger TPSystem for å skaffe de nødvendige opplysninger om ruteinfo, posisjon, forsinkelser og stoppesteder. Dersom vi hadde valgt å bruke flere altbokser i sekvensdiagrammet sd getroute, ville denne tilstandsmaskinen ha sett litt annerledes ut (blant annet er det jo meningsløst å sjekke forsinkelser for en rute som ikke finnes).

10 Tilstandsmaskin: sm UserControl Klassen UserControl venter på forespørsler fra TPSystem. Ved to av utfallene for autorisasjonen, blir klassen inaktiv, og ved det siste tilfellet foretas en registrering (se punktene under sm TPSystem).

11 Tilstandsmaskin: sm Route Klassen Route får forespørsler fra TPSystem og returnerer ruteinfo.

12 Tilstandsmaskin: sm PublicTransport Klassen PublicTransport får forespørsler fra TPSystem og returnerer info om posisjonering.

13 Tilstandsmaskin: sm Delay Klassen Delay får forespørsler fra TPSystem og returnerer info om forsinkelser og tidspunkt.

14 Tilstandsmaskin: sm Stop Klassen Stop får forespørsler fra TPSystem og returnerer info om stoppesteders status.