Materiali Plote Ledjo Allkoja

Analiza ,implementimi dhe optimizimi gabimeve n kod
Prmbajtje
Abstrakt ......................................................................................................................................................... 4
1
Hyrje ...................................................................................................................................................... 5
1.1
Qllimi ........................................................................................................................................... 6
1.2
Organizimi ..................................................................................................................................... 6
Testimi i software-it dhe gabimet n kod ............................................................................................. 7

2.1
Hyrje .............................................................................................................................................. 7
2.2
Defektet n software .................................................................................................................... 9
2.3
Nivelet e testimit......................................................................................................................... 10
2.4
Metodat e testimit ...................................................................................................................... 12
2.5
Llojet e testimit ........................................................................................................................... 14
2.6
Metrikat e testimit ...................................................................................................................... 15
Parashikimi i gabimeve n kod ........................................................................................................... 17

3.1
Hyrje ............................................................................................................................................ 17
3.2
Cikli i jets s nj gabimi n kod ................................................................................................. 18
3.3
Klasifikimi .................................................................................................................................... 20
3.4
Gjetja e gabimeve n kod dhe mjetet e gjurmimit ..................................................................... 23
3.4.1
3.5
Sisteme efektive n gjurmimin e gabimeve n kod ............................................................ 24
Modelet e parashikimit t gabimeve n kod .............................................................................. 25
3.5.1
Metrikat e bazuar tek ndryshimet ...................................................................................... 26
3.5.2
Metrikat e kodit .................................................................................................................. 27
3.5.3
Metrikat e organizimit ........................................................................................................ 30
Mjetet e prdorura ............................................................................................................................. 32

4.1
SOTA ............................................................................................................................................ 32
4.1.1
Si punon SOTA ..................................................................................................................... 33
4.1.2
Tipet e prdorimit ............................................................................................................... 33
4.1.3
Puna me SOTA ..................................................................................................................... 34
4.2
CCCC ............................................................................................................................................ 36
4.2.1
Metrikat e shfaqura ............................................................................................................ 37
4.2.2
Metodat e numrimit ......................................................................................................... 38

5
Analiza Dinamike ................................................................................................................................. 40

5.1
Objektivi dhe motivimi. ............................................................................................................... 40
5.2
Software-i nn testim. Rast studimor. ........................................................................................ 40
5.2.1
5.3
Prmbledhje ................................................................................................................................ 47
5.3.1
6
Problemet ne kualitetin software-ik dhe matjet e tij. ............................................................... 48
6.1.1
Objektivi dhe motivimi. ....................................................................................................... 48
6.1.2
Software-i nn testim ......................................................................................................... 48
6.1.3
Komentet mbi vlerat e metrikave MVG dhe LOC............................................................... 48
6.2
Klasa Error.java ........................................................................................................................... 49
6.2.1
Rezultatet e CCCC................................................................................................................ 49
6.2.2
Rezultatet e SOTA ............................................................................................................... 50
6.3
Scaner.java .................................................................................................................................. 51
6.3.1
Rezultatet e CCCC................................................................................................................ 53
6.3.2
Rezultatet e SOTA ............................................................................................................... 54
6.4
Klasa testuese n Java......................................................................................................... 47
Analiza Statike ..................................................................................................................................... 48

6.1
Implementimi i rastit studimor. .......................................................................................... 40
Avantazhet dhe disavantazhet e kompleksitetit iklomatik ....................................................... 55
6.4.1
Vlerat e kqija pr kompleksitetin iklomatik .................................................................... 57
6.4.2
Matje shtes........................................................................................................................ 58
Optimizimi dhe sfidat n t ardhmen ................................................................................................. 60

7.1
Optimizimi i gabimeve n kod .................................................................................................... 60
7.2
Nivelet e optimizimit ................................................................................................................... 60
7.3
Platforma e varur dhe optimizimi i pavarur................................................................................ 62
7.4
Pikat bllokuese ............................................................................................................................ 62
7.5
Kostoja e optimizimi.................................................................................................................... 62
7.6
Sfidat e optimizimit ..................................................................................................................... 63
Prfundimet ........................................................................................................................................ 64
Lista e figurave ............................................................................................................................................ 65

Lista e tabelave ........................................................................................................................................... 66
Shtojca 1...................................................................................................................................................... 67

Shtojca 2...................................................................................................................................................... 69
Shtojca 3...................................................................................................................................................... 82
Referencat ................................................................................................................................................... 87

Abstrakt
Defektet n software jan gjendje, q nuk i prgjigjen krkesave t software-it ose
pritshmrive t prdoruesit prfundimtar. Me fjal t tjera, jan gabime n kod ose gabime
logjike, t cilat ojn n keqfunksinimin e programit ose n rezultate t gabuara.
Kjo paper prezanton analizn e kodeve burim t porgrameve te zhvilluara n java ,pr te
ilustruar identifikimin e bugeve dhe realizimin e nj testimi t mirfillt software-ik.
Testimi software sht nj aktivitet thelbsor pr t kontrolluar dhe provuar korrektsin e
sjelljes e software-it sipas specifikimit t tij. Testimi prballet me problemin pr t gjetur setin
e t gjitha rasteve t mundshme t testit e cila ka nj probabilitet t lart pr t zbuluar gabimet.
Nj mnyr pr t adresuar kt problem sht t prdoret testimi i strukturuar (p.sh duke
prdorur Sota).
Analizohet zgjedhja e testcase-ve specifike pr te qne n numrin minimal t tyre dhe arsyet pse
n nje kod burim nuk mbulohen plotsisht gjith nyjet apo deget e tij lidhur me problemet ne
kod. N aspektin e metrikave npmjet CCCC dhe SOTA realizohet pr cdo njsi ,modul ,klase
rishikimi i parametrave si kualitetin software-ik, kompleksitetin cikolmatik, gjatsine, prmasn,
numrin e variablave, parametrave etj. Do t diskutohet se fundmi optimizime t mundshme ne
aspektin software-ik n kodet prkatse.
Terminologji Me termin Gabime ne kod n kt material do ti referohemi termit software
bug n anglisht, i cili n kt material ka kuptimin e nj sjellje difektoze n program q
rregullohet nprmjet ndryshimeve semantike n kodin burim.

1 Hyrje
Lidhur me fenomenin e rritjeve n internet sht e rndsishme t testohet dhe t rishikohet
kodi software pr t shmangur ndodhjen e buge-ve dhe shmangjen e pjeseve te kodit t pa
nevojshme t cilt thjesht rritin kohn e kompilimit.Lidhur me kte kompanit shtetet jan t
prirura pr t investuar sasi t mdha parash p t rritur kualitetin software-ik. Kshtu testimi
software sht vlersuar pr t marr rreth 50% t kohs dhe kostove t procesit t zhvillimit t
software-it .
Inxhiniert e testimit jan prballur me problemin pr t gjetur nj setin e t gjitha rasteve t
mundshme t testit e cila ka nj probabilitet t lart pr zbuluar gabimet .
N kt tem ne fokusohemi n testimin e kodeve te programeve n java duke realizuar nj
analiz statike. Analiza statike nnkupton ekzaminimin e nj pjese t kodit pa e ekzekutuar at.
Kjo i referohet analizs s kompleksitetit t kodit n lidhje me rritjen e numrit t rrjeshtave t
kodit, kohs s zhvillimit dhe kohs gjat ekzekutimit t kodit. Shum tool-se t automatizuara
jan zhvilluar pr t realizuar kt analiz.
N kt tez prezatoj nj tools shum efektiv sic sht CCCC dhe SOTA (e prdorur pr t dyja
analizat) t ekzekutuara n platform t ndryshme si psh Windows, Mac, Linux. Metrikat
software-ike prcaktohet si nj objektiv si nj mates matematik q sht i ndjeshm n
diferencn n karakteristikat software-ike. Qllimi i tij shte njohja e procesit software-ik duke
kontrolluar aspekte t ndryshme. Thuhet q kto metrika prdoren pr t rritur mundsin e
identifikimit, kontrollit dhe matjen e parametrave esenciale.
Informacioni i mbledhur nga metrikat software-ike mund t pdoren pr t menaxhuar dhe pr
parashikuar procesin e zhvillimit. Disa nga cilsite ideale t metrikave software jan:
1. Duhet t jet i thjesht, lehtsisht i pcaktuar dhe i qart
2. Duhet t jet i vlefshm
3. Duhet t jet i fort n natyr
N varsi me metrikat software q veprojn jan klasifikuar n dy tipe:
Metrikat e tipit t testimit

Mat produktet e software. (Psh kodi burim dhe dokumentet e dizenjimit)
Metrikat e tipit t procesit
Psh tipi i metodologjis, numrin e ndryshimeve t bra n dokument dhe numrin e
bugeve t rikuperuara gjat testimit
Kjo tez diskuton kualitetin e dhn nga nj standard si ISO, rndsin e kualitetit gjat procesit
t zhvillimit,dhe s fundmi zgjedhjen e metrikave software si metrikat e pmass (size-metrics),
metrika e kompleksitetit metrikat e defekteve pr t vlersuar kodet n java .

Ndrsa teknika e vlersimit software-ik gjat kompilimit njihet si analiza dinamike. Kshtu q
analiza dinamike sht m thelbsore pasi prdoret pr t testuar gabimet logjike dhe stresin e
testimit gjat ekzekutimit n nj mjedis me burime t kufizuara.
Lidhur me analizn dinamike nprmjet SOTA e cila ka nnt parametra q do t prezantohen n
rastet studimore t mposhtme anlaizohet n mnyr t hollsishme pse jo t gjith mbulimet
(coverage) nuk realizohen 100% duke shpjeguar arsyet. Shikohet se pr gjasht parametrat e par
mbulimi sht realizuar i plot kurse pr 3 t fundit ka nj rnie dhe maximum q u arrit 43.6%.
Kjo tez bn nj kontribut n fushn e Software Engineering e mbshtetur n aspektein empirik
dhe analitik t kodeve reale (me numr t vogl LOC) dhe n fund realizimin e prgjithsimeve
pr kode shum t mdha (Referuar LOC).
1.1 Qllimi
Qllimi i ksaj teme sht t studioj gabimet q ndodhin n kodet e ndrtuara n
programet n java dhe nprmjet tyre te realizoj prgjithsime pr super programe. Kto gabime
do t analizohen n aspektin e kompleksitetit ku shpjegohet dhe ndikimi i kompleksitetit n
mundsin pr gabime, rritja e pmasave te kodit (LOC). Prve ksaj shikohet mbulimi i kodit
ne 9 parametrat e specifikuara nga programi .
Pr t realizuar kt gje prdoren dy programe SOTA dhe CCCC. Kto rezultate jan
interpretuar dhe n baz t tyre nxirren prfundime n forme raportesh. Kto raporte do t
shprehin dhe ndikimin e tyre ne gabimet n kod, q sht dhe thelbi i studimit t ksaj teme
diplome.
1.2 Organizimi
Materiali sht organizuar n shtat kapituj. N kapitullin e dyt trajtohet testimi i
software-it kryesisht testimi i gabimeve n kod. Ky kapitull jep nj pasqyr t defekteve n
software, niveleve t testimit, metodave , llojeve si dhe metrikat e testimit. Kapitulli i tret
fokusohet tek parashikimi i gabimeve n kod, cikli i jets s nj gabimi, klasifikimi dhe gjetja e
tyre, mjetet e gjurmimit dhe modelet pr parashikimin e gabimeve. Toolset e prdoruara pr
realizimin e implementimit, ku shpjegohet manuali i prdorimit dhe mnyrn se si funksionon,
jan pjes e kapitullit t katrt. Kapitulli i pest paraqet implementimin e nj rasti studimor, nj
analize e detajuar statike t realizuar me ann e CCCC tool-s i shpjeguar n kapitullin e
mparshm. Analiza dinamike dhe analiza e hollsishme e parametrave t mbulimit t kodit
sht pjes e kapitullit t gjasht. Kapitulli shtat paraqet mundsi optimizimi t kodit e cila
mund t shihet si pun n t ardhmen, pse jo futjen e inteligjencs artificiale pr kode
vetkorrigjuese.
Pr ilustrim t studimit n shtojcat e pas kapitujve do t paraqiten tabelat, gafikt pr sejcilin nga
rastet ilustrues dhe kodet burim t shkruara n java, t prdoruar pr kt studim t bre. S
fundmi paraqiten konkluzionet e nxjerra nga kjo pun si dhe referencat e prdorura.
6

2 Testimi i software-it dhe gabimet n kod
2.1 Hyrje
Software-t po bhen gjithmon e m shum kompleks dhe t shumllojshm. Si rrjedhoj
e ksaj edhe krkesat ndaj tyre jan rritur. Krkohet q software-t t ken kosto m t ult, t
ken m shum funksionalitete, t jen m t shpejt dhe me nj cilsi m t mir se m par.
Krijimi dhe zhvillimi i nj software-i kalon n disa faza, ku secila faz prdor rezultatet e fazs
s mparshme. M posht po japim nj prshkrim t shkurtr t tyre:
Specifikimi i krkesave dhe analiza kjo faz krkon t specifikohen krkesat e
prdoruesit, por edhe krkesat e vet software-it.
Projektimi krkesat e marra nga faza e par ndahen n module t pavarura duke krijuar
nivele m t vogla
Kodimi programuesit shkruajn kodin e projektit sipas gjuhs s przgjedhur t
programimit
Testimi n kt faz krijohet nj plan testimi, vihet n zbatim dhe dokumentohen
rezultatet e marra
Implementimi sht faza e instalimit t produkteve t nevojshme n mjediset prkatse
Mirmbajtja pasi sht krijuar software-i dhe ka filluar prdorimi nga prdoruesit,
mirmbajtja sht faza e rradhs
N varsi se si shfrytzohen kto faza, jan krijuar modelet e ciklit t jets s nj software-i. Disa
prej ktyre modeleve jan: modeli waterfall, V, spiral, iterativ dhe inkremental.
Figura 1 Fazat e zhvillimit t nj software
Figura 2 Modeli Waterfall
Sic shihet, testimi sht nj nga fazat e zhvillimit t nj software. Kjo faz fokusohet n nj
hetim empirik, ku rezultatet prshkruajn cilsin e sistemit. Testimi nuk mund t konfirmoj q
sistemi funksionon si duhet n t gjitha kushtet, por mund t provoj se ai dshton pr kushte t
caktuara. Sa me shpejt q t gjendet defekti gjat procesit t zhvillimit, aq m e vogl sht
kostoja e rregullimit. Testimi i hershm redukton rreziqet si vonesat ose tejkalimi i kostos. N
fazn e testimit, ai provon nse jan plotsuar t gjitha krkesat, prfshir edhe krkesat e
performancs dhe siguris. Si prfundim, testimi konfirmon q sistemi plotson krkesat e
prdoruesit dhe prmbush nevojat e biznesit.
Qllimi i fazs s testimit sht t garantoj se sistemi ka ndrtuar dhe testuar me sukses t gjitha
krkesat dhe parametrat e projektimit n fazat e mparshme. Pasi kjo faz kalohet me sukses
shkohet n fazn e implementimit.
Testimi sht nj proces q realizohet nga grupe dhe persona t ndryshm. S pari sht
menaxheri i testimit q menaxhon dhe kontrollon projektet e testimit, prcakton planin e testimit
dhe mbikqyr inxhiniert. Kta t fundit hartojn rastet e studimit (test cases), prcaktojn
specifikimet dhe ekzekutojn testet. Me testimin merren edhe grupe t pavaruara testimi. Vet
prdoruesi pfundimtar sht nj testues, i cili kontrollon nse software i plotson apo jo
krkesat. Ndarja n kt mnyr e ndihmon procesin sepse testuesit nuk kan t njjtat njohuri
pr kodin dhe brendsin e aplikacionit. sht e rndsishme q kur krijohet dhe ndrtohet nj
software t testohet hap pas hapi. Testimi n fund t projektit ka kosto m t mdha sepse sht
m e vshtir t rikthehesh n fillim pr t gjetur se ku ka ndodhur problemi dhe pr ta rregulluar
at.
Problemet m t shpeshta t software-it jan[1]:
Gabimet n llogaritje
8
Redaktimet e t dhnave jo t sakta dhe redaktimet e t dhnave jo efektive

Bashkimi dhe prputhja jo korrekte e t dhnave
Krkimet e t dhnave q japin rezultate jo korrekte
Prpunimi i pasakt i t dhnave
Kod i pasakt
Performanca e pamjaftueshme e software-it
T dhnat jo t qarta
Prdorimi i software-it nga prdoruesit prfundimtar dhe software-t e vjetruar
Prpunimi jo konsistent
Rezultatet jo t besueshme
Ndrfaqe t pamjaftueshme ose t pasakta me sistemet e tjera
2.2 Defektet n software

Defektet n sofware jan gjendje, q nuk i prgjigjen krkesave t software-it ose
pritshmrive t prdoruesit prfundimtar. Me fjal t tjera, jan gabime n kod ose gabime
logjike, te cilat cojn n keqfunksionimin e programit ose n rezultate t gabuara.
Shkalla e rndsis s defekteve ndryshon n varsi t problemit q ato shkaktojn. Jo t gjith
defektet jan serioz pr software-in. Prpara se defektet t parandalohen dhe t hiqen, sht e
nevojshme t dihet origjina e defektit dhe far e shkakton at. Jan tre kategori q shkaktojn
defektet dhe shtat origjina t tyre. Shkaqet e defekteve prfshijn[2]:
Gabimet e komisionit (sht br dika e gabuar)
Gabimet e mosveprimit (dika sht ln pa br aksidentalisht)
Gabimet e qartsis dhe dykuptimsis (dy persona kan interpretime t ndryshme)
Gabimet e komisionit i referohen problemeve t shkaktuara nga nj veprim jo korrekt, si
prfshirja e gjendjeve t caktuara n nj specifikim me t cilin jan reciprokisht kontradiktore.
40-65% e problemeve t numruara n nj software i prkasin gabimeve t komisionit, duke e
br kt kategori si shkaktaren kryesore t defekteve.
Gabimet e mosveprimit i referohen problemeve t shkaktuara nga nj dshtim pr t prfshir
informacion jetik. 15-30% e problemeve t numruara n nj software i prkasin gabimeve t
mosveprimit. Probabiliteti dhe frekuenca e ktyre defekteve sht n prpjestim t drejt me
madhsin e sistemit.
Gabimet e qartsis dhe dykuptimsis i referohen problemeve t shkaktuara nga dy ose m
shum interpretime t t njjtit informacion. Shembull i nj gabimi t till sht shprehja koh
prgjigje e shpejt, ku e shpejt nuk ka nj prcaktim fiks. Prafrsisht 5-10% e problemeve
t numruara n nj software i prkasin ktij grupi t gabimeve.
Pr sa i prket origjins s defekteve, m posht paraqitet nj list e tyre:
Defektet n krkesat e software-it

Defektet n projekt
Defektet n kod
9

