UNIVERZITET MEGATRENDFAKULTET ZA POSLOVNE STUDIJE

POSLOVNO − INFORMACIONI SISTEMI

UML I IDEF − SLIČNOSTI I RAZLIKE− Seminarski rad −

Nastavnik: Student:Doc. dr Zlatko Langović Nikola Radić, F234/10

Beograd, juni 2013.

SADRŽAJ:

1. UVOD ..........................................................................................................32. Objednjeni vizuelni jezik UML ................................................................33. Dijagrami klasa ..........................................................................................64. Dijagrami komponenti ..............................................................................75. Dijagrami razmeštaja ................................................................................76. Dijagrami objekata i paketa .....................................................................87. Dijagrami stanja i aktivnosti ..................................................................108. Dijagrani slučejava upotrebe ..................................................................139. Sekvencijalni i komunikacioni dijagrami...............................................1410. Familija IDEF jezika ...............................................................................1510.1 IDEF0 ........................................................................................................1610.2 IDEF1 / IDEF1x........................................................................................1710.3 IDEF2 ........................................................................................................1810.4 IDEF3 .......................................................................................................18 10.5 IDEF4 ........................................................................................................2010.6 IDEF5 ........................................................................................................2010.7 IDEF6 do ODEF16 ..................................................................................2111. Poređenje IDEF i UML ...........................................................................2112. Zaključci ...................................................................................................22LITERATURA .................................................................................................23

2

1. UVOD

Razvoj informacionih sistema je suviše kompleksan da bi se mogao planirati iz glave. Kao rezultat analize i dizajna dobijaju se modeli. U razvoju informacionih sistema, modeli su: apstraktni / ne-fizički (softver nije opipljiv) i vidljivi (težimo da vizuelizujemo neopipljive elemente). Danas softver postaje sve kompleksniji i stoga ga se mora razumeti kroz mode-lovanje. Model je uprošćena predstava kompleksne realnosti. Ukratko, potrebna nam je jed-nostavna predstava kompleksnih modela, a modelovanje je sredstvo za savlađivanje ove kompleksnosti. Metodama modelovanja definisani su jezik, kao i procedure za korišćenje jezika za konstruisanje modela. Modelovanje je jedini način za vizuelizaciju dizajna i njegovu proveru prema zahtevima pre početka implementacije.

Ciljevi modelovanja su: 1) pomaže u vizuelizaciji sistema onakvog kakav jeste ili onak-vog kakav želimo da bude, 2) omogućava specifikaciju strukture i ponašanja sistema, 3) defi-niše šablon koji pomaže prilikom konstruisanja sistema, 4) dokumentuje odluke koje su done-sene, 5) obezbeđuje zajednički jezik za sve stejkholdere, 6) omogućava jasnoću i razumeva-nje.U sistemima postoje dva osnovna načina za pristupanje modelovanju:− strukturno – fokusira se na aspekte procesa, podataka i vremena – odvojena ali povezana dekompozicija ovih aspekata.− objektno-orijentisano – zasnovano na objektima i klasama [objekat –“predmet” intere-sovanja, koji ima jedinstvenost, stanje i ponašanje, klasa – opis grupe objekata].

Zašto model? Model je pojednostavljenje realnosti (mogu se izabrati detalji koje želimo da predstavimo, mogu se izabrati detalji koje ćemo ignorisati), model se može razvijati para-lelno sa našim razumevanjem, može predstavljati realne i apstraktne stvari, kreiranje modela omogućava bolje razumevanje sistema, model se može koristiti za razmenu ideja, što je sistem veći, veći je značaj modela, model se može koristiti da simulira realni sistem, model se kreira lakše i brže od realnog sistema.

U ovom radu prikazane su osnove UML i IDEF, kao jezika za modelovanje koji imaju široku primenu u poslovnim i softverskim aplikacijama. Takođe, izvršeno je poređenje nekih karakteristika i mogućnosti jezika.

2. Objedinjeni vizuelni jezik UML

UML (Unified Modeling Language) – objedinjeni vizuelni jezik za poslovno i softversko modelovanje u svim fazama razvoja i za sve tipove sistema, kao i za generalno modelovanje kojim se definišu statičke strukture i dinamičko ponašanje. To je standardni jezik za vizueli-zaciju, specifikaciju, konstruisanje i dokumentovanje softverskih sistema. UML kombinuje najbolje iz koncepta “Data Modeling” (Entity Relationships Diagrams), poslovnog mode-lovanja (work flow) i objektnog i komponentnog modelovanja.

UML je projektovan kao vrlo fleksibilan i prilagodljiv jezik, koji omogućava različite vrste modelovanja, uključujući: modele koji olakšavaju razumevanje poslovnih procesa, od-vijanja tokova događaja, sekvenci upita, aplikacija, baza podataka, arhitektura i dr.

UML je nastao 1990. godine kao rezultat evolucije objektno orijentisanih jezika za mode-lovanje. Razvila ga je kompanija Rational Software objedinjavanjem tri vodeće metode ob-jektno orijentisanog modelovanja: Booch koji je razvio Grady Booch, OMT (Object Modeling Technique) koji je razvio Jim Rambaugh i OOSE (Object-Oriented Software Engineering) koji je razvio Ivar Jacobson.

3

UML je prihvaćen od strane Object Manage-ment Group (OMG) 1997. godine i sve do da-nas je vođen od strane te kompanije. Međuna-rodna organizacija za standardizaciju (ISO) pri-hvatila je 2000. godine UML kao industrijski standard za modelovanje softverski intenzivnih sistema. Trenutna verzija UML je 2.4.1, koja je publikovana avgusta 2011. godine. UML uključuje skup tehnika koje ostvaruju grafički prikaz objektno-orijentiranih račubars-kih sistema. Računarski sistem modeluje se raz-novrsnim dijagramima, od kojih se svaki koristi za prikaz sistema iz nešto drugačije perspektive.

