UMLUML je standardni jezik za izradu specifikacija, vizualizaciju, kreiranje i dokumentovanje delova sistema. UML (Unified Modeling Language) je kreiran od strane Object Management Group-e (OMG). Prva specifikacija UML 1.0 je izala u januaru 1997. godine. On se razlikuje od drugih standardnih programskih jezika poput C++, Java, itd, jer predstavlja vizuelni jezik. Iako se UML uglavnom koristi za modelovanje softverskih sistema, on se moe koristiti i za modelovanje drugih sistema. UML nije tipian programski jezik ali se moe koristiti da se pomou dijagrama generie kod u razliitim programskim jezicima. On je direktno povezan sa objektno orjentisanom analizom i dizajnom i dovoljno moan da prikae bilo koji koncept koji u njima postoji. Ciljevi UML-a Slika vredi hiljadu rei. Ova poznata misao se u potpunosti uklapa u sutinu diskusije o UML-u. Objektno orjentisani koncepti su predstavljeni dosta ranije od UML-a, pa u to vreme nije postojala standardna metodologija organizacije objektno orjentisanog razvoja sistema. UML se pojavio upravo da bi odgovorio na ove zahteve. Postoji vie ciljeva koji su doveli do razvoja UML-a ali je najvaniji da se definie jezik za modelovanje opte namene koji mogu koristiti svi koji se bave modelovanjem a koji e biti jednostavan za razumevanje i upotrebu. UML dijagrami se ne kreiraju samo za ljude koji se bave kreiranjem softvera ve i za poslovne korisnike, obine ljude i bilo koga ko eli da razume kako funkcionie neki sistem. Ovaj sistem moe ali i ne mora biti softverski. Kao zakljuak moe se rei da UML dijagrami predstavljaju jednostavan mehanizam za modelovanje razliitih praktinih sistema u dananjem kompleksnom okruenju. UML dijagrami Bilo koji kompleksni sistem se moe najbolje razumeti tako to emo ga prikazati putem dijagrama ili slike. Ovi dijagrami imaju uticaj na lake razumevanje. Jedan dijagram nije dovoljan da bi pokrio sve funkcionalnosti sistema. Zbog toga u UML-u postoje razliiti dijagrami pomou kojih je mogue pokriti ove funkcionalnosti. Postoje dve iroke kategorije UML dijagrama koje se dele u svoje podkategorije. Ove kategorije dijagrama su: Strukturalni dijagrami (Structural diagrams) Dijagrami ponaanja (Behavioral diagrams) Strukturalni dijagrami Strukturalni dijagrami predstavljaju statike aspekte sistema. Oni su predstavljeni pomou klasa, interfejsa, objekata, komponenti i vorova. U ovu grupu dijagrama spadaju: Klasni dijagrami Dijagrami objekata

Dijagrami komponenti Dijagrami rasporeda Klasni dijagrami Dijagrami klasa su statiki dijagrami i predstavljaju statiki pogled na aplikaciju. Oni se ne koriste samo za vizualizaciju, opisivanje i dokumentovanje razliitih delova sistema, ve i za konstruisanje izvrnog koda softverskih aplikacija. Klasni dijagrami opisuju atribute i operacije klasa kao i ogranienja koja su postavljena pred sistem. Masovno se koriste u modelovanju objektno orjentisanih sistema jer predstavljaju jedine UML dijagrame koji se mogu direktno mapirati na objektno orjentisane jezike. Ovi dijagrami prikazuju kolekcije klasa, interfejsa, asocijacija, saradnje i ogranienja.

Dijagrami objekata Dijagrami objekata su izvedeni iz klasnih dijagrama pa su objektni dijagrami zavisni od klasnih dijagrama. Objektni dijagrami predstavljaju instancu dijagrama klasa. Osnovni koncepti su slini i za klasni dijagram i za dijagram objekata. Dijagrami objekata takoe prikazuju statiki pogled na sistem, ali ovaj statiki pogled predstavlja sliku sistema u odreenom momentu. Dijagrami objekata se koriste da iscrtaju skup instanci objekata i njihove meusobne veze.

