Sadraj

1. UVOD..............................................................................................................................................1

2. UML MODELIRANJE........................................................................................................................2

2.1. Povijest...................................................................................................................................2

2.2. Modeliranje............................................................................................................................3

2.3. UML Language........................................................................................................................5

3. DIJAGRAMI...................................................................................................................................11

3.1. Modeliranje UML dijagrama objekata..................................................................................12

3.1.1. Definiranje objekata......................................................................................................13

3.1.2. Veze izmeu objekata...................................................................................................13

3.2. Modeliranje UML dijagrama klasa........................................................................................15

3.2.1. Definiranje klasa...........................................................................................................16

3.2.2. Pridruivanje.................................................................................................................17

3.2.3. Agregacija i kompozicija................................................................................................19

3.2.4. Pridruivanje, agregacija ili kompozicija?......................................................................20

3.2.5. Atribut..........................................................................................................................20

3.2.6. Nasljeivanje................................................................................................................21

3.2.7. Ovisnost........................................................................................................................22

3.2.8. Suelje i implementacija...............................................................................................23

4. ZAKLJUAK...................................................................................................................................24

5. LITERATURA..................................................................................................................................25

6. POPIS SLIKA..................................................................................................................................26
1. UVOD

Raznolikost dijagrama UML-a omoguuje modeliranje jednostavnih, ali i vrlo sloenih

aplikacija. Sami dijagrami omoguuju viestruki pogled na sustav koji se analizira i
meusobno su povezani, to olakava interakciju, a samim time verifikaciju dijagrama i
kvalitetu softvera.

Rad prati definiranje i razvoj UML-a, objanjava osnove modeliranja, te se ciljano fokusira na
dijagrame klasa i objekata. Kroz modeliranje u tim dijagramima usporeuju se slinosti i
razlike ove dvije kategorije, koje su istaknute u zakljuku.

Pritom koritene metode jesu: analiza ( pri definiranju glavnih pojmova analizirati e se
njihovi sastavni dijelovi to e pridonijeti njihovom lakem razumijevanju ), dedukcija
( prilikom dokazivanja ili odbacivanja radne hipoteze preko pojedinanih rezultata
istraivanja donijeti e se opi zakljuak ), indukcija ( preko postavljene radne hipoteze
istraivati e se njeni sastavni dijelovi na temelju kojih e se donositi pojedinani posebni
zakljuci ), deskripcija ( prilikom analize opisivati e se pojedine injenice, procesi te
empirijske veze izmeu njih ), klasifikacija ( vaniji pojmovi razloiti e se na njihove
sastavne dijelove ), komparacija ( prilikom objanjavanja rezultata istraivanja usporeivati e
se pojedine injenice i utvrivati njihove slinosti i razlike ) i kompilacija ( pri razradi teme
navoditi e se zakljuci drugih istaknutih autora ).

1
2. UMLMODELIRANJE

Kako bi se izgradila programska podrka dugotrajne kvalitete, potrebno je sloiti solidnu

baznu arhitekturu. Za brz i efikasan razvoj programske podrke, potrebno je imati prave ljude,
dobar alat i dobar fokus. Kako bi se to sve napravilo konzistentno i sa uzimanjem u obzir
same cijene razvojnog ciklusa, potrebno je imati dobar razvojni proces koji se moe vrlo lako
prilagoditi stalnim promjenama tehnologije i poslovanja.

2.1. Povijest

Objektno-orijentirano programiranje pojavilo se negdje izmeu sredine '70-ih i kraja '80-ih

kada su metodolozi, suoeni sa novom vrstom objektno-orijentiranih programskih jezika i
poveanom kompleksnou aplikacija, poeli eksperimentirati sa alternativnim pristupima
analizi i dizajnu. Veliki broj korisnika objektno-orijentiranih metoda imao je puno problema u
traenju onog jezika za modeliranje koji bi u potpunosti pokrivao njihove potrebe.

Na osnovu tog iskustva poele su se pojavljivati nove generacije metoda, od kojih je