Defektet n dokumentacion
Defektet Bad Fixes
Defektet n t dhna dhe tabela
Defektet n rastet e studimit (test cases)
Shkaktart e defekteve n krkesat e software-it jan t treja kategorit e msiprme, por m t
shpeshta jan gabimet e mosveprimit dhe gabimet e qartsis dhe dykuptimsis. Kto lloj
defektesh, q lindin q n fillim t projektit, nse nuk parandalohen dhe nuk hiqen deprtojn
dhe n hapat e mposhtm (projektimi, kodi dhe dokumentacioni). Jan defektet q krkojn
koston m t lart dhe q kan m shum vshtirsi n eleminimin e tyre. Pr t reduktuar kto
defekte, parandalimi sht m efikas se heqja e tyre. Vshtirsia m e madhe vjen nga krkesat
q bazohen n gjuhn natyrale. Pr ta shmagur kt, jan zhvilluar disa metoda pr ti prcaktuar
krkesat n gjuh formale, por nuk jan ende gjersisht t prdorura. Shkaktart e defekteve n
projekt jan t treja kategorit, por m t shpeshta jan gabimet e mosveprimit, ku lihen gjra pa
br, si dhe gabimet e komisionit, ku dika sht deklaruar, por rezulton e gabuar m von. Edhe
gabimet e qartsis dhe dykuptimsis jan t shpeshta dhe shum probleme q lidhen me
performancn lindin pikrisht nga ky shkak. Edhe kto defekte kan kosto t lart dhe vshtirsi
n trajtimin e tyre.
Shkaktart e defekteve n kod jan t treja kategorit, ku gabimet e komisionit jan dominante
gjat kohs s krijimit t kodit. E vecanta e defekteve n kod sht se 50% e gabimeve serioze t
gjetura n kodin burim nuk e kan origjinn nga kodi. Pjesa m e madhe gabimeve ndodhin n
rastet kur programuesi nuk e kupton qart projektin, ose kur projekti nuk i interpreton krkesat
ashtu si duhet.
Dokumentacioni pr prdoruesin si n formn e manualit, ashtu edhe n formn e informacionit
online, mbart gabime t mosveprimit dhe t komisionit. N fakt, defektet m t shpeshta i
prkasin gabimeve t qartsis dhe dykuptimsis. Fraza Bad Fixes i referohet tentativs pr t
riparuar nj gabim q edhe pse gabimi origjinal mund t jet rregulluar, paraqet ende nj gabim
n kod pr aplikacionin. Zakonisht Bad Fixes jan gabime t komisionit. Ato jan defekte t
shpeshta dhe mund t jen edhe serioze pr aplikacionin. 5-20% e tentativave pr t riparuar
gabime n kod mund t shkaktojn nj gabim t dyt n kod. Bad Fixes lidhen fort me nivelet
e larta t kompleksitetit.
Defektet e t dhnave mund t jen shum serioze dhe mund t ndrveprojn me gabimet e
software-it pr t krijuar probleme edhe m t mdha dhe me kosto m t lart. Shum nga
problemet n aplikacione njerzit i vn re tek defektet e t dhnave. Gabime t tilla si gabimet
n faturat e shrbimeve, pasqyrat financiare, gabime t taksave, regjistrimin e automjeteve
motorike jan shpesh gabime t t dhnave.
Rastet e studimit kan pr qllim t sigurojn q do karakteristik e aplikacionit punon si duhet
dhe se materialet e reja nuk kan shkaktuar gabime n pjes ekzistuese t aplikacionit. Gabimet
n rastet e studimit ndodhin kur kto raste t krijuara pr testim nuk jan t prshtatshme pr
krkesat e software-it. N rastet kur bhen ndryshime n aplikacion, prdoret testimi i regresit, q
nnkupton nj set me raste studimi. Regresi i referohet nj gabimi t ndodhur gjat prpjekjes pr
t shtuar karakteristika t reja n aplikacion.
2.3 Nivelet e testimit

Prpara se nj aplikacion t publikohet, ai i nnshtrohet nj procesi t plot t testimit pr
tu siguruar se aplikacioni punon n mnyrn n t ciln sht krkuar. Jan katr nivele testimi,
10

t cilat duhet t prmbushen para se programi t jet gati pr prdorim: testimi njsi, testimi i
integruar, testimi i sistemit, dhe testimi i pranimit.
Tetsimi njsi sht nj nivel i procesit t testimit t software-it ku tetsohen njsi ose komponente
individuale t software-it. Qllimi sht t vlersoj se do njsi e software-it performon ashtu
si sht projektuar. Ky lloj testimi krkon njohuri t kodit dhe projektit t brendshm t
programit dhe realizohet nga programuesit. Nj njsi i referohet nj funksioni, programi
individual ose nj procedure. Nj nga benefitet kryesore t ktij niveli testimi sht se mund t
ekzekutohet sa her q ndryshon nj pjes kodi, duke br t mundur q shtjet t zgjidhen sa
m shpejt t jet e mundur. Zhvilluesit e software-it realizojn testimin njsi prpara se ta
drgojn pr testimin formal[3]. Testimi i integrimit sht nj nivel i procesit t testimit t
software-it ku njsi individuale kombinohen dhe testohen n grup. Qllimi sht t vj n dukje
gabimet n ndrveprimin midis njsive t integruara. Ky nivel testimi sht projektuar pr t
gjetur defektet e ndrfaqes ndrmjet moduleve. Njsit e integruara apo grupet q testohen mund
t jen module kodi, aplikacione individuale ose aplikacione klient-server. Ky testim sht
veanrisht i dobishm sepse prcakton se sa efikasitet kan njsit t ekzekutuara s bashku.
sht me rndsi fakti se pavarsisht se nj njsi funksionon si duhet m vete, ndikon n
funksionalitetin e software-it nse nuk sht e integruar si duhet. Jan dy metoda q prdoren
pr t realizuar testimin e integrimit: testimi nga Posht-Lart (Bottom-up) dhe testimi nga LartPosht (Top-Down).
Tetsimi nga Posht-Lart fillon me testimin njsi dhe ndiqet nga testimet progresive t
kombinimeve t njsive (moduleve) t niveleve m t larta.
Testimi nga Lart-Posht teston fillimisht modulet e niveleve t larta dhe m pas teston n
mnyr progresive modulet e niveleve m t ulta.
N nj mjedis t plot t zhvillimit t software-it realizohet fillimisht testimi Posht-Lart dhe m

pas tetstimi Lart-Posht. Testimi i sistemit sht nj nivel i procesit t testimit ku testohet nj
sistem ose software i plot dhe i integruar. sht niveli i par n t cilin i gjith aplikacioni
testohet si i tr. Qllimi sht t vlersoj prputhshmrin e sistemit me krkesat specifike dhe
nse prmbush standartet e kualitetit. Ky testim kryet nga testues t pavarur, q nuk kan pasur
rol n zhvillimin e programit. sht i rndsishm sepse vren q aplikacioni plotson krkesat
teknike, funksonale dhe t biznesit ashtu si krkohen nga prdoruesi.
Testimi i pranimit sht nj nivel i procesit t testimit ku sistemi testohet pr pranueshmrin.
Qllimi sht t vlersoj prputhshmrin e sistemit me krkesat e biznesit dhe nse sht i
pranueshm pr tu shprndar. Gjate ciklit t jets s zhvillimit t software-it, ndryshimet e
krkesave mund t keqinterpretohen n nj mnyr q nuk prputhen me nevojat e prdoruesit.
Pikrisht n kt faz, prdoruesi teston nse sistemi i plotson nevojat e tij t biznesit. Pasi sht
plotsuar ky proces, ather programi sht gati pr prdorim. Ky testim vrteton dhe njher
faktin q sa m hert t bhen testimet aq m shum defekte zbulohen. Duke realizuar testimin e
pranimit n nj aplikacion, grupi i testimit nxjerr n prfundim se si do t punoj aplikacioni n
prodhim. Dallojm dy faza t testimit t pranimit: testimin Alpha dhe testimin Beta.
Testimi Alpha sht faza e par dhe duhet t performohet nga zhvilluesit dhe grupi i
kualitetit. Kombinimi i testimit njsi, testimit t integrimit dhe testimit t sistemit njihet si
testimi Alpha. N kt faz testohen gabimet drejtshkrimore, linqet e kputura, koha e
ngarkimit dhe problemet e voness.
11
Testimi Beta performohet pasi sht realizuar me sukses testimi Alpha. Vetm nj pjes
e vogl e audiencs s parashikuar teston aplikacionin. Njihet ndryshe si testimi i para
lirimit. N kt faz prdoruesi do t instaloj, ekzekutoj aplikacionin dhe do drgoj
nj analiz tek ekipi i projektit. Do t testohen gabimet tipografike, sjelljet konfuze t
aplikacionit dhe rastet e prplasjeve. Pasi merr analizn, ekipi i projektit mund t
rregulloj problemet prpara se ta dorzoj aplikacionin tek prdoruesit. Sa m shum
probleme t zgjidhura t jen, aq m e lart sht dhe cilsia e aplikacionit dhe sa m e
lart cilsia, aq m e lart dhe knaqsia e marr nga klienti.
Disa tentojn q t prfshijn n nivelet e testimit dhe testimin e regresit, por ai nuk sht i
nevojshm. Testimi i regresit sht thjesht nj lloj testimi q mund t kryhet tek secili nga katr
nivelet e msiprme.
Figura 3 Nivelet e testimit
2.4 Metodat e testimit

Rastet e studimit jan zhvilluar duke prdorur teknika t ndryshme testimi pr t arritur
nivele efektive testimi. Ka metoda t ndryshme q mund t prdoren pr testimin software-it.
Prmendim testimin Black Box, White Box dhe Gray Box[2].
Testimi Black Box sht nj teknik testimi, e cila nuk ka njohuri pr brendsin e aplikacionit
dhe se si ai punon. Testuesi sht i pavmendshm pr akitekturn e sistemit dhe nuk ka akses n
kodin burim. Gjat ktij testimi, testuesi ndrvepron me ndrfaqen e prdoruesit duke ofruar t
dhna hyrse dhe duke gjeneruar rezultate, pa ditur se ku kan vepruar t dhnat.
Avantazhet e ktij testimi jan:
T prshtatshme dhe efikase pr segmente t mdha t kodit

Nuk krkohet akses n kod
12
N mnyr t qart ndan perspektivn e prdoruesit nga perspektiva e zhvilluesit

nprmjet prcaktimit t roleve
Shum testues mund ta testojn aplikacionin pa patur njohuri pr implementimin, gjuhn
e programimit apo sistemin operativ t prdorur
Disavantazhet:
Mbulim i kufizuar sepse vetm nj pjes e przgjedhur e rasteve t studimit performohet
Testim jo efikas pr shkak se testuesi ka njohuri t kufizuara n lidhje me aplikacionin
Mbulim i verbr sepse testuesi nuk mund t synoj segmente kodi specifike apo zona t
caktuara t gabimeve
Rastet e testimit jan t vshtira pr tu projektuar
Testimi White Box sht hetim i detajuar i logjiks dhe strukturs s brendshme t kodit. Quhet
ndryshe testimi i kutis s hapur. Pr t realizuar kt testim n nj aplikacion, testuesi duhet t
ket njohuri se si punon kodi n brendsi. Gjithashtu duhet t zbuloj se cila njsi e kodit nuk
punon ashtu si duhet.
Avantazhet jan:
Ndihmon n optimizimin e kodit

Rrjeshtat e teprt t kodit mund t hiqen
Nisur nga fakti se testuesi ka njohuri pr kodin, mbulimi maksimal arrihet gjat shkrimit
t skenarit t testimit
Disavantazhet:
Ka kosto t lart
Ndonjher sht e pamundur pr t par n do cep dhe knd pr t gjetur gabime t
fshehura q mund t krijojn probleme duke qen s shum rrug mbeten pa testuar.
sht e veshtir pr t ruajtur testimin White Box duke qen se krkohet prdorimi i
mjeteve t specializuara si analizuesit e kodit apo mjetet pr debug.
Testimi Grey Box sht nj teknik testimi q krkon njohuri t limituara t puns s brendshme
t aplikacionit. Ndryshe nga testimi Black Box ku testuesi teston vetm ndrfaqen e prdoruesit,
n testimin Grey Box testuesi ka akses n bazn e t dhnave dhe n dokumentat e projektit. Me
kto njohuri testuesi sht i aft t prgatis skenare testimi dhe raste testimi m t mira gjat
hartimit t planit t testimit. Avantazhet q ofron ky testim jan:
Ofron benefite t kombinuara t testimit Black Box dhe atij White Box
Testuesit nuk mbshteten n kodin burim, por mbshteten tek krkesat funksionale dhe
prkufizimi i ndrfaqes
Testuesit mund t projektojn skenare t shklqyera testimi rreth protokolleve t
komunikimit dhe trajtimit t llojeve t t dhnave
Testimi realizohet nga pikpamja e prdoruesit dhe jo nga pikpamja e projektuesit
Disavantazhet:
Duke qen se aksesi n kodin burim nuk sht i mundur, edhe mbulimi (test coverage)
sht i limituar
13
Testet mund t jen t teprt nse projektuesi i software-it ka ekzekutuar nj rast testimi
(test case)
Testimi i do t dhne hyrse t mundshme sht i paarsyeshm sepse merr shum koh
dhe rrjedhimisht shum rrug mbeten pa testuar
N tabeln m posht paraqitet nj krahasim midis t tre metodave t testimit:

Tabela 1 Krahasimi i metodave t testimit
2.5 Llojet e testimit

Llojet e testimit fokusohen n objektiva t veanta testimi. Dallohen dy grupime t llojeve
t testmit, testmi funksional dhe testimi jo funksional. Testimi funksional i referohet aktiviteteve
q testojn nj veprim specifik ose nj funksion t kodit. Ky testim tenton ti prgjigjet pyetjeve
A mundet prdoruesi ta bj kt? ose A punon kjo karakteristik e veant. Testimi jo
funksional i referohet aspekteve t software-it, q nuk lidhen me nj funksion specifik ose me nj
veprim t prdoruesit si shkallzueshmria apo performanca ose siguria.
14

Sipas ktyre dy grupimeve ekzistojn nj numr i madh llojesh testimi. M posht do t
paraqiten vetm nj pjes e tyre.
Ndr testimet funksionale prmendim[7]:
Testimi i instalimit fokusohet n far duhet t bj klienti pr instalimin dhe

funksionimin e sakt t software-it t ri
Testimi i zhvillimit prfshin aplikacione t sinkronizuara lidhur me strategjit e
dedektimit t defekteve n mnyr q t reduktoj risqet, kohn dhe koston. Prfshin
analizat e kodit, analizat e t dhnave, testimin njsi dhe praktika t tjera verifikimi
Testimi i shndosh (sanity testing) ofron testim t shpejt dhe t plot dhe prcakton
nse sht e mundur dhe e arsyeshme pr t vazhduar testimin e mtejshm. Ky testim
sht nj mnyr pr t kursyer koh.
Testimi i rivendosjes sht testimi q tregon se sa i aft sht nj aplikacion t rikthehet
n gjendjen fillestare pas prplasjeve, dshtimeve n hardware dhe problemeve t tjera t
ngjashme.
Testimi i pranimit nga prdoruesi konsiston n verifikimin e software-it nse punon pr
prdoruesin.
Lidhur me testimet jo funksionale ndr m t shpeshtat jan:
Testimi i performancs - ka t bj me aspektet e shpejtsis, kapacitetit, stabilitetit dhe

shkallzueshmris s sistemit
Testimi i prdorshmris - lidhet me testimin e krkesave t tilla si; e leht pr tu msuar,
e leht pr tu prdorur, efient n prdorim, i knqshm n prdorim dhe i leht pr tu
kuptuar
Testimi i siguris - duhet t siguroj konfidencialitetin, integritetin, autentikimin,
disponueshmrin, sigurin e t dhnave etj.
Testimi i portabilitetit - teston nse software-i mund t riprdoret dhe t mund t
transferohet n nj tjetr kompjuter
2.6 Metrikat e testimit

Metrikat e software-it jan teknika ose formula q prdoren pr t matur disa karakteristika
t veanta t software-it. Ato lidhen drejtprdrejt me matjet dhe matjet kan rol domethns n
menaxhimin e software-it.
Metrikat e software-it jan nj guid sasiore e performancs s software-it n raport me
ndrveprimet e njriut t nevojshme q software-i t punoj. Metrikat jan zhvilluar sipas ides
se prpara se dika t matet, duhet t prkthehet n numra. Ato kan prdorim t gjer n shum
fusha.
Metrikat gjejn zbatim gjat gjith ciklit t jets s zhvillimit t nj software-i. N fillim t
projektit ato prdoren pr t prcaktar koston dhe krkesat e burimeve. Gjat fazs s projektimit
prdoren pr t numruar pikat e funksionit. Matjet pr prmasat e software-it jan nj tjetr
aspekt sasior. Pr kto matje shrbejn metrikat e kodit burim si pr shembull numri i rreshtave
t kodit. N mnyr t ngjashme edhe metrikat e detajuara t projektimit ose t strukturs s
kontrollit ojn n procesin e testimit. Gjithashtu analiza e kodit ndihmon n prmirsimin e
kostos s mirmbajtjes s software-it.
15
Matjet efektive japin objektiva t rndsishme t menaxhimit si kostoja dhe vlersimi i

burimeve. Nga sa m sipr metrikat zhvillohen pr:
Prmasat e software-it
Vlersimin e kostos
Vlersimin e prpjekjes
Cilsin e software-it
Mirmbajtjen
Modelet e besueshmris
Analizat e kompleksitetit
Analizat e defekteve
Testimin e software-it
Metrikat e software-it mund t grupohen si m posht:

1. Metrikat e procesit
2. Metrikat e produktit
3. Metrikat e burimeve
Metrikat e software-it qe lidhen me matjet e atributeve t procesit t software-it grupohen si
metrika t procesit. Kto matje prfshijn vlersimin e kohzgjatjes, vlersimin e kostos,
prpjekjen e krkuar, cilsin e procesit dhe efektivitetin e zhvillimit t procesit. Kto metrika
mund t llogariten n do hap t zhvillimit t software-it.
Shembull i metrikave t procesit sht SLOC(Source Line of Code). Numri i rreshtave t kodit
llogaritet thjesht duke i numruar ato. Ky numrim jep nj t dhn mbi prpjekjen e br pr t
zhvilluar kodin.
Matjet mbi produktin nuk prfshijn vetm dorzimin e produktit tek klienti, por gjithashtu edhe
gjith aktivitetin gjat procesit t zhvillimit si pr shembull dokumentacionin. Ekzistojn shum
metrika pr matjen e produktit. Ato shrbejn si pr matje t atributeve t jashtme ashtu edhe pr
ato t brendshme. Atributet e jashtme kan t bjn me matjet e performancs s produktit n
mjedisin aktual ku duhet t ekzekutohet software. Kto matje prfshijn prdorimin dhe
riprdorimin, portabilitetin dhe efiencn. Atributet e brendshme prfshijn prmasat e softwareit, saktsin, kompleksitetin, gabimet n kod dhe testimin.
Metrikat e burimeve jan m shum t lidhura me menaxhert pr vlersimin e burimeve t

nevojshme pr projektin. Kto burime jan fuqia njerzore (zhvilluesit), burimet fizike
(kompjuterat, materialet, metodat). Jan metrika t cilat mund t klasifikohen edhe n klasn e
metrikave t procesit.
16

3 Parashikimi i gabimeve n kod
3.1 Hyrje
Parashikimi i t ardhmes sht shum trheqs pr njerzit. T parashikosh sakt ose n
mnyr t prafrt t ndihmon t planifikosh punn me m shum efikasitet. Software-t
ndrtohen dhe tregtohen dhe shum defekte apo gabime n kod gjenden n to. Ndonjher
konsumatort duhet t presin pr nj koh t gjat pr rregullimin e tyre. Parashikimi i gabimeve
n kod sht i dobishm pr dedektimin e tyre n nj software. Ai sht gjersisht i studiuar dhe
sht nj nga temat m t nxehta t krkimeve shkencore.
Defektet n software jan gabime, t meta ose dshtime t programit q e pengojn at q t
punoj ashtu si duhet ose q prodhojn rezultate t gabuara. Gabimet n kod jan gabime q
krkojn ndryshime semantike n kod. Nse nj gabim q n hapat fillestar t programit nuk
shndrrohet n defekt, ather jemi me fat, por nse ai kthehet n defekt, ather mund t
shkaktoj dshtime dhe duhet t rregullohet.
Ka shum lloje gabimesh n kod q mund t gjenden n nj software. Gjersisht jan dy tipe
gabimesh: gabimet funksionale dhe gabimet e regresit. Gabimet funksionale n kod lidhen me
funksionalitetin e aplikacionit. Ne duhet t verifikojm rrjedhn e veprimeve dhe nse ajo sht
jo korrekte ose jo konsistente, ather raportohet si gabim q prodhon nj sjellje t papritur/jo
logjike t aplikacionit, ku rezultati final ndryshon nga rezultati i pritur. Gabimet e regresit lidhen
me ndryshimet n kodin ekzistues q ndryshojn sjelljen e aplikacionit. Pra, ai nuk sillet njsoj si
m par pas ndryshimeve n kod.
Gabimet n kod t nj software kan pasoja t shumta duke filluar nga gliet e vogla deri tek
humbje jetsh njerzish dhe t mira materiale. Pr shembull, m 1962 nj gabim kodi n
kontrollin e fluturimit shaktoi devijimin e rakets nga rruga e prcaktuar. Kjo shkaktoi dshtimin
e misionit. M 1988 m shum se 2000 kompjutera u infektuan nga krimbi i par kompjuterik,
i cili u b i mundur nga nj gabim n kod n nj program Unix. Prgjithsisht prdoren proceset
e rregullimit (debugging) pr t gjetur dhe pr t eleminuar gabimet nga nj program. Procesi
tradicional i rregullimit krkon rishikim e kodit, prdorimin e mjeteve t prshtatshme, testimet e
llojeve t ndryshme (t regresit apo t njsis) dhe srish rishikimin e kodit. Pra, sht nj pun e
lodhshme dhe q krkon shum koh. Pas gjith ktyre problemeve mund t themi se
parashikimi i gabimeve n kod sht mnyra m e mir pr t gjetur gabimet dhe pr t
prmirsuar cilsin e software-it[8].
Pr t identifikuar gabimet n kod jan dy teknika. E para dedektimi i gabimeve n kod dhe e
dyta parashikimi i gabimeve n kod. N dedektimin e gabimeve n kod, kur programi dshton
kemi mjaftueshm probleme. Ndoshta me t rrezikshm mund t jen gabimet e padedektuara, t
cilat veprojn n heshtje. Kur nj gabim n kod dedektohet n nj software, procesi i rregullimit
fillon t gjej vendodhjen korrekte t ktij gabimi. Dedektimi sht nj proces q konsumon
koh dhe fillon n momentin kur gjendet nj gabim n software. Identifikimi i moduleve t
prirura pr t qen difektoz sht detyr e rndsishme pr menaxhimin. Parashikimi i gabimeve
17

