UVOD

Šta je UML?
Unified Modeling Language (UML) (Jedinstveni jezik modelovanja) je familija grafičkih modela, u sklopu jednog zajedničkog meta modela, koji pomažu u opisivanju i skiciranju softverskih sistema, naročito onih izgrađenih korištenjem objektno orijentisanog (OO) stila. UML, zapravo, znači različite stvari za različite korisnike. To proizlazi iz njegove sopstvene istorije i različitih ciljeva koje korisnici imaju u zavisnosti od procesa softverskog inžinjerstva. Na početku opisa UML-a, razmotrićemo različite načine na koje se on može koristiti. Jezici grafičkog modelovanja su prisutni već duže vrijeme u softverskoj industriji. Osnovni motiv njihovog razvoja je činjenica da programski jezici nisu na dovoljno visokom nivou apstrakcije da bi se pomoću njih moglo diskutovati o samom dizajnu softvera na visokom nivou. Bez obzira na činjenicu da su grafički jezici modeliranja prisutni u softverskoj industriji već duže vrijeme, postoji neslaganje u softverskoj industriji o njihovoj ulozi. Ove nesuglasice se direktno odražavaju na poimanje uloge UML-a. UML je relativno otvoren standard, kontrolisan od strane Object Managment Grupe (OMG), otvorenog konzorcijuma kompanija. OMG je formiran za postavljanje standarda koji podržavaju interoperabilnost, I specijalno interoperabilnost objektno orjentisanih sistema. Najpoznatiji produkt OMG-a su CORBA (Common Object Resource Broker Architecture) standardi.

Načini korištenja UML-a
Suština uloge UML-a u softverskom razvoju su razliciti načini na koje ga ljudi koriste. UML se može koristiti na tri načina : kao skica, nacrt I programski jezik. Daleko najčešći od sva tri načina korištenja je korištenje UML-a kao skice. U ovom scenariju, UML se koristi kao sredstvo komunikacije o različitim aspektima sistema koji se gradi. Postoje dva načina korištenja UML-a kao skice sistema : kada se UML dijagrami koriste prije pisanja samog koda programa (forward engineering) I kreiranje UML dijagrama
1

na osnovu postojećeg koda programa, u cilju njegovog razumijevanja (reverse engineering). Suština korištenja UML-a kao skice je selektivnost. Sa skiciranjem unaprijed, UML dijagramima ugrubo predstavljamo osobine nekih dijelova koda koji tek treba da napišemo, obično u cilju diskusije sa drugim članovima zajedničkog softverskog tima o njima. Cilj korištenja ovih skica je predstavljanje ideja i alternativa o dijelovima koda koje treba da pišemo. Na ovaj način možemo da se koncentrišemo samo na bitne ideje koda na kojem treba da radimo, i da ih na jednostavan način predstavimo drugim članovima programerskog tima. Kod skiciranja unazad, koristimo UML dijagrame da objasnimo kako pojedini dijelovi već konstruisanog sistema rade. Takođe, ni ovde ne predstavljamo sve dijelove koda, nego samo one glavne. Kod korištenja UML-a kao skice softvera, najčešće nam je bitna brzina kojom možemo da realizujemo dijagrame I tu se obično ne pridržavamo u potpunosti kompletne I striktne specifikacije UML-a. Za razliku od ovog načina korištenja, kod korištenja UML-a kao nacrta, suština je u kompletnosti. U inžinjeringu prema naprijed, ideja je da nacrti predstavljaju detaljan dizajn koda koji programeri moraju da napišu. Taj dizajn mora da bude kompletan, što znači da sve odluke o dizajnu softvera moraju da budu specificirane I da programeri mogu da ih slijede prilično automatski, bez mnogo razmišljanja. U programerskom timu, obično su dizajneri zaduženi sa pravljenje ovog nacrta za čitav tim programera. Inspiracija za ovo su ostali vidovi inžinjerstva, gdje profesionalni inžinjeri kreiraju nacrte koji se potom predaju kompanijama za konstruisanje koje ih sprovode u djelo. U inžinjeringu prema nazad, nacrti sadrže detaljne informacije o već razvijenom kodu. Nacrti mogu da prikažu sve detalje o klasama koje su prisutne u programu, u grafičkoj formi koja omogućava njihovo lakše razumijevanje. Nacrti zahtijevaju mnogo sofisticiranije alate nego skice da bi mogli da prikažu sve detalje koji se od nacrta zahtijevaju. Specijalni CASE (Computer Aided Software Engineering) alati se koriste u te svrhe. Alati za inženjering prema naprijed podržavaju crtanje dijagrama i njihovo smiještanje u repozitorije, dok alati za inžinjerstvo unazad omogućavaju analizu koda i generisanje dijagrama iz njega. Razlika između skica i nacrta nije tako očigledna, ali ona leži u namjernoj nekompletnosti skica, kod kojih je suština u naglašavanju glavnih osobina, dok su nacrti predviđeni da budu veoma iscrpni, i obično

2

imaju za cilj da svedu sam proces pisanja programa na jednostavnu, mehaničku aktivnost. U slučaju veoma detaljnih UML dijagrama, moguće je i autmatsko generisanje koda na osnovu njih. Zaista, mnogi CASE alati podržavaju neku formu automatskog generisanja koda, pomoću kojih se može automatski generisati veliki dio ciljnog sistema. Krajnja tačka je ona u kojoj kompletan sistem može biti specificiran pomoću UML dijagrama I tada govorimo o UML-u kao programskom jeziku. U ovom načinu korištenja UML-a, programeri crtaju UML dijagrame koji se direktno prevode u izvršni kod, I UML dijagrami postaju izvorni kod. Očigledno, da bi se UML koristio na ovaj način, potrebni su veoma sofisticirani softverski alati. Interesantno pitanje vezano za korištenje UML-a kao programskog jezika je kako modelirati “dinamičke” osobine programa (razmjena poruka itd.). UML 2 specifikacija predviđa tri različita načina na koje se ove osobine mogu modelirati : dijagrami interakcije, dijagrami stanja I dijagrami aktivnosti. Svaki od ovih dijagrama imaju svoje pristalice među softverskim inžinjerima, I biće interesantno vidjeti koji on njih će se nametnuti kao dominantni.

UML dijagrami
UML 2 definiše trinaest tipova dijagrama koji se mogu koristiti. To su

dijagrami aktivnosti, koji opisuju proceduralno I paralelno ponašanje objekata u programu dijagrami klasa, koji opisuju klase I veze između njih dijagrami komunikacije, koji opisuju interakciju između objekata sa naglaskom na veze među objektima dijagrami komponenti, koji opisuju strukturu I veze između komponenata programa dijagrami strukture, koji opisuju dekompoziciju klasa u toku izvršavanja programa dijagrami pregleda interakcije, koji su mješavina dijagrama sekvenci I aktivnosti

– –

3

dijagrami razvijanja, koji opisuju razvijanje programa na fizičkim čvorovima (procesori) objektni dijagrami, koji opisuju primjere konfiguracija instanci klasa (objekata) u toku izvršavanja programa dijagrami paketa, koji opisuju hijerarhiju paketa od kojih se sastoji kompletan program dijagrami sekvenci, koji opisuju interakciju među objektima, sa naglaskom na poredak u kojem se interakcije dešavaju dijagrami stanja, koji opisuju kako pojedini događaji u toku izvršavanja programa mijenjaju objekte u programu dijagrami vremena, koji opisuju interakciju među objektima sa naglaskom na vrijeme u kojoj se interakcije obavljaju use case dijagrami, koji opisuju kako korisnici komuniciraju sa sistemom

Tipovi dijagrama nisu previše rigorozni u smislu šta sve u njima može da se pojavljuje, tako da je sasvim legalno korištenje elemenata jednog tipa dijagrama u dijagramima drugog tipa. UML standard definiše da su pojedini elementi tipični za pojedini tip dijagrama, ali ne obavezuje na korištenje samo tih elemenata.

4

i ako ste procijenili da će za to biti potrebno godinu dana. fazu dizajniranja od četiri mjeseca I faze pisanja koda I testiranja u trajanju po tri mjeseca. jer način korištenja UML-a uveliko zavisi od stila razvoja softvera koji koristimo. pojavite sa konačnim rezultatom. dizajna. najprije urade analiza i dizajn na viskom nivou za kompletan projekat. Neophodan je neki način razbijanja problema na manje. Takozvani vodopad stil razvoja softvera razbija projekat na bazi aktivnosti koje su potrebne za njegovo realizovanje. ali su I tako razlike primjetne.PROCES RAZVOJA SOFTVERA Kao što smo već spomenuli. projekat od godinu dana može. tako da bi se moglo lakše pristupiti problemu I pratiti napredak u njegovom rješavanju. Postoje i hibridni pristupi razvoju softvera. dizajn softvera. Sve te medote kombinuju jezike grafičkog modelovanja sa procesom razvoja softvera. Sa druge strane. npr. pisanja koda i testiranja u svakom tromjesečju. Jedna od najvećih debata o procesima razvoja softvera je ona oko toga da li treba koristiti iterativni ili tzv. iterativni stil razvoja softvera razbija projekt na podskupove kranje funkcionalnosti koju on treba da ima. poslije toga. naravno. Za razumijevanje UML-a neophodno je razumjeti kako se samo grafičko modelovanje uklapa u proces razvoja softvera. 5 . Ovo je. U ovom slučaju. morate da zavrišite neke aktivnosti kao što su analiza zahtjeva (analiza onoga što se očekuje od softvera). i u svakom dijelu implementiramo po četvrtinu funkcionalnosti ciljnog sistema. rijetko koji poslodavac će željeti da vas ostavi na miru godinu dana I da se. programiranje koda I testiranje. pojednostavljen prikaz ova dva načina razvijanja softvera. kao u vodopad stilu. UML se razvio kao dio metoda objekto orjentisane analize i dizajna. a potom se faze pisanja koda i testiranja podijele u iteracije. npr. Osnovna razlika između ova dva stila je način na koji projekat razbijamo u manje dijelove. gdje se. Ako je vaš tim dobio zadatak da dizajnira I implementira softverski sistem. prolazeći kompletan proces analize. projekat od godinu dana možemo razbiti na četiri dijela od po tri mjeseca. da ima fazu analize u trajanju od dva mjeseca... “vodopad” stil razvoja. Na osnovu ovakve podjele. Da biste izgradili softver.

