Univerzitet u Beogradu Fakultet organizacionih nauka, Beograd

Master rad
Razvoj JEE aplikacije primenom Ekstremnog programiranja
Kandidat: Maja Stanilović Članovi komisije: dr Siniša Vlajić, doc. dr V ladan Devedžić, red. prof. dr Zoran Marjanović, red. prof.

Mart 2009. godine

Zahvalnica
Želela bih ovom prilikom da se zahvalim svom mentoru dr. Siniši Vlajiću, na velikoj podršci, pomoći i stručnim savetima koje mi je pružio ne samo tokom izrade ovog rada, već i u trenucima života kada mi je savet bio potreban. Hvala Vam puno! Takoñe bih želela da se zahvalim roditeljima, sestri i svom dečku Aleksandru što su bili uz mene sve vreme i podržavali me. Posebno se zahvaljujem svom ocu koji me celog života bodri da istrajem u svojim ciljevima i onda kada mi je najteže.

Curr iculum Vitae
Lični podaci Prezime, ime, ime STANILOVIĆ MAJA roditelja Adresa Mihaila Bulgakova 27/10, 11000 Beograd, Srbija Telefon 011 3425 621 Mobilni: 064 22 555 22 E-mail mstanilovic@fon.bg.ac.yu Datum rodjenja: 14.04.1979. Radno iskustvo Datum Od novembra 2007. Pozicija Software developer Glavne aktivnosti I Razvoj informacionih sistema odgovornosti Spinnaker – NT, Savski Nasip 7, Beograd Od jula 2006. do novembra 2007. Stručni saradnik u sektoru za informatiku

1.

Naziv I adresa firme 2. Datum Pozicija Glavne aktivnosti I odgovornosti

Održavanje i razvoj integralnog informacionog sistema sa stanovišta softvera i hardvera, odgovornost za kvalitet i ažurnost baze podataka, odgovornost za realizaciju korektivnih i preventivnih akcija u cilju otklanjanja neusaglašenosti u delu informacionog sistema, odgovornost za realizaciju zaključaka tima za unapredjenje kvaliteta koji se odnose na problematiku integralnog informacionog sistema PERIHARD INŽENJERING DOO, Kneginje Zorke 24, Beograd, Naziv I adresa firme www.perihard.com Prozvodnja, industrijski remont toner kaseta za laserske štampače I mini fotokopir aparate I servis laserskih štampača Od 2005.

3. Datum

Pozicija Spoljni saradnik Glavne aktivnosti I Pružanje podrške odgovornosti Naziv I Fakultet organizacionih nauka, 154 Jove Ilica, Beograd, adresa firme www.fon.bg.ac.yu 4. 2003. – 2005. Datum Pozicija System administrator i inokorespodent Glavne aktivnosti I Sistem administrator, korespodencija sa inostranim partnerima odgovornosti BEL TEC DOO, Sinñelićeva 11, Beograd Naziv I adresa firme Export-import rezervnih delova za teške mašine .

Schell Brothers Spinnaker . Zvanje Diplomirani inženjer organ izacionih nauka – smer informacioni sistemi I tehnologije Naziv fakulteta Fakultet organizacionih nauka.NT 2007. Školska godina 2006.5. USA . Real Estate Information System.-2009. HIS – Hospital Information System Spinnaker .. IS Integra lnog katastra zagañivača. Univerzitet u Beogradu 2. Naziv I adresa firme www. Agencija za zaštitu životne sredine Spinnaker .com Član vodećih malih hotela u svetu Obrazovan je 1.sonnenalp. koordinacija svih aktivnosti. 20 Vail Road. Colorado. / 2007 .-2008. Naziv projekta Implementacija softvera PANTHEON (ERP rešenje) u poslovno informa cioni sistem firme Perihard Inženjering Organizacija Perihard Inženjering doo Veštine Jezici Engleski Francuski Čitanje odlično dobro Pisanje odlično osnovno Govor odličan osnovno iv iv . Datum Jul – Decembar 2002. Pozicija Spa attendan t Glavne aktivnosti I Pružanje usluga klijentima.NT 2008. Project Central. god. uspostavljanje odgovornosti kontakta I održavanje poslovnih odnosa sa klijentima (program razmene studenata) SONNENALP RESORT .NT 2007. postdiplomske studije Modul Softversko inženjerstvo Naziv fakulteta Fakultet organizacionih nauka. Vail. Univerzitet u Beogradu Projekti Datum realizacije Naziv projekta Organizacija Datum realizacije Naziv projekta Organizacija Datum realizacije Naziv projekta Organizacija Datum realizacije 2009.

Razvojna okruženja (Eclipse.) 5. COBOL. .) B kategorija Vozačka dozvola Ostali podaci Učestvovanje na seminaru “Smart e-Government 2006” International Conference and Exhibition Učestvovanje na seminaru “IDC EAS Forum Adriatics 2006” u Beogradu – ponuda I potražnja ERP rešenja Učestvovanje na konferenciji YU INFO 2007. Sistemi za upravljanje bazama podataka (MSSQL. NetBeans.Kompjuterske veštine 1.) 3. MS Access) 6. VB) 4. Programi za izradu raznih multimedijalnih sadržaja (Macromedia Dreamweaver. Društvo za informacione sisteme i računarske mreže . SQL. Objektno orijentisani i drugi programski jezici (JAVA.. Kopaonik.prezentacija rada „Implementacija ERP rešenja „Pantheon“ u Perihard Inženjeringu“ (prvi autor) v . Microsoft Office paket 2. C.. .. MySQL. C++. Jbuilder.. ERwin. Pascal. BPwin. Adobe Photoshop... . Case alati (Rational Rose.

Na kraju će biti data studija slučaja pod nazivom “Elektronska prodavnica” koja će se razviti korišćenjem Ekstremnog programiranja. Keywords: Agile methods. Further. JUnit Abstract: This paper will present Java Enterprise Edition (JEE) application development by using Extreme programming method. Prvo će biti objašnjeni osnovni pojmovi životnog ciklusa softvera. JEE platform and JUnit tools. with the emphasis on the following: a) iterative-incremental model of software life cycle. b) agilne metode životnog ciklusa softvera i c) strategiju životnog ciklusa softvera koja je voñena testovima. Nakon toga biće dat prikaz Ekstremnog programiranja kroz precizno definisan redosled faza životnog ciklusa softvera. Zatim će biti dat prikaz JEE platforme. At the end. Ekstremno programiranje. JEE platforme i JUnit alata. b) agile methods of software life cycle and c) test-driven strategy of software life cycle.Apstrakt: U ovom radu će biti predstavljen razvoj JEE aplikacije primenom metode Ekstremnog programiranja. it will be explained JUnit tool that is used for software testing. U daljem radu biće objašnjen JUnit alat koji se koristi za testiranje softvera. JUnit vi . it will be given a view of Extreme programming through precisely defined phase order of life cycle software. it will be given the case study titled "Electronic Store" which will be developed using the Extreme programming. Before all. Then. Ključne reči: Agilne metode. JEE. sa naglaskom na: a) iterativno-inkrementalni model životnog ciklusa softvera. Extreme Programming. it will be given a view of JEE platform. JEE. basic concepts of software life cycle will be given. Then.

