FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA – ZAGREB

Zavod za primijenjenu matematiku

Predmet: ZPM19D2 Strukturirane tehnike programiranja

Smjer: Jezgra računarstva/primijenjeno računarstvo
Šk. god. 2000/2001
Nastavnik: prof. dr. sc. Marijan Đurek

VIZUALNO MODELIRANJE OBJEKTNO

ORIJENTIRANIH SUSTAVA KORIŠTENJEM UML-A
seminarski rad

Darije Ramljak

Zagreb, listopad 2001

Kazalo:
1. UVOD............................................................................................................................3
1.1. Povijest razvoja UML-a.................................................................................................3
2. Objektno orijentirano modeliranje.................................................................................5
2.1. Modeliranje....................................................................................................................5
3. Unified modeling language (UML)...............................................................................7
3.1. Pregled UML-a..............................................................................................................7
3.1.1. UML je jezik..............................................................................................................7
3.1.2. UML je jezik za vizualiziranje...................................................................................7
3.1.3. UML je jezik za specificiranje...................................................................................8
3.1.4. UML je jezik za konstruiranje...................................................................................8
3.1.5. UML je jezik za dokumentiranje...............................................................................8
3.1.6. Gdje se sve UML može koristiti................................................................................9
4. Konceptualan model UML-a.......................................................................................10
4.1. Građevni blokovi UML-a.............................................................................................10
4.1.1. Stvari u UML-u........................................................................................................10
4.1.2. Strukturalne stvari....................................................................................................10
4.1.3. Stvari sa ponašanjem................................................................................................13
4.1.4. Grupirajuće stvari.....................................................................................................14
4.1.5. Opisne stvari............................................................................................................14
4.1.6. Relacijske stvari u UML-u.......................................................................................14
4.1.7. Dijagrami u UML-u.................................................................................................16
4.2. Pravila UML-a.............................................................................................................17
4.3. Standardni mehanizmi u UML-u.................................................................................18
4.3.1. Specifikacije.............................................................................................................18
4.3.2. Ukrasi.......................................................................................................................18
4.3.3. Podjele......................................................................................................................19
4.3.4. Mehanizmi proširivosti............................................................................................20
5. Zaključak......................................................................................................................22
Literatura..................................................................................................................................23
1. UVOD
Unified Modeling Language (UML) je grafički jezik za vizualiziranje, specificiranje,
konstruiranje i dokumentiranje sustava programske podrške. UML pruža standardiziran način
planiranja sustava, pokrivajući konceptualne stvari, kao što su poslovni procesi i funkcije
sustava, kao i konkretne stvari, među koje spadaju klase pisane u nekom programskom
jeziku, sheme baza podataka i ponovno iskoristive (eng. reusable) programske komponente.
U ovom radu bit će predstavljen UML i prikazani njegovi osnovni principi.

1.1. Povijest razvoja UML-a

Objektno-orijentirano programiranje pojavilo se negdje između sredine '70-ih i kraja '80-ih
kada su metodolozi, suočeni sa novom vrstom objektno-orijentiranih programskih jezika i
povećanom kompleksnošću aplikacija, počeli eksperimentirati sa alternativnim pristupima
analizi i dizajnu. Broj objektno-orijentiranih metoda povećao se sa nešto manje od 10 na više
od 50 u periodu između 1989 i 1994. Veliki broj korisnika tih metoda imao je puno problema
u traženju onog jezika za modeliranje koji bi u potpunosti pokrivao njihove potrebe.
Na osnovu tog iskustva počele 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). Ostale važnije
metode bile su Fusion, Shlaer-Mellor i Coad-Yourdon. 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 podršku
za "slučajeve korištenja" (eng. use-cases) kao način 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 podataka.
Kritična masa ideja počela se formirati sredinom '90-ih kada su Grady Booch (Rational
Software Corporation), Ivar Jacobson (Objectory) i James Rumbaugh (General Electric)
počeli međusobno usvajati ideje. Htjela se napraviti konverzija njihovih ideja što bi donijelo
stabilnost objektno-orijentiranom tržištu i omogućilo projektima korištenje jednog zrelog
jezika za modeliranje. Također, konverzijom tih triju metoda željela sa napraviti nova
naprednija metoda.
Službeni početak razvoja UML-a počeo je u listopadu 1994, kada se Rumbaugh udružio sa
Booch-em u Rational Software Corporation. Projekt se u početku sastojao od unifikacije
Booch-eve i OMT metode. Verzija 0.8 Unified Method (kako se u to vrijeme zvala) izašla je
u listopadu 1995. U to vrijeme je i Jacobson prešao u Rational i opseg UML-a se proširio i od
tada je obuhvaćao i OOSE. U lipnju 1996. izašla je verzija 0.9. U to se već vrijeme vidjelo da
velika većina organizacija koje proizvode programsku podršku 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 došlo 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, snažan i primjenjiv u širokom spektru domena problema. UML 1.0 je

2
ponuđen na standardizaciju OMG-u (Object Management Group) u siječnju 1997., kao
odgovor na njihov zahtjev za prijedlog standardnog jezika za modeliranje.
Između siječnja i srpnja 1997., originalna grupa se proširila i obuhvatila je sve koji su poslali
svoje prijedloge OMG-u, uključujući 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 prihvaćen od strane OMG-a u prosincu 1994.
Zadnja verzija UML-a koja je izašla je 1.3 (jesen 1998).