UML je razvijan od druge polovine 1990-tih godina i ima korene u objektno orijentisanim metodama razvijenim krajem 1980-tih i početkom 1990-tih godina. Vremenski okvir prikazuje glavne atrakcije istorije objektno-orijentisanih metoda modelovanja i obeležavanja (slika 2.1)

Slika 2.1 Vremenski okvir razvoja UML

UML je znatno "sazreo" od pojave prve verzije UML 1.1. Nekoliko manjih revizija (UML 1.3, 1.4 i 1.5) fiksirale su neke mane i bagove u prvoj verziji UML, koje je sledila ve-lika revizija UML 2.0, koja je prihvaćena od strane OMG 2005. godine. Iako UML 2.1 nije nikada prikazana kao zvanična specifikacija, verzije 2.1.1 i 2.1.2 pojavile su se 2007. godine, koju je sledila UML 2.2 u februaru 2009. godine. UML 2.3 je prikazana u maju 2010. godine, a UML 2.4.1 je prikazana u avgustu 2011. godine. UML 2.5 je prikazana u oktobru 2012. godine kao verzija "u procesu" i tek treba zvanično da se prikaže.

UML koriste sledeće kategorije korisnika:

Logo UML-a

4

sistem analitičari i krajnji korisnici – specifikacija zahtevane strukture i ponašanja sistema,

arhitekte sistema – projektanti sistema koji će zadovoljiti zahteve, razvojni inženjeri (developers) – transformišu arhitekturu u izvršni kod, kontrolori kvaliteta – provera strukture i ponašanje sistema, rukovodioci projekta (managers) – vode i usmeravaju kadrove i resurse.

UML je kompletan jezik za prikupljanje informacija o subjektu i njihovo kasnije preds-tavljanje kroz prikazivanje zahteva i modelovanje tih zahteva. Ovakvo modelovanje obuhvata dve faze: analizu i dizajn (slika 2.2)

Slika 2.2 Faze modelovanja u UML

Važno je praviti razliku između UML modela i skupa dijagrama sistema. Dijagram je de-limična (parcijalna) grafička prezentacija sistemskog modela. Model, takođe, sadrži doku-mentaciju koja pokreće elemente modela i dijagrame.

UML dijagrami predstavljaju dva različita pogleda na modele sistema:

statički (ili strukturni, integralni) pogled: naglašava statičku strukturu sistema koristeći objekte, atribute, operacije i relacije (odnose). Strukturni pogled uključuje klase dijag-rama i kompozitne dijagrame strukture.

dinamički ili pogled ponašanja: naglašava dinamičko ponašanje sistema prikazivanjem saradnje između objekata i promene unutrašnjeg stanja objekata. Taj pogled uključuje dijagrame sekvenci, dijagrame aktivnosti i dijagrame stanja.

Nešto savremenija podela dijagrama je ona koja deli UML-dijagrame s obzirom na to da li modeluju strukturu sistema (engl. structure diagram) ili ponašanje sistema (engl. behavior diagram). Ovakva podela se okvirno podudara sa podelom na statičke (strukturne) i dinamičke (ponašajne) dijagrame, sa izuzetkom dijagrama slučajeva upotrebe koji, iako modeluju ponašanje, ne modeluju vremensku komponentu sistema.

Podela UML-dijagrama prema standardu UML 2.4.1 prikazana je na slici 2.3., a u okviru ove podele postoji veći broj pojedinačnih dijagrama. Sedam vrsta dijagrama predstavlja struk-turne (integralne) informacije, a sedam drugih vrsta predstavlja opšte vrste ponašanja, uklju-čujući četiri koja predstavljaju različite aspekte interakcija. Ti dijagrami mogu biti katego-risani hijerarhijski.

5

Slika 2.3. Dijagrami u UML

3. Dijagrami klasa

Dijagrami klasa (engl. class diagrams) opisuju klase i njihove međusobne veze. Isto tako, dijagrami klasa opisuju vrste objekata u nekom sistemu. Dijagrami klasa pripadaju strukturnoj grupi UML-dijagrama (engl. structure diagram). Oni ne opisuju događaje, stanja, aktivnosti ili bilo kakvu vremenski promenljivu karakteristiku sistema koji se modeluje. Naprotiv, dijagra-mi klasa su statični s obzirom na vremensku komponentu. Na slici 3.1 prikazan je primer dijagram klasa.

Slika 3.1 Primer dijagrama klasa

6

Klasa (engl. class) je osnovni gradivni element UML-dijagrama razreda. Za pravilno ra-zumevanje definicije klase važno je prvo odrediti značenje objekta. Objekat predstavlja entitet iz stvarnog sveta ili neki koncept, odnosno apstrakciju nečega što ima dobro definisane gra-nice i smisao u sistemu. Stoga je klasa opis grupe objekata sa sličnim svojstvima, a svaki ob-jekat je obavezno pojedinac (instanca) jedne klase. Za svaku klasu neophodno je definisati na-ziv, a moguće je odrediti popis atributa i operacija. Mada atribute i operacije nije neophodno definisati, bez njih klasa nema implementacionu svrhu. Za atribute neophodno je odrediti nji-hov naziv i tip podataka, a za operacije njihovu definiciju koja uključuje naziv operacije i sve ulazne i izlazne parametre.

4. Dijagrami komponenti

Dijagrami komponenti prikazuju komponente (strukturne celine) sistema i njihove me-đusobne odnose. Komponenta je zasebna celina programske podrške i predstavlja fizičku i stvarnu implementaciju logičkih elemenata sistema, kao što su klase i pridruživanja. Kompo-nentni dijagrami pomažu u modelovanju fizičkih celina sistema, kao što su izvršne datoteke, programske biblioteke, tabele i drugi dokumenti. Često se kaže da su u UML-u sve fizičke „stvari“ modelovane kao komponente. Na slici 4.1 prikazan je primer dijagrama kompo-nenti.

