Prirucnik UML

Sveuilite u Zagrebu
Fakultet elektrotehnike i raunarstva

Zavod za elektroniku, mikroelektroniku, raunalne i inteligentne sustave
UML-dijagrami:
Zbirka primjera i rijeenih zadataka
Manualia Universitatis studiorum Zagrabiensis

Sveuilini prirunik
Autori:
Dr. sc. Alan Jovi, dipl. ing.
Mr. sc. Marko Horvat, dipl. ing.
Dr. sc. Igor Grudeni, dipl. ing.
Zagreb, listopad 2013.
Sadraj
1.
Uvod ................................................................................................................................................ 5
2.
Dijagrami obrazaca uporabe ............................................................................................................ 7

2.1. Karakteristike dijagrama .............................................................................................................. 7
2.2. Elementi dijagrama....................................................................................................................... 8
2.2.1. Aktori ..................................................................................................................................... 8
2.2.2. Obrasci uporabe .................................................................................................................... 9
2.2.3. Veze na dijagramima obrazaca uporabe ............................................................................... 9
2.2.4. Asocijacija (engl. association) ................................................................................................ 9
2.2.5. Generalizacija (engl. generalization) ................................................................................... 10
2.2.6. Ukljuivanje (engl. include).................................................................................................. 11
2.2.7. Proirenje (engl. extend) ..................................................................................................... 11
2.2.8. Rijeeni sloeni primjer ....................................................................................................... 12
2.3. Zadaci za vjebu ......................................................................................................................... 15
2.4. Napomene................................................................................................................................... 17
3.
Sekvencijski i komunikacijski dijagrami....................................................................................... 19

3.1. Karakteristike dijagrama ............................................................................................................ 19
3.2. Sekvencijski dijagrami ............................................................................................................... 19
3.2.1. Rijeeni primjeri................................................................................................................... 19
3.2.2. Napomene u vezi sekvencijskih dijagrama .......................................................................... 26
3.2.3. Zadaci za vjebu ................................................................................................................... 27
3.3. Komunikacijski dijagrami .......................................................................................................... 30
3.3.1. Rijeeni primjeri................................................................................................................... 30
3.3.2. Napomene u vezi komunikacijskih dijagrama ..................................................................... 34
3.3.3. Zadaci za vjebu ................................................................................................................... 34
4.
Dijagrami razreda .......................................................................................................................... 35

4.1. Karakteristike razreda................................................................................................................. 35
4.2. Odnosi izmeu razreda ............................................................................................................... 36
4.3. Pridruivanje .............................................................................................................................. 36
4.4. Vrhovi i nazivi veza ................................................................................................................... 37
4.5. Viestrukost pridruivanja .......................................................................................................... 39
4.6. Refleksivno pridruivanje .......................................................................................................... 40
4.7. Agregacija i kompozicija............................................................................................................ 41
4.8. Pridruivanje, agregacija ili kompozicija? ................................................................................. 42
4.9. Atributi ....................................................................................................................................... 43
4.10. Operacije .................................................................................................................................. 44
4.11. Nasljeivanje ............................................................................................................................ 44
2
4.12. Nasljeivanje ili agregacija?..................................................................................................... 45

4.13. Ovisnost .................................................................................................................................... 47
4.14. Suelje i realizacija ................................................................................................................... 48
4.15. Tipovi podataka i obrojavanja (enumeracije) ......................................................................... 50
4.16. Komentari ................................................................................................................................. 51
4.17. Zadaci za vjebu ....................................................................................................................... 52
5.
Dijagrami objekata i paketa ........................................................................................................... 54

5.1. Dijagrami objekata ..................................................................................................................... 54
5.1.1. Karakteristike objekata........................................................................................................ 54
5.1.2. Definiranje objekata ............................................................................................................ 54
5.1.3. Veze izmeu objekata ......................................................................................................... 55
5.1.4. Zadaci za vjebu ................................................................................................................... 57
5.2. Dijagrami paketa ........................................................................................................................ 58
5.2.1. Karakteristike paketa........................................................................................................... 58
5.2.2. Vidljivost i ugnijeenje paketa ........................................................................................... 58
5.2.3. Veze paketa ......................................................................................................................... 59
5.2.4. Stereotipovi paketa ............................................................................................................. 61
5.2.5. Zadaci za vjebu ................................................................................................................... 62
6.
Dijagrami stanja i aktivnosti.......................................................................................................... 63

6.2. Dijagram stanja........................................................................................................................... 63
6.2.1. Elementi dijagrama.............................................................................................................. 63
6.2.2. Zadaci za vjebu ................................................................................................................... 65
6.3. Dijagram aktivnosti .................................................................................................................... 66
6.3.1. Elementi dijagrama.............................................................................................................. 66
6.3.2. Rijeeni primjer.................................................................................................................... 67
6.3.3. Zadaci za vjebu ................................................................................................................... 69
7.
Dijagrami komponenti ................................................................................................................... 71

7.2. Svojstva komponenti .................................................................................................................. 71
7.3. Suelja komponenti .................................................................................................................... 73
7.4. Vrste komponenti ....................................................................................................................... 74
7.5. Stereotipovi komponenti ............................................................................................................ 74
7.6. Zadaci za vjebu ......................................................................................................................... 77
8.
Dijagrami razmjetaja.................................................................................................................... 78
8.2. Elementi dijagrama..................................................................................................................... 78
3
8.3. Veze vorova .............................................................................................................................. 79

8.4. Stereotipovi ................................................................................................................................ 81
8.5. Pojedinci vorova i komponenti ................................................................................................. 82
8.6. Zadaci za vjebu ......................................................................................................................... 83
9.
Rjeenja zadataka .......................................................................................................................... 83

9.1. Dijagrami obrazaca uporabe ....................................................................................................... 83
9.2. Sekvencijski i komunikacijski dijagrami.................................................................................... 89
9.3. Dijagrami razreda ....................................................................................................................... 96
9.4. Dijagrami objekata i paketa ...................................................................................................... 100
9.5. Dijagrami stanja i aktivnosti..................................................................................................... 102
9.6. Dijagrami komponenti .............................................................................................................. 105
9.7. Dijagrami razmjetaja............................................................................................................... 106
Literatura ............................................................................................................................................. 107
1. Uvod
Ujedinjeni jezik za modeliranje (engl. Unified Modelling Language, krae: UML) je normirani jezik
ope namjene koji se koristi za modeliranje raunalnih sustava temeljenih na objektno-orijentiranoj
paradigmi. Jezik je normirala Grupa za upravljanje objektima (engl. Object Management Group,
krae: OMG) s prvom normom iz 1997., a s trenutanom inaicom UML 2.4 iz 2011. godine. UML
ukljuuje skup tehnika koje ostvaruju grafiki prikaz objektno-orijentiranih raunalnih sustava.
Raunalni sustav modelira se raznovrsnim dijagramima, od kojih se svaki koristi za prikaz sustava iz
poneto drugaije perspektive.
Dijagrami unutar UML-a mogu se podijeliti s obzirom na dinaminost na statike i dinamike
dijagrame. Statiki dijagrami ne razmatraju vremensku komponentu sustava, ve daju sliku dijelova ili
cijelog sustava kakav postoji u nekom trenutku. Tenja dinamikih dijagrama je da ukljue
meudjelovanje sudionika i vremensku komponentu u opis sustava kako bi se modelirali slijedovi
dogaaja unutar sustava. Neto suvremenija podjela dijagrama je ona koja dijeli UML-dijagrame s
obzirom na to da li modeliraju strukturu sustava (engl. structure diagram) ili ponaanje sustava (engl.
behavior diagram). Ovakva podjela se okvirno podudara s podjelom na statike (strukturni) i
dinamike (ponaajni) dijagrami, s iznimkom dijagrama obrazaca uporabe koji, iako modelira
ponaanje, ne modelira vremensku komponentu sustava. Podjela UML-dijagrama prema normi UML
2.4 prikazana je na slici 1.1. U okviru ove podjele postoji vei broj pojedinanih dijagrama, od ega se
u okviru ove zbirke obrauju oni dijagrami koji su oznaeni sivo na slici 1.1.
Cilj ove zbirke je predoiti to vie normiranih UML-dijagrama kako bi se omoguila kvalitetna
komunikacija na grafikoj razini izmeu inenjera koji su ukljueni u razvoj raunalnog sustava.
Pritom je potrebno ovladati znanjem o komponentama svakog opisanog dijagrama i razumjeti za to
se taj dijagram koristi. U zbirci je dan naglasak na tri dijagramima koji se najee koriste u praksi:
Slika 1.1. Pregled UML-dijagrama, norma UML 2.4 [OMG 2011]

5
dijagramu obrazaca uporabe, dijagramu razreda i sekvencijskom dijagramu. itatelji se upoznaju s

dijagramima kroz nekoliko primjera i rijeenih zadataka za svaku vrstu dijagrama. Rjeavanjem
zadanih zadataka itatelj moe usporediti svoja rjeenja s onima koja su dana u ovoj zbirci i na taj
nain nauiti ispravan nain crtanja UML-dijagrama.
Zbirka je namijenjena poglavito studentima 3. godine preddiplomskog studija raunarstva, na
kolegiju Oblikovanje programske potpore (OPP), u sklopu Zavoda za elektroniku, mikroelektroniku,
raunalne i inteligentne sustave, Fakulteta elektrotehnike i raunarstva, Sveuilita u Zagrebu (FER).
Namjena zbirke je da se koristi kao dodatni nastavni materijal koji e olakati studentima
savladavanje gradiva iz modeliranja raunalnog sustava koritenjem jezika UML u okviru projekta iz
kolegija OPP, to pokriva priblino treinu gradiva kolegija. Takoer, vjebanjem zadataka iz ove
zbirke studenti se mogu uspjeno pripremiti za ispite iz ovog kolegija. Zbirka je takoer namijenjena i
svim ostalim zainteresiranim itateljima koji bi eljeli nauiti modelirati sustave koritenjem jezika
UML.
Primjeri i zadaci unutar ove zbirke crtani su koritenjem dvaju alata dostupnih studentima FER-a, a
to su Microsoft Visio 2007 i 2010 (putem licence MSDNAA) i ArgoUML v.0.32 (slobodan programski
proizvod [Wulp 2011]). Izbor alata za crtanje UML-dijagrama ostavljen je na volju itatelja budui da
kod samih alata postoji velika raznolikost po pitanju licenciranja, podranih dijagrama i mogunosti
crtanja njihovih komponenata.
Zbirka je ustrojena na sljedei nain. U poglavlju 2 opisuju se dijagrami obrazaca uporabe: njihovo
znaenje iz perspektive krajnjeg korisnika sustava i opis bitnih komponenti dijagrama. Poglavlje 3
posveeno je dijagramima meudjelovanja, to znai sekvencijskim i komunikacijskim dijagramima.
Opisuju se karakteristike tih dijagrama, njihove razlike i daju se razraeni primjeri da bi se to lake
razumjelo kako modelirati meudjelovanje dijelova sustava. Dijagrami razreda detaljno su razraeni
u opsenom poglavlju 4, zajedno sa svim entitetima koji se na tim dijagramima prikazuju. Poglavlje 5
opisuje dijagrame paketa i objekata, koji slue kao nadopuna dijagramima razreda. Poglavlje 6
posveeno je dijagramima stanja i dijagramima aktivnosti koji modeliraju dinamiko ponaanje
dijelova sustava. Poglavlje 7 ukljuuje dijagrame komponenti, a poglavlje 8 dijagrame razmjetaja.
Obje vrste dijagrama na slian nain modeliraju statiku sliku sustava iz perspektive povezanosti
dijelova sustava, samo to ine na razliitoj razini. U poglavlju 9 dana su rjeenja zadataka iz svih
ostalih poglavlja. Studentima se savjetuje da konzultiraju rjeenja tek kad su sami izradili svoje
rjeenje zadatka na temelju primjera i uputa danih u ovoj zbirci. Literatura je navedena na kraju
zbirke.
2. Dijagrami obrazaca uporabe

2.1. Karakteristike dijagrama
Dijagrami obrazaca uporabe (engl. use-case diagrams) koriste se da bi se prikazalo ponaanje
sustava, dijelova sustava ili konkretnog razreda na nain vidljiv korisniku sustava. Obrasci uporabe
takoer slue tome da se razvojni tim i korisnici usaglase po pitanju ponaanja korisnika pri
komunikaciji sa sustavom [Rational 2001]. Ponaanje sustava opisano je pomou ciljeva (engl. usecases obrasci uporabe) i aktora (engl. actors) koji predstavljaju apstrakciju korisnika sustava,
odnosno openitije nekog od dionika (engl. stakeholder) sustava. Aktori mogu predstavljati i druge
vanjske sustave koji sudjeluju u radu sustava koji se modelira. Jedan obrazac uporabe ukljuuje
komunikaciju aktora s modeliranim sustavom koji se ostvaruje kao niz poruka meu sudionicima
obrasca uporabe, a koji doprinosi ostvarenju nekog jedinstvenog cilja. Na dijagramima obrazaca
uporabe dodatno se definiraju odnosi izmeu pojedinih obrazaca uporabe kao i odnosi izmeu
aktora.
Dijagrami obrazaca uporabe su statiki UML-dijagrami (kao i dijagrami razreda, objekata, paketa i
razmjetaja), a takoer pripadaju i skupini ponaajnih dijagrama budui da modeliraju mogue
ponaanje korisnika sustava.
Primjer 2.1.1. Blagajna u trgovakom centru
Prikaite u dijagramu obrazaca uporabe funkcionalnost blagajne u trgovakom centru.
Slika 2.1. Rjeenje primjera 2.1.1.

U primjeru navedenom na slici 2.1 aktori u sustavu su Blagajnik i Kupac, oznaeni
pojednostavljenim prikazom ovjeka (engl. stickman). Blagajnik moe ukljuiti blagajnu, napraviti
prijavu u sustav te napraviti transakciju. Te temeljne aktivnosti ine obrasce uporabe (engl. use-case)
koji se prikazuju elipsom. Obrazac uporabe Napravi transakciju odnosi se na oitavanje svih artikala,
ispis rauna, odabir naina plaanja i plaanje robe. U tom obrascu uporabe sudjeluje i kupac.
Obrazac uporabe Napravi transakciju mogue je ralaniti na nekoliko povezanih jednostavnijih
obrazaca uporabe. Razina apstrakcije na kojoj e se sustav modelirati obrascima uporabe ovisi o
iteraciji procesa programskog inenjerstva, odnosno potrebnoj razini detalja u odreenoj fazi izrade
programske potpore.
2.2. Elementi dijagrama

Prema UML-specifikaciji dijagrami obrazaca uporabe sastoje se od aktora, obrazaca uporabe te
veza i odnosa meu aktorima i obrascima uporabe. Dodatno se na dijagramu obrazaca uporabe moe
istaknuti granica sustava koji se izgrauje.
2.2.1. Aktori
Aktori u dijagramima obrazaca uporabe predstavljaju jednu od idealiziranih uloga korisnika u
sustavu. Na dijagramima obrazaca uporabe aktori su prikazani pojednostavljenim prikazom ovjeka.
Jedan fiziki korisnik moe ostvariti vie uloga u sustavu, a jednu ulogu u sustavu moe preuzeti vie
korisnika. Aktori su sudionici pojedinih obrazaca uporabe pri emu jedan aktor moe sudjelovati u
vie obrazaca uporabe, a u jednom obrascu uporabe moe sudjelovati vie aktora. Uz to to
predstavljaju uloge korisnika u sustavu, aktori mogu predstavljati odreene funkcionalnosti eksternih
sustava s kojima sustav koji se modelira komunicira.
Aktori komuniciraju putem niza poruka s obrascima uporabe u kojima sudjeluju. Niz poruka
izmeu aktora i obrazaca uporabe ne prikazuje se na dijagramima obrazaca uporabe, ali se moe
prikazati na drugim UML-dijagramima poput sekvencijskog ili komunikacijskog dijagrama. Ponekad se
dinamika odreene komunikacije korisnika sa sustavom opisuje neformalnim nainima poput
proznog teksta.
Kod modeliranja sustava obrascima uporabe najvanije je identificirati obrasce koji su kljuni za
ispravno funkcioniranje sustava. Nakon toga treba odrediti ljudske imbenike, a dodatno i vanjske
sustave koje treba prikazati u svrhu boljeg razumijevanja funkcionalnosti modeliranog sustava. Aktori
meusobno mogu biti povezani vezom generalizacije pri emu je definicija apstraktnog aktora
dopunjena odreenijim ulogama izvedenih aktora.
Primjer 2.2.1.1. Odredi aktore ija uloga je koritenje internet trgovine.
Kod ostvarenja veine internet trgovina korisnici se dijele u dvije vee skupine: anonimni i
registrirani korisnici. Anonimnim korisnicima dozvoljene su aktivnosti poput pregledavanja kataloga
proizvoda, odabira proizvoda koje planiraju kupiti, pregled odabranih proizvoda i sline
funkcionalnosti koje ne zahtjevaju da identitet korisnika bude poznat. Registrirani korisnici mogu
izvoditi sve aktivnosti (obrasce uporabe) kao i anonimni korisnici uz dodatak izmjene osobnih
podataka, te provedbu plaanja robe. Budui da je skup obrazaca uporabe koje moe provoditi
anonimni korisnik pravi podskup skupa obrazaca uporabe koje provodi registrirani korisnik mogue je
definirati da je registrirani korisnik posebna vrsta anonimnog korisnika koji ostvaruje i dodatne uloge
u sustavu. Rjeenje primjera 2.2.1.1 prikazano je na slici 2.2.
Slika 2.2. Rjeenje primjera 2.2.1.1.
Uvoenje generalizacije meu aktorima u dijagramima obrazaca uporabe je korisno zato to se

smanjuje broj veza izmeu aktora i obrazaca uporabe te se dijagram ini itljivijim.
2.2.2. Obrasci uporabe
Obrazac uporabe predstavlja jedinstvenu funkcionalnost koju prema vanjskom svijetu prua
modelirani sustav. Obrazac uporabe sastoji se od glavnog tijeka izvoenja, a moe biti proiren
varijacijama tog tijeka kao i posebnim sluajevima koji se mogu dogoditi za vrijeme njegovog
ostvarenja. Tijek izvoenja obrasca uporabe opisan je nizom poruka koje aktori izmjenjuju s
modeliranim sustavom. Spomenuti niz poruka se ne prikazuje na dijagramu obrazaca uporabe.
Izvravanje svakog obrasca uporabe je neovisno od drugih obrazaca uporabe. Jedina ovisnost
izmeu obrazaca uporabe ostvaruje se preko dijeljenih podataka.
Obrasci uporabe su od velike vanosti u iterativnom procesu programskog inenjerstva. Kod
iterativnog pristupa u svakoj od iteracija se odabire podskup obrazaca uporabe koje je potrebno
ostvariti.
2.2.3. Veze na dijagramima obrazaca uporabe
U dijagramima obrazaca uporabe postoji nekoliko vrsta veza koje se mogu ostvariti izmeu aktora i
obrazaca uporabe. Pregled i kratki opis svih vrsta veza prikazan je u tablici 2.1.
Tablica 2.1. Grafiki prikaz i opis veza na dijagramima obrazaca uporabe.
Tip veze
asocijacija
generalizacija
ukljuivanje
proirenje
Grafiki prikaz
Opis
Asocijacijom se povezuju aktori s obrascima uporabe u kojima
sudjeluju. Meusobno povezivanje aktora ili meusobno povezivanje
obrazaca uporabe ovom vrstom veze nije dozvoljeno. Kod asocijacije
mogue je definirati njenu viestrukost (engl. multiplicity) ije
znaenje je definirano u nastavku teksta.
Generalizacijom se povezuju dva aktora ili dva obrasca uporabe. U
sluaju da se generalizacijom povezuju dva aktora, specifiniji aktor
preuzima sve uloge apstraktnijeg aktora uz dodatak novih uloga. Kod
koritenja generalizacije izmeu dva obrasca uporabe specifiniji
obrazac proiruje odnosno mijenja funkcionalnosti apstraktnijeg
obrasca uporabe.
Vezom ukljuivanja se povezuju dva obrasca uporabe na nain da
jedan obrazac u tijeku svog izvoenja u potpunosti izvede ukljueni
obrazac uporabe.
Vezom proirenja se povezuju dva obrasca uporabe pri emu jedan
proiruje funkcionalnost drugog. Proirenje se ostvaruje ako je
zadovoljen odreeni uvjet definiran u toki proirenja.
2.2.4. Asocijacija (engl. association)

Asocijacijom se povezuju aktori s obrascima uporabe u kojima sudjeluju. U sluaju da se eli
naglasiti koji aktor inicira odreeni obrazac uporabe (inicijator) to se moe napraviti dodatkom
strelice na vezu asocijacije, kako je to prikazano na slici 2.3.
Slika 2.3. Asocijacija izmeu aktora i obrasca uporabe.

Naznaeno je da klijent inicira izdavanje potvrde, a slubenik sudjeluje u izdavanju potvrde. Ako neki
aktor samo sudjeluje u obrascu uporabe, ali sam ne inicira akciju (sudionik), tada se veza izmeu
obrasca uporabe i sudionika moe oznaiti strelicom koja ide u sudionika. Tipian primjer bila bi baza
podataka ili datoteni sustav.
Kod asocijacije je mogue koristiti viestrukost pri emu se odreuje koliko puta neki aktor
sudjeluje u odreenom obrascu uporabe te koliko aktora moe izvesti odreeni obrazac uporabe. Na
slici 2.4 prikazan je primjer narudbe robe u internet trgovini.
Narudba robe
0..*
0..1
Klijent
Slika 2.4. Primjer viestrukosti.

Pri tome u sustavu internetske trgovine u nekom vremenskom trenutku klijent moe izraditi
najvie jednu narudbu robe (0..1), dok se u istom trenutku moe odvijati nula ili vie (0..*) narudbi
robe razliitih klijenata.
Viestrukost na vezi asocijacije se promatra u nekom vremenskom periodu. U navedenom
primjeru viestrukost se promatra u jednom beskonano kratkom trenutku vremena, ali vremenski
interval koji se promatra moe biti dui (primjerice tjedan dana) ili moe biti vezan uz neko svojstvo
sustava poput trajanje sjednice za vrijeme koritenja web sjedita. U svakom sluaju je korisno na
dijagramu napomenuti na koji se vremenski interval viestrukosti odnose, primjerice na nain kako je
to prikazano na slici 2.5.
Slika 2.5. Vremenski interval pri odreivanju viestrukosti.

Ovime je naznaeno da klijent moe izraditi narudbu kataloga dva puta mjeseno, a da se dnevno
provede 400 000 narudbi kataloga.
2.2.5. Generalizacija (engl. generalization)
Generalizacijom se povezuju dva aktora ili dva obrasca uporabe. U sluaju da se generalizacijom
povezuju dva aktora, specifiniji aktor preuzima sve uloge apstraktnijeg aktora uz dodatak novih
uloga. Kod koritenja generalizacije izmeu dva obrasca uporabe, specifiniji obrazac proiruje,
odnosno mijenja funkcionalnosti apstraktnijeg obrasca uporabe.
Primjer generalizacije obrazaca uporabe i tijeka njihovog izvoenja prikazan je na slici 2.6.
10
Slika 2.6. Primjer generalizacije.

