Løsningsforslag til Case. (Analysen)

Transkript

1 Løsningsforslag til Case (Analysen)

2 Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen ikke er fullstendig. Oppstart Vi må prøve å få avklart de viktigste kravene til systemet som skal lages. Jeg legger her vekt på de funksjonelle kravene som jeg vil utrykke ved hjelp av use case. Dessuten vil jeg lage en Domenemodell, system seksvensdiagram, kontrakter og ordbok som støtte til å forstå hva systemet skal gjøre. Aller først må vi forsøke å oppsummere/avklare det som kan trekkes ut av formuleringen av case et. Hvis dette var et virkelig prosjekt, kunne vi ha snakket med aktuelle brukere og en oppdragsgiver. Men i dette tilfeller får vi gjøre egne forutsetninger. Et hjelpemiddel som er brukt er ruteheftet til Trondheim Trafikkselskap (nå Team). Det å studere eksisterende dokumentasjon er en av de ting man kan gjøre i arbeidet med å forstå problemområdet og dets terminologi. Sentrale begreper og sammenhenger som er funnet i ruteheftet er nedfelt i ordboken og domenemodellen. Skjermbildet må betraktes som et eksempel på hvordan brukergrensesnittet kan se ut. Det er ment som en hjelp til å belyse det som egentlig er det primære nemlig funksjonaliteten. Det man kan trekke ut er at systemet skal gjøre det mulig for en som skal reise med buss å få presentert en reiserute med angivelse av nærmeste holdeplass, avgangstider og reisens varighet, å få presentert en tidtabell for en gitt linje eller alle linjer til et trafikkselskap. Det er opp til de som skal designe systemet å utforme et godt brukergrensesnitt for innlesning og presentasjon av data. Use case Det er generelt flere måter å oppdage use case på. Jeg velger oppskriften til Larman:. Avgrensning av systemet. Det som skal utvikles er programvare. I utgangspunktet skal programvaren kunne kjøres fra personlige datamaskiner. Men alle nødvendige opplysninger om linjer, holdeplasser, traséer og avgangstider skal finnes i en sentral database. I første omgang vil vi se bort fra detaljene rundt denne databasen og se den som eksternt til systemet som skal utvikles. På sikt ser vi for oss at programmet også skal kunne kjøres fra mobiltelefon (wap) og PDA. 2. Identifiser aktører. Det er ikke vanskelig her å finne en primær aktør. Det er den som skal reise. Vi kaller aktøren Reisende. Vi ser også umiddelbart en støtteaktør (supporting actor) i databasesystemet med all relevant informasjon. Slik informasjon er den vi finner i et rutehefte. Derfor kaller vi denne aktøren Rutehefte.

3 3. Primære aktørers hensikt (goal) med systemet. Den primære aktør ønsker å oppnå to ting ved bruk av systemet, å finne en reiserute og få presentert en eller flere tidtabeller. 4. Definer use case for hvert behov. 3 leder til to use case, FinnReiserute og FinnTidtabell. Diagrammet som følger her viser use case modellen. FinnReiserute <<Actor>> Rutehefte Reisende FinnTidtabell Legg merke til at vi bruker to forskjellige symboler for aktører. For primære aktører som normalt vil være mennesker, bruker vi symbolet til venstre. Støtteaktører som ofte er andre systemer fremstiller med klassesymbol med stereotypen <<Avtor>>. For øvrig er det vanlig å plassere primære aktører til venstre og støtteaktører til høyre. Domenemodellen Andre navn for denne modellen er problemdomenemodell eller konseptuell modell. Den lages for å få frem viktige begreper og sammenhenger i problemområdet (domenet). I UML fremstilles modellen som en klassemodell hvor klassene representerer objekter i den virkelige verden. Assosiasjonene viser relasjoner mellom disse objektene. Det er altså ikke programvareklasser vi finner i denne modellen. Men det ligger i objektorienteringens ånd at vi vil finne igjen de samme navnene på klasser i programvaren. Kandidater til klasser i domenemodellen er funnet ved å studere teksten i Case et, ordboken, use case og ruteheftet. Vi har ikke funnet det nødvendig å bruke en kategoriliste. En sjekk mot kategorilisten viser at de konsepter vi har funnet, er dekket av kategorilisten. Assosiasjonene er også funnet mer ved intuisjon enn med utgangspunkt i en kategoriliste for assosiasjoner. Men også assosiasjonene faller inn under kategoriene i kategorilisten. Noen eksempler: Linje er en logisk del av en reiserute. Holdeplasser er logisk knyttet til linjer. Neste figur viser den domenemodellen vi har kommet frem til. 2

