Univerzitet u Beogradu Fakultet organizacionih nauka, Beograd

Master rad
Komparativna analiza EJB 2.1 i EJB 3.0 tehnologija

Kandidat: Srdjan Krsmanovi 13/2007 Mentor: dr Sinia Vlaji, doc.

Beograd, Jul 2009. godine

Komisija koja je pregledala rad i odobrila odbranu:

Mentor: dr. Sinia Vlaji, docent

-----------------------------------------

lan: dr. Duan Starevi, redovni profesor

---------------------------------

lan: dr. Sinia Nekovi, docent -----------------------------------------

ii

Apstrakt:
U ovom radu e biti predstavljene dve verzije EJB tehnologije, EJB 2.1 i EJB 3.0, koje se koriste za razvoj sloenih aplikacija. Nakon prikaza tehnologija bie dat pregled ISO/IEC 9126 standarda za ocenjivanje kvaliteta softvera. Zatim e na osnovu studijskog primera biti izvrena ocena posmatranih tehnologija korienjem softverskih metrika zasnovanih na ISO/IEC 9126 standardu i softverskih profajlera. Softverske metrike e se koristiti za statiku analizu softvera, a softverski profajleri za dinamiku analizu softvera. Kljune rei: EJB 2.1, EJB 3.0, ISO/IEC 9126, softverske metrike

Abstract:
This paper will present two versions of EJB technology, EJB 2.1 and EJB 3.0, which are used for enterprise application development. Subsequent to technology presentation, the review of ISO/IEC 9126 standard will be given. In accordance with case study, mentioned technologies will be evaluated using software metrics based on ISO/IEC 9126 standard, and software profilers. Software metrics will be used for static software analysis, and software profilers will be used for dynamic software analysis.

Keywords: EJB 2.1, EJB 3.0, ISO/IEC 9126, software metrics

iii

Curriculum Vitae
Lini podaci Ime i prezime: Srdjan Krsmanovi Telefon: 064/225-0945 E-mail: krsrdjan@beotel.net Datum rodjenja: 8.4.1982. god. Pol: muki

Obrazovanje:
(2007 - 2009) Fakultet organizacionih nauka, Beograd, softverskog inenjerstva Master studije iz oblasti

(2001 - 2007)

Fakultet organizacionih nauka, Beograd, Odsek za informacione sisteme i tehnologije, prosena ocena 8.53 Elektrotehnika kola Nikola Tesla, Beograd

(1998 - 2001)

Radno iskustvo:
(maj 2008 - danas) (januar 2007 maj 2008) Sportska kladionica MOZZART, Software developer

Mega Computer Engineering, Software developer Diplomski rad na temu Informacioni sistem agencije za zapoljavanje u J2EE okruenju

(maj 2007)

Ostale vetine:
Vozaka dozvola: B kategorija

Ostala interesovanja:

elektrina gitara, lino usavravanje, druenje

iv

Zahvalnica

eleo bih, ovom prilikom, da se zahvalim mojoj porodici na velikoj podrci koju mi je pruila tokom redovnih studija, a posebno mojoj majci bez ijih saveta i pomoi ovaj rad ne bi video svetlost dana.

Hvala Vam svima!

SADRAJ: 1. UVOD ........................................................................................................................................ 1 2. EJB 2.1 TEHNOLOGIJA ............................................................................................................ 3 2.1. Java tehnologije .................................................................................................................... 3 2.2. Java EE komponente ............................................................................................................ 5 2.3. Java EE kontejneri (Java EE containers) ............................................................................... 6 2.4. Struktura Java EE aplikacija ................................................................................................. 8 2.5. Enterprise Beans u EJB 2.1 tehnologiji ................................................................................. 9 2.5.1. Tipovi Enterprise objekata .......................................................................................... 10 2.5.2. Session beans ............................................................................................................. 11 2.5.3. Entity Beans ............................................................................................................... 14 2.5.4. Message-Driven beans ............................................................................................... 21 2.6. Perzistentnost u EJB 2.1 tehnologiji.................................................................................... 24 2.6.1. Upitni jezik ................................................................................................................ 24 2.7. Saetak ............................................................................................................................... 25 3. EJB 3.0 TEHNOLOGIJA .......................................................................................................... 26 3.1. EJB 3.0 kratak pregled ....................................................................................................... 26 3.2. Enterprise Bean klase i poslovni interfejsi .......................................................................... 27 3.2.1. Enterprise Bean klasa ................................................................................................. 27 3.2.2. Interfejsi ..................................................................................................................... 27 3.2.3. Presretai ................................................................................................................... 27 3.2.4. InvocationContext ...................................................................................................... 29 3.2.5. Izuzeci........................................................................................................................ 29 3.2.6. Home interfejsi ........................................................................................................... 29 3.3. Stateless Session Beans ...................................................................................................... 29 3.3.1. Interfejsi Stateless Session Bean-a .............................................................................. 29 3.3.2. Bean klasa i njene metode ivotnog ciklusa ................................................................ 30 3.3.3. Ostale karakteristike ................................................................................................... 30 3.3.4. Klijenstki pogled ........................................................................................................ 31 3.4. Stateful Session Beans ........................................................................................................ 31 3.4.1. Interfejsi Stateful Session Bean-a ............................................................................... 31 3.4.2. Bean klasa i njene metode ivotnog ciklusa ................................................................ 31 3.4.3. Ostale karakteristike ................................................................................................... 32 3.4.4. Klijentski pogled ........................................................................................................ 32 3.5. Message Driven Beans ....................................................................................................... 33 3.5.1. Interfejsi Message Driven Bean-a ............................................................................... 33 3.5.2. Bean klasa i njene metode ivotnog ciklusa ................................................................ 33 3.5.3. Ostale karakteristike ................................................................................................... 33 3.6. Perzistencija ....................................................................................................................... 34 3.6.1. Entiteti ....................................................................................................................... 34 3.6.1.1. Veze izmedju entiteta .......................................................................................... 36 3.6.1.2. Dvosmerna (bidirectional) i jednosmerna (unidirectional) veza ........................... 36 3.6.1.3. Upiti u zavisnosti od dvosmerne i jednosmerne veze ........................................... 37 3.6.2. Operacije nad entitetima ............................................................................................. 37 3.6.2.1. Entity Menager ................................................................................................... 37 3.6.2.2. ivotni ciklus entiteta ......................................................................................... 37 3.6.3. Upitni jezik ................................................................................................................ 40 3.6.3.1. SELECT upiti ..................................................................................................... 41 3.6.3.2. UPDATE i DELETE upiti................................................................................... 41 3.6.4. Metapodaci za objektno-relaciono preslikavanje (O/R Mapping) ................................ 41 3.6.4.1. Karakteristine anotacije za O/R presikavanje .................................................... 41 vi

3.7. Enterprise Bean kontekst i okolina...................................................................................... 46 3.8. Kompatibilnost i migracija ................................................................................................. 48 3.9. Metadata anotacije .............................................................................................................. 49 3.9.1. Anotacije za EJB Bean-ove ........................................................................................ 49 3.9.2. Anotacije za transakcije .............................................................................................. 52 3.9.3. Anotacije za presretae i ivotni ciklus bean-a ............................................................ 53 3.9.4. Anotacije za izuzetke, zatitu pristupa i timeout ......................................................... 54 3.9.5. Anotacije za EJB reference i Resource reference ........................................................ 55 3.10. Saetak ............................................................................................................................. 56 4. SOFTVERSKE METRIKE ....................................................................................................... 57 4.1. ISO standardi ..................................................................................................................... 57 4.1.1. ISO/IEC 9126-1 ......................................................................................................... 57 4.1.2. ISO/IEC 9126-2 ......................................................................................................... 59 4.1.3. ISO/IEC 9126-3 ......................................................................................................... 60 4.1.4. ISO/IEC 9126-4 ......................................................................................................... 62 4.2. Swat4j i Analyst4j .............................................................................................................. 63 4.2.1. Opis softverskih metrika ............................................................................................. 66 4.3. Saetak ............................................................................................................................... 73 5. STUDIJSKI PRIMER ............................................................................................................... 74 5.1. Uproena Larmanova metoda razvoja softvera .................................................................. 74 5.1.1. Zahtevi ....................................................................................................................... 74 5.1.1.1. Verbalni model ................................................................................................... 74 5.1.1.2. Sluajevi korienja sistema ................................................................................ 74 5.1.1.3. Opis sluaja korienja ........................................................................................ 75 5.1.2. Analiza ....................................................................................................................... 82 5.1.2.1. Ponaanje sistema ............................................................................................... 82 5.1.2.1.1. Sistemski dijagram sekvenci ........................................................................ 82 5.1.2.1.2. Definisanje ugovora o sistemskim operacijama ............................................ 95 5.1.2.2. Struktura sistema ................................................................................................ 97 5.1.2.2.1. Konceptualni (domenski) model .................................................................. 97 5.1.2.2.2. Relacioni model .......................................................................................... 98 5.1.3. Projektovanje ............................................................................................................. 98 5.1.3.1. Arhitektura softverskog sistema .......................................................................... 98 5.1.3.2. Aplikaciona logika .............................................................................................. 98 5.1.3.2.1. Kontroler poslovne logike ........................................................................... 98 5.1.3.2.2. Poslovna logika ........................................................................................... 99 5.1.3.2.3. Perzistentni okvir......................................................................................... 99 5.1.3.3. Skladite podataka ............................................................................................ 100 5.1.3.4. Projektovanje korisnikog interfejsa ................................................................. 101 5.1.3.4.1. Ekranske forme ......................................................................................... 102 5.1.3.4.2. Projektovanje kontrolera korisnikog interfejsa ......................................... 110 5.1.3.5. Konani izgled arhitekture softverskog sistema ................................................. 111 5.4. Sazetak ............................................................................................................................. 112 6. KOMPARATIVNA ANALIZA EJB 2.1 I EJB 3.0 TEHNOLOGIJE ....................................... 113 6.1. Statika analiza softverskog sistema ................................................................................. 113 6.2. Dinamika analiza softverskog sistema ............................................................................. 128 6.2.1. Monitoring aplikacije ............................................................................................... 128 6.2.2. Analiza performansi delova aplikacije ...................................................................... 130 6.3. Ocena posmatranih tehnologija ......................................................................................... 133 6.4. Saetak ............................................................................................................................. 134 7. ZAKLJUAK ......................................................................................................................... 135 8. LITERATURA ....................................................................................................................... 138 vii

Lista slika: Slika 1: Scenario izvravanja JEE aplikacija [JenniferBall] ............................................................. 6 Slika 2: Java EE server i kontejneri [JenniferBall] ........................................................................... 7 Slika 3: Struktura EAR datoteke [JenniferBall] ............................................................................... 8 Slika 4: ivotni ciklus session objekta ........................................................................................... 13 Slika 5: ivotni ciklus Entity bean-a ............................................................................................. 18 Slika 6: ivotni ciklus Message objekta ........................................................................................ 23 Slika 7: Dijagram prelaza stanja entiteta ........................................................................................ 38 Slika 8: Model kvaliteta [ISO9126_1] ........................................................................................... 58 Slika 9: Eksterne Softverske metrike definisane za podkategoriju Changeability [ISO9126_2] ...... 60 Slika 10: Interne Softverske metrike definisane za podkategoriju Changeability [ISO9126_3] ...... 61 Slika 11: Metrike za utvrivanje efektivnosti [ISO9126_4] ........................................................... 62 Slika 12: Odnos izmedju atributa softverskog sistema, softverskih metrika i pravila u pisanju programskog koda......................................................................................................................... 64 Slika 13: Sluajevi korienja sistema ........................................................................................... 75 Slika 14: Konceptualni model ....................................................................................................... 97 Slika 15: Kontroler poslovne logike .............................................................................................. 99 Slika 16: Perzistentni okvir ......................................................................................................... 100 Slika 17: Kompletna arhitektira softverskog sistema ................................................................... 111 Slika 18: Model kvaliteta softvera EJB 2.1 tehnologija ............................................................. 113 Slika 19: Model kvaliteta softvera EJB 3.0 tehnologija ............................................................. 114 Slika 20: Atribut Testiranje za EJB 2.1 tehnologiju ..................................................................... 117 Slika 21: Atribut Testiranje za EJB 3.0 tehnologiju ..................................................................... 117 Slika 22: Atribut Kvalitet projektovanja za EJB 2.1 tehnologiju .................................................. 118 Slika 23: Atribut Kvalitet projektovanja za EJB 3.0 tehnologiju .................................................. 119 Slika 24: Atribut Performanse za EJB 2.1 tehnologiju ................................................................. 119 Slika 25: Atribut Performanse za EJB 3.0 tehnologiju ................................................................. 120 Slika 26: Atribut Razumljivost za EJB 2.1 tehnologiju ................................................................ 121 Slika 27: Atribut Razumljivost za EJB 3.0 tehnologiju ................................................................ 122 Slika 28: Atribut Odravanje za EJB 2.1 tehnologiju ................................................................... 123 Slika 29: Atribut Odravanje za EJB 3.0 tehnologiju ................................................................... 124 Slika 30: Atribut Ponovno korienje za EJB 2.1 tehnologiju ...................................................... 125 Slika 31: Atribut Ponovno korienje za EJB 3.0 tehnologiju ...................................................... 125 Slika 32: Monitoring aplikacije koja koristi EJB 2.1 tehnologiju ................................................. 128 Slika 33: Monitoring aplikacije koja koristi EJB 3.0 tehnologiju ................................................. 129 Slika 34: Prikaz poziva metode snimiClana() kontrolera poslovne logike (EJB 3.0 tehnologija) .. 130 Slika 35: Prikaz poziva metode snimiClana() kontrolera poslovne logike (EJB 2.1 tehnologija) .. 131

viii

Lista tabela: Tabela 1: Nivoi JEE aplikacije ........................................................................................................ 4 Tabela 2: Pojednostavljeni prikaz metrike Parametrised modifiability ........................................... 60 Tabela 3: Pojednostavljeni prikaz metrike Change recordability .................................................... 61 Tabela 4: Metrika Frekvencija greke ............................................................................................ 63 Tabela 5: Odabrane metrike u modelu kvaliteta softverskog paketa Swat4j ................................... 72 Tabela 6: Skladite podataka - tabela Clan .................................................................................. 100 Tabela 7: Skladite podataka - tabela Firma ............................................................................... 101 Tabela 8: Skladite podataka - tabela Clanarina Firme................................................................ 101 Tabela 9: Skladite podataka - tabela Login ............................................................................... 101 Tabela 10: Matrini prikaz vrednosti softverskih metrika u modelu kvaliteta softvera ................. 126 Tabela 11: Prikaz rezultata dobijenih monitoringom aplikacije .................................................... 129 Tabela 12: Prikaz redosleda poziva metoda i rezultata dobijenih analizom metoda ...................... 132

ix

1. UVOD
Dananju kompjutersku tehnologiju karakterie veoma brz stepen razvoja. Ovo je naroito izraeno u oblasti softverskog inenjerstva. Svakim danom se radjaju ideje kako ubrzati razvoj softvera i olakati posao programera, a na svakih par godina, poneka ideja se razvije u neku novu tehnologiju. Postojee tehnologije evoluiraju a nove se kreiraju, teei da otklone probleme koje su imale njihove prethodnice. Kada se postavlja pitanje koju tehnologiju koristiti za razvoj sloenih (Enterprise) aplikacija est izbor je EJB tehnologija (Enterprise Java Beans) [JenniferBall] [BB] [DPanda]. Ovaj rad predstavlja logian nastavak diplomskog rada [Krsmanovi] u okviru koga su iznete osnove EJB tehnologije. Neosporna je injenica da EJB tehnologija predstavlja de facto standard prilikom razvoja slo enih aplikacija i u verziji EJB 3.0 je znaajno napredovala [JenniferBall]. Takodje se definiu i standardi u oblasti softverskog inenjerstva. Tako je, na primer, Meunarodna organizacija za standardizaciju (International organization for Standardization ISO) definisala standard ISO/IEC 9126 [ISO9126] [ISO9126_1] [ISO9126_2] [ISO9126_3] [ISO9126_4] kojim se precizno definie kvalitet softvera. U standardu su definisani atributi kvaliteta softverskog sistema, kao i softverske metrike [JavaBoutique1] [JavaBoutique2] na osnovu kojih je mogue izvriti statiku analizu softverskog sistema. Pored statike analize, postoji i dinamika analiza softverskog sistema koja se zasniva na korienju softverskih paketa (na primer, The NetBeans Profiler Project [ZWNetBeans], Eclipse Test & Performance Tools Platform Project [ZWEclipse]) namenjenih praenju performansi softverskog sistema. Na osnovu dinamike analize softverskog sistema mogue je uoiti delove aplikacije koji se sporo izvravaju, zauzimaju memorijski prostor itd. Predmet istraivanja je komparativna analiza dve vezije savremene softverske tehnologije, EJB tehnologije, koje se koriste u razvoju slo enih (enterprise) aplikacija. Na osnovu definisanog predmeta, na po etku istraivanja postavljeni su sledei ciljevi istraivanja: 1. Dati pregled EJB 2.1 tehnologije; 2. Dati pregled EJB 3.0 tehnologije; 3. Dati pregled ISO/IEC 9126 standarda; 4. Izvriti komparativnu analizu EJB 2.1 i EJB 3.0 tehnologije. U okviru ovog cilja definisani su sledei podciljevi: Izvriti statiku analizu tehnologija korienjem softverskih metrika; Izvriti dinamiku analizu tehnologija korienjem softverskih profajlera; Oceniti posmatrane tehnologije na osnovu softverskih metrika i profajlera.

Rad se sastoji iz sedam poglavlja: U prvom poglavlju dat je Uvod koji prethodi razmatranju tehnologija. U drugom poglavlju dat je prikaz EJB 2.1 tehnologije. Prikazane su Java komponente, kontejneri kao i struktura Java EE aplikacija. Nakon toga su objanjeni Enterprise bean-ovi u EJB 2.1 tehnologiji, kao i relizacija perzistentnosti u EJB 2.1. U treem poglavlju dat je prikaz EJB 3.0 tehnologije. Poto je to novija verzija iste tehnologije, akcenat je stavljen na razlike i poboljanja uvedena izmedju posmatranih verzija. Takodje je vie okrenuta panja perzistentnosti u EJB 3.0. U etvrtom poglavlju prikazan je ISO/IEC 9126 standard kojim se definie kvalitet softverskog sistema. Ovaj standard se sastoji iz etiri dela: 1. ISO/IEC 9126-1 [ISO9126_1] kojim se definie model kvaliteta softvera (Quality model), 2. ISO/IEC 9126-2 [ISO9126_2] kojim se definiu eksterne metrike ( External metrics), 3. ISO/IEC 9126-3 [ISO9126_3] kojim se definiu interne metrike ( Internal metrics) i 4. ISO/IEC 9126-4 [ISO9126_4] kojim se definie kvalitet u korie nju metrika (Quality in use metrics). Zatim je korienjem matematikih modela dat prikaz metrika koje se nalaze u softverskom paketu Swat4j [ZWSwat4j] koji predstavlja dodatak za razvojno okruenje Eclipse. U petom poglavlju dat je prikaz studijskog primera korienjem Larmanove metode razvoja softvera. U estom poglavlju je izvrena statika i dinamika analiza softverskog sistema korienjem softverskog alata Swat4j i NetBeans Profiler. Rezultati analize su dati tabelarno i izvedeni su odgovarajui zakljuci. U sedmom poglavlju data su zakljuna razmatranja o posmatranim tehnologijama.

2. EJB 2.1 TEHNOLOGIJA

U ovo poglavlju e biti dat kratak pregled Java tehnologije, Java EE, kao i pregled EJB 2.1 tehnologije. Unutar izlaganja o EJB 2.1 bie objanjene komponente EJB 2.1 tehnologije, kao i perzistencija unutar EJB 2.1. 2.1. Java tehnologije Programski jezik Java je u potpunosti nezavistan od operativnog sistema na kojem se izvrava, ime je obezbeena prenosivost (portabilnost) aplikacija razvijenih u Javi. Napisana aplikacija se moe izvriti na bilo kom operativnom sistemu, pod pretpostavkom da za taj operativni sistem postoji JRE (Java Runtime Environment), odnosno JVM (Java Virtual Machine) koja interpretira Java naredbe, preslikavajui ih u naredbe konkretnog operativnog sistema. Takoe, programski jezik je u potpunosti nezavistan od konkretnih Sistema za upravljanje bazama podataka (DBMS - Database Management System), ime se, uz obezbeivanje odgovarajuih upravljakih programa (drajvera) omoguava povezivanje aplikacije sa konkretnim DBMS sistemima i preslikavanje optih Java naredbi u naredbe konkretnog DBMS. Razlikujemo tri izdanja Java platforme. Svako izdanje namenjeno je razvoju specifinih aplikacija i obezbeuje drugaije izvrno ( runtime) okruenje: 1. Java 2 Standard Edition, J2SE obezbeuje izvrno okruenje za razvoj desktop aplikacija i predstavlja jezgro funkcionalnosti za naredna izdanja Java platforme; 2. Java Enterprise Edition, JEE predstavlja nadskup J2SE koji podrava razvoj enterprise aplikacija; 3. Java 2 Micro Edition, J2ME definie skup izvrnih okruenja za razvoj aplikacija za embedded ureaje kao to su mobilni telefoni, PDA ureaji, TV ureaji i ostali ureaji koji imaju manjak resursa da podre J2SE ili JEE. Java platforma za razvoj enterpise aplikacija (JEE) moe se podeliti u etiri dela koja prate odgovarajue tehnologije i servisi [DrVlajic3]: 1. Web tehnologije koje se koriste u razvoju prezentacionog nivoa JEE ili stand-alone Web aplikacije: Java servleti Java server strane (JavaServer Pages - JSP) Java server strane sa standardnom bibliotekom tagova ( JavaServer Pages Standard Tag Library - JSTL) Java server oblici (JavaServer Faces JSF) Internacionalizacija i lokalizacija web aplikacija 2. Enterprise JavaBeans (EJB) tehnologije koje se koriste u razvoju poslovne logike JEE aplikacije: Session bean-ovi Enterprise bean-ovi Message-driven bean-ovi Enterprise JavaBeans upitni jezik 3. Java XML tehnologije za razvoj aplikacija koje procesiraju XML dokumente i implementiraju web servise: 3

Java API za XML procesiranje (JAXP) Java API za XML-RPC (JAX-RPC) SOAP attachments API za Javu (SAAJ) Java API za XML registrovanje (JAXR) 4. Servisi JEE platforme koje koriste sve navedene tehnologije: Transakcije (Transactions) Povezivanje resursa (Resource Connections) Zatita (Security) Java servis poruke (Java Message Service) JEE platforma podrava [DrVlajic3]: Vienivojski distribuirani aplikacioni model Komponente koje se mogu ponovo koristiti Jedinstveni model zatite Prilagodljivu transakcionu kontrolu Web servise koji su zasnovani na XML standardnima i protokolima. JEE platforma koristi distribuirani vie-nivojski model (obino tronivojski model) za razvoj JEE enterprise aplikacija (slo enih aplikacija). JEE aplikacija sastoji se od JEE komponenti koje su instalirane na razliitim raunarima. Komponente, odnosno raunari na kojima se izvravaju komponente su dodeljene razliitim nivoima JEE aplikacije (Slika 1.) [DrVlajic3]: 1. Klijentski nivo komponente koje se izvravaju na klijentskim raunarima 2. Nivo aplikacione logike komponente koje se izvravaju na JEE serveru. Ovaj nivo je podeljen na dva podnivoa: Web nivo Poslovni nivo 3. Enterprise information system (EIS) nivo komponente koje se izvravaju na EIS serveru (obino je to neki sistem za upravljanje bazama podataka Database Management System DBMS).
1. Klijentski nivo 2. Nivo aplikativne logike 3. EIS nivo

2.1 Web nivo 2.2 Poslovni nivo

Tabela 1: Nivoi JEE aplikacije JEE komponente su pisane u Java programskom jeziku i kompajliraju se na isti nain kao i bilo koji drugi program pisan u Javi. Razlika izmeu JEE komponenti i standardnih Java klasa se ogleda u tome da se JEE komponente ugrauju (assembled) u JEE aplikaciju ako zadovoljavaju JEE specifikaciju. JEE aplikacije se izvravaju u okruenju JEE servera koji ima ulogu da prati i upravlja izvrenjem JEE aplikacije. Pri tome je bitno napomenuti da se sve specifikacije koje se odnose na Javu i odgovarajue tehnologije definiu kroz JCP (Java Community Process, [ZWJCP]) za koji je zaduen Sun Microsystems. JCP je otvorena organizacija, njeni lanovi su individue i organizacije koje dele zajedniki interes vienja Java tehnologije koja zadovoljava trine zahteve i koja evoluira. JCP proces je krajnje jednostavan: JCP lanovi koji ele da proire Java platformu podnose formalni predlog JSR (Java Specification Request) koji prolazi kroz poznati ivotni ciklus glasanja, kritika, testiranja i odluke. 4

2.2. Java EE komponente

Kao to je ve napomenuto JEE aplikacije se sastoje od komponenti. U Java EE specifikaciji razlikujemo sledee komponente: Aplikacioni klijenti i apleti (komponente koje se izvravaju na strani klijenta); Java Servlet, JavaServer Faces i JavaServer Pages predstavljaju web komponente koje se izvravaju na strani servera; EJB (Enterprise Java Beans) predstavljaju poslovne komponente koje se izvravaju na serverskoj strani. Web klijenti se esto nazivaju tanki klijenti. Tanki klijenti obino ne izvravaju upite nad bazom podataka i ne izvravaju sloena poslovna pravila. Web klijenti se sastoje iz dva dela [JenniferBall]: 1. Dinamike web strane koje su zasnovane na nekom markup jeziku (na primer HTML, XML...) koje se generiu na osnovu web komponenti koje se izvravaju na web nivou; 2. Web itaa koji je zaduen za prikazivanje (renderovanje) strana koje dobija kao odgovor servera. Aplet (Applet) predstavlja klijentsku aplikaciju napisanu u programskom jeziku Java koja se izvrava pomou Java virtuelne maine klijentskog sistema uz korienje internet itaa. Meutim, klijentskim sistemima je najee potreban odgovarajui Java plug-in i verovatno policy datoteka jer su apleti prilino restriktivni kada je u pitanju pristup lokalnom datotenom sistemu. Aplikacioni klijenti se izvravaju na klijentskom sistemu i omoguavaju izvrenje zadataka u okruenju koje ima znaajno bolji korisniki interfejs. Najee se za realizaciju korisnikog interfejsa koristi Swing ili AWT (Abstract Window Toolkit) API. Aplikacioni klijenti mogu direktno pristupiti EJB komponentama koje se izvravaju na poslovnom nivou. Takoe, aplikacioni kljenti mogu uspostaviti HTTP konekciju i na taj nain komunicirati sa servletima koji se izvravaju na poslovnom nivou. Java EE web komponente su ili servleti ili strane koje su kreirane korienjem JSP tehnologije (JSP strane) i/ili JavaServer Faces (JSF) tehnologije. JSF tehnologija zasnovana je na servletima i JSP tehnologiji i definie okvir koji se sastoji od komponenti namenjenih za realizaciju korisnikog interfejsa web aplikacija. Na ovaj nain mogu se formirati bogate internet aplikacije. Za poslovnu logiku aplikacije zadueni su EJB komponente koje se izvravaju u okviru poslovnog sloja. Na Slici 2. prikazan je tipian scenario po kome EJB komponente prihvataju podatke iz klijentskih programa, procesiraju ih (ukoliko je potrebno) i alju ih do EIS nivoa kako bi ih sauvali u odgovarajuem sistemu za upravljanje bazom podataka. Takoe, EJB komponente prihvataju podatke iz skladita podataka, obrauju ih (ukoliko je potrebno) i prosleuju ih do klijentskih programa.

Slika 1: Scenario izvravanja JEE aplikacija [JenniferBall]

2.3. Java EE kontejneri (Java EE containers)

injenica je da je Java EE arhitektura platformski nezavisna i zasnovana na komponentama. To omoguava jednostavan razvoj aplikacija , jer se poslovna logika organizuje u komponente koje se mogu ponovo koristiti. Pored toga, Java EE server obezbeuje dodatne servise koji se mogu koristiti unutar odgovarajueg kontejnera. Kontejneri predstavljaju interfejs izmeu komponenti i platformski specifinih funkcionalnosti koji podravaju izvravanje komponenti. Na primer, pretpostavimo da je potrebno pokrenuti web aplikaciju. Najpre se web aplikacija mora spakovati u odgovarajui web modul i postaviti u web kontejner. Na ovaj nain se specificiraju podeavanja kontejnera za svaku komponentu Java EE aplikacije kao i za samu Java EE aplikaciju. Tipini servisi koje obezbeuje Java EE server su zatita (security), upravljanje transakcijama (transaction management), JNDI pozivi (Java Naming and Directory Intrerface), daljinsko povezivanje (remote connectivity)... Na ovaj nain ostvaruju se viestruke prednosti: Java EE security model omoguava definisanje odgovarajuih mehanizama zatite web komponenti ili EJB komponenti tako da im mogu pristupiti samo autorizovani korisnici; Java EE transaction model omoguava specificiranje odnosa metoda koje ine jednu transakciju ime se obezbeuje da se sve metode koje ine jednu transakciju posmatraju kao jedinstvena jedinica; Java EE remote connectivity model zaduen je za upravljanje komunikacijama izmeu klijenata i enterprise bean-ova (u pitanju je komunikacija na niskom novu). Nakon kreiranja enterprise bean-ova klijent poziva njegove metode kao da se nalaze u okviru iste virtuelne maine. 6

Poto Java EE arhitektura omoguava korienje servisa koji se mogu konfigurisati, komponente Java EE aplikacije se mogu ponaati razliito u zavisnosti od mesta gde su rasporeene. Na primer, EJB moe imati podeene zatitne mehanizme koji mu omoguavaju jedan nivo pristupa bazi podataka u nekom izvrnom okruenju, ili drugaiji nivo pristupa podacima u drugom izvrnom okruenju. Kontejner takoe upravlja servisima koji se ne konfiguriu: ivotnim ciklusima servlet-a i enterprise bean-ova, datasource connection pooling-om, perzistentnou podataka (data persistence) i pristupom do Java EE API-ja. Na Slici 2. predstavljene su Java EE komponente koje se izvravaju u okviru odgovarajuih kontejnera. Razikujemo nekoliko kontejnera [JenniferBall]: Java EE server: izvrni deo Java EE proizvoda. Unutar Java EE server-a nalaze se EJB i web kontejner; EJB (Enterprise JavaBeans) kontejner: Upravlja izvrenjem enterprise bean-ova Java EE aplikacija. Enterprise bean-ovi i njihov kontejner izvravaju se na Java EE serveru; Web kontejner: Upravlja izvrenjem JSP strane i servlet komponente Java EE aplikacije. Web komponente i njihov kontejner izvravaju se na Java EE serveru; Application Client Container: Upravlja izvrenjem aplikacionih komponenti klijenta. Aplikacioni klijenti i njihov kontejner izvravaju se na klijentskom sistemu ( client machine); Applet container: Upravlja izvrenjem apleta. Sastoji se od web itaa i odgovarajueg plug-in mehanizma koji se zajedno izvravaju na klijentskom sistemu.

