Pregled UML-a

UML je jezik za:

 Vizuelizaciju
 Specifikaciju
 Konstrukciju
 Dokumentaciju

artifakta softverski intenzivnih sistema.

UML je jezik

Jezik obezbeđuje rečnik i pravila kojima kombinujemo reči iz rečnika u cilju

komunikacije. Jezik za modelovanje je jezik čiji se rečnik i pravila fokusiraju na
konceptualnu i fizičku reprezentaciju sistema.
Modelovanje se zasniva na poznavanju sistema. Nijedan model sam po sebi nije
dovoljan. Često je potrebno više modela koji su povezani međusobom u cilju
razumevanja i najtrivijalnijeg sistema. Za softverski intenzivne sisteme ovaj zahtev se
odnosi na različite poglede na sistemsku arhitekturu kao i njen razvoj u životnom procesu
razvoja procesa.
Rečnik i pravila jezika kao što je UML nam govore kako da kreiramo i čitamo
dobro formirane modele, ali nam ne govore kako da ih kreiramo. To je uloga procesa
razvoja. Dobro definisani procesi nas vode kroz odluke koje artifakte da kreiramo, koje
aktivnosti i koji radnici će se koristiti, i kako da koristimo ove artifakte u smislu merenja
i kontrole projekta kao celine.

UML je jezik za vizuelizaciju

Za mnoge programere, distanca između razmišljanja o implementaciji a yatim

njene realizacije kroz kod je ravna nuli. Dok razmišljamo, kodiramo. U stvari, neke stvari
je najbolje izraziti direktno kroz kod. Tekst je minimalan i direktan način za predtavljanje
izraza i algoritama.
U takvim slučajevima, programeri dalje radi neko modelovanje, iako potpunao u
glavi. On ili ona, možda čak i vrše neko prestavljanje nekih ideja na papiru. Svejedno, u
takvom pristupu se javljaju izvesni problemi. Prvo, komunikacija ovakvih modela je vrlo
podložna greškama, osim ako svi ne pričaju istim jezikom. Tipično, projekti i
organizacije razvijaju svoje jezike, i vrlo je teško da razumemo šta se dešava ako smo
novi u grupi ili smo izvan grupe. Drugo, postoje neke stvari o softveru koje se ne mogu
razumeti osim ako ih ne predstavimo na neki način koji prevazilazi tekstualne
programske jzike. Na primer, značenje hijerarhije klasa može da se nasluti, ali ne potpuno
sagleda iz koda za sve klase u hijerarhiji. Slično je sa fizičkom distribucijom i mogućom
migracijom objekata u Web-baziranim sistemima. Treće, ako projektant ne prebaci
koncepte modela iz glave u konkretan model, informacija će zauvek biti izgubljena ako
on izađe iz projekta.

1
 Pisanje modela u UML-u se odnosi prvenstveno na sledeću činjenicu: Eksplicitan
model olakšava komunikaciju.
Neke stvari je bolje modelovati tekstualno, ostale grafički. U svim interesantnim
sistemima postoje transcedentne strukture koje se mogu prikazati u programskim
jezicima. UML je grafički jezik.
UML predstavlja više od prostog skupa grafičkih simbola. Tačnije, iza svakog
simbola u UML notaciji stoji bogata semantika. Na ovaj način, jedan projektant može
kreirati model u UML-u a drugi projektant ili lak i neki drugi alat da ga tumači
nedvosmisleno.

UML je jezuk za specifikaciju

U ovom kontekstu, specifikacija označava kreiranje modela koji su precizni,

nedvosmisleni i kompletni. Konkretno, UML se odnosi na specifikaciju svih važnih
odluka o analizi, dizajnu i implementaciji koju vrše projektanti u razvoju softverski
intenzivnih sistema.

UML je jezik za konstrukciju

UML nije vizuelni progamski jezik, ali modeli mogu da se povežu direktno sa
velikom brojem programskih jezika. Ovo znači da je moguće mapirati model iz UML-a u
programske jezike kao što je Java, C++, ili VIusal Basic, ili čak u tabele u relacionoj bazi
podataka, ili prezistene objekte u objektno orjentisanoj bazi podataka. Stvari koje se
najbolje izražavaju grafički se izražavaju u UML-u a tekstualne koncepte u programskim
jezicima.
Ovo mapiranje omogućava forward engeneering: Generisanje koda iz UML-a u
programski jezik. Obrnuto je takođe moguće, rekonstruisanje modela iz implementacije.
To nije u svakom slučaju moguće, ako ne kodiramo informaciju u implementaciji,
informacija je izgubljena kada resauriramo kod. ZAto postoje alati koji zahtevalju
čovekovu intervenciju. Kombinovanje foreward i reverzibilnog inžinjerstva uvode round-
trip inžinjerstvo.
Pored toga moguća je direktna interpretacija UML modela u cilju simulacije,
pošto je on dovoljno nedvosmislen.

