ITM Lekcija 3 - Projektovanje Softvera i Arhitektura Aplikacija

7/28/2019 ITM Lekcija 3 - Projektovanje Softvera i Arhitektura Aplikacija

1/22

1

INFORMACIONE TEHNOLOGIJE U MEDICINI 2012/13 LEKCIJA 3Mateja Opai

PROJEKTOVANJE SOFTVERA I ARHITEKTURA APLIKACIJAivotni ciklus softvera

ivotni ciklus softvera porazumeva korake kroz koje se prolazi svaki put kada se kreiraaplikacija bez obzira da li je mala ili velika.

Prvi korak u tom procesu je skupljanje informacija. U ovom koraku treba prikupiti to vieadekvatnih informacija kako bi se na osnovu njih mogao osmisliti softver. Sam proces

prikupljanja poataka je jako sloen i esto kritian u procesu proizvodnje softvera pa mu trebaposvetiti maksimalno panje. Ovaj korak je ujeno i prvi korak u celokupnom procesu , pa svaka

greka u ovom elu moe biti viestruko umnoena 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 uzimajo oatnihzahteva kako bi se tano efinisao zaatak.Tredi korak u ovom procesu je dizajn. Ovde se ne misli na vizuelni dizajn aplikacije ved naraspored programskog koda. Odluka o dizajnu se donosi na osnovu analiziranih prikupljenih

podataka. Dizajn aplikacije veoma zavisi od zahteva, tako a loe prikupljeni zahtevi mogu anaveu na pogrean izajn to ovoi o toga a je celokupan projekat pogreno osmiljen i ase pogreno kreira. Dizajnom se oreuju programske celine i naini programiranja.Kodiranje je korak koji podrazumeva unos programskih linija u raunar i kreiranje softvera. Iakoizglea kao najvaniji korak u procesu kreiranja softvera, on je samo jean o postojedih koraka.Samo koiranje jeste bitno i kljuno, ali nije ovoljno za uspeno kreiranje aplikacije. Jena onajvedih greaka je zapoinjanje raa na softveru o ovog koraka. Ovakvi projekti su osueni na propast.

Testiranjeje korak koji je neophoan u svakoj izrai softvera. Pogrean pristup u testiranju jea se testiranje vri tek u trenutku kaa se softver zavri. Ako se testiranje vri na ovaj nainvedina greaka u aplikaciji de biti otkrivena tek pre kraj ivotnog ciklusa razvoja softvera. Da otoga ne bi olo sve vie se koriste takozvana jeinina testiranja koja testiraju svaku kreiranuklasu i na taj nain proces testiranja poinje paralelno sa procesom koiranja, ime se rastinosmanjuje ukupan broj greaka na projektu.Instalacija, odnosno implementacija softverskog reenja je korak u kojem se softverski sistem

instalira ko korisnika. Ovaj korak je poneka prilino komplikovan pa ga treba obro pripremitii osmisliti.


2/22

2

Svaki softver mora da pretrpi odreene izmene tokom raa i zato je potrebno odravanjesoftvera. Ovaj korak je jako bitan svakom klijentu, a programeri ga esto zanemaruju.

Waterfall metod projektovanja

Postoji vie naina implementacije ivotnog ciklusa. Najjenostavnijije vodopad. On predstavljasekvencijalno poreane sve elemente koji postoje u ivotnom ciklusu softvera. Dakle , radi se odoslovnoj implementaciji ivotnog ciklusa softvera. Ovo je najstariji nain projektovanjasoftvera. Na poetku raunarske ere, kada su postojali uglavnom samo mali projekti, ovaj nain

je bio sasvim zaovoljavajudi. On je i anas koristan i funkcionalan kod malih projekata. Ako jeprojekat iole vedeg obima ovaj pristup nije aekvatan. Veliki broj projekata raenih ovommetodologijom je propao, tako a ova metoologija ima mali procenat uspenih projekata.Projekti koji su uspeno zavreni ovom metoologijom spaaju obino u projekte malog obima.Problemi u ovoj metoologiji koji ovu metoologiju ine neprihvatljivom za srednje i velike

projekte su:- Loa paralelizacija etapa: jean tim mora a eka dok drugi ne zavri svoj eo posla, kako bioni raili. Ovo ovoi o velikih gubitaka u ljuskim resursima i loe optimizacije vremenaizvravanja celokupnog projekta. Jo jena posleica ovakvog pristupa je ue vremeizvravanja projekta- Loe upravljanje rizicima: svaki projekat nosi sa sobom izvestan broj rizika. Sistem vodopad u

sebi ne sari nikakve mehanizme koji bi voili rauna o rizicima u projektu. Kao posleicuimamo da, kaa neto u projektu poe kako ne treba, obino i celokupan projekat straa.- Problemi u komunikaciji: s obzirom da je u vodopad metodologiji svaka etapa nezavisna,

obino se javlja problem kad ljudi koji rade na jednoj etapi zavise od ljudi iz druge etape koji susvoj eo posla zavrili ili jo nisu ni poeli a ga rae. Jena od analiza koja je ispitivala zatosoftverski projekti propadaju, pokazala je a je najvedi razlog propasti programerskih projekataloa ili neuspela komunikacija izmeu ljui koji uestvuju na projektu.Ovaj metod projektovanja se smatra najnefleksibilnijim od svih metoda projektovanja koji

postoje.


3/22

3

Slika 1: Waterfall metod projektovanja

Inkrementalni metod