3
2. OBJEKTNO ORIJENTIRANO MODELIRANJE
Primarni produkt nekog razvojnog tima je dobra programska aplikacija koja zadovoljava
rastuće potrebe korisnika i njihovog poslovanja. Sve ostalo je manje važno.
Nažalost, velik broj organizacija koje proizvode programsku podršku ono "manje važno"
zamjenjuje sa "potpuno nevažno". Kako bi se izgradila programska podrška dugotrajne
kvalitete, potrebno je složiti solidnu baznu arhitekturu. Za brz i efikasan razvoj programske
podrške, 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 može vrlo lako prilagoditi stalnim promjenama tehnologije i
poslovanja.

2.1. Modeliranje
Modeliranje je glavni dio svih tih aktivnosti koje vode produkciji dobre programske podrške.
Modeliranjem se vizualizira i kontrolira arhitektura sustava. Modelira se kako bi se bolje
shvatio sustav koji se izgrađuje i često se koristi radi pojednostavljenja i mogućnosti ponovne
iskoristivosti dijelova tog istog sustava.
Modeliranje je dokazana i široko prihvaćena inžinjerska tehnika. Npr. arhitekti rabe
modeliranje kako bi olakšali projektiranje neke kuće ili zgrade. Koriste razne matematičke
modele kako bi analizirali utjecaje vjetra i potresa na stambene objekte. Naravno,
modeliranje nije vezano samo za građevinsku industriju. Bilo bi gotovo nemoguće proizvesti
novi avion ili auto bez prethodne izrade modela – od računalnih modela, fizičkih modela, koji
se testiraju u zračnim tunelima, pa sve do pravih prototipova. U stvarnom životu moguće je
naći mnogo primjera gdje se modeliranje koristi kao jedan od glavnih procesa.
Model pruža na uvid nacrte za izgradnju određenog sustava. Modeli mogu sadržavati vrlo
detaljne nacrte, kao i one generalne koji daju samo prikaz većih cjelina. Dobar model
uključuje one elemente koji imaju širok utjecaj, a zanemaruje one manje elemente koji nisu
relevatni za promatranu razinu apstrakcije. Svaki sustav može se opisati sa više aspekata
koristeći više modela pa je samim time svaki model semantički zatvorena apstrakcija sustava.
Kroz modeliranje, postižu se četiri cilja:
1. Modeli pomažu pri vizualizaciji sustava koji se promatra ili koji se želi izgraditi.
2. Modeli omogućuju specifikaciju strukture ili ponašanja sustava.
3. Modeli pružaju predloške koji služe kao vodiči pri izgradnji sustava.
4. Modeli dokumentiraju odluke koje su donesene.

Modeliranje se ne koristi isključivo u izradi velikih sustava jer čak i mali sustavi imaju koristi
od njega. Ipak, istina je da što je veći i kompleksniji sustav koji se radi to je i veća važnost
modeliranja.
U razvoju programske podrške postoji nekoliko načina pristupa modelu. Dva najčešća
pristupa su pristup sa strane algoritma i objektno-orijentirani pristup.

4
Tradicionalan pogled na razvoj programske podrške uzima pristup sa strane algoritma. U
ovom pristupu, glavni građevni elementi programa su procedure ili funkcije, a glavni fokus se
daje na stvari vezane uz kontrolu i dekompoziciju većih algoritama na manje. Ovaj način
razvoja nije loš, ali pokazuje svoje velike nedostatke pri promjenama zahtjeva na sustav. Iz
toga proizlazi da su sustavi koji su razvijani sa fokusom na algoritme vrlo teški za
održavanje.
Moderan pogled na razvoj sustava za programsku podršku koristi objektno-orijentirani
pristup. Ovdje je glavni građevni blok sustava objekt ili klasa. To je stvar koja je izvedena iz
rječnika domene problema ili rješenja; klasa je opis kolekcije objekata sa istim zajedničkim
svojstvima. Svaki objekt ima identitet (može se imenovati ili nekako drugačije razlikovati od
ostalih objekata), stanje (obično su tu pridruženi nekakvi podaci) i ponašanje (mogu se vršiti
nekakve operacije nad objektom ili on može vršiti operacije nad drugim objektima).
Objektno-orijentirani pristup zauzima centralno mjesto među pristupima razvoju programske
podrške jednostavno zato što je dokazao svoju vrijednost u razvoju sustava u raznim
domenama problema i u obuhvaćanju svih razina kompleksnosti. Nadalje, većina modernih
jezika, operativnih sustava i alata su u neku ruku objektno-orijentirani, dajući veći doprinos
objetno-orijentiranom pogledu na svijet. Objektno-orijentirani razvoj daje i konceptualne
temelje razvoju sustava kroz slaganje komponenata koristeći tehnologije poput Java Beans ili
COM+.
Iz svega ovoga proizlazi da je svrha UML-a upravo vizualiziranje, specificiranje,
konstruiranje i dokumentiranje objektno-orijentiranih sustava.

5
3. UNIFIED MODELING LANGUAGE (UML)
Unified Modeling Language (UML) je standardiziran jezik za pisanje nacrta za razvoj sustava
programske podrške. UML se koristi za vizualiziranje, specificiranje, konstruiranje i
dokumentiranje komponenata koje sačinjavaju taj sustav.
UML se može koristiti za modeliranje sustava od ranga poslovnih informacijskih sustava pa
sve do distribuiranih mrežnih aplikacija pa čak i za sustave koji rade u realnom vremenu
(eng. real time embedded systems). To je vrlo ekspresivan jezik koji se bavi svim pogledima
na sustav koji su potrebni za njihov razvoj i pokretanje.
UML je samo jezik i samim time je samo dio metode razvoja programske podrške. Neovisan
je o procesu, iako bi, optimalno, trebao biti korišten u procesu koji se temelji na slučajevima
korištenja te koji je iterativan i inkrementalan.

3.1. Pregled UML-a

Unified Modeling Language je jezik za:
 Vizualiziranje
 Specificiranje
 Konstruiranje
 Dokumentiranje
