dunp, kss, tim#1, oqt risk management expert ver 3.0

Optimal SQM, SQL Risk Management EXper

1

Sadraj 1 UVOD .................................................................................................................. 4

1.1 Rezime .......................................................................................................... 5 1.2 Anketa ........................................................................................................... 6 1.3 Definicija rizika .............................................................................................. 9

1.3.1 Definicije rizika ........................................................................................ 9 1.4 Tipovi rizika ................................................................................................. 10 1.5 Proces Upravljanja Rizikom ........................................................................ 12 1.6 Uloge i odgovornosti ................................................................................... 13 1.7 Softverski rizici ............................................................................................ 13

1 PISA - Poslovno Inteligentna Simualaciona Arhitektura ............................. 14 1.1 OQT MNGR ................................................................................................ 16 1.2 OQT SIM ..................................................................................................... 17 1.3 OQT BOX .................................................................................................... 18 1.4 OQT MAINT ................................................................................................ 19 1.5 OQT OPST .................................................................................................. 20

2 Risk Management eXpert .................................................................................. 21 3 Analiza i validacija postojeih konkurentskih reenja ........................................ 52

3.1 UTest .......................................................................................................... 52 3.1.1 Security paket ....................................................................................... 53 3.1.2 Usability paket ...................................................................................... 55 3.1.3 Utest mobile .......................................................................................... 59

3.2 SAP Risk Management ............................................................................ 61 3.2.1 Identifikacija upravljanja rizikom i predlog elemenata upravljanja ......... 63 3.2.2 Usvajanje i definisanje kontrole ............................................................ 67 3.2.3 Pregled procene rizika .......................................................................... 70

3.3 Managenable .............................................................................................. 71 3.3.1 Uzorci upravljanja interfejs rizikom ....................................................... 71

4 Spisak za proveru arhitekture ili checklist-a ...................................................... 77 4.1 Dizajn model ............................................................................................... 77 4.2 Dizajn podataka .......................................................................................... 78 4.3 Arhitekturni dizajn ........................................................................................ 78 4.4 Dizajn korisnikog interfejsa ........................................................................ 79 4.5 Component-level dizajn ............................................................................... 79

5 ANALIZA ARHITEKTURE I REALIZACIJA ARHITEKTURE ............................. 80

Optimal SQM, SQL Risk Management Expert

2

5.1 USE CASE DIJAGRAMI ZAHTEVA ............................................................ 80 5.2 DIJAGRAMI AKTIVNOSTI .......................................................................... 88 5.3 DIJAGRAMI SEKVENCI ............................................................................. 94 5.4 KLASNI DIJAGRAMI ................................................................................... 97 5.5 RISK MANAGEMENT EXPERT - TECH ................................................... 101

6 Dvolsojna arhitektura ........................................................................................ 23 7 Karakteristike troslojne arhitekture .................................................................... 24 8 Servisno orijentisana arhitektura (SOA) ............................................................ 26 9 CORBA ............................................................................................................. 29 10 CORBA -Distribuirani sistemi ......................................................................... 32 11 CORBA Arhitektura ...................................................................................... 33 12 Remote Method Invocation (RMI) ................................................................... 35

12.1 RMI osnove .............................................................................................. 38 12.2 Ulazno-izlazni tokovi podataka ................................................................ 38 12.3 Serijalizacija objekata .............................................................................. 41 12.4 Soketi ....................................................................................................... 42

13 RMI programiranje .......................................................................................... 43 13.1 Komunikacija klijentskog i serverskog objekta ......................................... 43 13.2 Realizacija RMI aplikacije ........................................................................ 44 13.3 Kreiranje serverskog programa ................................................................ 44

14 Pokretanje RMI aplikacije ............................................................................... 46 15 RMI tehnologija .............................................................................................. 47 16 Aplikaciona logika RMI realizacije studije sluaja-Kontroler ........................... 47 17 Aplikaciona logika RMI realizacije studije sluaja-Poslovna logika ................. 49 18 Monitoring RMI realizacije studije sluaja ....................................................... 50


3

Re autora:

Rizik se moe objasniti kao stohastika pojava. Rizini dogaaj ima veliinu pojave i vjerovatnou pojave na nekom podruju u odreenom vremenskom razdoblju.U prolom naem projektu, kroz postignuta znanja i umea predstavili smo softver za simulaciju softvera, koji je podvrgnut postignutim znanjem iz HCI tehnologija. Ako mislite da smo tu stali, e pa nismo, posle poslednjeg projekta i u perijodu ne duem od godinu dana, odluili smo baviti se RIZICIMA u softverskim sistemima, zapravo baviemo se rizik menadmentom, crpeemo znanja iz ve postignute tehnologije BISA platforme i pokuati kreirati novi softver koji e se baviti iskljuivo Rizik Menadmentom, na softver e se zvati RISK MANAGEMENT EXPERT.

EldinMujovi

Ja obino volim da se hvalim, posle odraenog posla, ali da, RIZICIMA emo se baviti u ovom poglavlju. Pokuaemo biti dosledni, dosadanjem postignutom kvalitetu, smartram da imamo dosta iskustva kada je u pitanju testiranje i simulacija softvera, rizikom smo se bavili i u naem predhodnom projektu, ali ovde e to biti razraeno do detalja i kreiranje jednog ovakvog softvera e biti zahtevan posao, ali trud se uvek isplati.

Naris Heo


4

1 UVOD

Sve to se moe povezati sa ljudskim ivotima je bez izuzetaka izloeno raznovrsnim rizicima koji mogu dovesti do neprocenjivih gubitaka. Izreka da nikad ne znamo ta e nam doneti sutra posebno je prisutna u poslovnom svetu. injenica je da ne moemo sa sigurnou predviati budunost to je rizicima osiguralo znaajno mesto u dananjem visoko-turbulentnom okruenju gde jata crnih labudova potope celokupne ekonomske sisteme u samo nekoliko dana. Statistiki podaci vie ne pomau u prognozama za budunost upravo zbog pojave novih i neoekivanih rizika.Rizici kao sastavni deo ivota dobivaju sve vei znaaj u poslovnim aktivnostima svih subjekata ili organizacija koje tee ostvariti eljene ciljeve. Svaka aktivnost koja se provodi generie odreene rizike koji se generalno ne mogu izbei. Jedini nain da se izbegnu svi (poslovni) rizici je da se nikako ne posluje, to naravno nije preporuljivo pa se oni nastoje minimizirati primjenom neke od tehnika dostupnih za upravljanje rizicima.

Enterprise Risk Management ili Upravljanje organizacijom zasnovano na rizicima predstavlja moderno shvatanje procesa koji je prethodno nosio naziv rizik menadment i bavio se iskljuivo istim rizicima. ERM uvodi novitet u smislu sveobuhvatnog pristupa svim rizicima kojima je organizacija izloena, tj.pored istih se razmatraju pekulativni i kontrolni rizici. To je dovelo do znaajnog pomaka funkcionisanja organizacija u smeru obuhvatanja, merenja i nadzora potencijalnih rizika kao i analize moguih gubitaka i dobitaka. Posao menadera koji se bave rizikom proirio se sa aktuarske naune oblasti i na finansijsku. Rizici su prepoznati u svim sektorima organizacije, pa se prema tome i rizik menaderi prilagoavaju datim uslovima i dodatno edukuju po potrebi. Rizik menaderi su otrebni u softverskoj industriji, bilo da su oni realizovani na softverki ili na nain ljudskih resursa. U softversim organizacijama rizici su jako zastupljna pojva i moraju se kontrolisati.

Organizacije najprije moraju razumjeti rizike da bi mogle njima pravilno upravljati. U tom sluaju je potrebno sagledati sve dostupne standarde koji su izdati od strane meunarodnih ili nacionalnih institucija. Time bi se definisali tipovi i koliine rizika koje su organizacije spremne preuzeti ili izbei. S obzirom da je potrebno vie vremena da se od ovih poetnih koraka doe do korporativnog upravljanja rizicima, organizacije takoe moraju delovati i izvan formalnih kontrola da bi se razvila neophodna kultura u kojoj menaderi samoinicijativno analiziraju rizike i povrate za dobrobit poslovanja. Kada je u pitanju klijent-server arhitektura i takva vrsta organizacija, rizici su sekundarna pojva, I optimalan menadment na njima mora takoe biti u korak sa pojvaljivanjem istih, tj. mora zadovoljavati pomenute standarde.

Za sve poslovne organizacije je u sutini najvanije shvatanje ta su rizici i na koji nain utiu na ostvarivanje uspeha i zacrtanih ciljeva. Odgovor na tu tezu u celosti daje ERM kao holistiki pristup koji znai aktivno identificiranje, procenu i upravljanje celim spektrom rizika.


5

1.1 Rezime

Enterprise Risk Management (ERM) je proces koordiniranog upravljanja rizicima koji stavlja vei naglasak na saradnju izmeu razliitih odeljenja za upravljanje svim organizacijskim rizicima u celini. To je najnovija forma rizik menadmenta koja koristi holistiki pogled za sve neizvesne faktore koji mogu uticati na materijalnu i nematerijalnu imovinu organizacije.

Rizik je realnost sa kojom se trebaju suoiti sve organizacije, bez obzira na model poslovanja. ERM nudi okvir za efikasno upravljanje neizvesnosti, reagiranje na rizik i iskoritavanje mogunosti kada se pojave. Za razliku od prethodnih praksi za upravljanje rizicima, koncept ERM utjelovljuje ideju da analiza rizika preseca itavu organizaciju. Organizacije su tradicionalno koristile silos pristup upravljanju rizicima koji je posmatrao individualne performanse poslovnih jedinica umjesto holistikog pristupa koji se obazire na dugoroni uticaj rizika i poslovnih potreba cele organizacije. Sve je vea potreba organizacija da trajno povezuju svoje rizike preko poslovnih jedinica i da usvoje ovaj sveobuhvatni okvir.

Bez obzira koliko su dobro planirane i ispunjene, procedure rizik menadmenta ne mogu uvijek garantovati rezultate. Ipak, koritenje okvira za upravljanje rizicima moe poveati organizacijsko i dioniarsko povjerenje da e ostvariti svoje ciljeve. U tom sluaju, ERM se razvija u alat koji se moe koristiti za poveanje vrijednosti firme. Programi rizik menadmenta se trebaju neprestao ocenjivati. Kao to poslovanje nije statian pojam, tako se ni ERM ne moe posmatrati kao projekat koji treba biti zavren.

Ovaj rad takoe razmatra i probleme sa kojima se susree rizik menadment i moderni rizik menaderi. Za njih je vano da percipiraju svoje odgovornosti i formiraju uloge za budui razvoj i poboljanje ERM.

Ako razmiljamo o riziku, kao potencijalnom problem, koji moe naruiti red I mir u naoj organizaciji u ovom sluaju softverskoj organizaciji, onda moemo uvideti da taj problem moramo reavati, kao I bilo koji drugi problem, poto smo iz predhodnog projekta uvideli da problem moramo reavati preventivno, I sam rizik kao problem moramo prdvideti I reavati. S toga emo se truditi kreirati softver koji e se baviti ovim problmemom na najbolji mogui nain.


6

1.2 Anketa