Slika 4.1 Primer dijagrama komponenti

Dijagrami komponenti su strukturni UML-dijagrami. Prikazuju vremenski nepromenljiva (statička) svojstva sistema sa fizičkog aspekta implementacije. Stoga se uz dijagrame razmeš-taja još nazivaju fizičkim dijagramima, pa se često prikazuju zajedno u jednom UML-dija-gramu komponenti i razmeštaja.

5. Dijagrami razmeštaja

Dijagrami razmeštaja (engl. deployment diagrams) opisuju topologiju sklopova i prog-ramsku podršku koja se koristi u implementaciji sistema u njegovom radnom i produkcionom okruženju. Drugim rečima, dijagrami razmeštaja prikazuju računarske resurse koji su neop-hodni za ispravno funkcionisanje sistema i njihove međusobne odnose: stvarne uređaje (radne

7

stanice, korisničke računare, itd.), komponente programske podrške koje se na njima izvrša-vaju i veze između prikazanih resursa. Dijagrami razmeštaja, kao i dijagrami paketa i klasa, su statički i strukturni UML-dijagrami. Dijagrami razmeštaja sastoje se od čvorova (engl. nodes), komponenti (engl. components) i njihovih međusobnih veza.

Na slici 5.1 prikazani su primeri dijagrama razmeštaja.

Slika 5.1 Primeri dijagrama razmeštaja

6. Dijagrami objekata i paketa

Dijagrami objekata (engl. object diagrams), kao i dijagrami klasa pripadaju strukturnim UML-dijagramima, ali je njihova uloga različita: dijagrami objekata prikazuju strukturu siste-ma u nekom trenutku. Prikaz može biti delimičan ili potpun, odnosno nije neophodno prika-zati objekte svih klasa sistema. U proizvoljno odabranim trenucima objekti sistema imaju različite vrednosti atributa i dijagrami objekata prikazuju upravo te vrednosti, zajedno sa ob-

8

jektima i njihovim međusobnim vezama. Najčešće je dovoljno prikazati samo jedan trenutak u radu sistema, ali ako je stanje sistema izrazito dinamično, potrebno je izraditi više dijagrama koji opisuju rad sistema u nekoliko trenutaka sa karakterističnim stanjima objekata.

Simbol objekta je pravougaonik sa dva odeljka – jedan za naziv objekta i drugi za vred-nosti atributa. Objekti se razlikuju od klasa jer nemaju definicije atributa i procedura, ali ima-ju jasno označeno stanje važnih atributa. Prikazuju se atributi po kojima se pojedinci u dija-gramu međusobno razlikuju, odnosno po kojima su oni specifični. Dijagrami objekata se sas-toje od objekata i veza. Za pridruživanja objekata najčešće se koristi dvosmerna veza, a doz-voljeno je i korišćenje kompozicije. Na slici 6.1 prikazan je dijagram objekata.

Slika 6.1 Primer dijagrama objekata

Dijagrami paketa (engl. package diagram) prikazuju kako je sistem podeljen u logične ce-line ili skupove, pokazujući zavisnost između tih celina. Korisni su za uspostavljanje hijerar-hijskog odnosa između klasa i njihovo grupisanje u smislene i funkcionalne celine. Dijagrami paketa, takođe, pripadaju strukturnoj skupini UML-dijagrama i prikazuju vremenski statička svojstva sistema. Na slici 6.2 prikazan je primer dijagrama paketa.

Slika 6.2 Primer dijagrama paketa

Paket (engl. package) je skup različitih UML-objekata. Pomoću paketa moguće je objedi-niti obrasce upotrebe kako bi se strukturno objasnila funkcija modelovanog sistema. U više-

9

slojnim sistemima paketi se mogu koristiti za grupisanje pojedinačnih slojeva programske po-drške kako bi se mogao objasniti tok podataka između različitih slojeva.

7. Dijagrami stanja i aktivnosti

Dijagrami stanja (engl. statechart, UML state machine diagram) i aktivnosti (engl. activity diagram) pripadaju ponašajnim dijagramima (engl. behavioral diagram) u UML-u, zajedno s dijagramom slučajeva upotrebe. Za razliku od dijagrama slučajeva upotrebe, dijagrami stanja i aktivnosti prikazuju funkcionalnost softverskog sistema iz perspektive unutrašnjosti sistema. Budući da razrađuju ponašanje sistema u smislu aktivnosti i prelaza između stanja, svrstavaju se u dinamičke dijagrame.

Iako slični, ove dve vrste dijagrama imaju i određene razlike. Prva razlika odnosi se na njihovu svrhu. Dijagram stanja služi za opis diskretnih stanja sistema i prelaza između tih sta -nja. Dijagram aktivnosti prikazuje radni tok (ili kontrolni tok) aktivnosti koje se obavljaju u sistemu korak po korak. Druga razlika je u tome što dijagrami stanja na prelazima između sta-nja sadrže naziv događaja koji je aktivirao prelaz i često poziv izlazne metode ili operacije ko-ja se događa, dok kod dijagrama aktivnosti to nije slučaj.

Dijagram stanja sastoji se od sledećih (najčešćih) gradivnih elemenata:1. Početno stanje i konačno stanje. Početno stanje označeno je crnim krugom, a konačno

stanje označeno je zaokruženim crnim krugom (slika 7.1).

Slika 7.1 Oznake početnog i konačnog stanja

2. Stanje, označeno zaobljenim pravougaonikom. Pri tome, gornji deo pravougaonika sa-drži naziv stanja, a donji deo, odvojen horizontalnom linijom, sadrži aktivnosti koje se događaju u tom stanju (slika 7.2).

Slika 7.2 Oznaka stanja

3. Prelaz između stanja, označen strelicom. Opšti oblik prelaza između stanja prikazan je na slici 7.3. Prelaz između stanja može sadržati: 1) događaj koji je izazvao prelaz, 2) ograničenje ili izraz koje treba zadovoljiti događaj da bi se prelaz ostvario, 3) akciju koja se događa prilikom prelaza ukoliko je ograničenje zadovoljeno, 4) tip događaja.

