UNIVERZITET U BEOGRADU

FAKULTET ORGANIZACIONIH NAUKA

DIPLOMSKI RAD

Web aplikacija za stomatološku ordinaciju u J2EE okruženju

Mentor: Kandidat:
prof. dr Siniša Vlajić Medić Jelena 270/02

Beograd, 2009.
Sadržaj

1. Uvod.......................................................................................................................3
2. JAVA Platforme...................................................................................................4
3. JAVA Enterprise Edition (JEE).........................................................................5
3.1. Distribuirane višenivojske aplikacije.............................................................................6
3.2. Java EE komponente......................................................................................................7
3.2.1. Java EE klijenti.............................................................................................8
3.2.2. Java EE server komunikacija........................................................................9
3.2.3. Web komponnete..........................................................................................9
3.2.4. Enterprise JavaBeans komponente..............................................................10
3.2.4.1. Vrste enterprise bean-ova...............................................................11
3.2.4.2. Sadržaj enterprise bean-a...............................................................13
3.2.4.3. Životni ciklus enterprise bean-a.....................................................14
3.2.4.4. Tipovi pristupa klijenta session i entity bean-ova..........................17
3.3. Java EE kontejneri........................................................................................................19
3.3.1. Tipovi kontejnera……………………………………………………………...20
3.4. Podrška Web servisa…………………………………………………………………20
3.5. Pakovanje Java EE aplikacija…………………………………………………….24
3.6. Java EE moduli…………………………………………………………………...25
3.7. Java EE API………………………………………………………………...........27
3.8. Web i aplikacioni serveri………………………………………...............………27
4. Web aplikacija…………………………………………………………………29
4.1. Evolucija Java EE Web tehnologija………………………………………………….30
4.2. Web moduli……………………………………………………………………. ……31
4.3. Model-View-Controller arhitektura………………………………………………….32
5. Java Servlet tehnologija………………………………………………………34
5.1. Servlet i servlet kontejner…………………………………………………………….34
5.2. Osnovne metode servleta……………………………………………………………..36
5.3. Životni ciklus servlet-a……………………………………………………….............37
5.4. Filterovanje zahteva i odgovora……………………………………………..........….38
5.5. Obrada izuzetaka……………………………………………………………..............39
5.6. Prednosti servlet-a……………………………………………………………........... 39
6. JavaServer Pages tehnologija………………………………………………....41
6.1. Uvod u JSP……………………………………………………………………...........41
6.2. JSP arhitektura…………………………………………………………………..........42
6.3. Komponente JSP-a…………………………………………………………………...43
6.4. Elementi JSP-a……………………………………………………………………43

1
 6.5. Životni ciklus JSP strane……………………………………………………………..45
6.6. Prednosti JSP-a……………………………………………………………………….46
7. JavaServer Faces tehnologija……………………………………………… ...48
7.1. Prednosti JSF tehnologije…………………………………………………………….49
7.2. JSF aplikacija………………………………………………………………………...50
7.3. Model komponenti korisničkog interfejsa……………………………………………52
7.4. Životni ciklus JSF strane……………………………………………………………..52
8. Studijski primer razvoja softverskog sistema.................................................56
8.1. Zahtevi…......................................................................................................................56
8.2. Analiza..........................................................................................................................65
8.3. Projektovanje................................................................................................................81
8.4. Faza implementacije………………………………………………………………...111
9. Zaključak……………………………………………………………………..112
10. Literatura……………………………………………………………………113

2
 1. UVOD

U današnjem vremenu sve više se javlja potreba za distribuiranim,

transakcionalnim i prenosivim aplikacijama koje povećavaju brzinu, sigurnost i pouzdanost
server-side tehnologije. Jedan od trendova i tendencija današnjice je da se web aplikacije
koriste za rešavanje najrazličitijih problema iz sfere poslovanja kako malih tako i velikih
preduzeća. Kao jedno od najefikasnijih sredstava za rešavanje ovih problema samo po sebi se
nameće Java Enterprise Edition tehnologija.
U prvom delu rada je opisana Java Enterprise Edition tehnologija koja
predstavlja razvojno okruženje za složene aplikacije. Glavni cilj Java EE platforme je da
obezbedi programerima moćan aplikacioni programski interfejs (API), dok sa druge strane
smanjuje vreme razvoja i složenost aplikacije, a poboljšava aplikacione performanse.
Prikazane su i komponente ove platforme, kontejneri i moduli. Zatim je dat pregled web
modula i softverske arhitekture Model-View-Controller (MVC) koja razdvaja aplikacioni
model podataka, korisnički interfejs i kontrolu logike u tri odvojene komponente.
U drugom delu, predstavljene su tehnologije za razvoj pomenutih web
aplikacija - Servlet, JavaServer Pages i JavaServer Faces, koje omogućavaju jednostavno
pisanje i razvoj poslovnih aplikacija. Oni nude rešenja za mnoge probleme sa kojima se
susreću programeri koji se bave razvojem poslovnih softverskih sistema. Servlet je Javina
klasa i server–side komponenta koja se koristi da proširi sposobnost servera koji izvršavaju
aplikacije. U ovom delu su predstavljene i osnovne metode, životni ciklus, kao i glavne
prednosti Servlet-a. Sledeća tehnologija koja je predstavljena - JavaServer Pages, se najčešće
koristi kao prezentacioni sloj za kombinovanje HTML-a i Java kod-a. Dat je prikaz osnovnih
komponenti i elemenata, kao i životni ciklus JavaServer Pages-a. Na kraju ovog dela
prikazana je JavaServer Faces tehnologija - server-side okvir koji implementira patern
baziran na MVC arhitekturi. Najveća prednost ove tehnologije je jasno razdvajanje ponašanje
i prezentacije.
Na kraju rada, dat je studijski primer kojim su obuhvaćene navedene
tehnologije. U razvoju aplikacije iz studijskog primera primenjena je Larmanova metoda
razvoja softvera. Prva faza – prikupljanje zahteva je opisana preko modela slučaja korišćenja.
Druga faza – analiza, koja definiše logičku strukturu i ponašanje softverskog sistema, je
opisana pomoću sistemskih dijagrama sekvenci i ugovora (ponašanje softverskog sistema) i
konceptualnog i relacionog modela (struktura softverskog sistema). Treća faza –
projektovanje, definiše fizičku strukturu i ponašanje softverskog sistema (arhitektura
softverskog sistema). Na kraju je objašnjena faza implementacije, dok faza testiranje nije
razmatrana. Kao razvojno okruženje korišćen je NetBeans IDE, jedan od najpopularnijih
grafičkih alata za razvoj aplikacija u Java tehnologiji.

3
 2. JAVA Platforme

Postoje tri platforme Java programskog jezika koje su predstavljenje na slici 1:

Java 2 Platform, Micro Edition (J2ME) definiše skup izvršnih okruženja za razvoj
aplikacija za mobilne uređaje kao što su telefoni, pejdzeri i navigacioni uređaji. Mogućnosti
ove platforme su ograničene usled slabijih performansi i kapaciteteta malih uređaja.

Java 2 Platform Standard Edition (J2SE) čini standardno jezgro paketa koji se korise u
apletima, Java EE aplikacijama, Java ME i konzolnim aplikacijama. Dato jezgro čini čitav
spektar paketa za rad sa ulazom/izlazom, grafičkim korisničkim interfejsom, mrežom itd. Ova
platforma sadrži pakete koji se najčešće koriste u standardnom programiranju.

Java 2 Platform Enterprise Edition (J2EE) predstavlja nadogradnju i proširenje Java SE.
Namenjen je za razvijanje i izvršavanje velikih, višenivojskih, skalabilnih, pouzdanih i
sigurnih mrežnih aplikacija.

Slika 1: Java platforme [16]

4
 3. JAVA Enterprise Edition (JEE)

Java EE je razvojno okruženje za složene aplikacije. Sastoji se od JEE komponenti, servisa,

API-ja i protokola koji su prikazani na slici 2. Protokoli se koriste za pristup internet
servisima. Java EE platforma podržava HTTP (HyperText Transfer Protocol), TCP/IP
(Transmission Control Protocol / Internet Protocol), RMI (Remote Method Invocation),
SOAP (Simple Object Access Protocol) i SSL (Secured Socket Layer) protokol.

Slika 2: JEE nivoi, kontejneri, komponente, servisi i API [3]

Java EE platforma (Java Enterprise Edition) može se podeliti u četiri dela koja prate
odgovarajuće tehnologije:
1. Stand-alone web aplikacije ili web tehnologije koje se koriste u razvoju
prezentacionog nivoa.
2. Enterprise JavaBeans (EJB) tehnologije koje se koriste u razvoju poslovne

5
 logike JEE aplikacije.
3. Java XML tehnologije za razvoj aplikacija koje procesiraju XML dokumente i
implementiraju web servise.
4. Servisi JEE platforme.

Stand-alone web aplikacije mogu biti: Java servleti, Java server strane (JavaServer Pages -
JSP), Java server strane sa standardnom bibliotekom tagova (JavaServer Pages Standard Tag
Library - JSTL), Java server oblici (JavaServer Faces – JSF), Internacionalizacija i
lokalizacija web aplikacija.
Enterprise JavaBeans čine: Session bean-ovi, Enterprise bean-ovi, Message-driven bean-ovi i
Enterprise JavaBeans upitni jezik.
Java XML tehnologije i JEE web servisi: Java API za XML procesiranje (JAXP), Java API za
XML-RPC (JAX-RPC), SOAP attachments API za Javu (SAAJ), Java API za XML
registrovanje (JAXR).
Servisi JEE platforme koriste sledeće tehnologije: Transakcije (Transactions), Povezivanje
resursa (Resource Connections), Zaštita (Security), Java servis poruke (Java Message
Service).

3.1. Distribuirane višenivojske aplikacije

Java EE platforma podržava višenivojski distribuirani aplikacioni model za razvoj enterprise

aplikacije. Nivoi predstavljaju funkcije koje su podeljenje u različita polja, dok se svaka JEE
aplikacija sastoji iz JEE komponenti koje su instalirane na različitim računarima.
Na slici 3 su prikazane dve Java EE aplikacije:

Slika 3: Višenivojska aplikacija [2]

6
Primećujemo da postoji sledeći nivoi:
1. Klijentski nivo
2. Nivo aplikacione logike koji se sastoji iz web i poslovnog nivoa
3. Enterprise information sistem (EIS) nivo

Na Java EE serveru se izvršavaju komponente web i poslovnog nivoa, dok se na EIS serveru
izvršavaju komponente EIS nivoa. EIS server obično predstavlja neki sistem za upravljanje
bazama podataka – Database Management System.
EIS uključuje relacione baze podataka, ERP (enterprise resource planning) sisteme i velike
sisteme za transakcione procese.

3.2. Java EE komponente

Java EE komponente su sastavni deo svake Java EE aplikacije i one predstavljaju relativno
nezavisan deo koda koje se mogu dodati ili oduzeti iz aplikacije.
Java EE komponenta je samostalna funkcionalna softverska jedinica koja se sastoji od skupa
međusobno povezanih klasa i datoteka koje treba tretirati kao i obične Java klase, sa tom
razlikom sto se komponente ugrađuju u aplikaciju samo ako zadovoljavaju JEE specifikaciju.
Java EE komponente i njihov način pakovanja su prikazane u tabeli 1.

Component type Components Packaged as

Applet Applets JAR (Java ARchive)
Application client Client side Java codes. JAR (Java ARchive)
Web component JSP, Servlet WAR (Web ARchive)
Enterprise JavaBeans Session beans, Entity beans, JAR (Java ARchive)
Message driven beans
Enterprise application WAR, JAR, etc EAR (Enterprise ARchive)
Resource adapters Resource adapters RAR (Resource Adapter
ARchive)
Tabela 1: Komponente i način pakovanja

U Java EE specifikaciji razlikujemo sledeće komponente:

Aplikacioni klijenti i apleti (komponente koje se izvršavaju na strani klijenta),

Java Servlet, JavaServer Faces i JavaServer Pages predstavljaju web komponente
koje se izvršavaju na strani servera,

EJB (Enterprise Java Beans) predstavljaju poslovne komponente koje se izvršavaju na
serverskoj strani.

7
3.2.1. Java EE klijenti

Java EE klijent može biti:

- Web klijent ili
- Aplikacioni klijent.

Web klijent se sastoji iz dva dela:

1. Dinamičkih Web strana
2. Web čitača (Web browser)
Dinamičke Web strane su zasnovane na nekom markup jeziku (na primer HTML, XML...),
dok je Web čitac zadužen za prikazivanje strana koje dobija kao odgovor servera.
Web klijenti se često nazivaju tanki klijenti. Tanki klijenti obično ne izvršavaju upite nad
bazom podataka i ne izvršavaju složene operacije čije izvšenje prenose na enterprise bean-ove
koji se izvršavaju na serveru. Preko HTTP protokola se web klijent povezuje sa web nivoom
JEE aplikacije, koji predstavlja jedini način da klijent dopre do servera.

Apleti predstavlja klijentsku aplikaciju napisanu u programskom jeziku Java koja se izvršava
pomoću Java virtuelne mašine klijentskog sistema uz korišćenje čitača. Za rad apleta
potrebno je uvesti dve datoteke: java.applet.* i java.awt.*. Svaki aplet mora naslediti klasu
Applet. Apleti su najčesce male aplikacije ugnježdene u JSP/HTML stranice. Klijentskim
sistemima je najčešće potreban odgovarajući Java plug-in i verovatno policy datoteka.
Za rad apleta su potrebne sledeće metode init(), start(), paint(), stop() i destroy() respektivno:
1. init() metoda - se poziva samo jednom u toku izvršenja apleta.
2. start() metoda - se poziva i kod ponovnog pokretanja apleta tj. svaki put kada se čitač
vrati na HTML dokument koji sadrzi taj aplet.
3. paint() metoda - se poziva svaki put kada izlazni podaci moraju ponovo da se prikažu.
4. stop() metoda – ukoliko čitač napusti HTML dokument u kome se aplet nalazi.
5. destroy() metoda – ukoliko želimo da se aplet u potpunosti ukloni iz memorije.
Apleti su se koristili za odrađivanje komplikovanih formi na web-u sto sad preuzima JSF u
kombinaciji sa AJAX-om.

Aplikacioni klijenti su komponente koje se izvršavaju u kontejneru na klijentskoj strani i oni

predstavljaju rešenje problema kada se zahteva složeniji korisnički interfejs od onog koji
pruža neki markup jezik. Aplikacioni klijenti se nalaze u JAR datoteci i mogu biti direktno
instalirani na klijentskoj mašini. Oni takođe direktno pristupaju enterprise bean-ovima, ali ako
je potrebno mogu da naprave HTTP konekciju za komunikaciju sa Servletom.

8
3.2.2. Java EE server komunikacija

Komunikacija klijenta i poslovnog nivoa se može obaviti na dva načina kao što je prikazano
na slici 4. Prvi način je direktno, dok drugi način predstavlja slučaj ukoliko se klijent izvršava
u okviru čitača, JSP strana ili Servleta koji se izvršavaju na Web nivou.

Slika 4: Komunikacija sa serverom [2]

3.2.3. Web komponente

Java EE Web komponente mogu biti:

Servleti ili

JSP strane (Java Server Pages) ili

JSF (Java Server Faces) tehnologije

Servlet je komponenta koja predstavlja Java klasu koja implementira proces primanja, obrade,
i vraćanja odgovora čitaču koji je zahtev poslao.
JavaServer Pages (JSP) tehnologija omogućava lako kreiranje web sadržaja koji se sastoji i od
statičkih i od dinamičkih elemenata. Interno se JSP strane kompajliraju u Servlet-e .
JavaServer Faces tehnologija se nadograđuje na Servlete i JSP tehnologiju i obezbeđuje
okvir komponenti korisničkog interfejsa (user interface component framework) za Web
aplikacije. Web nivoi JEE aplikacije su prikazani na slici 5.
O ovim tehnologija će biti više reči u daljim poglavljima.

9
Slika 5: Web nivo i Java EE aplikacija [2]

3.2.4. Enterprise JavaBeans (EJB) komponente

Zvanična definicija bean-a, kako stoji u EJB specifikaciji glasi:

„Bean je višestruko upotrebljiva softverska komponenta zasnovana na JavaBeans
specifikaciji kompanije Sun kojom se može vizuelno manipulisati u okruženju za izradu
aplikacija. “
Enterprise Beans su JavaEE server-side komponente koje se izvršavaju unutar EJB kontejnera
i učauruju poslovnu logiku JavaEE aplikacija. Ove komponente su skalabilne, transakcione,
višenitne i mogu im pristupiti više korisnika u isto vreme.
Preko EJB komponenata se upravlja tokom podataka između aplikacionog klijenta ili apleta i
komponenti koje se izvršavaju na Java EE serveru, ili između serverskih komponenti i baze
podataka.
Enterprise JavaBeans se izvršavaju na poslovnom nivou kao što se vidi na slici 6 i predstavlja
komunikaciju između klijentskog programa i Enterprise Information System nivoa EIS-a.

Slika 6: Poslovni i EIS nivo [2]

10
Klijentski pogled (view) je definisan striktno preko interfejsa.
Enterprise bean-ovi pojednostavljuju razvoj distribuiranih aplikacija iz sledećih razloga:
1. EJB kontejner obezbeđuje sistemske servise (npr.upravljanje transakcijama) enterprise
bean-ovima, dok se programer bean-a moze koncentrisati na rešavanje poslovnih
problema.
2. Bean-ovi, a ne klijenti, sadrže poslovnu logiku aplikacije, programer klijenta se može
fokusirati na predstavljanje klijenta. Programer klijenta ne mora da piše kod rutina
koje implementiraju poslovna pravila ili pristup bazama podataka.
3. Enterprise bean-ovi su prenosive komponente. Ove aplikacije se mogu izvršavati na
bilo kojem kompatibilnom Java EE serveru.

3.2.4.1. Vrste enterprise bean-ova

Postoje tri vrste enterprise bean-ova koji su prikzane na slici 7:

- Session bean
- Entity bean
- Message-driven bean.

Slika 7: Vrste Enterprise bean-ova [16]

Session bean

Session bean predstavlja komponentu koja pruža servise iz sloja poslovne logike i on
predstavlja jednog klijenta u aplikacionom serveru. Session bean može imati najviše jednog
klijenta kao što sesija moze imati samo jednog korisnika. Session bean nije perzistentan (što znači
da se njegovi podaci ne čuvaju u sistemu za upravljanje bazom podataka). Bean klasa mora da

