VIŠA ELEKTROTEHNIČKA ŠKOLA
Nikolić Slobodan
RAZVOJ POSLOVNIH APLIKACIJA – JEDNO REŠENJE
– diplomski rad –
Beograd, 2005
Kandidat:
Nikolić Slobodan
Broj indeksa:
03/02
Smer:
Računarska tehnika
Tema:
Razvoj poslovnih aplikacija – jedno rešenje
Osnovni zadaci:
1. Razviti framework za rad sa relacionim bazama podataka
2. Primeniti razvijeni framework na primeru desktop aplikacije
3. Koristiti J2EE tehnologije
Hardver:
0%
Softver: 80
%
Teorija: 20
%
Mentor:
Beograd,
10.10.2005. _________________________
Mr. Boško Nikolić
Nikolić Slobodan: Poslovne aplikacije – jedno rešenje
UVOD
Razvoj softvera odavno je postao širok pojam. Svaka vrsta aplikacija koje se projektuju
ima svoje izazove i kompleksnosti. Primera radi, softver za telekomunikacionu industriju
morao bi da vodi računa o multithreading-u, integraciji softvera i hardvera, što nije slučaj sa
Enterprise aplikacijama. S druge strane Enterprise aplikacije često rade sa kompleksnim
podacima, imaju složenu poslovnu logiku i pravila. Iako su neke tehnike i pattern-i relevantni
za sve vrste softvera, neki su primenljivi samo na pojedinim vrstama.
Kada odlučujemo kako da projektujemo Enterprise poslovnu aplikaciju i koje pattern-e
da koristimo, veoma je važno imati u vidu to da Enterprise aplikacije nisu sve iste i te razlike
treba da odluče kojim putem ćemo ići. Dakle, ne postoji univerzalni dizajn. Generalno važi
podela na B2C (business to clients) i B2B (business to business) aplikaicje. Navešću neke od
karakteristika poslovnih aplikcija.
Poslovne aplikacije zahtevaju
čuvanje (perzistenciju) podataka
. Ovo je potrebno da bi
isti podaci bili dostupni u više navrata i po nekoliko godina bez obzira na prekid rada
aplikacije. Često se tu radi sa
velikim količinama podataka
, preko 1Gb, organizovanih u
preko 10 miliona redova. Upravljanje tolikim količinama podataka obavljaju baze podataka.
Pri tom treba imati u vidu i to da mnogo ljudi
pristupa podacima konkurentno
. Za neke
sisteme ovaj broj može biti par stotina, dok za Web aplikacije može biti nesaglediv. Tu treba
voditi računa da se ne desi situacija u kojoj dve osobe pristupaju istom podatku na način koji
može proizvesti greške. Transaction manager-i obavljaju ovaj posao, ali ipak, ta problematika
se ne može sakriti od programera.
Pored toga, ovakvi informacioni sistemi mogu da sadrže
mnogo korisničkih interfejsa
za prikaz različitih informacija. Korisnici Enterprise aplikacija variraju i mogu spadati u
različite grupe tako da informacije treba da im se prikažu na različite načine i u različite svrhe.
Enterprise aplikacije retko žive na "ostrvu", usamljene, već imaju potrebu da se
integrišu sa drugim aplikacijama
. Različiti sistemi izrađeni u različito vreme i na različitim
tehnologijama, čak i mehanizmi kolaboracije mogu biti različiti: COBOL data files, CORBA,
messaging systems. Ovo postaje još teže kada dodamo činjenicu da poslovne aplikacije imaju
težnju za saradnjom sa aplikacijama kompanijskih partnera pa im se moraju prilagoditi.
Kompleksna poslovna logika
bitna je karakteristika ovih sistema. Poslovna pravila su
vam data takva kakva su i vi ih ne možete menjati. Suočavate se sa nizom čudnih uslova koji
često reaguju jedni sa drugima na iznenađujući način (naravno da za takvo ponašanje postoje
opravdani razlozi). U takvoj situaciji morate organizovati poslovnu logiku što je moguće
bolje, jer je jedina izvesna stvar to da će se ta logika vremenom menjati, a vi trebate biti
spremni za nove izazove.
Na kraju postavljamo pitanje: Kako se nositi sa ovim problemima? – "Podeli pa vladaj!"
slogan, primenljiv je i u industriji softvera. Tehnologije poput Java2Enterprise, brojna
framework rešenja, višeslojna arhitektura softvera nastala su upravo sa ciljem da pomognu
razvoj informacionih sistema. Postoji mnogo framework-a napisanih za Javu. Neki se koriste
kao osnova za izgradnju cele aplikacije, dok se drugi bave određenim njenim delovima.
1
Nikolić Slobodan: Poslovne aplikacije – jedno rešenje
1. PRISTUP BAZAMA PODATAKA
Čuvanje podataka je potreba svake poslovne aplikacije. Perzistencija je jedan od
osnovnih pojmova u razvoju aplikacija. Kada govorimo o perzistenciji u Javi, govorimo,
naravno, o skladištenju podataka u
relacionoj bazi
koristeći SQL. Relacione baze su
najzastupljenije i to ne slučajno već zato što imaju neverovatno fleksibilan i robustan prilaz
upravljanju podacima.
Relacioni model ovih baza podataka, međutim, nije prirodan Javi kao ni drugim
objektno orijentisanim jezicima. Kada radimo sa SQL bazama (relacione baze) u Java
aplikacijama, koristimo se SQL iskazima
Java Database Connectivity (JDBC) API
-ja. JDBC
koristimo da postavimo parametre upita, izvršimo ih, krećemo se kroz rezultujući set, vadimo
podatke iz njega, itd. Ovo su radnje niskog nivoa i programer koji se bavi razvojem aplikacija
ne bi trebao da je puno zainteresovan za taj stepen programiranja, već bi svoju pažnju trebao
da usmeri ka samoj poslovnoj logici. Cilj je da možemo da pišemo kod koji pamti i vraća
kompleksne objekte iz baze, a da pri tom ne ulazimo u detalje nižih nivoa. Kad je pristup
podacima tako naporan, postavlja se pitanje: Da li je relacioni model pravi izbor za objektno
orijentisane aplikacije? Odgovor je svakako: Da! Postoje brojni razlozi zbog kojih su
relacione baze potreba svake Java aplikacije.
Međutim između objektnog modela i relacionog modela ima neslaganja. Na primer,
SQL operacije poput projekcije ili spoja rezultovaće tabelarnom predstavom rezultujućeg
skupa. Ovo je sasvim drugačije od grafa međusobno povezanih objekata upetrbljenih za
izvršenje neke poslovne logike u Java aplikaciji. Radi se, dakle, o sasvim drugačijim
modelima, a ne samo drugačijem prikazu istog modela. Pogledajmo problem izbliza.
1.1. Nesaglasnost modela
Slika 1.1.1: Jednostavan UML klasni dikagram entiteta User i BillingDetails
Pretpostavimo da projektujemo online e-commerce aplikaciju. Za to nam je potrebna
klasa koja predstavlja korisnika sistema, i druga koja predstavlja informacije o njegovim
računima. Iz klasnog dijagrama vidi se da User ima više BillingDetails-a.
public class
User {
private
String
userName
;
private
String
name
;
private
String
address
;
private
Set
billingDetails
;
//
accessor methods (get/set pairs), business methods, etc.
...
}
public
class
BillingDetails
{
private
String
accountNumber
;
private
String
accountName
;
private
String
accountType
;
private
User
user
;
//methods, get/set pairs...
...
3
