1.

UVOD

Tempo u savremenom poslovnom svijetu postaje sve brži, i raste potreba da se zahtjevi
tržišta prihvate, dostignu i pobijede.Tradicionalni načini razvoja sistema jednostavno nisu
odgovarajući. S obzirom da preovladava E-biznis, E-trgovina i drugi E sistemi, današnji
sistem mora biti razvijen na osnovu zahtjeva „Internet vremena“ i treba da bude veoma
fleksibilan u odnosu na okruženje i promjene. Zahtjev za promjenu, upućen nekom IT
odjeljenju zahtijeva ujedno i odgovor za najmanje sedam dana. Zahtjevi menadžera i
samih korisnika primorali su programerske firme da pronalaze najbolja rješenja i da
promjene u sistemu predvide i odrade brzo. Samo takav pristup održaće ih na
beskompromisnom tržištu. Strukturno programiranje je do skora bilo osnova za razvoj
softvera. Programeri su pisali standardne linije koda kako bi izveli operacije poput
štampanja, a onda su taj kod kopirali u sve aplikacije koje su pisali, kad im je bilo
potrebno da izvedu tu operaciju. Uspjelo se smanjiti vrijeme razvoja novih aplikacija, ali
su problemi nastajali kad je bilo potrebno izmijeniti kod koji je kopiran, zato što je to
zahtijevalo izmjenu u svim aplikacijama u kojima je taj kod kopiran. Objektno-
orjentisano programiranje upravo ima za cilj da ove probleme koji su stvoreni
struktuiranim programiranjem riješi. U objektno-orjentisanom programu programeri
kreiraju blokove koda koji se zovu objekti i koriste se od strane različitih aplikacija. Ako
jedan od objekata treba modifikovati, programer tu promjenu treba da uradi samo
jednom. Objektno-orjentisana paradigma je drugačije viđenje aplikacije. Sa objektno
orjentisanim pristupom aplikaciju dijelimo na mnoštvo malih dijelova, ili objekata, koji
su prilično nezavisni jedan od drugog. Aplikacija se razvija tako što se objekti povezuju u
jednu jedinstvenu cjelinu. Osnovna prednost OO programiranja je mogućnost izgradnji
komponenti samo jednom i njihovo ponovno korištenje. Primjenom OO pristupa mogu da
se razviju elastični sistemi koji su fleksibilni kako na promjene informacija tako i na
promjene u samom sistemu. Uopšte kada se želi napraviti novi savremeni sistem,
sakupljaju se zahtjevi, uobzire se sve potrebe korisnika koje se mogu razumjeti i iz njih
se pokuša generisati kod. Započeće se proces modelovanja, koji predpostavlja da se kod
vezuje za zahtjev, odnosno da se zahtjev susreće sa kodom. Ako želimo npr. da
napravimo program koji će računati kvadratnu jednačinu, potrebno je zadati kvadratnu
jednačinu, znati kako se rješava, a zatim i znati kako se programira u određenom
programu. Konstrukcija kvadratne jednačine u glavi, prije nego što dobijeni zadatak
ukucamo u kod, je u stvari modelovanje. Ako je zadatak koji treba riješiti složenije

1
prirode od kvadratne jednačine, čija realizacija prelazi okvire mogućnosti jednog čovjeka,
javlja se potreba za timskim radom. Tu stupa na snagu UML, Unified Modeling
Language. Cilj pri korištenju UML-a za poslovne procese, za razvoj aplikacija i
modelovanje baza podataka jeste da se povežu razvojni timovi i da se osigura da
organizacije ne prave arhitekture preduzeća bez uključivanja svih timova od značaja za
taj proces.

2
 2.UML

Objedinjen jezik za modelovanje, UML, jeste skup grafičkih notacija zasnovanih na