11
implementira javax.ejb.SessionBean interfejs. Session bean predstavlja vezu izmedju klijenta i i
entity i message bean-ova.
Session bean-ovi moraju zadovoljiti određene preduslove:
-Moraju imati konstruktor bez parametara.
-Moraju implementirati locale ili remote interface.
-Moraju biti definisani kao stateless ili statefull.
-Moraju imati polje koje predstavlja jedinstveni id.
Razlikujemo:
1. stateful i
2. stateless sesion bean-ove.

Kada su u pitanju stateful session bean-ovi, promenljive predstavljaju stanje jedistvene client-
bean sesije. Klijent i bean su u neposrednoj interakciji pa se ovo stanje često naziva
konverzaciono stanje. Stanje se čuva tokom trajanja client-bean sesije. Ukoliko klijent završi
sa radom ili ukoliko bean prekine rad, sesija se završava i stanje se vise ne čuva.
Stateless session bean ne održava konverzaciono stanje sa klijentom. Kada klijent pozove
metode stateless bean-a, promenljive pojavljivanja bean-a mogu sadržati stanje specifično za
tog klijenta, ali jedino za vreme trajanja poziva. Kada se metoda izvrši, spečificno stanje
klijenta ne bi trebalo biti sačuvano. Oni mogu da podržavaju veći broj klijenata i mogu da
implementiraju web servis, što ostali tipovi bean-ova ne mogu.

Entity bean

Session i entity imaju dva tipa interfejsa: component interfejs i home interfejs. Home interfejs
definiše metode create(), remove() i find(), kao i pristup metapodacima bean-a. Component
interfejs definiše metode poslovne logike bean-a. Entity bean reprezentuje perzistentne
podatke skladištene u tabelama baze podataka. Bean klasa mora da implementira
javax.ejb.EntityBean interfejs.
Kada se klijentska aplikacija završi ili se server ugasi entity bean podaci ostaju sačuvani.
U Java EE5 entity bean је zamenjen perzistentnim API entitetima.
Neke od glavnih razlika izmedju session i entity bean-a su sledeće:

Session bean izvršava zadatak ili proces za klijenta, dok entity bean predstavlja
poslovne objekte.

Session bean nije perzistentan, za razliku od entity bean koji jeste tj. stanje objekta
ostaje sačuvano u bazi.

Instanca entity bean je deljena od strane više klijenata, dok se kod session bean jedna
instanca vezuje za samo jednog klijenta.
Postoje dva tipa Entity bean-a:

12
 1. CMP (Container Managed Persistence)
2. BMP (Bean Managed Persistence)

Message-driven bean

Message-driven bean-ovi omogućavaju asinhronu komunikaciju klijenata sa poslovnim

slojem (EJB komponentama). Oni kombinuje osobine session bean-a i Java servisa poruke
(JMS - Java Message Service) omogućavajući poslovnim komponentama da prihvataju JMS
poruke asinhrono. On se obično ponaša kao osluškivač JSM poruka, pa je sličan osluškivaču
događaja sa razlikom da prima JSM poruke umesto događaja. Poruke mogu biti poslate od
strane bilo koje Java EE komponente - aplikacionog klijenta, drugog enterprise bean-a ili web
komponente – ili od strane JSM aplikacije ili sistema koji ne koristi Java EE tehnologiju.
Message-driven bean-ovi mogu procesirati JSM poruke ili druge tipove poruka.
Message-driven bean-ovi su relativno kratkog života, i oni takođe mogu pristupiti i ažurirati
podacima baze podataka.
Glavna razlika između message-driven bean-ova i session bean-ova je da klijenti ne pristupaju
message-driven bean-ovima kroz interfejse. Za razliku od session bean-a, message driven
bean poseduje samo bean klasu.

3.2.4.2. Sadržaj enterprise bean-a

Kako bi se kreirao enterprise bean, moraju se obezbediti sledeće:

1. Enterprise bean klasa – implementira metode definisane u poslovnom interfejsu i
neke callback metode životnog ciklusa.
2. Poslovni interfejsi – definišu metode implementirane od strane
enterprise bean klase.
3. Pomoćne klase – potrebne enterprise bean klasi, kakve su exception i
utility klase.
Datoteke se pakuju u listu u okviru EJB JAR datoteke koja je prikazana na slici 8. Kako bi se
sastavila Java EE aplikacija, pakuje se jedan ili više modula, kao što su EJB JAR datoteke, u
EAR datoteku, arhiva datoteku koja sadrži aplikaciju.

13
Slika 8: Struktura enterprise bean JAR-a [2]

3.2.4.3. Životni ciklus enterprise bean-a

Razlikujemo stateful session, stateless session, entity i message driven bean-ove. Svaki
enterprise bean prolazi kroz različite faze u svom životnom ciklusu.

Životni ciklus stateful session bean-a

Slika 9 prikazuje faze kroz koje session bean prolazi tokom svog životnog ciklusa.
Klijent inicira životni ciklus pozivanjem create() metode. EJB kontejner instancira bean i
poziva setSessionContext() i ejbCreate() metode. Dok je u stanju Ready, EJB kontejner može
odlučiti da deaktivira ili pasivizira bean pomerajući ga u sekundarno skladište. Za ovu
operaciju kontejner koristi algoritam po kome se bira bean koji je najranije korišćen (least-
recently-used algorithm). EJB kontejner zatim poziva ejbPassivate() metodu. Ako je klijent
pozvao poslovnu metodu dok je bean u pasivnom stanju, EJB kontejner aktivira bean
pozivajući ejbActivate() metodu. Na kraju životnog ciklusa klijent poziva remove() metod,
dok EJB kontejner poziva ejbRemove() metodu. Tek tada je pojavljivanje bean-a spremno za
sakupljača otpada. Klijent može pozvati samo dve metode životnog ciklusa: create() i
remove(), dok sve ostale poziva EJB kontejner.

14
Slika 9: Životni ciklus stateful session bean-a [2]

Životni ciklus stateless session bean-a

Zbog toga sto stateless session bean nikada ne može biti u pasivnom stanju, njegov životni
ciklus se može naći u samo dva stanja: nepostojeće i spremno za pozivanje poslovnih metoda
(Ready stanje). Ova dva stanja su prikazana na slici 10.

Slika 10: Životni ciklus stateless session bean-a [2]

Životni ciklus entity bean-a

Slika 11 prikazuje životni ciklus entity bean-a. Pošto EJB kontejner kreira instancu, on poziva
setEntityContext() metodu, koja prosleđuje sadržaj entiteta bean-u. Posle instanciranja, entity
bean se pomera u oblast raspoloživih instanci. Sve instance u zajedničkoj oblasti su identične.
EJB kontejner dodeljuje jednom identitetu jednu instancu u vreme kada on pomeri entity bean
u pripravno (Ready) stanje. To se može uraditi na dva načina. Prvi način je da klijent pozove
create() metod, pri čemu uzrokuje da EJB kontejner pozove ejb-Create() i ejbPostCreate()
metod. Drugi način je da EJB kontejner pozove ejbActivate() metod. Poziv poslovnih metoda
je moguće jedino kad je entity bean u pripravnom stanju (stanju Ready). Takodje postoje i dva
načina da se iz pripravnog stanja dođe u Pooled stanje. Prvi je da klijent pozove remove()
metod, što opet dovodi do toga da EJB kontejener pozove ejbRemove() metod. Dok je drugi
način da EJB kontejner pozove ejbPassivate() metod.

15
Slika 11: Životni ciklus entity bean-a [2]

Na kraju životnog ciklusa, EJB kontejener uklanja sve i poziva unsetEntityContext() metod.
U Pooled stanju, instanca nije pridružena nijednom delu EJB identiteta objekta. Kada EJB
kontejner pomeri instancu u pripravno (Ready) stanje, on ne postavlja automatski primarni
ključ. Metode ejbCreate() i ejbActivate() dodeljuju vrednost primarnom ključu. Ako je kojim
slučajem primarni ključ pogrešan, ejbLoad() i ejbStore() metode neće uspeti da sinhronizuju
instance promenljivih sa bazom podataka.
U Pooled stanju, vrednosti instance promenljivih nisu potrebne. Da bi instance promenljivih
napravili pogodnim za garbege collector-a, potrebno ih je postaviti na null u ejbPassivate()
metodi.

Životni ciklus message-driven bean-a

EJB kontejner uobičajeno kreira skup instanci message-driven bean-ova. Za svaku instancu,
on postavlja sledeće zadatke:
1. poziva se metoda setMessageDrivenContext() i prosleđuje joj sadržaj objekta
instance.
2. to uzrokuje pozivanje ejbCreate() metode instance.

Slika12: Životni ciklus message-driven bean-a [2]

16
Kao i kod stateless session bean, i message-driven bean se nikada ne mogu naći u pasivnom
stanju kao što je i prikazano na slici 12. Na kraju životnog ciklusa, kontejner poziva
ejbRemove() metod, koji priprema instancu za sakupljača otpada.

3.2.4.4. Tipovi pristupa klijenta session i entity bean-ova

Mogući pristupi o kojima ću govoriti u ovom delu se odnose samo na session i entity bean-
ove, jer message-driven bean-ovi nemaju interfejse koji definišu pristup klijenata. Ovi
interfejsi definišu poglede (view) na bean-ove, dok su svi ostali aspekti (implementacije
metoda, apstraktne šeme itd.) sakriveni od klijenta.

Tipovi pristupa klijenta mogu biti:

1. lokalni klijent (local client)
2. udaljeni klijent (remote client)
3. web servis klijent.

Udaljeni klijenti (Remote Clients)

Udaljeni klijent enterprise bean-a se može izvršavati na različitoj mašini ili različitoj Java
virtuelnoj mašini od enterprise bean-a kome pristupa i moze biti Web komponenta,
aplikacioni klijent ili drugi enterprise bean. Lokacija enterprise bean-a je vidljiva
(transparentna) udaljenom klijentu.
Moguće je na dva načina kreirati bean koji dozvoljava udaljeni pristup. Jedan je da se označi
interfejs sa Remote anotaciom:
@Remote
public interface InterfaceName
{ ... }

Dok je drugi način da se označi klasa:

@Remote(InterfaceName.class)
public class BeanName implements
InterfaceName
{ ...}

Na slici 13 vidimo udaljeni interfejs kojeg ćemo nazvati BankAccountBean, koji sadrži dve
poslovne metode: deposit() i credit().
Home interfejs definiše create() i remove() metode, dok je za entity bean-ove moguće napisati
i metode za pretragu (npr. findByPrimeryKey()).

17
Slika 13: Interfejsi za enterprise bean sa udaljenim pristupom [2]

Lokalni klijenti (Local Clients)

Lokalni klijent se mora izvršavati na istoj JVM kao i enterprise bean kome pristupa i može
biti Web komponenta ili drugi enterprise bean. Lokacija enterprise bean-a nije vidljiva
lokalnom klijentu.
Poslovni interfejs je podrazumevano lokalni interfejs, ukoliko nema nikakve oznake. Kako bi
se kreirao enterprise bean koji dozvoljava jedino lokalni pristup, može se, ali nije neophodno
uraditi nešto od sledećeg:
- Označiti poslovni interfejs enterprise bean-a kao @Local interfejs
@Local
public interface InterfaceName {...}

- Specificirati interfejs označavanjem klase bean-a sa @Local i specificiranjem imena

interfejsa
@Local(InterfaceName.class)
public class BeanName implements InterfaceName { ... }
Čvrsto upareni bean-ovi su dobri kandidati za lokalni pristup, zato što su pogodni zajedno kao
lokalna jedinica, obično pozivaju jedni druge često i imaće koristi od povećanih performansi
koje su moguće sa lokalnim pristupom. Ukoliko enterprise bean-u pristupaju aplikacioni
klijenti, onda bi on trebao dozvoliti udaljeni pristup. U distribuiranoj aplikaciji, na primer,
Web komponente se mogu izvršavati na različitom serveru od enterprise bean-a kome
pristupaju. U ovom distribuiranom scenariju enterprise bean-ovi bi trebali dozvoliti udaljeni
pristup. Usled faktora kao što su mrežna latentnost, udaljeni pozivi mogu biti sporiji od
lokalnih poziva. Sa druge strane, ukoliko se komponente distribuiraju među različitim
serverima, mogu se poboljšati ukupne performanse aplikacije.
Udaljeni pristup je uvek dobar izbor, jer pruža veću fleksibilnost. Iako je neuobičajeno,
moguće je da enterprise bean dozvoli i udaljeni i lokalni pristup. U ovom slučaju, ili poslovni

18
interfejs bean-a mora biti eksplicitno imenovan kao poslovni interfejs označavanjem sa
@Remote ili @Local anotacijom, ili klasa bean-a mora eksplicitno imenovati poslovne
interfejse korišćenjem @Remote i @Local anotacija. Isti poslovni interfejs ne može biti i
lokalni i udaljeni poslovni interfejs.

Web servis klijenti

Prvi način pristupa Java EE aplikaciji preko Web servisa je preko JAX-WS, dok je drugi
način da web servis klijent pozove poslovne metode stateless session bean-a. Anotacija
@WebMetod može biti iskorišćena za podešavanje ponašanja web servis metoda. Ukoliko je
@WebMetod anotacija iskorišćenja za označavanje metoda klase bean-a, jedino te metode
označene sa @WebMetod su izložene Web servis klijentima.

3.3. Java EE kontejneri

Kontejneri predstavljaju interfejs izmedju komponenti i platformski specifičnih

funkcionalnosti koji podržavaju izvršavanje komponenti. Na primer, pretpostavimo da je
potrebno pokrenuti web aplikaciju. Najpre se web aplikacija mora spakovati u odgovarajući
web modul i postaviti u web kontejner.
Za svaku komponentu Java EE aplikacije su potrebna detaljna podešavanja kontejnera gde
kontejner obezbeđuje odgovarajuću podršku koja je obezbeđena od strane Java EE servera,
uključujući servise kao što su zaštita, upravljanje transakcijama, Java Naming i Directory
Interface (JNDI) i udaljeno povezivanje.
Servisi Java EE servera:

Java EE model zaštite - sistemskim resursima mogu pristupiti samo autorizovani
korisnici.

Java EE transakcioni model - sve metode u jednoj transakciji se tretiraju kao jedna
jedinica.

Servis JNDI pretraživanja - obezbeđuje jedinstven interfejs za višestruko imenovanje
i servise direktorijuma.

Java EE model udaljenog povezivanja - upravlja komunikacijama niskog nivoa
između klijenata i enterprise bean-ova.
U zavisnosti od rasporeda aplikacione komponente se mogu ponašati različito u okviru iste
Java EE aplikacije. Kontejner takođe upravlja servisima koji se ne mogu konfigurisati, kao što
su životni ciklusi enterprise bean-ova ili servleta, database connection resource pooling,
perzistentnost podataka i pristup do API-a Java EE platforme.

19
3.3.1. Tipovi kontejnera

Proces raspoređivanja instalira komponente Java EE aplikacije u Java EE kontejnere.

Slika14: Java EE server i kontejneri [2]

Tipovi kontejnera su prikazani na slici 14 i oni mogu biti:

1. Web kontejner – upravlja izvršenjem JSP strana i Servlet komponenti za Java EE
aplikacije. Web komponente i njihov kontejner izvršavaju se na Java EE serveru.
Web kontejner obezbeđuje sledeće servise za Web komponente: usmeravanje
zahteva, zaštitu, konkurentnost i upravljanje životnim ciklusom.
2. Kontejner aplikacionog klijenta – upravlja izvršenjem komponenti aplikacionog
klijenta. Aplikacioni klijenti i njihov kontejner izvršavaju se na klijentu.
3. Enterprise JavaBeans (EJB) kontejner – upravlja izvršenjem enterprise bean-
ova za Java EE aplikacije.
4. Aplet kontejner – upravlja izvršenjem apleta. Sastoji se od Web čitača i Java
Plug-in–a koji se zajednički izvršavaju na klijentu.
5. Java EE server – izvršno okruženje Java EE proizvoda. Java EE server
obezbeđuje EJB i Web kontejnere.

3.4. Podrška Web servisa

Da bi se rešio problem komunikacije između različitih aplikacija potrebno je bilo obezbediti

standardizovan način razmene poruka između programa nezavisno od toga kako su programi
implementarni. Tu se pojavljuju Web servisi. Model web servisa i Java EE je prikazan na slici
15. Web servisi nude standardizovane metode komunikacije izmedu različitih aplikacija i na
taj način omogućavaju integraciju softvera na način koji do sada nije bio moguć.

20
Slika 15: Model Web servisa i JEE [16]
Web servisi su distribuirane softverske komponente koje su dostupne kroz standardne Internet
protokole. Web servisi su platformski nezavisni i to je njihov najveći značaj. Unutrašnja
implementacija neke aplikacije može da se promeni, a da to, zahvaljujuci Web servisima, ne
utice na njenu komunikaciju sa drugim aplikacijama.
Web servisi su enterprise aplikacije zasnovane na Webu koje koriste na XML-u (eXtensible
Markup Language) zasnovane standarde i transportne protokole za razmenu podataka sa
klijentima.
Protokoli koji se koriste u web servisima podeljeni su u slojeve koji su prikazani na slici 16:

transportni sloj,

sloj poruka,

sloj opisivanja servisa,

sloj procesa.

Slika 16: Slojevi protokola web servisa [18]

21
Java EE platforma obezbeđuje XML API i alate koji su potrebne za brzo kreiranje, razvoj,
testiranje i raspoređivanje Web servisa i klijenata koji u potpunosti sarađuju sa drugim Web
servisima i klijentima. Kako bi se pisali Web servisi i klijenti sa Java EE XML API-jem,
potrebno je prosleđivanje parametarskih podataka do metoda i procesiranje povratnih
podataka, ili u slučaju dokumentno orijentisanih Web servisa, slanje dokumenata koji sadrže
podatke servisa unapred i unazad. Prevođenje podataka u standardizovani na XML-u
zasnovani tok podataka (XML-based data stream) je ono što čini Web servise i klijente pisane
sa Java EE XML API-jem u potpunosti interoperabilnim. Tipičan scenario korišcenja Web
servisa je prikazan na slici 17 i on bi izgledao ovako: pretragom pomoću UDDI-a se nalazi
željeni servis i njegov URL, a zatim poslovna aplikacija šalje zahtev u XML formatu
(koristeci SOAP preko HTTP-a) servisu na datoj URL. Servis prima zahtev, obrađuje ga i
vraća odgovor, takode u XML formatu. Korišćenje web servisa može biti jednostavno, poput
prijavljivanja na određeni web sajt, ili komplikovano, kao opsluživanje poslovnih pregovora
više organizacija.
XML, SOAP i WSDL su usvojeni standardi za razmenu poruka i opisivanje web servisa, koje
omogućavaju njihovo korišćenje i integraciju bez obzira na razvojnu platformu.

Slika 17: Scenario pronalaženja i korišcenja Web servisa [3]

XML (eXtensible Markup Language)