Zato ba anketa? Pomou ankete detaljno emo sagledati kako zapravo rizik utie na odreene kompanije, i koliko je zapravo vano, preventivno delovati na rizik. Anketa je vrena na kompaniju Schneider Electric iz Srbije. Schneider Electric je svjetski strunjak u upravljanju energijom sa poslovanjem u vie od 100 zemalja, gdje nudi integrisana reenja kako bi energiju uinili bezbednom, pouzdanom, efikasnom i produktivnom na polju energetike i infrastrukture, industrije, data centara, graevinarstva i trita stambenih objekata. Kompanija je osnovana 1836.godine u Francuskoj, danas vredi 31 milijardu eura a poslovala je sa 19.6 milijardi eura prodaje u 2010. godini. Zapoljava preko 110 000 radnika. Na tritu Srbije kompanija posluje od 1997. godine kada je u Beogradu otvoreno predstavnitvo, a od 2002. kompanija posluje kao D.O.O. prema sklopu strukture sa naredne slike. Ova kompanije je pravi primer, na kome moemo sagledati bit rizik menadmenta.

Anketne tabele i ocene koje emo sagledati je popunio i nama dostavio glavni finansijski direktor Slobodan epini, dipl.ecc.


7

Uputstvo za ocene: Ocena 1 podrazumeva 100% neslaganje sa tezom, ocene od 2 do 4 podrazumevaju 20-40% slaganje sa tezom, ocena 5 podrazumeva 50% slaganje sa tezom, ocene od 6 do 9 podrazumevaju 60-90%, dok ocena 10 podrazumeva 100% slaganje sa tezom. Vee ocene podrazumevaju vei stepen primene rizik menadmenta. Prosek ocena ispod 5 je nezadovoljavajui, 5 je prihvatljivi a sve iznad predstavlja dobar rezultat za primenu rizik menadmenta u organizaciji.

A Proces upravljanja rizicima Ocena Odgovor

1 U kompaniji postoji organizaciona jedinica koja je zaduena za RM (tj. identifikaciju rizika, njihovo merenje, izbor metoda kontrole i/ili finansiranja rizika i sl.).

5 U kompaniji postoji vie osoba koje obavljaju poslove vezane za RM.

2 Za identifikaciju rizika kompanija koristi sljedee metode: upitnike, analizu finansijskih izvetaja, pregled na terenu, intervju, dijagram toka, analizu ugovora, analizu iskustva iz prolosti, analizu hazarda, razmenu informacija meu pojedinim organizacionim jedinicama i sa vanjskim partnerima, itd. Te metode u potpunosti odgovaraju specifinosti poslovanja kompanije.

7 Kompanija koristi gotovo sve metode.

3 Merenje rizika, odnosno procenu njihovog intenziteta i uestalosti, kompanija vri primenom sljedeih metoda: statistikih metoda, teorije verojatnoe, SWOT, scenario analize, itd. Kroz dosadanju praksu te metode procene rizika pokazale su se uspenim.

7 Kompanija koristi gotovo sve metode.

4 Zadravanje rizika, kao metodu RM, kompanija koristi u sluaju rizika koji imaju malu jainu (intenzitet). 6 Kompanija pored rizika koji imaju malu jainu zadrava i neke rizike koji imaju veliku jainu.

5 Za imovinske rizike kompanija koristi osiguranje kao metodu RM. 9 Kompanija osigurava svu imovinu.

6 Za line rizike (odnose se na zaposlene) kompanija koristi osiguranje kao metodu RM. 8 Kompanija osigurava sve zaposlene.

7 Kompanija koristi izbegavanje rizika kao metodu zatite od rizika. 8 Kompanija izbegavanje rizika koristi kada je to potrebno.

8 Kompanija vri transfer rizika koji nije zasnovan na osiguranju. 7 U veini sluajeva kompanija koristi ovu metodu, kada se moe ona koristiti.

9 Kompanija poseduje formalni dokument strategije RM, koja je usklaena sa njenim specifinostima i koja se prati u svim fazama implementacije. 6 RM je reguliran kroz razne procedure.

10 Kompanija vri monitoring (praenje) RM i, shodno nalazima/rezultatima, implementira korektivne mjere. 8 Praenje se vri za gotovo sve poslovne funkcije.

11 Za utvrivanje uspenosti procesa RM kompanija koristi odabrane performanse i indikatore koji najbolje mogu pokazati uspenost odnosnog procesa. 7 Kompanija koristi mnotvo perfomansi i indikatora.

12 Kompanija je upoznata sa ISO 31000:2009 standardom, koji se odnosi na RM i implementira ga (ili postoje indikacije o njegovoj skoroj implementaciji). 6 Kompanija e implementirati standard.

A: Proces upravljanja rizicima - Iz prve teze se moe zakljuiti da organizacija koristi silos pristup, prema kojem svaki sektor sprovodi proces upravljanja rizicima prema svojim odgovornostima. To predstavlja najslabiju stavku upravo zbog nedostatka


8

jedinice rizik menadmenta. Meutim, iz narednih odgovora se vidi da kompanija namerava implementirati standard ISO 31000:2009, koji promovie holistiki pristup upravljanja rizicima u preduzeu odnosno Enterprise Risk Management. Osiguranje je generalno najzastupljenija metoda upravljanja rizicima, gde se rizik nastoji izbei kako za imovinu tako i za zaposlene. Ova kompanija koristi i druge metode transfera rizika, pored osiguranja. Praenje se vri kroz sve poslovne funkcije to je predstavljeno visokom ocenom, tako da je ukupni dojam iznad zadovoljavajueg. Prosena ocena za ovaj deo ankete je 7.

B Proces upravljanja rizicima Ocena Odgovor

1 Kompanija je spremna prepoznati globalne rizike iz okruenja koji su prouzrokovani uslovima na tritu i promenama ekonomskih kretanja. 8 Kompanija je spremna.

2 Kompanija je u mogunosti da identifikuje sve potencijalne rizike iz okruenja koji utiu na procese investiranja, nabavke, prodaje i politike kadrova. 8 Kompanija identifikuje veliki broj rizika prije njihovog uticaja na poslovanje.

3 Kompanija ima adekvatne procedure koje mogu osigurati brzu reakciju na neregularnosti u poslovanju (tipa prevara, utaja, i slino). 8 Kompanija ima procedure koje u potpunosti zadovoljavaju njene potrebe.

4 Poslovni proces je u mogunosti da identifikuje i ugradi u poslovanje irok spektar ekonomskih promena kao to su promene deviznih kurseva, kamatnih stopa, promena pozicije dobavljaa na tritu, cena proizvoda i usluga potrebnih za nesmetano obavljanje

9 Kompanija reaguje na veliki broj ekonomskih promena.

5 Kompanija je u mogunosti da identifikuje sve potencijalne rizike i da adekvatno reaguje na njih (efikasnost i efektivnost poslovnog procesa isl.). 7 Kompanija identifikuje rizike i reaguje na njih.

6 Formalni proces ima potrebne znaajke da osigura prave talente, odnosno kompetentno osoblje za trenutni i budui rast kompanije prema stratekim opredjeljenjima.

6 Kompanija ima struno osoblje koje treba da se usavrava.

7 Izvjetaji o poslovanju podrazumevaju i izvetavanje o rizicima. 10 Kompanija ima deo koji govori o RM, ali on jo uvek nije sveobuhvatan.

B: Rizici poslovanja - Iz ovog dijela se moe zakljuiti da kompanija Schneider ima razvijene procedure za identifikovanje i prepoznavanje rizika da bi se osigurala brza i adekvatna reakcija na njih. Kroz objanjenje ocjena se moe vidjeti da kompanija djeluje proaktivno ali izostaje sveobuhvatni nain tretiranja rizika, odnosno neki oblik Enterprise Risk Managementa. Izvjetaji o poslovanju podrazumijevaju i izvjetavanje o rizicima, a veliki plus je i pravovremeno reagovanje na ekonomske promjene. Prosjena ocjena za ovaj dio ankete je 7.


9

1.3 Definicija rizika Oxfordski engleski rijenik definie rizik kao verovatnou ili mogunost opasnosti, gubitka, povrede ili druge tetne posledice i u drugim navodima kao izloenost opasnosti. U tom kontekstu, rizik se koristi da oznai negativne posledice. Meutim, preuzimanjem rizika se moe doi i do pozitivnog ishoda. Trea mogunost je ta da je rizik povezan sa neizvesnou ishoda.

Definicije rizika se mogu nai u vie verzija. Tradicionalno se definie na osnovu neizvesnosti i gubitka. Takva jedna definicija od strane Rejde je opisana kao neizvesnost ostvarivanja gubitka. Ukoliko postoji rizik, moraju postojati makar dva mogua ishoda. Ako se unapred zna da se gubitak nee ostvariti ili da e se ostvariti, onda rizik ne postoji. To je posledica neizvesnosti i nedostatka znanja o buduim deavanjima. Na primjer, verovatnoa dogaaja koji su neostvarivi jednaka je nuli, dok verovatnoa da e se dogoditi izvesni dogaaj je jednaka broju jedan. U terminima verovatnoe, neizvesnost znai da se verovatnoa procenjuje izmeu 0 i 1. Upravo zbog toga neki autori izjednaavaju neizvesnost i rizik.

Zavisno od organizacija, rizik se moe definisati na razliite naine. Kada je re o osiguravajuim drutvima, rizik se definie na osnovu odreenog broja gubitaka i njihov iznos predstavlja iznos predvienih gubitaka, pa definicija moe glasiti da je rizik verovatnoa negativnog odstupanja gubitaka od oekivanog ishoda. Tako T. Vaughan i E. Vaughan definiu rizik kao stanje u kojem postoji mogunost negativnog odstupanja od eljenog ishoda koji oekujemo ili kojem se nadamo.

Alternativne definicije su uvedene iz razloga da se ukae na iroki spektar rizika koji mogu uticati na razliite organizacije. Institut za rizik menadment (IRM) definie rizik kao kombinaciju verovatnoe dogaaja i njihovih posljedica. Posljedice mogu varirati od pozitivnih do negativnih. Ovo je iroko primjenjiva i praktina definicija koja se moe lako shvatiti.

Meunarodni prirunik koji obuhvata definicije vezane za rizike, ISO Prirunik 73, definie rizik kao efekat neizvesnosti u odnosu na ciljeve. Ovaj prirunik objanjava da efekat moe biti pozitivan, negativan ili predstavlja odstupanje od oekivanog. Ove tri vrste dogaaja povezane sa rizicima mogu biti opisane kao prilika (mogunost), hazard (opasnost) ili neizvenost kako se i navodi u narednoj tabeli. Tu su date neke od definicija koje se iroko primjenjuju u poslovnom svietu rizika.

1.3.1 Definicije rizika

Organizacije DEFINICIJE RIZIKA

SO Prirunik 73 ISO 31000

Uticaj neizvesnosti na ciljeve. Ti efekti mogu biti pozitivni, negativni ili odstupati od oekivanog. Takoe, rizik se esto opisuje na osnovu dogaaja, promene u okolnostima, ili posljedica aktivnosti.

Institut za rizik menadment (IRM)

Rizik je kombinacija verovatnoe dogaaja i njihovih posledica. Posledice mogu varirati od pozitivnih do negativnih.