Valovitom linijom oznaen je tijek izvoenja obrasca uporabe. Kod generalizacije specifiniji
obrazac uporabe dodaje nove ili mijenja dijelove postojee funkcionalnosti apstraktnijeg obrasca
uporabe.
2.2.6. Ukljuivanje (engl. include)
Vezom ukljuivanja se povezuju dva obrasca uporabe na nain da jedan obrazac u tijeku svog
izvoenja u potpunosti izvede ukljueni obrazac uporabe pri emu trenutak izvoenja ukljuenog
obrasca nije specificiran dijagramom.
Grafiki prikaz tijeka izvoenja obrazaca povezanih vezom ukljuivanja prikazan je na slici 2.7.
Slika 2.7. Primjer ukljuivanja.

U sluaju da osnovni obrazac uporabe doe u toku izvoenja u kojoj je potrebno izvesti ukljueni
obrazac uporabe tada se ukljueni obrazac uporabe izvodi u cijelosti. Mogue je da u tijeku izvoenja
nisu zadovoljeni uvjeti pozivanja ukljuenog obrasca uporabe.
2.2.7. Proirenje (engl. extend)
Vezom proirenja se povezuju dva obrasca uporabe pri emu jedan proiruje funkcionalnost
drugog. Proirenje se ostvaruje ako je zadovoljen odreeni uvjet definiran u toki proirenja.
Proirenja se obino koriste kada je potrebno naznaiti da je neka funkcionalnost opcionalna u
nekom obrascu uporabe. Dodatno se koriste kada je potrebno naznaiti da se neka posebna
funkcionalnost ostvaruje samo kada su ostvareni odreeni uvjeti, pri emu su ti uvjeti dovoljno
znaajni da bi ih se naglasilo na dijagramu obrazaca uporabe.
Primjer toka izvoenja osnovnog i proirenog obrasca uporabe prikazan je slikom 2.8.
11
<extend>
Proireni obrazac uporabe
Osnovni obrazac uporabe

Toka proirenja
Slika 2.8. Primjer proirenja.

U toki proirenja se funkcionalnost osnovnog obrasca uporabe proiruje proirenim obrascem
uporabe ako su zadovoljeni uvjeti toke proirenja. U sluaju da postoji vie toaka proirenja i
proirenih obrazaca uporabe redoslijed njihovog izvoenja ovisi o komunikaciji aktora s osnovnim
obrascem uporabe.
Primjer koritenja veze proirenja u dijagramima obrazaca dan je kroz postupak dobivanja
besplatnog kataloga uz kupnju u trgovini iji iznos premauje 500 kn. Pri tome se u toki proirenja
Besplatni dodaci vri provjera je li iznos rauna dovoljan da bi se ostvarilo pravo na besplatni katalog.
Iako veze proirenja i ukljuivanja obje ukljuuju potpuno izvoenje dodatnog obrasca uporabe, pri
emu to izvoenje moe biti uvjetno, one su semantiki razliite. Kod veze ukljuivanja osnovni
obrazac uporabe ne moe postojati bez ukljuenog obrasca uporabe, dok je kod veze proirenja
mogue ukloniti proireni obrazac uporabe. Dodatno se kod veze proirenja posebno naglaava toka
proirenja i odgovarajui uvjeti nuni za izvoenje proirenog obrasca uporabe. Primjer koritenja
veze proirenja u dijagramima obrazaca prikazan je na slici 2.9.
Prodaja artikala
________________
Besplatni dodaci
Blagajnik
Klijent
Poklanjanje
kataloga
Slika 2.9. Primjer koritenja veze proirenja u dijagramima obrazaca.

2.2.8. Rijeeni sloeni primjer
Primjer 2.2.8.1. Izraditi dijagram obrazaca uporabe za projektni zadatak vezan uz trgovinu
nekretninama.
Trgovci nekretninama najee su zatvorene, male privatne tvrtke koje posluju bez informacijske
infrastrukture i bez kvalitetnog vizualnog predstavljanja klijentima. Od klijenata se oekuje da iskau
svoje zahtjeve uivo i tada im trgovac pronae poto-poto ono to su klijenti traili, bez
transparentnosti procesa ili utjecaja klijenata. Zadatak ovog programskog proizvoda je u poveanju
transparentnosti trita nekretninama ime se olakava posao i trgovcima nekretninima i klijentima.
12
Programskom proizvodu mogu pristupiti bilo registrirani klijenti bilo registrirani trgovci
nekretninama. Registraciju provodi administrator programa na temelju osnovnih podataka korisnika
(ime i prezime, OIB, adresa, telefon, e-mail). Administrator ima ovlast promjene podataka svih
korisnika. Klijenti i trgovci imaju razliit pogled na program. Svaki klijent ima pridruenog jednog
trgovca nekretninama. Jedan trgovac nekretninama moe imati vie pridruenih klijenata.
Klijent na poetku u programu bira trgovca nekretninama iz liste aktivnih trgovaca na temelju
preporuka (od 1 do 10) koje su dali drugi klijenti i iznosa naknade koju trgovac zaraunava. Klijent
moe promijeniti osobne podatke o sebi, kao i dodati opis o tome kakva ga tono nekretnina zanima.
Klijent ima pravo pretraivati bazu dostupnih nekretnina koju su sastavili trgovci nekretninama. Svaka
nekretnina opisana je svojim podacima: nazivom, nazivom grada, nazivom kvarta, adresom, vrstom
nekretnine (stan, obiteljska kua, vila), tipom (garsonijera, 1-,2-,3-,viesobni stan; prizemnica, jedno-,
dvo- tro-, viekatnica), starosti, brojem kvadrata, prikljucima (struja, telefon, plin, voda), bazenom,
brojem parkirnih mjesta, tekstualnim komentarom i cijenom. Svaka nekretnina ima pridruenu jednu
ili vie fotografija. Bazu se moe pretraivati po redu kako su nekretnine dodavane, ili na temelju
parametara pretrage (grad, kvart, vrsta, tip, starost, broj kvadrata), pri emu se dobiva lista
odgovarajuih nekretnina.
Nakon to se odlui obii nekretninu, klijent moe poslati poruku sebi pridruenom trgovcu za
dogovor oko vremena i mjesta sastanka. Poruka se alje kroz program i klijent dobiva odgovor kroz
program o tome odgovara li termin trgovcu ili je trgovac zauzet. U svakom trenutku, klijent ima pravo
odabrati drugog pridruenog trgovca nekretninama. O svakoj promjeni statusa pridruenosti treba
biti obavijeten trgovac porukom unutar programa. Takoer, klijent mora moi pregledati sve poruke
koje je poslao trgovcima ili primio od trgovaca. Klijent moe ocijeniti sebi pridruenog trgovca
nekretninama ocjenom od 1 do 10 u svakom trenutku u programu, pri emu se revidira prosjena
preporuka trgovca.
Trgovac nekretninama ima sljedee mogunosti rada u programu: 1) Pregledati popis klijenata koji
su mu pridrueni, zajedno s njihovim osnovnim podacima i opisom zahjeva; 2) Dodati novu
nekretninu u bazu, pri emu treba unijeti sve potrebne informacije o nekretnini, ukljuujui i
fotografije. Pretpostavlja se da je podatke dobavio na terenu od prodavaa. 3) Izmijeniti postojee
podatke o nekoj nekretnini; 4) Poslati poruku klijentu, bilo kao odgovor na ve pristiglu poruku, bilo
kao preporuku klijentu koja bi bila dobra nekretnina za njega; 5) Pregledati bazu nekretnina, slino
kao i klijenti; 6) Izmijeniti iznos naknade (u postotcima od iznosa nekretnine) i 7) izmijeniti osobne
podatke na svojoj poetnoj stranici profila.
13
1. Prvi korak u rjeavanju zadatka je pronalazak aktora. Aktore je mogue iitati iz teksta zadatka. U
ovom sluaju, aktori su: klijent, trgovac, administrator i baza podataka. Osim toga, moe se
izdvojiti i zaseban aktor, korisnik, koji je generalizacija klijenta i trgovca.
2. Da bi se lake izradio dijagram obrazaca uporabe, potrebno je na temelju teksta zadatka pregledno
pobrojati aktivnosti koje pojedini aktori koriste i koja je njihova uloga (da li su inicijatori akcije ili
samo sudionici). Ovo je rezultat:
Korisnik, inicijator:
o Moe zahtijevati registraciju
o Ima pristup i mogunost promjene osobnih podataka nakon registracije
o Pretrauje i pregledava bazu nekretnina
Klijent, inicijator:
o Pregledava popis trgovaca
o Odabire novog trgovca
o Ocjenjuje trgovca
o Dodaje opis kakva ga nekretnina zanima
o Baratanje porukama prema trgovcu (primanje i slanje)
Trgovac, inicijator:
o Pregledava popis svojih klijenata
o Mijenja postojee podatke o nekretninama
o Unosi nove nekretnine u bazu
o Baratanje porukama prema klijentima (primanje i slanje)
o Mijenja iznos naknade
Administrator, inicijator:
o Provodi registraciju korisnika
o Ima pristup svim podacima i moe ih mijenjati
Baza podataka, sudionik:
o Sadri arhivu podataka o nekretninama sa svim karakteristikama
o Pohranjuje sve podatke o korisnicima sustava
o Pohranjuje poruke korisnika
3. Na kraju se crta dijagram obrazaca uporabe koji e obuhvatiti sve navedene aktivnosti korisnika.
Prema potrebi, na dijagram se ucrtavaju odnosi generalizacije, ukljuivanja i proirenja. Bazu
podataka u ovom sluaju nije potrebno crtati budui da veina obrazaca uporabe komunicira s
njom, ali je potrebno navesti da baza podataka postoji u komentaru dijagrama. Rezultat je prikazan
na slici 2.10.
14
Slika 2.10. Dijagram obrazaca uporabe za primjer 2.2.8.1.
2.3. Zadaci za vjebu

Zadatak 2.1. Modeliranje upravljanja hotelom
Potrebno je izraditi use-case dijagram dijela sustava namijenjenog upravljanju hotelom.
Administrator sustava moe konfigurirati sustav to ukljuuje upis svih raspoloivih soba, parkirnih
mjesta i cjenika. Korisnici preko interneta mogu pretraiti hotelsku ponudu i napraviti rezervaciju
15
sobe. Prilikom rezervacije sobe korisnici mogu opcionalno rezervirati parkirno mjesto, te dokupiti
doruak, polupansion ili puni pansion.
Recepcionar hotela moe izdati sobu i napraviti naplatu. Kod izdavanja sobe recepcionar obavezno
provjerava rezervaciju i programira klju (karticu) za otvaranje sobe. Prilikom naplate recepcionar
izdaje raun i naznauje da soba postaje slobodna.
Zadatak 2.2. Modeliranje prodaje autobusnih karata
Potrebno je izraditi dijagram obrazaca uporabe za prodaju karata na autobusnom kolodvoru.
Sustav koriste blagajnici i putnici. Blagajnik prodaje kartu putniku. Prodaja karte ukljuuje odabir
relacije i naplatu. Naplata se moe izvriti u gotovini ili putem kartice. U sluaju da se naplata vri
putem kartice u naplati sudjeluje putnik utipkavanjem PIN-a. Opcionalno kod prodaje karte blagajnik
moe izdati raun R1.
Uz prodaju karata blagajnik moe napraviti i rezervaciju karte. Rezervaciju karte moe napraviti i
putnik samostalno preko telefonskog automata.
Zadatak 2.3. Modeliranje koritenja grozda raunala
Grozd raunala mogu koristiti administratori i korisnici. Administratori sustava zasluni su za
dodavanje novih korisnika, promjenu podataka korisnika, brisanje postojeih korisnika i konfiguraciju
sustava. Konfiguracija sustava podrazumijeva podeavanje postavki rasporeivaa poslova i izrade
sigurnosne kopije podataka. Izrada sigurnosne kopije podataka je posebna vrsta kopiranja podataka.
Korisnici mogu dodavati nove poslove na obradu, mogu brisati postojee poslove, te mogu mijenjati
parametre postojeih poslova. Izmjena parametra postojeih poslova ukljuuje brisanje postojeeg
posla i stvaranje novog posla. Dodatno, korisnici mogu slati podatke na grozd raunala, kopirati
podatke i uitavati podatke s grozda raunala.
Zadatak 2.4. Modeliranje rada rent-a-car kompanije
Potrebno je izraditi dijagram obrazaca uporabe sustava koji slui kao podrka radu rent-a-car
kompanije, a u aritu sustava je kontrola flote rent-a-car vozila i rad s kupcima. Sustav treba pratiti
nabavke i rashodovanja vozila te pratiti njihovo koritenje kroz vrijeme. Korisnici koji iznajmljuju
automobile mogu preko interneta napraviti i otkazati rezervaciju vozila. Kod stvaranja rezervacije
korisnici moraju unijeti broj kreditne kartice. Korisnici mogu napraviti rezervaciju vozila samo u
sluaju da u sustavu za zatraen vremenski period postoje slobodna vozila. Kod stvaranja rezervacije
korisnici mogu prema elji i raspoloivim resursima napraviti i rezervaciju za GPS ureaj, djeju
sjedalicu, krovne nosae za bicikle ili skije i prikolicu.
Kada korisnici dou u poslovnicu rent-a-car kompanije u kojoj trebaju preuzeti vozilo zaposlenik
provjerava postoji li rezervacija vozila za odreenog korisnika. Ako rezervacija ne postoji zaposlenik
rent-a-car kompanije izrauje rezervaciju za korisnika.
Nakon to je rezervacija napravljena (ili je postojala od ranije) zaposlenik rent-a-car kompanije
ispisuje obrazac o preuzimanju vozila koji korisnik potpisuje. Potpisani obrazac se skenira i unosi u
raunalo. Nakon to je obrazac skeniran zaposlenik rent-a-car kompanije odvodi klijenta do
automobila i predaje mu kljueve, prometnu dozvolu i obrazac o preuzimanju vozila.
Kod povratka automobila korisnik dolazi u poslovnicu rent-a-car kompanije gdje predaje obrazac o
preuzimanju vozila, prometnu dozvolu i kljueve automobila. Zaposlenik odlazi s korisnikom do
automobila, provjerava stanje automobila i preostalu koliinu goriva. Nakon povratka u poslovnicu
zaposlenik generira raun i odobrava tereenje kreditne kartice korisnika.
16
Zadatak 2.5. Modeliranje sigurnosnog sustava banke

Neka banka ima sigurnosni sustav koji se sastoji od nadzornih kamera i dvostrukih kliznih vrata sa
senzorom na ulazu. Klijent banke moe ui u banku tako da mu se otvore prva vrata i on proe kroz
njih u meuprostor. Nakon toga, senzor na drugim vratima detektira klijenta i nakon to proe 5
sekundi, senzor pokree ulazak klijenta u banku. Time se otvaraju druga vrata i zatvaraju prva vrata.
Klijent zatim proe kroz druga vrata u banku. Klijent u banci moe obaviti svoje poslovanje i potom
izai iz banke. Prilikom izlaska, otvaraju mu se najprije druga vrata, zatim klijent opet eka 5 sekundi
u meuprostoru i potom senzor pokree izlazak klijenta. Time se otvaraju prva vrata i zatvaraju druga
vrata nakon ega klijent moe izai. Senzor ne pokree otvaranje prvih ili drugih vrata drugim
klijentima dok su neki klijenti ve u meuprostoru i dok traje zadanih 5 sekundi ekanja.
Slubenik sigurnosti banke moe kroz sigurnosni sustav u svakom trenutku zakljuati prva vrata i/ili
druga vrata. Ako slubenik kroz sustav zakljua bilo koja vrata, to se evidentira u bazi podataka
banke. Jednako tako, slubenik sigurnosti moe otkljuati bilo koja vrata, to se takoer evidentira u
bazi. Slubenik sigurnosti moe provjeriti zapise nadzornih kamera iz baze podataka banke. Tijekom
provjere zapisa, slubenik sigurnosti moe pobrisati neki zapis nadzorne kamere iz baze. U
specijalnom sluaju, kada postoji neki evidentirani incident, brisanje zapisa nadzorne kamere iz baze
povlai to da sustav o pokuaju brisanja obavjetava policiju. Nadzorne kamere imaju samo zadatak
snimanja protoka klijenata u banci i zapisivanje toga u bazu podataka banke.
Crte uz zadatak 2.5:
Banka
Druga
vrata
Prva
vrata
Meuprostor
Senzor
2.4. Napomene
esta pogreka prilikom modeliranja sustava dijagramima obrazaca uporabe odnosi se na
stvaranje obrasca uporabe kojeg svi drugi obrasci ukljuuju. Tipian primjer takve pogreke je
ukljuivanje obrasca uporabe, Prijava na sustav u sve druge obrasce uporabe, zato jer je nuno
ostvariti prijavu na sustav prije nego se izvode ostali obrasci uporabe. Takav pristup nije dobar budui
da podrazumijeva da e se obrazac uporabe Prijava na sustav izvesti u sklopu svakog pojedinanog
obrasca uporabe koji ga ukljuuje, odnosno da e se korisnik stalno morati prijavljivati na sustav u
sklopu svake aktivnosti.
Takva pogreka rezultat je krive percepcije izraajne vrijednosti dijagrama obrazaca uporabe.
Dijagrami obrazaca uporabe ne koriste se da bi se ostvario sustav preduvjeta izvoenja odreenih
obrazaca uporabe (uz iznimku toaka proirenja). Napomene o preduvjetima ostvarenja pojedinog
obrasca uporabe treba navesti u detaljnom opisu tog obrasca u formalnoj ili neformalnoj formi koja
nije dio dijagrama obrazaca uporabe.
esto se pri modeliranju grijei i sa pretjeranom generalizacijom obrazaca uporabe. Kod takvog
pristupa moe se dogoditi da se napravi jedan generalni obrazac uporabe tipa Transakcija i onda
17
puno specifinih obrazaca koji bi trebali predstavljati posebne vrste te transakcije. Prije koritenja
generalizacije potrebno je identificirati koja ponaanja openitog obrasca uporabe je nuno
promijeniti ili dodati u specifinim obrascima uporabe.
Neki detalji ostvarenja sustava koji se modelira su suvini na dijagramu obrazaca uporabe. Iako
aktori mogu biti vanjski sustavi ili ak dijelovi sustava koji se modelira, njihovo koritenje treba biti
ogranieno. Primjerice, ako sustav koji se modelira sadri bazu podataka i svi ili veina obrazaca
koritenja komunicira s tom bazom podataka, tada se baza podataka moe ukloniti s dijagrama
obrazaca, jer u suprotnom ona djeluje kao centar i kao najvanija stavka na dijagramu obrazaca
koritenja.
18
3. Sekvencijski i komunikacijski dijagrami

Sekvencijski dijagrami (engl. sequence diagram) i komunikacijski dijagrami (engl. communication
diagram) pripadaju iroj skupini UML-dijagrama meudjelovanja (engl. interaction diagram). Obje
vrste dijagrama spadaju u nadskupinu ponaajnih dijagrama (engl. behavioral diagram), zajedno s
dijagramima stanja, aktivnosti i obrazaca uporabe. Stari naziv za komunikacijski dijagram je
kolaboracijski dijagram.
Za razliku od dijagrama obrazaca uporabe, kod kojih vremenska komponenta nije vana,
sekvencijski i komunikacijski dijagrami daju naglasak na vremenskom redoslijedu kojim se odvija
meudjelovanje sudionika u sustavu, tako da ih se svrstava i u dinamike UML-dijagrame.
Sudionici koji se modeliraju na sekvencijskim i komunikacijskim dijagramima mogu biti aktori
(predoavanjem komunikacije aktora s dijagrama obrazaca uporabe) ili objekti, pri emu se prikazuje
komunikacija instanci razreda prikazanih na dijagramu razreda. Dok se prilikom komunikacije aktora
govori o porukama, kod objekata to su pozivi postupaka u objektima drugih razreda.
Razlika izmeu sekvencijskog i komunikacijskog dijagrama s informacijskog stajalita nema. Bilo
koji od ova dva dijagrama moe se koristiti za prikaz meudjelovanja sudionika i jednog je mogue
jednoznano pretvoriti u drugi [Quatrani 2002]. Ipak, manje razlike izmeu te dvije vrste dijagrama
postoje u samom prikazu i one su saete u tablici 3.1.
Tablica 3.1. Razlike izmeu sekvencijskog i komunikacijskog dijagrama.
Sekvencijski
Vei naglasak na vremenskoj
ureenosti scenarija
Redoslijed poruka sudionika
odozgora lijevo prema dolje desno
Koristi se u ranim fazama
specifikacije i analize projekta
Raireniji i itljiviji
Tee izmjene
Komunikacijski
Vei naglasak na pregledu scenarija,
odnosno na meusobnoj komunikaciji
Redoslijed poruka sudionika odreen
je brojanim oznakama koje se stavljaju na poruke
Koriste se u fazi dizajniranja
implementacije odnosa
Saetiji i tei za itati
Lake izmjene
3.2. Sekvencijski dijagrami

3.2.1. Rijeeni primjeri
Primjer 3.2.1.1. Otvaranje rauna u banci
Potrebno je modelirati otvaranje rauna klijenta u banci sekvencijskim dijagramom. Klijent najprije
zatrai otvaranje novog rauna. Osobnom bankaru je za akciju otvaranja rauna potreban
identifikacijski dokument klijenta. Takoer, za tu akciju treba naplatiti iznos od 50 kuna. Osobni
bankar zato najprije zatrai od klijenta identifikacijski dokument i 50 kuna. U sluaju da klijent nema
dokument ili 50 kuna, meudjelovanje se obustavlja i klijent odlazi. Inae, klijent predaje dokument i
novac, a osobni bankar otvara raun u bazi podataka. im je raun otvoren, osobni bankar to
potvruje klijentu i time je meudjelovanje zavreno. Pretpostavite da e otvaranje rauna proi bez
greaka.
19
Postupak rjeavanja
1. Pronaite sudionike u meudjelovanju:
Modelirati otvaranje rauna klijenta u banci sekvencijskim dijagramom. Klijent najprije zatrai
otvaranje novog rauna. Osobnom bankaru je za akciju otvaranja rauna potreban identifikacijski
dokument klijenta. Takoer za tu akciju treba naplatiti iznos od 50 kuna. Osobni bankar zato najprije
zatrai od klijenta identifikacijski dokument i 50 kuna. U sluaju da klijent nema dokument ili 50 kuna,
meudjelovanje se obustavlja i klijent odlazi. Inae, klijent predaje dokument i novac, osobni bankar
otvara raun u bazi podataka i potvruje klijentu da je raun otvoren. Pretpostavite da e otvaranje
rauna proi bez greaka i da klijent nema ve otvoren raun u banci.
U ovom sluaju, aktori su: klijent, osobni bankar i baza podataka. Pritom su osobni bankar i klijent
aktivni aktori, a baza podataka pasivan aktor (vidjeti dijagrame obrazaca uporabe).
2. Nacrtajte sudionike u redoslijedu od lijeva prema desno kako se pojavljuju u tekstu zadatka. Za
crtanje sudionika koristite pravokutnik s nazivom sudionika unutar njega. Ako postoji nejasnoa po
pitanju pripadnosti razredu, moe se navesti i naziv razreda objekta, odvojen od objekta znakom ":".
U posebnom sluaju, ako su sudionici aktori, mogu se crtati i u obliku ovjeuljka (engl. stickman) s
nazivom ispod ili iznad. Primjer sudionika prikazan je na slici 3.1.
Naziv sudionika
ili
Naziv sudionika : Razred
ili
Slika 3.1. Primjeri sudionika.

Naziv sudionika obino je u raunalnim alatima potcrtan ili je ispred njega stavljen znak "/" ili ":".
Pretpostavlja se da je naziv sudionika jednak nazivu razreda iji objekt je taj sudionik. Linija koja se
protee okomito ispod sudionika naziva se ivotna linija (engl. lifeline) sudionika i moe biti puna ili
iscrtkana. ivotna linija oznaava boravak sudionika u meudjelovanju unutar sustava koji se
modelira. Sudionici sa ivotnim linijama iz primjera 3.2.1.1 prikazani su na slici 3.2.
Slika 3.2. Sudionici sa ivotnim linijama iz primjera 3.2.1.1.