XML je kreiran 1996. godine od strane W3C (World Wide Web Consortium) i predstavlja
podskup jezika SGML (Standard Generalized Markup Language, standardni opšti markerski
jezik). XML dokumenta predstavljaju samoopisujuće, platformski nezavisne tekstualne
datoteke sa hijerarhijskom strukturom. Ovaj dokument se sastoji od teksta (sadržaj
dokumenta) i tagova. XML opisuje strukturu i značenje dokumenta. XML je proširiv, na
tekstu zasnovan standard za prezentovanje podataka. Naziva se proširivim jer omogućava
korisnicima da sami definišu elemente, a jezikom za označavanje zbog činjenice da
dokumenti u XML-u ne opisuju kako će se dokumenti prikazivati, već strukturu i semantiku
podataka.
XML nije nalik drugim markup jezicima, kakav je na primer HTML. XML je meta-markup

22
jezik. Meta-jezik predstavlja jezik pomoću koga se opisuju drugi jezici. Markup jezici
definišu standardni set tagova koji opisuju fiksiran broj elemenata. XML omogućava kreiranje
sopstvenih tagova koji su potrebni. Ovi tagovi moraju biti organizovani u skladu sa
određenim opštim principima, ali su u svakom slučaju prilično fleksibilni u svojem značenju.
Strane, takođe, mogu podešavati šeme kako bi specificirale koji tagovi se mogu koristiti u
pojedinim oblicima XML dokumenata. Šema se može posmatrati kao rečnik i sintaksa za
određene oblike dokumenata. XML ne opisuje formatiranje elemenata na strani. Formatiranje
se može dodati dokumentu pomoću style sheet-ova. Style sheet-ovi se koriste kako bi se
upravljalo prikazom i obradom podataka.
W3C je ponudio dva standarda načina za opisivanje strukture XML dokumenta:
1. Document Type Definition (DTD)
2. XML Shema Definition (XSD)
Neke XML tehnologije:
- Procesiranje XML dokumenata (XML parseri, XSLT jezik)
- Specifikacija logičke strukture (DTD,XSD)
- Upitni XML jezici (Xpath, XQuery)

SOAP transportni protokol

SOAP predstavlja standardizovani protokol za transport XML dokumenata preko niza
standardnih Internet protokola, uključujući SMTP, HTTP i FTP.
Klijentski zahtevi i odgovori Web servisa se prenose kao Simple ObjectAccess Protocol
(SOAP) poruke preko HTTP-a omogućavajući potpunu interoperabilnost razmene između
klijenata i Web servisa, koji se mogu izvršavati na različitim platformama i na različitim
lokacijama na Internetu.

Slika 18: SOAP poruka [18]

23
HTTP je poznati request-response standard za slanje poruka putem Interneta, a SOAP je na
XML-u zasnovan protokol koji prati HTTP request-response model.
SOAP poruka je običan XML dokument koji sadrži sledeće elemente koji su prikazani na slici
18:

Envelope

Header (opcioni)

Body
Envelope je element koji identifikuje XML dokument kao SOAP poruku i označava početak i
kraj poruke. U okviru ovog elementa se nalaze i header i body elementi. Header obezbeđuje
informacije o sadržaju i dužini tipa, kao i primaocu poruke. Body element sadrži informacije
od primaoca poruke.

WSDL standardni format

WSDL (Web Services Description Language) predstavlja XML tehnologiju koja opisuje
interfejs web servisa na standardizovan način. WSDL dokument opisuje šta web servis radi,
daje detalje o tome kako se pozivaju njegove operacije i gde zahtevi za pozivom treba da
budu upućeni. WSDL je standardizovani XML format za opisivanje mrežnih servisa. Opis
uključuje ime servisa, lokaciju servisa i način komunikacije sa servisom. WSDL opisi servisa
mogu se čuvati u UDDI registrima i/ili mogu biti objavljeni na Web-u.

UDDI standardni format

UDDI (Universal Description, Discovery and Integration) omogućava postojanje svetskog
registra za web servise, kako bi se isti mogli otkriti (locirati) i upotrebiti u integracione svrhe.
UDDI pruža strukturu za predstavljanje poslova, poslovnih veza, web servisa, metapodataka
specifikacija, kao i pristupnih tačaka web servisa.

3.5. Pakovanje Java EE aplikacija

Da bi se stvorila jedna JEE aplikacija potrebno je napraviti JEE modul, a zatim upakovati taj
JEE modul. Pakovanje aplikacije predstavlja proces sakupljanja komponenata u module i
modula u složenu aplikaciju, dok raspoređivanje predstavlja proces postavljanja i prihvatanja
aplikacije u operativno okruženje.
Java EE aplikacija se najčesce pakuje u Enterprise Archive (EAR) datoteku koja je standardna
JAR datoteka sa ekstenzijom .ear. Uz pomoć ovog pakovanja moguće je spajati više različitih
Java EE aplikacija bez ikakvog dodatnog programiranja. Struktura EAR datoteka je prikazana
na slici 19.

24
Slika 19: Struktura EAR datoteke [2]

EAR datoteka sadrži Java EE module i opisivač rasporeda.

Opisivač rasporeda je XML dokument sa .xml ekstenzijom koji opisuje podešavanja
raspoređivanja aplikacije, modula ili komponente. U runtime-u, Java EE server čita opisivač
rasporeda i deluje na aplikaciju, modul ili komponentu prema tome.
Opisivača rasporeda moze biti:
1. Java EE opisivač rasporeda – definisan je Java EE specifikaciom i može se koristiti za
konfigurisanje podešavanja raspoređivanja bilo koje Java EE komplementarne
implementacije.
2. Runtime opisivač rasporeda – koristi se za konfigurisanje specifičnih parametara Java
EE implementacije.
Minimalan sadržaj aplikacionog paketa se sastoji iz jednog JEE modula i aplikacionog
opisivača rasporeda. Na primer, Sun Java System Application Server Platform Edition 9
runtime opisivač rasporeda aplikacionog servera je nazvan sun-moduleType.xml i lociran u isti
direktorijum kao i Java EE opisivač rasporeda. Java EE modul se sastoji od jedne ili više Java
EE komponenti za isti tip kontejnera i jednog opisivača rasporeda tog tipa. Java EE modul bez
opisivača rasporeda aplikacije može biti raspoređen kao samostalni modul.

3.6. Java EE moduli

Postoje četiri tipa Java EE modula:

1. Enterprise JavaBeans modul
2. Web modul
3. Modul aplikacionog klijenta
4. Modul adaptera resursa

EJB modul je upakovan i raspoređen kao EJB JAR datoteka sa ekstenzijom .jar. Predstavlja
najmanju rasporedivu jedinicu enterprise bean-ova.

25
Sadržaj EJB modula:
- Java class datoteke za enerprise bean-ove i njihove remote i home interfejse
- Java class datoteke za bilo koje klase i interfejse od kojih enterprise bean kod zavisi a
koje nisu uključene sa JEE platformom
- EJB opisivač rasporeda koji obezbeđuje strukturnom i aplikacionom sastavljaču
(assembler-u) informacije o enterprise bean-u u EJB modulu.
EAR datoteka se razlikuje od standardne JAR datoteke u tome što uključuje opisivač rasporeda
( nazvan META-INF/ejb-jar.xml) koji sadrži meta podatke o enterprise bean-ovima.

Web modul je upakovan i raspoređen kao Web Archive (WAR) datoteka, JAR datoteka sa .war
ekstenzijom. Predstavlja najmanju rasporedivu jedinicu Web resursa.
Web modul sadrzi:

Java class datoteku za servlete i klase od kojih zavise.

JSP datoteke i Javine klase za podršku.

Statička dokumenta kao što su HTML, slike, muzika.

Aplete i njegove klase.

Web opisivač rasporeda (web.xml).
Kao i drugi tipovi modula, WAR datoteka moze biti raspoređena nezavisno kao Web
aplikacija ili paket u EAR datoteku.

Modul aplikacionog klijenta je upakovan u JAR datoteku sa .jar ekstenzijom. Modul

aplikacionog klijenta sadrzi:

Java klase koje implementiraju klijenta i

Opisivač rasporeda aplikacionog klijenta.
Klijentska JAR datoteka se sastoji od svih klasa koje su klijentskom programu neophodne za
pristup enterprise bean-u u EJB modulu.

Modul adaptera resursa je upakovan i raspoređen kao Resource Adapter Archive (RAR)
datoteka, JAR datoteka sa .rar ekstenzijom. Modul adaptera rasursa sadrži:

Java class datoteke za klase i interfejse koje implementiraju Connector.

Pomoćne datoteke i dokumentaciju.

Opisivač rasporeda adaptera resursa.
Modul adaptera resursa zahteva podršku urodjenim datotekama (native libraries).

26
 3.7. Java EE API

Java API koristi četiri tipa tehnologija:

1. Komponentne
2. Servisne
3. Integracione
4. Komunikacione
Neke od ovih tehnologija su prikazane u tabeli 2.

JEE technology category API (Application Program Interface)

Component model tech Java Servlet, JavaServer Pages(JSP), Enterprise JavaBeans
(EJB).
Web services technology JAXP (Java API for XML Processing), JAXR (Java API for XML Registries), SAAJ

(SOAP with attachment API for Java), JAX-RPC (Java API for XML-based RPC), JAX-

WS (Java API for XML-based Web Services).

Other JDBC (Java Database Connectivity), JNDI (Java Naming and Directory Interface), JMS

(Java Messaging Service), JCA (J2EE Connector Architecture), JTA (Java Transaction

API), JavaMail, JAF (JavaBeans Activation Framework – used by JavaMail), JAAS (Java

Authentication and Authorization Service), JMX (Java Management eXtenstions).

Tabela 2: JEE i API

3.8. Web i aplikacioni serveri

Java EE server prati i upravlja izvršenjem Java EE aplikacija. Java EE server može biti:
1. Web server (npr. Apache Tomcat) koji radi sa web komponentama: Servlet, JSP i Web
servisi ili
2. i Web i aplikacioni server (npr.GlassFish) koji radi i sa EJB komponentama
Razlike između web i aplikacionog servera su prikazane u tabeli 3. Aplikacioni serveri
pripremaju podatke za web server – npr. dobavljaju podatke iz baza podataka, procesiraju
sigurnosne provere, prilagođavaju poslovna pravila itd. Web server se koristi da podrži web
komponente kao što su Servleti i JSP. Treba naglasiti da web serveri ne podržavaju EJB
komponentu.

27
Tabela 3: Razlika između web i aplikacionog servera
Web Server Application Server
Podrzava HTTP protokol. Kada Web server primi HTTP zahtev, on Izlaze poslovnu logiku i dinamički sadržaj klijentu kroz protokole

vraća nazad HTTP odgovor, kao što je slanje HTML stranice kao sto su HTTP, TCP/IP, IIOP, JRMP itd. Takodje obezbeđuje

(statički sadržaj) ili delegira dinamički odgovor preko drugog upravljanje životnim ciklusom komponenata, upravljanje

programa kao što je CGI scripts ili Servleti ili JSP stranice u transakcijama, sigurnošću, obezbeđuje servise za komponenete kao

aplikacioni server. sto je web kontejener za Servlete i EJB kontejener za EJB

komponente i sl.

Granica izmedju web i aplikacionog servera nije skroz jasna, pogotovo sa pojavom XML
dokumenata koji sluze za komunikaciju zahtev-odgovor. Takođe se može desiti da se jedan
web server ponaša kao aplikacioni server. Neki primeri servera dati su u tabeli 4.

Web Servers Apache, Microsoft IIS, Netscape, Domino

etc
Application Servers IBM Websphere, BEA Weblogic, Apache
Tomcat, Borland Enterprise Server, Fujitsu
Interstage, JBoss, ATG Dynamo etc
LDAP Servers IPlanet’s directory server, SiemensDirX etc
Database Servers IBM DB2, Oracle, SQL Server, Sybase,
Informix
Tabela 4: Primeri servera

28
 4. Web aplikacija

Web aplikacija predstavlja aplikaciju koja se izvršava u okruženju Web servera. Web
aplikacija se sastoji od Web komponenti, standardnih Javinih klasa, HTML strana, JavaBeans
komponenti i Message Handler komponenti. Postoje dva tipa Web aplikacija:
1. Prezentaciono orijentisane: Prezentaciono orijentisana Web aplikacija generiše
interaktivne Web strane koje sadrže različite tipove markup jezika (HTML, XML i
slične) i dinamički sadržaj kao odgovor na zahteve.
2. Servisno orijentisane: Servisno orijentisana Web aplikacija implementira krajnju
svrhu Web servisa. Prezentaciono orijentisane aplikacije su često klijenti servisno
orijentisanih Web aplikacija.
Java Servleti, JSP strane ili krajnji Web servisi predstavljaju Web komponente koje
obezbeđuju dinamičko proširenje sposobnosti Web servera.
Interakcija između Web aplikacije i Web klijenta je prikazana na slici 20. Klijent šalje HTTP
zahtev do Web servera koji konvertuje zahtev u HTTPServletRequest objekat. Ovaj objekat se
dostavlja do Web komponente, koja može da bude u interakciji sa JavaBeans komponentama
ili sa bazom podataka kako bi generisala dinamički sadržaj. Web komponenta može zatim da
generiše HTTPServletResponse objekat ili prosledi zahtev do druge Web komponente.
Krajnje Web komponenta generiše HTTPServletResponse objekat. Web server konvertuje
ovaj objekat u HTTP odgovor i vraća ga nazad do klijenta.

Slika 20: Interakcija između Web aplikacije i Web klijenta [2]

Javine klase koje dinamički procesiraju zahteve i konstruišu odgovore su Servleti. JSP strane
su tekstualni dokumenti koji se izvršavaju kao i Servleti, ali koji omogućavaju prirodniji
pristup kreiranju statičkog sadržaja. Svaka od ovih tehnologija ima svoje prednosti. Servleti
su najpogodniji za servisno orijentisane aplikacije (krajnji Web servisi su implementirani kao

29
Servleti) i za kontrolne funkcije prezentaciono orijentisanih aplikacija, kao što su usmeravanje
zahteva i obrada netekstualnih podataka. JSP strane su pogodnije za generisanje tekstualnih
markup-a, kao što su HTML, Scalable Vector Graphics (SVG), Wireless Markup Language
(WML) i XML. Od pojave Java Servlet i JSP tehnologije, razvijene su i druge Java
tehnologije i okviri za kreiranje interaktivnih Web aplikacija. Slika 21 prikazuje ove
tehnologije i njihove veze.

Slika 21: Java tehnologije [2]

Osnova svih ostalih tehnologija Web aplikacije je Java Servlet tehnologija. Svaka tehnologija
dodaje određeni nivo apstrakcije koji omogućava lakši razvoj Web aplikacija i njihovih
prototipova. Web komponente su podržane od strane servisa runtime platforme nazvanog
Web kontejner. Web kontejner obezbeđuje servise kao što su usmeravanje zahteva, zaštita,
konkurentnost i upravljanje životnim ciklusom. On takođe omogućava Web komponentama
pristup API-jima kao što su imenovanje, transakcije i e-mail.
Izvesni apekti ponašanja Web aplikacije mogu biti konfigurisani kada je aplikacija instalirana,
ili raspoređena, u Web kontejneru. Konfiguracione informacije se održavaju u
tekstualnoj datoteci u XML formatu zvanoj opisivač rasporeda Web aplikacije koji se
mora slagati sa šemom opisanom u Java Servlet specifikaciji.

4.1. Evolucija Java EE Web tehnologija

Ranije je svaka aplikacija imala svoj klijentski program koji je radio kao korisnički interfejs i
bilo je potrebno instalirati ga na svaku korisničku mašinu. Većina web aplikacija koriste
HTML/XHTML koji je podržan od strane svih čitača i web strane ih prikazuju klijentima kao
statičke dokumente. Slika 22 prikazuje evoluciju web tehnologija na Java EE platformi.

Slika 22: Evolucija Java EE web tehnologije

Pre Java Servleta, CGI (Common Gateway Interface) skript je predstavljao glavnu

30
tehnologiju korišćenu za generisanje dinamičkog sadržaja. Iako široko rasprostranjena CGI
tehnologija ima i nekoliko mana uključujući platformsku zavisnost i nedostatak skalabilnosti.
Posle CGI skripta pojavljuju se Java Servlet-i i postaju osnova svih web tehnologija na Java
EE platformi. Servleti obezbeđuju odlične preduslove za razvoj web komponenata i aplikacija
koje su dinamičke, prenosive kroz web kontejner i sa korisnički orijentisanim sadržajem.
Jedan od nedostataka servleta je što zahtevaju dosta kodiranja - ceo HTML kod se prikazuje
korišćenjem println() metoda. Servlet ne obezbeđuje spoj izmedju grafičkog projektanta koji
projektuje izgled strana i Java programera koji kreira dinamički sadržaj. JSP predstavlja
sledeći nivo u razvoju web tehnologija. JSP premošćuje jaz izmedju projektanta (dizajnera) i
programera. Bazirane na Java Servlet tehnologiji, JSP strane su HTML strane sa ugrađenim
Java kodom. Ovaj model omogućuje projektantu da kreira strane sa dinamičkim sadržajem.
Prilikom kompajliranja, JSP strane postaju Java servleti. Mnogi programeri se bave zadacima
kao sto je prolaženje kroz kolekciju podataka, što dovodi do kreiranja JSP Standard Tag
Library (JSTL), koji automatizuje neke od ovih zadataka. Tehnološka unapređenja, koja su
obezbedila znantno jednostavniji pristup izgradnje web aplikacija, nisu razvila standardni
komponentni model za razvoj web aplikacija. JSF predstavlja jednu od poslednjih Java EE
web tehnologija. JSF sadrzi komponentni model, kojim se omogućava izdavanje
komponenata koje se mogu ponovo koristiti i lakši način izgradnje web aplikacija.

4.2. Web moduli

Web resursi predstavljaju Web komponente i statičke Web datoteke kao što su slike. Web
modul je najmanja rasporedljiva i upotrebljiva jedinica Web resursa. Java EE Web modul
odgovara Web aplikaciji kako je definisano u Java Servlet specifikaciji.
Web modul može sadržati različite datoteke:
- Server-side utility klase (database beans, shopping carts i slične)
- Client-side klase (apleti i utility klase).
Web modul ima specifičnu strukturu koja je prikazana na slici 23. Direktorijum najvišeg
nivoa Web modula je dokument koren aplikacije. Dokument koren se nalazi tamo gde su JSP
strane, client-side klase i arhive, i statički Web resursi, kao što su slike. Dokument koren
sadrži poddirektorijum nazvan /WEB-INF/, koji sadrži sledeće datoteke i direktorijume:
- web.xml: Opisivač rasporeda Web aplikacije
- .tld: Datoteke za opis tag biblioteke
- classes: Sadrži server-side klase: Servlete, utility klase i JavaBean komponente
- tags: Direktorijum koji sadrži tag datoteke, koje su implementacije tag biblioteka
- lib: Direktorijum koji sadrži JAR arhive biblioteka koje pozivaju server-side klase.
Ukoliko Web modul sadrži samo JSP strane i statičke datoteke onda nije neophodno uključiti
web.xml datoteku. Web modul može biti raspoređen kao nespakovana struktura datoteka ili