Orange Book iz HM Treasury

Neizvesnost ishoda, u rasponu izloenosti, koja proizilazi iz kombinacije uticaja i verovatnoe potencijalnih dogaaja.

Institut internih revizora (IIA)

Neizvesnost dogaaja koji bi se mogao desiti i uticati na ostvarivanje ciljeva. Rizik se meri u smislu posledica i verovatnoe.

Alternativna definicija

Dogaaj sa mogunou uticaja (spreavanja, poveavanja ili uzrokovanja sumnje) na ispunjenje misije, strategije, projekata, rutinskih operacija, ciljeva, temeljnih procesa, zahtjeva stakeholdera.


10

Rizik u organizacijskom kontekstu je obino definisan kao neto to moe uticati na ispunjenje korporativnih ciljeva. Meutim, korporativni ciljevi nisu u potpunosti navedeni u veini organizacija i teko ih je materijalizirati. Da bi se rizik materijalizirao, dogaaj se mora dogoditi. Ukoliko se fokus stavi na ove dogaaje, javlja se i vea verovatnoa uspene primene procesa rizik menadmenta. U taj proces spadaju faze poput identifikacije dogaaja koji mogu uticati na provedbu ciljeva, analize i evaluacije da bi se umanjila ili izbegla teta nastanka negativnih ishoda. Zatim se izabire adekvatan nain upravljanja rizicima. Sve zavrava fazama monitoringa i pravljenjem izvetaja o uspenosti ispunjenja zacrtanih ciljeva, uz kontinuiranu kontrolnu problematinih pozicija.

1.4 Tipovi rizika

Rizici se mogu klasificirati na razliite naine. Nemogue ih je razvrstati prema jedinstvenom kriterijumu pa se na osnovu toga pojavljuju razliite klasifikacije od strane razliitih organizacija. I pored specifinih rizika koji se pojavljuju samo u nekim finansijskim institucijama (npr.rizik polisa osiguranja specifian za osiguravajua drutva) takoe postoji mnotvo zajednikih rizika prisutnih u svim poslovnim aktivnostima razliitih finansijskih institucija. Na osnovu pristupa upravljanju rizicima gruba podela rizika se odnosi na opte i specifine. Opti rizici obuhvataju iste rizike, pekulativne, osnovne, pojedinane, dinamike, statike, finansijske (kreditni, trini, rizik likvidnosti, operativni rizik, zakonski, politiki, rizik poravnanja, solventnosti, dobiti, dogaaja), nefinansijski, sistemski, nesistemski. Specifini rizici u odnosu na organizacije koje ih najee identifikuju su bankarski rizici, rizici osiguravajuih drutava, rizici investicionih fondova, rizici poslovnih organizacija...

Openito rizici mogu biti sa pozitivinim, negativnim ili neutralnim ishodom. U sluaju pozitivnog ishoda, rizik je predstavljen kao prilika, dok je za situaciju gdje se oekuje negativni ishod obino odreen pojmovima gubitka ili neutralnog delovanja (ako se dogaaj ne desi). Svaki rizik ima svoje karakteristike koje zahtevaju odreeni vid analiza ili upravljanja. Tipovi rizika e se predstaviti u tri kategorije:

Hazardni (ili isti) rizici

Kontrolni (ili neizvjesni) rizici

Rizici prilike (ili pekulativni rizici)

Vano je napomenuti da ne postoji prava ili pogrena podela rizika. Moe se naii na razliite klasifikacije u drugim standardima ili knjigama, ali se sve one smatraju ispravnim i prikladnim za odreene situacije. Najuestalija je podela rizika na iste i pekulativne, ali openito postoje mnoge rasprave o terminologiji tipova rizika i njihovim upravljanjem. Bez obzira na teorijske rasprave, najvanije je da organizacija usvoji sistem klasifikacije rizika koji joj je najpogodniji za vlastito poslovanje.


11

Postoje odreeni rizici dogaaja ije posljedice rezultiraju samo negativnim ishodima. To su hazardni ili isti rizici, koji su osnovni predmet osiguranja. Organizacije mogu napraviti planove i programe odgovarajue tolerancije ovih rizika, ali i u okviru tog plana treba postojati stepen upravljanja i monitoringa. Jednostavan primjer istog rizika sa kojim se suoavaju mnoge organizacije je kraa ili poar.

Takoe postoje rizici koji ispoljavaju velike nesigurnosti o ishodu situacije. To su kontrolni rizici i esto su povezani sa nepoznatim i neoekivanim dogaajima ili upravljanjem projektima. Openito, organizacije imaju averziju prema kontrolnim rizicima iz razloga to se teko kvantifikuju. esto ih je nemogue predvideti, naroito preko historiskih podataka i tehnika distribucije. Vezano za projekte, nesigurnosti mogu proizilaziti iz prednosti koje projekat kreira, kao i neizvesnosti isporuke projekta na vrijeme, unutar budeta i plana realizacije. Upravljanje rizicima kontrole se esto preduzima da bi se osigurao rezultat poslovnih aktivnosti unutar eljenog raspona sa proaktivnim delovanjem.

U isto vrijeme, organizacije svesno preuzimaju rizike, posebno trine ili komercijalne, u cilju da postignu pozitivan povrat. Ovi rizici pruaju mogunosti ostvarenja prinosa i nazivaju se pekulativnim rizicima. Postoje dva aspekta povezana sa ovim rizicima, i to jedan koji se odnosi na opasnost preuzimanja mogunosti, dok drugi predstavlja rizik proputanja prilike. Organizacije imaju posebnu naklonost za investiranje u pekulativne rizike. Manje organizacije prihvataju rizike mogunosti u vidu pomeranja poslovanja na novu lokaciju, sticanje novih nekretnina, irenje biznisa, diverzifikacije kroz nove proizvode itd.

Po pitanju ERM-a, potrebno je istaknuti tzv. preduzetni rizik (enterprise risk) kao preteno noviji termin za sve rizike ije delovanje direktno utie na poslovanje preduzea. Preduzetni rizik obuhvata iste, pekulativne, finansijske, strategijske i rizike poslovanja. Kako su isti i pekulativni rizici objanjeni prethodno, potrebno je za ovu klasifikaciju pojasniti finansijske i strategijske, kao i poslovne (operativne).

Finansijski rizici se odnose na neizvesnost gubitka radi negativnih promjena u cenama, kamatnim stopama, deviznom kursu i vrednosti novca. Strategijski rizik predstavlja neizvesnost u pogledu realizacije finansijskih ciljeva i instrumenata preduzea. Operativni rizici ili rizici poslovanja proizilaze iz poslovanja preduzea i odnose se na gubitke koji proistiu iz neadekvatnih ili neuspenih internih procesa, ljudi i sistema.

Preduzetni rizik (rizik preduzea) postao je najvaniji u upravljanju komercijalnim rizicima. ERM unosi novitet da menaderi koji upravljaju rizicima razmatraju sve vrste rizika u nekom programu. Upravljanje rizicima u preduzeima (ERM) podrazumjeva da se jedinstvenim programom obuhvate svi vaniji rizici sa kojima se preduzee suoava. Ako grupie vanije rizike u taj program, preduzee moe da neutralie odnosno da izjednai dejstvo jednog rizika sa dejstvom drugih rizika. Rizici koji ne uslovaljavaju jedni druge, koji nisu ni u kakvoj vezi, se mogu kombinovati i time umanjiti ukupne posledice rizika, naroito ako se kombinuju rizici koji se meusobno iskljuuju.


12

1.5 Proces Upravljanja Rizikom

Kada neka organizacija odlui implementirati rizik menadment u svoj svakodnevni ivot, prvo se donosi odluka o organizovanju sistema za upravljanje rizicima koji se odvija putem procesa.

Na osnovu prethodne slike, elementi za proces upravljanja rizicima se opisuju na sljedei nain:

-Komunikacija i konsultacija: Komunikacija i konsultacija sa internim i eksternim ulagaima zainteresiranim stranama, kako je primjereno (tehnoloki), na svakom stepenu procesa upravljanja rizikom i razmatranje procesa kao cjeline.

-Utvrivanje konteksta: Utvrivanje eksternog, internog i konteksta upravljanja rizikom u kojem e se odvijati ostatak procesa. Treba utvrditi kriterije prema kojima e se procjenjivati rizik i definisati struktura analize.

-Identifikacija rizika: Identifikacija gdje, kada, zato i kako bi dogaaji mogli sprijeiti, umanjiti, odloiti ili poveati postizanje ciljeva.

-Analiza rizika: Identifikacija i procjena postojeih kontrola. Odreivanje posljedica i vjerojatnoe a zatim nivoa rizika. Ova analiza treba razmotriti podruje potencijalnih posljedica i njihovu pojavu.

Slika 1.5.1: Prikaz upravljanja rizikom u ovoj kompaniji.


13

-Vrednovanje rizika: Poreenje procijenjenih nivoa rizika sa prethodno utvrenim kriterijima i razmatranje ravnotee izmeu potencijalnih koristi i nepovoljnih rezultata. To omoguuje donoenje odluka o obimu i prirodi potrebnih obrada i o prioritetima.

-Obrada rizika: Izrada i primjena specifinih trokovno-efikasnih strategija i akcijskih planova za poveanje potencijalnih koristi i smanjenje potencijalnih trokova.

-Monitoring i pregled: Neophodno je pratiti efikasnost svih koraka procesa upravljanja rizikom. To je vano za stalno poboljavanje. Potrebno je pratiti rizike i uinkovitost mjera obrade kako bi se osiguralo da promjena uslova ne mijenja prioritete.

1.6 Uloge i odgovornosti

Svako u organizaciji ima neku odgovornost za ERM. Glavni izvrni direktor (CEO) je u konanici odgovoran i treba preuzeti tu odgovornost. Ostali menaderi podravaju filozofiju upravljanja rizicima u organizaciji, promoviraju usklaenost sklonosti riziku i upravljaju rizicima u podrujima za koja su odgovorni. Rizik menader, finansijski direktor, interni revizor i drugi obino imaju kljune odgovornosti. Ostalo osoblje organizacije odgovorno je za izvravanje upravljanja rizicima u skladu sa utvrenim smjernicama i protokolima. Upravni odbor nadzire ERM i podrava odluke o sklonosti riziku. Broj vanjskih stranaka kao to su kupci, dobavljai, poslovni partneri, vanjski revizori, regulatori i finansijski analitiari esto daju korisne informacije to utie na efikasnost ERM ali nisu odgovorni za efikasnost niti su dio ERM procesa organizacije.

1.7 Softverski rizici

Svakako ono ime se mi bavimo i do ega mi elimo doi svim ovim definisanjem rizika jeste zapravo rizik menadment u softverskim organizacijama. Prva pomisao kada se kae softver pomisli se na ogromne linije koda koje su programirane kako bi obraivale odreene algoritme. ak i ta prva pomisao ima u sebi gomilu rizika, da li je kod ispravno napisan, da li moe doi do beskonane petlje, da li su uslovi ispunjeni, i standardizacija izvrena, da li je broj linija koda dovoljno koncizan, i jo puno osvrta na mogue rizike. Ali kada pomislimo na kompletan softver in a kompletne aplikacije onda se rizici proiruju.