UML je jezik za dokumentovanje

Zdrava softverska organizacija proizvodi sve vreste artifakta pre no što se dođe do
sirovog koda. Među ovim artifikatima se nalaze:
 Zahtevi
 Arhitektura
 Dizajn
 Sors kod
 Projektni planovi
 Testovi
 Protipovi
 Verzije

2
 Zavisno od razvojne kulture, neki od artifakta se tretiraju manje ili više formalno.
Takvi artifakti nisu samo rezultati projekta, već imaju veliku važnost u kontrolisanju,
merenju, i komunikaciju o sistemu tokom razvoja projekta i posle projekta.
UML se poziva na dokumentovanje arhitekture sistema i svih njegovih detalja.
Takođe UML obezbeđuje jezik za izražavanje zahteva za testiranje. Konačno, UML
obezbeđuje jezik za modelovanje aktivnosti u planiranju projekata i upravljanju
verzijama.

Gde se može koristiti UML?

UML se prvenstveno koristi u softverski inetnzivnim sistemima. On se koristi

efikasno za domene kao:

 Informacioni sistemi u preduzećima

 Bankarskim i finansijskim servisima
 Telekomunikacijama
 Transportu
 Odbrani-avijaciji
 Medicinskoj elektronici
 Nauci
 Distribuiranim Web-baziranim servisima

UML nije ograničen ma modelovanje softvera. U stvari on je dovoljno

ekspresivan i za modelovanje nesoftverskih sistema, ko što su radni procesi i pravne
oblasti, struktira i ponašanje sistema zdravstvene zaštite, i dizajniranje hradvera.

Konceptualni model UML-a

Da bi razumeli UML potrebno je da formiramo konceptualni model jezika, i to

zahteva poznavanje tri osnovna elementa: osnovni gradivni blokovi UML-a, pravila koja
nam govore kako se ti blokovi povezuju, i neki zajednički mehanizmi koji se prostiru
kroz čitav UML.

Gradivni elementi UML-a

Rečnik UML-a se odnosi na tri tipa gradivnih blokova:

1. Stvari
2. Relacije
3. Dijagrami

Stvari su abstrakcije i to su osnovni članovi modela;relacije ih povezuju

međusobom; dijagrami grupišu interesantne kolekcije nekih stvari.

3
 Stvari u UML-u Postoje četiri gradivnih stvari u UML-u

1. Struktiralne stvari
2. Stvari koje opisuju ponašanje
3. Stvari koje opisuju grupisanja
4. Stvari za anotaciju (obeležavanje)

Ove stvari su osnovni objektno orjentisani gradivni blokovi UML-a i oni se

koriste u cilju formiranja modela.

Strukturalne stvari su imenice UML modela. To su najstatičniji delovi modela i

predstavljaju elemente koji su ili konceptualni ili fizilki (realni). Uopše postoji nekoliko
vrsta strukturalnih stvari.

Prvo klasa, prdstavlja skup objekata koji dele iste atribute, operacije, relacije i
semantiku. Klasa implementira jedan ili više interfejsa. Grafički klasa se crta kao
pravougaonik i često uključuje ime, atribute i operacije.
Window

origin
size

open()
close()
move()
display()

Drugo, interfejs je kolekcija operacija koje specificiraju servis klase ili

komponente. Interfejs dakle opisuje ekterno vidljivo ponašanje datog elementa. Interfejs
može da predstavlja kompletno ponašanje klase ili komponente ili samo deo ponašanja.
Interfejs definiše skup operacija (odnosno njihove signature) ali nikada skup
implementacija operacija. Grafički intersefs je predstavljen krugom i
pridruženimimenom. Interfejs retko stoji sam za sebe. Tipično je pridružen klasi ili
komponenti koja realizuje taj interfejs.

ISpelling

Treće kolaboracija definiše interakciju i predstavlja “društvo” uloga i ostalih

elemenata koje rade zajedno u cilju obebeđivnaj kooperativnog ponašanja koje je veće od
proste sume tih elemenata. Dakle, kolaboracija ima strukturalne kao i dimenzije
ponašanja. Data klasa može učestvovati u nekoliko kolaboracija. Ove kolaboracije dakle

4
predstavljaju implementaciju uzoraka koje čine sistem. Grafički kolaboracija je elipsa sa
siprekidanim linijama u okviru koje se nalazi ime kolaboracije.

Chain of
responsibili

Četvrto use case je opis skupa sekvenci akcija koje sistem izvršava i koje daju
rezultat u vrednostima koje za konkretnog učesnika (actor). Use case se koristi da bi
struktuirali stvari koje opisuju ponašanje u sistemu. Use case se realizuje preko
kolaboracije. Grafički, use case se iscrtava sa elipsom (puna linija), sa pridruženim
imenom.

