1.

PRIMJER 1

Funkcionalni zahtjevi

Dionici, odnosno osobe koje imaju interes u danom sustavu su svi zaposlenici auto-
servisa, redom:

Mehaniar
Elektriar
Voditelj servisa
Direktor servisa

Aktori, odnosno entiteti koji na neki nain sudjeluju u radu sustava su:

Servisni savjetnik, inicijator

o Moe pregledavati stanje skladita
o Moe pregledavati radne naloge
Voditelj servisa, inicijator
o Prima nove stranke, zaprima podatke novih stranaka
o Otvara radne naloge
o Zatvara radne naloge
o Stornira radne naloge
o Aurira radne naloge
o Unosi podatke o rezervnim dijelovima
o Moe pregledavati stanje skladita
o Moe pregledavati radne naloge
Direktor servisa, inicijator
o Moe pregledavati dnevni, mjeseni i godinji promet, kao i dnevni,
mjeseni i godinji bilancu (obraun) servisa
Stranka, sudionik

1
 o Predaje vozilo u servis te na taj nain pokree rad servisa te indirektno
radnicima servisa osigurava posao
o Plaa za obavljene radove na vozilu
Baza podataka, sudionik
o Sadrava sve podatke o radu servisa, ukljuujui otvorene, stornirane i
zatvorene naloge, stanje skladita, dnevnu, mjesenu i godinju bilancu i
promet servisa te popis moguih postupaka na vozilima, kao i
registracijske podatke svih zaposlenika servisa

Elektriar i mehaniar imaju jednaka prava i ovlasti te smo ih poopili u jedinstvenu

osobu pod nazivom servisni savjetnik.

Svi aktori koji su ujedno i inicijatori imaju mogunost prijave u raunalni sustav servisa
te su radi toga u dijagramu obrazaca uporabe vezom generalizacije povezani s
jedinstvenim aktorom imena korisnik.

Opis obrazaca uporabe:

UC1 PrijavaUSustav
o Glavni sudionik: Korisnik.
o Cilj: Autorizacija korisnika registriranog u sustavu.
o Sudionici: Baza podataka.
o Preduvjeti: Pristup raunalu, pristup mrei, prethodna registracija korisnika u
sustavu.
o Rezultat: Glavni sudionik je prijavljen u sustav.
o eljeni scenarij:
1. Korisnik na umreenom raunalu pokree internetski preglednik te pokuava
pristupiti aplikaciji auto-servisa.
2. Korisnik unosi svoje korisniko ime.
3. Korisnik unosi odgovarajuu lozinku.
4. Korisnik je uspjeno prijavljen u sustav i dodjeljuju mu se unaprijed odreene
ovlasti za njegov korisniki raun.

2
 o Mogui scenarij: Neuspjean pokuaj prijave u sustav zbog nepostojeeg
korisnikog rauna ili pogrene lozinke.

UC2 OtvaranjeRadnogNaloga
o Glavni sudionik: Voditelj servisa.
o Cilj: Stvaranje novog radnog naloga.
o Sudionici: Stranka, baza podataka.
o Preduvjeti: Pristup raunalu, pristup mrei, prethodna prijava voditelja servisa u
sustav, postojanje vozila kojemu je potreban servis.
o Rezultat: U bazi podataka je stvoren novi radni nalog sa svim potrebnim
podacima.
o eljeni scenarij:
1. Stranka doprema svoje vozilo u auto-servis te se javlja voditelju.
2. Voditelj servisa u aplikaciji odabire opciju za izradu novog naloga.
3. Voditelj servisa od stranke saznaje podatke i to redom: ime, prezime, adresu
(opcionalno) i kontakt telefon stranke, zatim model, godite i registarsku oznaku
vozila te opis kvara ili popis postupaka na vozilu koje stranka potrauje.
4. Voditelj servisa potvuje unesene podatke te je novi nalog stvoren u bazi.
o Mogui scenarij: Odustaje se od izrade naloga zbog nemogunosti servisa
(nedostatka ili manjka potrebnih dijelova, nedovoljne strunosti ili nedovoljnog
broja servisnih radnika) da obavi potrebne ili eljene postupke na vozilu.

UC3 StorniranjeRadnogNaloga
o Glavni sudionik: Voditelj servisa.
o Cilj: Otvoreni radni nalog se stornira.
o Sudionici: Baza podataka.
o Preduvjeti: Pristup raunalu, pristup mrei, prethodna prijava voditelja servisa u
sustav, postojanje otvorenog radnog naloga.
o Rezultat: Otvoren radni nalog u bazi se stornira.
o eljeni scenarij:
1. Voditelj servisa pristupa popisu naloga.
2. Voditelj servisa oznaava otvoreni radni nalog koji eli stornirati.
3. Voditelj servisa odabirom opcije mijenja status naloga iz otvoren u
storniran.

3
 UC4 ZatvaranjeRadnogNaloga
