1

INFORMACIONE TEHNOLOGIJE U MEDICINI 2012/13 LEKCIJA 3

Mateja Opačić

PROJEKTOVANJE SOFTVERA I ARHITEKTURA APLIKACIJA

Životni ciklus softvera

Životni ciklus softvera podrazumeva korake kroz koje se prolazi svaki put kada se kreira aplikacija bez obzira da li je mala ili velika. Prvi korak u tom procesu je skupljanje informacija. U ovom koraku treba prikupiti što više adekvatnih informacija kako bi se na osnovu njih mogao osmisliti softver. Sam proces prikupljanja podataka je jako složen i često kritičan u procesu proizvodnje softvera pa mu treba posvetiti maksimalno pažnje. Ovaj korak je ujedno i prvi korak u celokupnom procesu, pa svaka greška u ovom delu može biti višestruko umnožena u ostalim koracima. Drugi korak je analiza. U okviru analize se pregledaju prikupljeni zahtevi i ustanovljava se da li postoje praznine i/ili nedoslednosti u zahtevima. Često se u toku analize uzima još dodatnih zahteva kako bi se tačno definisao zadatak. Tredi korak u ovom procesu je dizajn. Ovde se ne misli na vizuelni dizajn aplikacije ved na raspored programskog koda. Odluka o dizajnu se donosi na osnovu analiziranih prikupljenih podataka. Dizajn aplikacije veoma zavisi od zahteva, tako da loše prikupljeni zahtevi mogu da navedu na pogrešan dizajn što dovodi do toga da je celokupan projekat pogrešno osmišljen i da se pogrešno kreira. Dizajnom se određuju programske celine i načini programiranja. Kodiranje je korak koji podrazumeva unos programskih linija u računar i kreiranje softvera. Iako izgleda kao najvažniji korak u procesu kreiranja softvera, on je samo jedan od postojedih koraka. Samo kodiranje jeste bitno i ključno, ali nije dovoljno za uspešno kreiranje aplikacije. Jedna od najvedih grešaka je započinjanje rada na softveru od ovog koraka. Ovakvi projekti su osuđeni na propast. Testiranje je korak koji je neophodan u svakoj izradi softvera. Pogrešan pristup u testiranju je da se testiranje vrši tek u trenutku kada se softver završi. Ako se testiranje vrši na ovaj način vedina grešaka u aplikaciji de biti otkrivena tek pred kraj životnog ciklusa razvoja softvera. Da do toga ne bi došlo sve više se koriste takozvana jedinična testiranja koja testiraju svaku kreiranu klasu i na taj način proces testiranja počinje paralelno sa procesom kodiranja, čime se drastično smanjuje ukupan broj grešaka na projektu. Instalacija, odnosno implementacija softverskog rešenja je korak u kojem se softverski sistem instalira kod korisnika. Ovaj korak je ponekad prilično komplikovan pa ga treba dobro pripremiti i osmisliti.

2

Svaki softver mora da pretrpi određene izmene tokom rada i zato je potrebno održavanje softvera. Ovaj korak je jako bitan svakom klijentu, a programeri ga često zanemaruju.

“Waterfall” metod projektovanja

Postoji više načina implementacije životnog ciklusa. Najjednostavniji je vodopad. On predstavlja sekvencijalno poređane sve elemente koji postoje u životnom ciklusu softvera. Dakle, radi se o doslovnoj implementaciji životnog ciklusa softvera. Ovo je najstariji način projektovanja softvera. Na početku računarske ere, kada su postojali uglavnom samo mali projekti, ovaj način je bio sasvim zadovoljavajudi. On je i danas koristan i funkcionalan kod malih projekata. Ako je projekat iole vedeg obima ovaj pristup nije adekvatan. Veliki broj projekata rađenih ovom metodologijom je propao, tako da ova metodologija ima mali procenat uspešnih projekata. Projekti koji su uspešno završeni ovom metodologijom spadaju obično u projekte malog obima. Problemi u ovoj metodologiji koji ovu metodologiju čine neprihvatljivom za srednje i velike projekte su: - Loša paralelizacija etapa: jedan tim mora da čeka dok drugi ne završi svoj deo posla, kako bi oni radili. Ovo dovodi do velikih gubitaka u ljudskim resursima i loše optimizacije vremena izvršavanja celokupnog projekta. Još jedna posledica ovakvog pristupa je duže vreme izvršavanja projekta - Loše upravljanje rizicima: svaki projekat nosi sa sobom izvestan broj rizika. Sistem vodopad u sebi ne sadrži nikakve mehanizme koji bi vodili računa o rizicima u projektu. Kao posledicu imamo da, kada nešto u projektu pođe kako ne treba, obično i celokupan projekat strada. - Problemi u komunikaciji: s obzirom da je u vodopad metodologiji svaka etapa nezavisna, obično se javlja problem kad ljudi koji rade na jednoj etapi zavise od ljudi iz druge etape koji su svoj deo posla završili ili još nisu ni počeli da ga rade. Jedna od analiza koja je ispitivala zašto softverski projekti propadaju, pokazala je da je najvedi razlog propasti programerskih projekata loša ili neuspela komunikacija između ljudi koji učestvuju na projektu. Ovaj metod projektovanja se smatra najnefleksibilnijim od svih metoda projektovanja koji postoje.

3

Slika 1: Waterfall metod projektovanja

Inkrementalni metod

Inkrementalni životni ciklus softvera se zasniva na razbijanju korisničkih zahteva na manje celine. Te manje celine se onda nezavisno obrađuju slededim redosledom: analiza, dizajn, kodiranje, testiranje i instalacija. Ideja je nastala od činjenice da je vodopad uspešan na malim projektima. Veliki projekat se onda izdeli na vedi broj manjih i svaki za sebe se vodi kao mali projekat. Iako je ideja dobra, ovakav način razvoja nosi sa sobom dosta problema. Osnovni problemi nastaju jer veliki projekti ne mogu uvek efektno da se podele u male nezavisne projekte. Iz tog razloga je često potrebna intezivna komunikacija i interakcija sa timovima koji razvijaju druge delove. Razvojem na ovaj način može da dođe do neusaglašenosti delova projekta, pa iz tog razloga mogu da nastanu i bagovi i nedoslednosti u funkcionalnosti.

