Embed Size (px)
DESCRIPTION
knjiga
Citation preview
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 Siniša Vlajić, doc.
Beograd, Jul 2009. godine
ii
Komisija koja je pregledala rad i odobrila odbranu:
Mentor: dr. Siniša Vlajić, docent
-----------------------------------------
Ĉlan: dr. Dušan Starĉević, redovni profesor
---------------------------------
Ĉlan: dr. Siniša Nešković, docent
-----------------------------------------
iii
Apstrakt:
U ovom radu će biti predstavljene dve verzije EJB tehnologije, EJB 2.1 i EJB 3.0, koje
se koriste za razvoj sloţenih aplikacija. Nakon prikaza tehnologija biće dat pregled ISO/IEC
9126 standarda za ocenjivanje kvaliteta softvera. Zatim će na osnovu studijskog primera biti
izvršena ocena posmatranih tehnologija korišćenjem softverskih metrika zasnovanih na
ISO/IEC 9126 standardu i softverskih profajlera. Softverske metrike će se koristiti za statiĉku
analizu softvera, a softverski profajleri za dinamiĉku analizu softvera.
Kljuĉne reĉi: 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
iv
Curriculum Vitae
Liĉni podaci
Ime i prezime: Srdjan Krsmanović
Telefon: 064/225-0945
E-mail: [email protected]
Datum rodjenja: 8.4.1982. god.
Pol: muški
Obrazovanje:
(2007 - 2009) Fakultet organizacionih nauka, Beograd, Master studije iz oblasti
softverskog inţenjerstva
(2001 - 2007) Fakultet organizacionih nauka, Beograd, Odsek za informacione
sisteme i tehnologije, proseĉna ocena 8.53
(1998 - 2001) Elektrotehniĉka škola Nikola Tesla, Beograd
Radno iskustvo:
(maj 2008 - danas) Sportska kladionica MOZZART, Software developer
(januar 2007 – maj 2008) Mega Computer Engineering, Software developer
(maj 2007) Diplomski rad na temu „Informacioni sistem agencije za
zapošljavanje u J2EE okruţenju“
Ostale veštine:
Vozaĉka dozvola: B kategorija
Ostala interesovanja: elektriĉna gitara, liĉno usavršavanje, druţenje
v
Zahvalnica
Ţeleo bih, ovom prilikom, da se zahvalim mojoj porodici na velikoj podršci koju mi je
pruţila tokom redovnih studija, a posebno mojoj majci bez ĉijih saveta i pomoći ovaj rad ne bi
video svetlost dana.
Hvala Vam svima!
vi
SADRŢAJ:
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. Saţetak ............................................................................................................................... 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. Presretaĉi ................................................................................................................... 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. Karakteristiĉne anotacije za O/R presikavanje .................................................... 41
vii
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 presretaĉe i ţivotni ciklus bean-a ............................................................ 53 3.9.4. Anotacije za izuzetke, zaštitu pristupa i timeout ......................................................... 54
3.9.5. Anotacije za EJB reference i Resource reference ........................................................ 55 3.10. Saţetak ............................................................................................................................. 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. Saţetak ............................................................................................................................... 73
5. STUDIJSKI PRIMER ............................................................................................................... 74 5.1. Uprošćena Larmanova metoda razvoja softvera .................................................................. 74
5.1.1. Zahtevi ....................................................................................................................... 74 5.1.1.1. Verbalni model ................................................................................................... 74
5.1.1.2. Sluĉajevi korišćenja sistema ................................................................................ 74 5.1.1.3. Opis sluĉaja korišćenja........................................................................................ 75
5.1.2. Analiza ....................................................................................................................... 82 5.1.2.1. Ponašanje 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. Skladište podataka ............................................................................................ 100
5.1.3.4. Projektovanje korisniĉkog interfejsa ................................................................. 101 5.1.3.4.1. Ekranske forme ......................................................................................... 102
5.1.3.4.2. Projektovanje kontrolera korisniĉkog interfejsa ......................................... 110 5.1.3.5. Konaĉni izgled arhitekture softverskog sistema ................................................. 111
5.4. Sazetak ............................................................................................................................. 112 6. KOMPARATIVNA ANALIZA EJB 2.1 I EJB 3.0 TEHNOLOGIJE ....................................... 113
6.1. Statiĉka analiza softverskog sistema ................................................................................. 113 6.2. Dinamiĉka 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. Saţetak ............................................................................................................................. 134
7. ZAKLJUĈAK ......................................................................................................................... 135 8. LITERATURA ....................................................................................................................... 138
viii
Lista slika:
Slika 1: Scenario izvršavanja 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 utvrĊivanje efektivnosti [ISO9126_4] ........................................................... 62 Slika 12: Odnos izmedju atributa softverskog sistema, softverskih metrika i pravila u pisanju
programskog koda ......................................................................................................................... 64 Slika 13: Sluĉajevi korišćenja 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 Odrţavanje za EJB 2.1 tehnologiju ................................................................... 123 Slika 29: Atribut Odrţavanje za EJB 3.0 tehnologiju ................................................................... 124
Slika 30: Atribut Ponovno korišćenje za EJB 2.1 tehnologiju ...................................................... 125 Slika 31: Atribut Ponovno korišćenje 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
ix
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 greške ............................................................................................ 63 Tabela 5: Odabrane metrike u modelu kvaliteta softverskog paketa Swat4j ................................... 72
Tabela 6: Skladište podataka - tabela Clan .................................................................................. 100 Tabela 7: Skladište podataka - tabela Firma ............................................................................... 101
Tabela 8: Skladište podataka - tabela Clanarina Firme................................................................ 101 Tabela 9: Skladište podataka - tabela Login ............................................................................... 101
Tabela 10: Matriĉni 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
1
1. UVOD
Današnju kompjutersku tehnologiju karakteriše veoma brz stepen razvoja. Ovo je
naroĉito izraţeno u oblasti softverskog inţenjerstva. Svakim danom se radjaju ideje kako
ubrzati razvoj softvera i olakšati posao programera, a na svakih par godina, poneka ideja se
razvije u neku novu tehnologiju. Postojeće tehnologije evoluiraju a nove se kreiraju, teţeći da
otklone probleme koje su imale njihove prethodnice. Kada se postavlja pitanje koju
tehnologiju koristiti za razvoj sloţenih (Enterprise) aplikacija ĉest izbor je EJB tehnologija
(Enterprise Java Beans) [JenniferBall] [BB] [DPanda].
Ovaj rad predstavlja logiĉan 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 znaĉajno napredovala
[JenniferBall].
Takodje se definišu i standardi u oblasti softverskog inţenjerstva. Tako je, na primer,
MeĊunarodna 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 definiše kvalitet softvera. U standardu su definisani atributi
kvaliteta softverskog sistema, kao i softverske metrike [JavaBoutique1] [JavaBoutique2] na
osnovu kojih je moguće izvršiti statiĉku analizu softverskog sistema.
Pored statiĉke analize, postoji i dinamiĉka analiza softverskog sistema koja se zasniva
na korišćenju softverskih paketa (na primer, The NetBeans Profiler Project [ZWNetBeans],
Eclipse Test & Performance Tools Platform Project [ZWEclipse]) namenjenih praćenju
performansi softverskog sistema. Na osnovu dinamiĉke analize softverskog sistema moguće
je uoĉiti delove aplikacije koji se sporo izvršavaju, zauzimaju memorijski prostor itd.
Predmet istraţivanja 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 istraţivanja postavljeni su sledeći ciljevi
istraţivanja:
1. Dati pregled EJB 2.1 tehnologije;
2. Dati pregled EJB 3.0 tehnologije;
3. Dati pregled ISO/IEC 9126 standarda;
4. Izvršiti komparativnu analizu EJB 2.1 i EJB 3.0 tehnologije. U okviru ovog cilja
definisani su sledeći podciljevi:
Izvršiti statiĉku analizu tehnologija korišćenjem softverskih metrika;
Izvršiti dinamiĉku analizu tehnologija korišćenjem softverskih profajlera;
Oceniti posmatrane tehnologije na osnovu softverskih metrika i profajlera.
2
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 objašnjeni Enterprise bean-ovi u
EJB 2.1 tehnologiji, kao i relizacija perzistentnosti u EJB 2.1.
U trećem poglavlju dat je prikaz EJB 3.0 tehnologije. Pošto je to novija verzija iste
tehnologije, akcenat je stavljen na razlike i poboljšanja uvedena izmedju posmatranih verzija.
Takodje je više okrenuta paţnja perzistentnosti u EJB 3.0.
U ĉetvrtom poglavlju prikazan je ISO/IEC 9126 standard kojim se definiše kvalitet
softverskog sistema. Ovaj standard se sastoji iz ĉetiri dela:
1. ISO/IEC 9126-1 [ISO9126_1] kojim se definiše model kvaliteta softvera (Quality
model),
2. ISO/IEC 9126-2 [ISO9126_2] kojim se definišu eksterne metrike (External metrics),
3. ISO/IEC 9126-3 [ISO9126_3] kojim se definišu interne metrike (Internal metrics) i
4. ISO/IEC 9126-4 [ISO9126_4] kojim se definiše kvalitet u korišćenju metrika (Quality
in use metrics).
Zatim je korišćenjem matematiĉkih modela dat prikaz metrika koje se nalaze u softverskom
paketu Swat4j [ZWSwat4j] koji predstavlja dodatak za razvojno okruţenje Eclipse.
U petom poglavlju dat je prikaz studijskog primera korišćenjem Larmanove metode
razvoja softvera.
U šestom poglavlju je izvršena statiĉka i dinamiĉka analiza softverskog sistema
korišćenjem softverskog alata Swat4j i NetBeans Profiler. Rezultati analize su dati tabelarno i
izvedeni su odgovarajući zakljuĉci.
U sedmom poglavlju data su zakljuĉna razmatranja o posmatranim tehnologijama.
3
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 biće objašnjene 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
izvršava, ĉime je obezbeĊena prenosivost (portabilnost) aplikacija razvijenih u Javi. Napisana
aplikacija se moţe izvršiti 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, preslikavajući ih u naredbe konkretnog operativnog
sistema.
TakoĊe, programski jezik je u potpunosti nezavistan od konkretnih Sistema za
upravljanje bazama podataka (DBMS - Database Management System), ĉime se, uz
obezbeĊivanje odgovarajućih upravljaĉkih programa (drajvera) omogućava povezivanje
aplikacije sa konkretnim DBMS sistemima i preslikavanje opštih Java naredbi u naredbe
konkretnog DBMS.
Razlikujemo tri izdanja Java platforme. Svako izdanje namenjeno je razvoju
specifiĉnih aplikacija i obezbeĊuje drugaĉije izvršno (runtime) okruţenje:
1. Java 2 Standard Edition, J2SE – obezbeĊuje izvršno okruţenje za razvoj desktop aplikacija
i predstavlja jezgro funkcionalnosti za naredna izdanja Java platforme;
2. Java Enterprise Edition, JEE – predstavlja nadskup J2SE koji podrţava razvoj enterprise
aplikacija;
3. Java 2 Micro Edition, J2ME – definiše skup izvršnih okruţenja za razvoj aplikacija za
embedded ureĊaje kao što su mobilni telefoni, PDA ureĊaji, TV ureĊaji i ostali ureĊaji koji
imaju manjak resursa da podrţe J2SE ili JEE.
Java platforma za razvoj enterpise aplikacija (JEE) moţe se podeliti u ĉetiri dela koja
prate odgovarajuće 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:
4
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)
Zaštita (Security)
Java servis poruke (Java Message Service)
JEE platforma podrţava [DrVlajic3]:
Višenivojski distribuirani aplikacioni model
Komponente koje se mogu ponovo koristiti
Jedinstveni model zaštite
Prilagodljivu transakcionu kontrolu
Web servise koji su zasnovani na XML standardnima i protokolima.
JEE platforma koristi distribuirani više-nivojski model (obiĉno tronivojski model) za razvoj
JEE enterprise aplikacija (sloţenih aplikacija). JEE aplikacija sastoji se od JEE komponenti
koje su instalirane na razliĉitim raĉunarima. Komponente, odnosno raĉunari na kojima se
izvršavaju komponente su dodeljene razliĉitim nivoima JEE aplikacije (Slika 1.) [DrVlajic3]:
1. Klijentski nivo – komponente koje se izvršavaju na klijentskim raĉunarima
2. Nivo aplikacione logike – komponente koje se izvršavaju na JEE serveru. Ovaj nivo je
podeljen na dva podnivoa:
Web nivo
Poslovni nivo
3. Enterprise information system (EIS) nivo – komponente koje se izvršavaju na EIS serveru
(obiĉno je to neki sistem za upravljanje bazama podataka – Database Management System
DBMS).
1. Klijentski nivo
2. Nivo aplikativne logike 2.1 Web nivo
2.2 Poslovni nivo
3. EIS nivo
Tabela 1: Nivoi JEE aplikacije
JEE komponente su pisane u Java programskom jeziku i kompajliraju se na isti naĉin
kao i bilo koji drugi program pisan u Javi. Razlika izmeĊu JEE komponenti i „standardnih“
Java klasa se ogleda u tome da se JEE komponente ugraĊuju (assembled) u JEE aplikaciju
ako zadovoljavaju JEE specifikaciju. JEE aplikacije se izvršavaju u okruţenju JEE servera
koji ima ulogu da prati i upravlja izvršenjem JEE aplikacije.
Pri tome je bitno napomenuti da se sve specifikacije koje se odnose na Javu i
odgovarajuće tehnologije definišu kroz JCP (Java Community Process, [ZWJCP]) za koji je
zaduţen Sun Microsystems. JCP je otvorena organizacija, njeni ĉlanovi su individue i
organizacije koje dele zajedniĉki interes viĊenja Java tehnologije koja zadovoljava trţišne
zahteve i koja evoluira. JCP proces je krajnje jednostavan: JCP ĉlanovi koji ţele da prošire
Java platformu podnose formalni predlog JSR (Java Specification Request) koji prolazi kroz
poznati ţivotni ciklus glasanja, kritika, testiranja i odluke.
5
2.2. Java EE komponente
Kao što je već napomenuto JEE aplikacije se sastoje od komponenti. U Java EE
specifikaciji razlikujemo sledeće komponente:
Aplikacioni klijenti i apleti (komponente koje se izvršavaju na strani klijenta);
Java Servlet, JavaServer Faces i JavaServer Pages predstavljaju web komponente
koje se izvršavaju na strani servera;
EJB (Enterprise Java Beans) predstavljaju poslovne komponente koje se izvršavaju na
serverskoj strani.
Web klijenti se ĉesto nazivaju tanki klijenti. Tanki klijenti obiĉno ne izvršavaju upite
nad bazom podataka i ne izvršavaju sloţena poslovna pravila. Web klijenti se sastoje iz dva
dela [JenniferBall]:
1. Dinamiĉke web strane koje su zasnovane na nekom markup jeziku (na primer HTML,
XML...) koje se generišu na osnovu web komponenti koje se izvršavaju na web nivou;
2. Web čitača koji je zaduţen za prikazivanje (renderovanje) strana koje dobija kao
odgovor servera.
Aplet (Applet) predstavlja klijentsku aplikaciju napisanu u programskom jeziku Java
koja se izvršava pomoću Java virtuelne mašine klijentskog sistema uz korišćenje internet
ĉitaĉa. MeĊutim, klijentskim sistemima je najĉešće potreban odgovarajući Java plug-in i
verovatno policy datoteka jer su apleti priliĉno restriktivni kada je u pitanju pristup lokalnom
datoteĉnom sistemu.
Aplikacioni klijenti se izvršavaju na klijentskom sistemu i omogućavaju izvršenje
zadataka u okruţenju koje ima znaĉajno bolji korisniĉki interfejs. Najĉešće se za realizaciju
korisniĉkog interfejsa koristi Swing ili AWT (Abstract Window Toolkit) API. Aplikacioni
klijenti mogu direktno pristupiti EJB komponentama koje se izvršavaju na poslovnom nivou.
TakoĊe, aplikacioni kljenti mogu uspostaviti HTTP konekciju i na taj naĉin komunicirati sa
servletima koji se izvršavaju na poslovnom nivou.
Java EE web komponente su ili servleti ili strane koje su kreirane korišćenjem JSP
tehnologije (JSP strane) i/ili JavaServer Faces (JSF) tehnologije. JSF tehnologija zasnovana
je na servletima i JSP tehnologiji i definiše okvir koji se sastoji od komponenti namenjenih za
realizaciju korisniĉkog interfejsa web aplikacija. Na ovaj naĉin mogu se formirati „bogate“
internet aplikacije. Za poslovnu logiku aplikacije zaduţeni su EJB komponente koje se
izvršavaju u okviru poslovnog sloja. Na Slici 2. prikazan je tipiĉan scenario po kome EJB
komponente prihvataju podatke iz klijentskih programa, procesiraju ih (ukoliko je potrebno) i
šalju ih do EIS nivoa kako bi ih saĉuvali u odgovarajućem sistemu za upravljanje bazom
podataka. TakoĊe, EJB komponente prihvataju podatke iz skladišta podataka, obraĊuju ih
(ukoliko je potrebno) i prosleĊuju ih do klijentskih programa.
6
Slika 1: Scenario izvršavanja 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 omogućava jednostavan razvoj aplikacija, jer se poslovna logika
organizuje u komponente koje se mogu ponovo koristiti. Pored toga, Java EE server
obezbeĊuje dodatne servise koji se mogu koristiti unutar odgovarajućeg kontejnera.
Kontejneri predstavljaju interfejs izmeĊu komponenti i platformski specifiĉnih
funkcionalnosti koji podrţavaju izvršavanje komponenti. Na primer, pretpostavimo da je
potrebno pokrenuti web aplikaciju. Najpre se web aplikacija mora spakovati u odgovarajući
web modul i postaviti u web kontejner. Na ovaj naĉin se specificiraju podešavanja kontejnera
za svaku komponentu Java EE aplikacije kao i za samu Java EE aplikaciju. Tipiĉni servisi
koje obezbeĊuje Java EE server su zaštita (security), upravljanje transakcijama (transaction
management), JNDI pozivi (Java Naming and Directory Intrerface), daljinsko povezivanje
(remote connectivity)...
Na ovaj naĉin ostvaruju se višestruke prednosti:
Java EE security model omogućava definisanje odgovarajućih mehanizama zaštite
web komponenti ili EJB komponenti tako da im mogu pristupiti samo autorizovani
korisnici;
Java EE transaction model omogućava specificiranje odnosa metoda koje ĉine jednu
transakciju ĉime se obezbeĊuje da se sve metode koje ĉine jednu transakciju
posmatraju kao jedinstvena jedinica;
Java EE remote connectivity model zaduţen je za upravljanje komunikacijama izmeĊu
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 mašine.
7
Pošto Java EE arhitektura omogućava korišćenje servisa koji se mogu konfigurisati,
komponente Java EE aplikacije se mogu ponašati razliĉito u zavisnosti od mesta gde su
rasporeĊene. Na primer, EJB moţe imati podešene zaštitne mehanizme koji mu omogućavaju
jedan nivo pristupa bazi podataka u nekom izvršnom okruţenju, ili drugaĉiji nivo pristupa
podacima u drugom izvršnom okruţenju.
Kontejner takoĊe upravlja servisima koji se ne konfigurišu: ţivotnim ciklusima
servlet-a i enterprise bean-ova, datasource connection pooling-om, perzistentnošću podataka
(data persistence) i pristupom do Java EE API-ja.
Na Slici 2. predstavljene su Java EE komponente koje se izvršavaju u okviru
odgovarajućih kontejnera. Razikujemo nekoliko kontejnera [JenniferBall]:
Java EE server: izvršni deo Java EE proizvoda. Unutar Java EE server-a nalaze se
EJB i web kontejner;
EJB (Enterprise JavaBeans) kontejner: Upravlja izvršenjem enterprise bean-ova Java
EE aplikacija. Enterprise bean-ovi i njihov kontejner izvršavaju se na Java EE
serveru;
Web kontejner: Upravlja izvršenjem JSP strane i servlet komponente Java EE
aplikacije. Web komponente i njihov kontejner izvršavaju se na Java EE serveru;
Application Client Container: Upravlja izvršenjem aplikacionih komponenti klijenta.
Aplikacioni klijenti i njihov kontejner izvršavaju se na klijentskom sistemu (client
machine);
Applet container: Upravlja izvršenjem apleta. Sastoji se od web čitača i odgovarajućeg
plug-in mehanizma koji se zajedno izvršavaju na klijentskom sistemu.
Slika 2: Java EE server i kontejneri [JenniferBall]
8
2.4. Struktura Java EE aplikacija
Java EE aplikacije se pakuju u jednu ili više standardnih jedinica za rasporeĊivanje
(deployment units). Svaka jedinica se sastoji iz sledećih komponenti:
Funkcionalne komponente (enterprise bean-ovi, JSP strane, servleti, apleti...);
Opisivaĉ rasporeda (Deployment descriptor) koji opisuje sadrţaj aplikacije.
Nakon postavljanja aplikacije na odgovarajući server (podsetimo se, potreban je Java
EE server) aplikacija se moţe izvršiti. Pri tome, moţe 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 isporuĉuje u obliku EAR datoteke (Enterprise Archive) koja, u
stvari, predstavlja standardnu Java arhivu (Java archive, JAR) koja ima .EAR ekstenziju.
Korišćenje EAR datoteka i modula omogućava sklapanje većeg broja razliĉitih Java EE
aplikacija koje se mogu zasnivati na istim komponentama. Drugim reĉima, nije neophodno
dodatno pisanje programskog kôda; samo je potrebno na odgovarajući naĉin spakovati
razliĉite Java EE module u jedinstvenu EAR datoteku. Na Slici 3. je prikazana struktura Java
EE aplikacije. Kao što se moţe videti, EAR datoteka sastoji se iz Java EE modula i opisivaĉa
rasporeda (deployment descriptor). Opisivaĉ rasporeda je XML datoteka koja opisuje
podešavanja aplikacije, modula ili komponenti. Bitno je napomenuti da je sadrţaj opisivaĉa
rasporeda deklarativan tako da se on moţe promeniti bez potrebe za modifikovanjem
programskog kôda. U vreme izvršavanja Java EE server ĉita sadrţaj deployment descriptor-a
i vrši odgovarajuća podešavanja aplikacije, modula i komponenti.
Slika 3: Struktura EAR datoteke [JenniferBall]
Razlikujemo ĉetiri tipa Java EE modula [JenniferBall]:
EJB moduli: sadrţe class datoteke koje se odnose na enterprise bean-ove i
odgovarajući EJB opisivaĉ rasporeda. EJB moduli se pakuju u JAR datoteke koje
imaju .jar ekstenziju;
9
Web moduli: sadrţe 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: sadrţe class datoteke i opisivaĉ rasporeda aplikacije.
Application client moduli se pakuju u JAR datoteke koje imaju .jar ekstenziju;
Resource Adapter moduli: sadrţe Java interfejse, klase, biblioteke i drugu
dokumentaciju i odgovarajući resource adapter opisivaĉ rasporeda. Oni obezbeĊuju
connector arhitekturu za odreĊeni EIS. Resource adapter moduli se pakuju u JAR
datoteke koje imaju .rar ekstenziju.
Postoje dva tipa opisivaĉa rasporeda: Java EE i runtime. Java EE opisivaĉ rasporeda
je definisan u Java EE specifikaciji i moţe se koristiti za konfigurisanje parametara
zajedniĉkih za svaku Java EE implementaciju (implementacija nastaju na osnovu Java EE
specifikacije, moţe postojati više implementacija). Sa druge stane, runtime opisivaĉ rasporeda
se koristi za konfigurisanje implementaciono - specifiĉnih parametara Java EE aplikacija. Na
primer, aplikacioni server kompanije Sun Microsystems sadrţi informacije o kontekstu web
aplikacije (context root) kao i implementaciono-specifiĉna podešavanja kao što su, na primer,
direktive za keširanje. 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
Sadrţe u sebi poslovnu logiku koja operiše podacima
Pojavljivanjima bean-ova upravlja kontejner
Bean se moţe menjati u vreme puštanja u rad, promenom podešavanje njegove
okoline
Razni servisi kao sto su transakcije, sigurnost i sl. su odvojeni od samih klasa bean-
ova
Pristup bean-ovima ide preko kontenera
Ako bean koristi samo EJB definisane servise onda moze da se izvršava u bilo kom
kontejneru
Moţe se dodati u sloţenoj (enterprise) aplikaciju bez promene koda na beanu ili
aplikaciji itd.
Ugovori
Klijentski ugovori su ugovori izmedju klijenta i kontejnera. Klijent jednog enterprise bean-a
moţe biti drugi bean, Java aplikacija, web servis itd, kao i klijent koji nije pisan u Javi. Klijent
jednog session ili entity bean-a moţe imati pogled na bean koji moţe 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 ograniĉen na komponente koje sa nalaze u istoj VM kao i sam klijent.
Lokalni pogled koristi obiĉne Java interfejse.
10
Local i Remote pogledi sadrţe:
Home interfejs
Interfejs komponente (Remote i Local)
Identitet objekta
Dodatno Remote pogled sadrţi:
Meta podatke
Ruĉku (Handle)
Home interfejs enterprise bean-a definiše metode za kreiranje, uništavanje i pretraţivanje, kao
i poslovne metode za Entity bean-ove. Ako bean ima definisan Remote interfejs uz njega treba
da ide i Home interfejs. Isto vaţi ako bean ima definisan Local interfejs, tada treba da ima i
odgovarajući LocalHome interfejs. Klijent moţe 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 naĉin se definiše šta je kom klijentu dostupno iz jednog bean-a. EJB objekat ţivi unutar
svoje kuće (Home) i ima jedistven identitet povezan sa Home interfejsom. Kontejner je
zaduţen da kreira ovaj jedinstevi identeitet. Ovaj identitet nije dostupan klijentu ali klijent
moţe da proveri da li su dva objekta ista.
MessageDriven Beans su karakteristiĉni jer nemaju Home interfejse, interfejse komponente i
krajnju taĉku za web-servise. Njima se takodje pristupa preko standardnog Java Naming and
Directory Interface (JNDI) API, sliĉno kao kod Remote pristupa.
2.5.1. Tipovi Enterprise objekata
Enterprise JavaBeans definiše 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 sledeće karakterstike:
Izvršava se u ime jednog klijenta
Svestan je transakcija u kojim se moţe naći
Moţe menjati podatke u bazi, ali ih ne predstavlja direktno
Ima relativno kratak ţivotni vek i gubi se ako EJB kontejner padne
EJB specifikacija definiše Stateless i Statefull session objekte koji su sliĉni ali imaju razlike
medjusobom. Ovi bean-ovi se najĉešće koriste kada se implementira neka poslovna logika.
Entity objekat ima sledeće karakteristike:
Predstavlja podatke iz baze
Dozvoljava pristup od strane više korisnika
Ima dug ţivotni vek jer nastavlja da ţivi u bazi podataka
11
Ovaj objekat moţe da „preţivi“ ako kontejner padne, jer je snimljen u bazi. Ako se
desi pad u toku transakcije, stanje entity objekta se vraća na poslednje regularno
snimljeno stanje.
Entity bean se najĉešće koristi u perzistentnom sloju sistema, za potrebe ĉitanja i pisanja
podataka u bazu.
MessageDriven objekat ima sledeće karakteristike:
Izvršava se kad primi jednu poruku od klijenta
Izvršava se asinhrono
Moţe 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 najĉešće koristi kada je potrebno izvršavati asinhrone zahteve. Ĉesto
se dešava da ovaj bean poziva poslovnu logiku pisanu u Session bean-ovima.
2.5.2. Session beans
U ovom poglavlju ćemo bliţe 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 omogući korišćenje session objekata. Session
objekat ţivi unutar kontejnera, koji mu obezbedjuje podršku za sigurnost, transaktivnost,
konkurentnost i druge servise.
Session bean je ne perzistentni objekat koji sadrţi deo poslovne logike i koji se se
izvršava na serveru. Ovaj objekat nije deljiv izmedju više klijenata. Session bean svoju
poslovnu logiku nudi preko Local i / ili Remote interfejsa. U EJB 2.1 Statless bean moţe da
sluţi kao krajnja taĉka 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 moţe da ide preko Java
JNDI APIa.
Udaljeni klijent jednog session bean-a moţe biti drugi session bean, Java aplikacija,
web servis, aplet i td. Udaljeni pristup preko Remote interfejsa je nezavisan od lokacije, sto
znaĉi da klijent i bean mogu da budu na istoj ili potpuno razliĉitoj VM i/ili raĉunaru. Ovo nije
sluĉaj 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 sledeći naĉin.
Ako je interfejs za pristup session beanu localni (Local) onda je kod za uzimanje Home
objekta malo drugaĉiji:
Context initialContext = new InitialContext();
CartHome cartHome = (CartHome)javax.rmi.PortableRemoteObject.narrow(
initialContext.lookup(“java:comp/env/ejb/cart”),CartHome.class);
12
Tipiĉno korišćenje je da jedan Home objekat moţe da se koristi više 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 uništava session objekat. Kreiranje session objekata se radi definisanjem i
izvršavanjem bar jedne create() metode. Create metoda bean-a kao povratni parametar mora
imati remote interfejs session bean-a na koji se odnosi.
Udaljeni klijent moţe uništiti session objekat koristeći remove() metodu nad
javax.ejb.EJBObject klasom.
LocalHome interfejs
Sliĉno kao za RemoteHome interfejs, LocalHome interfejs omogućava da se kreira i uništava
session objekat. Za razliku od Remote pristupa, Local pristup je zavisan od lokacije. Kreiranje
session objekta se radi definisanjem i pozivanjem metode create() . Takodje uništavanje
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
drţi samo jedan klijent. Zbog toga oni nemaju nekakav identifikator niti metode za
pronalaţenje (finder methods). Ĉak, ako se nad session objektom pozove metod
EJBObject.getPrimaryKey() desiće se izuzetak. Pokazivaĉ na session objekat se moţe
serijalizovati i koristiti kasnije ali pod uslovom da session objekat i dalje postoji na serveru.
Životni ciklus session objekta
Na sledećoj slici dajemo graf koji predstavlja ţivotni ciklus session objekta.
Context initialContext = new InitialContext();
CartHome cartHome = (CartHome)
initialContext.lookup(“java:comp/env/ejb/cart”);
public sessionbeans.clan.Clan create()
throws
javax.ejb.CreateException,java.rmi.RemoteException;
13
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 moţe 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 „ruĉku“ (Handle) na session objekat ili da unisti sesson
objekat. Ako se pokuša poziv metoda nad session objektom koji nije kreiran desiće se
izuzetak.
U sluĉaju da korisnk uzima referencu na Local interfejs ima sliĉne mogućnosti kao i Remote
interfejs, samo sto ne moţe da uzme „ruĉku“ (Handle) i ne moţe koristi referencu Local
interfejsa kao parametar metoda koje su Remote tipa. Znaĉi 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 moţe 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 moţe biti referenciran sa više
mesta. Znaĉi, jedan session objekat je vezan sa jednim Home interfejsom.
14
Session objekat je po pravilu anoniman za klijenta i metoda getPrimaryKey() će baciti
izuzetak.
Session bean ugovor
Session bean predstavlja produţenje klijenta koji ga koristi, i moţe imati neko interno stanje,
ako je u pitanju Statefull Session bean. Session bean moţe pisati / ĉitati podatke iz baze, i ako
je u pitanju Statefull bean, njegov ţivotni vek odredjuje klijent.
Tipiĉno, stanje Session bean-a se ne piše u bazi direktno. Ono se ĉuva dok traje sesija klijenta,
unutar samog bean-a. Ako je potrebno da se stanje snimi u bazu, obiĉno se to radi preko
Entity bean-ova. Sam programer je duţan da osveţi stanje Session bean-a kad god je
potrebno, ako je odluĉio 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 moţe da sluţi bilo kom klijentu.
Statefull bean-ovi imaju interno stanje koje se prenosi kroz više 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 mogućih 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 piše
apstraktnu perzistentnu shemu i kojoj navodi polja koja ce Entity bean imati kao i metode
kojima će se pristupati tim poljima.
Ova shema se definiše u opisivaĉu rasporeda, i kontejner prilikom puštanja u rad (deploy)
koristi ovu shemu da generiše neke klase i obavi neophodne pripreme da entity bean moţe
uspesno da se koristi.
CMP i nezavisnost podataka
EJB model je projektovan tako da omogući 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 omogućava da bean moţe da se menja a da pritom klijenti ne moraju
da se rekompajliraju. Takodje, baza podataka koja ĉuva podatke o bean-u se moţe 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
piše 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 piše kod koristeći 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 naĉin se postiţe nezavisnost izmedju slojeva baze,
perzistencije i bean klase.
15
EJB opisivaĉ rasporeda definise logiĉke veze izmedju entity bean-ova. Kontejner je taj koji
ima zadatak da te logicke veze poveţe na odgovarajuci naĉin, da omogući povezivanje sa
konkretnom fiziĉkom 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
fiziĉke baze podataka u kojoj se snimaju podaci. Na taj naĉin se baza podataka moze
promeniti a da entitet uopste ne mora da se menja.
Programerski pogled na CMP
Entity bean pisan koristeći CMP tipiĉno se sastoji od entity klase, komponent interfejsa
(interfejs koji sadrţi get i set metode) koji definise klijentski pogled na bean, home interfejsa
koji sluzi za kreiranje, brisanje, traţenje 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 naĉin 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 ograniĉenja kada piše 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 opisivaĉu rasporeda i moraju poĉinjati
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 raĉuna da ne dozvoli da menja primarni kljuĉ entity bean-a i
stoga metoda za set kljuĉa 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
16
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 definiše 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
vraća 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 uspešno izvrši,
bean će biti obrisan. Takodje, se brišu sva pojavljivanja tog bean-a iz svih veza (kolekcija) u
kojima je obrisani bean bio prisutan.
Na kraju se briše 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 više 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” brišu 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 kljuĉem 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 moţe koristiti
unutar veze.
Značenje dodele vrednosti nad vezama
U sluĉaju 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 više – više veza nece izbaciti elemente
iz original kolekcije ako se element poveţe sa novom kolekcijom. Kod rada sa kolekcijom
untar veze, bitno je da tip elemenata u kolekciji bude odgovarajući inaĉe će kontejner baciti
izuzetak.
17
Update relationship model
Oblik veze takodje utiĉe 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 ubaĉen. Identitet objekta će naravno ostati isti.
I ovde vaţi 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 definiše polja unutar bean-a kao i veze koje jedan bean moţe
imati. On pored ostalog opisuje sledeće 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 ejb-
relationship-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.
18
Pojavljivanje entity bean-a moţe 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 naĉina: 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
Slika 5: Životni ciklus Entity bean-a
19
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 vraća 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 vraćeno u pool više nije povezano sa nekim identitetom entity bean-a i
moţe se opet koristiti.
Pojavljivnje se moţe izbaciti iz pool-a pozivanjem unsetEntityContext() metode.
Finder metode
Home interfejs entity bean-a definiše jedan ili više find metoda. One sluţe da
pronalaze razliĉite entity objekte i vraćaju entity objekat ili kolekciju. Svaki find metod mora
biti povezan sa nekim EJB upitom unutar opisivaĉa rasporeda izuzev findByPrimaryKey().
Postoje finder metode koje vraćaju jedan objekat. Kod njih je bitno da tip interfejsa
koji se vraća 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 vraća više objekata, desiće se izuzetak.
Pored ovih find metoda postoje i find metode koje vraćaju više objekata. Ova metoda vraća
kolekciju objekata, gde tip objekta unutar kolekcije odgovara tipu Home interfejsa. Ako je
Home Local tipa vratiće se kolekcija Local interfejsa, a ako je Home interfejs Remote tipa
vratiće kolekciju Remote interfejsa. Ako se ne koristi DISTINCT ova kolekcija moţe imati
viće istih elemenata.
Enterprise Bean klasa
Entity bean klasa mora da ispostuje neka pravila
Mora da implementira javax.ejb.EntityBean interfejs
Moţe 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 moţe imati super klase ili interfejse. Bitno je da bean ili neka njegova super
klasa ima implementirane obavezne ejbMetode.
Entity bean moţe imati i pomoćne metode koje nisu navedene u EJB specifikaciji, a koriste se
u radu bean-a.
Entity bean ne implementira finder metode. To je posao kontejnera.
20
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 poĉinju sa ejbPostCreate prefiksom, da budu public, ne smeju biti final i static, tip
koji vraćaju mora biti void. Ulazni paramatri moraju biti isti kao i paramateri za odgovarajaću
ejbCreate metodu.
Poslovne metode
Bean moţe imatu nula ili više poslovnih metoda. Njihova imena su proizvoljna ali ne smeju
poĉinjati sa ejb zbog konflikta sa EJB metodama.
Entity Bean Remote interfejs
Ovaj interfejs mora naslediti javax.ejb.EJBObject. Metode definisane u ovom interfejsu
moraju poštovati 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 poštovati 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 sadrţi 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
21
Klasa primarnog ključa
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 ključa
Kontejner mora imati mogućnost da upravlja primarnim kljuĉem bean-a. Zbog toga klasa
primarnog kljuĉa mora postovati neka pravila. Primarni kljuĉ moţe biti prost ili sloţen kljuĉ.
U oba sluĉaja se mora navesti polje primary-key u opisivaĉu 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 odredište koje taj bean servisira. MessageDriven Bean nema Local ili Home interfejs.
Unutar specifikacije EJB 2.1 MessageDriven bean-ovi mogu da podrţe tipove poruka
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 poruka na odredište. Ţivotni
vek bean-a kontroliše kontejner.
Ciljevi
Osnovni ciljevi message-driven modela je da obezbedi bean koji će asinhrono da se poziva i
obradjuje pristigle poruke. Dalji ciljevi ovog modela su da omogući konkurentnu obradu toka
poruka koristeći 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 moţe da se podesi tako da ukljuĉuje više message-driven odredišta
22
na više mašina ili mreţa. Sama lokacija bean-a koji će obraditi poruku je transparentna za
korisnika.
Message Driven Bean i kontejner
Od kreiranja do uništenja MessageDriven bean postoji unutar kontejnera. Kontejner mu
obezbedjuje servise za sigurnost, konkurentnost, transakcije i dr. Kontejer upravlja ţivotnim
ciklusom bean-a, obaveštava pojavljivanja kada se dešavaju pojedini dogadjaji i pruţa jos
mnogo servisa koje omogućavaju 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 moţe 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 poveţe
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 drţao.
Message Listener interfejs
Message Driven bean mora implementirati odgovarajući message listener interfejs. Ovaj
interfejs odredjuje tip poruke koje će bean obradjivati. Ako bean implementira
javax.jms.MessageListener onda je taj bean JMS bean.
Glavna stvar ovog interfejsa je metoda koju bean mora da implementira (u sluĉaju JMS to je
metoda onMessage()). Ova metoda se poziva svaki put kada stigne poruka i u njoj se piše
logika za obradu poruke.
Ostale karakteristike
Message Driven bean opciono moţe da implementira TimedObject interfejs. Ovo mu
omogućava da koristi dogadjaje koji su zasnovani na vremenu i time proširi 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 više pojavljivanja message bean-a izvrsava istovremeno i time
omogućava 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 izvršenja.
Metoda message listener interfejsa se izvrsava unutar opsega transakcije koji je opisan u
opisivaĉu rasporeda. Zbog toga bean moţe upravljati transakcijom tj ako se desi neka greska
bean moţe oboriti celu transakciju.
23
Dijagram stanja MessageDriven bean-a
Stanjem i ţivotnim vekom bean-ova upravlja kontejner. Kada poruka stigne i treba da se
izvrši na nekom beanu, kontejner bira jedno pojavljivanje bean-a i poziva odgovarajuću
metodu. Sledeći crteţ opisuje ţivotni vek jednog bean-a.
Slika 6: Životni ciklus Message objekta
Ţivotni vek jednog pojavljivanja message bean-a poĉinje pozivanjem tri metode newInstace(),
setMessageContext(), i ejbCreate(). Posle toga bean je spreman da izvršava poruke koje su
mu prosledjene. Kada pojavljivanje bean-a više nije potrebno, kontejner poziva odgovarajuću
ejbRemove() metodu i uništava pojavljivanje.
24
2.6. Perzistentnost u EJB 2.1 tehnologiji
U ovom poglavlju ćemo reći 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 pretraţivanje entity bean-ova koji koriste CMP (upravljanje
perzistenciom od strane kontejnera). EJB QL moţe da se kompajlira na odgovarajuci jezik, od
kojih je jedan i SQL. Na ovaj naĉin 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. Upiti koji se pišu u EJB QL se odnose na ovu shemu i definisane veze u opisivaĉu
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 sliĉnu SQL koja se zasniva nad apstraktnim tipovima i vezama entity
bean-ova. EJB QL je string koji se sastoji od sledećih celina:
SELECT klauzula – odredjuje tip objekta ili vrednosti koji se bira
FROM klauzula – odredjuje domen nad kojim se vrši selekcija
WHERE klauzula – sluţi da suzi vrednost izbora
ORDER BY klauzula – koja se koristi da se sortiraju pronadjene vrednosti
EJB QL se moţe definisati na sledeći naĉin:
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 sluţe da korisnik selektuje perzistentno stanje entiteta ili cele
entitete, na naĉin opisan upitom. Rezultat izvršenja ove metode moţe biti EJBObject,
EJBLocalObject, vrednost polja bean-a i sl.
EJB QL :: = select_ klauzula from_ klauzula [where_ klauzula] [orderby_ klauzula]
25
SELECT klauzula
Select klauzula oznaĉava rezultat upita. Ona sadrţi promenljivu koja je apstraktnog tipa,
putanju, ili pak agregatni select iskaz. Select klauzula ima sledeću sintaksu:
Sve samostalne identifikacione promenljive u SELECT klauzuli moraju biti oznaĉene sa
OBJECT operatorom. OBJECT operator se ne sme koristiti u gradjenu select_izraza.
FROM klauzula
From klauzula definiše domen upita deklaracijom promenljivih za identifikaciju. Ova
klauzula moţe da sadrţi više promenljivih za deklaraciju odvojenih zarezom.
WHERE klauzula
Where klauzula definiše izraz koji se koristi da suzi skup vrednosti koje su rezultat upita. Ona
se definiše na sledeći naĉin:
2.7. Sažetak
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 objašnjeni
Enterprise bean-ovi (Session bean i Message-Driven bean), kao i relizacija perzistentnosti u
EJB 2.1 tehnologiji. U tom kontekstu moţemo reći da EJB tehnologija ima sledeće
karakteristike:
EJB tehnologija predstavlja de facto standard prilikom razvoja sloţenih aplikacija;
EJB koristi dobre osobine aplikacionog servera (deklarativno upraljvanje
transakcijama, security...);
Zahteva korišćenje EJB kontejnera;
Na taj način smo realizovali prvi cilj istraživanja (Dati pregled EJB 2.1 tehnologije).
from_klauzula ::= FROM deklaracija_identifikacione_promenljive
[,deklaracija_identifikacione_promenljive]
where_klauzula ::= WHERE izraz_za_stanje
select_klauzula ::= SELECT [DISTINCT] {select_izraz | OBJECT(identifikaciona_promenljiva)}
26
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. Biće detaljnije obradjeni enterprise bean-ovi, perzistencija, kao i korišćenje
anotacija za lakši razvoj celokupne EJB 3.0 aplikacije.
3.1. EJB 3.0 kratak pregled
EJB 3.0 predstavlja novi uprošćeni API koji ima za cilj da olakša programerima razvoj
sloţenih (enterprise) aplikacija. Stari EJB 2.1 API ostaje prisutan radi kompatibilnosti sa
postojećim programima i moţe se koristiti u kombinaciji sa novim EJB 3.0 API-jem.
EJB 3.0 je fokusiran na sledeće ciljeve:
Iskoristiti metadata anotacije kojima bi se olakšao posao programerima i smanjio broj klasa
koje moraju da implementiraju. Takodje je cilj smanjiti upotrebu opisivaĉa rasporeda,
koristeći pristup „konfiguracije po izezetku“. Ovakav pristup podrazumeva da nije potrebno
pisati opisivaĉe rasporeda ako su oni jednostavni tj podešavanje je podrazumevano.
Specificirati podrazumevana podešavanja tako da programer ne mora da ih navodi. Cilj je da
se iskoriste podrazumevana podešavanja u što većem broju sluĉajeva, jer njih programer ne
mora da piše. Onde gde programer mora napisati opisivaĉe rasporeda je neki sloţeniji,
nestandardan sluĉaj konfiguracije.
Uĉaurenje zavisnosti EJB radne okoline i JNDI pristupa kroz korišćenje anotacija, ubacivanja
(injection) zavisnosti, i prostih Lookup mehanizama.
Uprošćenje enterprise bean tipova kroz eliminaciju EJB interfejsa za session bean-ove.
Uprošćenje 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
mogućnostima za operacije spajanja, podupite, group by komandu i sl.
Uvodjenje klasa presretaĉa za session bean-ove i message driven bean-ove.
Eliminisanje zahteva za implementacijom callback interfejsa.
Metadata anotacije i opisivači rasporeda
Jedna od kljuĉnih tehnologija prikazana u Javi 5.0 su anotacije. One omogućavaju
programeru da oznaĉi delove programa i na taj naĉin kontroliše tok i puštanje u rad cele
aplikacije. Anotacije omogućavaju programeru da uprosti razvoj EJB aplikacije kao i da ih
koristi kao alternativa opisivaĉima rasporeda. Anotacije nisu obavezne i programeri koji ţele
da koriste opisivaĉe rasporeda mogu to da rade.
Opisivaĉi rasporeda su opisani kao alternativa anotacijama i kao naĉin da se prepišu
(override) podešavanja iz anotacije.
27
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 moţe da
koristi EJB 3.0 bean-ove. Na taj naĉin je omogućena 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, presretaĉa, konteksta i
izuzetaka.
3.2.1. Enterprise Bean klasa
Enterprse Bean klasa je najĉešća komponenta (artifact) koji programer koristi. U EJB 3.0
programer najĉešće 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 tipiĉno radi
korišćenjem anotacija ili kao alternativa preko opisivaĉa rasporeda.
3.2.2. Interfejsi
Unutar EJB 3.0 API poslovni interfejs je obiĉan Java interfejs. U sluĉaju
MessageDrivenBean-a on je odredjen tipom poruka. Za Entity Bean-ove se ne definišu
interfejsi.
Bean klasa moţe da implementira svoj biznis interfejs. Tu vaţe sledeća 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 moţe da ima više interfejsa. U tom sluĉaju svaki poslovni interfejs ponaosob 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 moţe 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 obraĊen od strane kontejnera i omotan u EJBException.
3.2.3. Presretači
Presretaĉi su metode koje presreću pozive poslovnog interfejsa ili dogadjaje ţivotnog ciklusa
bean-a. Presretaĉ moţe da se definiše u bean klasi ili kao klasa van bean-a koja je sa njom
povezana. On se moţe praviti za Session i Message driven bean-ove. Presretaĉ se moţe
28
podesiti da bude povezan sa svim poslovnim metodama ili samo sa pojedinim. Klase
presretaĉa su oznaĉene anotacijom Interceptors unutar bean-a, ili preko opisivaĉa rasporeda.
Takodje u opisivaĉu rasporeda se moţe definisati presretaĉ za sve bean-ove u ejb-jar datoteci.
Ako je potrebno jedan bean moţe imati više presretaĉa. U tom sluĉaju redosle izvšavanja je
oznaĉen redosledom navodjenja. Presretaĉ klasa mora imati jedan javni kontruktor bez
argumenata. Presretaĉi 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 mogućnost da koriste JNDI, JDBC, JMS, druge bean-ove, i Entity
Manager kao i ubacivanje (injection) zavisnosti.
Presretači metoda životnog ciklusa bean-a
Metoda moţe biti oznaĉena da prima dogadjaje zivotnog ciklusa bean-a. Za to se koriste
anotacije PostConstruct, PreDestroy, PostActivate, ili PrePassivate unutar bean-a ili u
opisivaĉu rasporeda. Metode presretaĉa nad bean-om imaju sledeći oblik
void <METHOD>()
dok metode nad klasom presretaĉa imaju oblik
void <METHOD>(InvocationContext).
Primer za @PreDestroy anotaciju
Antacije za obeleţavanje metoda su iste za presretaĉe u bean-ovima i u presretaĉ klasama.
Takodje jedna metoda moze da se poziva od strane više anotacija tj dogadjaja. Jedana ista
anotacija se ne moţe postaviti na više metoda.
Presretači poslovnih metoda
Presretaĉi poslovnih metoda se definišu korišćenjem AroundInvoke anotacije ili pomoću
around-invoke taga u opisivaĉi rasporeda. Samo jedna AroundInvoke metoda moţe postojati
nad bean klasom ili nad klasom presretaĉa. AroundInvoke metoda ne sme biti poslovna
metoda. Ona se izvršava pre izvršenja poslovne metode i mora pozvati
InvocationContext.proceed() jer u suprotnom neće se izvrsiti ni poslovna metoda ni sledeća
AroundInvoke metoda.
Ona ima potpis
public Object <METHOD>(InvocationContext) throws Exception.
@Stateful
public class ShoppingCartBean implements ShoppingCart {
private float total;
private Vector productCodes;
public int someShoppingMethod(){...};
...
@PreDestroy
void endShoppingCart() {...};
}
29
3.2.4. InvocationContext
Presretaĉi imaju svoj kontekst javax.interceptor.InvocationContext, koji se prebacuje od jedne
do druge metode presretaĉa. Na taj naĉin presretaĉi 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() vraća pojavljivanje bean-a, a getMethod() vraca metodu za koji je pozvan
presretaĉ. Metoda getParamatars() vraća listu parametara koji su prosledjeni poslovnoj
metodi. Metoda proceed() poziva sledeci presretaĉ u nizu.
3.2.5. Izuzeci
AroundInvoke metode se izvršavaju na istom steku kao i poslovne metode. To znaĉi da se
ponašaju isto kao obiĉne 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 utiĉu 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 napišu za Session bean-ove u verziji EJB 3.0 tehnologije,
a za entitete su potpuno izbaĉeni. Entiteti su sada obiĉni 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 obiĉni Java interfejsi, a ne EJBObject or EJBLocalObject
interfejsi. U sluĉaju da bean implemetira WebServis dovoljna je anotacija @WebMethod da
se oznaĉe metode koje su izloţene kao web servis. Takodje ovi bean-ovi ne zahtevaju Home
interfejs.
30
3.3.2. Bean klasa i njene metode životnog ciklusa
Stateless Bean klasa mora biti oznaĉena kao @Stateless unutar klase ili u opisivaĉu rasporeda.
Klasa ne mora da nasledjuje javax.ejb.SessionBean interfejs.
Karakteristiĉne 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 uništi.
Sve metode ţivotnog ciklusa se izvršavaju u neodredjenom okviru transakcije i sigurnosti.
3.3.3. Ostale karakteristike
Ako Stateless 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 presretaĉa.
Dajemo kratak primer za jedan stateless bean, koji ima jednu klasu presretaĉa:
@Stateless
@Interceptors({
com.acme.Metrics.class,
})
public class AccountManagementBean implements AccountManagement {
public void createAccount(int accountNumber, AccountDetails details) { ... }
public void deleteAccount(int accountNumber) { ... }
public void activateAccount(int accountNumber) { ... }
public void 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.");
}
}
}
31
3.3.4. Klijenstki pogled
Klijenti dobijaju referencu na bean-ove preko ubacivanja (injection) zavisnosti ili preko
Lookup mehanizma.
Primer:
3.4. Stateful Session Beans
U ovom poglavlju će biti reĉi o bean-ovima koji imaju neko interno stanje koje treba ĉuvati.
Biće ukratko dati interfejsi bean-a i neke karakteristike.
3.4.1. Interfejsi Stateful Session Bean-a
Poslovni interfejsi u EJB 3.0 su obiĉni 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 oznaĉena kao @Stateful unutar klase ili u opisivaĉu rasporeda.
Bean ne mora da implemetira javax.ejb.SessionBean ili java.io.Serializable interfejse. Stateful
Session Bean moţe da implementira SessionSynchronization interfejs.
Stateful session bean ima nekoliko metoda ţivotnog ciklusa: kreiranje, uništavanje, 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.
@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 {
…
}
}
32
PreDestory se poziva pre nego što se pojavljivanje bean-a uništi.
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 izvršavaju 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 presretaĉa.
Za stateful session beans koji implementiraju SessionSynchronization interfejs, afterBegin se
dešava pre AroundInvoke metode, a metoda beforeCompletion se poziva pošto su se sve
AroundInvoke metode izvrsile.
3.4.4. Klijentski pogled
Remote ili Local klijent moţe uzeti referencu na bean preko ubacivanja zavisnosti (dependecy
injection) ili preko lookup mehanizma.
Ako se stateful bean traţi 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. Tipiĉno klijent kreira bean
preko jedne ili više poslovnih metoda.
Uklanjanje stateful bean-a se oznaĉava korišćenjem Remove anotacije. Ova anotacija se
stavlja iznad neke metode i kontejner zna da treba da unušti bean kad se izvrši 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() {
...
}
}
33
3.5. Message Driven Beans
U ovom poglavlju će biti reĉi o MessageDriven Bean-ovima i njegovim interfejsima i
karakteristikama. Ovaj bean se najĉešće 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 sluĉaju JMS ovo je javax.jms.MessageListener interfejs.
MessageDriven Bean mora implementirati odgovarajući message listener interfejs odredjenog
tipa, ili mora koristiti anotaciju MessageDriven unutar bean-a ili odgovarajući opis u
opisivaĉu rasporeda, koji kaţe da je bean message driven.
3.5.2. Bean klasa i njene metode životnog ciklusa
MessageDriven Bean mora biti oznaĉen anotaciom MessageDriven ili oznaĉen u opisivaĉu
rasporeda kao MessageDriven. Bean klasa nije neophodno da implementira interfejs
javax.ejb.MessageDrivenBean.
MessageDriven Bean ima sledeće metode ţivotnog ciklusa:
• PostConstruct
• PreDestroy
PostConstruct metoda se izvršava pre prvog poziva neke poslovne metode message bean-a. U
ovom trenutku celokupna injekcija zavisnosti je izvršena na kontejneru.
PreDestory metoda se poziva u trenutku kada se message bean uništava ili izbacuje iz
privremenog skladista (pool).
Sve metode ţivotnog ciklusa se izvršavaju u neodredjenom okviru transakcije i sigurnosti.
3.5.3. Ostale karakteristike
MessageDriven Bean moţe koristiti resurse i servise kontejnera. Kontejner ove resurse
ubacuje pre bilo kog poziva poslovnih metoda ili metoda ţivotnog ciklusa bean-a.
AroundInvoke anotacija moţe da se koristi za MessaegeDriven Bean. Isto kao kod ostalih
bean-ova, ova metoda moţe da se navede u samom beanu ili u posebnoj klasi presretaca.
34
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. Tipiĉno entitet predstavlja tabelu u
relacionoj bazi podataka i svako pojavljivanje entiteta predstavlja jedan slog u tabeli.
Perzistentno stanje entiteta reprezentuje se korišćenjem perzistentnih polja (persistent fields)
ili perzistentnih svojstava (persistent properties). Pomenuta polja/svojstva koriste odreĊene
anotacije koje omogućavaju preslikavanje entiteta i njihovih odnosa prema relacionim
podacima koji se nalaze u odreĊenom sistemu za upravljanje bazom podataka.
Dajemo prikaz mogućih tipova perzistentnih polja i perzistentnih svojstava [JenniferBall]:
1. Java primitivni tipovi (Java primitive types);
java.lang.String;
2. Drugi serializable tipovi ukljuĉujući
java.math.BigInteger;
java.math.BigDecimal;
java.util.Date;
java.util.Calendar;
java.sql.Date;
java.sql.Time;
java.sql.TimeStamp;
Korisniĉki definisani serializable tipovi;
Omotaĉi Java primitivnih tipova;
byte[]
Byte[]
char[]
Character[]
3. Enumerisani tipovi (Enumerated types)
4. Drugi entiteti ili kolekcije entiteta...
Entity klasa mora zadovoljiti sledeće zahteve [JenniferBall]:
Klasa mora biti oznaĉena korišćenjem 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 koristeći remote interfejs session bean-a, klasa mora
implementirati Serializable interfejs;
35
Perzistentna pojavljivanja moraju biti deklarisana kao private, protected ili package-
private i direktno im se moţe pristupiti samo iz metoda entity klase. Klijent im moţe pristupiti
korišćenjem u tu svrhu definisanih metoda (tzv. accessor metode) ili korišćenjem poslovnih
metoda.
Svaki entitet ima jedinstveni identifikator objekta. Na primer, „Firma“ moţe biti
identifikovana na osnovu odgovarajućeg identifikatora jer će on biti jedinstven za svaku
firmu. Jedinstveni identifikator, ili primarni kljuĉ (primary key), omogućava kljentima da
lociraju pojedine pojavljivanja entiteta. Svaki entitet mora imati primarni kljuĉ. Entitet moţe
imati ili prost ili sloţen (composite) primarni kljuĉ. Dajemo primer entity klase:
Prosti primarni kljuĉevi koriste javax.persistence.Id anotaciju kako bi naznaĉili
primarni kljuĉ perzistentnih polja ili perzistentnih svojstava. Sloţeni primarni kljuĉ mora biti
definisan u primary key klasi. Sloţeni primarni kljuĉ oznaĉava se korišćenjem
javax.persistence.EmbeddedId i javax.persistence.IdClass anotacija. Prost primarni kljuĉ, kao
i svojstvo ili polje sloţenog primarnog kljuĉa mora biti jedan od sledećih Java tipova:
1. Java primitivni tipovi; 2. Omotaĉi Java primitivnih tipova;
java.lang.String;
java.util.Date;
java.sql.Date.
Sa druge strane, primary key klase moraju zadovoljiti sledeće uslove [JenniferBall]:
Naĉin pristupa klasi mora biti public;
@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;
}
public String getAdresa() {
return adresa;
}
public void setAdresa(String adresa) {
this.adresa = adresa;
}
public String getTel() {
return tel;
}
public void setTel(String tel) {
this.tel = tel;
}
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
public String getDelatnost() {
return delatnost;
}
public void setDelatnost(String delatnost) {
this.delatnost = delatnost;
}
public String getUsername() {
return username;
}
public void setUsername(String username) {
36
Naĉin 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 sledeće tipove preslikavanja: one-to-one, one-to-many, many-to-one i many-to-
many [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, moţe se postaviti ograniĉenje da svaka
firma moţe da kupi jednu i samo jednu ĉlanarinu. U ovom sluĉaju se moţe koristiti one-to-
one preslikavanje i tada se na odgovarajuće perzistentno svojstvo (ili perzistentno polje)
postavlja anotacija javax.persistence.OneToOne.
One-to-many: Pojavljivanje jednog entiteta moţe biti povezano sa više pojavljivanja
drugog entiteta. Na primer, pretpostavimo da imamo dva entiteta: Raĉun i StavkaRaĉuna.
Svaka stavka raĉuna odnosi se na jedan i samo jedan raĉun. Sa druge strane, jedan raĉun moţe
imati više stavki raĉuna, pri ĉemu sigurno ima bar jednu stavku. U ovom sluĉaju se moţe
koristiti one-to-many preslikavanje i tada se na odgovarajuće perzistentno svojstvo (ili
perzistentno polje) postavlja anotacija javax.persistence.OneToMany.
Many-to-one: Više pojavljivanja jednog entiteta mogu biti povezana sa jednim
pojavljivanjem drugog entiteta. Kao što se moţe zakljuĉiti, ovo je suprotno od one-to-many
veze. Ukoliko posmatramo prethodni primer, iz perspektive Stavke raĉuna relationship ka
Raĉunu je many-to-one. U ovom sluĉaju se moţe koristiti many-to-one veza i tada se na
odgovarajuće perzistentno svojstvo (ili perzistentno polje) postavlja anotacija
javax.persistence.ManyToOne. Many-to-many: Više pojavljivanja jednog entiteta mogu biti povezana sa više pojavljivanja
drugog entiteta. Na primer, na fakultetu svaki predmet sluša i polaţe veći broj studenata. Sa druge
strane, svaki student sluša i polaţe veći broj predmeta. U ovom sluĉaju se moţe koristiti many-to-
many relationship i tada se na odgovarajuće 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. Koristeći pomenuto polje ili svojstvo, iz entity klase se moţe
pristupi do povezanog objekta. Ukoliko entity klasa ima polje ili svojstvo kaţemo da entity
klasa „ima znanje“ o povezanom objektu.
Dvosmerna veza mora zadovoljiti sledeća pravila [JenniferBall]:
Suprotna strana u dvosmernoj vezi mora imati referencu na sopstvenu stranu
korišćenjem elementa mappedBy koji se moţe 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
sadrţi odgovarajući spoljni kljuĉ (foreign key);
37
Za many-to-many dvosmernu vezu svaka strana moţe biti „vlasnik“ strana.
U dvosmernoj vezi, samo jedan entitet ima polje ili svojstvo koje predstavlja referencu
na drugi entitet. Drugim reĉima, iz jednog identiteta uvek moţemo doći do odgovarajućeg
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, Raĉun
moţe imati referencu na stavku raĉuna i preko njega uvek moţemo doći do odgovarajućih
stavki.
3.6.1.3. Upiti u zavisnosti od dvosmerne i jednosmerne veze
Java persistence upitni jezik (Java persistence query language) omogućava izvršavanje
upita i navigaciju kroz rezultate dobijene njihovim izvršavanjem. U zavisnosti od tipa veze
odreĊuje se da li se u upitu moţe vršiti navigacija od jednog entiteta ka drugom. Pretpostavimo da
imamo dva entiteta: Raĉun i StavkaRaĉuna. TakoĊe, pretpostavimo da je definisana jednosmerna
veza, i da iz Raĉuna uvek moţemo doći do stavke raĉuna. U tom sluĉaju se u upitu moţe vršiti
navigacija od Raĉuna ka njegovoj stavki ali se ne moţe vršiti navigacija u suprotnom smeru.
MeĊutim, ukoliko se koristi dvosmerna veza u upitu se moţe vršiti navigacija u oba smera.
3.6.2. Operacije nad entitetima
U ovom poglavlju ćemo dati kako se mogu vršiti neke osnovne operacije nad entitetima i reći
nešto 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. Pomoću EntityManager-a moţemo da kreiramo, unistavamo, menjamo i pretraţujemo
entitete.
Metode persist, merge, remove, i refresh, zahtevaju da se izvrašavaju unutar otvorene
transakcije. Ako im to nije obezbedjeno desiće se izuzetak javax.persistence.-
TransactionRequiredException.
Metode find() i getReference() ne zahtevaju transakciju da bi se izvršile.
Objekti Query and EntityTransaction su validni dok je entity manager otvoren. Ako metoda
createQuery() kao parametar ima upit koji nije u redu desiće se izuzetak
IllegalArgumentException.
3.6.2.2. Životni ciklus entiteta
Jedan entitet u bilo kom trenutku moţe biti opisan kao novi, upravljan, nepovezan i uklonjen.
Na sledećoj slici je dat ţivotni ciklus entiteta i njegov dijagram prelaza stanja.
38
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 oznaĉen za brisanje
u bazi, ali transakcija brisanja u bazi još nije završena.
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 sledeće rezultate:
Ako je X novi entitet on će postati upravljan i dobiće 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 desiće se izuzetak.
39
Uklanjanje entiteta
Entitet postaje uklonjen pozivanjem remove metode entity menadţera. Znaĉenje je sledeće:
Ako je X novi entitet operacija se ignoriše ali se poziva nad svim entitetima sa kojima je X
povezan, ako je naznaĉena 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 desiće se izuzetak.
Ako je X već uklonjen operacija se ignoriše. 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 neće desiti osim ako se ne pozove refresh operacija.
Sinhronizacija sa bazom se moţe forsirati i to se kontroliše naredbom flush. Ona se odnosi
samo na entitete koji su povezani sa perzistentnim okvirom. EntityManager i Query
setFlushMode su komande kojima se kontroliše rad sinhronizacije sa bazom.
FlushModeType.COMMIT komanda oznaĉava da se sinhrnizacija vrši kad se uradi commit.
Ako trenutno ne postoji aktivna transakcija flush se ne sme izvršiti.
Nepovezani entiteti
Nepovezan entitet se moţe javiti u nekoliko sluĉajeva. Kada se uradi commit u sluĉaju kada
se koristi transaktivnost i enitity menadzer iz kontejnera, kad se desi rollback, kada se oĉisti
perzistentni kontekst, ili kada se koristi serijalizacija ili neki drugi prenos entiteta preko
vrednosti.
Nepovezan entitet nastavlja da postoji izvan perzistentnog konteksta, ali njegovo stanje više
nije sinhronizovano sa stanjem u bazi. Aplikacija i dalje moţe da pristupa stanjima entiteta
pod uslovom da polje kome se pristupa nije oznaĉno kao fetch=LAZY. Ako polje kome se
pristupa je asocijacija, siguran naĉin 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 uĉitavanje (lazy loading).
40
Upravljanje pojavljivanjima
Posao aplikacije je da osigura da se pojavljivanjem entiteta upravlja u samo jednom
perzistentnom kontekstu. U sluĉaju da to nije obezbedjeno, rezultat je nepredvidjeno
ponašanje. Za kontrolu da li je entitet vec povezan sa perzistentnim okvirom koristi se
contains() metoda. Ona vraca true ako je entitet vraćen iz baze a nije obrisan ili nepovezan, ili
ako je tek kreiran a jeste pozvana persist() metoda. False ce biti vraćen u sluĉaju 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 moţe da ima trajanje koje se prostire unutar
jedne transakcije ili preko više transakcija. Ţivotni vek se definiše kada sa instancira entity
menadţer. 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 više
transakcija (prošireni okvir).
public enum PersistenceContextType {
TRANSACTION,
EXTENDED
}
Kada se koristi produţeni okvir (EXTENDED) on postoji od kad se kreira EntityManager do
kad se ne zatvori. Za to vreme moţe da obradi više transakcija. EntityManager kod
produţenog okvira će zadrţati vezu sa entitetima i posle završetka transakcije. To omogućava
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 produţen. 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 sluĉaju da se koristi okvir koji traje više transakcija, tada posle 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 vraća na stanje koje je
imalo u trenutku rollback poziva. Ovo u opštem sluĉaju dovodi do nekonzistentnog stanja
entiteta. Takodje, pojavljivanja koje su bile upravljane obiĉno se ne mogu ponovo koristiti
kao klasuĉni nepovezani entiteti.(npr generisani kljuĉ nije u redu i sl.)
3.6.3. Upitni jezik
Java persistence upitni jezik definiše osnovu za pisanje upita nad entitetima i njihovim
perzistentnim stanjima. Upitni jezik omogućava pisanje prenosivih upita koji se mogu
izvršavati nezavisno od korišćenog sistema za upravljanje bazom podataka. Upitni jezik kao
model podataka koristi apstraktne perzistentne šeme entiteta, ukljuĉujući i njihove veze, i
41
definiše operatore i izraze koji su zasnovani na takvom modelu podataka. Upitni jezik koristi
sintaksu koja je veoma sliĉna SQL upitnom jeziku (SQL-like syntax) kako bi izvršio 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 korišćenjem BNF sintakse [JenniferBall]:
3.6.3.2. UPDATE i DELETE upiti
UPDATE i DELETE upiti omogućavaju aţuriranje stanja sistema za upravljanje bazom
podataka. Njima se, u stvari, odreĊujuju tipovi entiteta koji će biti aţurirani ili izbrisani. Pri
tome, ukoliko je potrebno ograniĉiti opseg UPDATE i DELETE operacija, moţe se koristiti
WHERE klauzula [JenniferBall].
3.6.4. Metapodaci za objektno-relaciono preslikavanje (O/R Mapping)
Objektno / relaciono presikavanje je deo ugovora izmedju aplikacije i domenskog modela. On
predstavlja oĉekivanja i zahteve koje aplikaija ima prema preslikavanim enititetima u bazi.
Upiti koji se pišu nad bazom podataka potpuno zavise od ovog preslikavanja.
Ovo presikavanje moţe, ali ne mora da podrţi DDL naredbe nad bazom podataka.
3.6.4.1. Karakteristične anotacije za O/R presikavanje
Anotacije koje se koriste se nalaze u paketu javax.persistence. Sada ćemo navesti neke
najĉešće korišćene 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.
QL_statement ::= select_klauzula from_klauzula
[where_klauzula][groupby_klauzula][having_klauzula][orderby_klauzula]
update_statement :: = update_klauzula [where_klauzula]
delete_statement :: = delete_klauzula [where_klauzula]
42
@SecondaryTable
@SecondaryTable anotacija definiše druge tabele gde će se upisati podaci iz entiteta. Isti se
koristi sliĉno kao @Table anotacija. Ako se ne definiše ova anotacija, smatra se da se podaci
snimaju samo u primarnoj tabeli. Ako se ne navedu primarni kljucevi sekundarne tabele,
koristiće se isti kljuĉevi kao i u primarnoj tabeli. Takodje se podrazumeva da se tipovi
kljuĉeva u ove dve tabele poklapaju.
@UniqueConstraint
@UniqueConstraint anotacija se koristi da definiše ograniĉenje nad poljem prilikom kreiranja
tabele u bazi. Navodjenje imena kolona koje ţelimo da postavimo za unique je obavezno.
@Column
@Column anotacija se koristi kada ţelimo da poveţemo 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 moţe da se piše i nije postavljena da bude jedinstvena. Navodimo par
primera.
@Entity
@Table(name = "firma")
@SequenceGenerator(name = "firma_sequence",
sequenceName = "firma_id_seq")
public class DOFirma implements Serializable{…}
@Entity
@Table(name="CUSTOMER")
@SecondaryTable(name="CUST_DETAIL",
pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_ID"))
public class Customer { ... }
@Entity
@Table(
name="EMPLOYEE",
uniqueConstraints=
@UniqueConstraint(columnNames={"EMP_ID", "EMP_NAME"})
)
public class Employee { ... }
43
@Id anotacija
@Id anotacija se koristi da se definiše polje entiteta koje predstavlja primarni kljuĉ tabele.
Ova anotacija se moţe 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.
@GeneratedValue
@GeneratedValue anotacija se koristi za specifikaciju strategije generisanja primarnih
kljuĉeva. Ova anotacija se koristi za u kombinaciji sa @Id anotaciom, kada se definiše
primarni kljuĉ. Postoji 4 naĉina generisanja primarnog kljuĉa TABLE, SEQUENCE,
IDENTITY, AUTO.
TABLE tip opisuje generisanje kljuĉeva u tabeli koja je namenjena za to. SEQUENCE i
IDENTITY opisuju korišćenje sekvenci iz baze kojima se generiše primarni kljuĉ. AUTO tip
nalaţe bazi da odredi koji je najbolji naĉin na generisanje kljuĉeva. Ovo zavisi od same baze
podataka i kako je implementirana.
@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; }
@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;
}
…
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "clan_sequence")
public Long getId() {
return id;
}
44
@Transient
@Transient anotacija definiše da odradjeno polje entiteta nije perzistento. To polje se neće
uzimati u obzir prilikom perzistencije.
@ManyToOne
@ManyToOne definiše jednovrednosnu asocijaciju na drugi entitet koji ima vise prema jedan
preslikavanje. Definisanje tipa drugog entiteta nije obavezno jer se to moţe 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.
@OneToOne
@OneToOne anotacija definiše 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:
@OneToMany
@OneToManu definiše viševrednosnu asocijaciju sa jedan prema više preslikavanjem. Sa
strane jedan kada se definiše kolekcija definiše se i tip objeka koji se preslikava. Takodje, sa
strane više, nije potrebno definisati tip jer se on vidi iz objekta sa kojim je u vezi.
@Entity
public class Employee {
@Id int id;
@Transient User currentUser;
...
}
@ManyToOne(cascade=CascadeType.ALL)
@JoinColumn(name = "firma_id")
public DOFirma getFirma() {
return firma;
}
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; }
45
@JoinTable
@JoinTable anotacija se koristi za presikavanje asocijacija. A JoinTable anotacija se postavlja
na owning strani vise-prema-više veze, ili na jednosmernim vezama jedan-prema-više.
Podrazumevano ime tabele se sastoji od imena tabela koje se spajaju, povezano donjom
linijom.
@ManyToMany
@ManyToMany anotacija definiše visevrednostu asocijaciju tipa više-prema-više. 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 moţe da se proglasi za owning.
@OrderBy
@OrderBy anotacija se koristi kada se definiše kako će se elementi kolekcije sortirati, unutar
višestruke veze,u trenutku kada se ĉita kolekcija podataka iz baze. Ako nije definisano,
podrazumevano sortiranje je po primarnom kljuĉu.
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(
name="CUST_PHONE",
joinColumns=
@JoinColumn(name="CUST_ID", referencedColumnName="ID"),
inverseJoinColumns=
@JoinColumn(name="PHONE_ID", referencedColumnName="ID")
)
Klasa Customer
@ManyToMany
@JoinTable(name="CUST_PHONES")
public Set<PhoneNumber> getPhones() { return phones; }
Klasa PhoneNumeber
@ManyToMany(mappedBy="phones")
public Set<Customer> getCustomers() { return customers; }
46
@SequenceGenerator
@SequenceGenerator anotacija definiše generator primarnog kljuĉa kome se moţe pristupiti
po imenu kada se koristi GeneratedValue anotacija. SequenceGenerator se moţe 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 sedeća.
3.7. Enterprise Bean kontekst i okolina
Kontekst enterprise bean-a se sastoji od konteksta kontejnera i konteksta okoline
(environment). Bean moţe 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 deklariše da će koristiti neke resurse iz okoline koristeći anotaciju. Ova anotacija
definiše tip objekta ili resursa koji je potreban beanu, njegove karakteristike i ime pod kojim
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 moţe da oznaĉi promenljive bean-a koje predstavljaju promenljive iz njegove
okoline. Kontejner će proĉitati ove oznake i obezbediti bean-u odgovarajuće promenljive iz
okoline. Ovo se dešava pre bilo kog poziva poslovne metode bean-a.
@Entity
public class Course {
...
@ManyToMany
@OrderBy("lastname ASC")
public List<Student> getStudents() {...};}
@Entity
@Table(name = "firma")
@SequenceGenerator(name = "firma_sequence", sequenceName =
"firma_id_seq")
public class DOFirma implements Serializable{
…
47
@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);
}
}
Primer :
Kada se tip resursa moţe odrediti iz tipa promenljive anotacija ne mora da sadrţi 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.
Vaţi isto pravilo kao za anotaciju promenljivih. Kada se tip resursa moţe odrediti iz tipa
promenljive anotacija na setter metodi ne mora da sadrţi 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.
48
Primer:
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 korišćenjem
nove tehnologije. Postojeći 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 moţe se koristiti na EJB 2.1 komponentama,
naravno uz uslov da se koristi EJB 3.0 kontejner. Neke od tih osobina su: injection, klase
presretaĉa, 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 naĉin se
postiţe ponovno koriscenje komponenata, migracija deo po deo i zahvaljujući injekciji
uprošćenje klijentskog pogleda.
@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;
}
49
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 podrţavaju 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 menadţerom 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 moţe a ne mora biti kreiran, što zavisi od implementacije
kontejnera. Kontejner moţe da koristi neko keširanje podataka (data pooling) ili kasnu
inicijalizacju.
Ipak kad se pozove create() metoda poziva se i PostConstruct dogadjaj. Takodje, kad se
poziva remove() metoda pozvaće se i PreDestroy dogadjaj.
Kada je u pitanju StatefulSessionBean, kada se pozove create() metoda izaziva kreiranje bean-
a i lanac izvršenja poziva PostConstruct, i odgovarajucu Init metodu. Kao rezultat klijentu se
vraca odgovarajuci local ili remote interfejs nad bean-om. Ove metode se izvršavaju 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 najĉešće 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 reĉi o anotacijama koje se najĉešće koriste za EJB bean-ove. Ove su
uvedene u verziji EJB 3.0 i znatano oloakšavaju rad sa EJB bean-ovima.
Stateless Bean
Anotacija Stateless se koristi da se bean definiše kao Stateless bean. Ova anotacija se
postavlja na klasu koja predstavlja bean. Dajemo definiciju anotacije:
50
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 definiše kao Stateful bean. Ova anotacija se postavlja
na klasu koja predstavlja bean. Dajemo definiciju anotacije:
Anotacioni element “name“ mora biti jedinstven unutar ejb-jar. Podazumevana 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.
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 omogućila kompatibilnost sa klijentima EJB 2.1.
Parametri metode koja je anotirana kao Init moraju biti isti kao parametri u create() metodi.
Value element mora biti definisan ako Home interfejsi imaju više create<METHOD> metoda.
Na taj naĉin anotacija zna na koji create() metod treba da se poveţe.
Ako Stateful bean obezbedjuje RemoteHome ili LocalHome interfejse, onda mora imati bar
jednu Init anotaciju. Ako ima više create() metoda, Init anotacija mora imati value element
definisan.
@Target(TYPE) @Retention(RUNTIME)
public @interface Stateless {
String name() default "";
String mappedName() default "";
String description() default "";
}
@Target(TYPE) @Retention(RUNTIME)
public @interface Statelful {
String name() default "";
String mappedName() default "";
String description() default "";
}
@Target(METHOD)
@Retention(RUNTIME)
public @interface Init{
String value() default "";
}
51
Još jedna karakteristika Stateful bean-a je da ima Remove metodu. Kada se ova metoda izvrši,
kontejner će pozvati PreDestroy metodu a potom unistiti bean. Polje retainIfException,
omogućava da se bean ne unistava ako se desi neki izuzeak.
MessageDriven Bean
MessageDriven anotacija se koristi kad ţelimo da definišemo 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.
Anotacije Local i Remote se koriste samo na session bean-ovima. Remote anotacija se moţe
postaviti na bean ili na njegov interfejs i na taj naĉin se oznaĉava Remote interfejs. Isto vaţi i
Local anotaciju.
Local anotacija mora da se koristi jedino ako bean klasa imlepentira više interfejsa, pa se na
taj naĉin definiše koji interfejs predstavlja Local interfejs i to preko value elementa.
@Target(METHOD) @Retention(RUNTIME)
public @interface Remove{
boolean retainIfException() default false;
}
@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();
}
@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
}
52
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 oĉekuju postojanje
RemoteHome i LocalHome interfejsa.
3.9.2. Anotacije za transakcije
TransactionManagement anotacije definišu kako će se upravljati transakcijama, i definišu 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 piše bean.
Anotacija TransactionAttribute definiše da li će odredjena metoda biti pozvana unutar jedne
transakcije. Ova anotacija zahteva da se kao tip transaktivnosti koristi transaktivnost preko
kontejnera. TranasctionAttribute se moţe postaviti na ceo bean ili samo na pojedinu metodu.
U sluĉaju da postoje obe postavke, biće korišćena postavka nad metodom. Podrazumevana
vrednost za ovu anotaciju je REQUIRED.
@Target(TYPE) @Retention(RUNTIME)
public @interface RemoteHome {
Class value(); // home interface
}
@Target(TYPE) @Retention(RUNTIME)
public @interface LocalHome {
Class value(); // local home interface
}
@Target(TYPE) @Retention(RUNTIME)
public @interface TransactionManagement {
TransactionManagementType value()
default TransactionManagementType.CONTAINER;
}
public enum TransactionManagementType {
CONTAINER,
BEAN
}
public enum TransactionAttributeType {
MANDATORY,
REQUIRED,
REQUIRES_NEW,
SUPPORTS,
NOT_SUPPORTED,
NEVER
}
@Target({METHOD, TYPE}) @Retention(RUNTIME)
public @interface TransactionAttribute {
TransactionAttributeType value()
default TransactionAttributeType.REQUIRED;
}
53
3.9.3. Anotacije za presretače i životni ciklus bean-a
Interceptors anotacija sluţi da se definiše jedna ili više klasa presretaĉa. 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 definiše da ne ţelimo da ukljuĉimo podrazumevane presretaĉe. Takodje anotacija
javax.interceptor.ExcludeClassInterceptors omogućava da se iskljuĉi presretaĉ na nivou
klase, s tim što podrazumevani presretaĉ ostaje.
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 sledeće:
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 {}
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 {}
54
3.9.4. Anotacije za izuzetke, zaštitu pristupa i timeout
Timeout anotacija sluţi da ograniĉi vreme izvršenja metode bean-a.
AplicationException anotacija se koristi da se odredjni izuzetak oznaĉi kao aplikacioni i da se
ne obmotava od strane kontejnera. Rollback element sluţi da opiše da li će transakcija biti
oborena ako se desi taj izuzetak.
Anotacije za sigurnost definišu ko i kako moţe da pristupi metodama bean-a. Za pristup
metodama se mogu koristiti anotacije RolesAllowed, koja oĉekuje da se navede spisak rola
koje su dozvoljene. Ova anotacija se moţe definisati nad klasom bean-a ili nad poslovnom
metodom. U prvom sluĉaju će vaţiti nad svim poslovnim metodama bean-a, a u drugom samo
na metodi gde je definisana.
PermitAll anotacija definiše da metodu ili sve metode moţe da izvrši bilo ko. I ova anotacija
moţe da se definiše nad celim bean-om ili samo za metodu. U sluĉaju da se koriste obe
definicije podešavanje na metodi će biti uzeto u obzir.
DenyAll anotacija zabranjuje pravo izvršenja bilo kome, za zadati bean ili klasu. Vaţe sliĉna
pravilia kao i za PermitAll.
@Target({METHOD})
@Retention(RUNTIME)
public @interface Timeout
{}
@Target(TYPE) @Retention(RUNTIME)
public @interface
ApplicationException {
boolean rollback() default false;
}
package javax.annotation.security;
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface RolesAllowed {
String[] value();
}
package javax.annotation.security;
@Target ({TYPE, METHOD}) @Retention(RUNTIME)
public @interface PermitAll {}
package javax.annotation.security;
@Target (METHOD)
@Retention(RUNTIME)
public @interface DenyAll {}
55
RunAs anotacija definiše ime korisniĉke uloge koju ce bean nositi. Postavlja se na nivo bean-
a.
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 traţi u EJB okolini. BeanName je ime bean-a
koje je preslikavano na name polje. BeanName omogućava da se uzme pravi bean ako više
bean-ova implemetira isti interfejs.
Resource anotacija se koristi kada bean ţeli da pristupi resursima izvan svog bean konteksta.
Ovo se najĉešće koristi za pristup bazama i td. Name polje je ime resursa u okolini,
authenticationType definiše ko proverava pristup, a shareable da li je resurs deljiv.
package javax.annotation.security;
@Target(TYPE) @Retention(RUNTIME)
public @interface RunAs {
String value();
}
@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();
}
56
3.10. Sažetak
U ovom poglavlju smo dali kratak prikaz EJB 3.0 tehnologije. Naglasak je stavljen na
korišćenje anotacija, i razlike koje postoje u odnosu na prethodnu verziju EJB 2.1.
Na osnovu toga moţemo doneti sledeće zakljuĉke:
Korišćenje Entity klasa EJB 3.0 tehnologije je sada moguće van aplikacionog servera;
EJB tehnologija preuzima dobre osobine drugih tehnologija;
EJB tehnologija je u novoj verziji EJB 3.0 znaĉajno pojednostavljena i unapreĊena;
Zahteva korišćenje EJB kontejnera.
Na taj način smo realizovali drugi cilj istraživanja (Dati pregled EJB 3.0 tehnologije).
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();
}
57
4. SOFTVERSKE METRIKE
U ovom pogalavlju ćemo opisati ISO standard koji se koristi za merenje kvaliteta softvera.
Pomenućemo 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 meĊunarodne organizacije ĉije je delovanje
usmereno na uspostavljanje meĊunarodnih standarda u razliĉitim oblastima.
Ni oblast softverskog inţenjerstva nije izostala. Za nju je posebno znaĉajan standard ISO/IEC
9126 koji prouĉava softverske metrike i sastoji se iz ĉetiri dela:
ISO/IEC 9126-1 prouĉava model kvaliteta (Quality model);
ISO/IEC 9126-2 prouĉava eksterne softverske metrike (External metrics);
ISO/IEC 9126-3 prouĉava interne softverske metrike (Internal metrics);
ISO/IEC 9126-4 prouĉava kvalitet u softverskim metrikama (Quality in use metrics);
4.1.1. ISO/IEC 9126-1
Primena softverskih sistema u današnjem poslovanju je priliĉno raznovrsna pa se
moţe reći da je njihov pravilan rad kljuĉan za poslovni uspeh i/ili za ljudsku bezbednost.
Stoga je razvoj i izbor visoko kvalitetnog softverskog proizvoda od velike vaţnosti. Da bi se
osigurao odgovarajući kvalitet neophodno je na pravilan naĉin izvršiti specifikaciju i
evaluaciju kvaliteta softvera. Ovo se moţe postići definisanjem odgovarajućih atributa
kvaliteta softvera, uzimajući u obzir svrhu korišćenja softvera.
Kao što se moţe zakljuĉiti, potrebno je da se svaki relevantni atribut softverskog
proizvoda specificira i evaluira korišćenjem prihvaćenih softverskih metrika. Standard
ISO/IEC 9126-1 definiše atribute softverskog sistema u šest kategorija [ISO9126_1]:
1. Funkcionalnost (Functionality);
2. Pouzdanost (Reliability);
3. Upotrebljivost (Usability);
4. Efikasnost (Efficiency);
5. Odrţavanje (Maintainability) i
6. Prenosivost (Portability).
Svaka kategorija sadrţi elemente koji se mogu izmeriti korišćenjem internih ili eksternih
softverskih metrika što je i prikazano na Slici 8.
58
Slika 8: Model kvaliteta [ISO9126_1]
U okviru Funkcionalnosti razlikujemo sledeće podkategorije:
Pogodnost (suitability);
Taĉnost (accuracy);
Interoperabilnost (interoperability);
Sigurnost (security) i
Mogućnost usaglašavanja funkcionalnosti sa standardima (functionality compilance).
U okviru Pouzdanosti razlikujemo sledeće podkategorije:
Zrelost (maturity);
Tolerantnost na greške (fault tolerance);
Mogućnost povratka (recoverability) i
Mogućnost usaglašavanja pouzdanosti sa standardiima (reliability compilance).
U okviru Upotrebljivosti razlikujemo sledeće podkategorije:
Razumljivost (understendability);
Mogućnost uĉenja (learnability);
Operativnost (operability);
Atraktivnost (attractiveness) i
Mogućnost usaglašavanja upotrebljivosti sa standardiima (usability compilance).
U okviru Efikasnosti razlikujemo sledeće podkategorije:
Vremensko ponašanje (time behaviour);
Upotreba resursa (resource utilisation) i
Mogućnost usaglašavanja efikasnosti sa standardiima (reliability compilance).
59
U okviru Odrţavanja razlikujemo sledeće podkategorije:
Mogućnosti analize (analysability);
Mogućnosti promena (changeability);
Stabilnost (stability);
Mogućnost testiranja (Testability) i
Mogućnost usaglašavanja odrţavanja sa standardiima (maintainability compilance).
U okviru Prenosivosti razlikujemo sledeće podkategorije:
Adaptivnost (adaptability);
Mogućnost instalacije (installability);
Zajedniĉko postojanje (co-existence);
Mogućnost zamene (replaceability) i
Mogućnost usaglašavanja prenosivosti sa standardiima (portability compilance).
Definisane karakteristike su primenljive na svaku vrstu softvera i na taj naĉin
obezbeĊuju 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 poĉetka korišćenja softverskog sistema potrebno je izvršiti njegovu evaluaciju
korišćenjem softverskih metrika. Ta evaluacija je zasnovana na poslovnim ciljevima koji su
povezani sa upotrebom i upravljanjem softverskim proizvodom u specificiranom tehniĉkom i
organizacionom okruţenju. Standardom ISO/IEC 9126-2 definišu 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
korišćenja, formula, interpretacija izmerenih vrednosti, korišćena merna skala, tip mere...
Tako, na primer, ukoliko posmatramo Odrţavanje (Maintainability), i u okviru njega
Mogućnosti promena (Changeability) razlikujemo sledeće eksterne softverske metrike:
60
Slika 9: Eksterne Softverske metrike definisane za podkategoriju Changeability [ISO9126_2]
Na primer metrika Mogućnost promene preko parametra (Parameterised modifiability) je
definisana na sledeći naĉin (dajemo pojednostavljeni prikaz) [ISO9126_2]:
Naziv metrike Svrha metrike Formula Interpretacija
izmerene vrednosti
Mogućnost
promene preko
parametra
(Parameterised
modifiability)
Da li se na
jednostavan naĉin
moţe promeniti
odreĊeni parametar
softverskog sistema
kako bi se na taj naĉin
rešio odreĊeni
problem?
X=1-A/B,
Pri ĉemu je A – broj
sluĉajeva u kojima se
softver ne moţe
promeniti preko
parametra; B – broj
sluĉajeva u kojima se
pokušava promena
softvera preko
parametra.
0<=X<=1
Bolje je ukoliko
vrednost X teţi 1.
U tom sluĉaju je
mogućnost
promene softvera
preko parametra
veća.
Tabela 2: Pojednostavljeni prikaz metrike Parametrised modifiability
4.1.3. ISO/IEC 9126-3
Standard ISO/IEC 9126-3 definiše 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 postići odreĊeni eksterni kvalitet
(external quality) i kvalitet u upotrebi (quality in use) softverskog proizvoda. Tako, na primer,
ukoliko posmatramo Odrţavanje (Maintainability), i u okviru njega Mogućnosti promena
(Changeability) razlikujemo sledeće interne softverske metrike:
Maintainability
Changeability
Software change control
capability
Parametrised
modifability
Modification complexity
Change cycle efficiency
Change implementation
elapse time
61
Slika 10: Interne Softverske metrike definisane za podkategoriju Changeability [ISO9126_3]
Metrika Pamćenje promena (Change recordability) je definisana na sledeći naĉin (dajemo
pojednostavljeni prikaz) [ISO9126_3]:
Naziv metrike Svrha metrike Formula Interpretacija izmerene
vrednosti
Pamćenje
promena (Change
recordability)
Da li su promene u
specifikaciji
softverskog sistema i
promene u
programskim
modulima na
odgovarajući naĉin
zabeleţene u
programskom kodu,
sa odgovarajućim
komentarima?
X=A/B,
Pri ĉemu je A – Broj
promena u
funkcijama/modulima
koji imaju promenjene
komentare potvrĊene u
reviziji; B – Ukupan
broj funkcija/modula
koji su promenjeni;
0<=X<=1
Ukoliko vrednost X
teţi 1, promene su
bolje zabeleţene.
Ukoliko vrednost X
teţi 0, promene su
slabije zabeleţene ili je
izvršeno malo promena
(visoka stabilnost).
Tabela 3: Pojednostavljeni prikaz metrike Change recordability
Maintainability
Changeability
Change recordability
62
4.1.4. ISO/IEC 9126-4
ISO/IEC 9126-4 prouĉava kvalitet u softverskim metrikama (Quality in use metrics).
Drugim reĉima, na ovaj naĉin se moţe utvrditi da li softverski proizvod zadovoljava
specifiĉne potrebe korisnika kako bi se postigli odreĊeni ciljevi u pogledu efektivnosti,
produktivnosti, bezbednosti i zadovoljstva korisnika.
U tom kontekstu ISO/IEC 9126-4 definiše sledeće grupe metrika [ISO9126_4]:
Metrike za utvrĊivanje efektivnosti (Effectiveness metrics) – procenjuju da li su zadaci
koje su izvršili korisnici doveli do postizanja specifiĉnih ciljeva, pri ĉemu se u obzir
uzima taĉnost i kompletnost u specifiĉnom kontekstu primene;
Metrike za utvrĊivanje produktivnosti (Productivity metrics) – procenjuju da li su
resursi koje upotrebljavaju korisnici u relaciji sa postignutom efektivnošću u
specifiĉnom kontekstu primene;
Metrike za utvrĊivanje sigurnosti (Safety metrics) – procenjuju nivo rizika koji moţe
dovesti do povrede ljudi, poslovanja, softvera ili okruţenja u specifiĉnom kontekstu
primene;
Metrike za utvrĊivanje zadovoljenja (Satisfaction metrics) – procenjuju odnos
korisnika prema korišćenju softverskog proizvoda u specifiĉnom kontekstu primene.
Na primer, razlikujemo sledeće Metrike za utvrĊivanje efektivnosti (Effectiveness metrics):
Slika 11: Metrike za utvrĎivanje efektivnosti [ISO9126_4]
Effectivness metrics
Task effectivness
Task completion
Error frequency
63
Metrika Frekvencija greške (Error frequency) definisana je na sledeći naĉin (dajemo
pojednostavljeni prikaz) [ISO9126_4]:
Naziv metrike Svrha metrike Formula Interpretacija izmerene
vrednosti
Frekvencija greške
(Error frequency)
Potrebno je utvrditi
frekvenciju grešaka
koje se mogu javiti pri
korišćenju softvera od
strane korisnika.
X=A/T,
pri ĉemu je A – Broj
grešaka koje napravi
korisnik pri korišćenju
softvera; T – vreme ili
broj zadataka koje
izvršava korisnik.
X >=0
Bolje je ukoliko
vrednost X teţi 0. U
tom sluĉaju je broj
grešaka koje napravi
korisnik pri korišćenju
softvera manji.
Tabela 4: Metrika Frekvencija greške
4.2. Swat4j i Analyst4j
Swat4j [ZWSwat4j] je softverski paket namenjen praćenju i upravljanju aktivnostima
razvoja i odrţavanja 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 sledeći atributi kvaliteta softvera [ZWSwat4j]:
Testiranje (Testability);
Kvalitet projektovanja (Design quality);
Performanse (Performance);
Razumljivost (Understandability);
Odrţavanje (Maintainability) i
Ponovno korišćenje (Reusability).
TakoĊe, softverski paket se moţe koristiti za pronalaţenje potencijalnih grešaka (bugs)
u programu. U okviru Swat4j je integrisano preko 30 metrika (metrike su prilagoĊene
karakteristikama programskog jezika Java) i preko 100 industrijskih standarda koji se odnose
na pravila najbolje prakse u pisanju programskog kôda (Best Practise Rules). Prema
predefinisanom modelu kvaliteta softvera, za svaki atribut softverskog sistema vezano je više
metrika, odnosno više pravila u pisanju programskog kôda. Sa druge strane, jedna metrika,
odnosno jedno pravilo, moţe se odnositi na više atributa softverskog sistema, što je i
prikazano na Slici 12.
64
Slika 12: Odnos izmedju atributa softverskog sistema, softverskih metrika i pravila u pisanju
programskog koda
Osiguranje kvaliteta programskog kôda ne predstavlja opcionu aktivnost ni za jednu
sofversku kompaniju. U krajnjem sluĉaju defekat u softverskom sistemu moţe izazvati velike
probleme, npr. povećanje troškova odrţavanja softvera, što moţe dovesti do nezadovoljstva
krajnjih korisnika. Kontrola „Entropije programskog kôda“ predstavlja veliki izazov (i teţak
zadatak) za svakog projekt menadţera. Jedna od metoda koju koriste mnoge organizacije je
pridrţavanja standarda u pisanju programskog kôda što obezbeĊuje unformnost i prati
najbolje prakse pisanja programskog kôda kako bi se, u skladu sa definisanim modelom
kvaliteta, ocenili atributi softverskog sistema. Ipak, u velikom broju sluĉajeva to je mnogo
lakše reći nego uraditi iz prostog razloga što „kvalitet“ moţe razliĉitim ljudima znaĉiti
razliĉite stvari. U tom kontekstu, termin „kvalitet“ moţe biti priliĉno dvosmislen ukoliko se
pravilno ne definiše.
Moţemo reći da Swat4j sadrţi sledeće grupe metrika:
Objektno-orijentisane metrike (Object-oriented metrics) – omogućavaju merenje kvaliteta
objektnog projektovanja, veza i zavisnosti izmeĊu objekata, kao i drugih principa:
1. Sloţenost ponderisanih metoda (Weighted Methods Complexity – WMC) - WMC se
definiše kao suma sloţenosti metoda;
2. Broj odgovora klase (Response For Class – RFC) - Definiše 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 meĊusobne 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 nasleĊivanja (Depth of Inheritance Tree – DIT) - Dubina klase u
hijerarhiji nasleĊivanja definiše se kao maksimalni broj nivoa od posmatranog ĉvora
do korena drveta;
6. Broj podklasa (Number of Children – NOC) - NOC raĉuna broj neposrednih podklasa
posmatrane klase/interfejsa u hijerarhiji klasa.
65
Metrike za odreĎivanje složenosti (Complexity metrics) – Sloţenost sistema ili njegovih
komponenti predstavlja teţinu razumevanja softverskog sistema ili komponenti softverskog
sistema. Razlikujemo sledeće metrike za odreĊivanje sloţenosti:
1. Cikliĉna sloţenost (Cyclomatic Complexity – McCabe) - Cikliĉna sloţenost
softverskog sistema se meri raĉunanjem broj taĉaka odluĉivanja (decision points) ili
uslovnih iskaza (conditional statements) posmatranog programskog jezika;
2. Halstedova sloţenost (Halstead Complexity Metrics) - Sluţi za merenje sloţenosti
modula direktno iz izvornog kôda programa korišćenjem operatora i operanda.
Metrike za odreĎivanje indeksa održavanja (Maintainability Index metric) – Predstavlja
kvantitativnu meru namenjenu merenju i praćenju odrţavanja kako bi se smanjila ili ukinula
tendencija sistema prema “entropiji programskog kôda”.
Metrike koje se odnose na programski kôd (Code metrics) – pomenute metrike
predstavljaju specijalizovane metrike koje omogućavaju specifiĉan uvid u kvalitet programski
kôda. Ove metrike se koriste u kombinaciji sa jednom ili više specijalizovanih metrika kao što
su npr. objektno-orijentisane metrike ili metrike za odreĊivanje sloţenosti. Pri tome, ove
metrike moţemo 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 kôda (Number of lines of Code – NLOC_MTD) - LOC
predstavlja meru kojom se moţe utvrditi veliĉina modula, odnosno projekta;
2. Procenat komentara (Percentage of comments – POC_MTD) - Raĉuna procenat
komentara u metodi i definiše se kao odnos izmeĊu ukupnog broja komentarisanih
linija u metodi i ukupnog broja linija u metodi;
3. Broj promenljivih (Number of Variables – NOV_MTD) - Raĉuna broj promenljivih u
metodi;
4. Broj nekorišćenih promenljivih (Number of Unused Variables – NOUV_MTD) -
Raĉuna broj nekorišćenih promenljivih u metodi;
5. Broj komentarisanih linija (Number of comment lines – CL_MTD) - Raĉuna ukupan
broj komentarisanih linija u okviru metode;
6. Broj parametara (Number of Parameters – NOP_MTD) - Raĉuna ukupan broj
parametara u okviru metode;
7. Broj nekorišćenih parametara (Number of Unused Parameters –NOUP_MTD) -
Raĉuna ukupan broj nekorišćenih parametara u okviru metode.
Metrike na nivou klase (Class Level) 1. Broj linija kôda (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) - Raĉuna broj roditelja klase. Pri
tome, klasa ukljuĉuje druge klase i interfejse;
3. Broj atributa (Number of Fields – NOFLD_CLS) - Raĉuna ukupan broj atributa klase.
Pri tome, klasa ukljuĉuje 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;
66
6. Broj unutrašnjih klasa (Number of Inner Classes – NOIC_CLS) - Raĉuna broj
unutrašnjih klasa u okviru klase pri ĉemu se ne uzimaju u obzir anonimne klase5.
Metrike na nivou datoteke (File Level) 1. Broj linija kôda (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) - Sluţi za
merenje sloţenosti modula programa korišćenjem operatora i operanada;
Metrike na nivou paketa (Package Level)
1. Broj linija kôda (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) - Raĉuna ukupan broj klasa u paketu;
3. Broj interfejsa (Number of Interface – NOIFC_PKG) - Raĉuna broj interfejsa u
paketu;
4. Broj datoteka (Number of Files – NOF_PKG) - Raĉuna broj datoteka u paketu.
4.2.1. Opis softverskih metrika
Kao što je već napomenuto, Swat4j sadrţi sledeće grupe metrika:
Objektno-orijentisane metrike (Object-oriented metrics);
Metrike za odreĊivanje sloţenosti (Complexity metrics);
Metrike za odreĊivanje indeksa odrţavanja (Maintainability Index metric) i
Metrike koje se odnose na programski kôd (Code metrics).
U nastavku dajemo prikaz najvaţnijih metrika posmatranih kategorija. Pri tome, svaka
softverska metrika će imati sledeću strukturu:
- Naziv metrike;
- Opis metrike;
- Matematiĉki model;
- Interpretacija;
- Veza sa atributima softverskog sistema;
Objektno-orijentisane metrike
1. Složenost ponderisanih metoda (WMC)
Naziv metrike: Složenost ponderisanih metoda (WMC)
Opis metrike: WMC se definiše kao suma sloţenosti metoda. Pri tome je ostavljena
mogućnost izbora „sloţenosti metode“ koju treba uzeti u razmatranje.
Matematički model: Pretpostavimo da imamo klasu C sa metodama M1, M2,..., Mn (metode
su definisane u klasi). Neka je C1, C2,..., Cn sloţenost metoda. U tom sluĉaju je:
WMC=C1+C2+...+Cn
67
U softverskom paketu Swat4j se kao mera „sloţenosti metode“ koristi metrika Ciklična
složenost (Cyclomatic Complexity). Pri tome, softverski paket ne uzima u obzir interfejse i
nasleĊivanje klasa, ali se razmatraju anonimne klase.
Interpretacija: WMC >= 1. Najbolje bi bilo kada bi Ciklična složenost svake metode bila 1.
U tom sluĉaju bi Složenost ponderisanih metoda bila jednaka broju metoda. Ukoliko klasa
ima visoku Složenost ponderisanih metoda, trebalo bi izvršiti refaktorisanje (refaktorisati
klasu/metodu na dve ili više klasa/metoda).
Veza sa atributima softverskog sistema: Testiranje, Razumljivost, Odrţavanje, Ponovno
korišćenje.
2. Broj odgovora klase (RFC)
Naziv metrike: Broj odgovora klase (RFC)
Opis metrike: U objektno-orijentisanom pristupu objekti komuniciraju prvenstveno
razmenom poruka. Na primer, odreĊena poruka moţe dovesti do odreĊenog ponašanja objekta
na taj naĉin što će pozvati neku njegovu metodu. U tom kontekstu metode se mogu definisati
kao odgovor na odreĊne poruke.
Matematički model: Uzimajući u obzir definiciju metrike moţemo reći 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 sledeće:
Konstruktori se raĉunaju kao metode;
Anonimne klase/Unutrašnje klase se predstavljaju posebno (dobija se poseban
izveštaj);
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, Odrţavanje, Ponovno korišćenje.
68
3. Nedostatak kohezivnosti metoda u klasi (LCOM)
Naziv metrike: Nedostatak kohezivnosti metoda u klasi (LCOM)
Opis metrike: Ukoliko klasa ima metode koje se izvršavaju nad istim skupom atributa za
klasu se kaţe da je kohezivna. Kohezija je usmerena na atribute objekta, kao i na metode koje
pristupaju atributima.
LCOM predstavlja meru meĊusobne povezanosti metoda.
Matematički model: Uzimajući u obzir definiciju metrike, u softverskom paketu Swat4j se
nedostatak kohezivnosti metoda u klasi raĉuna na sledeći naĉin:
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 izmeĊu 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 više 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,
Odrţavanje, Ponovno korišćenje.
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.
Matematički model: CBO dobijamo brojanjem povezanih klasa. Pri tome, za softverski paket
Swat4j je bitno napomenuti i sledeće:
Interfejsi, anonimne klase, Enum promenljive i nasleĊivanje se ne uzimaju u
obzir;
Konstruktori se smatraju metodama;
Statiĉko uvoĊenje (static import) klase se uzima u obzir;
Direktan pristup statiĉkim promenljivim drugih klasa se uzima u obzir.
Interpretacija: Prevelika povezanost objekata klasa dovodi do narušavanja modularnog
projektovanja i spreĉava ponovno korišćenje softverskih komponenti (reuse). Sa druge strane,
ukoliko je klasa „više nezavisna“ lakše se moţe koristiti u drugim aplikacijama pa je stoga
potrebno povezanost klasa svesti na minimum.
69
Veza sa atributima softverskog sistema: Testiranje, Kvalitet projektovanja, Performanse,
Razumljivost, Odrţavanje, Ponovno korišćenje.
5. Dubina stabla nasleĎivanja (DIT)
Naziv metrike: Dubina stabla nasleĎivanja (DIT)
Opis metrike: Dubina klase u hijerarhiji nasleĊivanja definiše se kao maksimalni broj nivoa
od posmatranog ĉvora do korena drveta.
Matematički model: U softverskom paketu Swat4j, DIT za odreĊenu Java klasu dobija se
tako što se izraĉuna broj predakata u hijerarhiji nasleĊivanja. Pri tome je bitno napomenuti
sledeće:
Ukoliko se pronaĊe više nadklasa, raĉunanje se ponavlja za sve putanje i u
razmatranje se uzima najveći broj nivoa (najveći broj nivoa postaje DIT
vrednost);
Podrazumevana DIT vrednost za klasu je 1;
Podrazumevana DIT vrednost za interfejs je 0;
Ne uzimaju se u obzir unutrašnje anonimne klase.
Interpretacija: Ukoliko je klasa dublje u hijerarhiji verovatno je veći broj metoda koje klasa
nasleĊuje što moţe oteţati predviĊanje ponašanje klase. Sa druge strane, moţe se povećati
potencijal ponovnog korišćenja metoda. Preporuĉljivo je da DIT vrednost bude što manja.
Veza sa atributima softverskog sistema: Testiranje, Kvalitet projektovanja, Razumljivost,
Odrţavanje, Ponovno korišćenje.
6. Broj podklasa (NOC)
Naziv metrike: Broj podklasa (NOC)
Opis metrike: NOC raĉuna broj neposrednih podklasa posmatrane klase/interfejsa u
hijerarhiji klasa.
Matematički 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 veći, povećava se mogućnost ponovnog korišćenja jer je
nasleĊivanje jedan od oblika ponovnog korišćenja. TakoĊe, sa rastom NOC povećava se i
verovatnoća neodgovarajuće apstrakcije roditeljske klase (ukoliko posmatrana klasa ima
veliki broj potomaka moţe doći do greške u kreiranju podklasa).
Veza sa atributima softverskog sistema: Testiranje, Kvalitet projektovanja, Ponovno
korišćenje.
70
Metrike za određivanje složenosti
7. Ciklična složenost (CC)
Naziv metrike: Ciklična složenost (CC)
Opis metrike: Ciklična složenost predstavlja meru sloţenosti primenjenog algoritma u
metodi.
Matematički model: Ciklična složenost softverskog sistema se meri raĉunanjem broja taĉaka
odluĉivanja (decision points) ili uslovnih iskaza (conditional statements) posmatranog
programskog jezika.
Drugim reĉima, algoritam uzima u obzir jedan od sledećih 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 uĉiniti ukoliko je uslov
zadovoljen, odnosno šta uĉiniti ukoliko uslov nije zadovoljen). U tom sluĉaju cikliĉna
sloţenost predstavlja broj linearno nezavisnih putanja v(G) u usmerenom grafu G.
U softverskom paketu Swat4j cikliĉna sloţenost se raĉuna na sledeći naĉin:
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 cikliĉna sloţenost svake metode bila 1.
Ukoliko je CC metode veća, primenjeni algoritam je sloţeniji (ima više grananja i ispitivanja
uslova).
Veza sa atributima softverskog sistema: Testiranje, Razumljivost, Odrţavanje.
8. Halstedova složenost (HE)
Naziv metrike: Halstedova složenost (HE)
Opis metrike: Sluţi za merenje sloţenosti modula direktno iz izvornog kôda programa
korišćenjem operatora i operanda. Ova metrika je znaĉajan indikator sloţenosti programskog
kôda.
Matematički model: Napor potreban za implementaciju ili razumevanje programa
proporcionalan je obimu programa i nivou teţine programa. Stoga je
HE=V*D ili
HE=V/L,
pri ĉemu je
n1 - Broj jedinstvenih (razliĉitih) operatora
n2 - Broj jedinstvenih (razliĉitih) operanada
71
N1 - Ukupan broj operatora
N2 - Ukupan broj operanada
N = N1 + N2 - Halstedova duţina programa (Halstead program length)
n = n1 + n2 - Veliĉina reĉnika (Vocabulary size)
V= N * log2(n) - Obim programa (Program volume)
D = ( n1 / 2 ) * ( N2 / n2 ) - Nivo teţine (Difficulty level)
L = 1 / D ili L = (2 * n2) / (n1 * N2) - Nivo programa (Program level)
Pri tome, bitno je napomenuti sledeće:
- Komentari se ne uzimaju u obzir
- Unutrašnje klase i anonimne klase se uzimaju u obzir
Interpretacija: Metrika se moţe koristiti za utvrĊivanje napora potrebnog za implementaciju
korisniĉkih zahteva, kao i napora potrebnog za uspešno odrţavanje softverskog sistema.
Ukoliko je vrednost parametra HE veća, biće potreban veći napor kako bi se uspešno
implementirao korisniĉki zahtev, odnosno uspešno odrţavao softverski sistem.
Veza sa atributima softverskog sistema: Testiranje, Razumljivost, Odrţavanje.
9. Indeks odrţavanja {datoteke, klase, paketa, projekta} (MI)
Naziv metrike: Indeks održavanja {datoteke, klase, paketa, projekta} (MI)
Opis metrike: Predstavlja kvantitativnu meru namenjenu merenju i praćenju odrţavanja kako
bi se smanjila ili ukinula tendencija sistema prema “entropiji programskog kôda”.
Matematički model: U softverskom alatu Swat4j MI se raĉuna po sledećoj 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 – Proseĉan Halstedov obim programa po modulu
aveV(G) = Proseĉna cikliĉna sloţenost po modulu
aveLOC = Proseĉan broj linija koda po modulu
perCM = Proseĉan procenat linija komentara po modulu
Interpretacija: Ukoliko je MI < 65 smatra se da su mogućnosti odrţavanja softvera male.
Ukoliko je 65<=MI<85 smatra se da su mogućnosti odrţavanja softvera dobre. Ukoliko je MI
>= 85 smatra se da su mogućnosti odrţavanja softvera odliĉne.
Veza sa atributima softverskog sistema: Odrţavanje.
72
U Tabeli 5. dajemo matriĉni prikaz pojedinih metrika koje podrţava 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 softverskog sistema vezano je više
metrika. Sa druge strane, jedna metrika se moţe odnositi na više atributa softverskog sistema. Ukoliko se konkretna metrika moţe koristiti za
odreĊivanje vrednosti posmatranog atributa kvaliteta softvera postavljena je oznaka .
Softverska metrika Atribut softverskog sistema Testiranje Kvalitet
projektovanja
Performanse Razumljivost Odrţavanje Ponovno
korišćenje
Objektno
orjentisane
metrike
Sloţenost ponderisanih metoda
(WMC)
Broj odgovora klase (RFC)
Nedostatak kohezivnosti metoda
u klasi (LCOM)
Povezanost objekata (CBO)
Dubina stabla nasledjivanja
(DIT)
Broj podklasa (NOC)
Metrike za
odredjivanje
sloţenosti
Cikliĉna sloţenost (McCabe)
Halsedova sloţenost (HE)
Metrike za
odredjivanje
indexa odrţavnja
Index odrţavanja (MI)
Tabela 5: Odabrane metrike u modelu kvaliteta softverskog paketa Swat4j
73
4.3. Sažetak
U ovom poglavlju prikazan je ISO/IEC 9126 standard kojim se definiše kvalitet
softverskog sistema. Ovaj standard se sastoji iz ĉetiri dela:
ISO/IEC 9126-1 kojim se definiše model kvaliteta softvera (Quality model),
ISO/IEC 9126-2 kojim se definišu eksterne metrike (External metrics),
ISO/IEC 9126-3 kojim se definišu interne metrike (Internal metrics) i
ISO/IEC 9126-4 kojim se definiše kvalitet u korišćenju metrika (Quality in use
metrics).
Zatim je korišćenjem matematiĉkih modela dat prikaz metrika koje se nalaze u
softverskom paketu Swat4j (koji je, u stvari, zasnovan na ovom standardu).
Na ovaj način smo realizovali treći cilj istraživanja (Dati pregled ISO/IEC 9126
standarda).
74
5. STUDIJSKI PRIMER
U ovom poglavlju ćemo dati studijski primer i opisati uprošćenu Larmanovu metodu razvoja
softvera. Studijski primer opisan u ovom poglavlju je implementiran na dva naĉina,
korišćenjem EJB 2.1 i EJB 3.0 tehnologije. Ta dva primera su u poglavlju 6. komparativno
analizirana.
5.1. Uprošćena Larmanova metoda razvoja softvera
Uprošćena Larmanova metoda razvoja softvera se sastoji iz 5 faza:
1. Prikupljanje korisniĉkog zahteva
2. Analiza
3. Projektovanje
4. Implementacija
5. Testiranje
U nastavku ćemo reći više o pojednim fazama.
5.1.1. Zahtevi
Korisniĉki zahtev predstavlja prvu fazu razvoja jednog softvera. Jedan od modela za
predsavaljanje korisniĉkog zahteva je i verbalni model.
5.1.1.1. Verbalni model
Na osnovu korisniĉkog zahteva, potrebno je projektovati web aplikaciju koja prati
poslovanje Agencije za zapošljavanje. Poslovanje se zasniva na tome da vlasnik agencije
prikuplja podatke i odrţava bazu podataka o kadrovima raznih profila, i te podatke ustupa
firmama uz meseĉnu novĉanu nadoknadu. Obiĉni 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 korišćena je uprošćena Larmanova metoda razvoja
softvera.
5.1.1.2. Slučajevi korišćenja sistema
U Larmanovoj metodi razvoja softvera zahtevi se opisuju pomoću Modela Sluĉaja
Korišćenja (Use-Case Model). U ovom primeru postoji 3 aktera, i svaki od njih ima neke
sluĉajeve sluĉajeve korišćenja. Sluĉajevi korišćenja su dati na slici.
75
Slika 13: Slučajevi korišćenja sistema
5.1.1.3. Opis slučaja korišćenja
SK1: Slučaj korišćenja – Prijava člana
Naziv SK
Prijava ĉlana
Aktor SK
Ĉlan (fiziĉko lice) Učesnici 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 vraća poruku da je ĉlan snimljen (IA)
Logovanje
Prijava clana
Promena clana
Brisanje clana
clan (fizicko lice)
Logovanje
Prijava firme
Promena firme
Brisanje firme
Pretraga clanova
firma
Logovanje
Brisanje clana
Brisanje firme
Evidentiranje clanarine
administrator
76
Alternativni scenario
3.1. Ukoliko već postoji ĉlan sa istim korisniĉkim imenom sistem vraća poruku da ne moţe da
kreira slog u bazi (IA) i prekida se izvršenje scenarija.
SK2: Slučaj korišćenja – Logovanje člana
Naziv SK
Logovanje ĉlana
Aktor SK
Ĉlan (fiziĉko lice) Učesnici 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 odgovarajući sistem vraća poruku (IA) i prekida se
izvršenje scenarija.
4.1. Ukoliko dodje do greške prilikom ĉitanja podataka iz baze, sistem vraća poruku o grešci
(IA)
SK3: Slučaj korišćenja – Brisanje člana
Naziv SK
Brisanje ĉlana
Aktor SK
Ĉlan (fiziĉko lice) Učesnici 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 obriše podatke o ĉlanu (APSO)
2. Sistem briše podatke o ĉlanu (SO)
3. Sistem prikazuje ĉlanu poruku da je uspešno obrisan slog (IA)
77
Alternativni scenario
2.1. Ukoliko dodje do greske u toku operacije brisanja sistem vraća poruku da slog nije
obrisan u bazi (IA) i prekida se izvršenje scenarija.
SK4: Slučaj korišćenja – Promena podataka o članu
Naziv SK
Promena podataka o ĉlanu
Aktor SK
Ĉlan (fiziĉko lice) Učesnici 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 uspešno promenjen slog.(IA)
Alternativni scenario
3.1. Ukoliko dodje do greske u toku operacije promene sistem vraća poruku da slog nije
promenjen u bazi (IA) i prekida se izvršenje scenarija.
SK5: Slučaj korišćenja – Logovanje pravnog lica (firme)
Naziv SK
Logovanje pravnog lica
Aktor SK
Pravno lice (firma) Učesnici 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)
78
Alternativni scenario
3.1. Ukoliko username i password nisu odgovarajući sistem vraća poruku (IA) i prekida se
izvršenje scenarija.
4.1. Ukoliko dodje do greške prilikom ĉitanja podataka iz baze, sistem vraća poruku
o grešci (IA).
SK6: Slučaj korišćenja – Prijava pravnog lica
Naziv SK
Prijava pravnog lica
Aktor SK
Pravno lice Učesnici 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 vraća poruku da je kreiran slog (IA)
Alternativni scenario
3.1. Ukoliko već postoji pravno lice sa istim imenom sistem vraća poruku da ne moţe da
kreira slog u bazi (IA) i prekida se izvršenje scenarija.
SK7: Slučaj korišćenja – Brisanje pravnog lica
Naziv SK
Brisanje pravnog lica
Aktor SK
Pravno lice Učesnici 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 obriše podatke o pravnom licu (APSO)
2. Sistem briše podatke o pravnom licu (SO)
3. Sistem prikazuje pravnom licu poruku da je uspešno obrisan slog.(IA)
79
Alternativni scenario
2.1. Ukoliko dodje do greske u toku operacije brisanja sistem vraća poruku da slog nije
obrisan u bazi (IA) i prekida se izvršenje scenarija.
SK8: Slučaj korišćenja – Promena podataka o pravnom licu
Naziv SK
Promena podataka o pravnom licu
Aktor SK
Pravno lice Učesnici 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 uspešno promenjen slog (IA)
Alternativni scenario
3.1. Ukoliko dodje do greske u toku operacije promene sistem vraća poruku da slog nije
promenjen u bazi (IA) i prekida se izvršenje scenarija.
SK9: Slučaj korišćenja – Pretraga članova
Naziv SK
Pretraga ĉlanova od strane pravnog lica
Aktor SK
Pravno lice Učesnici 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 pretraţi bazu podataka ĉlanova (APSO)
3. Sistem pretraţuje bazu podataka (SO)
4. Sistem prikazuje zaposlenom podatke o ĉlanovima koji odgovaraju zadatom kriterijumu
(IA).
80
Alternativni scenario
3.1. Ukoliko ne postoji ni jedan ĉlan koji zadovoljava kriterijum pretrage sistem vraća
odgovarajuću poruku (IA)
3.2. Ukoliko firma nije platila ĉlanarinu za tekući mesec, sistem prikazuje poruku da
ĉlanarina nije plaćena.
SK10: Slučaj korišćenja – Logovanje administratora
Naziv SK
Logovanje administratora
Aktor SK
Administrator Učesnici 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 odgovarajući sistem vraća poruku (IA) i prekida se
izvršenje scenarija.
SK11: Slučaj korišćenja – Brisanje člana (od strane administratora)
Naziv SK
Brisanje ĉlana (od strane administratora)
Aktor SK
Administrator Učesnici 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 obriše podatke o ĉlanu (APSO)
3. Sistem briše podatke o ĉlanu (SO)
4. Sistem prikazuje administratoru poruku da je uspešno obrisan slog (IA)
81
Alternativni scenario
3.1. Ukoliko dodje do greske u toku operacije brisanja sistem vraća poruku da slog nije
obrisan u bazi (IA) i prekida se izvršenje scenarija.
SK12: Slučaj korišćenja – Brisanje pravnog lica (od strane administratora)
Naziv SK
Brisanje pravnog lica (od strane administratora)
Aktor SK
Administrator Učesnici 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 obriše podatke o pravnom licu(APSO)
3. Sistem briše podatke o pravnom licu (SO)
4. Sistem prikazuje administratoru poruku da je uspešno obrisan slog (IA)
Alternativni scenario
3.1. Ukoliko dodje do greske u toku operacije brisanja sistem vraća poruku da slog nije
obrisan u bazi (IA) i prekida se izvršenje scenarija.
SK13: Slučaj korišćenja – Evidentiranje članarine za pravno lice
Naziv SK
Evidentiranje ĉlanarine za pravno lice
Aktor SK
Administrator Učesnici 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)
82
Alternativni scenario
3.1. Ukoliko dodje do greske u toku operacije evidentiranja sistem vraća poruku (IA) i
prekida se izvršenje scenarija.
5.1.2. Analiza
Faza analize opisuje logiĉku strukturu i ponašanje softverskog sistema (poslovnu
logiku softverskog sistema). Ponašanje softverskog sistema se opisuje pomoću sistemskih
dijagrama sekvenci, koji se prave za svaki SK, i pomoću ugovora o sistemskim operacijama,
koje se dobijaju na osnovu sistemskih dijagrama sekvenci. Struktura softverskog sistema se
opisuje pomoću 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. Ponašanje sistema
5.1.2.1.1. Sistemski dijagram sekvenci
DS1: Dijagrami sekvenci slučaja korišćenja – Prijava člana
Osnovni scenario SK
1. Ĉlan poziva sistem da snima podatke (APSO)
2. Sistem vraća poruku o uspesnosti (IA)
Alternativni scenario
2.1. Ukoliko već postoji ĉlan sa istim korisniĉkim imenom sistem vraća poruku da ne moţe da
kreira slog u bazi (IA) i prekida se izvršenje scenarija.
: Fizicko lice
(clan)
Sistem
SOsnimiClana(podaci)
poruka
83
DS2: Dijagrami sekvenci slučaja korišćenja – 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)
Alternativni scenario
1.1. Ukoliko username i password nisu odgovarajući sistem vraća poruku (IA) i prekida se
izvršenje scenarija.
2.1. Ako se desi greška prilikom uzimanja podataka o ĉlanu iz baze, sistem vraća poruku o
grešci (IA) i prekida se izvršenje scenarija.
: Fizicko lice (clan)Sistem
SOproveriKorisnika()
podaci
SOvratiClana()
84
DS3: Dijagrami sekvenci slučaja korišćenja – Brisanje člana
Osnovni scenario SK
1. Ĉlan poziva sistem da obriše podatke o ĉlanu (APSO)
2. Sistem vraća poruku o uspešnosti (IA)
Alternativni scenario
2.1. Ukoliko dodje do greške u toku operacije brisanja sistem vraća poruku da slog nije
obrisan u bazi (IA) i prekida se izvršenje scenarija.
: Fizicko lice (clan)Sistem
SObrisiClana(podaci)
poruka
85
DS4: Dijagrami sekvenci slučaja korišćenja – 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 uspešno promenjen podatak.(IA)
Alternativni scenario
1.1. Ukoliko dodje do greške u toku operacije promene sistem vraća poruku da slog nije
promenjen u bazi (IA) i prekida se izvršenje scenarija.
: Fizicko lice (clan)Sistem
SOpromeniClana(podaci)
promenjeni podaci
86
DS5:Dijagrami sekvenci slučaja korišćenja – 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)
Alternativni scenario
1.1. Ukoliko username i password nisu odgovarajući sistem vraća poruku (IA) i prekida se
izvršenje scenarija.
2.1. Ako se desi greska prilikom uzimanja podataka o pravnom licu iz baze, sistem
vraća poruku (IA) i prekida se izvršenje scenarija.
: FirmaSistem
SOproveriKorisnika()
podaci
SOvratiFirmu()
87
DS6: Dijagrami sekvenci slučaja korišćenja – Prijava pravnog lica
Osnovni scenario SK
1. Pravno lice poziva sistem da snimi podatke (APSO)
2. Sistem vraća poruku o uspešnosti (IA)
Alternativni scenario
2.1. Ukoliko već postoji pravno lice sa istim imenom sistem vraća poruku da ne moţe da
kreira slog u bazi (IA) i prekida se izvršenje scenarija.
Sistem : Firma
SOsnimiFirmu(podaci)
poruka
88
DS7: Dijagrami sekvenci slučaja korišćenja – Brisanje pravnog lica
Osnovni scenario SK
1. Pravno lice poziva sistem da obriše podatke o pravnom licu (APSO)
2. Sistem vraća poruku o uspešnosti (IA)
Alternativni scenario
2.1. Ukoliko dodje do greške u toku operacije brisanja sistem vraća poruku da slog nije
obrisan u bazi (IA) i prekida se izvršenje scenarija.
: FirmaSistem
SObrisiFirmu(podaci)
poruka
89
DS8: Dijagrami sekvenci slučaja korišćenja – 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 uspešno promenjen slog (IA)
Alternativni scenario
1.1. Ukoliko dodje do greške u toku operacije promene sistem vraća poruku da slog nije
promenjen u bazi (IA) i prekida se izvršenje scenarija.
: FirmaSistem
SOpromeniFirmu(podaci)
promenjeni podaci
90
DS9: Dijagrami sekvenci slučaja korišćenja – 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)
Alternativni scenario
1.1. Ukoliko pravno lice nije platilo ĉlanarinu, sistem vraca odgovarajucu poruku (IA)
2.1. Ukoliko dodje do greške u toku izvršenja operacije sistem vraća poruku (IA) i prekida se
izvršenje scenarija.
Firma : firmaSistem
SOProveriClanarinu()
SOPronadjiClanoveIVratiIh()
bollean
clanovi
91
DS10: Dijagrami sekvenci slučaja korišćenja – Logovanje administratora
Osnovni scenario SK
1. Adminstrator poziva sistem da proveri username i password (APSO)
2. Sistem prikazuje administratoru meni (IA)
Alternativni scenario
1.1. Ukoliko username i password nisu odgovarajući sistem vraća poruku (IA) i prekida se
izvršenje scenarija.
: AdministratorSistem
SOproveriKorisnika()
podaci
92
DS11: Dijagrami sekvenci slučaja korišćenja – Brisanje člana od strane administratora
Osnovni scenario SK
1. Administrator poziva sistem da obriše podatke o ĉlanu (APSO)
2. Sistem vraća poruku o uspešnosti (IA)
Alternativni scenario
2.1. Ukoliko dodje do greške u toku operacije brisanja sistem vraća poruku da slog nije
obrisan u bazi (IA) i prekida se izvršenje scenarija.
: administratorSistem
poruka
SObrisiClana()
93
DS12: Dijagrami sekvenci slučaja korišćenja – Brisanje pravnog lica od strane
administratora
Osnovni scenario SK
1. Administrator poziva sistem da obriše podatke o pravnom licu (APSO)
2. Sistem vraća poruku o uspešnosti (IA)
Alternativni scenario
2.1. Ukoliko dodje do greške u toku operacije brisanja sistem vraća poruku da slog nije
obrisan u bazi (IA) i prekida se izvršenje scenarija.
: Administrator Sistem
poruka
SObrisiFirmu()
94
DS13: Dijagrami sekvenci slučaja korišćenja – Evidentiranje članarine pravnog lica
Osnovni scenario SK
1. Administrator poziva sistem da snimi podatke o ĉlanarini (APSO)
2. Sistem vraća poruku o uspešnosti (IA)
Alternativni scenario
1.1. Ukoliko dodje do greške u toku izvršenja operacije sistem vraća poruku (IA) i prekida se
izvršenje scenarija.
: AdministratorSistem
SOevidentirajClanarinu()
poruka
95
5.1.2.1.2. Definisanje ugovora o sistemskim operacijama
Sistemske operacije opisuju ponašanje softverskog sistema. Ugovori se prave za
sistemske operacije i oni opisuju njeno ponašanje. Oni opisuju šta operacija treba da radi, a ne
kako će to da radi. Za neke karakteristiĉne 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.
96
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.
97
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 pomoću 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 pomoću konceptualnog modela. Konceptualni
model sadrzi konceptualne klase (domenske objekte) i asocijacije izmedju konceptualnih
klasa.
Konkretan primer konceptualnog modela:
Slika 14: Konceptualni model
98
5.1.2.2.2. Relacioni model
Na osnovu konceptualnog modela moţe se napraviti relacioni model, koji će da
predstavlja osnovu za projektovanje relacione baze podataka. Uoĉene su sledeće 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 fiziĉku strukturu i ponašanje softverskog sistema
(arhitekturu softverskog sistema). Projektovanje arhitekture softverskog sistema obuhvata
projektovanje aplikacione logike, skladišta podataka i korisniĉkog interfejsa. U okviru
aplikacione logike se projektuju kontroler, poslovna logika i database broker. Projektovanje
poslovne logike obuhvata projektovanje logiĉke strukture i ponašanja softverskog sistema.
5.1.3.1. Arhitektura softverskog sistema
Prilikom projektovanja je korisćen model arhitekture sa tri nivoa: korisniĉki interfejs,
poslovna logika i skladiste podataka. Ovakav model omogućava da se sistem koji se razvija
bude prilagodljiv za buduće 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 – korišćenje sistema.
99
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. Moţe se reci da jedna sistemska
operacija predstavlja jedno ţeljeno ponašanje 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 koristeći EJB Session Beans i Entity Beans.
100
Slika 16: Perzistentni okvir
5.1.3.3. Skladište podataka
Tabela – clan Ime kolone Tip podatka
Id Number
JMBG Text
Ime Text
Adresa Text
Telefon Text
Email Text
Starost Number
ZavrsenaSkola Text
StraniJezik Text
VozackaDozvola Text
RadNaRacunaru Text
Username Text
Tabela 6: Skladište podataka - tabela Clan
Primarni kljuĉ – Id
Spoljni kljuĉ – username iz tabele login
101
Tabela - firma
Ime kolone Tip podatka
Id Number
Naziv Text
Adresa Text
Telefon Text
Email Text
Delatnost Text
Username Text
Tabela 7: Skladište podataka - tabela Firma
Primarni kljuĉ – Id
Spoljni kljuĉ – username iz tabele login
Tabela - clanarinaFirme
Ime kolone Tip podatka
Id Number
UsernameFirme Text
DatumIsteka Text
Iznos Number
Firma_id Number
Tabela 8: Skladište podataka - tabela Clanarina Firme
Primarni kljuĉ – RB,usernameFirme
Tabela - login
Ime kolone Tip podatka
Id Number
Username Text
password Text
tipKorisnika Text
Tabela 9: Skladište podataka - tabela Login
Primarni kljuĉ – Id
5.1.3.4. Projektovanje korisničkog interfejsa Korisniĉki interfejs predstavlja realizaciju ulaza i/ili izlaza softverskog sistema
[DrVlajic1]. Korisniĉki interfejs sastoji se od ekranskih formi i kontrolera korisniĉkog interfejsa.
Ekranske forme realizovane su korišćenjem JSP tehnologije, dok se kao kontroler korisniĉkog
interfejsa koristi servlet.
102
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 završi 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 izvršava se SOsnimiClana().
4. Sistem vraća poruku da je ĉlan snimljen (IA)
103
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 izvršava se SOsnimiFirmu().
4. Sistem vraća poruku da je kreiran slog (IA)
104
Login strana
Login strana se prikazuje pošto korisnik klikne na dugme Login. Od korisnika se
oĉekuje da unese odgovarajuće korisniĉko ime i lozinku. Ova stranica je zajedniĉka 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 izvršava se SOproveriKorisnika().
4. Sistem uzima sve podatke o ĉlanu iz baze (SO)
5. Sistem prikazuje sve podatke o ĉlanu (AI)
105
Meni član
Meni ĉlan se prikazuje pošto je ĉlan prošao Login stranicu. Ovde su prikazani podaci o
ĉlanu, kao i mogućnost njihove izmene i brisanja. Ova stranica se koristi u SK Brisanje ĉlana,
SK Promena podataka o ĉlanu.
106
Meni firma
Meni firma se prikazuje pošto je pravno lice prošlo Login stranicu. Ovde su prikazani
podaci o firmi, kao i mogućnost njihove izmene i brisanja. Ova stranica se koristi u SK
Brisanje pravnog lica, SK Promena podataka o pravnom licu, SK Pretraga ĉlanova.
107
Pretraga članova
Ova stranica se prikazuje kad pravno lice ţeli da pretraţi bazu podataka. Pravno lice
unosi kriterijum za pretragu baze podataka ĉlanova. Kada unese kriterijume klikne na dugme
Pretraţi.
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 pretraţuje 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 izvršava se
SOpretraziClanoveIVrati().
4. Sistem prikazuje zaposlenom podatke o ĉlanovima koji odgovaraju zadatom kriterijumu
(IA).
108
Rezultat pretrage članova
Kada firma zada kriterijume za pretragu ĉlanova dobija odgovarajući rezultat, u vidu
liste ĉlanova koji zadovoljavaju kriterijume pretrage. Ovde je dat primer liste ĉlanova koji
zadovoljavaju kriterijum pretrage.
109
Admin meni
Admin meni se prikazuje posto je administrator uneo odgovarajuce korisniĉko 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 sluĉaju korišćenja 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 obriše (APUSO)
2. Administrator poziva sistem da obriše podatke o ĉlanu (APSO)
3. Sistem briše podatke o ĉlanu (SO)
Opis akcije: Administrator popunjava polja i klikom na dugme Obrisi, poziva sistem da
obriše korisnika sa zadatim username-om, tj izvršava se SObrisiClana() ili SObrisiFirmu().
4. Sistem prikazuje administratoru poruku da je uspešno obrisan slog (IA)
110
5.1.3.4.2. Projektovanje kontrolera korisničkog interfejsa
Uloga kontrolera korisniĉkog interfejsa je da [DrVlajic1]:
Prihvati podatke koje šalje ekranska forma;
Konvertuje podatke (koji se nalaze u grafiĉkim elementima) u objekat koji predstavlja
ulazni argument SO koja će biti pozvana;
Šalje zahtev za izvršenje SO do aplikacionog servera (softverskog sistema);
Prihvata objekat (izlaz) softverskog sistema koji nastaje kao rezultat izvršenja SO;
Konvertuje objekat u podatke grafiĉkih elemenata.
U studijskom sluĉaju, kontroler korisniĉkog interfejsa realizovan je kao servlet. Centralni
kontroler aplikacije proslediće poziv do kontrolera korisniĉkog interfejsa koji nastavlja
izvršenje po prethodno utvrĊenom scenariju.
Dajemo kao primer deo kontrolera korisniĉkog 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;
}
}
111
5.1.3.5. Konačni izgled arhitekture softverskog sistema
Na sledećoj slici je data arhitektura aplikacije uradjena korišćenjem EJB 3.0
tehnologije. Na slici se vidi da je model uradjen iz više nivoa.
DOclan (from DOMENSKI OBJEKTI)
DOclanarinaFirme (from DOMENSKI OBJEKTI)
DOfirma (from DOMENSKI OBJEKTI)
1..* 1
1..* 1
LoginBean
proveriKorisnika() createLogin()
(from sessionBeans)
ClanBean
createClan() readClan() deleteClan() updateClan()
(from sessionBeans)
FirmaBean
createFirma() readFirma() deleteFirma() updateFirma()
(from sessionBeans)
Baza podataka
ClanarinaBean
createClanarina() readClanarina() deleteClanarina() updateClanarina()
(from sessionBeans)
GUIKontroler je servlet
ClanarinaRemote (from sessionBeans)
<<Interface>>
FirmaRemote (from sessionBeans)
<<Interface>>
PromeniFirmu
SnimiFirmu
SnimiClana
PromeniClana
BrisiKorisnika
EvidentirajClanarinu
ProveriClanarinu
VratiKorisnika
LoginRemote (from sessionBeans)
<<Interface>>
ProveriKorisnika
Svi DO su Entity Bean-ovi
JSP stranice
KontrolerPLRemote
snimiClana() snimiFirmu() proveriKorisnika() vratiKorisnika() brisiKorisnika() pretraziClanoveIVratiIh() evidentirajClanarinu() proveriClanarinu() promeniClana() promeniFirmu()
<<Interface>>
GUIKontroler
KontrolerPLBean
snimiClana() snimiFirmu() proveriKorisnika() vratiKorisnika() brisiKorisnika() pretraziClanoveIVratiIh() evidentirajClanarinu() proveriClanarinu() promeniClana() promeniFirmu()
PretraziClanoveIVratiIh
ClanRemote (from sessionBeans)
<<Interface>>
Slika 17: Kompletna arhitektira softverskog sistema
112
5.4. Sazetak
U ovom poglavlju dat je prikaz studijskog primera korišćenjem uprošćene Larmanove metode
razvoja softvera [DrVlajic1]. Pri tome su date sledeće 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.
113
6. KOMPARATIVNA ANALIZA EJB 2.1 I EJB 3.0 TEHNOLOGIJE
Jedan od ciljeva ovog rada je da se izvši statiĉka i dinamiĉka analiza softverskog sistema koji
su implementirani korišćenjem EJB2.1 i EJB3.0 tehnologiji. U ovom poglavlju će taj cilj biti i
ostvaren.
6.1. Statička analiza softverskog sistema
Statiĉka analiza softverskog sistema predstavlja analizu kojom se opisuju statiĉke osobine
sistema. Ona nam govori kako je sistem projektovan, koliko ga je teško razumeti, menjati,
odrţavati itd. Za statiĉku analizu studijskog primera korišćene su softverske metrike koje
podrţava softverski paket Swat4j i Analyst4j. Akcenat je, pre svega, stavljen na objektno-
orijentisane metrike, Metrike za odreĊivanje sloţenosti i Metrike za odreĊivanje indeksa
odrţavanja.
Slika 18: Model kvaliteta softvera – EJB 2.1 tehnologija
114
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 zajedniĉke za sve atribute kvaliteta softvera. Pri tome, za
pojedine atribute kvaliteta softverskog sistema moţe se definisati razliĉit prag vrednosti
metrike (Threshold).
Prosečna složenost 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 tehnologijom prešao preko dozvoljene vrednosti. Takodje
se vidi da je projekat napisan korišćenjen EJB 3.0 tehnologije dao vrlo dobar rezultat unutar
dozvoljenih vrednosti. Na osnovu toga moţemo zakljuĉiti da EJB 3.0 daje mnogo bolje
rezultate za metriku WMC, od EJB 2.1 tehnologije.
Prosečan 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 prešao preko dozvoljene vrednosti. Sa
druge strane EJB 3.0 je za ovu metriku dala mnogo bolje vrednosti koje su unutar
dozvoljenih. Na osnovu toga moţemo zakljuĉiti da EJB 3.0 daje mnogo bolje rezultate za
metriku RFC, od EJB 2.1 tehnologije.
115
Prosečan 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 zadovoljavajući rezultat unutar
dozvoljenih vrednosti. Sa druge strane EJB 3.0 je za ovu metriku dala lošiji rezultat, koji je
ĉak malo van dozvoljenih vrednosti. Na osnovu toga moţemo zakljuĉiti da EJB 2.1 daje
mnogo bolje rezultate za metriku LCOM, od EJB 3.0 tehnologije. Ovo se moţe objasniti
donekle prirodom EJB 3.0 tehnologije koja je uprostila pisanje koda i mnoge klase i interfejse
generiše sama tehnologija pa se „oseća“ nedostatak kohezije metoda u klasama.
Prosečna 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 zadovoljavajući rezultat unutar dozvoljenih
vrednosti, stim što EJB 3.0 daje za nijansu bolji rezultat. Na osnovu toga moţemo zakljuĉiti
da su klase slabo povezane. Na taj naĉin su klase „više nezavisne“ i lakše se mogu koristiti u
drugim aplikacijama.
Prosečna dubina stabla nasleđivanja (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,
veće od 2.2, u zavisnosti od toga koji atribut softvera se posmatra. Ova metrika je donekle
specifiĉna jer je za pojedine atribute kvaliteta softverskog sistema dat razliĉit prag vrednosti
metrike (Threshold), što će biti objašnjeno u nastavku izlaganja.
Prosečan 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, veće od 0.6, u
zavisnosti od toga koji atribut softvera se posmatra. Ova metrika je donekle specifiĉna jer je
za pojedine atribute kvaliteta softverskog sistema dat razliĉit prag vrednosti metrike
(Threshold), što će biti objašnjeno u nastavku izlaganja.
Prosečna ciklična složenost 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 zadovoljavajući rezultat unutar dozvoljenih vrednosti, stim što EJB 3.0 daje za nijansu
bolji rezultat. Moţemo zakljuĉiti da sloţenost metoda nije velika, odnosno da primenjeni
algoritam nema puno grananja i ispitivanja uslova.
116
Prosečna Halstedova složenost (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 zadovoljavajući rezultat unutar dozvoljenih vrednosti, stim što EJB
3.0 daje bolji rezultat. Pošto je Halstedova sloţenost u dozvoljenim granicama, moţemo reći
da neće biti potreban veći napor kako bi se uspešno odrţavao softverski sistem, odnosno
uspešno implementirao novi korisniĉki zahtev.
Prosečan indeks održavanja (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 veće od 95. Vidi se da obe
tehnologije daju zadovoljavajući rezultat unutar dozvoljenih vrednosti, stim što EJB 2.1 daje
malo rezultat. Ove vrednosti ukazuju da je indeks mogućnosti odrţavanja softverskog sistema
dobar.
U nastavku ćemo dati prikaz metrika za svaki atribut kvaliteta softverskog sistema.
Testiranje
Sa atributom Testiranje povezane su sledeće softverske metrike:
- Složenost ponderisanih metoda (WMC);
- Broj odgovora klase (RFC);
- Nedostatak kohezivnosti metoda u klasi (LCOM);
- Povezanost objekata (CBO);
- Dubina stabla nasleĎivanja (DIT);
- Broj podklasa (NOC);
- Ciklična složenost (CC) i
- Halstedova složenost (HE).
Na Slici 31. i Slici 32. prikazane su metrike koje se odnose na atribut Testiranje.
117
Slika 20: Atribut Testiranje za EJB 2.1 tehnologiju
Slika 21: Atribut Testiranje za EJB 3.0 tehnologiju
118
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 moţe objasniti time sto EJB 3.0 tehnologija
ima lošije 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 sledeće metrike:
- Broj odgovora klase (RFC);
- Nedostatak kohezivnosti metoda u klasi (LCOM);
- Povezanost objekata (CBO);
- Dubina stabla nasleĎivanja (DIT) i
- Broj podklasa (NOC).
Na sledećim slikama su predstavljene metrike koje se odnose na atribut Kvalitet
projektovanja.
Slika 22: Atribut Kvalitet projektovanja za EJB 2.1 tehnologiju
119
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 sledeće metrike:
- Broj odgovora klase (RFC) i
- Povezanost objekata (CBO).
Na sledećim slikama predstavljene su dobijene vrednosti metrika za atribut Performanse.
Slika 24: Atribut Performanse za EJB 2.1 tehnologiju
120
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 graniĉne.
Razumljivost
Sa atributom Razumljivost povezane su sledeće metrike:
- Složenost ponderisanih metoda (WMC);
- Broj odgovora klase (RFC);
- Nedostatak kohezivnosti metoda u klasi (LCOM);
- Povezanost objekata (CBO);
- Dubina stabla nasleĎivanja (DIT);
- Ciklična složenost (CC) i
- Halstedova složenost (HE).
Na sledećim slikama će biti predstavljene vrednosti metrika za atribut Razumljivost.
121
Slika 26: Atribut Razumljivost za EJB 2.1 tehnologiju
122
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) veću od
graniĉne.
Održavanje
Sa atributom Održavanje povezane su sledeće metrike:
- Složenost ponderisanih metoda (WMC);
- Broj odgovora klase (RFC);
- Nedostatak kohezivnosti metoda u klasi (LCOM);
- Povezanost objekata (CBO);
- Dubina stabla nasleĎivanja (DIT);
- Ciklična složenost (CC);
- Halstedova složenost (HE);
- Indeks održavanja (MI).
Na sledećim slikama predstavljene su vrednosti metrika za atribut Odrţavanje.
123
Slika 28: Atribut Održavanje za EJB 2.1 tehnologiju
124
Slika 29: Atribut Održavanje 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) veću od
graniĉne.
Ponovno korišćenje
Sa atributom Ponovno korišćenje povezane su sledeće metrike:
- Složenost ponderisanih metoda (WMC);
- Broj odgovora klase (RFC);
- Nedostatak kohezivnosti metoda u klasi (LCOM);
- Povezanost objekata (CBO);
- Dubina stabla nasleĎivanja (DIT);
- Broj podklasa (NOC);
Na sledećim slikama prikazane su vrednosti metrika koje se odnose na atribut Ponovno
korišćenje.
125
Slika 30: Atribut Ponovno korišćenje za EJB 2.1 tehnologiju
Slika 31: Atribut Ponovno korišćenje 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.
126
Dobijene rezultate moguće 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 više metrika. Sa druge strane, jedna metrika se moţe odnositi na više atributa softverskog
sistema. Ukoliko dobijena vrednost metrike zadovoljava granicu definisanu za odreĊeni atribut softverskog sistema koristi se oznaka , a ukoliko ne
zadovoljava koristi se oznaka .
Softverska metrika
Atribut softverskog sistema Testiranje Kvalitet projektovanja
Performanse Razumljivost Odrţavanje Ponovno korišćenje
Objektno
orjentisane
metrike
Sloţenost ponderisanih metoda (WMC)
EJB 2.1: 17.63
EJB 3.0: 8.2
Broj odgovora klase (RFC) EJB 2.1: 29.46
EJB 3.0: 17.25
Nedostatak kohezivnosti
metoda u klasi (LCOM) EJB 2.1: 0.19
EJB 3.0: 0.44 Povezanost objekata (CBO) EJB 2.1: 3.63
EJB 3.0: 2.35
Dubina stabla nasledjivanja
(DIT) EJB 2.1: 1.24
EJB 3.0: 1.2
Broj podklasa (NOC) EJB 2.1: 0.24
EJB 3.0: 0.6
Metrike za
odredjivanje
sloţenosti
Cikliĉna sloţenost
(McCabe) EJB 2.1: 1.16
EJB 3.0: 1.01
Halsedova sloţenost (HE) EJB 2.1: 41791.88
EJB 3.0: 18077.8
Metrike za
odredjivanje
indexa
odrţavnja
Index odrţavanja (MI) EJB 2.1: 121.88
EJB 3.0: 109.88
Tabela 10: Matrični prikaz vrednosti softverskih metrika u modelu kvaliteta softvera
127
Sada na osnovu tabele sa prikazanim rezultatima moţemo doneti neke zakljuĉke o pomenutim
verzijama tehnologija. Iako je u pitanju ista tehnologija, ali dve njene razliĉite verzije, postoje
razlike u ocenama pojedinih metrika, koje nisu zanemarljive. Ti zakljuĉci su sledeći:
1. Primenom EJB 3.0 tehnologije se dobijaju metode koje su prostije od metoda koje su
dobijene korišćenjem 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 proseĉan nedostatak kohezije od
metoda EJB 3.0. Ovo moţe biti posledica toga što EJB 3.0 ne zahteva da se pisu EJB
interfejsi, pa stoga se oseća 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 korišćenjem dobijaju klase koje nisu
sloţene.
7. Korišćenjem ovih tehnologija dobijaju se aplikacije koje se lako odrţavaju.
Kada se uzme u obzir cela tabela, dolazimo do sledećeg zakljuĉka:
Korišćenjem obe tehnologije se dobijaju aplikacije koje se lako odrţavaju i koje nisu sloţene.
Pri tome EJB 3.0 prednjaĉi po smanjenju sloţenosti 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 moţemo reći da je korišćenje 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.
128
6.2. Dinamička analiza softverskog sistema
Nakon izvršene statiĉke analize za koju su korišćene softverske metrike, dajemo prikaz
dinamiĉke analize softverskog sistema. U tom kontekstu osmišljen je sledeći 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 dinamiĉke (heap)
memorije i analiza upravljanja nitima. U okviru analize upotrebe memorije daje se prikaz
zauzete memorije (vrednost u trenutku merenja i najveća vrednost), kao i relativno vreme koje
koristi Sakupljaĉ smeća (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 najveća vrednost).
Monitoring aplikacije će obuhvatiti podizanje JBOSS aplikativnog servera, aplikacije
na njemu i izvršavanje sluĉaja korišćenja „Snimanje novog clana“. Tako ćemo steći bolju
sliku o tome koliko je zauzeće memorije i niti tokom ovog sluĉaja korišćenja. Isti koraci će
biti izvršeni u sluĉaju EJB 2.1 i EJB 3.0 tehnologija.
Na prvoj slici dajemo grafiĉki prikaz monitoringa aplikacije pisane u EJB 2.1.
Slika 32: Monitoring aplikacije koja koristi EJB 2.1 tehnologiju
U prvom delu prikazano je korišćenje dinamiĉke memorije. Prilikom izvršavanja EJB 2.1
aplikacija, u trenutku testiranja je bilo zauzeto 41.013.744 B dinamiĉke memorije (oznaĉeno
je ljubiĉastom bojom), dok najveća korišćena vrednost iznosi 80.475.072 B (oznaĉeno je
crvenom bojom).
U drugom delu je prikazano relativno vreme koje koristi GC koji je zaduţen 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 trećem delu je dat prikaz broja niti. U trenutku testiranja aktivno je bilo 50 niti koje su se
nalazile u razliĉitim stanjima. Najveći broj aktivnih niti je iznosio 61.
Na sledećoj slici dajemo grafiĉki prikaz monitoringa aplikacije pisane u EJB 3.0.
129
Slika 33: Monitoring aplikacije koja koristi EJB 3.0 tehnologiju
U prvom delu prikazano je korišćenje dinamiĉke memorije. Prilikom izvršavanja EJB 2.1
aplikacija, u trenutku testiranja je bilo zauzeto 55.552.512 B dinamiĉke memorije (oznaĉeno
je ljubiĉastom bojom), dok najveća korišćena vrednost iznosi 89.079.416 B (oznaĉeno je
crvenom bojom).
U drugom delu je prikazano relativno vreme koje koristi GC koji je zaduţen 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 trećem delu je dat prikaz broja niti. U trenutku testiranja aktivno je bilo 52 niti koje su se
nalazile u razliĉitim stanjima. Najveći broj aktivnih niti je iznosio 60.
U Tabeli 11. dat je prikaz izvršenog monitoringa aplikacije. U redovima su prikazane
tehnologije, dok su u kolonama prikazani serveri. Za svaku tehnologiju posmatrani su sledeći
parametri:
1. Zauzeće dinamiĉke 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 najveća vrednost postignuta za vreme izvršavanja testa.
Tehnologija JBOSS aplikativni server
Heap (B) GC (%) Threads (No)
Current Max Current Max Current Max
EJB 2.1 41.013.744 80.475.072 1.1 2.2 50 61
EJB 3.0 55.552.512 89.079.416 3.3 13.4 52 60
Tabela 11: Prikaz rezultata dobijenih monitoringom aplikacije
Na osnovu izvršenog monitoringa aplikacije moţemo doneti sledeće zakljuĉke o posmatranim
tehnologijama:
1. EJB 2.1 tehnologija zauzima manje dinamiĉke (Heap) memorije, od EJB 3.0
tehnologije. Ovo se moţe objasniti ĉinjenicom da EJB 3.0 generiše dobar deo
interfejsa automatski, dok su ti interfejsi morali ruĉno da se pišu za EJB 2.1.
2. Vreme koje koristi Sakupljaĉ smeća (Garbadge collector – GC) je veće kod EJB 3.0
tehnologije nego kod EJB 2.1. Ovo je povezano sa povećanim zauzećem memorije i
više “rada u pozadini” koji obeleţava EJB 3.0 tehnologiju.
3. Broj aktivnih niti koje se nalaze u razliĉitim stanjima je pribliţno jednak kod obe
tehnologije.
130
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 raĉuna
se vreme izvršenja (vremensko trajanje) svake metode. TakoĊe se raĉuna 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 sluĉaj korišćenja
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 lakšeg uporedjivanja.
Metoda
(Hot spots)
Vreme
(Self time)
Broj poziva
(Invocations)
kontrolerPL.KontrolerPLBean.snimiClana() 0.402 1
sistemskeoperacije.AbstractOperacija.initBeans() 0.127 1
sistemskeoperacije.SnimiClana.snimiClana() 0.049 1
sistemskeoperacije.clan.ClanBean.createClan() 0.054 1
domenskiobjekti.DOClan() 0.010 1
Kao što se moţe videti, svaka metoda se poziva taĉno jednom. Pri tome, najduţe traje
izvršenje metode snimiClana klase KontrolerPLBean. (0.402 ms).
Na sledećoj slici će biti prikazani podaci koji se odnose na EJB 2.1 tehnologiju. Takodje će
biti praćena metoda snimiClana i sluĉaj korišćenja Snimanje novog ĉlana.
131
Slika 35: Prikaz poziva metode snimiClana() kontrolera poslovne logike (EJB 2.1
tehnologija)
Sada ćemo dati tabelaran prikaz snimljenih podataka, radi lakšeg uporedjivanja.
Metoda
(Hot spots) Vreme
(Self time) Broj poziva
(Invocations)
sessionbeans.kontrolerPL.KontrolerPLBean.snimiClana() 0.432 1
sistemskeoperacije.AbstractOperacija.initBeans() 0.148 1
sistemskeoperacije.SnimiClana.snimiClana() 0.051 1
sistemskeoperacije.clan.ClanBean.createClan() 0.057 1
entity.doclan.DOClanBean() 0.019 1
Kao što se moţe videti, svaka metoda se poziva taĉno jednom. Pri tome, najduţe traje
izvršenje metode snimiClana klase KontrolerPLBean. (0.432 ms).
U nastavku dajemo prikaz izvršenja ostalih metoda (Tabela 12.). U redovima je dat prikaz
poziva metoda, dok su u kolonama prikazane tehnologije. Za svaku tehnologiju posmatrani su
sledeći parametri:
1. Vreme izvršenja metode i
2. Broj poziva metode.
132
Metoda
(Hot spots)
EJB 2.1 tehnologija EJB 3.0 tehnologija
Vreme
(Self time) Broj poziva
(Invocations) Vreme
(Self time) Broj poziva
(Invocations)
sessionbeans.kontrolerPL.KontrolerPLBean.brisiKorisnika() 0.209 1 0.249 1
sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 0.413 1
sistemskeoperacije.BrisiKorisnika.brisiKorisnika() 0.117 1 0.117 1
sessionbeans.clan.ClanBean.deleteClan() 0.059 1 0.071 1
sessionbeans.kontrolerPL.KontrolerPLBean.snimiFirmu() 0.201 1 0.256 1
sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 0.413 1
sistemskeoperacije.SnimiFirmu.snimiFirmu() 0.058 1 0.058 1
sessionbeans.firma.FirmaBean.createFirma() 0.060 1 0.067 1
sessionbeans.kontrolerPL.KontrolerPLBean.brisiKorisnika() 0.209 1 0.249 1
sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 0.413 1
sistemskeoperacije.BrisiKorisnika.brisiKorisnika() 0.117 1 0.117 1
sessionbeans.firma.FirmaBean.deleteFirma() 0.064 1 0.056 1
sessionbeans.kontrolerPL.KontrolerPLBean.proveriKorisnika() 0.191 1 0.237 1
sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 0.413 1
sistemskeoperacije.ProveriKorisnika.proveriKorisnika() 0.024 1 0.025 1
sessionbeans.login.LoginBean.proveriKorisnika() 0.188 1 0.191 1
sessionbeans.kontrolerPL.KontrolerPLBean.pretraziClanoveIVratiIh() 0.245 1 0.241 1
sistemskeoperacije.AbstractOperacija.initBeans() 0.377 1 0.413 1
sistemskeoperacije.PretraziClanoveIVratiIh. pretraziClanoveIVratiIh () 0.150 1 0.141 1
sessionbeans.clan.findClanove() 0.111 1 0.107 1
Tabela 12: Prikaz redosleda poziva metoda i rezultata dobijenih analizom metoda
133
Na osnovu podataka iznetih u tabelama moţemo primetiti da vreme izvršavanja metoda u EJB
2.1 sliĉno kao vreme izvršavanja metoda u EJB 3.0. Ipak se kod nekih metoda blago oseća
duţe vreme izvršavanja za EJB 3.0 tehnologiju. Ovo se moţe objasniti ĉinjenicom da EJB 3.0
generiše veliki deo EJB intefejsa, dok su ti interfejsi u EJB 2.1 napisani ruĉno.
Drugim reĉima,deo posla programera je prebaĉen na EJB tehnologiju a cena toga je blago
povećanje vremena izvršenja u nekim sliĉajevima.
6.3. Ocena posmatranih tehnologija
Na osnovu uradjene statiĉke i dinamiĉke analze sada moţemo dati sumarni zakljuĉak o
posmatranim tehnologijama.
Što se tiĉe statiĉke analize, korišćenjem obe tehnologije se dobijaju aplikacije koje se lako
odrţavaju i koje nisu sloţene. Pri tome EJB 3.0 prednjaĉi po smanjenju sloţenosti 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 moţemo reći da je
korišćenje EJB 3.0 tehnologije znatno lakse, zahteva pisanje manje koda, a daje iste ili bolje
rezultate.
Kada posmatramo dinamiĉku analizu, EJB 2.1 tehnologija zauzima manje dinamiĉke (Heap)
memorije, od EJB 3.0 tehnologije. Ovo se moţe objasniti ĉinjenicom da EJB 3.0 generiše
dobar deo interfejsa automatski, dok su ti interfejsi morali ruĉno da se pišu za EJB 2.1. Vreme
koje koristi Sakupljaĉ smeća (Garbadge collector – GC) je veće kod EJB 3.0 tehnologije nego
kod EJB 2.1. Ovo je povezano sa povećanim zauzećem memorije i više “rada u pozadini” koji
obeleţava EJB 3.0 tehnologiju.
Takodje, moţemo primetiti da vreme izvršavanja metoda u EJB 2.1 sliĉno kao vreme
izvršavanja metoda u EJB 3.0. Ipak se kod nekih metoda blago oseća duţe vreme izvršavanja
za EJB 3.0 tehnologiju. Ovo se moţe objasniti ĉinjenicom da EJB 3.0 generiše veliki deo EJB
intefejsa, dok su ti interfejsi u EJB 2.1 napisani ruĉno.
Konaĉan zakljuĉak koji se nameće je da korišćenje EJB 3.0 tehnologije daje proizvod koji ima
manju sloţenost, manji broj klasa i lakše odrţavanje nego EJB 2.1. Sa druge strane EJB 3.0 je
za nijansu više tehniĉki zahtevnija, jer zauzma malo više memorije i ponegde duţe vreme
izvršavanja.
Ovakav zakljuĉak je i „intuitivno jasan“ jer predstavlja napredak tehnologije i prebacivanje
posla sa ĉoveka na mašinu, tj sa programera na tehnologiju, uz blago povećanje hardverske
zahtevnosti tehnologije.
134
6.4. Sažetak
U ovom poglavlju je data komparativna analiza projekta uradjenog u EJB 2.1 i EJB 3.0
tehnologiji. Ona obuhvata statiĉku analizu korišćenjem softverskog alata Swat4, i dinamiĉku
analizu korišćenjem softverskog alata NetBeans Profiler. Na osnovu izvršene analize softvera
doneli smo zakljuĉke koji su izneti u poglavlju 6.3.
Na taj način smo realizovali četvrti cilj istraživanja (Izvršiti komparativnu analizu Spring
i EJB tehnologije).
135
7. ZAKLJUČAK
U master radu su prikazani osnovni koncepti EJB 2.1 i EJB 3.0 tehnologije. EJB tehnologija
omogućavaju razvoj sloţenih (enterprise) aplikacija. Na osnovu definisanog predmeta
istraţivanja, na poĉetku istraţivanja postavljeni su sledeći ciljevi istraţivanja:
1. Dati pregled EJB 2.1 tehnologije;
2. Dati pregled EJB 3.0 tehnologije;
3. Dati pregled ISO/IEC 9126 standarda;
4. Izvršiti komparativnu analizu EJB 2.1 i EJB 3.0 tehnologije. U okviru ovog cilja
definisani su sledeći podciljevi:
Izvršiti statiĉku analizu tehnologija korišćenjem softverskih metrika;
Izvršiti dinamiĉku analizu tehnologija korišćenjem 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 objašnjeni 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
naglašene su razlike koje postoje izmedju EJB 2.1 i EJB 3.0. Akcenat je stavljen na
perzistentnost i korišćenje anotacija u EJB 3.0 tehnologiji.
Tokom rada smo utvrdili da EJB tehnologija ima sledeće karakteristike:
EJB tehnologija predstavlja de facto standard prilikom razvoja sloţenih aplikacija;
EJB koristi dobre osobine aplikacionog servera (deklarativno upraljvanje
transakcijama, security...);
Korišćenje Entity klasa EJB 3.0 tehnologije sada je moguće van aplikacionog servera;
EJB 3.0 tehnologija preuzima dobre osobine drugih tehnologija;
EJB tehnologija je u novoj verziji EJB 3.0 znaĉajno pojednostavljena i unapreĊena;
Iz dosadašnjeg istraţivanja zakljuĉili smo da je EJB 3.0 u znatnoj meri pojednostavio razvoj
velikih aplikacija.
Iz dosadašnjeg istraţivanja smo zakljuĉili je EJB 3.0 tehnologija preuzela mnoge
dobre osobine postojećih tehnologija. Tako su iskorišćene dobre karakteristike Spring okvira
(na primer, dodata je podrška za koncept IoC) i Hibernate okvira (dodate su anotacije,
podrška za presikavanje klasa u POJO entitete za jednostavno obezbedjivanje
perzistentnosti)... Na ovaj naĉin je tehnologija znatno poboljšana i pojednostavljena. Mnoge
stvari su automatizovane i kontejner ih izvršava u pozadini (bez eksplicitnog poziva
korisnika). TakoĊe, u novoj specifikaciji omogućeno je korišćenje Entity klasa EJB
tehnologije van aplikacionog servera (na taj naĉin se Entity klase EJB tehnologije mogu
koristiti kao i drugi ORM alati). TakoĊe, postoji i više 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 definiše kvalitet softverskog sistema. Ovaj standard se sastoji iz ĉetiri dela:
ISO/IEC 9126-1 kojim se definiše model kvaliteta softvera (Quality model),
ISO/IEC 9126-2 kojim se definišu eksterne metrike (External metrics),
ISO/IEC 9126-3 kojim se definišu interne metrike (Internal metrics),
136
ISO/IEC 9126-4 kojim se definiše kvalitet u korišćenju metrika (Quality in use
metrics).
Zatim je korišćenjem matematiĉkih 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
korišćenjem EJB 2.1 tehnologije, i druga korišćenjem EJB 3.0 tehnologije. Ove aplikacije su
predstavljale osnovu za izvršavanje statiĉke analize softvera (korišćene su softverske metrike
koje zadovoljavaju ISO/IEC 9126 standard) kao i dinamiĉke analize softvera (korišćen je
profajler koji se moţe koristiti za optimizovanje aplikacija). Kada je u pitanju statiĉka analiza
softvera, na osnovu definisanog modela kvaliteta softvera dobijeni su sledeći rezultati:
Testiranje Kvalitet
projektovanja
Performanse Razumljivost Odrţavanje Ponovno
korišćenje
EJB 2.1 10.0 10.0 10.0 10.0 10.0 10.0
EJB 3.0 10.0 4.8 10.0 10.0 10.0 3.14
Na osnovu dobijenih vrednosti atributa u modelu kvaliteta softvera moţemo reći da je
aplikacija koja je razvijena korišćenjem EJB 2.1 tehnologije bolje projektovana i ima bolje
ponovno korišćenje u odnosu na aplikaciju koja je razvijena korišćenjem EJB 3.0 tehnologije.
Medjutim, treba naglasiti da Swat4j nije savrsen alat za statiĉku alanizu i da on nije uzeo u
obzir anotacije koje se koriste u EJB 3.0 tehnologiji. To je u dobroj meri uticalo na loše ocene
nekih parametara.
Ipak, kada se radi analiza pojedniĉnih metrika dobili smo sledeće zakljuĉke:
1. Primenom EJB 3.0 tehnologije se dobijaju metode koje su prostije od metoda koje su
dobijene korišćenjem 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 proseĉan nedostatak kohezije od
metoda EJB 3.0. Ovo moţe biti posledica toga što EJB 3.0 ne zahteva da se pisu EJB
interfejsi, pa stoga se oseća 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 korišćenjem dobijaju klase koje nisu
sloţene.
7. Korišćenjem ovih tehnologija dobijaju se aplikacije koje se lako odrţavaju.
Nakon statiĉke analize softverskog sistema izvršena je dinamiĉka analiza softverskog
sistema korišćenjem profajlera. U tom kontekstu izvršen je monitoring aplikacije, kao i
analiza performansi delova aplikacije. Na osnovu izvršenog monitoringa aplikacije doneli
smo sledeće zakljuĉke o posmatranim tehnologijama:
1. EJB 2.1 tehnologija zauzima manje dinamiĉke (Heap) memorije, od EJB 3.0
tehnologije. Ovo se moţe objasniti ĉinjenicom da EJB 3.0 generiše dobar deo
interfejsa automatski, dok su ti interfejsi morali ruĉno da se pišu za EJB 2.1.
2. Vreme koje koristi Sakupljaĉ smeća (Garbadge collector – GC) je veće kod EJB 3.0
tehnologije nego kod EJB 2.1. Ovo je povezano sa povećanim zauzećem memorije i
više “rada u pozadini” koji obeleţava EJB 3.0 tehnologiju.
137
3. Broj aktivnih niti koje se nalaze u razliĉitim stanjima je pribliţno jednak kod obe
tehnologije.
Na osnovu izvršene analize performansi delova aplikacije doneli smo sledeće zakljuĉke:
Na osnovu podataka iznetih u tabelama moţemo primetiti da vreme izvršavanja
metoda u EJB 2.1 sliĉno kao vreme izvršavanja metoda u EJB 3.0. Ipak se kod nekih metoda
blago oseća duţe vreme izvršavanja za EJB 3.0 tehnologiju. Ovo se moţe objasniti
ĉinjenicom da EJB 3.0 generiše veliki deo EJB intefejsa, dok su ti interfejsi u EJB 2.1
napisani ruĉno.
Eventualni dalji pravci istraţivanja odnosili bi se na detaljnije prouĉavanje savremenih
softverskih arihitektura i metoda razvoja softvera, softverskih uzora, softverskih metrika i
profajlera, kao i na definisanje kompletnog okvira kojim bi se mogla izvršiti evaluacija
performansi odreĊene tehnologije.
Imajući sve to u vidu, oĉekuje se da će u narednom periodu doći do znaĉajnih
kvalitativnih i kvantitativnih poboljšanja 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 sadrţi neke biblioteke koje nisu vlasništvo
firme Sun Microsystems i nemaju licencu otvorenog koda.
138
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. [DrVlajić1] Dr Siniša Vlajić: Projektovanje programa (Skripta), FON, Beograd 2004.
5. [DrVlajić2] Dr Siniša Vlajić, prof. dr Vidojko Ćirić, Dušan Savić: Projektovanje
programa (Praktikum – programski jezik Java), FON, Beograd, 2003.
6. [DrVlajić3] Dr Siniša 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 zapošljavanje u J2EE
okruženju, FON, Beograd, 2007
25. [ZWSwat4j] Zvaniĉna web prezentacija softverskog paketa Swat4j: http://www.codeswat.com/cswat/index.php?option=com_content&task=view&id=12&Itemid=27
139
26. [ZWAnalyst4j] Zvaniĉna web prezentacija softverskog paketa Analyst4j: http://www.codeswat.com/cswat/index.php?option=com_content&task=view&id=43&Itemid=63
27. [ZWEclipse] Zvaniĉna web prezentacija Eclipse Test & Performance Tools Platform
Project:
http://www.eclipse.org/tptp/
28. [ZWNetBeans] Zvaniĉna web prezentacija The NetBeans Profiler Project:
http://profiler.netbeans.org/
29. [ZWJBoss] Zvaniĉna web prezentacija JBOSS aplikativnog servera:
http://www.jboss.org/