koji opisuju kako korisnici komuniciraju sa sistemom Dijagrami klasa. pisanja koda I testiranja moraju da se obave. Obično. aktivnosti analize. Bez obzira da li se koristi ovaj stil ili ne. UML u procesu razvoja softvera Kada se pogledaju jezici grafičkog modelovanja. Tu se analizira šta je to što korisnici žele da krajnji sistem radi. Može se učiniti da posao odlično napreduje nakon prve dvije faze. I da se tek u fazi pisanja koda primijete ozbiljni propusti napravljeni u njima. očigledno je da je iterativni proces bolji. a jedan od njih je I što je veoma teško ocijeniti kako projekt napreduje ako se koristi taj stil. Korištenje UML-a ne podrazumijeva I pisanje kompleksnih dokumenata čiji su dijagrami veći dio ili korištenje CASE alata. jedini način da se zaista realno ocijeni napredak u projektu je da se proizvede testirani softver. Što se ovoga tiče. Postoji mnogo nedostataka vodopad stila (koji se. UML dijagrami se crtaju samo tokom sastanaka I rasprava o idejama o realizaciji softvera. kao i detalje o funkcionisanju komplikovanijih use case-ova. – – 6 . obično o njima razmišljamo u kontekstu razvoja softvera pomoću vodopad stila. U mnogo slučajeva. prikazujući interakciju između softvera i njegovih korisnika. ipak najčešće primjenjuje). nacrtani iz konceptualne perspektive mogu biti dobar način da se izgradi rigorozni “riječnik” domena problema Dijagrami aktivnosti. dizajna. dizajna I pisanja koda.Mnogi softverski inžinjeri i programeri preferiraju iterativni stil. jer u njemu se više puta prije kraja rada na projektu proizvode manji dijelovi funkcionalnog softvera. iz nekog razloga. Analiza zahtjeva Proces analize zahtjeva uključuje analiziranje zahtjeva koji korisnici imaju prema sistemu. koji može prikazati radni tok organizacije. u odnosu na vodopad stil. npr: – Use Case dijagrami. Dijagram aktivnosti može prikazati kontekst use case-ova. Grafički modeli obično čine veći dio ovih dokumenata. U ovom stilu obično postoje dokumenti koji predstavljaju tačke prelaza između faze analize. Mnoge UML tehnike se mogu primijeniti u ovom procesu.

Najvažnija aktivnost u procesu analize zahtjeva koje softver treba da ispunjava je komunikacija sa budućim korisnicima sistema. Ipak. ona postaje važna u fazi dizajna. jer pruža uvid na viskom nivou o dijelovima softvera. ove dijagrame crtamo kao dijelove različitih faza. Dijagrami paketa. Ovde treba još nešto dodati.. oni nisu programeri I nisu upoznati sa UML ili bilo kojom drugom tehnikom vizuelnog modeliranja.Dijagrami stanja. dijagrami postaju opširniji. 7 . UML tehnike koje su veoma korisne u fazi dizajna su : – Dijagrami klasa iz softverske perspektive. UML dijagrami se koriste ili kao skice ili kao nacrti. koji pokazuju organizaciju softvera. Obično. sa različitim stanjima I događajima koji mijenjaju ta stanja. koji mogu biti korisni ako neki koncept ima izvjesni ciklus trajanja. sami morati da modifikuju napisani kod. U iterativnom stilu razvoja softvera. Oni pokazuju klase u programu I načine na koje one komuniciraju. Dizajn U fazi dizajna softvera. eventualno. Vodopad stil obično podrazumijeva da se UML koristi kao nacrt za softver. pokazuju kako se softver izvršava na – – – – Mnoge od ovih tehnika mogu da se koriste i za dokumentovanje softvera kada je on već napisan. ali I ovako je priličan smor. UML notacija im može biti veoma korisna u predstavljanju budućeg sistema na visokom nivou. Dijagrami stanja za klase sa komplikovanim ciklusom trajanja Dijagrami razvoja koji hardverskim sistemima. To je veoma korisno korisnicima koji će. Dokument koji se produkuje na kraju faze obično sadrži UML dijagrame pogodne za tu fazu. Dok je u fazi analiziranja zahtjeva poželjno minimalno koristiti notaciju kod dijagrama. Kod dizajniranja softvera metodom vodopada. Dijagrami sekvenci za uobičajene scenarije. Veoma dobar način dizajna je da odaberemo najvažnije i najinteresantnije scenarije korištenja programa (iz use case-ova) I onda koristimo dijagrame sekvenci da zaključimo šta se dešava u softveru.

Kutije u dijagramu su klase. dok ćemo u drugom razmotriti I rijeđe korištene napredne elemente. takođe pokazuje dvije vrste veza izmedju klasa: udruživanje (asocijacije) i uopstavanje(generalizacije).1 Osobine klase 8 . Slika 3.DIJAGRAMI KLASA Najvažnija i najčešća vrsta UML dijagrama su dijagrami klasa. UML koristi naziv svojstvo kao generalni naziv koji pokriva atribute i operacije klase. Slika 3. dok se napredniji elementi tih dijagrama rjeđe koriste. Dijagrami klasa takođe pokazuju osobine i operacije klasa i ograničenja koja su posljedica tipove veza među objektima. Dijagrami klasa opisuju tipove objekata u sistemu i brojne vrste statičkih veza koje postoje izmedju njih. Osnovni elementi dijagrama klasa su neophodni svima onima koji se bave vizuelnim modelovanjem. Prvi dio ovog poglavlja posvećen je osnovnim elementima dijagrama klasa.1. atributi i operacije klase. Slika 3.1 pokazuje jednostavni model klasa koji se može koristiti u sistemu procesiranja narudžbi koje prave kupci. koje su podeljene u tri odjeljka: ime klase (ispisano podebljanim slovima).

Osobine prestavljaju strukturu klase. U stvarnosti je situacija malo složenija. za početak posmatraćemo osobine kao atribute klase. u stringu-osobine je navedeno {readOnly} svojstvo koje pokazuje da se vrijednost atributa može samo čitati. 9 . ako vrijednost atributa nije specificirana kod kreiranja objekta string-osobine omogućava da se navedu dodatna svojstva atributa. Mnoge informacije koje možemo prikazati u opisu atributa mogu biti prikazane I pomoću asocijacija. – – – Asocijacije Drugi način za obiljezavanje osobina klase je asocijacija. Iako na dijagramu atributi I asocijacije izgledaju potpuno drugačije. Puna forma atributa je : vidljivost ime:tip multiplikativnost = podrazumijevana_vrijednost {stringosobine} Primjer ovoga je: . multiplikativnost atributa će biti objašnjena naknadno podrazumijevana vrijednost je vrijednost koja se automatski dodjeljuje atributu kada se kreira novi objekt. Za početak. Ovaj dio se odnosi na tip vrijednosti atributa u programskom jeziku.ime : String [1] = ‘’Untitled’’ {readOnly} Od kompletnog opisa atributa. Svi ostali su opcionalni : – – – Vidljivost pokazuje koji atribut je javni (+) ili privatni (-). Osobine se pojavljuju u dva oblika : atributi I asocijacije. U gornjem primjeru. ali ipak. ustvari se radi o sličnoj stvari Atributi Atributi opisuju osobine klase kao liniju teksta u sklopu kutije klase. Ime atributa tip atributa pokazuje restrikcije koje vrijednosti mogu biti smještene u atribut. jedino je ime neophodan dio. možemo razmišljati o osobinama klase kao o njenim atributima.

kao što su String. npr.slika 3.. ako postoji asocijacija od izvorne klase prema odredišnoj. I ako je na odredišnom kraju napisano ime name.. Odredište asocijacije pokazuje na klasu koja je tip osobine koju razmatramo. usmjerena od izvorne klase ka odredišnoj klasi. postoje neke razlike između ove dvije notacije. asocijacija može da prikaže mnogostrukost veze na oba njena kraja. Pošto imamo dvije notacije za istu stvar. I ime atributa je name. Primjećujemo da I pomoću opisa atributa I pomoću asocijacija možemo da prikažemo iste osobine klase. Npr. U praksi. a ne samo jednu? Korištenje notacije opisa atributa je pogodnija kada su atributi jednostavnog tipa.3 10 .Ovo možemo prikazati I preko opisa atributa. Kada je atribut jedne klase niz objekata druge klase. onda izvorna klasa kao atribut ima objekat tipa odredišne klase. Ime osobine je napisano na odredišnom kraju asocijacije. pitanje je zašto koristiti obje... dok je korištenje asocijacija pogodnije kada su atributi složenijeg tipa. Integer. Ipak.2 Asocijacija se prikazuje kao puna linija između dvije klase. Slika 3. Boolean. zajedno sa njenom mnogostrukošću. navodeći kao njegov tip odredišnu klasu.

poželjno je u svim dijagramima eksplicitno navesti sve mnogostrukosti. Najčešće mnogostrukosti su: – 1 (jedna narudžba može imati samo jednu mušteriju. Ako su gornja i donja granica iste. elementi multivalued mnogostrukosti čine neki skup.1. dakle. Kod asocijacija. koja označava neuređen skup elemenata koji ne moraju biti jedinstveni. čak I one koje imaju podrazumijevanu vrijednost 1.. tj. I pored ovoga. 1 je isto što i 1. Zbog toga. dodajemo odrednicu ordered na kraj asocijacije. a gornja granica bilo koji pozitivan broj ili * (za neogranicene). Takođe. 11 .Mnogostrukost osobina Mnogostrukost osobine pokazuje koliko objekata može zadovoljavati tu osobinu. jer u dijagramu mnogostrukosti mogu biti namjerno izostavljene. Ako nam je bitan poredak elemenata u skupu.. kao npr. Mandatory (obavezni) ukazuje da je donja granica 1.1 (Korporacijska predstavnika) mušterija može imati nijednog ili jednog – – * (jedna mušterija ne mora imati ni jednu narudžbu. ne možemo pretpostaviti da je ona 1. Podrazumijevana vrijednost mnogostrukosti je 1. ako je u nekom dijagramu vrijednost neke mnogostrukosti izostavljena. Zato što je to čest slučaj. može se koristiti jedan broj. Kada koristimo opise atributa.*. * je skraćenica za 0. ali I ne postoji ograničenje koliko jedna mušterija može da ima narudžbi : jedna mušterija može da napravi I više narudžbi) Opštije. ona pokazuje koliko objekata jedne klase može da odgovara jednom objektu druge klase. koristimo različite termine za opis mnogostrukosti.. a moguće I više Single-valued ukazuje da je gornja granica 1 Multivalued ukazu da je gornja granica više nego 1: obično * Obično. – – – – Optional (po izboru) ukazuje da je donja granica 0. mnogostrukosti su definisane donjom i gornjom granicom. Donja granica može biti bilo koji pozitivan broj ili nula.4 za igrače kartaške igre kanasta. 2.. Jednom objektu tupa Narudzba odgovara tačno jedan objekat tipa Musterija) 0. ponekad možemo naići na odrednicu {bag}. koristimo odrednicu {nonunique}. Ako želimo da dodamo duplikate.

