You are on page 1of 6

Programski stil I metodologija

● Problemi povrede principa programiranja:


- Nedostajanje komentara
- Nepostojanje uvlačenja prilikom kucanja koda
- Greške u kodiranju

● Celokupan proizvod obuhvata:


- Izvorni program
- Dokumentaciju
- Objekt program
- Dokumente testiranja

● Aspekti dobrog stila programiranja:


- Komentarisanje delova koda
- Integrisana dokumentacija
- Odgovarajući izbor imena
- Formatiranje izgleda programa
- Praktikovanje strukturnog programiranja
- Primenjivanje odbrambenog programiranja

● Metodologije – Dobre prakse


- Dobar izbor programskog jezika
- Pravilan redosled implementacije komponenti
- Praktikovanje metoda stepenastog profinjavanja
- Korišćenje osnovnih koncepata
- Dobra procena grešaka u programiranju

Strukturno programiranje
Podsetimo se da smo gore naveli da praktikovanje strukturnog programiranja spada u apsekte
dobrog stila programiranja
• Strukturne naredbe (treba koristiti)
- Sekvence
- Uslovne naredbe
- While petlje
Odbrambeno programiranje
• Podstiče programera da se ne oslanja na sistem u smislu da će on uraditi stvari umesti vas

Portabilno programiranje
• Portabilno programiranje je takvo da je akcenat na zavisnosti od hardvera I
sistema(operativnog, kompajlerskog)
Stepenasto profinjavanje
• Dobar način za kreiranje “čistog” koda I obuhvata:
- Implementaciju sa apstraktnim podacima, operacijama
- Profinjavanje komentara
• Prednosti primene profinjavanja:
- Dokumentovan proces razvoja
- Jednostavnije I brže uvođenje novih osoba u suštinu programa
- Program je struktuiran po kontrolnim strukturama I po slojevima profinjenja.

Komentari

● Šta treba komentarisati?


- Početak određenog dela programa
- Podatke
- Izmene programa

● Loše prakse kod komentara:


- Previše komentara(gubi se preglednost)
- Prepričavanje koda

● Prioriteti pre komentarisanja:


- Struktura programa
- Izbor imena

● Administrativne informacije u dokumentaciji


- Autor (programer)
- Broj verzije
- Status (u radu, završen, prihvaćen)
- Datum
- Način pozivanja metoda u programu

Identifikatori

● Konvencije I smernice za korišćenje identifikatora:


- Razumljive skraćenice
- Počinje slovom
- Bez praznina
- Pisane na engleskom ili lokalnom jeziku
- Svaka reč u identifikatoru počinje velikim slovom itd...
- Imena klasa
• počinju velikim slovom
• su imenice
- Imena objekata počinju malim slovom
- Imena operacija počinju glagolom iza kojeg sledi imenica
Algoritamski orijentisan pogled

● Ciljevi:
- Podrška razvoju programa
- Uproštavanje procesa razvoja softvera korišćenjem osnovnih koncepata
● Osnovni koncepti razvoja softvera:
- Funkcijsko stablo
- Psudo kod
- Box dijagram
- Petri mreže
- Dijagram klasa
- Dijagram toka programa (poluformalni, verbalni)
● Faze razvoja softvera:
- Faza definisanja
- Faza projektovanja
- Faza implementacije
Napomena:Radi boljeg razumevanja pogledati primere dijagrama (grafički prikaz) u temi 19(str. 40+)

Testiranje

● Vodopani model proširen testiranjem(svakoj fazi se pridružuje određen test):


- Faza definisanja zahteva → Test prihvatanja
- Faza projektovanja arhitekture → Sistemski test
- Faza detaljnog projektovanja → Test integracije
- Faza implementiranja modula → Test modula
● Značaji testiranja:
- Usled nedovoljnog testiranja postoji solidna šansa za propadanje celokupnog projekta
- Gubitak novca
- Veliki udeo u razvoju kvalitetnog softvera
● Šta obuhvata testiranje?
- Testiranje programa obuhvata pre svega biranje test podataka a kasnije I izvršanje programa
pomoću istih te analiza dobijenih podataka
● Problemi koji se javljaju u toku testiranja:
- Kako izabrati dobre test podatke
- Kako pravilno izvršiti program pomoću istih
- Kako pravilno analizirati podatke
● Vrste zahteva za testiranje:
- Funkcionalni zahtevi
- Nefunkcionalni zahtevi (efikasnost, upotrebljivost)
● Alati za testiranje daju podršku testiranja prilikom:
- Određivanja test primera
- Definisanja očekivanih rezultata
- Izvršavanja testa
- Nadgledanja I procene testa
● Dva pristupa obezbeđivanju kvaliteta:
- Konstruktivni (u toku razvoja – ISO 9000)
- Analitički (provera gotovog softvera testiranjem primenom gore navedenih načina)
● Pregled (review) softvera predstavlja, kako samo ime kaže, pregled celokupnog sistema sa
ciljem prihvatanja(odbijanja) ili komentarisanja.
● Ispitivanje softvera predstavlja poveru usklađenosti sa specifikacijom, standardima, ugovornim
obavezama ili sa nekim drugim kriterijumima.