3. Analizirajte reenice po redu, uvijek traei prvu sljedeu poruku koja se pojavljuje izmeu neka
dva sudionika.
Klijent najprije zatrai otvaranje novog rauna.
20
Ovdje se pojavljuje poruka izmeu klijenta i osobnog bankara (iako nije eksplicitno naveden, ali se
podrazumijeva), kojim klijent trai otvaranje novog rauna. Sa ivotne linije klijenta alje se poruka
prema osobnom bankaru koja sadri samo naziv i praznu listu argumenata:
zatrazi_otvaranje_racuna().
Poruka (ili poziv) izmeu klijenta i bankara je sinkrona (engl. synchronous message ili engl.
synchronous call). To znai da e klijent ekati na odgovor osobnog bankara i da za to vrijeme nee
nita drugo raditi unutar sustava. Iako takvo ponaanje klijenta nije eksplicitno navedeno u tekstu
zadatka, sinkrona poruka se pretpostavlja. Gdje god nije jasno navedeno koji tip poruke se oekuje,
pretpostavlja se sinkrona poruka. Sinkrona poruka oznaava se s punom strelicom na vrhu u svim
verzijama UML-a. Traenje otvaranja rauna prikazano je na slici 3.3.
Slika 3.3. Traenje otvaranja rauna.

Osobnom bankaru je za akciju otvaranja rauna potreban identifikacijski dokument klijenta.
Takoer za tu akciju treba naplatiti iznos od 50 kuna. Osobni bankar zato najprije zatrai od klijenta
identifikacijski dokument i 50 kuna.
Osobni bankar treba na zahtjev klijenta odgovoriti s upitom za identifikacijskim dokumentom i
uplatom u iznosu 50 kuna.
Klijent
Osobni bankar
Baza podataka
zatrazi_otvaranje_racuna()
zatrazi_id_dokument_i_50kn()
Slika 3.4. Povratna poruka osobnog bankara.

Zato se alje povratna poruka (engl. return message ili return call). Povratna poruka sadri naziv i
moe, ali i ne mora imati navedenu listu argumenata. Povratna poruka je takoer poruka i moe
pokrenuti reakciju kod aktora koji ju je primio ovisno o svojem sadraju. Povratna poruka crta se
iscrtkanom linijom s obinom strelicom na vrhu. Primijetite da sad ivotne linije klijenta i osobnog
bankara sadre i okomiti pravokutnik koji se naziva aktivacija (engl. activation), a koristi se za bolji
vizualni prikaz komunikacije izmeu procedura dvaju sudionika. Aktivacije se mogu, ali i ne moraju
crtati na sekvencijskim dijagramima. Posebno su korisne ako se eli prikazati komunikacija izmeu
vie razina procedura (poziv procedura unutar procedura) kao i za prikaz rekurzije. Povratna poruka
osobnog bankara prikazan je na slici 3.4.
21
U sluaju da klijent nema dokument ili 50 kuna, meudjelovanje se obustavlja i klijent odlazi.
Inae, klijent predaje dokument i novac, a osobni bankar otvara raun u bazi podataka. im je raun
otvoren osobni bankar to potvruje klijentu i time je meudjelovanje zavreno.
Ovdje je navedeno da postoje uvjeti na izvoenje daljnje komunikacije sudionika. Uvjeti su da
klijent ima identifikacijski dokument i da ima 50 kuna. U tom sluaju osobni bankar mu smije otvoriti
raun u bazi podataka banke i potvruje mu da je operacija uspjeno provedena.
Slika 3.5. Konano rjeenje primjera 3.2.1.1.

Dva uvjeta navode se unutar uglatih zagrada prije naziva poruke i povezana su s && to
oznaava logiki i. Primijetite da su argumenti poruke identifikacijski dokument i 50 kuna. Konano
rjeenje primjera 3.2.1.1 prikazano je na slici 3.5.
Primjer 3.2.1.2. Sustav za preanje piljevine
Modelirajte rad sustava za preanje piljevine sekvencijskim dijagramom. Zadaa plavog robota je
prenoenje kutije od skladita do crvenog robota. Crveni robot ih najprije raspakira i potom sadraj
(piljevinu) prazni u kontejner koji slui za skupljanje piljevine. Kad je kontejner preko 80% pun, na
njemu se pali signalna lampica koja signalizira nadzorniku da pokrene preu kojom e dobiti
niskokvalitetnu ivericu. Nadzornik najprije privremeno zaustavlja rad plavog i crvenog robota dok
kontejner ne bude spreman za novo punjenje. Pretpostavite da dok se zaustavlja plavi robot da se
moe pokrenuti zaustavljanje crvenog. Nakon to se oba zaustave, nadzornik pokree preu. Nakon
to prea zavri s poslom, nadzornik pokree logiku u kontejneru kojom se aktivira interni postupak
pranjenja i ienja kontejnera. Kad se taj postupak zavri, nadzornik pokree crveni i plavi robot.
Pretpostavite da je za punjenje kontejnera do 80% svaki put potreban neodreen broj kutija iz
skladita kao i da uvijek ima kutija na skladitu. Pretpostavka je takoer da crveni robot bre
22
raspakira i isprazni piljevinu nego to plavom robotu treba da mu donese novu kutiju tako da je
crveni robot uvijek spreman. Nije potrebno modelirati mogue kvarove u sustavu.
Postupak rjeavanja
Modelirajte rad sustava za preanje piljevine sekvencijskim dijagramom. Zadaa plavog robota je
prenoenje kutije od skladita do crvenog robota. Crveni robot ih najprije raspakira i potom sadraj
(piljevinu) prazni u kontejner koji slui za skupljanje piljevine. Kad je kontejner preko 80% pun, na
njemu se pali signalna lampica koja signalizira nadzorniku da pokrene preu kojom e dobiti
niskokvalitetnu ivericu. Nadzornik najprije privremeno zaustavlja rad plavog i crvenog robota dok
kontejner ne bude spreman za novo punjenje. Pretpostavite da dok se zaustavlja plavi robot da se
moe pokrenuti zaustavljanje crvenog. Nakon to se oba zaustave, nadzornik pokree preu. Nakon
to prea zavri s poslom, nadzornik pokree logiku u kontejneru kojom se aktivira interni postupak
pranjenja i ienja kontejnera. Kad se taj postupak zavri, nadzornik pokree crveni i plavi robot.
Pretpostavite da je za punjenje kontejnera do 80% svaki put potreban neodreen broj kutija iz
skladita kao i to da uvijek ima kutija na skladitu. Pretpostavka je takoer da crveni robot bre
raspakira i isprazni piljevinu nego to plavom robotu treba da mu donese novu kutiju tako da je
crveni robot uvijek spreman. Nije potrebno modelirati mogue kvarove u sustavu.
Zato skladite nije zasebni sudionik? Moglo bi biti, meutim jedino gdje se u tekstu pojavljuje to
je na mjestu gdje plavi robot iz njega vadi kutije i nosi crvenom robotu. Time e prenaanje kutije iz
skladita biti modelirano kao poruka.
Zato signalna lampica nije zasebni sudionik? Zato to se signalna lampica nalazi na kontejneru i
slui samo za signalizaciju. Zato e se modelirati kao poruka.
2. Nacrtajte sudionike u redoslijedu s lijeva na desno kako se pojavljuju u tekstu zadatka. Sudionici iz
primjera 3.2.1.2 prikazani su na slici 3.6.
Slika 3.6. Sudionici iz primjera 3.2.1.2.

3. Analizirajte reenice po redu, uvijek traei prvu sljedeu poruku koja se pojavljuje izmeu neka
dva sudionika.
Zadaa plavog robota je da prenosi kutije od skladita do crvenog robota.
Oito, kutije se prenose u petlji bez nekog ogranienja, jedna ili vie odjednom. Prenosi ih plavi
robot iz skladita do crvenog robota, kako je to prikazano na slici 3.7. Ne spominje se da plavi robot
radi ita drugo za to vrijeme, tako da je poruka sinkrona.
23
Slika 3.7. Plavi robot prenosi kutije iz skladita crvenom robotu primjer petlje.
Petlja se oznaava znakom *. Uvjet na petlju navodi se unutar uglatih zagrada, kao to je ve
prikazano u primjeru 3.2.1.1. za sluaj poruke koja se nije izvodila u petlji. Povratna poruka u ovom je
sluaju implicitna, budui da crveni robot automatski dojavi plavom da je sve u redu im primi kutije.
Tada se plavi robot vraa u skladite po nove.
Crveni robot ih najprije raspakira i potom sadraj (piljevinu) prazni u kontejner koji slui za
skupljanje piljevine.
Raspakiravanje sadraja je interni postupak (ili interna procedura) koji izvodi crveni robot prije
operacije pranjenja sadraja u kontejner. Svaki interni postupak oznaava se tako da se poruka alje
samom sebi pri emu se samo navede poziv poruke. Pritom se mogu koristiti dodatne aktivacije za
proceduru, ali i ne moraju. Poziv internog postupka za raspakiravanje sadraja kutija prikazan je na
slici 3.8.
Slika 3.8. Poziv internog postupka za raspakiravanje sadraja kutija.

Poruka isprazni_sadrzaj() je sinkrona zato to na kraju primjera pie da crveni robot uvijek
spremno eka (tj. nita drugo ne radi) dok ponovno ne doe plavi robot. Povratna poruka je takoer
implicitna.
Kad je kontejner preko 80% pun, na njemu se pali signalna lampica koja signalizira nadzorniku da
pokrene preu kojom e dobiti niskokvalitetnu ivericu.
Postavlja se uvjet na sadraj kontejnera. Kad je preko 80% pun, signalizirat e nadzorniku da je sve
spremno za preanje. Na slici 3.9 prikazan je uvjet na popunjenje kontejnera i signalna poruka
nadzorniku.
24
Slika 3.9. Uvjet na popunjenje kontejnera i signalna poruka nadzorniku.

Nadzornik najprije privremeno zaustavlja rad plavog i crvenog robota dok kontejner ne bude
spreman za novo punjenje. Pretpostavite da dok se zaustavlja plavi robot da se moe pokrenuti
zaustavljanje crvenog. Nakon to se oba zaustave, nadzornik pokree preu.
Nadzornik izvodi privremeno zaustavljanje radne snage. To se zbog uvjeta zadatka ostvaruje
asinkronim porukama (engl. asynchronous message ili asynchronous call). Kad je vidio da su oba
robota zaustavljena pokree preu koja treba spreati piljevinu.
Slika 3.10. Primjer asinkronih poruka koje se koriste za zaustavljanje rada robota.
Asinkrone poruke oznaavaju se sa strelicom samo na jednoj strani poruke. Drugi naini prikaza su
s obinom strelicom (pri emu nije jasno radi li se o bilo kojoj poruci ili ba o asinkronoj) ili
alternativno, sa strelicom u obliku trokuta, samo praznom iznutra (ista strelica kao i generalizacija
kod dijagrama razreda). Primjer asinkronih poruka koja se koriste za zaustavljanje rada robota
prikazan je na slici 3.10.
Nakon to prea zavri s poslom, nadzornik pokree logiku u kontejneru kojom se aktivira interni
postupak pranjenja i ienja kontejnera. Kad se taj postupak zavri, nadzornik pokree crveni i plavi
robot.
Nadzornik pokree interni postupak ienja kontejnera tek nakon to prea zavri s radom. Kad se
taj postupak zavri, nadzornik pokree robote (budui da nije navedeno nita drugo, pretpostavlja se
sinkrono pokretanje). Konano rjeenje primjera 3.2.1.2 prikazano je na slici 3.11.
25

3.2.2. Napomene
apomene u vezi sekvencijskih dijagrama
1. Tijekom ivota nekog sudionika mogue je stvoriti ili unititi nekog drugog sudionika u sustavu ako
se tako trai u zadatku. Stvaranje se ostvaruje jednostavnom porukom usmjerenom prema novom
sudioniku (pravokutniku ili ovjeuljku). To znai da se taj sudionik ne crta odmah na poetku, ve ga
se dodaje u dijagram kasnije. Unitavanje se provodi takoer porukom pri emu se na kraju ivotne
Slika 3.12. Primjer stvaranja i brisanja sudionika u sustavu.

26
linije unitavanog sudionika nacrta znak X ime je oznaeno da se linija prekida i da sudionik
prestaje biti modeliran u sustavu. Primjer stvaranja i brisanja sudionika u sustavu prikazan je na slici
3.12.
2. Opi oblik poruke (sinkrone ili asinkrone) u sekvencijskom dijagramu prikazan je na slici 3.13.
Slika 3.13. Opi oblik poruke u sekvencijskom dijagramu.

Pritom je jedino naziv poruke obavezan, dok su svi ostali elementi poruke opcionalni. Parametri
poruke odvajaju se zarezom, a mogu sadravati ili samo naziv varijable, ili oblik varijabla : tip, kao
npr. naziv_korisnika : String.
3. Uvjetno grananje (if - else if - else) mogue je prikazati kao na slici 3.14.
Slika 3.14. Uvjetno grananje podrano u sekvencijskom dijagramu.

Neki alati za crtanje sekvencijskih dijagrama ne podravaju ovakav nain prikaza grananja. U tom
sluaju poruke se crtaju jedna ispod druge bez zajednike izvorine toke.
4. Mogui su i drugaiji naini prikaza uvjetnih grananja i petlji. Zainteresiranog itatelja upuujemo
da pogleda web stranicu [Bell 2004] na kojoj je detaljno objanjeno kako je mogue na drugaiji nain
prikazati ove sloenije elemente u sekvencijskim dijagramima.
3.2.3. Zadaci za vjebu

Zadatak 3.1. Implementacija sustava internetske knjiare
Modelirajte sustav internetske knjiare sekvencijskim dijagramom. Kod implementacije sustava
internetske knjiare postoje razredi cKorisnik, cAutorizacija, cKatalog, cKosarica, cSkladiste, cBanka.
Prilikom kupovine, objekt razreda cKorisnik poziva postupak autoriziraj(k_ime,zaporka) razreda
cAutorizacija i pri tome alje svoje korisniko ime i zaporku. Ako je autorizacija dobro prola, korisnik
moe pretraivati katalog postupkom pretrazi(parametri_pretrage) razreda cKatalog kojem alje
parametre pretrage, a kao rezultat dobiva listu knjiga koje je mogue kupiti. Da bi kupio knjigu
27
korisnik je prvo mora dodati u koaricu pozivom postupka dodaj(id_knjige) razreda cKosarica kojem
alje identifikator knjige koju eli kupiti. Razred cKosarica unutar postupka dodaj() postupkom
provjeri_stanje(id_knjige) razreda cSkladiste, kojoj se alje identifikator knjige, provjerava
raspoloivost knjige na skladitu. Ako je knjiga raspoloiva, dodaje se u koaricu. Ciklus pretraivanja
kataloga moe se ponoviti vie puta, koliko god korisnik eli.
Kupnja se zavrava korisnikim pozivom postupka kupi(br_kartice) razreda cKosarica iji parametar
je broj kreditne kartice korisnika. Nakon poziva tog postupka, razred cKosarica za svaku knjigu zove
postupak azuriraj(id_knjige) razreda cSkladiste kojem alje identifikator knjige, te na kraju poziva
postupak naplati(br_kartice,iznos) razreda cBanka, kojem alje broj kreditne kartice i ukupni iznos
koji je potrebno naplatiti.
Zadatak 3.2. Komunikacija klijent-posluitelj
Modelirajte sekvencijskim dijagramom jednostavnu komunikaciju izmeu klijenta i posluitelja.
Posluitelj najprije pokree interni postupak pokreni(), kojim inicijalizira svoje resurse. Posluitelj
zatim eka na dolazak zahtjeva od klijenta. Klijent najprije alje posluitelju zahtjev za odobravanjem
sjednice zahtjev_za_sjednicom(). Pretpostavite da je zahtjev sinkron.
Ako posluitelj ima dostupnih resursa, vraa odgovor klijentu da je sjednica odobrena i vraa mu
identifikacijski broj sjednice (id), inae vraa odgovor da sjednica nije dostupna. U sluaju da je
sjednica odobrena, klijent alje vie datoteka na obradu. Slanje datoteka treba se odvijati u petlji
dokle god ima datoteka. Svaka datoteka sastoji se od naziva (String), sadrzaja (Object) i imena_
korisnika (String).
U sluaju da je bilo koji sastavni dio poruke jednak null, tada posluitelj alje asinkronu poruku o
greci. Posluitelj prima ostale datoteke i dalje bez obzira da li je bilo slanja poruke o greci. Nakon
to je primio sve datoteke, posluitelj asinkrono javlja klijentu da je u tijeku obrada datoteka te
pokree interni postupak obrade pristiglih datoteka. Interni postupak odvija se onoliko puta koliko
ima primljenih datoteka bez greaka.
Na kraju, posluitelj alje asinkronu poruku da su sve datoteke obraene. Klijent tada prekida svoju
sjednicu slanjem sinkrone poruke prekini_sjednicu(id) na to mu posluitelj odgovara s porukom o
potvrdi prekida sjednice.
Zadatak 3.3. Slanje lanka na recenziju
Modelirati sekvencijskim dijagramom postupak slanja lanka na recenziju u znanstveni asopis.
Prvi autor odluio je poslati lanak u znanstveni asopis. Najprije autor poalje lanak urednitvu i
eka potvrdu od urednitva o ispravnosti. Urednitvo obavi internu kontrolu pri emu se provjerava
da li je oblik i tema lanka u skladu s pravilima asopisa. Ako je lanak ispravan, alje se povratni
odgovor da je lanak ispravan i da se kree s recenzijom. Ako lanak nije ispravan, daljnji proces
recenzije se obustavlja i lanak se odbija. Zatim, urednitvo alje jednu kopiju lanka prvom
recenzentu. Ne ekajui na potvrdu, druga kopija lanka alje se drugom recenzentu. Ne ekajui na
potvrdu, trea kopija rada alje se treem recenzentu.
Recenzenti odgovore u roku od 14 dana mogu li recenzirati lanak. Ako manje od dvoje
recenzenata moe recenzirati, tada urednitvo alje primjerke lanka novim recenzentima (i dalje
oznaenima kao prvi, drugi i trei recenzent), to se ponavlja sve dok se ne nau najmanje dvoje onih
koji su voljni recenzirati. Recenzenti koji su odgovorili potvrdno provode recenziju, to se smatra
internim postupkom koji radi recenzent. Za recenziju imaju 30 dana. Nakon to zavri s recenzijom,
recenzent alje svoju recenziju urednitvu.
28
Recenzija treba sadravati opisnik s: 1) poljem int [], u kojem piu ocjene za svaku komponentu
lanka, 2) String s opisom rada i miljenjem. Urednitvo zaprimi sve recenzije. Zatim iterativno
provjerava recenzije, tako da za svaku recenziju i za svaku komponentu recenzije provjeri da li je u
nekom sluaju jednaka 1, to znai da lanak ne zadovoljava. Ako postoji neka komponenta lanka
koja ne zadovoljava, urednitvo alje poruku prvom autoru da se lanak odbija. Ako nema
komponente koja ne zadovoljava, tada urednitvo alje poruku prvom autoru da se lanak prihvaa.
Zadatak 3.4. Postupak deblokade tvrtke
Modelirajte sekvencijskim dijagramom postupak deblokade i plaanja dugova tvrtke. Tvrtka je
zbog dugovanja prema banci u blokadi, to znai da ne moe slobodno raspolagati imovinom i da ne
moe isplaivati novac sa svog bankovnog rauna (ali ga smije primati). Tvrtka duguje novac i drugim
tvrtkama, a ne samo banci. Da bi se tvrtku deblokiralo, ona najprije mora vratiti sva dugovanja banci.
Pretpostavite da u deblokadi izravno sudjeluju troje subjekata: ef tvrtke, raunovodstvo tvrtke i
banka kod koje tvrtka ima podignut kredit i otvoren raun. Neka tvrtka povremeno prima novac od
klijenata potreban za isplatu svog duga. Najprije raunovodstvo tvrtke javi efu da je stigao novac u
iznosu od N kuna (float) i da tvrtka ukupno raspolae s K kuna (float). Ako je ukupna koliina novca
kojom tvrtka raspolae vea od iznosa potrebnog za isplatu svih dugova (iznos koji ef zna) tada ef
odlui isplatiti sve dugove. Inae, ako novca jo nema dovoljno, ef eka dok se ne sakupi dovoljno
novca.
Kad je odluio isplatiti sve dugove, ef najprije nazove banku i najavi isplatu duga banci. Zatim ef
alje nalog raunovodstvu da isplati dugove. Raunovodstvo isplati banci dug. Banka po isplati
deblokira raun tvrtke (interni postupak banke). Po zavretku deblokade, ef odluuje ostatkom
novca isplatiti ostale dugove. Za svaku tvrtku kojoj jo duguje novac, ef alje nalog raunovodstvu da
joj se isplati dug. Raunovodstvo putem deblokiranog bankovnog rauna isplauje dugovanja
dotinim tvrtkama (te transakcije se provode preko banke).
Pretpostavite da se sve transakcije provode putem jednog rauna tvrtke. Na kraju raunovodstvo
obavjetava efa da je sve plaeno.
Zadatak 3.5. Sigurnosni sustav banke
Modelirajte kretanje klijenta u banci pomou sekvencijskog dijagrama. Klijent najprije prolazi kroz
prva vrata u meuprostor prilikom ega aktivira senzor. Nakon to proe 5 sekundi kako je klijent u
meuprostoru, senzor alje istovremeno dvije poruke sigurnosnom sustavu. Prvu da se zatvore prva
vrata i drugu da se otvore druga vrata. U sluaju da klijent ostane u meuprostoru (predomislio se i
eli izai), senzor opet eka 5 sekundi i alje istovremeno dvije poruke sigurnosnom sustavu. Prvu, da
se zatvore druga vrata i drugu, da se otvore prva vrata. Ciklus provjere senzora da li je klijent u
meuprostoru i slanja dviju poruka se ponavlja sve dok klijent ne izae iz banke ili proe kroz druga
vrata u banku. Ako klijent izae iz banke, zavrava se sekvencijski dijagram, a ako ue u banku, tada
klijent komunicira s nekim od bankovnih slubenika.
Klijent moe prema potrebi komunicirati s bankovnim slubenikom na pultu ili s osobnim
bankarom. Nakon to je zavrio komunikaciju, klijent izlazi iz banke prolazei najprije kroz druga vrata
u meuprostor. Nakon to proe 5 sekundi, senzor alje istovremeno dvije poruke sigurnosnom
sustavu. Prvu, da se zatvore druga vrata i drugu, da se otvore prva vrata. Nakon toga klijent moe
izai iz banke ili se vratiti nazad u banku ponovnim ekanjem u meuprostoru. Napomena: uz ovaj
zadatak ide isti crte kao i uz zadatak 2.5.
29
3.3. Komunikacijski dijagrami