jedinstvenom metamodelu, a služi za opisivanje i projektovanje softverskih sistema,
naročito onih koji su napravljeni primjenom u objektno orjentisanih tehnologija. [1]
Nastao je objedinjavanjem više objektno orjentisanih grafičkih jezika za modelovanje,
koji su razvijeni kasnih osamdesetih i ranih devedesetih godina prošlog vijeka. Graddy
Booch, Ivar Jacobson i Jim Rumbaugh su tvorci jeika UML, koji je 1997. godine, postao
standard Grupe za upravljanje objektima, Objekt Management Group, OMG. Nastao je
kao ideja da se napravi objedinjen jezik za modelovanje koji će omogućavati razmjenu
modela između CASE alata. UML omogućuje da se specifikuju, vizuelizuju i
dokumentuju modeli softverskih sistema u skladu sa postavljenim zahtjevima. Njime nije
moguće samo modelovati neki program, već je moguće pratiti razvoj bilo kakvog objekta,
građevine, voćnjaka.
Mogu se istaći ciljevi kojima UML kao jezik teži:
 Pružiti korisniku brz jezik za vizuelno modelovanje kojim će moći u
relativno kratkom vremenu napraviti i razmjenjivati modele sa
određenim značenjem.
 Pružiti korisniku mogućnost proširenja i stvaranja specijalizovanih
dijelova
 Biti nezavisan od programskih jezika i razvojnih procesa
 Pružiti formalne osnove za razumijevanje jezika za modelovanje
 Podsticanje rasta i razvoja objektno orjentisanih programskih jezika
 Podrška visoko pozicioniranih razvojnih pojmova kao što su saradnja,
okvirni rad, uzorci i komponente

UML je razvijen sa ciljem da pojednostavi veliki broj objektno orjentisanih razvojnih

metoda. Definišu ga notacija (sintaksa) i metamodel (semantika). Notacija je skup
grafičkih elemenata koji se koriste u modelima; to je grafička sintaksa jezika za
modelovanje.
UML je i osnovni jezik arhitekture MDA, arhitekture zasnovane na modelu, Model
Driven Architekture, u okviru kojeg se aplikacija može predstaviti kao:
 model nezavisan od platforme Platform Independent Model, PIM
To je UML model koji je nezavisan od tehnologije.

3
  model za specifičnu platformu Platform Specifik Model, PSM
Model sistema namijenjen određenom izvršnom okruženju. Drugi alati zatim prave kod
za tu platformu na osnovu modela PSM.

2.1.STRUKTURA UML-a

UML se sastoji od niza pogleda na arhitekturu (Architectural Views) koji zavise od

problema i rješenja, a dijele se na:
 Pogled korištenja (use case view) pokazuje problem i rješenje onako kako ga
vide oni koji postavljaju problem, odnosno definišu se zahtjevi sa stanovišta
korisnika.
 Logički pogled (logical view) pogled pokazuje strukturnu dimenziju problema
rješenja
 Pogled paralelnog rada (concurrency view) pokazuje dimenziju ponašanja
problema i rješenja, a naziva se još i dinamički pogled.
 Pogled na komponente (component view) pokazuje strukturu i ponašanje
realizacije rješenja, a naziva se i razvojni pogled.
 Pogled postavljanja (deployment view) pokazuje strukturu i ponašanje domena
u kome je rješenje ostvareno, a naziva se još i fizički pogled ili pogled na
razmještaj.

Svaki od pogleda opisan je pomoću jednog od trinaest UML dijagrama. Za gotovo sve
sisteme dijagrami predstavljaju poboljšani prikaz elemenata koji čine sistem.

Dijagram Svrha
Aktivnosti Proceduralno i paralelno ponašanje
Klasa Klase, osobine, veze
Komponenata Strukture i veze između komponenti
Komunikacije Interakcija između objekata sa naglaskom na vezi
Mašine stanja Kako događaji mijenjaju objekat
Objekata Primjer konfigurisanja instanci
Paketa Hijerarhijska struktura za vrijeme kompajliranja
Pregleda interakcije Kombinacija dijagrama sekvence i aktivnosti
Raspoređivanja Raspoređivanje artefakta po čvorovima
Sekvence Interakcija između objekata
Složene strukture Razlaganje klasa tokom izvršavanja
Slučajeva korištenja Interakcija korisnika i sistema
Vremenski Interakcija između objekata

Tabela 2. Vrste dijagrama

4
Da bi se mogli pojedinačno predstaviti navedeni dijagrami potrebno je prvo upoznati
njihove gradivne elemente. Sam UML ima četiri vrste elemenata:

 Strukturne elemente (structural things)

 Elemente sa ponašanjem (behavioural things)
 Grupišuće elemente (grouping things)
 Označavajuće elemente (annotational things)

2.2.STRUKTURNI ELEMENTI