Funkcionalno testiranje

● Takvo da se test primer kreira na osnovu specifikacije softvera i u toku kojeg je program
nepoznat
● Test primere možemo pronaći u specifikaciji zahteva i modelu proizvoda(ovo su delovi faze
definisanja)
Napomena: Objašnjenje na primeru možete viditi u Temi 21(str. 7-9)
● Pristup zasnovan na slučajevima korišćenja (seti se praktičnog zadatka u kojem smo imali
use case dijagrame)
● Dijagrami aktivnosti omogućavaju dodatnu analizu scenarija primene i test sekvenci
● Testiranje izuzetaka I graničnih vrednosti je izuzetno bitno ukoliko želimo bezbedan softver

Napomena: Kako bi se se razumelo savetujem da pogledate dat primer na slajdovima(Tema 21


str. 21-29)
● Usled kompleksnih ulaznih podatka dobra je praksa podeliti ih na podskupove te testirati samo
te podskupove međusobno umesto svaki podatak sa svakim podatkom.
● Osnovni principi metoda drveta klasifikacije:
- Određivanje bitnih aspekata ulaznih podataka (npr. boja, veličina, oblik) za objekte koji treba
se testiraju
- Hijerarhijsko struktuiranje aspekata(npr. BOJA) I klasa(npr. ŽUTA)
- Određivanje test primera
Zaključak vezan za drvo klasifikacije: Imamo deo programa koji treba da testiramo→ pitamo
se koji podaci obeležavaju dati deo programa(klasifikacija)→ kako možemo opisati date
podatke(klase)
- Minimalan broj test primera → samo klase
- Maksimalan broj test primera → klase I klasifikacije(aspekti)

Napomena: Primer test slučaja možete videti u temi 21 str. 110

● Osnovni principi testiranja u metodi zasnovanoj na stanjima:


- Pokrivenost stanja (svako stanje mora biti posećeno bar jednom)
- Pokrivenost prelaza (mora se preći iz svakog stanja u odgovarajuće suprotno, npr. iz stanja
radi→ ne radi)
- Pokrivenost događaja (za svaki prelaz se moraju testirati događaji koji vode u taj prelaz, npr iz
stanja radi se u stanje ne radi može doći na više načina)

Strukturno testiranje

● Takvo da se test primeri određuju iz programa I sam program je poznat (test bele kutije u kojem
je odlučujući faktor struktura programa )
● Orijentisano je ka toku kontrole i ka toku podataka
- Metodi toka kontore:
- Pokrivenost naredbi (svi test primeri moraju prolaziti bar jednom kroz svaku naredbu)
Cnaredba = BrojPosećenihČvorova / UkupanBrojČvorova
- Pokrivenost grana (prolaz kroz sve grane)
Cgrana = BrojPosećenihGrana / UkupanBrojGrana
- Uslov minimalno višestruke pokrivenosti (svaki uslov mora biti proveren test
primerom bar jednom za TRUE i jednom za FALSE slučaj)
- Testiranje unutrašnjih graničnih putanja (prolaz kroz telo ciklusa bar jednom)
- Metodi toka podataka:
- Odnos između dodele vrednosti i upotrebe vrednosti kod promenljivih
- Definisanje vrednosti (def:value)
- Upotreba vrednosti (use:value)
- Proširenje grafa kontrole toka

- Test primeri obezbeđuju da za svaku dodelu (def) promenljive i za svaku njenu


narednu upotrebu (use) postoji bar jedna putanja između te dve tačke u programu

Struktuno VS Funkcionalno

● Strukturno testiranje
- Prednosti:
- Meri se kvalitet test primera
- Problemi:
- Funkcionalnost koja nedostaje se ne može uočiti
- Alati:
- Mere stepen pokrivenosti

● Funkcionalno testiranje
- Prednosti:
- Program se testira prema specifikaciji
- Problemi:
- Ako je specifikacija neprecizna i nekompletna
- Nemoguće je izmeriti kvalitet test primera
- Alati:
- Sistematičan izbor test primera

You might also like