3.3.1. Rijeeni primjeri
Primjer 3.3.1.1. Kupovina zrakoplovnih karata putem Interneta
Modelirajte meudjelovanje klijenta i sustava pri kupovini zrakoplovnih karata putem Interneta
komunikacijskim dijagramom. Klijent moe rezervirati zrakoplovnu kartu na internetskom portalu
zrakoplovnog prijevoznika. Pritom klijent najprije poziva podsustav za odabir parametara leta. Klijent
odreuje odredite, datum polaska i broj karata. Podsustav mu dojavljuje ima li dostupnih karata.
Ako ima, klijent se prosljeuje podsustavu za detaljan odabir leta. Klijent odreuje vrstu karte
(ekonomska ili poslovna) i eljeni zrakoplov na dan polaska. Pretpostavite da klijent rezervira kartu
samo u jednom smjeru tako da ne odreuje povratni termin. Nakon odabira tih parametara, zahtjev
klijenta se prosljeuje podsustavu za naplatu. Klijent treba podsustavu za naplatu definirati ime i
prezime, broj putovnice, e-mail i nain plaanja. Ako definira da je naplata putem bankovnog rauna,
klijent treba upisati broj bankovne kartice. Podsustav za naplatu treba na kraju zatraiti od klijenta
potvrdu kupovine karte. Ako klijent potvrdi naplatu i ako je upisao broj bankovne kartice, podsustav
za naplatu treba u internom postupku skinuti novac s bankovnog rauna klijenta. Na kraju podsustav
za naplatu alje e-mail klijentu sa zrakoplovnom kartom.
Postupak rjeavanja
Modelirajte meudjelovanje pri kupovini zrakoplovnih karata putem Interneta komunikacijskim
dijagramom. Klijent moe rezervirati zrakoplovnu kartu na internetskom portalu zrakoplovnog
prijevoznika. Pritom klijent najprije poziva podsustav za odabir parametara leta. Klijent odreuje
odredite, datum polaska i broj karata. Podsustav mu dojavljuje ima li dostupnih karata. Ako ima,
klijent se prosljeuje podsustavu za detalje leta. Klijent odreuje vrstu karte (ekonomska ili poslovna)
i eljeni zrakoplov na dan polaska. Pretpostavite da klijent rezervira kartu samo u jednom smjeru tako
da ne odreuje povratni termin. Nakon odabira tih parametara, zahtjev klijenta se prosljeuje
podsustavu za naplatu. Klijent treba podsustavu za naplatu definirati ime i prezime, broj putovnice, email i broj bankovnog rauna. Podsustav za naplatu treba zatraiti od klijenta potvrdu kupovine karte.
Ako klijent potvrdi naplatu i ako je upisao broj bankovne kartice, podsustav za naplatu treba u
internom postupku skinuti novac s bankovnog rauna klijenta. Ako je sve uspjeno provedeno, na
kraju podsustav za naplatu alje e-mail klijentu sa zrakoplovnom kartom.
2. Za razliku od sekvencijskih dijagrama, kod komunikacijskih dijagrama nije jednostavno unaprijed
posloiti sudionike da bi prikaz bio pregledan. Zato se treba pristupiti postepenom crtanju, poevi od
komunikacije prva dva sudionika u opisu zadatka i postepeno dodavati sljedee kako bi se ouvala
preglednost dijagrama.
Ako su sudionici aktori s dijagrama obrazaca uporabe, za prikaz se moe koristiti ovjeuljak kao i
kod sekvencijskog dijagrama. Ipak, najee se koristi prikaz sudionika unutar pravokutnika.
3. Analizirajte reenice po redu.
Klijent moe rezervirati zrakoplovnu kartu na internetskom portalu zrakoplovnog prijevoznika.
Pritom klijent najprije poziva podsustav za odabir parametara leta. Klijent odreuje odredite, datum
polaska i broj karata. Podsustav mu dojavljuje ima li dostupnih karata.
30
Prva komunikacija u ovom primjeru je ona izmeu klijenta i podsustava za odabir parametara leta.
Klijent djeluje tako da u sustav unese parametre odredita, datuma polaska i broj zrakoplovnih
karata. Na to mu sustav odgovara s informacijom ima li dostupnih karata. Meudjelovanje klijenta i
podsustava za odabir parametara leta prikazan je na slici 3.15.
Slika 3.15. Meudjelovanje klijenta i podsustava za odabir parametara leta.

Ako ima karata, klijent se prosljeuje podsustavu za detalje leta. Klijent odreuje vrstu karte
(ekonomska ili poslovna) i eljeni zrakoplov na dan polaska. Pretpostavite da klijent rezervira kartu
samo u jednom smjeru tako da ne odreuje povratni termin.
3: [
k
art
e
_sl
ob
odn
e] o
dab
eri(
pu
tni_
raz
red
, av
ion
)
Slika 3.16. Komunikacija klijenta s podsustavom za detalje leta.

