SOFTVERSKO INŽENJERSTVO ( SHARI LAWRENCE PFLEEGER

)
DIZAJNIRANJE SISTEMA 1 ŠTA JE TO DIZAJN Dizajn je kreativni proces pretvaranja problema u rešenje; opis rešenja se takodje zove dizajn. Specifikacija zahteva definiše problem. Zatim dolazi rešenje problema kao nešto što zadovoljava sve zahteve I specifikacije. U mnogim slučajevima broj rešenja je veliki. Priroda rešenja može da se menja I u toku opisa I u toku imlementacije. KONCEPTUALNI I TEHNIČKI DIZAJN Da bi se zahtevi pretočili u sistem koji funkcioniše, dizajneri moraju da zadovolje I klijente i graditelje sistema u razvojnom timu. Klijenti znaju šta sistem treba da radi a članovi projektnog tima moraju znati kako taj sistem treba da radi. Zbog toga je dizajn iterativni proces iz dva dela. Prvo se pravi konceptualni dizajn ili dizajn sistema koji opisuje klijentu tačno šta će sistem raditi. Pošto ga klijent odobri, konceptualni dizajn se prevodi u mnogo detaljniji dokument, tehnički dizajn koji omogućava graditeljima sistema da utvrde koji će hardver i softver biti potrebni za rešenje klijentovog problema. Proces je iterativan zato što dizajneri naizmenično rade na analizi zahteva, predlaganju mogućih rešenja, testiranju izvodljivosti svih oblika rešenja, prikazivanju mogućnosti klijentima i dokumentovanju dizajna za programere. Ponekad se dizajn prikazuje u jednom dokumentu, ali često postoje dva: konceptualni dizajn i tehnički dizajn

šta ? konceptualni dizajn

dizajneri sistema

kako ? tehnički dizajn

funkcije

oblik

kupci

grsditelji sistema

Tako imamo konceptualni dizajn, usresredjen na funkcije sistema I tehnički dizajn koji opisuje oblik sistema. Kako se sistem definiše svojim granicama, entitetima, atributima I odnosima (relacijama), konceptualni dizajn opisuje svaki od tih aspekata sistema u vidu odgovora na pitanja kao što su: Odakle će podaci stizati?

Šta će se u sistemu dogadjati sa podacima? Kako će sistem izgledati korisnicima? Šta će korisnici moći da biraju? Kakav je vremenski raspored dogadjaja? Kako će izgledati izveštaji I ekrani? Sistem se u konceptualnom dizajnu opisuje jezikom koji klijent razume, a ne računarskim žargonom I tehničkim terminima. Npr. klijentu možemo reći da će meni na ekranima omogućiti korisnicima pristup do funkcija sistema, mogu se nabrojati odgovori korisnika na dati meni i akcije koje oni prouzrokuju. Ali klijentu ne objašnjavamo kako se podaci čuvaju niti koja će vrsta sistema za upravljanje bazama odataka manipulisati podacima. Slično tome, u konceptualnom dizajnu klijentu možemo reći da se poruke mogu usmeravati sa jednog mesta na drugo, ali ne navodi se mrežni protokol koji to omogućava. Ponekad su klijenti profesionalci i mogu da razumu objedinjene i „šta“ i „kako“. To se dešava kada su klijenti projektanti softvera, a sistem je alatka koju će oni koristiti za razvoj ili održavanje. U takvim slučajevima se tehnički i koncepzualni dizajn može objediniti u u jedan sveobuhvatan dokument dizajna. Inače, korisno je da ti dokumenti budu odvojeni ali povezani, tako da se promene do kojih dodje u jednom reflektuju u drugom dokumentu.

„Korisnik će moći da pošalje poruku svakom drugom korisniku na bilo kom računaru u mreži.“

Topologija mreže Protokol Propisana brzina u bps

Konceptualni dizajn

Tehnički dizajn

Dobar konceptualni dizajn bi morao da ima sledeće karakteristike: da bude pisan jezikom klijenta da ne sadrži tehnički žargon da opisuje funkcije sistema da ne zavisi od implementacije da bude povezan sa dokumentima specifikacije zahteva Drugim rečima, konceptualni dizajn omogućava klijentu da shvati šta će sistem raditi tako što objašnjava spoljašnje karakteristike sistema.

a detaljni opisi opisuju šta će sistem uraditi sa svakim od unetih elemenata. Znači. Dizajner počinje sa opštim opisom funkcija koje treba implementirati i gradi detaljna objašnjenja o organizaciji svake komponente i njenim relacijama sa ostalim komponentama. Za sistem kažemo da je modularan kada svaku aktivnost sistema vrši samo jedna komponenta sa dobro definisanim ulazima I izlazima. a detaljni opisi navode koji će elementi podataka biti obuhvaćeni i kakve su njihove medjusobne veze.Postoje mnogi načini da se napravi dobar dizajn. Na detaljnijim nivoima se opisuju atributi objekata I akcije. Ponekad se izbor zasniva na sklonostima dizajnera. opis u tehničkom dizajnu je tehnička slika specifikacije sistema. mrežnu arhitekturu i sve ostalo čime se zahtevi prevode u rešenje klijentovog problema. Na najopštijem nivou opisuju se tipovi objekata.Znači. a dizajn objašnjava medjusobne veze objekata. svaka vrsta raščlanjavanja razdvaja dizajn na sastavne delove koje nazivamo modulima ili komponentama. opštih opisa funkcija ili kombinovanjem I pravljenjem hijerarhije informacija sa više detalja. dogadjaja. dizajn se može izvesti na osnovu sistemskih podataka. izlazom I karakteristikama. Objektno orijentisan dizajn: Ovaj dizajn definiše klase objekata I njihove medjusobne veze.Suprotno tome. tehnički dizajn opisuje konfiguraciju hardvera. softverske potrebe. u svakom metodu postoji neka vrsta raščlanjavanja: počinje se od okvirnog opisa ključnih elemenata sistema a zatim se detaljno prikazuje kako će se elementi i funkcije sistema medjusobno uklapati. Dizajn spolja ka unutra: Ovaj pristup “crne kutije” zasniva se na onome što korisnik unosi u sistem. Znači. ulaze u sistem i izlaze iz njega. najmanje što sadrži je: opis glavnih hardverskih komponenti i njihove funkcije hijerarhiju i funkcije softverskih komponenti strukture i tokove podataka RAŠČLANJAVANJE I MODULARNOST Projektovati sistem znači utvrditi skup komponenti i interfejsa medju komponentama kojima se zadovoljava konkretan skup zahteva.Opšti opis prikazuje globalnu strukturu podataka. Medjutim. Raščlanjavanje na osnovu podataka: Ovaj dizajn se zasniva na spoljašnjim strukturama podataka. . a detaljan opis govori kako dolazi do transformacije stanja. kao I dobijene podatke. Opšti opis sadrži spisak različitih stanja. a ponekad metod diktiraju zahtevana struktura sistema ili struktura podataka. Dizajn se može realizovati na jedan od načina: Modularno raščlanjavanje: Ova konstrukcija se zasniva na tome da se komponentama dodele funkcije. Raščlanjavanje na osnovu dogadjaja: Ovaj dizajn se zasniva na dogadjajima koje sistem mora da obradi i koristi informacije o tome kako dogadjaji menjaju stanje sistema. opšti opis navodi šta sve korisnik može da unese.korisničkog unosa. Bez obzira na pristup dizajnu. komunikacione interfejse. U svakom slučaju komponenta dizajna je entitet sa dobro definisanim ulazom. Tehnički dizajn.