mogla koncentrisati više na get metode nego na same atribute.. Možemo zapaziti da u Javi osobina odgovara privatnom atributu klase. private Money cijena. Tako bi RedNarudzbi klasa sa slike 3. Read-only atribut neće imati odgovarajući set metod. Privatnim atributima možemo pristupati pomoću set I get metoda klase za taj atribut.1 odgovarao sljedećem kodu u Javi: public class Orderline.. mogli bismo vidjeti sljedeći kod u RedNarudzbe klasi public class Orderline. } public Money getPrice() { 12 .quantity = quantity. umjesto toga. private Product product. } public void setQuantity(int quantity() { this. Korištenje privatnih polja je interpretacija dijagrama koja je veoma fokusirana na implementaciju. public int getQuantity() { return quantity. Najšesća softverska reprezentacija je da se osobina klase sa dijagrama prevodi u polje (atribut) klase u programu.Programerska interpretacija svojstava Kao i svega ostalog u UML-u. Interpretacija koja je orjentisana na interfejs bi se. private Order narudzba.. U tom slučaju. ne postoji jedan način da se interpretiraju osobine iz dijagrama klase u kodu koji pišemo.. private int kolicina. Private int quantity. private Product proizvod.

13 . ali problem sa njima je što oni imaju fiksiranu granicu koliko elemenata mogu da sadrže. Ako je skup neuređen. public Set getLineItems() { return Collections. ili IList u . ipak.unmodifiableSet(lineItems). ne bi trebalo da bude bitan poredak objkata. Višestruka svojstva rezultiju drukčijom vrstom interfejsa prema njima nego jednostruka svojstva: class Order { private Set lineItems = new HashSet(). ne dodjeljujemo direktno vrijednosti višestrukim svojstvima. } U većini slučajeva. strogo uzevši. umjesto toga.remove(arg). ne postoji polje za podatak o cijeni. } public void removeLineItem (OrderItem arg) { lineItems. kod njega. Ovo sakrivanje informacije je sustina enkapsulacije. Pojedinci koriste nizove. to implicira da se podatak odnosi na kolekciju objekata. } public void addLineItem (OrderItem arg) { lineItems. umjesto toga. taj skup mora da bude uredjen (kao sto je List u Javi. } U ovom slučaju. Ako atribut ima viseštruke vrijednosti (Multivalued). ali većina programera implementira i neuređene karakteristike kao liste.NET). bolje koristiti liste. Tako bi se klasa Narudzba u sebi sadržavala atribut koji se odnosi na skup RedNarudzbe objekata. ona je izračunata vrijednost. dok kod UML notacije možemo da imamo neograničenu mnogostrukost (*).add (arg). tako da je.multiply(quantity).return product. dodajemo ih I oduzimamo sa add i remove metodama.getPrice(). Zbog toga što je ova višestrukost uređena.

nađemo njegovog vlasnika. Ipak. i tada pogledam skup auta tog vlasnika. kao na slici 3. skoro nikad ne vidite klase skupova na dijagramu klase. Poželjnije je koristiti dvosmjernu strelicu kao na slici 3.4 kada želite da naglasite da imate dvosmjernu asocijaciju.Zbog toga što višestruki atributi impliciraju skupove. UML dopušta da koristite ovu formu ili da obiljezite dvosmjernu asocijaciju ili kada ne želite da pokažete smijerove asocijacije. tj.. dvosmjerna priroda asocijacije je napravljenja vidljivom korištenjem navigacionih strelica na oba kraja asocijacije. poželjno je imenovati asocijacije samo onda kada to poboljšava čitljivost I razumijevanje dijagrama. jer moramo da obezbijedimo da su atributi sinhronizovani. trebalo bi da se vratite unatrag do grupe koja sadrzi vašu polaznu tačku.5).4 Dvosmjerna asocijacija je par svojstava koja su međusobno povezana kao inverzna. Inverzna povezanost među njima podrazumijeva da. taj skup bi trebalo da sadrži MG Midget. radije obilježavaju asocijaciju korištenjem glagolskih fraza (slika 3. ako počnemo sa nekim autom MG Midget.4. tj. Da ako pratimo asocijaciju u jednom smijeru I onda u 14 . Oni se prikazuju samo na dijagramima veoma niskog nivoa. Ovo je legalno i možete da dodate strelicu da biste izbjegli nedoumicu. Druga bitna vrsta asocijacija su dvosmjerne asocijacije. Implementacija dvosjmernih asocijacija nije tako lagana kao kada su u pitanju jednosmijerne. a Person klasa ima svojstvo auta:Auto[*]. Klasa Auto ima svojstvo vlasnik: Person[1]. slika 3. Slika 3. Na slici 3.4. tako da se ime asocijacije može koristiti u rečenici.5 nema strelice. Na primjer. od kojeg smo krenuli. Dijagramima samih kolekcija Dvosmijerne asocijacije Asocijacije koje smo do sada posmatrali se nazivaju jednosmijerne asocijacije. Kao alternativu obilježavanju asocijacije na osnovu svojstva. Pojedinci smatraju da je potrebno imenovati svaku asocijaciju na neki nacin. mnogi ljudi. ako slijedite oba svojstva.

ostale modifikatore vidljivosti ćemo razmotriti poslije. type i default_value su isti kao i za svojstva. 15 . Puna UML sintaksa za operaciju je: vidljivost name (lista_parametara) : return_type {property-stryng}      vidljivost može biti public (+) ili private (-). U jeziku C++. kao što je to navedeno u primjeru koji se odnosi na sliku 3. jer se one obično podrazumijevaju. ako je moguće ona koja je jednoznacna (single-valued) kontroliše asocijaciju. Operacije najočiglednije odgovaraju metodama kod klase. property_string pokazuje vrijednosti svojstava koja se odnose na datu operaciju. Forma je: Direction name: type = default_value  name. U dijagramima klase obično ne pokazujemo one operacije koje jednostavno upravljaju svojstvima klase. lista_parametara je lista parametara za operaciju. da se vratimo na skup koji sadrži isti objekat. koja omogućava objektu strane klase da mijenja polja druge klase. ako ona postoji.4 slika 3. Parametri u listi parametara su obilježeni na sličan način kao atributi.drugom. Operacije klase Operacije su akcije koje klasa zna da izvodi. return_type je tip povratne vrijednosti. Npr.5 Primarna stvar je obezbijediti da jedna strana asocijacije. ovo se postiže korištenjem odredbe friend. Da bi ovo funkcionisalo. name je ime operacije. objekat na drugoj strani asocijacije treba da obezbijedi objektu koji kontroliše asocijaciju pristup njegovim poljima.

njih treba koristiti da se pokažu osnovni zadaci te klase. Ponekad je mučno raditi ovo stalno. UML definiše query (upiti) kao operaciju koja vraća vrijednost iz klase ne mijenjajući stanje sistema – drugim riječima bez propratnih efekata. na taj način možemo se osloniti na činjenicu da su operacije koje vraćaju vrijednost upiti. kompjuterski keš (cache) bi promijenila unutrašnje stanje. Takođe se pravi razlika je između operacije i metoda. Set I get metode ne bi trebalo da budu dio vanjskog interfejsa prema klasi. Set metod smiješta vrijednost u polje (i ne radi nista drugo). [Meyer] ovo tumači kao Command-Query separacioni princip. Operacije koje mijenjaju stanje sistema označavamo kao modifiers (modifikatore). budući da možete promijeniti redoslijed izvršavanja upita i ne promijeniti sistem ponašanja. Primjer operacije na računu moze da bude: + balanceOn (date: Date) : Money Kod konceptualnih modela. Get metod vraca vrijednost iz polja (i ne radi ništa drugo). Ako imamo nadtip sa tri podtipa. Strogo uzevši. Ove metode su dio internog interfejsa klase. Ostali izrazi koje povremeno susrećemo su get metode i set metode. direction pokazuje da li je parameter ulazni (in). Često je korisno razlikovati operacije koje mijenjaju stanje sistema i one koje ne mijenjaju. Operacija koja koriguje. npr. Ovo dvoje je različito u slučaju da imamo polimorfizam. razlika izmedju query i modifiers je da li oni mijenjaju vidljivo stanje. koji se nazivaju i komandama. možda koristeci par riječi koje sazimaju odgovornost klase. Vidljivo stanje je ono koje se može primjetiti izvana. Takvu operaciju možete označiti sa property_string vrijednošću {query}. ne treba navoditi operacije da se naglasi interfejs prema klasi. izlazni (out) ili oboje (inout). Umjesto toga. ali ne bi imala efekat vidljiv spolja.. Često pravilo je da se operacije pišu tako da modifikatori ne vraćaju vrijednost. ali bi trebalo to radite sto je više moguće. Operacija je nešto što se poziva za neki objekat – objava procedure – dok je metod glavni dio procedure. Ako pravac nije prikazan. Korisno je naglasiti upite. smatra se da je in. koji korisnik može da vidi. svaki od njih poništava 16 . koji se koristi za izvršavanje operacija klase.

Međutim. Generalizacija Tipičan primjer generalizacije obuhvata privatne i korporacijske mušterije. kada mnogi nisu voljeli primjenu ugrađene Vector klase i željeli su da je zamijene nečim lakšim.getPrice operaciju nadtipa. i da sve funkcioniše dobro. ja možemo da uzmemo bilo koji podtip Customer-a. ali ponekad je korisno biti precizan oko razlika. Iako je nasljeđivanje moćan mehanizam. Sličnosti se mogu smjestitii u opštu Customer klasu (nadtip). Da bi se obezbijedile zamjenljive klase. Ovo. ali imaju i sličnosti. koristeći polimorfizam. po definiciji. CorporateCustomer može da odgovara na neke komande drukčije od drugog Customer-a. očigledna interpretacija je nasljeđivanje: CorporateCustomer je podklasa Customer-a. Iz perspektive softvera. Trebalo bi biti moguće zamijeniti CorporateCustomer unutar bilo kojeg koda koji zahtijeva Customer. CorporateCustomer je tada specijalna vrsta Customer-a. mnogi vole da razlikuju podtipiziranje. operacije – istinito je i za Corporate Customer. Kod OO jezika. jedini način na koji su mogli da produkuju klasu koja bi bila zamjena za vektore je bilo da je podklasiraju. a to je značilo nasljedjivanje mnoštva neželjenih podataka i ponašanja. Oni se razlikuju. svojstva. ili nasljedjivanje interfejsa i podklasiranje. I instance Customer klase. ili nadljeđivanje implementacije. Ljudi obično koriste termine operacija i metod kao sinonime. Ključna ideja je da sve što kažemo o Customer-u – asocijacije. Kao rezultat. Ovaj fenomen je podložan različitim interpretacijama u različitim vidovima modelovanja. u suštini. ali pozivač ne mora da brine zbog razlike. podklasa nasljeđuje sve osobine nadklase i može da poništi svaki metod nadklase. mogu se koristiti i mnogi drugi mehanizmi. ako pišemo kod pretpostavljajući da imamo Customer klasu. Dobar primjer za ovo je bio u ranom period Jave. ono nosi mnogo opterećenja koje nije uvijek potrebno da bi se postigla zamjenljivost. sa PersonalCustomer i Corporate Customer podtipovima. Uopšteno. Važan princip efektivnog korištenja nasljedja je zamjenljivost. 17 . znači da. možemo da kažemo da je Corporate Customer podtip Customer-a ako su sve instance CorporateCustomer klase takođe. pa imamo jednu operaciju i četiri metoda da primjenite.

ili mogu da budu crticama povezane sa elementom na koji se odnose (slika 3. pravila 18 .6 Zavisnosti Između dva elementa postoji zavisnost ako promjene u definiciji jednog elementa (snabdjevač ili meta) mogu da uzrokuju promjene u drugom (klijent ili izvor). Mogu takođe da postoje u bilo kojoj vrsti dijagrama. Slika 3. jer se sve više i više stvari mora mijenjati. ni jedna poruka poslana toj klasi više nije validna. implementacije interfejsa. bilo da koristi nasljeđivanje ili ne. Postoje i mnogi drugi mehanizmi koji omogucavaju podtipiziranje bez podklasiranja. Ako zavisnost izmakne kontroli.7 pokazuje neke zavisnosti koje mozete naći u višeslojnim aplikacijama. ako je zamjenljiva za svoj nadtip. Što je talasanje veće. Bilješke I komentari Bilješke su komentari u dijagramima. Kako kompjuterski sistemi rastu. Zato je uobičajeno rješenje staviti vrlo mali otvoren krug na kraju linije. Ako klasa mijenja svoj interfejs.Klasa je podtip. kontrola zavisnosti postaje sve bitnija. Bilješke mogu da stoje same za sebe. Podklasiranje se koristi kao sinonim za pravo nasljedjivanje. svaka promjena na sistemu ima efekat talasa. Dijagram 3. Kod klasa zavisnosti postoje iz različitih razloga: jedna klasa šalje poruku drugoj. ili prezentacijska klasa – je zavisna od Employee klase: objekat domena koji obuhvata esencijalno ponašanje sistema – u ovom slučaju. teže je bilo šta promijeniti. jedna klasa sadrži drugu kao dio njenih podataka. jedna klasa spominje drugu kao parameter u nekoj operaciji. Benefits Window klasa – korisnički interfejs. Nekad je korisno imati I inline komentar na elemenat dijagrama. Primjeri su npr.6). Crtice ponekad mogu da budu nezgrapne jer ne možemo tačno odrediditi gdje se one završavaju. UML dopušta prikazivanje zavisnosti među svim vrstama elemenata. Zavisnosti se mogu koristiti kada god želimo da pokažemo kako promjene u jednom element mogu promijeniti druge elemente. To možete da uradite dodavanjem dvije crtice (--) prije teksta.

koju koristimo bez navođenja specijalnih ključnih riječi. UML ima mnoge varijetete u obilježavanju zavisnosti. Call Create Instantiate Izvor poziva operaciju cilja Izvor kreira instancu cilja Izvor je instanca cilja (ako je izvor klasa. mora da se promijeni i Benefits Window klasa. Ako se ove dvije klase promijene. a ne njenog interfejsa. gdje prezentacija zavisi od domena. Ali ako je promjena samo u implementaciji Employee klase. Ovde ćemo naglasiti osnovnu zavisnost. je vrijedno pravilo koje treba slijediti. To znači da. ako Employee klasa mijenja svoj interfejs. ali ne i obrnuto. možemo da dodamo odgovarajuću ključnu riječ (tabela 3. Ovdje je važno da je zavisnost jednosmjerna i ide od prezentacijske klase ka domen klasi. Striktna podjela na prezentacijsku logiku I logiku domena. mora da se promijeni i Employee klasa. Slika 3.1). promjena se tu zaustavlja. Cilj je metaklasa) Cilj dozvoljava izvoru da pristupi privatnim osobinama cilja Permit 19 .7 Druga stvar koja se može zapaziti sa ovog dijagrama je da ne postoji direktna zavisnost od Benefits Window ka dvije Data Gateway klase.biznisa. svaka sa posebnim semantikama i ključnim riječima. tj. Da bismo dodali više detalja. Na ovaj način znamo da slobodno možemo da promjenimo Benefit Window bez da te promjene imaju bilo kakav efekat na Empoyee ili druge objekte domena. onda je on instanca ciljne klase.

Primjeri dijagrama klasa Primjer 1 – Nacritati dijagram klasa koji modelira problem dat sljedećom specifikacijom : Kompanija za prodaju automobila posjeduje više soba za prezentaciju. ali u većini slučajeva postoji značajna razlika izmedju direktnih i indirektnih zavisnosti.7. Podklasa je zavisna od njene nadklase. Svaki automobil je karakterisan veličinom motora. Svi ljudi imaju ime. jer je takvih zavisnosti najčešće previše. određenog datuma. Takođe. kao što je supstitucija. 20 . proizvođačem. u dijagramima klasa ne treba prikazivati sve zavisnosti između klasa na njoj. Sve klase moraju biti sposobne da štampaju svoje podatke. takođe se bilježe I adrese mušterija kao I zarade prodavača.Realize Izvor je implementacije specifikacije ili interfejsa definisanog od strane cilja Izvor je zamjenjiv sa ciljem Izvor zahtijeva implementaciju cilj za svoju Substitute Use Osnovna zavisnost nije tranzitivan odnos. Usmjerena asocijacija od Narudžbe ka Mušteriji na slici 3. posebno onda kada su one između “udaljenih” dijelova sistema. Generalno pravilo je da treba minimizovati zavisnosti. Automobil može biti prodan od strane određenog prodavača. ali ne i obrnuto. Neke vrste zavisnosti. određenom kupcu. cijenom I registracionim brojem. Svaki prodavač ima menadžera.1 znaci da je Narudžba zavisna od Mušterije. su tranzitivne. Treba biti selektivan I pokazati samo zavisnosti samo onda kada su one od direktnog značaja za nešto što želimo da prikažemo dijagramom. Mnoge UML relacije impliciraju zavisnost. Svaka od soba za prezentaciju posjeduje više prodavača koji u njoj rade. I mijenjaju se prečesto. kao što je na slici 3.

Potrebno je obezbijediti odgovarajuće pristupne metode za sve atribute. Svaka sestra ima ime I dodijeljena je određenom odjeljenju. Sve klase bi trebalo da budu sposobne da štampaju svoje detalje. a svako odjeljenje sadrži više pacijenata I sestara. 21 . Sestra može biti glavna u odjeljenju.Primjer 2 – Nacrtati dijagram klasa koji modelira problem dat sljedećom specifikacijom : Bolnica sadrži različita odjeljenja. Svaki pacijent ima ime I dodijeljen je određenom odjeljenju. Bolnica ima ime I adresu. koje nije poznato kada se kreira objekat sestre. I svako odjeljenje ima svoj broj. Ukupan broj pacijenata u bolnici treba bude poznat. Pacijent može napustiti bolnicu. koje nije poznato kada se kreira pacijent. Odjeljenje pripada određenoj bolnici.

22 .

ali puna sintaksa je ime:Klasa. Npr. ali ako koristite samo ime klase. I kako metoda klase koja se poziva šalje poruku getDiscountInfo instanci klase mušterije. Ipak. UML definiše nekoliko vrsta dijagrama interakcije. Slika 4. Svaki objekat na 23 . morate ostaviti simbol :. Objekte u dijagramima sekvenci najčešće obilježavamo samo imenom objekta. Učesnici u dijagramima interakcije su najčešće objekti. Ovo se ne vidi sa dijagrama. narudžba mora da “pogleda” listu artikala koji se u njoj nalaze I njihove cijene. Da bi se to postiglo. Tipično. a calculateDiscounts se poziva samo jednom. sa slike se vidi da instanca klase Narudžba šalje poruke getQuantitiy I getProduct order lineu. gdje su I ime I Klasa opcionalni. Takođe. dijagrami sekvenci opisuju pojedinačne scenarije. potrebno je izračunati ukupni popust. Tipičan dijagram sekvence prikazuje izvjestan broj primjera objekata i poruka koje se razmjenjuju između njih u sklopu jednog scenarija (use case-a). vidimo kako se prikazuje situacija u kojoj klasa šalje poruku samoj sebi. Nakon što se to obavi. a najčešće se koriste dijagrami sekvenci. Dijagrami sekvenci prikazuju interakciju tako što prikazuju svakog učesnika u njoj sa njegovim vremenom učestvovanja u interakciji . Sekvenca poruka getQuantity..DIJAGRAMI SEKVENCI Dijagrami interakcije pokazuju kako grupe objekata “sarađuju” u nekim scenarijima. koji se bazira na pravilima koja važe za kupca. Notacija dijagrama sekvenci gotovo da I ne zahtijeva dodatno pojašnjavanje. koje teče odozgo prema dole na dijagramu. ovaj dijagram ne pokazuje sve sasvim jasno. Na isti način (odozgo prema dole) određujemo I redoslijed u kojem se razmjenjuju poruke.1 je dijagram sekvence koji pokazuje jednu implementaciju gornjeg scenarija. Razmotrimo sljedeći jednostavan scenario. Imamo narudžbu I izvršićemo komandu nad njom kojom ćemo izračunati njenu ukupnu cijenu. ali ćemo poslije uvesti notaciju kojom ćemo riješiti ovaj problem. getPricingDetails I calculateBasePrice treba da se izvrše za svaku order line u narudžbi. getProduct.

Ovo je veoma dobra strana dijagrama interakcije. Order Line prosljeđuje ovaj zahtjev objektu klase Product. a ostali učesnici služe samo za to da ga snabdijevaju podacima. Order poziva metodu klase Customer. Pošto mu treba informacija od objekta Order klase. Objekat Order klase traži od svake Order Line da izračuna svoju cijenu. Primjećujemo da prva poruka nema učesnika koji ju je poslao. Slika 4. Slika 4. I prema tome isti učesnik. Primjećujemo da smo ovakvu sintaksu (obilježavanje vrijednosti koja se vraća kao rezultat metode) koristili samo u ovom slučaju.2. Ovo odgovara situaciji kada se participantova metoda nalazi na steku.2 pokazuje distribuiranu kontrolu. ali je poželjnije koristiti to samo u situacijama u kojima tako dobijamo više informacija o interakciji. objekat Customer klase vrši povratni poziv (getBaseValue) objektu Order klase da dobije podatke. jer ona dolazi iz nepoznatog pravca.1 pokazuje centralizovanu kontrolu. Drugi način predstavljanja iste interakcije je dat na slici 4. Tu poruku nazivamo found message.dijagramu ima activation bar koji označava kada je participant aktivan u interakciji. ali su veoma korisni u pojašnjavanju ponašanja objekata. Osnovna stvar koju treba da primijetimo u ova dva dijagrama je kako jasno dijagrami sekvenci pokazuju razlike u načinima na koji učesnici učestvuju u interakciji. u kojoj je procesiranje podijeljeno među sudionicima I svaki sprovodi po dio algoritma. gdje jedan učesnik vrši kompletno procesiranje. Druga stvar koju možemo primijetiti je jasna razlika u stilovima između dvije interakcije. Slično. ali je način na koji učesnici sarađuju drugačiji. strelica za pravac poruke se 24 . Oni nisu dobri da prikažu detalje algoritama. Na dijagramu je pokazano kako metoda getProduct vraća kao svoj rezultat aProduct objekat. kao aProduct za koji je pozvana metoda getPricingDetails. Ponekad se naznačavanje vrijednosti koju metoda vraća koristi za sve pozive metoda u dijagramu sekvenci. Za kreiranje učesnika. Imenovanje je obično korisno za povezivanje učesnika u dijagramu. kao što su petlje I uslovne konstrukcije. Problem je isti. Activation bars su takođe opciona stvar u UML-u. da izračunamo popust. što je isto ime. Kreiranje I brisanje učesnika u interakciji Dijagrami sekvenci posjeduju dodatnu notaciju za kreiranje I brisanje učesnika u interakciji. ali veoma jasno prikazuju pozive metoda između učesnika I daju veoma jasnu sliku o tome koji učesnici procesiraju koju informaciju.

objekti se ne brišu direktno. možemo započeti aktivaciju odmah nakon boxa učesnika.usmjerava direktno prema boxu učesnika. Dijagrame sekvenci treba posmatrati kao vizualizaciju načina na koji objekti komuniciraju.dispatch else regular. ali je I u tom slučaju poželjno stavljati znakove X u dijagrame sekvenci da se označi da neki objekat nije više potreban. Petlje I uslovne komande Uobičajeno pitanje o dijagramima sekvenci je kako prikazati petlje I uslovne komande. ali obično biramo “new”. Ime poruke je ovde opcionalno. a X na kraju linije koja obilježava trajanje učesnika označava brisanje samog sebe. Slika 4. pokazuje jednostavan algoritam baziran na sljedećem pseudokodu: procedure dispatch foreach (lineitem) If (product. koji služe za označavanje dijela dijagrama sekvence.4. Dijagrami sekvenci nisu previše pogodni za ovo. Takođe je pogodan I za operacije zatvaranja. Strelica poruke koja je usmjerena prema X označava da jedan učesnik u interakciji eksplicitno briše drugog.value veceod $10000) careful. U tu svrhu se koriste okviri interakcije. No. U okruženjima koja imaju sakupljače otpadaka. postoji notacija u dijagramima sekvenci koja omogućava korištenje petlji I uslovnih komandi. Ako učesnik izvršava neku radnju odmah nakon što je kreiran.dispatch endif 25 . a ne kao način modeliranja kontrolne logike programa. Brisanje učesnika se označava velikim znakom X. I tada označava da objekat više nije upotrebljiv. zbog preglednosti. I pored toga. za to su pogodniji dijagrami aktivnosti ili pisanje samog koda.

U dijagramima sekvenci postoje dvije vrste poruka koje se mogu slati: sinhronizovane I asinhronziovane poruke. Kada treba koristiti dijagrame sekvenci Dijagrami sekvenci se koriste kada posmatramo ponašanje nekolicine objekata u skolpu jednog use case-a. koristimo loop operator sa jednim jedinim fragmentom I stavljamo bazu iteracije u čuvara.endfor if (needsConfirmation) messenger. a manje pogodni za precizniju definiciju ponašanja objekata u programu. Za uslovne iskaze. Ako se šalje asinhronizovana poruka.confirm end procedure Generalno. ili više niti izvršavanja. Samo fragment čiji je guard ispunjen će biti izvršen. U dijagramima sekvenci. Dijagrami sekvenci su pogodni za prikazivanje razmjene poruka (kolaboracije) među objektima. Ako učesnik koji šalje poruku drugom učesniku pošalje sinhronziovanu poruku. on mora da sačeka dok se obrada poruke ne završi. Asinhronizovane poruke susrećemo u programa koji imaju više niti izvršavanja (threads). okvirovi se sastoje od nekog regiona dijagrama sekvence koji je podijeljen u jedan ili više fragmenata. onda je bolje koristiti dijagrame stanja. asinhronizovane poruke se obilježavaju “polustrelicama”. Svaki okvir ima operator a svaki fragment može imati čuvara. 26 . Ako želimo da posmatramo ponašanje jednog objekta kroz više use case-ova. može se koristiti alt operator I staviti uslov u svaki fragment. za razliku od sinhronizovanih. on ne mora da čeka na odgovor I može nastaviti sa procesiranjem. Ako želimo posmatrati ponašanje više objekata u više use case-ova. Da prikažemo petlju. za to su pogodni dijagrami aktivnosti. koje se označavaju kompletnim strelicama. Ako postoji samo jedan region. onda se koristi opt operator.

Ovo je veoma korisno kada su moguće veze između objekata previše komplikovane. zbog toga što su im imena podvučena. :Person. a ne kompletne instance klase. elementi dijagrama objekata su specifikacije instanci. nekoliko dijagrama objekata u potpunosti “rasvjetljavaju” situaciju. umjesto samih klasa. U dijagramima objekata možemo da prikažemo vrijednosti atributa I veza. ili da prikažemo instance apstraktnih klasa. Dijagrami objekata mogu da se koriste da se prikaže primjer konfiguracije objekata. ali da ta struktura bude još uvijek nejasna.DIJAGRAMI OBJEKATA Dijagram objekata predstavlja sliku objekata u sistemu u nekom određenom trenutku. dijagram objekta obično zovemo I instancni dijagram. To je zbog toga što je sasvim u redu da izostavimo vrijednosti atributa koje nas u datom trenutku ne zanimaju. Svako ime uzima sljedeći oblik : ime_instance:Ime_klase. Ako koristimo samo ime klase. tako da ime objekta može biti John. U mnogim situacijama. Pošto ovaj tip dijagrama prikazuje instance klasa. Striktno govoreći. Oba dijela imena su opcionalna. aPerson. Specifikacija instance se može shvatiti kao nepotpuno definisana instanca. U ovim situacijama. Primjer dijagrama objekta dat je na slici 6. Odmah možemo da vidimo da su elementi dijagrama na toj slici instance klasa. Dijagrami objekata su korisni za pokazivanje primjera objekata koji su povezani zajedno. možemo definisati strukturu programa veoma precizno sa dijagramom klase. onda moramo da stavimo dvije tačke ispred imena klase.2. 27 .

možemo koristiti potpuno kvalifikovano ime ili. paketi su prikazani pomoću foldera sa zaglavljem. Da bismo razlikovali dvije klase sa istim imenom koje pripadaju različitim paketima. tako da dobijamo hijerarhijsku strukturu u kojoj su paketi na vrhu razbijeni u podpakete. čak to tačke kada možemo uključiti I kompletan dijagram klase unutar paketa. što znači da svaka klasa mora imati jedinstveno ime unutar svog paketa. Svaki paket predstavlja jedan prostor imena (namespace). kao na slici 7. tj. koji opet imaju svoje podpakete itd. sve što treba da uradimo je da je smjestimo u neki drugi paket. Paketi takođe mogu biti dijelovi drugih paketa. U folderu možemo prikazati samo ime paketa ili I njegov sadržaj. Javna klasa je dio interfejsa paketa I može se koristiti u klasama u drugim 28 . svaka klasa je dio jednog paketa. koristimo potpuno kvalifikovano ime. U bilo kojoj situaciji. UML dozvoljava da klase u paketu budu privatne ili javne. Paket je struktura koja omogućava da grupišemo elemente bilo koje UML konstrukcije u jedinice višeg nivoa. Prikazivanje sadržaja sa ikonama klasa dozvoljava nam da prikažemo sve detalje klasa. U UML-u modelu. Npr. jednostavno. Najčešća upotreba paketa je grupisanje klasa. ali treba zapamtiti da pakete možemo koristiti I za sve ostale elemente UML-a. Paket može sadržavati istovremeno I podpakete I klase.DIJAGRAMI PAKETA Klase predstavljaju osnovni oblik strukture objektno orjentisanog sistema. Ako želimo da kreiramo klasu Date. da prikažemo strukturu velikog sistema koji se sastoji od stotina klasa. U dijagramima. a ta klasa već postoji u System paketu. Npr. MartinFowler::Util::Date. Međutim. regularna imena. Sve do paketa na dnu koji sadrže same klase. Jednostavno izlistavanje samo imena klasa je sasvim dovoljno ako samo želimo da pokažemo koja klasa je u kojem paketu. I to ćemo opisati u dijelu koji se odnosi na dijagrame paketa. Ime koje pokazuje klasu I pakete koji su vlasnici te klase.1. potrebno nam je nešto više od toga. Potpuno kvalifikovana imena su System::Date ili npr.

Iako je to dobar indikator dobro struktuiranog sistema. je izuzetak ovog “pravila”. skiciranje dijagrama paketa je veoma važna stvar koja pomaže da se kontroliše cjelokupna struktura sistema. Iako ovo nije apsolutno pravilo.2). Kako odlučujemo koje klase smjestiti u koje pakete? Ovo je prilično kompleksno pitanje koje zahtjeva iskustvo u dizajnu softvera da bi se odgovorilo na njega. Idealno. zavisnosti između paketa sumiraju zavisnosti njihovog sadržaja. Data mapper paketi se ponašaju kao insulating layer između paketa domena I baze podataka. U srednjim I velikim sistemima. oni bi trebalo da budu lokalizovani. glavni razlozi grupisanja klasa u pakete imaju veze sa zavisnostima između paketa. 29 . na šta ćemo sada da obratimo pažnju. Veoma je poželjno da nema ciklusa u zavisnostima među paketima. a ako već imamo cikluse u zavisnostima. Paketi I zavisnosti Dijagram paketa pokazuje pakete I njihove zavisnosti. Ovo se može postići tako što ćemo sve klase u paketu proglasiti privatnima. onda imamo zavisnost od paketa prezentacije prema paketu domena ako bilo koja klasa iz paketa prezentacije ima zavisnost prema bilo kojoj klasi paketa domena. Princip zajedničkog zatvorenja govori da klase koje se nalaze u istom paketu zahtijevaju promjene zbog sličnih razloga. Drugačija programerska okruženja imaju drugačija pravila o vidljivosti između dijelova njihovih paketa. dijagram bi trebao da se generiše iz samog izvornog koda programa. Princip zajedničkog iskorištenja kaže da klase u paketu treba da budu ponovoiskoristljive (!) zajedno. Dobra struktura paketa ima jasan tok zavisnosti (slika 7. U ovom smislu. jasan tok zavisnosti možemo identifikovati na osnovu toga što sve zavisnosti idu u jednom pravcu. dijagram na slici 7. Obično. tako da se one mogu vidjeti samo od strane klasa iz istog paketa. treba ga slijediti kad god je moguće. Korisna tehnika kod dijagrama paketa je da redukujemo interfejs paketa tako što ćemo u njemu izložiti samo mali podskup operacija koje su dio javnih klasa paketa. I dodavajući dodatne javne klase koje će moći pozivati metode privatnih klasa.2. Ipak. privatna klasa je sakrivena. Dva korisna principa ovde su Princip zajedničkog zatvorenja I Princip zajedničkog iskorištenja. Ako imamo pakete za prezentaciju I domen.paketima. tako da jasno možemo da vidimo šta se gdje nalazi u sistemu.

2. Neki paketi se koriste na mnogo mijesta. relacija realizacije pokazuje da database gateway definiše interfejs. konvencija je da se koriste ključe riječi. Prilično je uobičajeno da interfejsi I implementacije budu u različitim paketima. Implementiranje paketa Često se susrećemo sa situacijom u kojoj jedan paket definiše interfejs koji može biti implementiran od strane nekolicine drugih paketa. kao npr. klientski paketi obično sadrže interfejse drugih paketa. Jedna je struktura nivao aplikacije : prezentacija. Tako u asset domain paketu na slici 7. U praksi.3. Ali. kao na figuri 7. jer ne možemo dodijeliti klase samo jednom paketu (morao bi se izabrati jedan od svakog aspekta). jasno se može vidjeti svaki aspekt. ponovo. Druga vrsta struktura su oblasti subjekata : leasing and assets. Iako su dijagrami kao onaj na slici 7. posmatrajmo sliku 7. kao npr. Relacija zavisnosti nije tranzitivna. Ako se klasa u asset domain paketu promijeni.4. “global”. oni su veoma pogodni za objašnjavanje strukture kompleksne aplikacije. Aspekti paketa Na slici 7.Što više zavisnosti ulazi u paket. u paketu. a da druge gateway klase obezbjeđuju impelementaciju. Ipak. možemo primijetiti da dijagram ima dvije vrste struktura. ovo bi značilo da database gateway paket sadrži interfejse I apstraktne klase koje su implementirane u ostalim paketima. domen. Da bismo primijetili zašto je to važno za zavisnosti.2.2. jer tada bilo koja promjena u njegovom interfejsu ima odjek u svim paketima koji zavise od njega. U ovom slučaju. interfejs mora da bude stabilniji nego u leasing data mapper paketu. Na ovom dijagramu. U tom slučaju. Zaista. ova dva aspekta nisu pravi paketi. ova promjena ne mora obavezno da doseže do leasing presentation klase (doseže ako leasing domain paket promijeni svoj interfejs). nestandardni u UML-u. data mapper I baza podataka. Ovo se može učiniti još jasnijim ako razdvojimo ova dva apsekta. I bilo bi previše da crtamo sve linije zavisnosti prema njima. Na slici 7.3. 30 . utoliko više mora da bude stabilan interfejs paketa. postoji mogućnost da se moraju promijeniti I klase u leasing domain paketu.

Pretpostavimo da želimo da omogućimo neki korisnički interfejs. Crtanje dijagrama paketa I zavisnosti između njih nam pomaže da držimo zavisnosti aplikacije pod kontrolom. grijači I svjetla. Korisnički interfejs treba da pozove metode grijača. Kada treba koristiti dijagrame paketa Dijagrami paketa su veoma korisni u velikim sistemima da bismo dobili sliku o zavisnostima između glavnih elemenata sistema. 31 . Želimo da ovo radi sa mnogo različitih stvari. kao na slici 7. recimo.5. Ovu zavisnost možemo da izbjegnemo tako što ćemo definisati u paketu kontrola interfejs koji je onda implementiran u bilo kojoj klasi koja želi da radi sa ovim kontrolama. koji će uključivati I isključivati neke stvari. kao što su. ali ne želimo da on ima zavisnost prema grijaču.

povezani komunikacionim kanalima.1. HTML dokumenti itd. u suštini. Čvorovi sadrže artifakte. Čvorove ili artifakte možemo obilježiti oznakama da bismo prikazali interesantne informacije o čvoru. konfiguracione biblioteke. to može biti kompjuter ili neki drugi hardver priključen na sistem. kao što su proizvođač. kao što je učinjeno na slici 8. Ovi fajlovi mogu biti izvršni fajlovi. Ako se prikazuju kao boxovi klasa. Obično imamo više fizičkih čvorova koji izvršavaju isti logički zadatak. je jednostavan primjer dijagrama razvoja. Artifakti se mogu prikazati kao boxovi klasa ili izlistavanjem imena u čvoru. Glavni elementi dijagrama su čvorovi. Izlistavanje artifakta u čvoru pokazuje da je artifakt smješten (razvijen) na taj čvor u sistemu. Ovo možemo prikazati ili korištenjem više boxova čvorova ili navođenjem broja u sklopu oznake čvora. Oni su. Čvorovi se pojavljuju u dva oblika. koji predstavljaju fizičku manifestaciju softvera: obično fajlove. Komunikacioni putevi između čvorova pokazuju kako stvari komuniciraju. 32 . primjeri čega su operativni sistem ili kontejner procesi. Uređaj je hardver. Čvor je nešto što može da izvrši neki softver.DIJAGRAMI RAZVOJA Dijagrami razvoja prikazuju fizički izgled sistema. veoma jednostavni. Izvršno okruženje je softver koji izvršava drugi softver. pokazujući koji dijelovi softvera se izvršavaju na kojim dijelovima hardvera. operativni sistem.1. Ove komunikacione puteve možemo označiti informacijom o komunikacionim protokolima koje oni koriste. Slika 8. možete dodati ikone dokumenata ili ključnu riječ “artifact”. lokacija ili bilo šta drugo što smislimo. fajlovi sa podacima.

i to bi bio treći scenario. Use case-ovi se zasnivaju na opisivanju tipične interakcije izmedju korisnika sistema i samog sistema. Svi ovi scenariji su različiti. Akter je uloga koju korisnik igra u odnosu na sistem. on daje informacije o transportu i kreditnoj kartici i potvrđuje prodaju. Akteri mogu da uključuju kupca. od koje ne morate da pribavljate podatke o transportu i kreditnoj kartici. i to bi bio poseban scenario. ali ipak i slični. kao i e-mailom koji šalje kupcu. predstavnika službe za odnose sa kupcima. možda je u pitanju stalna mušterija. ako imamo on line prodavnicu. U drugom slučaju.USE CASE DIJAGRAMI Use case dijagrami su tehnika za prikazivanje funkcionalnih zahtjeva sistema. Ako sistem služi za drugi kompjuterski sistem. Takođe. tako da mnogo ljudi mogu da budu akteri kupci. pak. i obrnuto. Korisnici se u use case-u označavaju kao akteri. Scenario je sekvenca koraka koji opisuje interakciju između korisnika i sistema. Obično postoji mnogo kupaca. lakše je da im pristupimo indirektno i počnemo opisujući scenarije. mušterija ima isti cilj: da kupi proizvod. kao menadžer prodaje koji obavlja i zadatke službe za odnose sa kupcima. Sistem autorizuje vlasništvo nad karticom i potvrđuje prodaju odmah. Akteri izvrsavaju use case-ove. Kada kupac želi da plati. Jedan akter može da izvršava više use case-ova. tada je taj drugi sistem akter. Umjesto da opisujemo direktno use case-ove. jedna osoba može da funkcioniše kao više aktera. Ovaj cilj je ključ za upotrebu use case-ova: use case je set scenarija koji su povezani zajedničkim ciljem korisnika. obezbjeđujuci objašnjenje kako se sistem koristi. Akter ne mora da bude osoba. Međutim. autorizacija kartice može da ne uspije. 33 . npr. mogli bismo imati “Kupiti produkt” scenario koji će imati sljedeći oblik: Kupac lista katalog i dodaje željene produkte u korpu za kupovinu. use case može da ima nekoliko aktera koji ga izvršavaju. Ovaj scenario prikazuje kako se stvar može odvijati. Tako. u sva tri scenarija. Suština njihove sličnosti je da. menadžera prodaje i analitičara produkta.

Ništa u UML-u ne opisuje kako bi trebalo obuhvatiti sadržaj use case-a. Nastavljamo slijed koraka na isti način kao što je ucinjeno u scenariju glavnog uspjeha. a dijagram ima prilično ograničenu vrijednost. Očito. pokazuje uobičajeni stil koji se koristi. a akter je termin koji koristi zajednica use case-ova. mada ne uvijek. opisujući ih kao varijacije glavnog uspješnog scenarija. Međutim. koji poziva sistem da isporuči uslugu. Ali. ne opisujemo korisnički interfejs u use case-u. iznenađuje da je definicija use case-ova u UML-u prilično oskudna. uloga bi bio mnogo bolji. Use cases su poznati kao važan dio UML-a. postojati I drugi akteri sa kojima sistem komunicira dok izvršava use case. Svaki use case ima primarnog aktera. Dakle.1. Figura 9. Oni su poznati kao sekundarni akteri. Ekstenzija unutar use case-a označava uslov koji rezultuje drukčijim interakcijama od onih koje su opisane u scenariju glavnog uspjeha (Main Success Scenarion . Ekstenziju započinjemo imenovanjem koraka na kojem je uslov prepoznat i obezbjeđujemo kratak opis stanja. a ne mehanizam onoga što akter čini. to je pogrešan prevod sa švedskog. Mogu.ili kao neuspješne (kao u 6a).Akter nije pravi termin. Nakon toga uzimamo druge scenarije i pišemo ih kao ekstenzije. Korak bi trebalo da pokaže namjeru aktera. Ekstenzije mogu biti prikazane kao uspješne – gdje korisnik postiže cilj (3a) . Sve što UML opisuje je use case dijagram. Tijelo use case-a počinjemo opisujući glavni uspješan scenario kao sekvencu numerisanih koraka. takođe. U stvari. začetnik use case-a.MSS) i govori koje su to razlike. Svaki korak u use case-u je jedan elemenat interakcije između aktera i sistema. Primarni akter je akter čiji cilj use case nastoji da zadovolji i obično je. skoro sva vrijednost use case-a leži u sadržaju. pisanje use case-a obično prethodi modeliranju korisničkog interfejsa. Use Case-Sadržaja Ne postoji standardan način da se opiše sadržaj use case-a i različiti oblici dobro funkcionišu u različitim slučajevima. Počinjemo tako što uzmemo jedan od scenarija kao glavni uspješan scenario. Slijed završavamo 34 . koji pokazuje kako se use case-ovi odnose međusobno. Svaki korak bi trebalo da bude jednostavan iskaz i trebalo bi da jasno pokaže ko ga izvršava.

Vjerovatno ćete na ovaj nacin smisliti više alternativa. Komplikovani koraci u use case-u mogu biti drugi use case-ovi. 3A : Ako je mušterija redovna mušterija 1. Sistem potvrđuje prodaju odmah 8. Obično je najbolje da razmotrimo sva stanja ekstenzija prije nego što se zapetljamo liječeći posljedice nečega što nije pošlo kako treba. Mušterija prelistava katalog I izabira proizvod koji želi da kupi 2. što znači da ćete poslije imati manje bugova za otklanjanje u samom programu. Sistem prikazuje trenutnu adresu I broj kreditne kartice za mušteriju 2. ali podvlačenje. Kupovina proizvoda Scenario glavnog uspjeha: 1. koje sugeriše hiperlink. Sistem šalje e-mail u kojem se potvrđuje prodaja Proširenja. služi veoma dobro I da će u mnogim 35 . Sistem autorizuje transakciju 7. Sistem prikazuje kompletnu cijenu (zajedno sa dostavom) 5.pokazujući gdje se vraćamo u glavni scenario uspjeha. U UML terminologiji.1 Use case struktura je veoma pogodan način da razmotrimo alternative scenarija glavnog uspjeha. Za svaki korak se pitamo: “Kako bi ovo moglo da se odvija drugačije?”. Mušterija unosi podatke o kreditnoj kartici 6. ako to uopšte činimo. Mušterija može pokušati sa unosom druge kreditne kartice ili poništiti transakciju Slika 9. Mušterija završava prelistavanje I prelazi na uplatu 3. Korisnik može prihvatiti ove podatke ili ih promijeniti 6A : Sistem ne prepoznaje kreditnu karticu 1. Ne postoji standardan način da se prikaže sadržani use case u tekstu. a narocito: “Šta bi moglo da pođe krivo?”. Mušterija popunjava informacije o isporuci (adresa I datum isporuke) 4. kažemo da prvi use case ukljucuje (sadrži) drugi.

Iako je dijagram ponekad koristan. Garancije uspjeha važe u slučaju uspješnog scenarija.   Kada razmatramo dodavanje elemenata. stalno treba nastojati da use case bude kratak i lak za čitanje. drugi mogu da budu skicirani neposredno prije nego što se primjenite. U razmatranju use case-ova ne treba ulagati previše napora u sam dijagram.alatima to zaista I biti hiperlink. prvi korak uključuje use case “pregledaj katalog i izaberi artikle za kupovinu”. Uključeni use case-ovi mogu biti korisni za kompleksne korake koji bi opteretili glavni scenario ili za korake koji se ponavljaju u više use caseova. UML je nije striktan u odnosu na sadržaj use case-a. Use Case Dijagrami Kao što je rečeno ranije. Osim koraka uključenih u scenario. ali obezbjeđuje format dijagrama za njihovo prikazivanje. treba biti oprezan. Često su potrebni detalji samo za nekoliko ključnih use case-ova na početku projektovanja. Dakle. minimalne garancije važe u slučaju bilo kojeg scenarija. na slici 9.1. Količina detalja koja je potrebna u use case-u zavisi od količine rizika u tom use case-u. Umjesto toga.2. Garancija opisuje šta će sistem osigurati na kraju use case-a. kao na slici 9. Triger označava događaj koji pokreće use case. u use case možete da dodate I neke druge uobičajene informacije. 36 .  Pre-stanje opisuje šta bi sistem trebalo da obezbijedi kao preduslov prije nego što sistem dopusti da use case otpočne se izvršavanjem. bolje se skoncentrisati se na tekstualni sadrzaj use case-a. on nije obavezan. Bolje je dodati premalo elemenata. To je korisno da bi programeri znali koje uslove ne moraju da provjeravaju u svom kodu. Takođe. nego previše.

Osnovni use case-ova su na “sea level”. use case-ove i relacije među njima:   Koji akter izvršava koji use case Koji use case-ovi sadrže druge use case-ove Nivoi Use Case-a Čest problem sa use case-ovima je da. Često se može čuti kako se govori o sistemskim use caseovima i biznis use case-ovima. možemo da zanemarimo situacije u kojima je prelazak na biznis proces može da bude najbolji nacin da se problem riješi. usredsređujuci se na interakciju između korisnika i sistema. dok biznis use case razmatra kako biznis odgovara kupcu ili događaju. ali. Ovi izrazi nisu precizni. Sea level use case-ovi tipično predstavljaju pojedine diskretne interakcije između primarnog aktera i sistema. On je. jer prikazuje granice sistema i interakcije sa spoljašnjim svijetom. sistemski use case je interakcija sa softverom. Use case dijagram prikazuje aktere.Najbolji način razmisljanja o use case dijagramu je da je on grafička tabela sadržaja za skup use case-ova. koji se koristi u struktuiranim metodama. uopšteno. Takvi use caseovi će isporučiti nešto vrijedno primarnom akteru i obično je primarnom akteru za to potrebno od nekoliko minuta do pola sata za kompletiranje 37 . takođe slican dijagramu sadržaja. Cockburn predlaže shemu nivoa use case-ova.

Velika opasnost rada sa use case-ova je što se nekada mogu napraviti komplikovanijima nego što je to potrebno. Kite-level use case-ovi su obično biznis use case-ovi. Kod use case-ova pažnju treba koncentrisati svoju energiju na njihov tekst nego na dijagram. bezbolnije će biti uraditi suviše malo. Viši. Poželjno je označiti nivo na vrhu use case-a. kao na slici 9.1 Kada koristiti Use Case-ove Use case-ovi su vrijedno sredstvo pomoći za razumijevanje funkcionalnih zahtjeva sistema. Use cases koji postoje samo zato jer su sadržani u sealevel use case-u su fish level.tog use case-a. Mnogo detaljnije verzije use case-ovi bi trebalo da budu napravljene neposredno prije razvijanja tog use case. Nekoliko stranica po jednom use case će za većinu slučajeva biti savim dovoljno. ne treba očekivati bilo kakve korelacije između use case-ova I klasa unutar sistema. 38 . Kao takav. tekst je taj koji sadrži svu vrijednost tehnike. Prvi osvrt na use case bi trebalo napraviti rano. Važno je zapamtiti da use case predstavlja vanjski izgled sistema. Obično. dok su sea i fish nivoi sistemski use case-ovi. Uprkos činjenici da u UML ne postoje pravila o tekstu use case-a. Najveći broj use case-ova koje pravimo bi trebalo da bude na sea nivou. nego da uradite previše. kite-level use case-ovi pokazuju kako se sea-level use case-ovi uklapaju u šire biznis interakcije.

Fork čvor ima jedan ulazni tok i više izlaznih tokova. To u suštini znači da poredak medju njima nije bitan. takodje.DIJAGRAMI AKTIVNOSTI Dijagrami aktivnosti su tehnika za opisivanje proceduralne logike I toka programa. ispuniti narudžbu i onda izvršiti dostavu. poslati račun. Moguće je prvo ispuniti narudžbu. Moguće je. i akcije koje im slijede izvršavaju paralelno.1 prikazuje jednostavan primjer dijagrama aktivnosti. izvršiti dostavu i primiti novac od narudžbe. Počinjemo sa akcijom na početnom čvoru i izvršavamo akciju "Primi Narudžbu". Nakon što se ta akcija obavi.1 naznačava da se akcije “Popuni Narudžbu” i “Pošalji Račun”. nailazimo na fork čvor. 39 . Slika 11. Slika 11. i poslati račun. primiti novac od narudžbe.

izvršava se "Hitna Isporuka". Korištenje [else] kao čuvara znači da će [else] tok biti izvršen ako svi ostali čuvari imaju vrijednost [false]. Možemo uzeti dio dijagrama 11. Poziv metoda se može prikazati sintaksom ime-klase::ime-metoda 40 . Svaki tok koji izlazi iz grane ima po jednog "čuvara". Čvor spajanja predstavlja kraj uslovnog ponašanja započetog odlukama. dakle uslovi u čuvarima moraju biti međusobno isključivi. dijagram samo navodi osnovna pravila o nizu radnji koja se trebaju slijediti. Takodje je bitno za konkurentne algoritme. Uslovno ponašanje je određeno odlukama i spajanjima. Na slici 11. možemo odabrati samo jedan od tokova koji vode iz nje. Dakle. koja se naziva grana u UMLu. u kojima se nezavisne "niti" (threads) mogu izvršavati paralelno. Kada god dođemo do odluke. dijagram aktivnosti prikazuje jednu aktivnost koja se sastoji od više akcija. ima jedan tok koji ulazi u nju i više tokova koji iz nje izlaze. neophodna je i sinhronizacija. Odluka.1. i definisati zasebnu aktivnost (kao na slici 11. Ne možemo zatvoriti narudžbu sve dok ona nije isporučena i dok za nju nije plaćeno. Ako je narudžba hitna. preduzimamo akciju "Zatvaranje Narudžbe" tek kada su izvršene akcije isporuke i akcija "Primanje Plaćanja".Dijagram aktivnosti dopušta da onaj ko izvršava proces na njemu. Akcije mogu biti implementirane ili kao podaktivnosti. ili kao metode klasa. i jedan tok koji izlazi iz njih. Boolean izraz postavljen unutar uglastih zagrada.1 koji se odnosi na isporuke. izabere poredak u kojem će izvrsiti radnje. tj. Kada imamo paralelizam. Čvorovi spajanja imaju više tokova koji ulaze u njih. Čvorovi na dijagramu aktivnosti se nazivaju akcije. nakon što je narudžba popunjena. inače. donosi se odluka. Drugim riješima. Ovo je važno za biznis modelovanje jer se procesi obično desavaju paralelno.2) za to. tok koji izlazi iz njega započinje tek kada svi tokovi koji ulaze u njega dostignu join čvor. Dakle. Kada imamo join. Ovo prikazujemo preko join čvora na dijagramu. a sekvenca akcija se naziva aktivnost. izvršava se "Regularna Isporuka". Dekompozicija akcije Akcije mogu biti razložene u podaktivnosti.

Ovo obično i nije problem.3). ako akcija nije samo jedan poziv metoda. U programiranju. Takođe se moze napisati i mali fragment koda u simbol akcije. Slika 11. Slika 11. ali ne govore o tome koju akciju ko izvršava. jer je obično bitno koncentrisati se na to šta treba da se uradi. ovo znači da nam dijagram ne pokazuje koja klasa je odgovorna za koju akciju. možemo podijeliti dijagram aktivnosti na particije. koje pokazuju koje akcije jedna klasa ili organizacija izvršava. Particije na slici 11. 41 . a ne ko to treba da uradi.2 Particije Dijagrami aktivnosti nam govore šta se dešava u jednoj aktivnosti.4 su jednostavne jedno-dimenzionalne particije.(Slika 11. Moguće je napraviti i dvodimenzionalne particije.4 pokazuje jednostavan primjer ovoga. Ako želimo da pokažemo ko šta radi. pokazujuci kako akcije uključene u procesiranje narudžbe mogu biti razdvojene među različitim odjelima.

Slika 11.3 42 .

4 Signali U primjeru na slici 11. dijagrami aktivnosti imaju jasno označenu tačku početka. Slika 11. koja predstavlja poziv programa ili rutine. Signal vremena se pojavljuje zbog protoka vremena. Akcije takođe mogu odgovarati i na signale. Takvi signali mogu predstavljati kraj mjeseca u finansijkom periodu ili mikrosekundu u kontroleru u realnom vremenu.1.Slika 11.5 prikazuje aktivnost koja prati pojavljivanje dva signala. Signal označava da je aktivnost primila izvještaj o nekom događaju od 43 .

5 Osim što mozemo odgovarati na signale.6 44 . Slika 11.6 prikazuje primjer ovoga. Ovo je korisno kada moramo poslati poruku i sačekati na njen odgovor prije nego što nastavimo sa aktivnošću. ali možemo ih i predstaviti preko nekog toka koji ulazi u njih. možemo ih i slati. Slika 11. s tim što je definisana i akcija koja se izvršava u slučaju da odgovor ne stigne.nekog vanjskog procesa. Primjećujemo da postoji vremenska trka između dva toka na slici . Slika 11. To znači da aktivnost neprekidno “osluškuje” signale i dijagram definiše kako aktivnost odgovara na njih.prvi koji stigne do finalnog stanja prekida drugi. Prihvatači signala obično samo čekaju na neki vanjski događaj.

generisanje izlaza je završeno i prelazi se na "Objavi Novine" aktivnost. neki tokovi mogu da se završe i bez toga da se kompletna aktivnost završi. Na slici 11. Ovakav pristup dozvoljava regionima proširenja da se ponašaju kao filteri. ne mora se posebno označavati. gdje je izlazna kolekcija objekata manja nego ulazna. onda se tok u kojem se on nalazi prekida. Postoji više načina kako se to može prikazati u UMLu. “Izaberi Temu” aktivnost generiše listu tema kao svoj izlaz. Na slici 11.7.9.8. kao na slici 11. Ovaj primjer dopušta da neki članci budu odbačeni. U ovom slučaju imamo isti broj elemenata u ulaznoj i izlaznoj kolekciji. koji moraju u potpunosti da procesiraju svaki element ulaza. Ako se region prosirenja sastoji od samo jedne akcije. preko drugih tokova. 45 . ali najlakši način za to su "Regioni proširenja". To ne mora uvijek da bude slučaj. aktivnost se može i dalje nastaviti. što se označava ključnom riječi "concurrent".Regioni proširenja Sa dijagramima aktivnosti često dolazimo u situaciju kada izlaz jedne akcije proizvodi više izvršavanja jedne druge akcije. u kojem slučaju region proširenja služi kao filter. Svaki element liste tada postaje ulaz za "Napiši članak" aktivnost. Regioni proširenja označavaju dio diagrama aktivnosti gdje se sve akcije ponavljaju po jednom za svaki objekat iz ulazne kolekcije. Međutim.7. jedan po jedan. Može se koristiti i skraćena notacija kao na slici 11. Ovo se označava čvorovima kraja. svaka "Pregledaj Članak" aktivnost proizvodi po jedan članak koji je dodat na izlaznu listu regiona. Kada se aktivnosti izvrše za svaki objekat iz kolekcije na ulazu u region. može da ih bude i manje ili više. Takođe mogu da postoje i iterativni regioni proširenja. Slično tome. svi članci su napisani i pregledani paralelno. Čvor kraja toka U dijagramima aktivnosti. Ako je članak odbačen.

izračunava se izraz u specifikaciji spajanja. akcija spajanja dozvoljava da se izvršavanje nastavi u vanjskom toku samo ako su svi ulazni tokovi došli do akcije spajanja.10 46 .10. kada god izaberemo piće ili ubacimo novčić u mašinu.Specifikacija spajanja Podrazumijevano. Svaki put kada neki tok dođe do tačke spajanja. izraz u specifikaciji spajanja se izračunava i ako je true. Ponekad je potrebna veća kontrola. Specifikacija spajanja je Boolean izraz koji je pridružen spajanju. nastavlja se sa tokom koji izlazi iz spajanja. Međutim. Slika 11. Na slici 11. tok se nastavlja na izlazu iz spajanja samo ako su ispunjeni uslovi u specifikaciji.

PRIMJER PROJEKTOVANJA Razmotrićemo sada jedan primjer modeliranja sistema koji odgovara zadatoj. – – Nacrtaćemo dijagram klasa koji modelira zadati sistem. koji zadovoljava sljedeća ograničenja: – Svaki lift ima m dugmadi. Kada lift stigne do odabranog sprata. Dugme zasvijetli kada se pritisne I lift se pomijera do odabranog sprata. osim prvog I posljednjeg. Jedan od dijagrama klasa koji bi odgovarao problemu je sljedeći : 47 . dugme prestaje da svijetli. Ona prestaju da svijetle kada lift dostigne sprat sa kojeg je pozvan I počne da se pomijera u željenom smijeru (gore ili dole) Kada je lift nepozvan. razmotriti jedan jednostavan Use Case korištenja lifta I nacrtati dijagram sekvenci koji odgovara tom Use Case-u. ima po dva dugmeta: jedno koje poziva lift I sa kojim se ide na viši sprat I jedno sa kojim se ide na niži sprat. Potrebno je projektovati sistem koji kontroliše lift u zgradi sa m spratova. stoji na mjestu sa zatvorenim vratima. Oba dugmeta zasvijetle kada se pritisnu. Svaki sprat. po jedno za svaki sprat. jednostavnoj specifikaciji.

Use Case pozivanja lifta bi mogao biti sljedeći 1. Lift dolazi na trazeni sprat 4. Vrata lifta se otvaraju 5. Vrata lifta se otvaraju 8. Lift se pomijera na trazeni sprat 7. Vrata se zatvaraju 48 . Putnik izlazi 9. Putnik ulazi I pritisce dugme lifta 6. Putnik pritisce dugme sprata 2. Kontroler lifta detektuje koje dugme je pritisnuto 3.