Slika 2: Java EE server i kontejneri [JenniferBall]

2.4. Struktura Java EE aplikacija

Java EE aplikacije se pakuju u jednu ili vie standardnih jedinica za rasporeivanje (deployment units). Svaka jedinica se sastoji iz sledeih komponenti: Funkcionalne komponente (enterprise bean-ovi, JSP strane, servleti, apleti...); Opisiva rasporeda (Deployment descriptor) koji opisuje sadraj aplikacije. Nakon postavljanja aplikacije na odgovarajui server (podsetimo se, potreban je Java EE server) aplikacija se mo e izvriti. Pri tome, moe se koristiti web kontejner ukoliko su u pitanju aplikacije koje se sastoje iz web komponenti ili EJB kontejner koji je neophodan ukoliko se prilikom razvoja aplikacija koristi Enterprise bean-ovi. Java EE aplikacija se isporuuje u obliku EAR datoteke (Enterprise Archive) koja, u stvari, predstavlja standardnu Java arhivu (Java archive, JAR) koja ima .EAR ekstenziju. Korienje EAR datoteka i modula omoguava sklapanje veeg broja razliitih Java EE aplikacija koje se mogu zasnivati na istim komponentama. Drugim reima, nije neophodno dodatno pisanje programskog kda; samo je potrebno na odgovarajui nain spakovati razliite Java EE module u jedinstvenu EAR datoteku. Na Slici 3. je prikazana struktura Java EE aplikacije. Kao to se moe videti, EAR datoteka sastoji se iz Java EE modula i opisivaa rasporeda (deployment descriptor). Opisiva rasporeda je XML datoteka koja opisuje podeavanja aplikacije, modula ili komponenti. Bitno je napomenuti da je sadraj opisivaa rasporeda deklarativan tako da se on mo e promeniti bez potrebe za modifikovanjem programskog kda. U vreme izvravanja Java EE server ita sadraj deployment descriptor-a i vri odgovarajua podeavanja aplikacije, modula i komponenti.

Slika 3: Struktura EAR datoteke [JenniferBall]

Razlikujemo etiri tipa Java EE modula [JenniferBall]: EJB moduli: sadre class datoteke koje se odnose na enterprise bean-ove i odgovarajui EJB opisiva rasporeda. EJB moduli se pakuju u JAR datoteke koje imaju .jar ekstenziju;

Web moduli: sadre servlet class datoteke, JSP class datoteke, HTML datoteke i opisiva rasporeda web aplikacije. Web moduli se pakuju u JAR datoteke koje imaju .war ekstenziju; Appication client moduli: sadre class datoteke i opisiva rasporeda aplikacije. Application client moduli se pakuju u JAR datoteke koje imaju .jar ekstenziju; Resource Adapter moduli: sadre Java interfejse, klase, biblioteke i drugu dokumentaciju i odgovarajui resource adapter opisiva rasporeda. Oni obezbeuju connector arhitekturu za odreeni EIS. Resource adapter moduli se pakuju u JAR datoteke koje imaju .rar ekstenziju. Postoje dva tipa opisivaa rasporeda: Java EE i runtime. Java EE opisiva rasporeda je definisan u Java EE specifikaciji i moe se koristiti za konfigurisanje parametara zajednikih za svaku Java EE implementaciju (implementacija nastaju na osnovu Java EE specifikacije, moe postojati vie implementacija). Sa druge stane, runtime opisiva rasporeda se koristi za konfigurisanje implementaciono - specifinih parametara Java EE aplikacija. Na primer, aplikacioni server kompanije Sun Microsystems sadri informa cije o kontekstu web aplikacije (context root) kao i implementaciono-specifina podeavanja kao to su, na primer, direktive za keiranje. Usvojena je konvencija da runtime opisiva rasporeda aplikacionog servera ima naziv sun-tipModula.xml i da se nalazi u istom folderu kao i Java EE opisiva rasporeda.

2.5. Enterprise Beans u EJB 2.1 tehnologiji

Enterprise Beans su osnovne komponente od kojih su izgradjene velike (enterprise) aplikacije. Osnovne osobine ovih komponenata su da Sadre u sebi poslovnu logiku koja operie podacima Pojavljivanjima bean-ova upravlja kontejner Bean se mo e menjati u vreme putanja u rad, promenom podeavanje njegove okoline Razni servisi kao sto su transakcije, sigurnost i sl. su odvojeni od samih klasa beanova Pristup bean-ovima ide preko kontenera Ako bean koristi samo EJB definisane servise onda moze da se izvrava u bilo kom kontejneru Moe se dodati u sloenoj (enterprise) aplikaciju bez promene koda na beanu ili aplikaciji itd.

Ugovori Klijentski ugovori su ugovori izmedju klijenta i kontejnera. Klijent jednog enterprise bean-a moe biti drugi bean, Java aplikacija, web servis itd, kao i klijent koji nije pisan u Javi. Klijent jednog session ili entity bean-a moe imati pogled na bean koji moe biti udaljeni (Remote ) ili lokalni (Local) pogled. Udaljeni pogled je prilagodljiviji, jer ga mogu koristiti i udaljeni i lokalni klijenti. Ova pogled koristi standardni Java API za udaljeni pristup objektima. Lokalni pogled je ogranien na komponente koje sa nalaze u isto j VM kao i sam klijent. Lokalni pogled koristi obine Java interfejse. 9

Local i Remote pogledi sadre: Home interfejs Interfejs komponente (Remote i Local) Identitet objekta Dodatno Remote pogled sadri: Meta podatke Ruku (Handle) Home interfejs enterprise bean-a definie metode za kreiranje, unitavanje i pretraivanje, kao i poslovne metode za Entity bean-ove. Ako bean ima definisan Remote interfejs uz njega treba da ide i Home interfejs. Isto vai ako bean ima definisan Local interfejs, tada treba da ima i odgovarajui LocalHome interfejs. Klijent moe da locira Home interfejs bean-a preko Java Naming and Directory Interface (JNDI) API. Jednom EJB objektu se pristupa preko interfejsa komponente koji mogu biti Remote ili Local. Na taj nain se definie ta je kom klijentu dostupno iz jednog bean-a. EJB objekat ivi unutar svoje kue (Home) i ima jedistven identitet povezan sa Home interfejsom. Kontejner je zaduen da kreira ovaj jedinstevi identeitet. Ovaj identitet nije dostupan k lijentu ali klijent moe da proveri da li su dva objekta ista. MessageDriven Beans su karakteristini jer nemaju Home interfejse, interfejse komponente i krajnju taku za web-servise. Njima se takodje pristupa preko standardnog Java Naming and Directory Interface (JNDI) API, slino kao kod Remote pristupa. 2.5.1. Tipovi Enterprise objekata Enterprise JavaBeans definie 3 tipa objekata: 1. Session objekat 2. Entity objekat 3. MessageDriven objekat Svaki tip JavaBeans tipova ima neke karakteristike, i ovde emo navesti neke od njih. Session objekat ima sledee karakterstike: Izvrava se u ime jednog klijenta Svestan je transakcija u kojim se moe nai Moe menjati podatke u bazi, ali ih ne predstavlja direktno Ima relativno kratak ivotni vek i gubi se ako EJB k ontejner padne EJB specifikacija definie Stateless i Statefull session objekte koji su slini ali imaju razlike medjusobom. Ovi bean-ovi se najee koriste kada se implementira neka poslovna logika. Entity objekat ima sledee karakteristike: Predstavlja podatke iz baze Dozvoljava pristup od strane vie korisnika Ima dug ivotni vek jer nastavlja da ivi u bazi podataka 10

Ovaj objekat moe da preivi ako kontejner padne, jer je snimljen u bazi. Ako se desi pad u toku transakcije, stanje entity objekta se vraa na poslednje regularno snimljeno stanje. Entity bean se najee koristi u perzistentnom sloju sistema, za potrebe itanja i pisanja podataka u bazu. MessageDriven objekat ima sledee karakteristike: Izvrava se kad primi jednu poruku o d klijenta Izvrava se asinhrono Moe da bude svestan transakcije u kojoj se nalazi Moze menjati podatke u bazi, ali ih ne predstavlja Ima kratak ivotni vek, nema stanje i gubi se ako kontejner padne MessageDriven bean se najee koristi kada je potrebno izvravati asinhrone zahteve. esto se deava da ovaj bean poziva poslovnu logiku pisanu u Session bean-ovima. 2.5.2. Session beans U ovom poglavlju emo blie objasniti Session bean-ove. Ali prvo da pojasnimo sta su to kontejner i session objekat. Kontejner je sistem unutar koga ive session objekti, i taj sistem ima zadatak da preko Home objekta omogui korienje session objekata. Session objekat ivi unutar kontejnera, koji mu obezbedjuje podrku za sigurnost, transaktivnost, konkurentnost i druge servise. Session bean je ne perzistentni objekat koji sadri deo poslovne logike i koji se se izvrava na serveru. Ovaj objekat nije deljiv izmedju vie klijenata. Session bean svoju poslovnu logiku nudi preko Local i / ili Remote interfejsa. U EJB 2.1 Statless bean moe da slui kao krajnja taka za web servis. Java objekat koji implementira Remote interfejs zove se EJBObject. Ovaj objekat je dostupan kroz Java API za udaljeni pristup. Ako neki objeket implementira Local interfejs tada se naziva EJBLocalObject. On je dostupan samo lokalno , ne moe da ide preko Java JNDI APIa. Udaljeni klijent jednog session bean-a moe biti drugi session bean, Java aplikacija, web servis, aplet i td. Udaljeni pristup preko Remote interfejsa je nezavisan od lokacije, sto znai da klijent i bean mogu da budu na istoj ili potpuno razliitoj VM i/ili raunaru. Ovo nije sluaj sa Local interfejsima. Klijent koristi session Home objekat preko JNDI servisa. Ako je intefejs za pristup udaljeni (Remote) onda Home objekat moze da se dobije na sledei nain.
Context initialContext = new InitialContext(); CartHome cartHome = (CartHome)javax.rmi.PortableRemoteObject.narrow( initialContext.lookup(java:comp/env/ejb/cart),CartHome.class);

Ako je interfejs za pristup session beanu localni ( Local) onda je kod za uzimanje Home objekta malo drugaiji: 11

Context initialContext = new InitialContext(); CartHome cartHome = (CartHome) initialContext.lookup(java:comp/env/ejb/cart);

Tipino korienje je da jedan Home objekat moe da se koristi vie puta, u toku ivotnog ciklusa klijentske aplikacije.

RemoteHome interfejs RemoteHome interfejs je klijentu dostapan preko JNDI servisa. Jedna od njegovih osnovnih uloga je da kreira i unitava session objekat . Kreiranje session objekata se radi definisanjem i izvravanjem bar jedne create() metode. Create metoda bean-a kao povratni parametar mora imati remote interfejs session bean-a na koji se odnosi.
public sessionbeans.clan.Clan create() throws javax.ejb.CreateException,java.rmi.RemoteException;

Udaljeni klijent moe unititi javax.ejb.EJBObject klasom.

session

objekat

koristei

remove()

metodu

nad

LocalHome interfejs Slino kao za RemoteHome interfejs, LocalHome interfejs omoguava da se kreira i unitava session objekat. Za razliku od Remote pristupa, Local pristup je zavisan od lokacije. Kreiranje session objekta se radi definisanjem i pozivanjem metode create() . Takodje unitavanje session objekta se radi pozivanjem remove() metode nad javax.ejb.EJBObject klasom.

Identitet seesion objekata Session objekti, gledano sa klijentske strane su anonimni, tj predstavljaju privitan resurs koji dri samo jedan klijent. Zbog toga oni nemaju nekakav identifikator niti metode za pronalaenje (finder methods). ak, ako se nad session objektom pozove metod EJBObject.getPrimaryKey() desie se izuzetak. Pokaziva na session objekat se moe serijalizovati i koristiti kasnije ali pod uslovom da session objekat i dalje postoji na serveru. ivotni ciklus session objekta Na sledeoj slici dajemo graf koji predstavlja ivotni ciklus session objekta.

12

Slika 4: ivotni ciklus session objekta Session objekat ne postoji dok ga korisnik ne kreira. Kada korisnik kreira session objekat, tada korisnik dobija referencu na odgovarajuci interfejs, Remote ili Local. Korisnik koji ima referencu na Remote interfejs moe da je prosledjuje unutar svog domena kao parametar ili povratnu vrednost metode, da pozove remote poslovne metode, da uzme referencu na Home interfejs, da uzme ruku (Handle) na session objekat ili da unisti sesson objekat. Ako se pokua poziv metoda nad session objektom koji nije kreiran desie se izuzetak. U sluaju da korisnk uzima referencu na Local interfejs ima sline mogunosti kao i Remote interfejs, samo sto ne moe da uzme ruku ( Handle) i ne moe koristi referencu Local interfejsa kao parametar metoda koje su Remote tipa. Znai Local i Remote reference ne saradjuju medjusobno.

Identitet session objekata Statefull session objekti imaju jedinstven identitet, koji im se dodeljuje u trenutku kreiranja.O ovom identitetu brine kontejner. Klijent koji koristi ove objekte moe da ih poredi metodom isIdentical(EJBObject otherEJBObject). Za razliku od Statefull session objekata, kod Stateless session objekata postoji jedan session objekat, za jedan njegov Home interfejs. Taj session objekat moe biti referenciran sa vie mesta. Znai, jedan session objekat je vezan sa jednim Home interfejsom. 13

Session objekat je po pravilu anoniman za klijenta i metoda getPrimaryKey() e baciti izuzetak. Session bean ugovor Session bean predstavlja produenje klijenta koji ga koristi, i moe imati neko interno stanje, ako je u pitanju Statefull Session bean. Session bean moe pisati / itati podatke iz baze, i ako je u pitanju Statefull bean, njegov ivotni vek odredjuje klijent. Tipino, stanje Session bean-a se ne pie u bazi direktno. Ono se uva dok traje sesija klije nta, unutar samog bean-a. Ako je potrebno da se stanje snimi u bazu, obino se to radi preko Entity bean-ova. Sam programer je duan da osvei stanje Session bean-a kad god je potrebno, ako je odluio da se stanje snima u bazu. Postoje dve vrste bean-ova Statefull i Stateless bean-ovi. Stateless bean-ovi nemaju nikakvo stanje, i bilo koji bean moe da slui bilo kom klijentu. Statefull bean-ovi imaju interno stanje koje se prenosi kroz vie transakcija i metoda. Ponekad je potrebno da se stanje Statefull bean-a snimi u bazu. Ta operacija je pasivizacija. Obrnuta operacija, itanje stanja bean-a iz baze, je aktivacija. Ove dve operacije mogu da se rade samo ako bean nije trenutno u transakciji.

2.5.3. Entity Beans Entity bean-ovi su jo jedan od moguih tipova bean-ova koji postoje u EJB 2.1. Programer ima zadatak da razvija entity bean-ove i pri tome utvrdjuje veze izmedju njih. On pie apstraktnu perzistentnu shemu i kojoj navodi polja koja ce Entity bean imati kao i metode kojima e se pristupati tim poljima. Ova shema se definie u opisivau rasporeda, i kontejner prilikom putanja u rad (deploy) koristi ovu shemu da generie neke klase i obavi neophodne pripreme da entity bean moe uspesno da se koristi.

CMP i nezavisnost podataka EJB model je projektovan tako da omogui odvojen klijentski pogled na bean-ove od samih entity bean-ova, a takodje i da odvoji entity bean-ove od njihove reprezentacije u bazi podataka. Ovakav dizajn omoguava da bean moe da se menja a da pritom klijenti ne moraju da se rekompajliraju. Takodje, baza podataka koja uva podatke o bean-u se moe menjati, a da pri tom ne mora da se menja ili rekompajlira sama bean klasa. Kada se koristi upravljanje perzistencijiom od strane kontejnera onda programer ne mora da pie kod za pristup bazi. O perzistencuiji se brine kontejner na osnovu eme koja mu je data za svaki entity bean. Ovakav pristup se zove Container Management Persistance (CMP). Programer pie kod koristei pristupne metode a sam pristup bazi radi kontejner. Kontejner takodje preslikava apstraktnu shemu bean-a na odgovarajucu klasu, i takodje na odgovaraju u shemu (tabelu) u bazi podataka. Na ovaj nain se postie nezavisnost izmedju slojeva baze, perzistencije i bean klase. 14

EJB opisiva rasporeda definise logike veze izmedju entity bean-ova. Kontejner je taj koji ima zadatak da te logicke veze povee na odgovarajuci na in, da omogui povezivanje sa konkretnom fizikom bazom podataka i da brine o referencijalnom integritetu podataka. Prednost koriscenja CMP bean-ova je u tome to se bean razvija i koristi nezavisano od fizike baze podataka u kojoj se snimaju podaci. Na taj nain se baza podataka moze promeniti a da entitet uopste ne mora da se menja.

Programerski pogled na CMP Entity bean pisan koristei CMP tipino se sastoji od entity klase, komponent interfejsa (interfejs koji sadri get i set metode) koji definise klijentski pogled na bean, home interfejsa koji sluzi za kreiranje, brisanje, traenje bean-a, i apstraktne sheme za perzistenciju bean-a. Klijent koristi Home interfejs da upravlja ivotnim ciklusom bean-a i odgovarajuce interfejse komponente da poziva poslovne metode. Entity bean koji koristi CMP ima veze sa drugim bean-ovima. Te veze su opisane u perzistentnoj shemi pod elementom relationships. Na taj nain se mogu pisati slo ene aplikacije. Entity bean-ovi veze ostvaruju tako to ne komuniciraju direktno vec preko interfejasa, i to Local interfejasa. Znaci, i klijenti i drugi bean-ovi vide samo interfejse jednog bean-a.

Pogled na Entity bean ugovor Programer mora paziti na neka ogranienja kada pie jedan entity bean. Entity bean klasa mora biti apstraktna, a kontejer pravi odgovarajucu implementaciju CMP polja u entity klasi ne smeju biti klase entity bean-ova. Sva polja su u stvari virtuelna polja i kontejner postavlja odgovarajuce implementacije CMP polja i CMP veze moraju biti definisane u opisivau rasporeda i moraju poinjati malim slovom svim poljima i vezama se pristupa preko get / set metoda svaka metod za pristup mora biti apstraktna, javna i polje mora da se zove isto kao u semi za raspored sa prefiksom get / set ako je neka veza definisana kao jedan vise ili vise vise mora se koristiti java.util.Collection ili java.util.Set metode za pristup vezama ne smeju biti izlozene Remote interfejsima programer treba da vodi rauna da ne dozvoli da menja primarni klju entity bean-a i stoga metoda za set kljua ne sme biti postavljena u interfejse za pristup dozvoljeni Java tipovi za polja jednog bean-a moraju biti Java primitivni tipovi ili Java serijalozovani tipovi.

Pogled na Entity bean veze CMP bean moze imati veze sa drugim bean-ovima ako i oni koriste CMP. Veze mogu biti tipa jedan vise, jedan jedan, i vise vise. One mogu da postoje medju bean-ovima koji su u 15

istom Local okviru. Veze mogu biti jednosmerne i dvosmerne. Kod jednosmernih veza, navigacija ide u jednom smeru, za razliku od dvosmernih gde ide u oba smera. Jednosmerna veza se pravi tako to se veza definie na samo jednom bean-u a ne i na drugom. Bean koji ima definisanu vezu zna za nju. Drugi bean iako je u vezi ne zna za nju. Ako bean nema Local interfejs on ne moze da formira dvosmerne veze, samo jednosmerne. To je zato to veza koristi Local interfejs. Programer mora znati kardinalnost veze bean-ova i tako ih definisati unutar bean-a.

Klase zavisne vrednosti Klasa zavisne vrednosti je konkretna klasa koja je vrednost polja bean-a, nikako polja koje predstavlja vezu. Ova klasa mora biti serijalozovana. Pristup ovim klasama sa get metodom vraa kopiju pojavljivanja klase.

Brisanje bean-ova Brisanje bean-ova se moze uraditi pozivanjem remove metode nad Home interfejsom ili preko cascade-delete opcije nad vezom bean-a. Kada se pozove remove metoda, kontejner poziva ejbRemove(). Ako se ona uspeno izvri, bean e biti obrisan. Takodje, se briu sva pojavljivanja tog bean-a iz svih veza (kolekcija) u kojima je obrisani bean bio prisutan. Na kraju se brie perzistentna reprezentacija bean-a u bazi. Takodje e biti obrisani svi povezani bean-ovi ako se koristi cascade-delete opcija nad vezom. Cascade-delete opcija za brisanje se koristi kada je vie bean-ova egzistencjalno vezano za jedan. Ova opcija mo e da se koristi samo na strani veze gde je jedan, znaci jedan-vise, i jedan-jedan. Brisanjem bean-a na strani jedan briu se svi bean-ovi povezani sa njim.

Identitet entity objekata Entitet u toku izvrsavanja ima identitet o kome se brine kontejner. Perzistentni identitet je predstavljen primarnim kljuem i on se ne sme menjati kada se jednom postavi. Kada se kreira novi bean mora se pozvati ejbCreate() metoda pre nego to se bean moe koristiti unutar veze. Znaenje dodele vrednosti nad vezama U sluaju jedan jedan veze kada se bean prebacuje iz jednog polja bean-a A u isto polje bean-a B, onda se brise sadrzaj iz bean-a A. Ovo je u stvari move operacija. Kada se koristi rad sa kolekaciiama i pokusa da se doda jedan bean u kolekciju u kojoj postoji bean sa tim identitetom, stari bean e biti obrisan, a novi uba en u kolekciju. Osnovne metode za rad sa kolekcijama su add() i addAll(). Treba napomenuti da vie vie veza nece izbaciti elemente iz original kolekcije ako se element povee sa novom kolekcijom. Kod rada sa kolekcijom untar veze, bitno je da tip elemenata u kolekciji bude odgovaraju i inae e kontejner baciti izuzetak.

16

Update relationship model Oblik veze takodje utie na promenu podataka unutar kolekcije koja ini vezu. Kada elimo da postavimo nove vrednosti za postoje i objekat unutar veze, stari objekat ce biti obrisan, a novi objekat ce biti ubaen. Identitet objekta e naravno ostati isti. I ovde vai pravilo da ako se objekat prebacuje iz jedne jedan veze u drugu jedan vezu onda e biti obrisan iz stare jedan veze. Ovo je logicno zbog toga sto oblik veze jedan ukazuje na egzistencijalnu zavisnost.

Ostale karakteristike Pojavljivanja koje su uzlozene na Remote interfejsu su prenete po vrednosti i odvojene od perzistentnog okvira. Promene nad njima ne e menjati stanje entiteta u bazi. Druga stvar je kod Local interfejsa, jer se kod njih prenos radi preko pokaziva a, tako da se svaka promena preko Local interfejsa vidi u bazi. Remote interfejs ima karakteristike koje moraju da se po tuju. Remote interfejs ne sme da izlo i pristup kolekcijama koje predstavljaju veze sa drugim bean-ovima Unutar Remote intefejsa ne sme da izlozi nikakav Local interfejs kao parametar ili rezultat metode Timer-i ne smeju biti izlo eni preko Remote interfejsa. Zavisne klase vrednosti (klase koje predstavljaju polje bean-a) mogu biti izlo ene preko Remote interfejsa Opisiva rasporeda Opisivac rasporeda slu i da definie polja unutar bean-a kao i veze koje jedan bean mo e imati. On pored ostalog opisuje sledee elemente ejb-name je unikatno ime za jedan bean abstract-schema-name je jedinstveno ime sheme koje je povezano sa bean-om ejb-relation definise veze koje bean moze imati, a jedna veza se definise sa dva ejbrelationship-role elementa ejb-relationship-role element opisuje vezu, njeno ime, kardinalnost i navigaciju.

ivotni ciklus Entity bean-a Na sledecoj slici dajemo prikaz ivotnog ciklusa Entity bean-a.

17

Slika 5: ivotni ciklus Entity bean-a

Pojavljivanje entity bean-a moe biti u 3 stanja Ne postoji Postoji u resource pool ali nije povezan ni sa jednim identitetom Spreman pojavljivanje je spremno i povezano sa nekim identitetom ivotni ciklus se moze opisati na sledeci nacin: Pojavljivanje kreira kontejner metodom newInstance() i postavlja mu kontext, setEntityContext(). Pojavljivanje ulazi u pool. Svaki bean ima svoj pool pojavljivanja (instanci). Kad je pojavljivanje u pool-u ono nije povezana sa nekim identitetom i sva pojavljivanja u pool-u se smatraju jednakim. Pojavljivanja u pool-u se ne diraju dok se izvrsava neka Home ili finder metoda. Pojavljivanje prelazi u stanje Spreman na dva naina: pozivanjem ejbCreate() ili ejbPostCreate() metoda ili pozivanjem ejbActivate() metoda. Prvi se koristi kad je entity tek kreairan, a drugi kad ne postoji spreman bean da izvrsi klijentski zahtev. Kada se pojavljivanje nalazi u stanju Spreman ono je povezano sa jednim identitetom entity objekta. Sada kontejner mo e da sinhronizuje stanje pojavljivanja i stanje u 18

bazi podataka, kad god je to potrebno. Ovo se radi pozivanjem metoda ejbLoad() i ejbStore(). Kontejner moze da pasivira pojavljivanje u toku transakcije. Prvo pozove ejbStore() i posle nje ejbPassivate() metodu. Pojavljivanje se onda vraa u pool. Pre ili kasnije kontejner e prebaciti pojavljivanje u pool. To se moze desiti pozivanjem ejbPassivate() metode, pozivanje ejbRemove() metode ili usled pozivanja ejbRollback(). Pojavljivanje vraeno u pool vie nije povezano sa nekim identitetom entity bean-a i moe se opet koristiti. Pojavljivnje se moe izbaciti iz pool-a pozivanjem unsetEntityContext() metode.

Finder metode Home interfejs entity bean-a definie jedan ili vie find metoda. One slue da pronalaze razliite entity objekte i vraaju entity objekat ili kolekciju. Svaki find metod mora biti povezan sa nekim EJB upitom unutar opisiva a rasporeda izuzev findByPrimaryKey(). Postoje finder metode koje vraaju jedan objekat. Kod njih je bitno da tip interfejsa koji se vraa zavisi od tipa finder metode. Ako je Home interfejes lokalnog tipa find metoda e vratiti Local interfejs, a ako je Home interfejs Remote tipa find metoda e vratiti Remote interfejs. Ako je upit u ovoj find metodi takav da vraa vie objekata, desie se izuzetak. Pored ovih find metoda postoje i find metode koje vraaju vie objekata. Ova metoda vraa kolekciju objekata, gde tip objekta unutar kolekcije odgovara tipu Home interfejsa. Ako je Home Local tipa vratie se kolekcija Local interfejsa, a ako je Home interfejs Remote tipa vratie kolekciju Remote interfejsa. Ako se ne koristi DISTINCT ova kolekcija mo e imati vie istih elemenata.

Enterprise Bean klasa Entity bean klasa mora da ispostuje neka pravila Mora da implementira javax.ejb.EntityBean interfejs Moe a ne mora da implementira javax.ejb.TimedObject interfejs Klasa mora biti public i abstract Klasa mora da ima konstruktor bez argumenata Klasa ne sme definisati finalize() metodu Entity bean ne mora da ima neki poslovni interfejs, ali ako ga ima onda mora da implementira sve metode potpisane u interfejsu. Entity bean mora da implementira ejbCreate() i ejbPostCreate() metode, kao i sve ejbHome metode potpisane u Home interfejsu. Entity bean mora implementrati get i set metode za pristup definisane u apstraktnoj shemi, kao abstract metode. Enity bean klasa moe imati super klase ili interfejse. Bitno je da bean ili neka njegova super klasa ima implementirane obavezne ejbMetode. Entity bean moe imati i pomone metode koje nisu navedene u EJB specifikaciji, a koriste se u radu bean-a. Entity bean ne implementira finder metode. To je posao kontejnera. 19

Klase koje predstavljaju atribute bean-a moraju biti serijalozovane i moraju biti public.

EjbCreate i ejbPostCreate metode Bean mora da implementira ejbCreate metode koje odgovaraju onim navedenim u Home ili LocalHome interfejsima. Za svaki ejbCreate metod bean mora da implementira ejbPostCreate metodu. Ove metode moraju da poinju sa ejbPostCreate prefiksom, da budu public, ne smeju biti final i static, tip koji vraaju mora biti void. Ulazni paramatri moraju biti isti kao i paramateri za odgovaraja u ejbCreate metodu.

Poslovne metode Bean moe imatu nula ili vie poslovnih metoda. Njihova imena su proizvoljna ali ne smeju poinjati sa ejb zbog konflikta sa EJB metodama.

Entity Bean Remote interfejs Ovaj interfejs mora naslediti javax.ejb.EJBObject. Metode definisane u ovom interfejsu moraju potovati pravila za RMI-IIOP. Takodje svaki metod naveden u Remote interfejsu mora biti implementiran u bean klasi.

Entity Bean Remote Home Ovaj interfejs mora naslediti javax.ejb.EJBHome interfejs. Metode definisane u ovom interfejsu moraju potovati pravila za RMI-IIOP. Svaki metod mora biti jedan od tri tipa Create metoda Finder metoda Home metoda

Entity Bean Local interfejs Ovaj intefejs mora naslediti javax.ejb.EJBLocalObject. Svaki metod u Local interfejsu mora biti implementiran u beanu. Ovaj interfejs sadri lokalne poslovne metode.

Entity Bean LocalHome interfejs Ovaj interfejs mora naslediti javax.ejb.EJBLocalHome. Svaka njegova metoda mora biti jedna od tri tipa. Create metoda Finder metoda Home metoda 20

Klasa primarnog kljua Programer mora da specificira klasu primarnog klju a. Ova klasa mora da postuje pravila za RMI-IIOP. Klasa mora da obezbedi odgovarajucu implementaciju za hashCode() i equals(Object other). Entity Bean opisiva rasporeda Unutar njega programer definise relationship elemet, u kome opisuje veze izmedju bean-ova. Bean-ovi moraju imati jedinstvena imena koja se definisu u ejb-name elementu. Takodje bean mora imati jedinstveno ime sheme koja se na njega odnosi. Programer mora unutar opisivaca rasporeda da napise EJB upit, za svaki finder metod osim za findByPrimaryKey(key). Klasa primarnog kljua Kontejner mora imati mogu nost da upravlja primarnim kljuem bean-a. Zbog toga klasa primarnog kljua mora postovati neka pravila. Primarni klju moe biti prost ili slo en klju. U oba sluaja se mora navesti polje primary-key u opisivau rasporeda, koje definise klasu primarnog kljuca. Ako je klasa slo en klju ona mora biti public, imati public konstruktor i sva njena polja moraju biti public. Takodje polja koja su deo klju a moraju biti podskup polja koja se ve nalaze kao polja unutar bean-a.