4 for på og avstigning nærmeste..* Reiserute inneholder Linje - Varighet - linjeid - FørsteAvgang : Tidspunkt 0..*..* - Type - NesteAvgang : Tidspunkt har * beskrives i Reise Sted * Bestemmelsessted foregår med har Avreisested..* følger Trase består av Strekning - Navn har har....*..* Avgang - Avgangstid kan ha skjer fra har er i nærheten av * Holdeplass - Navn terminal er oppført i er oppført i..*.. Note 0..* 2 Tidtabell.. kan ha Passering - Passeringstid Passeringstid angis i minutter etter avgang fra terminal. Det normale er at en holdeplass har en passeringstid oppført i en tidtabell. Derfor assosiasjonsklasse. Unntak kan forekomme og er angitt i Note. Av denne modellen trekker vi ut disse hovedpunktene: Reiserute har kunnskap om reisens varighet og avgangstidspunkter. En reiserute er assosiert med holdeplasser for på og avstigninger. Reiserute er også assosiert med en eller flere Linje. Reise er beskrevet i en Reiserute og starter på et Sted og slutter på et Sted. En Linje følger en Trasé som igjen består av Strekninger. En Linje har flere Holdeplasser. Linje er også assosiert med tidtabeller. For å få frem at en bestemt tidtabell inneholder avgangstider for en bestemt linje, har vi introdusert konseptet Avgang i assosiasjonen mellom Linje og Tidtabell. Vi kan ikke gjøre Avgang til en assosiasjonsklasse fordi hver instans av Linje og Tidtabell er assosiert med mange avganger. Avgang er assosiert med Holdeplass ved at avganger skjer fra en holdeplass som er terminal. Det får vi frem ved at Holdeplass har rollen terminal i denne sammenheng. I en bestemt tidtabell er de enkelte holdeplasser for en linje oppført en gang med ett passeringstidspunkt. Dette er ikke en egenskap ved en holdeplass eller tidtabell, men knyttet til assosiasjonen mellom en holdeplass og en tidtabell. Derfor har vi introdusert assosiasjonsklassen Passering. Enkelte har lett for å begynne å tenke programvareklasser og hvordan assosiasjoner skal realiseres i koden når de ser domenemodellen. Det skal man ikke. For som Larman skriver Domenemodellen er en visuell ordbok som inneholder ord og konsepter fra problemdomenet og som kan inspirere oss når vi skal navngi ting under design av programvaren. Det bidrar til å redusere et av gapene i forståelse av problem og programvare. 3

5 Mer analyse Fullstendig essensiell use case Use case UC: Finn reiserute Primær aktør: Reisende Støtteaktør: Rutehefte. Representerer en database med nødvendig informasjon til å finne reiseruter. Andre interessenter: Trafikkselskaper: Ønsker å bedre servicen til sine reisende Prebetingelse: Ingen spesielle. Postbetingelse: En reiserute er funnet og presentert. Hovedflyt av hendelser:. Systemet er klart til å lage reiserute. 2. Reisende legger inn avreisested. 3. Systemet ber om bestemmelsessted. 4. Reisende legger inn bestemmelsessted. 5. Systemet presenterer en reiserute med informasjon om linje som skal brukes, nærmeste holdeplass ved avreisested, nærmeste holdeplass ved bestemmelsessted, første avgangstid, neste avgangstid, reisens varighet og eventuelle overganger og holdeplasser for disse. 6. Systemet er klart for å motta nytt avreisested. Alternativ flyt: *a. Reisende kan når som helst avslutte programmet. 2a, 4a. Ugyldige steder:. Systemet gir melding om at sted enten er skrevet feil eller ikke finnes. 2. Reisende korrigerer sted. Spesielle krav: Svartid fra bestemmelsessted er lagt inn til reiserute presenteres skal ikke overstige 2 sekunder i 90% av tiden. Teknologi: a. Systemet skal kunne kjøre på hjemme PC er med Windows 95, Windows NT 4.0 og nyere versjoner som er kommersielt tilgjengelige pr første halvår 200. b. Systemet skal kunne kjøre på datamaskiner som kjører Linux operativsystem. c. Systemet skal kunne kjøre på Apple datamaskiner. Bruksfrekvens: Nærmest kontinuerlig. Uavklarte spørsmål: Om systemet skal kjøres på mobiltelefoner (WAP). Om systemet skal kjøres på PDA er. 4