31
može biti spakovan u JAR datoteku poznatu kao Web archive (WAR) datoteka sa .war
ekstenzijom. Da bi se WAR datoteka postavila na aplikacioni server, mora sadržati i runtime
opisivač rasporeda (runtime deployment descriptor). Runtime opisivač rasporeda je XML
datoteka koja sadrži informacije o kontekstu korena Web aplikacije i o preslikavanju imena
aplikacionih resursa ka resursima aplikacionog servera. Runtime opisivač rasporeda Web
aplikacije je nazvan sun-web.xml i on se nalazi u /WEB-INF/ zajedno sa opisivačem
rasporeda Web aplikacije.

Slika 23: Struktura Web modula [2]

4.3. Model-View-Controller arhitektura

Model-View-Controller (MVC) je softverska arhitektura koja razdvaja aplikacioni model

podataka, korisnički interfejs i kontrolu logike u tri odvojene komponente.
Evolucija MVC arhitektura:

Model 1 (Page-centric)

Model 2 (Servlet-centric)

Web application frameworks (Struts)

Standard-based Web application framework (JavaServer Faces)
MVC predstavlja okvir za razvoj složenih Web aplikacija. Interaktivne aplikacije distribuiraju
svoje funkcionalnosti kroz aplikacione objekte kako bi smanjile stepen dupliranja između
objekata. Da bi se to postiglo aplikacija se deli na tri sloja: model, view i controller kao što se
može videti na slici 24. Svaki sloj obrađuje specifične zadatke i poseduje odgovornosti ka
ostalim slojevima:
1. Model predstavlja poslovne podatke, zajedno sa poslovnom logikom ili operacijama koje
upravljaju pristupom ili modifikaciom ovih poslovnih podataka. Model obaveštava view

32
 kada dodje do promena i dozvoljava view-u da ispituje model o njegovom stanju. On
takodje omogućava controller-u da pristupi aplikacionoj funkcionalnosti sadržanoj u
model-u.
2. View prikazuje sadrzaj model-a. Dobija podatke od model-a i definiše kako će ti podaci
biti prezentovani. Vrši ažuriranje prezentacije podataka kada u model-u dodje do
promena. View takodje prosledjuje ulazne podatke do controller-a.
3. Controller definiše ponašanje aplikacije. Prihvata korisničke zahteve i odabira view-ove
za prezentaciju. Interpretira ulazne podatke i preslikava ih u akcije koje će obaviti model.
U Web aplikaciji, ulazni podaci su HTTP GET i POST zahtevi. Controller odabira naredni
view za prikaz na osnovu korisničke interakcije i rezultata operacija model-a.
Neke od prednosti MVC arhitekture su:
- Jasan način projektovanja
- Efikasna modularnost
- Lak način distribucije
- Moćni korisnički interfejs
- Lak način rasta aplikacije

Slika 24: JEE MVC Model 2 [3]

33
 5. Java Servlet tehnologija

5.1. Servlet i servlet kontejner

Java Servlet tehnologija je nastala kao odgovor na Common Gateway Interface (CGI)
programiranje, koje se ranije koristilo kao glavna tehnologija za generisanje dinamičkog
sadržaja. Servleti su jedan od načina da se izgrade interaktivne web aplikacije.
Servlet je Javina klasa i server-side komponenta koja se koristi da proširi sposobnosti servera koji
izvršavaju aplikacije kojima se pristupa po principu modela zahtev-odgovor.

Slika 25: Servlet Request-Response model [17]

U zahtev-odgovor modelu koji je prikazan na slici 25, klijent šalje zahtev serveru i server
odgovara tako što šalje nazad odgovor. Http zahtev sadrži: header (zaglavlje), metode (Get,
Post, Put, Header) i zahtevane podatke. Iako servleti mogu da odgovore bilo kom tipu
zahteva, obično se koriste da prošire aplikacije koje se izvršavaju na Web serveru. Za takve
aplikaciije, Java Servlet tehnologija definiše HTTP-posebne klase servleta. Kada servlet primi
zahtev od klijenta, on generiše odgovor, verovatno pozivanjem poslovne logike u enterprise
bean-u ili direktnim postavljanjem upita bazi podataka. Servlet onda šalje odgovor – kao
HTML ili XML dokument .
Svaki servlet mora da implementira javax.servlet.Servlet interfejs. Vecina servleta
implementira interfejs nasleđivanjem jedne od klasa:

javax.servlet.GenericServlet

javax.servlet.http.HttpServlet, koji nasleđuje GenericServlet.
Generic Servlet prekriva service() metodu da prosledi zahteve i generiše odgovore, dok
HttpServlet prekriva sledeće metode: doPost( ), doGet( ) or service( ) method.
Tabela 5 prikazuje metode klase HttpServlet:
HTTP zahtev HttpServlet metoda
GET doGet(HttpServletRequest request, HttpServletResponse response)

POST doPost(HttpServletRequest request, HttpServletResponse response)

PUT doPut(HttpServletRequest request, HttpServletResponse response)

DELETE doDelete(HttpServletRequest request, HttpServletResponse response)

Tabela 5: Metode klase HttpServlet

34
Servletska klasa nije deo JDK (Java Development Kit). Servlet je objekat koji se učitava i
pokreće sa servletske mašine ili servletskog kontejnera, kao što je Apache Tomcat.
Servlet kontejner je kompajliran, izvršni program, koji sadrži sledeće funkcije:

Učitavanje

Inicijalizovanje

Izvršavanje
Postoje dve grupe kontejnera. Prva, koja može izvršavati samo jednostavnije servlete, dok je
druga grupa u stanju da obavlje sledeće: poziva init() i destroy() metode, obrazuju
pojavljivanje javax.servlet.ServletRequest i javax.servlet.ServletResponse objekata, pozivaju
service metode itd.

Primer servleta:

import java.io.*;
import java.net.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ServletPrimer extends HttpServlet {
/**
* Processes requests for both HTTP <code>GET</code> and <code>POST</code>
methods.
* @param request servlet request
* @param response servlet response
*/
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
out.println("<html>");
out.println("<head>");
out.println("<title>Servlet ServletPrimer</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>Servlet ServletPrimer<h1>");
out.println("</body>");
out.println("</html>");
} finally {
out.close();
}
}
/**
* Handles the HTTP <code>GET</code> method.
* @param request servlet request
* @param response servlet response
*/

35
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException {
processRequest(request, response);
}
/**
* Handles the HTTP <code>POST</code> method.
* @param request servlet request
* @param response servlet response
*/
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException {
processRequest(request, response);
}
/**
* Returns a short description of the servlet.
*/
public String getServletInfo() {
return "Short description";
}
// </editor-fold>
}
Web aplikacije se pakuju u .war fajl i jedan od načina da se kreira .war fajl je sledeći -
otvorite command prompt iz servlet-example direktorujuma i izvršite sledeću liniju:

jar cvf ServletPrimer.war *

Ova komanda će upakovati sav sadržaj servlet-example direktorijuma u arhivu nazvanu

servletexample.war. Oznake cvf predstavljaju sledeće:
* -c opcija kreira novi WAR fajl.
* -v opcija generiše verbose output.
* -f opcija specificira ciljno ime WAR fajl-a.
Takođe možemo koristiti sledeću komandu da vidimo sadržaj ServletPrimer.war fajla:

Jar –tvf ServletPrimer.war

Zatim ćemo .war fajl kopirati u <TOMCAT_HOME>/webapp direktorijum. Na ovaj način

smo postavili aplikaciju na Tomcat web server. Aplikaciji možemo pristupiti preko čitača:
http://localhost:8080/ServletPrimer/.

5.2. Osnovne metode servleta

Osnovne metode servleta su:

1. init() je namenjena za inicijalizaciju servleta i poziva se samo jednom. Jedan od
osnovnih zadataka ove metode je čitanje inicijalizovanih parametara.
Primer:

36
 public void init() throws ServletException {
ServletConfig config = getServletConfig();
String param1 = config.getInitParameter("SomeParameter"); }
2. service() proverava tip zahteva (GET, POST, PUT, DELETE, itd.) i poziva
respektivno doGet, doPost, doPut, doDelete.
3. getServletConfig() – ova metoda najčešce prosleđuje ServletConfig objekat init()
metodi.
4. getServletInfo()- je metoda koja vraća informacije o servletu.
5. destroy()- poziva se prilikom uništavanja servleta, i daje mogućnost servletu da zatvori
vezu sa bazom, prekine niti itd.

5.3. Životni ciklus servlet-a

Životni ciklus servleta se sastoji iz četiri faze:

1. Učitavanje
2. Inicijalizacija
3. Obrada zahteva
4. Uništavanje servleta
5. Pražnjenje servleta
Ove faze su predstavljene na slici 26:

Slika 26: Životni ciklus servleta [15]

Učitavanje servleta zavisi od atributa <load-on-startup> iz web.xml datoteke. Servlet se
učitava iz kontejnera ako ovaj atribut ima pozitivnu vrednost, u suprotnom se učitava kada
stigne prvi zahtev iz servisa.
Kontejner kreira pojavljivanje servleta koristeći Class.forName(ServletName).newInstance().
Ovo je razlog zašto nemamo konstruktor za servlet, tj. kontejner obavlja ovaj posao za nas.
Ovaj proces se inače zove inicijalizacija, što predstavlja nasu drugu fazu. Postavlja se pitanje
kako kontejner zna koji servlet da učita i gde da ga nađe. Za svaku web aplikaciju postoji
deployment descriptor datoteka koji je pridružen web aplikaciji i koji se zove web.xml. Kada

37
se kontejner pokrene, jedna od njegovih aktivnosti je da prosledi web.xml i da pročita naziv
klase servleta i da ih napuni. Kontejner inicijalizuje servlet pozivajući init(ServletConfig obj)
metodu, pri čemu ServletConfig objekat sadrži inicijalizovane parametre pročitane iz web.xml
datoteke. Inicijalizovani parametri traju do poziva destroy() metode. Servlet će biti sposoban za
rad ako je uspešno učitan. Ukoliko nije uspešno učitan servletski kontejner "prazni" (unload)
servlet. Posle inicijalizacije, servlet je spreman za rad i on kreira posebne niti za svaki zahtev.
Servletski kontejner poziva service() metodu za obradu zahteva. Metoda service() određuje vrstu
zahteva i poziva odgovarajuću metodu za obradu zahteva i slanje odgovora klijentu. Ukoliko
servlet duže vreme nije potreban za obradu zahteva, kontejner poziva metodu destroy(). Jednom
kad je pozvana metoda destroy() tj. kad je pojavljivanje servleta uništeno, poziva se sakupljač
otpada i tada dolazi do poslednje faze – pražnjenje servleta.

5.4. Filterovanje zahteva i odgovora

Za transformaciju zaglavlja i sadržaja zahteva ili odgovora se koristi poseban objekat kojeg
nazivamo filter. Filteri ne kreiraju odgovor, ali obezbeđuju funkcionalnost koja može biti
prikačena za bilo koji web resurs. Filter može biti zakačen za više od jednog tipa Web
resursa.

Slika 27: Filter [3]

Servletske filtere treba posmatrati kao lanac koraka (kao što je prikazano na slici 27) kroz
koje svaki zahtev/odgovor treba proći pre nego sto pristupi Servletu, JSP-u ili HTML stranici
u web aplikaciji.
Zadaci koje filter može obaviti su sledeći:

Istražiti zahtev i ponašati se u skladu sa tim

Blokirati par zahtev-odgovor od prosleđivanje bilo gde dalje

Promeniti zaglavlja i podatke zahteva

Promeniti zaglavlja i podatke odgovora

Stupiti u interakciju sa spoljnim resursima
Fiter ima svoje tri metode:
1. void init(FilterConfig config) throws ServletException

38
 2. void destroy()
3. void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException,ServletException.
Aplikacije filtera uključuju autentifikaciju, logovanje, konverziju slika, kompresiju podataka,
enkripciju, tokenizirajuće stream-ove, XML transformacije i slično. Može se podesiti da Web
resurs bude filtriran od strane lanca od nijednog, jednog ili više filtera u određenom
redosledu.

5.5. Obrada izuzetaka

Izuzeci se mogu desiti za vreme izvršavanja ili kompajliranja. Neki od opštih izuzetaka koji se
sreću u radu sa servletima su HTTP Servlet greške kao što su Internal server greške 500 i
404, greške koje se javljaju pri radu sa podacima kao što su NumberFormatError,
NullPointerException i DivideByZeroException. U servletima, izuzeci su predstavljeni preko
pojavljivanja klase javax.servlet.ServletException. Postoji više tehnika za obradu izuzetaka u
servletu, neke od njih su:

Korišćenje web.xml datoteke za obradu izuzetaka.

Korišćenje RequestDispatcher za prosleđivanje zahteva na error stranu.

Korišćenje HttpServletResponse metode sendError().

Korišćenje Web Application Log za beleženje poruke o izuzetku.

Korišćenje HttpServletResponse metode setStatus() za vraćanje stanja greške čitaču.

Pristupanje atributima greške iz HttpServletRequest objekata.

5.6. Prednosti Servlet-a

Servlet obezbeđuje platformski nezavisne metode za razvoj web aplikacija, bez ograničenja
performansi kao što je to bio slučaj sa CGI-em. Korišćenjem servleta web programeri mogu
kreirati brže i efikasnije server-side aplikacije.
Prednosti Servleta:

Bez CGI ograničenja (platformska zavisnost i nedostatak skalabilnosti)

Pristup Java API-u

Veliko mnoštvo third-party alata i Web servisa

Bolja performansa i skalabilnost

Platformska i serverska nezavisnost

Zaštita
Prenosivost Servleti su napisani u Javi i prate dobro poznat standardizovan API pa je tako
visoko prenosiv kroz operativni sistem i serversku implementaciju.
Snaga Pomoću servleta se mogu izvršiti operacije koje je jako teško ili nemoguće izvršiti sa

39
CGI-om, na primer servlet moze direktno da komunicira sa web serverom, dok CGI programi
ne mogu. Servleti mogu deliti podatke između sebe i održavati sesiju korišćenjem mehanizma
za praćenje (session tracking mechanism), koji im pomaže da čuvaju informacije od zahteva
do odgovora.
Bezbednost Kako su servleti napisani u Javi, oni nasleđuju visok nivo sigurnosti Java jezika.
Javin automatski sakupljač otpada i nedostatak pokazivača znači da su servleti sigurni od
problema koji nastaju usled lošeg upravljanja memorijom. U servletima se mogu lako
obrađivati greške kroz Javin mehanizam za obradu izuzetaka.
Integracija Servleti su čvrsto povezani sa serverom. Servlet može koristiti server pri
prevođenju putanje datoteke, logovanju i proveri autorizacije.
Proširljivost Servlet API je projektovan na takav način da se može veoma lako proširiti.
Danas, servlet API podržava HTTP Servlet-e, što ne znači da se u budućnosti API neće
proširiti na neki drugi tip servleta.

40
 6. JavaServer Pages tehnologija
6.1. Uvod u JSP

JavaServerPages (JSP) predstavlja proširenje Java Servlet tehnologije i najčešće se koristi kao
prezentacioni sloj za kombinovanje HTML i Java kod-a. JSP stranica je tekst dokument koji
sadrži dva tipa teksta: statične podatka koji predstavljaju bilo koji tekstualno bazirani format
(HTML, SVG, WML i XML) i JSP elemente koje konstruišu dinamički sadržaj. Primer JSP-a
je prikazano na slici 28. JSP odvaja poslovnu logiku od prezentacije, pri čemu je poslovna
logika implementirana kao Java Bean ili custom tagovi.

Slika 28: JavaServer Pages [3]

Kao i sa normalnim stranicama, čitač šalje HTTP zahtev Web serveru. Ovo se ne menja sa
JSP-om, iako se URL verovatno završava sa .jsp, pre nego sa .html. Web server je Java
server, koji je sposoban da identifikuje servlete i rukovodi njima. Web server zatim prosleđuje
HTTP zahtev JSP mašini koja konvertuje JSP stranicu u Servlet. JSP mašina kompajlira
Servlet u izvšnu klasu i prosleđuje originalni zahtev Servlet mašini. Primetimo da JSP mašina
konvertuje JSP stranicu u Servlet i rekompajlira je, samo ako se JSP stranica promenila od
poslednjeg zahteva. Deo Web servera kojeg nazivamo Servlet mašina učitava Servlet klasu i
izvršava je. Tokom izvršavanja, Servlet generiše izlaz u HTML formatu kojeg Servlet mašina
prosleđuje Web serveru unutar HTTP odgovora. Web server zatim prosleđuje HTTP odgovor
čitaču koji dinamički generiše HTML stranu, baš kao da je u pitanju statična stranica.
Ekstenzija za JSP strane je .jsp. Strana može biti sastavljena od glavne datoteke koja uključuje
druge datoteke koje sadrže ili kompletnu JSP stranu ili delove (fragmente) JSP strane.
Preporučena ekstenzija za izvornu datoteku fragmenta JSP strane je .jspf.
Većina JSP dokumenata predstavljaju običan HTML u koji su ubačeni specijalni JSP tagovi.
Pored ovoga, JSP stranica sadrži i specijalne JSP elemente koje dozvoljavaju serveru da ubaci

41
dinamički sadržaj. Kada korisnik zatraži JSP stranicu, server izvršava JSP elemente, spajajuci
rezultat sa statičnim delovima stranice, i šalje dinamičku kompoziciju nazad do čitača. JSP
definiše standardne elemente koji su korisni za pravljenje bilo koje web aplikacije, kao što su
pristup JavaBeans komponentama, deljenje informacija između zahteva, stranica i korisnika,
prebacivanje kontrole između stranica itd. Takođe je moguće proširiti JSP sintaksu
implemetirajući specifične elemente koje rešavaju zadatke kao što su: pristup bazama
podataka, slanje e-mail-a, generisanje HTML-a za prikazivanje specifičnih podataka itd.
Jedna takva kolekcija najčešce korišćenih korisničkih elemenata je definisana preko JSP
Standard Tag Library (JSTL) specifikacije.
JSTL (JSP Standard Tag Library) sadrži:

tagove za setting/getting atribute, iteracije i sl.

tagove za pristup bazi podataka

tagove za Xml

