Univerzitet u Beogradu Fakultet organizacionih nauka, Beograd

Master radRazvoj JEE aplikacije primenom Ekstremnog programiranjaKandidat: Maja Stanilovi lanovi komisije: dr Sinia Vlaji, doc. dr V ladan Devedi, red. prof. dr Zoran Marjanovi, red. prof.

Mart 2009. godine

Zahvalnicaelela bih ovom prilikom da se zahvalim svom mentoru dr. Sinii Vlajiu, na velikoj podrci, pomoi i strunim savetima koje mi je pruio ne samo tokom izrade ovog rada, ve i u trenucima ivota kada mi je savet bio potreban. Hvala Vam puno! Takoe bih elela da se zahvalim roditeljima, sestri i svom deku Aleksandru to su bili uz mene sve vreme i podravali me. Posebno se zahvaljujem svom ocu koji me celog ivota bodri da istrajem u svojim ciljevima i onda kada mi je najtee.

Curr iculum VitaeLini 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. Struni saradnik u sektoru za informatiku

1.

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

Odravanje i razvoj integralnog informacionog sistema sa stanovita softvera i hardvera, odgovornost za kvalitet i aurnost baze podataka, odgovornost za realizaciju korektivnih i preventivnih akcija u cilju otklanjanja neusaglaenosti u delu informacionog sistema, odgovornost za realizaciju zakljuaka tima za unapredjenje kvaliteta koji se odnose na problematiku integralnog informacionog sistema PERIHARD INENJERING DOO, Kneginje Zorke 24, Beograd, Naziv I adresa firme www.perihard.com Prozvodnja, industrijski remont toner kaseta za laserske tampae I mini fotokopir aparate I servis laserskih tampaa Od 2005.

3. Datum

Pozicija Spoljni saradnik Glavne aktivnosti I Pruanje podrke 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, Sinelieva 11, Beograd Naziv I adresa firme Export-import rezervnih delova za teke maine .

5. Datum

Jul Decembar 2002.

Pozicija Spa attendan t Glavne aktivnosti I Pruanje usluga klijentima, koordinacija svih aktivnosti, uspostavljanje odgovornosti kontakta I odravanje poslovnih odnosa sa klijentima (program razmene studenata) SONNENALP RESORT , 20 Vail Road, Vail, Colorado, USA , Naziv I adresa firme www.sonnenalp.com lan vodeih malih hotela u svetu Obrazovan je 1. Zvanje Diplomirani inenjer organ izacionih nauka smer informacioni sistemi I tehnologije Naziv fakulteta Fakultet organizacionih nauka, Univerzitet u Beogradu 2. kolska godina 2006. / 2007 ., postdiplomske studije Modul Softversko inenjerstvo Naziv fakulteta Fakultet organizacionih nauka, Univerzitet u Beogradu Projekti Datum realizacije Naziv projekta Organizacija Datum realizacije Naziv projekta Organizacija Datum realizacije Naziv projekta Organizacija Datum realizacije

2009. IS Integra lnog katastra zagaivaa, Agencija za zatitu ivotne sredine Spinnaker - NT 2008.-2009. Project Central, Real Estate Information System, Schell Brothers Spinnaker - NT 2007.-2008. HIS Hospital Information System Spinnaker - NT 2007. god.

Naziv projekta

Implementacija softvera PANTHEON (ERP reenje) u poslovno informa cioni sistem firme Perihard Inenjering

Organizacija Perihard Inenjering doo Vetine Jezici Engleski Francuski itanje odlino dobro Pisanje odlino osnovno Govor odlian osnovno iv iv

Kompjuterske vetine

1. Microsoft Office paket 2. Case alati (Rational Rose, ERwin, BPwin, ...) 3. Objektno orijentisani i drugi programski jezici (JAVA, C++, C, Pascal, COBOL, SQL, VB) 4. Razvojna okruenja (Eclipse, NetBeans, Jbuilder, ...) 5. Sistemi za upravljanje bazama podataka (MSSQL, MySQL, MS Access) 6. Programi za izradu raznih multimedijalnih sadraja (Macromedia Dreamweaver, Adobe Photoshop, ...) B kategorija

Vozaka dozvola

Ostali podaci

Uestvovanje na seminaru Smart e-Government 2006 International Conference and Exhibition Uestvovanje na seminaru IDC EAS Forum Adriatics 2006 u Beogradu ponuda I potranja ERP reenja Uestvovanje na konferenciji YU INFO 2007, Kopaonik, Drutvo za informacione sisteme i raunarske mree - prezentacija rada Implementacija ERP reenja Pantheon u Perihard Inenjeringu (prvi autor)

v

Apstrakt:U ovom radu e biti predstavljen razvoj JEE aplikacije primenom metode Ekstremnog programiranja. Prvo e biti objanjeni osnovni pojmovi ivotnog ciklusa softvera, sa naglaskom na: a) iterativno-inkrementalni model ivotnog ciklusa softvera, b) agilne metode ivotnog ciklusa softvera i c) strategiju ivotnog ciklusa softvera koja je voena testovima. Nakon toga bie dat prikaz Ekstremnog programiranja kroz precizno definisan redosled faza ivotnog ciklusa softvera. Zatim e biti dat prikaz JEE platforme. U daljem radu bie objanjen JUnit alat koji se koristi za testiranje softvera. Na kraju e biti data studija sluaja pod nazivom Elektronska prodavnica koja e se razviti korienjem Ekstremnog programiranja, JEE platforme i JUnit alata. Kljune rei: Agilne metode, Ekstremno programiranje, JEE, JUnit

Abstract:This paper will present Java Enterprise Edition (JEE) application development by using Extreme programming method. Before all, basic concepts of software life cycle will be given, with the emphasis on the following: a) iterative-incremental model of software life cycle, b) agile methods of software life cycle and c) test-driven strategy of software life cycle. Then, it will be given a view of Extreme programming through precisely defined phase order of life cycle software. Then, it will be given a view of JEE platform. Further, it will be explained JUnit tool that is used for software testing. At the end, it will be given the case study titled "Electronic Store" which will be developed using the Extreme programming, JEE platform and JUnit tools. Keywords: Agile methods, Extreme Programming, JEE, JUnit

vi

SADRAJ1. Uvod 2. ivotni ciklus softvera 2.1 Modeli ivotnog ciklusa softvera 2.1.1 Model vodopada 2.1.2 Spiralni model 2.1.3 Model evolucionarnog prototipa 2.1.4 Iterativno-inkrementalni model (fazni razvoj) 2.2 Metode ivotnog ciklusa softvera 2.2.1 Uvod u agilne metode razvoja softvera 2.2.1.1 Larmanova metoda razvoja softvera 2.2.1.2 Jedinstveni proces razvoja softvera (Unified Proces) 2.2.1.3 Scrum 2.2.1.4 Ekstremno programiranje (Extreme Programming - XP) 2.3 Strategije ivotnog ciklusa softvera 2.3.1 Upravljanje prema sluajevima korienja (use-case driven) 2.3.2 Orijentacija ka arhitekturi (architecture centric) 2.3.3 Razvoj voen testovima (test-driven development - TDD) 2.4 Aktivnosti ivotnog ciklusa softvera 2.4.1 Prikupljanje korisnikih zahteva 2.4.2 Projektovanje (dizajniranje) sistema 2.4.3 Implementacija 2.4.3.1 Java platforma 2.4.3.2 .NET platforma 2.4.4 Testiranje programa 2.4.4.1 Organizacija testiranja 2.4.4.2 Automatizovani alati za testiranje 2.4.5 Isporuka softverskog sistema 2.4.6 Odravanje softverskog sistema 2.5 Saetak 3. Ekstremno programiranje (Extreme programming - XP) 3.1 Nastanak XP-a 3.2 ta je Ekstremno programiranje? 3.3 ivotni ciklus XP-a 3.4 Postupci u XP-u kroz faze procesa ivotnog ciklusa softvera 3.4.1 Planiranje razvoja softvera u XP-u 3.4.1.1 Prie korisnika (user stories) 3.4.1.2 Planiranje isporuka (Release Planning) 3.4.1.3 Male isporuke 3.4.1.4 Iterativni razvoj 3.4.2 Projektovanje softvera u XP-u 3.4.2.1 Jednostavan dizajn 3.4.2.2 Metafore sistema (Szstem Methafor) 3.4.2.3 CRC kartice (Class, Responsibilities, Collaboration cards) 3.4.2.4 Stalno refaktorisanje 3.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

3.4.3.1 Kupac na licu mesta 3.4.3.2 Standardi u pisanju koda 3.4.3.3 Programiranje u paru 3.4.3.4 Pisanje jedininih testova pre implementacije funkcionalnosti 3.4.3.5 Kontinuirana integracija koda 3.4.3.6 Zajedniko vlasnitvo nad kodom 3.4.3.7 Optimizacija koda 3.4.3.8 40 radnih sati nedeljno 3.4.4 Testiranje softvera u XP-u 3.4.4.1 Jedinini testovi 3.4.4.2 Testovi prihvaenosti 3.4.2.3 Testiranje jedinice programa pomou okvira xUnit 3.5 Saetak 4. JUnit alat za testiranje koda 4.1 Osnovni koncepti JUnit-a 4.2 Osnovni ciklus sluaja testiranja 4.3 Jedinino testiranje Veb aplikacije 4.3.1 Sluajevi testiranja (Test Cases) 4.3.2 Pokretanje testova 4.4 Saetak 5. Java platforma 5.1 Uvod u JEE tehnologiju 5.2 Web aplikacija 5.2.1 Veb komponente 5.2.2 Kontejner Veb komponenti 5.2.3 Sistem za upravljanje bazom podataka 5.2.4 ivotni ciklus Veb aplikacije 5.2.5 Veb modul 5.3 Java Servlet Tehnologija 5.3.1 Metode slanja zahteva Veb serveru 5.3.2 Stateless i Stateful tipovi protokola 5.3.3 Praenje sesije preko servleta 5.3.4 ivotni ciklus servleta 5.4 Saetak 6. Studijski primer 6.1 ShopCart servlet aplikacija 6.1.1 Korisniki zahtevi (planiranje) 6.1.2 Planiranje 6.1.3 Implementacija 6.1.3.1 Testiranje entiteta 6.1.3.2 Testiranje kritinih klasa 6.1.3.3 Skup testova 6.1.3.4 Izvorni kod ShopCart aplikacije 6.2 Saetak 7. Zakljuak 8. 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

Lista slika:Slika 1: Model vodopada . Slika 2: Spiralni model . Slika 3: Model Evolucionarnog prototipa Slika 4: Iterativni inkrementalni razvoj Slika 5: ivotni ciklus jedinstvenog procesa razvoja softvera . Slika 6: ivotni ciklus Scrum-a Slika 7: Proces evidentiranja zahteva ... Slika 8: Koraci testiranja .. Slika 9. Vremenski okviri planiranja i povratnih veza u XP-u Slika 10: ivotni ciklus u XP-u Slika 11: Praktini postupci u XP-u . Slika 12: Ciklus jedne iteracije u XP- u ... Slika 13. Programeri koriste kontrolu izvornog koda i posebnu mainu za sklapanje softvera .. Slika 14. Produktivnost raste sa utroenim vremenom Slika 15. Tok rada testa za prihvatanje Slika 16. Osnovni koncepti Junit-a .. Slika 17. JUnit prikazuje neuspean test .. Slika 18: Interakcija izmeu Web klijenta i Web aplikacije Slika 19: Java Web aplikacione tehnologije Slika 20 : Web modul struktura Slika 21: Interakcija izmeu Web klijenta i servleta Slika 22: Uloge servlet kontejnera ... Slika 23. Plan isporuke . Slika 24: CRC kartica .. Slika 25: Predlog postupka razvoja softvera primenom XP postupaka ... Slika 26: Prikupljanje zahteva korisnika u fazi analize Slika 27: Login stranica Slika 28: Katalog stranica sa postojeim korisnikom .. Slika 29: Katalog stranica sa novim korisnikom .. Slika 30: Shopping Cart stranica .. Slika 31: stranica koja prikazuje broj potvrene porudbine ... Slika 32: Korienje CRC kartiva u fazi projektovanja softverskog sistema .. Slika 33: Metafora sistema .. Slika 34: Veze izmeu klasa Slika 35: CRC1_ShopCartServletBase Slika 36: CRC2_Catalog . Slika 37: CRC3_ShowCart .. Slika 38: CRC4_ShoppingCartItem . Slika 39: CRC5_ShoppingCart Slika 40: CRC6_Confirmation . Slika 41: CRC7_Order . Slika 42: CRC8_LineItem Slika 43: Faza implementacije u XP-u . Slika 44: JUnit prikazuje uspean TestShoppingCart test Slika 45: JUnit prikazuje uspean TestOrder test Slika 46: JUnit prikazuje uspean AllTests test ... 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