Dijagram komponenti Dijagrami komponenti su po svojoj prirodi i ponaanju drugaiji od klasnih dijagrama i dijagrama objekata. Oni se koriste za modelovanje fizikih pogleda na sistem. Fiziki aspekti su elementi poput izvrnih fajlova, biblioteka, dokumenata itd. koji predstavljaju sistem. Drugim reima, dijagrami komponenti se koriste da prikau organizaciju i odnose meu komponentama u sistemu. Oni ne opisuju funkcionalnosti sistema ve komponente koje se koriste da bi kreirali date funkcionalnosti.

Dijagram rasporeda Dijagrami rasporeda se koriste da prikau topologiju fizikih komponenti sistema, odnosno gde su razmetene softverske komponente sistema. Oni se koriste da opiu statiki prikaz rasporeda sistema. Ovi dijagrami se sastoje od vorova i njihovih meusobnih odnosa. Dijagrami komponenti i dijagrami rasporeda su blisko povezani. Dijagrami komponenti se koriste da opiu komponente a dijagrami rasporeda prikazuju kako su te komponente razmetene po hardveru. UML je dizajniran da se preteno fokusira na softverske inioce sistema. Meutim, ova dva dijagrama su specijalni dijagrami koji se koriste za fokus na softverske komponente i hardverske komponente. Veina UML dijagrama se koristi za logike komponente dok se dijagrami rasporeda koriste da bi se ukazalo na hardversku topologiju sistema.

Dijagrami ponaanja Svaki sistem moe da ima dva aspekta: statiki i dinamiki. Na osnovu ovoga moe se rei da se model smatra kompletnim kada su oba aspekta u potpunosti pokrivena. Dijagrami ponaanja prikazuju dinamike aspekte sistema. Dinamiko ponaanje sistema predstavlja ponaanje sistema kada se on izvrava. U ovu grupu dijagrama spadaju: Dijagrami sluajeva korienja Sekvencijalni dijagrami Dijagrami saradnje

Dijagrami stanja Dijagrami aktivnosti

Dijagrami sluajeva korienja Svrha dijagrama sluajeva korienja je da prikau dinamike aspekte sistema. Meutim ova definicija je suvie opta da bi opisala svrhu jer i drugi dinamiki UML dijagrami (dijagrami aktivnosti, sekvencijalni dijagrami, dijagrami saradnje i dijagrami stanja) takoe imaju istu svrhu. Zbog toga emo sagledati odreenu namenu ovih dijagrama koja ih razdvaja od drugih dijagrama za modelovanje dinamikih osobina sistema. Dijagrami sluajeva korienja se koriste da se prikupe zahtevane funkcionalnosti sistema ukljuujui unutranje i spoljanje uticaje. Dakle, kada se sistem analizira da bi se uvidele njegove funkcionalnosti, kreiraju se sluajevi korienja i identifikuju se uesnici. Oni se sastoje od uesnika, sluajeva korienja i njihovih meusobnih veza. Dijagram se koristi da modeluje sistem ili podsistem aplikacije. Jedan dijagram sluajeva korienja prikazuje odreenu funkcionalnost sistema. Da bi se modelovao ceo sistem koristi se vie ovih dijagrama.

Sekvencijalni dijagrami Sekvencijalni dijagram predstavlja tip dijagrama interakcije. Sekvencijalni dijagram prikazuje vremensku sekvencu poruka koje se alju od jednog objekta ka drugom. On prikazuje redosled poruka. Svrha ovih dijagrama je da prikau interakciju koja se deava u sistemu. Interakcija u sistemu je veoma vana sa gledita implementacije i izvravanja.

Dijagrami saradnje Dijagram saradnje takoe predstavlja tip dijagrama interakcije. Ovi dijagrami opisuju organizaciju objekata u sistemu koji uestvuju u razmeni poruka. Oni se sastoje od objekata i veza. Svrha dijagrama saradnje je slina sa svrhom sekvencijalnih dijagrama. Razlika je u tome to ovi dijagrami prikazuju organizaciju objekata i njihovu interakciju.

