SOFTVERSKO INŽENJERSTVO Vježbe 3: Utvrđivanje i...

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


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.


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


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.


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


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.


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.


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.


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.


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)


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.


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)


Primjeri use case dijagrama (1)


Primjeri use case dijagrama (2)


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


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.


Primjer detaljne specifikacije


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.


Primjeri za složeniju kontrolu toka (1)


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.


Primjer alternativnih tokova (1)


Primjer alternativnih tokova (2)


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.


Primjer za generalizaciju aktera


Primjer za generalizaciju use case


Primjer za uključivanje manjeg use case-a u veće (1)


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


Primjer dijela projektnog pojmovnika za sustav prodaje preko Interneta

SOFTVERSKO INŽENJERSTVO Vježbe 3: Utvrđivanje i...

Documents

Transcript of SOFTVERSKO INŽENJERSTVO Vježbe 3: Utvrđivanje i...