6 Use case UC2: Finn tidtabell Primær aktør: Reisende Støtteaktør: Rutehefte. Representerer en database med nødvendig informasjon til å finne tidtabeller. Andre interessenter: Trafikkselskaper: Ønsker å bedre servicen til sine reisende Prebetingelse: Ingen spesielle. Postbetingelse: En eller alle tidtabeller er funnet og presentert. Hovedflyt av hendelser:. Systemet er klart til å motta kommando fra reisende. 2. Reisende legger inn kommando. Kommando gjelder presentasjon av tidtabell for en bestemt linje eller tidtabell for alle linjer. 3. Systemet presenterer en eller alle tidtabeller. 4. Systemet er klart til å motta ny kommando. Alternativ flyt: *a. Reisende kan når som helst avslutte programmet. *b. Alle inndata skal sjekkes for gyldighet og reisende gis adgang til å korrigere data. 2a. Ugyldig kommando:. Systemet gir melding om at kommando er feil. 2. Reisende korrigerer kommando. 2b. Kommando gjelder en bestemt linje:. Systemet ber om aktuell linje. 2. Reisende legger inn aktuell linje. 3a. En linje:. Systemet presenterer tidtabell for aktuell linje. 3b. Alle linjer:. Systemet presenterer tidtabeller for alle linjer. Spesielle krav: Svartid fra data er lagt inn til systemet starter å presentere tidtabeller skal ikke overstige 2 sekunder i 90% av tiden. Teknologi: d. Systemet skal kunne kjøre på hjemme PC er med Windows 95, Windows NT 4.0 og nyere versjoner som er kommersielt tilgjengelige pr første halvår 200. e. Systemet skal kunne kjøre på datamaskiner som kjører Linux operativsystem. f. Systemet skal kunne kjøre på Apple datamaskiner. Bruksfrekvens: Nærmest kontinuerlig. Uavklarte spørsmål: Om systemet skal kjøres på mobiltelefoner (WAP). Om systemet skal kjøres på PDA er. 5

7 System sekvensdiagrammer Finn Reiserute : System Systemet er klart til å lage reiserute : Reisende lagreiserute() Reisende setter avreisested settavreisested(avreisested) Reisende setter bestemmelsessted settbestemmelsessted(bestemmelsessted) presenterreiserute( ) Systemet presenterer reiserute reiserute Dette burde vært en stiplet linje for å markere retur fra systemet. Denne versjon av verktøyet har ikke den muligheten. Finn tidtabell 6

8 : System Sytemet er klart til å lage tidtabeller : Reisende lagtidtabell() Reisende legger inn kommando leskommando(kommando) Systemet presenterer tidtabell tidtabell presenteres Dette burde vært en stiplet linje for å markere retur fra systemet. Denne versjon av verktøyet har ikke den muligheten. 7

9 Kontrakter Kontrakter kan lages for systemoperasjoner i kompliserte use case som et element til økt forståelse. I vårt relativt enkel system er ikke dette strengt talt nødvendig. Vi tar med noen her som eksempler på hvordan kontrakter ser ut. Kontrakter for Finn Reiserute Kontrakt KO: lagreiserute Operasjon: lagreiserute( ) Kryssreferanse: Use case: Finn Reiserute Prebetingelse: Ingen spesiell Postbetingelse: En Reiserute ble laget (instans ble kreert) Kontrakt KO2: settavreisested Operasjon: settavreisested( avreisested : Sted ) Kryssreferanse: Use case: Finn Reiserute Prebetingelse: Ingen spesiell Postbetingelse: Et avreisested ble laget (instans kreert) Et avreisested ble assosiert med Reiserute (assosiasjon etablert) Kontrakt KO3: settbestemmelsessted Operasjon: settbestemmelsessted( bestemmelsessted : Sted ) Kryssreferanse: Use case: Finn Reiserute Prebetingelse: Ingen spesiell Postbetingelse: Et bestemmelsessted ble laget (instans kreert) Et bestemmelsessted ble assosiert med Reiserute (assosiasjon etablert) Kontrakt KO4: presenterreiserute Operasjon: presenterreiserute( ) Kryssreferanse: Use case: Finn Reiserute Prebetingelse: Ingen spesiell Postbetingelse: En instans av Holdeplass, avreiseholdeplass, ble laget (instans kreert) En instans av Holdeplass, bestemmelsesholdeplass, ble laget (instans kreert) En instans av Linje, linje, ble laget (instans kreert) En instans av Tidtabell, tidtabell, ble laget (instans kreert) En instans av Avgang, avgang, ble laget (instans kreert) avreiseholdeplass ble assosiert med en Reiserute (assosiasjon etablert) bestemmelsesholdeplass ble assosiert med en Reiserute (assosiasjon etablert) linje ble assosiert med en Reiserute (assosiasjon etablert) avgang ble assosiert med linje (assosiasjon etablert) tidtabell ble assosiert med avgang (assosiasjon etablert) Tidspunkt for første avgang ble funnet (attributt modifisert) Tidspunkt for neste avgang ble funnet (attributt modifisert) Reisens varighet ble funnet (attributt modifisert) 8

10 En instans av Holdeplass, overgangsholdeplass, ble eventuelt laget og assosiert med en Reiserute (instans kreert og assosiasjon etablert) En instans av Linje, overgangslinje, ble eventuelt laget og assosiert med en Reiserute (instans kreert og assosiasjon etablert). 9