Dijagrami stanja Dijagram stanja je jedan od pet UML dijagrama koji se koriste za modelovanje dinamike prirode sistema. On definie razliita stanja objekta tokom njegovog ivotnog ciklusa. Ova stanja se mogu promeniti pomou dogaaja. Dijagram stanja je koristan kod modelovanja reaktivnih sistema. Reaktivni sistem se moe definisati kao sistem koji reaguje na spoljanje ili unutranje dogaaje. Dijagram stanja opisuje tok kontrole iz jednog stanja u drugo stanje. Stanja su definisana kao uslovi u kojima neki objekat postoji a koja se menjaju kada se neki dogaaj izvri. Na osnovu ovoga se moe rei da je najvanija svrha dijagrama stanja da modeluju ivotni ciklus objekta od njegovog kreiranja do njegovog unitenja.

Dijagrami aktivnosti Dijagram aktivnosti je jo jedan vaan UML dijagram koji se koristi da opie dinamike aspekte sistema. Dijagram aktivnosti predstavlja dijagram koji prikazuje prelazak iz jedne aktivnosti u drugu aktivnost. Aktivnost se moe opisati kao operacija sistema. Na osnovu ovoga moemo rei da kontrola prelazi iz jedne operacije u drugu. Ovaj prelazak moe biti sekvencijalni, razgranat ili konkurentan. Dijagrami aktivnosti modeluju sve tipove kontrole toka koristei razliite elemente kao to je spajanje, razdvajanje, itd. Osnovna svrha dijagrama aktivnosti je slina sa ostalim dijagramima koji modeluju dinamiko ponaanje sistema. Ostali dijagrami se koriste da prikau tok poruka od jednog objekta do drugog dok se dijagrami aktivnosti koriste da prikau prelaz iz jedne aktivnosti u drugu.

Power DesignerPowerDesigner predstavlja grafiko okruenje za modelovanje koje sadri integrisano modelovanje kroz standardne metodologije i notacije automatsko generisanje koda kroz prilagodljive ablone o SQL (sa vie od 50 podranih DBMS) o Java o .NET mone inenjerske mogunosti za dokumentovanje i menjanje postojeih sistema prilagodljiva reenja skladitenja (repository) sa visokim stepenom sigurnosti i mogunostima praenja razvoja po verzijama kao podrka viekorisnikom radu automatizovana mogunost generisanja izvetaja proirivo radno okruenje koje omoguava dodavanje novih pravila, komandi i koncepata u postojeu metodologiju modelovanja i kodiranja Tipian izgled prozora PowerDesigner-a je dat na sledeoj slici.

Vidljive su sledee komponente: Browser - prikazuje modele i objekte koji im pripadaju i omoguava brzu navigaciju kroz njih. Browser takoe poseduje i karticu koja omoguava pristup Repository-ju, u kom moemo uvati sve nae modele i pripadajue fajlove. Canvas - predstavlja osnovni prozor koji prikazuje trenutni dijagram modela ili izvetaj. Palette - predstavljaju grafike alate koji pomau da brzo kreiramo dijagrame modela. Prikazani alati e se razlikovati u zavisnosti od tipa dijagrama. Output window - prikazuje napredak bilo kog PowerDesigner procesa, kao to su kreiranje modela, provera modela ili kreiranje baze podataka iz modela. Result list - prikazuje rezultate pretraga ili provere modela. Browser Browser omoguava hijerarhijski pogled na sve objekte modela. Izgled Browser-a je dat na sledeoj slici.

