T 3.1 definisanje zahteva koriscenjem use case dijagrama

Definisanje zahteva korišćenjem Use Case dijagramaAnaliza i specifikacija informacionih sistema

dr Zoran Jeremić[email protected]

1

Sadržaj

Uvod

Use Case dijagrami

Pisanje slučajeva upotrebe

Povezivanje slučajeva upotrebe

Uputstvo za definisanje efektivnih slučajeva upotrebe

2Uvod | Dijagrami | Pisanje | Povezivanje | Uputstvo

Proces razvoja sistema

3

Faza Aktivnost Izlaz

Započinjanje Utvrđivanje poslovnih potreba Biznis dokumenta

Analiza Intervjuisanje stejkholdera, istraživanje sistemskog okruženja

Organizovana dokumentacija

Specifikacija Analiza inženjerskih aspekata sistema, definisanje koncepata sistema

Logički model sistema

Implementacija Programiranje, testiranje jedinica, integrisanje, dokumentovanje

Proverljiv sistem

Testiranje & Integracija

Integrisanje svih komponenti, verifikacija, validacija, instalacija, obuka

Resultati testiranja, funkcionalan sistem

Održavanje Popravljanje bagova, modifikacije, adaptacija Verzije sistema

Uvod | Dijagrami | Pisanje | Povezivanje | Uputstvo

Izvori zahteva

Početni zahtevi dolaze od korisnika, preko: Dokumenta, kao što su RFI/RFP Sastanci, izveštaji

Detaljniji zahtevi dolaze od analitičara, nakon studiranja: Domena i cene Izvodljivosti (tehničke, organizacione itd) Prototipovi

Konačni zahtevi se ustaljuju kroz iterativni proces.


Zahtevi vs. dizajn

Zahtevi: Šta sistem treba da radi Abstraktnije

Dizajn: Kako sistem treba da radi nešto Više detalja


Tipovi zahteva

Vidljivi funkcionalni zahtevi “Sistem će korisniku dati gotovinu” “Gotovina će se dati korisniku nakon što se izvadi kartica”

Kvalitativni zahtevi “Proces autorizacije ne sme da traje duže od 1 sekunde” “Korisnički interfejs treba da bude jednostavan”

Skriveni zahtevi “Proces održavanja baze podataka

će se odvijati svake noći”

6

Kvalitativnizahtevi

Skrivenifunkcionalni

zahtevi

Vidljivi funkcionalni

zahtevi


Sadržaj

Uvod

Use Case dijagrami





Slučajevi upotrebe

Slučaj upotrebe je prikaz interakcije između sistema i učesnika.

Puni model slučajeva upotrebe se sastoji iz: Dijagrama – opisuje relacije između slučajeva upotrebe i

učesnika. Dokumenta koji detaljno opisuje svaki slučaj upotrebe.

8

Use Case

Slučaj upotrebe u dijagramu Slučaj upotrebe u tekstuUčesnik


Cilj

Kreiranje polu-formalnog modela funkcionalnih zahteva

Analiza i definisanje: Domena Spoljašnjih interfejsa Scenarija i reakcija


Šta čini dobru specifikaciju slučajeva upotrebe?

Nepostojanje dvosmislenosti Svaki zahtev mora biti interpretiran na jedinstven način.

Kompletnost Moraju zadovoljiti sve trenutne zahteve sistema.

Konzistentnost Zahtevi ne smeju biti u konfliktu jedan sa drugim. Ukoliko

konflikti postoje, moraju se pronaći ustupci.

Izbegavaju dizajn Zahtevi treba da iskažu potrebu, a ne da daju odgovor na nju.

(Zašto?)


Slučajevi upotrebe kao sredstvo komunikacije

Slučaj upotrebe treba da stimuliše diskusiju o tome štasistem treba da radi, uglavnom sa ljudima koji su van razvojnog tima.

11

Kupci Dizajneri Korisnici


Jednostavan primer: Bolnički informacioni sistem

12

Učesnik

Slučaj upotrebe

Granice sistema

Asocijacija

Pronalaženje učesnika

Spoljašnji objekti koji proizvode/koriste podatke: Moraju služiti kao izvor i odredište podataka Moraju biti van sistema

13

Ljudi Mašine Spoljašnji sistemi Senzori

Baze podatakaŠtampačOrganizacione jediniceUvod | Dijagrami | Pisanje | Povezivanje | Uputstvo

Example

Učesnici mogu biti generalizovani

Dete učesnik nasleđuje sve asocijacije slučaja upotrebe

14

Treba koristiti ako (i samo ako), specifični učesnik ima više odgovornosti od generalizovanog (tj.,povezan je sa više slučajeva upotrebe)


Sadržaj

Uvod

Use Case dijagrami