4

Slika 2: Inkrementalni životni ciklus razvoja softvera

Iterativni životni ciklus

Vodopad je najlogičniji i najjednostavniji oblik životnog ciklusa razvoja softvera. Iz tog razloga postoje mnogi pokušaji da se taj sistem dotera i da se uklone nedostaci samog vodopad sistema. Pored inkrementalnog postoji i iterativni pristup. Kod iterativnog pristupa se zadržava vodopad princip, ali se obezbeđuje vradanje na predhodnu fazu po potrebi. Na ovaj način se obezbeđuju izmene u sistemu kada se za to pojavi potreba. Ovim se uklanja jedan od glavnih nedostataka vodopad sistema. Ovakav sistem je značajno fleksibilniji od vodopad sistema ali i dalje zadržava neke od mana vodopad sistema. Glavni nedostatak je odsustvo paralelnog razvoja, mada ovaj sistem omogudava da se neki elementi pojedinačnih faza mogu paralelno izvršavati.

5

Slika 3: Iterativna metodologija razvoja softvera

Spiralni metod projektovanja

Za razliku od vodopada gde se ne vodi računa o rizicima, spiralni način projektovanja je u potpunosti usmeren na rizike. Ovim načinom je eliminisan i problem naknadnih izmena i dopuna jer se svakim novim ciklusom mogu ubacivati nove izmene i dopune. Spiralni razvoj podrazumeva sledede: projekat se deli na više manjih celina i to pre svega u zavisnosti od rizika. Dakle, u određenom malom potprojektu daleko je lakše definisati mogude rizike i napraviti više rešenja koja pokrivaju celu paletu problema – rizika. Ovaj sistem primenjuje Microsoft u razvoju sopstvenih aplikacija. Glavna karateristika je da dok se jedan ciklus izvršava ved počinje drugi tako da dok teče faza testiranja u jednom ciklusu u isto vreme drugi ciklus može da bude u fazi analize ili kodiranja. Zbog ove karakteristike je ceo sistem i dobio naziv spiralni. Prednosti su sledede: može da skrati vreme izrade projekta, povedana je verovatnoda na uspeh i često je mogude primenom ovakvog sistema smanjiti troškove. Mane se ogledaju u slededem: veoma je komplikovano uskladiti veliki broj paralelnih aktivnosti i rad na različitim delovima koda.

6

Slika 4: Spiralni metod razvoja softvera

Prototipski ciklusi

Prototipska metodologija razvoja softvera nalaže da se kreira čitav niz prototipova. Počinje se od osnove, odnosno od bazičnog zahteva korisnika, pa se onda kreira jedan prototip samo od tih jednostavnih elemenata. Za ovako mali projekat je dobar vodopad sistem razvoja. Nakon završenog prototipa, taj prototip se instalira i korisnik ustanovljava šta mu se dopada na prototipu a šta ne i na osnovu toga se kreira slededi prototip. Mogude je i prvobitni prototip u potpunosti odbaciti i krenuti iz početka, sa drugim dizajnom i drugim zahtevima. Nakon razvoja, a često i paralelno sa razvojem jednog malog prototipa, razvija se drugi. Ovaj sistem je idealan za projekte na kojima klijent ne zna šta tačno hode. Na primer u naučnim timovima ili u slučaju razvoja novih koncepata. Razvojni tim se u takvim projektima plada po utrošenom vremenu, a nikako po poslu. Karakteristično za ovu metodologiju je da koristi sve raspoložive alate i programske jezike, tako da se projekat često radi na više programskih platformi istovremeno. Ova metodologija se obično koristi dok se ne dođe do nekog konačnog skupa zahteva, a nakon toga se projekat razvija iz početka sa nekim od standardnih metoda razvoja.

7

Extreme Programming (XP)

Ekstremno programiranje uvodi sasvim drugačiji sistem rada od do sad prikazanih. Ovde nema elemenata životnog ciklusa. U ekstremnom programiranju postoji stroga metodologija rada koja oslikava najbolju programersku praksu. Ekstremno programiranje uvodi svoje metodologije u svaki korak razvoja softvera, pri čemu je glavni akcenat na prisustvu klijenta u procesu izrade softvera, kodiranja i testiranja. Ciklusi razvoja softvera u ekstremnom programiranju su jako kratki, oko nedelju do dve dana između softverskih iteracija, što uslovljava veoma dinamičan razvoj. Ekstremno programiranje se zasniva na principu “prvo testiraj onda programiraj”. To bi značilo da se za određene opcije programa prvo kreiraju odgovarajudi testovi pa se isprogramira samo ono što zadovoljava te testove. U slededem koraku se osmišljaju novi testovi koji oslikavaju novu funkcionalnost pa se kreira kod koji ispunjava date testove. Kod se konstantno poboljšava koristedi refaktoring i dizajn paterne pri čemu testovi stalno opstaju da bi osigurali da program radi ono što treba. Prilikom kodiranja moraju da se poštuju strogi standardi kodiranja. Kod ekstremnog programiranja, prilikom kodiranja uvek su prisutna dva programera nad jednim računarom, poslovi se ugovaraju isključivo po vremenu angažovanja, zastupljeno je fiksno radno vreme, vlasništvo nad kodom je isključivo kolektivno i vrši se konstantna integracija.

Vlasništvo nad kodom

Na pitanje: ko de da menja kod kad je potrebno, postoji nekoliko mogudih situacija:

Niko – kod je izgubljen, ne postoji ili je zaštiden. U tom slučaju prema kodu se odnosimo kao prema crnoj kutiji. Ovo je najnepovoljinija situacija za programere koji treba nešto da urade.

Zadnji koji je menjao – na ovaj način se obaveze izmene koda odnose na onog ko je zadnji vršio izmene. Često se ovaj slučaj menja u slučaj da se vlasništvo dodeli najboljem slobodnom programeru. Ova situacija je takođe nezgodna jer programer kome je dodeljeno da radi na kodu možda nije najbolje upoznat sa situacijom u datom kodu a često se pred njega iznose zahtevi koji zalaze duboko u izmene koda koji programer nije radio.