tagove za internacionalizaciju
Kombinacija standardnih i korisničkih elemenata predstavlja odličan alat za pravljenje
moćnih web aplikacija.

6.2. JSP arhitektura

Postoje tri scenarija izvršenja JSP strane koji su prikazani na slici 29:
1. Klijent prvi put poziva JSP stranu. Klijent šalje zahtev do Web servera (1). Web
server pokreće mehanizam koji na osnovu JSP strane generiše Servlet (2.1), koga
nakon toga kompajlira (3). JSP mehanizam izvršava Servlet (4), koji vraća neki
rezultat (5). Rezultat se vraća nazad do klijenta (6).
2. Klijent zove JSP stranu za koju je već formiran Servlet. Klijent šalje zahtev do Web
servera (1). JSP mehanizam izvršava Servlet (4), koji vraća neki rezultat (5). Rezultat
se vraća nazad do klijenta (6).
3. Promenjena je JSP strana za koju je bio formiran Servlet (Servlet nije validan).
Klijent šalje zahtev do Web servera (1). Web server pokreće mehanizam koji na
osnovu JSP strane generiše novi Servlet (2.2), koga nakon toga kompajlira (3). JSP
mehanizam izvršava Servlet (4), koji vraća neki rezultat (5). Rezultat se vraća nazad
do klijenta (6).
Na osnovu navedenog može se zaključiti da se za svaku JSP stranu generiše po jedan Servlet.

42
Slika 29: Scenariji izvršenja JSP strane

6.3. Komponente JSP-a

Pravila koja se najčešće primenjuju u svim JSP tagovima su:

Tagovi imaju jedan početni tag (npr. <title>) sa artibutima koji su neobavezni,
neobavezno telo (body), i odgovarajuće krajnji tag (npr. </title>).

Vrednosti atributa u tagovima su navedeni.
JSP podseća na HTML, ali kada se prvi put pozove kompajlira se u Java servlet. Rezultujući
servlet je kombinacija HTML-a iz JSP datoteke i ugrađenog dinamičkog sadržaja
specificiranog od strane novih tagova. Sve što se nalazi na JSP strani se može podeliti u dve
kategorije. Prva se sastoji od elemenata koji se procesiraju na server. Druga se sastoji od
šablon podataka (template data) ili svega drugog izuzev elemenata koje mašina procesira JSP
mašinama.

6.4. Elementi JSP

Postoje dva tipa podataka JSP-a:

1. Statički deo (HTML, CSS i sl.) – koji se direktno kopiraju u odgovor preko JSP
mašine.

43
 2. Dinamički deo – koji sadrže sve ostalo što se prevodi i kompajlira od strane JSP
mašine.
Elementi JSP datoteke:
- direktive (direktives) – obezbeđuju osnovne informacije o strani, kao što su klase koje
se uključuju (import) u JSP stranu, kodne strane (contentType) koje će se koristiti,
informacije o jeziku koji će se koristiti u JSP strani (language=˝java˝)...
- deklaracije (declaratives) – koje se koriste za deklarisanje promenljivih i metoda u
JSP stranama.
- izrazi (expressions) – koji se formatiraju u stringove koji se uključuju u rezultat
izvršenja JSP strane.
- skripleti (scriplets) – Java programski kod koji se ugrađuje u JSP stranu.

JSP direktiva je izraz koji daje JSP mehanizmu informacije o JSP strani koja treba da se
obradi. Generalna sintaksa JSP direktiva je:
<%@ directive {attribute=˝value˝} %>
gde direktive mogu da imaju više atributa:
- page – informacije za stranu
- include – datoteke koje treba da se uključe
- taglib – biblioteku tagova koja će se koristiti u strani.
Deklaracije - deklariše se jedna ili više promenljivih i/ili metoda koje se koriste u JSP strani.
Generalna sintaksa je sledeća:
<%! declaration; [ declaration; ] ... %>
Izrazi se definišu unutar logike Java naredbi ako bi se prikazale određene vrednosti na
JSP strani. Generalna sintaksa je:
<%= expression %>
Skriplet je validan Java programski kod koji se ugrađuje u JSP stranu. Generalna sintaksa
je:
<% Java programski kod %>

U tabeli 6 dat je pregled JSP elemenata:

JSP element Sintaksa Interpretacija
JSP izraz (expression) <%= expression %> Izraz se procenjuje i smešta u izlaz

JSP skriptlet <% Java programski kod %> Kod se ubacuje u service metodu servleta

JSP strane

JSP deklaracija <%! ... %> Kod se ubacuje u telo servlet klase, van

service metode

JSP page direktiva <%@page attribute=“val“%> Definiše zavisne atribute strane kao što su

praćenje sesije

44
 JSP include direktiva <%@include file=“url“%> Uključuje se datoteka prilikom prevođenja

JSP strane u servlet

JSP komentar <%-- komentar --%> Komentar; ignoriše se prilikom prevođenja

JSP strane u servlet

jsp:include akcija <jsp:include page= “ relative url“ / > Uključuje datoteku kada se javi zahtev za

stranom

jsp:useBean akcija <jsp:useBean attribute=“val“/> Omogućava korišćenjem Java Bean-ova

jsp:setProperty akcija <jsp:setProperty attribute=“val“/> Postavlja vrednost Java Bean komponente

jsp:getProperty akcija <jsp:getProperty name=“ propertyName“ Uzima i prikazuje vrednosti iz Java Bean

value=“ val“ /> komponente

jsp:forward akcija <jsp:forward page=“ relative URL“ /> Prosleđuje zahtev drugoj strani

jsp:plugin akcija <jsp:plugin Generiše HTML koji sadrži čitač elemente

attribute=“value“>... za izvršenje apleta sa java plug-in

</jsp:plugin> softverom.

Tabela 6: JSP elementi

6.5. Životni ciklus JSP strane

Faze zivotnog ciklusa JSP-a su sledeće:

1. Faza prevođenja (Translation phase)
2. Faza kompajliranja (Compile phase)
3. Faza izvršenja (Execution phase)
Ove faze su prikazane na slici 30:

Slika 30: Životni ciklus JSP strane [17]

Faza prevođenja i kompajliranja: JSP fajlovi se prevode u servlet kod, pa se zatim
kompajliraju. Kontejner obavlja ove poslove automatski. JSP elementi se drugačije tretiraju:

Direktive se koriste da kontrolišu prevođenje i izvršenje od strane Web
kontejnera.

Scripting elementi se ubacuju u servletske klase JSP-a.

45

Elementi forme <jsp:xxx .../> se konvertuju u metode koje pozivaju
komponente JavaBeans-a.
Faza izvršenja je predstavljenja na slici 31:

Slika 31: Metode faze izvršenja [17]

6.6. Prednosti JSP-a

JSP vs. Active Server Pages (ASP)

ASP je slična tehnologija JSP razvijena od strane Microsoft-a. Prednost JSP-a je u sledećem:
dinamički delovi napisani u Javi su mnogo moćniji i lakši za korišćenje i moguće ih je
koristiti na drugim operativnim sistemima i web serverima koji nisu samo Microsoft-ov
proizvod.

JSP vs. Pure Servlets
Servleti generišu HTML preko println naredbi, dok JSP direktno koristi i modifikuje HTML.
JSP strane se sastoji iz HTML-a (kao statičkog dela) i Java koda (kao dinamičkog dela), tako
da se ova dva dela mogu nezavisno pisati i razvijati i na kraju sastaviti u jednu JSP stranu.
Ovo, pak, nije moguće sa Servletima. Na slici 32. su prikazani JSP i Servlet.

46
Slika 32: Servlet i JSP [17]
Jedan od glavnih razloga zašto je JavaServer Pages tehnologija izrasla u ono što je danas je
velika tehnička potreba za jednostavno projektovanim aplikacijama sa odvojenim dinamičkim
sadržajem od statički šablonski prikazanih podataka. Druga prednost korišćenja JSP-a je što
omogućuje jasnije odvajanje uloge web aplikacije/HTML projektanta od programera softvera.
JSP tehnologija je platformski nezavisna, u svojim dinamičkim web stranama, web serverima
i osnovnim server komponentama. JSP strane se izvršavaju bez bilo kakvih problema na bilo
kojoj platformi, pokreće se na bilo kom serveru koji podržava rad na web-u.

47
 7. JavaServer Faces tehnologija

JavaServer Faces (JSF) tehnologija je server-side okvir, zasnovan na komponentama

korisničkog interfejsa, namenjen razvoju Web aplikacija zasnovanih na Java tehnologiji.
JSF implementira patern poznat pod nazivom Model2, koji je baziran na MVC arhitekturi.
JSF arhitektura je prikazana na slici 33.

Slika 33: JSF arhitektura [17]

Aplikacija koja je razvijena korišćenjem JSF okvira su lakše za rukovanje od bilo koje druge
aplikacije razvijene u JSP-u i Servletu. Sa JSF-om možemo:
- Ubacivati komponente u stranu dodavanjem tagova komponenti.
- Vezivati događaje generisane od strane komponenti za server-side aplikacioni kod.
- Vezivati komponente korisničkog interfejsa za server-side podatke.
- Konstruisati korisnički interfejs sa komponentama koje se mogu ponovo
koristiti.

Slika 34: Korisnički interfejs se izvršava na serveru [2]

Kao što je i prikazano na slici 34, JSP strana myForm.jsp je JavaServer Faces strana, koja je u
stvari JSP strana koja uključuje JavaServer Faces tagove. Ona prikazuje komponente
korisničkog interfejsa koristeći tagove definisane JavaServer Faces tehnologijom. Korisnički
interfejs Web aplikacije (predstavljen na slici kao myUI) upravlja objektima koje referencira

48
JSP strana. Ovi objekti uključuju:
- Objekte komponenti korisničkog interfejsa koji odgovaraju tagovima na JSP strani.
- Osluškivače događaja, validatore i konvertore koji su vezani za komponente.
- JavaBeans komponente koje učauruju podatke i specifične aplikacione
funkcionalnosti komponenti.

7.1. Prednosti JSF tehnologije

Prednosti JSF-a u odnosu na druge tehnologije:

JSF definiše standard, komponente koje se mogu ponovo koristiti za kreiranje user
interface-a web aplikacije.

JSF obezbeđuje biblioteku tag-ova za proširenje i manipulaciju komponenata.

Automatski čuva formu podataka.

JSF učauruje rukovanje događajima i pravljenje logičke forme.

Uprošćava transfer aplikacionih podataka do i od UI komponenti.

Pojednostavljuje upravljanje stanjima UI.

Obezbeđuje jednostavan model za prosleđivanje događaja generisanih od strane
klijenta do server-side aplikacionog koda.

Zasniva se na Model-View-Controller arhitekturi koja obezbeđuje jasnu razdvojenost
prezentacionog od logičkog koda.
Upravo ova zadnja prednost je i najveća prednost JSF tehnologije, jer omogućava jasno
razdvajanje između ponašanja i prezentacije. Web aplikacije izgrađene JSP tehnologijom
postižu ovo razdvajanje samo delimično. Međutim, JSP aplikacija ne može da preslika HTTP
zahtev do specifičnog događaja obrade niti da upravlja elementima korisničkog interfejsa kao
stateful objektima (objekti koji čuvaju stanje) na serveru, kao što JavaServer Faces aplikacija
može. Razdvajanje logike od prezentacije takođe dozvoljava svakom članu razvojnog tima
Web aplikacije da se fokusira na svoj deo razvojnog procesa i obezbeđuje jednostavan
programerski model za povezivanje delova. Još jedno važno dostignuće JavaServer Faces
tehnologije je snaga poznatih komponenti korisničkog interfejsa i koncepata Web nivoa bez
ograničenja pojedinih skripting jezika ili markup jezika. Iako JavaServer Faces tehnologija
uključuje JSP custom tag bibioteku za predstavljanje komponenti na JSP strani, API
JavaServer Faces tehnologije je naslonjen direktno na Servlet API. Ovo slaganje API-ja
omogućava nekoliko važnih slučajeva iz prakse, kao što su korišćenje druge prezentacione
tehnologije umesto JSP strana, kreiranje sopstvenih komponenti direktno iz component klasa i
generisanje izlaza za razne klijente. Kao najvažnije, JavaServer Faces tehnologija obezbeđuje
bogatu arhitekturu za upravljanje stanjem komponenti, procesiranje podataka komponenti,
validaciju ulaznih podataka i obradu događaja.
Glavni cilj JSF-a je kreiranje web aplikacija što brže i jednostavnije. Projektanti se mogu

49
fokusirati na UI komponente, rukovanje događajima, pozadinske bean-ove i njihove
interakcije, pre nego na zahtev, odgovor i markup. JSF sakriva složenost i omogućava
projektantima da se skoncentrišu na njihove specifične poslove.

7.2. JSF aplikacija

JavaServer Faces aplikacija je slična bilo kojoj drugoj Java Web aplikaciji i uglavnom
ukljucuje:
o Kolekciju (set) API-ja za reprezentaciju i manipulaciju komponenti koja pomaže
pri server-side validaciji, rukovanju događajima, navigaciju između strana,
konverziju podataka i slično.
o Standardnu biblioteku tag-ova za kreiranje UI komponenti.
Tipična JavaServer Faces aplikacija sadrži sledeće delove koji su prikazani na slici 35:
- Skup JSP strana,
- Skup bean-ova za podršku, koji su JavaBeans komponente koje definišu osobine i
funkcije komponenti korisničkog interfejsa na Web strani,
- Aplikacionu konfiguracionu datoteku (application configuration resource file), koja
definiše pravila navigacije i konfiguriše bean-ove i druge custom objekte, kao što su
custom komponente,
- Opisivač rasporeda (web.xml datoteka),
- Moguće i skup objekata kreiranih od strane programera aplikacije. Ovi objekti mogu
uključivati custom komponente, validatore, konvertore ili osluškivače,
- Skup custom tagova za predstavljanje custom objekata na strani.

Slika 35: Primer izgleda i strukture JSF aplikacije [3]

50
Primer:
input_accountNumber.jsp

<%@ taglib uri="http://java.sun.com.jsf/html" prefix="h" %>

<%@ taglib uri="http://java.sun.com.jsf/core" prefix="f" %>

<f:loadBundle basename="messages" var="msg"/>

<html>
...
<body>

<f:view>
<h:form id="accountForm">
<h:outputText value="#{msg.account_number}" />
<h:inputText value="#{accountBean.accountNumber}" />
<h:commandButton action="getAccount" value="#{msg.account_button}" />
</h:form>
</f:view>
</body>
</html>

faces-config.xml
...

<faces-config>
<navigation-rule>
<form-view-id>/jsps/input_accountNumber.jsp</form-view-id>
<navigation-case>
<from-outcome>getAccount</from-outcome>
<to-view-id>/jsps/output_accountNumber.jsp</to-view-id>

</navigation-case>
</navigation-rule>
...
<managed-bean>
<managed-bean-name>accountBean</managed-bean-name>
<managed-bean-class>AccountBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
</faces-config>

51
7.3. Model komponenti korisničkog interfejsa

Komponente JSF-a imaju mogućnost ponovnog korišćenja i mogu biti jednostavne (npr.
dugme, text box) ili složene (tabela). JSF tehnologija obezbeđuje bogatu, fleksibilnu
arhitekturu komponenti koja obuhtata sledeće elemente:
• Skup UIComponent klasa kojima se opisuju stanje i ponašanje komponenti
korisničkog interfejsa.
• Model prikazivanja komponenti (rendering model) koji definiše kako na različite
načine prikazati komponente.
• Model događaja i slušaoca (event and listener model) koji definiše kako upravljati
događajima komponenti.
• Konverzioni model (conversion model) koji definiše kako da se registruju konverteri
podataka na komponentu.
• Validacioni model (validation model) koji definiše kako registrovati validatore na
komponentu.

7.4. Životni ciklus JSF strane

JSF stranica je predstavljena preko stabla UI komponenti, nazvanih pogled (view). Kada
klijent prosledi stranu, JavaServer Faces implementacija obavlja nekoliko poslova, kao što su
validacija ulaznih podataka komponenti view-a i konverzija ulaznih podataka u tipove
specificirane na serverskoj strani.
Faze zivotnog ciklusa JSF su predstavljene na slici 36:
1. Faza formiranja stabla (Restore view)
2. Faza dodele vrednosti (Apply request values)
3. Faza validacije (Process validations)
4. Faza ažuriranja vrednosti (Update model values)
5. Faza poziva aplikacije (Invoke application)
6. Faza prikaza odgovora (Render response)

Životni ciklus obrađuje dve vrste zahteva:

- Inicijalne zahteve (initial requests)
- Ponovne zahteve (postbacks).

52
Slika 36: Životni ciklus JSF-a [14]

Kada korisnik traži stranu po prvi put, tada on pravi inicijalni zahtev. U slučaju ponovnog
traženja, forma je sadržana u strani. Kod inicijalnog zahteva samo se izvršavaju faze
formiranja view-a i prikaza odgovora, jer ne postoje ulazni podaci ili akcije koje treba
procesirati, dok se kod obrade ponovnog zahteva izvršavaju sve faze. Najčešce prvi zahtev za
JSF stranom stiže kao rezultat kliktanja na hyperlink HTML strane koji je povezan sa JSF
stranom. Kao rezultat klika, formira se novi view koji se čuva u FacesContext pojavljivanju,
koje predstavlja sve kontekstualne informacije povezane sa procesiranjem pristižućeg zahteva
i kreiranjem odgovora. Aplikacija zatim zahteva reference objekata potrebne view-u i poziva
FacesContext.renderResponse(), koji trenutno pokreće prikazivanje view-a prelaskom na
Render Response (poslednju) fazu životnog ciklusa. U slucaju da aplikacija mora da se
preusmeri na neki drugi resurs Web aplikacije, kao što je Web servis, ili da generiše odgovor
koji ne sadrži JavaServer Faces komponente, tada ona preskace Render Response fazu
pozivanjem FacesContext.responseComplete(). U slucaju da JSF komponenta podnese zahtev
za drugom JSF stranom, tada JSF implementacija obrađuje zahtev i automatski prolazi kroz
faze životnog ciklusa kako bi obavila neophodne konverzije, validacije, ažuriranja modela i
generisala odgovor.

Faza formiranja view-a (Restore View Phase)

Kada je zahtev za JSF stranom napravljen, JavaServer Faces implementacija započinje fazu
formiranja stabla. Tokom ove faze, JavaServer Faces implementacija formira stablo strane,
vezuje obrađivače događaja i validatore za komponente u stablu, i čuva stablo u FacesContext