Tada rizici imaju ovi pogled, jedan od rizika bi bila bezbednost, preoptereenost na mrei, i jo ogroman broj rizika, kojima treba adekvatno upravljati. Na zadatak bi bio, stvoriti softver koji e upravljati svim ovim. Dozvoliete da izloimo odreena konkurentska reenja a potom predstavimo concept koji smo mi zapravo zamislili.


14

Slika 1.1 Novi logo PISA (Poslovno Inteligentna Simualaciona Arhitektura) kompanije.

1 PISA - Poslovno Inteligentna Simualaciona Arhitektura

PISA predstavlja skup njboljih model i tehnik iz prkse, integrisnih u optimizovn i kvntittivno rukovoden proces rzvoj, testirnj i odrvnj softver. To su pre svega ekspertski alati koji se integriu na zahtev korisnika.

Okruenje z simulciju scenrij rzvoj kvlitetnog softver koje omoguv minimizciju trokov i rizik, izborom lterntivnih plnov testirnj koji zdovoljvju ogrnienj u pogledu slobodnih resurs, kriterijum optimlnosti i performnsi dte kompnije i ekonomski model kvlitet softver z ocenu ispltivosti predloenih ktivnosti SQA, mere z poboljnje PRSPTS (Proces Razvoja Softvera, Proces Testiranja Softvera) n osnovu ekonomskih prmetr. Razvoj softvera troi vie od polovine svog budeta na aktivnosti povezane sa testiranjem u toku projektovanja softvera i na odravanju softvera nakon njegove predaje na upotrebu.


15

Razvoj softvera obuhvata:

Precizno planiranje(resursa, trokova, trajanja, obuke kadra i td.) Identifikaciju, procenu i kontrolu rizika na softverskom projektu Utvrdivanje merenja kvaliteta softverskog proizvoda Kvantitativno upravljanje procesom testiranja tj. aktivnostima osiguranja

kvaliteta softvera u cilju poveanja efikasnosti otkrivanja greaka u toku razvoja softvera.

Poto je nemoguce izvriti testiranje i dokazati da je softver bez greke kako u fazi razvoja tako i u fazi odravanja softvera cilj ovog projekta bi bio da se predloi model odgovarajue metode i algoritmi i odgovarajue softverske alate za integralni i optimizirani proces testiranja i odravanja softvera. U postizanju to boljeg kvaliteta softverskog proizvoda optimizacija se vri uz navedena ogranienja u pogledu vremena i predvidenog budeta.

Slika 1.2: Komponente softverske arhitekture OpimalSQM reenja


16

1.1 OQT MNGR

OQT MNGRkomponenta se nalazi u srcu PISA-e, obezbeuje integrisano i koherentno upravljanje multidisciplinarnim aspektima operacija testiranja, omoguavajui naprednu generaciju pravila testiranja. MNGR sadri SaaS-ove (Softwere as a Service) paradigme pravila - koja e biti prvi industriski jezik scenarija za testiranje softvera sa lako prilagodljivim unapred definisanim predlocima pravila - za reavanje kritinih vektorskih (preko 100 promenljivih) u procesu upravljanja testiranjem. Takoe, vana funkcija MNGR komponente je da prui sve upitnike na projektu: aktivnosti razvoja procesa i bitne stavke produktivnosti procesa radi izraunavanja ogranienja procene rizika i radi postizanja odrive procene odreenih preduzea i projekata.1

1 Obrada je zasnovana na osnovu literature glavnog PISA sajta, uz potpunu saglasnost Prof. dr Ljubomira Lazia - http://www.bisa.rs/PISA/

Slika 1.1.1: OQT MNGR komponenta i njene osnovne funkcionalne celine.


17

1.2 OQT SIM

OQT SIM componenta simulira procese (scenarije) testiranje na osnovu uspostavljenih pravila i algoritama koji su bazirani na empirijskim rezultatima testiranja, kvalifikacijom potencijalne koristi ovih pravila pre primene.

Zahvaljujui nadgledanjem planiranja, OQT-SIM takoe proverava poboljanje kvaliteta i efikasnosti postojeih pravila postavljenih tokom vremena, to omoguava poreenje stvarne koristi baziranih na akumulaciji informacija u realnom svetu procesa testiranja za razne vrste softverskih proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj pruamo servis. OQT-SIM nudi tano razumevanje stvarne koristi i ROI postavljenih pravila, prua dokaz koncepta za vie scenarija stvarnih performansi konkretne kompanije i konkretnog projekta te kompanije (iz sopstvene metrike ili usrednjene baze merenih karakteristika tipa softverskog proizvoda koji se razvija, performansi razvojnog tima, procesa testiranja u datoj kompaniji i sl.), procenu optimalnog scenarija za dati projekat na bazi rezultata simulacije moguih scenarija testiranja spremljenog pre primene u realizaciji datog konkretnog softverskog projekta. SIM nudi simulaciju ablona koji sadre algoritme iz razliitih porodica softverskih proizvoda, nivoa zrelosti softverskih kompanija, kao to su smanjenje vremena testiranja, napredna statistika kontrola procesa, kvalitet i pouzdanost, smanjenje naknadne dorade usled napravljenih greaka u svim fazama razvoja softvera. Svaka familija stimulacije je bogata sa pravilima koji su posebna meta poslovnih potreba. Potpuno integrisan sa svim drugim OQT-MNGR ,modelima, OQT-SIM omoguava simulaciju pravila i postavljena pravila definisana u OQT-pravilima, koji onda mogu biti objavljeni putem OQT-MNGR u realnom vremenu ili kasnijem radnom okruenju. Simulacijoni tok je intuitivan, jednostavan za korienje i podran je jakom metodologijom.

Slika 1.2.1: OQT SIM komponenta i njene osnovne funkcionalne celine.


18

1.3 OQT BOX

OQT BOX komponenta e biti najbolja praksa i skup univerzalnih tehnika za testiranje softvera po metodi Crne kutije, Bele kutije i Sive kutije u IT industriji, koje e biti spremljene za sve vrste softverskih proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj pruamo servis i kupljene softverske alate za testiranje. BOX komponenta e biti potpuno nezavisna od modela procesa razvoja softvera i vrste softverskih proizvoda, podravajui sve nivoe i tipove testiranja softvera. Kao deo reenja OptimalSQM-a, izvravae se na zahtev OQT MNGR komponente, a na osnovu proverenih pravila koja su kreirana i proverena simulacijom moguih scenarija testiranje softvera pre njihove primene u tesetiranju konkretnog softvera koji razvija i testira konkretna kompanija sa svojim ljudskim, procesnim i laboratorijskim kapacitetima, a prema uspostavljenim kriterijumima efikasnosti i efektivnosti za sve SDLC aktivnosti.2


Slika 1.3.1: OQT BOX komponenta i njene osnovne funkcionalne celine.


19

1.4 OQT MAINT

OQT MAINT komponenta razmilja o svim rezultatima testiranja radi poboljanja kontrole kvaliteta i upravljanja svim aspektima operacija testiranja u korektivnom, adaptivnom i perfektivnom odravanju softvera kako u toku razvoja tako i nakon isporuke softverskog proizvoda na upotrebu. MAINT komponenta vri unakrsne procene kvaliteta svih flota testiranja, za sve procene efikasnosti testiranja u otkrivanju i otklanjanju defekata (poveenje prinosa otkrivenih greaka), nudei ekstremni integritet podataka. Osim toga, MAINT komponenta poboljava pouzdanost softvera kroz SRE (Software Reliability Engineering) metodologiju metrike pouzdanosti softverskog proizvoda u predvianju i proceni kritinih faktora kao to su: stopa greaka po fazama razvoja softvera, konana stopa greaka nakon 6 meseci upotrebe softvera, gustine greaka na KSLOC ili FP metrici veliine softvera, profil greka itd. Na osnovu ovih podataka MAINT komponenta obezbeuje kompletnu tehniku podrku nakon putanja softverskih proizvoda u promet, odnosno program za aktivnosti odravanje tj.za korektivno, adaptivno, perfektivno i preventivno odravanje na optimizovan nain.3


Slika 1.4.1: OQT MAINT komponenta i njene osnovne funkcionalne


20

1.5 OQT OPST

OQT OPST komponenta (OPeratinonal Software Testing) treba timu za planiranje i sprovoenje testiranja konkretnog razvijanog softvera, konkretne kompanije (Project Specific Software Testing) omogui da na osnovu stvarnih performansi konkretne kompanije i konkretnog projekta te kompanije i pronaenog optimalnog scenarija za dati projekat na bazi REZULTATA izvrenih simulacija (OQT SIM komponente) moguih scenarija testiranja pre primene u realizaciji datog konkretnog softverskog projekta odredi karakteristike integralnog i optimalnog PTS (IOPTS). Dakle, na osnovu sopstvene metrike ili usrednjene baze merenih karakteristika tipa softverskog proizvoda koji se razvija, performansi razvojnog tima, zrelosti (TMM nivoa) procesa testiranja u datoj kompaniji i sl., odredi aktivnosti i objekte testiranja u takama provere artifakata datog PTS (SDLC), odredi adekvatne tehnike detekcije greaka koje obezbeuju zahtevani kvalitet tokom razvoja softverskog proizvoda u okvirima projektnih ogranienja tj. sve parametre IOPTS.4


Slika 1.5.1: OQT OPST komponenta i njene osnovne funkcionalne celine.


21

2 Risk Management eXpert

Risk Management eXpert treba da u saradnji sa Profit eXpert sofverskim alatom prui servis menaderima dizajna i testiranja softvera u: identifikaciji, proceni efekata, plana aktivnosti smanjenja i kontrole rizika na prihvatljivom nivou, datog softverskog projekta.

Risk Management eXpert koristi veliku bazu podataka koja sadri vie od 8 000 projekata koji se koriste u modelu za optimizaciju testiranja baziranom na riziku u cilju otklanjanja defekata u ranim fazama projekta i poveanja pouzdanosti softvera.

Upravljanje rizicima je glavni problem u planiranju i upravljanju bilo kojim poduhvatom. U oblasti softvera, upravljanje rizicima je krucijalna disciplina. Proces upravljanjem rizicima obuhvata analiziranje, planiranje, praenje, kontrolu i diskutovanje o rizicima. Alatka Risk Management eXpert prua struktuirani mehanizam kojim se omoguava da se proceni delotvornost pretnje na uspenost projekta.

Upravljanje rizicima je disciplina koja omoguava da se projekat realizuje uprkos pretnjama koje ga okruuju, a posao Risk Management eXperta je da te pretnje proceni na osnovu merljivih podataka i da da mogua reenja za umanjivanje efekta rizika.

Pravi zadatak Risk Management eXperta je da da procenu greaka pre i tokom faze testiranja kao i u fazi distribucije, proceni pouzdanost. Procena pouzdanosti softvera je funkcija alatke Risk Management eXpert-a koja se bavi procenom i kalibracijom pouzdanosti softvera tokom nekoliko faza ivotnog ciklusa projekta.

Slika 2.1.1.1: LOGO Risk Management komponente.


22