Struktura specifikacije slučaja upotrebe

16

Ime

Učesnici

Preduslovi

Posledice

Uspešni scenario

Alternativni tokovi

Okidač


Okidači (triggers)

Šta aktivira slučaj upotrebe?

Primeri: Korisnik podnosi zahtev Korisnik ubacuje karticu Sistemsko vreme je 10:00


Preduslovi

Koje uslove je potrebno da sistem ispuni pre započinjanja slučaja upotrebe.

Primeri: Korisnikov račun postoji Korisnik ima dovoljno novca na svom računu Postoji dovoljno prostora na disku


Posledice

Posledice predstavljaju rezultat realizovanog slučaja upotrebe. Primeri:

Novac je prenet sa korisnikovog računa Korisnik je ulogovan Fajl je sačuvan na hard disk

Minimalne garancije Minimalna stvar koju sistem može obećati, čak i kada se

slučaj upotrebe nije uspešno realizovao. Primeri: Novac nije prenet dok autorizaciju nije odobrio

korisnik Uspešne garancije

Šta se dešava nakon uspešnog izvršenja slučaja upotrebe. Primeri: Fajl je sačuvan; Novac je prenet


Uspešni scenario

Uspešni scenario je glavna nit priče slučaja upotrebe

Napisan je pod pretpostavkom da je sve u redu, da nije došlo do grešaka ili problema, i vodi direktno ka željenom ishodu slučaja upotrebe

Sastavljen je od niza akcionih koraka

Primeri:

20

1. Korisnik unosi ime proizvoda, šifru i opis2. Sistem proverava šifru proizvoda3. Sistem dodaje proizvod u bazu podataka i šalje poruku potvrde

Korak interakcije

Korak validacije

Korak unutrašnje promene

(dodatni) korak interakcije


Primer uspešnog scenarija

1. Korisnik unosi ključnu reč2. Sistem prikazuje skup rezultata pretraživanja i

sponzorisane proizvode, pri čemu svaki obuhvata ime, kratak opis i cenu

3. Korisnik bira proizvod4. Sistem prikazuje stranu proizvoda koja obuhvata

informacije o proizvodu, prikaz i slične proizvode5. Korisnik dodaje proizvod na šoping listu


Uputstvo za efektivno pisanje

Koristite jednostavnu gramatiku

Samo jedna strana (sistem ili učesnik) radi nešto u jednom koraku

Pišite sa ciljne tačke gledišta Loše: “Uzmi količinu od korisnika i daj

mu novac”

Bilo koji korak mora voditi do nekog progresa Loše: “Korisnik potvrdi na enter dugme”

22

Sistem UčesnikUčesnik traži novac

Sistem pita za količinu

Učesnik unosi količinu

Sistem daje novac


Koraci – nastavak

Grane: Ukoliko korisnik ima više od 10 000 $ na svom računu, sistem

mu prikazuje listu reklama U suprotnom…

Ponavljanja:1. Korisnik unosi ime artikla koji želi da kupi2. Sistem prikazuje stavke3. Korisnik bira stavke koje želi da kupi4. Sistem dodaje stavke na šoping listu5. Korisnik ponavlja korake 1-4 sve dok ne prijavi da je

završio


Slučajevi upotrebe – najčešće greške

Suviše složeni dijagrami

Nema sistema

Nema učesnika

Previše detalja o korisničkom interfejsu “Korisnik unosi username i password, klikne OK ili pritisne Enter”

Vrlo malo bitnih detalja Korisnik obezbeđuje ime Korisnik obezbeđuje adresu Korisnik obezbeđuje broj telefona …


Alternativni tokovi

Koriste se da opišu vanredne funkcionalnosti

Primeri: Greške Neuobičajeni ili retki slučajevi Otkazi Polazne tačke Završne tačke Prečice

25

Uspešni scenario

PrečiceIzuzeci

Završne tačke

Polazne tačke


Alternativni tokovi - Primer

Greške: “Kućište se nije otvorilo propisno” “Bilo koja mrežna greška koja se dogodila između koraka 4 i 7” “Bilo koja vrsta greške da se dogodila”

Neuobičajeni ili retki slučajevi “Kreditna kartica je definisana kao ukradena” “Korisnik je izabrao da doda novu reč u rečnik”

Završne tačke “Sistem je utvrdio da nema više otvorenih stavki”

Prečice: “Korisnik može napustiti slučaj upotrebe pritiskom na dugme “esc”


Specifikacija slučaja upotrebe: BIS

27

Ime:

Učesnici:

Preduslovi:

Posledice:

Okidač:


Ažuriranje podataka o pacijentu

Zdravstveni radnik

Dolazak pacijenta u ordinaciju

Da pacijent ima važeću ličnu kartu i zdravstvenu knjižicu