Monogamija – jedna osoba je zadužena za jedan deo koda. Svaka izmena na kodu mora da se prođe kroz proces verifikacije od stane vlasnika koda. Ovo ima prednosti u obliku da se zna ko šta radi i šta je čija dužnost. U slučaju da osoba nije prisutna mora da se dodeli novi vlasnik tom kodu. Nedostatak ovog pristupa je pravo vlasnika da odbije izmene tako da ostali moraju da nepotrebno umotavaju njegov kod čime se gubi na performansama i kvalitetu. Takođe možda je vlasnik koda nešto pogrešio, pa sad krije

8

situaciju time što ne dozvoljava da se menja ono što funcioniše. Takođe može da se desi da se traži da se taj kod ne menja jer mnogo drugog koda ovisi o njemu iako su izmene u tom delu koda neophodne.

Iznajmljeno vlasništvo – u ovoj situaciji vlasnik je privremeno zadužen programer koji je nadležan za taj kod dok se radi određen zadatak. Nedostatak ovakvog pristupa je što je programer svestan privremenosti situacije pa se nede truditi da rešava probleme na duge staze ved samo onoliko koliko mu je potrebno da završi svoj zadatak. Ovo može dovesti do komplikovanja koda i loših rešenja posle par promena vlasnika.

Vlasništvo u lejerima – u ovom slučaju vlasništvo je podeljeno na manje timove. Svaki subtim ima pravo da pravi sve izmene u svom delu koda pri čemu o tome obaveštava ostale u timu. Ovo je odlična taktika za kvalitet koda i za način unapređivanja koda. Problemi su u komunikaciji između subtimova i njihovih slojeva. Interfejs koji spaja dva dela (lejera) je jako teško menjati i može da bude izvor problema.

Kolektivno vlasništvo – u ovom slučaju vlasnici su svi članovi tima tako da svi podjednako učestvuju u svim delovima koda. Dobre strane ovoga su mogudnost brze promene programa i efikasan rad. Ali i nedostaci su brojni. Možda neko ne želi da drugi menjaju njegov kod. Svako ima svoj stil programiranja, pa može da se desi da u istom delu koda postoji nekoliko različitih stilova programiranja. S obzirom da su svi zaduženi, lako se desi situacija da niko nije zadužen odnosno da niko ne želi da radi na tom delu koda, da niko nije zainteresovan da odradi stvari koji de poboljšati kod na duže staze, a često može da dođe i do sukoba među članovima tima.

Extreme programming (XP) podrazumeva kolektivno vlasništvo nad kodom bez obzira na probleme koji se javljaju. Rizici nastali od ovog principa vlasništva mogu da se smanje na više načina: - Izrada testova i princip “prvo test pa onda kod” ne dozvoljavaju da pojedinac poremeti postojedi kod. - Lični ponos, odnosno nedozvoljavanje da drugi menjaju kod, ne postoji u ekstremnom programiranju jer svi moraju da rade zajedno. - Programiranje u paru omogudava da se znanje proširuje kroz tim, a ujedno se i pravi ujednačeniji stil programiranja. - Promena parova u okviru koda i promena ljudi koji su bili par obezbeđuje da svi imaju uvid u rad svakog dela koda, smanjuje se mogudnost zaglavljivanja na nekom kodu, potpomaže širenje znanja i ujednačavanje stila programiranja i poštovanje dogovorenih standarda. - Konstantno refaktorovanje bi trebalo da obezbedi kvalitetniji i čitljiviji kod (primenjivati refaktoring što više).

9

- Jednostavni dizajn svakog dela koda omogudava da programeri mogu brzo da uđu u suštinu svakog dela koda. - Standardi pri programiranju obezbeđuju da se programer lako uključi na neki deo koda i da nastavi započet posao. - Konstantna integracija obezbeđuje da nečiji trud nije uzaludan ved da se ubacuje konstantno i proverava tako da niko nije pogođen previše.

Integracija

Kod koji je pisan od strane različitih članova tima može da se integriše u različitim trenucima:

Neposredno pre isporuke programa – ovakav način integracije je najproblematičniji. To je slučaj kad svako radi svoj deo posla i kad je sve završeno, pokušava se stapanje svega u jednu celinu. Ovo često ne funkcioniše: vreme koje je potrebno za integraciju naglo se povedava, a osoba zadužena za integraciju mora da rešava gomilu problema. Takođe može da se desi da je neki član tima pogrešno shvatio svoj zadatak i da je uzaludno radio nedeljama, a da se to vidi tek prilikom integracije.

Povremeno – u ovoj varijanti integracija se vrši u nekim trenucima kada se vrši revizija urađenog i pregled tekudeg stanja. Ovakav način integracije se koristi da bi menadžeri i investitori stekli sliku o trenutnom stanju stvari. Ovo je više formalna integracija i ne razlikuje se od integracije neposredno pre isporuke, osim što su koraci između dve integracije ipak kradi nego u prvom slučaju.

Dnevna integracija – na kraju radnog dana se izvrši integracija svega što je urađeno tog dana. Na ovaj način se obezbeđuje da niko ne ode predaleko od zadatog cilja bez provere sa ostatkom tima. Ovakav princip ima i svoje loše strane što neko mora stalno da utvrđuje ko je pogrešio i da pronađe ko treba da ispravi grešku.

Konstantna integracija – XP programiranje zahteva konstantnu integraciju. To znači da par koji programira integriše svoj kod u ostatak projekta par puta u toku dana. Ovo se radi tako što postoji jedna mašina na kojoj se nalazi celokupan projekat i na kojoj se vrši integracija. Kada programerski par završi neku fazu seda za tu mašinu i integriše svoj deo posla sa ostatkom projekta koji je zatečen na mašini. Ovo je olakšano zahvaljujudi unit testovima koji moraju da budu zadovoljeni kada se ubaci novi deo. Svaki programerski par na mašinu stavlja kod zajedno sa test unitima (svi testovi su OK na mestu na kome su pisali kod), integriše ga sa ostatkom i proverava da li svi testovi u projektu prolaze sa OK. U tom slučaju vradaju se na svoje mesto i nastavljaju sa radom. U suprotnom, ne integrišu svoj deo ved ga prvo poprave (ako je potrebno pomaže im neki drugi programerski par).

