Goran Pavlovic Razvoj Web Aplikacije Za Pracenje Softverskih Gresaka Koriscenjem Spring i Hibernate Tehnologija

Univerzitet u Beogradu

Fakultet organizacionih nauka

DIPLOMSKI RAD Razvoj Web aplikacije za praćenje softverskih grešaka korišćenjem

Spring i Hibernate tehnologija

Kandidat: Pavlović Goran

Mentor: Dr Siniša Vlajić, doc.

April 2009. godine

Diplomski rad – Razvoj Web aplikacije korišćenjem Spring i Hibernate tehnologija

2

SADRŽAJ

SADRŽAJ .................................................................................................................................................................................2

1. UVOD...................................................................................................................................................................................6

2. SPRING OKVIR ...............................................................................................................................................................7

2.1. Razvoj Java tehnologije ....................................................................................................................................7

2.2. Java Platforma......................................................................................................................................................8

2.2.1. Java 2 Platform, Stadnard Edition (J2SE) .....................................................................................8

2.2.2. Java 2 Platfrom, Enterprise Edition (J2EE) ..................................................................................9

2.2.3. Java 2 Platform, Micro Edition (J2ME) ........................................................................................ 10

2.3. Arhitektura Spring okvira ............................................................................................................................ 11

2.4. IoC (Inversion Of Control) ............................................................................................................................. 12

2.4.1. Dependency Injection ........................................................................................................................... 13

2.4.1.1. Setter Injection ............................................................................................................................... 13

2.4.1.2. Constructor Injection .................................................................................................................. 13

2.4.1.3. Method Injection ........................................................................................................................... 14

2.5. Spring kontejner ............................................................................................................................................... 14

2.5.1. Interfejsi BeanFactory i ApplicationContext ............................................................................. 14

2.5.2. Konfigurisanje i pokretanje kontejnera ..................................................................................... 16

2.6. Rad sa JavaBean komponentama ............................................................................................................. 20

2.6.1. Definisanje bean-ova ............................................................................................................................. 20

2.6.2. Kreiranje bean-ova ................................................................................................................................. 21

2.6.3. Definisanje zavisnosti između bean-ova ..................................................................................... 23

2.6.4. Definisanje opsega bean-a .................................................................................................................. 24

2.7. Spring MVC okvir .............................................................................................................................................. 26

2.7.1. Struktura Web aplikacije ..................................................................................................................... 26

2.7.2. Java Servleti i JSP (JavaServer Pages)............................................................................................ 27

2.7.2. MVC uzor ...................................................................................................................................................... 29

2.7.3. Koncepti Spring Web MVC okvira.................................................................................................... 31

2.7.3.1. Klasa DispatcherServlet ................................................................................................. 31

2.7.3.2. Preslikavanje zahteva (request) ka kontrolerima ......................................................... 34

2.7.3.3. Kontoler (Controller) .................................................................................................................... 37

2.7.3.4. Klasa ModelAndView ................................................................................................................ 38

2.7.3.5. Pogled (View) i bean-ovi za preslikavanje pogleda (ViewResolver) ..................... 39


3

2.7.3.6. Korišćenje formi ............................................................................................................................. 41

2.7.3.7. Validacija podataka ....................................................................................................................... 43

2.7.3.8. Internacionalizacija (i18n) ........................................................................................................ 44

2.7.3.9. Ilustrativni primer ......................................................................................................................... 45

3. HIBERNATE OKVIR .................................................................................................................................................. 59

3.1. Osobine objektnog i relacionog modela ............................................................................................... 60

3.2. Problem transformacije između modela.............................................................................................. 61

3.2.1. Koncept nasleđivanja ........................................................................................................................... 62

3.2.2. Koncept identiteta ................................................................................................................................. 62

3.2.3. Asocijacije .................................................................................................................................................. 63

3.2.4. Struktura i ponašanje ........................................................................................................................... 63

3.3. JDBC ......................................................................................................................................................................... 64

3.4. ORM alati - klasifikacija ................................................................................................................................. 65

3.5. Arhitektura Hibernate okvira .................................................................................................................... 67

3.6. Konfigurisanje okvira ..................................................................................................................................... 68

3.6.1. Konfiguracioni podaci .......................................................................................................................... 69

3.6.2. Pokretanje okvira ................................................................................................................................... 71

3.7. Rad sa objektima – materijalizacija i dematerijalizacija .............................................................. 71

3.7.1. Stanja objekata ........................................................................................................................................ 71

3.7.2. Realizacija CRUD operacija ............................................................................................................... 72

3.7.2.1. Operacija snimanja (Create) .................................................................................................... 72

3.7.2.2. Operacija čitanja (Read) ............................................................................................................ 74

3.7.2.3. Operacija ažuriranja (Update) ................................................................................................ 76

3.7.2.4. Operacija brisanja (Delete)....................................................................................................... 76

3.7.3. Proxy uzor .................................................................................................................................................. 77

3.7.4. Kasna matrijalizacija (Lazy loading) ............................................................................................ 78

3.7.5. Keširanje ..................................................................................................................................................... 79

3.7.6. HQL – Hibernate Query Language .................................................................................................. 80

3.8. Kreiranje ORM modela .................................................................................................................................. 82

3.8.1. Pristupi u kreiranju ORM modela .................................................................................................. 82

3.8.2. Datoteke za definisanje preslikavanja......................................................................................... 83

3.8.3. Primeri preslikavnja ............................................................................................................................. 85

4. INTEGRACIJA SPRING I HIBERNATE OKVIRA ........................................................................................... 90

4.1. Perzistentnost u Spring okviru ................................................................................................................ 90


4

4.2. Konfigurisanje Hibernate resursa .......................................................................................................... 91

4.2.1. Konfigurisanje SessionFactory bean-a ........................................................................................ 91

4.2.2. Klasa HibernateTemplate .................................................................................................................. 94

4.2.3. Klasa HibernateDaoSupport ............................................................................................................. 95

4.3. Upravljanje transakcijama........................................................................................................................... 97

4.3.1. Definicija i osobine transakcije ........................................................................................................ 97

4.3.2. Transakcije u Spring okviru ............................................................................................................... 97

4.3.3. Atributi transakcija ................................................................................................................................ 99

4.3.3.1. Propagaciono ponašanje ............................................................................................................ 99

4.3.3.2. Nivo izolovanosti ......................................................................................................................... 100

4.3.3.3. Timeout i Read-only atributi .................................................................................................. 101

4.3.4. Deklarativno upravljanje transakcijama .................................................................................. 101

5. STUDIJSKI PRIMER – Razvoj aplikacije korišćenjem Larmanove metode ............................... 103

5.1. Korisnički zahtev – verbalni model ..................................................................................................... 103

5.2. Opis korisničkog zahteva pomoću slučajeva korišćenja(SK) ................................................. 103

5.2.1. Slučajevi korišćenja ............................................................................................................................. 103

5.2.2. Opis slučajeva korišćenja ................................................................................................................. 104

5.3. Analiza ................................................................................................................................................................ 112

5.3.1. Ponašanje sistema................................................................................................................................ 112

5.3.1.1. Sistemski dijagrami sekvenci(DS) ...................................................................................... 113

5.3.1.2. Definisanje ugovora o sistemskim operacijama.......................................................... 127

5.3.2. Struktura sistema ................................................................................................................................ 130

5.3.2.1. Konceptualni (domenski) model......................................................................................... 130

5.3.2.2. Relacioni model ............................................................................................................................ 131

5.4. Projektovanje .................................................................................................................................................. 131

5.4.1. Arhitektura softverskog sistema .................................................................................................. 131

5.4.2. Projektovanje aplikacione logike – kontroler ....................................................................... 132

5.4.3. Projektovanje strukture sotverskog sistema – Domenske klase................................. 133

5.4.4. Projektovanje ponašanja sotverskog sistema – Sistemske operacije ....................... 134

5.4.5. Projektovanje logike za pristup podacima .............................................................................. 140

5.4.5.1. Projektovanje DAO klasa ......................................................................................................... 141

5.4.6. Projektovanje skladište podataka ............................................................................................... 142

5.4.7. Preslikavanja između klasa domenskog modela i skladišta podataka ..................... 144

5.4.8. Projektovanje korisničkog interfejsa ......................................................................................... 146


5

5.4.8.1. Projektovanje scenarija SK koji se izvode preko ekranske forme ..................... 146

5.4.8.2. Projektovanje kontrolera korisničkog interfejsa ........................................................ 178

5.4.9. Finalna arhitektura softverskog sistema ................................................................................. 194

5.5. Implementacija ............................................................................................................................................... 195

6. ZAKLJUČAK............................................................................................................................................................... 196

7. LITERATURA ........................................................................................................................................................... 197


6

1. UVOD

U nekim budućim udžbenicima istorije, prethodni vek će, bez sumnje, biti opisan kao vek munjevitog tehnološkog razvoja. Pojava i razvoj računara i razvoj informacionih tehnologija sigurno su u najvećoj meri potpomogle, ne samo sveopšti tehnološki razvoj, već i razvoj u svim oblastima čovekovog delovanja. Veliki broj stvari, gotovo nezamislivih pre samo pedesetak, možda i manje godina, postale su deo naše svakodnevice.

Može slobodno da se kaže da je pojava Interneta dovela do revolucije u mnogim sferama ljudskog delovanja, međutim, verovatno najveći uticaj Internet je imao u oblasti razvoja globalnog poslovnog okruženja. Informacije, njihova dostupnost i brzina razmene predstavljaju osnovu uspešnog poslovanja savremenih preduzeća, a Internet u tom kontekstu predstavlja savršeno sredstvo za pronalaženje i distribuciju informacija. Složene, distribuirane Web aplikacije postale su neophodne za opstanak i razvoj savremenih preduzeća u uslovima globalnog, međunarodnog tržišta.

U okviru ovog rada biće prikazan razvoj Web aplikacije korišćenjem Java tehnologija. U prvom delu rada kratko je prikazan razvoj Java tehnologije, dok je centralni deo poglavlja posvećen prikazu Spring okvira, sa posebnim naglaskom na konceptima Spring MVC modula koji je korišćen za razvoj Web aplikacije dokumentovane u studijskom primeru.

Drugi deo rada obrađuje problem perzistencije podataka. Budući da su relacione baze podataka postale svojevrsni standard u domenu perzistencije podataka, kao i objektno orjentisan pristup u razvoju aplikacija, uvodni deo poglavlja bavi se karakteristikama objektnog i relacionog modela, kao i problematikom transformacije između dva modela. Centralni deo poglavlja posvećen je problematici objektno-relacionog preslikavanja i perzistenciji podataka korišćenjem Hibernate ORM (Object-Relational Mapping) alata.

U poslednjem poglavlju dat je studijski primer koji je razvijen korišćenjem Spring i Hibernate tehnologija, predstavljenih u prva dva poglavlja rada. U razvoju aplikacije iz studijskog primera primenjena je Larmanova metoda razvoja softvera.


7

2. SPRING OKVIR

U uvodnom delu ovog poglavlja dat je kratak prikaz razvoja Java tehnologije, kao i prikaz osnovnih karakteristika Java platforme, odnosno izdanja koja ona uključuje. U centralnom delu poglavlja prikazana je arhitektura Spring okvira, kao i način konfigurisanja i pokretanja okvira u različitim aplikacionim okruženjima. U skladu sa temom ovog rada, najvećim delom je posvećena pažnja osobinama i rešenjima koja Spring okvir nudi u kontekstu razvoja Web aplikacija.

2.1. RAZVOJ JAVA TEHNOLOGIJE

U jednoj od prvih definicija firme “Sun” Java se opisuje na sledeći način[1]:

Java je: jednostavan, objektno orjentisan, distribuiran, interpretiran, robustan, siguran, arhitektronski neutralan, prenosiv, visoko performantan, višenitni i dinamički programski jezik.

U nastavku je dat kratak prikaz razvoja Java programske tehnologije od njenog nastanka do danas. Java tehnologija je kreirana 1991. godine kao programski alat u maloj, tajnoj akciji “The Green Project” u firmi Sun Microsystems. Ovaj tajni tim pod nazivom “Green Team”, sačinjen od 13 ljudi, počeo je sa radom sredinom maja 1991. Rezultat njihovog osamnaestomesečnog rada bio je programski jezik nezavisan od uređaja na kome se izvršava, nazvan “Oak”.

Njihov prevashodni cilj nije bio kreiranje novog programskog jezika, već predviđanje novih tendencija u kompjuterskoj tehnologiji. Njihova razmatranja su ih dovela do zaključka da je jedini siguran trend konvergencija digitalnih korisničkih uređaja i računara.

Da bi demonstrirali koliko je moćan njihov novi jezik, Green Team razvija interaktivni kućni kontroler uređaj vezan za digitalnu kablovsku televiziju. Nažalost, ideja je bila ispred svog vremena i u neskladu sa tehnološkim razvojem tadašnje industrije kablovske televizije. Ali tu se našao Internet koji je mogao prihvatiti ove napredne ideje. Javno prestavljanje svetu počinje 1995. godine ugrađivanjem Jave u Internet pretraživač Netscape Navigator[2] .

Posle petnaest godina razvoja Java tehnologije Java se proširila na više milijardi uređaja prvenstveno zahvaljujući osobinama prenosivosti i sigurnosti. Ti uređaji su:

o Preko 800 miliona PC računara o Preko 1,5 milijardi mobilnih telefona i drugih prenosivih uređaja o 2,2 milijarde pametnih (smart) kartica o štampači, web igrice, sistemi za navigaciju automobila, terminali lutrije, o medicinski uređaji, sistemi za naplatu parkinga i drugi.


8

2.2. JAVA PLATFORMA

Java je softverska tehnologija koja je ujedno i platforma i objektno – orjentisani programski jezik. [3]

Java platforma uključuje tri različita izdanja, pri čemu je svako izdanje namenjeno za razvoj različitih aplikacija i obezbeđuje drugačije izvršno okruženje.

Java platfroma uključuje:

1. Java 2 Platform, Standard Edition ( J2SE) 2. Java 2 Platform, Enterprise Edition ( J2EE) 3. Java 2 Platform, Micro Edition ( J2ME)

2.2.1. Java 2 Platform, Stadnard Edition (J2SE)

Java 2 Platform, Stadnard Edition (J2SE) je razvojno okruženje koje obezbeđuje Java API 1 (Application Programming Interface) i alate za kreiranje, testiranje i izvršavanje Java programa. J2SE se sastoji iz dva osnovna proizvoda [3]:

1. Java SE Runtime Environment (JRE) i 2. Java SE Development Kit (JDK)

JRE predstavalja osnovu Java tehnologija, sastoji se od Java Virtuelne Mašine (Java Virtual Machine - JVM), J2SE API-ja i skupa tehnologija raspoređivanja kao što su npr. Java Web Start2 i Java Plug-in3 koje podržavaju izvršenje Java programa.

JDK predstavlja proširenje JRE-a, jer pored JRE-a sadrži i alate za razvoj i testiranje aplikacija. Pored ovih alata, uz JDK se isporučuje dokumentacija, izvorni (source) kod, kao i praktični primeri.

1 API – Application Programming Interface – skup klasa koje biblioteka ili servis pruža radi ispunjenja zahteva upućenih od strane aplikacije.[3] 2 Java WebStart omogućava preuzimanje i pokretanje Java aplikacija koje se nalaze na mreži (web). 3 Java Plug-in – mehanizam koji omogućava da se Java aplikacije (apleti) mogu izvršiti u okruženju Web čitača (Internet Explorer, Mozilla Firefox...)


9

2.2.2. Java 2 Platfrom, Enterprise Edition (J2EE)

Java 2 Platfrom, Enterprise Edition (J2EE) platforma može da se podeli u tri grupe tehnologija [3]:

1. Java Web tehnologije koje se koriste za razvoj prezenatacionog sloja Web i J2EE aplikacija. U ove tehnologije spadaju:

- Java Servlet - JavaServer Pages (JSP) - JavaServer Pages Standard Tag Library (JSTL) - Java Server Faces (JSF) - Internacionalizacija i lokalizacija Web aplikacija

2. Enterprise JavaBeans (EJB) tehnologije, koje se koriste za razvoj poslovne logike aplikacija. U ove tehnologije spadaju:

- Session Beans - Entity Beans - Message-Driven Beans

3. Java XML tehnologije koje se koriste prilikom implementacije Web servisa. U ove tehnologije spadaju:

- The Java API for XML Processing (JAXP) - The Java API for XML based RCP (JAX-RCP) - SOAP with Attachments API for JAVA (SAAJ) - The Java API for XML Registries (JAXR)

J2EE platforma podržava[3]:

o Višenivojski distribuirani aplikacioni model; o Komponente koje se mogu ponovo koristiti; o Jedinstveni model zaštite; o Fleksibilnu transakcionu kontrolu; o Web servise koji su zasnovani na XML standardnima i protokolima.

J2EE platforma koristi distribuirani više-nivojski model (obično tronivojski model) za razvoj J2EE složenih (enterprise) aplikacija. J2EE aplikacija sastoji se od J2EE komponenti koje su instalirane na različitim računarima. Komponente, odnosno računari na kojima se izvršavaju komponente su dodeljene različitim nivoima J2EE aplikacije (Slika 1) [4]:

1. Klijentski nivo – komponente koje se izvršavaju na klijentskim računarima 2. Nivo aplikacione logike – komponente koje se izvršavaju na J2EE serveru. Ovaj nivo je

podeljen na dva podnivoa:

Web nivo

Poslovni nivo


10

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

Slika 1: Model tronivojske aplikacije

J2EE aplikacija može da bude realizovana kao Web aplikacija, ili kao EJB aplikacija. Web aplikacija predstavlja aplikaciju koja se izvršava u okruženju Web servera.

Postoje dva tipa Web aplikacija[4]:

o Prezentaciono orjentisana –ove aplikacije generišu Web strane na osnovu zahteva koji im postavlja klijent. Web strana može biti realizovana preko HTML-a, XML-a, ili nekog drugog jezika za označavanje (markup language).

o Servisno-orjentisana – ove aplikacije koriste Web servise da realizuju zahteve koje im postavlja klijent, ili prezentaciono-orjentisana aplikacija.

2.2.3. Java 2 Platform, Micro Edition (J2ME)

Java 2 Platform, Micro Edition (J2ME) je razvojno okruženje koje obezbeđuje API i oruđa za razvoj, testiranje i izvršavanje aplikacija koje se koriste za uređaje poput mobilnih telefona, PDA uređaja.


11

2.3. ARHITEKTURA SPRING OKVIRA

Jedna od najbitnijih karakteristika Spring okvira jeste njegova modularnost, koja omogućava da se prilikom projektovanja aplikacije ne koristi celokupan okvir, već samo oni moduli koji su potrebni u specifičnoj situaciji. Modularan pristup omogućava da se uz pomoć Spring okvira razviju Java aplikacije različitog nivoa složenosti - veoma složene (Enterprise) aplikacije, ali, i dosta jednostavnije aplikacije, na nivou Java apleta. Dakle, u zavisnosi od zahteva aplikacije, moguće je koristiti bilo koji Spring modul nezavisno od drugih modula. Na primer, može da se koristi samo Spring-ov osnovni (core) kontejner za upravljanje slojem poslovne logike aplikacije, dok se drugi delovi aplikacije mogu realizovati korišćenjem neke druge tehnologije. Dakle, pored modularnosti, Spring omogućava i integraciju sa velikim brojem tehnologija.

Arhitektura Spring okvira data je je na sledećoj slici (Slika 2). Na samoj slici uočava se da se Spring okvir sastoji od sledećih šest modula [5]:

Core (Osnovni, jezgro); AOP (Aspect Oriented Programming); DAO (Data Acces Objects); ORM (Object Relational Mapping); JEE (Java Enterprise Edition); Web.

Slika 2 : Moduli Spring okvira [5]


12

Core modul je centralni modul Spring okvira. U okviru Core modula realizovan je Inversion of Control (IoC), odnosno Dependency Injection (DI) mehanizam. Realizacija DI mehanizma u Core modulu ostvaruje se preko interfejsa BeanFactory, tj. preko implementacija ovog interfejsa.

AOP modul obezbeđuje podršku za aspektno orjentisano programiranje koje omogućava da se na jednostavan način razdvoje komponente sistema, implementirajući funkcionalnosti koje su logički odvojene.

DAO modul obezbeđuje JDBC (Java Database Connectivity) sloj koji uklanja potrebu za klasičnim pristupanjem bazama podataka korišćenjem JDBC upravljačkih programa. Naime, korišćenje JDBC-a podrazumeva pisanje kôda za pribavljanje konekcije, formiranje naredbi (statement), obradu rezultata i zatvaranje konekcije, dok se korišćenjem Spring JDBC okvira celokupan posao apstrahuje i pojednostavljuje. DAO modul omogućava i vrlo efikasnu obradu izuzetaka koji mogu da nastanu prilikom rada sa bazama podataka. Pored gored navedenog, DAO modul obezbeđuje i mehanizme za programsko, kao i deklarativno upravljanje transakcijama.

ORM modul obezbeđuje sloj za integraciju Spring okvira sa popularnim ORM alatima. Pored Hibernate okvira, čija je integracija sa Spring okvirom i predmet ovog rada, Spring pruža mogućnost integracije sa sledećim ORM alatima: iBatis SQL Maps, JDO, Apache OJB, Oracle TopLink. ORM modul, pored integracije sa navedenim ORM alatima, pruža i mogućnost korišćenja deklarativnog upravljanja transakcijama.

JEE modul omogućava integraciju Spring okvira i EJB (Enterprise Java Bean) komponenti, zatim integraciju sa JMS (Java Message Service) komponentama, što omogućava asinhrono kreiranje, slanje i primanje poruka.

Web modul sadrži kompletnu implementaciju MVC4 okvira koji se koristi za razvoj Web aplikacija. Spring Web MVC implementacija obezbeđuje potpuno razdvajanje poslovne logike aplikacije od njenog prezentacionog sloja, omogućavajući uz to i korišćenje svih IoC osobina okvira prilikom razvoja Web aplikacije. Pored sopstvene implementacije MVC okvira, Spring okvir nudi mogućnost integracije sa drugim MVC okvirima. Kao što se na slici 1 vidi, Web modul omogućava integraciju sa JSF, WebWork, Tapestry i Apache Struts okvirima.

2.4. IOC (Inversion Of Control)

IoC predstavlja generalni princip koji omogućava otklanjanje zavisnosti komponenti na nivou implementacije. IoC je poznat pod nazivom „Holivudski princip - Ne zovite Vi mene, ja ću pozvati Vas“5.

IoC princip predstavlja zajedničku karakteristiku, odnosno, predstavlja suštinu svih, takozvanih, „laganih“ (lightweight) kontejnera. Činjenica da se svi „lagani“ kontejneri zasnivaju na IoC principu daje kontejnerima jednu jako bitnu osobinu – kontejneri sa poslovnim objektima rade na nenametljiv (non-invasive) način. To praktično znači da aplikacioni kôd, odnosno, kôd poslovnih objekata aplikacije kojom upravlja IoC kontejner ne zavisi od samog kontejnera, budući da nije

4 MVC - Model-View-Controller 5 Hollywood Principle - Don't call me, I'll call you


13

neopohodno da poslovne klase naslede neku klasu, ili implementiraju neki interfejs specifičan za kontejner. Na taj način minimizira se zavisnost između aplikacije i kontejnera.

2.4.1. Dependency Injection

Spring IoC kontejner zasniva se na Dependency Injection (DI) mehanizmu. Sam naziv6 dosta govori o odnosu između aplikacije i kontejnera, kao i načinu na koji se razrešavaju zavisnosti između komponenti aplikacije. Aplikacija može da se posmatra kroz skup komponenti koje na određeni način sarađuju, zavise jedna od druge u toku izvršenja aplikacije. Kod Java aplikacija, ove komponente su pojavljivanja Java klasa, odnosno objekti. Poslovni objekti aplikacije kojom upravlja Spring IoC kontejner nisu zaduženi za pribavljanje resursa i kreiranje drugih objekata sa kojima sarađuju i od kojih zavise. Umesto njih, kreiranje i konfigurisanje njihovih zavisnosti vrši kontejner, što omogućava da se prilikom projektovanja poslovnih klasa pažnja fokusira na poslovnu logiku koju metode klase treba da izvrše.

Postoje tri osnovne varijante DI mehanizma koje su podržava Spring kontejner:

Setter Injection Constructor Injection Method Injection

2.4.1.1. Setter Injection

Setter Injection najpopularniji i najčešće korišćen tip DI mehanizma. Klase koje je potrebno povezati su najčešće JavaBeans7 klase sa konstruktorom bez parametara. Kontejner nakon kreiranja bean-ova koristi metode za postavljanje vrednosti atributa klase (setter metode), kako bi povezao dati bean sa drugim bean-ovima.

2.4.1.2. Constructor Injection

Kada se koristi Constructor Injection mehanizam, neophodno je da klase koje kontejner kreira sadrže konstruktor metodu sa određenim brojem parametara. Prilikom kreiranja bean-a, kontejner poziva određeni konstruktor klase na osnovu broja i tipa parametara konstruktora. Ovakva forma DI mehanizma garantuje validno stanje svih kreiranih bean-ova, međutim, kao glavni

6 Dependency Injection – Slobodnim prevodom može da se prevede kao ubrizgavanje zavisnosti 7 Bean je softverska komponenta, sa mogućnošću ponovnog korišćenja, kojom se može vizuelano manipulisati u odgovarajućem alatu. Konvencijom je definisano da svaka bean klasa mora da poseduje podrazumevani konstruktor (neparametarski), kao i odgovarajuće metode za postavljanje i preuzimanje vrednosti atributa klase (set i get metode).


14

nedostatak može da se navede problem upravljanja koji nastaje zbog većeg broja parametara konstruktora, kao i većeg broja samih preklopljenih8 konstruktora.

2.4.1.3. Method Injection

Pored Constructor i Setter Injection mehanizama, Spring podržava i Method Injection mehanizam. Prilikom korišćenja ove forme kontejner je zadužen da u vreme izvršavanja aplikacije implementira metode. Na primer, objekat može da sadrži metodu koja je deklarisana kao protected abstract metoda, pri čemu će kontejner u vreme izvršenja da je realizuje. Ova DI forma se najređe koristi.

2.5. SPRING KONTEJNER

DI mehnizam predstavlja suštinu Spring okvira, a sama implementacija ovog mehanizma realizovana je kroz dva interfejsa koji su srž Spring IoC kontejnera.

org.springframework.beans.factory.BeanFactory

org.springframework.context.ApplicationContext

2.5.1. Interfejsi BeanFactory i ApplicationContext

BeanFactory je osnovni interfejs Spring kontejnera koji omogućava konfigurisanje i

povezivanje bean-ova koristeći DI mehanizme. Kada se interfejs BeanFactory kreira, Spring okvir

vrši validaciju konfiguracije bean-ova. Svaki singleton bean9 se kreira prilikom pokretanja okvira, dok se ostali bean-ovi kreiraju na zahtev korisnika. Pored toga, interfejs BeanFactory obezbeđuje i

neke mehanizme za upravljanje životnim ciklusom bean-ova, pri čemu se to odnosi samo na singleton bena-ove, jer kod prototype10 bean-ova kontejner nakon kreiranja bean-a gubi kontrolu nad njim. U nastavku je prikazan BeanFactory interfejs:

8 preklapanje metoda – overloading: mogućnost se u istoj klasi deklarišu dve ili više metoda sa istim imenom. Ove metode moraju se razlikovati po broju i/ili tipu parametara. 9 singleton bean – ukoliko je opseg bean-a definisan kao singleton, kontejner će kreirati samo jedno pojavljivanje bean-a, tako da će pri svakom zahtevu za takvim bean-om biti vraćeno isto pojavljivanje bean-a. Definisanje opsega bean-a objašnjeno je u poglavlju 2.6.4. Definisanje opsega bean-a 10 prototype bean – ukoliko je opseg bean-a definisan kao prototype, kontejner prilikom svakog zahteva za bean-om kreira novo pojavljivanje bean-a. U ovom slučaju, kontejner može da se posmatra kao zamena za new operator u Javi.


15

package org.springframework.beans.factory;

import org.springframework.beans.BeansException;

public interface BeanFactory {

String FACTORY_BEAN_PREFIX = "&";

Object getBean(String name) throws BeansException;

Object getBean(String name, Class requiredType) throws BeansException;

Object getBean(String name, Object[] args) throws BeansException;

boolean containsBean(String name);

boolean isSingleton(String name) throws NoSuchBeanDefinitionException;

boolean isPrototype(String name) throws NoSuchBeanDefinitionException;

boolean isTypeMatch(String name, Class targetType) throws

NoSuchBeanDefinitionException;

Class getType(String name) throws NoSuchBeanDefinitionException;

String[] getAliases(String name);

}

ApplicationContext interfejs nasleđuje BeanFactory interfejs. Njegove implementacije

takođe omogućavaju kreiranje i upravljanje životnim ciklusom bean-ova, ali pored toga nude podršku za integraciju sa Spring-ovim AOP modulom, upravljanje resursima za poruke (message resource support), kao i propagaciju događaja (application events propagation). Pored toga, obezbeđuje i posebne kontekste aplikacionog sloja kao što je interfejs WebApplicatioContext koji

se koristi u Web aplikacijama.

Dakle, interfejs BeanFactory obezbeđuje konfigurisanje okvira, kao i njegove osnovne

funkcionalnosti, dok interfejs ApplicationContext dodaje okviru nove, složenije funkcionalnosti,

pri čemu interfejs ApplicationContext predstavlja kompletan nadskup interfejsa BeanFactory,

odnosno omogućava sve što i BeanFactory interfejs. Odnos ova dva interfejsa prikazan je na

sledećoj slici (Slika 3).


16

Slika 3 : Odnos BeanFactory i ApplicationContext interfejsa[5]

2.5.2. Konfigurisanje i pokretanje kontejnera

Konfigurisanje Spring kontejnera vrši se na osnovu metapodataka koje je potrebno obezbediti prilikom pokretanja kontejnera. Ovi metapodaci predstavljaju uputstva kontejneru kako da kreira i konfiguriše bean-ove u aplikaciji. Konfiguracioni metapodaci mogu da se obezbede


17

programskim putem, zatim pomoću datoteka za definisanje osobina (properties 11 datoteke), međutim najčešče korišćena forma u kojoj se predstavljaju metapodaci su XML datoteke.

U primeru koji sledi data je osnovna struktura konfiguracione XML datoteke:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

<bean id="..." class="...">



</bean>

<bean id="..." class="...">



</bean>



</beans>

Nakon kreiranja konfiguracione datoteke koja sadrži definicije bean-ova potrebno je koristiti određenu implementaciju BeanFactory interfejsa (ili nekog izvedenog interfejsa, npr

interfejsa ApplicationContext), kome je prilikom kreiranja potrebno proslediti XML

konfiguracionu datoteku. U nastavku je dat primer kreiranja kontejnera korišćenjem ClassPathXmlApplicationContext i XmlBeanFactory klasa, pri čemu je naziv konfiguracione

datoteke appContext.xml i ona se nalazi u classpath12 putanji aplikacije. U ovoj datoteci definisan je samo jedan bean, što je i prikazano u sedećem primeru.




xmlns:context="http://www.springframework.org/schema/context"


http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-2.5.xsd">

<bean id="projekat" class="domen.Projekat">

11 properties datoteke – datoteke sa extenzijom .properties, koje se najčešće koriste za čuvanje određenih

parametara aplikacije. Parametri se čuvaju u formi dva stringa, od kojih je prvi ključ, a drugi vrednost parametra, npr. jdbc.driverClassName=com.mysql.jdbc.Driver. 12 classpath – putanja na osnovu koje Java virtuelna mašina (JVM) pronalazi klase Java aplikacija. Putanja može da se postavi korišćenjem –classpath opcije prilikom poziva nekog Java alata, ili postavljanjem sistemske CLASSPATH promenljive.


18

<property name="naziv" value="Studijski primer"/>

<property name="opis" value="Pracenje gresaka"/>

</bean>

</beans>

package domen;

public class Projekat {

private String naziv;

private String opis;

public String getNaziv() {

return naziv;

}

public void setNaziv(String naziv) {

this.naziv = naziv;

}

public String getOpis() {

return opis;

}

public void setOpis(String opis) {

this.opis = opis;

}

}

Sledećim primerom prikazan je način pokretanja kontejnera korišćenjem ClassPathXmlApplicationContext klase.

ApplicationContext spring = new

ClassPathXmlApplicationContext("appContext.xml");

Sledeći primer ilustruje način pokretanja kontejnera korišćenjem FileSystemXmlApplicationContext klase. Za razliku od prethodnog primera, ovoj klasi se kao

parametar konstruktora proseđuje apsolutna putanja do datoteke sa konfiguracionim metapodacima.

ApplicationContext spring = new

FileSystemXmlApplicationContext("D:/NetBeansProjects/PokretanjeSpringa/src/ap

pContext.xml");

Sledeći primer ilustruje način pokretanja kontejnera korišćenjem XmlBeanFactory klase. U

ovom primeru konfiguracioni metapodaci se prosleđuju ClassPathResource klasi u formi

apsolutne putanje u odnosu na classpath putanju aplikacije.


19

ClassPathResource conf = new ClassPathResource("appContext.xml");

BeanFactory spring = new XmlBeanFactory(conf);

Prilikom pokretanja Web aplikacije, konfiguracija Web aplikacionog konteksta se vrši u web.xml konfiguracionoj datoteci. Ako se koristi servlet kontejner koji podržava Servlet 2.3. ili noviju specifikaciju može da se koristi klasa org.springframework.web.context.

ContextLoaderListener, odnosno u slučaju korišćenja kontejnera koji podržava stariju, Servlet

2.2. specifikaciju koristi se klasa org.springframework.web.context.ContextLoader

Servlet.

Primer konfigurisanja Web aplikacionog konteksta korišćenjem klase ContextLoaderListener prikazan je u sledećem lisitngu.

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>/WEB-INF/appContext.xml</param-value>

</context-param>

<listener>

<listener-class>

org.springframework.web.context.ContextLoaderListener</listener-class>

</listener>

ApplicationContext objekat koji je na ovaj način kreiran od strane

ContextLoaderListener klase smešta se u ServletContext objekat Web aplikacije.

Objekat klase ContextLoaderListener prilikom pokretanja Web aplikacionog konteksta

tražiće datoteku applicationContext.xml unutar WEB-INF direktorijuma, međutim ovu podrazumevanu lokaciju i naziv konfiguracione datoteke moguće je promeniti korišćenjem contextConfigParam parametra kao što je prikazano u prethodnom primeru.


20

2.6. RAD SA JavaBean KOMPONENTAMA

Java Beans specifikacija na sledeći način definiše bean:[6]

Bean je softverska komponenta, sa mogućnošću ponovnog korišćenja, kojom se može vizuelno manipulisati u odgovarajućem alatu.

U kontekstu aplikacija koje se baziraju na Spring okviru, termin bean se koristi za sve objekte koji su kreirani od strane Spring kontejnera i kojima kontejner upravlja [7].

2.6.1. Definisanje bean-ova

Prilikom definisanja bean-ova, konfiguraciona datoteka se sastoji od jednog (korenog) beans elementa, i jednog ili više bean elemenata. Validacija ove XML datoteke vrši se u odnosu na

XML DTD datoteku spring-beans.dtd koja u potpunosti opisuje sve validne atribute i elemente koje konfiguraciona datoteka može da sadrži.

Od verzije 2.0 Spring okvir podržava i validaciju strukture konfiguracione datoteke u odnosu na XSD shemu. Novije verzije Springa su kompatibilne unazad, tako da je moguće i dalje koristiti DTD, međutim preproruka je da se koriste XSD datoteke, jer je konfiguracija uz pomoć njih kraća, čitljivija i jednostavnija.

Ono što se u najvećem broju slučajeva prvo definiše jeste ime bean-a, odnosno identifikator. Bitno je naglasiti da nije neophodno definisati identifikator, jer se u tom slučaju definisani bean tretira kao anoniman bean13. Ime bean-a može da se definiše korišćenjem name ili id atributa bean

elementa. Preporuka je da se prilikom definisanja imena bean-a koristi id atribut, jer je on XML

IDREF tipa, tako da u slučaju da ga drugi bean-ovi referenciraju XML parser može odrediti da li je referenca validna. IDREF tip poseduje ograničenja zbog kojih nije pogodan za korišćenje u određenim situacijama. Ova ograničenja se, pre svega, odnose na korišćenje karaktera. Neophodno da prvi karakter u nazivu bean-a bude slovo, a zatim mogu da sadrže i alfanumeričke karaktere ili donju crticu (underscore). Nije dozvoljeno korišćenje razmaka (whitespace). name atribut je koristan

ukoliko je potrebno definisati više od jednog identifikatora za bean, pri čemu se identifikatori odvajaju zarezom.

13 Anoniman bean – bean kome nije definisan identifikator ili ime korišćenjem id ili name atributa.


21

2.6.2. Kreiranje bean-ova

Najčešće primenjivan mehanizam kreiranja bean-ova jeste pomoću konstruktora bean-a. Prilikom definisanja bean-a, u okviru class atributa navodi se ime klase bean-a. U trenutku kada

kontejner zatreba novo pojavljivanje ovog bean-a, kontejner će interno odraditi operaciju koja je ekvivalent pozivu new operatora u Java kodu. Sledećim primerom prikazano je korišćenje

konstuktora za kreiranje bean-a.

package domen;




public String getNaziv() {

return naziv;

}

public void setNaziv(String naziv) {

this.naziv = naziv;

}

public String getOpis() {

return opis;

}

public void setOpis(String opis) {

this.opis = opis;

}

}