Dijagram se iri kao to je prikazano na slici 3.16. Potrebno je primijetiti da se komunikacija odvija
samo u sluaju kad postoji dovoljan broj slobodnih karata. Sintaksa za ogranienje je ista kao i kod
sekvencijskog dijagrama.
Nakon odabira tih parametara, zahtjev klijenta se prosljeuje podsustavu za naplatu. Klijent treba
podsustavu za naplatu definirati ime i prezime, broj putovnice, e-mail i broj bankovnog rauna.
Podsustav za naplatu treba zatraiti od klijenta potvrdu kupovine karte.
Na slici 3.17. prikazana je komunikacija izmeu klijenta i podsustava za naplatu. Pritom klijent
najprije definira sve potrebne informacije sustavu, a sustav od njega zatrai da potvrdi kupnju
zrakoplovne karte.
31
)
na
cu
ra
r_
,b
ail
em
e, u()
nic vrd
ov ot
ut _p
_p zi
br tra
e, : za
j(im 5
ira
fin
de
4:
Slika 3.17. Komunikacija izmeu klijenta i sustava za naplatu.

Ako klijent potvrdi naplatu i ako je upisao broj bankovne kartice, podsustav za naplatu treba u
internom postupku skinuti novac s bankovnog rauna klijenta. Ako je sve uspjeno provedeno, na
kraju podsustav za naplatu alje e-mail klijentu sa zrakoplovnom kartom.
Ovdje je prisutan interni postupak unutar podsustava za naplatu koji se aktivira u sluaju ako
klijent potvrdi kupnju karata. U ovakvim sluajevima najbolje je koristiti ulanano obrojavanje
poruke.
Ulanano obrojavanje se koristi zato da se istakne da je neki postupak unutarnji dio nekog
vanjskog postupka. Ulanano obrojavanje prikazano je u konanom rjeenju zadatka, na slici 3.18.
Neki autori vie vole koristiti ulanano obrojavanje na itavom komunikacijskom dijagramu, pri
emu se sve daljnje poruke koje se dogaaju nakon prve mogu promatrati kao unutarnji postupci
aktivirani prvom porukom. Primjer kako bi izgledao komunikacijski dijagram primjera 3.3.1.1 u tom
sluaju, prikazan je na slici 3.19. Studentima se preporua da ulanano obrojavanje koriste samo u
sluajevima jasne aktivacije nekog postupka unutar nekog drugog postupka da bi se ublaio stupanj
ulanavanja, odnosno da bi se sprijeilo da poruke poinju sa zbunjujuim brojem kao to je npr.
1.3.1.1.2.
32
1.3: definiraj(ime,br_putovnice,email,br_racuna)
1.3.1: zatrazi_potvrdu()
1.3.1.1: potvrdi_ili_odustani()
1.3.1.2: [sve_ok] posalji_mail_klijentu(zr_karta)
Klijent
1.
2:
[k
a
Podsustav za naplatu
rte
_s
lo
b
od
n
e]
o
da
b
er
i(p
ut
ni
_r
az
re
d,
av
io
n)
Podsustav za detalje
leta
Bankovni raun
Podsustav za odabir parametara

leta
Slika 3.19. Konano rjeenje primjera 3.3.1.1, uz jau primjenu ulananog obrojavanja.
33
3.3.2. Napomene u vezi komunikacijskih dijagrama

Za stvaranje i unitavanje sudionika u komunikacijskim dijagramima mogu se koristiti sljedee
kljune rijei: <<create>> i <<destroy>> kao nazivi poruka.

Zadatak 3.6. Plaanje u duanu
Prikazati postupak plaanja proizvoda u duanu komunikacijskim dijagramom. Kupac dolazi na
blagajnu duana s kupljenom robom. Kupac predaje proizvod po proizvod prodavau koji oitava
cijenu proizvoda to se pohranjuje u raunalo. Raunalo svaki puta potvrdi uitanje proizvoda.
Postupak traje sve dok ima proizvoda u koarici. Nakon to je sva roba oitana, prodava pita kupca
ima li karticu za popust od 10% pri kupnji. Ako kupac ima karticu, tada predaje tu karticu na uvid
prodavau, koji upisuje podatke s kartice u raunalo i time ostvaruje popust kupcu. Zatim prodava
pita kupca eli li plaati gotovinom ili kreditnom karticom. U sluaju plaanja gotovinom, kupac
ostvaruje daljni popust od 5% to prodava zapisuje u raunalo.
Raunalo pokazuje na ekranu kupcu kolika je konana cijena. U sluaju da je to sve, kupac
potvruje kupnju prodavau koji pokree naplatu na raunalu. Raunalo zatim ispisuje raun
prodavau i pohranjuje podatke o kupnji u zapis na lokalnom posluitelju. Podaci o kupnji ukljuuju
naziv kupca (String, ako postoji), listu kupljenih artikala (List) i konanu cijenu (float). Na kraju,
prodava uruuje raun kupcu.
Zadatak 3.7. Sustav za preanje piljevine
Rijeiti primjer 3.2.1.2 (Sustav za preanje piljevine) komunikacijskim dijagramom.
34
4. Dijagrami razreda
4.1. Karakteristike razreda
Dijagrami razreda (engl. class diagrams) opisuju razrede i njihove meusobne veze. Jednako tako,
dijagrami razreda opisuju vrste objekata unutar nekog sustava i njihove meusobne statine odnose.
Dijagrami razreda pripadaju strukturnoj skupini UML-dijagrama (engl. structure diagram). Oni ne
opisuju dogaaje, stanja, aktivnosti ili bilo kakvu vremenski promjenjivu karakteristiku sustava koji se
modelira. Naprotiv, dijagrami razreda su statini s obzirom na vremensku komponentu.
Razred ili klasa (engl. class) je osnovni tvorbeni element UML-dijagrama razreda. Stoga su drugi
nazivi za dijagrame razreda dijagram klasa, ili class dijagram. Za ispravno razumijevanje definicije
razreda vano je prvo odrediti znaenje objekta. Objekt predstavlja entitet iz stvarnog svijeta ili neki
koncept, odnosno apstrakciju neega to ima dobro definirane granice i smisao u sustavu. Stoga je
razred opis grupe objekata sa slinim svojstvima, a svaki objekt je obvezno pojedinac (instanca) jedne
klase.
Za svaki razred nuno je definirati naziv, a mogue je odrediti popis atributa i operacija. Makar
atribute i operacije nije nuno definirati, bez njih razred nema implementacijsku svrhu. Za atribute
nuno je odrediti njihov naziv i tip podataka, a za operacije njihovu definiciju koja ukljuuje naziv
operacije, te sve ulazne i izlazne parametre.
Primjer 4.1.1. Definirati razred Student
Svaki student ima svoj identifikacijski broj (ID, podatkovnog tipa Long), ime (String), prezime
(String) i prosjek ocjena (Double). Student moe prijaviti ispit, odjaviti ispit i pristupiti ispitu. Za
prijavu i odjavu ispita potrebna je ifra predmeta (Integer), a operacije vraaju logike (boolean)
vrijednosti da li je izvrenje uspjelo ili ne. Pristupanje ispitu je definirano drugaije: ulazni argument
operacije je ifra predmeta (Integer), a povratna vrijednost (Double) je dobivena ocjena na ispitu. Ako
je manja ili jednaka 1 smatra se da je student pao na ispitu, ili -1 ako je dolo do greke u radu
sustava.
Rjeenje:
Tekst zadatka jasno definira koji atributi se trae u definiciji razreda i koji su njihovi tipovi. Nazivi
atributa i operacija moraju biti jasno razumljivi i saeti. Dodatno, u odabiru naziva operacija dobro je
slijediti konvencije. Potrebno je definirati tri operacije koje imaju jedan ulazni parametar (cjelobrojna
vrijednost). Prve dvije operacije (prijaviIspit i odjaviIspit) vraaju vrijednost tipa Bool, dok trea
operacija (pristupiIspitu) vraa vrijednost tipa Double. Rjeenje primjera 4.1.1 prikazano je na slici
4.1.

35
4.2. Odnosi izmeu razreda

Dva osnovna tipa odnosa izmeu razreda su pridruivanje (veza ili asocijacija) i podtip. Odnosi
izmeu razreda: pridruivanje i podtip prikazani su na slici 4.2.
Slika 4.2. Odnosi izmeu razreda: pridruivanje i podtip.

Student pristupa ispitu je jedan primjer veze, dok je Asistent je zaposlenik fakulteta primjer
podtipa. Pridruivanje moe biti jednostruko, viestruko i refleksivno. Agregacija i kompozicija su
vrste pridruivanja. Odnos podtip odreen je mehanizmom nasljeivanja u meusobno suprotnim
smjerovima generalizacije i specijalizacije. Osim navedenog, UML-dijagrami razreda mogu prikazati
atribute i operacije razreda, njihova svojstva i ogranienja nad njima, pakete, ovisnost, tipove
podataka, obrojavanje (enumeraciju), komentare i vie drugih strukturnih svojstava sustava koji su
opisani u sljedeim potpoglavljima.
4.3. Pridruivanje
Pridruivanje ili veza (engl. association) opisuje statine odnose izmeu dva pojedinca, odnosno
instance, razreda. Veze dijelimo na jednosmjerne, dvosmjerne, agregacije i refleksivne. Tip agregacije
ukljuuje i kompoziciju.
Ako je vrh neke asocijacije oznaen strelicom, onda je definiran njezin smjer (engl. navigability).
Veze ovisno o njihovom smjeru pridruivanja dijele se na unidirekcionalne i bidirekcionalne.
Unidirekcionalne veze (jednosmjerne) imaju smjer definiran samo na jednom vrhu, dok
bidirekcionalne (dvosmjerne) imaju smjer definiran na oba vrha. Ako smjer nije eksplicitno definiran,
smatra se da je veza nepoznata (nedefinirana) ili bidirekcionalna. Ako je veza bidirekcionalna, onda
njezini smjerovi moraju biti meusobno inverzni, odnosno raunalni kod koji implementira
bidirekcionalnu vezu u obje klase mora imati suprotnu funkcionalnost.
Primjer 4.3.1. Dvosmjerno pridruivanje
Student upisuje predmet po vlastitom izboru. Izraditi UML-dijagram razreda i pripadni kod u
programskom jeziku C++.
Rjeenje:
Na dijagramu se mora nalaziti dvosmjerna veza izmeu razreda Student i Predmet koju se
interpretira kao student upisuje predmet. Ovdje dvosmjerna veza znai da studenti vide svoj
predmet, a predmet ima informaciju koji studenti su ga odabrali. Programski kod u jeziku C++ je
36
jednostavan. Razred Student ima u svojoj definiciji pokaziva na pojedinca razreda Predmet i
obrnuto, Predmet ima vlastiti pokaziva na pojedinca razreda Student.
Osim rune izrade programskog koda moe se iskoristiti funkcionalnost ureivaa ArgoUML koji iz
dijagrama automatski generira kd u nekoliko programskih jezika. Ako programski jezik ne podrava
pokazivae, implementacija dvosmjerne veze ostvaruje se pomou obine varijable. Rjeenje
primjera 4.3.1 prikazano je na slici 4.3.
class Student {
public:
Predmet *myPredmet;
class Predmet {
public:
Student *myStudent;
};

Primjer 4.3.2. Jednosmjerno i dvosmjerno pridruivanje
Student upisuje predmet po vlastitom izboru. Informacija o upisima studenata i njihovom odabiru
predmeta pohranjena je u upisnim podacima. Zbog sigurnosnih razloga studenti nemaju uvid u sve
upisne podatke. Takoer, osobni podaci o studentima ne smiju biti dostupni kroz podatke o upisanim
predmetima. Implementirati dizajnirani sustav u programskom jeziku C++.
Rjeenje:
U rjeenju ovog primjera moraju se koristiti jednosmjerne i dvosmjerne veze. Zbog jednosmjerne
veze od Student prema Predmet, Predmet nema referencu na pojedince Student i ne moe doi do
njihovih podataka. Zato se uvodi novi razred UpisniPodaci koji je povezan jednosmjernom vezom sa
Student i dvosmjernom s Predmet. Na taj nain Predmet moe preko dvosmjerne veze s UpisniPodaci
doi do pokazivaa tog razreda na pojedinca tipa Student i tako dobiti informacije o studentima koji
su upisali predmet. Rjeenje primjera 4.3.2 prikazano je na slici 4.4.
4.4. Vrhovi i nazivi veza

Veza uvijek ima dva vrha, a svaki vrh obvezno dodiruje jedan od dva razreda u vezi. Pri tome se
kae da su vrhovi pridrueni razredima. Veza koja spaja vie od dva razreda nije dozvoljena. Vrhovi se
jo nazivaju uloge ili role (engl. association role). Svaki vrh moe, ali i ne mora imati naziv ili ime (engl.
37
class Student {
public:
Predmet *myPredmet;
class Predmet {
public:
UpisniPodaci *myUpisniPodaci;
};
class UpisniPodaci {
public:
Student *myStudent;
Predmet *myPredmet;
};

role name), viestrukost, vidljivost i druga svojstva. Nazivi uloga su imenice ili glagoli. Obino u
programskom kodu naziv uloge je identian nazivu varijable koja predstavlja vezu izmeu razreda. U
posljednjem primjeru pokaziva na Predmet eksplicitno je nazvan upisuje dok u primjeru koji
prethodi tome ima generiki naziv automatski dodijeljen od ureivaa UML-dijagrama.
Osim naziva uloga i veza moe imati vlastiti naziv. U praksi ee se susreu imenovane veze od
vrhova. Nije potrebno imenovati svaku vezu ve samo onda kada to doprinosi razumijevanju
dijagrama. Veze se nazivaju glagolima ili rjee imenicama, odnosno mogu opisivati akciju koju jedan
razred vri nad drugim (npr. veza slua_predmet izmeu razreda Student i Predmet), ili odnos
izmeu dva razreda (npr. mentor izmeu razreda Profesor i Student). Primjerice, vezu mentor
moe se jednako tako imenovati glagolskim oblikom je_mentor_od. Ako se veza opisuje glagolom
obino se koristi tree lice jednine prezenta, a za imenice, nominativ jednine. Naziv veze uvijek se
odabire tako da je sukladan smjeru pridruivanja.
Naposljetku, vano je istaknuti da je ponekad na dijagramu dovoljno naznaiti samo jedan naziv
vrha. Tada se naziv veze poistovjeuje s nazivom imenovanog vrha, pri emu onda i naziv veze moe
imati oznaena svojstva poput vidljivosti. U tom sluaju, sva svojstva naziva vrha prenose se na naziv
veze.
38
Primjer 4.4.1. Naziv veze

Student moe upisati predmet po vlastitom izboru. Oznaiti pridruivanje izmeu razreda. Izraditi
UML-dijagram razreda i pripadni kod u programskom jeziku C++.
Rjeenje:
Rjeenje je gotovo identino prvom primjeru iz prethodnog podpoglavlja, osim definiranog naziva
pridruivanja koji se u programskom kodu preslikao na naziv pokazivaa na pojedinca drugog razreda
u vezi. Rjeenje primjera 4.4.1 prikazano je na slici 4.5.
class Student {
public:
Predmet *upisuje;
};
class Predmet {
public:
Student *upisuje;
};
4.5. Viestrukost pridruivanja

Za svaki vrh veze mogue je definirati viestrukost veze (engl. multiplicity) koja odreuje koliko
pojedinaca, ili objekata, moe sudjelovati u odnosu izmeu dva razreda.
Dozvoljene vrijednosti na bilo kojoj strani pridruivanja:
1
= tono 1 pojedinac
n1
= bilo koji tono odreen broj, npr. 0, 1, 3, 5, 15
n1.. n2
= izmeu n1 i n2, npr. 58 5, 6, 7 ili 8
n1..n
= izmeu n1 i vie pojedinaca
n1n2, n3
= kombinacija, npr. 47, 9 4, 5, 6, 7 ili 9
n..*
= n ili vie pojedinaca, neogranieno
0..* ili * ili n = vie pojedinaca, neogranieno
Ako viestrukost pridruivanja nije naznaena podrazumijeva se vrijednost 1 (tono 1 pojedinac).
39
U programskom kodu viestrukost se implementira dinamikom strukturom podataka, npr.

std::vector u C++, koja sadrava pokazivae na drugi razred.
Primjer 4.5.1. Viestrukost veze izmeu razreda Student i Indeks
Izradite UML-dijagram razreda gdje svakom studentu pripada tono jedan indeks.
Rjeenje primjera 4.5.1 prikazano je na slici 4.6.

Primjer 4.5.2. Viestrukost veze izmeu razreda Asistent i Ispit
Nakon zavretka ispitnog roka asistent svaki put ispravlja tono 60 pismenih ispita.

Primjer 4.5.3. Viestrukost veze izmeu razreda Profesor i Student
Na nekom projektu profesor mora voditi barem pet studenata. Studenti mogu biti samo na
jednom projektu. Ako to ele, studenti ne moraju prijaviti sudjelovanje na projektu.
4.6. Refleksivno pridruivanje

Vie pojedinaca istog razreda ponekad moraju meusobno komunicirati. Ova vrsta veze u
dijagramu razreda prikazuje se pomou refleksivnog pridruivanja ili refleksivne agregacije. Ako je
potrebno imenovati vezu koriste se nazivi uloga (vrhova), a ne nazivi veza. Kao i kod svakog
pridruivanja potrebno je odrediti njegovu viestrukost.
Refleksivno pridruivanje moe se primijeniti na bilo koju vrstu pridruivanja dijagrama razreda. To
jest, i na jednosmjerne veze, dvosmjerne, ovisnost, i tako dalje.
40
Primjer 4.6.1. Refleksivna jednosmjerna veza

U nekom auto-servisu otvaraju se radni nalozi nakon zaprimanja automobila klijenata. Ponekad je
potrebno nakon otvaranja jednog radnog naloga otvoriti novi koji je pridruen prethodnom. Broj
radnih naloga je neogranien.
Rjeenje:
Nuno je na razred RadniNalog primijeniti jednosmjernu refleksivnu vezu. Novi radni nalog je
uvijek pridruen tono jednom prethodnom radnog nalogu. Budui da neki radni nalozi nemaju niti
jedan drugi pridrueni nalog, a njihov krajnji broj je neogranien viestrukost veze je 1 i 0..*. Rjeenje
primjera 4.6.1 prikazano je na slici 4.9.
4.7. Agregacija i kompozicija

Agregacija (engl. aggregation) je vrsta pridruivanja koja pokazuje da jedan razred sadri druge, tj.
da je dio drugog razreda. Kae se da je razred agregiran (sadran) u drugom razredu. To je oblik
odnosa nadskup-podskup, odnosno vei skup-manji skup. Agregacija se jo naziva i odnos cjelina-dio
(engl. whole-part relationship).
Kompozicija (engl. composition) je vrsta pridruivanja slina agregaciji, ali bitna razlika jest da se
prilikom unitavanja (engl. termination) objekta razreda (tj. pojedinca) uvijek unitavaju i pojedinci
razreda koji su dio poetnog objekta. Dakle, ako sustav oslobaa zauzetu radnu memoriju sustava i
brie pojedince, osim njih bit e izbrisani i svi pojedinci koji su s njim povezani kompozicijom. U
sluaju pridruivanja agregacijom to se nee dogoditi i drugi pojedinci (agregirani s poetnim
objektom) ostati e u radnoj memoriji sustava.
Simbol agregacije i kompozicije uvijek dodiruje razred nadskup, a prazna linija razred podskup.
Veze agregacija i kompozicija usmjerene su od nadskupa prema podskupu.
Primjer 4.7.1. Knjiara i police
U nekoj knjiari nalazi se vie polica koje su organizirane tematski, tako da se unutar polica mogu
nalaziti police, unutar njih druge police, i tako dalje. Svakoj polici pripadaju neke knjige. U sluaju
reorganizacije knjiare, knjige se rasporeuju na druge police. Svaka knjiga ima svoj ISBN (String),
naziv (String), izdavaa (String) i datum izdanja (Date). Rjeenje primjera 4.7.1 prikazano je na slici
4.10.
41
Primjer 4.7.2. Organizacija fakulteta

Neki fakultet sastoji se od jednog ili vie zavoda, a svaki zavod od jedne ili vie zavodskih grupa.
Fakultet ima svoj matini broj (String) i naziv (String). Zavod ima svoj naziv (String) i broj rauna
(String). Naziv i broj rauna zavoda nasljeuju i zavodske grupe, s tim da one osim toga imaju i svoj
naziv grupe te dodatno, naziv glavnog laboratorija (String). Rjeenje primjera 4.7.2 prikazano je na
slici 4.11.
4.8. Pridruivanje, agregacija ili kompozicija?

Vano pitanje za ispravnu izradu dijagrama razreda jest: "Kada se koristi koja vrsta pridruivanja?"
Odnosno, kada je potrebno koristiti obine jednosmjerne ili dvosmjerne veze, a kada agregaciju i
kompoziciju?
Ako se primijeti da su dva razreda u svezi i da jedan obuhvaa ili sadrava drugi, odnosno, da su
povezana odnosom cjelina-dio, tada se obino radi o agregaciji. Ova odluka moe ovisiti i o kontekstu
kako se promatra sustav. Primjerice, za auto-servis razred Guma moe biti povezan agregacijom s
razredom Vozilo jer su gume bitan i nedjeljiv dio automobila. Meutim, za trgovinu auto-gumama
razredi Vozilo i Guma mogu biti povezani obinim pridruivanjem jer su u kontekstu njihovog sustava
42
gume, kao proizvod koji prodaju, puno vanije od vozila te se na njih gleda odvojeno, a ne kao na
jedinstvenu cjelinu nadskup-podskup.
Nakon prve odluke o vrsti veze potrebno je uoiti da li pojedinci razreda podskupa ostaju u sustavu
nakon brisanja objekta razreda nadskup. U sluaju da to nije eksplicitno naglaeno, ispravno je
pretpostaviti da pojedince razreda podskup nije potrebno izbrisati iz radne memorije. Naravno, ako
se povezani razredi ne odnose jedan prema drugom kao cjelina-dio, onda se radi o obinoj
jednosmjernoj ili dvosmjernoj vezi. Naposljetku, ovisno o opisu sustava bira se jedna od ove dvije
veze, s tim da se bidirekcionalna podrazumijeva unaprijed ako nisu zadana nikakva ogranienja na
odnos pridruenih razreda.
Ukratko, postupak odabira ispravnog pridruivanja je jednostavan: prvo je potrebno odluiti da li je
veza obina ili agregacija. Ako je agregacija odluuje se da li je moda ipak kompozicija. U suprotnom,
ako je veza ipak obina, prosuuje se da li je jednosmjerna, ali ako nije onda je zasigurno dvosmjerna.
4.9. Atributi
Atributi (engl. attributes) su lanske varijable razreda. Atributi imaju sljedea svojstva: stupanj
vidljivosti (engl. visibility), naziv (engl. name), vrsta ili tip (engl. type), poetna vrijednost (engl. initial
value). Takoer za atribute je dozvoljeno, ali nije nuno, definirati promjenjivost (engl. changeability)
i modifikator (engl. modifier).
Za sve atribute razreda potrebno je definirati svojstva vidljivost (engl. attribute visibility) i vrsta ili
tip (engl. attribute type), a mogue je definirati i vie razliitih svojstva promjenjivosti atributa (engl.
attribute changebility). Stupanj vidljivosti atributa odreuje koji pojedinci mogu pristupiti atributima
razreda. Mogue su etiri vrijednosti: javno (public; atribut je dostupan svim razredima i paketima),
privatno (private; atribut je dostupan samo unutar istog razreda), zatieno (protected; atribut je
dostupan unutar istog razreda i izvedenih razreda), a mogue je definirati i stupanj vidljivosti paket
(package; atribut je dostupan svim razredima istog paketa).
Oznake public, private i protected mogu se zapisati skraeno simbolima +, - i #. U definiranju
svojstva vrste atributa dozvoljene su razne oznake tipova. To su UML-tipovi (Boolean, Integer, String,
UnlimitedInteger), Java tipovi podataka (byte, char, double, float, int), Java razredi iz paketa java.util
(Collection, Date, List, Set, SortedSet, Time, Vector, ), java.lang, java.lang.math i java.net (URL)
paketa. Takoer je doputeno koritenje vlastitih tipova razreda i podataka koji su definirani u istom
dijagramu. Koritenje razreda iz drugih dijagrama nee dopustiti mnogi ureivai UML-dijagrama, a
prilikom rune izrade dijagrama potrebno ih je naznaiti i objasniti UML-komentarima.
U nekima ureivaima UML-dijagrama mogue je definirati dodatna svojstva promjenjivosti
atributa. Tako su mogua i svojstva: addOnly (vrijednost atributa moe se samo poveavati),
changeable (vrijednost atributa moe se nesmetano mijenjati), frozen (vrijednost atributa ili
asocijacije ne smije se promijeniti tijekom ivota (engl. lifetime) pripadajueg objekta), static
(modifikator, vrijednost atributa je konstanta, ne mijenja se i ne ovisi o ivotu objekta), read-only
(vrijednost atributa ne moe se mijenjati izvan objekta kojemu pripada, ureiva ArgoUML ne
podrava ovo svojstvo). Svojstvo read-only nije isto kao i frozen, jer je kod read-only mogue mijenjati
atribut unutar objekta kojemu pripada. Podrazumijevano svojstvo promjenjivosti atributa je
changeable.
Primjer 4.9.1. Bolniki informacijski sustav i stupanj vidljivosti atributa
43
U nekom bolnikom informacijskom sustavu nalaze se podaci o zaposlenicima. Svaki zaposlenik

ima vlastitu ifru (Integer), ime (String), prezime (String), JMBG (String), OIB (String) i oznaku sobe u
kojoj radi (String). ifra i OIB su zatieni podaci, JMBG privatni, a ime i prezime te oznaka sobe su
javno dostupni.
Rjeenje:
U rjeenju ovog kratkog zadatka, dovoljno je definirati samo jedan razred, ali nuno je oznaiti
stupnjeve vidljivosti atributa. Koriste se simboli + (javno dostupno), - (privatni podatak) i #
(zatieni podatak). Rjeenje primjera 4.9.1 prikazano je na slici 4.12.
4.10. Operacije
Operacije (engl. operations) su procesi koje razred moe izvriti. Drugim rijeima, to su vlastite
metode i funkcije razreda. Najvanija svojstva operacija su vidljivost, te ulazni i izlazni parametri.
Svojstvo vidljivosti je identino kao kod atributa i mogue vrijednosti su public, package, protected i
private. Parametri ili argumenti su svojstveni samo za operacije. Oni odreuju ulazne vrijednosti koje
operacija moe dobivati i izlazne vrijednosti koje vraa pozivajuim funkcijama.
Osim vidljivosti i argumenata u ureivau ArgoUML za operacije mogu se dodatno odrediti
svojstva: modifikator (static, abstract, leaf, root, query) i istodobnost (sequential, guarded,
concurrent).
4.11. Nasljeivanje
Nasljeivanje (engl. inheritance) je temeljni koncept objektno-orijentiranog programiranja koji se
moe uspjeno modelirati UML-dijagramima. Nasljeivanje je oblik odnosa izmeu razreda, odnosno
nasljedna veza izmeu razreda. Jedan razred je roditelj (nadrazred) jednom ili vie drugih razreda
(djeca ili podrazredi).
Kae se da je objekt koji se nasljeuje proiren u objektu koji ga nasljeuje. Stoga su definirane
dvije vrste odnosa izmeu razreda: generalizacija i specijalizacija. Generalizacija omoguuje stvaranje
nadrazreda koja objedinjuje strukturu i ponaanje zajedniko za nekoliko razreda, a specijalizacija
omoguuje stvaranje podrazreda koja predstavlja dodavanje novih elemenata.
Odnosi generalizacija i specijalizacija usmjereni su u meusobno suprotnim smjerovima.
Generalizacija je usmjerena od podrazreda prema nadrazredu, a specijalizacija od nadrazreda prema
podrazredu. Na dijagramima razreda veza nasljeivanja uvijek je usmjerena od podrazreda prema
44
nadrazredu, tj. u smjeru generalizacije. Ponekad je korisno nasljeivanje crtati tako da je nadrazred
smjeten iznad podrazreda jer to pridonosi jednostavnijem i brem razumijevanju dijagrama razreda.
Kod nasljeivanja uvijek vrijede sljedea pravila:
Podrazred uvijek ima vie ili jednak broj svojstava u odnosu na nadrazred
Podrazred nasljeuje od nadrazreda atribute, relacije i operacije
Podrazred moe biti proirena atributima, operacijama ili relacijama
Podrazred moe imati svoju implementaciju operacija koje je naslijedila

Napomena: Nasljeivanje nema viestrukost. Ovo svojstvo nasljeivanja je oito i samorazumljivo,
ali korisno ga je izriito naglasiti da bi se izbjegle greke studenata u rjeenjima ispita.
Primjer 4.11.1. Bolniki informacijski sustav i nasljeivanje razreda
Bolniki informacijski sustav iz primjera 4.9.1. je potrebno proiriti. Medicinske sestre i lijenici su
zdravstveno osoblje. Zdravstveno osoblje i administracija su razliite vrste zaposlenika bolnice.
Zaposlenici imaju zatienu operaciju s kojima se dohvaa njihova ifra i OIB, te javnu operaciju za
dohvaanje radne sobe. Zdravstveno osoblje moe imati radnu obvezu u nekoliko soba istodobno, te
imaju vlastitu implementaciju operacije dohvaanja radne sobe. Lijenici mogu postavljati dijagnozu.
Medicinske sestre mogu izmjeriti temperaturu i tlak bolesnika. Rjeenje primjera 4.11.1 prikazano je
na slici 4.13.
4.12. Nasljeivanje ili agregacija?

Zadan je sljedei problem: potrebno je definirati razrede raunalnog sustava koji prati studente,
upisane predmete i profesore kao nositelje tih predmeta. Pri tome se sustav mora moi jednostavno
proiriti i nadograditi tako da kasnije izmjene zahtijevaju minimalne preinake programskog koda.
esto zadaci ovog tipa eksplicitno zahtijevaju sve korisnike sustava proiriti u jedan nadrazred koji
sadrava njihove zajednike podatke kao to je ime, prezime, OIB, i tako dalje. Ali ak ako se to
izriito ne zahtijeva, dobra je praksa iskoristiti nasljeivanje za obuhvaanje zajednikih svojstava
dvaju ili vie razreda. U ovom sluaju razredi Student i Profesor mogu naslijediti razred Osoba u
kojemu se nalaze atributi ifra, Ime, Prezime i OIB. Pri tome Profesor i Studenti imaju vlastite
specifine atribute kao to su, recimo, RasporedPredavanja za profesora i ProsjekOcjena za studenta.
Sada neka se pretpostavi da je u sustav potrebno dodati redovne i izvanredne studente, a svaki od
njih ima svoje specifine podatke ili operacije. Ako se dodaju novi razredi RedovniStudent,
IzvanredniStudent i izvede ih se iz razreda Student napravit e se greka u dizajnu. Makar je takvo
rjeenje ispravno, dugorono e se takav sustav morati puno vie izmjenjivati nego da se koristila
45
agregacija i nasljeivanje zajedno. Primjerice, to e se dogoditi ako neki student promijeni status iz
izvanrednog u redoviti? U tom sluaju morat e pojedinac od razreda IzvanredniStudent promijeniti
razred u RedovniStudent. to ako se doda novo ogranienje? Naprimjer, student ima stipendiju i
student nema stipendiju? Samo pomou nasljeivanja morale bi se raditi dva nova podrazreda i bilo
bi nuno koristiti viestruko nasljeivanje da se pokriju sve mogunosti koje se mogu dogoditi u
sustavu redovni student sa stipendijom, redovni student bez stipendije, i tako dalje. Ispravno i
nefleksibilno rjeenje prikazano je slikom 4.14.
Slika 4.14. Ispravno i nefleksibilno rjeenje.

Stoga bi jedino skalabilno rjeenje, odnosno fleksibilni dizajn koji dugorono zahtijeva minimalne
preinake, bilo koritenje agregacije za novi razred KlasifikacijaStudenta iz kojeg se izvode podrazredi
RedovniStudent i IzvanredniStudent, kao to je prikazano na slici 4.15.
46
Slika 4.15. Ispravno, skalabilno i fleksibilno rjeenje.

Nasljeivanje je potrebno koristiti samo kada se zajednika svojstva dijele ili rastavljaju od
specifinih, dok se agregacija koristi za modeliranje sloenih ili mijeanih relacija izmeu razreda.
esto je potrebno nasljeivanje i agregaciju koristiti zajedno.
4.13. Ovisnost
Ovisnost (engl. dependency) je odnos koje pokazuje da jedan razred ovisi o drugome razredu, ili
jedan paket o drugome paketu, ili jedna komponenta o drugoj, i tako dalje. Moe se openito rei da
je ovisnost relacija izmeu dva entiteta u kojoj promjena u jednoj (neovisnom) entitetu moe utjecati
na drugi (ovisni) entitet. Pri tome se neovisni entitet naziva isporuitelj (engl. supplier), a ovisni
klijent (engl. client). Ovisnost je jednosmjerna (unidirekcionalna) veza i u smjeru simbola veze izmeu
dva entiteta u dijagramu itamo je kao: B ovisi o A. Primjerice, ako postoje dva razreda A i B, te ako
se zna da B ovisi o promjenama stanja razreda A, tada e se nacrtati UML veza ovisnosti, usmjerena
od B prema A. U ovom primjeru razred A je isporuitelj i B klijent. Ovisnost izmeu razreda (B ovisi o
A) prikazana je na slici 4.16.
Slika 4.16. Ovisnost izmeu razreda (B ovisi o A).

U programskom kodu ovisnost moemo implementirati na vie naina, primjerice s funkcijama
koje oslukuju dogaaje (engl. event handlers). U tom sluaju razred B koji ima navedenu funkciju je
47
ovisan o razredu A koji generira dogaaj. Ureiva ArgoUML ne preslikava svojstvo ovisnosti u
programski kod.
Zadatak 4.13.1. Vojno osoblje
Brigadir i satnik su vojno osoblje, kao i vojnik. Brigadir smije odlikovati i promicati sve lanove vojnog
osoblja (osim samog sebe).
Rjeenje:
itanjem zadatka odmah se uoava jedan nadrazred (vojno osoblje) i tri podrazreda koji ga
nasljeuju (brigadir, satnik i vojnik). Razred Brigadir ima dvije operacije odlikuj() i promakni() koje
izvrava nad pojedincima razreda VojnoOsoblje. Na taj nain vojno osoblje ovisi o brigadiru (veza
ovisnosti), ali on ne ovisi sam o sebi. Brigadir ne moe sam sebe promaknuti i odlikovati, odnosno
razred Brigadir ne moe izvriti svoje operacije nad sobom i zato se zna da nema potrebe za
refleksivnim pridruivanjem. Zahtjevi nad razinama vidljivosti u zadatku nisu eksplicitno navedeni,
stoga se pretpostavlja da su sve operacije i atributi javni (public). Operacije nemaju izriito navedene
ulazne i izlazne parametre pa ih se ne mora modelirati. Rjeenje primjera 4.13.1 prikazano je na slici
4.17.
Satnik
Brigadir
Vojnik
+odlikuj()
+promakni()
VojnoOsoblje
4.14. Suelje i realizacija

Suelje (engl. interface) je skup operacija koje specificiraju usluge nekog razreda. Suelje definira
skup operacijskih specifikacija (tj. njihovih potpisa), ali nikada skup njihovih implementacija. Drugim
rijeima, suelje je vrsta razreda ali bez atributa, dok sve operacije imaju samo definiciju, bez tijela
funkcije i implementacije programskog koda. Ispravan izgled UML-simbola suelja je slian razredu ali
bez prostora za atribute.
Suelje je usko povezano s odnosom realizacije (engl. realization) koje oznaava ostvarenje suelja.
Jedan ili vie razreda realiziraju ili ostvaruju suelje, odnosno koriste suelje kako bi implementirali
operacije definirane u suelju. Odnos realizacije je slian nasljeivanju, samo to se kod realizacije
nasljeuju samo operacije s parametrima, bez implementacije. Veza realizacije (strelica) uvijek je
48
usmjerena od razreda prema suelju. U ureivau ArgoUML realizacija ima dva svojstva: suelje
(supplier) i razred koji ostvaruje suelje (client).
Za razliku od viestrukog nasljeivanja (engl. multiple inheritance) koje je zabranjeno u nekim
objektno-orijentiranim programskim jezicima (npr. Java), viestruka realizacija je uvijek doputena.
Viestruka realizacija omoguuje tzv. ope viestruko nasljeivanje (engl. general multiple
inheritance). U Javi je tako mogue implementirati vie razreda bez mijenjanja njihove definicije, to
je u konanici slino uinku viestrukog nasljeivanja.
Primjer 4.14.1. Definirati suelje Zaposlenik
U nekoj organizaciji postoje odjeli Nabave i Prodaje. Odjeli imaju vlastite zaposlenike, koji rade
samo u tom odjelu. Svi zaposlenici dobivaju isplate mjesenih plaa, ali zaposlenici nabave i prodaje
imaju drugaiji algoritam izrauna iznosa plae. Zaposlenici prodaje mogu prodati proizvode
organizacije, a zaposlenici Nabave kupiti ulazni materijal potreban za proizvodnju. Operacije nabave i
prodaje vraaju double vrijednosti. Zaposlenike je potrebno definirati koristei zajedniko suelje.
Rjeenje:
Iz teksta zadatka razvidna je nunost koritenja suelja u definiranju dvije vrste zaposlenika
ZaposlenikNabava i ZaposlenikProdaja. Oba razreda imaju vlastitu implementaciju operacije
isplatiPlacu(). Pretpostavljamo da operacija vraa vrijednost tipa double (iznos mjesene plae).
Dodatno ZaposlenikNabava ima vlastitu operaciju nabaviMaterijal(), a ZaposlenikProdaja
prodajProizvod(). Oba razreda realiziraju suelje Zaposlenik koje mora imati definiciju operacije
isplatiPlacu(). Vidljivosti svih operacija su public jer drugaije nije traeno, niti eksplicitno niti
implicitno. Zaposlenici rade u dva razliita odjela (Nabava i Prodaja) koji nasljeuju zajedniki razred
Odjel. Odjeli pripadaju Organizaciji. U odreivanju viestrukosti uoava se da postoji samo jedan
odjel Nabave i jedan Prodaje, i samo jedna Organizacija. Dakle, viestrukost oba pridruivanja je 1 1.
Nestankom (brisanjem) organizacije odjeli moraju biti izbrisani iz sustava, stoga su pridrueni
Organizaciji pomou kompozicije. U pravilu, moe se rei da, ako u tekstu zadatka nije eksplicitno
navedeno da se pojedinci briu iz sustava nakon brisanja razreda koji ih sadrava, tada se koristi
agregacija.
49
4.15. Tipovi podataka i obrojavanja (enumeracije)

Tipovi podataka (engl. data types) su slini razredima, ali za razliku od razreda pojedinci se
identificiraju samo po vrijednosti. U dijagramu nisu povezani s razredima. U dijagramu razreda iznad
naziva obrojavanja obavezno se nalazi oznaka <<enumeration>>.
Obrojavanje (engl. enumeration) je oblik tipa podataka koji sadrava ureene parove imenovanih
identifikatora i njima pridruenih vrijednosti. Te vrijednosti nazivaju se obrojani literali.
Obrojavanja se koriste za praktiniji i razumljiviji opis razliitih diskretnih vrijednosti sustava. Kao i
tipovi podataka, oni nisu povezani s razredima.
Primjer 4.15.1. Ocjene komisije
Na nekom specijalistikom studiju nakon polaganja zavrnog ispita komisija odluuje o uspjehu
pristupnika. Mogue ocjene su jednoglasno poloio, poloio s veinom glasova, nije poloio.
Rjeenje:
Ocjene komisije mogue je predstaviti s tri diskretne vrijednosti ili kategorije. Pogodno je koristiti
obrojavanje za opis ocjena komisije. Unose se kategorije i pridruuju im se brojane vrijednosti:
JednoglasnoPoloio = 1, Poloio = 2, i NijePoloio = 0. Budui da u tekstu nema ogranienja pristupa
sve vrijednosti moraju biti javne (public). Rjeenje primjera 4.15.1 prikazano je na slici 4.19.
50
4.16. Komentari
Unato irokoj formalnoj izraajnosti dijagrama razreda, ponekad je potrebno koristiti i komentare
za uinkovitije razumijevanje opisanog sustava. Komentare ne treba upotrebljavati uvijek i u svakoj
prilici. Oni se koriste za dodatni opis svrhe nekog razreda, atributa, veza, operacija i drugih elemenata
dijagrama. U komentarima je poeljno biti jasan i saet, te obuhvatiti sve bitne aspekte UMLelementa koji se opisuje.
Komentari mogu biti povezani s konkretnim elementom dijagrama (pridruivanje, razred, ), ili se
mogu odnositi na cijeli dijagram. Specifini komentari povezani su s elementom neoznaenom
vezom, a komentari o cijelom dijagramu nemaju veze i nalaze se na rubu dijagrama, obino u jednom
od uglova. U radu s alatom ArgoUML osim komentara za detaljniji opis elementa dijagrama mogue
je koristiti i karticu Documentation na dnu ekrana.
Primjer 4.16.1. Komentar pridruivanja
U knjiari se nalaze police na kojima su knjige. Dolaze kupci i uzimaju knjige s polica. Ako se neke
police bace, ne bacaju se i knjige nego se preraspodjele na druge police. Neke police moda nemaju
knjige. Kupci mogu kupiti knjige.
Rjeenje:
Dijagram iz ovog primjera je jednostavan, ali uoavaju se barem dva mogua rjeenja problema.
Budui da iz teksta zadatka nije sigurno koje se rjeenje zahtijeva, koriste se komentari kako bi se
objasnilo vlastito razmiljanje. Rjeenje primjera 4.16.1 prikazano je na slici 4.20.

51

Zadatak 4.1. Organizacija poduzea
Neko poduzee sastoji se od jednog ili vie odjela, a na elu svakog odjela je direktor odjela. Svaki
odjel moe imati vie pododjela. Svaki pododjel ima svog direktora pododjela i radnike. Postoje dva
tipa zaposlenika: direktori i radnici. Nadalje, direktori mogu biti direktori odjela ili direktori
pododjela. Svaki zaposlenik moe raditi na vie poslova, a svaki posao moe raditi nijedan ili vie
zaposlenika. Konkretni posao moe biti administrativni ili razvojni. Svaki posao ima svoj naziv (String)
i rok dovrenja (Date). Ako je posao razvojni, onda on sadri i matini broj nekog drugog poduzea
(String) za koje se takav posao obavlja. Direktor odjela moe zaposliti ili otputati sve direktore
pododjela i sve radnike u pododjelima (oni ovise o njemu). Direktor pododjela ne moe otputati niti
zapoljavati radnika, ali ima opciju da upita direktora odjela ako se ukae potreba za otputanjem ili
zapoljavanjem radnika. Poduzee ima svoj matini broj (String), broj rauna (String) i ukupan broj
zaposlenika (int). Svaki odjel ima svoj naziv i adresu, a svaki pododjel, osim naslijeenog naziva i
adrese odjela, ima i vlastiti naziv. Svaki zaposlenik ima svoj matini broj u poduzeu i ime i prezime.
Zadatak 4.2. Organizacija knjiare
Neka se knjiara sastoji od dvije organizacijske jedinice: prodaje i nabave. Knjiara ima dvije vrste
zaposlenika: ef knjiare i radnici, s tim da uvijek postoji tono jedan ef knjiare i barem jedan
radnik. ef knjiare vodi obje organizacijske jedinice. Jedinice prodaje i nabave imaju vlastite vrste
radnika. Radnici koji rade u prodaji ne rade u nabavi, i obrnuto. Ako se prodaja ili nabava zatvore,
radnici nee zato biti otputeni iz knjiare. Svaki zaposlenik ima svoj JMBG (String), ime (String) i
prezime (String). Glavni artikal s kojim barata i prodaja i nabava je knjiga. Svaka knjiga ima svoj ISBN
(String), naziv (String), izdavaa (String) i datum izdanja (Date). U jedinici prodaje nalazi se jedna ili
vie polica na kojima se nalazi vie knjiga. U nekom trenutku jedna knjiga moe se nalaziti samo na
jednoj polici. Ako se neku policu ukloni ili premjesti, pripadajue knjige prebacuju se na drugu policu
(knjige ne nestaju zajedno s policom). Isto tako, ako se jedinica prodaje ugasi, s njome ne nestaju i
police. Jedinica nabave odjednom dobavlja grupe od po 100 knjiga. U knjiaru dolaze kupci. Kupci
mogu: uzeti knjige s polica, vratiti knjige na police, konzultirati se s jednim radnikom koji radi u
prodaji, stati u red, izai iz reda i platiti knjige. Radnik moe savjetovati kupca i naplatiti knjige ako
radi u prodaji. Radnik u prodaji ili nabavi u svakom trenutku se moe konzultirati sa efom.. Obje
organizacijske jedinice knjiare imaju istu funkciju izracunajCijenuKnjige() koju implementiraju na
razliite naine i njihove razrede potrebno je definirati koristei zajedniko suelje. U dijagramu
oznaite meusobne ovisnosti i razrede koji se nasljeuju.
Zadatak 4.3. Veterinarska ambulanta
Dijagramom razreda modelirajte veterinarsku ambulantu. Veterinarska ambulanta Umiljato
stvorenje sastoji se od barem jedne ambulantne jedinice. Svakoj jedinici pripada barem jedan
lijenik. Lijenik moe biti dio samo jedne jedinice. U sluaju zatvaranja neke jedinice pripadajui
lijenici pridruuju se preostalim jedinicama. Ambulantom upravlja direktor. Svaku jedinicu vodi
jedan voditelj. Voditelj ne moe voditi druge jedinice osim svoje.
Lijenik, voditelj i direktor su zaposlenici. Zaposlenik ima atribute ID (tipa Integer, vidljivost
protected), Ime (String, public) i Prezime (String, public), i operaciju primiPlacu() vidljivosti public.
Direktor drugaije implementira operaciju primiPlacu() od ostalih zaposlenika. Direktor odreuje
bonus na plau voditelja, dok voditelj odreuje bonus lijenika. Zbog toga voditelj i direktor
52
implementiraju suelje IVoditelj s definicijom operacije odrediBonus() koja je vidljiva svim razredima.
Operacija odrediBonus() ima jedan ulazni argument tipa Integer i vraa vrijednost tipa Double.
Lijenik izvrava nula ili vie postupaka. Jedan postupak mora izvriti barem jedan lijenik. Postupci
ponekad mogu sadravati druge postupke. Postupak se vri ili izvodi nad ivotinjom. ivotinja ima
atribute Vrsta (String, public) i Masa (Integer, public). Sustav raspoznaje dvije vrste ivotinja: mala
ivotinja i velika ivotinja. Jedinica ima atribute ID (Integer, private) i Naziv (String, public). Postupak
ima atribut Opis (String, public).
U izradi dijagrama navedite nazive rola gdje je to potrebno, te oznaite vidljivosti svih atributa i
operacija pomou simbola. Dijagram izradite koristei najmanji potreban broj razreda i njihovih
meusobnih odnosa.
Zadatak 4.4. Tvrtka za popravak informatike opreme
U tvrtci za popravak informatike opreme zaposleno je vie servisera i jedan voditelj. Oni su
djelatnici tvrtke iji se podaci briu njezinim zatvaranjem. Svaki djelatnik ima svoje Ime (String,
public), Prezime (String, public) i OIB (String, private).
Voditelj otvara radne naloge, dok jedan serviser izvrava barem jedan radni nalog. Jednom radnom
nalogu pridruena je jedna stranka u ije ime je radni nalog otvoren. Svaka stranka posjeduje Ime
(String, public), Prezime (String, public) i Broj telefona (String, public). Ponekad se jedan radni nalog
sastoji od jednog ili vie dodatnih radnih naloga zbog sloenosti popravaka.
Status radnog naloga je javna varijabla s diskretnim vrijednostima: zaprimljen, u obradi,
zavren uspjeno i zavren neuspjeno. Svaki radni nalog sadrava barem jednu servisnu
akciju. Akcije se dijele na: dijagnostiku, podeavanje i ugradnju. Ugradnja sadrava barem jednu
raunalnu komponentu koja se ugrauje tijekom akcije. Svaka komponenta ima svoju cijenu (Double,
public). Svaki radni nalog obavlja se na informatikoj opremi koja se dijeli na: periferne jedinice,
stolna raunala i prijenosna raunala. Nakon otvaranja radnog naloga voditelj inicijalno procjenuje
trajanje radnog naloga i upisuje taj podatak u radni nalog.
Tvrtka omoguava korisnicima uvid u promjene radnih naloga putem Web aplikacije, stoga se
moe rei da Web aplikacija ovisi o radnom nalogu. Nakon to je radni nalog zavren, bilo uspjeno ili
neuspjeno, serviser zove stranku na telefon i informira je o promjeni statusa radnog naloga. Servisna
akcija posjeduje atribute UtroeniovjekSati (Double, protected) i CijenaovjekSata (Double,
protected). U radnom nalogu nalazi se javno dostupna operacija IzraunajCijenu() s izlaznom
vrijednosti tipa Double.
Nacrtajte dijagram razreda te navedite nazive uloga gdje je to potrebno, te oznaite vidljivosti svih
atributa i operacija pomou simbola.
53
5. Dijagrami objekata i paketa

5.1. Dijagrami objekata
5.1.1. Karakteristike objekata
Dijagrami objekata (engl. object diagrams) kao i dijagrami razreda pripadaju strukturnim UMLdijagramima, ali njihova uloga je razliita: dijagrami objekata prikazuju strukturu sustava u nekom
trenutku. Prikaz moe biti djelomian ili cjelovit, odnosno nije nuno prikazati objekte svih razreda
sustava. U proizvoljno odabranim trenucima objekti sustava imaju razliite vrijednosti atributa i
dijagrami objekata prikazuju upravo te vrijednosti, zajedno s objektima i njihovim meusobnim
vezama. Najee je dovoljno prikazati samo jedan trenutak u radu sustava, ali ponekad ako je stanje
sustava izrazito dinamino potrebno je izraditi vie dijagrama koji opisuju rad sustava u nekoliko
trenutaka s karakteristinim stanjima objekata.
5.1.2. Definiranje objekata
Simbol objekta je pravokutnik s dva pretinca jedan za naziv objekta i drugi za vrijednosti atributa.
Objekti se razlikuju od razreda jer nemaju definicije atributa i procedura, ali imaju jasno oznaeno
stanje vanih atributa. Prikazuju se atributi po kojima se pojedinci unutar dijagrama meusobno
razlikuju, odnosno po kojima su oni specifini.
Primjer 5.1.2.1. Objekti razreda Osoba
Razred Osoba ima sljedee atribute: jedinstvena ifra (Integer), ime (String), prezime (String) i OIB
(String). ifra je zatiene vidljivosti, a ime, prezime i OIB javno dostupni podaci. Izradite tri pojedinca
navedenog razreda s proizvoljnim vrijednostima atributa.
Rjeenje:
Prvo treba definirati razred Osoba. U tekstu zadatka zadan je naziv razreda i njegovi atributi, bez
operacija. Operacije razreda nisu bitne za objektni dijagram jer objekti nemaju operacije. Stoga, ak i
da su operacije zadane u tekstu zadatka, mogli bismo ih ignorirati. Atributi Ime, Prezime i OIB su
public, a ifra je protected. Prvi dio rjeenja prikazan je na slici 5.1.
Slika 5.1. Prvi dio rjeenja.

Pojedinci se meusobno razlikuju barem po vrijednosti jednog atributa. Dva pojedinca sa istim
atributima nisu mogua u istom dijagramu. U nazivu svakog pojedinca nalazi se njegovo jedinstveno
ime i razred kojemu pripada. Primjerice, Osoba1 : Osoba jer pojedinac imena Osoba1 koje je
jedinstveno u dijagramu i izveden je iz razreda Osoba. Unosimo vrijednosti atributa pojedinaca
razreda Osoba: (ifra, Ime i prezime, OIB) = { (1, Petar Kova, 123); (2, Luka Horvat, 456); (3, Ivan
Gali, 789). Vrijednosti su proizvoljno odabrane. Konano rjeenje primjera 5.1.2.1 prikazano je na
slici 5.2.
54

5.1.3. Veze izmeu objekata
Dijagrami objekata sastoje se od objekata i veza. Za pridruivanja objekata najee se koristi
dvosmjerna veza, a dozvoljeno je koritenje i kompozicije. Ako su dva razreda povezana
nasljeivanjem, veza izmeu njihovih objekata biti e dvosmjerna, a moe dodatno biti oznaena i s
oznakom parent koja se nalazi pokraj toke gdje veza dodiruje razred roditelj.
U izradu dijagrama objekata prvo odaberemo razrede ije objekte emo prikazati. Najee to su
najvaniji razredi za ispravno funkcioniranje sustava, odnosno oni razredi bez kojih sustav ne moe
ispuniti svoje temeljne funkcionalnosti. Nakon toga unosimo proizvoljne vrijednosti u objekte, ali
pazimo da one ispravno demonstriraju vrijednosti koje e atributi imati tijekom rada sustava. Na
kraju povezujemo objekte, oznaavamo veze gdje je to potrebno i zavravamo izradu dijagrama.
U pravilu se za neki sloeni sustav radi nekoliko dijagrama objekata koji uvijek odgovaraju
njegovim obrascima uporabe. Tijekom rada i uporabe sustava stvorit e se razliiti pojedinci ili e oni
imati razna stanja. Dijagrami objekata moraju prikazati stanje sustava za svaki obrazac uporabe
prethodno definiran u istoimenim dijagramima.
Primjer 5.1.3.1. Veze izmeu objekata
Neka organizacija ima vie odjela. Odjeli se mogu dodavati i brisati. Svaki odjel ima svoj naziv
(String). Odjeli se mogu sastojati od pododjela. Svakom odjelu moe pripadati zaposlenik. Zaposlenici
imaju ifru (Integer), ime i prezime (String) i naziv radnog mjesta (String). ifra je zatien podatak.
Nekim zaposlenicima mogu biti pridruene vlastite kontakt informacije.
Rjeenje:
itajui zadatak uoavamo etiri razreda: organizacija, odjel, osoba i kontakt informacije. Razred
Organizacija sadrava razred Odjel koji je u reflektivnoj vezi sam sa sobom. Jednom odjelu moe
pripadati od 0 do neogranieno mnogo drugih odjela. Osoba pripada samo jednom odjelu, te u
svakom odjelu mora raditi barem jedna osoba. Kontakt informacije povezane su s osobom. Prvi dio
rjeenja primjera 5.1.3.1 prikazan je na slici 5.3.
55
Slika 5.3. Prvi dio rjeenja primjera 5.1.3.1.

Postoji samo jedna organizacija i nekoliko odjela, stoga e se u rjeenju nalaziti samo jedan
pojedinac razreda Organizacija i tri pojedinca razreda Odjel dva pojedinca koji su neposredno
pridrueni organizaciji i jedan pojedinac koji je pridruen drugom odjelu. Jednom od odjela bit e
pridruen pojedinac zaposlenik osoba1. Veza pojedinca osoba1 s odjelom o3 je nazvana voditelj. To
je rola (uloga) pojedinca osoba1 u odjelu o3. Istom zaposleniku je pridruen anonimni pojedinac
kontakt podataka Time e se predstaviti sve zahtijevane karakteristike sustava. Konano rjeenje
primjera 5.1.3.1 prikazano je na slici 5.4.

Primjer 5.1.3.2. Nasljeivanje objekata
U bolnici rade zaposlenici. Medicinske sestre i lijenici su zdravstveno osoblje. Zdravstveno osoblje
i administracija su razliite vrste zaposlenika bolnice. Prikazati u objektnom dijagramu jednog
pojedinca razreda lijenik i administracija. Svaki zaposlenik ima ifru (integer) i ime i prezime (string).
56
ifra je zatieni podatak. Lijenik moe postaviti dijagnozu, dok medicinska sestra moe izmjeriti
temperaturu i tlak.
Rjeenje:
U primjeru bolnikog informacijskog sustava iz poglavlja o dijagramima razreda definirani su
razredi: zaposlenik, administracija, zdravstveno osoblje, lijenik i medicinska sestra, te njihovi
meusobni odnosi. Prvi dio rjeenja prikazan je na slici 5.5.
Slika 5.5. Prvi dio rjeenja primjera 5.1.3.2.

Pojedinca razreda koji nasljeuju druge razrede automatski nasljeuju sve atribute roditelja. Stoga
je za pojedince Lijenik i MedicinskaSestra potrebno definirati karakteristine vrijednosti koje su
definirane u razredima Zaposlenik i MedicinskoOsoblje. Pojedinci razreda Administracija nasljeuju
atribute razreda Zaposlenik. Konano rjeenje primjera 5.1.3.2.

Zadatak 5.1. Objektni dijagram autonomnog robota
Potrebno je modelirati dio raunalnog sustava autonomnog robota. Robot ima neko stanje r, npr.
stoji ili kree se. Robot sadri razred za interni prikaz okoline, tj. svijeta. Model svijeta ili okoline
sastoji se od nekoliko elemenata i povrina. Svaka povrina moe sadravati zidove i vrata. Zidovi i
vrata imaju svojstvo irina koje je izraeno u elementima slike (Integer). Svi elementi koji tvore
povrinu su meusobno ovisni.
57
5.2. Dijagrami paketa

5.2.1. Karakteristike paketa
Dijagrami paketa (engl. package diagram) prikazuju kako je sustav podijeljen u logine cjeline ili
skupove pokazujui ovisnost izmeu tih cjelina. Korisni su za uspostavu hijerarhijskog odnosa izmeu
razreda i njihovo grupiranje u smislene i funkcionalne cjeline. Dijagrami paketa takoer pripadaju
strukturnoj skupini UML-dijagrama i prikazuju vremenski statika svojstva sustava.
Paket (engl. package) je skup razliitih UML-objekata. U programskom kodu paketi se
interpretiraju kao struktura namespace u programskom jeziku C++ ili package u Javi, ali paketi mogu
sadravati druge pakete, objekte, razrede, komponente, pa ak i dijagrame. Pomou paketa mogue
je objediniti obrasce uporabe kako bi se strukturalno objasnila funkcija modeliranog sustava. U
vieslojnim sustavima paketi se mogu koristiti za grupiranje pojedinanih slojeva programske podrke
kako bi se mogao objasniti tok podataka izmeu razliitih slojeva.
Primjer 5.2.1.1. Dijagram paketa inteligentnog agenta
Definirajte zajedniki paket nekog inteligentnog agenta koji se sastoji od tri manja paketa: senzora,
rasuivaa i aktuatora.
Rjeenje primjera 5.2.1.1 prikazano je na slici 5.7.

5.2.2. Vidljivost i ugnijeenje paketa
Slino kao razredi, i paketi imaju mogunost definiranja vidljivosti objekata koje sadravaju.
Oznake imaju jednako znaenje: + public, - private, # protected. Javno vidljivi objekti (public) nazivaju
se eksporti paketa (engl. package exports), jer njih mogu koristiti objekti u drugim importirajuim
paketima.
U prikazu paketa moe se koristiti tekstualno ugnijeenje (engl. textual nesting) ili grafiko
ugnijeenje (engl. graphical nesting). To su dva razliita i jednako vrijedna pristupa oznaavanju
objekata unutar dijagrama.
Primjer 5.2.2.1. Ugnijeenje paketa
Klijent neke raspodijeljene aplikacije sastoji se od sljedeih formi ili prozora: forme za narudbu,
forme za praenje narudbe i forme za pregled izvrene narudbe. Forme za narudbu i praenje su
javno dostupne svim korisnicima aplikacije, dok formi za pregled izvrene narudbe moe pristupiti
samo administrator aplikacije. Prikazati sve komponente klijenta s tekstualnim i grafikim
ugnijeenjem.
58
Rjeenje:
Klijentska aplikacija ima tri forme koje imaju razliite vidljivosti. Forme za narudbu i praenje su
public, dok je forma za pregled izvrene narudbe private. Koristimo simbole + i za oznaavanje
razina vidljivosti komponenti public i private. U tekstualnom ugnijeenju prikazujemo komponente u
istom paketu jednu ispod druge, a u grafikom kao zasebne pakete unutar veeg paketa Klijent. Prvi
dio rjeenja (tekstualno ugnijeenje paketa) prikazan je na slici 5.8, a drugi dio rjeenja (grafiko
ugnijeenje paketa) prikazan je na slici 5.9.
Slika 5.8. Prvi dio rjeenja (tekstualno ugnijeenje paketa).
Slika 5.9. Drugi dio rjeenja (grafiko ugnijeenje paketa).
5.2.3. Veze paketa

Paketi mogu biti povezani s tri vrste veza: importiranje (engl. import stereotype), nasljeivanje
(engl. inheritance) i ovisnost (engl. dependency). Importiranje se oznaava vlastitim stereotipom
<<import>>. Importiranje je usmjerena veza i omoguuje jednom razredu da vidi objekte drugog.
Primjer 5.2.3.1. Importiranje i eksportiranje paketa
Raspodijeljena aplikacija iz prethodnog primjera proirena je s paketima Posluiva, Pravila i GUI.
Server ima objekte BazaPodataka i ServisBiljeenja (engl. LoggingService). Svi su javno dostupni.
Paket Pravila ima javno dostupni objekt PravilaNarudba i zatieni objekt Prozor iz paketa GUI. Paket
GUI sadrava objekte Prozor, Forma i zatieni ObraivaDogaaja (engl. EventHandler).
Rjeenje:
Paket GUI eksportira dva razreda: Prozor i Forma. ObraivaDogaaja nije eksportiran jer je
oznaen kao zatien dio paketa. Objekti koje paket eksportira vidljivi su samo onom paketu koji ga
importira. U ovom primjeru Pravila eksplicitno importira paket GUI. Pa su tako GUI: Prozor i GUI:Form
vidljivi sadraju paketa Pravila. Ali GUI:ObraivaDogaaja nije vidljiv jer je zatien (protected).
Posluitelj ne importira paket GUI, te stoga sadraji tog paketa nemaju pravo pristupa nijednom
objektu iz paketa GUI. Isto tako, objekti iz paketa GUI ne mogu pristupiti sadraju paketa Posluitelj.
Zavisnosti importiranja i pristupa nisu tranzitivne. U ovom primjeru Klijent importira Pravila i Pravila
importiraju GUI, ali Klijent ne importira GUI i ne moe pristupiti njegovim objektima. Zato sadraj
paketa Klijent nema pravo pristupa eksportima paketa GUI, ali ima pristup eksportima paketa Pravila.
59
Da bi Klijent dobio pristup morao bi biti neposredno ili eksplicitno povezan s GUI. Rjeenje primjera
5.2.3.1 prikazano je na slici 5.10.
Primjer 5.2.3.2. Nasljeivanje paketa

U raspodijeljenoj aplikaciji iz prethodnog primjera potrebno je napraviti odvojena suelja za
operacijske sustave Windows i MacOS, ali nuno je maksimalno iskoristiti postojei paket GUI.
Rjeenje:
Nasljeivanje izmeu paketa je vrlo slino nasljeivanju izmeu razreda. Na sljedeoj slici prikazan
je paket WindowsGUI i MacOSGUI koji nasljeuju zajedniku strukturu iz generikog paketa GUI koji
eksportira dva razreda (Prozor i Forma) i ima jednu zatieni razred (ObraivaDogaaja). Dva
specijalizirana paketa (WindowsGUI i MacOSGUI) nasljeuju javne i zatiene elemente od
openitijeg paketa (GUI). Isto kao i kod nasljeivanja razreda, paketi mogu zamijeniti elemente
openitog razreda sa svojima. Na taj nain WindowsGUI nasljeuje iz GUI i ukljuuje razrede
GUI::Prozor i GUI::ObraivaDogaaja, nadjaava (engl. override) razred Forma i dodatno definira
vlastiti novi razred C#NETForma. Rjeenje primjera 5.2.3.2 prikazano je na slici 5.11.

Primjer 5.2.3.3. Ovisnost izmeu paketa
Dvoslojni informatiki sustav sastoji se od komponenti Klijent i Posluitelj. One su meusobno
ovisne, jer izvravanje posluiteljskih funkcija utjeu na izgled i ponaanje klijenta, dok akcije
korisnika upravljaju ponaanjem posluitelja.
60
Rjeenje:
Dijagram paketa u ovom primjeru je vrlo jednostavan. Klijent i Posluitelj su meusobno ovisni, a
veza ovisnosti je jednosmjerna i usmjerena. Stoga je potrebno spojiti Klijent i Posluitelj s dvije veze
ovisnosti - jedna je usmjerena od Posluitelja prema Klijentu, a druga obrnuto. Rjeenje primjera
5.2.3.3 prikazano je na slici 5.12.
5.2.4. Stereotipovi paketa

Stereotipovi su uobiajen nain proirenja UML-a. U dijagramima paketa, stereotipovi se koriste za
preciznije definiranje vrste ili tipa paketa. Stereotipovi nemaju posebne simbole, ve se u postojeu
oznaku paketa ispod njegovog naziva umee oznaka stereotipa. Koritenje stereotipova podataka nije
nuno.
U dijagramima paketa mogu se koristiti sljedei stereotipovi:
1. facade
Paket definira samo pogled (engl. view) na neki drugi paket
2. framework Paket se sastoji veinom od programskih okvira i obrazaca
3. stub
Paket je samo posrednik (engl. proxy) za javno dostupne komponente
drugih paketa
4. subsystem Paket predstavlja nezavisni dio cijelog sustava koji se modelira
5. system
Paket predstavlja cijeli sustav koji se modelira
Primjer 5.2.4.1. Sistemska komponenta ekspertnog sustava
Rasuiva je najvanija sistemska komponenta nekog ekspertnog sustava. Druga neophodna
komponenta je grafiko korisniko suelje. Prikazati sve komponente u paketnom dijagramu.
Rjeenje primjera 5.2.4.1 prikazano je na slici 5.13.
61

Zadatak 5.2. Sustav kunog alarma ima dva paketa. Paket Senzor generira poruke koje slua paket
Nadzornik. Paket Nadzornik sastoji se od tri razreda: Upravljanje, Podaci i Suelje. Izraditi dijagram
paketa sustava koristei grafiko ugnijeenje.
Zadatak 5.3. Najvaniji paketi raunalnog sustava za prodaju preko Interneta su Narudbe i Kupci
koji pripadaju veem paketu Prodaja. Razredi u Kupci ovise o paketu Narudbe. Time cijeli paket
Prodaja generira poruke koje slua abstraktni paket SueljeBazePodataka. Ovaj paket obuhvaa
specijalizirane pakete za pristup pojedinanim bazama podataka: SueljeOracle i SueljeMSSQL. Cijela
aplikacija je izraena u Javi i za implementaciju korisnikog suelja koriten je AWT Toolkit. Najvaniji
dijelovi korisnikog suelja su razredi u paketima NarudbeUlaz i ObavijestiUlaz. Paket
AplikacijaNarudbe alje poruke u paket Prodaja, a dobiva poruke iz NarudbeUlaz. Na slian nain
operacije u AplikacijaObavijesti pozivaju se temeljem akcije korisnika u ObavijestiUlaz i nakon obrade
prosljeuju direktno u paket Kupci. U svim paketima koriste se globalne operacije i konstante koje su
definirane u razredima Koliina, Novac i RasponPodataka. Ovi razredi nalaze se u istom paketu
Openito. Modelirati opisani dijagram paketa.
62
6. Dijagrami stanja i aktivnosti

Dijagrami stanja (engl. statechart, UML state machine diagram) i aktivnosti (engl. activity diagram)
pripadaju ponaajnim dijagramima (engl. behavioral diagram) u UML-u, zajedno s dijagramom
obrazaca uporabe. Za razliku od dijagrama obrazaca uporabe, dijagrami stanja i aktivnosti prikazuju
funkcionalnost softverskog sustava iz perspektive unutranjosti sustava. Pritom ovi dijagrami ne
prikazuju niti aktore niti vanjsko suelje prema krajnjim korisnicima. Budui da razrauju ponaanje
sustava u smislu aktivnosti i prijelaza izmeu stanja, svrstavaju se u dinamike dijagrame.
Iako slini, ove dvije vrste dijagrama imaju i odreene razlike koje se mogu uoiti. Prva razlika
odnosi se na njihovu svrhu. Dijagram stanja slui za opis diskretnih stanja sustava i prijelaza izmeu
tih stanja. Teite mu je na unutarnjem djelovanju dijelova sustava i esto prikazuje prijelaze izmeu
stanja u sustavu koji su poticani dogaajima. Dijagram aktivnosti prikazuje radni tok (ili kontrolni tok)
aktivnosti koje se obavljaju u sustavu korak po korak. Stoga je kod dijagrama aktivnosti naglasak na
jednostavnosti i poslovnim operacijama koje se uvijek odvijaju slijedno, jedna za drugom.
Druga razlika je u tome to dijagrami stanja na prijelazima izmeu stanja sadre naziv dogaaja koji
je aktivirao prijelaz i esto poziv izlazne metode ili operacije koja se dogaa, dok kod dijagrama
aktivnosti to nije sluaj.
6.2. Dijagram stanja

6.2.1. Elementi dijagrama
Dijagram stanja sastoji se od sljedeih (najeih) gradivnih elemenata:
1. Poetno stanje i konano stanje. Poetno stanje oznaeno je crnim krugom, a konano stanje
oznaeno je zaokruenim crnim krugom, slika 6.1. Dijagram stanja moe imati jedno poetno i vie
konanih stanja.
Slika 6.1. Oznake poetnog i konanog stanja, prikazanih zajedno s prijelazima.

2. Stanje, oznaeno zaobljenim pravokutnikom. Pritom gornji dio pravokutnika sadri naziv stanja, a
doljnji dio, odvojen horizontalnom crtom, sadri aktivnosti koje se dogaaju u tom stanju, slika
6.2. Stanje ne mora sadravati donji dio, ono mora sadravati samo naziv. Uobiajene oznake za
trenutke kada se aktivnosti odvijaju su: pri ulasku u stanje (engl. entry) pri izlasku iz stanja (engl.
exit) i nedefinirani trenutak izvoenja (engl. do).
Slika 6.2. Oznaka stanja.
63
3. Prijelaz izmeu stanja, oznaen strelicom. Opi oblik prijelaza izmeu stanja prikazan je na slici
6.3. Prijelaz izmeu stanja moe sadravati:
3.1. Dogaaj (engl. event) koji je izazvao prijelaz (ako takav postoji, inae se prijelaz uvijek
dogaa), prikazan svojim nazivom (engl. eventName).
3.2. Ogranienje ili izraz koje treba zadovoljiti dogaaj da bi se prijelaz ostvario (engl.
guardExpression), prikazan u uglatim zagradama.
3.3. Akciju koja se dogaa prilikom prijelaza ukoliko je ogranienje zadovoljeno. Akcija moe biti
bilo koje vrste, npr. poziv vanjske procedure, pridruivanje vrijednosti varijabli, itd. Akcija je
od dogaaja odvojena znakom "/".
3.4. Tip dogaaja (engl. type). Dogaaji imaju najee predefinirane tipove kao to su: poziv
(engl. call), signal (engl. signal), promjena (engl. change), vrijeme (engl. time).
Sve komponente prijelaza mogu se izostaviti. Opi oblik prijelaza izmeu stanja prikazan je na slici
6.3.
Slika 6.3. Opi oblik prijelaza izmeu stanja.

4. Odluka ili uvjetno grananje (engl. decision), prikazana bijelim, dijamantnim oblikom, slika 6.4. Uz
odluku, mogue je i spajanje (engl. merge), koje se prikazuje s istim bijelim dijamantnim oblikom,
samo s dvije strelice koje idu u vor, a jednom koja izlazi.
Slika 6.4. Oznaka odluke.

5. Ravanje i skupljanje (engl. fork and join) koje se najee koristi pri paralelnom odvijanju nekih
aktivnosti. Pritom se dijagram stanja rava od nekog stanja u niz drugih stanja da bi se nakon
prolaska kroz ta paralelna stanja ponovno skupio, slika 6.5. Sastanak (engl. rendezvous) ima vie
prijelaza koji ulaze i izlaze. Jednom kad su svi ulazni prijelazi aktivirani pokreu se svi izlazni
prijelazi, svaki u zasebnoj dretvi [Lethbridge 2005].
Stanje2
Stanje3
Stanje1
Stanje4
Slika 6.5. Oznaka ravanja i skupljanja.

6. Sloeno stanje, koje se sastoji od hijerarhije stanja i prijelaza, prikazano zaobljenim
pravokutnikom unutar ega se nalazi novi dijagram stanja. Budui da veina alata za crtanje UML-
64
dijagrama ima problema s prikazom takvih sloenih stanja, uobiajeno je hijerarhiju stanja crtati
odvojeno, kao na slici 6.6.
Sloeno stanje 1, postupak pozovi():
Slika 6.6. Primjer hijerarhije stanja.

Zadatak 6.1. Izmjena podataka u eliji
Modelirati dijagramom stanja izmjenu podataka u eliji unutar tablice tablinog kalkulatora. Unos
poinje klikom mia ili pozicioniranjem putem tipkovnice, prilikom ega se na ekranu podeblja elija u
tablici i omogui upis teksta. Pretpostavite da unos teksta traje dok se pritie bilo koji znak osim
znakova "Enter", "Tab" ili "Esc". Prilikom unosa, pritisnuti znak se ispisuje na ekran, ali ne brie se
dosadanji sadraj elije.
U sluaju uspjenog zavretka unosa (znakovi "Enter" ili "Tab"), dolazi do izmjene podataka u eliji.
Najprije se dosadanji sadraj elije brie iz memorije. Potom se trenutni podatak pohrani u
memoriju i ispie u eliju. U sluaju obustave unosa (znak "Esc"), podatak u eliji ostaje netaknut. U
svakom sluaju nakon zavretka unosa elija se defokusira, odnosno postaje normalne debljine.
Zadatak 6.2. Paralelizacija izvoenja procesa
Upotrebom dijagrama stanja potrebno je modelirati paralelizaciju poslova pri ulasku u procesor
koji sadri dvije jezgre. Poslovi se nalaze u prirunoj memoriji. Pretpostavite da svaki posao ima
zabiljeenu koliinu prirune memorije koju je zauzeo i priblinu koliinu vremena potrebnu za
izvoenje. Pretpostavite da jedna jezgra izvodi samo jedan posao u nekom trenutku. Ako su obje
jezgre pune, posao ostaje u prirunoj memoriji.
Posao e se nalaziti u prirunoj memoriji sve dok se neka jezgra ne oslobodi. Zatim posao prelazi u
stanje razmatranja. U tom stanju, onaj posao koji zauzima najvie prirune memorije bit e odabran
za izvravanje. Svi ostali poslovi e se vratiti u prethodno stanje. Svaki posao pri izvravanju u
procesoru mora proi kroz tri stanja: 1) predobradu, u kojoj se posao optimira, 2) izvoenje, na kraju
ega se rezultati zapisuju u priuvnu memoriju, i 3) brisanje, pri emu se brie stanje u jezgri koja je
posao izvravala i postavlja se signalna zastavica da je jezgra prazna.
65
6.3. Dijagram aktivnosti

6.3.1. Elementi dijagrama
Dijagram aktivnosti sastoji se od sljedeih temeljnih elemenata:
1. Poetnog i konanog stanja, koje se obiljeava jednako kao i kod dijagrama stanja.
2. Aktivnosti, koja se obiljeava zaobljenim pravokutnikom, jednako kao i stanje kod dijagrama
stanja. Jedina razlika je u tome to se unutar neke aktivnosti odvija samo ta aktivnost - nema
vie aktivnosti unutar nekog stanja kao to je to mogue kod hijerarhije stanja.
3. Prijelaz izmeu aktivnosti, oznaen strelicom. Jedine dvije komponente prijelaza koje su
dozvoljene kod dijagrama aktivnosti su naziv prijelaza i ogranienje.
4. Odluka ili uvjetno grananje, oznaena bijelim, dijamantnim oblikom isto kao i kod dijagrama
stanja.
5. Ravanje i skupljanje, koje se oznaava isto kao i kod dijagrama stanja.
6. Signal (dogaaj). Signali se koriste na dijagramu aktivnosti da bi nadomjestili postojanje
dogaaja kod dijagrama stanja. Postoje tri tipa signala: 1) aljui signal (engl. sending signal ili
generating signal), 2) Primajui signal (engl. receiving signal ili accepting signal) i vremenski
signal (engl. timer signal). Sva tri primjera signala prikazana su na primjeru na slici 6.7.
Slika 6.7. Signali kao elementi dijagrama aktivnosti.

