SVEUČILIŠTE/UNIVERZITET ''VITEZ'' TRAVNIK

FAKULTET INFORMACIONIH TEHNOLOGIJA

STUDIJ I CIKLUSA; GODINA STUDIRANJA: IV GODINA

SMJER: INFORMACIONE TEHNOLOGIJE

“USE CASE ALATI”

SEMINARSKI RAD

Travnik, 17.02.2020. godina

SVEUČILIŠTE/UNIVERZITET ''VITEZ'' TRAVNIK
FAKULTET INFORMACIONIH TEHNOLOGIJA

STUDIJ I CIKLUSA; GODINA STUDIRANJA: IV GODINA

SMJER: INFORMACIONE TEHNOLOGIJE

“USE CASE ALATI”

SEMINARSKI RAD

IZJAVA: Ja, Admir Jaganjac student Sveučilišta/Univerziteta „Vitez“ Travnik,

Indeks broj: 163-19/DIIT odgovorno i uz moralnu i akademsku
odgovornost izjavljujem da sam ovaj rad izradio potpuno samostalno uz
korištenje citirane literature i pomoć profesora odnosno asistenta.

Potpis studenta: ____________

STUDENT: Admir Jaganjac
PREDMET: Prikupljanje Softverskih Zahtjeva
PROFESOR: dr sci. Ilija Šušić
SADRŽAJ

SADRŽAJ.............................................................................................................................................. 3

1. UVOD.......................................................................................................................................... 1
1.1 Problem, predmet i objekt istraživanja................................................................................................2
1.2 Svrha i ciljevi istraživanja.....................................................................................................................2
1.3 Radna hipoteza....................................................................................................................................2
1.4 ZNANSTVENE METODE........................................................................................................................3
1.5 Struktura rada......................................................................................................................................3

2. Case Tools primjeri...................................................................................................................... 4

2.1 Alati za dijagram..................................................................................................................................4
2.2 Alati za modeliranje procesa................................................................................................................4
2.3 Alati za upravljanje projektima............................................................................................................5
2.4 Dokumentacijski alati...........................................................................................................................5

3. Primjer upotrebe “Use case”........................................................................................................ 5

3.1 Sistem............................................................................................................................................6
3.2 Akteri.............................................................................................................................................7
3.3 Ljudi (uloge) akteri........................................................................................................................7
3.4 Akteri sistema...............................................................................................................................8
3.5 Dodatni primjeri:..................................................................................................................................8
3.5 Slučajevi upotrebe.........................................................................................................................9
3.7 Dodatni primjeri...................................................................................................................................9

4. Ključne komponente toka događaja........................................................................................... 10

4.1 Alternativni koraci..............................................................................................................................10
4.2 Koraci izuzeća.....................................................................................................................................10
4.3 Pronalazak upotrebnih slučajeva.......................................................................................................11
4.4 Jedinstveni postupak..........................................................................................................................12

5. Upravlanje projektom pomoću “Case-a” slučaja upotrebe..........................................................12

6. Kontrola dosega pomoću dijagrama slučaja................................................................................13

6.1 Upravljanje ljudskim resursima..........................................................................................................14
6.2 Upravljanje rizicima...........................................................................................................................14
 6.3 Manipulacija slučajeva upotrebe.......................................................................................................15
6.4 Objašnjenje........................................................................................................................................16

7. Inspekcijski protocol.................................................................................................................. 17

8. Karakteristike hardwera CASE alata............................................................................................ 18

8.1 Podrška za dokumentaciju.................................................................................................................18
8.2 Vanjski interfejs..................................................................................................................................19
8.3 Obrnuti inženjering............................................................................................................................19

9. test ili stvarni slučaj?.................................................................................................................. 20

10. Provjera protokola................................................................................................................. 22

11. Zaključak............................................................................................................................... 23

12. Literatura............................................................................................................................... 24
1. UVOD
Povećava se složenost dizajna računalnih sistema. Praktično sve učinkovite
korporacije prelaze na viši stepen automatizacije u obradi podataka. To podrazumijeva
veće zahtjeve prema računalnim sistemima koji se razvijaju. Slijedom toga, povećava se
potreba za učinkovitijim metodama i alatima za razvoj i održavanje računalnih sistema.
Posljednjih nekoliko godina stvoren je veliki broj alata za analizu i oblikovanje
računalnih sistema. Ovi alati, zvani CASE alati, namjeravaju automatizirati dijelove
procesa razvoja sistema. Međutim, danas postoji velika raznolikost među alatima CASE.
Neki od njih su samo grafički urednici s jednostavnom bazom podataka za spremanje
dizajnerskog učinka, te se specifikacije često mogu prenijeti na 4GL alate ili sisteme
baza podataka radi daljnjeg dizajna i primjene. Neki alati, u nml-u, su sofisticirane radne
površine s velikom količinom automatizacije u procesima analize i dizajna te s
mogućnošću generiranja koda iz projektnih specifikacija. Važan činilac koji se odnosi na
CASE alate je metoda (ili metode) koju alat podržava u analizi a s tim povećava
složenost dizajna računalnih sistema. Korištenje CASE alata ubrzava razvoj projekta da
bi se dobio željeni rezultat i pomaže otkriti nedostatke prije nego što krenemo prema
sljedećoj fazi razvoja softvera.

1
1.1 PROBLEM, PREDMET I OBJEKT ISTRAŽIVANJA

Za donošenje odluke o izboru case alata potrebna je detaljna informacija o alatu i

podržanim metodama ka oi zahtjevi za određene funkcije, kao što su izrada prototipa,
generiranje koda i interfejsa s drugim proizvodima, moraju se uzeti u obzir pri odabiru
alata. Naravno, postoje i drugi aspekti prilikom odabira CASE alata, ali oni su izvan
okvira ovog rada.

1.2 SVRHA I CILJEVI ISTRAŽIVANJA

Svrha ovog rada je opisati kako se pouzdana i detaljna informacija o alatima

CASE može zabilježiti proučavanjem i procjenom istih u praksi. dizajnu sistema.
Kompanija se možda mora odlučiti hoće li ulagati u CASE-ov alat specifičan za metodu
i naučiti metodu koju koristi ili će odabrati alat koji se može prilagoditi metodi koju
koristi kompanija. Za donošenje ove važne odluke potrebna je detaljna informacija o
alatu i podržanim metodama. zahtjevi za određene funkcije, kao što su izrada prototipa,
generiranje koda i interfejsa s drugim proizvodima, moraju se uzeti u obzir pri odabiru
alata.