dijelova sustava programske podrške.

3.1.1. UML je jezik

Jezik pruža rječnik i pravila za kombiniranje riječi u svrhu komunikacije. Jezik za
modeliranje je jezik čiji se rječnik i pravila fokusiraju na konceptualnu i fizičku
reprezentaciju sustava. Jezik za modeliranje kao što je UML je stoga standardan jezik za
nacrte sustava programske podrške.
Modeliranje pruža razumijevanje sustava. Niti jedan model nije, sam po sebi, dovoljan, već je
često potrebno više povezanih modela kako bi se razumio i najjednostavniji sustav. Sustavi
programske podrške zahtijevaju jezik koji se bavi različitim pogledima na arhitekturu
sustava, kako se sustav razvija kroz razvojni ciklus.
Rječnik 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. Dobro definiran proces vodi korisnika u odlučivanju 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.

3.1.2. UML je jezik za vizualiziranje

Za mnoge programere, glavni način programiranja sastoji se u tome da se malo razmisli o
problemu i odmah počne pisati programski kod. Na ovaj način programer ipak malo
modelira, ali to sve drži u glavi. Također, ponekad se te ideje malo i skiciraju na ploči ili

6
papiru. Međutim, tu se javljaju neki problemi. Prvo, prenošenje tih konceptualnih ideja
nekome drugome je podložno greškama osim ako svi ne govore istim jezikom. Projekti i
organizacije najčešće rabe i razvijaju nekakav svoj jezik i nekome drugome je to možda teško
razumjeti. Drugo, neke se stvari ne mogu na jednostavan način razumjeti ako prije samog
pisanja programskog koda nije izgrađen model. Npr. hijerarhije klasa će se teško razumjeti iz
samog koda. Treće, ako programer koji je napisao neki programski kod nije svoju ideju iz
glave prenio na papir, ta bi se ideja mogla nepovratno izgubiti. U najboljem slučaju, ideja bi
se mogla djelomično iskonstruirati iz postojećeg koda.
Pisanje modela u UML-u dotiče treću stavku: Eksplicitan model poboljšava komunikaciju.
Neke se stvari najbolje modeliraju tekstualno, a neke grafički. U gotovo svim interesantnim
sustavima postoje strukture koje nadilaze ono što se može prikazati programskim jezikom.
UML je grafički jezik i time dotiče, prije spomenuti, prvi problem. UML nije samo skup
grafičkih simbola, već iza svakog simbola stoji dobro definirana semantika. Na taj način,
model koji je napravio jedan programer može jednoznačno pročitati i razumjeti drugi
programer i time se dotiče, prije spomenuti, drugi problem.

3.1.3. UML je jezik za specificiranje

U ovom kontekstu, specificiranje znači izgradnju modela koji su precizni, jednoznačni i
kompletni. UML se bavi specifikacijom svih važnih odluka analize, dizajna i implementacije
koje se moraju donijeti u razvoju i pokretanju sustava programske podrške.

3.1.4. UML je jezik za konstruiranje

UML nije vizualan programski jezik, ali njegovi modeli mogu biti direktno povezani sa
raznim programskim jezicima. To znači da je moguće mapiranje između modela u UML-u i
programskih jezika kao što su Java, C++,Visual Basic ili tablica u relacijskoj bazi ili
spremnika u objektno-orijentiranoj bazi. Na taj način su stvari, koje se najbolje predstavljaju
grafički, napravljene u UML-u, a stvari koje se najbolje predstavaljaju u tekstualnom obliku,
u programskom jeziku.
Ovo mapiranje dozvoljava tzv. inžinjerstvo unaprijed (eng. forward engineering): Generaciju
koda iz UML modela u programski jezik. Unatrag je također moguće: Moguće je
rekonstruirati UML model iz već postojećeg koda. Inžinjerstvo unatrag (eng. reverse
engineering) nije svemoguće i ako se informacija ne ukodira u implementaciju, ta informacija
je izgubljena kada se ponovno generira kod iz modela. Iz toga se može zaključiti da
inžinjerstvo unatrag zahtijeva ljudsku intervenciju. Kombiniranjem ta dva načina generacije
koda i modela dobiva se tzv. inžinjerstvo u krug (eng. roud-trip engineering), što daje
mogućnost rada i u grafičkom i u tekstualnom načinu dok se alat brine za konzistentnost
podataka.
Uz direktno mapiranje, UML je dovoljno ekspresivan i jednoznačan da dozvoljava direktno
izvođenje modela, simulacije sustava i instrumentaciju sustava u radu.

3.1.5. UML je jezik za dokumentiranje

Iz prave programerske organizacije, uz sam izvršni kod, na tržište izlaze i razne dodatne
stvari kao što su:

7
  Zahtjevi na sustav
 Arhitektura
 Dizajn
 Programski kod
 Projektni planovi
 Testovi
 Prototipovi
Ovisno o samoj kulturi razvoja programske podrške, neke od tih stvari tretirane su manje ili
više formalno od drugih. Takve stvari nisu samo popratne stvari uz sam sustav, već su one,
također, vrlo važne u kontroli, mjerenju i komunikaciji o sustavu u toku njegovog razvoja i
nakon pokretanja.
UML se bavi dokumentacijom arhitekture sustava i svim njenim detaljima. UML, također,
pruža jezik za artikuliranje zahtjeva na sustav i testove. Na kraju, UML pruža jezik za
modeliranje aktivnosti planiranja projekta i upravljanja načinima puštanja u rad.

3.1.6. Gdje se sve UML može koristiti

