UML

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

1

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

2

2.UML Objedinjen jezik za modelovanje, UML, jeste skup grafičkih notacija zasnovanih na jedinstvenom metamodelu, a služi za opisivanje i projektovanje softverskih sistema, naročito onih koji su napravljeni primjenom u objektno orjentisanih tehnologija. [1] Nastao je objedinjavanjem više objektno orjentisanih grafičkih jezika za modelovanje, koji su razvijeni kasnih osamdesetih i ranih devedesetih godina prošlog vijeka. Graddy Booch, Ivar Jacobson i Jim Rumbaugh su tvorci jeika UML, koji je 1997. godine, postao standard Grupe za upravljanje objektima, Objekt Management Group, OMG. Nastao je kao ideja da se napravi objedinjen jezik za modelovanje koji će omogućavati razmjenu modela između CASE alata. UML omogućuje da se specifikuju, vizuelizuju i dokumentuju modeli softverskih sistema u skladu sa postavljenim zahtjevima. Njime nije moguće samo modelovati neki program, već je moguće pratiti razvoj bilo kakvog objekta, građevine, voćnjaka. Mogu se istaći ciljevi kojima UML kao jezik teži:  Pružiti korisniku brz jezik za vizuelno modelovanje kojim će moći u relativno kratkom vremenu napraviti i razmjenjivati modele sa određenim značenjem.  Pružiti korisniku mogućnost proširenja i stvaranja specijalizovanih dijelova  Biti nezavisan od programskih jezika i razvojnih procesa  Pružiti formalne osnove za razumijevanje jezika za modelovanje  Podsticanje rasta i razvoja objektno orjentisanih programskih jezika  Podrška visoko pozicioniranih razvojnih pojmova kao što su saradnja, okvirni rad, uzorci i komponente UML je razvijen sa ciljem da pojednostavi veliki broj objektno orjentisanih razvojnih metoda. Definišu ga notacija (sintaksa) i metamodel (semantika). Notacija je skup grafičkih elemenata koji se koriste u modelima; to je grafička sintaksa jezika za modelovanje. UML je i osnovni jezik arhitekture MDA, arhitekture zasnovane na modelu, Model Driven Architekture, u okviru kojeg se aplikacija može predstaviti kao:  model nezavisan od platforme Platform Independent Model, PIM To je UML model koji je nezavisan od tehnologije.

3

 model za specifičnu platformu Platform Specifik Model, PSM Model sistema namijenjen određenom izvršnom okruženju. Drugi alati zatim prave kod za tu platformu na osnovu modela PSM. 2.1.STRUKTURA UML-a UML se sastoji od niza pogleda na arhitekturu (Architectural Views) koji zavise od problema i rješenja, a dijele se na:  Pogled korištenja (use case view) pokazuje problem i rješenje onako kako ga vide oni koji postavljaju problem, odnosno definišu se zahtjevi sa stanovišta korisnika.  Logički pogled (logical view) pogled pokazuje strukturnu dimenziju problema rješenja  Pogled paralelnog rada (concurrency view) pokazuje dimenziju ponašanja problema i rješenja, a naziva se još i dinamički pogled.  Pogled na komponente (component view) pokazuje strukturu i ponašanje realizacije rješenja, a naziva se i razvojni pogled.  Pogled postavljanja (deployment view) pokazuje strukturu i ponašanje domena u kome je rješenje ostvareno, a naziva se još i fizički pogled ili pogled na razmještaj. Svaki od pogleda opisan je pomoću jednog od trinaest UML dijagrama. Za gotovo sve sisteme dijagrami predstavljaju poboljšani prikaz elemenata koji čine sistem. Dijagram Aktivnosti Klasa Komponenata Komunikacije Mašine stanja Objekata Paketa Pregleda interakcije Raspoređivanja Sekvence Složene strukture Slučajeva korištenja Vremenski

