INF 2120 drop 3. Trafikanten plus. Group 4. danielmw, ronnieo, naimaa, arep, andeba

Transkript

1 INF 2120 drop 3 Trafikanten plus Group 4 danielmw, ronnieo, naimaa, arep, andeba

2 Index INF 2120 drop Index... 2 Introduksjon med forutsetninger... 3 Endringer i designmodeller fra drop 2:... 3 Composite structure diagram... 3 Tilstandsmaskin NySession... 5 Tilstandsmaskin getstation... 6 Implementasjon... 7 a. Her beskrives de implementasjonsvalg man har foretatt... 7 b. Dokumentasjon på databasedesignen... 8 Appendix A: Java koden (på toppen av JavaFrame)... 8 Appendix B: Java-implementasjonen leveres også i et format som er lett kjørbart... 9 (.jar eller.zip)... 9 Appendix C: Databaseimplementasjonen... 9

3 Introduksjon med forutsetninger Vi har kun implementert tjeneste 2, finne nærmeste stasjon i forhold til brukeren. Dette fordi vi ikke har hatt tid til å implementere begge tjenestene som vi har modellert. JavaFrame ga oss større utfordringer enn hva vi hadde forventet, vi prioriterte derfor å få et kjørbart system, fremfor å ha to halvferdige tjenester. Endringer i designmodeller fra drop 2: Composite structure diagram Figur 1, CS System fra designet i drop 2

4 Figur 2, System fra drop 3 Ved å sammenligne figur 1 med figur 2, ser man at componentene; Station, Transport og Route, ikke har blitt implementert inn i systemet Trafikanten_plus. Dette har vi gjort p.g.a. at informasjonen om holdeplassene ligger i den eksterne databasen, noe som gjør at vi ikke trenger egne componenter/klasser for det, og at vi ikke bruker informasjonen om transportmidlene og rutene i den tjenesten vi har implementert.

5 Tilstandsmaskin NySession Figur 3, NySession fra designet i drop 2 Figur 4, NySession fra drop 3

6 I figur 4sammenlignet med figur 3, ser vi at vi har lagt til tilstanden wait. Tilstanden er bare en idletilstand, hvor vi står å venter på å få inn en SMS fra brukeren. Når meldingen kommer sjekker den formatet, og sender en outputmelding til riktig tjeneste, før den går over til den tilhørende tilstanden. Tilstandsmaskin getstation Figur 5, tilstandsmaskin getstation fra drop 2

7 Figur 6, getstationsimple fra drop 3 I figur 6, sammenlignet med figur 5, ser vi at tilstanden wait SMS er fjernet. Denne tilstanden er den samme som vi la til I figur 4. Vi har med andre ord flyttet tilstanden ett hakk ut. I tilegg er tilstanden Station byttet ut med et choicepoint. Implementasjon a. Her beskrives de implementasjonsvalg man har foretatt. Systemet har 4 hovedkompnenter; PATS, Trafikant_plus, TpCsnySession og Tp_db. Den eneste komponenten som ikke står i en Idle tilsstand er TpCsnySession. Når vi får inn en melding fra PATS, kommer den inn gjennom en mediator til Trafikant_plus. Meldingen blir derfra sendt gjennom en mediator til TpCsnySession. Her sjekkes formatet på meldingen, og hvis formatet tilsier det, sendes det ut en position request til PATS, før vi går over i den korrekte tilstanden. (getstation, da vi ikke har implementert den adre tjenesten getschedule enda). Hvis formatet er feil returneres det en feilmelding til bruker. I tilstanden get Station står vi og venter til vi får posisjonene til bruker fra PATS. Deretter sender tilstanden en request til databasen, med brukers posisjon, og går over til neste tilstand; waitlocation2. Output requesten som går til databasen inneholder en ferdig formatert SQLspørring som regner ut nærmeste holdeplass i forhold til brukerens posisjon. Svaret fra SQLspørringen blir sendt som input til waitlocation2, som igjen sender svar til brukeren, og går tilbake til idle tilstanden wait, hvor den venter på ny SMS. Hvis spørringen skulle feile, vil det også bli sendt ut en melding til brukeren med denne informasjonen. Og systemet går så tilbake til idle.

8 b. Dokumentasjon på databasedesignen ID hpnr st retning Pos Navn patsl Trafikantx patsb Trafikanty Figur 7, E/R diagramm over databasen ID - er den unike id en til hver holdeplass, og primærnøkkel for tabellen. Hpnr unikt nummer for hver holdeplass. St antall ruter som stopper ved holdplassen. Navn holdplassens navn. Trafikantx holdplassens lengdegrad. (i trafikantens system) Trafikanty holdeplassens breddegrad (i trafikantens system) Patsb holdeplassens breddegrad. (i PATS system) Patsl holdeplassens lengdegrad. (i PATS system) Retning viser rutens retning. (1 for helsfyr->nydalen, 2 for nydalen->helsfyr Appendix A: Java koden (på toppen av JavaFrame) Tp_db.java TpCSgetSchedule.java TpCSgetStation.java TPCSnySession.java TpnySession.java

9 TpSMgetSchedule.java TpSMgetStation.java TpSMnySession.java Trafikanten_plus.java Appendix B: Java-implementasjonen leveres også i et format som er lett kjørbart (.jar eller.zip) Trafikanten_plus..zip Appendix C: Databaseimplementasjonen Tabell.sql