Procena pouzdanosti softvera omoguava vrstu osnovu za izvoenje znaajnih studija na poetku projekta. Takoe omoguava predvianje verovatnoe otkaza softvera pre testiranja ili u bilo kom trenutku u toku testiranja. Procena pouzdanosti softvera (Software Reliability Estimation) slui za fino podeavanje i kalibraciju u cilju da odreeni projekat bude konzistentan i pouzdan.

Slika 2.1.1.1: Ilustracija koja pokazuje kako funkcionie Risk Management eXpert komponenta..


23

3 OPIS POSTOJEIH ARHITEKTURA 3.1 Dvolsojna arhitektura

Dvoslojna arhitektura sastoji se od 3 komponente distribuirane u dva sloja klijentskom i serverskom. Te tri komponente su:

Korisniki interfejs sesije, unos teksta, dijaloki prozori, prikaz na ekranu Upravljanje procesima (process managment) generisanje, izvoenje i nadgledanje procesa i neophodnih resursa

Slika: Prikaz dvoslojne arhitekture

Upravljanje podacima (database managment) servisi vezani za deljenje podataka i datoteka. Jedna od osnovnih karakteristika klijent/server sistema je distribuirana obrada podataka logika aplikacije je podeljena izmeu klijenta i servera tako da obezbedi optimalno korienje resursa.

Na primer, prezentacija podataka i provera ulaznih podataka su sastavni deo klijent-aplikacije, dok se rukovanje podacima, u smislu njihovog fizikog smetaja i kontrole pristupa, vri na serveru.

Neke od prednosti ovakvog modela obrade podataka su:

centralizovano upravljanje resursima sistema i jednostavnije obezbeivanje sigurnosti podataka.

Osnovni problem nedostatak skalabilnosti. Pod skalabilnou se podrazumeva osobina sistema da omogui efikasan rad

velikom broju korisnika, i da dalje poveavanje broja korisnika ne izaziva drastian pad performansi sistema.


24

3.2 Karakteristike troslojne arhitekture

Troslojna arhitektura je specijalni sluaj klijent/server arhitekture gde je funkcionalnost sistema podeljena na tri logike particije: servisi aplikacije, poslovni servisi i servisi podataka.

Slika: prikaz troslojne arhitekture

Servisi aplikacija se obino bave GUI prezentacijama

Servisi podataka su obino implementirani nekom od tehnologija baza podataka i opsluuju hiljade korisnika

Poslovne servise obino koristi veina korisnika, te su locirani na specijalizovanim serverima


25

Slika: Prikaz servis aplikacije, poslovnog servisa i servisa podataka

U troslojnom generikom modelu jasno se odvaja upravljanje podacima, aplikaciona logika i korisniki interfejs.

Prilagodljiva je brzim promenema, kako u korisnikom (poslovnom), tako i u implementacionom (tehnolokom) okruenju.

Omoguava transparentno povezivanje korisnikih aplikacija sa razliitim izvorima podaka na raznim platformama, a ne samo sa jednim serverom baze podataka.

Sutinu ove arhitekture odraava srednji sloj koji se razliito naziva: aplikacioni server, transakcioni server, server komponenti, server poslovnih pravila, ime se posebno istie neka funkcionalnost ovoga sloja.

Troslojna arhitektura je generika za vieslojne arhitekture koje postaju opteprihvaeni standard. Koncept distribuiranih softverskih komponenti (CORBA, DCOM, Java Beans) omoguava da se i komponente srednjeg sloja distribuiraju.U njima se razliite funkcije srednjeg sloja (middleware) raslojavaju, da bi se preko veeg broja slojeva, odnosno veeg stepena indirekcije, omoguila vea modularnost, heterogenost i elastinost sistema.


26

3.3 Servisno orijentisana arhitektura (SOA)

SOA predstavlja nain projektovanja IT sistema koji omoguava razliitim aplikacijama na razliitim nivoima da razmenjuju podatke bez obzira na kom se operativnom sistemu izvravaju i na kom su programskom jeziku napisane.

Slika: SOA arhitektura

SOA predstavlja model u kome se funkcionalnosti dekomponuju na razliite jedinice (servise), koji se mogu nezavisno distribuirati putem mree i kombinovati sa drugim servisima radi stvaranja kompleksnijih biznis aplikacija.

Servisi komuniciraju izmedju sebe putem razmene podataka ili putem koordinacije aktivnosti izmedju dva ili vie servisa.

Slika: Prikaz SOA Arhitekture


27

Prednosti SOA arhitekture:

Bra i jeftinija izgradnja novih usluga ili aplikacija

Bolji kvalitet aplikacija

Manji trokovi odravanja sistema

Cilj SOA arhitekture, IT sistem uciniti:

Fleksibilnijim nezavisan od tehnologije Skalabilnijim resursi potrebni za uvodjenje novih usluga/sistema ne zavisi

od kompleksnosti sisema. Robustnijim otporan na otkaze pojedinih delova sistema

Osnovni koncept ove arhitekture tj. IS baziranog na SOA je da omogui maksimalnu:

fleksibilnost proirivost.

Fleksibilnost arhitekture je sposobnosti da se itava arhitektura ili njeni elementi prilagoavaju promenama odnosno novim okolnostima. Fleksibilnost omoguava primenu u drugim projektima i bliska je ponovnoj upotrebljivosti.

Slika: Prikaz fleksibilnijegsIstema


28

Slika: Primer arhitekture gde je razdvojena poslovna od raunarske logike

Neke od definicija SOA arhitekture:

SOA je arhitektura IS koja omoguava prvenstveno korienje labavo povezanih servisa i dobijanje visoke fleksibilnosti i proirivosti na tehnoloki nezavisan nain.

SOA je oblik organizacije IS koju karakterie ponuda i korienje njegovih distribuiranih funkcija predstavljenih servisima.

Slika: Prikaz skalabilnijeg sistema


29

Implementiranjem SOA arhitekture dobijamo:

Brze uvodjenje novih usluga I korisnika Nove mogucnosti za upotrebu informacija iz sistema, preko vec postojecih

servisa Transparentnije poslovanje Informacije dostupne svima, u zavisnosti od toga kakva im je uloga u sistemu Jednostavnije odrzavanje I unapredjenje sistema Komunika cija sa klijentima/korisnicima usluga preko razlicitih kanala,

koriscenjem vec postojecih sistema Servisi dostupni za koriscenje I poslovnim (non-IT) korisnicima, preko BPM

alata

3.4 CORBA

Common Object Request Broker Architecture (CORBA) je standard definisan od strane Object Management Group (OMG) koji omoguava meusobnu komunikaciju aplikativnim komponentama pisanim razliitim programskim jezicima, a koje se izvravaju unutar razliitih procesa bilo na istom ili razliitim raunarima.

Slika: Opsta arhitektura CORBA-e

CORBA umotava programski kod u paket koji sadri informacije o tome to je sadraj paketa i kako se isti moe izvriti.CORBA koristi IDL (Interface Definition Language) za specifikaciju suelja koje e objekti predstaviti vanjskom svijetu. CORBA specificira nain mapiranja IDL-a u odgovarajui programski jezik.npr. C, C++, Java


30

CORBA Primena

CORBA je okruenje koje omoguava razvoj i izvravanje distribuiranih aplikacija, a to moe biti potrebno iz sledeih razloga:

Podaci koji se koriste su distribuirani - podatke ne smemo ili ne moemo imati na svim lokacijama gdje su oni potrebni

Potrebni raunalni resursi su distribuirani - potrebno je iskoristiti procesorsku snagu veeg broja raunala kako bi se raspodijelio teret obrade podataka

Korisnici aplikacije su distribuirani - razliiti korisnici koriste razliite dijelove aplikacije ili meusobno komuniciraju pomou aplikacije

Implementacije

Kao to je ve ranije re eno, CORBA je samo papir, tj.specifikacija na vie od hiljadu stranica teksta. Ova specifikacija je bila ispred svog vremena kada je izala (po etkom devedesetih godina dvadesetog veka) i softverska zajednica je sa entuzijazmom prihvatila ovaj novi standard. Krenulo se u pisanje ve eg broja implementacija. Implementacija je fizi ka realizacija CORBA specifikacije koja radi na jednom ili vie operativnih sistema i/ili na odre enoj hardverskoj platformi. Poznatije CORBA specifikacije su prikazane u tabeli 2.

ime CORBA verzija licenca OmniORB 2.6 LGPL TAO 3.0 GPL ORBit2 2.4 LGPL MICO 3.0 LGPL IIOP.NET 2.3 LGPL Visibroker 2.6 Komrcijalna Orbacus 2.6 komercijalna Tabela 1: CORBA implementacije

Tabela 1.sadri implementacije sa otvorenim kodom (sa razli itim licencama) i dve komercijalne implementacije. Na katedri za Automatiku i upravljanje sistemima koriste se omniORB i TAO. IIOP.NET je moda najinteresantniji projekat iz tabele, jer je pisan u za .NET framework, bazira se na .NET remoting-u i omogu ava komunikaciju izme u .NET, CORBA i J2EE objekata.


31

Slika 1: . Opta arhitektura CORBA-e

Prikazana slika je relativno loa, ali se najvaniji elementi lepo vide:

Object impl server. Preciznije: serverski objekat

Client klijent, koristi usluge servera

Object Request Broker sloj koji sedi na operativnom sistemu i sakriva njegovu sloenost

ORB Interface API preko koga i klijent i server pristupaju ORB -u

IDL Skeleton kod dobijen prevo enjem IDL-a. Mapiranje tipova (tzv. marshaling ) i bazne klase koje serverski objekat treba da implementira

IDL Stubs poput IDL Skeleton-a, slui za mapiranje tipova

Object adapter pove ava portabilnost serverske implementacije jer omoguave pisanje koda servera koji je nezavisan od kori ene CORBA implementacije

Postoje dve verzije object adapter -a:

BOA ( Basic Object Adapter ) i

POA ( Portable Object Adapter )

POA je novijeg datuma i prakti no razdvaja implementaciju serverskog objekta od objekta koji obra uje zahteve ( servant )

Od svih objekata sa slike 1., programer koji radi na razvoju CORBA aplikacije pie samo klijenta i implementaciju serverskog objekta.


32

Slika: Prikaz veze izmedju CORBA servisa sa aplikacionim objektom

3.5 CORBA -Distribuirani sistemi

Razvoj distribuiranih aplikacija namee neke probleme (izazove) s kojima se tokom razvoja nedistribuiranih (centralizovanih) aplikacija ne susreemo.

Centralizovane aplikacije Distribuirane aplikacije Komunikacija Brza spora Greske Svi objekti su ugrozeni Objekti su pojedinacno ugrozeni Raspolozivost Mala Velika Paralelni pristup Uz pomoc niti moguc sigurnost Jednostavna implementacija Kompleksna implementacija Tabela 2: Centralizovane i Distribuirane aplikacije

Komunikacija

Komunikacija u distribuiranim sustavima je znatno sporija nego u centraliziranim sustavima, stoga je potrebno izbjegavati distribuirana rjeenja kada objekti imaju intenzivnu meusobnu interakciju

Greke

