0) Hva er UML?
Unified Modeling Language
1) Hva er et use case (bruksmønster), og hvorfor er det nyttig å lage use cases?
FERDIG
Unified Modeling Language
1) Hva er et use case (bruksmønster), og hvorfor er det nyttig å lage use cases?
Et use case er beskrivelsen av hvordan systemet oppnår et mål av verdi for en aktør. Det er nyttig å bruke use case diagrammer av flere grunner: 1) hva de forskjellige målene til systemet er 2) hvem som bruker systemet til hva 3) hvilke andre aktører systemet går via.
I forige post gikk jeg igjennom krav og kravspesifikasjon. Krav er som sagt viktig for hele prosjektet. Kommunikasjonen mellom oppdragsgiver og leverandør, planlegging og oppfølging, arkitektur, design og test, og å støtte vidreutvikling og vedlikhold. I tilegg til dette skal et krav være: forståelig, testbare og sporbare.
2) Hva skiller aktører fra interessenter?
Interessenter er grupper som har direkte eller indirekte påvirkning eller som blir påvirket av systemets utvikling/bruk. De påvirker eller blir påvirket av kravspesifikasjonen til systemet. En aktør representerer en rolle som et menneske eller et annet system når det kommuniserer med dette systemet. En aktør kommuniserer med systemet gjennom et eller flere use case.
3) Hva er en aktør i et use case diagram, og hva er forskjellen på en primær og sekundær aktør?
En primæraktør har et mål av verdi i systemet mens en sekundæraktør er en aktør som systemet går via for å oppnå et mål av verdi. I eksemplet over er både søker og lånekonsulent primæraktører som har egne mål, de setter i gang use case som oppfyller deres mål. Kredittbyrå og kontosystem er sekundæraktører. Sekundære aktører har ikke egne mål (et kontosystem har ikke i seg selv et eget mål) men de er nødvendige for å realisere målene til de primære aktørene (man kan ikke få lån uten et kontosystem, tror jeg)
Hvordan finner man aktører?
- Gjennom workshops (brainstorming)
- Fra tekstlige krav
- Blant prosjektets interessenter
4) Hva er en domenemodell, og hvorfor er det nyttig å lage en domenemodell for et gitt system?
En domenemodell er en representasjon av de ulike objektene et system består av. Det er nyttig å benytte domenemodeller av flere grunner:
- Kartlegging av hvilke objekter man bør ta hensyn til
- Kommunisere at man har fortsått domenet
5) Bordreserveringssytem for en restaurant
Krav:
- Kunden kontakter resepsjonist, på tlf eller ved oppmøte for å bestille/avbestille bord
- Bestillinger legges inn for et bestemt bord med antall gjester, kontaktperson og tlfnummer
- Bestillingen markeres som ankommet når gjestene kommer
- Bordendringer registreres på bestillingen
- Drop-in registreres, men uten kontaktperson og tlfnummmer
I forige post gikk jeg igjennom krav og kravspesifikasjon. Krav er som sagt viktig for hele prosjektet. Kommunikasjonen mellom oppdragsgiver og leverandør, planlegging og oppfølging, arkitektur, design og test, og å støtte vidreutvikling og vedlikhold. I tilegg til dette skal et krav være: forståelig, testbare og sporbare.
2) Hva skiller aktører fra interessenter?
Interessenter er grupper som har direkte eller indirekte påvirkning eller som blir påvirket av systemets utvikling/bruk. De påvirker eller blir påvirket av kravspesifikasjonen til systemet. En aktør representerer en rolle som et menneske eller et annet system når det kommuniserer med dette systemet. En aktør kommuniserer med systemet gjennom et eller flere use case.
3) Hva er en aktør i et use case diagram, og hva er forskjellen på en primær og sekundær aktør?
En primæraktør har et mål av verdi i systemet mens en sekundæraktør er en aktør som systemet går via for å oppnå et mål av verdi. I eksemplet over er både søker og lånekonsulent primæraktører som har egne mål, de setter i gang use case som oppfyller deres mål. Kredittbyrå og kontosystem er sekundæraktører. Sekundære aktører har ikke egne mål (et kontosystem har ikke i seg selv et eget mål) men de er nødvendige for å realisere målene til de primære aktørene (man kan ikke få lån uten et kontosystem, tror jeg)
Hvordan finner man aktører?
- Gjennom workshops (brainstorming)
- Fra tekstlige krav
- Blant prosjektets interessenter
4) Hva er en domenemodell, og hvorfor er det nyttig å lage en domenemodell for et gitt system?
En domenemodell er en representasjon av de ulike objektene et system består av. Det er nyttig å benytte domenemodeller av flere grunner:
- Kartlegging av hvilke objekter man bør ta hensyn til
- Kommunisere at man har fortsått domenet
5) Bordreserveringssytem for en restaurant
Krav:
- Kunden kontakter resepsjonist, på tlf eller ved oppmøte for å bestille/avbestille bord
- Bestillinger legges inn for et bestemt bord med antall gjester, kontaktperson og tlfnummer
- Bestillingen markeres som ankommet når gjestene kommer
- Bordendringer registreres på bestillingen
- Drop-in registreres, men uten kontaktperson og tlfnummmer
Finn aktørene for systemet:
For å finne aktørene må vi finne ut hvem som skal bruke systemet. Dette systemet har følgende aktører: resepsjonist og hovmester (ansatte).
Finn Use Cases for systemet (bruksmønster)
- For å finne use cases må man lete etter ulike mål i systemet.
- Disse målene knyttes så opp mot hva aktørene ønsker å kunne gjøre i systemet. I resturantscenario vil dette være de ulike use casene:
Lag et use case diagram for systemet
Nå som både aktørene og use caset er redgjort gjenstår det å sette det sammen til et use case diagram. Det kan se slik ut:
Her er de ulike aktørene og bruksmønsteret knyttet mot hverandre.
Include-relasjonen: Et use case kan være ett flere andre use case.
To eller flere use cases kan ha en felles del (noen like steg). Denne delen kan da legges ut i et eget use case som disse use casene kan inkludere.
To eller flere use cases kan ha en felles del (noen like steg). Denne delen kan da legges ut i et eget use case som disse use casene kan inkludere.
Exstend-relasjonen: Et use case som beskriver tilleggsoppførsel kan utføres under gitte omstendigheter. Alternativ oppførsel som utføres i noen tilfeller kan skrives som eget use case som utvider (extends) et annet. Extenduse case beskriver hvordan oppnå et tilleggsresultat
Om man så får i oppgave på eksamen om å legge til noe, f.eks at en kunde skal kunne bestille bord over telefon og nett må man gjøre eventuelle modifikasjoner i alle oppgavene.
Vi vil få en ekstra aktør: KUNDE.
Om man så får i oppgave på eksamen om å legge til noe, f.eks at en kunde skal kunne bestille bord over telefon og nett må man gjøre eventuelle modifikasjoner i alle oppgavene.
Vi vil få en ekstra aktør: KUNDE.
Vi vil få et ekstra use case: BESTILL BORD PÅ NETT
Og vi vil få en ekstra del i use case diagrammet: KUNDE - BESTILLE BORD PÅ NETT
5E) På eksamen kan man også få spørsmål om å lage enkle domenemodeller.
En domenemodell er en representasjon av de ulike objektene et system består av. Og en domenemodell for nevnt oppgave kan dermed se slik ut:
En domenemodell er et UML klassediagram uten metoder. De ulike tallene (1, 1...*, 0...*) representerer at f.eks det er 1 resutrant, men det kan være 0 eller flere bordbestillinger, 1 eller flere bord osv.
5D) Gi en tekstlig beskrivelse av et use case
En tekstlig beskrivelse av et use case tar for seg interaksjonen som foregår mellom systemet og bruker. Denne beskrives steg for steg og innholder:
- Aktør
- Prebetingelser (en betingelse som skal være på plass før et use case kan utføres)
- Postbetingelser (en endring i systemet som skal være på plass etter at et use case er utført)
- Hovedflyt
- Alternativ flyt
Den kan se slik ut:
Navn: Bestill bord
Aktør(er): Resepsjonist
Prebetingelser: Ingen
Postbetingelser: Bord er reservert på kunde
Hovedflyt:
1. Kundebehandler ber systemet om å finne et ledig bord til gitt dato og tid
2. Systemet finner ledig bord
3. Kundebehandler registrerer kundens navn, telefonnummer og adresse
4. Systemet lagrer kundens navn, telefonnummer og adresse
5. Systemet ber om bekreftelse på reservering av bord
6. Kundebehandler bekrefter reservering av bord
7. Systemet registrerer reservasjon av bord på kunde.
Alternativ flyt:
1. Systemet finner ingen ledige bord
2. Returnerer til hovedflyt, steg 1.
FERDIG
Hva vil det si å generalisere i programmering?
- En klasse (objekt) arver en annens klasses atferd, slik som subklasser
- Alle attributter og metoder til klasse A arves til klasse B.
Ingen kommentarer:
Legg inn en kommentar