UML je prvenstveno namijenjen sustavima koji se oslanjaju na programsku podršku. Vrlo se
efikasno koristi u slijedećim domenama:
 Poslovni informacijski sustavi
 Bankarske i financijske usluge
 Telekomunikacije
 Transport
 Obrana/avionautika
 Prodaja
 Medicinska elektronika
 Znanost
 Distribuirane mrežne usluge
UML nije ograničen samo na modeliranje programske podrške. Ustvari, dovoljno je
ekspresivan i za modeliranje ostalih sustava, kao što su tok podataka i dokumenata u
pravnom sustavu, struktura i ponašanje zdravstvenog sustava pacijenta, i dizajn sklopovlja.

8
4. KONCEPTUALAN MODEL UML-A
Za razumijevanje UML-a, potrebno je formirati konceptualan model jezika i to zahtijeva
učenje tri glavna elementa: osnovne građevne blokove UML-a, pravila koja diktiraju kako
koristiti i slagati te blokove i neke osnovne mehanizme koji se primjenjuju kroz UML.

4.1. Građevni blokovi UML-a

Rječnik UML-a obuhvaća tri tipa građevnih blokova:
1. Stvari
2. Relacije
3. Dijagrame
Stvari su apstrakcije i one su glavni dijelovi UML-a. Relacije povezuju te iste stvari, a
dijagrami grupiraju interesantne kolekcije tih stvari.

4.1.1. Stvari u UML-u

Postoje četiri vrste stvari u UML-u:
1. Strukturalne stvari (eng. structural things)
2. Stvari sa ponašanjem (eng. behavioral things)
3. Grupirajuće stvari (eng. grouping things)
4. Označavajuće stvari (eng. annotational things)
Te stvari su osnovni objektno-orijentirani građevni blokovi UML-a i koriste se za pisanje
dobro formiranih modela.

4.1.2. Strukturalne stvari

Strukturalne stvari su imenice u UML modelima. To su najčešće statički dijelovi modela i
oni predstavljaju elemente koji su ili konceptualni ili fizički. U UML-u postoji sedam tipova
strukturalnih stvari.
Prvi od njih je klasa koja predstavlja opis skupa objekata koji dijele iste atribute, operacije,
relacije i semantiku. Klasa može implementirati jedno ili više sučelja (eng. interface).
Grafički, klasa je prikazana kao pravokutnik koji obično sadrži ime, atribute i operacije kao
na slici Slika 1.

9
 Slika 1: Klasa
Drugi tip je sučelje. To je je kolekcija operacija koja specificira usluge neke klase ili
komponente. Sučelje stoga predstavlja izvana vidljivo ponašanje tog elementa i može
predstavljati kompletno ponašanje klase ili komponente ili samo djelomično. Sučelje definira
skup operacijskih specifikacija (tj. njihovih potpisa), ali nikada skup njihovih implementacija.
Grafički, sučelje je predstavljeno krugom zajdeno sa njegovim imenom (Slika 2.). Sučelje,
prema svojoj namjeni, nikada neće stajati samo, već će obično biti vezano za određenu klasu
ili komponentu koja ga realizira.

Slika 2: Sučelje
Treći tip je suradnja (eng. collaboration). Ono definira interakciju te je skup uloga (eng.
roles) i ostalih elemenata koji zajednički rade i pružaju nekakvo kooperativno ponašanje koje
je veće nego suma svih elemenata zajedno. Stoga, suradnja ima strukturalnu dimenziju kao i
dimenziju ponašanja. Neka klasa može participirati u više suradnji odjednom i suradnje time
reprezentiraju implementaciju predložaka (eng. patterns) koji čine sustav. Grafički, suradnja
je predstavljena elipsom sa isprekidanim linijama i obično se u njoj nalazi njeno ime, kao na
Slici 3.

Slika 3: Surađivanje
Četvrti tip je slučaj korištenja (eng. use case). On opisuje skup slijednih događaja koje sustav
izvodi kako bi dobio neki rezultat i koristi se za strukturiranje stvari sa ponašanjem u samom
modelu. Slučaj korištenja se u modelu realizira već spomenutim tipom: suradnjom. Grafički,
slučaj korištenja je predstavljen elipsom kao na Slici 4.

10
 Slika 4: Slučaj korištenja
Preostala tri tipa – aktivne klase, komponente i čvorovi – slični su klasama jer opisuju skup
objekata koji dijele iste atribute, operacije, relacije i semantiku. Ipak, ova tri tipa su dovoljno
različita i neophodna za modeliranje određenih aspekata objektno-orijentiranih sustava da se
ne smiju zaobići u opisu.
Peti tip je aktivna klasa (eng. active class). To je klasa čiji objekti posjeduju jedan ili više
procesa ili niti i time mogu inicirati neku kontrolnu aktivnost. Slična je samoj klasi osim što
njeni objekti predstavljaju elemente čije ponašanje je konkurentno sa ostalim elementima.
Grafički, predstavlja se kao i normalna klasa, ali sa podebljanim linijama, kao na Slici 5.

Slika 5: Aktivna klasa

Preostala dva tipa predstavljaju fizičke stvari, za razliku od prethodnih pet koji su
predstavljali konceptualne ili logičke stvari.
Šesti tip je komponenta (eng. component) i predstavlja fizički i zamjenjivi dio sustava koji se
prilagođava skupu sučelja i pruža njihovu realizaciju. U sustavu se mogu sresti mnoge razne
komponente kao što su COM+ komponente, zatim JavaBeans komponente kao i ostale
komponente koje su dio razvojnog procesa, kao datoteke programskog koda. Komponenta
tipično predstavlja fizičko pakiranje inače logičkih elemenata kao što su klase, sučelja i
surađivanja. Grafički, komponenta se prikazuje kao pravokutnik sa hvataljkama, kao na Slici
6.