1. UvodUsled znaajnog rasta industrije vezane za Internet, mobilne i distribuirane aplikacije, javlja se izraena potreba da se brzo odgovori na promene i neoekivane izazove u razvoju softvera. U tom smislu pojavljuje se veliki broj metoda u oblasti softverskog inenjerstva, koje su namenjene za reavanje problema razvoja softvera. Meu njima se istiu agilne metode razvoja softvera [1, 5, 8, 9, 16] koje pokuavaju da ree problem brzog tehniko-tehnolokog razvoja u oblasti softverskog inenjerstva [2, 6, 10, 19]. Kao najpopularnija agilna metoda razvoja softvera, istie se Ekstremno programiranje (XP) [4, 12, 15, 20], koje donosi sasvim drugaciji pristup u komunikaciji sa klijentima, izvravanju zadataka, testiranju, refaktorisanju i svim ostalim fazama razvoja softvera. Primenom Ekstremnog programiranja i tehnologija, kao to je EJB tehnologija [3, 11, 18] koja je predvodnica enterprise izdanja Java platforme, sloene (Enterprise) aplikacije se mogu razviti na relativno jednostavan i brz nain. S obzirom da je Ekstremno programiranje metoda koja primenjuje strategiju razvoja softvera koja je voena testovima, primenjuju se alati koji se koriste za testiranje softvera kao to je JUnit [7, 13, 14, 17]. Junit je veoma jednostavan okvir za pisanje i izvravanje automatizovanih testova. U JUnit-u se testovi brzo izvravaju i dobija se vizuelna povratna informacija da li je test proao ili nije. Ovaj okvir je besplatan, a istovremeno poveava stabilnost sistema. Predmet istraivanja ovog master rada je razvoj JEE aplikacije primenom metode Ekstremnog programiranja. U tom kontekstu se razmatra: a) iterativno-inkrementalni model ivotnog ciklusa softvera, b) agilne metode ivotnog ciklusa softvera i c) strategija ivotnog ciklusa softvera koja je voena testovima. Na osnovu definisanog predmeta istraivanja, na poetku istraivanja postavljeni su sledei ciljevi istraivanja: 1. Dati pregled modela, metoda, strategija i aktivnosti ivotnog ciklusa softvera; 2. Dati pregled metode Ekstremno programiranje; 3. Dati pregled JEE platforme; 4. Dati pregled JUNIT alata za testiranje softvera; 5. Izvriti razvoj JEE aplikacije. U okviru ovog cilja definisani su sledei podciljevi:

2

5.1. Izvriti razvoj JEE aplikacije primenom metode Ekstremnog programiranja u Eclipse razvojnom okruenju; 5.2. Izvriti testiranje softvera primenom JUnit alata za jedinino testiranje softvera; 5.3. Oceniti posmatranu metodu razvoja softvera u odnosu na Larmanovu metodu razvoja softvera. Rad se sastoji iz poglavlja: U prvom poglavlju je dat Uvod koji predhodi detaljnom razmatranju tehnologija i studijskom primeru. U drugom poglavlju dat je pregled ivotnog ciklusa softvera. Prikazani su modeli, metode, strategije kao i aktivnosti ivotnog ciklusa softvera. U treem poglavlju dat je detaljan prikaz metode Ekstremno programiranje. Objanjen je ivotni ciklus XP-a kao i postupci u XP-u kroz faze procesa ivotnog ciklusa softvera, od planiranja razvoja softvera u XP-u, projektovanja softvera, implementacije softvera do testiranja softvera u XP-u. U etvrtom poglavlju prikazan je JUnit alat za testiranje koda. Objanjeni su osnovni koncepti Junita, kao i jedinino testiranje veb aplikacije. U petom poglavlju dat je prikaz Java platforme. Prikazani su osnovni koncepti veb aplikacije (veb komponente, kontejner veb komponenti, ivotni ciklus veb aplikacije, veb modul), kao i Java Servlet tehnologija. U estom poglavlju prikazan je studijski primer korienjem XP metode razvoja softvera. U sedmom poglavlju data su zakljuna razmatranja o posmatranim tehnologijama.

3

2. IVOTNI CIKLUS SOFTVERADa bi se razumeo nain izrade dobrog softvera, procenjivanje rizika kao i mogunosti koje softver unosi u na svakodnevni ivot, neophodno je vrsto teorijsko i praktino razumevanje softverskog inenjerstva. Izrada dobrog softvera predstavlja umetnost koja se ogleda u razumevanju naina apstrahovanja i modelovanja sutinskih elemenata problema, a zatim korienju takvih apstrakcija za projektovanje reenja. Dobra softver-inenjerska praksa mora da obezbedi da softver daje pozitivan doprinos nainu na koji ivimo, jer je u dananje vreme rad softvera prisutan u svim aspektima naeg ivota. Da bi se razumelo kako se softversko inenjerstvo uklapa u svet raunarske nauke treba objasniti da se raunarstvo usredsreuje na raunare i programske jezike, a softversko inenjerstvo iste koristi kao alate u projektovanju i primeni reenja nekog problema. Umesto da istrauje dizajn hardvera, softver inenjer se usredsreuje na raunar kao sredstvo za reavanje problema. Svaki haker moe da napie programski kod koji neto radi, ali su potrebni umee i znanje profesionalnog softverskog inenjera da bi se proizveo stabilan i razumljiv kod koji se lako odrava i koji efikasno i efektivno radi ono zbog ega je napravljen. Kod softverskog inenjerstva sutina je u projektovanju i razvoju visoko kvalitetnog softvera. Softversko inenjerstvo je stvaralaki i postupan proces, koji okuplja veliki broj ljudi na poslovima izrade razliitih vrsta proizvoda. Prilikom pruanja usluga ili izrade proizvoda uvek se sledi niz koraka kako bi se izvrio neki skup zadataka. Zadaci se obino izvravaju u istom redosledu. Uredjeni skup zadataka smatra se procesom: nizom koraka koji obuhvataju aktivnosti, ogranienja i resurse, a rezultiraju eljenim ostvarenjem. Proces obino ukljuuje skup alata i tehnika. [19, 45 str.] Proces izrade nekog proizvoda se ponekad naziva ivotni ciklus. Zbog toga se nekada softverski razvojni proces naziva i ivotni ciklus softvera jer opisuje ivot softverskog proizvoda od formulisanja, preko implementacije do isporuke, upotrebe, operativnog korienja i odravanja. [1, 46 str.] Procesi su vani jer omoguavaju strukturisanje i konzistentno predstavljanje skupa aktivnosti. Proces razvoja softvera moe se opisati fleksibilno, tako da omoguava projektovanje i izradu 4

softvera uz oslonac na tehnike i alate koje pojedincima vie odgovaraju. Proces pomae da se odri nivo konzistentnosti i kvaliteta proizvoda ili usluga koje razliiti ljudi realizuju. Proces je sloeniji pojam od postupka. Postupak je ureen nain kombinovanja alata i tehnika u cilju izrade proizvoda (softvera). Proces predstavlja skup postupaka, organizovanih tako da rezultujui proizvod zadovolji unapred postavljeni skup ciljeva i standarda. [19, 46 str.] Na primer, proces moe da zahteva da proverimo delove projekta pre poetka procesa kodiranja. Provera moe da se izvede neformalnim pregledom ili formalnom inspekcijom, od kojih je svaki postupak za sebe, ali im je isti cilj. Procesi takoe omoguavaju evidentiranje iskustava i njihovo prosleivanje drugima. Time se omoguava uenje na iskustvima ranije razvijenih projekata, dokumentovanje izrade softvera visokog kvaliteta i praenje procesa razvoja softvera. Razvoj softvera obino obuhvata sledee faze: 1. definisanje korisnikih zahteva 2. projektovanje 3. implementacija 4. testiranje 5. isporuka 6. odravanje Svaka faza predstavlja proces koji se moe opisati skupom aktivnosti pri emu svaka aktivnost ukljuuje ogranienja, izlaze i resurse.[19, 47 str.] Na primer, u fazi prikupljanja zahteva, kao poetni ulaz koriste se iskazi, koje formulie korisnik na neki od moguih naina. Izlaz ove faze je skup zahteva. Postoje ogranienja, kao to su budet i vremenski rok za izradu dokumenta o zahtevima, standardi vezani za tipove ukljuenih zahteva i notaciju za njihovo iskazivanje.

5

------------------------------------------------------------------------------------------------------2.1. MODELI IVOTNOG CIKLUSA SOFTVERA------------------------------------------------------------------------------------------------------------------------Svaki proces moe da se opie na razliite naine, pomou teksta, slika ili njihovom kombinacijom. [19, 48 str.] Istraivai u oblasti softverskog inenjerstva predlau razliite forme takvih opisa, odnosno modele ivotnog ciklusa softvera sa ciljem da se utvrdi nain na koji organizovanje aktivnosti unutar procesa moe da dovede do efikasnijeg razvoja softverskog sistema. U domenu softverskog inenjerstva opisani su mnogi modeli procesa. Izrada modela procesa i razmatranje njegovih potprocesa pomau projektnom timu da shvati jaz izmeu toga ta bi trebalo da bude i onoga to stvarno jeste. Model treba da odraava ciljeve razvoja, kao to je izrada softvera visokog nivoa kvaliteta, otkrivanje greaka u ranim fazama razvoja i ostajanje u okvirima budeta i formulisanih ogranienja vezanih za rokove realizacije. [19, 48 str.] Svaki model procesa razvoja softvera kao ulaz koristi specifikaciju zahteva, a kao izlaz isporueni proizvod. Tokom niza godina predloeni su mnogi takvi modeli. Meu njima najpopularniji su Model vodopada, Spiralni model, Prototipski model i Iterativno-inkrementalni model.

2.1.1 Model vodopada Jedan od najstariji h modela ivotnog ciklusa softvera je model vodopada. Iako ima pun o problema , on slui kao osnova za druge, efikasnije modele ivotnog ciklusa. U modelu vodopada, projekat napreduje kroz ureenu seriju koraka od inicijalnog koncepta softvera do testiranja sistem. Proje kat se preis pituje na kraj u svake faze, da bi se odredilo da li je spreman za prelazak u sledeu fazu. Ukoliko projekat nije spreman za prelazak u sledeu fazu, ostaje u trenutnoj fazi dok ne bude spreman. [16, 136 str.] Model vodopada je baziran na dokumentima (document driven), to znai da su dokumenti glavni radni proizvodi koji se prenose iz fazu u fazi. U istom modelu vodopada, ove faze su nepovezane, tj. ne preklapaju se [16, 136 str.]. Na slici 1 [16, 137 str.] je prikazan model vodopada.

6

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 tehnikim metodologijama. U takvim sluajevima, model vodopada pomae da se nau greke u ranim fazama projekta. On prua stabilnost zahteva, koju programeri ele. Ukoliko se pravi dobro definisana verziju za odravanje postojeeg proizvoda, ili konvertuje postojei proizvod na novu platformu, model vodopada moe da bude pravi izvor za brz razvoj. Ovaj model smanjuj e optereenje planiranj em poto se celo planiranje radi unapred. Ne prua opipljive rezultate u formi softvera do kraja ivotnog ciklusa, ali neko ko je upoznat sa ovim modelom, moe da iz dokumentacije koja se generie da dobije smislene indikacije napretka kroz ivotni ciklus. [16, 136 str.] Model vodopada radi dobro za projekte koji su veoma veliki, ali jasni, zato to ima koristi od pristupanja sloenosti na ureen nain. On dobro radi kada zahtevi za kvalitetom dominiraju nad trokovima i vremenskim zahtevima. Eliminacija izmena tokom implementacije, eliminie veliki i est izvor potencijalnih greaka. Model vodopada radi posebno dobro ukoliko je osoblje tehniki slabo potkovano, ili neiskusno, zato to prua projektu strukturu koja minimizira utroeni 7