<bean id="projekat" class="domen.Projekat">

<property name="naziv" value="Studijski primer"/>

<property name="opis" value="Pracenje gresaka"/>

</bean>

Prilikom kreiranja pojavljivanja projekat bean-a, kontejner će koristiti podrazumevani14 (default) konstruktor, a zatim će pomoću metoda za postavljanje vrednosti atributa (set metode) dodeliti odgovarajuće vrednosti atributima bean-a.

Sledećim primerom prikazana je analogija između kreiranja bean-a od strane kontejnera, iz prethodnog primera, i kreiranja bean-a korišćenjem new operatora u Java kodu.

Projekat p = new Projekat();

p.setNaziv("Studijski primer");

p.setOpis("Pracenje gresaka");

14 podrazumevani (default) konstruktor – konstruktor koji kreira Java kompajler ukoliko klasa ne sadrži nijedan drugi konstruktor.


22

Kreiranje bean-a moguće je izvršiti i pomoću statičkog factory metoda. U tom slučaju potrebno je definisati klasu čija je uloga da učauri proces kreiranja bean-a unutar statičke metode. Zatim se, koristeći class atribut definiše ovaj bean, a factory-method atributom se specificira

koja metoda bean-a je zadužena za kreiranje bean-a. U nastavku sledi primer kreiranja bean-a korišćenjem statičkog factory metoda.

package domen;

/**

*

* @author Goran

*/

public class ProjekatStatickiFactory {

public static Projekat dajProjekat(){

return new Projekat();

}

}

<bean id="projekat" class="domen. ProjekatStatickiFactory "

factory-method="dajProjekat"

p:naziv="Studijski primer"

p:opis="Pracenje gresaka"/>

U ovom slučaju kontejner će korišćenjem definisane statičke metode da kreira bean, a zatim će pomoću metoda za postavljanje vrednosti atributa (set metode) dodeliti odgovarajuće vrednosti atributima bean-a.

Sledeći pristup u kreiranju bean-ova je korišćenje nestatičke (instance factory) metode. U tom slučaju za kreiranje bean-a se koristi metoda nekog drugog bean-a koji je već kreiran od stane kontejnera. Sledi primer kreiranja bean-a korišćenjem nestatičke metode.

package domen;

/**

*

* @author Goran

*/

public class ProjekatNestatickiFactory {

public Projekat dajProjekat(){

return new Projekat();

}

}

<bean id="projekatNestatickiFactory"

class="domen.ProjekatNestatickiFactory"/>

<bean id="projekat" factory-bean=" projekatNestatickiFactory "

factory-method="dajProjekat"

p:naziv="Studijski primer"

p:opis="Pracenje gresaka" />


23

2.6.3. Definisanje zavisnosti između bean-ova

Pored kreiranja bean-ova, ključna funkcionalnost koju obezbeđuje Spring IOC kontejner jeste definisanje zavisnosti bean-a. Zavisnosti između bean-ova definišu se u konfiguracionim datotekama, a u zavisnosti od konfiguracije, Spring će koristiti Setter ili Constructor Injection mehanizam.

Prilikom definisanja zavisnosti između dva bean-a, u smislu da jedan bean sadrži kao atribut referencu na drugi, koristi se ref element. ref element je moguće koristiti za specificiranje

vrednosti atributa ili stvarnog argumenta konstruktora. Konfiguracija se vrši tako što se najpre definišu referencirani i referencirajući bean-ovi, a potom se u referencirajućem doda ref element

kome se kao vrednost atributa bean navodi id referenciranog bean-a. Sledi primer:

<bean id=" projekatServisTarget" class=" servis.ProjekatServisImpl ">

<property name="dao">

<ref bean="projekatDao"/>

</property>

</bean>

<bean id="projekatDao" class="dao.ProjekatHibernateDaoImpl"

p:sessionFactory-ref="sessionFactory"/>

Pored bean atributa ref elementa, za definisanje zavisnosti između bean-ova moguće je

koristiti i local i parent atribute. Ukoliko se koristi local atribut, XML parser može u toku

parisiranja odrediti da li referencirani bean postoji ili ne. Međutim, pošto se ovaj proces verifikacije zasniva na XML IDREF mehanizmu, neophodno je da bean-ovi budu definisani u istoj konfiguracionoj datoteci i da su im imena definisana id atributom.

Kada se koristi bean atribut ref elementa, referencirani bean može da se nalazi u istom ili

drugom fragmentu XML datoteke koja se koristi za konfigurisanje kontejnera. U ovom slučaju validaciju će vršiti kontejner, a ne XML parser. parent atribut je najređe korišćen, i koristi se

uglavnom u slučajevima kada postoji konflikt u imenima bean-ova na različitim nivoima aplikacije.

Pored eksplicitnog definisanja zavisnosti bean-ova, Spring okvir nudi i mogućnost automatkog povezivanja korišćenjem autowire atributa bean elementa. Ukoliko se prilikom

definisanja bean-a u XML konfiguracionoj datoteci izostavi deklaracija atributa i argumenata konstruktora, kontejner će korišćenjem refleksije izvršiti povezivanje bean-ova na osnovu njihovog tipa ili imena. Automatsko povezivanje može da se definiše na globalnom nivou za ceo kontejner, ili na nivou pojedinačnog bean-a. Na nivou pojedinačnog bean-a moguće je koristiti jednu od pet vrednosti autowire atributa.


24

Vrednost Opis

no

Isključuje se automatsko povezivanje. Ova opcija se koristi u slučaju da je na globalnom novou za ceo kontejner uključeno automatsko povezivanje. U ovom slučaju povezivanje se vrši eksplicitno, korišćenjem ref elemetna.

byName

Povezivanje na osnovu imena atributa. Kontejner na osnovu imena atributa pronalazi odgovarajući bean koji je deklarisan pod istim imenom. Ukoliko kontejnter ne pronađe bean sa odgovarajućim imenom, osobina ostaje nepovezana.

byType

Povezivanje na osnovu tipa atributa. Kontejner pokušava da pronađe bean koji je istog tipa kao i atribut bean-a. Ukoliko ne pronađe odgovarajući bean, atribut ostaje nepovezan, a ukoliko nađe više od jednog bean-a istog tipa, baciće izuzetak.

constructor

Za svaki argument konstruktora kontejner pokušava da pronađe odgovarajući bean na osnovu tipa argumenta konstruktora.

autodetect

Kontejner pokušava automatsko povezivanje korišćenjem byType

ili constructor strategije. Ukoliko bean ima podrazumevani

konstruktor bez argumenata koristi se byType, a u ostalim

slučajevima constructor strategija.

Tabela 1 : Opcije za automatsko povezivanje bean-ova

2.6.4. Definisanje opsega bean-a

Opseg bean-ova se u Spring okviru, počev od verzije 2.0 definiše korišćenjem scope atributa

bean elementa. Spring okvir podržava 5 različitih opsega, od kojih su tri dostupna jedino u Web

aplikacijama.

Opseg Opis

singleton Jedno pojavljivanje bean-a za jedan Spring IoC kontejner.

prototype Jedna definicija bean-a se koristi za bilo koji broj pojavljivanja.

request

Jedna definicija bean-a se koristi po jednom životnom ciklusu HTTP zahteva (HTTP Request), tj. svaki HTTP zahtev će imati sopstveno pojavljivanje bean-a.

session

Jedno pojavljivanje bean-a se koristi po jednom životnom ciklusu HTTP sesije (HTTP Session).

global session Jedno pojavljivanje bean-a po jednoj HTTP globalnoj sesiji.

Tabela 2 : Opcije za definisanje opsega bean-a


25

U slučaju bean-ova koji su definisani kao singleton, kontejner će kreirati jedinstveno pojavljivanje bean-a na nivou kontejnera, a svi zahtevi i reference ka ovom bean-u rezultovaće vraćanjem ovog pojavljivanja. Singleton opseg je podrazumevani opseg, tj. ukoliko se prilikom definisanja bean-a ne navede drugačiji opseg, kontejner će bean posmatrati kao singleton. Sledi nekoliko ekvivalentnih definicija singleton bean-a.

<bean id="projekatDao" class="dao.ProjekatDaoImpl"/>

<bean id="projekatDao" class="dao.ProjekatDaoImpl" scope="singleton"/>

U 1.x verzijama Spring okvira podržani su bili samo singleton i prototype opsezi, a definicija opsega vršena je pomoću singleton atributa:

<bean id="projectDao" class="dao.ProjectDaoImpl" singleton="true"/>

Kod prototype bean-ova, novo pojavljivanje bean-a se pravi svaki put kada dodje do zahteva za bean-om. Prototype bean-ovi se koriste kada su potrebni stateful15, dok se singleton bean-ovi koriste za stateless16 bean-ove. Sledi definicija prototype bean-a:

<bean id="projekat" class="domen.Projekat" scope="prototype"/>

< bean id="projekat" class="domen.Projekat" singleton="false"/>

15 stateful bean – bean čije se stanje čuva između dve interakcije sa klijentom. 16 stateless bean – bean koji ne održava stanje između dve interakcije sa klijentom. Prilikom poziva metoda stateless bean-a, promenljive mogu da čuvaju stanje koje je specifično za klijenta, ali samo za vreme trajanja izvršenja metode.


26

2.7. SPRING MVC OKVIR

U okviru Web modula, Spring nudi kompletnu implementaciju MVC okvira, koji se koristi za razvoj Java Web aplikacija. Pre samog ulaska u opis komponeneti i koncepata MVC implementacije koju nudi Spring okvir, u nastavku je dat prikaz strukture Java Web aplikacija, kratak osvrt na Java Servlet i JSP tehnologije, kao i prikaz MVC uzora.

2.7.1. Struktura Web aplikacije

Web aplikacija predstavlja kolekciju individualnih komponenti koje zajedno čine kompletnu aplikaciju koja može da se instalira i izvrši u okviru Web kontejnera, npr. Apache Tomcat servlet kontejnera. Vezu između pojedinih komponenti čini zajednički Web kontekst, što im omogućava da, direktno, ili indirektno pozivaju jedna drugu.

Web aplikacija može da bude konkurentno instalirana i izvršavana u okviru više Web kontejnera. Takođe, moguće je više pojavljivanja jedne Web aplikacije instalirati unutar jednog Web kontejnera.

Većina Web aplikacija se sastoji od skupa direktorijuma i fajlova koji čine hijerarijsku strukturu17. Na sledećoj slici (Slika 4) dat je prikaz strukture Web modula.

Slika 4 : Struktura Web modula [4]

17 Java Servlet specifikacija ne zahteva da kontejneri podrže hijerarhijsku strukturu, ali je većina kontejnera ipak podržava.


27

Na samom vrhu Web modula nalazi se koreni (root) direktorijum aplikacije. U okviru ovog direktorijuma nalaze se sve ostale komponente aplikacije. Prema Java Servlet specifikaciji, neposredno ispod korenog direktorijuma mora da se nalazu WEB-INF direktorijum. WEB-INF direktorijum je privatni direktorijum aplikacije, što praktično znači da ni jedan resurs koji se nalazi unutar WEB-INF direktorijuma nije direktno dostupan korisniku aplikacije. Ovi resursi dostupni su samo servletima i Java klasama koje sačinjavaju Web aplikaciju, što WEB-INF direktorijum čini logičnim mestom za smeštanje konfiguracionih fajlova aplikacije.

WEB-INF direktorijum sastoji se od sledećih datoteka i direktorijuma [4]:

o web.xml : Opsivač rasporeda (Deployment Descriptor) Web aplikacije o .tld : Datoteke za opis tag bibilioteke o classes : Direktorijum koji sadrži servlete i utility klase i JavaBeans komponente. Ako su

Java klase u okviru njega grupisane po paketima onda ovaj direktorijum mora imati podirektorijume koji će imati nazive identičane nazivima paketa.

o tags : Direktorijum koji sadrži tag datoteke koji su implementacije tag biblioteke. o libs : Direktorijum koji sadrži biblioteke JAR (Java Archive) arhiva koje pozivaju klase sa

serverske strane.

Web modul predstavlja organizacioni okvir unutar koga se postavlja Web aplikacija. Web aplikacija se obično pakuje u JAR datoteku prilagođenu Web aplikacijama (WAR – Web archive), međutim, Web modul može da se organizuje i kao neraspakovana struktura direktorijuma. Ukoliko je aplikacija upakovana u WAR datoteku, datoteka mora da očuva hijerarhijsku strukturu direktorijuma u originalnom, neupakovanom obliku. Web modul koji je upakovan u WAR datototeku može lako da se distribuira i izvrši unutar Web kontejnera koji zadovoljava Java Servlet specifikaciju, ili pak može da bude deo veće EAR (Enterprise archive)18 datoteke.

Da bi se WAR datoteka postavila na Web server, datoteka mora da sadrži i opisivač rasporeda u vreme izvršenja (runtime deployment descriptor), koji predstavlja XML datoteku koja sadrži informacije o kontekstu Web aplikacije (gde je početak – koren Web aplikacije preko koga se pristupa Web komponentama) [4].

2.7.2. Java Servleti i JSP (JavaServer Pages)

Java servleti su deo Sun-ove J2EE (Java 2 Platform Enterprise Edition) arhitekture i oni pored JSP strana (Java Server Pages) i EJB-ova (Enterprise Java Beans) čine njenu osnovu. Java servleti pružaju metodu za razvoj Web aplikacija koji je komponentno zasnovan i platformski nezavistan. Servlet je preslikan pomoću jednog ili više URL (Uniform Resource Locator) adresa, i u opštem slučaju, kada server primi korisnički zahtev (request) koji je adresiran sa jednom od servletovih URL adresa, metoda service() u okviru servleta se pobuđuje i procesuira zahtev generišući određeni odgovor (response). Zato što se za svaki korisnički zahtev kreira odvojena nit (thread) koja je

18 Enterprise Archive (EAR) – standardna Java Archive (JAR) datoteka koja ima .ear ekstenziju. Korišćenjem EAR datoteka moguće je spajati više različitih J2EE modula (aplikacija) u novu složenu J2EE aplikaciju. [4]


28

povezana sa tim zahtevom, više niti ili korisnika može da aktivira service() metod datog servleta istovremeno. Ovakva višenitna priroda servleta je jedan od glavnih razloga zbog koga su oni bili skalabilniji od nekada uobičajenih CGI aplikacija. Takođe, to što su napisani u Java jeziku, čini ih nezavisnim od vrste platforme ili operativnog sistema. Druga značajna prednost toga što su napisani u Javi je mogućnost korišćenja celokupnog Java API-ja (Application Programming Interface), uključujući tu JDBC (Java DataBase Connectivity) i EJB-ove. Ovo su glavni razlozi zbog kojih je Java Servlet tehnologija tako brzo postala popularna.

Servlete ne izršava direktno Web server. Oni zahtevaju za svoje izvršavanje postojanje servlet kontejnera koji servletima pruža sve neophodne servise. Servlet kontejner je slabo povezan sa određenom instancom Web servera; oni zajedno sarađuju da bi obezbedili adekvatan servis svim korisničkim zahtevima koji mogu da dođu sa Web čitača (Web browser), Java apleta ili nekog drugog klijentskog programa.

Postoji veći broj popularnih servlet kontejnera na tržištu. Neki od njih su samostalni, dok drugi obezbeđuju i Web server i servlet kontejner unutar istog proizvoda. Postoji nekoliko njih koji su integrisani unutar aplikacionih servera i omogućavaju mnogo više funkcionalnosti.

Iako su servleti odlični u onome što rade ubrzo je postalo jasno da imaju neka ozbiljna ograničenja. Ova ograničenja prouzrokovana su najviše neophodnošću da se HTML direktno unosi u servlete i meša sa Java kodom. To je automatski značilo teškoće, jer je pri bilo kakvim izmenama u HTML dokumentima bilo neophodno rekompajliranje servleta. Takođe je postojao problem internacionalizacije Web aplikacija. U mnogim Web aplikacijama je zaobiđen ovaj problem tako što je za svaku posebnu lokalizaciju kreiran drugi servlet. Konačno, postojao je problem u raspodeli odgovornosti jer je usled mešanja HTML-a i Java koda unutar servleta postalo teško razdvojiti dizajnerske i programerske zadatke. Tako su JSP strane usledile kao sledeći korak u razvoju Web tehnologija zasnovanih na Java platformi.

Slika 5 : Upravljanje JSP stranama od strane servlet kontejnera


29

JSP strane su prirodno proširenje Java Servlet tehnologije. Ustvari, posle određenog predprocesiranja koje obavlja JSP kontejner, iz JSP strana se generišu njima odgovarajući Java servleti. Inače JSP strane su tekstualni dokumenti koji imaju .jsp ekstenziju i sadrže kombinaciju

statičkih HTML-olikih i XML-olikih tagova i skriptleta19. JSP datoteke se predprocesiraju i pretvaraju u .java datoteke. Iz ovakvih izvornih datoteka Java kompajler generiše .class datoteke koje

servlet kontejner može da izvršava. Ilustracija ovog procesa data je na slici 5.

2.7.2. MVC uzor

MVC uzor predstavlja uzor arhitekture, i sastoji se od tri ključne komponenete [8]:

o Model (Model) o Pogled (View) o Kontroler (Controller)

Model (Model) je komponenta koja sadrži strukturu poslovnog sistema i njene operacije,

odnosno, sadrži podatke i operacije za obradu podataka. Pogled (View) komponenta obezbeđuje korisnički interfejs preko koga korisnik komunicira

sa sistemeom. Takođe, on šalje korisniku izveštaje koji se dobijaju iz modela.

Kontroler (Controller)je komponenta koja je zadužena da upravlja izvršavanjem sistemskih operacija. Ona prihvata zahtev od klijenta, nakon toga poziva operaciju koja je definisana u modelu i kontroliše njeno izvršavanje.

Slika 6 : Apstraktan model MVC uzora

19 skriptlet je validan programski kod koji je ugrađen u JSP stranu.


30

Tradicionalna realizacija MVC uzora korišćenjem GUI (Graphic User Interface) implementacije podrazumeva da nakon određenog zahteva od strane korisnika u saradnji sa pogled komponentom, kontroler komponenta ažurira stanje model komponente, zatim se ove promene preko, npr. Observer20 uzora ažuriraju na pogled komponenti. Ovakva implementacija MVC uzora, usled ograničenja u HTTP protokolu nije izvodljiva u slučaju Web aplikacija.

U domenu razvoja Web aplikacija, JSP specifikacija predviđa dva osnovna modela razvoja korišćenjem JSP tehnologije. Ovi pristupi prezentirani su kao modeli arhitekture Web aplikacije a poznati su pod imenom Model 1 i Model 2.

Najveća razlika između ova dva modela arhitekture jeste u tome koja komponenta Web aplikacije je predviđena za procesiranje klijentskog zahteva (request). U Modelu 1, JSP strana obavlja svo procesiranje zahteva i takođe je zadužena da klijentu prikaže izlaz (output) najčešće u vidu HTML dokumenta. Ne postoje dodatni servleti koji su uključeni u ovaj proces. Klijentski zahtev se direktno šalje JSP strani koja komunicira sa JavaBens komponentama, ili nekim drugim servisom, ali isključivo je JSP strana ta koja određuje koja će sledeća strana biti poslata klijentu.

Slika 7 : Model 1

Za razliku od Modela 1, u Modelu 2 predviđeno je postojanje servleta koji presreće klijentski zahtev. Ovaj servlet se zove kontroler servlet. On obavlja inicijalno procesiranje zahteva i odlučuje koju JSP stranu sledeću treba prikazati. Ovim se za sve klijente omogućava jedinstvena tačka ulaska u web aplikaciju. Takođe se pruža mogućnost lakšeg proširivanja funkcionalnosti i ponovne upotrebe već postojećih komponenata.

20 Observer uzor omogućava mehanizam pomoću koga se između zavisnih objekata obezbeđuje automatsko obaveštavanje promene stanja jednog objekta i ažuriranje ostalih, pri čemu je moguće da je broj objekata koji se ažuriraju nepoznat, ili da objekat koji obaveštava druge objekte o promeni stanje ne poseduje nikakvu pretpostavku o tome koji su to objekti. U MVC kontekstu, Observer uzor se koristi kako bi se ostvarila slaba zavisnost (loose coupling) između modela i pogleda, tako što se prilikom svake promene stanja modela obaveštava pogled o nastalim promenama, kako bi automatski mogao da ažurira svoje stanje.


31

Slika 8 : Model 2

Kod drugog modela arhitekture postoji jasna podela na tri sloja: sloj poslovne logike, prezentacioni sloj i sloj koji obavlja procesiranje zahteva.

2.7.3. Koncepti Spring Web MVC okvira

Arhitektura Spring Web MVC okvira zasniva se na prikazanom Modelu2 , tj. podrazumeva postojanje kontroler servleta, kao centralne ulazne tačke za sve dolazeće zahteve. Ova komponenta u Spring MVC okviru realizovana je preko klase DispatcherServlet. Sloj poslovne logike

aplikacije realizovan je preko kontroler (Controller) komponente. U prezentacionom delu, Spring MVC podržava različitie tehnologije prikaza. Kao najznačajnija karakteristika prezentacionog sloja ističe se mogućnost ostvarenja potpune nezavisnosti između poslovne logike i konkretne prezentacione tehnologije. U nastavku sledi detaljniji prikaz realizacije navedenih komponenti u Spring MVC okviru, kao i način njihove međusobne komunikacije.

2.7.3.1. Klasa DispatcherServlet

Centralna komponenta Spring Web MVC okvira jeste klasa DispatcherServlet, koja

predstavlja glavnu ulaznu tačku za svaki dolazeći zahtev (request), koji je adresiran na Spring Web MVC aplikaciju. Ova klasa je u potpunosti integrisana u Spring IoC kontejner što omogućava korišćenje svih osobina koje poseduje Spring okvir.


32

Slika 9 : Konceptualni model toka obrade zahteva

Na prethodnoj slici (Slika 9), prikazan je konceptualni model obrade zahteva korišćenjem DispatcherServlet klase kao centralnog kontrolera. Kao što se sa slike vidi, centralni kontroler je

ulazna tačka za svaki dolazeći zahtev (request). Centralni kontroler po prijemu zahteva delegira zahtev odgovarajućem kontroleru koji je zadužen za obradu zahteva. Kontroler kreira model i obrađuje zahtev, zatim predaje centralnom kontoleru model i logičko ime pogleda. Model sadrži atribute koje pogled treba da prikaže klijentu. Na osnovu logičkog imena pogleda vrši se preslikavanje ka konkretnoj realizaciji pogleda kako bi se izvršila priprema (render) prikaza koji će biti vraćen klijentu kao odgovor (response).

Klasa DispatcherServlet je, zapravo, servlet (izvedena je iz klase javax.servlet.

http.HttpServlet). To jedini servlet koga je potrebno deklarisati i konfigurisati u opisivaču

rasporeda (deployment descriptor) Web aplikacije. Pored deklaracije servleta, u opisivaču rasporeda neophodno je definisaiti preslikavanja zahteva ka centralnom kontroleru (klasi DispatcherServlet). U nastavku je dat primer dela web.xml datoteke iz studijskog primera, u

kojoj je izvršena deklaracija klase DispatcherServlet.

<context-param>


<param-value>/WEB-INF/applicationContext.xml</param-value>

</context-param>

<listener>

<listener-class>

org.springframework.web.context.ContextLoaderListener

</listener-class>

</listener>


33

<servlet>

<servlet-name>spring</servlet-name>

<servlet-class>

org.springframework.web.servlet.DispatcherServlet

</servlet-class>

<load-on-startup>2</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>spring</servlet-name>

<url-pattern>*.htm</url-pattern>

</servlet-mapping>

Iz navedenog primera deklaracije vidi se da će svi zahtevi sa ekstenzijom .htm biti obrađeni od strane sevleta sa imenom spring, koji predstavlja objekat klase org.springframework.web. servlet.DispatcherServlet.

Spring okvir omogućava hijerarhijsko komponovanje aplikacionih konteksta (Application Context) Web aplikacije. Na taj način moguće je kontekst aplikacije logički podeliti tako da se svaki pojedinačni nivo konkteksta fokusira na određeni sloj aplikacije. U prethodnom primeru aplikacioni kontekst podeljen je u dva nivoa. Prvi aplikacioni kontekst zadužen je za kreiranje i upravljanje bean-ovima na poslovnom nivou aplikacije, dok se za klasu DispatcherServlet kreira aplikacioni

kontekst koji upravlja bean-ovima u Web sloju aplikacije. Ilustracija odnosa aplikacionih konteksta data je na sledećoj slici:

Slika 10 : Hijerarhija aplikacionihkonteksta u Spring MVC aplikaciji [5]


34

Prilikom inicijalizacije klase DispatcherServlet, Spring okvir će tražiti datoteku pod

imenom [imeDispatcherServleta]-servlet.xml unutar WEB-INF direktorijuma, i na osnovu toga kreirati bean-ove koji su u datoteci definisani.

Za prethodni primer u kome je definisana klasa DispatcherServlet sa imenom spring,

prilikom inicijalizacije, okvir će u WEB-INF direktorijumu potražiti datoteku sa imenom spring-servlet.xml.








</beans>

Kao što se može videti na Slici 3., interfejs WebApplicationContext predstavlja proširenje

ApplicationContext interfejsa, koje poseduje neke dodatne funkcionalnosti karakteristične za

Web aplikacije.

U okviru aplikacionog konteksta koji se kreira za DispatcherServlet klasu definišu se

bean-ovi koji obezbeđuju modelovanje toka procesa obrade zahteva. Sledi kratak opis interfejsa ovih bean-ova:

o HandlerMapping : Odgovoran je za određivanje odgovarajućeg kontrolera kome će zahtev biti prosleđen. Kriterijum na osnovu koga se donosi odluka koji kontroler da se izvrši može da bude, na primer, URL dolazećeg zahteva.

o ViewResolver : Omogućava preslikavanje logičkih imena pogleda (View) u stvarne poglede. o LocaleResolver : Komponenta aplikacije koja omogućava lokalizaciju. o MultipartResolver : Omogućava slanje (upload)datoteka na server korišćenjem HTTP

protokola. o ThemeResolver : Omogućava korišćenje tema. o HandlerExceptionResolver : Pruža podršku za preslikavanje izuzetaka. o Controller : Predstavljaju komponentu MVC okvira. o HandlerInterceptor : Omogućavaju presretanje dolazećeg HTTP zahteva.

2.7.3.2. Preslikavanje zahteva (request) ka kontrolerima

Spring okvir obezbeđuje više mehanizama koji omogućavaju da se ostvari veza između dolazećeg HTTP zahteva (HTTP Request) i kontrolera koji treba da se izvrši. Sve klase koje obezbeđuju mehanizam preslikavanja nalaze se u paketu org.springframework.web.servlet.

handler. U ovom paketu nalazi se više implementacija org.springframework.web.servlet.


35

HandlerMapping interfejsa koje omogućavaju primenu različitih strategija preslikavanja zahteva

ka kontrolerima.

Podrazumevana (default) strategija

Ukoliko u kontekstu aplikacije nije definisan bean za preslikavanje zahteva, Spring okvir će koristiti podrazumevanu implementaciju, klasu BeanNameUrlHandlerMapping. Dakle,

podrazumevana strategija preslikavanja zahteva prema kontrolerima realizuje se korišćenjem imena bean-a kome će zahtev biti prosleđen na obradu.

Kada se koristi ova strategija preslikavanja, sva imena kontroler bean-ova prema kojima se vrši preslikavanje zahteva moraju biti definisana u formi URL obrasca (URL pattern). U sledećem primeru prikazana je definicija bean-a pod imenom “/index.htm”. Svaki zahtev (HTTP Request) sa

URL adresom http://localhost:8084/ProgramskeGreske/index.htm biće preslikan ka bean-u web.kontroler.IndexController

21.






<bean name="/index.htm"

class="web.kontroler.IndexController">



</bean>

</beans>

Preslikavanje pomoću imena klase kontrolera

Klasa ControllerClassNameHandlerMapping obezbeđuje preslikavanje zahteva ka

kontrolerima na osnovu imena klase kontroler bean-a. Ova implementacija HandlerMapping

interfejsa koristi URL obrazac sadržan u zahtevu i preslikava je na onaj kontroler čije se ime klase podudara sa URL obrascem. Sledi primer:






<bean

class="org.springframework.web.servlet.mvc.support.ControllerClassNameHandler

21 U okviru paketa web.kontroler mora da postoji implemetacija klase IndexController koja će da vrši

obradu zahteva.

http://localhost:8084/ProgramskeGreske/index.htm


36

Mapping"/>

<bean class="web.kontroler.IndexController">



</bean>

</beans>

Prilikom definicije kontroler bean-a nije potrebno navesti identifikator, budući da se preslikavanje vrši na osnovu imena klase. Za zahtev (HTTP request) sa URL adresom http://localhost:8084/ProgramskeGreske/index.htm biće urađeno preslikavanje ka web.kontroler.IndexController kontroleru. Dakle, iz URL adrese se uzima samo URI deo, u

ovom slučaju “/index.htm”, iz koga se izuzuma “.htm” deo, a iz imena klase kontrolera izuzima se “Controller” deo (ako postoji). Ovo preslikavanje može slikovito da se prikaže na sledeći način:

Eksplicitna definicija preslikavanja

Klasa SimpleUrlHandlerMapping je najčešće korišćena implementacija HandlerMapping

interfejsa. Za razliku od prethodne dve strategije, gde je bilo potrebno voditi računa o identifikatoru kontroler bean-ova, ili o imenu klase kontrolera, ukoliko se koristi klasa SimpleUrlHandlerMapping, preslikavanja između zahteva i kontrolera se eksplicitno zadaju u

mappings atributu SimpleUrlHandlerMapping klase. Sledeći primer prikazuje preslikavanje

zahteva prikazanog u prethodna dva primera korišćenjem SimpleUrlHandlerMapping bean-a.






<bean

class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">

<property name="mappings">

<props>

<prop key="index.htm">indexController</prop>

</props>

</property>

</bean>

<bean name="indexKontroler" class="web.kontroler.IndexController">



</bean>

</beans>

http://localhost:8084/ProgramskeGreske/index.htm


37

2.7.3.3. Kontoler (Controller)

Jedna od najznačajnijih komponenti Spring MVC okvira je kontroler komponenta. U opštem slučaju, nakon prijema korisničkog zahteva, kontroler je komponenta koja je odgovorna za izvršenje konkretne poslovne operacije i definisanja koji pogled (View) će biti vraćen korisniku.

Kontroler komponentu Spring MVC okvira predstavaljaju implementacije org.

springframework.web.servlet.mvc.Controller interfejsa. U najjednostavnijem slučaju,

neophodno je implementirati samo metodu handleRequest() definisanu u Controller

interfejsu, međutim sam Spring okvir nudi više realizacija ovog interfejsa koje omogućavaju složeniju obradu zahteva. U sledećem listingu dat je prikaz Controller interfejsa:

package org.springframework.web.servlet.mvc;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import org.springframework.web.servlet.ModelAndView;

public interface Controller {

ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse

response) throws Exception;

}

Kontroler može da se posmatra kao običan servlet, pri čemu handleRequest() metoda

predstavlja ekvivalent service() metodi. Kao i običan servlet, kontroler može direktno da vrati

odgovor (Response) klijentu. To se postiže jednostavnim vraćanjem null vrednosti umesto

pojavljivanja ModelAndView objekta. Suštinska razlika između servleta i kontrolera je u tome da se

kontroleri ne definišu direktno u web.xml datoteci, već njima upravlja Spring-ov centralni servlet (klasa DispatcherServlet). Na ovaj način omogućeno je da kontroleri mogu da koriste sve

osobine i funkcionalnosti koje nudi Spring IoC kontejner.


38

Slika 11 : Hijerarhija najčešće korišćenih kontrolera [9]

Na prethodnoj slici (Slika 11) dat je prikaz najčešće korišćenih kontrolera koji su deo Spring MVC okvira.

Pomenuta tri koncepta, Model, pogled (View) i kontroler (Controller), predstavljaju osnovu Spring MVC implementacije. Controller interfejs definiše osnovnu funkcionalnost svakog

kontrolera, dok različite varijante njegove implementacije nude više funkcionalnosti koje se mogu koristiti u određenim situacijama.

2.7.3.4. Klasa ModelAndView

Nakon obrade zahteva, kontroler komponenta kao povratnu vrednost vraća pojavljivanje klase org.springframework.web.servlet. ModelAndView. Iz samog naziva klase može da se


39

zaključi šta je njen sadržaj – objekti klase ModelAndView sadrže reference ka model i pogled (View)

komponentama.

Model je predstavljen mapom (java.util.Map), sačinjenom od imena objekata kao

ključeva, i samih objekata kao vrednosti.

Pogled (View) može da bude konkretno pojavljivanje određene implementacije org.springframework. web.servlet.View interfejsa, ili logičko ime pogleda, čije se

preslikavanje u konkretan pogled vrši pomoću bean-ova za preslikavanje imena pogleda (interfejs ViewResolver). Na taj način omogućeno je potpuno razdvajanje imena pogleda od konkretne

tehnologije kojom je realizovan.

2.7.3.5. Pogled (View) i bean-ovi za preslikavanje pogleda (ViewResolver)

Kao što je već rečeno, svaki kontroler u Spring MVC okviru kao rezultat vraća pojavljivanje ModelAndView objekta. Pogled (View) predstavlja određenu implementaciju

org.springframework.web.servlet.View interfejsa čiji prikaz je dat u nastavku:

package org.springframework.web.servlet;

import java.util.Map;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

public interface View {

void render(Map model, HttpServletRequest request,

HttpServletResponse response) throws Exception;

}

Uloga pogleda je da pripremi model koji joj se proseđuje kao argument render() metode, u

određeni oblik koji je pogodan za izabranu tehnologiju prikaza. Na primer, u slučaju kada se koristi JSP tehnologija, render() metoda postavlja primljeni model (java.util.Map) kao atribut

dostupan JSP strani u opsegu HTTP zahteva (HTTPServletRequest scope).

Spring MVC omogućava potpunu nezavisnost kontroler komponente od konkretne tehnologije prikaza. Razdvajanje ovih komponenti realizovano je tako što ModelAndVew objekat,

vraćen od strane kontrolera sadrži samo logičko ime pogleda, dok se mehanizam preslikavanja logičkih imena pogleda u konkretnu realizaciju pogleda vrši pomoću bean-ova za preslikavanje imena pogleda (View Resolver). Bean-ovi za preslikavanje imena pogleda (View Resolver) predstavljaju implementaciju org.springframework.web.servlet.ViewResolver interfejsa.


40

package org.springframework.web.servlet;

import java.util.Locale;

public interface ViewResolver {

View resolveViewName(String viewName, Locale locale) throws Exception;

}

U okviru paketa org.springframework.web.servlet.view postoji određeni broj

implementacija koje je moguće koristiti. U sledećem listingu prikazana je konfiguracija bean-a za preslikavanje imena pogleda (View Resolver)unutar spring-servlet.xml datoteke.






<bean id=”viewResolver”

class="org.springframework.web.servlet.view.InternalResourceViewResolver">

<property name="viewClass">

<value>org.springframework.web.servlet.view.JstlView</value>

