Trafikanten + Innlevering oblig 1 INF2120 Våren Versjon 1

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

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

INF 2120 Innlevering 1. Gruppe 4. Kravspesifikasjoner til trafikanten +

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle

Universitetet i Oslo Institutt for informatikk. Leveranse 2 - inf2120. Gruppe 9. Mads Andre Bergdal Neeru Bhardwaj Saqib Riaz Trond Arne Sørby

Fra krav til objektdesign

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell (ny versjon) Dagens forelesning. Fra krav til objektdesign

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

Operatørkontroll Kvalitetsmanual - Buss. Ruter AS Versjon: Kvalitetsmanual Buss. Operatørkontroll. Fotograf: Bonanza AS

Eksamen INF5261. Sanntidsinformasjon på holdeplassen

INF 2120-PROSJEKT: <DROP 2 GRUPPE 7> ATLE WANDSVIK DAMIR NADIC SOHAIL AHMED CHAUDRY LARS ANTHONY LAMPAY FOZIA SAEED

Humanware. Trekker Breeze versjon

Vårt system kan kjøres ved å skrive. STUD1 konto fredo 37 (holdeplass)

Operatørkontroll Kvalitetsmanual Buss. Kvalitetsmanual Buss. Versjon 8.0 Februar

Omfang av gåing til holdeplass

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Beskjed fra Skagestein

Produktrapport Gruppe 9

Bilag 1. RUTER MIS ALLE DRIFTSARTER Spørreskjema operatørkontroll og kundeintervjuer. Revidert per Ruter AS, Kvalitet og prosjekt

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

INF2120 Prosjektoppgave i modellering. Del 1

Ruters arbeid med universell utforming:

1.1 Anropsbaserte kollektivtrafikktjenester for alle (AKTA)

Ruters arbeid med UU i publikumsrettede IKT løsninger

SANNTID EN BEDRE BUSS- OPPLEVELSE. nå kommer SANNTID på bussene i Kristiansandsområdet! Sanntidsinformasjonssystem

RUTERS MARKEDSINFORMASJONSSYSTEM OPPDRAGSBESKRIVELSE OPERATØRKONTROLL OG KUNDEINTERVJUER

NB! Endring i undervisningsplanen

Funksjonsbeskrivelse

INF 2120 PROSJEKT: <DROP 3 GRUPPE 7> ATLE WANDSVIK DAMIR NEDIC SOHAIL AHMED CHAUDRY LARS ANTHONY MAPOY FOZIA SAEED

Teknostart prosjekt 2010 for Kommunikasjonsteknologi. Posisjoneringstjenester for mobiltelefon

Sporveiens erfaringer med EK

UKE 11 UML modellering og use case. Gruppetime INF1055

Sanntids informasjonssystem for synshemmede i kollektivtrafikken et skritt nærmere universell utforming

Erik Eiesland

KLASEN OKTOBER KL Seilingsbestemmelsar

UNIVERSITETET I OSLO

Prosjektrettet systemarbeid

Ruters arbeid med UU i publikumsrettede IKT løsninger. Juridisk Rådgiver Svend Wandaas

Løren T -en ny forbindelse. Reisetilfredshet blant reisende ved LørenT banestasjon

Brukerveiledning For Synkronisering Av HotSoft Med PCKasse

Busstjenester Oslo syd Vedlegg 3 Rutebeskrivelse

IT-arkitektur leveransemodell

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

PRINSIPPER FOR RUTEPLANLEGGING Bergen 20. januar Katrine N Kjørstad og Bård Norheim

bedre trafikantinformasjon økt framkommelighet for buss og trikk

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

INF2120 Prosjektoppgaven Våren Et Trafikkoppfølgingssystem. Tjenester. Konkret gjennomføring. (Versjon )

Utvikling fra skallet og inn

Ingen investeringskostnader Ingen risiko Ingen bindinger eller forpliktelser Løpende oversikt over status Enkel håndtering av nye poster

Seilingsbestemmelser. 1. Regler. 2. Betingelser for å delta

Teknisk regelverk for bygging og prosjektering. C-Elektrotekniske anlegg. 5. Publikumsinformasjonsanlegg (PIA-anlegg)

Universell utforming kollektivtrafikk

Installasjonsveiledning. Datek Lysstyring. Versjon 1.3

Prosjektoppgave INF2120 Våren 2007: Rebusløp

Balanserte anskaffelser gjennom dialog Erfaring fra kontraktsoppfølging... Østfold fylkeskommune

DELLEVERANSE 1 INF2120 V06

Brukermanual for. Internettbookingen. Versjon 1.0

Betal kun for resultater slik fungerer affiliate markedsføring

- På Farten - Midttermsrapport

Om informasjonskapsler (cookies) på nettsidene til Stendi

Modellering av krav. INF1050: Systemutvikling 11. februar Universitetslektor Yngve Lindsjørn

Oppgave 1 Multiple Choice

Trafikantenes verdsetting av bedre kvalitet på kollektivtilbudet En Stated Preference-undersøkelse på internett

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