Slika 7.3 Opšti oblik prelaza između stanja

10

4. Odluka ili uslovno grananje (engl. decision), prikazuje se belim, dijamantskim obli-kom (slika 7.4).

Slika 7.4 Oznaka odluke

5. Račvanje i skupljanje (engl. fork and join) koje se najčešće koristi pri paralelnom od-vijanju nekih aktivnosti (slika 7.5).

Slika 7.5 Oznaka račvanja i skupljanja

6. Složeno stanje, koje se sastoji od hijerarhije stanja i prelaza, prikazano zaobljenim pravougaonikom u čemu se nalazi novi dijagram stanja (slika 7.6).

Slika 7.6 Primer hijerarhije stanja

Na slici 7.7 prikazan je primer dijagrama stanja.

11

Slika 7.7 Dijagram stanjaDijagram aktivnosti sastoji se od sledećih osnovnih elemenata:

1. početnog i konačnog stanja, koje se obeležava isto kao i kod dijagrama stanja,2. aktivnosti, koja se obeležava zaobljenim pravougaonikom, isto kao i stanje kod dija-

grama stanja,3. prelaz između aktivnosti, označen strelicom.,4. odluka ili uslovno grananje, označena belim, dijamantskim oblikom, isto kao i kod di-

jagrama stanja,5. račvanje i skupljanje, koje se označava isto kao i kod dijagrama stanja.6. signal (postoje tri tipa signala: 1) šaljući signal (engl. sending signall), 2) primajući

signal (engl. receiving signal) i vremenski signal (engl. timer signal)). Primeri signala prikazani su na slici 7.8.

Slika 7.8 Signali kao elementi dijagrama aktivnosti

7. plivačke staze (engl. swimlanes), kod kojih su aktivnosti raspoređene u vertikalne i/ilihorizontalne particije koje su razgraničene linijama (slika 7.9). Aktivnost 1 izvodi se u okviru particije broj 1, zatim se druga i treća aktivnost izvode u okviru particije 3, da bi aktivnost 4 bila poslednja u particiji 2.

12

Slika 7.9 Plivačke staze

Na slici 7.10 prikazan je primer dijagrama aktivnosti.

Slika 7.10 Primer dijagrama aktivnosti

8. Dijagrami slučajeva upotrebe

Dijagrami slučajeva upotrebe (engl. use-case diagrams) koriste se da bi se prikazalo po-našanje sistema, delova sistema ili konkretne klase na način koji je vidljiv korisniku sistema. Obrasci upotrebe, takođe, služe da se razvojni tim i korisnici usaglase po pitanju ponašanja korisnika pri komunikaciji sa sistemom. Ponašanje sistema opisano je pomoću ciljeva (engl. use cases – obrasci upotrebe) i aktera (engl. actors) koji predstavljaju apstrakciju korisnika sistema, odnosno nekog od delova sistema. Akteri mogu predstavljati i druge spoljne sisteme koji učestvuju u radu sistema koji se modeluje. Jedan obrazac upotrebe uključuje komuni-kaciju aktera sa modelovanim sistemom koji se ostvaruje kao niz poruka među učesnicima obrasca upotrebe, a koji doprinosi ostvarenju nekog jedinstvenog cilja. Na dijagramima slu-

13

čajeva upotrebe dodatno se definišu odnosi između pojedinih slučajeva upotrebe, kao i odnosi između aktera (slika 8.1).

Slika 8.1 Primer dijagrama slučaja upotrebeDijagrami slučajeva upotrebe su statički UML-dijagrami (kao i dijagrami klasa, objekata,

paketa i razmeštaja), a pripadaju i grupi ponašajnih dijagrama budući da modeluju moguće ponašanje korisnika sistema. Prema UML-specifikaciji, dijagrami slučajeva upotrebe sastoje se od aktera, slučajeva upotrebe i veza i odnosa između aktera i slučajeva upotrebe. Dodatno se na dijagramu slučajeva upotrebe može istaći granica sistema koji se izgrađuje.

Akteri u dijagramima slučajeva upotrebe predstavljaju jednu od idealizovanih uloga ko-risnika u sistemu. Na dijagramima slučajeva upotrebe akteri su prikazani pojednostavljenim prikazom čoveka. Jedan fizički korisnik može ostvariti više uloga u sistemu, a jednu ulogu u sistemu može preuzeti više korisnika. Akteri su učesnici pojedinih slučajeva upotrebe, pri čemu jedan akter može sudelovati u više slučajeva upotrebe, a u jednom obrascu upotrebe može sudelovati više aktera. Akteri komuniciraju preko niza poruka sa slučajevima upotrebe u kojima učestvuju..

Slučaj upotrebe predstavlja jedinstvenu funkcionalnost koju prema spoljnom svetu pruža modelovani sistem. Slučaj upotrebe sastoji se od glavnog toka izvođenja, a može biti proširen varijacijama tog toka, kao i posebnim slučajevima koji se mogu dogoditi za vreme njegovog ostvarenja. Tok izvođenja obrasca upotrebe opisan je nizom poruka koje akteri razmenjuju sa modelovanim sistemom. Pomenuti niz poruka se ne prikazuje na dijagramu slučajeva upo-trebe. Izvršavanje svakog obrasca upotrebe je nezavisno od drugih slučajeva upotrebe. Jedina zavisnost između slučajeva upotrebe ostvaruje se preko deljenih podataka.