o Glavni sudionik: Voditelj servisa.
o Cilj: Zatvaranje otvorenog radnog naloga.
o Sudionici: Stranka, baza podataka.
o Preduvjeti: Pristup raunalu, pristup mrei, prethodna prijava voditelja servisa u
sustav, postojanje otvorenog radnog naloga.
o Rezultat: Otvoreni radni nalog u bazi je zatvoren.
o eljeni scenarij:
1. Servisni radnici informiraju voditelja servisa kako su radovi na vozilu uspjeno
izvreni.
2. Voditelj servisa informira stranku o zavretku radova te po dolasku stranke u
servis u aplikaciji pokree raunanje ukupnog troka popravaka i rezervnih
dijelova.
3. Nakon to stranka podmiri financijska potraivanja servisa, voditelj servisa
zatvara nalog koji se kao takav sprema u bazu te se pokree auriranje dnevne
bilance servisa.

UC5 PromjenaRezervnogDijela
o Glavni sudionik: Voditelj servisa.
o Cilj: Unos rezervnog dijela u dio baze podataka koji reprezentira skladite.
o Sudionici: Baza podataka.
o Preduvjeti: Pristup raunalu, pristup mrei, prethodna prijava voditelja servisa u
sustav.
o Rezultat: U bazi podataka koja predstavlja skladite auto-servisa aurirana je
koliina ve postojeeg rezervnog dijela.
o eljeni scenarij:
1. Voditelj servisa je informiran o pristiglom rezervnom dijelu.
2. Voditelj servisa u aplikaciji odabire opciju za auriranje skladita.
3. Voditelj servisa unosi koliinske podatke o pristiglom rezervnom dijelu,
odnosno mijenja ve postojei na nain da smanjuje koliinu ve postojeeg.
o Mogui scenarij: Navedeni dio ve postoji u bazi/skladitu te se u tom sluaju
koliina ve postojeeg dijela poveava.

4
 UC6 PregledSkladita
o Glavni sudionik: Servisni savjetnik ili voditelj servisa ili direktor servisa.
o Cilj: Saznati stanje svih raspoloivih dijelova na skladitu.
o Sudionici: Baza podataka.
o Preduvjeti: Pristup raunalu, pristup mrei, prethodna prijava u sustav.
o Rezultat: Zaposleniku se na zaslonu raunala prikae popis svih rezervnih
dijelova trenutno raspoloivih na skladitu, kao i njihova trenutna koliina.
o eljeni scenarij:
1. Zaposlenik sustava putem aplikacije potrauje trenutno stanje skladita.
2. Na zaslonu raunala s kojeg je podnesen zahtjev mu se prikae stanje
skladita poimence popis svih raspoloivih dijelova te njihova koliina.

UC7 PregledNaloga
o Glavni sudionik: Servisni savjetnik ili voditelj servisa.
o Cilj: Prikaz eljenih naloga iz baze podataka.
o Sudionici: Baza podataka.
o Preduvjeti: Pristup raunalu, pristup mrei, prethodna prijava u sustav,
postojanje naloga u bazi podataka.
o Rezultat: Na zaslonu se prikau eljeni nalozi dohvaeni iz baze podataka.
o eljeni scenarij:
1. Zaposlenik u aplikaciji odabire opciju pretrage baze podataka.
2. Sustav mu vraa naloge koji odgovaraju njegovom potraivanju.
o Mogui scenarij: Nemogunost sustava da vrati nalog u sluaju loe definiranih
ili nepostojeih parametara.

UC8 AuriranjeNaloga
o Glavni sudionik: Voditelj servisa.
o Cilj: Promjena odreenog segmenta ve otvorenog radnog naloga.
o Sudionici: Baza podataka.
o Preduvjeti: Pristup raunalu, pristup mrei, prethodna prijava voditelja servisa u
sustav, postojanje naloga nad kojim se vri promjena.
o Rezultat: Promijenjen je eljeni podatak u odreenom radnom nalogu.
o eljeni scenarij:

5
 1. Voditelj servisa u aplikaciji pristupa popisu otvorenih radnih naloga te odabire
radni nalog nad kojim eli izvriti promjenu.
2. Voditelj servisa odbire stavku (podatak, servisni postupak ili rezervni dio) koji
eli promijeniti ili pobrisati, odnosno odabire opciju za dodavanje ukoliko je
potrebno dodati novi servisni postupak.
3. Voditelj servisa potvruje obavljene izmjene nad nalogom te se aurirani nalog
sprema u bazu podataka.
o Mogui scenarij: Nemogunost izmjene naloga (dodavanja ili promjene
rezervnih dijelova) zbog nedostatka potrebnih dijelova u skladitu.