1.3 RADNA HIPOTEZA

Svi znamo koliko je teško postići uspjeh projekta bez potpunih zahtjeva za
proizvodom. Ipak, prikupljanje cjelovitih zahtjeva bez iscrpljivanja rasporeda projekata i
proračuna ostaje neizbježno za mnoge voditelje projekata. Kada se miksu doda nova
tehnologija, izazovi su još veći. Ovaj rad govori o složenosti prikupljanja nejasnih
zahtjeva, pokazujući kako slučajevi korištenja mogu pomoći u rješavanju ovog
problema. Također odgovara na pitanja koja često postavljaju voditelji projekata o
jednoj tehnici prikupljanja zahtjeva koja se naziva slučajevima upotrebe.

2
1.4 ZNANSTVENE METODE

U ovom radu ćemo koristiti medote komparacija, analize i metode apstrakcije.

1.5 STRUKTURA RADA

Voditelji projekata i poslovni analitičari tradicionalno se bore ne samo kako

definirati jednoznačne zahtjeve, već i kako spriječiti da se zahtjevi promijene nakon što
su ti početni zahtjevi definirani. Jedan od načina da se ovaj problem ublaži jest pružanje
strukture koja olakšava raspravu o potrebama između kupaca i tehničkog osoblja i
rezultira proizvodima za rad koji su korisni ne samo dizajnerima i programerima, već i
poslovnim kupcima. Slučajevi korištenja pružaju tu strukturu i prilagođavaju se
promjenama kako je poznato više tokom životnog ciklusa projekta. Koliko god ova
struktura bila korisna, okružena je mistikom i zabludama. Ovaj rad opisuje praktičan
pristup korištenju slučajeva i daje naputke kako ih voditelji projekata mogu uključiti u
svrhu poboljšanja tehničke i poslovne komunikacije, pomoći u upravljanju opsegom
projekta i naoštrenju poslovnih zahtjeva.
Ovaj se rad bavi ovim problemima odgovarajući na ovih deset često postavljanih pitanja
o slučajevima upotrebe.

 Zašto bi se rukovoditelji projekata trebali brinuti o slučajevima upotrebe?

 Koje su ključne komponente slučajeva upotrebe?
 Koja je razlika između modela slučaja upotrebe i dijagrama slučajeva upotrebe?
 Je li slučaj upotrebe najučinkovitiji alat za modeliranje procesa?
 Kako mogu pronaći slučajeve upotrebe?
 Kako će mi slučajevi pomoći da upravljam svojim projektima?
 Ako stvaramo slučajeve upotrebe, trebamo li dovršiti popis zahtjeva?
 Sadrže li slučajevi upotrebe sve zahtjeve?

3
Definicija pojma "upotreba slučaja" u udžbenicima je mnogo. Mnoge od tih definicija su
teoretske i opisuju slučaj upotrebe u terminima koje je teško shvatiti za posao. Na
primjer, Geri Schneider definira slučaj upotrebe kao „ponašanje sistema koji proizvodi
mjerljiv rezultat vrijednosti za aktera. Frank Armor1 opisuje slučaj upotrebe kao "niz
radnji potrebnih sistemu , funkcionalna traka kroz sistem i prikazana je kao vodoravna
elipsa ..." Ivar Jacobson definira slučaj upotrebe kao "opis niza nizova radnji i varijanti
koje sistem izvodi, a koji daju akteru rezultate vidljive vrijednosti. Martin Fowler
definira slučaj upotrebe kao "skup scenarija povezanih zajedničkim poslovnim ciljem.

Jednostavno rečeno, slučaj upotrebe opis je svih načina na koje krajnji korisnik želi
"koristiti" sistem. Te „upotrebe” su poput zahtjeva sistema, a slučajevi korištenja opisuju
što sistem radi kao odgovor na takve zahtjeve. Drugim riječima, slučajevi upotrebe
opisuju razgovor između sistema i njegovih korisnika, poznatih kao akteri. Iako je
sistem obično automatiziran (kao što je sistem narudžbe), slučajevi upotrebe primjenjuju
se i na opremu, uređaje ili poslovne procese.

2. CASE TOOLS PRIMJERI

2.1 ALATI ZA DIJAGRAM

Ti se alati koriste u prikazu komponenti sistema, podataka i upravljanja

protokom različitih softverskih komponenti i strukture sistema u grafičkom obliku. Na
primjer, alat za izradu dijagrama protoka za izradu modernih dijagrama toka.

2.2 ALATI ZA MODELIRANJE PROCESA

Modeliranje procesa metoda je za kreiranje softverskog modela procesa, koja se

koristi za razvoj softvera. Alati za modeliranje procesa pomažu menadžerima da odaberu

1
https://books.google.ba/books/about/Advanced_Use_Case_Modeling.html?
id=VINuQgAACAAJ&redir_esc=y

4
model procesa ili ga promijene prema zahtjevima softverskog proizvoda. Na primjer,
EPF Composer

2.3 ALATI ZA UPRAVLJANJE PROJEKTIMA

Ovi se alati koriste za planiranje projekata, procjenu troškova i napora,

zakazivanje projekata i planiranje resursa. Menadžeri moraju strogo pridržavati
izvođenja projekata sa svakim spomenutim korakom u upravljanju softverskim
projektima. Alati za upravljanje projektima pomažu u pohrani i razmjeni informacija o
projektu u stvarnom vremenu u cijeloj organizaciji. Na primjer, Creative Pro Office,
Trac Project, Basecamp.

2.4 DOKUMENTACIJSKI ALATI

Dokumentacija u softverskom projektu započinje prije softverskog procesa,

prolazi kroz sve faze SDLC-a i nakon završetka projekta. Dokumentacijski alati
generiraju dokumente za tehničke korisnike i krajnje korisnike. Tehnički korisnici su
uglavnom interni profesionalci razvojnog tima koji se pozivaju na priručnik sistema,
priručnik za upotrebu, priručnik za obuku, priručnike za instalaciju itd. Dokumenti
krajnjeg korisnika opisuju funkcioniranje i rad sistema kao što je korisnički priručnik.
Na primjer, Doxygen, DrExplain, Adobe RoboHelp za dokumentaciju.

3. PRIMJER UPOTREBE “USE CASE”