U dijagramima slučajeva upotrebe postoji nekoliko vrsta veza koje se mogu ostvariti iz-među aktera i slučajeva upotrebe, kao što su asocijacija, generalizacija, uključivanje i proširenje. Asocijacijom se povezuju akteri sa slučajevima upotrebe u kojima učestvuju. Ge-neralizacijom se povezuju dva aktera ili dva slučaja upotrebe. Vezom uključivanja se pove-zuju dva slučaja upotrebe na način da jedan obrazac u toku svog izvođenja u potpunosti iz-vede uključeni obrazac upotrebe, pri čemu trenutak izvođenja uključenog obrasca nije speci-ficiran dijagramom. Vezom proširenja se povezuju dva slučaja upotrebe, pri čemu jedan pro-širuje funkcionalnost drugog.

9. Sekvencijalni i komunikacioni dijagrami

14

Sekvencijalni dijagrami (engl. sequence diagram) i komunikacioni dijagrami (engl. communication diagram) pripadaju široj grupi UML-dijagrama interakcije (engl. interaction diagram). Obe vrste dijagrama spadaju u grupu ponašajnih dijagrama (engl. behavioral diagram), zajedno s dijagramima stanja, aktivnosti i slučajeva upotrebe. Za razliku od dijag-rama slučajeva upotrebe, kod kojih vremenska komponenta nije važna, sekvencijalni i komu-nikacioni dijagrami daju naglasak na vremenski redosled kojim se odvija interakcija učesnika u sistemu, tako da se svrstavaju i u dinamičke UML-dijagrame.

Učesnici koji se modeluju na sekvencijalnim i komunikacionim dijagramima mogu biti akteri (predstavljanjem komunikacije aktera sa dijagrama slučajeva upotrebe) ili objekti, pri čemu se prikazuje komunikacija instanci klasa prikazanih na dijagramu klasa. Dok se prili -kom komunikacije aktera govori o porukama, kod objekata to su pozivi postupaka u objek-tima drugih razreda.

Sa informacionog aspekta nema razlika između sekvencijalnog i komunikacionog dija-grama. Ipak, manje razlike između te dve vrste dijagrama postoje u samom prikazu i one su date u tabeli 2.

Tabela 2.Sekvencijalni Komunikacioni

Veći naglasak na vremenskojuređenosti scenarija

Veći naglasak na pregledu scenarija, odnosno na međusobnoj komunikaciji

Redosled poruka učesnikaodozgo levo prema dole desno

Redosled poruka učesnika određen je brojčanim oznakama koje se stavljaju na poruke

Koristi se u ranim fazamaspecifikacije i analize projekta

Koriste se u fazi dizajniranja implementacije odnosa

Rašireniji i čitljiviji Sažetiji i teži za čitanjeTeže izmene Lakše izmene

Na slici 9.1 i 9.2 prikazani su primeri sekvencijalnog i komunikacionog dijagrama.

Slika 9.1 Primer sekvencijalnog dijagrama

15

Slika 9.2 Primer komunikacionog dijagrama

10. Familija IDEF jezika

Metodologije za analizu i modelovanje poslovnih procesa imaju potencijal da premoste jaz između definisanja zahteva za informacione sisteme i razvoja softverskih sistema. Tradi-cionalno, međutim, poslovni analitičari imaju poteškoća u prihvatanju poslovnih modela u ci-lju boljeg razumevanja i njihovog poboljšanja. Srećom, pojava alata za modelovanje apli-kacija metoda poslovnog modelovanja je promenila ovu situaciju.

IDEF (ICAM DEFinition, postaje IntegratedDEFinition) metodologija prvobitno je uve-dena za upotrebu u sistemskom inžinjeringu. Tokom 70-tih godina 20. veka oblast dizajna i analize sistema zahtevala je podršku metoda modelovanja. Integrisani računarski program američkog vazduhoplovstva za podršku proizvodnji (ICAM) bio je odgovor na ove zahteve u kome je osmišljen komplet metoda poznatih kao IDEF.

IDEF je na početku sadržavao metod modelovanja aktivnosti (funkcija), poznat kao IDEF0, konceptulani metod modelovanja nazvan je IDEF1, a metoda simulacije specifikacija modela – IDEF2. Od tada, svetlost dana ugledalo je nekoliko izmena IDEF1, tako da je nastao IDEF1x. Takođe, rad na usavršavanju metode modelovanja procesa poznat kao IDEF3 za-počeo je 80-tih godina 20. veka. Sledili su IDEF4 i IDEF5 tokom 90-tih godina. IDEF4 je objektno-orijentisani softverski metod dizajna koji uključuje zahteve specificirane u drugim metodama. IDEF5 je metod za sticanje znanja i inžinjering. Kompletna lista IDEF metoda kreće se od IDEF0 do IDEF14, a metode koje se sada koriste su IDEF0, IDEF1x, IDEF3 i IDEF4. Skorašnji razvoji usmereni su na efikasno preoblikovanje i integraciju tih metoda, ta-ko da se informacije između njih mogu lako razmenjivati.

10.1 IDEF0

Metoda IDEF0 se koristi za specificiranje funkcija modela. Ona je zasnovana na metodi SADT (Structured Analysis and Design Technique – strukturne analize i tehnika dizajna), ko-ju je razvio Daglas Ros iz kompanije SofTech tokom 70-tih godina.

IDEF0 omogućava korisniku da opiše pogled na proces uključivanjem input-a, output-a, upravljanja i mehanizama:

input-i su resursi utrošeni ili transformisani od strane procesa,

16

output-i su stvari stvorene tokom trošenja ili transformacije inputa od strane procesa, mehanizmi su agenti koji ostvaruju akcije (aktivnosti) sadržane u procesu. Na slici 10.1 prikazan je generički IDEF0 dijagram.

Slika 10.1 Generički IDEF0 dijagram

Veoma važan koncept u metodi IDEF0 je apstrakcija iz vremena. IDEF0 dijagrami po-kazuju aktiviranje aktivnosti, ne tok (sekvence). IDEF0 dijagrami mogu se dekomponovati u niže nivoe ("child") dijagrama. Hijerarhija se održava preko numeričkog sistema koji orga-nizuje "roditeljske" i "dečje" dijagrame. Strelice korišćene u IDEF0 modelu mogu račvati ili spajati. Spajanje dve strelice zajedno ima značenje objedinjavanja. Neke strelice mogu biti usmerene nadole, tj. one su izuzete (nevidljive) od dekompozicije roditeljske kutije sve dok se ne dostigne željeni novo dekompozicije i one postanu vidljive.