UC9 PrikazPrometaServisa
o Glavni sudionik: Direktor servisa.
o Cilj: Prikaz prometa auto-servisa.
o Sudionici: Baza podataka.
o Preduvjeti: Pristup raunalu, pristup mrei, prethodna prijava direktora servisa u
sustav.
o Rezultat: Prikazuje se promet i bilanca auto-servisa za eljeni dan, mjesec i/ili
godinu.
o eljeni scenarij:
1. Direktor servisa u aplikaciji odabire opciju za prikaz prometa odnosno bilance
sustava te odabire eljeno vremensko razdoblje.
2. Na zaslonu se prikazuju eljeni podaci vezani uz financijsko poslovanje auto-
servisa.
o Mogui scenarij: Zahtjev za prikazom bilance je odbijen jer se jo nije dogodio
obraun potreban za izraun eljene bilance servisa.

6
Slika 1.1. Dijagram obrazaca uporabe 7
2. PRIMJER 2
Funkcionalni zahtjevi

Dionici:
Korisnik
Administrator centrale
Neovlatena osoba (provalnik)

Aktori i njihovi funkcionalni zahtjevi:

Korisnik, inicijator: Namjeta nain upravljanja (automatsko ili runo). Mijenja
podatke o sustavu u bazi podataka (definira i podeava listu MSISDN brojeva za
razne sluajeve dojave nadzornog sustava, mijenja podatke o senzorima u
sustavu).

Senzori, sudionici: alju signal sustavu prilikom njihove aktivacije, tj. u sluaju
detekcije nedozvoljenog pristupa javljaju sustavu da ukljui sirenu i prikljuene
svjetlosne pokazatelje, te da alje SMS na sve MSISDN brojeve definirane u
posebnoj listi (senzori pokreta, kontaktni senzori), te senzor vanjskog osvjetljenja
alje sustavu informaciju je li dan ili no .

Operater centrale, inicijator: Mijenja podatke o sustavu u bazi (identifikator

nadzornog sustava, dolazne poruke koje sustav alje centrali) te moe alarmirati
policiju koristei svoje korisniko suelje.

Baza podataka, sudionik: Sprema podatke o sustavu (listu MSISDN brojeva,

podatke o senzorima, identifikator sustava)

Interni sat, sudionik: Sat sustava koji normalno prati vrijeme ak i kada nestane
vanjskog napajanja, te za vrijeme dojave nedozvoljenog dogaaja vrijeme
poslano SMS-om se oitava s njega njemu, a ako nestane vanjskog napajanja
sustav prati njega, te alje poruke svakih sat vremena

Neovlatena osoba (provalnik), inicijator: Prilikom pokuaja nedozvoljenog

ulaska u objekt aktivira kontaktne senzore ili senzore pokreta

Nestanak vanjskog napajanja, inicijator: Dogaaj nestanka napajanja sa gradske

elektrine mree na koju je sustav prikljuen

8
Opis obrazaca uporabe

1. UC1 NedozvoljeniDogaaj
Glavni sudionik: Provalnik
Cilj: Detektirati nedozvoljeni pristup, te obavijestiti korisnike o provali
Sudionici: Senzor (senzor pokreta ili kontaktni senzor), baza podataka, interni sat
Preduvjeti: Nadzorni sustav ukljuen, konfigurirana lista brojeva mobilnih telefona
Rezultat: Pri detekciji nedozvoljenog dogaaja odmah ukljuiti sirenu i prikljuene
svjetlosne pokazatelje, te poslati SMS poruke na sve MSISDN brojeve definirane u
posebnoj listi
eljeni scenarij:
1. Provalnik pokuava ui u objekt te aktivira kontaktne senzore ili senzore pokreta
2. Aktivacijom senzora ukljuuje se sirena, te prikljuni svjetlosni pokazatelji (rotirajue
svjetlo) i ako senzor vanjskog osvjetljenja javlja da je no, takoer, ukljuuje reflektore
na objektu u dvoritu
3. Aktivacijom senzora, sustav postavlja upit nad bazom podataka za brojeve definirane
za sluaj nedozvoljenog dogaaja i na te brojeve alje SMS poruke, koje sadravaju
jedinstveni identifikacijskih broj instalacije sustava, informacije o vremenu kada je
detektiran nedozvoljenih dogaaj i senzoru koji ga je detektirao
5. Nakon prestanka opasnosti, korisnik iskljuuje dojavu nedozvoljenog dogaaja
(sirenu, svjetlosne pokazatelje)

2. UC2 - NestanakVanjskogNapajanja
Glavni sudionik: Nestanak vanjskog napajanja
Cilj: Ukljuiti vlastiti izvor napajanja, te dojaviti nestanak vanjskog napajanja na brojeve
definirane za to
Sudionici: Baza podatka, interni sat
Preduvjeti: Konfigurirana lista brojeva mobilnih telefona
Rezultat: Ukljuen vlastiti izvor napajanja, slanje SMS poruke na brojeve definirane za
taj sluaj, te ponavljati slanje svakih sat vremena dok sustav u potpunosti ne ostane bez
napajanja

9
eljeni scenarij:
1. Iz bilo kojeg razloga (kvar, sabotaa) nestaje vanjskog napajanja, pa sustav ne
dobiva energiju iz gradske mree na koji je prikljuen
2. Sustav aktivira vlastiti izvor napajanja
3. Sustav postavlja upit nad bazom podataka za brojeve definirane za sluaj nestanka
vanjskog napajanja i na te brojeve alje SMS poruke, koje obavjetavaju odgovarajue
osobe o tom sluaju
4. Sustav ponavlja slanje SMS poruka svakih sat vremena (prema internom satu) sve
dok u potpunosti ne ostane bez napajanja