n kod luan rol t rndsishm n zhvillimin software-it. Ai deprton n mirmbajtjen e
software-it n mnyr q menaxhimi dhe skuadra e testimit mund t analizoj informacionin pr
t prmirsuar cilsin e software-it.
Parashikimi mund t realizohet me dy mnyra: me intuit dhe bazuar tek t dhenat. Parashikimi
me intuit nuk prodhon rezultat t sakt, madje shpesh on drejt vendimeve t gabuara. Mnyra
m e mir sht parashikimi bazuar tek t dhnat. Shume parashikime n kod jan propozuar t
trajtojn problemet e software-it duke u mbeshtetur tek infrormacioni i ndryshm si metrikat e
kodit, metrikat e procesit ose n defektet e mparshme.
Disa shtje q lidhen me parashikim e gabimeve n kod jan:
Parashikimi i bazuar tek ndryshimet

Parashikimi i bazuar tek problemet
Parashikimi i bazuar tek metrikat
Parashikimi i bazuar tek klasifikimi
Parashikimi i bazuar tek ndryshimet ndihmon zhvilluesit nprmjet rekomandimeve t entiteteve

t programit q duhet t ndryshohen s bashku me entitetet q tashm jan ndryshuar.
Ndryshimet jan studiuar n disa nivele; n nivel klase, n nivel metode dhe n nivel skedari.
N parashikimin e bazuar tek problemet prfshihen ngjarjet si prodhimi i adresave dhe vlerave
jasht kufirit, ekzekutimi i rrugve t pazakonta t kontrollit, shkaktimi i dshtimeve, llogaritjet e
teprta, gjenerimi i alarmeve false dhe shum t tjera.
Parashikimi bazuar tek metrikat prdor metrikat e marra nga t dhnat historike t projektit
prpara se produkti t prodhohet. Premton mbshtetje m t mir pr menaxhert duke ofruar
parshikimin e defekteve.
Parashikimi i bazuar tek klasifikimi parashikon ndryshimet nse kemi t bjm me gabim ose jo.
Sipas ktij parashikimi prcaktohet se sa sakt sht parshikuar gabimi dhe sa % duhet ti
nnshtrohen nj kontrolli t dyt.
Parashikimi i gabimeve n kod vazhdon t jet ende nj fush e re. Ai nuk mund t qndroj
vetm n kornizat e shtjeve t prmendura m lart. sht nj fush premtuese, e cila ndihmon
n identifikimin e gabimve q n faza t hershme pr t prmirsuar cilsin e software-it dhe
pr t prmbushur krkesat e prdoruesve.
3.2 Cikli i jets s nj gabimi n kod

Cikli i jets s nj gabimi n kod sht cikli q prshkon nj defekt gjat gjith ekzistencs
s tij. Ai fillon n momentin q defekti gjendet dhe prfundon n momentin q defekti mbyllet
n mnyr q t mos prsritet m. Gabimet n kod kalojn n gjendje t ndryshme gjat gjith
ciklit t jets s tij. N figur paraqitet diagrama e gjendjeve n t cilat kalon gabimi n kod[13]:
18
Figura 4 Cikli i jets s nj gabimi n kod
E re sht gjendja ku defekti regjistrohet dhe njoftohet pr ekzistencen e tij pr her t par.
Caktuar pasi testuesi ka njoftuar pr pranin e gabimit n kod, provohet q gabimi n kod sht
i vrtet dhe i caktohet ekipit prkats t zhvilluesve.
Hapur n kt gjendje zhvilluesi ka filluar analizn dhe punn pr t rregulluar defektin.
Rregulluar pasi zhvilluesi ka br ndryshimet e nevojshme n kod dhe i ka verifikuar kto
ndryshime, gjendja e gabimit n kod kalon n gjendjen e rregulluar dhe gabimi n kod i kalon
grupit t testimit.
N pritje t ritestimit pasi sht rregulluar defekti, zhvilluesi ia jep kodin specifik testuesve pr
ritestim. N kt gjendje testimi sht n pritje t prfundimit t puns s testuesve.
Ritestimi n kt gjendje testuesi riteston ndryshimet e bra n kod n fazn e mparshme pr
t kontrolluar nse defekti sht rregulluar apo jo.
19

Verifikuar tetsuesi teston srish gabimin n kod pasi sht rregulluar. Nse ai nuk sht m
prezent n software, ai konfirmon se gabimi n kod sht rregulluar dhe statusi tashm kalon n i
verifikuar.
Rihapur nse gabimi n kod sht ende i pranishm edhe pasi sht rregulluar nga zhvilluesi
kalohet n gjendjen reopen, ku gabimi n kod duhet ti nnshtrohet dhe njher t gjith
hapava nga fillimi.
Mbyllur pasi gabimi n kod sht rregulluar, testohet nga testuesit. Nse ai prfundimisht nuk
sht i pranishm n software, kalohet n gjendjen i mbbyllur. Kjo gjendje do t thot se gabimi
n kod sht rregulluar, testuar dhe miratuar.
Dublikuar - sht gjendja ku gabimi n kod prsritet dy her ose dy gabime t ndryshme n kod
kan t njjtin koncept.
Refuzuar nse zhvilluesi kupton q gabimi n kod nuk sht i vrtet, ai e refuzon at.
Shtyr pr m von gabimi n kod i vendosur n kt gjendje do t thot q pritet t rregullohet
m von. Arsyet pse gabimet n kod vendosen n kt gjendje varen nga shum faktor. Disa
faktor mund t jen: prioritet i ult i gabimit n kod, mungesa e kohs pr ta rregulluar at ose
gabimi n kod mund t mos ket efekt t madh n software.
Jo nj gabim n kod - kjo gjendje vendoset n rastet kur nuk ka ndryshime n funksionalitetin e
aplikacionit. Pr shembull: nse klienti krkon disa ndryshime n pamjen e aplikacionit apo n
fusha t tilla si ndryshimi i ngjyrs ose tekstit, ky nuk sht nj gabim n kod. sht thjesht nj
ndryshim n dukjen e aplikacionit.
3.3 Klasifikimi
Shumica e gabimeve n kod ndodhin nga gabimet e bra nga njerzit n kodin burim ose
n dizajn dhe pak shkaktohen nga kompilimi q prodhon kod t pasakt. Nj program q ka nj
numr t madh gabimesh n kod q ndikojn seriozisht funksionalitetin e tij thuhet t jet nj
program me problem (buggy). Ekzistojn raporte q raportojn n mnyr t detajuar gabimet n
kod q ka nj program. Ato njihen si raportet e gabimeve n kod, raportet e defekteve, raportet e
problemeve etj.
Gabimet n kod shkaktojn problem q mund t ken nj shumllojshmri efektesh me nivele t
ndryshme t shqetesimit pr prdoruesin e programit. Disa gabime n kod mund t ken nj efekt
jo shum t dukshm n funksionalitetin e programit dhe n kt mnyr mund t mos
dedektohen pr nj koh t gjat. Gabimet n kod m serioze mund t shkaktojn ngrirje t
programit ose shkatrrim. T tjer gabime t kualifikuar si gabime n kod t siguris mund t
lejojn prdorues me qllim t keq t anashkalojn kontrollet e aksesit me qllim q t marrin
privilegje t paautorizuara.
20

N projektet e zhvillimit t software-it, nj gabim mund t ndodh n seciln nga fazat e
zhvillimit. Gabimet n kod jan pasoj e faktorit njeri n programim. Ato lindin nga
anashkalimet apo keqkuptimet e bra nga grupi i software-it gjat specifikimit, projektimit,
kodimit, futjes s t dhnave apo dokumentimit. Gabimet m komplekse n kod mund t lindin
nga ndrveprime ndrmjet pjesve t ndryshme t nj programi. Kjo shpesh ndodh sepse
programet mund t jen komplekse, t programuara nga shum njerz pr nj koh t gjat.
Nj gabim q n momentin e shfaqjes s tij deri n fazn finale pson transformime.
Metamorfoza e nj gabimi paraqitet n hapat e mposhtm:
Gabim
Anomali
Dshtim
Pasaktsi
Prjashtim
Shkatrrim
Gabime n kod
Defekt
Incident
Efekt ansor
sht e natyrshme q software-t t ken gabime n kod q nuk konsiderohen kritik dhe q nuk
ndikojn tek prdoruesi. Duke qen se software-t kan nj numr t panjohur gabimesh n kod,
matjet gjat testimit mund t ofrojn nj vlersim t gabimeve n kod duke e br m t
besueshm produktin. Pjesa m e madhe e projekteve t software-it prmban dy lloje t
gabimeve n kod ato q njihen nga ekipi i software-it dhe ato q duhet ti bhen t ditura
prdoruesit. Lloji i dyt informon prdoruesit pr gabimet n kod q nuk jan rregulluar.
Ka shum arsye pse nj gabim n kod nuk mund t rregullohet. Zhvilluesit shpesh nuk kan
kohn e mjaftueshme apo mundsi ekonomike pr t rregulluar t gjith gabimet jo serioze. Nj
tjetr arsye sht se gabimet n kod krkojn t rregullohen n ndonj version t ri q ende nuk
sht i njohur. Nga ana tjetr ndryshimet n kod mund t jen t mdha, t shtrenjta ose mund t
vonojn prfundimin e projektit. Edhe gabimet n kod q n dukje jan t thjesht mund t ojn
n krijimn e gabimeve t reja n kod t panjohura n sistem.
Gabimet n kod kategorizohen nga pesha q kan dhe disa kompani tolerojn gabimet jo kritike
n kod m pesh t ult sepse ato nuk ndikojn n funksionimin si duhet t sistemit.
Pesha e nj gabimi n kod nuk sht njsoj si rndsia e rregullimit t tij. Secila prej tyre mund t
matet dhe menaxhohet n mnyr t veant. Ky balanc varet nga shum faktor dhe pr t patur
nj ekuilibr sa m t mir disa zhvillues software-i prdorin nj proces t formalizuar t
przgjedhjes s gabimit n kod. N kt proces secilit gabim n kod i caktohet nj prioritet
bazuar n peshn e tij, frekuencn, rrezikun dhe faktor t tjer.
Disa nga llojet m t shpeshta t gabimeve n kod jan[10]:
21

Gabimet konceptuale, t cilat jan korrekte nga ana e sintakss s kodit, por sillen n nj
mnyr tjetr nga ajo q sht parashikuar nga projektuesi.
Gabime arithmetike n kod jan gabime q vijn nga logjika matematike. T tilla mund t jen
pjestimi me zero, mbiderdhja ose nnderdhja dhe humbja e preizionit matematik pr shkak t
rrumbullakimit.
Gabime logjike n kod prfshijn problemet q vijn nga ciklet e pafundm apo rekursioni i
pafundm.
Gabime sintaksore n kod jan problemet q lindin nga sintaksa e gjuhs si prdorimi i
operatorve t gabuar. Shembull sht ngatrrimi i barazimit me vlerdhnien (== dhe =).
Gabime n kod multi-threading sjellin problemet e njohura si deadlock, kushtet e gars ku nj
kompjuter nuk performon detyrat sipas rradhs q ka menduar programuesi dhe problemet e
konkurrencs.
Gabimet e ndrfaqes n kod lidhen me prdorimin e gabuar t ndrfaqes. Probleme t tjera jan
dhe implementimi i pasakt i protokolleve, menaxhim jo i mir i hardware-it dhe hipoteza t
pasakta lidhur me nj platform t caktuar.
Gabimet e performancs n kod kan t bjn me kompleksitetin e lart llogarits s
algoritmave apo me akseset n memorje.
Prve tipit, nj tjetr klasifikim i gabimeve n kod bhet nga pesha q ata kan n nj
aplikacion. Kategorit kryesore jan:
Bllokues jan gabimet n kod me prioritetin m t lart.

Kritike jan gabime kritike n kod pr funksionalitetin baz t aplikacionit dhe pr t
cilat nuk ka rrugzgjidhje. Kto gabime n kod duhet t rregullohen prpara se
aplikacioni t dal pr publikun. Gabime kiritike n kod jan shum t rrall dhe
klasifikohen si t till vetm n rastet kur vonohet nisja e produktit pr shkak t tij.
Shembuj t gabimeve n kod kritike mund t jen: t mos hyjm dot n nj faqe t
caktuar, t mos bsh dot pagesn me kart, t mos marrsh dhe drgosh dot email etj.
E lart gabime n kod q lidhen me funksionalitetin baz t aplikacionit, por q nuk
duhet t rregullohen me patjetr para se produkti t lanohet. Gjithsesi kto gabime n
kod duhet t rregullohen sa m shpejt t jet e mundur.
Mesatare gabime n kod q nuk prekin pjes kritike t funksionalitetit t aplikacionit.
Gabimet n kod me nj pesh mesatare kan rrugzgjidhje q i lejojn prdoruesit t
kryejn detyrn e duhur.
I ult gabime n kod q nuk ndikojn n funksionalitetin e aplikacionit dhe q mund t
mbeten pa rregulluar.
22

3.4 Gjetja e gabimeve n kod dhe mjetet e gjurmimit
Gjetja e gabimeve n kod sht nj sistem q sht i domosdoshm pr do sistem q do t
performoj mir. sht nj mjet q lehtson rregullimin e shpejt t gabimeve n kod dhe
siguron cilsin e software-it. Kto sisteme jan t prdorura gjersisht dhe trajtohen si
thelbsore n gjetjen e statusit t gabimeve n kod dhe n zgjidhjen e shpejt t tyre duke
garantuar ecurin e projektit. Potenciali dhe qndrueshmria e nj sistemi t mir gjurmimi t
gabimeve n kod ndihmon sistemin pr t rritur cilsin pr t prmbushur pritshmrit e
klientve. Inxhiniert shpesh prdorin raportet e gabimeve n kod dhe prpiqen ti rregullojn
nse krkohet informacion i mjaftueshm. Raportet e pamjaftueshme ose t paprshtatshme
shkaktojn vonesa n rregullimin e gabimeve n kod dhe si pasoj shkaktojn shkeljen e afateve.
Disa nga informasionet q prfshihen n raport jan fotot, rastet e testimit, sjellja q pritet dhe
sjellja e vzhguar. N prgjithsi ky sht informacioni q nevojitet pr rregullimin e nj gabimi
n kod. Megjithat sht zbuluar se raportuesit i ln jasht kto fusha thelbsore n raportet e
tyre duke i br kto raporte t vakt dhe t projektuar dobt. Kur zhvilluesit kan nevoj pr
informacion t detajuar dhe raportet i paraqesin mungesa, kjo on n zvarritjen e projektit ose n
vonesa n prfundimin e tij. Problem kryesor n sistemet e gjurmimit t gabimeve n kod sht
se ata thjesht ruajn disa fusha t informacionit n bazn e t dhnave, por nuk kan natyr
prshkruese. Nj raport duhet t jet specifik, jo i dykuptimt apo i dyshimt dhe i detajuar.
Gjithashtu duhet t jet raport minimal dhe unik.
Sistemet e gjurmimit t gabimeve n kod ndryshojn shum nga madhsia, qllimi dhe metodat.
Nga njra an jan sisteme t thjeshta me nj qllim, kurse nga ana tjetr jan sisteme t plota
menaxhimi q kontrollojn do aspekt t procesit t zhvillimit t software-it. Megjithat qllimet
kryesore t ktyre sistemeve mbeten konstante. Ato jan:
Para s gjithash, sigurojn q nuk kemi harruar asnj gabim n kod
Duke ofruar nj standard pr raportet e gabimeve n kod, rrisin shanset q t prfshihet i

gjith informacioni i nevojshm
Si nj gjurm auditimi, sigurojn q pr do lanim t dim cilat gabime n kod jan t
pazgjidhura, cilat t rregulluara, kush i ka zgjidhur dhe si i ka zgjidhur.
Japin mundsin pr t prcaktuar prioritetet e gabimeve n kod dhe t prcaktojm se
cili duhet t zgjidhet i pari.
Duke ofruar nj mnyr komunikimi midis aktorve t ndryshm, sigurojn q t gjith
t kuptojn gjendjen aktuale t gabimeve n kod dhe q i gjith informacioni i
rndsishm lviz midis individve ose ekipeve.
Si mjete t menaxhimit, ofrojn nj pasqyr t gjendjes aktuale t projektit.
N raste t rralla q zgjidhet t mos rregullohen gabimet n kod, mund t ruajm arsyet e
ktij vendimi n mnyr q t mos prsrisim procesin n t ardhmen.
Megjithat sistemet e gjurmimit t gabimeve n kod jan t mira nse sht i mir dhe
informacioni q ata mbartin.
Pothuajse do sistem i gjurmimit t gabimeve n kod ka nj mjedis t caktur n t cilin vepron.
Nse punojm me software desktop, ky mund t prdoret pr t regjistruar gabime n kod q
ndodhin n sistemin operativ. Pr aplikacionet web, mjedisi sht browser-i. Megjithat kjo nuk
23

sht e mjaftueshme. S pari sepse prdoruesit q nuk e njohin pjesn teknike nuk kan asnj ide
pr mjedisin e tyre dhe s dyti mjediset kompjuterike jan br me t komplikuara dhe m t
ndrlidhura.
3.4.1
Sisteme efektive n gjurmimin e gabimeve n kod
Inxhiniert e software-it shpesh prfshihen n rregullimin e gabimeve n kod gjat fazs

s zhvillimit. Koha q shpenzohet pr kt mund t reduktohet dhe cilsia e software-it mund t
rritet duke prdorur nj sistem efektiv t gjurmimit t gabimeve n kod. Informacioni fillestar
mund t ndihmoj n zgjidhjen e shpejt t gabimeve n kod duke kursyer koh dhe kosto. Gjat
nj periudh koh, zhvilluesit mund t reduktojn shum harxhimin e kohs me nj sistem t
sofistikuar t gjurmimit t gabimeve n kod. N figurn m posht paraqitet nj struktur
konceptuale, q ofron drejtime q mund t prmirsojn kto sisteme[35].
Figura 5 Drejtimet pr t prmirsuar sistemet e gjurmimit t gabimeve n kod
Orientuar nga mjetet rekomandohet q sistemet e gjurmimit t gabimeve n kod t jen t

orientuara nga mjetet. Kjo nuk do t thot q kto sisteme do t konfigurohen pr t mbledhur
gjurm q do t vendosen n raportet q prmbajn detajet e gabimeve n kod. Duke vepruar
kshtu mund t prmirsoj aftsit e mbledhjes s informacionit. Orientimi nga mjetet mund t
prmirsoj aftsin e sistemeve t gjurmimit t gabimeve n kod n mbledhjen e informacionit
q sht shum e rndsishme dhe mund t prdoret lehtsisht n rregullimin e gabimeve n kod
n sistem. Kjo do t oj n gjurmimin efektiv dhe rezultatet n cilsin e software-it prve
faktit t t qenit produktiv.
Orientuar nga informacioni ky sht nj drejtim q ndihmon zhvilluesit e software-it t
prmirsojn mbledhjen e informacionit q do t shkruhet te raportet. Pr kt qllim disa lloje
mjetesh duhet t prfshihen n sistemet e gjurmimit. Kto mjete verifikojn informacionin e
ofruar n raportet e gabimeve n kod dhe ofrojn reagimet q ndihmon n prmirsimin e
cilsis s informacionit. Kjo ndihmon edhe inxhiniert t jen t motivuar dhe m t
prqndruar n zgjidhjen e gabimeve n kod. Orientimi nga informacioni me mbshtetjen e
mjeteve t caktuara rrit mundsit pr t kontrolluar nse raportet e gjurmve jan t plota dhe
konsistente.
24