10.2 IDEF1 / IDEF1x

Prvobitna namena IDEF1 bila je prihvatanje postojećih informacija o objektima u predu-zeću i IDEF1 se generalno koristi u računarski podržanoj proizvodnji (CIM), uglavnom za:

identifikaciju informacija dostupnih u organizaciji, identifikaciji problema koji su uzrokovani nedostatkom odgovarajućeg menadžmenta

informacijama, specificiranje informacja kojima treba da se upravlja u CIM implementaciji.

IDEF1 nije metod dizajna baza podataka. On samo omogućava biznisu da razume infor-macije sa kojima radi. Osnovni koncepti IDEF1 su (slika 10.2):

entiteti: informacije dostupne u organizaciji o fizičkim ili konceptualnim objektima (ljudi, ideje, itd.). Entiteti se razumeju kao informaciona slika.

relacije (odnosi): udrživanje između entiteta (tj. informacionih slika), entiteti i klase odnosa: šabloni za entitete i odnose.

17

Slika 10.2 Osnovni koncepti IDEF1

IDEF1 je posebno dijazniran da bude tehnološki nezavisan. Stoga se, IDEF1x (za rela-cione baze podataka) ili IDEF4 (za objektno-orijentisane implementacije) koriste za projektovanje stvarne implementacije.

Suprotno IDEF1, IDEF1x podržava modelovanje podataka, prihvatanje logičnog pogleda na poslovne podatke preduzeća. IDEF1x je zasnovan na Chen-ovom modelu odnosa između entiteta i namenjen je za dizajn logičkih baza podataka. U IDEF1x, entiteti se navode kao kolekcija ili grupa instanci podataka koji se mogu razlikovati jedni od drugih. IDEF1x je naj-korisniji kada su identifikovane potrebe za informacijama i kada treba doneti odluke o ko-rišćenju relacionog modela. Osnovni elementi IDEF1x su entiteti (koji se odnose na kolekci-ju), atributi (povezani sa svakim članom grupe-seta) i klasifikaciona struktura (za modelova-nje logičkih tipova podataka).

Na slici 10.3 prikazan je primer IDEF1x dijagrama.

18

Slika 10.3 Primer IDEF1x dijagrama

10.3 IDEF2

Simulacioni model je alata za podršku odlučivanju koji pomaže u rešavanju složenih pro-blema u mnogim oblastima aplikacija. Simulacije omogućavaju da se izrade scenariji "šta ako" i njihovi mogući efekti na postojeći ili imaginarni sistem koji treba da se analizira. Pred-nosti su očigledne − sistem ne treba da postoji, simulacija se može ubrzati u vremenu, rizici su mali ili nikakvi, itd. Međutim, eksperti u posebnim oblastima obično nisu eksperti u simu-lacijama, tako da oni treba da se oslone na modelare simulacija. Da bi se to uradilo, sistemski eksperti treba efikasno da komuniciraju sa svojim znanjem o sistemu sa modelarima simu-lacija − što obično nije jednostavna stvar.

IDEF2 usmeren je na navedene probleme, omogućavajući modelaru simulacija da komu-nicira sa ekspertom u oblasti. U cilju da se obezbedi potencijalna ponovna upotreba, simu-lacioni model je podeljen u četiri podmodela: 1) podmodel objekta, 2) podmodel toka entiteta, 3) raspolaganje resursima i 4) podmodel kontrole sistema.

Mada je uglavnom grafički, dizajni IDEF2 modela omogućavaju direktno izvršenje mo-dela koji se specificira. IDEF2 je prilično uspavan u ovom trenutku. Međutim, njegove mo-gućnosti specificiranja i grafičkih inovacija ugrađene su u komercijalno dostupne proizvode. IDEF2 pomaže modelarima simulacije, ali ne podržavaju "drugu stranu", tj. eksperte u oblasti. IDEF2 može pomoći u obezbeđivanju informacija modelarima simulacija u generisanju sis-tema. Metod IDEF2 ne može se koristiti za naše posebne zadatke.

10.4 IDEF3.

IDEF3 jezik pripada tzv. sledećoj generaciji IDEF jezika, koji su se pojavili kao odgovor na nove zahteve (potrebe) u oblasti modelovanja preduzeća. Primeri takvih zahteva (potreba) su: prihvatanje scenarija logičkih/vremenskih sekvenci događaja, dizajn objektno-orijentisa-

19

nih aplikacija i baza podataka, prihvatanje opisa referentnih objekata u realnom vremenu i zapis obrazložene odluke.

IDEF3 uvodi metod prihvatanja procesa opisivanja, koji koriste oni koji razvijaju sistem za prihvatanje znanja eksperata iz oblasti oko dinamičkih (ponašajnih) aspekata sistema. IDEF3 izrađuje (konstruiše) modele procesa preduzeća i stoga je sličan IDEF0. Osnovna raz-lika između njih je da IDEF0 prihvata jednostavan pogled na sistem, dok IDEF3 prihvata ne-koliko korisničkih opisa vremenskih procesa (korisnički pogled). Rezultat IDEF3 metoda je pre opis nego model. IDEF3 sadrži dva pristupa modelovanju: 1) opis toka procesa i 2) opis stanja tranzicije objekta.

U opisu toka procesa, proces prihtava znanja sa IDEF3 je organizovan u scenario. Os-novna IDEF3 sintaksna jedinica u tom slučaju je UOB (Unit of Behavior – jedinica za pona-šanje). Zavisno od strukture okruženja, UOB mogu postati funkcije, aktivnosti, procesi, itd. UOB može da se dekomponuje u druge UOB i, takođe, može biti uporediva sa IDEF0 ak-tivnostima. Primer IDEF3 dijagrama toka procesa prikazan je na slici 10.4.

