SOFTVERSKO INŽENJERSTVO Vježbe 3: Utvrđivanje i modeliranje zahtjeva Robert Manger Sveučilište u Zagrebu PMF-Matematički odsjek Akademska godina 2019/2020.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SOFTVERSKO INŽENJERSTVO
Vježbe 3: Utvrđivanje i modeliranje zahtjeva
Robert Manger
Sveučilište u Zagrebu
PMF-Matematički odsjek
Akademska godina 2019/2020.
V-03 Softversko inženjerstvo 2
Sadržaj Vježbi 3
Utvrđivanje zahtjeva – klasični pristup
Modeliranje zahtjeva u skladu s UP
Akteri, use-case-ovi, use case dijagram
Detaljna specifikacija use case-a
Složenija kontrola toka, alternativni tokovi
Daljnji oblici modeliranja use case-ova
Sastavljanje projektnog pojmovnika
V-03 Softversko inženjerstvo 3
Utvrđivanje zahtjeva – klasični pristup
Da bi otkrili zahtjeve, najprije.
Razgovaramo s korisnicima.
Proučavamo njihove radne procese, dokumente, postojeći
softver.
Proučavamo relevantne zakone i propise.
Za otkrivene zahtjeve radimo sljedeće.
Organiziramo ih u taksonomiju i pritom ih dijelimo na
funkcionalne i nefunkcionalne.
Jasno ih formuliramo, izbjegavajući pritom moguće
kontradikcije i nepotpunosti.
Odredimo im prioritet.
V-03 Softversko inženjerstvo 4
Primjer taksonomije zahtjeva (za poslovni sustav)
Funkcionalni zahtjevi
Kupci
Proizvodi
Narudžbe
Kanali prodaje
Plaćanja
Nefunkcionalni zahtjevi
Performanse
Kapacitet
Raspoloživost
Poštivanje standarda
Sigurnost
V-03 Softversko inženjerstvo 5
Primjer jasno formuliranih zahtjeva (za bankomat) Funkcionalni zahtjevi
1. Bankomat treba ispitati valjanost umetnute bankomatske kartice.
2. Bankomat treba provjeriti točnost PIN-a kojeg je upisao korisnik.
3. Bankomat unutar perioda od 24 h ne smije isplatiti više od 4000
kuna za istu karticu.
Nefunkcionalni zahtjevi
1. Softver za bankomat treba biti napisan u jeziku C++.
2. Bankomat treba komunicirati s bankom služeći se kriptiranjem
koje je zasnovano na ključu duljine barem 256 bita.
3. Bankomat treba ispitati valjanost bankomatske kartice u roku od
3 sekunde ili brže.
V-03 Softversko inženjerstvo 6
Uobičajena shema za određivanje prioriteta zahtjeva
Priority atribute values Semantics
Must have Mandatory requirements that
are fundamental to the system
Should have Important requirements that
may be omitted
Could have Requirements that are truly
optional (realize if there is time)
Want to have Requirements that can wait for
later releases of the system
MoSCoW criteria
V-03 Softversko inženjerstvo 7
Modeliranje zahtjeva u skladu s UP UP zanemaruje nefunkcionalne zahtjeve i bavi se samo
funkcionalnim.
UP zahtijeva da se funkcionalni zahtjevi razrade i
modeliraju kao use case-ovi. Dakle.
Crta se use case dijagram.
Sastavlja se detaljna specifikacija u obliku tablice za svaki use
case.
Veza između polaznih zahtjeva dobivenih klasičnim
pristupom i use case-ova može se izraziti kao 0/1
matrica.
Retci odgovaraju polaznim zahtjevima.
Stupci odgovaraju use case-ovima.
V-03 Softversko inženjerstvo 8
Priprema za modeliranje
Utvrđivanje granice sustava.
Granica određuje što je dio sustava, a što je izvan sustava.
Pronalaženje aktera (actors).
Akteri su uloge koje stvari ili osobe ili pojave izvan sustava poprimaju
onda kada su u neposrednoj interakciji sa sustavom.
Pronalaženje use case-ova.
Use case je funkcija koju sustav izvodi u ime ili korist određenih
aktera.
Postupak pronalaženja odnosno utvrđivanja se iterira,
sve dok se granica sustava, popis aktera, te popis use case-ova ne
stabilizira.
V-03 Softversko inženjerstvo 9
Primjeri aktera
Kupac (Customer).
Uloga koju mogu igrati razni konkretni ljudi, na primjer Pero,
Ivana, Marija, Marko.
AdministratorSustava (SystemAdministrator).
Ovu ulogu ponekad igra konkretna osoba Marko koja inače može
igrati i ulogu kupca.
DrugiSustav.
U slučaju da dva sustava stupaju u međusobnu interakciju.
Vrijeme (Time).
Onda kad se u sustavu nešto dešava samo od sebe u određenom
vremenskom trenutku, na primjer automatski backup sustava
svake večeri u 23:00 h.
V-03 Softversko inženjerstvo 10
Napomene o akterima Da bi identificirali aktere, postavljamo sljedeća pitanja.
Tko ili što koristi sustav?
Koje uloge korisnici igraju tijekom interakcije?
Tko instalira sustav?
Tko ili što pokreće ili gasi sustav?
Tko održava sustav?
Koji drugi sustavi stupaju u interakciju s našim sustavom?
Tko ili što dostavlja informacije sustavu?
Postoji li nešto što se događa u određeno vrijeme?
Akter uvijek mora biti izvan sustava. Doduše, sustav
često u sebi pohranjuje internu reprezentaciju aktera,
no te dvije stvari ne treba miješati. Na primjer:
Customer je akter izvan sustava,
CustomerDetails je klasa unutar sustava.
V-03 Softversko inženjerstvo 11
Primjeri use case-ova Usluge koje Kupac (Customer) dobiva od
SustavaZaKataloškuProdaju (MailOrderSystem)
NapraviNarudžbu (PlaceOrder)
ProvjeriStatusNarudžbe (CheckOrderStatus)
ZatražiKatalog (RequestCatalog)
Funkcije koje Menadžer (Manager) pokreće u
SustavKadrovskeSlužbe (PersonnelSystem).
PromijeniPodatkeOZaposleniku (ChangeEmployeeDetails)
GledajPodatkeOZaposleniku (ViewEmployeeDetails)
BrišiPodatkeOZaposleniku (DeleteEmployeeDetails)
V-03 Softversko inženjerstvo 12
Napomene o use case-ovima
Da bi pronašli use case-ove, postavljamo sljedeća
pitanja.
Koje funkcije određeni akter traži od sustava?
Da li sustav pohranjuje ili pronalazi informacije? Koji akter
pokreće takvo ponašanje sustava?
Što se dešava ako sustav promijeni stanje, na primjer krene ili
stane? Da li akteri to mogu primijetiti?
Da li vanjski događaji utječu na sustav? Tko ili što obavještava
sustav o tim događajima?
Da li sustav stupa u interakciju s nekim drugim sustavom?
Da li sustav generira izvještaje?
Use case uvijek pokreće neki akter.
Use case se opisuje s točke gledišta aktera.
V-03 Softversko inženjerstvo 13
Dijelovi use case dijagrama Granica sustava
(crta se kao pravokutnik)
Akteri
(crtaju se izvan granice)
Use case-ovi
(crtaju se unutar granice)
Interakcije
(spajaju aktera s use case)
V-03 Softversko inženjerstvo 14
Primjeri use case dijagrama (1)
V-03 Softversko inženjerstvo 15
Primjeri use case dijagrama (2)
V-03 Softversko inženjerstvo 16
Detaljna specifikacija use case-a (1) Ime use case-a
(na primjer u obliku UpperCamelCase).
Jednoznačno određuje use case.
Identifikator use case-a
(na primjer hijerarhijska brojčana oznaka).
Koristan ako se imena vremenom mijenjaju.
Kratki opis use case-a.
Navodi cilj i bitna svojstva use case-a.
Popis aktera:
Primarni (oni pokreću use case)
Sekundarni (oni stupaju u interakciju s use case nakon
što je on već bio pokrenut).
V-03 Softversko inženjerstvo 17
Detaljna specifikacija use case-a (2)
Preduvjeti (preconditions).
Ograničenja koja moraju biti zadovoljena prije pokretanja use
case-a.
Glavni tok.
Niz koraka unutar use case-a koji se izvršavaju sekvencijalno
jedan za drugim.
Naknadni uvjeti (postconditions).
Ograničenja koja će postati zadovoljena nakon izvršavanja
use case-a.
Alternativni tokovi.
Lista imena tokova koji služe kao alternative glavnom toku.
V-03 Softversko inženjerstvo 18
Primjer detaljne specifikacije
V-03 Softversko inženjerstvo 19
Složenija kontrola toka
Ključna riječ Ako (If)
Grananje ili uvjetno izvršavanje koraka.
Ključna riječ Za (For)
Ponavljanje koraka određeni broj puta.
Ključna riječ Dok (While).
Ponavljanje koraka dok god je ispunjen neki uvjet.
V-03 Softversko inženjerstvo 20
Primjeri za složeniju kontrolu toka (1)
V-03 Softversko inženjerstvo 21
Primjeri za složeniju kontrolu toka (2)
V-03 Softversko inženjerstvo 22
Primjeri za složeniju kontrolu toka (3)
V-03 Softversko inženjerstvo 23
Modeliranje alternativnih tokova Glavni tok predstavlja “redovni” scenarij gdje sve
ide na uobičajeni način.
Alternativni tokovi odgovaraju iznimkama,
prekidima, situacijama kad se pojavila greška.
Alternativni tok se može pokrenuti:
umjesto glavnog toka,
nakon određenog koraka glavnog toka,
u bilo kojem trenutku dok se izvršava glavni tok.
U jednostavnijim slučajevima alternativni tokovi
nisu potrebni jer se mogu zamijeniti složenijom
kontrolom glavnog toka.
Uvođenje alternativnih tokova opravdano je samo
onda kad to zaista poboljšava razumljivost modela.
V-03 Softversko inženjerstvo 24
Primjer alternativnih tokova (1)
V-03 Softversko inženjerstvo 25
Primjer alternativnih tokova (2)
V-03 Softversko inženjerstvo 26
Daljnji oblici modeliranja use case Generalizacija aktera
Uspostavlja se hijerarhija među akterima. Nadređeni akter preuzima
interakcije koje su zajedničke za sve podređene aktere. Time se
pojednostavnjuje use case dijagram.
Generalizacija use case-ova.
Uspostavlja se hijerarhija među use case-ovima. Nadređeni use
case preuzima svojstva koja su zajednička svim podređenim use
case-ovima.
Uključivanje manjih use case-ova u veće.
Dešava se da se u tokovima raznih use case-ova pojavljuje isti niz
koraka. Tada se taj niz može izdvojiti u posebni use case koji se
onda uključuje u polazne tokove slično kao što se potprogram
uključuje u glavni program.
V-03 Softversko inženjerstvo 27
Primjer za generalizaciju aktera
V-03 Softversko inženjerstvo 28
Primjer za generalizaciju use case
V-03 Softversko inženjerstvo 29
Primjer za uključivanje manjeg use case-a u veće (1)
V-03 Softversko inženjerstvo 30
Primjer za uključivanje manjeg use case-a u veće (2)
V-03 Softversko inženjerstvo 31
Primjer za uključivanje manjeg use case-a u veće (3)
V-03 Softversko inženjerstvo 32
Sastavljanje projektnog pojmovnika
Tijekom utvrđivanja i modeliranja zahtjeva usput se
bavimo i sastavljanjem projektnog pojmovnika
(project glossary).
Riječ je o listi pojmova koji se koriste u poslovnoj
domeni kojom se bavimo.
Za svaki pojam objašnjava se njegovo značenje.
Razrješavaju se sinonimi i homonimi.
Pojmovnik je važan jer omogućuje nesmetanu
komunikaciju između razvijača sustava (softverskih
inženjera) i korisnika sustava (stručnjaka iz dotične
poslovne domene).
V-03 Softversko inženjerstvo 33
Primjer dijela projektnog pojmovnika za sustav prodaje preko Interneta
Related Documents