Place

Ostale tri stvari: aktivne klase, komponente i čvorovi su slične klasama, odnosno
opisuju skup objekata koji dele iste atribute, relacije, relacije i semantiku. Svejedno one
su dovoljno različite i potrebne su u modelu za predstavljanje nekih aspekata objektno
orjentsanog sistema, pa zahtevaju specijalan tretman.
Peto, aktivna klasa je klasa čiji objekti imaju jedan ili više procesa ili tredova i
samim timmože inicirati kontrolnu aktivnost. Aktivna klasa je kao klasa, osim što je
aktivnost njenih objekata konkurentna sa aktivnošću osalih elemenata. Grafički, aktivna
klasa se predstavlja isto kao klasa, sa podebljanom spoljnom linijom.

Event manager

suspend()
flush()

Ostale dve komponente (komponente i čvorovi) su takođe različiti. Oni

predstavlaju fizičke stvari, dok prethodne stvari predstavljaju konceptualne ili logičke
stvari.

5
 Šetsto, komponenta je fizički ili zamenljivi deo sistema kome se obraćamo i koji
obezbeđuje skup interfejsa. U sistemu će biti uključene različiti oblici razvojnih
komponenti, kao što je COM+ komponete ili Java Beans, kao i komponente koje su
artifakti rezvojnog procesa, kao što su sors kod fajlovi. Tipične komponente predstavljaju
pakete ili ostale logičke komponente, kao što su klase, interfejsi i kolaboracije. Grafički
komponente se predstavljaju na sledeći način:

orderform.java

Sedmo, čvorovi su fizički elementi koji postoje u izvršno vreme i predstavljaju

računarski resurs, pri čemu generalno imaju najmanje zajedničku memoriju i često
procesne mogućnosti. Skup komponenata mogu biti na čvoru ili mogu migrirati od čvora
do čvora. Grafički čvorovi se predstavljau kao kocke: sa obično imenom:

Server

Ovih sedam elemenata su osnovne strukturalne stvarikoje možemo uključiti u

UML model. Postoje takođe varijacije ovih sedam modela, kao što su actor-i, signali i
utilities (oblici klasa), procesi i tredovi (oblici aktivnih klasa), aplikacije, dokumenta,
fajlovi, biblioteke, strane i tabele (oblici komponenti).

Stvari koje opisuju ponašanje, su dinamički delovi UML modela. Ovo su

glagoli modela, predstavljajući ponašanje kroz vreme i prostor. Generalno postoje dva
tipa stvari koje opisuju ponašanje.

Prvo interakcija, je ponašanje koje obuhvata skup poruka koje se razmenjuju

između skupa objekata sa konkretnim kontekstom u cilju postizanja specifične uloge.
Ponašanje grupe objekata ili individualne operacije može se specificirati sa interakcijom.
Interakcija uključuje i ostale elemente kao što su poruke, akcione sekvence (ponašanje
koje se izayiva porukama), i linkovi (veze među objektima) . Grafički interakcije se
prikazuju na sledeći način:

display

Drugo state machine, je ponašanje koje specificira sekvencu stanja objekta ili
interakcija koje vrši objekat na određene događaje tokom njegovog životnog ciklusa.
Ponašanje individualne klase ili kolaboracije među klasama mogu biti prikazane sa state
machine. Ona uključuje izvestan broj ostalih elemenata kao što su stanja, tranzicije (tok
od stanja ka stanju), događaji (stvari kao što su trigeri ili tranzicije) i aktivnosti (odgovor

6
na tranzicije). Grafički stanje se prikazuje na sledeći način uključujući ime i eventualno
podstanje (ako postoji)

Waiting

Ova dva elementa (interakcije i state machine) su osnovne strukturalne stvarikoje

uključujemo u UML model. Semantički, ovi elementi obično povezuju razne strukturalne
elemente, i to prvenstveno klase, kolaboracije i objekte.

Stvari koje opisuju grupisanja su organizacioni delovi UML modela. To su

kutije u koje model može biti dekomponovan. Generalno postoji jedna vrsta stvari koje
opisuju grupisanja – paketi.

Paketi su generalni mehanizmi za organizovanje elemenata u grupe. Strukturalne

stvari, stvari koje opisuju ponašanje i čak i druge stvari za grupisanje. Za razliku od
komponenata koje postoje i u vreme izvršavanja, paketi su čisto konceptualni koncepti,
odnosno postoje samo za vreme razvoja. Frafički paket je predstavljeni na način kao na
slici.
Paketi su isnovna stvar za grupisanje komoj mrganizujemo stvari u UML modelu.
Postoje takođe varijacije kao šro su okviri, modeli, podsistemi (oblici paketa).

Business