Svrha Proceduralno i paralelno ponašanje Klase, osobine, veze Strukture i veze između komponenti Interakcija između objekata sa naglaskom na vezi Kako događaji mijenjaju objekat Primjer konfigurisanja instanci Hijerarhijska struktura za vrijeme kompajliranja Kombinacija dijagrama sekvence i aktivnosti Raspoređivanje artefakta po čvorovima Interakcija između objekata Razlaganje klasa tokom izvršavanja Interakcija korisnika i sistema Interakcija između objekata

Tabela 2. Vrste dijagrama

4

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

Strukturne elemente (structural things) Elemente sa ponašanjem (behavioural things) Grupišuće elemente (grouping things) Označavajuće elemente (annotational things) 2.2.STRUKTURNI ELEMENTI

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

Slika 1.Klasa  Interfejs (Interface) je skup poruka koji se može poslati klasi i ne uključuje implementaciju tih operacija. Interfejs se označava krugom i njegovim imenom, nikada ne stoji sam već će biti vezan uz neku klasu ili komponentu koja ga realizuje.

Slika 2. Interfejs

5

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

Slika 3. Učesnik  Slučaj korištenja (use case) prikazuje jednu funkciju sistema kako je vidi spoljašnji učesnik.To je skup sukcesivnih događaja koje sistem izvodi kako bi dobio neki rezultat.

Slika 4. Slučaj korištenja  Komponenta (component) je fizički dio sistema koji je saglasan sa skupom interfejsa i pruža njihovu realizaciju.

Slika 5. Komponenta  Čvorovi su obično fizički elementi koji postoje tokom rada sistema (obično računarski resursi) koji u opštem slučaju posjeduju memoriju. Takođe, čvorovi često posjeduju sposobnost procesiranja. Skup komponenti se može nalaziti u čvoru, a može da se i premješta od čvora do čvora.

Slika 6. Čvor

6

2.3. ELEMENTI PONAŠANJA Ovaj skup elemenata predstavlja dinamički dio UML modela. Dva su tipa stvari ponašanja.  Interakcija (interaction) je ponašanje koje obuhvata skup poruka koje se izmjenjuju između grupe objekata, a u sklopu određenog konteksta i u cilju izvršavanja specifične svrhe. Ponašanje grupe objekata ili pojedinačne operacije može se specificirati pomoću interakcije. Interakcija sadrži čitav niz drugih elemenata, kao što su poruke, akcije, konektori (veze između objekata) i sl. Grafički se poruka prikazuje punom crtom s označenim smjerom i gotovo uvijek sadrži i ime operacije (). prikaži

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

Čekanje

Slika 8.Stanje

7

2.4.GRUPIŠUĆI ELEMENTI Grupišući elementi predstavljaju organizacijski dio UML. To su „kutije“ u koje se može razložiti UML model. Postoji samo jedan tip grupišućih stvari, a to su paketi.  Paket (package) služi za organizovanje elemenata u grupe. U paket se mogu smjestiti strukturni elementi, elementi ponašanja i drugi grupišući elementi. Paket postoji samo za vrijeme razvoja, dok za vrijeme izvođenja ne postoji.

Slika 9. Paket

2.5. ELEMENTI OZNAČAVANJA Elementi označavanja odnose se na dio UML za objašnjenja. To su komentari koji opisuju, rasvjetljavaju i uvode napomene i ograničenja o elementima modela.  Osnovni element je bilješka (note) koja se pridružuje elementu ili skupu elemenata.

Slika 10. Bilješka

8

2.6. RELACIJE UML ima tri osnovne vrste relacija: Zavisnost (dependency) je semantička relacija između dva elementa u kojoj promjena jednog, nezavisnog, elementa može da utiče na semantiku drugog , zavisnog, elementa.