7. Plivake staze (engl. swimlanes), kod kojih su aktivnosti rasporeene u vertikalne i/ili
horizontalne particije koje su razgraniene linijama. Same particije ne donose dodatnu
semantiku u dijagram osim organizacijske, kada se eli istaknuti koji od dijelova sustava to
izvodi [Fowler 2004]. Primjer plivakih staza prikazan je na slici 6.8. Aktivnost 1 izvodi se u okviru
particije broj 1. Zatim se druga i trea aktivnost izvode u okviru particije 3, da bi aktivnost 4 bila
posljednja unutar particije 2.
66
Slika 6.8. Plivake staze.
6.3.2. Rijeeni primjer

Primjer 6.3.2.1.
Modelirajte dijagramom aktivnosti izgradnju kue. Najprije radnici postavljaju temelje kue. Zatim
u paraleli radnici grade okvir (katovi i nosivi zidovi) dok elektriar postavlja elektrine instalacije u
temeljima. Nakon toga, elektriar postavlja elektrine instalacije u nosivim zidovima. Dok jedni
radnici postavljaju krov, drugi grade pregradne zidove. Nakon toga elektriar postavlja ostale
elektrine instalacije kroz cijelu kuu. Zatim radnici provode vanjsko i unutarnje bukanje. Na kraju
radnici postavljaju vrata i prozore. Inspekcija po zavretku pregledava stanje kue.
Rjeenje:
Podijelit e se aktivnosti u tri plivake staze. Jedna je za radnike, druga za elektriara, a trea za
inspekciju. Prva aktivnost koju radnici provode je postavljanje temelja kue, slika 6.9.
Slika 6.9. Poetak dijagrama aktivnosti iz primjera 6.3.2.1.
67
Nakon toga radnici i elektriar rade u paraleli na postavljanju okvira i elektrinim instalacijama u
temeljima. Ovdje se koristi ravanje i skupljanje, slika 6.10.
Slika 6.10. Nastavak dijagrama aktivnosti iz primjera 6.3.2.1.