Osnovni strukturni tipovi su klasa, interfejs, učesnik, slučaj korištenja, komponenta i

čvor.
 Klasa predstavlja skup objekata koji dijele iste atribute, operacije,
relacije i semantiku. Klase su rječnik i terminologija jednog područja
znanja. Kada se pravi jedan sistem i upoznaju njegove karakteristike
treba slušati onoga ko ga predstavlja, prema tome dizajnirati. Treba
uočiti terminologiju i modelirati pojmove kao klase u UML. Treba
obratiti pažnju na imenice koje se koriste da bi opisali entiteti u svom
poslu. Te imenice će biti klase u modelu. Također treba obratiti
pažnju na glagole jer će oni činiti metode unutar klasa. Atributi će
izaći kao imenice koje su u vezi sa imenicama koje određuju klasu.

Slika 1.Klasa

 Interfejs (Interface) je skup poruka koji se može poslati klasi i ne uključuje

implementaciju tih operacija. Interfejs se označava krugom i njegovim
imenom, nikada ne stoji sam već će biti vezan uz neku klasu ili komponentu
koja ga realizuje.

Slika 2. Interfejs

5
 Učesnik (Actor) je spoljašnji krajnji korisnik.

Slika 3. Učesnik

 Slučaj korištenja (use case) prikazuje jednu funkciju sistema kako je

vidi spoljašnji učesnik.To je skup sukcesivnih događaja koje sistem izvodi
kako bi dobio neki rezultat.

Slika 4. Slučaj korištenja

 Komponenta (component) je fizički dio sistema koji je saglasan sa

skupom interfejsa i pruža njihovu realizaciju.

Slika 5. Komponenta

 Čvorovi su obično fizički elementi koji postoje tokom rada sistema

(obično računarski resursi) koji u opštem slučaju posjeduju memoriju.
Takođe, čvorovi često posjeduju sposobnost procesiranja. Skup
komponenti se može nalaziti u čvoru, a može da se i premješta od čvora
do čvora.

Slika 6. Čvor

6
 2.3. ELEMENTI PONAŠANJA

Ovaj skup elemenata predstavlja dinamički dio UML modela. Dva su tipa stvari
ponašanja.

 Interakcija (interaction) je ponašanje koje obuhvata skup poruka koje

se izmjenjuju između grupe objekata, a u sklopu određenog konteksta i
u cilju izvršavanja specifične svrhe. Ponašanje grupe objekata ili
pojedinačne operacije može se specificirati pomoću interakcije.
Interakcija sadrži čitav niz drugih elemenata, kao što su poruke, akcije,
konektori (veze između objekata) i sl. Grafički se poruka prikazuje
punom crtom s označenim smjerom i gotovo uvijek sadrži i ime
operacije ().
prikaži

Slika 7. Interakcija

 Automat stanja (state machine) je ponašanje koje specificira slijed

stanja objekta ili interakcije kroz koje objekt prolazi tokom svog životnog
vijeka, a kao odgovor na određene događaje. Ponašanje pojedinačne klase
ili klasa može se predstaviti kao automat stanja. Automat stanja uključuje i
druge elemente kao što su stanje, prijelaz – tranzicija (tok iz jednog stanja
u drugo), događaje (stvari koje predstavljaju okidač za tranziciju) i
aktivnosti (odgovor na tranziciju). Grafički se stanje predstavlja kao
pravougaonik sa zaobljenim rubovima koji sadrži ime stanja

Čekanje

Slika 8.Stanje

7
 2.4.GRUPIŠUĆI ELEMENTI

Grupišući elementi predstavljaju organizacijski dio UML. To su „kutije“ u koje se može

razložiti UML model. Postoji samo jedan tip grupišućih stvari, a to su paketi.

 Paket (package) služi za organizovanje elemenata u grupe. U paket se

mogu smjestiti strukturni elementi, elementi ponašanja i drugi
grupišući elementi. Paket postoji samo za vrijeme razvoja, dok za
vrijeme izvođenja ne postoji.

Slika 9. Paket

2.5. ELEMENTI OZNAČAVANJA

Elementi označavanja odnose se na dio UML za objašnjenja. To su komentari koji

opisuju, rasvjetljavaju i uvode napomene i ograničenja o elementima modela.
 Osnovni element je bilješka (note) koja se pridružuje elementu ili
skupu elemenata.