2.2 Metode životnog ciklusa softvera 2.3 Razvoj voñen testovima (test-driven development .2.XP) 3. Responsibilities.1.4.5 Isporuka softverskog sistema 2.2 .1.TDD) 2.4.2.1 Upravljanje prema slučajevima korišćenja (use-case driven) 2.4.3 Male isporuke 3.3.4.4.3.2.4.1 Planiranje razvoja softvera u XP-u 3.4.2.2 Orijentacija ka arhitekturi (architecture centric) 2.4.4 Iterativno-inkrementalni model (fazni razvoj) 2.1 Organizacija testiranja 2.3 Životni ciklus XP-a 3.4 Testiranje programa 2.4 Aktivnosti životnog ciklusa softvera 2.4.6 Održavanje softverskog sistema 2.3 CRC kartice (Class.4. Ekstremno programiranje (Extreme programming .2.4.3 Implementacija softvera u XP-u 2 4 6 6 8 10 11 13 14 15 17 19 20 21 21 22 22 23 23 24 28 28 29 30 31 32 33 33 33 35 35 35 38 39 40 41 42 43 43 44 45 45 45 46 48 vii .2 Projektovanje (dizajniranje) sistema 2.2.3.4.1.4.4.3 Scrum 2.1 Priče korisnika (user stories) 3.3.3.1 Nastanak XP-a 3.2 Metafore sistema (Szstem Methafor) 3.1 Uvod u agilne metode razvoja softvera 2.4 Iterativni razvoj 3.2 Jedinstveni proces razvoja softvera (Unified Proces) 2.4.3 Implementacija 2.3 Strategije životnog ciklusa softvera 2.1 Larmanova metoda razvoja softvera 2.4.1.4 Stalno refaktorisanje 3.1.4.1.1 Jednostavan dizajn 3. Životni ciklus softvera 2.2.1.4.1 Prikupljanje korisničkih zahteva 2.4. Collaboration cards) 3.1.1.2 Projektovanje softvera u XP-u 3.1 Model vodopada 2.4 Postupci u XP-u kroz faze procesa životnog ciklusa softvera 3.3 Model evolucionarnog prototipa 2. Uvod 2.4.SADRŽAJ 1.4 Ekstremno programiranje (Extreme Programming .2 Planiranje isporuka (Release Planning) 3.4.2 Šta je Ekstremno programiranje? 3.2 Automatizovani alati za testiranje 2.1 Modeli životnog ciklusa softvera 2.4.1.NET platforma 2.1.2 Spiralni model 2.1 Java platforma 2.1.2.5 Sažetak 3.4.XP) 2.

3.3.3.2.4 Životni ciklus Veb aplikacije 5.1.1 Kupac na licu mesta 3.3 Java Servlet Tehnologija 5. Literatura 48 49 50 51 53 55 55 56 57 57 58 59 59 61 61 63 66 67 67 67 68 68 69 71 72 72 73 73 75 77 78 78 80 80 81 83 84 89 93 93 95 99 101 116 118 122 viii .3.2 Web aplikacija 5.3 Implementacija 6.4 Sažetak 5. JUnit alat za testiranje koda 4.1.1 Korisnički zahtevi (planiranje) 6.3 Testiranje jedinice programa pomoću okvira xUnit 3.4.3.4.4. Java platforma 5.4.4.2 Pokretanje testova 4.4.4.3.4.3.4 Sažetak 6.1.1.2.2 Testovi prihvaćenosti 3.2 Sažetak 7.4 Izvorni kod ShopCart aplikacije 6.3 Skup testova 6.3.3.3.6 Zajedničko vlasništvo nad kodom 3.2.8 40 radnih sati nedeljno 3.1 Jedinični testovi 3.3.2 Stateless i Stateful tipovi protokola 5.3 Programiranje u paru 3.3.3.2.2 Standardi u pisanju koda 3.3.1 Testiranje entiteta 6. Studijski primer 6.3 Jedinično testiranje Veb aplikacije 4.4.1.1 Osnovni koncepti JUnit-a 4.7 Optimizacija koda 3.3.4.4.4 Životni ciklus servleta 5.5 Veb modul 5.3 Sistem za upravljanje bazom podataka 5.2.5 Sažetak 4.4.2 Osnovni ciklus slučaja testiranja 4.1 Metode slanja zahteva Veb serveru 5.3.4 Pisanje jediničnih testova pre implementacije funkcionalnosti 3.3.1 Veb komponente 5.2 Planiranje 6.3 Praćenje sesije preko servleta 5.1 Slučajevi testiranja (Test Cases) 4.5 Kontinuirana integracija koda 3.4 Testiranje softvera u XP-u 3.2 Kontejner Veb komponenti 5.1.1.3.4.2.3.1 ShopCart servlet aplikacija 6.1 Uvod u JEE tehnologiju 5. Zaključak 8.4.2 Testiranje kritičnih klasa 6.

Slika 18: Interakcija izmeñu Web klijenta i Web aplikacije ……………………………………… Slika 19: Java Web aplikacione tehnologije ……………………………………………………… Slika 20 : Web modul struktura …………………………………………………………………… Slika 21: Interakcija izmeñu Web klijenta i servleta ……………………………………………… Slika 22: Uloge servlet kontejnera ………………………………………………………………... 6 7 9 10 15 16 19 25 29 30 31 34 41 43 45 47 51 54 56 57 58 59 63 64 65 66 67 68 69 70 70 71 71 72 72 73 73 73 74 74 74 74 75 77 80 82 1 . Slika 8: Koraci testiranja …………………………………………………………………………. Slika 12: Ciklus jedne iteracije u XP.Lista slika: Slika 1: Model vodopada ………………………………………………………………………….. Programeri koriste kontrolu izvornog koda i posebnu mašinu za sklapanje softvera …. Slika 6: Životni ciklus Scrum-a …………………………………………………………………… Slika 7: Proces evidentiranja zahteva ……………………………………………………………... Slika 39: CRC5_ShoppingCart …………………………………………………………………… Slika 40: CRC6_Confirmation ……………………………………………………………………... Slika 23. Slika 14.. Slika 2: Spiralni model …………………………………………………………………………….... Osnovni koncepti Junit-a ……………………………………………………………….. Produktivnost raste sa utrošenim vremenom …………………………………………… Slika 15. Vremenski okviri planiranja i povratnih veza u XP-u …………………………………… Slika 10: Životni ciklus u XP-u …………………………………………………………………… Slika 11: Praktični postupci u XP-u ……………………………………………………………….. Slika 37: CRC3_ShowCart ……………………………………………………………………….. Slika 9.. Slika 29: Katalog stranica sa novim korisnikom …………………………………………………. Tok rada testa za prihvatanje …………………………………………………………… Slika 16. Slika 44: JUnit prikazuje uspešan TestShoppingCart test ………………………………………… Slika 45: JUnit prikazuje uspešan TestOrder test ………………………………………………… Slika 46: JUnit prikazuje uspešan AllTests test …………………………………………………. Slika 32: Korišćenje CRC kartiva u fazi projektovanja softverskog sistema ……………………. Slika 30: Shopping Cart stranica …………………………………………………………………. Slika 13. Slika 26: Prikupljanje zahteva korisnika u fazi analize …………………………………………… Slika 27: Login stranica …………………………………………………………………………… Slika 28: Katalog stranica sa postojećim korisnikom ……………………………………………. Slika 33: Metafora sistema ……………………………………………………………………….. Slika 38: CRC4_ShoppingCartItem ………………………………………………………………. JUnit prikazuje neuspešan test …………………………………………………………. Slika 34: Veze izmeñu klasa ……………………………………………………………………… Slika 35: CRC1_ShopCartServletBase …………………………………………………………… Slika 36: CRC2_Catalog …………………………………………………………………………. Slika 31: stranica koja prikazuje broj potvrñene porudžbine …………………………………….. Slika 3: Model Evolucionarnog prototipa ………………………………………………………… Slika 4: Iterativni inkrementalni razvoj …………………………………………………………… Slika 5: Životni ciklus jedinstvenog procesa razvoja softvera ……………………………………... Slika 41: CRC7_Order ……………………………………………………………………………. Slika 17. Plan isporuke ……………………………………………………………………………. Slika 24: CRC kartica …………………………………………………………………………….. Slika 42: CRC8_LineItem ………………………………………………………………………… Slika 43: Faza implementacije u XP-u ……………………………………………………………...u …………………………………………………………. Slika 25: Predlog postupka razvoja softvera primenom XP postupaka …………………………..

Dati pregled JEE platforme. 3. 17]. ističe se Ekstremno programiranje (XP) [4. 2. Kao najpopularnija agilna metoda razvoja softvera. 16] koje pokušavaju da reše problem brzog tehničko-tehnološkog razvoja u oblasti softverskog inženjerstva [2. mobilne i distribuirane aplikacije. javlja se izražena potreba da se brzo odgovori na promene i neočekivane izazove u razvoju softvera. U JUnit-u se testovi brzo izvršavaju i dobija se vizuelna povratna informacija da li je test prošao ili nije. S obzirom da je Ekstremno programiranje metoda koja primenjuje strategiju razvoja softvera koja je voñena testovima. izvršavanju zadataka. koje su namenjene za rešavanje problema razvoja softvera. 19]. 12. 20]. na početku istraživanja postavljeni su sledeći ciljevi istraživanja: 1. testiranju. Uvod Usled značajnog rasta industrije vezane za Internet. 13. 4. 10. U tom smislu pojavljuje se veliki broj metoda u oblasti softverskog inženjerstva. 18] koja je predvodnica enterprise izdanja Java platforme. Meñu njima se ističu agilne metode razvoja softvera [1. kao što je EJB tehnologija [3. strategija i aktivnosti životnog ciklusa softvera. b) agilne metode životnog ciklusa softvera i c) strategija životnog ciklusa softvera koja je voñena testovima. 6. metoda. 8. Dati pregled modela. 5. U tom kontekstu se razmatra: a) iterativno-inkrementalni model životnog ciklusa softvera. Izvršiti razvoj JEE aplikacije. 15. 14. Predmet istraživanja ovog master rada je razvoj JEE aplikacije primenom metode Ekstremnog programiranja.1. koje donosi sasvim drugaciji pristup u komunikaciji sa klijentima. 9. Dati pregled JUNIT alata za testiranje softvera. Primenom Ekstremnog programiranja i tehnologija. Junit je veoma jednostavan okvir za pisanje i izvršavanje automatizovanih testova. U okviru ovog cilja definisani su sledeći podciljevi: 2 . a istovremeno povećava stabilnost sistema. složene (Enterprise) aplikacije se mogu razviti na relativno jednostavan i brz način. Dati pregled metode Ekstremno programiranje. 11. primenjuju se alati koji se koriste za testiranje softvera kao što je JUnit [7. 5. Na osnovu definisanog predmeta istraživanja. refaktorisanju i svim ostalim fazama razvoja softvera. Ovaj okvir je besplatan.

Prikazani su modeli. projektovanja softvera.1. od planiranja razvoja softvera u XP-u. U drugom poglavlju dat je pregled životnog ciklusa softvera. U šestom poglavlju prikazan je studijski primer korišćenjem XP metode razvoja softvera. Rad se sastoji iz poglavlja: U prvom poglavlju je dat Uvod koji predhodi detaljnom razmatranju tehnologija i studijskom primeru. 3 . kao i Java Servlet tehnologija.3. Objašnjeni su osnovni koncepti Junita. implementacije softvera do testiranja softvera u XP-u.5. Izvršiti testiranje softvera primenom JUnit alata za jedinično testiranje softvera. Objašnjen je životni ciklus XP-a kao i postupci u XP-u kroz faze procesa životnog ciklusa softvera. U trećem poglavlju dat je detaljan prikaz metode “Ekstremno programiranje”. kontejner veb komponenti. veb modul). metode.2. 5. U petom poglavlju dat je prikaz Java platforme. U sedmom poglavlju data su zakljuĉna razmatranja o posmatranim tehnologijama. Izvršiti razvoj JEE aplikacije primenom metode Ekstremnog programiranja u Eclipse razvojnom okruženju. Oceniti posmatranu metodu razvoja softvera u odnosu na Larmanovu metodu razvoja softvera. životni ciklus veb aplikacije. Prikazani su osnovni koncepti veb aplikacije (veb komponente. kao i jedinično testiranje veb aplikacije. strategije kao i aktivnosti životnog ciklusa softvera. 5. U četvrtom poglavlju prikazan je JUnit alat za testiranje koda.

Da bi se razumelo kako se softversko inženjerstvo uklapa u svet računarske nauke treba objasniti da se računarstvo usredsreñuje na računare i programske jezike. [19. Uredjeni skup zadataka smatra se procesom: nizom koraka koji obuhvataju aktivnosti. 46 str. Svaki haker može da napiše programski kod koji nešto radi. tako da omogućava projektovanje i izradu 4 . [1.] Proces izrade nekog proizvoda se ponekad naziva životni ciklus. preko implementacije do isporuke.2. Prilikom pružanja usluga ili izrade proizvoda uvek se sledi niz koraka kako bi se izvršio neki skup zadataka. a softversko inženjerstvo iste koristi kao alate u projektovanju i primeni rešenja nekog problema. 45 str. Proces razvoja softvera može se opisati fleksibilno. Kod softverskog inženjerstva suština je u projektovanju i razvoju visoko kvalitetnog softvera. Softversko inženjerstvo je stvaralački i postupan proces. Umesto da istražuje dizajn hardvera. Proces obično uključuje skup alata i tehnika. a rezultiraju željenim ostvarenjem. neophodno je čvrsto teorijsko i praktično razumevanje softverskog inženjerstva. operativnog korišćenja i održavanja. upotrebe. Zadaci se obično izvršavaju u istom redosledu. koji okuplja veliki broj ljudi na poslovima izrade različitih vrsta proizvoda. ograničenja i resurse. a zatim korišćenju takvih apstrakcija za projektovanje rešenja. ŽIVOTNI CIKLUS SOFTVERA Da bi se razumeo način izrade dobrog softvera. procenjivanje rizika kao i mogućnosti koje softver unosi u naš svakodnevni život. softver inženjer se usredsreñuje na računar kao sredstvo za rešavanje problema. ali su potrebni umeće i znanje profesionalnog softverskog inženjera da bi se proizveo stabilan i razumljiv kod koji se lako održava i koji efikasno i efektivno radi ono zbog čega je napravljen. Izrada dobrog softvera predstavlja „umetnost“ koja se ogleda u razumevanju načina apstrahovanja i modelovanja suštinskih elemenata problema. Zbog toga se nekada softverski razvojni proces naziva i životni ciklus softvera jer opisuje „život“ softverskog proizvoda od formulisanja.] Procesi su važni jer omogućavaju strukturisanje i konzistentno predstavljanje skupa aktivnosti. Dobra softver-inženjerska praksa mora da obezbedi da softver daje pozitivan doprinos načinu na koji živimo. jer je u današnje vreme rad softvera prisutan u svim aspektima našeg života.

Time se omogućava učenje na iskustvima ranije razvijenih projekata. 46 str. Postupak je ureñen način kombinovanja alata i tehnika u cilju izrade proizvoda (softvera). koje formuliše korisnik na neki od mogućih načina. standardi vezani za tipove uključenih zahteva i notaciju za njihovo iskazivanje. testiranje 5.softvera uz oslonac na tehnike i alate koje pojedincima više odgovaraju. Postoje ograničenja. proces može da zahteva da proverimo delove projekta pre početka procesa kodiranja. izlaze i resurse.] Na primer. 47 str. 5 . Procesi takoñe omogućavaju evidentiranje iskustava i njihovo prosleñivanje drugima. isporuka 6. Izlaz ove faze je skup zahteva. implementacija 4. Proces pomaže da se održi nivo konzistentnosti i kvaliteta proizvoda ili usluga koje različiti ljudi realizuju. održavanje Svaka faza predstavlja proces koji se može opisati skupom aktivnosti pri čemu svaka aktivnost uključuje ograničenja. [19. Provera može da se izvede neformalnim pregledom ili formalnom inspekcijom. kao početni ulaz koriste se iskazi. Proces predstavlja skup postupaka. kao što su budžet i vremenski rok za izradu dokumenta o zahtevima. od kojih je svaki postupak za sebe. Razvoj softvera obično obuhvata sledeće faze: 1. u fazi prikupljanja zahteva. projektovanje 3. definisanje korisničkih zahteva 2. Proces je složeniji pojam od postupka. dokumentovanje izrade softvera visokog kvaliteta i praćenje procesa razvoja softvera.[19.] Na primer. organizovanih tako da rezultujući proizvod zadovolji unapred postavljeni skup ciljeva i standarda. ali im je isti cilj.

ostaje u trenutnoj fazi dok ne bude spreman. [19. tj.] je prikazan model vodopada. U modelu vodopada. 136 str. [19.] Istraživači u oblasti softverskog inženjerstva predlažu različite forme takvih opisa. ne preklapaju se [16. U domenu softverskog inženjerstva opisani su mnogi modeli procesa. odnosno modele životnog ciklusa softvera sa ciljem da se utvrdi način na koji organizovanje aktivnosti unutar procesa može da dovede do efikasnijeg razvoja softverskog sistema. projekat napreduje kroz ureñenu seriju koraka od inicijalnog koncepta softvera do testiranja sistem.1. Model treba da odražava ciljeve razvoja. slika ili njihovom kombinacijom. Tokom niza godina predloženi su mnogi takvi modeli. 6 . a kao izlaz isporučeni proizvod. Izrada modela procesa i razmatranje njegovih potprocesa pomažu projektnom timu da shvati jaz izmeñu toga šta bi trebalo da bude i onoga što stvarno jeste.] Svaki model procesa razvoja softvera kao ulaz koristi specifikaciju zahteva. [16. 136 str. Prototipski model i Iterativno-inkrementalni model.------------------------------------------------------------------------------------------------------2. Ukoliko projekat nije spreman za prelazak u sledeću fazu. što znači da su dokumenti glavni radni proizvodi koji se prenose iz fazu u fazi. otkrivanje grešaka u ranim fazama razvoja i ostajanje u okvirima budžeta i formulisanih ograničenja vezanih za rokove realizacije. pomoću teksta. Na slici 1 [16. Spiralni model. 137 str. 48 str. MODELI ŽIVOTNOG CIKLUSA SOFTVERA ------------------------------------------------------------------------------------------------------------------------Svaki proces može da se opiše na različite načine. Proje kat se preis pituje na kraj u svake faze. 2. on služi kao osnova za druge.]. Iako ima pun o problema . Meñu njima najpopularniji su Model vodopada.1 Model vodopada Jedan od najstariji h modela životnog ciklusa softvera je model vodopada. kao što je izrada softvera visokog nivoa kvaliteta. 48 str. ove faze su nepovezane. da bi se odredilo da li je spreman za prelazak u sledeću fazu. U čistom modelu vodopada.1.] Model vodopada je baziran na dokumentima (document driven). efikasnije modele životnog ciklusa.

U takvim slučajevima. ili neiskusno. eliminiše veliki i čest izvor potencijalnih grešaka. Eliminacija izmena tokom implementacije. Ovaj model smanjuj e opterećenje planiranj em pošto se celo planiranje radi unapred. koju programeri žele. zato što pruža projektu strukturu koja minimizira utrošeni 7 . model vodopada može da bude pravi izvor za brz razvoj. može da iz dokumentacije koja se generiše da dobije smislene indikacije napretka kroz životni ciklus. ili konvertuje postojeći proizvod na novu platformu. On dobro radi kada zahtevi za kvalitetom dominiraju nad troškovima i vremenskim zahtevima. ali jasni. On pruža stabilnost zahteva. 136 str. zato što ima koristi od pristupanja složenosti na ureñen način. Ukoliko se pravi dobro definisana verziju za održavanje postojećeg proizvoda. model vodopada pomaže da se nañu greške u ranim fazama projekta.Slika 1: Model vodopada Čist model vodopada ostvaruj e dobre rezultate za proizvodne cikluse u kojima su stabilne definicije proizvoda i kada se radi sa dobro poznatim tehničkim metodologijama. Ne pruža opipljive rezultate u formi softvera do kraja životnog ciklusa. [16. Model vodopada radi posebno dobro ukoliko je osoblje tehnički slabo potkovano.] Model vodopada radi dobro za projekte koji su veoma veliki. ali neko ko je upoznat sa ovim modelom.

Koncept rizika je široko definisan u ovom kontekstu. Dok projekat ne doñe do testiranja sistema. i može da se odnosi na loše protumačene korisničke zahteve. već od tretiranja aktivnosti kao razjedinjenih. Mane čistog vodopada nastaju iz poteškoća da se u potpunosti specificiraju korisnički zahtevi pre početka projekta.1. Može se modifikovati tako da se faze ne preklapaju. [16. Na slici 2 [16. Spiralni model Spiralni model je definisao Barry Boehm člankom "A Spiral Model of Software Development and Enhancement" 1986. 137 str.] Prvi veliki problem sa modelom vodopada je da nije fleksibilian. Razlika je u brzini. potencijalne probleme sa performansama.] je prikazan spiralni model. [16. neće se znati da neki korisnički zahtev fali ili da je pogrešan.].]. ali je veoma teško. Moguće je ispraviti neke od glavnih nedostataka čistog modela vodopada sa relativno minornim izmenama.napor. ili godinama pre nego što se kreira gotov proizvod.2. Svaki mini projekat obrañuje jedan ili više glavnih rizika dok svi rizici nisu obrañeni. lošu arhitekturu. 142 str. 143 str. i koji razbija softverski proje kat u mini proje kte. Postoje kritike modela vodopada povodom toga što ne dozvoljava vraćanje u prethodne faze da bi se ispravile greške. itd. [16. godine [13]. Takoñe je moguće je dozvoliti više vraćanja u prethodne faze. Najveći značaj modela je eksplicitno prepoznavanje i uklanjanje rizika. tipu isporuke i povećanoj fleksibilnosti. 137 str. Potrebno je u potpunosti specificirati korisničke zahteve na početku projekta. što može da bude mesecima. probleme u osnovnoj tehnologiji. pre ikakvog projektantskog rada i pre pisanja koda. zaboraviti nešto može da bude skupa greš ka. Moguće je smanjiti naglasak na dokumentaciji. Većina slabosti u čistom modelu vodopada nastaje ne od samih aktivnosti. Spiral ni model je model životnog ciklusa softvera koji je orije ntisan na rizik.] Sve druge metodologije na neki način predstavljaju varijacije modela vodopada. vraćan je unazad je dozvoljeno. 8 . 141 str.] Ukoliko se koristi model vodopada. To nije u potpunosti tačno. 138 str. Kao što je prikazano na slici 3 [16. 2. [16. sekvencijalnih faza.

napravi se plan za obradu rizika. alte rnati va i ograničenja. 5. Određivanje ciljeva. i onda se posveti pristupu za sledeću iteraciju. Plan sledeće iteracije. 2.Slika 2: Spiralni model Osnovna ideja iza dijagrama spiralnog modela je da se počne malim koracim a u sredini. Moguće je početi projekat sa serijom iteracija za smanjenje rizika. Razvoj isporuka (deliverables) za tu iteraciju. Moguće je kombinovat i ovaj model sa ostalim modelima životnog ciklusa softvera na par različitih načina. Posvećenje pristupu za sledeću iteraciju (ukoliko postoji). i provera da li su ispravne. 3. Identifikovanje i otklan janje rizika. ispitaju se rizici. Pošto je rizik smanjen na prihvatljivu meru. 6. Ocena alternativa. 4. Svaka iteracija uključuje šest koraka: 1. moguće je završiti razvoj sa modelom vodopada ili nekim drugim 9 .

a zatim se nastavlja sa razvojem matrice prototipa na osnovu dobijene povratne informacije (feedback). Pošto je model orijentisan na rizik. ukoliko je jedan od rizika da li je moguće postići željene performanse.3. Ukoliko projekat ne može da se završi zbog tehničkih ili drugih razloga. Spiralni model u današnje vreme nije korišćen u većoj meri [14]. moguće je uključiti iteraciju protipiziranja (prototyping). spiralni model omogućava da se to zna rano. agilne metode. [16. Model evolucionarnog prototipa Model evolucionarnog prototipa je model životnog ciklusa softvera u kome se prototip razvija i razrañuje kroz različite faze životnog ciklusa softvera u cilju dobijanja kompletnog softverskog sistema. na moderne 2. i da ne košta puno. Postoje kontrolne tačke na kraju svake iteracije. brižno i znanjem potkovano upravljanje. U jednom trenutku klijent i programer se usaglašavaju da je prototip „dovoljno dobar“. 147 str. Obično se počinje razvojem aspekata sistema koji su najviše vidljivi. model u kome se koncept sistema razvija u toku života projekta. Prednosti spiralnog modela je i mogućnost hvatanja u koštac sa (gotovo neizbežnim) promenama koje razvoj softvera neizostavno nameće. Na primer. programer kompletira preostali deo posla na sistemu i isporučuje prototip kao krajnji proizvod. Ipak on utiče koncepte razvoja softvera današnjice. Zahteva savesno. Slika 3 [16. smanjuj e rizik.] ilustruje ovaj pristup: 10 . U tom trenutku.] Jedna od glavnih prednosti spiralnog modela je da se povećanjem troškova. da bi se ispitalo da li je moguće postići postavljene ciljeve. Moguće je ugra diti druge modele životnog ciklusa unu tar spiral nog modela. naročito na tzv. 142 str. Spiralni model pruža makar onoliko menadžerske kontrole koliko i tradicionalni model vodopada. Glavni nedostatak spiralnog modela je što su procene koje se tiču budžeta i plana grube na početku jer neke analize nisu završene sve dok te etape nisu prošle fazu projektovanja. on pruža rane indikatore bilo kog nepremostivog rizika.1.modelom koji nije baziran na riziku. Mana spiralnog modela je njegova složenost. Taj deo sistema se predstavlja klijentu.

[16. isporučen tržištu ili klijentima.4. vidljive znake napretka. Krajnja iteracija je potpuni proizvod. sve dok se ne prihvati Kompletiranje i isporuka prototipa Slika 3: Model Evolucionarnog prototipa Model evolucionarnog prototipa je posebno koristan kada se korisnički zahtevi često menjaju.1.] Model evolucionarnog prototipa uključuje analizu korisničkih zahteva. [5. projektovanja. 147 str. Takoñe je koristan kada programeri nisu sigurni koju optimalnu arhitekturu ili algoritme da koriste.inkrementa lni model (fazni razvoj) Koncept razvoja sistema pomoću iteracija je poznat kao iterativ no ikreme ntalni razvoj (IID. Svaka iteracija je samo-sadržani (self-contained) mini projekat sastavljen od aktivnosti poput analize zahteva. ili kada ni korisnik ni programer ne poznaju dobro oblast aplikacije. 9 str. projektovanje. Itera tivno.] 2. kada je korisnik nevoljan da definiše skup zahteva.Inicijalni koncept Dizajn i implementacija prototipa Fino podešavanje prototipa. 147 str.] 11 . [16. [16. 148 str. Cilj iteracije je dobijanj e verzije softvera koja je stabilna. ne daju se krajnjim korisnicima. Iterativni razvoj je pristup razvoja softvera u kome je ceo životni ciklus sastavljen od nekoliko sekvencijalnih iterac ija. Iterative and Incremental Development). 10 str]. Čak se ne zna ni kroz koliko iteracija je potrebno proći. što može biti od posebne važnosti kada postoji zahtev za brzim razvojem.] Glavni nedostatak modela evolucionarnog prototipa je da je nemoguće znati na početku projekta koliko vremena je potrebno da se kreira prihvatljiv proizvod. implementaciju – samo u mnogo manjim inkrementima nego tradicionalni pristupi. i koriste ih samo razvojni timovi. integrisana i testirana. iako je često korišćenje termina “iterativ ni razvoj”[5. Većina iteracija su interne. programiranja i i testiranja. Ovaj nedostatak je ublažen činjenicom da korisnik može da vidi jasne znake napretka. tj. Ovaj model daje čvrste.

]. Metode iterativno inkrementalnog razvoja predlažu priorite iteracija bazirane na upravljanju rizikom i odnosom prema klijentima [5. odnosno. ali ne haos. U moru stalnih promena. Iterativni proces je revizija i nastavak rada na prethodnom poslu. 10 str. 12 . U metodama iterativno inkrementalnog razvoja ovo se postiže pomoću sledećeg pravila [5. Iterativno inkrementalni razvoj je impleme ntiran u jedinstvenom procesu razvoja softvera (UP.] je prikazan iterativni-inkrementalni razvoj. Završeni inkrement je podsistem za koji važi da su faze analize. projektovanja i implementacije sistema završene. Scrum-u.]: “Jednom kada su zahtevi za iteraciju izabrani i radi se na njima. Inkrement je definisan kao podsistem sistema. 12 str. potrebna je tačka stabilnosti. klijenti ne mogu da ih promene”. Unified Process). Iterativ ne metode prihvataj u prome ne.XP).Slika 4: Iterativni inkre mentalni razvoj Na slici 4 [5.]. ekstremnom progra miranju (eXtreme Programming . 14 str. 10str. ostvaruje se inkreme ntalni razvoj [5. iteraciju po iteraciju. Itera cija je definisana kao prolaz preko odreñenog skupa aktivnosti. Podsistem raste inkrementalno sa novim funkcionalnostina. revidirane i testirane.

Ovaj pristup dobro funkcioniše u slucajevima kada je sistem mali. najčešca kritika upućena ovim metodama je ta da su one previše birokratske i da usporavaju ceo proces razvoja softvera. sa osnovnom namerom da povećaju predvidljivost i efikasnost razvoja softvera. Glavna odlika ovakvih sistema je dugo testiranje nakon kompletiranja odreñene funkcionalnosti [21]. Postoji širok izbor takvih okvira. projekta i načinu razmišljanja koje vlada u timu. Napomena: U ovoj tezi. sve je teže dodati nove osobine u sistem. Agilne metode razvoja softvera se javljaju kao reakcija na tradicionalne metode.2. svaki sa svojim slabostima i prednostima. u zavisnosti od različitih tehnika. ove aktivnosti najbolje opisuje fraza kodiraj i popravi (“code and fix“). Pisanje softvera se ne zasniva na planu. Veći deo softverskog razvoja karakteriše niz haotičnih aktivnosti. Povećava se broj grešaka u softveru i sve je teže ispraviti ih. poseban akcenat se stavlja na iterativno-inkrementalni model životnog ciklusa softvera koji će se primeniti u razvoju aplikacije (Elektronska prodavnica – Shop Cart). 13 . Kao odgovor na ovaj način razvoja softvera javljaju se disiplinovani procesi. Jedna metoda razvoja softvera nije uvek odgovarajuća za razvoj svih softvera. METODE ŽIVOTNOG CIKLUSA SOFTVERA ------------------------------------------------------------------------------------------------------Metoda životnog ciklusa softvera predstavlja okvir koji se koristi da se struktuira. Nalazeći inspiraciju u ostalim inženjerskim dicisplinama tradicinalne metode (planom voñene) razvijaju detaljne procese koji posebno ističu planiranje. planira i kontroliše proces razvoja softvera. organizacije.evolucionarnom upravljanju projektima (EVO. Sa povecanjem obima sistema. koji su se razvijali tokom godina. Svaka od metoda odgovara odreñenom softveru. ------------------------------------------------------------------------------------------------------2. Meñutim. a projektovanje se sastoji od veceg broja kratkoročnih odluka. ali i drugim metodama razvoja softvera. EVOlutionary Project Management) i Larmanovoj metodi životnog ciklusa softvera.

].XP) Larmanova metoda Jedinstveni proces razvoja softvera (Unified Proces .2. Moto agilnih metoda je: „prigrliti promene“ (embrace change) . Kent Beck 14 . Uvod u agilne metode razvoja softvera Agilne metode razvoja softvera primenjuju vremenski ograničen iterativni i evolucioni razvoj. programiranje – nasuprot obimnoj dokumentaciji.UP) Scrum 1 Podnaslov prve knjige o XP-u. agilne metode predstavljaju principe i postupke koji odražavaju jednostavnost. samo-upravljive timove.1. Iterativni razvoj predstavlja srž agilnih metoda. sa okolinom vezanom za mobilne aplikacije i sa distribuiranim razvojem. Glavno pitanje je šta čini razvojnu metodu agilnom? To je slučaj kada je razvoj softvera: • inkrementalan (male isporuke. Strateška tačka agilnih metoda je pokretnost. 26 str. [5. neprekidnu integraciju i drugo. komunikaciju. evolucionu isporuku i uključuju druge vrednosti 1 i postupke koji podstiču agilnost – brz i fleksibilan odgovor na promene. Dodatno.2. sposobnost za manevrisanje (maneuverability) [5.] U softverskom inženjerstvu. 25 str. lakoću. sa brzim ciklusima) • kooperativan (naručioc i razvojni tim rade neprestano zajedno u bliskoj komunikaciji) • direktan (metoda je jednostavna za učenje i modifikovanje) • prilagodljiv (u mogućnosti da se čine promene u poslednjem trenutku). adaptivno planiranje. Kao rezultat agilnog pristupa u razvoju softvera. mogu se izdvojiti sledeće agilne metode koje su definisane na načelima jednostavnosti i brzine: Ekstremno programiranje (Extreme Programming . razvoj usmeren testovima. Extreme Programming Explained: Embrace Change. agilne metode razvoja softvera minimiziraju rizik time što osiguravaju da su inženjeri koji razvijaju softver fokusirani na male jedinice posla. To je naročito važno sa današnjim rapidnim rastom industrije vezane za Internet.

15 . Za notaciju se koriste UML dijagrami. Faza analize opisuje logiĉku strukturu i ponašanje softverskog sistema (poslovnu logiku softverskog sistema). metoda ekstremno programiranje je detaljnije objašnjena (u posebnom poglavlju) u odnosu na ostale pomenute metode. Zahtevi se opisuju pomoću Modela slučaja korišćenja (Use-case Model). Larmanova metoda razvoja softvera Larma nova metoda životnog ciklusa softvera je bazirana na iterativ no inkrementalnom modelu životnog ciklusa softvera. Opis zahteva i slučajevi korišćenja 2. Najčešće se počinje tekstualnim opisom zahteva da bi se. Testiranje U prvoj fazi se formulišu zahtevi koje softver treba da ispuni.1. Primena agilnog razvoja nije do danas do kraja istražena.1. koristi upravljanj e prem a slučajevima-korišćenja (use-case driven) strategiju i objektno orijentisa nu metodu projektovanj a softvera. Slučajevi korišćenja se opisuju tekstualno i grafički. kojim se opisuje skup željenih korišćenja sistema od strane korisnika [1]. Implementacija 5.Zbog svoje važnosti za ovaj rad. taj zahtev transformisao u manje ali logički relativno nezavisne celine. Faze Larmanove metode razvoja softvera su: 1.2. Analiza 3. 2. Glavni dijagrami koji se kreiraju u fazi analize su: konceptualni model. Projektovanje 4. formiranjem slučajeva korišćenja. ugovori. U ovoj fazi se definišu učesnici u sistemu i svi slučajevi korišćenja. Očekuje se potvrda vremena. sekvencijalni dijagrami sistema.

Kao ulaz koriste se rezultati iz prethodne faze: konceptualni model i sistemske operacije i njihovi ugovori. Mada Larman podrazumeva fazu testiranja posle faze implementacije. Sistem raste dodavanjem novih funkcionalnosti sa svakim razvojnim ciklusom. Svaka klasa iz dijagrama se implementira po unapred definisanom redosledu: prvo se implementiraju klase koje ne zavise od drugih klasa. dijagrami saradnje. Izlaz iz ove faze su stvarni sluĉajevi korišćenja. projektovanja. Na osnovu objektno orijentisane analize koja je prethodila. projektovanja. implementacije i testiranja. implementacije i testiranja. Slučajevi-korišćenja tre ba da budu rangira ni. njenih klasa i metoda. razvoj se nastavlja u fazi izgradnje kroz seriju razvojnih ciklusa analize. Osnovna strategija je da se prvo izaberu slučajevi-korišćenja koji značajna utiču na osnovnu arhitekturu. U trećoj fazi vrši se projektovanje aplikacione strukture. U studijskom primeru korišćen je programski jezik Java. 16 .U ovoj fazi se definiše konceptualni model koji služi kao osnova za izradu relacionog modela i šeme baze podataka. odnosno da se testovi za klase pišu i izvršavaju uporedo sa implementacijom samih klasa. i oni sa najvišim rangom treba da se obrade u ranim razvoj nim ciklusima. pa se u svakom sledećem ciklusu implementiraju samo one klase koje zavise isključivo od već implementiranih. Poslednja faza je faza testiranja programa. Iterativ no inkreme ntalni model životnog ciklusa softvera je u ovoj metodi implementiran kroz uzastopno povećanje i usavršavanj e sistema kroz više razvoj nih ciklusa analize. dijagrami sekvenci za sistemske operacije i dijagrami klasa koji obuhvataju sve klase iz aplikacije i njihove relacije i metode. opšta preporuka je da se ove dve faze vrše paralelno. opisuje fiziĉka struktura i ponašanje softverskog sistema (arhitektura softverskog sistema). Četvrta faza je faza implementacije. Posle preliminarne faze planiranja i razrade. ili da se izaberu slučajevi-korišćenja sa najvećim stepenom rizika. pri čemu je realizacija studijskog primera data korišćenjem Servlet tehnologije. obrañivanjem domenskih i uslužnih slojeva visokog nivoa. Izlaz iz faze je program.

koristi strategije upravljanj e prem a slučajevima-korišćenja (use-case driven) i orijentacij e ka arhitekturi (architecture centric).2. Za prosečne projekte.2. U toku razvojne faze pravi se plan projekta. Za notaciju se koriste UML dijagrami.]: Početna faza definiše opseg projekta i viziju krajnjeg proizvoda. 17 . 174 str. razvoj – usavršavanje (elaboration). SK se razrañuju i daje se nacrt arhitekture sistema. vremenski ograničenim (timeboxed) iteracijama.] Jedinstveni proces ohrabruje veoma mali stepen formalizma.]: Razvoj u kratkim. Prilagoñavanje promenama rano u projektu. izdavanjem nekoliko verzija koje mu se isporučuju. Razvoj visoko rizičnih i elemenata sa visokom vrednošću (na primer. vremenski ograničene iteracije je izmeñu dve i šest nedelja [5. preferirajući ponovno korišćenje (re-use) postojećih komponenti. iako u opštem smislu preporučuje više dokumentacije i modeliranja nego u drugim metodama koje koriste model iterativno inkrementalnog razvoja.1. 180 str. osnovna arhitektura) u ranim iteracijama. kao i objektno orije ntisanu metodu proje ktovanj a sof tvera. 173 str.2. Neke od ključnih praksi i smernica jedinstvenog procesa razvoja softvera su sledeće [5. Jedinstveni proces razvoja softvera (Unified Proces) Jedinstveni proces razvoja softvera je metoda bazirana na iterativ no inkreme ntalnom modelu životnog ciklusa softvera. grañenja (construction) i prelaz (transition) [5. 100 str. Usresreñenost članova tima na timski rad. preporučena veličina. Ovde se navode osnovni slučajevi-korišćenja (SK). Faze su detaljnije definisane u [5. Jedinstveni proces razvoja softvera (JPRS) se sastoji iz četiri faze: početak (inception).]. Osigurava stvaranje vrednosti klijentu.

Nakon ispravke uočenih problema pravi se generalni riliz. Na taj način se dolazi do Beta Verzije Riliza (BVR). Slika 5: Životni ciklus jedinstvenog procesa razvoja softvera 2 Riliz (release) označava jednu verziju isporučenog softverskog proizvoda 18 . 2 Na slici 5 [5.U fazi grañenja dobija se kompletan softver koji se pridružuje do arhitekture sistema.] je prikazan životni ciklus jedinstvenog procesa razvoja softvera. U prelaznoj fazi BVR se prosleñuje do korisnika radi testiranja. 180 str. sa naglaskom na aktivnosti i svrhu faza. U prelaznoj fazi se obučavaju korisnici.

Kao takva. implementacija. projektovanje. Dnevni. Ona naglašava menadžerske aspekte razvoja softverskog projekta.]. Scrum Scrum je metoda životnog ciklusa softvera koja je bazirana na iterativ no inkrementalnom modelu životnog ciklusa softvera.] je prikazan životni ciklus scrum-a.3. ANALIZA (PRE-GAME) PLANIR ANJE SVRHA: POBUðIVANJE (STAGING) SVRHA: RAZVOJ ISPORUKA SVRHA: .marketing i prodaja .]: Samo-upravljivi i samo-organizijući timovi.dokumentovanje . lako se može kombinovati sa ili biti dopuna drugim metodama [5.trening .istraživačko dizajn i prototipovi AKTIVNOSTI: .operativno razvijanje .identifikacija kor. 113 str. nasuprot pristupu gde se naglasak stavlja na standardnim fazama životnog ciklusa softvera (prikupljanje korisničkih zahteva.dnevni sastanci .implemetacija sistema u iteracijama od 30 dana SVRHA: .2.2. .istraživački dizajn prototipovi AKTIVNOSTI: . analiza. budžeta i procenjivanje stavki .utvrñivanje vizije.izveštavanje Slika 6: Životni ciklus Scrum-a 19 . „stojeći“ (stand-up) sastanci na kojima se postavljaju pitanja ključna za razvoj softvera Iteracije obično traju 30 – kalendarskih dana Adaptivno planiranje.planiranje svake iteracije i procene . usmereno na klijenta (client-driven) Na kraju svake iteracije klijentu se isporučuje verzija Na slici 6 [5. 109 str.1.pisanje vizije. 111 str. zahteva i očekivanja i obezbeñivanje definisanje prioriteta za prvu potrebnih finansijskih iteraciju sredstava AKTIVNO STI: . testiranje i održavanje).planiranje AKTIVNOSTI: . sa naglaskom na aktivnosti i svrhu faza. Neke od ključnih praksi i smernica scrum-a ilustruju njegovu suštinu [5.

Kupac na terenu 12. refaktorisanje . Namenjena je relativno malim projektnim timovima.2. Stalno refaktorisanje 7. obično je rok isporuke softvera manji od godinu dana. Programiranje u paru 8. Planiranje igre 2.2. Jednostavan dizajn 5.XP) Ekstremno programiranje (XP) je dobro poznata agilna metoda. jednostavnost. Stalna integracija 10. Komponente sistema se više puta dnevno ugrañuju. brzo razvijanje softvera i postupke veštog razvoja softvera. Pored iterativno-inkrementalnog modela razvoja softvera. Zasniva se na sledećim vrednostima: komunikacija. Metafore sistema 4. Ova metoda naglašava brzo kreiranje visoko – kvalitetnog softvera.]: 1. Standardi u kodiranju Ekstremno programiranje je kreirao Kent Beck 1996. 137 str. Male. XP metoda životnog ciklusa softvera je bazirana na iterativ no inkreme ntalnom modelu životnog ciklusa softvera (IID). Zahvaljujući tome. Testiranje 6. naglašava saradnju. Kolektivno vlasništvo koda 9. a da se pritom ne promeni očigledno ponašanje sistema. Iteracije su kratke – od jedne do tri nedelje [5. Ekstremno programiranje (Extre me Program ming . XP primenjuje razvoj voñen testovima (test-driven development).1. programiranje u paru i stalnu integraciju koda. programeri mogu sa više samopouzdanja da 4 3 3 4 Poboljšanje dizajna postojećeg koda. godine kao način prevazilaženja problema i spašavanja projekta C3 (Chrysler Comprehensive Compensation). tehnike veštog i održivog razvoja softvera i fleksibilan odgovor na promene. povratna sprega i hrabrost. preporučuje dvanaest postupaka koji predstavljaju srž XP-a [5. 139 str.4. stalne isporuke 3. 20 . Radna nedelja od 40 sati 11.].

a istovremeno da razvijaju kvalitetan kod [5. programeri i menadžeri formiraju tim koji radi u projektnoj sobi (project room) gde brzo razvijaju softver. za razliku od tradicionalne funkcionalne specifikacije koja je odgovarala na pitanje: Šta sistem treba da radi? To znači da su potrebe korisnika u osnovi specifikacije sistema.i team-oriented). klijenti. STRATEGI JE ŽIVOTNOG CIKLUSA SOFTVERA ------------------------------------------------------------------------------------------------------Pored modela. veliki uticaj na životni ciklus softvera imaju strateški pristupi ovom procesu. Upravljan je prema slučajevima-korišćenja (use-case driven) Slučaj korišćenja (SK) je deo funkcionalnosti sistema koji korisniku daje neki rezultat (vrednost). orijentacij a ka arhitekturi (architecture centric) i razvoj voñen testovima (test-driven development).3. ------------------------------------------------------------------------------------------------------------------------- 2. Primenom ove metode životnog ciklusa softver razvijaće se aplikacija (Elektronska prodavnica) i detaljno će biti objašnjena u posebnoj glavi ove teze. Napomena: U ovoj tezi. XP je veoma usmeren na komun ikaciju i tim (communication. 139 str. strategij e životnog ciklusa softvera. Model SK odgovara kod specifikacije sistema na sledeće pitanje: Šta sistem treba da radi za svakog korisnika. čak i kasnije u projektu.]. tj. 21 . To znači da SK opisuju funkcionalne zahteve.odgovore na promene korisničkih zahteva. poseban akcenat se stavlja na Ekstremno programiranje. Neke od strategija životnog ciklusa softvera su: upravljan je prem a slučajevima-korišćenja (use-case driven). Svi SK zajedno čine model SK koji opisuje kompletnu funkcionalnost sistema.

ASS pored toga obuhvata: platformu na kojoj se izvršava softver (kompjuterska arhitektura. kada se realizuju. ali osnovno je da test koji se jednom verifikovao mora da se iznova verifikuje. SK moraju. 5 2. Slučajevi korišćenja (SK) se razvijaju zajedno sa sistemskom arhitekturom. Refaktorisanjem se taj kod dalje prečišćava i pojednostavljuje..SK istovremeno iniciraju i povezuju kompletan proces razvoja softverskog sistema.). SK upravljaju sistemskom arhitekturom dok sistemska arhitektura utiče na selekciju SK.TDD) Test Driven Development je tehnika razvoja softvera koja podrazumeva stalno i prevashodno testiranje napisanog koda. 22 . znači da se sistemska arhite ktura u toku razvoja softvera koristi kao glavni artifakt za konceptualiz aciju. pri svim sledećim izmenama. upravljanje i razrađivanje sistema. Veza izmeñu SK i arhitekture se može objasniti na sledeći način: Svaki proizvod ima funkciju i oblik(form) koji moraju biti izmeñu sebe povezani. raspoložive komponente koje se mogu ponovo koristiti(npr: okvir za grafički korisnički interfejs). operativni sistem.Kod razvoja arhitekture prvo se kreira onaj deo arhitekture (platforma) koji je nezavisan od SK. DBMS.3. Test se piše pre koda. konstruk ciju. Arhitektura i SK moraju da se razvijaju paralelno. sistem nasleña (legacy system). dok oblik korespondira sa arhitekturom. To znači da se pomoću SK proizvoda. da se ugrade u arhitekturu. protokoli za mrežnu komunikaciju). Arhitektura mora da obezbedi prostor da se u nju ugrade svi sadašnji a po mogućnosti i budući SK. implementacijom i testiranjem softevrskog Orije ntaci ja ka arhitekturi (architectu re-ce ntric ) Arhitektura softverskog sistema(ASS) obuhvata najvažnije statičke i dinamičke aspekte sistema. prenosivost. nefunkcionalne zahteve (performanse. Funkcija korespondira sa SK.. projektovanjem. Zatim se arhitektura razvija zajedno sa SK koji predstavljaju ključne funkcije razmatranog sistema..3 Razvoj voñen testovima (test-driven development . a nakon toga se piše izvorni kod koji treba da zadovolji test. upravlja analizom. Osim takvog 5 U kont ekstu životnog ciklusa softvera.

jer će se primeniti u razvoju aplikacije (Elektronska prodavnica). kao što su na primer principi „Keep It Simple.1 Prikupljanje korisničkih zahteva Zahtev predstavlja izraz željenog ponašanja. Napomena: U ovoj tezi. 143 str. Cilj faze definisanja zahteva je razumevanje problema i potreba naručioca. [19. stanjima u kojima oni mogu biti. dizajn može biti jasniji i čistiji nego što se to obično može postići nekom drugom metodom. Testovi korisnosti i korisničkog interfejsa se takoñe izvode kod klijenta. TDD brzo daje povratnu vezu (feedback).jediničnog testiranja (unit test). TDD zahteva da programeri prvo napišu test case koji ne prolazi. kako bi bili sigurni da test zaista radi ispravno i da može da uhvati grešku. 2. Bavi se objektima ili entitetima. postoje i funkcionalni testovi kroz test primere. bez izražavanja kako će to ponašanje biti ostvareno. testiranje. kao aspekt Ekstremnog programiranja. Zahtevi označavaju kakvo ponašanje naručilac želi. ali poslednjih godina zaokuplja veću pažnju. implementacija. isporučivanje. [19] Postoje razni aspekti TDD razvoja. Ova tehnika je počela da privlači pažnju početkom 2000-te. projektovanje (dizajniranje). Fokusirajući se samo na kod koji mora da zadovolji test. odnosno test slučajeve (test case) koje izvodi sam klijent.4. Stupid“ (KISS). kao i funkcijama koje se izvode radi promene stanja ili osobina objekta. poseban akcenat se stavlja na strategiju životnog ciklusa softvera koja je voñena testovima.] 23 . i „You Ain’t Gonna Need It“ (YAGNI). ------------------------------------------------------------------------------------------------------AKTIVNOSTI ŽIVOTNOG CIKLUSA SOFTVERA ------------------------------------------------------------------------------------------------------Proces razvoja softvera obuhvata 5 faza: specifikacija zahteva. održavanje sistema.

što pomaže da se bolje razume zahtevano ponašanje. Tokom validacije proverava se da li specifikacija odgovara onome što naručilac želi da vidi u finalnom proizvodu. 143 str. SRS) koja se koristi za komunikaciju sa drugim članovima razvojnog tima.4.Slika 7: Proces evidentir anja zahteva Na slici 7 [19. o tome kako konačni proizvod treba da se ponaša. Priroda rešenja može da se menja i u toku opisa ili implementacije. koji rade na projektovanju.2. Kada se postigne dobro razumevanje zahteva. testiranju i održavanju. što dovodi do ponovnih poseta naručiocu i revidiranje modela i specifikacije. mogu da nastanu zbog 24 . Modifikacije ne moraju biti rezultat hira. nastavlja se izradom specifikacije u kojoj se odlučuje koji će delovi zahtevanog ponašanja biti implementirani u softveru. Proj ektovan je (dizajniranje) sistema Sledeći korak u razvoju je prevoñenje želja klijenata u rešenje: projektovanje koje će zadovoljiti potrebe klijenta. Analitičar zahteva prvo radi sa naručiocima na izvoñenju zahteva (postavlja pitanja. Projektovanje je kreativni proces pretvaranja problema u rešenje. ispituje aktuelno ponašanje ili demonstrira slične sisteme). a zatim dolazi rešenje problema koje zadovoljava sve zahteve i specifikacije. Specifikacija zahteva definiše problem. 2.] je prikazan proces evidentiranja zahteva za softverski sistem. Nakon toga zahteve evidentiramo u sklopu modela ili prototipa. Krajnji ishod je specifikacija softverskih zahteva (Software Requirements Specification. Aktivnosti analize i validacije mogu da otkriju probleme ili propuste u modelu ili specifikaciji. To nije nista neobično ni nerazumno.

kako je softver rastavljen i organizovan u komponenete – i da opiše interfejse izmeñu ovih komponenti.] Sistem se u konceptualnom dizajnu opisuje jezikom koji klijent razume. u kojoj se analiziraju korisničkih zahtevi da bi se dobio opis interne strukture softvera koja će služiti kao osnova za njegovu konstrukciju. rezultat projektovanja softvera mora da opiše softversku arhite kturu – tj. pogled. a u tehničkom „kako“ radi. On mora da opiše i komponenete na nivou detalja koji omogućava njihovu konstrukciju. Kada klijent odobri konceptualni dizajn. ulaze u sistem i izlaze iz njega. komunikacione interfejse. Prvo se pravi konceptualni dizajn ili dizajn sistema koji opisuje klijentu tačno šta će sistem da radi. Konceptualni dizajn se odnosi na funkcije sistema. Jedna od podela notacija je na one koje opisuju strukturni.promenjenog doživljaja ili potrebe. projektovanj e softvera (software design) je aktivnost inženjerskog životnog ciklusa softvera. [19. mrežnu arhitekturu i sve ostalo čime se zahtevi prevode u rešenje klijentovog problema. nasuprot onima koje opisuju ponašanje. 3-1] Arh itekturalno projekt ovanj e softvera (poznato i kao “projektovanje na vrhu” (toplevel design) ili makro arhitektura): opisuje najvišu strukturu i organizaciju i identifikuje različite komponente Detaljno projektovanj e softvera (poznato i kao mikro arhitektura): dovoljno opisuje svaku komponentu da bi bilo moguće da se ona konstruiše Prilikom projektovanja za beleženje glavne projektantske odluke koje su donešene koriste se različite notacije i jezici. 3-1] Projektovanje softvera sastoji iz dve aktivnosti koje se nalaze izmeñu analize korisničkih zahteva i konstrukcije softvera: [6. Dizajn je iterativni proces koji se sastoji iz dva dela. 25 statični . Opis sistema može da se menja tokom ciklusa razvoja. Opisuje se „šta“ sistem radi. Klijent često zajedno sa projektantima menja zahteve i posle okončanja početne analize zahteva. dok tehnički dizajn opisuje oblik sistema. tj. Konceptualni dizajn omogućava klijentu da shvati šta će sistem raditi tako što objašnjava vidljive spoljašnje karakteristike sistema. dinamični pogled. dok tehnički dizajn opisuje konfiguraciju hardvera. Gledano kao proces. tj. softverske potrebe. Preciznije rečeno. [6. tehnički dizajn koji omogućava graditeljima sistema da utvrde koji će hardver i softver biti potrebni za rešenje klijentovog problema. 224 str. on se prevodi u detaljniji dokument.

klasifikacije. nasleñivanja. specifikovanje ili za dokumentovanje problema. Objektno orijentisani razvoj softvera zaslužuje posebnu pažnju zato što veliki broj novih sistema koji se danas razvijaju delimično ili potpuno prihvata objektnu orijentaciju. ima svojstvena stanja i ponašanja. 3-5]: funkcionalno-orijentisano proje ktovanje . zavisnost i implementacija) i proširenjima (ograničenja. i dijagramima stanja koji ilustruju stanja sistema i prelaze stanja. a posebno za dokumentovanje proizvoda procesa projektovanja. generalizacija. Ona se može prepoznati na osnovu svojih sedam karakteristika: identiteta. Za projektovanje softvera koriste se metode proje ktovanj a softvera koje predstavljaju specifične strategije. Dinamički prikaz se izvodi putem slučaja korišćenja. [19. Statički prikaz se definiše na osnovu dijagrama klasa sa njihovim vezama (asocijacija. [19. kao jedinstvena prepoznatljiva celina.] Ident itet postoji jer objekat.] 26 . 288 str. ključne vrednosti). učaurenje (enkapsulacije). spiska aktivnosti. apstrakcije. koje omogućava meñusobno razlikovanje objekata. Koristi se za opisivanje različitih varijanti projektnih rešenja. i koje predlažu i pružaju skup notacija koje se koriste sa metodom (kao opis procesa koji bi trebalo koristi prilikom praćenja metode. Neke od metoda projektovanja softvera su [20 str. projektovanj e orije ntisano ka strukturama podataka (DataStructure-Centered Design) i proje ktovanj e bazirano na komponentama. dijagrama interakcije koji modeluju saradnju objekata i sekvence u obavljanju aktivnosti. Svaki objekat u OO sistemu sadrži ime (referenca ili “hendl”). polimorfizma i perzistencije (trajanja). objektnoorije ntisano proje ktovanje . i skup smernica za korišćenje metode). Može da se koristi za vizualizaciju. UML je popularna notacija za opisivanje OO (Object Oriented) rešenja. Objektna orijentacija predstavlja skup objekata koje karakteriše odreñena struktura i ponašanje.UML (Unified Modeling Language) je često korišćen u obe vrste notacije. 286 str.

OO sistem karakteriše učaurenje. stanje i ponašanje objekta se čuvaju prilikom njegove transformacije. ime. gde vrednosti atributa omogućavaju da se konkretni objekti meñusobno razlikuju. [19. koja sama ne instancira objekte već se oni instanciraju jedino kao objekti podklasa. 288 str.] 27 . Svaki primerak poseduje vlastite vrednosti atributa (koji opisuju njegovo stanje) ali sa ostalim primercima iste klase deli imena atributa i ponašanja. Ponašanje je akcija ili transformacija koju vrši objekat ili koja se nad njim vrši.” [19. [19. Moguće je da se isto ponašanje različito manifestuje kod različitih klasa ili podklasa i ta osobina se naziva polimorfizam.] Klasifikacija se koristi u OO razvoju softvera za grupisanje objekata sa zajedničkim svojstvima i ponašanjem.] Klase se mogu organizovati u hijerarhiju na osnovu sličnosti ili razlika. 291 str. 288 str. pri čemu ta hijerarhija definiše strukturu nasleñivanja.] Može se zaključiti da klasa opisuje skup objekata sa zajedničkom strukturom i ponašanjem.] Svaki objekat neke klase predstavlja primer ak (instancu) te klase. Klasa vrši učaurenje ponašanja i atributa objekta i sakriva implementacione detalje.Apstra kcija je bitna za izgradnju svakog sistema. bez obzira da li je OO ili ne. U cilju pojednostavljenja hijerarhije koristi se apstraktna klasa . a da se pri tome vidi ono što želimo da bude vidljivo. stanje i ponašanje objekta opstanu u vremenu i prostoru. Klasi se dodeljuju atributi (struktura) i operacije (ponašanja). odnosno. [19. Apstrakcije u OO sistemu omogućavaju da se predstave različiti aspekti sistema koji je predmet projektovanja. Podklasa može da nasleñuje i strukturu i ponašanje nadreñene klase. 290 str. Persistentnost (trajno st) je sposobnost da ime. Berard (2000) ističe da je učaurenje tehnika za pakovanje informacija na takav način da se sakrije ono što treba da bude sakriveno. Polimorfizam omogućava dodavanje nove klase bez promene postojećeg koda. [19. 290 str.

28 . kako bi proverili da li su scenariji pravilno implementirani. . Softverske platforme uključuju arhitekturu. operativni sistem ili programski jezik i njihove izvršne (runtime) biblioteke. U ovom radu se napominju Java implementacione tehnologije sa akcentom na Java platformu. Zatim programeri pišu kod kojim implementiraju scenarije i to redosledom kojim su kupci postavili prioritete. odnosno piše se program koji implementira dizajn. sledi implementacija tog rešenja u obliku softvera. Iz tog razloga je opisana odreñena filozofija programiranja kod ekstremnog programiranja.3. koristeći formu scenarija da opišu način funkcionisanja sistema. Java programski jezik je razvijen kao odgovor na izazov razvoja aplikacija u heterogenom i distribuiranom okruženju.2. Kupci predstavljaju korisnike budućeg sistema. Java platforma Predstavlja naziv za skup Java tehnologija čiji je proizvoñač Sun Microsystem. QNX. U ovom radu predmet istraživanja je implementacija on-line prodavnice primenom metode ekstremnog programiranja. MFC i druge. Programeri moraju da procene koliko će trajati kodiranje svakog scenarija kako bi kupci mogli da planiraju testove prihvatanja. Oni izvršavaju sledeće aktivnosti: definišu svojstva koja će programeri da implementiraju. 2.3. Implementacija Kada se shvati problem kupaca i korisnika i formuliše opšte rešenje.NET. VxWorks. dodeljuju prioritete scenarijama i njihovom testiranju.4. U ekstremnom programiranju postoje dve vrste učesnika: kupci i programeri.4.1. opisuju detaljne testove koji će se izvršavati kada softver bude spreman. Neke od softverskih platformi su Java.

Java API je zbirka različitih gotovih programskih komponenti koje programeru nude mnoge korisne mogućnosti.NET kategoriju. koje spadaju u . Od Decembra 2006. tako da se Java programi mogu izvršavati na svim OS. [2.NET je Microsoftov odgovor na Sanovu Java platformu. tekuća verzija Java Platforme je 1.0 ili 6. 5 str. U toku interpretiranja bajt programskog koda JVM proverava validnost programa (da nije došlo do kvara u programu) i bezbednost njegovog aktiviranja. Implementiran je kompajler sa skupom standardnih biblioteka za različiti hardver i operativne sisteme.JVM).NET okvir (Framework).6.NET proizvoda NET Passport (šifru) 29 . . nego virtualnoj mašini. komponentu operativnog sistema koju zahtevaju većina . Platforma nije posebno namenjena nijednom procesoru ili operativnom sistemu. Java kompajler konvertuje Java izvorni kod u bajt programski kod (posredni jezik za Java Virtualnu Mašinu . Microsoft proizvodi i komponente.] Postoje sledeća izdanja Java platforme: Java Standard Edition ili Java SE (J2SE) namenjen za desktop mašine Java Micro Edition ili Java ME (J2ME) namenjen za priručne ureñaje (smart phones) Java Enterprise Edition ili Java EE (J2EE) namenjen za web servise Zbog svoje važnosti. uključuju: Microsoft .2.Java platforma sadrži dve komponente: Java Virtuelnu Mašinu (JVM) i Java Application Programming Interface (Java API). Bajt programski kod se interpretira pomoću JVM. jer on sadrži naredbe koje prepoznaje JVM i koje se preslikavaju u naredbe konkretnog operativnog sistema.NET obuhvata veliku kolekciju Microsoftovih proizvoda i tehnologija.4. 2. Java Enterprise Edition – Java EE).3. Java EE platforma je opisana u posebnom poglavlju (poglavlje 3.NET platforma . Microsoft . na primer za implementaciju grafičkog interfejsa.

meñutim upravo suprotno tome. Upravlja izvršenjem programa koji su specijalno napisani za taj okvir. Bez obzira koliko su programeri vešti u pisanju programa. 366 str. zbog raznolikosti mogućih otkaza treba proveriti da li su komponente ispravno kodirane.]. programi se testiraju da bi se dokazalo postojanje grešaka. Krajem 2000 godine prva beta verzija .NET okvira kasnih 90-ih pod imenom Next Generation Windows Services (NGWS).4.0 je razvijena.FCL) Slojevi koji se nalaze iznad CLR predstaljaju . Microsoft je započeo razvoj .NET Framework je softverska komponenta koja može biti dodata ili je deo Microsoft operativnog sistema.NET Framework Class Library koji omogućava brz razvoj softverskih aplikacija.NET Framework) su: Zejednički jezik u fazi izvršavanja (Common language runtine . U tabeli 1. Prepoznavanje grešaka je postupak utvrñivanja zbog koje greške.NET 1.CLR) Biblioteke klasa (Framework Class Library . su prikazane samo neke od baznih klasa.]. i obrada izuzetaka. 366 str. ili grešaka. CLR omogućava postojanje virtualne mašine. CLR takoñe omogućava i druge bitne servise kao što su mehanizmi sigurnosti (zaštite). Mnogi programeri posmatraju testiranje kao dokaz da njihovi programi ispravno rade. test se smatra uspešnim samo ako se greška otkrije ili ako doñe do otkaza u toku testiranja. 30 . Framework Class Library ima preko 5000 klasa. potrebno ih je testirati kako bi se kupcima isporučili kvalitetni softverski sistemi. Pošto je cilj da se greška otkrije. tako da programeri ne moraju da uzimaju u obzir mogućnosti CPU-a pri izvršavanju programa. Osnovni delovi . Test iranje programa Kada se kodiraju programske komponente. Ispravljanje grešaka ili otklanjanje grešaka je postupak unošenja izmena u sistem u cilju otklanjanja grešaka [19. upravljanje memorijom (memory management).4. je došlo do otkaza [19.NET okvira (. 2.Microsoft .

logiku i granične uslove za ulazne i izlazne podatke [19. Kada se obavi završni test. Integrac iono test iranje je postupak provere da li sistemske komponente sarañuju kao što je opisano u specifikacijama dizajna sistema i programa. Kao rezultat dobija se funkcionalni softverski sistem. 371 str.2. testiranje zahteva više faza. Prvo se zasebno testira svaka programska komponenta. 31 . Takoñe. u kojem se proverava usklañenost sistema sa opisom zahteva kupca.] su predstavljeni koraci testiranja. [19. Kada se završi jedinično testiranje skupa komponenti. Na slici 8 [19. sledi provera da li su interfejsi izmeñu komponenti pravilno definisani i realizovani.4. 371 str. [19. 372 str.1 Organizacija testiranja Kada se razvija veliki sistem. tim za testiranje proverava unutrašnju strukturu podataka. Kada se to testiranje uspešno obavi u stvarnom radnom okruženju kupca. Test iranj em performanse sistem se poredi sa ostatkom hardverskih i softverskih zahteva.]. zajedno sa kupcem se obavlja završni test prihva tanja.]. u skladu sa dizajnom komponente. Konačni instalacioni test potvrñuje da li sistem i dalje ispravno funkcioniše. nezavisno od ostalih delova sistema. U sledećem koraku. prihvaćeni sistem se instalira u okruženje u kome će se koristiti. 372 str. Funkcionalnim testiranjem se proverava da li integrisani sistem zaista izvršava funkcije opisane u specifikaciji zahteva.].4. 371 str. Takvo testiranje modula (jedinično testiranje) proverava da li pojedinačne komponente ispravno funkcionišu sa svim očekivanim tipovima ulaza. dobija se validiran sistem [19. i da posmatra izlazne akcije i rezultate.]. Jedinično testiranje treba vršiti u kontrolisanom okruženju tako da tim za testiranje može komponenti koja se testira da predaje unapred definisan skup podataka. Funkcionalni test predstavlja poreñenje sistema koji se gradi sa funkcijama zahteva kupca.

i treba proveriti da li su odgovarajući dogañaji potpuni i konzistentni. Tokom testiranja treba obratiti pažnju na probleme u vezi sa konkurentnim radom i sinhronizacijom. 45-54 str. 32 .Slika 8: Koraci testiranja Smith i Robson [7. editorima teksta i alatima za simulaciju i modelovanje da bi se automatizovao što je moguće veći deo procesa testiranja.2. klase. klastere (grupe objekata koji sarañuju i meñusobno utiču jedni na druge) i sistem kao celinu. alatima za analizu koda. mernim alatima.4. Alati se često povezuju sa bazom podataka za testiranje. bez kojih sistem ne bi bio temeljito testiran. S obzirom na veličinu i složenost većine današnjih sistema. alati za automatizovano izvršavanje testova su bitni jer omogućavaju veoma veliki broj slučajeva za testiranje. Alati za izvršavanje testova mogu da se integrišu sa drugim alatima radi izgradnje okruženja za sveobuhvatno testiranje. Automat izovani alati za testiranje Postoje mnogi automatizovani alati za testiranje koji pomažu prilikom testiranja komponenti. 2.4.] smatraju da bi testiranje objektno-orijentisanih sistema trebalo da obuhvati mnoge različite nivoe: funkcije.

Ljudi iz održavanja vode računa o proizvodima procesa razvoja. i. nije isto utvrditi da greška postoji i pronaći samu grešku. iterativno-inkrementalni model). Takoñe se moraju predvideti stvari koje mogu da krenu loše. Sistem prati dokumentacija kojoj se korisnici obraćaju za rešavanje nastalih problema ili za dalje informacije. model evolucionarnog prototipa.6. Detaljno su 33 . Održavanje softverskog sistema Sve aktivnosti vezane za izmenu sistema posle njegovog uvoñenja u eksploataciju smatraju se da pripadaju fazi održavanja[1.]. Predmet istraživanja u ovom radu je JUnit automatizovani alat za testiranje. Kod razvoja sistema tim je usredsreñen na izradu koda koji zadovoljava postavljene zahteve. Održavanje sistema se razlikuje od razvoja sistema. JUnit predstavlja open source okvir za testiranje. koje je napisao Kent Beck (SUnit). JUnit je nastao na osnovu originalnog okruženja za testiranje u SmallTalku. spiralni model. Isporu ka softverskog sistema Dva ključna pitanja pri uvoñenju softverskog sistema su: obuka i dokumentacija. planira se i razvijaju se sredstva koja će pomoći korisniku da koristi taj sistem. Prikazani su modeli životnog ciklusa softvera (model vodopada. Zbog svoje važnosti. Ovo okruženje omogućava ogromnom broju Java programera da lako testiraju svoje komponente.Meñutim. Zatim su prikazane metode životnog ciklusa softvera. uspostavljajući spregu sa korisnicima i operaterima da bi utvrdili kako su oni zadovoljni načinom rada sistema. 2. Testiranje će uvek zahtevati ljudski trud u traženju izvora za svaki problem. Kada se projektuje sistem. razmotriti izmene funkcionalnosti koje su posledica izmena u poslovanju i sagledati izmene sistema koje su posledica izmene hardvera.5. 2. ali takoñe i o sadašnjosti. softvera ili interfejsa. koji se koristi sa programskim jezikom Java. 499 str. 2. za ovaj rad najbitniji.5 Sažetak U ovom poglavlju dat je prikaz životnog ciklusa softvera. ali ne može da zameni ovu čovekovu funkciju. Automatizacija pomaže.4. JUnit je opisan u posebnom poglavlju (peto poglavlje).4.

objašnjene agilne metode razvoja softvera: Larmanova metoda, Jedinstveni proces razvoja sofvera, Scrum i Ekstremno programiranje. Objašnjene su zatim strategije životnog ciklusa softvera (upravljanje prema slučajevima korišćenja, orijentacija ka arhitekturi i razvoj voñen testovima, kao najbitnija strategija za ovaj rad). Na kraju ovog poglavlja prikazane su aktivnosti životnog ciklusa softvera: prikupljanje korisničkih zahteva, projektovanje softverskog sistema, implementacija, testiranje, isporuka softverskog sistema i održavanje softverskog sistema. Na taj način smo realizovali prvi cilj istraživanja (Dati pregled životnog ciklusa softvera).

34

3. EKSTREMNO PROGRAMIRANJE (Extreme Programming - XP)
”Lako je imati komplikovanu ideju. Veoma je teško imati jednostavnu ideju ” - Carver Mead

3.1. Nastanak XP-a
Ekstremno programiranje nije bilo prva metoda agilnog razvoja softvera. Ipak, XP popularizuje i omasovljava upotrebu agilnih metoda. Ekstremno programiranje je kreirao Kent Beck 1996. godine kao način spašavanja projekta C3 (Chrysler Comprehensive Compesation). Iako je ovaj projekat na kraju otkazan, Ron Jeffries, Ward Cunningham i Kent Beck su ovu metodu preradili u javnoj diskusiji na Cunninghan-ovom Portland Pattern Repository wiki sajtu koji je ujedno i prvi wiki sajt. Godine 1999. izlazi Beckova knjiga „Extreme Programming Explained“. Danas, sve veći broj softverskih kompanija prelazi na ekstremno programiranje. U svakom konkretnom slučaju i za svaki pojedinačni zahtev, softverska kompanija se može drugačije organizovati, jer ekstremno programiranje ne predstavlja krutu metodu, već dozvoljava taktičke izmene u proceduri izvoñenja pojedinih aktivnosti. Zajedničko za sve je korišćenje obaveznih praktičnih preporuka. Čak i sprovoñenje praktičnih preporuka (praksi) podleže adaptacijama, zavisno od potrebe.

3.2. Šta je Ekstremno programiranje?
Ekstremno programiranje (XP) je dobro poznata agilna metoda; naglašava saradnju, brzo razvijanje softvera i postupke veštog razvoja softvera. Zasniva se na sledećim vrednostima: komunikacija, jednostavnost, povratna sprega i hrabrost. Pored iterativno-inkrementalnog modela razvoja softvera, preporučuje dvanaest postupaka koji predstavljaju srž XP-a [5, 137 str.]:

35

1. Planiranje igre 2. Male, stalne isporuke 3. Metafore sistema 4. Jednostavan dizajn 5. Testiranje 6. Stalno refaktorisanje 7. Programiranje u paru 8. Kolektivno vlasništvo koda 9. Stalna integracija 10. Radna nedelja od 40 sati 11. Kupac na terenu 12. Standardi u kodiranju XP metoda životnog ciklusa softvera je baz irana na iterativ no inkreme ntalnom modelu životnog ciklusa softvera (IID). Ova metoda naglašava brzo kreiranje visoko – kvalitetnog softvera, tehnike veštog i održivog razvoja softvera i fleksibilan odgovor na promene. Namenjena je relativno malim projektnim timovima; obično je rok isporuke softvera manji od godinu dana. Iteracije su kratke – od jedne do tri nedelje [5, 139 str.]. XP primenjuje razvoj voñen testovima (test-driven development), refaktorisanje , programiranje u paru i stalnu integraciju
7 6

koda. Zahvaljujući tome, programeri mogu sa više samopouzdanja da

odgovore na promene korisničkih zahteva, čak i kasnije u projektu, a istovremeno da razvijaju kvalitetan kod [5, 139 str.]. XP je veoma usmeren na komun ikaciju i tim (communication- i team-oriented); klijenti, programeri i menadžeri formiraju tim koji radi u projektnoj sobi (project room) gde brzo razvijaju softver koji sadrži visoku poslovnu vrednost. XP ne teži detaljima, osim kada su u pitanju programski kod i testovi. Naglašava usmenu komunikaciju u fazama prikupljanja korisničkih zahteva i projektovanja. Na primer, korisnički
6 7

Poboljšanje dizajna postojećeg koda, a da se pritom ne promeni ponašanje sistema. Komponente sistema se više puta dnevno ugrañuju.

36

Sa ovako postavljenim temeljom.] Na slici 9 [22] su prikazani vremenski okviri planiranja i povratnih veza u XP-u: Slika 9. a kada počne faza projektovanja.zahtev “pronaći najnižu cenu putarine” se rukom zapisuje na indeksiranim karticama (story card). Vremenski okviri planiranja i povratnih veza u XP-u 37 . XP teži brzom razvoju softvera izbegavajući detaljnu dokumentaciju o korisničkim zahtevima. Oni održavaju svoj dizajn jednostavnim i čistim. [5. Ali to se kompenzuje stalnim prisustvom klijenta u projektnoj sobi gde se usmenom komunikacijom razrañuju detalji korisničkog zahteva. 140 str. “ Postoji znatan skup postupaka (practices) u XP-u: 12 postupaka koji čine srž XP-a i više pomoćnih. Isporučuju sistem klijentima što je ranije moguće i implementiraju tražene promene. Dobijaju povratnu informaciju testirajući softver od prvog dana.]. Mnogi od ovih postupaka funkcionišu u sinergiji i rizično je ukloniti neki elemenat. 141 str. XP programeri komuniciraju sa svojim klijentima i saradnicima. radeći puno radno vreme [5. programeri saznaju detalje korisničkog zahteva kroz razgovor sa klijentima u projektnoj sobi. jednostavnošću. XP konsultant Don Wells objašnjava uticaj XP-a na razvoj softvera [18]: „XP poboljšava softverske projekte na četiri suštinska načina: komunikacijom. povratnom spregom i hrabrošću. Na primer. XP programeri su u stanju da hrabro odgovore na promene korisničkih zahteva i tehnologije.

3. potrebno je vratiti se na korak 3. Održavanje (meintenance) – ako softver nije spreman za isporuku.]): 1. Beleže se zahtevi korisnika najvišeg nivoa na karticama (story cards). nezadovoljstvo ljudi. U ovoj fazi se procenjuje koliko ljudske energije i napora je potrebno uložiti za procenjene zadatke. Životni ciklus XP-a Beck definiše odreñene karakteristike životnog ciklusa razvoja softvera u XP-u (slika 10 [5. Iteracije do prve isporuke (iterations to first release) – testiranje i razvoj sistema. smanjenje produktivnosti i kvaliteta. neprekidno sarañujući sa korisnicima (u okviru zajedničke projektne sobe) na testiranju i detaljima njihovih zahteva. s obzirom da XP ne dozvoljava da radna nedelja traje duže od 40 radnih sati (8 sati dnevno). Uvoñenje u proizvodnju (productionizing) – programeri implementiraju priče u okviru dogovorenog perioda. na sledeću iteraciju. Planiranje (planning) – definisanje prioriteta u radu. Korisnici i programeri kompletiraju Priče korisnika zabeležene na karticama (story cards) i odlučuju šta treba raditi za sledeću isporuku. To ukazuje na nefunkcionalnost projekta. procenjenih zadataka. pravi se tehnički prototip. odnosno vrši se podela na isporuke i definiše prvi plan. 4. Programeri onda razbijaju priče na više manjih. a to vodi ka mogućem ponovnom usklañivanju izabranih korisničkih priča.3. 38 . 2. Istraživanje (exploration) – početak projekta. Korisnici biraju priče koje će se implementirati prema definisanim prioritetima. 142 str. 5.3.

.Utvrñivanje datuma i . .Dokumentovanje . Postoji još jedan aspekt praktičnih postupaka koji odlikuje XP..Obuka Planning .Utvrñivanje ostvarljivosti.Release Planning Game Aktivnosti: .Pisanje korisničkih priča procenjivanje na karticama i procenjivanje . 39 . ispravka . U pitanju je najbolja praksa koju su prepoznali softverski inženjeri.ISTRAŽIVANJE PLANIRANJE ITER ACIJE DO PRVE ISPORUKE UVOðENJE U PROIZVODNJU ODRŽAVANJE Svrha: Svrha: Svrha: Svrha: Svrha: . Na taj način se slabosti odreñene preporuke prevazilaze.Operativan razvoj . Aktivnosti: .4. (bitnijih) isporuka .Marketing . testiranog sistema . Aktivnosti: .Ako je potrebno ponavljanje faza.Prototipovi Aktivnosti: . Opšta praksa je da se postupci primenjuju do krajnjih granica.Implementacija procenjene priče korisnika priča za prvu isporuku.Testiranje i programiranje .Poboljšavanje.Izgradnja većih spremnog za isporuku za prvu isporuku. Postupci u XP-u kroz faze procesa životnog ciklusa softvera XP ima 12 praktičnih postupaka koje opisuju način na koji tim razvija sistem. Ono što je novo je upotreba postupaka na usaglašen način.Pisanje korisničkih priča na karticama i .definisanje radnih zadataka i procenjivanje Slika 10: Životni ciklus u XP-u 3.Dovoljno dobro .Iteration Game Aktivnosti: . koji se meñusobno dopunjuju. za inkrementalne isporuke.

40 .4.1.).3. bez toga projekat može da propadne. testovi klijenata Kupac na licu mesta Jedinično testiranje Programiranje u paru Kolektivno vlasništvo koda Upravljanje projektom Planiranje igre (Planiranje isporuke) Kratke isporuke Upravljanje promenama Stalna integracija Zajednička soba Radna nedelja od 40 sati „stojeći“ (standup) sastanci Planiranje igre (Planiranje isporuke) Slika 11: Praktični postupci u XP-u Na slici 11 [5.1.) odnosno podelu isporuka na iteracije i planiranje iteracije (3.2. planiranje isporuke na nivou čitavog projekta (3.1.).5. 146 str.4.4. 3.1.).4.] su predstavljeni glavni praktični postupci (practices) u XP-u kroz faze procesa životnog ciklusa softvera.).4. važnost čestih i malih isporuka (3. Svi ovi praktični mehanizmi moraju biti motivisani i voñeni vrednostima.1.1.4. Planiranje razvoja softvera u XP-u Planiranje razvoja softvera uključuje akcije prikupljanja zahteva koji se oblikuju u priče korisnika (User Stories) (3.Korisnički zahtevi (planiranje) Planiranje isporuka Kupac na licu mesta Metafore sistema Projektovanje Stalno refaktorisanje Jednostavan dizajn Test prihvaćenosti softvera Implementacija Stalno refaktorisanje Standardi u kodiranju Test iranje i verifikacija Test prihvaćenosti softvera. iterativni razvoj (3.4.1.

jedino što nisu ograničene opisom korisničkog interfejsa (user interface). Dakle. Idealno vreme razvoja označava koliko vremena je potrebno za implementaciju priče korisnika. dve ili tri nedelje procene u "idealnom vremenu" razvoja. Priče korisnika (User Stories) Priče korisnika (User Stories) imaju isti cilj kao i slučajevi korišćenja (Use Cases). Potrebno je da se kreira jedan ili više automatizovanih testova prihvaćenosti softvera kako bi se verifikovale priče korisnika. Takoñe. proverilo da li su priče korisnika ispravno implementirane. Priče korisnika piše naručioc (customer) softvera kao zahteve koje softverski sistem treba da zadovolji.1. Programer procenjuje koliko dugo (vremenski) će trajati implementacija pojedine priče korisnika. postoji potreba da se razlike bolje objasne. Najveća razlika je u stepenu detalja. ali zapravo nisu isto. U kreiranju procena učestvuje i naručioc. Druga bitna razlika izmeñu priča korisnika i dokumentacije zahteva.4. programeri od naručioca dobijaju detaljan opis zahteva. odnosno slučajeva korišćenja je fokus na potrebe naručioca.1.3. Svaka priča korisnika će oduzeti jednu. Kada doñe vrieme za implementaciju priče. Priče korisnika vode ka kreiranju tzv. koriste se umesto obimne dokumentacije zahteva (requirements document) koje softver treba da zadovolji. Priče korisnika treba da daju dovoljno detalja kako bi se izvršila procena relativno niskog rizika koja ukazuje na to koliko dugo će trajati implementacija te priče korisnika. Period kraći od jedne nedelje znači premalo detalja. Zbog čestog nerazumevanja razlika izmeñu priča korisnika (user stories) i slučajeva korišćenja (use cases). 41 . Slične su korisničkom scenariju. testa prihvaćenosti (Acceptance Test) softvera kojeg potvrñuje naručioc. razlikuju se od slučajeva korišćenja. druge obaveze. ukoliko ne postoje neke prepreke. Koriste se da bi se planirala isporuka softvera (Release Planing). Treba kombinovati nekoliko priča korisnika u jednu. po svojim karakteristikama. Period duži od tri nedelje znači da bi priču korisnika trebalo podeliti u više manjih delova. pa je tačno poznato šta i kako treba raditi. odnosno.

XP dozvoljava da se menja domen ali fiksira ostale promenljive. Suština planiranja isporuke za razvojni tim je da procene svaku priču korisnika. jer kupci žele da budu sigurni da je ubačeno sve što žele i što bi mogli da požele u budućnosti. Poštovanje skupa pravila omogućava definisanje vremenskog plana kojeg svako iz tima može ispuniti. ali dodatna sredstva u projekat ne dovode obavezno do pokrivanja nedostataka. Domen – standardna procedura pri razvoju softvera predviña da se u razvoj kreće tek nakon što se svi slože o domenu proizvoda. Cena – kupac treba da finansira razvoj do procenjenog nivoa. tako da kupac što pre dobije povratnu informaciju. Promena domena ne znači neograničeno trajanje projekta. a zatim donose odluku koja priča ima najviši prioritet implementacije. Uloga razvojnog tima je da što brže implementira promene. produženje vremena možda i neće dovesti do odgovora koji očekujemo.smanjenje kvaliteta može dovesti do skraćivanja vremena razvoja softvera. Ako kupac u svom zahtevu doda novu osobinu. Programeri i naručioci zajedno kreiraju skup priča koji će se implementirati za prvu (ili sledeću) isporuku. Sa druge strane. Planiranje isporuke softvera sadrži skup pravila koja omogućuju svima koji su uključeni u projekat da donose vlastite odluke.1. odnosno koliko vremena im je potrebno da implementiraju datu priču.4. Ovo se razlikuje od 42 . Kvalitet . ali se time povećava vreme koje je potrebno korisnicima da testiraju softver.2. da se pregleda kod i izvrši testiranje.3. To su: Vreme – suviše kratko vreme utiče na kvalitet proizvoda pošto nema dovoljno vremena da se saslušaju kupci. onda mora da izbaci nešto što je tom zahtevu ekvivalentno po veličini. Osnovna filozofija planiranja isporuke je da projekat može biti kvantifikovan sa četiri promenljive . Priče korisnika se pišu na karticama (cards). Planiranje isporuke (Release Planning) Planiranj em isporuke se kreira plan isporuke (release plan). Plan isporuke se koristi za kreiranje planova iteracija za svaku pojedinačnu iteraciju. Problem je održavanje zahteva i domena.

Prednost malih isporuka je u tome da razvojni tim može da proveri tačnost sa kojom su vršene procene. kako bi se odredilo šta će se raditii u trenutnoj iteraciji.3. Poželjno je da je dužina iteracije konstantna tokom čitavog projekta jer su iteracije zapravo „žila kucavica“ projekta. Naredni korak je planiranje pojedinačnih iteracija. Ovo je iteracija "nulta poslovna vrednost". Fiksiranje vremena (time boxing) je tehnika planiranja i kontrole projekta koja se odnosi na razvoj softvera. Ciklusi isporuka moraju da budu što kraći zbog sigurnosti da se pravi program koji kupac očekuje. obično od jedne do tri nedelje. 3.1.1.4. Osnovni princip je da se datum isporuke ne menja. Planiranje u trenutku (just-in-time planning) je jednostavan način za praćenje promena korisničkih zahteva u projektu. Umesto toga.4. Iterativni razvoj Itera tivni razvoj (Iterative Development) povećava brzinu razvoja softvera. 43 . 3. potrebno je napraviti plan iteracija i planirati iteracije na početku svake od njih. Svaki vremenski okvir ima fiksnu dužinu. Ne treba deliti programerske zadatke unapred.4. Inicijalna iteracija se fokusira na komponente arhitekture koje su potrebne da bi se postavio osnovni sistem. koje tim nije imao u vidu. Male isporuke Praktična preporuka XP-a je da se koriste male isporuke. Brzo se dobija povratna informacija o tome koliko je dobar plan.stalnog širenja domena gde kupac stalno proširuje svoje zahteve. ubacujući nove. Isporuka se deli na odreñeni broj iteracija (oko desetak) koje obično traju od jedne do tri nedelje.

130 str.4.4.2.4. Važno je da se ozbiljno shvate rokovi predviñeni za implementaciju svake iteracije. prateći napredak tokom iteracije. ne preporučuje se implementacija onoga što nije predviñeno u trenutnoj iteraciji. 44 .2.).).4). Ta funkcionalnost će se implementirati onda kada ona postane deo jedne od sledećih korisničkih priča u nekoj od sledećih iteracija.) i važnost upotrebe prakse refaktorisanja kao metode koja obuhvata akcije poboljšanja koda (3.2.4. ponoviti procene i smanjiti broj zadataka koji ulaze u iteraciju.1. korišćenje metafore kao pojednostavljene slike softverskog sistema koji se razvija (3. Projektovan je softvera u XP-u Projektovanje softvera u XP-u uključuje korišćenje jednostavnog dizajna (3.] je prikazan ciklus jedne iteracije u XP-u: Slika 12: Ciklus jedne iteracije u XP.Takoñe.2.2. potrebno je izvršiti novo planiranje iteracija.3. U slučaju da se ne mogu završiti svi zadaci. Na slici 12 [4.4.u 3. korišćenje CRC kartica za projektovanje softverskog sistema (3.2.

3.4. „rizik kamatne stope“ i slično. Tim treba svoj jezik da uskladi sa jezikom kupca. Još jedan razlog za upotrebu metafora je da one omogućavaju da kupac lakše shvati tehničke podatke. potrebno je da se definišu zajednički termini koji se koriste u komunikaciji. Koriste se za timsko projektovanje softverskog sistema. postoji najmanji mogući broj klasa i metoda. odnosno skraćenica za „ne radite ono što ne morate“. Važno je da ta slika softverskog sistema bude što više pojednostavljena kako bi je svi u timu razumeli.2. Primer za metaforu može biti kada tim razvija sistem za poslovanje menjačnice. Postoji šansa da će se utrošiti vreme na rešavanje problema koji ne postoji.2. Kupac koristi reči kao što je „zamena“.3. Treba izbegavati složeni dizajn i zbog mogućih promena u budućnosti. što može da ide do nivoa pojedinačnih komponenti ili modula. „opcije“. 45 . „bazna tačka“.1. Responsibilities. 3. Collaborat ion cards) CRC kartice su kartice klasa. Prilikom kreiranja softverskog sistema koji se isporučuje kupcu. kod koji je lako razumljiv. odgovornosti i saradnje. nema duplog koda. CRC kartice (Class. Najteža stvar koju programeri treba da prihvate kada prelaze na XP je rad sa ograničenjem.2. Suština je u tome da se ne radi nešto samo zato što bi možda moglo da zatreba.2. U XP-u postoji akronim YAGNI (You Ain’t Gonna Need It).3. Jednostavan dizajn U XP-u postoji jasna definicija jednostavnosti: izvršiti sve testove.4.4. Metafore sistema (System Metaphor) Metaf ora sistema predstavlja pojednostavljenu sliku softverskog sistema koji se razvija.

Loše projektovan kod obično traži više koda za obavljenje istih stvari.[21.] Svrha refaktorisanja je da se softver učini razumljivijim i pogodnijim za modifikovanje. Samo one izmene koje softver čine razumljivijim jesu refaktorisanja. Kod refaktorisanja se ne dodaju nove funkcije već se samo restruktuira kod.4.]: Poprav lja dizajn softvera . Prolazeći kroz sistem.Pojedinačne CRC kartice se koriste za predstavljanje objekata. kako da se implementiraju i menjaju. ponovo se vrši dodavanje nove funkcije. rano se otkrivaju slabosti i problemi. Dodavanjem nove funkcije može se uvideti da bi to bilo lakše ako bi struktura koda bila drugačija. Kada se popravi struktura koda.[21. često se prelazi sa jednog na drugi zadatak. Tokom razvijanja softvera. već ono nudi tehniku prečišćavanja koda na efikasniji i kontrolisaniji način. Kada se koristi refaktorisanje da bi se razvio sistem.4. U softveru mogu da se naprave puno izmena koje se malo ili nimalo odražavaju na vidljivo ponašanje. već samo da se dodaju nove mogućnosti.2. Refaktorisanje ne predstavlja samo prečišćavanje koda. odgovornosti mogu da se prikažu na donjoj levoj strani kartice. a saradnja meñu klasama desno od svake pojedinačne odgovornosti. Alternative dizajna mogu biti brzo istražene simulirajući predloženi dizajn. 54 str. vreme se deli na dve različite aktivnosti: dodavanje funkcija i refaktorisanje. Zato je vrlo bitno u 46 . često zato što kod bukvalno radi istu stvar na nekoliko mesta. a koji objekti te poruke primaju. xii str. Tada se prelazi na refaktorisanje. Suština je u tome da se razume šta se želi postići definisanim objektima. 3. Stalno refaktorisanje Refaktorisanje je proces menjanja softverskog sistema tako da se ne menja spoljno ponašanje koda. 55 str. već se poboljšava unutrašnja struktura. Refaktorisanje ima nekoliko namena [21. Klasa objekta može biti predstavljena na vrhu kartice. Kada se dodaju funkcije ne bi trebalo da se menja postojeći kod.] To je disciplinovani način prečišćavanja koda koji svodi na minimum šanse da se pojave greške. Jako je bitno naglasiti dvojnu prirodu refaktorisanja. CRC sesija se odvija na taj način što neko iz tima simulira sistem. govoreći koji objekti šalju poruke.

Refaktorisanje pomaže da se softver brže razvija. teže ga je ispravno modifikovati. ali se bitno odražava na modifikacije koda. Refaktorisanje pomaže u razumevanju nepoznatog koda. Primena ovog refaktoringa smanjuje broj linija koda. odnosno onoga šta on obavlja. jer ne utiče bitno na zauzeće resursa. umesto na dodavanje novih funkcija. Što je više koda. sve to vodi poboljšanju kvaliteta koda. U kodu u kome postoji sakrivena redudansa postoji više delova koda obavljaju istu stvar. čitljivosti. Glavni cilj dobrog dizajna (projektovanja) je da omogući brz razvoj. Dupliciranog koda. Pomaže u nalaženju grešaka – Razumevanje koda pomaže i u uočavanju grešaka. Bez dobrog dizajna može se brzo napredovati do nekog trenutka. unapreñuje dizajn sistema pa je samim tim jednostavnije njegovo razumevanje. Dobar dizajn je od suštinskog značaja za brz razvoj softvera. ali se one razlikuju zbog korišcenja razlicitih kvantifikatora. Čini softver razumljivim – Da bi i drugi korisnici mogli da razumeju i menjaju napisan kod. čak i da poboljša dizajn. Omogućava brže pisanje koda – Definitivno je da refaktorisanje poboljšava kvalitet koda. Najčešći problemi koji dovode do lošeg koda su sledeći.popravljanju dizajna eliminisanje ponovljenog koda. Poboljšavanje dizajna. Umanjenje količine koda neće sistem učiniti bržim. ali usled lošeg dizajna ubrzo vreme počinje da se troši na nalaženje i ispravljanje grešaka. Redundansa u kodu se može smanjiti primenom refaktoringa „Ekstrahovanje metode“. Kada su interfejsi dve 47 . odnosno karakteristike lošeg koda su sledeće: Postojanje redundanse odn. važno je da je razumljivo napisan. Dešava se da promenom dela koda na jednom mestu sistem i dalje ne radi ono što se očekuje jer nije promenjen deo koda i na drugom mestu gde radi istu stvar u malo drugačijem kontekstu. uklanjanje grešaka. Dobar dizajn je presudan za održavanje brzine pri razvijanju softvera. Razjašnjavanjem strukture programa dolazi se do tačke kada se lako uočavaju greške. Redudansa može biti Eksplicitna što je slučaj kada u kodu na više mesta postoji identična sekvenca naredbi ili Sakrivena kada u kodu postoji niz različitih naredbi koje daju iste rezultate.

4.4) i važnost kontinuirane integracije koda (3. Ističe se politika zajedničkog vlasništva nad kodom (3.3.4.klase koje realizuju sličnu funkcionalnost različiti.4. optimizacija koda na kraju (Optimize Last) (3. dogovora) pisanja koda (3.4. ali povećanje broja uslova povećava složenost softverskog rešenja.6). Indikator da klasa ima previše odgovornosti je postojanje velikog broja pojavljivanja (instanci) date klase.3. Ovaj problem obično nastaje kada se funkcionalnosti dodaju a pritom se ne konsoliduje dizajn softverskog rešenja.4.1). 3.4.2).5).3. Solution Spawl) je slucaj kada se kod ili podaci koje se odnose na jednu funkcionalnost nalaze u nekoliko klasa. primenom refaktoringa Ekstrahovanje klase/podklasa. važnost implementacije testova pre implementacije samog koda 3.3. Sve faze XP projekta zahtevaju komunikaciju sa 48 . odn. “Velika klasa” je slučaj kada klasa ima previše odgovornosti. Uslovna logika ne predstavlja problem na početku razvoja softvera. No Overtime) (3.4.7) i praktikovanje 40 radnih sati nedeljno. (3.1 Kupac na licu mesta Jedan od zahteva Ekstremnog programiranja je da je kupac dostupan razvojnom timu. “Lenja klasa” je slučaj kada postoji klasa koja nema dovoljno odgovornosti. Ne samo da pomaže.3.4.4. “Nepristojno otkrivanje” javlja se u slučaju kada se kreiraju public metode ili public klase koje ne trebaju biti javne. već da predstavlja deo razvojnog tima. Ovakve klase treba eliminisati. klase treba refaktorisati tako da dele zajednički interfejs.3.8).3).3. bez prekovremenog rada (40 Hours Week. važnost postojanja standarda (tj.3. Manji broj uslovnih naredbi je jednostavno razumeti. opis tehnike programiranja u paru (3.4.3. Rašireno rešenje (engl. Ovaj problem se rešava premeštanjem odgovornosti u druge klase. Implement acija softvera u XP-u Implementacija softvera u XP-u naglašava važnost prisutnosti i dostupnosti naručioca razvojnom timu (3.3.

Kupac je takoñe potreban pri testiranju funkcionalnosti softverskog sistema. 3. ovi standardi se dokumentuju i formalizuju kao deo tehnike koju kompanija koristi u razvoju softvera. Pomoć kupaca obezbeñuje da je većina željenih funkcionalnosti sistema pokrivena pričama korisnika. kako bi se procenilo vreme potrebno za razvoj softvera i definisali prioriteti. Priče korisnika (user stories) piše kupac. Testovi funkcionalnosti softverskog sistema verifikuju da je sistem spreman za upotrebu. Često se odnose na generalni pristup u programiranju. Najbolje je dodeliti jednog kupca (korisnika. U većini slučajeva.3.kupcem. odnosno funkcionalnosti koje će ranije biti isporučene kupcu. 49 . kada postoje opravdani razlozi za njihovo izbegavanje. uz pomoć programera. nezavisan od autora. na licu mesta. osim u izuzetnim okolnostima. poslovnog eksperta i drugih vrsta kupaca) ili više njih razvojnom timu.4. Preporuke – u pitanju su pravila koja se smatraju dobrom praksom i koja treba uvek da se koriste. Na sastancima na kojima se vrši planiranje isporuke definišu se male inkrementalne isporuke (small incremental releases).2 Standardi u pisanju koda Svrha primene standarda je da se proizvede softver koji ima konzistentan stil. Tako se dobija softver koji je razumljiviji i koji se lakše održava. Tokom planiranja isporuke kupac vrši selekciju korisničkih priča koje će biti uključene u raspored isporuka. Kupac je tada u mogućnosti da ranije testira softverski sistem i prosledi (ranije) povratnu informaciju programerima. Standardi u kodiranju se dele u različite kategorije: Obavezni – ovih standarda treba da se pridržavaju svi članovi tima Vodiči – to treba smatrati dobrom praksom.

otežava se zamena partnera. onda koristimo i programiranje u parovima. dogañajima i parametrima. pošto bi onda trebali da se upoznamo sa pojedinačnim pristupima programera. uvlačenja i dužinu linija sa komentarima u kodu. Ako se komentari koriste na pravi način. Rukovanje greškama – opisuje kako objekti rukuju greškama. resursa i drugih datoteka sa izvornim kodom. Struktura koda – ovde spada opšti raspored projekta (datoteke i sl.Ako koristimo XP. kako se o njima izveštava i kako se one zapisuju. Dva programera dele istu radnu stanicu. klasa. Pojedinci iz tih parova se smenjuju za tastaturom.4. Postoje različiti aspekti koje standardi u kodiranju treba da definišu. koji se koriste umesto razmaka.3 Program iranje u paru Programeri u XP. Ako se ne koriste standardi u kodiranju. Najvažniji od njih su: Formatiranje – se odnosi na upotrebu belina.). Neki standardi mogu da sadrže zajedničko podešavanje editora i definisanje tabulatora. promenljivim. Konvencije prilikom zadavanja imena – ukazuju na način na koji programeri zadaju imena svojim metodama. Komentari – se postavljaju u kod i objašnjavaju logiku koda (kvalitetan kod treba da bude sam po sebi jasan). 3. kod postaje razumljiviji i lakši za održavanje. Programiranje u parovima ima sledeće prednosti: Sve odluke vezane za dizajn proverile su dve osobe Najmanje dva programera su upoznata sa tim delom sistema Manja je šansa da će testovi biti izostavljeni Par koji zajedno radi proširuje svoja znanja Sav kod se neprekidno pregleda 50 .3. smenjujući se za tastaturom. klasama.u rade u parovima.

dosta lakšom. 51 .U XP-u se praksa saradnje primenjuje do ekstrema. Oni pišu jedinične testove kojima se testira svaka metoda.4 Pisanje jediničnih testova pre implementacije funkcionalnosti Programeri u XP-u prvo pišu test. došlo se do sledećih zaključaka: Vreme razvoja kod programiranja u parovima je 15% duže nego kod individualnog programiranja. Takoñe.4. pošto ne postoji sigurnost da li će se javiti greška ako se promeni kod koji nije testiran. Vreme koje je potrebno da se implementira prvo test a zatim kod koji zadovoljava test je slično vremenu koje je potrebno da se implementira funkcionalnost bez implementacije testa. boljeg morala i povećane kreativnosti. piše se samo onoliko koda koliko je potrebno da bi se prošao test. za koju se piše test. koje je izvršila Laurie Williams sa univerziteta Severna Karolina. a posle toga kodiraju. 3. U istraživanjima o prednostima i nedostacima programiranja u parovima. Saradnja u procesu razvoja daje kod boljeg kvaliteta. ne odnosi neko dodatno vreme. jer svi programeri rade u parovima. Nakon što napišu sve testove za odreñenu komponentu. Kreiranje jediničnih testova omogućava programerima da imaju uvid u ono što zaista treba isprogramirati. programeri imaju brzu povratnu informaciju tokom rada. Refaktorisanje bez skupa testova dovodi do privremenog razvoja. nego čini implementaciju funkcionalnosti. Postavlja se pitanje šta je sa ekonomičnošću.3. Testiranje na ovaj način omogućava da programeri imaju poverenje u svoj kod i predstavlja osnovu za refaktorisanje. Programiranje u parovima daje najmanje 15% manje grešaka nego individualno programiranje. dakle. Ako se prvo kreiraju jedinični testovi. odnosno da li dva programera koji rade za istom mašinom poboljšavaju krajnji rezultat. Pisanjem testova na ovaj način dobija se skup testova sistema. Implementacija testa. dovodi do kvalitetnijeg rada. onda će se znati kada su sve funkcionalnosti implementirane jer se svi testovi uspešno izvršavaju.

Prethodno napisanom kodu se doda samo onoliko koda koliko je potrebno da se novi test uspešno izvrši. pa i poslovni i tehnički tim imaju stalnu povratnu spregu koja ukazuje na stanje softverskog sistema. Tipični alati. Prilikom dodavanja nove funkcionalnosti. TDD).NET platformu. Kod koji se kreira treba da je jednostavan i koncizan. Zatim se kreira najjednostavniji kod koji će omogućiti da se taj test izvrši uspešno. moguće je automatizovano izvršavati jedinične testove iz IDE razvojnog okružja. Nakon toga se kreira drugi test. 52 . Automatizovani testovi omogućavaju da se stalno izvršavaju testovi. Za taj test (ili testove) se implementira najjednostavniji kod koji će omogućiti da prethodno implementirani test proñe bez grešaka. Testovi koji su napisani se dodaju u automatizovano okruženje za testiranje. Prvo se kreira jedan test kojim se definišu neki manji aspekti problema. prethodno se prema potrebi refaktorše prethodni kod. kad god se vrši integracija. Testovi su ujedno i svojevrsna dokumentacija koda. i da se refaktorisanjem nije narušila neka prethodna funkcionalnost. refaktorisanje koda i dodavanje nove funkcionalnosti sve dok svi zahtevi nisu testirani i implementirani. i projektovanje sistema se unapreñuje na ovaj način.Takoñe. odnosno okruženja kojima je moguće vršiti jedinično testiranje su JUnit za J2SE ili J2EE platformu i csUnit za Microsoft . Drugi programeri mogu lakše da razumeju kod pregledom testova. implementirajući samo željene zahteve. odnosno pokazuju kako se kod ispravno koristi. Ulazi čiji rezultati nisu definisani neće biti uključeni u skup testova (test suite). Taj pristup je opšte poznat kao razvoj voñen testovima (Test Driven Development. Postoji ritam u razvoju softvera koji nalaže da se vrši implementacija jediničnih testova pre implementacije samog koda. Ciklično se ponavlja dodavanje testnih metoda. Test se neprestano izvodi kako bi se proverilo da ta nova funkcionalnost radi. Na ovaj način se nastavlja sa kreiranjem testa i koda sve dok ne postoji više ništa da se testira. Prvo se implementira jedan test (jedna ili više testnih metoda) koji definiše jedan mali aspekt problema. Pomoću ovih alata.

Na kraju sklapanja treba da postoji neka vrsta „dimnog“ testa koji će proveriti da li je sve u redu (dimni test je termin koji se pojavio u elektronskoj industriji. a integracija se radi samo u vreme isporuke. rešavaju probleme i prelaze na novi zadatak. pa se proverava da li negde dimi). jer programeri rade na pojedinim objektima. ili pravilnije. nakon čega se na odreñenoj mašini sklapa potreban softver: 53 . biće više konflikta i povećava se trud koji se troši na integraciju. Razvoj sa malim delovima aplikacije se uklapa u objektno orijentisano okruženje. ako sistem proñe testove za verifikaciju i dimne testove. a ne prave kompletnu aplikaciju. vrše testiranje. Izvorni kod se skida sa sistema za kontrolu verzija. Što je duži period izmeñu dve integracije. Rezultati su katastrofalni.5 Kontinuirana integra cija koda Programeri rade na svom delu softverskog sistema i kada ga završe dolazi do integracije sa celim sistemom. Sklopljena verzija softvera je dobra ili uspešna. klasi ili komponenti rade sve dok ne završe. integracija se vrši kad kod je to moguće. Tada je softver spreman za testiranje ili pregled od strane kupca i tima. vrši se kompilacija. Stalna integracija se u praksi primenjuje tako što programeri svoj posao na modulu. Ekstremna suprotnost u odnosu na integraciju u trenutku isporuke je stalna integracija. to je bolje.4. koja su manje stroga.3. jer što su manji. U inženjerskim okruženjima. Na slici 13 je prikazano kako programeri rade kada proveravaju izvorni kod iz skladišta. programeri rade nedeljama ili mesecima. linkovanje i na kraju sklapa softver.3. Zadaci u razvoju su mali. kada se štampan ploča ili neka druga komponenta ispituje pod naponom . Na taj način se stvaraju osnove da se svakog dana dodaje ono što se tog dana uradilo i osigurava se da projekat neće suviše odstupiti od stabilne radne verzije. jer se stalno proverava da ništa nije ugrozilo osnovni projekat. Ako se desi nešto nepredviñeno to se odmah popravlja. Ovakvi testovi osiguravaju osnovnu stabilnost projekta. Nakon toga oni vrše integraciju (na mašini za integraciju). Svakodnevno sklapanje softvera se radi pomoću automatizovanih skriptova.

Ako je ciklus sklapanja kratak. Ispravka sklopljenog softvera koji nije prošao testove je prioritetan zadatak za ceo tim. Programeri koriste kontrolu izvornog koda i posebnu mašinu za sklapanje softvera Ako sklapanje ne uspe (ne proñu svi testovi). onda je bolja odluka da se ponište promene i da se pre ponovne integracije izvrše dopunska testiranja. Kolektivno vlasništvo donosi kolektivnu odgovornost. onda je i manje promena izmeñu sklapanja. Ako se problemi integracije odnose na fundamentalne greške ili probleme. pa se problemi lakše otkrivaju i ispravljaju.Programeri Početak pro vere koda Automatizovani testovi Pro veren kod Mašina za sklapanje Skladište izvornog koda Proizvod Rezultati testa Rezultati sklapanja Rezultati sklapanja idu do razvojnog tima Proizvod koji se testira Kupac Slika 13. kada se prvi put upotrebi neki 54 . tim može da odluči da poništi promene. tim ima dve mogućnosti: Može odmah da rešava problem. Poništavanje promena. Na primer. U slučaju da postoji mogućnost da nešto nepoznato skrene tim sa pravog puta.

modul trećih (nezavisnih) proizvoñača. 55 .

7 Optimizacija koda Optimizaciju koda treba ostaviti za kraj razvojnog projekta.3. Nastaju problemi ako ključni članovi tima u svojim glavama drže važne informacije.6 Zajedničko vlasništvo nad kodom Zajedničko vlasništvo nad kodom (Collective Code Ownership) daje mogućnost da svaka osoba u okviru tima. testiranje. kolektivno vlasništvo. Odsustvo zbog bolesti ili nekog drugog razloga može da oduzme vreme celom timu. 3. . ali se ne primenjuju druge praktične preporuke iz XP-a. Suprotnost kolektivnom vlasništvu predstavljaju situacije kada pojedinačni programeri imaju status "vlasnika modula" ili vlasnika "podsistema". može u bilo kom trenutku da menja kod.4.4.3. Kontrola izvornog koda je najlakši način da se od početka do kraja projekta uspostavi kontrola. Programiranje u parovima takoñe podržava ideju o kolektivnom vlasništvu. bez obzira koliko često se to radi. koja je deo tima. optimizaciju ne treba raditi za vreme trajanja implementacije. Stalna integracija je u XP-u podržana preko praktičnih preporuka koje se odnose na programiranje u parovima. Ako se u projektu koristi kolektivno vlasništvo. je da sav izvorni kod mora da bude u kontrolnom skladištu. koji pokušava da prevaziñe neki problem koji se javlja kod integracije.. onda može nastati haos i sav uložen trud može biti uzaludan. Tek nakon toga se može posvetiti optimizaciji koda i brzini rada sistema. testiranje i standarde u kodiranju. 3. ruši se osećaj zajedništva kojem se teži u timu. standardi u kodiranju i sl.Odbranom u stilu: "To nije moj kod". tako da nenamerno mogu da dovedu do zastoja u radu celog tima. refaktorisanje. kao što su programiranje u parovima. Najvažnije je da sistem ispravno radi.Ključna stvar u sklapanju.

ali na kraće staze. Zamor XP tima može da dovede do mrzovolje. 3. ako postoji tim koji je preopterećen.8 40 radn ih sati nedeljno Razvoj u XP-u teče uz dosta komunikacije i velikom brzinom. P r o d u k ti v n o s t (n o v i r a d minusizgubljeno vreme z a p o p ra v k e ) Radni sati u toku nedelje 40 60 80 100 120 Slika 14. raspoloženje se menja i komunikacija opada. Produkti vnost raste sa utrošenim vremenom Dobici su mogući. Optimizacija koda se vrši kako bi se odreñeni delovi koda zamenili sa delovima koji su tehnički napredniji: manjeg su stepena složenosti. Ne bi mogao da se održi kvalitet. jednostavniji su za korišćenje i vremenski se brže izvode. Programeri rade u okruženju gde je naglasak na promenama. je prikazana zavisnost produktivnosti od prekovremenog rada. Kod se bolje razume i bolje je struktuiran. čime se eliminišu viškovi i redudansa.4.Proces optimizacije se razlikuje od procesa refaktorisanja. Jedna od osnovnih praktičnih preporuka XP-a je da kvalitet nikad ne sme da se dovede u pitanje. tako da . Povećava se broj grešaka. Prekovremeni rad na duže staze može da dovede do veće promene osoblja i slabijeg kvaliteta. Na sledećoj slici 14.3. Refaktorisanjem se poboljšava kod bez promene funkcionalnosti. Mora da se zadrži kontrola nad radnim satima programera i da se dalje zadrže visoki standardi. Rad na XP projektu znači stalno poboljšanje kvaliteta i performansi u toku života projekta.

Ako se prate druge praktične preporuke XP-a. Moguće je uneti nepravilnosti istovremeno i u testove i u izvorni kod. Moguće je brzo integrisati bilo koju nedavnu promenu pokrećući niz testova. jedinični testovi verifikuju da promena u strukturi nije dovela do promene funkcionalnosti. Povremeno se može dogoditi da je test pogrešan.4.1 Jedinični testovi Proveravaju ispravnost rada sistema i uvek moraju raditi.4.4. Nakon svake male promene koda. ako se dan utroši na ono što se zna da je važno i ako se jednostavno rešava problem. Jedinični testovi omogućavaju primenu postupka „zajedničkog vlasništva nad kodom“. Popravljanje malih problema svakih nekoliko sati oduzima manje vremena nego popravljanje velikih i kritičnih problema pre isporuke.4. Tes tiranje softvera u XP-u Testovi se mogu podeliti u dve osnovne grupe: jedinični testovi (Unit Tests) i testovi prihvaćenosti (Acceptance Tests). Daju sigurnost programerima u vlastiti kod i ujedno objašnjavaju kako se kod koristi. ali to se lako otkriva pokretanjem testa. Kreiranjem jediničnih testova štiti se funkcionalnost softverskog sistema kako se ona ne bi slučajno narušila. Jedinični testovi takoñe omogućuju refaktorisanje. više od osam radnih sati dnevno neće biti potrebno. a da je kod ispravan. Često dodavanje novih funkcionalnosti zahteva menjanje jediničnih testova. 57 . iako se to u praksi ne dogaña često. Kreiranje univerzalnog skupa jediničnih testova (unit test suite) za validaciju i regresivno testiranje omogućuje čestu integraciju. 3. Automatizovanjem jediničnih testova moguće je sjediniti skup promena sa zadnjom verzijom u kratkom vremenu. 3. Moraju biti automatizovani kako bi se omogućila jednostavna ponovljivost. Zahtevom da sav kod mora da proñe sve jedinične testove osigurava se da sve funkcionalnosti uvek rade.otvorena i pozitivna komunikacija sa kupcem postaje nemoguća.

2 Testovi prihvaćenosti Proveravaju funkcionalnost čitavog sistema koji je opisan korisničkim pričama. Testovi prihvaćenosti predstavljaju sistem crne kutije. Korisnici su odgovorni za verifikaciju ispravnosti testova prihvaćenosti i oni odlučuju kog su prioriteta testovi koji nisu prošli. programeri mogu da kreiraju jedinične testove koji konkretnije ukazuju na to gde se u kodu javila greška. koji nije prošao. tada test prihvaćenosti koji nije prošao može ponovo da se izvrši kako bi se izvršila validacija ispravljenih grešaka. Pišu ga naručioci uz pomoć programera. Prikazano je kako kupci pišu testove dok programeri rade. Na osnovu testa prihvaćenosti. Odreñuju da li sistem zadovoljava kriterijum prihvaćenosti i omogućuju naručiocu da odluči da li može prihvatiti sistem.3. Svaki test prihvaćenosti predstavlja neki očekivani rezultat sistema. Test koji ne uspe premešta se u sledeću iteraciju. Testovi prihvaćenosti treba da se automatizuju kako bi se omogućila njihova ponovljivost. Korisnička priča nije završena sve dok ne proñe test prihvaćenosti. Priča korisnika Programeri razlažu priču Zadaci Implementacija zadatka Implementirana priča Kupac piše testove Testovi za prihvatanje Kompletna priča se šalje na test Rezultati testiranja Izvršavanje testova Test nije uspeo Naredna iteracija Test je uspeo Završena priča 58 .4. To znači da u svakoj iteraciji moraju da se kreiraju novi testovi prihvaćenosti ili razvojni tim proglašava „nula“ progres.4. Na slici 15 je ilustrovan tok rada testa za prihvatanje. Kada su svi jedinični testovi 100% uspešno izvršeni.

Slika 15. Tok rada testa za prihvatanje 59 .

Standardi u pisanju koda.4. Planiranje isporuke. U fazi projektovanja objašnjeni su sledeći postupci: Class. Kent Beck je napisao SUnit testno okruženje za Smalltalk programski jezik. Objašnjeni su postupci koje XP primenjuje kroz faze razvoja softvera. moguće je automatizovano izvršavati jedinične testove iz IDE razvojnog okruženja. Collaboration cards. VBUnit za Visual Basic. Iterativni razvoj Jednostavan dizajn. U fazi implementacije dat je prikaz sledećih postupaka: . Za uspešno korišćenje jediničnih testova.3 Test iranje jedinice progra ma pomoću okvira xUnit Jedinični testovi su jedna od najvažnijih stvari u ekstremnom programiranju.Objašnjen zatim postupci u XP-u kroz faze procesa životnog ciklusa softvera. Male isporke. Pomoću ovih alata. Kupac na listu mesta. U fazi projektovanja prikazani su sledeći postupci: Priče korisnika (user stories). Stalno refaktorisanje.3.5 Sažetak U ovom poglavlju dat je prikaz metode Ekstremno programiranje. Nakon toga su Kent Beck i Erich Gamma napravili JUnit [35] za J2SE [36] i J2EE [37] platformu. SUnit za SmallTalk itd. U zavisnosti od jezika postoji JUnit za Javu. 3. Zbog svoje važnosti u ovom radu. JUnit je opisan u posebnom poglavlju. Responsibilities. je životni ciklus XP-a. potrebno je kreirati ili koristiti neki od gotovih test okruženja koja su dostupna na tržištu i kojima je moguće vršiti jedinično testiranje. Metafore sistema.4.

Jedinični testovi. . U fazi testiranja softvera objašnjene su sledeći postupci: Testiranje jedinice programa pomoću okvira xUnit. cilj istra živanja (Dati pregled metode Ekstremno Na taj način smo realizovali drugi programiranje). 40 radnih sati nedeljno. Kontinuirana integracija koda. Testovi prihvaćenosti. Zajedničko vlasništvo nad kodom. Pisanje jediničnih testova pre implementacije funkcionalnosti. Optimizacija koda.- Programiranje u paru.

.* JUnit Slika 16.4.. Meñutim. Osnovni koncepti Junit-a Sa slike 15 se vidi da svaka Java klasa može da se testira.* 0. Ovo okruženje omogućava ogromnom broju Java programera da lako testiraju svoje komponente. ..* Skup testova (JUnit) sadrži 0. Konkretan test je u vezi sa samo jednom procedurom i sa samo jednom klasom. Test procedura je nezavisna od klase. Python (PyUnit). Kad se test procedura primeni na odreñenu klasu..1 Osnovni koncepti Junit-a JUnit je open source okvir za testiranje.. koristi se jedna ili više test procedura. Junit omogućava kreiranje testova za bilo koju Java klasu. napisan za Java programski jezik. postao je toliko popularan da je preveden i prilagoñen za korišćenje u drugim programskim jezicima: C# (NUnit). onda nastaje konkretan test ili više konkretnih testova... pa može ista test procedura da se primeni na različitim klasama. ali ne moraju sve. Test procedura 1 0. Kada se testira klasa. koje je napisao Kent Beck (SUnit).* 1 0. JUnit je nastao na osnovu originalnog okruženja za testiranje u SmallTalku.* Java klasa Konkretan test Test klasa (JUnit) 1 1.* je sadržan od 0. odnosno za bilo koju njenu metodu (Slika 16). C++ (CPPUnit). Fortran (fUnit). JUNIT ALAT ZA TESTIRANJE KODA 4.* Test metoda (JUnit) 0.

vrše automatsku proveru rezultata i prijavljuju greške. NetBeans. a testovi se izvode organizovano i detaljno. kao što je na primer kompajliranje testova i izvršavanje testova. a testovi se pišu veoma lako. dopuniti i ponovo izvršavati. . Test klase mogu da se organizuju u veće celine – skupove testova (TestSuite). nekih testova koji pripadaju odreñenom skupu ili pojedinačnih testova. što je jako bitno kada je broj testova relativno veliki. testovi napisani u JUnit-u. U okviru XP metode. jer se prvo piše test. Tako se stvara sigurnost da sve što je implementirano i potpuno funkcionalno. Svaki skup sadrži jednu ili više test klasa. a mnoge operacije. Prednost integrisanog JUnita je u tome što je olakšan rad pri testiranju koda jer se vrši preko bogatog grafičkog interfejsa. Korišćenjem JUnita kreira se baza testova. tako da se može menjati. JUnit test metoda je Java metoda čije ime počinje sa „test“ (na primer: testIzracunajRacun) i pripada JUnit test klasi (TestCase). su automatizovane. a test metoda može da pripada samo jednoj test klasi. Testovi se mogu organizovati u hijerarhijski povezane celine. a takoñe može da sadrži i jedan ili više drugih skupova. Čuva se baza testova. odnosno onoj koja se testira. svaki konkretan test može da se implementira kao jedna test metoda. odnosno pišu se jedinični testovi kojima se testira svaka metoda. Na taj način se može pozvati izvršavanje svih testova. Prednosti testiranja koda korišćenjem JUnit-a su sledeće: JUnit je veoma jednostavan za korišćenje. Svaka test klasa može da ima jednu ili više test metoda. odnosno vrši se regresiono testiranje (izvršavaju se svi postojeći testovi) i da li novi deo funkcioniše kako bi trebalo (napišu se i dodaju novi testovi u bazu i izvrše).U JUnit-u. JDeveloper. Svaka test klasa odgovara samo jednoj Java klasi. a posle toga kodira. JUnit se koristi sve vreme tokom razvoja softvera. JBuilder. Pri izvršavanju. JUnit je integrisan u mnoga razvojna okruženja (Eclipse. Sun Java Enterprise Studio) . što je jako bitno jer se može proveriti da li je program zadržao svu funkcionalnost koju je imao ranije.

// izvršava se logika za inicijalizaciju // izvršava se metod za testiranje tearDown(). testConvertAmount(). // izvršava se logika za završetak testa } Svaki jedinični test treba da sledi sledeće korake: 1.framework.TestCase. . 4. Treba definisati test. Svaki test treba da vraća void (odnosno da ne vraća ništa). Definisati skup testova. Pruža osećaj sigurnosti da testirane klase ne mogu neočekivano da ispolje neka druga drastična ponašanja. ako je potrebno da se testovi izvršavaju zajedno. a njegovo ime treba da počinje sa test. testAdd() itd. doTests(). na primer testMaxSize(). 2. Resurse koje smo zauzeli preko funkcije setUp() osloboditi preklapanjem metoda tearDown(). jer se pišu u Javi u formi običnih metoda. 3. Treba da bude potklasa klase junit. U metodu setUp() treba dodati neki kod za podešavanje. 5.Svaki programer može lako da nauči da piše testove. 4.2 Osnovni ciklus slučaja testiranja Svaki slučaj testiranja prati sledeći osnovni ciklus: petlja kroz metode za testiranje: { setUp().

0.99.class). assertEquals("Capacity". 11. new Long(12)). // forced failure result ==5 assertTrue(result==6). . } public void testDivideByZero(){ int zero=0.0. } protected void setUp(){ value1=2. public class SimpleTest extends TestCase{ protected int value1. int result=8/zero. } } ~ assertEquals() – uporeñuje jednakost dve vrednosti. } public static TestSuite(){ return new TestSuite(SimpleTest. import junit. protected int value2. 12). Test prolazi ako su te dve vrednosti jednake. 12L). } public void testEquals() { assertEquals(12.Primer : Testiranje klase SimpleTest package junit. 13). assertEquals(new Long(12).framework.samples. value2=3. } public void testAdd(){ double result=value1+value2. public SimpleTest(String name) { super (name).0). assertEquals(12L. assertEquals("Size". 12. 12.*.

Pravi se izuzetak. Izvršavanjem SimpleTest-a preko Swing TestRunner-a. Ovde se javlja greška radi demonstracije. Veši se preklapanje metode setUp() i podešavanje inicijalne vrednosti za promenljive u testu. Nastaje greška.java nalazi se sledeće: Referencira se biblioteka iz okvira JUnit. Klasa za testiranje implementira test "dodavanje brojeva". Metoda testEquals() proverava jednakosti i vraća poruku o neuspehu. što je suprotno u odnosu na neuspeh. tako što se u metodi testDivideByZero() vrši deljenje sa nulom. Vrši se preklapanje osnovnog skupa testova i vraća novua istanca za taj slučaj testiranja. Daje se ime klasi za testiranje (SimpleTest). testAdd(). Test prolazi ako je vrednost boolean U datoteci SimpleTest. Generiše se poruka ako sabiranje ne uspe. procenjuje boolean promenljivu. dobija se ekran (slika 17): . Ta klasa treba da bude potklasa klase TestCase.~ assertTrue() promenljive true.

Metode poslovnih pravila entiteta moraju detaljno da se testiraju. U suprotnom.Slika 17. jako je teško napisati testove jer sami testovi moraju da budu razumljivi.3 Jedin ično testir anje veb aplikacije Kreiranje veoma granularnih metoda pomaže u jediničnom testiranju. lako se kreira jedinični test koji testira tu metodu. Entiteti se lako testiraju ako imaju dobro ograničenu funkcionalnost. Ako metoda predstavlja atomsku operaciju. JUnit prikazuje neuspešan test 4. get() i set() metode generalno ne moraju da se testiraju. ako su metode velike i izvršavaju veći broj operacija. .

3.org/wiki/Reflection_(computer_science)] .2 Pokretanje testova Pokretači testova ukazuju na pojedinačne slučaj testiranja (test case) ili paket koji sadrži slučajeve testiranja i pokreće sve sto počinje sa test. 8 Refleksija je proces kojim program može da uoči i modifikuje svoju strukturu i ponašanje. Sadrži pomoćne metode za kreiranje i pokretanje testova. Na primer. 4. Ne testira se sama konekcija. To nije nešto što se testira.4 Sažetak U ovom poglavlju prikazan je JUnit alat za testiranje softvera. [http://en.3. Na primer. Slučaj testiranja će uključiti Connection kao „fixture“. Učitava svaku klasu paketa koja počinje sa Test a koja implementira TestCase i pokreće metode čiji naziv počinje sa test. ako se testira pristup bazi podataka (database access). Kada se izvrši TestCase.1 Slučajevi testiranja (Test Cases) TestCase klasa je osnovna klasa za testiranje. JUnit koristi refleksiju da odredi koje testove da pokrene. tearDown() metoda se poziva nakon što se pokrene svaki test. setUp() uspostavlja konekciju na bazu. Na ovaj način.wikipedia. „Fixture“ je artifakt u odnosu na koga se pokreću testovi. olakšavajući na taj način dodavanje novih metoda za testiranje u postojeći slučaj testiranja. potreban je Connection objekat da bi se pristupilo tabelama baze. a tearDown() zatvara tu konekciju. Slično.4. nego je konekcija potrebna pre nego što se napiše ostatak testa. 8 4. osnovni ciklus slučaja testiranja. automatski se pokreću sve metode klase koja počinje sa test. kao i jedinično testiranje veb aplikacije. nego sredstvo (resource) koje je potrebno da bi se test pokrenuo. setUp() metodu okvir (framework) automatski poziva pre nego što se pokrene svaki test. TestCase takoñe uključuje metode kojima se implementira „fixture“. Na taj način smo realizovali treći cilj istraživanja (Dati pregled JUNIT alata za testiranje softvera). Objašnjeni su osnovni koncepti JUnit-a. JUnit omogućava da se kreiraju novi testovi koji se automatski priključuju skupu testova i pokreću.

odnosno JVM (Java Virtual Machine) koja interpretira Java naredbe. JEE API se sastoji od više tehnologija: JSP. PDA ureñaji.1 Uvod u JEE tehnologiju Programski jezik Java je u potpunosti nezavistan od operativnog sistema na kojem se izvršava. uz obezbeñivanje odgovarajućih upravljačkih programa (drajvera) omogućava povezivanje aplikacije sa konkretnim DBMS sistemima i preslikavanje opštih Java naredbi u naredbe konkretnog DBMS. Definicija: JEE aplikacije su višenivojske složene aplikacije (multitier enterprise applications). Takoñe. testiranje i izvršavanje JEE aplikacije. ĉime se. JAVA PLATFORMA 5. JSF. Java Platform. pod pretpostavkom da za taj operativni sistem postoji JRE (Java Runtime Environment). ĉime je obezbeñena prenosivost (portabilnost) aplikacija razvijenih u Javi. Java 2 Standard Edition.5. Napisana aplikacija se može izvršiti na bilo kom operativnom sistemu. Svako izdanje namenjeno je razvoju specifičnih aplikacija i obezbeñuje drugačije izvršno (runtime) okruženje: 1. Enterprise Edition ili Java EE je razvojno okruženje koje obezbeñuje JEE API i oruña za grañenje. programski jezik je u potpunosti nezavistan od konkretnih Sistema za upravljanje bazama podataka (DBMS . preslikavajući ih u naredbe konkretnog operativnog sistema. 3. J2SE – obezbeñuje izvršno okruženje za razvoj desktop aplikacija i predstavlja jezgro funkcionalnosti za naredna izdanja Java platforme. TV ureñaji i ostali ureñaji koji imaju manjak resursa da podrže J2SE ili JEE. JEE tehnologije su podeljene u tri grupe: . Java Servlet. EJB. Java 2 Micro Edition. Java Enterprise Edition. J2ME – definiše skup izvršnih okruženja za razvoj aplikacija za embedded ureñaje kao što su mobilni telefoni. Razlikujemo tri izdanja Java platforme.Database Management System). 2. JAXP i druge. JEE – predstavlja nadskup J2SE koji podržava razvoj enterprise aplikacija.

Jedinstveni model zaštite (Unified security model). Veb strana može biti realizovana preko HTML-a. JavaServer Pages Standard Library – JSTL. Komponente koje se mogu ponovo koristiti (Reusable components). JavaBeans komponenti i Message Handler komponenti. Internacionalizacija i lokalizacija Web aplikacija). XML-a ili nekog drugog markup jezika. standardnih Javinih klasa. Veb aplikacija se sastoji od Veb komponenti. . Postoje dva tipa web aplikacija: Prezentac iono-or ijentisana Prezentaciono orijentisane Veb aplikacije generišu Veb strane na osnovu zahteva koje im postavlja klijent. JavaServer Pages – JSP.JAXR). HTML strana. Servisno-orijentisana – Servisno orijentisane Veb aplikacije koriste Veb servise da realizuju zahteve koje im postavlja klijent ili prezentaciono-orijentisana aplikacija (u tom slučaju je prezentaciono-orijentisana aplikacija klijent servis-orijentisanoj Veb aplikaciji). SOAP with Attachments API za Javu – SAAJ. JEE platforma podržava: Više nivojski distribuirani aplikacioni model (Multitiered distributed application model). Java API za XML based RPC – JAX-RPC. Message-driven beans). Fleksibilnu transakcionu kontrolu (Flexible transaction control).a) Web tehnologije koje se koriste u razvoju prezentacionog nivoa ili stand-alone web aplikacije (Java Servlet. Entity beans. JavaServer Faces – JSF. 5. Java API za XML registrovanje . b) Enterpr ise JavaBeans (EJB) tehnologije koje se koriste u razvoju poslovne logike JEE aplikacije (Session beans. c) Java XML tehnologije za razvoj aplikacija koje procesiraju XML dokumente i implementiraju Web servise (Java API za XML procesiranje – JAXP.2 Veb aplikacija Veb aplikacija predstavlja aplikaciju koja se izvršava u okruženju Veb servera. Web servise koji prihvataju i razmenjuju podatke koji su zasnovani na XML (Extensible Markup Language) standardima i protokolima.

. konveruje zahtev u HTTPServletRequest objekat. Veb server konvertuje HTTPServletResponse objekat u HTTP odgovor i vraća ga nazad do klijenta. Veb komponenta može da generiše HTTPServletResponse objekat ili može da prosledi zahtev do druge Veb komponente. koji podržava Java Servlet i JSP tehnologiju. Web server.Interakcija izmeñu Veb klijenta i Veb aplikacije je prikazana na slici 18 [11]. Slika 18: Inter akcija izmeñu Veb klijenta i Veb aplikacije Klijent šalje HTTP zahtev do Veb servera (1). JavaEE aplikacija se pravi od sledećih komponenti : 9 9 J2EE komponenta je softverska jedinica (software unit) koja ima neku funkcionalnost i koja je pridružena J2EE aplikaciji i koja je realizovana u skladu sa J2EE specifikacijom. koja može da bude u interakciji sa JavaBeans komponentama ili sa SUBP-a kako bi generisala dinamički sadržaj. Taj objekat se šalje do Veb komponente. J2EE komponenta se sastoji od skupa meñusobno povezanih klasa i datoteka koje joj obezbeñuju željenu funkcionalnost.

JSP strane su tekst dokumenti koji se izvršavaju kao servleti ali oni dozvoljavaju da se na neposredniji način kreira statički sadržaj tih dokumenata (moguće je direktno pisati HTML kod u JSP stranu). Na serverskoj i klijentskoj strani mogu da postoje i JavaBeans komponente koje takoñe nisu realizovane u skladu sa JavaEE specifikacijom. Klijentske komponente nisu JavaEE komponente jer nisu u skladu sa JavaEE specifikacijom.2. Servleti su najpogodniji za servisno orijentisane aplikacije. Servleti su Javine klase koje dinamički procesiraju zahteve i konstruišu odgovore. JSP strane su pogodne za prezentaciono-orijentisane aplikacije. 5. Na slici 19 [11] su prikazane Java Veb aplikacione tehnologije: Slika 19: Java Veb aplikacione tehnologije .1 Veb komponente Veb komponente su ili servleti ili JSP strane (kreirane korišćenjem JSP tehnologije).Klijentske komponen te (aplikacioni klijent i aplet) na klijentskoj mašini Veb komponente (Servleti i JSP-ovi) na JavaEE serverskoj mašini Poslovne komponente (EJB-ovi) na JavaEE serverskoj mašini JavaBeans komponente Veb komponente i EJB komponente su JavaEE komponente jer su realizovane u skladu sa JavaEE specifikacijom.

.2. U ovoj tezi za razvoj ShopCart servlet aplikacije kao sistem za upravljanje bazom podataka koristi se MySQL 5. upravljanje životnim ciklusom (life-cycle management). transakcije i e-mail. 5. 5.3 Sistem za uprav ljanje bazom podataka Sistem za upravljanje bazom podataka je softverski sistem koji treba da omogući čuvanje podataka. istovremeno korišćenje podataka od strane više korisnika i jednostavan način komunikacije sa bazom podataka.2. Veb kontejner obezbeñuje sledeće servise za Veb komponente: a) b) c) d) usmeravanje zahteva (request dispatching). odnosno njegov EJB kontejner). odnosno programer mora da implementira komunikaciju sa SUBP-a (dok EJB aplikacije to čine posredno jer je to obezbedio EJB server. Takoñe daje Veb komponentama pristup do API-ja koji se odnosi na imenovanje (naming). zaštitu (security). pouzdanost podataka u slučaju otkaza sistema.Java Servlet tehnologija je osnova svih Veb aplikacionih tehnologija (JSP.2 Kontejner Veb komponenti Veb komponente su podržane servisima koje obezbeñuje Veb kontejner. JavaServer Faces i JavaServerPages Standard Tag Library). Veb aplikacije moraju neposredno da komuniciraju sa SUBP. Konfiguracione informacije aplikacije se nalaze u XML datoteci koja se naziva Opisivač rasporeda Veb aplikacije (Veb application deployment descriptor .0. konkurentnost (concurrency).DD).

preko koga se pristupa Veb komponentama).2. Veb modul ima specifičnu strukturu.2. rasporeñivanja i izvršenja Veb aplikacije se sastoji iz sledećih koraka: 1. 5.4 Životni ciklus Veb aplikacije Proces kreiranja. Veb modul može biti organizovan (rasporeñen) kao nespakovana struktura datoteka ili može biti pakovan u JAR datoteku koja je prilagoñena Veb aplikacijama (WAR – Web Archive File). 2. 3. Na vrhu Veb modula je dokument koren (document root) aplikacije (slika 20 [11]).5. Klijent pristupa URL-u koji referencira na Veb aplikaciju. datoteka mora da sadrži i runtime opisivač rasporeda (runtime deployment descriptor). Kompajliraju se se Veb komponente i pomoćne klase na koje ukazuju komponente. Da bi se WAR datoteka postavila na Veb server. Pravi se opisivač rasporeda (deployment descriptor) za Veb aplikaciju (kreiranje Veb aplikacije). 5.5 Veb modul Veb modul predstavlja organizacioni okvir unutar koga se postavlja Veb aplikacija. 4. Aplikacija se postavlja u Veb kontejner i izvršava se (izvršenje Veb aplikacije). Pravi se programski kod Veb komponenti (kreiranje Veb aplikacije). . Runtime opisivač rasporeda je XML datoteka koja sadrži informacije o kontekstu Veb aplikacije (gde je početak-koren Veb aplikacije. 6. Aplikacija se pakuje u rasporedljivu (deployable) jedinicu (rasporeñivanje Veb aplikacije).

.). classes: direktorijum koji sadrži klase serverske strane: servlete. slike... .tld: datoteke za opis tag biblioteka (Tag library descriptor files). klase i arhive klijentske strane i statičke Veb resurse (HTML strane. lib: direktorijum koji sadrži biblioteke JAR arhiva koje pozivaju klase sa serverske JabaBeans komponente.Slika 20 : Veb modul struktura Dokument koren sadrži: JSP strane. Poddirektorijum /WEB-INF/ koji sadrži sledeće datoteke i direktorijume: strane. web. utility klase i tags: direktorijum koji sadrži tag datoteke koje su implementacije tag biblioteke.xml: opisivač rasporeda (deployment descriptor) Veb aplikacije. .

Uloga servlet kontejnera je prikazana na slici 22 [3]: .http obezbeñuju interfejse i klase za pisanje servleta.5. Nakon izvršenja servleta HTTPServletResponse objekat se šalje nazad do kontejnera koji ga konvertuje u HTTP Response i vraća ga nazad do klijenta.servlet. koji treba da se napuni sa rezultatima izvršenja servleta. Paketi javax.Svi servleti moraju da implementiraju Servlet interfejs. Nakon toga kontejner poziva service() metodu servleta i kao argumente mu šalje HTTPServletRequest i HTTPServletResponse objekat.servlet i javax.3 Java Servlet Tehnologija Servleti su Javine klase koje dinamički procesiraju zahteve i konstruišu odgovore. Servlet kontejner (Servlet Container) Veb servera konvertuje zahtev u HTTPServletRequest objekat. Interakcija izmeñu Veb klijenta i servleta je prikazana na slici 21 [3]: Slika 21: Inter akcija izmeñu Veb klijenta i servleta Klijent šalje HTTP zahtev do Veb servera.

Kontejner poziva init() metodu pojavljivanja. Implementacija kontejnera kod različitih JavaEE okruženja se može razlikovati ali interfejs izmeñu kontejnera i servleta je isti za bilo koje JavaEE okruženje i odreñeno je specifikacijom servleta. Pojavljivanje se uništava i markira se za mehanizme skupljanja smeća (garbage collection). .Slika 22: Uloge servlet kontejnera Servlet kontejneri obrañuju zahteve koje šalju klijenti. kontejner poziva destroy() metodu. Kontejner upravlja životnim ciklusom servleta koji se sastoji iz sledećih koraka: Kontejner servleta kreira pojavljivanje (instancu) servleta. Kada kontejner dobije zahtev od klijenta prosleñuje ga do servleta pozivajući njegovu service() metodu. Kontejner mora da obezbedi da: service() metoda servleta neće biti pozvana pre nego što se izvrši init() metoda servleta. Pre nego što se uništi pojavljivanje. prosleñuju zahteve do servleta i vraćaju odgovor od servleta do klijenta.

Pored URL strane kojoj se pristupa mora se naznačiti i metoda koaj će biti korišćena pri slanju zahteva. HEAD. GET i POST. HEAD metoda prihvata informacije o dokumentu ali ne prihvata sadržaj samog dokumenta. Telo zahteva je ulazna datoteka za server koji je čita i u njoj .) i vrši preusmeravanje (dispatching) poziva do odgovarajuće metode (doGet(). POST.. 5. . dužinu i tip zahteva. Podatke ukoliko su prihvaćeni preko forme i Dopunske informacije zaglavlja (header info) koje se odnose na čitač. Tri najčešća korišćenja metode slanja zahteva su HEAD.1 Metode slanja zahteva Veb serveru Čitač (browser) treba da spakuje podatke koji su prihvaćeni preko ekranske forme i da ih prosledi preko HTTP zahteva (request) do Veb servera. Kada service() metoda prihvati zahtev od kontejnera ona prepoznaje tip zahteva (GET. GET metoda se koristi kao podrazumevana (default) metoda za sve Veb zahteve.. doPost(). Kada se koristi GET metoda.3. svi podaci koji su bili uneti preko ekranske forme se prosleñuju do stringa zahteva (request string). svi podaci koji su bili uneti preko ekranske forme se pakuju i unose u telo zahteva (request body). doHead()) u zavisnosti od tipa zahteva. tada se može desiti da je stara verzija sačuvana u kešu i da se ona pri pozivu prikaže na ekranu. HTTP zahtev sadrži: URL (adresa) strane kojoj se želi pristupiti. Podaci se dodaju korišćenjem ključ=vrednost parova (key+value pairs). Navedenim metodama se takoñe prenosi HTTPServletRequest i HTTPServletResponse objekti. Postoje potencijalno dva problema kada se koristi GET metoda: Ukoliko se poziva neka strana.Servlet neće biti uništen dok se pre toga ne izvrši destroy() metoda servleta. Kada korisnik poziva direktno neku stranu preko URL-a čitač podrazumeva da je u pitanju GET metoda slanja zahteva. Kada se koristi POST metoda. GET i POST se koriste kada se poziva Veb aplikacija. Iznos podataka koji se može poslati je ograničen. koja je već bila pozvana. ali to rade na različite načine.

Održavanje stanja klijenta na serveru je praćenje sesije (session tracking). Server šalje klijentu podatke za identifikaciju. Klijent se konektuje na server. Kod HTTP-a je stateless protokol koji je zasnovan na zahtev-odgovor modelu (request-response model). Veb server ne zna sa kojom sesijom komunicira. Pošto je HTTP stateless protokol.3 Prać enje sesije preko servleta Sesija je serija povezanih interakcija. Podaci se čuvaju u nekom skladištu podataka. Server izvršava zahtev i šalje odgovor.3.2 Stateless i Stateful tipovi protokola Postoje dva tipa internet komunikacionih protokola: Stateless i Stateful. server pamti ko je klijent i šta je uradio od trenutka uspostavljanja konekcije. Svaki par zahtev-odgovor je izolovana transakcija. 5. Scenario stateful tipa tipa protokola je sledeći: 1. Kod POST metode ne postoje ograničenja u veličini podataka koji će biti poslati do servera. 2. Klijent prekida konekciju sa serverom. Klijent izvršava seriju operacija preko konekcije. tada se obrañuju podaci vezani za tog klijenta. 3. 2. 3. Postoje dva načina da on sazna koja je to sesija: 1. 78 . izmeñu jednog klijenta i Veb servera. Svaki put kada klijent šalje zahtev on treba da se identifikuje. koja se dešava u nekom periodu vremena.prepoznaje imena promenljivih i njihove vrednosti. 2. Klijent svaki put kada postavlja zahtev serveru šalje te podatke koji ga identifikuju. 5.3. Kaže se da konekcija ima stanje. Klijent se konektuje na server i šalje mu zahtev. Klijent prekida konekciju sa serverom. Meñusobno se razlikuju po načinu uspostavljanja konekcije izmeñu klijenta i servera. Scenario stateless tipa protokola je sledeći: 1. Za stateful tip protokola.

Kada servlet kreira sesiju (objekat sesije) on može preko nje da čuva stanje sesije. 2. Klijent preko stringa zahteva šalje podatke za identifikaciju. Klijent unosi identifikacione podatke preko forme za logovanje a zatim šalje podatke za identifikaciju do servera preko post metode. on preko podataka identifikacije zna ko je klijent. dodajući na njegov kraj nove identifikacione podatke klijenta. može da mu pošalje nove identifikacione podatke. Servlet kreira sesiju (daje joj broj) i šalje ga do klijenta za novu identifikaciju klijenta. Servlet šalje nevidljiva polja. 3. u tekućoj sesiji. Nakon toga klijent šalje zahtev koji može da promeni početno stanje u neko novo (tekuće) stanje sesije. Stanje sesije se može čuvati tranzijentno i perzistentno. Puno HTML stranu koja ga poziva sa skrivenim poljima za identifikaciju. 4.Kada sesija izgubi stanje tada ona prestaje da se izvršava (prestaje da postoji). koja čuvaju stanja sesije . Tranzijentnost stanja sesije se obezbeñuje na nekoliko načina: 1. Nove identifikacione podatke servlet šalje klijentu na nekoliko načina: 1. Kada server prihvati zahtev. koji su fiksirani u URL-u. Servlet nakon identifikovanja klijenta. Server identifikuje sesiju i prati njeno stanje na sledeći način: Klijent šalje podatke za identifikaciju do servleta. Podaci za identifikaciju klijenta se mogu poslati na dva načina: 7. 8. odnosno zna koja je sesija aktivna. Prepisuje URL sa HTML strane koja ga poziva . 2. Trajanje sesije je odreñeno stanjem sesije.Praćenje sesije preko servleta se odvija tako što se sesija pokreće identifikovanjem klijenta koji je pozvao servlet (jedna sesija je vezana za jednog klijenta). do klijenta. koji će biti validni dok je aktivna tekuća sesija. 79 . Početno stanje sesije je odreñeno identifikacionim podacima klijenta. Šalje kolačiće (cookies) do klijenta koji služe za novu identifikaciju klijenta.

životni ciklus veb aplikacije i veb modul). Kada se stanje čuva perzistentno. 4. Aplikacija se pakuje u rasporedljivu (deployable) jedinicu (rasporeñivanje Veb aplikacije). 5. koja čuvaju stanje sesije. trajanje sesije je ograničeno vremenom trajanja identifikacionih podataka klijenta i izvršavanjem čitača koji je pozvao servlet. kontejner veb komponenti. stanje sesije je ograničeno vremenom trajanja identifikacionih podataka klijenta. U tom kontekstu. praćenje sesije preko servleta i životni ciklus servleta. 5. Kada seee stanje čuva tranzijentno. Datoteke ili baze podataka. 2. Aplikacija se postavlja u Veb kontejner i izvršava se (izvršenje Veb aplikacije). kao i JavaServlet tehnologija. Na taj način smo realizovali četvrti cilj istra živanja (Dati pregled JEE tehnologije). Servleta koji generišu i šalju kolačiće. vremenom trajanja kolačića koli su poslati do klijenta i dostupnošću skladišta podataka koja čuvaju stanje sesije. objašnjene su metode slanja zahteva veb serveru. do klijenta.Perzistentnost stanja sesije se obezbeñuje preko: 1. Kompajliraju se Veb komponente i pomoćne klase na koje ukazuju komponente.4 Životni ciklus servleta 1. 6. Pravi se opisivač rasporeda (deployment descriptor) za Veb aplikaciju (kreiranje Veb aplikacije). 5. 2. 80 . Klijent pristupa URL-u koji referencira na Veb aplikaciju. Pravi se programski kod Veb komponenti (kreiranje Veb aplikacije) ). Stateless I Stateful tipovi protokola. Kada se čitač zatvori stanje sesije se gubi. 3.4 Sažetak U ovom poglavlju dat je prikaz JEE tehnologije.3. Objašnjeni su koncepti veb aplikacije (veb komponente.

faza analize uključuje akcije prikupljanja zahteva koji se oblikuju u priče korisnika (User Stories – US). koja se može nacrtati ručno (ručno nacrtana forma). Priče korisnika se koriste da bi se planirala isporuka softvera (Release Planning) i kreirao test prihvaćenosti (Acceptance Test). fazi projektovanja softvera koriste se metafore kao pojednostavljene slike softverskog sistema koji se razvija i CRC kartice (Class. odnosno na manje delove kojima se opisuju diskretne razvojne aktivnosti. To znači da test prihvaćenosti koji nije prošao premešta se u sledeću iteraciju. umesto tekstom.6. 81 . a primenom XP postupaka. Planiranjem isporuke razvojni tim vrši procenu svake priče korisnika. STUDIJSKI PRIMER U ovom poglavlju prikazan je razvoj JEE aplikacije (ShopCart aplikacija) kroz faze procesa životnog ciklusa softvera. odnosno procenjuje se vreme potrebno za implementaciju date priče i donosi se odluka koja priča ima najviši prioritet implementacije. Prva faza razvoja softvera. Na slici 23 prikazan je primer plana isporuke: Priča (zadaci) Logovanje Pretraživanje knjiga Obrada porudžbine korisnika Procenjeno vreme Itera cija 1 Itera cija 2 Itera cija 3 Itera cija n za implementaciju 3h 6h 16 h Slika 23. Svaka iteracija treba da kupcu isporuči neku vrednost. odnosno za predstavljanje klasa objekata i saradnje meñu klasama. Kada se proceni veličina isporuke. Responsibilities. ona se deli na iteracije. U drugoj fazi. Korisnička priča nije završena sve dok ne proñe test prihvaćenosti. Model je skica. Collaboration cars) za projektovanje softverskog sistema. Napomena1: Priča korisnika se može podeliti na zadatke. Plan isporuke x x x Napomena 2: Svaki zadatak se može predstaviti modelom.

Korisnik verifikuje da kod odgovara njegovim poslovnim potrebama. 82 . Za jedinično testiranje koda u ovom radu se koristi JUnit alat za jedinično testiranje integrisan u Eclipse razvojnom okruženju. Nakon toga oni vrše integraciju (na mašini za integraciju) i vrše testiranje (svi testovi moraju uspešno da se izvše). Programeri svoj posao na modulu. klasi ili komponenti rade sve dok ne završe.CRC kartica se može predstaviti na sledeći način (slika 24): Slika 24: CRC kartica U fazi implementacije softvera u XP-u naglašava se važnost implementacije jediničnih testova pre implementacije samog koda kako bi proverili da li kreirani kod zadovoljava funcionalnosti koje su opisane u korisničkim pričama. Sklopljena verzija softvera je dobra ili uspešna. Tada je softver spreman za testiranje ili pregled od strane korisnika i tima. ako sistem proñe testove za verifikaciju i „dimne“ testove.

1 ShopCart servlet aplikacija ShopCart aplikacija je jednostavna e-commerce aplikacija koja je razvijena korišćenjem servleta. odnosno knjiga iz oblasti softverskog inženjerstva.Na slici 25 prikazan je postupak razvoja softvera primenom XP postupaka. Faze razvoja ShopCart aplikacije su sledeće: 83 . Ova aplikacija ne uzima u obzir logistiku isporuke. Slika 25: Predlog postupka razvoja softvera primenom XP postupaka 6. Sadrži četiri stranice i omogućava on-line kupovinu proizvoda.

Korisnik potvrñuje porudžbinu i sistem prikazuje korisniku broj potvrde porudžbine.6. Korisnik zahteva da doda izabrane proizvode u korpu. kao što je navedeno vrši se prikupljanje zahteva koji se oblikuju u priče korisnika (User Stories – US). Sistem treba da omogući korisniku da doda izabrane proizvode u korpu i da unese sve potrebne podatke za plaćanje.1 Korisnički zahtevi (planiranje) U fazi analize. Priče korisnika se zatim koriste da se isplanira isporuka softvera (Release Planning) i kreira test prihvaćenosti (Acceptance Test) (slika 26): Slika 26: Prikuplj anje zahteva korisnika u fazi analize Priče korisnika (User Stories): US1: Korisnik se loguje i pristupa listi proizvoda. Planiranje isporuke (Release Planning): Priča korisnika (zadaci) Logovanje Listanje proizvoda Dodavanje korpu proizvoda Procenjeno vreme Itera cija 1 Itera cija 2 Itera cija 3 za implementaciju 3h 5h u 16 h 14 h x x x x Potvrñivanje porudžbine 84 .1.

Servlet koji generiše Catalog stranicu izvršava sledeće operacije: 85 . Korisniku se prikazuje korpa za izabranim proizvodom. Svaki zadatak je predstavljen modelom (formama koje treba implementirati): Prva stran ica: Welcome Prva stranica je jednostavna HTML login stranica (slika 27): Slika 27: Login stranica Druga stran ica: Katalog Pozdravna (Welcome) stranica usmerava ka servletu Catalog. Pritisne se dugme „Add to cart“ za izabrani proizvod i proizvod se doda u korpu.Test prihvaćenosti (Acceptance Tests): AT1: Unosi se ime kupca kao login podatak. Korisniku se prikazuje lista proizvoda i pozdravna poruka. Korisnik zatim unosi potrebne podatke za plaćanje (broj kreditne kartice. Sistem prikazuje broj potvrde porudžbine i zahvalnu poruku. koji prikazuje katalog proizvoda. tip kreditne kartice i datum isteka kreditne kartice) i pritisne dugme „Check out“.

Kreira skup konekcija na bazu podataka (database connection pool) za sve servlete. pozdravlja korisnika (slika 28). Vrši validaciju korisnika i: Ako korisnik već postoji u bazi. Slika 28: Katalog stranica sa postojećim korisnikom 86 .

87 . sa opcijom na dnu stranice za kompletiranje kupovine (slika 30).Dodaje novog korisnika u bazu (slika 29). u više navrata). Treća stranica: ShowCart Treća stranica aplikacije prikazuje sadržaj korpe korisnika do tada (sve artikle koje je korisnik dodao do tada. Slika 29: Katalog stranica sa novim korisnikom Prikazuje katalog.

Na slici 31 je prikazana confirmation stranica: Slika 31: stranica koja prikazuje broj potvrñene porudžbine 88 .Slika 30: Shopping Cart stranica Četvrta stranica: confirmation Četvrta i poslednja stranica aplikacije dodaje novu porudžbinu (sa odgovarajućim artiklima) i prikazuje korisniku broj potvrde (confirmation number).

u drugoj fazi.1. Slika 32: Korišćenje CRC kartiva u fazi projekt ovanja softverskog sistema Pojednostavljena slika softverskog sistema. Responsibilities.6. odnosno za predstavljanje klasa objekata i saradnje meñu klasama.2 Projektovanje Kao što je napomenuto. fazi projektovanja softvera koriste se metafore kao pojednostavljene slike softverskog sistema koji se razvija i CRC kartice (Class. odnosno metafora sistema prikazana je na sledeći način (slika 33): Slika 33: Met afora sistema 89 . Collaboration cars) za projektovanje softverskog sistema.

. 36. odnosno prikazane su CRC kartice (slike 35. . Collaborations: HttpServlet Catalog ShowCart Confirmation 90 . .vrši validaciju user-a. ShowCart.Ova aplikacija koristi nekoliko klasa.kreira standardne HTML elemente za vrh stranice. 38.generiše hedere i futere za HTML dokument. 42): Slika 34: Veze izmeñu klasa Class name: ShopCartServletBase Superclasses: HttpServlet Subclasses: Catalog.prikazuje katalog proizvoda. 41.proverava da li user postoji u bazi ili dodaje novog user-a u bazu podataka. . 37. .obezbeñuje skup konekcija. Confirmation Responsibilities: . 39. uključujući servlete i pomoćne klase. 40. Slika 34 prikazuje veze izmeñu klasa.

.kreira skup konekcija i postavlja ih na lokaciju gde svi drugi servleti mogu da im pristupe.Slika 35: CRC 1_ShopCartServletBase Class name: Catalog Superclasses: ShopCartServletBase Subclasses: Responsibilities: Collaborations: . Slika 36: CRC 2_Catalog Class name: ShowCart Superclasses: ShopCartServletBase Subclasses: ShoppingCartItem.prikazuje sadžaj korpe kupca.privata inicijalne parametre od servlet konteksta i dodaje skup konekcija aplikacionom kontekstu. ShoppingCart Responsibilities: Collaborations: . količina. ShoppingCartItem ShoppingCart Slika 37: CRC 3_ShowCart Class name: ShoppingCartItem Superclasses: ShowCart Subclasses: Responsibilities: Collaborations: . uz opciju ShopCartServletBase za kompletiranje nabavke.). ShowCart itd. ShopCartServletBase .entitet koji opisuje „item“ (ID. ShoppingCart Slika 38: CRC 4_ShoppingCartItem 91 .deklariše konstante za SQL pristup.

Class name: ShoppingCart Superclasses: ShowCart Subclasses: Responsibilities: Collaborations: . Slika 42: CRC 8_LineItem Collaborations: Order 92 .prikazuje sadržaj shopping cart-a. Slika 39: CRC 5_ShoppingCart Class name: Confirmation Superclasses: ShopCartServletBase Subclasses: Responsibilities: Collaborations: . ShowCart .učauruje podatke o porudžbini i dodaje Confirmation porudžbinu u bazu.prihvata shopping cart i podatke o ShopCartServletBase plaćanju i generiše porudžbinu. LineItem Slika 41: CRC 7_Order Class name: LineItem Superclasses: Subclasses: Responsibilities: .izračunava ukupnu vrednost korpe i ShoppingCartItem prikazuje tu vrednost u valuti. Order Slika 40: CRC 6_Confirmation Class name: Order Superclasses: Subclasses: Responsibilities: Collaborations: .prosleñuje artikal do baze.

6.1.3 Implementacija Već je napomenuto da programeri u XP-u prvo pišu test, a posle toga kodiraju (slika 43).

Slika 43: Faza implementacije u XP-u

6.1.3.1 Test iranje e ntiteta Testiraće se klasa ShoppingCart. TestShoppingCart slučaj testiranja testira metodu getCartTotal(): package com.shopcart.servlet.lib.test; import com.shopcart.servlet.lib.CartItem; import com.shopcart.servlet.lib.ShoppingCart; import junit.framework.TestCase; public class TestShoppingCart extends TestCase { protected ShoppingCart shoppingCart = null; static int itemNum = 0; protected ShoppingCartItem[] items; public TestShoppingCart(String name) { super(name); } protected void setUp() throws Exception { super.setUp(); shoppingCart = new ShoppingCart(); items = new ShoppingCartItem [4]; for (int i = 0; i < items.length; i++) { items[i] = generateRandomCartItem(); shoppingCart.addItem(items[i]); } 93

} protected void tearDown() throws Exception { shoppingCart = null; items = null; super.tearDown(); } public void testGetCartTotal() { double expectedReturn = 0.0; for (int i = 0; i < items.length; i++) { expectedReturn += items[i].getExtendedPrice(); } double actualReturn = shoppingCart.getCartTotal(); assertEquals("cart total", expectedReturn, actualReturn, 0.01); } private ShoppingCartItem generateRandomCartItem() { ShoppingCartItem c = new ShoppingCartItem (); c.setItemName("Test Item " + ++itemNum); c.setItemPrice(Math.random() * 1000); c.setQuantity((int) Math.round(Math.random() * 100)); return c; } Klasa TestShoppingCart nasleñuje klasu JUnit-a TestCase, nasleñujući tako metode okvira za pokretanje testova. Metoda setUp(), koja se pokreće pre svakog testa, kreira „fixture“ nad kojim se pokreću testovi. Da bi metoda getCartTotal() radila, shopping cart mora da sadrži artikle. Da bi se generisali artikli, mora da postoje proizvodi. Prema tome, postoji nekoliko metoda za generisanje neophodnih objekata kako bi se kreirao test metode getCartTotal(). Metoda setUp() poziva setUp() metodu klase iz koje je izvedena (super.setUp(); ) radi podešavanja inicijalnih vrednosti u nadreñenoj klasi (parent class). Zatim se kreira novi ShoppingCart objekat i niz CartItem. Iterira se kroz niz, poziva se metoda generateRandomCartItem() da bi se popunio niz artiklima. generateRandomCartItem() metoda poziva metodu getProduct(), koja generiše besmislen objekat tipa Product i nasumičnu (random) cenu, i postavlja nasumičnu količinu za cart item. Cena i količina su dve vrednosti koje su bitne za izračunavanje ukupne vrednosti korpe.
10

10

U Javi ključna reč super se koristi da ukaže na klasu koja je na prvom višem nivou hijerarhije od klase, koja u okviru neke od svojih metoda, koristi ključnu reč super.

94

Niz artikla se koristi na dva mesta. Test kod mora da proveri da li shopping cart dodaje artikle ispravno. Da bi se izvela ova provera, mora ručno da se izračuna ukupna vrednost svih artikla u korpi. To je glavna jedinica zadatka metode testGetCartTotal(). U metodi se iterira kroz niz i izračunava očekivana vrednost artikla. Zatim se poziva aktuelna getCartTotal() metoda i vrši se poredjenje vrednosti pomoću metode assertEquals() koja je deo JUnit okvira. Cilj testova je da se generiše očekivana i stvarna vrednost i da se uporede. Ako su te dve vrednosti jednake, test prolazi. Metoda uključuje deskritivni string koji identifikuje test. Poslednja vrednost je delta, ukazujući na maksimalnu vrednost tolerancije za nejednakost vrednosti koje se uporeñuju.

Slika 44: JUnit prikazuje uspešan TestShoppingCart test

6.1.3.2 Test iranje kr itičnih klasa U ovoj aplikaciji najsloženija (i prema tome najkritičnija) klasa za testiranje je ona koja dodaje nove porudžbine u bazu (Order.java). Deklarativni deo klase TestOrder:

95

DB_URL. PASSWORD).lib. connection = dbPool.servlet.jdbc. private static final String DRIVER_CLASS = "com. private int orderKey. private DbPool dbPool. protected void setUp() throws Exception { super. } 96 . Sadrži i konstante za konekciju na bazu podataka jer se ne mogu tako lako dobiti iz opisivača rasporeda web aplikacije. private static final String TEST_NAME = "Maja". private static final int TEST_USER_KEY = 1. private static final String SQL_DELETE_ORDER = "delete from orders where order_key = ?".package com. } protected void tearDown() throws Exception { deleteOrder(addedOrderKey).test. private static final String TEST_CC_NUM = "1111111111111111". dbPool.getConnection(). orderDb = new OrderDb().tearDown().setDbPool(dbPool). private static final String TEST_CC_EXP = "11/1111".Driver". private static final String DB_URL = "jdbc:mysql:// localhost:3306/shopcart". super. USER. orderDb = null.mysql.shopcart. dbPool = new DBPool(DRIVER_CLASS. public class TestOrder extends TestShoppingCart { private Order order = null.setUp(). private static final String SQL_SELECT_ORDER = "select * from orders where order_key = ?".release(connection). orderDb. private static final String USER = "root". private static final String TEST_CC_TYPE = "Visa". private static final String PASSWORD = "maja". } Klasa TestOrder sadrži konstante koje definišu SQL upite i test podatke. private Connection connection. Listing 17. Sledeće dve metode test klase TestOrder su nasleñene metode setUp() i tearDown().3 The declaration section of TestOrderDb public TestOrder (String name) { super(name).

int rowsAffected = 0. ps. ps.setInt(1.executeUpdate().next().Metode setUp() i tearDown()su „protected“ tako da drugi slučajevi testiranja mogu da naslede ove metode korišćenjem ključne reči „super“ (kao što se i može videti iz primera). PreparedStatement ps = null. } finally { 97 . addedOrderKey).setCcExp(rs. Učitavaju porudžbinu iz baze podataka (da bi je uporedili sa novododatom) . a zatim se nova porudžbina briše.getInt("order_key")). o.5 These two } catch (Exception ex) { throw new RuntimeException(ex. PreparedStatement ps = null.getMessage()). addedOrderKey). } catch (Exception ex) { throw new RuntimeException(ex.setCcType(rs.getMessage()).getString("CC_NUM")). o. ResultSet rs = null. try { ps = connection. o.getString("CC_TYPE")). } private void deleteOrder(int addedOrderKey) { Connection c = null.getString("CC_EXP")).setInt(1.prepareStatement(SQL_DELETE_ORDER). Sledeće dve metode predstavljaju „fixture“ testa. private Order getOrderFromDatabase() { Order o = new Order(). o. } catch (SQLException ignored) { } } return o.executeQuery().prepareStatement(SQL_SELECT_ORDER).setUserKey(1). try { ps = connection.close().setCcNum(rs. TearDown() metoda super klase briše porudžbinu (order) koja je dodata u ovom slučaju testiranja (test case). Metoda setUp() super klase kreira neophodne „fixtur-e“ (artifakte) za Order objekat. rowsAffected = ps.Listing 17. rs.setOrderKey(rs. } finally { try { if (ps != null) ps. rs = ps. o. if (rowsAffected != 1) throw new Exception("Delete failed").

orderDb.setUserKey(TEST_USER_KEY).getUserKey()).getUserKey(). actualOrder). if (c != null) c. TEST_NAME. dbOrder. dbOrder. actualOrder.getCcExp(). actualOrder. dbOrder. dbOrder. assertEquals("user key". public void testAddOrder() throws SQLException { Order actualOrder = new Order().setCcType(TEST_CC_TYPE). deleteOrder(addedOrderKey). assertEquals("cc exp". assertEquals("cc num".close(). } catch (SQLException ignored) { } } } Poslednja metoda je zapravo test metoda. Kreira simuliranu porudžbinu. actualOrder. koristi Order objekat da je doda u bazu podataka a onda uporeñuje rezultate upitom nad bazom podataka koji učitava slogove.try { if (ps != null) ps. actualOrder. addedOrderKey = orderDb. actualOrder.close().getCcType()). actualOrder. } 98 .setCcNum(TEST_CC_NUM).getCcNum().getCcType(). actualOrder.setCcExp(TEST_CC_EXP). assertEquals("cc type". Order dbOrder = getOrderFromDatabase().getLastOrderKey().addOrder(shoppingCart.getCcNum()). actualOrder.getCcExp()).

servlet. suite.shopcart.class).TestShoppingCart.framework.shopcart. public class AllTests extends TestCase { public AllTests(String s) { super(s). suite.3.class).*. Aplikacija uključuje dva slučaja testiranja koji su u relaciji i pokreću se u istom skupu (suit): package com.servlet.shopcart. } public static Test suite() { TestSuite suite = new TestSuite().addTestSuite(com.1.3 Skup testova (Test suites) TestSuite je kolekcija pojedinačnih slučajeva testiranja.test. import junit. return suite.test.Slika 45: JUnit prikazuje uspešan TestOrd er test 6. 99 .test.TestOrder.lib.servlet.lib.addTestSuite(com.

JUnit je projektovan da automatski prihvata slučajeve testiranja u poseban paket. pa su prosleñene vrednosti objekti klase za klase slučajeva testiranja. U skupu testova pokretač testova pokreće slučajeve testiranja po redosledu. Nasleñuje klasu TestCase i sadrži static metodu suite(). U metodi suite() se kreira novi TestSuite i dodaje svaka klasa slučaja testiranja. Skup testova omogućava da programer kontroliše koji testovi će se pokretati zajedno. Parametar metode addTestSuite() je Class klasa. Slika 46: JUnit prik azuje uspešan AllTests test 100 .} } Klasa AllTests je jednostavna.

} private void getPropertiesFromServletContext() {Listing 2. dbUrl. driverClass = sc. user.*. } private DbPool createConnectionPool() { DbPool p = null.util. import java. import com. private String dbUrl. public void init() throws ServletException { getPropertiesFromServletContext(). private String password.6. import javax. import javax.http. public class Catalog extends HttpServlet { static final private String SQL_INS_USERS = "insert into users (name) values (?)".getInitParameter("password").shopcart. import java.2 The declaration and init() sections of the Catalog servlet ServletContext sc = getServletContext().*. static final private String SQL_SEL_PRODS = "select * from products". Deklaracija i init() Catalog servleta: com. password). private String user.getInitParameter("user").servlet. dbPool).getInitParameter("dbUrl").servlet. user = sc. private String driverClass.*.setAttribute(CONN_POOL_ID.getInitParameter("driverClass").*.3.1. addPoolToApplication(createConnectionPool()). 101 . try { p = new DbPool(driverClass. static final private String SQL_SEL_USERS = "select name from users where name = ?".servlet.shopcart.*. import java. } private void addPoolToApplication(DbPool dbPool) { getServletContext().4 Izvorni kod ShopCart aplikacije Nakon uspešno izvršenih testova prikazuje se detaljan kod ShopCart aplikacije.*.io. dbUrl = sc.lib. password = sc.servlet.sql.

} return p.log("Connection Pool Error". DbPool pool = getConnectionPool(). Metoda init() obrañuje (hendluje) dva zahteva: prihvata inicijalne parametre od servlet konteksta i dodaje skup konekcija aplikacionom kontekstu. generatePagePostlude(out). try { con = pool. Uobičajena je praksa da se u veb aplikaciji koristi skup konekcija i većina aplikacionih servera i okvira (frameworks) uključuju klase za skup konekcija. razlog izuzetka je logovanje preko log() metode servlet konteksta.println("</h3><p>"). Metoda getPropertiesFromServletContext() uzima odgovarajuće vrednosti iz konfiguracionog fajla i dodeljuje ih promenljivim servleta. out. Metoda createConnectionPool() kreira skup konekcija na osnovu vrednosti parametara. sqlx). sqlx). U ovom primeru se koristi klasa DbPool koja obezbeñuje skup konekcija na bazu podataka. userName. Ako se javi greška. con). String userName = validateUser(request. out). Skup konekcija je onda smešteno u servlet kontekstu aplikacije. } finally { 102 .HttpServletResponse response) throws ServletException. IOException { PrintWriter out = generatePagePrelude(response. userName). con). displayCatalog(out. Drugi zahtev koji init() metoda obrañuje je kreiranje skupa konekcija i njihovo postavljanje na lokaciju gde svi drugi servleti mogu da im pristupe. } Catalog klasa počinje deklaracijom konstanti za SQL pristup i promenljivih. Konekcija na bazu podataka je definisana u web. kako bi drajver klasa i login informacije mogle da se promene a da ne mora da se rekompajlira aplikacija.xml fajlu.getConnection(). handleReturnOrNewUser(out.log("SQL error". Prva od servlet specifičnih deklaracija je za init() metodu koja je odgovorna za kreiranje skupa konekcija na bazu podataka (database connection pool). Sledeća metoda Catalog servleta je doPost(): public void doPost(HttpServletRequest request. addUserToSession(request.} catch (SQLException sqlx) { getServletContext(). odnosno skup konekcija će biti dostupno drugim servletima. Connection con = null. } catch (SQLException sqle) { getServletContext(). "Catalog").

103 .DbPool. Prvi zadatak doPost() metode je generisanje uvodne stranice. PrintWriter out = response.servlet. Ova metoda se ne pojavljuje u Catalog servletu.*. import javax. import java. import javax.setContentType(CONTENT_TYPE). Postoje zajednički taskovi koje svi servleti moraju da izvrše. U ovoj aplikaciji svaki servlet mora da dobije referencu na skladište konekcije i generiše hedere (headers) i futere (footers) za HTML dokument.println("<head><title>Logon</title></head>"). doPost() metoda poziva generatePagePrelude() metodu: private PrintWriter generatePagePrelude(HttpServletResponse response) throws IOException { response. out. package com.println("<html>"). kohezivne metode. Jedna od prednosti kreiranja granularnih.shopcart. što znači da su metode veoma male i mnogobrojne.shopcart. doPost() metoda Catalog servleta je primer primene ove tehnike.servlet.sql.*. Kohezivnost metoda vodi ka granularnosti. kohezivnih metoda je u tome što olakšava identifikaciju metoda koje se mogu generalizovati unutar „parent“ klase.util. import com.println("<body>").servlet. import java.io.release(con).SQLException. Kohezivne metode izvode jedan zadatak (task) i ne više od toga. out. return out.pool.http.*.lib.*. } } Dobra praksa je da se kreiraju veoma granularne. Nalazi se u osnovnoj klasi servleta koja je nazvana ShopCartServletBase.servlet.getWriter(). čineći kod lakšim za ponovnu upotrebu. out. import java. } Ova metoda kreira „print writer“ objekat i koristi ga da kreira standardne HTML elemente za vrh stranice.

protected DbPool getConnectionPool() { DbPool pool = (DbPool) getServletContext().log("Pool cannot be loaded").println("<head><title>" + title + "</title></head>"). } } Metoda validateUser() vrši validaciju usera: private String validateUser(HttpServletRequest request.getParameter("username"). String title) throws IOException { response. out. } Metoda doPost() dalje poziva getConnectionPool() metodu iz osnovne (base) klase.html"). out. out.").println("</body></html>"). HttpServletResponse response) throws IOException { HttpSession session = request. } Listing 2.public class ShopCartServletBase extends HttpServlet { static final protected String CONN_POOL_ID = "DbPool". PrintWriter out = response. out.println("<h3>Hello.getWriter().sendRedirect("Welcome. protected PrintWriter generatePagePrelude(HttpServletResponse response.4 The generatisting 2.5 EMotherServletBase consolidates common servlet methods.println("<body>"). return userName.equals("")) out. kako bi servlet hendlovao pristup bazi podataka. return session. return out. if (pool == null) getServletContext().PrintWriter out) { String userName = request. if (userName. static final protected String CONTENT_TYPE = "text/html". " + userName + ". return pool.getSession(false).println("<h1>Error! You must enter a user name!"). if (session == null) response.println("<html>").setContentType(CONTENT_TYPE) . 104 .getAttribute(CONN_POOL_ID). } protected HttpSession getSession(HttpServletRequest request. } protected void generatePagePostlude(PrintWriter out) { out.

.setString(1. String userName) throws SQLException { PreparedStatement ps = c. ps. session. } Ova metoda se sastoji od drugih pomoćnih metoda.prepareStatement(SQL_SEL_USERS). userName). userName). Connection con) throws SQLException { if (isNewUser(con. U suprotnom. else { addUser(con..getSession(true). u cilju kreiranja što je više moguće granularnog koda.println("Welcome back to the store!").executeQuery(). out. } out. } Metoda displayCatalog() prikazuje katalog proizvoda: 105 . String userName) { HttpSession session = request. String userName) throws SQLException { PreparedStatement psi = c. return rs. metoda doPost() kreira sesiju (session) i dodaje usera u sesiju: private void addUserToSession(HttpServletRequest request. psi. Metoda isNewUser() proverava da li user već postoji u bazi: private boolean isNewUser(Connection c.Metoda doPost() dalje uspostavlja konekciju na bazu podataka unutar try.prepareStatement(SQL_INS_USERS). } Ako ResultSet sadrži rekord onda user postoji u bazi i next() metoda vraća true. userName)) out.next().println("Welcome to the store! We'll add " + "you to the user database").println("</h3><p>"). String userName. finaly bloka kako bi se osiguralo da se konekcija uvek zatvara. ResultSet rs = ps.executeUpdate(). userName). psi.setString(1. } U nastavku. Zatim generiše različite poruke za postojećeg ili novog usera: private void handleReturnOrNewUser(PrintWriter out. userName).setAttribute("user". aplikacija automatski dodaje novog usera: private void addUser(Connection c.

setShoppingForm(true). stmt.NumberFormat.toString()).println("<h1>Products</h1><p>"). Connection con) { this. numCols). public HtmlSQLResult(String sql.sql = sql. out.private void displayCatalog(PrintWriter out.text.sql.lib.getInt("id")). generateShoppingForm(out. setupTable(out). private boolean shoppingForm. } Metoda displayCatalog() nije složena jer je veći deo složenosti prenet u pomoćnu klasu HtmlSQLResult koja sadrži konekciju na bazu i SQL statement renderuje rezultat unutar HTML tabele. this. ResultSet rs = stmt.execute(sql). . } endTable(out). try { Statement stmt = con. con). output. Takoñe sadrži opciju za kreiranje druge kolone sa tekstualnim poljem i dugme koje omogućava user-u da izvrsi kupovinu.servlet. generateHeaders(out. import java. int numCols = rsmd. package com. endRow(out). } public String toString() { StringBuffer out = new StringBuffer().getResultSet().*.con = con. out. numCols. while (rs.getColumnCount(). Connection con) { HtmlSQLResult output = new HtmlSQLResult(SQL_SEL_PRODS. rsmd. ResultSetMetaData rsmd = rs.println(output. rs. public class HtmlSQLResult { private String sql.getMetaData().shopcart.next()) { generateStandardRow(rs. rsmd. import java.createStatement(). out). private Connection con.

} catch (SQLException e) { out. int numcols) throws SQLException { for (int i = 1.getMessage()). } } private void generateStandardRow(ResultSet rs.append("</TABLE><H1>ERROR:</H1> " +e.").append("<TD>&nbsp. i++) { Object obj = rs.Types. i++) { out. b.getColumnLabel(i)). b. b. i <= numcols.sql. ResultSetMetaData rsmd.getColumnType(i) == java.getCurrencyInstance(). } } private void generateHeaders(StringBuffer out. if ((obj != null) && (rsmd.toString().append("<form action='ShowCart' method='post'>").append("<TD>"). StringBuffer out) throws SQLException { NumberFormat formatter = NumberFormat.DOUBLE)) out. int numCols.append("</form>"). . i <= numCols.append("Qty: <input type='text' size='3' " + "name='quantity'>"). for (int i = 1.append("<input type='submit' name='submit' " + "value='Add to cart'>").append(rsmd.getObject(i).append("</TR>\n").append("</TABLE>\n"). } private void endRow(StringBuffer out) { out. out.append("<input type='hidden' name='id' " + "value='"+ currentId + "'>"). ResultSetMetaData rsmd.format(rs. } return out.append("<TH>"). else out. } private void generateShoppingForm(StringBuffer b.append("<TR>").append("<TD>" + obj. b. } private void endTable(StringBuffer out) { out.append("<TD align='right'> " + formatter. int currentId) { if (shoppingForm) { b.getDouble(i))). out. b.toString()). else if (obj == null) out.

*. public class ShowCart extends ShopCartServletBase { static final private String SQL_GET_PRODUCT = "select * from products where id = ?". } public boolean isShoppingForm() { return shoppingForm. Kod za ShowCart servlet je sledeći: package com.12 This servlet shows the cntenint quantity =Integer. } public void setShoppingForm(boolean value) { shoppingForm = value.http. import java.append("<TR>").*. } } ShowCart servlet prikazuje sadžaj korpe kupca. .getParameter("id")).servlet. IOException { PrintWriter out = generatePagePrelude(response.util.*.println("<h3>" + userName + ". int itemId = Integer. } private void setupTable(StringBuffer out) { out.} if (shoppingForm) out.shopcart. import javax.append("<TH>" + "Buy"). here is your shopping cart:</h3>"). import javax.*.sql. HttpSession session = getSession(request.getParameter("quantity")).shopcart.servlet.*. ShoppingCart sc = getShoppingCart(session).parseInt(request. String userName = (String) session. out.getAttribute("user"). response). HttpServletResponse response) throws ServletException.servlet. uz opciju za kompletiranje nabavke.append("<TABLE border=1>\n").parseInt(request. import java. import com. out. "Cart").servlet.append("</TR>\n"). out.lib. public void doPost(HttpServletRequest request.isting 2.

.Connection con = null.

println("<form action='confirmation' method='post'>"). ShoppingCartItem sci = new ShoppingCartItem(id.prepareStatement(SQL_GET_PRODUCT).release(con). quantity. double price = rs. } finally { pool.executeQuery(). } out.println("Credit Card # <input type='text' " + "name='ccNum'><br>").println("<p>").setInt(1. price). sc. outputCheckoutForm(userName. } private void outputCheckoutForm(String user.toHtmlTable()). int quantity. return sc. generatePagePostlude(out). if (sc == null) sc = new ShoppingCart(). out. boolean status.getConnection(). out. name. if (status = rs. } catch (SQLException sqlx) { getServletContext().getDouble("price").sqlx). itemId.println(sc. session. itemId).getAttribute("cart").next()) { int id = rs.setAttribute("cart". int itemId. } private ShoppingCart getShoppingCart(HttpSession session) { ShoppingCart sc = (ShoppingCart) session. } private boolean addItemToCart(Connection c.DbPool pool = getConnectionPool(). out.println("<p><p><a href=\"catalog?username=" + user + "\"> Click here to return to catalog</a>").getString("name").println("<h3>Check out</h3>").getInt("id"). . ps. out).addItem(sci). String name = rs. out. if (!addItemToCart(con. out. sc).println("Credit Card Type <select name='ccType'>"). quantity. PrintWriter out) { out. ResultSet rs = ps.println("Error: Failed to add item to cart"). ShoppingCart sc) throws SQLException { PreparedStatement ps = c.log("SQL error adding item:". } return status. try { con = pool. sc)) out.

Učauruje kolekciju ShoppingCartItem objekata. Catalog servlet prosleñuje samo „ID“ i „quantity“ artikla.println("</select>"). } } I ovaj servlet nasleñuje ShopCartServletBase.*.text. kao što je ID. ShoppingCartItem je jednostavna klasa (entitet) sa poljima koji odreñuju „item“. tako da metoda addItemToCart() mora da koristi date promenljive da bilduje (build) sve informacije vezane za artikle u korpi. količina itd.println("<input type='submit' value='Check out'>"). koristeći generičke metode koje su tamo deklarisane. out. Prvi put kada user pristupi ovoj stranici. Servlet zatim poziva pomoćnu metodu outputCheckoutForm() da generiše HTML da prihvati informacije o plaćanju. out.println("<option value='Visa'>Visa</option>"). servlet dodaje ažuriranu korpu nazad u sesiju i generiše zaglavlje na dnu stranice (footer). aktivna je sesija tog korisnika (user-a).shopcart.println("</form>").servlet lib. import java. Servlet mora da obradi (hendluje) dva slučaja. out.out. public String toHtmlTable() { . import java. out.util.NumberFormat.println("<option value='MC'>MC</option>"). Metoda getShopingCart() je pomoćna metoda servleta. Metoda doPost() prihvata parametre prosleñene iz kataloga. out. Kada se svaki naredni put pristupi ovoj stranici. Na kraju. public class ShoppingCart { private List items = new Vector(5). getShopingCart() obrañuje (hendluje) oba slučaja. shopping cart još uvek ne postoji.println("<option value='Amex'>Amex</option>"). uspostavlja konekciju na bazu podataka i dodaje novi slog u shopping cart. ShoppingCart klasa je pomoćna klasa u ovoj aplikaciji.println("Credit Card Exp Date <input type='text' " + "name='ccExp'><br>"). ShoppingCart sadrži sledeće metode: package com. mora da se kreira. out.

hasNext()) { ShoppingCartItem item = (ShoppingCartItem) it.getTotal())). StringBuffer out = new StringBuffer(). double sum = 0.iterator().next().hasNext()) sum += ((ShoppingCartItem)it.getItemPrice())). while (it. out.getItemName()). } public List getItemList() { return items. return sum.append("<TH> Name").format(item.append("<TH> Total"). } public double getCartTotal() { Iterator it = items.append("<TH> Quantity").append("<TD> " + item.append("<TABLE border=1>\n").toString().getExtendedPrice(). out. out.next()). out.format(item. return out.append("</TABLE>\n").add(sci). out. out.append("<TR>").append("<TD> " + item. } out.append("<TD align='right'> " + formatter.iterator(). out. out.append("<TH> ID"). } public void addItem(ShoppingCartItem sci) { items. out. } public String getTotalAsCurrency() { return NumberFormat.NumberFormat formatter = NumberFormat. out.getCurrencyInstance().getCurrencyInstance().append("<TD> " + item.getItemId()). Iterator it = items. out. out.append("</TR>\n").append("<TR>"). out.getQuantity()). out.append("</TR>\n").append("<TD align='right'> " + formatter.format(getCartTotal()). while (it. out.append("<TH> Price"). } } .

import java. Confirmation servlet: package com.getParameter("ccNum"). import com.http. String user. HttpServletResponse response) throws ServletException. generatePagePostlude(out).servlet. return. } private Order insertOrder(HttpServletRequest request.*.io.*. String ccNum = request.setContentType(CONTENT_TYPE). import java. generatePagePostlude(out). order. String ccType = request. session. out. if (order == null) { getServletContext(). Klasa takoñe sadrži metode za izračunavanje ukupne vrednosti korpe i prikazuje tu vrednost u valuti. String user = (String) session.getParameter("ccType"). "Confirmation"). DbPool pool) throws IOException { Order order = new Order(). PrintWriter out.sql.log("Failed inserting order").getAttribute("user").getOrderKey()).servlet. HttpServletResponse response.setDbPool(pool). Order order = insertOrder(request. try { . import javax.*. PrintWriter out = generatePagePrelude(response. order.*.*.util.shopcart. import javax.invalidate(). import java. response). session.*. ShoppingCart sc. HttpSession session = getSession(request. DbPool dbPool = getConnectionPool().getParameter("ccExp"). public class Confirmation extends ShopCartServletBase { public void doPost(HttpServletRequest request. sc. String ccExp = request. } generateConfirmation(out. out.println("<h1>Error processing order</h1>").Ova klasa uključuje metodu koja prikazuje sadržaj shopping cart-a kao HTML tabelu.servlet. user. response. dbPool). IOException { response.lib.getAttribute("cart"). HttpSession session.shopcart.servlet. user. ShoppingCart sc = (ShoppingCart) session.

order.addOrder(sc, user, ccNum, ccType, ccExp); } catch (SQLException sqlx) { getServletContext().log("Order insert error", sqlx); } return order; } private void generateConfirmation(PrintWriter out, String user, int orderKey) { out.println("<h1>"); out.println(user + ", thank you for shopping at " + "ShopCart"); out.println("</h1>"); out.println("<h3>"); out.println("Your confirmation number is " + orderKey); out.println("</h3>"); out.println("<p>"); out.println("<P>"); out.println("<a href='Welcome.html'> " + "Click here to return to the store</a>"); out.println("</P>"); out.println("</P>"); } } Confirmation servlet ima najsloženiji zadatak da izvede. Prihvata i shopping cart i podatke o plaćanju zajedno i da generiše porudžbinu (koja sadrži podatke o porudžbini i artiklima) u bazi. Dobro je što klase Order i LineItem obavljaju veći deo tog posla. LineItem klasa je jednostavna, sadrži get() i set() metode za svako polje objekta. Metoda prosleñuje artikal do baze koristeći PreparedStatement. Order klasa unosi porudžbine unutar transakcije i sadrži veliki broj get() i set() metoda. Klasa Order učauruje podatke o porudžbini i dodaje porudžbinu u bazu: private static final String SQL_GET_USER_KEY = "SELECT ID FROM USERS WHERE NAME = ?"; private static final String SQL_INSERT_ORDER = "INSERT INTO ORDERS (USER_KEY, CC_TYPE, CC_NUM, CC_EXP) " + "VALUES (?, ?, ?, ?)"; private static final String SQL_GET_GENERATED_KEY = "SELECT LAST_INSERT_ID()"; public void addOrder(ShoppingCart cart, String userName, String ccNum, String ccType, String ccExp) throws SQLException {

Connection c = null; try { c = dbPool.getConnection(); c.setAutoCommit(false); int userKey = getUserKey(userName, c); addTheOrder(c); orderKey = getOrderKey(c); insertLineItems(cart, c); c.commit(); } catch (SQLException sqlx) { c.rollback(); throw sqlx; } finally { dbPool.release(c); } } private void insertLineItems(ShoppingCart cart, Connection c) throws SQLException { Iterator it = cart.getItemList().iterator(); Lineitem li = new Lineitem(); while (it.hasNext()) { ShoppingCartItem ci = (ShoppingCartItem) it.next(); li.addLineItem(c, orderKey, ci.getItemId(), ci.getQuantity()); } } private int getOrderKey(Connection c) throws SQLException { ResultSet rs = null; Statement s = null; int orderKey = -1; try { s = c.createStatement(); rs = s.executeQuery(SQL_GET_GENERATED_KEY); if (rs.next()) orderKey = rs.getInt(1); else { throw new SQLException("Order.addOrder(): no generated key"); } } finally { rs.close( ); s.close(); } return orderKey; }

private void addTheOrder(Connection c) throws SQLException { int result = -1; PreparedStatement ps = c.prepareStatement(SQL_INSERT_ORDER); try { ps.setInt(1, userKey); ps.setString(2, ccType); ps.setString(3, ccNum); ps.setString(4, ccExp); result = ps.executeUpdate(); if (result != 1) throw new SQLException("Order.addOrder(): order insert failed"); } finally { ps.close(); } } private int getUserKey(String userName, Connection c) throws SQLException { PreparedStatement ps = null; ResultSet rs = null; int userKey = -1; try { ps = c.prepareStatement(SQL_GET_USER_KEY); ps.setString(1, userName); rs = ps.executeQuery(); if (!rs.next()) { throw new SQLException("Order.addOrder(): user not found"); } userKey = rs.getInt(1); } finally { rs.close() ; ps.close(); } return userKey; } Metoda addOrder() prvo učitava konekciju iz skupa konekcija a onda setuje autoCommit properti konekcije na false. U bazi, porudžbine sadrže i podatke o porudžbini (kreditna kartica, status itd.) i poručene artikle koje su u drugoj tabeli. Da bi se dodala porudžbina u bazu, podaci moraju da se automatski proslede u obe tabele, Order i LineItems tabele. Zbog toga je potrebna obrada transakcije (transaction processing).

Kod MySQL-a postoji specijalna uskladištena (stored) procedura koja vraća poslednji generisani ključ za odreñenu tabelu. poziva posebnu uskladištenu proceduru MySQL-a da dobije najnoviji generisani ključ porudžbine. koje je integrisano u Eclipse razvojnom okruženju. Na kraju je dat detaljan izvorni kod koji je prethodno istestiran. Catch blok obezbeñuje da se izvrši roll back cele transakcije ukoliko dodje do neuspeha transakcije pozivom metode rollback(). Objašnjena je faza prikupljanja zahteva kroz priče korisnika (user stories) i plan isporuke. 6. tako da se ime koristi za pronalaženje ključa korisnika (koji predstavlja jedan od spoljašnih ključeva u Order tabeli). addTheOrder() metoda izvršava PreparedStatement i dodaje novu porudžbinu u bazu. koji se zatim koristi da se dodaju artikli pozivom metode insertLineItems(). Takoñe je izvršeno testiranje softvera primenom JUnit alata za jedinično testiranje softvera. primenom postupaka metode Ekstremnog programiranja u Eclipse razvojnom okruženju. Jedna od karakteristika MySQL-a je automatsko generisanje vrednosti ključa. Confirmation servlet prikazuje ID broj porudžbine kao broj koji korisniku potvrñuje uspešno izvršenu porudžbinu. Ime je jedini podatak koji korisnik prosleñuje od servleta do servleta. a baza generiše „unique“ ključeve. Priče korisnika i plan isporuke su korišćeni umesto obimne dokumentacije zahteva (Requirements documents) koje softver treba da zadovolji. koju poziva metoda addOrder(). CRC karticama simulira se sistem tako što se prikazuje . Definiše se primarni ključ. metoda addOrder() komituje (commit) promene obe tabele pozivom metode commit(). Kao sistem za upravljanje bazom podataka koristi se open-source database server MySQL. Na kraju.2 Sažetak U ovom poglavlju prikazan je razvoj JEE aplikacije (ShopCart aplikacije) kroz faze procesa životnog ciklusa softvera. Zatim je dato objašnjenje kako se koriste metafore i CRC kartice u fazi projektovanja softvera.Sledeći zadatak metode addOrder() je da pronañe ID korisnika u bazi. Način na koji se ključevi generišu kada postoji master/detail relacija je iskorišćen za generisanje ključeva relacije porudžbine/artikli u bazi ovog studijskog primera. Metoda getOrderKey().

koji objekti šalju poruke. odnosno kreiranjem testova pre izvornog koda. Na taj način smo realizovali peti cilj istraživanja (Izvršiti razvoj JEE aplikacije). Takoñe. rano se otkrivaju slabosti i problemi u softverskom sistemu. možemo zaključiti da primena XP postupaka dovodi do kraćeg vremena razvoja izvornog koda za koji smo sigurni da je ispravno implementiran. Na osnovu toga. . Uvoñenjem jediničnih testova. sigurni smo da su funkcionalnosti ispravno implementirane. Na taj način. automatizacijom jediničnih testova. a koji objekti te poruke primaju. omogućena je njihova jednostavna ponovljivost.

planira i kontroliše proces razvoja softvera: 1. 4. U prvom delu ovog rada analiziran je životni ciklus razvoja softvera: Dat je pregled osnovnih modela razvoja softvera koji odražavaju ciljeve razvoja (kao što je visok nivo kvaliteta izrade softvera. Dat je pregled osnovnih metoda razvoja softvera koje predstavljaju okvir kojio se koristi da se struktuira. Osnovne strategije. Spiralni model koji je orijentisan na rizik i koji razbija softverski projekat u mini projekte. Jedinstvenog procesa razvoja softvera. odnosno strateški pristup procesu razvoja softvera su Razvoj koji se zasniva na testovima. Zaključak Ovaj rad se sastoji iz šest delova.7. Testiranje i Održavanje. Dat je prikaz Larmanove metode. Ovo je agilna metoda razvoja softvera koja je bazirana na iterativno-inkrementalnom modelu životnog ciklusa softvera. Agilne metode koje predstavljaju konkretnu realizaciju iterativno-inkrementalnih modela. otkrivanje grešaka u ranim fazama razvoja softvera i ostajanje u okvirima budžeta i rokova realizacije softvera): 1. efikasnije modele životnog ciklusa softvera. Osnovne aktivnosti životnog ciklusa razvoja softvera su: Prikupljanje korisničkih zahteva. Tradicionalne metode koje predstavljaju konkretnu realizaciju modela vodopada. 3. Implementacija. Razvoj koji se zasniva na slučajevima korišćenja i Razvoj koji se orijentiše ka arhitekturi. Model evolucionarnog prototipa u kome se prototip razvija i razrañuje kroz različite faze životnog ciklusa softvera. Model vodopada koji služi kao osnova za druge. 2. 2. XP metoda naglašava saradnju članova tima. Zatim je u analizirana metoda Ekstremnog programiranja. postupke veštog razvoja softvera i omogucava razvoj sistema koji se bolje prilagodava promenjivim zahtevima korisnika. Scrum i za ovaj rad posebno naglašena metoda Ekstremnog programiranja. . brzo razvijanje softvera. Projektovanje. Iterativno-inkrementalni model koji u okviru više iteracija razvija manje inkremente softverskog rešenja.

Prikazana je interakcija izmeñu veb klijenta i servleta. Servleti su Javine klase koje dinamički procesiraju zahteve i konstruišu odgovore. a mnoge operacije. integrisan u Eclipse razvojnom okruženju. Prednost korišćenja integrisanog JUnit-a u neko razvojno okruženje (u ovom radu koristi se JUnit integrisan u Eclipse razvojnom okruženju) ogleda se u tome što je olakšan rad pri testiranju koda jer se testiranje vrši preko bogatog grafičkog interfejsa. Kontejner veb komponenti koji obezbeñuje servise za veb komponente. Stateless i Stateful internet komunikacione protokole koje uspostavljaju na različite načine konekciju izmeñu klijenta i servera. Uloge servlet kontejnera koji upravlja životnim ciklusom servleta. JavaServlet tehnologija koja obezbeñuje interfejse i klase za pisanje servleta: 1. Sistem za upravljanje bazom podataka. 2. potrebnoje koristiti neki od gotovih test okruženja. Jedinični testovi su jedna od najvažnijih stvari u ekstremnom programiranju. Veb modul kao organizacioni okvir unutar koga se postavlja veb aplikacija. 5. Prikazana je interakcija izmeñu veb klijenta i veb aplikacije.XP metoda realizuje strategiju koja se zasniva na testovima. Praćenje sesije preko servleta. 3. JUnit je napisan za Java programski jezik i omogućava kreiranje testova za bilo koju Java klasu. U trećem delu analiziran je JUnit alat za testiranje softvera. koja se dešava u nekom periodu vremena. . JSP strane sekreiraju korišćenjem JSP tehnologije i omogućavaju da se na neposredniji način kreira statički sadržaj dokumenata. Da bi se jedinični testovi uspešno koristili. odnosno njenu metodu. 4. Analizirani su: Veb aplikacija koja se izvršava u okruženju veb servera. izmeñu jednog klijenta i veb servera. Metode slanja zahteva veb serveru (GET i POST metoda). kao što je izvršavanje testova. odnosno serije povezanih interakcija. U ovom radu je korišćen JUnit alat za jedinično testiranje. U narednom delu je dat pregled Java platforme. vrši se automatski. Veb komponente u koje spadaju servleti ili JSP strane. U ovom radu se koristi MySQL 5.0 sistem za upravljanje bazom podataka.

Ekstremni način programiranja u potpunosti menja dosadašnju praksu timskog programiranja. modularnim komponentama. Primenom integrisanih testova. Ovaj okvir je besplatan. Ona pojednostavljuje složene (enterprise) aplikacije tako što ih zasniva na standardizovanim. Implementacija funkcionalnosti je dosta time olakšana. obezbeñujući kompletan skup . Junit je veoma jednostavan okvir za pisanje i izvršavanje automatizovanih testova. odnosno u tome što se prvo testira. pregledom koda u realnom vremenu i malim ciklusima isporuke. Trenutno se ovim stilom programiranja najviše koriste Java programerski timovi. Ova aplikacija predstavlja rezultat svih analiza prethodnih poglavlja u ovom radu. Kvalitetan kod se takoñe obezbeñuje i kontinualnim testiranjem koda u toku razvoja softvera. a istovremeno povećava stabilnost sistema.testiranje i ispravljanje grešaka. U JUnit-u se testovi brzo izvršavaju i dobija se vizuelna povratna informacija da li je test prošao ili nije. Za ovaj način programiranja poželjno je i posedovanje programskog koda svih elemenata pa i osnovnih biblioteka. Do sada je postojao sistem koji se sastojao od planiranja. Testiranjem na ovaj način programeri stiču mnogo veću sigurnost u ispravnost svog koda.Za potrebe master rada projektovan je studijski primer. zatim se obavljalo kodiranje i na kraju . pri čemu su korišćeni XP postupci kroz faze procesa životnog ciklusa softvera. ona predstavlja idealnu platformu za ovakav način programiranja. jer ne postoji sigurnost da li će se javiti greška ako se promeni kod koji nije testiran. S obzirom da je Java javno dostupna. a tek onda kodira. Meñu njima se ističe JUnit okvir. analizirale potrebe korisnika. U razvoju web aplikacije JEE platforma definiše standard za razvoj višenivojskih složenih aplikacija (multitier enterprise applications). raditi refaktorisanje bez skupa testova dovodi do privremenog razvoja. Danas postoje mnogi alati koji proces testiranja čine lakšim. Takoñe. ShopCart servlet aplikacija. jer za Javu postoje svi potrebni alati i pomoćna sredstva. XP osigurava dobijanje kvalitetnog koda. Lično smatram da je najveći doprinos primene XP-a u promeni šeme programiranja na testiranjekodiranje-refaktorisanje. u okviru kojeg se smišljala čitava struktura programa. kreirali postupci pri izradi softvera.

JDBC API za pristup bazi. kao što su portabilnost .servisa za te komponente. . bez složenog programiranja. Java 2 Platform. JavaServer Pages i XML tehnologija. 11 11 Mogućnost izvršavanja na različitim operativnim sistemima („Write Once. Na taj način se automatizuje ponašanje aplikacije. Java Servlet API-ja. Time. Enterprise Edition. izdanja Standard Edition (J2SE). Dalji pravci istraživanja odnosili bi se na: Analizu odnosa izmedju koncepta refaktoringa i metode ekstremnog programiranja. JEE platforma koristi mnoge prednosti Java 2 Platform-e. Razvoj automatizovanih alata koji podržavaju metodu Ekstremnog programiranja. daje punu podršku za primenu Enterprise JavaBean komponenata. model sigurnosti (security model) koji omogućava zaštitu podataka čak i u Internet (web) aplikacijama. Primenu uzora (paterna) u Ekstremnom programiranju. Run Anywhere“). Iz svih prethodno navedenih razloga doneta je odluka da se detaljnije objasni razvoj JEE (web) aplikacije primenom XP agilne metode razvoja softvera.

Alistair Cockburn and Jim Highsmith Series Editors). Jennifer Ball. 1996 [11] Eric Jendrock. Programiranje – seminar (napredni koncepti Jave i web programiranje u Javi). 2000. Journal of Object-OrientedPromming. Rapid Development: taming wild software schedules. 2003 [3] Siniša Vlajić. Outi Salo. D. Projektovanje programa (praktikum – Programski jezik Java). IEEE Computer Society [7] Smith M. FON. Vidojko Ćirić.. Ian Evans. Addison Wesley Professional. William Opdyke i Don Roberts. izdanje. Addison Wesley Professional. Scott Fordin. Jussi Ronkainen & Juhani Warsta: Agile software development methods (http://www.org) . [10] Steve McConnell. Using Junit in Eclipse.org [13] Bojan Tomić. Dušan Savić. 2001.pdf) [9] Alstair Cockburn: Agile Software Development. The Java EE 5 Tutorial.8. 2004 Version. Available: www. Kent Beck. ISBN 86-7991-202-6 [16] Kent Beck: Test Driven Development: By Example. Beograd. Projektovanje programa (Skripta). 2004 [2] Siniša Vlajić. Third Edition – For Sun Java System Application Server Platform. 2006 [6] Swebok. Literatura Za potrebe pristupnog rada koristili smo sledeću literaturu: [1] Siniša Vlajić. 2003 [5] Craig Larman. Debbie Carson.extremeprogramming. AddisonWesley. i Robson D. Guide to Software Engineering Body of Knowledge. Kim Haase..J. Edition 9. Agile & Iterative Development: A Manager’s Guide (Agile Software Development Series. XP material. John Brant. 2002 [17] JUNIT. Testiranje Java programa korišćenjem Junit alata – Praktikum sa dodatnim objašnjenjem i postupcima za NetBeans i Eclipse razvojna okruženja za Javu. A Framework for Testing Object-Oriented Programs. Ekstremno programiranje. 1992 [8] Pekka Abrahamsson. 2003 [15] Martin Flower. Addison-Wesley. 2007 [14] Christopher Batty. ISBN:0321146530.junit.vtt. Beograd [4] Stewart Baird. Beograd. 2006 [12] Wells D. 2001.fi/pdf/publications/2002/P478. TESTING RESOURCES FOR EXTREME PROGRAMMING (http://www. Refaktorisanjepoboljšanje dizajna postojećeg koda.inf. Sams Publishing. 1.

wikipedia. diplomski rad. Softversko inženjerstvo: teorija i praksa . ISBN 86-7991-284-0 [20] Stanilović Maja.com/j2ee) [19] Shari Lawrence Pfleger.html [212 http://en.martinfowler. Enterprise Edition (J2EE) (http://java. Atlee.com/articles/newMethodology. Joanne M.org/wiki/Extreme_programming . prevod trećeg izdanja (2006).sun. Razvoj aplikacija korišćenjem ekstremnog programiranja. 2006 [21] http://www.[18] Java 2 Platform.

Sign up to vote on this title
UsefulNot useful