Inkrementalni ivotni ciklus softvera se zasniva na razbijanju korisnikih zahteva na manjeceline. Te manje celine se onda nezavisno obrauju sleedim reosleom: analiza, dizajn,koiranje, testiranje i instalacija. Ieja je nastala o injenice a je voopa uspean na malimprojektima. Veliki projekat se onda izeli na vedi broj manjih i svaki za sebe se vodi kao maliprojekat. Iako je ideja dobra, ovakav nain razvoja nosi sa sobom osta problema. Osnovniproblemi 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 kojirazvijaju druge delove. Razvojem na ovaj nain moe a oe o neusaglaenosti elovaprojekta, pa iz tog razloga mogu da nastanu i bagovi i nedoslednosti u funkcionalnosti.


4/22

4

Slika 2: Inkrementalni ivotni ciklus razvoja softvera

Iterativni ivotni ciklus

Voopa je najloginiji i najjenostavniji oblik ivotnog ciklusa razvoja softvera. Iz tog razlogapostoje mnogi pokuaji a se taj sistem otera i a se uklone neostaci samo g vodopadsistema. Pore inkrementalnog postoji i iterativni pristup. Ko iterativnog pristupa se zaravavodopad princip, ali se obezbeuje vradanje na prehonu fazu po potrebi. Na ovaj nain se

obezbeuju izmene u sistemu kaa se za to pojavi potreba. Ovim se uklanja jedan od glavnihneostataka voopa sistema. Ovakav sistem je znaajno fleksibilniji o voopa sistema ali ialje zarava neke o mana voopa sistema. Glavni neostatak je odsustvo paralelnograzvoja, maa ovaj sistem omogudava a se neki elementi pojeinanih faza mogu paralelnoizvravati.


5/22

5

Slika 3: Iterativna metodologija razvoja softvera

Spiralni metod projektovanja

Za razliku o voopaa ge se ne voi rauna o rizicima, spiralni nain projektovanja je upotpunosti usmeren na rizike. Ovim nainom je eliminisan i problem naknanih izmena idopuna jer se svakim novim ciklusom mogu ubacivati nove izmene i dopune.

Spiralni razvoj porazumeva sleede: projekat se eli na vie manjih celina i to pre svega uzavisnosti od rizika. Dakle, u oreenom malom potprojektu aleko je lake efinisati moguderizike i napraviti vie reenja koja pokrivaju celu paletu problema rizika. Ovaj sistemprimenjuje Microsoft u razvoju sopstvenih aplikacija. Glavna karateristika je da dok se jedan

ciklus izvravaved poinje rugi tako a ok tee faza testiranja u jenom ciklusu u isto vremerugi ciklus moe a bue u fazi analize ili koiranja. Zbog ove karakteristike je ceo sistem idobio naziv spiralni.

Prenosti su sleede:moe a skrati vreme izrade projekta, povedana je verovatnoda na uspeh iesto je mogude primenom ovakvog sistema smanjiti trokove.Mane se ogleaju u sleedem: veoma je komplikovano uskladiti veliki broj paralelnih aktivnosti ira na razliitim elovima koa.


6/22

6

Slika 4: Spiralni metod razvoja softvera

Prototipski ciklusi

Prototipska metoologija razvoja softvera nalae a se kreira itav niz prototipova. Poinje seod osnove, odnosno od bazinog zahteva korisnika, pa se ona kreira jean prototip sam o od

tih jednostavnih elemenata. Za ovako mali projekat je dobar vodopad sistem razvoja. Nakonzavrenog prototipa, taj prototip se instalira i korisnik ustanovljava ta mu se dopada naprototipu a ta ne ina osnovu toga se kreira sleedi prototip. Mogude je i prvobitni prototip upotpunosti odbaciti i krenuti iz poetka, sa rugim izajnom i rugim zahtevima. Nakon razvoja,a esto i paralelno sa razvojem jednog malog prototipa, razvija se drugi. Ovaj sistem je idealanza projekte na kojima klijent ne zna ta tano hode. Na primer u naunim timovima ili u sluajurazvoja novih koncepata. Razvojni tim se u takvim projektima plada po utroenom vremenu, anikako po poslu.

Karakteristino za ovu metoologiju je a koristi sve raspoloive alate i programske je zike, takoa se projekat esto rai na vie programskih platformi istovremeno.

Ova metoologija se obino koristi ok se ne oe o nekog konanog skupa zahteva , a nakontoga se projekat razvija iz poetka sa nekim od standardnih metoda razvoja.


7/22

7

Extreme Programming (XP)

Ekstremno programiranje uvoi sasvim rugaiji sistem rada od do sad prikazanih. Ovde nemaelemenata ivotnog ciklusa. U ekstremnom programiranju postoji stroga metodologija rada koja

oslikava najbolju programersku praksu. Ekstremno programiranje uvodi svoje metodologije usvaki korak razvoja softvera, pri emu je glavni akcenat na prisustvu klijenta u procesu izradesoftvera, kodiranja i testiranja. Ciklusi razvoja softvera u ekstremnom programiranju su jako

kratki, oko nedelju do dve dana izmeu softverskih iteracija, to uslovljava veoma inamianrazvoj.

Ekstremno programiranje se zasniva na principu prvo testiraj onda programiraj. To bi znailoa se za oreene opcije programa prvo kreiraju ogovarajudi testovi pa se isprogramira samoono to zaovoljava te testove. U sleedem koraku se osmiljaju novi testovi koji oslikavajunovu funkcionalnost pa se kreira ko koji ispunjava ate testove. Ko se konstantno poboljavakoristedi refaktoring i dizajn paterne pri emu testovi stalno opstaju da bi osigurali da programrai ono to treba. Prilikom koiranja moraju a se potuju strogi stanari koiranja.Kod ekstremnog programiranja, prilikom kodiranja uvek su prisutna dva programera nad jednim