nekolicina bila vrlo napredna, posebno Booch-ova, Jacobson-ova OOSE (Object-Oriented
Software Engineering) i Rumbaugh-ova OMT (Object Modeling Technique). Svaka od njih
bila je kompletna metoda i svaka je imala svoje prednosti i mane. Npr. Booch-ova metoda bila
je vrlo ekspresivna za vrijeme dizajna i faze konstrukcije projekta, OOSE davala je izvrsnu
podrku za "sluajeve koritenja" (eng. use-cases) kao nain prolaska kroz postavljanje
zahtjeva na sustav (eng. requirements), analize i dizajna na visokoj razini (eng. high-level
design), a OMT-2 bila je najkorisnija kod analize informacijskih sustava sa velikim
zahtjevima na obradu podataka1.

Kritina masa ideja poela se formirati sredinom '90-ih kada se htjelo stabilizirati objektno-
orijentirano trite i omoguiti projektima koritenje jednog zrelog jezika za modeliranje.
Takoer, eljela sa napraviti nova naprednija metoda.

Slubeni poetak razvoja UML-a poeo je u listopadu 1994, kada se Rumbaugh udruio sa
Booch-em u Rational Software Corporation. Projekt se u poetku sastojao od unifikacije
Booch-eve i OMT metode. Verzija 0.8 Unified Method (kako se u to vrijeme zvala) izala je u
1
http://www.mitchellsoftwareengineering.com/IntroToUML.pdf (20.01.2015.)
2
listopadu 1995. U to vrijeme je i Jacobson preao u Rational i opseg UML-a se proirio i od
tada je obuhvaao i OOSE. U lipnju 1996. izala je verzija 0.9. U to se ve vrijeme vidjelo da
velika veina organizacija koje proizvode programsku podrku vidi UML kao strategiju za
svoj posao. Tada je osnovan UML konzorcij sa nekoliko organizacija koje su bile voljne
upregnuti svoje resurse kako bi se dolo do stabilne i kompletne definicije UML-a. Ti
partneri, koji su pridonijeli UML 1.0 definiciji, bili su DEC, Hewlett-Packard, I-Logix,
Intellicorp, IBM, ICON Computing, MCI, Microsoft, Oracle, Rational, Texas Instruments i
Unisys. Ta suradnja rezultirala je sa UML 1.0, jeziku za modeliranje koji je bio dobro
formiran, ekspresivan, snaan i primjenjiv u irokom spektru domena problema. UML 1.0 je
ponuen na standardizaciju OMG-u (Object Management Group) u sijenju 1997., kao
odgovor na njihov zahtjev za prijedlog standardnog jezika za modeliranje2.

Izmeu sijenja i srpnja 1997., originalna grupa se proirila i obuhvatila je sve koji su poslali
svoje prijedloge OMG-u, ukljuujui Andersen Consulting, Ericsson, Platinum Technology,
Softeam, itd. Osnovana je grupa za semantiku, koju je vodio Cris Kobryn, kako bi se
formalizirala UML specifikacija i kako bi se UML integriralo sa drugim standardima.
Revidirana verzija UML-a (verzija 1.1) je predana na pregled OMG-u u srpnju 1997. i OMG
ADTS (Analysis and Design Task Force) je u rujnu 1997. prihvatio tu verziju i dao ju na
glasovanje. Na kraju je UML 1.1 prihvaen od strane OMG-a u prosincu 19943.

2.2. Modeliranje

Modeliranje je glavni dio svih aktivnosti koje vode produkciji dobre programske podrke.
Njime se vizualizira i kontrolira arhitektura sustava u cilju boljeg shvaanja sustava koji se
izgrauje i esto se koristi radi pojednostavljenja i mogunosti ponovne iskoristivosti dijelova
tog istog sustava. Ono je dokazana i iroko prihvaena inenjerska tehnika (npr. arhitekti rabe
modeliranje kako bi olakali projektiranje neke kue ili zgrade, bilo bi gotovo nemogue
proizvesti novi avion ili auto bez prethodne izrade modela od raunalnih modela, fizikih
modela, koji se testiraju u zranim tunelima, pa sve do pravih prototipova)4.

2
http://www.omg.org/ (19.01.2015.)

3
Ibidem

4
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999,
str.13.
3
Kroz modeliranje, postiu se etiri cilja5:

1. Modeli pomau pri vizualizaciji sustava koji se promatra ili koji se eli izgraditi.

2. Modeli omoguuju specifikaciju strukture ili ponaanja sustava.