10

RUP - Rational Unified Process

RUP predstavlja sistem razvoja baziran na UML procesima. Podržan je od strane velikih kompanija kao što su IBM, Oracle, itd. Ovaj sistem razvoja podrazumeva drugačije faze razvoja od onih viđenih kod vodopad sistema. Prilagođen je objektno orijentisanim programskim jezicima, mogu ga primenjivati i timovi i pojedinci i može se koristiti i za male i za velike projekte. Faze u RUP-u: 1. Inception - Identifikacija biznis slučaja za projekat. - Dokument koji predstavlja osnovni nacrt projekta. - Definisanje obima projekta. - Gruba definicija potreba projekta. - Kraj faze: definisani ciljevi projekta. 2. Elaboration - Detaljna izrada projektnog plana. - Detaljan biznis slučaj. - Detaljni korisnički zahtevi. - Definisanje skoro svih zahteva. - Inicijalna arhitektura aplikacije. - Plan razvoja. - Kraj faze: Definisana arhitektura 3. Construction - Iterativno i inkrementalno kreiranje projekta. - Kreiranje beta verzije softvera. - Kreiranje korisničke dokumentacije. - Kraj faze: Osnovna funkcionalna beta verzija softvera. 4. Transition - Implementacija – instalacija. - Obuka korisnika. - Kraj faze: Isporuka softvera.

11

Slika 5: RUP metodologija razvoja

Arhitektura aplikacije

Postoji više tipova arhitekture aplikacije. Svaka od ovih arhitektura je bila u nekom trenutku u istoriji otkrivena i korišdena, ali ni jedna od njih nije prevaziđena ili izbačena iz upotrebe. Nove arhitekture su otkrivane kada se pojavila potreba za određenim oblikom aplikacije, odnosno kada su se pojavili specifični zahtevi. Svaka aplikacija se sastoji od vedeg broja različitih poddelova, objekata u objektnim aplikacijama ili modula u modularnim. Ti delovi jedne aplikacije moraju da se raspodele u zavisnosti od toga koji deo aplikacije treba gde da se izvršava. Vedina jednostavnih aplikacija ima monolitnu strukturu, odnosno izvršava se na jednom računaru. Ali nisu sve aplikacije koje se izvršavaju na jednom računaru monolitne. Arhitektura aplikacije zavisi od više parametara - zahteva.

12

Namena aplikacije i postavka aplikacije povlače sa sobom način organizacije delova aplikacije, način raspodele programa kao i način na koji koristimo takvu aplikaciju. Tako da namena i način korišdenja aplikacije uslovljava koju arhitekturu aplikacije demo primeniti. Arhitektura aplikacije nije vezana za programski jezik u kom programiramo aplikaciju. Iako je u nekim programskim jezicima lakše implementirati određenu arhitekturu, generalno govoredi, arhitektura aplikacije nije vezana za programski jezik.

Tipovi arhitekture

Postoji više tipova arhitekture. Trenutno se koriste slededi tipovi: Monolitna, Dvoslojna koja se još naziva i Client-Server, Troslojna, Višeslojna i SOA (Service oriented aplication). Svaki od ovih tipova arhitekture ima svoje karakteristike i specifičnu namenu. Namena aplikacije najviše utiče na to koju arhitekturu demo odabrati. Tako na primer ako želimo da pravimo jednostavan kalkulator svakako demo se odlučiti za monolitnu arhitekturu. S druge strane, ako želimo da pravimo veb portal koji de da opslužuje korisnike sa najrazličitijim informacijama od sporta do berzanskih izveštaja onda demo odabrati SOA arhitekturu. Postoje naravno situacije kad namena aplikacije nije dovoljna da bi se odredila arhitektura aplikacije, a postoje i situacije kad je logično koristiti jedan oblik arhitekture ali jedan specifični zahtev nam namede drugu arhitekturu. Na primer, želimo da napravimo jednostavan kalkulator koji de između ostalog i da vrši konverziju iz din u evre po aktuelnom kursu. Iako je kalkulator školski primer monolitne arhitekture u ovom slučaju moramo da koristimo uslugu spoljnjeg servisa da bi saznali trenutni kurs pa de ova aplikacija imati elemente SOA arhitekture iako de vedim delom biti monolitna. Obično se izbegavaju hibridne arhitekture. Hibridna ahitektura podrazumeva da aplikacija meša arhitekture u različitim delovima. U navedenom primeru kalkulatora bilo bi najlogičnije napraviti hibridnu arhitekturu i to Monolitnu sa elementima SOA.

Monolitna arhitektura

Aplikacije sa monolitnom arhitekturom su veoma rasprostranjene. Sve velike i male desktop aplikacije uglavnom imaju monolitnu arhitekturu. Monolitnu arhitekturu je najlakše prepoznati po distribuciji koda. Ako se kompletna aplikacija izvršava na jednom računaru onda takva aplikacija najverovatnije ima monolitnu arhitekturu. Vedina desktop aplikacija koje se instaliraju na računaru su uglavnom rađene u monolitnoj arhitekturi. Ipak ovo ne mora da bude strogo pravilo pošto programeri umeju da primenjuju višeslojne arhitekture prilikom razvoja aplikacije, pa da ih na kraju zapakuju kao jednu “stand alone” aplikaciju. Prilikom izrade aplikacija sa monolitnom arhitekturom nema strogih pravila.

13

Monolitne arhitekture su najstariji oblik arhitektura aplikacije. Iako se u današnje vreme brzih internet veza i sve popularnijih SOA arhitektura monolitne arhitekture sve manje koriste one još uvek čine veliku vedinu aplikacija. Primeri monolitne arhitekture su: kalkulatori, editori, office paketi (neki od njih uvode i SOA elemente pa spadaju u hibridne arhitekture), aplikacije za ctanje i obradu slika (važi ista napomena kao i kod office aplikacija), igrice (ne mrežne),...