raunarom, poslovi se ugovaraju iskljuivopo vremenu angaovanja, zastupljeno je fiksno radnovreme, vlasnitvo nakoom je iskljuivo kolektivno i vri se konstantna integracija.

Vlasnitvo nad kodom

Na pitanje: ko de a menja ko ka je potrebno, postojinekoliko mogudih situacija:

Niko kod je izgubljen, ne postoji ili je zatiden. U tom sluaju prema kou se onosimokao prema crnoj kutiji. Ovo je najnepovoljinija situacija za programere koji treba netoda urade.

Zadnji koji je menjao na ovaj nain se obaveze izmene koa onose na onog ko jezanji vrio izmene. esto se ovaj sluaj menja u sluaj a se vlasnitvo oeli najboljemslobonom programeru. Ova situacija je takoe nezgona jer programer kome jedodeljeno da radi na kou moa nije najbolje upoznat sa situacijom u datom kodu aesto se pre njega iznose zahtevi koji zalaze uboko u izmene koa koji programer nijeradio.

Monogamijajena osoba je zauena za jean eo koa. Svaka izmena na kou moraa se proe kroz proces verifikacije o stane vlasnika koa. Ovo ima prenosti u oblikua se zna ko ta rai i ta je ija unost. U sluaju a osoba nije prisutna mora a sedodeli novi vlasnik tom kodu. Nedostatak ovog pristupa je pravo vlasnika da odbije

izmene tako da ostali moraju da nepotrebno umotavaju njegov ko ime se gubi naperformansama i kvalitetu. Takoe moa je vlasnik koa neto pogreio, pa sad krije


8/22

8

situaciju time to ne ozvoljava a se menja ono to funcionie. Takoe moe a se esia se trai a se taj ko ne menja jer mnogo rugog koa ovisi o njemu iako su izmene utom delu koda neophodne.

Iznajmljeno vlasnitvou ovoj situaciji vlasnik je privremeno zauen programer koji jenalean za taj ko ok se rai oreen zaatak. Neostatak ovakvog pristupa je to jeprogramer svestan privremenosti situacije pa se nede truiti a reava probleme nauge staze ved samo onoliko koliko mu je potrebno a zavri svoj zaatak. Ovo moeovesti o komplikovanja koa i loih reenja posle par promena vlasnika.

Vlasnitvo u lejerimau ovom sluaju vlasnitvo je poeljeno na manje timove. Svakisubtim ima pravo a pravi sve izmene u svom elu koa pri emu o tome obavetavaostale u timu. Ovo je olina taktika za kvalitet koa i za nain unapreivanja koa.Problemi su u komunikaciji izmeu subtimova i njihovih slojeva. Interfejs koji spaja dvaela (lejera) je jako teko menjati i moe a bue izvor problema.

Kolektivno vlasnitvo u ovom sluaju vlasnici su svi lanovi tima tako da svipojenako uestvuju u svim elovima koa. Dobre strane ovoga su mogudnost brzepromene programa i efikasan ra. Ali i neostaci su brojni. Moa neko ne eli a rug imenjaju njegov kod. Svako ima svoj stil programiranja, pa moe a se esi da u istomdelu koda postoji nekoliko razliitih stilova programiranja. S obzirom a su svi zaueni,lako se desi situacija a niko nije zauen onosno a niko ne eli a rai na tom elukoa, a niko nije zainteresovan a orai stvari koji depoboljati ko na ue staze, aesto moe a oe i o sukoba meu lanovima tima.

Extreme programming (XP) porazumeva kolektivno vlasnitvo na koom bez obzira naprobleme koji se javljaju. Rizici nastali o ovog principa vlasnitva mogu a se smanje na vienaina:

- Izraa testova i princip prvo test pa ona ko ne ozvoljavaju a pojeinac porem etipostojedi ko.- Lini ponos, odnosno nedozvoljavanje da drugi menjaju kod, ne postoji u ekstremnomprogramiranju jer svi moraju da rade zajedno.

- Programiranje u paru omogudava a se znanje proiruje kroz tim, a ujedno se i praviujednaeniji stil programiranja.- Promena parova u okviru koa i promena ljui koji su bili par obezbeuje a svi imaju uvi ura svakog ela koa, smanjuje se mogudnost zaglavljivanja na nekom kodu, potpomae irenjeznanja i ujenaavanjestila programiranja i potovanje dogovorenih standarda.- Konstantno refaktorovanje bi trebalo a obezbei kvalitetniji i itljiviji kod (primenjivati

refaktoring to vie).


9/22

9

- Jednostavni izajn svakog ela koa omogudava a programeri mogu brzo a uu u sutinusvakog dela koda.

- Standari pri programiranju obezbeuju a se programer lako ukljui na neki eo koa i anastavi zapoet posao.

- Konstantna integracija obezbeuje a neiji tru nije uzaluan ved a se ubacuje konstantno iproverava tako a niko nije pogoen previe.

Integracija

Kod koji je pisan o strane razliitih lanova timamoe a se integrie u razliitim trenucima:

Neposredno pre isporuke programa ovakav nain integracije je najproblematiniji. Toje sluaj ka svako rai svoj eo posla i ka je sve zavreno, pokuava se stapanje svegau jenu celinu. Ovo esto ne funkcionie: vreme koje je potrebno za integraciju naglo sepovedava, a osoba zauena za integraciju mora a reava gomilu problema. Takoe