U pacijentov karton su uneti podaci o pruženoj usluzi

Specifikacija slučaja upotrebe: BIS (2)

28

Uspešniscenario

Alternativni tokovi


1. Provera identiteta pacijenta uz pomoć lič.karte i zdr. knjižice,

2. Pretraga baze pod. I otvaranje e-kartona ako ga pacijent nema,

3. Pružanje usluge pacijentu,4. Unos podataka o usluzi,5. Štampanje recepta,

1. Pacijent nema važeću lič.kartu ili zdr. knjižicu, pacijent odlazi.

2. Pacijent želi da mu usluge pruži drugi lekar (koji nije njegov, pacijent ga nije izabrao), pacijent mora da čeka, odlazi.

Sadržaj

Uvod

Use Case dijagrami






Povezivanje omogućava fleksibilnost u specifikaciji zahteva Izolovanje funkcionalnosti Omogućavanje deljenja funkcionalnosti Deljenje funkcionalnosti u delove koji se lakše obrađuju

Koriste se tri vrste relacija: Uključuje (Include) Proširuje (Extend) Nasleđuje (Inheritance)


“Include” konstrukcija

Include se koristi u sledećim slučajevima: Dekomponovanje složenog ponašanja Centralizovanje zajedničkog ponašanja

Osnovni slučaj upotrebe eksplicitno uključuje ponašanje drugog slučaja upotrebe lociranog u svojoj bazi.

31

Ažuriranje podataka o pacijentu

Unos podataka o izvršenom pregledu<<include>>

primer


Pisanje Include konstrukcija

Ako bazni slučaj upotrebe uključuje drugi slučaj upotrebe, dodaćemo referencu kao sledeći korak:1. Sistem prikazuje karton pacijenta2. Zdravstveni radnik unosi podatak o izvršenom pregledu

ili<include: unos podataka o izvršenom pregledu>


Extend – grafičko predstavljanje

Osnova slučaja upotrebe može uključiti drugi slučaj upotrebe u određenim tačkama, zvanim tačke proširenja.

Obratite pažnju na smer strelice Osnovni slučaj upotrebe ne zna koji slučaj upotrebe ga proširuje

33

Ažur. pod. o pacijentunema e-karton

Otvaranje e-kartona pacijentu

<<extend>>

Primer


Pisanje Extend konstrukcije

Scenariji ne uključuju reference

Umesto toga, oni uključuju tačke proširenja, kao što su:Zdravstveni radnik pretražuje b.p. korišćenjem jmbgSistem ne pronalazi traženog pacijentaTačka proširenja: otvaranje e-kartona pacijentu

ili<extension point: otvaranje e-kartona pacijentu>

Proširenje slučaja upotrebe obuhvata uslove u kojima će se proširenje primeniti Primer: ako je korisnik upućen na specijalistički pregled


Primer: Bolnički IS

35

Ažuriranje podataka o pacijentuUpućivanje na specijalistički pregled

Otvaranje e-kartona


36

Generalizacija između slučajeva upotrebe

Slučaj upotrebe dete nasleđuje ponašanje roditeljskog slučaja upotrebe: Interakcija (opisana tekstualno) Linkovi slučaja upotrebe (associations, include, extend, generalization)

Slučaj upotrebe dete može zameniti roditeljski slučaj upotrebe

37

Primer


Sadržaj

Uvod

Use Case dijagrami





Proces kombinovanja

Brojno ograničenje: Dijagram bi trebalo da sadrži između 3 i 10 osnovnih slučajeva

upotrebe. Dijagram ne bi trebalo da sadrži više od 15 slučajeva upotrebe

(osnovni + uključeni + prošireni).

Abstrakcija: Svi slučajevi upotrebi bi trebalo da budu na sličnom nivou

abstrakcije.

Veličina: Slučajeve upotrebe bi trebalo opisati na pola strane ili više.


Proces deljenja

Veličina: Ako slučaj upotrebe zauzima više od jedne strane, potrebno je

razmotriti mogućnost korišćenja include/extend

Slaba zavisnost: Ako je zavisnost između dva dela slučaja upotrebe slaba,

potrebno ih je razdvojiti.

40

UC


Još detalja

Faktori van zajedničke upotrebe koji su potrebni od strane više slučajeva upotrebe Ako je upotreba neophodna koristite <<include>> Ako je osnovni slučaj upotrebe kompletan a upotreba je opciona,

razmotrite upotrebu <<extend>>

Dijagram slučaja upotrebe treba da: Uključi samo učesnike koji su neophodni


Definisanje zahteva korišćenjem Use Case dijagramaAnaliza i specifikacija informacionih sistema

dr Zoran Jeremić[email protected]

42

Education

T 3.1 definisanje zahteva koriscenjem use case dijagrama