Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5

Transkript

1 1

2 Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5 FRA LEVERANSE 1 (GRUPPE 2)...5 TILLEGG I FORUTSETNINGER... 5 REVIDERT UTGAVE AV SPESIFIKASJON FRA LEVERANSE BRUKSMØNSTERE...6 MODELL...6 BRUKSMØNSTER 1:... 6 BRUKSMØNSTER 2:... 6 BRUKSMØNSTER 3:... 7 SEKVENSDIAGRAMMER... 8 GENERELLE ENDRINGER I SEKVENSDIAGRAMMENE... 8 SEKVENSDIAGRAM: FINN NESTE TRE AVGANGER MED KUN RUTE...9 KOMMENTARER TIL FINN NESTE TRE AVGANGER MED KUN RUTE... 9 SEKVENSDIAGRAM: FINN NESTE TRE AVGANGER MED RUTE OG HOLDEPLASS KOMMENTARER TIL FINN NESTE TRE AVGANGER MED RUTE OG HOLDEPLASS...10 SEKVENSDIAGRAM: ANNONSER NESTE HOLDEPLASS...11 KOMMENTARER TIL ANNONSER NESTE HOLDEPLASS SEKVENSDIAGRAM: FINN NESTE TRE AVGANGER DEKOMPONERT KOMMENTARER TIL FINN NESTE TRE AVGANGER DEKOMPONERT...12 DESIGNMODELL...13 KLASSEDIAGRAM KOMMENTARER TIL KLASSEDIAGRAM COMPOSITE STRUCTURE DIAGRAM KOMMENTARER TIL COMPOSITE STRUCTURE DIAGRAM...15 COLLABORATION DIAGRAM KOMMENTARER TIL COLLABORATION DIAGRAM...16 TILSTANDSMASKINER KOMMENTARER TIL TILSTANDSDIAGRAMMENE TILSTANDSMASKIN: TRAFIKANTEN KOMMENTAR TIL TILSTANDSMASKIN: TRAFIKANTEN TILSTANDSMASKIN: SYSTEM KOMMENTAR TIL TILSTANDSMASKIN: SYSTEM TILSTANDSMASKIN: BRUKERSESJON...17 KOMMENTAR TIL TILSTANDSMASKIN: BRUKERSESJON TILSTANDSMASKIN: POSISJON...17 KOMMENTAR TIL TILSTANDSMASKIN: POSISJON...18 TILSTANDSMASKIN: RUTEDYNAMISK

3 KOMMENTAR TIL TILSTANDSMASKIN: RUTEDYNAMISK TILSTANDSMASKIN: RUTESTATISK KOMMENTAR TIL TILSTANDSMASKIN: RUTESTATISK...19 TILSTANDSMASKIN: HOLDEPLASS...19 KOMMENTAR TIL TILSTANDSMASKIN: HOLDEPLASS

4 Revisjonsoversikt Tabell over de forskjellige versjonene Versjon Primær forfatter Beskrivelse av versjon Ferdigstilt (dato) 1. (Utkast) Espenol Satte sammen dokumentet (Utkast) Espenol Oppdatering av modeller/kommentarer (Utkast) Espenol Litt småoppdateringer (Ferdig) Alle Ferdig leveranse

5 Introduksjon med forutsetninger Fra leveranse 1 (gruppe 2) Trafikanten+ er et system tiltenkt å gjøre det lett for forbrukere av offentlige kommunikasjonsmidler å få informasjon om deres posisjon til ulike formål. Når kommer neste kommunikasjonsmiddel til mitt avreisested? Hva er neste stoppested for kommunikasjonsmiddelet jeg befinner meg på? Systemet tar utgangspunkt i en kontekst tilsvarende Oslo Sporveier, som opererer med tre ulike offentlige kommunikasjonsmidler i rutetrafikk: buss, trikk og t-bane. Oslo Sporveier innehar 72 trikker, 350 busser og anslagsvis 70 t-banetog. Selv om ikke alle disse er ute samtidig (trikker er på det meste 52 i aktiv drift samtidig), så kan man likevel legge opp til at systemet skal takle kontinuerlig behandling av minimum 500 kommunikasjonsmidler. Hvert kommunikasjonsmiddel har utstyr til å sende posisjonsdata samt identifikasjonsdata, og kan motta data som trigger annonsering av stoppesteder. Systemet er plassert på en eller flere sentrale servere. Det er snakk om et system som skal motta signaler fra hvert enkelt aktive kommunikasjonsmiddel hvert 5. sekund, og man kan ut i fra det anslå at databasen må takle minimum 6000 transaksjoner pr minutt, eller et snitt på 100 transaksjoner pr sekund. Det forutsettes at databasen har timestamp. Det forutsettes at kundene besitter mobil enhet som kommuniserer over GSM-nettet, da forespørsler til systemet går via SMS. Disse tjenestene forutsettes som kjent gjennom markedsføring, og kunden forventes dermed å ha kjennskap til hva som er korrekt syntaks for å kunne benytte tjenesten. Systemet forventes å sende automatisk rettledning dersom det mottar forespørsel i feil format/syntaks. Systemet er ruteavhengig, hvilket vil si at det forutsettes at så vel kunde som kommunikasjonsmiddel benytter ruteidentifikasjon/rutenummer som parameter når data sendes til systemet. En forutsetning er derfor at kunden kjenner navn på avreisested, så vel som rutenummer. Tillegg i forutsetninger Vi syntes en melding hvert 5. sekund er litt i overkant av hva som er nødvendig. Derfor har vi bestemt at kjøretøyene sender en melding hvert 30. sekund. Det er likevel uklart hvordan disse oppdateringene skal skje når vi implementerer systemet. 5