Orientuar nga procesi procesi n nj sistem gjurmimi mund t prmirsohet n kt drejtim.
Kjo do t thot q t gjitha aktivitetet administrative lidhur me gjurmimin dhe rregullimin e
gabimeve n kod vendosen nn funksionin e orientuar nga procesi. Kto sisteme fokusohen
gjithashtu edhe tek zhvilluesi q sht prgjegjs pr rregullimin e gabimeve n kod. Avantazh i
ktyre sistemeve sht se zhvilluesit kan vetdije m t plot lidhur me raportet e gabimeve n
kod. N kt mnyr ata jan m t vetdijshm pr veprimet q do t ndrmeren. Gjithashtu i
ndihmon ata t vlersojne kohn e shpenzuar n nj gabim kodi specifik dhe t planifikojn
kohn n prputhje me rrethanat.
Orientuar nga prdoruesi prdorues do t thot zhvilluesit dhe raportuesit e gabimeve n kod.
Ky drejtim fokusohet n edukimin e raportuesve n mnyr q tju mundsoj atyre t mbledhin
informacionin n mnyr korrekte dhe se si ta mbledhin at. Ndihmon si raportuesit, ashtu edhe
zhvilluesit. Informacioni i duhur n nj raport e bn zhvilluesin ta kuptoj m shpejt dhe t
veproj m shpejt pr rregullimin e gabimeve n kod. Ky drejtim ndikon n prshtatjen e mjeteve
t reja n proces, duke e br at m t fuqishm dhe produktiv.
3.5 Modelet e parashikimit t gabimeve n kod

Modelet e parashikimit t gabimeve n kod jan modele q krijohen paraprakisht pr t
identifikuar pjest e prirura pr t pasur gabime. Si fillim duhet t identifikohen komponentet e
sistemit q jan m kritike n lidhje me defektet. Modelet kombinojn metodat dhe teknikat e t
dhnave, t statistikave dhe algoritmave t makinave. N figurn e mposhtme paraqiten n
mnyr skematike disa modele t parashikimit t gabimeve n kod bazuar tek metrikat.
Figura 6 Parashikimi i gabimeve n kod
25

3.5.1
Metrikat e bazuar tek ndryshimet
Jan mats t procesit. Ato reflektojn aktivitetet e zhvillimit. Modulet me shum defekte n t
kaluarn kan shum mundsi t jen difektoz n t ardhmen. Gjithashtu modulet t cilt
ndryshojn shpesh kan shanse m t larta pr t qen t ndikuar nga defektet. Metrikat e
bazuara tek ndryshimet e bra n kod bazohen n tre teknika:
1. Gabimet e mparshme n kod
Angazhohet n sistemet e kontrollit. sht matje n nivel skedari. Pra, jan skedart ato q
ndryshojn. Quhet ndryshe struktur e ashpr.
2. Code churn
Code churn mat ndryshimet e bra n kodin baz pr nj periudh kohe dhe sht nj mnyr pr
t prcaktuar sasin e ktyre ndryshimeve. Ai sht i rndsishm pr skuadrn e zhvilluesve t
software-it sepse mund t prdoret pr t parashikuar densitetin e defekteve. Problemi me
metrikat sht se ato mund t shkaktohen nga shum gjra. Ka dy lloje matjesh: matjet absolute
dhe matjet relative. N tabeln e mposhtme jepet nj prshkrim i shkurtr i tyre[18].
Tabela 2 Matjet absolute dhe relative duke prdorur Code Churn
3. Struktur delikate e ndryshimit t kodit (SCC)

Code Churn e shpjeguar m lart sht nj matje q nuk mund t kap dot ndryshimet semantike
t bra n kod, por vetm rrjeshtat e modifikuar. Pr t rregulluar kt mangsi prdoret SCC, e
cila mat ndryshimet semantike.
Parashikimi i gabimeve n kod n nivel metode
26

Parashikimi n nj struktur delikate, i cili prfaqson nivelin e metods krkohet sepse mund t
paraqes rezultate interesante krahasuar me parashikimin me strukturn e ashpr (nivel skederi
dhe pakete). Kto rezultate prfshijn perfomancn dhe gjetje t reja midis korrelacionit t
gabimeve n kod me historikun.
3.5.2
Metrikat e kodit
Metrikat e kodit jan nj set matjesh n software q i ofrojn zhvilluesve informacione

m t mira lidhur me kodin q ata po zhvillojn. Duke prfituar nga avantazhet e metrikave t
kodit, ata mund t kuptojn se cilat lloje ose metoda duhet t ripunohen ose testohen m n
thellsi. Mund t identifikojn rreziqet e mundshme, t kuptojn gjendjen aktuale t projektit dhe
t ndjekin procesin gjat zhvillimit t software-it.
Kto metrika llogariten direkt n kod dhe variojn nga prmasat dhe kompleksiteti. Sa m t
mdhenj dhe kompleks t jen modulet, aq m e vshtir sht ti kuptosh dhe ti ndryshosh. Ato
vlersojn numrin e gabimeve t ndodhura n kod duke br dy lloje analizash: analiza statike
dhe analiza dinamike. Gjithashtu llogarit dshtimet n t ardhmen.
Analiza statike:
Halsteads software physics
n1 = nr. i operatorve t dukshm n program
n2 = nr. i operandeve t dukshm n program
N1 = nr. total i operatorve
N2 = nr. total i operandve
Gjatsia e programit: N = N1 + N2
Vllimi i programit: V = N log2 (n1 + n2), prfaqson volumin e informacionit (n bit).
Niveli i abstraksionit: L = (2 * n2) / (n1 * N2)
Prpjekja e programit: E = (n1 +N2 * (N1 + N2) * log2 (n1 + n2)) / (2 * n2)
McCabes Cyclomatic Complexity
Vshtirsia e t kuptuarit nj program prcaktohet nga kompleksiteti i grafit (Control Flow
Graph). Numri cyclomatic V i nj grafi t lidhur G sht numri i rrugve t pavarura lineare n
graf ose numri i rajoneve n nj graf t shesht. McCabe rekomandon q maksimimumi i V(G) t
jet 10[17].
Analiza statike ka disa probleme:

Nuk ndryshon me ndryshimin e programit
27

Korrelacion t lart me prmasat e programit
Nuk ka arsye intuitive pr shum metrika
Injoron shum faktor: p.sh. mjedisin e llogaritjeve, zonn e aplikacionit, algoritmat e
implementuar, karakteristikat e prdoruesve, aftsin e prgramuesve.
Prgramuesit mund t prezantojn m shum kompleksitet t panjohur n mnyr q t
minimizojn karakteristikat e matura nga metrika te veanta.
Analiza dinamike:
Vlerson numrin e gabimeve t kodit q kan mbetur me ato t gjetura. Jan dy modele: modeli i
numrimit t dshtimeve dhe modeli i numrimit t gabimeve. T vlersosh gabimet e mbetura
n kod ka kuptimin e performancs s programit, jo t numrit t gabimeve n kod q prmban.
Normat e dshtimit:
Jan modele input-domain. Vlerson besueshmrin e programit nprmjet rasteve t testimit.
Ndahet domaini i t dhnave n klasa ekuivalente. Secila klas shoqrohet me nj rrug t
programit. Llogarisin probabilitetin e kushtzuar pr t gjitha hyrjet e mundshme duke patur
parasysh q sht i sakt pr nj set specifik t t dhnave.
Besueshmria e software-it: ka t bj me portabilitetin e nj programi, i cili mund t performoj
funksionet e tij specifik pr nj gjendje t caktuar n kushte t caktuara. Ekzekutimi i
programeve derisa t ndodh nj dshtim, gjetja e gabimit, heqja e tij dhe vazhdimi i ekzekutimit.
Prdor nj funksion probabilitar t shprndar pr t parashikuar dshtimet n t ardhmen.
Problemet me modelet e besueshmris s software-it:
Nuk ka nj realitet fizik ku t bazohen hipotezat
Hipotezat nuk jan gjithmon t vlefshme pr t gjith dhe pr do lloj programi
Krkesat e mbledhjes s t dhnave mund t jen jo praktike
Metrikat e krkesave t software-it:
Fuqi e kufizuar parashikuese
Pikat e funksionit
1. Numrimi i hyrjeve dhe daljeve, skedart e prdorur, ndrfaqet e jashtme.
2. Vlersimi i secilit pr kompleksitetin dhe shumimin nprmjet nj faktori
ponderimi
3. Prdoret pr t parashikuar prmasat ose koston dhe pr t vlersuar
produktivitetin e projektit.
Numrin e gabimeve t gjetura (vlersimi i cilsis)
Ndryshimi i frekuencs s krkuar
1. Vlerson qndrueshmrin e krkesave
2. Frekuenca duhet t zvoglohet me kohn
Dallojm dy grupime t mdha t metrikave t kodit:
28

1) Metrikat e orientuara nga objekti
Qllimi i prdorimit t metrikave t orientuara nga objekti sht t vlersoj sistemin n mnyr
q t prodhoj rezultate t cilsis s lart. Vlefshmria e ktyre metrikave krkon bindshm t
demostroj q metrikat jan matur ashtu si duhet dhe se ato jan t lidhura me nj metrik t
jashtme si besueshmria, mirmbajtja dhe ekzpozimi ndaj dshtimeve.
Metrikat baz q llogariten jan:
iftimi
Kohezioni
Enkapsulimi
Trashgimnia
Kompleksiteti
Prve ktyre ka dhe matje shtes:
Numri i klasave
Numri i rreshtave t kodit
2) Metrikat n nivel funksioni
Llogariten tre tipe t metrikave t nivelit t funksioneve: metrikat prjashtuese, metrikat
prfshirse dhe metrikat e atributeve. Metrikat prjashtuese llogariten nga ngjarjet q ndodhin n
brendsi t funksionit. Ato prjashtojn metrikat q vijn nga thirrjet e funksioneve t tjera.
Metrikat prfshirse llogariten nga ngjarjet q ndodhin brenda funksionit dhe do funksioni q ai
thrret. Ato prfshijn metrikat q vijn nga thirrjet e funksioneve t tjera. Metrikat e atributeve
tregojn se sa metrika prfshirse vijn nga thirrjet e funksioneve t tjera ose nga funksionet e
tjera.
Pr nj funksion q paraqitet n fund t stivs, metrikat prjashtuese dhe prfshirse jan njsoj.
Kto metrika prdoren edhe pr objektet e ngarkess. Metrikat prjshtuese llogariten si shum e
metrikave n nivel funksioni, kurse metrikat prfshirse llogariten njsoj si pr funksionet.
Metrikat prjashtuese dhe prfshirse pr nj funksion japin informacion pr t gjitha rrugt e
regjistruara gjat funksionit. Metrikat e atributeve japin informacione pr rrug t veanta. Ato
tregojn se sa metrika vijn nga nj funksion i veant. Dy funksionet e prfshira n nj thirrje
jan thirrsi dhe i thirruri.
Lidhja midis ktyre metrikave shprehet me ekuacionin e mposhtm:
29

3.5.3
Metrikat e organizimit
Struktura e organizimit dhe rregullat ndikojn n kualitetin e software-it. Jan metrika q

kan t bjn me performancn. Edhe kto metrika ndahen n dy grupime kryesore:
Struktura e skuadrs
Struktura e skuadrs sht nj struktur e re organizative, m pak hierarkike, ku individt
grupohen n skuadra. Skuadra formohet nga njerz me aftsi plotsuese dhe prpjekje
bashkpunuese q punojn pr nj qllim t prbashkt. N nj organizim t gjer mund t jen
shum skuadra. Skuadrat ndryshojn me kohn dhe mund t prfshijn antar me funksione t
ndryshme. Edhe pse konsiderohen si jo shum hierarkike, ato prsri kan nj struktur
menaxhimi. Avantazhet e ksaj strukture jan:
Krkon m pak menaxhim

Prmirson marrdhniet
Rrit produktivitetin
Balancimi
Figura 7 Struktura e skuadrs
Struktura e kontributit
sht nj struktur q tregon se si ndikon ndryshimi i nj skedari dhe se si ky ndryshim

shprndahet tek zhvilluesit. Bazuar n koeficientin e Ginit ajo llogarit pabarazin. Kurba e
Lorenz sht nj metod grafike q shpreh pabarazin. N figurn e mposhtme tregohet grafiku i
kurbs s Lorenz n kushtet e parashikimit t gabimeve n kod, ku n boshtin e x-eve vendosen
zhvilluesit dhe n boshtin e y-eve burimet. Vija diagonale n grafik shpreh barazin ideale, ku t
gjjith kan t njjtin akses tek burimet. Devijimi nga diagonalja tregon pa barazin, ku nj
individ zotron gjithka[23].
30
Figura 8 Grafiku i kurbs s Lorenz
31

4 Mjetet e prdorura
4.1 SOTA
SOTA sht shpikur nga Ronney Treybe si pjes e tezs s diploms s tij. sht nj mjet
pr analizn e programeve statike dhe testimin e programeve t orientuar nga struktura (Structure
Oriented Test and Analysis).
Analiza statike e komponenteve t programit siguron disa metrika software-ike si kompleksiteti
thelbsor apo iklomatik si graf pr kontrollin e rrjedhs s do metode (pr analizn grafike t
testcase-ve t ekzekutuara. Pr m shum ofron disa mats t mbulimit t kodit si C0, C1, C2,
C3, MMCC and MCDC. Kodi vizualizohet n termat e CFG (Control Flow Graph). CFG
gjenerohet pa nevojn e kompilimit dhe ekzekutimin e software-it nn testim .
Pr m shum pr analizn e kodeve statike SOTA, siguron metrikat e kompleksitetin
ciklomatik, rrjeshtat e kodit, kompleksitetin esencial, degt.
Figura 9 Paraqitja grafike e SOTA
Detyrat e SOTA-s:
Bn llogaritjen e metrikave t ndryshme statike

Kontrollon mbulimin t kodit burim n testim pr nj set t dhn test case-esh
Prgatit informacionin vizualisht
Informacion i fituar lejon nj vlersim t cilsis s testimit t programit. Programi kontrollon

seksionet e kodit t mbuluar ose jo (d.m.th nuk jane testuar sa duhet kushtet ), pr nj set t
dhn testcase-esh. Pra, SOTA nuk sht drejtprdrejt prgjegjs pr testim, ajo sht nj ndihm
pr t vlersuar zhvillimin e testcase-eve shtese. [7].
32

4.1.1
Si punon SOTA
SOTA prcakton mbulimin nga instrumentimi i kodit burim. Instrumentimi sht

pasurimi i kodit original npm shtimit t shprehjev, thyerjene e kushteve, transformimin e
cikleve.
SOTA suporton :
Analizen statike t programeve

Analizen dinamike t programeve
N analizn statike kodi burim i programit sht analizuar dhe rezultatet prcaktohen prmes
dhjet mateseve sic paraqiten n figur.
Figura 10 Matsit e analizs statike
Analiza dinamike varet nga nj testcase-et specifice. Pr t realizuar kt gj SOTA ka

prcaktuar nnt kritere mbulimi gjat ekzekutimit t programi t paraqitur m posht.
Figura 11 Matsit e analizs dinamike
4.1.2
Tipet e prdorimit
Ka tre tipe versionesh se si SOTA mund t prdoret pr testim:
Testimi manual
33
S bashku me nj sistem testimi t jashtm

E integruar n nj system testimi automatik
Testimi manual
Realizohet me nj IDE sic sht eklipsi, e prdorur shtes pr SOTA-n, me t dhna

testuese t future nprmjet cmd
Me testcaset t vendosura n nj program JAVA dhe t testuara me eklipsin si JUnit test
Me SOTA-n nn prdorimin t nj Ant build files dhe nj skripti startues
Testimi external
Punon m nj system testimi t jashtm q sht i ngjashm me testimin manual

I vetmi ndryshim sht metoda e testimit
SOTA bn t njjtn gj si tek testimi manual, por pr testimin e programit n vetvete
prdoret nj sistem testimi i ndar (psh ATOSj)
Testimi automatik
4.1.3
Me nj system testimi automatik, SOTA mund t bashkohet si library (SOTA ATM) n

sistem
N kt rast asnj funksionalitet GUI nuk sht prdorur nga SOTA
Funksionet kernel t SOTA-s thirren ose mbi parmetrat e cmd, ose si nj instance e
ATM s SOTA-s , klasa e s cils thirret nga libraria.
Puna me SOTA
T punosh me SOTA-n konsiton n tre hapa:
Prgatitja
Ka te bj me leximin e kodit dhe prcaktimit t llojit t instrumentimit pr t. N
testimin manual kjo realizohet nprmjet SOTAGUI
Testimi
N fazn e testimit, kompilimit ndodh testimi i programit. Kompilimi nuk sht
prgjegjsi e SOTA-s. Shpesh kompilimi iniciohet nga SOTA nprmjet integrimit t
ANT build script. Nse nj batch file sht prezent programi gjithashtu mund t filloj
nga SOTA.
Vlersimi i fazave
N fazn e vlersimit kodi burim ngarkohet, logfile-at jan lexuar dhe matje t ndryshme
jan llogaritur. Rezultatet jan m pas t disponueshme pr vlersim, ose m mir t
eksportuara n nj raport HTML.
Instalimi i SOTA-s.
shte njaplikacion standalone Eclipse RPC. Pranon instalime Java (nga 1.6). Instalohet
nga paketimi nj file zip-i.
34
Figura 12 Zip file-i i SOTA
M posht paraqitet nje pamje vizuale e SOTA-s pas instalimit . N pjesn e siprm majtas lart
ka nj pamje t projektit, kurse majtas posht testcase-et e programit q jan realizuar.
Figura 13 Ndrfaqja e SOTA-s
35

4.2 CCCC
Mjet C dhe C ++ Code Counter ( CCC ) siguron funksionalitet pr t llogaritur disa
metrika Software pr C , C ++ dhe fila-a t Java-s .
Ai mbshtet metrikat si rreshta t kodit,kompleksiteti McCabe dhe metrika t orientuara nga
objekt t propozuara nga Chidamper dhe Kemerer. Pr m tepr ajo krijon nj raport n formn
e nj faqe interneti HTML cila sht e vendosur gjithmon n nndirektorine .cccc, me
directorin e ekzekutimit t cccc .
Matjet e kodit burim t ktij lloji jan prgjithsisht t referuara si " metrika software " , ose m
sakt ' produkte metrikash software ' (termi' software metrics` mbulon edhe matjet e procesit t
programeve, t cilat jan quajtur proces software metrics) . Ekziston nj konsensus i arsyeshm
n mesin e liderve t opinionit modern n fushn e inxhinieris software, q matja e disa lloj
sht ndoshta nj gj e mir, edhe pse ka m pak konsensus n at q sht me vler n matje
dhe far matjet thot .
CCCC sht zhvilluar si program opensource, dhe sht lshuar n form t kodit burim.
Prdoruesit jan t inkurajuar q t kompilojn programin n vetvete, dhe pr t modifikuar
burimin pr t pasqyruar preferencat dhe interesat e tyre .
Mnyra m e thjesht e prdorimit cccc sht vetm pr t ekzekutuar at me emrat e nj
przgjedhje t file-ave n cmd si kjo :
cccc my_types.h big.h small.h *.cc
Nga ana tjetr,pr nj hierarki komplekse, prdoruesi mund t hyj n nj komand si kjo:
dir /b/s | cccc - (n platformat e DOS/Windows)
Pika fillestare e raportit sht skedari cccc.html.Cccc sht nj mjet i lir q mund t prdoren
pr t matur kompleksitetin cyclomatic t nj kodin baz.
1) Pasi t kemi shkarkuar at nga sourceforge dhe e instalojm at shfaqet menuja e
zhvillimit.
Figura 14 Menuaja pas instalimit t CCCC
36

2) Ne klikojm tek command line dhe shfaqet dritarja e mposhtme.
Figura 15 Dritarja e instalimit t CCCC npermjet cmd
3) N dritaren cccc, shkruajm cccc C: \ Source1.cpp
Figura 16 Treguesi q dritarja sht e gatshme pr prdorim
4.2.1
Metrikat e shfaqura
Tabela 3 Metrikat e CCCC m t pdorura
Tag-u
LOC
Emri i metriks
Rrjeshta kodi
Prshkrimi
Kjo metrik numron numrin e rrjeshtave jo bosh
,sorce kodet pa koment n nj funksion(LOCf).
LOC ishte nj nga metrikat m t hershme q do t
vijn n prdorim ( kryesisht pr shkak se ajo sht e
drejtprdrejt pr tu matur ) .
Ajo ka nj lidhje t qart me madhsin apo
kompleksitetit t nj pjes t kodit dhe
produktivitetit mund t kalibrohet pr prdorim n
parashikimin e prpjekjeve t mirmbajtjes,
37
MVG
COM
4.2.2
McCabe's Cyclomatic
Complexity
Rreshta
Komenti(coment
lines)
megjithse shqetsim sht shprehur se prdorimi i

