Inlupp 2: Användningsfall (use cases)

• Inlämning senast onsdag 23 juni kl 09:00.
• Lämnas in skriftligen i elektronisk version (pdf, doc, rtf, txt), via e-post till adressen: . Obs, döp filen till inlupp1_DittNamn .
• Rapportens omfattning: motsvarande 1 – 5 A4-sidor exklusive framsida.
• Ditt namn, e-postadress och vilken uppgift det handlar om ska tydligt framgå i rapporten.
• Handledning: Lektionen torsdag 17/6 kl 10-12 (rum 1113) ägnas åt övning i att skriva användningsfall och handledning på uppgiften. Övrig handledning, Stefan Blomkvist, .
• Frågor och svar diskuteras förhoppningsvis i kursens epostarkiv/FAQ

2a. Självscanning i butik

Uppgift 2a handlar om användningsfall (use cases) som en metod att beskriva hur ett system ska fungera.
I många butiker kan kunderna själv skanna in sina varor. I stora drag ska systemet fungera enligt följande: Alla varor har en läsbar prisetikett som kan läsas in av kunderna med hjälp av någon apparat. Efter inköpen ska kunderna kunna betala utan att varorna behöver slås in i en kassaapparat. Vi ger inte fler detaljer än så om systemet eftersom hur självscanningen ska beskrivas med användningsfall är en del av uppgiften. Systemet behöver inte fungera exakt som hos er lokala stormarknad. Redovisa era antaganden.

Beskriv:

• minst två olika aktörer (användarroller/roles) och
• minst tre olika användningsfall (use cases) för systemet.

Utgå ifrån att det kan finnas olika aktörer som använder systemet på olika sätt och med olika villkor. Beskriv aktörerna respektive användningsfallet och dess förutsättningar på en rimlig nivå för att hålla den samlade dokumentationen mellan 1 och 5 sidor. Användningsfallen ska beskrivas i textform, ni behöver inte göra en grafisk representation (UML-diagram). Användningsfallen ska vara ”vanliga” användningsfall (även kallat system eller formal use case), inte ”essential use cases” (eller business use case).

2b. Reflektion kring användningsfall (AF)

Skriv ned dina reflektioner över följande frågor:

• Vad beskriver dina AF egentligen?
• Vad beskriver AF om användbarhet hos systemet?
• När i systemutvecklingsprocessen är det lämpligt att skriva AF? Vem bör skriva dem?
• Vilka tror du förstår dina AF? Användare, programmerare, MDI-experter etc.? Vilka bör förstå den?
• Är formen som AF är skrivna på bra eller dålig? Finns det bättre sätt?

Länksidan innehållet en del information som kan vara intressant.

Resurser

• Föreläsning 6.
• Handledning på övning/lektion 2.
• Gulliksen & Göransson kap 8.7.
• Länkar om AF, se länksidan.

Ett exempel: Bankomat

Aktören Bankkund kan använda en uttagsautomat för att ta ut pengar,
överföra pengar eller kontrollera saldo. Dessa egenskaper kan
representeras som en mängd användningsfall (AF):

• AF1: Ta ut pengar
• AF2: Överföra pengar
• AF3: Kontrollera saldo

Varje AF representerar något som systemet gör och som innebär ett värde
för bankens kund, dvs aktören Kund. Tillsammans utgör AFen alla möjliga
sätt att använda systemet. Namnet på ett AF uttrycker vanligtvis det
värde som AF ger aktören.

Händelseförlopp

Händelseförloppet beskriver sekvensen av händelser mellan aktören och
systemet. Det skrivs i naturligt på en enkel, konsekvent form och med
en termer från problemdomänen.

Exempel på händelseförlopp för AF 1 "Ta ut pengar"

1. AF börjar när kunden för in ett kort i automaten. Systemet läser och
kontrollerar informationen på kortet.

2. Systemet (S) frågar efter PIN-koden och slår in koden. S verifierar
koden.

3. S frågar vad kunden vill göra. Kunden väljer "uttag".

4. S ber om ett belopp. Kunden slår in beloppet.

5. S ber om en kontotyp. Kunden väljer kontotyp (check, spar eller
kreditkonto).

6. S kommunicerar med bankens nätverk för att kontrollera kontonr,
PIN-kod och om beloppet finns på kontot.

7. S frågar om kunden vill ha ett kvitto. Detta steg utförs bara om det
finns papper för att skriva ut.

8. S ber kunden ta kortet. Kunden tar kortet. (Detta är en
säkerhetsåtgärd för att kunderna inte ska glömma sina kort i automaten).

9. S lämnar ut det begärda beloppet i sedlar.

10. S skriver ett kvitto om så begärts och AF avslutas.

När man använder fullständiga händelsesekvenser för att beskriva vad
systemet gör förstår man snabbt att det finns många olika
händelseförlopp - olika vägar genom AFet. Olika värden och resultat
produceras och man måste ta hänsyn till alternativa förgreningar och
olika fall (scenarier). AFens händelseförlopp tillsammans beskriver alla
dessa möjliga vägar.

Exemplet ovan är taget från boken "The Rational Unified Process - en
introduktion (svenska utgåvan)", av P. Kruchten, 2 utg, 2002.

Några tips och exempel från förra årets kurs (delvis samma uppgift men för ett annat system). Uppgiften och kommentarerna.

Tillbaka till kursens huvudsida