Zatim neko vrijeme elektriar sam radi svoj posao postavljanjem elektrike u nosivim zidovima. Nakon
toga radnici rade u paraleli i postavljaju krov i pregradne zidove, da bi potom elektriar provukao
ostale instalacije kroz cijelu kuu, slika 6.11.
Slika 6.11. Nastavak dijagrama aktivnosti iz primjera 6.3.2.1.

68
Potom radnici provedu vanjsko i unutarnje bukanje i postavljanje vrata i prozore. Na kraju inspekcija
to sve pregleda i time je dijagram zavren, slika 6.12.
Slika 6.11. Zavretak dijagrama aktivnosti iz primjera 6.3.2.1.

Zadatak 6.3. Kuhanje kave
Modelirajte postupak kuhanja kave u nekom poduzeu dijagramom aktivnosti. Pretpostavite da u
dotinom poduzeu tajnica svako jutra kuha efu kavu. Slijed aktivnosti je sljedei. Po dolasku, ef
pozdravi tajnicu i zamoli ju za kavu. Nadalje, ef sjedne i ita pristiglu potu. Za to vrijeme, tajnica
najprije provjeri ima li dovoljno kave i eera u uredu. Ako ima dovoljno kave i eera, tada stavi vodu
da zakuha. U sluaju da nema dovoljno kave ili eera, tajnica ode do slube nabave poduzea. Ako
sluba nabave ima kavu ili eer, tada joj to daju i ona se vrati nazad u ured i zakuha vodu za kavu. U
sluaju da sluba nabave nema kavu ili eer, tada oni narue da im se ista to prije dostavi. Budui
da tajnica zna da ef ne moe bez jutarnje kave, ona ostaje kod slube nabave sve dok ne dobije kavu.
im kavu dobije, tajnica se vraa nazad u ured i zakuha kavu. Ako u meuvremenu proe vie od 45
69
minuta otkako je ef naruio kavu, ef prestaje itati potu i izlazi ljutit iz ureda. Tajnica u svakom
sluaju im ima kavu i eer i kad voda zakuha pripremi kavu, ak i u sluaju da je ef ve izaao. Ako
je ef jo tamo, ef pije kavu.
Zadatak 6.4. Pohaanje vjetine Osnove programskog jezika Java
Modelirajte pohaanje vjetine Osnove programskog jezika Java dijagramom aktivnosti. Student
eli upisati i proi teaj Jave. Prvi korak je proi prijemni test. Prijemni test ocjenjuje predava. U
sluaju da je student uspio proi prijemni test, student dolazi na sat Jave. Satovi Jave oblikovani su na
nain da najprije predava pria, a studenti ga sluaju. Na kraju sata predava daje studentima
domau zadau. Student tijekom sljedeeg tjedna napie domau zadau i preda ju predavau. Zatim
u paraleli predava ocjenjuje domau zadau, a student razmilja je li dovoljno dobro napisao
domau zadau za prolaz (grize nokte).
Predava donosi odluku o tome je li zadaa bila dovoljno dobra. Ako je zadovoljio na domaoj
zadai, postupak se ponavlja i student ponovno dolazi na sat Jave. Ako je student na taj nain uspio
zadovoljiti na 10 domaih zadaa, tada je proao vjetinu. U svakom drugom sluaju, smatra se da je
student odustao. Napomena: ovaj zadatak je pojednostavljen, u stvarnosti student ima pravo izostati
s najvie jednog predavanja i ne napisati najvie jednu zadau, bez obzira na opravdanja.
70
7. Dijagrami komponenti
Dijagrami komponenti prikazuju komponente (strukturne cjeline) sustava i njihove meusobne
odnose [Fowler 2000]. Komponenta je zasebna cjelina programske potpore s vlastitim sueljem.
Komponenta predstavlja fiziku i stvarnu implementaciju logikih elemenata sustava kao to su
razredi, suelja i pridruivanja [Booch 1999]. Komponentni dijagrami pomau u modeliranju fizikih
cjelina sustava kao to su izvrne datoteke, programske biblioteke, tablice, datoteke i svi drugi
dokumenti. esto se kae da su u UML-u sve fizike stvari modelirane kao komponente [Booch
1999].
U izradi programske podrke mnogi operacijski sustavi i raunalni jezici podravaju koncept
komponente: objektne biblioteke, izvrne datoteke, DCOM i COM+ komponente i Enterprise Java
Beans su primjeri komponenata koje se mogu direktno predstaviti u UML-u koritenjem komponenti
[Booch 1999]. Jedan razred moe biti predstavljen s vie komponenata, ali samo s jednim paketom.
Na primjer, razred Java String je smjeten u paket java.lang, ali istodobno sastoji se od mnogo
komponenata [Fowler 2000].
Dijagrami komponenti su strukturni UML-dijagrami. Prikazuju vremenski nepromjenjiva (statika)
svojstva sustava s fizikog aspekta implementacije. Stoga se uz dijagrame razmjetaja jo nazivaju
fiziki dijagrami te se esto prikazuju zajedno u jednom UML-dijagramu komponenti i razmjetaja.
Primjer 7.1.1. Sistemska DLL datoteka
Prikazati sistemsku datoteku 'gdi32.dll' operacijskog sustava Windows. Datoteka eksportira
Graphics Device Interface (GDI) programsko suelje. Zanemariti ostala suelja komponente.
Rjeenje primjera 7.1.1 prikazano jer na slici 7.1.
7.2. Svojstva komponenti

Svaka komponenta mora imati vlastito ime koje je razlikuje od ostalih komponenti u dijagramu
[Booch 1999]. Jednostavan naziv (engl. simple name) je niz znakova. Naziv puta (engl. path name) je
ime komponente s prefiksom imena paketa kojemu komponenta pripada. Jednostavne komponente
(engl. simple components) imaju jednostavne nazive, a proirene komponente (engl. extended
components) naziv puta ispred jednostavnog imena. U praksi, jednostavni nazivi komponenata
ukljuuju i ekstenziju njihovih datoteka (npr. .java ili .dll).
Znaajne razlike izmeu komponente i razreda su:
71
1. Razredi predstavljaju logiku apstrakciju sustava, dok su komponente fiziki (stvarni i

opipljivi) artefakti.
2. Komponente i razredi pripadaju razliitim pogledima na sustav s drugaijim razinama
apstrakcije.
3. Razredi imaju vlastite atribute i operacije koje mogu neposredno izvravati. Komponente
imaju pristup samo onim operacijama koje se mogu dosegnuti kroz suelja.
Primjer 7.2.1. Jednostavne i proirene komponente
Neki informatiki sustav za detekciju neeljene pote (engl. spam) sadrava komponente
'agent.exe, 'spamagent.dll' i 'agentdialog.dll'. Datoteka 'spamagent.dll' realizira razrede SpamAgent,
SpamPolicy i SpamPatternSearch. Datoteka 'agentdialog.dll' nalazi se u paketu system i u dijagramu
je prikazana inaica datoteke 9.2.3.34. Potrebno je prikazati komponente 'agent.exe' i 'spamagent.dll'
s jednostavnim nazivom, i 'agentdialog.dll' s proirenim.

Primjer 7.2.2. Komponente i razredi
U sustavu iz prethodnog primjera kljuna DLL-datoteka 'spamagent.dll' sastoji se od tri razreda:
SpamAgent, SpamPolicy i SpamPatternSearch. DLL-datoteku implementiraju dodatni razredi, ali oni
su manje vani za njezinu funkcionalnost te ih stoga nije potrebno prikazati u dijagramu.
72
7.3. Suelja komponenti

Suelje je kolekcija operacija za specificiranje usluge razreda ili komponente. Veza izmeu
komponenti i suelja je vrlo vana. Svi moderni operacijski sustavi koji podravaju komponente kao
to su COM+, CORBA, Enterprise Java Beans koriste suelja za povezivanje komponenata. Suelja su
ljepilo ili poveznica izmeu odvojenih komponenata unutar istog ili izmeu razliitih paketa i
vorova [Booch 1999]. Drugim rijeima, suelja premouju logike i fizike granice unutar sustava.
Suelje koje neka komponenta realizira je usluga za druge komponente i naziva se eksportirano
suelje (engl. export interface). Jedna komponenta moe realizirati vie suelja. Suelje koje neka
komponenta koristi naziva se importirano suelje (engl. import interface). Komponenta moe koristiti
neogranieni broj importiranih suelja.
Kod dijagrama komponenti u sluaju norme UML 1.x suelja mogu biti prikazana na dva naina:
1. Ikonizirani oblik (engl. iconic form). Najei nain prikaza suelja. Komponenta koja realizira
suelje povezana je sa sueljem s izostavljenom vezom realizacije (engl. elided realization
relationship).
2. Proireni oblik (engl. expanded form). Prikaz suelja pomou veze realizacije. Izgled ove veza
identian je vezi realizacije u dijagramima razreda, vidjeti poglavlje 4.14. Komponenta koja
realizira suelje povezana je sa sueljem pomou veze realizacije tako da strelica dodiruje
simbol suelja iz dijagrama razreda, a drugi dio veze dodiruje komponentu. U ovom obliku
atributi i operacije suelja moraju biti prikazani u dijagramu, dok u ikoniziranom obliku ne
moraju.
U oba sluaja komponenta koja importira suelje povezana je s njim pomou veze zavisnosti.
Primjer 7.3.1. Suelje razreda ImageObserver
Neki sustav sastoji se od komponente 'slika.java' i 'element.java'. Komponenta 'element.java' ima
suelje MotriteljSlika (engl. ImageObserver) s tri operacije prekini(), greska() i osvjeziSliku(). Prve dvije
operacije vraaju cjelobrojnu (Integer) vrijednost, a trea operacija Boolean. Prikazati sustav pomou
ikoniziranog i proirenog oblika dijagrama suelja.
Prvi dio rjeenja primjera 7.3.1 (ikonizirani oblik) prikazan je na slici 7.4, a drugi dio rjeenja
(proireni oblik) prikazan je na slici 7.5.
Slika 7.4. Prvi dio rjeenja primjera 7.3.1 (ikonizirani oblik).
Slika 7.5. Drugi dio rjeenja primjera 7.3.1 (proireni oblik).

73
7.4. Vrste komponenti

UML definira tri vrste komponenti:
1. Komponente razmjetaja (engl. deployment components) su nune i dovoljne za rad neke
raunalne aplikacije ili sustava, kao to su dinamiki povezane biblioteke (engl. dynamic
linked libraries, DLL) i izvrne datoteke (engl. executables, EXE). UML-definicija komponente
razmjetaja ukljuuje i irok raspon drugih objekata poput COM+, CORBA, Enterprise Java
Bean, dinamikih mrenih stranica, tablica baza podataka i drugih izvrnih datoteka.
2. Komponente radnog proizvoda (engl. work product component) su datoteke nastale tijekom
razvojnog procesa poput datoteka izvornog koda (engl. source code files), datoteka s
podacima (engl. data files), itd. Komponente radnog proizvoda koriste se za stvaranje drugih
komponenti.
3. Komponente izvoenja (engl. execution components) nastaju kao posljedica izvoenja i rada
sustava. Primjerice, COM+ objekt je takva komponenta jer nastaje izvoenjem pripadne DLLdatoteke.
Komponente se organiziraju i grupiraju u pakete slino kao to se organiziraju razredi. U UML 1.x
komponente se mogu organizirati i pomou veze ovisnosti. Druge vrste pridruivanja (generalizacija,
agregacija, proirenja dvosmjernih vezama prototipovima,) dozvoljene su samo u kasnijim
verzijama UML-a [Booch 1999].
7.5. Stereotipovi komponenti