ne postoje nepotrebni ulazi tj. Osim toga.Kažemo da je komponenta dobro definisana ako su svi njeni ulazi bitni za njenu funkciju. komponenta nije u stanju da obavi svoju funkciju u celosti. PROCES RAŠČLANJAVANJA Najviši nivo Prvi nivo Drugi nivo raščlanjavanja . a sve izlaze proizvodi jedna od njenih akcija. To znači da ako nedostaje jedan ulaz. svi ulazi se koriste za definisanje izlaza.

Podklasa moće da nasledjuje kako strukturu. Dva potpuno različita predstavljanja mogu biti podjednako ispravna I korisna. veličina. Za svaki objekat kažemo da je primerak (instanca) neke klase.Klasu možemo da predstavimo okvirom. za njih često kažemo da su zasnovane na objektima. Identitet postoji zbog činjenice da su podaci organizovani u diskretne. Združene apstrakcije formiraju hijerarhiju koja prikazuje medjusobne odnose različitih pogleda na sistem. koje zovemo objekti. recimo da postoji azijski. sletanje. enkapsulacija. jedinstveno prepoznatljive celine.Jednako smislena klasifikacija bi bila da se bicikl pridruži avionima I klasa nazove prevozna sredstva. FORMIRANJE HIJERARHIJE DIZEL Oktanski_broj Cena_po_litru Preostala_količina() . poreklo. počinjemo od sveobuhvatne definicije klase a zatim je delimo u specijalizovane podklase. broj putnika I operacije kao što su poletanje. brzina. Svaki primerak poseduje vlastite vrednosti atributa (tj. Primer1: grupa slonova može se smatrati klasom. kupa. Apstrakcije u OO sistemu pomažu da se predstave različiti aspekti sadržani u sistemu koji je predmet projektovanja. Da bismo izgradili hijerarhiju. kao karakteristika OO je tehnika pakovanja informacija na takav način da se sakriju informacije koje treba da budu sakrivene a vide one koje treba da budu vidjene. Treba imati u vidu da grupisanje u klase odražava shvatanja osobe ili tima koji grupiše objekte. Klasifikacija se OO koristi za grupisanje objekata sa zajedničkim svojstvima I ponašanjem. nasledjivanje. Objektna orijentisana reprezentacija se može prepoznati na osnovu svojih sedam karakteristika: identitet. Ovoj klasi možemo dodeliti operacije ili ponašanje: slon se kreće. 1 ŠTA JE OBJEKTNA ORIJENTACIJA Objektna orijentacija predstavlja pristup razvoju softvera u kojem se problem I njegovo rešenje organizuju kao skup diskretnih objekata pri čemu ta predstava obuhvata I strukturu podataka I ponašanje. remont. Svaki objekat u OO sistemu obično poseduje ime I obezbedjuje medjusobno razlikovanje objekata. Prema tome. tako i ponašanje i atribute nadredjene klase. polimorfizam I perzistencija (trajanje). broj_clanova_posade. velićina. klasa opisuje skup objekata sa zajedničkom strukturom I ponašanjem pri čemu nam vrednosti atributa omogućavaju da konkretne objekte medjusobno razlikujemo. klasifikacija. hrani.RAZMATRANJE OBJEKATA Veliki broj novih sistema koji se danas razvijaju delimično ili potpuno prihvataju objektno orijentisan razvoj. apstrakcija. Objekat ima svojstvena stanja I ponašanja. Enkapsuliranje. Ova grupa može se smatrati klasom. ali sa ostalim primercima iste klase deli imena atributa I ponašanja. Klasi slonova možemo dodeliti atribute: boja. U nekim reprezentacijama se koristi samo podskup od ovih karakteristika I mada se nazivaju objektno orijentisanim reprezentacijama. poseduje način da se u svakom trenutku opiše njegovo stanje). afrički . Primer 2: klasa avion poseduje atribute: boja. Važno je imati na umu da definicije I hijerarhije klasa imaju za cilj da predstave problem I njegovo rešenje.

ako želimo da cena goriva po litru za svaki dan bude trajno sačuvana. Polimorfizam omogućava dodavanje nove klase bez promene postojećeg koda. kao što je prirodni gas ili ugalj. ime.Ponašanje objekta se pokreće prijemom neke poruke ili ulaskom u neko stanje.Objektno orijentisan programski jezik projektovan je da automatski bira korektan metod za implementiranje operacije. parametre I naziv klase objekta. Sedmo svojstvo OO sistema je persistentnost (trajnost): sposobnost da ime. U sistemu sa polimorfizmom. svaki od njih ima atribut površina ali se površina razlišito izračunava kod trougla I kod pravougaonika. I ta osobina je poznata kao polimorfizam. odnosno izračunavanje površine zavisi od objekta na koji se primenjuje. stanje I ponašanje objekta se čuvaju prilikom njegove transformacije. Tako npr. . Primer: posmatramo klasu poligona. da bi mogli da uporedimo cene od prethodnih godina. u hijerarhije GORIVO lako moće da se doda novo gorivo. Npr. objekat će izabrati pravilnu metodu za računanje površine na osnovu parametara koji opisuju poligon. Npr.(ali ćemo morati bolje da razmislimo o metodama odnosno šta je sa oktanima ili cenom po litru – jedinica mere ? ). Konkretna implementacija operacije za odredjenu klasu naziva se metoda. Ponekad se isto ponašanje različito manifestuje kod različitih klasa ili potklasa. može da postoji jedan metod za izračunavanje površine trougla a drugi za izračunavanje površine kvadrata.BENZIN Oktanski_broj Cena_po_litru Preostala_količina() GORIVO Oktanski_broj Cena_po_litru Preostala_količina() Dizel_gorivo Benzin Ponašanje je akcija ili transformacija koju vrši objekat ili koja se nad njim vrši. stanje I ponašanje objekta opstanu u vremenu I prostoru. Drugim rečima. više različitih metoda implementira istu operaciju. U našem primeru sa površinom.