53
pojavljivanju, koja sadrži sve informacije potrebne za obradu jednog zahteva. Svi tagovi
komponenti, obrađivači događaja, konverteri, i validatori, imaju pristup FacesContext
instanci. Ako je zahtev za stranom inicijalni zahtev, JavaServer Faces implementacija tokom
ove faze kreira prazno stablo, i životni ciklus prelazi na fazu prikazivanja odgovora, tokom
koje se prazno stablo popunjava komponentama koje se odnose na tagove na strani. Ako je
zahtev za stranom ponovni zahtev, stablo koje se odnosi na tu stranu već postoji. Tokom ove
faze, JavaServer Faces implementacija rekonstruiše stablo, koristeći informacije sačuvane na
klijentu ili serveru.

Faza dodele vrednosti (Apply RequestValues Phase)

U ovoj fazi svaka komponenta uzima svoju novu vrednost iz parametara zahteva, pomoću
svoje decode() metode. Ukoliko je konverzija vrednosti neuspešna, generiše se poruka o
grešci vezanoj za komponentu, i dodaje se u FacesContext. Ova poruka će biti prikazana
tokom faze prikaza odgovora, zajedno sa greškama validacije nastalih u fazi validacije. Ako
neka decode() metoda ili osluškivač događaja pozove renderResponse() metodu FacesContext
pojavljivanja, JavaServlet Faces implementacija prelazi na fazu prikazivanja odgovora.
Ukoliko aplikacija ima potrebu da u ovoj fazi generiše odgovor koji ne sadrži JSF
komponente, može pozvati metodu FacesContext.responseComplete().

Faza validacije (Process Validations Phase)

U ovoj fazi se procesiraju svi validatori koji su vezani za komponente u stablu. Ispituju se
atributi komponenti koji definišu pravila validacije, i porede se ova pravila sa lokalnim
vrednostima komponenata. Ako neka od validate metoda ili osluškivač događaja pozove
renderResponse() metodu FacesContext pojavljivanja, JavaServer Faces implementacija
prelazi na fazu prikazivanja odgovora. Ukoliko aplikacija treba da generiše odgovor koji ne
sadrži JSF komponente, može da pozove FacesContext.responseComplete() metodu.

Faza ažuriranja vrednosti (Update Model Values Phase)

Ukoliko su podaci validni, JavaServer Faces implementacija prolazi kroz stablo komponenti i
postavlja atribute odgovarajućih objekata na serverskoj strani na lokalne vrednosti
komponenti. JavaServer Faces implementacija će ažurirati samo one bean atribute na koje
ukazuju atributi ulaznih vrednosti komponente. Ako lokalni podaci ne mogu da se konvertuju
u tip koji je određen bean atributom, životni ciklus prelazi na fazu prikaza odgovora, tako da
se strana prikaže sa porukom o grešci. Ukoliko aplikacija treba da generiše odgovor koji ne
sadrži JSF komponente, može da pozove FacesContext.responseComplete metodu.

Faza poziva aplikacije (Invoke Application Phase)

U ovoj fazi životnog ciklusa JavaServer Faces implementacija upravlja događajima, kao što

54
su podnošenje forme ili povezivanje sa drugom stranom. Ukoliko aplikacija treba da generiše
odgovor koji ne sadrži JSF komponente, može da pozove FacesContext.responseComplete()
metodu.

Faza prikaza odgovora (Render Response Phase)

U poslednjih fazi, JavaServer Faces implementacija delegira ovlašćenje za prikazivanje strane
JSP kontejneru, ako aplikacija koristi JSP strane. Ukoliko je u pitanju inicijalan zahtev,
komponente koje su prikazane na strani će biti dodate stablu komponenti kada JSP kontejner
izvrši stranu. Ako nije inicijalan zahtev, komponente su već dodate stablu, tako da ne treba da
se ponovo dodaju. Ukoliko je u pitanju ponovni zahtev i ako su se javile greške tokom jedne
od faza (dodele vrednosti, validacije ili ažuriranja vrednosti), prikazaće se originalna strana.
Nakon što je sadržaj stabla prikazan, stanje odgovora ostaje sačuvano.

55
 8. Studijski primer razvoja softverskog sistema

8.1. Specifikacije zahteva i slučajevi korišćenja

Zahtevi predstavljaju svojstva i uslove koje sistem mora da zadovolji. Zahtevi se kod
Larmana opisuju pomoću UML Modela slučajeva korišćenja (USE – CASE Model). Takav
model se sastoji od skupa SK (slučajeva korišćenja), aktora (spoljnih korisnika sistema) i veza
izmedju SK i aktora.
Slučaj korišćenja opisuje skup scenarija (USE-CASE pojavljivanja), tj.skup željenih
korišćenja sistema od strane aktora. Stoga možemo reći da je scenario opisan preko:
- sekvence akcija
- interakcija aktor – sistem
Slučaj korišćenja (SK) se sastoji od glavnog i alternativnih scenarija. Specifikacija korisničkih
zahteva podrazumeva opis potreba ili želja koje softverski proizvod treba da omogući. Zahtev
korisnika predstavlja opis potreba ili želja za nekim proizvodom.
Neophodno je identifikovati i dokumentovati potrebe radi lakše komunikacije klijenta sa
timom za razvoj softverskog proizvoda. Slučajevi korišćenja se u početnim fazama razvoja
softvera predstavljaju tekstualno, da bi kasnije oni bili prikazani uz pomoć sekvencijalnih
dijagrama, dijagrama saradnje, dijagrama prelaza stanja ili dijagrama aktivnosti.

Opis problema

Verbalni opis:
Potrebno je realizovati softver koji će pratiti rad sa pacijentima stomatološke ordinacije
(ubacivanje novog, promena postojeceg pacijenta), beleženje detalja njihovih poseta,
formiranje cenovnika usluga.
Korisnik: Ovaj sistem je namenjen vlasniku, koji je ujedno i lekar u stomatološkoj ordinaciji.
Ciljevi: Cilj je da se vrši što efikasnije praćenje poslovanja stomatološke ordinacije, efikasno
beleženje novih poseta pacijenata, pregled postojećih pacijenata sa njihovim posetama,
izmenu cenovnika usluga ordinacije.

Specifikacija zahteva pomoću modela sučajeva korišćenja

U mom primeru postoje sledeći slučajevi korišćenja koji su prikazani na dijagramu 1:

1. Ubacivanje novog pacijenta
2. Izmena podataka o pacijentu
3. Brisanje pacijenta iz baze podataka
4. Ubacivanje nove posete pacijenta

56
5. Izmena posete pacijenta
6. Pregled svih poseta pacijenta
7. Izmena cenovnika usluga
8. Pregled šifara bolesti zuba
9. Ubacivanje nove šifre bolesti zuba

Navedene slučajeve korišćenja koristi stomatolog (aktor), što se može predstaviti preko
sledećih dijagrama SK:

Dijagram 1: Model slučajeva korišćenja

SK1:Slučaj korišćenja – Ubacivanje novog pacijenta

Naziv SK
Ubacivanje novog pacijenta

Aktori SK
Stomatolog u stomatološkoj ordinaciji(u daljem tesktu korisnik)

Učesnici SK
Korisnik i program(u daljem tekstu sistem)

Preduslov: Sistem je uključen. Sistem prikazuje početnu formu.

57
Osnovni scenario SK

1. Korisnik poziva sistem da vrati šifru novog pacijenta(APSO)

2. Sistem nalazi šifru novog pacijenta(SO)
3. Sistem prikazuje šifru novog pacijenta(IA)
4. Korisnik unosi podatke o novom pacijentu(APUSO)
5. Korisnik kontroliše unete podatke (ANSO)
6. Korisnik poziva sistem da zapamti novog pacijenta (APSO)
7. Sistem pamti novog pacijetna (SO)
8. Sistem pokazuje korisniku poruku o uspešnom pamćenju pacijenta (IA)

Alternativna scenarija
3.1. Ukoliko sistem ne moze da dodeli šifru novom pacijentu, prikazuje se poruka(IA).
Prekida se izvršenje scenarija.
8.1. Ukoliko sistem ne moze da zapamti novog pacijenta, prikazuje se poruka(IA).
Prekida se izvršenje scenarija.

SK2:Slučaj korišćenja – Izmena podataka o pacijentu

Naziv SK
Izmena podataka o pacijentu

Aktori SK
Korisnik

Učesnici SK
Korisnik i sistem

Preduslov: Sistem je uključen i prikazuje formu za prikaz podataka o pacijentu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)
5. Sistem traži pacijenta sa datim imenom i prezimenom (SO)
6. Sistem prikazuje podatke o traženom pacijentu (IA)

58
 7. Korisnik menja podatke o odabranom pacijentu(APUSO)
8. Korisnik poziva sistem da zapamti načinjene izmene(APSO)
9. Sistem pamti izmene pacijenta(SO)
10. Sistem prikazuje poruku da je pacijent uspešno izmenjen(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako iz nekog razloga pacijent čiji se podaci menjaju ne postoji više u bazi
podataka, prikazuje se poruka korisniku o tome(IA). Prekida se izvršenje scenarija.
10.1. Ako sistem ne može da zapamti novonastale promene nad podacima, sistem
prikazuje poruku klijentu da nije uspelo pamćenje novih podataka(IA). Prekida se izvršenje
scenarija.

SK3:Slučaj korišćenja – Brisanje pacijenta iz baze podataka

Naziv SK
Brisanje pacijenta iz baze podataka

Aktori SK
Korisnik

Učesnici SK
korisnik i sistem

Preduslov: Sistem je uključen i prikazuje formu za prikaz podataka o pacijentu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)
5. Sistem traži pacijenta sa datim imenom i prezimenom (SO)
6. Sistem prikazuje podatke o traženom pacijentu (IA)
7. Korisnik poziva sistem da izbriše odabranog pacijenta iz baze(APSO)
8. Sistem briše pacijenta iz baze(SO)
9. Sistem prikazuje poruku da je pacijent izbrisan iz baze(IA)

59
Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako iz nekog razloga pacijent ciji se podaci menjaju ne postoji više u bazi
podataka, prikazuje se poruka korisniku o tome(IA). Prekida se izvršenje scenarija.
9.1. Ako sistem ne može da izbriše pacijenta, sistem prikazuje poruku klijentu da nije
uspelo brisanje pacijenta (IA). Prekida se izvršenje scenarija.

SK4:Slučaj korišćenja – Ubacivanje nove posete pacijenta

Naziv SK
Snimanje nove posete pacijenta

Aktori SK
Korisnik

Učesnici SK
korisnik i sistem