Dvoslojna arhitektura

Kao što smo ved napomenuli, nijedna od arhitektura nije prevaziđena i svaka od njih ima određen domen primene. Dvoslojne arhitekture su počele da se koriste pre svega za poslovnu primenu, odnosno kad imamo više umreženih računara u okviru preduzeda pa nam treba da iste podatke deli više zaposlenih. Vedina poslovnih aplikacija i danas koristi dvoslojnu arhitekturu. Dvoslojna arhitektura podrazumeva da imamo dva dela aplikacije. Jedan deo aplikacije, koji se zove Server, nalazi se na jednom računaru (serveru) i obavlja deo posla koji je zajednički za sve korisnike. Drugi deo programa se zove Client i nalazi se kod svakog korisnika koji koristi usluge Servera. Primer ovakve aplikacije bi mogao biti računovodstveni program. Na serveru se nalazi deo aplikacije zadužene za prihvatanje podataka od klijenata i za smeštanje tih podataka u bazu podataka. Prilikom zahteva klijenta server uzima podatke iz baze, vrši po potrebi obradu tih podataka i šalje ih klijentima. Server obično preuzima na sebe i posao kontrole prava pristupa klijenata. Na ovaj način su sve informacije preduzeda smeštene na jednom mestu pa nede dodi do dupliranja podataka ili do korišdenja pogrešnih ili zastarelih informacija. Klijentski deo programa na sebe preuzima posao uzimanja podataka od korisnika i prezentacije informacija korisniku. Kompletna komunikacija između korisnika i programa se obavlja preko klijentskog dela aplikacije. U klijentskom delu se obično nalazi i provera validnosti podataka koje korisnik unosi. Klijentski deo obično obavlja sve operacije vezane za grafiku odnosno prikaz podataka.

14

Slika 6: Dvoslojna arhitektura

Na Slici 6 je detaljnije prikazana dvoslojna arhitektura. Kao što se vidi, dvoslojna arhitektura u svom unutrašnjem delu krije više odvojenih komponenti – delova aplikacije. Ovo je gruba slika pravilne arhitekture dvoslojne aplikacije. Ponekad se dešava da dvoslojna aplikacija ima još delova, a u ređim situacijama manje elemenata nego što je prikazano na slici. Klijentski deo aplikacije je dosta složen i obavlja nekoliko različitih poslova. Kao što vidimo klijentski deo je zadužen za komunikaciju sa korisnikom i to oba dela, pripremu podataka za prikaz kao i uzimanje podataka od korisnika i njihovu verifikaciju. Naravno, osnovni deo svakog klijenta je renderovanje tih informacija na ekran korisnika. Klijenti obično podrazumevaju i neki složeniji sistem štampe. Ono što je karakteristično za dvoslojne arhitekture je da klijent obavlja deo biznis logike i to se u ovoj arhitekturi zove “Client application Logic”. Komunikacija između klijenta i servera se obavlja preko dela klijentske aplikacije koji je zadužen za pakovanje i slanje podataka serveru odnosno za primanje podataka od severa i raspakivanje istih. Taj deo aplikacije se zove “Client Facade” ili jednostavnije samo Facade. Serverski deo u dvoslojnoj arhitekturi ima manje poddelova. Serverska fasada ima zadatak da prima podatke od klijenata, da ih raspakuje i prosleđuje slededem delu, odnosno da ih pakuje i prosleđuje klijentu. “Server Application Logic” je deo serverske aplikacije koji obavlja svu biznis logiku koja mora da se obavi na server strani. To je onaj deo biznis pravila koji se odnosi na sve klijente. Naravno neophodno je i smeštanje podataka koje se obavlja na serveru.

15

Troslojna arhitektura

Od kad je veb postao jako popularan sve više se koristi troslojna arhitektura. Troslojna arhitektura nam dozvoljava da odvojimo aplikacioni deo aplikacije od same baze podataka. Ovo je bitno kod veb aplikacija jer baza podataka može fizički da se nalazi na drugom računaru ili domenu, odnosno na drugom kraju planete. Ovo znači da je kod aplikacije podeljen na tri dela: klijentski deo, aplikacioni server i server podataka. Aplikacioni server je deo koda koji je zadužen za logiku programa, obradu informacija dostavljenih od klijenata, prosleđivanje traženih informacija konkretnim klijentima, vođenje računa o pravima klijenata, itd. DB server ili server podataka je zadužen samo za deo smeštanja podataka i/ili uzimanje podataka. Ovaj server vodi računa o podacima i njihovom integritetu. Često ovaj server mora da obezbedi dobre performanse u obavljanju svojih operacija jer veb aplikacije često imaju veliki broj korisnika pa su performanse obrade podataka veoma bitne. Klijent u ovoj arhitekturi je obično laki klijent. Internet browser je primer lakog klijenta. On je pogodan kao klijent jer kad pravimo veb aplikaciju mi ne znamo koji operativni sistem koristi potencionalni korisnik pa shodno tome najbolje je da kao klijent koristimo nešto što je univerzalno za sve korisnike.

Slika 7: Troslojna arhitektura

16