ksaj metrike si nj mas e programues mund t
priren pr t inkurajuar praktikat e programimit
fjalshum dhe dekurajojn thjeshtsimin e
dshirueshme.
Nj mas e nj trupi t kodit n baz t analizave t
kompleksitetit cyclomatic t grafikut aciklik drejtuar
cili prfaqson rrjedhn e kontrollit brenda secilit
funksion . Propozuar s pari si nj mas e numrit
minimal t rasteve t testit t siguruar t gjitha pjest
e secilit funksion ushtrohen .Ajo tani sht e pranuar
gjersisht si nj mas pr zbulimin e kodit e cila ka t
ngjar t jen e prirur pr gabime / ose e vshtir pr
t mbajtur .
Nj mas e paprpunuar e krahasueshme me LOC t
shtrirjes s komentimit brenda nj rajoni t kodit . Jo
shum kuptimplot n izolim, por nganjher
prdoren n raport me LOC ose MVG pr t siguruar
se komentet jan t shprndar n mnyr
proporcionale n sasi t mdha ose kompleksitetit t
nj rajoni t kodit .
Metodat e numrimit
Cccc zbaton algoritme t thjeshta pr t llogaritur seciln nga masat e paraqitura.

Algoritme jan t destinuara pr t paraqitur nj prafrim t dobishme t sasive themelore, n
vend t numrimit t sakt , n marrveshje t prgjithshme me akuza t bazuara tek manuali n
t njjtat prkufizime duhet t bien dakord me cccc pr brenda 2-3 %. Nse mosprputhje t
mdha jan zbuluar, ose n qoft se ky nivel i marrveshjes nuk sht konsideruar i
prshtatshm, prdoruesit jan t mirpritur pr t modifikuar kodin burim pr t zbatuar
marrveshjen m t ngusht,apo pr t ndryshuar sjelljen e numrimit pr t pasqyruar nj baz
t dshiruar t llogaritjes. Prkufizimet themelore t do akuz jan si m posht :
Numri i Moduleve ( NOM )
Cccc prcakton module n drejtim t nj grupim t funksioneve antare : klasa dhe
hapsira C ++ , klasa Java dhe ndrfaqe, paketa Ada t gjitha t prcaktuara si module.
Prve ksaj, funksionet t cilat nuk jan antar t nj prej ktyre strukturave jan
trajtuar si pjestar t nj moduli anonim q konsiderohet nse ajo ka funksione antare
Rreshtat e Kodit ( LOC )
Kjo numrim ndjek standarti i numrimit jo- bosh ,rreshtat e jo komente t kodit burim .
Ndarjet midis rreshtave trajtohen si bosh . Deklarimet e klasave dhe funksioneve jan t
numruara, por deklarata e t dhnave globale injorohen. Nuk mund t ket disa
numrimi i dyfisht i rreshtave n prkufizimet klass sic algoritmi trajton totalin mbi
nj modul, si shuma e rreshtave q i prkasin modulit vet dhe linjat q i prkasin
funksioneve t tij antare ( deklaratat dhe prkufizimet e funksioneve antare n trupin e
prkufizimit t klass do t kontribuoj n t dy numrimet ) .
38
Komentet e rreshtave( COM )

do rresht i cili prmban do pjes t nj komenti pr gjuhn n fjal sht trajtuar si nj
komenti nga cccc , dhe sht i alokuar tek moduli. Kjo siguron q komentet kryesore
jan trajtuar si pjes e funksionit apo klass, prkufizimin q i ndjek ata .Esht nj
prjashtim nga ky rregull :Rational Rose mjet dizajn sht i njohur pr t futur direktivat
n file-at burim t maskuara si komentet e C ++ me prefiksin ' // ## ' . Kto nuk
numrohen si komentet, megjithat t gjitha strukturat e tjera komente jan, edhe nse
nuk ka prmbajtje brenda komenteve prndarse , apo prmbajtja sht komentuar nga
kodi burim .
Kompleksiteti Ciklomatik McCabe ( MVG )
Prkufizimi formal i kompleksitetit ciklomatik sht se ai sht numri i shtigjeve
linearisht t pavarur prmes nj rrjedh t grafikut t kontrollit q rrjedhin nga nj nnprogram . Nj prafrim pragmatik pr kt mund t gjendet duke numruar fjal kye t
gjuhs dhe operatort q do t vendoste rezultatet dhe vendimet shtes. Kjo mund t
tregohet t jet mjaft i sakt n shumicn e rasteve . N rastin e C ++ , numrimi sht
rritet pr secilin nga argumentet e mposhtme: 'if','while','for','switch','break','&&','||'
39

5 Analiza Dinamike
5.1 Objektivi dhe motivimi.
Testimi Software sht nj aktivitet thelbsor pr t kontrolluar dhe provuar
korrektsin e sjelljes e softuerit sipas specifikimit t tij. Megjithat, testimi i do gjndje t
mundshme t sistemit software mund t jet shum e shtrenjt, ose edhe e pamundur .
Kshtu testimi Software sht vlersuar pr t marr rreth 50 % t kohs dhe kostove t procesit
t zhvillimit t software-it.
Inxhiniert e testimit jan prballur me problemin pr t gjetur nj setin e t gjitha rasteve t
mundshme t testit e cila ka nj probabilitet t lart pr zbuluar gabimet [20]. Nj mnyr pr t
adresuar kt problem sht t prdoret testimi i strukturuar (p.sh duke prdorur Sota).
5.2 Software-i nn testim. Rast studimor.

Software-i q kam zgjedhur pr t testuar sht i vogl rreth 60 LOC(rrjeshta kodi), i cili
sht prgjegjs pr marrjen e dats nga nj string i dhn dhe krijimin e objektit t duhur t
dats. Pr 6 nga kriteret e para do t mundohem t gjej setin m t vogl t testcase-ve q e rrit
mbulimin e kodit deri ne 100%.N kt mnyr pr kodin e marr n shqyrtim kam ndrtuar
klasn specifike n java qe implementon setin e duhur t testcase-ve, e cila thrret metodn
kryesore t klass main t programit n Java. Kurse pr tre parametrat e fundit duke plotsuar
kshtu nnt kriteret e specifikuara tregoj arsyen pse mbulimi pr t tre nuk arrihet 100% .
5.2.1
Implementimi i rastit studimor.
Kjo matje mbulimi arrin 100% kur t gjitha inputet e mundshme t funksioneve dhe
vlerat e kthimit jan testuar (p.sh t gjithe parametrat e funksioneve jan kaluar, dhe t gjitha
vlerat e mundshme t kthimit jan thirrur t paktn njher t vetme).
Kshtuq, pr t testuar metodn Date.toString() na nevojitet vetm nj rast testimi pr t
mbuluar 100% testin e FEEC: pra nj dat e vlefshme pr tu br print.
System.out.println(DateParser.parseDate("2014.11.15"));
Po n t njjtn mnyr ne mund t testojm metodn DateParser.parseDate(), sapo inputi i

vlefshm (pr t br return new Date()) dhe njher me input t vlefshm (pr t br return
null;). Rasti i par testues sht aktualisht i mbuluar nga testi i par i prmendur msipr, ndrsa
pr rastin tjetr testues mposht jepet forma e vlefshme:
System.out.println(DateParser.parseDate("1ab"));
Kshtu q si prfundim, ne mund t mbulojm testin FEEC me metodn e mposhtme e cila