<property name="prefix" value="/WEB-INF/jsp/" />

<property name="suffix" value=".jsp"/>

</bean>

</beans>

Vrednosti prefix i suffix atributa se jednostavno dodaju logičkom imenu pogleda, tako

će, na primer, logičko ime pogleda login biti preslikano ka stranici /WEB-INF/jsp/login.jsp.

Iako je u većini slučajeva jedan bean za preslikavanje imena pogleda (View Resolver) dovoljan, Spring nudi mogućnost korišćenja više ovakvih bean-ova njihovim ulančavanjem. Ovo je korisno ukoliko se istovremeno koriste različite tehnologije prikaza. U tom slučaju potrebno je pomoću order atrubuta postaviti redosled kojim se određuje koji od bean-ova u lancu ima

prvenstvo prilikom preslikavanja. Order atribut prihvata celobrojne (Integer) vrednosti, pri čemu

je prioritet bean-a za preslikavanje veći ukoliko je vrednost order atributa manja.

Pored ulančavanja, Spring nudi i mogućnost keširanja pogleda čija su imena preslikana . U tu svrhu može da se koristi klasa AbstractCachingViewReslover i njene podklase. Keširanje

preslikanih pogleda omogućava znatno bolje performanse prilikom korišćenja određenih tehnologija prikaza.


41

2.7.3.6. Korišćenje formi

Iako sam Spring okvir ne favorizuje ni jednu tehnologiju prikaza, kada je reč o Java Web aplikacijama, u najvećem broju slučajeva koristi se JSP tehnologija. JSP tehnologija je deo J2EE specifikacije, koja predstavlja industrijski standard za razvoj Web aplikacija korišćenjem Java tehnologije.

U okviru Web aplikacija, interakcija sa korisnikom, odnosno unos podataka od strane korisnika, ostvaruje se putem HTML formi. U klasičnim aplikacijama koje koriste Java servlet tehnologiju za preuzimanje i korišćenje podataka koje korisnik unese , neophodno je da se radi direktno sa HttpServletRequest objektom i njegovom metodom getParameter(). Ovakva

obrada potencijalno predstavlja izvor mnogih grešaka u softveru, pošto iziskuje mnogo programskog koda koji se odnosi na obradu grešaka u samim podacima koje je korisnik uneo, proveru da li neki podaci eventualno nedostaju, zatim potencijalne konverzije tipova podataka, itd.

Spring MVC u okviru org.springframework.web.servlet.mvc paketa nudi niz

kontrolera koji omogućavaju automatizaciju procesa preuzimanja unetih podataka na formi, zatim proveru validnosti podataka, konvertovanje podataka, itd. U tom kontekstu, jedan od najkorisnijih i najčešće korišćenih kontrolera je klasa SimpleFormController. Kao i većinu komponenti koje

Spring nudi, i ovaj kontroler je moguće potpuno konfigurisati korišćenjem Dependency Injection osobina Spring okvira. Primer korišćenja ovog kontrolera prikazan je u nastavku, u oviru podnaslova 2.7.3.9. Ilustrativni primer.

Jedna od najbitnijih funkcionalnosti koje nudi SimpleFormController klasa jeste

povezivanje (data binding) HTML formi i JavaBean komponenti, čime se omogućava automatsko kreiranje i popunjavanje JavaBean komponente parametrima iz zahteva. Pomenuti bean-ovi nazivaju se komandni bean-ovi (command beans). Značajno je istaći da Spring okvir ne zahteva od korisnika da klasa komandnog bean-a bude određenog tipa, ili da nasledi neku Spring-ovu klasu, što omogućava korišćenje bilo koje Java klase koja zadovoljava JavaBeans model22. Na taj način moguće je direktno iz zahteva postaviti vrednosti atributa odgovarajućeg objekta domenskog modela aplikacije.

Povezivanje podataka (Data binding) se u Spring okviru realizuje pomoću org.springframework.validation.DataBinder klase i njenih podklasa. DataBinder klasa

nije vezana konkretno za Spring MVC okvir, već omogućava povezivanje podataka u bilo kom tipu aplikacije. Za povezivanje sa parametrima HTTP zahteva (HttpServletReqest) koristi se klasa

ServletRequestDataBinder. Proces povezivanja parametara zahteva sa atributima komandnog

bean-a podrazumeva konverziju parametara, koji mogu da budu jedino tipa String, u odgovarajući tip atributa komandnog bean-a. U tu svrhu koristi se infrastruktura editora osobina (Property Editors), koja predstavlja sastavni deo JavaBeans standarda. Uz Spring okvir isporučuje se veliki broj implementacija editora osobina, kao što je na primer klasa URLEditor koja vrši konverziju

String-a u odgovarajući java.net.URL objekat, i obratno. Implementacije editora osobina nalaze se

u paketu org.springframework.beans.propertyeditors.

22 Neophodno je da klasa poseduje javni neparametarski konstruktor i odgovarajuće metode za postavljanje i preuzimanje vrednoti atributa bean-a (set() i get() metode).


42

Spring okvir obezbeđuje posebne tagove koji se mogu koristiti prilikom kreiranja formi. U sledećoj tabeli dat je kratak opis tagova:

Tag Opis

bind

Kreira BindStatus objekat koji sadrži sve relevantne informacije

o osobinama komandnog objekta. Osobine se specificiriraju preko path atributa.

nestedPath

Koristi se u kombinaciji sa bind tagom, pri čemu se vrednost

path atributa nestedPath taga koristi kao prefiks u bind tagu.

Npr., ukoliko komandni objekat sadrži kolekciju objekata, u nestedPath putanju može da se stavi ime komandnog objekta i

ime kolekcije, kako bi se u bind tagovima unutar nestedPath

taga moglo pristupati objektima iz kolekcije bez navođenja celokupne putanje.

transform

Obezbeđuje mehanizme za transformaciju osobina iz izvora različitih od komandnog objekta. Pogodan je za prikaz referenciranih podataka, npr. opcija u padajućoj listi.

hasBindErrors Koristi se prilikom validacije podataka za prikaz grešaka.

message Koristi se za internacionalizaciju aplikacije.

Tabela 3 : Tagovi koji se mogu koristiti u radu sa formama

Najvažniji, i najčešće korišćen tag je bind tag. Korišćenjem bind taga vrši se povezivanje

jednog atributa komandnog objekta sa jednim poljem za unos na formi. Jedini obavezan atribut ovog taga je path atribut, kojim se navodi ime atributa koji se povezuje. Tom prilikom kreira se

objekat klase BindStatus, koji sadrži informacije o imenu, vrednosti i eventualnim greškama koje

su nastale tokom validacije atributa koji se povezuje bind tagom. Pojavljivanje BindStatus objekta

dostupno je u opsegu JSP strane (page scope) pod imenom status. Lista atributa status objekta

data je u sledećoj tabeli.

Tag Opis

expression

Vraća izraz koji identifikuje osobinu, odnosno naziv atributa koji se povezuje bind tagom. Može iskoristiti za specificiranje name

atributa polja za unos na formi.

value Vraća vrednost atributa.

error

Koristi se za utvrđivanje da li atribut sadrži poruku o greški. Kao rezultat izvršenja vraća logičku vrednost, tako da se lako može koristiti u JSP izrazima.


43

errorMessages

Vraća niz poruka o nastalim greškama. Poruke o greškama se kreiraju u kontroleru ili validatoru podataka.

errorMessage Vraća prvu dostupnu poruku o greški.

Tabela 4 : Najčešće korišćeni atributi status objekta

2.7.3.7. Validacija podataka

Veoma važna komponeneta poslovne logike svake aplikacije je logika kojom se vrši provera ispravnosti podataka koje unosi korisnik. Slučajnim, ili namernim unosom neispravnih podataka, ukoliko se ne izvrši validacija unetih podataka, može vrlo lako da se ugrozi integritet poslovnog sistema, jer se na taj način pozivaju poslovne metode sistema sa netačnim podacima.

Validacija podataka u Spring okviru obezbeđena je kroz Validator interfejs smešten u

org.springframework.validation paketu. Dakle, prilikom rada sa Spring okvirom, sva logika

koja se odnosi na validaciju podataka treba da bude smeštena u okviru klasa koje implementiraju Validator interfejs. Iz samog imena paketa u kome se nalazi interfejs može da se zaključi da se

mehanizmi validacije ne odnose samo na validaciju podataka u Web aplikacijama, već se na ovaj način može vršiti validacija u različitim tipovima aplikacija. U nastavku je dat prikaz Validator

interfejsa:

package org.springframework.validation;

public interface Validator {

boolean supports(Class clazz);

void validate(Object target, Errors errors);

}

U okviru validate() metode vrši se konkretna validacija na prosleđenom target objektu,

dok se metodom supports() definiše klasa nad kojom se vrši validacija u okviru validate()

metode. Metodi validate() prosleđuju se dva parametra. Prvi parametar je objekat nad kojim

treba izvršiti validaciju, a drugi predstavlja objekat klase Errors, smeštene u istom paketu kao i

Validator interfejs. Errors klasa se koristi za specifikaciju poruka o greškama nastalim tokom

validacije. Ove poruke se kasnije koriste u prezentacionom sloju za prikaz poruka o nastalim greškama.

Uz Spring okvir ne isporučuje se konkretna implementacija koja može da se koristi za validaciju podataka, već se implementacija validacione logike prepušta korisniku, pri čemu se u okviru org.springframework.validation paketa nalazi klasa ValidationUtils koja sadrži

nekoliko korisnih metoda koje mogu da se koriste prilikom validacije unetih podataka.


44

2.7.3.8. Internacionalizacija (i18n)

Proces projektovanja softvera kojim se postiže lako adaptiranje za različite jezičke i kulturne sredine naziva se internacionalizacija23[4].

Internacionalizovani softver poseduje sledeće karakteristike [4]:

o Poseduje dodatne, lokalizovane podatke tako da se može pokrenuti bilo gde u svetu u formatu razumljivom za specifični region.

o Tekstualni elementi programa, kao što su statusne poruke, GUI labele, itd., nisu vezane (hardcoded) za programski kôd, već se dinamički učitavaju (u toku izvršavanja programa).

o Podrška za novi jezik ne zahteva rekompajliranje programa. o Kulturno-zavisni podaci, kao što su prikazi datuma i moneta, prikazuju se u formatu koji

odgovara korisnikovom regionu i jeziku. o Može biti brzo lokalizovan.

Lokalizacija23 softvera je proces adaptiranja softvera za određeni region ili\i jezik, dodavanjem i menjanjem komponenti softvera. [4]

U Spring okviru internacionalizacija aplikacija realizuje se koršćenjem datoteka za definisanje osobina24 koje se u ovom kontekstu nazivaju resursni skupovi (resource bundle). Ove datoteke treba da sadrže sve podatke koje je potrebno lokalizovati za ciljni region ili jezik. Tu se pre svega misli na tekstualne poruke, koje predstavljaju najočigledniju formu podataka koji zavise od kulturne sredine i jezika, ali i na druge podatke, kao što su merne jedinice, monete, datumi, labele na formama, poruke o greškama, itd.

Komunikacija sa datotekama resursnih skupova (resource bundle) u Spring okviru ostvaruje se preko implementacija MessageSource interfejsa. U zavisnosti od implementacije interfejsa,

resursni skupovi se na različite načine čuvaju u MessageSource objektima, međutim, pristup

vrednostima se ostvaruje uvek preko getMessage() metode koja je definisana u MessageSource

interfejsu.

Prilikom učitavanja aplikacionog konteksta (interfejs ApplicationContext), okvir će

automatski tražiti bean pod imenom „messageSource“25. Podrazumeva se da ovaj bean mora da bude implementacija MessageSource interfejsa. Ukoliko bean pod ovim imenom nije definisan,

okvir će kreirati prazno 26 pojavljivanje StaticMessageSource klase, koja implementira

MessageSource interfejs. Ovo je neophodno, budući da ApplicationContext interfejs nasleđuje

MessageSource intefejs, kao što može da se vidi na Slika 3.

Najčešće korišćena implementacija koju nudi Spring okvir je klasa ResourceBundleMessageSource, koja u suštini predstavlja omotač (wrapper) standardne

23 Internacionalizacija (Internationalization) se često naziva skraćeno i18n, zbog dužine reči, 18 znakova između „i“ i „n“. U istom duhu za lokalizaciju (localization) se koristi skraćenica l10n 24 Datoteke sa ekstenzijom .properties u koje se smeštaju parovi stringova razdvojeni znakom „=”, gde je prvi string ključ, a drugi vrednost osobine. 25ukoliko se koristi neko drugo ime, kontejner će smatrati da izvor poruka (Message Source) nije definisan 26 prazno u smislu da ne sadrži nikakve podatke iz datoteka resursnih skupova.


45

java.util.ResourceBundle klase. Jedini parameter koji ova klasa zahteva je parameter

basename kojim se određuje koju datoteku resursnih skupova (resource bundle) treba da učita.

Klasa ReloadableResourceBundleMessageSource je druga implementacija

MessageSource interfejsa koju Spring nudi. Ova klasa daje mogućost promene vrednosti u

resursnim datotekama (resource bundle) u toku izvršenja programa, što omogućava da se poruke dinamički menjaju.

U okviru sledećeg podnaslova dat je primer kreiranja datoteke resursnih skupova (resource bundle), kao i konfigurisanja ResourceBundleMessageSource bean-a u okviru aplikacionog

konteksta.

2.7.3.9. Ilustrativni primer

Kroz sledeći primer, koji je zapravo deo studijskog primera, dat je detaljniji prikaz prethodno opisanih koncepata Spring MVC okvira. Kroz primer će biti prikazan proces implementacije slučaja korišćenja dat sledećim scenariom korišćenja:

SK: Snimanje programera Naziv: Snimanje programera Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje Web stranu za unos

podataka o programeru.

Osnovni scenario:

1. Korisnik unosi podatke o programeru 2. Korisnik proverava ispravnost unetih podataka 3. Korisnik poziva sistem da sačuva novog programera 4. Sistem kreira i snima novog programera 5. Sistem prikazuje podatke o novokreiranom programeru

Za implementaciju ovog primera korišćeno je NetBeans 6.5 razvojno okruženje koje pruža

podršku za jednostavno kreiranje projekata koji se baziraju na Spring okviru.

Kreiranje i konfigurisanje projekta

Kreiranje Java Web projekta u NetBeans okruženju vrši se izborom File>New Project stavke glavnog menija. Kreiranje projekta se odvija u nekoliko jednostavnih koraka. Prvi korak je izbor vrste projekta, gde je potrebno izabrati opciju Java Web -> Web Application. U sledećem koraku potrebno je dati ime projektu i definisati lokaciju na kojoj će se projekat nalaziti. Zatim, u narednom koraku je potrebno izabrati server u okviru koga će se izvršavati aplikacija. U okviru ovog primera korišen je Apache Tomcat 6.0.18 servlet kontejner, koji može da se konfiguriše da radi kao Web server. U poslednjem koraku potrebno je izabrati okvir koji će biti korišćen u aplikaciji. Ovde je


46

potrebno izabrati opciju Spring MVC 2.5. Takođe, u ovom koraku moguće je definisati ime cetralnog servleta (klasa Dispatcher Servlet).

Na ovaj način kreiran je projekat baziran na Spring MVC okviru, pri čemu NetBeans okruženje automatski kreira sledeće konfiguracione datoteke:

o WEB-INF\web.xml – standardni opisivač rasporeda Web aplikacije o WEB-INF\ [ime_ dispatcher_servleta]-servlet.xml – konfiguraciona datoteka na osnovu koje

se kreira aplikacioni kontekst27 za centralni servlet (realizaciju klase DispatcherServlet).

Ova datoteka se uglavnom koristi za definisanje bean-ova koji se koriste u Web sloju aplikacije.

o WEB-INF\applicationContext.xml - datoteka u kojoj se definišu bean-ovi poslovne logike aplikacije. Potrebno je napomenuti da je i bean-ove poslovne logike moguće definisati u okviru [ime_ dispatcher_servleta]-servlet.xml datoteke. Međutim , na ovaj način se obezbeđuje hijerahijska struktura aplikacionog konteksta aplikacije, kao što je prikazano na Slika 10.

U datoteci web.xml definisan je centralni servlet (klasa DispatcherServlet) na osnovu

imena datog prilikom kreiranja projekta. Na sledećem listingu može da se vidi da će svi zahtevi (HTTP Request) sa ekstenzijom .htm biti obrađeni od strane centralnog servleta.


<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"


xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

<context-param>


<param-value>/WEB-INF/applicationContext.xml</param-value>

</context-param>

<listener>

<listener-class>

org.springframework.web.context.ContextLoaderListener</listener-class>

</listener>

<servlet>

<servlet-name>dispatcher</servlet-name>

<servlet-class> org.springframework.web.servlet.DispatcherServlet</servlet-

class>

<load-on-startup>2</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>dispatcher</servlet-name>

<url-pattern>*.htm</url-pattern>

</servlet-mapping>

<session-config>

<session-timeout>

30

27 Aplikacioni kontekst Web aplikacija u Spring MVC okviru predstavlja realizaciju klasa koje implementiraju WebApplicationContext interfejs. Budući da se u ovom slučaju koriste XML konfiguracione datoteke, radi se o

XmlWebApplicationContext klasi.


47

</session-timeout>

</session-config>

<welcome-file-list>

<welcome-file>redirect.jsp</welcome-file>

</welcome-file-list>

</web-app>

Prilikom inicijalizacije centralnog servleta (realizacija klase DispatcherSevlet), Spring

okvir će automatski tražiti datoteku [ime_dispatcher_servleta]-servlet.xml u WEB-INF direktorijumu, i tom prilikom kreirati bean-ove definisane u ovoj datoteci. U konkretnom primeru, NetBeans je automatski kreirao datoteku dispatcher-servlet.xml u WEB-INF direktorijumu na osnovu imena centralnog servleta koje je definisano prilikom kreiranja projekta.

Pored konfiguracionih datoteka, NetBeans kreira i dve JSP datoteke: redirect.jsp i WEB-INF\jsp\index.jsp. Stranica redirect.jsp je definisana kao početna (welcome file) strana u web.xml konfiguracionoj datoteci, i njena uloga je da izvrši preusmeravanje ka zadatoj URL adresi. Preporuka je da sve ostale JSP stranice budu smeštene unutar WEB-INF direktorijuma, jer je na taj način onemogućen direktan pristup korisnicima ka ovim stranicama unošenjem URL adrese sa direktnom putanjom do JSP datoteka. U sledećem listingu dat je sadržaj datoteke redirect.jsp.

<%@page contentType="text/html" pageEncoding="UTF-8"%>

<% response.sendRedirect("index.htm"); %>

U konfiguracionoj datoteci dispatcher-servlet.xml definisan je kontroler bean koji vrši preusmeravanje na stranicu index.jsp koja se nalazi u WEB-INF\jsp direktorijumu. Pored toga, definisan je bean za preslikavanje zahteva (HTTP Request) ka kontrolerima (urlMapping bean), i

bean za preslikavanje logičkog imena pogleda (View) u stvarnu realizaciju pogleda (viewResolver

bean). Na sledećem listingu dat je prikaz dela dispatcer-servlet.xml datoteke na kome može da se vidi definicija ovih bean-ova:

<bean id="urlMapping"



<props>


</props>

</property>

</bean>

<bean id="viewResolver"

class="org.springframework.web.servlet.view.InternalResourceViewResolver"

p:prefix="/WEB-INF/jsp/"

p:suffix=".jsp" />


48



<bean name="indexController"

class="org.springframework.web.servlet.mvc.ParameterizableViewController"

p:viewName="index" />

Na ovaj način kreiran je projekat baziran na Spring Web MVC okviru. Nakon toga potrebno je kompajlirati projekat i napraviti .war datoteku koja može da se izvrši u okviru Apache Tomcat servlet kontejnera. Ukucavanjem http://localhost:8084/StudijskiPrimer/index.htm URL adrese u Web čitaču (Web Browser) dobija se rezultat prikazan na sledećoj slici (Slika 12):

Slika 12 : Rezultat nakon poziva index.htm strane

Kao što je već rečeno, direktan pristup ka stranici index.jsp nije moguć, tako da se

prilikom ukucavanja URL adrese koja predstavlja direktnu putanja do ove stanice dobija sledeći rezultat (Slika 13).

Slika 13 : Rezultat nakon direktnog poziva index.jsp strane

28 Klasa ParameterizableViewController može da se koristi u slučaju kada zahtev (HTTP Request) ne zahteva obradu od strane kontrolera, već ne dovoljno preusmeravanje ka određenom pogledu (View). Logičko ime pogleda se definiše atributom viewName.

http://localhost:8084/StudijskiPrimer/index.htm


49

Kreiranje forme

Potrebano je kreirati HTML formu koja će korisniku omogućiti da unese potrebne podatke i da pozove sistem da snimi unete podatke. Ukoliko korisnik uspešno pošalje unete podatke, kontroler komponenta je zadužena da pozove određenu poslovnu metodu koja treba da snimi prosleđene podatke u bazu.

Jedan od najkorisnijih i najčešće korišćenih kontrolera je klasa SimpleFormController.

Neki od najčešće korišćenih atributa klase SimpleFormController prikazani su u sledećoj tabeli.

Tag Opis

formView

Ime komponente prikaza (View) koja sadrži formu koju je potrebno prikazati korisniku.

succesView

Ime komponente prikaza (View) koja će biti prikazana korisniku nakon uspešne obrade forme.

commandName

Logičko ime komandnog objekta. Podrazumevana vrednost ove osobine je „command“.

commandClass Klasa komandnog objekta.

validator(s)

Ovim atibutom definišu se reference ka bean-ovima koji vrše validaciju atributa komandnog objekta.

sessionForm

Određuje da li će komandni objekat biti sačuvan u sesiji u vremenu između prikaza i obrade forme. Podrazumevana vrednost ovog atributa je false.

Tabela 5 : Atributi SimpleFormController klase

Proces obrade korisničkog zahteva korišćenjem klase SimpleFormController može

logički da se podeli u dva koraka. Prvi korak je prikazivanje odgovarajuće forme korisniku, a drugi obrada zahteva nakon potvrđivanja (submission) forme. Ovo razdvajanje postiže se različitim tretiranjem HTTP GET i HTTP POST zahteva. Kontroler koristi metodu isFormSubmission() da bi

odredio da li treba da prikaže formu, ili da obradi zahtev nakon potvrđivnja forme. Ova metoda jednostavno ispituje HTTP metod, i ukoliko je metod GET, prikazuje formu, a ukoliko je metod POST, vrši obradu potvđene forme.

Najčešće korišćene metode klase SimpleFormController su: formBackingObject(),

referenceData(), doSubmitAction() i onSubmit() metoda, koja ima nekoliko

preklopljenih (overloaded) varijanti.

Podrazumevana implementacija formBackingObject() metode jednostavno kreira

komandni objekat koji je definisan commandClass atributom. Na ovaj način dobija se komandni

objekat čiji su atributi postavljeni na podrazumevane vrednosti (vrednosti koje su defnisane u konstruktoru klase komandnog bean-a). Ova metoda se poziva pre prikaza forme, kako bi atributi


50

komandnog objekta bili povezani sa odgovarajućim poljima za unos na formi. Prekrivanjem29 (overriding) ove metode moguće je na drugačiji način izvšiti kreiranje komandnog objekta i postavljanje vrednosti njegovih atributa. Na primer, atribute komandnog objekta je moguće inicijalizovati vrednostima učitanim iz baze podataka.

Često je na formi potrebno, pored polja za unos, prikazati i određene podatke u obliku, na primer, padajućih lista, koje omogućavaju korisniku da izabere neku od ponuđenih vrednosti. Na primer, ukoliko se forma odnosi na unos podataka o osobi, padajuća lista može da sadrži vrednosti za pol osobe (“muški” i “ženski”), od kojih je potrebno izabrati jednu vrednost. Priprema podataka koji će na ovaj način biti prikazani na formi vrši se unutar referenceData() metode. Svi podaci

koje ova metoda vrati (metoda vraća java.util.Map) pridodaju se model komponenti i na taj

način postaju dostupni u JSP strani.

Nakon potvrđivanja forme, poziva se doSubmitAction() metoda, ili neka od onSubmit()

metoda, u zavisnosti koja je metoda prekrivena u kontroleru. U najvećem broju slučajeva dovoljno je prekrivanje doSubmitAction() metode. Ova metoda kao parametar prihvata komandni objekat,

a po izvršenju ove metode model se automatski prosleđuje na pripremu (render) onom pogledu (view) koji je definisan succesView atributom kontolera.

Ukoliko je potrebno dinamički odrediti koji će pogled biti prikazan korisniku nakon potvrđivnja forme, potrebno je prekriti neku od onSubmit() metoda, čija je povratna vrednost

objekat klase ModelAndView. onSubmit() metode se razlikuju po broju parametara i, u suštini,

svaka od njih poziva sledeću metodu sa manjim brojem parametara. Na sledećoj slici (Slika 14) prikazane su različite onSubmit() metode, kao i doSubmitAction() metoda i način njihovog

međusobnog pozivanja.

Slika 14 : Redosled pozivanja onSubmit() metoda

29 prekrivanje metoda – overriding: mogućnost da se u nadklasi i u podklasi deklariše metoda koja se isto zove, ima isti potpis kao i tip koji vraća, a da im se implementacije razlikuju.


51

U našem primeru, radi jednostavnosti30, prekrivena je metoda doSubmitAction(). U

sledećem listingu dat je prikaz dela klase ProgramerController.

public class ProgramerController extends SimpleFormController {

private ProgramerServis programerServis;

@Override

protected void doSubmitAction(Object command) throws Exception {

programerServis.snimi((Programer)command);

}

public ProgramerServis getProgramerServis() {

return programerServis;

}

public void setProgramerServis(ProgramerServis programerServis) {

this.programerServis = programerServis;

}

}

Kao što se vidi iz datog listinga, metoda doSubmitAction() će kao argument da primi

komandni objekat koji se nakon konverzije u objekat klase Programer prosleđuje poslovnoj metodi

snimi()koja treba da omogući snimanje prosleđenog objekta u bazu.

Nakon kreiranja ProgramerController klase, potrebno je izvršiti definiciju bean-a unutar

dispatcher-servler.xml konfiguracione datoteke. Prikaz ove konfiguracije dat je sledećim listingom.

<bean id="urlMapping"



<props>


<prop key="unosProgramera.htm">unosProgramera</prop>

</props>

</property>

</bean>

<bean name="unosProgramera" class="web.kontroler.ProgramerController">

<property name="formView" value="unosProgramera"/>

<property name="successView" value="uspesanUnos"/>

<property name="commandName" value="programer"/>

<property name="commandClass" value="domen.Programer"/>

<property name="programerServis" ref="programerServis"/>

</bean>

30 Podrazumeva se da će poslovna metoda uspešno da se izvrši, bez ulaska u obradu eventualnih grešaka koje mogu da nastanu.


52

Na ovaj način kreirano je pojavljivanje klase ProgramerController. Pored definicije ovog

bean-a, izvršena je i definicija preslikavanja URL adrese unosProgramera.htm ka ovom kontroleru. Atributi formView i succesView postavljeni su tako da se prilikom poziva ovog kontrolera prikaže

pogled sa logičkim imenom unosProgramera, dok se po završetku izvršenja doSubmitAction()

metode korisniku prikazuje pogled sa logičkim imenom uspesanUnos.

Nakon kreiranja kontrolera, i njegovog konfigurisanja, potrebno je kreirati formu koja će se koristiti za unos podataka. Forma je kreirana u okviru JSP strane unosProgramera.jsp koja se smeštena u WEB-INF\jsp direktorijumu.

Preslikavanje zahteva (HTTP Request) vrši se pomoću klase SimpleUrlHandlerMapping.

Mappings atributom ove klase definisano je da svi zahtevi sa URL adresom

http://localhost:8084/StudijskiPrimer/unosProgramera.htm budu delegirani kontroler bean-u sa imenom „unosProgramera“ , koji predstavlja pojavljivanje klase ProgramerController.

Preslikavanje logičkih imena pogleda ka stvarnim implementacijama vrši se pomoću klase InternalResourceViewResolver. Na taj način obezbeđeno je da se logička imena pogleda

definisana formView i succesView atributima kontrolera preslikaju ka odgovarajućim JSP

stranama smeštenim u WEB-INF\jsp direktorijumu.

Definicija bean-a za preslikavanje logičkih imena pogleda u dispatcher-servlet.xml datoteci prikazana je na sledećem listingu.

<bean id="viewResolver"

class="org.springframework.web.servlet.view.InternalResourceViewResolver"

p:prefix="/WEB-INF/jsp/"

p:suffix=".jsp"

p:viewClass="org.springframework.web.servlet.view.JstlView"/>

Na ovaj način obezbeđeno je potpuno razdvajanje logičkih imena pogleda od njihovih stvarnih realizacija, tako da ova klasa obezbeđuje da se, u našem primeru, logičko ime defnisano formView atributom („unosProgramera“) preslika ka /WEB-INF/jsp/unosProgramera.jsp stranici, a

logičko ime definisano successView atributom („uspesanUnos“) ka /WEB-INF/jsp/uspesanUnos.jsp

stranici.

Sada je moguće kreirati i samu JSP stranicu unosProgramera.jsp31.

<%@taglib prefix="form" uri="http://www.springframework.org/tags/form" %>

<%@page contentType="text/html;charset=windows-1250" %>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

31 JSP strana unosProgramera.jsp sadrži samo elemente koji su neophodni za pripremu (render) forme za unos podataka o programeru, dok je sadržaj JSP strana koje pripremaju zaglavlje (header) i podnožje (footer) stranice uključen na odgovarajućim mestima korišćenjem include JSP direktive. Include direktivom se u vreme prevođenja JSP strane sadržaj strane koja je navedena u file atributu direktive dodaje sadržaju tekuće JSP strane.

http://localhost:8084/StudijskiPrimer/unosProgramera.htm


53

"http://www.w3.org/TR/html4/loose.dtd">

<html>

<%@ include file="/WEB-INF/jsp/include/head.jsp" %>

<body>

<div class="page-container">

<%@ include file="/WEB-INF/jsp/include/navigation.jsp" %>

<div class="main">

<div class="main-content">

<h1 class="block">Programer</h1>

<form:form cssClass="contactform" method="POST" commandName="programer">

<form:errors cssClass="error" path="*"/>

<fieldset style="margin-top:15px;"><legend> Podaci

prijavi </legend>

<p><label for="username" class="left">Korisničko Ime:</label>

<form:input cssClass="field" id="username" path="korisnickoIme"

tabindex="1"/> *</p>

<p><label for="password" class="left">Lozinka:</label>

<form:password cssClass="field" id="password" path="lozinka" tabindex="2"

/> *</p>

</fieldset>

<fieldset style="margin-top:15px;"><legend> Ostali

podaci </legend>

<p><label for="firstName" class="left">Ime:</label>

<form:input cssClass="field" id="firstName" path="ime"


<p><label for="familyName" class="left">Prezime:</label>

<form:input cssClass="field" id="familyName" path="prezime"


<p><label for="email" class="left">Email:</label>

<form:input cssClass="field" id="email" path="email"


<p><label for="position" class="left">Pozicija:</label>

<form:input cssClass="field" id="position" path="pozicija"


</fieldset>

<p><input type="submit" name="submit" id="submit" class="button"

value="Sačuvaj >>" tabindex="7" /></p>

</form:form>

</div>

</div>

<%@ include file="/WEB-INF/jsp/include/footer_inc.jsp" %>

</div>

</body>

</html>

Počev od verzije 2.0. Spring okvir se isporučuje sa implementiranom bibliotekom koja omogućava pripremu (render) elementa forme. Ova komponenta sadrži odgovarajuće tagove i može da se koristi prilikom kreiranja JSP strana. Svaki tag podržava skup atributa i omogućava pripremu odgovarajuće HTML komponente. Dobijeni HTML dokument je u skladu sa HTML 4.01/XTML 1.0


54

specifikacijom. Ova biblioteka nalazi se u datoteci Spring.jar. TLD datoteka koja opisuje biblioteku se naziva spring-form.tld. Ukoliko je potrebno koristiti tagove iz biblioteke, potrebno je dodati sledeću JSP direktivu32 na početku JSP stanice:

<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>

Nakon kreiranja kontrolera i odgovarajuće JSP strane koja sadrži formu, ukoliko se ukuca http://localhost:8084/StudijskiPrimer/unosProgramera.htm u Web čitaču, dobićemo kao rezultat formu za unos podataka o programeru prikazanu na sledećoj slici.

Slika 15 : Prikaz forme za unos programera

Nakon potvrđivanja forme pritiskom na dugme Snimi, korisniku će biti prikazan pogled koji je definisan successView atributom SimpleFormController klase (u ovom slučaju to je

uspesanUnos).

32 JSP direktiva je izraz koji daje JSP mehanizmu informacije o JSP strani koja treba da se obradi. Generalna sintaksa JSP direktive je: <%@direktiva {atribut=“vrednost“}"%>. Moguće direktive su: page, include i taglib. Taglib direktivom navodi se URI za bibilioteku tagova koja će se koristiti u okviru JSP strane.

http://localhost:8084/StudijskiPrimer/unosProgramera.htm


55

Slika 16 : Prikaz poruke o uspešnom snimanju programera

Validacija podataka

Spring okvir obezbeđuje validaciju podataka u vidu Validator interfejsa. Da bi se izvršila

validacija unetih podaka o programeru kreirana je implementacija ovog interfejsa. Dajemo prikaz dela ove klase:

package web.validator;

import java.util.regex.Pattern;

import org.springframework.validation.Errors;

import org.springframework.validation.ValidationUtils;

import org.springframework.validation.Validator;

import domen.Programer;

/**

*

* @author Goran

*/

public class ProgramerValidator implements Validator {

private final Pattern pattern = Pattern.compile(".+@.+\\.[a-z]+");

public boolean supports(Class clazz) {

return Programer.class.isAssignableFrom(clazz);

}

public void validate(Object target, Errors errors) {

ValidationUtils.rejectIfEmptyOrWhitespace(errors, "korisnickoIme",

"input.usernameEmpty", "Morate da unesete Korisnicko Ime");


56

ValidationUtils.rejectIfEmptyOrWhitespace(errors, "lozinka",

"input.passwordEmpty", "Morate da unesete Lozinku!");

ValidationUtils.rejectIfEmptyOrWhitespace(errors, "email",

"input.emailEmpty", "Morate da unesete Email!");

ValidationUtils.rejectIfEmptyOrWhitespace(errors, "ime",

"input.firstNameEmpty", "Morate da unesete Ime!");

ValidationUtils.rejectIfEmptyOrWhitespace(errors, "prezime",

"input.familyNameEmpty", "Morate da unesete Prezime!");

ValidationUtils.rejectIfEmptyOrWhitespace(errors, "pozicija",

"input.positionEmpty", "Morate da unesete Poziciju!");

Programer d = (Programer) target;

if (!d.getEmail().isEmpty()) {

if (!pattern.matcher(d.getEmail()).matches()) {

errors.rejectValue("email", "inputErr.emailFormat",

"Nepravilan unos email adrese!");

}

}

}

}

}

Prilikom realizacije Validator interfejsa potrebno je implementirati dve metode:

supports() i validate(). supports() metodom definiše se klasa nad kojom se vrši validacija, a

u okviru validate() metode vrši se konkretna validacija. Za specifikaciju grešaka prilikom

validacije korisiti se Errors objekat koji se prosleđuje validate() metodi. Errors klasa definiše

nekoliko metoda, od kojih se u najvećem broju slučajeva koriste metode reject () i

rejectValue(). U našem primeru korišćena je metoda rejectValue() koja ima sledeći potpis.

void rejectValue(String field, String errorCode, String defaultMessage)

Definisani parametri metode imaju sledeće značenje:

o field: predstavlja atribut (property) objekta čiju validaciju vršimo. Vrednost ovog

parametra može biti null ili prazan String, pri čemu se ukazuje na ceo objekat a

ne na neko specifično polje; o errorCode: predstavlja identifikator (ključ) koji se koristi za pronalaženje

odgovarajuće poruke u resursnoj datoteci za definisanje osobina (resource bundle); o defalutMessage: koristi se za specifikaciju podrazumevane poruke

Spring okvir poseduje klasu ValidationUtils, koja sadrži nekoliko korisnih metoda koje