3. Modeli pruaju predloke koji slue kao vodii pri izgradnji sustava.

4. Modeli dokumentiraju odluke koje su donesene.

U razvoju programske podrke postoji nekoliko naina pristupa modelu. Dva najea
pristupa su pristup sa strane algoritma i objektno-orijentirani pristup.

Tradicionalan pogled na razvoj programske podrke uzima pristup sa strane algoritma. U

ovom pristupu, glavni graevni elementi programa su procedure ili funkcije, a glavni fokus se
daje na stvari vezane uz kontrolu i dekompoziciju veih algoritama na manje. Ovaj nain
razvoja nije lo, ali je vrlo teak za odravanje.

Moderan pogled na razvoj sustava za programsku podrku koristi objektno-orijentirani

pristup. Ovdje je glavni graevni blok sustava objekt ili klasa. Objektno-orijentirani pristup
zauzima centralno mjesto meu pristupima razvoju programske podrke jednostavno zato to
je dokazao svoju vrijednost u razvoju sustava u raznim domenama problema i u obuhvaanju
svih razina kompleksnosti. Nadalje, veina modernih jezika, operativnih sustava i alata su u
neku ruku objektno-orijentirani, dajui vei doprinos objektno-orijentiranom pogledu na
svijet. Objektno-orijentirani razvoj daje i konceptualne temelje razvoju sustava kroz slaganje
komponenata koristei tehnologije poput Java Beans ili COM+.

2.3. UMLLanguage

Modeliranje prua razumijevanje sustava. Niti jedan model nije, sam po sebi, dovoljan, ve je
esto potrebno vie povezanih modela kako bi se razumio i najjednostavniji sustav. Sustavi
programske podrke zahtijevaju jezik koji se bavi razliitim pogledima na arhitekturu sustava,
kako se sustav razvija kroz razvojni ciklus.

5
http://www.mitchellsoftwareengineering.com/IntroToUML.pdf (20.01.2015.)
4
Unified Modeling Language (UML) je grafiki jezik za vizualiziranje, specificiranje,
konstruiranje i dokumentiranje sustava programske podrke. On prua standardiziran nain
planiranja sustava, pokrivajui konceptualne stvari (poslovni procesi i funkcije sustava) i
konkretne stvari ( klase pisane u nekom programskom jeziku, sheme baza podataka i ponovno
iskoristive (eng. reusable) programske komponente)6.

UML obuhvaa informacije o statikoj strukturi i dinamikom ponaanju sustava. Sustav se

modelira kao kolekcija diskretnih objekata koji su u interakciji, a koji u konanici pogoduju
vanjskim korisnicima. Statina struktura definira vrste objekata vanih za sustav i njegovu
provedbu, kao i odnos meu objektima. Dinamiko ponaanje definira povijest objekata
tijekom vremena i komunikacija meu predmetima kako bi ostvarili ciljeve. Modeliranje
sustava od nekoliko odvojenih, ali povezanih gledita podrazumijeva razliite namjene7.

Nije namijenjen kao potpuna metoda razvoja, te ne ukljuuje step by step proces razvoja.
Vano je shvatiti da su UML i postupak za koritenje UML-a dvije odvojene stvari. UML je
namijenjen za podrku svih, ili barem veine, postojeih razvojnih procesa. Ukljuuje sve
pojmove za koje vjerujemo da su potrebni kako bi podrali moderni proces, a temelji se na
izgradnji jake arhitekture. Konani cilj UML je jednostavnost, izraajnost, te obrada svih
pojmova koji se javljaju u modernom sustavu, kao to su podudarnosti i distribucije, kao i za
softversko inenjerstvo to ukljuuje mehanizme, kao to su kuita i komponenti. To mora
biti univerzalni jezik8.

UML je prvenstveno namijenjen sustavima koji se oslanjaju na programsku podrku. Vrlo se

efikasno koristi u slijedeim domenama9:

Poslovni informacijski sustavi

Bankarske i financijske usluge

Telekomunikacije

6
http://www.mitchellsoftwareengineering.com/IntroToUML.pdf (20.01.2015.)

7
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999,
str.2.

8
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999,
str.8.

9
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999,
str.8.
5
 Transport

Obrana/avionautika