napor. Mane istog vodopada nastaju iz potekoa da se u potpunosti specificiraju korisniki zahtevi pre poetka projekta, pre ikakvog projektantskog rada i pre pisanja koda. [16, 137 str.] Prvi veliki problem sa modelom vodopada je da nije fleksibilian. Potrebno je u potpunosti specificirati korisnike zahteve na poetku projekta, to moe da bude mesecima, ili godinama pre nego to se kreira gotov proizvod. [16, 138 str.] Ukoliko se koristi model vodopada, zaboraviti neto moe da bude skupa gre ka. Dok projekat ne doe do testiranja sistema, nee se znati da neki korisniki zahtev fali ili da je pogrean. Postoje kritike modela vodopada povodom toga to ne dozvoljava vraanje u prethodne faze da bi se ispravile greke. To nije u potpunosti tano. Kao to je prikazano na slici 3 [16, 137 str.], vraan je unazad je dozvoljeno, ali je veoma teko. Veina slabosti u istom modelu vodopada nastaje ne od samih aktivnosti, ve od tretiranja aktivnosti kao razjedinjenih, sekvencijalnih faza. Mogue je ispraviti neke od glavnih nedostataka istog modela vodopada sa relativno minornim izmenama. Moe se modifikovati tako da se faze ne preklapaju. Mogue je smanjiti naglasak na dokumentaciji. Takoe je mogue je dozvoliti vie vraanja u prethodne faze. [16, 143 str.] Sve druge metodologije na neki nain predstavljaju varijacije modela vodopada. Razlika je u brzini, tipu isporuke i poveanoj fleksibilnosti.

2.1.2. Spiralni model Spiralni model je definisao Barry Boehm lankom "A Spiral Model of Software Development and Enhancement" 1986. godine [13]. Najvei znaaj modela je eksplicitno prepoznavanje i uklanjanje rizika. Spiral ni model je model ivotnog ciklusa softvera koji je orije ntisan na rizik, i koji razbija softverski proje kat u mini proje kte. Svaki mini projekat obrauje jedan ili vie glavnih rizika dok svi rizici nisu obraeni. Koncept rizika je iroko definisan u ovom kontekstu, i moe da se odnosi na loe protumaene korisnike zahteve, lou arhitekturu, potencijalne probleme sa performansama, probleme u osnovnoj tehnologiji, itd. [16, 141 str.]. Na slici 2 [16, 142 str.] je prikazan spiralni model.

8

Slika 2: Spiralni model

Osnovna ideja iza dijagrama spiralnog modela je da se pone malim koracim a u sredini, ispitaju se rizici, napravi se plan za obradu rizika, i onda se posveti pristupu za sledeu iteraciju. Svaka iteracija ukljuuje est koraka:1. Odreivanje ciljeva, alte rnati va i ogranienja; 2. Identifikovanje i otklan janje rizika; 3. Ocena alternativa; 4. Razvoj isporuka (deliverables) za tu iteraciju, i provera da li su ispravne; 5. Plan sledee iteracije; 6. Posveenje pristupu za sledeu iteraciju (ukoliko postoji);

Mogue je kombinovat i ovaj model sa ostalim modelima ivotnog ciklusa softvera na par razliitih naina. Mogue je poeti projekat sa serijom iteracija za smanjenje rizika. Poto je rizik smanjen na prihvatljivu meru, mogue je zavriti razvoj sa modelom vodopada ili nekim drugim 9

modelom koji nije baziran na riziku. Mogue je ugra diti druge modele ivotnog ciklusa unu tar spiral nog modela. Na primer, ukoliko je jedan od rizika da li je mogue postii eljene performanse, mogue je ukljuiti iteraciju protipiziranja (prototyping), model u kome se koncept sistema razvija u toku ivota projekta, da bi se ispitalo da li je mogue postii postavljene ciljeve. [16, 142 str.] Jedna od glavnih prednosti spiralnog modela je da se poveanjem trokova, smanjuj e rizik. Spiralni model prua makar onoliko menaderske kontrole koliko i tradicionalni model vodopada. Postoje kontrolne take na kraju svake iteracije. Poto je model orijentisan na rizik, on prua rane indikatore bilo kog nepremostivog rizika. Ukoliko projekat ne moe da se zavri zbog tehnikih ili drugih razloga, spiralni model omoguava da se to zna rano, i da ne kota puno. Prednosti spiralnog modela je i mogunost hvatanja u kotac sa (gotovo neizbenim) promenama koje razvoj softvera neizostavno namee. Mana spiralnog modela je njegova sloenost. Zahteva savesno, brino i znanjem potkovano upravljanje. Glavni nedostatak spiralnog modela je to su procene koje se tiu budeta i plana grube na poetku jer neke analize nisu zavrene sve dok te etape nisu prole fazu projektovanja. Spiralni model u dananje vreme nije korien u veoj meri [14]. Ipak on utie koncepte razvoja softvera dananjice, naroito na tzv. agilne metode. na moderne

2.1.3. Model evolucionarnog prototipa Model evolucionarnog prototipa je model ivotnog ciklusa softvera u kome se prototip razvija i razrauje kroz razliite faze ivotnog ciklusa softvera u cilju dobijanja kompletnog softverskog sistema. Obino se poinje razvojem aspekata sistema koji su najvie vidljivi. Taj deo sistema se predstavlja klijentu, a zatim se nastavlja sa razvojem matrice prototipa na osnovu dobijene povratne informacije (feedback). U jednom trenutku klijent i programer se usaglaavaju da je prototip dovoljno dobar. U tom trenutku, programer kompletira preostali deo posla na sistemu i isporuuje prototip kao krajnji proizvod. Slika 3 [16, 147 str.] ilustruje ovaj pristup:

10

Inicijalni koncept

Dizajn i implementacija prototipa

Fino podeavanje prototipa, sve dok se ne prihvati

Kompletiranje i isporuka prototipa

Slika 3: Model Evolucionarnog prototipa

Model evolucionarnog prototipa je posebno koristan kada se korisniki zahtevi esto menjaju, kada je korisnik nevoljan da definie skup zahteva, ili kada ni korisnik ni programer ne poznaju dobro oblast aplikacije. Takoe je koristan kada programeri nisu sigurni koju optimalnu arhitekturu ili algoritme da koriste. Ovaj model daje vrste, vidljive znake napretka, to moe biti od posebne vanosti kada postoji zahtev za brzim razvojem. [16, 147 str.] Glavni nedostatak modela evolucionarnog prototipa je da je nemogue znati na poetku projekta koliko vremena je potrebno da se kreira prihvatljiv proizvod. ak se ne zna ni kroz koliko iteracija je potrebno proi. Ovaj nedostatak je ublaen injenicom da korisnik moe da vidi jasne znake napretka. [16, 147 str.] Model evolucionarnog prototipa ukljuuje analizu korisnikih zahteva, projektovanje,

implementaciju samo u mnogo manjim inkrementima nego tradicionalni pristupi. [16, 148 str.]

2.1.4. Itera tivno- inkrementa lni model (fazni razvoj) Koncept razvoja sistema pomou iteracija je poznat kao iterativ no ikreme ntalni razvoj (IID, Iterative and Incremental Development), iako je esto korienje termina iterativ ni razvoj[5, 10 str]. Iterativni razvoj je pristup razvoja softvera u kome je ceo ivotni ciklus sastavljen od nekoliko sekvencijalnih iterac ija. Svaka iteracija je samo-sadrani (self-contained) mini projekat sastavljen od aktivnosti poput analize zahteva, projektovanja, programiranja i i testiranja. Cilj iteracije je dobijanj e verzije softvera koja je stabilna, integrisana i testirana. Veina iteracija su interne, i koriste ih samo razvojni timovi, tj. ne daju se krajnjim korisnicima. Krajnja iteracija je potpuni proizvod, isporuen tritu ili klijentima. [5, 9 str.] 11

Slika 4: Iterativni inkre mentalni razvoj

Na slici 4 [5, 10 str.] je prikazan iterativni-inkrementalni razvoj. Podsistem raste inkrementalno sa novim funkcionalnostina, iteraciju po iteraciju, odnosno, ostvaruje se inkreme ntalni razvoj [5, 10str.]. Inkrement je definisan kao podsistem sistema. Zavreni inkrement je podsistem za koji vai da su faze analize, projektovanja i implementacije sistema zavrene, revidirane i testirane. Itera cija je definisana kao prolaz preko odreenog skupa aktivnosti. Iterativni proces je revizija i nastavak rada na prethodnom poslu. Metode iterativno inkrementalnog razvoja predlau priorite iteracija bazirane na upravljanju rizikom i odnosom prema klijentima [5, 12 str.]. Iterativ ne metode prihvataj u prome ne, ali ne haos. U moru stalnih promena, potrebna je taka stabilnosti. U metodama iterativno inkrementalnog razvoja ovo se postie pomou sledeeg pravila [5, 14 str.]: Jednom kada su zahtevi za iteraciju izabrani i radi se na njima, klijenti ne mogu da ih promene. Iterativno inkrementalni razvoj je impleme ntiran u jedinstvenom procesu razvoja softvera (UP, Unified Process), Scrum-u, ekstremnom progra miranju (eXtreme Programming - XP), 12

evolucionarnom upravljanju projektima (EVO, EVOlutionary Project Management) i Larmanovoj metodi ivotnog ciklusa softvera, ali i drugim metodama razvoja softvera. Napomena: U ovoj tezi, poseban akcenat se stavlja na iterativno-inkrementalni model ivotnog ciklusa softvera koji e se primeniti u razvoju aplikacije (Elektronska prodavnica Shop Cart).

------------------------------------------------------------------------------------------------------2.2. METODE IVOTNOG CIKLUSA SOFTVERA ------------------------------------------------------------------------------------------------------Metoda ivotnog ciklusa softvera predstavlja okvir koji se koristi da se struktuira, planira i kontrolie proces razvoja softvera. Postoji irok izbor takvih okvira, koji su se razvijali tokom godina, svaki sa svojim slabostima i prednostima. Jedna metoda razvoja softvera nije uvek odgovarajua za razvoj svih softvera. Svaka od metoda odgovara odreenom softveru, u zavisnosti od razliitih tehnika, organizacije, projekta i nainu razmiljanja koje vlada u timu. Vei deo softverskog razvoja karakterie niz haotinih aktivnosti, ove aktivnosti najbolje opisuje fraza kodiraj i popravi (code and fix). Pisanje softvera se ne zasniva na planu, a projektovanje se sastoji od veceg broja kratkoronih odluka. Ovaj pristup dobro funkcionie u slucajevima kada je sistem mali. Sa povecanjem obima sistema, sve je tee dodati nove osobine u sistem. Poveava se broj greaka u softveru i sve je tee ispraviti ih. Glavna odlika ovakvih sistema je dugo testiranje nakon kompletiranja odreene funkcionalnosti [21]. Kao odgovor na ovaj nain razvoja softvera javljaju se disiplinovani procesi, sa osnovnom namerom da poveaju predvidljivost i efikasnost razvoja softvera. Nalazei inspiraciju u ostalim inenjerskim dicisplinama tradicinalne metode (planom voene) razvijaju detaljne procese koji posebno istiu planiranje. Meutim, najeca kritika upuena ovim metodama je ta da su one previe birokratske i da usporavaju ceo proces razvoja softvera. Agilne metode razvoja softvera se javljaju kao reakcija na tradicionalne metode.

13

2.2.1. Uvod u agilne metode razvoja softvera Agilne metode razvoja softvera primenjuju vremenski ogranien iterativni i evolucioni razvoj, adaptivno planiranje, evolucionu isporuku i ukljuuju druge vrednosti1

i postupke koji podstiu

agilnost brz i fleksibilan odgovor na promene. Moto agilnih metoda je: prigrliti promene (embrace change) . Strateka taka agilnih metoda je pokretnost, sposobnost za manevrisanje

