Use-case diagram Situacija gdje se sustav koristi za ispunjenje korisničkih zahtjeva te prikazuje djelić funkcionalnosti koju sustav pruža Opisuje funkcionalne zahtjeve sustava promatranih izvana Prikaz vrijednost koju sustav pruža korisnicima Kreira se u ranim fazama oblikovanja (najčešće kao prvi dijagram) Logički pogled Procesni pogled Pogled slučaja korištenja Fizički pogled Razvojni pogled 1
Prikazuju samo ono što sustav treba raditi (funkcionalne zahtjeve) Bitno je funkcionalne zahtjeve otkriti i prikazati na početku projekta (ušteda vremena i novca kasnije) Prikazuje ponašanje sustava kako ga vidi korisnik Aktivnosti visoke razine (high-level) Odgovara na nekoliko pitanja: (Seidl i dr., 2012) Što se opisuje? (sustav) Tko ima interakciju sa sustavom? (sudionici) Što sudionici mogu činiti? (slučajevi korištenja) ZAHTJEV A.1 Aplikacija za prijavu na diplomski studij treba omogućiti studentu prijavu u aplikaciju koristeći dobivene korisničke podatke. Prvi korak: odrediti tko/što je u interakciji sa sustavom! SUDIONICI 2
Vanjski entitet povezan sa sustavom, ali nije dio sustava Inicira neke akcije Stvarna osoba ili neki drugi sustav (npr. aplikacija) Imaju imena koja ne bi smjela biti povezana s organizacijom poduzeća Pisati kao imenicu u jednini Kako znati tko je sudionik čitajući zahtjeve sustava? Ne može se mijenjati, nije bitno na koji način radi, ali mora imati interakciju sa sustavom Drugi korak: pronaći slučajeve gdje se sustav koristi za izvršenje određenih zadataka sudionika! SLUČAJEVI KORIŠTENJA Slučajevi korištenja se identificiraju analizom dokumenata sa zahtjevima Ti dokumenti obuhvaćaju specifikacije napisane prirodnim jezikom koje objašnjavaju što korisnik želi od sustava 3
Apstraktni zadatak kojeg izvode sudionici Pisati kao glagol (radnja) jednostavnost Opisuju zadatke koje sustav obavlja, a koji su definirani u korisničkim zahtjevima Pruža mjerljivi rezultat korisniku jer iz njegove perspektive prikazuje cjelovito funkcioniranje sustava Da bi se analizom zahtjeva lakše uočilo slučajeve korištenja, potrebno je razraditi scenarij SCENARIJ - slijed koraka koji opisuju interakciju između sudionika i sustava Primjer scenarija: Web trgovina Kupac pretražuje web katalog proizvoda i dodaje željene proizvode u košaricu. U trenutku kupnje, kupac odabire mjesto dostave te daje podatke o kreditnoj kartici i potvrđuje kupnju. Sustav nakon toga provjerava valjanost kreditnu kartice, potvrđuje kupnju i šalje e-mail potvrde kupovine. 4
Prikazan je glavni (uspješni) scenarij Autorizacija kreditne kartice uspješna/neuspješna ALTERNATIVNI SCENARIJ Kreditna kartica je odbijena! Kupovina proizvoda je obustavljena! 1. Kupac pregledava katalog i odabire proizvode 2. Kupac potvrđuje proizvode 3. Kupac upisuje informacije o dostavi (npr. idući dan ili za 3 dana) 4. Sustav prikazuje punu cijenu sa dostavom 5. Kupac popunjava informacije o kred. kartici 6. Sustav autorizira kupnju 7. Sustav potvrđuje prodaju 8. Sustav šalje e-mail potvrde kupcu 5
1. Klijent ubacuje karticu u bankomat 2. Sustav traži PIN 3. Klijent upisuje PIN 4. Klijent potvrđuje unos tipkom Enter 5. Sustav provjerava valjanost PIN-a 6. Kartica autorizirana, sustav traži da klijent odabere ili unese željeni iznos 7. Klijent odabire iznos i potvrđuje ga 8. Sustav isplaćuje novac klijentu Vrsta veze Način prikaza Asocijacija Generalizacija Uključivanje <<include>> Proširenje <<extend>> 6
Sudionici se povezuju slučajevima korištenja Student sudjeluje u zadatku odabira studijskog smjera Označava da je sudionik ili slučaj korištenja vrsta drugog sudionika ili slučaja korištenja I redoviti i izvanredni student su studenti I stručni i sveučilišni studij su studiji 7
Povezuje dva slučaja korištenja Jedan slučaj korištenja u tijeku svog izvođenja u potpunosti izvodi drugi SK Prvi slučaj korištenja uključuje drugog ZAHTJEV A.2 Aplikacija za prijavu na diplomski studij treba omogućiti studentu upis nove akademske godine (studija). Da bi upisao studij, student mora odabrati izborne kolegije te željeni smjer 8
Povezuje dva slučaja korištenja pri čemu jedan proširuje funkcionalnost drugog (ako je zadovoljen određen uvjet) Veza uvijek ide od proširujućeg prema osnovnom SK ZAHTJEV A.3 Aplikacija za prijavu na diplomski studij treba omogućiti studentu ispunjavanje pristupnice za volontiranje na fakultet, ako student to želi. Prilikom upisa, student može (a ne mora) ispuniti i pristupnicu za volontiranje Korisnik se prijavljuje u sustav web trgovine, ali ako nema korisnički račun, mora se registrirati Klijent banke podnosi zahtjev za novom karticom, a u slučaju da njegova plaća prelazi 5.000 kn, može ostvariti i dodatnu Diners karticu 9
Služe za jasno odvajanje sudionika (koji nisu dio sustava) od samog sustava Crtaju se na način da se sve slučajeve korištenja stavi u jedan kvadrat Kvadratu se najčešće daje ime samog sustava Treći korak: opisati slučajeve korištenja! Dijagrami ne mogu pružiti dovoljno detalja dizajnerima sustava: Tko je najvažniji sudionik? Koji su koraci tog slučaja korištenja? Najčešće se dodatno opisuju složeniji sustavi Opisuje se SVAKI slučaj korištenja u modelu 10
Otprilike 1-2 stranice po slučaju korištenja Primjer informacija za opis SK: (prilagođeno prema Miles, Hamilton, 2006; Cockburn, 1997) Naziv SK Kratki opis SK Preduvjet: što mora biti napravljeno prije nego se SK može izvršiti Uspješno stanje: stanje sustava ako se SK uspješno izvrši Neuspješno stanje: stanje sustava ako se SK neuspješno izvrši Sudionici: tko su sudionici koji su vezani za taj SK Okidač: događaj pokrenut od strane sudionika koji je uzrok izvršenja slučaja korištenja Glavni scenarij: koraci koji su potrebni za izvršenje SK Alternativni scenarij: alternativni koraci koji nisu u glavnom scenariju Naziv: Kratki opis: Preduvjet: Uspješno stanje: Neuspješno stanje: Sudionici: Okidač: Glavni scenarij: Alternativni scenarij: Prijavi se u sustav Student se prijavljuje u aplikaciju za upis nove akademske godine. Student studira na EFOS-u. Student posjeduje sve korisničke podatke. Student se uspješno prijavio u sustav. Student se nije prijavio u sustav. Student Student želi upisati novu akademsku godinu. 1. Student upisuje web adresu aplikacije 2. Student unosi korisničko ime i lozinku 3. Student je prijavljen u sustav 3.1. Studentu je odbijena prijava zbog pogrešnog korisničkog imena i/ili lozinke 11
ZADATAK 1 Modelirati sustav Studomat dijagramom slučajeva korištenja Studomat treba omogućiti referadi unos ispitnih rokova (odabir vremena roka i dvorane u kojoj se ispit održava), a studentima njihovu prijavu/odjavu. Također, na studomatu je moguće pregledati uspješnost svakog kolegija te ispisati razne potvrde. ZADATAK 2 Modelirati sustav za prodaju karata za kazalište dijagramom slučajeva korištenja Sustav za prodaju karata koriste blagajnik i kupac. Kupac dolazi u kazalište i traži kartu za predstavu. Blagajnik prodaje kartu što uključuje odabir željenog sjedala i naplatu. Kupac ima mogućnost platiti kartu gotovinom ili putem debitne kartice. Ako kupac zatraži, prilikom prodaje karte, blagajnik mu može izdati R1 račun. Isto tako, kupac je mogao doći i samo rezervirati kartu ostavljajući svoje osobne podatke. 12
ZADAĆA 1 Modelirati sustav za prijavu teme seminarskog rada dijagramom slučajeva korištenja Sustav za prijavu tema seminarskih radova koriste profesori i studenti. Profesor preko aplikacije za određeni kolegij ponudi studentima teme seminara i moguće termine prezentacija (izlaganja) te ograničava broj studenata u timu. Prije toga, profesor mora unijeti sve studente nekog kolegija u aplikaciju. Studenti se najprije moraju prijaviti u aplikaciju pomoću svog AAI@Edu.hr korisničkog računa. Student potom odabire željeni kolegij (mora biti unesen na taj kolegij od strane profesora) te nakon toga bira slobodnu temu, članove tima i termin prezentacije. Klikom na gumb Potvrdi, potvrđuje uneseno te se odjavljuje iz aplikacije. Literatura korištena u ovom poglavlju: 1. Cockburn, A. (1997). Goals and Use Cases. Journal of Object- Oriented Programming, Vol. 10, No. 5, pp. 35-40. 2. Miles, R., Hamilton, K. (2006). Learning UML 2.0. Sebastopol: O Reilly Media. 3. Seidl, M. i dr. (2012). UML @ Classroom. An Introduction to Object-Oriented Modeling. NJ: Springer. 13