Prodaja

Medicinska elektronika

Znanost

Distribuirane mrene usluge

UML nije ogranien samo na modeliranje programske podrke. Ustvari, dovoljno je

ekspresivan i za modeliranje ostalih sustava, kao to su tok podataka i dokumenata u pravnom
sustavu, struktura i ponaanje zdravstvenog sustava pacijenta, i dizajn sklopovlja.

Za razumijevanje UML-a, potrebno je formirati konceptualan model jezika i to zahtijeva

uenje tri glavna elementa10:

osnovne graevne blokove UML-a

Rjenik UML-a obuhvaa tri tipa graevnih blokova:

1. Stvari - postoje etiri vrste stvari u UML-u:

strukturalne stvari (eng. structural things)

stvari sa ponaanjem (eng. behavioral things)

grupirajue stvari (eng. grouping things)

oznaavajue stvari (eng. annotational things).

Te stvari su osnovni objektno-orijentirani graevni blokovi UML-a i koriste se za pisanje

dobro formiranih modela.

Klasa pripada u strukturalne stvari, a predstavlja opis skupa objekata koji dijele iste atribute,
operacije, relacije i semantiku. Klasa moe implementirati jedno ili vie suelja (eng.
interface). Grafiki, klasa je prikazana kao pravokutnik koji obino sadri ime, atribute i
operacije kao na slici 1.

Slika 1. Prikaz klase

10
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999,
str.23. 53.
6
Aktivna klasa (eng. active class). To je klasa iji objekti posjeduju jedan ili vie procesa ili niti
i time mogu inicirati neku kontrolnu aktivnost. Slina je samoj klasi osim to njeni objekti
predstavljaju elemente ije ponaanje je konkurentno sa ostalim elementima. Grafiki,
predstavlja se kao i normalna klasa, ali sa podebljanim linijama, kao na slici 2.

Slika 2. Aktivna klasa

U UML, aktivne klase, te stoga i aktivni objekti, imaju vlastiti adresni prostor. Aktivni objekti
mogu mijenjati varijable, promjena ponaanja programa, i tako dalje.

Pasivni objekti u UML obino nemaju mogunost izmjene. Umjesto toga, pasivni objekti se u
pravilu se koriste za pohranu podataka, te se mogu dijeliti izmeu vie drugih objekata11.

2. Relacije

Postoje etiri tipa relacija unutar UML modela:

Ovisnosti (eng. dependency)

Asocijacije (eng. association)

Generalizacije (eng. generalization)

Realizacije (eng. realization)

Ove su relacije osnovni relacijski graevni blokovi u UML-u i koriste se za pisanje dobro
formiranih UML modela.

11
http://www.markdini.com/razlika-izmedu-pasivni-objekt-active-objekta-u-uml/ (18.01.2015.)
7
 3. Dijagrame

Dijagram je grafika prezentacija skupa elemenata, najee prikazanih kao povezani grafovi
vertikala (stvari) i lukova (relacije). Dijagrami se crtaju kako bi se vizualizirao sustav iz
razliitih perspektiva, pa to ini dijagram nekom vrstom projekcije u sustav. Za gotovo sve
sustave, osim onih vrlo jednostavnih, dijagrami predstavljaju poboljani prikaz elemenata koji
ine sustav. Isti elementi mogu se pojaviti u svim dijagramima, nekim dijagramima (najei
sluaj) ili se uope ne pojaviti (jako rijetko).

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 sljedovi 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 3. U okviru ove podjele
postoji vei broj pojedinanih dijagrama, od ega se u okviru ove zbirke obrauju oni
dijagrami koji su oznaeni sivo na slici12.

Slika 3. Podjela dijagrama

12
http://www.mitchellsoftwareengineering.com/IntroToUML.pdf (20.1.2015.)
8
Teoretski, dijagram moe sadravati bilo koju kombinaciju stvari i relacija u modelu. U
praksi, meutim, samo se mali broj kombinacija pojavljuje, i one su konzistentne sa pet
najkorisnijih pogleda na sustav koji ine arhitekturu sustava koji se oslanjaju na programsku
podrku. Stoga, UML ukljuuje devet takvih dijagrama13:

Dijagram klasa

Dijagram objekata

Dijagram sluajeva koritenja