• Slika 11. Zavisnost  Asocijacija ili pridruživanje je strukturalna veza koja opisuje vezu između objekata. Veza kaže da jedan objekat ima za atribut primjer drugog ili su ti objekti povezani u smislu posjedovanja.  Poseban slučaj asocijacije je agregacija, koja predstavlja strukturnu vezu cjeline i njenih dijelova; nešto ili neko je dio od nečega.

Pridruživanje razdjelnik

reglete Mnogostrukost 1

0..n

Slika 12. Asocijacija Nije određeno Tačno jedan Nula ili više Jedan ili više Nula ili jedan Određeno Višestruko

1 0..* 1..* 0..1 4..6 2,4..6

9

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

parice

kabl

Agregacija

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

roditelj

generalizacija djeca

10

Slika 14. Generalizacija

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

Osoba

klasa

Forma registracije

ime : String veza generalizacije

Algoritam rasporeda

0..n

opšte pridruživanje

1 Profesor

Student

titula : String

Menadzer registracije

smer : String

DodajStudenta(k : Kurs, s : Student) 3..10

1

1 opšte pridruživanje

agregacija

0..4

1..n

4

PonudaKursa

Kurs

lokacija : String Otvori() DodajStudenta(s : Student)

naziv 1..n

1

Otvori() DodajStudenta(s : Student)

11

Slika 15. Dijagram klase

3.2. DIJAGRAM KORIŠTENJA Use Case dijagram Dijagram korištenja predstavila sam pomoću scenarija za prijavu smetnji, kvara, na telefonskim linijama u okviru odjeljenja ispitnog stola. Treba napraviti Use Case dijagram i specifikaciju.

12

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

13

Slika 17. Forma naloga

2.

Sistem prikazuje formu za unos prijavljenog broja.

14

Slika 18. Forma naloga 2

15

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

4. Sistem formira nalog i inicira se štampanje.

16

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

3.3. DIJAGRAM SEKVENCI Sequence diagram Ponašanje sistema se predstavlja sekvencnim dijagramom koji opisuje šta sistem treba da radi, a ne kako. Sekvencni dijagram se pravi za jedan slučaj korišćenja i prikazuje redoslijed izvršavanja sistemskih operacija kao odgovor na istoimene sistemske događaje koje inicira učesnik. Sistemske operacije mogu da uključe parametre, a one mogu da se pridodaju, grupišu u sistem. Grafički, kod sekvencnog dijagrama učesnici se ređaju po x17

osi, a poruke poređane u vremenskom redoslijedu po y-osi. Učesnik koji započinje interakciju, obično se stavlja na vrh sa lijeve strane, a ostali se ređaju udesno. Zatim se unose poruke (na y-osi) koje ti učesnici šalju i primaju (od vrha ka dnu). Oni posjeduju dvije dimenzije: vrijeme i kolekciju objekata. Poruke preko kojih objekti komuniciraju, prikazuju se usmjerenim horizontalnim linijama. Postojanje aktivnosti koju objekt izvodi u vremenu predstavlja se tankim pravougaonikom koji prekriva vremensku osu u vertikalnom pravcu, i u veličini koja odgovara vremenu njegovog postojanja. Na dijagramu sekvenci postoje i rekurzivne poruke. To su poruke koje objekat upućuje samom sebi. Rekurzija je prikazana strelicom koja polazi i završava se u objektu. Poruka je definisana nazivom i parametrima. Ako su dijagrami slučajeva upotrebe prethodno definisani, onda je dijagram sekvenci jedna od realizacija slučajeva upotrebe, koja pokazuje redoslijed događaja koje generišu spoljni učesnici za svaki slučaj upotrebe. Slučaj upotrebe sugeriše način na koji se učesnik nalazi u interakciji sa softverskim sistemom, tj. učesnik generiše događaje.

Slika 19. Dijagram sekvenci

18

Slika 20.Sekvencni dijagram Dijagram sekvenci na slikama 20. i 21. predstavlja redosljed izvršavanja operacija prijavljivanja i realizacije smetnji na telefonskoj liniji.

19