Kada se svi objekti aplikacije nalaze unutar centraliziranog sastava oni bivaju zajedniki pogoeni grekama, tj.kada proces u kome se izvode prestane funkcionirati tada i svi objekti tog procesa prestaju s funkcijom. U distribuiranim sustavima je mogue izolirati procese i objekte u njima, a mogue je i realizirati sustav u kome aktivni procesi mogu preuzeti posao onih procesa koji trenutno nisu aktivni iz bilo kojeg razloga


33

Raspoloivost

Raspoloivost centraliziranih sustava je openito govorei manja od raspoloivosti distribuiranih sustava. Ispadom jedne komponente centraliziranog sustava esto itav sustav postaje neupotrebljiv. Distribuirani sustavi pruaju mogunosti paralelnog izvravanja zadataka i preuzimanja funkcije onih komponenti koje su na udaljenom sustavu izvan funkcije

Paralelni pristup

U cenatraliziranim sustavima je est sluaj da se aplikativna logika izvrava unutar jedne niti izvoenja, a elimo li podrati paralelan pristup susatvu od strane vie istovremenih korisnika moramo uzeti u obzir kompleksnost realizacije vienitnog izvoenja aplikacije. Kod distruibuiranih sustava nuno postoji vie niti izvoenja, no one se mogu izvoditi unutar zasebnih procesa.

sinhronizacija niti

Sigurnost

Kada se svi objekti aplikacije fiziki nalaze na jednom mjestu i unutar istog procesa tada ne postoji problem meusobne autorizacije objekata. Kod distribuiranih sustava taj problem postoji jer objekti iz razliitih okruenja (procesa) meusobno pokuavaju uspostaviti komunikaciju te ih je potrebno meusobno identificirati.

3.6 CORBA Arhitektura

Osnovna paradigma CORBA-e se moe definirati kao zahtijev za uslugu (servis) od strane distribuiranog objekta)

Usluge (servisi) koje objekti pruaju su raspoloivi pomou suelja, a suelje je definirano IDL jezikom

Distribuirani objekti se mogu identificirati pomou objektnih referenci, a iste se takoer definiraju IDL jezikom

ORB (Object Request Broker) je distribuirana usluga koja je zaduena za:

o Pronalaenje distribuiranog objekta o Proslijeivanje zahtijeva od strane klijenta prema distribuiranom objektu o Proslijeivanje rezultata izvravanja prema klijentu


34

ORB ini lokaciju distribuiranog objekta transparentnom za klijenta, tj. bez obzira na to gdje se on nalazi klijent mu pristupa na isti nain

ORB implementira neovisnost programskog jezika, tj. programski jezici u kojima su relaizirani klijent i distribuirani objekt ne moraju biti isti.

Stub

Na strani klijenta, CORBA aplikacija definira referencu na distribuirani objekt, a ona u sebi ima tzv. stubmetodu tj. metodu koja se poziva na distribuiranom objektu. Stub metoda inicira mehanizme povezivanja na ORB-u kojima se zahtijev proslijeuje prema distribuiranom objektu

Skeleton

Na strani distribuiranog objekta postoji skeleton, tj.metoda koja prevodi upit i parametra pristigle od strane klijenta te poziva izvravanje metode na distribuiranom objektu

CORBA Razvoj aplikacije

1. Definicija suelja prema udaljenom (distribuiranom) objektu 2. Prevoenje suelja 3. Implementacija distribuiranog objekta (server-a) 4. Implementacija klijenta 5. Pokretanje aplikacije

Definicija sistema

Sluaj prema udaljenom (distribuiranom) objektu se definise IDL jezikom, te se koricenjem idl alata prevodi u Java jezik

Hello.idl

module HelloApp

{

interface Hello

{

string sayHello();

oneway void shutdown();

};

};


35

Prevoenje IDL sistema:

Alat idlmoe kreirati i klijentsku i serversku stranu CORBA aplikacije idl fall Hello.idl

Rezultat:

HelloPOA.java Server skeleton, osnovna CORBA funkcionalnost server-a

_HelloStub.java Klijent stub, osnovna CORBA funkcionalnost klijenta

HelloHolder.java Pomona funkcionalnost

HelloHelper.java Pomona funkcionalnost

Hello.java Java verzija IDL suelja

HelloOperations.java Java interface koji definira metode sayHello() ishutdown()

3.7 Remote Method Invocation (RMI)

injenica je da softverski sistemi postaju sve sloeniji, a da se softverski inenjeri suoavaju sa sve teim zahtevima i izazovima. Jedan od veih izazova je programiranje distribuiranih softverskih sistema tj. softverskih sistema ije se komponente izvravaju na udaljenim raunarima. Podruje istraivanja master rada je razvoj i implementacija distribuiranih informacionih sistema (IS) korienjem Java tehnologija. U okviru podruja istraivanja konkretan problem koji se istrauje je komparativna analiza RMI i EJB 3.0 tehnologija. Analizom problema istraivanja dobijamo osnovne koncepte i asocijacije izmeu koncepata koji e biti detaljno razmatrani u radu (slika 1).


36

Slika 1. Konceptualni dijagram RMI arhitekture

Komparativna analiza EJB 3.0 i RMI tehnologija e se vriti na osnovu dinamike analize1 RMI i EJB 3.0 aplikacija. RMI aplikacija se sastoji od klijentskog i serverskog programa. U osnovi RMI programa se nalazi RMI/JRMP tehnologija (JRMP je standardni protokol pomou koga komuniciraju udaljeni objekti). Klijentski program poziva metode objekata serverskog programa preko servisa imenovanja(Naming Service).

EJB aplikacija se izvrava u okviru EJB kontejnera i realizovana je EJB tehnologijom koja obuhvata Session beans(Stateless i Stateful), Message Driven Beans(MDB), i Java Persistence API2 tehnologije. EJB aplikacija se sastoji od aplikacionog klijenta i EJB modula. Aplikacioni klijent realizuje korisniki interfejs i izvrava se u okviru aplikacionog kontejnera dok EJB modul realizuje poslovnu logiku aplikacije i izvrava se u okviru EJB kontejnera. Prilikom rasporeivanja(deploy) EJB modula kontejner registruje klase za pristup EJB komponentama(Stub) u servisu preslikavanja. Aplikacioni klijent preuzima stub klasu pomou JNDI programerskog interfejsa i poziva metode bean-a. Aplikacioni klijent koristi Java Message Servis(JMS) tehnologiju za pristup MDB-u. Motiv za prijavu ovog rada je interesovanje za Java tehnologiju i razvoj distribuiranih informacionih sistema. Pitanja koja su bila motivacija za izbor teme komparativna analiza RMI i EJB 3.0 tehnologija su :

1) Koja tehnologija omoguava bolje performanse distribuirane aplikacije?

2) Koja tehnologija omoguava bolje upravljanje memorijom?

3) Koliki je uticaj operativnog sistema(Linux, Windows) na performanse distribuirane aplikacije?


37

4) Koliki je uticaj propusnog opsega mree na performanse distribuirane aplikacije?

Istraivanje ima za cilj da olaka izbor tehnologije za razvoj distribuirane aplikacije na taj nain to ukazuje na parametre koji imaju uticaja na performanse krajnjih softverskih reenja. Oekivani doprinos master rada ogleda se u realizaciji postavljenih ciljeva:

1) Prikaz udaljenog pozivanja metoda (RMI) i korienje te tehnologije u realizaciji klijent-server arhitekture

2) Prikaz EJB 3.0 tehnologije i njene primene u razvoju sloenih aplikacija

3) Dinamika analiza RMI i EJB 3.0 tehnologija

4) Komparativna analiza dobijenih rezultata dinamike analize

U prvom delu rada je objanjen je koncept udaljenog pozivanja metoda, prikazane su tehnologije koje su u osnovi udaljenog pozivanja metoda, i navedeno je uputstvo za programiranje aplikacija koje su zasnovane na RMI tehnologiji. Nakon toga je prikazana arhitektura RMI tehnologije i tom smislu je opisan svaki od tri sloja RMI arhitekture : Stub/Skeletons, sloj udaljene reference i transportni sloj. U drugom delu rada je prikazana Java Enterprise Edition specifikacija za razvoj sloenih(Enterprise) aplikacija i EJB 3.0 tehnologija koja je sastavni deo JEE specifikacije i namenjana je za programiranje poslovne logike sloenih aplikacija. Nakon toga su prikazani Stateful i Message Driven Beans koji se koriste za modeliranje poslovnih procesa poslovnog sistema kao i programerski interfejs koji omoguava perzistentnost Java objekata(Java Persistence API).

U treem delu rada je prikazan razvoj softverskog sistema korienjem RMI i EJB 3.0 tehnologija. Metoda koja je koriena u razvoju je zasnovana na Larmanovoj metodi razvoja softverskih sistema, po kojoj razlikujemo sledee faze u razvoju softverskih sistema[Larman] :

1. Prikupljanje zahteva

2. Analiza

3. Projektovanje

4. Implementacija

5. Testiranje.

Faze prikupljanja zahteva i analize su u potpunosti preuzete od Larmanove metode, dok je faza projektovanja prilagoena tronivojskoj arhitekturi[Vlaji 1]. Razvoj softverskog sistema prati studija sluaja Evidencija radnih naloga.

U etvrtom delu rada prikazana je komparativna analiza RMI i EJB 3.0 tehnologija. Tehnologije e se komparativno analizirati na osnovu monitoringa3 studije sluaja i vremena izvrenja udaljenih metoda. Na slici 2.je prikazan dijagram aktivnosti (engl. Unified Modeling Language - UML4 activity diagram) koji grafiki opisuje organizaciju istraivanja ovog rada.


38

Slika 2. Organizacija istraivanja

3.7.1 RMI osnove U osnovi RMI tehnologije su ulazno-izlazni tokovi podataka(streams), serijalizacija objekata i soketi[RMI 2].

3.7.2 Ulazno-izlazni tokovi podataka Tok je ureen niz bajtova. Java program koristi ulazni tok (Input Stream) za itanje bajtova podataka iz nekog izvora (tastatura,datoteka,mrea i dr.), dok izlazni tok (Output Stream) koristi za pisanje bajtova podataka iz programa u navedeno odredite(ekran, datoteka, mrea i dr.). Apstraktne klase iz kojih se izvode navedeni tokovi su java.io.InputStream i java.io.OutputStream[Java API]. InputStream je apstraktna klasa koja reprezentuje izvor podataka, i sadri metode koje imaju tri najznaajnije uloge: itanje podataka iz nekog izvora (tastatura,datoteka,mrea i dr.), kretanje kroz tok podataka, oslobaanje resursa operativnog sistema koje je zauzeo ulazni tok. itanje podataka omoguava metoda read klase InputStream:


39

read() - vraa sledei slobodan bajt u toku podataka.

read(byte[] niz) ita niz bajtova iz nekog ulaznog toka i upisuje ih u niz

Kretanje kroz tok podataka omoguavaju sledee metode klase InputStream:

available() vraa broj bajtova dostupnih za itanje

skip(long brojBajtova)- preskae brojBajtova bajtova

mark(int brojBajtova)- obeleavanje pozicije u toku toku

Oslobaanje resursa operativnog sistema omoguava sledea metoda klase InputStream:

close() oslobaanje resursa operativnog sistema koje je zauzeo ulazni tok.