Slika 6: Komponenta
Sedmi tip je čvor (eng. node). To je fizički element koji postoji pri radu sustava i predstavlja
računalni resurs i obično ima neku memoriju i procesne mogućnosti. Unutar čvora može se
smjestiti skup komponenata, a komponente mogu, također, seliti se sa čvora na čvor.
Grafički, čvor je predstavljen kockom, kao na Slici 7.

11
 Slika 7: Čvor
Ovih sedam tipova elemenata – klase, sučelja, suradnje, slučajevi korištenja, aktivne klase,
komponente i čvorovi – su osnovne strukturalne stvari koje se mogu uključiti unutar UML
modela. Uz ove osnovne, postoje također i njihove varijacije, kao što su glumci (eng. actors),
signali, procesi i niti (oblici aktivnih klasa), aplikacije, dokumenti, datoteke, biblioteke,
stranice i tablice (oblici komponenti).

4.1.3. Stvari sa ponašanjem

Stvari sa ponašanjem su dinamički diojelovi UML modela. To su glagoli modela i
predstavljaju ponašanje kroz prostor i vrijeme. Postoje, sve skupa, samo dva primarna tipa
stvari sa ponašanjem.
Prvi od njih je interakcija. Interakcija je ponašanje koje obuhvaća skup poruka koji se
izmjenjuje u skupu objekata unutar nekog određenog konteksta s određenom svrhom.
Ponašanje skupa objekata ili individualne operacije može se specificirati interakcijom.
Interakcija uključuje i brojne druge elemente kao što su poruke, slijedovi akcija (ponašanje
pokrenuto porukom) i veze između objekata. Grafički, poruka je predstavljena kao linija sa
strelicom u jednom smjeru i najčešće uključuje i ime operacije, kao na Slici 8.

Slika 8: Interakcija
Drugi je automat stanja (eng. state machine). Automat stanja je ponašanje koje specificira
slijed stanja objekta ili interakcije kroz koje prolazi za vrijeme svog života kao odgovor na
neki događaj, zajedno sa odgovorom na taj događaj. Ponašanje pojedine klase ili suradnje
klasa može biti specificirana automatom stanja. Automat stanja uključuje i brojne druge
elemente, kao što su stanja, tranzicije (prijelazi između dva stanja), događaje (stvari koje
okidaju tranziciju) i aktivnosti (odgovori na tanziciju). Grafički, stanje je predstavljeno
pravokutnikom zaobljenih rubova (kao na Slici 9.) i obično uključuje ime stanja i njegova
podstanja.

Slika 9: Stanje

12
Ova dva elementa – interakcije i automati stanja – su osnovne stvari sa ponašanjem koje se
mogu uključiti unutar UML modela. Semantički gledano, ti elementi su obično povezani sa
različitim strukturalnim elementima, prvenstveno klasama, suradnjama i objektima.

4.1.4. Grupirajuće stvari

Grupirajuće stvari su organizacijski dio UML modela. To su "kutije" u koje se može razložiti
UML model i postoji samo jedan tip grupirajućih stvari, a to su paketi (eng. packages).
Paket je mehanizam opće namjene za organiziranje elemenata u grupe. Strukturalne stvari,
stvari sa ponašanjem pa čak i druge grupirajuće stvari mogu se smjestiti u paket. Za razliku
od komponenata (koje postoje za vrijeme izvođenja), paket je čisto konceptuale prirode (što
znači da postoji samo za vrijeme razvoja). Grafički, paket je prikazan kao pravokutnik sa
hvataljkom (eng. tabbed folder) kako je prikazano na Slici 10. i obično sadrži ime i, ponekad,
svoj sadržaj.

Slika 10: Paket

Paketi su osnovne grupirajuće stvari kojima je moguće organizirati UML model. Također,
postoje i varijacije, kao kosturi (eng. frameworks), modeli i podsustavi (tip paketa).

4.1.5. Opisne stvari

Opisne stvari su dijelovi UML modela koji daju neku vrstu objašnjenja. To su komentari koji
se mogu primijeniti kako bi se opisalo, naglasilo ili dalo primjedbu na neki element unutar
UML modela. Postoji samo jedan glavni tip opisnih stvari, a to je cedulja (eng. note). Cedulja
je, jednostavno, simbol za pisanje ograničenja i komentara i vezana je za neki element ili
kolekciju elemenata u UML modelu. Grafički, cedulja se predstavlja kao pravokutnik sa
zavrnutim rubom, zajedno sa tekstualnim ili grafičkim komentarom, kao na slici 11.

Slika 11: Cedulja

Ovaj element je osnovna opisna stvar koju je moguće koristiti u UML modelu. Cedulje se
tipiđno koriste za pisanje ograničenja uz dijagrame ili za pisanje tekstualnih komentara.
Postoje, također, i varijecije ovog elementa, kao što su zahtjevi na sustav (oni specificiraju
neko željeno ponašanje iz vanjske ili korisničke perpektive).

4.1.6. Relacijske stvari u UML-u

Postoje četiri tipa relacija unutar UML modela:

13
 1. Ovisnosti (eng. dependency)
2. Asocijacije (eng. association)
3. Generalizacije (eng. generalization)
4. Realizacije (eng. realization)
Ove su relacije osnovni relacijski građevni blokovi u UML-u i koriste se za pisanje dobro
formiranih UML modela.
Prvi tip, ovisnost, je semantička relacija između dvije stvari u kojoj promjena u jednoj
(neovisnoj stvari) može utjecati na semantiku druge (ovisne stvari). Grafički, ovisnost se
prikazuje kao isprekidana linija, sa mogućom oznakom direkcije (strelica) i imenom, kao na
Slici 12.

Slika 12: Ovisnost