2.Formiranje zapisnika

NalogForma

Broj

PodaciKorisnikaForma

u

smetnji

tehničar Formiranje naloga

Ukucaj broj preuzmipodatke

Prikaži

podatke

izdvoji vrati

Podaci

korisnika podatak

o korisniku

Dodaj

Podatke

ime

prezime

, broj telefona

Nalog

Slika 21.Dijagram sekvenci

20

3.4. DIJAGRAM STANJA MAŠINE State Machine diagram Dijagrami stanja služe za modelovanje dinamičkih aspekata sistema. Dijagramima stanja prikazuju se konačni automati. Dijagram aktivnosti je specijalan slučaj dijagrama stanja u kojem je prisutna većina stanja aktivnosti. Stanje je situacija u životu objekta kada on zadovoljava neki uslov. Objekat ostaje u nekom stanju u konačnom vremenskom intervalu. Dijagram stanja pokazuje odvijanje upravljanja od stanja do stanja. Obično modeluju objekte koji reaguju. Tranzicija pokazuje kretanje od jednog stanja ka drugom.To je relacija između dva stanja koja kaže da će objekat u jednom stanju izvršiti neke akcije pa će ući u drugo stanje. Na sljedećoj slici prikazan je jednostavan dijagram stanja od projekta do izbora izvođača. [nije odrađeno]

Snimanja na terenu

[nije izrađen]

[odradjene]

Izrada projekta

[izrađen]

[nisu ispunjeni uslovi]

Otvaranje ponuda

[konkurs]

Raspisivanje tendera

[odustaje se]

[Izabran izviođač]

Slika 22. Dijagram stanja objekta Projekat

21

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

Određivanje mogućih trasa

Crtanje stambenih objektata

Izrada projekta Revidovanje projekta [nije prošao reviziju]

[prošao reviziju]

Ponovna analiza i rad na projektu

[nije ispunjen uslov za izvođenje]

Tender za izvođača

[ispunjen uslov izvođenja]

Slika 23. Dijagram aktivnosti objekta projekat 22

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

Sadržaj prikazan pomoću dijagrama u bloku

•

Slika 24. Predstavljanje paketa

23

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

•

Slik 25.Paketni dijagram

24

3.7.OBJEKTNI DIJAGRAMI Objekt diagrams Služi za pojašnjenje i ilustraciju složenih dijagrama klasa. Predstavljen je slikama objekata i njihovim međusobnim vezama u određenom vremenskom trenutku. Sastavljen je od objekata i linkova. Linkovi predstavljaju instance veza (asocijacije i agregacije) .

Slika 26. Objektni dijagram

Slika 27. Dijagram relacije između objekata i klasa

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

prostoru, klasa predstavlja apstrakciju, tj. suštinu objekta, pa se može reći da su klase skupovi objekata koji dele zajedničku strukturu i ponašanje. 3.8. DIJAGRAM RASPOREĐIVANJA Deployment diagrams Opisuje fizičku arhitekturu i razmještaj komponenti u toj arhitekturi.

Slika 28. Dijagram raspoređivanja

26

3.9. KOMPONENTNI DIJAGRAM Component dijagram Opisuje programsku podršku (ponekad i hardware) koji čine sistem. Dijagrami komponenti omogućuju fizički pogled na trenutni model. Oni pokazuju organizaciju i zavisnosti između komponenti software-a, uključujući izvorni kôd, binarni kôd i izvršne komponente.

Slika 29. Komponentni dijagram

27

Component

Component

Component

Slika 30. Komponente i veze

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

28

Slika 31. Vremenski dijagram

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

29

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

LITERATURA: [1] Martin Fowler : UML ukratko, Mikro knjiga , Beograd, 2004; [2] Eric J. Naiburg, Robert A. Maksimchuk: UML za projektovanje baza podataka, CET,Beograd, 2001; [3] www.cet.co.yu , 19.01.2008.godine

30

31