Dijagram toka

Dijagram suradnji

Dijagram stanja

Dijagram aktivnosti

Dijagram komponenata

Dijagram pokretanja

Ovaj rad posebno objanjava dijagrame klasa i objekata u daljnjem tekstu.

13
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999,
str. 53 59.
9
 pravila koja diktiraju kako koristiti i slagati te blokove

neke osnovne mehanizme koji se primjenjuju kroz UML

10
3. DIJAGRAMI

Prema gore navedenom slijedi kratki opis svakog dijagrama, koji e se posebno posvetiti
dijagramu klasa i objekata u svrhu daljnjeg objanjenja modeliranja14.

Dijagram klasa prikazuje skup klasa, suelja i suradnji i njihove meusobne relacije. Ti
dijagrami su najei u objektno-orijentiranim sustavima. Dijagrami klasa bave se statikim
pogledom na dizajn sustava, a oni koji ukljuuju i aktivne klase, bave se i statikim pogledom
na procese u sustavu.

Dijagram objekata prikazuje skup objekata i njihove relacije u sustavu. Dijagrami objekata
predstavljaju statiku snimku instanci stvari koje se nalaze u dijagramu klasa. Oni se bave
statikim pogledom na dizajn i procese sustava, kao i dijagrami klasa, ali iz perspektive
pravih prototipova, tj. pravih objekata u sustavu.

Dijagram sluajeva koritenja prikazuje skup sluajeva koritenja i glumaca (eng. actors
specijalan tip klase) i njihovih relacija. Dijagrami sluajeva koritenja bave se statikim
pogledom na sluajeve koritenja u sustavu i vrlo su vani kod organiziranja i modeliranja
ponaanja sustava.

Dijagram toka i dijagram suradnji su tipovi interakcijskih dijagrama. Interakcijski dijagram

prikazuje interakciju, koja se sastoji od skupa objekata i njihovih relacija, zajedno sa
porukama koje se mogu slati izmeu njih. Interakcijski dijagram bavi se dinamikim
pogledom na sustav. Dijagram toka je interakcijski dijagram, koji daje naglasak na vremensku
dimenziju i poredak poruka. Dijagram suradnji je interakcijski dijagram, koji daje naglasak na
strukturalnu organizaciju objekata koji primaju i alju poruke. Oba dijagrama su izomorfni,
to znai da se svaki od njih moe lako transformirati u drugi.

Dijagam stanja prikazuje automat stanja, koji se sastoji od stanja, prijelaza, dogaaja i
aktivnosti i bavi se dinamikim pogledom na sustav. Dijagrami stanja su vrlo vani u
modeliranju ponaanja suelja, klasa ili suradnji i daju naglasak na ponaanje objekta
odreeno slijedom dogaaja, to je jako korisno u modeliranju reaktivnih sustava.

14
http://www.mitchellsoftwareengineering.com/IntroToUML.pdf (20.1.2015.)
11
Dijagram aktivnosti je specijalan tip dijagrama stanja koji pokazuje tok iz aktivnosti u
aktivnost unutar sustava i bavi se dinamikim pogledom na sustav. Vrlo su vani u
modeliranju funkcija sustava i daju naglasak na tok kontrole izmeu objekata.

Dijagram komponenata prikazuje organizacije i ovisnosti izmeu skupa komponenata.

Dijagrami komponenata bave se statikim pogledom na implementaciju sustava. Povezani su
sa dijagramima klasa tako da su komponente tipino mapirane na jednu ili vie klasa, suelja
ili suradnji.

Dijagram pokretanja prikazuje konfiguraciju izvrnih procesnih vorova i komponenata koje

se izvode na njima. Dijagrami pokretanja bave se statikim pogledom na pokretanje
arhitekture sustava. Povezani su sa dijagramima komponenata tako da vor tipino obuhvaa
jednu ili vie komponenata.

3.1. ModeliranjeUMLdijagramaobjekata

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

Modeliranje UML dijagrama objekata biti e objanjeno na primjeru koji slijedi.

Zadatak. Klasa 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. Treba izraditi tri pojedinca navedene klase s proizvoljnim vrijednostima atributa.

Nadalje, te osobe rade unutar organizacije koja 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. Treba neovisno o prethodnim informacijama izraditi
model.