Stvari za anotaciju su stvari koje služe za opis u okviru UML modela. One
predztavljaju komentari koji nam služe da opišemo, osvetlimo ili nazbačimo nešto u
okviru UML modela. Jedna od osnovnih stvai za anotaciju je note koje predtsavlja
jednostavan simbol za obradu ograničenja pridruženih elementu ili kolekciji elemenata.
Grafički nota se predstavlja na sledeći način:

return copy
of self

7
 Ovaj element je jedan od osnovnih anotacionih stvari koje uključujemo u UML
model. Obično se koriste da bi snabdeli dijagram sa ograničenjima i komentarima koji se
najbolje opisuju formalnim ili neformalnim tekstom. Takođe postoje varijacije ovih
elemenata, kao što su zahtevi (koji opisuju neko željeno ponašanje modela posmatrano
izvan modela).

Relacije u UML Postoji četiri glavan tipa relacija u UML modelu:

1. Zavisnosti
2. Asocijacije
3. Generalizacije
4. Realizacije

Prva, zavisnosti su semantičke relacije između dve stvari u kojima promena jedne
stvari (nezavisne stvari) može da utiče na semantiku druge stvari (zavisne stvari).
Grafički se obeležava na sledeći način (pri čemu može da uključi i labelu):

Druga, asocijacije su strukturalne relacije koje opisuju skup veza, veza između
objekata. Agregacija predstavlja specijalan oblik asocijacije, pri čemu predstavlja
strukturalne relacije među delovima u celini. Grafički se priakzuje na sledeći način (pri
čemu može uključiti i labelu)
0..1

employe employee

Treće, generalizacija je relacija koja opisuje specijalizaciju-generalizaciju u kojoj

objekti specijalizovanog elementa (child) predstavljaju zamenu objekata generalizujućeg
elementa (parent). NA ovaj način, child deli strukturu i ponašanje parent-a. Grafički
generalizacija se priakzuje na sledeći način:

Četvrta, realizacija je semantička relacija među klasifikatorima, gde jedan

klasifikator specificira ugovor za koji drugi klasifikator garantuje da će izvršiti.
Koristimo je na dva mesta: između interfejsa i klasa ili komponenata koji ih realizuju, i
između use case i kolaboracije koje ga realizuju. Predstavljena je na sledeći način:

8
 Ova četiri elemenata su osnovne relacije koje uključujemo u UML modelu.
Takođe postoje varijacije kao što su refinement, trace, include i extend (za zavisnosti).

Dijagrami u UML-u predstavljaju grafičku prezentaciju skupa elemenata, koji se

uglavnom crtaju kao povezan graf oblika (stvari) i linija (relacije). Crtamo dijagrame u
cilju vizuelizacije sistema sa različitih prespektiva. tako da dijagram predstavlja jednu
projekciju sistema. Osim za najtrivijalnije sisteme dijagrami predstavljaju osiromašen
pogled an elemente sistema. Isti element može postojati u svim dijagramima, samo u
nekim dijagramima (najčešći slučaj) ili nigde (vrlo retko). U teoriji, dijagram može
sadržavati bilo koju kombinaciju stvari i relacija. U praksi postoji mali broj kombinacija,
koji su u skladu sa pet najčešćih pogleda koji se poklapaju sa generalnom arhitekturom
softverski intenzivnih sistema. ZZbog toga UML uključuje devet takvih dijagrama:

1. Dijagram klasa
2. Objektni dijagram
3. Use case dijagram
4. Dijagram sekvenci
5. Kolaboracioni dijagram
6. Dijagram stanja
7. Dijagram komponenti
8. Deployment dijagram

Dijagram klasa pokazuje skup klasa, interfejsa, i kolaboracija i njihovih relacija.

Ovi dijagrami su najčešći dijagrami koji se pojavljuju u modelovanju objektno
orjentisanih sistema. Oni predstavljaju statički dizajnerski pogled na sistem. Dijagrami
klasa koji uključuju aktivne klase se odnose na statički pogled na procese sistema.

Objektni dijagram pokazuje skup objekata i njihovih relacija. On predstavlja

statički snapshot instanci klasa iz dijagrama klasa. Ovi dijagrami adresiraju statički
pogled kao i dijagrami klasa ali iz perspektive relanog ili prototipskog slučaja.

Use case dijagram je skup use case-ova i actora-a (specijalni oblik klase) i
njihovih relacija. Oni adresiraju statiči use case pogled na sistem. Ovi dijagrami su
posebno važni u organizovanju i modelovanju ponašanja sistema.

I sekvencijalni i kolaboracioni dijagrami su oblici interakcionih dijagrama.

Interakcioni dijagram pokazuje interakcije, koje se sastoje iz skupa objekata i njihovih
relacija, uključujući poruke koje se razmenjuju među njima. Dijagram interakcija se
odnosi na dinamički pogled na sistem. Dijagram sekvenci je interakcioni dijagram koji
naglašava vremenski redosled poruka; kolaboracioni dijagram je interakcioni dijagram
koji naglašava strukturalnu organizaciju objekata koji primaju i šalju poruke.
Sekvencijalni dijagrami i kolaboracioni dijagrami su izomorfni, što znači da se ne mogu
trensformisati jedan u drugi.