3. UC3 - AuriranjePodataka
Glavni sudionik: Korisnik
Cilj: Unijeti promjene u bazi podataka sustava
Sudionici: Baza podataka
Preduvjet: nema
Rezultat: Konfigurirani ili promijenjeni podaci sustava (MSISDN brojevi za razne
sluajeve, podaci o broju i tipovima senzora)
eljeni scenarij:
1. Korisnik se preko korisnikog suelja prijavi na sustav unosom tajne brojane ifre
2. Izabire koje podatke eli mijenjati
3. Sustav se povezuje sa bazom podataka
4. Mijenja podatke u bazi
5. Korisnik se odjavi iz sustava
Mogui drugi scenarij:
1. Ako korisnik prilikom pristupa sustavu tri puta zaredom unese neispravnu ifru,
odmah se ukljuuje alarm i registrira nedozvoljeni dogaaj (UC1)

4. UC4 - OdabirUpravljanja
Glavni sudionik: Korisnik

10
Cilj: Odabrati nain upravljanja sustavnom
Sudionici: nema
Preduvjet: nema
Rezultat: Odabran jedan od dva naina upravljanja nadzornim sustavom (automatski ili
runo)
eljeni scenarij:
1. Korisnik se preko korisnikog suelja prijavi na sustav unosom tajne brojane ifre
2. Korisnik odabire opciju izabiranja naina upravljanja
3. Izabire nain upravljanja (automatski ili runo)
4. Korisnik se odjavi iz sustava
Mogui drugi scenarij:
1. Ako korisnik prilikom pristupa sustavu tri puta zaredom unese neispravnu ifru odmah
se ukljuuje alarm i registrira nedozvoljeni dogaaj (UC1)

5. UC5 - NedozvoljniDogaajOp
Glavni sudionik: Operater
Cilj: Alarmirati policiju
Sudionici: nema
Preduvjet: Konfiguriran nadzorni sustav
Rezultat: Policija obavjetena
eljeni scenarij:
1. Na osnovi dobivenih i pohranjenih podataka u centrali, operater centrale uoi neku
nepravilnost ili nedozvoljeni dogaaj
2. Operater alarmira policiju preko svog korisnikog suelja

6. UC6 - AuriranjePodatakaOp
Glavni sudionik: Operater centrale
Cilj: Unijeti promjene u bazi podataka sustava
Sudionici: Baza podataka

11
Preduvjet: nema
Rezultat: Konfigurirani ili promijenjeni podaci sustava (identifikator nadzornog sustava,
dolazne poruke koje sustav alje centrali)
eljeni scenarij:
1. Operater se preko svoga korisnikog suelja prijavi na sustav unosom tajne brojane
ifre
2. Izabire koje podatke eli mijenjati
3. Sustav se povezuje sa bazom podataka
4. Mijenja podatke u bazi
5. Operater se odjavi iz sustava

Slika 1.0. Obrazac uporabe za UC1 do UC6

12
3. PRIMJER 3

Funkcionalni zahtjevi
Dionici:

Korisnici
Administrator
Sponzori
Statistiari

Aktori i njihovi funkcionalni zahtjevi:

Korisnik, inicijator:
o Dolazi na birako mjesto i prijavljuje se svojom jedinstvenom ip karticom na
sustav i obavlja glasovanje. Komunicira sa sustavom.
Baza podataka, sudionik:
o Pohranjuje listu sudionika glasovanja i rezultate glasovanja. Komunicira sa
sustavom.
Sustav za e-glasovanje, sudionik:
o Prikuplja i obrauje podatke i sprema ih u bazu podataka. Komunicira s
administratorom.
Administrator, inicijator:
o Kreira izborne liste i po potrebi ih mijenja ili brie, komunicira sa sustavom.

Opis obrazaca uporabe:

UC1 Kreiranje i izmjena liste:

o Glavni sudionik: Administrator.
o Cilj: Prema danim kriterijima kreiraju se (ili mijenjaju) izborne liste. Sustav stvara
ili mijenja liste na administratorovu inicijativu.
o Sudionici: Administrator, sustav za e-glasovanje, baza podataka.
o Preduvjeti: nema.
o Rezultat: stvaranje ili mijenjanje izborne liste i pohrana rezultata.

13
 o eljeni scenarij:
1. Administrator predaje zahtjev za kreiranje (ili dohvat) liste sustavu.
2. Sustav kreira listu ili dohvaa listu iz baze podataka u sluaju izmjene liste.
3. Kreirana (ili izmijenjena) lista se uspjeno upisuje u bazu podataka.
o Mogui drugi scenariji:
4. Sustav ne moe kreirati listu.
1. Sustav obavjetava korisnika da se lista ne moe kreirati.
2. Korisnik postavlja modificirani upit ili odustaje od kreiranja.
5. Sustav ne uspije predati zahtjev bazi podataka za spremanje (ili dohvatom)
liste.
1. Sustav obavjetava korisnika da se lista ne moe dohvatiti iz baze
podataka.
2. Korisnik postavlja modificirani upit ili odustaje od izmjene.
6. Baza podataka ne uspije vratiti zahtijevanu listu.
1. Sustav obavjetava korisnika da se lista ne moe dohvatiti.
2. Korisnik postavlja modificirani upit ili odustaje od dohvata.

Slika 3.1 Use Case dijagram za UC1 (Kreiranje i izmjena liste)

UC2 Glasovanje:
o Glavni sudionik: Korisnik.
o Cilj: Uspjeno glasovanje za odreenog kandidata.

14
o Sudionici: Korisnik, sustav za e-glasovanje, baza podataka.
o Preduvjeti: uspjena prijava na sustav
o Rezultat: Korisnikov glas uspjeno spremljen u bazu podataka.
o eljeni scenarij:
1. Korisnik dolazi na birako mjesto.
2. Sustav trai od korisnika ip karticu.
3. Sustav provjerava je li korisnikova kartica upisana u bazi podataka.
4. Sustav odobrava prijavu.
5. Korisnik odabire eljenog kandidata i potvruje svoj odabir.
6. Sustav sprema korisnikov odabir u bazu podataka.
o Mogui drugi scenariji:
7. Korisnikova ip kartica nije upisana u bazu podataka ili nije aktivna.
1. Sustav obavjetava korisnika da ima neispravnu ip karticu.
2. Korisnik kontaktira administratora ili odustaje od glasanja.
8. Korisnik je neuspjeno prijavljen na sustav.
1. Sustav obavjetava korisnika da ga ne moe prijaviti.
2. Korisnik kontaktira administratora ili odustaje od glasanja.
9. Sustav nije uspio spremiti korisnikov odabir kandidata.
1. Sustav obavjetava korisnika da njegov glas nije uspjeno unesen.
2. Korisnik postavlja ponovni upit ili odustaje od glasovanja.

Slika 3.2 Use Case dijagram za UC2 (Glasovanje)

15
 UC3 Prikupljanje i obrada podataka:
o Glavni sudionik: Administrator.
o Cilj: Prikupljanje podataka o glasovanju, prikaz podataka u sustavu te pohrana
podataka u bazu podataka.
o Sudionici: Administrator, sustav i baza podataka.
o Preduvjeti: Podatci se prikupljaju i obrauju nakon zatvaranja biralita (istek
brojaa).
o Rezultat: Obrada svih glasova nakon zatvaranja biralita.
o eljeni scenarij:
1. Administrator predaje zahtjev za prikupljanje podataka o glasovanju
sustavu.
2. Sustav prikuplja podatke iz baze podataka te ih analizira i daje ih
administratoru na uvid kad ih on zatrai ili ako su podaci o glasanju novi,
sustav ih pohranjuje u bazu podataka.
3. Sustav provjerava da li je glasa glasovao, ako jest, sprema podatak u
bazu. Na samom isteku roka, baza podataka daje podatke sustavu na
daljnju analizu.
o Mogui drugi scenariji:
4. Sustav ne moe dohvatiti podatke iz baze.
1. Sustav obavjetava korisnika da se lista ne moe dohvatiti.
2. Korisnik postavlja modificirani upit ili odustaje od dohvaanja.
5. Sustav ne uspije predati zahtjev bazi podataka za spremanje (ili dohvatom)
liste.
1. Sustav obavjetava korisnika da se lista ne moe dohvatiti iz baze
podataka.
2. Korisnik postavlja modificirani upit ili odustaje od izmjene.
6. Baza podataka ne uspije vratiti zahtijevanu listu.
1. Sustav obavjetava korisnika da se lista ne moe dohvatiti.
2. Korisnik postavlja modificirani upit ili odustaje od dohvata.

16
 Slika 3.3 Use Case dijagram za UC3 (Prikupljanje i obrada podataka)

UC4 Objava rezultata glasanja:

o Glavni sudionik: Administrator.
o Cilj: Nakon to je zavrilo glasanje, podatci su se analizirali i stvorena je statistika.
Cilj je na zahtjev administratora prikazati tu statistiku.
o Sudionici: Administrator, Sustav e glasovanja, baza podataka.
o Preduvjeti: Istek vremena za glasovanje te analiza prikupljenih podataka.
o Rezultat: Objavljena statistika svih stranka za sve izborne jedinice.
o eljeni scenarij:
1. Administrator zatrauje objavu rezultata od sustava koju mu sustav
odobrava ako su rezultati spremni.
2. Baza podataka gotove rezultate i statistike daje sustavu. Sustav ih nakon
odobravanja objavljuje i daje administratoru na uvid.
o Mogui drugi scenariji:
3. Sustav ne moe dohvatiti podatke iz baze.
1. Sustav obavjetava korisnika da se lista ne moe dohvatiti.
2. Korisnik postavlja modificirani upit ili odustaje od dohvaanja.
4. Korisnik postavlja modificirani upit ili odustaje od izmjene. Sustav ne uspije
predati zahtjev bazi podataka za spremanje (ili dohvatom) liste.
1. Sustav obavjetava korisnika da se lista ne moe dohvatiti iz baze
podataka.
2. Korisnik postavlja modificirani upit ili odustaje od izmjene.