2.5.4. Message-Driven beans Pregled MessageDriven bean je asinhroni primalac poruke. Njega aktivira kontejner kad poruka stigne na odredite koje taj bean servisira. MessageDriven Bean nema Local ili Home interfejs. Unutar specifikacije EJB 2.1 MessageDriven bean-ovi mogu da podre tipove po ruka drugacije od JMS. Za kljenta, MessageDriven bean je primalac poruke koji implemetira deo poslovne logike. On nema identifikaciju poznatu korisniku, a nema ni stanje koje uva u sebi. MessageDriven bean je kreiran od strane kontejnera, kada stigne poru ka na odredite. ivotni vek bean-a kontrolie kontejner.

Ciljevi Osnovni ciljevi message-driven modela je da obezbedi bean koji e asinhrono da se poziva i obradjuje prist igle poruke. Dalji ciljevi ovog modela su da omogui konkurentnu obradu toka poruka koristei pool message-driven bean-ova.

Klijentski pogled na message-driven bean Za jednog klijenta message-driven bean je primalac poruke. Klijent jedino to zna je da alje poruku na odredjenu destinaciju. On message-bean i ne vidi, samo posalje poruku na odrediste. Klijentski JNDI moe da se podesi tako da ukljuuje vie message-driven odredita 21

na vie maina ili mrea. Sama lokacija bean-a koji e obraditi poruku je transparentna za korisnika. Message Driven Bean i kontejner Od kreiranja do unitenja MessageDriven bean postoji unutar kontejnera. Kontejner mu obezbedjuje servise za sigurnost, konkurentnost, transakcije i dr. Kontejer upravlja ivotnim ciklusom bean-a, obavetava pojavljivanja kada se deavaju pojedini dogadjaji i prua jos mnogo servisa koje omoguavaju beanu da konkurentno obradi veliki broj poruka. Kontejner ima zadatak da kreira bean prilikom starta kontejnera i pre nego to stigne prva poruka na obradu. Sva pojavljivanja Message bean-a su ekvivalentna pa stoga bilo koja moe da obradi poruku koju je klijent poslao.

Message Driven Bean interfejs Svi MessageDriven bean-ovi moraju da implementiraju interfejs MessageDrivenBean. Metoda koja mora da se implemetira setMessageDrivenContext() ima zadatak da povee pojavljivanje bean-a sa njegovim kontekstom. ejbRemove() metoda postavlja signal da je pojavljivanje u procesu uklanjanja iz kontejnera. Kada se pozove ova metoda bean oslobadja resurse koje je drao.

Message Listener interfejs Message Driven bean mora implementirati odgovarajui message listener interfejs. Ovaj interfejs odredjuje tip poruke koje e bean obradjivat i. Ako bean implementira javax.jms.MessageListener onda je taj bean JMS bean. Glavna stvar ovog interfejsa je metoda koju bean mora da implementira (u sluaju JMS to je metoda onMessage()). Ova metoda se poziva svaki put kada stigne poruka i u njoj se pie logika za obradu poruke.

Ostale karakteristike Message Driven bean opciono moe da implementira TimedObject interfejs. Ovo mu omoguava da koristi dogadjaje koji su zasnovani na vremenu i time proiri upotrebljivost bean-a. Kontejner kreira pojavljivanje message bean-a u tri faze. Prvo, kontejner poziva newInstance() i kreira novo pojavljivanje bean-a. Onda poziva setMessageDrivenContext() metodu, i na kraju poziva ejbCreate() metodu. Svaki message driven bean mora imati jednu ejbCreate() metodu, bez argumenata. Kontejner dozvoljava da se vie pojavljivanja message bean-a izvrsava istovremeno i time omoguava da se itav tok poruka obradjuje. On nema garanciju kojim e redosledom poruke biti prosledjene pojavljivanjima bean-a, pa stoga logika unutar bean-a mora raditi proveru preduslova izvrenja. Metoda message listener interfejsa se izvrsava unutar opsega transakcije koji je opisan u opisivau rasporeda. Zbog toga bean moe upravljati transakcijom tj ako se desi neka gresk a bean moe oboriti celu transakciju. 22

Dijagram stanja MessageDriven bean-a Stanjem i ivotnim vekom bean-ova upravlja kontejner. Kada poruka stigne i treba da se izvri na nekom beanu, kontejner bira jedno pojavljivanje bean-a i poziva odgovarajuu metodu. Sledei crte opisuje ivotni vek jednog bean-a.

Slika 6: ivotni ciklus Message objekta

ivotni vek jednog pojavljivanja message bean-a poinje pozivanjem tri metode newInstace(), setMessageContext(), i ejbCreate(). Posle toga bean je spreman da izvrava poruke koje su mu prosledjene. Kada pojavljivanje bean-a vie nije potrebno, kontejner poziva odgovarajuu ejbRemove() metodu i unitava pojavljivanje.

23

2.6. Perzistentnost u EJB 2.1 tehnologiji

U ovom poglavlju emo rei par stvari o realizaciji perzistentnosti u EJB 2.1 tehnologiji i EJB QL upitnom jeziku. 2.6.1. Upitni jezik EJB QL je upitni jezik za pretraivanje entity bean-ova koji koriste CMP (upravljanje perzistenciom od strane kontejnera). EJB QL moe da se kompajlira na odgovarajuci jezik, od kojih je jedan i SQL. Na ovaj nain metode koje rade upite mogu biti prenosive na razne sisteme. EJB QL koristi apstraktne sheme za entity banove, zajedno sa definiciom veza za model podataka. Upit i koji se piu u EJB QL se odnose na ovu shemu i definisane veze u opisivau rasporeda. Upiti EJB QL mogu da se parsiraju i provere ak i pre nego to se bean-ovi puste u rad (deploy).

EJB QL definicija EJB QL ima sintaksu slinu SQL koja se zasniva nad apstraktnim tipovima i vezama entity bean-ova. EJB QL je string koji se sastoji od sledeih celina: SELECT klauzula odredjuje tip objekta ili vrednosti koji se bira FROM klauzula odredjuje domen nad kojim se vri selekcija WHERE klauzula slui da suzi vrednost izbora ORDER BY klauzula koja se koristi da se sortiraju pronadjene vrednosti EJB QL se moe definisati na sledei nain:
EJB QL :: = select_ klauzula from_ klauzula [where_ klauzula] [orderby_ klauzula]

EJB QL upit mora da ima SELECT i WHERE klauzulu. Ostale klauzule su opcione i zato su postavljene u uglaste zagrade.

Metode za upit EJB QL se koristi za dva tipa metoda: Finder metode ove su metode definisane u Home ili LocalHome interfejsima. Finder metoda Home interfejsa mora vratiti objekat tipa EJBObject ili kolekciju EJBObjekata. Sa druge strane finder metoda LocalHome interfejsa mora vratiti EJBLocalObject ili kolekciju EJBLocalObjekata. Select metode ove metode slue da korisnik selektuje perzistentno stanje entiteta ili cele entitete, na nain opisan upitom. Rezultat izvrenja ove metode moe biti EJBObject, EJBLocalObject, vrednost polja bean-a i sl. 24

SELECT klauzula Select klauzula oznaava rezultat upita. Ona sadri promenljivu koja je apstraktnog tipa, putanju, ili pak agregatni select iskaz. Select klauzula ima sledeu sintaksu:
select_klauzula ::= SELECT [DISTINCT] {select_izraz | OBJECT(identifikaciona_promenljiva)}

Sve samostalne identifikacione promenljive u SELECT klauzuli moraju biti oznaene sa OBJECT operatorom. OBJECT operator se ne sme koristiti u gradjenu select_izraza.

FROM klauzula From klauzula definie domen upita deklaracijom promenljivih za identifikaciju. Ova klauzula moe da sadri vie promenljivih za deklaraciju odvojenih zarezom.
from_klauzula ::= FROM deklaracija_identifikacione_promenljive [,deklaracija_identifikacione_promenljive]

WHERE klauzula Where klauzula definie izraz koji se koristi da suzi skup vrednosti koje su rezultat upita. Ona se definie na sledei nain:
where_klauzula ::= WHERE izraz_za_stanje

2.7. Saetak
U ovom poglavlju dat je prikaz Java platforme i EJB 2.1 tehnologije. Prikazane su Java komponente, kontejneri kao i struktura Java EE aplikacija. Nakon toga su objanjeni Enterprise bean-ovi (Session bean i Message-Driven bean), kao i relizacija perzistentnosti u EJB 2.1 tehnologiji. U tom kontekstu mo emo rei da EJB tehnologija ima sledee karakteristike: EJB tehnologija predstavlja de facto standard prilikom razvoja slo enih aplikacija; EJB koristi dobre osobine aplikacionog servera (deklarativno upraljvanje transakcijama, security...); Zahteva korienje EJB kontejnera;

Na taj nain smo realizovali prvi cilj istraivanja (Dati pregled EJB 2.1 tehnologije).

25

3. EJB 3.0 TEHNOLOGIJA

U ovom poglavlju emo dati pregled EJB 3.0 tehnologije, sa naglaskom na razlike u odnosu na EJB 2.1. Bie detaljnije obradjeni enterprise bea n-ovi, perzistencija, kao i korienje anotacija za laki razvoj celokupne EJB 3.0 aplikacije.

3.1. EJB 3.0 kratak pregled

EJB 3.0 predst avlja novi uproeni API koji ima za cilj da olaka programerima razvoj sloenih (enterprise) aplikacija. Stari EJB 2.1 API ostaje prisutan radi kompatibilnosti sa postojeim programima i moe se koristiti u kombinaciji sa novim EJB 3.0 API -jem. EJB 3.0 je fokusiran na sledee ciljeve: Iskoristiti metadata anotacije kojima bi se olakao posao programerima i smanjio broj klasa koje moraju da implementiraju. Takodje je cilj smanjiti upotrebu opisivaa rasporeda, koristei pristup konfiguracije po izezetku. Ovakav pristup podrazumeva da nije potrebno pisati opisivae rasporeda ako su oni jednost avni tj podeavanje je podrazumevano . Specificirati podrazumevana podeavanja tako da programer ne mora da ih navodi. Cilj je da se iskoriste podrazumevana podeavanja u to veem broju sluajeva, jer njih programer ne mora da pie. Onde gde programer mora napisati opisivae rasporeda je neki sloeniji, nestandardan sluaj konfiguracije. Uaurenje zavisnosti EJB radne okoline i JNDI pristupa kroz korienje anotacija, ubacivanja (injection) zavisnosti, i prostih Lookup mehanizama. Uproenje enterprise bean tipova kroz eliminaciju EJB interfejsa za session bean-ove. Uproenje perzistencije kroz Java Persistence API i ukidanje obaveznih interfejsa. Uvodjenje jezika za upite za Java Persistence API, koji nasledjuje EJB QL i pro iruje ga mogunostima za operacije spajanja, podupite, group by komandu i sl. Uvodjenje klasa presretaa za session bean-ove i message driven bean-ove. Eliminisanje zahteva za implementacijom callback interfejsa. Metadata anotacije i opisivai rasporeda Jedna od kljunih t ehnologija prikazana u Javi 5.0 su anotacije. One omoguavaju programeru da oznai delove programa i na taj nain kontrolie tok i putanje u rad cele aplikacije. Anotacije omoguavaju programeru da uprosti razvoj EJB aplikacije kao i da ih koristi kao alternativa opisivaima rasporeda. Anotacije nisu obavezne i programeri koji ele da koriste opisivae rasporeda mogu to da rade. Opisivai rasporeda su opisani kao alternativa anotacijama i kao nain da se prepiu (override) podeavanja iz anotacije. 26

Bean-ovi napisani u EJB 3.0 su kompatibilni sa bean-ovima EJB 2.1. Takodje klijenti pisani u EJB 3.0 su kompatiblni sa benovima EJB 2.1, a vazi i suprotno, klijent EJB 2.1 moe da koristi EJB 3.0 bean-ove. Na taj nain je omoguena potpuna kompatibilnost sa prethodnim verzijama EJB tenologije.

3.2. Enterprise Bean klase i poslovni interfejsi

U ovom delu e biti dat kratak prikaz enterprise bean klasa, interfejsa, presretaa, konteksta i izuzetaka. 3.2.1. Enterprise Bean klasa Enterprse Bean klasa je najea komponenta (artifact) koji programer koristi. U EJB 3.0 programer najee koristi anotacije nad bean-om da bi opisao semantiku i zahteve ejb kontejnera, da bi preuzeo neke servise koje nudi ejb kontejner ili da bi opisao kako bean treba da se pusti u rad (deploy). Da bi Bean klasa mogla da se koristi mora se definisati njen tip. Ovo se tipino radi korienjem anotacija ili kao alternativa preko opisivaa rasporeda. 3.2.2. Interfejsi Unutar EJB 3.0 API poslovni interfejs je obian Java interfejs. U sluaju MessageDrivenBean-a on je odredjen tipom poruka. Za Entity Bean-ove se ne definiu interfejsi. Bean klasa moe da implementira svoj biznis interfejs. Tu vae sledea pravila: Ako bean implemetnira samo jedan interfejs podrazumeva se da je taj interfejs poslovni interfejs. Ako se ne navede njegov tip anotacijom, podrazumeva se da je Local tipa. Bean klasa moe da ima vie interfejsa. U tom sluaju svaki poslovni interfejs ponao sob mora biti definisan kog je tipa Local ili Remote. Interfejsi koji ne moraju biti definisani kao Local ili Remote su samo java.io.Serializable; java.io.Externalizable; i bilo koji interfejs definisan u javax.ejb paketu. Jedan interfejs ne moe u isto vreme biti Local i Remote interfejs. Poslovni interfejs ne sme naslediti javax.ejb.EJBObject ili javax.ejb.EJBLocalObject. Metode poslovnog intefejsa mogu baciti bilo koji izuzetak, osim java.rmi.RemoteException. Takav izuzetak e biti obraen od strane kontejnera i omotan u EJBException. 3.2.3. Presretai Presretai su metode koje presreu pozive poslovnog interfejsa ili dogadjaje ivotnog ciklusa bean-a. Presreta moe da se definie u bean klasi ili kao kla sa van bean-a koja je sa njom povezana. On se moe praviti za Session i Message driven bean-ove. Presreta se moe 27

podesiti da bude povezan sa svim poslovnim metodama ili samo sa pojedinim. Klase presretaa su oznaene anotacijom Interceptors unutar bean-a, ili preko opisivaa rasporeda. Takodje u opisivau rasporeda se moe definisati presreta za sve bean-ove u ejb-jar datoteci. Ako je potrebno jedan bean moe imati vie presretaa. U tom sluaju redosle izvavanja je oznaen redosledom navodjenja. Presreta klasa mora imati jedan javni kontruktor bez argumenata. Presretai koriste istu transaktivnost kao i poslovne metode na koje se odnose. Oni modu baciti izuzetke koji su ve potpisani u poslovnim metodama interfejsa. Mogu baciti i Runtime izuzetke. Imaju mogunost da koriste JNDI, JDBC, JMS, druge bean-ove, i Entity Manager kao i ubacivanje (injection) zavisnosti. Presretai metoda ivotnog ciklusa bean-a Metoda moe biti oznaena da prima dogadjaje zivotnog ciklusa bean-a. Za to se koriste anotacije PostConstruct, PreDestroy, PostActivate, ili PrePassivate unutar bean-a ili u opisivau rasporeda. Metode presretaa nad bean-om imaju sledei oblik void <METHOD>() dok metode nad klasom presretaa imaju oblik void <METHOD>(InvocationContext). Primer za @PreDestroy anotaciju
@Stateful public class ShoppingCartBean implements ShoppingCart { private float total; private Vector productCodes; public int someShoppingMethod(){...}; ... @PreDestroy void endShoppingCart() {...}; }

Antacije za obeleavanje metoda su iste za presretae u bean-ovima i u presreta klasama. Takodje jedna metoda moze da se poziva od strane vie anotacija tj dogadjaja. Jedana ista anotacija se ne moe postaviti na vie metoda. Presretai poslovnih metoda Presretai poslovnih metoda se definiu korienjem AroundInvoke anotacije ili pomou around-invoke taga u opisivai rasporeda. Samo jedna AroundInvoke metoda moe postojati nad bean klasom ili nad klasom presretaa. AroundInvoke metoda ne sme biti poslovna metoda. Ona se izvrava pre izvrenja poslovne metode i mora pozvati InvocationContext.proceed() jer u suprotnom nee se izvrsiti ni poslo vna metoda ni sledea AroundInvoke metoda. Ona ima potpis public Object <METHOD>(InvocationContext) throws Exception. 28

3.2.4. InvocationContext Presretai imaju svoj kontekst javax.interceptor.InvocationContext, koji se prebacuje od jedne do druge metode presretaa. Na taj nain presretai mogu da razmenjuju podatke medju sobom, ali ne i sa poslovnim metodama. Dajemo potpis tog interfejsa.
public interface InvocationContext { public Object getTarget(); public Method getMethod(); public Object[] getParameters(); public void setParameters(Object[] params); public java.util.Map<String, Object> getContextData(); public Object proceed() throws Exception; }

Metoda getTarget() vraa pojavljivanje bean-a, a getMethod() vraca metodu za koji je pozvan presreta. Metoda getParamatars() vraa listu parametara koji su prosledjeni poslovno j metodi. Metoda proceed() poziva sledeci presreta u nizu. 3.2.5. Izuzeci AroundInvoke metode se izvravaju na istom steku kao i poslovne metode. To znai da se ponaaju isto kao obine metode. One mogu bacati sve izuzetke koje mo e baciti i poslovna metoda. Programeri mogu koristiti try/catch/finaly blok da bi upravljali ovim izuzecima i samim tokom programa. AroundInvoke metode mogu da utiu na transaktivnost, tj ako AroundInvoke metoda baci izuzetak koji obara transakciju, ona e biti oborena. 3.2.6. Home interfejsi Home interfejsi nisu obavezni da se napiu za Session bean-ove u verziji EJB 3.0 tehnologije, a za entitete su potpuno izbaeni. Entiteti su sada obini Java objekti, i mogu se snimiti u bazu (perzistirati) preko EntityManagera.

3.3. Stateless Session Beans

U ovom poglavlju emo dati pregled Stateless Session Bean-ova, njihovih interfejsa i karakteristika. 3.3.1. Interfejsi Stateless Session Bean-a Poslovni interfejsi u EJB 3.0 su obini Java interfejsi, a ne EJBObject or EJBLocalObject interfejsi. U sluaju da bean implemetira WebServis dovoljna je anotacija @WebMethod da se oznae metode koje su izloene kao web servis . Takodje ovi bean-ovi ne zahtevaju Home interfejs.

29

3.3.2. Bean klasa i njene metode ivotnog ciklusa Stateless Bean klasa mora biti oznaena kao @Stateless unutar klase ili u opisivau rasporeda. Klasa ne mora da nasledjuje javax.ejb.SessionBean interfejs. Karakteristine metode ivotnog ciklusa su PostConstruct PreDestroy PostConstruct se poziva posle injekcije zavisnosti (dependency injection) a pre prvog poziva neke od poslovnih metoda bean-a. PreDestory se poziva pre nego to se pojavljivanje bean-a uniti. Sve metode ivotnog ciklusa se izvravaju u neodredjenom okviru transakcije i sigurnosti.

3.3.3. Ostale karakteristike Ako Stateless bean koristi injekciju zavisnosti ona se deava pre poziva svih metoda poslovnih i metoda ivotnog ciklusa. AroundInvoke metode se mogu koristiti nad Stateless bean-ovima i mogu biti definisane unutar bean klase ili u posebnoj klasi presretaa. Dajemo kratak primer za jedan stateless bean, koji ima jednu klasu presretaa:

@Stateless @Interceptors({ com.acme.Metrics.class, }) public class AccountManagementBean implements AccountManagement { public public public public ... } void void void void createAccount(int accountNumber, AccountDetails details) { ... } deleteAccount(int accountNumber) { ... } activateAccount(int accountNumber) { ... } deactivateAccount(int accountNumber) { ... }

public class Metrics { @AroundInvoke public Object profile(InvocationContext inv) throws Exception { long time = System.currentTimeMillis(); try { return inv.proceed(); } finally { long endTime = time - System.currentTimeMillis(); System.out.println(inv.getMethod() + " took " + endTime + " milliseconds."); } } }

30

3.3.4. Klijenstki pogled Klijenti dobijaju referencu na bean-ove preko ubacivanja (injection) zavisnosti ili preko Lookup mehanizma. Primer:
@Stateless @Interceptors({ com.acme.Metrics.class, }) public class AccountManagementBean implements AccountManagement { public void createAccount(int accountNumber, AccountDetails details) { ... } ... } public class Metrics { @AroundInvoke public Object profile(InvocationContext inv) throws Exception { } }

3.4. Stateful Session Beans

U ovom poglavlju e biti rei o bean-ovima koji imaju neko interno stanje koje treba uvati. Bie ukratko dati interfejsi bean-a i neke karakteristike. 3.4.1. Interfejsi Stateful Session Bean-a Poslovni interfejsi u EJB 3.0 su obini Java interfejsi, a ne EJBObject or EJBLocalObject interfejsi. Takodje, i ovi bean-ovi ne zahtevaju Home interfejs.

3.4.2. Bean klasa i njene metode ivotnog ciklusa StatefulBean klasa mora biti oznaena kao @Stateful unutar klase ili u opisivau rasporeda. Bean ne mora da implemetira javax.ejb.SessionBean ili java.io.Serializable interfejse. Stateful Session Bean moe da implementira SessionSynchronization interfejs. Stateful session bean ima nekoliko metoda ivotnog ciklusa: kreiranje, unitavanje, aktivacija i pasivacija. Metode su: PostConstruct PreDestroy PostActivate PrePassivate PostConstruct se poziva posle injekcije zavisnosti (dependecy injection) a pre prvog poziva neke od poslovnih metoda bean-a. 31

PreDestory se poziva pre nego to se pojavljivanje bean-a uniti. PrePassivate metoda daje signal da kontejner eli da uradi pasivizaciju pojavljivanja. PostActivate metoda daje signal da je pojavljivanje upravo aktivirana. Sve metode ivotnog ciklusa se izvravaju u neodredjenom okviru transakcije i sigurnosti.

3.4.3. Ostale karakteristike Ako statelful bean koristi injekciju zavisnosti ona se de ava pre poziva svih metoda, poslovnih i metoda ivotnog ciklusa. AroundInvoke metode se mogu koristiti nad Stateless bean-ovima i mogu biti definisane unutar bean klase ili u posebnoj klasi presretaa. Za stateful session beans koji implementiraju SessionSynchronization interfejs, afterBegin se deava pre AroundInvoke metode, a metoda beforeCompletion se poziva poto su se sve AroundInvoke metode izvrsile.

3.4.4. Klijentski pogled Remote ili Local klijent moe uzeti referencu na bean preko ubacivanja zavisnosti (dependecy injection) ili preko lookup mehanizma. Ako se stateful bean trai ekspicitno preko JNDI lookup mehanizma onda kontejner mora da obezbedi novo pojavljivanje bean-a. Ukoliko se referenca uzima preko lookup mehanizma, situacija je ista, ali klijent nema utisak da je novi bean kreiran. Tipino klijent kreira bean preko jedne ili vie poslovnih metoda. Uklanjanje stateful bean-a se oznaava korienjem Remove anotacije. Ova anotacija se stavlja iznad neke metode i kontejner zna da treba da unuti bean kad se izvri zadata metoda do kraja. Kao primer dajemo jedan jednostavan stateful bean:
@Stateful public class ShoppingCartBean implements ShoppingCart { ... private String customer; public void startToShop(String customer) { this.customer = customer; ... } public void addToCart(Item item) { ... } @Remove public void finishShopping() { ... } }

32

3.5. Message Driven Beans

U ovom poglavlju e biti rei o MessageDriven Bean-ovima i njegovim interfejsima i karakteristikama. Ovaj bean se najee koristi za asinhrono slanje poruka izmedju objekata. 3.5.1. Interfejsi Message Driven Bean-a Poslovni interfejs message-driven bean-a je message listener interfejs koji je odredjen tipom bean-a koji se koristi. U sluaju JMS ovo je javax.jms.MessageListener interfejs. MessageDriven Bean mora implementirati odgovarajui message listener interfejs odredjenog tipa, ili mora koristiti anotaciju MessageDriven unutar bean-a ili odgovarajui opis u opisivau rasporeda, koji kae da je bean message driven. 3.5.2. Bean klasa i njene metode ivotnog ciklusa MessageDriven Bean mora biti oznaen anotaciom MessageDriven ili oznaen u opisivau rasporeda kao MessageDriven. Bean klasa nije neophodno da implementira interfejs javax.ejb.MessageDrivenBean. MessageDriven Bean ima sledee metode ivotnog ciklusa: PostConstruct PreDestroy PostConstruct metoda se izvrava pre prvog poziva neke poslovne metode messa ge bean-a. U ovom trenutku celokupna injekcija zavisnosti je izvrena na kontejneru. PreDestory metoda se poziva u trenutku kada se message bean unitava ili izbacuje iz privremenog skladista (pool). Sve metode ivotnog ciklusa se izvravaju u neodredjenom okviru transakcije i sigurnosti. 3.5.3. Ostale karakteristike MessageDriven Bean moe koristiti resurse i servise kontejnera. Kontejner ove resurse ubacuje pre bilo kog poziva poslovnih metoda ili metoda ivotnog ciklusa bean-a. AroundInvoke anotacija moe da se koristi za MessaegeDriven Bean. Isto kao kod ostalih bean-ova, ova metoda moe da se navede u samom beanu ili u posebnoj klasi presretaca.

33

3.6. Perzistencija
Ovo poglavlje opisuje entitete (Entity), upravljanje njima, njihove medjusobne veze i upitni jezik koji koristi Java Persistance API (JPA). 3.6.1. Entiteti Entitet predstavlja perzistentni domenski objekat. Tipino entitet predstavlja tabelu u relacionoj bazi podataka i svako pojavljivanje entiteta predstavlja jedan slog u tabeli. Perzistentno stanje entiteta reprezentuje se korienjem perzistentnih polja ( persistent fields) ili perzistentnih svojstava (persistent properties). Pomenuta polja/svojstva koriste odreene anotacije koje omoguavaju preslikavanje entiteta i nj ihovih odnosa prema relacionim podacima koji se nalaze u odreenom sistemu za upravljanje bazom podataka. Dajemo prikaz moguih tipova perzistentnih polja i perzistentnih svojstava [JenniferBall]: 1. Java primitivni tipovi (Java primitive types); java.lang.String; 2. Drugi serializable tipovi ukljuujui java.math.BigInteger; java.math.BigDecimal; java.util.Date; java.util.Calendar; java.sql.Date; java.sql.Time; java.sql.TimeStamp; Korisniki definisani serializable tipovi; Omotai Java primitivnih tipova; byte[] Byte[] char[] Character[] 3. Enumerisani tipovi (Enumerated types) 4. Drugi entiteti ili kolekcije entiteta... Entity klasa mora zadovoljiti sledee zahteve [JenniferBall]: Klasa mora biti oznaena korienjem javax.persistence.Entity anotacije; Klasa mora imati public ili protected konstruktor bez argumenata (default konstruktor). Pored toga, klasa mo e imati i druge konstruktore (copy konstruktor); Klasa ne sme biti deklarisana kao final. Metode ili perzistentna pojavljivanja tako e ne smeju biti deklarisane kao final; Ukoliko se entity pojavljivanja prenose preko vrednosti kao odvojeni objekat (tzv. detached object), na primer koristei remote interfejs session bean-a, klasa mora implementirati Serializable interfejs;

34

