01 dijagrami u powerdesigner-u

8/4/2019 01 Dijagrami u PowerDesigner-u

1/13

Power Designer

PowerDesigner 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 Javao .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 brzunavigaciju 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 iliizvetaj.


2/13

Palette - predstavljaju grafike alate koji pomau da brzo kreiramo dijagramemodela. Prikazani alati e se razlikovati u zavisnosti od tipa dijagrama.

Output window - prikazuje napredak bilo kog PowerDesigner procesa, kao to sukreiranje 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 folderakoji se naziva workspace (radno okruenje). To je virtuelno okruenje koje sadri iorganizuje 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 kojiomoguavaju da se organizuju modeli ili drugi fajlovi u grupe. Npr. ako radimo na


3/13

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 jedanili vie grafikih pogleda koji se nazivaju dijagrami i odreen broj objekatamodela.

Paketi - kada se radi na velikim modelima, moemo ih podeliti u manje "pod-modele" 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 kreirativie 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 kojepripadaju 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, poslovnezahteve i poslovne tokove posmatrane na visokom nivou apstrakcije. Oni mogu

koristiti

o Enterprise Architecture Model (EAM) - pomou kojeg mogu prikazatisveobuhvatnu 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 poslovnezahteve koji se mogu prevesti u tehnike zahteve. RQM opisuje projekat

tako to prikazuje i tano objanjava koje funkcionalnosti se moraju


4/13

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 definiuposlovne tokove na visokom nivou apstrakcije, objasne postojee i novesisteme 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 mapirajutehnike 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 BPMo 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 dobrodefinisane strukture podataka da optimizuju, denormalizuju i kreiraju baze

podataka. Koristi se:

o Physical Data Model (PDM) - koji predstavlja realnu bazu podataka ipridruene 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 izmeuCDM i PDM. Tehniki precizniji u odnosu na CDM, LDM omoguava daprikau 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 suzaduene 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 aplikacijudefiniui objektne strukture i ponaanje, i objektno/relaciono mapiranje. Oni

koriste:


5/13

o Object-Oriented Model (OOM) - koji koristi standardne UML dijagramei 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 velikojmeri pojednostaviti odravanje i razvoj sistema.

o XML Model (XSM) - se moe koristiti da grafiki modeluje kompleksnestrukture 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 daosiguraju 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 arhitekturusistema i aplikacija, scenarije upotrebe, dijagrame tokova i ostale grafike

prikaze.

Testers (testeri) - koriste RQM, CDM i ostale modele, zajedno sa dizajndokumentima kako bi razumeli kako aplikacija treba da radi i kako je kreirana.


6/13

UML

UML je standardni jezik za izradu specifikacija, vizualizaciju, kreiranje i

dokumentovanje delova sistema. UML (Unified Modeling Language) je kreiran od straneObject 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 bolo koga ko eli da razume kako funkcionie neki sistem.

Ovaj sistem moe ali i ne mora biti softverski.

Kao zakljuak moe se re

i da UML dijagrami predstavljaju jednostavan mehanizam zamodelovanje 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


7/13

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 iza 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. Osnovnikoncepti 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.


8/13

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.


9/13

Dijagram rasporeda

Dijagrami rasporeda se koriste da prikau topologiju fizikih komponenti sistema,

odnosno gde su razmetene softverske komponente sistema. Oni se koriste da opiu statikiprikaz 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


10/13

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 prikazujeodreenu 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.


11/13

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 utome to ovi dijagrami prikazuju organizaciju objekata i njihovu interakciju.


12/13

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 ivotnogciklusa. 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 jedneaktivnosti 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.


13/13

01 dijagrami u powerdesigner-u

Documents