15
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999
12
3.1.1. Definiranjeobjekata

Simbol objekta je pravokutnik s dva pretinca jedan za naziv objekta i drugi za vrijednosti
atributa. Prikazuju se atributi po kojima se pojedinci unutar dijagrama meusobno razlikuju,
odnosno po kojima su oni specifini.

S obzirom na na primjer, prvo treba definirati klasu Osoba. U tekstu zadatka zadan je naziv
klase i njenih atributa, bez operacija. Operacije klase 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. 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 klasu kojoj
pripada. Primjerice, Osoba1 : Osoba jer pojedinac imena Osoba1 koje je jedinstveno u
dijagramu i izveden je iz klase Osoba. Unosimo vrijednosti atributa pojedinaca klase Osoba:
(ifra, Ime i prezime, OIB) = { (1, Petar Kova, 123); (2, Luka Horvat, 456); (3, Ivan Gali,
789). Vrijednosti su proizvoljno odabrane. Rjeenje je prikazano na slici 4.

Slika 4. Definiranje objekta

3.1.2. Vezeizmeuobjekata

Dijagrami objekata sastoje se od objekata i veza. Za pridruivanja objekata najee se koristi

dvosmjerna veza, a dozvoljeno je koritenje i kompozicije.

U izradi dijagrama objekata prvo odaberemo klase ije objekte emo prikazati. Najee su to
najvanije klase za ispravno funkcioniranje sustava, odnosno one klase 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

13
prikazati stanje sustava za svaki obrazac uporabe prethodno definiran u istoimenim
dijagramima16.

itajui na zadatak, koji izrazito kae da drugi dio uzmemo kao zaseban sluaj, uoavamo
etiri klase: organizacija, odjel, osoba i kontakt informacije. Klasa Organizacija sadrava
klasu Odjel koja je u reflektivnoj vezi sama 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. Postoji samo
jedna organizacija i nekoliko odjela, stoga e se u rjeenju nalaziti samo jedan pojedinac klase
Organizacija i tri pojedinca klase 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. Potpuni prikaz opisanog je na slici 5.

Slika 5. Veze izmeu objekata

16
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 19. 01. 2015. )
14
3.2. ModeliranjeUMLdijagramaklasa

Dijagrami klasa 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. Za svaku klasu nuno je definirati naziv, a mogue je odrediti popis atributa i
operacija. Makar atribute i operacije nije nuno definirati, bez njih klasa 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 parametre17.

Na primjeru studentske administracije prikazati u jedan postupak modeliranja dijagrama

klasa.

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

17
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999.
15
Nadalje, 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. dizajnirani sustav treba implementirati u
programskom jeziku C++.

3.2.1. Definiranjeklasa

Tekst zadatka jasno definira koji atributi se trae u definiciji klasa 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)18. Prve dvije operacije (prijaviIspit i odjaviIspit)
vraaju vrijednost tipa Bool, dok trea operacija (pristupiIspitu) vraa vrijednost tipa Double.
Rjeenje je prikazano na slici 6.

Slika 6. Definiranje klasa

4.1.1. Odnosi izmeu klasa

18
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 19.01. 2015.)
16
Dva osnovna tipa odnosa izmeu klasa su pridruivanje (veza ili asocijacija) i podtip, a
prikazani su na slici 7 .

Slika 7. 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 klasa, njihova svojstva i ogranienja nad
njima, pakete, ovisnost, tipove podataka, obrojavanje (enumeraciju), komentare i vie drugih
strukturnih svojstava sustava19.

3.2.2. Pridruivanje

Pridruivanje ili veza (engl. association) opisuje statine odnose izmeu dva pojedinca,
odnosno instance, objekta. Veze dijelimo na jednosmjerne, dvosmjerne, agregacije i
refleksivne. Tip agregacije ukljuuje i kompoziciju20.

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

19
Ibidem

20
Ibidem
17
raunalni kod koji implementira bidirekcionalnu vezu u obje klase mora imati suprotnu
funkcionalnost21.

U naem zadatku 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 nova klasa UpisniPodaci koja je povezana
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. To je, kao i imenovanje
uloga i veza, vidljivo je na slici.
Slika 8. Pridruivanje i veze