9
 Dijagram stanja pokazuje state machine, koja se sastoji iz stanja, tranzicija,
događaja i aktivnosti. On se odnosi na dinamički pogled na sistem. On je posebno važan
u modelovanju ponašanja interfejsa, klasa i kolaboracija i naglašava red odvijanja
događaja objekata, što je posebno pogodno u modelovanju interaktivnih sistema.

Dijagram aktivnosti je poseban oblik dijagrama stanja koji pokazuje tok među
aktivnostima u sistemu. Odnosi se na dinamički pogled na sistem. Vrlo su važni u
modelovanju funkcija sistema i naglašava tok kontrole među objektima.

Dijagram komponenti pokazuje organizaciju i zavisnosti u skupu komponenti.

Odnosi se na statički implementacioni pogled na sistem. Oni su u vezi sa dijagramima
klasa u kojima se komponente tipično mapiraju na jednu ili više klasa, interfejsa ili
kolaboracija.

Deployment dijagram pokazuje konfiguraciju run-time procesnih čvorova i

komponente koje se tada izvršavaju. Odnosi se na statički pogeld na sistem. U vezi su sa
dijagramima komponenti u kojima čvor obično obuhvata jednu ili više komponenti.

Ovo nije zatvorena lista dijagrama. Mogu se koristiti različiti alati za uključivanje
različitih vrsta dijagrama, iako je ovih devet često upotrebljivo u praksi.

Pravila UML-a

UML gradivni blokovi nemogu slučajno da se povezuju. KAo jezik, UML ima
više pravila koja specificiraju kako dobro formirani model treba da izgleda. Dobro
formiran model je onaj koji je semantički konzistentan, samodovoljan i u harmoniji sa
ostalim povezanim modelima.

UML ima semantička pravila za:

 Imena Kako trebamo nazivati stvari, relacije i dijagrame

 Scope Kontekst koji daje specifično značenje imenu
 Vidljivost Kako se ova imena vide od ostalih korisnika
 Inetrity Kako se stveri korektno i konzistentno odnose prema ostalim
stvarima
 Execution Šta to znači kada izvršavamo ili simuliramodinamički model

Modeli izgrađeni tokom razvoja softverski intenzivnih sistema imaju tendenciju

da evoluiraju i pogu biti posmatrani na različite načine u različitim vremenskim
trenucima. Zbog svega ovoga često je u razvojnim timovima da se razvijaju modeli koji
su dobro formirani ali i koji su:

 Nepotpuni Neki elementi su sakriveni da bi pojednostavili pogled

 Nekompletni Neki elementi nedostaju
 Nekontistentni Nije garantovan integritet modela

10
 Ovakvi, nepotpuni modeli su neizbežni tokom razvoja softevra. Pravila koja UML
omogućuje UML – ali ne forsira – je da se oslonimo na najbitnija pitanja analize, dizajna
i implementacije, a da kasnije te modele doradimo.

Zajednički mehanizmi u UML-u

Građevina je obično jednostavnija i harmoničnija upotrebom detalja koja imaju

zahednička svojstva. U UML to postižemo sa četiri zahednička mehanizma koje
konzistentno primenjujemo u jeziku:

1. Specifikaije
2. Ukrasi
3. Zajedničke podele
4. Mehanizmi za proširivanje

Specifikacije. UML je više od grafičkog jezika. Tačnije, iza svake grafičke

notacije postoji specifikacija koja obezbeđuje tekstualne rečenice i semnatiku datog
gradivnog bloka. Na primer, iza ikone klase postoji specifikacija koja obezbeđuje pun
skup atributa, operacija (uključujući njihove pune signature), i ponašanje koje obuhvata
klasa; vizuelno ikona klase možda prikazuje samo mali deo ovih specifikacija. Nadalje,
može postojati i drugi pogled na klasu, koji prikazuje kompletno različit skup delova a
koji opet ostaje konzistentan sa osnovnom specifikacijom klase. UML grafičku notaciju
koristimo da bi vizelizirali sistem, dok UML specifikacije koristimo da bi uveli detalje
sistema. Za datu podelu je moguće kreirati model inkrementalno crtajući dijagrame i
zatim dodavati semantiku speifikacijama modela, ili direktno otkriti specifikacije,
reverzibilnim inžinjeringom postojećeg sistema, i zatim crtajući dijagrame kao projekcije
na date specifikacije.
UML specifikacije obezbeđuju semantičku osnovukoaj sadrži sve delove modela
sistema, pri čemu je svaki deo u konzistentnoj vezi sa drugim delom sistema. UML
dijagrami su dakle jednostavno vizuelne projekcije ove osnove, pri čemu svaki dijagram
otsvetljava poseban aspekt sistema.