moe a se esi a je neki lan tima pogreno shvatio svoj zaatak i da je uzaludno radionedeljama, a da se to vidi tek prilikom integracije.

Povremeno u ovoj varijanti integracija se vri u nekim trenucima kaa se vri revizijauraenog i pregle tekudeg stanja. Ovakav nain integracije se koristi a bi menaeri iinvestitori stekli sliku o trenutnom stanju stvari. Ovo je vie formalna integracija i nerazlikuje se o integracije neposreno pre isporuke, osim to su koraci izmeu veintegracije ipak kradi nego u prvom sluaju.

Dnevna integracija na kraju radnog ana se izvri integracija svega to je uraeno togana. Na ovaj nain se obezbeuje a niko ne oe prealeko o zaatog cilja bezprovere sa ostatkom tima. Ovakav princip ima i svoje loe strane to neko mora stalnoda utvruje ko je pogreio i a pronae ko treba a ispravi greku.

Konstantna integracija XP programiranje zahteva konstantnu integraciju. To znai apar koji programira integrie svoj ko u ostatak projekta par puta u toku ana. Ovo serai tako to postoji jena maina na kojoj se nalazi celokupan projekat i na kojoj se vriintegracija. Kaa programerski par zavri neku fazu sea za tu mainu i integrie svoj eoposla sa ostatkom projekta koji je zateen na maini. Ovo je olakano zahvaljujudi unittestovima koji moraju da budu zadovoljeni kada se ubaci novi deo. Svaki programerski

par na mainu stavlja ko zajeno sa test unitima (svi testovi su OK na mestu na kome supisali kod), integrie ga sa ostatkom i proverava da li svi testovi u projektu prolaze sa OK.U tom sluaju vradaju se na svoje mesto i nastavljaju sa radom. U suprotnom, neintegriu svoj eo ved ga prvo poprave (ako je potrebno pomae im neki drugi

programerski par).


10/22

10

RUP - Rational Unified Process

RUP predstavlja sistem razvoja baziran na UML procesima. Poran je od strane velikihkompanija kao to su IBM, Oracle, it. Ovaj sistem razvoja porazumeva rugaije faze razvoja

o onih vienih ko voopa sistema. Prilagoen je objektno orijentisanim programskimjezicima, mogu ga primenjivati i timovi i pojedinci i moe se koristiti i za male i za velikeprojekte.

Faze u RUP-u:

1. Inception

- Identifikacija biznis sluaja 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 sluaj.- Detaljni korisniki 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 korisnike okumentacije.- Kraj faze: Osnovna funkcionalna beta verzija softvera.

4. Transition

- Implementacija instalacija.- Obuka korisnika.

- Kraj faze: Isporuka softvera.


11/22

11

Slika 5: RUP metodologija razvoja

Arhitektura aplikacije

Postoji vie tipova arhitekture aplikacije. Svaka od ovih arhitektura je bila u nekom trenutku uistoriji otkrivena i koridena,ali ni jena o njih nije prevaziena ili izbaena iz upotrebe. Novearhitekture su otkrivane kada se pojavila potreba za oreenim oblikom aplikacije, odnosnokaa su se pojavili specifini zahtevi.Svaka aplikacija se sastoji o vedeg broja razliitih podelova, objekata u objektnimaplikacijama ili modula u modularnim. Ti delovi jedne aplikacije moraju da se raspodele u

zavisnosti o toga koji eo aplikacije treba ge a se izvrava. Vedina jenostavnih aplikacijaima monolitnu strukturu, onosno izvrava se na jenom raunaru. Ali nisu sve aplikacije kojese izvravaju na jenom raunaru monolitne. Arhitektura aplikacije zavisi o vie parametara -zahteva.


12/22

12

Namena aplikacije i postavka aplikacije povlaesa sobom nain organizacije elova aplikacije,nain raspoele programa kao i nain na koji koristimo takvu aplikaciju. Tako da namena i nainkoridenja aplikacije uslovljava koju arhitekturu aplikacije demo primeniti.Arhitektura aplikacije nije vezana za programski jezik u kom programiramo aplikaciju. Iako je u

nekim programskim jezicima lake implementirati oreenu arhitekturu, generalno govoredi,arhitektura aplikacije nije vezana za programski jezik.

Tipovi arhitekture

Postoji vie tipova arhitekture. Trenutno se koriste sleedi tipovi: Monolitna, Dvoslojna koja sejo naziva i Client-Server, Troslojna, Vieslojna i SOA (Service oriente aplication).Svaki o ovih tipova arhitekture ima svoje karakteristike i specifinu namenu. Namena aplikacijenajvie utie na to koju arhitekturu demo oabrati. Tako na primer ako elimo a pravimojednostavan kalkulator svakako demo se oluiti za monolitnu arhitekturu. S ruge strane , ako

elimo a pravimo veb portal koji de a opsluuje korisnike sa najrazliitijim informacijama osporta o berzanskih izvetaja ona demo oabrati SOA arhitekturu.Postoje naravno situacije kad namena aplikacije nije dovoljna da bi se odredila arhitektura