Upotrijebimo primjer mikrovalne. Mnogo je načina na koje mi, akteri ili krajnji
korisnici, želimo iskoristiti mikrovalnu pećnicu, uključujući grijanje ostataka vode,
kipuću vodu za čaj, odmrzavanje smrznute hrane, kuhanje obroka. Svaka od njih je
"upotreba" mikrovalne i može se opisati u upotrebnom slučaju. Ako želimo kuhati vodu
za čaj, kažemo mikrovalnoj što želimo učiniti (naš zahtjev da prokuhamo vodu).
Mikrovalna pećnica kuha vodu i obavještava nas kada završite.

5
Uzmimo još jedan primjer, automatizirani sistem narudžbi. Neke od koristi ovog sistema
mogu biti odabir stavke ili provjeravanje dostupnosti stavke. Ostale upotrebe uključuju
stvaranje naloga, njihovo kopiranje ili premještanje i brisanje. Slučajevi korištenja
opisali bi svaku od ovih funkcija sistema. I zašto bi se rukovoditelji projekata trebali
brinuti?
Slučajevi korištenja pružaju strukturu za prikupljanje zahtjeva kupaca i postavljanje
opsega projekta. Također su izuzetno korisni ako krajnji korisnici testiraju sistem kako
je zamišljen, što dovodi do bržeg razvoja i korisnijeg sistema. Iako modeliranje
slučajeva ne nudi cjelovito rješenje za prikupljanje zahtjeva, olakšava razvoj korisničkih
interfejsa (ekrana), uređivanja zaslona i poruka te scenarije testiranja prihvaćanja.
Poslovni analitičari tradicionalno su se borili ne samo s načinom prevođenja onoga što je
krajnji korisnik želio da sistem napravi u tehnički dizajn, već i s tim da taj isti krajnji
korisnik provjeri je li prijevod bio ispravan prije nego što je sistem izgrađen. Pseudo kod
koji obično pišu proizvođači softvera bio je previše tehnički da bi ga mogla potvrditi
većina krajnjih korisnika. Slučajevi korištenja pomažu riješiti ovu dilemu pružanjem
prijevoda koji krajnji korisnici mogu razumjeti i promijeniti prije nego što je u projekt
uloženo previše vremena. Dno crta - više se može učiniti s manje. Pored toga, slučajevi
upotrebe pomažu pri slijedećim slučajevima:
 Poslovni klijenti artikuliraju svoje potrebe.
 Poslovanje i IT međusobno komuniciraju.
 Scenariji testiranja na temelju zahtjeva i test testiranja prihvaćanja od strane
korisnika.
 Strukturirano postepene s iznimkama.
 Definicija izmjena i poruka.
 Cjelovitija i brža definicija zahtjeva.
 Koje su ključne komponente slučajeva upotrebe?

Ključne sastavnice slučajeva upotrebe su sistem, akteri i slučajevi upotrebe. Usko

povezano s gore navedenim interfejsa su koja olakšavaju razgovor između aktera i
sistema. Svaku od ovih komponenti pogledat ćemo zasebno.

6
 3.1 SISTEM

Schneider2 opisuje sistem kao "sve što namjeravate stvoriti" Sistem je granica
aplikacije. Na primjer, granice projekta razvoja novog sistema narudžbe uključivale bi
cijelu aplikaciju i njegova interfejsa sistema, te bi stoga bile znatno šire nego da je
projekt malo unapređenje. Granica sistema pomaže u postavljanju opsega projekta, o
čemu ćemo kasnije raspravljati u radu.
Bilo nam je najkorisnije usredotočiti se na sistem, a ne na aktera. Razumijevanjem
sistema, možemo bolje obuhvatiti naš projekt, razmotriti rizike projekta i prikupiti svoje
zahtjeve. Identifikacija ispravnih aktera ključni je kriterij uspjeha, ali određivanje opsega
sistema temelj je za upravljanje projektima, a također korisno u određivanju sudionika.

3.2 AKTERI

Akteri su vanjski entiteti koji izravno komuniciraju sa sistemom. Koristeći

primjer sistema narudžbe, kada predstavnici službe za korisnike unose broj artikla u
sistem, oni su sudionici. Kada kupci unose predmete na web stranicu, oni su akteri. Ako
kupac naručuje telefonom, a samo predstavnik službe za korisnike unosi taj nalog, kupac
nije akter.
Akteri mogu biti ljudi, drugi sistemi ili vrijeme. Kad sistem narudžbe pređe na
Inventarni sistem radi utvrđivanja je li neki proizvod na zalihi ili ne, sistem inventara je
drugi akter. Ako, primjerice, obrada na kraju mjeseca pokrene sistem narudžbe za
kreiranje, primjerice, izvještaja, vrijeme je vrijeme. Vremenski akteri nazivaju se
vremenski akteri.

3.3 LJUDI (ULOGE) AKTERI

2
https://www.amazon.com/Applying-Use-Cases-Practical-Guide/dp/0201708531

7
 Kada se ljudi smatraju akterima, važno je shvatiti da ljudi igraju uloge (poput kupca,
radnika za održavanje, tehničara za uklanjanje problema, instalatera i rukovoditelja), i
treba ih dokumentirati i opisati tim imenima, a ne njihovim imenima naslova. Ponekad
ljudi igraju više uloga, poput sljedeće:

 Kupac i zaposlenik
 Tehničar i voditelj
 Kupac, predstavnik računa i prodajni agent

Važno je aktere glumiti kao igrače uloga ili aktere u predstavi, a ne pojedine osobe ili
radna mjesta. Definiranje aktera prema interakcijama koje žele ostvariti sa sistemom
pomoći će definiranju i razlikovanju aktera.

3.4 AKTERI SISTEMA

Sistemi mogu biti bilo koji automatizirani uređaj s kojim će sistem interfejsavati.
To uključuje druga računala i interfejsa (ako su izvan opsega sistema koji se razvija). Na
primjer, ako je sistem distribucijskog centra koji čita podatke sa skeniranih kartona,
uređaji koji se koriste za skeniranje kartona vjerojatno će biti uključeni kao akteri.
Međutim, ako je „sistem“ sami uređaji za skeniranje, tada bi širi sistem distribucijskog
centra bio akter.

Drugi sistemi mogu biti bilo koji automatizirani uređaj s kojim će sistem interfejsavati.

 Ostala računala
 Uređaji za interfejs (ako nisu izvan opsega sistema koji se razvija)
 Sve drugo osim ljudi ili vremena
 Vremenski akteri
 Vremenski akteri vremenski su inicijatori ili pokretači obrade aktivnosti za
sistem. Uobičajeni timeri su tjedni, dnevni i mjesečni.