6 Revidert utgave av spesifikasjon fra leveranse 1 Her følger modellene vi har oppdatert fra gruppe 2s leveranse. Bruksmønstere Modell Bruksmønster 1: Navn: Annonsering av neste holdeplass: Aktør: Transportmiddelet Pre-betingelse: Systemet og transportmiddelet er koblet opp mot hverandre Post-betingelse: Trigger: Transportmiddel er langt nok unna en holdeplass Normal hendelsesflyt: Transportmiddel sender ut signal om posisjon, rute og retning. Systemet mottar og kontrollerer avstand til neste stoppested. Gitt avstand trigger et kall fra systemet til transportmiddelet. Neste stoppested annonseres korrekt i transportmiddelet. 6

7 Bruksmønster 2: Navn: Informasjon om neste avgang med kun rutenr Aktør: Kunde Trigger: Kunde vil ha informasjon om neste avgang. Normal hendelsesflyt: Kunde sender forespørsel til systemet med ønsket rutenr Systemet sender opplysninger om neste transportmiddel som ikke har passert stoppestedet som er nærmest kunden. Variasjoner: 1: Kundens meldingsformat er feil, får tilbakemelding om dette. 2: Om siste avgang er gått, får kunden beskjed om dette. Bruksmønster 3: Navn: Informasjon om neste avgang med holdeplass og rutenr: Aktør: Kunde Trigger: Kunde vil ha informasjon om neste avgang Normal hendelsesflyt: Kunde sender forespørsel til systemet med ønsket rutenr og holdeplass Systemet sender opplysninger om neste transportmiddel som ikke har passert stoppestedet. Variasjoner: 1: Kundens meldingsformat er feil, får tilbakemelding om dette. 2: Siste avgang er gått, kunden får beskjed om dette. 7

8 Sekvensdiagrammer Generelle endringer i sekvensdiagrammene Vi syntes at gruppe 2 har for mange sekvensdiagrammene (7 stykker, litt unødvendig og overflødig) hvor de f.eks. hadde dekomponert RuteSystem i flere sekvensdiagrammene, ref: sd RuteSystem dekomponert i sekvensdiagram finnnesteavgang og AnnonserNesteHoldePlass. Derfor har vi kun konstruert sekvensdiagrammer i utgangspunkt ut fra de use-casene de (og vi) hadde, et for hver av tjenester. En annen grunn er at gruppe 2 brukte ting som ikke er inneholdt/modellert i klassediagrammet, f.eks. splittet de klassen Rute i rutesystem, ruteinfo, rutetabell, liveoversiktruter, statiskrutetabell osv. Dette førte til at det ble uforståelig med de sekvensdiagrammene de tegnet. Man ble usikker på hva de mente Rute egentlig gjøre, hvorfor de brukte Rute slik? For å gjøre det lettere for andre tittere å skjønne hva Rute gjør, har vi splittet klasse Rute i to klasser: RuteDynamisk (den har oversikt over hvor alle busser/trikker/t-baner er til enhver tid) og RuteStatisk (den har oversikt over alle faste rutetider). Begge disse to klassene har vi brukt hele veien i sekvensdiagrammene våre. Det samme gjelder Bruker, System, BrukerSesjon, Posisjon, og Holdeplass. Det var et viktig punkt syntes vi: Sekvendiagrammene og Klassediagram må ha en sammenheng med hverandre. I tillegg har vi lagt til assert for brukersesjonen (noe som gruppe 2 ikke hadde) som sier timeout etter 5 minutter, alt informasjon om en Bruker som posisjon og mobilnummer blir da slettet. 8