mogu da se koriste prilikom validacije. Ova klasa omogućava jednostavnu proveru praznih polja preko metoda rejectIfEmpty() i rejectIfEmptyOrWhitespace().

Da bi bilo omogućeno čitanje poruka o nastalim greškama prilikom validacije iz resursnih datoteka (resource bundle) na osnovu identifikatora, potrebno je definisati bean koji će omogućiti


57

korišćenje ovih poruka, kao i odgovarajuću datoteku sa ekstenzijom .properties u unutar WEB-

INF\classes direktorijuma.

Nakon kreiranja datoteke, potrebno je definisati bean pod imenom „messageSource“. U ovom slučaju korišćena je klasa ResourceBundleMessageSource. Sledi prikaz definicije ovog

bean-a:

<bean id="messageSource"

class="org.springframework.context.support.ResourceBundleMessageSource">

<property name="basename" value="poruke"/>

</bean>

Spring okvir podržava izvorni ASCII33 format datoteka, tako da se Unicode34 podrška obezbeđuje korišćenjem escape sekvenci. Pomoću escape sekvenci moguće je predstaviti sve Unicode karaktere. Escape sekvence predstavljaju se heksadecimalnim brojem, u formi „\uXXXX16”. Ukoliko resursne datoteke za definisanje osobina (resource bundle) sadrže karaktere koji nisu u skupu ASCII karaktera moguće ih je konvertovati korišćenjem native2ascii aplikacije koje se isporučuje uz Java SDK. Ova aplikacija nalazi se u {$JAVA_HOME}/bin direktorijumu. U sledećem listingu dat je sadržaj datoteke poruke.properties nakon obrade pomoću native2ascii programa:

inputErr.postojeciUsername=Korisni\u010Dko ime koje ste uneli ve\u0107

postoji!

input.usernameEmpty=Morate da unesete Korisni\u010Dko Ime!

input.passwordEmpty=Morate da unesete Lozinku!

input.emailEmpty=Morate da unesete Email!

input.imeEmpty=Morate da unesete Ime!

input.prezimeEmpty=Morate da unesete Prezime!

input.positionEmpty=Morate da unesete Poziciju!

Nakon kreiranja ProgramerValidator klase, u dispatcher-servlet.xml datoteci je potrebno

definisati validator bean, a zatim i izmeniti definiciju kontroler bean-a unosProgramera dodajući

mu referencu na kreirani validator bean, kao što je prikazano sledećim listingom:

<bean name="unosProgramera" class="web.kontroler.ProgramerController">

<property name="formView" value="unosProgramera"/>

<property name="successView" value="uspesanUnos"/>

<property name="commandName" value="programer"/>

<property name="commandClass" value="domen.Programer"/>

<property name="programerServis" ref="programerServis"/>

<property name="validator" ref="programerValidator">

</bean>

<bean id="programerValidator" class="web.validator.ProgramerValidator"/>

33 American Standard Code for Information Interchange (ASCII) - sedmobitni kod kojim se predstavalja skup karaktera (character set) engleskog alfabeta, kao i skupa upravljačkih znakova. 34 Unicode predstavalja standard kojim se definiše skup karaktera (character set) koji obuhvata karaktere većine svetskih pisama, kao i neke tehničke karaktere. Opseg Unicode kodova nalazi se između U+000016 i U+10FFFF16.


58

Uključivanjem validacije podatka u ovom primeru obezbeđuje se da korisnik unese vrednosti za sva polja koja su obavezna, kao i da unese e-mail adresu u odgovarajućem formatu. Ukoliko ovo nije ispunjeno, prilikom validacije unetih podataka javlja se greška, zatim se korisniku ponovo prikazuje forma za unos podataka, ali ovaj put zajedno sa prikazom grešaka koje su nastale tokom validacije. Ovaj postupak se ponavalja sve do trenutka kad se prilikom validacije ne pojavi ni jedna greška, nakon čega se poziva metoda doSubmitAction(), koja obrađuje korisnički zahtev

pozivajući poslovnu metodu koja snima unete podatke u bazu, nakon čega se korisniku prikazuje poruka da su podaci uspešno snimljeni.


59

3. HIBERNATE OKVIR

Perzistencija podataka predstavlja jedan od fundamentalnih koncepata u razvoju softverskih sistema. Uopšteno, podaci su perzistentni ukoliko nadžive program koji ih je kreirao. Postoji nekoliko definicija vezanih za perzistenciju podataka u kontekstu objektno orjentisanog razvoja softvera [8].

o Objekat je perzistentan ukoliko se može materijalizovati i dematerijalizovati. o Objekat je perzistentan ukoliko nastavi da postoji i nakon prestanka rada programa koji ga

je stvorio (G.Booch). o Materijalizacija predstavlja proces transformacije slogova baze podataka u objekte

programa. o Dematerijalizacija prestavlja proces transformacije objekta iz programa u slogove baze

podataka. o Perzistentni okvir je skup interfejsa i klasa koji omogućava perzistentnost objektima

različitih klasa. Najrasprostranjeniji oblik čuvanja podataka u današnjim aplikacijama jeste korišćenje

relacionih baza podataka, tako da se kod perzistencije podataka u Java aplikacijama najčešće podrazumeva čuvanje čuvanje Java objekata u relacionoj bazi podataka.

Relacione baze podataka postale su svojevrsni standard u domenu perzistencije podataka.

Razlozi tome su brojni, ali pre svega to je jednostavnost njihovog kreiranja i pristupa podacima u njima korišćenjem SQL-a, kao i jednostavnost strukture modela podataka – relacionog modela. Relacione baze podataka pružaju struktuiranu reprezenataciju podataka, u tabelarnom obliku, omogućavaju pristup i ažuriranje perzistentnih podataka, i obezbeđuju čuvanje integriteta podataka. Takođe, obezbeđuju konkurentnost pristupa podacima, kao i deljenje podataka od strane različitih korisnika i aplikacija.

U objektno orjentisanim aplikacijama perzistencija treba da omogući čuvanje objekata u relacionoj bazi podataka. Pri tome se ne misli samo na čuvanje pojedinačnih objekata, već cele mreže uzajamno povezanih objekata, koja reprezentuje određeni objektni model. Pored obekata koji se trajno čuvaju, u objektno orjentisanim aplikacijam postoji i veliki broj tzv. transijentnih objekata. Transijentni objekti su objekti čije je trajanje ograničeno trajanjem aplikacije koja ih je kreirala. Najčešće u ovakvim aplikacijama postoji podsistem koji treba da obezbedi materijalizaciju i dematerijalizaciju perzistentnih objekata, tj. njihovu transformaciju u oblik pogodan za čuvanje u relacionim bazama podataka – relacioni model. Dakle, perzistentnost u objektno orjentisanim aplikacijama koje koriste relacionu bazu podataka možemo posmatrati kao proces transformacije objektnog modela u relacioni model i obratno.


60

3.1. OSOBINE OBJEKTNOG I RELACIONOG MODELA

Objektni model

U objektnom modelu, objekat se definiše kao entitet koji je sposoban da čuva svoja stanja i koji okolini stavlja na raspolaganje skup operacija preko kojih se tim stanjima pristupa. Stanje objekta predstavlja se vrednostima njegovih osobina: atributa objekta, i njegovih veza sa drugim objektima u sistemu[10]. Danas je u razvoju aplikacija preovladao tzv. objektno orjentisani pristup, te se za razvoj aplikacija koriste programski jezici bazirani na korišćenju objektnog modela.

U osnovi svih tih jezika nalazi se koncept klase. Klasa se definiše kao apstrktna predstava skupa objekata koji imaju iste osobine. Na ovaj način se u objektnom modelu postiže tipizacija, tj. klasifikacija, kao osnovna apstrakcija podataka. Klasa se sastoji od atributa i metoda. Atributima se definiše stanje, a metodama ponašanje klase. Objekat predstavlja jedno konkretno pojavljivanje svoje klase.[ 3]

Pored klasifikacije, objektni model podržava i generalizaciju – apstrakciju u kojoj se skup sličnih tipova, tj. klasa objekata predstavlja opštijim generičkim tipom, tj. nadtipom. Za različite klase objekata kaže se da su slične ako imaju neke zajedničke osobine i ponašanje.

Takođe, objektni model podržava i agregaciju – apstrakciju podataka kojom se skup postojećih objekata i njihovih međusobnih veza predstavlja novim, jedinstvenim – agregiranim tipom. Agregirani objekat kao svoje komponente ima objekte koji čine agregaciju, a može kao celina da ima i svoje sopstvene atribute, i kao celina može da stupa u vezu sa drugim objektima u modelu.

Pored navedenih apstrakcija, objektni model podržava i koncept učaurenja (encapsulation), kojim se stanje objekta učuruje, i na taj način se drugim objektima u sistemu stavlja na raspolaganje skup operacija kojima se može promeniti stanje objekta. Na taj način skrivaju se detalji implementacije stanja objekata, i omogućava promena stanja objekata od strane drugih objekata u sistemu, a da pri tome objekti iz okruženja ne poznaju samu implementaciju stanja objekata koji menjaju. Na ovaj način postiže se veći stepen nezavisnosti između različitih komponenti sistema koje su međusobno povezane, jer se izmenom implementacije jednog stanja objekta ne zahteva izmena objekata koji su sa tim objektom povezani.

Kombinacijom navedenih osobina koje podržava objektni model dobija se mogućnost kreiranja moćnih mehanizama koji objektnom modelu daju prednost prilikom razvoja poslovnih aplikacija u odnosu na druge modele. Tu se pre svega misli na sledeće koncepte: preklapanje metoda (overloading), prekrivanje metoda(overriding), kompatibilnost objektnih tipova, kasno povezivanje metoda35 , polimorfizam, apstraktne klase, interfejsi, itd.

35 Late binding – kasno povezivanje metoda: svojstvo koje imaju tzv. virtualne metode – metode koje se povezuju sa objektom koji ih je pozvao u vrjeme izvršenja programa, za razliku od običnih metoda koje se povezuju sa objektom u vrjeme kompajliranja. Predstavlja jedan od preduslova za stvaranje jakog polimorfizma. U programskom jeziku Java, sve metode su virtualne.


61

Relacioni model

U relacionom modelu sistem se predstavlja preko skupa relacija. Relacija se može predstaviti kao tabela, gde su kolone atributi relacije, a vrste n-torke relacije. Jedan ili više atributa relacije jedinstveno identifikuju jednu n-torku u relaciji, i taj skup atributa se naziva primarni ključ relacije. Relacioni model je vrednosno orjentisan, i veze se u njemu ostvaruju preko vrednosti atributa na taj način što se primarni ključ neke relacije pojavljuje kao atribut neke druge relacije koji tada postaje tzv. spoljni ključ. Tada se preko vrednosti tog atributa može uspostaviti veza između n-torki te dve relacije.

Grupisanjem atributa u relaciju postiže se tipizacija, tj. klasifikacija, kao osnovna apstrakcija podataka. Relacija se u modelu predstavlja tako što se ime relacije piše ispred zagrada u kojima se nalaze atributi koji čine relaciju. Primarni ključ relacije obeležava se podvlačenjem atributa koji ga čine.

NazivRelacije (id_relacije, atribut_1, atribut_2, ... , atribut_n)

Preko vrednosti atributa relacija u relacionom modelu moguće je ostvariti i generalizaciju, odnosno, specijalizaciju podataka. Ovo se postiže tako što se primarni ključ relacije koja je nadtip prikazuje takođe kao primarni ključ relacije koja je podtip. Bitno je naglasiti da je efekat generalizacije, tj. specijalizacije samo prividan, jer se posmatranjem relacija ni po čemu ne može zaključiti da je neka relacija nadtip, odnosno podtip neke druge relacije. Iz toga može da se zaključi da relacioni model ne podržava apstrakciju generalizacije.

Efekat agregacije takođe može da se postigne preko vrednosti atributa. Agregirana relacija će u tom slučaju kao skup atributa koji čine njen primarni ključ sadržati primarne ključeve relacija koje čine agregaciju, a pored toga može da sadrži i neke sopstvene atribute, jer se agregirana relacija posmatra kao svaka druga relacija u sistemu. Kao i kod generalizacije, ni za agregiranu relaciju u relacionom modelu ni po čemu se ne može zaključiti da predstavlja agregaciju dve ili više postojećih relacija, te se može zaključiti da relacioni model ne podržava ni apstrakciju agregacije.

Korišćenjem SQL-a, standardnog jezika relacionih sistema za upravljanje bazama podataka, na osnovu relacionog modela, kreiraju se tabele, skup ograničenja, kao i dinamička pravila integriteta. Nakon toga moguće je izvršavati SQL upite kojima se manipuliše nad podacima u relacionoj bazi podataka. Osnovne četiri operacije nad podacima su Create, Read, Update i Delete, koje se skraćeno zovu CRUD operacije.

3.2. PROBLEM TRANSFORMACIJE IZMEĐU MODELA

U objektno orjentisanim aplikacijama perzistencija treba da omogući čuvanje objekata u relacionoj bazi podataka, pri čemu se podaci transformišu iz objektnog u relacioni model. Kako su ovi modeli različiti, postoji čitav niz nepodudaranja koje je neophodno prevazići kako bi proces transformacije bio moguć. Ova nepodudaranja proističu iz različite namene ovih modela. Relacioni


62

model se koristi u relacionim bazama podataka, čija je osnovna namena čuvanja podataka, dok se objektni model koristi u objektno orjentisanim aplikacijama koje imaju za cilj modelovanje poslovnih problema. Prevazilaženje razlika između ova dva modela predmet je mnogih radova, a u literaturi se oblast koja se tiče ovog problema naziva object/relational impedance mismatch, ili samo impedance mismatch.

Ključne razlike između relacionog i objektnog modela, koje čine osnovu problema transformacije biće prikazane u nastavku.

3.2.1. Koncept nasleđivanja

Jedan od najvažnijih koncepata objektnog modela jeste mogućnost da jedan objekat nasledi i proširi osobine nekog drugog objekta. Kao što je već rečeno, relacioni model ne podržava koncept nasleđivanja, prema tome problem transformacije svodi se na prevođenje hijerarhije objekata u niz relacija. Ukoliko u objektnom modelu ne bi postojala hijerarhija, ovog problema ne bi ni bilo, međutim, kako objektno orjentisane aplikacije modeluju realne poslovne procese, tada se koncept nasleđivanja nameće kao najbolji način za precizno definisanje objektnog modela. Na taj način obezbeđuje se fleksibilnost softverskog sistema, što mu omogućava da isprati eventualne promene u poslovnom sistemu. Dakle, ukoliko se iskoristi ova prednost objektnog modela prilikom projektovanja, neophodno je realizovati i mehanizme koji će transformisati hijerarhiju objekata u relacije tako da se postigne efekat specijalizacije, odnosno, generalizacije u relacionom modelu.

3.2.2. Koncept identiteta

Kada se govori o identitetu objekata potrebno je razdvojiti postojanje objekta kao reference i vrednosti objekta. Objekat postoji nezavisno od svoje vrednosti. U tom kontekstu, u Java programskom jeziku poređenje objekata se vrši na dva načina:

objekat1==objekat2, i

objekat1.equals(objekat2).

Na prvi način porede se reference dva objekta, i ukoliko su refernece jednake znači da se radi o istom objektu. Na drugi način porede se vrednosti koje objekti sadrže, što znači da objekti mogu da budu jednaki iako su im reference različite. Reference na objekat identifikuju i tip objekta, jer objekat može da dobije referencu na objekat iste klase ili klase koja je izvedena iz klase referentnog tipa. Veze između objekata ostvaruju se tako što jedan objekat sadrži referencu na drugi objekat. Preko ove reference saznaje se kog je tipa objekat sa kojim se uspostavlja veza. Takođe, preko ove reference pristupa se vrednostima atributa referenciranog objekta.


63

U relacionom modelu, jedini identifikator svake n-torke jeste vrednost koja se nalazi u ćeliji koja predstavlja primarni ključ relacije. Zato se za svaki objekat iz objektnog modela, prilikom transformacije u relacioni model, određuje atribut koji će ga jedinstveno identifikovati (primarni ključ relacije), i koji će prlikom povezivanja relacija igrati ulogu reference u relaciji sa kojom se vrši povezivanja (spoljni ključ).

3.2.3. Asocijacije

Problem asocijacija odnosi se na transformacije veza koje se uspostavljaju između objekata u objektnom modelu i veza koje se ostvaruju između relacija u relacionom modelu. U relacionom modelu veze se ostvaruju korišćenjem spoljnih ključeva, tj. spoljni ključ u referentnoj tabeli predstavlja primarni ključ u referenciranoj tabeli. U objektnom modelu postoji nekoliko vrsta asocijacija: 1-1 (one-to-one), * - * (many-to-many), 1 - * (one-to-many). Ove asocijacije je u relacionom modelu potrebno obezbediti korišćenjem spoljnih ključeva.

one-to-one Najčešće se transformacija vrši na taj način što se oba objekta predstavljaju jednom relacijom. Na taj način podaci jednog objekta proširuju se podacima drugog objekta i postaju jedinstvena relacija. Atributi relacije postaju atributi i jednog i drugog objekta.

one-to-many Kada jedan objekat pravi vezu sa više objekata nekog tipa, tada se transformacija vrši tako što se naprave posebne relacije za svaki od tipova objekata, a zatim se primarni ključ objekta koji pravi vezu pamti kod svih objekata sa kojima je on u vezi, tj. primarni ključ relacije na strani one predstavlja se kao spoljni ključ relacije na strani many.

many-to-many Transformacija se vrši na taj način što se pored relacija koje se prave za svaki od tipova objekata pravi i dodatna agregirajuća relacija koju čine primarni ključevi relacija koje stupaju u vezu.

3.2.4. Struktura i ponašanje

Relacioni model kao interfejs prema okruženju koristi podatke, odnosno, interfejs predstavlja struktura relacije, dok interfejs objektnog modela čini ponašanje objekta izraženo preko javnih metoda koje predstavljaju servise koje neki objekat pruža. Konceptom učaurenja postiže se potpuno sakrivanje strukture objekta.


64

Proces transformacije objektnog u relacioni model i obratno treba da omogući preslikavanje atributa objekata koji čine njegovu strukturu u atribute relacije. Kako koncept interfejsa u objektnom modelu ne podrazumeva direktan pristup njegovim atributima, potrebno je napraviti vezu između atributa relacije i metode objekta koja obezbeđuje pristup odgovarajućem atributu tog objekta.

3.3. JDBC

Rad sa relacionim bazama podataka u Java programskom jeziku omogućen je korišćenjem JDBC-a. JDBC predstavlja tehnologiju kojom se omogućava uspostavljanje konekcije sa različitim sistemima za upravljanje bazama podataka, kao i izvršavanje SQL upita preko kojih aplikacija manipuliše podacima u bazi podtaka. JDBC je nezavisan od platforme na kojoj se izvršava, odnosno sistema za upravljanje bazom podataka sa kojom komunicira, tako da tokom programiranja nije potrebno voditi računa koji sistem za upravljanje bazom podataka će biti korišćen.

Prenosivost Java aplikacija u odnosu na različite sisteme za upravljanje bazama podataka postiže se korišćenjem upravljačkih programa - drajvera, koji se učitavaju u Java program pre uspostavljanja konekcije sa odabranim sistemom za upravljanje bazom podataka. Nakon toga koristi se klasa DriverManager, koja je zadužena za upravljanje drajverima, odnosno za uspostavljanje konekcije sa bazom podataka.

Komunikacija Java programa sa sistemom za upravljanje bazom podataka preko JDBC-a može da bude realizovana preko dve arhitekture. Prva arhitektura podrazumeva da se drajver povezuje sa odabranim sistemom za upravljanje bazom podataka, nakon čega se izvršava neka SQL naredba. Rezultati upita se do aplikacije prosleđuju posredstvom drajvera. U drugom slučaju, JDBC drajver se povezuje sa ODBC drajverom. ODBC drajver je zadužen za izvršenje SQL naredbi, nakon čega rezultate šalje do JDBC drajvera koji ih prosleđuje do aplikacije.

JDBC je kreiran tako da omogućava što jednostavniji interfejs prema servisima koje pruža. Za svaku logičku operaciju koju je potrebno obaviti prilikom rada sa bazom podataka (povezivanje, pravljenje naredbe, izvršavanje upita i pregled rezultata) obezbeđuje posebne klase, i u njima odgovarajuće metode. Sledećom slikom prikazan je odnos različitih klasa koje učestvuju u procesu izvršavanja operacija nad bazom podataka.

Slika 17 : Klase koje učestvuju u komunikaciji sa bazom podataka


65

Postupak komunikacije Java aplikacije i SUBP-a korišćenjem JDBC-a odvija se u nekoliko koraka:

1. Uvoz neophodnih klasa 2. Učitavanje JDBC drajvera 3. Identifikacija izvora podataka 4. Pravljenje objekta klase Connection 5. Pravljenje objekta klase Statement 6. Izvršavanje upita pomoću objekta klase Statement 7. Dobijanje podataka kao rezultata upita koristeći objekat klase ResultSet 8. Zatvaranje ResultSet-a 9. Zatvaranje objekta klase Statement 10. Zatvaranje objekta klase Connection

Direktno korišćenje JDBC-a zahteva od programera pisanje velikog broja linija programskog

kôda kojim se obezbeđuje transformacija objektnog u relacioni model, i obratno. Transformaciju je neophodno izvršiti prilikom svake operacije, prilikom operacije kreiranja, menjanja, ili brisanja. Najjednostavnije posmatranao, ukoliko je potrebno snimiti jedan objekat neke klase, čiji se atributi poklapaju sa kolonama u odgovarajućoj tabeli baze podataka, pri čemu objekat nema asocijacije sa drugim objektima sistema, neophodno je transformisati dati objekat u odgovarajuću SQL naredbu. Prilikom čitanja ovakvog objekta iz baze neophodno je izvršiti transformaciju rezultata SQL upita u odgovarajući objekat, odnosno listu objekata. Problem transformacije višestruko se komplikuje u slučaju kada ja objekat složen, odnosno kada kao atribute ima reference na druge objekte. U ovom slučaju neophodno je vršiti transformaciju i referenciranih objekata, čime se značajno povećava količina potrebnog koda za perzistenciju. Ovakav oblik obezbeđenja perzistencije u potpunosti se oslanja na strukturu samih objekata, što predstavlja značajan nedostatak, jer svaka izmena u strukturi objekata, ili relacija uslovljava izmenu kôda kojim se vrše transformacija između modela. Na taj način smanjuje se fleksibilnost sistema i usložnjava njegovo održavanje.

3.4. ORM ALATI - KLASIFIKACIJA

Prethodno opisan problem tranformacije između relacionog i objektnog modela predmet je velikog broja radova. Kao rešenje koje omogućava automatizaciju ovog procesa razvijeni su alati za objektno-relaciono preslikavanje. Pod ORM36 alatom podrazumeva se svako softversko rešenje koje obezbeđuje automatsko generisanje SQL upita na osnovu pripremljenih meta-podataka, a koje ne zahteva od programera direktno korišćenje JDBC-a. Na ovaj način programer je rasterećen pisanja onog dela programskod kôda koji se tiče transformacije između relacionog i objektnog modela, jer ORM alat nudi odgovarajući API koji programeru omogućava rad sa objektima, dok se generisanje i izvršavanje SQL naredbi vrši automatski, od strane ORM alata.

36 ORM (Object-Relational Mapping)- Objektno-Relaciono Preslikavanje


66

Pored automatizacije procesa perzistencije objekata, postojeći ORM alati obezbeđuju niz dodatnih funkcionalnosti koje omogućavaju rešavanje problema vezanih za perzistencioni sloj aplikacije. Na osnovu funkcionalnosti koje alati pružaju, moguće ih je svrstati u jednu od četiri kategorije [11]:

Svrstavanjem određenog ORM alata u neku od navedenih kategorija ne ističe se superirornost, odnosno inferiornost alata u odnosu na alate iz drugih kategorija, već se naglašava potreba da se prilikom izbora alata koji će se koristiti prilikom razvoja aplikacije izabere onaj ORM alat čije karakteristike na najbolji način mogu da zadovolje potrebe specifične situacije. Ukoliko je domenski model aplikacije obiman, pri čemu se koristi nasleđivanje, zatim, ako je potrebno obezbediti keširanje i optimizaciju punjenja objekata iz baze, kao najbolje rešenje nameće se

Pure relational

Cela aplikacija, uključujući i korisnički interfejs bazirana je na relacionom modelu i direktno se oslanja na SQL operacije. U ovakvim aplikacijama se najčešće deo aplikacione logike prebacuje u bazu podataka korišćenjem uskladištenih procedura. Ovaj pristup ima značajnih nedostataka, pre svega vezanih za održavanje i prenosivost, kao i slabe mogućnosti za ponovno korišćenje, ali i pored toga može biti pravo rešenje za jednostavne aplikacije.

Light object mapping

Entiteti su predstavljeni klasama koje se ručno preslikavaju u tabele baze podataka. SQL i JDBC kôd se takođe piše ručno, ali se od sloja poslovne logike sakriva korišćenjem softverskih paterna. I kod ovog pristupa često se sreće korišćenje uskladištenih procedura. Upotrebljava se kod aplikacija sa manjim brojem entiteta.

Medium object mapping

Aplikacija se projektuje na osnovu objektnog modela. SQL se automatski generiše korišćenjem kod generatora ili ga generiše perzistentni okvir tokom izvršenja. Perzistentni okvir podržava asocijacije između objekata, a upiti najčešće nisu kreirani korišćenjem SQL-a, već nekog objektno-orjentisanog jezika. Kod ovog pristupa izbegava se korišćenje uskladištenih procedura. Najčešće se koristi u aplikacijama srednje veličine. Većina postojećih ORM alata obezbjeđuje ovaj nivo funkcionalnosti.

Full object mapping

Ovakvi perzistentni okviri podržavaju sve mogućnosti objektog modela: kompoziciju, nasleđivanje, polimorfizam, i time pružaju mogućnost kreiranja bogatijeg domenskog modela. Ovakav pristup realizuje tzv. transparentnu perzistentnost, tj. klase iz domenskog modela ne moraju da nasleđuju neku određenu osnovnu klasu niti da implementiraju određeni interfejs čime se postiže nezavisnost domenskog modela od perzistentnog okvira. Takođe, mehanizmi keširanja i punjenja podataka iz baze u memoriju, koji mogu u znatnoj meri poboljšati performanse perzistentnog sloja, potpuno su ”nevidljivi” za aplikaciju. Postoje brojni komercijalni i open source perzistentni okviri koji obezbjeđuju ovaj nivo funkcionalnosti.


67

korišćenje full object mapping alata, dok je u slučaju aplikacija sa manjim brojem klasa domenskog modela prihvatljivo izabrati ORM alat iz drugih kategorija.

Među mnogobrojnim postojećim ORM alatima, tek nekoliko je steklo širu popularnost i praktičnu primenu. Kao najčešće korišćeni izdvajaju se Hibernate, iBatis i JPA. Među ova tri ORM alata postoje značajne razlike koje je potrebno razmotriti prilikom odabira odgovarajućeg alata za određenu aplikaciju. Ulazak u oblast analize razlika između pomenutih alata svakako prelazi van opsega ovog rada, fokus ovog rada je na Hibernate tehnologiji, kao i integraciji Hibernate perzistentnog okvira sa Spring okvirom.

3.5. ARHITEKTURA HIBERNATE OKVIRA

Hibernate okvir je veoma fleksibilan alat koji omogućava nekoliko različitih pristupa prilikom odabira servisa koje okvir pruža, a koji će se koristiti u razvoju aplikacije. Tri ključna servisa, odnosno komponente Hibernate okvira jesu: upravljanje konekcijama (Connection Management), upravljanje transakcijama (Transaction management) i objektno-relaciono preslikavanje (Object-Relational mapping). U zavisnosti od toga koje komponenete okvira se koriste u razvoju aplikacije, razlikuju se dve osnovne arhitekture, tzv. „Lite“ i „Full cream“ arhitektura.

Slika 18 : Arhitektura Hibernate okvira


68

Pod „Lite“ arhitekturom podrazumeva se korišćenje samo komponente za objektno-relaciono preslikavanje, a upravljanje transakcijama i obezbeđivanje JDBC konekcija je prepušteno aplikaciji.

„Full Cream“ arhitektura podrazumeva korišćenje sve tri komponente. Prikaz arhitekture Hibernate okvira dat je na slici 18.

3.6. KONFIGURISANJE OKVIRA

Hibernate, kao perzistentni okvir, može da komunicira sa velikim brojem različitih sistema za upravljanje bazama podataka (SUBP), i, takođe, može da se izvršava u različitim okruženjima – u okviru samostalnih37 (standalone) aplikacija, u okviru Web aplikacija, ili J2EE aplikacija. Ovakva prilagodljivost Hibernate-a različitim SUBP-ovima i okruženjima u kojima se izvršava zahteva različite načine konfigurisanja okvira. U poglavlju 4. Integracija Spring i Hibernate okvira, dat je prikaz konfiguracije Hibernate-a u okviru Web aplikacije dokumentovane u studijskom primeru. U ovom delu biće prikazan način kofigurisanja Hibernate okvira u okviru jednostavne, samostalne (standalone) aplikacije.

Bez obzira na okruženje i bazu podataka sa kojom komunicira aplikacija, konfigurisanje okvira može da se logički podeli u dve celine. U prvom delu obezbeđuju se konfiguracioni podaci koji su neophodni okviru da bi pristupio bazi podataka, a drugi deo čine konfiguracioni podaci kojima se obezbeđuje preslikavanje između perzistentnih klasa aplikacije i odgovarajućih tabela u relacionoj bazi podataka.

Centralna klasa pomoću koje se vrši konfigurisanje i pokretanje Hibernate okvira je klasa org.hibernate.cfg.Configuration. Kao što se može videti na sledećoj slici (Slika 19), prilikom

kreiranja, ovoj klasi je potrebno obezbediti konfiguracione podatke, na osnovu kojih Configuration objekat kreira jedno pojavljivanje (singleton) klase SessionFactory. Jedno

pojavljivanje SessionFactory klase, u suštini predstavlja potpuno konfigurisan Hibernate okvir

koji omogućava komunikaciju sa jednom bazom podataka. Pored toga što Configuration objekat

kreira jedinstveno (singleton) pojavljivanje SessionFactory klase, stanje ovog objekta nije

moguće menjati nakon kreiranja38. Naziv klase SessionFactory upućuje na njenu namenu – ona je

zadužena za kreiranje objekata klase Session prilikom svake interakcije sa bazom podataka.

37 Pod samostalnom (standalone) aplikacijom se ovde misli na aplikaciju kojoj nije potreban aplikacioni server ili servlet kontejner da bi se izvršila, već samo Java virtualna mašina (JVM). 38 SessionFactory je, takozvana, nepromenljiva (immutable) klasa – stanje objekata ove klase se ne može menjati

nakon kreiranja.


69

Slika 19 : Konfigurisanje Hibernate okvira

3.6.1. Konfiguracioni podaci

Kao što je rečeno, konfiguracioni podaci mogu da se podele u dve celine: podaci neophodni da bi se pristupilo bazi podataka, i podaci na osnovu kojih se vrši preslikavanje atributa perzistentnih klasa ka kolonama tabela u relacionoj bazi podataka. Hibernate nudi dve opcije, odnosno dva formata u kojima se mogu obezbediti podaci: u okviru standardne datoteke za definisanje osobina (properties datoteke), pod nazivom hibernate.properties, ili u XML formatu, u datoteci pod nazivom hibernate.cfg.xml. Bez obzira na izabrani format, datoteke moraju da budu smeštene u classpath putanji aplikacije, a ukoliko se obe datoteke nađu u classpath putanji, podaci iz datoteke hibernate.cfg.xml prekriće podatke iz datoteke za definisanje osobina. U ovom radu korišćen je XML format konfiguracionih datoteka, a u nastavku sledi primer hibernate.cfg.xml datoteke.


<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate

Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-

configuration-3.0.dtd">

<hibernate-configuration>

<session-factory>

<property

name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>

<property

name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>

<property

name="hibernate.connection.url">jdbc:mysql://localhost:3306/SoftverskeGreske<

/property>

<property name="hibernate.connection.username">root</property>

<property name="hibernate.connection.password">klapac</property>



<mapping resource="domen/Programer.hbm.xml"/>

</session-factory>

</hibernate-configuration>


70

Konfiguraciona datoteka mora da sadrži definiciju sledećih pet osobina:

o connection.driver_class : upravljački program (driver) za izabrani sistem za upravljanje bazom podataka (SUBP);

o connection.url : JDBC URL do baze podataka. JDBC URL sastoji se iz simboličkog imena upravljačkog programa (jdbc:mysql), IP adrese mašine na kojoj se nalazi SUBP (localhost=127.0.0.1), porta na kome je podignut SUBP (3306), i imena baze podataka sa kojom program treba da uspostavi konekciju (SoftverskeGreske). Na taj način dobija se URL prikazan u prethodnom listingu;

o connection.username : Korisničko ime za pristup bazi podataka;

o connection.password : Lozinku za pristup bazi podataka;

o dialect : Naziv SQL dijalekta za specifičnu bazu podataka

Jedan od načina za definisanje drugog dela konfiguracionih podataka, koji se odnose na

preslikavanja između perzistentnih klasa i tabela baze podataka jesu XML datoteke za preslikavanje.

Sledi primer datoteke Programer.xml.hbm kojom su definisana preslikavanja između perzistentne klase Programer i istoimene tabele u bazi podataka:


<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD

3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>

<class name="domen.Programer" table="Programer">

<id name="id">

<generator class="native"/>

</id>

<property name="korisnickoIme"/>

<property name="lozinka"/>

<property name="ime"/>

<property name="prezime"/>

<property name="eMail"/>

<property name="pozicija"/>

</class>

</hibernate-mapping>

Nakon kreiranja svih datoteka za preslikavanje, potrebno je za svaku datoteku dodati mapping element sa putanjom do kreirane datoteke u hibernate.cfg.xml datoteci. Zadate putanje su

relativne u odnosu na classpath putanju aplikacije.


71

3.6.2. Pokretanje okvira

Pokretanje Hibernate okvira moguće je realizovati na više načina. U sledećem listingu je data jedna od mogućih opcija.

Configuration cfg = new Configuration();

SessionFactory factory = cfg.configure().buildSessionFactory();

Pozivom configure() metode, kako je prikazano u prethodnom primeru, učitavaju se

podaci iz datoteke hibernate.cfg.xml, zatim se pozivom buildSessionFactory() metode kreira

objekat SessionFactory klase.

3.7. RAD SA OBJEKTIMA – MATERIJALIZACIJA I DEMATERIJALIZACIJA

U uvodu ovog poglavlja rečeno je da materijalizacija predstavlja proces transformacije

slogova baze podataka u objekte programa, a dematerijalizacija proces transformacije objekata iz programa u slogove baze podataka. Budući da Hibernate nudi objektno-orjentisan pogled da relacionu bazu podataka, programer je oslobođen pisanja SQL upita, kao i velikog dela programskog koda za komunikaciju sa bazom podataka. Jedino o čemu uvek treba voditi računa jesu stanja objekata.

3.7.1. Stanja objekata

Hibernate okvir definiše i podržava sledeća stanja objekata:

Transijentno (Transient)

Objekat je transijentan ukoliko je tek kreiran korišćenjem new operatora, i još

uvek nije povezan sa objektom klase Session. Objekat nema svoju

perzistentnu reprezentaciju u bazi podataka, i još uvek mu nije dodeljen identifikator. Ukoliko aplikacija nema referencu na transijentni objekat, taj objekat biva uništen od strane Javinog automatskog sakupljača smeća (garbage collector).

Perzistentno (Persistent)

Perzistentni objeti imaju odgovarajuću reprezentaciju u bazi podataka i vrednost identifikatora. Objekat prethodno može da bude snimljen ili učitan iz baze, ali u oba slučaja mora da bude povezan sa Hibernate Session objektom.

Kada je objekat u perzistentnom stanju Hibernate automatski detektuje sve


72

Na sledećoj slici (Slika 20) prikazan je dijagram prelaza stanja objekta između različitih

stanja koja Hibernate podržava, kao i odgovarajuće metode koje Hibernate nudi, a koje omogućavaju prelaz između odgovarajućih stanja.

Slika 20 : Prelazi stanja objekata

3.7.2. Realizacija CRUD operacija