Perzistentna pojavljivanja moraju biti deklarisana kao private, protected ili packageprivate i direktno im se mo e pristupiti samo iz metoda entity klase. Klijent im moe pristupiti korienjem u tu svrhu definisanih metoda (tzv. accessor metode) ili korienjem poslovnih metoda. Svaki entitet ima jedinstveni identifikator objekta. Na primer, Firma moe biti identifikovana na osnovu odgovarajueg identifikatora jer e on biti jedinstven za svaku firmu. Jedinstveni identifikator, ili primarni klju (primary key), omoguava kljentima da lociraju pojedine pojavljivanja entiteta. Svaki entitet mora imati primarni klju . Entitet moe imati ili prost ili slo en (composite) primarni klju. Dajemo primer entity klase:
@Entity @Table(name = "firma") @SequenceGenerator(name = "firma_sequence", sequenceName = "firma_id_seq") public class DOFirma implements Serializable{ private static final long serialVersionUID = 5656763945160311677L; //atributi private Long id; private String naziv; private String adresa; private String tel; private String email; private String delatnost; private String username; private String password; private String skin; @OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER, targetEntity=DOclanarinaFirme.class, mappedBy="firma") private Collection<DOclanarinaFirme> clanarine; public DOFirma() { } public DOFirma(Long _id, String _naziv, String _adresa, String _tel, String _email, String _delatnost, String _username, String _password, String _skin){ id = _id; naziv = _naziv; adresa = _adresa; tel = _tel; email = _email; delatnost = _delatnost; username = _username; password = _password; skin = _skin; } @Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "firma_sequence") public Long getId() { return id; } public void setId(Long id) { this.id = id; } public String getNaziv() { return naziv; } ostale getter i setter metode public void setNaziv(String naziv) { this.naziv = naziv; }

Prosti primarni kljuevi koriste javax.persistence.Id anotaciju kako bi naznaili public String getAdresa() { primarni klju perzistentnih polja ili perzistentnih svojstava. Slo eni primarni klju mora biti return adresa; } definisan u primary key klasi. Sloeni primarni klju oznaava se korienjem public void setAdresa(String adresa) { javax.persistence.EmbeddedId this.adresa = adresa; i javax.persistence.IdClass anotacija. Prost primarni klju , kao } i svojstvo ili polje slo enog primarnog kljua mora biti jedan od sledeih Java tipova: 1. Java primitivni tipovi; public void setTel(String tel) { 2. Omota ithis Java tipova; .telprimitivnih = tel; } java.lang.String; public String getEmail() { return email; java.util.Date ; } java.sql.Date . public void setEmail(String email) {
this.email = email; } public String getTel() { return tel; }

Sa druge strane, primary key klase moraju zadovoljiti sledee uslove [JenniferBall]: public String getDelatnost() { return delatnost; Na } in pristupa klasi mora biti public ; public void setDelatnost(String delatnost) { 35
this.delatnost = delatnost; } public String getUsername() { return username; }

Nain pristupa svojstvima mora biti public ili protected ukoliko se koristi pristup zasnovan na svojstvima (property-based access); Klasa mora imati public default konstruktor; Klasa mora implementirati hashCode() i equals(Object o) metode; Klasa mora biti serijalizovana.

3.6.1.1. Veze izmedju entiteta

Razlikujemo sledee tipove preslikavanja: one-to-one, one-to-many, many-to-one i many-tomany [MikeKeith]. One-to-one: Svako pojavljivanje entiteta je povezano sa jednim pojavljivanjem drugog entiteta. Na primer, pretpostavimo da imamo dva entiteta: Firma i ClanarinaFirme. Jedna Clanarina se odnosi na jednu i samo jednu firmu. Sa druge strane, moe se postaviti ogranienje da svaka firma moe da kupi jednu i samo jednu lanarinu. U ovom sluaju se moe koristiti one-toone preslikavanje i tada se na odgovarajue perzistentno svojstvo (ili perzistentno polje) postavlja anotacija javax.persistence.OneToOne. One-to-many: Pojavljivanje jednog entiteta moe biti povezano sa vie pojavljivanja drugog entiteta. Na primer, pretpost avimo da imamo dva entiteta: Raun i StavkaRauna. Svaka stavka rauna odnosi se na jedan i samo jedan raun. Sa druge strane, jedan raun moe imati vie stavki rauna, pri emu sigurno ima bar jednu stavku. U ovom sluaju se moe koristiti one-to-many preslikavanje i tada se na odgovarajue perzistentno svojstvo (ili perzistentno polje) postavlja anotacija javax.persistence.OneToMany. Many-to-one: Vie pojavljivanja jednog entiteta mogu biti povezana sa jednim pojavljivanjem drugog entiteta. Kao to se moe zakljuiti, ovo je suprotno od one-to-many veze. Ukoliko posmatramo prethodni primer, iz perspektive Stavke ra una relationship ka Raunu je many-to-one. U ovom sluaju se mo e koristiti many-to-one veza i tada se na odgovarajue perzistentno svojstvo ( ili perzistentno polje) postavlja anotacija javax.persistence.ManyToOne. Many-to-many: Vie pojavljivanja jednog entiteta mogu biti povezana sa vie pojavljivanja drugog entiteta. Na primer, na fakultetu svaki predmet slua i polae vei broj studenata. Sa druge strane, svaki student slua i polae vei broj predmeta. U ovom sluaju se moe koristiti many-tomany relationship i tada se na odgovarajue perzistentno svojstvo (ili perzistentno polje) postavlja anotacija javax.persistence.ManyToMany.

3.6.1.2. Dvosmerna (bidirectional) i jednosmerna (unidirectional) veza Razlikujemo dvosmernu i jednosmernu vezu. Kada je u pitanju dvosmerna veza, svaki entitet poseduje referencu i na suprotni entitet. Kod jednosmerne veze pomenuta referenca ne postoji. U dvosmernoj vezi, svaki entitet ima polje ili svojstvo koje, u stvari, predstavlja referencu na drugi entitet. Koristei pomenuto polje ili svojstvo, iz entity klase se moe pristupi do povezanog objekta. Ukoliko entity klasa ima polje ili svojstvo kaemo da entity klasa ima znanje o povezanom objektu. Dvosmerna veza mora zadovoljiti sledea pravila [JenniferBall]: Suprotna strana u dvosmernoj vezi mora imati referencu na sopstvenu stranu korienjem elementa mappedBy koji se moe koristiti u anotacijama @OneToOne, @OneToMany i @ManyToMany; Many strana u many-to-one dvosmernoj vezi ne sme definisati mappedBy element; Za one-to-one dvosmernu vezu, vlasnik (owning) strana predstavlja stranu koja sadri odgovarajui spoljni klju (foreign key); 36

Za many-to-many dvosmernu vezu svaka strana moe biti vlasnik strana. U dvosmernoj vezi, samo jedan entitet ima polje ili svojstvo koje predstavlja referencu na drugi entitet. Drugim reima, iz jednog identiteta uvek moemo doi do odgovarajueg drugog entiteta (na osnovu definisanog polja/svojstva) prvi entitet ima informacije o drugom entitetu, pri emu drugi entitet nema informacije o prvom entitetu. Na primer, Raun moe imati referencu na stavku rauna i preko njega uvek moemo doi do odgovarajuih stavki. 3.6.1.3. Upiti u zavisnosti od dvosmerne i jednosmerne veze
Java persistence upitni jezik (Java persistence query language) omoguava izvravanje upita i navigaciju kroz rezultate dobijene njihovim izvravanjem. U zavisnosti od tipa veze odreuje se da li se u upitu moe vriti navigacija od jednog entiteta ka drugom. Pretpostavimo da imamo dva entiteta: Raun i StavkaRauna. Takoe, pretpostavimo da je definisana jednosmerna veza, i da iz Rauna uvek moemo doi do stavke rauna. U tom sluaju se u upitu moe vriti navigacija od Rauna ka njegovoj stavki ali se ne moe vriti navigacija u suprotnom smeru. Meutim, ukoliko se koristi dvosmerna veza u upitu se moe vriti navigacija u oba smera.

3.6.2. Operacije nad entitetima U ovom poglavlju emo dati kako se mogu vriti neke osnovne operacije nad entitetima i rei neto o ivotnom ciklusu beana. 3.6.2.1. Entity Menager Unutar EJB 3.0 razvijen je EntityManager API kojim se upravlja ivotnim ciklusom entiteta. EntityManager je povezana sa perzistentnim kontekstom, unutar koga entitet ima svoj ivotni ciklus. Pomou EntityManager-a moemo da kreiramo, unistavamo, menjamo i pretraujemo entitete. Metode persist, merge, remove, i refresh, zahtevaju da se izvraavaju unutar otvorene transakcije. Ako im to nije obezbedjeno desie se izuzetak javax.persistence.TransactionRequiredException. Metode find() i getReference() ne zahtevaju transakciju da bi se izvrile. Objekti Query and EntityTransaction su validni dok je entity manager otvoren. Ako metoda createQuery() kao parametar ima upit koji nije u redu desie se izuzetak IllegalArgumentException. 3.6.2.2. ivotni ciklus entiteta Jedan entitet u bilo kom trenutku moe biti opisan kao novi, upravljan, nepovezan i uklonjen. Na sledeoj slici je dat ivotni ciklus entiteta i njegov dijagram prelaza stanja.

37

Slika 7: Dijagram prelaza stanja entiteta

Entitet se smatra novim (new), ako je kreiran ali nema svoj perzistentni indentet, tj jo uvek nije povezan sa perzistentnim kontekstom. Entitet je upravljan (managed) ako je povezan sa perzistentnim kontekstom. Entitet se smatra nepovezanim (detached) ako ima svoj perzistentni identitet, ali trenutno nije povezan sa njim. I na kraju entitet je obrisan (removed) ako je njegov perzistentni identitet oznaen za brisanje u bazi, ali transakcija brisanja u bazi jo nije zavrena.

Perzistiranje entiteta Entitet postaje perzistentan i upravljan pozivanjem persist metode EntityManager-a. U zavisnosti od stanja u kome se entitet nalazi, poziv persist metode e dati sledee rezultate : Ako je X novi entitet on e postati upravljan i dobie svoj zapis u bazi. Ako entitet ve postoji u bazi, operacija e biti ignorisana ali e svi entiteti koji imaju vezu sa X pozvati persist metodu, ako je cascade opcija postavljena na ALL ili PERSIST. Time e svi ti entiteti dobiti svoj zapis u bazi ako ga ve nemaju. Ako je X uklonjen entitet, pozivom persist metode on postaje upravljan. Ako je X nepovezan entitet desie se izuzetak. 38

Uklanjanje entiteta Entitet postaje uklonjen pozivanjem remove metode entity menadera. Znaenje je sledee: Ako je X novi entitet operacija se ignorie ali se poziva nad svim entitetima sa kojima je X povezan, ako je naznaena veza cascade ALL ili REMOVE. Ako je X upravljan entitet on e biti obrisan kao i svi entiteti povezani sa njim ako je cascade opcija postavljena na ALL ili REMOVE. Ako je X nepovezan entitet desie se izuzetak. Ako je X ve uklonjen operacija se ignorie. Na kraju X e biti obrisan iz baze pre ili u trenutku commit transakcije.

Sinhronizacija sa bazom podataka Stanje entiteta se sinhronizuje sa bazom na kraju commit naredbe. To podrazumeva da se u bazu upisuju promene nastale nad poljima entiteta kao i promene nad vezama. Te promene nad entitetom mogu biti nove vrednosti nad promenljivim ili promene postojecih vrednosti. Sinhronizacija se nee desiti osim ako se ne pozove refresh operacija. Sinhronizacija sa bazom se moe forsirati i to se kontrolie naredbom flush. Ona se odnosi samo na entitete koji su povezani sa perzistentnim okvirom. EntityManager i Query setFlushMode su komande kojima se kontrolie rad sinhronizacije sa bazom. FlushModeType.COMMIT komanda oznaava da se sinhrnizacija vri kad se uradi commit. Ako trenutno ne postoji aktivna transakcija flush se ne sme izvriti.

Nepovezani entiteti Nepovezan entitet se moe javiti u nekoliko sluajeva. Kada se uradi commit u sluaju kada se koristi transaktivnost i enitity menadzer iz kontejnera, kad se desi rollback, kada se oisti perzistentni kontekst, ili kada se koristi serijalizacija ili neki drugi prenos entiteta preko vrednosti. Nepovezan entitet nastavlja da postoji izvan perzistentnog kont eksta, ali njegovo stanje vie nije sinhronizovano sa stanjem u bazi. Aplikacija i dalje moe da pristupa stanjima entiteta pod uslovom da polje kome se pristupa nije oznano kao fetch=LAZY. Ako polje kome se pristupa je asocijacija, siguran nain za pistup je mogu jedino ako je asocirani objekat dostupan. Kada elimo stanje nepovezanog entitet da sinhronizujemo u bazi koristi se naredba merge. Ako je X nepovezan enitet njegovo stanje se kopira u stari ili se kreira novi entitet X. Ako je X novi entitet kreira se i novi perzistentni entitet X sa istim stanjem kao X. Ako je X obrisan, baca se izuzetak. Ako je X upravljan entitet, operacija se ignorise, ali se poziva za sve entitete povezane na X ako je cascade=MERGE i cascade=ALL. Perzistentni okvir ne sme uraditi merge nad poljima klase koja su markirana kao kasno uitavanje ( lazy loading).

39

Upravljanje pojavljivanjima Posao aplikacije je da osigura da se pojavljivanjem entiteta upravlja u samo jednom perzistentnom kontekstu. U sluaju da to nije obezbedjeno, rezultat je nepredvidjeno ponaanje. Za kontrolu da li je entitet vec povezan sa perzistentnim okvirom koristi se contains() metoda. Ona vraca true ako je entitet vraen iz baze a nije obrisan ili nepovezan, ili ako je tek kreiran a jeste pozvana persist() metoda. False ce biti vraen u sluaju kada je pojavljivanje entiteta nepovezano, kada je obrisana direktno ili preko cascade operacije, ili kad je tek kreirana a nije pozvana persist() metoda. Efekat persist() ili remove() metoda je vidljiv odmah kroz metodu contains() ali ce fizicko brisanje u bazi se desiti tek kada se uradi commit. ivotni vek perzistentnog okvira Kada se koristi okvir kojim upravlja kontejner on moe da ima trajanje koje se prostire unutar jedne transakcije ili preko vie transakcija. ivotni vek se definie kada sa instancira entity menader. Podrazumevna vrednost za ivotni vek okvira je jedna transakcija, ako se koristi entity manager kojim upravlja kontejner. Razlikujemo dva tipa okvira, okvir koji traje jednu transakciju ili okvir koji traje vie transakcija (proireni okvir).
public enum PersistenceContextType { TRANSACTION, EXTENDED }

Kada se koristi produeni okvir (EXTENDED) on postoji od kad se kreira EntityManager do kad se ne zatvori. Za to vreme moe da obradi vie transakcija. EntityManager kod produenog okvira e zadrati vezu sa entitetima i posle zavretka transakcije. To omoguava da se koriste komande persist, remove, merge, i refresh bez obzira da li je transakcija aktivna ili ne. Promene koje se dese e biti snimljene kada se okvir nadje unutar jedne transakcije i kada se desi commit. Kada se koristi EntityManager pozivanjem iz aplikacije (ne iz kontejnera) tada je ivotni vek produen. Odgovornost je na aplikaciji da upravlja ivotnim ciklusom perzistentnog okvira. Kada se desi commit transakcije sa okvirom koji traje jednu transakciju, onda svi entiteti postaju nepovezani. U sluaju da se koristi okvir koji traje vie transakcija, tada pos le commit naredbe entiteti ostaju upravljani. Kada se desi rollback bez obzira na trajanje okvira, sva pojavljivanja entiteta koja su bila upravljana ili obrisane postaju nepovezane. Stanje pojavljivanja se vraa na stanje koje je imalo u trenutku rollback poziva. Ovo u optem sluaju dovodi do nekonzistentnog stanja entiteta. Takodje, pojavljivanja koje su bile upravljane obino se ne mogu ponovo koristiti kao klasuni nepovezani entiteti.(npr generisani klju nije u redu i sl.) 3.6.3. Upitni jezik Java persistence upitni jezik definie osnovu za pisanje upita nad entitetima i njihovim perzistentnim stanjima. Upitni jezik omoguava pisanje prenosivih upita koji se mogu izvravati nezavisno od korienog sistema za upravljanje bazom podataka. Upitni jezik kao model podataka koristi apstraktne perzistentne eme entiteta, ukljuujui i njihove veze, i 40

definie operatore i izraze koji su zasnovani na takvom modelu podataka. Upitni jezik koristi sintaksu koja je veoma slina SQL upitnom jeziku (SQL-like syntax) kako bi izvrio izbor (selekciju) objekata i vrednosti zasnovanih na apstraktnoj emi tipova entiteta i njihovih veza.

3.6.3.1. SELECT upiti SELECT upit ima est klauzula: SELECT, FROM, WHERE, GROUP BY, HAVING i ORDER BY. Pri tome, SELECT i FROM klauzule su obavezne a ostale su opcione. Dajemo pojednostavljen prikaz SELECT upita korienjem BNF sintakse [JenniferBall]:
QL_statement ::= select_klauzula from_klauzula [where_klauzula][groupby_klauzula][having_klauzula][orderby_klauzula]

3.6.3.2. UPDATE i DELETE upiti UPDATE i DELETE upiti omoguavaju auriranje stanja sistema za upravljanje bazom podataka. Njima se, u stvari, odreujuju tipovi entiteta koji e biti aurirani ili izbrisani. Pri tome, ukoliko je potrebno ograniiti opseg UPDATE i DELETE operacija, moe se koristiti WHERE klauzula [JenniferBall].
update_statement :: = update_klauzula [where_klauzula] delete_statement :: = delete_klauzula [where_klauzula]

3.6.4. Metapodaci za objektno-relaciono preslikavanje (O/R Mapping) Objektno / relaciono presikavanje je deo ugovora izmedju aplikacije i domenskog modela. On predstavlja oekivanja i zahteve koje aplikaija ima prema preslikavanim enititetima u bazi. Upiti koji se piu nad bazom podataka potpuno zavise od ovog preslikavanja. Ovo presikavanje moe, ali ne mora da podri DDL naredbe nad bazom podataka. 3.6.4.1. Karakteristine anotacije za O/R presikavanje Anotacije koje se koriste se nalaze u paketu javax.persistence. Sada emo navesti neke najee koriene anotacije.

@Table @Table anotacija definise glavnu tabelu za zadati entitet. Dodatne tabele se mogu definisati anotacijama SecondaryTable i SecondaryTables. Ako se ne navede ime tabele koristi se podrazumevana vrednost, a to je ime tabele isto kao ime entiteta. 41

@Entity @Table(name = "firma") @SequenceGenerator(name = "firma_sequence", sequenceName = "firma_id_seq") public class DOFirma implements Serializable{}

@SecondaryTable @SecondaryTable anotacija definie druge tabele gde e se upisati podaci iz entiteta. Isti se koristi slino kao @Table anotacija. Ako se ne definie ova anotacija, smatra se da se podaci snimaju samo u primarnoj tabeli. Ako se ne navedu primarni kljucevi sekundarne tabele, koristie se isti kljuevi kao i u primarnoj tabeli. Tak odje se podrazumeva da se tipovi kljueva u ove dve tabele poklapaju.
@Entity @Table(name="CUSTOMER") @SecondaryTable(name="CUST_DETAIL", pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_ID")) public class Customer { ... }

@UniqueConstraint @UniqueConstraint anotacija se koristi da definie ogranienje nad poljem prilikom kreiranja tabele u bazi. Navodjenje imena kolona koje elimo da postavimo za unique je obavezno.
@Entity @Table( name="EMPLOYEE", uniqueConstraints= @UniqueConstraint(columnNames={"EMP_ID", "EMP_NAME"}) ) public class Employee { ... }

@Column @Column anotacija se koristi kada elimo da poveemo neko polje bean-a na kolonu u bazi podataka. Podrazumevana vrednost je da je ime kolone isto kao ime polja, da kolona prima null vrednost, da u nju moe da se pie i nije postavljena da bude jedinstvena. Navodimo par primera.

42

@Column(name="DESC", nullable=false, length=512) public String getDescription() { return description; } @Column(name="DESC", columnDefinition="CLOB NOT NULL", table="EMP_DETAIL") @Lob public String getDescription() { return description; } @Column(name="ORDER_COST", updatable=false, precision=12, scale=2) public BigDecimal getCost() { return cost; }

@Id anotacija @Id anotacija se koristi da se definie polje entiteta koje predstavlja primarni klju tabele. Ova anotacija se moe postaviti na entitet ili na njegovu preslikavanu super klasu. Podrazumevano ime kolone u bazi je isto kao ime polja entiteta gde je ostavljena anotacija @Id.
@Entity @Table(name = "clan") @SequenceGenerator(name = "clan_sequence", sequenceName = "clan_id_seq") public class DOClan implements Serializable { @Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "clan_sequence") public Long getId() { return id; }

@GeneratedValue @GeneratedValue anotacija se koristi za specifikaciju strategije generisanja primarnih kljueva. Ova anotacija se koristi za u kombinaciji sa @Id anotaciom, kada se definie primarni klju. Postoji 4 naina generisanja primarnog kljua TABLE, SEQUENCE, IDENTITY, AUTO. TABLE tip opisuje generisanje kljueva u tabeli koja je namenjena za to. SEQUENCE i IDENTITY opisuju korienje sekvenci iz baze kojima se generie primarni klju. AUTO tip nalae bazi da odredi koji je najbolji nain na generisanje kljueva. Ovo zavisi od same baze podataka i kako je implementirana.
@Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "clan_sequence") public Long getId() { return id; }

43

@Transient @Transient anotacija definie da odradjeno polje entiteta nije perzistento. To polje se nee uzimati u obzir prilikom perzistencije.
@Entity public class Employee { @Id int id; @Transient User currentUser; ... }

@ManyToOne @ManyToOne definie jednovrednosnu asocijaciju na drugi entitet koji ima vise prema jedan preslikavanje. Definisanje tipa drugog entiteta nije obavezno jer se to moe saznati od tipa objekta koji se referencira. Cascade element opisuje kako se operacije propagiraju medju asociranim entitetima. Postoji nekoliko tipova propagiranja ALL, PERSIST, MERGE, REMOVE, REFRESH.
@ManyToOne(cascade=CascadeType.ALL) @JoinColumn(name = "firma_id") public DOFirma getFirma() { return firma; }

@OneToOne @OneToOne anotacija definie jednovrednosnu asocijaciju prema drugom entitetu koji ima jedan prema jedan preslikavanje. Nije neophodno definisati povezanu klasu posto ce njen tip biti odredjen iz objekta koji je referenciran. Dajemo primer:
Klasa Customer @OneToOne(optional=false) @JoinColumn( name="CUSTREC_ID", unique=true, nullable=false, updatable=false) public CustomerRecord getCustomerRecord() { return customerRecord; } Klasa CustomerRecord @OneToOne(optional=false, mappedBy="customerRecord") public Customer getCustomer() { return customer; }

@OneToMany @OneToManu definie vievrednosnu asocijaciju sa jedan prema vie preslikavanjem. Sa strane jedan kada se definie kolekcija definie se i tip objeka koji se preslikava. Takodje, sa strane vie, nije potrebno definisati tip jer se on vidi iz objekta sa kojim je u vezi.

44

Klasa DOClanarinaFirme @OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER, targetEntity=DOclanarinaFirme.class, mappedBy="firma") private Collection<DOClanarinaFirme> clanarine; Klasa DOClanarinaFirme @ManyToOne(cascade=CascadeType.ALL) @JoinColumn(name = "firma_id") public DOFirma getFirma() { return firma;}

@JoinTable @JoinTable anotacija se koristi za presikavanje asocijacija. A JoinTable anotacija se postavlja na owning strani vise-prema-vie veze, ili na jednosmernim vezama jedan-prema-vie. Podrazumevano ime tabele se sastoji od imena tabela koje se spajaju, povezano donjom linijom.
@JoinTable( name="CUST_PHONE", joinColumns= @JoinColumn(name="CUST_ID", referencedColumnName="ID"), inverseJoinColumns= @JoinColumn(name="PHONE_ID", referencedColumnName="ID") )

@ManyToMany @ManyToMany anotacija definie visevrednostu asocijaciju tipa vie-prema-vie. Ako se koristi Java generics u oznaci kolekcije i tu se navede tip elemenata onda ne mora da se navodi u anotaciji. U suprotnom tip elementa mora da se navede u anotaciji. Svaka ManyToMany asocijacija ima dve strane, owning i ne-owning stranu. Ako je asocijacija dvosmerna bilo koja strana moe da se proglasi za owning.
Klasa Customer @ManyToMany @JoinTable(name="CUST_PHONES") public Set<PhoneNumber> getPhones() { return phones; } Klasa PhoneNumeber @ManyToMany(mappedBy="phones") public Set<Customer> getCustomers() { return customers; }

@OrderBy @OrderBy anotacija se koristi kada se definie kako e se elementi kolekcije sortirati, unutar viestruke veze,u trenutku kada se ita kolekcija podataka iz baze. Ako nije definisano, podrazumevano sortiranje je po primarnom kljuu.

45

@Entity public class Course { ... @ManyToMany @OrderBy("lastname ASC") public List<Student> getStudents() {...};}