(maneuverability) [5, 25 str.]. Iterativni razvoj predstavlja sr agilnih metoda. Dodatno, agilne metode predstavljaju principe i postupke koji odraavaju jednostavnost, lakou, komunikaciju, samo-upravljive timove, programiranje nasuprot obimnoj dokumentaciji, razvoj usmeren testovima, neprekidnu integraciju i drugo. [5, 26 str.] U softverskom inenjerstvu, agilne metode razvoja softvera minimiziraju rizik time to osiguravaju da su inenjeri koji razvijaju softver fokusirani na male jedinice posla. To je naroito vano sa dananjim rapidnim rastom industrije vezane za Internet, sa okolinom vezanom za mobilne aplikacije i sa distribuiranim razvojem. Glavno pitanje je ta ini razvojnu metodu agilnom? To je sluaj kada je razvoj softvera: inkrementalan (male isporuke, sa brzim ciklusima) kooperativan (naruioc i razvojni tim rade neprestano zajedno u bliskoj komunikaciji) direktan (metoda je jednostavna za uenje i modifikovanje) prilagodljiv (u mogunosti da se ine promene u poslednjem trenutku). Kao rezultat agilnog pristupa u razvoju softvera, mogu se izdvojiti sledee agilne metode koje su definisane na naelima jednostavnosti i brzine: Ekstremno programiranje (Extreme Programming - XP) Larmanova metoda Jedinstveni proces razvoja softvera (Unified Proces - UP) Scrum1

Podnaslov prve knjige o XP-u, Extreme Programming Explained: Embrace Change, Kent Beck

14

Zbog svoje vanosti za ovaj rad, metoda ekstremno programiranje je detaljnije objanjena (u posebnom poglavlju) u odnosu na ostale pomenute metode. Primena agilnog razvoja nije do danas do kraja istraena. Oekuje se potvrda vremena.

2.2.1.1. Larmanova metoda razvoja softvera Larma nova metoda ivotnog ciklusa softvera je bazirana na iterativ no inkrementalnom modelu ivotnog ciklusa softvera, koristi upravljanj e prem a sluajevima-korienja (use-case driven) strategiju i objektno orijentisa nu metodu projektovanj a softvera. Za notaciju se koriste UML dijagrami. Faze Larmanove metode razvoja softvera su: 1. Opis zahteva i sluajevi korienja 2. Analiza 3. Projektovanje 4. Implementacija 5. Testiranje U prvoj fazi se formuliu zahtevi koje softver treba da ispuni. Zahtevi se opisuju pomou Modela sluajakorienja (Use-case Model), kojim se opisuje skup eljenih korienja sistema od strane korisnika [1]. U ovoj fazi se definiu uesnici u sistemu i svi sluajevi korienja. Najee se poinje

tekstualnim opisom zahteva da bi se, formiranjem sluajeva korienja, taj zahtev transformisao u manje ali logiki relativno nezavisne celine. Sluajevi korienja se opisuju tekstualno i grafiki.Faza analize opisuje logiku strukturu i ponaanje softverskog sistema (poslovnu logiku softverskog sistema). Glavni dijagrami koji se kreiraju u fazi analize su: konceptualni model; sekvencijalni dijagrami sistema; ugovori.

15

U ovoj fazi se definie konceptualni model koji slui kao osnova za izradu relacionog modela i eme baze podataka. U treoj fazi vri se projektovanje aplikacione strukture, njenih klasa i metoda. Na osnovu objektnoorijentisane analize koja je prethodila, opisuje fizika struktura i ponaanje softverskog sistema (arhitektura softverskog sistema). Kao ulaz koriste se rezultati iz prethodne faze: konceptualni model i sistemske

operacije i njihovi ugovori. Izlaz iz ove faze su stvarni sluajevi korienja, dijagrami saradnje, dijagrami sekvenci za sistemske operacije i dijagrami klasa koji obuhvataju sve klase iz aplikacije i njihove relacije i metode. etvrta faza je faza implementacije. Svaka klasa iz dijagrama se implementira po unapred definisanom redosledu: prvo se implementiraju klase koje ne zavise od drugih klasa, pa se u svakom sledeem ciklusu implementiraju samo one klase koje zavise iskljuivo od ve implementiranih. Izlaz iz faze je program. U studijskom primeru korien je programski jezik Java, pri emu je realizacijastudijskog primera data korienjem Servlet tehnologije.

Poslednja faza je faza testiranja programa. Mada Larman podrazumeva fazu testiranja posle faze implementacije, opta preporuka je da se ove dve faze vre paralelno, odnosno da se testovi za klase piu i izvravaju uporedo sa implementacijom samih klasa. Iterativ no inkreme ntalni model ivotnog ciklusa softvera je u ovoj metodi implementiran kroz uzastopno poveanje i usavravanj e sistema kroz vie razvoj nih ciklusa analize, projektovanja, implementacije i testiranja. Sistem raste dodavanjem novih funkcionalnosti sa svakim razvojnim ciklusom. Posle preliminarne faze planiranja i razrade, razvoj se nastavlja u fazi izgradnje kroz seriju razvojnih ciklusa analize, projektovanja, implementacije i testiranja. Sluajevi-korienja tre ba da budu rangira ni, i oni sa najviim rangom treba da se obrade u ranim razvoj nim ciklusima. Osnovna strategija je da se prvo izaberu sluajevi-korienja koji znaajna utiu na osnovnu arhitekturu, obraivanjem domenskih i uslunih slojeva visokog nivoa, ili da se izaberu sluajevi-korienja sa najveim stepenom rizika. 16

2.2.1.2. Jedinstveni proces razvoja softvera (Unified Proces) Jedinstveni proces razvoja softvera je metoda bazirana na iterativ no inkreme ntalnom modelu ivotnog ciklusa softvera, koristi strategije upravljanj e prem a sluajevima-korienja (use-case driven) i orijentacij e ka arhitekturi (architecture centric), kao i objektno orije ntisanu metodu proje ktovanj a sof tvera. Za notaciju se koriste UML dijagrami. Neke od kljunih praksi i smernica jedinstvenog procesa razvoja softvera su sledee [5, 173 str.]:Razvoj u kratkim, vremenski ogranienim (timeboxed) iteracijama; Razvoj visoko rizinih i elemenata sa visokom vrednou (na primer, osnovna arhitektura) u ranim iteracijama, preferirajui ponovno korienje (re-use) postojeih komponenti; Osigurava stvaranje vrednosti klijentu, izdavanjem nekoliko verzija koje mu se isporuuju; Prilagoavanje promenama rano u projektu; Usresreenost lanova tima na timski rad;

Za prosene projekte, preporuena veliina, vremenski ograniene iteracije je izmeu dve i est nedelja [5, 174 str.] Jedinstveni proces ohrabruje veoma mali stepen formalizma, iako u optem smislu preporuuje vie dokumentacije i modeliranja nego u drugim metodama koje koriste model iterativno inkrementalnog razvoja. Jedinstveni proces razvoja softvera (JPRS) se sastoji iz etiri faze: poetak (inception), razvoj usavravanje (elaboration), graenja (construction) i prelaz (transition) [5, 180 str.]. Faze su detaljnije definisane u [5, 100 str.]:Poetna faza definie opseg projekta i viziju krajnjeg proizvoda. Ovde se navode osnovni sluajevi-korienja (SK). U toku razvojne faze pravi se plan projekta, SK se razrauju i daje se nacrt arhitekture sistema.

17

U fazi graenja dobija se kompletan softver koji se pridruuje do arhitekture sistema. Na taj nain se dolazi do Beta Verzije Riliza (BVR). U prelaznoj fazi BVR se prosleuje do korisnika radi testiranja. Nakon ispravke uoenih problema pravi se generalni riliz. U prelaznoj fazi se obuavaju korisnici.2

Na slici 5 [5, 180 str.] je prikazan ivotni ciklus jedinstvenog procesa razvoja softvera, sa naglaskom na aktivnosti i svrhu faza.

Slika 5: ivotni ciklus jedinstvenog procesa razvoja softvera

2

Riliz (release) oznaava jednu verziju isporuenog softverskog proizvoda

18

2.2.1.3. Scrum Scrum je metoda ivotnog ciklusa softvera koja je bazirana na iterativ no inkrementalnom modelu ivotnog ciklusa softvera. Ona naglaava menaderske aspekte razvoja softverskog projekta, nasuprot pristupu gde se naglasak stavlja na standardnim fazama ivotnog ciklusa softvera (prikupljanje korisnikih zahteva, analiza, projektovanje, implementacija, testiranje i odravanje). Kao takva, lako se moe kombinovati sa ili biti dopuna drugim metodama [5, 111 str.]. Neke od kljunih praksi i smernica scrum-a ilustruju njegovu sutinu [5, 109 str.]: Samo-upravljivi i samo-organizijui timovi; Dnevni, stojei (stand-up) sastanci na kojima se postavljaju pitanja kljuna za razvoj softvera Iteracije obino traju 30 kalendarskih dana Adaptivno planiranje, usmereno na klijenta (client-driven) Na kraju svake iteracije klijentu se isporuuje verzija Na slici 6 [5, 113 str.] je prikazan ivotni ciklus scrum-a, sa naglaskom na aktivnosti i svrhu faza.ANALIZA (PRE-GAME)PLANIR ANJE SVRHA: POBUIVANJE (STAGING) SVRHA:

RAZVOJ

ISPORUKA

SVRHA: - implemetacija sistema u iteracijama od 30 dana

SVRHA: - operativno razvijanje

- utvrivanje vizije, - identifikacija kor. zahteva i oekivanja i obezbeivanje definisanje prioriteta za prvu potrebnih finansijskih iteraciju sredstava AKTIVNO STI: - pisanje vizije, budeta i procenjivanje stavki - istraivaki dizajn prototipovi AKTIVNOSTI: - planiranje

AKTIVNOSTI: - planiranje svake iteracije i procene - dnevni sastanci - istraivako dizajn i prototipovi

AKTIVNOSTI: - dokumentovanje - trening - marketing i prodaja

- izvetavanje

Slika 6: ivotni ciklus Scrum-a

19

2.2.1.4. Ekstremno programiranje (Extre me Program ming - XP) Ekstremno programiranje (XP) je dobro poznata agilna metoda; naglaava saradnju, brzo razvijanje softvera i postupke vetog razvoja softvera. Zasniva se na sledeim vrednostima: komunikacija, jednostavnost, povratna sprega i hrabrost. Pored iterativno-inkrementalnog modela razvoja softvera, preporuuje dvanaest postupaka koji predstavljaju sr XP-a [5, 137 str.]: 1. Planiranje igre 2. Male, stalne isporuke 3. Metafore sistema 4. Jednostavan dizajn 5. Testiranje 6. Stalno refaktorisanje 7. Programiranje u paru 8. Kolektivno vlasnitvo koda 9. Stalna integracija 10. Radna nedelja od 40 sati 11. Kupac na terenu 12. Standardi u kodiranju Ekstremno programiranje je kreirao Kent Beck 1996. godine kao nain prevazilaenja problema i spaavanja projekta C3 (Chrysler Comprehensive Compensation). XP metoda ivotnog ciklusa softvera je bazirana na iterativ no inkreme ntalnom modelu ivotnog ciklusa softvera (IID). Ova metoda naglaava brzo kreiranje visoko kvalitetnog softvera, tehnike vetog i odrivog razvoja softvera i fleksibilan odgovor na promene. Namenjena je relativno malim projektnim timovima; obino je rok isporuke softvera manji od godinu dana. Iteracije su kratke od jedne do tri nedelje [5, 139 str.]. XP primenjuje razvoj voen testovima (test-driven development), refaktorisanje , programiranje u paru i stalnu integraciju koda. Zahvaljujui tome, programeri mogu sa vie samopouzdanja da4 3

3 4

Poboljanje dizajna postojeeg koda, a da se pritom ne promeni oigledno ponaanje sistema. Komponente sistema se vie puta dnevno ugrauju.

20

odgovore na promene korisnikih 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 menaderi formiraju tim koji radi u projektnoj sobi (project room) gde brzo razvijaju softver. Napomena: U ovoj tezi, poseban akcenat se stavlja na Ekstremno programiranje. Primenom ove metode ivotnog ciklusa softver razvijae se aplikacija (Elektronska prodavnica) i detaljno e biti objanjena u posebnoj glavi ove teze.

-------------------------------------------------------------------------------------------------------------------------