aplikacije, a postoje i situacije ka je logino koristiti jean oblik arhitekture ali jean specifinizahtev nam namede rugu arhitekturu. Na primer , elimo a napravimo jednostavan kalkulatorkoji de izmeu ostalog i a vri konverziju iz din u evre po aktuelnom kursu. Iako je kalkulatorkolski primer monolitne arhitekture u ovom sluaju moramo a koristimo uslugu spoljnjegservisa a bi saznali trenutni kurs pa de ova aplikacija imati elemente SOA arhitekture iako devedim elom biti monolitna. Obino se izbegavaju hibrine arhitekture. Hibridna ahitekturapodrazumeva da aplikacija mea arhitekture u razliitim elovima. U naveenom primerukalkulatora bilo bi najloginije 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 najlake prepoznatipo istribuciji koa. Ako se kompletna aplikacija izvrava na jenom raunaru ona takvaaplikacija najverovatnije ima monolitnu arhitekturu. Vedina esktop aplikacija koje se instalirajuna raunaru su uglavnom raene u monolitnoj arhitekturi. Ipak ovo ne mora da bude strogopravilo poto programeri umeju a primenjuju vieslojne arhitekture prilikom razvoja aplikacije,pa da ih na kraju zapakuju kao jenu stan alone aplikaciju.Prilikom izrade aplikacija sa monolitnom arhitekturom nema strogih pravila.


13/22

13

Monolitne arhitekture su najstariji oblik arhitektura aplikacije. Iako se u ananje vreme brzihinternet veza i sve popularnijih SOA arhitektura monolitne arhitekture sve manje koriste one jouvek ine veliku vedinu aplikacija.Primeri monolitne arhitekture su: kalkulatori, editori, office paketi (neki od njih uvode i SOA

elemente pa spaaju u hibrine arhitekture), aplikacije za ctanje i obrau slika (vai istanapomena kao i ko office aplikacija), igrice (ne mrene),...

Dvoslojna arhitektura

Kao to smo ved napomenuli, nijena o arhitektura nije prevaziena i svaka o njih imaoreen omen primene. Dvoslojne arhitekture su poele a se koriste pre svega za poslovnuprimenu, onosno ka imamo vie umreenih raunara u okviru preuzeda pa nam treba da istepodatke deli vie zaposlenih. Vedina poslovnih aplikacija i anas koristi voslojnu arhitekturu.Dvoslojna arhitektura podrazumeva da imamo dva dela aplikacije. Jedan deo aplikacije, koji se

zove Server, nalazi se na jednom raunaru (serveru) i obavlja eo posla koji je zajeniki za svekorisnike. Drugi deo programa se zove Client i nalazi se kod svakog korisnika koji koristi usluge

Servera.

Primer ovakve aplikacije bi mogao biti raunovostveni program. Na serveru se nalaz i deoaplikacije zauene za prihvatanje poataka o klijenata i za smetanje tih poataka u bazupodataka. Prilikom zahteva klijenta server uzima podatke iz baze, vri po potrebi obrau tihpoataka i alje ih klijentima. Server obino preuzima na sebe i posao kontrole prava pristupaklijenata. Na ovaj nain su sve informacije preuzeda smetene na jenom mestu pa nede odio upliranja poataka ili o koridenja pogrenih ili zastarelih informacija. Klijentski deoprograma na sebe preuzima posao uzimanja podataka od korisnika i prezentacije informacija

korisniku. Kompletna komunikacija izmeu korisnika i programa se obavlja preko klijentskogdela aplikacije. U klijentskom elu se obino nalazi i provera valinosti poataka koje korisnikunosi. Klijentski eo obino obavlja sve operacije vezane za grafiku onosno prikaz poataka.


14/22

14

Slika 6: Dvoslojna arhitektura

Na Slici 6 je detaljnije prikazana dvoslojna arhitektura. Kao to se vii, dvoslojna arhitektura usvom unutranjem elu krije vie ovojenih komponenti delova aplikacije. Ovo je gruba slikapravilne arhitekture voslojne aplikacije. Poneka se eava a voslojna aplikacija ima joelova, a u reim situacijama manje elemenata nego to je prikazano na slici.Klijentski deo aplikacije je dosta sloen i obavlja nekoliko razliitih poslova. Kao to viimoklijentski eo je zauen za komunikaciju sa korisnikom i to oba ela, pripremu podataka za

prikaz kao i uzimanje podataka od korisnika i njihovu verifikaciju. Naravno, osnovni deo svakogklijenta je renderovanje tih informacija na ekran korisnika. Klijenti obino porazumevaju i nekisloeniji sistem tampe.Ono to je karakteristino za voslojne arhitekture je a klijent obavlja eo biznis logike i to se uovoj arhitekturi zove Client application Logic. Komunikacija izmeu klijenta i servera seobavlja preko dela klijentske aplikacije koji je zauen za pakovanje i slanje podataka serveruodnosno za primanje podataka od severa i raspakivanje istih. Taj deo aplikacije se zove ClientFacade ili jenostavnije samo Facade.Serverski deo u dvoslojnoj arhitekturi ima manje poddelova. Serverska fasada ima zadatak da

prima poatke o klijenata, a ih raspakuje i prosleuje sleedem elu , odnosno da ih pakuje iprosleuje klijentu. Server Application Logic je eo 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 sveklijente. Naravno neophono je i smetanje poataka koje se obavlja na serveru.


15/22

15

Troslojna arhitektura

Od kad je veb postao jako popularan sve vie se koristi troslojna arhitektura. Troslojnaarhitektura nam dozvoljava da odvojimo aplikacioni deo aplikacije od same baze podataka. Ovo

je bitno kod veb aplikacija jer baza poataka moe fiziki a senalazi na rugom raunaru iliomenu, onosno na rugom kraju planete. Ovo znai a je ko aplikacije podeljen na tri dela:klijentski deo, aplikacioni server i server podataka. Aplikacioni server je deo koda koji je