Slika 10.4 Primer IDEF3 dijagrama toka procesa

Dijagram opisa stanja tranzicije objekta predstavlja objektno-orijentisan pogled na proces − on rezimira dozvoljene tranzicije objekta. Stanje objekta je definisano u obliku vrednosti imovine i ograničenja. Svojstva objekta mogu se definisati kao IDEF1 atributi i ukrštati se na dijagramu. Tranzicija može početi ili se smatrati završenom zavisno od pre- ili posle tran-zicionih ograničenja. Na slici 10.5 dat je primer IDEF3 dijagrama za opis stanja tranzicije objekta.

20

Slika 10.5 IDEF3 dijagram opisa stanja tranzicije objekta

10.5 IDEF4.

IDEF4 objektno-orijentisan metod dizajna je projektovan za pomoć u korektnoj aplikaciji objektno-orijentisane tehnologije. IDEF4 koristi grafičku sintaksu i dijagrame i tiče se objekt-no-orijentisanog dizajna kao dela većeg okvira razvoja sistema.

Eksplicitno se primenjuje u razvoju softvera i sastoji se od tipičnih elemenata, tj. klasa i metoda podmodela, dijagrama nasleđa, dijagrama protokola, klijent dijagrama, dijagrama pri-mera, itd. Organizacija IDEF4 dijagrama prikazana je na slici 10.6.

Slika 10.6 Struktura IDEF4 dijagrama

10.6 IDEF5

IDEF5 obezbeđuje metod za kreiranje, modifikovanje i održavanje ontologije preko dva osnovna jezika: šematskog jezika (grafički) i jezika za elaboraciju (tekstualni). Na slici 10.7 prikazani su primeri jezičkih simbola IDEF5.

21

Slika 10.7 Primeri jezičkih simbola IDEF5

10.7 IDEF6 do IDEF14

Drugi članovi familije IDEF bave se širokim dijapazonom poslovnih i softverskih mode-lovanja, ali u ovom trenutku nisu dublje sprovodljivi. Oni su navedeni u tabeli 9.1

Tabela 9.1.

IDEF6 Obrazloženje projekta (dizajna)

IDEF8 Modelovanje korisničkog interfejsa

IDEF9 Otkrivanje posolovnih ograničenja

IDEF10 Implementacija arhitekture modelovanja

IDEF11 Modelovanje informacionih artefakata

IDEF12 Organizacija modelovanja

IDEF13 Dizajn mapiranja tri šeme

IDEF14 Dizajn mreže

11. Poređenje IDEF I UML

IDEF metodologija je primerena poslovnim modelarima da razumeju i prihvate poslovne operacije, a omogućava pouzdanu osnovu na inžinjering i reinžinjering poslovnih procesa.

IDEF familija jezika za modelovanje je uspela zbog pravovremenog nastupa, podrške američkih odbrambenih organizacija i činjenice da se doživljava kao korisnički prihvatljiva metodologija, suprotno drugim metodama modelovanja. Kao posledica toga, mnogi alati po-čeli su da podržavaju IDEF metodologiju. Neke IDEF metode mogu se koristiti u razvoju

22

softvera, na primer IDEF1x (relacione baze podataka) i noviji IDEF4 (objektno-orijentisane analize i dizajn).

Na prvi pogled, postoji sličnost između UML i IDEF familija jezika. UML je primarno bio zamišljen za dizajn softvera, dok IDEF svoj početak ima u računarski podržanoj proiz-vodnji. Interesantna činjenica je da je svaka od tih metodologija kasnije proširena na druge oblasti. Dok je UML proširen na pokrivanje poslovnog modelovanja, IDEF familiji dodate su nove komponente koje omogućavaju da se upuste u razvoj softvera (informacionih sistema uopšte).

IDEF0 je ekvivalentan UML dijagramima aktivnosti, uz korišćenje specijalnih poslovnih proširenja za modelovanje procesa.

IDEF1 i IDEF1x su slični UML dijagramima klasa i objekata, koji izražavaju statičke (ar-hitektonske) aspekte sistema.

IDEF2 je u nekoj meri ekvivalentan sa komunikacionim dijagramima, dijagramima ak-tivnosti i stanja u UML jeziku.

IDEF3 dijagrami opisa procesa su slični UML dijagramima aktivnosti, dok su dijagrami stanja tranzicije slični dijagramima stanja u UML. IDEF3 je, takođe, sličan dijagramima slu-čajeva upotrebe u odnosu na koncept scenarija.

IDEF4 su posebno usmereni prema razvoju softvera i kao takvi imaju sličnosti sa dija-gramima klasa, objekata, aktivnosti i stanja u UML.

IDEF5 može se porediti samo sa meta-modelovanjem u UML, gde je definisana ontolo-gija jezika.

Kao opšti zaključak, i UML i IDEF pristupi mogu se koristiti za modelovanje gotovo svih korisnih pogleda na biznis. Familija IDEF jezika ima tradiciju od više od 30 godina i iza nje stoje neka američka vladina tela (ministarstvo odbrane, ratno vazduhoplovstvo). Nove verzije i proširenja (kao, na primer, IDEF4 i IDEF5) usmereni su ka novim ili promenjenim zahte-vima.

UML je "mladi" jezik za modelovanje u poređenju sa IDEF, usmeren većinom na razvoj softvera. UML je jednostavan za učenje i može uvesti zainteresovane korisnike u napredne koncepte modelovanja, kao što su meta-modeli.