21
Ibidem
18
to se tie samih veza i vrhova, veze se nazivaju glagolima ili rjee imenicama, odnosno
mogu opisivati akciju koju jedna klasa vri nad drugom (npr. veza slua_predmet izmeu
klasa Student i Predmet), ili odnos izmeu dvije klase (npr. mentor izmeu klase 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 veze22.

3.2.3. Agregacijaikompozicija

Agregacija (engl. aggregation) je vrsta pridruivanja koja pokazuje da jedna klasa sadri
druge, tj. da je dio druge klase. Kae se da je klasa agregirana (sadrana) u drugoj klasi. 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 klase (tj. pojedinca) uvijek unitavaju i
pojedinci klase 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 klasu nadskup, a prazna linija klasu podskup. Veze
agregacija i kompozicija usmjerene su od nadskupa prema podskupu23.

22
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/

23
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 19.01.2015.)
19
3.2.4. Pridruivanje,agregacijailikompozicija?

Ako se primijeti da su dvije klase u svezi i da jedna obuhvaa ili sadrava drugu, odnosno, da
su povezane 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 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 klase podskupa
ostaju u sustavu nakon brisanja objekta razreda nadskup. U sluaju da to nije eksplicitno
naglaeno, ispravno je pretpostaviti da pojedince klase podskup nije potrebno izbrisati iz
radne memorije. Naravno, ako se povezane klase ne odnose jedna prema drugoj 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 klasa. 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
dvosmjerna24.

3.2.5. Atributi

Atributi (engl. attributes) su lanske varijable klase. 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 klase 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)25.

24
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/
25
A. I. Holub, Allen Holub's UML Quick Reference (UML 2.0), version 2.1.3, dostupno na:
http://www.holub.com/goodies/uml/
20
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)26.

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 klasa
i podataka koji su definirani u istom dijagramu. Koritenje klasa 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 changeable27.

3.2.6. Nasljeivanje

Nasljeivanje (engl. inheritance) je temeljni koncept objektno-orijentiranog programiranja

koji se moe uspjeno modelirati UML-dijagramima. Nasljeivanje je oblik odnosa izmeu
klasa, odnosno nasljedna veza izmeu klasa. Jedna klasa je roditelj (nadrazred) jednoj ili vie
drugih klasa (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

26
M. Fowler, K. Scott, UML Distilled, 2nd ed., Addison-Wesley, 2000.

27
Rational Software Corporation, Artifact: Use-Case Model, dostupno na:
http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_ucmod.htm, [pristupljeno dana
21.01.2015.]
21
ponaanje zajedniko za nekoliko klasa, a specijalizacija omoguuje stvaranje podklase koja
predstavlja dodavanje novih elemenata. Odnosi generalizacija i specijalizacija usmjereni su u
meusobno suprotnim smjerovima. Generalizacija je usmjerena od podklase prema nadklasi,
a specijalizacija od nadklase prema podklasi. Na dijagramima klase veza nasljeivanja uvijek
je usmjerena od podklase prema nadklasi, tj. u smjeru generalizacije. Ponekad je korisno
nasljeivanje crtati tako da je nadklasa smjetena iznad podklase jer to pridonosi
jednostavnijem i brem razumijevanju dijagrama razreda28.

Nasljeivanje nema viestrukost. Ovo svojstvo nasljeivanja je oito i samorazumljivo, ali

korisno ga je izriito naglasiti. 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 klasa. esto je potrebno nasljeivanje i agregaciju koristiti
zajedno.

3.2.7. Ovisnost

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 dvije klase A i B, te ako se zna da B ovisi o
promjenama stanja klase A, tada e se nacrtati UML veza ovisnosti, usmjerena od B prema
A29.

U programskom kodu ovisnost moemo implementirati na vie naina, primjerice s

funkcijama koje oslukuju dogaaje (engl. event handlers). U tom sluaju klasa B koja ima
navedenu funkciju je ovisna o klasi A koja generira dogaaj. Ureiva ArgoUML ne
preslikava svojstvo ovisnosti u programski kod30.

3.2.8. Sueljeiimplementacija

28
A. I. Holub, Allen Holub's UML Quick Reference (UML 2.0), version 2.1.3, dostupno na:
http://www.holub.com/goodies/uml
29
Ibidem

30
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 18.01.2015.)
22
Suelje (engl. interface) je skup operacija koje specificiraju usluge neke klase. Suelje
definira skup operacijskih specifikacija (tj. njihovih potpisa), ali nikada skup njihovih
implementacija. Drugim rijeima, suelje je vrsta klase ali bez atributa, dok sve operacije
imaju samo definiciju, bez tijela funkcije i implementacije programskog koda. Ispravan izgled
UML-simbola suelja je slian klasi ali bez prostora za atribute. Suelje je usko povezano s
odnosom realizacije (engl. realization) koje oznaava ostvarenje suelja. Jedna ili vie klasa
realiziraju ili ostvaruju suelje, odnosno koriste suelje kako bi implementirale 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 usmjerena od klase prema suelju. U ureivau ArgoUML realizacija ima dva
svojstva: suelje (supplier) i klasu koje 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 klasa bez mijenjanja njihove definicije, to je u
konanici slino uinku viestrukog nasljeivanja31.