Slika 10. Bilješka

8
 2.6. RELACIJE

UML ima tri osnovne vrste relacija:

 Zavisnost (dependency) je semantička relacija između dva elementa u

kojoj promjena jednog, nezavisnog, elementa može da utiče na semantiku
drugog , zavisnog, elementa.

Slika 11. Zavisnost

 Asocijacija ili pridruživanje je strukturalna veza koja opisuje vezu između

objekata. Veza kaže da jedan objekat ima za atribut primjer drugog ili su ti
objekti povezani u smislu posjedovanja.
 Poseban slučaj asocijacije je agregacija, koja predstavlja strukturnu vezu
cjeline i njenih dijelova; nešto ili neko je dio od nečega.

Pridruživanje

razdjelnik reglete

Mnogostrukost

1 0..n

Slika 12. Asocijacija

Nije određeno
Tačno jedan 1
Nula ili više 0..*
Jedan ili više 1..*
Nula ili jedan 0..1
Određeno 4..6
Višestruko 2,4..6

Tabela 2 . Mnogostrukost

9
Mnogostrukost, multiplicity, asocijacije određuje broj primjeraka jedne klase u odnosu na
drugu klasu.

kabl parice

Agregacija

Slika 13 . Agregacija

Generalizacija (generalizacion), je relacija specijalizacije/generalizacije u kojoj objekti

specijalizovanih elemenata, djeca, mogu da se zamijene objektima generalizovanih
elemenata, roditelja. To je drugo ime za nasljeđivanje. Grafički, relacija generalizacije se
prikazuje kao puna linija sa šupljom strelicom koja prikazuje prema roditelju,veza
između nadklasa i njenih podklasa ili bolje rečeno hijerarhijski odnos među klasama.

roditelj

generalizacija

djeca

Slika 14. Generalizacija

10
 3. UML DIJAGRAMI
3.1. DIJAGRAM KLASA

Dijagram klase opisuje statičku strukturu sistema. Dijagram klasa daje pregled sistema
pokazujući njegove klase i odnose među tim klasama. Pokazuje šta uzajamno djeluje , ali
ne pokazuje šta se dešava tokom tog djelovanja.

Osoba klasa Forma Algoritam

ime : String registracije rasporeda

veza generalizacije
0..n

opšte pridruživanje

1
Profesor Student
Menadzer registracije
titula : String smer : String

DodajStudenta(k : Kurs, s : Student)

1 3..10
1
opšte pridruživanje

agregacija
0..4 4 1..n

PonudaKursa Kurs
lokacija : String naziv

Otvori() 1..n 1 Otvori()

DodajStudenta(s : Student) DodajStudenta(s : Student)

Slika 15. Dijagram klase

11
 3.2. DIJAGRAM KORIŠTENJA Use Case dijagram

Dijagram korištenja predstavila sam pomoću scenarija za prijavu smetnji, kvara, na

telefonskim linijama u okviru odjeljenja ispitnog stola. Treba napraviti Use Case
dijagram i specifikaciju.

Slika 16. USE CASE dijagram

12
Prijava smetnje
 Use-case:Prijava smetnje
 Kratak opis:Prijava kvara na telefonu službi 1275
 Akteri:Korisnik, Tehničar ispitnog stola
 Preduslovi: Korisnik je sva svoja dugovanja izmirio i može prijaviti
kvar
 Opis:
1. Korisnik daje svoje podatke putem telefona , ime, prezime, broj telefona,
i opis kvara
2. Tehničar prima prijavu kvara [Izuzetak:ako je isključen zbog duga , nije
smetnja]
3. Tehničar unosi podatke o prijavljnoj smetnji u nalog na računaru
 Izuzetci: [Ako je isključen zbog duga, nije smetnja. Ne piše se nalog.]
 Posljedice: Smetnja je evidentirana u bazu podataka, karton korisnika.

Formiranje naloga
 Use-case: Formiranje naloga za otklanjanje smetnji
 Kratak opis:Tehničar prosljeđuje prijavu za otklanjanje smetnji na osnovu
prijave korisnika.
 Akteri: Tehničar.
 Opis:
1. Tehničar inicira izvršavanje funkcije pravljenja naloga za
otklanjanje smetnje.

Slika 17. Forma naloga

13
2. Sistem prikazuje formu za unos prijavljenog broja.