Na slici je prikazana detaljnija šema troslojne aplikacije. Ova šema može da se razlikuje za različite implementacije troslojne arhitekture. Naravno ova šema je grublja šema koja pokazuje samo delove u okviru svakog sloja troslojne arhitekture, ali svaki sloj obično ima još specifičnih delova. Prva stvar koja nam upada u oči kod troslojne aplikacije je da se kompletna logika aplikacije nalazi na jednom mestu u delu koji smo na slici nazvali Bussines Logic. Ovo je ključni element svake troslojne arhitekture i razlog zbog čega je troslojna arhitektura najpoželjniji oblik arhitekture. Sa slike možemo da primetimo da se deo posla koji se u dvoslojnoj arhitekturi nalazio na strani klijenta sad izmestio na stranu Application Servera. To su verifikacija podataka i priprema podataka za klijenta. Iako postoje različite varijante implementacije ovog dela (često se Java skriptovima verifikacija rešava na strani klijenta) ovo je generalno posao servera u troslojnoj arhitekturi. Ako obratimo pažnju na komunikaciju u troslojnoj arhitekturi videdemo da je ona strogo standardizovana. Kod dvoslojne arhitekture komunikaciju između dva sloja rešavali smo serijalizovanim objektima, sirovim tekstom, binarnim podacima ili nekim oblikom nestandardizovanih XML protokola. Kod troslojne arhitekture komunikacija između slojeva je standardizovana. Između klijenta i Application servera je standardan HTTP protokol dok je komunikacija između Application servera i Baze podataka standardizovan SQL jezik. Ovo nam ukazuje na činjenicu da aplikacije koje imaju troslojnu arhitekturu moraju da poštuju propisane standarde. Postoji još jedan element koji je obično prisutan u troslojnim arhitekturama a vidi se i na ovoj slici. Kod ovakve raspodele obično se koriste usluge drugih aplikacija. Kao što se vidi na slici na strani klijenta se koristi usluga Internet Browsera. Na strani Application Servera se obično nalazi neki Application kontejner. Application kontejner može biti Tomcat (za Enterprise Java aplikacije), JBoss, Oracle Application Server, SUN Application server, WebSphere (IBM) ili IIS (Microsoft). Na strani servera podataka se obično nalazi neka od poznatih baza podataka: Oracle, MySQL, PostgreSQL, Sybase, itd.

Aplikacioni kontejneri

Pravljenje troslojnih aplikacija može da bude veoma komplikovano za programere pogotovu ako bi sami morali da isprogramiraju sve komunikacione protokole i pratede stvari kao što su na primer višestruki pristup korisnika, njihove sesije, itd.

17

Da bi se programerima olakšalo pisanje ovakvih arhitektura uvedeni su aplikacioni kontejneri. To su aplikacije u okviru kojih pokredemo naš kod. Kontejneri su zaduženi za implementaciju standardnih protokola, manipulaciju sa sesijama, pokretanje aplikacije na zahtev korisnika, itd. Deo koda koji programer treba da napiše u ovom sloju aplikacije se svodi na logiku aplikacije, pre svega na pravilnu implementaciju biznis logike kao i dobru pripremu podataka za klijenta i verifikaciju njegovih ulaza. Sve velike kompanije koje se bave razvojem internet tehnologija imaju svoje kontejnere. Svi oni obavljaju isti posao samo što neki nude još neke dodatne usluge i pomod pri programiranju (na primer ORM – mapiranje Java objekata na relacione baze podataka). Najpopularniji i najrasprostranjeniji aplikacioni kontejner je Apache Tomcat. S obzirom da se vedina servera na netu vrti na Apache serveru onda je logično koristiti njihov aplikacioni kontejner. Ovaj kontejner se smatra etalon Java kontejnerom. SUN micro sistem ima svoj application sever koji nije podrazumevan za Java veb aplikacije. IBM ima WebSphere, Oracle ima svoj, itd. Apache Tomcat je besplatan i “opensource” kontejner, osim njega popularan “opensource” kontejner je i JBoss.

Laki klijent vs Bogati klijent

U vedini troslojnih veb aplikacija kao klijent se koristi Internet Browser. Ovo je logičan izbor jer svi korisnici (bez obzira na operativni sistem koji koriste) imaju neki Inernet Browser. Osnovni nedostatak lakih klijenata je nemogudnost pisanja složenijeg koda. Ako koristimo lake klijente to podrazumeva da klijent radi jednostavne operacije prikazivanja podataka i uzimanje podataka od korisnika sa minimalnom ili nikakvom interakcijom sa tim podacima. Prednosti lakog klijenta su: jednostavan update aplikacije (ništa se ne menja na klijentskoj strani), nezavisnost od operativnog sistema korisnika ili od Internet Browser-a koji koristi, mogudnost prikaza bogate grafike. Nedostaci lakog klijenta su: male mogudnosti kontrole unetih podataka, ograničenost u programerskim tehnikama prilikom izrade klijenta (nemogudnost korišdenja objektnih principa), smanjene mogudnosti interakcije sa korisnikom. Bogati klijenti su obično aplikacije na klijentskoj strani koje predstavljaju samostalnu aplikaciju ili samostalnu aplikaciju koja radi u nekom generičkom kontejneru (java applet i Flash). Samostalna aplikacija može da bude bilo koja aplikacija pa čak i specifične aplikacije koje su vezane za određenu platformu. Dobar primer bogatog klijenta pisanog za specifičnu platformu može da bude GoogleTalk koji za Windows postoji kao gotova aplikacija pisana specifično za taj operativni sistem dok u slučaju drugih sistema se koriste hostujude aplikacije kao što je Gaim za Linux ili iChat za Mac OS X. Ovo je dobar primer jer se vidi da su ostali slojevi aplikacije nezavisni od samog klijenta.

18

Najčešdi izbor za bogatog klijenta je Java aplikacija ili neka podvarijanta applet ili Web Start. Web Start je tehnološki najnapredniji mada još uvek nije dovoljno rasprostranjen. Još uvek je mlada tehnologija. Web Start obezbeđuje sve prednosti bogatog klijenta bez mana koje obično idu sa bogatim klijentom. Najveda mana bogatog klijenta je težak jednovremeni update svih klijenata na novu verziju kao i obezbeđivanja jednakosti u izvršavanju bez obzira na OS. Web Start tehnologija je obezbedila dobar jednovremeni update kao i multiplatformnost baziranu na JVM. Web Start je Bogati klijent koji je unapređen da prevaziđe sva ograničenja bogatih klijenata. U praksi je pronađen i drugi put laki klijent koji je prevazišao mane lakih klijenata. Ova tehnika bogatog lakog klijenta je implementirana u AJAX tehnologiji o kojoj demo više pričati pri kraju kursa.

Višeslojna arhitektura