Tipina hijerarhija objekata u stablu prikaza je sledea: Workspace - poetak svakog stabla prikaza u Browser-u je specifian tip foldera koji se naziva workspace (radno okruenje). To je virtuelno okruenje koje sadri i organizuje sve informacije i fajlove koje kreiramo prilikom stvaranja modela. Workspace omoguava da sauvamo trenutno stanje modela koje moemo pokrenuti sledei put kada pokreemo PowerDesigner. Projekat - ponaa se kao kontejner za sve inioce koji su korieni u razvoju, omoguavajui da se oni sauvaju kao jedna stavka u repository-ju. Svaki projekat sadri dijagram koji automatski kreira i prikazuje zavisnosti i ostale veze izmeu modela i drugih dokumenata. Folderi - workspace moe da sadri foldere koje definie korisnik, a koji omoguavaju da se organizuju modeli ili drugi fajlovi u grupe. Npr. ako radimo na dva razliita projekta, ali elimo da pristupamo i jednom i drugom iz istog workspace-a, moemo organizovati njihove fajlove upotrebom foldera. Modeli - su osnovne jedinice dizajna u PowerDesigner-u. Svaki model ima jedan ili vie grafikih pogleda koji se nazivaju dijagrami i odreen broj objekata modela. Paketi - kada se radi na velikim modelima, moemo ih podeliti u manje "podmodele" kako bi izbegli rukovanje sa velikim skupom stavki. Ovi pod-modeli se nazivaju paketi, a mogu se koristiti kako bi dodelili razliite zadatke ili oblasti od interesa pojedinim razvojnim timovima. Dijagrami - prikazuju interakciju razliitih objekata u modelu. Mogue je kreirati vie dijagrama kako u okviru jednom modela tako i u okviru jednog paketa.

Objekti modela - ovo je opti izraz koji se koristi da opie sve stavke koje pripadaju modelu. Neki objekti modela, kao to su klase u objektno orjentisanom modelu, imaju grafike simbole, dok se ostali, kao to su poslovna pravila, ne pojavljuju u dijagramima. Njima se moe pristupiti jedino pomou Browser-a ili liste objekata. Izvetaji - mogu se automatski generisati kako bi dokumentovali model.

Modelovanje u PowerDesigner-u PowerDesigner omoguava jedinstven skup alata za modelovanje koji objedinjuju standardne tehnike i notacije modela poslovnih procesa, modelovanja podataka i UML modelovanje sa ostalim monim osobinama koje pomau u analiziranju, dizajniranju, kreiranju i odravanju aplikacija. On takoe omoguava da se blisko integriu dizajn i odravanje razliitih slojeva unutar aplikacije, poslovni procesi, objektno orjentisani kod, XML renik i informacije o organizaciji baze podataka. Pruajui bogat skup modela na svim nivoima apstrakcije, PowerDesigner obogauje proces dizajna svih aspekata sistema od koncepta pa sve do primene. On ne namee ni jednu metodologiju u procesu kreiranja softvera. Svaka kompanija moe implementirati svoj specifian redosled operacija, dodeliti odgovornosti i uloge, opisati koji alati treba da se koriste, koje provere se zahtevaju i koji dokumenti treba da se kreiraju u svakom koraku. Tim koji radi na razvoju softvera obuhvata vie inenjera sa razliitim ulogama. Ove uloge ukljuuju analitiare posla, analitiare podataka i dizajnere, administratore baze, ljude koji rade razvoj sistema i testiranje, pri emu e svaki koristiti razliitu kombinaciju komponenti PowerDesigner-a. Business Analysts (analitiari posla) - definiu arhitekturu organizacije, poslovne zahteve i poslovne tokove posmatrane na visokom nivou apstrakcije. Oni mogu koristiti o Enterprise Architecture Model (EAM) - pomou kojeg mogu prikazati sveobuhvatnu sliku organizacije, definisati njenu strukturu, analizirati funkcije, procese i tokove sa visokog nivoa apstrakcije. Ovi objekti se mogu povezati sa implementacionim objektima u bilo kom drugom modelu. o Requirements Model (RQM) - pomou kojeg mogu definisati poslovne zahteve koji se mogu prevesti u tehnike zahteve. RQM opisuje projekat tako to prikazuje i tano objanjava koje funkcionalnosti se moraju implementirati tokom procesa kreiranja softvera, kao i ko je odgovoran za njih. Ovi zahtevi se mogu dodati bilo kom objektu u bilo kom drugom modelu kako bi se pratilo gde i kako su zahtevi ispunjeni. o Business Process Model (BPM) - pomou kojeg mogu da definiu poslovne tokove na visokom nivou apstrakcije, objasne postojee i nove sisteme i da simuliraju poslovne procese kako bi smanjili potrebno vreme i resurse i poveali prihod. BPM prikazuje poslovne procese u stvarnim poslovnim terminima. Moe se koristiti kao dizajnerski alat za otkrivanje poslovnih potreba pomou koga se one hijerarhijski organizuju i grafiki prikazuju