Drugi tip, asocijacija, je strukturalna relacija koja opisuje skup veza između objekata.
Kombinacija (eng. aggregation) je specijalan oblik asocijacije i reprezentira strukturalnu
relaciju između cjeline i njenih dijelova. Grafički, asocijacija se predstavlja kao puna linija,
uz mogućnost određivanja smjera, i ponekad sadrži i dodatne stvari kao n-arnost i ime.
Prikazana je na Slici 13.

Slika 13: Asocijacija

Treći tip, generalizacija (eng. generalization), je relacija specijalizacije/generalizacije u kojoj
objekti specijaliziranih elemenata (djeca) se mogu zamijeniti objektima generaliziranih
elemenata (roditelja). Na ovaj način, djeca dijele strukturu i ponašanje roditelja. Grafički,
relacija generalizacije se prikazuje kao puna linija sa šupljom strelicom koja pokazuje prema
roditelju, kao na Slici 14.

Slika 14: Generalizacija

Četvrti tip, realizacija (eng. realization), je semantička relacija između klasifikatora, gdje
jedan klasifikator specificira ugovor koji drugi klasifikator garantira izvršiti. Realizacija se
susreće na dva mjesta: između sučelja i klasa ili komponenata koje ih realiziraju, i između

14
slučajeva korištenja i suradnji koje ih realiziraju. Grafički, realizacija se prikazuje kao
prijelaz između generalizacije i relacije ovisnosti, kao na Slici 15.

Slika 15: Realizacija

Ova četiri elementa su osnovne relacijske stvari koje se mogu uključiti u UML model.
Postoje, također, i njihove varijacije, kao što su uključivanje (eng. include), proširenje (eng.
extend), rafiniranje (eng. refinement), i praćenje (eng. trace).

4.1.7. Dijagrami u UML-u

Dijagram je grafička prezentacija skupa elemenata, najčešće prikazanih kao povezani grafovi
vertikala (stvari) i lukova (relacije). Dijagrami se crtaju kako bi se vizualizirao sustav iz
različitih perspektiva, pa to čini dijagram nekom vrstom projekcije u sustav. Za gotovo sve
sustave, osim onih vrlo jednostavnih, dijagrami predstavljaju poboljšani prikaz elemenata
koji čine sustav. Isti elementi mogu se pojaviti u svim dijagramima, nekim dijagramima
(najčešći slučaj) ili se uopće ne pojaviti (jako rijetko). Teoretski, dijagram može sadržavati
bilo koju kombinaciju stvari i relacija u modelu. U praksi, međutim, 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 podršku. Stoga, UML uključuje devet
takvih dijagrama:
1. Dijagram klasa
2. Dijagram objekata
3. Dijagram slučajeva korištenja
4. Dijagram toka
5. Dijagram suradnji
6. Dijagram stanja
7. Dijagram aktivnosti
8. Dijagram komponenata
9. Dijagram pokretanja
Dijagram klasa prikazuje skup klasa, sučelja i suradnji i njihove međusobne relacije. Ti
dijagrami su najčešći u objektno-orijentiranim sustavima. Dijagrami klasa bave se statičkim
pogledom na dizajn sustava, a oni koji uključuju i aktivne klase, bave se i statičkim pogledom
na procese u sustavu.
Dijagram objekata prikazuje skup objekata i nihove relacije u sustavu. Dijagrami objekata
predstavljaju statičku snimku instanci stvari koje se nalaze u dijagramu klasa. Oni se bave
statičkim pogledom na dizajn i procese sustava, kao i dijagrami klasa, ali iz perspektive
pravih prototipova, tj. pravih objekata u sustavu.
Dijagram slučajeva korištenja prikazuje skup slučajeva korištenja i glumaca (eng. actors –
specijalan tip klase) i njihovih relacija. Dijagrami slučajeva korištenja bave se statičkim

15
pogledom na slučajeve korištenja u sustavu i vrlo su važni kod organiziranja i modeliranja
ponašanja 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 između njih. Interakcijski dijagram bavi se dinamičkim
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 znači da se svaki od njih može lako transformirati u drugi.
Dijagam stanja prikazuje automat stanja, koji se sastoji od stanja, prijelaza, događaja i
aktivnosti i bavi se dinamičkim pogledom na sustav. Dijagrami stanja su vrlo važni u
modeliranju ponašanja sučelja, klasa ili suradnji i daju naglasak na ponašanje objekta
određeno slijedom događaja, što je jako korisno u modeliranju reaktivnih sustava.
Dijagram aktivnosti je specijalan tip dijagrama stanja koji pokazuje tok iz aktivnosti u
aktivnost unutar sustava i bavi se dinamičkim pogledom na sustav. Vrlo su važni u
modeliranju funkcija sustava i daju naglasak na tok kontrole između objekata.
Dijagram komponenata prikazuje organizacije i ovisnosti između skupa komponenata.
Dijagrami komponenata bave se statičkim pogledom na implementaciju sustava. Povezani su
sa dijagramima klasa tako da su komponente tipično mapirane na jednu ili više klasa, sučelja
ili suradnji.
Dijagram pokretanja prikazuje konfiguraciju izvršnih procesnih čvorova i komponenata koje
se izvode na njima. Dijagrami pokretanja bave se statičkim pogledom na pokretanje
arhitekture sustava. Povezani su sa dijagramima komponenata tako da čvor tipično obuhvaća
jednu ili više komponenata.

4.2. Pravila UML-a

Građevni blokovi UML-a ne mogu se samo nabacati kako bi tvorili model. Kao i svaki jezik,
i UML ima brojna pravila koja specificiraju kako dobro formiran model treba izgledati.
Dobro formiran model je semantički konzistentan i u skladu je sa svim drugim modelima sa
kojima je povezan.
UML ima semantička pravila za:
 Imena Kako se mogu nazivati stvari, relacije i dijagrami
 Doseg Kontekst koji daje specifično značenje imenu
 Vidljivost Kako ta imena mogu vidjeti i koristiti drugi korisnici
 Integritet Kako stvari na pravi način i konzistentno povezati sa drugima
 Izvođenje Što znači pokrenuti ili simulirati dinamički model