Sistem treba da signalizira ako stanje na zalihama padne ispod zadate kritične količine i formira porudžbenice za gorivo ili delove. 12.Računi se kupcima šalju u roku od tri dana od kupovine ili usluge. motocikla ili kamiona).Sistem treba da prati zaduženja I šalje opomene kupcima koji kasne sa plaćanjem.Sistem se primenjuje samo na stalne kupce. Sistem treba da prati račune na mesečnoj. adresom. matičnim brojem ili PIB-om. da popravi vozilo ili ga parkira na parkiralištu servisne stanice. U oba slučaja. kreditnom karticom ili čekom gradjana. a proizvode I usluge na dnevnoj osnovi. kupcu se ukida kredit. servis je potreban svakih 6 ili 12 meseci u zavisnosti od vrste vozila I vrste usluge. On vraća datum kada će se delovi isporučiti. Svaki kupac može od sistema da zahteva raspoloživi prostor za parkiranje. održavanje vozila I parkiranje. 11. iznos kupovine. 3.Sistem mora da rukuje podacima koji se koriste za spregu sa drugim sistemima. klujenti mogu da plate gotovinski.Šef stanice može na zhtev da dobije informacije o izdatim računima. Gorivo se u servisnoj stanici prodaje prema ceni po litru u skladu sa vrstom goriva: dizel i benzin u svim varijacijama. količinu u litrima I identifikacionu šifru stanice. Sistem kreditnih kartica koristi se za obradu transakcija sa kreditnim karticama kod plaćanja proizvoda I usluga. Sistem kreditnih kartica koristi identifikaciju kartice. 8. nedeljnoj ili mesečnoj tarifi. 5. 13. na zhtev šefa stanice da generiše izveštaj koji sadrži analizu cena I datih popusta. Srvisiranje vozila se naplaćuje u zavisnosti od cene delova I cene rada. Šef stanice može da pregleda periodični (mesečni) izveštaj u kojem se vidi koliko je mesta bilo raspoloživo a koliko zauzeto. Stalnim kupcem se smatra kupac identifikovan imenom. pri čemu popust nije isti za sve kupce.U normalnim okolnostima. koji je koristio usluge stanice bar jednom mesečno u zadnjih šest meseci. Klijent može da plaća automatski neposredno po završetku korišćenja usluge (kupovine goriva.Šef koristi sistem za kontrolu stanja zaliha. sistem kreditnih kartica vraća odgovor da li je transakcija odobrena ili odbijena.Sistem ne sme biti nefunkcionalan duže od 24 sata. Šef takodje jedini ima pravo da odobri popust odredjenom kupcu za odredjenu uslugu.Zahtevi servisne stanice: 1. 15.Sistem treba da automatski upozori vlasnike neaktivnih računa. Rezultate tog praćenja šef servisne stanice može da zahteva u formi izveštaja. 7. kojoj se može pristupiti na osnovu broja računa ili identifikacije kupca.Na sva plaćanja primenjuje se jedinstveni porez na promet od 20%. kao I iznos poreza po stavkama robe-usluge. Račun dospeva za plaćanje datuma koji je označen na računu. održavanja vozila ili parkiranja) ili na osnovu računa koji mu se dostavlja periodično (mesečno. Pošto prihvati ove informacije.Cene goriva. Ako se račun ne plati u roku od 90 dana od dana dospeća.servisiranja I parkiranja mogu da se menjaju.Kupci mogu da zakupe mesto za parkiranje na dnevnoj osnovi.Sistem održava evidenciju o računima. 4.Servisna stanica “NN” pruža korisnicima tri vrste usluga: prodaju goriva. 2. On vraća datum kada će gorivo biti isporučeno. Parkiranje se naplaćuje po dnevnoj.Sistem može. 6. 14. ali ih može unositi I menjati jedino šef servisne stanice. nedeljno). Šalje se poruka stalnim kupcima koji nisu u periodu od dva meseca ništa kupili u servisnoj stanici. Klijent može da sipa gorivo u rezervoar svog vozila (automobila.Sistem treba da povremeno šalje kupcima poruke kojima ih podseća da je potrebno servisiranje njihovih vozila.Šef stanice na zahtev dobija pregled evidencije zapisa o porezu. 10. . 9. Sistem za naručivanje delova prihvata šifru dela I broj komada.Sistem mora da evidentira porez I odgovarajuću strukturu poreza tj.Sistem za naručivanje goriva zahteva da narudžba sadrži vrstu goriva. iznos poreza koji je platio svaki kupac.

Cene goriva. Konkretno želimo da prikažemo povezanost objekata (npr. Ti dijagrami opisuju tipove objekata I njihove statičke relacije.Na sva plaćanja primenjuje se jedinstveni porez na promet od 20%. I na osnovu tih konkretnih elemenata formulišemo polazni skup klasa. Gorivo se u servisnoj stanici prodaje prema ceni po litru u skladu sa vrstom goriva: dizel i benzin u svim varijacijama. Parkiranje se naplaćuje po dnevnoj. nedeljno). U oba slučaja. razmotrimo deo prvog zahteva servisne stanice: .16. Tražimo: • • • • • • • • strukture spoljne sisteme uredjaje uloge radne postupke mesta organizacije stvari sa kojima projektovani sistem funkcioniše Na primer. pri čemu popust nije isti za sve kupce. pojedinačna ponašanja I ograničenja za svaku klasu ili objekat. kupac je povezan sa fakturom) I relacije tip-podtip (npr. dizel gorivo je podtip tipa gorivo). Proces projektovanja počinje iskazivanjem zahteva.Sistem mora da štiti informacije o kupcima od neovlašćenog pristupa. Želimo da dijagrami ilustruju atribute svakog objekta.servisiranja I parkiranja mogu da se menjaju. OO DIZAJN SISTEMA Koristimo UML (Unified Modeling Language) dijagrame klasa. klujenti mogu da plate gotovinski. održavanja vozila ili parkiranja) ili na osnovu računa koji mu se dostavlja periodično (mesečno. ali ih može unositi I menjati jedino šef servisne stanice. Klijent može da plaća automatski neposredno po završetku korišćenja usluge (kupovine goriva. Na osnovu ovako iskazanog zahteva moguće je izdvojiti nekoliko potencijalnih klasa: • • • • • • • • • • lični ček štampana faktura kreditna kartica kupac šef stanice kupljena stvar gorivo usluga popust porez . Srvisiranje vozila se naplaćuje u zavisnosti od cene delova I cene rada. nedeljnoj ili mesečnoj tarifi. kreditnom karticom ili čekom gradjana. Šef takodje jedini ima pravo da odobri popust odredjenom kupcu za odredjenu uslugu.Zatim pokušavamo da izdvojimo imenice.

• • • • parkiralište serviser gotovina cena Sledeća pitanja koja mogu da posluže kao uputstvo za pronalaženje kandidata za klase: • • • • Šta je to što treba da se na neki način obradi? Koje stavke poseduju više atributa? Kada postoji više objekata u jednoj klasi? Šta potiče od samih zahteva. Slično tome deveti: 9. peti zahtev glasi: 5. a nije izvedeno iz našeg tumačenja zahteva? Koji atributi I operacije se mogu uvek primeniti na neku klasu ili objekat? • Ova pitanja mogu da nam pomognu u grupisanju kandidata za klase I objekte: Prvo grupisanje atributa I klasa – korak 1 • • • • • Atributi lični ček faks cena gotovina kreditna kartica popusti Klase kupac serviser usluge parking gorivo faktura kupljene stvari šef stanice • • • • Zatim ispitujemo ostale zahteve da bismo videli kako oni proširuju postojeću tabelu atributa I klasa. Npr. Stalnim kupcem se smatra kupac identifikovan imenom. Prvo grupisanje atributa I klasa – korak 2 Atributi lični ček faks cena Klase kupac serviser usluge .Sistem treba da povremeno šalje kupcima poruke kojima ih podseća da je potrebno servisiranje njihovih vozila. adresom.Sistem se primenjuje samo na stalne kupce.U normalnim okolnostima. koji je koristio usluge stanice bar jednom mesečno u zadnjih šest meseci. servis je potreban svakih 6 ili 12 meseci u zavisnosti od vrste vozila I vrste usluge. matičnim brojem ili PIB-om.

Iz specifikacije zahteva izdvajamo glagole.gotovina kreditna kartica popusti datum rodjenja ime adresa matični broj parking gorivo faktura kupljene stvari šef stanice povremene poruke Za kompletan skup zahteva proširujemo tabelu I dobijamo: Prvo grupisanje atributa I klasa – korak 3 Atributi lični ček faks cena gotovina kreditna kartica popusti datum rodjenja ime adresa matični broj Klase kupac serviser usluge parking gorivo faktura kupljene stvari šef stanice povremene poruke pismo upozorenja delovi Računi Inventar Sistem kreditnih kartica Sistem za naručivanje delova Sistem za naručivanje goriva Zatim razmatramo ponašanja koja moraju da se opišu u našem dizajnu. Ponovo tražimo konkretne elemente koji opisuju ponašanja: zapovedne glagole pasivne glagole akcije stvari ili podsetnike .

Kada se jedan ram nalazi iznad drugog. Usluge procenat_popusta: broj cena() Nadklasa Nasledjivanje (jeste) Parkiranje cena : broj = 35 . fakturisanje kupcu je ponašanje. srednja trećina informacije o atributima. a povezani su strelicom. a donja opis operacija. U cilju lakšeg rukovanja objektima. tada gornji predstavlja nadklasu donjeg. klasama I ponašanjima koristićemo koristićemo UML dijagrama za opis njihovih odnosa. a omogućava da donji ram iz gornjeg nasledi atribute I ponašanja.uloge radne postupke usluge koje pruža neka organizacija Ponašanja će postati aktivnosti ili obaveza koje preuzima klasa ili objekt ili aktivnosti koje se vrše nad klasom ili objektom. a faktura utiče na kupca. Faktura Datum_izdavanja:datum Datu_plaćanja:datum cena() porez() kupac() kupovine() dodavanje_na_fakturu(kupac. Svaki atribut se opisuje imenom. Slično se svaka operacija opisuje imenom. listom argumenata I tipom povratne vrednosti. Npr.iznos. tipom I početnom vrednošću. To ponašanje izvršava deo sistema servisne stanice.datum) UML ramovi se postavljaju na dijagram tako da se uoče veze izmedju klasa na koje se odnose. Gornja trećina rama sadrći ime klase. Ta veza nasledjivanja ponekad se naziva vezom jeste (je) . Primer UML rama koji se koristi za ilustrovanje delova klase.

Npr. agregacija I kompozicija. nadklasa generalizuje podklasu. klasa gorivo predstavlja generalizaciju klase dizel_gorivo. a brojevi na kraju linije opisuju kardinalitet svakog člana relacije. I ovde se može na krajevima linije definisati kardinalitet. Dve klase su u asocijaciji ako se javljaju zajedno I ako ta veza mora da se održi tokom odredjenog vremena. Asocijacija je prikazana ravnom linijom.Podklasa Relacije izmedju klasa obično pripadaju jednom od četiri tipa. . kupac poseduje porudžbinu. a to su generalizacija. Prazan romb ukazuje na agregaciju koja nije relacija nasledjivanja. Primer agregacije je kada je jedna klasa deo druge klase. ali klasa kupac nije podklasa klase porudžbina. romb označava veći entitet koji sadrži povezanu klasu kao njegov deo. Na sl. Relacija je_deo označavamo linijom kojase završava popunjenim rombom. jedna porudžbenica može sadržati više stavki. U primeru. Kada imamo relaciju nasledjivanja. asocijacija.

.Primenom ove notacije možemo nacrtati ramove klasa početnog modela za servisnu stanicu.

održavate usklađenost elemenata na nivou dizajna sa elementima na nivou koda. moramo napisati programe koji implementiraju dizajn. Pisac koda ne mora biti deo tima za testiranje I . Sledeće aktivnosti su implementiranje tog rešenja u obliku softvera.9 ENDIF Standardi za druge: Kada ispišete svoj kod. koeficijent je 1. jednostavno se sprovode I time se značajno smanjuje mogućnost pojave greške. jer pojašnjava koji delovi programa izvršavaju koje funkcije. Možda će druga grupa integrisati vaš softver sa drugim programima da bi izgradili I testirali podsisteme ili ceo sistem. da bi kod I prateća dokumentacija bili jasni svima ko ih čita.To za posledicu ima lakše implementiranje promene u kodu koje su posledica promena u dizajnu. Standardi za vas: Standardi I procedure mogu da vam pomognu da sredite misli I izbegnete greške. Slično tome. Mnoge kompanije zahtevaju da kod bude usklađen sa standardima vezanim za stil. format I sadržaj. Neke procedure odnose se na način dokumentovanja koda da bi on bio jasan I pregledan. Standardi I procedure takođe pomažu pri prevođenju dizajna u kod. Takva dokumentacija vam omogućava da prekinete rad I vratite mu se. // upit za godine staža IF godine_staza < 20 then // kod za godina staza manje od 20. Zato morate upoznati standarde I procedure koje važe u vašoj organizaciji pre nego što počnete da pišete kod. Struktuisanjem koda prema standardima. koeficijent je 1. Jasno je da postoji više načina da se programira isti dizajn. može se ukazati potreba za promenom ili zbog greške ili zbog promene neke funkcije sistema. Standardizovana dokumentacija takođe pomaže pri pronalaženju grešaka I unošenju izmena. a da pri tom ne izgubite nit. tj. Samo pisanje koda najčešće podrazumeva učešće većeg broja ljudi. Zbog toga je veoma važno da I drugi mogu da shvate šta ste I zašto napisali I kako se to uklapa u njihov deo posla.PISANJE PROGRAMA Zaključno sa dizajnom. za testiranje. Kod mora biti razumljiv. promene koda koje su posledica promena u specifikaciji hardvera ili interfejsa. Čak I kada je sistem u eksploataciji.4 ELSE // kod za godina staza vece ili jednako 20. kompletnom zamenom ili upotrebom koda u sklopu druge aplikacije. 1 STANDARDI I PROCEDURE PROGRAMIRANJA Osim pisanja koda. često smo u situaciji da naknadno analiziramo svoj ili čitamo tuđi kod zbog potrebe za promenom. postoje mnogi jezici I alati koji se mogu koristiti za to. nama kada mu se vratimo prilikom testiranja a I drugima u toku evolucije sistema. postoji verovatnoća da će ga drugi koristiti na različite načine npr. shvatili smo problem kupaca I korisnika I formulisali opšte rešenje tog problema.

iznos. Ove izmene zahtevaju prvo izmene u dizajnu na svim nivoima a zatim i na kodu. To bi moglo da izgleda ovako: *************************************************** * KOMPONENTA ZA TRAZENJE NEPLACENIH RACUNA * IME KOMPONENTE: NEPL_RAC *Programer : Jovan Jovic *Verzija: 1. ako su imena podataka jasna a veze dobro definisane.održavanje I zato je potrebno da organizuje. programer koji radi na održavanju lakše će naći komponentu koju treba da promeni. pretpostavimo da svaki program po standardu na početku ima opis funkcije programa I njegovim vezama sa ostalim programima. održavanje i upravljanje konfiguracijom nije moguće bez veza koje se ovim standardima ustanovljavaju. valuta. formatira I dokumentuje svoj kod tako da drugi mogu lako da razumu šta on radi I kako to realizuje . funkcije. Čitanjem ovakvih blokova. Npr. . odozgo nadole.Karakteristike dizajna treba da se prenesu i na kod da bi algoritmi. algoritme i strukture podataka Kontrolne strukture: Važno je da struktura programa odražava kontrolne strukture definisane u sklopu dizajna. Osnovna namena sistema tokom čitavog životnog ciklusa ostaje ista. interfejsi i strukture podataka mogli lako da se prate iz dizajna u kod i obrnuto. ali su neka unapređenja i promene vrlo verovatne. valuta placanja *Trazeni racuni su neplaceni sa valutom manjom ili jednakom ulaznom datumu *Ako nema trazenih racuna. ovaj blok daje dovoljno elemenata za procenu verovatnoće da je razmatrana komponenta direktni krivac ili možda saučesnik.2 ( 12. 2 SMERNICE ZA PROGRAMIRANJE Bez obzira na programski jezik. Uparivanje dizajna sa implementacijom: Celokupan proces dizajna ništa ne vredi ako se modularnost prisutna u dizajnu ne prenese i na kod. svaka programska komponenta uključuje najmanje tri aspekta: Kontrolne strukture.2011) *Ulazni parametri su sifra poslovnog partnera.09. Nekome ko traži uzrok otkaza. Kada se pronađe komponenta. indikator je 0. I daje pregled načina rešavanja.neplaceni_iznos ***************************************************** Ovaj blok komentara informiše šitaoca šta radi kod koji sledi. Nekome ko traži komponentu za ponovno korišćenje ovaj blok pruža dovoljno informacija za donošenje odluke da li je to ono što traži. programer koji radi na održavanju može da bude siguran da zahtevana promena neće proizvesti neočekivane posledice po druge delove koda. Zbog toga je usklađenost između dizajna i koda važna i testiranje. Primer kako promena strukture povećava razumljivost koda: benef =minimum. datum.Standardi zahtevaju da se kod piše tako da komponenta može lako da se pročita. a ako ima indikator je 1 I racuni *su ispisani u tabelu: godina I broj racuna.

da zahtevana akcija bude neposredno nakon odluke koja je uslovljava.5 + bonus. Što je komponenta koda modularnija. Ako je program sastavljen od modularnih blokova. postoji visok stepen slobode prilikom konvertovanja algoritma u kod. Imena parametara i komponenti treba da budu asocijativna. sistem postaje razumljiviji za čitanje i održavanje. gde god je to moguće. goto C. Lakše je pratiti strukturu: if (godine < 55) benef=minimum else if (godine < 65) benef = minimum*1. Naravno da nije uvek moguće da tok ide strogo odozgo nadole. Međutim.5. zavisno od ograničenja implementacionog programa i hardvera. potprograme. benef = benef * 1. Tako će komponenta moći da se koristi za bilo koji string i bilo koji znak. lakše će se održavati i ponovo upotrebiti u drugim aplikacijama. ubrzanje koda može da sadrži prikrivene troškove: trošak pisanja bržeg koda koji je možda složeniji i zato zahteva više vremena troškove vremena za testiranje koda čija složenost zahteva više primera za testiranje ili više test podataka .metode. treba izbegavati da on bude specijalizovan više nego što je potrebno (opštost je vrlina). nasleđivanje kao sredstvo za skrivanje detalja uz povećanje stepena razumljivosti. Ali je korisno. Kada se piše kod. Algoritmi: Dizajn programa često definiše klasu algoritama koju treba upotrebiti prilikom kodiranja komponente.if (godine < 75) goto A. benef=maximum. kako bi napravili kod koji će se izvršavati najvećom mogućom brzinom. Programsku komponentu možemo modularno posmatrati. A: if (godine < 65) goto B. S druge starne ne treba dozvoliti da opštost utiče na performanse sistema ili na razumevanje. Čitaoc mora iz koda da prepozna šta su ulazni parametri a šta je krajnji rezultat odnosno izlaz.Izmene se ograničavaju na konkretan modul. a ne da zbunjuju čitaoca. Modularnost koda je karakteristika dobrog programa. Ovu komponentu treba programirati tako da ulazne vrednosti budu dužina niza i znak koji se traži. Primer: komponenta u nizu od sedamdeset znakova traži na kojoj je poziciji tačka. a zatim koristiti makroe.5 + bonus else benef = maximum. B: if (godine < 55) goto C. Ali. C: next read. benef = benef *1. Performansa ili efikasnost implementacije je oblast gde imate veliko pravo odlučivanja. goto C. procedure.5 else if (godine < 75) benef = minimum*1.

12 . struktuiranje podataka može da uprosti izračunavanja u programu. Postoji nekoliko tehnika u kojima se organizacija programa prilagođava strukturi podataka.Tako npr. goto KRAJ. Pitanje vremena izvršavanja treba razmatrati zajedno sa kvalitetom dizajna. if (iznos = 0) goto KRAJ. If (iznos >20000) porez = porez +1200 else porez =porez+ ( iznos-10000)*0. If (iznos >30000) porez = porez +1500 else porez =porez+ ( iznos-20000)*0. standardima i zahtevima kupca.troškove vremena da korisnici shvate kod troškovi vremena za promenu koda ako se pojavi potreba Prema tome. Primer:Treba napraviti komponentu za izračunavanje poreza i to: Za prvih 10000 dinara dohotka porez iznosi 10% Za sledećih 10000 dinara iznad 10000 porez iznosi 12% Za sledećih 10000 dinara iznad 20000 porez iznosi 15% Za sledećih 10000 dinara iznad 30000 porez iznosi 18% Za svaki dohodak preko 40000 dinara porez iznosi 20% Komponenta za koju se piše kod kao ulaz ima oporezivi iznos i izgleda ovako: porez =0. Strukture podataka: Kada se pišu programi. If (iznos >40000) porez = porez +18000 +( iznos-40000)*0. If (iznos >10000) porez = porez + 1000 else porez =porez+iznos*0.15 .Ponekad su u dizajnu programa definisane strukture podataka koje treba koristiti prilikom implementacije programa. vreme izvršavanja predstavlja samo mali deo u ukupnim troškovima.2 else . podatke bi trebalo formirati I čuvati na takav način da se njima jednostavno upravlja i manipuliše. goto KRAJ. Očuvanje jednostavnosti programa. goto KRAJ. posebno je važno ne žrtvovati jasnoću i ispravnost zbog brzine.10.

KRAJ. ulaz nije dobar else razlika je datum2 – datum1 izlaz je razlika Revidirati I ponovo pisati. ponekad je teško testirati delove programa koji obavljaju ulazne i izlazne funkcije. Prednost lokalizacije je što u specijalizovanu komponentu mogu da se uključe neke funkcije koje treba obaviti nad ulaznim podacima.18 . 1000 2200 3700 5500 0. Ako se čini da je tok kontrole zamršen ili da je . načina predstavljanja podataka I sl. porez=osnov[nivo] + (iznos-raspon[nivo])*procenat[nivo].porez =porez+ ( iznos-30000)*0. Prema tome. poželjno je da u komponentama ti delovi budu odvojeni od ostatka koda. Dizajn nije strogo vezan za programski jezik I ostavlja slobodu izbora jezičkih sklopopva. Međutim. korisno je da se od dizajna ka kodu ide u fazama.ne krpiti. Uključivanje pseudokoda.15 0. načina njihove upotrebe. Lokalizovanje ulaza i izlaza.20 Opšte smernice Da bi se očuvao kvalitet dizajna.Kako dizajn postavlja konture onoga šta programska komponenta treba da uradi.12 0. Za prilagođavanje dizajna izabranom programskom jeziku može se upotrebiti pseudokod. Primer: Komponenta daje razliku od datuma1 do datuma 2 ucitaj datum1. ako definišemo tabelu tj.datum2 if datum1 veci od datum2 poruka: datumi su neispravni. Kada se piše kod. a ne da se dizajn odmah prevodi u kod.18 0. najčešće se prvo napravi gruba skica. zatim se revidira I ponovo piše dok se ne postigne dobar rezultat. To su delovi koji će se verovatno menjati promenom hardvera i softvera.10 10000 20000 30000 40000 for i = 1 to 5 if (iznos > raspon[i] nivo=nivo+1. tako da se ostale komponente rasterećuju i izbegavaju ponavljanja. struktuiramo podatke gde za svaki interval imamo osnovni iznos I porez: Raspon Porez Procenat 0. korisno je upoznati nekoliko opštih strategija. Zbog te zavisnosti. Delovi programa koji učitavaju ulaz ili formiraju izlaz veoma su specijalizovani i moraju da odražavaju karakteristike osnovnog hardvera i softvera.

neka koriste parametre I pretpostavljaju uslove slične onima u kojima ih sistem poziva razdvojiti delove koji su podložni promenama. ili je teško ukloniti bezuslovna grananja. kakvi su algoritmi I razlaganja. pogledati kakva je struktura podataka. Potrošač. kada koristimo komponente koje su prvobitno razvijene za druge projekte. Postoje dve vrste višekratne upotrebljivosti: na strani proizvođača.treba da proveri četiri ključne karakteristike: Da li komponenta izvršava funkciju ili obezbeđuje podatke koji su potrebni Ako je potrebna nekaizmena. pogledati ga ponovo I videti da li je problem posledica dizajna ili prevođenja u kod. pre nego što upotrebi postojeću komponentu. od onih koji će verovatno ostati nepromenjeni neka interfejs komponente bude uopšten I dobro definisan uključiti informacije o pronađenim I ispravljenim greškama koristiti jasne standarde za imenovanje dokumentovati strukture podataka I algoritme 3 DOKUMENTACIJA Programskom dokumentacijom smatra se skup opisa u pisanoj formi koji obješnjavaju šta programi rade I kako to postižu. I na strani potrošača. Unutrašnja dokumentacija Unutrašnja dokumentacija sadrži informacije namenjene nekome ko će čitati izvorni kod programa. Unutrašnja dokumentacija podrazumeva opise koji se direktno upisuju u kod a sva ostala dokumentacija je spoljašnja dokumentacija. Zaglavlje bloka komentara daje kratak pregled za identifikaciju programa i opis njegovih struktura podataka. Višekratna upotrebljivost. mora se proceniti koliko koda treba napisati da bi sistem mogao da sarađuje sa višekratno upotrebljivim komponentama. treba se vratiti na dizajn. Ovaj deo sadrži sledeće informacije: 1 naziv komponente: 2 autor komponente 3 mesto komponente u celokupnom dizajnu sistema 4 kada je komponenta napisana odnosno revidirana . Proizvođači višekratno upotrebljivih komponenti treba da vode računa o nekoliko stvari: neka komponente budu opšte.postupak odlučivanja teško razumeti. kada pravimo komponente koje su planirane za upotrebu u kasnijim aplikacijama. da li je manje potrebno za promenu ili izgradnju nove komponente Da li je komponenta dobro dokumentovana tako da se može potpuno razumeti bez potrebe da se verifikuje celokupna implementacija Postoji li potpuna evidencija o testiranju I revizijama komponente tako da možemo biti sigurni da u njoj nema grešaka Takođe.

Ako su naredbe jasno formatirane. Kako je komponenta deo većeg sistema. Npr. ZNAK je slovo ili cifra koja se traži. potrebne su detaljnije informacije. Tokom životnog ciklusa. tip i svrhu svake veće strukture podataka i promenljive kratak opis logičkog toka. imena promenljivih i imena podataka opisana i asocijativna. ZNAK.com ULAZ: call TRAZI(DUZINA.2012 autor Ranko Savin. pozicijom znaka u nizu napuniti promenljivu DUZINA. 063 334-554 IvIlic@gmail. broj telefona. U programskoj dokumentaciji je potrebno da postoji evidencija izvršenih promena kao i imena autora promena. proizvoljne dužine. bilo zbog proširenja zahteva.04. zamenu znaka ili brisanje znaka. poboljšan algoritam traženja SVRHA: modul za pretraživanje bilo kakvog teksta. STRUKTURE PODATAKA: DUZINA integer. ZNAK char. Trebalo bi navesti ime. Zaglavlje bi trebalo da ukaže na to kako se komponenta poziva. Komentari treba da pruže dodatne informacije a ne da opisuju ono što je očigledno. ako se pronadje traženi znak. ako su oznake. brojac_redova = brojac redova +1 Mesecna_plata = (cena_sata*sati)*radni_staz Dokumentovanje podataka. TEKST string ALGORITAM: Čitati karakter niz znak po znak. TEKST je niz znakova koji se pretražuje. broj dodatnih komentara će biti mali. Iz grupe je pomoćnih programa za tekst projektovanih za dodavanje znaka. PROGRAM TRAZI_ZNAK: Program koji u nizu znakova traži zadati AUTOR: Ivan Ilić.2011. bilo zbog ispravljanja grešaka. Unutrašnja dokumentacija bi trebala da sadrži opise strukture podataka i kako se podaci koristi. VERZIJA 1: Napisana 12. Dobro je kada ime promenljive objašnjava aktivnost: Npr. Ostali komentari u programu. e-poštu zbog eventualne komunikacije sa drugim šlanovima tima. komponente se mogu revidirati. Dodatni komentari pomažu čitaocu koda da shvati kako su u kodu implementirane namere koje su opisane u zaglavlju.11. . Treba navesti autora. algoritme i tokove kontrole Ime komponente mora da bude uočljivo u dokumentaciji. inače promenljiva DUZINA dobija vrednost 0. dokumentacija bi trebala da ukaže na mesto komponente u hijerarhiji komponenti.g REVIZIJA 1: 12. Za objašnjenje kako komponenta izvršava svoj cilj. algoritama i obrade grešaka očekovani ulaz i mogući izlaz pomoćna sredstva za testiranje i kako ih treba koristiti očekivana proširivanja i ili revizije Standardi firme obično definišu redosled i sadržaj zaglavlja bloka komentara. TEKST) gde je DUZINA pozicija traženog znaka u nizu.5 zašto ta komponenta postoji 6 kako komponenta koristi svoju strukturu podataka.

treba obrazložiti izbor algoritama. Opis podataka. Opis algoritama. Opis problema nije ponavljanje dokumentacije zahteva. . Pošto je razjašnjeno zašto komponenta postoji. Opisuju se razlozi zbog kojih je izabrano konkretno rešenje. Spoljna dokumentacija komponenti čini deo sveobuhvatne dokumentacije sistema.Spoljna dokumentacija Spoljna dokumentacija je namenjena svum učesnicima. a ne neka druga koja su bili u opciji. Zatim objasniti svaki algoritam koji se koristi u komponenti. Delovi dokumentacije komponenti su: Opis problema. već opšti opis okvira sa objašnjenjem kada se komponenta poziva i zašto je ona potrebna. U spoljnoj dolumentaciji mora se videti tok podataka na nivou komponente. U prvom odeljku dokumentacije koda treba objasniti problem koji komponenta rašava. omogućava da se stvari opširnije objasne nego što je to moguće komentarima u programu. uključujući formule. ograničenja i posebne uslove.

ili njegova logika. Uobišajene algoritamske greške mogu biti: grananje pre vremena prekasno grananje ispitivanje pogrešnog uslova početnoj vrednosti njije dodeljena vrednost podešavanje uslova petlje propust pri ispitivanju konkretnog uslova(deljenje nulom) . Mnogi softverski sistemi obradjuju veliki broj stanja I složenih formula. Uzroci nastanka otkaza mogu biti: Specifikacija pogrešna ili u njoj nedostaje neki zahtev U specifikaciji postoji zahtev koji ne može da se implementira sa propisanim hardverom ili softverom Postoji greška u dizajnu sistema Postoji greška u programskom kodu Mnogi programeri smatraju da je svrha testiranja dokaz da programi ispravno rade. Osim toga za implementaciju zamisli kupca koristimo različite alate a I kupac često nije siguran šta mu treba. Npr. testiramo programe da bismo dokazali postojanje greške. Te greške se ponekad lako otkrivaju čitanjem programa ili pravljenjem ulaznih podataka iz svih razlišitih klasa podataka za koje se očekuje da se mogu pojaviti pri normalnom radu programa. Otkazom softvera se smatra situacija kada softver ne radi ono što je opisano u zahtevima. aktivnosti I algoritama. VRSTE GREŠAKA Algoritamska greška se javlja kada algoritam komponente. Prepoznavanje grešaka je postupak utvrdjivanja zbog koje greške ili grešaka je došlo do otkaza a ispravljanje ili otklanjanje grešaka je postupak unošenja izmena u sistem sa culjem da greške nestanu. Složenost potiče od velišine projekta I broja učesnika. 1 GREŠKE I SOFTVERSKI OTKAZI Teško je ostvariti da svaki program koji se proizvede pravilno radi kad god se pokrene.TESTIRANJE PROGRAMA Srž testiranja je otkrivanje grešaka I obezbedjenje da se kupcu isporuči kvalitetan softver. Za to postoji više razloga. ne proizvode ispravan rezultat za dati ulaz. podatak može da vidi korisnik koji nije ovlašćen za to. Ali svrha je upravo suprotno od toga. zato što nešto nije u redu sa postupkom obrade. Prisustvo grešaka ne zavisi samo od softvera već I od očekivanja kupaca I korisnika.

Takvim testiranjem. Funkcionalnim testiranjem se proverava da li integralni sistem zaista izvršava funkcije opisane u specifikaciji zahteva. koje se naziva testiranje modula ili jedinično testiranje. proverava se da li pojedinačne komponente ispravno funkcionišu sa svim očekivanim tipovima ulaza. Greške propusnosti ili performansi nastaju kada sistem ne omogućava performanse I brzinu specifikovanu u zahtevu. Prvo se zasebno testira svaka programska komponenta. u skladu sa dizajnom komponente. I da posmatra izlazne rezultate. Greške preopterećenja nastaju kada se broj korisnika u sistemu povećava preko navedenog kapaciteta. Kao rezultat dobija se sistem koji funkcioniše. a kod koji vrši koordinaciju tih procesa nije odgovarajući. neophodno je obaviti više vrsta testiranja. Greške kapaciteta nastaju kada vrednost premašuje kapacitet polja u strukturi podataka.Nastoji se da se jedinično testiranje vrši u kontrolisanom okruženju. Greške oporavka mogu da nastanu kada nastupi greška a sistem ne reaguje kako je predvidjeno zahtevom. grupe komponenti. logoku I granične uslove za ulazne I izlazne podatke. 3 JEDINIČNO TESTIRANJE . Neki testovi zavise od onoga što se testira: komponente.da vrati datoteke na stanje pre otkaza. Greška dokumentacije nastaje kada dokumentacija ne odgovara onome što program zaista radi. testira se sistem da bi se proverilo ima li on željenu funkcionalnost. Pošto se utvrdi da se izmedju komponenti informacije prenose u skladu sa dizajnom. Greške vremenskog rasporeda ili greške koordinacije nastaju kada se više procesa odvija istovremeno ili po strogo uredjenom redosledu. zahtevima?. očekivanjima kupaca? ORGANIZACIJA TESTIRANJA Kada se razvija veliki sistem. sledeći korak je proveravanje da li su interfejsi izmedju komponenti pravilno definisani I realizovani. Drugi testovi zavise od onoga šta želimo da saznamo: da li sistem radi u skladu sa projektom? . testiranje obično zahteva više faza. Kada se završi jedinično testiranje skupa komponenti. Intgraciono testiranje je postupak proveravanja da li sistemske komponente saradjuju kao što je opisano u specifikacijama dizajna sistema I programa. nezavisno od ostalih delova sistema.operacije sa promenljivim različitog tipa sintaksna greška Greške izračunavanja I greške preciznosti nastupaju kada se formula pogrešno implementira ili kada ne izračunava rezultat sa zahtevanom preciznošću. Kada se kombinuju izračunavanja u kojima učestvuju celobrojne vrednosti I vrednosti sa pokretnim zarezom može doći do neočekivanih rezultata. osim toga. tako da tim za testiranje može komponenti koja se testira da predaje unapred definisan skup podataka. podsistemi ili ceo sistem. npr. Hardverske greške I greške sistemskog softvera nastaju kada isporučeni hardver ili sistemski softver ne funkcionišu u skladu sa dokumentovanim operativnim uslovima I procedurama 2 PITANJA TESTIRANJE Pre nego što se kupcu preda sistem za koji se veruje da ispravno funkcioniše. tim za testiranje proverava unutrašnju strukturu podataka.

F i G. program specijalne namene koji simulira aktivnost komponente koja nije testirana. Zatim se prevodi kod I otklanjaju preostale greške sintakse. Kada se uverimo da te tri komponente ispravno rade prelazimo na sledeći viši nivo. Na kraju se prave slučajevi za testiranje da li se ulaz pravilno konvertuje u željeni izlaz. kako C ne poziva ni jednu komponentu. Kada se koristi metod testiranje odozdo nagore. 4 INTEGRACIONO TESTIRANJE Pošto je završeno jedinično testiranje. One se kombinuju sa komponentama koje pozivaju a one su već testirane. Zajedno testiramo B.E. Sledeći koraci u procesu testiranja treba da budu isplanirani: . pišemo poseban kod kao pomoć za integraciju.F .G. Tokom testiranja moguće je ići od vrha prema dole. moguće je ići odozdo nagore ili kombinovati oba pristupa. testiramo D. Taj postupak se ponavlja sve dok testiranjem ne budu obuhvaćene sve komponente sistema. U našem primeru potrebni su nam rukovaoci komponenti za E. Na najvišem nivou obično postoji jedna kontrolna komponenta I ona se izolovano testira. Planiranje testa pomaže da se testiranje odvija tako da daje dobre rezultate. Zatim se testiraju komponente koje pozivaju prethodno testirane komponente. N kraju testiramo sve komponente zajedno. podacima I sintaksi. Primer: A B C D E F G Testiranje: Prvo se testirau komponente E. Pošto komponente koje pozivaju module najnižeg nivoa nisu spremne. testiramo je izolovano. Rukovalac se lako kodira pošto retko zahteva složenu obradu. slično tome. kod objektno orijentisanog dizajna ili kada sistem integriše veći broj nezavisnih ponovi iskoristivih komponenti. Rukovalac komponentom je rutina koja poziva odredjenu komponentu I predaje joj ulaz. Postupak se ponavlja dok se ne uključe sve komponente.F i G. Komponenta koja se testira možda poziva rutinu koja još nije testirana I zato pišemo lažnu rutinu . prvo se jedinično testira svaka komponenta na najnižem nivou hijerarhije sistema. prelazi se na integraciono testiranje. Ovaj metod je koristan kada većina komponenti na najnižem nivou predstavlja pomoćne rutine opšte namene koje se pozivaju iz drugih komponenti. Sistem se posmatra kao hijerarhija komponenti.Prvo se čita programski kod I traže greške u algoritmu. Može se uporediti kod sa specifikacijom I dizajnom da se vidi da li su uzeti svi relevantni slučajevi. Integracija odozgo nadole. Svaki korak u procesu testiranja mora da se planira. 5 PLANIRANJE TESTA Testiranje komponenti I njihovo integrisanje u sistem nije jednostavno. Zatim se komponente koje ona poziva kombinuju I testiraju kao veća celina. gde svaka komponenta pripada nekom sloju dizajna.

izvršavanje testa počinje pregledom slučajeva u cilju provere njihove ispravnosti.1 utvrdjivanje ciljeva testiranja 2 dizajn slučajeva 3 pisanje slučajeva 4 testiranje slučajeva 5 izvršavanje testova 6 ocenjivanje rezultata testiranja Cilj testiranja upićuje na vrste slučajeva za testiranje koje treba izgraditi. ostalo testiranje postaje beskorisno. Zato. Ako slušajevi nisu reprezentativni I ne izvršavaju u potpunosti funkcije koje dokazuju ispravnost I validnost sistema. postizanja željenog stepena pokrivanja I demonstracije željene funkcionalnosti. . izvodljivosti.

angažuje se ceo razvojni tim. Testiranje performansi obično uključuje I hardver I softver. testiranje performansi polazi od nefunkcionalnih zahteva. TESTIRANJE PERFORMANSE Pošto se utvrdi da sistem izvršava funkcije navedene u zahtevima. Proces testiranja sistema se sastoji od nekoliko koraka: Funkcionalno testiranje Testiranje performanse Testiranje prihvatanja Instalaciono testiranje FUNKCIONALNI TEST Testiranje sistema počinje od funkcionalnog testa. Kao što se funkcionalni test bavi funkcionalnim zahtevima. test opterećenja . Funkcionalni test se zasniva na funkcionalnim zahtevima sistema. Ako u zahtevima stoji da sistem treba da najviše odredjen broj korisnika ili uredjaja. zato se slučajevi za funkcionalno testiranje prave na osnovu specifikacije zahteva. Smernice za funkcionalno testiranje su: visoka verovatnoća otkrivanja grešaka tim za testiranje nezavisan od projektanata I programera poznate očekivane akcije I izlaz testiranje ispravnih I neispravnih ulaza sistem se nikad ne menja da bi se testiranje olakšalo definisani kriterijumi završetka U funkcionalnom testiranju se sistem poredi sa zahtevima. Svakoj funkciji se mogu pridružiti one komponente koje je izvršavaju.TESTIRANJE SISTEMA Kada se testira sistem. pa se funkcionalno testiranje ponekad naziva testiranje niti. Proverava se da li sistem radi ono što želi kupac. VRSTE TESTOVA PERFORMANSE Vrste testova performanse se odredjuju prema vrstama nefunkcionalnih zahteva. zanemaruje se struktura sistema I usrsredjuje se na funkcionalnost. prelazi se na način na koji se te funkcije izvršavaju. Skup aktivnosti pridružen jednoj funkciji se naziva nit. Za neke funkcije to može obuhvatiti I ceo sistem. U efikasnom funkcionalnom testiranju verovatnoća otkrivanja grešaka je visoka. Testovi opterećenja ocenjuju sistem kada se on optereti do svojih granica u kratkom vremenskom periodu.

kupac izveštava koji zahtevi nisu ispunjeni . instalacioni test možda nije ni potreban. Ako je test prihvatljivosti izveden na lokaciji korisnika. Nakon testiranja prihvatljivosti. Testovi ljudskih faktora istražuju zahteve koji se tiču interakcije korisnika sa sistemom. proveravaju se polja i datoteke da li će moći da prime sve očekivane rezultate.ocenjuje performanse sistema kada su istovremeno aktivni svi ti uredjaji I korisnici. Ispituje se izgled ekrana. Testovi kapaciteta posmatraju obradu velike količine podataka u sistemu. a zatim posmatra da li se on pravilno oporavlja. Sistem se izlaže gubitku sistemskih resursa. Testovi su usresredjeni na dve stvari: da li je instalirani sistem potpun I da li . a koje treba izbrisati. test kompatibilnosti ispituje brzinu I preciznost pronalaženja podataka. Sada kupac vodi testiranje I definiše slučajeve koji će se testirati.Proverava se da li sistem reaguje pravilno kada skupovi podataka dosegnu svoj maksimum. revidirati ili dodati zbog promenjenih uslova. integritet I poverljivost podataka. Testovi kompatibilnosti su potrebni kada sistem ima interfejsove prema drugim sistemima. testira se dostupnost. Osoblje koje upravlja konfiguracijom identifikuje ove promene I evidentira potrebne modifikacije dizajna. implementacije I testiranja. Alociraju se datoteke I dodeljuje pristup odgovarajućim funkcijama I podacima. Npr. formati izveštaja I druge karakteristike koje mugu da utiču na lakoću korišćenja. zna se da sistem zadovoljava sve zahteve definisane u pičetnoj fazi razvoja softvera. Testovi konfiguracije analiziraju različite softverske I hardverske konfiguracije navedene u zahtevima. uredjaja ili usluga. potrebno je dodatno testiranje. Svrha testa prihvatljivosti jest da se kupcima I korisnicima omogući da utvrde da li sistem koji je napravljen zadovoljava njihove zahteve I očekivanja. TESTIRANJE PRIHVATLJIVOSTI Kada se završi funkcionalno testiranje I testiranje performansi. napajanja. Test slučajevi uveravaju kupca da je sistem potpun I da su prisutne sve datoteke I uredjaji. Ispituje se da li se funkcije interfejsa izvršavaju u skladu sa zahtevima. Test konfiguracije ocenjuje sve moguće konfiguracije I proverava da li svaka od njih zadovoljava zahteve. Npr. Testovi bezbednosti proveravaju da li su zadovoljeni bezbednosni zahtevi. Za početak instalacionog testa konfiguriše se sistem prema korisničkom okruženju. ako sistem komunicira sa velikim sistemom baze podataka I preuzima informacije od njega. poruke. povezuje se odgovarajući uredjaji sa glavnim procesorom I uspostavlja komunikacija sa drugim sistemima. ako uslovi testiranja prihvatljivosti nisu bili identični uslovima kod korisnika. INSTALACIONI TEST Sam kraj testiranja predstavlja instaliranje sistema na lokaciji korisnika. Ovaj test je posebno značajan za sisteme koji najčešće funkcionišu ispod svog maksimumalnog opterećenja ali su u nekim vršnim situacijama žestoko opterećeni. Medjutim. Sledeći korak je pitati kupca I korisnike da li se oni sa tim slažu. gleda se da li su strukture podataka definisane dovoljno široko da mogu da prihvate sve podatke. Testovi oporavka ispituju reagovanje sistema na prisustvo grešaka ili na gubitak podataka.

testiranje se završava I sistem se formalno isporučuje. Vrste obuke Obuka korisnika Obuka operateta Specijalna obuka DOKUMENTACIJA Vrsta dokumentacije Korisnički priručnik Priručnici za operatere Opšti vodič kroz sistem . Kada kupac bude zadovoljan rezultatima.uslovi na lokaciji utiču na neke funkcionalne ili nefunkcionalne karakteristike. ISPORUČIVANJE SISTEMA OBUKA Sistem koristi dve vrste ljudi: korisnici I operateri.

Sign up to vote on this title
UsefulNot useful