Ukrasi. Najveći broj elemenata u UML-u imaju jedinstvenu i direktnu grafičku

notaciju koja obezbeđuje vizuelnu reprezentaciju najva-nijih aspekata elementa. Na
primer, notacija za klasu je kreirana tako da bi se jednostavno crtala, pošto su klase
najčešći elementi u modelovanju objektno orjentisanih sistema. Notacija klase uključuje i
najvažnije aspekte klase , kao što sui njno ime, atributi i operacije.
Specifikacija klase može sa druge strane da uključi i ostale detalje kao što su
vidljivost atributa i operacija. Mnogi od ovih detalja mogu biti i grafički prikazani kao
gradički ili terstualni ukrasi na osnovnoj notaciji klase.
Primer je dat na sledećoj slicikoja prikazuje klasu koja ima dve public, jednu
protected i jednu private operaciju.

11
 Transaction

+ execute()
+ rollback()
# prority()
- timestamp()

Svaki element u UML notaciji počinje sa osnovnim simbolom, kome možemo

dodati proizvoljan broj ukrasa.

Zajedničke podele. U modelovanju objektno orjentisanog sistema, »svet« je

obično podeljen na više načina.
Prvo, postoji podela na klase i objekte. Klasa je apstrakcija, dok je objekt
konkretna manifestacijate apstrakcije. U UML-u možemo modelovati klase i objekte na
sledeći način:

Jan :
Customer
name
address
phone : Customer

Elyse

Na datoj slici, postoji jedna klasa, čije je ime Customer, zajedno sa tri objekta:
Jan (koji je eksplicitno markiran da pripada Customer objektu), :Customer
(anonimni Customer objekat), i Elyse (koji je u specifikaciji markiran kao
Customer objekat, iako nije ovde eksplicitno prikazano).
Skoro svaki gradivni blok u UML-u ima neki oblik klasa/objekat dihotomije. Na
primer, možemo posmatrati use case i use case i nstance, kompnente i instance
komponenti, čvorove i instance čvorova, itd... Grafički, UML razlikuje objekte
korišćenjem istog simbola kao i klasa pri čemu je naziv objekta jednostavno podvučen.
Drugo, interfejs i implementacija su odvojene stveri. Interfejs deklariše ugovor, a
implementacija predstavlja konkretnu realizaciju ugovora, odgovornog za potpuno
ispunjavanje kompletne semantike interfejsa. U UML-u moguće je modelovati interfejs i
implementaciju na sledeći način:

12
 IUnknow spellingwizard.dll

ISpellin

Na gornjoj slici, postoji komponenta spellingwizard.dll koja

implementira dva interfejsa, IUnknown i ISpelling.
Skoro svaki gradivni blok u UML ima neki oblik implementacija/interfejs
dihotomije. NA primer, mogu postojati use case-ovi i implementacije koje ih realizuju,
kao i operacije i metode koje ih implementiraju.

Mehanizmi za proširivanje. UML obezbeđuje standardni jezik za pisanje

softverskih okvira, ali nije moguće za jedan zatvoreni jezik da bude dovoljan da izrazisve
manifestacije svih modela kroz sve domene kroz svo vreme. Zbog ovoga, UML je
otvoren, ostvarujući moguće proširenja na kontrolisan način. UML mehanizmi
proširivanja uključuju:

 Stereotipove
 Tagged vrednosti
 Ograničenja

Stereotipovi. Proširuju rečnik UML-a, čime dozvoljavaju kreiranje novih oblika

gradivnih blokova koji su izvedeni iz postojećih sali su specifični za dati problem. NA
priemr, ako radite sa programskim jezicim akao što su Java i C++, vi ćete čestomorati da
modelujete exception-e. U tim jezicima, exception je klasa, iako se tretiraju na specijalan
način. Tipično, jedino što želite da im dozvolite je da budu poslani i uhvaćeni i ništa
drugo. Možete da postavite execption-e kao klase prvog reda u vašem modelu – što znači
da ih tretiramo kao osnovne gradivne blokove – markirajući ih kao odgovarajuće
stereotipove, ako overflow na sledećoj slici.

EventQueue
{versions = 3.2
author = egb}

“exception”
overflow
add() {ordered}
remove()
flush()

13
 Tagged value proširuju osbine UML gradivnih blokova, dozvoljavajući vam da
kreirate nove informacije u specifikacji elementa. Na primer, ako radite sa proizvodom
koji ima mnoge verzije i tada želimo da pratimo autore i verzije neke kreitične
apstrakcije. Autor i verzija nije primitiva u UML konceptu. Njih možemo dodtati kao
gradivne blokove, na primer klase, uključujući nove tagged vrednosti datom gradivnom
bloku. Na prethodnoj slici klasa EventQueue je proširena sa tagged vrednostima.