9 Sekvensdiagram: finn neste tre avganger med kun rute Kommentarer til finn neste tre avganger med kun rute Først mottar systemet en melding fra brukeren. Systemet finner så brukerens posisjon ved å bruke mobilnummeret. Deretter opprettes et objekt med informasjon om brukeren. Denne returnerer en autmatisk generert ID. Deretter sjekkes det om rutenr eksisterer. Negativ okstatus under denne prosessen gir en informativ tilbakemelding til brukeren. Videre sendes et kall til RuteDynamisk og RuteStatisk for å finne de neste 3 avgangene. Til slutt returneres resultatet og sesjonen slettes. 9

10 Sekvensdiagram: finn neste tre avganger med rute og holdeplass Kommentarer til finn neste tre avganger med rute og holdeplass Bruker sender først en melding til systemet. Systemet oppretter deretter en brukersesjon som lagre informasjon om brukeren og den aktuelle spørringen. Denne returnerer en automatisk generert ID som anonymiserer brukeren. Etter dette sender systemet kall på RuteStatisk og Holdeplass sopm sjekker om oppgitt rutenr og holdeplass eksisterer. Negativ okstatus på noe sted under denne prosessen gir en informerende feilmelding tilbake til brukeren. Nå finner systemet de neste tre avgangene gjennom kall til RuteDynamisk og RuteStatisk. Til slutt returneres resultatet og informasjonen om brukeren slettes. Dersom dette ikke er gjort etter 5 minutter pga. f.eks. systemfeil eller andre ting slettes brukeren autmatisk. 10

11 Sekvensdiagram: annonser neste holdeplass Kommentarer til annonser neste holdeplass Hvert 30. sekund sender hvert enkelt aktivt transportmiddel en melding til systemet om ID, posisjon, rute og retning. Systemet oppretter så et objekt med info om transportmiddelet. Denne returnerer en ID. Deretter sender info om posisjon til RuteDynamisk som har en oversikt over posisjoner for alle transportmiddler. Etter dette finner systemet neste holdeplass' posisjon ved et kall til Holdeplass. Hvis avstanden til neste holdeplass er rett, så sendes en beskjed tilbake til transportmiddelet om at den skal spille av en bestemt lydbeskjed (F.eks. "Neste holdeplass er..."). Deretter slettes objektet som har informasjon om denne sesjonen. Dersom denne prosessen tar mer enn 30 sekunder slettes brukersesjonsobjektet automatisk. Dette er for å hindre en opphoping av gamle, ubrukte objekter. 11

12 Sekvensdiagram: finn neste tre avganger dekomponert Kommentarer til finn neste tre avganger dekomponert Systemet prøver først å finne de tre neste avgangene i RuteDynamisk (uavhengig av retning). Hvis det ikke er flere aktive transportmiddler kaller systemet RuteStatisk, som har en oversikt over den statisk rutetabellen, og finner de neste avgangene som ikke har begynt å gå enda (F.eks. dagen etter). 12

13 Designmodell Klassediagram 13

14 Kommentarer til klassediagram I tillegg de fire klassediagrammene som gruppe 2 hadde (Rute, Holdeplass, Posisjon og Kunde) har vi lagt til noen andre klasser i vårt klassediagram for å få vårt Trafikkoppfølgingssystem til å fungere bedre. Som dere ser så har vi prøvd å lage et overordnet klassediagram hvor vi har prøvd å modellere klassene som senere skal programmeres, og pga. det har vi lagt til metoder (i kontrast til gruppe 2), i hver av de klassene. Disse metodene er da i samsvar med sekvensdiagrammene, mens klassene finner man igjen i composite structure diagrammet. Vi har hele tiden prøvd å få knyttet klassediagram, sekvensdiagrammene, composite structure og state machine sammen slik at de har en sammenheng med hverandre. I stedet for klassen Kunde har vi kalt vår klasse for Bruker, mens klasser som Holdeplass og Posisjon har vi gjenbrukt fra gruppe 2 sitt prosjekt. Når det gjelder Rute har vi splittet den opp i to deler: RuteDynamisk (den har oversikt over hvor alle busser/trikker/tbaner er til enhver tid) og RuteStatisk (den har oversikt over alle faste rutetider). I tillegg oppretter vi objekter av BrukerSesjon som lagrer nødvendige informasjoner til en bruker for eksempel brukers posisjon og mobilnummer. Den viktigste klassen i vårt system er klassen System (vi har lagt til i vårt system siden vi syntes den er nødvendig og hensiktmessig å ha med), hvor Bruker, BrukerSesjon, Holdeplass, Posisjon, RuteDynamisk og RuteStatisk har en enkel assosiasjon med System. Når en bruker sender inn en forespørsel om en eller annen informasjon forespørselen til System. System tar da kontakt direkte med de andre klassene for å de nødvendige informasjoner (alt avhengig hva slags informasjoner en bruker trenger), for eksempel sender System en forespørsel om å finne neste holdeplass til Holdeplass for å få den informasjonen og Holdeplass returnerer da en melding til System og fra System igjen får bruker svaret. Mer om dette kommer vi tilbake til i sekvensdiagrammene. Klassen System har derfor 1..* assosiasjoner med alle de andre klassene, mens ingen av disse andre klassene har relasjoner til hverandre, alt ting må skje gjennom/ved hjelp av System. 14

