T 3.1 definisanje zahteva koriscenjem use case dijagrama

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

dr Zoran Jeremić
zoran.jeremic@gmail.com

1

Sadržaj

 Uvod
 Use Case dijagrami
 Pisanje slučajeva upotrebe
 Povezivanje slučajeva upotrebe
 Uputstvo za definisanje efektivnih slučajeva upotrebe

2
Uvod | Dijagrami | Pisanje | Povezivanje | Uputstvo

Proces razvoja sistema

Faza Aktivnost Izlaz
Biznis
Započinjanje Utvrđivanje poslovnih potreba
dokumenta
Intervjuisanje stejkholdera, istraživanje Organizovana
Analiza sistemskog okruženja dokumentacija
Analiza inženjerskih aspekata sistema, Logički model
Specifikacija definisanje koncepata sistema sistema
Programiranje, testiranje jedinica, Proverljiv
Implementacija integrisanje, dokumentovanje sistem
Resultati
Testiranje & Integrisanje svih komponenti, verifikacija, testiranja,
Integracija validacija, instalacija, obuka funkcionalan
sistem
Popravljanje bagova, modifikacije,
Održavanje adaptacija
Verzije sistema

3

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.

4

Zahtevi vs. dizajn

 Zahtevi:
 Šta sistem treba da radi
 Abstraktnije

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

5

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 Vidljivi
 “Proces održavanja baze podataka funkcionalni
zahtevi
će se odvijati svake noći”
Skriveni
funkcionalni
zahtevi
Kvalitativni
zahtevi
6

Sadržaj

 Uvod

7

Slučajevi upotrebe

Use Case

Učesnik Slučaj upotrebe u dijagramu Slučaj upotrebe u tekstu

 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

Cilj

 Kreiranje polu-formalnog modela funkcionalnih zahteva
 Analiza i definisanje:
 Domena
 Spoljašnjih interfejsa
 Scenarija i reakcija

9

Š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?)

10

Slučajevi upotrebe kao sredstvo komunikacije

Kupci Dizajneri Korisnici
 Slučaj upotrebe treba da stimuliše diskusiju o tome šta
sistem treba da radi, uglavnom sa ljudima koji su van
razvojnog tima.

11

Jednostavan primer: Bolnički informacioni sistem

Granice
sistema

Učesnik

Slučaj
Asocijacija upotrebe

12

Pronalaženje učesnika

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

Ljudi Mašine Spoljašnji sistemi Senzori

Organizacione jedinice Baze podataka Štampač
13

Učesnici mogu biti generalizovani

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

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)

Example

14

Sadržaj

 Uvod

15

Struktura specifikacije slučaja upotrebe
Ime

Učesnici
Okidač

Preduslovi

Posledice

Uspešni scenario

Alternativni tokovi

16

Okidači (triggers)

 Šta aktivira slučaj upotrebe?
 Primeri:
 Korisnik podnosi zahtev
 Korisnik ubacuje karticu
 Sistemsko vreme je 10:00

17

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

18

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
19

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:
Korak
interakcije
1. Korisnik unosi ime proizvoda, šifru i opis
Korak
2. Sistem proverava šifru proizvoda validacije
3. Sistem dodaje proizvod u bazu podataka i šalje poruku potvrde
Korak unutrašnje (dodatni) korak
promene interakcije
20

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 proizvod
4. Sistem prikazuje stranu proizvoda koja obuhvata
informacije o proizvodu, prikaz i slične proizvode
5. Korisnik dodaje proizvod na šoping listu

21

Uputstvo za efektivno pisanje

 Koristite jednostavnu gramatiku
 Samo jedna strana (sistem ili Sistem Učesnik
učesnik) radi nešto u jednom koraku Učesnik traži novac

 Pišite sa ciljne tačke gledišta Sistem pita za količinu

 Loše: “Uzmi količinu od korisnika i daj
Učesnik unosi količinu
mu novac”
 Bilo koji korak mora voditi do nekog Sistem daje novac

progresa
 Loše: “Korisnik potvrdi na enter dugme”

22

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 kupi
2. Sistem prikazuje stavke
3. Korisnik bira stavke koje želi da kupi
4. Sistem dodaje stavke na šoping listu
5. Korisnik ponavlja korake 1-4 sve dok ne prijavi da je
završio

23

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
 …

24

Alternativni tokovi

 Koriste se da opišu vanredne funkcionalnosti
 Primeri: Polazne tačke
 Greške
 Neuobičajeni ili retki slučajevi
 Otkazi Izuzeci
 Polazne tačke Uspešni Prečice
scenario
 Završne tačke
 Prečice
Završne tačke

25

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”

26

Specifikacija slučaja upotrebe: BIS

Ime: Ažuriranje podataka o pacijentu

Učesnici: Zdravstveni radnik
Okidač: Dolazak pacijenta u ordinaciju

Da pacijent ima važeću ličnu
Preduslovi:
kartu i zdravstvenu knjižicu
U pacijentov karton su uneti
Posledice:
podaci o pruženoj usluzi

27

Specifikacija slučaja upotrebe: BIS (2)

1. Provera identiteta pacijenta uz pomoć
lič.karte i zdr. knjižice,
2. Pretraga baze pod. I otvaranje e-
Uspešni
kartona ako ga pacijent nema,
scenario 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.
Alternativni
2. Pacijent želi da mu usluge pruži drugi
tokovi lekar (koji nije njegov, pacijent ga nije
izabrao), pacijent mora da čeka, odlazi.

28

Sadržaj

 Uvod

29

Povezivanje slučajeva upotrebe

 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)

30

“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.

Unos podataka o
Ažuriranje podataka o <<include>>
pacijentu izvršenom pregledu

primer

31

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 pacijenta
2. Zdravstveni radnik unosi podatak o izvršenom pregledu
ili
<include: unos podataka o izvršenom pregledu>

32

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

<<extend>>
Ažur. pod. o pacijentu Otvaranje e-kartona
nema e-karton pacijentu

Primer

33

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 jmbg
Sistem ne pronalazi traženog pacijenta
Tač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
34

Primer: Bolnički IS

Otvaranje e-kartona

Ažuriranje podataka o pacijentu
Upućivanje na
specijalistički pregled
35

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

Primer
37

Sadržaj

 Uvod

38

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.

39

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.

UC

40

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

41

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

dr Zoran Jeremić
zoran.jeremic@gmail.com

42

T 3.1 definisanje zahteva koriscenjem use case dijagrama

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a T 3.1 definisanje zahteva koriscenjem use case dijagrama

Similar a T 3.1 definisanje zahteva koriscenjem use case dijagrama (6)

Más de Zoran Jeremic

Más de Zoran Jeremic (20)

T 3.1 definisanje zahteva koriscenjem use case dijagrama