@SequenceGenerator @SequenceGenerator anotacija definie generator primarnog kljua kome se moe pristupiti po imenu kada se koristi GeneratedValue anotacija. SequenceGenerator se moe definisati nad klasom entiteta ili nad poljem koje predstavlja primarni klju. Ime koje ima ovaj generator je globalno na nivou cele perzistentne jedinice. Sintaksa je sedea.
@Entity @Table(name = "firma") @SequenceGenerator(name = "firma_sequence", sequenceName = "firma_id_seq") public class DOFirma implements Serializable{

3.7. Enterprise Bean kontekst i okolina

Kontekst enterprise bean-a se sastoji od konteksta kontejnera i konteksta okoline (environment). Bean moe da pristupa referencama resursa i drugim delovima okoline u svom kontekstu, tako to mu kontejner obezbedi potrebne reference. Kao alternativa moze se koristiti lookup metoda dodata u javax.ejb.EJBContext interfejs ili JNDI API da se pristupi eljenom resursu iz okoline bean-a. Anotacija promenljivih iz konteksta Jedan bean deklarie da e koristiti neke resurse iz okoline koristei anotaciju. Ova anotacija definie tip objekta ili resursa koji je potreban beanu, njegove karakteristike i ime pod koj im mu se moze pristupiti. Evo nekih primera: @EJB(name="mySessionBean", beanInterface=MySessionIF.class) @Resource(name="myDB", type=javax.sql.DataSource.class) Anotacije se mogu postaviti na samu klasu bean-a ili na njegove promenljive ili metode. Anotacija pojavljivanja promevljivih Programer moe da oznai promenljive bean-a koje predstavljaju promenljive iz njegove okoline. Kontejner e proitati ove oznake i obezbediti bean-u odgovarajue promenljive iz okoline. Ovo se deava pre bilo kog poziva poslovne metode bean-a.

46

Primer :
@Stateless public class MySessionBean implements MySession { @Resource(name="myDB") //type is inferred from variable public DataSource customerDB; @EJB //reference name and type inferred from variable public AddressHome addressHome; public void myMethod1(String myString){ try{ Connection conn = customerDB.getConnection(); ... } catch (Exception ex){ ... } } public void myMethod2(String myString){ Address a = addressHome.create(myString); } }

Kada se tip resursa moe odrediti iz tipa promenljive anotacija ne mora da sadri tip objekta kojem pristupa. Ako je naziv promeljive isti kao naziv resursa u okolini onda ni on ne mora da se navodi. Primer: @EJB public ShoppingCart myShoppingCart; @Resource public DataSource myDB; @Resource public UserTransaction utx; @Resource SessionContext ctx;

Setter injection Setter injekcija predstavlja alternativu inicijalizaciji promenljivih od strane kontejnera. Kada se koristi injekcija preko setter metoda onda se anotacije odnose na setter metode bean-a, definisane za tu svrhu. Vai isto pravilo kao za anotaciju promenljivih. Kada se tip resursa mo e odrediti iz tipa promenljive anotacija na setter metodi ne mora da sadri tip objekta kojem pristupa. Ako je naziv promeljive isti kao naziv resursa u okolini onda ni on ne mora da se navodi. Setter metode koje su anotirane e biti pozvane i promenljive e dobiti neku vrednost, pre bilo kog poziva poslovne ili metode ivotnog ciklusa.

47

Primer:

@Resource(name=customerDB) public void setDataSource(DataSource myDB) { this.ds = myDB; } @Resource // reference name is inferred from the property name public void setCustomerDB(DataSource myDB) { this.customerDB = myDB; } @Resource public void setSessionContext(SessionContext ctx) { this.ctx = ctx; }

Resursi, reference na komponente, i drugi objekti koji se mogu na i u JNDI name space-u, mogu biti ubaceni unutar bean gorenavedenim metodama injekcije. JNDI name space koji se gleda je java:comp/env. Kada je beanu potrebno da nadje neke objekte izvan sopstvenog konteksta, on mo e da koristi metodu Object lookup(String name), koja je dodata u javax.ejb.EJBContext interfejs.

3.8. Kompatibilnost i migracija

Jedan od bitnih zahteva koji je postavljen pred EJB 3.0 je da bude kompatibilan unazad sa verzijom EJB 2.1. Ovaj zahtev je vrlo realan jer mnogi sistemi ve uveliko rade na EJB 2.1 i neprihvatljivo je odbaciti celokupan stari sistem prilikom prelaska na novu verziju tehnologije. EJB 3.0 uspesno izveo zahtev za kompatibilnost. Aplikacije razvijene u EJB 2.1 rade bez izmena na EJB 3.0 kontejneru. Ovo omogucava da se postojeci sistem prenese u novi kontejner i da se nastavi razvoj korienjem nove tehnologije. Postojei sistem me mora da se menja. Nove aplikacije mogu da budu klijenti starim bean-ovima. Isto tako, stari klijenti mogu da koriste nove bean-ove, bez izmene klijentskog pogleda. Dosta osobenosti EJB 3.0 tehnologije moe se koristiti na EJB 2.1 komponentama, naravno uz uslov da se koristi EJB 3.0 kontejner. Neke od tih osobina su: injection, klase presretaa, transaktivne i bezbednosne anotacije, callback anotacije i sl.

EJB 3.0 klijent / EJB 2.1 komponente Bean-ovi napisani u EJB 3.0 mogu da budu klijenti starim bean-ovima. Na taj nain se postie ponovno koriscenje komponenata, migracija deo po deo i zahvaljujui injekciji uproenje klijentskog pogleda.

48

EJB 2.1 klijent / EJB 3.0 komponente Stari klijenti napisani u EJB 2.1 mogu da komuniciraju sa novim komponentama. Prilikom unapredjenja verzije (update) serverske komponente mogu da se menjaju bez ikakve promene na postojecem klijentu. Nove komponente mogu da podravaju i EJB 3.0 i starije klijente. Home i poslovni interfejsi su preslikani na bean klasu.

Takodje, entity bean-ovi iz EJB 2.1 se mogu koristiti zajedno sa EJB 3.0 entitetima ili sa entity menaderom unutar iste transakcije.

Adaptiranje EJB 3.0 Session Bean-ova na ranije verzije klijenata Problem kompatibilnosti sa starim klijentima je taj to ovi klijenti o ekuju postojanje Home i Component interfejsa. EJB 3.0 bean-ovi se vrlo lako mogu modifikovati da budu kompatibilni sa starim klijentima. Dovoljno je da bean-ovi iskoriste anotacije RemoteHome i LocalHome. Kada je u pitanju StatelessSessionBean poziv create() metode mora vratiti Local ili Remote interfejs bean-a. Sam bean moe a ne mora biti kreiran, to zavisi od implementacije kontejnera. Kontejner moe da koristi neko keiranje podataka (data pooling) ili kasnu inicijalizacju. Ipak kad se pozove create() metoda poziva se i PostConstruct dogadjaj. Takodje, kad se poziva remove() metoda pozvae se i PreDestroy dogadjaj. Kada je u pitanju StatefulSessionBean, kada se pozove create() metoda izaziva kreiranje beana i lanac izvrenja poziva PostConstruct, i odgovarajucu Init metodu. Kao rezultat klijentu se vraca odgovarajuci local ili remote interfejs nad bean-o m. Ove metode se izvravaju u istoj transakciji i sigurnosnom okviru kao i create() metoda. Kada se poziva remove() metoda , poziva se i PreDestroy metoda i onda kontejer uklanja bean. Init anotacija se koristi da se definise veza izmedju create() metode interfejsa i odgovarajuce metode bean-a.

3.9. Metadata anotacije

Ovde emo izneti neke najee anotacje koje se koriste u novom EJB 3.0 API -ju. Bice date njihove definicije i kratak opis gde se koriste. 3.9.1. Anotacije za EJB Bean-ove U ovom poglavlju e biti rei o anotacijama koje se najee kor iste za EJB bean-ove. Ove su uvedene u verziji EJB 3.0 i znatano oloakavaju rad sa EJB bean-ovima. Stateless Bean Anotacija Stateless se koristi da se bean definie kao Stateless bean. Ova anotacija se postavlja na klasu koja predstavlja bean. Dajemo definiciju anotacije:

49

@Target(TYPE) @Retention(RUNTIME) public @interface Stateless { String name() default ""; String mappedName() default ""; String description() default ""; }

Anotacioni element name mora biti jedinstven unutar ejb-jar. Podrazumevana vrednost mu je ime same klase koja predstavlja bean, mada se mo e eksplicitno promeniti. Anotacioni element mappedName je ime na koje je preslikavan session bean. Aplikacije koje koriste preslikavana imena nisu prenosive.

Stateful Bean Anotacija Stateful se koristi da se bean definie kao Stateful bean. Ova anotacija se postavlja na klasu koja predstavlja bean. Dajemo definiciju anotacije:
@Target(TYPE) @Retention(RUNTIME) public @interface Statelful { String name() default ""; String mappedName() default ""; String description() default ""; }

Anotacioni element name mora biti jedinstven unutar ejb-jar. Podazumevana vrednost mu je ime same klase ko ja predstavlja bean, mada se moe eksplicitno promeniti. Anotacioni element mappedName je ime na koje je preslikavan session bean. Aplikacije koje koriste preslikavana imena nisu prenosive. Kod Stateful bean-ova koristi se i Init anotacija da bi sa povezala neka metoda bean-a sa create() metodom. Ovo je potrebno da bi se omoguila kompatibilnost sa klijentima EJB 2.1. Parametri metode koja je anotirana kao Init moraju biti isti kao parametri u create() metodi.
@Target(METHOD) @Retention(RUNTIME) public @interface Init{ String value() default ""; }

Value element mora biti definisan ako Home interfejsi imaju vie create<METHOD> metoda. Na taj nain anotacija zna na koji create() metod treba da se povee. Ako Stateful bean obezbedjuje RemoteHome ili LocalHome interfejse, onda mora imati bar jednu Init anotaciju. Ako ima vie create() metoda, Init anotacija mora imati value element definisan.

50

Jo jedna karakteristika Stateful bean-a je da ima Remove metodu. Kada se ova metoda izvri, kontejner e pozvati PreDestroy metodu a potom unistiti bean. Polje retainIfException, omoguava da se bean ne unistava ako se desi neki izuzeak.
@Target(METHOD) @Retention(RUNTIME) public @interface Remove{ boolean retainIfException() default false; }

MessageDriven Bean MessageDriven anotacija se koristi kad elimo da definiemo da je bean MessageDriven tipa. Ova anotacija se postavlja nad klasom. Anotacioni element name mora biti jedinstven unutar ejb-jar. Podazumevana vrednost mu je ime same klase koja predstavlja bean, mada se moze eksplicitno promeniti. Karakteristika MessageDriven bean-a je da ima odredjeni messageListenerInterface element. On mora biti postavljen u beanu ako bean vec ne implementira message interfejs ili ako implementira vise od jednog interfejsa koji mogu predstavljati MessageListener interfejs.
@Target(TYPE) @Retention(RUNTIME) public @interface MessageDriven { String name() default ""; Class messageListenerInterface() default Object.class; ActivationConfigProperty[] activationConfig() default {}; String mappedName() default ""; String description() default ""; } @Target({}) @Retention(RUNTIME) public @interface ActivationConfigProperty { String propertyName(); String propertyValue(); }

Anotacije Local i Remote se koriste samo na session bean-ovima. Remote anotacija se moe postaviti na bean ili na njegov interfejs i na taj nain se oznaava Remote interfejs. Isto vai i Local anotaciju. Local anotacija mora da se koristi jedino ako bean klasa imlepentira vie interfejsa, pa se na taj nain definie koji interfe js predstavlja Local interfejs i to preko value elementa.

@Target(TYPE) @Retention(RUNTIME) public @interface Remote { Class[] value() default {}; // list of remote business interfaces } @Target(TYPE) @Retention(RUNTIME) public @interface Local { Class[] value() default {}; // list of local business interfaces }

51

Anotacija RemoteHome i LocalHome se mogu primeniti samo na session bean-ove. Ove anotacije se koriste u svrhu kompatibilnosti EJB 3.0 sa klijentima koji oekuju postojanje RemoteHome i LocalHome interfejsa.
@Target(TYPE) @Retention(RUNTIME) public @interface RemoteHome { Class value(); // home interface } @Target(TYPE) @Retention(RUNTIME) public @interface LocalHome { Class value(); // local home interface }

3.9.2. Anotacije za transakcije TransactionManagement anotacije definiu kako e se upravljati transakcijama, i definiu se nad Session i MessageDriven bean-ovima. Ako ova anotacija nije navedena podrazumevana vrednost je da transakcijom upravlja kontejner. Tipovi transakcije mogu biti container i bean, tj transakciom moze upravljati kontejner ili se to ostavlja programeru koji pie bean.
@Target(TYPE) @Retention(RUNTIME) public @interface TransactionManagement { TransactionManagementType value() default TransactionManagementType.CONTAINER; } public enum TransactionManagementType { CONTAINER, BEAN }

Anotacija TransactionAttribute definie da li e odredjena metoda biti pozvana unutar jedne transakcije. Ova anotacija zahteva da se kao tip transaktivnosti koristi transaktivnost preko kontejnera. TranasctionAttribute se moe postaviti na ceo bean ili samo na pojedinu metodu . U sluaju da postoje obe postavke, bie koriena postavka nad metodom. Podrazumevana vrednost za ovu anotaciju je REQUIRED.
public enum TransactionAttributeType { MANDATORY, REQUIRED, REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED, NEVER } @Target({METHOD, TYPE}) @Retention(RUNTIME) public @interface TransactionAttribute { TransactionAttributeType value() default TransactionAttributeType.REQUIRED; }

52

3.9.3. Anotacije za presretae i ivotni ciklus bean-a Interceptors anotacija slui da se definie jedna ili vie klasa presretaa. Ova anotacija se postavlja na bean klasu ili na poslovnu metodu. Anotacija koja se postavlja na poslovnu metodu je AroundInvoke. Postoji anotacija javax.interceptor.ExcludeDefaultInterceptors, kojom se definie da ne elimo da ukljuimo podrazumevane presretae. Takodje anotacija javax.interceptor.ExcludeClassInterceptors omoguava da se iskljui presreta na nivou klase, s tim to podrazumevani presreta ostaje.

package javax.interceptor; @Target({TYPE, METHOD}) @Retention(RUNTIME) public @interface Interceptors { Class[] value(); } package javax.interceptor; @Target({METHOD}) @Retention(RUNTIME) public @interface AroundInvoke {} package javax.interceptor; @Target({TYPE, METHOD}) @Retention(RUNTIME) public @interface ExcludeDefaultInterceptors {} package javax.interceptor; @Target({METHOD}) @Retention(RUNTIME) public @interface ExcludeClassInterceptors {}

Anotacije za ivotni ciklus bean-a se koriste kada elimo da se neka metoda bean-a izv i prilkom kreiranja ili pre unistavanja bean-a. Anotacije koje se koriste su sledee:

package javax.annotation; @Target({METHOD}) @Retention(RUNTIME) public @interface PostConstruct {} package javax.annotation; @Target({METHOD}) @Retention(RUNTIME) public @interface PreDestroy {} package javax.ejb; @Target({METHOD}) @Retention(RUNTIME) public @interface PostActivate {} package javax.ejb; @Target({METHOD}) @Retention(RUNTIME) public @interface PrePassivate {}

53

3.9.4. Anotacije za izuzetke, zatitu pristupa i timeout Timeout anotacija slui da ogranii vreme izvrenja metode bean-a.
@Target({METHOD}) @Retention(RUNTIME) public @interface Timeout {}

AplicationException anotacija se koristi da se odredjni izuzetak oznai kao aplikacioni i da se ne obmotava od strane kontejnera. Rollback element slui da opie da li e transakcija biti oborena ako se desi taj izuzetak.
@Target(TYPE) @Retention(RUNTIME) public @interface ApplicationException { boolean rollback() default false; }

Anotacije za sigurnost definiu ko i kako moe da pristup i metodama bean-a. Za pristup metodama se mogu koristiti anotacije RolesAllowed, koja oekuje da se navede spisak rola koje su dozvoljene. Ova anotacija se moe definisati nad klasom bean-a ili nad poslovnom metodom. U prvom sluaju e vaiti nad svim poslovnim metodama bean-a, a u drugom samo na metodi gde je definisana.
package javax.annotation.security; @Target({TYPE, METHOD}) @Retention(RUNTIME) public @interface RolesAllowed { String[] value(); }

PermitAll anotacija definie da metodu ili sve metode moe da izvri bilo ko. I ova anotacija moe da se definie nad celim bean-om ili samo za metodu. U sluaju da se koriste obe definicije podeavanje na metodi e biti uzeto u obzir.
package javax.annotation.security; @Target ({TYPE, METHOD}) @Retention(RUNTIME) public @interface PermitAll {}

DenyAll anotacija zabranjuje pravo izvrenja bilo kome, za zadati bean ili klasu. Vae slina pravilia kao i za PermitAll.
package javax.annotation.security; @Target (METHOD) @Retention(RUNTIME) public @interface DenyAll {}

54

RunAs anotacija definie ime korisnike uloge koju ce bean nositi. Postavlja se na nivo beana.
package javax.annotation.security; @Target(TYPE) @Retention(RUNTIME) public @interface RunAs { String value(); }

3.9.5. Anotacije za EJB reference i Resource reference EJB anotacija se koristi kad bean eli da uzme pokaziva na neki Local ili Remote bean interfejs. Name polje predstavlja ime koje se trai u EJB okolini. BeanName je ime bean-a koje je preslikavano na name polje. BeanName omoguava da se uzme pravi bean ako vie bean-ova implemetira isti interfejs.
@Target({TYPE, METHOD, FIELD}) @Retention(RUNTIME) public @interface EJB { String name() default ""; Class beanInterface() default Object.class; String beanName() default ""; String mappedName() default ""; String description() default ""; } @Target(TYPE) @Retention(RUNTIME) public @interface EJBs { EJB[] value(); }

Resource anotacija se koristi kada bean eli da pristupi resursima izvan svog bean konteksta. Ovo se najee koristi za pristup bazama i td. Name polje je ime resursa u okolini, authenticationType definie ko proverava pristup, a shareable da li je resurs deljiv.

55

package javax.annotation; @Target({TYPE, METHOD, FIELD}) @Retention(RUNTIME) public @interface Resource { public enum AuthenticationType { CONTAINER, APPLICATION } String name() default ""; Class type() default Object.class; AuthenticationType authenticationType() default AuthenticationType.CONTAINER; boolean shareable() default true; String mappedName() default ""; String description() default ""; } package javax.annotation; @Target(TYPE) @Retention(RUNTIME) public @interface Resources { Resource[] value(); }

3.10. Saetak
U ovom poglavlju smo dali kratak prikaz EJB 3.0 tehnologije. Naglasak je stavljen na korienje anotacija, i razlike koje postoje u odnosu na prethodnu verziju EJB 2.1. Na osnovu toga moemo doneti sledee zakljuke: Korienje Entity klasa EJB 3.0 tehnologije je sada mogue van aplikacionog servera; EJB tehnologija preuzima dobre osobine drugih tehnologija; EJB tehnologija je u novoj verziji EJB 3.0 znaajno pojednostavljena i unapreena; Zahteva korienje EJB kontejnera.
Na taj nain smo realizovali drugi cilj istraivanja (Dati pregled EJB 3.0 tehnologije).

56

4. SOFTVERSKE METRIKE
U ovom pogalavlju emo opisati ISO standard koji se koristi za merenje kval iteta softvera. Pomenuemo softverske metrike kao i softverske alate za merenje kvaliteta softvera.

4.1. ISO standardi

ISO (International Organization for Standardization) i IEC (International Electrotechnical Commision) predstavljaju meunarodne organizacije ije je delovanje usmereno na uspostavljanje meunarodnih standarda u razliitim oblastima. Ni oblast softverskog inenjerstva nije izostala. Za nju je posebno znaajan standard ISO/IEC 9126 koji prouava softverske metrike i sastoji se iz etiri dela: ISO/IEC 9126-1 prouava model kvaliteta (Quality model); ISO/IEC 9126-2 prouava eksterne softverske metrike (External metrics); ISO/IEC 9126-3 prouava interne softverske metrike (Internal metrics); ISO/IEC 9126-4 prouava kvalitet u softverskim metrikama (Quality in use metrics); 4.1.1. ISO/IEC 9126-1 Primena softverskih sistema u dananjem poslovanju je prilino raznovrsna pa se moe rei da je njihov pravilan rad kljuan za poslovni uspeh i/ili za ljudsku bezbednost. Stoga je razvoj i izbor visoko kvalitetnog softverskog proizvoda od velike vanosti. Da bi se osigurao odgovarajui kvalitet neophodno je na pravilan nain izvriti specifikaciju i evaluaciju kvaliteta softvera. Ovo se moe postii definisanjem odgovarajuih atributa kvaliteta softvera, uzimajui u obzir svrhu korienja softvera. Kao to se moe zakljuiti, potrebno je da se svaki relevantni atribut softverskog proizvoda specificira i evaluira korienjem prihvaenih softverskih metrika. Standard ISO/IEC 9126-1 definie atribute softverskog sistema u est kategorija [ISO9126_1]: 1. Funkcionalnost (Functionality); 2. Pouzdanost (Reliability); 3. Upotrebljivost (Usability); 4. Efikasnost (Efficiency); 5. Odravanje (Maintainability) i 6. Prenosivost (Portability). Svaka kategorija sadri elemente koji se mogu izmeriti korienjem internih ili eksternih softverskih metrika to je i prikazano na Slici 8.

57

Slika 8: Model kvaliteta [ISO9126_1] U okviru Funkcionalnosti razlikujemo sledee podkategorije: Pogodnost (suitability); Tanost (accuracy); Interoperabilnost (interoperability); Sigurnost (security) i Mogunost usaglaavanja funkcionalnosti sa standardima ( functionality compilance). U okviru Pouzdanosti razlikujemo sledee podkategorije: Zrelost (maturity); Tolerantnost na greke (fault tolerance); Mogunost povratka (recoverability) i Mogunost usaglaavanja pouzdanosti sa standardiima ( reliability compilance). U okviru Upotrebljivosti razlikujemo sledee podkategorije: Razumljivost (understendability); Mogunost uenja (learnability); Operativnost (operability); Atraktivnost (attractiveness) i Mogunost usaglaavanja upotrebljivosti sa standardiima ( usability compilance). U okviru Efikasnosti razlikujemo sledee podkategorije: Vremensko ponaanje (time behaviour); Upotreba resursa (resource utilisation) i Mogunost usaglaavanja efikasnosti sa standardiima ( reliability compilance).

58

U okviru Odravanja razlikujemo sledee podkategorije: Mogunosti analize (analysability); Mogunosti promena (changeability); Stabilnost (stability); Mogunost testiranja (Testability) i Mogunost usaglaavanja odravanja sa standardiima (maintainability compilance). U okviru Prenosivosti razlikujemo sledee podkategorije: Adaptivnost (adaptability); Mogunost instalacije (installability); Zajedniko postojanje (co-existence); Mogunost zamene (replaceability) i Mogunost usaglaavanja prenosivosti sa standardiima ( portability compilance). Definisane karakteristike su primenljive na svaku vrstu softvera i na taj na in obezbeuju konzistentnu terminologiju za definisanje kvaliteta softverskog proizvoda, kao i okvir (framework) za specificiranje zahteva za kvalitetom softvera.

4.1.2. ISO/IEC 9126-2 Pre poetka korienja softverskog sistema potrebno je izvriti njego vu evaluaciju korienjem softverskih metrika. Ta evaluacija je zasnovana na poslovnim ciljevima koji su povezani sa upotrebom i upravljanjem softverskim proizvodom u specificiranom tehni kom i organizacionom okruenju. Standardom ISO/IEC 9126-2 definiu se eksterne softverske metrike koje se koriste za merenje performansi softverskog sistema. Za svaki atribut softverskog sistema u potpunosti je definisana metrika: naziv metrike, njena svrha, na in korienja, formula, interpretacija izmerenih vrednosti, koriena merna skala, tip mere... Tako, na primer, ukoliko posmatramo Odr avanje (Maintainability), i u okviru njega Mogunosti promena (Changeability) razlikujemo sledee eksterne softverske metrike:

59

Maintainability

Changeability

Software change control capability

Parametrised modifability

Modification complexity

Change cycle efficiency

Change implementation elapse time

Slika 9: Eksterne Softverske metrike definisane za podkategoriju Changeability [ISO9126_2]

Na primer metrika Mogunost promene preko parametra (Parameterised modifiability) je definisana na sledei nain (dajemo pojednostavljeni prikaz) [ISO9126_2]:

Naziv metrike Mogunost promene preko parametra (Parameterised modifiability)

Svrha metrike Da li se na jednostavan nain moe promeniti odreeni parametar softverskog sistema kako bi se na taj nain reio odreeni problem?

Formula X=1-A/B, Pri emu je A broj sluajeva u kojima se softver ne moe promeniti preko parametra; B broj sluajeva u kojima se pokuava promena softvera preko parametra.

Interpretacija izmerene vrednosti 0<=X<=1 Bolje je ukoliko vrednost X tei 1. U tom sluaju je mogunost promene softvera preko parametra vea.

Tabela 2: Pojednostavljeni prikaz metrike Parametrised modifiability

4.1.3. ISO/IEC 9126-3 Standard ISO/IEC 9126-3 definie interne softverske metrike. Interne softverske metrike se mogu primeniti na softverski proizvod u toku projektovanja i pisanja programskog koda. Primarni zadatak ovih metrika je da osiguraju da e postii odreeni eksterni kvalitet (external quality) i kvalitet u upotrebi (quality in use) softverskog proizvoda. Tako, na primer, ukoliko posmatramo Odravanje (Maintainability), i u okviru njega Mogunosti promena (Changeability) razlikujemo sledee interne softverske metrike: 60

Maintainability

Changeability

Change recordability

Slika 10: Interne Softverske metrike definisane za podkategoriju Changeability [ISO9126_3]

Metrika Pamenje promena (Change recordability) je definisana na sledei nain (dajemo pojednostavljeni prikaz) [ISO9126_3]:

Naziv metrike Pamenje promena (Change recordability)

Svrha metrike Da li su promene u specifikaciji softverskog sistema i promene u programskim modulima na odgovarajui nain zabeleene u programskom kodu, sa odgovarajuim komentarima?

Interpretacija izmerene vrednosti X=A/B, 0<=X<=1 Pri emu je A Broj Ukoliko vrednost X promena u tei 1, promene su funkcijama/modulima bolje zabeleene. koji imaju promenjene Ukoliko vrednost X komentare potvrene u tei 0, promene su reviziji; B Ukupan slabije zabeleene ili je broj funkcija/modula izvreno malo promena koji su promenjeni; (visoka stabilnost).

Formula

Tabela 3: Pojednostavljeni prikaz metrike Change recordability

61

4.1.4. ISO/IEC 9126-4 ISO/IEC 9126-4 prouava kvalitet u softverskim metrikama (Quality in use metrics). Drugim reima, na ovaj nain se moe utvrditi da li softverski proizvod zadovoljava specifine potrebe korisnika kako bi se postigli odreeni ciljevi u pogledu efektivnosti, produktivnosti, bezbednosti i zadovoljstva korisnika. U tom kontekstu ISO/IEC 9126-4 definie sledee grupe metrika [ISO9126_4]: Metrike za utvrivanje efektivnosti (Effectiveness metrics) procenjuju da li su zadaci koje su izvrili korisnici doveli do postizanja specifinih ciljeva, pri emu se u obzir uzima tanost i kompletnost u specifinom kontekstu primene; Metrike za utvrivanje produktivnosti (Productivity metrics) procenjuju da li su resursi koje upotrebljavaju korisnici u relaciji sa postignutom efektivnou u specifinom kontekstu primene; Metrike za utvrivanje sigurnosti (Safety metrics) procenjuju nivo rizika koji moe dovesti do povrede ljudi, poslovanja, softvera ili okruenja u specifinom kontekstu primene; Metrike za utvrivanje zadovoljenja (Satisfaction metrics) procenjuju odnos korisnika prema korienju softverskog proizvoda u specifinom kontekstu primene. Na primer, razlikujemo sledee Metrike za utvrivanje efektivnosti (Effectiveness metrics):

Effectivness metrics

Task effectivness

Task completion

Error frequency

Slika 11: Metrike za utvrivanje efektivnosti [ISO9126_4]

62

Metrika Frekvencija greke (Error frequency) definisana je na sledei nain (dajemo pojednostavljeni prikaz) [ISO9126_4]:

Naziv metrike Frekvencija greke (Error frequency)

Svrha metrike Potrebno je utvrditi frekvenciju greaka koje se mogu javiti pri korienju softvera od strane korisnika.

Formula X=A/T, pri emu je A Broj greaka koje napravi korisnik pri korienju softvera; T vreme ili broj zadataka koje izvrava korisnik.

Interpretacija izmerene vrednosti X >=0 Bolje je ukoliko vrednost X tei 0. U tom sluaju je broj greaka koje napravi korisnik pri korienju softvera manji.

Tabela 4: Metrika Frekvencija greke

4.2. Swat4j i Analyst4j

Swat4j [ZWSwat4j] je softverski paket namenjen praenju i upravljanju aktivnostima razvoja i odravanja softverskog sistema koji je napisan u programskom jeziku Java. On je zasnovan na principima standarda ISO/IEC 9126-1 (Quality model) i ISO/IEC 9126-3 (Software Product Quality, Internal Metrics). Softverskim paketom definisani su sledei atributi kvaliteta softvera [ZWSwat4j]: Testiranje (Testability); Kvalitet projektovanja (Design quality); Performanse (Performance); Razumljivost (Understandability); Odravanje (Maintainability) i Ponovno korienje (Reusability). Takoe, softverski paket se moe koristiti za pronalaenje potencijalnih greaka ( bugs) u programu. U okviru Swat4j je integrisano preko 30 metrika (metrike su prilagoene karakteristikama programskog jezika Java) i preko 100 industrijskih standarda koji se odnose na pravila najbolje prakse u pisanju programskog kda (Best Practise Rules). Prema predefinisanom modelu kvaliteta softvera, za svaki atribut softverskog sistema vezano je vie metrika, odnosno vie pravila u pisanju programskog kda. Sa druge strane, jedna metrika, odnosno jedno pravilo, moe se odnositi na vie atributa softverskog sistema, to je i prikazano na Slici 12.

63

Slika 12: Odnos izmedju atributa softverskog sistema, softverskih metrika i pravila u pisanju programskog koda

Osiguranje kvaliteta programskog kda ne predstavlja opcionu aktivnost ni za jednu sofversku kompaniju. U krajnjem sluaju defekat u softverskom sistemu moe izazvati velike probleme, npr. poveanje trokova odravanja softvera, to moe dovesti do nezadovoljstva krajnjih korisnika. Kontrola Entropije programskog kda predstavlja veliki izazov (i teak zadatak) za svakog projekt menadera. Jedna od metoda koju koriste mnoge organizacije je pridravanja standarda u pisanju programskog kda to obezbeuje unformnost i prati najbolje prakse pisanja programskog kda kako bi se, u skladu sa definisanim modelom kvaliteta, ocenili atributi softverskog sistema. Ipak, u velikom broju sluajeva to je mnogo lake rei nego uraditi iz prostog razloga to kvalitet moe razliitim ljudima znaiti razliite stvari. U tom kontekstu, termin kvalitet moe biti prilino dvosmislen ukoliko se pravilno ne definie. Moemo rei da Swat4j sadri sledee grupe metrika: Objektno-orijentisane metrike (Object-oriented metrics) omoguavaju merenje kvaliteta objektnog projektovanja, veza i zavisnosti izmeu objekata, kao i drugih principa: 1. Sloenost ponderisanih metoda (Weighted Methods Complexity WMC) - WMC se definie kao suma sloenosti metoda; 2. Broj odgovora klase (Response For Class RFC) - Definie skup svih metoda koje mogu biti pozvane kao odgovor na poruku objekta klase; 3. Nedostatak kohezivnosti metoda u klasi (Lack Of Cohesive Methods LCOM) Predstavlja meru meusobne povezanosti (bliskosti) metoda; 4. Povezanost objekata (Coupling Between Object CBO) - CBO se zasniva na ideji da je objekat povezan sa drugim objektom ukoliko jedan objekat koristi osobine i metode drugog objekta (na primer, metoda prvog objekta koristi metode ili pojavljivanja drugog objekta); 5. Dubina stabla nasleivanja (Depth of Inheritance Tree DIT) - Dubina klase u hijerarhiji nasleivanja definie se kao maksimalni broj nivoa od posmatranog vora do korena drveta; 6. Broj podklasa (Number of Children NOC) - NOC rauna broj neposrednih podklasa posmatrane klase/interfejsa u hijerarhiji klasa. 64

Metrike za odreivanje sloenosti (Complexity metrics) Sloenost sistema ili njegovih komponenti predstavlja teinu razumevanja softverskog sistema ili komponenti softverskog sistema. Razlikujemo sledee metrike za odreivanje sloenosti: 1. Ciklina sloenost (Cyclomatic Complexity McCabe) - Ciklina sloenost softverskog sistema se meri raunanjem broj taaka odluivanja (decision points) ili uslovnih iskaza (conditional statements) posmatranog programskog jezika; 2. Halstedova sloenost (Halstead Complexity Metrics) - Slui za merenje sloenosti modula direktno iz izvornog kda programa korienjem operatora i operanda. Metrike za odreivanje indeksa odravanja (Maintainability Index metric) Predstavlja kvantitativnu meru namenjenu merenju i praenju odravanja kako bi se smanjila ili ukinula tendencija sistema prema entropiji programskog kda. Metrike koje se odnose na programski kd ( Code metrics) pomenute metrike predstavljaju specijalizovane metrike koje omoguavaju specifian uvid u kvalitet programski kda. Ove metrike se koriste u kombinaciji sa jednom ili vie specijalizovanih metrika kao to su npr. objektno-orijentisane metrike ili metrike za odreivanje sloenosti. Pri tome, ove metrike moemo posmatrati na etiri nivoa: na nivou metode (Method Level), na nivou klase (Class Level), na nivou datoteke (File Level) kao i na nivou paketa (Package Level). Metrike na nivou metode (Method Level) 1. Broj linija programskog kda (Number of lines of Code NLOC_MTD) - LOC predstavlja meru kojom se mo e utvrditi veliina modula, odnosno projekta; 2. Procenat komentara (Percentage of comments POC_MTD) - Rauna procenat komentara u metodi i definie se kao odnos izmeu ukupnog broja komentarisanih linija u metodi i ukupnog broja linija u metodi; 3. Broj promenljivih (Number of Variables NOV_MTD) - Rauna broj promenljivih u metodi; 4. Broj nekorienih promenljivih (Number of Unused Variables NOUV_MTD) Rauna broj nekorienih promenljivih u metodi; 5. Broj komentarisanih linija (Number of comment lines CL_MTD) - Rauna ukupan broj komentarisanih linija u okviru metode; 6. Broj parametara (Number of Parameters NOP_MTD) - Rauna ukupan broj parametara u okviru metode; 7. Broj nekorienih parametara (Number of Unused Parameters NOUP_MTD) Rauna ukupan broj nekori enih parametara u okviru metode. Metrike na nivou klase (Class Level) 1. Broj linija kda (Number of Lines of Code NLOC_CLS) - Isto kao i NLOC_MTD, pri emu se NLOC_CLS odnosi na nivo klase; 2. Broj roditelja (Number of Parents NOPNT_CLS) - Rauna broj roditelja klase. Pri tome, klasa ukljuuje druge klase i interfejse; 3. Broj atributa (Number of Fields NOFLD_CLS) - Rauna ukupan broj atributa klase. Pri tome, klasa ukljuuje druge klase, interfejse i enumeracije; 4. Procenat ne-privatnih atributa (Percentage of Non-Private Fields NPFP_CLS) - Pod ne-privatnim atributima se podrazumevaju atributi koji imaju podrazumevano javni (default) pristup i atributi sa javnim (public) pristupom; 5. Procenat ne-privatnih metoda (Percentage of Non-Private Methods NPMP_CLS) Pod ne-privatnim metodama se podrazumevaju metode koje imaju podrazumevano javni (default) pristup i metode sa javnim (public) pristupom; 65

6. Broj unutranjih klasa (Number of Inner Classes NOIC_CLS) - Rauna broj unutranjih klasa u okviru klase pri emu se ne uzimaju u obzir anonimne klase5. Metrike na nivou datoteke (File Level) 1. Broj linija kda (Number of Lines of Code NLOC_FIL) - Isto kao i NLOC_MTD i NLOC_CLS, pri emu se NLOC_FIL odnosi na nivo polja; 2. Halstedov Napor / Obim (Halstead Effort / Volume HE_FIL/ HV_FIL) - Slui za merenje sloenosti modula programa korienjem operatora i operanada; Metrike na nivou paketa (Package Level) 1. Broj linija kda (Number of Lines of Code NLOC_PKG) - Isto kao i NLOC_MTD, NLOC_CLS i NLOC_FIL, pri emu se NLOC_PKG odnosi na nivo paketa; 2. Broj klasa (Number of Classes NOCLS_PKG) - Rauna ukupan broj klasa u paketu; 3. Broj interfejsa (Number of Interface NOIFC_PKG) - Rauna broj interfejsa u paketu; 4. Broj datoteka (Number of Files NOF_PKG) - Rauna broj datoteka u paketu.

4.2.1. Opis softverskih metrika Kao to je ve napomenuto, Swat4j sadri sledee grupe metrika: Objektno-orijentisane metrike (Object-oriented metrics); Metrike za odreivanje sloenosti (Complexity metrics); Metrike za odreivanje indeksa odravanja (Maintainability Index metric) i Metrike koje se odnose na programski kd ( Code metrics). U nastavku dajemo prikaz najvanijih metrika posmatranih kategorija. Pri tome, svaka softverska metrika e imati sledeu strukturu: - Naziv metrike; - Opis metrike; - Matematiki model; - Interpretacija; - Veza sa atributima softverskog sistema;

Objektno-orijentisane metrike

1. Sloenost ponderisanih metoda (WMC)

Naziv metrike: Sloenost ponderisanih metoda (WMC) Opis metrike: WMC se definie kao suma sloenosti metoda. Pri tome je ostavljena mogunost izbora sloenosti metode koju treba uzeti u razmatranje. Matematiki model: Pretpostavimo da imamo klasu C sa metodama M1, M2,..., Mn (metode su definisane u klasi). Neka je C1, C2,..., Cn sloenost metoda. U tom sluaju je: WMC=C1+C2+...+Cn

66

U softverskom paketu Swat4j se kao mera sloenosti metode koristi metrika Ciklina sloenost (Cyclomatic Complexity). Pri tome, softverski paket ne uzima u obzir interfejse i nasleivanje klasa, ali se razmatraju anonimne klase. Interpretacija: WMC >= 1. Najbolje bi bilo kada bi Ciklina sloenost svake metode bila 1. U tom sluaju bi Sloenost ponderisanih metoda bila jednaka broju metoda. Ukoliko klasa ima visoku Sloenost ponderisanih metoda, trebalo bi izvriti refaktorisanje (refaktorisati klasu/metodu na dve ili vie klasa/metoda). Veza sa atributima softverskog sistema: Testiranje, Razumljivost, Odravanje, Ponovno korienje.

2. Broj odgovora klase (RFC)

Naziv metrike: Broj odgovora klase (RFC) Opis metrike: U objektno-orijentisanom pristupu objekti komuniciraju prvenstveno razmenom poruka. Na primer, odreena poruka moe dovesti do odreenog ponaanja objekta na taj nain to e pozvati neku njegovu metodu. U tom kontekstu metode se mogu definisati kao odgovor na odrene poruke. Matematiki model: Uzimajui u obzir definiciju metrike moemo rei da je: RFC = |RS|, pri emu je RS skup odgovora klase, odnosno skup svih metoda koje mogu biti pozvane kao odgovor na poruku objekta klase. U softverskom paketu Swat4j je RFC=M+R, pri emu je M Broj metoda u klasi koje mogu biti pozvane kao odgovor klase; R Ukupan broj drugih metoda koje se se pozivaju od strane metoda iz klase (ove metode pozvane su iz metoda definisanih u M). Pri tome, bitno je napomenuti i sledee: Konstruktori se raunaju kao metode; Anonimne klase/Unutranje klase se predstavljaju posebno (dobija se poseban izvetaj); Ne uzimaju se u obzir pozivi System.out.* i System.err.*; Interfejsi se ne uzimaju u obzir. Interpretacija: Ukoliko je skup svih metoda koje mogu biti pozvane kao odgovor na poruku objekta klase veliki, klasa je slo enija. Veza sa atributima softverskog sistema: Testiranje, Kvalitet projektovanja, Performanse, Razumljivost, Odravanje, Ponovno korienje.

67

3. Nedostatak kohezivnosti metoda u klasi (LCOM)

Naziv metrike: Nedostatak kohezivnosti metoda u klasi (LCOM) Opis metrike: Ukoliko klasa ima metode koje se izvravaju nad istim skupom atributa za klasu se kae da je kohezivna. Kohezija je usmerena na atribute objekta, kao i na metode koje pristupaju atributima. LCOM predstavlja meru meusobne povezanosti metoda. Matematiki model: Uzimajui u obzir definiciju metrike, u softverskom paketu Swat4j se nedostatak kohezivnosti metoda u klasi rauna na sledei nain: LCOM = (m - sum(mA)/a) / (m-1), pri emu je m Broj metoda u klasi; a Broj atributa u klasi; mA Broj metoda koje pristupaju atributu a; sum(mA) Suma svih vrednosti mA (uzimaju se u obzir svi atributi u klasi). Interpretacija: LCOM se nalazi u granicama izmeu 0 i 2. Ukoliko je LCOM=0 svaka metoda pristupa svim atributima (indikacija visoke kohezije). Vrednosti LCOM>1 je indikacija nedostatka kohezije. Ekstremni nedostatak kohezije (npr. LCOM>1) je indikacija da posmatranu klasu treba podeliti na dve ili vie klasa. Ukoliko postoji samo jedna metoda ili samo jedan atribut u klasi vrednost LCOM je nedefinisana. Veza sa atributima softverskog sistema: Testiranje, Kvalitet projektovanja, Razumljivost, Odravanje, Ponovno korienje.

4. Povezanost objekata (CBO)

Naziv metrike: Povezanost objekata (CBO) Opis metrike: Dve klase su povezane ukoliko metode jedne klase koriste atribute ili metode druge klase. Matematiki model: CBO dobijamo brojanjem povezanih klasa. Pri tome, za softverski paket Swat4j je bitno napomenuti i sledee: Interfejsi, anonimne klase, Enum promenljive i nasleivanje se ne uzimaju u obzir; Konstruktori se smatraju metodama; Statiko uvoenje (static import) klase se uzima u obzir; Direktan pristup statikim promenljivim drugih klasa se uzima u obzir. Interpretacija: Prevelika povezanost objekata klasa dovodi do naruavanja modularnog projektovanja i spreava ponovno korienje softverskih komponenti ( reuse). Sa druge strane, ukoliko je klasa vie nezavisna lake se moe koristiti u drugim aplikacijama pa je stoga potrebno povezanost klasa svesti na minimum. 68

Veza sa atributima softverskog sistema: Testiranje, Kvalitet projektovanja, Performanse, Razumljivost, Odravanje, Ponovno korienje.

5. Dubina stabla nasleivanja (DIT)

Naziv metrike: Dubina stabla nasleivanja (DIT) Opis metrike: Dubina klase u hijerarhiji nasleivanja definie se kao maksimalni broj nivoa od posmatranog vora do korena drveta. Matematiki model: U softverskom paketu Swat4j, DIT za odreenu Java klasu dobija se tako to se izrauna broj predakata u hijerarhiji nasleivanja. Pri tome je bitno napomenuti sledee: Ukoliko se pronae vie nadklasa, raunanje se ponavlja za sve putanje i u razmatranje se uzima najvei broj nivoa (najvei broj nivoa postaje DIT vrednost); Podrazumevana DIT vrednost za klasu je 1; Podrazumevana DIT vrednost za interfejs je 0; Ne uzimaju se u obzir unutranje anonimne klase. Interpretacija: Ukoliko je klasa dublje u hijerarhiji verovatno je vei broj metoda koje klasa nasleuje to moe oteati predvianje ponaanje klase. Sa druge strane, moe se poveati potencijal ponovnog korienja metoda. Preporuljivo je da DIT vrednost bude to manja. Veza sa atributima softverskog sistema: Testiranje, Kvalitet projektovanja, Razumljivost, Odravanje, Ponovno korienje.

6. Broj podklasa (NOC)

Naziv metrike: Broj podklasa (NOC) Opis metrike: NOC rauna broj neposrednih podklasa posmatrane klase/interfejsa u hijerarhiji klasa. Matematiki model: U programskom paketu Swat4j NOC vrednost se dobija brojanjem neposrednih podklasa posmatrane klase. Pri tome, anonimne klase se ne uzimaju u obzir. Interpretacija: Ukoliko je NOC vei, poveava se mogunost ponovnog korienja jer je nasleivanje jedan od oblika ponovnog korienja. Takoe, sa rastom NOC poveava se i verovatnoa neodgovarajue apstrakcije roditeljske klase (ukoliko posmatrana klasa ima veliki broj potomaka mo e doi do greke u kreiranju podklasa). Veza sa atributima softverskog sistema: Testiranje, Kvalitet projektovanja, Ponovno korienje.

69

Metrike za odreivanje sloenosti

7. Ciklina sloenost (CC)

Naziv metrike: Ciklina sloenost (CC) Opis metrike: Ciklina sloenost predstavlja meru slo enosti primenjenog algoritma u metodi. Matematiki model: Ciklina sloenost softverskog sistema se meri raunanjem broja taaka odluivanja (decision points) ili uslovnih iskaza (conditional statements) posmatranog programskog jezika. Drugim reima, algoritam uzima u obzir jedan od sledeih operatora: "if","else", "for", "while", "do-while", "catch", "case", default iskaze, kao i operatore "&&,||, ?:". Neka je dat usmereni graf G. Neka iskazi predstavljaju vorove (npr. if iskaz). Neka grane predstavljaju put od jednog vora ka drugom (na primer, ta uiniti ukoliko je uslov zadovoljen, odnosno ta uiniti ukoliko uslov nije zadovoljen). U tom sluaju ciklina sloenost predstavlja broj linearno nezavisnih putanja v(G) u usmerenom grafu G. U softverskom paketu Swat4j ciklina sloenost se rauna na sledei nain: CC = P + 1, gde je P Broj predikata (ili) Broj uslova (ili) Broj binarnih vorova 1 Predstavlja ulaznu putanju funkcije. Interpretacija: CC>=1. Najbolje bi bilo kada bi ciklina sloenost svake metode bila 1. Ukoliko je CC metode vea, primenjeni algoritam je sloeniji (ima vie grananja i ispitivanja uslova). Veza sa atributima softverskog sistema: Testiranje, Razumljivost, Odravanje.

8. Halstedova sloenost (HE)

Naziv metrike: Halstedova sloenost (HE) Opis metrike: Slui za merenje slo enosti modula direktno iz izvornog kda programa korienjem operatora i operanda. Ova metrika je znaajan indikator slo enosti programskog kda. Matematiki model: Napor potreban za implementaciju ili razumevanje programa proporcionalan je obimu programa i nivou teine programa. Stoga je HE=V*D ili HE=V/L, pri emu je n1 - Broj jedinstvenih (razliitih) operatora n2 - Broj jedinstvenih (razliitih) operanada 70

N1 - Ukupan broj operatora N2 - Ukupan broj operanada N = N1 + N2 - Halstedova duina programa (Halstead program length) n = n1 + n2 - Veliina renika (Vocabulary size) V= N * log2(n) - Obim programa (Program volume) D = ( n1 / 2 ) * ( N2 / n2 ) - Nivo teine (Difficulty level) L = 1 / D ili L = (2 * n2) / (n1 * N2) - Nivo programa (Program level) Pri tome, bitno je napomenuti sledee: - Komentari se ne uzimaju u obzir - Unutranje klase i anonimne klase se uzimaju u obzir Interpretacija: Metrika se moe koristiti za utvrivanje napora potrebnog za implementaciju korisnikih zahteva, kao i napora potrebnog za uspeno odravanje softverskog sistema. Ukoliko je vrednost parametra HE vea, bie potreban vei napor kako bi se uspeno implementirao korisniki zahtev, odnosno uspeno odravao softverski sistem. Veza sa atributima softverskog sistema: Testiranje, Razumljivost, Odravanje.

9. Indeks odravanja {datoteke, klase, paketa, projekta} (MI)

Naziv metrike: Indeks odravanja {datoteke, klase, paketa, projekta} (MI) Opis metrike: Predstavlja kvantitativnu meru namenjenu merenju i praenju odravanja kako bi se smanjila ili ukinula tendencija sistema prema entropiji programskog kda. Matematiki model: U softverskom alatu Swat4j MI se rauna po sledeoj formuli: MI = 171 - 5.2 * log2( aveV ) - 0.23 * aveV( g' ) - 16.2 * log2 ( aveLOC ) + 50 * sin (sqrt( 2.46 * perCM )), pri emu je aveV Prosean Halstedov obim programa po modulu aveV(G) = Prosena ciklina sloenost po modulu aveLOC = Prosean broj linija koda po modulu perCM = Prosean procenat linija komentara po modulu Interpretacija: Ukoliko je MI < 65 smatra se da su mogunosti odravanja softvera male. Ukoliko je 65<=MI<85 smatra se da su mogunosti odravanja softvera dobre. Ukoliko je MI >= 85 smatra se da su mogunosti odravanja softvera odline. Veza sa atributima softverskog sistema: Odravanje.

71

U Tabeli 5. dajemo matrini prikaz pojedinih metrika koje podrava softverski paket Swat4j u predefinisanom modelu kvaliteta. U redovima su prikazane odabrane softverske metrike, dok su u kolonama predstavljeni atributi kvaliteta softvera. Za svaki atribut softvers kog sistema vezano je vie metrika. Sa druge strane, jedna metrika se mo e odnositi na vie atributa softverskog sistema. Ukoliko se konkretna metrika mo e koristiti za odreivanje vrednosti posmatranog atributa kvaliteta softvera postavljena je oznaka .
Softverska metrika Atribut softverskog sistema Testiranje Kvalitet projektovanja Performanse Razumljivost Odravanje Ponovno korienje

Objektno orjentisane metrike

Sloenost (WMC)

ponderisanih

metoda

Metrike za odredjivanje sloenosti Metrike za odredjivanje indexa odravnja

Broj odgovora klase (RFC) Nedostatak kohezivnosti metoda u klasi (LCOM) Povezanost objekata (CBO) Dubina stabla nasledjivanja (DIT) Broj podklasa (NOC) Ciklina sloenost (McCabe) Halsedova sloenost (HE) Index odravanja (MI)

Tabela 5: Odabrane metrike u modelu kvaliteta softverskog paketa Swat4j

72

4.3. Saetak U ovom poglavlju prikazan je ISO/IEC 9126 standard kojim se definie kvalitet softverskog sistema. Ovaj standard se sastoji iz etiri dela: ISO/IEC 9126-1 kojim se definie model kvaliteta softvera ( Quality model), ISO/IEC 9126-2 kojim se definiu eksterne metrike (External metrics), ISO/IEC 9126-3 kojim se definiu interne metrike (Internal metrics) i ISO/IEC 9126-4 kojim se definie kvalitet u korienju metrika ( Quality in use metrics). Zatim je korienjem matematikih modela dat prikaz metrika koje se nalaze u softverskom paketu Swat4j (koji je, u stvari, zasnovan na ovom standardu). Na ovaj nain smo realizovali trei cilj istraivanja ( Dati pregled ISO/IEC 9126 standarda).

73

5. STUDIJSKI PRIMER
U ovom poglavlju emo dati studijski primer i opisati uproenu Larmanovu metodu razvoja softvera. Studijski primer opisan u ovom poglavlju je implementiran na dva naina, korienjem EJB 2.1 i EJB 3.0 tehnologije. Ta dva primera su u poglavlju 6. komparativno analizirana.

5.1. Uproena Larmanova metoda razvoja softvera

Uproena Larmanova metoda razvoja softvera se sastoji iz 5 faza: 1. Prikupljanje korisnikog zahteva 2. Analiza 3. Projektovanje 4. Implementacija 5. Testiranje U nastavku emo rei vie o pojednim fazama. 5.1.1. Zahtevi Korisniki zahtev predstavlja prvu fazu razvoja jednog softvera. Jedan od modela za predsavaljanje korisnikog zahteva je i verbalni model. 5.1.1.1. Verbalni model Na osnovu korisnikog zahteva, potrebno je projektovati web aplikaciju koja prati poslovanje Agencije za zapoljavanje. Poslovanje se zasniva na tome da vlasnik agencije prikuplja podatke i odrava bazu podataka o kadrovima raznih profila, i te podatke ust upa firmama uz mesenu novanu nadoknadu. Obini korisnici sistema (kadrovi) mogu ostaviti svoje podatke na web sajtu besplatno. Firme koje ele pregled kardova, moraju se registrovati i platiti lanarinu, i tek tada mogu pregledati podatke o kardovima. Konkretno, potrebno je raditi sa podacima o lanovima (kadrovi), firmama, lanarinama firme, vestima i sl. Kao metoda razvoja softvera koriena je uproena Larmanova metoda razvoja softvera. 5.1.1.2. Sluajevi korienja sistema U Larmanovoj metodi razvoja softvera zahtevi se opisuju pomou Modela Sluaja Korienja (Use-Case Model). U ovom primeru postoji 3 aktera, i svaki od njih ima neke sluajeve sluajeve korienja. Sluajevi korienja su dati na slici.

74

Logovanje Logovanje
Prijava firme

Promena firme

Prijava clana

firma
Brisanje firme

clan (fizicko lice) Promena clana

Pretraga clanova

Brisanje clana

Logovanje
Brisanje clana

administrator

Brisanje firme

Evidentiranje clanarine

Slika 13: Sluajevi korienja sistema 5.1.1.3. Opis sluaja korienja SK1: Sluaj korienja Prijava lana Naziv SK Prijava lana Aktor SK lan (fiziko lice) Uesnici SK lan i program (u daljem tekstu sistem). Preduslov: lan je otvorio web sajt i izabrao opciju Prijava lana. Sistem prikazuje stranicu Prijava lana. Postuslov: Novi lan je kreiran. Osnovni scenario SK 1. lan unosi podatke o sebi (APUSO) 2. lan poziva sistem da snimi podatke (APSO) 3. Sistem snima podatke (SO) 4. Sistem vraa poruku da je lan snimljen (IA)

75

Alternativni scenario 3.1. Ukoliko ve postoji lan sa istim korisnikim imenom sistem vraa poruku da ne moe da kreira slog u bazi (IA) i prekida se izvrenje scenarija. SK2: Sluaj korienja Logovanje lana Naziv SK Logovanje lana Aktor SK lan (fiziko lice) Uesnici SK lan i program Preduslov: lan je otvorio web sajt i izabrao opciju Login. Sistem prikazuje stranicu Login. Postuslov: lan je ulogovan na sistem. Osnovni scenario SK 1. lan unosi username i password (APUSO) 2. lan poziva sistem da proveri username i password (APSO) 3. Sistem proverava podatke (SO) 4. Sistem uzima sve podatke o lanu iz baze (SO) 5. Sistem prikazuje sve podatke o lanu (AI) Alternativni scenario 3.1. Ukoliko username i password nisu odgovarajui sistem vraa poruku (IA) i prekida se izvrenje scenarija. 4.1. Ukoliko dodje do greke prilikom itanja podataka iz baze, sistem vraa poruku o greci (IA) SK3: Sluaj korienja Brisanje lana Naziv SK Brisanje lana Aktor SK lan (fiziko lice) Uesnici SK lan i sistem Preduslov: lan je otvorio web sajt i ulogovao se. Sistem je automatski prikazao podatke o lanu. Postuslov: Izabrani clan je obrisan. Osnovni scenario SK 1. lan poziva sistem da obrie podatke o lanu (APSO) 2. Sistem brie podatke o lanu (SO) 3. Sistem prikazuje lanu poruku da je uspeno obrisan slog (IA)

76

Alternativni scenario 2.1. Ukoliko dodje do greske u toku operacije brisanja sistem vraa poruku da slog n ije obrisan u bazi (IA) i prekida se izvrenje scenarija. SK4: Sluaj korienja Promena podataka o lanu Naziv SK Promena podataka o lanu Aktor SK lan (fiziko lice) Uesnici SK lan i sistem Preduslov: lan je otvorio web sajt i ulogovao se. Sistem je automatski prikazao podatke o lanu. Postuslov: Podaci o lanu su promenjeni. Osnovni scenario SK 1. lan unosi nove podatke o sebi (AUPSO) 2. lan poziva sistem da promeni podatke (APSO) 3. Sistem menja podatke o lanu (SO) 4. Sistem prikazuje lanu nove podatke i poruku da je uspeno promenjen slog.(IA) Alternativni scenario 3.1. Ukoliko dodje do greske u toku operacije promene sistem vraa poruku da slog nije promenjen u bazi (IA) i prekida se izvrenje scenarija. SK5: Sluaj korienja Logovanje pravnog lica (firme) Naziv SK Logovanje pravnog lica Aktor SK Pravno lice (firma) Uesnici SK Pravno lice i program Preduslov: Pravno lice je otvorilo web sajt i izabralo opciju Login. Sistem prikazuje stranicu Login. Postuslov: Pravno lice se uspesno logovalo na sistem. Osnovni scenario SK 1. Pravno lice unosi username i password (APUSO) 2. Pravno lice poziva sistem da proveri username i password (APSO) 3. Sistem proverava podatke (SO) 4. Sistem uzima sve podatke o pravnom licu iz baze (SO) 5. Sistem prikazuje sve podatke o pravnom licu (AI) 77

Alternativni scenario 3.1. Ukoliko username i password nisu odgovarajui sistem vraa poruku (IA) i prekida se izvrenje scenarija. 4.1. Ukoliko dodje do greke prilikom itanja podataka iz baze, sistem vraa poruku o greci (IA). SK6: Sluaj korienja Prijava pravnog lica Naziv SK Prijava pravnog lica Aktor SK Pravno lice Uesnici SK Pravno lice i sistem Preduslov: Pravno lice je otvorilo web sajt i izabralo opciju Prijava firme. Sistem prikazuje stranicu Prijava Firme. Postuslov: Novo pravno lice je kreirano. Osnovni scenario SK 1. Pravno lice unosi podatke o sebi (APUSO) 2. Pravno lice poziva sistem da snimi podatke (APSO) 3. Sistem snima podatke o novom pravnom licu (SO) 4. Sistem vraa poruku da je kreiran slog (IA) Alternativni scenario 3.1. Ukoliko ve postoji pravno lice sa istim imenom sistem vraa poruku da ne moe da kreira slog u bazi (IA) i prekida se izvrenje scenarija. SK7: Sluaj korienja Brisanje pravnog lica Naziv SK Brisanje pravnog lica Aktor SK Pravno lice Uesnici SK Pravno lice i sistem Preduslov: Pravno lice je otvorilo web sajt i ulogovalo se. Sistem je automatski prikazao podatke o pravnom licu. Postuslov: Pravno lice je obrisano iz baze. Osnovni scenario SK 1. Pravno lice poziva sistem da obrie podatke o pravnom licu (APSO) 2. Sistem brie podatke o pravnom licu (SO) 3. Sistem prikazuje pravnom licu poruku da je uspeno obrisan slog.(IA) 78

Alternativni scenario 2.1. Ukoliko dodje do greske u toku operacije brisanja sistem vraa poruku da slog nije obrisan u bazi (IA) i prekida se izvrenje scenarija. SK8: Sluaj korienja Promena podataka o pravnom licu Naziv SK Promena podataka o pravnom licu Aktor SK Pravno lice Uesnici SK Pravno lice i sistem Preduslov: Pravno lice je otvorilo web sajt i ulogovalo se. Sistem je automatski prikazao podatke o pravnom licu. Postuslov: Podaci o pravnom licu su promenjeni. Osnovni scenario SK 1. Pravno lice unosi nove podatke o sebi (APUSO) 2. Pravno lice poziva sistem da promeni podatke (APSO) 3. Sistem menja podatke o pravnom licu (SO) 4. Sistem prikazuje nove podatke i poruku da je uspeno promenjen slog (IA) Alternativni scenario 3.1. Ukoliko dodje do greske u toku operacije promene sistem vraa poruku da slog nije promenjen u bazi (IA) i prekida se izvrenje scenarija. SK9: Sluaj korienja Pretraga lanova Naziv SK Pretraga lanova od strane pravnog lica Aktor SK Pravno lice Uesnici SK Pravno lice i sistem Preduslov: Pravno lice je otvorilo web sajt i ulogovalo se. Sistem je automatski prikazao podatke o pravnom licu. Postuslov: Lista lanova je prikazana. Osnovni scenario SK 1. Pravno lice unosi kriterijume za pretragu lanova (APUSO) 2. Pravno lice poziva sistem da pretrai bazu podataka lanova (APSO) 3. Sistem pretrauje bazu podataka (SO) 4. Sistem prikazuje zaposlenom podatke o lanovima koji odgovaraju zadatom kriterijumu (IA). 79

Alternativni scenario 3.1. Ukoliko ne postoji ni jedan lan koji zadovoljava kriterijum pretrage sistem vraa odgovarajuu poruku (IA) 3.2. Ukoliko firma nije platila lanarinu za tekui mesec, sistem prikazuje poruku da lanarina nije plaena. SK10: Sluaj korienja Logovanje administratora Naziv SK Logovanje administratora Aktor SK Administrator Uesnici SK Administrator i program Preduslov: Administrator je otvorio web sajt i izabrao opciju Login. Sistem prikazuje stranicu Login. Osnovni scenario SK 1. Administrator unosi username i password (APUSO) 2. Administrator poziva sistem da proveri username i password (APSO) 3. Sistem proverava podatke (SO) 4. Sistem prikazuje odgovarajuci meni za administatora (AI) Alternativni scenario 3.1. Ukoliko username i password nisu odgovarajui sistem vraa poruku (IA) i prekida se izvrenje scenarija. SK11: Sluaj korienja Brisanje lana (od strane administratora) Naziv SK Brisanje lana (od strane administratora) Aktor SK Administrator Uesnici SK Administrator i sistem Preduslov: Adminstrator je otvorio web sajt i ulogovao se. Sistem je automatski prikazao opcije o brisanju lana i evidentiranju lanarine. Postuslov: lan je obrisan iz baze. Osnovni scenario SK 1. Administrator unosi podatke o lanu koga eli da obrise (APUSO) 2. Administrator poziva sistem da obrie podatke o lanu (APSO) 3. Sistem brie podatke o lanu (SO) 4. Sistem prikazuje administratoru poruku da je uspeno obrisan slog (IA) 80

Alternativni scenario 3.1. Ukoliko dodje do greske u toku operacije brisanja siste m vraa poruku da slog nije obrisan u bazi (IA) i prekida se izvrenje scenarija. SK12: Sluaj korienja Brisanje pravnog lica (od strane administratora) Naziv SK Brisanje pravnog lica (od strane administratora) Aktor SK Administrator Uesnici SK Administrator i sistem Preduslov: Adminstrator je otvorio web sajt i ulogovao se. Sistem je automatski prikazao opcije o brisanju pravnog lica i evidentiranju lanarine. Postuslov: Pravno lice je obrisano iz baze. Osnovni scenario SK 1. Administrator unosi podatke o pravnom licu koga eli da obrise (APUSO) 2. Administrator poziva sistem da obrie podatke o pravnom licu(APSO) 3. Sistem brie podatke o pravnom licu (SO) 4. Sistem prikazuje administratoru poruku da je uspeno obrisan slo g (IA) Alternativni scenario 3.1. Ukoliko dodje do greske u toku operacije brisanja sistem vraa poruku da slog nije obrisan u bazi (IA) i prekida se izvrenje scenarija. SK13: Sluaj korienja Evidentiranje lanarine za pravno lice Naziv SK Evidentiranje lanarine za pravno lice Aktor SK Administrator Uesnici SK Administrator i sistem Preduslov: Adminstrator je otvorio web sajt i ulogovao se. Sistem je automatski prikazao opcije o brisanju korisnika i evidentiranju lanarine. Postuslov: lanarina za zadato pravno lice je evidentirana. Osnovni scenario SK 1. Administartor unosi podatke o pravnom licu i lanarini (APUSO) 2. Administrator poziva sistem da snimi podatke o lanarini pravnog lica (APSO) 3. Sistem snima podatke o lanarini (SO) 4. Sistem prikazuje poruku da je lanarina uspesno evidentirana (AI)

81

Alternativni scenario 3.1. Ukoliko dodje do greske u toku operacije evidentiranja sistem vraa poruku (IA) i prekida se izvrenje scenarija.

5.1.2. Analiza Faza analize opisuje logiku strukturu i ponaanje softverskog sistema (poslovnu logiku softverskog sistema). Ponaanje softverskog sistema se opisuje pomou sistemskih dijagrama sekvenci, koji se prave za svaki SK, i pomou ugovora o sistemskim operacijama, koje se dobijaju na osnovu sistemskih dijagrama sekvenci. Struktura softverskog sistema se opisuje pomou konceptualnog i relacionog modela. Relacioni model se kasnije koristi da se implementira relaciona baza podataka, u kojoj e se uvati podaci. 5.1.2.1. Ponaanje sistema 5.1.2.1.1. Sistemski dijagram sekvenci DS1: Dijagrami sekvenci sluaja korienja Prijava lana Osnovni scenario SK 1. lan poziva sistem da snima podatke (APSO) 2. Sistem vraa poruku o uspesnosti (IA)

Sistem
: Fizicko lice (clan)

SOsnimiClana(podaci)

poruka

Alternativni scenario 2.1. Ukoliko ve postoji lan sa istim korisnikim imenom sistem vraa poruku da ne moe da kreira slog u bazi (IA) i prekida se izvrenje scenarija. 82

DS2: Dijagrami sekvenci sluaja korienja Logovanje lana

Osnovni scenario SK 1. lan poziva sistem da proveri podatke (APSO) 2. lan poziva sistem da uzme sve podatke o lanu iz baze (APSO) 3. Sistem prikazuje sve podatke o lanu (IA)

: Fizicko lice (clan)

Sistem

SOproveriKorisnika()

SOvratiClana()

podaci

Alternativni scenario 1.1. Ukoliko username i password nisu odgovarajui sistem vraa poruku (IA) i prekida se izvrenje scenarija. 2.1. Ako se desi greka prilikom uzimanja podataka o lanu iz baze, sistem vraa poruku o greci (IA) i prekida se izvrenje scenarija.

83

DS3: Dijagrami sekvenci sluaja korienja Brisanje lana

Osnovni scenario SK 1. lan poziva sistem da obrie podatke o lanu (APSO) 2. Sistem vraa poruku o uspenosti (IA)

Sistem
: Fizicko lice (clan)

SObrisiClana(podaci)

poruka

Alternativni scenario 2.1. Ukoliko dodje do greke u toku operacije brisanja sistem vraa poruku da slog nije obrisan u bazi (IA) i prekida se izvrenje scenarija.

84

DS4: Dijagrami sekvenci sluaja korienja Promena podataka o lanu

Osnovni scenario SK 1. lan poziva sistem da menja podatke o lanu (APSO) 2. Sistem prikazuje lanu nove podatke i poruku da je uspeno promenjen podatak.(IA)

Sistem
: Fizicko lice (clan)

SOpromeniClana(podaci)

promenjeni podaci

Alternativni scenario 1.1. Ukoliko dodje do greke u toku operacije promene sistem vraa poruku da slog nije promenjen u bazi (IA) i prekida se izvrenje scenarija.

85

DS5:Dijagrami sekvenci sluaja korienja Logovanje pravnog lica

Osnovni scenario SK 1. Pravno lice poziva sistem da proveri podatke (APSO) 2. Pravno lice poziva sistem da uzme sve podatke o pravnom licu iz baze (APSO) 3. Sistem prikazuje sve podatke o pravnom licu (IA)

: Firma

Sistem

SOproveriKorisnika()

SOvratiFirmu()

podaci

Alternativni scenario 1.1. Ukoliko username i password nisu odgovarajui sistem vraa poruku (IA) i prekida se izvrenje scenarija. 2.1. Ako se desi greska prilikom uzimanja podataka o pravnom licu iz baze, sistem vraa poruku (IA) i prekida se izvrenje scenarija.

86

DS6: Dijagrami sekvenci sluaja korienja Prijava pravnog lica

Osnovni scenario SK 1. Pravno lice poziva sistem da snimi podatke (APSO) 2. Sistem vraa poruku o uspenosti (IA)

: Firma

Sistem

SOsnimiFirmu(podaci)

poruka

Alternativni scenario 2.1. Ukoliko ve postoji pravno lice sa istim imenom sistem vraa poruku da ne moe da kreira slog u bazi (IA) i prekida se izvrenje scenarija.

87

DS7: Dijagrami sekvenci sluaja korienja Brisanje pravnog lica

Osnovni scenario SK 1. Pravno lice poziva sistem da obrie podatke o pravnom licu (APSO) 2. Sistem vraa poruku o uspenosti (IA)

Sistem
: Firma

SObrisiFirmu(podaci)

poruka

Alternativni scenario 2.1. Ukoliko dodje do greke u toku operacije brisanja sistem vraa poruku da slog nije obrisan u bazi (IA) i prekida se izvrenje scenarija.

88

DS8: Dijagrami sekvenci sluaja korienja Promena podataka o pravnom licu

Osnovni scenario SK 1. Pravno lice poziva sistem da menja podatke o pravnom licu (APSO) 2. Sistem prikazuje nove podatke i poruku da je uspeno promenjen slog (IA)

Sistem
: Firma

SOpromeniFirmu(podaci)

promenjeni podaci

Alternativni scenario 1.1. Ukoliko dodje do greke u toku operacije promene sistem vraa poruku da slog nije promenjen u bazi (IA) i prekida se izvrenje scenarija.

89

DS9: Dijagrami sekvenci sluaja korienja Pretraga lanova od strane pravnog lica

Osnovni scenario SK 1. Pravno lice poziva sistem da proveri da li je pravno lice platilo lanarinu ( APSO) 2. Pravno lice poziva sistem da vrati lanove koji odgovaraju kriterijumu pretrage (APSO) 3. Sistem prikazuje rezultat pretrage (IA)

Firma : firma

Sistem

SOProveriClanarinu()

bollean

SOPronadjiClanoveIVratiIh()

clanovi

Alternativni scenario 1.1. Ukoliko pravno lice nije platilo lanarinu, sistem vraca odgovarajucu poruku (IA) 2.1. Ukoliko dodje do greke u toku izvrenja operacije sistem vraa poruku (IA) i prekida se izvrenje scenarija.

90

DS10: Dijagrami sekvenci sluaja korienja Logovanje administratora

Osnovni scenario SK 1. Adminstrator poziva sistem da proveri username i password (APSO) 2. Sistem prikazuje administratoru meni (IA)

: Administrator

Sistem

SOproveriKorisnika()

podaci

Alternativni scenario 1.1. Ukoliko username i password nisu odgovarajui sistem vraa poruku (IA) i prekida se izvrenje scenarija.

91

DS11: Dijagrami sekvenci sluaja korienja Brisanje lana od strane administratora

Osnovni scenario SK 1. Administrator poziva sistem da obrie podatke o lanu (APSO) 2. Sistem vraa poruku o uspenosti (IA)

: administrator

Sistem

SObrisiClana()

poruka

Alternativni scenario 2.1. Ukoliko dodje do greke u toku operacije brisanja sistem vraa poruku da slog nije obrisan u bazi (IA) i prekida se izvrenje scenarija.

92

DS12: Dijagrami sekvenci sluaja korienja Brisanje pravnog lica od strane administratora

Osnovni scenario SK 1. Administrator poziva sistem da obrie podatke o pravnom licu (APSO) 2. Sistem vraa poruku o uspenosti (IA)

: Administrator

Sistem

SObrisiFirmu()

poruka

Alternativni scenario 2.1. Ukoliko dodje do greke u toku operacije brisanja sistem vraa poruku da slog nije obrisan u bazi (IA) i prekida se izvrenje scenarija.

93

DS13: Dijagrami sekvenci sluaja korienja Evidentiranje lanarine pravnog lica

Osnovni scenario SK 1. Administrator poziva sistem da snimi podatke o lanarini ( APSO) 2. Sistem vraa poruku o uspenosti (IA)

: Administrator

Sistem

SOevidentirajClanarinu()

poruka

Alternativni scenario 1.1. Ukoliko dodje do greke u toku izvrenja operacije sistem vraa poruku (IA) i prekida se izvrenje scenarija.

94

5.1.2.1.2. Definisanje ugovora o sistemskim operacijama Sistemske operacije opisuju ponaanje softverskog sistema. Ugovori se prave za sistemske operacije i oni opisuju njeno ponaanje. Oni opisuju ta operacija treba da radi, a ne kako e to da radi. Za neke karakteristine SO je dat dijagam sekvenci.

UGOVOR UG1: proveriKorisnika Operacija: SOproveriKorisnika(String username, String password): tipKorisnika Veza sa SK: DS2, DS5, DS10 Preduslovi: Postuslovi: Ako je username i password ok vraca tipKorisnika

UGOVOR UG2: snimiClana

Operacija: SOsnimiClana(String _JMBG,String _ime,String _adresa,String _tel,String _email,int _starost, String _zavrsenaSkola, String _radNaRacunaru, String _straniJezik, String _vozackaDozvola, String _username,String _password): poruka; Veza sa SK: DS1 Preduslovi: Postuslovi: lan je snimljen u bazu

UGOVOR UG3: snimiFirmu Operacija: SOsnimiFirmu(String _naziv, String _adresa, String _tel, String _email, String _delatnost, String _username, String _password, _datumIsteka, _iznos): poruka Veza sa SK: DS6 Preduslovi: Postuslovi: Pravno lice je snimljeno u bazu

UGOVOR UG4: vratiClana Operacija: SOvratiClana(String username) : String[] Veza sa SK: DS2 Preduslovi: lan je uspesno ulogovan. Postuslovi: Vraca niz stringova koji predstavljaju clana.

UGOVOR UG5: vratiFirmu Operacija: SOvratiFirmu(String username) : String[] Veza sa SK: DS5 Preduslovi: Firma je uspesno logovan. Postuslovi: Vraca niz stringova koji predstavljaju firmu.

95

UGOVOR UG6: brisiClana

Operacija: SObrisiClana(String username) : poruka Veza sa SK: DS3, DS11 Preduslovi: lan se ulogovao na sistem ili admin se ulogovao na sistem. Postuslovi: lan sa zadatim username-om je obrisan.

UGOVOR UG7: brisiFirmu Operacija: SObrisiFirmu(String username) : poruka Veza sa SK: DS7 Preduslovi: Pravno lice se ulogovalo na sistem ili admin se ulogovao na sistem. Postuslovi: Pravno lice zadatim username-om je obrisana.

UGOVOR UG8: promeniClana Operacija: SOpromeniClana(String _JMBG, String _ime, String _adresa, String _tel,String _email, int _starost, String _zavrsenaSkola, String _radNaRacunaru, String _straniJezik, String _vozackaDozvola,String _username, String _password) Veza sa SK: DS4 Preduslovi: lan se ulogovao na sistem. Postuslovi: lan sa zadatim username-om je primenjen.

UGOVOR UG9: promeniFirmu Operacija: SOpromeniFirmu(String _naziv, String _adresa, String _tel, String _email, String _delatnost, String _username, String _password) Veza sa SK: DS8 Preduslovi: Pravno lice se ulogovao na sistem. Postuslovi: Pravno lice sa zadatim username-om je primenjen.

UGOVOR UG10: evidentirajClanarinu Operacija: SOevidentirajClanarinu(String naziv, String datumIsteka, int iznos) Veza sa SK: DS13 Preduslovi: Admin se ulogovao na sistem. Postuslovi: lanarina za zadatu firmu je upisana u bazu.

UGOVOR UG11: proveriClanarinu Operacija: SOproveriClanarinu(String _username) Veza sa SK: DS9 Preduslovi: Firma se ulogovao na sistem. Postuslovi: Vraca true ili false ako je lanarina firme OK.

96

UGOVOR UG12: pretraziClanoveIVrati

Operacija: SOpretraziClanoveIVrati(int god1, int god2, String zavrsenaSkola, String radNaRacunaru, String vozackaDozvola): ArrayList Veza sa SK: DS9 Preduslovi: Pravno lice se ulogovalo na sistem. Postuslovi: Vraca listu lanova koji odgovaraju zadatom kriterijumu.

5.1.2.2. Struktura sistema Struktura softverskog sistema se opisuje pomou konceptualnog modela. Konceptualni model sadrzi konceptualne klase (domenske objekte) i asocijacije izmedju konceptualnih klasa.

5.1.2.2.1. Konceptualni (domenski) model Struktura softverskog sistema se opisuje pomou konceptualnog modela. Konceptualni model sadrzi konceptualne klase (domenske objekte) i asocijacije izmedju konceptualnih klasa. Konkretan primer konceptualnog modela:

Slika 14: Konceptualni model 97

5.1.2.2.2. Relacioni model Na osnovu konceptualnog modela moe se napraviti relacioni model, koji e da predstavlja osnovu za projektovanje relacione baze podataka. Uoene su sledee relacije:

Login (id, username, password, tipKorisnika) Clan (id, JMBG, ime, adresa, telefon, email, starost, zavrsenaSkola, straniJezik, vozackaDozvola, username, radNaRacunaru) Firma (id, naziv, adresa, telefon, email, delatnost, username) lanarinaFirme (id, firma_id, usernameFirme, datumIsteka, iznos)

5.1.3. Projektovanje Faza projektovanja opisuje fiziku strukturu i ponaanje softverskog sistema (arhitekturu softverskog sistema). Projektovanje arhitekture softverskog sistema obuhvata projektovanje aplikacione logike, skladita podataka i korisnikog interfejsa. U okviru aplikacione logike se projektuju kontroler, poslovna logika i database broker. Projektovanje poslovne logike obuhvata projektovanje logike strukture i ponaanja softverskog sistema. 5.1.3.1. Arhitektura softverskog sistema Prilikom projektovanja je korisen model arhitekture sa tri nivoa: korisniki interfejs, poslovna logika i skladiste podataka. Ovakav model omoguava da se sistem koji se razvija bude prilagodljiv za budue izmene. 5.1.3.2. Aplikaciona logika
U okviru aplikacione logike se projektuju kontroler aplikacione logike, poslovna logika i perzistentni okvir.

5.1.3.2.1. Kontroler poslovne logike Kontroler poslovne predstavalja Facade pattern i ima ulogu da sakrije selokupan podsistem iza sebe, i ponudi samo nekoliko metoda za pristup korienje sistema.

98

Slika 15: Kontroler poslovne logike Na slici je dat konroler poslovne logike kao i sistemske operacije koje on sakriva od GUI klijenta. Kao to se vidi sa slike, kontrolerPL nudi jednostavne metode za upravljanje sistemom. 5.1.3.2.2. Poslovna logika Poslovna logika obuhvata sistemske operacije. Moe se reci da jedna sistemska operacija predstavlja jedno eljeno ponaanje sistema. U ovom projektu sve sistemske operacije nasledjuju AbstractOperacija, u kojoj su kesirani bean-ovi za pristup perzistentnom okviru.

5.1.3.2.3. Perzistentni okvir Perzistentni okvir je deo poslovne logike koji ima ulogu da obavlja CRUD operacije nad bazom podataka. On je implementiran koristei EJB Session Beans i Entity Beans. 99

Slika 16: Perzistentni okvir 5.1.3.3. Skladite podataka Tabela clan Ime kolone Id JMBG Ime Adresa Telefon Email Starost ZavrsenaSkola StraniJezik VozackaDozvola RadNaRacunaru Username

Tip podatka Number Text Text Text Text Text Number Text Text Text Text Text

Tabela 6: Skladite podataka - tabela Clan Primarni klju Id Spoljni klju username iz tabele login 100

Tabela - firma Ime kolone Id Naziv Adresa Telefon Email Delatnost Username

Tip podatka Number Text Text Text Text Text Text

Tabela 7: Skladite podataka - tabela Firma Primarni klju Id Spoljni klju username iz tabele login

Tabela - clanarinaFirme Ime kolone Id UsernameFirme DatumIsteka Iznos Firma_id

Tip podatka Number Text Text Number Number

Tabela 8: Skladite podataka - tabela Clanarina Firme Primarni klju RB,usernameFirme Tabela - login Ime kolone Id Username password tipKorisnika Primarni klju Id 5.1.3.4. Projektovanje korisnikog interfejsa
Korisniki interfejs predstavlja realizaciju ulaza i/ili izlaza softverskog sistema [DrVlajic1]. Korisniki interfejs sastoji se od ekranskih formi i kontrolera korisnikog interfejsa. Ekranske forme realizovane su korienjem JSP tehnologije, dok se kao kontroler korisnikog interfejsa koristi servlet.

Tip podatka Number Text Text Text

Tabela 9: Skladite podataka - tabela Login

101

5.1.3.4.1. Ekranske forme

Unos lana
Kada lan eli da se registruje na sistemu, onda klikne na dugme prijava lana. Otvara mu se stranica na kojoj je potrebno uneti podatke o lanu. Kad zavri unos podataka, lan klikne na dugme snimi podatke. Ova stranica se koristi u SK Prijava lana. Osnovni scenario SK 1. lan unosi podatke o sebi (APUSO) 2. lan poziva sistem da snimi podatke (APSO) 3. Sistem snima podatke (SO) Opis akcije: lan popunjava podatke i klikom na dugme Snimi podatke, poziva sistem da snimi podateke, tj izvrava se SOsnimiClana(). 4. Sistem vraa poruku da je lan snimljen (IA)

102

Unos pravnog lica

Kada pravno lice eli da se registruje na sistemu, onda klikne na dugme prijava firme. Otvara mu se stranica na kojoj je potrebno uneti podatke o pravnom licu. Kad zavr i unos podataka, pravno lice klikne na dugme snimi podatke. Ova stranica se koristi u SK Prijava firme.

Osnovni scenario SK 1. Pravno lice unosi podatke o sebi (APUSO) 2. Pravno lice poziva sistem da snimi podatke (APSO) 3. Sistem snima podatke o novom pravnom licu (SO) Opis akcije: Pravno lice popunjava podatke i klikom na dugme Snimi podatke, poziva sistem da snimi podateke, tj izvrava se SOsnimiFirmu(). 4. Sistem vraa poruku da je kreiran slog (IA)

103

Login strana
Login strana se prikazuje po to korisnik klikne na dugme Login. Od korisnika se oekuje da unese odgovarajue korisniko ime i lozinku. Ova stranica je zajednika za lanove i pravna lica. Ova stranica se koristi u SK Logovanje lana, SK Logovanje firme, SK Logovanje administratora.

Osnovni scenario SK 1. lan unosi username i password (APUSO) 2. lan poziva sistem da proveri username i password (APSO) 3. Sistem proverava podatke (SO) Opis akcije: Korisnik popunjava polja i klikom na dugme Login, poziva sistem da proveri username i password, tj izvrava se SOproveriKorisnika(). 4. Sistem uzima sve podatke o lanu iz baze (SO) 5. Sistem prikazuje sve podatke o lanu (AI)

104

Meni lan
Meni lan se prikazuje poto je lan proao Login stranicu. Ovde su prikazani podaci o lanu, kao i mogunost njihove izmene i brisanja. Ova stranica se koristi u SK Brisanje lana, SK Promena podataka o lanu.

105

Meni firma
Meni firma se prikazuje poto je pravno lice prolo Login stranicu. Ovde su prikazani podaci o firmi, kao i mogunost njihove izmene i brisanja. Ova stranica se koristi u SK Brisanje pravnog lica, SK Promena podataka o pravnom licu, SK Pretraga lanova.

106

Pretraga lanova
Ova stranica se prikazuje kad pravno lice eli da pretrai bazu podataka. Pravno lice unosi kriterijum za pretragu baze podataka lanova. Kada unese kriterijume klikne na dugme Pretrai.

Osnovni scenario SK 1. Pravno lice unosi kriterijume za pretragu lanova (APUSO) 2. Pravno lice poziva sistem da pretrazi bazu podataka lanova (APSO) 3. Sistem pretrauje bazu podataka (SO) Opis akcije: Pravno lice unese kriterijum i klikom na dugme Pretrazi, poziva sistem da vrati listu svih lanova koji odgovaraju zadatom kriterujumu pretrage, tj izvrava se SOpretraziClanoveIVrati(). 4. Sistem prikazuje zaposlenom podatke o lanovima koji odg ovaraju zadatom kriterijumu (IA).

107

Rezultat pretrage lanova

Kada firma zada kriterijume za pretragu lanova dobija odgovarajui rezultat, u vidu liste lanova koji zadovoljavaju kriterijume pretrage. Ovde je dat primer liste lanova koji zadovoljavaju kriterijum pretrage.

108

Admin meni
Admin meni se prikazuje posto je administrator uneo odgovarajuce korisniko ime i lozinku. U admin meniju je moguce brisati lanove i pravna lica, evidentirati lanarinu i snimiti vesti u bazu. Ova strana se prikazuje u sluaju korienja SK Evidentiranje lanarine, SK Brisanje lana od strane administratora, SK Brisanje firme od strane administratora .

Osnovni scenario SK 1. Administrator unosi podatke o lanu koga zeli da obrie (APUSO) 2. Administrator poziva sistem da obrie podatke o lanu (APSO) 3. Sistem brie podatke o lanu (SO) Opis akcije: Administrator popunjava polja i klikom na dugme Obrisi, poziva sistem da obrie korisnika sa zadatim username-om, tj izvrava se SObrisiClana() ili SObrisiFirmu(). 4. Sistem prikazuje administratoru poruku da je uspeno obrisan slog (IA)

109

5.1.3.4.2. Projektovanje kontrolera korisnikog interfejsa Uloga kontrolera korisnikog interfejsa je da [DrVlajic1]: Prihvati podatke koje alje ekranska forma; Konvertuje podatke (koji se nalaze u grafikim elementima) u objekat koji predstavlja ulazni argument SO koja e biti pozvana; alje zahtev za izvrenje SO do aplikacionog servera (softverskog sistema); Prihvata objekat (izlaz) softverskog sistema koji nastaje kao r ezultat izvrenja SO; Konvertuje objekat u podatke grafikih elemenata. U studijskom sluaju, kontroler korisnikog interfejsa realizovan je kao servlet. Centralni kontroler aplikacije prosledie poziv do kontrolera korisnikog interfejsa koji nastavlja izvrenje po prethodno utvrenom scenariju. Dajemo kao primer deo kontrolera korisnikog interfejsa:
public class GUIKontroler extends HttpServlet { private static final long serialVersionUID = 1L; private Context context; private KontrolerPLRemote kontrolerPL = null; // metode za inicijalizaaciju servleta protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html;charset=UTF-8"); int izbor = 0; // izbor predstavlja skretnicu kad dodje poziv sa jsp // strane izbor = Integer.parseInt(request.getParameter("Marker")); switch (izbor) { case 1: { prijavaClana(request, response); break; } case 2: { prijavaFirme(request, response); break; } case 3: { loginKorisnika(request, response); break; } case 4: { brisiKorisnika(request, response); break; } case 6: { pretraziClanove(request, response); break; } case 7: { evidentirajClanarinu(request, response); break; } case 8: { promeniClana(request, response); break; } }

110

5.1.3.5. Konani izgled arhitekture softverskog sistema Na sledeoj slici je data arhitektura aplikacije uradjena korienjem EJB 3.0 tehnologije. Na slici se vidi da je model uradjen iz vie nivoa.

GUIKontroler je servlet <<Interface>> KontrolerPLRemote snimiClana() snimiFirmu() proveriKorisnika() vratiKorisnika() brisiKorisnika() pretraziClanoveIVratiIh() evidentirajClanarinu() proveriClanarinu() promeniClana() promeniFirmu()

ProveriKorisnika LoginBean
(from sessionBeans)

<<Interface>> LoginRemote SnimiClana

(from sessionBeans)

proveriKorisnika() createLogin()

GUIKontroler

ClanBean PretraziClanoveIVratiIh <<Interface>> ClanRemote PromeniClana

(from sessionBeans) (from sessionBeans)

JSP stranice

createClan() readClan() deleteClan() updateClan() Baza podataka

BrisiKorisnika

FirmaBean
(from sessionBeans)

KontrolerPLBean VratiKorisnika snimiClana() snimiFirmu() proveriKorisnika() vratiKorisnika() brisiKorisnika() pretraziClanoveIVratiIh() evidentirajClanarinu() proveriClanarinu() promeniClana() promeniFirmu() <<Interface>> FirmaRemote
(from sessionBeans)

createFirma() readFirma() deleteFirma() updateFirma()

SnimiFirmu ClanarinaBean
(from sessionBeans)

PromeniFirmu

<<Interface>> ClanarinaRemote
(from sessionBeans)

createClanarina() readClanarina() deleteClanarina() updateClanarina()

ProveriClanarinu

EvidentirajClanarinu

DOfirma
(from DOMENSKI OBJEKTI)

Svi DO su Entity Bean-ovi

1 1..* DOclanarinaFirme
(from DOMENSKI OBJEKTI)

DOclan
(from DOMENSKI OBJEKTI)

Slika 17: Kompletna arhitektira softverskog sistema

111

5.4. Sazetak
U ovom poglavlju dat je prikaz studijskog primera korienjem uproene Larmanove metode razvoja softvera [DrVlajic1]. Pri tome su date sledee faze razvoja jednog softverskog sistema Prikupljanje zahteva Analiza Projektovanje Na osnovu rezultata faze projektovanja, faza implementacije je uradjena prvo u EJB 2.1 a potom u EJB 3.0 tehnologiji. Faza testiranja je u manjem obimu pokrivena u toku faze implementacije. Proizvodi dobijeni iz faze implementacije e biti analizirani i ceo postupak analize je dat u poglavlju 6.

112

6. KOMPARATIVNA ANALIZA EJB 2.1 I EJB 3.0 TEHNOLOGIJE

Jedan od ciljeva ovog rada je da se izvi statika i dinamika analiza softverskog si stema koji su implementirani korienjem EJB2.1 i EJB3.0 tehnologiji. U ovom poglavlju e taj cilj biti i ostvaren.

6.1. Statika analiza softverskog sistema

Statika analiza softverskog sistema predstavlja analizu kojom se opisuju statike osobine sistema. Ona nam govori kako je sistem projektovan, koliko ga je teko razumeti, menjati, odravati itd. Za statiku analizu studijskog primera koriene su softverske metrike koje podrava softverski paket Swat4j i Analyst4j. Akcenat je, pre svega, stavljen na objektnoorijentisane metrike, Metrike za odreivanje sloenosti i Metrike za odreivanje indeksa odravanja.

Slika 18: Model kvaliteta softvera EJB 2.1 tehnologija

113

Slika 19: Model kvaliteta softvera EJB 3.0 tehnologija

U nastavku emo dati prikaz vrednosti svih metrika definisanih u poglavlju 4.2. Napominjemo da su metrike zajednike za sve atribute kvaliteta softvera. Pri tome, za pojedine atribute kvaliteta softverskog sistema mo e se definisati razliit prag vrednosti metrike (Threshold). Prosena sloenost ponderisanih metoda (WMC) Kada je u pitanju EJB 2.1 tehnologija vrednost ove metrike iznosi 17.63. U EJB 3.0 tehnologiji vrednost metrike iznosi 8.2. Za dozvoljene vrednosti se smatra vrednost manja od 15.0. Vidi se da projekat uradjen EJB 2.1 tehnologijo m preao preko dozvoljene vrednosti. Takodje se vidi da je projekat napisan korienjen EJB 3.0 tehnologije dao vrlo dobar rezultat unutar dozvoljenih vrednosti. Na osnovu toga moemo zakljuiti da EJB 3.0 daje mnogo bolje rezultate za metriku WMC, od EJB 2.1 tehnologije. Prosean broj odgovora klase (RFC) Kada je pitanju EJB 2.1 tehnologija vrednost metrike iznosi 29.46. U EJB 3.0 tehnologiji vrednost metrike iznosi 17.25. Dozvoljene vrednosti za ovu metriku su manje od 26.8. Vidi se da projekat uradjen EJB 2.1 tehnologijom preao preko dozvoljene vrednosti. Sa druge strane EJB 3.0 je za ovu metriku dala mnogo bolje vrednosti koje su unutar dozvoljenih. Na osnovu toga moemo zakljuiti da EJB 3.0 daje mnogo bolje rezultate za metriku RFC, od EJB 2.1 tehnologije. 114

Prosean nedostatak kohezivnosti metoda u klasi (LCOM) Kada je pitanju EJB 2.1 tehnologija vrednost metrike iznosi 0.19. U EJB 3.0 tehnologiji vrednost metrike iznosi 0.44. Dozvoljene vrednosti za ovu metriku su manje od 0.4. Vidi se da projekat uradjen EJB 2.1 tehnologijom dao zadovoljavajui rezultat unutar dozvoljenih vrednosti. Sa druge strane EJB 3.0 je za ovu metriku dala loiji rezultat, koji je ak malo van dozvoljenih vrednosti. Na osnovu toga moemo zakljuiti da EJB 2.1 daje mnogo bolje rezultate za metriku LCOM, od EJB 3.0 tehnologije. Ovo se moe objasniti donekle prirodom EJB 3.0 tehnologije koja je uprostila pisanje koda i mnoge klase i interfejse generie sama tehnologija pa se osea nedostatak kohezije metoda u klasama. Prosena povezanost objekata (CBO) Kada je pitanju EJB 2.1 tehnologija vrednost metrike iznosi 3.63. U EJB 3.0 tehnologiji vrednost metrike iznosi 2.35. Dozvoljene vrednosti za ovu metriku su manje od 7.8. Vidi se da projekat za obe tehnologije daje zadovoljavajui rezultat unutar dozvoljenih vrednosti, stim to EJB 3.0 daje za nijansu bolji rezultat. Na osnovu toga moemo zakljuiti da su klase slabo povezane. Na taj nain su klase vie nezavisne i lake se mogu koristiti u drugim aplikacijama. Prosena dubina stabla nasleivanja (DIT) Kada je pitanju EJB 2.1 tehnologija vrednost metrike iznosi 1.24. U EJB 3.0 tehnologiji vrednost metrike iznosi 1.2. Dozvoljene vrednosti za ovu metriku su manje od 1.8 odnosno, vee od 2.2, u zavisnosti od toga koji atribut softvera se posmatra. Ova metrika je donekle specifina jer je za pojedine atribute kvaliteta softverskog sistema dat razliit prag vrednosti metrike (Threshold), to e biti objanjeno u nastavku izlaganja. Prosean broj podklasa (NOC) EJB 2.1 tehnologija je dala vrednost metrike 0.24, dok je EJB 3.0 tehnologiji dala vrednost metrike 0.6. Dozvoljene vrednosti za ovu metriku su manje od 0.4 odnosno, vee od 0.6, u zavisnosti od toga koji atribut softvera se posmatra. Ova metrika je donekle specifina jer je za pojedine atribute kvaliteta softverskog sistema dat razliit prag vrednosti metrike (Threshold), to e biti objanjeno u nastavku izlaganja. Prosena ciklina sloenost metoda (CC) EJB 2.1 tehnologija je dala vrednost metrike 1.16, dok je EJB 3.0 tehnologiji dala vrednost metrike 1.01. Dozvoljene vrednosti za ovu metriku su manje 2.4. Vidi se da obe tehnologije daju zadovoljavajui rezultat unutar dozvoljenih vrednosti, stim to EJB 3.0 daje za nija nsu bolji rezultat. Moemo zakljuiti da sloenost metoda nije velika, odnosno da primenjeni algoritam nema puno grananja i ispitivanja uslova.

115

Prosena Halstedova sloenost (HE) EJB 2.1 tehnologija je dala vrednost metrike 41791.88 , dok je EJB 3.0 tehnologiji dala vrednost metrike 18077.8. Dozvoljene vrednosti za ovu metriku su manje od 297725.4 . Vidi se da obe tehnologije daju zadovoljavajui rezultat unutar dozvoljenih vrednosti, stim to EJB 3.0 daje bolji rezultat. Poto je Halstedova sloenost u dozvoljenim granicama, moemo rei da nee biti potreban vei napor kako bi se uspeno odravao softverski sistem, odnosno uspeno implementirao novi korisniki zahtev. Prosean indeks odravanja (MI) EJB 2.1 tehnologija je dala vrednost metrike 121.88, dok je EJB 3.0 tehnologiji dala vrednost metrike 109.88. Dozvoljene vrednosti za ovu metriku su vee od 95. Vidi se da obe tehnologije daju zadovoljavajui rezultat unutar dozvoljenih vrednosti, stim to EJB 2.1 daje malo rezultat. Ove vrednosti ukazuju da je indeks mogunosti odravanja softverskog sistema dobar. U nastavku emo dati prikaz metrika za svaki atribut kvaliteta softverskog sistema. Testiranje Sa atributom Testiranje povezane su sledee softverske metrike: - Sloenost ponderisanih metoda (WMC); - Broj odgovora klase (RFC); - Nedostatak kohezivnosti metoda u klasi (LCOM); - Povezanost objekata (CBO); - Dubina stabla nasleivanja (DIT); - Broj podklasa (NOC); - Ciklina sloenost (CC) i - Halstedova sloenost (HE). Na Slici 31. i Slici 32. prikazane su metrike koje se odnose na atribut Testiranje.

116

Slika 20: Atribut Testiranje za EJB 2.1 tehnologiju

Slika 21: Atribut Testiranje za EJB 3.0 tehnologiju

117

Swat4j je dao ukupu ocenu 10.0 za EJB 2.1 tehnologiju. Sa druge strane ocena za EJB 3.0 tehnologiju je znatno manja i iznosi 7.42. Ovo se moe objasniti time sto EJB 3.0 tehnologija ima loije ocene za metrike Nedostatak kohezivnosti metoda u klasi (LCOM) i procenat polja u klasama koja nisu privatna.

Kvalitet projektovanja Sa atributom Kvalitet projektovanja povezane su sledee metrike: - Broj odgovora klase (RFC); - Nedostatak kohezivnosti metoda u klasi (LCOM); - Povezanost objekata (CBO); - Dubina stabla nasleivanja (DIT) i - Broj podklasa (NOC). Na sledeim slikama su projektovanja. predstavljene metrike koje se odnose na atribut Kvalitet

Slika 22: Atribut Kvalitet projektovanja za EJB 2.1 tehnologiju

118

Slika 23: Atribut Kvalitet projektovanja za EJB 3.0 tehnologiju

Swat4j je dao ukupu ocenu 10.0 za EJB 2.1 tehnologiju. Sa druge strane ocena za EJB 3.0 tehnologiju je znatno manja i iznosi 4.8. Performanse Sa atributom Performanse povezane su sledee metrike: - Broj odgovora klase (RFC) i - Povezanost objekata (CBO). Na sledeim slikama predstavljene su dobijene vrednosti metrika za atribut Performanse.

Slika 24: Atribut Performanse za EJB 2.1 tehnologiju

119

Slika 25: Atribut Performanse za EJB 3.0 tehnologiju

Swat4j je dao ukupu ocenu 10.0 za obe tehnologije iako se vidi na slikama da je EJB 2.1 tehnologija imala vrednost (RFC) iznad granine.

Razumljivost Sa atributom Razumljivost povezane su sledee metrike: - Sloenost ponderisanih metoda (WMC); - Broj odgovora klase (RFC); - Nedostatak kohezivnosti metoda u klasi (LCOM); - Povezanost objekata (CBO); - Dubina stabla nasleivanja (DIT); - Ciklina sloenost (CC) i - Halstedova sloenost (HE). Na sledeim slikama e biti predstavljene vrednosti metrika za atribut Razumljivost.

120

Slika 26: Atribut Razumljivost za EJB 2.1 tehnologiju

121

Slika 27: Atribut Razumljivost za EJB 3.0 tehnologiju

Swat4j je dao ukupu ocenu 10.0 za obe tehnologije iako se vidi na slikama da je EJB 2.1 i EJB 3.0 imaju vrednost metrike Nedostatak kohezivnosti metoda u klasi (LCOM) veu od granine. Odravanje Sa atributom Odravanje povezane su sledee metrike: - Sloenost ponderisanih metoda (WMC); - Broj odgovora klase (RFC); - Nedostatak kohezivnosti metoda u klasi (LCOM); - Povezanost objekata (CBO); - Dubina stabla nasleivanja (DIT); - Ciklina sloenost (CC); - Halstedova sloenost (HE); - Indeks odravanja (MI). Na sledeim slikama predstavljene su vrednosti metrika za atribut Odravanje. 122

Slika 28: Atribut Odravanje za EJB 2.1 tehnologiju

123

Slika 29: Atribut Odravanje za EJB 3.0 tehnologiju

Swat4j je dao ukupu ocenu 10.0 za obe tehnologije iako se vidi na slikama da je EJB 2.1 i EJB 3.0 imaju vrednost metrike Nedostatak kohezivnosti metoda u klasi (LCOM) veu od granine. Ponovno korienje Sa atributom Ponovno korienje povezane su sledee metrike: - Sloenost ponderisanih metoda (WMC); - Broj odgovora klase (RFC); - Nedostatak kohezivnosti metoda u klasi (LCOM); - Povezanost objekata (CBO); - Dubina stabla nasleivanja (DIT); - Broj podklasa (NOC); Na sledeim slikama prikazane su vrednosti metrika koje se odnose na atribut Ponovno korienje. 124

Slika 30: Atribut Ponovno korienje za EJB 2.1 tehnologiju

Slika 31: Atribut Ponovno korienje za EJB 3.0 tehnologiju

Swat4j je dao ukupu ocenu 10.0 za EJB 2.1 tehnologiju dok je EJB 3.0 ocenio vrlo niskom ocenom od 3.14.

125

Dobijene rezultate mogue je predstaviti i tabelarno. U Tabeli 10. dajemo prikaz dobijenih vrednosti metrika za atribute softverskog sistema. U redovima su prikazane odabrane softverske metrike i njihove vrednosti za posmatrane tehnologije, dok su u kolonama predstavljeni atributi kvaliteta softvera. Za svaki atribut softverskog sistema vezano je vie metrika. Sa druge strane, jedna metrika se moe odnositi na vie atributa softverskog sistema. Ukoliko dobijena vrednost metrike zadovoljava granicu definisanu za odreeni atribut softverskog sistema koristi se oznaka , a ukoliko ne zadovoljava koristi se oznaka .
Softverska metrika Atribut softverskog sistema Sloenost ponderisanih metoda (WMC) Testiranje Kvalitet projektovanja Performanse Razumljivost Odravanje Ponovno korienje

Objektno orjentisane metrike

Broj odgovora klase (RFC) Nedostatak kohezivnosti metoda u klasi (LCOM) Povezanost objekata (CBO) Dubina stabla nasledjivanja (DIT) Broj podklasa (NOC)

Metrike za odredjivanje sloenosti

Ciklina sloenost (McCabe) Halsedova sloenost (HE) Index odravanja (MI)

EJB 2.1: 17.63 EJB 3.0: 8.2 EJB 2.1: 29.46 EJB 3.0: 17.25 EJB 2.1: 0.19 EJB 3.0: 0.44 EJB 2.1: 3.63 EJB 3.0: 2.35 EJB 2.1: 1.24 EJB 3.0: 1.2 EJB 2.1: 0.24 EJB 3.0: 0.6 EJB 2.1: 1.16 EJB 3.0: 1.01 EJB 2.1: 41791.88 EJB 3.0: 18077.8 EJB 2.1: 121.88 EJB 3.0: 109.88

Metrike za odredjivanje indexa odravnja

Tabela 10: Matrini prikaz vrednosti softverskih metrika u modelu kvaliteta softvera 126

Sada na osnovu tabele sa prikazanim rezultatima moemo doneti neke zakljuke o pomenutim verzijama tehnologija. Iako je u pitanju ista tehnologija, ali dve njene razliite verzije, postoje razlike u ocenama pojedinih metrika, koje nisu zanemarljive. Ti zakljuci su sledei: 1. Primenom EJB 3.0 tehnologije se dobijaju metode koje su prostije od metoda koje su dobijene korienjem EJB 2.1 tehnologije. 2. Skup odgovora klase za metode EJB 3.0 je bolji od skupa odgovora klase za metode EJB 2.1. 3. Tehnologija EJB 2.1 pokazuje bolji parametar prosean nedostatak kohezije od metoda EJB 3.0. Ovo moe biti posledica toga to EJB 3.0 ne zahteva da se pisu EJB interfejsi, pa stoga se osea nedostatak kohezije na nivou celog projekta, u metodama EJB 3.0. 4. Obe tehnologije imaju slabo povezane klase to je dobro. 5. Ocene za dubinu stabla nasledjivanja su dobre za obe verzije tehnologija. 6. Obe tehnologije pokazuju da se njihovim korienjem dobijaju klase koje nisu sloene. 7. Korienjem ovih tehnologija dobijaju se aplikacije koje se lako odravaju. Kada se uzme u obzir cela tabela, dolazimo do sledeeg zakljuka: Korienjem obe tehnologije se dobijaju aplikacije koje se lako odravaju i koje nisu sloene. Pri tome EJB 3.0 prednjai po smanjenju sloenosti metoda i klasa u odnosu na EJB 2.1. Kada se uzme u obzir i injenica da je implementacija u EJB 3.0 tehnologiji imala 30tak klasa, a implementacija u EJB 2.1 imala preko 50 klasa, onda moemo rei da je korienje EJB 3.0 tehnologije znatno lakse, zahteva pisanje manje koda, a daje iste ili bolje rezultate. To je i bio postavljen cilj kada je razvijana EJB 3.0 tehnologija.

127

6.2. Dinamika analiza softverskog sistema

Nakon izvrene statike analize za koju su koriene softverske metrike, dajemo prikaz dinamike analize softverskog sistema. U tom kontekstu osmiljen je sledei plan testa: 1. Monitoring aplikacije: Analiza upotrebe memorije Analiza upravljanja nitima 2. Analiza performansi aplikacije: Analiza performansi kontrolera poslovne logike Analiza performansi sistemskih operacija Analiza performansi klasa koje rade CRUD operacije nad bazom podataka. 6.2.1. Monitoring aplikacije U okviru monitoringa aplikacije prikazuje se analiza upotrebe dinamike ( heap) memorije i analiza upravljanja nitima. U okviru analize upotrebe memorije daje se prikaz zauzete memorije (vrednost u trenutku merenja i najvea vrednost), kao i relativno vreme koje koristi Sakuplja smea (Garbadge collector GC) za uklanjanje objekata iz memorije na koji ne pokazuje ni jedna referenca. Sa druge strane, u okviru analize upravljanja nitima daje se prikaz broja aktivnih niti (vrednost u trenutku merenja i najvea vrednost). Monitoring aplikacije e obuhvatiti podizanje JBOSS aplikativnog servera, aplikacije na njemu i izvravanje sluaja korienja Snimanje novog clana. Tako emo stei bolju sliku o tome koliko je zauzee memorije i niti tokom ovog sluaja korienja. Isti koraci e biti izvreni u sluaju EJB 2.1 i EJB 3.0 tehnologija. Na prvoj slici dajemo grafiki prikaz monitoringa aplikacije pisane u EJB 2.1.

Slika 32: Monitoring aplikacije koja koristi EJB 2.1 tehnologiju

U prvom delu prikazano je korienje dinamike memorije. Prilikom izvravanja EJB 2.1 aplikacija, u trenutku testiranja je bilo zauzeto 41.013.744 B dinamike memorije (oznaeno je ljubiastom bojom), dok najvea koriena vrednost iznosi 80.475.072 B (oznaeno je crvenom bojom). U drugom delu je prikazano relativno vreme koje koristi GC koji je zaduen za uklanjanje objekata iz memorije na koje ne pokazuje ni jedna referenca. U trenutku testiranja to je bilo 1.1%, dok je maksimalna vrednost iznosila 2.2%. U treem delu je dat prikaz broja niti. U trenutku testiranja aktivno je bilo 50 niti koje su se nalazile u razliitim stanjima. Najvei broj aktivnih niti je iznosio 61. Na sledeoj slici dajemo grafiki prikaz monitoringa aplikacije pisane u EJB 3.0. 128

Slika 33: Monitoring aplikacije koja koristi EJB 3.0 tehnologiju

U prvom delu prikazano je korienje dinamike memorije. Prilikom izvravanja EJB 2.1 aplikacija, u trenutku testiranja je bilo zauzeto 55.552.512 B dinamike memorije (oznaeno je ljubiastom bojom), dok najvea koriena vrednost iznosi 89.079.416 B (oznaeno je crvenom bojom). U drugom delu je prikazano relativno vreme koje koristi GC koji je zaduen za uklanjanje objekata iz memorije na koje ne pokazuje ni jedna referenca. U trenutku testiranja to je bilo 3.3%, dok je maksimalna vrednost iznosila 13.4%. U treem delu je dat prikaz broja niti. U trenutku testiranja aktivno je bilo 52 niti koje su se nalazile u razliitim stanjima. Najvei broj aktivnih niti je iznosio 60. U Tabeli 11. dat je prikaz izvrenog monitoringa aplikacije. U redovima su prikazane tehnologije, dok su u kolonama prikazani serveri. Za svaku tehnologiju posmatrani su sledei parametri: 1. Zauzee dinamike memorije (jedinica mere je bajt); 2. Vreme koje koristi GC za uklanjanje objekata iz memorije na koje ne pokazuje ni jedna referenca; 3. Broj aktivnih niti. Pri tome, za svaki parametar je prikazana vrednost dobijena u trenutku bele enja performansi, kao i najvea vrednost postignuta za vreme izvravanja testa.
Tehnologija JBOSS aplikativni server Heap (B) GC (%) Threads (No) Current Max Current Max Current Max 41.013.744 80.475.072 1.1 2.2 50 61 55.552.512 89.079.416 3.3 13.4 52 60

EJB 2.1 EJB 3.0

Tabela 11: Prikaz rezultata dobijenih monitoringom aplikacije

Na osnovu izvrenog monitoringa aplikacije moemo doneti sledee zakljuke o posmatranim tehnologijama: 1. EJB 2.1 tehnologija zauzima manje dinamike ( Heap) memorije, od EJB 3.0 tehnologije. Ovo se moe objasniti injenicom da EJB 3.0 generie dobar deo interfejsa automatski, dok su ti interfejsi morali runo da se piu za EJB 2.1. 2. Vreme koje koristi Sakuplja smea (Garbadge collector GC) je vee kod EJB 3.0 tehnologije nego kod EJB 2.1. Ovo je povezano sa poveanim zauzeem memorije i vie rada u pozadini koji obeleava EJB 3.0 tehnologiju. 3. Broj aktivnih niti koje se nalaze u razliitim stanjima je priblino jednak kod obe tehnologije. 129

6.2.2. Analiza performansi delova aplikacije U okviru analize performansi delova aplikacije posmatraju se performanse kontrolera poslovne logike, performanse sistemskih operacija i performanse klasa koje rade CRUD operacije nad bazom podataka. U tom kontekstu se posmatraju metode klasa, odnosno rauna se vreme izvrenja (vremensko trajanje) svake metode. Takoe se rauna broj poziva svake metode. Na Slici 34. dat je prikaz dobijenih rezultata koji se odnose na metodu snimiClana kontrolera poslovne logike, kao i za ostale metode koje su relevantne sa sluaj korienja Snimanje novog lana. Podaci se odnose na EJB 3.0 tehnologiju.

Slika 34: Prikaz poziva metode snimiClana() kontrolera poslovne logike (EJB 3.0 tehnologija) Sada emo dati tabelaran prikaz snimljenih podataka, radi lakeg uporedjivanja. Metoda (Hot spots) kontrolerPL.KontrolerPLBean.snimiClana() sistemskeoperacije.AbstractOperacija.initBeans() sistemskeoperacije.SnimiClana.snimiClana() sistemskeoperacije.clan.ClanBean.createClan() domenskiobjekti.DOClan() Vreme (Self time) 0.402 0.127 0.049 0.054 0.010 Broj poziva (Invocations) 1 1 1 1 1

Kao to se moe videti, svaka metoda se poziva tano jednom. Pri tome, najdue traje izvrenje metode snimiClana klase KontrolerPLBean. (0.402 ms). Na sledeoj slici e biti prikazani podaci koji se odnose na EJB 2.1 tehnologiju. Takodje e biti praena metoda snimiClana i sluaj korienja Snimanje novog lana.

130

Slika 35: Prikaz poziva metode snimiClana() kontrolera poslovne logike (EJB 2.1 tehnologija)

Sada emo dati tabelaran prikaz snimljenih podataka, radi lakeg uporedjivanja. Metoda (Hot spots) sessionbeans.kontrolerPL.KontrolerPLBean.snimiClana() sistemskeoperacije.AbstractOperacija.initBeans() sistemskeoperacije.SnimiClana.snimiClana() sistemskeoperacije.clan.ClanBean.createClan() entity.doclan.DOClanBean() Vreme (Self time) 0.432 0.148 0.051 0.057 0.019 Broj poziva (Invocations) 1 1 1 1 1

Kao to se moe videti, svaka metoda se poziva tano jednom. Pri tome, najdue traje izvrenje metode snimiClana klase KontrolerPLBean. (0.432 ms). U nastavku dajemo prikaz izvrenja ostalih metoda (Tabela 12.). U redovima je dat prikaz poziva metoda, dok su u kolonama prikazane tehnologije. Za svaku tehnologiju posmatrani su sledei parametri: 1. Vreme izvrenja meto de i 2. Broj poziva metode.

131

EJB 2.1 tehnologija Vreme Broj poziva (Self time) (Invocations) sessionbeans.kontrolerPL.KontrolerPLBean.brisiKorisnika() 0.209 1 sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 sistemskeoperacije.BrisiKorisnika.brisiKorisnika() 0.117 1 sessionbeans.clan.ClanBean.deleteClan() 0.059 1 sessionbeans.kontrolerPL.KontrolerPLBean.snimiFirmu() 0.201 1 sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 sistemskeoperacije.SnimiFirmu.snimiFirmu() 0.058 1 sessionbeans.firma.FirmaBean.createFirma() 0.060 1 sessionbeans.kontrolerPL.KontrolerPLBean.brisiKorisnika() 0.209 1 sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 sistemskeoperacije.BrisiKorisnika.brisiKorisnika() 0.117 1 sessionbeans.firma.FirmaBean.deleteFirma() 0.064 1 sessionbeans.kontrolerPL.KontrolerPLBean.proveriKorisnika() 0.191 1 sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 sistemskeoperacije.ProveriKorisnika.proveriKorisnika() 0.024 1 sessionbeans.login.LoginBean.proveriKorisnika() 0.188 1 sessionbeans.kontrolerPL.KontrolerPLBean.pretraziClanoveIVratiIh() 0.245 1 sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 sistemskeoperacije.PretraziClanoveIVratiIh. pretraziClanoveIVratiIh () 0.150 1 sessionbeans.clan.findClanove() 0.111 1

Metoda (Hot spots)

EJB 3.0 tehnologija Vreme Broj poziva (Self time) (Invocations) 0.249 1 0.413 1 0.117 1 0.071 1 0.256 1 0.413 1 0.058 1 0.067 1 0.249 1 0.413 1 0.117 1 0.056 1 0.237 1 0.413 1 0.025 1 0.191 1 0.241 1 0.413 1 0.141 1 0.107 1

Tabela 12: Prikaz redosleda poziva metoda i rezultata dobijenih analizom metoda

132

Na osnovu podataka iznetih u tabela ma moemo primetiti da vreme izvravanja metoda u EJB 2.1 slino kao vreme izvravanja metoda u EJB 3.0. Ipak se kod ne kih metoda blago osea due vreme izvravanja za EJB 3.0 tehnologiju. Ovo se moe objasniti injenicom da EJB 3.0 generie veliki deo EJB intefejsa, dok su ti interfejsi u EJB 2.1 napisani runo. Drugim reima,deo posla programera je prebaen na EJB tehnologiju a cena toga je blago poveanje vremena izvrenja u nekim sliajevima.

6.3. Ocena posmatranih tehnologija

Na osnovu uradjene statike i dinamike analze sada moemo dati sumarni zakljuak o posmatranim tehnologijama. to se tie statike analize, korienjem obe tehnologije se dobijaju aplikacije koje se lako odravaju i koje nisu sloene. Pri tome EJB 3.0 prednjai po smanjenju sloenosti metoda i klasa u odnosu na EJB 2.1. Kada se uzme u obzir i injenica da je projekat u EJB 3.0 tehnologiji imao 30tak klasa, a projekat EJB 2.1 preko 50 klasa, onda moemo rei da je korienje EJB 3.0 tehnologije znatno lakse, zahteva pisanje manje koda, a daje iste ili bolje rezultate. Kada posmatramo dinamiku analizu, EJB 2.1 tehnologija zauzima manje dinamike ( Heap) memorije, od EJB 3.0 tehnologije. Ovo se moe objasniti injenicom da EJB 3.0 generie dobar deo interfejsa automatski, dok su ti interfejsi morali runo da se piu za EJB 2.1. Vreme koje koristi Sakuplja smea (Garbadge collector GC) je vee kod EJB 3.0 tehnologije nego kod EJB 2.1. Ovo je povezano sa poveanim zauzeem memorije i vie rada u pozadini koji obeleava EJB 3.0 tehnologiju. Takodje, moemo primetiti da vreme izvravanja metoda u EJB 2.1 slino kao vreme izvravanja metoda u EJB 3.0. Ipak se kod nekih metoda blago osea due vreme izvravanja za EJB 3.0 tehnologiju. Ovo se moe objasniti injenicom da EJB 3.0 generie veliki deo EJB intefejsa, dok su ti interfejsi u EJB 2.1 napisani runo. Konaan zakljuak koji se namee je da korienje EJB 3.0 tehnologije daje proizvod koji ima manju sloenost, manji broj klasa i lake odravanje nego EJB 2.1. Sa druge strane EJB 3.0 je za nijansu vie tehniki zahtevnija, jer zauzma malo vie memorije i ponegde due vreme izvravanja. Ovakav zakljuak je i intuitivno jasan jer predstavlja napredak tehnologije i pr ebacivanje posla sa oveka na mainu, tj sa programera na tehnologiju , uz blago poveanje hardverske zahtevnosti tehnologije.

133

6.4. Saetak
U ovom poglavlju je data komparativna analiza projekta uradjenog u EJB 2.1 i EJB 3.0 tehnologiji. Ona obuhvata statiku analizu korienjem softverskog alata Swat4, i dinamiku analizu korienjem softverskog alata NetBeans Profiler. Na osnovu izvrene analize softvera doneli smo zakljuke koji su izneti u poglavlju 6.3. Na taj nain smo realizovali etvrti cilj istraivanja (Izvriti komparativnu analizu Spring i EJB tehnologije).

134

7. ZAKLJUAK
U master radu su prikazani osnovni koncepti EJB 2.1 i EJB 3.0 tehnologije. EJB tehnologija omoguavaju razvoj sloenih (enterprise) aplikacija. Na osnovu definisanog predmeta istraivanja, na poetku istraivanja postavljeni su sledei ciljevi istraivanja: 1. Dati pregled EJB 2.1 tehnologije; 2. Dati pregled EJB 3.0 tehnologije; 3. Dati pregled ISO/IEC 9126 standarda; 4. Izvriti komparativnu analizu EJB 2.1 i EJB 3.0 tehnologije. U okviru ovog cilja definisani su sledei podciljevi: Izvriti statiku analizu tehnologija korienjem softverskih metrika; Izvriti dinamiku analizu tehnologija korienjem softverskih profajlera; Oceniti posmatrane tehnologije na osnovu softverskih metrika i profajlera. Najpre je dat prikaz EJB 2.1 tehnologije. Prikazane su Java komponente, kontejneri kao i struktura Java EE aplikacija. Nakon toga su objanjeni Enterprise bean-ovi (Session bean i Message-Driven bean), kao i relizacija perzistentnosti u EJB tehnologiji. Nakon toga je dat prikaz EJB 3.0 tehnologije. Prikazane su njene karakteristike i naglaene su razlike koje postoje izmedju EJB 2.1 i EJB 3.0. Akcenat je stavljen na perzistentnost i korienje anotacija u EJB 3.0 tehnologiji. Tokom rada smo utvrdili da EJB tehnologija ima sledee karakteristike: EJB tehnologija predstavlja de facto standard prilikom razvoja slo enih aplikacija; EJB koristi dobre osobine aplikacionog servera (deklarativno upraljvanje transakcijama, security...); Korienje Entity klasa EJB 3.0 tehnologije sada je mogue van aplikacionog servera; EJB 3.0 tehnologija preuzima dobre osobine drugih tehnologija; EJB tehnologija je u novoj verziji EJB 3.0 znaajno pojednostavljena i unapreena; Iz dosadanjeg istraivanja zakljuili smo da je EJB 3.0 u znatnoj meri pojednostavio razvoj velikih aplikacija. Iz dosadanjeg istraivanja smo zakljuili je EJB 3.0 tehnologija preuzela mnoge dobre osobine postojeih tehnologija. Tako su iskoriene dobre karakteristike Spring okvira (na primer, dodata je podrka za koncept IoC) i Hibernate okvira (dodate su anotacije, podrka za presikavanje klasa u POJO entitete za jednostavno obezbedjivanje perzistentnosti)... Na ovaj na in je tehnologija znatno poboljana i pojednostavljena. Mnoge stvari su automatizovane i kontejner ih izvrava u pozadini (bez eksplicitnog poziva korisnika). Tako e, u novoj specifikaciji omogueno je korienje Entity klasa EJB tehnologije van aplikacionog servera (na taj na in se Entity klase EJB tehnologije mogu koristiti kao i drugi ORM alati). Takoe, postoji i vie projekata u kojima je data implementacija Java EE perzistentnosti (Java EE persistence): na primer, Oracle TopLink [Oracle], kao i Apache OpenJPA [Apache]. Nakon prikaza EJB 2.1 i EJB 3.0 tehnologije dat je prikaz ISO/IEC 9126 standarda kojim se definie kvalitet softverskog sistema. Ovaj standard se sastoji iz etiri dela: ISO/IEC 9126-1 kojim se definie model kvaliteta softvera ( Quality model), ISO/IEC 9126-2 kojim se definiu eksterne metrike (External metrics), ISO/IEC 9126-3 kojim se definiu interne metrike (Internal metrics), 135

ISO/IEC 9126-4 kojim se definie kvalitet u korienju metrika (Quality in use metrics). Zatim je korienjem matematikih modela dat prikaz metrika koje se nalaze u softverskom paketu Swat4j (koji je, u stvari, zasnovan na ovom standardu). Za potrebe master rada kompletno je projektovan studijski primer, pri emu su date dve relizacije: jedna korienjem EJB 2.1 tehnologije, i druga korienjem EJB 3.0 tehnologije. Ove aplikacije su predstavljale osnovu za izvravanje statike analize softvera (koriene su softverske metrike koje zadovoljavaju ISO/IEC 9126 standard) kao i dinamike analize softvera (korien je profajler koji se mo e koristiti za optimizovanje aplikacija). Kada je u pitanju statika analiza softvera, na osnovu definisanog modela kvaliteta softvera dobijeni su sledei rezultati:
Testiranje Kvalitet projektovanja Performanse Razumljivost Odravanje Ponovno korienje

EJB 2.1 EJB 3.0

10.0 10.0

10.0 4.8

10.0 10.0

10.0 10.0

10.0 10.0

10.0 3.14

Na osnovu dobijenih vrednosti atributa u modelu kvaliteta softvera moemo rei da je aplikacija koja je razvijena korienjem EJB 2.1 tehnologije bolje projektovana i ima bolje ponovno korienje u odnosu na aplikaciju koja je razvijena korienjem EJB 3.0 tehnologije. Medjutim, treba naglasiti da Swat4j nije savrsen alat za statiku alanizu i da on nije uzeo u obzir anotacije koje se koriste u EJB 3.0 tehnologiji. To je u dobroj meri uticalo na loe ocene nekih parametara. Ipak, kada se radi analiza pojed ninih metrika dobili smo sledee zakljuke: 1. Primenom EJB 3.0 tehnologije se dobijaju metode koje su prostije od metoda koje su dobijene korienjem EJB 2.1 tehnologije. 2. Skup odgovora klase za metode EJB 3.0 je bolji od skupa odgovora klase za metode EJB 2.1. 3. Tehnologija EJB 2.1 pokazuje bolji parametar prosean nedostatak kohezije od metoda EJB 3.0. Ovo moe biti posledica toga to EJB 3.0 ne zahteva da se pisu EJB interfejsi, pa stoga se osea nedostatak kohezije na nivou celog projekta, u metodama EJB 3.0. 4. Obe tehnologije imaju slabo povezane klase to je dobro. 5. Ocene za dubinu stabla nasledjivanja su dobre za obe verzije tehnologija. 6. Obe tehnologije pokazuju da se njihovim korienjem dobijaju klase koje nisu sloene. 7. Korienjem ovih tehnologija dobijaju se aplikacije koje se lako odravaju. Nakon statike analize softverskog sistema izvrena je dinamika analiza softverskog sistema korienjem profajlera. U tom kontekstu izvren je monitoring aplikacije, kao i analiza performansi delova aplikacije. Na osnovu izvrenog monitoringa aplikacije doneli smo sledee zakljuke o posmatranim tehnologijama: 1. EJB 2.1 tehnologija zauzima manje dinamike ( Heap) memorije, od EJB 3.0 tehnologije. Ovo se moe objasniti injenicom da EJB 3.0 generie dobar deo interfejsa automatski, dok su ti interfejsi morali runo da se piu za EJB 2.1. 2. Vreme koje koristi Sakuplja smea (Garbadge collector GC) je vee kod EJB 3.0 tehnologije nego kod EJB 2.1. Ovo je povezano sa poveanim zauzeem memorije i vie rada u pozadini koji obeleava EJB 3.0 tehnologiju. 136

3. Broj aktivnih niti koje se nalaze u razliitim stanjima je priblino jednak kod obe tehnologije. Na osnovu izvrene analize performansi delova aplikacije doneli smo sledee zakljuke: Na osnovu podataka iznetih u tabelama moemo primetiti da vreme izvravanja metoda u EJB 2.1 slino kao vreme izvravanja metoda u EJB 3.0. Ipak se kod nekih metoda blago osea due vreme izvravanja za EJB 3.0 tehnologiju. Ovo se moe objasniti injenicom da EJB 3.0 generie veliki deo EJB intefejsa, dok su ti interfejsi u EJB 2.1 napisani runo. Eventualni dalji pravci istraivanja odnosili bi se na detaljnije prouavanje savremenih softverskih arihitektura i metoda razvoja softvera, softverskih uzora, softverskih metrika i profajlera, kao i na definisanje kompletnog okvira kojim bi se mogla izvriti evaluacija performansi odreene tehnologije. Imajui sve to u vidu, oekuje se da e u narednom periodu doi do znaajnih kvalitativnih i kvantitativnih poboljanja Jave kao platforme za razvoj aplikacija kao i njeno potpuno preseljenje u Open Source svet. Pri tome mislim na Sun-ovu implementaciju Java6, koja trenutno nije potpuno otvoren kod, jer sadri neke biblioteke koje nisu vlasnitvo firme Sun Microsystems i nemaju licencu otvorenog koda.

137

8. LITERATURA
1. [JBOSS] Allesio Soldano, Andreadis Dimitris, Bill Burke, Brian Stansberry i drugi: Jboss Application Server 4.2.2 - Administration And Development Guide 2. [BB] Bill Burke, Richard Monson-Haefel: Enterprise JavaBeans, 3.0, O'Reilly, 2006. 3. [DPanda] Debu Panda, Reza Rahman, Derek Lane: EJB 3 in Action, Manning Publications, 2007 4. [DrVlaji1] Dr Sinia Vlaji: Projektovanje programa (Skripta), FON, Beograd 2004. 5. [DrVlaji2] Dr Sinia Vlaji, prof. dr Vidojko iri, Duan Savi: Projektovanje programa (Praktikum programski jezik Java), FON, Beograd, 2003. 6. [DrVlaji3] Dr Sinia Vlaji: Napredni koncepti Jave i web programiranje u Javi, FON, Beograd 2005. 7. [EdRoman] Ed Roman, Rima Patel, Gerald Brose: Mastering Enterprise JavaBeans, Third edition 8. [EJB2.1KickStart] EJB 2.1 Kick Start : Implementing a Solution Using EJB 2.1: http://www.stardeveloper.com/articles/display.html?article=2002121701&page=1 9. [EJB3.0Tutorial] EJB 3.0 tutorial with JBOSS: http://www.laliluna.de/ejb-3-tutorial-jboss.html 10. [ImplEJB2.1CMP] Implementing an EJB 2.1 Entity Bean with CMP:
http://download.oracle.com/docs/cd/B31017_01/web.1013/b28221/ent21imp001.htm

11. [ISO 9126] ISO 9126 standard: http://www.issco.unige.ch/projects/ewg96/node13.html 12. [ISO 9126Wiki] ISO/IEC 9126 standard: http://en.wikipedia.org/wiki/ISO_9126 13. [ISO 9126_1] ISO/IEC 9126-1:2001, Part 1: Quality model,
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749

14. [ISO 9126_2] ISO/IEC TR 9126-2:2003, Part 2: External metrics,

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22750

15. [ISO 9126_3] ISO/IEC TR 9126-3:2003, Part 3: Internal metrics,

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22891

16. [ISO 9126_4] ISO/IEC TR 9126-4:2004, Part 4: Quality in use metrics,

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39752

17. [JenniferBall] Jennifer Ball, Debbie Carson, Ian Evans, Scott Fordin, Kim Haase, Eric Jendrock: The Java EE 5 Tutorial, Third Edition: For Sun Java System Application Server Platform Edition , Addison Wesley Professional, 2006. 18. [JavaBoutique_1]Measuring the Complexity of OO System: http://javaboutique.internet.com/tutorials/metrics/ 19. [JavaBoutique_2]Metrics for Object Oriented Software Development: http://javaboutique.internet.com/tutorials/codemetrics/ 20. [MartinBond] Martin Bond, Dan Haywood, Debbie Law, Andy Longshaw, Peter Roxburgh: Teach yourself J2EE in 21 days, Sams 21. [MikeKeith] Mike Keith, Merrick Schincariol: Pro EJB 3: Java Persistence API, Apress, 2006. 22. [Raghu] Raghu R. Kodali, Jonathan R. Wetherbee, Peter Zadrozny: Beginning EJB 3 Application Development: From Novice to Professional, Apress, 2006. 23. [Rod Johnson] Rod Johnson: Expert One-on-One J2EE Design and Development, Wiley Publishing, 2002. 24. [Krsmanovi] Srdjan Krsmanovi: Softverski sistem agencije za zapoljavanje u J2EE okruenju, FON, Beograd, 2007 25. [ZWSwat4j] Zvanina web prezentacija softverskog paketa Swat4j:
http://www.codeswat.com/cswat/index.php?option=com_content&task=view&id=12&Itemid=27

138

26. [ZWAnalyst4j] Zvanina web prezentacija softverskog paket a Analyst4j: http://www.codeswat.com/cswat/index.php?option=com_content&task=view&id=43&Itemid=63

27. [ZWEclipse] Zvanina web prezentacija Eclipse Test & Performance Tools Platform Project: http://www.eclipse.org/tptp/ 28. [ZWNetBeans] Zvanina web prezentacija The NetBeans Profiler Project: http://profiler.netbeans.org/ 29. [ZWJBoss] Zvanina web prezentacija JBOSS aplikativnog servera: http://www.jboss.org/

139