prmban vetm dy raste testuese:
private static void functionIOCoverage_feec(){
System.out.println(DateParser.parseDate("2014.11.15
System.out.println(DateParser.parseDate("1ab"));}
40

Emri i file-it t logeve SOTA: functionIOCoverage_feec.log
Rezultati i analizs SOTA:
Figura 17 Paraqitja grafike pas ekzekurimit t testit FECC
5.2.1.1 Testi mbulimit deklarativ Testi C0
Duke par mbulimin e kodit t kryer nga testi FEEC mund t shohim se ekzistojn vetm
pak rreshta t cilt nuk jan mbuluar, kshtuq metoda e mposhtme prcakton 5 raste t tjera
testuese t cilat duke zgjeruar 2 testet e mparshme mund t mbulojn testin C0 n nivel 100%:
private static void statementCoverageTest_C0(){
System.out.println(DateParser.parseDate(".01.11"));
}
Kshtuq 3 rastet e para testuese n kt metod shrbejn pr t mbuluar rrjeshtat deklarativ n
metodn Date.toString(), t cilt nuk ishin mbuluar nga rasti i rregullt testues i mparshm q
konsistonte n dhnien si input t dats (testi FEEC msipr).
else if (year < 1000) {

result += "0" + year;
} // eshte mbuluar nga ("199.11.15") input
else if (year < 100) {
} // eshte mbuluar nga ("20.11.15") input
if (year < 10) {
}
And
if (month < 10) {
result += ".0" + month;
}
41

And
if (day < 10) {
result += ".0" + day;
} // jane mbuluar nga ("2.5.1") input
Rastet e tjera testuese sherbejne per te mbuluar rrjeshtat ne vijim:
if(month < 1 | month > 12) {
errorFree = false;
} // is covered by ("2013.00.11")
if(year < 0 | index == 1) {
errorFree = false;
} // eshte mbuluar nga (".01.11") sepse index==1 me ate input
Pra, ne kemi zgjeruar rastet testuese t FEEC me kt set testesh shtes (5 teste) dhe m n fund
kemi arritur q ta ojm testin C0 n nivelin e mbulimit 100%, gj q dshmon se t gjitha
deklaratat jan ekzekutuar t paktn njher.
Emri i skedarit te
Rezultati i analizes SOTA:
logeve
SOTA:
statementCoverageTest_C0.log
5.2.1.2 Testi mbulimit t degve Testi C1
Ashtu si kemi par nga figura e msiprme (statementCoverageTest) testi C1 sht

mbuluar 100%. Kjo ndodh ngaq struktura e programit testues sht e thjesht dhe n mnyr q
t arrihet do deklarat (testi C0) ne kemi pr t pasuar t paktn njher prmes t gjitha
degve.
5.2.1.3 Testi i mbulimit t kushtzimit t thjesht Testi C2
Duke par diagramen CFG, ne mund te nxjerrim ne pah kushtezimet atomike te cilat nuk
kane mbulim 100%:
-dita>31 ishte prher e vrtet, kshtuq duhet ta vlersojme si t pasakt : 2013.05.32
-muaji>12 ska qen asnjher e vrtet, pra duhet ta vlersojm testin e sakt: 2013.14.11
-Si prfundim , neve na duhet nj test q t vlersojm viti<0 si t sakt, gj q duket e
pamundur, duke qen se viti fillon viti=0 dhe programi nuk e njeh - si shenj.
Por pastaj e kuptojm q kur testojm vitin me nj vler t madhe, n mnyr q shumzimi i
vit = vit * 10 + Integer.parseInt(chr); do t gjeneronte mbiderdhje dhe viti mund t merrte disa
vlera negative. Kshtuq si prfundim, si zgjerim i rasteve testuese t mparshme, kemi shtuar
metodn e mposhtme me 3 raste testuese:
private static void simpleConditionCoverage_c2(){
System.out.println(DateParser.parseDate("2013.14.11")); // month>12
42

}
Emri i skedarit te logeve SOTA: simpleConditionCoverage_c2.log
Figura 18 Paraqitja grafike pas ekzekutimit t test case-ve t 5 parametrave t para
5.2.1.4 Testi i mbulimit t kushteve minimale t shumfishta Testi MMDC
Si e shohim nga figura e msiprme (simpleConditionCoverage_c2) testi MMDC sht

mbuluar tashm 100%. Kjo ndodh ngaq n testin C2 ne mbuluam kushte atomike, n mnyr q
kushtet komplekse t cilat duhet t mbulohen n MMCC t cilat jan vlersuar aktualisht t
paktn njher si t sakta ose t pasakta.
5.2.1.5 Testi i kushteve t modifikuara/Mbulimit t vendimeve Testi MCDC
Testi MCDC pretendon t jet m preiz sesa testi MMCC, sepse na duhet t testojm
nse ndryshimi i nj kushti atomik ka impakt mbi vlersimin kompleks t kushtit apo jo. Duke
par n skemn e CFG n kt faze, ne kemi mbulim t ult t MCDC n kto kushte:
- (!errorFree | day < 1 | day > 31)
- (chr.equals(".") & whereAmI.equals("month"))
Kshtuq kemi zgjeruar rastet tona testuese me metodat e mposhtme te cilat
prmbajne 3 teste te tjera:
private static void modifiedConditionDecisionCoverage_MCDC(){
System.out.println(DateParser.parseDate("2013.14_11"));
System.out.println(DateParser.parseDate("2013.05.11."));
}
Testi i par vlerson day<1 si t sakt, vlern e dyt e vlersojm chr.equals(.)
si t pasakt dhe rasti i tret vlerson whereAmI.equals(month) si t pasakt. Me kto tre
raste t tjera ne mund t prmbushim mbulimin e MCDC n nivel 100%.
Emri i skedarit te logeve SOTA: modifiedConditionDecisionCoverage_MCDC.log
43

Analiza e rezultateve t SOTA:
Figura 19 Paraqitja grafike pas ekzekutimit t testit e MCDC
5.2.1.6 Testi i mbulimit t kushteve t shumfishta Testi C3
Pr kt matje, n mnyr q t arrijm mbulim 100%, duhet t prfshijm rastet testuese

t cilat vlersojn do kombinim t mundshm t kushteve atomike n nj kushtzim kompleks.
Prderisa ekzistojn disa kombinime t paarritshme, testi C3 nuk mund t mbulohet asnjher n
nivel 100% pr arsyet e mposhtme:
1.(month<1 | month>12)
Nuk ka mundsi t jet asnjher true|true sepse nj numr nuk mund t jet
asnjher n t njjtn koh edhe m i vogl se 1 dhe m i madh se 12. Ne kemi
testuar 3 nga 4 kombinimet e mundshme (1 sht i pamundur).
2.(year<0 | index==1)
Nuk mund t vlersohet asnjher si true|true sepse n mnyr q viti t ket disa
vlera duhet q t inkrementohet index.
Ky kusht ka nj total prej 8 kombinimesh t mundshme, por 2 nga kto kombinime jan t
paarritshme. Kombinimet n vazhdim jan t pamundura q t ndodhin:
errorFree
True
False
Day<1
True
True
Day>31
True
True
Dita nuk mund t jet m e vogl se 1 dhe m e madhe se 31 n t njejtn koh, kshtuq ne
kemi mbuluar 5/8. Ekziston vetm nj kombinim q nuk sht mbuluar, i cili mund t testohet
nga metoda n vijim:
public static void multipleConditionCoverage_c3(){
System.out.println(DateParser.parseDate("2013.9.999."));
}
44

Emri i skedarit te logeve SOTA: multipleConditionCoverage_c3.log
Figura 20 Paraqitja grafike e pas ekzekutimit t testit C3
5.2.1.7 Testi i kufirit te brendshem Testi BI
N rastin e klass Date testi BI sht i thjesht, sepse kemi 4 mundsi pikash hyrje n
bllokun e par (q sht year<10, year<100, year<1000, etj). Pr secilen nga kto 4 mundsi, ne
mund ti kombinojm ato me (month<10, muaj t tjer) dhe pastaj ti kombinojm srish me
(day<10, dit t tjera). Kshtuq, n total kemi 4*2*2=16 raste t mundshme testuese, prderisa
nuk kemi asnj cikl t mbyllur. Duke prjashtuar rastet studimore t cilat jan prdorur mpar,
marrim:
Ve ksaj, ne mund t gjykojm n t njjtn mnyr si bm me funksionin
DateParser.parseDate(). sht paksa e komplikuar prderisa kemi nj cikl t mbyllur:
1. Cikli nuk ekzekutohet,
2. Cikli ekzekutohet vetm njher t vetme,
3. Cikli prsritet vetm njher t vetme
45

Trupi i ciklit t mbyllur sht nj element i strukturuar (if, else if, else if, else) dhe do bllok
sht gjithashtu nj element i strukturuar, kshtuq numri total i rasteve testuese sht me t
vrtet shum i madh. Sipas SOTA-s (dhe Matematiks gjithashtu) ne mund t gjejm se numri
m i mundshm i testit BI sht 147 pr funksionin parseDate(). Kjo n fakt nuk sht shum e
vrtet sepse disa pathe jan t paarritshme, si pasoj e strukturs logjike:
Pr shembull, trupi i nj cikli t mbyllur nuk mund t filloj asnjher tek blloku:
else if(chr.equals(.) & whereAmI.equals(month))
Kjo gj vjen ngaq karakteri i par sht ., ather variabli whereAmI ka vlern year. Pra,
testi i mbulimit BI sht me t vrtet i ngusht. Ne do mund t prdornim testime t rastsishme
pr t rritur prqindjen, por duke qen se testimet kushtojn, ne pranojm nj mbulim m t
vogl me minimumin e rasteve t mundshme testuese. SOTA ka vlersuar nj numr maksimal
t degzimeve n vlern 163.
Ne ndoqm nj rregull baz pr t derivuar rastet n vijim: Nisim me nj vler t sakt t mundur
ose t pamundur dhe prpiqemi q t parashikojm t gjitha karakteret vijuese n hyrje t cilat
programi mund ti lexoj pa u mbyllur.
Prderisa metoda prmban 120 raste testuese, ajo sht e prfshir n nj skedar zip t
emrtuar boundaryInteriorPath_BI() brenda klass testuese.
Emri i skedarit te logeve SOTA:
boundaryInteriorPath_BI.log
Figura 21.Paraqitja grafike pas anlizes se testit MBI dhe BI
5.2.1.8 Testi i pathit t brendshm t modifikuar - Testi MBI
uditrisht, mbulimi pr kt test sht shum i ult, 43,96%. Edhe pse testi BI ka nj
mbulim shum t mir me 85,59% q do t thot se shum nga pathet e mundshme jan vizituar
tashm, testi MBI sht shum i ult prap se prap. Pr m tepr, numri i rasteve testuese
aktualisht sht rritur pak, kshtuq po t shtonim raste t tjera testuese shtes rrit koston dhe
kohn pr t aplikuar kto teste. Kshtuq prfundimisht ne po pranojm vlern 43,96% si nj
mbulim t mir pr kt test.
46

5.3 Prmbledhje
5.3.1
Klasa testuese n Java
Ne kemi krijuar nj klas n Java t emrtuar DateParserTest , e cila ka nj metod pr

secilin set t rasteve testues. Metodat thirren nj nga nj n metodn kryesore (duke komentuar
rreshtat e tjer ndrkoh), kshtuq secili set testues ka nj skedar t ndar ASCILogger.
Prderisa rastet testuese jan t trashguar/zgjeruar n setet pasuese testuese, ne mund ti
bashkangjisim ekzekutimin e metodave pasuese brenda main() ose t bashkojm rezultatet e
testeve (interpretimet e logeve) n SOTA. N rastin ton menduam se sht m i arsyeshm
bashkimi i rezultateve t testeve n SOTA.
Vini re:
Metodat n klasn DateParserTest mbajn thirrjen System.out.println(); e cila nuk sht
e nevojshme (prve testit FEEC dhe BI).
Tabela 4 Tabela e rezultateve
Testi
FEEC
C0
C1
C2
Mbulimi Nr.
Testimeve
100%
2
100%
5
100%
0
100%
3
Emri metods
Emrtimi skedarit t logeve
functionIOCoverage_feec
statementCoverageTest_C0
simpleConditionCoverage_c2
functionIOCoverage_feec.log
statementCoverageTest_C0.log
simpleConditionCoverage_c2.l
og
MMCC 100%
MCDC 100%
0
3
modifiedConditionDecisionCov
erage_MCDC
modifiedConditionDecisionCo
verage_MCDC.log
C3
90.91%
multipleConditionCoverage_c3
MBI
BI
43.96%
85.89%
0
121
boundaryInteriorPath_BI
multipleConditionCoverage_c
3.log
boundaryInteriorPath_BI.log
47

6 Analiza Statike
6.1 Problemet ne kualitetin software-ik dhe matjet e tij.
6.1.1
Objektivi dhe motivimi.
Sistemet software-ike q jan prmendur sot jan br shum t komplikura. Lidhur me

kt ato jan ndar n module/klasa/njsi apo cdo form q nj gjuh programimi suporton. Pr
sejciln prej ktyre njsive, dhe pr cdo gjuh programimi ka sygjerime lidhur me kualitetin
software-ik, lidhur me kompleksitetin, gjatsin, prmasn, numrin e variablave, parametrave etj.
Matja e kualitetit software-ik sht vrtetuar q sht gj e mir pr procesin e zhvillimit[17].
6.1.2
Software-i nn testim
Pr kt rast studimor kam zgjedhur dy klasa t nj komplilatori q prkthen

njprogram n paskal n nj kod makine virtuale P-Code. Klasa Error sht prgjegjse pr
printimin e mesazhin gabues pr stream-in n pputhje me nje kod t dhn ku klasa Scanner
implementon komponentt leksik t kompilatorit. Prdor CCCC pr t krijuar nj raport t
metrikave pr nj softuer t caktuar n baz t testit dhe analizuar vlerat e metrikave, rreshtat e
kodit ( LOC ) dhe kompleksiteti ciklomatik( MVG ) pr metodat e klasave ( moduls ) Error dhe
Scanner . Veanrisht vmendje marrin metodat kritike ( hyrjet me ngjyr ). Prve ksaj t
ekzaminoj sipas kodi burim t ktyre metodave duke prdorur mjetet Sota pr t llogaritur
metrikat pr software n prov dhe krahasoj metrikat , vlerat me ato nga raporti cccc .
6.1.3
Komentet mbi vlerat e metrikave MVG dhe LOC
Klasat Error dhe Scanner jan klasa t nj kompilatori q prkthejn programet e

shkruara n nga Pas-0 n kod t makins virtuale P-Code. S pari sht prdorur mjeti CCCC
pr t llogaritur vlerat e metrikave LOC (rreshtat e kodit) dhe MVG (cyclomatic complexity) pr
metodat e ktyre klasave. sht prdorur dhe mjeti SOTA pr t njjtn arsye.
N kt seksion do t analizohen vlerat q jan marr nga CCCC pr seciln nga metrikat pr
metodat e klasave t msiprme. Pas ksaj do t analizohen rezultatet e marra nga SOTA pr t
njjtat metrika. Rezultatet e marra nga dy mjete t ndryshme do t krahasohen.
Pr t analizuar vlerat, do t marrim n konsiderat vlern maksimale t MVG, q sht 10
(bazuar tek rekomandimet e McCabe).
M pas do t analizojm metodat pr nj kompleksitet m t lart, e cila mund t oj n m
shum gabime dhe n nj munges t qartsis. Metodat komplekse krkojn m shum koh pr
tu zhvilluar dhe pr tu testuar. Nga rezultatet q u morn nga CCCC, u vu re se disa vlera t
metrikave ishin me ngjyra (t kuqe dhe t verdha). Kjo ndodh pr shkak t kompleksitetit t
tepruar q duhet t shmanget. Zgjidhje pr t thjeshtuar kompleksitetin sht t rishkruhen dhe
t ndahen metodat n disa metoda.
48

Nga ana tjetr kompleksiteti lidhet pozitivisht me prmasat e kodit. Nj program apo funksion i
madh ka gjasa t jet kompleks. Gjithsesi nj procedure me relativisht pak rreshta kodi mund t
jet edhe m komplekse se sa nj procedure e gjat.
6.2 Klasa Error.java

Kjo klas sht prgjegjse pr t printuar mesazhet jo korrekte n rradhn e gabimeve
bazuar n nj gabim kodi t dhn. N figurn 22 je pen vlerat e metrikave pr tre metoda (error,
ioError, symbolError) llogaritur nga CCCC dhe n figurn 2 jepen vlerat e llogaritura nga
SOTA.
Figura 22 Vlerat e metrikave t llogaritura nga CCCC
Figura 23 Vlerat e metrikave t llogaritura nga SOTA
6.2.1
Rezultatet e CCCC
a. Metoda: error(int,int,int)
Metoda
error(int,int,int)
LOC
34
MVG
57
MVG
Ne e dim se kompleksiteti iklomatik prdoret pr t treguar kompleksitetin e nj programi. Ai
mat direkt numrin e rrugve lineare t pavarura n nj kod burim t nj programi. Nga tabela
shohim se MVG sht 57, q tregon nj vler t lart. Por duke marr n konsiderat
49

implementimin e ksaj metode (switch me shum case) mund t themi se ka nj prpjestim
ndrmjet kompleksitetit dhe prmasave t kodit.
LOC
Nga tabela e msiprme shohim se rezultati pr LOC t llogaritura nga CCCC sht 34, e cila
nuk sht nj vler e lart. Mund t themi se metoda sht e qart dhe e thjesht pr tu kuptuar.
b. Metoda: symboError(int,int,int)
Metoda
symbolError(int,int,int)
LOC
4
MVG
0
MVG
Nga tabela mund t shohim se rezultatet e lloagritura nga CCCC tregojn se MVG sht 0 sepse
kjo sht nj metod e thjesht dhe nuk ka fjal kye ose operator q t rrisin kompleksitetin.
LOC
Rezultati i marr nga CCCC sht 4. sht nj vler e vogl dhe nuk shkakton kompleksitet,
kshtu q sht nj metod e qart dhe e thjesht pr tu kuptuar.
6.2.2
Rezultatet e SOTA
a. Metoda: error(int,int,int)
Metoda
error(int,int,int)
LOC
39
MVG
29
MVG
Bazuar tek prkufizimi i MVG dhe tek formula: v(G) = e n + 2 (e numri i degve, n - numri i
nyjeve), ne mund ta llogarisim vlern e msiprme: v(G) = 89 -62 + 2 = 29.
Vlera e llogaritur nga CCCC sht m e madhe se v(G). Kjo ndodh sepse switch-i me 28 case rrit
kompleksiteti e ksaj metode.
LOC
Rezultati i llogaritur nga SOTA sht 39, kurse rezultati i marr nga CCCC sht m i vogl. Kjo
ndodh pr arsye se CCCC nuk llogarit hapsirat midis rreshtave dhe komentet. Pavarsisht ksaj
t dyja vlerat nuk jan t larta dhe nuk tregojn kompleksitet n rreshtat e kodit.
Si prfundim mund t themi se kjo metod sht e thjesht pr tu kuptuar dhe lexuar. Gjithashtu
sht e leht pr tu zhvilluar, testuar dhe riimplementuar.
b. Metoda: symbolError(int,int,int)
50

Metoda
symbolError(int,int,int)
LOC
3
MVG
1
MVG
Bazuar n metodn e CFG, kjo metod ka 1 deg dhe 2 nyje, kshtu vlera MVG sht v(G) = 1
2 + 2 = 1.
Kjo vler sht m e vogl se 10, e cila sht vlera e rekomanduar, prandaj mund t themi se
metoda nuk ka kompleksitet. Vlera nga CCCC sht m e vogl sepse kjo metod nuk prmban
cikle apo kushte.
LOC
Rezultati i llogaritur nga SOTA sht 3 dhe ky sht nj rezultat i pritshm. Rezultati i marr nga
CCCC sht m i madh, por n t dyja rastet metoda sht e qart, e thjesht pr tu kuptuar, e
thjesht pr tu zhvilluar dhe riimplementuar.
c. Metoda: ioError()
Metoda
ioError()
LOC
3
MVG
1
MVG
Njsoj si metoda symbolError, kjo metod ka 1 deg dhe 2 nyje, me nj vler t MVG prej: v(G)
= 1 2 + 2 = 1. Kjo vler sht nj njsi m e madhe se vlera e llogaritur nga CCCC dhe sht
m e vogl se vlera e rekomanduar 10. Si prfundim mund t themi se sht nj metod pa
komleksitet.
LOC
Rezultati i SOTA sht 2 dhe ky sht rezultati q ne prisnim sepse ka vet 2 rreshta kod.
Rezultati i CCCC sht m i madh se sa rezultati i SOTA, por t dyja vlerat jan t vogla dhe
nuk tregojn kompleksitet. Metoda sht e qart dhe e thjesht pr tu kuptuar. Gjithashtu e leht
pr tu zhvilluar dhe testuar.
6.3 Scaner.java
Kjo klas implementon komponenten leksikore t kompilatorit. N figurn 24 jepen vlerat
e metrikave t llogaritura nga CCCC pr metodat (Scanner, charIsAlpha, charIsDigit, comment,
getLine, getPos, getSymbol, handleIdentifier, main, number, readNextChar). N figurn 25 jepen
vlerat e llogaritura nga SOTA.
51
Figura 24 Vlerat e metrikave t llogaritura nga CCCC
Nga figura shohim se disa nga metodat jan t ngjyrosura (t kuqe dhe t verdha), q do t thot
se se ato kan kompleksitet t teprt. Vlerat e tjera q nuk jan t ngjyrosura tregojn se MVG
dhe LOC jan larg vlers maksimale t rekomanduar dhe metodat prkatse nuk jan komplekse.
Ato jan t thjeshta pr tu kuptuar, lexuar, zhvilluar dhe testuar. Interesi yn sht analiza dhe
krahasimi i vlerave pr metodat e ngjyrosura.
52
Figura 25 Vlerat e metrikave t llogaritura nga SOTA
6.3.1
Rezultatet e CCCC
a. Metoda: getSymbol()
Metoda
getSymbol
LOC
78
MVG
45
MVG
Rezultati i llogaritur nga CCCC sht m i lart se sa kufiri i rekomanduar. Me kt mund t
themi se metoda sht komplekse dhe jo shum e sigurt.
LOC
Jan 78 rreshta, e cila sht nj vler e lart. Kjo vler tregon pr nj kompleksitet t lart t
rreshtave t kodit.
b. Metoda: handleIdentifier()
Metoda
handleIdentifier()
LOC
22
MVG
19
MVG
Vlera e MVG sht 19 dhe sht nj vler m e madhe se sa kufiri i lejuar. Kjo do t thot se
kemi t bjm me nj metod komplekse.
53

LOC
Rezultati i CCCC sht 66. Kjo vler sht m e madhe se limiti maksimal dhe nuk merr n
konsidert hapsirat midis rreshtave dhe komentet.
6.3.2
Rezultatet e SOTA
a. Metoda: getSymbol()
Metoda
getSymbol()
LOC
78
MVG
27
MVG
Kjo metod ka 99 deg dhe 74 nyje, kshtu vlera e MVG sht: v(G) = 99 74 + 2 = 27. Kjo
sht vlera e llogaritur nga SOTA dhe sht m e madhe se vlera maksimale. Prandaj metoda
sht komplekse dhe jo e sigurt.
Shohim se ka shum diferenc midis vlerave t llogaritura nga SOTA dhe CCCC. Bazuar tek
implementimi shohim se arsyeja e ktij kompleksiteti t lart dhe ndryshimit midis dy vlerave
sht switch-i me shum case dhe disa if-else brenda switch-it. Pr m tepr switch-i sht i
vendosur brenda nj cikli.
LOC
Vlera e llogaritur nga SOTA sht 78 dhe sht e njjt me vlern e llogaritur nga
CCCC. Kjo sht nj vler e lart q tregon edhe nj kompleksitet t lart t kodit. Kjo do t
thot se metoda ka probleme me qartsin, sht e vshtir pr tu kuptuar dhe me gabime.
Gjithashtu nuk sht e leht pr tu zhvilluar si metod.
b. Metoda: handleIdentifier()
Metoda
handleIdentifier()
LOC
21
MVG
20
MVG
Kjo metod ka 97 deg dhe 79 nyje. Vlera e MVG sht: v(G) = 97 79 + 2 = 20. Ky rezultat
sht m i lart se vlera maksimale e prcaktuar q do t thot se metoda sht komplekse.
Shohim se vlera e llogarir nga SOTA sht nj njsi m e madhe se sa ajo e llogaritur nga
CCCC. Kjo ndodh sepse jan 19 kushte t llogaritura nga CCCC. Duke marr parasysh
implementimin e ksaj metode, vme re se jan 20 rrug t mundshme sipas if-else, e cila e
54

dyfishon kompleksitetin. Pavarsisht se nga vlera e MVG rezulton se metoda sht komplekse.
N fakt nga implementimi i saj kuptohet se nuk sht shum.
LOC
Vlera e LOC sht nj njsi m e vogl se vlera e llogaritur nga CCCC. N fakt kjo sht vlera
q ne presim sepse jan 21 rreshta kodi. T dyja vlerat nuk jan shum t larta dhe nuk tregojn
kompleksitet n kod. Si prfundim mudn t themi se metoda sht e qart dhe lehtsisht e
kuptueshme.
c. Metoda: number()
Metoda
number()
LOC
70
MVG
12
MVG
Kjo metod ka 47 deg dhe 37 nyje. Vlera e MVG sht: v(G) = 47 37 + 2 = 12. Kjo vler nuk
sht shum larg nga vlera kufi e prcaktuar. Prandaj mund t themi se kjo metod nuk sht
shum komplekse. Krahasuar me CCCC sht nj vler 2 njsi m e vogl.
Pr m tepr, bazuar tek implementimi kjo metod ka shum cikle dhe kushte if-else. Kjo na
shtyn q t presim nj kompleksitet m t madh se sa ai i rekomanduar.
LOC
Rezultati i SOTA sht 4 her m i madh se sa ai i marr nga CCCC sepse CCCC nuk merr n
konsiderat hapsirat midis rreshtave dhe komentet. T dyja vlerat jan t larta dhe tregojn pr
kompleksitet n kod. Gjithashtu bazuar tek implementimi vm re se kjo metod ka shum
rreshta kod dhe asnj koment. Kjo do t thot se kodi nuk sht i qart, sht i vshtir pr tu
kuptuar, zhvilluar dhe riimplementuar.
6.4 Avantazhet dhe disavantazhet e kompleksitetit iklomatik

M posht do t jepet nj list e avantazheve dhe disavantazheve t MVG. Bazuar n
punn e br do t komentojm disa prej tyre.
Avantazhet:
1. sht i leht pr tu llogaritur nga programi dhe CFG
Llogaritja e MVG u b me dy mjetet CCCC dhe SOTA. N t dyja rastet ishte e thjesht
llogaritja. Pr CCCC duke numruar fjalt kye si if, while, for, switch, break, &&,
55

||ose pr SOTA nprmjet formuls v(G) + e n + 2 duke numruar degt dhe nyjet nga
metoda CFG.
2. Ajo mbshtet nj proces zhvillimi nga lart-posht pr t kontrolluar kompleksitetin n
fazn e projektimit.
3. Prcakton setin maksimal t rrugve t pavarura.
4. Prdoret pr t kontrolluar kompleksitetin e moduleve t programit duke prcaktuar
vlern kufi 10.
sht prdorur vlera e rekomanduar pr t prcaktuar nse programi ishte kompleks ose jo. Nse
MVG ishte m e madhe se 10, ather programi ishte kompleks, n t kundrt nuk ishte.
5. Prdoret pr t vlersuar dezajnin e programit pr t gjetur strukturn m t thjesht t
mundshme t programit.
Nj vler e lart e MVG do t thot se programi ka nj struktur t keqe, prandaj na duhet ta
rishkruajm programin duke e ndar n disa procedura n mnyr q t kemi nj program m t
thjesht dhe t mir strukturuar.
6. Shrben pr t ndar strukturn e programit n mundsi t larta ose t ulta pr gabime
sipas vlers.
Nj vler e lart e MVG do t thot se edhe mundsia e gabimeve sht e lart, q prkthehet
ndryshe si paqartsi dhe vshtirsi pr leximin dhe riimplementimin e programit. E kundrta
ndodh pr vlera t vogla t MVG.
7. Shrben pr t ndar strukturn e programit n gjetje dhe heqje t gabimeve shpejt ose
ngadal n varsi t vlers.
8. Mund t shrbej si guid pr vendosjen e burimeve t testimit.
Disavantazhet:
1. Mat vetm kompleksitetin psikologjik. Nuk mat kompleksitetin llogarits.
MVG mat direkt numrin e rrugve lineare t pavarura n nj kod programi dhe nuk mat
kompleksitetin llogarits q sht i rndsishm sepse ndikon tek overhead-i.
2. Tregon t gjitha predikatat, alternimet dhe prsritje sikur ndikojn njsoj tek
kompleksiteti.
Tek MVG do prsritje ose alternim e rrit kompleksitetin me 1. Kjo nuk sht korrekte sepse
disa prsritje ose alternime jan m komplekse se sa t tjerat dhe ndikimi n kompleksitet nuk
duhet t jet i njjt.
3. sht e pandjeshme n nivelin e :
56

a. Ngastra me shumllojshmri ndrtimesh
Pr llogaritjen e MVG nuk merren n konsiderat niveli i ndrthurjeve. N vend t ksaj bazohet
tek numri i degve. Kjo situat u pa tek metoda getSymbol(), e cila ka shum ndrthurje, po kto
nuk ndikuan kompleksitetin.
b. Frekuenca dhe tipi i hyrjeve dhe daljeve
c. Prmasa e programeve sekuenciale
d. Numri i variablave n program
Klasa Scanner.java ka m shum varibla se sa klasa Error.java, por kjo nuk e ndikoi
kompleksitetin e klass.
e. Numri i veprimeve me t dhnat n program
f. Varsia e rrjedhjes s kontrollit n veprimet me t dhnat
g. Situatat kur nj kusht sht i maskuar apo i bllokuar nga nj tjetr
Kjo situat u pa tek metoda number() e klass Scanner,java. Fakti se kjo nuk ndikon
kompleksitetin nuk sht shum e sakt sepse kjo situat mund t oj n rrug t pamundshme
brenda moduli.
h. Stili i programit dhe prdorimi i GOTO
MVG sht indiferente ndaj GOTO, por rrugt e modulit kan varsi. Prandaj GOTO duhet t
merret n konsiderat sepse kjo situat mund t oj n rrug t pamundshme brenda modulit.
4. Ai nuk llogarit as llojet dhe nivelet e modulit t prsritur, as nivelet e modulit thirs.
5. Ajo nuk pasqyron me saktsi prmirsim e rezultatit nga rishikimi i programit.
6.4.1
Vlerat e kqija pr kompleksitetin iklomatik
MVG sht nj vler q prdoret pr t shprehur kompleksitetin e kodit burim. Nj vler

e ult sht nj faktor pr t prmirsuar lexueshmrin, mirmbajtjen dhe testimin pr kodin.
Nse moduli ka nj vler t lart do t thot se ky program ka vshtirsi pr tu kuptuar,
ndryshuar, zgjeruar dhe zhvendosur.
Mirmbajtja sht nj faktor q ndikon n cilsin e software-it. Nj produkt duhet t jet i mir
dokumentuar n mnyr q t jet e leht pr tu mirmbajtur. N kt mnyr MVG ka nj
ndikim t madh n mirmbajtjen e moduleve t programit.
M lart jan analizuar dhe krahasuar vlerat q jan marr nga CCCC dhe SOTA pr MVG dhe
LOC. N kt seksion do t analizojm vlerat kritike (>10) q tregojn kompleksitet t lart t
metodave dhe q mund t ndikoj tek mirmbajtja. Metodat me vlera t larta t MVG jan:
Klasa: Error.java
57
6.4.2
1. N metodn error(int,int,int), vlerat e MVG t llogaritura nga CCCC dhe SOTA

jan m t mdha se kufiri i lejuar. Kjo tregon se kjo metod sht komplekse dhe
ka stil t keq programimi. Pr kt arsye na duhet ta rishkruajm programin duke
e ndar n metoda m t thjeshta q mund t jen m t kuptueshme dhe lehtsisht
t zgjerueshme.
Klasa: Scanner.java
1. N metodn getSymbol(), vlerat e MVG t llogaritura nga CCCC dhe SOTA jan
shum m t larta se kufiri i prcaktuar. Kjo do t thot se metoda ka nj stil t
keq programimi. Kjo ndodh pr shkak t nj switch me shum case t prfshir
brenda nj cikli. Gjithashtu ka shum cikle while dhe kushte if-else t ndrfutura.
Kjo metod duhet t riimplementohet n mnyr t till q t shmangen
instruksionet e ndrfutura dhe ta bjm metodn m t leht pr tu kuptuar,
lexuar dhe mirmbajtur.
2. N metodn handleIdentifier(), vlerat e llogaritura nga CCCC dhe SOTA
tregojn se metoda ka nj vler dyfish m t lart t MVG se sa kufiri i
prcaktuar. Kjo do t thot se metoda sht komplekse, por ne presim q kto
vlera t jen m t mdha se 10 pr shkak t kushteve if-else q krijojn 20 rrug
lineare t mundshme. Kjo metod nuk ka stil t keq programimi dhe sht e
thjesht pr tu kuptuar dhe mirmbajtur.
3. N metodn number(), vlerat e llogaritur nga CCCC e SOTA jan afrsisht sa
vlera kufi, kshtu metoda nuk ka stil t keq programimi dhe nuk mund t
sugjerojm ndonj prmirsim.
Matje shtes
Nga llogaritjet e bra u vu re se ka disa vlera t tjera interesante t matura nga CCCC.
Jan dy metoda error(int,int,int) nga klasa Error.java dhe number() nga klasa Scanner.java q
kan rezultate t ngjyrosura pr dy metrikat L_C dhe M_C.
L_C = rreshta kodi pr rreshta komenti. Tregon densitetin e komenteve n respekt t prmass s
tekstit n program.
M_C = MVG pr rreshta komenti. Tregon densitetin e komenteve n respekt t kompleksitetit
logjik n program.
Metodat
error(int,int,int)
number()
L_C
11,333
7,333
M_C
19,000
1,556
Metoda: error(int,int,int) e klass Error,java
L_C = 34 / 3 = 11,333
58

Kjo do t thot se 8,8% e metods sht koment. Kjo sht nj vler e ult sipas limitit minimal
t rekomanduar ku 30% - 75% e kodit duhet t jet koment. Kjo sht arsyeja pse jan t
ngjyrosura me t verdh.
M_C = 57 / 3 = 19
Sipas vlerave t larta t MVG, mund t themi se M_C ka nj vler t lart gjithashtu. Kjo sht
arsyeja pse ka nj ngjyr t kuqe.
Metoda: number() e klass Scanner.java
N kt metod vetm L_C ka nj vler kritike:

L_C = 66 / 9 = 7,333
Kjo do t thot se 13,6% e metods sht koment. Pr t njjtn arsye si n metodn
error(int,int,int) themi se metoda sht varfrisht e shpjeguar.
59

7 Optimizimi dhe sfidat n t ardhmen
7.1 Optimizimi i gabimeve n kod
N shkencat kompjuterike optimizimi i programeve sht proesi i modifikimit t nj
sistemi kompjuterik pr t br disa aspekt t saj t punojn n mnyr m efikase ose t pr t
prdorur m pak burime. N prgjithsi, nj program kompjuterik mund t jet i optimizuar n
mnyr q ai t ekzekutoj m shpejt, ose sht i aft t veprojn m pak kujtess ose burime t
tjera, ose t humb m pak energji.
Edhe pse fjala "optimizim " ndan t njjtin rrnj si "optimal", ajo sht e rrall pr procesin e
optimizimit pr t prodhuar nj sistem t vrtet optimale. Sistemi i optimizuar n mnyr tipike
do vetm t jet optimal n nj aplikim ose pr nj audienc. Nj system i till mund t
zvogloj sasin e kohs q nj program merr pr t kryer disa detyra, duke e br t
konsumojn m shum memorie . N nj aplikim ku hapsira e memories sht primare ,
dikush mund t zgjidhni qllimisht nj algoritm m t ngadalshme n mnyr q t prdorin m
pak memorie . Shpesh nuk ka " nj madhsi q iu prshtatet t gjith-ve " ,por dizajn-i q punon
mir n t gjitha rastet , kshtu q inxhiniert t bjn kompromise t zgjedhin atributet me
interesit m t madh .
Prve ksaj ,prpjekje t nevojshme pr t br nj pjes e software plotsisht optimale t
paaft pr ndonj prmirsim t mtejshm - sht pothuajse gjithmon e m shum e arsyeshme
pr t mirat q do t grumbullohen ; n mnyr q procesi i optimization mund t ndalet para se
nj zgjidhje krejtsisht optimale t jet arritur. Pr fat t mir , sht shpesh rasti q
prmirsimet m t mdha vijn n fillim t procesit.
7.2 Nivelet e optimizimit

Optimization mund t ndodh n nj numr nivelesh . N mnyr tipike nivelet m t
larta t ken ndikim m t madh , dhe jan t vshtir pr t ndryshuar m von n nj projekt q
krkon ndryshime t rndsishme ose nj rishkrim t plot n qoft se ato duhet t ndryshohen.
Kshtu optimization n mnyr tipike mund t vazhdoj nprmjet rafininmit nganiveli m i
lart n at m t ult , me fitimet fillestare pr t qen m t mdha dhe t arrihet me m pak
pun , dhe fitimet pasuese duke qen m t vogla dhe q krkojn m shum pun.
Megjithat, n disa raste performanca e prgjithshme varet nga performanca e shum pjesve t
nivelit t ult t nj programi , dhe ndryshime t vogla n nj faz t vonshme mund t ket
ndikim shum t madh .
Disa prej niveleve t optimizimit jan:
Algoritmet dhe strukturat e t dhnave
N nj dizajn t prgjithshm duhet pasur parasysh q t kemi nj zgjedhje t mir
algoritmeve efikase dhe strukturave t t dhnave, si dhe zbatim efikas t tyre.Pas
projektimit, zgjedhja e algoritmeve dhe strukturave t t dhnave ndikon n efikasitet m
shum se do aspekt tjetr i programit. N prgjithsi strukturat e t dhnave jan m t
vshtira pr t ndryshuar se algoritmet. Supozimet pr strukturn e t dhnave dhe pr
performancn jan prdorur n program,edhe pse kjo mund t minimizohet nga prdorimi
i llojeve abstrakte t t dhnave n prkufizimet e funksionit, dhe duke e mbajtur
prkufizimet konkrete pr strukturn e t dhnave t kufizuara n disa vende.
60

Pr algoritmeve, kjo kryesisht konsiston pr t siguruar q algoritmet jan me
kompleksitet konstant O(1), logaritmik O(log n), O linear (n), ose n disa raste logaritem
-linear (n log n) n t dhna (si n hapsir dhe koh). Algoritmet me kompleksitet O(N2)
katror nuk arrijn t shkallzohen dhe madje edhe algoritme lineare t shkaktojn
probleme nse n mnyr t prsritur rithirren dhe jan zvendsuar n mnyr tipike
me konstante ose logaritmike nse sht e mundur.
Nj teknik e prgjithshme pr t prmirsuar performancn sht shmangia e puns. Nj

shembull i mir sht prdorimi i nj rrug t shpejt pr raste t zakonshme,
prmirsimin e performancs duke shmangur punn e panevojshme. Nj tjetr teknik e
rndsishme sht caching, veanrisht memorizimi, e cila shmang llogaritje t teprta.
Pr shkak t rndsis s caching, shpesh ka shum nivele t caching n nj sistem, i cili
mund t shkaktoj probleme nga prdorimi kujtess, dhe shtje t korrektsis nga arka
bajate.
Niveli i kodit burim
Prtej algoritme t prgjithshme dhe zbatimin e tyre n nj makin abstrakte , zgjedhja
konkrete e nivelit t kodit burim mund t bj nj ndryshim t rndsishm .Pr
shembull , mbi hartuesit e hershme t C , while ( 1 ) ishte m e ngadalshme se sa for ( ;; )
pr nj cikl t pakushtzuar , sepse while ( 1 ) sht vlersuar 1 dhe pastaj kishte nj
krcim me kusht q testuar nse kjo ishte e vrtet , ndrsa pr ( ;; ) kishte nj krcim t
pakushtzuar . Disa optimizations (si ky ), n ditt e sotme mund t kryhet nga
optimizimi i kompilatorit . Kjo varet nga gjuha burim, n gjuhn e makins objektiv ,
dhe prpiluesit , dhe mund t jet edhe i vshtir pr t'u kuptuar ose t parashikuar dhe
ndryshimet me kalimin e kohs. Ky sht nj vend ky ku kuptimi i kompilatorit dhe
kodit t makins mund t prmirsoj performancn . Kodi ciklik i pandryshuar dhe
vlerat e kthyera jan shembuj t optimizimit q zvoglojn nevojn pr variabla ndihmse
dhe mund t rezultoj n performance m t mire duke shmangur optimizimet vajtje
ardhje.
Niveli i ndrtimit
Midis burimit dhe nivelit t kompilimit direktivat dhe flamujt mund t prdoren pr t
mbajtur performancn n kodin burim dhe kompilatorin respektivisht.
Gjat ekzekutimit
Kompilatort e sotm (Just-in-Time) mund t prodhoj kode n makina t bazuara n t
dhnat e drejtuara me koh, n koston e kompilimit t siprm. Kjo teknik e prdoru n
motort e shprehjeve t rregullta sht prhapur me Java HotSpot dhe V8 pr
JavaScript. N disa raste prshtatja e optimizimit mund t jet aft pr t kryer n koh
optimizime duke tejkaluar aftsin e hartuesve statike me rregullimi dinamik t
parametrave sipas kontributit aktual apo faktorve t tjer.
Kodi Vet-modifikimin mund t ndryshoj veten n ekzekutim kushtet kohore n
mnyr q t optimizoj kodin; kjo ishte m shum e zakonshm n asembler.
Disa dizajne CPU mund t kryej disa optimizime gjat ekzekutimit. Disa shembuj
prfshijn ekzekutimit Out-of-order(Jasht rendit)
, ekzekutimi spekulative,
Kompilatort mund t ndihmojn programin pr t marr parasysh kto cilsi t CPU-s
CPU-s ,pr shembull perms instruksioneve t skedulimit.
61

7.3 Platforma e varur dhe optimizimi i pavarur
Optimizimi i kodit mund t kategorizohet gjrsisht si i varuar nga platform me
teknika t pavarura. Ndrsa kta t fundit jan efektive n shumicn apo t gjitha platformat ,
teknikat platformave t varura prdorin vetit e veanta t nj platform , ose mbshteten n
parametrat n varsi t nj platforme t vetme apo edhe n procesor t vetmShkrimi ose
prodhimi i versioneve t ndryshme pr t njjtin kod pr procesor t ndryshm mund t jete e
nevojshme.Pr shembull n rastin e optimizimit t kompilimit teknika t pavarura jan teknika
gjenerike si psh loop unrolling ,reduktim n thirrjet e funksionit ,reduktimi i kushteve , q kan
inpakt n CPU n mnyre t ngjashme.Prgjithsisht kto ndihmojn pr t reduktuar rrugn
totale pr t prfunduar programin dhe pr t prdorimin e prgjithshm t kujtess gjat
procesit.N ann tjetr teknikat e varura nga platform prfshijn skedulimin e
instruksioneve,nivelin e paralelizmit t tyre,t t dhnave optimizimin e nivelit t caches dhe
instruksionet optimale t skedulimit mund t jen t ndryshme pr procesor t ndryshm t s
njjts arkitektur.
7.4 Pikat bllokuese

Optimizimi pfshin gjetjen e pikave pikave bllokuese t nj sistemi, nj factor q limiton
performancn.N termat e kodit kjo sht nj zone e nxeht,nj pjes kritike q sht
konsumuese dhe q ka nevoj pr burime.Algoritme komplekse dhe struktura t dhnash
performojn mire me shum gjra ndrsa algoritme t thjeshta pr sasi shuem t vogl t
dhnash-setup-in kohn e inicializimit, dhe faktor konstant pr shum algoritma komplekspsh
algoritmat hibrid apo adaptive , t cilt mund t jen m t shpejt se cdo algoritm i vetm.
7.5 Kostoja e optimizimi

Sot nuk sht e pazakont pr programuesit software pr t rekomanduar q asnj
funksion apo metod nuk duhet t jet m e gjat se disa rreshta . Disa dekada m par
,rekomandimi ishte e kundrta: mos vendos dika n nj subroutin t veant nse ajo sht
thirrur vetm nj her. Arsyet pr kt ndryshim n shkrim software jan q projektet software
jan br m t mdha dhe m komplekse , q ka m shum fokus n kostot e zhvillimit t
softwerit , dhe se kompjutert jan br m i fuqishm.
Prioritet i lart i zhvillimit t softwerit t strukturuar dhe me prioritet t ult t efikasitetit t
programit sht reflektuar , para s gjithash , n zgjedhjen e gjuhs s programimit dhe t
ndrfaqes s framework-ut. Kjo sht shpesh nj disavantazh pr prdoruesit fundor q ka pr t
investuar ndonjher n kompjuterat m t fuqishm pr t mbajtur me paketat m t mdha
software dhe q dshton ende nga koht e papranueshme t gjata dhe prgjigje , madje edhe pr
detyra t thjeshta .
Ndonjher sht e nevojshme t bhet kompromis mbi parimet e avancuara t zhvillimit
software- it n mnyr q ti bj paketat software m t shpejt dhe m t vogla . Ky manual
diskuton se si t bjn nj bilanc t ndjeshme n mes t ktyre konsideratave . Ajo sht
diskutuar se si pr t identifikuar dhe izoluar pjesn m kritike t nj programi dhe t
prqndrohen prpjekjet optimizimin n at pjes t veant. Ajo sht diskutuar se si pr t
kaprcyer rreziqet e nj stili programimi relativisht primitive q nuk kontrollon automatikisht
pr mdhenj shkeljet e kufijve , pointer-at e pavlefshme ,etj Dhe kjo sht diskutuar q nga
konstruktet e programimit t avancuar q jan t kushtueshme dhe ato q jan t lira, n lidhje
me kohn e ekzekutimit .
62

7.6 Sfidat e optimizimit
T zbulosh gabimet q ndodhin n kod sht nj process jo i leht pasi ka kosto.Sic
sht prcaktuar edhe n kt tez diplome ka lloje te ndryshme gabimesh t cilt jan
shpeshher t vshtir pr tu dedektuar.Sfida pr kt tez sht shmangia e tyre gjetja e
metodave t cilat mund t eleminojn kto gabime,pse jo propozimin e ndonj algoritmi pr
menaxhimin e tyre.
Sfid kuptimplot sht pfshirja e rrjeteve artificiale domethne fush se inteligjencs artificiale
per realizimi e kodeve vetdetektuese pr t realizuar
1. Shmangien e gabimeve
2. Ujen e kompleksitetit
3. Ndarjen e metodave nga njra tjetra
4. Shmangjen e pjesve prsritse
5. Shmangien hapsirave boshe
T gjith elementt e msiprm rritin kohn e kompilimit gjithsesi kjo mbetet nj sfid pr t
ardhmen vazhdimin e ketij projekti sidomos ndrhyrja e inteligjencs artificiale maja e
programimit n ditt e sotme.
63

8 Prfundimet
Ky punim konsistoi n dy drejtime kryesore.E para me ane t nj analize statike kodet n java
jane vlersuar duke prdorur metrikat e paracaktuara dhe vlerat e metrikave t ndryshme jan
llogaritur.Nga vlerat e llogaritura t metrikave dmth rrjeshtave t kodit, numrin e gabimeve dhe
kompleksiteti ciklomatik sht e qart q kto metrika prdoren pr t parashikuar nivelin e
cilsis t software-it t zhvilluar duke nxjerr kto prfundime.
1. Identifikimi dhe prfshirja e gjith metrikave n studim.Nga ky studim u realizua nj
analize e plot e gjith metrikave t Sots dhe Cccc.
2. Krijimi i nnseteve minimale pr rritjen e performances, n prgjithsi rritja e numrit t
seteve t testscase-ve rrit kohen e ekzekutimit dhe ul performancn e vet sistemit.
3. Nnseti m i mir i testcase-ve varion nga programi n program,dmth nuk sht e thn
se nje program me shum LOC t ket nj mbulim m te madh se nj me m pak rreshta
pasi kjo varet nga kushtet atomike t ktij programi.
4. Gabimet n kod nuk duhet t trajtohen gjithmon njsoj ,dmth jo cdo tip gabimi sht i t
njejts fuqi ka gabime q sduhen neglizhuar pasi mund t sjellin dshtime katastrofike.
5. Kompleksiteti cikolomatik prcakton pjese t kodit ku kompleksiteti sht m i
madh,kshtu m shum prqndrim duhet dhn tek kto pjest, t cilat jan m t
prirura pr gabime. Zgjidhje pr t thjeshtuar kompleksitetin sht t rishkruhen dhe t
ndahen metodat n disa metoda.
6. N analizn dinamike t po kodeve t ndrtuara n java u arrit t gjendej numri minimal i
testcase-ve t cilat realizonin mbulimin e kodit edhe pse jo plotsisht mbulimi sht i
mundshm ,kjo n fakt nuk sht shum e vrtet sepse disa pathe jan t paarritshme, si
pasoj e strukturs logjike t programit.
7. Lidhur me aspektin optimizues t gabimeve n kod sht nj problem i cili lihet si pun
n vijim qoft n propozimin e nj algoritmi apo qoft n realizimin e kodeve inteligjente
nprmjet prdorimit t inteligjencs artificiale,vetdetektuese dhe vet manipuluese
nprmjet heqjes se hapsirave, heqjen e pjesve prsritse.
64

Lista e figurave
Figura 1 Fazat e zhvillimit t nj software .................................................................................................... 7
Figura 2 Modeli Waterfall ............................................................................................................................. 8
Figura 3 Nivelet e testimit ........................................................................................................................... 12
Figura 4 Cikli i jets s nj gabimi n kod .................................................................................................... 19
Figura 5 Drejtimet pr t prmirsuar sistemet e gjurmimit t gabimeve n kod ...................................... 24
Figura 6 Parashikimi i gabimeve n kod...................................................................................................... 25
Figura 7 Struktura e skuadrs ..................................................................................................................... 30
Figura 8 Grafiku i kurbs s Lorenz ............................................................................................................. 31
Figura 9 Paraqitja grafike e SOTA ............................................................................................................... 32
Figura 10 Matsit e analizs statike............................................................................................................ 33
Figura 11 Matsit e analizs dinamike........................................................................................................ 33
Figura 12 Zip file-i i SOTA ............................................................................................................................ 35
Figura 13 Ndrfaqja e SOTA-s ................................................................................................................... 35
Figura 14 Menuaja pas instalimit t CCCC .................................................................................................. 36
Figura 15 Dritarja e instalimit t CCCC npermjet cmd............................................................................... 37
Figura 16 Treguesi q dritarja sht e gatshme pr prdorim ................................................................... 37
Figura 17 Paraqitja grafike pas ekzekurimit t testit FECC ......................................................................... 41
Figura 18 Paraqitja grafike pas ekzekutimit t test case-ve t 5 parametrave t para .............................. 43
Figura 19 Paraqitja grafike pas ekzekutimit t testit e MCDC .................................................................... 44
Figura 20 Paraqitja grafike e pas ekzekutimit t testit C3 .......................................................................... 45
Figura 21.Paraqitja grafike pas anlizes se testit MBI dhe BI ..................................................................... 46
Figura 22 Vlerat e metrikave t llogaritura nga CCCC ................................................................................ 49
Figura 23 Vlerat e metrikave t llogaritura nga SOTA ................................................................................ 49
Figura 24 Vlerat e metrikave t llogaritura nga CCCC ................................................................................ 52
Figura 25 Vlerat e metrikave t llogaritura nga SOTA ................................................................................ 53
65

Lista e tabelave
Tabela 1 Krahasimi i metodave t testimit ................................................................................................. 14
Tabela 2 Matjet absolute dhe relative duke prdorur Code Churn ............................................................. 26
Tabela 3 Metrikat e CCCC m t pdorura ............................................................................................... 37
Tabela 4 Tabela e rezultateve ..................................................................................................................... 47
66

Shtojca 1
Kodi burim i prdorur pr realizimin e implementimit.
public class DateParser {
/**
* Parses the given string and tries to extract the date.
*
* @param dateString
* date string in the format 'yyyy.mm.dd'.
* @return
*/
public static Date parseDate(String dateString) {
int year = 0;
int month = 0;
int day = 0;
String whereAmI = "year";
boolean errorFree = true;
int index = 1;
while((index <= dateString.length()) & errorFree) {
String chr = dateString.substring(index - 1, index);
if (chr.matches("[0-9]")) {
if(whereAmI.equals("year")) {
year = year * 10 + Integer.parseInt(chr);
} else if(whereAmI.equals("month")) {
month = month * 10 + Integer.parseInt(chr);
} else {
day = day * 10 + Integer.parseInt(chr);
}
} else if (chr.equals(".") & whereAmI.equals("year")) {
if(year < 0 | index == 1) {
errorFree = false;
}
whereAmI = "month";
} else if (chr.equals(".") & whereAmI.equals("month")) {
if(month < 1 | month > 12) {
errorFree = false;
}
whereAmI = "day";
} else {
errorFree = false;
}
index++;
}
if(!errorFree | day < 1 | day > 31) {
return null;
} else {
return new Date(year, month, day);
}
}
} /** Simple Date class for simple output of dates. */
public class Date {
private int year;
private int month;
private int day;
67

public Date(int year, int month, int day) {
this.year = year;
this.month = month;
this.day = day;
}
@Override
public String toString() {
String result = new String();
if (year < 10) {
} else if (year < 100) {
} else if (year < 1000) {
} else {
result += year;
}
if (month < 10) {
result += ".0" + month;
} else {
result += "." + month;
}
if (day < 10) {
result += ".0" + day;
} else {
result += "." + day;
}
return result;
}
}
68

Shtojca 2
Klasa Scanner.java
import java.io.*;
/**
* Simple scanner for lexical analysis of Pas-0 (Simple Pascal)
*
* @author Andreas Kunert
*/
public class Scanner implements TokenConsts {
private char nextChar;
private char currentChar;
private Symbol currentSymbol;
private Symbol lastSymbol; //1//
private InputStreamReader input;
private int line;
private int pos;
private ViewScanner viewScan; //1//
/**
Generates a scanner using as input the InputStreamReader
*/
Scanner(InputStreamReader input) {
try {
viewScan = new ViewScanner(); //1//
line = 1;
pos = 0;
this.input = input;
nextChar = (char) input.read();
currentSymbol = null;
69

}
catch (Exception e) {
Error.ioError();
}
}
/**
Checks whether the input char c is a digit.
*/
private boolean charIsDigit (char c) {
if ((c >= '0') && (c <= '9')) {
return true;
}
else {
return false;
}
}
/**
Checks whether the input char c is a letter.
*/
private boolean charIsAlpha (char c) {
if (((c >= 'a') && (c <= 'z')) || ((c >= 'A') && (c <= 'Z'))) {
return true;
}
else {
return false;
}
}
/**
70

Reads the next character from the input.
*/
private void readNextChar() {
try {
pos++;
currentChar = nextChar;
nextChar = (char) input.read();
viewScan.update(line, pos, currentChar, nextChar, lastSymbol); //1//
}
catch (java.io.IOException e) {
Error.ioError();
}
}
/**
Searches the next symbol, identifies it, and instatiates a
corresponding symbol object to be returned
@see Symbol
@return ideentified symbol as an objcet
*/
public Symbol getSymbol() {
viewScan.update("\nSuche neues Symbol"); //1//
lastSymbol = currentSymbol; //1//
currentSymbol = null;
while (currentSymbol == null) {
readNextChar();
if (charIsAlpha(currentChar)) {
String identifier = (new Character(currentChar)).toString();
viewScan.update("\nStringbau: " + identifier); //1//
71

while (charIsAlpha(nextChar) || charIsDigit(nextChar)) {
viewScan.update(String.valueOf(nextChar)); //1//
identifier = identifier + nextChar;
readNextChar();
}
currentSymbol = handleIdentifier(identifier.toUpperCase());
}
else if (charIsDigit(currentChar)) {
currentSymbol = number();
}
else {
viewScan.update("\nSymbol may consist of two letters"); //1//
switch (currentChar) {
case ' ' :
viewScan.update("\nScip empty character"); //1//
break;
case '\n' : line++; pos=0;
viewScan.update("\nScip end of line"); //1//
break;
case 65535 : currentSymbol = new Symbol(EOP);
viewScan.update("\nEnd of program reached"); //1//
break;
case '{' : comment(); break;
case ':' : if (nextChar == '=') {
readNextChar();
currentSymbol = new Symbol(BECOMES);
}
else {
72

currentSymbol = new Symbol(COLON);
}
break;
case '<' : if (nextChar == '=') {
readNextChar();
currentSymbol = new Symbol(LEQSY);
}
else if (nextChar == '>') {
readNextChar();
currentSymbol = new Symbol(NEQSY);
}
else {
currentSymbol = new Symbol(LSSSY);
}
break;
case '>' : if (nextChar == '=') {
readNextChar();
currentSymbol = new Symbol(GEQSY);
}
else {
currentSymbol = new Symbol(GRTSY);
}
break;
case '.' : currentSymbol = new Symbol(PERIOD);
break;
case '(' : currentSymbol = new Symbol(LPARENT); break;

case ',' : currentSymbol = new Symbol(COMMA);
break;
case '*' : currentSymbol = new Symbol(TIMES);
break;
case '/' : currentSymbol = new Symbol(SLASH);
break;
73

case '+' : currentSymbol = new Symbol(PLUS);
break;
case '-' : currentSymbol = new Symbol(MINUS);
break;
case '=' : currentSymbol = new Symbol(EQLSY);
break;
case ')' : currentSymbol = new Symbol(RPARENT); break;

case ';' : currentSymbol = new Symbol(SEMICOLON); break;
default
: if (currentChar > ' ') Error.error(100,line,pos);

else viewScan.update("\nUeberlese Steuerzeichen"); //1//
}
}
}
viewScan.update(currentSymbol); //1//
return currentSymbol;
}
/**Tries to identify in the given String a keyword.
If it is a keyword, the corresponding object will be returned.
Otherwise, the returned object represents an Identifier covering its name.
@see Symbol
@see SymbolIdent
@return if Keyword found, return it, otherwise SymbolIdent
*/
private Symbol handleIdentifier(String identifier) {
if (identifier == "AND") return new Symbol(ANDSY);
else if (identifier.compareTo("DIV"
) == 0) return new Symbol(DIVSY);
else if (identifier.compareTo("OR"
) == 0) return new Symbol(ORSY);
else if (identifier.compareTo("NOT"
else if (identifier.compareTo("CONST"
) == 0) return new Symbol(NOTSY);

) == 0) return new Symbol(CONSTSY);
else if (identifier.compareTo("TYPE"
) == 0) return new Symbol(TYPESY);
else if (identifier.compareTo("VAR"
) == 0) return new Symbol(VARSY);
74

else if (identifier.compareTo("TO"
) == 0) return new Symbol(TOSY);
else if (identifier.compareTo("PROCEDURE") == 0) return new Symbol(PROCEDURESY);

else if (identifier.compareTo("BEGIN"
else if (identifier.compareTo("OF"
else if (identifier.compareTo("IF"
) == 0) return new Symbol(BEGINSY);
) == 0) return new Symbol(OFSY);

) == 0) return new Symbol(IFSY);
else if (identifier.compareTo("THEN"
) == 0) return new Symbol(THENSY);
else if (identifier.compareTo("ELSE"
) == 0) return new Symbol(ELSESY);
else if (identifier.compareTo("WHILE"
) == 0) return new Symbol(WHILESY);
else if (identifier.compareTo("DO"
) == 0) return new Symbol(DOSY);
else if (identifier.compareTo("FOR"
) == 0) return new Symbol(FORSY);
else if (identifier.compareTo("END"
) == 0) return new Symbol(ENDSY);
else if (identifier.compareTo("PROGRAM" ) == 0) return new Symbol(PROGRAMSY);

else
return new SymbolIdent(identifier);
}
/** Tries to identify a number: either as an integer or as a floating point number
@see SymbolIntcon
@see SymbolRealcon
@return SymbolIntcon- or SymbolRealcon object
*/
private Symbol number() {
final int maxInt
= 2147483647;
final int maxIntDiv10 = maxInt / 10;

final int maxIntMod10 = maxInt % 10;
boolean isInteger
= true;
boolean integerTooLong = false;

int
integerMantisse;
double realMantisse;
int
exponent
= 0;
75

int
expCounter
int
expSign
= -1;
= 1;
integerMantisse = currentChar - '0';

while (charIsDigit(nextChar) && ((integerMantisse < maxIntDiv10))
|| ((integerMantisse == maxIntDiv10) && ((nextChar - '0') <= maxIntMod10))) {
integerMantisse *= 10;
integerMantisse += nextChar - '0';
readNextChar();
}
realMantisse = integerMantisse;
while (charIsDigit(nextChar)) {
integerTooLong = true;
realMantisse *= 10;
realMantisse += nextChar - '0';
readNextChar();
}
if (nextChar == '.') {
readNextChar();
isInteger = false;
if (!charIsDigit(nextChar)) {
Error.error(101,line,pos);
viewScan.update(101); //1//
}
realMantisse += (nextChar - '0') * Math.pow(10, expCounter);
readNextChar();
expCounter--;
}
76

}
if (nextChar == 'E') {
isInteger = false;
readNextChar();
if (nextChar == '-') {
expSign = -1;
readNextChar();
}
if (!charIsDigit(nextChar)) {
}
exponent *= exponent;
exponent += nextChar - '0';
readNextChar();
}
}
if (isInteger) {
if (integerTooLong) {
}
return new SymbolIntcon(integerMantisse);
}
else {
return new SymbolRealcon(realMantisse * Math.pow(10, (expSign * exponent)));
}
77

}
/**scip comments
*/
private void comment() {
viewScan.update("\nUberlese einen Kommentar"); //1//
while (currentChar != '}') {
if (currentChar == 65535) {
}
else {
if (currentChar == '\n') {
line++;
pos = 0;
}
readNextChar();
}}
}
/**return current line number @return current line number */
public int getLine() {
return line;
}
/**@return current column number */
public int getPos() {
return pos;
}
/** run a test: it generates a scanner object and reads symbols by means of getsymbol()
*/
78

public static void main(String argv[])
throws java.io.IOException {
Scanner scan;
Symbol c;
if (argv.length == 0) {
scan = new Scanner(new FileReader("test.pas"));
}
else {
scan = new Scanner(new FileReader(argv[0]));
}
do {c = scan.getSymbol();
System.out.println(c);
} while (c.getTyp() != EOP);
}}
Klasa Error .java