zauen za logiku programa, obrau informacija ostavljenih o klijenata, prosleivanjetraenih informacija konkretnim klijentima, voenje rauna o pravima klijenata, it. DB server iliserver poataka je zauen samo za eo smetanja poataka i/ili uzimanje poataka. Ovajserver voi rauna o poacima i njihovom integritetu. esto ovaj server mora a obezbeidobre performanse u obavljanju svojih operacija jer veb aplikacije esto imaju veliki brojkorisnika pa su performanse obrade podataka veoma bitne.

Klijent u ovoj arhitekturi je obino laki klijent. Internet browser je primer lakog klijenta. On jepogodan kao klijent jer kad pravimo veb aplikaciju mi ne znamo koji operativni sistem koristi

potencionalni korisnik pa shono tome najbolje je a kao klijent koristimo neto to jeuniverzalno za sve korisnike.

Slika 7: Troslojna arhitektura


16/22

16

Na slici je prikazana etaljnija ema troslojne aplikacije. Ova ema moe a se razlikuje zarazliite implementacije troslojne arhitekture. Naravno ova ema je grublja ema koja pokazujesamo delove u okviru svakog sloja troslojne arhitekture, ali svaki sloj obino ima jo specifinihdelova.

Prva stvar koja nam upaa u oi ko troslojne aplikacije je a se kompletna logika aplikacijenalazi na jednom mestu u delu koji smo na slici nazvali Bussines Logic. Ovo je kljuni elementsvake troslojne arhitekture i razlog zbog ega je troslojna arhitektura najpoeljniji oblikarhitekture.

Sa slike moemo a primetimo a se deo posla koji se u dvoslojnoj arhitekturi nalazio na straniklijenta sad izmestio na stranu Application Servera. To su verifikacija podataka i priprema

poataka za klijenta. Iako postoje razliite varijante implementacije ovog ela (esto se Java skriptovima verifikacija reava na strani klijenta) ovo je generalno posao servera u troslojnojarhitekturi.

Ako obratimo panju na komunikaciju u troslojnoj arhitekturi viedemo a je ona strogostanarizovana. Ko voslojne arhitekture komunikaciju izmeu va sloja reavali smoserijalizovanim objektima, sirovim tekstom, binarnim podacima ili nekim oblikom

nestanarizovanih XML protokola. Ko troslojne arhitekture komunikacija izmeu slojeva jestanarizovana. Izmeu klijenta i Application servera je stanaran HTTP protokol ok jekomunikacija izmeu Application servera i Baze poataka standardizovan SQL jezik. Ovo namukazuje na injenicu a aplikacije koje imaju troslojnu arhitekturu moraju a potuju propisanestandarde.

Postoji jo jean element koji je obino prisutan u troslojnim arhitekturama a vii se i na ovojslici. Kod ovakve raspoele obino se koriste usluge rugih aplikacija. Kao to se vii na slici nastrani klijenta se koristi usluga Internet Browsera. Na strani Application Servera se obino nalazineki Application kontejner. Application kontejner moe biti Tomcat (za Enterp rise Java

aplikacije), JBoss, Oracle Application Server, SUN Application server, WebSphere (IBM) ili IIS(Microsoft).

Na strani servera poataka se obino nalazi neka od poznatih baza podataka: Oracle, MySQL,PostgreSQL, Sybase, itd.

Aplikacioni kontejneri

Pravljenje troslojnih aplikacija moe a bue veoma komplikovano za programere pogotovuako bi sami morali da isprogramiraju sve komunikacione protokole i pratede stvari kao to su naprimer viestruki pristup korisnika, njihove sesije, itd.


17/22

17

Da bi se programerima olakalo pisanje ovakvih arhitektura uveeni su aplikacioni kontejneri.To su aplikacije u okviru kojih pokredemo na ko. Kontejneri su zaueni za implementacijustandardnih protokola, manipulaciju sa sesijama, pokretanje aplikacije na zahtev korisnika, itd.

Deo koa koji programer treba a napie u ovom sloju aplikacije se svoi na logiku aplikacije,

pre svega na pravilnu implementaciju biznis logike kao i dobru pripremu podataka za klijenta iverifikaciju njegovih ulaza.

Sve velike kompanije koje se bave razvojem internet tehnologija imaju svoje kontejnere. Svi oni