Modeli koji se grade za vrijeme razvoja sustava koji se oslanja na programsku podršku teže
ka povećanju i mogu ih vidjeti razni korisnici u različito vrijeme i na različit način. Stoga
razvojni timovi ne grade samo dobro formirane modele već i modele koji su:
 Neotkriveni Neki elementi su sakriveni kako bi se pojednostavnio pogled

16
  Nekompletni Neki elementi mogu nedostajati
 Nekonzistentni Integritet modela nije garantiran
Ovi, ne dobro formirani modeli, su neizbježni u toku razvoja dok se mnogi detalji sustava tek
otkrivaju. Pravila UML-a potiču, ali ne prisiljavaju na bavljenje najvažnijim pitanjima
analize, dizajna i implementacije koji usmjeravaju model da, kroz vrijeme, postane dobro
formiran.

4.3. Standardni mehanizmi u UML-u

Izgrađivanje modela je jednostavnije ako postoji konformizam prema nekim predlošcima koji
imaju standardna zajednička svojstva. Tako je i sa UML-om jer u njemu postoje četiri
standardna mehanizma čijom primjenom se dobiva konzistentnost kroz sam jezik.
1. Specifikacije (eng. specifications)
2. Ukrasi (eng. adornments)
3. Podjele (eng. common divisions)
4. Mehanizmi proširivosti (eng. extensibility mechanisms)

4.3.1. Specifikacije
UML je puno više od samog grafičkog jezika jer iza svake grafičke notacije stoji specifikacija
koja daje tekstualan opis sintakse i semantike tog građevnog bloka. Npr. iza ikone klase stoji
specifikacija koja pruža cijeli skup atributa, operacija i ponašanja koja ta klasa sadržava;
vizualno, ta klasa može prikazati samo manji dio te specifikacije. Grafička notacija UML-a
koristi se za vizualizaciju sustava, a specifikacija UML-a koristi se za opis detalja tog
sustava. S obzirom na ovu podjelu, moguće je graditi model inkrementalno, crtajući
dijagrame i nakon toga dodavati semantiku specifikaciji modela, ili direktno kreirajući
specifikaciju (možda čak i korištenjem inžinjerstvom unatrag već postojećeg sustava) i nakon
toga kreirati dijagrame koji su projekcija u te specifikacije.
Specifikacije UML-a pružaju semantičku pozadinu koja sadržava sve dijelove modela sustava
i gdje je su svi dijelovi na konzistentan način povezani. UML dijagrami su stoga samo
vizualne projekcije na tu pozadinu, gdje svaki dijagram otkriva specifičan aspekt sustava.

4.3.2. Ukrasi
Većina elemenata u UML-u ima jednoznačnu i izravnu grafičku notaciju koja pruža vizualnu
reprezentaciju najvažnijih aspekata tog elementa. Npr. notacija za klasu je namjerno
dizajnirana jednostavnom za crtanje jer su klase najčešči elementi koji se nalaze u
modeliranju objektno orijentiranih sustava. Notacija za klasu također daje na uvid i
najvažnije aspekte klase, a to su ime, atributi i operacije.
Specifikacija klase može uključivati i ostale detalje, kao što su: da li je klasa apstraktna, ili
vidljivost njenih atributa i operacija i sl. Mnogi od ovih detalja mogu se prikazati kao grafički
ili tekstualni ukrasi samoj notaciji klase (pravokutnik). Npr. Slika 16 prikazuje klasu koja je
ukrašena kako bi se naglasilo da je klasa apstraktna i da sadrži dvije javne (eng. public),
jednu zaštićenu (eng. protected) i jednu privatnu (eng. private) operaciju.

17
 Slika 16: Ukrasi
Svaki element u UML notaciji počinje sa osnovnim simbolom, kojem se mogu dodati razni
ukrasi specifični za taj simbol.

4.3.3. Podjele
Pri modeliranju objektno orijentiranih sustava, sve se često dijeli na više načina.
Prvo, tu je podjela na klase i objekte. Klasa je apstrakcija, a objekt je konkretna manifestacija
te apstrakcije. U UML-u mogu se modelirati i klase i objekti, kao što je prikazano na Slici 17.

Slika 17: Klase i objekti

Na ovoj slici je jedna klasa, nazvana Customer, zajedno sa tri objekta: John (koji je
eksplicitno naveden kao Customer objekt), :Customer (anonimni Customer objekt) i Jack (za
kojeg je u specifikaciji navedeno da je Customer objekt, iako to nije eksplicitno navedeno).
Gotovo svi građevni blokovi UML-a imaju sličnu razliku kao klase i objekti. Npr. postoje
slučajevi korištenja i njihove instance, komponente i njihove instance, čvorovi i njihove
instance, itd. Grafički, UML razlikuje objekte koristeći iste simbole kao i za klase i
potcrtavajući samo ime objekta.
Drugo, postoji separacija sučelja od implementacije. Sučelje deklarira ugovor, a
implementacija predstavlja konkretnu realizaciju tog ugovora i odgovorna je za točno
izvršavanje kompletne semantike sučelja. U UML-u mogu se modelirati i sučelja i
implementacije, kao na Slici 18.

18
 Slika 18: Sučelja i implementacije
