U ovoj lekciji obrađivaćemo:
Sam proces konstrukcije i integracije ima veliku važnost u inženjerstvu. Važnost ispravne gradnje najbolje se vidi na primeru fudbalskog stadiona na Univerzitetu u Vašingtonu, koji se srušio tokom gradnje (slika 1).
Slika 1. Rušenje stadiona u Vašingtonu u toku konstrukcije
Stadion se srušio tokom gradnje jer nije bio dovoljno jak da izdrži sebe tokom gradnje. Bio bi jak po okončanju konstrukcije i završetka radova, ali je bio zidan na pogrešan način. Postojala je integrativna greška pri razvoju.
Nije samo važno da sistem bude jak kada se izgradi, sistem mora da bude jak tokom svakog koraka gradnje. Ako se softver razvija i integriše na pogrešan način, biće teže samo kodiranje, testiranje i otklanjanje grešaka.
Softverski sistem takođe može da se sruši prilikom gradnje, da broj grešaka postane nepremostiv, progres nevidiljiv, ili kompleksnost na krajnje porazanom nivou.
Pažljiva konstrukcija će doneti sledeće prednosti:
Do pre nekoliko godina, fazna integracija je bila uobičajeni model. Sastojala se od sledećih koraka:
Problem sa faznom integracijom je taj što se klase u sistemu spajaju zajedno po prvi put, što neminovno dovodi do problema. Pošto postoji veliki broj klasa koje nikada pre nisu radile zajedno, uzrok može biti loše urađeno testiranje klase, greška u interfejsu između dve klase, ili greška prouzrokovana interakcijom između dve klase.
Problem je neodređenost lokacije i mesta sa koga potiče problem. Svaka klasa može da bude uzrok. Dodatna teškoća je što se u takvim slučajevima uvek pojavljuje veći broj grešaka, a ne samo jedna, pa je otklanjanje još teže pošto i same greške međusobno reaguju. Zbog svega ovoga se fazna integracija naziva i big bang integration, kao što je prikazano na sledećoj slici.
Slika 2. Fazna integracija se naziva i big bang integracija
Fazna integracija ne može da počne ne početku projekta, nego tek kada se sve klase razviju i testiraju. Kada se klase konačno kombinuju i greške isplivaju na površinu kao rezultat toga, programeri počnu sa brzim ispravkama i zakrpama, umesto sa metodičkim načinom detekcije i korekcije. Za manje programe, fazna integracija može da bude dobro rešenje, ali u najvećem broju slučajeva postoji bolji pristup.
U inkrementalnoj integraciji piše se i testira program u malim delovima, a potom se kombinuju delovi jedan po jedan. Koraci integracije su:
Povremeno postoji potreba za dodavanjem jedinice veće od jedne klase. Ako je jedinica potpuno testirana i svaka od klasa prošla kroz mini integraciju, može se dodati cela komponenta, ali i dalje postoji prostor za izvođenje inkrementalne integracije. Kako se dodaju novi delovi, tako sistem raste i dobija na veličini i snazi, slično kao grudva snega koja se kotrlja niz brdo (slika 3).
Slika 3. Ilustracija inkrementalne integracije
Inkrementalni pristup nudi mnoge prednosti u odnosu na tradicionalni fazni pristup.
Lakše se otkrivaju greške - Kada se pojavi problem tokom inkrementalne integracije, očigledno je u pitanju nova klasa koja se dodaje (slika 4). U tom slučaju lakše se locira greška i smanjuje se rizik od pojave višestrukih grešaka.
Slika 4. Ilustracija lakšeg lociranja greške kod inkrementalnog pristupa
Rezultati rada su vidljivi ranije - Sa inkementalnom integracijom, programeri vide ranije rezultate svoga rada, što je značajan podstrek daljem angažovanju.
Poboljšano praćenje projekta - Sa učestalim integracijama, jasno su uočljivi elementi koji su prisutni i koji nisu. Menadžment ima bolju sliku ako vidi 50% sistemskih funkcionalnosti koje rade, nego da čuju da je 99% kodiranja završeno.
Poboljšan odnos sa kupcima - Učestale integracije imaju uticaja i na kupca, koji voli da vidi napredak i nove mogućnosti koje donose inkrementi.
Jedinice sistema se testiraju potpunije - Integracija počinje rano u samom razvoju, svaka klasa se integriše kako se razvija, za razliku od jednog velikog integrativnog procesa na kraju. Klase se razvijaju i testiraju u oba slučaja, ali se ovde klase porede i odnose sa celim sistemom, što daje bolje rezultate.
Reference:
1. Thimbleby, Harold. "Delaying Commitment." IEEE Software, May, 1988
2. Page-Jones, Meilir. "The Practical Guide to Structured Systems Design. Englewood Cliffs, NJ: Yourdon Press", 1988.
3. Card, David N. , Victor E. Church , and William W. Agresti . "An Empirical Study of Software Design Practices." IEEE Transactions on Software Engineering SE-12, 1986.