Dijagrami komponenti definiraju pet standardnih stereotipova za komponente:
1.
2.
3.
4.
5.
executable
library
table
file
document
Komponenta moe biti izvrena u voru (engl. node)

Komponenta je statiki ili dinamiki objekt biblioteke
Komponenta je tablica baze podataka
Komponenta je dokument s izvornim kodom ili podacima
Komponenta je dokument opeg znaenja ili sadraja
UML ne definira specifine ikone za stereotipove, ali potie se koritenje u praksi standardiziranih
slikovnih simbola za izvrne datoteke, DLL datoteke, tablice baze podataka, itd.
Primjer 7.5.1. Modeliranje sveuilinog informacijskog sustava
Vieslojni sveuilini informacijski sustav sastoji se od tri velika podsustava:
UpravljanjeSeminarima, UpravljanjeStudentima i Sigurnost, koji su u modelu ekvivalentni izvrnim
datotekama. U najviem sloju sustava nalaze se komponente UpravljanjeSeminarima i
UpravljanjeStudentima, u drugom sloju Student, Seminar i Raspored, te u treem Sigurnost i
Upravljanje. U drugom sloju komponenta Student ima suelja IDB i IStudent, komponenta Seminar
suelja IDB i ISeminar, te komponenta Raspored suelja IDB i IRaspored. U treem sloju komponenta
Sigurnost ima suelja ISifra i IPristup, a komponenta Upravljanje suelje IUpravljanje. Komponenta
UpravljanjeSeminarima importira suelja IRaspored i ISeminar, dok UpravljanjeStudentima importira
74
ista suelja i dodatno IStudent. Komponente Student, Seminar i Raspored koriste suelja IPristup i
IUpravljanje. Komponenta Upravljanje pristupa bazi podataka koristei radni okvir ADO.NET. Prikazati
pripadni dijagram komponenti. Rjeenje primjera 7.5.1 prikazano je na slici 7.6.
Rjeenje:
Primjer 7.5.2. Modeliranje tablica, datoteka i dokumenata

Nakon instalacije, Windows aplikacija za raunalnu animaciju Animator sastoji se od izvrne
datoteke 'animator.exe' koja koristi DLL datoteke 'prozor.dll', 'model.dll', 'crtaj.dll' i 'prikazi.dll'.
Konfiguracija aplikacije nalazi se u formatiranoj datoteci 'animator.ini', a sustav pomoi u binarnoj
datoteci 'animator.hlp'. Izvrna datoteka 'animator.exe' je u inaici 3.1.4. Biblioteka 'model.dll'
pohranjuje podatke u tablicu baze podataka pod nazivom 'Oblik', koja se sastoji od datoteke
'oblik.tbl'. Biblioteka 'crtaj.dll' realizira 'prikazi.dll'. Prikaite navedene komponente u dijagramu.
Rjeenje:
Koristit e se stereotipovi komponenti i standardni simboli za prikaz svih navedenih datoteka.
Jedina veza u dijagramu je ovisnost. Rjeenje primjera 7.5.2 prikazano je na slici 7.7.
75

Zbog jasnoe dijagrama esto se koriste normirane ikone umjesto simbola UML-komponenti. Ako
je dijagram sloen, s puno komponenti i veza, upotreba ikona pridonosi jednostavnijem i brem
razumijevanju dijagrama, pogotovo kod osoba koje nisu strune u UML-u. Mogue rjeenje primjera
7.5.2 koritenjem normiranih ikona prikazano je na slici 7.8.
Slika 7.8. Mogue rjeenje primjera 7.5.2 koritenjem normiranih ikona.
76

Zadatak 7.1.
Neki projekt raunalne grafike u programskom jeziku C++ sastoji se od nekoliko datoteka izvornog
koda i zaglavlja: 'crtaj.h' (inaica 1.9), 'crtaj.cpp' (inaica 2.6.9), 'jezgra.h' (inaica 1.8), 'polinom.h'
(inaica 4.5) i 'boja.h' (inaica 7.3). Datoteka 'crtaj.h' ovisi o svim ostalim datotekama. Prikazati
pripadni dijagram komponenti.
Zadatak 7.2.
Aplikacija za animaciju ima vlastiti API - radni okvir koji definira etiri suelja: ISkripte, ICrtanje,
IModeli i IAplikacija. Izvrna datoteka aplikacije je 'animator.exe' u inaici 9.2.8. Prikazati dijagram
komponenti.
77
8. Dijagrami razmjetaja
Dijagrami razmjetaja (engl. deployment diagrams) opisuju topologiju sklopovlja i programsku
potporu koja se koristi u implementaciji sustava u njegovom radnom i produkcijskom okruenju.
Drugim rijeima, dijagrami razmjetaja prikazuju raunalne resurse koji su neophodni za ispravno
funkcioniranje sustava i njihove meusobne odnose: stvarne ureaje (posluitelje, radne stanice,
korisnika raunala, itd.), komponente programske podrke koje se na njima izvravaju i veze izmeu
prikazanih resursa. Dijagrami razmjetaja, kao i dijagrami paketa i razreda, su statiki i strukturni
UML-dijagrami.
Primjer 8.1.1. Mreni posluitelj s komponentom
Prikaite u dijagramu razmjetaja mreni posluitelj s komponentom za slanje elektronike pote.
8.2. Elementi dijagrama

Po specifikaciji UML 1.1 dijagrami razmjetaja sastoje se od vorova (engl. nodes), komponenti
(engl. components) i njihovih meusobnih veza.
Izmeu vorova i komponenti postoje dvije velike razlike:
1. Komponente sudjeluju u izvravanju sustava, a vorovi izvravaju komponente. vorovi su
raunalni resursi koji omoguuju pokretanje i izvravanje komponenti.
2. vorovi predstavljaju fiziki aspekt sustava, a komponente logiki.
vorovi predstavljaju sklopovlje sustava kao to su razni posluitelji, dok su komponente izvrne
datoteke, stolne, mobilne i mrene aplikacije koje ine opisani sustav. Jedan vor moe simbolizirati
vie raunala kao to je grozd posluitelja. vorovi su predstavljeni u obliku kocki, a komponente
vlastitim posebnim simbolom. Zbog vee informativnosti dijagrama unutar komponenti mogu biti
naznaeni objekti koji se pomou njih realiziraju.
Svaki vor mora imati jedinstveno ime koje ga razlikuje od ostalih vorova u istom dijagramu
razmjetaja. Jednostavan naziv (engl. simple name) je samo ime vora, a naziv putanje (engl. path
name) je naziv paketa kojemu taj vor pripada (npr. server::backup). Naziv putanje uvijek prethodi
(prefiks) imenu vora. Oblik imena vora s nazivom putanje je proireni naziv (engl. extended name),
78
a takvi vorovi koji pripadaju drugom paketu nazivaju se proireni vorovi (engl. extended nodes).
vorovi s jednostavnim nazivom nazivaju se jednostavni vorovi (engl. simple nodes). Dobra je praksa
nazvati vorove nazivom posluitelja ili raunala (npr. IBM zEnterprise 196, PRIMERGY RX200 S6,
Stolno raunalo, Pametni mobilni telefon Android), generikim nazivom koji opisuje njegovu
funkciju (npr. Posluitelj baze podataka, Mreni posluitelj, Mobilni klijent), ili po operacijskom
sustavu koji se na raunalu izvrava (npr. posluitelj FreeBSD).
Primjer 8.2.1. Jednostavni i proireni vorovi
vorovi nekog sustava za naplatu su: kiosk aplikacija, prodaja i pohrana podataka (engl. backup).
Podsustav pohrane podataka izvrava se na posluitelju iz drugog paketa i s njim se moe upravljati
samo putem udaljenog pristupa (engl. remote administration), a ne neposredno iz paketa s
vorovima kiosk i prodaja. Prikazati vorove s jednostavnim i proirenim imenima.
Rjeenje:
KioskAplikacija1 je pojedinac (instanca) kiosk aplikacije. Prodaja predstavlja istoimeni podsustav
koji razmjeta dvije komponente: 'pos.exe' i 'kontakti.exe'. Osim tekstualno, komponente su se
mogle predstaviti i njihovim simbolima. Posluitelju se moe pristupiti samo udaljeno, pa se dijagram
proiruje s posebnom oznakom remoteAdministrationOnly kako bi se to ogranienje jasno
naznailo. Rjeenje primjera 8.2.1 prikazano je na slici 8.2.
8.3. Veze vorova

vorovi su meusobno povezani jednosmjernom ili puno ee dvosmjernom vezom koja oznaava
put prijenosa podataka izmeu vorova. Dobra praksa je oznaiti vezu komunikacijskim protokolom
ili tehnologijom pomou koje se odvija prijenos informacija, npr. TCP/IP, HTTP, RMI, .NET
Remoting, itd.
vorovi i komponente su esto meusobno ovisni. Pri tome komponenta moe biti ovisna o voru,
ali i obrnuto. Smjer veze ovisnosti uvijek je usmjerena od elementa koji generira informaciju ili
poruku, isporuitelja (engl. supplier) prema klijentu (engl. client) koji je konzumira, odnosno ovisi o
79
toj poruci. Komponente koje meusobno ovise jedna o drugoj, unutar istog vora ili izmeu vie
razliitih vorova, povezane su usmjerenom vezom ovisnosti (engl. dependency).
Ako komponenta ima definirano aplikativno suelje (npr. koristei port TCP/IP ili programsku
fasadu) veza dodiruje simbol suelja komponente (engl. component interface).
Primjer 8.3.1. Ovisnosti komponenti podsustava za naplatu
Neki podsustav za naplatu sastoji se od dvije komponente: mjesto prodaje (POS) i imenik.
Podsustav ovisi o komponentama. Prikazati navedene ovisnosti u dijagramu razmjetaja.
Rjeenje:
Ovisnost komponenti o voru kojemu pripadaju se podrazumijeva, ali svejedno moe se dodatno
naglasiti u dijagramu. U rjeenju primjera Prodaja je klijent, a komponente POS i Imenik su
isporuitelji. Rjeenje primjera 8.3.1 prikazano je na slici 8.3.

Primjer 8.3.2. Veze izmeu vorova
Neki sustav sastoji se od nekoliko vorova: kiosk-aplikacija, konzola, posluitelj, posluitelj za
sigurnosno spremanje podataka (engl. NAS storage) i RAID-polje tvrdih diskova. Kiosk je beino
povezan s posluiteljem putem WLAN-a, a konzola je povezana pomou 1 GB Etherneta. Posluitelj
pohranjuje podatke u polje vrstih diskova pomou NAS posluitelja.
Rjeenje:
Potrebno je nacrtati zadane vorove i povezati ih na opisani nain. Zbog vee informativnosti
dijagrama korisno je svaku vezu dodatno opisati. Rjeenje primjera 8.3.2 prikazano je na slici 8.4.
80
Primjer 8.3.3. Suelje komponente

Neki posluitelj sastoji se od vie komponenti. Jedna komponenta je posluiteljska aplikacija koja
ima javno izloeno suelje za konfiguraciju posluitelja.
8.4. Stereotipovi
UML-dijagrame mogue je proiriti koritenjem stereotipova. U dijagramima razmjetaja proirivi
su samo vorovi (komponente se ne mogu proirivati). To svojstvo moe se iskoristiti za oznaavanje
namjene vorova. Standardni stereotipovi vorova su:
1. processor vor koji ima obrauje podatke i izvrava komponente
2. device
vor koji ne moe obraivati podatke, ali predstavlja sklopovlje, neki ureaj
ili suelje prema fizikom svijetu.
Takoer, u dijagramima razmjetaja umjesto standardnog simbola vora dozvoljeno je koristiti
razliite slike ili ikone karakteristine za vor odreene namjene. Slikovni znakovi pruaju uinkovitije
razumijevanje namjene vorova, pogotovo u opirnim dijagramima s velikim brojem vorova.
Uestalo koritenje istog simbola za procesore i ureaje modeliranog sustava razliite namjene
doprinosi nejasnoi dijagrama.
Primjer 8.4.1. Modeliranje topologije sustava
Prikazati topologiju sustava iz prethodnog primjera koritenjem uobiajene ikonografije za vorove
kiosk, konzola i farme diskova.
Rjeenje:
Odabiremo pogodne ikone za naznaene vorove koje e doprinijeti izraajnosti dijagrama
razmjetaja. Rjeenje primjera 8.4.1 prikazano je na slici 8.6.
81
8.5. Pojedinci vorova i komponenti

Dijagram razmjetaja moe prikazivati pojedince vorova i komponenti. U tom sluaju dijagram
razmjetaja postaje slian dijagramu objekata. Pojedince raspoznajemo po podcrtanim nazivima.
U jednom dijagramu razmjetaja nije dozvoljeno mijeati definicije i pojedince vorova ili
komponenti, ve je mogue prikazati samo definicije, ili samo pojedince.
Pojedince vorova je korisno oznaiti najvanijim podacima iz specifikacije raunala i radne
okoline, primjerice Brzina procesora=3GHz, Radna memorija=16GB, vrsti disk=2TB, Verzija=3.1.4.
Primjer 8.5.1. Modeliranje topologije sustava pomou pojedinaca vorova i komponenti
Sustav iz prethodnog primjera potrebno je konkretizirati sa specifinim sklopovljem. Posluitelj ima
procesor s etiri jezgre brzine 2.2 GHz i 16 GB RAM-a. Posluitelj razmjeta dvije komponente:
'dbadmin.exe' i 'ctrlpanel.exe' koje ine aplikaciju za administratora baze podataka, odnosno
aplikaciju za upravljanje postavkama operacijskog sustava posluitelja Na NAS posluitelju e se
nalaziti upravljaka aplikacija 'nasadmin.exe'. Na kiosku se razmjeta aplikacija 'kiosk.exe'. Na konzoli
e se nalaziti komponente 'admin.exe' za upravljanje i 'konfig.exe' za promjenu postavki konzole.
82

Zadatak 8.1.
Neki raspodijeljeni dvoslojni informatiki sustav sastoji se od korisnike aplikacije koja se preko
Interneta povezuje na serversku aplikaciju. Korisnika aplikacija izvrava se na korisnikom raunalu i
spaja se na Internet preko ADSL-modema. Posluiteljska aplikacija izvrava se na grozdu tri
posluitelja kojima upravlja posluitelj privremene memorije (engl. caching server). Modelirati
razmjetaj opisanog sustava.
9. Rjeenja zadataka
9.1. Dijagrami obrazaca uporabe
Zadatak 2.1.
83
84
Zadatak 2.2.
85
Zadatak 2.3.
86
Zadatak 2.4.
87
Zadatak 2.5.
88
9.2. Sekvencijski i komunikacijski dijagrami

Zadatak 3.1.
89
Zadatak 3.2.
90
Zadatak 3.3.
91
Zadatak 3.4.
92
Zadatak 3.5.
93
3.1
.1:
[go 5 5.1.
2.1 tov .1: p 1: is
.1: ina okr pisi
_r
u ]u e
1.2 pisi_ pisi ni_n acu
_p ap n(
k
:
a
1.1 po
o
la )
r
: o tvrd ticu pust tu()
_
cit
_
aj_ i_oc za_ na_
pro itan pop go
izv je( us tov
t() inu
od )
()
()
Zadatak 3.6.
94
Zadatak 3.7.
)
ut(
r en ( ) )
ok vog n(
i_p la vlje )
lav i_p sta g(
: p ren au avo
6.1 pok vi_z i_pl
6: pla stav
. 1: au
2. 1 . 1: z
2
Napomena: asinkronost poruka (u ovom sluaju pri zaustavljanju robota) nije mogue modelirati
komunikacijskim dijagramom, tako da se najprije zaustavlja plavi, a potom crveni robot.
95
9.3. Dijagrami razreda

Zadatak 4.1.
96
Zadatak 4.2.
97
Zadatak 4.3.
98
Zadatak 4.4.
99
9.4. Dijagrami objekata i paketa

Zadatak 5.1.
Zadatak 5.2.
100
Zadatak 5.3.
101
9.5. Dijagrami stanja i aktivnosti

Zadatak 6.1.
Napomena 1: zadatak je mogue rijeiti u uvoenjem vora odluke odnosno uvjetnog grananja,
ovako:
Napomena 2: Nazivi dogaaja "entry" i "exit" kod stanja "Izmjena podataka u eliji" generirani su
automatski u programu Visio 2007. Mogu je i bilo koji drugi naziv za dogaaje u tom stanju.
102
Zadatak 6.2.
Zadatak 6.3.
Napomena: U dijagram je mogue ukljuiti i plivake staze efa, tajnice i nabave.
103
Zadatak 6.4.
104
9.6. Dijagrami komponenti

Zadatak 7.1.
U izradi dijagrama koristit e se ikonizirani oblik i openita slika datoteke izvornog koda.
crtaj.cpp
{version = 2.6.9}
crtaj.h
{version = 1.9}
jezgra.h
{version = 1.8}
boja.h
{version = 7.3}
polinom.h
{version = 4.5}
Zadatak 7.2.
Broj suelja komponente je neogranien. U ovom zadatku definirana su etiri suelja. Nisu
definirane operacije suelja pa se stoga koristi ikonizirani oblik prikaza.
executable
animator.exe
{version = 9.2.8}
ISkripte
ICrtanje
IModeli
IAplikacija
105
9.7. Dijagrami razmjetaja

Zadatak 8.1.
106
Literatura
[Bell 2004] D. Bell, UML basics: The sequence diagram, 2004, dostupno na:
http://www.ibm.com/developerworks/rational/library/3101.html, [pristupljeno dana 10. 10.
2012.]
[Booch 1999] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide,
Addison-Wesley, 1999.
[Fowler 2000] M. Fowler, K. Scott, UML Distilled, 2nd ed., Addison-Wesley, 2000.
[Fowler 2004] M. Fowler, UML Distilled: a brief guide to the Standard object modeling language, 3rd
ed., Addison-Wesley, 2004.
[Holub 2012] A. I. Holub, Allen Holub's UML Quick Reference (UML 2.0), version 2.1.3, dostupno na:
http://www.holub.com/goodies/uml/, [pristupljeno dana 10. 10. 2012.]
[Lethbridge 2005] T. C. Lethbridge, R. Laganire, Object-Oriented Software Engineering, McGraw-Hill
Education, 2005.
[OMG 2011] Object Management Group, OMG Unified Modeling Language (OMG UML),
Infrastructure, Version 2.4.1, 2011, dostupno na:
http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/, [pristupljeno dana 10. 10. 2012.]
[Quatrani 2002] T. Quatrani, Visual Modeling with Rational Rose 2002 and UML, 3rd ed., AddisonWesley, 2002.
[Rational 2001] Rational Software Corporation, Artifact: Use-Case Model, dostupno na:
http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_ucmod.htm, [pristupljeno
dana 10. 10. 2012.]
[Wulp 2011] M. van der Wulp, et al., ArgoUML User Manual, v.0.32, 2011, dostupno na:
http://argouml-downloads.tigris.org/argouml-0.32/, [pristupljeno dana 10. 10. 2012.]
107

Prirucnik UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Prirucnik UML

Uploaded by

Copyright:

Available Formats

Sveuilite u Zagrebu

Fakultet elektrotehnike i raunarstva

Manualia Universitatis studiorum Zagrabiensis

Zagreb, listopad 2013.

Dijagrami obrazaca uporabe ............................................................................................................ 7

Sekvencijski i komunikacijski dijagrami....................................................................................... 19

Dijagrami razreda .......................................................................................................................... 35

4.12. Nasljeivanje ili agregacija?..................................................................................................... 45

Dijagrami objekata i paketa ........................................................................................................... 54

Dijagrami stanja i aktivnosti.......................................................................................................... 63

Dijagrami komponenti ................................................................................................................... 71

8.3. Veze vorova .............................................................................................................................. 79

Rjeenja zadataka .......................................................................................................................... 83

Literatura ............................................................................................................................................. 107

Slika 1.1. Pregled UML-dijagrama, norma UML 2.4 [OMG 2011]

dijagramu obrazaca uporabe, dijagramu razreda i sekvencijskom dijagramu. itatelji se upoznaju s

2. Dijagrami obrazaca uporabe

Slika 2.1. Rjeenje primjera 2.1.1.

2.2. Elementi dijagrama

Slika 2.2. Rjeenje primjera 2.2.1.1.

Uvoenje generalizacije meu aktorima u dijagramima obrazaca uporabe je korisno zato to se

2.2.4. Asocijacija (engl. association)

Slika 2.3. Asocijacija izmeu aktora i obrasca uporabe.

Slika 2.4. Primjer viestrukosti.

Slika 2.5. Vremenski interval pri odreivanju viestrukosti.

Slika 2.6. Primjer generalizacije.

Slika 2.7. Primjer ukljuivanja.

Proireni obrazac uporabe

Osnovni obrazac uporabe

Slika 2.8. Primjer proirenja.

Slika 2.9. Primjer koritenja veze proirenja u dijagramima obrazaca.

Slika 2.10. Dijagram obrazaca uporabe za primjer 2.2.8.1.

2.3. Zadaci za vjebu

Zadatak 2.5. Modeliranje sigurnosnog sustava banke

3. Sekvencijski i komunikacijski dijagrami

3.2. Sekvencijski dijagrami

Naziv sudionika : Razred

Slika 3.1. Primjeri sudionika.

Slika 3.2. Sudionici sa ivotnim linijama iz primjera 3.2.1.1.

Slika 3.3. Traenje otvaranja rauna.

Slika 3.4. Povratna poruka osobnog bankara.

Slika 3.5. Konano rjeenje primjera 3.2.1.1.

Slika 3.6. Sudionici iz primjera 3.2.1.2.

Slika 3.8. Poziv internog postupka za raspakiravanje sadraja kutija.

Slika 3.9. Uvjet na popunjenje kontejnera i signalna poruka nadzorniku.

Slika 3.11. Konano rjeenje primjera 3.2.1.2.

Slika 3.12. Primjer stvaranja i brisanja sudionika u sustavu.

Slika 3.13. Opi oblik poruke u sekvencijskom dijagramu.

Slika 3.14. Uvjetno grananje podrano u sekvencijskom dijagramu.

3.2.3. Zadaci za vjebu

3.3. Komunikacijski dijagrami

Slika 3.15. Meudjelovanje klijenta i podsustava za odabir parametara leta.

Slika 3.16. Komunikacija klijenta s podsustavom za detalje leta.

Slika 3.17. Komunikacija izmeu klijenta i sustava za naplatu.

Slika 3.18. Konano rjeenje primjera 3.3.1.1.

Podsustav za odabir parametara

3.3.2. Napomene u vezi komunikacijskih dijagrama

3.3.3. Zadaci za vjebu

Slika 4.1. Rjeenje primjera 4.1.1.

4.2. Odnosi izmeu razreda

Slika 4.2. Odnosi izmeu razreda: pridruivanje i podtip.

Slika 4.3. Rjeenje primjera 4.3.1.

4.4. Vrhovi i nazivi veza