17
 5. Baza podataka ne uspije vratiti zahtijevanu listu.
1. Sustav obavjetava korisnika da se lista ne moe dohvatiti.
2. Korisnik postavlja modificirani upit ili odustaje od dohvata.

Slika 3.4 Use Case dijagram za UC4 (Objava rezultata glasanja)

18
4. PRIMJER 4
Funkcionalni zahtjevi:

Sustav za rezervaciju karata ima zadau obavljanja rezervacija sjedala u

vlakovima i raspodijelu rezervacija. Sustav je napravljen na taj nain da u
sebi ima sustav podataka u kojima su upisani svi kolodvori, lokomotive i svi
vagoni, te rezervacije u njima. Izmjenu podataka vezne uz lokomotive i
kolodvore moe vriti samo globalni administrator, dok podatke vezane uz
kompozicije moe vriti i lokalni administrator. Podatke vezane uz
registracije i rezervacije mijenja sam korisnik (putnik).

Dionici sustava su:

Globalni administrator (Admin)
Lokalni administrator
Putnik

Aktori i njihove uloge su:

Globalni Administrator (Admin):
aurira listu kolodvora
aurira listu lokomitiva
aurira listu vagona
uvodi nove kompozicije
izrada izvjetaja za svaku kompoziciju koja sadri podatke o
popunjenosti, sastavu (lokomotive i vagoni) i podatke o polaznom i
dolaznom kolodvoru.

Lokalni Administrator:
aurira listu lokomotiva
izrada izvjetaja za svaku kompoziciju koja sadri podatke o
popunjenosti, sastavu (lokomotive i vagoni) i podatke o polaznom i
dolaznom kolodvoru.

19
Putnik:
registrira se u sustav
rezervira karte u kompozicijama
ima mogunost izmjene svojih rezervacija
mogunost rezervacije do pet karata

Sustav podataka:
sprema i uzima podatke o kolodvorima
sprema i uzima podatke o lokomtivama
sprema i uzima podatke o vagonima
sprema i uzima podatke o kompozicijama
sprema i uzima podatke o registriranim korisnicima i rezervacijama
karata

Use case dijagrami:

1. Izvjetaji:

Dionici: Globalni administrator (Admin)

Akteri: Globalni administrator (Admin), Sustav podataka
Cilj: Dobivanje izvjetaja
Preduvjet: Dostupnost sustava i korisnik mora biti administrator sustava
Rezultat: Izrada izvjetaja
eljeni scenarij:
1. Unoenje zahtjeva izvjetaja za odreenu kompoziciju ili slobodnih
vagona
2. Provjera postojanja kompozicije ili slobodnih vagona i lokomotiva, te
provjera vremena
3. Stvaranje izvjetaja
20
Mogui scenarij:
2. Nepostojanje kompozicije ili slobodnih vagona i lokomotiva

2. Brisanje i mijenjanje kompozicije:

Dionici: Globalni administrator (Admin), Lokalni administrator
Akteri: Globalni administrator (Admin), Lokalni administrator, Sustav
podataka
Cilj: Brisanje ili mijenjanje kompozicije
Preduvjet: Dostupnost sustava i korisnik mora biti administrator sustava
Rezultat: Izrada izvjetaja
eljeni scenarij:
1. Odabir kompozicije
2. Provjera postojanja kompozicije
3. Biranje izmeu brisanja ili mijenjanja kompozicije
4. Brisanje - Dodavanje vagona i lokomotiva iz komopozicije koju elimo
obrisati u slobodne te brisanje kompozicije
5. a) Dodavanje lokomotive, provjera vune snage
b) Oduzimanje lokomotive
c) Oduzimanje vagona
d) Dodavanje vagona, provjera vune snage

Mogui scenarij:
2. Kompozicija ne postoji
5. a) i d) vuna snaga preslaba

21
 3. Promjena rute:
Dionici: Globalni administrator (Admin)
Akteri: Globalni administrator (Admin), Sustav podataka
Cilj: Izmjena ruta
Preduvjet: Dostupnost sustava i mora biti administrator sustava
Rezultat: dodavanje ili oduzimanje kolodvora na ruti
eljeni scenarij:
1. Odabiranje i provjera postojanja kompozicije
2. Odabir i provjera postojanja kolodvora
3. Mogunost biranja izmeu brisanja i dodavanja kolodvora
4. a) Provjera broja kolodvora i provjera opasnosti od sudara te brisanje
kolodvora
b) Provjera opasnosti od sudara te dodavanje kolodvora