8
3.5 DODATNI PRIMJERI:

 17:00 svakog petka stvara se tjedno izvješće o stanju

 12:00 svakog posljednjeg utorka u mjesecu stvara se bilanca dobiti
Svakog sata u satu provodi se provjera vremena pomoću korporativnog vremenskog
sistema kako bi se osiguralo točnost sata sistema.

3.5 SLUČAJEVI UPOTREBE

Jesu li procesi koji se odvijaju u sistemu. Kao i drugi procesi, oni imaju doseg
procesa. Odnosno, počinju i završavaju. Oni također pretvaraju ulaz u izlaz. Slučajevi
upotrebe su imenovani aktivnim glagolom i imenicom, poput ispunjenog naloga ili
povratnog predmeta.

3.7 DODATNI PRIMJERI

 Povlačenja procesa.
 Računovodstvene i prodajne knjige.
 Izrada sigurnosnih kopija odjeljaka predmeta.
To se smatraju postupcima koji akteru ostvaruju zadatak. Slučajevi korištenja trebali bi
akteru pružiti vrijednost. Cilj je otkriti sve moguće slučajeve upotrebe za sve prethodno
definirane aktere, što pomaže definirati opseg sistema.
Interfejs omogućuje razgovor između aktera i sistema. Iako tehnički nisu dio slučaja
upotrebe, oni su povezani. Razmišljanje o sučeljima pomaže u otkrivanju dodatnih
slučajeva upotrebe i obrnuto. Razmišljanje o slučaju upotrebe često pokreće dizajn
interfejsa.

Upotrijebimo primjer automobila. Jedan od načina na koji bismo možda željeli koristiti
svoj automobil je zaustavljanje kad želimo. Slučaj upotrebe opisao bi 'komunikaciju' s
9
automobilom kada smo željeli da on stane. Ta komunikacija je omogućena kroz
interfejs, u ovom slučaju kočnicu, što nam omogućava da aktiviramo svoj zahtjev prema
automobilu i da automobil odgovori na zahtjev da se zaustavi. Moramo razgovarati
jezikom svog automobila; ne možemo jednostavno vikati „stop!“ Za izradu zahtjeva
trebamo koristiti interfejs (kočnicu). Nadam se da automobil reagira usporavanjem i
zaustavljanjem. Zasloni, poznati i kao korisničko interfejs, pomažu krajnjim korisnicima
da komuniciraju s automatiziranim sistemima.
Koja je razlika između modela slučaja upotrebe i dijagrama slučajeva upotrebe?
Model slučaja upotrebe sastoji se od dijagrama slučajeva upotrebe i narativnog teksta
koji detaljno opisuje slučajeve upotrebe. Dijagram je slika sistema, aktera i slučajeva
korištenja. Sadrži granicu sistema, koja se naziva rubni okvir, aktere i slučajeve
upotrebe. Većina dijagrama crta se pomoću UML-a. Narativni tekst koji opisuje slučaj
upotrebe naziva se tok događaja. UML se ne bavi ovim tekstualnim opisom.

4. KLJUČNE KOMPONENTE TOKA DOGAĐAJA

Uvjeti prije i poslije, koji određuju opseg slučaja upotrebe. Preduvjet navodi
početno stanje ili ono što se mora dogoditi prije nego što započne slučaj korištenja.
Postkondicija navodi stanje završetka ili ono što se dogodilo kao rezultat upotrebe. Kao i
kod svakog procesa, granice gdje se počinje i završava obično su nejasne. Na primjer,
gdje završava nalog za ispunjavanje? Kako možemo znati da ispunjavamo narudžbu? Je
li to kada artikl otpremi? Je li odabran u distribucijskom centru? Je li stvorena u
sistemu? Korisnici procesa obično imaju različite pretpostavke i razumiju o granicama
procesa.
Primarni koraci procesa. Ponekad se naziva primarni put, uobičajeni tok događaja,
glavni tok, sretan put, put sunčanog dana ili rutinski postupak, to su navodi koraka koji
se događaju većinu vremena. To je rutinska obrada.

4.1 ALTERNATIVNI KORACI

10
 Ponekad se naziva alternativni put ili podtok, to su koraci koji mogu dovesti do
završetka postupka, ali su rjeđi od primarnih koraka procesa. Drugi izraz koji se koristi
za opisivanje alternativnih koraka je scenarij. Na primjer, glavni tok može biti
predstavnik službe za korisnike da unese narudžbu kupca kroz interni sistem, dok bi
alternativni protok bio web nalog.

4.2 KORACI IZUZEĆA.

Ponekad se naziva i sekundarni tok događaja ili tok izuzetaka, to su uvjeti koji se
mogu dogoditi da spriječe sistem da prijeđe na svoje post-stanje. Koristeći primjer našeg
sistema naloga, ako je kredit odbijen, sistem ne može obraditi nalogodavca.
Je li slučaj upotrebe najučinkovitiji alat za modeliranje procesa? Iako se sistem može
definirati kao poslovni proces, ne mislimo da je to praktično. Otkrili smo da su i drugi
modeli procesa, poput mapa procesa, staza za plivanje i dijagrama aktivnosti efikasniji.
Upotrijebite slučajeve koji modeliranje poslovnih procesa mogu postati tekstualne
procedure. Međutim, grafička slika poslovnog procesa pomaže uočiti anomalije s
trenutnim procesom i lakše ih vodi do načina da se poboljšaju. Tekstualni postupci nisu
podložni ovoj vrsti analiza.

4.3 PRONALAZAK UPOTREBNIH SLUČAJEVA

Potičemo dokumentiranje poslovnih procesa pomoću jednog od gore spomenutih

modela poslovnih procesa i tražimo dodirne točke sa sadašnjim ili budućim
automatiziranim sistemima. Te su dodirne točke slučajevi upotrebe kandidata. Koristimo
ponovo sistem Narudžbe kao primjer. Recimo da u trenutačnom postupku predstavnik
službe za korisnike unosi tražene podatke o artiklima u sistem. Točka u kojoj se događa
taj unos je slučaj upotrebe kandidata. Slučaj upotrebe opisao bi što nalogodavac očekuje
od sistema i što sistem čini da bi izvršio narudžbu.
Čuli smo puno o UML-u (jeziku objedinjenog modeliranja) i jedinstvenom procesu.
Kako se oni odnose na slučajeve upotrebe? UML daje smjernice za izradu dijagrama
koji su obično povezani s objektnom tehnologijom. Glavna mu je korist pomoći