Slika 18. Forma naloga 2

14
3. Tehničar unosi broj, sistem automatski poziva podatke bitne za
nalog.

4. Sistem formira nalog i inicira se štampanje.

15
Štampanje
 Use-case: Štampanje
 Kratak opis: Štampanje različitih dokumenata, izvještaja, naloga.
 Akteri:-
 Preduslovi: Štampač je uključen i povezan sa računarom.
 Opis:
1. Sistem prosljeđuje zahtjev za štampanje dokumenta.
2. Ukoliko je štampač slobodan, zahtjev se prosljeđuje štampaču, ukoliko
nije zahtjev je na čekanju dok se štampač ne oslobodi.
3. Kada zahtjev stigne do štampača, dokument se štampa.
 Izuzetak:
 [Nema papira u štampaču.] Neophodno je staviti papir
 [Nema tonera]Neophodno je isključiti štampač i promijeniti toner, a
zatim ponovo proslijediti zahtjev za štampanje.
 Posljedice: Kompletan dokument je odštampan.

16
 3.3. DIJAGRAM SEKVENCI Sequence diagram

Ponašanje sistema se predstavlja sekvencnim dijagramom koji opisuje šta sistem treba da
radi, a ne kako. Sekvencni dijagram se pravi za jedan slučaj korišćenja i prikazuje
redoslijed izvršavanja sistemskih operacija kao odgovor na istoimene sistemske događaje
koje inicira učesnik. Sistemske operacije mogu da uključe parametre, a one mogu da se
pridodaju, grupišu u sistem. Grafički, kod sekvencnog dijagrama učesnici se ređaju po x-
osi, a poruke poređane u vremenskom redoslijedu po y-osi. Učesnik koji započinje
interakciju, obično se stavlja na vrh sa lijeve strane, a ostali se ređaju udesno. Zatim se
unose poruke (na y-osi) koje ti učesnici šalju i primaju (od vrha ka dnu). Oni posjeduju
dvije dimenzije: vrijeme i kolekciju objekata. Poruke preko kojih objekti komuniciraju,
prikazuju se usmjerenim horizontalnim linijama. Postojanje aktivnosti koju objekt izvodi
u vremenu predstavlja se tankim pravougaonikom koji prekriva vremensku osu u
vertikalnom pravcu, i u veličini koja odgovara vremenu njegovog postojanja. Na
dijagramu sekvenci postoje i rekurzivne poruke. To su poruke koje objekat upućuje
samom sebi. Rekurzija je prikazana strelicom koja polazi i završava se u objektu. Poruka
je definisana nazivom i parametrima.
Ako su dijagrami slučajeva upotrebe prethodno definisani, onda je dijagram sekvenci
jedna od realizacija slučajeva upotrebe, koja pokazuje redoslijed događaja koje generišu
spoljni učesnici za svaki slučaj upotrebe. Slučaj upotrebe sugeriše način na koji se
učesnik nalazi u interakciji sa softverskim sistemom, tj. učesnik generiše događaje.

Slika 19. Dijagram sekvenci

17
Slika 20.Sekvencni dijagram

Dijagram sekvenci na slikama 20. i 21. predstavlja redosljed izvršavanja operacija

prijavljivanja i realizacije smetnji na telefonskoj liniji.

18
2.Formiranje zapisnika

NalogForma PodaciKorisnikaForma Broj u smetnji

tehničar

Formiranje naloga
Ukucaj broj
preuzmipodatke

Prikaži podatke
izdvoji korisnika

vrati podatak

Podaci o korisniku ime prezime , broj telefona

Dodaj Podatke Nalog

Slika 21.Dijagram sekvenci

19
 3.4. DIJAGRAM STANJA MAŠINE State Machine diagram

Dijagrami stanja služe za modelovanje dinamičkih aspekata sistema. Dijagramima stanja

prikazuju se konačni automati. Dijagram aktivnosti je specijalan slučaj dijagrama stanja u
kojem je prisutna većina stanja aktivnosti. Stanje je situacija u životu objekta kada on
zadovoljava neki uslov. Objekat ostaje u nekom stanju u konačnom vremenskom
intervalu. Dijagram stanja pokazuje odvijanje upravljanja od stanja do stanja. Obično
modeluju objekte koji reaguju. Tranzicija pokazuje kretanje od jednog stanja ka
drugom.To je relacija između dva stanja koja kaže da će objekat u jednom stanju izvršiti
neke akcije pa će ući u drugo stanje.