OutputStream je apstraktna klasa koja reprezentuje odredite podataka. OutputStream sadri metode namanjene pisanju podataka u navedeno odredite(ekran, datoteka, mrea i dr.), oslobaanju resursa operativnog sistema koje je zauzeo izlazni tok. Pisanje podataka omoguava metoda write klase OutputStream :

write(byte[] buffer) upisuje niz bajtova u neki od izlaznih tokova

Upravljanje resursima operativnog sistema omoguavaju sledee metode klase OutputStream:

flush() transportuje podatake iz bafera izlaznog toka u izlazno odredite

close() poziva se kada klijent zavri sa itanjem toka i eli da oslobodi resurse operativnog sistema koje je zauzeo izlazni tok. Sve klase koje reprezentuju ulazno/izlazne tokove bajtova nasleuju InputStream/Outputstream klase i prikazane su na slici 3.


40

Slika 3. Klase koje reprezentuju ulazno/izlazne tokove bajtova

Klasa System sadri statine atribute5 koji se odnose na tokove. To su out, i err koji su tipa PrintStream i in koji je tipa InputStream. Pomenutim objektima se moe pristupiti iz bilo kog dela programa preko klase System. Atribut System.in se odnosi na standardni ulazni tok, koji je podrazumevano tastatura. Atribut System.out se odnosi na standardni izlazni tok, koji je podrazumevano ekran, dok se atribut System.err odnosi na standardni tok za greke koji je takoe ekran. Klase Reader i Writer su apstraktne klase sline pomenutim klasama InputStream i OutputStream ali su orijentisane prema karakteru za razliku od pomenutih koje su orijentisane prema bajtu. Time su podrani npr. Unicode, UTF-8 i drugi formati podataka koji svaki karakter predstavljaju sa dva bajta. Metode klase Reader i Writer su analogne metodama klasa InputStream i OutputStream sa razlikom to npr. metoda read klase Reader vraa celobrojnu vrednost u rasponu od 0-65535, dok metoda read klase InputStream vraa broj u intervalu od 0-255.


41

Slika 4. Klase koje reprezentuju ulazno/izlazne tokove karakter

Svi tokovi u okviru biblioteke tokova se mogu podeliti na primitivne i posrednike. Primitivni tokovi omoguavaju prenos podataka iz izvora(input) odnosno odredita(output) u Java programski jezik. Primeri primitivnih tokova su InputStream, OutpuStream, Reader, Writter i dr. Posredniki tokovi se koriste kao omotai (wrap) primitivnih tokova i omoguavaju im dodatne funkcionalnosti npr.

BufferedInputStream buffer= new BufferedInputStream(inputStream);

U ovom konkretnom primeru smo ulazni tok proirili BufferedInputStream klasom i omoguili da se podaci iz toka smetaju u privremenu memoriju(buffer) iz koje kasnije preuzimamo sve podatke iz ulaznog toka. Slojevitost tokova podrazumeva da se jedan posredniki tok moe obuhvatiti drugim i na taj nain dodati nove mogunosti postojeeg posrednikog toka.

3.8 Serijalizacija objekata

Serijalizacija je proces kojim se konvertuje stanje objekta u niz bajtova. RMI koristi serijalizaciju da prenese stanje objekta izmeu dve virtuelne maine, bilo kao argumente prilikom poziva udaljenih metoda ili kao povratne vrednosti izvrenih udaljenih metoda. Serijalizacija objekata se vri kreiranjem objekta6 klase ObjectOutputStream i pozivom writeObject() metode. Uitavanje serializovanog objekta (deserijalizacija) omoguava readObject() metoda klase ObjectInputStream. Pomou serijalizacije veza izmeu dva ili vie objekta, koja je ostvarena referencama u toku izvrenja programa biva snimljena u navedeno odredite(npr. datoteka) tj. deserijalizacijom se veze izmeu njih obnavljaju. Da bi omoguili serijalizaciju objekata klase, moramo ispuniti etiri uslova :

1. Klasa mora implementirati Serializable interfejs,

2. Omoguiti da svi atributi klase budu serijalizovani,

3. Omoguiti da nadreena klasa bude serijalizovana,

4. Preklopiti metod equals() i hashCode() (nije obavezno)


42

Samo objekti koji mogu biti serijalizovani se mogu koristiti kao ulazni/izlazni parametri metoda koje se udaljeno pozivaju pomou RMI tehnologije.

3.8.1 Soketi Soket je apstrakcija za komunikacioni kanal koji se uspostavlja izmeu dva programa koji se izvravaju kao odvojeni procesi. Java realizuje sokete koristei paket java.net, pri emu su dve osnovne klase za kreiranje soketa java.net.Socket i java.net.ServerSocket[Java API]. Realizacija prenosa podataka izmeu udaljenih raunara podrazumeva postojanje pojavljivanja klase Socket na klijentskoj i serverskoj strani. Pomenuta klasa omoguava etiri osnovne soket operacije:

1. Povezivanje(connect) na udaljeni raunar

2. Slanje podataka

3. Prijem podataka

4. Zatvaranje konekcije

Kreiranje pojavljivanja klase Soket na serverskoj strani podrazumeva izvravanje sledee dve naredbe:

1. Kreiranje pojavljivanja klase ServerSocket, pri emu se prosleuje port sa kojim se server soket povezuje7. ServerSocket ss = new ServerSocket(8189);

2. Pozivanje accept() metode klase ServerSocket: public Socket accept( ) throws IOException

Metoda accept() blokira izvrenje programa u smislu da je izvrenje programskih instrukcija koje slede poziv accept() metode mogu jedino ako se klijent povee sa serverom. Povratna vrednost pozvane metode je pojavljivanje klase Socket koja se koristi za komunikaciju sa jednim povezanim klijentom.

Povezivanje(connect) klijenta sa serverskim programom omoguava klasa Socket koja se kreira pozivom sledeeg konstruktora :

public Socket(String host, int port)

Promenjiva host je string koji predstavlja simboliku ili IP adresu raunara na kome se nalazi serverski soket. Primer za simboliku adresu je www.finansijebgd.org, dok IP adresa 32-bitni broj koji jedinstveno identifikuje raunar kome su poslati podaci, npr. 132.163.135.130. Port slui za identifikaciju programa (procesa) koji e da prihvati podatke na klijentskom ili serverskom raunaru sa navedenom adresom host.

Slanje i prijem podataka preko soketa omoguavaju pojavljivanja klasa InputStram i OutputStram koje se dobijaju kao povratne vrednosti sledee dve metode klase Socket :

public InputStream getInputStream() throws IOException

public OutputStream getOutputStream() throws IOException

Zatvaranje soketa se realizuje metodom close() klase Socket :


43

public synchronized void close() throws IOException

3.9 RMI programiranje

Tehnologija poziva udaljenih metoda(RMI) omoguava da objekat klijentskog programa poziva metode objekta serverskog programa koji se izvrava kao odvojen proces na istom ili nekom drugom raunaru u mrei. RMI tehnologija smanjuje sloenost programiranja distribuiranih aplikacija u odnosu na sokete obzirom da korisnik ne programira detalje interakcije izmeu dva udaljena raunara. Osnova za razvoj RMI-a je tehnologija udaljenog pozivanje procedura(Remote Procedures Call-RPC)8 koja se pojavila sedamdesetih godina prolog veka.

3.9.1 Komunikacija klijentskog i serverskog objekta

Osnovni koncepti RMI tehnologije su :

1. Klijent i server program Java aplikacije koju pie programer(korisnik RMI tehnologije)

2. Stub i skeletons klase klase koje imaju ulogu posrednika preko kojih klijent poziva metode serverskog objekta.

3. RMI izvrno okruenje omoguava transport podataka koristei sokete.

4. RMI registrator(RMI registry) servis preslikavanja(naming service)

Koncepti RMI tehnologije su prikazani na slici 5.

slika 5. Komunikacija klijentskog i serverskog objekta


44

Komunikacija izmeu klijentkog i serverskog programa se realizuje u vie koraka:

1. Startuje se serverski program koji povezuje stub klasu sa rmi registratorom. Stub klasa se automatski generie na serveru, i sadri neophodne informacije za poziv metoda serverskog objekta.

2. Klijentski program prihvata pojavljivanje stub klase od RMI registratora.

3. Klijent poziva metodu serverskog objekta koristei Stub klasu. Stub klasa prihvata zahtev za izvravanje metode serverskog objekta, i prosleuje ga RMI izvrnom okruenju koji ga transformie i prenosi kroz mreu do servera. Informacioni blok koji se transportuje kroz mreu se sastoji od [Vlaji 2] :

Identifikatora serverskog objekta Opisa metode koja se poziva Kodiranih(serijalizovanih) ulaznih parametara metode. Proces kodiranja

parametara se naziva parameter marshaling, i omoguava prenos ulaznih parametara motode kroz mreu.

4. RMI izvrno okruenje servera prihvata informacioni blok koji je poslao klijent i prosleuje ga Skeletons klasi koja dekodira prihvaeni blok i poziva metodu kojoj alje odgovarajue ulazne parametre klijenta. Nakon toga, prihvata izlazne vrednosti pozvane metode, kodira ih, i posredstvom rmi izvrnog okruenja ih prosleuje klijentu .

5. Stub klasa vri dekodiranje podataka koje je dobila od servera i prosleuje ih klijentskom program.

3.9.2 Realizacija RMI aplikacije

Realizacija RMI aplikacije podrazumeva sledee korake :

Kreiranje serverskog programa Kreiranje klijentskog programa Kompajliranje i pokretanje programa

3.10 Kreiranje serverskog programa

Serverski program u kontekstu RMI tehnologije sadri[Vlajic 2] :

1. Interfejs koji definie skup metoda koje se udaljeno pozivaju

2. Klasu koja implementira metode navedenog interfejsa

3. Klasu koja kreira serverske objekte i registruje kreirane objekte u rmi registratoru(engl. RMI Registry)

Interfejs serverskog programa se naziva udaljeni interfejs i ima sledee karakteristike:

Nasleuje interfejs java.rmi.Remote


45

Svaka metoda interfejsa baca java.rmi.RemoteException izuzetak npr.