Arhitektura sa više slojeva označava aplikaciju koja ima pored klijenta i dva servera, još neki server ili servis. Na primer želimo da napravimo aplikaciju za popunjavanje listida sportske prognoze preko veba i pladanja sportske prognoze preko mobilnog telefona. Prvo nam treba laki klijent, server aplikacije i server podataka. Pored ove obične troslojne arhitekture neophodno je da imamo još jedan servis koji bi trebalo da bude odvojen od ovih i da može da se pokrede po potrebi na zasebnom računaru. Ovaj novi servis bi obrađivao uplate i komunicirao sa aplikativnim serverom i serverom podataka. Naravno ovo unosi još jedan sloj u našu troslojnu arhitekturu i takvu aplikaciju čini aplikacijom sa višeslojnom arhitekturom. Zbog sve vede komunikacije i raširenosti internet i mobilnih tehnologija sve češde imamo potrebe za ovakvim rešenjima. Tako da su višeslojne arhitekture sve rasprostranjenije.

SOA

Zbog sve boljih internet veza, pogotovo među serverima, sve češde se koriste usluge drugih servisa prilikom pravljenja neke aplikacije. Arhitektura gde aplikacija koristi usluge drugih za ponudu sopstvenih rešenja se zove SOA. SOA je skradenica od Service Oriented Aplication. SOA arhitektura može da se smatra specijalnom varijantom višeslojne arhitekture ili njenim nastavkom odnosno proširenjem. Ipak ovakva arhitektura ima sopstvena karakteristična rešenja koja je čine posebnom vrstom arhitekture aplikacije. Na primer, ako želimo da napravimo sopstvenu aplikaciju za predenje sportskih događaja i njihovu analizu, potrebne su nam informacije koje možemo da dobijemo od raznih servisa dostupnih na netu. Ovakva aplikacija bi imala slededu arhitekturu:

19

Klijent bi najverovatnije bio laki klijent u vidu klasičnog Internet Browser-a. Onda bismo imali Application server kao deo aplikacije koja bi bila zadužena za obradu svih podataka i analizu istih. Server podataka bi nam koristio za smeštanje podataka kako onih sirovih tako i onih obrađenih. Konačno, da bi ceo sistem mogao da bude koristan nama trebaju informacije o sportskim događajima. S obzirom da u okviru aplikacije želimo da pratimo vedi broj događaja, moramo za svaki tip sportskih događaja te informacije dobiti od odgovarajudeg servis-provajdera koje nudi uslugu davanja traženih informacija. Na taj način dobijamo SOA arhitekturu aplikacije.

SOA napomene

Arhitektura koja je najmlađa od svih pomenutih je SOA. Ona se od skoro koristi i veoma je popularna u savremenim bogatim internet aplikacijama. Prilikom kreiranja SOA aplikacije treba kreirati deo u sopstvenom kodu koji de biti zadužen za komunikaciju sa udaljenim servisom. Na ovaj način centralizujemo pristup tom servisu u okviru naše aplikacije što ima nekoliko korisnih efekata. Ako želimo da zamenimo taj servis nekim drugim potrebno je da promenimo samo taj deo koda. Ako servis promeni protokol ili format podataka potrebno je prilagođavanje obaviti samo na jednom mestu. Ovim se značajno smanjuju operacije u delu održavanja tog dela aplikacije. Ovaj pristup se zove Getaway i ima još jednu bitnu prednost. Možemo da naš Getaway zamenimo lažnim za potrebe razvoja. Pri razvoju aplikacije ponekad nije mogude koristiti usluge pravog servisa, pa bi nam u tom delu od velikog značaja bila upotreba lažnog servisa koji bi simulirao pravi. Taj lažni uvek možemo da smestimo na mesto Getaway-a. Ako pravimo sopstveni servis trebalo bi da proverimo da li postoji neki standardizovani protokol i/ili format koji se koristi za takav servis. Tela za standardizaciju intezivno usvajaju sve više standarda za komunikaciju sa servisima. Ako koristimo tuđi servis uvek treba da biramo servis koji ima standardizovanu komunikaciju. Ako oblast za koju pravimo servis nije standardizovana, najbolje je napraviti sopstveni protokol ili format baziran na XML-u, a takav XML treba dodatno obezbediti sa odgovarajudim DTD-om. Nakon toga treba izvršiti i dobro dokumentovanje protokola i/ili formata kako bi drugi mogli lako da koriste taj servis.

Razmena informacija između slojeva

Kada želimo da razmenimo informacije između klijenta i servera ili između bilo koja dva sloja u aplikaciji moramo da odlučimo na koji način demo ostvariti razmenu podataka. Kod Monolitnih aplikacija nema potrebe da razmišljamo o ovom, jer ne postoje slojevi, pa samim tim ni potrebe za razmenom informacija među slojevima. Kod aplikacija sa dvoslojnom arhitekturom ved

20

moramo da vodimo računa o načinu razmene informacija između servera i klijenta. Osnovni parametar za odlučivanje je da li su oba dela (klijent i server) pisana u istom programskom jeziku sa istim tehnologijama. Ako je ovo slučaj, onda je najjednostavniji način razmene podataka neki od oblika razmene serijalizovanih objekata. Veoma često imamo slučaj da su klijent i server ili različiti slojevi aplikacije, rađeni različitim programskim tehnikama, često od strane različitih timova, u različitim vremenskim periodima ne znajudi jedni za druge. Ovo je slučaj između aplikacionog servera i DB servera. DB server obično pišu kompanije koje se bave izradom DB servera i usluge takvog servera se koriste od strane naše aplikacije. Kada se razvijao DB server nije se znalo u kojim sve aplikacijama de biti korišden. Da bi se ipak obezbedila kvalitetna komunikacija napravljen je standardizovan jezik za opis zahteva i dostavljanje podataka koji se zove SQL. Svaka komunikacija između baze i naše aplikacije se vrši preko SQL-a. Standardizacija je veoma važan element u kreiranju kvalitetnih višeslojnih aplikacija ili SOA aplikacija. Komunikacija između lakog klijenta i servera aplikacije se u vedini slučajeva svodi na standardni HTTP protokol. Razni servisi kojih svakog dana na internetu ima sve više obično nude neku od podvarijanti XML jezika kao standard za razmenu podataka. Sirov binarni paket Serijalizovani objekti Tekstualne informacije Protokoli sa unapred definisanim formatom informacija Tekstualne informacije u strogo zadatim formatima Neki od primera standarda za razmenu informacija