Na sljedećoj slici prikazan je jednostavan dijagram stanja od projekta do izbora izvođača.

[nije odrađeno] [nije izrađen]

[odradjene] Izrada
Snimanja na
terenu projekta

[nisu ispunjeni uslovi] [izrađen]

Otvaranje Raspisivanje
ponuda tendera
[konkurs]

[odustaje se]

[Izabran izviođač]

Slika 22. Dijagram stanja objekta Projekat

20
 3.5. DIJAGRAM AKTIVNOSTI Activity diagrams

Dijagrami aktivnosti služe za modelovanje dinamičkih aspekata sistema. Oni služe da

pokažu poslovni proces ili tok posla. Dijagrami aktivnosti mogu se tretirati i kao
specijalni slučajevi dijagrama stanja. U čvorovima ovog dijagrama prikazane su akcije.
Oni opisuju šta se radi ali ne govore ko šta radi.Podjelo dijagrama na particije, dijelove,
možemo prikazati ko šta radi.
Na sljedećem dijagramu prikazane su aktivnosti koje objekat projekat prođe u svom
životnom ciklusu.
 Prva aktivnost je prikupljanje podataka na terenu ( ucrtavanje
stambenih objekata sa mogućim brojem telefonskih priključaka.
 Nakon prikupljenih podataka stvara se projekat.
 Po završetku izrade projekta, isti se predaje komisiji za revidovanje
koja daje svoje mišljenje o tehničkoj ispunjenosti uslova.
 Ukoliko je sve u redu projekat ide na tender za izvođenje radova, a
ako ne vraća se projektnom timu na prepravku.
Prikupljanje podataka
na terenu

Crtanje stambenih Određivanje

objektata mogućih trasa

Izrada projekta

Revidovanje
projekta
[nije prošao reviziju] [prošao reviziju]

Ponovna analiza i Tender za izvođača

rad na projektu

[nije ispunjen uslov za izvođenje] [ispunjen uslov izvođenja]

Slika 23. Dijagram aktivnosti objekta projekat

21
 3.6. PAKETNI DIJAGRAMI

Paket je konstrukcija za grupisanje u UML-u. Paket dozvoljava da se uzmu bilo kakve

konstrukcije UML-a i grupišu u jedinice višeg nivoa. Najčešće se koriste za grupisanje
klasa, ali mogu se koristiti za grupisanja ma kakvih elemenata u UML-u. U UML-modelu
svaka klasa je član jedinstvenog paketa. Paketi mogu biti članovi drugih paketa itd. Paket
može sadržati podpakete i klase. Paket se predstavlja ikonicom za folder. Sistem može
biti zamišljen kao jedan paket najvišeg nivoa koji u sebi sadrži sve ostalo. U samom
paketu klase mogu biti predstvljene na razne načine kao što pokazuje sledeća slika. Paketi
su virtualna „spremišta“ u koje se stavljaju klase slične namjene.

Sadržaj prikazan pomoću

dijagrama u bloku

Slika 24. Predstavljanje paketa

22
Paketnim dijagramima se može opisivati zavisnost između paketa. Dva paketa su zavisna
ako sadrže zavisne klase odnosno ako postoji zavisnost između njihovih sadržaja.

Slik 25.Paketni dijagram

23
 3.7.OBJEKTNI DIJAGRAMI Objekt
diagrams

Služi za pojašnjenje i ilustraciju složenih dijagrama klasa. Predstavljen je slikama

objekata i njihovim međusobnim vezama u određenom vremenskom trenutku. Sastavljen
je od objekata i linkova. Linkovi predstavljaju instance veza (asocijacije i agregacije) .

Slika 26. Objektni dijagram

Slika 27. Dijagram relacije između objekata i klasa

Pojmovi klase i objekta su tijesno povezani. O objektima se ne može govoriti bez osvrta
na njihove klase. Dok objekat predstavlja konkretan entitet koji postoji u vremenu i

24
prostoru, klasa predstavlja apstrakciju, tj. suštinu objekta, pa se može reći da su klase
skupovi objekata koji dele zajedničku strukturu i ponašanje.

3.8. DIJAGRAM RASPOREĐIVANJA Deployment diagrams

Opisuje fizičku arhitekturu i razmještaj komponenti u toj arhitekturi.

Slika 28. Dijagram raspoređivanja

25
 3.9. KOMPONENTNI DIJAGRAM Component dijagram

Opisuje programsku podršku (ponekad i hardware) koji čine sistem. Dijagrami

komponenti omogućuju fizički pogled na trenutni model. Oni pokazuju organizaciju i
zavisnosti između komponenti software-a, uključujući izvorni kôd,  binarni kôd i izvršne
komponente.

Slika 29. Komponentni dijagram

26
 Component Component

Component

Slika 30. Komponente i veze

3.10. VREMENSKI DIJAGRAM

To je još jedna vrsta interakcionih dijagrama kod kojih je akcenat na vremenskim

ograničenjima. Mogu se odnositi na jedan objekat, ali češće se odnose na više njih.
Promjena stanja u vremenskim dijagramima može se opisivati linijama ili površinskim
zonama. Na sledećim slikama prikazana su dva vremenska dijagrama u kojima se koriste
ova dva načina za prikaz vremenskih dešavanja.
U 1. primeru događaj e1 izaziva promenu stanja u objektu b. Objekt b reaguje
upućivanjem poruke start() objektu a. Kasnije, događaj e2 izaziva promenu stanja objekta
a, koji šalje poruku done() utičući na promenu stanja objekta b. U 2. primeru površinska
zona opisuje promene stanja u vremenu.

27
 Slika 31. Vremenski dijagram

4.ZAKLJUČAK

Razvoj UML-a bio je podstaknut potrebom za razumijevanjem objektno-orijentisanog

razvijanja i načina na koji arhitektura projekta utiče na rezultat.UML-se može koristiti u
svakom projektu analize i dizajna, iako su ili nisu objektno orjentisani sistemi.
Najveća zabluda ljudi u vezi sa UML-om je to da se misli da je to čarobni jezik koji će
omogućiti da se uz hrpu dijagrama napravi novi OS. Najvažnija namjena UML-a je
komunikacija. Najjednostavnija predstava projekta kojeg radimo, nekome ko tek postaje
dio grupe je putem dijagrama. Cilj pri korištenju UML-a za poslovne procese, za razvoj
aplikacija i modelovanje baza podataka jeste da se povežu razvojne grupe i da se osigura
da organizacije ne prave arhitekturu preduzeća bez uključivanja svih grupa od značaja za
taj proces. Promjene koje se dešavaju u toku životnog ciklusa projekta, UML dijagramima
se mogu ažurirati, tako da svi učesnici mogu da razumiju promjene koje imaju uticaja na

28
njihovu oblast. Pored dijagrama i metamodeli imaju važnu ulogu u razumijevanju.U
samom modelovanju baza podataka UML je proširio vidokrug i postao dijelom
cjelokupnog procesa analize i dizajna. Pri projektovanju baza podataka mi i dalje imamo
tabele, kolone i druge bitne elemente. Oni su sada samo malo drugačije opisani i
omogućuju lakšu komunikaciju između radnih grupa. UML pruža mogućnost da se jednim
jezikom modeluje poslovni sistem, aplikacija, baza podataka i arhitektura sistema.
Korišćenjem UML-a kao jezika za čitav životni ciklus razvojnog procesa omogućuje da
svi učesnici rade na isti način, ali da svoj sopstveni dio rade prema potrebama.
Mi imamo veću mogućnost da razumijemo stvari ako su nam one predstavljene vizuelno
preko modela, nego u slučaju kada su nam one predstavljene tekstom.Izradom vizuelnog
modela sistema, možemo pokazati kako sistem radi posmatrajući više nivoa. Možemo
modelovati inerakciju korisnika i sistema. Možemo modelovati interakciju pojedinih
objekata sistema i samog sistema.
U ovom radu pokušala sam iz dostupne literature sakupiti dijelove i napraviti jednu
cjelinu koja se pomalo dotakla osnova UML jezika.

LITERATURA:

[1] Martin Fowler : UML ukratko, Mikro knjiga , Beograd, 2004;

[2] Eric J. Naiburg, Robert A. Maksimchuk: UML za projektovanje baza podataka,
CET,Beograd, 2001;
[3] www.cet.co.yu , 19.01.2008.godine

29
30