U nastavku će biti dat prikaz korišćenja metoda prikazanih na prethodnoj slici (Slika 20), sa naglaskom na onim metodama koje omogućavaju realizaciju četiri osnovne operacije za manipulaciju podacima u bazi podataka, tzv. CRUD (Create, Read, Update i Delete) operacijama.

3.7.2.1. Operacija snimanja (Create)

Nakon kreiranja objekta korišćenjem new operatora, Hibernate posmatra novokreirani

objekat kao transijentni. Povezivane objekta sa sesijom, odnosno prevođenje objekta u perzistentno stanje vrši se pomoću metode save(). Sledi primer:

promene na objektu, i sinhronizuje stanje objekta sa stanjem u bazi podataka po završetku transakcije.

Odvojeno (Detached)

Objekat se nalazi u odvojenom stanju ukoliko je prethodno bio u perzistentnom, ali je u međuvremenu Session objekat, za koji je bio vezan, zatvoren.

Referenca na odvojen objekat ostaje validna, što znači da je moguće pristupiti i promeniti stanje ovog objekta. Odvojen objekat može ponovo da se prevede u perzistentno stanje , ukoliko se poveže sa novim pojavljivanjem objekta klase Session.


73

public int kreirajISnimiProgramera(String _loz, String _ki, String _ime,

String _prezime, String _pozicija, String _email){

Session sesija = HibernateUtil.getSessionFactory().

getCurrentSession();

Programer p = new Programer(); //transijentno stanje objekta p

p.setIme(_ime);

p.setPrezime(_prezime);

p.setEmail(_email);

p.setKorisnickoIme(_ki);

p.setLozinka(_loz);

p.setPozicija(_pozicija);

sesija.beginTransaction();

Integer id = (Integer)sesija.save(p); //perzistentno stanje

sesija.getTransaction().commit();

return id.intValue();

}

Pomoćna kasa HibernateUtil služi za kreiranje SessionFactory objekta na osnovu

hibernate.cfg.xml datoteke smeštene u classpath putanji aplikacije.

public class HibernateUtil {

private static final SessionFactory sessionFactory;

static {

try {

sessionFactory = new

Configuration().configure().buildSessionFactory();

} catch (Throwable ex) {

System.err.println("Initial SessionFactory creation failed." +

ex);

throw new ExceptionInInitializerError(ex);

}

}

public static SessionFactory getSessionFactory() {

return sessionFactory;

}

}

Ukoliko objekat koji se prevodi u perzistentno stanje poseduje reference ka drugima objektima, ti objekti mogu da se prevedu u perzistentno stanje u bilo kom redosledu, međutim, potrebno je paziti da se prilikom snimanja ne naruši NOT NULL39 ograničenje na spoljnim ključevima. U tom kontekstu, Hibernate okvir nudi mogućnost kaskadnog vršenja operacija nad povezanim objektima, tako da se održavanje integriteta može prepustiti samom okviru.

39 NOT NULL – ograničenje na vrednost kolone kojim se definiše da prilikom ubacivanja novog reda (n-torke) mora da se unese podatak za datu kolonu. U suprotnom, narušava se NOT NULL ograničenje što prouzrokuje neuspešno operacije ubacivanje n-toke[10].


74

3.7.2.2. Operacija čitanja (Read)

Ukoliko je poznat identifikator objekta koji je potrebno učitati, učitavanje može da se izvrši korišćenjem load() metode Session objekta. Load() metoda prima kao parametar class

objekat, a kao rezultat vraća pojavljivanje date klase čiji atributi su postavljeni odgovarajućim vrednostima iz baze podataka. Sledi primer:

public Programer ucitajProgramera(int _id){




Programer p = (Programer)sesija.load(Programer.class,new

Integer(_id));


return p;

}

Ukoliko u bazi ne postoji odgovarjući red, metoda load() će baciti HibernateExeption

izuzetak. Na sličan način može da se koristi metoda get(), međutim, pogodnost ove metode jeste

što metoda ne baca izuzetak ukoliko odgovarajući red ne postoji, već vraća null.

public Programer getProgramer(int _id){




Programer p = (Programer)sesija.get(Programer.class,new

Integer(_id));


return p;

}

Prethodno opisani načini realizacije operacije čitanja podataka iz baze mogući su samo u slučaju kada je poznat identifikator objekta, odnosno primarni ključ u odgovarajućoj tabeli baze podataka. Ukoliko identifikator nije poznat, potrebno je koristi upite nad bazom da bi se dobili odgovarjući rezultati.

Hibernate okvir definiše sopstveni, objektno-orjentisani upitni jezik, HQL (Hibernate Query Language), ali podržava i standardni SQL upitni jezik. HQL i SQL upiti dobijaju se pomoću objekta klase koja realizuje org.hibernate.Query interfejs. Ovaj interfejs nudi mogućnost kreiranja

parametrizovanih upita i iterativnu obradu vraćenih rezultata upita (result set). Pojavljivanje upita dobija se korišćenjem createQuery() metode tekuće sesije. Sledi primer korišćenja Query

interfejsa:

public List vratiListuProgramera(){




75


List listaProgramera = sesija.createQuery("from Programer").list();


return listaProgramera;

}

Pored Query interfejsa, Hibernate obezbeđuje i Criteria API koji omogućava dinamičko

kreiranje upita. Interfejs org.hibernate.Criteria predstavlja upit definisan za određenu

perzisentnu klasu. Kao i kod Query interfejsa, pojavljivanje objekta se dobija korišćenjem

createCriteria() metode tekuće sesije. Sledi primer korišćenja Criteria interfejsa:

public List vratiListuProgramera(){




Criteria crit = sesija.createCriteria(Programer.class);

crit.setMaxResults(10);

List listaProgramera = crit.list();


return listaProgramera;

}

Korišćenjem org.hibernate.criterion.Example klase moguće je kreirati Criteria

upit na osnovu objekta perzistentne klase, kao što je prikazano u sledećem primeru:

public Programer ucitajNaOsnovuPrimera(String _ki, String _loz) {

Programer p = new Programer ();

p.setKorisnickoIme(_ki);

p.setLozinka(_loz);

Session sesija =

HibernateUtil.getSessionFactory().getCurrentSession();


Criteria crit = sesija.createCriteria(Programer.class);

crit.add(Example.create(p));

p = (Programer) crit.uniqueResult();


return p;

}


76

3.7.2.3. Operacija ažuriranja (Update)

Ukoliko se objekti nalaze u perzistentnom stanju, tj. povezani su sa tekućom sesijom i imaju svoju reprezentaciju u bazi podataka, tada će svaka promena na tim objektima biti automatski sinhronizovana u bazi podataka po završetku transakcije, odnosno nakon poziva flush() metode

tekuće sesije. Dakle, najjednostavniji način da se promeni stanje nekog objekta jeste njegovo učitavanje i promena stanja objekta za vreme trajanja tekuće sesije.

Prethodno opisan proces podrazumeva da se u okviru jedne transakcije vrši materijalizacija objekta, promena njegovog stanja i dematerijalizacija objekta. U većini aplikacija ovakav pristup je neefikasan, i zahteva se čitanje podataka, odnosno materijalizacija objekata u jednoj transakciji, zatim se vrši izmena podataka u komunikaciji sa prezentacionim slojem aplikacije, nakon čega se izmenjeni objekti dematerijalizuju u okviru nove transakcije.

Ovakav pristup podržan je od strane Hibernate okvira korišćenjem update(), odnosno

merge() metoda Session objekta. Obe metode povezuju odvojeni (detached) objekat sa novom

sesijom i tako ga prevode u perzistentno stanje. Prilikom korišćenja update() metode neophodno

je voditi računa da u tekućoj sesiji ne postoji objekat sa istim identifikatorom kao i objekat koji se prosleđuje update() metodi. Sledi primer korišćenja update() metode:

public void azurirajProgramera(Programer p) {

Session sesija =

HibernateUtil.getSessionFactory().getCurrentSession();


sesija.update(p);


}

3.7.2.4. Operacija brisanja (Delete)

Operacija brisanja podataka iz baze ostvaruje se korišćenjem delete() metode Session

objekta. Pozivom delete metode brišu se podaci iz baze podataka, međutim, aplikacija i dalje može da zadrži referencu na objekat čiji su podaci obrisani, tako da se brisanje podataka pomoću delete() metode može posmatrati kao prevođenje objekta iz perzistentnog u transijentno stanje,

kao što je prikazano na Slika 20.


77

3.7.3. Proxy uzor

Proxy uzor se u Hibernate okviru koristi kako bi se obezbedila kasna materijalizacija (lazy loading) objekata. Koncept kasne materijalizacije prikazan je u sledećem podnaslovu.

Definicija

Proxy uzor je strukturni uzor kojim se obezbeđuje zamena (surrogate, placeholder) interfejsa nekog drugog objekta, u cilju kontrolisanog pristupa do njega.

Poznat kao : Surrogate

Primena

Proxy uzor se koristi u sledećim situacijama:

Ukoliko je za učitavanje objekta (npr. slike) potrebno mnogo vremena. Ova forma proxy uzora poznata je pod nazivom virtual proxy.

Ukoliko se objekat nalazi na udaljenoj (remote) mašini. U ovom slučaju proxy objekat predstavlja lokalnu reprezantaciju udaljenog objekta. Ovakva forma proxy uzora naziva se remote proxy.

Ukoliko je potrebno obezbediti kontrolu pristupa do objekta. Ova forma proxy uzora poznata je pod nazivom protection proxy.

Ukoliko je prilikom pristupa objektu potrebno izvršiti dodatne operacije. Ova forma proxy uzora poznata je pod nazivom smart reference.

Struktura

Učesnici

Proxy o održava referencu ka originalnom objektu (RealSubject) preko koje je proxy

objektu omogućen pristup metodama originalnog objekta. o obezbeđuje interfejs identičan Subject interfejsu, kako bi proxy mogao da se

koristi kao zamena za originalni objekat.


78

o kontroliše pristup do originalnog objekta, i može da bude odgovoran za kreiranje i brisanje originalnog objekta.

Subject o defniniše zajednički interfejs za RealSubject i Proxy.

RealSubject o definiše originalni objekat koga Proxy predstavalja.

Saradnja

Proxy prosleđuje klijentske zahteve do RealSubject objekta. Realizacija ove saradnje zavisi od forme proxy uzora.

Posledice

Sakrivanje činjenice da se originalni objekat nalazi na udaljenoj (remote) mašini.

Optimizacija, u smislu kreiranja objekata u trenutku kada im se pristupi u kodu.

3.7.4. Kasna matrijalizacija (Lazy loading)

Jedna od kritičnih tačaka, koja umogome determiniše performanse aplikacije, posebno u domenu Web aplikacija, jeste brzina i način pristupa podacima u bazi podataka. Objektni model, kroz bogatstvo koncepata koje podržava, omogućava da se klase domenskog modela aplikacije na različite načine povežu, počev od veoma jednostavnih asocijacija između klasa tipa „1-1“(one-to-one), do mnogo kompleksnijh veza kojima se kreiraju čitavi grafovi objekata. Način na koji se objekti koji su u međusobnoj vezi materijalizuju ima veoma veliki uticaj na performase aplikacije.

Tipičan primer, koji se može sresti u mnogim aplikacijama, jeste veza između objekata tipa „1-*“ (one-to-many), koja može da se realizuje tako što objekat koji je na strani one sadrži kolekciju objekata koji su na strani many.

U ovom slučaju performase sistema se narušavaju ukoliko se prilikom materijalizacije objekta klase Projekat istovremeno vrši i materijalizacija kompletne kolekcije objekata klase

Greska, a za tekuću operaciju relevantni su samo podaci objekta klase Projekat.

Kasna materijalizacija objekata omogućava da se referencirani objekti, ili kolekcija objekata materijalizuju u trenutku kada su potrebni, tj. kada im se pristupi u kodu. Na taj način bi se, u


79

posmatranom primeru, materijalizacija liste grešaka izvršila tek u trenutku poziva metode getListaGresaka().

U Hibernate okviru kasna materijalizacija je podrazumevana strategija materijalizacije kada se za definisanje preslikavanja koriste XML datoteke. Kasna materijalizacija u Hibernate okviru se realizuje preko Proxy uzora.

U kontekstu kasne materijalizacije u Hibernate okviru, metode proxy objekata sadrže dodatnu logiku koja omogućava da se u vreme poziva metode pristupi bazi podataka i izvrši materijalizacija zahtevanih podataka. Budući da se u Hibernate okviru pristup bazi podataka vrši isključivo preko Session objekata, proxy objekat mora da čuva referencu na tekuću sesiju pomoću

koje je izvršena materijalizacija objekta roditelja. Kada se izvrši poziv neke metode objekta roditelja (npr. pozivom metode getListaGresaka() iz prethodnog primera), proxy objekat će izvršiti

materijalizaciju podataka koristeći istu sesiju kojom je izvršena materijalizacija objekta roditelja. Kasnu materijalizaciju moguće je vršiti samo ukoliko je objekat roditelj u perzistentnom stanju, odnosno ako je vezan za sesiju. Ako se objekat roditelj nije vezan za sesiju, prilikom poziva proxy metoda biće generisan LazyInitializationException izuzetak.

3.7.5. Keširanje

Druga tehnika, kojom se u kontekstu brzine pristupa podacima mogu značajno poboljšati performanse aplikacije je keširanje. Keširanje predstavlja proces privremenog skladištenja kopija podataka na mestu gde im se može brže pristupiti. U Hibernate kontekstu, poboljšanje performansi se postiže privremenim čuvanjem – keširanjem materijaliziovanih perzistentnih objekata, kako bi se pri sledećem zahtevu za istim objektima, umesto operacija čitanja podataka iz baze, ovi objekti materijalizovali iz keš memorije.

Hibernate okvir podržava dva nivoa keširanja.

Prvi nivo keširanja je u upsegu izvršenja jedne sesije, odnosno u opsegu izvršenja jedne transakcije. Prvi nivo keširanja se u Hibernate-u podrazumevano koristi. Prvim nivoom keširanja se na nivou transakcije smanjuje broj generisanih SQL upita, odnosno, smanjuje se broj pristupa bazi podataka. Ilustracije radi, ukoliko se u toku transakcije materijalizuje jedan objekat, sve izmene koje se u toku transakcije izvrše na tom objektu čuvaju se u keširanoj kopiji objekta, da bi se umesto pojedinačnog ažuriranja stanja u bazi podataka nakon svake promene stanja objekta , ažuriranje izvršilo jednom, na kraju izvršenja transakcije.

Drugi nivo keširanja u Hibernate okviru je opcion, odnosno, podrazumevano nije uključen. Keširanje drugog nivoa je šireg opsega od keširanja na prvom nivou. Objekte keširani na ovom nivou dostupni su svim sesijama kreiranim od strane SessionFactory objekta.

Hibernate u keš memoriju ne smešta same perzistentne objekte, već koristi određenu formu deserijalizacije objekata. Deserijalizacija se vrši tako što se atributi objekata smeštaju u odgovarajući niz vrednosti, dok se identifikator objekta koristi kao referenca na niz. Ovakvo stanje objekata se u Hibernate terminologiji naziva dehidrirano (dehydrated). Slično tome, proces


80

smeštanja objekata u keš memoriju, i proces kreiranja objekata domenskog modela iz keš memorije nazivaju se „dehidratacija“ i „hidratacija“ respektivno. Konceptualno gledano, keš memorija može da se posmatra kao mapa koja sadrži identifikatore objekata kao ključeve, a nizove kao vrednosti.

Ukoliko se želi koristiti keširanje drugog nivoa , neophodno je u konfiguracionim metapodacima navesiti implementaciju koja će se koristiti. Hibernate podržava sledeće četiri open-source implementacije:

EHCache

OSCache

SwarmCache

JBoss TreeCache

Nakon izbora implementacije, neophodno je definisati strategiju keširanja. Na raspolaganju su četiri strategije:

Read-only : Koristi se u situacijama kada se podaci često čitaju, ali nikad ne ažuriraju.

Read –Write : Koristi se u situacijama kad je podatke neophodno i ažurirati.

Nonstrict Read-Write : Ova strategija ne garantuje da dve transakcije neće simultano izvršiti izmenu istih podataka. Zbog toga je prikladna samo u situacijama kad se podaci često čitaju, a vrlo retko ažuriraju.

Transactional : Može da se koristi samo u JTA40 okruženjima.

Različite implementacije podržavaju različit skup navedenih strategija, što je prikazano sledećom tabelom:

Strategija Keš implementacija

Read-only Nonstrict

Read-Write Read –Write Transactional

EHCache DA DA DA NE

OSCache DA DA DA NE

SwarmCache DA DA NE NE

Jboss TreeCache DA NE NE DA

Na drugom nivou keširanja, Hibernate podržava i mehanizam keširanja rezultata upita.

Keširanje rezultata upita (ResultSet ) razlikuje se od keširanja objekata, jer se tom prilikom ne keširaju objekti koji se iz upita dobijaju, već samo identifikatori objekata.

3.7.6. HQL – Hibernate Query Language

Hibernate okvir podržava veliki broj opcija za pristup podacima u bazi podataka. Jedan od načina koji je prikazan u prethodnom delu ovog poglavlja je korišćenje Criteria API-ja, zatim

40 JTA – Java Transaction API


81

korišćenje određenih metoda Session API-ja koje omogućavaju da se na osnovu identifikatora

objekat materijalizuje. Pored ovih opcija Hibernate omogućava direktno korišćenje SQL upita, međutim, Hibernate okvir poseduje i sopstveni upitni jezik koji omogućava čitanje podataka iz baze.

Suštinska razlika između SQL-a i HQL-a (Hibernate Query Language) je u tome što je HQL objektno-orjentisan jezik. Osnovni problem u korišćenju SQL-a jeste njegova prenosivost. Naime, različiti sistemi za upravljanje bazama podataka (SUBP) podržavaju različite SQL dijalekte, specifičane za dati SUBP, tako da se prelaskom sa jednog na drugi sistem mora vršiti prilagođavanje SQL upita. HQL u tom kontekstu nudi određen nivo apstrakcije između aplikacije i SUBP-a. HQL-om se obezbeđuje objektni pogled na relacionu bazu podataka, jer se upiti kreiraju na osnovu objekata perzistentnih klasa, dok je Hibernate zadužen za automatsko generisanje odgovarajućih SQL upita. Na taj način poboljšava se prenosivost aplikacije, jer je za prelazak na drugi SUBP dovoljno prilikom konfigurisanja okvira definisati drugi dijalekt. U studijskom primeru korišćen je MySQL SUBP, tako da je prilikom konfiguracije definisan org.hibernate.dialect.MySQLDialect. U sledećoj tabeli

dat je spisak dijalekata koje podržava Hibernate okvir:

SUBP Dijalekt

DB2 org.hibernate.dialect.DB2Dialect DB2 AS/400 org.hibernate.dialect.DB2400Dialect DB2 OS390 org.hibernate.dialect.DB2390Dialect PostgreSQL org.hibernate.dialect.PostgreSQLDialect MySQL org.hibernate.dialect.MySQLDialect MySQL ( InnoDB) org.hibernate.dialect.MySQLInnoDBDialect MySQL ( MyISAM) org.hibernate.dialect.MySQLMyISAMDialect Oracle org.hibernate.dialect.OracleDialect

Oracle 9i/10g org.hibernate.dialect.Oracle9Dialect

Sybase org.hibernate.dialect.SybaseDialect

Sybase Anywhere org.hibernate.dialect.SybaseAnywhereDialect

Microsoft SQL Server org.hibernate.dialect.SQLServerDialect

SAP DB org.hibernate.dialect.SAPDBDialect

Informix org.hibernate.dialect.InformixDialect

HypersonicSQL org.hibernate.dialect.HSQLDialect

Ingres org.hibernate.dialect.IngresDialect

Progress org.hibernate.dialect.ProgressDialect

Mckoi SQL org.hibernate.dialect.MckoiDialect

Interbase org.hibernate.dialect.InterbaseDialect

Pointbase org.hibernate.dialect.PointbaseDialect

FrontBase org.hibernate.dialect.FrontbaseDialect

Firebird org.hibernate.dialect.FirebirdDialect Tabela 6 : Hibernate dijalekti


82

3.8. KREIRANJE ORM MODELA

Integracija Hibernate okvira u određeno aplikaciono okruženje podrazumeva veliki broj konfiguracionih podataka. Logički, u prvu grupu ovih podataka spadaju konfiguracioni podaci koji su neophodni da bi Hibernate okvir po pokretanju bio u mogućnosti da komunicira sa određenom bazom podataka. Prikaz ovog dela konfiguracionih podataka dat je u poglavlju 3.6. Konfigurisanje okvira, dok je akcenat ovog dela na drugoj logičkoj celini konfiguracionih podataka , kojima se definišu preslikavanja između klasa koje čine domenski model aplikacije i odgovarajućih relacija u bazi podataka. Najčešće korišćena forma u kojoj se obezbeđuju podaci koji definišu pomenuta preslikavanja jesu XML datoteke.

Kompletan ORM model sačinjavaju tri komponente[12]:

domenski/objektni model aplikacije,

šema baze podataka, i

XML datoteke kojima se definišu preslikavanja.

3.8.1. Pristupi u kreiranju ORM modela

Prvi pristup u kreiranju ORM modela podrazumeva ručno kreiranje sve tri komponente modela. Dakle, neophodno je ručno izvršiti implementaciju svih klasa koje sačinjavaju domenski model aplikacije, zatim projektovati odgovarajuću šemu baze podataka i, konačno, kreirati sve datoteke kojima se definišu preslikavanja između druge dve komponente.

Široka primena i velika popularnost Hibernate okvira omogućili su razvoj velikog broja alata, koji pored pomenutog pristupa, omogućavaju različite strategije u razvoju ORM modela. U suštini, uloga ovih alata je da se nakon ručnog kreiranja jedne komponente modela automatizuje proces kreiranja preostale dve komponente. Na taj način se, u zavisnosti od koje komponente se polazi, razlikuju tri pristupa u kreiranju ORM modela [12]:

pristup vođen domenskim/objektnim modelom,

pristup vođen modelom podataka, i

pristup vođen datotekama za preslikavanje.

Pristup vođen domenskim/objektnim modelom podrazumeva prethodnu implementaciju klasa domenskog modela, prilikom koje se korišćenjem Java anotacija41, ili korišćenjem XDoclet tagova za označavanje (markup) definišu preslikavanja između klasa i tabela u bazi podataka. Na osnovu datih metapodataka kreiraju se datoteke za preslikavanje, iz kojih se, korišćenjem Hibernate-ovog HBM2DDL alata može kreirati šema baze podataka.

41 Anotirati – označiti. Označavanjem se elementima programa (klase, metode, promenljive, ...) pridružuju odgovarajući metapodaci na osnovu kojih se označenom elementu pridružuje određena funkcionalnost. Java uvodi anotacije počev od verzije J2SE 5.


83

Drugi pristup, kod koga se polazi od postojećeg modela podataka, podrazumeva da je prethodno izabran sistem za upravljanje bazom podataka i da je kreirana odgovarajuća šema baze podataka. Alati kao što su Middlegen, ili Hibernate Synchronizer omogućavaju da se na osnovu šeme baze podataka kreiraju datoteke za preslikavanje, na osnovu kojih se, korišćenjem Hibernate-ovih HBM2JAVA alata mogu kreirati klase domenskog modela.

U trećem pristupu polazi se od detaljne specifikacije datoteka za preslikavanje, kojima se definišu sva preslikavanja između klasa domenskog modela i odgovarajućih tabela u bazi podatka. Na osnovu kreiranih datoteka se zatim generiše šema baze podataka korišćenjam HBM2DDL alata, odnosno klase domenskog modela korišćenjem HBM2JAVA alata.

Aplikacija koja je dokumentovana u okviru studijskog primera je relativno malog obima, tako da su sve tri komponente ORM modela kreirane ručno, bez upotrebe alata koji bi ovaj proces automatizovali.

3.8.2. Datoteke za definisanje preslikavanja

Objektno-relaciona preslikavanja u Hibernate okviru se definišu unutar XML datoteka. Pravila, tj. jezik za pisanje ovih datoteka je orjentisan ka Java klasama42, što znači da se preslikavanja konstruišu na osnovu deklaracija perzistentnih klasa, a ne na osnovu relacionog modela. Validacija XML datoteka za preslikavanja vrši se u odnosu na DTD datoteku hibernate-mapping-3.0.dtd.

Sledi opis najčešće korišćenih elemenata koji se koriste prilikom kreiranja XML datoteka za preslikavanje.

Koreni element svake datoteke za preslikavanje je <hibernate-mapping> element.

Atributima ovog elementa uglavnom se definišu podrazumevana podešavanja koja se primenjuju za sve podelemente.

Deklaracija perzistentnih klasa unutar datoteka za preslikavanje vrši se korišćenjem <class> elementa. U suštini, sva preslikavanja između perzistentne klase i odgovarajuće tabele u

bazi podataka definišu se unutar tela <class> elementa. Svaka klasa koja se direktno definiše

korišćenjem <class> elementa mora da sadrži <id> ili <composite-id> element. Ovim

elementom se za svaku klasu definiše koja kolona u odgovarajućoj tabeli baze podataka predstavlja primarni ključ. Perzistentne Java klase u tom slučaju poseduju atribut koji sadrži jedinstveni identifikator svakog pojavljivanja objekta. <id> elementom se definiše preslikavanje između tog

atributa i kolone primarnog kluča u tabeli.

U telu <id> elementa definiše se <generator> element kojim se specificira na koji način

se generiše primarni ključ svakog novog pojavljivanja klase. Ovim elementom definiše se Java klasa koja vrši generisanje primarnih ključeva. Sve generator klase implementiraju interfejs

42 U literaturi se koristi izraz Java-centric, što u suštini znači da je smer preslikavanja od perzistentih klasa ka tabelama u bazi podataka.


84

org.hibernate. id.IdentifierGenerator. Hibernate poseduje gotove implementacije ovog

interfejsa koje mogu da se referenciraju preko skraćenih imena. Sledi prikaz najčešće korišćenih generatora:

Skraćeno ime Opis

sequence

Zasniva se na sekvencijalnom generisanju identifikatora. Ova opcija nije u potpunosti prenosiva, jer nije podržana od strane nekih baza podataka. Podržani tipovi su int, short i long.

native

U zavisnosti od baze podataka koristi se hilo, sequence, ili

identity generator. Ova opcija obezbeđuje maksimalnu

prenosivost. Podržani tipovi su int, short i long.

increment

Prilikom pokretanja Hibernate-a, ovaj generator čita maksimalnu vrednost u koloni primarnog ključa, zatim tu vrednost uvećava za 1 prilikom svakog sledećeg dodavanja reda u tabeli. Generisani ključevi su jedinstveni samo u slučaju kada drugi procesi istovremeno ne unose podatke u istu tabelu. Podržani tipovi su int, short i long.

assigned

Aplikacija dodeljuje identifikator objekta pre poziva save()

metode. Ovo je podrazumevana strategija generisanja identifikatora ukoliko se ne navede <generator> element.

foreign

Koristi identifikator drugog, povezanog objekta. Obično se koristi kod veza tipa <jedan-prema-jedan>.

Tabela 7 : Generatori primarnihključeva

Za svaki atribut klase koji je potrebno sačuvati u bazi podataka neophodno je definisati <property> element u datoteci za preslikavanje. Perzistentni atributi klase moraju da imaju

odgovarajuće metode za postavljanje vrednosti atributa (set() i get() metode). <property>

element poseduje više atributa, od kojih je neophodno definisati samo name atribut, čija vrednost

mora da počne malim slovom.

Sledi primer datoteke za preslikavanje Programer.hbm.xml iz studijskog primera, kojom se definišu preslikavanja između perzistentne klase domen.Programer i tabele Programer.




<hibernate-mapping>


<id name="id">


</id>




85



<property name="eMail"/>


</class>


3.8.3. Primeri preslikavnja

Bogatstvo objektnog modela, kao i veliki broj mogućnosti preslikavanja koje nudi Hibernate okcir rezultiraju širokim spektrom opcija kojima se pomoću datoteka za preslikavanje mogu predstaviti različiti odnosi između klasa objektnog modela. U nastavku je dat prikaz nekoliko karakterističnih primera preslikavanja veza između objekata, primer preslikavanja kolekcije objekata, kao i prikaz mogućih strategija za preslikavanja nasleđivanja.

Pod pojmom asocijacije podrazumevaju se odnosi, tj. veze između objekata perzistentnih klasa. Objektni model podržava nekoliko vrsta asocijacija: 1-1 (one-to-one), * - * (many-to-many), 1 - * (one-to-many). Asocijacije, tj. veze mogu da budu jednosmerne (unidirectional) i dvosmerne (bidirectional). Veze se u Java klasama realizuju preko atributa objekata, bilo da je atribut referenca na jedan objekat, ili kolekcija drugih objekata. Jednosmerna veza je veza između dva objekta kod koje samo jedan od objekata ima referencu na drugi objekat u vezi, dok u dvosmernoj vezi oba objekta imaju referencu na objekat koji se nalazi na drugoj strani veze. Sledi nekoliko primera preslikavanja jednosmernih veza.

Preslikavnje veze tipa “1-1“ predstavlja jedan od najjednostavnijih slučajeva, koji se može praktično realizovati na više načina. Najjednostavnihi način za preslikavanje veze tipa “1-1“ je korišćenje <component> elementa. Komponeneta predstavlja zavisni objekat referenciran od

strane perzistentnog objekta, pri čemu sama komponenta ne predstavlja perzistentni objekat, već se u perzistentno stanje prevodi kao promenljiva koja ima proste tipove vrednosti.


<id name="id">


</id>

<component name="korisnik" class="domen.Korisnik">



</component>



<property name="email" column="eMail"/>


</class>


86

Sledi odgovarajući programski kod klasa Programer i Korisnik:

package domen;

public class Programer {

private int id;

private Korisnik korisnik;

private String email;

private String ime;

private String prezime;

private String pozicija;

// set i get metode su izostavljene...

}

package domen;

public class Korisnik {

private String korisnickoIme;

private String lozinka;


}

U ovom slučaju postoji samo jedna tabela u bazi podataka:

Programer(id, korisnickoIme, lozinka, email, ime, prezime, pozicija)

Pored prethodno opisanog načina realizacije preslikavanja veze tipa “1-1“, preslikavanje se može realizovati i korišćenjem <many-to-one> elementa.

U slučaju da se oba objekta u vezi posmatraju kao zasebni perzistentni objekti, pri čemu svaki ima odgovarajuću tabelu u bazi podataka, preslikavanje veze “1-1“ se može realizovati preko spoljnog ključa korišćenjem <many-to-one> elementa, ili preko primarnog ključa, korišćenjem

<one-to-one> elementa.

Sledi primer korišćenja <many-to-one> elementa za realizaciju veze tipa „1-1“:


<id name="id">


</id>



<property name="email" column="eMail"/>


87


<many-to-one name="korisnik"

column="id_korisnik"

unique="true"

not-null="true"/>

</class>

<class name="domen.Korisnik" table="Korisnik">

<id name="id">


</id>



</class>

U ovom slučaju i klasa Programer i klasa Korisnik imaju odgovarajuću tabelu u bazi

podataka:

Programer(id, email, ime, prezime, pozicija, id_korisnik) Korisnik(id, korisnickoIme, lozinka)

Na sličan način vrši se preslikavanje veze tipa „* - 1“ (many-to-one). Da bi se veza tipa „1 -1“ iz prethodnog primera pretvorila u vezu „* - 1“ potrebno je samo ukloniti unique ograničenje za

kolonu spoljnog ključa u tabeli Programer.

Realizacija veze tipa „1 - *“ u Java klasama najčešće se ostvaruje tako što objekat na strani „1“ sadrži kolekciju objekata koji su na strani „*“. Neophodno je da se prilikom deklaracije kolekcije koristi interfejsni tip, npr. java.util.Set, java.util.List, ili java.util.Map, budući da

Hibernate poseduje sopstvene implementacije pomenutih interfejsa, tako da nije moguće deklarisati kolekciju, na primer, tipa java.util.ArrayList. Primer koji sledi prikazuje preslikavanje

dvosmerene veze tipa „1 - *“ između objekata klasa Projekat i Greska, pri čemu objekti klase

Projekat sadrže kolekciju (listu) objekata klase Greska.

<class name="domain.Projekat" table="projekat">

<id name="id">


</id>

<property name="naziv"/>

<list name="listaGresaka" table="greska"

cascade="save-update"

inverse="true"

lazy="false">

<key column="id_projekta"/>

<index column="id"/>

<one-to-many class="domain.Greska"/>

</list>


88

</class>

<class name="domain.Greska" table="greska">

<id name="id">


</id>

<property name="kratakOpis"/>

<property name="opis"/>

<property name="prioritet"/>

<property name="status"/>

<many-to-one name="projekat" column="id_projekta"/>

</class>

package domain;

import java.util.List;


private int id;


private List<Greska> listaGresaka;


}

package domain;

public class Greska {

private int id;

private String kratakOpis;


private String status;

private String prioritet;

private Projekat projekat;


}

Projekat(id, naziv) Greska(id, kratakOpis, opis, status, prioritet, id_projekta)


89

Dvosmerna veza se u prethodnom primeru ostvaruje tako što objekti klase Projekat

sadrže listu objekata Greska, dok objekti klase Greska sadrže atribut tipa Projekat kojim se

referencira projekat na koji se greška odnosi. Obe klase imaju odgovarajuće tabele u bazi podataka, pri čemu tabela Greska poseduje spoljni ključ, preko koga se refernecira Projekat.

Za definisanje preslikavanja liste objekata koristi se <list> element. Jedini atribut <list>

elementa koji je nephodno definisati je name atribut, kojim se specificira naziv atributa klase koji

predstavlja kolekciju. <key> elementom specificira se kolona koja sadrži spoljni ključ u tabeli

Greska. Ovaj element je neophodno definisati, kao i <index> element.

cascade atributom omogućava se automatizacija operacija nad povezanim objektima.

Moguće vrednosti ovog atributa su none, all, save-update, delete, all-delete-orphan,

i delete-orphan, a moguće je koristiti i kombinaciju više vrednosti odvojenih zarezom. U

prikazanom primeru postavljena je vrednost cascade="save-update", što znači da će prilikom

snimanja ili ažuriranja objekta Projekat ista operacija biti kaskadno urađena nad svim objektima

u kolekciji grešaka.

Koncept nasleđivanja klasa je najočigledniji vid nepodudaranja između objektnog i relacionog modela. Budući da relacioni model ne podržava koncept nasleđivanja neophodni su mehanizmi kojima bi se obezbedilo preslikavnje hijerarhije objekata u odgovarajuće tabele baze podataka.

Postoje tri različita pristupa preslikavanja hijerarhije objekata:

Preslikavanje cele hijerarhije klasa u jednu tabelu – ovo je najjednostavnija strategija kod koje se celokupna hijerarhija klasa preslikava u jednu tabelu baze podataka, pri čemu tabela sadrži posebnu kolonu (diskriminator), na osnovu koje se određuje koju podklasu reprezentuje red u posmatranoj tabeli. Glavni nedostatak ovog pristupa je to što se mora dozvoliti da kolone tabele u koje se smeštaju vrednosti atributa podklasa mogu da sadrže null vrednosti, što može da dovede do narušavanja integriteta podataka.

Preslikavanje svake konkretne (neapstraktne) klase u sopstvenu tabelu – kod ovog pristupa svi atributi klasa, uključujući i atribute koje klasa nasleđuje preslikavaju se u jednu tabelu. Očigledan nedostatak ovog pristupa je potreba da se vrše izmene u svim tabelama ukoliko se izvrši bilo kakva izmena u nadklasi.

Preslikavanje svake klase u sopstvenu tabelu – kod ovog pristupa hijerarhija nasleđivanja klasa u relacionom modelu se realizuje preko spoljnih ključeva. Za svaku klasu u hijerarhiji postoji odgovarajuća tabela u bazi podataka, pri čemu se efekat generalizacije, odnosno specijalizacije postiže tako što su primarni ključevi u tabelama koje reprezentuju podklase ujedno i spoljni ključevi preko kojih se referenecira tabela koja reprezentuje nadklasu.


90

4. INTEGRACIJA SPRING I HIBERNATE OKVIRA