Mogui scenarij:
1. Ne postoji kompozicija
2. Ne postoji kolodvor
4. a) Broj kolodvora je manji od dva ili postojanje opasnosti od sudara
b) Postojanje opasnosti od sudara

4. Brisanje i dodavanje kolodvora:

Dionici: Globalni administrator (Admin)
22
Akteri: Globalni administrator (Admin), Sustav podataka
Cilj: brisanje i dodavanje kolodvora
Preduvjet: Dostupnost sustava i korisnik mora biti administrator sustava
Rezultat: dodan ili obrisan kolodvor
eljeni scenarij:
1. Zahtjev za dodavanje ili brisanje kolodvora
2. Provjera postojanja kolodvora
3. Provjera prolazi li kompozicija kroz kolodvor koji se eli brisati
4. Dodavanje ili brisanje kolodvora
Mogui scenarij:
2. Ne postoji kolodvor
3. Postoji kompozicija koja prolazi kroz kolodvor

5. Dodavanje kompozicije:
Dionici: Globalni administrator (Admin)
Akteri: Globalni administrator (Admin), Sustav podataka
Cilj: Dodavanje kompozicije
Preduvjet: Dostupnost sustava i korisnik mora biti administrator sustava
Rezultat: dodana kompozicija
eljeni scenarij:
1. Odabiranje imena kompozicije
2. Provjera postojanja istog imena
3. Odabiranje kolodvora, provjera postojanja kolodvora i provjera
povezanosti s prugom
4. Dodavanje kolodvora

23
5. Odabir lokomotive
6. Provjera slobodnih lokomotiva
7. Promjena rute i/ili mijenjanje kompozicije
8. Dodavanje kompozicije
Mogui scenarij:
2. Postoji kompozicija s odabranim imenom
3. Kolodvor ne postoji, kolodvor nema prugu
6. Nema slobodnih lokomotiva

6. Rezervacija karata:
Dionici: Putnik
Akteri: Putnik, Sustav podataka
Cilj: registracija i rezervacija karata
Preduvjet: Dostupnost sustava
Rezultat: registracija i/ili rezervacija karata
eljeni scenarij:
1. Odabiranje pregleda rasporeda vlakova, registracija na stranicu ili log in
2. Odabir rezervacije ili brisanja rezervacije
3. Ako je odabrana rezervacija karta se rezervira inae se ide na korak 4
4. Provjera da li vlak kree za dva dana ili manje
5. Brisanje rezervacije

Mogui scenarij:
4. Vlak kree za dva dana ili manje

24
 UC 1 - Izvjetaji

UC 2 Brisanje i mijenjanje kompozicije

UC 3 Promjena rute

25
UC 4 Dodavanje i brisanje kolodvora

UC 5 Dodavanje kompozicije

26
UC 6 Rezervacija karata

27
5. PRIMJER 5
Funkcionalni zahtjevi
Dionici:

Voditelj
Direktor
Djelatnik servisa

Aktori i njihovi funkcionalni zahtjevi:

Voditelj, inicijator:
o Otvara/zatvara radni nalog za popravak auta te za svaki imenuje odgovornog
servisnog radnika; aurira i pretrauje bazu podataka
Direktor, inicijator:
o Po potrebi aurira u bazi podataka podatke o postupcima, dijelovima i materijalima
te mijenja jedininu cijenu ovjek-sata za djelatnike servisa
Baza podataka, sudionik:
o Sprema radne naloge, postupke koji se izvravaju nad vozilima te podatke o
djelatnicima servisa
Brojilo vremena, sudionik:
o Pokree dnevne, mjesene i godinje obraune
Savjetnik servisa, inicijator:
o Dodaje radne naloge na postojei, te novi materijal u pojedinani postupak
(definiran u bazi podataka) ako je to potrebno

Opis obrazaca uporabe:

UC1 - ZaprimiStranku:
o Glavni sudionik: Voditelj.
o Cilj: Otvoriti novi radni nalog prilikom zaprimanja stranke.
o Sudionici: Baza podataka.
o Preduvjeti: Djelatnik servisa je logiran u sustav kao voditelj.

28
 o Rezultat: Pokrenut je postupak popravka automobila.
o eljeni scenarij:
1. Voditelj otvara novi radni nalog.
2. U radni nalog voditelj upisuje ime i prezime stranke, adresu, kontakt telefon
te za vozilo model, godite, registarsku oznaku i opis kvara ili postupaka
na vozilu koje stranka trai.
3. Voditelj dodjeljuje odgovornog servisnog savjetnika.
4. Sustav postavlja status radnog naloga na otvoren.
o Mogui drugi scenariji:
3. Dodjeljeni servisni savjetnik ima previe stranaka (definiramo broj stranaka
po servisnom savjetniku).

1. Sustav obavjetava voditelja.

2. Voditelj dodjeljuje novog servisnog savjetnika.