Preduslov: Sistem je uključen i prikazuje početnu formu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)
5. Korisnik unosi detalje o poseti(APUSO)
6. Korisnik poziva sistem da zapamti novu posetu(APSO)
7. Sistem pamti novu posetu pacijenta(SO)
8. Sistem prikazuje poruku o uspešnom pamćenju posete(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
8.1. Ukoliko sistem nije sposoban da zapamti novu posetu pacijenta, prikazuje se
odg.poruka(IA). Prekida se izvršenje scenarija.

60
SK5:Slučaj korišćenja – Izmena posete pacijenta

Naziv SK
Izmena posete pacijenta

Aktori SK
Korisnik

Učesnici SK
korisnik i sistem

Preduslov: Sistem je uključen i prikazuje početnu formu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta i poziva sistem da
prikaže datume poseta odabranog pacijenta(APSO)
5. Sistem traži sve posete odabranog pacijenta(SO)
6. Sistem prikazuje posete odabranog pacijenta(IA)
7. Korisnik bira posetu koju želi da vidi na formi(APUSO)
8. Korsnik poziva sistem da prikaze detalje odabrane posete(APSO)
9. Sistem nalazi željenu posetu(SO)
10. Sistem prikazuje posetu(IA)
11. Korisnik menja detalje odabrane posete pacijenta(APUSO)
12. Korisnik poziva sistem da zapamti izmene posete(APSO)
13. Sistem pamti izmenjenu posetu(SO)
14. Sistem prikazuje poruku da je uspešno izmenjena poseta(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako sistem nije sposoban da prikaže sve posete odabranog pacijenta, prikazuje se
odg.poruka(IA) . Prekida se izvršenje scenarija.
10.1. Ako sistem nije sposoban da prikaže odabranu posetu pacijenta, prikazuje se
odg.poruka (IA). Prekida se izvršenje scenarija.

61
 14.1. Ako sistem nije sposoban da zapamti izmene posete, prikazuje se odg. poruka
(IA). Prekida se izvršenje scenarija.

SK6: Slučaj korišćenja – Pregled svih poseta pacijenta

Naziv SK
Pregled svih poseta pacijenta

Aktori SK
Korisnik

Učesnici SK
korisnik i sistem

Preduslov: Sistem je uključen i prikazuje osnovnu formu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta i poziva sistem
da prikaže sve posete odabranog pacijenta(APSO)
5. Sistem traži sve posete odabranog pacijenta(SO)
6. Sistem prikazuje sve posete odabranog pacijenta(IA)

Alternativna scenarija:
3.1 Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1 Ako sistem nije sposoban da prikaze sve posete odabranog pacijenta, prikazuje se
odg.poruka(IA) . Prekida se izvršenje scenarija.

SK7:Slučaj korišćenja – Izmena cenovnika usluga

Naziv SK
Izmena cenovnika usluga

62
Aktori SK
Korisnik

Učesnici SK
korisnik i sistem

Preduslov: Sistem je uključen i prikazuje početnu formu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve vrste usluga iz baze podataka(APSO)

2. Sistem nalazi sve vrste usluga u bazi podataka(SO)
3. Sistem prikazuje sve vrste usluga iz baze podataka(IA)
4. Korisnik iz liste sa svim vrstama usluga na formi bira neku vrstu usluge i poziva
sistem da prikaže cenu i datum početka važenja cene usluge(APSO)
5. Sistem traži poslednju cenu i datum usluge(SO)
6. Sistem prikazuje detalje usluge(IA)
7. Korisnik menja detalje konkretne usuge(APUSO)
8. Korisnik poziva sistem da zapamti izmene usluge(APSO)
9. Sistem pamti izmene detalja vezanih za uslugu(SO)
10. Sistem prikazuje poruku o uspešnoj izmeni detalja usluge(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve vrste usluga iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako sistem nije u stanju da prikaže detalje o ceni i datumu poslednje izmene cene
konkretne usluge, prikazuje odg. poruku(IA). Prekida se izvršenje scenarija.
10.1. Ako sistem nije u stanju da prikaže poruku o uspešnoj izmeni detalja usluge,
prikazuje odg. poruku(IA). Prekida se izvršenje scenarija.

SK8:Slučaj korišćenja – Pregled šifara bolesti zuba

Naziv SK
Pregled šifara bolesti zuba

Aktori SK
Korisnik

63
Učesnici SK
korisnik i sistem

Preduslov: Sistem je uključen i prikazuje osnovnu formu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati listu sa šiframa bolesti(APSO)

2. Sistem kreira listu sa šiframa bolesti(SO)
3. Sistem prikazuje listu sa šiframa bolesti(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da prikaze listu sa šiframa svih bolesti , prikazuje tu
poruku(IA). Prekida se izvršenje scenarija.

SK9:Slučaj korišćenja – Ubacivanje nove šifre bolesti zuba

Naziv SK
Ubacivanje nove šifre bolesti zuba

Aktori SK
Korisnik

Učesnici SK
korisnik i sistem

Preduslov: Sistem je uključen i prikazuje formu za pregled šifara bolesti

Osnovni scenario SK

1. Korisnik unosi detalje o novoj šifri bolesti(APUSO)

2. Korisnik kontroliše da li je pravilno uneo sve neophodne podatke(ANSO)
3. Korsnik poziva sistem da kreira novu šifru bolesti(APSO)
4. Sistem pamti novu šifru bolesti(SO)
5. Sistem prikazuje poruku da je uspešno zapamtio novu šifru bolesti(IA)

64
Alternativna scenarija:
5.1. Ako sistem nije u stanju da zapamti novu šifru bolesti , prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.

8.2. Analiza

Nakon faze prikupljanja zahteva, prelazi se na sledeću fazu, fazu analize. Ova faza opisuje
logičku strukturu i ponašanje sofvterskog sistema, tj. poslovnu logiku softverskog sistema.
Pomenuli smo da softverski sistem ima svoje ponašanje i strukturu.
Ponašanje opisujemo pomoću:
- sistemskih dijagrama sekvenci, prave se za svaki prethodno utvrdjen SK
- ugovora o sistemskim operacijama, koje dobijaju na osnovu sistemskih dijagrama
sekvenci.

Strukturu opisujemo pomoću:

- konceptualnog modela
- relacionog modela

Za svaki SK, odnosno za svaki scenario SK, prave se sistemski dijagrami i to samo za APSO
(Aktor Poziva sistem da izvrši Sistemsku Operaciju) i IA (Izlazni argument).

DS1: Dijagrami sekvenci slučaja korišćenja - Ubacivanje novog pacijenta

Osnovni scenario SK

1. Korisnik poziva sistem da vrati šifru novog pacijenta(APSO)

2. Sistem prikazuje šifru novog pacijenta(IA)
3. Korisnik poziva sistem da zapamti novog pacijenta (APSO)
4. Sistem pokazuje korisniku poruku o uspešnom pamćenju pacijenta (IA)

Aktor Sistem

vratiBRPoslednjegPacijenta(pac);

SifraNovogPacijenta
snimiNovogPacijenta(pac);

Poruka o uspesnom snimanju(IA)

65
Alternativna scenarija:
2.1. Ukoliko sistem ne može da prikaze šifru novog pacijenta, prikazuje se odgovarajuca
poruka(IA). Prekida se izvršenje scenarija.

4.1. Ako sistem nije u stanju da zapamti novog pacijenta, poruka se prikazuje(IA) . Prekida
se izvršenje scenarija.

DS2: Dijagrami sekvenci slučaja korišćenja – Izmena podataka o pacijentu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem prikazuje sve pacijente iz baze podataka(IA)
3. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)
4. Sistem prikazuje podatke o traženom pacijentu (IA)
5. Korisnik poziva sistem da zapamti načinjene izmene(APSO)
6. Sistem prikazuje poruku da je pacijent uspešno izmenjen(IA)

66
Alternativna scenarija:
2.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.

Aktor Sistem

vratiSvePacijente(pac, listaPacijenata);

Poruka o nesuspesnom vracanju liste pacijenata(IA)

4.1. Ako iz nekog razloga pacijent ciji se podaci menjaju ne postoji više u bazi
podataka, prikazuje se poruka korisniku o tome(IA) Prekida se izvršenje scenarija.

6.1. Ako sistem ne može da zapamti novonastale promene nad podacima, sistem
prikazuje poruku klijentu da nije uspelo pamćenje novih podataka(IA). Prekida se izvršenje
scenarija.

67
DS3: Dijagrami sekvenci slučaja korišćenja - Brisanje pacijenta iz baze podataka

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem prikazuje sve pacijente iz baze podataka(IA)
3. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)
4. Sistem prikazuje podatke o traženom pacijentu (IA)
5. Korisnik poziva sistem da izbriše odabranog pacijenta iz baze(APSO)
6. Sistem prikazuje poruku da je pacijent izbrisan iz baze(IA)

Alternativna scenarija:
2.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.

68
 4.1. Ako iz nekog razloga pacijent ciji se podaci menjaju ne postoji vise u bazi
podataka, prikazuje se poruka korisniku o tome(IA) Prekida se izvršenje scenarija.

6.1. Ako sistem ne može da izbriše pacijenta, sistem prikazuje poruku klijentu da nije
uspelo brisanje pacijenta (IA). Prekida se izvršenje scenarija.
Aktor Sistem
vratiSvePacijente(pac, listaPacijenata);

listaPacijenata

vratiPodatkeOIzabranomPacijentu(p);

podaciOIzabranomPacijentu(IA)

IzbrisiPacijenta(p);

Poruka da brisanje nije uspelo(IA)

DS4: Dijagrami sekvenci slučaja korišćenja - Ubacivanje nove posete pacijenta

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem prikazuje sve pacijente iz baze podataka(IA)
3. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)

69
 4. Korisnik poziva sistem da zapamti novu posetu(APSO)
5. Sistem prikazuje poruku o uspešnom pamcenju posete(IA)

Alternativna scenarija:
2.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
Aktor Sistem

vratiSvePacijente(pac, listaPacijenata);

poruka da lista sa pacijentima nije uspesno vracena(IA)

5.1. Ukoliko sistem nije sposoban da zapamti novu posetu pacijenta, prikazuje se
odg.poruka(IA). Prekida se izvršenje scenarija.

DS5: Dijagrami sekvenci slučaja korišćenja – Izmena posete pacijenta

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem prikazuje sve pacijente iz baze podataka(IA)
3. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta i poziva sistem
da prikaze datume poseta odabranog pacijenta(APSO)
4. Sistem prikazuje posete odabranog pacijenta(IA)

70
 5. Korsnik poziva sistem da prikaže detalje odabrane posete(APSO)
6. Sistem prikazuje posetu(IA)
7. Korisnik poziva sistem da zapamti izmene posete(APSO)
8. Sistem prikazuje poruku da je uspešno izmenjena poseta(IA)

Alternativna scenarija:
2.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.

4.1. Ako sistem nije sposoban da prikaze sve posete odabranog pacijenta, prikazuje se
odg.poruka(IA) . Prekida se izvršenje scenarija.

6.1. Ako sistem nije sposoban da prikaže odabranu posetu pacijenta, prikazuje se
odg.poruka (IA). Prekida se izvršenje scenarija.

71
 8.1. Ako sistem nije sposoban da zapamti izmene posete, prikazuje se odg. poruka
(IA). Prekida se izvršenje scenarija.

DS6: Dijagrami sekvenci slučaja korišćenja – Pregled svih posete pacijenta

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem prikazuje sve pacijente iz baze podataka(IA)
3. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta i poziva sistem
da prikaže sve poseta odabranog pacijenta(APSO)
4. Sistem prikazuje sve posete odabranog pacijenta(IA)

72
Alternativna scenarija:
2.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.

4.1. Ako sistem nije sposoban da prikaze sve posete odabranog pacijenta, prikazuje se
odg.poruka(IA) . Prekida se izvršenje scenarija.

DS7: Dijagrami sekvenci slučaja korišćenja - Izmena cenovnika usluga

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve vrste usluga iz baze podataka(APSO)

2. Sistem prikazuje sve vrste usluga iz baze podataka(IA)
3. Korisnik iz liste sa svim vrstama usluga na formi bira neku vrstu usluge i poziva
sistem da prikaže cenu i datum pocetka vazenja cene usluge(APSO)

73
 4. Sistem prikazuje detalje usluge(IA)
5. Korisnik poziva sistem da zapamti izmene usluge(APSO)
6. Sistem prikazuje poruku o uspešnoj izmeni detalja usluge(IA)

Alternativna scenarija:
2.1. Ako sistem nije u stanju da vrati sve vrste usluga iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.

4.1. Ako sistem nije u stanju da prikaze detalje o ceni i datumu poslednje izmene cene
konkretne usluge, prikazuje odg. poruku(IA). Prekida se izvršenje scenarija.

6.1. Ako sistem nije u stanju da zapamti izmenjene detalje o ceni i datumu konkretne
usluge, prikazuje odg. poruku(IA). Prekida se izvršenje scenarija.

74
 Aktor Sistem

vratiVrsteUsluga(tu, listaVrstaUsluga);

listaVrstaUsluga

vratiPoslednjuCenuUsluge(cu);

poslednja cena usluge(IA)

snimiNovuCenuUsluge(cu);

poruka o neuspesnom snimanju nove cene usluge(IA)

DS8: Dijagrami sekvenci slučaja korišćenja - Pregled šifara bolesti

Osnovni scenario SK

1. Korisnik poziva sistem da vrati listu sa šiframa bolesti(APSO)

2. Sistem kreira listu sa šiframa bolesti(SO)
3. Sistem prikazuje listu sa šiframa bolesti(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da prikaze listu sa šiframa svih bolesti , prikazuje tu
poruku(IA). Prekida se izvršenje scenarija.

DS9: Dijagrami sekvenci slučaja korišćenja - Ubacivanje nove šifre bolesti

Osnovni scenario SK

1. Korsnik poziva sistem da kreira novu šifru bolesti(APSO)

2. Sistem prikazuje poruku da je uspešno zapamtio novu šifru bolesti(IA)

75
Alternativna scenarija:
2.1. Ako sistem nije u stanju da zapamti novu šifru bolesti , prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.

Ponašanje softerskog sistema – Definisanje ugovora o sistemskim

operacijama

UGOVOR UG1 vratiBRPoslednjegPacijenta

Operacija: vratiBrPoslednjegPacijenta(Pacijent pac) : signal
Veza sa SK: SK Ubacivanje novog pacijenta
Preduslovi:
Postuslovi: dodeljen je redni broj novom pacijentu

UGOVOR UG2 snimiNovogPacijenta

Operacija: snimiNovogPacijenta(Pacijent pac): signal
Veza sa SK: SK Ubacivanje novog pacijenta
Preduslovi: u bazi ne postoji pacijent sa novim rednim brojem pacijenta
Postuslovi: snimljen je novi pacijent u bazu podataka

UGOVOR UG3 prikaziPodatkeOIzabranomPacijentu

Operacija: prikaziPodatkeOIzabranomPacijentu(Pacijent pac): signal
Veza sa SK: SK Izmena podataka o pacijentu, Brisanje pacijenta iz baze podataka,
Ubacivanje nove posete pacijenta,Izmena posete pacijenta
Preduslovi: pacijent postoji u bazi podataka
Postuslovi: procitani su podaci o odabranom pacijentu, iz baze podataka

UGOVOR UG4 izbrisiPacijentaIzBaze

Operacija: izbrisiPacijentaIzBaze(Pacijent pac): signal

76
Veza sa SK: SK Brisanje pacijenta iz baze
Preduslovi: u bazi postoji traženi pacijent
Postuslovi: izbrisan je pacijent iz baze podataka

UGOVOR UG5 izmeniPodatkeOIzabranomPacijentu

Operacija: izmeniPodatkeOIzabranomPacijentu(Pacijent pac): signal
Veza sa SK: SK Izmena podataka o pacijentu
Preduslovi: u bazi postoji pacijent ciji se podaci menjaju
Postuslovi: izmenjen je pacijent u bazi podataka

UGOVOR UG6 snimiNovuDijagnostiku

Operacija: snimiNovuDijagnostiku(Dijagnostika dij) : signal
Veza sa SK: SK Ubacivanje nove posete pacijenta
Preduslovi: u bazi postoji pacijent čija se poseta belezi
Postuslovi: kreirana je nova poseta pacijenta

UGOVOR UG7 vratiSvePoseteIzabranogPacijenta

Operacija:vratiSvePoseteIzabranogPacijenta(Dijagnostika dij, ArrayList listaDatuma): signal
Veza sa SK: Izmena posete pacijenta
Preduslovi: u bazi postoji pacijent čija se posete traze
Postuslovi: iz baze su pročitane sve posete koje se odnose na traženog pacijenta

UGOVOR UG8 vratiPodatkeOIzabranojPoseti

Operacija: vratiPodatkeOIzabranojPoseti(Dijagnostika dij) : signal
Veza sa SK: Izmena posete pacijenta
Preduslovi: u bazi postoji pacijent čija se posete traze
Postuslovi: iz baze je pročitana poseta koja se odnosi na traženog pacijenta

UGOVOR UG9 izmeniPodatkeOIzabranojPoseti

Operacija : izmeniPodatkeOIzabranojPoseti(Dijagnostika dij) : signal
Veza sa SK: Izmena posete pacijenta
Preduslovi: u bazi postoji pacijent čija se poseta menja i postoji registrovana poseta čiji se
detalji žele menjati
Postuslovi: promenjena je tražena poseta odabranog pacijenta

UGOVOR UG10 vratiSveSifreBolestiIzBaze

Operacija : vratiSveSifreBolestiIzBaze(Sifrarnik sif, ArrayList listaSvihSifaraBolesti)
: signal

77
Veza sa SK: Pregled šifara bolesti zuba
Preduslovi:
Postuslovi: kreirana je lista šifara bolesti

UGOVOR UG11 snimiNovuSifruBolesti

Operacija : snimiNovuSifruBolesti(Sifrarnik sif) : signal
Veza sa SK: Ubacivanje nove šifre bolesti zuba
Preduslovi: Šifra bolesti ne postoji u bazi podataka
Postuslovi: kreirana je nova šifra bolesti

UGOVOR UG12 vratiVrsteUsluga

Operacija : vratiVrsteUsluga(Tip_usluge tu, ArrayList listaVrstaUsluga) : signal
Veza sa SK: Izmena detalja postojeće usluge
Preduslovi:
Postuslovi: vraćena je lista sa svim vrstama usluga

UGOVOR UG13 vratiPoslednjuCenuUsluge

Operacija : vratiPoslednjuCenuUsluge(Cena_usluge cu) : signal
Veza sa SK: Izmena detalja postojeće usluge
Preduslovi:
Postuslovi: vraćeni su detalji o poslednjoj izmeni tražene usluge

UGOVOR UG14 snimiNovuCenuUsluge

Operacija : snimiNovuCenuUsluge(Cena_usluge cu) : signal
Veza sa SK: Izmena detalja postojeće usluge
Preduslovi:
Postuslovi: snimljene su izmene detalja tražene usluge

UGOVOR UG15 vratiSvePacijente

Operacija : vratiSvePacijente(Pacijent pac, ArrayList listaPac) : signal
Veza sa SK: Izmena podataka o pacijentu, Brisanje pacijenta iz baze podataka, Ubacivanje
nove posete pacijenta, Izmena posete pacijenta
Preduslovi:
Postuslovi: vraćena je lista sa svim pacijentima koji se nalaze u bazi podataka

UGOVOR UG16 vratiPoseteSvihIzBaze

Operacija : vratiPoseteSvihIzBaze (Dijagnostika dij, ArrayList listaDij) : signal
Veza sa SK: Pregled svih poseta pacijenta

78
Preduslovi:
Postuslovi: vraćena je lista sa svim pacijentima koji se nalaze u bazi podataka

Struktura softverskog sistema – Konceptualni (domenski) model

Slika 37: Konceptualni model softverskog sistema

Kao rezultat analize scenarija slučajeva koriscenja, dobija se logicka struktura i ponašanje
softverskog sistema:

Dijagram 2: Poslovna logika sistema : struktura (domenske klase) i ponašanje sistema (klase
ponašanja)

79
8.2.3 Struktura softerskog sistema – Relacioni model

Na osnovu konceptualnog, može se napraviti relacioni model, koji ce da predstavlja

osnovu za projektovanje relacione baze podataka.

cena_usluge
Field Type Null Key Extra
RBCen int(5) NO PRI auto_increment
DatumCenovnika date NO
Cena int(5) YES
TipUsluge int(2) NO
unsigned
dijagnostika
Field Type Null Key Extra
ID int(10) NO PRI auto_increment
P int(5) NO PRI
Datum date YES
Dijagnoza longtext NO
Terapija longtext YES
TipUsluge int(2) unsigned NO
pacijent
Field Type Null Key Extra
BR int(5) NO PRI auto_increment
Prezime varchar(20) YES
ImeOca varchar(20) YES
Ime varchar(20) YES
JMBG varchar(13) YES
DatumRodjenja date YES
Adresa varchar(25) YES
Mesto varchar(30) YES
Telefon varchar(20) YES
Notes varchar(50) YES
sifrarnik

80
 Field Type Null Key Extra
IdDijagnoze varchar(5) NO PRI
TromesnaSifra varchar(3) NO
NazivDijagnoze varchar(150) YES
LatinskiNaziv varchar(150) YES

tip_usluge
Field Type Null Key Extra
IDTipa int(2) NO PRI auto_increment
unsigned
NazivTipaUsluge varchar(25) YES

Na osnovu konceptualnog modela, imamo relacioni model:

Sifrarnik (IdDijagnoze, TromesnaSifra, NazivDijagnoze, LatinskiNaziv)

Cena_usluge (RBCen, DatumCenovnika, Cena, TipUsluge*)
Tip_usluge (IDTipa, NazivTipaUsluge)
Pacijent (BR, Prezime, ImeOca, Ime, JMBG, DatumRodjenja, Adresa, Mesto, Telefon,
Notes)
Dijagnostika (ID, P, Datum, Terapija, Dijagnoza*, TipUsluge* )

Primarni ključevi su podvučeni, dok spoljni ključevi imaju zvezdicu pored naziva.

81
 8.3. PROJEKTOVANJE

Faza projektovanja opisuje fizičku strukturu i ponašanje softverskog sistema (arhitekturu

softverskog sistema). Projektovanje arhitekture softverskog sistema obuhvata projektovanje
aplikacione logike, skladišta podataka i korisničkog interfejsa.

Projektovanje aplikacione logike – Kontroler aplikacione logike

Preko klase KontrolerPL prihvatamo zahtev od klijenata za izvršenje sistemskih operacija i

iste prosleđujemo do klasa koje su odgovorne za izvršenje SO.
Za svaku sistemsku operaciju se pravi softverska klasa, koja treba da realizuje SO. One
predstavljaju softverske klase ponašanja.
Klasa KontrolerPL ima ulogu Fasade, jer ona redirektuje pozive od strane klijenta ka klasama
koje su odgovorne za izvršenje sistemskih operacija. Klasa KontrolerPL je interfejs, i samo
metode interfejsa klijent može da „vidi“. Klasa koja zapravo poziva sistemske operacije, i
koja implementira taj interfejs je KontrolerPLImpl. KontrolerPLImpl može, pored metoda
svog interfejsa da ima i sopstvene pomoćne metode.

82
Façade pattern: Klasa KotrolerPLImpl predstavlja fasadu koja preusmerava pozive ka
sistemskim operacijama, čime se smanjuje složenost sistema. Klijent ne može pristupati
direktno klasama koje implementiraju ponašanje sistema, vec jedino preko Facade.

83
Projektovanje strukture softverskog sistema(aplikaciona logika) – Poslovna logika –
Domenske klase

Na osnovu konceptualnih klasa, prave se softverske klase strukture:

Klase strukture (domenske klase) implementiraju interfejs OpstiDomenskiObjekat, da

bi se dobila polimorfnost metoda DatabaseBrokera (koji kao argumente prima taj interfejs,
umesto samih klasa).

84
Projektovanje ponašanja softverskog sistema – Aplikaciona logika – Poslovna logika -
Sistemske operacije

Sve sistemske operacije ( klase koje ih implementiraju nasledjuju klasu OpstaSO, koja
u svojoj definiciji ima metodu opsteIzvrsenjeSO (OpstiDomenskiObjekat odo) i koja
predstavlja primer Template method pattern-a, jer ona svim klasama koje je nasleđuju pruža
servise komunikacije sa DatabaseBrokerom, a u svom telu poziva apstraktnu metodu
izvrsenjeSO (OpstiDomenskiObjekat odo), koju mora da implementira svaka klasa ponašanja,
pa se time omogućuje da svaka klasa ima razlicito ponašanje, a koristi servise Brokera za
komunikaciju sa perzistetnim skladištem).

Ugovor UG1: vratiBrPoslednjegPacijenta(Pacijent pac) : signal

Sekvencni dijagram za sistemsku operaciju VratiPoslednjegPacijentaUBazi

Dijagram kolaboracije za sistemsku operaciju : VratiPoslednjegPacijentaUBazi

85
Ugovor UG 2 : snimiNovogPacijenta(Pacijent pac): signal

Ugovor UG3 : prikaziPodatkeOIzabranomPacijentu(Pacijent pac): signal

Ugovor UG4 : izbrisiPacijentaIzBaze(Pacijent pac): signal

86
Ugovor UG5: izmeniPodatkeOIzabranomPacijentu(Pacijent pac): signal

Ugovor UG6 : snimiNovuDijagnostiku(Dijagnostika dij) : signal

Ugovor UG7 : vratiSvePoseteIzabranogPacijenta(Dijagnostika dij, ArrayList

listaDatuma): signal

87
Ugovor UG8 : vratiPodatkeOIzabranojPoseti(Dijagnostika dij) : signal

Ugovor UG9 : izmeniPodatkeOIzabranojPoseti(Dijagnostika dij) : signal

Ugovor UG10 :vratiSveSifreBolestiIzBaze(Sifrarnik sif, ArrayList listaSvihSifaraBolesti)

: signal

88
Ugovor UG11 : snimiNovuSifruBolesti(Sifrarnik sif) : signal

Ugovor UG 12 : vratiVrsteUsluga(Tip_usluge tu, ArrayList listaVrstaUsluga) : signal

}

Ugovor UG 13: vratiPoslednjuCenuUsluge(Cena_usluge cu) : signal

89
Ugovor UG 14 : snimiNovuCenuUsluge(Cena_usluge cu) : signal

Ugovor UG 15 : vratiSvePacijente(Pacijent pac, ArrayList listaPac) : signal

Ugovor UG 16 : vratiPoseteSvihIzBaze(Dijagnostika dij, ArrayList listaDij) : signal

90
Projektovanje aplikacione logike – DatabaseBroker

Klasa DatabaseBroker je zamišljena kao posrednik u svim operacijama nad bazom podataka, i
kao takva implementira sledeće metode:

public int otvoriBazu(String imeBaze);

public int commitTransakcije();
public int rollbackTransakcije();
public int zatvoriBazu();
public int vratiMaxPK(OpstiDomenskiObjekat odo);
public int vratiPacijentePoLIKEKriterijumu(OpstiDomenskiObjekat odo);
public int kreirajNoviSlog(OpstiDomenskiObjekat odo);
public int brisiSlog(OpstiDomenskiObjekat odo);
public int promeniSlog(OpstiDomenskiObjekat odo);
public int vratiSveSlogoveTabele(OpstiDomenskiObjekat odo, ArrayList
listaPacijenataTEMP, int kodSortiranja);
public int popuniSvaPoljaOdabranogObjekta(OpstiDomenskiObjekat odo);
public int vratiSlogoveTabelePoUslovu(OpstiDomenskiObjekat odo, ArrayList
listaObjekata);
public int daLiPostojiSlog(OpstiDomenskiObjekat odo);
public int vratiPoslednjiSlogPoZadatomUslovu(OpstiDomenskiObjekat odo);

91
 Bridge pattern Komunikacija između DatabaseBrokera i klase OpstiDomenskiObjekat

Bridge pattern odvaja apstrakciju od njene implementacije tako da se one mogu menjati
nezavisno. DatabaseBroker sadrži konkretnu implementaciju apstrakcije
(OpstiDomenskiObjekat), dok apstrakciju implementiraju konkretne domenske klase.
Korišćenjem koncepata apstrakcije i dekompozicije, složenost problema se pojednostavljuje.

92
 Arhitektura softverskog sistema

Arhitektura sistema se zasniva na klasičnoj tronivojskoj arhitekturi, koja jasno razdvaja

prezentaciju, logiku i perzistentno skladište.

Tro-nivojska arhitektura se sastoji iz sledećih nivoa:

1. Korisničkog interfejsa koji predstavlja ulazno-izlaznu reprezentaciju softverskog sistema
2. Aplikacione logike koja opisuje strukturu i ponašanje softverskog sistema
3. Skladišta podataka koji čuva stanje atributa softverskog sistema

Konačan izgled arhitekture prikazan je na slici 38.

93
Slika 38: Konačan izgled arhitekture softverskog sistema: Komunikacija izmedju klijentskog i
serverskog dela se odvija korisćenjem javine RMI (Remote Method Invocation) tehnologije.

94
 Projektovanje korisničkog interfejsa

Korisnički interfejs predstavlja realizaciju ulaza i/ili izlaza softverskog sistema. Korisnički
interfejs sastoji se od ekranskih formi i kontrolera korisničkog interfejsa.

Projektovanje ekranskih formi:

SK1: Ubacivanje novog pacijenta

Osnovni scenario SK

1. Korisnik poziva sistem da vrati šifru novog pacijenta(APSO)

2. Sistem nalazi šifru novog pacijenta(SO)
3. Sistem prikazuje šifru novog pacijenta(IA)

4. Korisnik unosi podatke o novom pacijentu(APUSO)

5. Korisnik kontroliše unete podatke (ANSO)
6. Korisnik poziva sistem da zapamti novog pacijenta (APSO)

95
 Opis akcije: Korisnik sistema pritiska dugme (jednim levim klikom miša) Snimi pacijenta,
nakon cega se poziva sistemska operacija zadužena za snimanje pacijenta.

7. Sistem pamti novog pacijetna (SO)

8. Sistem pokazuje korisniku poruku o uspešnom pamćenju pacijenta (IA)

Alternativna scenarija
3.1. Ukoliko sistem ne moze da dodeli šifru novom pacijentu, prikazuje se poruka(IA).
Prekida se izvršenje scenarija.
8.1. Ukoliko sistem ne moze da zapamti novog pacijenta, prikazuje se poruka(IA).

96
 Prekida se izvršenje scenarija.

SK2:Pregled podataka o pacijentu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)