11
članovima tima da bolje komuniciraju jedni s drugima. Kad dijagrami slijede iste
konvencije, poslovni analitičari, dizajneri, programeri i testeri mogu sve interpretirati na
isti način, smanjujući rizik da će zahtjevi koje je naveo poslovni stručnjak pogrešno
protumačiti. Kao što je ranije napomenuto, postoje UML smjernice za dijagram
korištenja, ali ne i za narativni tekst. Nije potrebno koristiti UML pri kreiranju dijagrama
slučajeva upotrebe, ali je korisno.

4.4 JEDINSTVENI POSTUPAK

Ovaj skup procesa pruža okvir za razvoj sistema općenito i predmeta posebno.
Omogućuje razvojni životni ciklus sa standardiziranim fazama projekata, koje uključuju
početne faze, razradu, konstrukciju i prijelaz (vidi Jacobson et al.). Međutim, nije
potrebno koristiti jedinstveni postupak prilikom stvaranja slučajeva upotrebe i svi
razvojni životni ciklusi mogu uključivati slučajeve upotrebe.

5. UPRAVLANJE PROJEKTOM POMOĆU “CASE-A”

SLUČAJA UPOTREBE

Dijagram slučaja upotrebe posebno je učinkovit alat za pomoć u prepoznavanju i

upravljanju opsegom projekta. Iako je samo jedan od mnogih aspekata upravljanja
projektima, upravljanje opsegom često se smatra najtežim. Dijagram slučaja upotrebe
pomaže identificirati opseg na slijedeće načine
Postavlja granicu projekta. Granični okvir označava opseg sistema. Sve što je unutar
okvira uključeno je u system, bilo što izvan okvira isključeno je. Ovaj je dijagram
prekrasan grafički prikaz opsega sistema.
Prikazuje procese koji se razmatraju. Svaki je slučaj upotrebe proces koji donosi
krajnjem korisniku vrijednost. Svaka osoba ima poslovni cilj ili cilj koji će biti ostvaren.
Tok događaja potvrđuje opseg. Pruža detalje koji su uključeni u svaki postupak slučaja
upotrebe i opisuje koliko je svaki proces velik.

12
Svi se slučajevi upotrebe moraju povezati s vizijom i ciljevima poslovanja i projekta.
Svaki slučaj upotrebe koji ne pruža ovo poravnanje može se lako vidjeti i ukloniti.
Prikazivanje aktera sistema pomaže pružiti sliku interfejsa koja je potrebno izmijeniti.
Ova slika pomaže prikazivanju ne samo onoga što se nalazi u aplikaciji, već i koliko
interfejsa sistema treba uključiti u projekt. Pruža učinkovit komunikacijski alat i vizual
koji može biti od pomoći u objašnjavanju i procjeni napora koji poslovnim kupcima
može biti transparentan.

Slika1. Dijagram slučaja upotrebe

Izvor: https://www.pinterest.com/pin/582371795552393422/

6. KONTROLA DOSEGA POMOĆU DIJAGRAMA SLUČAJA

13
 Nakon što se potvrde slučajevi upotrebe, novim slučajevima upotrebe može se
bolje upravljati. Promjene se mogu usporediti s vizijom i izvornim dijagramom kako bi
se vidjelo pripadaju li ili ne. Novi zahtjevi mogu se prevesti u nove slučajeve upotrebe i
staviti u dijagram. Ako se novi akteri pojave, to je pokazatelj da je potrebno više rada.
Opet, vizual služi kao način za komunikaciju s poslovnim stručnjacima o utjecaju
njihovih zahtjeva na projekt.
Ako novi slučajevi upotrebe uzrokuju promjenu veze, trebat će i dodatni rad.

6.1 UPRAVLJANJE LJUDSKIM RESURSIMA

Dijagram slučajeva upotrebe također pomaže u identificiranju aktera koji su, za

ljudske aktere, sudionici u projektu. Proces povezivanja aktera s korištenjem slučajeva
na dijagramu može biti još jedan alat za otkrivanje skrivenih dionika i bolju
komunikaciju među dionicima, koji mogu dovesti u pitanje njihovu potrebu za
sudjelovanjem u projektu.

6.2 UPRAVLJANJE RIZICIMA.

Korisno je prije ispitati rizike i riješiti se činilaca s najvećim rizikom. Na početku

projekta, slučajevi upotrebe označeni u dijagramu slučajeva upotrebe mogu pomoći
projektnom timu da identificira i analizira takve činilace rizika kao što su upotreba nove
tehnologije, softvera treće strane i pridruženih rizika dobavljača i više sudionika (što
više akteri, veći je rizik, bilo da ti akteri predstavljaju dionike ili interfejsa sistema).
Kako projekt napreduje, slučajevi upotrebe mogu se koristiti za pomoć u prepoznavanju
rizika koji su se pojavili od početka projekta. Ako kreiramo slučajeve upotrebe, trebamo
li dovršiti popis zahtjeva? Mnogi od naših kupaca imaju vlastite predloške slučajeva
upotrebe koji uključuju povezano poslovno pravilo ili zahtjev. Oni se suočavaju s
pitanjem hoće li ili ne napraviti poseban popis zahtjeva. Neki su odlučili uskladiti se s
IEEE, (Institut inženjera elektrotehnike i elektronike, koji objavljuje zahtjeve i predloške
i standarde za testiranje), što uključuje zaseban popis u specifikaciji zahtjeva. Ostali su

14
zahtjeve pravila stavili pravo na ili na kraju opisnog slučaja upotrebe i nisu upotrijebili
zasebni popis zahtjeva. I drugi su napravili kombinaciju obojega.
Potičemo poseban popis zahtjeva za sljedivost. Popis zahtjeva postaje temelj za matricu
sljedivosti, koja je glavni alat za osiguravanje da svaki zahtjev ispunjava poslovne
potrebe i da se odobreni zahtjevi zaista isporučuju na kraju projekta

6.3 MANIPULACIJA SLUČAJEVA UPOTREBE

Slučajevi upotrebe mogu se izmanipulirati da biste ispunili sve zahtjeve, ali