Na ovoj slici je jedna komponenta, nazvana spellingwizard.dll koja implementira dva sučelja,
IUnknown i ISpelling.
Gotovo svi građevni blokovi u UML-u imaju sličnu razliku kao sučelja i implementacije.
Npr. postoje slučajevi korištenja i suradnje koje ih realiziraju, kao i operacije i metode koje ih
implementiraju.

4.3.4. Mehanizmi proširivosti

UML pruža standardan jezik za pisanje nacrta za sustave programske podrške, ali nemoguće
je, za jedan jezik, da ikada bude dovoljan kako bi izrazio sve moguće dijelove modela u svim
mogućim domenama u vremenu. Iz tog razloga, UML je otvoren i lako ga je kontrolirano
proširiti. UML-ovi mehanizmi proširivosti uključuju:
 Stereotipe (eng. stereotypes)
 Označene vrijednosti (eng. tagged values)
 Ograničenja (eng. constaints)
Stereotip proširuje rječnik UML-a, omogućavajući kreiranje novih vrsta građevnih blokova
koji su izvedeni iz već postojećih, ali su specifični za neki problem. Npr. ako se programira u
jezicima kao što su Java i C++, često postoji potreba za modeliranjem iznimaka (eng.
exceptions). U tim jezicima, iznimke su, jednostavno, klase, iako se s njima postupa na
specijalan način. Tipično, želi se samo mogućnost bacanja i hvatanja iznimaka, ništa više.
Stereotipovi ovdje dolaze u pomoć dajući mogućnost pretvaranja iznimke (kao klase) u
poseban građevni blok. Klasa koja se želi tako unaprijediti označi se sa određenim
stereotipom, kao klasa Overflow na Slici 19.
Označene vrijednosti proširuju svojstva građevnih blokova UML-a, omogućavajući kreiranje
novih informacija u specifikaciji tog elementa. Npr. pri izradi nekog programa za kojeg
postoji velik broj izmjena javlja se potreba za označavanjem verzija i autora nekih kritičnih
apstrakcija u tom programu. Verzije i autori ne postoje kao primitivi u konceptu UML-a.
Moguće ih je dodati svakom građevnom bloku, kao klasi, uvodeći nove označene vrijednosti
tom bloku. Na Slici 19, klasa EventQueue je proširena eksplicitnim označavanjem autora i
verzije.
Ograničenja proširuju semantiku građevnih blokova UML-a, omogućavajući dodavanje
novih pravila ili mijenjanje već postojećih. Npr. ograničavanje klase EvenQueue na taj način

19
da sve što se doda u nju mora biti poredano. Na Slici 19, prikazano je eksplicitno dodavanje
ograničenja na operaciju add().

Slika 19: Mehanizmi proširivosti

Sva tri navedena mehanizma proširivosti omogućuju oblikovanje UML-a kako bi
zadovoljavao potrebe projekta. Oni, također, daju UML-u sposobnost adaptiranja na nove
tehnologije izrade programske podrške, kao što je pojava novih i moćnijih distribuiranih
programskih jezika. Moguće je dodavanje novih građevnih blokova, modificiranje
specifikacije već postojećih, pa čak i mijenjanje njihove semantike. Naravno, sva proširenja
UML-a moraju biti strogo kontrolirana kako se na bi mijenjala osnovna namjena UML-a, a to
je - komunikacija informacija.

20
5. ZAKLJUČAK
U ovom seminarskom radu prikazane su osnove UML-a, jezika za vizualno modeliranje, i
opisani su njegovi principi i semantika. Dan je i pregled njegove povijesti razvoja kako bi se
vidjelo da je nastao kao evolucija raznih objektno orijentiranih metoda.
Iz svega što je do sad napisano može se zaključiti da je UML trenutno najbolji jezik za
vizualno modeliranje i moglo bi se reći da niti nema neku dostojnu konkurenciju. Ne postoji
jezik koji je toliko kompletan kao UML, a istovremeno i neovisan o razvojnom procesu. To
znači da je UML vrlo prilagodljiv jezik i moguće je koristiti samo neke njegove dijelove u
razvojnom procesu, a da se ne reduciraju njegove velike mogućnosti. Neovisnost o
razvojnom procesu daje veliku fleksibilnost razvojnim timovima koji mogu zadržati svoje
dosadašnje procese prilagođavajući UML svojim potrebama, istovremeno ih poboljšavajući i
modernizirajući.
UML svoju najveću snagu pokazuje na velikim projektima u kojima sudjeluje velik broj ljudi
jer je komunikacija o sustavu koji se gradi gotovo dovedena do savršenstva i nije teško
uključiti nove ljude na taj projekt ako razumiju UML.
Proširivost UML-a i njegove semantike omogućuje mu prilagodljivost novim programskim
jezicima čime se osigurava njegova budućnost i time se razvojnim timovima daje alat za koji
znaju da će ga moći koristiti dugi niz godina.
Sve to čini UML vrlo korisnim i prilagodljivim alatom za vizualno modeliranje sustava
programske podrške i danas postaje gotovo neizbježan pomoćnik svakom programeru i
dizajneru sustava.

21
LITERATURA
I. Jacobson, M. Christerson, P. Jonsson, G. Overgaard: Object–Oriented Software
Engineering – A Use Case Driven Approach, Addison-Wesley, Reading, Massachusetts,
1992.
Rational Software Team: Using Rose – Rational Rose 2000e, Rational Software Corporation,
2000.
T. Quatrani: Visual Modeling with Rational Rose 2000 and UML, Addison-Wesley, Reading,
Massachusetts, 2000.
G. Booch, I. Jacobson, J. Rumbaugh: The Unified Modeling Language User Guide, Addison-
Wesley, Reading, Massachusetts, 1998.
D. Rosenberg, K. Scott: Use Case Driven Object Modeling with UML, Addison-Wesley,
Reading, Massachusetts, 1999.

22
23