obavljaju isti posao samo to neki nue jo neke oatne usluge i pomod pri programiranju (naprimer 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 ona je logino koristiti njihov aplikacionikontejner. 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 popularanopensource kontejner je i JBoss.

Laki klijent vs Bogati klijent

U vedini troslojnih veb aplikacija kao klijent se koristi Internet Browser. Ovo je logian izbor jersvi korisnici (bez obzira na operativni sistem koji koriste) imaju neki Inernet Browser. Osnovni

nedostatak lakih klijenata je nemogudnost pisanja sloenijeg koa. Ako koristimo lake klijente topodrazumeva da klijent radi jednostavne operacije prikazivanja podataka i uzimanje podataka

od korisnika sa minimalnom ili nikakvom interakcijom sa tim podacima.

Prenosti lakog klijenta su: jenostavan upate aplikacije (nita se ne menja na klijentskojstrani), nezavisnost od operativnog sistema korisnika ili od Internet Browser-a koji koristi,

mogudnost prikaza bogate grafike.Neostaci lakog klijenta su: male mogudnosti kontrole unetih poataka, ogranienost uprogramerskim tehnikama prilikom izrade klijenta (nemogudnost koridenja objektnih principa),smanjene mogudnosti interakcije sa korisnikom.Bogati klijenti su obino aplikacije na klijentskoj strani koje predstavljaju samostalnu aplikacijuili samostalnu aplikaciju koja rai u nekom generikom kontejneru (java applet i Flash).Samostalna aplikacija moe a bue bilo koja aplikacija pa ak i specifine aplikacije koje suvezane za oreenu platformu. Dobar primer bogatog klijenta pisanog za specifinu platformumoe a bue GoogleTalk koji za Winows postoji kao gotova aplikacija pisana specifino za tajoperativni sistem ok u sluaju rugih 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 nezavisniod samog klijenta.


18/22

18

Najedi izbor za bogatog klijenta je Java aplikacija ili neka podvarijanta applet ili Web Start.Web Start je tehnoloki najnapreniji maa jo uvek nije ovoljno rasprostranjen. Jo uvek jemlada tehnologija. Web Start obezbeuje sve prenosti bogatog klijenta bez mana koje obinoidu sa bogatim klijentom.

Najveda mana bogatog klijentaje teak jenovremeni upate svih klijenata na novu verziju kao iobezbeivanja jenakosti u izvravanju bez obzira na OS. Web Start tehnologija je obezbediladobar jednovremeni update kao i multiplatformnost baziranu na JVM.

Web Start je Bogati klijent koji je unapreen a prevazie sva ogranienja bogatih klijenata. Upraksi je pronaen i rugi put laki klijent koji je prevaziao mane lakih klijenata. Ova tehnikabogatog lakog klijenta je implementirana u AJAX tehnologiji o kojoj demo vie priati pri krajukursa.

Vieslojna arhitektura

Arhitektura sa vie slojeva oznaava aplikaciju koja ima pore klijenta i va servera , jo nekiserver ili servis.

Na primer elimo a napravimo aplikaciju za popunjavanje listida sportske prognoze preko vebai pladanja sportske prognoze preko mobilnog telefona. Prvo nam treba laki klijent, serveraplikacije i server podataka. Pored ove obine troslojne arhitekture neophono je a imamo jojedan servis koji bi trebalo a bue ovojen o ovih i a moe a se pokrede po potrebi nazasebnom raunaru. Ovaj novi servis bi obraivao uplate i komunicirao sa aplikativnimserverom i serverom podataka. Naravno ovo unosi jo jean sloj u nau troslojnu arhitekturu itakvu aplikaciju ini aplikacijom sa vieslojnom arhitekturom.Zbog sve vede komunikacije i rairenosti internet i mobilnih tehnologija sve ede imamopotrebe za ovakvim reenjima. Tako a su vieslojne arhitekture sve rasprostranjenije.

SOA

Zbog sve boljih internet veza, pogotovo meu serverima, sve ede se koriste usluge rugihservisa prilikom pravljenja neke aplikacije. Arhitektura gde aplikacija koristi usluge drugih za

ponudu sopstvenih reenja se zove SOA. SOA je skradenica o Service Oriente Aplication. SOAarhitektura moe a se smatra specijalnom varijantom vieslojne arhitekture ili njenimnastavkom onosno proirenjem. Ipak ovakva arhitektura ima sopstvena karakteristina reenjakoja je ine posebnom vrstom arhitekture aplikacije.Na primer, ako elimo a napravimo sopstvenu aplikaciju za predenje sportskih ogaaja injihovu analizu, potrebne su nam informacije koje moemo a obijemo o raznih servisadostupnih na netu. Ovakva aplikacija bi imala sleedu arhitekturu:


19/22

19

Klijent bi najverovatnije bio laki klijent u viu klasinog Internet Browser-a. Onda bismo imaliApplication server kao eo aplikacije koja bi bila zauena za obrau svih poataka i analizuistih. Server podataka bi nam koristio za smetanje poataka kako onih sirovih tako i onihobraenih. Konano, a bi ceo sistem mogao a bue koristan nama trebaju informacije o

sportskim ogaajima. S obzirom a u okviru aplikacije elimo a pratimo vedi broj ogaaja ,moramo za svaki tip sportskih ogaaja te informacije obiti o ogovarajudeg servis-provajera koje nui uslugu avanja traenih informacija. Na taj nain obijamo SOAarhitekturu aplikacije.

SOA napomene

Arhitektura koja je najmlaa o svih pomenutih je SOA. Ona se od skoro koristi i veoma jepopularna u savremenim bogatim internet aplikacijama.

Prilikom kreiranja SOA aplikacije treba kreirati eo u sopstvenom kou koji de biti zauen za

komunikaciju sa ualjenim servisom. Na ovaj nain centralizujemo pristup tom servisu u okvirunae aplikacije to ima nekoliko korisnih efekata. Ako elimo a zamenimo taj se rvis nekimdrugim potrebno je da promenimo samo taj deo koda. Ako servis promeni protokol ili format

poataka potrebno je prilagoavanje obaviti samo na jenom mestu. Ovim se znaajnosmanjuju operacije u elu oravanja tog ela aplikacije. Ovaj pristup se zove Getaway i ima jojednu bitnu prenost. Moemo a na Getaway zamenimo lanim za potrebe razvoja. Prirazvoju aplikacije ponekad nije mogude koristiti usluge pravog servisa, pa bi nam u tom delu odvelikog znaaja bila upotreba lanog servisa koji bi simulirao pravi. Taj lani uvek moemo asmestimo 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 stanarizaciju intezivno usvajaju sve vie

stanara za komunikaciju sa servisima. Ako koristimo tui servis uvek treba a biramo serviskoji 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

obezbeiti sa ogovarajudim DTD-om. Nakon toga treba izvriti i obro okumentovanjeprotokola i/ili formata kako bi drugi mogli lako da koriste taj servis.

Razmena informacija izmeu slojeva

Kaa elimo a razmenimo informacije izmeu klijenta i servera ili izmeu bilo koja va sloja uaplikaciji moramo a oluimo na koji nain demo ostvariti razmenu poataka. Kod Monolitnihaplikacija nema potrebe a razmiljamo o ovom, jer ne postoje slojevi, pa samim tim ni potrebeza razmenom informacija meu slojevima. Ko aplikacija sa voslojnom arhitekturom ved


20/22

20

moramo a voimo rauna o nainu razmene informacija izmeu servera i klijenta. Osnovniparametar za oluivanje je a li su oba ela (klijent i server) pisana u istom programskom

jeziku sa istim tehnologijama. Ako je ovo sluaj, ona je najjenostavniji nain razmenepodataka neki od oblika razmene serijalizovanih objekata.

Veoma esto imamo sluaj a su klijent i server ili razliiti slojevi aplikacije, raeni razliitimprogramskim tehnikama, esto o strane razliitih timova, u razliitim vremenskim perioimane znajudi jeni za ruge. Ovo je sluaj izmeu aplikacionog servera i DB servera. DB serverobino piu kompanije koje se bave izraom DB servera i usluge takvog servera se koriste ostrane nae aplikacije. Kaa se razvijao DB server nije se znalo u kojim sve aplikacijama de bitikoriden. Da bi se ipak obezbedila kvalitetna komunikacija napravljen je standardizovan jezik zaopis zahteva i dostavljanje podataka koji se zove SQL. Svaka komunikacija izmeu baze i naeaplikacije se vri preko SQL-a. Standarizacija je veoma vaan element u kreiranju kvalitetnihvieslojnih aplikacija ili SOA aplikacija. Komunikacija izmeu lakog klijenta i servera aplikacije seu vedini sluajeva svoi na stanarni HTTP protokol. Razni servisi kojih svakog ana nainternetu ima sve vie obino nue neku o povarijanti XML jezika kao standard za razmenupodataka.

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 odluimo koju arhitekturu a koristimo obino treba prvo a razmiljamo onameni aplikacije. Ako kreiramo obinu esktop aplikaciju ona demo najverovatnije a seopredelimo za aplikaciju sa monolitnom arhitekturom. Naravno i ovde mogu da postoje izuzeci.

Recimo, ako elimo a naoj Monolitnoj esktop aplikaciji pridodamo neki internet servis, utom sluaju kreiramo hibrinu arhitekturu. Ako aplikacija ima vie korisnika koji trebaistovremeno da pristupaju poacima i utiu jean na rugog ona to znai a nam monolitnaarhitektura ne ogovara. Ako aplikacija ima vie korisnika postavlja se pitanje da li su oni u

okviru iste fizike mree ili su na internetu. U sluaju a su u okviru iste fizike mree to znai ademo primeniti dvoslojnu arhitekturu koja je pogodnija kod intranet aplikacija. Naravno i ovde


21/22

21

postoje izuzeci. Sve vie se pojavljuju zahtevi a intranet aplikaciji moe a se pristupi van togintraneta. U tom sluaju nam ne ogovara voslojna arhitektura. esto programeri koristetroslojne arhitekture i u okviru intraneta rai lakeg potencionalnog irenja na internet. Akosmo se oluili za troslojnu arhitekturu uvek vrei proveriti a li neki eo aplikacije moe a se

kreira kao nezavisni servis. Ako postoji takav sluaj ona bi on treba lo da se odvoji u posebansloj. Takav servis posle moe nezavisno a se koristi i za potrebe neke ruge aplikacije toprestavlja obro i fleksibilno reenje. Takvo reenje prestavlja vieslojnu arhitekturu .Poneka elimo a u naoj aplikaciji koristimo servis koji postoji o ranije ili servis nekogrugog. U tom sluaju treba a se opreelimo za SOA arhitekturu.

Koraci:

Oluiti a li je aplikacija samostalna ili ima vie korisnika Ako ima vie korisnika a li su oni u okviru iste fizike mree ili su na internetu Da li imamo vie nezavisnih sevisa u okviru jene 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 izmeu slojeva ili aplikacija u SOA arhitekturi

Za komunikaciju izmeu meicinskih sistema i u okviru slojeva medicinskog sistema najbolje je

koristiti industrijske standarde za razmenu podataka. Tokom vremena kreirano je mnotvo

takvih stanara, neki o njih su isto meic inskog karaktera poput DICOM-a ili HL7v2

stanara za razmenu poataka, ok su neki opteg karaktera ali su nali primenu i u meicini

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

drugim, odnosno semantiki sa softverskim. Evo primera jene 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

Meutim savremeni stanari za razmenu poataka su otili korak alje i ozvoljavaju a se

osnovni nain razmene poataka zasniva na nekom inustrijskom standardu. Najede su to

VebServisi, a ispod u XML-ovima moe a bue bilo koji stanarizovani-struktuirani xml koji


22/22

22

prestavlja poatke onosno semantiki nivo kumunikacije izmeu sistema. Ovakav pristup se

koristi u SOA arhitekturi. Ovakav pristup je viestruko koristan, jer mogu a se koris te bilo koji

meicinski stanari za struktuiranje i efinisanje poataka koji potuju xml specifikaciju, dok

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

mehanizama poput licenci, elektronskih potpisa, ssl, itd. Primer iseka efinicije meicinskih

(xsd) podataka u xml formatu:

Documents

ITM Lekcija 3 - Projektovanje Softvera i Arhitektura Aplikacija