postoje neke vrste zahtjeva koji se bolje podvrgavaju drugim modelima. Jedno od
najčešće postavljanih pitanja je zašto koristiti druge modele u definiranju zahtjeva.
Koristite modele slučajeva koji prikazuju procese, pa ako je projekt prvenstveno onaj
koji manipulira podacima (poput skladišta podataka ili aplikacije za izvještaj), tada su
drugi alati učinkovitiji.
Karte poslovnih procesa. Uz ranije navedene prednosti procesnih karata, one pružaju i
korisničku interfejs (zaslon) navigaciju koja u idealnom slučaju prati poslovne procese
(nadamo se poboljšani ili ponovno izmijenjeni). Te karte mogu istjerati i skrivena
pravila poslovanja, npr. ne možemo izbrisati stavku kada je količina narudžbe veća od
nule.
Modeli podataka pružaju informacije potrebne za dionike. Također pomaže prikazati
ono što se pojavljuje na svakom zaslonu, kako za zaslone za unos podataka, tako i za
izvješća. Oni također pružaju mnoga poslovna pravila, npr. trebaju li klijenti imati
račune ili ne.
Izrada prototipa, koja je izvedena iz modela podataka, procesa i korištenja slučajeva,
omogućava ranu povratnu informaciju i pomaže u isticanju dodatnih zahtjeva tokom
analize zahtjeva. Ove prototipe ne treba u potpunosti dizajnirati ili čak izraditi
automatizacijom. Neki od najučinkovitijih prototipa izrađeni su na papiru, koristeći
ljepljive trake za uklanjanje alternativnih staza i izuzetaka kako je opisano u slučajevima
upotrebe.

15
Nije čudo da je jedan od najčešćih prigovora koje čujemo od projektnih menadžera i
poslovnih analitičara da su obavili temeljit posao korištenja modela modeliranja, a
zahtjevi se i dalje pojavljuju tokom i nakon projekta!
Jedan dokazani pristup za brzo i cjelovito prikupljanje zahtjeva ono je što nazivamo
„istodobnim poslovnim modeliranjem“3. Ovaj se pristup razlikuje od istodobnog
inženjeringa komponenata ili istodobnosti, koja se obično koristi u razvoju objekata i e-
rješenja. Paralelno poslovno modeliranje usredotočeno je na dobivanje poslovnih
zahtjeva, a ne na izgradnju softvera. Predlaže da se modeliranjem poslovnih podataka,
poslovnih procesa, sistemskih procesa korištenjem modela kućišta i prototipiranja
zahtjeva zahtjevi brzo pojave. Pored toga, svaka vrsta napora za modeliranje podržava i
poboljšava ostale napore modeliranja i potiče analitičare da postavljaju svojim kupcima
vrste odgovarajućih pitanja koja istjeraju skrivene potrebe.
U početku se slučajevi upotrebe razvijaju pomalo neugodno i neprirodno. Ljudima je
teško razmišljati poput "sistema." Ipak, većina analitičara i rukovoditelja projekata vide
trenutnu korist u razvoju slučajeva upotrebe i nakon jednog ili dva napora nespretnost
nestaje. Tada se počinje događati čudna stvar, klijenti, analitičari, voditelji projekata i
tehničko osoblje počinju govoriti istim jezikom, naglašavajući važnost nedvosmislenih
zahtjeva, a projekti se dovršavaju brže i s manje troškova.

6.4 OBJAŠNJENJE

Ne treba sumnjati da je najbolji način da naučite CASE-alat upotrebe u praksi.

Čitanje podataka iz dobavljača i programa može biti osnova preliminatnog odabira, tj.
jasno dati do znanja koji alati ne udovoljavaju osnovnim zahtjevima. Međutim, da bi
odabrali pravi alat, potrebna je detaljna informacija o nekoliko alata, vaše prednosti i
problemi koji se mogu pojaviti kod njihove upotrebe u praksi. Primjena CASE alata u
praksi je na najbolji način otkrila praktične probleme i njihove ozbiljnosti. Kada se
prouči nekoliko alata u praksi na sličnim stvarima, potrebno je iskoristiti iskustva za
usporedbu praktičnih vrijednosti tih alata.

3
https://www.visual-paradigm.com/tutorials/vptscollbpd.jsp?format=pdf

16
Svrha praktične studije je stjecanje iskustava i relevantnih značajki ispitivanog predmeta
i finaliziranje rezultata. Krajnje izvješće temelji se na konačnoj procjeni proučavanog
predmeta. Tokom proučavanja CASE alata, izvješće treba navesti informacije o svim
važnim značajkama alata i njihovoj ulozi u praksi. Detaljna i identična strukturirana
izvješća o nekoliko alata daju dobru osnovu za usporedbu alata i konačnu selekciju.
Naravno, priprema i izvršavanje ovih praktičnih studija CASE alata je skup i dugotrajan
zadatak. Prilikom donošenja svoje odluke, mnoga poduzeća su ograničena na pružanje
informacija o dobavljačima i iskustva drugih korporacija. Međutim, korisnička iskustva
rijetko se zapisuju i formaliziraju kako bi bila lako dostupna drugim ljudima. Stoga
dobro formirana izvješća o praktičnim studijama i procjenama CASE alata pružaju
važan način dobivanja vrijedne i detaljne informacije o alatima s praktičnog stajališta.

7. INSPEKCIJSKI PROTOCOL

Da bi se studije različitih alata CASE i dobiveni izvještaj učinili što je moguće

ravnopravnijim, može se koristiti inspekcijski protokol. Inspekcijski protokol vrsta je
kontrolnog popisa atributa alata, uključujući opis načina na koji bi se ovi alO'ibuti trebali
tumačiti i proučavati. Korištenje protokola tokom praktičnog ispitnog rada i pisanja
izvještaja osigurava dobro strukturirana i usporediva izvješća koja se mogu koristiti u
postupku odabira.

Slika 2. Matrica usporedbe CASE alata.

17
Izvor:https://senturus.com/blog/microsoft-bi-tool-overview-comparison/tool-comparison-matrix/

8. KARAKTERISTIKE HARDWERA CASE ALATA

U većini slučajeva, prevladavajući hardver može postavljati ograničenja pri

odabiru alata CASE. Stoga, umjesto da se za hardverski alat tretiraju potrebni hardverski
zadaci, zadatak koji se sada nalazi postaje prilagođavanje optimalne konfiguracije CASE
alata stupnja unutar postojećih hardverskih mogućnosti. Zbog toga se često naglašava
izbor najbolje optimalne konfiguracije alata CASE za datu konfiguraciju hardvera.
Heterogena mreža jedna je instanca distribuirane okoline i to će biti odabrano za
ilustraciju, jer mnogo je stila zbog svojih mogućnosti slobodnih uređaja. Implementacija
CASE alata u heterogenoj mreži koristi paradigmu klijent-poslužitelj. Višestruki kupci
koji izvode potpuno različite module pristupaju knjizi znanja putem ovog poslužitelja.
poslužitelj info wordbooka mogao bi podržati jedan ili puno dolaze. Iako je moguće