Ograničenja proširuju semantiku UML gradivnih blokova, čime dozvoljavamo

promenu ili modifikaciju postojećih. Na primer, možemo da ograničimo klasu
EventQueue tako da sva dodavanja budu u nekom rasporedu. Na prethodnoj slici se
vide ograničenja na operaciji add.
Kolektivno, ova tri mehanizme proširivanja doyvoljavaju da oblikujemo UML
prema našem projektu. Ovi mehanizmi takođe dozvoljavaju UML-u da se prilagodi novoj
softverskoj tehnologiji (npr. distribuiranim sistemima). Možete dodati nove gradivne
blokove, modifikovati specifikacije postojećim, čak i menjati njihovu semantiku.
Prirodno, važno je da ovo uradite kontrolisano kroz postojeće mehanizme proširivanja.

Arhitektura

Vizuelizacija, specifikacija, konstrukcija i dokumentovanje softverski intenzivnih

sistema zahteva da posmatramo sistem iz različitih perspektiva. Različiti učesnici –
krajnji korisnici, analitičari, integratori sistema, testeri, pisci tehničkih izveštaja, i
menadyeri projekta – svako ima drugačiji plan rada, i svaki posmatra različito sistem u
različitim vremenskim trenucima u životnom toku projekta. Arhitektura sistema je
maožda najvažniji artifakt koji se koristi u upravljanju ovim različitim pogledima i da
tako kontrolišemo iterativni i inkrementalni razvoj sistema kroz njegov životni ciklus.

Arhitektura je skup značajnih odluka o:

 Organizaciji softverskog sistema

 Selekciji strukturalnih elemenata i njihovih interfejsa pomoću kojih je sistem
komponovan
 Njihovih ponašanja, kao što je specificirano u kolaboraciji mešu elementima
 Kompozicija ovih strukturalnih i “ponašajnih” elemenata u progresivno veći
podsistem
 Arhitekturalni stil koji vodi ovu organizaciju: statičke, dinamičke elemente i
njihovih interfejsa, njihovih kolaboracija, i kompozicija.

Softerska arhitektura nije samo pitanje strukture i ponašanja, već i korišćenja,

funkcionalnosti, elastčnosti, mogućnosti ponovnog korišćenja, ekonomije, i tehnoloških
ograničenja (trade-off-ova) i estetskih pitanja.

Kao što pokazuje sledeća slika, arhitektura softverski intenzivnih sistema može
biti prikazana sa pet povezanih pogleda. Svaki pogled je projekcija u organizaciju i
strukturu sistema i fokusira se na praktični aspekt sistema.

14
 vocabulary system assembly
functionality configuration -
Design Implementation management
view view

behavior Use case

view
system topolgy
performace Process Deployment distribution
scalability view view
throughput
delivery
instalaltion

Use case view sistema razmatra use caseo-ve koji opisuju ponašanje sistema
posmatrano od strane krajnjih korisnika, analitičara i testera. Ovaj pogled ne specificira
organizaciju softverskog sistema. Ovo pre svega specificira ono što oblikuje sistemsku
arhitekturu. Sa UML-om, statički aspekt ovog pogleda je obuhvaćen u use case
dijagramima, dok dinamički aspekt ovog pogleda je obuhvaćen dijagramima interakcije,
dijagrami ma stanjai aktivacionim dijagramima.

Design view sistema uključuje klase, interfejse i kolaboracije koji formiraju rečnik
problema kao i rečnik rešenja. Ovaj pogled prvenstveno podržava funkcionalne zahteve
sistema, što uključuje usluge koje koje sistem obezbeđuje korisnicima. Sa UML-om,
statički aspekt ovog pogleda je prikazan u dijagramima klasa i objekata; dinamički aspekt
ovog pogleda se prikazuje interakcionim dijagramima, dijagramima stanja i aktivacionim
dijagramima.

Process view sistema se proširuje na procese i thread-ove koji formiraju

konkurentnost sistema i mehanizme sinhronizacije. Ovaj pogled se prvenstveno adresira
na preformanse, skalabilnost i propusnost sistema. Sa UML-om statiči i dinamički aspekt
ovog pogleda se prikazuje na isti način kao i design view, ali se fokusira na aktivne klase
koje predstavljaju tredove i procese.

Implemntation view sistema se odnosi na komponente i fajlove koji se koriste za

konstruisanje i realizaciju fizičkih sistema. Ovaj pogled se prvenstveno odnosi na
upravljanje konfiguracijom izdanja sistema, koji je napravljen od nezavisnih komponenti
i fajlova koji se sklapaju na različite načine u cilju relizacije sistema. Sa UML-om,
statički aspekt ovog pogleda s eopisuje u dijagramima komponenti; dok se dinamički
aspekt ovog pogleda prikazuje interakcionim dijagramima, dijagramima stanja i
aktivacionim dijagramima.