4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)

97
 Opis akcije: Korisnik iz liste sa svim pacijentima u levom delu ekranske forme, bira
pacijenta čije podatke želi da vidi. Automatski se poziva sistemska operacija koja je
zadužena da vrati podatke o traženom pacijentu.
5. Sistem traži pacijenta sa datim imenom i prezimenom (SO)
6. Sistem prikazuje podatke o traženom pacijentu (IA)

Alternativna scenarija

3.1. Ako sistem ne može da vrati listu sa svim pacijentima, prikazuje se odg.
Poruka(IA). Prekida se izvršenje scenarija.
6.1. Ako pacijent sa tim imenom i prezimenom ne postoji u bazi podataka, sistem
prikazuje poruku o tome(IA)

98
SK3: Izmena podataka o pacijentu

Preduslov: Sistem je uključen i prikazuje formu za prikaz podataka o pacijentu

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)
5. Sistem traži pacijenta sa datim imenom i prezimenom (SO)
6. Sistem prikazuje podatke o traženom pacijentu (IA)
7. Korisnik menja podatke o odabranom pacijentu(APUSO)
8. Korisnik poziva sistem da zapamti načinjene izmene(APSO)

Opis akcije: Korisnik jednim levim klikom miša na dugme snimi izmene na dnu
ekranske forme poziva sistemsku operaciju zaduženu za izmenu podataka o
naznačenom pacijentu.

9. Sistem pamti izmene pacijenta(SO)

10. Sistem prikazuje poruku da je pacijent uspešno izmenjen(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako iz nekog razloga pacijent ciji se podaci menjaju ne postoji više u bazi
podataka, prikazuje se poruka korisniku o tome(IA) Prekida se izvršenje scenarija.
10.1. Ako sistem ne može da zapamti novonastale promene nad podacima, sistem
prikazuje poruku klijentu da nije uspelo pamćenje novih podataka(IA). Prekida se izvršenje
scenarija.

99
SK4: Brisanje pacijenta iz baze podataka

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)
5. Sistem traži pacijenta sa datim imenom i prezimenom (SO)
6. Sistem prikazuje podatke o traženom pacijentu (IA)
7. Korisnik poziva sistem da izbrise odabranog pacijenta iz baze(APSO)

Opis akcije: Korisnik jednim levim klikom miša na dugme obrisi pacijenta, na dnu
ekranske forme, poziva sistemsku operaciju zaduženu za brisanje naznačenog
pacijenta.

8. Sistem briše pacijenta iz baze(SO)

9. Sistem prikazuje poruku da je pacijent izbrisan iz baze(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako iz nekog razloga pacijent čiji se podaci menjaju ne postoji više u bazi
podataka, prikazuje se poruka korisniku o tome(IA) Prekida se izvršenje scenarija.

100
 9.1. Ako sistem ne može da izbrise pacijenta, sistem prikazuje poruku klijentu da nije
uspelo brisanje pacijenta (IA). Prekida se izvršenje scenarija.

SK5: Ubacivanje nove posete pacijenta

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta(APSO)

Opis akcije: Korisnik jednim levim klikom miša bira pacijenta iz liste pacijenata na
ekranskoj formi. Time se automatski poziva sistemska operacija zadužena za vraćanje
podataka o traženom pacijentu.
5. Korisnik unosi detalje o poseti(APUSO)
6. Korisnik poziva sistem da zapamti novu posetu(APSO)

101
 Opis akcije : Korisnik jednim klikom miša na dugme Snimi posetu poziva sistemsku
operaciju zaduženu za snimanje nove posete datog pacijenta.

7. Sistem pamti novu posetu pacijenta(SO)

8. Sistem prikazuje poruku o uspešnom pamćenju posete(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
8.1. Ukoliko sistem nije sposoban da zapamti novu posetu pacijenta, prikazuje se
odg.poruka(IA). Prekida se izvršenje scenarija.

102
SK6: Pregled posete postojećeg pacijenta

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta i poziva sistem
da prikaze datume poseta odabranog pacijenta(APSO)

Opis akcije : Korisnik jednim levim klikom miša bira pacijenta iz liste pacijenata, cime
se automatski poziva sistemska operacija zaduzena da vrati sve posete datog
pacijenta.

5. Sistem trazi sve posete odabranog pacijenta(SO)

6. Sistem prikazuje posete odabranog pacijenta(IA)
7. Korisnik bira posetu koju želi da vidi na formi(APUSO)

103
 Opis akcije : Korisnik na listi datuma poseta, jednim levim klikom miša bira datum
posete koju želi da vidi.
8. Korsnik poziva sistem da prikaže detalje odabrane posete(APSO)

Opis akcije : Korisnik jednim levim klikom miša na listu pacijenta poziva sistemsku
operaciju zaduženu da vrati podatke o traženoj poseti.

9. Sistem nalazi željenu posetu(SO)

10. Sistem prikazuje posetu(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako sistem nije sposoban da prikaže sve posete odabranog pacijenta, prikazuje se
odg.poruka(IA) . Prekida se izvršenje scenarija.
10.1. Ako sistem nije sposoban da prikaže odabranu posetu pacijenta, prikazuje se

104
odg.poruka (IA). Prekida se izvršenje scenarija.

SK7: Slučaj korišćenja – Pregled svih poseta pacijenta

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta i poziva sistem
da prikaže sve posete odabranog pacijenta(APSO)

5. Sistem traži sve posete odabranog pacijenta(SO)

6. Sistem prikazuje sve posete odabranog pacijenta(IA)

105
Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako sistem nije sposoban da prikaže sve posete odabranog pacijenta, prikazuje se
odg.poruka(IA) . Prekida se izvršenje scenarija.

SK8: Izmena posete pacijenta

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve pacijente iz baze podataka(APSO)

2. Sistem nalazi sve pacijente u bazi podataka(SO)
3. Sistem prikazuje sve pacijente iz baze podataka(IA)
4. Korisnik iz liste sa svim pacijentima na formi bira nekog pacijenta i poziva sistem
da prikaže datume poseta odabranog pacijenta(APSO)
5. Sistem traži sve posete odabranog pacijenta(SO)
6. Sistem prikazuje posete odabranog pacijenta(IA)
7. Korisnik bira posetu koju želi da vidi na formi(APUSO)
8. Korsnik poziva sistem da prikaže detalje odabrane posete(APSO)
9. Sistem nalazi željenu posetu(SO)
10. Sistem prikazuje posetu(IA)
11. Korisnik menja detalje odabrane posete pacijenta(APUSO)
12. Korisnik poziva sistem da zapamti izmene posete(APSO)

106
 Opis akcije: Korisnik jednim levim klikom miša na dugme Snimi izmene, poziva
sistemsku operaciju zaduženu da vrši izmenu naznačene posete.

13. Sistem pamti izmenjenu posetu(SO)

14. Sistem prikazuje poruku da je uspešno izmenjena poseta(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve pacijente iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako sistem nije sposoban da prikaže sve posete odabranog pacijenta, prikazuje se
odg.poruka(IA) . Prekida se izvršenje scenarija.
10.1. Ako sistem nije sposoban da prikaže odabranu posetu pacijenta, prikazuje se
odg.poruka (IA). Prekida se izvršenje scenarija.
14.1. Ako sistem nije sposoban da zapamti izmene posete, prikazuje se odg. poruka
(IA). Prekida se izvršenje scenarija.

SK9: Pregled detalja postojeće usluge

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve vrste usluga iz baze podataka(APSO)

107
 2. Sistem nalazi sve vrste usluga u bazi podataka(SO)
3. Sistem prikazuje sve vrste usluga iz baze podataka(IA)
4. Korisnik iz liste sa svim vrstama usluga na formi bira neku vrstu usluge i poziva
sistem da prikaže cenu i datum početka vašenja cene usluge(APSO)

Opis akcije: Korisnik jednim levim klikom miša na listu usluga poziva sistemsku
operaciju zaduženu da vrati poslednje podatke o toj vrsti usluge.
5. Sistem traži poslednju cenu i datum usluge(SO)
6. Sistem prikazuje detalje usluge(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve vrste usluga iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako sistem nije u stanju da prikaše detalje o ceni i datumu poslednje izmene cene
konkretne usluge, prikazuje odg. poruku(IA). Prekida se izvršenje scenarija.

SK10: Izmena detalja postojeće usluge

Osnovni scenario SK

1. Korisnik poziva sistem da vrati sve vrste usluga iz baze podataka(APSO)

2. Sistem nalazi sve vrste usluga u bazi podataka(SO)
3. Sistem prikazuje sve vrste usluga iz baze podataka(IA)
4. Korisnik iz liste sa svim vrstama usluga na formi bira neku vrstu usluge i poziva
sistem da prikaže cenu i datum početka važenja cene usluge(APSO)
5. Sistem traži poslednju cenu i datum usluge(SO)
6. Sistem prikazuje detalje usluge(IA)

108
 7. Korisnik menja detalje konkretne usuge(APUSO)
8. Korisnik poziva sistem da zapamti izmene usluge(APSO)

Opis akcije: Korisnik jednim levim klikom miša na dugme Snimi izmenu, poziva
sistemsku operaciju zaduženu za izmenu detalja o željenoj usluzi.
9. Sistem pamti izmene detalja vezanih za uslugu(SO)
10. Sistem prikazuje poruku o uspešnoj izmeni detalja usluge(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da vrati sve vrste usluga iz baze, prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.
6.1. Ako sistem nije u stanju da prikaže detalje o ceni i datumu poslednje izmene cene
konkretne usluge, prikazuje odg. poruku(IA). Prekida se izvršenje scenarija.
10.1. Ako sistem nije u stanju da prikaže poruku o uspešnoj izmeni detalja usluge,
prikazuje odg. poruku(IA). Prekida se izvršenje scenarija.

SK11: Pregled sifara bolesti

Osnovni scenario SK

1. Korisnik poziva sistem da vrati listu sa šiframa bolesti(APSO)

109
 2. Sistem kreira listu sa šiframa bolesti(SO)
3. Sistem prikazuje listu sa šiframa bolesti(IA)

Alternativna scenarija:
3.1. Ako sistem nije u stanju da prikaže listu sa šiframa svih bolesti , prikazuje tu
poruku(IA). Prekida se izvršenje scenarija.

SK12: Ubacivanje nove šifre bolesti

Osnovni scenario SK

1. Korisnik unosi detalje o novoj šifri bolesti(APUSO)

2. Korisnik kontroliše da li je pravilno uneo sve neophodne podatke(ANSO)
3. Korisnik poziva sistem da kreira novu šifru bolesti(APSO)

110
 Opis akcije: Korisnik jednim levim klikom miša na dugme Snimi novu šifru poziva
sistemsku operaciju zaduženu za snimanje nove šifre bolesti.
4. Sistem pamti novu šifru bolesti(SO)
5. Sistem prikazuje poruku da je uspešno zapamtio novu šifru bolesti(IA)

Alternativna scenarija:
5.1. Ako sistem nije u stanju da zapamti novu šifru bolesti , prikazuje tu poruku(IA).
Prekida se izvršenje scenarija.

8.4. Implementacija

Softverski sistem je implementiran u programskom jeziku Java. Kao razvojno okruženje je

korišćen NetBeans 6.1 (sa jdk 1.6.0_03), dok je sistem za upravljanje bazom podataka
MySqlServer 5.1.
Za implementaciju klijent-server arhitekture je korišćena Java RMI (Remote Method
Invocation).Napravljena je .bat datoteka sa serverske strane, kako bi se automatizovalo
pokretanje programa.
Za implementaciju klijent-server tronivojske arhitekture korišćena je JEE tehnologija. Stoga
je najpre neophodno instalirati Apache Tomcat web server, na nekom čvoru mreže, na koji će
se postaviti Web modul. Sve što je potrebno na klijentskoj strani je Web čitač preko koga se
pristupa serveru preko adrese http://<localhost_or_IP>:80/StomatoloskaOrdinacija/.
Ova web aplikacija predstavlja nastavak rada prethodnog projekta, tako da su pojedine klase
na strani klijenta uključene u ovaj projekat, dok je sama serverska strana ostala nepromenjena.

111
 9. Zaključak

U uvodnom delu diplomskog rada dato je kratko upoznavanje sa Java Enterprise Edition
platformom, dok se sam diplomski rad najviše bazira na tehnologijama Servleta, Java Server
Pages i Java Server Faces. Studijski primer obuhvata projektovanje informacionog sistema
pojednostavljenog modela namenjenog za rad u stomatološkim ordinacijama. U tom poglavlju
su prikazane i faze životnog ciklusa razvoja softverskog sistema, dok je pri projektovanju
korisćena Larmanova metoda. Prva faza prikupljanja zahteva je opisana preko modela
slučajeva korisćenja. Ponašanje softverskog sistema je prikazano u fazi analize preko
sistemskih dijagrama sekvenci i ugovora, dok je struktura softverskog sistema predstavljena
preko konceptualnog i relacionog modela. Faza projektovanja je prilagođena tro-nivojskog
arhitekturi. Implemetacija samog programa se zasniva se na tehnologijama Servleta i
JavaServer Pages, što mi je u značajnoj meri smanjilo i olakšalo pisanje koda. Za
komunikaciju, kontrolu i obradu informacija između korisničkog interfejsa i poslovne logike
je odgovoran Servlet. Koristeci JEE tehnologije dobar deo koda se generiše sam. Faza
testiranja nije razmatrana.
Radeći na ovom radu, mnogo sam naučila, a samim tim i uvidela da se Java tehnologija
razvija u pravcu koja svakim danom olakšava posao programerima pri kreiranju velikih,
višenivojskih, skalabilnih, pouzdanih,i sigurnih mrežnih aplikacija.

112
Literatura:

[1] www.sun.com
[2] Eric Armstrong, Jennifer Ball, Stephanie Bodoff, Debbie Bode Carson, Ian Evans,
Dale Green, Kim Haase, Eric Jendrock: The Java2EE 1.4 Tutorial, 2005.
[3] Dr Siniša Vlajić: Projektovanje programa, Beograd, 2006.
[4] K.Arulkumaran: Learn Java/J2EE core concepts and design/coding issues
With Java/J2EE Job Interview Companion, 2005.
[5] David R. Heffelfinger: Java EE 5 Development using GlassFish Application Server,
2007.
[6] Ted Neward: Effective Enterprise Java, 2004.
[7] http://en.wikipedia.org/
[8] Dr Siniša Vlajić, Dušan Savić, Vojislav Stanojević, Ilija Antović, Miloš Milić:
Projektovanje softvera – napredne Java tehnologije, FON, Beograd 2008.
[9] Hans Bergsten: JavaServer Pages, 3rd Edition, 2003.
[10] David Geary, Cay Horstmann: Core JavaServer Faces,2004.
[11] Cay S. Horstmann, Gary Cornell: Java 2 Tom II Napredne tehnike, 2008.
[12] Jonas Jacobi, John R. Fallows: Pro JSF and Ajax, 2006.
[13] Jason Hunter: Java Servlet Programming, 1998.
[14] http://www.developersbook.com/jsf/jsf-tutorials/jsf-tutorials.php
[15] http://www.visualbuilder.com/jsp/webcomponent/servlet-execution-flow/
[16] http://www.docstoc.com/docs/1526965/J2EEOverview
[17] http://www.javapassion.com/
[18] www.pjp.fon.rs

113