2.3. STRATEGI JE IVOTNOG CIKLUSA SOFTVERA ------------------------------------------------------------------------------------------------------Pored modela, veliki uticaj na ivotni ciklus softvera imaju strateki pristupi ovom procesu, tj. strategij e ivotnog ciklusa softvera. Neke od strategija ivotnog ciklusa softvera su: upravljan je prem a sluajevima-korienja (use-case driven), orijentacij a ka arhitekturi (architecture centric) i razvoj voen testovima (test-driven development).

Upravljan je prema sluajevima-korienja (use-case driven) Sluaj korienja (SK) je deo funkcionalnosti sistema koji korisniku daje neki rezultat (vrednost). To znai da SK opisuju funkcionalne zahteve. Svi SK zajedno ine model SK koji opisuje kompletnu funkcionalnost sistema. Model SK odgovara kod specifikacije sistema na sledee pitanje: ta sistem treba da radi za svakog korisnika. za razliku od tradicionalne funkcionalne specifikacije koja je odgovarala na pitanje: ta sistem treba da radi? To znai da su potrebe korisnika u osnovi specifikacije sistema.

21

SK istovremeno iniciraju i povezuju kompletan proces razvoja softverskog sistema. To znai da se pomou SK proizvoda. Sluajevi korienja (SK) se razvijaju zajedno sa sistemskom arhitekturom. SK upravljaju sistemskom arhitekturom dok sistemska arhitektura utie na selekciju SK. upravlja analizom, projektovanjem, implementacijom i testiranjem softevrskog

Orije ntaci ja ka arhitekturi (architectu re-ce ntric ) Arhitektura softverskog sistema(ASS) obuhvata najvanije statike i dinamike aspekte sistema. ASS pored toga obuhvata: platformu na kojoj se izvrava softver (kompjuterska arhitektura, operativni sistem, DBMS, protokoli za mrenu komunikaciju), raspoloive komponente koje se mogu ponovo koristiti(npr: okvir za grafiki korisniki interfejs), sistem naslea (legacy system), nefunkcionalne zahteve (performanse, prenosivost,...). Veza izmeu SK i arhitekture se moe objasniti na sledei nain: Svaki proizvod ima funkciju i oblik(form) koji moraju biti izmeu sebe povezani. Funkcija korespondira sa SK, dok oblik korespondira sa arhitekturom. SK moraju, kada se realizuju, da se ugrade u arhitekturu. Arhitektura mora da obezbedi prostor da se u nju ugrade svi sadanji a po mogunosti i budui SK. Arhitektura i SK moraju da se razvijaju paralelno.Kod razvoja arhitekture prvo se kreira onaj deo arhitekture (platforma) koji je nezavisan od SK. Zatim se arhitektura razvija zajedno sa SK koji predstavljaju kljune funkcije razmatranog sistema.

5

2.3.3 Razvoj voen testovima (test-driven development - TDD) Test Driven Development je tehnika razvoja softvera koja podrazumeva stalno i prevashodno testiranje napisanog koda. Test se pie pre koda, a nakon toga se pie izvorni kod koji treba da zadovolji test. Refaktorisanjem se taj kod dalje preiava i pojednostavljuje, ali osnovno je da test koji se jednom verifikovao mora da se iznova verifikuje, pri svim sledeim izmenama. Osim takvog5

U kont ekstu ivotnog ciklusa softvera, znai da se sistemska arhite ktura u toku razvoja softvera koristi kao glavni artifakt za konceptualiz aciju, konstruk ciju, upravljanje i razraivanje sistema.

22

jedininog testiranja (unit test), postoje i funkcionalni testovi kroz test primere, odnosno test sluajeve (test case) koje izvodi sam klijent. Testovi korisnosti i korisnikog interfejsa se takoe izvode kod klijenta. TDD brzo daje povratnu vezu (feedback). Ova tehnika je poela da privlai panju poetkom 2000-te, kao aspekt Ekstremnog programiranja, ali poslednjih godina zaokuplja veu panju. [19] Postoje razni aspekti TDD razvoja, kao to su na primer principi Keep It Simple, Stupid (KISS), i You Aint Gonna Need It (YAGNI). Fokusirajui se samo na kod koji mora da zadovolji test, dizajn moe biti jasniji i istiji nego to se to obino moe postii nekom drugom metodom. TDD zahteva da programeri prvo napiu test case koji ne prolazi, kako bi bili sigurni da test zaista radi ispravno i da moe da uhvati greku. Napomena: U ovoj tezi, poseban akcenat se stavlja na strategiju ivotnog ciklusa softvera koja je voena testovima, jer e se primeniti u razvoju aplikacije (Elektronska prodavnica).

------------------------------------------------------------------------------------------------------AKTIVNOSTI IVOTNOG CIKLUSA SOFTVERA ------------------------------------------------------------------------------------------------------Proces razvoja softvera obuhvata 5 faza: specifikacija zahteva, projektovanje (dizajniranje), implementacija, testiranje, isporuivanje, odravanje sistema.

2.4.1 Prikupljanje korisnikih zahteva Zahtev predstavlja izraz eljenog ponaanja. Bavi se objektima ili entitetima, stanjima u kojima oni mogu biti, kao i funkcijama koje se izvode radi promene stanja ili osobina objekta. Cilj faze definisanja zahteva je razumevanje problema i potreba naruioca. Zahtevi oznaavaju kakvo ponaanje naruilac eli, bez izraavanja kako e to ponaanje biti ostvareno. [19, 143 str.]

23

Slika 7: Proces evidentir anja zahteva

Na slici 7 [19, 143 str.] je prikazan proces evidentiranja zahteva za softverski sistem. Analitiar zahteva prvo radi sa naruiocima na izvoenju zahteva (postavlja pitanja, ispituje aktuelno ponaanje ili demonstrira sline sisteme). Nakon toga zahteve evidentiramo u sklopu modela ili prototipa, to pomae da se bolje razume zahtevano ponaanje. Kada se postigne dobro razumevanje zahteva, nastavlja se izradom specifikacije u kojoj se odluuje koji e delovi zahtevanog ponaanja biti implementirani u softveru. Tokom validacije proverava se da li specifikacija odgovara onome to naruilac eli da vidi u finalnom proizvodu. Aktivnosti analize i validacije mogu da otkriju probleme ili propuste u modelu ili specifikaciji, to dovodi do ponovnih poseta naruiocu i revidiranje modela i specifikacije. Krajnji ishod je specifikacija softverskih zahteva (Software Requirements Specification, SRS) koja se koristi za komunikaciju sa drugim lanovima razvojnog tima, koji rade na projektovanju, testiranju i odravanju, o tome kako konani proizvod treba da se ponaa.

2.4.2. Proj ektovan je (dizajniranje) sistema Sledei korak u razvoju je prevoenje elja klijenata u reenje: projektovanje koje e zadovoljiti potrebe klijenta. Projektovanje je kreativni proces pretvaranja problema u reenje. Specifikacija zahteva definie problem, a zatim dolazi reenje problema koje zadovoljava sve zahteve i specifikacije. Priroda reenja moe da se menja i u toku opisa ili implementacije. To nije nista neobino ni nerazumno. Modifikacije ne moraju biti rezultat hira, mogu da nastanu zbog

24

promenjenog doivljaja ili potrebe. Opis sistema moe da se menja tokom ciklusa razvoja. Klijent esto zajedno sa projektantima menja zahteve i posle okonanja poetne analize zahteva. Dizajn je iterativni proces koji se sastoji iz dva dela. Prvo se pravi konceptualni dizajn ili dizajn sistema koji opisuje klijentu tano ta e sistem da radi. Kada klijent odobri konceptualni dizajn, on se prevodi u detaljniji dokument, tehniki dizajn koji omoguava graditeljima sistema da utvrde koji e hardver i softver biti potrebni za reenje klijentovog problema. Konceptualni dizajn se odnosi na funkcije sistema, dok tehniki dizajn opisuje oblik sistema. [19, 224 str.] Sistem se u konceptualnom dizajnu opisuje jezikom koji klijent razume. Opisuje se ta sistem radi, a u tehnikom kako radi. Konceptualni dizajn omoguava klijentu da shvati ta e sistem raditi tako to objanjava vidljive spoljanje karakteristike sistema, dok tehniki dizajn opisuje konfiguraciju hardvera, softverske potrebe, komunikacione interfejse, ulaze u sistem i izlaze iz njega, mrenu arhitekturu i sve ostalo ime se zahtevi prevode u reenje klijentovog problema. Gledano kao proces, projektovanj e softvera (software design) je aktivnost inenjerskog ivotnog ciklusa softvera, u kojoj se analiziraju korisnikih zahtevi da bi se dobio opis interne strukture softvera koja e sluiti kao osnova za njegovu konstrukciju. Preciznije reeno, rezultat projektovanja softvera mora da opie softversku arhite kturu tj. kako je softver rastavljen i organizovan u komponenete i da opie interfejse izmeu ovih komponenti. On mora da opie i komponenete na nivou detalja koji omoguava njihovu konstrukciju. [6, 3-1] Projektovanje softvera sastoji iz dve aktivnosti koje se nalaze izmeu analize korisnikih zahteva i konstrukcije softvera: [6, 3-1]Arh itekturalno projekt ovanj e softvera (poznato i kao projektovanje na vrhu (toplevel design) ili makro arhitektura): opisuje najviu strukturu i organizaciju i identifikuje razliite komponente Detaljno projektovanj e softvera (poznato i kao mikro arhitektura): dovoljno opisuje svaku komponentu da bi bilo mogue da se ona konstruie

Prilikom projektovanja za beleenje glavne projektantske odluke koje su doneene koriste se razliite notacije i jezici. Jedna od podela notacija je na one koje opisuju strukturni, tj. pogled, nasuprot onima koje opisuju ponaanje, tj. dinamini pogled. 25 statini

UML (Unified Modeling Language) je esto korien u obe vrste notacije. Dinamiki prikaz se izvodi putem sluaja korienja, spiska aktivnosti, dijagrama interakcije koji modeluju saradnju objekata i sekvence u obavljanju aktivnosti, i dijagramima stanja koji ilustruju stanja sistema i prelaze stanja. Statiki prikaz se definie na osnovu dijagrama klasa sa njihovim vezama (asocijacija, generalizacija, zavisnost i implementacija) i proirenjima (ogranienja, kljune vrednosti). UML je popularna notacija za opisivanje OO (Object Oriented) reenja. Moe da se koristi za vizualizaciju, specifikovanje ili za dokumentovanje problema. Koristi se za opisivanje razliitih varijanti projektnih reenja, a posebno za dokumentovanje proizvoda procesa projektovanja. Za projektovanje softvera koriste se metode proje ktovanj a softvera koje predstavljaju specifine strategije, i koje predlau i pruaju skup notacija koje se koriste sa metodom (kao opis procesa koji bi trebalo koristi prilikom praenja metode, i skup smernica za korienje metode). Neke od metoda projektovanja softvera su [20 str. 3-5]: funkcionalno-orijentisano proje ktovanje , objektnoorije ntisano proje ktovanje , projektovanj e orije ntisano ka strukturama podataka (DataStructure-Centered Design) i proje ktovanj e bazirano na komponentama. Objektno orijentisani razvoj softvera zasluuje posebnu panju zato to veliki broj novih sistema koji se danas razvijaju delimino ili potpuno prihvata objektnu orijentaciju. Objektna orijentacija predstavlja skup objekata koje karakterie odreena struktura i ponaanje. Ona se moe prepoznati na osnovu svojih sedam karakteristika: identiteta, apstrakcije, klasifikacije, uaurenje (enkapsulacije), nasleivanja, polimorfizma i perzistencije (trajanja). [19, 286 str.] Ident itet postoji jer objekat, kao jedinstvena prepoznatljiva celina, ima svojstvena stanja i ponaanja. Svaki objekat u OO sistemu sadri ime (referenca ili hendl), koje omoguava meusobno razlikovanje objekata. [19, 288 str.]

26