U prethodnom poglavlju dat je kratak prikaz Hibernate ORM alata, međutim naglasak je tom prilikom stavljen na opis problema perzistentnosti u objektno orjentisanim aplikacijama i rešenja koja u tom kontekstu nudi Hibernate okvir. U ovom poglavlju više pažnje biće posvećeno integraciji Spring i Hibernate okvira, načinu konfigurisanja Hibernate resursa unutar Spring-ovih konfiguracionih datoteka, zatim će biti prikazani mehanizmi deklarativnog upravljanja transakcijama koje nudi Spring okvir.

4.1. PERZISTENTNOST U SPRING OKVIRU

Spring okvir nudi nekoliko mehanizama koji omogućavaju rad sa različitim tehnologijama i alatima koji obezbeđuju perzistentnost. Na vrlo jednostavan način moguće je koristiti JDBC, ali pored toga Spring omogućava integraciju i sa nekoliko najpoznatijih ORM alata:

iBATIS SQL Maps;

Hibernate;

JDO;

Apache OJB;

Oracle TopLink.

Spring okvir obezbeđuje skup apstraktnih DAO (Data Access Object) klasa koje omogućavaju jednostavan pristup različitim tehnologijama. DAO uzor je jedan od najčešće korišćenih uzora prilikom razvoja J2EE aplikacija. Primarna svrha DAO uzora je razdvajanje poslovne logike aplikacije od dela koji je zadužen za perzistentnost. DAO uzor se zasniva na principu korišćenja interfejsa koji definišu operacije koje perzistentni okvir nudi na raspolaganje poslovnim klasama aplikacije, pri čemu je konkretna implementacija sakrivena. Na taj način obezbeđuje se potpuna nezavisnost poslovnog dela aplikacije od konkretne tehnologije koja obezbeđuje perzistentnost. U sledećoj tabeli dat je prikaz apstraktnih DAO klasa koje Spring nudi za pristup podacima preko različitih tehnologija.

Klasa Opis

JdbcDaoSupport Omogućava pristup podacima preko JDBC-a.

HibernateDaoSupport Omogućava pristup podacima preko Hibernate okvira.

JdoDaoSupport Omogućava pristup podacima preko JDO mehanizama.

JpaDaoSupport Omogućava pristup podacima preko JPA tehnologije.

Tabela 8 : Prikaz apstraktnih DAO klasa


91

Jedan od najvećih nedostataka prilikom direktnog korišćena JDBC-a, pored potrebe da se veliki broj linija koda ponavlja, oduzimajući dosta vremena u toku implementacije, jeste problem upravljanja izuzecima. Naime, ukoliko dođe do greške prilikom komunikacije sa bazom podataka, implementacije koje koriste JDBC moraju da generišu java.sql.SQLException izuzetak. Problemi

vezani za obradu ovog izuzetka su višestruki. Pre svega, SQLException je proveravani (checked)

izuzetak, što znači da mora da bude obrađen korišćenjem try-catch blokova, ili dodavanjem

throws klauzule u definiciji metode. Na taj način poslovna logika postaje direktno vezana za

konkretnu implementaciju perzistentnog okvira. Drugi problem vezan je za prenosivost aplikacije. Informacije o nastaloj grešci koja je prozrokovala generisanje SqlException izuzetka mogu da se

dobiju korišćenjem metoda getMessage(), getErrorCode() i metode getSQLState(). Budući

da se error code i SQL state kodovi na različite načine definišu od strane različitih proizvođača sistema za upravljanje bazama podataka, prilikom prelaska sa jednog na drugi sistem neophodno ponovno kodiranje onog dela aplikacije koji se odnosi na obradu izuzetaka.

Spring okvir poseduje sopstvenu hijerarhiju izuzetaka koja se koristi prilikom korišćenja JDBC mehanizama i prilikom korišćenja ORM alata. Na vrhu hijerarhije ovih izuzetaka nalazi se DataAccessException izuzetak koji je podklasa RuntimeException izuzetka što znači da cela

hijerahija izuzetaka predstavlja neproveravane (unchecked) izuzetke, tako da njihova obrada nije obavezna.

4.2. KONFIGURISANJE HIBERNATE RESURSA

Hibernate okvir pruža mugućnost integracije sa mnogim aplikacionim okruženjima. Primer konfiguracije Hibernate okvira kao perzistentnog servisa samostalne (standalone) aplikacije dat je u prethodnom poglavlju, dok je akcenat ovog poglavlja na integraciji Spring i Hibernate okvira. U tom kontekstu, u nastavku će biti prikazan način povezivanja Spring i Hibernate okvira, kao i konfigurisanje i način korišćenja klasa pomoću kojih Spring obezbeđuje pristup servisima Hibernate okvira.

4.2.1. Konfigurisanje SessionFactory bean-a

Za konfigurisanje Hibernate SessionFactory bean-a u Spring okviru koristi se klasa

LocalSessionFactoryBean. Sledećim listingom prikazana je definicija sessionFactory bean-a

koji se konfiguriše na osnovu podataka iz standardne hibernate.cfg.xml datoteke:

<bean id="sessionFactory"

class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">

<property name="configLocation" value="classpath:hibernate.cfg.xml"/>

</bean>


92

U sledećem listingu dat je sadržaj hibernate.cfg.xml datoteke.


<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate

Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-

configuration-3.0.dtd">

<hibernate-configuration>

<session-factory>

<property

name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>

<property

name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>

<property

name="hibernate.connection.url">jdbc:mysql://localhost:3306/SoftverkseGreske<

/property>

<property name="hibernate.connection.username">root</property>

<property name="hibernate.connection.password">klapac</property>

<property name="current_session_context_class">thread</property>

<property

name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>

<property name="show_sql">true</property>



<mapping resource="domen/Projekat.hbm.xml"/>

<mapping resource="domen/Programer.hbm.xml"/>

</session-factory>

</hibernate-configuration>

Budući da se svi konfiguracioni prametri u XML datotekama prosleđuju u string formatu, potrebno je obezbediti mehanizam konverzije datih stringova u odgovarajući tip atributa klase LocalSessionFactoryBean. U tu svrhu se koriste klase editori osobina (Property Editors).

Konkretno, u slučaju atributa configLocation, koji je tipa Resource, Spring okvir koristi klasu

ResourceEditor kako bi prosleđeni string (hibernate.cfg.xml) konvertovao u odgovarajući objekat

klase Resource.

Prethodno prikazanim podešavanjem, SessionFactory bean se kreira na osnovu podataka

iz hibernate.cfg.xml konfiguracione datoteke koja sadrži podešavanja vezana za upravljački

program (driver) za izabrani SUBP, JDBC URL baze podataka, kao i korisničko ime i lozinku za pristup bazi podataka. Alternativa ovom pristupu je korišćenje određene implementacije DataSource interfejsa, kome je prilikom deklarisanja potrebno obezbediti gore pomenute

parametre. U sledeće listingu prikazana je konfiguracija klase DriverManagerDataSource, koja

implementira DataSource interfejs.

<bean id="dataSource"

class="org.springframework.jdbc.datasource.DriverManagerDataSource">

<property name="driverClassName"

value="com.mysql.jdbc.Driver" />

<property name="url"

value="jdbc:mysql://localhost:3306/SoftverskeGreske" />

<property name="username" value="root" />


93

<property name="password" value="klapac" />

</bean>



<property name="dataSource" ref="dataSource"/>

<property name="configLocation" value="classpath:hibernate.cfg.xml"/>

</bean>

Pored prethodno prikazanog načina obezbeđenja konfiguracionih podatka koji su potrebni za kreiranje SessionFactory bean-a, korišćenjem standardne hibernate.cfg.xml datoteke,

konfiguracione podatke je moguće definisati i korišćenjem hibernateProperties atributa

LocalSessionFactoryBean klase. Prednost ovakvog pristupa je svakako to što su svi

konfiguracioni podaci smešteni na jednom mestu. Sledi prikaz konfigurisanja SessionFactory

bean-a korišćenjem hibernateProperties atributa:




<property name="hibernateProperties">

<props>

<prop

key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>

<prop key="hibernate.show_sql">true</prop>

</props>

</property>

</bean>

Na ovaj način obezbeđen je deo konfiguracionih podataka koji su potrebni za uspostavljanje konekcije sa bazom podataka. Kao što je u prethodnom poglavlju rečeno, druga logička celina konfiguracionih podataka odnosi se na preslikavanja između atributa perzistentnih klasa i odgovarajućih kolona u tabelama baze podataka. Nakon kreiranja XML datoteka za preslikavanje, neophodno je korišćenjem mappingResources ili mappingLocations atributa

LocalSessionFactoryBean klase navesti putanje do ovih datoteka. Sledi primer:




<property name="hibernateProperties">

<props>

<prop

key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>

<prop key="hibernate.show_sql">true</prop>

</props>

</property>

<property name="mappingResources">


94

<value>domen/Projekat.hbm.xml</value>

<value>domen/Programer.hbm.xml</value>

...

</property>

</bean>

4.2.2. Klasa HibernateTemplate

Klasa HibernateTemplate predstavlja pomoćnu klasu, koja u kontekstu integracije Spring i

Hibernate okvira nudi alternativu direktnom korišćenju Hibernate Session API-ja za pristup

podacima u bazi podataka. HibernateTemplate klasa nudi čitav niz template metoda43 koje imaju

isti potpis kao i metode Hibernate Session API-ja. Prednost korišćenja template metoda

HibernateTemplate klase u odnosu na direktno korišćenje metoda Session API-ja je u tome što

algoritam template metoda omogućava da se tim metodama delegira upravljanje transakcijama i Hibernate sesijama, dok programer prilikom poziva ovih metoda treba da vodi računa samo o perzistentnim objektima, ili upitima koji se prosleđuju ovim metodama.

Sledi primer definicije HibernateTemplate bean-a:

<bean id="hibernateTemplate"

class="org.springframework.orm.hibernate3.HibernateTemplate">

<property name="sessionFactory">

<ref bean="sessionFactory"/>

</property>

</bean>

<bean id="projekatDao" class="dao.ProjekatDaoImpl">

<property name="hibernateTemplate">

<ref bean="hibernateTemplate"/>

</property>

</bean>



HibernateTemplate klasa nudi jednostavan mehanizam poziva (callback). U tu svrhu

koristi se interfejs HibernateCallback koji definiše samo jednu metodu.

Object doInHibernate(Session session)

throws HibernateException, SQLException;

43 Template Method uzor (pattern) – Definiše skelet algoritma neke operacije, prenoseći odgovornost izvršenja pojedinih koraka algoritma do podklasa. Template method omogućava podklasama da redefinišu neke od koraka algoritma bez promene algoritamske strukture [8].


95

U sledećem primeru prikazan je način korišćenja HibernateTemplate klase za učitavanje

jednog objekta klase Projekat iz baze podataka.

public Projekat vratiProjekat(final Integer id){

return (Projekat) hibernateTemplate.execute(new HibernateCallback() {

public Object doInHibernate(Session session) throws

HibernateException, SQLException {

return session.load(Projekat.class, id);

}

});

}

Na sličan način moguće je izvršiti čitanje objekta klase Projekat korišćenjem template

metode load(), što je prikazano sledećim primerom:

public Projekat vratiProjekat(Integer id){

return (Projekat)hibernateTemplate.load(Projekat.class, id);

}

Najveća prednost korišćenja HibernateTemplate klase je u tome što template metode ove

klase automatski vrše konverziju generisanih HibernateException izuzetaka u odgovarajući

izuzetak iz DataAccessException hijerarhije izuzetaka koje nudi Spring okvir. Izuzeci iz

DataAccessException hijerarhije predstavljaju omotač (wrapper) oko originalnog izuzetka, tako

da ne postoji mogućnost gubljenja informacije o nastaloj grešci koja je prozrokovala generisanje originalnog izuzetka. Bitno je istaći da su izuzeci iz DataAccessException hijerarhije

neproveravani (unchecked), što je, kako ističu autori Spring okvira, generalna strategija kad su u pitanju izuzeci koje okvir generiše. Izuzeci u Hibernate okviru su počev od verzije 3.0. takođe neproveravani (unchecked).

4.2.3. Klasa HibernateDaoSupport

U prethodnom podnaslovu je prikazano kako se preko klase HibernateTemplate pristupa

servisima koje pruža Hibernate Session API. U okviru paketa org.springframework.orm.

hibernate.support Spring okvir nudi još jednu pomoćnu klasu, HibernateDaoSupport, koja

omogućava kreiranje objekta klase HibernateTemplate, kao i pristup kreiranom objektu. Ukoliko

se želi koristiti klasa HibernateDaoSupport, potrebno ju je naslediti (extend) u korisničkim DAO

klasama. Na taj način korisničke DAO klase nasleđuju metode set/getHibernateTemplate(),

odnosno set/getSessionFactory().


96

Postoje dve alternative za konfigurisanje bean-ova DAO klasa koje nasleđuju klasu HibernateDaoSupport. Ukoliko se bean klase HibernateTemplate definiše kao što je prikazano

u prethodnom podnaslovu, neophodno je samo povezati atribut hibernateTemplate klase

HibernateDaoSupport sa prethodno definisanim HibernateTemplate bean-om. Nakon toga se

objektu klase HibernateTemplate može pristupiti u korisničkim DAO klasama korišćenjem

metode getHibernateTemplate(). Sledi primer:

public class ProjekatDaoImpl extends HibernateDaoSupport implements

ProjekatDao {


return (Projekat)getHibernateTemplate().load(Projekat.class, id);

}

...

...

}


<property name="hibernateTemplate" ref="hibernateTemplate"/>

</bean>

<bean id="hibernateTemplate"

class="org.springframework.orm.hibernate3.HibernateTemplate">

<property name="sessionFactory">

<ref bean="sessionFactory"/>

</property>

</bean>

Druga opcija je da se bean-ovi korisničkih DAO klasa povežu sa SessionFactory bean-om.

U ovom slučaju nije potrebno definisati bean HibernateTemplate klase, pošto se u okviru

setSessionFactory()metode HibernateDaoSupport klase kreira objekat HibernateTemplate

klase, koji se istovremeno povezuje sa SessionFactory bean-om. Sledi primer:

public class ProjekatDaoImpl extends HibernateDaoSupport implements

ProjekatDao {


return (Projekat)getHibernateTemplate().load(Projekat.class, id);

}

...

}


<property name="sessionFactory" ref="sessionFactory"/>

</bean>


97

4.3. UPRAVLJANJE TRANSAKCIJAMA

Transakcije, odnosno upravljanje transakcijama predstavljaju jedan od osnovnih koncepata u razvoju poslovnih aplikacija. U okviru ovog poglavalja biće data definicija i osobine koje treba da zadovolji transakcija, zatim prikaz mehanizama za upravljanje transakcijama koje pruža Spring okvir.

4.3.1. Definicija i osobine transakcije

Baza podataka je zajednički resurs koji istovremeno (konkurentno) koristi veći broj programa. Pri ovakvom radu može doći do mnogih neželjenih efekata[10]:

otkaz sistema u toku izvršenja nekog programa koji može ostaviti bazu u nekonzistentnom stanju;

neželjena interferencija dva ili više programa nad podacima za koje istovremeno konkurišu, može, takođe da dovede bazu podataka u nekonzistentno stanje.

Osnovni cilj baze podataka je da omogući efikasnu obradu transakcija. Transakcija je jedno izvršenje „logičke jedinice posla“, jedno izvršenje neke logičke celine jednog programa ili jedno izvršenje celog programa. U jednom vremenskom trenutku nad bazom podataka se izvršava više transakcija.

Transakcija mora da poseduje sledeće osobine (tzv. ACID osobine transakcije)[10]:

Atomnost (Atomicity): Skup aktivnosti nad bazom podataka koje se izvršavaju po principu „sve ili ništa“ (ili su sve aktivnosti uspešno obavljene ili je baza podataka ostala nepromenjena) je atomski skup aktivnosti;

Konzistentnost (Consistency): Izvršenje transakcije treba da prevede bazu podataka iz jednog u drugo konzistentno stanje;

Izolacija (Isolation): Po pravilu, transakcija ne treba svoje promene baze podataka da učini vidljivim drugim transakcijama pre nego što se ona okonča, odnosno promene potvrde u bazi podataka;

Trajnost (Durability): Kada su u bazi podataka potvrđene promene koje je izvršila neka transakcija, ove promene se više ne mogu izgubiti.

4.3.2. Transakcije u Spring okviru

U klasičnim Java programima korišćenje transakcija je direktno vezano za programski kôd, pri čemu svaka promena u načinu korišćenja transakcija podrazumeva izmene u programskom kôdu koji se odnosi na upravljanje transakcijama. Sa druge strane, EJB specifikacija omogućava kontejnersko upravljanje transakcijama (container-managed trasactions, CMT), pri čemu se


98

specifikacija upravljanja transakcijama definiše u odgovarajućim konfiguracionim datotekama. Ovo predstavlja jednu od najčešće korišćenih osobina EJB-a, međutim, kao glavni nedostatak ovog pristupa ističe se neophodnost postojanja EJB kontejnera.

Rešenje koje Spring okvir nudi ne zahteva korišćenje EJB kontejnera, tako da je moguće koristiti i jednostavni servlet kontejner ili samostalno (standalone) okruženje. Pored toga, Spring okvir omogućava i deklarativno upravljanje transakcijama korišćenjem Spring AOP modula.

Spring-ov transakcioni okvir ostavlja mogućnost izbora između dve strategije za razgraničenje (demarcation) transakcija. To je moguće odraditi programskim putem, direktnim korišćenjem API-ja koji pruža PlatformTransactionManagement interfejs, ili korišćenjem

TransactionTemplate klase. Drugi pristup podrazumeva korišćenje Spring AOP modula za

deklarativno upravljanje transakcijama. U tu svrhu može da se koristi kombinacija ProxyFacoryBean i TransactionInteceptor klasa, ili klasa TransactionProxyFactoryBean.

Sledeća odluka koju je potrebno doneti odnosi se na izbor strategije upravljanja transakcijama u smislu izbora konkretne implementacije PlatformTransactionManagement

interfejsa. U suštini, ovaj izbor se svodi na izbor implementacije koja odgovara tehnologiji koja se koristi za pristup podacima. U sledećoj tabeli (Tabela 9) prikazana je lista tehnologija za pristup podacima koje podržava Spring-ova transakciona infrastruktura, odgovarajuće implementacije transakcionog menadžera i klase koje podržavaju rad sa transakcijama.

Ključna osobina ovakvog pristupa u realizaciji transakcione infrastrukture u Spring okviru jeste mogućnost jednostavne promene transakcionog menadžera, bez potrebe da se aplikacioni kôd menja. Jedino što je potrebno izmeniti jesu konfiguracioni podaci.

Tehnologija Implementacija int. PlatformTransactionManagement

Klase

JDBC DataSourceTransactionManager

JtaTransactionManager

JdbcTemplate i sve klase iz org.springframework.jdbc.

object paketa.

iBatis DataSourceTransactionManager


SqlMapClientTemplate i SqlClientTemplate

Hibernate HibernateTransactionManager


HibernateTemplate i HibernateInterceptor

JDO JdoTransactionManager


JdoTemplate i JdoInterceptor

Apache OJB PersistenceBrokerTransactionManager


PersistenceBrokerTemplate

JMS JmsTransactionManager

JmsTemplate

Tabela 9 : Transakcioni menadžeri u Spring okviru


99

4.3.3. Atributi transakcija

Konfigurisnje transakcija podrazumeva podešavanje vrednosti određenih transakcionih atributa. U tom kontekstu, moguće je izvršiti podešavanja sledećih atributa transakcije:

Propagaciono ponašanje (propagation behavior);

Nivo izolovanosti (isolation);

Dužinu trajanja transakcije (timeout);

Read-only atribut

4.3.3.1. Propagaciono ponašanje

Propagaciono ponašanje je atribut transakcije kojim se definiše opseg transakcija i način na koji transakcije ostvaruju međusobnu interakciju. Na raspolaganju je sedam različitih opcija prikazanih u sledećoj tabeli.

Propagaciona konstanta Opis

PROPAGATION_REQUIRED

Metoda mora da se izvrši u okviru transakcije. Ukoliko ne postoji tekuća transakcija kreira se nova. Ova opcija ujedno predstavlja i podrazumevanu vrednost.

PROPAGATION_SUPPORTS

Ukoliko postoji tekuća transakcija, metoda se izvršava u okviru te transakcije. Ukoliko ne postoji transakcija, metoda se izvršava van transakcije.

PROPAGATION_MANDATORY

Metoda mora da bude pokrenuta u okviru tekuće transakcije. Ukoliko transakcija ne postoji baca se izuzetak.

PROPAGATION_REQUIRES_NEW

Metoda se pokreće u okviru sopstvene, nove transakcije. Ukoliko je neka druga transakcija u toku, ta transakcija će biti suspendovana do završetka novokreirane transakcije.

PROPAGATION_NOT_SUPPORTED

Metoda se izvršava izvan transakcije. Ukoliko postoji tekuća transakcija, ta transakcija se suspednuje do završetka izvršenja metode.

PROPAGATION_NEVER

Metoda se izvršava izvan transakcije. Ukoliko postoji tekuća transakcija biće bačen izuzetak.

PROPAGATION_NESTED

Ukoliko postoji tekuća transakcija, metoda se izvršava u ugnježdenoj transakciji. Ukoliko ne postoji tekuća transakcija, ponaša se kao PROPAGATION_REQUIRED.

Tabela 10 : Propagaciona ponašanja


100

Ukoliko se drugačije ne navede, podrazumevana ponašanje je PROPAGATION_REQUIRED. Sve

prikazane vrednosti, izuzev PROPAGATION_NESTED postoje pod istim imenom i u EJB specifikaciji.

4.3.3.2. Nivo izolovanosti

Serijabilnost skupa transakcija je najviši stepen njihove međusobne izolovanosti u izvršenju. Da bi se ostvario veći paralelizam u izvršenju skupa transakcija, a samim tim i poboljšale performanse sistema, Spring okvir dozvoljava i niže stepene izolovanosti transakcija.

Pre samog prikaza različitih nivoa izolovanosti koje Spring okvir podržava, potrebno je dati prikaz načina narušavanja serijabilnosti izvršenja skupa transakcija. Ukoliko posmatramo dve transakcije, T1 i T2, narušenja serijabilnosti njihovog izvršenja mogu da budu sledeća [10]:

Prljavo čitanje (dirty read) – ukoliko transakcija T1 ažurira neki podatak, zatim transakcija T2 pročita taj podatak, nakon čega transakcija T1 izvrši rollback, sledi da je transakcija T2 pročitala nepostojeći podatak, odnosno izvršila „prljavo čitanje“.

Neponovljivo čitanje (nonrepeatable read) – u jednoj transakciji, ponovno čitanje istih podataka mora dati isti rezultat. Ukoliko transakcija T1 pročita neki podatak, zatim ga transakcija T2 promeni, ponovno čitanje istog podatka u transakciji T1 neće dati isti rezultat.

Fantomsko čitanje (fantoms) – ako transakcija T1 preuzme upitom skup n-torki koje zadovoljavaju dati uslov, a posle toga transakcija T2 doda novu n-torku koja zadovoljava isti uslov, novo izvršenje istog upita u transakciji T1 sadržaće i novu „fantomsku“ n-torku.

U sledećoj tabeli prikazani su različiti nivoi izolovanosti kao i narušenja serijabilnosti koja svaki od nivoa dozvoljava:

ponašanje

nivo izolovanosti Prljavo čitanje

Neponovljivo čitanje

Fantomsko čitanje

ISOLATION_READ_UNCOMMITTED DA DA DA

ISOLATION_READ_COMMITED NE DA DA

ISOLATION_REPEATABLE_READ NE NE DA

ISOLATION_SERIALIZABLE NE NE NE

ISOLATION_DEFAULT Podrazumevani nivo za izvor podataka.

Tabela 11 : Nivoi izolovanosti transakcija


101

Različiti nivoi izolovanosti dozvoljavaju različite načine narušavanja serijabilnosti. Spring okvir, pored četiri nivoa izolacije koja definiše SQL stadnard, podržava i ISOLATION_DEFAULT nivo

izolovanosti. Ukoliko se ovaj atribut transakcije postavi na ISOLATION_DEFAULT nivo, koristiće se

podrazumevani nivo izolovanosti SUBP-a sa kojim aplikacija komunicira. U slučaju, na primer, MySql SUBP-a, podrazumevani nivo izolovanosti je REPEATABLE-READ.

4.3.3.3. Timeout i Read-only atributi

Timeout atributom specificira se kolika je maksimalna dozvoljena dužina trajanja transakcije u sekundama. Nakon isteka definisanog intervala vremena, menadžer transakcija će otkazati transakciju i poništiti sve promene koje je transakcija napravila. Za podešavanje ove opcije može da se koristi TIMEOUT_DEFAULT konstanta, ili bilo koji pozitivan broj.

Read only atributom specificira se da transakcija izvršava samo operaciju čitanja, što omogućava primenu odgovarajućih mehanizama optimizacije od strane baze podataka koje unapređuju ovakve transakcije.

Read only i timeout atribute moguće je specificirati samo za transakcije koje propagacionim ponašanjem mogu da pokrenu novu transakciju, pošto se vreme trajanja transakcije meri od trenutka startovanja iste.

4.3.4. Deklarativno upravljanje transakcijama

Kao što je ranije napomenuto, Spring okvir nudi mogućnost programskog i deklarativnog upravljanja transakcijama. U ovom delu biće prikazan način korišćenja deklarativnog upravljanja transakcijama.

Moguća su dva pristupa: korišćenje kombinacije ProxyFactoryBean i Transaction

Interceptor klasa, ili korišćenje TransactionProxyFactoryBean klase. Prva opcija omogućava

veću kontrolu nad transakcijama i veću fleksibilnost, međutim u najvećem broju slučajeva TransactionProxyFactoryBean klasa nudi sve neophodne funkcionalnosti. Ova klasa u sebi

objedinjava funkcionalnosti klasa ProxyFactoryBean i Transaction Interceptor, takođe,

omogućava i definisanje transakcionih atributa. U aplikaciji koja je dokumentovana u studijskom primeru korišćena je ova klasa, te u nastavku sledi primer njene definicije.

Pre svega, potrebno je izvršiti definiciju transakcionog menadžera. Menadžeri transakcija u Spring okviru predstavljaju implementacije PlatformTransactionManager interfejsa.

HibernateTransactionManager klasa je realizacija ovog interfejsa koja se koristi ukoliko se

perzistencija podataka ostvaruje korišćenjem Hibernate okvira. Ovu klasu neophodno je povezati sa SessonFactory bean-om koja je odgovorna za kreiranje Session objekata, pošto se

komunikacija sa SUBP-om u Hibernate okviru ostvaruje preko Session API-ja. U suštini, klasa


102

HibernateTransactionManager delegira odgovornost upravljanja transakcijama

net.sf.hibernate.Transaction objektu, dobijenom od objekta klase Session. Sledi defninicija

HibernateTransactionManager objekta:

<bean id="transactionManager"

class="org.springframework.orm.hibernate3.HibernateTransactionManager">

<property name="sessionFactory" ref="sessionFactory"/>

</bean>

Zatim je potrebno definisati bean klase TransactionProxyFactoryBean koja, kao što je

već rečeno, objedinjuje funkcionalnosti ProxyFactoryBean i Transaction Interceptor klasa.

target atributom ove klase referencira se bean koji će biti obuhvaćen proxy objektom, dok se

transactionAttributes atributom specificiraju transakcioni atributi. Sledi primer definicije

ovog bean-a:

<bean id="projekatServis" class="org.springframework.transaction.interceptor.

TransactionProxyFactoryBean">

<property name="transactionManager" ref="transactionManager"/>

<property name="target">

<bean class="servis.ProjekatServisImpl">

<property name="projekatDao" ref="projekatDao"/>

</bean>

</property>

<property name="transactionAttributes">

<props>

<prop key="ucitaj*">PROPAGATION_SUPPORTS, readOnly</prop>

<prop key="snimi*">PROPAGATION_REQUIRED </prop>

<prop key="azuriraj*">PROPAGATION_REQUIRED </prop>

</props>

</property>

</bean>

Prethodnim primerom prikazana je definicija bean-a TransactionProxyFactoryBean

klase koji predstavalja proxy klase ProjekatServisImpl.

Transakcionim atributima definisano je da sve metode koje počinju44 rečju „ucitaj“ vrše samo operaciju čitanja (readOnly) i da se izvršavaju u okviru tekuće transakcije, ukoliko ona postoji. Ukoliko transakcija ne postoji, ove metode će se izvršiti van transakcije. Za metode koje počinju rečima „snimi“, ili „azuriraj“ definisano je da moraju da se izvršavaju u okviru transakcije.

44 Prilikom specifikacije vrednosti key atributa dozovljeno je korišćenje džoker znaka “*” (znak koji zamenjuje sva slova

u nastavku), tako da se vrednost “ucitaj*” odnosti na sve metode koje počinju rečju „ucitaj“.


103

5. STUDIJSKI PRIMER – RAZVOJ APLIKACIJE KORIŠĆENJEM

LARMANOVE METODE

U okviru ovog poglavlja biće prikazan razvoj Web aplikacije za praćenje softverskih grešaka bazirane na Spring i Hibernate tehnologijama, korišćenjem Larmanove metode razvoja softvera. Razvoj softverskog sistema sastoji se iz sledećih faza[8]:

Prikupljanje zahteva korisnika,

Analize,

Projektovanja,

Implementacije, i

Testiranja.

5.1. KORISNIČKI ZAHTEV – VERBALNI MODEL

Potrebno je projektovati i implementirati informacioni sistem za praćenje grešaka u softverskim projektima. Sistem treba da omogući evidenciju o članovima tima koji učestvuju na projektu, kao i o lideru projekta. Članovi projektnog tima koriste sistem da bi evidentirali prijavljene i uočene greške u softveru, kao i da bi izvršili promenu statusa greške u trenutku kad je greška ispravljena, ili joj se na neki drugi način promeni status. Sistem treba da omogući izdavanje izveštaja o greškama po prioritetu rešavanja grešaka, po članu projektnog tima koji je zadužen za rešavanje prijavljene greške, kao i izveštaje o greškama po svakom projektu.

5.2. OPIS KORISNIČKOG ZAHTEVA POMOĆU SLUČAJEVA KORIŠĆENJA(SK)

U Larmanovoj metodi razvoja softvera, korisnički zahtevi se opisuju pomoću modela slučajeva korišćenja (Use-Case Model). Model slučajeva korišćenja sastoji se od skupa slučajeva korišćenja, aktora i veza između slučajeva korišćenja i aktora[8].

5.2.1. Slučajevi korišćenja

Na osnovu verbalnog modela mogu da se uoče sledeći slučajevi korišćenja:


104

1. Unos projekta 2. Prikaz liste projekata 3. Unos programera 4. Ažuriranje programera 5. Prikaz liste programera 6. Dodavanje članova projektnog tima 7. Brisanje članova iz projektnog tima 8. Unos greške 9. Promena stanja greške 10. Prikaz grešaka po projektu 11. Prikaz grešaka po programeru 12. Prikaz grešaka po prioritetu 13. Prijavljivanje korisnika

Slika 21 : Dijagram slučajeva korišćenja

5.2.2. Opis slučajeva korišćenja

Slučaj korišćenja (SK) opisuje skup scenarija (use-case pojavljivanja), odnosno skup željenih korišćenja sistema od strane aktora. Scenario opisuje jedno željeno korišćenje sistema od strane korisnika. Scenario se opisuje preko: sekvence akcija i preko interakcija između aktora i sistema. Slučaj korišćenja se sastoji od glavnog i alternativnog scenarija[8].

Aktor (učesnik) predstavlja spoljnog korisnika sistema. On postavlja zahtev sistemu da izvrši jednu ili više sistemskih operacija, po unapred definisanom redosledu[8].

Unos projekta

Prikaz gresaka po prioritetu

Prikaz gresaka po programeru

Prikaz gresaka po projektu Promena stanja greske Unos greske Prijavljivanje korisnika

Brisanje clana projektnog tima

Dodavanje clana projektnog tima

Prikaz liste programeraAzuriranje programeraUnos programera

Korisnik

Prikaz liste projekata


105

Jednu akciju scenarija izvodi ili aktor, ili sistem. Aktor izvodi jednu od tri vrste akcija[8]:

Aktor Priprema Ulaz (Ulazne Argumente(UA)) Za Sistemsku Operaciju (APUSO)

Aktor Poziva sistem da izvrši Sistemsku Operaciju (APSO)

Aktor izvršava NeSistemsku Operaciju (ANSO)

Sistem izvodi dve akcije u kontinuitetu:

Sistem izvršava Sistemsku Operaciju (SO)

Rezultat sistemske operacije se (Izlazni Argumenti (IA)) se prosleđuje do aktora.

SK se u početnim fazama razvoja softvera predstavljaju tekstualno, dok se kasnije oni predstavljaju preko sekvencnih dijagrama, dijagrama saradnje, dijagrama prelaza stanja ili dijagrama aktivnosti. Budući da se za raznoj studijskog primera koristi Larmanova metoda, u kasnijim fazama biće korišćeni sekvencni dijagrami. Tekstualni oblik SK ima sledeću strukturu[8]:

Naziv SK

Aktori SK

Učesnici SK

Preduslovi koji trebaju biti ispunjeni da bi SK počeo da se izvršava

Osnovni scenario izvršenja SK

Postuslovi koji se moraju zadovoljiti da bi se potvrdilo da je SK uspešno izvršen

Alternativna scenarija izvršenja SK

Specijalni zahtevi

Tehnološki zahtevi

Otvorena pitanja

Operacije kod tekstualnog opisa SK se obično predstavljaju pomoću glagola, dok se atributi SK predstavljaju pomoću imenica ili prideva.

U nastavku sledi tekstualni opis slučajeva korišćenja prikazanih u prethodnom podnaslovu.

SK1: Unos projekta

Naziv: Unos projekta Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za unos novog projekta.


106

Osnovni scenario:

1. Korisnik unosi podatke o projektu (APUSO) 2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da sačuva novi projekat (APSO) 4. Sistem kreira i snima novi projekat (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)

Alternativna scenarija:

5.1. Ukoliko sistem nije u mogućnosti da kreira i snimi novi projekat, prikazuje korisniku odgovarajuću poruku (IA). Prekida se izvršenje scenarija.

SK2: Prikaz liste projekata

Naziv: Prikaz liste projekata Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i korisnik ulogovan.

Osnovni scenario:

1. Korisnik poziva sistem da prikaže listu projekata (APSO) 2. Sistem kreira listu projekata (SO) 3. Sistem prikazuje listu projekata korisniku (IA)


3.1. Ukoliko sistem nije u mogućnosti da kreira listu projekata, prikazuje korisniku odgovarajuću poruku (IA). Prekida se izvršenje scenarija.

SK3: Unos programera

Naziv: Unos programera Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i prikazuje web stranu za unos novog programera.

Osnovni scenario:

1. Korisnik unosi podatke o programeru (APUSO) 2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da sačuva novog programera (APSO) 4. Sistem kreira i snima novog programera (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


107


5.1. Ukoliko sistem nije u mogućnosti da kreira i snimi novog programera, prikazuje korisniku odgovarajuću poruku (IA). Prekida se izvršenje scenarija.

S4: Ažuriranje podataka o programeru

Naziv: Ažuriranje podataka o programeru Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za ažuriranje podataka o programeru.

Osnovni scenario:

1. Korisnik unosi nove podatke o programeru (APUSO) 2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da ažurira podatke o programeru (APSO) 4. Sistem ažurira podatke o programeru (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


5.1. Ukoliko sistem nije u mogućnosti da ažurira podatke o programeru, prikazuje korisniku odgovarajuću poruku (IA). Prekida se izvršenje scenarija.

SK5: Prikaz liste programera

Naziv: Prikaz liste programera Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i korisnik ulogovan.

Osnovni scenario:

1. Korisnik poziva sistem da prikaže listu programera (APSO) 2. Sistem kreira listu programera (SO) 3. Sistem prikazuje listu programera (IA)


3.1. Ukoliko sistem nije u mogućnosti da kreira listu programera, prikazuje korisniku odgovarajuću poruku (IA). Prekida se izvršenje scenarija.


108

SK6: Dodavanje članova projektnog tima

Naziv: Dodavanje članova projektnog tima Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za izbor projekta za koji se vrši dodavanje člana tima.

Osnovni scenario:

1. Korisnik bira projekat iz ponuđene liste projekata(APUSO) 2. Korisnik poziva sistem da prikaže tekući projektni tim (APSO) 3. Sistem učitava projetni tim (SO) 4. Sistem prikazuje korisniku tekući projektni tim i formu za unos novog člana tima

(IA) 5. Korisnik bira programera iz ponuđene liste dostupnih programera (APUSO). 6. Korisnik unosi ulogu izabranog programera u projektnom timu (APUSO) 7. Korisnik poziva sistem da snimi novog člana projektnog tima (APSO) 8. Sistem snima novog člana projektnog tima (SO) 9. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


4.1 . Ukoliko su svi dostupni programeri angažovani na projektu, sistem prikazuje poruku da nema dostupnih programera koji mogu da se dodaju projektnom timu (IA). Prekida se izvršenje scenarija.

SK7: Brisanje članova projektnog tima

Naziv: Brisanje članova projektnog tima Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za izbor projekta za koji se vrši brisanje člana tima.

Osnovni scenario:

1. Korisnik bira projekat iz ponuđene liste projekata (APUSO) 2. Korisnik poziva sistem da prikaže projektni tim (APSO) 3. Sistem učitava projektni tim (SO)


109

4. Sistem prikazuje korisniku listu članova prjektnog tima (IA) 5. Korisnik poziva sistem da izbriše člana projektnog tima (APSO) 6. Sistem briše člana projektnog tima (SO) 7. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


4.1. Ukoliko na projektu nije angažovan nijedan programer, sistem prikazuje korisniku poruku da ne može da obriše člana projektnog tima (IA). Prekida se izvršenje scenarija.

SK8: Unos greške

Naziv: Unos greške Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za unos nove greške na projektu.

Osnovni scenario:

1. Korisnik unosi podatke o grešci (APUSO) 2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da sačuva novu grešku (APSO) 4. Sistem kreira i snima novu grešku (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


5.1. Ukoliko sistem nije u mogućnosti da kreira i snimi grešku, prikazuje korisniku odgovarajuću poruku (IA). Prekida se izvršenje scenarija.

SK9: Promena stanja greške

Naziv: Promena stanja greške Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu sa informacijom o grešci i formom za unos novog stanja greške.

Osnovni scenario:


110

1. Korisnik unosi podatke o novom stanju greške (APUSO) 2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da sačuva novo stanje greške (APSO) 4. Sistem kreira i snima novo stanje greške (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


5.1. Ukoliko sistem nije u mogućnosti da kreira i snimi novo stanje greške, prikazuje korisniku odgovarajuću poruku (IA). Prekida se izvršenje scenarija.

SK10: Prikaz grešaka po projektu

Naziv: Prikaz grešaka po projektu Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za izbor

projekta po kome se kreira izveštaj.

Osnovni scenario:

1. Korisnik bira projekat iz liste projekata (APUSO) 2. Korisnik poziva sistem da prikaže izveštaj (APSO) 3. Sistem pronalazi greške za izabrani projekat (SO) 4. Sistem prikazuje izveštaj o greškama (IA)


4.1. Ukoliko sistem nije u mogućnosti da prikaže izveštaj o greškama, prikazuje korisniku odgovarajuću poruku (IA). Prekida se izvršenje scenarija.

SK11: Prikaz grešaka po programeru


programera po kome se kreira izveštaj.

Osnovni scenario:


111

1. Korisnik bira programera iz liste (APUSO) 2. Korisnik poziva sistem da prikaže izveštaj (APSO) 3. Sistem pronalazi greške za izabranog programera (SO) 4. Sistem prikazuje izveštaj o greškama (IA)



SK12: Prikaz grešaka po prioritetu

Naziv: Prikaz grešaka po prioritetu Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za izbor

prioriteta greške po kome se kreira izveštaj.

Osnovni scenario:

1. Korisnik bira prioritet grešaka iz ponuđene liste (APUSO) 2. Korisnik poziva sistem da prikaže izveštaj (APSO) 3. Sistem pronalazi greške po izabranom prioritetu (SO) 4. Sistem prikazuje izveštaj o greškama (IA)



SK13: Prijavljivanje korisnika

Naziv: Prijavljivanje korisnika Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i prikazuje web stranu za prijavljivanje korisnika.

Osnovni scenario:

1. Korisnik unosi korisničko ime i lozinku (APUSO) 2. Korisnik proverava ispravnost unetih podataka (ANSO)


112

3. Korisnik poziva sistem da izvrši prijavljivanje (APSO) 4. Sistem izvršava prijavljivanje (SO) 5. Sistem prikazuje početnu web stranu. (IA)


5.1. Ukoliko korisnik unese pogrešne podatke za prijavljivanje sistem obaveštava korisnika da prijavaljivanje nije uspešno izvršeno. Sistem prikazuje korisniku web stranu za prijavljivanje (IA). Prekida se izvršenje scenarija

5.3. ANALIZA

Faza analize opisuje logičku strukturu sistema i ponašanje softverskog sistema (poslovnu logiku). Ponašanje sistema je opisano pomoću sistemskih dijagrama sekvenci, koji se prave za svaki slučaj korišćenja (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.

5.3.1. Ponašanje sistema

Ponašanje softverskog sistema se može opisati pomoću UML sekvencnih dijagrama, ili preko dijagrama saradnje. Sistemski dijagram sekvenci prikazuje, za izdvojeni scenario slučaja korišćenja, događaje u određenom redosledu, koji uspostavljaju interakciju između aktora i softverskog sistema.

Događaj koji napravi aktor je pobuda za poziv sistemske operacije. Preciznije rečeno, događaj koji napravi aktor prihvata primalac događaja, koji nakon toga prihvata sistemsku operaciju. To znači da aktor ne poziva sistemsku operaciju neposredno, već to čini preko posrednika (primaoca događaja). Poziv sistemske operacije ukazuje na interakciju između aktora i sistema. Za događaj koji predstavlja pobudu za poziv sistemske operacije se često kaže da je to sistemski događaj.

Definisanjem sistemskih događaja jasno se određuje granica između aktora i softerskog sistema. Broj sistemskih događaja jednak je broju APSO akcija koje izvodi aktor. Za svaki SK, preciznije rečeno, za svaki scenario SK, prave se sistemski dijagrami sekvenci, i to samo za APSO i IA akcije scenarija. Dakle, na sistemskim dijagramima sekvenci se ne vide APUSO, SO i ANSO akcije[8].


113

5.3.1.1. Sistemski dijagrami sekvenci(DS)

DS1: Dijagram sekvenci slučaja korišćenja: SK1: Unos projekta

Osnovni scenario:

1. Korisnik poziva sistem da sačuva novi projekat (APSO) 2. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)



Uvedene sistemske operacije:

boolean snimiProjekat(Projekat)

: Korisniksistem

1: snimiProjekat(Projekat)

2: PORUKA - uspesno izvrsena operacija

: Korisniksistem

1: snimiProjekat(Projekat)

2: PORUKA - neuspesno izvrsena operacija


114

DS2: Dijagram sekvenci slučaja korišćenja: SK2: Prikaz liste projekata

Osnovni scenario:

1. Korisnik poziva sistem da prikaže listu projekata (APSO) 2. Sistem prikazuje listu projekata korisniku (IA)




List vratiListuProjekata()

: Korisniksistem

1: vratiListuProjekata

2: ListaProjekata

: Korisniksistem

1: vratiListuProjekata

2: PORUKA - neuspesno kreiranje liste


115

DS3: Dijagram sekvenci za slučaj korišćenja: SK3: Unos programera

Osnovni scenario:

1. Korisnik poziva sistem da sačuva novog programera (APSO) 2. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


2.1. Ukoliko sistem nije u mogućnosti da kreira i snimi novog programera, prikazuje korisniku odgovarajuću poruku (IA). Prekida se izvršenje scenarija.


boolean snimiProgramera(Programer)

: Korisniksistem

1: snimiProgramera(Programer)


: Korisniksistem

1: snimiProgramera(Programer)



116

DS4: Dijagram sekvenci za slučaj korišćenja: SK4: Ažuriranje podataka o programeru

Osnovni scenario:

1. Korisnik poziva sistem da ažurira podatke o programeru (APSO) 2. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)




boolean azurirajProgramera(Programer)

: Korisniksistem

1: azurirajProgramera(Programer)


: Korisniksistem

1: azurirajProgramera(Programer)



117

DS5: Dijagram sekvenci za slučaj korišćenja: SK5: Prikaz liste programera

Osnovni scenario:

1. Korisnik poziva sistem da prikaže listu programera (APSO) 2. Sistem prikazuje listu programera (IA)




List vratiListuProgramera()

: Korisniksistem

1: vratiListuProgramera

2: ListaProgramera

: Korisniksistem


1: vratiListuProgramera


118

DS6: Dijagram sekvenci za slučaj korišćenja: SK6: Dodavanje članova projektnog tima

Osnovni scenario:

1. Korisnik poziva sistem da prikaže tekući projektni tim (APSO) 2. Sistem prikazuje korisniku tekući projektni tim i formu za unos novog člana tima

(IA) 3. Korisnik poziva sistem da dodeli nove članove projektu (APSO) 4. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


2.1. Ukoliko su svi dostupni programeri angažovani na projektu, sistem prikazuje poruku da nema dostupnih programera koji mogu da se dodaju projektnom timu (IA). Prekida se izvršenje scenarija.

: Korisniksistem

3: snimiClanaProjektnogTima(ClanTima)

4: PORUKA -uspesno izvrsena operacija

1: ucitajProjektniTim(projekatId)

2: projektniTim

: Korisniksistem

1: ucitajProjektniTim(projektId)

2: PORUKA - nema dostupnih programera


119


List ucitajProjektniTim(projekatId)

boolean snimiClanaProjektnogTima(ClanTima)

DS7: Dijagram sekvenci za slučaj korišćenja: SK7: Brisanje članova projektnog tima

Osnovni scenario:

1. Korisnik poziva sistem da prikaže projektni tim (APSO) 2. Sistem prikazuje korisniku listu članova projektnog tima (IA) 3. Korisnik poziva sistem da izbriše članove iz projektnog tima (APSO) 4. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)



: Korisniksistem

3: brisiClanaProjektnogTima(ClanTima)

4: PORUKA -uspesno izvrsena operacija


2: projektniTim


120


boolean brisiClanaProjektnogTima(ClanTima)

DS8: Dijagram sekvenci za slučaj korišćenja: SK8: Unos greške

Osnovni scenario:

1. Korisnik poziva sistem da sačuva novu grešku (APSO) 2. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)

: Korisniksistem

1: ucitajProjektniTim(projektId)

2: PORUKA - nije formiran projektni tim

: Korisniksistem

1: snimiGresku(Greska)



121



Uvedne sistemske operacije:

boolean snimiGresku(Greska)

DS9: Dijagram sekvenci za slučaj korišćenja: SK9: Promena stanja greške

Osnovni scenario:

1. Korisnik poziva sistem da sačuva novo stanje greške (APSO) 2. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)

: Korisniksistem

1: snimiGresku(Greska)


: Korisniksistem

1: snimiStanjeGreske(StanjeGreske)



122




boolean snimiStanjeGreske(StanjeGreske)

DS10: Dijagram sekvenci za slučaj korišćenja: SK10: Prikaz grešaka po projektu

Osnovni scenario:

1. Korisnik poziva sistem da prikaže izveštaj (APSO) 2. Sistem prikazuje izveštaj o greškama (IA)

: Korisniksistem

1: snimiStanjeGreske(StanjeGreske)


: Korisniksistem

1: vratiListuGreska(Projekat)

2: ListaGresaka


123




List vratiListuGresaka(Projekat)

DS11: Dijagram sekvenci za slučaj korišćenja: SK11: Prikaz grešaka po programeru

Osnovni scenario:


: Korisniksistem

1: vratiListuGreska(Projekat)


: Korisniksistem

1: vratiListuGreska(Programer)

2: ListaGresaka


124




List vratiListuGresaka(Programer)

DS12: Dijagram sekvenci za slučaj korišćenja: SK12: Prikaz grešaka po prioritetu

Osnovni scenario:


: Korisniksistem

1: vratiListuGreska(Programer)


: Korisniksistem

1: vratiListuGreska(prioritet)

2: ListaGresaka


125




List vratiListuGresaka(prioritet)

DS13: Dijagram sekvenci za slučaj korišćenja: SK13: Prijavljivanje korisnika

Osnovni scenario:

1. Korisnik poziva sistem da izvrši prijavljivanje (APSO) 2. Sistem prikazuje početnu web stranu. (IA)

sistem : Korisnik

1: vratiListuGreska(prioritet)


: Korisniksistem

1: prijaviKorisnika(Programer)



126


2.1. Ukoliko korisnik unese pogrešne podatke za prijavljivanje sistem obaveštava korisnika da prijavaljivanje nije uspešno izvršeno. Sistem prikazuje korisniku web stranu za prijavljivanje (IA).


boolean prijavi(Programer)

Kao rezultat analize sistemskih dijagrama sekvenci dobijeno je 13 sistemskih operacije koje potrebno projektovati:

1. boolean snimiProjekat(Projekat) 2. List vratiListuProjekata() 3. boolean snimiProgramera(Programer) 4. boolean azurirajProgramera(Programer) 5. List vratiListuProgramera() 6. List ucitajProjektniTim(projekatId) 7. boolean snimiClanaProjektnogTima(ClanTima) 8. boolean brisiClanaProjektnogTima(ClanTima) 9. boolean snimiGresku(Greska) 10. boolean snimiStanjeGreske(StanjeGreske) 11. List vratiListuGresaka(Projekat) 12. List vratiListuGresaka(Programer) 13. List vratiListuGresaka(prioritet) 14. boolean prijavi(Programer)

: Korisniksistem

1: prijaviKorisnika(Programer)

2: PORUKA - pogresni podaci za prijavu


127

5.3.1.2. Definisanje ugovora o sistemskim operacijama

Sistemskim operacijama opisuje se ponašanje softverskog sistema. Sistemska operacija ima svoj potpis, koji sadrži ime metode i opciono ulazne i\ili izlazne parametre. Ona je javna i njoj se može pristupiti iz okruženja softverskog sistema[8].

Za svaku sistemsku operaciju prave se ugovori koji opisuju njeno ponašanje. Ugovorom se definiše šta operacija treba da uradi, bez objašnjenja kako će to da uradi. Ugovori se sastoje iz sledećih sekcija[8]:

operacija – ime operacije i njeni ulazni argumenti

veza sa SK – imena SK u kojima se poziva sistemska operacija

preduslovi – pre izvršenja sistemske operacije moraju biti zadovoljeni određeni preduslovi (sistem mora biti u odgovarajućem stanju)

postuslovi – posle izvršenja sistemske operacije u sistemu moraju biti zadovoljeni određeni postuslovi (sitem mora biti u odgovarajućem stanju ili se poništava rezultat operacije)

Ugovor1(UG1):SnimiProjekat Operacija: snimiProjekat(Projekat, progId):boolean Veza sa SK: SK1 Preduslovi:- Postuslovi: Snimljen je novi projekat

UG2: PrikažiListuProjekata Operacija: vratiListuProjekata():List Veza sa SK: SK2 Preduslovi:- Postuslovi: Prikazana je lista projekata

UG3: SnimiProgramera Operacija: snimiProgramera(Programer) Veza sa SK: SK3 Preduslovi:- Postuslovi: Snimljen je novi programer

UG4: AžurirajProgramera Operacija: azuriraj Programera(Programer):boolean Veza sa SK: SK4 Preduslovi:- Postuslovi: Ažurirani su podaci o programeru

UG5: PrikažiListuProgramera Operacija: vratiListuProgramera():List Veza sa SK: SK5 Preduslovi:- Postuslovi: Prikazana je lista programera


128

UG6: UčitajProjektniTim

Operacija: ucitajProjektniTim(projekatId):List Veza sa SK: SK6, SK7 Preduslovi:- Postuslovi: Učitan projektni tim

UG7: SnimiČlanaProjektnogTima Operacija: snimiClanaProjektnogTima(ClanTima, projekatId, programerId):boolean Veza sa SK: SK6 Preduslovi:- Postuslovi: Snimljen je novi clan projektnog tima

UG8: BrisiClanaProjektnogTima Operacija: brisiClanaProjektnogTima(ClanTima, projekatId, programerId):boolean Veza sa SK: SK7 Preduslovi:- Postuslovi: Obrisan je član projektnog tima

UG9: SnimiGrešku Operacija: snimiGrešku(Greška, projId, prPrId, prZadId):boolean Veza sa SK: SK8 Preduslovi:- Postuslovi: Snimljena je nova greška

UG10: SnimiStanjeGreške Operacija: snimiStanjeGreske(StanjeGreske):boolean Veza sa SK: SK9 Preduslovi:- Postuslovi: Snimljeno je novo stanje greške

UG11:PrikažiGreškePoProjektu Operacija: vratiListuGresaka(Projekat):list Veza sa SK: SK10 Preduslovi:- Postuslovi: Prikazana je lista grešaka

UG12:PrikažiGreškePoProgrameru Operacija: vratiListuGresaka(Programer):list Veza sa SK: SK11 Preduslovi:- Postuslovi: Prikazana je lista grešaka


129

UG13:PrikažiGreškePoPrioritetu Operacija: vratiListuGresaka(prioritet):list Veza sa SK: SK12 Preduslovi:- Postuslovi: Prikazana je lista grešaka

UG14:PrijaviKorisnika Operacija: prijavi(Programer):boolean Veza sa SK: SK13 Preduslovi:- Postuslovi: Korisnik je prijavljen


130

5.3.2. Struktura sistema

Struktura softverskog sistema se opisuje pomoću konceptualnog (domenskog) modela. Konceptualni model opisuje konceptualne klase (domenske objekte) i asocijacije između konceptualnih klasa. Često se za konceptualne modele kaže da su to domenski modeli ili modeli objektne analize.

Koncepti (konceptualne klase) predstvaljaju atribute softverskog sistema. To znači da koncepti opisuju strukturu softverskog sistema. Konceptualne klase sastoje se od atributa koji opisuju osobine klase[8].

5.3.2.1. Konceptualni (domenski) model

Slika 22 : Domenski model


131

5.3.2.2. Relacioni model

Na osnovu konceptualnog modela može se napraviti sledeći relacioni model:

Projekat(id, naziv, datumPocetka, krajnjiRok, idProgramerLider ) Programer(id, , ime, prezime, email, pozicija, korisnickoIme, lozinka) ProjektniTim(idProjekat, idProgramer, uloga ,datumPristupanja) Greska(id, kratakOpis, opis, status, prioritet, datumPrijave, idProgramerPrijavio, idProgramerZaduzen, idProjekat) StanjeGreske(id, status, opis, datum, idProgramer, idGreska )

5.4. PROJEKTOVANJE

Faza projektovanja opisuje fizičku strukturu i ponašanje softverskog sistema. Projektovanje arhitekture softverskog sistema obuhvata projektovanje aplikacione logike, skladišta podataka i korisničkog interfejsa.

5.4.1. Arhitektura softverskog sistema

Tronivojska arhitektura softverskog sitema sastoji se iz sledećih nivoa[8]:

1) Korisničkog interfejsa (predstavlja ulazno-izlaznu reprezentaciju softverskog sistema) 2) Aplikacione logike (opisuje strukturu i ponašanje softverskog sistema) 3) Skladišta podataka (čuva stanja atributa softverskog sistema)

Slika 23 : Tronivojska arhitektura


132

Budući da se u izradi ovog rada koristi Spring MVC okvir, arhitektura aplikacije biće podeljena na pet nivoa apstrakcije. Ovakav pristup u potpunosti je saglasan sa prethodno prikazanom tronivojskom arhitekturom. Autori okvira preporučuju sledećih pet nivoa apstrakcije:

Korisnički interfejs

Web sloj

Sloj servisa

Domenski model

Sloj za pristup podacima

Aplikacija će biti podeljena na slojeve primenom projektovanja preko interfejsa. Slojevi izlažu interfejse dok konkretna implementacija interfejsa ostaje sakrivena od klijenta. Na taj način postiže se slaba povezanost između slojeva aplikacije čime se omogućava veća fleksibilnost sistema u smislu izmene implementacije na nekom sloju aplikacije, kao i lakše kompajliranje i testiranje aplikacije.

5.4.2. Projektovanje aplikacione logike – kontroler

Kontroler je klasa koja je odgovorna za upravljanje sistemskim događajima. Sistemski događaj je događaj koji inicira poziv sistemske operacije.

Sistemske operacije biće logički organizovane u servise prema logičkoj podeli posla koji obavljaju. U tom smislu, upravljanje sistemskim događajima biće delegirano implementacijama sledećih interfejsa:

public interface ProjekatServis {

public List<Projekat> vratiListuProjekata();

public boolean snimiProjekat(Projekat _projekat);

public List<ClanTima> ucitajProjektniTim(int _projekatId);

public boolean snimiClanaProjektnogTima(ClanTima _clanTima);

public boolean brisiClanaProjektnogTima(ClanTima _clanTima);

}

public interface ProgramerServis {

public boolean snimiProgramera(Programer _programer);

public boolean azurirajProgramera(Programer _programer);

public List<Programer> vratiListuProgramera();

public Programer prijavi(Programer _programer);

}

public interface GreskaServis {

public boolean snimiGresku(Greska _greska);


133

public boolean snimiStanjeGreske(StanjeGreske _stanjeGreske);

public List<Greska> vratiListuGresaka(Projekat _projekat);

public List<Greska> vratiListuGresaka(Programer _programer);

public List<Greska> vratiListuGresaka(String _prioritet);

}

5.4.3. Projektovanje strukture sotverskog sistema – Domenske klase

Na osnovu konceptualnih klasa prave se softverske klase strukture. Klase strukture prikazane su sledećim dijagramom.

Slika 24 : Struktura softverskog sistema – domenske klase


134

5.4.4. Projektovanje ponašanja sotverskog sistema – Sistemske operacije

Za svaki ugovor sistemske operacije projektuje se konceptualno rešenje, kojim se opisuje logika problema.

UG1:SnimiProjekat Operacija: snimiProjekat(Projekat, progId):boolean Veza sa SK: SK1 Preduslovi:- Postuslovi: Snimljen je novi projekat

UG2: PrikažiListuProjekata Operacija: vratiListuProjekata():List Veza sa SK: SK2 Preduslovi:- Postuslovi: Prikazana je lista projekata

klijent ps:ProjekatServis projekat : Projekat

prog : Programer

dao: ProjekatDao

1: snimiProjekat(projekat, progId)

2: new(progId)

3: setProgramer(prog)

4: snimi(projekat)

klijent ps:ProjekatServis dao:projekatDao

1: vratiListuProjekata()

2: ucitajSve()


135

UG3: SnimiProgramera

Operacija: snimiProgramera(Programer) Veza sa SK: SK3 Preduslovi:- Postuslovi: Snimljen je novi programer

UG4: AžurirajProgramera Operacija: azuriraj Programera(Programer):boolean Veza sa SK: SK4 Preduslovi:- Postuslovi: Ažurirani su podaci o programeru

UG5: PrikažiListuProgramera Operacija: vratiListuProgramera():List Veza sa SK: SK5 Preduslovi:- Postuslovi: Prikazana je lista programera

klijent ps:ProgramerServis dao:ProgramerDao

1: snimiProgramera(programer)

2: snimi(programer)

klijent ps:ProgramerServis dao:ProgramerDao

1: azurirajProgramera(programer)

2: azuriraj(azuriraj)


136

UG6: UčitajProjektniTim Operacija: ucitajProjektniTim(projekatId):List Veza sa SK: SK6, SK7 Preduslovi:- Postuslovi: Učitan projektni tim

UG7: SnimiČlanaProjektnogTima Operacija: snimiClanaProjektnogTima(ClanTima, projekatId, programerId):boolean Veza sa SK: SK6 Preduslovi:- Postuslovi: Snimljen je novi clan projektnog tima

klijent ps:ProgrameServis dao:ProgramerDao

1: vratiListuProgramera()

2: ucitajSve()

klijent ps:ProjekatServis dao:ProjekatDao




137

UG8: BrisiClanaProjektnogTima Operacija: brisiClanaProjektnogTima(ClanTima, projekatId, programerId):boolean Veza sa SK: SK7 Preduslovi:- Postuslovi: Obrisan je član projektnog tima

UG9: SnimiGrešku Operacija: snimiGrešku(Greška):boolean Veza sa SK: SK8 Preduslovi:- Postuslovi: Snimljena je nova greška

clanTima : ClanTima

klijent ps:ProjekatServis programer:Programer projekat:Projekat dao:ProjekatDao

1: snimiClanaProjektnogTima(clanTima,programerId, projekatId )

2: new(programerId)

3: new(projekatId)

4: setProgramer(programer)

5: setProjekat(projekat)

6: snimi(clanTima)

dao:ProjekatDaoklijent ps:ProjekatServis

clanTima:ClanTima

projekat:Projekat programer:Programer

1: brisiClanaProjektnogTima(clanTima, projekatId, programerId)

2: new(projekatId)

3: new(programerId)



6: brisi(clanTima)


138

UG10: SnimiStanjeGreške Operacija: snimiStanjeGreske(StanjeGreske, greskaId, progId):boolean Veza sa SK: SK9 Preduslovi:- Postuslovi: Snimljeno je novo stanje greške

UG11:PrikažiGreškePoProjektu Operacija: vratiListuGresaka(Projekat):list Veza sa SK: SK10 Preduslovi:- Postuslovi: Prikazana je lista grešaka

klijent gs:GreskaServis

projekat:Projekat

programer:Programer

greska:Greska

dao:GreskaDao

1: snimiGresku(greska, projId, prPrId, prZadId)

2: new(projId)


4: new(prPrId)

5: setProgramerPrijavio(programer)

6: new(prZadId)

7: setProgramerZaduzen(programer)

8: snimi(greska)


greska:Greska

programer:Programer

stanjeGreske:StanjeGreske

dao:GreskaDao

1: snimiStanjeGrese(stanjeGreske, greskaId, progId)

2: new(greskaId)

3: new(progId)

4: setGreska(greska)


6: snimi(stanjeGreske)


139

UG12:PrikažiGreškePoProgrameru Operacija: vratiListuGresaka(Programer):list Veza sa SK: SK11 Preduslovi:- Postuslovi: Prikazana je lista grešaka

UG13:PrikažiGreškePoPrioritetu Operacija: vratiListuGresaka(prioritet):list Veza sa SK: SK12 Preduslovi:- Postuslovi: Prikazana je lista grešaka


dao:GreskaDao

1: vratiListuGresaka(projekatId)

2: ucitajGreskePoProjektu(projekatId)


dao:GreskaDao

1: vratiListuGresaka(programerId)

2: ucitajGreskePoProgrameru(programerId)


dao:GreskaDao

1: vratiListuGresaka(prioritet)

2: ucitajGreskePoPrioritetu(prioritet)


140

5.4.5. Projektovanje logike za pristup podacima

Budući da se u ovom radu koristi Hibernate okvir za objektno-relaciono preslikavanje, korišćenjem DAO (Data Access Object)uzora biće omogućeno razdvajanje metoda koje realizuju sistemske operacije od onog dela aplikacionog koda koji obezbeđuje perzistenciju podataka.

Uloga DAO klasa je da kompletno sakriju detalje implementacije izvora podataka (data source) od klijenta. Budući da se interfejs koji je izložen klijentu ne menja prilikom promene implementacija, DAO uzor omogućava da se prilagodimo različitim mehanizmima skladištenja, bez uticaja na poslovne komponente aplikacije.

U nastavku sledi kratak prikaz DAO uzora.

Struktura

Učesnici i odgovornosti


141

BusinessObject – objekat koji predstavlja klijenta koji zahteva pristup izvoru podataka (data source). U našem slučaju, ovi objekti predstavaljaju implementacije interfejsa servisnog sloja aplikacije.

DataAccessObject (DAO)– centralni objekat ovog uzora. Operacije čitanja i snimanja podataka delegirju se ovom objektu od strane poslovnih objekata (Business Object).

DataSource – implementacija izvora podataka. U našem slučaju to je Hibernate sesija.

TransferObject – nosilac podataka.

5.4.5.1. Projektovanje DAO klasa

Korišćenjem IoC karakteristika Spring okvira moguće je primeniti DAO uzor. U konfiguracionim datotekama potrebno je definisati bean-ove klasa koje implementiraju DAO interfejse. Klase koje realizuju sistemske operacije u ovom slučaju predstavljaju klijente DAO implementacijama. Budući da su sistemske operacije logički grupisane u servise korišćenjem interfejsa, potrebno je izvršiti povezivanje odgovarajuće implementacije tih interfejsa sa prethodno definisanim DAO implementacijama. Ukoliko se neka od implementacija DAO interfejsa promeni, potrebno je izvršiti izmene samo u konfiguracionim datotekama.

HibernateDaoSupport«interface»

GenerickiDao

«interface»

ProjekatDao

«interface»

GreskaDao

«interface»

ProgramerDaoApstraktniGenerickiHibernateDao

ProjekatServisImpl GreskarServisImpl ProgramerServisImpl

«interface»

ProjekatServis

«interface»

GreskaServis

«interface»

ProgramerServis

ProgramerDaoImpl

Osenčenim delom dijagrama prikazan je odnos između interfejsa ProgramerDao i

implementacije interfejsa ProgramerServis.


142

Kao što se iz dijagrama može videti, implementacija ProgramerDaoImpl ostaje sakrivena

od ProgramerServisImpl objekta. Jedino mesto gde je definisano koja implementacija se koristi

jesu konfiguracione datoteke. Sledi prikaz dela konfiguracione datoteke kojim se specificira konkretna implementacija ProgramerDao interfejsa, kao i bean-a ProgramerServisImpl koji se

povezuje sa prethodno definisanom implementacijom.

<bean id="programerDao"

class="programskegreske.dao.ProgramerDaoImpl"

p:sessionFactory-ref="sessionFactory"/>

<bean id="programerServisTarget" class="servis.ProgramerServisImpl"

p:programerDao-ref="programerDao"/>

Analogno prikazanom primeru za ProgramerDao interfejs vrši se implementacija i

konfiguracija GreskaDao i ProjekatDao interfejsa.

5.4.6. Projektovanje skladište podataka

Na osnovu softverskih klasa strukture projektovano je odgovarajuće skladište podataka. U sledećem listingu prikazane su SQL DDL (Data Definition Language) naredbe za kreiranje projektovane relacione baze podataka.

CREATE DATABASE IF NOT EXISTS programskegreske;

USE programskegreske;

CREATE TABLE `clantima` (

`projekat_id` int(10) unsigned NOT NULL auto_increment,

`programer_id` int(10) unsigned NOT NULL,

ùloga` varchar(45) NOT NULL,

`datumPristupa` date NOT NULL,

PRIMARY KEY (`projekat_id`,`programer_id`),

KEY `FK_clantima_programer` (`programer_id`),

CONSTRAINT `FK_clantima_programer` FOREIGN KEY (`programer_id`) REFERENCES

`programer` (ìd`) ON UPDATE CASCADE,

CONSTRAINT `FK_clantima_projekat` FOREIGN KEY (`projekat_id`) REFERENCES

`projekat` (ìd`) ON UPDATE CASCADE

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `greska` (

ìd` int(10) unsigned NOT NULL auto_increment,

`kratakOpis` varchar(45) NOT NULL,

òpis` varchar(250) NOT NULL,

`status` varchar(20) NOT NULL,

`prioritet` varchar(20) NOT NULL,

`datumPrijave` datetime NOT NULL,

`projekat_id` int(10) unsigned NOT NULL,

`programer_id_prijavio` int(10) unsigned NOT NULL,


143

`programer_id_dodeljeno` int(10) unsigned NOT NULL,

PRIMARY KEY (ìd`),

KEY `FK_greska_projekat` (`projekat_id`),

KEY `FK_greska_programer_prijavio` (`programer_id_prijavio`),

KEY `FK_greska_programer_dodeljeno` (`programer_id_dodeljeno`),

CONSTRAINT `FK_greska_programer_dodeljeno` FOREIGN KEY

(`programer_id_dodeljeno`) REFERENCES `programer` (ìd`),

CONSTRAINT `FK_greska_programer_prijavio` FOREIGN KEY

(`programer_id_prijavio`) REFERENCES `programer` (ìd`) ON UPDATE CASCADE,

CONSTRAINT `FK_greska_projekat` FOREIGN KEY (`projekat_id`) REFERENCES

`projekat` (ìd`) ON UPDATE CASCADE


CREATE TABLE `programer` (


`korisnickoIme` varchar(45) NOT NULL,

`lozinka` varchar(45) NOT NULL,

ìme` varchar(45) NOT NULL,

`prezime` varchar(45) NOT NULL,

èmail` varchar(45) NOT NULL,

`pozicija` varchar(45) NOT NULL,

PRIMARY KEY (ìd`)

) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8;

CREATE TABLE `projekat` (


`naziv` varchar(45) NOT NULL,

`datumPocetka` date NOT NULL,

`krajnjiRok` date NOT NULL,


PRIMARY KEY (ìd`),

KEY `FK_projekat_programer` (`programer_id`),

CONSTRAINT `FK_projekat_programer` FOREIGN KEY (`programer_id`) REFERENCES

`programer` (ìd`)

) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;

CREATE TABLE `stanjegreske` (


`status` varchar(20) NOT NULL,

òpis` varchar(250) NOT NULL,

`datumPrijave` datetime NOT NULL,


`greska_id` int(10) unsigned NOT NULL,

PRIMARY KEY (ìd`),

KEY `FK_stanjegreske_greska` (`greska_id`),

KEY `FK_stanjegreske_programer` (`programer_id`),

CONSTRAINT `FK_stanjegreske_greska` FOREIGN KEY (`greska_id`) REFERENCES

`greska` (ìd`) ON UPDATE CASCADE,

CONSTRAINT `FK_stanjegreske_programer` FOREIGN KEY (`programer_id`)

REFERENCES `programer` (ìd`) ON UPDATE CASCADE



144

5.4.7. Preslikavanja između klasa domenskog modela i skladišta podataka

Preslikavanja između prezistentnih klasa domenskog modela aplikacije i odgovarajućih tabela u relacionoj bazi podataka u ovom radu su realizovane korišćenjem standardnih Hibernate XML datoteka za preslikavanje. Sledi prikaz XML datoteka za preslikavanje:




<hibernate-mapping package="programskegreske.domen">

<class name="StanjeGreske" table="StanjeGreske">

<id name="id" unsaved-value="0">


</id>



<property name="datumPrijave">

<column name="datumPrijave" sql-type="Date"/>

</property>

<many-to-one class="programskegreske.domen.Greska" column="greska_id"

foreign-key="FK_stanjegreske_greska" lazy="false" name="greska"/>

<many-to-one class="programskegreske.domen.Programer"

column="gramer_id_prijavio" foreign-key="FK_stanjegreske_programer"

lazy="false" name="programerPrijavio"/>

</class>

<class name="Greska" table="greska">



</id>

<property name="kratakOpis"/>



<property name="prioritet"/>

<property name="datumPrijave">

<column name="datumPrijave" sql-type="Date"/>

</property>

<many-to-one class="programskegreske.domen.Projekat" column="projekat_id"

foreign-key="FK_greska_projekat" lazy="false" name="projekat"/>


column="gramer_id_prijavio" foreign-key="FK_greska_programer_prijavio"

lazy="false" name="programerPrijavio"/>


column="gramer_id_dodeljeno" foreign-key="FK_greska_programer_dodeljeno"

lazy="false" name="programerDodeljeno"/>

<bag inverse="true" name="stanjaGreske" order-by="datumPrijave desc">

<key column="greska_id" foreign-key="FK_stanjegreske_greska"/>

<one-to-many class="programskegreske.domen.StanjeGreske"/>

</bag>

</class>

<class name="Projekat" table="projekat">


145



</id>

<property name="naziv"/>

<property name="datumPocetka">

<column name="datumPocetka" sql-type="Date"/>

</property>

<property name="krajnjiRok">

<column name="krajnjiRok" sql-type="Date"/>

</property>


column="programer_id" foreign-key="FK_projekat_programer" lazy="false"

name="programer"/>

<bag inverse="true" name="listaGresaka" order-by="datumPrijave desc">

<key column="projekat_id" foreign-key="FK_greska_projekat"/>

<one-to-many class="programskegreske.domen.Greska"/>

</bag>

<bag inverse="true" name="projektniTim" order-by="datumPristupa desc">

<key column="projekat_id" foreign-key="FK_clantima_projekat"/>

<one-to-many class="programskegreske.domen.ClanTima"/>

</bag>

</class>