IDEF0 modeli odvajaju funkcije od organizacije, ali ne podržavaju specifikacije procesa, niti prihvataju vremenska ograničenja između aktivnosti. IDEF1 ne može se direktno koristiti u fazi implementacije. Međutim, on je izuzetno koristan u modelovanju informacija u biznisu. IDEF1x je dobar alat za osnovni dizajn baza podataka, ali ne sledi pravila dobrog grafičkog dizajna. Osim toga, ispravljanje jedne greške u IDEF1x dijagramu obično izaziva kaskadne izmene. Suviše složeni i prenatrpani IDEF3 dijagrami mogu rezultovati kombinacijom više pogleda i scenarija u jednom dijagramu.

12. ZAKLJUČCI

Ne postoje takve stvari kao konačna rešenja ili univerzalni alat, pa izazov nije da se pronađe konačan alat, nego pravi alat za posao. Isto važi i za poslovno modelovanje. Poslovno modelovanje pojavilo se kao odgovor na potrebu formalizacije poslovnih procesa u cilju da se omogući čuvanje ili ponovna upotreba poslovnih znanja. To se, međutim, može ostvariti samo ako je poslovno znanje formalno prikupljeno i organizovano u dobro definisanom okviru.

U današnjem konkurentnom svetu, biznis koji ne teži kontinuiranim promenama svoje efikasnosti (bolji proizvodi uz manje troškove) ne može da očekuje da traje veoma dugo. Sto-ga, drugi važan aspekt u životu (odvijanju) biznisa su promene. Donošenje dugoročnih prog-noza u okruženju koje se brzo menja je izuzetno teško. Kao posledica (ili rezultat) toga, pre-duzeće (biznis) mora ne samo brzo da se adaptira na promene, nego mora konitunirano da se

23

razvija. U tim uslovima, promene postaju više permanentan unutrašnji proces pre nego spoljni faktor kome preduzeće treba da se prilagodi.

Poslovno modelovanje proizašlo je iz CIM koncepta (računarski podržana proizvodnja, ali je postalo je jasno da su formulisani koncepti primenljivi na bilo koje preduzeće ili sistem u preduzeću.

Znatan napredak zabležen je u dizajnu softverskih alata i metoda. Mada je softver deo biznisa i namenjen je njegovoj podršci, mnogo vremena on se nije reflektovao u realnim pot-rebama. Između ostalog, osnovni uzrok može biti u modelovanju i implementaciji informa-cionog sistema u biznis koji treba da podrži. Otuda ideja da se:

koristi razvoj softverskih alata/metoda za poslovno modelovanje (sa odgovarajućim izmenama/proširenjima),

koriste poslovni modeli kao primeri za potrebe razvoja softvera.

U ovom radu analizirane su dve metode koje nastoje da ispune navedene ideje. Dve me-tode odnose se na različite grupe ljudi. Svaka ima prednosti i nedostatke, ali iskazuje isti trend: pokušavaju da pokriju druge domene tradicionalnih metoda.

IDEF je proizašao iz proizvodno/informacionog okruženja i usmeren je na pokrivanje objektne orijentacije, prikazivanje znanja i razvoj softvera. UML se nalazi u "ranom de-tinjstvu", proizlazi iz oblasti objektno-orijentisanog razvoja softvera, ali se ulažu veliki napori da se to proširi i na modelovanje poslovnih procesa.

Koji metod izabrati? To zavisi od korisnika: zadatak, osnova (pozadina), resursi, obrasci ... svi će igrati važnu ulogu u izboru pravog alata za posao.

LITERATURA

Bell, D.,UML basics: The sequence diagram, 2004, dostupno na:http://www.ibm.com/developerworks/rational/library/3101.html, [pristupljeno 10. 06. 2013.]Holub, A., UML Quick Reference (UML 2.0), version 2.1.3, dostupno na:http://www.holub.com/goodies/uml/, [pristupljeno 10. 06. 2013.]Object Management Group, OMG Unified Modeling Language (OMG UML), Infrastructure, Version 2.4.1, 2011, dostupno na:http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/, [pristupljeno 10. 06. 2013.]Rational Software Corporation, Artifact: Use-Case Model, dostupno na:http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_ucmod.htm, [pristupljeno 10. 06. 2013.]Wulp, M., et al., ArgoUML User Manual, v.0.32, 2011, dostupno na:http://argouml-downloads.tigris.org/argouml-0.32/, [pristupljeno 10. 06. 2013.]Mayer, R. J., IDEF Family of Languages Overview and Practical Guidelines for IDEF use - paper on the IDEF, dostupno na: http://www.idef.com/complete_reports, [pristupljeno 10. 06. 2013.]Panrahan, R., et al.: The IDEF Modelling Methodology, dostupno na:http://stsc.hill.af.mil/CrossTalk/1995/jun/IDEF.asp, [pristupljeno 10. 06. 2013.]Noran, O., VITE: The Fruit and Vegetable Virtual Enterprise, Enterprise Integration Assignment paper, Griffith University, November 1999, dostupno na:http://www.cit.gu.edu.au/~noran/cit_6118, [pristupljeno 10. 06. 2013.]Business Modelling: UML vs. IDEF, Griffith University, School of Computing and Information Technology , Domain: Modelling Languages, dostupno na:http://www.cit.gu.edu.au/~noran, [pristupljeno 10. 06. 2013.]Jović, A., Horvat, M., Grudenić, I., UML-dijagrami, Zbirka primjera i rješenih zadataka, Sveučilište u Zagrebu, Fakultet elektronike i računarstva, Zagreb, 2012.

24

Jeremić, Z., Uvod u modelovanje korišćenjem UML-a, Visoka škola elektrotehnike i računarstva strukovnih studija, dostupno na: www.viser.edu.rs/download/uploads/5850.pdf[pristupljeno 09. 06. 2013.]Nikolić, B., Modelovanje i implementacija IS za parking službu, Završni rad, Visoka škola strukovnih studija za informacione tehnologije, Zemun, 2006, dostupno na:http://www.its.edu.rs/cms/mestoZaUploadFajlove/Diplomski_rad_Bogdan_Nikolic.pdf, [pristupljeno 09. 06. 2013.]

25