Apstra kcija je bitna za izgradnju svakog sistema, bez obzira da li je OO ili ne. Apstrakcije u OO sistemu omoguavaju da se predstave razliiti aspekti sistema koji je predmet projektovanja. [19, 288 str.] Klasifikacija se koristi u OO razvoju softvera za grupisanje objekata sa zajednikim svojstvima i ponaanjem. Klasi se dodeljuju atributi (struktura) i operacije (ponaanja). [19, 288 str.] Svaki objekat neke klase predstavlja primer ak (instancu) te klase. Svaki primerak poseduje vlastite vrednosti atributa (koji opisuju njegovo stanje) ali sa ostalim primercima iste klase deli imena atributa i ponaanja. [19, 290 str.] Moe se zakljuiti da klasa opisuje skup objekata sa zajednikom strukturom i ponaanjem, gde vrednosti atributa omoguavaju da se konkretni objekti meusobno razlikuju. OO sistem karakterie uaurenje. Klasa vri uaurenje ponaanja i atributa objekta i sakriva implementacione detalje. Berard (2000) istie da je uaurenje tehnika za pakovanje informacija na takav nain da se sakrije ono to treba da bude sakriveno, a da se pri tome vidi ono to elimo da bude vidljivo. [19, 290 str.] Klase se mogu organizovati u hijerarhiju na osnovu slinosti ili razlika, pri emu ta hijerarhija definie strukturu nasleivanja. Podklasa moe da nasleuje i strukturu i ponaanje nadreene klase. U cilju pojednostavljenja hijerarhije koristi se apstraktna klasa , koja sama ne instancira objekte ve se oni instanciraju jedino kao objekti podklasa. Ponaanje je akcija ili transformacija koju vri objekat ili koja se nad njim vri. Mogue je da se isto ponaanje razliito manifestuje kod razliitih klasa ili podklasa i ta osobina se naziva polimorfizam. Polimorfizam omoguava dodavanje nove klase bez promene postojeeg koda. Persistentnost (trajno st) je sposobnost da ime, stanje i ponaanje objekta opstanu u vremenu i prostoru, odnosno, ime, stanje i ponaanje objekta se uvaju prilikom njegove transformacije. [19, 291 str.]

27

2.4.3. Implementacija Kada se shvati problem kupaca i korisnika i formulie opte reenje, sledi implementacija tog reenja u obliku softvera, odnosno pie se program koji implementira dizajn. U ovom radu predmet istraivanja je implementacija on-line prodavnice primenom metode ekstremnog programiranja. Iz tog razloga je opisana odreena filozofija programiranja kod ekstremnog programiranja. U ekstremnom programiranju postoje dve vrste uesnika: kupci i programeri. Kupci predstavljaju korisnike budueg sistema. Oni izvravaju sledee aktivnosti: definiu svojstva koja e programeri da implementiraju, koristei formu scenarija da opiu nain funkcionisanja sistema; opisuju detaljne testove koji e se izvravati kada softver bude spreman, kako bi proverili da li su scenariji pravilno implementirani; dodeljuju prioritete scenarijama i njihovom testiranju. Zatim programeri piu kod kojim implementiraju scenarije i to redosledom kojim su kupci postavili prioritete. Programeri moraju da procene koliko e trajati kodiranje svakog scenarija kako bi kupci mogli da planiraju testove prihvatanja. U ovom radu se napominju Java implementacione tehnologije sa akcentom na Java platformu. Softverske platforme ukljuuju arhitekturu, operativni sistem ili programski jezik i njihove izvrne (runtime) biblioteke. Neke od softverskih platformi su Java, .NET, VxWorks, QNX, MFC i druge.

2.4.3.1. Java platforma Predstavlja naziv za skup Java tehnologija iji je proizvoa Sun Microsystem. Java programski jezik je razvijen kao odgovor na izazov razvoja aplikacija u heterogenom i distribuiranom okruenju.

28

Java platforma sadri dve komponente: Java Virtuelnu Mainu (JVM) i Java Application Programming Interface (Java API). Java API je zbirka razliitih gotovih programskih komponenti koje programeru nude mnoge korisne mogunosti, na primer za implementaciju grafikog interfejsa. Platforma nije posebno namenjena nijednom procesoru ili operativnom sistemu, nego virtualnoj maini. Od Decembra 2006, tekua verzija Java Platforme je 1.6.0 ili 6. Implementiran je kompajler sa skupom standardnih biblioteka za razliiti hardver i operativne sisteme, tako da se Java programi mogu izvravati na svim OS. Java kompajler konvertuje Java izvorni kod u bajt programski kod (posredni jezik za Java Virtualnu Mainu - JVM). Bajt programski kod se interpretira pomou JVM, jer on sadri naredbe koje prepoznaje JVM i koje se preslikavaju u naredbe konkretnog operativnog sistema. U toku interpretiranja bajt programskog koda JVM proverava validnost programa (da nije dolo do kvara u programu) i bezbednost njegovog aktiviranja. [2, 5 str.] Postoje sledea izdanja Java platforme: Java Standard Edition ili Java SE (J2SE) namenjen za desktop maine Java Micro Edition ili Java ME (J2ME) namenjen za prirune ureaje (smart phones) Java Enterprise Edition ili Java EE (J2EE) namenjen za web servise Zbog svoje vanosti, Java EE platforma je opisana u posebnom poglavlju (poglavlje 3. Java Enterprise Edition Java EE).

2.4.3.2. .NET platforma .NET je Microsoftov odgovor na Sanovu Java platformu. Microsoft .NET obuhvata veliku kolekciju Microsoftovih proizvoda i tehnologija. Microsoft proizvodi i komponente, koje spadaju u .NET kategoriju, ukljuuju: Microsoft .NET okvir (Framework), komponentu operativnog sistema koju zahtevaju veina .NET proizvoda NET Passport (ifru)

29

Microsoft .NET Framework je softverska komponenta koja moe biti dodata ili je deo Microsoft operativnog sistema. Upravlja izvrenjem programa koji su specijalno napisani za taj okvir. Osnovni delovi .NET okvira (.NET Framework) su: Zejedniki jezik u fazi izvravanja (Common language runtine - CLR) Biblioteke klasa (Framework Class Library - FCL) Slojevi koji se nalaze iznad CLR predstaljaju .NET Framework Class Library koji omoguava brz razvoj softverskih aplikacija. U tabeli 1. su prikazane samo neke od baznih klasa. Framework Class Library ima preko 5000 klasa. CLR omoguava postojanje virtualne maine, tako da programeri ne moraju da uzimaju u obzir mogunosti CPU-a pri izvravanju programa. CLR takoe omoguava i druge bitne servise kao to su mehanizmi sigurnosti (zatite), upravljanje memorijom (memory management), i obrada izuzetaka. Microsoft je zapoeo razvoj .NET okvira kasnih 90-ih pod imenom Next Generation Windows Services (NGWS). Krajem 2000 godine prva beta verzija .NET 1.0 je razvijena.

2.4.4. Test iranje programa Kada se kodiraju programske komponente, potrebno ih je testirati kako bi se kupcima isporuili kvalitetni softverski sistemi. Bez obzira koliko su programeri veti u pisanju programa, zbog raznolikosti moguih otkaza treba proveriti da li su komponente ispravno kodirane. Mnogi programeri posmatraju testiranje kao dokaz da njihovi programi ispravno rade, meutim upravo suprotno tome, programi se testiraju da bi se dokazalo postojanje greaka. Poto je cilj da se greka otkrije, test se smatra uspenim samo ako se greka otkrije ili ako doe do otkaza u toku testiranja. Prepoznavanje greaka je postupak utvrivanja zbog koje greke, ili greaka, je dolo do otkaza [19, 366 str.]. Ispravljanje greaka ili otklanjanje greaka je postupak unoenja izmena u sistem u cilju otklanjanja greaka [19, 366 str.]. 30

2.4.4.1 Organizacija testiranja Kada se razvija veliki sistem, testiranje zahteva vie faza. Na slici 8 [19, 372 str.] su predstavljeni koraci testiranja. Prvo se zasebno testira svaka programska komponenta, nezavisno od ostalih delova sistema. Takvo testiranje modula (jedinino testiranje) proverava da li pojedinane komponente ispravno funkcioniu sa svim oekivanim tipovima ulaza, u skladu sa dizajnom komponente. Jedinino testiranje treba vriti u kontrolisanom okruenju tako da tim za testiranje moe komponenti koja se testira da predaje unapred definisan skup podataka, i da posmatra izlazne akcije i rezultate. Takoe, tim za testiranje proverava unutranju strukturu podataka, logiku i granine uslove za ulazne i izlazne podatke [19, 371 str.]. Kada se zavri jedinino testiranje skupa komponenti, sledi provera da li su interfejsi izmeu komponenti pravilno definisani i realizovani. Integrac iono test iranje je postupak provere da li sistemske komponente sarauju kao to je opisano u specifikacijama dizajna sistema i programa. [19, 371 str.]. Funkcionalnim testiranjem se proverava da li integrisani sistem zaista izvrava funkcije opisane u specifikaciji zahteva. [19, 371 str.]. Kao rezultat dobija se funkcionalni softverski sistem. Funkcionalni test predstavlja poreenje sistema koji se gradi sa funkcijama zahteva kupca. Test iranj em performanse sistem se poredi sa ostatkom hardverskih i softverskih zahteva. Kada se to testiranje uspeno obavi u stvarnom radnom okruenju kupca, dobija se validiran sistem [19, 372 str.]. U sledeem koraku, zajedno sa kupcem se obavlja zavrni test prihva tanja, u kojem se proverava usklaenost sistema sa opisom zahteva kupca. Kada se obavi zavrni test, prihvaeni sistem se instalira u okruenje u kome e se koristiti. Konani instalacioni test potvruje da li sistem i dalje ispravno funkcionie.

31

Slika 8: Koraci testiranja

Smith i Robson [7, 45-54 str.] smatraju da bi testiranje objektno-orijentisanih sistema trebalo da obuhvati mnoge razliite nivoe: funkcije, klase, klastere (grupe objekata koji sarauju i meusobno utiu jedni na druge) i sistem kao celinu. Tokom testiranja treba obratiti panju na probleme u vezi sa konkurentnim radom i sinhronizacijom, i treba proveriti da li su odgovarajui dogaaji potpuni i konzistentni. 2.4.4.2. Automat izovani alati za testiranje Postoje mnogi automatizovani alati za testiranje koji pomau prilikom testiranja komponenti. S obzirom na veliinu i sloenost veine dananjih sistema, alati za automatizovano izvravanje testova su bitni jer omoguavaju veoma veliki broj sluajeva za testiranje, bez kojih sistem ne bi bio temeljito testiran. Alati za izvravanje testova mogu da se integriu sa drugim alatima radi izgradnje okruenja za sveobuhvatno testiranje. Alati se esto povezuju sa bazom podataka za testiranje, mernim alatima, alatima za analizu koda, editorima teksta i alatima za simulaciju i modelovanje da bi se automatizovao to je mogue vei deo procesa testiranja. 32

Meutim, nije isto utvrditi da greka postoji i pronai samu greku. Testiranje e uvek zahtevati ljudski trud u traenju izvora za svaki problem. Automatizacija pomae, ali ne moe da zameni ovu ovekovu funkciju. Predmet istraivanja u ovom radu je JUnit automatizovani alat za testiranje. JUnit predstavlja open source okvir za testiranje, koji se koristi sa programskim jezikom Java. JUnit je nastao na osnovu originalnog okruenja za testiranje u SmallTalku, koje je napisao Kent Beck (SUnit). Ovo okruenje omoguava ogromnom broju Java programera da lako testiraju svoje komponente. Zbog svoje vanosti, JUnit je opisan u posebnom poglavlju (peto poglavlje).

2.4.5. Isporu ka softverskog sistema Dva kljuna pitanja pri uvoenju softverskog sistema su: obuka i dokumentacija. Kada se projektuje sistem, planira se i razvijaju se sredstva koja e pomoi korisniku da koristi taj sistem. Sistem prati dokumentacija kojoj se korisnici obraaju za reavanje nastalih problema ili za dalje informacije.