/**
* This class covers all error messages to be printed by the method "error".
*/
class Error implements TokenConsts {
public static void error(int number, int line, int pos) {
System.err.println("Error " + number + ": line " + line + " pos " + pos);
switch(number) {
// lexical errors
case 100: System.err.println("illegal character"); break;
case 101: System.err.println("error in constant"); break;
case 102: System.err.println("constant out of range"); break;
case 103: System.err.println("open comment at end of file"); break;
// syntactical errors
79

case 106: System.err.println("identifier expected"); break;
case 108: System.err.println("error in block"); break;
case 109: System.err.println("error in expression"); break;
case 110: System.err.println("error in procedure declaration"); break;
case 111: System.err.println("error in type declaration"); break;
case 113: System.err.println("error in formal parameter list"); break;
case 114: System.err.println("error in statement sequence"); break;
// semantical errors (static semantics = context-sensitive syntax)
case 201: System.err.println("identifier not declared"); break;
case 204: System.err.println("identifier declared twice"); break;
case 300: System.err.println("type identifier expected"); break;
case 301: System.err.println("procedure expected"); break;
case 302: System.err.println("variable, parameter or constant expected");
break;
case 303: System.err.println("Boolean constant expected"); break;
case 304: System.err.println("integer constant expected"); break;
case 305: System.err.println("more actual parameters expected"); break;
case 306: System.err.println("too many actual parameters"); break;
case 307: System.err.println("type incompatibility in parameter"); break;
case 308: System.err.println("boolean type expected"); break;
case 309: System.err.println("type incompatibility in assignment"); break;
case 310: System.err.println("type incompatibility"); break;
case 311: System.err.println("integer type expected"); break;
case 312: System.err.println("type incompatibility in expression"); break;
case 313: System.err.println("parameter must be a VAR parameter");

break;
case 314: System.err.println("variable expected"); break;
80

default: System.err.println("Other errors");
}
}
public static void symbolError(int typ, int line, int pos) {

System.err.println("Error 105: line " + line + " pos " + pos);
System.err.println("missing " + tokenNames[typ]);
}
public static void ioError() {

System.err.println("IOException");
}
81

Shtojca 3
Rezutatet grafike pr analizn statike
82
83
84
85
86

Referencat
1.
2.
3.
4.
University of Toronto. Introduction to testing. Toronto : s.n., 2012.

Jones, Capers. SOFTWARE DEFECT ORIGINS AND REMOVAL METHODS. 2012.
Software defects 2. [N linj] [Cituar m: 21 August 2014.] http://sgraham745.net/.
Software Testing Tutorial. [N linj] [Cituar m: 21 August 2014.]
http://actoolkit.unprme.org/wp-content/resourcepdf/software_testing.pdf.
5. Software Testing. [N linj]
www.careervarsity.com/careertools/SOFTWARETESTING.ppt.
6. Software Testing. [N linj] [Cituar m: 21 August 2014.]
www.ecs.csun.edu/~rlingard/COMP595VAV/SoftwareTesting.ppt.
7. Gao, Jerry. Introduction to Software Testing. [N linj] [Cituar m: 20 July 2014.]
http://www.engr.sjsu.edu/gaojerry.
8. BUG PREDICTION APPROACHES A SURVEY ANALYSIS. N., Ganeshan dhe Gupta,
Varuna. s.l. : VSRD International Journal of Computer Science & Information
Technology, 2013.
9. Wagner, Stefan. Defect Classification and Defect Types Revisited. 2008.
10. Software Testing. [N linj] 2018. http://softwaretestingfundamentals.com/defect/.
11. [N linj] 2002. http://www.abeacha.com/NIST_press_release_bugs_cost.htm.
12. Test. [N linj] 2013. http://university.utest.com/participation-submitting-reports/.
13. Anderson, Lisa dhe Francis, Brenda. The Bug Life Cycle. s.l. : The Journal of Defense
Software Engineering, 2003.
14. Software Testing Help. [N linj] 2013. http://www.softwaretestinghelp.com/bug-lifecycle/.
15. Oracle. [N linj] 2010. [Cituar m: 29 August 2014.]
http://docs.oracle.com/cd/E19205-01/819-5264/afacc/index.html.
16. Computer Science. [N linj] [Cituar m: 29 August 2014.]
www.cs.umd.edu/~mvz/mswe609/change.pdf.
17. MIT OpenCourseWare, Massachusetts Institute of Technology. [N linj] 2009. [Cituar
m: 29 August 2014.] http://ocw.mit.edu/.
18. Caulfield, William, Jette, Remy dhe Rivera, Joe. https://www.wpi.edu/. Worcester
Polytechnic Institute. [N linj] 2012. [Cituar m: 29 August 2014.]
https://www.wpi.edu/Pubs/E-project/.../E.../CodeChurnDashboard.pdf.
19. GOTEL, ORLENA dhe FINKELSTEIN, ANTHONY. http://eprints.ucl.ac.uk/. UCL
Discovery. [N linj] 1995. [Cituar m: 29 August 2014.]
eprints.ucl.ac.uk/747/1/2.0_contrib.pd. Testimi dhe parashikimi i gabimeve n kod.
20. Giger, Emanuel. http://www.ifi.uzh.ch/index.html. University of Zurich. [N linj] 25
May 2012. [Cituar m: 29 August 2014.]
ww.ifi.uzh.ch/seal/teaching/courses/archive/...1/evolution/sw_evo.pdf.
21. Giger, Emanuel, Pinzger, Martin dhe Gall, Harald C. http://swerl.tudelft.nl/. The
Software Evolution Research Lab. [N linj] 2011. [Cituar m: 10 September 2014.]
http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2011-018.pdf.
22. Rodriguez, Daniel dhe Harrison, Rachel. http://www.cc.uah.es/. [N linj] 2001.
http://www.cc.uah.es/drg/b/RodHarRama00.English.pdf.
23. Giger, Emanuel, Pinzger, Martin dhe Gall, Harald C. http://repository.tudelft.nl/.
TUDelft. [N linj] 21 May 2011. [Cituar m: 29 August 2014.]
87

24. Herzig, Kim, Just, Sascha dhe Zeller, Andreas. Its Not a Bug, Its a Feature: How
Miscssification Impacts Bug Prediction. San Francisco, CA : ICSE 2013, 2014.
25. Kelly, Mike. [N linj]
http://searchsoftwarequality.techtarget.com/answer/Software-bugs-errors-anddefects-Whats-the-difference.
26. Mousavi, Mohammad. Software Testing: IntThere are no sources in the current
document.roduction. 2008.
27. http://www.quora.com/. Quora. [N linj] 2012. [Cituar m: 12 September 2014.]
http://www.quora.com/What-is-the-difference-between-a-software-bug-or-defectand-a-feature-request-improvement-or-enhancement.
28. Kollur, Akhilesh Babu, Gudikandula, Kalpana and K., Tameezuddin. Effective Bug
Tracking Systems: Theories and Implementation. s.l. : Journal of Computer Engineering,
2012.
29. https://www2.informatik.hu-.berlin.de/swt/lehre/TestTools/sota/
30. H. Mcheick, H. Dhiab, M. Dbouk and R. Mcheik, Detecting Type Errors and Secure
Coding
31. http://dl.acm.org/citation.cfm?id=225405
32. http://dl.acm.org/citation.cfm?
33. Paper: Application of Sampling Methods for statistical toler-ance analysis Andreas
Stockinger Sandro Wartzack
34. http://www.locmetrics.com/alternatives.html
35. P.R.Caseley, and M.J.Hadley, Assessing the Effectiveness of Static Code Analysis,
Proceedings of the 1st Institution of Engineering and Technology International
Conference on System Safety, pp.227-237, 2006.
36. P. Brereton, B. Kitchenham, D. Budgen, et al., "Lessons from applying the systematic
literature review process within the software engineering domain," Journal of Systems
and Software, vol. 80 (4), pp. 571-583, 2007.
37. A. Arsanjani, S. Ghosh, A. Allam, et al., "SOMA: A method for developing serviceoriented solutions," IBM Systems Journal, vol. 47 (3), pp. 377-396, 2008.
38. Sanjay Singla, Dharminder Kumar, H M Rai and Priti Singla, A Hybrid PSO
Approach to Automate Test Data Generation for Data Flow Coverage with Dominance
Concepts, International Journal of Advanced Science and Technology, Vol. 37,
December, 2011.
39. International Journal of Advanced Research in Computer Science and Software
Engineering Research Paper Available online at: www.ijarcsse.com A Review on
Optimization Methodologies Used for Randomized Unit Testing
88

Materiali Plote Ledjo Allkoja

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Materiali Plote Ledjo Allkoja

Uploaded by

Copyright:

Available Formats

Analiza ,implementimi dhe optimizimi gabimeve n kod

Testimi i software-it dhe gabimet n kod ............................................................................................. 7

Defektet n software .................................................................................................................... 9

Metodat e testimit ...................................................................................................................... 12

Llojet e testimit ........................................................................................................................... 14

Metrikat e testimit ...................................................................................................................... 15

Parashikimi i gabimeve n kod ........................................................................................................... 17

Cikli i jets s nj gabimi n kod ................................................................................................. 18

Gjetja e gabimeve n kod dhe mjetet e gjurmimit ..................................................................... 23

Sisteme efektive n gjurmimin e gabimeve n kod ............................................................ 24

Modelet e parashikimit t gabimeve n kod .............................................................................. 25

Metrikat e bazuar tek ndryshimet ...................................................................................... 26

Metrikat e kodit .................................................................................................................. 27

Metrikat e organizimit ........................................................................................................ 30

Mjetet e prdorura ............................................................................................................................. 32

Si punon SOTA ..................................................................................................................... 33

Tipet e prdorimit ............................................................................................................... 33

Puna me SOTA ..................................................................................................................... 34

Metrikat e shfaqura ............................................................................................................ 37

Metodat e numrimit ......................................................................................................... 38

Analiza ,implementimi dhe optimizimi gabimeve n kod

Analiza Dinamike ................................................................................................................................. 40

Objektivi dhe motivimi. ............................................................................................................... 40

Software-i nn testim. Rast studimor. ........................................................................................ 40

Problemet ne kualitetin software-ik dhe matjet e tij. ............................................................... 48

Objektivi dhe motivimi. ....................................................................................................... 48

Software-i nn testim ......................................................................................................... 48

Komentet mbi vlerat e metrikave MVG dhe LOC............................................................... 48

Klasa Error.java ........................................................................................................................... 49

Rezultatet e SOTA ............................................................................................................... 50

Rezultatet e SOTA ............................................................................................................... 54

Klasa testuese n Java......................................................................................................... 47

Analiza Statike ..................................................................................................................................... 48

Implementimi i rastit studimor. .......................................................................................... 40

Avantazhet dhe disavantazhet e kompleksitetit iklomatik ....................................................... 55

Vlerat e kqija pr kompleksitetin iklomatik .................................................................... 57

Optimizimi dhe sfidat n t ardhmen ................................................................................................. 60

Optimizimi i gabimeve n kod .................................................................................................... 60

Nivelet e optimizimit ................................................................................................................... 60

Platforma e varur dhe optimizimi i pavarur................................................................................ 62

Pikat bllokuese ............................................................................................................................ 62

Sfidat e optimizimit ..................................................................................................................... 63

Lista e figurave ............................................................................................................................................ 65

Analiza ,implementimi dhe optimizimi gabimeve n kod

Analiza ,implementimi dhe optimizimi gabimeve n kod

Analiza ,implementimi dhe optimizimi gabimeve n kod

Metrikat e tipit t testimit

Analiza ,implementimi dhe optimizimi gabimeve n kod

Analiza ,implementimi dhe optimizimi gabimeve n kod

Figura 1 Fazat e zhvillimit t nj software

Analiza ,implementimi dhe optimizimi gabimeve n kod

Figura 2 Modeli Waterfall

Analiza ,implementimi dhe optimizimi gabimeve n kod

Redaktimet e t dhnave jo t sakta dhe redaktimet e t dhnave jo efektive

2.2 Defektet n software

Defektet n krkesat e software-it

Analiza ,implementimi dhe optimizimi gabimeve n kod

2.3 Nivelet e testimit

Analiza ,implementimi dhe optimizimi gabimeve n kod

N nj mjedis t plot t zhvillimit t software-it realizohet fillimisht testimi Posht-Lart dhe m

Analiza ,implementimi dhe optimizimi gabimeve n kod

Figura 3 Nivelet e testimit

2.4 Metodat e testimit

T prshtatshme dhe efikase pr segmente t mdha t kodit