18
pokrenuti nekoliko poslužitelja za različite, distribuirana implementacija udžbenika
informacija nije uobičajena.
Skup alata integriran je kroz knjigu informacija koje podržava više jezgara, više
korisnika koji rade istovremeno i dozvolu za razmjenu podataka između korisnika i
dolazi. udžbenik s informacijama nudi dosljedno čitanje svih subjekata projekta, npr.
definicija zapisa znanja i njegov dijagram odnosa entiteta biti dosljedni. Poslužitelj bi
trebao prikazati logično čitanje knjige s podacima o projektu. ovo sugerira da bi trebalo
dopustiti sigurnosno kopiranje obnavljanje, kopiranje, čišćenje dijela info-knjige s
knjigama itd.
Alat bi trebao raditi zadovoljavajući za optimalno izvedivu raznolikost korisnika koji
rade istovremeno. Alat bi trebao podržavati okruženje s više prozora za korisnike, ovo je
često od vitalnog značaja za modificiranje korisnika da rade jedan po jedan dijagram u
isto vrijeme. Dodatno olakšava navigaciju i prebacivanje s jedne polovice na drugu.

8.1 PODRŠKA ZA DOKUMENTACIJU

Isporučivi dokumenti trebali bi biti organizirani shematski i možda bi mogli

sadržavati tekst i dijagrame iz središnjeg skladišta. To pomaže u izradi ažurne
dokumentacije. Alat CASE trebao bi se integrirati s jednim ili puno komercijalno
dostupnih paketa za publikaciju. Trebalo bi izvesti tekst, grafiku, tablice, izvještaje iz
udžbenika znanja u DTP paket u uobičajenim oblicima kao što je PostScript Alat CASE
trebao bi podržati sastavljanje, pohranjivanje i analizu podataka o napretku računalnog
koda, poput izračunave dužine zadatka, redovnog i stvarnog početka zadatka, datuma
završetka, datuma i rezultata pregleda itd.

8.2 VANJSKI INTERFEJS

Alat CASE trebao bi omogućiti razmjenu podataka radi ponovne upotrebe stila.
Podaci koji će se izvoziti pomoću CASE alata trebali bi biti idealno u Evropskom
standardnom kodeksu za razmjenu informacija i podržavati otvoreni dizajn. Slično tome,

19
udžbenik bi trebao dati programski interfejs za pristup informacijama koje su potrebne
za integraciju prilagođenih alata, izgradnju novih tehnika ili popunjavanje info-knjige.

8.3 OBRNUTI INŽENJERING

Alat CASE trebao bi podržati stvaranje strukturnih grafikona i znanja ka oi imati

odgovore na slijedeča pitanja.

• Kakav je alat CASE prikladan

• Koji su osnovni zahtjevi za alat
• Koje metode alata trebaju podržavati
• Koje su trenutno specifične značajke
• Koje su značajke potrebne za buduće potrebe

Odgovori na ova pitanja daju temelj za preliminarnu procjenu alata CASE. Alati koji ne
zadovoljavaju osnovne zahtjeve mogu se otkriti i izostaviti iz daljnjeg razmatranja.
Postoji puno kratkih analiza i ispitivanja lako dostupnih CASE alata koji u ovoj fazi
mogu biti korisni. Analiza trenutnih problema može rezultirati otkrivanjem ozbiljnih
nedostataka u trenutno korištenoj metodi, što ukazuje na potrebu za učinkovitijom i
formaliziranijom metodom. Koju metodu odabrati ovisi o raznim stvarima, ali treba
naglasiti da metode koje pružaju posebni alati često imaju veliki prioritet. Neki alati
imaju snažnu povezanost s dobro definiranim i fonitiziranim metodama i stoga
podržavaju veliku automatizaciju u različitim fazama razvoja sistema. Može biti
prikladno ispitati alate u ovoj klasi kada su potrebne nove i učinkovite metode. S druge
strane, ako se metoda koja se ranije koristi pokazala efikasnom i dobro definiranom,
prikladno je ispitati mogućnosti njezine implementacije unutar ljuske CASE. Problemi
ili posebne potrebe koje nemaju svoje porijeklo u metodi ili su povezane s određenim
kina aplikacijama, također bi se trebali uzeti u obzir pri odabiru.

20
 9. TEST ILI STVARNI SLUČAJ?

Postoje mogućnosti za procjenu alata CASE u praksi, može se koristiti više ili
manje idealan testni slučaj ili se alat može testirati u stvarnom projektu razvoja sistema.
Koju ćete strategiju odabrati ovisi o raspoloživom vremenu i resursima. Za preduzeće bi
moglo biti dobro imati dobro strukturirana izvješća koja se temelje na testnim
slučajevima kada trebaju donijeti brzu odluku ili nemaju potrebna sredstva za testiranje
alata u stvarnim projektima. Međutim, većina poduzeća ne može sama testirati brojne
alate, bez obzira na to jesu li koristili testni slučaj ili stvarni slučaj.
Čini se da su test slučajevi najprikladniji da ih koriste konzultantska poduzeća ili instituti
koji su specijalizirani za testiranje alata za razvoj sistema u svrhu objavljivanja rezultata.
Ispitni primeri služe i najjednostavnijim načinima ispitivanja i prototipa alata u svrhu
istraživanja.
Oni se mogu posebno koristiti za testiranje specifičnih značajki poput izražajnosti (to
jest, koliko vrsta detalja i ograničenja može se izraziti pomoću tehnika opisivanja alata).
Ispitivanje alata na sintetičkim ispitnim slučajevima je lakše i može se izvesti u bilo
kojem trenutku za razliku od stvarnih projekata. Postavljanje alata u stvarne i teške
slučajeve je, međutim, najpouzdaniji način dobivanja informacija o praktičnoj
vrijednosti alata i metoda kada se koriste u određenom okruženju. Drugi aspekt koji se
protivi ispitnim slučajevima je taj da su oni već konceptualizirani. Konceptualizacija
fizičkog i logičkog okruženja jedan je od glavnih problema u razvoju sistema i jedan od
glavnih razloga korištenja CASE alata.
Potpuni "opis slučaja" za testni slučaj nije ništa drugo do konceptualizacija virtualnog
okruženja. Procjena CASE alata u stvarnim projektima zahtijeva i financijska i
vremenska sredstva, ali odabir pravog alata i, još važnije, ispravne metode može
rezultirati znatnim uštedama u produktivnosti i kvaliteti sistema. Stoga poduzetnici s
mnogim teškim projektima i složenim računalnim sistemima vjerojatno najbolje služe
svojim ciljevima ako se odluče za nagradu na najbolji mogući način staviti u stvarne
projekte razvoja sistema.
Kada koristite sintetički test slučaj, treba uzeti u obzir neke važne aspekte. Dobar testni
slučaj nije previše sveobuhvatan u vremenu i trudu, a istovremeno je karakterističan i