2.4.6. Odravanje softverskog sistema Sve aktivnosti vezane za izmenu sistema posle njegovog uvoenja u eksploataciju smatraju se da pripadaju fazi odravanja[1, 499 str.]. Odravanje sistema se razlikuje od razvoja sistema. Kod razvoja sistema tim je usredsreen na izradu koda koji zadovoljava postavljene zahteve. Ljudi iz odravanja vode rauna o proizvodima procesa razvoja, ali takoe i o sadanjosti, uspostavljajui spregu sa korisnicima i operaterima da bi utvrdili kako su oni zadovoljni nainom rada sistema. Takoe se moraju predvideti stvari koje mogu da krenu loe, razmotriti izmene funkcionalnosti koje su posledica izmena u poslovanju i sagledati izmene sistema koje su posledica izmene hardvera, softvera ili interfejsa.

2.5 Saetak U ovom poglavlju dat je prikaz ivotnog ciklusa softvera. Prikazani su modeli ivotnog ciklusa softvera (model vodopada, spiralni model, model evolucionarnog prototipa, i, za ovaj rad najbitniji, iterativno-inkrementalni model). Zatim su prikazane metode ivotnog ciklusa softvera. Detaljno su 33

objanjene agilne metode razvoja softvera: Larmanova metoda, Jedinstveni proces razvoja sofvera, Scrum i Ekstremno programiranje. Objanjene su zatim strategije ivotnog ciklusa softvera (upravljanje prema sluajevima korienja, orijentacija ka arhitekturi i razvoj voen testovima, kao najbitnija strategija za ovaj rad). Na kraju ovog poglavlja prikazane su aktivnosti ivotnog ciklusa softvera: prikupljanje korisnikih zahteva, projektovanje softverskog sistema, implementacija, testiranje, isporuka softverskog sistema i odravanje softverskog sistema. Na taj nain smo realizovali prvi cilj istraivanja (Dati pregled ivotnog ciklusa softvera).

34

3. EKSTREMNO PROGRAMIRANJE (Extreme Programming - XP)Lako je imati komplikovanu ideju. Veoma je teko imati jednostavnu ideju - Carver Mead

3.1. Nastanak XP-aEkstremno 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 nain spaavanja 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 vei broj softverskih kompanija prelazi na ekstremno programiranje. U svakom konkretnom sluaju i za svaki pojedinani zahtev, softverska kompanija se moe drugaije organizovati, jer ekstremno programiranje ne predstavlja krutu metodu, ve dozvoljava taktike izmene u proceduri izvoenja pojedinih aktivnosti. Zajedniko za sve je korienje obaveznih praktinih preporuka. ak i sprovoenje praktinih preporuka (praksi) podlee adaptacijama, zavisno od potrebe.

3.2. ta je Ekstremno programiranje?Ekstremno programiranje (XP) je dobro poznata agilna metoda; naglaava saradnju, brzo razvijanje softvera i postupke vetog razvoja softvera. Zasniva se na sledeim vrednostima: komunikacija, jednostavnost, povratna sprega i hrabrost. Pored iterativno-inkrementalnog modela razvoja softvera, preporuuje 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 vlasnitvo 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 naglaava brzo kreiranje visoko kvalitetnog softvera, tehnike vetog i odrivog razvoja softvera i fleksibilan odgovor na promene. Namenjena je relativno malim projektnim timovima; obino je rok isporuke softvera manji od godinu dana. Iteracije su kratke od jedne do tri nedelje [5, 139 str.]. XP primenjuje razvoj voen testovima (test-driven development), refaktorisanje , programiranje u paru i stalnu integraciju7 6

koda. Zahvaljujui tome, programeri mogu sa vie samopouzdanja da

odgovore na promene korisnikih 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 menaderi formiraju tim koji radi u projektnoj sobi (project room) gde brzo razvijaju softver koji sadri visoku poslovnu vrednost. XP ne tei detaljima, osim kada su u pitanju programski kod i testovi. Naglaava usmenu komunikaciju u fazama prikupljanja korisnikih zahteva i projektovanja. Na primer, korisniki6 7

Poboljanje dizajna postojeeg koda, a da se pritom ne promeni ponaanje sistema. Komponente sistema se vie puta dnevno ugrauju.

36

zahtev pronai najniu cenu putarine se rukom zapisuje na indeksiranim karticama (story card), a kada pone faza projektovanja, programeri saznaju detalje korisnikog zahteva kroz razgovor sa klijentima u projektnoj sobi, radei puno radno vreme [5, 140 str.]. XP konsultant Don Wells objanjava uticaj XP-a na razvoj softvera [18]: XP poboljava softverske projekte na etiri sutinska naina: komunikacijom, jednostavnou, povratnom spregom i hrabrou. XP programeri komuniciraju sa svojim klijentima i saradnicima. Oni odravaju svoj dizajn jednostavnim i istim. Dobijaju povratnu informaciju testirajui softver od prvog dana. Isporuuju sistem klijentima to je ranije mogue i implementiraju traene promene. Sa ovako postavljenim temeljom, XP programeri su u stanju da hrabro odgovore na promene korisnikih zahteva i tehnologije. Postoji znatan skup postupaka (practices) u XP-u: 12 postupaka koji ine sr XP-a i vie pomonih. Mnogi od ovih postupaka funkcioniu u sinergiji i rizino je ukloniti neki elemenat. Na primer, XP tei brzom razvoju softvera izbegavajui detaljnu dokumentaciju o korisnikim zahtevima. Ali to se kompenzuje stalnim prisustvom klijenta u projektnoj sobi gde se usmenom komunikacijom razrauju detalji korisnikog zahteva. [5, 141 str.] Na slici 9 [22] su prikazani vremenski okviri planiranja i povratnih veza u XP-u:

Slika 9. Vremenski okviri planiranja i povratnih veza u XP-u

37

3.3. ivotni ciklus XP-aBeck definie odreene karakteristike ivotnog ciklusa razvoja softvera u XP-u (slika 10 [5, 142 str.]): 1. Istraivanje (exploration) poetak projekta. Belee se zahtevi korisnika najvieg nivoa na karticama (story cards), pravi se tehniki prototip. 2. Planiranje (planning) definisanje prioriteta u radu. Korisnici i programeri kompletiraju Prie korisnika zabeleene na karticama (story cards) i odluuju ta treba raditi za sledeu isporuku, odnosno vri se podela na isporuke i definie prvi plan. 3. Iteracije do prve isporuke (iterations to first release) testiranje i razvoj sistema. Korisnici biraju prie koje e se implementirati prema definisanim prioritetima. Programeri onda razbijaju prie na vie manjih, procenjenih zadataka. U ovoj fazi se procenjuje koliko ljudske energije i napora je potrebno uloiti za procenjene zadatke, a to vodi ka moguem ponovnom usklaivanju izabranih korisnikih pria, s obzirom da XP ne dozvoljava da radna nedelja traje due od 40 radnih sati (8 sati dnevno). To ukazuje na nefunkcionalnost projekta, nezadovoljstvo ljudi, smanjenje produktivnosti i kvaliteta. 4. Uvoenje u proizvodnju (productionizing) programeri implementiraju prie u okviru dogovorenog perioda, neprekidno saraujui sa korisnicima (u okviru zajednike projektne sobe) na testiranju i detaljima njihovih zahteva. 5. Odravanje (meintenance) ako softver nije spreman za isporuku, potrebno je vratiti se na korak 3, na sledeu iteraciju.

38

ISTRAIVANJE

PLANIRANJE

ITER ACIJE DO PRVE ISPORUKE

UVOENJE U PROIZVODNJU

ODRAVANJE

Svrha: Svrha: Svrha: Svrha: Svrha: - Operativan razvoj - Poboljavanje, ispravka - Dovoljno dobro - Utvrivanje datuma i - Implementacija procenjene prie korisnika pria za prvu isporuku. testiranog sistema - Izgradnja veih spremnog za isporuku za prvu isporuku. (bitnijih) isporuka - Utvrivanje ostvarljivosti. Aktivnosti: - Prototipovi Aktivnosti: - Pisanje korisnikih pria na karticama i - Pisanje korisnikih pria procenjivanje na karticama i procenjivanje - Release Planning Game Aktivnosti: - Testiranje i programiranje - Iteration Game Aktivnosti: - Dokumentovanje - Obuka Planning - Marketing ... Aktivnosti: - Ako je potrebno ponavljanje faza, za inkrementalne isporuke.

- definisanje radnih zadataka i procenjivanje

Slika 10: ivotni ciklus u XP-u

3.4. Postupci u XP-u kroz faze procesa ivotnog ciklusa softveraXP ima 12 praktinih postupaka koje opisuju nain na koji tim razvija sistem. U pitanju je najbolja praksa koju su prepoznali softverski inenjeri. Ono to je novo je upotreba postupaka na usaglaen nain, koji se meusobno dopunjuju. Na taj nain se slabosti odreene preporuke prevazilaze. Postoji jo jedan aspekt praktinih postupaka koji odlikuje XP. Opta praksa je da se postupci primenjuju do krajnjih granica.

39

Korisniki zahtevi (planiranje)Planiranje isporuka Kupac na licu mesta Metafore sistema

ProjektovanjeStalno refaktorisanje Jednostavan dizajn

Test prihvaenosti softvera

ImplementacijaStalno refaktorisanje Standardi u kodiranju

Test iranje i verifikacijaTest prihvaenosti softvera, testovi klijenata Kupac na licu mesta Jedinino testiranje

Programiranje u paru

Kolektivno vlasnitvo koda

Upravljanje projektomPlaniranje igre (Planiranje isporuke) Kratke isporuke

Upravljanje promenamaStalna integracija Zajednika soba

Radna nedelja od 40 sati

stojei (standup) sastanci

Planiranje igre (Planiranje isporuke)

Slika 11: Praktini postupci u XP-u

Na slici 11 [5, 146 str.] su predstavljeni glavni praktini postupci (practices) u XP-u kroz faze procesa ivotnog ciklusa softvera. Svi ovi praktini mehanizmi moraju biti motivisani i voeni vrednostima, bez toga projekat moe da propadne.

3.4.1. Planiranje razvoja softvera u XP-uPlaniranje razvoja softvera ukljuuje akcije prikupljanja zahteva koji se oblikuju u prie korisnika (User Stories) (3.4.1.1.), planiranje isporuke na nivou itavog projekta (3.4.1.2.), vanost estih i malih isporuka (3.4.1.3.), iterativni razvoj (3.4.1.4.) odnosno podelu isporuka na iteracije i planiranje iteracije (3.4.1.5.). 40

3.4.1.1. Prie korisnika (User Stories) Prie korisnika (User Stories) imaju isti cilj kao i sluajevi korienja (Use Cases), ali zapravo nisu isto. Koriste se da bi se planirala isporuka softvera (Release Planing). Takoe, koriste se umesto obimne dokumentacije zahteva (requirements document) koje softver treba da zadovolji. Prie korisnika pie naruioc (customer) softvera kao zahteve koje softverski sistem treba da zadovolji. Sline su korisnikom scenariju, jedino to nisu ograniene opisom korisnikog interfejsa (user interface). Dakle, po svojim karakteristikama, razlikuju se od sluajeva korienja. Prie korisnika vode ka kreiranju tzv. testa prihvaenosti (Acceptance Test) softvera kojeg potvruje naruioc. Potrebno je da se kreira jedan ili vie automatizovanih testova prihvaenosti softvera kako bi se verifikovale prie korisnika, odnosno, proverilo da li su prie korisnika ispravno implementirane. Zbog estog nerazumevanja razlika izmeu pria korisnika (user stories) i sluajeva korienja (use cases), postoji potreba da se razlike bolje objasne. Najvea razlika je u stepenu detalja. Prie korisnika treba da daju dovoljno detalja kako bi se izvrila procena relativno niskog rizika koja ukazuje na to koliko dugo e trajati implementacija te prie korisnika. Kada doe vrieme za implementaciju prie, programeri od naruioca dobijaju detaljan opis zahteva. Programer procenjuje koliko dugo (vremenski) e trajati implementacija pojedine prie korisnika. Svaka pria korisnika e oduzeti jednu, dve ili tri nedelje procene u "idealnom vremenu" razvoja. Idealno vreme razvoja oznaava koliko vremena je potrebno za implementaciju prie korisnika, ukoliko ne postoje neke prepreke, druge obaveze, pa je tano poznato ta i kako treba raditi. Period dui od tri nedelje znai da bi priu korisnika trebalo podeliti u vie manjih delova. Period krai od jedne nedelje znai premalo detalja. Treba kombinovati nekoliko pria korisnika u jednu. U kreiranju procena uestvuje i naruioc. Druga bitna razlika izmeu pria korisnika i dokumentacije zahteva, odnosno sluajeva korienja je fokus na potrebe naruioca.