Løsningsforslag til Case. (Analysen)

Norsk olje og gass plan for opplæring. MOB-ba t repetisjonskurs

Ruters billett-app Strategiforum 6. desember Hanne N. Breivik, prosjektleder

Oversikt over forelesningene. Fra analyse til objektdesign. Utfordringen i å lage OO-modeller. Metode for ansvarsdrevet OO. Uke 12: Ansvarsdrevet OO:

Use Case-modellering. INF1050: Gjennomgang, uke 04

Når du registrerer deg for å få tilgang til Tjenestene som arrangør Kontakter oss med forespørsler

Hovedprosjekt i Anvendt Datateknologi Våren 2008 FORSIDE

Enkel veiledning for: GSM key3+

Kollektivassignment i EMMA og VISUM

Konkurransen om rutenettet i Trondheim, Klæbu, Malvik og Melhus

DELLEVERANSE 2 INF2120 GRUPPE 12. Jon G. Berentsen Geir A. Nilsen Lailuma Arezo

Telespor AS Storfemøte Siljan Egil M. Pettersen

Dagens forelesning. o Litt mer om design med UML sekvensdiagrammer. Sentralisert og delegert kontrollstil

DELLEVERANSE 3 INF2120 GRUPPE 12. Jon G. Berentsen Geir A. Nilsen Lailuma Arezo

GPS kurs. Få oversikt over nyttige funksjoner til GPS Lære litt om hvordan de kan brukes Og praktisere litt også

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Testskjema for Contact

NVDB, veibilder og SINUS.infra

Drosjesentralen. I-120: Obligatorisk oppgave 2, 2000

Fergene i Oslo utgjør en naturlig, omenn liten del av Oslos totale trafikkbilde. Båttrafikken i Oslo besørges av to private selskaper:

PRODUKTBESKRIVELSE NRDB. NRDB E-post-portering

Målrettet kollektivtransport Delrapport 2: Trafikantenes preferanser

F.I.F.F.I.G. Fleksibelt og Innovativt system For FakultetsInformasjon og andre Greier

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk

Øving 3: Begrensninger

INF1050 Systemutvikling

«Bruksanvisning» Trafikkagent - appen

INF1050 Systemutvikling

(12) PATENT (19) NO (11) (13) B1 NORGE. (51) Int Cl. Patentstyret

Informasjon om din trådløse forbindelse

BRUKERMANUAL FOR NRDB E-POST-PORTERING

Spesifikasjon av Lag emne. Kursregistrering g bruksmønstermodell. Dagens forelesning. Fra krav til objekter

1. Innholdsfortegnelse

Prosjektoppgave våren 2007

Transkript:

Trafikanten + Innlevering oblig 1 INF2120 Våren 2005 Versjon 1 Gruppe 2: Ingunn Elisabeth Sundal Rønningen <ieronnin@student.matnat.uio.no>, Kjetil Magnus Kristiansen <kjetimk@student.matnat.uio.no>, Sjur Ohldieck Sundin <sjuros@student.matnat.uio.no>, Noushin Mousavi <noushinm@student.matnat.uio.no> Christian Clasen <christian@medicom.no> 1

Innledning Trafikantent+ er et system tiltenkt å gjøre det lett for forbrukere av offentlige kommuniksajonsmidler å få informasjon om deres posisjon til ulike formål. Når kommer neste kommuniksajonsmiddel 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 kommuniksajonsmidler 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 kommuniksajonsmidler. 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 utifra 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 kjenskap 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. 2

Bruksmønsterene: Tre tjenester: -> Annonsering av neste holdeplass ombord i bussen -> Motta informasjon om neste avgang m/kun rute (gps finner ut pos) -> Motta informasjon om neste avgang m/rute og holdeplass 3

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. Bruksmønster 2: Navn: Informasjon om neste avgang med kun rutenr Aktør: Kunde Pre-betingelse: Post-betingelse: 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 Pre-betingelse: Post-betingelse: Trigger: Kunde vil ha informasjon om neste avgang Normal hendelsesflyt: 4

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. 5

Klassediagram Rute Rutenummer Starttid Posisjon * * Holdeplass Holdeplassnavn Posisjon * 0:1 1 Posisjon 1 Kunde posisjon 1 * Kundenr Posisjon 6

7

Sekvensdiagram 1. Finn neste avgang, kun rutenummer sendes som parameter. 8

1.1 Rutesystemet dekomponeres for å vise detaljene 9

1.2Live oversikt over ruter kan ytterligere dekomponeres 10

11

2. Finn neste avgang, rutenummer og holdeplass sendes som parametre 12

2.1Finn neste avgang dekomponert 13

3. Annonser neste holdeplass 14

3.1Annonser neste holdeplass dekomponert 15

Begrensninger Det er vanskelig å anslå nøyaktig hvor ofte posisjoneringssignaler bør sendes for å unngå feil. Basert på at vi ikke vet den korteste avstand mellom to stoppesteder innenfor gjeldende område, verken i distanse eller tid, er dette et anslag som muligens må modereres. 16