Softverske tehnike

UVOD

Komponente softvera se mogu podijeliti na mašinski izvodljive i mašinski neizvodljive.

Kategorije softvera: aplikacioni i sistemski, Real time softver - podržava rad u realnom vremenu, poslovni softver, inženjerski ili naučni, embedded softver - egzistira u kontrolerima raznih uređaja, PC softver.

Softverska kriza: kako razvijamo softver i kako odrzhavati višerastući softver. Paradigma (obrazac): kombinuje razumljive metode u svim fazama ravoja, bolje alate za razvoj metoda (planiranje, analiza zahtjeva, projektovanje)Projektovanje: struktura podataka, programiranje arhitekture i algebarske procedure.Nakon projektovanja nastupa kodiranje pa testiranje i, nakon toga, održavanje. Kada alate za sve ove metode integrišemo tako da oni mogu razmjenjivati informacije onda dobijamo CASE (Computer Aided Software Engineering)

strana 1 od 75

Softverske tehnike

McCabe:

Object oriented:1.analiza – sakupljanje zahtjeva vezanih isključivo za softver2.dizajn - 3.kodiranje – programiranje

Nedostaci:1.realni projekti rijetko2.korisnik u početku ne može znati sve zahtjeve3.korisnik mora biti ????? za radnu verziju4.prototip dolazi u slučaju da korisnik ne zna šta traži.

strana 2 od 75

Softverske tehnike

Tehnike četvrte generacije:

Upotrebljivo za poslovne aplikacije, za male i srednje firme. Za velike firme se skraćuje vrijeme kodiranja, za manje se smanjuju i troškovi.

PROCEDURE – definišu upotrebu svakog elementa.BAZE PODATAKA – organizovani podaci kojima se pristupa preko softvera.

strana 3 od 75

Softverske tehnike

SISTEMSKA ANALIZA

1. Identifikacija potreba2. Studija opravdanosti (feasibility study)3. Ekonomska analiza (troškovi i dobit)4. Tehnička analiza (performanse, pouzdanost, odrzavanje, produktivnost)5. Alociranje (dodjela koja se odnosi na sistemske funkcije, sistemske elemente

tj. šta čime izvršiti (tzv. trade off)

IDEDENTIFIKACIJA POTREBA (učestvuju analitičar i naručilac)

FEASIBILITY STUDY Ovdje postoje dva problema beskonačno vrijeme I neograničeni resursiStudija je skoncentrisana na:a) ekonomsku opravdanostb) tehničku opravdanostc) pravna opravdanostd) alternative

SADRŽAJ STUDIJE OPRAVDANOSTIa) uvod:

- kratak opis problema- okruženje u kojem će se sistem implementirati- ograničenja u projektu

b) zapažanja i preporuke za dalji razvoj sistemac) alternative:

- kriterij upotrebljen u selekciji- alternative sistemske konfiguracije

d) opis sistema (skraćena verzija sistemske specifikacije)

strana 4 od 75

Softverske tehnike

e) analiza troškova i dobitif) vrednovanje tehničkog rizikag) zakonske graneh) ostale specifičnosti

SISTEMSKA ANALIZA

- identifikacija korisnikovih potreba- opravdanost sistemskog koncepta- ekonomska i tehnička analiza- dodjela funkcija (hardvera, softvera, ljudima, bazama podataka i ostalim sistemskim elementima)- ograničenja u pogledu troškova i rokova- kreiranje sistemskih definicija (kao osnov za sav ostali inženjerski posao)

Sistemska analiza se provodi u nekoliko faza (kroz pitanja i odgovore):

- planiranje analize- kontakt sa korisnicima- ciljevi sistema- postojeći sistemi- elementi i strukture podataka- korisnički intrvjui- istraživanje drugih sistema- prijedlozi alternativa- selekcija dizajnerskih alternativa- strukturalna analiza (tokovi podataka, procesiranje…)- planovi za sljedeće faze- prezentacija svim nivoima upravljanja

SISTEMSKA SPECIFIKACIJA

Ona je prva isporučiva u softver inženjeringu i opisuje sljedeće:- ciljeve i okruženje- opravdanost, troškove, rokove itd.- opis svake sistemske funkcije (ulaz, zadaci, izlaz, interfejs)- dodjela sistemskih elemenata svakoj funkciji- ograničenja- troškovi- rokovi i planovi.

Zaključak:CSE (computer system enginering) je prvi korak u razvoju novog kompjuterski baziranog sistema ili proizvoda razvijenog u sistemskoj analizi.

strana 5 od 75

Softverske tehnike

CSE identifikuje ključne sistemske elemente, a to su:-korisnikove potrebe-ekonomska opravdanost-softverske funkcije-hardver-ljudi i baze podataka

CSE zahtjeva intenzivnu komunikaciju korisnika i analitičara u kojoj korisnik mora da razumije sistemske ciljeve, a analitičar treba da zna šta da pita i kakve savjete da daje.

PLANIRANJE SOFTVERSKOG PROJEKTA

Da bi planirali softverski projekt moramo imati sljedece:1. razumijevanje posla2. resurse koji su na raspolaganju3. zadatke4. tačke za kontrolu (mile stones)5. napor, vrijeme, troškove i rokove

Softver inženjering kombinuje istraživanje i očekivanje. Istraživanje se odnosi na rizik, ciljeve i softver. Softver obuhvata broj simultanih korisnika, vrijeme odziva i memoriju. Dok se očekivanje svodi na resurse.

strana 6 od 75

Softverske tehnike

Hardverski resursi podrazumijevaju:

Personalne računare (njihove karakteristike, proizvođače, performanse) računarske mreže (postoji 5 tipova koji se razlikuju pre svega po topologiji:

BUS (magistralne), STAR (zvijezda, glavni element HUB), RING (prsten) i dvije koje se rijetko koriste MESH i TREE

Izbor baze podataka (oracle, access…)

SOFTVERSKI ALATI:

CASE –computer aided software enginering

strana 7 od 75

Softverske tehnike

SOFTVERSKE METRIKE

2.1 OSNOVE TEORIJE MJERENJA

Softverska mjerenja, kao u bilo kojoj drugoj disciplini moraju se bazirati na naučnoj teoriji mjerenja da bi bila prihvatljiva i ispravna. Teorija mjerenja rasvjetljava sve prednosti i nedostake softverskih metrika. Mjerenje se definiše kao proces u kome se brojevi ili simboli pridružuju aributima entiteta u realnom svijeta na taj način da ih opišu prema jasno definisanim pravilima. Pod entitetom se smatra objekt, kao što je osoba ili softverska specifikacija odnosno događaj npr. faza testiranja softverskog projekta. Aribut je osobina eniteta npr. visina osobe, dužina specifikacije, trajanje testne faze itd.

Pridruživanje brojeva i simbola mora osigurati intuitivnu i empirijsku opservaciju entiteta i atributa. U većini stuacija, atribut iako je dobro poznat, ima raličito intuitivno značenje za različite ljude i zbog toga se mora definisati model za entite koji se mjere. Kada je definisan model onda postoje jasne empirijske relacije između entiteta i atributa. Npr. kod jednostavnog mjerenja dužine programa brojem linija izvornog koda (LOC) zahtijeva se dobro definisa model programa koji omogućava da se identificira nedvosmislen broj linija koda.

Dva osnova tipa mjerenja su :

-direktna mjerenja i-indirektna mjerenja

Direktno mjerenje atributa ne zavisi od mjerenja bilo kog drugog atributa za razliku od idirektnog mjerenja koje obuhvata mjerenje jednog ili više atributa.

Dva glavna razloga za mjerenje su:

-procjena i-predviđanje

Mjerenje za predviđanje aributa A zavisi od matematičkog modela koji stavlja u relaciju egzistirajuća metrike atributa A1...An. Tačnost mjerenja za prdeviđanje zavisi od tačnosti metrika za procjenu atributa A1...An i zato tačna mjerenja ključnih atributa za postojeće projekte omogućavaju tačnu predviđanje za buduće projekte. Nadalje, za tačna mjerenja za predviđanje model sam za sebe nije dovoljan, naime potrebno je definisati još procedure za :

-determinisanje parametara modela i-interpretaciju rezultata

Model, zajedo sa procedurama, naziva se sistem za predviđanje. Upotrebom istog modela i različitih procedura dolazi se do različitih predviđenih rezultata.

strana 8 od 75

Softverske tehnike

Premda nema univerzalno prihvaćene teorije mjerenja većina pitanja se svode na rješavanje sledećih problema:

-šta je mjerljivo, a šta nije ?-koji tipovi atributa mogu ili ne mogu biti mjereni i na kojoj skali mjerenja -kako se zna da su atributi realno mjereni ?-kako odrediti skalu mjerenja ?-koji je prag greške prihvatljiv ?-koji su izvještaji o mjerenju značajni ?

Mjerenje da bi bilo efektivno mora biti :

1. Fokusirano na specifične ciljeve.2. Primjenjeno u svim fazama životnog ciklusa produkta, procesa i resursa.3. Interpretirano na bazi razumjevanju organizacionog konteksta,

okruženja i ciljeva.

To znači da mjerenje mora biti definisano u top-down (od vrha prema dnu) stilu i mora biti fokusirano i bazirano na ciljevima i modelima. Drugi pristup bottom-up (od dna ka vrhu) nije dobar jer postoje mnoge opservabilne karakteristike softvera (npr. vrijeme, broj grešaka, kompleksnost, linije koda, napor, produktivnost itd.) ali nije sasvim jasno koje metrike upotrebiti i na koji način ih interpretirati bez odgovarajućeg modela i ciljeva.

GQM model ima tri nivoa:

1. Konceptualni nivo (GOAL) : Cilj se definiše za objekt vodeći računa o različitim modelima kvaliteta i različitim tačkama gledišta. Objekti mjerenja su:

Produkti koji nastaju u životnom ciklusu sistema npr. : specifikacije, projekti, programi, testni podaci.

Procesi koji obuvataju aktivnosti vezane za vrijeme npr. : specificiranje, projektovanje, testiranje, intervijuisanje.

Resursi upotrebljeni u procesu da bi se dobio produkt npr. :personal, hardver, softver, radni prostor.

2. Operativni nivo (QUESTION) : Ovaj nivo obuhvata niz pitanja koja se upotrebljavaju da specificiraju put za postizanje željenog cilja. Pitanja pokušavaju da karakterišu objekte mjerenja (produkti, procesi, resursi) sa respektom na selektirani nivo izlazećeg kvaliteta sa različitih tačaka gledišta.

3. Kvantitativni nivo (METRIC) : Ovaj nivo je predstavljen nizom podataka, pridruženih svakom pitanju, koji daju odgovor u kvantitativnoj formi. Podaci mogu biti :

-objektivni -subjektivni

strana 9 od 75

Softverske tehnike

Objektivni podaci zavise samo od objekta mjerenja ali ne i od tačke gledišta za razliku od subjektivnih koja zavise i od jednog i od drugog.

GQM model ima hijerarhijsku strukturu prikazanu na Slici 2.1.

Slika 2.1 Hijerahijska struktura GQM

Kasnije si neki autori proširivali ovaj osnovni model na više nivoa. Ciljevi su podjeljeni na podciljeve, podciljevi na domene a domene na poddomene. Pitanja su proširena sa podpitanjima a metrike su podjeljene na karakteristične i pojedinačne.

Proširenje se takođe odnosi i na tri nova nivoa: prikupljanje podataka, modeliranje i implementaciju iz kojih se može dobiti informacija o troškovima i dobiti tj o ekonomskoj opravdanosti programa za mjerenje. Ovaj model je nazvan GQM++.

GQM prilaz je u stvari mehanizam za definisanje i interpretiranje mjerljivog softvera i može se upotrebiti zasebno ili u kombinaciji sa nekim drugim pristupima u smislu poboljšana kvaliteta softvera.

Međutim postoje situacije kada se koristi mjerenje softvera a da ciljevi nisu jasno definisani. Ova situacije se obično dešavavaju kada se mali broj metrika odnosi na različite ciljeve. Sledeći problem je ko postavlja ciljeve. Najviše rukovodstvo može identificirati loše ciljeve ili ciljeve za koje se ne mogu praktično izračunati metrike na inženjeriskom nivou koji zahtijeva korisne i praktične metrike.

Fenton smatra da je GQM koristan za identifikaciju ciljeva mjerenja ali da ne ukazuje na stvarne probleme u mjerenju (tehnički aspekt kao što je skala mjerenja), Gray i MacDonel ovaj kriticizam proširuju na opravdanost, ekonomičnost i korektnost provjere (jednostavan i intuitivan način).

strana 10 od 75

CILJ CILJ

PITANJE PITANJE PITANJE PITANJE

METRIKA METRIKA METRIKAMETRIKAMETRIKA

Softverske tehnike

TIPOVI METRIKA

Postoji konfuzna situacija u upotrebi termina mjerenje softvera i softverske metrike. U skladu sa teorijom mjerenja upotrebljava se termin mjerenje softvera, me|utim u literaturi se ova dva termina upotrebljavaju kao sinonimi. Pod softverskom metrikom se podrazumjeva kvantitativna mjera izvodljiva ili izvedena iz atributa u toku životnog ciklusa softvera na mehanički ili algoritamski način tako da ne zavisi od uređaja za mjerenje koji može biti čovjek, hardver, softver ili kombinacija.

Kompleksnost programa koja usporava razvoj i održavanje u direktnoj je vezi sa vremenom i troškovima i kao takva zahtijeva mjerenje sa različitih aspekata. Prirodna kompleksnost zadatka može se veoma razlikovati od očite kompleksnosti programa razvijenog za taj zadatak. Softver je diskretni sistem i to je u suštini uzrok njegove kompleksnosti.

Da bi se vrednovali :

- korektnost- tačnost- pouzdanost- mogućnost održavanja- čitljivost- razumljivost- portabilnost- efikasnost- fleksibilnost- mogućnost testiranja- mogućnost nadgradnje- cijena programiranja- cijena izvodjenja itd.

treba koristiti metrike koje obezbedjuju :

- objektivnost- pouzdanost- sigurnost- ispravnost- prikladnost i td.

a ne intuiciju.

Takve metrike mogu biti korisne u :

-pripremi kvalitetne specifikacije i ugovorenih obaveza

-provjeravanju jasne specifikacije softvera-u odredjivanju odnosa održavanje/troškovi-poboljšanju produktivnosti-poboljšanju kvaliteta-povećanju pouzdanosti

strana 11 od 75

Softverske tehnike

-kao baza za dalja predviđanja-zahtijevu za novim softverskim alatima i dodatnoj

obuci

Softverske metrike obuhvataju širok rang mjerenja koja se mogu podijeliti na direktna i indirektna mjerenja.

Direktna mjerenja obuhvataju :

-cijenu-vrijeme-broj linija izvornog koda-kompleksnost-broj grešaka-brzinu itd.

Indirektna mjerenja se uglavnom odnose na:

-kvalitet-efikasnost-pouzdanost-produktivnost-pogodnost održavanja itd.

Fenton je, na osnovu entiteta i atributa koji se mjere, metrike podjelio na sledeći način (Tabela 2.1):

ENTITETI ATRIBUTI INTERNI EKSTERNI

PRODUKTI

Specifikacije veličina, ponovna upotreba, modularnost,redudancija, funkcionalnost, koreksnost sintakse...

razumljivost,pogodnost održavanja...

Projektovanje veličina, ponovna upotreba, modularnost, kohezivnost, funkcionalnost, povezivost...

kvalitet, kompleksnost, pogodnost održavanja...

Kod veličina, ponovna upotreba, modularnost, kohezivnost, funkcionalnost, povezivost, kompleksnost algoritma, kompleksnost upravljačkih struktura...

pouzdanost, upotrebljivost, pogodnost za održavanje...

Testni podaci veličina, nivo pokrivanja... kvalitet......PROCESI

Konstrukcija specifikacije vrijeme, napor, broj zahtiva za izmjenu...

kvalitet, troškovi, stabilnost...

Detaljno projektovanje troškovi, efektivnost

strana 12 od 75

Softverske tehnike

ENTITETI ATRIBUTItroškova

Testiranje vrijeme, troškovi, broj nađenih grešaka...

troškovi, efektivnost troškova, stabilnost...

...RESURSI

Personal godine, cijena... produktivnost, iskustvo, inteligencija...

Timovi veličina, nivo komunikacija, struktura...

produktivnost, kvalitet...

Softver cijena, veličina upotrbljivost, pouzdanostHardver cijena, brzina, kapciteti... pouzdanostRadni prostor veličina, temperatura,

svijetlost...komfor, kvalitet...

...

Tabela 2.1 Komponente mjerenja softvera

Metrike se u odnosu na kvalitet i produktivnost softvera mogu podijeliti i na sledeći način :

1. metrike koje predviđaju kvalitet softvera2. metrike koje testiraju kvalitet softvera3. metrike koje indiciraju produktivnost u fazi razvoja i održavanja

Ove metrike se mogu dobiti iz statičke analize dokumentacije ili izvornog koda odnosno iz istorijata testiranja i održavanja programa ili sistema.

Prediktivne metrike se dobijajaju u fazi definisanja, projektovanja i programiranja.

Metrike koje se dobiju u fazi testiranja koriste se za vrednovanje prediktivnih metrika i njihovu korekciju.

Produktivne metrike se dobijaju dijelenjem nekih dobijenih metrika sa upotrebljenim resursima.

Za mjerenje kvaliteta softvera definisano je niz faktora i kriterija. Precizna mjerenja kvaliteta softvera su onemogućena nedostatkom preciznih relacija između mjeremih varijabli i karaktera softvera. Iz ovoga sledi da se ne može realno mjeriti kvalitet softvera nego samo neke manifestacije kvaliteta. Predmet ovoga rada su samo one metrike koje se odnose na kvantitativno vrednovanje kvaliteta softvera (Halstead, McCabe itd.)

McCall je u odnosu na stanje softverskog produkta (operativnost, revizija i tranzijentnost) faktore i kriterije podijelio na sledeći način:

strana 13 od 75

Softverske tehnike

OPERATIVNOST

faktor kriterij

UPOTREBLJIVOST -operativnost-obuka-komunikativnost-veličina ulaza/izlaza

INTEGRITET -kontrola pristupa programima i podacima

EFIKASNOST -efikasnost upotrebe memorije-efikasnost izvođenja

KOREKTNOST -kompletnost-konzistencija

POUZDANOST -sigurnost-tolerancija greške-jednostavnost

REVIZIJA

ODRŽAVANJE -konzistencija-jednostavnost-samoidokumentovanost-modularnost-konciznost

TESTIRANJE -jednostavnost-instrumentacija-samodokumentovanost-modularnost

FLEKSIBILNOST -proširivost-samodokumentovanost-generalitet-modularnost

TRANZIJENTNOST

PONOVNA UPOTREBA -generalitet-samodokumentovanost-modularnost-nezavisnost od mašine-nezavisnost od sistemskog softvera

strana 14 od 75

Softverske tehnike

PORTABILNOST -samodokumentovanost-modularanost-nezavisnost od mašine-nezavisnost od sistemskog softvera

INTEROPERATIVNOST -modularnost-komunikacije-zajednički podaci

Sa povećanjem broja softverskih aplikacija, rastao je i značaj kvaliteta softvera i da bi se upravljalo kvalitetom softvera bilo je potrebno utvrditi metodologije za objektivno kvatitativno vrednovanje softverskih proizvoda i procesa njegovog razvoja. Kao baza za internacionalni standard kvaliteta softwera je preporučen McCall-ov model. 1991. godine standardom ISO / IEC 9126 definisano šest karakteristika sa sledećim podkarakteristikama :

KARAKTERISTIKA PODKARAKTERISTIKA

FUNKCIONALNOST pogodnosttačnostpovezanostusaglašenostsigurnost

POUZDANOST zrelost (učestalost greške usled nedostatka u softveru)

otpornost prema greškamaoporavljivost

UPOTREBLJIVOST razumljivostpogodnost za učenjeizvršivost

EFIKASNOST ponašanje u vremenuponašanje sa resursima

POGODNOST ZA pogodnost za analizuODRŽAVANJE izmjenljivost

stabilnostpogodnost za testiranje

PRENOSIVOST prilagodljivostpogodnost za instaliranjeusaglašenostzamjenljivost

strana 15 od 75

Softverske tehnike

Dosad razvijene metrike za kompleksnost softvera mogu se svrstati u dve glavne grupe :

1. statičke2. dinamičke.

Statičke metrike se odnose na statičku analizu izvornog koda dok su dinamičke vezane za izvodjenje programa i u velikoj zavisnosti su od ulaznih podataka.

Statička mjerenja se mogu odnositi na :

1. mjerenje veličine programa (volumen)2. mjerenje upotrebe i interakcije podataka (organizacija podataka)3. mjerenje upravljačke organizacije programa

Statičke metrike su bazirane na fizikalnim atributima softvera.

Metrike volumena uglavnom mjere veličinu softverskog produkta : broj linija koda, broj naredbi, broj operatora i operanada, broj procedura, srednju veličinu procedura, broj varijabli itd.

Upravljačke metrike mjere kompleksnost upravljačkih struktura ili kada su napisane ili kada su predstavljene pomoću grafa toka.

Metrike podataka mjere upotrebu podataka, njihovu vizuelnost i njihovu interakciju sa programom.

Prema Belady nije uvijek jasno kojoj kategoriji pripada koja metrika. Npr. kompleksnost upravljačkih struktura se može posmatrati ili kao metrika volumena ili kao metrika kompleksnosti, zavisno od toga šta se želi naglasiti.

Metrike volumena i upravljačke metrike spadaju u grupu strukturalnih metrika za razliku od metrike podataka koje spadaju u drugu grupu i neće biti razmatrane u ovom radu.

Sledeća podjela metrika u odnosu na kompleksnost baziranu na fizikalnim atributima softvera je :

1. statičke metrike koje mjere softverski produkt u određenoj tački vremena

2. istorijske metrike koje mjere produkt naknadno

Gornje metrike su prihvatljive za ispravno mjerenje kompleksnosti programa zbog nedostatka ekspirimentalne evidencije koja determiniše koji aspekt životnog ciklusa softvera metrika objašnjava. Međutim dok metrika može dobro korelirati sa vremenom otklanjanja grešaka na drugoj strani može biti slab prediktor za napor u fazi održavanja.

strana 16 od 75

Softverske tehnike

METRIKE PRODUKTA

Metrike produkta su prema klasifikovane na sledeći način :

Metrike veličine produkta

- metrike broja elemenata-broj linija koda-broj stranica dokumentacije-broj testnih slučajeva

-metrike razvoja-metrike vremena-metrike troškova-metrike upotrebe resursa

-metrike veličine komponenata-broj modula/objekata-srednja veličina komponenata

Metrike arhitekture

-metrike komponenata-broj (jezičkih) paradigmi-dio standardnog softvera-nivo kvaliteta

-karakteristike arhitekture-nivo otvorenosti sistema-nivo integracije

-standard za metrike-upotreba standardnih metrika-dio standardizacije

Metrike strukture

-karakteristike komponenata-broj elemenata strukture-dio komponenata po elementu strukture-srednji nivo povezivanja

-karakteristike strukture-nivo kompozicije-nivo dekompozicije-povezanost komponenata

-psihologičke metrike-orjentacija za širinu strukture-orjentacija za dubinu strukture-vizuelni nivo

Metrike kompleksnosti

-metrike za računsku kompleksnost

strana 17 od 75

Softverske tehnike

-kompleksnost algoritma-kompleksnost strukture podataka-kompleksnost podataka-kombinaciona kompleksnost-logička kompleksnost-funkcionalna kompleksnost

-metrike za psihologičku kompleksnost-kompleksnost strukture-kompleksnost toka- entropijska kompleksnost-ciklomatska kompleksnost-esencijalna kompleksnost-topološka kompleksnost-harmonička kompleksnost-sintaktička kompleksnost-semantička kompleksnost-percepcionalna kompleksnost-organizaciona kompleksnost-dijagnostička kompleksnost

METRIKE VELIČINE PRODUKTA

Veličina softverskog sistema spada u interne atribute sotverskog produkta i lako se definiše u odnosu na teoriju mjerenja i predstavlja ključni faktor za vrednovanje napora, troškova i produktivnosti.

Osnovne zamjerke za jednostavno mjerenje ovog atributa su:

-izostavljanje redundancije i kompleksnosti kada je u pitanju napor-izostavljanje napora i funkcionalnosti kada je u pitanju produktivnost-izostavljanje kompleksnosti i ponovne upotrebe koda u slučaju troškova

Ovi problemi se mogu prevazići definisanjem više atributa za veličinu softvera:

-dužina-funkcionalnost-kompleksnost-redundancija-ponovna upotreba koda (reuse)

da bi se dobila jasnija slika napora, troškova i produktivnosti.

Međutim sada se javlja drugi problem vezan za mogućnost mjerenja ovih atributa u slučaju specifikacije, projekta odnosno programa. Jedino za mjernje dužine programa postoji određeni konsenzus mišljenja ali ne i za mjerenje ovih atributa u slučaju specifikacije, odnosno projekta.

strana 18 od 75

Softverske tehnike

MJERENJE DUŽINE

Jedna od najstarijih softverskih metrika za mjerenje dužine programskog koda je broj linija koda pod kojim se može podrazumjevati:

-ukupan broj linija koda-broj linija komentaraa-broj praznih linija-broj linija koje sadrže i kod i komentare

Da ne bi došlo do konfuzije potrbno je jasno definisati šta je broj linija koda. Najčešće upotrbljavana definicija pod linijom koda podrazumjeva bilo koju liniju programskog teksta koja nije linija komentara ili prazna linija, nezavisno od broja naredbi (statement-a) ili njihovih fragmenata u liniji. Dakle uključene su sve linije koje sadrže zaglavlje programa, deklaracije, izvodljive i neizvodljive naredbe.

Međutim, upotrebom ove definicije, odnosno broja linija koda bez komentara i praznih linija, gube se važne informacije o dužini kao što su zauzeće memorije i broj strana koje će biti štampane i ova metrika nije valjana u tom slučaju.

Ali, u slučaju da su veličina i napor vezani za produktivnost ovo je valjana metrika jer se smatra da komentari ne utiču mnogo na napor. Iz gore navedenih direktnih metrika mogu se izvesti neke indirektne metrike kao npr. gustoća komentara u programu :

CLOC/LOC

pri čemu su:

CLOC (Comment Lines Of Code) - broj linija komentaraLOC (Lines Of Code) - ukupan broj linija

Sledeći način mjerenja dužine programa je izražen u broju bajtova memorije koji zauzima programski tekst. Na ovaj način se ova veličina može dovsti u vezu sa veličinom objektnog ili izvršnog koda jer se nalaze na istoj skali mjerenja.

Dužina programa se takođe može izraziti u broju karaktera (CHAR) u programskom tekstu i pomoću CHAR i prosječnog broja karaktera po liniji r dobiti stohastičku relaciju između LOC i CHAR :

LOC = CHAR / r

Sledeća često upotrebljavan metrika za dužinu programa je DSI (Delivered Source Instructions) tj. broj isporučenih izvornih instrukcija. Međutim veoma je teško dati nedvosmislenu definiciju za DSI koja je prihvatljiva za bilo koja koji programski jezik.

strana 19 od 75

Softverske tehnike

Jedan od glavnih problema mjerenja LOC-a je nekonzistentnost jer neke linije su teže za kodiranje od drugih i to nameće davanje veće težine tim linijama jer je u njih uložen veći napor odnosno vrijeme.

Ova ideja da se u vezu dovedu dva različita atributa, dužina programa i napor, postaknuta je pristupom Halstead-a i dao ju je Conte a kritikovao Fenton zbog konfuzije. Naime, Halstead je definisao dužinu programa kao sumu ukupnog broja pojavljivanja operatora i operanada (N), (više riječi o tome biće u sledećem poglavlju). Na taj način ova hibridna mjera je ograničena na specifičan jezik.

Halstead-ov sistem za predviđanje LOC na osnovu njegove definicije dužine N je:

LOC = N / Clang

Tj. za programsi jezik, Lang, postoji konstanta CLang taka da za svaki program P, očekivanini očekivani broj LOC u P je dat gornjom formulom.

Npr. ako je Lang = FORTRAN, N = 77 i Clang = 7 na osnovu gornje formule LOC = 11.

Pošto je N zavisan od jezika a LOC nije, može se prihvatiti ideja da je enkodiranje operatora i opranada u nekim jezicima zahtijeva više koda a sa samim tim i više napora i to zadovoljava Conte-ovu tvrdnju davanja veće težine nekim linijama.

Dok su LOC i CHAR dobre metrike za dužinu koda, definisanje analognih

metrika za specifikaciju i projektovanje nije tako lako.

Kada je u pitanju dužina,bilo je pokušaja da se nađu empirijske relacije između dužine programskog koda i dužine programske dokumentacije koja je jedan od bitnih faktora kvaliteta softvera i kojiu treba automatizovati. Automatizovana dokumentacija omogućava razmatranje veličine dokumenta i njegovu čitljivost. Metrike koje to određuju su:

- broj riječi- broj rečenica- broj stranica

Ove metrike se vrlo lako dobiju. Npr. kod UNIX-a pomoću komandi “”wc” ili “lex”.

Riječi, rečenice i stranice omogućavaju sagledavanje veličine programa/projekta i koreliraju sa vremenom razvoja. Sa porastom stranica dokumentacije smanjuje se vrijeme implementacije do određene tačke da bi zatim ponovo počelo da raste, drugim riječima malo dokumentacije povećava napor (vrijeme programiranja) dok previše dokumentacije dovodi do konfuzije i takođe povećava napor, odnosno vrijeme.

strana 20 od 75

Softverske tehnike

Jedna od metrika koja ocjenjuje čitljivost dokumenta je “fog” index na osnovu koga se predviđa obrazovni nivo potrebana za razumjevanje dokumenta i koji je definisan sa:

(broj riječi / broj rečenica + broj riječi > 3 sloga / broj riječi) x 0.4

Ovaj indeks je kod većine klasične literature između 7 i 8 a kod tehničke 12 ili više.

Ispitujuću vezu između dužine programskog koda i programske dokumentacije Webster i Felix su došli do sledeće formule:

D = 49L1.01

gdje su :

D - dužina dokumentacije mjerena u stranicamaL - dužina programa mjerena u hiljadama LOC-ova (KLOC)

Za tačniju predikciju pomoću ove formule podaci moraju biti skupljeni za specifično okruženje.

I pored široke upotrebe LOC metrika je često kritikovana zbog nepreciznosti kada su u pitanju različiti jezici tj. ova metrika zanemaruje više programske jezike, objektno orijentisane jezike, programske generatore, odnosno bilo koji modernom programski jezik.

Veličina ovog zanemarivanja je direktno proporcionalna nivou odnosno snazi jezika. Npr. ako proces proizvodnje uključuje fiksne troškove, redukovanje proizvedenih jedinica povećava cijenu po jedinici. Kada je u pitanju proizvodnja softvera više od polovine vremena se potroši nanekodirajuće aktivnosti (specifikacija, projektovanje, dokumentacija, upravljanje). Ako se LOC definiše kao jedinični proizvod a zatim se sa nižeg programskog jezika želi preći na viši troškovi za ne kodirajuće aktivnosti teže da ostanu nepromjenjeni ali rastu troškovi po liniji koda, što je pokazano na sledećem primjeru.

Ako se uzme projekt realizovan na asemblerskom jeziku sa 10000 linija koda, ne kodirajuće aktivnosti traju 5 mjeseci a kodiranje i testiranje 10 mjeseci, u tom slučaju ukupan projekat bi trajao 15 mjeseci. Produktivnost ukupnog projekta je 10000 LOC-ova podjeljeno sa 15 mjeseci i iznosi 666 linija koda mjesečno. Sa kadrovskim troškovima $5000 mjesečno ukupni troškovi su $75000, odnosno $7.50 po LOC-u.

Sada, ako se pretpostavi da se ovaj projekt radi npr. u ADA i da je potrebno 2000 linija koda, nekodirajuće aktivnosti traju 5 mjeseci a kodiranje 2 mjeseca, projekt traje 5 mjeseci, produktivnost se smanjuje na 285 linija koda mjesečno i sa $5000 kadrovskih troškova ukupni troškovi su $35000 ali je cijena po liniji koda porasla na $17.5.

strana 21 od 75

Softverske tehnike

Metrika LOC se obično koristi u kombinaciji sa uloženim vremenom, troškovima, stranicama dokumentacije, greškama, brojem programera itd. Iz gore navedenih i sakupljenih podataka, nekoliko jednostavnih metrika u vezi sa produktivnošću i kalitetetom softvera može biti lako izvedeno:

produktivnost = LOC / čovjek-mjeseci kvalitet = greške / LOC troškovi = novac / LOC

dokumentacija = broj stranica / LOC

Slaba strana LOC metrike je u tome da je zavisna od programskog jezika i da favorizuje velike programe na račun malih dobro dizajniranih programa.

Iz svega ovoga slijedi da ova metrika može dati ispravne rezultate, kada su u pitanju različiti jezici, samo ako se sav kod konvertuju u ekvivalentne linije.

FUNKCIONALNE TAČKE

Mnogi softverski stručnjaci tvrde da je funkcionalnost produkta daje bolju sliku o veličini produkta nego njegova dužina . U ranoj fazi projektovanja intersantnija je funkcionalnost kada su u pitanju napor i vrijeme od same fizičke veličine.

Postoje različiti pristupi mjerenju funkcionalnosti od kojih su najpoznatiji :

-Albrecht-ove funkcionalne tačke (FP)-DeMarco-ova funkcionalna “bang” metrika-Bohem-ov COCOMO model

Funkcionalne tačke, kao što i samo ime govori, mjere količinu funkcionalnosti sistema opisanog specifikacijom. Da bi se izračunale FP potrebno je identificirati računljive diskretne komponente sledećeg tipa:

Eksterni ulazi - procesni podaci ili upravlaljačke informacije koje dolaze iz vana

Eksterni izlazi - procesni podaci podaci i upraravljačke informacije koje idu

vanEksterni upiti - interaktivni upiti koji zahtijevaju izlazEksterne interfejs datoteke - mašinski čitljive za druge sistemeInterne matične datoteke - logičke interne datoteke

Albrecht je funkcionalne tačke FP računao po formuli :

-broj ulaza x 4 +-broj izlaza x 5 +-broj upita x 4 +-broj matičnih datoteka x 10

strana 22 od 75

Softverske tehnike

-broj interfejsa x 7

sa tim da težinski faktori mogu varirati +/- 25% zavisno od kompleksnosti programa. Težinski faktori su prikazani u Tabeli 2.2.

Pomoću gornje formule se dobiju nepodešene funkcionalne tačke UFC. Podešene funkcionalne tačke se dobiju množenjem UFC sa faktorom tehničke kompleksnosti TCF koji ima 14 doprinosećih faktora (on-line ulazi, on-line ažuriranje, kompleksnost interfejsa, ponovna upotreba, komuniciranje sa podacima itd.) i varira od 0.65 do 1.35.

BAZNI ELEMENT TEŽINSKI FAKTOR

JEDNOSTAVAN SREDNJI KOMPLEKSANULAZI 3 4 6IZLAZI 4 5 7UPITI 3 4 6EKST. DATOTEKE 7 10 15INTER. DATOTEKE

5 7 10

Tabela 2.2 Težinski faktori funkcionalnih tačaka

Na osnovu FP može se odrediti numerički nivo jezika i što je taj nivo viši potrebno je manje linija koda po FP. Numerički nivo jezika omogućava prečicu za konvertovanje veličine softverskog produkta iz jednog jezika u drugi. Odnos nivo jezika i srednje produktivnosti dat je u Tabeli 2.3 (Casper Jones, Software Product Research 1996) :

NIVO JEZIKA SREDNJA PRODUKTIVNOST PO ČOVJEK MJESECU

1 - 3 5 - 10 FP 4 - 8 10 - 20 FP 9 - 15 16 - 23 FP16 - 23 15 - 30 FP24 - 55 30 - 50 FP> 55 40 - 100 FP

Tabela 2.3 Relacije nivoa jezika i srednje produktivnost čovjeka po mjesecu

U sledećoj Tabeli 2.4 dati su neki jezici, njihovi nivoi i srednji broj izvornih linija po FP prema :

JEZIK NIVO SREDNJI BROJ IZVORNIH LINIJA KODA PO FP

strana 23 od 75

Softverske tehnike

ADA 95 6.50 49ANSI COBOL 85 3.50 91BASIC MS 3.50 91C++ 6.00 53CLIPPER 17.00 19CLIPPER DB 8.00 40COBOL 3.00 107DELPHI 11.00 29EIFFEL 25 21FORTRAN 95 4.50 71FRAMEWORK 50.00 6HTML 3.0 22.00 15JAVA 6.00 53MOSAIC 50.00 6ORACLE 8.00 40POWERBILDER 20.00 16SMALLTALK 15.00 21VISUAL C++ 9.5 34

Tabela 2.4 Relacije jezici - nivoi-izvorne linije kod

Zbog teškoće računanja , radno intezivnih aktivnosti i neautomatizovanosti FP se često izvode iz nekih drugih atributa softvera.

Na osnovu podataka iz Tabele 2.4 i tehnike “backfiring” moguće je izvršiti konverziju LOC metrike u funkcionalne tačke FP.

Harrison i Milik sugerišu aproksimaciju FP sa Halstead-ovom podešenom E metrikom AE:

AE = (NČ / N) * E

za postojeći kod. Na ovaj način se funcionalne tačke ekstraktuju automatski iz egzistirajućeg koda i smanjuju se troškovi mjerenja.

Glavna namjena FP je:

- mjerenje veličine produkta koja se koristi u predviđanju napora i troškova u ranoj fazi životnog ciklusa softvera (specifikacija, projektovanje)- predviđanje broja linija izvornog koda- konverzija veličine projekta pisanog u jednom jeziku u veličinu projekta pisanog u drugom jeziku jer su FP nezavisne od jezika- mjerenje produktivnosti projekata koji su pisani u više jezika- normalizacija u odnosu na FP (defekti/FP, čovjek mjesece/FP itd.- upotreba FP kao baze za ugovaranje.

strana 24 od 75

Softverske tehnike

Nedostaci FP su:

- teškoća računanja jer različiti ljudi mogu da različito računaju FP i potrebna je vrlo detaljna specifikacija- za razliku od LOC-a ne mogu se automatski računati- neke empirijske studije sugerišu da FP nisu vrlo dobre za predviđanje napora i da su nepotrebno kompleksne - problem sa subjektivitetom tehnološkog faktora- problem sa aplikacionim domenom (komercijalne aplikacije, aplikacije u realnom vremenu, naučne aplikacije)

Očekivani broj linija izvornog koda dobijen iz FP (ili na neki drugi način) omogućava predviđanje drugih karakteristika softvera.

Na osnovu resurs modela , koji se sastoji od empirijskih jednačuna, obično se predviđa:

-E napor u čovjek / mjesecima-D trajanje projekta-DOC broj linija dokumentacije

Međutim, treba imati u vidu da se empirijski podaci dobijaju na osnovu limitiranog i specifičnog broja projekata i resurs model nije odgovarajući za sve klase softvera.

Basili je resurs modele svrstao u četiri klase:

-statički jednovarijabilni model-statički multivarijabilni model-dinamički multivarijabilni model-teoretski model

Statički jednovarijabilni model ima sledeću formu:

resurs = c1 x (očekivane karakteristike) c2

Konstante c1 i c2 se deriviraju iz prethodnih projekata. Kao primjer Pressman Š21Ć navodi studiju Walston-a i Felix-a baziranoj na 60 razvojnih projekata na osnovu kijih su došli do sledećih rezultata, odnosno modela.

E = 5.2 x L0.91

D = 4.1 x L0.36

D = 2.47 x E0.35

S = 0.54 x E0.06

DOC = 49 x L1.01

E, D (trajanje projekta i kalendarsko trajanje projekta) i DOC su izvedeni na osnovu L tj. broja linija izvornog koda u hiljadama.

Alternativno, S (potrebni ljudi) i trajanje projekta mogu biti izračunati iz deriviranog ili predviđenog napora E.

strana 25 od 75

Softverske tehnike

Gornje jednačine se ne mogu uzeti generalno jer zavise od okruženja i specifičnosti aplikacija. Ovakav model se derivira na osnovu lokalnog okruženja i istorijskih podataka.

Ostali tipični modeli su :

E = 5.5 X 0.73 L1.16 (Bailey-Basili model)E = 3.2 X L1.05 (Bohem-ov jednostavni model)E = 3.0 X L1.12 (Bohem-ov srednji model)E = 2.8 X L1.20 (Bohem-ov kompleksni model)E = 5.288 X L 1.047 (Doty model)

Ove modele je veoma teško porediti zbog različitih definicija L (npr. da li su uračunati komentari ili ne) i E (da li se odnosi samo na kodiranje ili i na ostale faze životnog ciklusa softvera).

Upotrebom statičkog jednovarijabilnog resurs modela Schaefer Š21Ć predviđa broj čovjek / mjeseci potrebnih za održavanje softvera godišnje E.maint na sledeći način :

E.maint = ACT x 2.4 x L1.05

gdje se ACT definiše sa :

ACT = ( L - za sistem koji se održava) / CI

pri čemu je CI broj linija koda koje su modifikovane ili dodane za vrijeme jednogodišnjeg održavanja.

Statički multivarijabilni model ima sledeću formu :

resurs = c11 x e1 + c21 x e2 + ...

gdje je ei i-ta softverska karakteristika a ci1 empirijski derivirana konstanta za i-tu karakteristiku softvera.

Dinamički multivarijabilni model projektuje zahtijeve za resursima kao funkciju vremena.

Teoretski model pretpostavlja specifičnu distribuciju napora u toku razvoja projekta i na osnovu toga prati ponašanje resursa.

HALSTEAD-ova METRIKA

Početkom tridesetih godina ovog vijeka G.K. Zipf je razvio teoriju koja opisuje strukturu pisanog ili govornog jezika. Sličnu stvar samo kada su u pitanju

strana 26 od 75

Softverske tehnike

kompjuterski jezici uradio je M. Halstead koji je 1972. godine publikovao teoriju softverske fizike, kasnije preimenovane u softverske nauke, po kojoj algoritam ima karakteristike analogne fizikalnim zakonima.

Prema Halstead-u uloženi napor za razvoj programa može biti izveden iz broja jedinstvenih operatora i operanada i njihovoj ukupnoj frekvenciji. Iz ova četiri kvantiteta može se izračunati broj mentalnih diskriminacija (poredjenja) potrebnih za razvoj programa.

Ako pretpostavimo da je algoritam izražen u nekom programskom jeziku i da se sastoji samo od operatora i operanada tada je :

n1 broj jedinstvenih operatoran2 broj jedinstvenih operanadaN1 ukupan broj operatoraN2 ukupan broj operanada

Halstead definiše programski riječnik sa :

n = n1 + n2

i dužinu programa sa :

N = N1 + N2

Broj "token-a" ili simbola koji konstruišu program je funkcija od veličine riječnika operatora (n1) i veličine riječnika operanada (n2) tj. Halstead-ova hipoteza je da se N može aproksimirati sa:

NČ = n1log2n1 + n2logn22

Neki autori kao Jansen su pokušavali da N aproksimiraju drugim izrazima npr.

NČ = log2n1! + log2n2!

koji je za njihove podatke bio bolja aproksimacija. Pošto je veličina programa odredjena sa podacima koje on mora procesirati Gahhney smatraju da u očekivanju broja "token-a" N, n1 ne mora biti poznat i da faktor n1logn1 može biti izostavljen, normalno uzrokujući neki stepen greške. Dalje pojednostavljenje

je da se umjesto n2 koristi potencijalni broj jedinstvenih ulaza i izlaza n2* koji je lako odreditiu ranoj fazi eksternog projektovanja.

Harrison i Miluk umjest NČ (nominalne dužina) sugerišu novu metriku ANL (Adjusted Nominal Length) koja se računa po formuli :

ANL = (n1 / N1) * NČ

strana 27 od 75

Softverske tehnike

i koja treba da omogući distribuciju sa manje varijabiliteta u odnosu na metriku LOC i može poslužiti kao stabilna baza za konstrukciju modela veličine softvera.

Veličina programa (volumen) preko V metrike se definiše sa:

V = Nlog2n

i predstavlja veličinu implementacije izraženu preko broja bitova koji su potrebni da se enkodira čitav modul.

Potencijalna veličina algoritma V* se odnosi na minimalnu reprezentaciju algoritma u jeziku u kome su zahtijevane opercije definisane i implementirane i data je sa :

V* = n*log2n*

pri čemu je

n* = n1* + n2* ³ 2 + n2*

n2* je broj ulaznih i izlaznih parametara algoritma, u minimalnoj formi broj operatora je 2, ime algoritma i () i sada je :

V* = (2 + n2)log2(2 + n2)

Nivo programa L se definiše kao odnos potencijalne (minimalne) veličine i veličine stvarne implementacije programa:

L = V* / V

Najviši nivo je 1 tj. što je V veći nivo programa je manji. Zbog poteškoća u

računanju V* nivo programa L može biti aproksimiran sa :

LČ = 2n2 / n1N2

Nivo programa zavisi od kompleksnosti programskog jezika, kompleksnosti operatora i kompleksnosti struktura podataka što je i pokazano na sledećim primjerima. Prvi faktor 2 / n1 se povećava sa upotrebom kompleksnijh programskih struktura jer se smanjuje n1. Drugi faktor n2 / N2 se povećava zbog zahtijeva za manje varijabli. Sa svakom eliminisanom varijablom, n2 se smanjuje za 1 ali se istovremeno smanjuje i N2 i to za 1 ili više. Npr. ako imamo programski odsječak (primjer 1.) koji simulira DO petlju sa IF naredbom:

primjer 1.i=1

10 if(i.gt.n) goto 20

strana 28 od 75

Softverske tehnike

...

...i=i+1go to 10

20 continue

operatori i operandi su dati u Tabeli 2.4.

operatori br.pojavljivanja operandi br.pojavljivanja= 2 i 4.gt. 1 n 1+ 1 1 2If 1 10 1Goto 2 20 1Continue 1n1=6 n2=5 N2=9

Tabela 2.4 Operatori i operandi za primjer 1.

LČ = (2/6)*(5/9)=10/54=0.18

Ako ovo izvedemo sa petljom (primjer 2.) imamo sledeću situaciju :

primjer 2.

for i = 1 to n......next i

operatori br.pojavljivanja operandi br.pojavljivanjafor 1 i 1= 1 1 1to 1 n 1next 1n1=4 N1 = 4 n2=3 N2=3

Tabela 2.5 Operatori i operandi za primjer 2.

LČ = (2/4)*3/3) = 0.5

Ako se povećava kompleksnost operatora smanjuje se njihov broj i faktor 2/n1 se povećava. Takođe potrebno je i manje operanada pa je faktor n2/N2 u direktnoj relaciji sa kompleksnošću operatora iz istih razloga kao kod kompleksnosti programa odnosno programskog jezika.

strana 29 od 75

Softverske tehnike

Ako se algoritmom rješava kvadratni korijen sume dva ulazna parametra

tada je n2*=3 i potencijalna veličina programa je :

V* = (2+3)log2(2+3) = 11.61

U slučaju da u nekom jeziku to napišemo (primjer 3.) kao :

primjer 3.

sum (p1,p2,t)sqrt (t,r)

imamo sledeću situaciju :

operatori br.pojavljivanja operandi br.pojavljivanjasum 1 p1 1sqrt 1 p2 1( 2 t 2) 2 r 1, 3n1=5 N1=9 n2=4 N2=5

Tabela 2.6 Operatori i operandi za primjer 3.

V3 = (9+5)log2(5+4) = 14log29

Kada bi operator bio još kompleksniji (primjer 4.) dobili bi smo sledeću situaciju :

primjer 4.

sqrsum (p1, p2, r)

operatori br.pojavljivanja operandi br.pojavljivanjasqrsum 1 p1 1( 1 p2 1, 2 r 1) 1n1=4 N1=5 n2=3 N2=3

Tabela 2.7 Operatori i operandi za primjer 4.

V4 = (3+5)log2(4+3) = 8log27

Ako sada izračunamo nivo programa za različite kompleksnosti operatora u gornja dva slučaja imamo:

L3 = V*/ V3 = 11.61 / 14log29

strana 30 od 75

Softverske tehnike

L4 = V*/ V4 = 11.61 / 8log27

i pošto je 14log29 > 8log27 sledi da je drugi program višeg nivoa od prvog.

Teškoća kodiranja algoritma D se definiše kao :

D=1/L

i može biti očekivana sa :

D2=1/LČ = n1N2/2n2

Christensen, Fistos i Smith su pokazali da n1 ima tendenciju relativne kostantnosti u odnosu na dužinu njihovih programa. Oni smatraju da faktor N2/n2 daje glavni doprinos teškoći kodiranja D2.

Halstead dalje uvodi proizvod IC = L*V za koji smatra da ostaje invarijantan kod translacije iz jednog u drugi jezik. IC definiše kontekst inteligencije algoritma i povećava se sa kompleksnošću rješavanja problema.

Napor da se generiše algoritam E se definiše sa:

E = V / L

i E se povećava za velike programe pisane na nižem programskom nivou. Aproksimacija za E može biti dobijena bez poznavanja potencijalne veličine programa korištenjem LČ umjesto L :

EČ = V / LČ = n1N2V / 2n2 = n1N2Nlog2n / 2n2

EČ definiše produkt polovine jedinstvenih operatora, srednju upotrebu operanada i veličine programa. Ako se N zamjeni sa NČ dobije se :

EČČ = n1N2NČlog2n / 2n2

Pošto je metrika E predstavlja broj mentalnih diskriminacija potrebnih za razumijevanje programa, koristeći tvrdnju psihologa John Stroud-a da je ljudsko biće u stanju da napravi od 5 do 20 elementarnih diskriminacija u sekundi , Halstead smatra da je zahtijvano vrijeme pisanja programa T napora E :

T = E / 18

pri čemu je 18 broj mentalnih diskriminacija u sekundi.Kada su u pitanju gore navedene mjere, sa aspekta teorije mjerenja tj.

odnosa programa i njegovih internih atributa može se zaključiti sledeće:

strana 31 od 75

Softverske tehnike

- Ako je u pitanju dužina programa N, programski riječnik n i volumen programa V, nema kontradikcije za intuitivno razumjevanje relacije program - atribut i može se smatrati da su ova tri interna atributa rezonske mjere za različite aspekte veličine programa. Međutim mnogi ih upotrebljavaju i za mjerenje komleksnosti programa, potpuno različitog atributa.

- Kada su u pitanju ostale mjere onda je pristup problematičan jer su one ništa više nego generalizacija intuitivno neuvjerljivog sistema za predviđanje, naročito kada su u pitanju metrike E i T koje predstavljaju mjere za predviđanje atributa procesa implementacije programa, jer nije uvijek jasno kada proces starta nakon prihvatanja zahtijeva.

Sa aspekta teorije mjerenja u vezi sa dužinom izvornog programskog koda, tj. internog atributa N, rezonski nema kontradikcije intuitivnog razumjevanja relacija programa i atributa.

Halstead-ov rad je veoma važan u istoriji mjerenja softvera iz sledećih razloga:

-to je bio prvi pokušaj deriviranja softverskih metrika baziran na teoriji-to su bile prve metrike koje su pokazale potencijal mjerenja u softveru-to su bile prve metrike uporebljene u industriskom kontekstu-do sredine 80 godina objavljeno je preko stotinu radova na bazi

Halsteadovog rada -zajedno sa McCabe-ovim metrikama još 1984 su upotrebljene od strane

Deborah Bohem-Davis i Lily Ross u studiji za General Electric za OO (Object Oriented) rješenja sa ADA softverom.

Međutim sredinom 80-tih godina ove metrike počinju biti osporavane iz

sledećih razloga:-mnoge pretpostavke bazirane na psihologiji koje je upotrebio Halstead se

smatraju pogrešnim-za mnoge ekspirimente koji su dali impresivne rezultate je ustanovljeno

da su bili statistički pogrešni-uopštenost mjerenja bez orijentacije na posebne zadatke-previše su kodno orijentisane u odnosu na sistemski dizajn i današnji

koncept softverskog inženjeringa-pravila računanja koja su upotrebljena u razvoju metrika nisu potpuno

definisana

2. METRIKE STRUKTURE

Softverski produkt nije karakteriziran samo svojom veličinom nego i svojom strukturom koja ima sledeće atribute: modularnost, povezivanje, koheziju, ponovnu upotrebu, nečistoću stabla, informacioni tok i najbitniji upravljački tok.

Ovi atributi su važni za održavanje, testiranje, ponovnu upotrebu i pouzdanost, odnosno za projektovanje dokumenta i koda.

strana 32 od 75

Softverske tehnike

Postoji nekoliko aspekata strukture ili kompleksnosti koji igraju različite uloge a to su :

-struktura upravljačkog toka-struktura toka podataka-struktura podataka

Predmet ovoga rada je struktura upravljčkog toka. Svaki struktuirani program je napravljen od primitivnih struktura (primova) koji su ustvari gradeći blokovi programa. Dekompozicija programa u njegove primove omogućava razna hijerarhiska mjerenja koja mogu poslužiti za restrukturu programa.

U ovom radu dalje će biti riječi o McCabe-ovoj metrici baziranoj na tome da se struktura upravljačkog toka odnosno kompleksnost programa mjeri ciklomatskim brojem programskog grafa toka.

Važnost i relacije u mjerenju kompleksnosti softvera Š51Ć prikazane su na Slici 2.3.

slika 2.3 Relacije u mjerenju kompleksnosti softvera

Razumljivost se odnosi na sledeće faktore :

-konzistencija-strukturnost-samodokumentovanost-konciznost-čitljivost

strana 33 od 75

KOMPLEKSNOST SOFTVERA

POGODNOST IZMJENE

POGODNOSTTESTIRANJA

RAZVOJ CIJENA

VRIJEME

METRIKA ZA KOMOPLEKSNOT

SOFTVERARAZUMLJIVOST ODRŽAVANJE

POGODNOST ODRŽAVANJA

1 2

3

4

b

a

c d

f

e

ff

e

Softverske tehnike

Pogodnost izmjene se odnosi na :

-strukturnost-argumentovanost

Pogodnost testiranja se odnosi na :

-pristupačnost-komunikativnost-strukturnost-samodokumentovanost

3. McCABE-ova METRIKA

McCabe je krenuo od toga da kompleksnost programa zavisi samo od strukture odluka u programu tj. dodavanje ili oduzimanje funkcionalnih blokova ne utiče na kompleksnost programa. Nezavisnost kompleksnosti od veličine programa je ilustrovana sa tim da program od 50 uzastopnih IF..THEN konstrukcija ima 33.5 miliona različitih upravljačkih puteva od kojih će mali procenat ikada biti testiran .

Osnovni cilj mjerenja kompleksnosti sa McCabe-ovom metrikom je modularizacija softvera tako da rezultatni moduli budu pogodni za testiranje i održavanje što se odražava u uloženom vremenu za razvoj i potrošenom novcu za održavanje. Mjerenje kompleksnosti se satoji u odredjivanju ciklomatičnog broja koji indicira broj linearno nezavisnih upravljačkih puteva u programu. Kombinacijom ovih bazičnih puteva može se dobiti bilo koji put kroz program.

Pošto je McCabe-ova metrika vezana za poteškoće u testiranju programa ona je prezentovana kao mjera za računsku kompleksnost jer se broj upravljačkih puteva indeksiran sa McCabe-ovom metrikom može odnositi i na broj mentalnih diskriminacija (komparacija) koje zahtijeva programski zadatak jer dodatni upravljački putevi mogu učiniti program mnogo težim za razumjevanje.

Ciklomatični broj v(G) grafa sa n čcvorova i e grana i p modula se definiše sa :

v(G) = e - n + 2

U strogo orijentisanom grafu ciklomatični broj je broj linearno nezavisnih petlji. Za programe sa jednim ulazom i jednim izlazom v(G) je jednak broju odluka plus jedan. Za ovakve programe može se konstrusati orijentisani graf u kome svaki čvor odgovara bloku koda a linije sa strelicama odgovaraju granama u programu. Primjer na slici 2.4 koji je McCabe upotrebio u svom originalnom radu Š8Ć ilustruje prirodu v(G).

strana 34 od 75

Softverske tehnike

Slika 2.4 Graf programa

Ako zamislimo da se izlazni čvor (f) grana nazad nas čvor (a) onda je graf strogo usmjeren tj. postoji veza između bilo koja dva čvora u grafu. Npr. broj linearno nezavisnih petlji je 5 i to :

B1: (abefa), (beb), (abea), (acfa), (adcfa)

Iz ovoga slijedi da B1 formira bazu za set svih petlji u G i svaki put u G se može izraziti kao linearna kombinacija petlji iz B1. Npr. put (abeabebebef) se može predstaviti kao :

(abea) + 2(beb) + (abefa)

Ukupna strategija mjerenja kompleksnosti je u tome da se mjeri kompleksnost programa računanjem broja linearno nezavisnih puteva v(G) a da se ”veličina“ oderđuje gornjom granicom v(G) umjesto stvarnom fizikalnom veličinom.

Kao što je već rečeno svaki strukturni program je napravljen od primitivnih struktura odnosno primova koji su gradeći element programa i ako program ima sledeće navedene primove onda je doprinos tih primova ciklomatskom broju sledeći:

sekvenca v(G)=1-2+2=1

IF ..ELSE...ENDIF v(G) = 4-4+2=2

DOWHILEv(G)=3-3+2=2

strana 35 od 75

Softverske tehnike

FOR v(G) = 3-3+2=2

1DOCASE v(G)=N-

1+1 N-broj uslova

Pri računanju v(G) doprinos primitivnih upravljačkih struktura je sledeći :

sekvenca = 1IF = 1DOWHILE = 2FOR = 2CASE = N

Za v(G) vrijedi sledeće :

1. v(G) ³ 1.2. v(G) je maksimalan broj linearno nezavisnih puteva u G.3. Umetanje ili brisanje funkcionalnih naredbi nema efekta na G.4. G ima samo jedan put ako i samo ako je v(G) = 1.5. v(G) zavisi samo od struktura odluka.

Moguća su neka pojednostavljenja u računanju v(G) u odnosu na sintaksu programa ili izgled grafa. Ako se program sastoji od predikata (tačke odlučivanja), funkcionalnih blokova i kolekcionih čvorova, respektivno P, F, K i e je broj grana tada je po Mills-u:

e = 1 + F+ 3P

Pošto svaki predikatni čvor ima samo jedan kolekcioni čvor i postoji samo jedan ulazni i jedan izlazni čvor sledi :

n = F + 2P + 2

Uz pretpostavku da je p = 1 u V = e - n +2 dobije se:

V(1 + F +3P) - (0 + 2P +2) + 2 = P + 1

Iz ovoga sledi da se kompleksnost programa može odrediti brojanjem predikata u programu ne vodeći računa o grafu. Ako imamo graf tada se

strana 36 od 75

Softverske tehnike

kompleksnost određuje vizuelnim putem brojeći regione u grafu što je prikazano na Slici 2.5.

Slika 2.5 Regioni u grafu

U vezi sa testiranjem i održavanjem programa McCabe na bazi empirijske evidencije smatra da kompleksnost programa odnosno njegov ciklomatski broj ne treba da prelazi 10. U ovom kontekstu, v može biti upotrebljen za osiguranje kvaliteta.

Na drugoj strani Grady je 1994. godineu svojoj studiji za HP zaključio da je maksimalni ciklomatiski broj 15 a Bennett takođe 1994. godine da taj broj ne treba da prelazi 20.

Fenton smatra da sa aspekta teorije mjerenja ciklomatski broj ne može biti upotrebljen kao generalna mjera kompleksnosti programa jer nema intuitivnih relacija o kompleksnosti ali da je veoma koristan za testiranje i održavanje.

Na osnovu cikomatskog broja mogu se predvidjeti očekivani troškovi testiranja i održavanja programa i na osnovu toga izabrati jednu od alternativa :

- ponovno pisanje programa u manjim modulima radi lakšeg održavanja - nastaviti započeti posao.

U slučaju prve alternative, reprogramiranje zahtijeva manje vremena odnosno napora nego originalno programiranje i značajni troškovi i vrijeme mogu biti smanjeni u fazi testiranja i održavanja.

Ciklomatski broj je takođe baza za različite strategije za testiranje softvera ali nema konsenzusa koja je najbolja u datoj situaciji. Ove strategije spadaju u dvije kategorije :

- ”black box” testiranje- ”white box” testiranje

strana 37 od 75

1 2

3

4

Softverske tehnike

Prva vrsta podrazumjeva potpuno poznavanje specificiranih funkcija za koje je softver projektovan (ulaz korektno prihvaćen, izlaz korektno proizveden).

Druga vrsta zahtijeva potpuno poznavanje internog rada tj. internih operacija koje se izvode prema specifikacionom zahtijevima.Kod upotrebe “white box” metode testni primjer mora obezbediti sledeće:

- svaki nezavisni put unutar modula mora biti izveden najmanje jednom- sve logičke odluke moraju biti ispitane na obe strane (istinito, neistinito)- petlje se moraju odviti unutar granica- osigurati ispravnost internih struktura podataka

Metoda testiranja baznih puteva, bazirana na ciklomatičnom broju, je “white box” tehnika testiranja. Ova metoda omogućava projektantu testnih primjera da odredi logičku kompleksnost procedure i na osnovu toga definiše set baznih puteva koji garantuje da će svaka naredba u programu biti izvedena najmanje jednom u toku testiranja.

Kada se ciklomatski broj upotrebi u kontekstu metode testiranja baznih puteva tada on predstavlja gornju granicu broja nezavisnih puteva, odnosno broj testova koji se moraju izvršiti da bi svaka naredba bila izvedena jednom i da svaki uslov bude bude izveden na obe strane (istinito, neistinito).

Ako je izračunata kompleksnost programa v i broj testiranih puteva je ac (aktuelana kompleksnost) i ako je ac manje od v tada sledi :

1. više puteva mora biti testirano2. graf toka programa može biti redukovan u kompleksnosti sa v - ac3. dijelovi programa mogu biti redukovani u kodu

Npr. ako se starta sa sledećim programskim grafom:

G:

Slika 2.5 Graf programa

Ako se predpostavi da je ac = 2 i dva puta za testiranje su:

strana 38 od 75

1

@ 3

4

5 6

7

Softverske tehnike

- [ 1, 2, 4, 6, 7 ]- [ 1, 3, 4, 5, 7 ]

tada se ne testiraju putevi:- [ 1, 2, 4, 5, 7 ]- [ 1, 3, 4, 6, 7 ]

i ac < v i dolazi do slučaja 2. i graf G može biti reduciran izbacivanjem odluke 4. što je prikazano na Slici 2.5.

G1:

Slika 2.5. Redukovani graf programa

U grafu G1 v = ac i kompleksnost G1 je manja od kompleksnost G.

Poređenjem aktuelne i ciklomatske kompleksnosti često se otkrivaju dodatni putevi koji nisu testirani i ovakav pristup je vrlo koristan za programera, naročito kada dokumentuje diagram toka, odnosno eksplicitno prikazuje testirane puteve.

Pored gor navedene dvije metrike v(G) i ac(G) McCabe je uveo još niz metrika za kompleksnost softvera :

-iv(G) - metrika kompleksnosti projektovanja modula koja kvantificira ciklomatsku kompleksnost strukture modula u odnosu na pozive drugih modula.

-ev(G) - metrika esencijalne kompleksnosti koja mjeri stepen nestruktuiranih konstrukcija.

-pv(G) - metrika patološke kompleksnosti koja mjeri stepen ekstremno ne struktuiranih konstrukcija.

strana 39 od 75

1

2 3

5 6

7

Softverske tehnike

-SO - metrika kompleksnosti projektovanja koja mjeri interakciju između modula u sistemu.

-S1 - metrika kompleksnosti integracije koja mjeri količinu inetgracionog testiranja potrebnog za zaštitu od grešaka.

-OS1 - metrka kompleksnosti integracije objekata koja kvantificira broj testova za potpunu integraciju objekata ili klasa u OO sistemu.

-gdv(G) - metrika globalne kompleksnosti podataka koja kvantificira ciklomatsku kompleksnost strukture modula u odnosu na globalne/parametarske podatke. Ona ne može biti manja od jedan i ne veća od ciklomatske kompleksnosti originalnog grafa toka.

PROBLEMI SA GENERALNIM METRIKAMA “KOMPLEKSNOSTI “

Kompleksnost programa je kombinacija više atributa (razumljivost, korektnost, pogodnost održavanja, pouzdanost, pogodnost testiranja i lakoća implementacije) i teško je pronaći metriku koja karakteriše veliku kolekciju tih različitih atributa jer mjerenja često imaju različite ciljeve. Svaki od ovih atributa treba posmatrati separatno da bi se egzaktno razumjelo koliko je koji atribut odgovoran za ukupnu kompleksnost.

Iako eksterna mjerenja imaju najveći uticaj na ciklus razvoja softvera ona su teža za kvantificiranje nego interna. Kao rezultat toga, istraživači pokušavaju da naprave dobra interna mjerenja i dođu do korelacija između internih i eksternih mjerenja preko empirijskih studija. Međutim ne postoji sistematski način za upotrebu ovih studija u selekcionom procesu .

Jedan od prilaza je bio da se razvije formalni aksiomatski model komleksnosti od kojih je jedan od najpoznatiji Weyuker-ov model Š16Ć. Weyuker je predložila devet aksioma (svojstava, kriterija) koje treba da zadovolji bilo koja “dobra “ metrika kompleksnosti. P, Q i R su bilo kakvi programski blokovi a M metrika kompleksnosti.

Svojstvo 1 : Postoje programi P i Q za koje je M(P) M(Q).

Svojstvo 2 : Ako je c ne negativan broj tada postoji samo konačano mnogo programa P za koje je M(P) = c.

Svojstvo 3 : Postoje različiti programi P i Q za koje je M(P) = M(Q).

Svojstvo 4 : Postoje funkcionalno ekvivalentni prograni P i Q za koje je

strana 40 od 75

Softverske tehnike

M(P) M(Q)

Svojstvo 5 : Za bilo koje programe P i Q vrijedi M(P) M(P+Q) i M(Q) M(P+Q)

Svojstvo 6 : Postoje programi P, Q i R za koje vrijedi M(P) = M(Q) i M(P+R) M(Q+R)

Svojstvo 7 : Postoje programi P i Q i Q je formiran permutacijom redosleda statement-a P i M(P) M(Q).

Svojstvo 8 : Ako je P preimenovani Q tada je M(P) = M(Q).

Svojstvo 9 : Postoje programi P i Q za koje vrijedi M(P) + M(Q) < M(P+Q).

Uzimajući u obzir četiri sintaktičke metrike kompleksnosi i njihovo zadovoljavanje predloženih svojstva Weyuker je došla do sledećih rezultata prikazanih u Tabeli 3.7.Svojstvo br. br. statement-a ciklomatski broj napor E tok podataka1 DA DA DA DA2 DA NE DA NE3 DA DA DA DA4 DA DA DA DA5 DA DA NE NE6 NE NE DA DA7 NE NE NE DA8 DA DA DA DA9 NE NE DA DA

Tabela 3.7 Metrike i njihova svojstva

Weyuker-ova svojstva predstavljaju osnovu za komparaciju i vrednovanje metrika kompleksnosti na formalan način. Međutim često su kritikovana. Zuse je 1992. godine upotrebio reprezentativnu teoriju mjerenja da bi dokazao da su neka od svojstava (svojstvo 5 i 6) kontradiktorna.

Svojstvo 5 podrazumjeva da dodavanje koda programu ne smanjuje kompleksnost programa. Sa stanovišta ovoga svojstva veličina programa je ključni faktor kompleksnosti. Iz svojstva 5 se takođe može zaključiti da niska razumljivost nije ključni faktor jer postoji vjerovanje da u izvjesnim slučajevima program lakše može razumjeti ako se vidi što više programa.

Na drugoj strani svojstvo 6 podrazumjeva da se mogu naći dva programa jednake kompleksnosti koja odvojeno konkatirana sa istim trećim programom rezultiraju programima različitih kompleksnosti. Ovo svojstvo je više vezano za razumljivost a malo sa veličinu.

strana 41 od 75

Softverske tehnike

Dakle, svojstva 5 i 6 su važna za vrlo različite i inkompatibilne poglede na kompleksnost. Oba ne mogu biti zadovoljena sa jednostavnim mjerenjem koje obuhvata veličinu i nisku razumljivost. Zuse pojačava inkompatibilnost formalnom tvrdnjom da svojstvo 5 eksplicitno zahtijeva odnosnu skalu mjerenja dok ju svojstvo 6 eksplicitno isključuje.

Cherniavsky i Smith takođe kritikuju Weyuker-ove aksiome. Oni su defenisali kodno-baziranu metriku koja zadovoljava sva Weyuker-ova svojstva ali koja po njihovoj tvrdnji nije senzibilna mjera kompleksnosti i da aksiomatski prilaz nije dobar.

Međutim, Fenton smatra da su Cherniavsky i Smith korektno pronašli probleme sa Weyuker-ovim aksiomima ali da nisu dokazali svoj zaključak o aksiomatskom pristupu. Oni nisu uzeli u obzir da je Weyuker-ova preporučila da su njeni aksiomi potreban ali i ne dovoljan uslov. Nadalje metrika Cherniavsky i Smith nije realna metrika u odnosu na teoriju mjerenja i ne obuhvata specifične atribute.

Traženje generalne mjere za kompleksnost softvera je pogrešno. Međutim, teorija pomaže da se definiše i potvrdi mjerenje specifičnih atributa kompleksnosti jer je kompleksnost intuitivni atribut kiji uključuje specifične interne atribute. Dakle, treba identifikovati specifične atribute od interesa i izvršiti tačna mjerenja i u kombinaciji dobiti kompletnu sliku kompleksnosti.

strana 42 od 75

Softverske tehnike

2.6 OBJEKTNO-ORIJENTISANE SOFTVERSKE METRIKE

2.6.1 UVOD

U poslednjoj dekadi značajno je porasla popularnost Objektno-Orijentisane (OO) tehnologije i mnoge kompanije su je uvele u svoje okruženje za razvoj softvera. OO Analiza (OOA), OO Dizajn (OOD), OO Programiranje (OOP) su postali popularni kako u velikim tako i u malim kompanijama. Uvođenje OO tehnologije je postao veliki izazov za kompanije koje su upotrebljavale metrike produkta za praćenje, upravljanje i poboljšanje u razvoju i održavanju softvera.

Prethodne, tradicionalne metrike su često bile subjekt jednog ili više tipova kritika. Ove kritike su se odnosile na :

-nedostatak teoretske baze-nedostatak poželjenih mjernih svojstava-nedovoljna generalizacija-velika zavisnost od implementacione tehnologije-radno intezivne za prikupljanje

Zbog specifičnosti OO sistema (lokalizacija, enkapsulacija, sakrivanje informacija, nasleđivanja i apstrakcije) većina tradicionalnih metrika produkta nije dovoljna za karakterizaciju, procjenu i predviđanje kvaliteta OO softverskog sistema. Uvođenje nove tehnologije je dovelo do razvoja i implementacije novih metrika (OO metrika) specijalno dizajniranih za mjerenje jedinstvenih aspekata OO sistema.

Mnogo novih OO metrika je predloženo od strane mnogo autora i osnovni izazov je bio da te metrike imaju podlogu u teoriji i da budu relevantne za praktičare. Uprkos velikom intersu u početku, malo empirijskih podataka za komercijalno orijentisane OO aplikacije je publikovano u literaturi.

CHIDAMBER-KEMERER-OVE METRIKE ZA OOD

Jedne od najpoznatijih OOD metrika su Chidamber-Kemerer-ove metrike (šest metrika) definisane 1994. Autori su krenuli od toga da predlože metrike:

-koje imaju čvrstu bazu u teorijskim konceptima mjerenja i ontologiji objekata.

-koje inkorporiraju iskustvo profesionalih istraživaža-koje su vrednovane prema odgovarajućim kriterijma

strana 43 od 75

Softverske tehnike

-koje prezentuju empirijske podatke iz komercijalnih projekata da ilustruju karakteristike ovih metrika na realnim aplikacijama i način njihove

upotrebe.

Ove metrike se odnose na procjenu dizajna OO sistema a ne na njegovu specifičnu implementaciju i prema tome mogu biti prihvatljive širokom nizu korisnika.

Baza za empirijski relacioni sistem je set ontoloških principa predložen od Bunge-a 1979 god. a od strane Yand-a i Webera primjenjen na OO sisteme 1990 god. Ovdje se svijet sastoji od substancionalnih individuala koji posjeduju konačan skup svojstava. Zajedno, substancionalni individuali sa svojim svojstvima, konstituišu objekt. Klasa je skup objekata koji imaju zajednička svojstva a metod je operacija na objektu definisan kao dio deklaracije klase.

Objekt može biti reprezentovan na sledeći način:

X = (x, p(x)) gdje su :

- x supstancionalni individual- p(x) konačan skup svojstava

Upotrebom Bunge-ovih ontoloških termina definisani su atributi kao couplig (povezivanje), kohezija (unutrašnja funkcionalna snaga), kompleksnost objekta i skup svojstava važnih za OO sisteme.

Coupling

Ako imamo dva objekta X = (x, p(x)) i Y = (y, p(y)) i

p(x) =[MX] U [IX]p(y) = [My] U [Iyć]

gdje je [Mi] skup metoda i [IX] skup varijabli instace objekta.

Upotrebom gornje definicije coupling, bilo koja akcija od [MX] na [My] ili [Iy] konstituiše coupling, isto vrijedi za bilo koju akciju [My] na [Mx] ili [Ix]. Kada Mx

poziva My, Mx mjenja istoriju upotrebe My. Isto tako kada Mx upotrebljava Iy on mjenja pristup i istoriju upotrebe Iy. Nadalje, bilo koja evidencija da metod jednog objekta upotrebljava metode ili varijable instance drugog metoda konstituiše coupling. Dvije klase su povezane kada metode deklarisani u jednoj klasi upotrebljavaju metode i varijable instance druge klase.

Kohezija

Drugi važan atribut za koncept dizajniranja softvera je kohezija. Stepen sličnosti metoda M1 i M2 se definiše na sledeći način:

(M1,M2) = [I1] [I2]

strana 44 od 75

Softverske tehnike

Stepen sličnosti metoda je glavni aspekt kohezivnosti. Ako klasa ima različite metode koje izvode različite operacije na istom setu varijabli instance onda je klasa kohezivna.

Dobar dizajn softvera pretpostavlja minimizaciju coupling-a i maksimizaciju kohezije.

Kompleksnost objekta

Kompleksnost objekta se svodi na to da kompleksni individual ima više svojstava. Uzimajući ovo u obzir kompleksnost objekta se defiše kardinalitetom seta njegovih svojstava tj. kompleksnost (x, p(x)) = p(x) pri čemu je p(x) kardinalitet od p(x).

Obim svojstava

Prilikom dizajniranja hijerarhije klasa odnosno hijerarhije nasleđivanja nephodno je voditi računa o restrikciji ili ekspanziji obima svojstava klasa objekata u aplikaciji. Dvije stvari koje utiču na hijerarhiju nasleđivanja su dubina nasleđivanja i broj neposrednih potomaka koje ima klasa. Dubina nasleđivanje se definiše kao dužina maksimalnog puta od čvora do krijena u stablu nasleđivanja. Broj djece se definiše kao broj neposrednih naslednika. Dubina nasleđivanja indicira koliko je klasa influencirana svojstvima svojih predaka a broj neposrednih potomaka indicira potencijalni uticaj na potomke.

Na osnovu gornjih definicija predloženo je šest metrika koje su vrednovane prema devet Weyuker-ovih kriterijia. Sve metrike zadovoljavaju drugi kriterij. Sedmi kriterij (permutacija elemenata) je značajan za tradicionalne programske jezike ali ne i za OOD jer npr. redoslijed metoda ne utiče na njihovo izvođenje.

Metrika 1: Weighted Methods per Class (WMC)

Metrika WMC (težina metoda po klasi) se odnosi na kompleksnost. Ako se posmatra klasa C sa metodama M1........Mn koje su definisane u klasi i imaju kompleksnost c1......cn tada je:

WMC = ci i=1,........,n

Ako sve metode imaju istu kompleksnost tada je WMC = n tj. broj metoda.

Broj i kompleksnost metoda može poslužiti kao prediktor napora i vremena za razvoj i održavanje klase. Veliki broj metoda u klasi utiče na djecu koja mogu da naslijede sve metode definisane u klasi. Klase sa velikim brojem metoda su obično aplikacijski specifične i na taj način mogu da smanje mogućnost ponovne upotrebe (reuse) i sklonije su greškama. Za težine u ovoj metrici Li i Henry su uzeli McCabe-ov ciklomatski broj. Na bazi empirijske studije i regresione analize oni su zaključili da je ova mjera upotrebljiva.

strana 45 od 75

Softverske tehnike

Ova metrika ne zadovoljava jedino deveti Weyuker-ov kriterij jer za bilo koje dvije klase P i Q vrijedi:

np + nq - c np + nq pri čemu je c broj zajedničkih metoda

M(P + Q) M(P) + M(Q)

i ovo ne zadovoljava spomenuti kriterij.

Metrika 2: Depth of Inheritence Tree (DIT)

U OOD aplikacioni model se modelira kao hijerarhuja klasa. Ova hijerarhija se reprezentuje kao stablo nasleđivanja. Čvorovi u stablu reprezentuju klase i za svaku takvu klasu DIT (dubina stabla nasleđivanja) metrika predstavlja dužinu maksimalnog puta od čvora do korijena stabla. Teoretska osnova za ovu klasu je Bunge-ov obim svojtava.

Što je klasa dublje u hijerarhiji nasleđuje više metoda i postaje kompleksnija, ima veći potencijal ponovne upotrebe i sklonija je grešci.

Ova metrika ne zdovoljava peti Weyukerov kriterij u slučaju da je P ili Q neposredni potomak jedan drugom. U ovom slučaju M(P) = n, M(Q) = n + 1 ali je M(P + Q) = n i M(P + Q) < M(Q) što ne zadovoljava spomenuti princip.

Takođe nije zadovolje i deveti kriterij. Za bilo koje dvije klse P i Q, M(P + Q) = M(P) ili M(P + Q) = M(Q) što ne zadovoljava navedeni kriterij.

Metrika 3: Number of Children (NOC)

Metrika NOC (broj djece) predstavlja broj neposrednih naslednika klase odnosno to je mjera koja pokazuje koliko neposrednih potomaka namjerava da nasledi metode roditeljske klase. Što je veći broj neposrednih potomaka veća je ponovna upotreba. Klasa sa velikim brojem neposrednih potomaka je teža za modifikaciju i obično zahtijeva više testiranja jer klasa potencijalno utiče na sve neposredne potomke.

NOC metrika ne zadovoljava deveti Weyukero-v kriterij. Za dvije klase P i Q sa np i nq djece, respektivno vrijedi sledeće:

M(P) = np i M(Q) = nq

M(P +Q) = np + nq - c pri čemu je c broj zajedničkih potomaka M(P + Q) M(P) + M(Q) što ne zadovoljava pomenuti kriterij.

Metrika 4: Coupling Between Object classes (CBO)

strana 46 od 75

Softverske tehnike

Metrika CBO (povezivanje između klasa objekata) predstavlja broj drugih klasa sa kojima je data klasa povezana. Dvije klase su povezane kada metode deklarisane u jednoj klasi upotrebljavaju metode ili varijable instace deklarisane u drugoj klasi. Visoko povezane klasa su teže za održavanje i zahtijevaju rigoroznije testiranje i nisu pogodne za modularizaciju i ponovnu upotrebu.

I ova metrika ne zadovoljava deveti Weyuker-ov kriterij. Za bilo koje dvije klase P i Q, M(P + Q) = np + nq - c pri čemu je c broj povezivanja redukovan zbog kombinacije.

M(P + Q) = M(P) + M(Q) - c i M(P + Q) M(P) + M(Q) što ne zadovoljava kriterij devet.

Metrika 5: Response For a Class (RFC)

Metrika RFC (odziv za klasu) predstavlja broj lokalnih metoda plus broj metoda pozvanih od lokalnih metoda. Veliki broj metoda pozvanih da odgovore na poruku povećavaju kompleksnost klase i otežavaju testiranje i otklanjanje grešaka.

I ova metrika ne zadovoljava Weyuker-ov kriterij devet. Za bilo koje dvije klase P i Q vrijedi:

M(P+Q) = M(P) + M(Q) - c pri čemu c predstavlja zajedičke metode upotrebljene od P i Q.M(P+Q) M(P) + M(Q) što ne zadovoljava deveti kriterij.

Metrika 6: Lack Of Cohesion in Methods (LCOM)

Metrika LCOM (nedostatak kohezije u metodi) predstavlja broj parova metoda koje nemaju zajedničkih varijabli instance minus broj parova metoda koje imaju zajedničke varijable instance. Ova metrika se postavlja na nulu kada je rezultat oduzimanj negativan. Klase sa niskom kohezijom ukazuju na neodgovarajući dizajn, veću kompleksnost i mogućnost podjele u podklase.

LCOM metrika ne zadovoljava peti i deveti Weyukerov kriterij. Npr. ako P ima tri metode od kojih jedna nema zajedničkih varijabli sa ostale dvije koje imaju zajedničke varijable tada je LCOM = 1. Ako Q ima tri metode sa zajedničkim varijablam instance tada je LCM = 0. Ako kombinujemo P i Q i pri tome su varijable instance Q jednake varijablama iz P koje su zajedničke za metode tada je LCOM = 0 jer broj nepraznih intersekcija premašuje broj praznih i M(P + Q) M(P) što ne zadovoljava peti kriterij.

Za bilo koje dvije klase P i Q, M(P +Q) = np + nq - c i M(P + Q) M(P) + M(Q) što ne zadovoljava deveti kriterij.

strana 47 od 75

Softverske tehnike

Svih šest metrika u glavnom zadovoljavaju sve Weyuker-ove kriterije sa jednim strogim izuzetkom: kriterij 9 (interakcija povećava kompleksnost). Ako se izostavi kriterij devet, sledi da se metrike kompleksnosti mogu povećati, prije nego smanjiti ako se klasa podijeli u više klasa, što se pokazalo i u praksi. Sa aspekta teorije mjerenja metrike koje zadovoljavaju deveti kriterij ne mogu biti mjerene na intervalskoj ili odnosnoj skali tj. takve metrike ne mogu dati sud da je klasa A dva puta kompleksnija od klase B. Zadovoljenje devetog kriterija nije esencijalno za OOD metrike kompleksnosti i ne zadovoljavanje ovog kriterija može biti uzeto kao prednost a ne kao nedostatak za široku upotrebu ovih metrika.

Sledeće odstupanje je od kriterija pet (monotonost) u slučaju metrika DIT i LCOM. DIT metrika ne zadovoljava ovaj kriterij samo kada su klase u odnosu roditelj-dijete. Ovo je zbog toga što distanca roditelje od korijena ne može biti duža nego distanca od korijena do dijeteta. I LCOM metrika u nekim uslovima kombinacija klasa ne zadovoljava peti kriterij.

Ovih šest metrika mogu biti upotrebljene i za:

-vrednovanje različitih OO metodologija.

-analiziranje razlika između različitih OO jezika i okruženja.

-analiziranje stepena u kome metrike koreliraju sa dizajnom, naporom za testiranje i održavanje, kvalitetom i sistemskim performansama.

-pravljenje kompromisa između konfliktnih zahtijeva kao što su povećanje

ponovne upotrebe (preko više nasleđivanja) i lakoće testiranja (preko manje komplikovane hijerarhije nasleđivanja.

-identifikacuju dijelova aplikacije koji zahtijevaju rigoroznije testiranje i dijelova koji su kandidati za redizajniranje.

Sami autori ovih metrika smatraju da i dalje treba raditi na njihovoj nadogradnji, izmjenama i mogućim brisanjima. Ove metrike takođe mogu poslužiti istraživačima kao baza za razvoj specijalizovanih metrika za posebne namjene.

I ove metrike su bile predmet određenih kritika. Iako je upotreba ovih metrika obećavajuća još nema široke saglasnosti šta treba mjeriti u OO sistema i koje su metrike odgovarajuće. Churcher i Shepperd kritikuju Chidamber-Kemerer-ove metrike na temelju toga da ne postoji konsenzus o temeljnim atributima. Npr. oni tvrde da je čak i zamisao “metoda po klasi” dvosmislena.

2.6.3 LORENZ-ove OO METRIKE

Prvu knjigu o OO-metrikama objavio je Lorenz 1994. U ovoj knjizi je prikazano oko 40 metrika koje su podjeljene na metrike procesa i metrike dizajna. Ove metrike su uglavnom namjenjene praktičarima i po riječima autora nisu zasnovane na matematičkim dokazima i teoriji.

strana 48 od 75

Softverske tehnike

Projektne metrike su upotrebljavaju za predeviđanje potreba projekta kao što su nivo personala i ukupni napor. One takođe treba da mjere dinamičke izmjene u projektu kako bi se znalo šta je urađeno a šta je ostalo da se uradi. Ove metrike su više globalne i manje specifične od metrika dizajna. Lorenz ih je svrstao u tri kategorije:

-veličina aplikacije obuhvata metrike upotrbljene za mjerenje obima posla na projektu. Tipične metrike su broj scenario skriptova, broj ključnih klasa, broj podržanih klasa, broj podsistema.

-veličina personala obuhvata metrike koje treba da odgovore na pitanje o broju potrebnih ljudi, o vremenu njihovog angažovanja itd. Tipične metrike ove kategorije su broj ljudi/dana po klasi, broj klasa po programeru itd.

-raspored po kome se odvija projekt obuhvata metrike koje treba da daju odgovor koliko je iteracija urađeno, odnosno koliko je ostalo da se uradi. Tipične metrike su broj glavnih iteracija, broj kompletiranih ugovora.

Metrike dizajna obuhvataju :

-veličinu metode može biti mjerena na više načina. Metrike u ovoj grupi se odnose na kvantificiranje idividualnih metoda i to su broj poruka poslatih metodi, broj linija koda.

-interne karakteristike metoda predstavljaju metrike kao što su kompleksnost metode. Kompleksnost metode Lorenz računa sa sledećim težinama:

-API pozivi 5.0-pridruživanje 0.5-binarni izrazi (Smaltalk) ili aritmetički operatori (C++) 2.0-poruke sa parametrima (C++) 3.0-ugnježdeni izrazi 0.5-parametri 0.3-primitivni pozivi 7.0-privremene varijable 0.5-poruke bez parametara 1.0

Lorenz iz iskustva sa mnogo projekata predlaže 65 kao prag vrijednosti.

-veličina klase obuhvata metrike koje se bave kvantifikacijom individualnih klasa. Tipične metrike su broj javnih metoda, broj metoda instance u klasi, broj varijabli instance u klasi itd.

-nasleđivanje klasa obuvata metrike kao što su dubina klase i višestruko nasleđivanje.

strana 49 od 75

Softverske tehnike

-nasleđivanje metoda obuhvata metrike koje se bave relacijama nasleđivanja superklasa-podklasa.

-interne karakteristike klase obuhvataju metrike koje se bave kohezijom.

-eksterne krakteristike klase obuvataju metrike povezivanja, ponovne upotrebe i kolaboracije.

Za svaku metriku Lorenz je dao ime, značenje, rezultate iz prethodnih projekata, djelovanje, metrike sa kojima je u vezi, prag vrijednosti i sugerisao akciju.

2.6.4 McCABE-ove OO METRIKE

Pored već spemenute metrike OS1 (Object Inegration Complexity Metric) koja kvantificira broj testova potrebnih za potpunu integraciju objekata i klasa u OO sistem McCabe je uveo i sledeće metrike koje se odnose na enkapsulaciju, polimorfizam i kvalitet.

ENKAPSULACIJA

-Procenat javnih (public) podataka (PCTPUB). Ova metrika predstavlja procenat javnih i zaštićenih (protected) podataka unutar klase.

-Pristup javnim podacima (PUBDATA) . Ova metrika predstavlja broj pristupa javnim i zaštićenim podacima.

POLIMORFIZAM

-Procenat neisprepletanih (unoverloaded) poziva (PCTCALL) Ova metrika predstavlja broj neisprepletanih poziva u sistemu.

-Broj korijena (ROOTCNT). Ova metrika predstavlja ukupan broj korijena u programu.

-Fan-in (FANIN). Ova metrika predstavlja broj klasa iz kojih je klasa izvedena.

KVALITET

-Maksimalni v(G) (MAXV). Ova metrika predstavlja maksimalnu vrijednost ciklomatskog broja za metodu u klasi.

-Maksimalni ev(G) (MAXEV). (Ova metrika predstavlja maksimalnu vrijednost esencijalne kompleksnosti za metodu u klasi.

-Kvalitet hijerahije (QUAL). Ova metrika predstavlja broj klasa u sistemu koje zavise od svojih naslednika.

strana 50 od 75

Softverske tehnike

Neki autori, kao npr. Lorenz smatraju da v(G) nije odgovarajuća metrika za kompleksnost OO sistema. Razlog za to vidi u kratkoći metoda (manje od 6 linija) i u tome da dobro dizajnirani OO sistemi ne upotrebljavaju CASE naredbe i da je uptreba IF naredbe znatno smanjena. Što je bolji dizajn sistema tradicionalna mjera komleksnosti je manje upotrebljiva.

Sa druge strane za težine u WMC metrici Li i Henry su uzeli McCabe-ov ciklomatski broj. Na bazi empirijske studije i regresione analize oni su zaključili da je ova mjera upotrebljiva u OO sistemima .

Fetcke smatra da se tradicionalne metrike iz proceduralnog domena koje se odnose na upravljački tok mogu primjeniti za metode jer u većini OO modela metode su konstruisane kao subrutine.

OSTALE OO METRIKE

Pored već navedenih postoji još niz ostalih OO metrika i njihovih podjela. Bellin dijeli OO metrike u tri grupe:

-Prva grupa sadrži statističke aspekte OO dizajna dobijene statičkom analizom izvornog koda. Pored već spominjanih metrika tu su još odnos dubina/širina hijerarhuje klasa, odnos metode/klasa, odnos privatne/javne meode, odnos broj linija koda/metoda, odnos broj linija koda/broj komentara itd.

-Druga grupa se fokusira na ponovnu upotrebu koda u vezi sa efektima na OO razvojni proces. Te metrike obuhvataju broj ponovo upotrebljenih klasa i procenat modifikovanih ponovo upotrebljenih klasa.

- Treća grupa se odnosi na subjektivne aspekte OO programiranja. kao što su povezivanje, kohezija itd.

Od posebno interesa kada su u pitanju kvalitet i produktvnost u OO sistemima je ponovna upotreba. Glavna motivacija za ponovnu upotrebu softvera (pored koda tu su uključeni zahtijevi, dizajn, dokumentacija, testni podaci i skriptovi) je smanjivanje cijene razvoja, skraćivanje vremenskog ciklusa i smanjenje ljudskog napora za razvoj softverskog produkta.

Da bi se mjerila ponovna upotreba prvo je potrebno definisat metriku Size (veličina). Veličina sistema S je funkcija Size(S) i ona ima tri svojstva. Prvo, Size ne može biti negativan. Drugo, očekuje se da bude nula kada sistem ne sadrži ni jednu komponentu i treće, kada komponente nemaju zajedničkih elemenata za Size se očekuje da bude aditivan.

Ako pretpostavimo operator Components :

strana 51 od 75

Softverske tehnike

Components (S) = [C1,.......Cn] takav da ako je Ci = Cj tada je i = j za i,j = 1,...,n

Veličina sistema S je data sledećom funkcijom:

Size (S) = Size (c) c Components

gdje Size (c) može biti definisan kao broj izvornih linja koda komponente c.

“Količina” ponovo upotrebljenog koda u sistemu S je funkcija Reuse (S) koja takođe ima tri prethodna svojstva tj. Reuse je instanca metrike veličine. Reuse ne može biti negativan, nula je kada sistem ne sadrži ni jedan ponovo upotreblje element i kada ponovo upotrebljene komponente nemaju zajedničkih ponovo upotrebljenih elementa Reuse je aditivna.

Priliko definisanja Reuse (S) mora se voditi računa o specifičnostima OO koncepta kao što su klase i nasleđivanje. Postoji nekoliko slučajeva:

1. kod je ponovno upotrebljen bez ikakvih izmjena (npr. klasa C pripada biblioteci). u tom slučaju je:

Reuse (C) = Size (C)

2. Klasa C je kreirana modifikacijom egzistirajuće klase EC i tada je:

Reuse (C) = %Change * Size (C)

gdje %Change predstavlja procenat obrisanog ili modifikovanog C.

Ove podatke je teško dobiti i radi pojednostavljenja uzima se prag od 25%. Ako su izmjene manje od 25% takve izmjene se smatraju neznatnim a ako su veće onda se smatraju ekstezivnim. Kada se radi na nivou projekta upotrebljava se sledeća aproksimacija:

-ekstezivna modifikacija Reuse (C) = 0-neznatna modifikacija Reuse (C) = Size (C).

3. C je kreiran bez upotrebe bilo kakvog prethodnog koda. U ovom slučaju je:

Reuse (C) = 0.

I na kraju odnos ponovne upotrebe i veličine je dat sa:

ReuseRate (S) = Reuse (S) / Size (S) 0 ReuseRate (S) 1.

EMPIRIJSKA ISTRAŽIVANJA

strana 52 od 75

Softverske tehnike

Empirjska istraživanja prestavljaju praktičnu vezu koja je odnosi na

hipotezu u realnom svijetu i njeno testiranje sa empirijskim podacima.

Nakon odluke šta se želi istraživati, u ovom slučaju 4GL (CLIPPER) a entiteti od interesa su veličina i kompleksnost, postavlja se cilj istraživanja i on odeređuje tehniku ( “case study” ), a izražen je kao hipoteza koja se želi testirati. Primjenom GQM pristupa odeđuju se metrike koje treba da odgovore na pitanja da li je cilj postignut.

Hipoteza u ovom radu je da postoje visoke korelacije tradicionalnih metrika za mjerenje internih atributa softverskih produkata pisanih u 4GL (CLIPPER).

Empirijska istraživanja treba da potvrde ili odbace ovu hipotezu i pored toga odgovore na sledeća pitanja:

1. Koje su to metrike koje dobro koreliraju i kako ih validirati?. 2. Koje su metrike pogodne za vrednovanje razlika između aplikacija i programera?.3. Koje metrike su pogodne za izgradnju predikcionog sitema veličine produkta?.3. Kako izvršiti redukciju broja metrika odnosno smanjiti njihov dimenzionalitet?.

U sledećim poglavljima je prikazano kako su sakupljeni podaci, kako je projektovan mjerni sistem i kako je izvršena analiza rezultata.

KONCEPTI I METODE PROGRAMIRANJA

Programiranje, kao što je već rečeno je jedna faza u životnom ciklusu SW i ona obuhvata:

Analizu programa Dizajn programa Kodiranje Testiranje Održavanje

strana 53 od 75

Softverske tehnike

Analizaprograma

Dizajnprograma

Kodiranje

Testiranje

Održavanje

Cik

lus

test

iranj

a

Cik

lus

odr

žava

nja

Analiza programa:

KONTROLAkoje kontrolne

procedure

PROCESIRANJEkoje su procedure

potrebne

IZLAZšta želimo na

izlazu

ULAZkoji je ulaz naraspolaganju

MEMORISANJEkoje podatkememorisati

Dizajn (tradicionalni) programaModuli:

- Inicijalizacija (Deklaracije);- Ulaz;- Obrada;- Izlaz.

Za dizajniranje svakog od gore navedenih modula koriste se razni alati:1. Strukturni dijagrami;2. Hipo dijagrami;3. Dijagram toka;

strana 54 od 75

Softverske tehnike

4. Pseudokod;5. Tabele odlučivanja.

1. Strukturni dijagram:

1. Izracunavanje plata

2. Izracunavanjebruto plata

6. Izracunavanjeneto plata

3. Akumulacija radnih sati

4. Odredivanjefaktora

5. Bruto plata7. Izracunavanje

odbitaka8. Štampanje

lista

2. Hipo dijagram

strana 55 od 75

Softverske tehnike

Tabelaposlova kojise placaju

Glavnatabela plata

Tabelafaktora plata

Akumuliranjesati rada

Pronalaženjefaktora za tip

posla

Izracunavanjebruto plata

Glavnatabela plata

Tabela butoplata

Tabela netoplata

ULAZ OBRADA IZLAZ

3. Dijagram toka:

Procesiranje

Odluka

Pocetak/Kraj (terminalna tacka)

Konektor stranice

Konektor za drugi dijagram toka

Ulaz/Izlaz

Predefinisani proces(Operacije koje nisu detaljnopredstavljene u konkretnom dijagramu)

Pravci toka

strana 56 od 75

Softverske tehnike

START

STOP

4. Tabele odlučivanja

Paušal

Varijabila

Potrošnja < 100kWh

Potrošnja > 100kWh

Minimalna naplata

Racun A

Racun B

Drugi tretman

T T F F F

F F T T F

T F T F

F T F T

x

x x

x

x

1 2 3 4 5

Usl

ovi

Akc

ija

Pravila

Pravila - koja akcija za set uslova

5. Pseudo kod

BEGIN / Počni program

strana 57 od 75

Softverske tehnike

READ / Pročitaj podatke o prodajiDO WHILE / Radi dok ima podataka

Pomnoži prodaju sa procentomIF / Ako je prodaja veća od kvote dodaj 10%ENDIFADD Dodaj procenatPRINT Štampaj, itd.

READ PročitajEND DO

END / Kraj programa

STRUKTURNO PROGRAMIRANJE

Temelji proceduralnog dizajna su nastali kasnih 60-tih godina (Edgar Dijkstra) kada je preporučena upotreba skupa egzistirajućih logičkih konstrukcija od kojih može biti formiran bilo koji program. Svaka od ovih konstrukcija ima predvidivu logičku strukturu i u nju se ulazi na vrhu a izlazi na kraju tako da čitač može lako da prati tok programa. Bazne konstrukcije su sekvenca, odluka i iteracija. Sekvenca je niz naredbi bitnih u specifikaciji svakog algoritma. Odluka omogućava selektiranje procesiranja na osnovu nekog logičkog uslova a iteracija (ponavljanje, petlja) omogućava ponavljanje izvođenja dijela koda. Ove tri konstrukcije su temelj strukturnog programiranja (programiranja bez GOTO naredbe za bezuslovni skok). Strukturno programiranje predpostavlja i razbijanje programa u više modula sa određenom hijerarhijom. Upoterba strukturnih konstrukcija redukuje kompleksnost programa i poboljšava čitljivost, razumljivost, testiranje i održavanje. Strukturno programiranje koristi top down dizajn. Na SL. X prikazane su te konstrukcije.

sekvenca

IF...ELSE...ENDIF

DOWHILE

FOR ( DO)

1DOCASE N-broj uslova

strana 58 od 75

Softverske tehnike

PROGRAMSKI JEZICI I KODIRANJE

Programiranje (kodiranje) je jedana od faza u životnom ciklusu SW. i vodi ka konačnom cilju tj. translaciji SW reprezentacije u formu koju računar razumije. To je proces transformacije programskog dizajna u programski jezik. Program se definiše (Knuth) kao izraz računske metode u računarskom jeziku. Dva ključna termina u ovoj definiciji su računska metoda i računarski jezik. Računska metoda je procedura koja ima sve karakteristike algoritma, izuzev moguće konačnosti, tj. osobinu osobinu da se završi poslije konačnog broja koraka. Algoritam je konačan skup pravila koja precizno specificiraju niz operacija ili koraka koji se izvode da bi se rješio problem. Činjenica da je program napisan u računarskom jeziku znači da može biti izveden na bilo kome računaru koji razumije taj jezik. Naravno, bilo koji čovjek koji zna taj jezik može izvesti program npr. sa olovkom i papirom.

Nakon pisanja (kodiranja) programa pomođu nekog tekstualnog editora dolazi translacioni proces u kome prevodioc (compiler) prihvata izvorni (source) program kao ulaz a kao izlaz daje mašinski zavisan objektni kod (object) koji je ulaz u povezioc (linker) a izlaz iz linkera je mašinski izvodljiv kod (exe, application)

Kroz istoriju razvoja softvera nastojao se generisati programski jezik (sredstvo za komunikaciju izme|u čovjeka i računara) na {to vi{em nivou apstrakcije. Danas egzistira pet generacija programskih jezika. Bilo koja kategorizacija je ote`ana jer u mnogim slu~ajevima jedan programski jezik mo`e legitimno spadati u vi{e nego jednu kategoriju. Tako|e ne postoji standard za 4GL, primarno zbog stalno novih ideja u sintaksi jezika, dijalozima i semantici .

Prva generacija programskih jezika je radila na nivou mašinskog instrukcionog seta (najniži mogući nivo apstrakcije). Ovi jezici su računarski zavisni i svaki tip računara ima svoj vlastiti mašinski jezik. Ti jezici se danas upotrebljavaju samo ako se ne mogu upotrebiti viši programski jezici ili ako neke funkcije u višim programskim jezicima nisu podržane.

Druga generacija programskih jezika (asemblerski jezici) je razvijena kasnih pedesetih godina i upotrbljavala je skraćene notacije od slova i brojeva za komunikaciju sa računarom umjesto binarnih grupa. Asembleri su ovako napisane programe prevodili u mašinski jezik. I ovi jezici su zavisili od tipa računara.

Treća generacija programskih jezika (FORTRAN, COBOL, ALGOL, C itd.) se pojavljuje šezdesetih godina i sastoji se od statementa-a koji su bliski govornom jeziku. Lakše su se čitali i pisali i trebalo je manje statemeta-a po funkciji. Oni su bili na višem nivou apstrakcije ali su u njima morale biti prezentovane kompletne algoritamske strukture. Pressman je ove jezike podijelio u dvije grupe : jezici opšte namjene i specijalizovani jezici.

Sa četvrtom generacijom programskih jezika (4GL), koji se pojavljuju osamdesetih godina, nivo apstrakcije je postao još veći. 4GL “znaju” kako da

strana 59 od 75

Softverske tehnike

izračunaju željene funkcionalne podatke bez specifikacije odgovarajućih algoritama, međutim to “znanje” je u granicama aplikacionog domena.

Peta generacija jezika se upotrebljava u oblasti umjetne inteligencije. Tipičan predstavnik je Prolog.

Četvrta generacija jezika je klasa jezika koja je aplikaciono orijentisana. To su jezici specijalne namjene koji mogu biti lako upotrebljeni za specifične aplikacije ili klase aplikacija kao što su :

-upravljanje bazama podataka-upiti i genersisanje izvještaja-interakcija sa ekranima-generisanje koda (generatori aplikacija)-grafika visokog nivoa-tabeliranje

Danas egzistira veliki broj ovih jezika kao što su Oracle, SQL,Visicalc, FOCUS, RAMIS II, Informix, dbase, CLIPPER i stalno se pojavljuju novi.

4GL kombinuju proceduralne (kako računar da radi) i neproceduralne (šta računar da radi) karakteristike tj. jezik omogućava korisniku da specificira uslove i odgovarajuće akcije (proceduralna komponenta) dok u isto vrijeme traži od korisnika da specificira željeni ishod (ne proceduralna komponenta ) i to zajedno ponudi domenski specifičnom znanju da se dopune proceduralni detalji.

Sintaksa 4GL je bliska sintaksi ljudskog jezika i 4GL su lagani za učenje. Ne proceduralna priroda većine ovih jezika omogućava brze i impresivne rezultate. Cilj ovih jezika je takođe da se izbjegne upotreba nepotrebnih akronima i da se korisnik orijentiše na namjenu aplikacije. Sa druge strane 4GL su tipično dizajnirani za limitirani set funkcija ili specifične aplikacije da bi bili lakši za upoterebu. Ovi jezici za veliki broj zahtijevanih parametara nude ugrađene vrijednosti i na taj način skraćuju potrebno vrijeme i smanjuju napor za otklanjanje grešaka.

Osnovni ciljevi 4GL su:

1. da se poveća brzina u procesu pravljenja aplikacije 2. da se omoguće lake i brze izmjene u aplikacijama i smanji cijena održavanja3. da se minimiziraju problemi u otklanjanju grešaka4. da se iz uslova i zahtijeva generiše kod koji nema grešaka5. da su laki za upotrebu krajnjim korisnicima za rješavanje vlastitih problema

U odnosu na 3GL, 4GL zahtijevaju znatno manje linija koda, znatno manji napor , imaju veću produktivnost po funkcionalnim tačkama ali su i znatno manje produktivni u linijama koda.

U samom procesu kodiranja se koriste različiti stilovi koji imaju veliki uticaj na kvalitet i pogodnost održavanja. Npr. Jedna te ista stvar se može napisati na više načina zavisno od programera:

strana 60 od 75

Softverske tehnike

D = B*TDIST = BRZINA * VRIJEMEDISTANCA = BRZINA * VRIJEME_U_SEC

Sledeće o čemu treba vodititi računa su komentari:

Koliko je komentara dovoljno Gdje ih smjestiti Da li komentari smetaju praćenju logičkog toka Da li zbunjuju čitača itd.

Prolog komentara treba da sadži:

Opis funkcije modula Opis interfejsa

Sekvence za pozivanje Deskripcija argumenata Lista subordiniranih modula

Istorijat razvoja Autor , datum kreiranja, datum modifikacije, broj verzije itd.

Konstrukcija naredbi je takođe bitna u kodiranju, kao što se vidi u sledećem primjeru (mnogi jezici dopuštaju pisanje više naredbi u jednom redu):

DO I = 1 TO N –1; T=I;DO J=I+1 TO N;IF A(J)<A(T) THE DO T=J;END;IF T<> THEN DO H=A(T);A(T)=A(I);A(I)=H;END;END;

Ovo je potpuno nepregledno i to se može napisati na drugi način:DO I = 1 TO N – 1;

T=I;DO J = J + 1 TO N;

IF A(J) < A(T) THEN DOT = J;

ENDIF T <> I THEN DO

H = A(T);A(T) = A(I);A(I) = H;

END;END;

END;

Prilikom kodiranja treba:

Izbjegavat komplikovane uslove Izbjegavati testove na negativne uslove Izbjegavati višestruko ugnjždavanje Upotrebljavati zagrade za aritmetičke i logičke uslove Uptrbljavati blenkove između operatora i operanada Vršiti vršiti kontrolu ulaznih podataka (numerik, karakter, datum itd)

strana 61 od 75

Softverske tehnike

Omogućti jednostavan ulazni format (masku) za kretanje po ekranu u slučajevima dodavanja, ažuriranja, brisanja i kraja rada

Upotrebljavati jednostavne aritmetičke i logičke operacije Izbjegavati multidimenzionalna polja Izbjegavati pointere i kompleksne liste Ne miksati različite tipove podataka Upotrebljavati integere i bool-ove izraze kad god je to moguće Minimizirati broj I/O zahtjeva itd.

OBJEKTNO ORIJENTISANO PROGRAMIRANJE OOP

Bunge-a je 1979 god.predložio set ontoloških principa (opŠta svojstva stvari bi’a) koje su Yand i Webera primjenili na OO sisteme 1990 god. Ovdje se svijet sastoji od substancionalnih individuala koji posjeduju konačan skup svojstava. Zajedno, substancionalni individuali sa svojim svojstvima konstituišu objekt. Klasa je skup objekata koji imaju zajednička svojstva a metod (funkcija) je operacija na objektu definisan kao dio deklaracije klase.

Objekt može biti reprezentovan na sledeći način:X = (x, p(x))

gdje su :- x supstancionalni individual- p(x) konačan skup svojstava

Upotrebom Bunge-ovih ontoloških termina definisani su atributi kao couplig (povezivanje), kohezija, kompleksnost objekta i skup svojstava važnih za OO sisteme.

Coupling (spajanje, povezivanje)

Ako imamo dva objekta X = (x, p(x)) i Y = (y, p(y)) i

p(x) =[MX] U [IX]p(y) = [My] U [Iy]

gdje je [Mi] skup metoda i [IX] skup varijabli instace objekta.

Upotrebom gornje definicije couplinga, bilo koja akcija od [MX] na [My] ili [Iy] konstituiše copling, isto vrijedi za bilo koju akciju [My] na [Mx] ili [Ix]. Kada Mx

poziva My, Mx mjenja istoriju upotrebe My. Isto tako kada Mx upotrebljava Iy on mjenja pristup i istoriju upotrebe Iy. Nadalje, bilo koja evidencija da metod jednog objekta upotrbljava metode ili varijable instance drugog metoda konstituiše copling. Dvije klase su povezane kada metodi deklarisani u jednoj klasi upotrbljavaju metode i varijable instance druge klase.

KohezijaDrugi važan atribut za koncept dizajniranja softvera je kohezija. Stepen sličnosti metoda M1 i M2 se definiše na sledeći način:

(M1,M2) = [I1] [I2]

strana 62 od 75

Softverske tehnike

Stepen sličnosti metoda je glavni aspekt kohezivnosti. Ako, klasa ima različite metode koje izvode različite operacije na istom setu varijabli inctance onda je klasa kohezivna.

Dobar dizajn softvera predpostavlja minimizaciju coupling-a i maksimizaciju kohezije.

Kompleksnost objekta

Kompleksnost objekta se svodi na to da kompleksni individual ima više svojstava. Uzimajući ovo u obzir kompleksnost objekta se defiše kardinalitetom seta njegovih svojstava tj. kompleksnost (x, p(x)) = p(x) pri čemu je p(x) kardinalitet od p(x).

Obim svojstava

Prilikom dizajniranja hijerarhije klasa odnosno hijerarhije nasleđivanja nephodno je voditi računa o restrikciji ili ekspanziji obima svojstava klasa objekata u aplikaciji. Dvije stvari koje utiču na hijerarhiju nasleđivanja su dubina nasleđivanja i broj djece koje ima klsa. dubina nasleđivanje se definiše kao dužina maksimalnog puta od čvora do krijena u stablu nasleđivanja. Broj djece se definiše kao broj neposrednih naslednika. Dubina nasleđivanja indicira koliko je klasa influencirana svojstvima svoji predaka a broj djece indicira potencijalni uticaj na potomke.

Pored OOA (Objektno Orijentisane Analize) i OOD (Objektno Orijentisanog Dizajna) postoji i OOP (Objektno Orijentisano Programiranje). OOP je nastao kada su uočeni mnogi nedostaci u klasičnom programiranju. PASCAL, C, FORTRAN i slični jezici spadaju u proceduralne jezike u kojima svaka naredba kaže računaru da nešto uradi (učitaj, dodaj, podijeli, prikaži itd.). Za male programe nije bio potreban neki drugi organizacioni princip, međutim kada se radi o većim i kompleksnijim programima lista naredbi postaje nepregledna i neprikladna i zato je bilo potrebno program razbiti na funkcije, procedure, potprograme itd. pri čemu svaka funkcija ima jasno definisanu namjenu i vezu sa drugim modulima. Ideja podjele programa u funkcije je dalje proširena na grupsanje funkcija u module. Dijeljenje programa u funkcije i module je bio kamen temeljac strukturnog programiranja. Tj. discipline koja je obilježila organizaciju programiranja u nekoliko zadnjih dekada. Međutim pošto su programi postajali sve veći i kompleksniji i strukturno programiranje je počelo pokazivati svoje slabe strane, naročito u baratanju sa podacima koji su bili zapostavljeni tj. druga klasa u organizaciji proceduralnih jezika, a podaci su razlog za egzistenciju programa. Npr. Podaci učitani sa diska u glavnu memoriju se tretiraju kao globalne varijable pod kojima podrazumjevamo podatke koji su deklarisani van bilo koje funkcije i dostupni su svim funkcijama. Mnogi jezici podržavaju lokalne varijable koje su sakrivene unutar jedne funkcije i nisu dostupne drugim funkcijama.

strana 63 od 75

Softverske tehnike

Sl.1 Globalne i lokalne varijable

Drugi problem je u tome da različite funkcije pristupaju istim podacima i način na koji su podaci spremljeni postaje kritičan. Npr. ako se doda novi podatak potrebno je modificirati sve funkcije koje ga koriste. Nadalje, u tradicionalnim jezicima je veoma teško kreirati vlastiti tip podatka jer oni već imaju ugrađene tipične tipove podataka (integer, real, character itd.) što je još jedan nedostatak ovih jezika.

Rezultat svega ovoga je da su tradicionalni jezici suviše kompleksni i teški za pisanje i održavanje i zato je bilo potrebno tražiti neki drugi pristup programiranju i to je rezultiralo u OOP.

Fundamentala ideja OOP je bila da se u jednoj jednostavnoj jedinici kombinuju podaci i funkcije koje rade sa tim podacima. Takve jedinice se nazivaju objekti. Funkcije unutar objekta se zavisno od jezika (OO Language) nazivaju member funkcije (funcije članice) ili metode i tipično omogućavaju jedini put za pristup podacima. Ako se želi čitati podatak u objektu poziva se member funkcija u objektu. Funkcija čita podatak i vraća vrijednost. Podacima se ne može pristupiti direktno. Podaci su skriveni (hidden) i na taj način su sigurni od incidentalnog pristupa. Za podatke i funkcije se kaže da su enkapsulirani u jednostavan entitet. Enkapsulacija i skrivanje podataka su ključni termini u opisu OOL.

Ako se žele modifikovati podaci u objektu egzaktno se zna koje funkcije su u interakciji sa njima i druge funkcije nemogu pristupiti tim podacima. Ovo pojednostavljuje pisanje, otklanjanje grešaka (debugging) i održavanje programa. Pozivanje member funkcije se vrši slanjem poruka (massages). Objektno orijentisana paradigma data je na Sl. 2.

strana 64 od 75

Softverske tehnike

Sl. 2. Objekton orijentisana paradigma

Radi boljeg razumjevanja upotrebit ćemo jednu analogiju. Zamislimo objekte kao odjele nekog preduzeća – prodaja, računovodstvo, kadrovsko itd. Svaki odjel ima vlastiti personal sa jasno podjeljenim dužnostima i vlastite podatke npr. o platama, personalu, skladištima i td. Ljudi u svakom odjelu upravljaju i koriste podatke odjela. Ako ste vi iz odjela prodaje i želite znati sve isplaćene plate za neki region u nekom mjesecu nemorate ići u odjel plata i pretraživati papire, nego jednostavno pošaljete poruku odgovarajućoj osobi u odjelu plata i čekate da ona pristupi podacima i da pošalje odgovor sa informacijama koje ste željeli. Ovakav način osigurava da podaci budu tačni i da nisu koruptirani od osobe sa strane.

strana 65 od 75

Softverske tehnike

Sl.3. Korporacijska paradigma

Kada se pristupa problemu programiranja u OOL više se nepitamo kako problem podijeliti na funkcije nego kako ga podijeliti na objekte. Razmišljanje u terminima objekta ima veliki efkat u dizajniranju programa zbog bliske veze objekta u programskom smislu i objekta u realnom svijetu. Koje vrste stvari postaju objekti zavisi od naše imaginacije i neke tipične kategorije su:

Fizikalni objekti Automobili u simulaciji saobraćaja Elektronske komponente u CAD-u Zemlje u ekonomskim modelima

Elementi u okruženju računar-korisnik windows meni grafički objekti (linije, krugovi, kvadrati i td) miš, tastatura, disk, printer itd.

Ljudski entiteti službenici studenti kupci umjetnici itd.

Sledeći pojam bitan u OOP je klasa. U OOP se kaže da je objekt član klase. Klasa je kolekcija sličnih objekata. Npr. Madona, Prince i Sting su članovi klase

strana 66 od 75

Softverske tehnike

rok muzičara, međutim ne postoji nijedna osoba čije je ime rok muzičar ali specifični ljudi sa specifičnim imenima su članovi ove klase ako posjeduju određene karakteristike.

Sledeći pojam iz OOP je nasleđivanje (Inheritance). Ideja klase vodi ka ideji nasleđivanja. Klase se dalje dijele na podklase. Npr. klasa vozila je podjeljena na automobile, autobuse, kamione i motocikle. Svi oni imaju točkove i motore koji definišu karakteristike vozila. Pored zajedničkih karakteristika svak podklasa ima svoje vlastite karakteristike. Npr. autobusi prevoze putnike a kamioni teret itd. Dakle, podklasa nasleđuje neke karakteristike od klase i pri tome dodaje svoje vlastite karakteristike.

Ponovna upotreba (Reusability) je takođe jedna od karakteristika OOP. Jednom kada je klasa napisana, kreirana i kada su grške otklonjene ona može biti distribuirana drugim programerima za upotrebu u njihovim vlastitim programima. Slično je i u tradicionalnom programiranju kada se rutine iz programskih biblioteka inkorporiraju u program. U OOP koncept nasleđivanja omogućava ekstenziju ideje o ponovnoj upotrebi. Programer može uzeti egzistirajuću klasu bez modifikacije i dodati joj nove mogućnosti. To znači da se iz egzistirajuće klase derivira nova klasa koja nasleđuje mogućnosti stare klase i otvara mogućnost daljeg proširenja.Sledeća karakteristika OOL je kreiranje vlastitih tipova podataka i upotreba operatora na različit način i to se zove polimorfizam.

Primjer OO C++ programa.

Sl. 4. Klase sadže podatke i funkcije

Ovaj program sadrži jednu klasu (smalljob) i dva objekta(s1 i s2) te klase. Program demonstrira sintaksu i generalne karakteristike klase. Klasa smalljobj specificirana u ovom programu sadrži jedan podatak (somedata) i dve member funkcije (setdata i showdata). Member funkcije dopuštaju pristup podatku izvan klase. Prva funkcija stavlja vrijednost u podatak a druga prikazuje tu vrijednost. Tijelo klase sadrži dvije ključne riječi private i public vezane za sakrivanje

strana 67 od 75

Softverske tehnike

podataka.Privatnim podacima i funcijama se može pristupiti samo iz klase dok su javni (public) podaci i funkcije dostupni izvan klase.

Sl. 5. Privatni i javni podaci

// smallobj.cpp// demonstrates a small, simple object#include <iostream.h>

class smallobj // specify a class { private: int somedata; // class data public: void setdata(int d) // member function to set data

{ somedata = d; } void showdata() // member function to display data

{ cout << "\nData is " << somedata; } };

void main() { smallobj s1, s2; // define two objects of class smallobj

s1.setdata(1066); // call member function to set data s2.setdata(1776);

s1.showdata(); // call member function to display data s2.showdata(); }

Rezultat je:

Data is 1066 ovo prikazuje objekt s1Data is 1776 ovo prikazuje objekt s2

strana 68 od 75

Softverske tehnike

Sl 6: Dva objekta klase small obj

TESTIRANJE SOFTWARE-a

Testiranje SW-a je kritičan element u osiguravanju kvaliteta i pouzdanosti SW-a u fazama specifikacije, dizajna i kodiranja. Posebnu pažnju i cijenu zahtjava SW koji je orijentisan na ljude (kontrola leta, monitoring nuklearnih reaktora itd.). Cijena i vrijeme testiranja može biti nekoliko puta veća u odnosu na sve ostale faze zajedno.

Testiranje je proces izvođenja programa sa ciljem pronalaženj grešaka. Za izvoženje testa potrebni su ulazni podaci koji formiraju testni slučaj (test case) koji treba da ima veliku jerovatnoću otkrivanja grešaka. Testovi moraju biti dizajnirani tako da otkrivaju različite klase grešaka i testiranje može prikazati samo prisustvo defekta. Rezultati testa se porede sa očekivanim rezultatima i ako nisu prihvatljivi, tj. nepoklapaju se, potrebno je otkloniti greške. Greške koje se neotkriju u fazi testiranja otklanjaju se u fazi održavanja tj. eksploatacije.

Dizajniranje testnih podataka. Testni podaci (slučajevi) moraju biti dizajnirani tako da imaju veliku vjerovatnoću pronalaženja greške uz mali uloženi napor i vrijeme. Kao i bilo koji drugi produkt SW može biti testiran na dva načina.

Poznate su sve specificirane funkcije za koje je produkt dizajniran da ih izvede. Testovi treba da demonstriraju da je svaka funkcija potpuno operacionalna (black box testiranje).

Poznate su sve interne operacije koje se izvode prema specifikaciji i sve interne komponente se adekvatno ispituju (white box testiranje)

strana 69 od 75

Softverske tehnike

Black box testiranje (testiranje crne kutije) je funkcionalno testiranje. Testni slučajevi demonstriraju da su SW funkcije operacionalne, da je input dobro specificiran, da je output korektno produkovan i da se održava integritet eksternih informacija (npr. fajlova). Dakle, black box testiranje razmatra neke aspekte fundamentalnog modela sistema i malo pažnje posvećuje internoj logičkoj strukturi SW-a.

White box testiranje (testiranje bijele kutije) je metoda za dizajniranje testnih slučajeva koja uptrebljava upravljačke strukture proceduralnog dizajna. Uptrebom white box testiranja mogu se derivirati testni slučajevi koji omogućavaju:

Da su svi nezavisni putevi unutar modula izvedeni najmanje jednom

Da je kod svake logičke odluke izvedeno testiranje na obe strane true(ispravno) i false (pogrešno)

Da je izvođenje svih petlji izvršeno u njihovim granicama Da se ispita interna struktura podataka i njihova validnost

Softverske greške mogu biti simboličke i logičke:

Simboličke greške se obično pojavljuju ybog nepoznavanja sintakse i semantike programskog jezika i tipografskih grešaka. Mnoge od ovih grešaka otkriva kompajler u fazi prevođenja i relativno ih je lako otkloniti a neotkrivene greške će se pokazati u fazi testiranja.

Logičke greške se javljaju prilikom testiranja ili izvođenja programa a poslijedica su lošeg dizajna, implementacije funkcija i uslova. Za pronalaženje ovih grešaka najčešće se koriste simbolički debug-eri koji omogućavaju programeru da prati izvođenje programa od jedne do druge izvorne instrukcije, da ispituje i mjenja sadržaje varijabli, postavlja tačke prekida od kojih počinje ispitivanje itd.

Verifikacija i validacija. SW testiranje je jedan od elemenata verifikacije i validacije. Verifikacija se odnosi na skup aktivnosti koje osiguravaju da je SW korektno implementiran za specifičnu funkciju. Validacija se odnosi na različit skup aktivnosti koje osiguravaju da SW zadivoljava korisnikove zahtjeve. Rečeno na drugi način:

Verifikacija: Da li smo napravili produkt dobro ?

Validacija Da li smo napravili pravi produkt ?

strana 70 od 75

Softverske tehnike

Strategije SW testiranja

Jedinično testiranje se fokusira na male jedinice softverskog dizajna – moduli i uvijek je White box orjentisan i koraci mogu biti paralelno izvođeni za različite module.

Integracioni test. Poslije jediničnog testiranja i ako svi moduli rade individualno ispravno, to ne znači da će nakon integracije raditi dobro zbog pojavljivanja problema interfejsa između modula. Podaci mogu biti izgubljeni kroz interfejs, jedan modul može imati neželjene efekte na drugi, kombinovani moduli ne produkuju željenu funkciju, javljaju se problemi sa globalnim strukturama podataka itd. Integracioni test uzima jedinično testirane module i od njih gradi programsku strukturu diktiranu od dizajna za testiranje koje treba da otkrije greške koje se pripisuju interfejsu između modula.

Validacioni testiranje nastupa kada je završeno integraciono testiranje. SW je kompletno asembliran u paket, greške u interfejsu su otkrivene i otklonjene i dolazi se do konačne serije SW testova tj. validaciono testiranje može početi. Validacija je u stvari indikator koliko su SW funkcije u skladu sa korisnikovim rezonskim očekivanjem. Ako postoji problem, postavlja se pitanje ko je arbitar i odgovor treba potražiti u specifikaciji SW zahtjeva koja sadrži kriterije za validaciju.

Sistemsko testiranje obuhvata seriju različitih testova čija je primarna namjena da se potpuno ispita računarski baziran sistem. Iako svaki test ima različitu namjenu, oni svi zajedno rade da verifikuju da su svi sistemski elementi integrisani pravilno i da izvode svije funkcije. Sistemsko testiranje obuhvata:

Recovery testiranje koje forsira ispad SW-a na raličite načine i nastavak njegovog rada od momenta ispada ili unapred predviđene vremenske tačke;

Testiranje sigurnosti verificira protekcione mehanizme ugrađene u sistem.

Stres testiranje se odnosi na testiranje u uslovima abnormalne potražnje resursa u kvantitetu, frekvenciji i volumenu.

Testiranje performansi se izvodi u svim koracima procesa testiranja sa ciljem da se vrednuje propusnost, vrijeme odziva i iskoristivost resursa.

Održavanje (Maintenance)Uvode se dva pojma:

Software Maintenance - SMSoftware Configuration Maintenance – SCM

SM - skup SE aktivnosti koje se događaju poslije isporuke softvera korisniku i kada je softver stavljen u operativno stanje

strana 71 od 75

Softverske tehnike

SCM - skup aktivnosti koje vode trag i upravljačke aktivnosti koje počinju kada softverski projekat starta, a završavaju kada se softver izbaci iz upotrebe

Definicija SMSM definišemo sa četiri aktivnosti kada je program stavljen u upotrebu.

1) Korektivno održavanjeNerezonski je pretpostaviti da se greške u velikim softverskim programima mogu otkriti u fazi testiranja

2) Adaptivno održavanjeDogađa se zbog čestih izmjena koje se događaju u svakom aspektu kompjuterizacije (novi HW, novi SW, nove vezije aplikativnog SW - vijek trajanja (10 god.))

3) Perfektivno održavanje- SW zadovoljava- ali preporučuju se nove mogućnosti; modifikacije

4) Preventivno održavanjeKada se SW mijenja kako bi se poboljšala mogućnost održavanja i pouzdanosti

50%

21%

25%

4%

Perfektivno

Korektivno

Adaptivno

Ostalo

Problemi Teško je razumjeti nečiji program; Neko nije u okruženju (blizini); Dokumentacija ne egzistira ili je nekompletna; Većina SW nije dizajnirana za promjene; Potcijenjeno održavanje.

strana 72 od 75

Softverske tehnike

Pogodnosti održavanjaOsnovne karakteristike (kvalitativno):- Lakoća razumijevanja;- Korekcije;- Adaptacije;- Poboljšavanja.

Faktori pogodnosti održavanja (kvalitet)- Raspolaganje sa kvalifikovanim osobljem;- Razumijevanje sistemske strukture;- Lakoća upravljanja sistemom;- Upotreba standardizovanih programskih alata;- Upotreba standardizovanih OS;- Standardizovana dokumentacija;- Raspolaganje sa testnim podacima;- Ugrađene debug mogućnosti;- Remote Mintenance.

Kvantitativni faktori pogodnosti održavanja1. Vrijeme prepoznavanja problema;2. Vrijeme administrativnog kašnjenja;3. Prikupljanje alata za održavanje;4. Analiza problema;5. Vrijeme izmjene specifikacije;6. Korekcija (modifikacija) – vrijeme;7. Lokalno testiranje;8. Globalno testiranje;9. Izvještaj o održavanju;

10. Totalno vrijeme popravke.

Izvještavanje (Recordkeeping) Nedefinisano, ali mora obuhvatiti nešto od slijedećeg:

1. Identifikacija programa;2. Broj source statamets-a;3. Broj machine code instructions;4. Upotrijebljeni programski jezik;5. Datum instalacije programa;6. Broj programa koji su radili od instalacije;7. Broj programskih grešaka iz 6.;8. Nivo izmjena programa;9. Broj dodanih source statamets-a;

10. Broj izbrisanih source statamets-a u izmjenama;11. Broj čovjek/sati provedenih na izmjenama;12. Datum izmjene programa;13. Identifikacija SW inženjeringa;14. MRF (Mean Repair Failure);15. Tip održavanja;16. START/END Maintenance;17. Kumulativni rad čovjek/sat, provedenih na održavanju;18. Korist od održavanja.

strana 73 od 75

Softverske tehnike

Vrednovanje održavanja1. Prosječan broj grešaka;2. Totalan broj osoba korišćenih u svakoj kategoriji održavanja;3. Prosječan broj izmjena po programu, jeziku i tipu održavanja;4. Prosječan broj čovjek/sati po dodanom ili izbrisanom statements zbog

održavanja;5. MRF;6. Procenat zahtjeva za održavanje po tipu;7. Procenat zahtjeva za održavanje po tipu.

SCM SE: - Metodi; - Procedure; - Alati.

Output SE: 1. Programi;2. Dokumenatcija;3. Strukture podataka.

Informacije produkovane kao dio SE procesa se kolektivno nazivaju SW Configuration.

SCM je niz aktivnosti koje upravljaju izmjenama u životnom ciklusu softvera

Zadaci SCM:Svi žele izmjene - Korisnici;

- Projektanti;- Menadžeri.

SW Configuration Items (SCI):- Informacije kreirane kao dijelovi SE procesa;- SCI je dokument;- Slijedeći SCI su cilj za CM tehnike:

1. Specifikacija sistema;2. Plan projekta SW;3. Specifikacija zadataka (a) Izvodqiv ili papirni prototip (b);4. Preliminarni korisnički menjuel;5. Specifikacija dizajna;

a) Preliminarni;b) Detaljni;

6. Liste source koda;7. Plan testa i procedure;Testni slučajevi i ispisani rezultati8. Operacioni i instrukcioni menjuel;9. EXE programi;

10. Korisnički menjueli;11. Dokumentacija održavanja

a) SW problemi (izvještaji);b) Zahtjevi za održavanje.

strana 74 od 75

Softverske tehnike

strana 75 od 75