◦ SQL ◦ HTTP ◦ XML ◦ …

Kako odabrati arhitekturu? Kada treba da odlučimo koju arhitekturu da koristimo obično treba prvo da razmišljamo o nameni aplikacije. Ako kreiramo običnu desktop aplikaciju onda demo najverovatnije da se opredelimo za aplikaciju sa monolitnom arhitekturom. Naravno i ovde mogu da postoje izuzeci. Recimo, ako želimo da našoj Monolitnoj desktop aplikaciji pridodamo neki internet servis, u tom slučaju kreiramo hibridnu arhitekturu. Ako aplikacija ima više korisnika koji treba istovremeno da pristupaju podacima i utiču jedan na drugog onda to znači da nam monolitna arhitektura ne odgovara. Ako aplikacija ima više korisnika postavlja se pitanje da li su oni u okviru iste fizičke mreže ili su na internetu. U slučaju da su u okviru iste fizičke mreže to znači da demo primeniti dvoslojnu arhitekturu koja je pogodnija kod intranet aplikacija. Naravno i ovde

21

postoje izuzeci. Sve više se pojavljuju zahtevi da intranet aplikaciji može da se pristupi van tog intraneta. U tom slučaju nam ne odgovara dvoslojna arhitektura. Često programeri koriste troslojne arhitekture i u okviru intraneta radi lakšeg potencionalnog širenja na internet. Ako smo se odlučili za troslojnu arhitekturu uvek vredi proveriti da li neki deo aplikacije može da se kreira kao nezavisni servis. Ako postoji takav slučaj onda bi on trebalo da se odvoji u poseban sloj. Takav servis posle može nezavisno da se koristi i za potrebe neke druge aplikacije što predstavlja dobro i fleksibilno rešenje. Takvo rešenje predstavlja višeslojnu arhitekturu. Ponekad želimo da u našoj aplikaciji koristimo servis koji postoji od ranije ili servis nekog drugog. U tom slučaju treba da se opredelimo za SOA arhitekturu.

Koraci: Odlučiti da li je aplikacija samostalna ili ima više korisnika Ako ima više korisnika da li su oni u okviru iste fizičke mreže ili su na internetu Da li imamo više nezavisnih sevisa u okviru jedne aplikacije Ako su internet korisnici, da li su nam potrebne usluge drugih servisa Postoje i hibridne varijante, recimo, Monolitna arihitektura sa upotrebom servisa.

Primer komunikacije između slojeva ili aplikacija u SOA arhitekturi

Za komunikaciju između medicinskih sistema i u okviru slojeva medicinskog sistema najbolje je

koristiti industrijske standarde za razmenu podataka. Tokom vremena kreirano je mnoštvo

takvih standarda, neki od njih su čisto medicinskog karaktera poput DICOM-a ili HL7v2

standarda za razmenu podataka, dok su neki opšteg karaktera ali su našli primenu i u medicini

poput EDIFACT-a (MEDEUR). Ovo je bilo neophodno da bi se tredi nivo razmene spojio sa

drugim, odnosno semantički sa softverskim. Evo primera jedne EDIFACT poruke:

UNB+UNOA:1+500011774+500003170+940731:2127+108E'UNH+2100+MEDEUR:1:1:IT'BGM+U

PD'DTM+137+1994:07:24'NAD+EMP+123456+Dr. Sending'NAD+ EMP+654321+Dr. Receiving'

PNA+PAT+999999+Patient name'SEQ+P+1'DTM+194+1989:10:22'CIN+DI+T90.1+ICP++Insulin

dependent Diabates Melitus'SEQ+P+2'DTM+194+1991:03:27'CIN+DI+K86.0+ICP+Primary

hypertension'GIS+C'DTM+007+1994:08:08'INV+LM+102:LOC:Glucose'REF+G3:1'RSL+N+17.2+m

mol/l'RNG+NRM+:3.5:4.5'DLI+O+0'CLI+MED+13617893:KMP::Ins mixt 10/90 novolet

Međutim savremeni standardi za razmenu podataka su otišli korak dalje i dozvoljavaju da se

osnovni način razmene podataka zasniva na nekom industrijskom standardu. Najčešde su to

VebServisi, a ispod u XML-ovima može da bude bilo koji standardizovani-struktuirani xml koji

22

predstavlja podatke odnosno semantički nivo kumunikacije između sistema. Ovakav pristup se

koristi u SOA arhitekturi. Ovakav pristup je višestruko koristan, jer mogu da se koriste bilo koji

medicinski standardi za struktuiranje i definisanje podataka koji poštuju xml specifikaciju, dok

sami veb servisi mogu da obezbede sigurnost same razmene podataka na osnovu standardnih

mehanizama poput licenci, elektronskih potpisa, ssl, itd. Primer isečka definicije medicinskih

(xsd) podataka u xml formatu:

<xs:complexType name="subjectOfCare">

<xs:complexContent mixed="false">

<xs:extension base="adminEntity">

<xs:sequence>

<xs:element minOccurs="0" name="ehrStatus" type="ehrStatus" />

<xs:element minOccurs="0" maxOccurs="unbounded" name="persons" nillable="true"

type="person" />

<xs:element minOccurs="0" name="subjectOfCareHealthData"

type="subjectOfCareHealthData" />

<xs:element minOccurs="0" maxOccurs="unbounded" name="subjectOfCareInsurances"

nillable="true" type="subjectOfCareInsurance" />

<xs:element minOccurs="0" maxOccurs="unbounded" name="subjectOfCareSocialDatas"

nillable="true" type="subjectOfCareSocialData" />

</xs:sequence>

<xs:attribute name="id" type="xs:long" />

<xs:attribute name="tempId" type="xs:string" />

</xs:extension>

</xs:complexContent>

</xs:complexType>