UC2 DodajRadniNalog:
o Glavni sudionik: Djelatnik servisa.
o Cilj: Dodati radni nalog na postojei radi dodavanja novih postupaka koji se trebaju
izvriti nad vozilom stranke.
o Sudionici: Baza podataka.
o Preduvjeti: Djelatnik servisa je logiran u sustav.
o Rezultat: Novi radni nalog je dodan na postojei.
o eljeni scenarij:
1. Djelatnik servisa upisuje u web suelje podatke o stranki za koju je
potrebno dodati radove nad vozilom.
2. Sustav trai u bazi podataka inicijalni otvoreni radni nalog.
3. Djelatnik servisa na postojei radni nalog dodaje novi s opisom novih
kvarova ili postupaka na vozilu stranke.
o Mogui drugi scenariji:
2. U bazi podataka nema otvorenog radnog naloga.

1. Sustav obavjetava korisnika da traeni podaci nisu dostupni.

2. Djelatnik servisa javlja voditelju da je potrebno otvoriti novi radni nalog
3. Voditelj servisa otvara novi radni nalog.

29
 UC3 AurirajBazuPodataka:
o Glavni sudionik: Djelatnik servisa.
o Cilj: Promjeniti podatke u bazi podataka.
o Sudionici: Baza podataka.
o Preduvjeti: Djelatnik servisa je logiran u sustav.
o Rezultat: Novi podaci o postupcima na vozilu, djelovima ili materijalima se
spremaju u bazu podataka.
o eljeni scenarij:
1. Sustav provjerava koji je djelatnik servisa logiran u sustav te sukladno tome
omoguuje djelatniku odreene akcije.
2. Sustav omoguuje svim djelatnicima servisa dodavanje materijala u
pojedinani postupak, mehaniarima itanje baze podataka o postupcima,
djelovima i materijalima, a voditeljima i direktoru omoguuje izmjenu
navedenih podataka. Direktoru sustav omoguuje mijenjanje jedinine
cijene ovjek-sat.
3. Voditelji ili direktor auriraju bazu podataka.
o Mogui drugi scenariji:
2. Mehaniar pokuava aurirati bazu podataka o postupcima i djelovima.

1. Sustav mu ne dozvoljava izmjenu.

UC4 PokreniObraun:
o Glavni sudionik: Brojilo vremena.
o Cilj: Pokrenuti dnevni, mjeseni i godinji obraun.
o Sudionici: Baza podataka.
o Preduvjeti: Istek vremena za pokretanje obrauna (kraj radnog vremena, kraj
mjeseca ili kraj godine).
o Rezultat: Aurira se baza podataka: dnevni, mjeseni i godinji promet.
o eljeni scenarij:
1. Pokree se skripta za raunanje prometa (za mjeseni promet zbraja se
dnevna bilanca svih dana u mjesecu, za godinji se zbraja mjeseni promet
svih mjeseci u godini).
2. Sustav upisuje podatke u bazu podataka na za to predvieno mjesto.

30
 UC5 ZatvoriPostupak:
o Glavni sudionik: Djelatnik servisa.
o Cilj: Oznaiti da je postupak obavljen.
o Sudionici: Baza podataka.
o Preduvjeti: Nema.
o Rezultat: Sustav javlja voditelju ako je mogue zatvoriti radni nalog.
o eljeni scenarij:
1. Sustav provjerava status svih postupaka u trenutnom radnom nalogu.
o Mogui drugi scenariji:
1a. Postoje postupci koji nisu zavreni.

1b. Svi postupci su zavreni.

1. Pokree se skripta koja rauna cijenu radnog naloga na temelju

jedinine cijene ovjek-sata, ukupnog broja potroenih radnih sati i
cijene radnog materijala. (Ti se podaci nalaze u bazi podataka)
2. Sustav javlja voditelju da je mogue zatvoriti radni nalog.

UC6 ZatvoriRadniNalog:
o Glavni sudionik: Voditelj.
o Cilj: Zatvoriti radni nalog za koji su svi postupci u njemu definirani izvreni.
o Sudionici: Baza podataka.
o Preduvjeti: Voditelj je logiran u sustav, zavreni su svi postupci navedeni u
radnom nalogu i njegovim podnalozima, stranka je platila raun.
o Rezultat: Radni nalog je zatvoren.
o eljeni scenarij:
1. Voditelj potvruje da je stranka platila popravak te postavlja status radnog
naloga u zavren.
2. Sustav zatvara radni nalog
3. Sustav aurira dnevnu bilancu.
o Mogui drugi scenariji:
1. Stranka nije platila popravak.

1. Voditelj ne zatvara nalog,

eka da stranka plati radove.

31
 2. Radni nalog je podreen nekom drugom
radnom nalogu

1. Sustav aurira podatke u

nadreenom nalogu

Slika 3.1. Obrazac uporabe za UC1 do UC6.

32
Slika 3.2. Detaljniji prikaz obrasca AurirajBazuPodataka

Slika 3.3. Detaljniji prikaz obrasca ZaprimiStranku

33
Slika 3.4.Detaljniji prikaz obrasca PokreniObraun

34