public interface KontrolerAL extends Remote{

public void izmeni(ArtikalDTO dto)throws

RemoteException,ArtikalNePostojiException;

U nastavku navodimo primer klase serverskog programa koja implementira metode udaljenog interfejsa :

public class KontrolerALImpl implements KontrolerAL{

public int izmeni(ArtikalDTO dto)throws

RemoteException,ArtikalNePostojiException{

Artikal artikal = new Artikal();

artikal.postaviArtikal(to); I

zmeniArtikal.izvrsi(artikal);

}

Klasa koja kreira serverske objekte i registruje kreirane objekte u rmi registratoru izvrava sledee naredbe :

KontrolerAL obj = new KontrolerALImpl();

KontrolerAL stub = (KontrolerAL) UnicastRemoteObject.exportObject(obj, 0); LocateRegistry.getRegistry().bind("Racun", stub);

Statina metoda UnicastRemoteObject.exportObject(obj, 0) automatski kreira serverski soket i prihvata pozive klijenta ka metodama udaljenog objekta. Kao ulazni argument se pored udaljenog objekta navodi i port na kome se oekuju budui pozivi metoda. Kao rezultat izvrenja metode dobija se Stub klasa za prosleeni objekat. Stub klasa predstavlja referencu udaljenog objekta koja se prenosi na klijentski raunar i pomou koje klijenti pozivaju udaljene metode. Klijent prihvata referencu pomou servisa preslikavanja(naming sevice) koji se naziva rmi registrator (engl. RMI registry). Povezivanje serverskog objekta sa rmi registratorom se obavlja pozivom bind(String ime, Remote obj) metode java.rmi.Naming klase. Ulazni argumenti metode su udaljeni objekat i njegovo simboliko ime.Klijenti koriste simboliko ime da bi jedinstveno identifikovali udaljeni objekat u rmi registratoru. U nastavku je dat prikaz serverske klase koja kreira serverske objekte i registruje kreirane objekte u rmi registratoru :

public class KontrolerALServer {

public static void main(String[] args){

try {

KontrolerAL obj = new KontrolerALImpl();


46

KontrolerAL stub = (KontrolerAL) UnicastRemoteObject.exportObject(obj, 0);

Registry registry = LocateRegistry.getRegistry();

registry.bind("Stub", stub);

System.out.println("Server spreman...");

} catch (Exception e) {

System.err.println("Server exception: " + e.toString());

}

}

3.11 Pokretanje RMI aplikacije

Pokretanje serverskog programa podrazumeva:

1. pokretanje rmi registratora - registrator objekata se pokree pozivom datoteke rmiregistry.exe koja se sastavni deo JDK-a.

2. podeavanje sledeih svojstava(properties) za Java virtualne maine koje izvravaju serverski i klijentski program :

a) java.rmi.server.codebase (baza koda)

b) java.java.security.manager (kreiranje menadera zatite)

c) java.security.policy (definisanje dozvola za menader zatite) Svojstva virtuelne maine se postavljaju prilikom pokretanja programa u komandnoj liniji na sledei nain :

java Dsvojstvo=vrednost imePrograma

Postavljanjem svojstva java.rmi.server.codebase omogueno je definisanje lokacija na mrei gde se nalaze class datoteke serverskog programa npr. -Djava.rmi.server.codebase = http://localhost/bdragan.Prilikom registrovanja serverskog objekta u rmi registratoru, navedena baza koda se prosleuje kao anotacija(metapodatak) reference serverskog objekta(Stub klase). Kada klijent zatrai Stub klasu sa navedenim logikim imenom, rmi registrator vraa klijentu pojavljivanje stub klase i pomenutu anotaciju. Virtuelna maina koja izvrava klijentski program prvo pokuava da uita class datoteku Stub-a lokalno tj.pretraujui poznate putanje pretrage klasa(Classpath). Ako se class datoteka stub-a ne moe uitati lokalno onda se pretrauje baza koda koja je preuzeta od rmi registratora i klasa se dinamiki uitava sa lokacije koja je navedena u bazi koda.

Ukoliko se prilikom poziva udaljene metode prosledi ulazni argument referentnog tipa za koji u poznatim putanjama pretrage klasa(Classpath) servera ne postoji class datoteka, baza koda koja je definisana prilikom pokretanja klijentskog programa se koristi da bi se dinamiki preuzela potrebna class datoteka. Analogno tome klijentski program preuzima bazu koda koja je definasana prilikom pokretanja servera za


47

povratne vrednosti udaljenih metoda koje ne postoje u putanjama pretrage klasa klijenta.

Svojstvo java.security.manager kreira menader zatite za pokrenutu aplikaciju. Menader zatite kontrolie da li kod koji izvrava virtuelna maina ima pristup pojedinim resursima operativnog sistema na lokalnom raunaru. Dozvole za menader zatite se postavljaju pomou datoteke za prodeavanje dozvola(policy file). Datoteka za prodeavanje dozvola definie koje dozvole su odobrene za kod koji se poziva sa odreene lokacije. Primer datoteke za prodeavanje dozvola koja dozvoljava kodu itanje svojstava operativnog sistema ima sledei sadraj :

grant

{

permission java.util.PropertyPermission "java.vendor", "read";

};

Povezivanje programa sa datotekom za podeavanje dozvola izvravamo na taj nain to u argumentu prilikom pozivanja programa postavimo java.security.policy svojstvo. npr. java -Djava.security.policy=policy.dat i navede se putanja do fajla definie putanju polise koja se koristi.

3.12 RMI tehnologija

RMI implementacija se sastoji od tri sloja :

1. Osnovni/Kostur sloj (Stub/Skeletons)

2. Sloj udaljene reference(Remote reference)

3. Transportni sloj

Prilikom poziva udaljene metode od strane klijenta, poziv prolazi kroz osnovni sloj i ide u referentni sloj, koji obavlja proces pakovanja objekata i prosleuje iste preko transportnog sloja do servera. Transportni sloj na serveru prihvata poziv i prosleuje ga do referentnog nivoa, gde dolazi do raspakivanja argumenata i prosleivanja do kostur nivoa, a zatim do implementacije servera. Prilikom vraanja vrednosti udaljenog metoda prolazi se ista putanja.Postojanje tri sloja omoguava svakom sloju da bude nezavisno kontrolisan odnosno implementiran.

3.12.1 Aplikaciona logika RMI realizacije studije sluaja-Kontroler

Kontroler je udaljeni objekat koji je odgovoran da prihvati zahtev za izvrenje sistemske operacije od klijenta, transformie objekat za transfer podataka(TO) u domenski objekat i da prosledi domenski objekat do poslovne logike koja je odgovorna za izvrenje sistemske operacije.


48

public class KontrolerAL implements RemoteKontrolerAL {

public void storniraj(RadniNalogPKTO pk) throws OperationFailsException,

EntityNotFoundException, InvalidParameterException,RemoteException

{

RadniNalog radniNalog = new RadniNalog();//Kreiraj domenski objekat radniNalog.mergeRadniNalogPKTO(pk);//podesi klasu na osnovu vrednosti atributa

TO

StornirajRadniNalog.storno(radniNalog);//pozovi sistemsku operaciju poslovne logike

}

//ostale metode....


49

3.13 Aplikaciona logika RMI realizacije studije sluaja-Poslovna logika

Poslovna logika je opisana strukturom(domenskim klasama) i ponaanjem (sistemskim operacijama) softverskog sistema.

Klase strukture softverskog sistema su projektovane korienjem JPA programerskog interfejsa(API) na osnovu konceptualnih klasa koje su prikazane u fazi analize

Navodimo realizaciju klase Artikal:

@Entity

@Table(name = "\"Artikal\"")

public class Artikal implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@Column(name = "\"PKArtikla\"", nullable = false)

private String PKArtikla;

@Column(name = "\"Naziv\"")

private String naziv;

@Column(name = "\"Cena\"")

private Double cena;

public Artikal() {

}...

}

Sistemske operacije su klase koje opisuju ponaanje softverskog sistema. Za svaki od ugovora se projektuje konceptualno reenje sistemske operacije. Konceptualne realizacije su prikazane preko sekvencnih dijagrama.


50

Slika: Konaan izgled arhitekture RMI studije sluaja

3.14 Monitoring RMI realizacije studije sluaja

U nastavku prikazujemo rezultate monitoringa RMI realizacije studije sluaja Evidencija radnih naloga.

Slika: Upotreba dinamike memorije RMI realizacije studije sluaja


51

Slika: Broj aktivnih niti i uitanih klasa RMI realizacije studije sluaja

Analizom prikazanih dijagrama dolazimo do podataka da je zauzeto 5.117 megabajta dinamike(heap) memorije, a da je maksimalno korieno 3.044 megabajta dinamike memorije. Virtuelna maina je uitala 2595 klasa, pri emu je maksimalno pokrenuto 9 niti. Sakuplja smea je napravio 21 kolekciju smea, a procenat vremena izvrenja koji JVM troi na sakupljanje smea iznosi maksimalno 6.5% prilikom pokretanja aplikacije, dok najvei deo izvravanja aplikacije iznosi 0%.


52

4 Analiza i validacija postojeih konkurentskih reenja

Ovo poglavlje je zasigurno poznato, ukoliko ste itali na predhodni projekat, ali zapravo ovde emo predstaviti nekoliko konkurentskih reenja, sagledati nedostatke, vrline i mane istih, detaljno predstaviti oekivanja softvera, kao i baziranje Klijent Server arhitekture kroz prizmu zadatih reenja.

4.1 UTest

Test je kompanija koja je osnovana 2007 godine od strane Doron Reuvenia i Roy Solomona i bavi se apsolutno simulacijom i testiranjem

softvera. Sedite kompanije se nalazi u Soutburgu dok se njene filijale nalaze u nekoliko veih gradova u svetu. Kompanija je kreirala softver koji vri testiranje na jedan jako specifian nain.

U naem prethodnom projektu, takoe smo kao primer uzimali Utest, ali sa aspekta simulacije softvera. Zapravo Utest kompanija dosta podsea na PISA Poslovnu Simulacionu Arhitekturu, iz prostog razloga to poseduje dosta priblian koncept, ali ne prua dovoljno jasnih i decentnih reenja, kao to to ini PISA platforma. Utest u svom sastavu vri menadment rizika i to kroz svoja dva paketa:

Utest kompanija nam je omoguila testiranje i uzimanje kao primer njihovog softvera. Sam softver je ceo u klijent-server konceptu. Zato to se kompletno testiranje obavlja putem komunikacije izmeu klijenta i servera, online. Klijent koji poseduje svoju aplikaciju, prua sve svoje source fajlove Utest kompaniji, koja dalje vri proveru potrebna testiranja na odreenu vrstu rizika koji mogu nastati.

Security paket se zapravo bavi menadmentom rizika, kada je u pitanju bezbednost. Kako bezbednost u mrei (od spoljanjih upada i malverzacija) tako i bezbednost unutar samog softvera. Rizik od pucanja programa usled velikog optereenja je jako esta pojava, pa se izmeu ostalog i time mora baviti ovaj paket.

Testiranje upotrebljivosti softvera se bazira na simuliranju korisnika razliitih obrazovnih profila. Alati koji slue ovom paketu testiraju softver na taj nain to predstavljaju korisnika i vre sve aktivnosti koje bi vrio i korisnik i dovode do iskazivanja greki koje bi se pokazale i samom korisniku. Na ovaj nain umanjuju rizik od greaka koje mogu nastati korienjem samog softvera.


53

4.1.1 Security paket

Ovaj paket podrazumeva tim strunjaka i menadera rizika koji se bave testiranjem rizika, kada je u pitanju bezbednost. Upravljanje ovakvom vrstom rizika je jako kompleksan posao, ali nije i nemogu.

Na slici 4.1.1.1 moemo videti kako izgleda prozor pri samom logovanju korisnika na Utest aplikaciju. Automatski primeujemo i dnevne aktivnosti pri testiranju, moemo izvui iz baze podataka testiranje u zadnja 3, 4, ili 12 meseci. Moemo videti koliko se korisnika ulogovalo u zadnjim mesecima, kao i kakav je to efekat ostvarilo na izabrani softver. Na glavnom dijagramu moemo videti koliki je rizik od nastajanja odreenih problema, usled stat

dunp, kss, tim#1, oqt risk management expert ver 3.0

Documents