<class name="Programer" table="programer">



</id>





<property name="email"/>


<bag inverse="true" name="listaProjekata" order-by="datumPocetka desc">

<key column="programer_id" foreign-key="FK_projekat_programer"/>

<one-to-many class="programskegreske.domen.Projekat"/>

</bag>

</class>

<class name="ClanTima" table="clantima">

<composite-id>

<key-many-to-one foreign-key="FK_clantima_projekat" lazy="false"

name="projekat">

<column name="projekat_id"/>

</key-many-to-one>

<key-many-to-one foreign-key="FK_clantima_programer" lazy="false"

name="programer">

<column name="programer_id"/>

</key-many-to-one>

</composite-id>

<property name="uloga"/>

<property name="datumPristupa">

<column name="datumPristupa" sql-type="Date"/>

</property>

</class>



146

5.4.8. Projektovanje korisničkog interfejsa

Korisnički interfejs predstavlja realizaciju ulaza i izlaza sistema. Korisnički iterfejs se sastoji iz[8]:

Ekranske forme koja je odgovorna da:

o prihvata podatke koje unosi aktor, o prihvata događaje koje pravi aktor, o poziva kontrolera grafičkog interfejsa, prosleđujući mu prihvaćene podatke o prikazuje podatke koje je dobila od kontrolera grafičkog interfejsa

Kontrolera korisničkog interfejsa koji je odgovoran da:

o prihvati podatke koje šalje ekranska forma, o konvertuje podatke (koji se nalaze u grafičkim elementima) u objekat koji

predstavlja ulazni argument sistemske operacije koja će biti pozvana, o šalje zahtev za izvršenje sistemske operacije do aplikacionog servera (softverskog

sistema), o prihvata objekat (izlaz) softverskog sistema koji nastaje kao rezultat izvršenja

sistemske operacije, o konvertuje objekat u podatke grafičkih elemenata.

Postoje dva aspekta projektovanja ekranskih formi[8]:

Projektovanje scenarija SK koji se izvode preko ekranske forme, i

Projektovanje metoda ekranske forme.

5.4.8.1. Projektovanje scenarija SK koji se izvode preko ekranske forme

SK1: Unos projekta

Naziv: Unos projekta Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za unos novog projekta.


147

Osnovni scenario:

1. Korisnik unosi podatke o projektu (APUSO)

Opis akcije: Potrebno je uneti naziv projekta, datum početka i krajnji rok za završetak projekta. Iz padajuće liste potrebno je izabrati programera koji je je postavljen za vođu projekta.

2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da sačuva novi projekat (APSO)

Opis akcije: Pritiskom na dugme Sačuvaj ili pritiskom tipke <Enter>, poziva se sistem da snimi podatke o novom projektu.

4. Sistem kreira i snima novi projekat (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


148



SK2: Prikaz liste projekata

Naziv: Prikaz liste projekata Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i korisnik ulogovan.

Osnovni scenario:


149

1. Korisnik poziva sistem da prikaže listu projekata (APSO)

Opis akcije: Pritiskom na stavku menija Projekti->Lista Projekata, korisnik poziva sistem da prikaže listu projekata

2. Sistem kreira listu projekata (SO) 3. Sistem prikazuje listu projekata korisniku (IA)


150



SK3: Unos programera

Naziv: Unos programera Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i prikazuje web stranu za unos novog programera.

Osnovni scenario:

1. Korisnik unosi podatke o programeru (APUSO)

Opis akcije: Potrebno je uneti korisničko ime, lozinku, ime, prezime, email i poziciju programera.

2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da sačuva novog programera (APSO)


151

Opis akcije: Pritiskom na dugme Sačuvaj ili pritiskom tipke <Enter>, poziva se sistem da snimi podatke o novom programeru.

4. Sistem kreira i snima novog programera (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


152


5.1. Ukoliko sistem nije u mogućnosti da kreira i snimi novog programera, prikazuje korisniku odgovarajuću poruku.


153

S4: Ažuriranje podataka o programeru

Naziv: Ažuriranje podataka o programeru Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za ažuriranje podataka o programeru.


154

Osnovni scenario:

1. Korisnik unosi nove podatke o programeru (APUSO)

Opis akcije: Potrebno je uneti korisničko ime, lozinku, ime, prezime, email i poziciju programera.

2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da ažurira podatke o programeru (APSO)

Opis akcije: Pritiskom na dugme Sačuvaj ili pritiskom tipke <Enter>, poziva se sistem da snimi podatke o novom programeru.

4. Sistem ažurira podatke o programeru (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


155




156

SK5: Prikaz liste programera

Naziv: Prikaz liste programera Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i korisnik ulogovan.


157

Osnovni scenario:

1. Korisnik poziva sistem da prikaže listu programera (APSO)

Opis akcije: Pritiskom na stavku menija Programeri->Lista Projekata, korisnik poziva sistem da prikaže listu projekata

2. Sistem kreira listu programera (SO) 3. Sistem prikazuje listu programera (IA)


158




159

SK6: Dodavanje članova projektnog tima

Naziv: Dodavanje članova projektnog tima Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za izbor projekta za koji se vrši dodavanje člana tima.

Osnovni scenario:

1. Korisnik bira projekat iz ponuđene liste projekata(APUSO)


160

2. Korisnik poziva sistem da prikaže tekući projektni tim (APSO) 3. Sistem učitava projetni tim (SO) 4. Sistem prikazuje korisniku tekući projektni tim i formu za unos novog člana tima

(IA)


161

5. Korisnik bira programera iz ponuđene liste dostupnih programera (APUSO). 6. Korisnik unosi ulogu izabranog programera u projektnom timu (APUSO) 7. Korisnik poziva sistem da snimi novog člana projektnog tima (APSO)

Opis Akcije: Korisnik pritiskom na dugme Dodaj poziva sistem da snimi novog člana projektnog tima.

8. Sistem snima novog člana projektnog tima (SO) 9. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)

Opis Akcije: Novi član projektnog tima je prikazan u tabeli iznad forme za unos članova tima.


162


4.1 . Ukoliko su svi dostupni programeri angažovani na projektu, sistem prikazuje poruku da nema dostupnih programera koji mogu da se dodaju projektnom timu (IA). Prekida se izvršenje scenarija.


163

SK7: Brisanje članova projektnog tima

Naziv: Brisanje članova projektnog tima Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za izbor projekta za koji se vrši brisanje člana tima.

Osnovni scenario:

1. Korisnik bira projekat iz ponuđene liste projekata (APUSO) Napomena: Koristi se ista ekranska forma kao u SK6.

2. Korisnik poziva sistem da prikaže projektni tim (APSO) 3. Sistem učitava projektni tim (SO) 4. Sistem prikazuje korisniku listu članova prjektnog tima (IA)

Napomena: Koristi se ista ekranska forma kao u SK6. 5. Korisnik poziva sistem da izbriše člana projektnog tima (APSO)

Opis Akcije: Korisnik bira člana tima u prikazanoj tabeli. Pritiskom na dugme Izbaci u redu tabele koji odgovara clanu tima koji se izbacuje, korisnik poziva sistem da izbriše člana tima.


164

6. Sistem briše člana projektnog tima (SO) 7. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)



SK8: Unos greške

Naziv: Unos greške Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za unos nove greške na projektu.


165

Osnovni scenario:

1. Korisnik unosi podatke o grešci (APUSO)

Opis Akcije: Potrebno je da korisnik unese kratak opis greške, detaljan opis, da izabere status i prioritet greške iz padajućih lista, kao projekat na koji se greska odnosi i programera kome je greska dodeljena.

2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da sačuva novu grešku (APSO)

Opis Akcije: Korisnik pritiskom na dugme Sačuvaj ili pritiskom tipke <Enter> poziva sistem da snimi grešku.

4. Sistem kreira i snima novu grešku (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


166




167

SK9: Promena stanja greške

Naziv: Promena stanja greške Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu sa informacijom o grešci i formom za unos novog stanja greške.


168

Osnovni scenario:

1. Korisnik unosi podatke o novom stanju greške (APUSO)

Opis Akcije: Potrebno je uneti opis novog stanja greske izabrati status iz padajuće liste.

2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da sačuva novo stanje greške (APSO)

Opis Akcije: Pritiskom na dugme sačuvaj korisnik poziva sistem da snimi unete podatke.

4. Sistem kreira i snima novo stanje greške (SO) 5. Sistem prikazuje poruku o uspešno izvršenoj operaciji (IA)


169




170

SK10: Prikaz grešaka po projektu


projekta po kome se kreira izveštaj.

Osnovni scenario:

1. Korisnik bira projekat iz liste projekata (APUSO) 2. Korisnik poziva sistem da prikaže izveštaj (APSO)

Opis Akcije: Nakon izbora željenog projekta iz padajuće liste, korisnik pritiskom na dugme Prikaži poziva sistem da prikaže listu grešaka na izabranom projektu.

3. Sistem pronalazi greške za izabrani projekat (SO) 4. Sistem prikazuje izveštaj o greškama (IA)


171




172

SK11: Prikaz grešaka po programeru


programera po kome se kreira izveštaj.

Osnovni scenario:

1. Korisnik bira programera iz liste (APUSO) 2. Korisnik poziva sistem da prikaže izveštaj (APSO)

Opis Akcije: Nakon izbora programera iz padajuće liste, korisnik pritiskom na dugme Prikaži poziva sistem da prikaže listu grešaka koje su dodeljene izabranom programeru.

3. Sistem pronalazi greške za izabranog programera (SO) 4. Sistem prikazuje izveštaj o greškama (IA)


173




174

SK12: Prikaz grešaka po prioritetu

Naziv: Prikaz grešaka po prioritetu Aktori: Korisnik Učesnici: Korisnik i sistem Preduslov: Sistem je uključen i korisnik ulogovan. Sistem prikazuje web stranu za izbor

prioriteta greške po kome se kreira izveštaj.

Osnovni scenario:

1. Korisnik bira prioritet grešaka iz ponuđene liste (APUSO) 2. Korisnik poziva sistem da prikaže izveštaj (APSO)

Opis Akcije: Nakon izbora prioriteta iz padajuće liste, korisnik pritiskom na dugme Prikaži poziva sistem da prikaže listu grešaka izabranog prioriteta.

3. Sistem pronalazi greške po izabranom prioritetu (SO) 4. Sistem prikazuje izveštaj o greškama (IA)


175




176

SK13: Prijavljivanje korisnika

Naziv: Prijavljivanje korisnika Aktori: Korisnik Učesnici: Korisnik i sistem

Preduslov: Sistem je uključen i prikazuje web stranu za prijavljivanje korisnika.

Osnovni scenario:

1. Korisnik unosi korisničko ime i lozinku (APUSO) 2. Korisnik proverava ispravnost unetih podataka (ANSO) 3. Korisnik poziva sistem da izvrši prijavljivanje (APSO) 4. Sistem izvršava prijavljivanje (SO) 5. Sistem prikazuje početnu web stranu. (IA)


177


5.1. Ukoliko korisnik unese pogrešne podatke za prijavljivanje sistem obaveštava korisnika da prijavaljivanje nije uspešno izvršeno. Sistem prikazuje korisniku web stranu za prijavljivanje (IA). Prekida se izvršenje scenarija


178

5.4.8.2. Projektovanje kontrolera korisničkog interfejsa

U realizaciji ovog rada koriščen je Spring MVC okvir. Prikaz MVC uzora dat je u poglavlju 2.7.2., dok je u poglavlju 2.7.3. dat detaljan prikaz koncepata Spring MVC okvira.

Kao tehnologija prikaza (view) u ovom radu korišćena je JSP tehnologija. Kontroleri korisničkog interfejsa predstavljaju odgovarajuće implementacije org.springframework.web.

servlet.mvc.Controller interfejsa. Za slučajeve korišćenja koji ne zahtevaju povezivanje (data

binding) polja za unos na formi sa atributima komandnog bean-a45, kontroleri implementiraju Controller interfejs, pri čemu je potrebno samo implementirati metodu handleRequest(). U

okviru ove metode prihvataju se podaci koje šalje ekranska forma, vrši se konverzija primljenih podataka u odgovarajući objekat koji je ulazni argument sistemske operacije, vrši se poziv sistemske operacije, zatim se prihvata rezultat sistemske operacije, koji se prosleđuje odgovarajućem pogledu (view).

Za slučejeve korišćenja koji zahtevaju povezivanje podataka kao kontroler koriste se klase koje proširuju (nasleđuju) klasu SimpleFormController. Klase domenskog modela koriste se kao

komandni bean-ovi, tj., vrši se povezivanje polja za unos na ekranskoj formi sa odgovarajućim atributima domenskog objekta. Povezivanje podataka istovremeno podrazumeva i konverziju podataka iz polja za unos koji su tipa String , u odgovarajući tip podatka atributa komandnog objekta sa kojim se polje povezuje. Poziv sistemske operacije i prihvatanje rezultata izvršenja operacije, kao i prosleđivanje rezultata do definisanog pogleda (view) vrši se u okviru metode onSubmit(), ili doSubmitAction(), koje su definisane u klasi SimpleFormController. Dakle

potrebno je izvršiti prekrivanje (overriding) odgovarajuće metode. U nastavku sledi prikaz projektovanih kontrolera.

Kontroler KI za SK1: UnosNovogProjekta:

public class NoviProjekatKontroler extends SimpleFormController {

private ProjekatServis projekatServis;


@Override


projekatServis.snimi((Projekat)command);

}

@Override

protected Object formBackingObject(HttpServletRequest request) throws

Exception {

Projekat p = new Projekat();

p.setProgramer(new Programer());

return p;

}

@Override

protected void initBinder(HttpServletRequest req,

45 Povezivanje (data binding) prikazano je u poglavlju 2.7.3.6. Korišćenje forme


179

ServletRequestDataBinder binder) throws Exception {

binder.registerCustomEditor(Date.class, new CustomDateEditor(

new SimpleDateFormat("yyyy-MM-dd"), true));

}

@Override

protected Map referenceData(HttpServletRequest request) throws Exception

{

List<Programer> listaProgramera = programerServis.dajSveProgramere();

Map modelRef = new HashMap();

modelRef.put("listaProgramera", listaProgramera);

return modelRef;

}

/**

* @return the projekatServis

*/

public ProjekatServis getProjekatServis() {

return projekatServis;

}

/**

* @param projekatServis the projekatServis to set

*/

public void setProjekatServis(ProjekatServis projekatServis) {

this.projekatServis = projekatServis;

}

/**

* @return the programerServis

*/



}

/**

* @param programerServis the programerServis to set

*/



}

}

Kontroler KI za SK2: PrikazListeProjekata:

public class ListaProjekataKontroler implements Controller{


public ModelAndView handleRequest(HttpServletRequest request,

HttpServletResponse response) throws Exception {

List<Projekat> listaProjekata = projekatServis.dajSveProjekte();

ModelAndView mav = new ModelAndView("listaProjekata");

mav.addObject("listaProjekata", listaProjekata);

return mav;


180

}

/**


*/



}

/**


*/



}

}

Kontroler KI za SK3: UnosProgramera i SK4: AžuriranjeProgramera

public class ProgramerKontroler extends SimpleFormController {


@Override

protected ModelAndView onSubmit(HttpServletRequest request,

HttpServletResponse response, Object command, BindException errors) throws

Exception {

ModelAndView mav = new ModelAndView();

// ako je snimanje novog -save()+promena atributa 'login' u sesiji

if (requestNew(request)) {

if (getProgramerServis().snimi((Programer) command)) {

mav.setViewName(getSuccessView());

request.getSession(true).setAttribute("login", command);

} else {

errors.rejectValue("korisnickoIme",

"inputErr.postojeciUsername", "Korisnicko ime koje ste uneli je zauzeto!");

return showForm(request, errors, getFormView());// nije dobar

username

}

} else {// update postojeceg

getProgramerServis().azuriraj((Programer) command);

request.getSession(false).setAttribute("login", command);


}

return mav;

}

@Override


Exception {

if (requestNew(request)) {

return super.formBackingObject(request);

} else {//onda je updateProgramer.htm


181

return (Programer)

request.getSession(false).getAttribute("login");

}

}

private boolean requestNew(HttpServletRequest request) {

return request.getRequestURI().endsWith("noviProgramer.htm");

}

/**


*/



}

/**


*/



}

}

Kontroler KI za SK5: Prikaz liste programera

public class ListaProgrameraKontroler extends AbstractController{


@Override

protected ModelAndView handleRequestInternal(HttpServletRequest request,

HttpServletResponse response) throws Exception {


ModelAndView mav = new ModelAndView("listaProgramera");

mav.addObject("listaProgramera", listaProgramera);

return mav;

}

/**


*/



}

/**


*/



}

}


182

Kontroler KI za SK6: Dodavanje članova projektnog tima i SK7: Brisanje članova projektnog tima

public class ProjektniTimKontroler extends SimpleFormController {


private ProgramerServis programerServis; // za reference data

public ProjektniTimKontroler() {

setCommandClass(ProjektniTimCommand.class);

setCommandName("projekatCommand");

setSuccessView("redirect:index.htm");

setFormView("projektniTim");

setSessionForm(true);

}

@Override


super.doSubmitAction(command);

}

@Override


Exception {

int projekatId = Integer.valueOf(request.getParameter("projekatId"));

Projekat projekat = projekatServis.ucitajProjekat(projekatId);

if (projekat != null) {

projekat.setProjektniTim(projekatServis.ucitajProjektniTim(projekatId));

}

ProjektniTimCommand projekatCommand = new ProjektniTimCommand();

BeanUtils.copyProperties(projekat, projekatCommand);

projekatCommand.setDostupniProgrameri(programerServis.dajSveProgramere());

return projekatCommand;

}

@Override

protected void onFormChange(HttpServletRequest request,

HttpServletResponse response,

Object command, BindException errors)

throws Exception {

ProjektniTimCommand p = (ProjektniTimCommand) command;

// ako je dodavanje clana dodajem ga u listu


183

// i pozivam snimanje

if (isNoviClanTima(request)) {

ClanTima noviClan = p.getNoviClanTima();

noviClan.getProjekat().setId(p.getId());

int indexProgramera =

p.getDostupniProgrameri().indexOf(noviClan.getProgramer());

//posto ne radim redirekciju

//ako uradim refresh strane ne sme ponovo da doda istog

programera!!

//ako je -1 znaci da nije vise dostupan, tj vec je u timu

if (indexProgramera != -1) {

noviClan.getProgramer().setIme(p.getDostupniProgrameri().get(indexProgramera)

.getIme());

noviClan.getProgramer().setPrezime(p.getDostupniProgrameri().get(indexProgram

era).getPrezime());

p.getProjektniTim().add(noviClan);

p.getDostupniProgrameri().remove(noviClan.getProgramer());

projekatServis.dodajClanaTima(noviClan);

}

}

if (isIzbaciClanaTima(request)) {

Integer index = getIndeksClanaKojiSeIzbacuje(request);

ClanTima izbaceniClan =

p.getProjektniTim().remove(index.intValue());

p.getDostupniProgrameri().add(izbaceniClan.getProgramer());

projekatServis.izbaciClanaTima(izbaceniClan);

}

}

@Override

protected boolean isFormChangeRequest(HttpServletRequest request) {

// ako je izbacivanje ili dodavanje onda se forma menja

// ako je pritisnuto dugme kraj formiranja prikazuje stranu index

return (isNoviClanTima(request) || isIzbaciClanaTima(request));

}

// ako je pritisnuto dugme name=dodajClanaTima vraca true

private boolean isNoviClanTima(HttpServletRequest request) {

return request.getParameter("dodajClanaTima") != null;

}

// ako je pritisnuto dugme name=izbaciClana_xx, vraca true


184

private boolean isIzbaciClanaTima(HttpServletRequest request) {

return getIndeksClanaKojiSeIzbacuje(request) != null;

}

// vraca indeks clana tima koga treba izbaciti

// ili null ako nije pritisnuto dugme za izbacivanje

private Integer getIndeksClanaKojiSeIzbacuje(HttpServletRequest request)

{

Integer index = null;

for (Enumeration e = request.getParameterNames();

e.hasMoreElements();) {

String imeParametra = (String) e.nextElement();

if (imeParametra.startsWith("izbaciClana_")) {

// konvertujem ono sto je poslje donje crtice u integer

index =

Integer.valueOf(imeParametra.substring("izbaciClana_".length()));

}

}

return index;

}

@Override

protected void initBinder(HttpServletRequest request,




}

/**


*/



}

/**


*/



}

/**


*/



}

/**


*/



}

}


185

Kontroler KI za SK8: Unos Greške

public class NovaGreskaKontroler extends SimpleFormController {

private String[] listaPrioriteta = {"Visok", "Srednji", "Nizak"};

private String[] listaStatusa ={"Neresena", "Resena"};



private GreskaServis greskaServis;

public NovaGreskaKontroler() {

//Initialize controller properties here or

//in the Web Application Context

setCommandClass(Greska.class);

setCommandName("greska");

setSuccessView("redirect:uspesnoSnimanjeGreske.htm");

setFormView("formGreska");

}

@Override



Exception {

// onaj koji prijavljuje mora biti ulogovan,

// iz sesije uzimam atribut i preuzimam id onog koji je ulogovan

Greska g = (Greska)command;

Programer ulogovaniKorisnik = (Programer)

request.getSession().getAttribute("login");

g.setProgramerPrijavio(ulogovaniKorisnik);

greskaServis.snimiGresku(g);

//priprema modela za redirekciju

Map model = new HashMap();

model.put("kratakOpis", g.getKratakOpis());

model.put("opis", g.getOpis());

model.put("prioritet", g.getPrioritet());

model.put("status", g.getStatus());

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");

model.put("datumPrijave", sdf.format(g.getDatumPrijave()));

Programer p =

programerServis.ucitaj(g.getProgramerDodeljeno().getId());

model.put("dodeljenaProgrameru", p.getIme()+" "+p.getPrezime());

Projekat proj =

projekatServis.ucitajProjekat(g.getProjekat().getId());

model.put("nazivProjekta", proj.getNaziv());

ModelAndView mav = new ModelAndView(getSuccessView());

mav.addAllObjects(model);

return mav;

}


186

@Override

protected Object formBackingObject(HttpServletRequest request)

throws Exception {

Greska g = new Greska();

g.setDatumPrijave(new Date());

g.setProgramerDodeljeno(new Programer());

g.setProgramerPrijavio(new Programer());

g.setProjekat(new Projekat());

return g;

}

@Override

protected Map referenceData(HttpServletRequest request)

throws Exception {

List listaProjekata = projekatServis.dajSveProjekte();

List listaProgramera = programerServis.dajSveProgramere();

Map reference = new HashMap();

reference.put("listaProjekata", listaProjekata);

reference.put("listaProgramera", listaProgramera);

reference.put("listaPrioriteta", this.listaPrioriteta);

reference.put("listaStatusa", this.listaStatusa);

return reference;

}

@Override

protected void initBinder(HttpServletRequest request,




}

/**


*/



}

/**


*/



}

/**


*/



}

/**


187


*/



}

/**

* @return the greskaServis

*/

public GreskaServis getGreskaServis() {

return greskaServis;

}

/**

* @param greskaServis the greskaServis to set

*/

public void setGreskaServis(GreskaServis greskaServis) {

this.greskaServis = greskaServis;

}

}

Kontroler KI za SK9: Promena stanja greške

public class NovoStanjeGreskeKontroler extends SimpleFormController {

private GreskaServis greskaSerivis;

private String[] listaStatusa ={"Neresena", "Resena"};

public NovoStanjeGreskeKontroler() {



setCommandClass(StanjeGreskeCommand.class);

setCommandName("stanjeGreskeCommand");

setSuccessView("redirect:uspesnoSnimanjeStanjaGreske.htm");

setFormView("formNovoStanjeGreske");

// cuva komandni objekat izmedju prikaza i potvrde forme u sesiji

setSessionForm(true);

}

@Override



Exception {

StanjeGreskeCommand sgc = (StanjeGreskeCommand) command;

StanjeGreske sg = sgc.getNovoStanjeGreske();

sg.setProgramerPrijavio((Programer)

request.getSession().getAttribute("login"));

greskaSerivis.snimiStanjeGreske(sg);

//priprema modela za redirekciju

Map model = new HashMap();


188

model.put("opis", sg.getOpis());

model.put("status", sg.getStatus());

ModelAndView mav = new ModelAndView(getSuccessView());

mav.addAllObjects(model);

return mav;

}

@Override

protected Object formBackingObject(HttpServletRequest request)

throws Exception {

StanjeGreskeCommand stanjeGreskeCommand = new StanjeGreskeCommand();

int greskaId = Integer.parseInt(request.getParameter("greskaId"));

stanjeGreskeCommand.setGreskaId(greskaId);

Greska g = greskaSerivis.vratiGreskuSaSvimStanjima(greskaId);

stanjeGreskeCommand.setGreska(g);

stanjeGreskeCommand.getNovoStanjeGreske().setGreska(g);

return stanjeGreskeCommand;

}

@Override


{

Map modelRef = new HashMap();

modelRef.put("listaStatusa", listaStatusa);

return modelRef;

}

/**

* @return the greskaSerivis

*/

public GreskaServis getGreskaSerivis() {

return greskaSerivis;

}

/**

* @param greskaSerivis the greskaSerivis to set

*/

public void setGreskaSerivis(GreskaServis greskaSerivis) {

this.greskaSerivis = greskaSerivis;

}

}

Kontroler KI za SK10: Prikaz grešaka po projektu

public class ListaGresakaPoProjektuKontroler extends SimpleFormController {



public ListaGresakaPoProjektuKontroler() {




189

setCommandClass(ListaGresakaCommand.class);

setCommandName("greske");


setFormView("listaGresakaPoProjektu");

}

@Override



}

@Override


{

List<Projekat> listaProjekata = projekatServis.dajSveProjekte();

Map ref = new HashMap();

ref.put("listaProjekata", listaProjekata);

return ref;

}

// iz komandnog objekta uzimam projekat i prosledjujem ga metodi

vratiListuGresaka...

@Override


HttpServletResponse response, Object command) throws Exception {

ListaGresakaCommand listaGresakaCommand = (ListaGresakaCommand)

command;

listaGresakaCommand.setListaGresaka(greskaServis.vratiListuGresaka(listaGresa

kaCommand.getProjekat()));

}

@Override


return (request.getParameter("prikazi") != null);

}

/**


*/



}

/**


*/



}

/**


190


*/



}

/**


*/



}

}

Kontroler KI za SK11: Prikaz grešaka po programeru

public class ListaGresakaPoProgrameruKontroler extends SimpleFormController {



public ListaGresakaPoProgrameruKontroler() {






setFormView("listaGresakaPoProgrameru");

}

@Override



}

@Override


{



ref.put("listaProgramera", listaProgramera);

return ref;

}

// iz komandnog objekta uzimam programera i prosledjujem ga metodi

vratiListuGresaka...

@Override




command;


191

listaGresakaCommand.setListaGresaka(greskaServis.vratiListuGresaka(listaGresa

kaCommand.getProgramer()));

}

@Override



}

/**


*/



}

/**


*/



}

/**


*/



}

/**


*/



}

}

Kontroler KI za SK12: Prikaz grešaka po prioritetu

public class ListaGresakaPoPrioritetuKontroler extends SimpleFormController {

private String[] listaPrioriteta = {"Visok", "Srednji", "Nizak"};


public ListaGresakaPoPrioritetuKontroler() {






setFormView("listaGresakaPoPrioritetu");

}


192

@Override



}

@Override


{


ref.put("listaPrioriteta", this.listaPrioriteta);

return ref;

}

@Override




command;

String prioritet = request.getParameter("prioritet");

listaGresakaCommand.setListaGresaka(greskaServis.vratiListuGresaka(prioritet)

);

}

@Override



}

/**


*/



}

/**


*/



}

}

Kontroler KI za SK13: Prijavljivanje korisnika

public class PrijavaOdjavaKontroler extends SimpleFormController {


public PrijavaOdjavaKontroler() {

}

@Override


193



Exception {

Programer commandProgramer =(Programer)command;

Programer retrievedProgramer =

getProgramerServis().prijavi(commandProgramer);

ModelAndView mav = new ModelAndView();

// ako vrati objekat prikazujem index stranu

// a vracenog programera stavljam u sesiju

if(retrievedProgramer!=null){


request.getSession(true).setAttribute("login",

retrievedProgramer);

}else{

errors.addError(new ObjectError("user",

new String[]{"inputErr.prijava"},

null, "Pogresno korisnicko ime ili lozinka!"));

mav.addObject("user", commandProgramer);

mav.setViewName(getFormView());

return showForm(request, errors, getFormView());

}

return mav;

}

@Override

protected boolean isFormSubmission(HttpServletRequest request) {

//cistim atribut user iz sesije

if (!super.isFormSubmission(request)){

request.getSession().setAttribute("login", null);

}

return super.isFormSubmission(request);

}

/**


*/



}

/**


*/



}

}


194

5.4.9. Finalna arhitektura softverskog sistema

Hib

ern

ate

Da

oS

up

po

rt«

inte

rfa

ce

»

Ge

ne

ric

kiD

ao

«in

terf

ace

»

Gre

sk

aD

ao

«in

terf

ace

»

Pro

gra

me

rDa

o

«in

terf

ace

»

Pro

jek

atD

ao

Ap

str

ak

tniG

en

eri

ck

iHib

ern

ate

Da

o

Gre

sk

aS

erv

isIm

pl

Pro

jek

atS

erv

isIm

pl

Pro

gra

me

rSe

rvis

Imp

l

«in

terf

ace

»

Gre

sk

aS

erv

is

«in

terf

ace

»

Pro

jek

atS

erv

is

«in

terf

ace

»

Pro

gra

me

rSe

rvis

Pro

jek

atD

ao

Imp

l

Pro

gra

me

rDa

oIm

pl

Gre

sk

aD

ao

Imp

l

Pro

jek

at

Pro

gra

me

r

Gre

sk

a

Cla

nT

ima

Sta

nje

Gre

sk

e

1

0..*

1

0..*

10

..*

1

0..*

0..*

11

0..*

10

..*

No

viP

roje

ka

tKo

ntr

ole

r

Lis

taP

roje

ka

taK

on

tro

ler

Pro

jek

tniT

imK

on

tro

ler

Ko

risn

ički

inte

rfe

js

Po

na

ša

nje

sis

tem

a

Str

uktu

ra s

iste

ma

Ko

ntr

ole

ri K

I

So

ftve

rski sis

tem

Ta

ble

Gre

ska

Ta

ble

Pro

jeka

t

Ta

ble

Sta

nje

Gre

ske

Ta

ble

Pro

gra

me

r

Ta

ble

Cla

nT

ima

Skla

diš

te

po

da

taka

Slika 25 : Finalna arhitektura softverskog sistema46

46 Radi preglednosti na slici su date samo veze između komponenti koje učestvuju u realiziaciji SK1, SK2, SK6 i SK7. Odgovarajuće komponente su na slici osenčene.


195

Prethodnom slikom prikazana je konačna arhitektura projektovanog softverskog sistema. Radi preglednosti, na dijagramu nisu prikazane sve komponente sistema i njihove međusobne veze, već je akcenat na tome da se preko osenčenih komponenti na dijagramu prikažu odnosi komponenti na različitim slojevima aplikacije.

Međusobna nezavisnost slojeva aplikacije realizovana je preko interfejsa. Sistemske operacije su logički grupisane u interfejse koji su izloženi kontrolerima korisničkog iterfejsa, pri čemu konkretne implementacije sistemskih operacija ostaju sakrivene od kontrolera.

Korišćenjem DAO uzora, na sličan način izvršeno je razdvajanje komponenti koje realizuju sistemske operacije od konkretnih realizacija DAO interfejsa.

5.5. IMPLEMENTACIJA

U fazi implementacije dobijene su sledeće komponente aplikacije, koje su prikazane na prethodnoj slici:

paket programskegreske.domen: Programer.java

Projekat.java

Greska.java

StanjeGreske.java

ClanTima.java

paket programskegreks.domen.preslikavanja: Greska.xml.hbm

Projekat.xml.hbm

Programer.xml.hbm

StanjeGreske.xml.hbm

ClanTima.xml.hbm

paket programskegreske.web.kontroler: ProgramerKontroler.java

ListaProgrameraKontroler.java

NoviProjekatKontroler.java

ListaProjekataKontroler.java

PrijavaOdjavaKontroler.java

NovaGreskaKontroler.java

NovoStanjeGreskeKontroler.java

PrikazGresakaKontroler.java

LoginInterceptor.java

ListaGresakaPoProjektu.java

ListaGreskaPoPrioritetu.java

ListaGresakaPoProgrameru.java

paket programskegreske.web.validator: ProjekatValidator.java

ProgramerValidator.java

PrijavaOdjavaValidator.java

GreskaValidator.java

StanjeGreskeValidator.java paket programskegreske.dao.generic: GenerickiDao.java

ApstraktniGenerickHibernateDao.java

paket programskegreske.dao: ProjekatDao.java

ProjekatDaoImpl.java

ProgramerDao.java

ProgramerDaoImpl.java

GreskaDao.java

GreskaDaoImpl.java

paket programskegreske.servis: ProjekatServis.java

ProjekatServisImpl.java

ProgramerServis.java

ProgramerServisImpl.java

GreskaServis.java

GreskaServisImpl.java

konfiguracione datoteke: hibernate.cfg.xml

applicationContext.xml

dispatcher-servlet.xml

web.xml

poruke.properties

jdbc.properties


196

6. ZAKLJUČAK

Dugačak put sam prevalio od prvih koraka na fakultetu, prvih beleški na predavanjima , prvih poznanstava. Pratila su me na tom putu mnogobrojna lepa, poneko i ružno iskustvo, posrtanja, padovi, ali i usponi. Kroz mnogo neprospavanih noći, truda i odricanja stekao sam dosta znanja koja će mi sigurno biti dragocena na nekim novim putevima i novim izazovima koja mi život donosi...

Temu ovog rada izabrao sam želeći na neki način da zaokružim ranije stečena programerska znanja i iskustva, ali i u želji da savladam neke nove tehnologije. Svakako je danas najveći izazov svakome ko se na bilo koji način bavi informacionim tehnologijama da prati korak njihovog razvoja i da se permanentno usavršava i usvaja nove tehnologije. Noseći se tom idejom, izabrao sam Spring i Hibernate okvire, kako bi unapredio i proširio znanja vezana za Java tehnologije, ali i neka šira znanja u oblasti razvoja softvera.

Nije baš sve išlo glatko, trebalo je uložiti dosta napora, dosta noći i dana provesti ispred monitora, iznad knjiga, ali su utoliko i rezultati draži, jer ono što bez muke i napora steknemo isto malo i cenimo.


197

7. LITERATURA

[1] ZeljkoGavrilović: Komparativna analiza EJB JPA kontejnerske i JDBC perzitentnosti, master rad, 2008. [2] Jon Byous, članak Java Technology: The Early Years http://java.sun.com/features/1998/05/birthday.html [3] S. Vlajić, D. Savić, V. Stanojević, I. Antović, M. Milić, Projektovanje Softvera – Napredne Java tehnologije, Zlatni Presek, Beograd, 2008. [4] Dr Siniša Vlajić: Napredni koncepti Jave i web programiranje u Javi, FON, Beograd 2005. [5] Rod Johnson i drugi, The Spring Framework - Reference Documentation, www.springframework.org [6] http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html [7] B. Smeets, S. Ladd, Building Spring 2 Enterprise Applications, Apress, 2007 [8] Dr Siniša Vlajić, Projektovanje programa (Skripta), FON, Beograd, 2004. [9] Craig Walls, Spring In Action, Manning Publications, 2008. [10] B. Lazarević, Z. Marjanović, N. Aničić, S. Babarogić, Baze Podataka, FON, Beograd, 2003. [11] Mark Fussell – Foundations of Object-Relational Mapping [12] Brian Sam-Boden, Beginnig POJOs From Novice to Professional, Apress, 2006. [13] Gary Mak, Spring Recepies A Problem Solution Approach, Apress, 2008. [14] Eric Pough, Joseph D. Gradecki, Professional Hibernate, Wiley publishing, 2004. [15] Hibernate Reference Documentation, http://www.hibernate.org/

http://java.sun.com/features/1998/05/birthday.html

www.springframework.org

http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html

http://www.hibernate.org/

Documents

Goran Pavlovic Razvoj Web Aplikacije Za Pracenje Softverskih Gresaka Koriscenjem Spring i Hibernate Tehnologija