Deployment view sistema opisuje čvorove hardverske topologije sistema na kojem

se sistem izvršava. Ovaj pogled se prvenstveno odnosi na distribuciju, i instalaciju delova
koji čine fizički sistem. Sa UML-om statički aspekt ovog pogleda se priakzuje

15
deployment dijagramima, dok se dinamički aspekt prikazuje interakcionim dijagramima,
dijagramima stanja i aktivacionim dijagramima

Svaki od ovih pet pogleda može da stoji sam za sebe, čime se fokusiramo na ona
pitanja arhitekture softvera koje nas najviše interesuju. Ovih pet dijagram su i
mešusobnoj vezi – čvorovi u deployment pogledu sadržavaju komponente
implementacionog pogleda koji sa druge strane predstavlja fizičku realizaciju klasa,
interfejsa, kolaboracija i aktivnih klasa iz dizajn i procesnog pogleda. UML omogućava
da izrazite svaki od ova pet pogleda.

Životni ciklus razvoja softvera

UML je pre svega pocesno nezavistan, ćto znači da naije konkretno vezan ni za
koji konkretan životni cilus razvoja softvera. Svejedno, da bi izvukli najviše iz UML-a,
moramo razmatrati procese koji su:

 Use case upravljani

 Centirani oko arhitekture
 Iterativni i inkrementalni

Use case upravljani označava da su use case-ove osnovni artifakti za

uspostavljenje željenog ponašanja sistema i za verifikaciju i validaciju arhitekture
sistema, za testiranje, i komunikaciju među osnovama projekta.

Centrirani oko arhitekture označava da je arhitektura sistema osnovni artefakt za

konceptualizaciju, konstrukciju,upravljanje i ispitivanje sitema koji razvijamo.

Iterativni proces je onaj koji uključuje upravljanje nizom izvršnih izdanja.

Inkrementalni proces uključuje kontinualnu integraciju arhitekture sistema u cilju
relizacije ovih izdanja, pri čemu svako novo izdanje inkrementalno poboljšava prethodnu.
Zajedno iterativni i inkrementalni proces se naziva rizikom upravljani (risk driven) što
znači da je svako novo izdanje fokusirano na napad i redukciju najznačajnijih rizika za
uspeh projekta.

Ovakvi (Use case upravljani, Centirani oko arhitekture i Iterativni i

inkrementalni) procesi mogu da se podele u faze. Faza je vremenski interval između dve
ključne tačke (milestone) procesa, kada se nađe skup dobro definisanih ciljeva, kada
kompletiramo artefakte, i odluke koje donesemo pre no što pređemo na sledeću fazu
projekta. Sledeća slika prikazuje ove četiri faze u životnom razvoju softvera u životnom
razvoju softvera: inspekcija, elaboracija, konstrukcija i tranzicija. Na dijagramu,
workflow je nacrtan u odnosu na faze, čime prikazujemo različite stepene fokusiranja
tokom vremena.

16
 Inspekcija je prva faza procesa, gde praktično “zasejana” ideja projekta je
razvijena do tog nivoa da postaje, bar interno, dovoljna formirana da bi prešli u fazu
elaboracije.

Elaboracija je druga faza procesa, kada se definiše vizija projekta i arhitekture. U

ovoj fazi artikulisani su zahtevi sistema, prioriteti i osnovni temelji. Zahtevi sistema
mogu varirati od rečenica o generalnim vizijama do preciznijih rečenica, pri čemiu svaka
specificira konkretnu funkcionalno ili nefunkcionalno ponašanje sistema i daje osnovu za
testiranje.

Konstrukcija je treća faza procesa, kada se softver prebacuje iz arhitekturalnih

osnovau oblik koji j možemo da izbacimo u korisničku zajednicu. Ovde takođe se zahtevi
sistema, a posebno kriterijumi razvoja se konstanto preospituju u odnosu na potrebe
poslovanja samog projekta, a sa druge strane se alociraju resursi u odnosu na potrebu da
napadamo rizike projekta.

Tranzicija je četvrta faza projekta, kada se softver prebacuje korisnicima. Retko

se razvoj softvera završava na ovoj tačci, već se čak i tokom ove faze softver kontinualno
popravlja, beleže se graške i dodaju se neke mogućnosti softvera se dodatno unapređuju.

Jedan element koji se prostire kroz sve četiri faze je iteracija. Iteracija je odvojen
skup aktivnosti, sa osnovnim planom i kriterijumima razvojakoje rezultiraju u izdanju ili
internom ili eksternom. Ovo znači da se životni tok razvoja softvera u stvari predstavlja
kao niz izvršnih izdanja arhitekture sistema, što samo po sebi povlači i različite poglede
na srhitekturu sistema.

17