41

3.4.1.2. Planiranje isporuke (Release Planning) Planiranj em isporuke se kreira plan isporuke (release plan). Plan isporuke se koristi za kreiranje planova iteracija za svaku pojedinanu iteraciju. Planiranje isporuke softvera sadri skup pravila koja omoguuju svima koji su ukljueni u projekat da donose vlastite odluke. Potovanje skupa pravila omoguava definisanje vremenskog plana kojeg svako iz tima moe ispuniti. Sutina planiranja isporuke za razvojni tim je da procene svaku priu korisnika, odnosno koliko vremena im je potrebno da implementiraju datu priu, a zatim donose odluku koja pria ima najvii prioritet implementacije. Prie korisnika se piu na karticama (cards). Programeri i naruioci zajedno kreiraju skup pria koji e se implementirati za prvu (ili sledeu) isporuku. Osnovna filozofija planiranja isporuke je da projekat moe biti kvantifikovan sa etiri promenljive . To su: Vreme suvie kratko vreme utie na kvalitet proizvoda poto nema dovoljno vremena da se sasluaju kupci, da se pregleda kod i izvri testiranje. Sa druge strane, produenje vremena moda i nee dovesti do odgovora koji oekujemo. Uloga razvojnog tima je da to bre implementira promene, tako da kupac to pre dobije povratnu informaciju. Cena kupac treba da finansira razvoj do procenjenog nivoa, ali dodatna sredstva u projekat ne dovode obavezno do pokrivanja nedostataka. Kvalitet - smanjenje kvaliteta moe dovesti do skraivanja vremena razvoja softvera, ali se time poveava vreme koje je potrebno korisnicima da testiraju softver. Domen standardna procedura pri razvoju softvera predvia da se u razvoj kree tek nakon to se svi sloe o domenu proizvoda. Problem je odravanje zahteva i domena, jer kupci ele da budu sigurni da je ubaeno sve to ele i to bi mogli da poele u budunosti. XP dozvoljava da se menja domen ali fiksira ostale promenljive. Promena domena ne znai neogranieno trajanje projekta. Ako kupac u svom zahtevu doda novu osobinu, onda mora da izbaci neto to je tom zahtevu ekvivalentno po veliini. Ovo se razlikuje od 42

stalnog irenja domena gde kupac stalno proiruje svoje zahteve, ubacujui nove, koje tim nije imao u vidu. Naredni korak je planiranje pojedinanih iteracija.

3.4.1.3. Male isporuke Praktina preporuka XP-a je da se koriste male isporuke. Brzo se dobija povratna informacija o tome koliko je dobar plan. Ciklusi isporuka moraju da budu to krai zbog sigurnosti da se pravi program koji kupac oekuje. Prednost malih isporuka je u tome da razvojni tim moe da proveri tanost sa kojom su vrene procene.

3.4.1.4. Iterativni razvoj Itera tivni razvoj (Iterative Development) poveava brzinu razvoja softvera. Isporuka se deli na odreeni broj iteracija (oko desetak) koje obino traju od jedne do tri nedelje. Inicijalna iteracija se fokusira na komponente arhitekture koje su potrebne da bi se postavio osnovni sistem. Ovo je iteracija "nulta poslovna vrednost". Poeljno je da je duina iteracije konstantna tokom itavog projekta jer su iteracije zapravo ila kucavica projekta. Fiksiranje vremena (time boxing) je tehnika planiranja i kontrole projekta koja se odnosi na razvoj softvera. Svaki vremenski okvir ima fiksnu duinu, obino od jedne do tri nedelje. Osnovni princip je da se datum isporuke ne menja. Ne treba deliti programerske zadatke unapred. Umesto toga, potrebno je napraviti plan iteracija i planirati iteracije na poetku svake od njih, kako bi se odredilo ta e se raditii u trenutnoj iteraciji. Planiranje u trenutku (just-in-time planning) je jednostavan nain za praenje promena korisnikih zahteva u projektu.

43

Takoe, ne preporuuje se implementacija onoga to nije predvieno u trenutnoj iteraciji. Ta funkcionalnost e se implementirati onda kada ona postane deo jedne od sledeih korisnikih pria u nekoj od sledeih iteracija. Vano je da se ozbiljno shvate rokovi predvieni za implementaciju svake iteracije, pratei napredak tokom iteracije. U sluaju da se ne mogu zavriti svi zadaci, potrebno je izvriti novo planiranje iteracija, ponoviti procene i smanjiti broj zadataka koji ulaze u iteraciju. Na slici 12 [4, 130 str.] je prikazan ciklus jedne iteracije u XP-u:

Slika 12: Ciklus jedne iteracije u XP- u

3.4.2. Projektovan je softvera u XP-uProjektovanje softvera u XP-u ukljuuje korienje jednostavnog dizajna (3.4.2.1.), korienje metafore kao pojednostavljene slike softverskog sistema koji se razvija (3.4.2.2.), korienje CRC kartica za projektovanje softverskog sistema (3.4.2.3.) i vanost upotrebe prakse refaktorisanja kao metode koja obuhvata akcije poboljanja koda (3.4.2.4).

44

3.4.2.1. Jednostavan dizajn U XP-u postoji jasna definicija jednostavnosti: izvriti sve testove; nema duplog koda; kod koji je lako razumljiv; postoji najmanji mogui broj klasa i metoda.

U XP-u postoji akronim YAGNI (You Aint Gonna Need It), odnosno skraenica za ne radite ono to ne morate. Sutina je u tome da se ne radi neto samo zato to bi moda moglo da zatreba. Postoji ansa da e se utroiti vreme na reavanje problema koji ne postoji. Treba izbegavati sloeni dizajn i zbog moguih promena u budunosti. Najtea stvar koju programeri treba da prihvate kada prelaze na XP je rad sa ogranienjem.

3.4.2.2. Metafore sistema (System Metaphor) Metaf ora sistema predstavlja pojednostavljenu sliku softverskog sistema koji se razvija. Vano je da ta slika softverskog sistema bude to vie pojednostavljena kako bi je svi u timu razumeli. Prilikom kreiranja softverskog sistema koji se isporuuje kupcu, potrebno je da se definiu zajedniki termini koji se koriste u komunikaciji. Jo jedan razlog za upotrebu metafora je da one omoguavaju da kupac lake shvati tehnike podatke. Primer za metaforu moe biti kada tim razvija sistem za poslovanje menjanice. Kupac koristi rei kao to je zamena, opcije, bazna taka, rizik kamatne stope i slino. Tim treba svoj jezik da uskladi sa jezikom kupca, to moe da ide do nivoa pojedinanih komponenti ili modula.

3.4.2.3. CRC kartice (Class, Responsibilities, Collaborat ion cards) CRC kartice su kartice klasa, odgovornosti i saradnje. Koriste se za timsko projektovanje softverskog sistema.

45

Pojedinane CRC kartice se koriste za predstavljanje objekata. Klasa objekta moe biti predstavljena na vrhu kartice, odgovornosti mogu da se prikau na donjoj levoj strani kartice, a saradnja meu klasama desno od svake pojedinane odgovornosti. Sutina je u tome da se razume ta se eli postii definisanim objektima, kako da se implementiraju i menjaju. CRC sesija se odvija na taj nain to neko iz tima simulira sistem, govorei koji objekti alju poruke, a koji objekti te poruke primaju. Prolazei kroz sistem, rano se otkrivaju slabosti i problemi. Alternative dizajna mogu biti brzo istraene simulirajui predloeni dizajn.

3.4.2.4. Stalno refaktorisanje Refaktorisanje je proces menjanja softverskog sistema tako da se ne menja spoljno ponaanje koda, ve se poboljava unutranja struktura.[21, xii str.] To je disciplinovani nain preiavanja koda koji svodi na minimum anse da se pojave greke. Refaktorisanje ne predstavlja samo preiavanje koda, ve ono nudi tehniku preiavanja koda na efikasniji i kontrolisaniji nain.[21, 54 str.] Svrha refaktorisanja je da se softver uini razumljivijim i pogodnijim za modifikovanje. U softveru mogu da se naprave puno izmena koje se malo ili nimalo odraavaju na vidljivo ponaanje. Samo one izmene koje softver ine razumljivijim jesu refaktorisanja. Jako je bitno naglasiti dvojnu prirodu refaktorisanja. Kada se koristi refaktorisanje da bi se razvio sistem, vreme se deli na dve razliite aktivnosti: dodavanje funkcija i refaktorisanje. Kada se dodaju funkcije ne bi trebalo da se menja postojei kod, ve samo da se dodaju nove mogunosti. Kod refaktorisanja se ne dodaju nove funkcije ve se samo restruktuira kod. Tokom razvijanja softvera, esto se prelazi sa jednog na drugi zadatak. Dodavanjem nove funkcije moe se uvideti da bi to bilo lake ako bi struktura koda bila drugaija. Tada se prelazi na refaktorisanje. Kada se popravi struktura koda, ponovo se vri dodavanje nove funkcije. Refaktorisanje ima nekoliko namena [21, 55 str.]: Poprav lja dizajn softvera - Loe projektovan kod obino trai vie koda za obavljenje istih stvari, esto zato to kod bukvalno radi istu stvar na nekoliko mesta. Zato je vrlo bitno u 46

popravljanju dizajna eliminisanje ponovljenog koda. Umanjenje koliine koda nee sistem uiniti brim, jer ne utie bitno na zauzee resursa, ali se bitno odraava na modifikacije koda. to je vie koda, tee ga je ispravno modifikovati. Deava se da promenom dela koda na jednom mestu sistem i dalje ne radi ono to se oekuje jer nije promenjen deo koda i na drugom mestu gde radi istu stvar u malo drugaijem kontekstu. ini softver razumljivim Da bi i drugi korisnici mogli da razumeju i menjaju napisan kod, vano je da je razumljivo napisan. Refaktorisanje pomae u razumevanju nepoznatog koda, odnosno onoga ta on obavlja. Pomae u nalaenju greaka Razumevanje koda pomae i u uoavanju greaka.

Razjanjavanjem strukture programa dolazi se do take kada se lako uoavaju greke. Omoguava bre pisanje koda Definitivno je da refaktorisanje poboljava kvalitet koda. Poboljavanje dizajna, itljivosti, uklanjanje greaka, sve to vodi poboljanju kvaliteta koda. Dobar dizajn je od sutinskog znaaja za brz razvoj softvera. Glavni cilj dobrog dizajna (projektovanja) je da omogui brz razvoj. Bez dobrog dizajna moe se brzo napredovati do nekog trenutka, ali usled loeg dizajna ubrzo vreme poinje da se troi na nalaenje i ispravljanje greaka, umesto na dodavanje novih funkcija. Dobar dizajn je presudan za odravanje brzine pri razvijanju softvera. Refaktorisanje pomae da se softver bre razvija, ak i da pobolja dizajn. Najei problemi koji dovode do loeg koda su sledei, odnosno karakteristike loeg koda su sledee: Postojanje redundanse odn. Dupliciranog koda. Redudansa moe biti Eksplicitna to je sluaj kada u kodu na vie mesta postoji identina sekvenca naredbi ili Sakrivena kada u kodu postoji niz razliitih naredbi koje daju iste rezultate. U kodu u kome postoji sakrivena redudansa postoji vie delova koda obavljaju istu stvar, ali se one razlikuju zbog koricenja razlicitih kvantifikatora. Redundansa u kodu se moe smanjiti primenom refaktoringa Ekstrahovanje metode. Primena ovog refaktoringa smanjuje broj linija koda, unapreuje dizajn sistema pa je samim tim jednostavnije njegovo razumevanje. Kada su interfejsi dve 47

klase koje realizuju slinu funkcionalnost razliiti, klase treba refaktorisati tako da dele zajedniki interfejs. Uslovna logika ne predstavlja problem na poetku razvoja softvera. Manji broj uslovnih naredbi je jednostavno razumeti, ali poveanje broja uslova poveava sloenost softverskog reenja. Nepristojno otkrivanje javlja se u sluaju kada se kreiraju public metode ili public klase koje ne trebaju bit