Use Case-modellering INF1050: Gjennomgang, uke 04
Kompetansemål Modellering av krav Kunne modellere ulike typer krav UML-diagrammer Innføring i grunnleggende UML-modellering Bruksmønster (use case) Sekvensdiagram Domenemodell Aktivitetsdiagram
Gjennomgang av ukesoppgaver Ukens tema: Modellering av krav og UML-diagrammer
Oppgave 1 Hva er et use case, og hvorfor er det nyttig å lage use cases?
Oppgave 1: Løsningsforslag Hva er et use case, og hvorfor er det nyttig å lage use cases? Use case Beskrivelse av hvordan systemet oppnår et mål av verdi for en aktør Beskriver en komplett funksjonell enhet Redegjør for ulike hendelsesforløp Normal flyt (hovedflyt) og alternativ flyt Kan ses på som en slags historie Use case er testbare
Oppgave 1: Løsningsforslag Hva er et use case, og hvorfor er det nyttig å lage use cases? Nytteverdi: Kommuniserer tydelig - Hva de forskjellige målene til systemet er - Hvem som bruker systemet, og til hva systemet skal brukes - Hvilke andre aktører systemet interagerer med Bestill bord Registrer lånesøknad Endre passord
Oppgave 2 Hva skiller aktører fra interessenter?
Oppgave 2: Løsningsforslag Hva skiller aktører fra interessenter? Definisjon på aktør Samlebetegnelse for å angi alle grupper av personer som anvender systemet, eller øvrige systemer som blir anvendt av systemet Skiller mellom to typer aktører Primæraktører Har et mål av verdi i systemet Sekundæraktører Hjelper primæraktører med å oppnå mål Vanligvis; et annet system man henter / sender informasjon til
Oppgave 2: Løsningsforslag Hva skiller aktører fra interessenter? Definisjon på interessent Samlebetegnelse for alle personer, grupper eller organer, som påvirkes av eller påvirker systemets utvikling / bruk Direkte / indirekte Fire hovedkategorier Kunde De(n) som betaler for at systemet utvikles Leverandør De(n) som leverer produktet Bruker De som bruker systemet Andre / øvrige Andre enheter med interesse i systemet (utvikling / bruk)
Oppgave 2: Løsningsforslag Hva skiller aktører fra interessenter? Skillet mellom aktør og interessent Omhandler: Rolle / tilknytning til bruken og utviklingen av systemet Aktører må være Brukere av systemet Andre systemer som brukes av / bruker systemet Interessenter kan Være brukere av systemet Inkluderer alle som påvirker / påvirkes av systemets kravspesifikasjon og utvikling
Oppgave 3 Hva er en aktør i et use case-diagram og hva er forskjellen på en primær og en sekundær aktør?
Oppgave 3: Løsningsforslag Hva er en aktør i et use case-diagram og hva er forskjellen på en primær og en sekundær aktør? UML-representasjon av aktører Figur: Strekmann Merkelapp: Navn på aktørens rolle Kunde Bank Kontosystem
Oppgave 3: Løsningsforslag Hva er en aktør i et use case-diagram og hva er forskjellen på en primær og en sekundær aktør? Primæraktører Har et mål av verdi i systemet Sette inn penger UML: Kunde setter inn penger Sekundæraktører Realiserer målene til primæraktørene UML: Bank sørger for at pengene blir satt inn Kunde Bank
Oppgave 4 Hva er en domenemodell, og hvorfor er det nyttig å lage en domenemodell for et gitt system?
Oppgave 4: Løsningsforslag Hva er en domenemodell, og hvorfor er det nyttig å lage en domenemodell for et gitt system? UML-klassediagrammer uten metoder Konseptuell modell / abstraksjon Viser objekter knyttet til problemdomenet / problemområdet Representasjon av de ulike objektene et system består av Hensikt: Forstå objektene Oversikt over terminologi
Oppgave 4: Løsningsforslag Hva er en domenemodell, og hvorfor er det nyttig å lage en domenemodell for et gitt system? Domenemodellens nytteverdi Viser informasjon om objekter i use casene Verktøy for å sjekke at use casene er beskrevet på rett detaljnivå Kartlegger hvilke objekter man bør ta hensyn til Kommuniserer at man har forstått domenet / problemområdet Klassene kan brukes til utforming av pre- og postbetingelser for use caset
Oppgave 4: Løsningsforslag Hva er en domenemodell, og hvorfor er det nyttig å lage en domenemodell for et gitt system?
Oppgave 5: Bordbestilling Systemet skal støtte bordreservasjoner og plassering i en restaurant. Kunder kontakter restauranten for å bestille / avbestille bord. En resepsjonist mottar samtalene. Bestillinger legges inn for et bestemt bord sammen med antall personer. For hver bestilling registreres kontaktperson med navn og telefonnummer. Når gjester ankommer, blir de plassert ved sitt bord av hovmesteren, og bestillingen markeres med ankommet. Hvis gjestene plasseres ved et annet bord, registreres dette bordbyttet. Tidspunktet et gitt bort må være ledig igjen kan også registreres. Kunder kan endre bestilling / avbestille på forhånd. Det er mulig å få bord uten å ha bestilt på forhånd, gitt at ledige bord finnes. Når gjester får bord uten å ha bestilt dette, markeres tidspunkt, bord og antall i systemet, men ikke navn og telefonnummer. Når nye bestillinger registreres i systemet, eller eksisterende bestillinger endres, skal skjermbildet umiddelbart oppdateres, slik at ansatte på restauranten alltid har oppdatert informasjon tilgjengelig.
Oppgave 5(a) Finn aktører for systemet
Oppgave 5(a): Løsningsforslag Finn aktører for systemet Aktører: Hvem skal bruke systemet? Resepsjonist - Motta samtaler og håndtere bestillinger Hovmester - Plassere gjester Begge - Se oversikt over bestillinger/plasseringer Felles funksjonalitet? Rollene kan generaliseres til Ansatt
Oppgave 5(a): Løsningsforslag Finn aktører for systemet Generalisering (i programmering) En klasse arver en annen klasses adferd (slik som subklasser) Alle attributter / metoder i foreldreklassen arves av subklassen Generalisering i UML Har objektene (klassene) felles [ ]? Attributter / Egenskaper Hovmester Ansatt Resepsjonist Skal objektene i tillegg ha særegne egenskaper / attributter? Alle resepsjonister er ansatte, men ikke alle ansatte er resepsjonister
Oppgave 5(b) Finn use cases for systemet
Oppgave 5(b): Løsningsforslag Finn use cases for systemet Use case: Hvilke mål har systemet? Hva skal aktørene kunne gjøre? - Funksjonalitet Hvilke resultater vil aktøren oppnå? Identifiser de viktigste oppgavene - Skape / Lagre / Endre / Lese / Slette UML-representasjon av use case Figur: Oval Merkelapp: Navn på use case Verbfrase Bestill bord Registrer drop-inn Bytt bord Registrer ankomst Finn bestilling Vis bestillinger Endre bordbestilling Avbestill bord
Oppgave 5(c) Lag et use case-diagram for systemet
Oppgave 5(c): Løsningsforslag Lag et use case-diagram for systemet Use case-diagram Visualiser forhold mellom aktører og use case Hvem skal gjøre hva? Bestill bord Finn bestilling Bytt bord Registrer drop-inn Vis bestillinger Registrer ankomst Avbestill bord Endre bordbestilling
Oppgave 5(c): Løsningsforslag Lag et use case-diagram for systemet
Oppgave 5(c): Løsningsforslag Lag et use case-diagram for systemet <<include>>-relasjonen Indikerer at et (sub) use case inneholder nødvendig funksjonalitet for gjennomførelsen av et annet basiscase. <<extend>>-relasjonen Utvider oppførselen / funksjonalitet til et basiscase, som utføres under spesielle omstendigheter.
Oppgave 5(c): Løsningsforslag Lag et use case-diagram for systemet
Oppgave 5(d) Anta at kunden kan bestille bord på nett i tillegg til over telefon. Gjør eventuelle endringer i (a), (b) og (c).
Oppgave 5(d): Løsningsforslag Anta at kunden kan bestille bord på nett i tillegg til over telefon. Gjør eventuelle endringer i (a), (b) og (c). Ny aktør Kunde Bestiller bord på nett Nytt use case? Skal man opprette et nytt use case Bestill bord på nett? Skal man beholde Bestill bord? Oppdater use case-diagrammet
Oppgave 5(d): Løsningsforslag Anta at kunden kan bestille bord på nett i tillegg til over telefon. Gjør eventuelle endringer i (a), (b) og (c). Vi definerer en ny aktør
Oppgave 5(d): Løsningsforslag Anta at kunden kan bestille bord på nett i tillegg til over telefon. Gjør eventuelle endringer i (a), (b) og (c). Oppdater diagrammet Nytt use case
Oppgave 5(d): Løsningsforslag Anta at kunden kan bestille bord på nett i tillegg til over telefon. Gjør eventuelle endringer i (a), (b) og (c). Oppdater diagrammet Bruker eksisterende use case
Oppgave 5(e) Lag en enkel domenemodell for systemet
Oppgave 5(e): Løsningsforslag Lag en enkel domenemodell for systemet Domenemodell: Klassediagram uten metoder Hvilke klasser er aktuelle å modellere? Abstraher objekter fra den naturlige verden For hver klasse: Hvilke attributter (variabler) er naturlig å inkludere? Hvilket forhold er det mellom klassene? Én-til-én Mange-til-én Én-til-mange Mange-til-mange
Oppgave 5(e): Løsningsforslag Lag en enkel domenemodell for systemet
Oppgave 6(a) Hva er en tekstlig beskrivelse av et use case?
Oppgave 6(a): Løsningsforslag Hva er en tekstlig beskrivelse av et use case? Detaljert beskrivelse av interaksjon mellom bruker og system Nummerert liste: Interaksjon beskriver steg for steg Tekstlige beskrivelser skal inneholde: Navn på use case Hvilken funksjonalitet dreier det seg om? Prebetingelse(r) Hva skal til for å starte use caset? Postbetingelse(r) Hva skal til for å avslutte use caset? Hovedflyt Hvilke steg inngår i gjennomførelsen av use caset? Alternativ flyt Hvilke steg inntreffer ved avvik i hovedflyten?
Oppgave 6(b) Lag en tekstlig beskrivelse av ett av use casene fra 5b. Husk pre-, postbetingelser og alternativ flyt.
Oppgave 6(b): Løsningsforslag Lag en tekstlig beskrivelse av ett av use casene fra 5b. Husk pre-, postbetingelser og alternativ flyt. Betingelser Hvordan starte og avslutte et use case? Prebetingelse Betingelse som må være på plass før et use case kan utføres Postbetingelse En endring i systemet som skal være på plass etter at et use case er utført
Oppgave 6(b): Løsningsforslag Lag en tekstlig beskrivelse av ett av use casene fra 5b. Husk pre-, postbetingelser og alternativ flyt. Navn: Bestill bord Aktører: Bruker [resepsjonist] Prebetingelse(r): Ingen Postbetingelse(r): Bord reservert på kunde Hovedflyt: 1. Bruker ber systemet om å finne et ledig bor til en gitt tid og dato 2. Systemet returnerer ledig bord 3. Bruker registrerer kundens navn og telefonnummer 4. Systemet lagrer kundens navn og telefonnummer 5. Systemet ber om bekreftelse på reservasjon av bord 6. Kundebehandler bekrefter reservasjon av bord 7. Systemet registrerer reservering av bord på kunde
Oppgave 6(b): Løsningsforslag Lag en tekstlig beskrivelse av ett av use casene fra 5b. Husk pre-, postbetingelser og alternativ flyt. Modellering av alternativ flyt Identifiser avvik i hovedflyten Hva skjer i slike tilfeller? / Hvordan responderer systemet? 1. Bruker ber systemet om å finne et ledig bor til en gitt tid og dato 2. Systemet returnerer ledig bord INGEN LEDIGE BORD 3. Bruker registrerer kundens navn og telefonnummer 4. Systemet lagrer kundens navn og telefonnummer UGYLDIG NAVN / TELEFONNUMMER 5. Systemet ber om bekreftelse på reservasjon av bord 6. Bruker bekrefter reservasjon av bord BRUKER AVKREFTER RESERVASJON 7. Systemet registrerer reservering av bord på kunde
Oppgave 6(b): Løsningsforslag Lag en tekstlig beskrivelse av ett av use casene fra 5b. Husk pre-, postbetingelser og alternativ flyt. Alternativ flyt I, steg 2: Ingen ledige bord A1.1 Systemet finner ingen ledige bord A1.2 Returner til steg 1 i hovedflyten Alternativ flyt II, steg 4: Ugyldig navn / telefonnummer A2.1 Systemet registrerer at oppgitt informasjon er ugyldig A2.2 Returner til steg 3 i hovedflyten
Spørsmål? Ta kontakt Yulai Fjeld ydfjeld @ uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene
Takk til Foilene er basert på Tidligere presentasjoner laget av Emilie Hallgren og Kristin Brænden Eksisterende forelesningsnotater av Dag Sjøberg og Yngve Lindsjørn Sommerville, I. (2010). Software Engineering (9th Edition). Pearson.
Takk for meg Neste uke : UML-modellering: Fra krav til objekter