31
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999
23
4. ZAKLJUAK

Rjenik i pravila jezika kao to je UML govore kako treba kreirati i itati dobro formirane
modele, ali ne govore koje modele treba kreirati i kada ih treba kreirati. To je uloga razvojnog
procesa. Stvari su apstrakcije i one su glavni dijelovi UML-a. Relacije povezuju te iste stvari,
a dijagrami grupiraju interesantne kolekcije tih stvari.

Na temelju svega napisanoga, moe se zakljuiti da pri modeliranju UML dijagrama klasa i
objekata postoje dvije slinosti koje ukljuuju statinost i injenicu da oba dijagrama
pripadaju strukturalnim.

No, ima puno vie razlika nego slinosti izmeu ova dva procesa. Prva razlika potjee iz same
definicije koja klasu karakterizira kao apstrakciju, a objekt kao konkretnu manifestaciju
apstrakcije. Samim time klasa ukljuuje puno ire opise, dok objekt ukljuuje odreene
pojedinosti. Iz toga pak proizlazi da je objekt pojedinac unutar opisa grupe klase. Kao
pojedinac pokazuje strukturu sustava u nekom trenutnu, to nikako nije svojstveno za klasu
koja slijedi brojne operacije. Unutar operacija klasa definira brojne atribute i procedure, dok
objekt ne ovisi o tim definicijama, ve ima tono odreeno stanje.

Dobro definiran proces vodi korisnika u odluivanju koje komponente sustava treba kreirati,
kada ih treba kreirati, koje aktivnosti koristiti za njihovo kreiranje i kako koristiti te
komponente u mjerenju i kontroli projekta kao cjeline.

24
5. LITERATURA

1. http://www.markdini.com/razlika-izmedu-pasivni-objekt-active-objekta-u-uml/
(18.01.2015.)
2. http://www.mitchellsoftwareengineering.com/IntroToUML.pdf (20.01.2015.)
3. http://www.omg.org/ (19.01.2015.)
4. A.I. Holub, Allen Holub's UML Quick Reference (UML 2.0), version 2.1.3, dostupno
na: http://www.holub.com/goodies/uml
5. D. Bell, UML basics: The sequence diagram, 2004, dostupno na:
http://www.ibm.com/developerworks/rational/library/3101.html, [pristupljeno dana
10. 10. 2012.]
6. G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide,
Addison-Wesley, 1999
7. 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 18.01.2015.)
8. M. Fowler, K. Scott, UML Distilled, 2nd ed., Addison-Wesley, 2000.
9. 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 19. 01.
2015. )
10. Rational Software Corporation, Artifact: Use-Case Model, dostupno na:
http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_ucmod.htm,
(pristupljeno dana 21.01.2015.)

25
6. POPISSLIKA

Slika 1. Prikaz klase...............................................................................................................................7

Slika 2. Aktivna klasa.............................................................................................................................7

Slika 3. Podjela dijagrama......................................................................................................................9

Slika 4. Definiranje objekta..................................................................................................................13

Slika 5. Veze izmeu objekata..............................................................................................................15

Slika 6. Definiranje klasa.....................................................................................................................16

Slika 7. Pridruivanje i podtip..............................................................................................................17

Slika 8. Pridruivanje i veze.................................................................................................................18

26