15 Composite structure diagram Kommentarer til composite structure diagram Vår komposittstruktur diagram er i samsvar med sekvensdiagrammene og klassediagrammet. Komposittstruktur diagrammet viser hvem de ulike objektene har tilgang til. Bruker er ikke en del av systemet, siden Bruker bare sender en forespørsel og mottar en tilbakemelding fra System. Bruker kan for eksempel ikke kommunisere direkte med Posisjon eller Holdeplass, derfor må Bruker få hjelp av System. Vårt system kan behandle flere meldinger samtidig ved hjelp av BrukerSesjon. System er hovedelement som kommuniserer med de andre elementene. Alt skjer derfor ved hjelp av System. 15

16 Collaboration diagram Kommentarer til collaboration diagram Collaboration diagrammet viser forhold mellom alle elementene som arbeider sammen i Systemets kontekst. System er det viktigste elementet som har direkte forhold med alle de andre elementene gjennom portene, fordi System kontakter de andre elementer for å få nødvendig informasjon, mens ingen av de andre elementene har direkte forhold med hverandre. 16

17 Tilstandsmaskiner Kommentarer til tilstandsdiagrammene I utgangspunktet har vi valgt å konstruere et tilstandsdiagram (med simple state) for hver av delene i Composite Structure diagrammet, og et overordnet tilstandsdiagram for hele Trafikkantens systemet. Under følger tilstandsmaskinene med kommentarer. Tilstandsmaskin: Trafikanten Kommentar til tilstandsmaskin: Trafikanten Dette er tilstandsdiagrammet for hele vårt system. Her har vi lagt opp en tilstand som er Idle slik at i kan behandle mange brukere på en gang. Systemet venter på å motta noe å gjøre, når den f.eks blir bedt om å utføre sjekkeholdeplass() gjør den det og går tilbake til ventetilstand, slik kan systemet vårt hele tiden være klar for å motta kall fra flere brukere. 17

18 Tilstandsmaskin: System Kommentar til tilstandsmaskin: System System utfører beregnavstand() samt at den mottar melding fra Bruker, sender metodekall og tilslutt returnerer melding tilbake til Bruker. 18

19 Tilstandsmaskin: Brukersesjon Kommentar til tilstandsmaskin: Brukersesjon Brukersesjon sjekker først syntaksen på meldingen. Hvis syntaksen er ok, genererer den en ID for denne brukeren og deretter opprettes en sesjon og bevarer denne til systemet er ferdig med denne brukere. Dersom syntaksen er feil, returnerer den en feilmelding og objektet slettes. 19

20 Tilstandsmaskin: Posisjon Kommentar til tilstandsmaskin: Posisjon Fra initial state blir metoden finnposisjon() kalt. I tilstanden posisjon funnet har posisjonen blitt beregnet. Deretter returnerer den posisjonen og objektet slettes. 20

21 Tilstandsmaskin: RuteDynamisk Kommentar til tilstandsmaskin: RuteDynamisk Fra rutedynamisk blir det enten kalt på finnneste3avg() eller oppdaterdynamisk(). Dersom kallet var finnneste3avg() blir det returnert de 3 neste avganger. Mens Dynamisk Rutetabell blir oppdatert hvis kallet var oppdaterdynamisk(). 21

22 Tilstandsmaskin: RuteStatisk Kommentar til tilstandsmaskin: RuteStatisk Tilstanden venter utfører metoder som sjekkomrutenreksisterer() / sjekkomholdeplasseksisterer() eller finnnesteavgangstatisk(). Etterpå blir informasjon returnert. 22

23 Tilstandsmaskin: Holdeplass Kommentar til tilstandsmaskin: Holdeplass Første tilstand oppstår når Holdeplass mottar et kall. Denne tilstanden er venter hvor den enten kaller på finnnærmesteholdeplass() eller finnnesteholdeplass(). Når den har utført den/de metodene den skal, returnerer den holdeplassen og objektet slettes. 23