Data Analysts and Designers (analitiari podataka i dizajneri) - oni mapiraju tehnike zahteve na poslovne zahteve. Ulazei dublje u analizu, mogu se definisati Use Case dijagrami koji se mapiraju na zahteve. Moe se napisati funkcionalna specifikacija i preciznije definisati priroda i detalji svakog procesa, aplikacije ili strukture podataka. Mogu se koristiti: o BPM o Conceptual Data Model (CDM) - koji predstavlja prikaz sistema nezavisan od platforme, dajui apstraktan pogled na njegove statike strukture podataka. CDM omoguava realne normalizovane strukture podataka sa vie-ka-vie i nadreen-podreen tipom odnosa, i omoguava jasan prikaz podataka kroz sve sisteme, inei informacije o sistemu dostupnim korisnicima, sistem arhitektama i analitiarima. Database Administrators (administratori baze podataka) - koriste dobro definisane strukture podataka da optimizuju, denormalizuju i kreiraju baze podataka. Koristi se: o Physical Data Model (PDM) - koji predstavlja realnu bazu podataka i pridruene objekte koji se izvravaju na serveru sa kompletnom informacijom o strukturi fizikih objekata kao to su tabele, kolone, reference, trigeri, ugraene procedure, pogledi i indeksi. PDM se moe koristiti da generie kod baze za bilo koju od 50 podranih relacionih baza podataka. PDM se moe kreirati inverznim inenjeringom iz skripti ili iz ivog servera kroz standardnu ODBC konekciju. Drei se PDM i CDM modela, osiguravamo da e krajnja implementacija u potpunosti odgovarati zahtevima sistema. o Logical Data Model (LDM) - koji se moe ponaati kao most izmeu CDM i PDM. Tehniki precizniji u odnosu na CDM, LDM omoguava da prikau mnoge vie-ka-vie i nadreen-podreen odnosi, da se denormalizuju strukture podataka i da se definiu indeksi, bez navoenja odreene RDBMS. o Information Liquidity Model (ILM) - koristi se od strane osoba koje su zaduene za kopiranje baze. On omoguava globalni prikaz kopiranja informacija iz centralne baze u jednu ili vie udaljenih baza podataka. Developers (inenjeri) - piu tehniku specifikaciju u RQM i modeluju aplikaciju definiui objektne strukture i ponaanje, i objektno/relaciono mapiranje. Oni koriste: o Object-Oriented Model (OOM) - koji koristi standardne UML dijagrame i notacije da predstavi objekte i njihove interakcije. To moe biti forma inverznog inenjerstva koja se koristi da generie kod za Java-u, .NET i mnoge druge jezike. Jaka integracija sa BPM, CDM i PDM moe u velikoj meri pojednostaviti odravanje i razvoj sistema. o XML Model (XSM) - se moe koristiti da grafiki modeluje kompleksne strukture XML fajlova. Njihovi dijagrami i pogledi u obliku stabla daju globalan i ematski prikaz svih elemenata iz dokumenta. Team Leaders (voe projekata) - imaju interes za sve tipove modela, i ele da osiguraju da su svi zahtevi, objekti i dokumenti meusobno povezani. Vano je da poslednja verzija dokumenata bude dostupna svim uesnicima u kreiranju softvera.

Pomou Report Editor-a se moe automatizovati kreiranje detaljnih izvetaja (u RTF ili HTML formatima) za pojedinu ili sve komponente sistema. Moe se koristiti: o Free Model (FEM) - za kreiranje dijagrama koji e objasniti arhitekturu sistema i aplikacija, scenarije upotrebe, dijagrame tokova i ostale grafike prikaze. Testers (testeri) - koriste RQM, CDM i ostale modele, zajedno sa dizajn dokumentima kako bi razumeli kako aplikacija treba da radi i kako je kreirana.