21
dovoljno širok da obuhvati najvažnije dijelove određenog područja. Koji test odabrati
(ili dizajnirati) ovisi o vrsti predmetnog područja te o značajkama i problemima koje
treba ispitati. Testni slučaj trebao bi biti dobro definiran i opisan vrlo detaljno kako bi se
omogućilo osobama koje nemaju mogućnosti intervjuiranja "stvarnih korisnika" kako bi
ih mogle provesti u razumnom vremenu. Nejasne i dvosmislene opise treba izbjegavati.
U stvarnim se projektima troši mnogo vremena i truda za rješavanje problema s
nejasnim opisima i za modeliranje različitih vrsta rješenja za te probleme. Nije bitno
opterećivati testni slučaj ovim problemima, jer oni nisu dovoljno "produktivni" s
obzirom na utrošeno vrijeme i dobivene rezultate.
Ciljno okruženje sistema i vrsta sistema trebali bi odražavati test slučaj. Primjerice,
testni slučaj koji određuje informacijski sistem orijentiran na bazu podataka nije posebno
prikladan pri testiranju alata za upravljačke sisteme u stvarnom vremenu. Izbor testnog
slučaja od velike je važnosti za otkrivanje pravih značajki u pravom okruženju.
Često je moguće odabrati postojeći testni slučaj i koristiti ga samo s malim izmjenama.
Postoji nekoliko test slučajeva koji se često koriste pri testiranju i ocjenjivanju metoda
za razvoj sistema. Ovi su test slučajevi najčešće prikladni i za ispitivanje i procjenu alata
za razvoj sistema. Naravno, događa se da novi testni slučaj mora biti dizajniran od
početka, ali vjerovatno je da postoje "stvarni slučajevi" koji se mogu pojednostaviti i
izmijeniti bez previše napora.

10. PROVJERA PROTOKOLA

Protokol inspekcije predstavlja i tretira sve relevantne aspekte zabrinutosti

prilikom proučavanja alata CASE. Ti su aspekti službeno povezani s atributima alata i s
tim kako se trebaju postupati prilikom ocjenjivanja alata ili pisanja izvještaja. Svrha je
pružiti jednoličan i dobro definiran način provođenja studije i jednak tretman alata u
rezultirajućim izvješćima. Izvješća zasnovana na jednakim inspekcijskim protokolima
imaju jednaku strukturu i organizaciju što olakšava procjenu alata i njihovo
uspoređivanje. Preciznije, značajke od posebnog interesa pri konačnom odabiru alata se
lako može odabrati i detaljno ispitati. Pažljivo izvedeno izvršenje protokola također

22
pruža način ukazivanja na slabe točke proučavanih alata, što pomaže programerima da
pronađu moguća poboljšanja koja će biti otkrivena u budućim izdanjima.
Naglasili smo da testni slučaj treba odražavati neuobičajeno okruženje i posebno
zanimljive probleme. To vrijedi i za protokol. Protokol treba odražavati vrstu alata i
tretirati odgovarajuće značajke. Drugim riječima, protokol nije uobičajen u zdravom
smislu, više je ili manje prilagođen različitim vrstama CASE alata. Naravno, moglo bi se
koristiti opći i detaljan protokol koji vrijedi za sve vrste alata i tretirati samo one aspekte
koji nisu relevantni za trenutni alat.

11. ZAKLJUČAK

U ovom radu smo predstavili rad i funkcionalnost CASE alata kao i njihov način
interkcije sa okolinom. Postavlja se pitanje upotrebljivosti “Use-Case” alata u praksi,
odnosno da li ih treba koristiti ili ne. Kao prvo trebamo uzeti u obzir naše iskustvo na
dosadašnjim projektima, znači kompletan portfolio, sposobnosti našeg programerskog
tima da izvede zadatak na određenom nivou, infrastruktura koju posjedujemo kao i
kvaliteta menadžerskog i operativnog kadra. Mislim da se trenutno nazire pravac u
kojem se krećemo. Ako smo relativno nova kompanija bez puno prethodnih iskustava,
onda bi trebali uzeti u obzir rad i vodjenje projekta bez upotrebe CASE alata, s obzirom
da postoji mišljenje kako pretvaranje korisničkih zahtjeva u model ili kod može

23
 imati veoma ne-determinističke rezultate što u konačnici dovodi do zabune i kaosa gdje
ne možemo imati model tzv. jedno rješenje za sve. Sa druge strane, ako imamo
kompaniju koja je već duže vrijeme na tržištu, i koja ima zavidan portfolio, onda bi ona
definitivno imala koristi od automatizacije procesa koje sa sobom nose “use-case” alati.
Ipak sve se svodi na razmišljanje o tome da li ovi alati donose odredjenu vrijednost
kompaniji u njenom poslovanju. Često će menadjeri dati inicijativu o upotrebi CASE
alata, samo zbog toga što su čuli za njih, ali ne uzimaju u obzir da li će tako nešto imati
uspješnu integraciju u trebutne procese i koliko će razvojni timovi moći da se adaptiraju
na novi način rada.
U svakom slučaju ovakve promjene su dobro došle i mogu samo podići nivo poslovanja
i organizacije rada na visočiju tehnološku ljestvicu.

12. LITERATURA

1. Frank Armour: Advanced use case modeling: (Decembar, 2000)

2. Ivar Jacobson: UML Distilled: An Agile Toolkit (Septembar.25.2003)
3. Schneider & Winters: Applying Use Cases: (2001)
4. Case Tools Overview:
https://www.tutorialspoint.com/software_engineering/case_tools_overview.htm
5. SDLC models: http://learnoraclefromoracle.blogspot.com/2015/03/the-agile-system-
in-sdlc.html (Dec 2019)

24
6. Larson Elizabeth: https://www.pmi.org/learning/library/use-cases-project-manager-
know-8262 (26 Okt. 2005)
7. Primjeri Dijagrama: http://30.1.adopt.computernote.de/use-cases-diagram.html (16
Feb. 2020)
8. Tapani J. Kinnula: How to test and compare CASE tools (Jan. 1989)

25